COMP4710 Senior Design

1. COMP4710Senior Design Process Documentation and Deliverables

2. Outline • Timeline • Administrative Deliverables • Development Deliverables

3. The Senior Design Process • The SDP is broken up into four 3-to-4-week iterations beginning with the Architectural Spike. The goal of this iteration is to develop an as complete as possible version of the final product. Week 1 Week 2 Week 3 Week 4 Weeks 5-8 Weeks 9-12 Weeks 13-16 Architectural Spike Week 3 Deliverables • Spike Presentation (7min) • Spike Overview • Technical Challenges • Design description • Product Demonstration • Written Report • Peer Evaluations

4. The Senior Design Process • Cycle 1 – The goal of this cycle is to implement the core features that make the product minimally viable. Weeks 1-3 Week 4 Week 5 Week 6 Week 7 Weeks 8-11 Weeks 12-15 Cycle 1 Weeks 5&6 Deliverables Week 7 Deliverables Week 4 Deliverables • Status Report • Management Plan • Projected Code Freeze • Product Presentation (7min) • Product Demonstration • Cycle 1 Binder • Peer Evaluations • System Metaphor • User Stories • Cycle Intent • Status Report

5. The Senior Design Process • Cycle 2 – The goal of this cycle is to extend the core product. Weeks 1-3 Weeks 4-7 Week 8 Week 9 Week 10 Week 11 Weeks 12-15 Cycle 2 Weeks 9&10 Deliverables Week 8 Deliverables Week 11 Deliverables • Status Report • Management Plan • Projected Code Freeze • User Stories • Cycle Intent • Status Report • Product Presentation (7min) • Product Demonstration • Cycle 2 Binder • Peer Evaluations

6. The Senior Design Process • Cycle 3 – The goal of this cycle is to improve the product. Weeks 1-3 Weeks 4-7 Weeks 8-11 Week 12 Week 13 Week 14 Week 15 End Cycle 3 Weeks 13&14 Deliverables Week 12 Deliverables Week 15 Deliverables • Status Report • Management Plan • Projected Code Freeze • User Stories • Cycle Intent • Status Report • Product Presentation (7min) • Product Demonstration • Cycle 3 Binder • Peer Evaluations

7. Administrative Deliverables • Product Presentations (hardcopy & binder) • Management Plan (weekly & binder) • Status Reports (weekly & binder) • Peer Evaluations (email) • Memoranda (binder) • Lessons Learned (binder)

8. Administrative Deliverables – Product Presentations • The Product Presentations are limited to 7 minutes and should cover the following; • Cycle Progress – measure in terms of User Stories. • Design Discussion – highlight a few interesting aspects. • Process Discussion – highlight any unique experiences. • Lessons Learned – highlight the key lessons learned. • Future Plans – propose the work for the next cycle. • Submission requirements; • Bring 3 hardcopies to your presentation • Include hardcopy in Cycle Binder • Include softcopy on Cycle CD

9. Administrative Deliverables – Management Plan • The Management Plan is a high-level schedule indicating tasks and task assignments. It should include the following; • User Story LoE, planned start and end dates. • Team member assignments. • Planned Code Freeze date. • Any other key dates. • Submission requirements; • Submitted with 2nd week’s Status Report and each Status Report thereafter. • Include hardcopy in Cycle Binder • Include softcopy on Cycle CD

10. Administrative Deliverables – Status Reports • The Status Report is a weekly mechanism to indicate to the customers the team’s progress. • 4710_Template__StatusReport.xls • Submission requirements; • Submitted via email by 5pm on Monday of each week of the cycles. • Include hardcopies in Cycle Binder • Include softcopies on Cycle CD

11. Administrative Deliverables – Peer Evaluations • Peer Evaluations are a critical evaluation of your team members done in confidence. • 4710_Template___Peer_Evaluation.xls • Submission requirements; • Submit on paper at the time of your group’s presentation.

12. Administrative Deliverables – Memoranda • Memoranda are any records of project related correspondence, this includes; • Emails – any project related email • Chat Logs – relevant IM conversations • Meeting Minutes – this is written documentation of any regular team meetings. Meeting attendance, meeting agenda, main topics of discussion, action items/task assignments, and meeting date should, at a minimum, be included. • Submission requirements; • Include hardcopies in Cycle Binder • Include softcopies on Cycle CD

13. Administrative Deliverables – Lessons Learned • Lessons Learned are knowledge gained from a post-effort critical evaluation. • Good lessons learned answer the following questions; • What were our major successes and the factors that contributed to them? • What were our key failures and the factors that contributed to them? • Submission requirements; • Highlighted in Product Presentation • Include hardcopies in Cycle Binder • Include softcopies on Cycle CD

14. Development Deliverables • System Metaphor (weekly) • Cycle Intent (weekly) • User Stories (summarized weekly & binder) • Design Documentation (binder) • Test Documentation (binder) • Source Code (binder) • Version Description (binder)

15. Development Deliverables – System Metaphor • The System Metaphor is the team’s mission statement and focus of the team. • Should clearly and briefly describe the project to an outsider • Submission Requirements; • Submitted with the first Status Report of each cycle. • Same submission requirements as Status Report.

16. Development Deliverables – Cycle Intent • The Cycle Intent is a description of the envisioned product at the end of the cycle. • It should capture the rationale for the particular set of features to be implemented in the cycle’s product • NOT a list of the features that will be in the product • Should expand on and fit with the system metaphor • Submission Requirements; • Submitted with first Status Report of each cycle. • Same submission requirements as Status Report.

17. Development Deliverables – User Stories • A User Story is a description of a feature written in the Customer’s vernacular. • A form of requirements specification • Used to create time estimates and development plans • A User Story document should contain the following; • Name • Summary: brief sentence description of the feature. • Description: Full explanation of the feature in the customer’s vernacular • Planned hours, actual hours, coder name(s), tester name(s), reviewers names, story status • Submission Requirements; • Name & summarized description included on each Status Report. • Include hardcopies in Cycle Binder • Include softcopies on Cycle CD

18. Development Deliverables – User Stories • User Story Example; Name: Off-Screen Ghost Markers Summary: A marker system to indicate to the user the location and velocity of any ghosts that do not fit on the screen Description: The phone screen is much smaller than the arcade game screen. To preserve the character of the original game, the large playing area is needed, which means only a fraction can be displayed at any time. The player must have some awareness of where each ghost is on the playfield as well as whether the ghost is in “kill” or “run away” mode. The screen real estate available to the application should not decrease as result of the marker system. [and more, omitted in interest of brevity]

19. Development Deliverables – User Stories • User Story Example, continued • Planned hours: 20 • Planned hours this cycle: 20 • Actual hours, total 30 • Hours this cycle: 30 • Coder: Susan H., Joe W. • Tester: Bill S. • Reviewer: entire team • Status: collaborative development

20. Development Deliverables – Design Documentation • The design document tells how your product works, what decisions you made, why you made them. It should give a follow-on team or a new team member who comes in mid-cycle what they need to know to start working on the project. • Architecture – What is the overall picture of how your application works. Diagrams can be helpful here (e.g. UML), but prose description is essential. • Structure – How do the pieces of code you have written interact with each other and with any framework code or libraries. Use prose, not just lists or pictures. • Interfaces -- any interfaces to or interactions with other components in the application. Define these in detail, describing parameters, data rates, protocols, global shared variables any other important features. • Assumptions & Dependencies – any assumptions made about or dependencies on other features or elements of the application. • Don’t rewrite the BREW, J2ME, Symbian, etc. manual -- describe the code you wrote. • Submission Requirements; • Include hardcopies in Cycle Binder • Include softcopies on Cycle CD

21. Development Deliverables – Test Documentation • The test documentation is a description of the steps used to test a feature and logs of when these tests were conducted. • The test documentation should contain the following; • Acceptance Tests (each User Story must have at least one) • User Story name, Test name/ID, Test description, Required programs/files, Sequence of steps required to conduct the test. • Unit Tests • User Story name, Test name/ID, Test description, Required programs/files, Sequence of steps required to conduct the test (manual) -or- Unit test code and test harness. (automated) • Test Logs • User Story name, Test name/ID, Tester, Test date, Test Result, Comments • Submission Requirements; • Include hardcopies in Cycle Binder • Include softcopies on Cycle CD

22. Development Deliverables – Version Description • A Version Description is the “README” for the delivered product. • A Version Description should contain the following; • Version number • Description of the application • Key features • Known bugs/issues • Submission Requirements; • Include hardcopies in Cycle Binder • Include softcopies on Cycle CD