ÚŘAD PRO OBRANNOU STANDARDIZACI, KATALOGIZACI A STÁTNÍ OVĚŘOVÁNÍ JAKOSTI ČESKÝ OBRANNÝ STANDARD Praha 2020 051665 1. vydání SMĚRNICE PRO ŘÍZENÍ BEZPORUCHOVOSTI A UDRŽOVATELNOSTI SOFTWARE ZAVÁDÍ STANAG 4174, Ed. 3 ALLIED RELIABILITY AND MAINTAINABILITY PUBLICATIONS Spojenecké publikace pro bezporuchovost a udržovatelnost ARMP-9, Ed.1 GUIDE TO THE MANAGEMENT OF SOFTWARE R&M Směrnice pro řízení bezporuchovosti a udržovatelnosti software NAHRAZUJE Nenahrazuje žádný standard nebo normu
Transcript
ÚŘAD PRO OBRANNOU STANDARDIZACI, KATALOGIZACI A STÁTNÍ OVĚŘOVÁNÍ JAKOSTI
ČESKÝ OBRANNÝ STANDARD
Praha 2020
051665 1. vydání
SMĚRNICE PRO ŘÍZENÍ BEZPORUCHOVOSTI A UDRŽOVATELNOSTI SOFTWARE
ZAVÁDÍ STANAG 4174, Ed. 3
ALLIED RELIABILITY AND MAINTAINABILITY PUBLICATIONS
Spojenecké publikace pro bezporuchovost a udržovatelnost
ARMP-9, Ed.1
GUIDE TO THE MANAGEMENT OF SOFTWARE R&M
Směrnice pro řízení bezporuchovosti a udržovatelnosti software
NAHRAZUJE Nenahrazuje žádný standard nebo normu
ČOS 051665 1. vydání
2
(VOLNÁ STRANA)
ČOS 051665 1. vydání
3
ČESKÝ OBRANNÝ STANDARD
SMĚRNICE PRO ŘÍZENÍ BEZPORUCHOVOSTI A UDRŽOVATELNOSTI SOFTWARE
Základem pro tvorbu tohoto standardu byly originály následujících dokumentů:
STANAG 4174, Ed.3
ALLIED RELIABILITY AND MAINTAINABILITY PUBLICATIONS
Spojenecké publikace pro bezporuchovost a udržovatelnost
ARMP-9, Ed.1 GUIDE TO THE MANAGEMENT OF SOFTWARE R&M
Směrnice pro řízení bezporuchovosti a udržovatelnosti software
ČOS 051665, 1. vydání, zavádí STANAG 4174, Ed.3, který přejímá ARMP-9, Ed.1 (GUIDE TO THE MANAGEMENT OF SOFTWARE R&M – Pokyny k managementu bezporuchovosti a udržovatelnosti software) do prostředí České republiky. Standard poskytuje definice pro oblast bezporuchovosti a udržovatelnosti softwaru a dále se věnuje podstatě softwaru, jeho chybovosti, upgradům a zabezpečovatelnosti. V kapitole Specifikace požadavků na bezporuchovost a zabezpečovatelnost (R&S) je probrán management vad, metriky určené pro sledování R&S a smluvní definice potřebné k jejich ošetření. V další části je popsán jednoduchý a flexibilní rámec pro řízení programu R&S, plán a případ R&S. Největší pozornost je věnována vlastnímu životnímu cyklu R&S softwaru, od etapy koncepce až k etapě vyřazení. Poslední část standardu je věnována uzavírání smluv na R&S softwaru, progresivní zajištění požadavků řízení změn v průběhu životního cyklu, přijetí softwaru a smlouvám na dodání a zabezpečení pro softwarové aplikace. Standard je vydán jako česká verze ARMP-9, Ed. 1.
Nahrazení standardů (norem)
Tento standard nenahrazuje žádný dokument.
Související dokumenty
V tomto ČOS jsou normativní odkazy na následující citované dokumenty (celé nebo jejich části), které jsou nezbytné pro jeho použití. U odkazů na datované citované dokumenty platí tento dokument bez ohledu na to, zda existují novější vydání/edice tohoto dokumentu. U odkazů na nedatované dokumenty se používá pouze nejnovější vydání/edice dokumentu (včetně všech změn).
AAP-48 NATO SYSTEM LIFE CYCLE PROCESSES
Procesy životního cyklu systémů v NATO (zavedeno ČOS 051655)1
ACMP-7 NATO CONFIGURATION MANAGEMENT – GUIDANCE ON THE APPLICATION OF ACMPs 1 – 6
Management konfigurace uplatňovaný v NATO – pokyny pro použití ACMP-l až ACMP-6 (zavedeno ČOS 051610, 2. vydání)
ČOS 051616 TERMINOLOGIE NATO PRO BEZPORUCHOVOST A UDRŽOVATELNOST POUŽÍVANÁ V ARMP
1 V současné době existuje AAP-48 Edition B, Version 1 – NATO SYSTEM LIFE CYCLE
PROCESSES – Procesy životního cyklu systému v NATO. Bude zavedena ČOS 051655, 2. vydání, do 31. 7. 2014.
ČOS 051665 1. vydání
7
ČOS 051617 POŽADAVKY NATO NA BEZPORUCHOVOST A UDRŽOVATELNOST
ČOS 051619 SMĚRNICE PRO VYTVÁŘENÍ DOKUMENTŮ NATO PRO BEZPORUCHOVOST A UDRŽOVATELNOST
ČOS 051649 SMĚRNICE PRO ŘÍZENÍ BEZPORUCHOVOSTI A UDRŽOVATELNOSTI V PROVOZU
Def Stan 00-42 Part 3 RELIABILITY AND MAINTAINABILITY ASSURANCE GUIDE
Pokyny pro zajišťování bezporuchovosti a udržovatelnosti
Def Stan 00-60 Part 0 APPLICATION OF INTEGRATED LOGISTIC SUPPORT (ILS).
Použití integrovaného logistického zabezpečení (ILS)
IEEE Standard 610.12
STANDARD GLOSSARY OF SOFTWARE ENGINEERING TERMINOLOGY
IEEE Standard 829 SOFTWARE AND SYSTEM TEST DOCUMENTATION
IEEE Standard 1016 RECOMMENDED PRACTICE FOR SOFTWARE DESIGN DESCRIPTIONS
ISO 12207
ČSN ISO/IEC 12207
SOFTWARE LIFE CYCLE PROCESSES
Informační technologie – Procesy v životním cyklu softwaru
RTCA DO-178 SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICATION
SAE JA 1000:2012 RELIABILITY PROGRAM STANDARD
SAE JA 1000-1:2012 RELIABILITY PROGRAM STANDARD IMPLEMENTATION GUIDE
SAE JA 1002:2012 SOFTWARE RELIABILITY PROGRAM STANDARD
SAE JA 1003:2012 SOFTWARE RELIABILITY PROGRAM IMPLEMENTATION GUIDE
SAE JA 1004:2012 SOFTWARE SUPPORTABILITY PROGRAM STANDARD
SAE JA 1005:2012 SOFTWARE SUPPORTABILITY PROGRAM IMPLEMENTA-TION GUIDE
SAE JA 1006:2012 SOFTWARE SUPPORT CONCEPT
ČOS 051665 1. vydání
8
Zpracovatel ČOS
Vojenský výzkumný ústav, s. p., RNDr. Milan Čepera, Ph.D.
Použité zkratky, značky a definice
Zkratky
Zkratka Český význam Anglický význam
AAP Spojenecká administrativní publikace
Allied Administrative Publication
ACMP Spojenecká publikace pro management konfigurace
Allied Configuration Management Publication
ACT Roční frekvence změn Annual Change Traffic
ARMP Spojenecká publikace pro bezporuchovost a udržovatelnost
Allied Reliability and Maintainability Publication
BIT Zabudovaný test Built-in test
BITE Zabudované testovací zařízení Built-in test equipment
BSI Britský institut pro standardizaci British Standards Institute
CASE Softwarové inženýrství pomocí počítače
Computer Aided Software Engineering
CEIL Seznam smluvních koncových položek
Contract End Items List
CM Management konfigurace Configuration Management
CMMI Integrovaný model vyzrálosti způsobilosti
Capability Maturity Model Integrated
COTS Komerčně nakoupený Commercial Off-The-Shelf
ČOS Český obranný standard ---
Def Stan Obranný standard Spojeného království
UK Defence Standards
DID Popisy datových položek Data Items Descriptions
EEPROM Elektricky mazatelná programovatelná paměť pouze pro čtení
Electrically Erasable Programmable Read Only Memory
FRACAS Systém záznamů o poruchách a nápravná opatření
Failure Reporting and Corrective Action System
HITL Člověk v simulační smyčce Human in the loop
IEC Mezinárodní komise pro elektrotechniku
International Electrotechnical Commission
IEEE Institut pro elektrotechnické a elektronické inženýrství
Institute of Electrical and Electronic Engineers
ČOS 051665 1. vydání
9
IETM Interaktivní elektronický technický manuál
Interactive Electronic Technical Manual
ILS Integrované logistické zabezpečení
Integrated Logistic Support
IPR Práva na duševní vlastnictví Intellectual Property Rights
ISC Výbor pro vynášení výroků o událostech
Incident Sentencing Committee
ISO Mezinárodní organizace pro normalizaci
International Organization for Standardization
IV&V Nezávislé ověřování a validace Independent Verification and Validation
JA Dvoupísmenný kód u standardů a pokynů SAE pro pozemní vozidla (J) a letectví (A)
Two character code for SAE ground vehicle (J) and aerospace (A) standards
and guidelines
KSLOC Tisíce (K) zdrojových řádků kódu Thousands (K) of Source Lines of Code
MTBF Střední doba mezi poruchami Mean Time Between Failure
MTTF Střední doba do poruchy Mean Time to Failure
NATO Organizace severoatlantické smlouvy
North Atlantic Treaty Organization
POFOD Pravděpodobnost poruchy na povel
Probability of failure on Demand
PROM Programovatelná permanentní paměť
Programmable Read Only Memory
R&M Bezporuchovost a udržovatelnost Reliability and Maintainability
R&S Bezporuchovost a zabezpečovatelnost
Reliability and Supportability
RTCA Radiotechnická komise pro letectví
Radio Technical Commission for Aeronautics
RFP Požadavek na návrh Request for Proposal
ROCOF Intenzita výskytu poruch Rate of Occurrence of Failure
SAE Společnost automobilového inženýrství
Society of Automotive Engineers
SAS Analýza zabezpečení softwaru Support Analysis for Software
SDP Plán vývoje softwaru Software Development Plan
SEI Institut softwarového inženýrství Software Engineering Institute
SLOC Zdrojové řádky kódu Source Lines of Code
SMP Plán managementu softwaru Software Management Plan
UML Jednotný modelový jazyk Unified Modelling Language
V&V Ověřování a validace Verification and Validation
Definice Software
Instrukce prováděné počítačem, jako protiklad fyzického zařízení, na kterém běží (hardware). Software můžeme rozdělit do dvou hlavních typů: systémový software a aplikační software, neboli aplikační programy.
Software
The instructions executed by a computer, as opposed to the physical device on which they run (the "hardware"). Software can be split into two main types: system software and application software or application programs.
Firmware
Kombinace hardwarového zařízení a počítačových instrukcí nebo počítačo-vých dat, které jsou uloženy jako software pouze pro čtení v hardwarovém zařízení. Software nemůže být snadno modifikován programovým řízením (ISO 12207).
Firmware
The combination of a hardware device and computer instructions or computer data that reside as a read only software on the hardware device. The software cannot readily be modified under program control (ISO 12207).
Systémový software
Systémový software (také je znám jako operační software) je jakýkoliv software, který je vyžadován k zabezpečení vytváření nebo provádění aplikačních programů, ale není specifický pro žádnou speciální aplikaci. Příkladem systémového softwaru jsou operační systémy.
System Software
System software (also known as Operating software) is any software that is required to support the production or execution of application programs but that is not specific to any particular application. Operating systems are examples of system software.
Bezporuchovost softwaru
Pravděpodobnost bezporuchové ope-race softwarového programu během specifikovaného času za specifikova-ných podmínek (SAE JA 1002).
Software Reliability
The probability of failure free operation of a software program for a specified time under specified conditions (SAE JA 1002).
Udržovatelnost softwaru
Snadnost, se kterou může být softwa-rový systém nebo komponenta modifiko-vána, aby se opravily vady, zlepšil výkon
Software Maintainability
The ease with which a software system or component can be modified to correct faults, improve performance or other
ČOS 051665 1. vydání
11
nebo další atributy, nebo aby se adapto-val na měnící se prostředí. Také je to soubor atributů, které souvisejí s úsilím potřebným k provedení specifických modifikací (SAE JA 1004).
attributes, or adapt to a changing environment. Also a set of attributes that bear on the effort needed to make specified modifications (SAE JA 1004).
Zabezpečovatelnost softwaru
Soubor atributů návrhu softwaru, souvi-sející vývojové nástroje a metody a infrastruktura prostředí zabezpečení, které umožňují uskutečnit zabezpečo-vací činnosti (SAE JA 1004).
Software Supportability
A set of attributes of software design, the associated development tools and methods, and the support environment infrastructure that enables support activities to be accomplished (SAE JA 1004).
Podniková aplikace
COTS softwarový produkt, který integruje veškeré funkce napříč organizací do jednoho počítačového systému, který může sloužit všem jednotlivým potřebám organizace. Příkladem podnikových aplikací jsou SAP R/3, Mincom a PeopleSoft (CAN MASIS, DAOD 3001-0).
Enterprise Application
A COTS Software product that integrates all functions across an organization onto a single computer system that can serve all the particular needs of the organization. Examples of Enterprise Applications are SAP R/3, Mincom and PeopleSoft. (CAN MASIS, DAOD 3001-0).
Chyba
Rozdíl mezi počítanou, pozorovanou, měřenou hodnotou, podmínkou a skutečnou, specifikovanou teoreticky správnou hodnotou nebo podmínkou (IEEE standard 610.12).
Error
The difference between a computed, observed, measured value, condition and the true, specified, theoretically correct value or condition. (IEEE Standard 610.12).
Selhání (porucha) (softwaru)
Neschopnost systému nebo komponenty provádět její požadované funkce v mezích specifikovaných požadavků na provedení. (IEEE standard 610.12).
Failure (software)
The inability of a system or component to perform its required functions within specified performance requirements. (IEEE Standard 610.12).
Vada (softwaru)
Nepředvídaný stav, který způsobuje, že funkční softwarová jednotka při provádění požadované funkce selže (SAE JA 1003 – A.2.1).
Fault (software)
An accidental condition that causes a software functional unit to fail to perform its required functions (SAE JA 1003 - A.2.1).
Bug
Viz Vada (softwaru).
Bug
See Fault (software).
Základní úroveň (Softwarová základní úroveň)
Specifikace, dokument nebo produkt, který je formálně přezkoumán a smluven po daný čas a od té doby slouží jako
Baseline (Software Baseline)
A specification, document or product that has been formally reviewed and agreed upon at a given time and thereafter
ČOS 051665 1. vydání
12
základ pro další vývoj. Může být pouze změněn, je-li nastavován a schválen, pomocí oficiálního řídicího postupu.
serves as the basis for further development. It can only be changed if justified and approved through a formal control procedure.
Model
Fyzikální, matematická nebo jiná logická reprezentace systému, entity reálných slov, fenoménů nebo procesu.
Model
A physical, mathematical or otherwise logical representation of a system, real world entity, phenomenon or process.
Simulace
Zavedení modelu v průběhu času.
Simulation
The implementation of a model over time.
Simulátor
Člověk v simulační smyčce (HITL).
Simulator
A human in the loop (HITL) simulation.
Ověřování
Potvrzení objektivního důkazu zkouškou, že jsou splněny specifikované požadavky (IEEE 610.12).
Verification
Confirmation by the examination of objective evidence that specified requirements have been fulfilled (IEEE 610.12).
Ověřování a validace (V&V)
Proces stanovení, zda jsou požadavky na systém nebo komponentu úplné a správné, produkty každé vývojové etapy splňují požadavky nebo podmínky na ně vložené v předchozí etapě a že konečný systém nebo komponenta jsou ve shodě se specifikovanými požadavky (IEEE 610.12).
Verification and Validation (V&V)
The process of determining whether the requirements for a system or component are complete and correct, the products of each development stage fulfill the requirements or conditions imposed by the previous stage and the final system or component complies with specified requirements (IEEE 610.12).
Nezávislé ověřování a validace (IV&V)
Ověření a validace prováděná organizací, která je technicky, manažersky a finančně nezávislá na organizaci provádějící vývoj (IEEE 610.12).
Independent Verification and Validation (IV&V)
Verification and validation performed by an organization that is technically, managerially, and financially independent of the development organization (IEEE 610.12).
Aktualizace
Nová verze existujícího softwarového programu, která je modifikována k odstranění vad.
Update
New version of an existing software program that has been modified to remove faults.
Upgrade
Nová verze existujícího softwarového programu, která je modifikována, aby poskytla novou schopnost.
Upgrade
New version of an existing software program that has been modified to provide a new capability.
ČOS 051665 1. vydání
13
PROVÁDĚCÍ SHRNUTÍ EXECUTIVE SUMMARY Mnoho obranných systémů se spoléhá na počítače, že fungují správně, proto je nezbytné, aby byl podpůrný software řízen jako integrální součást celého systému. Ačkoliv je povaha hardwaru a softwaru odlišná, existuje mnoho podobností, které mají být využity pro to, aby byl software řízen efektivně.
Many Defence systems rely on computers to function correctly; therefore it is essential that the supporting Software be managed as an integral part of the whole system. Although the nature of Hardware and Software is different, there are many similarities, which should be exploited to manage Software effectively.
To je běžný pohled, který navzdory návrhu a testovacímu úsilí není schopen vyprodukovat software, který nemá vady. Proto má specifikace bezporuchovosti softwaru zahrnovat cíle, jako je vyvaro-vání se vadám, odolnost vůči vadám, vyhledávání vad a oprava vad, navíc k celkovým kvantitativním požadavkům. Nejdůležitější mechanismy manage-mentu založeného na provedení pro-gramu bezporuchovosti softwaru jsou označovány jako „Plán bezporuchovosti a zabezpečovatelnosti softwaru“ a „případ R&S softwaru“2. Plán a případ jsou manažerské nástroje obecného účelu, které jsou vhodné pro použití v nejedné sféře systémového inženýrství.
It is a common view that despite design and testing effort, it will not be possible to produce software that has no faults. Therefore, the specification of Software Reliability should include objectives such as fault avoidance, fault tolerance, fault detection and fault correction, in addition to the overall quantitative requirements. The principal mechanisms for the performance-based management of a Software Reliability program are termed the "Software Reliability & Supportability (R&S) Plan" and the “Software R&S Case”.2 The Plan and Case are general-purpose management tools which are suitable for use in many fields of system engineering.
Úspěch, nebo cokoli jiného v jakémkoliv projektu se opírá o kvalitní přípravu smluv na pořízení a zabezpečení. Jsou-li smlouvy v dobrém stavu, dobře napsané a úplné, existuje vysoká pravděpodob-nost, že výsledný produkt bude splňovat jejich požadavky a bude dodávat zamýšlenou schopnost v průběhu život-ního cyklu vybavení, za optimálních nákladů.
The success or otherwise of any project rests to a large extent on the quality of its procurement and support contracts. If these are taut, well written and comprehensive, there is a high probability that the resulting product will meet its requirements and deliver the intended capability throughout the equipment life cycle, at optimum cost.
KAPITOLA 1 ÚVOD
CHAPTER 1 INTRODUCTION
1 Obecně
1 General S rostoucí sofistikací moderního vybavení, vzrůstající miniaturizací
With the growing sophistication of modern equipment, the increasing
2 SAE JA –1002, paragraf 4.3 „Základní rámec managementu“.
SAE JA – 1002 para 4.3 „Management Framework“
ČOS 051665 1. vydání
14
elektroniky a přesunu od analogového k digitálnímu zpracování, začleňuje stále více systémů nějakou formu počítačové technologie k monitorování nebo řízení jejich provedení. Zatímco se pro složité platformy, jako lodě nebo letadla, tyto systémy pouze očekávají, jsou stále více využívány u zařízení denního použití, jako mobilní telefony nebo pračky. Výsledkem tohoto procesu je, že nové systémy se při rozšíření provedení stávají stále více a více závislé na softwaru.
miniaturization of electronics and the move from analogue to digital processing, more and more systems incorporate some form of computer technology to monitor or control their performance. While this is only to be expected for complex platforms like ships or aircraft, it is equally true of domestic devices like mobile phones and washing machines. As a result, new systems are becoming more and more dependent on Software to enhance performance.
U obranných zařízení tvoří software inte-grální část systému a musí být brán v úvahu ve shodě se všemi dalšími rysy během životního cyklu vybavení. Indivi-duální charakteristiky jakéhokoliv softwaru budou přispívat k celkové úrovni bezporuchovosti a udržovatel-nosti, dosažené systémem jako celkem.
For Defence equipment, Software forms an integral part of a system and must be considered in concert with all other features, throughout the equipment life cycle. The individual characteristics of any Software will contribute towards the overall levels of Reliability and Maintainability achieved by the system as a whole.
Ačkoli je u softwaru sdíleno mnoho atributů s mechanickými a elektronickými systémy, má také některé speciální vlastnosti: neopotřebovává se nebo nedegraduje v průběhu času3. Mnoho problémů spojených s hybridními systémy vzniká na rozhraní mezi soft-warem a fyzickými prvky systému. Software má být nicméně řízen podobným způsobem jako hardware, v rámci celkového programu systému. Jestliže mají být minimalizována rizika, musí být tento proces zahájen při co nejranější příležitosti.
Although Software shares many attributes with mechanical and electronic systems, it also possesses some special properties: in that it does not wear out or degrade over time3. Many of the problems associated with hybrid systems arise from the interface between Software and the physical elements of a system. Nevertheless, Software should be managed in a similar manner to hardware, within an overall system programme. This process must be initiated at the earliest opportunity if project risks are to be minimized.
Zatímco bezporuchovost je právě tak významná u softwaru, jako u mechanic-kých a elektronických systémů, koncepci udržovatelnosti není jednoduché použít. V čistě softwarovém kontextu je udržo-vatelnost vytlačena pojmem zabezpečo-
While Reliability is just as relevant to Software as it is to mechanical or electronic systems, the concept of Maintainability is not so easy to apply. In a purely Software context, Maintainability has been superseded by the term
3 Software se neopotřebovává v mechanickém smyslu, avšak změna provozního prostředí, způsobená zastaráváním softwaru, může dát vzniku podobným problémům. Software does not wear out in a mechanical sense; however the changing operating environment, causing software obsolescence, can give rise to similar issues.
ČOS 051665 1. vydání
15
vatelnost, která je širší koncepcí, zahrnující návrh, nástroje, metody a prostředí pro zabezpečení. Koncepce bezporuchovosti a zabezpečovatelnosti (R&S) byla vyvíjena softwarovou komu-nitou mnoho let tak, aby odrážela činnosti požadované pro vývoj a udržení softwaru v průběhu životního cyklu produktu (viz SAE JA 1002, ČOS 051655).
Supportability, which is a broader concept embracing the design, tools, methods and support environment. The Reliability & Supportability (R&S) concept has been developed by the Software community over a number of years, to reflect the activities required to develop and sustain Software over a producťs life cycle (see SAE JA 1002, AAP-48).
Nehledě na rozšíření počítačů do všech kroků života a milionů řádků kódu napsaných každý rok, pouze malá část softwarově intenzivních systémů vstupuje úspěšně do užívání v rámci rozpočtu a harmonogramu. To předsta-vuje obrovskou ztrátu investic a riziko pro provozní provedení. Je proto nezbytné, aby byly požadavky na software pečlivě stanoveny, precizně specifikovány, odpovídajícně demonstrovány a pořizování bylo řízeno s velkou péčí.
Despite the spread of computers into all walks of life and the millions of lines of code written every year, only a small proportion of software intensive systems successfully enter Utilization within budget and on schedule. This represents an enormous loss of investment and risk to operational performance. It is therefore essential that Software requirements are carefully determined, precisely specified, adequately demonstrated and the procurement managed with great care.
Management softwaru může být obvykle, a u R&S softwaru především, podnětný. Je proto nezbytné využívání dobrých nástrojů a technik softwarového inženýrství v rámci celkového rámce systémů. Metodologie však musí být přizpůsobena tomu, aby splnila potřeby projektů na individuálním základě. Pro minimalizaci rizika projektu se mají v průběhu etapy koncepce hledat rady a pomoc specialistů.
The management of Software in general and Software R&S in particular can be challenging. The application of good Software Engineering tools and techniques within an overall systems framework is therefore essential. However, methodologies must be tailored to meet the needs of projects on an individual basis. To minimize project risk, specialist advice and assistance should be sought during the Concept Stage.
U obranných systémů je často využíván komerčně nakupovaný (COTS) software. Existují však některé speciální ohledy, které se mohou použít pouze u COTS aplikací, jež mohou zahrnovat: nedostatek při řízení konfigurace, licencování, zastarávání a zabezpe-čovatelnost. Tyto problémy mají být aktivně určeny v plánu managementu životního cyklu, neboť mohou mít významný dopad na cenu zabezpečení v průběhu životního cyklu systému.
Commercial Off The Shelf (COTS) software is frequently employed within defence systems. However, there are some special considerations, which only apply to COTS applications, which may include: lack of configuration control, licensing, obsolescence and supportability. These issues should be actively addressed within the Life Cycle Management Plan, since they can have a significant impact on support costs over the life of the system.
ČOS 051665 1. vydání
16
Se zřetelem na rozmanitost a složitost softwaru neexistuje universální řešení pro efektivní dodání, neřku-li pro bezpo-ruchové a zabezpečovatelné programy.
In view of the diversity and complexity of Software, there is no universal solution to delivering effective, let alone reliable and supportable programs.
1.1 Smysl
1.1 Aim Smyslem ČOS 051665 je poskytnout pokyny sponzorům4, manažerům, zaměstnancům projektu a dodavatelům pro pořizování a údržbu bezporuchového a zabezpečovatelného systémového softwaru během životního cyklu vybavení.
The aim of ARMP-9 is to provide guidance to Sponsors4, Managers, Project Staff and Suppliers for the procurement and maintenance of Reliable and Supportable System Software, throughout the equipment life cycle.
1.2 Účel
1.2 Purpose Účelem těchto pokynů je: The purpose of this guide is to:
a. popsat podstatu a důležitost softwaru, a. Describe the nature and importance of Software;
b. popsat specifikace požadavků na R&S,
b. Describe the specification of Software R&S requirements;
c. popsat nástroje a techniky, které se mohou použít pro posuzování a prokazování R&S softwaru,
c. Describe tools and techniques that can be used for assessing and demonstrating Software R&S;
d. popsat principy a základní rámec požadovaný pro dodání a udržení bezporuchového a zabezpečovatel-ného softwaru,
d. Describe the principles and framework required for procuring and sustaining reliable and supportable Software;
e. popsat role a odpovědnosti spojené s dodáním a udržením bezporucho-vého a zabezpečovatelného softwaru,
e. Describe the roles and responsibilities associated with procuring and sustaining reliable and supportable Software;
f. popsat smluvní ujednání dopo-ručovaná pro dodání a udržení bez-poruchového a zabezpečovatelného softwaru.
f. Describe contractual arrangements recommended for procuring and sustaining reliable and supportable Software.
1.3 Použitelnost
1.3 Applicability Tyto pokyny jsou použitelné pro národní projekty a projekty spolupráce pro pozemní, námořní, letecké a společné systémy, k využití všem sponzorům, manažerům a dodavatelům, kteří mají odpovědnost za vývoj, pořízení
This guide is applicable to national and collaborative projects for Land, Sea, Air or joint systems for the use of all sponsors, managers and suppliers who have responsibility for the development, procurement or support of Software. The
4 Sponzoři jsou představováni uživatelem, nastavují celkové požadavky na systém a poskytují financování programu. Sponsors represent the User, set the overall system requirements and provide programme funding.
ČOS 051665 1. vydání
17
nebo zabezpečení softwaru. Standard se snaží poskytnout úplný základní rámec a řídicí principy pro efektivní management R&S softwaru během životního cyklu vybavení.
document seeks to provide a comprehensive framework and guiding principles for the effective management of Software R&S throughout the equipment life cycle.
Pokyny jsou především využitelné u softwaru používaného v rámci, nebo pro přímé zabezpečení obranného systému, včetně:
The guide is mainly applicable to Software used within or in direct support of Defence systems, including:
- aplikačního softwaru, - Application Software;
- zákazníkem postaveného softwaru, kritického vůči požadavkům úkolu,
- Custom-built mission critical Software;
- komerčně nakupovaného softwaru adaptovaného pro specifické aplikace,
- COTS Software adapted for specific applications;
- operačního systému, - Operating system;
- softwaru kritického vůči bezpečnosti. - Safety critical Software.
Principy by však také mohly být použity na obecnější software, včetně podnikových aplikací5.
However, the principles could also be applied to more general software including Enterprise Applications.5
1.4 Související dokumenty
1.4 Related Documents STANAG 4174 Spojenecké publikace pro bezporuchovost a udržovatelnost
STANAG 4174: Allied Reliability and Maintainability Publications
ARMP-1 Požadavky NATO na bezporuchovost a udržovatelnost
ARMP-4 Směrnice pro zpracování dokumentů s požadavky NATO na bezporuchovost a udržovatelnost
ARMP-6 Směrnice pro řízení bezporuchovosti a udržovatelnosti v provozu
ARMP-7 Terminologie NATO pro bezporuchovost a udržovatelnost použitá v ARMP
ARMP-1 NATO Requirements for Reliability and Maintainability.
ARMP-4 Guidance for Writing NATO R&M Requirement Documents.
ARMP-6 Guidance for Managing In-Service R&M.
ARMP-7 NATO R&M Terminology Applicable to ARMPs.
KAPITOLA 2 POVAHA SOFTWARU
CHAPTER2 THE NATURE OF SOFTWARE
2 Pokud jde o pojmy, software je soubor instrukcí, které umožňují počítači
2. In simple terms, Software is a set of instructions, which enables a computer
5 Viz definici: Jako v CAN MASIS – poskytující úplný přehled o zdrojích. See definition: such as CAN MASIS - providing total asset visibility.
ČOS 051665 1. vydání
18
provádět danou funkci. Soubor instrukcí se skládá z jednoduchých, po sobě následujících instrukcí nebo řádků kódu, které mohou obsahovat složky složitých algoritmů vyžadujících paralelní zpracování. Softwarové instrukce mohou být psané v mnoha počítačových jazycích, které jsou poté přeloženy nebo převedeny do strojových instrukcí. Tento proces se v průběhu času vyvíjí, aby umožnil programátorům psát počítačový kód mnohem pohodlněji. Softwarové programy se mohou lišit velikostí: od několika řádků kódu pro velmi jednoduché aplikace, k mnoha milionům řádků komplexních systémů nebo sys-tému systémů. V sofistikovaných platfor-mách, jako je bojový letoun, může být zapojeno mnoho počítačů, aby vytvořily polygonální síť a existuje zde významný počet softwarových programů spuštěných současně, aby efektivně provozovaly celý systém.
to perform a given function. The instruction set consists of simple, sequential instructions or lines of code, which may contain the components of complex algorithms requiring parallel execution. Software instructions may be written in a variety of computer languages, which are then translated or converted to machine instructions. This process has evolved over time to enable programmers to write computer code more conveniently. Software programs can vary in size from a few lines of code for a very simple application to many million lines for complex systems or systems of systems. In sophisticated platforms such as fighter aircraft, many computers can be connected to form a distributed network and a significant number of Software programs executed concurrently, to operate the entire system efficiently.
2.1 Software se od hardware liší v mnoha zřetelech, které mohou být sumarizovány následovně:
2.1 Software differs from Hardware in a number of ways, which may be summarized as follows:
a. software není hmotný produkt, jako rádio nebo stroj, ale soubor kódovaných instrukcí, který je uchováván v paměťovém zařízení, jako je PROM, EEPROM, CD, paměťová karta, pružný disk nebo pevný disk.
a) Software is not a tangible product like a radio or an engine, but a set of coded instructions, which is stored on a memory device, such as a PROM, EEPROM, CD, memory stick, floppy disc or hard drive.
b. na rozdíl od hardwaru je přenos mezi vývojovým a produkčním softwarem relativně jednoduchý, ačkoli proces vyžaduje extenzivní testování a vhodnou dokumentaci. Jakmile je vývoj hotov, může být vytvořeno jaké-koliv množství kopií z originálu softwaru. Inherentní charakteristiky, včetně R&S každé kopie, budou identické ve vztahu k originálu programu, za předpokladu externích faktorů, jako je prováděcí platforma, další aplikace běžící na platformě a síťová připojení, pokud nějaká jsou, které jsou také identické. Mnoho-násobná reprodukce softwaru však
b) Unlike hardware, the transition between development and production Software is relatively simple, although the process requires extensive testing and proper documentation. Once development is complete, any number of copies can be made from the master Software. The inherent characteristics, including R&S of every copy will be identical to the master program, providing external factors, such as executing platform, other applications running on the platform and network connections, if any, are also identical. Multiple reproduction of the Software,
ČOS 051665 1. vydání
19
bude také obsahovat vady, které mohou být přítomny v původní originální verzi.
however, will also include any faults, which may be present in the original master version.
c. softwarové programy zpravidla mohou být použity nesčetněkrát, bez opotřebování. Ačkoli se software neopotřebovává, trpí vlivy zastarávání. To je důležitý problém, který je zapotřebí vzít v úvahu. Životní cyklus softwaru je často podobný hardwaru, na němž je provozován, který může být v rozsahu od desktop počítače až po komplexní zbraňový systém. Jak hardware stárne a mění se technologie, jsou prováděny modifikace a jsou zaváděna nová rozhraní. Tyto hardwarové změny mohou vyžadovat modifikace softwaru, které mají často za následek zavedení vady. Jestliže se na ně narazí, budou vyžadovat následnou opravu. Dokumentace pro zabezpečení, jestliže není udržována na původní úrovni přes-nosti, může způsobit při pokusu udržet řízení konfigurace další obtíže softwaru. Ke konci životnosti systému se může ukázat jako omezená dostupnost programátorů znalých původního softwarového jazyka nebo kódu. Vývoj softwaru a nástrojů pro údržbu, které se jeví jako specializované balíčky, mohou mít nakonec na novém hardwaru nedlouhou funkci, čímž se zavádí dodatečná rizika pro údržbu předmětu softwarové aplikace.
c) In principle, Software programs can be used any number of times without wearing out. Although Software does not wear out, it suffers from the effects of obsolescence. This is an important issue that requires consideration. The life cycle of Software is often similar to that of the underlying hardware, which may range from a desktop computer to a complex weapon system. As the hardware ages and technology changes, modifications are made and new interfaces are introduced. These hardware changes may require modifications to the Software, which often result in faults being introduced. When encountered, these will require further correction. Supporting Documentation, if not maintained to the original level of accuracy, could cause further difficulties when attempting to maintain the configuration control of the Software. Towards the end of the service life of a system, the availability of programmers, knowledgeable in the original Software language or code, may also become scarce. Finally, Software development and maintenance tools, which are specialized packages, may no longer function on new hardware, thereby introducing additional risk to the maintenance of the subject Software application.
d. software není ovlivněn fyzikálními podmínkami, ačkoli hardware pro zabezpečení může být ovlivněn hodně,
d) Software is not affected by physical conditions, although the supporting hardware may well be.
e. software může být spouštěn po mnoho let bez speciálních úprav, ačkoli media, na kterých je držen, mohou být předmětem poškození nebo zastarávání,
e) Software can be stared for many years, without special arrangements, although the media on which it is held may be subject to deterioration and obsolescence.
ČOS 051665 1. vydání
20
f. často se předpokládá, že software je bezporuchový, neboť není porušen v mechanickém smyslu. Může však selhat při provozování za některých okolností, jako výsledek chyb návrhu nebo neúplného testování.
f) It is frequently assumed that Software is reliable since it does not break in a mechanical sense. However, it can fail to operate correctly under certain circumstances as a result of design errors or incomplete testing.
g. neodhalené vady budou v softwaru zůstávat a mohly by způsobit poruchu v závislosti na vstupních datech nebo vstupech z jiných systémů. Nápravná opatření musí zahrnovat orgán pro návrh nebo určenou organizaci pro zabezpečení a řízení konfigurace udržovaného softwaru.
g) Undetected faults will remain in the Software and could cause failures, depending on the input data or input from other systems. Corrective action must involve the design authority or designated support organization and configuration control of the Software maintained.
h. softwarové inženýrství vyvinulo specifický slovník, který je zapotřebí pochopit, aby byl software dobře řízen. Zatímco mnoho pojmů je podobných jako v tradičním inženýrství, velký počet je specifický pro software (viz ČOS 051616 & přílohu A).
h) Software engineering has developed a specific vocabulary, which needs to be understood if Software is to be well managed. While many terms are similar to traditional engineering, a number are Software specific (see ARMP-7 & Annex A).
i. obecně je mnohem obtížnější provést vyčerpávající testování softwaru, než hardwaru. Konečné přijetí však zahrnuje celý test systému (za použití integrovaného softwaru i hardwaru) v reprezentativním provozním pro-středí.
i) In general, it is more difficult to conduct comprehensive tests on Software than Hardware. However, final acceptance should include a whole system test (using integrated Software and Hardware) in a repre-sentative operating environment.
2.2 Protože se mnoho obranných systémů spoléhá na správnou funkci počítačů, je nezbytné, aby byl software pro zabezpečení řízen jako integrální součást celého systému. I když je podstata hardwaru a softwaru rozdílná, existuje mnoho podobností, které mají být pro efektivní řízení softwaru využívány.6
2.2 Since many defence systems rely on computers to function correctly, it is essential that the supporting Software be managed as an integral part of the whole system. Although the nature of Hardware and Software is different, there are many similarities, which should be exploited to manage Software effectively.6
Většina softwaru bude mít následující charakteristiky:
Most Software will possess the following characteristics:
a. Jazyk – softwarové programy jsou psány v jednom z mnoha počítačo-vých jazyků. Ty jsou uspořádány od
a) Language – Software programs are written in one of many computer languages. These range from low-
6 Viz SAE JA – 1003 a 1005
See SAE JA - 1003 and 1005.
ČOS 051665 1. vydání
21
nízkoúrovňových generických jazyků, jako je strojový kód, k vysokoúrovňo-vým specializovaným jazykům, jako je C++ nebo JAVA. Pro aplikace s vyso-kou úrovní kritické bezpečnosti mohou být použity pouze velmi speciální jazyky, jako je ADA nebo Assembler. Volba jazyka bude záviset na pohotovosti programátorů, složi-tosti aplikace a požadované operační rychlosti systému. Je-li v systému používáno více jazyků, je zapotřebí pečlivě řídit rozhraní mezi rozdílnými moduly.
level generic languages like Machine Code to high-level specialized languages like C++ or JAVA. For highly specialized safety critical applications, only very special languages such as ADA or Assembler should be used. The choice of language will depend on the availability of programmers, the complexity of the application and the required system operating speed. If multiple languages are used within a system, the interface between different modules will need to be managed carefully.
b. Velikost - velikost softwarového programu může být měřena v řádcích kódu, funkčních bodech nebo bytech. Čím je větší program, tím je větší vývojový tým a tím je obtížnější jej vyvinout.
b) Size: The size of a Software program can be measured in lines of code, function points or bytes. The larger a program, the bigger the development team and the more difficult it will be to develop.
c. Modularita – na pomoc vývojářům softwaru mohou být větší programy rozděleny do modulů. Každý modul se stává podprogramem, který může být vyvíjen nezávisle a poté je spojen s ostatními moduly, aby vytvořil větší aplikaci. Je-li zapotřebí upgradovat složitý program kvůli rozšíření provedení nebo odstranění vad, je mnohem jednodušší vyvinout, zafixovat nebo podpořit modulární návrh. Pro vytváření nových aplikací může být také možné relativně jednoduše kombinovat moduly z různých zdrojů.
c) Modularity: To assist Software development, large programs can be partitioned into modules. Each module becomes a sub program, which can be developed independently, then combined with other modules to form a larger application. If a complex program needs to be upgraded to enhance performance or remove faults, it is much easier to develop, fix or sustain a modular design. It may also be possible to combine modules from different sources to create new applications relatively easily.
d. Utajení – mnoho aplikací včleňuje některou formu utajovaného systému. To může obsahovat informační neporušenost, která začleňuje činnosti, jako je šifrování, omezení přístupu a firewall. Takové systémy jsou navrženy tak, aby skýtaly ochranu před počítačovými viry a neautorizovanými zásahy.
d) Security: Many applications incorporate some form of security system. This may include information integrity, which incorporates activities such as encryption, access restrictions and firewalls. These systems are designed to afford protection from computer viruses and unauthorized intervention.
ČOS 051665 1. vydání
22
2.3 Zabezpečení při používání
2.3 Utilization Support. Jakmile vybavení vstoupí do etapy využívání7, má být software systému zabezpečován jedinou navrženou organizací8, která bude odpovědná za:
Once equipment enters the Utilization Stage7, the system Software should be supported by a single nominated organization8 which will be responsible for:
a. udržování originálu programu nebo zdrojového kódu aplikace (to nemusí být vždy možné, pokud nejsou dodržována práva na duševní vlastnictví (IPR)),
a) Maintaining the master program or application source code. (This may not always be possible if Intellectual Property Rights(IPR) are not held);
b. prostředí softwarového inženýrství, b) Software engineering environment;
c. technické dokumenty (jak je požadováno plánem vývoje softwaru (SDP)),
c) Engineering documents (as required by Software Development Plan (SDP);
d. analýzu zabezpečení softwaru (SAS), d) Support Analysis for Software (SAS);
g. management upgrade a aktualizací, g) Upgrade and update management;
h. výcvik. h) Training.
2.4 Management vad
2.4 Fault Management. Jestliže se při používání setkáme s vadami, má se to oznámit určené organizaci, s využitím záznamu o incidentech (viz ČOS 051649 FRACAS). Má proběhnout vyšetřování, aby se potvrdil problém a stanovilo se, zda může být incident připsán systémovému softwaru, hardwaru, uživateli nebo postupům. Byl-li incident způsoben softwarem, je zapotřebí identifikovat základní vadu, neboť může být přítomna ve všech zavedených systémech.
If faults are encountered in the field, they should be reported to the identified organization using incident reports (see ARMP-6 FRACAS). These should be investigated to confirm the problem and determine whether the incident can be attributed to the system Software, Hardware, user or procedures. If the incident was caused by Software, the underlying fault will need to be identified, since it may be present in all fielded systems.
Softwarové vady jsou normálně řešeny v dávkách a uvolňovány do míst zavedení jako periodické aktualizace, buď jako nové vydání, nebo softwarová
Software faults are normally resolved in batches and released to the field as periodic updates, either as a new release or Software patch. However, safety
7 Viz ČOS 051662, 2. vydání. See AAP-48.
8 Např. centrum softwarového inženýrství, agentura pro zabezpečení softwaru nebo orgán pro návrh. e.g. Software Engineering Centre, Software Support Agency or Design Authority.
ČOS 051665 1. vydání
23
záplata (patch). Vady kritické na bezpečnost však mají být fixovány s vyšší prioritou a uvolněny hned jako nouzové aktualizace ve formě softwarové záplaty.
critical faults should be fixed with a higher priority and released immediately as emergency updates in the form of a Software patch.
2.5 Upgrade
2.5 Upgrades Funkcionalita obranného systému může být modifikována, aby se zlepšila bezpo-ruchovost, zvětšila schopnost/provedení nebo rozšířilo použití o nové provozní prostředí. Konfigurace hardware a pro-vozní prostředí mohou být ve výsledku měněny a to může vyžadovat upgrade softwaru. Aby se toho úspěšně dosáhlo, má být nejprve revidována specifikace softwarových požadavků (SRS), aby se zdokumentovala nová schopnost a aby se co nejúplněji specifikovaly požadavky na testování9. Upgrady softwaru se mohou přidržovat stejného vývojového cyklu, jako původní aplikace (viz ISO 12207).
The functionality of a defence system may be modified, to improve reliability, enhance capability/performance or extend use to new operational environments. As a result, the hardware configuration and operating procedures may be changed and this will require the Software to be upgraded. To achieve this successfully the Software Requirements Specification (SRS), should first be revised, to document the new capability and specify the test requirements as comprehensively as possible.9 Software upgrades should follow the same development cycle as the original application (see ISO 12207).
Jakmile byl upgrade plně vyvinut, má se dokončit proces uvolnění softwaru, aby byla zajištěna zabezpečovatelnost a vhodnost vydání. Aby se udrželo řízení konfigurace napříč počítačovým parkem, má být distribuce a instalace upgradu softwaru přísně řízena.
Once an upgrade has been fully developed it should complete the Software Release process to ensure supportability and suitability for issue. To maintain configuration control across the fleet, the distribution and installation of software upgrades should be strictly controlled.
Upgrady a aktualizace se tam, kde je to možné, mají kombinovat, aby se minima-lizoval počet vydání softwaru a tedy i potíže u uživatele. Může být také vhodné kombinovat hlavní vydání softwaru s příhodným bodem v harmo-nogramu preventivní údržby hardwaru.
Upgrades and updates should be combined where possible, to minimize the number of Software releases and therefore inconvenience to the User. It may also be appropriate to combine a major Software release with a convenient point in the Hardware preventative maintenance schedule.
2.6 Zabezpečovatelnost
2.6 Supportability Koncepce udržovatelnosti hardwaru se u softwaru nesnadno využívá, neboť
The concept of Hardware Maintainability does not readily apply to Software since
9 Testování softwaru je málokdy úplné díky těžkostem zátěžového testování (simulace reálných prostředí a extrémních podmínek) v rámci normálních omezení nákladů a času. Software testing is seldom exhaustive due to the difficulty of stress testing (simulating real environments and extreme conditions), within the normal constraints of cost and time.
ČOS 051665 1. vydání
24
se předpokládá jednoduchost, se kterou může být systém obsluhován nebo opra-vován. Proto se software pokrývá pojmem zabezpečovatelnost10. Z před-chozích diskusí je evidentní, že u soft-waru nemůže uživatel nebo údržbář provádět údržbu softwarového kódu. Všechny opravy jsou prováděny v určené organizaci na originálu programu, kde je k dispozici nezbytná dokumentace, tech-nické prostředí a podmínky. Co je pro určenou organizaci významné, je stabilita softwaru, spolu s jednoduchostí, se kterou může být aplikace doplněna, testována a duplikována, se zaměstnanci a zdroji dostupnými v průběhu života softwaru. Navíc, metoda a snadnost, se kterou může být software nahrán do systému, má vliv na zabezpečovatelnost systému.
it is concerned with the ease with which a system can be serviced or repaired. Therefore Software is covered by the term Supportability10. From the previous discussion it is evident that for Software, the User or Maintainer cannot carry out maintenance on the Software code. All repairs are carried out by the nominated organization on the master program, where the necessary documentation, engineering environment and conditions are available. What is relevant to the nominated organization is the stability of the Software along with the ease with which an application can be amended, tested and duplicated, with the staff and resources available over the life of the Software. In addition the method and ease with which Software can be loaded into the system has an influence on system Supportability.
KAPITOLA 3 SPECIFIKACE POŽADAVKŮ NA R&S SOFTWARU
CHAPTER 3 SPECIFYING SOFTWARE R&S REQUIREMENTS
3.1 Bezporuchovost
3.1 Reliability Požadavky na bezporuchovost jsou obvykle souborem pro celý systém, který většinou sestává z hardwarových i soft-warových komponent. Proto mohou být požadavky na bezporuchovost softwaru odvozeny od požadavků na bezporucho-vost systému. Požadavky na bezporu-chovost softwaru a jejich správná speci-fikace jsou nejkritičtějším prvkem při dosahování dobré R&S softwaru. Toho by mohlo být dosaženo buď přidělením bezporuchovosti systému, nebo, kde je to vhodné, jako specifický požadavek. Problémy, které mohou být brány v úvahu, uvažujeme-li separátní poža-davky na bezporuchovost softwaru, zahrnují:
Reliability requirements are usually set for an entire system, which mostly consists of hardware and software components. Hence Software reliability requirements should be derived from the system reliability requirements. Software reliability requirements, and their correct specification, are the most critical element in achieving sound Software R&S. This could either be achieved as a system reliability allocation or, where appropriate, as a specific requirement. Issues, which should be taken into account when considering separate software reliability requirements, include:
10 Viz koncepci zabezpečení v SAE JA 1006. See support concept SAE JA 1006.
ČOS 051665 1. vydání
25
a. kritičnost poruchy celého systému, a) Criticality of failure for whole system;
b. dobu na zotavení z poruchy, b) Time to recover from a failure;
c. vliv poruchy na software nebo datové prvky,
c) Impact of a failure on software or data elements;
d. požadovaný zásah operátora poté, co se porucha objeví.
d) Required intervention of an operator after a failure has occurred.
Aby byly požadavky na bezporuchovost softwaru smysluplné, mají být specifikovány kvantitativně, což bude vyžadovat použití vhodných metrik.
To be meaningful, software reliability requirements should be specified quantitatively, which will require the application of suitable metrics.
Tradiční míry bezporuchovosti u hard-waru, jako je střední doba do poruchy (MTTF) nebo intenzita poruch (viz ČOS 051619), nutně neodpovídají při využití u softwarových aplikací. Zatímco bezporuchovost je u hardwaru založena na kombinaci systémové a náhodné poruchy, bezporuchovost softwaru je stanovena pomocí inherentních chyb a proto může být uvažována jako zcela systémová. Avšak nepředvídatelnost omylů u programátorů a podmínky pro zpracování programu často činí to, že se poruchy softwaru objevují ve své podstatě náhodně.
The traditional reliability measures for hardware, such as Mean Time to Failure (MTTF) or failure rate (see ARMP-4) are not necessarily appropriate for use with Software applications. While hardware reliability is based on a combination of systematic and random failures, Software reliability is determined by inherent errors and therefore can be considered completely systematic. However, the unpredictability of mistakes by programmers and the conditions of program execution often makes software failures appear to be random in nature.
3.2 Bezporuchovost softwaru silně závisí na minimalizaci počtu defektů v kódu a efektivnosti jakékoliv činnosti oprav, provedené při její opravě. Softwarové defekty jsou charakterizovány vadami, poruchami a nepřesnostmi, které jsou definovány v kapitole Definice.
3.2 Software reliability depends heavily on minimizing the number of defects in the code and the effectiveness of any repair activity undertaken to correct them. Software defects are characterized by faults, failures and errors, which are defined in Annex A.
Je důležité poznamenat rozdíl mezi vadou a poruchou. Pojem porucha je vztažen k chování programu a může se objevit jedině, když je prováděn software. Vada je spíše vlastností programu, než rys jeho chování a je běžně nazývána „bug“.
It is important to note the distinction between fault and failure. The term failure relates to the behaviour of a program and can only occur when the software is executed. A fault is a property of the program rather than a feature of its behaviour and is commonly called a "bug".
3.3 Bezporuchovost systému je obvykle spojena s časem. V rámci bezporucho-vosti softwaru mohou být brány v úvahu tři typy doby:
3.3 System Reliability is usually related to time. In terms of Software Reliability three types of time should be taken into consideration:
a. doba provádění: doba, kterou procesor stráví prováděním programu,
a) Execution time: The time spent by a processor in executing a program;
ČOS 051665 1. vydání
26
b. kalendářní doba: časový údaj, b) Calendar time: Time of day;
c. uplynulá doba: doba od zahájení provádění programu, včetně doby čekání a doby provádění dalších programů.
c) Elapsed time: The time since start of software execution, including waiting time and execution time of other programs.
Vztah mezi dobou a poruchami, což je jeden z možných parametrů specifikace bezporuchovosti softwaru, pak může být vyjádřena veličinou, jako je:
The relation between time and failures, being one of the possible parameters for Software Reliability specifications, may then be expressed by quantities such as:
a. časový interval mezi poruchami, a) Time interval between failures;
b. doba před poruchou (nebo bezporuchová provozní perioda),
b) Time before failure (or failure free operating period);
c. intenzita nebo hustota poruch (počet poruch za jednotku času)11.
c) Failure intensity or density (the number of failures per unit time). 11
Pokud počet poruch tvoří část specifikace, je důležité uvažovat potíže spojené s poruchami i dobu odhalení. Mimoto i následky poruchy systému mohou být také promyšlené, včetně:
When the number of failures forms part of the specification, it is important to consider the severity of a failure and the time of manifestation. Furthermore, the consequences of system failure should also be well thought-out, including:
a. ztráty jakékoliv funkce kritické na bezpečnost,
a. Loss of any safety critical functions;
b. ztráty jakékoliv funkce kritické vůči úkolu,
b. Loss of any mission critical functions;
c. přijatelný rozsah ztráty dat, c. Tolerable amount of data loss;
d. zásadní informace, které musí být chráněny před poruchou.
d. Vital information that must be protected from failures.
3.4 Management vad
3.4 Fault Management Je to obvyklá představa, že nehledě na úsilí návrhu a testování nebude možné produkovat software, který nebude mít žádné vady. Proto má specifikace bezporuchovosti softwaru zahrnovat cíle, jako je vyvarování se vadám, odolnost vůči vadám, vyhledávání vad a oprava vad, navíc k celkovým kvantitativním požadavkům:
It is a common view that despite design and testing effort, it will not be possible to produce software that has no faults. Therefore, the specification of Software Reliability should include objectives such as fault avoidance, fault tolerance, fault detection and fault correction, in addition to the overall quantitative requirements:
a. vyvarování se vadám: Snaha získat software napoprvé právě za použití oficiálních technik, jako je integrovaný
a) Fault Avoidance: Endeavor to get the software right first time using formal techniques such as the
11 Toto je charakteristika umožňující výpočet související bezporuchovosti softwaru jako funkci času,
předpokládajíc použití stochastických procesů v Poissonově rozdělení. This characteristic allows the calculation of associated Software Reliability as a function of time, assuming stochastic processes such as Poisson apply.
ČOS 051665 1. vydání
27
model vyzrálosti způsobilosti (CMMI) z Institutu softwarového inženýrství nebo přístup, který zastává RTCA 00178.
Software Engineering Institute's Capability Maturity Model Integrated (CMMI) or the approach advocated by RTCA 00178.
b. odolnost vůči vadám: Vlastnost návrhu, která umožňuje systému pokračovat v provozu12 navzdory vadám softwaru nebo návrat ke známé bezpečné podmínce. Je to koncepce chyb, kdy jedna příčina ne-způsobí poruchu a obvykle využívá nadbytečnosti paralelních softwa-rových funkcionalit nebo zařazení člověka do zkušební smyčky (HITL). Odolnost vůči vadám může vyžadovat další nebo záložní hardware.
b) Fault Tolerance: A property of design which allows a system to continue to operate12 despite software faults or return to a known safe condition. This is the no single point of failure concept and commonly employs redundancy, with parallel software functionality, or with a human in the loop (HITL) approach. Fault Tolerance may require additional or redundant hardware.
c. vyhledávání vad: Vlastnost návrhu, která k monitorování softwaru sys-tému využívá techniku programových hlídacích (diagnostických) programů, jako je zabudovaný test (BIT) nebo zabudované testovací zařízení (BITE). Ty by mohly kontrolovat kri-tické parametry a jejich limity, prová-dět nezávislé kontroly shodnosti jako míru zavádění systému. Typicky jsou využívány, aby poskytly varování a omezily nebo bezpečně vypnuly procesy před tím, než selžou.
c) Fault Detection: A property of design, which uses watchdog programs techniques to monitor system Software such as built in test (BIT) and built in test equipment (BITE). These might check critical parameters and their limits, conduct independent consistency checks as measure system loading. Typically these are used to provide warnings and limit or safely shut down processes before they fail.
d. oprava vad: V podstatě se to týká samoopravného softwaru, což je velmi pokročilá koncepce. Nyní se většina oprav provádí manuálně.
d) Fault Correction: In principle this concerns self healing software, which is a very advanced concept. Currently most correction is done manually.
3.5 Metriky
3.5 Metric Častou metrikou užívanou při stanovování kvality softwaru je počet vad na 1000 řádků kódu. Při vyšetřování, zda byl takový požadavek splněn, mohou být použity techniky, jako je simulace Monte Carlo. Známý počet vad (nasazených bugů) je vědomě vložen do programu; software je poté testován a podíl detekovaných nasazených vad může být využit pro dovození celkového počtu vad,
A common metric used in determining Software quality is the number of faults per 1000 lines of code. To investigate whether such a requirement has been met, techniques such as Monte Carlo Simulation can be applied. A known number of faults (seeded bugs) are deliberately inserted in a program; the software is then tested and the proportion of seeded faults detected can
12 Toto může být v degradovaném módu, zejména u funkcí kritických na bezpečnost. This may be in a degraded mode especially for safety critical functions.
ČOS 051665 1. vydání
28
které zbývají v programu. Příklady softwarových metrik jsou uvedeny v příloze A.
be used to infer the total number of faults remaining in the program. Examples of software metrics are at Annex B.
3.6 Smluvní definice
3.6 Contractual Definitions Abychom se vyhnuli komerčním sporům, musí být klíčové pojmy zahrnující vadu, poruchu, bezporuchovost a zabezpečo-vatelnosti jasně definovány ve smlouvě. Poznámka: Definice jsou obsaženy v kapitole Definice.
To avoid commercial disputes, key terms; including fault, failure, reliability and supportability, must be clearly defined in the contract. Note: Definitions are contained in Annex A.
KAPITOLA 4 VYTVOŘENÍ PROGRAMU R&S SOFTWARU
CHAPTER 4 DEVELOPING A SOFTWARE R&S PROGRAMME
4. Účelem této kapitoly je popsat jedno-duchý a flexibilní základní rámec pro management programu bezporuchovosti softwaru, založený na provedení. Nejdůležitější mechanismy jsou označeny jako „Plán R&S softwaru“ a „Případ R&S softwaru“13. Plán a případ jsou obecně účelové manažerské nástroje, které jsou vhodné pro použití v mnoha oborech systémového inženýrství.
4. The aim of this chapter is to describe a simple and flexible framework for the performance-based management of a Software Reliability program. The principal mechanisms are termed the “Software R&S Plan” and the “Software R&S Case”.13 The Plan and Case are general-purpose management tools which are suitable for use in many fields of system engineering.
4.1 Plán R&S softwaru
4.1 The Software R&S Plan Plán R&S softwaru je dokument, který popisuje činnosti, které mají být provedeny v průběhu vývoje, aby se zajistilo, že:
The Software R&S Plan is a document that describes the activities that should be performed throughout development to ensure that:
a. požadavky na R&S jsou odvozeny od a zůstávají ve shodě s požadavky na úroveň systému,
a) Requirements for Software R&S are derived from and remain consistent with system level requirements;
b. požadavkům na R&S softwaru je porozuměno a jsou uživatelem zavedeny,
b) Requirements for Software R&S are understood and implemented by the Supplier;
c. případ R&S softwaru je udržován, aby poskytl přesný a aktuální záznam postupu oproti požadavkům.
c) A Software R&S Case is maintained to provide an accurate and current record of progress against the requirement.
13 SAE JA -1002, paragraf 4.3 „Základní rámec managementu“. SAE JA-1002 para 4.3 "Management Framework".
ČOS 051665 1. vydání
29
Plán R&S má tvořit integrální část plánu vývoje softwaru, který postupně tvoří část celkového plánu projektu.
The R&S plan should form an integral part of the Software Development plan, which in turn forms part of the overall project plan.
4.2 Případ R&S softwaru
4.2 The Software R&S Case Případ R&S softwaru je zdrojem pro důkaz, který poskytuje zajištění, že byl učiněn pokrok v plnění požadavků na R&S systému. Důkaz má být čas od času v průběhu projektu analyzován, aby se zajistilo, že vývoj R&S softwaru je odpovídající a vyhovující požadavkům na úroveň systému. Případ má také poskytnout ujištění, že požadavkům na R&S bylo dodavatelem porozuměno a že každá nesrovnalost byla vyřešena.
The Software R&S Case is a repository for evidence which provides assurance that progress has been made in meeting a system's R&S requirements. The evidence should be analyzed from time to time throughout the project, to ensure the software R&S development is consistent and compliant with system level requirements. The Case should also provide assurance that the R&S requirements are understood by the Supplier and that any discrepancies have been resolved.
Kombinace plánu a případu R&S poskytuje prostředky pro sledování postupu vůči záměrům bezporuchovosti. Plán a případ zabezpečují koncepci odstraňování časných vad a nepřetržitou prevenci vad v průběhu životního cyklu softwaru. Plán poskytuje perspektivní pohled na procesy, činnosti a požadavky na provedení se zamýšlenou bezporuchovostí, zatímco případ poskytuje důkazy o dosahování bezporuchovosti softwarového produktu, což je dokumentováno kvantitativními i kvalitativními mírami provedení.
The R&S Plan and R&S Case in combination provide a means of tracking progress, against a reliability goal. The Plan and Case support the concept of early fault removal and continued fault prevention throughout the Software life cycle. The Plan provides a forward view of intended reliability processes, activities, and performance requirements, while the Case provides evidence of software product reliability achievement as documented by quantitative and qualitative performance measures.
Pomoc s vytvářením a používáním plánů a případů R&S může být nalezena v pokynech pro zavedení bezporuchovosti softwaru SAE (SAE JA 1003), které definují praktiky zavedení programu bezporuchovosti softwaru v celkovém základním rámci systémového inženýrství. Jsou zde popsány postupy pro ustavení R&S softwaru v programu v průběhu zvolených činností životního cyklu, které jsou přizpůsobeny systému. Jsou shrnuty četné analýzy, metody a techniky návrhu a ověřování a jsou poskytnuty odkazy.
Assistance with the creation and use of R&S Plans and Cases may be found in the SAE Software Reliability Implementation Guide (SAE JA 1003), which defines practices for the implementation of a Software Reliability programme within an overall systems engineering framework. Practices are described for establishing a Software R&S programme through the selection of life cycle activities which are tailored to a system. Numerous analysis, design and verification methods and techniques are summarized and references
ČOS 051665 1. vydání
30
Pokyny pro přizpůsobení programů bezporuchovosti softwaru obsahují úvahy o bezpečnosti a utajení, integraci COTS softwaru a sběr příslušných dat. Jsou použitelné pro všechny projekty, které začleňují software, zejména systémy kritické na úkol nebo bezpečnost, kde je nezbytná vysoká bezporuchovost softwaru. Jsou poskytnuty pokyny pro všechny organizace zahrnuté do návrhu, vývoje, pořízení, integraci, používání a zabezpečení softwaru.
provided. Guidelines for tailoring Software Reliability programmes include safety and security concerns, integration of COTS software and collection of appropriate data. They are applicable to all projects incorporating software, particularly mission or safety critical systems, where high software reliability is essential. Direction is provided for all organizations involved in the design, development, procurement, integration, use and support of software.
KAPITOLA 5 DODÁVÁNÍ A ŘÍZENÍ R&S SOFTWARU
CHAPTER 5 DELIVERING & MANAGING SOFTWARE R&S
5. Životní cyklus softwaru musí být uvažován v kontextu životního cyklu systému, který je v případě systému vyzbrojování NATO popsán v ČOS 05165514 a rozděluje životní cyklus do šesti přizpůsobitelných etap:
5. A Software life cycle must be considered in the context of system life cycle, which, in the case of NATO armament systems, is described in AAP-4814 and divides a life cycle into six tailorable stages:
a. koncepce, a) Concept;
b. vývoj, b) Development;
c. produkce, c) Production;
d. využívání, d) Utilization;
e. zabezpečení, e) Support;
f. vyřazení. f) Retirement.
Tato kapitola o dodávání a managementu R&S softwaru je uspořádána podle AAP-4815. Většina činností se objeví během vývoje softwaru, ačkoli management
This chapter, on the delivery and management of Software R&S, is aligned with AAP-4815. Most activities will occur during software Development although configuration management, version
14
Etapy a procesy životního cyklu systému v NATO.
NATO System Life Cycle Stages and Processes. 15
AAP-48 (ČOS 051655) organizuje procesy do čtyř skupin: - smluvní procesy: zajišťují shodu mezi podniky a/nebo projekty, - podnikové procesy: zaměřují se na strukturu systému (super systémy – podsystémy), - projektové procesy: zaměřují se na životní cyklus předmětného systému, - technické procesy: poskytují zabezpečení pro fungování projektu a umožňují optimalizaci
výhod.
AAP-48 organizes processes into four groups: - Agreement Processes: ensure conformity between enterprises and/or projects - Enterprise Processes: focus on system structure (super systems - subsystems) - Project Processes: focus on the life cycle of the System of Interest - Technical Processes: provide support to project functions and enable benefit optimization
ČOS 051665 1. vydání
31
konfigurace, řízení verzí, strategie uvolňování, management chyb a defektů, výcvik a interakce s komunitou uživatelů se stanou hlavními činnostmi během etap využívání a zabezpečení.
control, release strategy, error and defect management, training and interaction with the user community will become major activities during the Utilization and Support stages.
5.1 Etapa koncepce
5.1 Concept Stage Koncepce je počáteční etapa v životním cyklu systému, která je započata s rozpoznáváním požadavku na novou schopnost, modifikaci existujícího systému nebo nahrazení systému. Má zahrnovat: studie proveditelnosti a analýzu možností, požadavky na vývoj a nástin plánů pro dodávání. Etapa koncepce bude končit rozhodovací bránou, kde bude brán v úvahu pokrok vůči etapě vývoje.
Concept is the initial stage in the system life cycle, which commences with the recognition of a requirement for a new capability, the modification of an existing system or the replacement of a system. It should include: feasibility studies and options analysis, the development of requirements and outline plans for delivery. The Concept stage will end with a Decision Gate where progression to the Development stage will be considered.
5.1.1 Plánování R&S softwaru
5.1.1 Planning for Software R&S
Během počátečního plánování, kdy jsou odvozovány softwarové požadavky z požadavků na systém, mají být brány v úvahu schopnosti R&S softwaru a mají být zabudovány do plánů projektu, testování, zabezpečování kvality a zabezpečení. Specifikace softwarových požadavků (SRS) má jasně stanovit funkcionalitu softwaru a musí být aktualizována, jak požadavky na software dozrávají v průběhu projektu. Během pozdější části etapy koncepce musí být vytvořen plán vývoje softwaru (SDP), který určuje schopnost R&S softwaru a vysvětluje, jak může být požadovaná specifikace realizována. Nechť je poznamenáno, že přibližně 50% všech softwarových chyb je způsobeno požadavky, které nejsou jasně stanoveny.
During initial planning, when the Software requirements are derived from system requirements, Software R&S capabilities should be considered and built into the project, test, Quality Assurance and Support plans. The Software Requirement Specification (SRS) should clearly state the Software functionality and must be updated as Software requirements mature throughout the project. During the latter part of the Concept stage, a Software Development Plan (SDP) must be created that addresses Software R&S capability and explains how the required specification can be realized. It should be noted that nearly 50% of all software failures are due to requirements not being clearly stated.
Úplný SDP bude tvořit základ pro etapu vývoje, využívání a zabezpečení v projektu. Má být integrován s celkovým plánem vývoje systému a má určit následující témata pro softwarové inženýrství, přizpůsobená specifickým
A comprehensive SDP will form the basis for the Development, Utilization and Support stages of the project. It should be integrated with the overall System Development Plan and address the following Software Engineering topics,
ČOS 051665 1. vydání
32
potřebám projektu16: tailored to the specific needs of a project:16
a. požadavky na dokumentaci, a) Documentation requirements;
b. metody vývoje softwaru17. Zásady pro opětovné použití softwaru (opětovné použití a modifikace zděděného softwaru).
b) Software development methods.17 Software reuse-policy (reuse and modification of legacy software);
c. metody, problémy a rizika integrace softwaru,
c) Software integration methods, issues and risks;
d. nakládání s kritickými požadavky, včetně: kritických na bezpečnost, vůči úkolu, zabezpečování informací a utajení,
d) Handling of Critical Requirements, including: safety-critical, mission-critical, information assurance and security;
e. nástroje a techniky používané při vývoji/údržbě softwaru18,
e) Tools and techniques used in the development/maintenance of software;18
f. řízení konfigurace: management změn, schvalování a sledování,
f) Configuration Control: change management, approval and tracking.
g. proces uvolňování verzí19, g) Version release process;19
h. použitelné standardy, h) Applicable standards;
i. požadavky na hardware při vývoji, využívání a zabezpečování,
i) Hardware requirements for Development, Utilization and Support;
j. strategie vytváření softwaru (včetně pokynů pro způsob kódování),
k. metodologie testování, včetně testování a dokumentace jednotky/ integrace/ systému,
k) Testing methodology, including: unit / integration / system test and documentation;
l. ověřování a validace softwaru a nezávislé ověřování a validace,
l) project verification & validation and Independent Verification & Validation;
m. proces podávání zpráv o datech, m) Data reporting process;
n. proces distribuce upgradovaného softwaru,
n) Software upgrade distribution process;
16
Viz ISO 12007 pro náčrt SDP a více podrobností o tomto tématu. See ISO 12207 for SDP outline and more detail on this topic.
17 Příklady zahrnují tradiční kaskádový model, Boehmův spirální Win-Win model, evoluční model a přírůstkový model. Examples include the traditional Waterfall model, Boehm's Spiral Win-Win model, Evolutionary and Incremental models.
18 Včetně nástrojů pro modelování a simulaci, vývojových a testovacích nástrojů, jazyků, kompilátorů, nástrojů softwarového inženýrství podporovaných počítačem a zobrazovacích konvencí. Including: modeling & simulation tools, development & testing tools, languages, compilers, Computer Aided Software Engineering tools and notation conventions.
19 Například: přírůstkové uvolnění, uvolnění všech jednotek najednou, selektivní uvolnění pro testování prototypu, pracovní oblasti k dispozici a dokumentace. For example: incremental release; release to all units at once, selective release for prototype testing, work-around and documentation.
ČOS 051665 1. vydání
33
o. audit a ověření instalovaného softwaru.
o) Audit and verification of installed software.
5.1.2 Zabezpečovatelnost softwarového jazyka
5.1.2 Software Language Supportability
Pro zákaznicky vytvářený software bude nezbytné zvolit vhodný programovací jazyk nebo jazyky. To může mít vážné následky, takže před volbou jazyka mají být brány v úvahu následující problémy:
For custom-built software, it will be necessary to select an appropriate programming language or languages. This can have profound consequences, so the following issues should be considered before a language is chosen:
a. hostitelská platforma musí podporovat jazyk20,
a. The host platform must support the language;20
b. kompilátor musí být podporován během celého životního cyklu,
b. The compiler must be supported during the whole life cycle;
c. jazyk musí být vhodný pro aplikace21, c. The language must be suitable for the application;21
d. oblíbenost jazyka22, d. The popularity of the language;22
e. otevřená specifikace jazyka23, e. Open language specification;23
f. efektivnost jazyka (rychlost provádění a požadavky na paměť),
f. Language efficiency (speed of execution and memory requirements);
g. flexibilita, kompatibilita a jednoduchost integrace24,
g. Flexibility, compatibility and ease of integration;24
h. bezporuchovost kompilátoru a zabezpečení dodavatelem25,
h. Compiler reliability and Supplier support;25
20 To je dobrá metoda dovolující kapacitu navíc v hostitelské platformě pro růst softwaru a provoz
programu. It is good practice to allow extra capacity within the host platform for Software growth and programme operation.
21 Software zbraňového systému nemá být vyvíjeno v obchodně orientovaném jazyce. Weapon system software should not be developed in a business-oriented language.
22 Je-li jazyk nejasný, programátoři pro zabezpečení ho budou těžko hledat a náklady na zabezpečení budou vysoké. If the language is obscure, support programmers will be difficult to find and support costs will be high.
23 Je-li specifikace jazyka ve společné oblasti, různí prodejci budou pravděpodobně vyvíjet zabezpečení, zatímco jazyk zatížený majetkovým právem bude závislý na rozmaru a přežití jednoho prodejce. If the language specification is in the public domain, several vendors are likely to develop support, whereas a proprietary language will be dependent on the whims and survival of a single vendor.
24 Jak snadné je modifikovat kód, zabudovat nezávislé moduly, budovat externí rozhraní a přidávat externí moduly psané v jiném jazyce? How easy it is to modify code, to build independent modules, to build external interfaces, to add-on external modules written in another language.
25 Záznam stopy, jak je asi dlouhý? Kolik existuje uživatelů?
ČOS 051665 1. vydání
34
i. jazyky/kompilátory jsou certifikovány vůči požadovaným bezpečnostním standardům.
i. Languages/compilers are certified to the required safety standards.
5.1.3 Management rizik
5.1.3 Risk Management
Software je vystaveno rizikům společným s hardwarem. Management rizik má být prováděn v průběhu životního cyklu softwaru. Má být vytvořen plán, aby se nastínily metody managementu rizik a posoudila se úroveň rizik (viz kapitolu 4).
Software is subject to risk in common with hardware. Risk management should be carried out throughout the Software life cycle. A plan should be developed to outline a method of risk management and assess the level of risk (see Chapter 4).
5.1.4 Komerčně nakupovaný software
5.1.4 COTS
Během etapy koncepce, kdy jsou uvažována alternativní řešení, může být zvoleno použití komerčního softwarového modulu nebo celé aplikace. Volba COTS řešení však ani nezajistí, ani nesejme ze zákazníka odpovědnost za zabezpečení kompatibility R&S.
During the Concept stage, when alternative solutions are being considered, the use of Commercial Off-The-Shelf (COTS) software modules or entire applications may be selected. However, choosing a COTS solution neither assures, nor removes responsibility from the Customer to ensure R&S compatibility.
Komerčně nakupovaný software může obsahovat nevývojové aplikace, dříve vyvinuté nebo adaptované programy a zahrnuje: operační systémy, kompilátory, nástroje pro zabezpečení softwaru, drivery související s hardwarem, komunikační moduly, aplikační knihovny nebo celé aplikace. Může být obtížné je řídit a náročné je modifikovat z legálních nebo technických důvodů (viz ČOS 051617 a ČOS 051649).
COTS software may include non-developmental applications, previously developed or adapted programs and encompass: operating systems, compilers, software support tools, hardware-related drivers, communication modules, application libraries or entire applications. It can be difficult to manage and is normally hard to modify for legal or technical reasons (see ARMP-1 and 6).
Výhody COTS produktů je jejich vyzrálost, dostupnost, široká uživatelská báze26, bezporuchovost27 a snížené náklady. Avšak existuje množství problémů, které mají být brány v úvahu, počítaje v to:
The advantages of COTS products are their maturity, availability, large user base26, reliability27 and reduced cost. However, there are numerous issues that should be considered, including:
Track record, how long has it been around? How many users are there?
26 Větší uživatelská základna poskytuje širší úroveň používaného testování pro identifikaci
inherentních vad. A larger user base provides a wider level of in use testing to identify inherent faults.
27 Z původní návrhové aplikace se může změnit na odlišnou aplikaci. In its original design application, this may change in a different application.
ČOS 051665 1. vydání
35
a. práva na data a licenční požadavky, a) Data rights and licensing requirements;
b. nedostatek řízení nebo schopnosti aktualizovat a udržovat produkt,
b) Lack of control or ability to update and maintain the product;
c. zastarávání, c) Obsolescence;
d. zabezpečení dodavatelem, d) Supplier support;
e. schopnost mít rozhraní s ostatními produkty,
e) Ability to interface with other products;
f. testování (může být omezeno na testování funkčnosti),
f) Testing (may be limited to functional testing);
g. provedení, monitorování a zlepšování,
g) Performance monitoring and improvement;
h. snižování rizik, h) Risk mitigation;
i. utajení, i) Security.
j. informace a výcvik, j) Information and training;
k. integrace, k) Integration;
l. hostitelská platforma a provozní prostředí,
l) Host platform and operational environment;
m. změny trhu. m) Market changes.
Jestliže je komerčně nakoupený software integrován do vojenského systému, má být poskytnuta záruka, že nebude podkopávat hostitelskou platformu. Má být proto podroben důslednému, pečlivému pohledu a testovacímu režimu, stejným způsobem jako u zákaznicky vytvořených produktů.
When COTS software is integrated into a military system, assurance should be provided that it will not undermine the host platform. It should therefore be subject to rigorous scrutiny and testing regime, in the same manner as custom-built products.
5.2 Etapa vývoje
5.2 Development Stage Vývoj je druhá etapa v životním cyklu systému, která začíná schválením poža-davků projektu a spouští návrh softwaru. Má zahrnovat: využití plánu tvorby soft-waru, vytváření základních úrovní, řízení konfigurací a testování verzí. V této etapě bude software vyvíjen tak, aby úplně splnil stanovené podmínky pro systém, včetně integrace s představitelem hardwaru a s vybavením operačního systému.
Development is the second stage in the system life cycle, which commences with the confirmation of the project requirements and the start of software design. It should include: the use of a Software build plan, baselining, configuration control and version testing. Throughout this stage the software will be developed to fully meet the stated system requirement including integration with representative hardware and equipment operating systems.
Etapa vývoje je pro R&S softwaru kritic-kou etapou, neboť vytváří základ pro dodání bezporuchového a zabezpečovatelného softwaru. Etapa vývoje může zahrnovat kódování
The Development stage is a critical stage for Software R&S, since it creates a foundation for the delivery of reliable and supportable Software. The Development stage may encompass the
ČOS 051665 1. vydání
36
zákaznického softwaru, modifikace existujícího softwaru nebo integraci COTS softwaru do systému.
coding of custom software, the modification of existing software or integration of COTS software into a system.
Etapa vývoje má být ukončena, jestliže je software předveden v reprezentativním hardwarovém prostředí a ověřen vůči stanoveným softwarovým požadavkům. Hlavní úvahou v tomto případě má být úplná bezporuchovost systému a etapa produkce má být zahájena pouze tehdy, když je stanovena a ověřena úplná způsobilost systému.
The Development stage should end when the software is demonstrated in a representative hardware environment and verified against the stated software requirement. Whole system reliability should be the main consideration and the production stage should only be commenced when whole system capability is determined and verified.
5.2.1 Principy použití R&S softwaru (proces analýzy požadavků, proces návrhu architektury, proces zavedení)
Kapitola 4 tohoto standardu poskytuje pokyny k požadavkům na R&S, k vytvo-ření a používání plánu R&S a k případu R&S. To musí být provedeno před defi-nicí požadavků na vývoj nebo akvizicí softwaru. Zatímco použitelnost specific-kých R&S postupů bude funkcí bezporu-chovosti významného softwaru, požadavky na R&S musí být sledova-telné v průběhu činností etapy vývoje. Dokument s návrhem softwaru, který definuje architekturu produktu, má zahr-novat požadavky na R&S, jako je modu-larita, malá složitost, podporovatelný jazyk, snadnost validace a nízká úroveň závislosti na externích modulech.
Chapter 4 of this document provides guidance on R&S requirements, the development and use of R&S Plan and R&S Case. These must be carried forward from the requirement definition to the development or acquisition of the software. While the applicability of specific R&S practices will be a function of reliability-significance of the software, the R&S requirements must be traceable throughout Development Stage activities. The Software Design Document, which defines the architecture of the product, should incorporate R&S requirements, such as modularity, low complexity, supportable language, ease of validation, and a low level of dependency on external modules.
5.2.2 Modularita
5.2.2 Modularity
Většina softwarových programů má být vyvíjena modulárním způsobem, který může napomáhat programování a zvy-šovat bezporuchovost, zabezpečovatel-nost a testovatelnost. Má být věnována pozornost zajištění, že moduly jsou přiměřeně nezávislé na funkcionalitě a že rozhraní jsou jednoduchá a dobře definovaná (viz kapitolu 2).
Large software programs should be developed in a modular fashion which can assist programming and enhance reliability, supportability and testability. Care should be taken to ensure that modules are reasonably independent in functionality and that interfaces are simple and well defined. (See Chapter 2).
ČOS 051665 1. vydání
37
5.2.3 Vytváření prototypů
5.2.3 Prototyping
Pro velké a složité softwarové programy je vysoce žádoucí zahájit vývojový proces budováním zjednodušené fungující makety nebo modelu. To pomůže objasnit specifikace uživatele a zlepšit dodavatelovo porozumění požadavkům. Proces vytváření neúplné nebo snížené verze softwaru s využitím jazyka pro modelování28 pro simulaci funkcí programu je znám jako vytváření prototypů. Tento proces pomůže definovat, zjednodušit a testovat rozhraní a algoritmy před zavedením do složitého kódovacího prostředí. Prototyp softwarové aplikace před úplným vý-vojem může významně snížit velikost konečného programu a dobu vývoje, při zlepšení R&S.
For large and complex Software programs, it is highly desirable to start the development process by constructing a simplified functioning mock up or model. This will help to clarify the User's specifications and improve the Supplier's understanding of the requirements. The process of building a partial or scaled-down version of the software, using a modelling language28 to simulate the functions of a program is known as Prototyping. This process will help define, simplify and test interfaces and algorithms before implementation in a complex coding environment. Prototyping Software applications before full-scale development can significantly reduce final program size and development time, while improving both R&S.
5.2.4 Modelování a simulace
5.2.4 Modeling and Simulation
Jakmile je proces vytváření prototypu završen a práce na softwarovém programu začaly, je žádoucí upotřebit techniky modelování a simulace na pomoc vývoji. Tento proces využívá systémy softwaru a hardwaru ve spojení s komunikací a lidskými zdroji k napodobení operačního systému. Simulace je proces, pomocí něhož je vytvářena softwarová aplikace, aby prováděla sérii funkcí v rámci modelu operačního systému pro ověření požadované funkcionality. Použití simulace umožní: stlačení nebo rozšíření doby, mód provozu „stop a běž“, experi-mentování s různými stavy systému a umožnění, aby byly měřeny výsledky bez potřeby vytvářet rozhraní a okolní infrastrukturu. Ke zlepšení R&S může být
Once the Prototyping process has been completed and work on the Software program has begun, it is desirable to employ Modeling and Simulation techniques to aid development. This process utilizes Software and Hardware systems in conjunction with communication and human resources to emulate the operational system. Simulation is a process whereby a Software application is made to perform a series of functions within a model of the operational system, to verify required functionality. The use of Simulation allows: time compression or expansion; a stop-and-go mode of operation; experimentation with various system states and enables results to be measured, without the need to build
28 Jako je Univerzální modelovací jazyk (UML), který je všestranným nástrojem, umožňujícím vizualizaci softwarových architektur a struktury. Such as Universal Modeling Language (UML) which is a versatile tool, enabling the visualization of software architectures and structure.
ČOS 051665 1. vydání
38
využita efektivní simulace softwarových aplikací během vývoje.
interfaces and surrounding infrastructure. Effective Simulation of Software applications during development can be used to improve both R&S.
5.2.5 Propojování
5.2.5 Interfacing
Pro složité systémy je velmi důležité zajistit kompatibilitu mezi softwarovými moduly, aplikacemi a hostitelskou platformou. Existují také rozhraní mezi softwarem a hardwarem a mezi hardwarem, operátory a prostředím. Rozhraní jsou komunikačními kanály mezi samostatnými podsystémy, které mohou být jednosměrné nebo dvousměrné. Komunikace napříč hranicemi rozhraní musí sledovat protokoly, které jsou srozumitelné na všech stranách.
For complex systems it is very important to ensure compatibility between Software modules, applications and the host platform. Interfaces also exist between Software and Hardware, and between Hardware, operators and the environment. Interfaces are communication channels between self-contained sub-systems, which may be unidirectional or bi-directional. Communication across interface boundaries must follow protocols, which are understood, on all sides.
Během vývoje mají být zmapována všechna rozhraní, aby se vytvořily podsystémové, aplikační a modulární závislosti29. Pro každé rozhraní má být definován plný popis, seznam všech programátorů, kteří potřebují znát jeho funkci v systému30.
During Development, all interfaces should be mapped to establish sub-system, application and modular dependencies.29 A full description should be defined for each Interface, listing everything a programmer needs to know about its function within the system.30
5.2.6 Testování
5.2.6 Testing
Testování je důležitou složkou vývoje softwaru a klíčovým přispěvatelem k bezporuchovosti softwaru. Běžnou a důležitou špatnou představou je to, že k testování dochází až na konci vývojového cyklu. Testování musí být integrální součástí každého kroku cyklu vývoje softwaru, zabezpečeného plánem testování, s flexibilitou pro přizpůsobení neočekávaným událostem. Testovací režim může zahrnovat rozsah přístupů od testování funkčnosti až k podrobnějšímu zkoumání softwaru řádka po řádce.
Testing is an important component of Software development and a key contributor towards software Reliability. A common and serious misconception is that testing takes place at the end of the development cycle. Testing must be an integral part of every step within the software development cycle, supported by a test plan, with the flexibility to accommodate unexpected events. The test regime may include a range of approaches from functional testing to more detailed line by line examination of the software.
29 To by mohlo být zabezpečeno komerčním mapovacím nástrojem, jako je UML. This could be supported by commercial mapping tools such as UML.
30 Standard IEEE 1016 poskytuje podrobnosti popisu softwarového návrhu, včetně křižování. IEEE Standard 1016 provides details on software design descriptions, including interlaces.
ČOS 051665 1. vydání
39
Režim testování softwaru má být rozdělen do množství postupných kroků, které mají zahrnovat:
The Software test regime should be divided into a number of progressive steps, which may include:
a. testování jednotky: testování softwarových modulů,
a) Unit testing: the testing of software modules;
b. integrační testování: testování dvou nebo vice kombinovaných modulů,
b) Integration testing: the testing of two or more combined modules;
c. testování systému: testování všech softwarových modulů v systému,
c) System testing: the testing of all of software modules within a system;
d. regresní testování: opětovné testování po provedení modifikace nebo změnách,
d) Regression testing: re-testing after modification or changes;
e. testování zatížení: testování softwaru mimo jeho zamýšlený rozsah,
e) Stress testing: testing software outside its intended envelope.
f. integrační testování softwaru vůči hardwaru: testování softwaru ve spojení s představitelem hardwaru,
f) Software to Hardware Integration testing: the testing of software in conjunction with representative hardware;
g. přejímací testování: oficiální testování systému oproti smluvním požadavkům,
g) Acceptance testing: formal testing of a system against contractual requirements;
h. provozní testování: testování koncových funkcí oproti provozním scénářům.
h) Operational testing: testing end-to-end functions against operational scenarios.
Veškeré testování softwaru musí být zabezpečeno dokumentací:
All Software testing must be supported by documentation:
Plán testování. Po dodavateli má být vyžadován hlavní plán testování, který bude popisovat testovací režim softwaru. To má zahrnout sérii plánů testů pro určení různých etap vývojového cyklu softwaru. Prvky každého plánu testování mají zahrnout kritéria schválení nebo neschválení, rizika a důsledky poruchy31 (viz ČOS 051649, příloha K).
Test Plan. The Supplier should be required to produce a Master Test Plan which will describe the test regime for the Software. This should include a series of Test Plans to address the various stages of the Software development cycle. The elements of each test plan should include pass or fail criteria, risks and implications of failure31 (see ARMP-6 Annex K).
Postupy testování. Postupy testování popisují činnosti, které se mají provést, aby se otestoval modul softwaru nebo aplikace, podmínky, za kterých má být
Test Procedures. Test Procedures describe the activities which should be undertaken to test a Software module or application, the conditions under which
31 Pro pokyny k vytváření plánů testování a dalších testovacích dokumentů se podívej do standardu IEEE 829, Dokumentace pro softwarové testování. For guidance on creating Test Plans and other test documentation see IEEE Standard 829, Software Test Documentation.
ČOS 051665 1. vydání
40
test proveden a očekávané výsledky. Každý postup testování má mít dokumentován požadavek v SRS. Každý požadavek má být sledovatelný vůči příslušnému postupu testování za použití ověřovací matice. Postup testování má zahrnout následující informace:
the tests should be conducted and the expected results. Each Test Procedure should have a requirement documented in the SRS. Each requirement should be traceable to the respective Test Procedure using a verification matrix. Test procedures should include the following information:
a. cíle testování: definují zamýšlené záměry etapy testování,
a) Test Objectives: defines the intended goal of the testing stage;
b. kriteria dokončení: podmínky, které určují úspěch,
b) Completion criteria: the condition that determines success;
c. odpovědnosti: popisují role dodavatele a zákazníka,
c) Responsibilities: describes Supplier and Customer roles;
d. použitelné standardy a dokumenty, d) Applicable Standards and Documents;
e. nástroje: včetně softwarových a hardwa rových produktů, kontrolních seznamů a instrukcí,
e) Tools: including Software or Hardware products, checklists and instructions;
f. zdroje: systémy, zařízení a lidské zdroje atd.,
f) Resources: systems, facilities and human resources, etc.;
g. postupy pro podávání zpráv: zápisy a sledování chyb (viz FRACAS v ČOS 051649, příloha F),
g) Reporting procedures: error logging and tracking (see FRACAS in ARMP-6 Annex F);
h. regresní testování. h) Regression testing.
Výsledky testování. Všechny výsledky testů musí být zaznamenány, srovnány s kriterii dokončení a prezentovány zákazníkovi v odsouhlaseném formátu.
Test Results. All test results must be recorded, compared with the completion criteria and presented to the Customer in an agreed format.
5.2.7 Automatizované nástroje
5.2.7 Automated Tools
Vývoj softwaru může být zabezpečen různými automatizovanými nebo počíta-čovými nástroji. Ty mohou být v rozsahu od nástrojů definujících požadavky a nástrojů sledujících požadavky k nástrojům návrhu softwaru, nástrojům počítačově podporovaného softwarového inženýrství32 a automatických nástrojů testování. Vhodné použití zvolených nástrojů během vývoje by mohlo zvýšit
Software development can be supported by a variety of automated or computer-assisted tools. These range from requirement-definition and requirement-tracing tools to Software design tools, Computer Aided Software Engineering (CASE) tools32 and test automation tools. The appropriate use of selected tools during Development could enhance Software R&S; however any tools used
32
CASE je užitečné, počítačově založené zabezpečení v procesu vývoje softwaru (Institut pro softwarové inženýrství). CASE is the use of computer-based support in the software development process (Software Engineering Institute).
ČOS 051665 1. vydání
41
R&S softwaru, avšak jakékoliv použité nástroje mají být schváleny příslušným orgánem.
should be approved by the appropriate authority.
5.2.8 Metriky vztažené k vývoji softwaru
5.2.8 Software Development-Related Metrics
Pro monitorování procesu během vývojové etapy je nezbytné definovat množství metrik souvisejících s řízením a produkcí a sbírat podpůrné datové prvky (viz kapitolu 3). U větších projektů by se mohly využít nástroje pro měření provedení. Některé běžné metriky zahrnují:
To monitor progress during the Development Stage it will be necessary to define a number of management and product related metrics and collect the supporting data elements (see Chapter 3). For large projects, performance measurement tools could be employed. Some common metrics include:
a. zdrojové řádky kódu (SLOC), a) Source Lines of Code (SLOC);
b. vady na tisíc řádků kódu (kSLOC nebo KSLOC),
b) Faults per Thousand Source Lines of Code (kSLOC or KSLOC);
c. počet modulů, c) Number of modules;
d. velikost programu (kB), d) Program Size (Kbytes);
e. roční frekvence změn (ACT), e) Annual Change Traffic (ACT);
f. čísla složitosti kódu. f) Code complexity numbers.
5.3 Etapa produkce
5.3 Production Stage Produkce je třetí etapa v životním cyklu systému a je zahájena s ustanovením základní úrovně pro první verzi softwarové aplikace, je-li dokončen vývoj. Má zahrnovat pokračující testování a konečnou integraci softwaru s provozním hardwarem. Etapa produkce končí instalací softwaru33 na všechny platformy a distribucí podpůrné dokumentace.
Production is the third stage in the system life cycle and commences with base-lining of the first version of a software application when Development is complete. It should include ongoing testing and final integration of the software with the operational hardware. The Production stage will end with installation of the software33 on all platforms and the distribution of supporting documentation.
Některé činnosti etapy vývoje mohou pokračovat v etapě produkce, i za ní. Jsou to: testování, management rizik, monitorování provedení a management konfigurace. U fázovaného rozvíjení softwaru není neobvyklé provádět postupné zvyšování funkcionality34.
Several of the Development Stage activi-ties may continue into the Production Stage and beyond, such as testing, risk management, performance monitoring and configuration management. It is not uncommon for a phased rollout of Soft-ware to be undertaken, with progressive increase in functionality34.
33
Včetně komerčně nakupovaného softwaru. Including COTS software. 34
Příklady zahrnují Boehmův spirální Win-Win model, evoluční model a přírůstkový model. Examples include Boehm's Spiral Win-Win model, Evolutionary and Incremental models.
ČOS 051665 1. vydání
42
5.4 Etapa využívání
5.4 Utilization Stage Využívání je čtvrtou etapou životního cyklu softwaru a je zahrnována do provozní etapy, odpovědné za nepřetržité fungování systému. Etapa zabezpečení běží paralelně s etapou využívání. Etapa využívání bude pokračovat po celý provozní život systému. Činnosti R&S softwaru se během této etapy zaměří na udržující používání a měření provedení.
Utilization is the fourth stage in the system life cycle and is the mainstream operational stage concerned with the continued functioning of the system. The Support Stage runs in parallel with the Utilization Stage. The Utilization stage will continue throughout the systems operational life. Software R&S activities during this stage focus on sustaining applications and performance measurement.
5.5 Etapa zabezpečení
5.5 Support Stage Software, podobně jako hardware, vyžaduje v průběhu životního cyklu zabezpečení, klíčovým prvkem kterého je management změn. Software může mít potřebu upgradu jako výsledku opravy vady, změn provozních postupů, prostředí, hardwaru nebo rozhraní. Aby se umožnily modifikace softwaru nebo upgrade bez potřeby modifikace hardwaru, v původním požadavku na hardware má být zahrnuto přiměřené následné zpracování a kapacita paměti.
Software, like Hardware, requires support throughout the life cycle, a key element of which is change management. Software may need to be upgraded as a result of fault correction, changes to operating procedures, environments, Hardware or interfaces. To allow Software modification or upgrade without the need for Hardware modification, sufficient additional processing and memory capacity should be included within the original Hardware requirement.
5.5.1 Metriky a sběr dat
5.5.1 Metrics & Data Collection
V průběhu etapy zabezpečení zůstává velmi důležitý sběr dat a jejich analýza, aby se izolovaly vady a zlepšila bezporuchovost. Metriky vyžadované pro podporu této etapy mohou zahrnovat:
Data collection and analysis remains very important throughout the Support Stage to isolate faults and improve reliability. The metrics required to support this stage may include:
a. POFOD – pravděpodobnost poruchy na povel,
a) POFOD - Probability of failure on Demand;
b. ROCOF – intenzita výskytu poruch, b) ROCOF - Rate of Occurrence of Failure;
c. MTTF – střední doba do poruchy. c) MTTF - Mean Time to Failure.
Hodnotným nástrojem pro řízení tohoto procesu je systém záznamů o poruchách a nápravná opatření (FRACAS), který může být použit k analýze dat o poruše, k vytvoření a zabezpečení trvalých záplat pro softwarové vady (viz ČOS 051649, přílohu F).
A valuable tool for managing this process is a Failure Reporting and Corrective Action System (FRACAS), which can be used to analyze failure data, develop and support fixes for Software faults (see ARMP-6 Annex F).
ČOS 051665 1. vydání
43
5.5.2 Management údržby softwaru
5.5.2 Software Maintenance Management
Během etapy zabezpečení má být určena R&S softwaru pomocí plánu managementu softwaru (SMP), který by měl tvořit část SDP. SMP má zahrnovat následující témata:
During the Support Stage, Software R&S should be addressed by a Software Management Plan (SMP) which could form part of the SDP. The SMP should include the following topics:
a. management vad, a) Fault Management;
b. monitorování provedení softwaru, b) Software Performance Monitoring;
c. management rizik, c) Risk Management;
d. management zastarávání, d) Obsolescence Management;
e. management konfigurace, e) Configuration Management;
f. zabezpečování kvality, f) Quality Assurance;
g. management dokumentace, g) Documentation Management;
h. výcvik, h) Training;
i. podporu programátorů. i) Programmer support.
5.5.3 Management konfigurace
5.5.3 Configuration Management
Management konfigurace (CM) je disciplína pro řízení vývoje hardwaru, softwaru, služeb a dokumentace. CM je kritickým aspektem podpory softwaru, neboť je důležité, aby všechny systémy běžely s obvyklou softwarovou verzí. Významná rizika u softwaru přicházejí z nekontrolovaného přístupu ke zdrojovému kódu, neboť software může být změněn bez sledování. Proto má být v platnosti přísná CM kázeň, aby se zabránilo neautorizovaným a nedokumentovaným změnám35. CM používá technické a administrativní řízení na následující činnosti:
Configuration Management (CM) is a discipline for controlling the evolution of hardware, software, services and documentation. CM is a critical aspect of Software Support since it is important that all systems run with a common Software version. A significant risk to Software comes from uncontrolled access to source code, since Software can be changed without trace. A strict CM discipline should therefore be in force, to prevent unauthorized and undocumented changes.35 CM applies technical and administrative direction to the following activities:
a. identifikaci softwarové konfigurace, a) Software configuration identification;
b. konfigurace softwaru, monitorování a řízení,
b) Software configuration, monitoring and control;
c. auditování konfigurace softwaru (jak funkční, tak fyzické).
c) Software configuration auditing (both functional and physical).
35 ACMP-7 (ČOS 051610) – Management konfigurace uplatňovaný v NATO – pokyny pro použití ACMP-l až ACMP-6. ACMP-7 NATO Configuration Management – Guidance on the Application of ACMPs 1 – 6.
ČOS 051665 1. vydání
44
5.5.4 Management rizik
5.5.4 Risk Management
Management rizik je integrální součást podpory softwaru, neboť jakákoliv změna v aplikaci by mohla mít nežádoucí vedlejší účinky. Proto každý požadavek na softwarovou změnu má být přezkoušen a mají být posouzena související rizika36. Posouzení rizik má být kvantitativní. Rizikové faktory související s R&S softwaru zahrnují:
Risk Management is an integral part of Software Support since any change to an application could have undesirable side-effects. Therefore every Software change request should be examined and the associated risks assessed.36 The risk assessment should be quantitative. Risk factors associated with Software R&S include:
a. faktory provedení: jako je použití dalších výpočetních zdrojů (paměť, CPU, úložná kapacita, šířka pásma sítě),
a) Performance factors: such as the use of additional computing resources (memory, CPU, storage capacity, network bandwidth);
b. složitost: počet softwarových modulů ovlivněných změnou; kvantitativní posouzení složitosti ve srovnání s dalšími změnami,
b) Complexity: the number of software modules affected by the change; qualitative assessment of complexity compared to other changes;
c. velikost modifikace: počet SLOC a počet ovlivněných modulů,
c) Size of modification. The number of SLOC and the number of modules affected;
d. kritičnost: možný vliv na základní úkol a bezpečnost,
d) Criticality. The potential effect on the primary mission and safety;
e. faktory rozhraní: modifikace související se změnami hardwaru nebo sítě,
e) Interface factors. The modification related to hardware or network changes;
f. testovatelnost: jak obtížné je testovat proces,
f) Testability. How difficult is the testing process;
g. lidské faktory, g) Human factors;
h. dokumentace: nedostatečná nebo nevhodná dokumentace.
h) Documentation. insufficient or inadequate documentation.
5.5.5 Proces testování
5.5.5 Testing Process
Testování softwaru pokračuje jako důležité hledisko zabezpečení softwaru. Nejdůležitější úlohou bude ověření trvalých záplat v aplikacích. Mnoho nástrojů a dokumentů vytvořených v etapě vývoje má být udržováno během etap využívání a zabezpečení, včetně:
Software testing continues to be an important aspect of Software Support. The principal role will be that of verifying fixes to the application. Many of the tools and documents produced during Development should be maintained during the Utilization and Support Stages, including:
36 Viz Pokyny pro neustálý management rizik z Institutu softwarového inženýrství. See the Software Engineering Institute's Continuous Risk Management Guide.
ČOS 051665 1. vydání
45
a. plánů pro testování, a) Test plans;
b. popisů testování, b) Test descriptions;
c. testovacích postupů, c) Test procedures;
d. výsledků testů a zpráv z testování, d) Test results and reports;
e. testovacích nástrojů a programů. e) Testing tools and programs.
Testování se má také využít u komerčně nakupovaného softwaru na úrovni systému nebo modulů.
Testing should also be applied to COTS software at system or module level.
5.5.6 Nezávislé ověřování a validace
5.5.6 Independent Verification and Validation
Pro všechny etapy vývoje softwaru má být uvažováno nezávislé ověřování a validace, aby se snížila rizika, včetně jakékoliv významné modifikace nebo upgradu.
Independent Verification and Validation should be considered for all stages of Software development in order to mitigate risk, including any significant modification or upgrades.
5.5.7 Udržování softwarové integrity
5.5.7 Maintaining Software Integrity
Management R&S softwaru během etap využívání a zabezpečení má dát úvahy k množství dalších faktorů, včetně:
The management of Software R&S during the Utilization and Support Stages should give consideration to a number of other factors, including:
a. zastarávání softwaru, a) Software Obsolescence;
b. integrita softwaru mezi verzemi, b) Software Integrity between versions;
c. bezpečnost, c) Safety;
d. udržování sledovatelnosti vůči původním požadavkům,
d) Maintaining traceability to original requirements;
e. udržování nástrojů pro vývoj softwaru a zabezpečení.
e) Maintaining software development and support tools.
5.6 Etapa vyřazení
5.6 Retirement Stage Činnosti R&S softwaru během etapy vyřazení jsou omezeny na:
Software R&S activities during the Retirement Stage are limited to:
a. řízenou likvidaci klasifikovaných dat, a) Controlled disposal of classified data;
b. řízené archivování programových dat a dokumentace,
b) Controlled archiving of programme data and documentation;
c. zadokumentování získaných zkušeností v průběhu životního cyklu ve prospěch následníka systémů.
c) Documentation of Lessons Learned throughout the life cycle, for the benefit of successor systems.
KAPITOLA 6 UZAVÍRÁNÍ SMLUV NA R&S SOFTWARU
CHAPTER 6 CONTRACTING FOR SOFTWARE R&S
6. Úspěch nebo cokoli jiného v jakémkoliv projektu se opírá o kvalitní
6. The success or otherwise of any project rests to a large extent on the
ČOS 051665 1. vydání
46
přípravu smluv na pořízení a zabezpečení. Jsou-li smlouvy v dobrém stavu, dobře napsané a úplné, existuje vysoká pravděpodobnost, že výsledný produkt bude splňovat jejich požadavky a bude dodávat zamýšlenou schopnost během etapy využívání v životním cyklu vybavení, za optimálních nákladů.
quality of its procurement and support contracts. If these are taut, well written and comprehensive, there is a high probability that the resulting product will meet its requirements and deliver the intended capability throughout the Utilization stage of the equipment life cycle, at optimum cost.
6.1 Software jako jedinečný prvek
6.1. Software as a Unique Element Software systému je příliš důležitým prvkem jakéhokoliv projektu, než aby byl opomenut v procesu uzavírání smlouvy. Se zřetelem na jeho jedinečné charakteristiky, musí být software určen v jakékoliv smlouvě na pořízení nebo za-bezpečení jako samostatný prvek. V kapitole smlouvy nazvané „Software“ má být určena bezporuchovost a za-bezpečovatelnost pomocí specifických požadavků a klauzulí. Jestliže má porucha plnohodnotně pokrýt toto oblast, projekt by mohl být vystaven významným rizikům, mohl by podkopat jeho schopnost a mohl by vyhnat do výše náklady na zabezpečení.
System Software is far too important an element of any project to be omitted from the contracting process. In view of its unique characteristics, Software must be addressed as a separate element within any procurement or support contract. Within the Software section of the contract, Reliability & Supportability should be addressed by specific requirements and clauses. Failure to cover this area adequately, could expose projects to significant risk, undermine capability and inflate support costs.
6.2 Software jako integrální součást systému
6.2. Software as an Integral System Component
Nehledě na jeho speciální statut má být software uvažován jako integrální součást systému a také má být určen v rámci celkových požadavků na schopnost. Rovněž má být uvažována R&S v rámci celkových požadavků na R&M. Dodání všech těchto spojených požadavků má být aktivně řízeno a postup má být přezkoumán během milníků projektu.
Notwithstanding its special status, Software should be considered as an integral part of a system and also addressed within the overall capability requirements. Likewise, Software R&S should be considered within the overall R&M requirements. The delivery of all of these interlinked requirements should be actively managed and progress reviewed at project milestones.
Požadavky na R&S projektu se mají stanovovat během etapy koncepce spolu s vhodnými metrikami a mechanismem, pomocí nichž mohou být shromažďována data o zabezpečení a analyzována, aby se změřil postup (viz odstavec 3.5). Všechny požadavky mají být pokryty zvláštními klauzulemi v rámci smluv na pořízení nebo zabezpečení a jejich podpůrnými specifikacemi činností.
Software R&S requirements should be determined during the Concept stage along with appropriate metrics and a mechanism through which supporting data can be gathered and analysed to measure progress (see Paragraph 3.5). All requirements should be covered under specific clauses within procurement or support contracts and their underpinning statements of work.
ČOS 051665 1. vydání
47
6.3 Definice pojmů
6.3. Definition of Terms Mezi zákazníkem a dodavatelem musí být odsouhlasena definice jakýchkoliv klíčových slov souvisejících s R&S softwaru, jejich měřením a dodáním a uchovávána ve smlouvě spolu s jakýmikoliv podpůrnými vysvětleními (viz přílohu A). Speciální úvahy mají být dány na rozlišení mezi chybami, vadami a poruchami a metodami evidence pro duplikování incidentů a s nimi souvisejícími trvalými záplatami (viz kapitolu 3).
The definition of any key words associated with Software R&S, its measurement and delivery must be agreed between the Customer and Supplier, and enshrined in the contract, along with any supporting explanations (see Annex A). Special consideration should be given to the distinction between Errors, Faults and Failures, and the methods of accounting for duplicate incidents and their associated fixes (see Chapter 3).
6.4 Progresivní zajištění
6.4. Progressive Assurance Společně s R&M má smlouva požadovat po dodavateli, aby poskytoval progresivní zajištění, že požadavky na R&S softwaru jsou plněny během etap vývoje, produkce a využívání životního cyklu vybavení. Po dodavateli má být požadováno, aby poskytl důkaz postupu vůči milníkům projektu (viz ČOS 051617), který může být posouzen zákazníkem. Mají se také učinit opatření pro společný výbor pro vynášení výroků o událostech (ISC) (viz ČOS 051649), který odsouhlasí kompetence, bude monitorovat postup a řídit významné problémy (tam, kde je to vhodné, by mohly být kombinovány s mítinky k R&M).
In common with R&M, the contract should require the Supplier to provide Progressive Assurance that Software R&S requirements are being met during the Development, Production and Utilization stages of the equipment life cycle. The Supplier should be required to provide evidence of progress against project milestones (see ARMP-1), which can be assessed by the Customer. Provision should also be made for joint R&S Incident Sentencing Committees (ISC) (see ARMP-6) to agree attribution, monitor progress and manage significant problems (these could be combined with R&M meetings where appropriate).
Smlouva má specifikovat jakýkoliv požadavek na oficiální vyzkoušení nebo prokazování R&S během vývoje, produkce nebo využívání. To má zahrnovat jakékoliv speciální podmínky nebo spoluodpovědnost zákazníka. Tam, kde se provádí společné vyzkoušení nebo prokazování, musí být jasně definovány odpovědnosti všech stran a specifikovány hraniční podmínky. Také mají být učiněna opatření pro společný panel k analýze a posouzení výsledných dat a odsouhlasení výsledků (to by mělo být provedeno ISC).
The contract should specify any requirement for formal R&S trials or demonstrations during Development, Production or Utilization. This should include any special conditions or Customer involvement. Where trials or demonstrations are undertaken jointly, the roles and responsibilities of all parties must be clearly defined and boundary conditions specified. Provision should also be made for a joint panel to analyse and assess the resulting data and agree the results (this could be carried out by the ISC).
ČOS 051665 1. vydání
48
6.5 Řízení změnových požadavků
6.5. Managing Changing Requirements
Během procesu projednávání smlouvy musí být věnována velká péče tomu, aby se zabránilo podkopání dodávek R&S softwaru. Jakékoliv navrhované změny vůči požadavkům, definicím, metrikám, měřicím procesům, progresivnímu zajištění, vyzkoušení, prokazování, milníkům nebo stimulům pro R&S mají být diskutovány se softwarovými specialisty předtím, než jsou odsouhlaseny dodavatelem.
During the contract negotiation process, great care must be taken to avoid undermining the delivery of Software R&S. Any proposed changes to the R&S requirements, definitions, metrics, measurement process, progressive assurance, trials, demonstrations, milestones or incentives, should be discussed with a Software specialist before they are agreed with the Supplier.
Pro zajištění závazku dodavatele ve vztahu k důležitosti softwaru, dodání R&S softwaru má být spojeno s významnými finančními stimuly, zabezpečeno objektivním měřením vůči odsouhlaseným cílům. Platby nebo pokuty mají být svázány s milníky projektu a úspěch nebo cokoli jiného má být stanoven pomocí progresivního zajištění (viz ČOS 051617).
To ensure Supplier commitment to the importance of Software, the delivery of Software R&S should be linked to significant financial incentives, supported by objective measurement against agreed targets. Payments or penalties should be tied at project milestones and success or otherwise determined through Progressive Assurance (see ARMP-1).
6.6 Přijetí softwaru
6.6. Software Acceptance Na konci procesu pořizování nemají být přijaty nové systémy pro využívání, dokud není dosaženo požadavků na R&S softwaru. Jsou-li z jakéhokoliv důvodu přijaty nedovyvinuté systémy, musí být všechny nedostatky oficiálně zaznamenány a musí být poskytnuty odpovídající zdroje pro dodání opraveného programu podle smlouvy.
At the end of the procurement process, new systems should not be accepted for Utilization unless the Software R&S requirements have been met. If immature systems are accepted for any reason, all shortcomings must be formally recorded and adequate resources provided to deliver a get well programme, under contract.
Pečlivě má být uváženo uspořádání pro udržování R&S softwaru od etapy koncepce, připraveno pro zavedení při přijetí softwaru v průběhu využívání a na počátku etapy vyřazení. Proces progresivního zajištění a management vad a poruch má být přezkoumáván a ke smlouvám na pořízení mají být provedeny dodatky tak, aby smlouva odrážela všechna zjemnění, která mohou být vyžadována časně v etapě využívání. Aby se vyhlo zmatkům, je důležité neuskutečňovat žádnou změnu definic nebo v procesu evidence, ustavených během pořízení. Mohou existovat změny
Careful consideration should be given to the arrangements for sustaining Software R&S from the Concept Stage, ready for implementation at Software acceptance, throughout the Utilization and early Retirement stages. The Progressive Assurance process and the management of faults and failures should be reviewed and the procurement contract amended to reflect any refinements which may be required early in the Utilization stage. To avoid confusion, it is important that no changes are made to any of the definitions or accounting processes established during procurement. Should
ČOS 051665 1. vydání
49
v úrovni zabezpečovací činnosti mezi vývojem a využíváním, smlouva má umožnit jakékoliv sdílení úspory mezi dodavatelem a zákazníkem.
there be a change in the level of support activity between Development and Utilization, the contract should enable any savings to be shared between the Supplier and Customer.
6.7 Využívání zabezpečení
6.7 Utilization Support Jestliže se smlouva na pořízení chýlí ke konci, je obyčejně nezbytné přijmout smlouvu na zabezpečení softwaru systému. Práce na tom mají začít mnohem dřív, než vyprší smlouva na pořízení (navrhuje se doba od 12 do 24 měsíců). Aby se zajistila spojitost a kontinuita, má smlouva na zabezpečení obsahovat speciální ustanovení pro R&S a má se přidržovat vzoru stanoveného pro pořízení, za použití stejných definic a metrik. Má být učiněno zvláštní ustanovení pro vývoj a dodání softwarových upgradů, aby se zajistilo, že nepodkopou původní schopnost R&S. Také má být vytvořeno ustanovení o shromáždění důkazu o jakýchkoliv vadách a poruchách softwaru, detekovaných během využívání a v rámci oficiálního rámce mají být řízena nápravná opatření. Má pokračovat využívání milníků projektu s finančními stimuly.
When a procurement contract comes to an end, it will normally be necessary to let a System Software support contract. Work on this should start well before the procurement contract is due to expire (12 to 24 months is suggested). To ensure coherence and continuity the support contract should include special provision for R&S and follow the template established for procurement, using the same definitions and metrics. Specific provision should be made for the development and delivery of software upgrades, to ensure they do not undermine the original R&S capability. Provision should also be made to gather evidence of any software faults or failures detected during Utilization and manage corrective action within a formal framework. The use of project milestones with financial incentives should continue.
6.8 Smlouvy na pořízení
6.8 Procurement Contracts Je-li zajišťována R&S, mají být souhrnně určeny následující položky ve smlouvě na pořízení softwaru systému:
In summary, the following items should be addressed in a System Software procurement contract, if R&S are to be assured:
a. musí být specifikovány požadavky na R&S,
a) R&S requirements must be specified;
b. definice klíčových slov, b) Key words defined;
c. definice metrik a mechanismu měření,
c) Metrics and measurement mechanism defined;
d. specifikace oficiálních vyzkoušení a prokazování R&S,
d) Formal R&S trials and demonstrations specified;
e. specifikace progresivního zajištění pro dodání R&S vůči cílům milníku,
e) Progressive Assurance specified for delivery of R&S against milestone targets;
f. finanční stimuly stanovené ke splnění požadavků na R&S,
f) Financial incentives established to fulfil R&S requirements;
ČOS 051665 1. vydání
50
g. ustanovení výboru pro vynášení výroků o událostech.
g) Incident Sentencing Committee established.
6.9 Smlouvy na zabezpečení
6.9 Support Contracts Je-li zajišťována R&S, mají být souhrnně určeny následující položky ve smlouvě na zabezpečení softwaru systému:
In summary, the following items should be addressed in a System Software support contract, if R&S are to be assured:
a. udržení požadavků na R&S, a) R&S requirements preserved;
b. udržení definic klíčových slov, b) Key words definitions preserved;
c. udržení metrik a mechanismu měření, c) Metrics and measurement mechanisms preserved;
d. specifikace oficiálních vyzkoušení a prokazování R&S pro upgrady,
d) Formal R&S trials and demonstra-tions specified for Upgrades;
e. specifikace progresivního zajištění k udržení R&S vůči platebním milníkům,
e) Progressive Assurance specified to sustain R&S against payment milestones;
f. finanční stimuly stanovené k zachování R&S vůči požadavkům,
f) Financial incentives established to sustain R&S against requirements;
g. udržování výboru pro vynášení výroků o událostech,
g) Incident Sentencing Committee maintained;
h. stanovení mechanismu pro sdílení úspor.
h) Mechanism established to share savings.
KAPITOLA 7 ZÁVĚR
CHAPTER 7 CONCLUSION 7.1 Všechny aspekty návrhu a zavádění softwaru v rámci komerční oblasti jsou relevantní a použitelné na projekty obranných systémů NATO. Proto úvahy o těchto problémech v koncepční etapě takových projektů mají obrovský význam pro zajištění úspěchu projektu. Tento standard popsal podstatu a důležitost softwaru a navrhl požadavky na specifikování R&S softwaru. Popisuje odpovědnosti a smluvní uspořádání po-žadované pro dodání a udržení bezporuchového a zabezpečovatelného softwaru a navrhl principy a rámec pro jeho provedení. Byly také popsány nástroje a techniky, které mohou být využity pro posouzení a prokazování R&S softwaru.
7.1 All aspects of design and implementation of software within a commercial field are relevant and applicable to NATO defence system projects. Therefore consideration of these issues at the concept stage of such projects is of great importance to ensure project success. This document has described the nature and importance of software and outlined the requirement to specify software R&S. It describes the responsibilities and contractual arrangements required for procuring and sustaining reliable and supportable Software and has outlined the principles and framework to accomplish this. Tools and techniques that can be used for assessing and demonstrating Software R&S have also been described.
7.2 Ve stále se rozvíjející oblasti softwarového inženýrství je zásadně důležité, aby se rozpoznala a aby se porozumělo rozmanitosti, složitosti
7.2 In the ever evolving field of software engineering it is vitally important that the diversity, complexity and varying size of possible software solutions is recognised
ČOS 051665 1. vydání
51
a měnící se délce možných softwarových řešení. Proto má přesná specifikace požadavků, včetně potřeby snižovat skluz požadavku a udržovat sledovatelnost stanoveného požadavku, velký dopad na úspěch projektu.
and understood. Therefore the accurate specification of requirements, including the need to mitigate requirement creep and maintain the traceability of the stated requirement, has a great impact on project success.
7.3 Předmět integrace systému má být určen od etapy koncepce projektu s prvky hardwaru a softwaru, které jsou uvažovány jako jedinečná entita. Má být zaveden oficiální proces managementu k řízení této integrace v průběhu životního cyklu projektu. To má zahrnovat:
7.3 The subject of system integration should be addressed from the Concept stage of the project with the hardware and software elements considered as a single entity. A formal management process should be implemented to control this integration throughout the life cycle of the project. This should include:
a. management rozhraní, a) Interface management;
b. management konfigurace, b) Configuration Management;
c. analýzu možností, c) Options Analysis;
d. oficiální proces pro přezkoumání, d) Formal review process;
e. program testování, e) Test program;
f. dokumentace. f) Documentation.
7.4 Jako u všech projektů je nezbytné efektivně uzavírat smlouvy, aby se zajis-tilo dosažení požadovaných výstupů. Proto má následovat robustní akviziční proces, zejména uzpůsobený na softwa-rový produkt, jako je CMMI a DO 178. Složitá podstata softwaru také vyžaduje využití specializovaných znalců, buď domácích, nebo konzultantů, aby bylo zajištěno, že během vzniku smlouvy a akvizičního procesu nevzniknou žádná nedorozumění a nejednoznačnosti.
7.4 As with all projects, effective contracting is essential to ensure the required output is achieved. Therefore a robust acquisition process, specifically tailored to software projects should be followed, such as CMMI and DO 178. The complex nature of software also requires the use of specialist advisors, either in-house or consultancy, to ensure that misunderstandings and ambiguity does not arise during the contracting and acquisition process.
7.5 Ačkoli má historie softwarového inženýrství mnoho příkladů složitých projektů, které vyžadují následné finan-cování a rozšiřování nejzazších termínů, ukazuje se, že opatrný a vhodný management může zajistit, aby se poža-dovaných výsledků mohlo dosahovat v daném čase a s daným rozpočtem. Pokyny pro uživatele, manažery, zaměstnance projektu a dodavatele pro pořízení a údržbu bezporuchového a zabezpečovatelného softwaru systému v průběhu životního cyklu vybavení obsažené v tomto standardu poskytují počáteční nástroj pro jejich provedení.
7.5 Although the history of software engineering has many examples of complex projects that require additional funds and extended deadlines, it has been shown that careful and appropriate management can ensure that the required results can be achieved on time and budget. The guidance to Users, Managers, project Staff and Suppliers for the procurement and maintenance of Reliable and Supportable System Software, throughout the equipment life cycle, contained within this document provides the initial tools to accomplish this.
ČOS 051665 1. vydání
52
(VOLNÁ STRANA)
ČOS 051665 1. vydání
53
P Ř Í L O H Y
A N N E X E X
ČOS 051665 1. vydání Příloha A
54
PŘÍKLADY METRIK BEZPORUCHOVÉHO SOFTWARU
EXAMPLE SOFTWARE RELIABILITY METRICS
Software má statistické charakteristiky, které zamezují použití hardwarových metrik bezporuchovosti, jako je MTBF. Místo toho softwarový průmysl vytvořil několik metrik specifických pro software, z nichž tři jsou ukázány níže v tabulce.
Software has statistical characteristics, which preclude the use of hardware reliability metrics such as MTBF. Instead, the software industry has developed several software-specific metrics - three of which are shown in the table below.
Metrika Popis Zaměření
POFOD
Pravděpodobnost poruchy na povel
Míra pravděpodobnosti, že systém bude mít chybu, když je proveden požadavek na službu. POFOD=0,001 znamená, že jeden z 1000 služebních požadavků může ve výsledku způsobit poruchu. Je počítán počet poruch a počet služebních požadavků.
Jaká je pravděpodobnost systému být schopen poskytovat jednotlivé služební požadavky?
ROCOF
Intenzita výskytu poruch
Míra výskytu četnosti nesprávného chování. ROCOF=0,02 znamená, že se mohou vyskytnout 2 poruchy ve 100 provozních časových jednotkách. Je počítán počet poruch v rámci celkového uplynulého času.
Kolik poruch se pravděpodobně objeví za nějakou specifikova-nou časovou periodu?
MTTF
Střední doba do poruchy
Míra času mezi pozorovanými poruchami systému. MTTF=1,500 znamená, že poru-cha se může stát každých 1,500 provozních časových jednotek. Poznamenejme, že MTTF a ROCOF jsou vůči sobě reciproké.
Jak je velký časový interval mezi poruchovými událostmi?
Následky poruchy nejsou brány v úvahu.
Metric Description Focus
POFOD
Probability of failure on demand
Measure of the likelihood that the system will fail when a service request is made. POFOD = 0.001 means that 1 out of 1,000 service requests may result in failure. The number of failures and service requests are counted.
What is the system's likelihood of being able to service a discrete service request?
ROCOF
Rate of occurrence of
failure
Measure of the occurrence frequency of in-correct behaviour. ROCOF = 0.02 means that 2 failures may occur in 100 operational time units. The number of failures is counted within the total elapsed time.
How many failures are likely to occur within some specified time period?
MTTF
Mean time to failure
Measure of the time between observed system failures. MTTF = 1,500 means that a failure may happen every 1,500 operational time units. Note that MTTF and ROCOF are reciprocals of each other.
How large is the time interval between failure events?
The consequences of failure are not considered.
ČOS 051665 1. vydání Příloha B
55
ZÁKLADNÍ RÁMEC PRO ŽÁDOST O NÁVRH PŘI POŘÍZENÍ SOFTWARU
SOFTWARE PROCUREMENT RFP FRAMEWORK
1. Technický návrh: 1. Technical Proposal:
a) pokyny pro technický návrh, a) Technical Proposal Guidelines;
b) hodnotící kritéria technického návrhu.
b) Technical Proposal Evaluation Criteria.
2. Práce a dodávané produkty: 2. Work and Deliverables:
a) specifikace činností (SOW), a) Statement of Work (SOW);
b) seznam smluvních požadavků na data (CDRL),
b) Contract Data Requirements List (CDRL);
c) popisy datových položek (DID), c) Data Items Descriptions (DIDs);
6. Státem poskytnutý materiál 6. Government Furnished Materiel
ČOS 051665 1. vydání
56
Účinnost českého obranného standardu od: 25. února 2014
Změny:
Změna číslo
Účinnost od
Změnu zapracoval Datum zapracování
Poznámka
U p o z o r n ě n í :
Oznámení o českých obranných standardech jsou uveřejňována měsíčně ve Věstníku Úřadu pro technickou normalizaci, metrologii a státní zkušebnictví v oddíle „Ostatní oznámení“ a Věstníku MO.
V případě zjištění nesrovnalostí v textu tohoto ČOS zasílejte připomínky na adresu distributora.
Rok vydání: 2020, obsahuje 28 listů
Distribuce: Odbor obranné standardizace Úř OSK SOJ, nám. Svobody 471, 160 01 Praha 6
Vydal: Úřad pro obrannou standardizaci, katalogizaci a státní ověřování jakosti
