wiki:SDP/LsstSoftwareDevelopmentPlan
Last modified 5 years ago Last modified on 01/30/2014 09:36:27 AM

Obsolete ............ O B S O L E T E ........... Obsolete

Document superseded by LSE-17: Systems Engineering Management Plan

And more specifically, LSE-17 Appendix A: The DM Software Management Process. September 2013



DRAFT last revised 1 May 2009

LSST Software Development Plan (SDP) (LSE-16)

This document is maintained under configuration control in the LSST document repository as LSE-16. It is currently edited in Trac, but the authoritative, project-approved version is always the one to be found in Docushare. The "live" Trac version (SDP/LsstSoftwareDevelopmentPlan) must always be treated as potentially unstable - it may, for instance, represent a proposed modification to the controlled document.

Related documentation may be found in Trac at Software Standards (Trac:SwStandards).

1. Introduction

The Software Development Plan defines the policies, procedures, and criteria that the project follows in the development, configuration management, verification and validation, and quality assurance of production software. The LSST SDP is a synthesis of best practices from plans and procedures in use by NSF, NASA, DOE, ESA, and other institutions.

The SDP includes the following components, in this document and in three subordinate policy documents:



1.1 Definitions, Acronyms and Abbreviations

  • Baseline: a set of objects fixed at a specific time which is then used as the basis for further modification leading up to the designation of a new baseline.
    • baselined: the act of freezing an object and its attributes in a instant of time. In the context of configuration management, when an object is placed under configuration controlled status.
  • Baseline Plans : also known as Software Release Plans, define the processes and procedures which guide development during a specific Baseline cycle. They include
    • Software Release Project Plan, also known as the SRP Plan, will generally include a
      • Transfer Readiness Plan
    • Software Quality Asssurance Plan also known as the SQA Plan
    • Configuration Management Plan also known as the CM Plan
    • Verification & Validation Plan, also known as the V & V Plan, includes
      • Acceptance Test Plan also known as the Transfer Test Plan
      • System Test Plan
      • Integration Test Plan
      • Unit Test Plan
  • Lifecycle : sequenced progression through the following phases during product development:
    • Requirements phase : includes specification of the Science Requirements and the Derived Software Requirements;
    • Architectural Design phase also known as the Preliminary Design phase : includes analysis and development of the preliminary architectural design;
    • Detailed Design and Development phase also known as the D & D phase : the design is further refined, the software developed, and the product tested for compliance to the Derived Software Requirements ;
    • Transfer phase : the product is tested for compliance to the Science Requirements and released for use if authorized by SQA review of Readiness criteria.
  • Release Product : a Project deliverable, such as a library, executable, documentation, or report.
    • Validated Release Product is a Release Product which has been appropriately validated for a Baseline release.
  • Requirements are Science Council mandated and auxiliary Derived Requirements driving LSST development.
    • Science Requirements also known as the SRD
    • System Requirements also known as the Functional Performance Requirements aka FPRD
    • SubSystem Requirements also known as
      • DM Functional Requirements Specification aka DM FRS
      • Camera Requirements Document
      • Telescope & Site Requirements Document
    • Interface Control Document aka ICD
  • Software Development Plan, also known as SDP, includes guidelines for the following issues
    • Software Development Process
    • SQA, also known as Software Quality Assurance, verifies that the process and procedures followed are consistent with the project's Standards and Policies.
    • CM, also known as Configuration Management
    • V & V, also known as Verification and Validation, ensures that the Release Products conform to the designs and requirements of the Project at which time they become Validated Release Products.
  • SW : abbreviation for software
  • Subsystems : the major functional and administrative divisions of LSST.
    • Camera : LSST Camera Group
    • DM : LSST Data Management Group
    • Telescope and Site : LSST Telescope and Site Groups
  • WBS : Work Breakdown Structure

1.2 Roles and Responsibilities

Only the Roles and Reponsibilities pertinent to the SDP and associated documents are included below.

Project-wide SDP Roles and Responsibilities

Role Responsibilities
Project Management Responsible for global resource allocation to the Subsystems.
Project System Engineering Responsible for ICD specification.
Responsible for system-level Integration, System, and Acceptance testing.
Project Quality Control Responsible for system-level Quality Control management.


Subsystem SDP Roles and Responsbilities

Each subsystem must allocate each of the roles defined below. Individuals may assume the mantle of more than one role during a Development cycle.

Role Responsibilities
Subsystem Project Management Responsible for Baseline's resource allocation and management.
Generate the Baseline Project Management Plan which also includes the Software Transfer Plan.
Verify the Baseline's Derived Science Requirements are documented in the FPRD.
Verify the Baseline's Software Requirements are documented in the Subsystem's FRS (although set points may be lower for non-Production releases).
Verify the Baseline's Architectural Design is documented and complete.
Verify the Baseline's Detailed Design is documented and complete.
Subsystem Architect Responsible for Baseline's architectural design.
Subsystem Configuration Management Generate the Baseline's Configuration Management Plan.
Consult with V&V Lead to ensure CM requirements are integrated into the V&V procedures.
Ensure required CM tools are installed and configured appropriately.
Ensure specified CM procedures are implemented and integrated into Developers' workflows.
Subsystem Verification and Validation Generate the Baseline's Verification and Validation Plan
Consult with CM Lead to ensure CM requirements are integrated into the V&V workflow procedures.
Ensure required V & V tools are installed and configured appropriately.
Ensure specified V & V procedures are implemented and integrated into Developers' workflows.
Subsystem Software Quality Assurance Generate the Baseline's Software Quality Assurance Plan.
Verify the Baseline's: Project Management, Configuration Management, Verification & Validation Plans exist and conform to the SDP requirements.
Verify that all Plans' procedures and policies are being followed.
Ensure required SQA tools are installed and configured appropriately.
Ensure specified SQA procedures are implemented and integrated into Developers' workflows.
Subsystem Test Generate Baseline's Test Plans for Acceptance, System, Integration and Unit Testing according to the V & V procedures and policies.
Manage the Baseline's testing process for Acceptance, System, and Integration testing
Ensure the Test procedures are carried out according to the V & V Test Plan procedures and policies.
Test according to the LSST SDP and the Baseline Plans' policies and procedures.
Subsystem Development Design, implement, document, test according to the LSST SDP and the Baseline Plans' policies and procedures.
Follow workflow procedures which are designed to ensure configuration management of designated artifacts.
For each new or modified feature implemented, designs and implements the unit tester.

Refer to section DM Roles and Responsibilities for DM specific content.

1.3 Coordination between LSST Subsystem Groups

LSST-wide coordination of software engineering and development is the responsibility of the Deputy Systems Engineer for computing and IT issues. Cross-subsystem coordination is necessary in three areas: software interfaces between subsystems, necessary for data and control connections among them; shared software, either externally provided libraries or internally developed common code; and shared tools, for design, QC, configuration and version control, and communication.

The Deputy Systems Engineer chairs a standing subcommittee of the Systems Engineering Team, with representation from each subsystem's software development effort. This subcommittee oversees cross-subsystem computing and IT issues within the project.

1.4 Tools

The following tools are baselined for Project-wide use; individual subsystems may add to the list. The tools, which may include specialized hardware, will be used during software development and testing.

  • Enterprise Architect is a comprehensive SysML and UML analysis and design tool, covering software development from requirements gathering, through to the analysis stages, design models, testing and maintenance. Also known as 'EA'.
  • Subversion a open source tool which manages files and directories and the changes made to them over time allowing the recovery of older versions of an object or the examination of how the object changed. Subversion is not limited to only source files, it can include any object maintained as a file, for example, binary data files, executables, image files. The tool is also known as svn
  • Trac is a source configuration and change management tool used by LSST for
    • tracking and reporting on change requests necessitated due to bugs or feature enhancements; and
    • tracking and reporting on source development resulting from those change requests.
  • twiki a display-based document management system embedded in the trac tool, which maintains change history.

The use of common tools across LSST subsystems is strongly encouraged.

2. Software Development Process

The Software Development Process defines the major workflows and activities that the project follows in the development of production software. The Process is characterized by a spiral development cycle[ 1 ] where incremental prototyping is combined with sequential transition through the following phases:

  • Requirements Definition phase which includes specification of the Science Requirements and the Derived Software Requirements;
  • Architectural Design phase which includes analysis and development of the preliminary architectural design;
  • Detailed Design and Development phase where the design is further refined, the software developed, and the product tested for compliance to the Derived Software Requirements ; and
  • Transfer phase where the product is tested for compliance to the Science Requirements and released for use.

The spiral development model promotes intermediate demonstrations of functionality and end-to-end integration.

Specializations of the Software Development Process for individual LSST subsystems are permitted, and include:

Specializations covering matrixed support, such as for calibration and simulation, are defined within the hosting subsystem's specialization. For example, the observing schedule simulation is found in the Telescope & Site's specialization; some aspects of image simulation are found within Data Management's specialization; and other aspects of image simulation are found within Camera.


3. Scope

This overarching Software Development Plan and its three associated Guidelines on Software Quality Assurance, Verification and Validation, and Configuration Management, describe the overall policies and procedures required for LSST software development and provide guidelines and plan templates to use when preparing Baseline Development Plans.

3.1 Baseline Development Plans and their Templates

Each LSST software subsystem will prepare, for each baseline encompassing a complete Requirements Review / Design / Implement / Test / Release cycle, a Baseline Development Plan defining the specific processes and procedures to use during that baseline cycle. Baselines are exemplified by planned software and/or hardware releases.

Each Baseline Development Plan will contain the following 4 sections:

If the characteristics of a particular Baseline Plan do not change for the next lifecycle, that particular Plan may be cited as the current plan. In particular, the Configuration Management and Software Quality Assurance Plans might remain stable over many lifecycle iterations.


4. Software Guidelines

4.1 Quality Assurance

Software Quality Assurance [ 2 ] is a planned review of processes and procedures to provide adequate confidence that the item or product produced conforms to established technical requirements. SQA does this by checking that:

  • All Plans comply with Project Standards and Policies.
    • e.g. were the required planning documents completed?
  • Any procedures defined within a Plan were carried out as stated.
    • e.g. were Released-Product failures entered into the bug tracking system? were unit tests done?
  • Any Product developed as a result of a Plan complies with Project Standards and Policies.
    • e.g. did the coding comply with the Coding Language standards?

Refer to Software Quality Assurance Guidelines (document LSE-13).


4.2 Verification and Validation

Software Verification and Validation [ 3 ] checks products against their specifications. This is done by:

  • checking that each software item meets specified requirements;
  • checking each software item before it is used as an input to another activity;
  • ensuring that the amount of verification and validation effort is adequate to show each software item is suitable for operational use.

As such Software Quality Assurance complements Software Verification and Validation. The former reviews the processes used to create the product and the latter checks the instantiation meets the requirements.

The V & V Plan encompasses the development of Unit, Integration, System, and Transfer Test Plans as appropriate for the Baseline.

Refer to Software Verification and Validation Guidelines (document LSE-15).


4.3 Configuration Management

Software Configuration Management [ 4 ] provides the means of tracking software development over time. Software Configuration ensures:

  • software components can be identified;
  • software is built from a consistent set of components;
  • software components are available and accessible;
  • software components never get lost ( e.g. after media failure or operator error);
  • each change to software is approved and documented;
  • changes do not get lost (e.g. through simultaneous updates);
  • it is possible to go back to a previous version;
  • a history of changes is kept so that is is always possible to discover who did what and when.

Refer to Software Configuration Management Guidelines (document LSE-14).


4.4 Software Release Project Management

The Software Release Project (SRP) Plan provides the overarching goals, schedules, assignments, and orchestration directing a specific baseline's design, development and transfer. An SRP Plan template is provided in the Appendix.

The SRP Plan encompasses the development of the Software Transfer Plan which provides:

  • the transfer risk assessment procedure including the criteria used to determine if the product is ready for transfer or release;
  • the software transfer procedure including specification of the Transfer Readiness form authorizing transfer.

4.5 Cross-subsystem Coordination Issues

4.5.1 Inter-Subsystem Software Interfaces

Software interfaces between Subsystems are strictly managed by Interface Control Documents (ICDs), which are the responsibility of the LSST Systems Engineer. Changes to ICDs are covered by the project-wide configuration management process and require approval by the project Change Control Board (CCB).

The Deputy Systems Engineer for computing has the role of facilitating communication regarding the development of ICDs and their application, and of arbitrating between subsystems, when possible, when disputes arise. The computing systems engineering subcommittee is the normal forum for technical communication among subsystems in the preparation of software and other computing-related ICDs.

Interface specifications are developed by first determining the interface requirements, which are captured in the LSST Model-Based Systems Engineering process in SysML; then developing explicit interface specifications; and then developing header files or other software representations of those interfaces.

The software representations may need to be in one or more of the approved specific programming languages of the LSST project, or they may be specified in a cross-language form such as the Object Management Group's Interface Definition Language (IDL).

Request for changes to software interfaces between subsystems should normally first be vetted by each affected subsystem's TCT and then approved by the computing systems engineering subcommittee - that process may be iterative - before being forwarded to the full LSST change control process.

4.5.2 Shared Software

Shared software includes

  • the programming language representations of shared interfaces, as above;
  • implementations of LSST-developed libraries that have an application across more than one LSST subsystem, examples of which are:
    • the OCS communications middleware software for exchanging messages between the subsystems,
    • the camera data acquisition clients ("SDS client" and its relatives),
    • the camera simulator developed by Camera group and used independently by the Data Management group, and
    • the image analysis system developed by the Data Management group and used independently by the Telescope & Site group; as well as
  • external libraries agreed to be of project-wide value.

Shared software must be maintained in a version control system that is accessible to all subsystems. The development and primary QA process for internally developed shared software is the responsibility of the subsystem group which owns the associated work package. The computing systems engineering subcommittee has an oversight role to ensure that shared software meets the necessary standards in all of its applications within LSST, and may ask other affected subsystems to take a role in QA and testing.

The quality assurance process for shared software must take into account all of its uses within LSST. Thus, for instance, it must be built and tested for the union all of the software development platforms that are used across its application in the project.

The selection of external libraries for project-wide use is managed by the computing systems engineering subcommittee. Requests for changes to baselined choices of external libraries with project-wide application are subject to the LSST configuration management process.

4.5.3 Development Platforms and Languages

Without interfering with the LSST subsystems' ability to make choices of software development environments and languages that meet the technical requirements of the subsystems, the project will strive to avoid an unnecessary multiplicity of platforms and languages across subsystems (e.g., different flavors of Linux across subsystems), with the goal of limiting the long-term complexity of operational maintenance. At the same time, the systematic and deliberate use of more than a single platform is recognized to have benefits in preserving portability and facilitating debugging. The computing systems engineering subcommittee is tasked with finding the appropriate balance.


4.6 Portability and Conformation to External Standards

Recognizing that the construction and operation phases of the project should last at least fifteen years, the long-term maintainability of the project software is a crucial design goal. Except when specific technical issues make this unusually difficult, or where a major benefit to the project would result, the project shall strive to make its software portable across platforms and conformant to applicable external standards, and shall avoid the use of vendor-specific extensions and other unique technologies. Decisions to deviate from this principle shall be documented and approved by the Deputy Systems Engineer and/or the LSST subsystem software architects or the bodies they may designate for this function.

Lists of applicable external standards, and definitions of the scope of portability to be maintained, shall be developed by the Deputy Systems Engineer and the LSST subsystem software architects and shall be placed under configuration control. These lists may include subsystem-specific specializations.


5. Acknowlegements and References

The framework for the Software Development Guidelines and their associated Plans are based on [ 2-5 ].

  • [ 1 ] Boehm B, "A Spiral Model of Software Development and Enhancement", "IEEE Computer", pp 61-72, May 1988

6. Subsystem Specialization Overview

(Editor's note: the collection of subsystem specializations is an ongoing process and has not completed as of the first release of this document for review. Changes in this area are to be expected.)

6.1 Data Management Subsystem

6.1-1.2 DM Roles and Responsibilities

Data Management organizational structure has an additional management level not represented in the general Roles and Responsibilities. The DM Subsystem Project Manager has split DM into two management entities: DM Applications and DM Middleware. Additionally, the SQA and Test roles have been combined. Following are the revised roles and responsibilities:

  • DM SQA & Test Management is responsible for the development of
    • the DM Software Quality Assurance Guidelines,
    • the DM Configuration Management Guidelines,
    • the DM Verification and Validation Guidelines,
    • the Baseline's Software Quality Assurance Plans,
    • the Baseline's Configuration Management Plans,
    • the Baseline's Verification and Validation Plans (excluding the Unit Test Plans),
    • the Baseline's Transfer Readiness Report, and
    • either performing or overseeing all the Verification and Validation Testing excluding the Unit Testing.
  • Applications Project Management is responsible for:
    • Coordinating the implementation of design/requirements across the Applications subsystems.
  • Applications SQA & Test is responsible for:
    • Ensuring that the Application implementation is traceable to and meets the levied requirements by
      • checking that coding standards were followed;
      • checking that unit testing procedures were followed;
    • Ensuring the overall Applications development is consistent with the implementation defined by the Applications Design Team;
    • Coordinating with the DM SQA & Test Lead on establishing quality metrics and integration and test plans
      • In particular, the development of the Unit Test Plan for Applications Modules in the Verification and Validation Plan.
  • Middleware Project Management is responsible for :
    • Coordinating the implementation of design/requirements across the Middleware subsystems.
  • Middleware SQA & Test is responsible for :
    • Ensuring that the Middleware implementation is traceable to and meets the levied requirements by
      • checking that coding standards were followed;
      • checking that unit testing procedures were followed;
    • Ensuring the overall Middleware development is consistent with the implementation defined by the Middleware Design Team;
    • Coordinating with the DM SQA & Test Lead on establishing quality metrics and integration and test plans
      • In particular, the development of the Unit Test Plan for Middleware Modules in the Verification and Validation Plan.

6.1-2 DM Software Development Process

The DM Software Development Process is based on the ICONIX Process as documented in the book "Use Case Driven Object Modeling with UML" by Doug Rosenberg and Matt Stephens. The major workflows in this process include:

The first 3 of these workflows map to the LSST Research and Design (R&D) phase, while the last one maps to the LSST Construction Phase.

The ICONIX Process relies on a subset of the Unified Modeling LanguageTM (UML), an Object Management Group standard that is very widely used in software development. In particular, the ICONIX Process uses the Use Case, Class Diagram, and Sequence Diagram portions of the UML standard, as well as the Objectory Extension to UML that defines Robustness Diagrams.

Note that in addition to and in parallel with the ICONIX Process, LSST has adopted a prototyping strategy during the LSST R&D phase involving annual Data Challenges. These Data Challenges are software development projects in their own right, albeit with a limited functional and performance scope. Each Data Challenge project is a complete iteration of the Software Development Process that validates a portion of the ultimate LSST System. A description of the Data Challenges can be found at Data Challenges.

During the LSST Construction Phase, the concept of Data Challenges changes to one of incremental development, where instead of prototypes, the actual system is developed in a sequence of incremental releases.

6.1-3.1 DM Baseline Templates and Plans

All DM Baseline Development Plans will be available on the DM Trac document archive at http://dev.lsstcorp.org/trac/wiki/SDP/Baselines.

6.2 Telescope and Site Subsystem

6.2-1.4 Telescope and Site specific development tools

  • MM (Modules Manager): the Telescope and Site software development team uses a tool called Modules Manager (MM) for the version control managment that implements a wrapper over subversion. This tool is an in-house development written in python and c-shell, acting as a thin layer that implements the group policies and practices in software versioning and archival, simplifying at the same time the interface to the version control system.
  • NI Requirements Gateway: NIRG is a Requirements Management Software from National Instruments that links the development and verification documents with formal requirements stored in documents and databases. It is also fully compatible with NI LabVIEW programming language, used extensively in the Telescope and Site software team.

6.3 Camera Subsystem

Differences between Camera and DM software arise from the different operating environments. Camera SW operates in real-time. It controls and monitors camera hardware and responds to user commands. The measure of performance is worst-case, not average, behavior.

6.3.1. Quality Assurance

Camera SW will undergo a similar QA cycle, with some important differences, to that performed on the DM SW.

The Camera software design philosophy is to divide the SW into autonomous modules that can be independently tested. Modularity is especially important, because many pieces of the camera SW will need to execute as standalone code during the hardware development and test phases.

Camera software tests and milestones will, by necessity, be coupled to the hardware development. Some tests can be performed with proxy software; others will require real hardware. The camera SW development schedule includes both kinds.

6.3.2. Verification and Validation

The functional requirements documents (FRDs) specify both algorithmic and temporal performance. Verification of algorithmic performance can often be done with simulated data. Verification of temporal performance (e.g., response times and control loop performance) will usually require attached hardware.

The camera software has internal interfaces (between camera modules), external interfaces (to TCS and DM), and user interfaces. These interfaces will be specified in several ICDs. Three camera specific interface behaviors are:

  • Each module must acknowledge receipt of commands.
  • The control SW must post telemetry data to the facility database.
  • The data acquisition must deliver images to its clients (e.g., DM).

As the camera software is developed, first for the various test stands, then in an increasingly integrated environment, the communications must adhere ever more closely to the communications and interface standards. The level of adherence required for each test will be specified in the milestones.

Timely error detection and reporting is a critical feature of the camera software. It is particularly important early in the development and construction of the camera, because good error detection will ease hardware development and debugging. Knowledge of the appropriate symptoms to report will translate into optimized performance of the completed camera.

Some aspects of the camera software (e.g., guiding) may require simulated data during verification. Also, simulated data can test more extensively the software's ability to detect hardware problems than is possible with a test stand. We need to specify when simulated data will be needed, and what properties it should have.

6.3.3. Configuration Management

For DM, configuration management means SW version control. The camera SW must also manage hardware configurations. This includes (in real time) adapting parameters to hardware and environmental conditions, responding to user reconfiguration requests, and (perhaps) adding and removing data clients.

Example requirements that follows from the above: Hardware components must self-identify (i.e., respond to "Who are you?" commands), in order to verify the correctness of configuration requests. The software must compare requested parameters with installed hardware, checking for consistency.


Appendix

Software Release Project Plan (SRPP) Template

  • 1. Introduction
    • This document will primarily provide pointers to the relevant documents.
    • 1.1 Release overview
      • 1.1.1 Objectives
      • 1.1.2 Deliverables
      • 1.1.3 Life Cycle Approach
      • 1.1.4 Major Activities
      • 1.1.5 Milestones
      • 1.1.6 Resource Requirements
      • 1.1.7 Schedule
      • 1.1.8 Budget
    • 1.2 Release deliverables
    • 1.3 Evolution of the SRP Plan
    • 1.4 Reference materials
    • 1.5 Definitions and acronyms
  • 2. Project Organization
    • 2.1 Process model
    • 2.2 Organizational structure
    • 2.3 Organizational boundaries and interfaces
    • 2.4 Project (roles) responsibilities
  • 3 Managerial Process
    • 3.1 Management objectives and priorities
      • This section should define the management objectives and their relative priorities. They should discuss any trade-offs between the objectives.
    • 3.2 Assumptions, dependencies and constraints
      • This section should state the:
        • assumptions on which the plan is based;
        • external events the project is dependent upon;
        • constraints on the project (e.g. availability of staff | hardware, budget, schedule).
    • 3.3 Risk management
      • This section of the plan should identify and assess the risks to the project, and describe the actions that will be taken in this phase to manage them.
    • 3.4 Monitoring and controlling mechanisms
      • This section of the plan should define the monitoring and controlling mechanisms for managing the work. Possible monitoring and controlling mechanisms are:
        • work package descriptions;
        • work package completion reports;
        • progress reports;
        • reviews;
        • audits; (SQA audits referenced)
        • workgroup meeting summaries .
    • 3.5 Staffing plan
      • This section of the plan should give the roles and total number of staff on the project.
  • 4. Technical Process
    • 4.1 Methods, tools and techniques
      • This section should specify the methods, tools and techniques to be used to produce the deliverables.
    • 4.2 Software documentation
      • This section should define or reference the documentation plan. For each document to be produced, the documentation plan should specify:
        • document name;
        • review requirements;
        • approval requirements.
    • 4.3 Project support functions
      • This section should contain an overview of the plans for the project support functions of:
        • software configuration management;
        • software verification and validation;
        • software quality assurance.
  • 5. Work Packages, Schedule, and Budget
    • 5.1 Work packages
      • This section should describe the breakdown of the phase activities into work packages. This section may begin with a Work Breakdown Structure (WBS) diagram to describe the hierarchical relationships between the workpackages. Each box should show the title and identifier of the work package. Alternatively, the work breakdown may be described by listing the work package titles and identifiers. Each Work Package description should define the:
        • work package title;
        • work package reference number;
        • responsible organization;
        • major constituent activity;
        • work package manager;
        • start event;
        • end event;
        • inputs;
        • activities;
        • outputs.
      • The full Work Package Descriptions may be contained in this section or put in an appendix.
    • 5.2 Dependencies
      • This section should define the ordering relations between the work packages. This may be done by using a planning network technique, such as the Program Evaluation and Review Technique (PERT), to order the execution of work packages according to their dependencies. Dependency analysis should define the critical path to completion of the project and derive the 'float' for activities off the critical path.
    • 5.3 Resource requirements
      • This section should describe, for each work package:
        • the total resource requirements;
        • the resource requirements as a function of time.
    • 5.4 Budget and resource allocation
    • 5.5 Schedule
      • This section should define when each work package starts and ends. This is normally done by drawing a Gantt chart.
      • This section should describe the milestones in the project, providing for each milestone:
        • an identifier;
        • a description (e.g. a list of deliverables);
        • the planned date of achievement;
        • the actual date of achievement (for plan updates).
  • Appendix
    • Work Breakdown Structure (WBS)