SMĚRNICE PRO ŘÍZENÍ BEZPORUCHOVOSTI A UDRŽOVATELNOSTI SOFTWARE

ČESKÝ OBRANNÝ STANDARD SMĚRNICE PRO ŘÍZENÍ BEZPORUCHOVOSTI A UDRŽOVATELNOSTI SOFTWARE Praha

(VOLNÁ STRANA) 2

Č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ů: ARMP-9, Ed.1 STANAG 4174, Ed.3 GUIDE TO THE MANAGEMENT OF SOFTWARE R&M Směrnice pro řízení bezporuchovosti a udržovatelnosti software ALLIED RELIABILITY AND MAINTAINABILITY PUBLICATIONS Spojenecké publikace pro bezporuchovost a udržovatelnost Úřad pro obrannou standardizaci, katalogizaci a státní ověřování jakosti Praha 2014 3

OBSAH Table of Contents Předmět standardu... 6 Nahrazení standardů (norem)... 6 Související dokumenty... 6 Zpracovatel ČOS... 7 Použité zkratky, značky a definice... 7 PROVÁDĚCÍ SHRNUTÍ... 13 Kapitola 1 Úvod... 13 1 Obecně... 13 1.1 Smysl... 15 1.2 Účel... 16 1.3 Použitelnost... 16 1.4 Související dokumenty... 17 KAPITOLA 2 POVAHA SOFTWARU... 17 2.3 Zabezpečení při používání... 21 2.4 Management vad... 21 2.5 Upgrade... 22 2.6 Zabezpečovatelnost... 22 KAPITOLA 3 SPECIFIKACE POŽADAVKŮ NA R&S SOFTWARU... 23 3.1 Bezporuchovost... 23 3.4 Management vad... 25 3.5 Metriky... 26 3.6 Smluvní definice... 26 KAPITOLA 4 Vytvoření programu R&S softwaru... 27 4.1 Plán R&S softwaru... 27 4.2 Případ R&S softwaru... 27 KAPITOLA 5 DODÁVÁNÍ A ŘÍZENÍ R&S SOFTWARU... 28 5.1 Etapa koncepce... 29 5.2 Etapa vývoje... 33 5.3 Etapa produkce... 39 EXECUTIVE SUMMARY... 13 Chapter 1 Introduction... 13 1 General... 13 1.1 Aim... 15 1.2 Purpose... 16 1.3 Applicability... 16 1.4 Related Documents... 17 CHAPTER2 THE NATURE OF SOFTWARE... 17 2.3 Utilization Support.... 21 2.4 Fault Management.... 21 2.5 Upgrades... 22 2.6 Supportability... 22 CHAPTER 3 SPECIFYING SOFTWARE R&S REQUIREMENTS... 23 3.1 Reliability... 23 3.4 Fault Management... 25 3.5 Metric... 26 3.6 Contractual Definitions... 26 CHAPTER 4 Developing a Software R&S Programme... 27 4.1 The Software R&S Plan... 27 4.2 The Software R&S Case... 27 CHAPTER 5 DELIVERING & MANAGING SOFTWARE R&S... 28 5.1 Concept Stage... 29 5.2 Development Stage... 33 5.3 Production Stage... 39 4

5.4 Etapa využívání... 39 5.5 Etapa zabezpečení... 39 5.6 Etapa vyřazení... 43 KAPITOLA 6 UZAVÍRÁNÍ SMLUV NA R&S SOFTWARU... 43 6.1 Software jako jedinečný prvek... 43 6.2 Software jako integrální součást systému... 43 6.3 Definice pojmů... 44 6.4 Progresivní zajištění... 44 6.5 Řízení změnových požadavků... 45 6.6 Přijetí softwaru... 45 6.7 Využívání zabezpečení... 46 6.8 Smlouvy na pořízení... 46 6.9 Smlouvy na zabezpečení... 47 KAPITOLA 7 ZÁVĚR... 47 PŘÍKLADY METRIK BEZPORUCHOVÉHO SOFTWARU... 50 ZÁKLADNÍ RÁMEC PRO ŽÁDOST O NÁVRH PŘI POŘÍZENÍ SOFTWARU... 51 ČOS 051665 5.4 Utilization Stage... 39 5.5 Support Stage... 39 5.6 Retirement Stage... 43 CHAPTER 6 CONTRACTING FOR SOFTWARE R&S... 43 6.1. Software as a Unique Element... 43 6.2. Software as an Integral System Component... 43 6.3. Definition of Terms... 44 6.4. Progressive Assurance... 44 6.5. Managing Changing Requirements... 45 6.6. Software Acceptance... 45 6.7 Utilization Support... 46 6.8 Procurement Contracts... 46 6.9 Support Contracts... 47 CHAPTER 7 CONCLUSION... 47 EXAMPLE SOFTWARE RELIABILITY METRICS... 50 SOFTWARE PROCUREMENT RFP FRAMEWORK... 51 5

Předmět standardu ČOS 051665,, 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 ACMP-7 NATO SYSTEM LIFE CYCLE PROCESSES Procesy životního cyklu systémů v NATO (zavedeno ČOS 051655) 1 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 ČOS 051617 ČOS 051619 ČOS 051649 Požadavky NATO na bezporuchovost a udržovatelnost Směrnice pro vytváření dokumentů NATO pro bezporuchovost a udržovatelnost Směrnice pro řízení bezporuchovosti a udržovatelnosti v provozu 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. 6

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 IEEE Standard 610.12 IEEE Standard 829 IEEE Standard 1016 ISO 12207 ČSN ISO/IEC 12207 RTCA DO-178 SAE JA 1000:2012 SAE JA 1000-1:2012 SAE JA 1002:2012 SAE JA 1003:2012 SAE JA 1004:2012 SAE JA 1005:2012 SAE JA 1006:2012 APPLICATION OF INTEGRATED LOGISTIC SUPPORT (ILS). Použití integrovaného logistického zabezpečení (ILS) STANDARD GLOSSARY OF SOFTWARE ENGINEERING TERMINOLOGY SOFTWARE AND SYSTEM TEST DOCUMENTATION RECOMMENDED PRACTICE FOR SOFTWARE DESIGN DESCRIPTIONS SOFTWARE LIFE CYCLE PROCESSES Informační technologie Procesy v životním cyklu softwaru SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICATION RELIABILITY PROGRAM STANDARD RELIABILITY PROGRAM STANDARD IMPLEMENTATION GUIDE SOFTWARE RELIABILITY PROGRAM STANDARD SOFTWARE RELIABILITY PROGRAM IMPLEMENTATION GUIDE SOFTWARE SUPPORTABILITY PROGRAM STANDARD SOFTWARE SUPPORTABILITY PROGRAM IMPLEMENTA- TION GUIDE SOFTWARE SUPPORT CONCEPT 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 7

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í Computer Aided Software Engineering počítače CEIL Seznam smluvních koncových položek Contract End Items List CM Management konfigurace Configuration Management CMMI Integrovaný model vyzrálosti Capability Maturity Model Integrated způsobilosti 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 International Electrotechnical elektrotechniku Commission IEEE IETM Institut pro elektrotechnické a elektronické inženýrství Interaktivní elektronický technický manuál Institute of Electrical and Electronic Engineers 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ů Incident Sentencing Committee o událostech 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 8

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 SRS Specifikace softwarových požadavků Software Requirements Specification STANAG Standardizační dohoda Standardization Agreement SOW Specifikace činností Statement of Work 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. Firmware Kombinace hardwarového zařízení a počítačových instrukcí nebo počítačový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). 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 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). 9

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. Bezporuchovost softwaru Pravděpodobnost bezporuchové operace softwarového programu během specifikovaného času za specifikovaných podmínek (SAE JA 1002). Udržovatelnost softwaru Snadnost, se kterou může být softwarový systém nebo komponenta modifikována, aby se opravily vady, zlepšil výkon nebo další atributy, nebo aby se adaptoval 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). Zabezpečovatelnost softwaru Soubor atributů návrhu softwaru, související vývojové nástroje a metody a infrastruktura prostředí zabezpečení, které umožňují uskutečnit zabezpečovací činnosti (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). 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). 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í. 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. Software Reliability The probability of failure free operation of a software program for a specified time under specified conditions (SAE JA 1002). Software Maintainability The ease with which a software system or component can be modified to correct faults, improve performance or other 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). 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). 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). Error The difference between a computed, observed, measured value, condition and the true, specified, theoretically correct value or condition. (IEEE Standard 610.12). Failure (software) The inability of a system or component to perform its required functions within specified performance requirements. (IEEE 10

(IEEE standard 610.12). Standard 610.12). Vada (softwaru) Fault (software) 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). Bug Viz Vada (softwaru). 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 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. Model Fyzikální, matematická nebo jiná logická reprezentace systému, entity reálných slov, fenoménů nebo procesu. Simulace Zavedení modelu v průběhu času. Simulátor Člověk v simulační smyčce (HITL). Ověřování Potvrzení objektivního důkazu zkouškou, že jsou splněny specifikované požadavky (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). 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 ČOS 051665 An accidental condition that causes a software functional unit to fail to perform its required functions (SAE JA 1003 - A.2.1). Bug See Fault (software). Baseline (Software Baseline) A specification, document or product that has been formally reviewed and agreed upon at a given time and thereafter serves as the basis for further development. It can only be changed if justified and approved through a formal control procedure. Model A physical, mathematical or otherwise logical representation of a system, real world entity, phenomenon or process. Simulation The implementation of a model over time. Simulator A human in the loop (HITL) simulation. Verification Confirmation by the examination of objective evidence that specified requirements have been fulfilled (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). Independent Verification and Validation (IV&V) Verification and validation performed by an organization that is technically, managerially, and financially independent of 11

(IEEE 610.12). the development organization (IEEE 610.12). Aktualizace Update Nová verze existujícího softwarového programu, která je modifikována k odstranění vad. Upgrade Nová verze existujícího softwarového programu, která je modifikována, aby poskytla novou schopnost. New version of an existing software program that has been modified to remove faults. Upgrade New version of an existing software program that has been modified to provide a new capability. 12

PROVÁDĚCÍ SHRNUTÍ 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ě. 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 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. Nejdůležitější mechanismy managementu založeného na provedení programu 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í. Ú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ěpodobnost, že výsledný produkt bude splňovat jejich požadavky a bude dodávat zamýšlenou schopnost v průběhu životního cyklu vybavení, za optimálních nákladů. KAPITOLA 1 ÚVOD EXECUTIVE SUMMARY 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. 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 performancebased 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. 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. CHAPTER 1 INTRODUCTION 1 Obecně 1 General S rostoucí sofistikací moderního vybavení, vzrůstající miniaturizací elektroniky a přesunu od analogového k digitálnímu zpracování, začleňuje stále více systémů With the growing sophistication of modern equipment, the increasing miniaturization of electronics and the move from analogue to digital processing, more and more systems 2 SAE JA 1002, paragraf 4.3 Základní rámec managementu. SAE JA 1002 para 4.3 Management Framework 13

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. U obranných zařízení tvoří software integrá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í. Individuální charakteristiky jakéhokoliv softwaru budou přispívat k celkové úrovni bezporuchovosti a udržovatelnosti, dosažené systémem jako celkem. 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 času 3. Mnoho problémů spojených s hybridními systémy vzniká na rozhraní mezi softwarem 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. Zatímco bezporuchovost je právě tak významná u softwaru, jako u mechanických a elektronických systémů, koncepci udržovatelnosti není jednoduché použít. V čistě softwarovém kontextu je udržovatelnost vytlačena pojmem zabezpečovatelnost, 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 komunitou mnoho let tak, aby odrážela činnosti požadované pro vývoj 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. 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. 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 time 3. 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. 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 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 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. 14

a udržení softwaru v průběhu životního cyklu produktu (viz SAE JA 1002, ČOS 051655). 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ředstavuje 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éčí. 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ů. 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. Se zřetelem na rozmanitost a složitost softwaru neexistuje universální řešení pro efektivní dodání, neřku-li pro bezporuchové a zabezpečovatelné programy. ČOS 051665 Software over a producťs life cycle (see SAE JA 1002, AAP-48). 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. 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. 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. 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ům 4, manažerům, zaměstnancům The aim of ARMP-9 is to provide guidance to Sponsors 4, Managers, Project Staff and 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. 15

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í. 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. Describe tools and techniques that can be used for assessing and demonstrating Software R&S; c. popsat nástroje a techniky, které se mohou použít pro posuzování a prokazování R&S softwaru, d. popsat principy a základní rámec požadovaný pro dodání a udržení bezporuchového a zabezpečovatelného softwaru, e. popsat role a odpovědnosti spojené s dodáním a udržením bezporuchového a zabezpečovatelného softwaru, f. popsat smluvní ujednání doporučovaná pro dodání a udržení bezporuchového a zabezpečovatelného softwaru. 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í 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í. 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ě: d. Describe the principles and framework required for procuring and sustaining reliable and supportable Software; e. Describe the roles and responsibilities associated with procuring and sustaining reliable and supportable Software; f. Describe contractual arrangements recommended for procuring and sustaining reliable and supportable Software. 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 document seeks to provide a comprehensive framework and guiding principles for the effective management of Software R&S throughout the equipment life cycle. 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, - Custom-built mission critical Software; kritického vůči požadavkům úkolu, - komerčně nakupovaného softwaru - COTS Software adapted for specific adaptovaného pro specifické aplikace, applications; - operačního systému, - Operating system; 16

- 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. ČOS 051665 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 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 STANAG 4174: Allied Reliability and Maintainability Publications 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 2 Pokud jde o pojmy, software je soubor instrukcí, které umožňují počítači 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 systému systémů. V sofistikovaných platformá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 CHAPTER2 THE NATURE OF SOFTWARE 2. In simple terms, Software is a set of instructions, which enables a computer 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 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. 17

softwarových programů spuštěných současně, aby efektivně provozovaly celý systém. 2.1 Software se od hardware liší v mnoha zřetelech, které mohou být sumarizovány následovně: 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. 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é. Mnohonásobná reprodukce softwaru však bude také obsahovat vady, které mohou být přítomny v původní originální verzi. 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řesnosti, může způsobit při pokusu udržet řízení konfigurace další efficiently. 2.1 Software differs from Hardware in a number of ways, which may be summarized as follows: 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) 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, however, will also include any faults, which may be present in the original master version. 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 18

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. d. software není ovlivněn fyzikálními podmínkami, ačkoli hardware pro zabezpečení může být ovlivněn hodně, 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í, 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í. 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. 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). 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 prostředí. 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í ČOS 051665 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 is not affected by physical conditions, although the supporting hardware may well be. 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. 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) 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) 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) 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 representative operating environment. 2.2 Since many defence systems rely on computers to function correctly, it is essential that the supporting Software be managed as 19

ří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 Většina softwaru bude mít následující charakteristiky: 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 Most Software will possess the following characteristics: a. Jazyk softwarové programy jsou psány v jednom z mnoha počítačových jazyků. Ty jsou uspořádány od nízkoúrovňových generických jazyků, jako je strojový kód, k vysokoúrovňovým specializovaným jazykům, jako je C++ nebo JAVA. Pro aplikace s vysokou ú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žitosti 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. 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. 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ů. a) Language Software programs are written in one of many computer languages. These range from low-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) 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) 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 d) Security: Many applications incorporate 6 Viz SAE JA 1003 a 1005 See SAE JA - 1003 and 1005. 20

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. ČOS 051665 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. 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: 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)), Once equipment enters the Utilization Stage 7, the system Software should be supported by a single nominated organization 8 which will be responsible for: 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); e. uvolnění softwaru, e) Software release; f. řízení konfigurace, standardizační dokumenty, f) Configuration management/standardization documentation; 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. Softwarové vady jsou normálně řešeny v dávkách a uvolňovány do míst zavedení 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. Software faults are normally resolved in batches and released to the field as periodic 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. 21

jako periodické aktualizace, buď jako nové vydání, nebo softwarová 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. 2.5 Upgrade 2.5 Upgrades Funkcionalita obranného systému může být modifikována, aby se zlepšila bezporuchovost, zvětšila schopnost/provedení nebo rozšířilo použití o nové provozní prostředí. Konfigurace hardware a provozní 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). 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. Upgrady a aktualizace se tam, kde je to možné, mají kombinovat, aby se minimalizoval 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 harmonogramu preventivní údržby hardwaru. 2.6 Zabezpečovatelnost 2.6 Supportability Koncepce udržovatelnosti hardwaru se u softwaru nesnadno využívá, neboť se předpokládá jednoduchost, se kterou může updates, either as a new release or Software patch. However, safety critical faults should be fixed with a higher priority and released immediately as emergency updates in the form of a Software patch. 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). 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. 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. The concept of Hardware Maintainability does not readily apply to Software since it is concerned with the ease with which a system 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. 22

být systém obsluhován nebo opravován. Proto se software pokrývá pojmem zabezpečovatelnost 10. Z předchozích diskusí je evidentní, že u softwaru 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, technické 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. ČOS 051665 can be serviced or repaired. Therefore Software is covered by the term Supportability 10. 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 softwarových komponent. Proto mohou být požadavky na bezporuchovost softwaru odvozeny od požadavků na bezporuchovost systému. Požadavky na bezporuchovost softwaru a jejich správná specifikace 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žadavky 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: 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é c) Impact of a failure on software or data 10 Viz koncepci zabezpečení v SAE JA 1006. See support concept SAE JA 1006. 23