睿地可靠度論壇(TW-REDI Forum)

 找回密碼
 立即註冊
查看: 8771|回復: 0
打印 上一主題 下一主題

A.2.4 軟體可靠度工程 [複製鏈接]

Rank: 7Rank: 7Rank: 7

UID
5
帖子
1525
主題
739
記錄
1
分享
0
日誌
213
閱讀權限
100
最後登錄
2024-12-11
在線時間
2326 小時
跳轉到指定樓層
樓主
發表於 2013-12-30 09:16:05 |只看該作者 |倒序瀏覽
A.2.4 Software Reliability Engineering (SRE)
A.2.4.1 Description and Purpose
The purpose of SRE is to predict the reliabilitly of software through statistical methods.  The problem is that, in principle, software does not fail, but delivers deterministically correct or erroneous results for a given fixed input.  The underlying model therefore does not assume that the software acts randomly, but that the system configuration and the operationn profile (e.g., input data) can be viewed as a random environment.

A.2.4.2 Application
SRE can either be applied during testing as a means to decide when to stop testing (assuming that an acceptance criterion has been set) or to predict the reliability in the field.  Usually the data are sampled in groups, e.g., as number of failures per cumulated execution time, as it is very hard to get real inter-arrival times for failures.  

In most applicatoins it is assumed that software failure can be described as a non-homogeneous Poisson process.  This means that software failures occur at statistically independent and expoenentially distributed inter-arrival times, but that the failure intensity varies with time.  Generally, a decreasing failure intensity is assumed, which means that the models assume that errors, once they are found, are-effectively removed, at least without introduction of new bugs.  The major objective of SRE is to determine the form of the failure intensity function and to estimate its parameters from observed failure data.  Once the failure intensity function and to has been determined, several reliability measures can be derived such as:
- cumulative number of failures;
- number of remaining failures;
- time to next failure;
- residual test time (until acceptance); and
- maximum number of failure (with respect to the lifetime)

Other approaches take into account the software architecture as funcational modules and model first their interaction and execution behaviour, e.g., by Markov processes.  In a second step, data are sampled and evaluated for the modules.  

A.2.4.3 Key Elements
- Define the relevant reliability measures and objectives.  
- Define the software reliabilty model to be used.  
- Sample failure data.  
- Validate the model.  
- Predict reliability measures from the data.  

A.2.4.4 Benefits
- Software can be included in reliability predictions.
- Objective test end criteria can be defined and controlled.  

A.2.4.5 Limitations
- Collection of software reliability data can be difficult.  The results are only as good as the data collected.  
- There exist a variety of approaches, but no standard has yet been set for the approach or for the failure intensity functions.  There is a temptation to select the model to which the data fit best instead of selecting the model as a priori.  
- The theoretical foundation for the non-homogeneous Poisson process is much weaker than in the case of hardware reliability prediction.  


您需要登錄後才可以回帖 登錄 | 立即註冊

Archiver|手機版|睿地可靠度論壇(TW-REDI Forum)   

GMT+8, 2024-12-13 08:54 , Processed in 0.030975 second(s), 9 queries .

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回頂部