Context Navigation

source: rtems-docs/eng/appendix-a.rst @ d721375

5

Last change on this file since d721375 was e52906b, checked in by Sebastian Huber <sebastian.huber@…>, on 01/09/19 at 15:14:06
Simplify SPDX-License-Identifier comment
Property mode set to `100644`
File size: 9.6 KB

Line
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:

Note: See TracBrowser for help on using the repository browser.

Download in other formats: