1. COMP4710 Senior Design Process Documentation and Deliverables

2. Outline Timeline Timeline Administrative Deliverables Administrative Deliverables Development 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. 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 3 Deliverables Spike Presentation (7min) Spike Overview Technical Challenges Design description Product Demonstration Written Report Peer Evaluations Week 1Week 2Week 3Week 4 Weeks 5-8Weeks 9-12Weeks 13-16 Architectural Spike

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

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

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

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

8. Administrative Deliverables – Product Presentations The Product Presentations are limited to 7 minutes and should cover the following; The Product Presentations are limited to 7 minutes and should cover the following; Cycle Progress – measure in terms of User Stories. Cycle Progress – measure in terms of User Stories. Design Discussion – highlight a few interesting aspects. Design Discussion – highlight a few interesting aspects. Process Discussion – highlight any unique experiences. Process Discussion – highlight any unique experiences. Lessons Learned – highlight the key lessons learned. Lessons Learned – highlight the key lessons learned. Future Plans – propose the work for the next cycle. Future Plans – propose the work for the next cycle. Submission requirements; Submission requirements; Bring 3 hardcopies to your presentation Bring 3 hardcopies to your presentation Include hardcopy in Cycle Binder Include hardcopy in Cycle Binder Include softcopy on Cycle CD 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; 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. User Story LoE, planned start and end dates. Team member assignments. Team member assignments. Planned Code Freeze date. Planned Code Freeze date. Any other key dates. Any other key dates. Submission requirements; Submission requirements; Submitted with 2 nd week’s Status Report and each Status Report thereafter. Submitted with 2 nd week’s Status Report and each Status Report thereafter. Include hardcopy in Cycle Binder Include hardcopy in Cycle Binder Include softcopy on Cycle CD 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. The Status Report is a weekly mechanism to indicate to the customers the team’s progress. 4710_Template__StatusReport.xls 4710_Template__StatusReport.xls 4710_Template__StatusReport.xls Submission requirements; Submission requirements; Submitted via email by 5pm on Monday of each week of the cycles. Submitted via email by 5pm on Monday of each week of the cycles. Include hardcopies in Cycle Binder Include hardcopies in Cycle Binder Include softcopies on Cycle CD Include softcopies on Cycle CD

11. Administrative Deliverables – Peer Evaluations Peer Evaluations are a critical evaluation of your team members done in confidence. Peer Evaluations are a critical evaluation of your team members done in confidence. 4710_Template___Peer_Evaluation.xls 4710_Template___Peer_Evaluation.xls 4710_Template___Peer_Evaluation.xls Submission requirements; Submission requirements; Submit on paper at the time of your group’s presentation. 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; Memoranda are any records of project related correspondence, this includes; Emails – any project related email Emails – any project related email Chat Logs – relevant IM conversations 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. 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; Submission requirements; Include hardcopies in Cycle Binder Include hardcopies in Cycle Binder Include softcopies on Cycle CD Include softcopies on Cycle CD

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

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

15. Development Deliverables – System Metaphor The System Metaphor is the team’s mission statement and focus of the team. The System Metaphor is the team’s mission statement and focus of the team. Should clearly and briefly describe the project to an outsider Should clearly and briefly describe the project to an outsider Submission Requirements; Submission Requirements; Submitted with the first Status Report of each cycle. Submitted with the first Status Report of each cycle. Same submission requirements as Status Report. 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. 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; Submission Requirements; Submitted with first Status Report of each cycle. Submitted with first Status Report of each cycle. Same submission requirements as Status Report. 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 User Story is a description of a feature written in the Customer’s vernacular. A form of requirements specification A form of requirements specification Used to create time estimates and development plans Used to create time estimates and development plans A User Story document should contain the following; A User Story document should contain the following; Name Name Summary: brief sentence description of the feature. Summary: brief sentence description of the feature. Description: Full explanation of the feature in the customer’s vernacular 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 Planned hours, actual hours, coder name(s), tester name(s), reviewers names, story status Submission Requirements; Submission Requirements; Name & summarized description included on each Status Report. Name & summarized description included on each Status Report. Include hardcopies in Cycle Binder Include hardcopies in Cycle Binder Include softcopies on Cycle CD Include softcopies on Cycle CD

18. Development Deliverables – User Stories User Story Example; 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 User Story Example, continued Planned hours: 20 Planned hours: 20 Planned hours this cycle: 20 Planned hours this cycle: 20 Actual hours, total 30 Actual hours, total 30 Hours this cycle: 30 Hours this cycle: 30 Coder: Susan H., Joe W. Coder: Susan H., Joe W. Tester: Bill S. Tester: Bill S. Reviewer: entire team Reviewer: entire team Status: collaborative development 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. 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. 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. 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. 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. 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. Don’t rewrite the BREW, J2ME, Symbian, etc. manual -- describe the code you wrote. Submission Requirements; Submission Requirements; Include hardcopies in Cycle Binder Include hardcopies in Cycle Binder Include softcopies on Cycle CD 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 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; The test documentation should contain the following; Acceptance Tests (each User Story must have at least one) 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. User Story name, Test name/ID, Test description, Required programs/files, Sequence of steps required to conduct the test. Unit Tests 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) 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 Test Logs User Story name, Test name/ID, Tester, Test date, Test Result, Comments User Story name, Test name/ID, Tester, Test date, Test Result, Comments Submission Requirements; Submission Requirements; Include hardcopies in Cycle Binder Include hardcopies in Cycle Binder Include softcopies on Cycle CD Include softcopies on Cycle CD

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