Final Project Requirements
Important Dates and Deadlines
| Item | Date |
|---|---|
| Pitching party | Friday, 23 February 2024 |
| Potential teams + project idea | Sunday, 3 March 2024 |
| Project proposal | Sunday, 10 March 2024 |
| Teams formed | Sunday, 10 March 2024 |
| Sprint 1 | Sunday, 24 March 2024 |
| Sprint 2 | Sunday, 7 April 2024 |
| STePS | Wednesday, 17 April 2024 |
| Final project report | Sunday, 21 April 2024 |
| Final project presentations | Monday, 22 April 2024 to Friday, 26 April 2024 |
Final Project Proposal
The proposal should be about 6 to 8 pages (maximum of 10) in length and address (at least) the following points:
-
Overview of the application you plan to develop.
-
Are there any existing applications out there that are similar?
-
What makes your application special? Why did you choose your application?
-
List of features. This list should include not only the features to be developed during the course, but also features that are "good-to-have" bells and whistles.
-
Project schedule: should be aligned to three agile sprints each lasting two weeks.
-
Mock-ups of some of the interfaces for the application should also be included if possible to help to explain how the application works.
-
High-level design (e.g. modules, application logic flow). This design is not expected to be too detailed, but it should be of sufficient detail to provide the teaching staff with an idea of how the development work will be divided among the team members.
-
Individual contribution and roles. Contributions and/or support from external partners, if any.
Note that the list of features should be specified clearly and include roughly some 50% more "good-to-have" features that are not within the implementation plan. The idea is to have a good list of features to discuss the deliverables during the first meeting.
Please submit the proposal in PDF format by Sunday, 10 March 2024. This is a hard deadline. No extensions will be given.
Final Project Specifications
Once the Final Project proposals are submitted, they will be open to all students. By default, we will assume that students will be working on the projects they proposed, but it is perfectly acceptable at this stage for a team to decide to implement the application that was proposed by another team. This ensures that no team is disadvantaged by the choice of project that they made - since they could have decided to work on another project. It is also possible for the students to change teams at this stage, but the teams should be finalized latest by the team formation deadline. Unless informed by this deadline, the teaching staff will assume that all students will stay with their project proposal teams.
Once the Final Project proposals are received, the teaching staff will convene a meeting to evaluate the proposals and formulate a set of final specifications for each project. Basically, the goal here is to moderate the projects to try to ensure that all the teams will do roughly the same amount of work. The general idea is that we will specify the set of functionality that have to be implemented correctly and well by the end of the project for the project to be considered an A-grade project.
If the project team is not able to satisfy this requirement, they will be awarded a lower grade. The teaching staff will meet with each team separately in the 8th week. The goal of this meeting is to communicate the required specifications for the project to the students.
Development of Final Project
The deliverables of each sprint cycle should be discussed and determined during the previous meeting with the teaching staff. The deliverables should be a complete working feature in itself. It may not be a complete component but it must be 100% working. e.g. If user login is one of the deliverables, then user login must be 100% implemented and working. But there need not be user logout if that is not part of the sprint deliverable.
At the end of each sprint, the team will be required to submit a report and arrange for a presentation meeting with the teaching staff. The meeting should take no longer than an hour and are compulsory sessions where the schedule is flexible and should be determined by both parties.
While the team leader may present the overall organisation of the project and application, each individual member is expected to present their own contributions and code.
Change of Specifications
The teams should expect to receive new specifications or changes to the initial specifications during the meetings. This simulates the vagaries of "real world" software development, i.e. the client doesn't really know what he/she wants. To some extent, these change requests would be a test of the flexibility in the software architecture chosen by the students.
If the application was well-designed, it should not be too difficult to incorporate these changes. But if the application design was not done properly, these changes could be very painful and cause a lot of problems and bugs.
STePS
CS3217 will be participating in STePS. Each team is to prepare an A1-sized poster for their booth. The judges and other members of the SoC and NUS will turn up for the "show and tell." Again, you can choose how you want to present your work. Minimally, you should bring along your iPads to demo your work!
Final Project Poster
The final A1-sized project poster should (at least) include the following points:
-
Description of the application you have developed.
-
What makes your application special?
-
Screenshots, graphics, diagrams and tables. Probably fewer words.
-
Prepare a snappy yet catchy 1-2 minute pitch that you can use (over and over) when presenting your poster.
Remember, avoid overloading the poster with too much (small) text. This will ensure that people won't want to read what is on your poster. Add in pictures, graphics, diagrams and tables when appropriate. You are there to "sell" people your idea, to make them convinced that your application is unique and creative, and NOT to put them to sleep.
Final Project Report and Presentation
The requirements for this report are specified in the document Documenting a Software System.
The Final Project Presentation will be held during the reading week. By then, the teaching staff should have a good understanding of your application through the sprint meetings. An extra component is given to a reflective presentation on Software Engineering Principles learnt during the course of the project.
Outline for Sprint Reports
An outline of the requirements for the sprint reports is given in Sprint Report. The descriptions in the document assume that your group has decided to build a pinball game called Gizmoball. This document should be viewed as a work-in-progress version of the final project report. Students should also refer to Documenting a Software System.