Software Fault Tolerance: Achievement and Assessment Strategies

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

The first ESPRIT programme contained several ambitious projects. of which REQUEST. with its wide brief covering all issues of assessment of quality and reliability of software process and product. was one. Within REQUEST. the research described in this volume. concerning those special problems of software that is required to have extremely high reliability. was particularly difficult and ambitious. The problems of software reliability are essentially twofold. On the one hand there is a concern with methods for achieving adequate reliability. on the other hand there is a need to evaluate what has actually been achieved in a particular case. Naturally. far more effort has been spent over the years on the former problem; indeed. there is a sense in which all of conventional software engineering can be seen as a response to this problem. However. it is becoming clearer than ever that we can only claim to have a truly sCientific approach. and so justify the description software engineering. when we are able to measure the attributes of process and product. It is still common to find software development methods recommended to users on purely anecdotal grounds. This is not good enough. Rational choices between rival approaches can only be made on the basis of quantified costs and benefits. Even more worrying is the tendency to argue that a software product can be depended upon merely because it has been developed by honest men using such anecdotal 'good practice'.