1. ® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 4: Phase Management - Elaboration

2. 4-2 Module 4 Objectives As a project progresses through phases and iterations, describe the changing emphasis of Project Management by:  Understanding Elaboration objectives, milestones, and evaluation criteria.  Understanding principal Elaboration activities and artifacts, and their uses.  Understanding the risk-reduction focus.  Understanding how change is managed by the team.

3. 4-3 Elaboration Primary Objectives:  Baselining the architecture as rapidly as practical  Baselining the vision  Baselining a plan for the Construction phase with the increased accuracy made possible by removing the highest risks  Demonstrating that the baseline architecture will support the vision at a reasonable cost in a reasonable time frame Essential Activities:  Refining the vision  Refining the process and infrastructure  Refining the architecture and selecting components

4. 4-4 Elaboration Considerations Phase Focus  Architecture tested  Architecture baselined  Architectural risk mitigated  Product requirements refined

5. 4-5 Elaboration Considerations Measurements  Progress25%  Expenditures (rate)Moderate  StaffingRamp up  StabilityModerate  Modularity25%-50%  AdaptabilityVarying  MaturityFragile

6. 4-6 Elaboration Essential Artifacts  Prototypes  Risk List  Development Process  Development Infrastructure  Software Architecture Document  Design Model (and all constituent artifacts)  Data Model  Implementation Model (and all constituent artifacts, including Implementation Elements)  Vision  Software Development Plan  Iteration Plan  Use-Case Model (Actors, Use Cases)  Supplementary Specifications  Test Suite ("smoke test")  Test Automation Architecture

7. 4-7 Elaboration is Risk Driven  Update the Risk List  Risk mitigation drives iterations in the Elaboration phase

8. 4-8 Primary Requirements Artifacts  Features: services that support user needs  Main audience: stakeholders and project team  Documented in the Vision artifact  Functional Requirements: specifying interactions with system users  Main audience: users and project team  Modeled in the Use-Case Model artifact  Supplementary Requirements: specifying functionality, usability, reliability, performance, supportability requirements, and design constraints  Main audience: architects and designers  Documented in the Supplementary Specifications artifact

9. 4-9 Requirements Affect Architecture  Supplementary requirements strongly influence the architecture.  Functional requirements (use cases) are implemented to validate the architecture.  During Elaboration, selected use cases (or parts of use cases) are implemented to exercise the architecture being baselined.

10. 4-10 Example of a Use-Case Model A University Course Registration System Professor Select Courses to Teach StudentCourse Catalog Register for Courses Maintain Student Information Maintain Professor Information Registrar Billing System Close Registration

11. 4-11 Use Cases as a Basis for Iteration Planning Iteration Plan Fine-grained plan for a single iteration Use-Case Model Supplementary Specifications Project Planning (Project Manager / Architect) Constraints During Elaboration, use cases are implemented to validate the architecture.

12. 4-12 Artifact Baselining Baselined artifact: A reviewed and approved release of an artifact that constitutes an agreed basis for further evolution or development  The artifact can only be changed through a formal procedure, such as change management and configuration control.  The natural timing for updating a previously-baselined artifact is at the end of an iteration.

13. 4-13 Changing a Baselined Artifact Change Acceptance by CCB CCB Composition: Executive Manager Marketing/User Manager Project Manager Architect System Analyst Change Product Requirements Change Product Architecture/Design Postponed Change Request Rejected Change Request Approved Change Request Record for Next Product Release Proposed Arch/Design Change Request Incorporate Changes into Baselines Plan Next Iteration using New Baseline Proposed Requirements Change Request

14. 4-14 Discussion: Change Control Board  What are characteristics of a successful CCB?

15. 4-15 RUP Distribution of Skills by Phase Management Environment/CM Requirements Design Implementation Assessment Deployment Total Percentage of effort by activity for the Elaboration phase. Elaboration % 12 8 18 36 13 10 3 100

16. 4-16 Elaboration Evaluation Criteria  Is the vision stable?  Is the architecture stable?  Does the executable demonstration show that the major risk elements have been addressed and credibly resolved?  Is the Construction phase plan of sufficient fidelity, and is it backed up with a credible basis of estimates?  Do all stakeholders agree that the current vision can be met if the current plan is executed to develop the complete system in the context of the current architecture?

17. 4-17 Elaboration Phase Management Issues  Using the same person as the PM and the Architect  Putting your head in the sand

18. 4-18 Elaboration Phase Recommendations  Don’t aim for a perfect solution since this is an engineering problem.  Look for the 80% solution that satisfies competing technical, social, and economic forces.  With an iterative approach, the entire development environment must be in place for the first release.  The project cannot defer finalizing CM and test policies and tools until later in the project.

19. 4-19 Exercise: Collegiate Sports Case Study Refer to the Exercises section of your workbook and complete: Exercise 4: Risk Mitigation Exercise 4: Risk Mitigation

20. 4-20 Module 4 Review  The main objective of Elaboration is to achieve a stable vision and architecture.  Elaboration is risk-driven.  Important Elaboration artifacts include:  Risk List  Software Development Plan  Iteration Plan/Assessment