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

All grades are calculated out of 100 pts maximum

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?
• 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
• Hold your first (virtual) meeting: include a picture showing your entire team or everyone's camera feeds in a video conferencing software of your choice
• Discuss every aspect of the team agreement in detail and describe all your decisions in the writeup
  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

Use Moore's product vision template to create a product vision statement as described below:

• For [target customer],
• whose [problem that needs to be solved],
• the [name of the product]
• is a [product category]
• that [key-benefits, reason to buy it].
• Different from [competition alternative],
• our product [key-difference].

Create an outline mapping at least three personas to a scenario of how they would use your software product:

• For each identified persona, specify their demographics, goals, problems, motivation and intention.
• For each persona, describe the context in which they would use your product, and provide a scenario illustrating how your product would help each persona to meet their goal(s).
• See How to Create Effective User Scenarios: A Step-by-Step Guide for reference.

Use an online planning tool to put together a detailed prioritized product backlog document as described below:

• Provide a narrative to give a general overview of the system's functional requirements
• Break down your product backlog into logical sections. Provide a meaningful organization of your user stories within each section
• Each user story must be written using the following format:
  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.
• Provide a separate list of any relevant nonfunctional requirements written as user stories
• Include a glossary that defines all relevant terms that may have a special meaning in the context of the system

We will create our product backlogs in two iterations, resulting in a draft and a refined version. The refined version of the product backlog must have the following (none of these are required in the draft):

• All user stories must be prioritized
• All user stories must be assigned weights using the Fibonacci scale
• Use themes/sections to group your user stories
• Consider and reflect on any possible implications of the chosen application architecture on the way how user stories are formulated, their priorities, and story point sizes

Consider three architectural options for building your project:

• A client-only desktop or mobile application with no server-side component,
• A client-server application, including a web-based application with some meaningful client-side logic, and
• An application build using a service-oriented architecture.

Compare and contrast these architectural options and their implications on your project. For each approach, discuss the following:

• How will the processing logic be distributed across various components?
• How would each option impact the project development process?
• Advantages and disadvantages from the following perspectives:
• Architectural complexity,
• Resilience,
• Scalability,
• Security.

Create a 2-page outline justifying your current architectural choice on the basis of the points listed above. One page of the outline should include a table comparing the three architectural options vs four perspectives.

Consider several microservices that are currently are (or are planned to be) integrated into your project. For each one, describe the following:

• Main purpose
• Overall functionality
• Provider
• Replacement options (what other similar services are available that could be used instead of the current one)

Propose a new microservice that could be implemented using some of the existing (or soon to be implemented) features of your project. What would be the purpose of this hypothetical microservice? How would other (3rd party) applications take advantage of the microservice you are offering? Keeping in mind the decomposition guidelines, describe the following characteristics of your proposed microservice:

• Self-contained
• Lightweight
• Implementation independent
• Independently deployable
• Business-oriented

Create a 2-page outline describing your current and/or planned use of existing microservices, as well the proposed new hypothetical microservice.

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

• Briefly introduce your team and project
• What did you 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 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)
• What was you team velocity at this sprint? How did you calculate it? What was the number of story points that you a) planned for this sprint and b) actually completed during this sprint? How does your team velocity compare with that from the previous sprint (if applicable)? What does it tell you with regard to reaching the project goal on time? Provide a burndown chart illustrating the team's current trajectory along with the ideal trajectory. (1 pts)
• (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.

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
• Explain the main features of the system to a potential user who may not be familiar with it
• Provide a walkthrough for the main scenario of using your system; include screenshots as necessary
• Provide walkthroughs for at least two additional scenarios with additional/alternative functionality; include screenshots as necessary

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. These surveys will be strictly confidential. Students who fail to complete this survey will receive a grade of 0 for the entire course project.