DI-SESS-82176

Software Architecture Description (SWARD)

Establishes preparation instructions for the Software Architecture Description (SWARD), which forms the basis for detailed design and gives the acquirer visibility into the architecture and software support needs.

Approval DateJanuary 8, 2018

AMSC Number9886

Preparing ActivityMI

Project NumberSESS-2018-004

OPR—

DTIC Applicable—

GIDEP Applicable—

Limitation—

Applicable Forms—

Approval Limitation—

Form Version—

DID Formatfree_text

963C CompliantYes

DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.

Supersedes

—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

This DID contains the format, content, and intended use information for the data deliverable resulting from the work task described in the solicitation.

This DID describes the preparation instructions for the Software Architecture Description (SWARD) which is used as the basis for creating the detailed design and provides the acquirer visibility into the architecture as well as information needed for software support.

Preparation Instructions

1Reference documentsNone.

2FormatThe SWARD shall be in contractor's format.

3Content

3.1ScopeThis section shall be divided into the following paragraphs.

3.1.1IdentificationThis paragraph shall contain a full identification of the system 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.1.2System overviewThis paragraph shall briefly state the purpose of the system to which this document applies. It shall describe the general nature of the system and software; 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.1.3Document overviewThis paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.

3.2Referenced documentsThis section shall list the number, title, revision, and date of all documents referenced in this document. This section shall also identify the source for all documents not available through normal Government stocking activities.

3.3Software architecture documentation

3.3.1The software architectural documentation shall include a high level overviewThe software architectural documentation shall include a high level overview and summary description of the architectural drivers and design along with a set of views created by the architect that describe the software system. In addition to providing and describing each of the relevant views, the documentation shall include the relevant cross-view information that applies to more than one view. These views shall be analyzable and provide the information needed to conclusively show that the software architecture can, in fact, achieve the software quality attributes. Moreover, the software architecture documentation shall be sufficiently robust to enable an analysis to be performed that shows how the system will respond to any particular scenario that is representative of one or more of the quality attributes that the system is required to satisfy.

3.3.2When creating the software architecture documentation, the followingWhen creating the software architecture documentation, the following guidelines shall be observed:

3.3.2.1Use a key/legend to define the graphical notation in diagrams

3.3.2.2Use consistent graphical notation across diagrams

3.3.2.3Identify in a clear way the elements that are externalIdentify in a clear way the elements that are external to the system.

3.3.2.4Use multiple levels of abstraction as needed

3.3.2.5If part of the architecture follows a known architectural style/patternIf part of the architecture follows a known architectural style/pattern, indicate that in the documentation.

3.3.3Software architecture views

3.3.3.1The SWARD shall include three view typesThe SWARD shall include three view types:

3.3.3.1.1Module viewsShow and describe how the software system is structured as a set of code unites or modules; i.e., document the principal units of implementation.

3.3.3.1.2Component-and-connector viewsShow and describe how the software system is structured as a set of software elements that have runtime behavior and interactions; i.e., document the units of execution.

3.3.3.1.3Allocation viewsShow and describe how the software system relates to non-software structures in its environment such as CPUs, file systems, networks, development teams, and so forth; i.e., document the relationship between the system's software and its development and execution environments.

3.3.3.2The SWARD shall include enough views to enableThe SWARD shall include enough views to enable a complete analysis to be performed; i.e., sufficient to determine the ability of the software architecture to achieve all the system's specified quality attribute requirements. Each view shall include:

3.3.3.2.1A primary graphical presentation along with a descriptionA primary graphical presentation along with a description of the view.

3.3.3.2.2An element catalog that explains the elements and relationsAn element catalog that explains the elements and relations in the primary presentation, including interface specification (or reference to it if documented in another view).

3.3.3.2.3A description of the variability pointsA description of the variability points (as determined via commonality and variability analysis) supported by the view, the variation mechanisms (e.g., inheritance, extension points, parameterization, configuration files, compile-time selection, etc.) and how to exercise the mechanisms, and rationale for the variation mechanisms.

3.3.3.2.4Rationale for non-obvious design decisionsRationale for non-obvious design decisions or decisions that are the source of questions, are critical, or have a widespread effect. It shall include relevant constraints, rejected alternatives, ramifications of the decision, and evidence that the decision was the correct one.

3.3.3.2.5Results of analyses of the architecture

3.3.3.2.6Other pertinent information

3.3.4Software architecture cross-view informationAdditionally, since the software architecture documentation represents the unifying vision for all software development, it shall include the data needed to document information that applies across views. This cross-view information shall include:

3.3.4.1A documentation roadmap

3.3.4.2A view template

3.3.4.3A system overview, including a context diagram

3.3.4.4Mapping between viewsMapping between views (using a table or equivalent means to show how the elements of one view correspond to elements of another).

3.3.4.5A directory

3.3.4.6A project glossary and acronym list

3.3.5Requirements allocation to software architectureThe software architecture documentation shall include traceability from the derived software requirements into the software architecture. The software architecture shall have coverage for all of the derived software requirements.

3.4NotesThis 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.5AppendicesAppendices shall be used to provide information published separately for convenience in document maintenance (e.g., charts, classified data, etc.) as necessary. As applicable, each appendix shall be referenced in the main body of the document where the data would normally have been provided. Appendices shall be bound as separate documents for ease in handling. Appendices shall be lettered alphabetically (A, B, etc.). Document where open architecture requirements conflict in an appendix to this document, including proposed resolution thereof.

References

—

Schema v3.0Community-maintained · Verify against ASSIST

Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer