[PATCH] eng/appendix-a: convert to a table

Joel Sherrill joel at rtems.org
Sat Dec 1 16:34:34 UTC 2018


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/999bef97/attachment-0001.html>


More information about the devel mailing list