Cross Referens H Progsäk / DO-178B
KC Ledsyst / Title
Organisation/project compliance with H ProgSäk (E) / Document id
KC Ledsyst 14910: 41378/04
Name
Inga-Lill Bratteby-Ribbing, FMV
Peter Nummert, Lennart Öhman, S&T / Phone
018-12 02 63
08-587623 00 / Date
2005-04-06 / Rev
2.1 / Page
29(29)
Organisation/project compliance with H ProgSäk (E)
This is a template for evaluation of the extent to which an organisation or project fulfils the generic software safety requirements of HProgSäk (E). The evaluation is made against documented rules and regulations (routines methods, techniques, tools) and the competency profile of the organisation or project.
The template does not include any project or system specific safety requirements[1].
A special template for comparison of HProgSäk (E) requirements with some other generic software safety handbook or standard is available in [7].
Template adaptations:
Issue / InstructionTemplate:
٠ head / · Replace logotype and head information (organisation etc.) with applicable text.
٠ text / · Remove the template instructions and fix cross referenced footnotes.
· Replace XXX_DOC in text and column heads with
a) the name of the document used for the evaluation or
b) with the text “Org./proj. doc” etc. if more than one document[2] have to be referenced in this column or as an alternative to this
٠ table structure / b’) Add and name a new column for references to compliant require-ements of an organization or project document other than XXX_DOC (case a). Include a description of the column in “Legend” below.
Stakeholder table / · Remove the main tables irrelevant to the evaluated organisation[3].
Column:
٠ XXX_DOC etc. / · Give references to
i) applicable sections in XXX_DOC etc. (case a and b’ above) or
ii) [document ref. no]: applicable sections (case b).
٠ Compliance / · Indicate the degree of compliance (see “Legend”).
٠ Evidence / · Specify references verifying compliance.
٠ Rationale / · State reasons for non-compliance to the H ProgSäk requirement.
٠ Action / · Suggest remedy actions for insufficient compliance.
An evaluation of the extent to which an organisation or project fulfils the generic software safety requirements of HProgSäk (E) has been performed based on documented rules and regulations (routines, methods, techniques, tools) and the competency profile of the organisation or project.
Section 1 below details the prerequisites and status of this evaluation.
Section 2 contains tables for all requirements of H ProgSäk[4], each identified by a unique label (cf. “Legend”). The level of compliance is evaluated with respect to individual HProgSäk requirements.
Section 3 and 4 present acronyms and references used in this document.
1 Evaluation prerequisites
Provide information on the organisation, project and system evaluated ( e.g. name, system configuration, versions of referenced documents, special characteristics and prerequisites), whether the evaluation is completed or in progress, the planned /actual completion date of the evaluation etc.
Give also reference to the document specifying the system specific safety requirements for the software1.
Include all referenced documents in section 5.
For the organisation an update of the evaluation has to considered, if competency profile, applied activities/procedures or any other condition with implications on software production and safety have been changed after the time of the inventory.
For the project it is important to specify the intended context for the system (environment[5] and usage). Any change to the system or its context invalidates a previous evaluation and its documentation, which then has to be reconsidered and updated.
1.1 Organisation
1.2 Project
1.3 System
1.4 System environment
1.5 Operational/User profile
1.6 Scope
An evaluation can initially be conducted with respect to the organizational issues only6. As long as these are unchanged the result can be used for evaluation of the individual project, by complementing with the product specific aspects7 of the system software.
Specify here whether the scope of the software safety evaluation includes organizational aspects only or organizational as well as project aspects.
1.7 Document history
This evaluation is still in progress and planned to be completed in …
Version / Date / Evaluation status / Comments2 Compliance with HProgSäk (E) requirements
Based on the organisation’s documented regulations and competency profile the maturity with respect to software safety is compiled in the below tables[6].
In addition to this the general software safety requirements relevant to the software product under development[7] are recorded for the individual project together with the extent to which the selected set of requirements is fulfilled and verified (cf. [2]: 6.4.2)[8]. The rationale for unsatisfied requirement issues are described and recommended actions given for how to meet uncovered aspects of an individual requirement. As the software system develops, suggested actions are implemented and the evaluation document updated. The document will therefore be a useful part of the software documentation with the successive versions showing the progression towards full compliance with the safety requirements for the system software[9].
Legend:
Include below any notation added specifically for the actual evaluation.
Column / ExplanationH ProgSäk Id / · H ProgSäk Id is a unique requirement identity consisting of 3 parts:
° The 1st part (6.) is a unique number for the handbook H ProgSäk within FMV.
° The 2nd part is the section number in H ProgSäk where the requirement statement is found.
° The 3rd part is letter K followed by the sequence number for the requirement in the section.
· For a H ProgSäk Id associated to a basic requirement4 a reference is given to the section in table 5.1 or 5.2 where the basic requirement is listed (e.g. “6.421K1: Cf. 5.2.2.1”).
· A single H ProgSäk Id addressing several sections in ISO/IEC 12207 is below refined by appending the section number within quotes (e.g. 6.5223K1 ”6.3” in Table 5.2). One table entry per section is provided (see tables 5.1/5.2 below). A further refinement into subsections is made if needed for the evaluation (e.g. 6.5223K1 ”6.4.2.1” in [6]).
Critic. / · The criticality categories for which the requirement H ProgSäk Id applies are specified:
° H(igh), M(edium), L(ow) for software of high, medium and low criticality, respectively
° B(asic) for a requirement relevant to safety-critical as well as non-critical software.
XXX_DOC etc. / · References to matching requirements in the organisation/project documentation XXX_DOC etc. are provided in the format [document ref. no]: applicable section, or only applicable section if the column head specifies a single document.
a) Specified references are either one or a few direct references to matching requirement identities in XXX_DOC etc., or a broader reference to a section or entire chapter.
b) A parenthesized reference is used for a main or partial match to the H ProgSäk requirement.
c) “-“ denotes that the requirement is not at all covered by XXX_DOC etc. (further comments are then provided in the “Rationale ” and “Action” columns).
d) “+” indicates that matching references are listed in the subtable specified in the “Evidence” column (e.g. for a H ProgSäk Id representing a basic requirement which is satisfied and verified more information is provided in the corresponding subtable for basic requirements. The “Evidence” will then include a text of type “See 5.2.5.2.1”).
Evidence / · References are given to documents[10] verifying full/main/partial compliance (case a-b above).
Specific conditions needed for compliance are also specified.
· For a basic H ProgSäk requirement references to subtables 5.1 or 5.2 with verifying references are specified (e.g. by including text of type “See 5.2.5.2.1”).
Rationale / · Requirement areas/aspects not covered[11] by XXX_DOC etc. are specified (cases b-c above).
· Reasons to requirement areas not covered11 and to an uncompleted evaluation[12] are given.
Action / · Recommended remedy actions in case of insufficient compliance[13].
· Date for completion of an uncompleted evaluation12(unless specified under section 1.6 ).
Compliance: / · The degree of compliance is specified according to the following notations:
٠ Yes / Full
compliance: / The requirement is in all aspects satisfied and verified acc. to “Evidence”.
No need for “Rationale”/“Action”.
٠ Main / Mainly
compliant: / The requirement is in all significant aspects satisfied and verified (though not necessarily in every detail) acc. to “Evidence”[14].
Also when compliance can be deduced from inevitable implications, or for non-compliance exclusively under irrelevant circumstances –these compliance conditions are then specified in “Evidence”15.
٠ Part / Partial
compliance: / The requirement is partially satisfied and verified acc. to “Evidence”.
Also when compliance is achieved exclusively under certain circumstances –these compliance conditions are then specified in “Evidence”[15].
“Rationale” + “Action” are provided for unsatisfied aspects.
٠ No / No
Compliance: / The requirement is not or nearly not satisfied.
“Rationale” + “Action” are provided for unsatisfied aspects.
٠ N/A / Not
applicable: / The requirement is not relevant to the organisation/project[16].
“Rationale” for non-applicability are provided.
٠ – / Not
investigated: / Requirement satisfaction not yet verified or evaluated.
“Action” with planned completion date provided.
A table entry below with all three columns “Evidence”, “Rationale” and “Action” left blank is a sign of omission, which should be solved.
HProgSäk E Chapter 2. CLIENT/END-USER (FM)
2.1 Personnel /H ProgSäk Id / Critic. / XXX_DOC / Evidence / Rationale / Action / Compliance /
6.21K1 / HML / - / –
6.21K2 / HML / - / –
6.21K3 / HML / - / –
2.2 Control processes /
H ProgSäk Id / Critic. / XXX_DOC / Evidence / Rationale / Action / Compliance /
2.2.1 System safety planning, management and assessment /
6.221K1 / HML / - / –
6.221K2a / HML / - / –
6.221K2b / HML / - / –
6.221K2c / HML / - / –
2.3 The FM Defence Materiel Acquisition Process /
H ProgSäk Id / Critic. / XXX_DOC / Evidence / Rationale / Action / Compliance /
No requirements N/A /
2.4 Products /
H ProgSäk Id / Critic. / XXX_DOC / Evidence / Rationale / Action / Compliance /
2.4.1 TTFO, TFOTM (TTEM, TEMU) /
6.241K1 / HML / - / –
6.241K2 / HML / - / –
6.241K3 / HML / - / –
6.241K4 / HML / - / –
6.241K5 / HML / - / –
HProgSäk E Chapter 3. ACQUIRER (FMV)
3.1 Personnel /H ProgSäk Id / Critic. / XXX_DOC / Evidence / Rationale / Action / Compliance /
6.31K1 / HML / - / –
3.2 Control processes /
H ProgSäk Id / Critic. / XXX_DOC / Evidence / Rationale / Action / Compliance /
3.2.1 Project planning, management and assessment /
6.321K1: Cf. 5.2.2.1 / HML
B / - / –
3.2.2 System safety planning, management and assessment
6.322K1 / HML / - / –
6.322K2 / HML / - / –
6.322K3 / HML / - / –
6.322K4 / HML / - / –
6.322K5 / HML / - / –
3.2.3 Quality control
6.323K1: Cf.
5.2.2.2 / HML
B / - / –
3.2.4 Quality assurance
6.324K1: See
5.1.2.1 / HML
B / - / –
6.324K2a / HML / - / –
6.324K2b / HML / - / –
6.324K2c / HML / - / –
6.324K2d / HML / - / –
6.324K2e / HML / - / –
3.3 The FMV Defence Materiel Acquisition Process /
H ProgSäk Id / Critic. / XXX_DOC / Evidence / Rationale / Action / Compliance /
3.3.1 Studies /
3.3.2 Procurement
6.332K1: See
5.1.3.1 / HML
B / - / –
3.3.3 Operation and Maintenance (Lifecycle Management, LCM)
6.333K1: See
5.1.3.2 / HML
B / - / –
3.3.3.1 Modifications of a completed system
6.3331K1 / HML / - / –
6.3331K2 / HML / - / –
6.3331K3 / HML / - / –
6.3331K4 / HML / - / –
3.3.4 Disposal
3.4 Products /
H ProgSäk Id / Critic. / XXX_DOC / Evidence / Rationale / Action / Compliance /
3.4.1 Statement of Work (SOW)
6.341K1 / HML / - / –
6.341K2 / H / - / –
6.341K3 / HML / - / –
6.341K4 / HM / - / –
6.341K5 / H / - / –
6.341K6 / HML / - / –
6.341K7 / HML / - / –
3.4.2 Time Plans (Operational Plans) (TP)
3.4.3 Lifecycle Management Support (LCMS)
6.343K1a / HML / - / –
6.343K1b / HML / - / –
6.343K2 / H / - / –
3.4.4 Technical Specification (TS)
6.344K1 / HML / - / –
6.344K2 / HML / - / –
6.344K3 / H / - / –
6.344K4 / HML / - / –
6.344K5 / HM / - / –
6.344K6 / HML / - / –
HProgSäk E Chapter 4. SUPPLIER
4.1 Personnel /H ProgSäk Id / Critic. / XXX_DOC / Evidence / Rationale / Action / Compliance /
6.41K1 / HML / - / –
6.41K2a / HML / - / –
6.41K2b / HML / - / –
6.41K3 / H / - / –
6.41K4 / M / - / –
6.41K5 / HM / - / –
6.41K6 / HML / - / –
6.41K7 / HML / - / –
6.41K8 / HML / - / –
6.41K8a / H / - / –
6.41K8b / M / - / –
6.41K8c / L / - / –
6.41K8d / HML / - / –
4.2. Control processes /
H ProgSäk Id / Critic. / XXX_DOC / Evidence / Rationale / Action / Compliance /
4.2.1 Project planning, management and assessment
6.421K1: See
5.2.2.1 / HML
B / - / –
6.421K2 / HML / - / –
4.2.2 System safety planning, management and assessment
6.422K1 / HML / - / –
4.2.3 Quality control
6.423K1: See
5.2.2.2 / HML
B / - / –
4.2.4 Quality assurance
6.424K1: See
5.2.2.3 / HML
B / - / –
6.424K2 / HML / - / –
4.2.5 Configuration management
6.425K1a: See
5.2.2.4 / HML
B / - / –
6.425K1b: See
5.2.2.4 / HML
B / - / –
6.425K1c: See
5.2.2.4 / HML
B / - / –
4.3. Production processes /
H ProgSäk Id / Critic. / XXX_DOC / Evidence / Rationale / Action / Compliance /
6.43K1: See 5.2.3 / HML
B / - / –
6.43K2 / H / - / –
6.43K3 / H / - / –
6.43K4 / H / - / –
4.3.1 Development model
6.431K1: See 5.2.3.1 / HML
B / - / –
4.3.2 Development methodology
6.432K1: See 5.2.3.2 / HML
B / - / –