DRAFT last revised 18 Dec 08

LSST Software Development Plan (SDP)

Table of Contents

  1. LSST Software Development Plan (SDP)
    1. 1. Introduction
      1. 1.1 Definitions, Acronyms and Abbreviations
    2. 1.2 Roles and Responsibilities
    3. 1.3 Coordination between LSST Subsystem Groups
      1. 1.3.1 Shared Software Interfaces
      2. 1.3.2 Shared Software
    4. 1.4 Tools
    5. 2. Software Development Process
    6. 3. Scope
      1. 3.1 Baseline Development Plans and their Templates
    7. 4. Software Guidelines
      1. 4.1 Quality Assurance
      2. 4.2 Verification and Validation
      3. 4.3 Configuration Management
      4. 4.4 Project Management
    8. 5. Acknowledgements and References
    9. 6. Subsystem Specialization Overview
      1. 6.1 Data Management Subsystem
        1. 6.1-2 DM Software Development Process
      2. 6.1-3.1 DM Baseline Templates and Plans
      3. 6.2 Telescope and Site Subsystem
      4. 6.3 Camera Subsystem
        1. 6.3.1. Quality Assurance
        2. 6.3.2. Verification and Validation
        3. 6.3.3. Configuration Management
    10. Appendix
      1. Baseline Software Project Management (BPM) Plan Template
      2. Baseline Software Transfer Plan Template

From Software Standards

1. Introduction

The Software Development Plan defines the plans, 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:



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 : define the processes and procedures which guide development during a specific Baseline cycle. They include
    • Baseline Project Management Plan, also known as the BPM Plan, includes
      • 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 becomes 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

TBD Define the many generic roles and responsibilities assumed during a Development Cycle. Kantor and Sweeney providing input.

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

Key

PM Project Manager
QCO Quality Control Officer
SE System Engineer
SS Subsystem


Role Responsibilities
LSST PM Responsible for global resource allocation to the Subsystems.
LSST SE Responsible for ICD specification.
Responsible for system-level Integration, System, and Acceptance testing.
LSST QCO Responsible for system-level Quality Control management.
SS Baseline PM 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.
SS Baseline Architect Responsible for Baseline's architectural design.
SS Baseline CM Lead Generate the Baseline's Configuration Management Plan.
Consults with V&V Lead to ensure CM requirements are integrated into the V&V procedures.
Ensures required CM tools are installed and configured appropriately.
Ensures specified CM procedures are implemented and integrated into Developers' workflows.
SS Baseline V & V Lead Generate the Baseline's Verification and Validation Plan
Consults with CM Lead to ensure CM requirements are integrated into the V&V workflow procedures.
Ensures required V & V tools are installed and configured appropriately.
Ensures specified V & V procedures are implemented and integrated into Developers' workflows.
SS Baseline SQA Lead 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.
Ensures required SQA tools are installed and configured appropriately.
Ensures specified SQA procedures are implemented and integrated into Developers' workflows.
SS Baseline Test Lead 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.
SS Baseline Tester 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.
SS Baseline Developer 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.

Individuals may assume the mantle of more than one role during a Development cycle.

1.3 Coordination between LSST Subsystem Groups

TBD Define process for coordination between subsystems for sharing common code (not done yet) and/or interfaces (done by ICD)

1.3.1 Shared Software Interfaces

Software interfaces shared between Subsystems are strictly managed by the Interface Control Document which is the responsbility of the LSST System Engineer.

1.3.2 Shared Software

  • change control process for subsystem-shared software
  • examples of shared software
    • camera simulator developed by Camera group and used independantly by the Data Management group
    • image analyzer developed by the Data Management group and used independantly by the Telescope & Site group

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.
  • Subversion uniformly labels the repository contents in an instant of time.
  • Trac is a source configuration and change management tool used by LSST for
    • tracking and reporting on change requests neccesitated due to bugs or feature enhancements; and
    • tracking and reporting on source development resulting from those change requests.

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

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

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 .

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
TBD: Gregory notes that the traceability of processed data also needs to be defined. This is more an Operations phase requirement than a Software Development phase requirement. It may be desirable that the CM model used for the data product management conforms to what is specified now.

4.4 Project Management

Baseline Project Management provides the overarching goals, schedules, assignments, and orchestration directing a specific baseline's design, development and transfer. An BPM Plan template is provided in the Appendix.

The BPM 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.

5. Acknowledgements 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

Note: Collect Material and Requirements has been moved to http://dev.lsstcorp.org/trac/wiki/SDPDataCollection. Once each subsystem's data has been incorporated into the Subsystem specific sections in the SDP and companion Guidelines, the document will be retired.

6.1 Data Management Subsystem

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:

  • Requirements Definition
  • Analysis/Preliminary Design
  • Detailed Design
  • Implementation

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.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 (eg, 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 (eg, 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 (eg, 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 (ie, 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

Baseline Software Project Management (BPM) Plan Template

  • 1. Introduction
    • This document will primarily provide pointers to the relevant documents.
    • 1.1 Project 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 Project deliverables
    • 1.3 Evolution of the BPM Plan
    • 1.4 Reference materials
    • 1.5 Definitions and acronyms
  • 2. Project Organization
    • 2.1 Process model
    • 2.2 Organizational structure
    • 2.3 Organisational 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 (wiki ptr to monthly status reports);
        • reviews;
        • audits; (SQA audits referenced)
        • workgroup meeting summaries (wiki ptr?).
    • 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 workpackage. 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 organisation;
        • 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)

Baseline Software Transfer Plan Template

TBD Need Transfer Plan template