1 | .. SPDX-License-Identifier: CC-BY-SA-4.0 |
---|
2 | |
---|
3 | .. Copyright (C) 2018. |
---|
4 | .. COMMENT: RTEMS Foundation, The RTEMS Documentation Project |
---|
5 | |
---|
6 | |
---|
7 | Appendix: Core Qualification Artifacts/Documents |
---|
8 | ************************************************ |
---|
9 | |
---|
10 | An effort at NASA has been performed to suggest a core set of artifacts |
---|
11 | (as defined by **BOTH** NASA NPR 7150.2B and DO-178B) that can be utilized |
---|
12 | by a mission as a baselined starting point for "pre-qualification" |
---|
13 | for (open-source) software that is intended to be utilized for flight |
---|
14 | purposes. This effort analyzed the overlap between NPR 7150.2B |
---|
15 | and DO-178B and highlighted a core set of artifacts to serve as a |
---|
16 | starting point for any open-source project. These artifacts were also |
---|
17 | cross-referenced with similar activities for other NASA flight software |
---|
18 | qualification efforts, such as the open-source Core Flight System (cFS). |
---|
19 | Along with the specific artifact, the intent of the artifact was also |
---|
20 | captured; in some cases open-source projects, such as RTEMS, are already |
---|
21 | meeting the intent of the artifacts with information simply needing |
---|
22 | organized and formalized. The table below lists the general category, |
---|
23 | artifact name, and its intent. Please note that this table does **NOT** |
---|
24 | represent all the required artifacts for qualification per the standards; |
---|
25 | instead, this table represents a subset of the most basic/core artifacts |
---|
26 | that form a strong foundation for a software engineering qualification |
---|
27 | effort. |
---|
28 | |
---|
29 | .. COMMENT: TBD convert to a table; see original PDF for guidance on desired look |
---|
30 | .. COMMENT: TBD The PDF is in https://ftp.rtems.org/pub/rtems/people/joel/sw_eng_hb/ |
---|
31 | |
---|
32 | .. table:: Table 1. Core Qualification Artifacts |
---|
33 | :class: rtems-table |
---|
34 | |
---|
35 | +----------------+-----------------------+---------------------------------+ |
---|
36 | | Category | Artifact | Intent | |
---|
37 | +================+=======================+=================================+ |
---|
38 | | Requirements | Software Requirements | The project shall document the | |
---|
39 | | | Specification (SRS) | software requirements. | |
---|
40 | | | | | |
---|
41 | | | | The project shall collect and | |
---|
42 | | | | manage changes to the software | |
---|
43 | | | | requirements. | |
---|
44 | | | Requirements | | |
---|
45 | | | Management | The project shall identify, | |
---|
46 | | | | initiate corrective actions, | |
---|
47 | | | | and track until closure | |
---|
48 | | | | inconsistencies among | |
---|
49 | | | | requirements, project plans, | |
---|
50 | | | | and software products. | |
---|
51 | | +-----------------------+---------------------------------+ |
---|
52 | | | Requirements Test and | The project shall perform, | |
---|
53 | | | Traceability Matrix | document, and maintain | |
---|
54 | | | | bidirectional traceability | |
---|
55 | | | | between the software | |
---|
56 | | | | requirement and the | |
---|
57 | | | | higher-level requirement. | |
---|
58 | | +-----------------------+---------------------------------+ |
---|
59 | | | Validation | The project shall perform | |
---|
60 | | | | validation to ensure that the | |
---|
61 | | | | software will perform as | |
---|
62 | | | | intended in the customer | |
---|
63 | | | | environment. | |
---|
64 | +----------------+-----------------------+---------------------------------+ |
---|
65 | | Design and | Software Development | A plan for how you will develop | |
---|
66 | | Implementation | or Management Plan | the software that you are | |
---|
67 | | | | intent upon developing and | |
---|
68 | | | | delivering. | |
---|
69 | | | | | |
---|
70 | | | | The Software Development Plan | |
---|
71 | | | | includes the objectives, | |
---|
72 | | | | standards and life cycle(s) to | |
---|
73 | | | | be used in the software | |
---|
74 | | | | development process. This plan | |
---|
75 | | | | should include: Standards: | |
---|
76 | | | | Identification of the Software | |
---|
77 | | | | Requirements Standards, | |
---|
78 | | | | Software Design Standards, | |
---|
79 | | | | and Software Code Standards for | |
---|
80 | | | | the project. | |
---|
81 | | +-----------------------+---------------------------------+ |
---|
82 | | | Software | To identify and control major | |
---|
83 | | | Configuration | software changes, ensure that | |
---|
84 | | | Management Plan | change is being properly | |
---|
85 | | | | implemented, and report changes | |
---|
86 | | | | to any other personnel or | |
---|
87 | | | | clients who may have an | |
---|
88 | | | | interest. | |
---|
89 | | +-----------------------+---------------------------------+ |
---|
90 | | | Implementation | The project shall implement the | |
---|
91 | | | | software design into software | |
---|
92 | | | | code. | |
---|
93 | | | | | |
---|
94 | | | | Executable Code to applicable | |
---|
95 | | | | tested software. | |
---|
96 | | +-----------------------+---------------------------------+ |
---|
97 | | | Coding Standards | The project shall ensure that | |
---|
98 | | | Report | software coding methods, | |
---|
99 | | | | standards, and/or criteria are | |
---|
100 | | | | adhered to and verified. | |
---|
101 | | +-----------------------+---------------------------------+ |
---|
102 | | | Version Description | The project shall provide a | |
---|
103 | | | Document (VDD) | Software Version Description | |
---|
104 | | | | document for each software | |
---|
105 | | | | release. | |
---|
106 | +----------------+-----------------------+---------------------------------+ |
---|
107 | | Testing and | Software Test Plan | Document describing the testing | |
---|
108 | | Software | | scope and activities. | |
---|
109 | | Assurance +-----------------------+---------------------------------+ |
---|
110 | | Activities | Software | To define the techniques, | |
---|
111 | | | Assurance/Testing | procedures, and methodologies | |
---|
112 | | | Procedures | that will be used. | |
---|
113 | | +-----------------------+---------------------------------+ |
---|
114 | | | Software Change | The project shall regularly | |
---|
115 | | | Report / Problem | hold reviews of software | |
---|
116 | | | Report | activities, status, and results | |
---|
117 | | | | with the project stakeholders | |
---|
118 | | | | and track issues to resolution. | |
---|
119 | | +-----------------------+---------------------------------+ |
---|
120 | | | Software Schedule | Milestones have schedule and | |
---|
121 | | | | schedule is updated | |
---|
122 | | | | accordingly. | |
---|
123 | | +-----------------------+---------------------------------+ |
---|
124 | | | Software Test | The project shall record, | |
---|
125 | | | Report / Verification | address, and track to closure | |
---|
126 | | | Results | the results of software | |
---|
127 | | | | verification activities. | |
---|
128 | +----------------+-----------------------+---------------------------------+ |
---|
129 | | Usability | Software User's | The Software User Manual | |
---|
130 | | | Manual | defines user instructions for | |
---|
131 | | | | the software. | |
---|
132 | +----------------+-----------------------+---------------------------------+ |
---|
133 | |
---|
134 | In an effort to remain lightweight and sustainable for open-source |
---|
135 | projects, Table 1 above was condensed into a single artifact outline |
---|
136 | that encompasses the artifacts' intents. The idea is that this living |
---|
137 | qualification document will reside under RTEMS source control and be |
---|
138 | updated with additional detail accordingly. The artifact outline is |
---|
139 | as follows: |
---|