[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-0002.html>
More information about the devel
mailing list