The purpose of this milestone is to evaluate your understanding of the design (the "blueprints" of what you are building) and the set of tasks remaining to finish the implementation and verify that it fulfills the requirements.
It is expected that you have coded most of your system and that the code conforms to design.
Design documentation should act as a bridge between business requirements and the technical details of the implementation. Try to avoid duplicating what is better stated in source code. This should be a road map to the details of the source code, which focuses on emphasizing the essential and critical decisions and mechanisms. Leave the details to the source code. In fact, when low level details need to be conveyed in design documentation, it is best to use source code snippets or examples to make them clear.
Architecture Page (additional documentation)
There should be a simple UML package diagram (or similar) that identifies the significant components of your system and the dependencies between them. Often an annotated screen shot of your source code folder hierarchy will suffice. Their purpose and functionality of the most significant components and interfaces should be explained succinctly in a sentence or two.
The most significant interfaces to components should be documented by an API description that clearly explains which API calls should be used and how for this project. It is acceptable and encouraged, to document this by simply copying the source code “headers” for the most important API calls (including comments and signature) from source code.
You may also find it useful to use class diagrams to document the application model for your project and its relationship to interface (view), session (controller) and persistence (model) components.
Critical Scenarios and Key Mechanisms Page (additional documentation)
Interaction diagrams should be used to document how your system implements your critical scenarios (functional requirements) The intent here is NOT to diagram every step and functional call in your system. The intent is to show how the different components and layers of your system distribute and coordinate the desired behavior. Only critical components, object and API calls should be mentioned.
Key mechanisms (like error handling, or persistence) should be documented as well. This could be done using interaction diagrams but often a well-document code example is more effective. This will serve as a template for developers to follow throughout the system.
Quality Assurance Page (new)
There should be a list of fully verified releases (planned and completed). There should be at least one completed release. Each completed release will have a formal QA Report. The report should provide a brief description of the release that was tested and summarize the current status of the different types of testing you are doing in a table. For each type of test, indicate how many tests are planned, how many have been implemented (i.e. can you run the test), and how many tests passed. You should also summarize the status of bugs for that release in a table. How many found, what severity, and how many fixed and total number of remaining bugs.
Update algorithms, databases and file formats as needed.
Actor and Use Cases, Development Environment, System Demo Pages
Update as appropriate
Risks, Project Plan
Update as appropriate (issues, boards, pages …)