دانلود رایگان مقاله مقایسه مدل های ارزیابی قابلیت اتکای نرم افزار

خلاصه

          قابلیت اتکا و اطمینان  یکی از مهمترین جنبه های کیفی هر نرم افزار به شمار میرود و تخمین قابلیت اتکای نرم افزار یکی از مسائل دشواری است که نیازمند دقت بالایی در مواجهه با آن است. با این وجود، برای مدیریت کیفیت نرم افزار و انجام رویه های متداول در یک سازمان، مهم است تا جای ممکن به درک صحیحی از قابلیت اتکای دقیق برسیم. در مقاله پیش رو چندین اصل و تکنیک برای تخمین قابلیت اتکا در نرم افزارها ارائه شده است، که از تعریف مفاهیم ضمنی تعیین کننده کیفیت نرم افزار کار را آغاز میکند. تخمین بخشی از نرم افزار نیز مد نظر قرار گرفته است. هدف مفروض تخمین قابلیت اتکا تشکیل یافته از آنالیز ریسک و قابلیت اتکای سیستم های مبتنی بر نرم افزار است. چنین انتظار میرود یک نظر مستند از متخصصان در رابطه با نرم افزار وجود داشته باشد و بروز رسانی بر تخمین قابلیت اتکای تعریف شده با اطلاعات موجود در رکوردهای داده عملیاتی صورت گیرد.

1. معرفی

         اگر یک ایراد در قسمت سخت افزاری نیازمند زمان برای تعویض عناصر مشکل آفرین باشد، همین مساله را نمیتوان به حوزه نرم افزاری بسط داد، ایراد بوجود آمده در این حوزه نشان دهنده یک خطای پیشین در برنامه است. ایرادهای نرم افزاری به عنوان رویدادهای تصادفی در نظر گرفته میشوند که در یک محور زمانی روی میدهند، آن هم به خاطر کمبود قطعیت در مورد زمان دقیق رخ دادنشان، همین دلیل ارجاعی به مفهوم قابلیت اتکا است، نه کیفیت نرم افزار.

          یک سیستم نرم افزاری از این نقطه نظر شبیه به بروز خطا در سیستم سخت افزاری به همراه روند بازیابی بوده و شاخص های قابلیت اتکای مشابهی نیز با آن دارد.

           با استناد به استاندارد IEEE (ANSI) 982.2 سال 1988 (IEEE 1988)، عناصر الزامی در تعریف نرم افزار از قرار زیر هستند:

خطا. یک خطای انسانی که باعث تولید برنامه نادرست میشود. برای مثال حذف یک وظیفه  حیاتی؛

باگ یا ایراد. این مورد نتیجه خطای انسانی است و نشان دهنده حادثه داخلی است که باعث میشود سیستم مورد انتظار عمل نکند.

در زبان حال حاضر، واژه خطا هم برای اشتباه کردن (ایراد )، و هم برای تاثیر مستقیم اش در برنامه (خطا یا باگ ) به کار میرود.

2. معیار برای آنالیز مدل های قابلیت اتکای نرم افزار

          اکثر مدلهای کنونی ارتقای قابلیت اتکای نرم افزار زمان را به عنوان یک متغیر پیوسته در نظر میگیرند (چه زمان تقویمی، ساعت یا زمان اجرا). با این وجود سیستم هایی وجود دارند که مانند سیستم های پرداشگر تراکنش ها، که در آنها قابلیت اتکا باید متناسب با تراکنش های موفق انجام شده در نظر گرفته شود. علاوه بر این، سیستم های دیگری هم هستند که مانند نرم افزار کنترل موشکی (سفینه های فضایی) که در آن دسته قابلیت اتکا میتواند تعداد دفعات موفق پرتاب موشک باشد. سیستم های از این دست نیازمند رویکرد محتاطانه ای در قبال زمان هستند، به عبارت دیگر تعداد دفعات اجرای نرم افزار.

            شاخص «پوشش کد» (بخش واقعی از کد که تست شده است) در فاز تست کردن میتواند تخمین قابلیت اتکای نرم افزار را به طرز چشم گیری افزایش دهد: تست کردن میتواند به اشباع برسد که در این شرایط بخش های جدید کد تست نمیشوند. پس تخمین قابلیت اتکا که بیشتر بر زمان اجرا متکی است میتواند قابلیت اتکای برنامه را بیش از حد واقعی تخمین بزند.

            راه های متعددی برای ارزیابی ارزش یک مدل نرم افزاری وجود دارد:

اعتبار قابل پیش بینی. این مورد نشان دهنده ظرفیت مدل برای پیش بینی است، با توجه به رفتار شکست آتی، که هم میتواند در طول فاز تست کردن و یا فاز اجرا صورت گیرد. پیش بینی های بدست آمده از این رفتار شکست و فاز متناسب پیشین حاصل میشوند. این جنبه را میتوان به بخش های بیشتری نیز تقسیم کرد:

دقت (سطح دقت) که از شباهت محتاطانه اندازه گیری میشود

انحراف  (شیب)، که از روی U-دیاگرام اندازه گیری میشود

گرایش ، یا تغییر سیستماتیک شیب از مقادیر کوچک به سمت مقادیر بزرگ در زمان شکست، که از روی Y-گرافیک اندازه گیری میشود

نویز، از روی تغییر نسبی روی داده در نرخ پیش بینی خطا حاصل میشود

توانایی. ظرفیت مدل برای تخمین با دقت مطلوب که مدیران، مهندسان و کاربران نرم افزار برای برنامه ریزی و مدیریت پروژه های توسعه نرم افزار به آن نیاز دارند، یا کنترل تغییرات روی داده در سیستم های عملیاتی نرم افزار. این ابعاد شامل قابلیت اتکای کنونی، موعد پیش بینی شده برای رسیدن به قابلیت اتکای هدف و همچنین هزینه رسیدن به هدف میشوند.

کیفیت برانگاشت. اگر یک برانگاشت (فرضیه) ایجاد شده توسط یک مدل میتواند مورد تست قرار گیرد، پس این جنبه به میزانی اشاره دارد که مدل توسط داده واقعی مقبول بوده است: هر چند، تست کردن برانگاشت ممکن نیست، جنبه ها به معقول بودن از نظر جامعیت منطقی اشاره دارند و تجربه بدست آمده در مهندسی نرم افزار. همچنین، شفافیت و توصیف یک برانگاشت مدل باید مورد بررسی بیشتر قرار گیرد.

Abstract

         The reliability of the software represents one of the most important attributes of software quality, and the estimation of the reliability of the software is a problem hard to solve with accuracy. Nevertheless, in order to manage the quality of the software and of the standard practices in an organization, it is important to achieve an estimation of the reliability as accurate as possible. In the present work there are described the principles and techniques which underlie the estimation of the reliability of the software, starting from the definition of the concepts which express the attributes of software quality. It is taken into account the issue of the estimation of a software part. The presumed objective of the estimation of the reliability consists in the analysis of the risk and of the reliability of the software-based systems. Supposedly, a documented opinion of the expert exists regarding the reliability of the software and an update of the defined estimation of the reliability is tried with the information contained in the records of the operational data.

1. Introduction

          If the failure of a hardware system is owing to the alteration in time of material properties, the wear doesn’t act in the software domain, the failure consisting here in the highlight of a latent error contained in the program (Mihalache, 1995). The failures of the software are treated as random events which are produced throughout a time axis, due to the lack of certainty regarding the exact time of their manifestation, reason for which we refer to the reliability, not the quality, of the software.

          A software system is thus similar from the point of view of the failure process with a hardware system with restoration and it is described by the same ensemble of reliability indicators as the latter.

According to IEEE (ANSI) 982.2 from 1988,(IEEE 1988) standard, the essential elements in defining the software are the following:

 The error. It is a human mistake which has as a result an incorrect program. E.g., the omission of a crucial requirement(task);

 The disorder (fault or bug). This is the result of a human error and represents the internal accident which causes the system not to work as expected.

In the current expression (language), the term error is used both for the act of making a mistake (error), and also for its direct manifestation in the program (fault or bug).

2. Criteria for analysis of software reliability models

          Most of the existing models of software reliability enhancement treat time as a continuous variable (either calendar time, hour time or execution time). Nonetheless, there are systems, like stock transaction processing systems, in which reliability should be treated in terms of transactions handled successfully. More than that, there are other systems, like the command software of missiles (space shuttles), in which it is more natural to measure reliability according with the number of launches of missiles (space shuttles) successfully completed. Systems like these require a discreet conception of time, in terms of the number of runs of the software.

           The “code coverage” indicator (the actual proportion of code covered by testing) within testing can significantly affect the software reliability estimation: testing may reach saturation, in which case new parts of code don’t actually get to be tested. Thus, the reliability estimations which rely completely on execution time/execution can overestimate the reliability of the program.

            There are several ways that can be used to evaluate the value of a model (Imol 1983):

 Predictive validity. This one represents the capacity of a model to make predictions regarding the future failure behavior, throughout either the testing phase or the operation phase, predictions obtained from the current failure behavior and from the one in the past in the respective phase. This aspect can be, further on, divided in:

o Accuracy ( precision level), measured by prudential likelihood

o Inclination, measured by the U-diagram

o Tendency, or the systematic change of the inclination, from small values towards big values of the failure time, attribute measured by the Y-graphic

o Noise, measured by the relative change occurred in the forecast rate of failure

 Capability. The capacity of the model to estimate with sizes of a satisfactory precision that the managers, engineers and the users of the software need in planning and administrating the software development projects, or in the control of the changes occurred in the operational software systems. These sizes include, e.g., the current reliability, the anticipated date for achieving the reliability objective, and also the necessary cost to achieve that objective.

خلاصه

1. معرفی

2. معیار برای آنالیز مدل های قابلیت اتکای نرم افزار

2.2. چارت-U

2.2. چارت-Y

2.3 فاکتور بایس

2.4. شباهت محتاطانه و نرخ شباهت محتاطانه

3. نتیجه گیری

منابع

Abstract

1. Introduction

2. Criteria for analysis of software reliability models

2.1 U-chart

2.2 Y-chart

2.3 Bayes factor

2.4. The prudential likelihood and the prudential likelihood ratio

3. Conclusions

References