1. PRJ480 Mastering the Management of Iterative Development v2
Mastering the Management of Iterative Development v2 Instructor Notes
PRJ480 Mastering the Management of Iterative Development v2
Module 2: Iterative Project Management
Module 2 - Iterative Project Management

2. Mastering the Management of Iterative Development v2 Instructor Notes
Module 2 Objectives
Understand issues for Project Managers (PM) who use iterative development by:
Learning how the PM monitors and steers an iterative project towards success.
Understanding the importance of the following in iterative development:
Confronting risk early.
Using an architecture-first approach.
Using objective quality control and progress assessment.
Learning the importance of the principal artifacts used by PM.
Understanding how team responsibilities change.
Module 2 - Iterative Project Management

3. Mastering the Management of Iterative Development v2 Instructor Notes
Team Leadership
The following are the main elements of team leadership:
The team framework: putting in place the appropriate roles, staff assignments, tools, and processes
The big picture: seeing that the effort continues to meet the business needs, and that it has the correct contents, schedule, and budget
Team dynamics: making sure that the project team and individuals are communicating effectively
See [Cantor 02] p. 131 for additional details.
The role of manager is one of the various team roles. However, it is special in a few ways:
The manager looks after the project as a whole, the large-scale structure of the effort. It follows that the manager cannot be involved with the details; detail work must the assigned to developers.
The manager treats the project as a dynamic system, using influence to provide the necessary steering.
Module 2 - Iterative Project Management

4. Review: Project Navigation
Mastering the Management of Iterative Development v2 Instructor Notes
Review: Project Navigation
Business-Oriented Goals Achieved
START
I-end
E-end
T-end
C-end
I = Inception phase
E = Elaboration phase
C = Construction phase
T = Transition phase
Technically-Oriented Goals Achieved
Module 2 - Iterative Project Management

5. Coarse-Grained Versus Fine-Grained Plans
Mastering the Management of Iterative Development v2 Instructor Notes
Coarse-Grained Versus Fine-Grained Plans
Project Plan
Phase Plan
Iteration Plan (current)
Phases and major milestones
What and when
Iterations for each phase
Number of iterations
Objectives
Duration
Work Breakdown Structure
The Project Plan, Phase Plan, and Iteration Plan are all components of the Software Development Plan artifact, which is a major artifact in the Project Management discipline.
The Project Plan captures the overall envelope of the project, for one cycle (and maybe the following cycles, if appropriate). The Project Plan is produced very early in the Inception phase and updated as often as necessary.
The Phase Plan is included in the Project Plan and includes the following:
Work Breakdown Structure (WBS)
A timeline or Gantt chart showing the allocation of time to the project phases or iterations
Identification of major milestones with their achievement criteria
Definition of any important release points and demos
The Iteration Plan is a time-sequenced set of activities and tasks, with assigned resources, containing task dependencies, for the iteration. It is a fine-grained plan, and there is one per iteration. A project usually has two iteration plans active at any given point:
The current iteration plan (that is, for the current iteration), which is used to track progress.
The next iteration plan (that is, for the upcoming iteration), which is built toward the second half of the current iteration and is ready at the end of the current iteration.
Iteration Plan (next)
Roadmap
Coarse-grained
Plan
Fine-grained Plans
Module 2 - Iterative Project Management

6. Work Breakdown Structure Issues
Mastering the Management of Iterative Development v2 Instructor Notes
Work Breakdown Structure Issues
Common Flaws
Solutions
Prematurely structured around product design
Organize around the process
Prematurely broken down into too much or too little detail
Evolve detail over time
Structured in a project-specific way that impedes cross-project comparisons
Remain consistent in form across enterprise
A Work Breakdown Structure (WBS) decomposes the Project Plan into tasks.
It provides the following structure:
Delineation of significant work
Task decomposition for assignment of responsibilities
A framework for scheduling, budgeting, and tracking
Module 2 - Iterative Project Management

7. Review: RUP Effort and Time Distribution by Phase
Mastering the Management of Iterative Development v2 Instructor Notes
Review: RUP Effort and Time Distribution by Phase
Inception
Elaboration
Construction
Transition
Effort 5%
20%
65%
10%
Time/Schedule
30%
50%
See [Boehm 00] p. 324 for more information.
This distribution is typical for new software projects
Module 2 - Iterative Project Management

8. Iteration Assessment and Steering
Mastering the Management of Iterative Development v2 Instructor Notes
Iteration Assessment and Steering
Start Iteration Using
Artifact: Iteration Assessment
Iteration Plan
Complete Planned
Iteration Work
Assess
Reduce risk
Accept change
Steer project
Iteration
Stop
Continue
Project Stopped
Adjust
Adjust Target
Objectives
Product
Notice that sometimes adjustments are not needed.
After an iteration starts, the teams complete the work specified in the Iteration Plan.
When the work is completed, the Iteration Assessment is performed to determine if and how the iteration goals were achieved. This is done using as many objective measures as possible. A determination is made to continue with the project or to stop it based on the assessment.
If you decide to continue, you have to analyze Change Control Board (CCB)-approved project changes, revise your risk list, and possibly modify the product’s objectives (requirements) or the specifications of the product itself (architecture and design). This revised specification for the project becomes the new target and allows you to steer the course of the project taking into consideration requirements and product changes.
Based on this adjusted set of objectives, you can plan the next iteration.
Two iteration planning documents in the IBM® Rational Unified Process® (RUP®) methodology are the Iteration Plan and the Iteration Assessment. In combination, they facilitate decisions that allow you to reduce risk, accept change, and steer the project through each iteration.
Adjust Remaining
Plan
Plan Next
Iteration
Start Next Iteration
Artifact: Iteration Plan
Module 2 - Iterative Project Management

9. Discussion: Iteration Assessment
Mastering the Management of Iterative Development v2 Instructor Notes
Discussion: Iteration Assessment
What types of information are needed to assess an iteration correctly?
Under what conditions might you be required to adjust:
Your project objectives?
Your target product?
Module 2 - Iterative Project Management

10. Mastering the Management of Iterative Development v2 Instructor Notes
Risk Recommendations
Iterative development recommends that you:
Create a risk list, order it by risk magnitude, and update it as the project progresses
Mitigate the highest magnitude risks as early as possible
Exiting Elaboration requires that highest (technical or otherwise) risks have been mitigated.
Module 2 - Iterative Project Management

11. Software Architecture
Mastering the Management of Iterative Development v2 Instructor Notes
Software Architecture
Software architecture defines the infrastructure, control, and data interfaces that permit:
Software components to cooperate as a system
Software designers to cooperate efficiently as a team
It is the most critical technical product of a software project.
It encompasses the set of significant decisions about the organization of a software system.
It maps the problem to a solution without violating constraints. It requires innovation and cannot be automated.
Module 2 - Iterative Project Management

12. Software Architecture (Cont.)
Mastering the Management of Iterative Development v2 Instructor Notes
Software Architecture (Cont.)
Software Architecture is the basis for decisions relating to:
Make/buy decisions
Component reuse
Intellectual control
Manage complexity
Maintain integrity
Project management
Planning, Staffing, Delivery
Because students vary in how familiar they are with the concept of architecture applied to software, it is best to get a sense of this from the students before beginning this section. If they are fairly unfamiliar, it helps to use the analogy of buildings or civil engineering. The more complex the building, the more critical a good architecture is. The longer you want the building to be useful, the more effort and expense you will put into the architecture. And in both of these cases, the choice of architect is critical.
Module 2 - Iterative Project Management

13. Architecture As a Basis for Project Management
Mastering the Management of Iterative Development v2 Instructor Notes
Architecture As a Basis for Project Management
A stable architecture represents a significant project milestone.
Poor architecture is often a reason for project failure.
Architecture is a prerequisite for predictable planning.
Architecture is the source of numerous high-payoff / high-risk decisions.
In RUP methodology, the architecture is primarily an outcome of the Analysis & Design reference workflow. As the project re-enacts this workflow iteration after iteration, the architecture evolves and becomes refined and polished. As each iteration includes integration and test, the architecture is quite robust by the time the product is delivered. This architecture is a main focus of the iterations of the Elaboration phase, at the end of which the architecture is normally baselined.
Module 2 - Iterative Project Management

14. Measurements in a Software Development Project
Mastering the Management of Iterative Development v2 Instructor Notes
Measurements in a Software Development Project
Measurements provide the development and management teams with:
An assessment of progress to date
Insight into the quality of the evolving software product
A basis for estimating the cost and schedule for completing the product with increasing accuracy over time
Two perspectives:
Point values
Trends of values
Module 2 - Iterative Project Management

15. Use of Measurements in Iterations
Mastering the Management of Iterative Development v2 Instructor Notes
Use of Measurements in Iterations
Start Iteration Using
Iteration Plan
Measurements
Complete Planned
Iteration Work
Assess
Iteration
Stop
Continue
Project Stopped
Adjust
Adjust Target
Objectives
Product
Measurements are one of the inputs to iteration assessment and subsequent planning. Low grades on some metric (when compared to requirements or estimates) may require rework or redirection in the next iteration.
Adjust Remaining
Measurements are used to assess iterations.
Plan
Plan Next
Iteration
Start Next Iteration
Module 2 - Iterative Project Management

16. Seven Core Metrics: Management
Mastering the Management of Iterative Development v2 Instructor Notes
Seven Core Metrics: Management
METRIC
PURPOSE
Work and progress
Iteration planning, plans versus actuals, management indicator
Budgeted cost and expenditures
Financial insight, plan versus actuals, management indicator
Change traffic and stability
Iteration planning, management indicator of schedule convergence
Breakage and modularity
Convergence, software scrap, quality indicator
Rework and adaptability
Convergence, software rework, quality indicator
MTBF and maturity
Test coverage/adequacy, robustness for use, quality indicator
Staffing and team dynamics
Resource plan versus actuals, hiring rate, attrition rate
See [Royce 98] page 188.
Module 2 - Iterative Project Management

17. Measurement Recommendations
Mastering the Management of Iterative Development v2 Instructor Notes
Measurement Recommendations
Iterative development recommends:
Measuring the progress and quality of software products throughout the development lifecycle
Extracting information from evolving artifacts, since these are the most useful measurements
Using objective analysis and automated data collection, since these are crucial to the success of any measurement program
Module 2 - Iterative Project Management

18. Discussion: Measurements
Mastering the Management of Iterative Development v2 Instructor Notes
Discussion: Measurements
Which measurements would you consider essential to iterative development in your environment? Can you think of any other measurement that your organization MUST have in addition to this core set? What is it and why?
In your last project, how did you adjust (or should you have adjusted) your objectives? What kind of measurement do you need to adjust your objectives?
Module 2 - Iterative Project Management

19. Mastering the Management of Iterative Development v2 Instructor Notes
Work Products
A work product is an abstract concept that provides a generalization for the concrete work product types Artifact, Outcome, and Deliverable.
A work product is:
Produced, modified, or used by a task
The responsibility of a single role, but can be modified or used by others
Likely to be subject to configuration control
Artifact-type work products may contain other artifacts
Iteration Plan
Iteration Assessment
Developer Test
Storyboard
Analysis Model
Business Goal
Use Case Model
Architectural Proof-of-Concept
Test Environment Configuration
Anything produced, evolved, or used by the process is considered to be a work product, including:
Models
Model elements
Documents
Source code
Executables
Work products are produced while working toward the final product. Only one role is responsible for a given work product. However, a work product of type artifact may contain other artifacts that are the responsibility of other roles (for example, the Software Development Plan).
Most work products evolve or change as the iterations progress.
Examples of work products:
Requirements Management Plan
Risk List
Design Model
Analysis Class
Project Measurements
Workspace
Tools
Business Use Case Model
User-Interface Prototype
Module 2 - Iterative Project Management

20. Mastering the Management of Iterative Development v2 Instructor Notes
Artifacts
An artifact is a work product that represents a piece of information that is produced, modified, or used by a process
Artifacts can be of type:
Model – created using modeling tools, from where we can automatically create reports
Document – created using word processors
Use Case Model
Iteration Plan
Module 2 - Iterative Project Management

21. Generic Artifact Lifecycles
Mastering the Management of Iterative Development v2 Instructor Notes
Generic Artifact Lifecycles
Evolving – Minor Changes Expected
Example: Vision
Example: Development Case
Evolving – Major Changes Expected
Example: Requirements Model
Snap-shot – Newly created for each iteration
Example: Iteration Plan
Examples through the phases:
Vision:
Evolving – Minor Changes Expected
Inception (end of phase): Approved by stakeholders and baselined
Elaboration iterations: Two features replaced by a new feature approved by CCB
Construction iteration: One minor change approved by CCB
Transition iterations: No changes
Development Case:
Inception (end of phase): Approved by team
Elaboration iterations: Verified and modified by team
Construction iteration: Verified and modified by team
Transition iterations: Verified and modified by team
Requirements Model:
Evolving – Major Changes Expected
Inception (end of phase): Baseline identification of use cases
Early Elaboration: Baseline the details of architecturally significant use cases or scenarios
End of Elaboration: Baseline architecturally significant use cases, identify (possibly) all use cases that make up the final system
End of Construction: All use cases detailed
Iteration Plan:
Snap-shot
Iteration Plan X+1 created and baselined at end of iteration X
No changes are made, a new Plan is created for following iteration
Module 2 - Iterative Project Management

22. Artifacts and their Uses
Mastering the Management of Iterative Development v2 Instructor Notes
Artifacts and their Uses
Artifacts provide:
Permanent documentation of a system’s structure and behavior, such as:
Reference manuals, user guides, and architecture description
Used by end-users, maintainers, and re-users
Transitory documentation of the development process, such as:
Internal design documentation
Status assessments
Defect reports
The goal is to minimize the
creation of artifacts.
Module 2 - Iterative Project Management

23. How Much Documentation is Enough?
Mastering the Management of Iterative Development v2 Instructor Notes
How Much Documentation is Enough?
A successful project provides documentation sufficient for:
Shared Vision
Communicate overall vision of project
Risk reduction
Promote a dialog between stakeholders and developers
Points of control for management
Make decisions and progress explicit and tangible
Conceptual integrity of the architecture
Capture and communicate the vision of the software architect/team
Module 2 - Iterative Project Management

24. Contrasting Approaches to Artifact Development
Mastering the Management of Iterative Development v2 Instructor Notes
Contrasting Approaches to Artifact Development
20-page paper with GUI prototype
Brief concept paper
Vision
Online help and tutorials, user manual, training course, phased cut-over plan, advertising campaign
Online help, Sales rollout, and marketing collateral
Deployment Plan
In-depth analysis of test results, measurement results, demos, and so on
Release Notes
Iteration Assessment
120 page document
5 slide presentation
Software Architecture Document
Detailed scenarios, quality targets, performance benchmarks, and so on
Kickoff meeting
Iteration Plan
Development plan, CM Plan, QA Plan, and so on
10 page overall plan
Software Development Plan
Full scope proposal
Short memo and spreadsheet
Business Case
Large System Development
Small Commercial Product
Sample Artifacts
Module 2 - Iterative Project Management

25. Essential Project Management Artifacts
Mastering the Management of Iterative Development v2 Instructor Notes
Essential Project Management Artifacts
Software Development Plan
Business Case
Deployment Plan
Risk List
Issues List
Review Record
Iteration Plan/ Iteration Assessment
Status Assessment
Only the artifacts for which the Project Manager is responsible are shown here. Each artifact is covered in the appropriate module of the course, along with a list of other artifacts belonging to other roles for that phase.
Some artifacts appear in multiple phases, indicating updates or recreation of the same artifact.
This list is similar to the essential artifacts listed in RUP.
Module 2 - Iterative Project Management

26. Essential Mgt. Artifact: Software Development Plan
Mastering the Management of Iterative Development v2 Instructor Notes
Essential Mgt. Artifact: Software Development Plan
The Software Development Plan includes the following information:
Project Overview
Project Organization
Management Process
Project Estimates
Project Plan
Iteration Plans
Project Monitoring and Control
Technical and Supporting Process Plans
Important for gathering all information necessary to control the project, and for directing the development effort.
The Software Development Plan is a comprehensive, composite artifact that gathers all of the information required to manage the project. It encloses a number of artifacts developed during the Inception phase, and is maintained throughout the project.
Module 2 - Iterative Project Management

27. Essential Mgt. Artifact: Iteration Plan
Mastering the Management of Iterative Development v2 Instructor Notes
Essential Mgt. Artifact: Iteration Plan
The Iteration Plan includes the following information:
Task-level Plan
Resources
Use Cases
Evaluation Criteria
It is important for:
The project manager, to plan the iteration tasks and activities, to schedule resource needs, and to track progress against the schedule
Project team members, to understand what they need to do, when they need to do it, and what other activities they are dependent upon
The Iteration Plan is a time-sequenced set of activities and tasks, with assigned resources, containing task dependencies, for the iteration. It is a fine-grained plan.
Module 2 - Iterative Project Management

28. Essential Mgt. Artifact: Iteration Assessment
Mastering the Management of Iterative Development v2 Instructor Notes
Essential Mgt. Artifact: Iteration Assessment
The Iteration Assessment includes the following information:
Iteration Objectives reached
Adherence to Plan
Use Cases implemented
Results relative to Evaluation Criteria
Test Results
External Changes
Rework required
It is important for the development organization to reflect on what has happened, what was achieved (or not) and why, and the lessons learned from the iteration.
The iteration Assessment captures the results of an iteration, the degree to which the evaluation criteria were met, lessons learned, and changes required.
Module 2 - Iterative Project Management

29. Team Scheduling and Staffing
Mastering the Management of Iterative Development v2 Instructor Notes
Team Scheduling and Staffing
Phase
Schedule
Staff
Inception
If the project will last about one year, this phase will last about one month.
A small team including:
The project manager
The system/software architect
A member of the test team
Several developers who will continue on the project
Elaboration
If the project will last about one year, this phase will last about two to four months.
The software architect
A small team of designers and developers
A small test team
One to two domain experts or end-users
Tool specialists
Module 2 - Iterative Project Management

30. Team Scheduling and Staffing (Continued)
Mastering the Management of Iterative Development v2 Instructor Notes
Team Scheduling and Staffing (Continued)
PHASE
SCHEDULE
STAFF
Construction
If the project will last about one year, this phase will last about five to six months.
For a modest size project, plan for a new release every 2 to 3 months.
For a more complex project, every 6 to 9 months.
Staffing reaches its peak. 80% of the team should be directly contributing to the release.
The remaining 20% are performing tasks that address new risks and prepare the ground work for next releases.
Transition
Varies greatly depending on how the end of the phase is defined.
If customer acceptance marks the end of transition, then for a one year project, the transition phase should not last more than one month.
If the end of product life marks the end of transition, the transition phase may last much longer.
The software manager
The software architect (part-time)
A small team of developers and testers
Technical support personnel
A technical writer (to update documentation)
Marketing, manufacturing, trainers, and other support personnel
Module 2 - Iterative Project Management

31. RUP Distribution of Skills by Phase
Mastering the Management of Iterative Development v2 Instructor Notes
RUP Distribution of Skills by Phase
Table shows percentage of effort by activity for each phase.
Inception %
Elaboration%
Construction%
Transition %
Management 14 12 10 14
Environment/CM 10 8 5 5
Requirements 38 18 8 4
Design 19
The table shows the percentage of effort by activity for each of the four RUP phases. See [Boehm 00] p. 324 for more information. 36 16 4
Implementation 8 13 34 19
Assessment 8 10 24 24
Deployment 3 3 3 30
Total
100
100
100
100
Module 2 - Iterative Project Management

32. Iterative Project Management Issues
Mastering the Management of Iterative Development v2 Instructor Notes
Iterative Project Management Issues
Overly detailed planning up to the end
Detailed plans outdate quickly
Incorporate precision commensurate with knowledge of current activities
Progress based upon completion of artifacts
Artifacts are poor predictors of project completion
Concentrate on code completion instead
Too many iterations
A build is not an iteration release
Keep iteration durations to a minimum of about 1-2 months
Module 2 - Iterative Project Management

33. Iterative Project Management Issues
Mastering the Management of Iterative Development v2 Instructor Notes
Iterative Project Management Issues
Change in responsibilities and perspective of team members and clients
Analysts
Developers
Testers
Project Manager
Quality Assurance and Method Expert
Client
From Per Kroll,
The analyst's new mindset
Establish an ongoing dialog with the end user, developers, and testers to ensure that developers will create the right system, choosing the right level of detail for requirements based upon the project’s needs.
The developer's new mindset
Broaden responsibilities to include detailed design, implementation, and unit testing. At the same time, participate in the requirements and testing efforts. Look for opportunities to reuse existing solutions.
The tester’s new mindset
Work with analysts and developers to ensure that the requirements and design are testable.
Get involved in the test effort early in the project.
The project manager’s new mindset
Drive out risks early in the lifecycle.
The quality assurance and method expert’s new mindset
Focus on maintaining quality throughout the project lifecycle, but be flexible. Quality is best achieved not through a maniacal focus on only reviews and testing, but through a good balance of investments in requirements, architecture, design, implementation, reviews, and testing at any given time.
The client’s new mindset
Actively participate in shaping requirements and become an integral part of the software development team.
Continuously provide feedback on capabilities that have been developed, such as working prototypes and user interface designs.
Module 2 - Iterative Project Management

34. Exercise: Collegiate Sports Case Study
Mastering the Management of Iterative Development v2 Instructor Notes
Exercise: Collegiate Sports Case Study
Refer to Exercises section of your workbook and complete:
Exercise 1: Project Planning
Module 2 - Iterative Project Management

35. Mastering the Management of Iterative Development v2 Instructor Notes
Module 2 Review
A Project Manager must monitor and steer an iterative project towards success by regularly assessing and re-planning.
Three concepts important for an iterative lifecycle are:
Addressing risk early
Stabilizing architecture early
Using objective measurements
Use of artifacts should be kept to a minimum, and the decision should be made about artifact evolution.
Important iterative project management artifacts are:
Software Development Plan
Iteration Plan
Iteration Assessment
Team responsibilities evolve through phases and iterations, so staffing and scheduling must evolve.
Module 2 - Iterative Project Management

36. Mastering the Management of Iterative Development v2 Instructor Notes
Module 2 - Iterative Project Management