[PATCH] eng/appendix-a: convert to a table
Joel Sherrill
joel at rtems.org
Sat Dec 1 16:45:14 UTC 2018
Patch was also attached to GCI site. It worked from there. Not sure what
happened.
But it is pushed now and GCI task closed.
Thanks
--joel
On Sat, Dec 1, 2018 at 10:34 AM Joel Sherrill <joel at rtems.org> wrote:
> I think you need to submit this using "git format-patch".
>
> Do your work on a branch and submit the patches on that branch.
> Something like:
>
> git checkout master
> git checkout -b am
> git add FILES
> git commit # pops up an editor to write message
>
> git format-patch -o am master
> # puts patch in direcctory am, send that.
>
> Email the patch. git has a lot of features. The above it a very minimal
> subset and not a complete workflow.
>
> --joel
>
> On Sat, Dec 1, 2018 at 10:30 AM Marçal Comajoan Cara <
> mcomajoancara at gmail.com> wrote:
>
>> Convert text to a table, TBDs into comments and add missing
>> formatting.
>>
>> This work was part of GCI 2018.
>> ---
>> eng/appendix-a.rst | 152 +++++++++++++++++++++++++++++++--------------
>> 1 file changed, 104 insertions(+), 48 deletions(-)
>>
>> diff --git a/eng/appendix-a.rst b/eng/appendix-a.rst
>> index 633996b..cfad927 100644
>> --- a/eng/appendix-a.rst
>> +++ b/eng/appendix-a.rst
>> @@ -8,7 +8,7 @@ Appendix: Core Qualification Artifacts/Documents
>> ************************************************
>>
>> An effort at NASA has been performed to suggest a core set of artifacts
>> -(as defined by BOTH NASA NPR 7150.2B and DO-178B) that can be utilized
>> +(as defined by **BOTH** NASA NPR 7150.2B and DO-178B) that can be
>> utilized
>> by a mission as a baselined starting point for “pre-qualification”
>> for (open-source) software that is intended to be utilized for flight
>> purposes. This effort analyzed the overlap between NPR 7150.2B
>> @@ -20,60 +20,116 @@ Along with the specific artifact, the intent of the
>> artifact was also
>> captured; in some cases open-source projects, such as RTEMS, are already
>> meeting the intent of the artifacts with information simply needing
>> organized and formalized. The table below lists the general category,
>> -artifact name, and its intent. Please note that this table does NOT
>> +artifact name, and its intent. Please note that this table does **NOT**
>> represent all the required artifacts for qualification per the standards;
>> instead, this table represents a subset of the most basic/core artifacts
>> that form a strong foundation for a software engineering qualification
>> effort.
>>
>> -TBD convert to a table; see original PDF for guidance on desired look
>> -TBD The PDF is in https://ftp.rtems.org/pub/rtems/people/joel/sw_eng_hb/
>> +.. COMMENT: TBD convert to a table; see original PDF for guidance on
>> desired look
>> +.. COMMENT: TBD The PDF is in
>> https://ftp.rtems.org/pub/rtems/people/joel/sw_eng_hb/
>>
>> -.. COMMENT: ====================================== BEGIN
>> -Table 1. Core Qualification Artifacts
>> +.. table:: Table 1. Core Qualification Artifacts
>> + :class: rtems-table
>>
>> -Category Artifact Intent
>> -Requirements Software Requirements Specification (SRS)
>> -
>> -Requirements Management The project shall document the software
>> requirements.
>> -
>> -The project shall collect and manage changes to the software
>> requirements.
>> -
>> -The project shall identify, initiate corrective actions, and track until
>> closure inconsistencies among requirements, project plans, and software
>> products.
>> - Requirements Test and Traceability Matrix The project shall
>> perform, document, and maintain bidirectional traceability between the
>> software requirement and the higher-level requirement.
>> - Validation The project shall perform requirements validation
>> to ensure that the software will perform as intended in the customer
>> environment.
>> -
>> -
>> -Design and Implementation Software Development or Management Plan A
>> plan for how you will develop the software that you are intent upon
>> developing and delivering.
>> -
>> -The Software Development Plan includes the objectives, standards and
>> life cycle(s) to be used in the software development process. This plan
>> should include: Standards: Identification of the Software Requirements
>> Standards, Software Design Standards, and Software Code Standards for the
>> project.
>> -
>> - Software Configuration Management Plan To identify and control
>> major software changes, ensure that change is being properly implemented,
>> and report changes to any other personnel or clients who may have an
>> interest.
>> -
>> - Implementation The project shall implement the software design
>> into software code.
>> -
>> -Executable Code to applicable tested software.
>> -
>> - Coding Standards Report The project shall ensure that software
>> coding methods, standards, and/or criteria are adhered to and verified.
>> - Version Description Document (VDD) The project shall provide
>> a Software Version Description document for each software release.
>> -
>> -Testing and Software Assurance Activities Software Test Plan
>> Document describing the testing scope and activities.
>> - Software Assurance/Testing Procedures
>> - To define the techniques, procedures, and methodologies that will
>> be used.
>> -
>> - Software Change Report / Problem Report The project shall
>> regularly hold reviews of software activities, status, and results with the
>> project stakeholders and track issues to resolution.
>> -
>> - Software Schedule Milestones have schedule and schedule is
>> updated accordingly.
>> -
>> - Software Test Report / Verification Results The project shall
>> record, address, and track to closure the results of software verification
>> activities.
>> -
>> -Problem report - Describes the process non-compliance with plans, output
>> deficiency, or software anomalous behavior, and the corrective action taken.
>> -
>> -The project shall ensure that the software code is unit tested per the
>> plans for software testing.
>> -
>> -
>> -Usability Software User’s Manual The Software User Manual defines
>> user instructions for the software.
>> -.. COMMENT: ====================================== END
>> +
>> +----------------+-----------------------+---------------------------------+
>> + | Category | Artifact | Intent
>> |
>> +
>> +================+=======================+=================================+
>> + | Requirements | Software Requirements | The project shall document
>> the |
>> + | | Specification (SRS) | software requirements.
>> |
>> + | | |
>> |
>> + | | | The project shall collect
>> and |
>> + | | | manage changes to the
>> software |
>> + | | | requirements.
>> |
>> + | | Requirements |
>> |
>> + | | Management | The project shall
>> identify, |
>> + | | | initiate corrective
>> actions, |
>> + | | | and track until closure
>> |
>> + | | | inconsistencies among
>> |
>> + | | | requirements, project
>> plans, |
>> + | | | and software products.
>> |
>> + |
>> +-----------------------+---------------------------------+
>> + | | Requirements Test and | The project shall
>> perform, |
>> + | | Traceability Matrix | document, and maintain
>> |
>> + | | | bidirectional
>> traceability |
>> + | | | between the software
>> |
>> + | | | requirement and the
>> |
>> + | | | higher-level requirement.
>> |
>> + |
>> +-----------------------+---------------------------------+
>> + | | Validation | The project shall perform
>> |
>> + | | | validation to ensure that
>> the |
>> + | | | software will perform as
>> |
>> + | | | intended in the customer
>> |
>> + | | | environment.
>> |
>> +
>> +----------------+-----------------------+---------------------------------+
>> + | Design and | Software Development | A plan for how you will
>> develop |
>> + | Implementation | or Management Plan | the software that you are
>> |
>> + | | | intent upon developing
>> and |
>> + | | | delivering.
>> |
>> + | | |
>> |
>> + | | | The Software Development
>> Plan |
>> + | | | includes the objectives,
>> |
>> + | | | standards and life
>> cycle(s) to |
>> + | | | be used in the software
>> |
>> + | | | development process. This
>> plan |
>> + | | | should include:
>> Standards: |
>> + | | | Identification of the
>> Software |
>> + | | | Requirements Standards,
>> |
>> + | | | Software Design
>> Standards, |
>> + | | | and Software Code
>> Standards for |
>> + | | | the project.
>> |
>> + |
>> +-----------------------+---------------------------------+
>> + | | Software | To identify and control
>> major |
>> + | | Configuration | software changes, ensure
>> that |
>> + | | Management Plan | change is being properly
>> |
>> + | | | implemented, and report
>> changes |
>> + | | | to any other personnel or
>> |
>> + | | | clients who may have an
>> |
>> + | | | interest.
>> |
>> + |
>> +-----------------------+---------------------------------+
>> + | | Implementation | The project shall
>> implement the |
>> + | | | software design into
>> software |
>> + | | | code.
>> |
>> + | | |
>> |
>> + | | | Executable Code to
>> applicable |
>> + | | | tested software.
>> |
>> + |
>> +-----------------------+---------------------------------+
>> + | | Coding Standards | The project shall ensure
>> that |
>> + | | Report | software coding methods,
>> |
>> + | | | standards, and/or criteria
>> are |
>> + | | | adhered to and verified.
>> |
>> + |
>> +-----------------------+---------------------------------+
>> + | | Version Description | The project shall provide
>> a |
>> + | | Document (VDD) | Software Version
>> Description |
>> + | | | document for each
>> software |
>> + | | | release.
>> |
>> +
>> +----------------+-----------------------+---------------------------------+
>> + | Testing and | Software Test Plan | Document describing the
>> testing |
>> + | Software | | scope and activities.
>> |
>> + | Assurance
>> +-----------------------+---------------------------------+
>> + | Activities | Software | To define the techniques,
>> |
>> + | | Assurance/Testing | procedures, and
>> methodologies |
>> + | | Procedures | that will be used.
>> |
>> + |
>> +-----------------------+---------------------------------+
>> + | | Software Change | The project shall
>> regularly |
>> + | | Report / Problem | hold reviews of software
>> |
>> + | | Report | activities, status, and
>> results |
>> + | | | with the project
>> stakeholders |
>> + | | | and track issues to
>> resolution. |
>> + |
>> +-----------------------+---------------------------------+
>> + | | Software Schedule | Milestones have schedule
>> and |
>> + | | | schedule is updated
>> |
>> + | | | accordingly.
>> |
>> + |
>> +-----------------------+---------------------------------+
>> + | | Software Test | The project shall record,
>> |
>> + | | Report / Verification | address, and track to
>> closure |
>> + | | Results | the results of software
>> |
>> + | | | verification activities.
>> |
>> +
>> +----------------+-----------------------+---------------------------------+
>> + | Usability | Software User’s | The Software User Manual
>> |
>> + | | Manual | defines user instructions
>> for |
>> + | | | the software.
>> |
>> +
>> +----------------+-----------------------+---------------------------------+
>>
>> In an effort to remain lightweight and sustainable for open-source
>> projects, Table 1 above was condensed into a single artifact outline
>> --
>> 2.17.1
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20181201/70f5c156/attachment-0002.html>
More information about the devel
mailing list