Objective: design and implement a complex software system utilizing the skills acquired in this course

All grades are calculated out of 120 pts maximum

Note: all dates are subject to change

This project must be completed by teams of three or four students using an agile process model.

Each deliverable must be submitted on or before the indicated due date. Teams will not be allowed to proceed to a subsequent project phase without submitting a satisfactory deliverable for the previous phase.

Each deliverable document must have a title page indicating the project title, deliverable name, team name and membership, and submission date.

The following will always be considered when grading your work in this course:

• Presentation: the report is well formatted, easy to read, and easy to navigate;
• Quality of writing: language, grammar, clarity, professionalism;
• Consistency: all required points are addressed in the same order as listed in each section below.

Get to know your team and make decisions about your own rules. Submit a PDF document containing the following:

• Introduce your team: give your team a unique name and provide a group picture of the entire team. What are the strengths of your team as a whole? (1 pt)
• Introduce each team member: include a picture and a 100 word biography of each team member. A biography should be professional as if you were introducing yourself to a prospective employer. Identify one team member who will serve as the main contact for the instructor (3 pts)
• Hold your first virtual meeting: include a picture showing your camera feeds in a video conferencing software of your choice (1 pt)
• Discuss every aspect of the team agreement in detail and describe all your decisions in the writeup (5 pts)
  Your team agreement must include the guidelines for the following (but feel free to add any other items you believe are important):
  • methods of communication (email, phone, messenger, text, ...)
  • communication response times (email, phone, messenger, text, ...)
  • meeting attendance (when to meet, whether all meetings are mandatory, ...)
  • running meetings (when, where, face-to-face vs. online, who takes minutes/notes, ...)
  • meeting preparation (whether preparation is needed, what to prepare, ...)
  • version control (what to/not to commit, content of log messages, ...)
  • division of work (how to divide work, who will decide who does what, ...)
    Important note: it's not OK to have a strict division of responsibilities, e.g. one team member will write all documentation/reports, one will serve as a team manager, one will serve as a developer, one will serve as a tester. Each team member is expected to contribute to a broad spectrum of the team's tasks.
  • submitting assignments (when to submit, who will submit, who will review the submission, ...)
  • contingency planning (what if a team member drops out, what if a team member consistently misses meetings, what if a team member is academically dishonest, ...)
• Each team member needs to create GitHub account. Include each member's GitHub account name in the writeup (0 pts)

Submit an essay (PDF, 2 pages max) describing the following:

• Intended use of the system: who and how will use the system (4 pts)
• Its overall functionality: what will the system do, how will the system help its users accomplish their tasks (3 pts)
• Main components of the system: break down the system into logical or architectural components and provide the rationale for this breakdown (3 pts)

Submit a system requirements document (PDF with a UML use case diagram, no page limit) as described below:

• Begin with a narrative to give a general overview of the system's functional requirements. Provide one big use case diagram illustrating the overall functionality of the system. Describe each use case in an easy to understand natural language (2 pts)
• Using the use case diagram as a starting point, convert each use case into a user story. Organize your user stories as a numbered list (2 pts)
  A typical format of the user story is as follows: As a user role, I want goal so that reason:
  • The user role represents an actor or a developer who benefits from this story;
  • The goal of the story is a feature or function in the system, a tool, or a part of a production pipeline;
  • The reason describes the benefit to the customer or user when this feature or function is used.
• For each user story, provide a set of pre- and post-conditions (refer to each corresponding user story by their numbers). Note: list pre- and post-conditions under the corresponding user story. Note: there should be a single list of user stories in your document (2 pts)
• Are there any user stories that are too big or complex (these user stories are usually referred to as 'epics')? Can some of them be decomposed into smaller user stories? For each user story, mention whether or not it may need to be broken down (this will be done later) (1 pt)
• Provide a separate list of any relevant nonfunctional requirements (1 pt)
• Include a glossary that defines all relevant terms that may have a special meaning in the context of the system (2 pts)

Submit a detailed prioritized product backlog document (PDF, no page limit) as described below:

• Refine your user stories taking into account the instructor's feedback. Break down previously identified large user stories (epics). Indicate which epics resulted in what new user stories (2 pts)
• Estimate the size of your user stories. Use Fibonacci numbers within the range of 1 to 21 to represent a relative size of each user story. Label each user story as high, medium, or low priority. Note the cumulative size of all user stories in your product backlog (2 pts)
• Provide an updated numbered list of all user stories; indicate pre- and post-conditions (1 pt)
• Taking into account the pre- and post-conditions, identify a subset of user stories to be implemented during the first sprint (there will be a total of four sprints). Be sure that the cumulative size of the selected user stories is about 1/4 of the size of the full backlog. Describe the functionality that your partially implemented system will have at the end of this sprint (3 pts)
• Design key features of the user interface; provide sketches of your designs (2 pts)

Each team will make an in-class presentation reflecting on the following:

• The project, its goals, its problem domain, project users and their needs (2 pts)
• Main functional and non-functional requirements of the project (2 pts)
• Highlights of the product backlog and sprint planning strategies (2 pts)
• Any lessons learned about interacting with the customer, teamwork, and other non-technical aspects of the project (2 pts)

Submit a PPT used for the in-class presentation. The presentation must be free of typos, readable and understandable by the audience, and neatly formatted (2 pts)

During every in-class sprint retrospective/review, each team needs to present and address the following:

• Briefly introduce your team and project.
• What did the team accomplish during the sprint? How many story points did you a) plan for and b) completed? Include a demo focusing on the work completed in this sprint.
• What were the individual contributions of each team member during this sprint? Specifically, what were the tasks assigned to each team member and how much each team member was able to accomplish?
• What aspects of the sprint (development/technologies/teamwork/etc) worked well for you?
• What problems did you encounter and how did you resolve them?
• What are the lessons learned so far?
• What changes will you be making based on the lessons learned?
• What challenges do you anticipate in the next sprint?

At the end of each sprint, submit a sprint report (PDF, no page limit) containing the following:

• What functionality does the system have at the end of this sprint? List user stories that you successfully implemented during this sprint (1 pt)
• Did you end up making any changes to any of these user stories? Did you break down further any the user stories? Did you identify any new user stories during this sprint and, if so, did you add them to the product backlog or decide to implement them right away? Explain (1 pt)
• What are the "lessons learned" at the end of this sprint? What would you do differently next time? Explain (1 pt)
• Provide an updated numbered list of all user stories yet to be implemented; indicate pre- and post-conditions (1 pt)
• (1 pt)
  • If this is not the last sprint:
    Given the current functionality of the system and taking into account the pre- and post-conditions, identify a subset of user stories to be implemented during the next sprint. Be sure that the cumulative size of the selected user stories is about 1/4 of the size of the full backlog. Describe the functionality that your (partially implemented) system will have at the end of this sprint.
  • If this is the last sprint:
    Are there any user stories left unimplemented in the backlog? Are there any new user stories that you would consider adding to the backlog. List these user stories and explain them.

All software developed within this project must be successfully demonstrated in class. Each demonstration must be accompanied by a brief presentation explaining the nature/specifics of the project. Project demonstration grade will reflect the quality and degree of project completion.

Submit the user manual document (PDF, 2 pages minimum, not including the screenshots) as described below:

• Detail all necessary steps needed to deploy/install your system. Provide all necessary technical specifications (2 pts)
• Explain the main features of the system to a potential user who may not be familiar with it (3 pts)
• Provide a walkthrough for the main scenario of using your system; include screenshots as necessary (3 pts)
• Provide walkthroughs for at least two additional scenarios with additional/alternative functionality; include screenshots as necessary (2 pts)

All deliverables will be graded as a result of work of the entire team. However, individual students may receive different grades based on the degree and quality of their involvement in the project. To facilitate the objectivity in grading, each student will be required to complete one or more confidential survey about the involvement of other members of his or her team in the project. This survey will be strictly confidential. Students who fail to complete a teamwork survey will receive a grade of zero for the entire course project.

Each course project is expected to meet customer requirements and be completed by the end of the semester. The degree to which the project meets original requirements will be determined by the project customer and the course instructor. In cases when the project requirements are not fully met, the team's project grade may be adjusted proportionally.