Download Project Lifecycle

Managing the Project Lifecycle
Jim Fawcett
CSE784 – Software Studio
Fall 2001
Reference
• Software Project Survival Guide
Steve McConnell
Microsoft Press, 1998
Customer’s Bill of Rights
• To set objectives for the project and have them followed
• To know how long the project will take and how much it will
cost
• To decide which features are in and which are out of the
software
• To make reasonable changes to requirements throughout
the course of the project and to know the costs of making
those changes
Customer’s Bill of Rights (continued)
• To know the project’s status clearly and confidently
• To be apprised regularly of risks that could affect cost,
schedule, or quality, and to be provided with options for
addressing potential problems
• To have ready access to project deliverables throughout
the project
Project Team’s Bill of Rights
• To know the project objectives and to clarify priorities.
• To know in detail what product I’m supposed to build and
to clarify the project definition if it is not clear.
• To have ready access to the customer, manager, marketer,
or other person responsible for making decisions about the
software’s functionality.
Team’s Bill of Rights (continued)
• To work each phase of the project in a technically
responsible way, especially to not be forced to start coding
too early in the project.
• To approve effort and schedule estimates for any work that
I will be asked to perform. This includes the right to
provide only the kinds of cost and schedule estimates that
are theoretically possible at each stage of the project
Team’s Bill of Rights (continued)
• To take the time needed to create meaningful estimates;
and to revise estimates whenever the project's
requirements change
• To have my project’s status reported accur-ately to
customers and upper management.
• To work in a productive environment free from frequent
interruptions and distractions, especially during critical
parts of the project.
People-aware Management Accountability
• Managers should be held accountable for whether the
organization’s human resources emerge from the project
strengthened or diminished.
– Do developers quit the company at the end of the project?
– Does the whole team emerge with improved skills and excellent
morale?
Life Cycle – Project Planning
• Software Development Plan
• Project cost and schedule estimates
• Quality Assurance Plan
– Technical reviews
– testing
•
•
•
•
Staged Delivery Plan
Requirements development
Architecture
Detailed Design
Planning Review
•
•
•
•
•
•
•
•
Vision statement and business case
Preliminary effort and schedule estimates
Top 10 risks list
User interface style guide
Detailed user interface prototype
User manual/Requirements Specification
Software Quality Assurance Plan
Detailed Software Development Plan
Early Project Control
•
•
•
•
Explicitly choose a life-cycle model, e.g., staged delivery.
Set up process to manage changes to requirements.
Set design and coding standards.
Create a detailed plan to focus each developer’s tasks on the
project goals.
Benefits of Staged Delivery
•
•
•
•
Critical functionality is available earlier.
Risks are reduced early.
Problems become evident early.
Status-reporting overhead is reduced.
– working software is best status report
• More options are available with staged delivery.
• Reduces estimation errors.
Softw are Concept
Staged Delivery
Requirements
Development
Architectural Design
Stage 1: Detailed
design, construction,
release
Stage 2: Detailed
design, construction,
release
Stage n: Detailed
design, construction,
release
Softw are Release
Costs of Staged Delivery
• Increases project overhead
–
–
–
–
–
Time to drive to software release many times
Retest already tested features
Versioning for each delivery
Support multiple versions in the field
Planning staged releases
A Staged Delivery Process
Top Level Milestones
•
•
•
•
•
•
•
Key decision maker on board.
Vision statement reviewed and published.
Preliminary cost and schedule targets defined.
First senior developers on board.
Change control plan established.
Top 10 risks defined.
Software project log started.
Project Launch – Then:
•
•
•
•
•
•
•
QA & Documentation leads on board.
Key users identified and interviewed.
UI Prototype created, reviewed by users.
UI style guide baselined.
First project estimates baselined.
Preliminary Software Development Plan baselined.
Top 10 risks and log updated.
Preliminary Requirements Development Complete – Then:
•
•
•
•
•
Detailed UI prototype completed and baselined.
User Manual/Requirements Specification baselined.
Software Quality Assurance Plan baselined.
Detailed Software Development Plan baselined.
Project estimates, top 10 risks, project log updated.
Detailed Requirements Development Complete – Then:
•
•
•
•
•
•
Most of development team and QA staff on-board.
Software architecture document baselined.
Software integration procedure defined.
Staged delivery plan defined.
Software test cases for stage 1 defined.
All earlier baselined products updated.
Architecture Complete – Then:
• Beginning-of-stage planning completed.
• Detailed Design Document for stage 1 baselined.
• Detailed software construction plan for stage 1 including
miniature milestones baselined.
• Software test cases for next stage baselined.
• Software build instructions (make files) for stage 1
baselined.
• Source code for stage 1 baselined.
Architecture Complete (cont)
•
•
•
•
Install program created and baselined.
User manual/specification updated.
Stage 1 “feature-complete” product delivered.
Estimates, top 10 risks, log updated.
First Stage Code Complete – Then:
• Repeat preceding steps.
Second Stage Code Complete:
•
•
•
•
•
•
•
Detailed design document for last stage baselined.
Software test cases for all stages updated.
Source code for all stages updated.
Build instructions for all stages updated.
Install program updated.
Integrated “feature-complete” product delivered.
Estimates, top 10 risks, log updated.
Last Stage Complete
• Release checklist baselined.
• Release sign-off form signed by all parties and put under
change control.
• Final product delivered.
• Final test cases delivered.
• Software media delivered.
• Project archives store off-site.
• Final updates to log.
• Project history document baselined.
Some Additional Detail
Change Control Procedure
• Initial development work is done without change control.
• When initial development is complete the product is
submitted to a change control board.
• If the board accepts the product it becomes baselined.
• After baselining the product is put under source control,
e.g., visual source safe, etc.
Change Control (continued)
• Further changes are treated systematically:
– Changes are proposed via Change Proposals with definition of
change and impact.
– The change board distributes the proposal to all affected
parties for review.
– Those affected provide assessments of cost and benefits from
their own perspectives.
– The board summarizes results and decides to:
• Accept, defer to a later time, or reject.
Elements of a Quality Assurance Plan
• Defect tracking
• Unit testing
– Source code tracing
• Technical reviews
• Integration testing
• System testing
Architecture
•
•
•
•
Provide system overview.
Define subsystems and organization.
Identify areas most subject to change.
Make buy versus build versus reuse decisions.
Architecture (continued)
• Specific areas to address:
–
–
–
–
–
–
–
–
–
–
External software interfaces
User interface
Database organization
Data structures and storage
Key algorithms
Memory management
Concurrency/threads
Security
Networking
Error handling
Code Integration Procedure
•
•
•
•
•
•
•
•
Code development
Developer unit tests code with tracing.
Developer integrates with a private version of main build.
Developer submits for review.
Informal turnover to testing.
Developer fixes problems found. Fixes are reviewed.
Developer integrates with main build.
Code is declared complete.
System Test
• System test is a half step behind construction.
• Exercises system from end-to-end.
• Testers support developers by ensuring that system quality
is high enough to support integration of new code.
• Developers support testers by fixing reported defects
quickly.