====== 4.3.2 Reliability ====== [[dido:public:ra:1.4_req:2_nonfunc: | return to Non-Functional Requirements]] ===== About ===== [[https://www.sebokwiki.org/wiki/Reliability,_Availability,_and_Maintainability#RAM_Considerations_during_Systems_Development]] //**Reliability** is the degree to which a system, product or component performs specified functions under specified conditions for a specified period of time. This characteristic is composed of the following sub-characteristics://(( ISO/IEC 25010, __Reliability__, Accessed 27 July 2020, [[https://iso25000.com/index.php/en/iso-25000-standards/iso-25010/62-reliability]] )) * //**[[dido:public:ra:1.4_req:2_nonfunc:14_reliability:01_matuity | Maturity]]** - Degree to which a system, product or component meets needs for reliability under normal operation.// * //**[[dido:public:ra:1.4_req:2_nonfunc:14_reliability:02_availability | Availability]]** - Degree to which a system, product or component is operational and accessible when required for use.// * //**[[dido:public:ra:1.4_req:2_nonfunc:14_reliability:04_faulttolerance| Fault tolerance]]** - Degree to which a system, product or component operates as intended despite the presence of hardware or software faults.// * //**[[dido:public:ra:1.4_req:2_nonfunc:14_reliability:12_recoverability|Recoverability]]** - Degree to which, in the event of an interruption or a failure, a product or system can recover the data directly affected and re-establish the desired state of the system.// [[dido:public:ra:xapend:xapend.a_glossary:r:ram|Reliability, maintainability, and availability (RAM)]] are three system attributes that are of great interest to systems engineers, logisticians, and users. Collectively, they affect both the utility and the life-cycle costs of a product or system. The origins of contemporary reliability engineering can be traced to World War II. The discipline’s first concerns were electronic and mechanical components (Ebeling, 2010) /* Need to add the reference to this article -- missing */. However, current trends point to a dramatic rise in the number of industrial, military, and consumer products with integrated computing functions. Given the rapidly increasing integration of computers into products and systems used by consumers, industry, governments, and the military, reliability must consider both hardware and software. [[dido:public:ra:xapend:xapend.a_glossary:m:maintainability|Maintainability]] models present some interesting challenges. The time to repair an item is the sum of the time required for evacuation, diagnosis, assembly of resources (parts, bays, tool, and mechanics), repair, inspection, and return. Administrative delay (such as holidays) can also affect repair times. Often these sub-processes have a minimum time to complete that is not zero, resulting in the distribution used to model maintainability having a threshold parameter. A threshold parameter is defined as the minimum probable time to repair. Estimation of maintainability can be further complicated by queuing effects, resulting in times to repair that are not independent. This dependency frequently makes the analytical solution of problems involving maintainability intractable and promotes the use of simulation to support analysis. ===== DDS Specifics ===== [[dido:public:ra:1.4_req:2_nonfunc:14_reliability | return to Top]] : To be added/expanded in future revisions of the DIDO RA /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- /* To add a discussion page to this page, comment out the line that says ~~DISCUSSION:off~~ */ ~~DISCUSSION:on|Outstanding Issues~~ ~~DISCUSSION:off~~