اندازه: px

شروع نمایش از صفحه:

رونوشت

1 # 06، ژوئن 2016 بررسی UDC بسته های نرم افزاری برای محاسبات قابلیت اطمینان سیستم های فنیمقدمه Shalamov A.V.، دانشجوی کارشناسی ارشد روسیه، مسکو، MSTU. N.E. Bauman، گروه "طراحی و فناوری ساخت تجهیزات الکترونیکی" سرپرست علمی: Solovyov V.A.، دانشیار روسیه، مسکو، MSTU به نام. N.E. Bauman، بخش "طراحی و فناوری ساخت تجهیزات الکترونیکی" در حال حاضر، راه حل های بسیاری از تولیدات خارجی و روسی در بازار برای سیستم های محاسبه قابلیت اطمینان وجود دارد. به محبوب ترین ها سیستم های خارجیمحاسبات قابلیت اطمینان شامل موارد زیر است: Relex، Risk Spectrum، A.L.D.، ISOgraph. از سیستم های روسیسیستم های زیر را می توان متمایز کرد: Arbiter، ASM، ASONIKA-K. برخی از سیستم های فوق، علاوه بر ابزارهایی برای محاسبه پارامترهای قابلیت اطمینان، امکان حل طیف گسترده ای از مسائل مهندسی مرتبط را فراهم می کنند. در مرحله بعد، بسته های نرم افزاری (PC) داده شده را از نقطه نظر استفاده از آنها برای محاسبه قابلیت اطمینان ERA با جزئیات بیشتری در نظر خواهیم گرفت. PC Relex و Risk Spectrum PC Relex و Risk Spectrum به شما این امکان را می دهد که تجزیه و تحلیل منطقی و احتمالی قابلیت اطمینان و ایمنی سیستم های فنی را انجام دهید، به عنوان مثال، قابلیت اطمینان سیستم های مدرن را محاسبه کنید. سیستم های خودکارمدیریت فن آوری، بهینه سازی ریسک فن آوری و تعیین پارامترهای بهینه سیستم تعمیر و نگهداری برای اشیاء بالقوه خطرناک. نرم افزار Risk Spectrum عمدتاً در تحلیل ایمنی احتمالی تأسیسات انرژی هسته ای در مرحله طراحی استفاده شد. مجموعه Spectrum در بیش از 50 درصد از نیروگاه های هسته ای جهان استفاده می شود و در لیست ابزارهای نرم افزاری تایید شده توسط شورای صدور گواهینامه گنجانده شده است.

2 ابزار نرم افزاری Gosatomnadzor روسیه در سال 2003 PC Relex و Risk Spectrum را می توان برای محاسبه قابلیت اطمینان نه تنها سیستم های کنترلی یا تکنولوژیکی، بلکه همچنین محصولات ابزارسازی در حمل و نقل و فناوری دفاعی مورد استفاده قرار داد. مدل‌سازی و محاسبه شاخص‌های قابلیت اطمینان و ایمنی سیستم‌های فنی، که به طور گسترده در اروپا و ایالات متحده استفاده می‌شود، مبتنی بر روش‌های منطقی-احتمالی است که از درخت‌های رویداد و درختان شکست به عنوان ابزاری برای ساخت مدل‌های گرافیکی قابلیت اطمینان استفاده می‌کنند (شکل 1). استفاده از دستگاه منطق ریاضی به ما اجازه می دهد تا شرایط عملیاتی سیستم های فنی پیچیده را رسمی کنیم و قابلیت اطمینان آنها را محاسبه کنیم. اگر بتوان استدلال کرد که سیستم در صورتی قابل اجرا است که عناصر A و B آن قابل اجرا باشند، می‌توان نتیجه گرفت که عملکرد سیستم (رویداد C) و عملکرد عناصر A و B (رویداد A و رویداد B) به هم مرتبط هستند. با معادله عملکرد منطقی: C = A B. در اینجا از نماد برای نمایش عملیات منطقی AND استفاده می شود. درخت رویداد به عنوان یک مدل گرافیکی درک می شود که منطق توسعه انواع مختلف فرآیند اضطراری ناشی از رویداد آغازگر مورد نظر را توصیف می کند. درخت خطا یک مدل گرافیکی است که منطق رویدادهای منجر به خرابی سیستم را به دلیل ترکیبات مختلف خرابی تجهیزات و خطاهای پرسنل نمایش می دهد. برنج. 1. درخت خطا در بولتن علمی و فنی جوانان Relex PC FS، ISSN

3 درخت خطا شامل عناصر گرافیکی است که برای نمایش رویدادهای تصادفی اولیه (رویدادهای اساسی) و عملگرهای منطقی خدمت می کنند. هر عملگر منطقی جبر بولی مربوط به یک عنصر گرافیکی خاص است که این امکان را فراهم می کند تا رویدادهای پیچیده را به موارد ساده تر (پایه یا ابتدایی) تجزیه کنیم. ماژول درخت خطای Relex PC از عملگرهای پویا-منطقی استفاده می کند که وابستگی رویدادها، روابط زمان بندی و اولویت ها را در نظر می گیرند. این به شما امکان می دهد شاخص های زیر را محاسبه کنید: احتمال شکست، در دسترس نبودن، پارامتر جریان شکست، میانگین تعداد خرابی ها. مقادیر اندیکاتورها هم برای رویداد راس و هم برای هر میانی محاسبه می شود. برای هر رویداد انتخابی، می‌توانید مجموعه‌هایی از حداقل بخش‌های مربوطه را مشاهده و تجزیه و تحلیل کنید. در رایانه شخصی Risk Spectrum، درخت رویداد به شکل یک جدول حاوی یک خط سرصفحه، یک فیلد حاوی یک نمودار باینری باز و چندین ستون با ویژگی‌های حالت‌های نهایی شی مدل‌سازی شده ارائه می‌شود که در طول پیاده‌سازی محقق می‌شوند. توالی های اضطراری (شکل 2). عنوان ستون 1 جدول نشان دهنده تعیین رویدادهای اولیه است. عناوین ستون های بعدی از چپ به راست حاوی نام و نمادهارویدادهای میانی مربوط به اجرای موفقیت‌آمیز یا ناموفق عملکردهای ایمنی، وضعیت‌های عملیاتی یا ناموفق سیستم‌های ایمنی یا اجزای منفرد (تجهیزات و وسایل فنی) اقدامات صحیح یا اشتباه پرسنل. ستون های مشخص کننده حالت های نهایی (FS) اعداد، نمادها، انواع آنها (به عنوان مثال، FS با آسیب هسته)، احتمالات اجرا، فرمول های منطقی مربوط به این توالی های اضطراری (EA) را نشان می دهد. با کمک AP، گزینه هایی برای توسعه فرآیند اضطراری در درخت رویداد نمایش داده می شود. در این مورد، حادثه به عنوان دنباله ای از رویدادها درک می شود که منجر به وضعیت نهایی مشخصی از یک جسم می شود، از جمله رویداد اولیه حادثه، فعال سازی موفقیت آمیز یا ناموفق سیستم های ایمنی و اقدامات پرسنل در طول توسعه حادثه. بسیاری از شرکت‌های معروف خارجی با رایانه‌های شخصی Relex کار می‌کنند: LG، Boeng، Motorolla، Dell، Cessna، Siemens، Raytheon، HP، Honda، Samsung، CiscoSystems، Nokia، EADS، 3M، NASA، Intel، GM، Kodak، AT&T، Philips. , Pirelli , Quallcomm, Seagete, Emerson. استودیوی قابلیت اطمینان Relex 2007 PC شامل ماژول های تحلیلی مختلفی برای حل طیف گسترده ای از مشکلات است: پیش بینی قابلیت اطمینان، قابلیت نگهداری،

4 تجزیه و تحلیل انواع، پیامدها و بحرانی خرابی ها، تجزیه و تحلیل مارکوف، تجزیه و تحلیل آماری، ارزیابی هزینه عمر مفید تجهیزات، و همچنین فلوچارت های قابلیت اطمینان، درختان خطا/رویداد، سیستم اطلاع رسانی خرابی، تجزیه و تحلیل و اقدامات اصلاحی، سیستم FRACAS (شکست). تجزیه و تحلیل گزارش و سیستم اقدام اصلاحی)، سیستمی برای ارزیابی عوامل انسانی و تجزیه و تحلیل ریسک. برنج. 2. درخت دودویی رویدادها در Spectrum PC ماژول پیش‌بینی قابلیت اطمینان شامل مدل‌هایی برای محاسبه شاخص‌های قابلیت اطمینان عناصر است. این شامل یک پایگاه داده گسترده شامل ویژگی های طبقه بندی عناصر و ویژگی های قابلیت اطمینان است. محاسبات مطابق با استانداردهای زیر انجام می شود: MIL-HDBK-217، Telcordia (Bellcore)، TR-332، Prism، ​​NSWC-98/LE1، CNET93، HRD5، GJB299. ماژول تجزیه و تحلیل قابلیت نگهداری مفاد استاندارد برای مطالعه قابلیت نگهداری سیستم های MIL-HDBK-472 را اجرا می کند. مشکلات پیش بینی تعمیر و نگهداری پیشگیرانه حل شده است. ماژول تجزیه و تحلیل انواع، پیامدها و بحرانی بودن خرابی ها مطابق با استانداردهای MIL-STD-1629، SAE ARP 5580 و غیره است. خرابی های خطرناک بر اساس اولویت های ریسک رتبه بندی و ارزیابی می شوند. ماژول Reliability Block Diagram (RBD) برای تجزیه و تحلیل سیستم های پیچیده اضافی استفاده می شود. شامل هر دو روش تحلیلی و شبیه سازی مونت کارلو است. ماژول درختان خطا/ درختان رویداد به شما امکان می دهد رویه هایی را برای تجزیه و تحلیل قیاسی و استقرایی توسعه خرابی ها پیاده سازی کنید، بولتن علمی و فنی جوانان مجلس فدرال، ISSN

5 رویداد در سیستم برای تجزیه و تحلیل قابلیت اطمینان و ایمنی استفاده می شود. شامل طیف گسترده ای از رئوس منطقی-عملکردی است. ماژول Relex PC Markov Modeling به شما امکان می دهد از فرآیندهایی استفاده کنید که در مدل سازی و تجزیه و تحلیل قابلیت اطمینان سیستم استفاده می شوند. مدل‌های توسعه‌یافته با کمک این دستگاه، پویا هستند و شرایط موقت لازم و سایر ویژگی‌ها و وابستگی‌ها را منعکس می‌کنند که مسیر انتقال سیستم را در فضای حالت‌های احتمالی ایجاد شده توسط خرابی‌ها و بازیابی عناصر مشخص می‌کند. ماژول Relex Markov PC فرآیندهای مارکوف را با مجموعه ای از حالت های گسسته و زمان پیوسته با در نظر گرفتن ویژگی های زیر عملکرد و افزونگی سیستم ها اجرا می کند: انواع ناسازگار خرابی عناصر، توالی خرابی ها، تغییر در میزان خرابی عناصر. بسته به رویدادهایی که قبلاً رخ داده است (به ویژه، میزان بار روی ذخیره)، تعداد تیم های بازسازی (محدود/نامحدود)، ترتیب بازسازی، محدودیت در قطعات یدکی، بازده عملیاتی مختلف در حالت های مختلف سیستم و درآمد (زیان) برای انتقال به ایالات. شاخص های محاسبه شده: احتمال هر حالت، احتمال عملکرد بدون مشکل(شکست) در یک بازه زمانی معین. ماژول تجزیه و تحلیل آماری "Weibull" برای پردازش نتایج آزمون و عملیات طراحی شده است. برای توصیف خرابی‌های فاجعه‌بار در منحنی نرخ شکست به شکل وان حمام، توزیع‌های نرمال، لگ نرمال و Weibull به طور گسترده استفاده می‌شوند. به عنوان مثال، توزیع Weibull که توزیع حداقل مقادیر است، اغلب برای پیش‌بینی احتمال عملیات بدون خرابی و میانگین زمان بین خرابی‌ها برای یک زمان عملیاتی معین از یک سیستم فنی پیچیده در حال طراحی استفاده می‌شود. توزیع های Lognormal و Weibull شکست های مشخصه دوره پیری را به همان اندازه به خوبی توصیف می کنند. ماژول تجزیه و تحلیل آماری Weibull از انواع مختلفی از توزیع ها از جمله نرمال، ویبول، لگ نرمال، یکنواخت، نمایی، گامبل، ریلی، دوجمله ای و غیره استفاده می کند. ارائه و تجزیه و تحلیل داده ها برای کلاس های منتخب توزیع پارامتری با استفاده از روش "کاغذ احتمال" انجام می شود. بر روی آن، توزیع تحلیل شده با یک خط مستقیم نشان داده می شود که وضوح را ارائه می دهد و به شما امکان می دهد به طور طبیعی تمام روش های تحلیل رگرسیون را اعمال کنید، به ویژه، کفایت مدل و اهمیت ضرایب رگرسیون (تحلیل فیشر) را بررسی کنید. برای تخمین پارامترهای توزیع پیشنهاد شده است

6 مجموعه بزرگی از روش ها، به عنوان مثال، روش های Hazen، Benard و اصلاحات آنها، تخمین دوجمله ای، روش میانگین ها، روش حداکثر درستنمایی و اصلاح آن. با استفاده از ماژول محاسبه اقتصادی، هزینه عمر سرویس در تمام مراحل ایجاد، بهره برداری و دفع سیستم ارزیابی می شود. PC ASM معروف ترین رایانه های شخصی خانگی مجموعه نرم افزاری برای مدل سازی خودکار ساختاری-منطقی (PC ASM) است. مبنای نظری روش کلی منطقی-احتمالی است تجزیه و تحلیل سیستم، که تمامی قابلیت های دستگاه اصلی مدل سازی جبر منطق را در پایه عملیات «AND»، «OR»، «NOT» پیاده سازی می کند. شکل نمایش ساختار اولیه سیستم یک نمودار یکپارچگی عملکردی است که به شما امکان می دهد تقریباً همه انواع شناخته شده مدل های ساختاری سیستم ها را نمایش دهید. این مجموعه به طور خودکار مدل‌های تحلیلی طراحی از قابلیت اطمینان و ایمنی سیستم را تولید می‌کند و احتمال عملکرد بدون خرابی، میانگین زمان تا شکست، فاکتور در دسترس بودن، میانگین زمان بین خرابی‌ها، میانگین زمان بازیابی، احتمال خرابی سیستم در حال بازیابی، احتمال خرابی را محاسبه می‌کند. آمادگی یک سیستم مختلط و همچنین اهمیت و سهم عناصر در شاخص های مختلف قابلیت اطمینان سیستم به عنوان یک کل. PC ASM همچنین به شما این امکان را می دهد که به طور خودکار کوتاه ترین مسیرها را برای عملکرد موفقیت آمیز، بخش های حداقل خرابی و ترکیب آنها تعیین کنید. مزایای اصلی سیستم های روسی نسبت به خارجی ها هزینه کمتر اجرا و پشتیبانی، عدم وابستگی تکنولوژیکی و راحتی آموزش پرسنل است. PC ASONIKA-K همچنین سیستم ASONIKA-K در بازار روسیه ارائه شده است، یک ابزار نرم افزاری برای حل مشکلات تجزیه و تحلیل و اطمینان از قابلیت اطمینان در داخل طراحی به کمک کامپیوتر REA. از نظر قابلیت ها، زیرسیستم ASONIKA-K دست کمی از رایانه های شخصی A.L.D ندارد. گروه، رلکس، ایزوگراف و ... مزیت آن قابلیت استفاده از پایه المان آماده تولید این کشور و همچنین استانداردهای روسیه در هنگام محاسبه است. مطابق با الزامات مجموعه استانداردهای نظامی "Moroz-6" برای تجهیزات الکترونیکی برای استفاده حیاتی و استاندارد ایالات متحده MIL-HDBK-217 و استاندارد چینی GJB/z 299B. ASONIKA-K یک ابزار نرم افزاری است که در فناوری مشتری-سرور ایجاد شده است. پایگاه داده سرور رایانه شخصی حاوی بولتن علمی و فنی جوانان FS، ISSN است

7 اطلاعات به روز شده مداوم در مورد قابلیت اطمینان محصولات الکترونیکی داخلی و خارجی، ساخته شده بر اساس اصول منحصر به فردی که به طور قابل توجهی کار مدیریت آن را تسهیل می کند، از جمله: ویرایش داده ها در مورد قابلیت اطمینان قطعات الکترونیکی، ویرایش مدل های ریاضی قطعات الکترونیکی، افزودن کلاس های جدید قطعات الکترونیکی بسته نرم افزاری ASONIKA-K شامل زیرسیستم های زیر است: سیستمی برای محاسبه ویژگی های قابلیت اطمینان قطعات، سیستمی برای محاسبه شاخص های قابلیت اطمینان محصول، سیستم تجزیه و تحلیل نتایج، سیستم بایگانی پروژه، سیستم کمکییک سیستم نگهداری پایگاه داده، یک سیستم مدیریت کاربر، یک سیستم برای تجزیه و تحلیل و حسابداری برای تأثیر عوامل خارجی بر قابلیت اطمینان، یک سیستم اطلاعاتی و مرجع بر روی ویژگی های قابلیت اطمینان اجزای فناوری پیچیده کامپیوتری مدرن (SVT) و ERI. پایگاه داده بخش مشتری رایانه شخصی حاوی اطلاعاتی در مورد تجهیزات الکترونیکی طراحی شده است. برنج. 3. تجزیه و تحلیل افزونگی در کامپیوتر ASONIKA-K این سازماندهی بخش مشتری امکان انجام محاسبات REA را به صورت موازی از چندین ایستگاه کاری فراهم می کند. بخش مشتری برنامه دارای یک پس پردازشگر گرافیکی و رابط با سیستم هایی برای مدل سازی فرآیندهای فیزیکی و طراحی ساختاری، از جمله ASONIKA-T، P-CAD 2001، ASONIKA-M و غیره است. هسته ریاضی رایانه شخصی شامل یک مدل قابلیت اطمینان است.

8 توزیع نمایی و DN و می توان آن را با هر مدل قابلیت اطمینان دیگری تطبیق داد. این امکان را به شما می دهد تا REA حاوی حداکثر چهار سطح سلسله مراتبی تفکیک و داشتن انواع مختلف افزونگی را محاسبه کنید. نتایج محاسبات را می توان هم به صورت متنی و هم به صورت گرافیکی ارائه کرد. PC ASONIKA-K به شما امکان می دهد انواع زیر را تجزیه و تحلیل محاسبات قابلیت اطمینان انجام دهید: تجزیه و تحلیل نتایج محاسبات قابلیت اطمینان تجهیزات الکترونیکی، که SRN آن یک اتصال دلخواه اجزای سازنده (شبیه درخت، سلسله مراتبی) و تجزیه و تحلیل نتایج محاسبه قطعات با اتصال سریال. استفاده از رایانه شخصی ASONIKA-K امکان افزایش قابلیت اطمینان تجهیزات الکترونیکی توسط قطعات اضافی آن را فراهم می کند. شکل 3 مقادیر احتمال عملیات بدون خرابی، ضریب در دسترس بودن و ضریب آمادگی عملیاتی کل تاسیسات را در کل نشان می دهد. خرابی قطعات ناگهانی است و نشان دهنده رویدادهای مستقل است، زمان شکست است متغیر تصادفی، بر اساس یک قانون نمایی با نرخ شکست ثابت λ توزیع شده است. عملکرد و چگالی توزیع زمان بین خرابی ها و همچنین وابستگی میزان خرابی تجهیزات الکترونیکی طراحی شده با استفاده از تحلیل گرافیکی نشان داده شده است. رایانه شخصی به شما امکان می دهد با استفاده از محاسبات قابلیت اطمینان را انجام دهید انواع مختلفافزونگی اجزاء: آماده به کار کشویی، آماده به کار داغ و بدون افزونگی، و همچنین راه هایی برای نظارت بر عملکرد آنها (پیوسته / دوره ای) ارائه می دهد. در آینده، قرار است دو ماژول دیگر به رایانه شخصی اضافه شود: یک سیستم برای حسابداری تأثیر عوامل خارجی بر ویژگی های قابلیت اطمینان و یک سیستم اطلاعاتی و مرجع برای ویژگی های قابلیت اطمینان. پایه عنصر. نتیجه‌گیری PC Relex، Risk Spectrum و ASM کلاسی از مدل‌ها را برای ارزیابی شاخص‌های قابلیت اطمینان سیستم‌های فنی مدل‌سازی منطقی-احتمالی پیاده‌سازی می‌کنند. می توان آن را یک کلاس از مدل های آماری نامید، زیرا آنها به فرد اجازه می دهند تا شاخص های قابلیت اطمینان، ایمنی و کارایی سیستم ها را در یک نقطه زمانی دلخواه محاسبه کند، بسته به مجموعه های احتمالی حالت های عملیاتی و غیرعملکردی عناصر سیستم. ماژول های کامپیوتر شخصی A.L.D. گروه (فرمانده رم)، رلکس، ایزوگراف برای محاسبه خودکار قابلیت اطمینان تجهیزات الکترونیکی داخلی فقط بر اساس تجهیزات الکترونیکی وارداتی قابل استفاده است که قابلیت اطمینان آنها با استفاده از کتاب های مرجع خارجی مختلف ارزیابی می شود. بولتن علمی و فنی جوانان FS، ISSN

9 استفاده از رایانه های شخصی خارجی مستلزم آن است که کاربران در زمینه آمار ریاضی و کاربرد آن در مسائل تئوری قابلیت اطمینان بسیار آموزش دیده باشند. رایانه های شخصی روسی از نظر قابلیت ها نسبت به رایانه های شخصی خارجی کم نیستند و می توان آنها را برای محاسبه قابلیت اطمینان تجهیزات الکترونیکی داخلی بر اساس تجهیزات الکترونیکی وارداتی و داخلی توصیه کرد. مزیت اصلی توانایی انجام محاسبات قابلیت اطمینان با استفاده از پایگاه های داخلیاجزا و استانداردها مراجع Stroganov A.V., Zhadnov V.K., Polessky S.M. بررسی سیستم های نرم افزاری برای محاسبه قابلیت اطمینان سیستم های فنی پیچیده / ویرایش. D. D. Krasnova. م.: HSE، ص. . Tikhomirov M.V., Shalumov A.S. ارزیابی قابلیت اطمینان و کیفیت RES / ویرایش. M. V. Khokhlova. م.: سولون-پرس، ص. . Shalumov A. S. مزایای AS برای اطمینان از قابلیت اطمینان و کیفیت تجهیزات ASONIKA. M.: MIEM، ص. . Zatylkin A.V., Tankov G.V., Kochegarov I.I. الگوریتمی و نرم افزار برای محاسبه پارامترهای قابلیت اطمینان RES / ویرایش. S. P. Malukva. M.: PSU، ص.

لومایف E.N.، Demyokhin F.V.، A.V. فدوروف، M.I. لبدوا، A.V. Semerikov بررسی مجتمع‌های نرم‌افزاری برای ارزیابی قابلیت اطمینان سیستم‌های خودکار حفاظت در برابر آتش و ایمنی اشیا در حال انجام است

استفاده از راه حل های کیفیت Windchill برای کنترل کیفیت و تجزیه و تحلیل قابلیت اطمینان اطلاعات عمومیدرباره راه حل های با کیفیت Windchill راه حل های با کیفیت Windchill (قبلا Relex) طراحی شده است

2 1. اهداف و مقاصد رشته هدف از مطالعه رشته "قابلیت اطمینان سیستم های فنی و ریسک ساخت انسان" ارائه دانش در زمینه مبانی ارزیابی قابلیت اطمینان سیستم های فنی است. معرفی به

Kulygin V.N.، Zhadnov I.V.، Polessky S.N.، Tsyganov P.A. برنامه محاسبه شاخص های قابلیت اطمینان ماژول های الکترونیکی (سیستم ASONIKA-K-SCH) UDC 621.396.6, 621.8.019.8 برنامه برای محاسبه شاخص های قابلیت اطمینان

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

سخنرانی.1. مفهوم از نمودار ساختاریقابلیت اطمینان تمام اشیاء فنی از عناصر تشکیل شده است. عناصر می توانند به روش های مختلف به صورت فیزیکی به یکدیگر متصل شوند. برای یک تصویر واضح از اتصالات

Tran Dong Hung (ویتنام) (آکادمی خدمات آتش نشانی دولتی وزارت موقعیت های اضطراری روسیه، ایمیل: [ایمیل محافظت شده]) فن آوری برای ارزیابی قابلیت اطمینان سیستم های کنترل خودکار حفاظت در برابر آتش

وزارت بهداشت فدراسیون روسیه دانشکده پزشکی دولتی ولگوگراد بخش سیستم های بیوتکنیکی و فناوری تست وظایف برای تأیید، ایمنی و قابلیت اطمینان

وزارت آموزش و پرورش و علوم مؤسسه آموزشی دولتی روسیه آموزش عالی حرفه ای «دانشگاه دولتی هوافضای سامارا به نام ACADEMICAN S.P. ملکه

Zhadnov V.V., Polessky S.N. ارزیابی طراحی قابلیت اطمینان سیستم های رادیویی ترکیبی روند توسعه فعلی سیستم های رادیویی(RTS) با افزایش عملکردهای انجام شده مشخص می شود

UDC 656.56: 68.3 SHEVCHENKO D. N. کاندیدای علوم فنی، دانشیار (BelSUT) ANALYSIS OF DYNAMIC FAILURE TREE مقاله توسط دکتر علوم فنی، پروفسور ارائه شده است. Bochkov K. A. Introduction Fault Tree Analysis FTA یکی از

1. اهداف و مقاصد رشته هدف از مطالعه رشته «قابلیت اطمینان سیستم‌های فنی و ریسک ساخت بشر»، ارائه دانش در زمینه مبانی ارزیابی قابلیت اطمینان سیستم‌های فنی است. نظریه را معرفی کنید

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

کاربرد مدل سازی سازه خودکار برای محاسبه قابلیت اطمینان طراحی سیستم کنترل خودکار A.S. موژائف، M.S. اسکورتسوف، A.V. Strukov /JSC "SPIK SZMA"، سنت پترزبورگ/ مقدمه محاسبه قابلیت اطمینان

TITLE SHEET این برنامه بر اساس استاندارد آموزشی ایالتی فدرال تدوین شده است آموزش عالی(سطح آموزش پرسنل مجرب) در زمینه آموزش 13/06/01

1 فن آوری مدل سازی ساختاری-منطقی خودکار در محاسبات طراحی قابلیت اطمینان سیستم Nozik A.A. OJSC "شرکت مهندسی تخصصی "SEVZAPMONTAZHAVTOMATIKA" چکیده.

قابلیت اطمینان سازه تئوری و عمل Antonov A.V., Plyaskin A.V., Tataev Kh.N. در مورد محاسبه قابلیت اطمینان سازه های ذخیره شده با در نظر گرفتن پیری عناصر، این مقاله موضوع محاسبه را مورد بحث قرار می دهد.

ALORIMS OF AVOMAZIZED SRUURNO-LOICHESOO MODELING OF Reliability AND SAFETY OF SRUURNO-COMPLEX SYSTEMS Mozhaeva IA, Nozik AA, Strukov AV JSC "SPI SZMA", St. Petersburg, E-mal: fo@Considered Abs

مجتمع نرم افزاری برای مدل سازی خودکار و محاسبه قابلیت اطمینان و ایمنی APCS در مرحله طراحی Nozik A.A., Mozhaev A.S., Potapychev S.N., Skvortsov M.S. انتخاب موجه و مصمم است

وزارت آموزش و پرورش و علوم بودجه ایالتی فدرال فدراسیون روسیه موسسه آموزشیآموزش عالی حرفه ای "پلی تکنیک تحقیقات ملی پرم

این برنامه بر اساس استاندارد آموزشی ایالتی فدرال آموزش عالی (سطح آموزش پرسنل با مهارت بالا) در راستای آموزش 01/06/27 "مدیریت" تدوین شده است.

وزارت حمل و نقل فدراسیون روسیه موسسات آموزشی دولتی فدرال آموزش عالی حرفه ای اولیانوفسک مدرسه عالی هوانوردی غیر نظامی (موسسه)

سخنرانی 3 3.1. مفهوم جریان خرابی ها و ترمیم ها یک شی قابل بازیافت به شیئی گفته می شود که برای آن بازیابی به حالت عملیاتی پس از خرابی در اسناد نظارتی و فنی پیش بینی شده است.

تست مبحث "قابلیت اطمینان IC" #num 1 قابلیت اطمینان عبارت است از: 1) خاصیت یک شی برای حفظ مداوم یک حالت عملیاتی در کل زمان کار. 2) خاصیت یک شی به طور مداوم عملیاتی باقی بماند

ویرایش سوم، تجدید نظر شده و اضافه شده MOSCOW "ENERGY" 1977 این کتاب به مسائل مربوط به قابلیت اطمینان سیستم های خودکار اختصاص دارد. ویژگی های ارزیابی قابلیت اطمینان و محاسبه شرح داده شده است. توجه قابل توجه

1. اهداف تسلط انضباط. اهداف تسلط بر این رشته عبارتند از: آشنایی دانش آموزان با مفاهیم و تعاریف پایه از تئوری قابلیت اطمینان، شاخص های قابلیت اطمینان سیستم های منبع تغذیه (SES)

آژانس فدرال آموزش دانشگاه ایالتی معماری و مهندسی عمران تومسک قابلیت اطمینان سیستم های فنی و ریسک فنی دستورالعمل های کار مستقل دانشجویان

این برنامه بر اساس استاندارد آموزشی ایالتی فدرال آموزش عالی (سطح آموزش پرسنل با مهارت بالا) در جهت آموزش 01.06.01 "ریاضیات" تدوین شده است.

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

K. Kapoor, L. Lamberson RELIBILITY AND SYSTEMS DESIGN ترجمه از انگلیسی توسط E. G. KOVALENKO، ویرایش شده توسط Dr. Tech. علوم، پروفسور I. A. USHAKOVA انتشارات "میر" مسکو 1980 مطالب مقدمه

GOST 24.701-86 گروه P87 استاندارد بین ایالتی سیستم یکپارچهاستانداردهای سیستم های کنترل خودکار قابلیت اطمینان سیستم های کنترل خودکار مفاد اساسی سیستم یکپارچه

مثال. قابلیت اطمینان سیستم منبع تغذیه شکل 1 نمودار عملکردی اولیه (گراف اتصال با چرخه ها) سیستم منبع تغذیه (SES) مشکل شناخته شده 35 Ryabinin را نشان می دهد

دولت فدراسیون روسیه موسسه آموزشی مستقل دولتی فدرال آموزش عالی حرفه ای "دانشگاه ملی تحقیقاتی "مدرسه عالی اقتصاد"

1 سخنرانی 3. مشکلات قابلیت اطمینان منبع تغذیه تئوری قابلیت اطمینان به عنوان مبنای علمی برای فعالیت های آزمایشگاه ها، بخش ها، دفاتر و گروه های قابلیت اطمینان در شرکت ها، در طراحی، تحقیق و توسعه است.

ارزیابی، پیش‌بینی و مدیریت ویژگی‌های منابع تجهیزات NPP Antonov A.V., Dagaev A.V. موسسه انرژی هسته ای اوبنینسک، روسیه در حال حاضر، تعدادی از واحدهای انرژی هسته ای

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

2 PERFORMERS مهندس ارشد نرم افزار LLC "NTC SZMA" متخصص برجسته JSC "SPIK SZMA" برنامه نویس پیشرو LLC "NTC SZMA" Mozhaeva I.A. استروکوف A.V. Kiselev A.V. 3 مطالب مقدمه... 5 1 توضیحات

دولت فدراسیون روسیه موسسه آموزشی مستقل دولتی فدرال آموزش عالی حرفه ای "دانشگاه ملی تحقیقاتی "مدرسه عالی اقتصاد"

وزارت کشاورزی فدراسیون روسیهموسسه آموزشی دولتی فدرال آموزش عالی حرفه ای "دانشگاه دولتی مهندسی کشاورزی مسکو به نام V.P. گوریاچکین" دانشکده آموزش مکاتباتی گروه "تعمیرات ماشین آلات و قابلیت اطمینان"

استفاده از داور رایانه شخصی برای حل مشکلات تجزیه و تحلیل خودکار قابلیت اطمینان سیستم های نصب برق هسته ای کشتی I. V. Kudinovich, N. V. Shklyarov, A. A. Nozikkov, A.V.St.

مدل‌سازی اثرات تصادفی در سیستم‌های مدل‌سازی با استفاده از روش‌های شبیه‌سازی، توجه قابل توجهی به در نظر گرفتن عوامل تصادفی و تأثیرات روی سیستم می‌شود. برای رسمی کردن آنها استفاده می کنیم

سخنرانی. اساسی ویژگی های آماریشاخص‌های قابلیت اطمینان این دستگاه ریاضی تئوری قابلیت اطمینان عمدتاً مبتنی بر روش‌های نظری احتمال است، زیرا خود فرآیند

سخنرانی 6 61 فرآیندهای مارکوف در محاسبه قابلیت اطمینان اشیاء قابل بازیابی غیر زائد ویژگی های اصلی سیستم های قابل بازیابی در مقایسه با غیر قابل بازیابی، بزرگ بودن آنهاست.

وزارت آموزش و پرورش جمهوری بلاروس مؤسسه آموزشی "دانشگاه دولتی انفورماتیک و رادیو الکترونیک بلاروس" تایید شده توسط رئیس دانشکده آموزش و علوم A.V. برنامه کاری Budnik برای رشته دانشگاهی "قابلیت اطمینان

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

مدل‌سازی خرابی‌های ناگهانی بر اساس قانون قابلیت اطمینان نمایی همانطور که قبلاً گفته شد، علت خرابی ناگهانی به تغییر وضعیت جسم در طول زمان مربوط نمی‌شود.

Barinov S.A., Tsekkhistrov A.V. 2.2 دانشجوی آکادمی نظامی لجستیک و پشتیبانی فنی به نام ژنرال ارتش A.V. خرولووا، سن پترزبورگ محاسبه شاخص های قابلیت اطمینان محصولات موشک و توپخانه

2 محتویات دامنه ... 5 2 مراجع نظارتی ... 5 3 اصطلاحات و تعاریف ... 6 4 نامگذاری ها و اختصارات ... 7 5 هدف و اهداف ارزیابی قابلیت اطمینان ... 8 6 مسئولیت ... 8 7 مقررات عمومی ...

آژانس حمل و نقل هوایی فدرال مؤسسه آموزشی فدرال آموزش عالی حرفه ای، دانشگاه فنی دولتی مسکو، هواپیمایی کشوری (MSTU GA)

1 سخنرانی 5. شاخص‌های قابلیت اطمینان شاخص‌های قابلیت اطمینان IT ویژگی‌های مهم سیستم‌ها مانند عملکرد بدون خرابی، قابلیت بقا، تحمل خطا، قابلیت نگهداری، ذخیره‌سازی، دوام را مشخص می‌کنند.

تجزیه و تحلیل مدل های پیش بینی قابلیت اطمینان نرم افزار T. Khunov دانشگاه ملی تحقیقاتی دانشکده عالی اقتصاد MIEM [ایمیل محافظت شده]چکیده این مقاله تحلیلی از مدل ها برای پیش بینی قابلیت اطمینان نرم افزار ارائه می دهد

اهداف و مقاصد این رشته رشته "قابلیت اطمینان وسایل نقلیه ویژه" یک رشته چرخه حرفه ای در آموزش مهندسان در تخصص " وسایل نقلیه

مشخصات: "ریاضی و روش های ابزاریاقتصاد" بخش اول. مبانی نظریه احتمال و آمار ریاضی 1. تعریف آماری و کلاسیک احتمال. مفهوم تصادفی

Ufa: UGATU, 202 T. 6, 8 (53. P. 67 72 V. E. Gvozdev, M. A. Abdrafikov statistical PROPERTIES OF FIDIENCE ESIMATES OF BUNDARY VALUES OF RIABILITY ویژگی های قابلیت اطمینان در مقاله 6 مورد اطمینان است.

گزینه تست برای گروه مکاتبات در رشته "قابلیت اطمینان سیستم های فنی و ریسک ساخت بشر". در نتیجه عملیات، تعدادی از داده های آماری در مورد قابلیت اطمینان غیر قابل تعمیر به دست آمد.

آژانس فدرال حمل و نقل راه آهن بودجه دولتی فدرال موسسه آموزش عالی حرفه ای "دانشگاه ارتباطات دولتی مسکو"

UDC 004.94، 519.2 A.Yu. روسین، ام. عبدالحمد (دانشگاه فنی دولتی Tver؛ پست الکترونیکی: [ایمیل محافظت شده]) پردازش اطلاعات در سیستم تست تجهیزات صنعتی برای قابلیت اطمینان

سخنرانی 8 8.1. قوانین توزیع شاخص های قابلیت اطمینان خرابی در سیستم های اتوماسیون راه آهن و تله مکانیک تحت تأثیر عوامل مختلف رخ می دهد. از آنجا که هر عامل به نوبه خود

UDC 59.873 الگوریتم و روش برای تجزیه و تحلیل قابلیت اطمینان یک وسیله نقلیه جنگی V. O. Karasev، دانشجوی روسیه، 05005، مسکو، MSTU. N.E. باومن، سرپرست علمی گروه انفورماتیک و سیستم های کنترل:

سخنرانی 4. شاخص های کمی اساسی قابلیت اطمینان سیستم های فنی هدف: در نظر گرفتن اصلی شاخص کمیقابلیت اطمینان زمان: 4 ساعت. سوالات: 1. شاخص های ارزیابی خواص فنی

UDC 681.3 A.I. ریژنکو، E.I. ریژنکو، دی.و. Kolesnichenko تعیین قابلیت اطمینان محصولات فنی اضافی غیر قابل تعمیر دانشگاه ملی هوافضا به نام. نه. ژوکوفسکی "خای"

7627 UDC 62-192 ON THE ISSUE OF RESOURCE ASSESSMENT OF TECHNICAL SYSTEMS N.V. موسسه مشکلات مدیریت لوبکوف. V.A. Trapeznikov RAS روسیه، 117997، مسکو، خیابان Profsoyuznaya، 65 ایمیل: [ایمیل محافظت شده] کلمات کلیدی:

1 این برنامه بر اساس استاندارد آموزشی ایالتی فدرال آموزش عالی (سطح آموزش پرسنل با مهارت بالا) در زمینه آموزش 01/06/13 "برق

قابلیت اطمینان سازه تئوری و عمل Tkachev O.A. تجزیه و تحلیل قابلیت اطمینان شبکه های متشکل از عناصر یکسان مدل های تحلیلی پیشنهاد شده است که به فرد امکان می دهد عباراتی را برای تعیین به دست آورد.

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

قابلیت اطمینان نرم افزار مقدمه

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

اگر می‌خواهید درک خوبی از مسائل مربوط به قابلیت اطمینان فناوری داشته باشید و به یک متخصص با درآمد بالا تبدیل شوید، از شما دعوت می‌کنم دوره آموزشی قابلیت اطمینان من را بگذرانید.

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

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

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

شاخص های قابلیت اطمینان نرم افزار

رایج ترین شاخص های قابلیت اطمینان نرم افزار به شرح زیر است:
– تعداد اولیه خطاهای N0 در نرم افزار پس از ساخت برنامه و قبل از رفع اشکال.
- تعداد خطاهای n در نرم افزار شناسایی شده و باقی مانده پس از هر مرحله اشکال زدایی؛
- زمان بین خرابی (MTBF)، ساعت؛
– احتمال عملکرد بدون خرابی (FBO) نرم افزار برای زمان مشخص شدهکار P(t);
– نرخ شکست نرم افزار λ، 10-6 1/h.

ارزیابی قابلیت اطمینان نرم افزار ساده شده

ابتدا بیایید به روش هایی که چارچوب نظارتی داخلی به ما ارائه می دهد نگاه کنیم. تنها سند تنظیمی در مورد این موضوع است
ارزیابی قابلیت اطمینان نرم افزار مطابق با GOST 28195-99 با استفاده از یک روش بسیار ساده محاسبه می شود که قابلیت اطمینان واقعی را بر اساس تجربه عملیاتی بسته نرم افزاری P(t) 1-n/N بیان می کند، که در آن n تعداد خرابی ها در طول نرم افزار است. آزمایش؛ N - تعداد آزمایش ها در طول آزمایش. بدیهی است که با این روش نمی توان چیزی را محاسبه کرد.

ارزیابی آماری قابلیت اطمینان نرم افزار

جالب تر، میانگین برآورد آماری توصیف شده در تعداد اولیه N0 خطا در نرم افزار پس از اشکال زدایی آفلاین است. بر اساس این ارزیابی، تعداد خطاها در هر هزار کلمه کد برای زبان‌های سطح پایین (اسمبلر) 4.34 و برای زبان‌های سطح بالا (C++) 1.44 است. متأسفانه، کاملاً مشخص نیست که منظور نویسندگان از عبارت "1K کلمه کد" چیست. در ادبیات انگلیسی زبان، مرسوم است که از پارامتر هزار خط کد (TCC) (KLOC) استفاده شود. پس با توجه به اتاق عمل سیستم های ویندوزتراکم خطای 2000 1.8-2.2 در TSC است. با توجه به اینکه ویندوز 2000 به زبان برنامه نویسی C نوشته شده است و تعداد خطاهای مشابهی دارد، می توان با اطمینان بالایی فرض کرد که نویسندگان داخلی پارامتر TSC را در نظر داشته اند.
نویسندگان داخلی شاخص های آماری نرخ شکست نرم افزار λ را ارائه می دهند. بیایید آنها را به
جدول 1.1.

جدول 1.1

متأسفانه، نویسندگان نمی گویند که این برای کدام زبان نرم افزار معتبر است. علاوه بر این، عوامل اصلاحی نیز معرفی می شوند:

جدول 1.2

و ضریب منعکس کننده تاثیر زمان اجرای برنامه:

جدول 1.3

سپس میزان شکست نرم افزار λ با استفاده از جداول 1.1-1.3 با عبارت:

λ توسط = λ* Kr* Kk* Kz* Ki (1.1)

مثال 1 محاسبه
حجم نرم افزار به عنوان مثال 1 مگابایت است.
سپس مطابق جدول 1.1 λ = 6
ما از عوامل تصحیح متوسط ​​استفاده می کنیم. اجازه دهید:
Kr = 2 ( کوتاه مدتاستفاده از نرم افزار)
Kk = 0.25 (نرم افزار با کیفیت بالا)
اتصال کوتاه = 0.25 (فرکانس بالای تغییرات نرم افزار)
Ki = 1 (متوسط ​​سطح بار کاری)
λ = 0.1 * 10 -6 خرابی در ساعت

P(t) = exp**(-λ*t) (1.2)

این مدل آماری برای ارزیابی قابلیت اطمینان نرم افزار دارای مزایای قابل توجهی در مقایسه با مدل ساده شده است، با این حال، دارای تعدادی معایب جدی نیز می باشد، به ویژه اینکه زبان توسعه نرم افزار را در نظر نمی گیرد و فواصل زیادی از حجم نرم افزار دارد. یعنی نمی توان مثلاً گفت که یک برنامه 2 گیگ چقدر قابل اعتماد خواهد بود و کدام یک باید 10 سال کار کند.
علاوه بر این، عوامل اصلاحی دارای یک ارزیابی ذهنی هستند. معلوم نیست از چه سقفی گرفته شده اند.
تلاش برای رفع این نواقص است مدل کمیارزیابی قابلیت اطمینان نرم افزار

مدل کمی برای ارزیابی قابلیت اطمینان نرم افزار

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

جدول 1.4

با دانستن V، مقدار کد نرم افزار، بر حسب بیت، می توانیم تعداد خطوط این کد را بدست آوریم. استفاده از پارامتر TSC راحت تر است.

TSC = V/146000 (1.3)

با استفاده از داده های جدول 1.4، می توانیم β، نرخ خطا در هزار خط کد را بدست آوریم:

β = 1.44*TSK/1000 (1.4)

حجم نرم افزار 10 مگابایت است. زبان توسعه ++C.
سپس بر اساس 1.3-1.4، β 0.08 خواهد بود
این شاخص بسیار نزدیک به نتیجه مثال 1 است.

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

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

می‌توانیم این فرض را داشته باشیم که β که معرفی کردیم (اختراع شده توسط من) معنای فیزیکینزدیک به λ، میزان شکست. λ میزان شکست را مشخص می کند. β فراوانی خطاها در برنامه و در نتیجه خرابی ها را مشخص می کند. اما!λ و β متفاوت هستند. λ، پس از تعیین برای یک ترانزیستور، بسته به تعداد ترانزیستورها تغییر نمی کند. β یک ضریب دینامیک است. هرچه اندازه برنامه بزرگتر باشد β بزرگتر است. اما این هم منطقی است. چگونه برنامه بیشتر، خطاهای بیشتری دارد. علاوه بر این، می توان فرض کرد که نویسندگان جدول 1.1 آن را برای نرم افزار به زبان C نوشته اند.

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

P(t) = exp**(-λ*t)

به طور خلاصه، برای ارزیابی قابلیت اطمینان نرم افزار، باید زبان توسعه آن (زیاد یا کم) و میزان کد نرم افزار را دانست.

قابلیت اطمینان ابزارهای هوانوردی و سیستم های اندازه گیری و محاسباتی، V.Yu. چرنوف/ V.G. نیکیتین؛ ایوانف یو.پی. - M. 2004.
قابلیت اطمینان و کارایی در فناوری: هندبوک.، V.S. آودوفسکی. 1988.
تخمین خطوط منبع کد از کد شی، L. Hatton. 2005.

حالا سعی کنید چیزی را محاسبه کنید. به عنوان مثال، قابلیت اطمینان نرم افزاری را پیدا کنید که 100 مگابایت حجم دارد و باید 100 ساعت کار کند. مهم! لطفاً توجه داشته باشید که وقتی حجم نرم افزار تغییر می کند، λ هر بار برای یک اندازه نرم افزار خاص دوباره محاسبه می شود.

نسخه نهایی سیستم توسعه یافته یک برنامه وب خواهد بود. بنابراین، برای اطمینان از عملکرد قابل اعتماد سیستم، لازم است اطمینان حاصل شود عملیات قابل اعتمادبخش نرم افزاری در این حالت، قابلیت اطمینان سیستم با استفاده از فرمول (1) محاسبه می شود:

R syst = R app.h R prog.h , (1)

که در آن R syst قابلیت اطمینان کل سیستم است.

R app.ch - قابلیت اطمینان سخت افزار؛

R prog.ch - قابلیت اطمینان بخش نرم افزار.

محاسبه قابلیت اطمینان نرم افزار

قابلیت اطمینان بخش نرم افزار با استفاده از فرمول (2) محاسبه می شود:

آر prog.h = آر سرور آر مشتری پ توسط , (2)

کجا آر سرور- قابلیت اطمینان نرم افزار سرور؛

آر مشتری- قابلیت اطمینان نرم افزار مشتری؛

آر توسط- قابلیت اطمینان نرم افزار توسعه یافته

محاسبه قابلیت اطمینان نرم افزار سرور

قابلیت اطمینان نرم افزار سرور با استفاده از فرمول (3) محاسبه می شود:

آر سرور = آر DBMS آر سیستم عامل , (3)

که در آن RDBMS قابلیت اطمینان سیستم مدیریت پایگاه داده است.

آر سیستم عامل- قابلیت اطمینان سیستم عاملبر روی سرور نصب شده است.

Red Hat Enterprise Linux 5 به عنوان سیستم عامل نصب شده بر روی سرور استفاده می شود.

آر سیستم عامل = 0,99.

کش DBMS به عنوان یک سرور پایگاه داده استفاده می شود که شرکت سازنده Intersystems احتمال عملکرد بدون خرابی را برابر با:

آر DBMS = 0,98.

بنابراین، احتمال عملکرد بدون خرابی نرم افزار سرور عبارت است از:

آر سرور =0,99 0,98= 0,98

محاسبهقابلیت اطمینان نرم افزار مشتری

قابلیت اطمیناننرم افزار مشتری با استفاده از فرمول (4) محاسبه می شود:

آر مشتری = آر سیستم عامل آر WB , (4)

کجا آر سیستم عامل- قابلیت اطمینان سیستم عامل نصب شده بر روی مشتری؛

آر WB- قابلیت اطمینان مرورگر وب مورد استفاده مشتری.

Windows 7 Home Premium به عنوان سیستم عامل نصب شده روی مشتری استفاده می شود که شرکت سازنده مایکروسافت احتمال عملکرد بدون خرابی را برابر با:

آر سیستم عامل = 0,98.

برای بسته اینترنت اکسپلورر 10، سازنده احتمال عملکرد بدون خرابی را برابر با:

آر WB = 0,9.

احتمال عملکرد بدون خرابی نرم افزار مشتری عبارت است از:

آر مشتری = 0,98 0,9 = 0,88

محاسبهقابلیت اطمینان نرم افزار

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

با استفاده از مدل میلز، قابلیت اطمینان نرم افزار سیستم توسعه یافته را محاسبه می کنیم. S = 25 خطا به طور مصنوعی وارد برنامه شد و با T = 100 اجرا، V = 24 مصنوعی و n = 4 خطای خود کشف شد. فرض بر این است که همه خطاها، چه مصنوعی و چه خود ایجاد شده، احتمال یکسانی برای شناسایی دارند. سپس تعداد اولیه خطاها را می توان از رابطه (5) تعیین کرد:

با استفاده از فرمول (6) احتمال چنین فرضی را می توان در مواردی که تمام خطاهای پراکنده مصنوعی شناسایی نشد، انجام داد:

K کجاست؟ n - تعداد خطاهای خود؛ صورت و مخرج فرمول ضرایب دو جمله ای شکل (7) هستند:

ما این احتمال را دریافت می کنیم که سیستم دارای 5 خطا از خود است: C = 0.75.

احتمال یک نتیجه نادرست با فرمول 8 تعیین می شود.

احتمال عملیات بدون خرابی (FBO) با فرمول (9) تعیین می شود:

نموداری از وابستگی عملکرد بدون خرابی نرم افزار سیستم به موقع (به ساعت) در شکل 23 ارائه شده است.

شکل 23 - وابستگی احتمال عملکرد بدون خرابی نرم افزار به زمان (به ساعت)

قابلیت اطمینان نرم افزار با استفاده از فرمول (5.2)، احتمال عملکرد بدون خرابی کل بخش نرم افزاری سیستم را تعیین می کنیم و یک نمودار وابستگی می سازیم. نموداری از احتمال عملکرد بدون خرابی بخش نرم افزاری سیستم نسبت به زمان (به ساعت) در شکل 24 ارائه شده است.

شکل 24 - وابستگی احتمال عملکرد بدون خرابی بخش نرم افزاری سیستم به موقع (به ساعت)

شکل نشان می دهد که خطاهای توسعه نرم افزار باعث کاهش قابلیت اطمینان کل سیستم می شود. با شناسایی و حذف خطاهای توسعه، تاثیر آنها بر قابلیت اطمینان سیستم کاهش می یابد.

ارسال کار خوب خود به پایگاه دانش آسان است. از فرم زیر استفاده کنید

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

ارسال شده در http://www.allbest.ru/

مقدمه

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

تجربه ایجاد و استفاده از سیستم‌های اطلاعاتی پیچیده (IS) اخیراً موقعیت‌های زیادی را آشکار کرده است که در آن خرابی‌ها و خرابی‌ها در عملکرد آنها ناشی از نقص در بسته‌های نرم‌افزاری بوده که منجر به خسارات اقتصادی قابل توجهی در طول عملیات آنها می‌شود. استفاده عملی. استفاده از چنین سیستم هایی در صورت ناکافی بودن قابلیت اطمینان آنها نه تنها بی فایده، بلکه خطرناک نیز می شود، زیرا می تواند منجر به شکست در سیستم های اطلاعاتی پیچیده اداری، بانکی و فناوری شود.

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

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

1 . بخش نظری

1.1 تعاریف اساسی

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

اصطلاح "قابلیت اطمینان نرم افزار" باید تعریف شود. به طور کلی پذیرفته شده است که قابلیت اطمینان احتمالی است که هیچ خطایی در طول عملیات یک سیستم برای مدت زمان معینی شناسایی نشود. این خطاها از نظر پیامدهای یکسان نیستند، بنابراین قابلیت اطمینان باید نه تنها به عنوان تابعی از فراوانی خطاها، بلکه همچنین از شدت آنها تعریف شود، یعنی. قابلیت اطمینان نرم افزار تابعی از تأثیر خطاها بر کاربر سیستم است. مختصرترین تفسیر از واژه قابلیت اطمینان نرم افزار با توجه به رویکرد اخیر به شرح زیر است. قابلیت اطمینان نرم افزار احتمال اجرای بدون خرابی اجرای برنامه است.

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

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

برنج. 1.1. ویژگی هایی که قابلیت اطمینان نرم افزار را تعیین می کند

قابلیت اطمینان عملیات نرم افزار به طور خلاصه با پایداری یا توانایی عملیات ایمن و بازیابی یک حالت عملیاتی پس از وقوع خرابی ها و خرابی ها مشخص می شود. به عبارت دیگر، حتی یک برنامه با خطا می تواند در حین کار به طور قابل اعتماد عمل کند. اگر خرابی ثبت نشود، چنین خطاهایی بر شاخص های قابلیت اطمینان نرم افزار تأثیر نمی گذارد.

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

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

زیر سیستم اطلاعاتی(IS) در تئوری قابلیت اطمینان معمولاً به عنوان مجموعه ای از زیرسیستم ها یا عناصر درک می شود که به طور عملکردی مطابق با یک الگوریتم تعامل خاص در هنگام انجام یک کار معین در فرآیند استفاده مورد نظر ترکیب می شوند.

ابزار نرم افزاری (SS) مجموعه ای از برنامه ها است که به شما امکان می دهد یک الگوریتم پردازش داده را با استفاده از فناوری رایانه پیاده سازی کنید.

نرم افزار (SW) مجموعه ای از ابزارهای نرم افزاری است که اجرای اهداف سیستم های پردازش و کنترل داده ها را تضمین می کند.

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

تدوین مفاهیم اساسی مورد استفاده در مطالعه و کاربرد شاخص های قابلیت اطمینان

شناسایی و مطالعه عوامل اصلی تعیین کننده ویژگی های قابلیت اطمینان سیستم های نرم افزاری پیچیده.

انتخاب و توجیه معیارهای قابلیت اطمینان برای بسته های نرم افزاری انواع مختلفو قرار ملاقات ها؛

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

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

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

نتایج حل این مشکلات مبنای ایجاد نرم افزارهای پیچیده مدرن با شاخص های قابلیت اطمینان مشخص شده است.

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

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

بررسی عملکرد سیستم و توانایی انجام تمام عملکردها در یک حالت عملیاتی معین در هر زمان؛

جستجو، شناسایی و بومی سازی منابع و نتایج خرابی ها، خرابی ها و خرابی ها در سیستم.

1.2 طبقه بندی مدل های قابلیت اطمینان

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

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

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

بنابراین نیاز به تعیین قابلیت اطمینان نرم افزار در تمام مراحل چرخه عمر آن وجود دارد.

بیایید طبقه بندی موجود مدل های قابلیت اطمینان نرم افزار را در نظر بگیریم (شکل 1.2).

برنج. 1.2. طبقه بندی مدل های قابلیت اطمینان نرم افزار

1.2.1 مدل های پویا پیوسته

اجازه دهید عملکرد نرم افزار با نمودار وضعیت نشان داده شده در شکل 1.3 توضیح داده شود. در اینجا S i وضعیت سیستم وقتی است i-th اتفاق افتادتعداد خرابی ها، l i شدت وقوع شکست بعدی ((i + 1) است.

برنج. 1.3. نمودار وضعیت عملکرد نرم افزار

می توانید هر نوع وابستگی شدت وقوع شکست بعدی را به تعداد خرابی هایی که قبلاً رخ داده است تنظیم کنید، به عنوان مثال،

جایی که r<1. Значения l 0 и r можно оценить статистически по данным о моментах отказов.

اجازه دهید فرآیندهای رخ داده در هنگام خرابی و بازیابی نرم افزار را توضیح دهیم. اگر l i را به عنوان یک متغیر تصادفی با تابع توزیع l(t) در نظر بگیریم، این تابع به طور یکنواخت در حال کاهش است، زیرا نرخ شکست در طول زمان کاهش می‌یابد. پس از اصلاح، نرخ شکست آنی به شدت کاهش می یابد (نقاط 1 و 2 در شکل 1.4).

برنج. 1.4. نمودار میزان شکست در مقابل زمان

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

مدل Jelinski-Moranda. این مدل بر این فرض استوار است که زمان تا شکست بعدی به صورت تصاعدی توزیع شده است و میزان شکست برنامه متناسب با تعداد خطاهای باقی مانده در برنامه است.

با توجه به این مفروضات، احتمال عملکرد بدون خرابی نرم افزار به عنوان تابعی از زمان tمن برابر است با:

نرخ شکست کجاست:

در اینجا C D ضریب تناسب است.

N تعداد اولیه خطاها است.

در (1.1)، شمارش زمان از لحظه شکست آخرین (i - 1) برنامه شروع می شود.

با استفاده از روش حداکثر درستنمایی بر اساس (1.1)، با نشان دادن k تعداد شکست پیش بینی شده، متوجه می شویم که تابع درستنمایی به شکل زیر است:

تابع log likelihood به شکل زیر است:

از این رو شرایط برای یافتن اکستریم:

از (1.6) دریافت می کنیم:

بیایید (1.7) را با (1.5) جایگزین کنیم. دریافت می کنیم:

برای مقادیر شناخته شده k؛ t 1 , t 2 , …, t k از (1.7) و (1.8) می توانید مقادیر پارامترهای مدل C D و N و سپس میزان شکست، زمان از آخرین تا شکست بعدی t k+ را پیدا کنید. 1، احتمال عملیات بدون شکست پس از زمان t k + 1 پس از آخرین شکست.

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

مثال محاسبه اجازه دهید فواصل زمانی t 1 = 10، t 2 = 20، t 3 = 25 ساعت بین خرابی های برنامه در حین اشکال زدایی ثبت شود. تعیین احتمال ضروری است:

و در سمت راست:

از (1.2) بدست می آوریم

بنابراین، میانگین زمان تا شکست بعدی:

سپس، با جایگزینی مقادیر یافت شده l 4 و t 4 به (1.1)، احتمال عدم وجود شکست چهارم را بدست می آوریم:

مدل احتمال انتقال مارکوفاین مدل بر اساس مدل‌سازی اولیه شدت خطاهای رخ داده l و همچنین سیستم تصحیح خطای اتخاذ شده که با شدت m کار می‌کند، تخمین‌ها و پیش‌بینی‌هایی از تعداد احتمالی خطاهایی را که در یک زمان معین تصحیح می‌شوند، ممکن می‌سازد. این مدل پیش‌بینی‌هایی را برای در دسترس بودن A(t) و قابلیت اطمینان R(t) سیستم نرم‌افزاری ممکن می‌سازد.

محدودیت های اصلی مدل توسعه یافته زیر پذیرفته شده است:

هر خطایی تصادفی و بدون درجه بندی عواقبی تلقی می شود.

شدت خطاها ثابت و برابر l است.

نرخ تصحیح خطا ثابت و برابر با m است.

زمان انتقال یک سیستم از یک حالت به حالت دیگر بی نهایت کم است.

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

مکان نقاط روی محور زمانی گسسته آزمایش کجاست. فرض کنید یک متغیر تصادفی دارای تابع توزیع است:

و اگر وجود داشته باشد، چگالی تابع توزیع خواهد بود:

قابلیت اطمینان سیستم R(t) با احتمال عدم خرابی در بازه تعیین می شود:

آمادگی سیستم در زمان t احتمال این است که سیستم در زمان t در حالت کار قرار دارد:

فرض کنید در دوره اولیه (t = 0) سیستم دارای تعداد ناشناخته (n) خطا است. شروع مرحله آزمایش به عنوان نقطه شروع برای زمان عملیات سیستم انتخاب می شود. همچنین می پذیریم که فرآیندهای تشخیص و تصحیح خطا به صورت متناوب و متوالی اجرا می شوند.

برنج. 1.5. مدل چند حالته برای ارزیابی عملکرد نرم افزار

تعدادی از حالت های سیستم (n، n - 1، n - 2، ...) مربوط به فرآیندهای تشخیص خطا است. به قیاس، برای مورد حذف خطا، حالات سیستم را معرفی می کنیم (t، t - 1، t - 2، ...). اگر خطای (k - 1) قبلاً تصحیح شده باشد و خطای k هنوز شناسایی نشده باشد، سیستم در حالت (n - k) است. در عین حال، پس از شناسایی خطای k اما هنوز تصحیح نشده است، سیستم در حالت (t - k) خواهد بود. نمودار کلی مدل که احتمال انتقال بین حالت ها را نشان می دهد در شکل 1 نشان داده شده است. 1.5.

فرض کنید S"(t) یک متغیر تصادفی باشد که از طریق آن وضعیت سیستم در زمان t مشخص می شود. آزمایش به گونه ای ساخته می شود که در نقطه ای از زمان سیستم را متوقف کرده و وضعیت آن را مشاهده می کنیم. فضای حالت های ممکن S سیستم را می توان به صورت زیر نشان داد:

حال فرض کنید که در لحظه ها (هر دنباله ای از مشاهدات) دنباله متغیرهای تصادفی برای هر عدد صحیح مثبت l برابری زیر را برآورده می کند:

جایی که با توالی حالت ها مطابقت دارد

بنابراین، هر حالت مدل با تعدادی احتمال انتقال (P ij ) تعیین می شود، که در آن P ij احتمال انتقال از حالت i به حالت j را نشان می دهد و به حالت های قبلی و بعدی سیستم، به جز حالت ها، بستگی ندارد. من و ج. احتمال انتقال از حالت (n - k) به حالت (t - k) برابر است برای k = 0, 1, 2, ... به طور مشابه، احتمال انتقال از حالت (t - k) به حالت (n - k - 1) برابر k = 0، 1، 2، …

شدت انتقال l j و m j به وضعیت فعلی سیستم بستگی دارد. برای یک سیستم نرم افزاری، l j به معنای شدت وقوع (تجلی) است، m j شدت حذف خطا است. بنابراین، ماتریس کامل احتمالات انتقال سیستم را می توان به صورت زیر نمایش داد:

عبارت آمادگی سیستم در زمان t (tі0) بر اساس تعریف آن به دست می آید:

در دسترس بودن سیستم در زمان t به عنوان نتیجه یک جمع ساده از همه احتمالات حالت های مشغول تعیین می شود.

قابلیت اطمینان سیستم به درجه اشکال زدایی آن بستگی دارد، یعنی. هر چه درجه اشکال زدایی سیستم بالاتر باشد، قابلیت اطمینان مورد انتظار بیشتر است. فرض کنید در زمان t سیستم به تازگی وارد حالت (n - k) شده است، یعنی خطای k به تازگی حذف شده است. بیایید این زمان را t. سپس، در بازه زمانی (0، T k+1)، جایی که t = T k+1، یک خطا (k + 1) می تواند در شدت خطای ثابت پذیرفته شده l k ظاهر شود.

بر اساس فرمول تابع قابلیت اطمینان، که احتمال عدم خرابی در بازه زمانی 0 تا t را ایجاد می کند.

یک عبارت برای قابلیت اطمینان بدست می آوریم:

مزایا و معایب مدل. مزیت مدل این است که یک سیستم نرم افزاری نسبتاً بزرگ در نظر گرفته شده است که تعداد آن حدود 105 کد است که به ما امکان می دهد به اهمیت نتایج آماری امیدوار باشیم.

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

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

مثال محاسبه اجازه دهید فواصل زمانی t 1 = 10، t 2 = 20، t 3 = 25 ساعت بین خرابی های برنامه در حین اشکال زدایی ثبت شود. سیستم در حالتی است که خطای 3 قبلاً تصحیح شده است، اما خطای 4 هنوز شناسایی نشده است. تعیین احتمال ضروری است:

عدم وجود شکست بعدی (چهارم).

در اینجا ساعت ها زمانی است که آخرین خطای شناسایی شده تصحیح شد.

ما مقدار l i را با استفاده از مدل Dzelinski-Moranda تعیین می کنیم (فرمول (1.2)):

ما مقادیر C D و N را با استفاده از فرمول های (1.7) و (1.8) تعیین می کنیم.

تعداد اولیه خطاهای N با روش انتخاب پیدا می شود. اگر N=3، یعنی تمام خطاها شناسایی شوند، در سمت چپ (1.8) داریم:

و در سمت راست:

اگر N=4، سمت چپ و راست به ترتیب 152 و 150 هستند، اگر N=5، 210 و 205 باشند.

در نتیجه، کوچکترین خطا در حل (1.8) توسط N=4 ارائه خواهد شد که طبق فرمول (1.7):

از (1.2) بدست می آوریم:

سپس، با جایگزینی مقدار یافت شده l 4 به (1.19)، احتمال عدم وجود شکست چهارم را بدست می آوریم:

1.2.2 مدل های گسسته

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

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

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

اجازه دهید در مجموع k مرحله تست وجود داشته باشد. اجازه دهید مدت زمان هر مرحله را با t 1، ...، t k، و تعداد خطاهای شناسایی شده در هر مرحله را با m 1، ...، m k نشان دهیم.

اجازه دهید T = t 1 + … + t k - زمان آزمایش کل. n = m 1 + … + m k - تعداد کل خطاهای شناسایی و تصحیح شده در طول آزمایش. n i = m 1 + … + m i - تعداد خطاهای اصلاح شده با شروع مرحله آزمایش (i + 1) (n 0 = 0).

در مدل شومان، نرم افزار در مرحله آزمایش i-امین تابع قابلیت اطمینان است:

N تعداد اولیه خطاهای نرم افزار است.

N - n i-1 - تعداد خطاهای باقی مانده در ابتدای مرحله i-ام.

ج - ضریب تناسب برابر با:

برای یافتن تعداد خطاهای اولیه در نرم افزار N از معادله استفاده می شود:

برای مقادیر شناخته شده k؛ t 1, t 2, …, t k; m 0 , m 1 , …, m k از (1.21) و (1.22) می توانید مقادیر پارامترهای مدل C و N را پیدا کنید. پس از آن می توانید شاخص های زیر را تعیین کنید:

1) تعداد خطاهای باقی مانده در نرم افزار:

2) عملکرد قابلیت اطمینان نرم افزار پس از اتمام آزمایش:

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

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

مثال محاسبه مدت زمان مراحل تست ساعت، ساعت، ساعت می باشد. تعداد شکست در مرحله اول ، در مرحله دوم - ، در مرحله سوم - . لازم است تعداد خطاهای باقی مانده در نرم افزار و همچنین عملکرد قابلیت اطمینان نرم افزار در پایان تست مشخص شود.

با استفاده از روش انتخاب از معادله (1.22)، در می یابیم که تعداد اولیه خطاها.

بیایید تعداد خطاهای باقی مانده در نرم افزار را با استفاده از (1.23) پیدا کنیم:

با استفاده از فرمول (1.21) مقدار پارامتر C را پیدا می کنیم:

با جایگزینی l به (1.24)، تابع قابلیت اطمینان نرم افزار را پس از اتمام آزمایش به دست می آوریم:

مدل موسی. در این مدل، قابلیت اطمینان نرم افزار در مرحله عملیاتی بر اساس نتایج آزمایش ارزیابی می شود.

فرض کنید T کل زمان تست، n تعداد خرابی هایی باشد که در طول آزمایش رخ داده است.

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

که در آن t 0 میانگین زمان شکست قبل از آزمایش است، C ضریبی است که فشردگی زمان آزمایش را در مقایسه با زمان عملیات واقعی در نظر می‌گیرد. به عنوان مثال، اگر یک ساعت آزمایش با 12 ساعت کار در شرایط واقعی مطابقت دارد، C = 12.

پارامتر مجهول t 0 را می توان از رابطه زیر تخمین زد:

که در آن N تعداد اولیه خطاهای نرم افزار است. می توان با استفاده از مدل دیگری تخمین زد که N را بر اساس آمار بدست آمده از آزمایش تعیین می کند.

K ضریب تظاهر خطا است. مقدار K به صورت تجربی با استفاده از برنامه های مشابه تعیین می شود. به طور معمول این مقدار از 1.5H10 -7 تا 4H10 -7 متغیر است.

f میانگین سرعت اجرای یک دستور برنامه، برابر با نسبت میانگین سرعت اجرای نرم افزار (A) به تعداد دستورات (اپراتورها) (B) است.

قابلیت اطمینان نرم افزار برای دوره عملیاتی t با فرمول تعیین می شود:

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

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

مثال محاسبه مدت زمان مراحل تست ساعت، ساعت، ساعت می باشد. تعداد شکست در مرحله اول ، در مرحله دوم - ، در مرحله سوم - . میانگین سرعت اجرای نرم افزار توسط اپراتورها/ساعت، تعداد اپراتورهای نرم افزار. قابلیت اطمینان نرم افزار را برای مدت کارکرد ساعت تعیین کنید.

بیایید میانگین سرعت اجرای یک عبارت را پیدا کنیم:

تعداد اولیه خطاها را در نرم افزار N با استفاده از مدل شومان با استفاده از روش انتخاب از معادله (1.22) پیدا خواهیم کرد: کمترین اختلاف در مقادیر سمت راست و چپ این معادله به دست می آید. بنابراین، این تعداد خطاهای اولیه در نرم افزار است.

فرض کنید ضریب بروز خطا K برابر است.

بیایید مقدار پارامتر t 0 را با استفاده از (1.26) پیدا کنیم:

بیایید مقدار ضریب را در نظر بگیریم.

سپس میانگین زمان شکست پس از آزمایش در مرحله عملیات مطابق (1.25):

اجازه دهید با استفاده از فرمول (1.27) قابلیت اطمینان نرم افزار را برای مدت کارکرد ساعت پیدا کنیم:

1.2.3 مدل های استاتیک

تفاوت مدل های استاتیک با مدل های پویا عمدتاً به این دلیل است که زمان وقوع خطا را در نظر نمی گیرند.

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

این برنامه برای مدتی آزمایش می شود و آمار خطاهای شناسایی شده جمع آوری می شود.

فرض کنید پس از آزمایش، n خطای برنامه خود و v خطای مصنوعی معرفی شده کشف شود. سپس تعداد اولیه خطاهای برنامه N را می توان با استفاده از فرمول Mills تخمین زد:

که در آن S تعداد خطاهای معرفی شده مصنوعی است.

بخش دوم مدل مربوط به آزمون فرضیه N است. فرض کنید ما معتقدیم که ابتدا K خطا در برنامه وجود دارد. ما به طور مصنوعی خطاهای S را وارد برنامه می کنیم و آن را آزمایش می کنیم تا تمام خطاهای معرفی شده مصنوعی شناسایی شوند. فرض کنید که n خطای برنامه خود شناسایی شده است. احتمال اینکه برنامه در ابتدا خطاهای K داشته باشد را می توان با استفاده از رابطه محاسبه کرد:

فرمول (1.29) تنها در صورتی قابل استفاده است که تمام خطاهای معرفی شده مصنوعی S شناسایی شوند. اگر فقط v خطاهای معرفی شده مصنوعی شناسایی شوند، از فرمول استفاده می شود:

تعداد ترکیبات n عنصر m.

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

با این حال، معایبی وجود دارد:

1) نیاز به معرفی خطاهای مصنوعی (این فرآیند ضعیف رسمی شده است).

2) یک فرض نسبتاً آزاد از ارزش K، که صرفاً مبتنی بر شهود و تجربه شخصی است که ارزیابی می کند، یعنی اجازه می دهد تا تأثیر زیادی از عامل ذهنی داشته باشد.

مثال محاسبه 1. 50 خطا به برنامه وارد شد و در طی مراحل تست 25 خطای خود و 5 خطای معرفی شده کشف شد، سپس با استفاده از فرمول Mills (1.28) این فرض ایجاد می شود که در ابتدا آنها در برنامه وجود داشته است.

مثال محاسبه 2. بیان شده است که هیچ خطایی در برنامه وجود ندارد (K = 0). هنگامی که 10 خطا به برنامه وارد می شود، همه آنها در طول آزمایش شناسایی می شوند، اما حتی یک مورد از خود ما شناسایی نمی شود. سپس طبق فرمول (1.29) احتمال درستی این عبارت برابر است. بنابراین، با احتمال 0.91 می توان گفت که برنامه هیچ خطایی ندارد. اما اگر حداقل یک خطای خود در طول آزمایش تشخیص داده شود، آنگاه p = 0.

مثال محاسبه 3. بیان شده است که هیچ خطایی در برنامه وجود ندارد. تا زمان ارزیابی قابلیت اطمینان، از هر 10 خطای معرفی شده مصنوعی، 5 مورد شناسایی شد و حتی یک خطای خودمان شناسایی نشد. سپس احتمال اینکه واقعا هیچ خطایی در برنامه وجود نداشته باشد با استفاده از فرمول (1.30) محاسبه می شود و برابر است با:

اگر در شرایط اولیه یکسان ارزیابی قابلیت اطمینان در لحظه ای انجام شود که از هر 10 خطای مصنوعی 8 مورد شناسایی شود، طبق فرمول (1.30)

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

مدل فرض می‌کند که ناحیه‌ای که ممکن است داده‌های ورودی برنامه به آن تعلق داشته باشد، به k ناحیه غیرمتناسب Z i، i = 1، 2، …، k تقسیم می‌شود. فرض کنید p i احتمالی باشد که یک مجموعه داده از ناحیه Z i برای اجرای بعدی برنامه انتخاب شود. مقادیر p i از آمار داده های ورودی در شرایط عملیاتی واقعی نرم افزار تعیین می شود.

فرض کنید تا زمان ارزیابی قابلیت اطمینان، n i اجرا از نرم افزار بر روی مجموعه داده ها از ناحیه Z i انجام شده است و از این اجراها با شکست به پایان رسیده است.

سپس قابلیت اطمینان نرم افزار با استفاده از فرمول ارزیابی می شود:

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

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

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

که در آن n + تعداد اجرای موفق نرم افزار است.

تعداد خطاهای شناسایی شده از نوع i که با احتمال p i حذف می شوند.

d i - ضریب به شرح زیر تعیین می شود:

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

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

نمونه ای از محاسبه با استفاده از مدل تعمیم یافته نلسون-کورکوران. تعداد کل اجرای نرم افزار، تعداد اجراهایی که ناموفق بوده است، .

قابلیت اطمینان با فرمول (1.34) تعیین می شود:

1.2.4 مدل های تجربی

مدل های تجربی مبتنی بر تجزیه و تحلیل اطلاعات انباشته شده در مورد عملکرد برنامه های توسعه یافته قبلی است.

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

مدل IBM IBM از یک مدل تجربی استفاده می کند که تعداد خطاها را در نسخه های مختلف سیستم عامل تخمین می زند:

که در آن M 10 تعداد ماژول هایی است که به 10 یا بیشتر اصلاحات نیاز دارند.

M 1 - تعداد ماژول هایی که کمتر از 10 خطا در آنها شناسایی شده است.

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

جایی که t میانگین زمان بین خرابی های نرم افزار بر حسب ساعت است.

V OP - حجم برنامه در اپراتورها.

N تعداد خطاهای نرم افزار است که با استفاده از یکی از مدل های بالا تخمین زده می شود.

a یک ضریب از 100 تا 1000 است.

مثال محاسبه تعداد ماژول هایی که به 10 یا بیشتر رفع نیاز داشتند برابر است و تعداد ماژول هایی که کمتر از 10 خطا در آنها یافت شد برابر است. بیایید تعداد خطاهای نرم افزار N را با استفاده از فرمول IBM (1.35) پیدا کنیم:

مدل هالستدتعداد خطاهای باقی مانده در برنامه پس از اتمام توسعه آن را تخمین می زند:

که در آن N OR تعداد خطاهای برنامه است.

K NO - ضریب تناسب؛

V OP - تعداد اپراتورها در برنامه؛

h 1 - تعداد اپراتورها در نرم افزار؛

h 2 - تعداد عملوندها در نرم افزار.

مزایا و معایب مدل های تجربی. مزیت مدل های تجربی این است که حاوی فرمول های پیچیده نیستند و محاسبات ساده هستند.

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

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

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

در طول مراحل تولید و استفاده از نرم افزار، اطلاعات مربوط به فرآیند اشکال زدایی، تشخیص خطا و حذف عموماً در دسترس نیست.

شکست در طول آزمون های پذیرش با شدت کم یا وجود ندارد.

بنابراین، برای تعیین قابلیت اطمینان نرم افزار در تمام مراحل چرخه عمر آن، توصیه می شود حداقل از دو مدل قابلیت اطمینان نرم افزار استفاده شود. مدل قابلیت اطمینان نرم افزار برای مرحله توسعه برای هر برنامه خاص انتخاب می شود. برای انجام این کار، شما باید داده های خطا را جمع آوری کنید، یک مدل قابلیت اطمینان را بر اساس داده های موجود انتخاب کنید، و سپس آزمایش هایی را اجرا کنید تا نشان دهید که مدل چقدر مطابقت دارد. برای تعیین قابلیت اطمینان نرم‌افزار در مراحل پایانی، استفاده از مدل‌های قابلیت اطمینان با استدلال مستقل از سیستم، به عنوان مثال، مدل نلسون، مؤثرتر است.

1.3 تجزیه و تحلیل قابلیت اطمینان سیستم های نرم افزاری

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

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

1.3.1 مدل نموداری برنامه

به عنوان یک مدل گراف برنامه، یک گراف جهت دار G (V, Г) را در نظر بگیرید، که در آن V = (v i) مجموعه رئوس است، Г = (g ij) مجموعه کمان ها است. نمودار سیستم G(V, Г) توسط ساختار سیستم نرم افزار تعیین می شود. مجموعه V از رئوس نمودار ماژول های برنامه (انواع ماژول ها) را تشکیل می دهد و مجموعه کمان ها ارتباط بین ماژول ها را منعکس می کند، یعنی اگر انتقالی از ماژول i به ماژول j وجود داشته باشد، سپس در نمودار G یک قوس g ij وجود دارد که از راس i-امین به راس j-ام منتهی می شود. اجازه دهید محدودیت های مدل را معرفی کنیم. فرض کنید در مدل گراف برنامه یک راس منبع v 0 (ورودی) و یک راس سینک v k (خروجی) وجود دارد. همچنین فرض کنید که از هر راس بیش از دو کمان خارج نمی شود. فرض می کنیم که مدل گراف برنامه شامل چرخه نیست و برنامه ای که نمایش می دهد به دسته غیر خودتغییر تعلق دارد.

هنگام مدل‌سازی یک فرآیند محاسباتی بر روی مدل نموداری یک برنامه و مطالعه ویژگی‌های نرم‌افزار، پیش‌بینی می‌شود که به هر عنصر مدل وزن مشخصی داده شود. اجازه دهید فرض کنیم که هر رأس v i با یک شاخص ابتدایی افزایشی d i مرتبط با ویژگی برنامه مورد مطالعه مشخص می شود. شاخص های وارد شده مجموعه D = (d i) را روی نمودار تشکیل می دهند. مدل G(V, Г, D) را می توان برای مطالعه آماری مسیرهای مختلف یک مدل گراف برنامه استفاده کرد. انتخاب مسیر در حال اجرا در نمودار توسط مجموعه ای از پیاده سازی های انتقال کنترل در رئوس تعیین می شود که با فرآیند تصادفی دریافت بردارهای داده ورودی مختلف در ورودی برنامه همراه است که منجر به ماهیت تصادفی می شود. انتخاب مسیرها در نمودار بنابراین، نرم افزار مورد مطالعه را می توان به عنوان یک سیستم پیچیده با ساختار تصادفی نشان داد که دینامیک عملکرد آن باید به صورت آماری با استفاده از احتمالات انتقال از راس i-ام به راس j-ام مدل گراف برنامه توصیف شود.

با در نظر گرفتن این موضوع، احتمال فعال شدن آن p(i, j)ОP را به قوس g ij اختصاص می دهیم، یعنی احتمال حرکت در امتداد آن از راس vi به راس v j. فرض کنید برای دو کمان و برابری زیر برقرار است:

بنابراین، مدل گراف ساخته شده برنامه یک گراف بارگذاری شده غیر چرخه‌ای G(V، Г، D، P) است.

در شکل 1.6 نمونه ای از مدل نمودار یک برنامه را نشان می دهد. روی آن، راس 0 راس مبدا و راس 4 سینک است.

1.3.2 مدل نلسون برای تعیین قابلیت اطمینان برای مدل نموداری یک برنامه

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

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

به منظور استفاده از مدل G(V، Г، D، P)، به ویژگی‌های افزودنی نشان‌داده‌شده معنای یک اندازه‌گیری لگاریتمی احتمالات r i یک اجرای بدون خرابی منفرد از یک دنباله از عملگرهای مرتبط با راس v i را نسبت می‌دهیم. :

سپس احتمال اجرای بدون خرابی مسیر در طول یکمین اجرای نرم افزار با برابری تعیین می شود:

و اندازه لگاریتمی آن:

با استفاده از تقریب:

که در آن Q m احتمال شکست هنگام اجرای مسیر است (این شرط طبق تعریف برآورده می شود) و فرض، داریم:

از آنجایی که مسیر w m با احتمال p(m) پیاده‌سازی می‌شود، احتمال کل شکست در طول mth اجرا با عبارت:

تخمین میانگین احتمال شکست Qm توسط روابط تکراری ارائه می شود:

که در آن p(i) احتمال فعال شدن راس i-ام مدل گراف برنامه است.

مدل ساختاری پیشنهادی به ما اجازه می‌دهد تا ویژگی‌های قابلیت اطمینان نرم‌افزار را در مراحل پایانی چرخه عمر آن تعیین کنیم.

1.3.3 روش تصادفی برای محاسبه قابلیت اطمینان

بیایید یکی از روش های ارزیابی عددی قابلیت اطمینان سیستم های نرم افزاری پیچیده را در نظر بگیریم.

اجازه دهید یک مجموعه نرم افزاری متشکل از M ماژول های منفرد داده شود. بر اساس ساختار بسته نرم افزاری، یک نمودار تصادفی حاوی رئوس مربوط به ماژول ها ساخته می شود. رئوس 0 و ساختگی هستند. راس 0 منبع و راس سینک گراف است. هر ماژول نرم افزاری برای تصمیم گیری با احتمال معین، بر اساس هدف عملیات یا مقادیر داده های اولیه فراخوانی می شود. فرض بر این است که قابلیت اطمینان همه ماژول های نرم افزار مشخص است. هدف یافتن احتمال راه حلی بدون خطا برای مشکل بسته نرم افزاری است.

فرض کنید P ij احتمال انتقال از ماژول نرم افزار i به j ام باشد و P i (t i) احتمال عملکرد بدون خطا ماژول نرم افزار i در طول زمان t i باشد.

از آنجایی که رئوس 0 و (M + 1) ساختگی هستند، زمان صرف شده در آنها را صفر فرض می کنیم و احتمال عملکرد بدون خطا در آنها یک است.

در شکل شکل 1.7 نمونه ای از نمودار تصادفی یک بسته نرم افزاری را نشان می دهد. روی آن: راس 0 راس منبع است، راس 4 راس فرورفتگی است، t 0 = t 5 = 0، P 0 (t 0) = P 5 (t 5) = 1.

ماتریس G = G(t), t = t 0 , t 1 , …, t M + 1 را در نظر بگیرید که عناصر آن حاصل ضرب P ij ХP i (t i) هستند. i، j = 0، …، M + 1:

اجازه دهید مفهوم یک مرحله را معرفی کنیم، به این معنی که یک انتقال واحد از یک ماژول نرم افزاری به ماژول دیگر است.

فرض کنید n حداکثر تعداد مراحل ممکن در مسیر از راس 0 تا راس (M + 1) باشد.

برای یافتن احتمالات عملیات بدون خطا در دو مرحله، باید حاصل ضرب احتمالات در تمام مسیرهای حاوی دو راس (یکی از آنها صفر است) را با احتمالات مربوطه جمع کنید. این با مجذور کردن ماتریس G به دست می آید. برای بدست آوردن احتمال عملیات بدون خطا در سه مرحله، G و غیره را بسته به n مکعب می کنیم.

اگر نمودار دارای چرخه باشد، n ​​برابر با بی نهایت است، زیرا چرخه را می توان بی نهایت بار طی کرد.

بیایید یک ماتریس از فرم بسازیم:

T = I + G(t) + G 2 (t) + … + G n (t).

اگر چرخه هایی در نمودار وجود داشته باشد، ماتریس T به شکل زیر خواهد بود:

T = I + G(t) + G 2 (t) + … = I (I - G(t))- 1، (1.42)

جایی که من ماتریس هویت هستم.

عنصر ماتریس T با شماره (0، M + 1) عبارتی است برای احتمال عملکرد بدون خطا کل مجموعه نرم افزار، با در نظر گرفتن تمام توالی های ممکن فراخوانی ماژول های نرم افزاری مجزا.

اگر چرخه هایی در نمودار وجود داشته باشد و ماتریس T مطابق با (1.42) باشد، برای یافتن مقدار عنصر با شماره (0، M + 1)، مطابق با قوانین محاسبه مقادیر از عناصر ماتریس معکوس، عبارت احتمال عملکرد بدون خطا بسته نرم افزاری را می توان به شکل زیر نشان داد:

Y(t) = Q(t) / R(t)، (1.43)

که در آن Q(t) مکمل جبری عنصر با عدد (M + 1, 0) ماتریس است. R(t) تعیین کننده اصلی ماتریس است (I - G(t)).

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

مزیت روش این است که امکان ارزیابی قابلیت اطمینان سیستم‌های نرم‌افزاری پیچیده با شاخص‌های قابلیت اطمینان شناخته‌شده ماژول‌های مؤلفه و وابستگی احتمالی آنها را در یک نمودار تصادفی فراهم می‌کند.

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

هنگام ارزیابی احتمال عملکرد بدون خرابی ماژول نرم‌افزار i-ام، از فرمول (1.27) از مدل Moose استفاده می‌کنیم که در آن عبارت میانگین زمان شکست پس از آزمایش در مرحله عملیاتی جایگزین می‌شود (1.25) (1.25). به پاراگراف 1.2.2 مراجعه کنید):

جایی که t i زمان کار ماژول i است.

میانگین زمان شکست قبل از آزمایش برای ماژول i-ام.

C ضریبی است که فشردگی زمان آزمایش را در مقایسه با زمان عملیات واقعی در نظر می گیرد.

T i - زمان تست ماژول i-ام.

n i تعداد خرابی هایی است که در طول تست ماژول i-ام رخ داده است.

مشخص است که ضریب مدت زمان عملیات ماژول c، s، s است. تعداد خرابی های رخ داده در ماژول ها در حین آزمایش: , . میانگین زمان شکست قبل از آزمایش برای ماژول ها: s، s، s. احتمالات انتقال بین ماژول ها: , . بیایید زمان تست ماژول را در نظر بگیریم: s، s، s.

بیایید از فرمول احتمال عملکرد بدون خرابی ماژول نرم افزار i-th از مدل Musa استفاده کنیم:

برای یک نمودار معین، تعداد ماژول ها M = 3 است (ماژول های 0 و 4 ساختگی هستند).

بیایید ماتریس این نمودار را با استفاده از (1.41) بسازیم:

اجازه دهید ماتریس T را بسازیم، که از آنجایی که نمودار شامل چرخه است، به شکل (1.42) خواهد بود:

مقدار عنصر ماتریس T با شماره (0، 4) برابر است با احتمال عملکرد بدون خطا کل مجموعه نرم افزار، با در نظر گرفتن تمام توالی های ممکن فراخوانی به ماژول های نرم افزار جداگانه.

بیایید ماتریس را بنویسیم:

مقدار عنصر ماتریس T را با عدد (0، 4) با استفاده از فرمول (1.43)، محاسبه مکمل جبری عنصر (4،0) ماتریس، برابر و تعیین کننده اصلی ماتریس، پیدا می کنیم. ، برابر با.

ما به دست می آوریم که مقدار عنصر ماتریس T با عدد (0، 4) و در نتیجه، احتمال عملکرد بدون خطا کل مجموعه نرم افزار برابر است.

1.3.4 ویژگی های نرم افزار شی گرا

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

...

اسناد مشابه

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

چکیده، اضافه شده در 2010/12/21


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

پایان نامه، اضافه شده 06/01/2010


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

ارائه، اضافه شده در 2014/04/30


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

کار دوره، اضافه شده در 2013/07/02


قابلیت اطمینان یک سیستم کنترل به عنوان ترکیبی از قابلیت اطمینان ابزار فنی، کامپیوتر، نرم افزار و پرسنل. محاسبه قابلیت اطمینان سیستم های فنی، انواع خرابی سیستم های کنترل اتوماتیک و سیستم های کنترل اتوماتیک، افزایش اطمینان و علل خرابی سیستم های کنترل اتوماتیک.

دوره سخنرانی ها، اضافه شده در 2008/05/27


نرم افزار به عنوان یک محصول ویژگی های اصلی کیفیت نرم افزار. مفاهیم اساسی و شاخص های قابلیت اطمینان نرم افزار. عوامل و روش های بی ثبات کننده برای اطمینان از قابلیت اطمینان عملکرد نرم افزار.

سخنرانی، اضافه شده در 2014/03/22


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

ارائه، اضافه شده در 10/16/2013


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

پایان نامه، اضافه شده در 1393/04/18


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

ارائه، اضافه شده در 2014/03/22


روش مدل سازی جبری احتمالی. نمونه هایی از تعیین ویژگی های احتمالی یک سیستم پیچیده عملکردی به شکل نمادین. دریافت و افزودن داده ها از سرور سازمان بهداشت جهانی. ساختار پایگاه داده

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

1) فناوری ایجاد نرم افزار به طور جدی از فناوری تولید پایه عنصر عقب است.

2) از نظر ماهیت، نرم افزار پیچیده تر از سخت افزار است (حجم برنامه ها برای سیستم های مدرن 10 6 - 10 8 یا بیشتر دستورات یا کلمات اطلاعاتی تخمین زده می شود).

3) الزامات نرم افزار در طول چرخه عمر آن، که به 15-20 سال افزایش یافته است، به طور قابل توجهی تغییر می کند.

4) بر خلاف مجموعه ای از ابزارهای فنی، محاسبه عملکرد قابل دستیابی در مرحله طراحی برای نرم افزار بسیار دشوار است، علاوه بر این، تغییرات دائمی در تجهیزات انجام می شود.

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

تقریباً می توان فرض کرد که نسبت تعداد خطاهای یک برنامه به تعداد کل دستورات موجود در آن در محدوده 0.25 تا 10 در هر 1000 دستور قرار دارد. این بدان معناست که در نرم افزارهایی با حجم 0.5 میلیون دستور ممکن است 125 تا 5000 خطا وجود داشته باشد. علاوه بر این، چنین ارزیابی خوش بینانه است. شناسایی خطاها و اصلاح آنها فرآیندی چند مرحله ای (مطابق با مراحل "عمر" نرم افزار)، زمان بر و پرهزینه است. همانطور که به مراحل بعدی توسعه نرم افزار می رویم، هزینه یک خطا افزایش می یابد، جدول این روند رشد را نشان می دهد:

جدول 2.1 - "قیمت" تقریبی یک خطای نرم افزار در مراحل مختلف عمر نرم افزار

هزینه خطایی که در این مراحل شناسایی نشده است می تواند کاملا غیرقابل پیش بینی و هنگفت باشد. شاهد این امر حوادثی است که با فضاپیماها رخ می دهد که بسیاری از آنها به دلیل خطاهای نرم افزاری از بین رفته اند.

2.3.1 تعاریف اساسی تئوری قابلیت اطمینان نرم افزار

اصطلاحات اصلی مورد استفاده در تئوری قابلیت اطمینان نرم افزار عبارتند از: خطای نرم افزار؛ تعداد خطاهای باقی مانده در برنامه که بیشتر به کاربر منتقل می شود. شدت تشخیص خطا (عملکرد ریسک)؛ "اجرای" برنامه؛ شکست برنامه؛ احتمال عملکرد بدون خرابی نرم افزار

مشکل اصلی در تعریف اصطلاح "اشکال نرم افزار" این است که یک اشکال در یک برنامه ذاتاً تابعی از خود برنامه و آنچه کاربر از آن انتظار دارد است. ما تظاهرات اصلی را که می توان به عنوان خطا شناسایی کرد فهرست می کنیم:

ظاهر شدن یک عملوند یا عملیات اشتباه در حین برنامه نویسی.

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

خطاهای محاسباتی (به عنوان مثال، سرریز)؛

نرم افزار را برای بهبود تجربه کاربری خود رفع می کند.

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

اجازه دهید نرخ تشخیص خطا یا تابع ریسک را معرفی کنیم r(t)،که با نسبت تعداد خطاهای کشف شده به مدت زمانی که این خطاها شناسایی شده اند تعیین می شود. برای شدت تشخیص خطا، تمام فرمول هایی که از تئوری قابلیت اطمینان شناخته شده اند معتبر هستند. برخلاف نرخ شکست، تابع ریسک با شناسایی و اصلاح خطاها کاهش می یابد. اگر فرض کنیم که بین لحظه‌های تشخیص و تصحیح خطاها ثابت بماند و در لحظه تشخیص خطاها به تدریج با یک مقدار ثابت کاهش یابد، برای سادگی بهتر است فرض کنیم که متناسب با تعداد خطاهای باقی‌مانده است.

, (2.80)

تعداد خطاهای شناسایی شده در این مرحله کجاست.

معادله افتراق (2.80) با توجه به زمانی که به دست می آوریم

که در آن - تابع ریسک است. اگر معادله دیفرانسیل را حل کنیم ، با شرایط اولیه پس از آن

(2.81)

بیایید نشان دهیم سپس معادله (2.81) را می توان به صورت بازنویسی کرد

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

(2.83)

محاسبه رگرسیون نمایی عبارات زیر را برای ضرایب آن به دست می دهد

(2.84)

(2.85)

برنامه برای محاسبه رگرسیون نمایی در زیر در 2.3.3 آورده شده است.

با شدت خاص تشخیص خطای نرم افزار، تابع زمان زیر را درک خواهیم کرد:

(2.87)

تعداد خطاهای نرم افزاری که با زمان t تصحیح شده اند کجاست. - تعداد دستورات در برنامه تقریباً می توان چنین فرض کرد

اینجا - عمق بیت فرمان؛ - محدوده برنامه Halstead، چه اتفاقی خواهد افتاد؛ در- تعداد خطاهای باقی مانده در نرم افزار در زمان t = 0; به– ضریب تناسب مقادیر درو بهناشناخته هستند.

بیایید دو دوره از اشکال زدایی برنامه را در نظر بگیریم T 1و T 2به گونه ای که T 1 < T 2. اجازه دهید n 1و n 2به ترتیب، تعداد خطاهای نرم افزاری شناسایی شده در هر دوره. سپس برای میانگین زمان عملیات بدون خطا (بدون شکست) در هر دوره، عبارات زیر را می توان نوشت:

(2.89)

(2.90)

با تقسیم تساوی اول بر دومی، پس از تبدیل ها می توانیم به دست آوریم:

(2.91)

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

. (2.92)

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

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

وارد کردن ترکیب احتمالی E iداده های ورودی؛

انجام محاسبات با استفاده از برنامه ای که با نتیجه به پایان می رسد F(Ei)یا امتناع

برای مجموعه خاصی از داده های ورودی، انحراف نتیجه از مقدار مشخص شده است F`(Ei)،به دست آمده در نتیجه اجرای برنامه در محدوده قابل قبول است

(2.93)

و برای تمام E i های دیگر که زیرمجموعه را تشکیل می دهند، اجرای برنامه نتیجه قابل قبولی ارائه نمی دهد، یعنی.

> (2.94)

رویدادهایی که با نابرابری (2.94) توصیف می شوند، خرابی برنامه نامیده می شوند.

روش‌شناسی برای ارزیابی آماری احتمال خرابی نرم‌افزار در طول nاجرای مستقل یک برنامه سنتی است و به طور رسمی شامل ارزیابی است

(2.95)

جایی که اگر نابرابری (2.93) برآورده شود؛ اگر نابرابری (2.94) ارضا شود.

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

اجرای چنین تعدادی از اجراها در عمل دشوار است و افراد معمولاً به روش های دیگری برای تخمین احتمال خرابی نرم افزار روی می آورند. با دانستن احتمال خرابی، به راحتی می توان احتمال عملکرد بدون خرابی نرم افزار را محاسبه کرد.

برای بررسی پایایی نرم افزار از روش های آزمون فرضیه های آماری و به ویژه تحلیل والد متوالی استفاده می شود. اجازه دهید متغیر دوگانه را با مقدار مقایسه کنیم 1 ، اگر (2.94) ارضا شود، و مقدار 0 اگر (2.93) ارضا شود. سپس نتیجه اجراها نمونه ای از متغیرهای تصادفی را تشکیل می دهد اجازه دهید این احتمال را نشان دهیم که، i.e. برنامه مانند P از کار می افتد. و احتمال P 0 است. که مقدار 0 را می گیرد و برنامه در حال کار است. سپس انتخاب ارزش

P 0 = 0.99 به این معنی است که در یک سری از 100 اجرا، به طور متوسط، یک شکست ممکن است رخ دهد.

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

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

برای هر برنامه ای می توانید تعریف کنید:

تعداد عملیات های مختلف، به عنوان مثال و غیره؛

تعداد کل همه عملوندها (متغیرها و ثابت ها)؛

تعداد کل همه عملیات

تعداد کل همه عملوندها

سپس فرهنگ لغت برنامه می باشد و طول اجرای آن برابر است با طول برنامه در این حالت برابر است

و حجم برنامه (2.97)

حجم برنامه بالقوه

که در آن حداقل تعداد عملوندهای مختلف (به طور دقیق تر، تعداد مقادیر ورودی و خروجی مستقل) است.

حجم بالقوه حداقل حجم ممکن یک الگوریتم معین است. سطح برنامه Lاز طریق نسبت حجم بالقوه به حجم برنامه تعیین می شود

کار برنامه نویسی Eبه عنوان تعداد کل تفاوت های ذهنی اولیه بین عناصر لازم برای تولید یک برنامه تخمین زده می شود:

سطح زبان به شما امکان می دهد مزیت یک زبان سطح بالاتر را در مقایسه با زبان قبلی خود ارزیابی کنید و توسط عبارت تعیین می شود.

که به شما امکان می دهد ویژگی ها را به گونه ای متفاوت بیان کنید Eو V:

جدول 2.2 مقادیر عددی زبان های سطوح مختلف را نشان می دهد.

جدول 2.2 - مقادیر عددی سطح زبان

پیچیدگی توسعه نرم افزار با فرمول تعیین می شود

مردم - ساعت؛ (2.104)

پارامتر Stroud کجاست، یعنی. زمانی که مغز انسان طول می کشد تا تفاوت قابل توجهی بین دو عنصر را تشخیص دهد، بین 5 تا 20 تفاوت قابل توجه در ثانیه تخمین زده می شود.

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

عامل تناسب بابر اساس ملاحظات زیر تعیین می شود. مطابق با قانون تجربی D. Miller "7 2" برای ما آن را تعیین می کنیم و برای زبان انگلیسی با در نظر گرفتن (2.100) به دست می آوریم

که به ما امکان می دهد ضریب را تخمین بزنیم باچگونه

با این حال، برای زبان های سطح پایین تر تخمین زدن صحیح تر است با، با استفاده از یک عبارت کلی تر

که، به ویژه، برای اسمبلر معنی می دهد بنابراین،

(2.108)

یا به طور کلی تر

مقادیر و را می توان از نتایج تجزیه و تحلیل نرم افزار یا به طور غیرمستقیم با حل معادلات Halstead تعیین کرد، در صورتی که مقادیر و مشخص باشند:

(2.110)

2.3.2 روش برای تخمین تعداد خطاهای باقی مانده در یک برنامه

ارزیابی تعداد احتمالی خطاها در نرم افزار قبل از شروع توسعه برنامه می تواند با محاسبه تعداد کمیت های ورودی و خروجی مستقل، حجم بالقوه برنامه و تعداد احتمالی خطاهای موجود در آن انجام شود. بیایید مثال هایی از تجزیه و تحلیل داده های ورودی و خروجی ارائه دهیم.

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

در مجموع چهل مقدار ورودی وجود دارد. چهار مقدار خروجی برای هر کانال اطلاعاتی (سه مختصات مکانی به اضافه زمان) وجود خواهد داشت. در مجموع 12 متغیر مستقل

راه حل.

حجم بالقوه برنامه است

و تعداد خطاهای احتمالی در نرم افزار برابر است

مثال 2.تعیین ویژگی های نرم افزار ایستگاه فضایی رزمی (CS) سیستم دفاع موشکی (ABM) از نوع ابتکار دفاع استراتژیک ریگان رئیس جمهور ایالات متحده. BKS باید طوری طراحی شود که حدود 1000 هدف را از فاصله 400 کیلومتری رهگیری کند.

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

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

مقادیر خروجی برنامه مختصات زاویه ای اهداف و فاصله تا آنها است. برای 20 هدف تعداد مقادیر خروجی است

بنابراین،

که به حجم بالقوه برنامه مقداری برابر با

محاسبات نشان می دهد که برای ایجاد چنین نرم افزار حجیمی حدود 10 12 نفر زمان نیاز است. - ساعت تعداد احتمالی خطا در این نرم افزار غول پیکر برای زبان های سطوح مختلف برابر است با:

رفع چنین تعداد زیادی از خطاها می تواند بسیار بیشتر از ایجاد خود نرم افزار طول بکشد. بنابراین، توسعه نرم افزارهایی با این حجم زیاد مشکوک است.

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

این مقدار شامل تعداد دستورات، سیستم فرمان استفاده شده و تعداد زیرروال های فردی است. نرم افزار نمونه از 45 عبارت مختلف استفاده می کرد که تعداد زیر روال ها 157 بود.

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

82 + 334 + 280 + 256 = 952.

مقادیر بدست آمده را می توان با مقادیر محاسبه شده مقایسه کرد که از حل معادلات هالستد برای

در نتیجه تصمیم این مقادیر را می توان قابل قبول در نظر گرفت (تفاوت با نرم افزار واقعی 11.0٪ و 10.5٪ است).

طول برنامه را محاسبه کنید

و محدوده برنامه را مشخص کنید

برآورد به روز شده تعداد خطاهای ارسال شده به نرم افزار برابر است با:

تخمین با تخمین قبلی = 168 تنها 12٪ متفاوت است و به معنای آن به واقعیت نزدیکتر است.

2.3.3 روش محاسبه شدت تشخیص خطا بسته به زمان عملیاتی برنامه

در فرآیند اشکال زدایی پیچیده، نرم افزار به منظور اجرای توابع از دست رفته و اصلاح خطاهای شناسایی شده در یک برنامه از قبل اجرا شده اصلاح می شود. چنین تغییراتی معمولاً در یک گزارش تصحیح ویژه ثبت می شود که تاریخ و معنایی اصلاح را نشان می دهد. به عنوان مثال، نرم افزار را از مثال 1 در نظر بگیرید. داده های اولیه نتایج اشکال زدایی جامع این نرم افزار در یک دوره تقریباً دو ساله است. تعداد خطاهای شناسایی شده به صورت ماهانه ثبت می شود، بنابراین میزان تشخیص خطا دارای اندازه "تعداد خطا در ماه" است. مقادیر نرخ تشخیص خطا برای 20 ماه در جدول زیر نشان داده شده است. جدول 2.3 - مقادیر شدت تشخیص خطا

Δt i
r(t i)
Δt i
r(t i)

با استفاده از تقریب نمایی، این تعداد خطاهای باقی مانده را به دست می دهد.

تقریب نمایی نرخ تشخیص خطا را می توان برای پیش بینی تعداد خطاهای باقیمانده استفاده کرد اگر میزان تشخیص خطا از مدتی قبل تعیین شود، مثلاً یک چهارم.

جدول 2.4 - نرخ تشخیص خطا برای سه ماهه پیش رو

Δt i
r(t i)

2.3.4 ارزیابی آماری احتمال عملیات بدون خرابی

نرم افزار

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

پذیرش یک برنامه غیرقابل اعتماد تنها زمانی تصمیم اشتباه تلقی می شود و در صورتی که رد یک برنامه قابل اعتماد اشتباه است. پس از تنظیم مقادیر احتمال P`و P``خطر قابل قبول تصمیم گیری اشتباه به حدی است که احتمال خطای نوع I، یعنی. رد یک برنامه قابل اعتماد نباید از α = Ver تجاوز کند و احتمال خطای نوع دوم، یعنی. پذیرش یک برنامه غیرقابل اعتماد نباید از β = Ver تجاوز کند. مقادیر α و β بر اساس یک مصالحه معقول قبل از شروع آزمایش تخصیص داده می شوند، زیرا با کاهش آنها، حجم آزمایش افزایش می یابد.

ماهیت تحلیل فرضیه های متوالی N 0 (P = P 0)شامل آزمون دو فرضیه رقیب است Н`(P = P`)و H`` (P = P``).در اینجا، تحت احتمال عملکرد بدون خرابی نرم افزار P(m)درک احتمال به دست آوردن نمونه ای که در آن برای عناصر P`

سپس

اگر فرضیه H درست باشد، پس

به طور مشابه، اگر فرضیه H`` درست باشد، پس

بیایید یک نسبت "احتمال" ایجاد کنیم:

(2.114)

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

(2.115)

اگر در مرحله متر پس نرم افزار قابل اعتماد نیست. چه می شود اگر سپس نرم افزار را می توان به عنوان قابل اعتماد پذیرفت.

فیس بوک

توییتر

VKontakte

+Google

وای فای