DI-IPSC-82208
Software Development Process Description Document (SDPDD)
The SDPDD documents the format, content, and delivery timeframes for describing software and programmable logic development processes, methods, and Agile, cyber security, and safety assurance practices for new development, modification, reuse, reengineering, and maintenance activities.
Approval DateApril 17, 2018
AMSC Number9927
Preparing ActivityNS/Y2D
Project NumberIPSC-2018-003
OPR—
DTIC ApplicableNo
GIDEP ApplicableNo
Limitation—
Applicable Forms—
Approval Limitation—
Form Version—
DID Formatfree_text
963C CompliantYes
DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.
Supersedes
—Related
—Description & Purpose
—
Application & Interrelationship
—
Use & Relationship
The Software Development Process Description Document (SDPDD) with Agile, Cyber Security and Safety Assurance contains the format, content, and delivery timeframes for the SDPDD. The SDPDD provides the acquirer insight into, and a tool for monitoring, the processes to be followed for software and programmable logic development, the methods to be used, the approach to be followed for each activity, and project schedules, organization, resources, and practices based on Capability Maturity Model Integration (CMMI), Maturity Level 3, or equivalent. This DID is useful for new development, modification, reuse, reengineering, maintenance, and other activities resulting in software products.
This Data Item Description contains the format, content, and intended use information for the data product resulting from the work task described by the contract.
Preparation Instructions
1General.
1.1The SDPDD shall be delivered in Microsoft Word or PDF unless otherwise agreed to by receiving organization.
1.2Shall include a Title Page listing the program name and nomenclature; document name and number; contract or Memorandum of Agreement number; A/CDRL number; revision and date; preparing organization; distribution organization per the A/CDRL; security markings or other restrictions on the handling of the document.
1.3Shall include a Change/Revision Page, a Table of Contents, and a Table defining all abbreviations and acronyms.
1.4Shall include a Referenced documents section that list the number, title, revision, and date of all documents referenced in this plan.This section shall also identify the source for all documents not available through normal Government stocking activities. The complete address or website or other conditions for availability will be described.
1.5The SDPDD shall include classification markings in accordance with DD-254 and applicable Classification Guide.
2Format.The SDPDD shall adhere to the format described under Content.
3Content.
3.1Identification.This paragraph shall contain a full identification of the product and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
3.2System overview.This paragraph shall briefly state the purpose of the product and the software to which this document applies. It shall describe the general nature of the system; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.
3.3Document overview.This paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.
3.4Relationship to other plans.This paragraph shall describe the relationship, if any, of the SDPDD to other project management plans.
3.5Overview of required work.This section shall be divided into paragraphs as needed to establish the context for the planning described in later sections. It shall include, as applicable, an overview of:
3.5.1Requirements and constraints on the system and software/programmable logic to be developed
3.5.2Requirements and constraints on project documentation
3.5.3Position of the project in the system life cycle
3.5.4The selected program/acquisition strategy or any requirements or constraints on it
3.5.5Requirements and constraints on project schedules and resources
3.5.6Other requirements and constraints, such as on project security, privacy, methods, standards, interdependencies in hardware and software development, etc.
3.6Plans for performing general software/programmable logic development activities.This section shall be divided into the following paragraphs. Provisions corresponding to non-required activities may be satisfied by the words "Not applicable." If different builds or different software on the project require different planning, these differences shall be noted in the paragraphs. In addition to the content specified below, each paragraph shall identify applicable risks/uncertainties and plans for dealing with them.
3.6.1Software/programmable logic development process.This paragraph shall describe the software/programmable logic development process to be used. The planning shall cover all contractual clauses concerning this topic, identifying planned builds, if applicable, their objectives, and the software development activities to be performed in each build to include status analysis tools, tools settings, and how they will be used to ensure compliance with security requirements.
3.6.2If the software/programmable logic development process is an Agile process, the following must be addressed within this section or subsection(s):
3.6.2.1Cite the Agile technique(s) being employed (Scrum, pair programming, extreme programming, etc.).
3.6.2.2For each Agile technique employed, describe your approach.
3.6.2.3Describe the approach for release planning.
3.6.2.4For Scrum, identify the sprint length and how it was determined.
3.6.2.5Describe how the backlog is initially established, and the process for modifying and re-prioritizing it.
3.6.2.6For Scrum, describe the typical sprint activities, and what happens during each iteration.
3.6.2.7Identify the Product Owner and his/her roles/responsibilities.
3.6.2.8Describe the acquirer's role in the sprints if the customer is not also the Product Owner.
3.6.2.9Describe the mechanism for getting acquirer (or end user) feedback for each sprint.
3.6.2.10Describe how the product (working, useful piece of software) will be demonstrated to the Product Owner after each sprint (e.g., live demo on real equipment, in the lab with sim/stim, PowerPoint slides, etc.).
3.6.2.11Describe the handling of incomplete user stories, unsatisfactory user stories, and bugs, and how they are factored back into the backlog.
3.6.2.12Describe your Configuration Management process for keeping track of which user stories passed without any rework needed, which require rework, and which failed.
3.6.2.13Describe your approach to artifact delivery; when documents such as the SED, SHRS, SHDD, SPLERs, SVPP will be available.
3.6.2.14Discuss your approach to refactoring.
3.6.2.15List and describe the software metrics to be used.
3.6.2.16Discuss your approach to paying off technical debt.
3.6.2.17Describe how you will determine story points for the velocity metric.
3.6.2.18Describe your Integrated Requirements Toolset (IRT) that traces user stories to mission threads and KPPs, and whether this is a commercial tool or a tool developed by your organization.
3.6.2.19Describe how software development activities will be coordinated with the Integration and Test (I&T) team, and how it will be assured that the I&T team can keep up with testing all the software releases.
3.6.2.20Describe how sprint-to-sprint dependencies (related to product and development resources) will be resolved and factored into the Sprint/Release Plan.
3.6.2.21Describe your strategy/mechanism for keep multiple sprint teams in sync.
3.6.2.22Describe how the integrity of the baseline is maintained for use in the development of the next sprint.
3.6.2.23Describe how regression testing will be conducted for each sprint release for all previous functions released.
3.6.2.24Describe how automated testing techniques will be used for sprint and/or regression testing.
3.6.2.25Describe how the software/programmable logic development effort will be synchronized and coordinated with systems engineering activities and reviews.
3.7General plans for software/programmable logic development.This paragraph shall be divided into the following subparagraphs.
3.7.1Software/programmable logic development methods.This paragraph shall describe or reference the software/programmable logic development methods to be used. Included shall be descriptions of the manual and automated tools and procedures to be used in support of these methods. The methods shall cover all contractual clauses concerning this topic. Reference may be made to other paragraphs in this plan if the methods are better described in context with the activities to which they will be applied.
3.7.2Standards for software/programmable logic products.This paragraph shall describe or reference the standards to be followed for representing requirements, design, code, test cases, test procedures, and test results. The standards shall cover all contractual clauses concerning this topic. Reference may be made to other paragraphs in this plan if the standards are better described in context with the activities to which they will be applied. Standards for code/VHDL shall be provided for each programming language to be used. They shall include at a minimum:
3.7.2.1Standards for format (such as indentation, spacing, capitalization, and order of information)
3.7.2.2Standards for header comments (requiring, for example, name/identifier of the code; version identification; coder's name, date, modification history; purpose; requirements and design decisions implemented; notes on the processing (such as algorithms used, assumptions, constraints, limitations, and side effects); and notes on the data (inputs, outputs, variables, data structures, etc.)
3.7.2.3Standards for other comments (such as required number and content expectations)
3.7.2.4Naming conventions for variables, parameters, packages, procedures, files, etc.
3.7.2.5Restrictions, if any, on the use of programming language constructs or features
3.7.2.6Restrictions, if any, on the complexity of code aggregates
3.7.3Reusable software/programmable logic products.This paragraph shall be divided into the following subparagraphs.
3.7.3.1Incorporating reusable software/programmable logic products.This paragraph shall describe the approach to be followed for identifying, evaluating, and incorporating reusable software/programmable logic products, including the scope of the search for such products and the criteria to be used for their evaluation. It shall cover all contractual clauses concerning this topic. Candidate or selected reusable software/programmable logic products known at the time this plan is prepared or updated shall be identified and described, together with benefits, drawbacks, and restrictions, as applicable, associated with their use.
3.7.3.2Developing reusable software/programmable logic products.This paragraph shall describe the approach to be followed for identifying, evaluating, and reporting opportunities for developing reusable software/programmable logic products. It shall cover all contractual clauses concerning this topic.
3.7.4Handling of critical requirements.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for handling requirements designated critical. The planning in each subparagraph shall cover all contractual clauses concerning the identified topic.
3.7.4.1Safety Assurance
3.7.4.1.1Software/VHDL Requirements
3.7.4.1.2System Software/Hardware Architecture and Software/VHDL Preliminary Design
3.7.4.1.3Software/VHDL Detailed Design
3.7.4.1.4Software/VHDL Coding and Unit Test
3.7.4.1.5Computer Software Component (CSC) Integration and Test
3.7.4.1.6Computer Software Configuration Item (CSCI) Formal Qualification Test (FQT)
3.7.4.1.7Subsystem Integration and Test
3.7.4.1.8System Qualification Test
3.7.4.2Cyber-Security / Software Assurance
3.7.4.2.1Software/VHDL Requirements
3.7.4.2.2System Software/VHDL Architecture and Software Preliminary Design
3.7.4.2.3Software/VHDL Detailed Design
3.7.4.2.4Software/VHDL Coding and Unit Test
3.7.4.2.5CSC Integration and Test
3.7.4.2.6CSCI FQT
3.7.4.2.7Subsystem Integration and Test
3.7.4.2.8System Qualification Test
3.7.4.2.9Describe the mechanism to address constant emerging cyber-security requirements.
3.7.5Assurance of other critical requirements
3.7.6Computer hardware resource utilization.This paragraph shall describe the approach to be followed for allocating computer hardware resources and monitoring their utilization. It shall cover all contractual clauses concerning this topic.
3.7.7Recording rationale.This paragraph shall describe the approach to be followed for recording rationale that will be useful to the support agency for key decisions made on the project. It shall interpret the term "key decisions" for the project and state where the rationales are to be recorded. It shall cover all contractual clauses concerning this topic.
3.7.8Access for acquirer review.This paragraph shall describe the approach to be followed for providing the acquirer or its authorized representative access to developer and subcontractor facilities for review of software products and activities. It shall cover all contractual clauses concerning this topic.
3.8Plans for performing detailed software development activities.This section shall be divided into the following paragraphs. Provisions corresponding to non-required activities may be satisfied by the words "Not applicable." If different builds or different software on the project require different planning, these differences shall be noted in the paragraphs. The discussion of each activity shall include the approach (methods/procedures/tools) to be applied to: 1) the analysis or other technical tasks involved; 2) the recording of results; and, 3) the preparation of associated deliverables, if applicable. The discussion shall also identify applicable risks/uncertainties and plans for dealing with them.
3.8.1Project planning and oversight.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for project planning and oversight. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.1.1Software/programmable logic development planning (covering updates to this plan)
3.8.1.2CSCI test planning
3.8.1.3System test planning
3.8.1.4Software/programmable logic installation planning
3.8.1.5Software/programmable logic transition planning
3.8.1.6Following and updating plans, including the intervals for management review
3.8.2Establishing a software/programmable logic development environment.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for establishing, controlling, and maintaining a software/programmable logic development environment. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.2.1Software/programmable logic engineering environment
3.8.2.2Software/programmable logic test environment
3.8.2.3Software/programmable logic development library
3.8.2.4Software/programmable logic development files
3.8.2.5Non-deliverable software/programmable logic
3.8.2.6Software/programmable logic assurance considerations, including on tool selection
3.8.3System requirements analysis.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for participating in system requirements analysis. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.3.1Analysis of user input
3.8.3.2Operational concept
3.8.3.3System requirements
3.8.4System design.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for participating in system design. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.4.1System-wide design decisions
3.8.4.2System architectural design
3.8.5Software/programmable logic requirements analysis.This paragraph shall describe the approach to be followed for software requirements analysis. The approach shall cover all contractual clauses concerning this topic.
3.8.6Software/programmable logic design.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for software/programmable logic design. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.6.1CSCI-wide design decisions
3.8.6.2CSCI architectural design
3.8.6.3CSCI detailed design
3.8.7Peer Review.This paragraph shall describe the peer review process covering: System requirements, system design, requirements, design, implementation and testing.
3.8.8Coding Standards.This paragraph shall describe the uniform set of rules and guidelines of the project and organization used for software development. This shall include standards for the creation and sustainment of secure systems.
3.8.9Implementation and unit testing.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for implementation and unit testing. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.9.1Implementation
3.8.9.2Preparing for unit testing
3.8.9.3Performing unit testing
3.8.9.4Revision and retesting
3.8.9.5Analyzing and recording unit test results
3.8.10Unit integration and testing.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for unit integration and testing. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.10.1Preparing for unit integration and testing
3.8.10.2Performing unit integration and testing
3.8.10.3Revision and retesting
3.8.10.4Analyzing and recording unit integration and test results
3.8.11CSCI qualification testing.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for CSCI qualification testing. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.11.1Independence in CSCI qualification testing
3.8.11.2Testing on the target computer system
3.8.11.3Preparing for CSCI qualification testing
3.8.11.4Dry run of CSCI qualification testing
3.8.11.5Performing CSCI qualification testing
3.8.11.6Revision and retesting
3.8.11.7Analyzing and recording CSCI qualification test results
3.8.12CSCI/HWCI integration and testing.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for participating in CSCI/HWCI integration and testing. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.12.1Preparing for CSCI/HWCI integration and testing
3.8.12.2Performing CSCI/HWCI integration and testing
3.8.12.3Revision and retesting
3.8.12.4Analyzing and recording CSCI/HWCI integration and test results
3.8.13System qualification testing.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for participating in system qualification testing. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.13.1Independence in system qualification testing
3.8.13.2Testing on the target computer system
3.8.13.3Preparing for system qualification testing
3.8.13.4Dry run of system qualification testing
3.8.13.5Performing system qualification testing
3.8.13.6Revision and retesting
3.8.13.7Analyzing and recording system qualification test results
3.8.13.8Describe the process to allow access by the government to the results of this code evaluation on a real-time basis and shall address the use of automated code analyzers and documented peer review process.
3.8.14Preparing for software/programmable logic use.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for preparing for software use.
3.8.14.1Preparing the executable software/programmable logic
3.8.14.2Preparing version descriptions for user sites
3.8.15Preparing for software/programmable logic transition.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for preparing for software transition. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.15.1Preparing the executable software/programmable logic
3.8.15.2Preparing source files
3.8.15.3Preparing version descriptions for the support site
3.8.15.4Preparing the "as built" CSCI design and other software support information
3.8.15.5Updating the system design description
3.8.15.6Preparing support manuals
3.8.15.7Transition to the designated support site
3.8.15.8Details for proposed evaluation of code quality and removal of defects before the code leaves the hands of the developers to the system integrators.This includes conformance to coding standards, as well as problems such as dead code, memory leaks and unreachable code
3.8.16Configuration management.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for software configuration management. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.16.1Configuration identification
3.8.16.2Configuration control
3.8.16.3Configuration status accounting
3.8.16.4Configuration audits
3.8.16.5Packaging, storage, handling, and delivery
3.8.17Product evaluation.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for product evaluation. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.17.1In-process and final software product evaluations
3.8.17.2Software/programmable logic product evaluation records, including items to be recorded
3.8.17.3Independence in product evaluation
3.8.18Software quality assurance.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for quality assurance. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.18.1Software/programmable logic quality assurance evaluations
3.8.18.2Software quality assurance records, including items to be recorded
3.8.18.3Independence in software quality assurance
3.8.19Corrective action.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for corrective action. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.19.1Problem/change reports, including items to be recorded(candidate items include project name, originator, problem number, problem name, software element or document affected, origination date, category and priority, description, analyst assigned to the problem, date assigned, date completed, analysis time, recommended solution, impacts, problem status, approval of solution, follow-up actions, corrector, correction date, version where corrected, correction time, description of solution implemented)
3.8.19.2Corrective action system
3.8.20Joint technical and management reviews.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for joint technical and management reviews. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.20.1Joint technical reviews, including a proposed set of reviews
3.8.20.2Joint management reviews, including a proposed set of reviews
3.8.21Other software/programmable logic development activities.This paragraph shall be divided into the following subparagraphs to describe the approach to be followed for other software development activities. The planning in each subparagraph shall cover all contractual clauses regarding the identified topic.
3.8.21.1Risk management, including known risks and corresponding strategies
3.8.21.2Software/programmable logic e management indicators, including indicators to be used
3.8.21.3Security and privacy
3.8.21.4Subcontractor management
3.8.21.5Interface with software independent verification and validation (IV&V) agents
3.8.21.6Coordination with associate developers
3.8.21.7Improvement of project processes
3.8.21.8Other activities not covered elsewhere in the plan
3.8.22Schedules and activity network.This section shall present:
3.8.22.1Schedule(s) identifying the activities in each build and showing initiation of each activity, availability of draft and final deliverables and other milestones, and completion of each activity
3.8.22.2An activity network, depicting sequential relationships and dependencies among activities and identifying those activities that impose the greatest time restrictions on the project
3.9Project organization and resources.This section shall be divided into the following paragraphs to describe the project organization and resources to be applied in each build.
3.9.1Project organization.This paragraph shall describe the organizational structure to be used on the project, including the organizations involved, their relationships to one another, and the authority and responsibility of each organization for carrying out required activities. This paragraph shall also include the definition of Systems Engineering, Software Engineering, Integrated Product and Process Development, and processes for the Division(s) responsible for the development and the principle sub-contractors responsible for software/programmable logic development, as applicable.
3.9.2Project resources.This paragraph shall describe the resources to be applied to the project. This section shall include a description of the extent to which personnel who contributed to these previous efforts using these processes will be supporting this development effort. It shall include:
3.9.2.1Personnel resources, including:
3.9.2.1.1The estimated staff-loading for the project (number of personnel over time)
3.9.2.1.2The breakdown of the staff-loading numbers by responsibility (for example, management, software engineering, software testing, software configuration management, software product evaluation, software quality assurance)
3.9.2.1.3A breakdown of the skill levels, geographic locations, and security clearances of personnel performing each responsibility
3.9.2.2Overview of developer facilities to be used, including geographic locations in which the work will be performed, facilities to be used, and secure areas and other features of the facilities as applicable to the contracted effort.
3.9.2.3Acquirer-furnished equipment, software, services, documentation, data, and facilities required for the contracted effort.A schedule detailing when these items will be needed shall also be included.
3.9.2.4Other required resources, including a plan for obtaining the resources, dates needed, and availability of each resource item.
3.10Notes.This section shall contain any general information that aids in understanding this document (e.g., background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.
3.11Appendices.Appendixes may be used to provide information published separately for convenience in document maintenance (e.g., charts, classified data). As applicable, each appendix shall be referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes shall be lettered alphabetically (A, B, etc.).
References
—
Schema v3.0Community-maintained · Verify against ASSIST
Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer
Verify against ASSIST·GitHub·About·Disclaimer