WBS.02.FEB.97
2 February 1997

SWSE 625 MJY Team Project Work Breakdown Structure


  1. ANALYZE SOFTWARE REQUIREMENTS
    1. Understand functional and software requirements
      1. Link(s) to original Software Risk Management Articles
      2. Link(s) to Software Risk Management Material in the Public Domain
      3. Bibliography of articles and publications related to Software Risk Management
      4. Link(s) to Tools used for Software Risk Management
      5. Link(s) to articles and publications related to lessons learned in Software Risk Management
      6. Link(s) to information on Software Risk Management metrics (Industry norms)
      7. Levity section containing humorous pictures or articles related to Software Project Management
      8. Chat room for interested users to interact with others
      9. MJY team draft documentation review section
    2. Identify missing, vague, ambiguous, and conflicting requirements
      1. Link(s) to Tools used for Software Risk Management
      2. Link(s) to information on Software Risk Management metrics (Industry norms)
      3. Chat room for interested users to interact with others
    3. Clarify stated requirements
      1. Link(s) to original Software Risk Management Articles
      2. Link(s) to Software Risk Management Material in the Public Domain
      3. Bibliography of articles and publications related to Software Risk Management
      4. Link(s) to Tools used for Software Risk Management
      5. Link(s) to articles and publications related to lessons learned in Software Risk Management
      6. Link(s) to information on Software Risk Management metrics (Industry norms)
      7. Levity section containing humorous pictures or articles related to Software Project Management
      8. Chat room for interested users to interact with others
      9. MJY team draft documentation review section
    4. Verify that stated requirements fulfill requestor's goals
    5. Assess technology for supplying required software
      1. Determine space available for web site requirements
      2. Determine if permissions required to support chat room requirement are available
    6. Propose alternate requirements or capability
    7. Document revised requirements
      1. Produce draft Software Requirements Specification (SRS)
      2. Submit draft SRS for team review
      3. Incorporate team comments into draft SRS
      4. Release Initial SRS to customer/team
      5. Update SRS for Preliminary Design Review (PDR)
      6. Update SRS for Critical Design Review (PDR)
      7. Produce final SRS for Functional Acceptance Testing (FAT)
  2. DEVELOP SOFTWARE ARCHITECTURE
    1. Determine architectural approach
    2. Develop external functional architecture
    3. Develop software internal architecture
      1. Link(s) to original Software Risk Management Articles
      2. Link(s) to Software Risk Management Material in the Public Domain
      3. Bibliography of articles and publications related to Software Risk Management
      4. Link(s) to Tools used for Software Risk Management
      5. Link(s) to articles and publications related to lessons learned in Software Risk Management
      6. Link(s) to information on Software Risk Management metrics (Industry norms)
      7. Levity section containing humorous pictures or articles related to Software Project Management
      8. Chat room for interested users to interact with others
      9. MJY team draft documentation review section
    4. Assess architected solution vs. requirements
    5. Revise architecture and/or renegotiate requirements
    6. Document architecture and/or changed requirements
  3. DEVELOP EXTERNAL FUNCTIONAL SPECIFICATION
    1. Define functional specification standards and conventions
    2. Formalize external environment and interface specifications
    3. Refine, formalize, and document the architected external operational view of the software
    4. Define functional acceptance tests
    5. Verify compliance of the external view with requirements
  4. PRODUCE AND DELIVER SOFTWARE ITEMS
    1. Define programming, test and verification, QA, and documentation standards and conventions
    2. Formalize internal environment and interface specifications
    3. Obtain support tools
    4. Refine and formalize the internal design
    5. Define testing specifications to demonstrate required performance
    6. Define QA specifications
    7. Code and check the program
      1. Link(s) to original Software Risk Management Articles
      2. Link(s) to Software Risk Management Material in the Public Domain
      3. Bibliography of articles and publications related to Software Risk Management
      4. Link(s) to Tools used for Software Risk Management
      5. Link(s) to articles and publications related to lessons learned in Software Risk Management
      6. Link(s) to information on Software Risk Management metrics (Industry norms)
      7. Levity section containing humorous pictures or articles related to Software Project Management
      8. Chat room for interested users to interact with others
      9. MJY team draft documentation review section
    8. Demonstrate acceptability and deliver software
  5. PREPARE FOR SOFTWARE SUSTAINING AND OPERATIONS
    1. Train cognizant sustaining and maintenance personnel
    2. Train cognizant operations personnel
    3. Deliver sustaining tools and materials
    4. Deliver all software and data deliverables to operations
    5. Install the software and data into its operational environment
    6. Prepare consulting agreement between implementation and operations
  6. PERFORM PROJECT MANAGEMENT FUNCTIONS
    1. Define project goals and objectives
    2. Scope and plan the project
      1. Produce project Work Breakdown Structure (WBS) elements
      2. Determine appropriate project milestones
      3. Establish schedule requirements for tasks
      4. Assign resources to tasks
    3. Administrate the implementation
      1. Collect actuals for task cost and schedule (weekly)
    4. Evaluate performance and product
      1. Conduct weekly project reviews
        1. Evaluate actual versus projected schedule
        2. Evaluate actual versus projected cost
    5. Terminate the project

Software Project Management / Comments? / Back / Last Updated: April 7, 1997