Overview
In a team of 4 or 5 you need to work through the semester to design and implement a web application with frontend, backend and data storage components following software develpment processes and maintaining documentation. The project is divided into 5 sprints each of which is dedicated to a specific goal. The team will be graded based on the quality of implementation, quality of produced documentation, following the development process, and preparadness to demos and presentations. The team grade will be individually modified based on personal contributions of each team member into each aspect (Trello activity, Slack presence, GitHub contribution) and peer evaluations.
The project has to be implemented with Java and Spring Boot for backend and Angular for frontend. You can find more information about these technologies in the resources section. Use of additional libraries and frameworks have to be approved by your instructor.
Project Vision
Non-profit organizations worldwide face diverse, evolving challenges but lack effective ways to connect with those who can help. Their needs vary ranging from physical goods and funding to volunteer labor or specialized skills and each organization maintains a dynamic set of these needs (a “Cupboard”), reflecting both type and status (e.g., unmet or fulfilled). Due to limited software expertise and the need for customization, many organizations prefer to acquire tailored solutions over using generic platforms or in-house development. This is the gap we aim to address by creating a custom need management system (U-Fund).
Non-profit Organization
Select a small imaginary non-profit organization to support, grounded in a specific context such as a culture, location, cause, or real-world need where your team can make a meaningful impact. Suitable examples include a disaster relief group connecting aid providers with affected communities, a fishing cooperative distributing their catch in equitable way based on members' needs every week, a faith-based organization coordinating donations for local needs, a nature preservation society coordinating volunteer efforts in maintaining trails and campsites, or an elderly care facility organizing activities for residents. Avoid overly broad or generic ideas such as a GoFundMe clone or a general-purpose need management system, as they lack focus or are too large in scope.
Note that different non-profits may have different types of needs (monetary donations, volunteer hours, etc.) which will have different structure and data, try to come up with an idea that will have at least two types of needs.
Minimum Viable Product
It doesn't matter what non-profit organization you develop the system for, the core functionality remains the same.
- Minimal Authentication
- The system will fully trust the browser for user identity (not secure by design). Passwords are not required.
- Users can log in and log out of the application.
- The U-fund Manager logs in using the reserved username admin. Any other username is treated as a Helper.
- The application must adjust available features based on the logged-in user role.
- Manager Functionality
- Can create, edit, and delete needs in the system.
- Cannot view or access helpers’ funding baskets.
- Helper Functionality
- Can see all available needs, and details of each of them.
- Can search for needs.
- Can add or remove needs to / from a personal funding basket.
- Can proceed to checkout and fund selected needs.
- Data Persistence
- Updates to the needs cupboard must persist across login sessions and users.
- Funding basket contents must persist across logout and login (even in different browsers).
- JSON file(-s) as a storage is sufficient.
This vision is quite generic and unspecified which represents the typical situation where a client has an idea, but hasn't fully defined it yet. It also has lacuns where some functionality is implied and logical, but not outlined directly word-by-word. You HAVE to work with the Product Owner (your instructor) to clarify the details. Lack of communications can lead to implementing wrong features and broken Product Owner's unspoken expectations which will result in grade penalties.
Sprint 0
Domain Analysis
Use one of the professional diagramming tools (Documentation section)
- create a domain model diagram based on the given feedback
- export it in one of the standard image formats (e.g., png, jpeg)
Product Backlog
If you are in doubts how some features should behave, don't hesitate to ask the Product Owner (your instructor).
- consolidate the identified epics and user stories for MVP from all team members into one list avoiding duplicates
- review user stories in the product and sprint backlogs on the project board that was copied into your Trello workspace and identify missing ones
- add missing user stories and epics to the product backlog on the project board based on your consolidated list (use templates cards provided on the project board)
- link user stories to respective epics (your can create new epics if you see it appropriate)
- go through user stories in the sprint backlog and add acceptance criteria and definition of done in the cases where they are missing
- identify areas that you need to research to successfully implement listed user stories and create corresponding spikes in the product or sprint backlog depending on their urgency
- go through the product and sprint backlogs and sort the cards by priority / order in which they should be done
- by the end, each user story card in the sprint backlog should have a short name as a title, a full user story as a description, a definition of done checklist and an acceptance criteria checklist
Submission
Submit the domain model image to the Sprint 0 assignment on myCourses. Your instructor has access to your Trello workspace and Slack channel, and will review your work.
Grading Criteria
| Exceptional Performance (100 points) | Competent Performance (88 points) | Acceptable Performance (75 points) | Developing Performance (50 points) | Unacceptable Performance (0 points) | |
|---|---|---|---|---|---|
| Domain Model 40% | Correctly captures all entities with all elements of relationships shown. | Captures core entities and relationships. Model is entirely in the language of the domain but there may be issues with the relationships. | Entities mostly complete, some language may be outside the domain, relationships with notations mostly correct. | Many entities missed, language not in the domain, little notation on relationships. Minimal effort put into creating model. | Domain model was not submitted or shows little domain understanding. |
| Backlogs 40% | Provide a full set of properly formed user stories, epics, and spike stories for MVP | Have a full set of user stories, epics, and spike stories with a small number of issues with format or missing stories for MVP. | Have issues with the format of several stories, or they miss several stories or epics. | There are format issues with most stories, or they miss many stories or epics. | There is minimal evidence of the team developing the backlogs. |
| Communications 20% | Team consistently communicates via Slack. | Team mostly regularly communicates via Slack. | Team communicates via Slack in bursts. | Team rarely communicates via Slack. | Minimal evidence of use of Slack. |
Sprint 1
Planning
Fix any issues identified in the feedback for Sprint 0 and update your Trello board. Each task in the sprint backlog should have proper checklists of acceptance criteria and definition of done.
Scope
Implement user stories from your Sprint Backlog and their edge cases (acceptance criteria) on backend and provide the functionality via REST API:
- As a Developer I want to submit a request to create a new need (the specific set of fields depends on the need type) so that it is added to the cupboard.
- As a Developer I want to submit a request to get a single need so that I can access its information.
- As a Developer I want to submit a request to get all needs so that I have access to all of the needs for the organization.
- As a Developer I want to submit a request to delete a single need so that it is no longer in the cupboard.
- As a Developer I want to submit a request to get the needs in the cupboard whose name contains the given text, so that I have access to only that subset of needs.
- As a Developer I want to submit a request to modify an item in the cupboard so that I can update needs in the cupboard.
During implementation:
- use proper branching and avoid committing directly to the main branch (don't forget --no-ff)
- follow the proper task management process and update your Trello board timely
- ask the Product Owner (your instructor) if you are not sure how some features should behave
Execute the spike:
- As a Developer I want to learn the Angular framework so that I can develop the project.
Design Document
Find the design document in your code repository and update all parts that are marked as Sprint 1. Do not hesitate to ask your instructor for clarifications if you are unsure about any part.
The design document should be updated each time you complete a user story, not at once after everything is done.
Release
When you create a new release, use vM.P notation (e.g., v1.0, v2.1). M - a major version matching the sprint number, P - a patch version. The initial release for Sprint 1 should be taged as v1.0. If after creating the release but before the deadline you need to make changes (e.g., fixing a bug), you can create a new release and bump the patch version (e.g., v1.1, v1.2).
- Open the main page of your project repository on GitHub, find the release section on the right side and click on the "Create a new release" link.
- Keep "main" as a target and put your release version into the "Tag" field.
- Scroll down and click on the "Publish release" button
Demo
You have to conduct a live demo for all user stories you implemented and their edge cases (acceptance criteria) using your system running on one of the team members' laptops. All team members have to participate. The demo should continue for 5-10 minutes (check with your instructor), so you need to plan carefully and in some cases decide what are the most important edge cases to demonstrate and which ones can be omitted to fit within the time limit.
The demo shouldn't be just a laundry list of features, try to add a narrative that connects the features and shows their value to users.
When other team is presenting, try to find issues or unclear aspects of their demo, explanations or the system behaviour so you would be able to ask meaningful questions after their demos is completed.
Recording
In addition to the live demo, prepare a recording of your demo before the class. All members have to participate. A recording of a team demo meeting over Zoom or any other platform is enough. This recording will be used as a backup option by your instructor if they need to recall some aspects of the demo.
Submission
Submit your demo recording to the Sprint 1 assignment on myCourses as a video file or video / file sharing platform link (you can upload a video on YouTube and make it unlisted - nobody without a direct link will be able to find it). Your instructor has access to your Trello workspace, GitHub repository and Slack channel, and will review your work.
Grading Criteria
| Exceptional Performance (100 points) | Competent Performance (88 points) | Acceptable Performance (75 points) | Developing Performance (50 points) | Unacceptable Performance (0 points) | |
|---|---|---|---|---|---|
| Architecture, Diagram and rationale 15% | Team properly documents their design work and rationale. Tiers/Layers Diagram is properly updated, components (e.g. controllers, services, entities,etc.) are added to correct tier and within the appropriate layer. Diagram is clear and works to support the claims. | Team documents their design work and rationale. Tiers/Layers Diagram is updated, and works to support the claims. Only a few issues found. | Team documents their design work and rationale. Tiers/Layers Diagram is updated, and works to support the claims but consistency is lacking. | Team documents their design work but rationale is inconclusive. Tiers/Layers Diagram lacks evidence to support the claims. | There is little effort in either the descriptions or evidence in the diagram to support the claims. |
| Code Communication 25% | Code adheres to style guideline; uses good variable, method, and class names; provides Javadocs for methods and classes; appropriate user of helper methods. | Code shows adherence to good code communications practices with only a few issues found. | Adherence to good code communications practices is apparent but consistency is lacking. | There are multiple major issues with adherence to good code communication practices. | Code does not meet most elements of good code communication. |
| Demo 25% | Team created a polished demo which covered all required features and unique inputs in detail, was easy to follow and showed the program runs without any problems. | Team created a polished demo which was easy to follow but there were a few minor issues noted with the demo. | Team created demo but there were major issues with delivery. | Team did not appear prepared but was able to carry off something of a demo. | Team did not provide demo or created one with minimal results. |
| Planning Activities 10% | Team correctly entered user stories into the sprint backlog and tracked them through to completion. | All team members were involved in planning activities but there were a few minor issues noted. | Only a portion of the team was involved in planning activities, or it was not done consistently. | Only a portion of the team was involved in planning activities, and it was not done consistently. | Minimal evidence of team performing planning activities. |
| Version Control 15% | The team consistently used version control to track project artifacts. | The team used version control but its use was not consistent. | The team used version control, but its use was only in a bursts. | The team had minimal use of version control, or its use was mostly just prior to submission. | There is little evidence of the team using version control to track artifacts. |
| Team Communication 10% | Team consistently communicates using Slack workspace including Virtual Standups. | Team has mostly regular use of Slack workspace including Virtual Standups. | Team uses Slack workspace including Virtual Standups in bursts. | Some evidence of use of Slack workspace including Virtual Standups. | Minimal evidence of use of Slack workspace. |
Enhancements
Around the beginning of Sprint 2, you need to come up with 2 enhancements that will extend the functionality of your system and that you will need to implement during Sprint 3 (think ahead). You need to find features complex and large enough to occupy the whole team through Sprint 3, but be careful not to overcommit.
Some examples of bad enhancements:
- [too simple] Adding a new filter to the search functionality.
- [too simple] Adding a page with information about the organization.
- [too complex] IRS-compliant tax calculation and reporting system.
- [no value] Enhancing the user interface with visual improvements.
You can check the examples of enhancements that have been implemented in previous semesters and use some of them (but try to come up with your own unique ideas after understanding the expected level of complexity).
Each enhancement has to be approved by the Product Owner (your instructor). Do not delay the ideation as in many cases your initial idea may go through several iterations of negotiations with the Product Owner before being finalized - it takes time.
Sprint 2
Planning
Identify and prioritize user stories for Sprint 2. If you realised that some of them are missing or incomplete, update your backlog on Trello accordingly. Each task in the sprint backlog should have proper checklists of acceptance criteria, definition of done, and solution tasks. Execute a planning poker session and assign story points to each user story in your Sprint Backlog.
Frontend and backend tasks and user stories should be separate. E.g., if you have a login feature, create a separate backend task and a user story from a developer's point of view (As a developer...) as end users do not interact with backend API endpoints, only frontend code do, and separate frontend tasks and user stories from a user's point of view (As a manager... / As a helper...). Typically, it means there will be a feature-based epic that will references both tasks / cards.
Scope
Implement user stories from your Sprint Backlog and their edge cases (acceptance criteria) for both backend and frontend. By the end of Sprint 2, you should have a fully working implementation of the MVP described in the project vision.
During implementation:
- use proper branching and avoid committing directly to the main branch (don't forget --no-ff)
- follow the proper task management process and update your Trello board timely
- ask the Product Owner (your instructor) if you are not sure how some features should behave
Execute any spike(-s) you planned for Sprint 2.
Acceptance Test Plan
If during planning or later you identify any missing user stories or acceptance criteria and create them, update your acceptance test plan immediately. It should always reflect the current state of your project.
While acceptance criteria is a part of definition of done and should be tested every time you test a user story before moving it to done, the acceptance test plan should be used at the end of the each development sprint before releasing to make sure the system as a whole works as expected.
You should go through your acceptance test plan and test everything. For passed tests, you put PASS into a corresponding column and your initials and the date to the comment column. For failed tests, you put FAIL into a corresponding column and what specifically went wrong, your initials and the date to the comment column.
Design Document
Find the design document in your code repository and update all parts that are marked as Sprint 1 and Sprint 2 so the document reflects the current state of your project. Do not hesitate to ask your instructor for clarifications if you are unsure about any part.
The design document should be updated each time you complete a user story, not at once after everything is done.
Release
When you create a new release, use vM.P notation (e.g., v1.0, v2.1). M - a major version matching the sprint number, P - a patch version. The initial release for Sprint 2 should be taged as v2.0. If after creating the release but before the deadline you need to make changes (e.g., fixing a bug), you can create a new release and bump the patch version (e.g., v2.1, v2.2).
- Open the main page of your project repository on GitHub, find the release section on the right side and click on the "Releases" header.
- Click on the "Draft a new release" button.
- Keep "main" as a target and put your release version into the "Tag" field (agree to create a new tag if offered).
- Scroll down and click on the "Publish release" button
Demo
You have to conduct an in-class live demo for all user stories you implemented during Sprint 1 and Sprint 2 from the user perspective (UI) and their edge cases (acceptance criteria) using your system running on one of the team members' laptops. You should use your acceptance test plan as a backbone for the demo scenario to not miss any important aspects. All team members have to participate. The demo should continue for 5-10 minutes (check with your instructor), so you need to plan carefully and in some cases decide what are the most important edge cases to demonstrate and which ones can be omitted to fit within the time limit.
The demo shouldn't be just a laundry list of features, try to add a narrative that connects the features and shows their value to users.
When other team is presenting, try to find issues or unclear aspects of their demo, explanations or the system behaviour so you would be able to ask meaningful questions after their demos is completed.
Recording
In addition to the live demo, prepare a recording of your demo before the class. All members have to participate. A recording of a team demo meeting over Zoom or any other platform is enough. This recording will be used as a backup option by your instructor if they need to recall some aspects of the demo.
Submission
Submit your demo recording to the Sprint 2 assignment on myCourses as a video file or video / file sharing platform link (you can upload a video on YouTube and make it unlisted - nobody without a direct link will be able to find it). Your instructor has access to your Trello workspace, GitHub repository and Slack channel, and will review your work.
Grading Criteria
| Exceptional Performance (100 points) | Competent Performance (88 points) | Acceptable Performance (75 points) | Developing Performance (50 points) | Unacceptable Performance (0 points) | |
|---|---|---|---|---|---|
| Architecture and Design Principles 20% | Team properly documents and accurately describes at least two design principles exemplified in their design and explains how and where they will/have materialized in their solution across all tiers in great detail. Diagram(s) are clear and work to support the claims. | Team documents and describes at least two design principles exemplified in their design and explains how and where they will/have materialized in their solution across most tiers. Diagram(s) are clear and work to support the claims. Only a few issues found. | Team documents and describes general design goals in their design and explains how and where they will/have materialized in their solution across some tiers, with minimal detail. Diagram(s) work to support the claims but consistency is lacking. | Team documents and describes minimally the principles in their design and fails to explains how or where they will/have materialized in their solution. Diagram(s) lack evidence to support the claims. | There is little effort in either the descriptions or evidence diagram(s) to support the design principles. |
| Unit Tests and Code Coverage 15% | Full set of high quality unit tests providing over 90% coverage. | Full set of high quality unit tests providing over 75% coverage. | Unit tests are of high quality with at least 50% coverage, or have some issues with mechanics and provide at least 65% coverage. | Significant unit tests are missing or are of notable poor quality in terms of mechanics. | Unit tests are very low quality either in terms of coverage or mechanics. |
| Design Documentation 10% | Document organized as coherent sections and subsections in a logical sequence and hierarchy with clear transitions and diagrams that follow structure; no notable issues with mechanics. | Document organized as coherent sections and subsections that follow logically in sequence and hierarchy using good diagrams; some issues with mechanics. | Document is mostly organized in a coherent structure follow structure but has notable issues with diagrams; Mechanics may hinder readability in places. | Document has significant issues with aspects of organization, diagrams, structure, or mechanics. | Document has little organization, unreadable diagrams, no coherent structure, and spelling, grammar or other mechanics issues throughout. |
| Acceptance Test Plan 10% | Complete Acceptance Test Plan showing full suite of acceptance criteria and test results. | Complete Acceptance Test Plan shows full suite of acceptance criteria with only a few issues with test results. | Acceptance Test Plan has been updated with most user stories and acceptance criteria, and shows most test results. | Acceptance Test Plan lacking many user stories, acceptance criteria, or test results. | No evidence of updating of Acceptance Test Plan with user stories, acceptance criteria, and test results. |
| Demo 25% | Team created a polished demo which covered all required features and unique inputs in detail, was easy to follow and showed the program runs without any problems. | Team created a polished demo which was easy to follow but there were a few minor issues noted with the demo. | Team created demo but there were major issues with delivery. | Team did not appear prepared but was able to carry off something of a demo. | Team did not provide demo or created one with minimal results. |
| Planning Activities 10% | Team correctly entered user stories into the sprint backlog and tracked them through to completion. | All team members were involved in planning activities but there were a few minor issues noted. | Only a portion of the team was involved in planning activities, or it was not done consistently. | Only a portion of the team was involved in planning activities, and it was not done consistently. | Minimal evidence of team performing planning activities. |
| Version Control Activities 10% | The team consistently used version control to track project artifacts with clear and consistent use of feature branching. | The team used version control but its use was not clear and consistent in tracking artifacts or use of feature branching. | The team used version control, but its use was only in a bursts. | The team had minimal use of version control, or its use was mostly just prior to submission. | There is little evidence of the team using version control to track artifacts. |
Sprint 3
Planning
Identify and prioritize user stories for Sprint 3. Each task in the sprint backlog should have proper checklists of acceptance criteria, definition of done, and solution tasks. Execute a planning poker session and assign story points to each user story in your Sprint Backlog.
You can proceed with separate user stories for frontend and backend tasks or create feature-based user stories that include both frontend and backend aspects depending on how you want to organize work within your team.
Scope
By the beginning of Sprint 3, you should have a clear and aligned with the Product Owner (your instructor) understanding of enhancements that you will design and implement. The sprint is fully dedicated to delivering these enhancements, and there will be no coding after Sprint 3, so make sure to plan accordingly.
However, if the MVP functionality is not fully implemented, doesn't function as expected by the Product Owner or contains noticeable issues, your enhancements will not be graded. If it's your case, make sure the MVP scope is fully completed before proceeding with enhancements.
During implementation:
- use proper branching and avoid committing directly to the main branch (don't forget --no-ff)
- follow the proper task management process and update your Trello board timely
- ask the Product Owner (your instructor) if you are not sure how some features should behave
Execute any spike(-s) you planned for Sprint 3.
Acceptance Test Plan
If during planning or later you identify any missing user stories or acceptance criteria and create them, update your acceptance test plan immediately. It should always reflect the current state of your project.
While acceptance criteria is a part of definition of done and should be tested every time you test a user story before moving it to done, the acceptance test plan should be used at the end of the each development sprint before releasing to make sure the system as a whole works as expected.
You should go through your acceptance test plan and test everything. For passed tests, you put PASS into a corresponding column and your initials and the date to the comment column. For failed tests, you put FAIL into a corresponding column and what specifically went wrong, your initials and the date to the comment column.
Design Document
Find the design document in your code repository and update all parts that are marked as Sprint 1, Sprint 2, and Sprint 3 so the document reflects the current state of your project. Do not hesitate to ask your instructor for clarifications if you are unsure about any part.
The design document should be updated each time you complete a user story, not at once after everything is done.
Release
When you create a new release, use vM.P notation (e.g., v1.0, v2.1). M - a major version matching the sprint number, P - a patch version. The initial release for Sprint 3 should be taged as v3.0. If after creating the release but before the deadline you need to make changes (e.g., fixing a bug), you can create a new release and bump the patch version (e.g., v3.1, v3.2).
- Open the main page of your project repository on GitHub, find the release section on the right side and click on the "Releases" header.
- Click on the "Draft a new release" button.
- Keep "main" as a target and put your release version into the "Tag" field (agree to create a new tag if offered).
- Scroll down and click on the "Publish release" button
Demo
You have to conduct a live demo for all user stories you implemented during Sprint 1, Sprint 2, and Sprint 3 from the user perspective (UI) and their edge cases (acceptance criteria) using your system running on one of the team members' laptops. You should use your acceptance test plan as a backbone for the demo scenario to not miss any important aspects. While you need to demonstrate the whole functionality, try to mostly focus on the enhancements that make your project unique. All team members have to participate. The demo should continue for 10-15 minutes (check with your instructor), so you need to plan carefully and in some cases decide what are the most important edge cases to demonstrate and which ones can be omitted to fit within the time limit.
The demo shouldn't be just a laundry list of features, try to add a narrative that connects the features and shows their value to users.
When other team is presenting, try to find issues or unclear aspects of their demo, explanations or the system behaviour so you would be able to ask meaningful questions after their demos is completed.
Recording
In addition to the live demo, prepare a recording of your demo before the class. All members have to participate. A recording of a team demo meeting over Zoom or any other platform is enough. This recording will be used as a backup option by your instructor if they need to recall some aspects of the demo.
Submission
Submit your demo recording to the Sprint 3 assignment on myCourses as a video file or video / file sharing platform link (you can upload a video on YouTube and make it unlisted - nobody without a direct link will be able to find it). Your instructor has access to your Trello workspace, GitHub repository and Slack channel, and will review your work.
Grading Criteria
| Exceptional Performance (100 points) | Competent Performance (88 points) | Acceptable Performance (75 points) | Developing Performance (50 points) | Unacceptable Performance (0 points) | |
|---|---|---|---|---|---|
| Functionality 40% | MVP feature set is bugfree. Enhancements are bugfree and match Product Owner's expectations. | MVP feature set is bugfree. Enhancements have minor issues or do not match Product Owner's expectations. | MVP feature set is bugfree. | MVP feature set has notable bugs. | Little functionality seen in the product. |
| Architecture and Design Principles 10% | Team properly documents and accurately describes at least three design principles exemplified in their design and explains how and where they will/have materialized in their solution across all tiers in great detail. Diagram(s) are clear and work to support the claims. Team includes prior recommendations and clearly describes improvements from previous submission. | Team documents and describes at least three design principles exemplified in their design and explains how and where they will/have materialized in their solution across most tiers. Diagram(s) are clear and work to support the claims. Only a few issues found. Team includes some prior recommendations and identifies some improvements from previous submission. | Team documents and describes design principles in their design and explains how and where they will/have materialized in their solution across some tiers, with minimal detail. Diagram(s) work to support the claims but consistency is lacking. Team did not head prior recommendations or fails to identify improvements. | Team documents and describes minimally the principles in their design and fails to explains how or where they will/have materialized in their solution. Diagram(s) lack evidence to support the claims. There are multiple major issues with adherence to architectural separation and OO design principles. | There is little effort in either the descriptions or evidence diagram(s) to support the design principles. |
| Unit Tests and Code Coverage 10% | Full set of high quality unit tests providing over 90% coverage. | Full set of high quality unit tests providing over 75% coverage. | Unit tests are of high quality with at least 50% coverage, or have some issues with mechanics and provide at least 65% coverage. | Significant unit tests are missing or are of notable poor quality in terms of mechanics. | Unit tests are very low quality either in terms of coverage or mechanics. |
| Code Communication 5% | Code adheres to style guideline; uses good variable, method, and class names; provides Javadocs for methods and classes; appropriate user of helper methods. | Code shows adherence to good code communications practices with only a few issues found. | Adherence to good code communications practices is apparent but consistency is lacking. | There are multiple major issues with adherence to good code communication practices. | Code does not meet most elements of good code communication. |
| Acceptance Test Plan 5% | Complete Acceptance Test Plan showing full suite of acceptance criteria and test results. | Complete Acceptance Test Plan shows full suite of acceptance criteria with only a few issues with test results. | Acceptance Test Plan has been updated with most user stories and acceptance criteria, and shows most test results. | Acceptance Test Plan lacking many user stories, acceptance criteria, or test results. | No evidence of updating of Acceptance Test Plan with user stories, acceptance criteria, and test results. |
| Demo 20% | Team created a polished demo which covered all required features and unique inputs in detail, was easy to follow and showed the program runs without any problems. | Team created a polished demo which was easy to follow but there were a few minor issues noted with the demo. | Team created demo but there were major issues with delivery. | Team did not appear prepared but was able to carry off something of a demo. | Team did not provide demo or created one with minimal results. |
| Planning Activities 5% | Team correctly entered user stories into the sprint backlog and tracked them through to completion. | All team members were involved in planning activities but there were a few minor issues noted. | Only a portion of the team was involved in planning activities, or it was not done consistently. | Only a portion of the team was involved in planning activities, and it was not done consistently. | Minimal evidence of team performing planning activities. |
| Version Control Activities 5% | Full use of version control, feature branches, pull requests, and substantive reviews. | Version control, feature branches, pull requests and reviews used with some breaks in consistency, use across the team, or quality of review comments. | Version control, feature branches, pull requests, and reviews are regularly used but not always in a coordinated manner or review comments are of low quality. | Inconsistent use of version control, feature branching, pull requests, and reviews. | Minimal use of version control, feature branches, pull requests, and reviews. |
Sprint 4
Planning
Identify tasks that you need to complete to finalize your Design Document and prepare your presentation. Do not forget that you need to not only add parts marked as Sprint 4 but also update all previously added parts if needed. Each of the artefacts should be worked on by multiple team members, so you need to split the work into tasks granularly - for example, two tasks "Finish DesignDoc" and "Prepare a presentation" are too large and should be decomposed (e.g., into tasks based on document sections). You do not need user stories, story points, acceptance criteria, definition of done or anything like that for these tasks, but you need to create Trello cards.
Scope
Find the design document in your code repository and update all parts that are marked as Sprint 1, Sprint 2, Sprint 3, and Sprint 4 so the document reflects the current state of your project. Do not forget to address issues revealed during the cross-team design document review. After the document is finished, remove all instructions, and ensure it is well-structured and comprehensive. Do not hesitate to ask your instructor for clarifications if you are unsure about any part.
Compose a final presentation that summarizes your project and the work you have done. Try to highlight unique, interesting and complicated aspects of your project that differentiate it from others. Also, try to highlight and justify architectural and UX choices your made after been given the initial project structure. It should be around 10-15 minutes long (check with your instructor) and cover the following aspects:
- Final domain model.
- Architectural overview of the tiers, layers and any important subsystem within.
- Class and sequence diagrams for key areas of your project.
- Static code analysis highlights (main groups of issues and potential consequences).
- Recommendations for future software architecture improvements.
- Recommendations for future usability improvements.
- (optionally) Any bad decisions, their consequences and changes you had to make.
- (optionally) Any additional insights or reflections.
For the presentation, prefer diagrams over text to better illustrate your points. Try to use several levels of abstraction and multiple diagrams to make them understandable, probably simplify some of them (e.g., by removing irrelevant for a point you are making details like some classes, attributes or methods)
There is no coding in this sprint.
Release
When you create a new release, use vM.P notation (e.g., v1.0, v2.1). M - a major version matching the sprint number, P - a patch version. The initial release for Sprint 4 should be taged as v4.0. If after creating the release but before the deadline you need to make changes (e.g., fixing design document issues), you can create a new release and bump the patch version (e.g., v4.1, v4.2).
- Open the main page of your project repository on GitHub, find the release section on the right side and click on the "Releases" header.
- Click on the "Draft a new release" button.
- Keep "main" as a target and put your release version into the "Tag" field (agree to create a new tag if offered).
- Scroll down and click on the "Publish release" button
Presentation
Conduct a final presentation to showcase your project and the work you have done. All team members have to participate.
When other team is presenting, try to find issues or unclear aspects of their presentation or explanations so you would be able to ask meaningful questions after their presentation is completed.
Recording
In addition to the live presentation, prepare a recording of your presentation before the class. All members have to participate. A recording of a team presentation meeting over Zoom or any other platform is enough. This recording will be used as a backup option by your instructor if they need to recall some aspects of the presentation.
Submission
Submit your presentation recording to the Sprint 4 assignment on myCourses as a video file or video / file sharing platform link (you can upload a video on YouTube and make it unlisted - nobody without a direct link will be able to find it). Your instructor has access to your Trello workspace, GitHub repository and Slack channel, and will review your work.
Grading Criteria
| Exceptional Performance (100 points) | Competent Performance (88 points) | Acceptable Performance (75 points) | Developing Performance (50 points) | Unacceptable Performance (0 points) | |
|---|---|---|---|---|---|
| Design Document | |||||
| Static Code Analysis 20% | There is a thorough analysis of the metric data for measurements that missed target and outlier values. | There is a thorough analysis of the metric data for measurements that missed target values and some evidence of analyzing beyond that. | The analysis of the metric data covered both missed target and outlier values but could have been in more depth. | There is a minimal analysis of the metric data. | The analysis does not go beyond presenting the measurements. |
| Recommendations for Improvement 15% | Complete recommendations for improvements in multiple areas of the software that are based on the metric data, software architecture design and usability principles and other thorough analysis. The above also substantiated with before and after graphics. | Includes recommendations for improvement in some areas of the software that are based on the metric data and other analysis. | Includes recommendations for improvement that could be better connected to the metric data or a more thorough analysis. | The recommendations for improvement are minimal with only some analysis of the metric data or other analysis. | The recommendations for improvement have little analysis of the metric data or other aspects of the design. |
| Design Principles Analysis 15% | Team properly documents and accurately describes at least FOUR design principles exemplified in their design and explains how and where they will/have materialized in their solution across all tiers in great detail including rationale and recommendations within front and back-end. Diagram(s) are clear and work to support the claims. Team includes prior recommendations and clearly describes improvements from previous submission. | Team documents and describes at least FOUR design principles exemplified in their design and explains how and where they will/have materialized in their solution across most tiers with some detail including rationale and recommendations within front and back-end. Diagram(s) are clear and work to support the claims. Only a few issues found. Team includes some prior recommendations and identifies some improvements from previous submission. | Team documents and describes design principles in their design and explains how and where they will/have materialized in their solution across some tiers, with minimal detail on rationale and recommendations within front and back-end. Diagram(s) work to support the claims but consistency is lacking. Team did not head prior recommendations or fails to identify improvements. | Team documents and describes minimally the principles in their design and fails to explains how or where they will/have materialized in their solution. Diagram(s) lack evidence to support the claims or rationale and recommendations within front and back-end. There are multiple major issues with adherence to architectural separation and OO design principles. | Description of current or future use of design principles is missing or evident lack of effort with rationale or recommendations within front and back-end. |
| Final Design Document 25% | Document has been updated, is organized as coherent sections and subsections in a logical sequence and hierarchy with clear transitions and diagrams that follow structure; no notable issues with mechanics. | Document has been updated, is organized as coherent sections and subsections that follow logically in sequence and hierarchy using good diagrams; some issues with mechanics. | Document minimally updated, is mostly organized in a coherent structure follow structure but has notable issues with diagrams; Mechanics may hinder readability in places. | Document has significant issues with aspects of organization, diagrams, structure, or mechanics. | Document has little organization, unreadable diagrams, no coherent structure, and spelling, grammar or other mechanics issues throughout. |
| Presentation | |||||
| Final Presentation 25% | All members participated. Information presented in a logical, interesting sequence which audience can follow. All areas covered at an appropriate level with slides fully supporting speakers with excellent mechanics. | Information presented in a logical, interesting sequence which audience can follow. All areas covered at an appropriate level with slides fully supporting speakers with a few issues with mechanics. | Some of the information seems out of sequence or disconnected. Some information is missing from presentation. The mechanics limited the presentation quality. | Audience has difficulty following presentation because it jumps around, is missing major elements, or had significant issues with mechanics. | The presentation had little organization, was delivered poorly, and provided little information about the design. |