dido:public:ra:1.4_req:2_nonfunc:14_reliability
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:1.4_req:2_nonfunc:14_reliability [2020/11/10 21:34] nick ↷ Links adapted because of a move operation |
dido:public:ra:1.4_req:2_nonfunc:14_reliability [2021/08/09 14:34] (current) murphy |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 4.2.2 Reliability ====== | + | ====== 4.3.2 Reliability ====== |
| [[dido:public:ra:1.4_req:2_nonfunc: | return to Non-Functional Requirements]] | [[dido:public:ra:1.4_req:2_nonfunc: | return to Non-Functional Requirements]] | ||
| - | |||
| - | * **<color darkblue><todo @nick>Char's review done - a few comments within</todo></color>** | ||
| - | * **<color #FF0000><todo @DDSFmember>Please Review</todo></color>** | ||
| ===== About ===== | ===== About ===== | ||
| Line 17: | Line 14: | ||
| * //**[[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: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.// | ||
| - | [[ddsf:private:cookbook:06_append: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: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. |
| - | 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. | + | [[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. | 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 ===== | ===== DDS Specifics ===== | ||
| - | [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:14_reliability| return to Top]] | + | [[dido:public:ra:1.4_req:2_nonfunc:14_reliability | return to Top]] |
| + | |||
| + | : <wrap hi><color red> To be added/expanded in future revisions of the DIDO RA </color></wrap> | ||
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||
dido/public/ra/1.4_req/2_nonfunc/14_reliability.1605062069.txt.gz · Last modified: 2020/11/10 21:34 by nick
