# Software Development Plan: [System or project name]

> Software Development Plan (SDP) describing how a developer will carry out
> a software development effort: the process, methods, standards, detailed
> plans for each activity, schedule, organisation and resources. The
> section numbering follows the MIL-STD-498 Data Item Description
> DI-IPSC-81427 (Software Development Plan, 5 December 1994; public
> domain), and the activities are cross-referenced to the software life
> cycle processes of ISO/IEC/IEEE 12207:2017. Replace every `[bracketed]`
> value and every row marked *Example*.

<!--
Guidance: How to use this template
- The SDP is the acquirer's window into how you will work. Write what the
  team will actually do, with named tools, standards and review points,
  not a copy of a generic process manual.
- Keep the DID numbering. If a paragraph does not apply, keep the heading
  and write "This paragraph has been tailored out." or "Not applicable."
  with a one-line reason, as the DID allows.
- Each activity paragraph should say the approach (methods, procedures,
  tools), how results are recorded, which deliverables are produced, and
  the risks and how they are handled.
- Agile delivery fits this structure: describe increments as builds,
  backlog refinement under requirements analysis, and the definition of
  done under product evaluation and quality assurance.
- Update the SDP when the plan changes (see 5.1.6) and keep it under
  configuration control like any other product.
-->

## Document control

<!-- Guidance: Title page data required by the DID: document number, version, date, system identifiers, contract and CDRL numbers, preparing organisation and distribution statement. -->

| Field | Value |
|---|---|
| Document number | [SDP-PROJECT-001] |
| Title | Software Development Plan for [System name] |
| Version / revision | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| System identifier | [System name, abbreviation, ID] |
| Contract number | [Contract no. or internal project code] |
| CDRL item | [A001 or "Not applicable"] |
| Prepared for | [Acquirer or sponsoring organisation] |
| Prepared by | [Developer organisation, address] |
| Author | [@author] |
| Distribution | [Distribution statement or "Internal"] |
| Security / handling | [Classification or handling restrictions] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Organisation | Decision | Date |
|---|---|---|---|---|
| Software project manager | [@name] | [Developer] | [Approved] | YYYY-MM-DD |
| Chief engineer / architect | [@name] | [Developer] | [Approved] | YYYY-MM-DD |
| Quality assurance lead | [@name] | [Developer] | [Approved] | YYYY-MM-DD |
| Acquirer representative | [@name] | [Acquirer] | [Approved / Comments] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record every approved change. Major plan changes (new build, new subcontractor, changed process) require re-approval. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft for proposal |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved at contract kick-off |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Build 3 split into 3a and 3b; schedule in section 6 updated |

## Contents

<!-- Guidance: Keep in sync with headings. -->

1. [Scope](#1-scope)
2. [Referenced documents](#2-referenced-documents)
3. [Overview of required work](#3-overview-of-required-work)
4. [Plans for performing general software development activities](#4-plans-for-performing-general-software-development-activities)
5. [Plans for performing detailed software development activities](#5-plans-for-performing-detailed-software-development-activities)
6. [Schedules and activity network](#6-schedules-and-activity-network)
7. [Project organisation and resources](#7-project-organisation-and-resources)
8. [Notes](#8-notes)
9. [Appendixes](#appendixes)
10. [Standard and licence note](#standard-and-licence-note)

## 1. Scope

<!-- Guidance: Identify the system and software, summarise the system, describe this document and relate it to other plans. -->

### 1.1 Identification

This plan applies to [System name] ([abbreviation]), identifier [ID],
version [x.y], and to the following software items:

| Software item | Abbreviation | Identifier | Planned release |
|---|---|---|---|
| *Example:* Mission planning server | MPS | CSCI-01 | 2.0 |
| *Example:* Operator workstation client | OWC | CSCI-02 | 2.0 |
| *Example:* Data exchange gateway | DXG | CSCI-03 | 1.0 |
| [Item] | [Abbr.] | [ID] | [Release] |

### 1.2 System overview

[System name] [purpose in two or three sentences]. It is sponsored by
[sponsor], acquired by [acquirer], used by [users], developed by
[developer] and will be supported by [support agency]. It operates at
[current and planned sites].

*Example:* The system lets regional dispatch centres plan and track field
crews. Version 1 has been in service since 2022 at three centres; this
effort replaces the desktop client with a web client and adds a gateway to
the national incident system, for roll-out to nine centres.

### 1.3 Document overview

This document sets out the developer's plans for the software development
effort. Sections 3 to 7 cover the work, general and detailed activity
plans, schedules and resources. [State any security or privacy
considerations for using this document, for example: contains staffing
data, internal distribution only.]

### 1.4 Relationship to other plans

| Plan | Relationship |
|---|---|
| *Example:* Project management plan PMP-01 | SDP implements the software part of the PMP; PMP holds cost and contract milestones |
| *Example:* Software configuration management plan SCMP-01 | Bound separately; summarised in 5.14 |
| *Example:* Software quality assurance plan SQAP-01 | Bound separately; summarised in 5.16 |
| *Example:* Software test plan STP-01 | Detailed qualification test planning; summarised in 5.9 |
| *Example:* Software transition plan STrP-01 | Detailed transition planning; summarised in 5.13 |
| [Plan] | [Relationship] |

## 2. Referenced documents

<!-- Guidance: List number, title, revision and date of every referenced document, and where to obtain documents that are not publicly available. -->

| Number | Title | Revision | Date | Source |
|---|---|---|---|---|
| *Example:* [Contract no.] | Statement of work | Rev B | YYYY-MM-DD | Acquirer |
| *Example:* SSS-01 | System/Subsystem Specification | 1.2 | YYYY-MM-DD | Project repository |
| ISO/IEC/IEEE 12207:2017 | Systems and software engineering, Software life cycle processes | 2017 | 2017 | ISO / IEEE |
| [Number] | [Title] | [Rev] | YYYY-MM-DD | [Source] |

## 3. Overview of required work

<!-- Guidance: Give the context for the planning in later sections. Cover each item a to f from the DID: requirements and constraints on the system and software, on documentation, position in the life cycle, acquisition strategy, schedule and resource constraints, and other constraints. -->

| Area | Overview |
|---|---|
| Requirements and constraints on the system and software | *Example:* 214 system requirements in SSS-01; availability 99.9%; must run on the acquirer's private cloud |
| Requirements and constraints on documentation | *Example:* Deliver SRS, SDD, STP, STR, SVD, SUM and STrP in developer format via the document portal |
| Position in the system life cycle | *Example:* Upgrade of a fielded system; development and transition phases |
| Acquisition strategy | *Example:* Fixed-price for builds 1 and 2, option for build 3; incremental delivery |
| Schedule and resource constraints | *Example:* Initial operational capability at three centres by YYYY-MM-DD; team capped at 14 FTE |
| Other constraints | *Example:* Personal data under GDPR; security accreditation before go-live; interface with national incident system owned by another contractor |

## 4. Plans for performing general software development activities

<!-- Guidance: Describe the overall process and the general plans that apply to all activities. For each paragraph, also note risks and uncertainties and how they will be handled. -->

### 4.1 Software development process

The project uses an [incremental / iterative / agile with builds] life
cycle. Each build delivers working, qualified software for a defined set
of requirements.

| Build | Objective | Activities in build | Planned end |
|---|---|---|---|
| Build 1 | *Example:* Core planning server and minimal web client | Requirements, design, implementation, unit and integration test | YYYY-MM-DD |
| Build 2 | *Example:* Full client, reporting, data migration | All activities including CSCI qualification test | YYYY-MM-DD |
| Build 3 | *Example:* Gateway to national incident system, transition | All activities including system qualification, installation and transition | YYYY-MM-DD |

Within each build, work runs in [two-week] iterations with backlog
refinement, review and retrospective. Process activities map to the
technical processes of ISO/IEC/IEEE 12207 (requirements, architecture,
design, implementation, integration, verification, transition, validation)
and its management and support processes.

Risk: *Example:* gateway interface definition depends on another
contractor; mitigated by an interface control working group from month 1.

### 4.2 General plans for software development

These plans apply across all activities in section 5.

#### 4.2.1 Software development methods

| Activity | Method | Tools |
|---|---|---|
| Requirements | *Example:* Use cases and user stories with acceptance criteria; requirement IDs traced to SSS | [Requirements tool] |
| Design | *Example:* Component-based design, C4 diagrams, architecture decision records | [Modelling tool], Markdown in repository |
| Implementation | *Example:* Trunk-based development, pull requests with two reviewers | [Git hosting], [IDE] |
| Testing | *Example:* Test pyramid: unit, contract, integration, end-to-end | [Test frameworks], [CI server] |

#### 4.2.2 Standards for software products

| Product | Standard |
|---|---|
| Requirements | *Example:* Requirement template with ID, statement, rationale, priority, verification method |
| Design | *Example:* Design description template; ADR format |
| Code | *Example:* Language style guides enforced by formatter and linter in CI |
| Test cases and procedures | *Example:* Test case template with ID, requirement, preconditions, steps, expected result |
| Test results | *Example:* Machine-readable reports archived per build |

Coding standards cover, for each language: formatting, header and other
comments, naming conventions, restricted language constructs and limits on
complexity (*Example:* cyclomatic complexity no greater than 15 per
function, enforced by static analysis).

#### 4.2.3 Reusable software products

##### 4.2.3.1 Incorporating reusable software products

Candidate reusable products (open-source libraries, commercial
components, existing project code) are evaluated against [criteria:
licence, maintenance activity, security record, fitness, cost] and
recorded in the reuse register.

| Product | Version | Use | Benefits | Drawbacks / restrictions | Decision |
|---|---|---|---|---|---|
| *Example:* PostgreSQL | 16.x | Main database | Mature, known to support team | Requires DBA skills at support site | Selected |
| *Example:* Map rendering library | 3.x | Client maps | Saves an estimated 4 months | Licence requires attribution | Selected |
| [Product] | [Version] | [Use] | [Benefits] | [Drawbacks] | [Decision] |

##### 4.2.3.2 Developing reusable software products

Opportunities for reuse are identified during design reviews and reported
to [the acquirer / the organisation's reuse board]. *Example:* the
gateway's message validation module will be packaged as a separate
library.

#### 4.2.4 Handling of critical requirements

Critical requirements are tagged in the requirements tool and receive
extra analysis, review and test.

##### 4.2.4.1 Safety assurance

[Approach, or "Not applicable" with reason.] *Example:* No safety-critical
functions; hazard analysis HA-01 confirmed no software contribution to
identified hazards.

##### 4.2.4.2 Security assurance

*Example:* Threat modelling per build, secure coding standard, dependency
and container scanning in CI, independent penetration test before
accreditation.

##### 4.2.4.3 Privacy assurance

*Example:* Data protection impact assessment, data minimisation in design
reviews, personal data fields tagged in the data dictionary, test data
anonymised.

##### 4.2.4.4 Assurance of other critical requirements

*Example:* Availability requirement SSS-AV-01 (99.9%) verified by
failover tests and a 72-hour soak test.

#### 4.2.5 Computer hardware resource utilisation

Resource budgets (CPU, memory, storage, network) are allocated per
component in the design and monitored in performance tests with a
reserve target of [30%] at forecast peak.

#### 4.2.6 Recording rationale

Key decisions (architecture style, major technology choices, deviations
from standards, interface agreements) are recorded as architecture
decision records in [repository path] so that the support agency can
understand why the software is built as it is.

#### 4.2.7 Access for acquirer review

The acquirer has read access to the repository, issue tracker, CI results
and document portal, and may attend iteration reviews and visit
[developer and subcontractor sites] with [5 working days'] notice.

## 5. Plans for performing detailed software development activities

<!-- Guidance: For each activity give the approach (methods, procedures, tools), how results are recorded, the deliverables, and risks. Reference 4.2.1 where methods are already described. Use "Not applicable" where an activity is not required. -->

### 5.1 Project planning and oversight

| Sub-paragraph | Approach |
|---|---|
| 5.1.1 Software development planning | *Example:* This SDP is prepared by the software PM, reviewed by QA and the acquirer, and updated at each build start |
| 5.1.2 CSCI test planning | *Example:* STP-01 prepared during build 1 design; covers qualification of each CSCI |
| 5.1.3 System test planning | *Example:* Developer participates in the acquirer's system test plan; provides test cases for software-related requirements |
| 5.1.4 Software installation planning | *Example:* Software installation plan for the three pilot centres prepared in build 3 |
| 5.1.5 Software transition planning | *Example:* STrP-01 drafted in build 2, final at build 3 test readiness review |
| 5.1.6 Following and updating plans | *Example:* Weekly progress review, monthly management review with acquirer; plans updated through change control |

### 5.2 Establishing a software development environment

| Sub-paragraph | Approach |
|---|---|
| 5.2.1 Software engineering environment | *Example:* Containerised developer environment; CI pipeline on [CI server]; same toolchain versions pinned in repository |
| 5.2.2 Software test environment | *Example:* Integration and qualification environments built from infrastructure code, refreshed per build |
| 5.2.3 Software development library | *Example:* Git repository with protected main branch and tagged baselines; artefact registry for builds |
| 5.2.4 Software development files | *Example:* Each component has a folder for design notes, test results and review records, linked from the issue tracker |
| 5.2.5 Non-deliverable software | *Example:* Test harnesses and data generators, kept in the repository; licences checked so the acquirer is not burdened |

### 5.3 System requirements analysis

| Sub-paragraph | Approach |
|---|---|
| 5.3.1 Analysis of user input | *Example:* Workshops at two centres; feedback from version 1 support tickets |
| 5.3.2 Operational concept | *Example:* Developer contributes scenarios to the acquirer's operational concept description |
| 5.3.3 System requirements | *Example:* Developer reviews SSS-01 and proposes clarifications through the requirements working group |

### 5.4 System design

| Sub-paragraph | Approach |
|---|---|
| 5.4.1 System-wide design decisions | *Example:* Participate in decisions on hosting, identity provider and interface protocols; record as ADRs |
| 5.4.2 System architectural design | *Example:* Contribute the software view to the system architecture description |

### 5.5 Software requirements analysis

Software requirements for each CSCI are derived from the system
requirements and recorded in the software requirements specification
with IDs, priority, verification method and trace to SSS. *Example:*
backlog refinement each iteration turns approved requirements into user
stories with acceptance criteria; the trace is checked by QA at each
build review.

### 5.6 Software design

| Sub-paragraph | Approach |
|---|---|
| 5.6.1 CSCI-wide design decisions | *Example:* Language, frameworks, error handling and logging conventions per CSCI, recorded as ADRs |
| 5.6.2 CSCI architectural design | *Example:* Component and deployment views in the software design description |
| 5.6.3 CSCI detailed design | *Example:* Interface and data design for each component, reviewed in pull requests before code |

### 5.7 Software implementation and unit testing

| Sub-paragraph | Approach |
|---|---|
| 5.7.1 Software implementation | *Example:* Code written to 4.2.2 standards, reviewed by two engineers |
| 5.7.2 Preparing for unit testing | *Example:* Unit tests written with or before code; coverage target 80% lines |
| 5.7.3 Performing unit testing | *Example:* Run on every commit in CI |
| 5.7.4 Revision and retesting | *Example:* Failing tests block merge |
| 5.7.5 Analysing and recording unit test results | *Example:* Results and coverage archived per build in the artefact registry |

### 5.8 Unit integration and testing

| Sub-paragraph | Approach |
|---|---|
| 5.8.1 Preparing for unit integration and testing | *Example:* Contract tests for every internal API; integration test cases derived from design |
| 5.8.2 Performing unit integration and testing | *Example:* Nightly integration runs in the integration environment |
| 5.8.3 Revision and retesting | *Example:* Defects raised in the tracker and retested before closure |
| 5.8.4 Analysing and recording results | *Example:* Trend dashboard of integration pass rate reviewed weekly |

### 5.9 CSCI qualification testing

| Sub-paragraph | Approach |
|---|---|
| 5.9.1 Independence | *Example:* Qualification tests designed and run by the test team, not by the developers of the CSCI |
| 5.9.2 Testing on the target computer system | *Example:* Run on acquirer-equivalent cloud environment |
| 5.9.3 Preparing | *Example:* Test cases and procedures in STP and STD, reviewed at test readiness review |
| 5.9.4 Dry run | *Example:* Full dry run one week before formal run |
| 5.9.5 Performing | *Example:* Formal run witnessed by acquirer |
| 5.9.6 Revision and retesting | *Example:* Regression of affected test cases after fixes |
| 5.9.7 Analysing and recording results | *Example:* Software test report per CSCI |

### 5.10 CSCI/HWCI integration and testing

[Approach for integrating software items with hardware items, or "Not
applicable" with reason.] *Example:* Participate in integration with
centre workstations and radio gateway hardware; preparing, performing,
retesting and recording follow the pattern of 5.8.

### 5.11 System qualification testing

The developer participates in system qualification testing run by
[acquirer / system integrator]. Independence, use of the target system,
preparation, dry run, performance, retesting and recording follow the
pattern of 5.9, with the system test plan as the governing document.

### 5.12 Preparing for software use

| Sub-paragraph | Approach |
|---|---|
| 5.12.1 Preparing the executable software | *Example:* Signed container images built by CI from tagged baselines |
| 5.12.2 Preparing version descriptions for user sites | *Example:* Software version description per release |
| 5.12.3 Preparing user manuals | *Example:* Software user manual for operators, updated each build |
| 5.12.4 Installation at user sites | *Example:* Install and check out at three pilot centres; train local administrators |

### 5.13 Preparing for software transition

| Sub-paragraph | Approach |
|---|---|
| 5.13.1 Preparing the executable software | *Example:* Same signed images as for user sites |
| 5.13.2 Preparing source files | *Example:* Source repository mirror with build scripts delivered to support agency |
| 5.13.3 Preparing version descriptions for the support site | *Example:* SVD including build environment and tool versions |
| 5.13.4 Preparing as-built design and support information | *Example:* Updated SDD and ADR log reflecting the delivered code |
| 5.13.5 Updating the system design description | *Example:* Software changes reflected in system design description |
| 5.13.6 Preparing support manuals | *Example:* Support manual for build, deploy and diagnose |
| 5.13.7 Transition to the designated support site | *Example:* Per STrP-01, with two months of joint support |

### 5.14 Software configuration management

| Sub-paragraph | Approach |
|---|---|
| 5.14.1 Configuration identification | *Example:* Configuration items listed in SCMP; semantic versioning |
| 5.14.2 Configuration control | *Example:* Change control board weekly; pull request approvals for code |
| 5.14.3 Configuration status accounting | *Example:* Release notes and baseline reports generated from tracker |
| 5.14.4 Configuration audits | *Example:* Functional and physical audits before each delivery |
| 5.14.5 Packaging, storage, handling and delivery | *Example:* Signed artefacts in registry; delivery via secure transfer with checksums |

### 5.15 Software product evaluation

| Sub-paragraph | Approach |
|---|---|
| 5.15.1 In-process and final evaluations | *Example:* Peer review of every requirement, design and code change; final evaluation at build review |
| 5.15.2 Evaluation records | *Example:* Review comments, decisions and disposition stored with the pull request or document |
| 5.15.3 Independence | *Example:* Final evaluations by a reviewer not involved in producing the product |

### 5.16 Software quality assurance

| Sub-paragraph | Approach |
|---|---|
| 5.16.1 SQA evaluations | *Example:* Monthly process audits against this SDP; product audits at each build review |
| 5.16.2 SQA records | *Example:* Audit reports and non-conformance log |
| 5.16.3 Independence | *Example:* QA lead reports to the quality manager, not to the project manager |

### 5.17 Corrective action

| Sub-paragraph | Approach |
|---|---|
| 5.17.1 Problem/change reports | *Example:* Tracker records ID, originator, item affected, date, category, priority, description, analyst, solution, impacts, status, approval, version corrected |
| 5.17.2 Corrective action system | *Example:* Triage twice weekly; trend analysis monthly; root cause for priority 1 and 2 problems |

### 5.18 Joint technical and management reviews

| Review | Type | When | Participants | Entry / exit criteria |
|---|---|---|---|---|
| *Example:* Software requirements review | Technical | End of requirements in build 1 | Developer, acquirer, users | SRS draft complete / requirements baselined |
| *Example:* Design review | Technical | Each build | Developer, acquirer | SDD updated / design approved |
| *Example:* Test readiness review | Technical | Before each qualification run | Developer, acquirer, QA | Procedures reviewed, environment ready / go decision |
| *Example:* Monthly management review | Management | Monthly | PMs, leads | Status report / actions agreed |

### 5.19 Other software development activities

| Sub-paragraph | Approach |
|---|---|
| 5.19.1 Risk management | *Example:* Risk register reviewed fortnightly; known risks: R-01 gateway interface delay, R-02 data migration quality, R-03 key staff availability |
| 5.19.2 Software management indicators | *Example:* Velocity, requirements volatility, defect density, open problem reports by priority, test pass rate, schedule variance |
| 5.19.3 Security and privacy | *Example:* As 4.2.4.2 and 4.2.4.3; access to production data restricted to cleared staff |
| 5.19.4 Subcontractor management | *Example:* Subcontractor for map client works under this SDP; monthly review and code access |
| 5.19.5 Interface with IV&V agents | *Example:* IV&V agent gets repository and environment access; findings handled as problem reports |
| 5.19.6 Coordination with associate developers | *Example:* Interface control working group with national incident system contractor |
| 5.19.7 Improvement of project processes | *Example:* Retrospective actions tracked; process changes reflected in this SDP |
| 5.19.8 Other activities | *Example:* Data migration from version 1 planned in migration plan MP-01 |

## 6. Schedules and activity network

<!-- Guidance: Show when each activity in each build starts and ends, when draft and final deliverables are available, and the dependencies that most constrain the schedule (critical path). -->

The schedule below shows the activities per build and the main
milestones. The detailed schedule is kept in [scheduling tool link].

```mermaid
gantt
  title Software development schedule
  dateFormat YYYY-MM-DD
  section Build 1
  Requirements and design      :b1a, 2026-01-05, 6w
  Implementation and unit test :b1b, after b1a, 8w
  Integration and test         :b1c, after b1b, 3w
  section Build 2
  Requirements and design      :b2a, after b1b, 4w
  Implementation and unit test :b2b, after b2a, 8w
  CSCI qualification test      :b2c, after b2b, 3w
  section Build 3
  Gateway design and build     :b3a, after b2a, 10w
  System qualification         :b3b, after b3a, 4w
  Installation and transition  :b3c, after b3b, 6w
```

| Milestone | Date | Deliverable | Draft / final |
|---|---|---|---|
| *Example:* Software requirements review | YYYY-MM-DD | SRS | Draft |
| *Example:* Build 1 review | YYYY-MM-DD | Build 1 software, SDD | Draft |
| *Example:* Build 2 test readiness review | YYYY-MM-DD | STP, STD | Final |
| *Example:* Initial operational capability | YYYY-MM-DD | SVD, SUM, installed software | Final |
| *Example:* Transition complete | YYYY-MM-DD | STrP actions closed | Final |

Activity network: the critical path runs through [gateway interface
agreement, gateway build, system qualification, installation]. A delay
in the interface agreement moves initial operational capability day for
day.

## 7. Project organisation and resources

<!-- Guidance: Describe the organisations, their authority and responsibilities, and the people, facilities, acquirer-furnished items and other resources for each build. -->

### 7.1 Project organisation

The organisation chart below shows reporting lines and the organisations
involved.

```mermaid
flowchart TB
  A["Acquirer programme office"] --- PM["Developer software PM"]
  PM --> ENG["Engineering lead"]
  PM --> QA["QA lead (reports to quality manager)"]
  PM --> CM["Configuration manager"]
  ENG --> T1["Server team"]
  ENG --> T2["Client team"]
  ENG --> SUB["Subcontractor: map client"]
  ENG --> TEST["Test team"]
```

| Organisation / role | Authority and responsibilities |
|---|---|
| *Example:* Software project manager | Owns this SDP, schedule and staffing; single point of contact with acquirer |
| *Example:* Engineering lead | Technical authority for design and code standards |
| *Example:* QA lead | Independent evaluation; can stop a delivery on non-conformance |
| *Example:* Configuration manager | Baselines, releases, change board secretary |
| [Role] | [Responsibilities] |

### 7.2 Project resources

| Resource | Plan |
|---|---|
| Staff loading over time | *Example:* 8 FTE in build 1, 14 FTE in builds 2 and 3, 6 FTE during transition |
| Staff by responsibility | *Example:* Management 1, engineering 8, test 3, CM 1, QA 1 |
| Skills, locations and clearances | *Example:* Two cleared engineers for on-site work; others remote in [location] |
| Developer facilities | *Example:* [Office], secure room for acquirer data, cloud accounts for environments |
| Acquirer-furnished items | *Example:* Access to version 1 source and data extracts by YYYY-MM-DD; test accounts on national incident system by YYYY-MM-DD |
| Other resources | *Example:* Penetration test vendor in build 3; plan for procurement by YYYY-MM-DD |

## 8. Notes

<!-- Guidance: Background, rationale, glossary and an alphabetical list of acronyms and abbreviations used in this document. -->

| Term | Meaning |
|---|---|
| ADR | Architecture decision record |
| CDRL | Contract data requirements list |
| CSCI | Computer software configuration item, a software item managed as a unit |
| HWCI | Hardware configuration item |
| IV&V | Independent verification and validation |
| SDD / SRS / STP / STrP / SVD / SUM | Software design description / requirements specification / test plan / transition plan / version description / user manual |

## Appendixes

<!-- Guidance: Use lettered appendixes for material published separately or kept for convenience, and reference each from the main body. -->

| Appendix | Content | Referenced in |
|---|---|---|
| A | *Example:* Requirements to activity traceability for critical requirements | 4.2.4 |
| B | *Example:* Tailoring record: paragraphs tailored out and why | All sections |
| C | [Content] | [Section] |

## Standard and licence note

Based on MIL-STD-498 Data Item Description DI-IPSC-81427, Software
Development Plan (SDP), dated 5 December 1994, a US Department of Defense
document approved for public release (public domain); the section
numbering follows its content requirements, in original wording. Later
revisions (DI-IPSC-81427A, 2000, and DI-IPSC-81427B, 2017) exist; check
which revision your contract cites. Activity mapping aligned with
ISO/IEC/IEEE 12207:2017, software life cycle processes; this template
reproduces no text from that standard, so obtain it for its normative
requirements. Template licence: MIT.