Software Development Plan Template (MIL-STD-498 SDP)

SDP per DI-IPSC-81427: process, methods, standards, reuse, critical requirements, per-activity plans, schedule, organisation

Perangkat Lunak & RekayasaLengkapMIL-STD-498 DI-IPSC-81427; ISO/IEC/IEEE 12207:2017software development planDiperbarui 20 Okt 2026

Buka di editorUnduh .md

Cara menggunakan: Use it at contract or project start to show the acquirer how the software will be built. Fill sections 3 and 4.1 (required work and process, builds) first, then each activity in section 5. The main pitfall is pasting a generic process manual instead of the tools, standards and reviews the team will really use.

Pratinjau

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.

Document control

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

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

Scope
Referenced documents
Overview of required work
Plans for performing general software development activities
Plans for performing detailed software development activities
Schedules and activity network
Project organisation and resources
Notes
Appendixes
Standard and licence note

1. Scope

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

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

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

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

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

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

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

7.1 Project organisation

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

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

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

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.

Templat terkait

Perangkat Lunak & Rekayasa