ČOS 051665 1. vydání ČESKÝ OBRANNÝ STANDARD
SMĚRNICE PRO ŘÍZENÍ BEZPORUCHOVOSTI A UDRŽOVATELNOSTI SOFTWARE
Praha
ČOS 051665 1. vydání
(VOLNÁ STRANA)
2
ČOS 051665 1. vydání Č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
GUIDE TO THE MANAGEMENT OF SOFTWARE R&M Směrnice pro řízení bezporuchovosti a udržovatelnosti software
STANAG 4174, Ed.3
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
ČOS 051665 1. vydání 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
EXECUTIVE SUMMARY.......................... 13
Kapitola 1 Úvod ........................................... 13
Chapter 1 Introduction ................................. 13
1 Obecně ....................................................... 13
1 General ...................................................... 13
1.1 Smysl................................................... 15
1.1 Aim ..................................................... 15
1.2 Účel ..................................................... 16
1.2 Purpose ............................................... 16
1.3 Použitelnost ......................................... 16
1.3 Applicability ....................................... 16
1.4 Související dokumenty ........................ 17
1.4 Related Documents ............................. 17
KAPITOLA 2 POVAHA SOFTWARU ...................................................................... 17
CHAPTER2 THE NATURE OF SOFTWARE ................................................ 17
2.3 Zabezpečení při používání .................. 21
2.3 Utilization Support.............................. 21
2.4 Management vad ................................. 21
2.4 Fault Management. ............................. 21
2.5 Upgrade ............................................... 22
2.5 Upgrades ............................................. 22
2.6 Zabezpečovatelnost ............................. 22
2.6 Supportability ..................................... 22
KAPITOLA 3 SPECIFIKACE POŽADAVKŮ NA R&S SOFTWARU ...... 23
CHAPTER 3 SPECIFYING SOFTWARE R&S REQUIREMENTS ............................. 23
3.1 Bezporuchovost................................... 23
3.1 Reliability ........................................... 23
3.4 Management vad ................................. 25
3.4 Fault Management .............................. 25
3.5 Metriky ................................................ 26
3.5 Metric .................................................. 26
3.6 Smluvní definice ................................. 26
3.6 Contractual Definitions ....................... 26
KAPITOLA 4 Vytvoření programu R&S softwaru ........................................................ 27
CHAPTER 4 Developing a Software R&S Programme ................................................... 27
4.1 Plán R&S softwaru ............................. 27
4.1 The Software R&S Plan...................... 27
4.2 Případ R&S softwaru .......................... 27
4.2 The Software R&S Case ..................... 27
KAPITOLA 5 DODÁVÁNÍ A ŘÍZENÍ R&S SOFTWARU ................................................ 28
CHAPTER 5 DELIVERING & MANAGING SOFTWARE R&S ....................................... 28
5.1 Etapa koncepce ................................... 29
5.1 Concept Stage ..................................... 29
5.2 Etapa vývoje........................................ 33
5.2 Development Stage ............................. 33
5.3 Etapa produkce.................................... 39
5.3 Production Stage ................................. 39
4
ČOS 051665 1. vydání 5.4 Etapa využívání ................................... 39
5.4 Utilization Stage ................................. 39
5.5 Etapa zabezpečení ............................... 39
5.5 Support Stage ...................................... 39
5.6 Etapa vyřazení ..................................... 43
5.6 Retirement Stage ................................. 43
KAPITOLA 6 UZAVÍRÁNÍ SMLUV NA R&S SOFTWARU ....................................... 43
CHAPTER 6 CONTRACTING FOR SOFTWARE R&S ....................................... 43
6.1 Software jako jedinečný prvek............ 43
6.1. Software as a Unique Element ........... 43
6.2 Software jako integrální součást systému ................................................................... 43
6.2. Software as an Integral System Component ................................................ 43
6.3 Definice pojmů.................................... 44
6.3. Definition of Terms ........................... 44
6.4 Progresivní zajištění ............................ 44
6.4. Progressive Assurance ....................... 44
6.5 Řízení změnových požadavků ............ 45
6.5. Managing Changing Requirements ... 45
6.6 Přijetí softwaru .................................... 45
6.6. Software Acceptance ......................... 45
6.7 Využívání zabezpečení ....................... 46
6.7 Utilization Support.............................. 46
6.8 Smlouvy na pořízení ........................... 46
6.8 Procurement Contracts........................ 46
6.9 Smlouvy na zabezpečení ..................... 47
6.9 Support Contracts ............................... 47
KAPITOLA 7 ZÁVĚR................................. 47
CHAPTER 7 CONCLUSION ...................... 47
PŘÍKLADY METRIK BEZPORUCHOVÉHO SOFTWARU ................................................ 50
EXAMPLE SOFTWARE RELIABILITY METRICS .................................................... 50
ZÁKLADNÍ RÁMEC PRO ŽÁDOST O NÁVRH PŘI POŘÍZENÍ SOFTWARU ...... 51
SOFTWARE PROCUREMENT RFP FRAMEWORK ............................................ 51
5
ČOS 051665 1. vydání
Předmět standardu Č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 používaná v ARMP
Č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
1
pro
bezporuchovost
a
udržovatelnost
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
ČOS 051665 1. vydání 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 IMPLEMENTATION GUIDE
SAE JA 1006:2012
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 Allied Configuration Management konfigurace Publication
ACT
Roční frekvence změn
Annual Change Traffic 7
ČOS 051665 1. vydání 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
EEPROM
Elektricky mazatelná programovatelná Electrically Erasable Programmable paměť pouze pro čtení 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
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ů Two character code for SAE ground a pokynů SAE pro pozemní vozidla (J) vehicle (J) and aerospace (A) standards a letectví (A) and guidelines
KSLOC
Tisíce (K) zdrojových řádků kódu
Data Items Descriptions
8
Thousands (K) of Source Lines of Code
ČOS 051665 1. vydání 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
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.
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
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).
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
ČOS 051665 1. vydání Systémový software
System 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 (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
Software Reliability
Pravděpodobnost bezporuchové operace softwarového programu během specifikovaného času za specifikovaných podmínek (SAE JA 1002).
The probability of failure free operation of a software program for a specified time under specified conditions (SAE JA 1002).
Udržovatelnost softwaru
Software Maintainability
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).
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).
Zabezpečovatelnost softwaru
Software Supportability
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).
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
Enterprise Application
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).
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
Error
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).
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)
Failure (software)
Neschopnost systému nebo komponenty provádět její požadované funkce v mezích specifikovaných požadavků na provedení.
The inability of a system or component to perform its required functions within specified performance requirements. (IEEE 10
ČOS 051665 1. vydání (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).
An accidental condition that causes a software functional unit to fail to perform its required functions (SAE JA 1003 - A.2.1).
Bug
Bug
Viz Vada (softwaru).
See Fault (software).
Základní úroveň (Softwarová základní úroveň)
Baseline (Software Baseline)
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.
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
Model
Fyzikální, matematická nebo jiná logická reprezentace systému, entity reálných slov, fenoménů nebo procesu.
A physical, mathematical or otherwise logical representation of a system, real world entity, phenomenon or process.
Simulace
Simulation
Zavedení modelu v průběhu času.
The implementation of a model over time.
Simulátor
Simulator
Člověk v simulační smyčce (HITL).
A human in the loop (HITL) simulation.
Ověřování
Verification
Potvrzení objektivního důkazu zkouškou, že jsou splněny specifikované požadavky (IEEE 610.12).
Confirmation by the examination of objective evidence that specified requirements have been fulfilled (IEEE 610.12).
Ověřování a validace (V&V)
Verification and Validation (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).
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)
Independent Verification and Validation (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
Verification and validation performed by an organization that is technically, managerially, and financially independent of
11
ČOS 051665 1. vydání (IEEE 610.12).
the development 610.12).
Aktualizace
Update
Nová verze existujícího programu, která je k odstranění vad.
softwarového modifikována
organization
(IEEE
New version of an existing software program that has been modified to remove faults.
Upgrade
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 provide a new capability.
12
ČOS 051665 1. vydání
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 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í.
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.
Ú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ů.
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í 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
ČOS 051665 1. vydání 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.
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 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.
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 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.
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 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
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
ČOS 051665 1. vydání a udržení softwaru v průběhu životního cyklu produktu (viz SAE JA 1002, ČOS 051655).
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ř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éčí.
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.
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.
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
The aim of ARMP-9 is to provide guidance to Sponsors4, 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
ČOS 051665 1. vydání 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. Describe the specification of Software R&S requirements; c. Describe tools and techniques that can be used for assessing and demonstrating Software R&S; d. Describe the principles and framework required for procuring and sustaining reliable and supportable Software;
b. popsat specifikace požadavků na 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.
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.
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í.
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.
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:
-
-
Application Software; Custom-built mission critical Software;
-
COTS Software adapted for specific applications; Operating system;
-
aplikačního softwaru, zákazníkem postaveného softwaru, kritického vůči požadavkům úkolu, komerčně nakupovaného softwaru adaptovaného pro specifické aplikace, operačního systému,
-
16
ČOS 051665 1. vydání - softwaru kritického vůči bezpečnosti. Principy by však také mohly být použity na obecnější software, včetně podnikových aplikací5.
- Safety critical Software. 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 bezporuchovost a udržovatelnost
ARMP-1 NATO Requirements Reliability and Maintainability.
na
for
ARMP-4 Směrnice pro zpracování dokumentů s požadavky NATO na bezporuchovost a udržovatelnost
ARMP-4 Guidance for Writing NATO R&M Requirement Documents.
ARMP-6 Směrnice pro řízení bezporuchovosti a udržovatelnosti v provozu
ARMP-6 Guidance for Managing In-Service R&M.
ARMP-7 Terminologie NATO pro bezporuchovost a udržovatelnost použitá v ARMP
ARMP-7 NATO R&M 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 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
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
Terminology
ČOS 051665 1. vydání softwarových programů spuštěných současně, aby efektivně provozovaly celý systém.
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. 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ší
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.
18
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
ČOS 051665 1. vydání 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í 19
d)
e)
f)
g)
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. Software is not affected by physical conditions, although the supporting hardware may well be. 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. 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. 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
ČOS 051665 1. vydání ří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
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 charakteristiky:
následující
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.
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.
bude
mít
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ů. d. Utajení – mnoho aplikací včleňuje
6
Viz SAE JA – 1003 a 1005 See SAE JA - 1003 and 1005.
20
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) Security: Many applications incorporate
ČOS 051665 1. vydání 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.
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:
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)), b. prostředí softwarového inženýrství, c. technické dokumenty (jak je požadováno plánem vývoje softwaru (SDP)), d. analýzu zabezpečení softwaru (SAS), e. uvolnění softwaru, f. řízení konfigurace, standardizační dokumenty, g. management upgrade a aktualizací, h. výcvik.
a) Maintaining the master program or application source code. (This may not always be possible if Intellectual Property Rights(IPR) are not held); b) Software engineering environment; c) Engineering documents (as required by Software Development Plan (SDP); d) Support Analysis for Software (SAS); e) Software release; f) Configuration management/Standardization documentation; g) Upgrade and update management; 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í
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
ČOS 051665 1. vydání 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.
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.
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).
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 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.
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ť se předpokládá jednoduchost, se kterou může
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
ČOS 051665 1. vydání být systém obsluhován nebo opravován. Proto se software pokrývá pojmem zabezpečovatelnost10. 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.
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 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, b. dobu na zotavení z poruchy, c. vliv poruchy na software nebo datové
a) Criticality of failure for whole system; b) Time to recover from a failure; 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
ČOS 051665 1. vydání prvky, d. požadovaný zásah operátora poté, co se porucha objeví. Aby byly požadavky na bezporuchovost softwaru smysluplné, mají být specifikovány kvantitativně, což bude vyžadovat použití vhodných metrik.
elements; d) Required intervention of an operator after a failure has occurred. To be meaningful, software reliability requirements should be specified quantitatively, which will require the application of suitable metrics.
Tradiční míry bezporuchovosti u hardwaru, 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 bezporuchovosti 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, b. kalendářní doba: časový údaj, c. uplynulá doba: doba od zahájení provádění programu, včetně doby čekání a doby provádění dalších programů.
a) Execution time: The time spent by a processor in executing a program; b) Calendar time: Time of day; c) Elapsed time: The time since start of software execution, including waiting time and execution time of other programs. The relation between time and failures, being one of the possible parameters for Software
Vztah mezi dobou a poruchami, což je jeden z možných parametrů specifikace
24
ČOS 051665 1. vydání bezporuchovosti softwaru, pak může být vyjádřena veličinou, jako je:
Reliability specifications, may then be expressed by quantities such as:
a. časový interval mezi poruchami, b. doba před poruchou (nebo bezporuchová provozní perioda), c. intenzita nebo hustota poruch (počet poruch za jednotku času)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ě:
a) Time interval between failures; b) Time before failure (or failure free operating period); c) Failure intensity or density (the number of failures per unit time). 11 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, b. ztráty jakékoliv funkce kritické vůči úkolu, c. přijatelný rozsah ztráty dat, d. zásadní informace, které musí být chráněny před poruchou.
a. Loss of any safety critical functions;
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ý model vyzrálosti způsobilosti (CMMI) z Institutu softwarového inženýrství nebo přístup, který zastává RTCA 00178. b. odolnost vůči vadám: Vlastnost návrhu, která umožňuje systému pokračovat v provozu12 navzdory vadám softwaru
a) Fault Avoidance: Endeavor to get the software right first time using formal techniques such as the Software Engineering Institute's Capability Maturity Model Integrated (CMMI) or the approach advocated by RTCA 00178. b) Fault Tolerance: A property of design which allows a system to continue to operate12 despite software faults or return
b. Loss of any mission critical functions; c. Tolerable amount of data loss; d. Vital information that must be protected from failures.
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.
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.
25
ČOS 051665 1. vydání nebo návrat ke známé bezpečné podmínce. Je to koncepce chyb, kdy jedna příčina nezpůsobí poruchu a obvykle využívá nadbytečnosti paralelních softwarový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. c. vyhledávání vad: Vlastnost návrhu, která k monitorování softwaru systé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 kritické 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. 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ě.
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) 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) 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, které zbývají v programu. Příklady softwarových metrik jsou uvedeny v příloze A.
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 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čovatelnosti 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.
26
ČOS 051665 1. vydání
KAPITOLA 4 VYTVOŘENÍ PROGRAMU R&S SOFTWARU
CHAPTER 4 DEVELOPING A SOFTWARE R&S PROGRAMME
4. Účelem této kapitoly je popsat jednoduchý 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, b. požadavkům na R&S softwaru je porozuměno a jsou uživatelem zavedeny, c. případ R&S softwaru je udržován, aby poskytl přesný a aktuální záznam postupu oproti požadavkům. Plán R&S má tvořit integrální část plánu vývoje softwaru, který postupně tvoří část celkového plánu projektu.
a) Requirements for Software R&S are derived from and remain consistent with system level requirements; b) Requirements for Software R&S are understood and implemented by the Supplier; c) A Software R&S Case is maintained to provide an accurate and current record of progress against the requirement. 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.
13
SAE JA -1002, paragraf 4.3 „Základní rámec managementu“. SAE JA-1002 para 4.3 "Management Framework".
27
ČOS 051665 1. vydání 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. 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.
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 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
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:
14
Etapy a procesy životního cyklu systému v NATO. NATO System Life Cycle Stages and Processes.
28
ČOS 051665 1. vydání přizpůsobitelných etap: a. koncepce, b. vývoj, c. produkce, d. využívání, e. zabezpečení, f. vyřazení. 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 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í.
a) Concept; b) Development; c) Production; d) Utilization; e) Support; f) Retirement. 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 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í,
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
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
29
ČOS 051665 1. vydá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.
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 potřebám projektu16:
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, tailored to the specific needs of a project:16
a. požadavky na dokumentaci, b. metody vývoje softwaru17. Zásady pro opětovné použití softwaru (opětovné použití a modifikace zděděného softwaru). c. metody, problémy a rizika integrace softwaru, 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í, e. nástroje a techniky používané při vývoji/údržbě softwaru18, f. řízení konfigurace: management změn, schvalování a sledování, g. proces uvolňování verzí19,
a) Documentation requirements; b) Software development methods.17 Software reuse-policy (reuse and modification of legacy software); c) Software integration methods, issues and risks; d) Handling of Critical Requirements, including: safety-critical, mission-critical, information assurance and security; e) Tools and techniques used in the development/maintenance of software;18 f) Configuration Control: change management, approval and tracking. g) Version release process;19
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.
30
ČOS 051665 1. vydání h. použitelné standardy, i. požadavky na hardware při vývoji, využívání a zabezpečování, 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, l. ověřování a validace softwaru a nezávislé ověřování a validace, m. proces podávání zpráv o datech, n. proces distribuce upgradovaného softwaru, o. audit a ověření instalovaného softwaru.
h) Applicable standards; i) Hardware requirements for Development, Utilization and Support; j) Software build-strategy (including coding style guidelines); k) Testing methodology, including: unit / integration / system test and documentation; l) project verification & validation and Independent Verification & Validation; m) Data reporting process; n) Software upgrade distribution process;
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, b. kompilátor musí být podporován během celého životního cyklu, c. jazyk musí být vhodný pro aplikace21,
a. The host platform must support the language;20 b. The compiler must be supported during the whole life cycle; c. The language must be suitable for the application;21 d. The popularity of the language;22 e. Open language specification;23
o) Audit and software.
d. oblíbenost jazyka22, e. otevřená specifikace jazyka23,
verification
of
installed
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, workaround and documentation.
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.
31
ČOS 051665 1. vydání f. efektivnost jazyka (rychlost provádění a požadavky na paměť), g. flexibilita, kompatibilita a jednoduchost integrace24, h. bezporuchovost kompilátoru 25 a zabezpečení dodavatelem , i. jazyky/kompilátory jsou certifikovány vůči požadovaným bezpečnostním standardům.
f. Language efficiency (speed of execution and memory requirements); g. Flexibility, compatibility and ease of integration;24 h. Compiler reliability and Supplier support;25 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 nondevelopmental 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,
The advantages of COTS products are their maturity, availability, large user base26,
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ů? Track record, how long has it been around? How many users are there?
32
ČOS 051665 1. vydání 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:
reliability27 and reduced cost. However, there are numerous issues that should be considered, including:
a. práva na data a licenční požadavky, b. nedostatek řízení nebo schopnosti aktualizovat a udržovat produkt, c. zastarávání, d. zabezpečení dodavatelem, e. schopnost mít rozhraní s ostatními produkty, f. testování (může být omezeno na testování funkčnosti), g. provedení, monitorování a zlepšování,
a) Data rights and licensing requirements; b) Lack of control or ability to update and maintain the product; c) Obsolescence; d) Supplier support; e) Ability to interface with other products;
h. i. j. k. l.
snižování rizik, utajení, informace a výcvik, integrace, hostitelská platforma prostředí, m. změny trhu.
a
provozní
f) Testing (may be limited to functional testing); g) Performance monitoring and improvement; h) Risk mitigation; i) Security. j) Information and training; k) Integration; l) Host platform and operational environment; 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žadavků projektu a spouští návrh softwaru. Má zahrnovat: využití plánu tvorby softwaru, 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
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.
33
ČOS 051665 1. vydání operating systems. Etapa vývoje je pro R&S softwaru kritickou etapou, neboť vytváří základ pro dodání bezporuchového a zabezpečovatelného softwaru. Etapa vývoje může zahrnovat kódování zákaznického softwaru, modifikace existujícího softwaru nebo integraci COTS softwaru do systému.
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 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í)
5.2.1 Application of Software R&S Principles (Requirement Analysis Process; Architectural Design Process; Implementation Process)
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 definicí požadavků na vývoj nebo akvizicí softwaru. Zatímco použitelnost specifických R&S postupů bude funkcí bezporuchovosti významného softwaru, požadavky na R&S musí být sledovatelné v průběhu činností etapy vývoje. Dokument s návrhem softwaru, který definuje architekturu produktu, má zahrnovat požadavky na R&S, jako je modularita, 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čovatelnost 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
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).
34
ČOS 051665 1. vydání 2). 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ěž“, experimentová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 využita efektivní simulace softwarových aplikací během vývoje.
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 interfaces and surrounding infrastructure. Effective Simulation of Software applications during development can be used to improve both R&S.
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.
35
ČOS 051665 1. vydání 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 selfcontained 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.
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ů, b. integrační testování: testování dvou nebo
a) Unit testing: the testing of software modules; b) Integration testing: the testing of two or
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.
36
ČOS 051665 1. vydání vice kombinovaných modulů, c. testování systému: testování všech softwarových modulů v systému, d. regresní testování: opětovné testování po provedení modifikace nebo změnách, e. testování zatížení: testování softwaru mimo jeho zamýšlený rozsah, f. integrační testování softwaru vůči hardwaru: testování softwaru ve spojení s představitelem hardwaru, g. přejímací testování: oficiální testování systému oproti smluvním požadavkům, h. provozní testování: testování koncových funkcí oproti provozním scénářům. Veškeré testování softwaru musí být zabezpečeno dokumentací:
more combined modules; c) System testing: the testing of all of software modules within a system; d) Regression testing: re-testing after modification or changes; e) Stress testing: testing software outside its intended envelope. f) Software to Hardware Integration testing: the testing of software in conjunction with representative hardware; g) Acceptance testing: formal testing of a system against contractual requirements; h) Operational testing: testing end-to-end functions against operational scenarios. 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 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:
Test Procedures. Test Procedures describe the activities which should be undertaken to test a Software module or application, the conditions under which 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í, b. kriteria dokončení: podmínky, které určují úspěch,
a) Test Objectives: defines the intended goal of the testing stage; b) Completion criteria: the condition that determines success;
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.
37
ČOS 051665 1. vydání c. odpovědnosti: popisují role dodavatele a zákazníka, d. použitelné standardy a dokumenty, e. nástroje: včetně softwarových a hardwa rových produktů, kontrolních seznamů a instrukcí, f. zdroje: systémy, zařízení a lidské zdroje atd., g. postupy pro podávání zpráv: zápisy a sledování chyb (viz FRACAS v ČOS 051649, příloha F), h. regresní testování. 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.
f) Resources: systems, facilities and human resources, etc.; g) Reporting procedures: error logging and tracking (see FRACAS in ARMP-6 Annex F); h) Regression testing. 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 R&S softwaru, avšak jakékoliv použité nástroje mají být schváleny příslušným orgánem.
Software development can be supported by a variety of automated or computer-assisted tools. These range from requirementdefinition 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 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);
32
c) Responsibilities: describes Supplier and Customer roles; d) Applicable Standards and Documents; e) Tools: including Software or Hardware products, checklists and instructions;
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).
38
ČOS 051665 1. vydání b. vady na tisíc řádků kódu (kSLOC nebo KSLOC), c. počet modulů, d. velikost programu (kB), e. roční frekvence změn (ACT), f. čísla složitosti kódu.
b) Faults per Thousand Source Lines of Code (kSLOC or KSLOC); c) Number of modules; d) Program Size (Kbytes); e) Annual Change Traffic (ACT); 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 activities 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 Software to be undertaken, with progressive increase in functionality34.
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
Software, like Hardware, requires support throughout the life cycle, a key element of which is change management. Software may
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.
39
ČOS 051665 1. vydání 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.
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, b. ROCOF – intenzita výskytu poruch, c. MTTF – střední doba do poruchy. 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) POFOD - Probability of failure on Demand; b) ROCOF - Rate of Occurrence of Failure; c) MTTF - Mean Time to Failure. 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).
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. b. c. d. e. f. g. h. i.
a) b) c) d) e) f) g) h) i)
management vad, monitorování provedení softwaru, management rizik, management zastarávání, management konfigurace, zabezpečování kvality, management dokumentace, výcvik, podporu programátorů.
Fault Management; Software Performance Monitoring; Risk Management; Obsolescence Management; Configuration Management; Quality Assurance; Documentation Management; Training; 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
Configuration Management (CM) is a discipline for controlling the evolution of hardware, software, services and
40
ČOS 051665 1. vydání 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:
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, b. konfigurace softwaru, monitorování a řízení, c. auditování konfigurace softwaru (jak funkční, tak fyzické).
a) Software configuration identification; b) Software configuration, monitoring and control; c) Software configuration auditing (both functional and physical).
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 sideeffects. 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) Complexity: the number of software modules affected by the change; qualitative assessment of complexity compared to other changes; c) Size of modification. The number of SLOC and the number of modules affected; d) Criticality. The potential effect on the primary mission and safety;
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, c. velikost modifikace: počet SLOC a počet ovlivněných modulů, d. kritičnost: možný vliv na základní úkol a bezpečnost,
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.
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.
41
ČOS 051665 1. vydání e. faktory rozhraní: modifikace související se změnami hardwaru nebo sítě, f. testovatelnost: jak obtížné je testovat proces, g. lidské faktory, h. dokumentace: nedostatečná nebo nevhodná dokumentace.
e) Interface factors. The modification related to hardware or network changes; f) Testability. How difficult is the testing process; g) Human factors; 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:
a. plánů pro testování, b. popisů testování, c. testovacích postupů, d. výsledků testů a zpráv z testování, e. testovacích nástrojů a programů. Testování se má také využít u komerčně nakupovaného softwaru na úrovni systému nebo modulů.
a) Test plans; b) Test descriptions; c) Test procedures; d) Test results and reports; e) Testing tools and programs. 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. b. c. d.
a) b) c) d)
zastarávání softwaru, integrita softwaru mezi verzemi, bezpečnost, udržování sledovatelnosti vůči původním požadavkům, e. udržování nástrojů pro vývoj softwaru a zabezpečení.
Software Obsolescence; Software Integrity between versions; Safety; Maintaining traceability to original requirements; e) Maintaining software development and support tools.
42
ČOS 051665 1. vydání 5.6 Etapa vyřazení Činnosti R&S softwaru vyřazení jsou omezeny na:
5.6 Retirement Stage během
etapy
Software R&S activities during Retirement Stage are limited to:
the
a. řízenou likvidaci klasifikovaných dat, b. řízené archivování programových dat a dokumentace, c. zadokumentování získaných zkušeností v průběhu životního cyklu ve prospěch následníka systémů.
a) Controlled disposal of classified data; b) Controlled archiving of programme data and documentation; 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í 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ů.
6. 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 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 zabezpečení jako samostatný prvek. V kapitole smlouvy nazvané „Software“ má být určena bezporuchovost a zabezpeč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
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
43
ČOS 051665 1. vydání spojených požadavků má být aktivně řízeno a postup má být přezkoumán během milníků projektu. 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í.
these interlinked requirements should be actively managed and progress reviewed at project milestones. 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.
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é
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
44
ČOS 051665 1. vydá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).
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).
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
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, 45
ČOS 051665 1. vydání žádnou změnu definic nebo v procesu evidence, ustavených během pořízení. Mohou existovat změny 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.
it is important that no changes are made to any of the definitions or accounting processes established during procurement. Should 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, b. definice klíčových slov, c. definice metrik a mechanismu měření,
a) R&S requirements must be specified; b) Key words defined; c) Metrics and measurement mechanism defined; d) Formal R&S trials and demonstrations specified; e) Progressive Assurance specified for delivery of R&S against milestone targets; f) Financial incentives established to fulfil R&S requirements; g) Incident Sentencing Committee established.
d. specifikace oficiálních vyzkoušení a prokazování R&S, e. specifikace progresivního zajištění pro dodání R&S vůči cílům milníku, f. finanční stimuly stanovené ke splnění požadavků na R&S, g. ustanovení výboru pro vynášení výroků o událostech. 46
ČOS 051665 1. vydání 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, b. udržení definic klíčových slov, c. udržení metrik a mechanismu měření, d. specifikace oficiálních vyzkoušení a prokazování R&S pro upgrady, e. specifikace progresivního zajištění k udržení R&S vůči platebním milníkům, f. finanční stimuly stanovené k zachování R&S vůči požadavkům, g. udržování výboru pro vynášení výroků o událostech, h. stanovení mechanismu pro sdílení úspor.
a) R&S requirements preserved; b) Key words definitions preserved; c) Metrics and measurement mechanisms preserved; d) Formal R&S trials and demonstrations specified for Upgrades; e) Progressive Assurance specified to sustain R&S against payment milestones; f) Financial incentives established to sustain R&S against requirements; g) Incident Sentencing Committee maintained; 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 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.
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 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.
47
ČOS 051665 1. vydání 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. b. c. d. e. f.
a) b) c) d) e) f)
management rozhraní, management konfigurace, analýzu možností, oficiální proces pro přezkoumání, program testování, dokumentace.
Interface management; Configuration Management; Options Analysis; Formal review process; Test program; Documentation.
7.4 Jako u všech projektů je nezbytné efektivně uzavírat smlouvy, aby se zajistilo dosažení požadovaných výstupů. Proto má následovat robustní akviziční proces, zejména uzpůsobený na softwarový 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é financování a rozšiřování nejzazších termínů, ukazuje se, že opatrný a vhodný management může zajistit, aby se požadovaný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.
48
ČOS 051665 1. vydání
PŘÍLOHY ANNEXEX
49
ČOS 051665 1. vydání Příloha A
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 softwarespecific 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ů. 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. Míra času mezi pozorovanými poruchami systému. MTTF=1,500 znamená, že porucha 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 pravděpodobnost systému být schopen poskytovat jednotlivé služební požadavky?
ROCOF Intenzita výskytu poruch MTTF Střední doba do poruchy
Metric
Description
POFOD Measure of the likelihood that the system will Probability of fail when a service request is made. POFOD = failure on demand 0.001 means that 1 out of 1,000 service requests may result in failure. The number of failures and service requests are counted. ROCOF Measure of the occurrence frequency of inRate of occurrence correct behaviour. ROCOF = 0.02 means that of failure 2 failures may occur in 100 operational time units. The number of failures is counted within the total elapsed time. MTTF Measure of the time between observed system Mean time to failures. MTTF = 1,500 means that a failure failure may happen every 1,500 operational time units. Note that MTTF and ROCOF are reciprocals of each other.
50
Kolik poruch se pravděpodobně objeví za nějakou specifikovanou časovou periodu? Jak je velký časový interval mezi poruchovými událostmi? Následky poruchy nejsou brány v úvahu.
Focus What is the system's likelihood of being able to service a discrete service request? How many failures are likely to occur within some specified time period? How large is the time interval between failure events? The consequences of failure are not considered.
ČOS 051665 1. vydání Příloha B
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í návrhu.
b) Technical Criteria.
kritéria
technického
2. Práce a dodávané produkty:
Proposal
Evaluation
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);
d) seznam smluvních koncových položek (CEIL).
d) Contract End Items List (CEIL).
3. Specifikace požadavků
3. Requirements Specification
4. Zjištění provozních požadavků (SOR)
4. Statement of Operational Requirements (SOR)
5. Třídy IETM
5. IETM Classes
6. Státem poskytnutý materiál
6. Government Furnished Materiel
51
ČOS 051665 1. vydání
Účinnost českého obranného standardu od: 25. února 2014 Opravy: Oprava Účinnost od Opravu zapracoval číslo
Upozornění:
Datum zapracování
Poznámka
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í: Tisk: Distribuce: Vydal:
2014, obsahuje 26 listů Ministerstvo obrany ČR Odbor obranné standardizace Úř OSK SOJ, nám. Svobody 471, 160 01 Praha 6 Úřad pro obrannou standardizaci, katalogizaci a státní ověřování jakosti www.oos.army.cz
NEPRODEJNÉ
52
