Software Development Plan - Model text

Each CSCI shall have an individual SDP to identify the organizations, resources, facilities, schedules, etc.

FOREWORD

1. This plan shall be used for the development of software for the name of project project;

2. Beneficial comments (additions, deletions, etc.,) on this plan will be welcome;

3. The objectives of this document are:

  1. establish the organizations
  2. identify facilities,
  3. provide the visibility of how the developer intends to meet the Standard.

CONTENTS

Include a table of contents here
Complete the SDP using Software Development Plan DID and documentation standard as a guide.
See DID list for other software documents to be prepared. 

 

Many process documents and templates are now available in .pdf format: See PDFDOCUMENTS.

1. SCOPE

1.1 Identification.

This Software Development Plan (SDP) establishes the plan for the development of CSCIs and non-deliverable software for the name of project project.

1.2 System overview.

Provide a brief summary of the system in which the software (CSCIs, etc.,) will reside.

1.3 Document overview.

This SDP has been prepared in accordance with the requirements defined in the 'Software Development Standard' to provide direction, monitoring, and surveillance during the Engineering and Management Development phase(s) of the CSCIs and non-development software for this project.
If the software for the project is to be developed in a distributed manner, this SDP will provide a common standard to be applied at each of the participating suppliers as well as to the external sub-contractors to design, develop, integrate, and test software to be used by the project.
This SDP has been prepared as demanded by the 'System/subsystem specification' and 'Statement of Work' when applicable.

1.4 Relationship to other plans.

This SDP meets the requirement as defined in the 'Systems Engineering Management plan' (SEMP) and will be used in conjunction with the 'Configuration Management Plan' (CMP), 'Technical Documentation Standard', and other speciality program plans for the management of the software development for the project.

2. REFERENCED DOCUMENTS

2.1 Standards documents.

The acquirer identified standards are listed here:

2.2 Other documents.

Identify here any project standards being provided to support this plan

2.3 Order of precedence.

In the event of conflict between the text of this SDP and its supporting documentation to the referenced documents in the above paragraphs the text of the supporting documentation shall take precedence E&OE.

2.4 Source of documents.

Copies of the Standards documents and other documents shall be available from the project library or project configuration control.

3. OVERVIEW OF THE REQUIRED WORK

3.1 Requirements and constraints - system and software.

State the type of software and any attributes e.g., safety critical, etc.

3.2 Requirements and constraints - documentation.

Documentation prepared will be in accordance with the 'Technical Documentation Standard'.

3.3 Position of the project in the system life cycle.

Identify the phase of the development life cycle the project is at the preparation or update of the SDP.

3.4 Acquisition strategy.

Specify the acquisition strategy e.g., grand design, incremental, evolutionary (see MIL-STD-498 for other strategies).

3.5 Requirements and constraints on project schedules and resources.

3.6 Other requirements and constraints.

4. SOFTWARE ENGINEERING

4.1 Software development process.

The software development process will be in accordance with MIL-STD-498.

4.1.1 Build strategy.

An incremental build strategy will be employed.

4.1.1.1 Deliverable software.

4.1.1.2 Procured software.

4.1.1.3 Non-development software.

4.1.2 Activities.

4.1.3 Objectives.

4.2 General plans for software development.

The plans for software development are

4.2.1 Software development techniques and methodologies.

As defined in the SDS the system/software life cycle comprises of a number of phases. See system/software life cycle
In general, substantial overlap between these activities will be necessary to accommodate the use of structured analysis and design methodology which will employ an incremental, iterative approach to analysis, design, coding, integration and testing.
The following lists the deliverable documents:

Once the SDP has been released, the software development manager shall be responsible for preparing a monthly status report and forwarding it to systems engineering management. The status report shall include a schedule identifying the baseline plan, progress, and plan to completion.
It will also include a summary of the management indicators, including:

If this is no significant deviation from the baseline plan (Engineering Program Plan), it will also include a variance analysis and a list of planned corrective actions. The status report will also include "lessons learned" and process feedback when available.
Memory utilization budgets will be kept current and included in the monthly provided status reports. Defect tracking information (metrics), including the number of defects, defect rate, time between failures. and time to repair will be included in the status reports once the job has entered the coding phase.

4.2.2 Standards for software products.

The code of practice, work instructions, and any clarifications and restrictions applicable to the methods and tools chosen for the project shall be defined in the Software Engineering Manual. Documentation being prepared for the project shall be in accordance with the 'Technical Documentation Standard'. The following identifies details guide-lines for the software products:

4.2.2.1 Software development files.

Software Development Files (SDF) shall be used to record, monitor and control activities during the detailed design, software unit coding and testing phases of the software development. The software engineering personnel shall create an on-line SDF for every Software Unit, aggregates of units, and CSCI being developed for the project.
The SDFs shall provide a centralized and accessible collection of data pertaining to the requirements, design data, schedules, coding, and testing of software units and aggregates of units. These SDFs will be used for progress assessment and quality control by software management.
In particular, SDFs shall be used to incrementally collect the requirements data, design data, informal test data, and audit data for all the planning and data files that comprise the Software Units and aggregates of Software Units.
Each SDF shall contain information that is relevant to the software units development, either directly or by reference, providing a uniform and visible collection point for all data and code. An example on the contents of SDFs are provided in the 'Documentation Standard'.
SDF will be opened when the associated component enters detailed design.

4.2.2.2 Design standards.

A structured design approach will result in the following:

To be continued

4.2.2.3 Coding standards.

All deliverable source code shall be developed in HOL Language and will conform to the coding standards defined in the Software Engineering Manual.

4.2.2.4 Safety critical software standards.

All software identified as safety critical will be developed using DEF STAN 00-55 as guidance.

4.3 Non-development software.

Software designed and developed for testing, simulation, support, etc., of the deliverable software will be produced using the same plans and procedures with the exception that an alternate coding language, design language, method or tools may be approved.
All documentation shall be prepared, changed or revised in accordance with the 'Software Documentation Standard'.
However the Software Configuration Management and Software Product Evaluation shall be performed in accordance with this SDP.

5. SOFTWARE DEVELOPMENT ACTIVITIES

This section contains the plans for performing detailed software development activities.

5.1 Project planning and oversight.

Details of the overall software requirement for the project, that is, deliverable software, non-development software, etc., will be identified and any build strategy defined or discussed.

5.1.1 Software development planning.

The initial issue and any subsequent revision will be presented to the acquirer for his approval.

5.1.2 CSCI test planning.

A Software Test Plan (STP) will be prepared in accordance with the STP data item description. The STP will describe the various aspects of CSCI test planning including the CSCI test environment definition, personnel, test identification, test schedules, and test traceability to software requirements.

5.1.3 System test planning.

System test planning should be documented in a 'System Test Plan' in accordance with the 'Systems Engineering Management Plan'.

5.1.4 Software installation planning.

5.1.5 Software transition planning.

5.1.6 Following and updating plans, including the intervals for management review.

All software plans prepared are intended to be "living' documents and as such revisions will be prepared with the latest estimated information.

5.2 Establishing a software development environment.

5.2.1 Software engineering environment.

The following shall provide a description of the plan to establish the hardware, and software resources necessary to perform the software engineering activities.

5.2.1.1 Software items.

5.2.1.2 Hardware items.

5.2.1.3 Propriety nature and acquirer rights.

5.2.1.4 Installation, control, and maintenance.

5.2.2 Software test environment.

5.2.3 Software development library.

Pment library will be implemented to store and archive oaa software items, supporting files, test result files, and documentation created during the software development life cycle.

The library will be maintained by the configuration controller, and will include:

5.2.2 Software development files.

Software development files will be maintained

5.2.2 Non-deliverable software.

Non-deliverable software will be developed when necessary to the process defined in MIL-STD-498.

5.3 System requirements analysis.

System requirements analysis will be performrd in accordance with the tasks defined in the Technical Management Plan.

5.3.1 Analysis of user input.

5.3.2 Operational concept.

5.3.3 System requirements.

5.4 System design.

5.4.1 System-wide design decisions.

5.4.2 System architectural design.

5.5 Software requirements analysis.

5.6 Software design.

5.6.1 Preliminary design.

5.6.2 Detailed design.

5.7 Software implementation and unit testing.

5.8 Unit integration and testing.

5.9 CSCI qualification testing.

5.10 CSCI/HWCI integration and testing.

5.11 System qualification testing.

5.11.1 Organizational and resources - formal qualification testing.

5.11.1.1 Organizational structure - formal qualification testing.

5.11.1.2 Personnel - formal qualification testing.

See Job descriptions for personnel.

5.11.2 System test approach/strategy.

System level testing will be the joint responsibility of systems engineering and an independent quality assurance authority. The software shall have been formally released from configuration control with support from software engineering when necessary. The purpose of system level testing is to verify that all the integrated hardware and software (subsystems) meets the system/subsystem requirements specified in the system subsystem specification(s).

5.12 Preparing for software use.

5.13 Preparing for software transition.

5.14 Software configuration management.

5.14.1 Organizational and resources - configuration management.

5.14.1.1 Organizational structure - configuration management.

An illustration of the organizational structure is provided by Software Configuration Management structure.

Software Configuration Management (SCM) shall be provided on an as needed basis. It should have an independent reporting chain through to the Technical Director of a supplier.

5.14.1.2 Personnel - configuration management.

See Job descriptions for personnel.

5.14.2 Configuration identification.

The remaining part of this paragraph may be documented separately in a  Software Configuration Management Plan.

5.14.2.1 Developmental configuration identification.

As the software development life cycle progresses the software design descriptions will be reviewed and entered into the developmental configuration. All changes to these documents shall be controlled by formal change methods.
The following provides a minimum list of documents to be entered into the developmental configuration:  

The developmental configuration shall be established by the first engineering release of the software design description (top-level) prior to submission to the 'Preliminary Design Review'.
Note: other associated documents (test, management data items) shall be controlled in accordance with the document control procedures defined in the 'System Engineering Management Plan'. Choosing to many documents for configuration control can create more problems than too few as visibility of the priorities can be lost and bureaucracy starts to rule.

5.14.2.2 Identification methods.

A common method of identifying documents and software units is necessary.

Under construction.

5.14.3 Configuration control.

5.14.4 Configuration status accounting.

5.14.5 Configuration audits.

5.14.6 Preparation for specification authentication.

5.14.7 Configuration management major milestones.

5.15 Software product evaluation.

5.15.1 Organizational and resources - software product evaluations.

See Software Product Evaluation Plan

5.15.1.1 Organizational structure - software product evaluations.

See software product evaluation illustration.

Software product evaluations should be performed by the SMG, however, members of a 'Software Engineering' department, who have not been assigned to the program may be used to provide technical support on an as needed basis to assure that evaluations have an adequate level of technical depth.
Under construction.

5.15.1.2 Personnel - software product evaluations.

See Job descriptions for personnel.

5.15.2 Software product evaluation procedures and tools.

5.15.2.1 Procedures.

5.15.2.2 Tools.

5.15.3 Subcontractor products.

5.15.4 Software product evaluation records.

5.15.5 Activity-dependent product evaluations.

5.16 Software quality assurance.

5.16.1 Organizational and resources - software quality assurance.

5.16.1.1 Organizational structure - software quality assurance.

5.16.1.2 Personnel - software quality assurance.

See Job descriptions for personnel.

5.16.2 Software quality assurance procedures and tools.

5.17 Corrective action.

A closed loop corrective action system for problems detected during software development will be established to ensure that detected problems are promptly reported, action taken and a resolution reached. The status of these problems shall be monitored, tracked and reported. All records prepared will be maintained for the life of the project.
The corrective action system operates by the raising of various types of reports:

Each problem shall be classified by category and by priority as identified by the acquirer.
Metrics and analysis shall be performed to detect trends in the problems reported.

5.17.1 Action item process.

When an audit or review report identifies defects it shall initiate the corrective action process.
Problems detected shall be identified and an action placed on individuals to correct within a specified time limits.
TBC

5.17.2 Problem/change report process.

5.17.3 Document change request process.

5.17.4 ECP/SCN change process.

5.18 Joint technical and management reviews.

5.18.1 Work Reviews.

Group leaders will conduct work reviews to ensure work products identified in the worksheet are reviewed prior to process management reviews. Guidance for conducting work reviews is provided in the 'Software Product Evaluation Plan'. Each work review is documented showing attendees, issues, and action items.

Software Process/Product Assurance Reviews .

The Software Product Evaluation Reviews will review the project's software work products and activities periodically throughout the life-cycle based on the Worksheet and SQPP plan and provide the project manager with visibility as to whether the project is adhering to established plans, standards, and procedures.

5.19 Other software development activities.

5.19.1 Risk management.

The project will generate potential problems, both technical and managerial. These problems are the starting point for addressing circumstances and events which may put the project at risk. That is, each problem contains the potential for bringing about unwanted changes (losses) in the technical performance, schedule, and cost of a project and must therefore be managed.

Potential problems the project will be translated into specific identifiable known risks which will be analyzed, documented, and prioritized based on their potential impact to the project. Risk identification is an iterative process that starts at the beginning of and continues throughout the project. As potential problems are identified, a risk management working group, established by the IPT manager, will analyze each problem and identify it, as appropriate, as a known risk to the project. The risk will be further analyzed to determine the best strategy for reducing the effects of or eliminating the risk altogether. The IPT manager will prioritize each risk and assign a risk owner to develop a brief plan of action for eliminating the risk or reducing its effects on the project.

From the very beginning of the project, the IPT manager will identify the top 1, 2, or X number of risks for a monthly review by the risk management working group. A formal update of the prioritized list of risks, their assessment (e.g., this risk , if not corrected in the next 90 days, will cause a work stoppage), actions underway to mitigate the risk (e.g., re-prioritize work), and the expected get-well dated. Risk management metrics (e.g. the number of technical and managerial risk identified according to their impacts, i.e., schedule, cost, and technical performance) will be updated during the Update Indicator stage of the SEMP process and briefed at the management review for each process.

See Risk management details

5.19.2 Software management indicators.

Another name for software management indicators is metrics. For direction on metrics to be used during development and maintenance projects, see the following:

Metrics will be collected on the project for three purposes. The first purpose is to measure the progress of each project to ensure completing software projects within budget, on schedule, with quality software products delivered to the users. The goals for software projects inherently lead to questions such as: Have we baselined the requirements? Have we baselined our schedule? Can we meet the schedule? Will the quality of the software be acceptable to our customers? How are we identifying, tracking, and correcting errors?

A second purpose for collecting metrics is to establish a historical, factual basis for planning future activities. Accordingly, each team will collect a set of metrics having the five core attributes. These attributes are size, effort, schedule, rework, and quality, and are discussed in detail in the 'Systems Engineering Management Plan'.

A third purpose for collecting metrics is to improve processes through increased process knowledge. As processes are measured, a factual basis for assessing how well processes are performing is established and opportunities for taking corrective actions are made more visible. Once corrective actions are taken, metrics will be used to verify that the corrective actions are yielding the desired results.

Metrics Collected

The following table identifies metrics with the five core attributes that are gathered throughout the development project and indicates the data stores and sources.

TBD

Metrics Analysis and Interpretation

a. In addition to the analysis and interpretation of metrics at the project level by the Project manager and Configuration Manager, sections perform their own metrics analysis using, e.g., variances between the actual Vs planned number of SUs produced. Each section will seek to identify problems early in the development phase of each project. Group leaders will assess their progress on a weekly basis and if at the end of the week, the actual number of SUs completed is 90 percent or less than what was planned, the Group leaders will begin to monitor production activity more closely. If after two or more weeks, the actual number of SUs completed continues to be 90 percent or less than what was planned and the trend appears to be worsening, the Group leader will determine the cause for the slow down and take corrective action. For example, if specifications are missing or inadequate, the Group leader take needed corrective action and track the progress made in delivering on-time, quality specifications within the production cycle until the production level is returned to the original plan.

Release Quality Assessment

Following the release of software to the users, the Software Manager will track the number of corrective actions initiated against the software. This metric is identified in the first table above under the quality attribute. This metric is stored in the MIS. Another metric using the Error reports count is called the Release Error reports Density. The Release Error reports Density is calculated by dividing the number of Error reports received in the first six months after the software is released by the number of thousand source lines-of-code (i.e., KSLOC) contained in the release. This metric is maintained in Software Manager and by the Configuration Manager.

Project Deliverables

In contracting out software development, deliverables are specified and tracked throughout the project cycle. Although there is no formal contractual arrangement for software developed in-house, deliverables will also be specified and tracked throughout the project cycle. Examples of deliverables are:

Modified programs, test reports, documentation

Estimating Project Variables

Probably one of the most difficult tasks in building metrics is the task of estimating project variables. Two important factors in estimating project variables are documented procedures and a factual basis for deriving the estimates. The SEMP provides documented procedures for estimating project size and schedules. The Pre-Development Phase. A factual basis for deriving the estimates, for example, are found in documented software histories stored in archives

All estimates are documented to the level of detail that readily identifies the procedures used and the factual basis on which the estimate is based.

Attachment 1: Example Metrics Charts.

TBD

See Software management indicator details

5.19.3 Security and privacy.

See Security and privacy details

5.19.4 Supplier management.

When applicable, subcontractor management will be performed in accordance with the procedures described in the 'Systems Engineering Management Plan' section 3.

See Supplier management details

5.19.5 Interface with software independent verification and validation (IV & V) agents.

See IV & V interface details

5.19.6 Coordination with associate developers.

See Coordination with associate developers details

5.19.7 Improvement of project processes.

See Improvement of project processes details

5.19.8 Software safety management.

See Software safety management details

5.19.9 Other activities not covered elsewhere in the plan.

6. SCHEDULES AND ACTIVITY NETWORK

6.1 Schedule activities.

The activities and documentation to be prepared for the completion of each phase of the system/software development life cycle is detailed in the 'Software Development Standards'.
If the system comprises of a number of CSCIs it will be necessary to provide individual SDPs which will detail all the activities and support documentation to be prepared in accordance with the sample model text contained in the 'Documentation Standard'.

6.1 Activities.

This paragraph shall detail activities necessary during the software development life cycle.
The activities to be performed and the documentation prepared for the completion of each phase of the software development life cycle are identified in the 'Software Development Standards'.
If the system comprises of a number of CSCIs it will be necessary for the suppliers of each CSCI or aggregate of a CSCI to prepare individual SDPs. Each SDP will detail all activities and support documentation necessary for that specific CSCI in accordance with the model text included in the 'Software Documentation Standard'.

The activity network for the CSCI development will be provided in the following format:

Under construction.

6.2 Activity network.

An activity network, depicting sequential relationships and dependencies among activities and identifying those activities that impose the greatest time restrictions on the project shall be contained here.

7. SOFTWARE DEVELOPMENT MANAGEMENT

7.1 Project organization.

The overall responsibility for the project shall be with the project manager who will use the concepts and principles defined in the 'Systems Engineering Management Plan' to provide direction, monitor and control the technical system being engineered.
He shall delegate to other managers the responsibility of managing subsystems and their comprising hardware and software.
A Software Management Group shall be established to prepare, monitor, control, maintain and administer the 'Software Development Standards' contractually required for the project.
Software development and test for the system software shall be the responsibility of a Software Development Manager assigned to the project. The Software Development Manager should report directly to the Project Manager. His role will be to ensure that the software engineering meets the required level of quality. Depending on the complexity a number of software development engineers and software test engineers will be appointed.

The software development manager shall be responsible for managing and controlling the CSCI requirements analysis, design, coding, informal test and integration of all deliverable code for a specific CSCI.
project manager organization

Project manager organization.

Under construction!

7.1.1 Organizational structures.

The Technical Management organization for the production of system software shall be the responsibility of the Systems Engineering Management group (SEMG). The relevant approval and authorization shall be required before the release of any project-level software or documentation prepared during the development of the system using the data management procedures identified in the SEMP. The SEMG shall act as the interface with the managerial organizations of the acquirer or his agent for the subjects of project management.
While the SEMG retains overall technical responsibility for software development, responsibility for the individual phases will be defined in individual SDPs.
Software development and test for the system shall be the responsibility of the Project Manager who shall assign personnel to the subsystem and CSCI elements of the system. The

Systems Engineering Management organization

Systems Engineering organization.

software development management organization

Software development manager organization.

To be continued.

7.2 Project resources.

The facilities that will be used for supporting the activities associated with the development of the CSCIs for the system shall be defined in the individual CSCI development plan.
Resources required to support the overall activities are:

7.2.1 Personnel resources.

As defined in the 'Software Development Standards' (SDS), a Software Standards Controller (SSC) shall be appointed to be responsible for adherence to the agreed plan.
The person appointed shall have the necessary qualifications and experience.

See Job descriptions for personnel.

Also, a Software Configuration Controller shall be appointed to be responsible for the adherence to the software configuration aspects of the project.

7.2.2 Developer facilities.

Development facilities are as follows:

7.2.3 Acquirer furnished equipment, software, and services.

7.2.4 Other required resources.

8. NOTES

(This Section contains information of a general or explanatory nature that may be helpful, but is not mandatory).

8.1 Definitions.

List any definitions that will add clarity to the document that have been used and not previously declared or are different from the declared references.
A list of definitions are provided in the glossary for the Project Management System.

8.2 Abbreviations.

List the abbreviations used and not previously declared.

8.3 Changes from previous issue.

Not applicable for the first issue, however, subsequent revisions will require a notation e.g., (|) in the margins of the lines that have been modified. 

 

 

Many process documents and templates are now available in .pdf format: See PDFDOCUMENTS.


LE FastCounter

The total number of visitors to this site since the 15th of March 1998
LE FastCounter

Back to Home page MANAGING STANDARDS Home page

Please send any beneficial comments or identification of errors using the following form to: kenr@wysywig.airtime.co.uk

Copyright © by Ken Rigby 1995, 1996. 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004