Managing the Project Lifecycle - PowerPoint PPT Presentation


PPT – Managing the Project Lifecycle PowerPoint presentation | free to download - id: 51a5d9-ZjhhN


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Managing the Project Lifecycle


Managing the Project Lifecycle Jim Fawcett CSE784 Software Studio Fall 2001 Reference Software Project Survival Guide Steve McConnell Microsoft Press, 1998 ... – PowerPoint PPT presentation

Number of Views:79
Avg rating:3.0/5.0
Slides: 33
Provided by: JimFa2
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Managing the Project Lifecycle

Managing the Project Lifecycle
  • Jim Fawcett
  • CSE784 Software Studio
  • Fall 2001

  • Software Project Survival Guide Steve
    McConnell Microsoft Press, 1998

Customers Bill of Rights
  • To set objectives for the project and have them
  • 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

Customers Bill of Rights (continued)
  • To know the projects status clearly and
  • To be apprised regularly of risks that could
    affect cost, schedule, or quality, and to be
    provided with options for addressing potential
  • To have ready access to project deliverables
    throughout the project

Project Teams Bill of Rights
  • To know the project objectives and to clarify
  • 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.

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

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.

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
  • 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 developers
    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.

Staged Delivery
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
  • 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

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
  • 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
  • When initial development is complete the product
    is submitted to a change control board.
  • If the board accepts the product it becomes
  • 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

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