Stage 2 planning
A big advantage of Staged Delivery model is natural break that occurs
after each release.
- Consider all submitted change requests and "wish list" items.
- Customer may have changed priorities for Stage 2 features.
- Designers can do refactorings without disrupting development.
- Processes can be revised or streamlined.
Midterm
Retrospective in lab today. Post report on wiki by Monday 9:00.
What's new for Release 2?
Maintenance Release (1.1). Extra credit for Spring 2009 (2%).
Deployment (1.0 and 1.1 wiki links to production
site).
Repository (trunk for 2.0 development and branch for
1.1 development).
Stage Delivery Plan (add section for 1.1 fixes)
Due May 15 in lab.
Formal Inspections
Read the process for Monday. Watch video
in class Monday.
Estimate 1-2 hrs prep * 4 developers / 200
LOC.
Estimate 1 hr inspection meeting and admin followup.
White Box Test Documentation
Derive white box unit tests using Basis Path
technique for one class, ideally a controller.
Class to be tested can be from release 1 or 2.
Submit all worksheets and JUnit test cases at
release.
Estimate: 1 hr / 50 LOC.
Next Steps
Draft high level design
Use Stage 2 features list from Staged
Delivery Plan.
Consider JCharts or other free Java
charting tool for grading data display.
Identify needed classes and methods.
Estimate size (LOC) based on previous
modules from Stage 1.
Budget Recalibration
We now have data from Stage 1.
Actual hours worked,
hopefully categorized.
LOC produced. GUI,
non-GUI, HTML.
Number of defects.
We now have better understanding of all
the tasks required for a release.
Training time.
Process planning and
tracking.
Writing good tests.
Do the Estimation
Process.
Results - List of features whose size
fits our LOC capability.
-
Revised Stage 2 Delivery Plan ready for customer/instructor approval by
end of Mon lab.
-
Detailed Schedule posted by end of Monday lab.
Follow the development process from Project Plan.
Write javadocs for Stage 2 modules.
Write psuedocode for every method in
Stage 2.
etc, etc.