A04 DID SWARD.pdf

DATA ITEM DESCRIPTION

Title: Software Architecture Description (SWARD)

Number: DI-SESS-82176 Approval Date: 20180108 AMSC Number: 9886 Limitation: N/A DTIC Applicable: N/A GIDEP Applicable: N/A Preparing Activity: MI Project Number: SESS-2018-004

Use/relationship:

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

b. 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.

Requirements:

1. Reference documents. None.

2. Format. The SWARD shall be in contractor’s format.

3. Content.

3.1 Scope. This section shall be divided into the following paragraphs.

3.1.1 Identification. This 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.2 System overview. This 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.3 Document 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.2 Referenced documents. This 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.3 Software architecture documentation.

3.3.1 The 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.

Source: http://assist.dla.mil -- Downloaded: 2023-08-01T13:59Z Check the source to verify that this is the current version before use.

DI-SESS-82176

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

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

b. Use consistent graphical notation across diagrams.

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

d. Use multiple levels of abstraction as needed.

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

3.3.3 Software architecture views.

3.3.3.1 The SWARD shall include three view types:

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

b. Component-and-connector views – show 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.

c. Allocation views – show 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.2 The 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:

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

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

c. A 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.

d. Rationale 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.

e. Results of analyses of the architecture.

DI-SESS-82176

f. Other pertinent information.

3.3.4 Software architecture cross-view information. Additionally, 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:

a. A documentation roadmap.

b. A view template.

c. A system overview, including a context diagram.

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

e. A directory.

f. A project glossary and acronym list.

3.3.5 Requirements allocation to software architecture. The 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.4 Notes. 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.5 Appendices. Appendices 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.

End of DI-SESS-82176