1. Completing and Presenting the Class Project
Chapter 12
Completing and Presenting the Class Project

2. Succeeding with the Project
As emphasized throughout the text, software development is inherently risky
If your software development team is unable to complete the project as initially outlined, it is important to:
determine what elements of the project can be completed
analyze what might have been done differently to increase the level of success

3. Aspects for Assessing Risk
Unfamiliarity
Abstractness
Incompleteness
Complexity
Error
Poorly structured solution

4. Assessing Importance to Project
Identify risk
Link risky elements to analysis and design documents to determine associated functionality
Determine how much your other teammates depend on this functionality to accomplish their tasks
Prioritize the functionality at risk for not being completed
Review and discuss the at risk functionality
Determine new priorities for each development team member
If time permits, address previously skipped functionality

5. Reflecting on the Project
Did lack of appreciation of the true complexity of certain aspects of the functionality of the system cause problems for you?
Were new areas of functionality needed after analysis or design had been completed?
Were additional human-computer interfaces required after product design was complete?
Was the flow of control between human-computer interfaces problematic or awkward?
Was object persistence more problematic than anticipated?

6. Reflecting on the Project
Was inter-process communication insufficient to support the full functionality of the system?
Was the process architecture inefficient?
Did your system require a significant number of methods and/or classes beyond what was provided for during design?
Were methods more complex than the algorithms specified during design?
Did classes require a significant number of additional attributes from the original design?

7. Reflecting on the Project
Did originally designated container classes need to be modified during implementation?
Did elements of the system require restructuring after the design phase?
Did unit testing take additional time because the design had to be altered?
Did integration testing require additional time because the inter-class interfaces were inconsistent or inadequate?
Did integration testing require additional time because unit testing was not sufficiently thorough?
Did system testing reveal errors not caught during integration or unit testing?

8. The Project Presentation
Should be a technical presentation
Should Address the needs of a sole user
Should be structured around use cases
Should illustrate the underlying class structure that supports each area of functionality
Should highlight challenging algorithms, code reuse, and interprocess communication mechanisms

9. Now its your turn!