Merge pull request #139 from eclipse-score/remove_score

removing s-core and place holder links

Author: masc2023

process/folder_templates/features/feature_name/safety_planning/index.rst

@@ -32,10 +32,10 @@ Feature Safety Planning
     - Adjust ``status`` to be ``valid``
     - Adjust ``safety`` and ``tags`` according to your needs
 
-.. list-table:: Feature <feature_name> Workproducts
+.. list-table:: Feature <feature_name> Work products
     :header-rows: 1
 
-    * - Workproduct Id
+    * - Work product Id
       - Link to process
       - Process status
       - Link to issue

process/folder_templates/modules/module_name/component_name/docs/component_classification.rst

@@ -154,7 +154,7 @@ Step 2: Determine (C): the uncertainty of finding systematic faults based on the
 
 | (C=1) shall be selected when none of the determined complexity measures indicate HM or NM.
 | (C=2) shall be selected when at least one of the determined complexity measures indicate HM or NM, but the gaps evaluated are acceptable, means
-|       the risk of systematic faults due to these gaps is sufficiently low in the context of S-CORE or manageable by mitigating the gaps.
+|       the risk of systematic faults due to these gaps is sufficiently low in the context of the project or manageable by mitigating the gaps.
 | (C=3) in all other cases.
 |
 

process/folder_templates/modules/module_name/docs/manual/safety_manual.rst

@@ -38,16 +38,16 @@ Introduction/Scope
 
 Assumed Platform Safety Requirements
 ------------------------------------
-| For the <S-CORE platform / module name> the following safety related stakeholder requirements are assumed to define the top level functionality (purpose) of the <S-CORE platform / module name>. I.e. from these all the feature and component requirements implemented are derived.
+| For the <Project platform / module name> the following safety related stakeholder requirements are assumed to define the top level functionality (purpose) of the <Project platform / module name>. I.e. from these all the feature and component requirements implemented are derived.
 | <List here all the stakeholder requirements, with safety not equal to QM, the module's components requirements are derived from.>
 
 Assumptions of Use
 ------------------
 
 Assumptions on the Environment
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-| Generally the assumption of the S-CORE platform SEooC is that it is integrated in a safe system, i.e. the POSIX OS it runs on is qualified and also the HW related failures are taken into account by the system integrator, if not otherwise stated in the module's safety concept.
-| <List here all the OS calls the S-CORE platform expects to be safe.>
+| Generally the assumption of the project platform SEooC is that it is integrated in a safe system, i.e. the POSIX OS it runs on is qualified and also the HW related failures are taken into account by the system integrator, if not otherwise stated in the module's safety concept.
+| <List here all the OS calls the project platform expects to be safe.>
 
 List of AoUs expected from the environment the platform / module runs on:
 
@@ -68,7 +68,7 @@ Assumptions on the User
 | As there is no assumption on which specific OS and HW is used, the integration testing of the stakeholder and feature requirements is expected to be performed by the user of the platform SEooC. Tests covering all stakeholder and feature requirements performed on a reference platform (tbd link to reference platform specification), reviewed and passed are included in the platform SEooC safety case.
 | Additionally the components of the platform may have additional specific assumptions how they are used. These are part of every module documentation: <link to add>. Assumptions from components to their users can be fulfilled in two ways:
 | 1. There are assumption which need to be fulfilled by all SW components, e.g. "every user of an IPC mechanism needs to make sure that he provides correct data (including appropriate ASIL level)" - in this case the AoU is marked as "platform".
-| 2. There are assumption which can be fulfilled by a safety mechanism realized by some other S-CORE platform component and are therefore not relevant for an user who uses the whole platform. But those are relevant if you chose to use the module SEooC stand-alone - in this case the AoU is marked as "module". An example would be the "JSON read" which requires "The user shall provide a string as input which is not corrupted due to HW or QM SW errors." - which is covered when using together with safe S-CORE platform persistency feature.
+| 2. There are assumption which can be fulfilled by a safety mechanism realized by some other project platform component and are therefore not relevant for an user who uses the whole platform. But those are relevant if you chose to use the module SEooC stand-alone - in this case the AoU is marked as "module". An example would be the "JSON read" which requires "The user shall provide a string as input which is not corrupted due to HW or QM SW errors." - which is covered when using together with safe project platform persistency feature.
 
 List of AoUs on the user of the platform features or the module of this safety manual:
 

process/folder_templates/modules/module_name/docs/release/release_note.rst

@@ -49,7 +49,7 @@ Release Note
 |  Disclaimer
 |  ----------
 |  This release note does not "release for production", as it does not come with a safety argumentation and a performed safety assessment.
-|  The work products compiled in the safety package are created with care according to a process satisfying standards, but the S-CORE project,
+|  The work products compiled in the safety package are created with care according to a process satisfying standards, but the as the project,
 |  being a non-profit and open source organization, can not take over any liability for its content.
 |
 | New Features

process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_package_fdr.rst

@@ -48,14 +48,14 @@ The purpose of this review checklist is to report status of the formal review fo
           - Comment
 
         * - 1
-          - Is a safety package provided which matches the safety plan (i.e. all planned workproducts referenced)?
+          - Is a safety package provided which matches the safety plan (i.e. all planned work products referenced)?
           - [YES | NO ]
           - <Rationale for result>
 
         * - 2
           - Is the argument how functional safety is achieved, provided in the safety package, plausible and sufficient?
           - NO
-          - The argument is intentionally not provided by S-CORE.
+          - The argument is intentionally not provided by the project.
 
         * - 3
           - Are the referenced work products available?

process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan.rst

@@ -36,7 +36,7 @@ Module Safety Plan
 Functional Safety Management Context
 ====================================
 
-This Safety Plan adds to the :ref:`process_safety_management` all the module development relevant workproducts needed for ISO 26262 conformity.
+This Safety Plan adds to the :ref:`process_safety_management` all the module development relevant work products needed for ISO 26262 conformity.
 
 Functional Safety Management Scope
 ==================================
@@ -58,21 +58,21 @@ Tailoring
 
 Additional to the tailoring in the SW platform project as defined in the :ref:`process_safety_management` we define here the additional tailoring on module level.
 
-- Excluded for this module are additionally the following workproducts (and their related requirements):
-  - <ISO 26262 reference>: <workproduct/requirement> - <Argumentation why it is not needed or replaced by another workproduct or activity.>
+- Excluded for this module are additionally the following work products (and their related requirements):
+  - <ISO 26262 reference>: <work product/requirement> - <Argumentation why it is not needed or replaced by another work product or activity.>
 
-Functional Safety Module Workproducts
-=====================================
+Functional Safety Module Work products
+======================================
 
-One set of workproducts for the module and one set for each component of the module:
+One set of work products for the module and one set for each component of the module:
 
-Module Workproducts List
-------------------------
+Module Work products List
+-------------------------
 
-.. list-table:: Module Workproducts
+.. list-table:: Module Work products
         :header-rows: 1
 
-        * - Workproduct Id
+        * - Work product Id
           - Link to process
           - Process status
           - Link to issue
@@ -122,8 +122,8 @@ Module Workproducts List
           - <WP status (manual)>
 
         * - :need:`wp__module_sw_build_config`
-          - `REPLACE_doc__software_development_plan`
-          - `copy('status', need_id='REPLACE_doc__software_development_plan')`
+          - :need:`gd_temp__software_development_plan`
+          - `copy('status', need_id='gd_temp__software_development_plan')`
           - <Link to issue>
           - <Link to WP>
           - <automated>
@@ -149,13 +149,13 @@ Module Workproducts List
           - :need:`doc__module_name_release_note`
           - :ndf:`copy('status', need_id='doc__module_name_release_note')`
 
-Component <name> Workproducts List
-----------------------------------
+Component <name> Work products List
+-----------------------------------
 
-.. list-table:: Component <name> Workproducts
+.. list-table:: Component <name> Work products
         :header-rows: 1
 
-        * - Workproduct Id
+        * - Work product Id
           - Link to process
           - Process status
           - Link to issue
@@ -252,16 +252,16 @@ In case an OSS element is used in the module, part 6 has to be filled out.
 OSS (sub-)component qualification plan
 ======================================
 
-For the selected OSS component the following workproducts will be implemented (and why):
+For the selected OSS component the following work products will be implemented (and why):
 
 If the OSS element is classified as a
     - component, then the below table shall match the above, adding the reasoning for tailoring of work products according to the OSS component classification.
-    - lower level component, then no workproducts additional to the component’s will be planned and activities below are part of the component’s issues.
+    - lower level component, then no work products additional to the component’s will be planned and activities below are part of the component’s issues.
 
-.. list-table:: OSS (sub-)component <name> Workproducts
+.. list-table:: OSS (sub-)component <name> Work products
         :header-rows: 1
 
-        * - Workproduct Id
+        * - Work product Id
           - Link to issue
           - Reasoning for tailoring
 

process/folder_templates/modules/module_name/docs/verification/module_verification_report.rst

@@ -33,7 +33,7 @@ Verification Report
     - Adjust ``safety`` and ``tags`` according to your needs
 
 
-This verification report is based on the `REPLACE_doc__verification_plan`.
+This verification report is based on the :need:`gd_temp__verification__plan`.
 It covers all the components of the above stated module.
 
 Verification Report contains:

process/general_concepts/score_building_blocks_concept.rst

@@ -21,16 +21,16 @@ Building blocks concept
 Building blocks meta model
 ++++++++++++++++++++++++++
 
-The following figure gives an overview about the building blocks of the **S-CORE** **Platform**
-(blue box, top, 2nd column). The objectives of the platform of the **S-CORE** platform include
+The following figure gives an overview about the building blocks of the project **Platform**
+(blue box, top, 2nd column). The objectives of the project platform include
 enabling of feature integration for different use cases and domains. This includes safety-critical
 applications. Thus the intention is, that the platform can be developed as a Safety
 Element out of Context (**SEooC**) (green box, top, 1 column). The objectives of the platform are
 expressed as concrete **Stakeholder Requirements** (blue box, top, 2nd column), which can be tested
 by provided **Platform Tests** (blue box, top, 5nd column) for reference hardware platforms. The
 platform consists of **Features** (yellow box, middle, 2nd column).
 
-Further **S-CORE** provides **Software Modules** (red box, middle, 1st column), which can also be
+Further the project provides **Software Modules** (red box, middle, 1st column), which can also be
 developed as a SEooC. A Software Module is defined as a **Component** (green box, middle, 2nd column)
 or a set of components realizing a Feature of the platform. In this sense a Software Module is the
 highest level component in our model. A Software Module represents e.g. executable code or a library.
@@ -63,15 +63,15 @@ to a Component.
 .. figure:: _assets/score_building_blocks_meta_model.drawio.svg
   :width: 100%
   :align: center
-  :alt: Building blocks overview for **S-CORE** platform
+  :alt: Building blocks overview for project platform
 
-  Building blocks overview for **S-CORE** platform
+  Building blocks overview for the project platform
 
 Building blocks example
 +++++++++++++++++++++++
 
 The following figure is an example to explain the elements from the meta model. The user of the
-**S-CORE** platform wants to use the feature key-value-store. For that the user must integrate
+project platform wants to use the feature key-value-store. For that the user must integrate
 the software module "kvstorage". As this modules dependence on another module, the user must also
 integrate the software module "json_al". The module "kvstorage" is built-up by the
 components "kvs" and "fs", where the module "json_al" contains only one component "json_al".

process/general_concepts/score_lifecycle_concept.rst

@@ -14,27 +14,25 @@
 
 .. _general_concepts_lifecycle:
 
-Lifecylce concept
+Lifecycle concept
 -----------------
 
-Contributions to the **S-CORE** project are driven by Change Requests.
+Contributions to the project are driven by Change Requests.
 
 As features are the main structuring element of the platform, new features are requested by
 a change request from type feature. The request may be supported by source code.
 A new feature request happens in the **Concept Phase**.
 
 During the **Development Phase** features are implemented and verified. The Development
 is planned, checked and adjusted to meet the requirements. Planning is also required from
-several standards especically to achieve functional safety.
+several standards especially to achieve functional safety.
 
 Features are improved during the **Maintenance Phase**. In case bugs are found, they are also
 fixed during this phase.
 
 .. figure:: _assets/score_lifecycle_model.drawio.svg
   :width: 100%
   :align: center
-  :alt: Lifecycle model for S-CORE
-
-  Lifecycle model for S-CORE
-
+  :alt: Lifecycle model for the project
 
+  Lifecycle model for the project

process/general_concepts/score_review_concept.rst

@@ -80,7 +80,7 @@ based on an implemented technical reviewer mechanism defined for the modified fi
 between reviewer(s) and author, the safety manager, security manager or quality manager can be added to the review to moderate a solution.
 
 The initial step for requirements and architecture is the (informal) GitHub review on every Pull-Request
-(resp. Change Request, see `REPLACE_doc__contr_guideline`)
+(resp. Change Request, see :need:`gd_guidl__change__change_request`)
 which creates or modifies one of these work products (subject to inspection).
 After this review the work products are in status "valid", which means they can be used for further development and verification steps.
 In this review the checklist entries shall be considered which are tagged as "incremental".