Managing the Project Lifecycle

1
Managing the Project Lifecycle

• Jim Fawcett
• CSE784 Software Studio
• Fall 2001

2
Reference

• Software Project Survival GuideSteve
  McConnellMicrosoft Press, 1998

3
Customers 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

4
Customers Bill of Rights (continued)

• To know the projects 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

5
Project Teams Bill of Rights

• To know the project objectives and to clarify
  priorities.
• To know in detail what product Im 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 softwares functionality.

6
Teams 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

7
Teams 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 projects 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.

8
People-aware Management Accountability

• Managers should be held accountable for whether
  the organizations 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?

9
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

10
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

11
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 developers
  tasks on the project goals.

12
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.

13
Staged Delivery
14
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

15
A Staged Delivery Process
16
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.

17
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.

18
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.

19
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.

20
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.

21
Architecture Complete (cont)

• Install program created and baselined.
• User manual/specification updated.
• Stage 1 feature-complete product delivered.
• Estimates, top 10 risks, log updated.

22
First Stage Code Complete Then

• Repeat preceding steps.

23
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.

24
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.

25
Some Additional Detail
26
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.

27
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.

28
Elements of a Quality Assurance Plan

• Defect tracking
• Unit testing
• Source code tracing
• Technical reviews
• Integration testing
• System testing

29
Architecture

• Provide system overview.
• Define subsystems and organization.
• Identify areas most subject to change.
• Make buy versus build versus reuse decisions.

30
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

31
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.

32
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.