• Initiation
• Requirements Complete
• Commit
• Functionality Complete
• QA Complete / Release

• Project Data Sheet
• Project Plan
• External Specification
• User Requirements
• Internal Specification
• Quality Plan
• Configuration Management Plan
• Memorandum of Understanding
• Official Process Image

This milestone marks the point at which all code is written, all user interfaces are working and documented (in the external specification), and the product has been broadly (as opposed to deeply) tested stand-alone and with “interacting partners” as described in the project plan.  Versions of on-line deliverables for this milestone which are under source control are tagged with an appropriate tag. This checkpoint document is derived from the Life Cycle Document. 
 

Questions:

 

Questions	OK	Issue
How have the outstanding issues or exception items from the previous phase been resolved?
Have any requirements or specifications changed since Project Commit?
Are all functions of the product coded and functional?
Are the QA criteria clearly defined for all aspects of FLURPS?
Are project plans in place for inspections and tests for all aspects of FLURPS for the project?
Where there will be early releases/availability? Are alpha- and beta-testplans in place? What learning products are available to support these? What is the support plan for them? Is there a plan to incorporate feed back from alpha- and beta-sites?
What is the plan to complete the next phase? Are all critical processesfor QA phase in place? How will we track progress toward our QA release criteria? Are the appropriate staffand equipment available to work on the QA phase? Is all necessary training available and planned?
Have all the deliverables for this milestone been reviewed by the appropriate stakeholders?
What is the plan for the phase retrospective?
Do the project manager, project team, and stakeholders feel that the product is functionally complete and ready for test?

 

Deliverables:

 

Deliverable Description	Required	Done
Completed Code (functional, but not fully tested)
GUI portion of External Specification
Inspection results of Critical/High-Risk Code
Unit-Test Code Design
Quality Plan updated, including complete description of quality metrics and tracking plans.
Alpha & Beta Test Plans
Critical processes in place: testing, defect reporting, integration
Plans for reaching next milestone Updated schedule staffing plans

 

Issues:

These issues should be generated for the various checkpoints and the ongoing set should accumulated in the project plan.
 

Issue	Owner	Resolution
Roses are red, violets are blue, you don't have enough people to make it through.	Buzz Lightyear	Pending.
Grinches are green, Santas are red, if you don't get this done, you'll get shot with lead..	Buzz Lightyear	yyyy/mm/dd: Resolution comments.

 

Approvals:

The approval process is that the people responsible for approving the checkpoint will be informed by email that they should review the materials on the web.  After a timely review, they will mail their approval, with any issues to the project owner.  The issues will be added to the formal issues list.  The reviewer should also specify explicitly whether the checkpoint is approved or disapproved and why.  The owner will, when all approvals have been received, send an email notification.
 

Approvals	Required	By	Approved
Authorizing manager: name  (R&D section manager, lab manager, organization manager).	Yes	Email	date
Stakeholder: name  (project team members - if appropriate).	Optional	Verbal	date
Partner: name (internal customer - if appropriate).	Optional	Email	date
Other: name	Optional	Signature	date