Managing the Project Lifecycle - PowerPoint PPT Presentation

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Managing the Project Lifecycle

Description:

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: http://lcs3.syr.edu
Category:

less

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

Title: Managing the Project Lifecycle


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

2
Reference
  • Software Project Survival Guide Steve
    McConnell Microsoft 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.
About PowerShow.com