فرآیند اقدامات اصلاحی ( بخش دوم )

تایید و اعتبار سنجی

پس از تکمیل این فصل ، می توانید:

– درک منظور از تأیید و اعتبار سنجی را بفهمید.

– فواید و هزینه های استفاده از تکنیک ها را درک کنید.

– روش ردیابی و مفید بودن آن را درک کنید؛

– درباره استاندارد و مدل های ieee 1012   و مدلهای مورد استفاده در صنعت اطلاعاتی کسب کنید.

– درک فرایندها و فعالیتهای

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

– یاد بگیرید که چگونه یک لیست چک و v را برای پروژه خود تهیه و استفاده کنید؛

– درک چگونگی نوشتن یک طرح  برای پروژه خود را درک کنید.

– در مورد ابزارهای  موجود ، اطلاعات کسب کنید.

– رابطه بین و تضمین کیفیت نرم افزار را درک کنید

مقدمه

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

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

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

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

– نرم افزار رفتارهای پیش بینی نشده ای دارد (خطرناک است) فراتر از آنچه در الزامات مشخص شده است.معرفی محصولات نوآورانه مرتبط با نرم افزار که شامل تعداد فزاینده ای از توابع هستند ، اغلب شامل افزایش تعداد واحد پردازش رایانه و اندازه نرم افزار است. به عنوان مثال ، در بخش خودرو بیش از 60 رایانه کوچک (واحد کنترل الکترونیکی با نام

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

تایید

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

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

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

نکته 2 برای ورود: از کلمه “معتبر” برای تعیین وضعیت مربوطه استفاده می شود.

نکته 3 برای ورود: شرایط استفاده برای اعتبار سنجی می تواند واقعی یا شبیه سازی شده باشد. ISO 9000 فرایند ارزیابی یک سیستم یا مؤلفه در طول یا در پایان فرآیند توسعه برای تعیین اینکه آیا شرایط مورد نیاز را برآورده می کند یا خیر. فرایند تهیه شواهدی مبنی بر اینکه سیستم ، نرم افزار ، یا سخت افزار و محصولات مرتبط با آن ، نیازهای اختصاص یافته به آن را در پایان هر فعالیت چرخه زندگی برآورده می کند ، مشکل درست را حل می کند (به عنوان مثال ، الگوی صحیح قوانین فیزیکی ، اجرای قوانین تجارت و از فرضیات مناسب سیستم استفاده کنید) و نیازهای کاربر را در نظر بگیرید. اعتبارسنجی از مجموعه ای از فعالیتهایی است که از ابتدای دوره چرخه عمر توسعه با اعتبارسنجی نیاز مشتری شروع می شود. کاربران نهایی یا نمایندگان آنها نیز رفتار محصول نرم افزار را در محیط هدف ، واقعی ، شبیه سازی شده یا کاغذ ارزیابی می کنند. اعتبارسنجی با اطمینان از كافی بودن و كامل بودن الزامات ، كمك می كند تا خطر ایجاد موارد اشتباه را به حداقل برساند. پس از آن ، اطمینان حاصل می شود که این الزامات معتبر در مرحله بعد ، خصوصاً مشخصات ، توسعه یافته اند. اعتبار سنجی همچنین اطمینان حاصل می کند که نرم افزار کاری را که باید انجام ندهد انجام نمی دهد. این به این معنی است که هیچ رفتار ناخواسته ای نباید از آن ناشی شود.

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

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

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

تفاوت بین تایید و اعتبار سنجی

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

مزایا و هزینه های vv

همانطور که در بالا اشاره کردیم، هدف V * V ایجاد کیفیت در نرم افزار در اوایل ساخت آن است و فقط در مرحله آزمایش سعی در رفع این مشکل ندارید. شکل 7.3 نمونه ای از فرآیندهای نرم افزاری را در یک شرکت آمریکایی که نقص ها در آن تزریق شده نشان می دهد. شکل نشان می دهد که درصد زیادی از نقص ها، تقریبا 70٪، حتی قبل از تولید هر خط کد تزریق می شود. بنابراین ضروری است که ما در چرخه عمر نرم افزار تکنیک هایی را در نظر بگیریم که امکان شناسایی و رفع زودهنگام این نقص ها را تا حد ممکن به هنگام ایجاد امکان پذیر می سازد. علاوه بر این، تکنیک های تشخیص خوب باعث کاهش هزینه های کاری مجدد همراه با اصلاح می شوند که دلیل مهم تأخیر در برنامه است. شکل 7.4 اثربخشی تشخیص نقص در یک شرکت آمریکایی را توصیف می کند. این نتایج از Northrop Grumman سرچشمه می گیرد که داده هایی را برای 14 سیستم جمع آوری کرده است که در آن 3418 نقص در طی 731 بررسی مشاهده شده است. این سیستم ها بین 25000 تا 500،000 خط کد داشتند و تیم های مربوطه بین 10 تا 120 توسعه دهنده را در اختیار داشتند. این مطالعه نشان می دهد که نه تنها امکان شناسایی خطاها بلکه از بین بردن آنها در همان مرحله ای که تولید شده است نیز وجود دارد. به عنوان مثال، شکل 7.3 نشان می دهد که 50٪ نقص هایی که در مرحله نیازتزریق می شوند وجود دارد. شکل 7.4 همچنین نشان می دهد که 96٪ از این نقص ها در همان مرحله حذف می شوند.

آنچه از این شکل می توان یاد گرفت این است که می توان درصد نقص تزریق شده را تخمین زد و درصد بالایی از آنها را کشف و تصحیح کرد به گونه ای که از مرحله به مرحله دیگر پخش نشوند. این فرآیند به عنوان فرایند مهار خطا نامگذاری شده است. بنابراین می توان در برنامه کیفیت پروژه ، معیارهای کمی کیفیت مربوط به اهداف رفع نقص در هر مرحله از پروژه را توصیف کرد. چرا اصلاح نقص در جایی که تزریق می شود مهم است؟ همانطور که در فصل 2 نشان داده شده است (شکل 2.2) ، یک هزینه ترکیبی از نقص وجود دارد که در فاز تزریق اصلاح نمی شود. به عنوان مثال ، نقصی كه در مرحله مونتاژ ایجاد می شود ، سه برابر بیشتر از رفع آن در مرحله قبل اصلاح می شود. برای رفع نقص در مرحله بعد (آزمایش و ادغام) هفت برابر بیشتر هزینه خواهد شد ، 50 برابر بیشتر در مرحله آزمایش ، 130 برابر بیشتر در مرحله ادغام و 100 برابر بیشتر در صورت عدم موفقیت برای مشتری و برای تعمیر در مرحله عملیاتی محصول انجام می‌شود. ما قادریم فقط بخش کوچکی از همه حالتهای ممکن سیستمهای پیچیده مبتنی بر نرم افزار را آزمایش کنیم. به عنوان مثال ، نرم افزاری که برای سیستم های جلوگیری از برخورد هواپیما استفاده می شود ، که در هر هواپیمای مدرن تعبیه شده است ، تقریباً شامل 1040 حالت است.

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

مدل های تجاری

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

 – سیستم های سفارشی که براساس قرارداد نوشته شده است: این سازمان با فروش خدمات توسعه نرم افزار متناسب برای مشتری فراهم شده است.

 – نرم افزار سفارشی نوشته شده در خانه: سازمان نرم افزاری را برای بهبود بهره وری سازمان (به عنوان مثال سازمان فعلی IT داخلی شما) توسعه می دهد.

– نرم افزار تجاری: این شرکت با توسعه و فروش نرم افزار به سازمان های دیگر (به عنوان مثال ، Oracle و SAP) سود می برد.

– نرم افزار بازار انبوه: این شرکت با تولید و فروش نرم افزار به مصرف کنندگان (به عنوان مثال ، مایکروسافت و Adobe) سود می برد.

– سیستم عامل تجاری و بازار انبوه: این شرکت با فروش نرم افزار در سخت افزار و سیستم های جاسازی شده (به عنوان مثال ، دوربین های دیجیتال ، سیستم ترمز خودرو ، موتورهای هواپیما) سود می برد. این مدل های تجاری به ما کمک می کنند تا خطرات مرتبط با هر وضعیت را درک کنیم.

استانداردها و مراحل:

 مهمترین استانداردها و مدل های فرآیندی که فرآیندها و عملکردهای مورد نیاز V * V را توصیف می کنند، در مرحله بعد ارائه می شوند:  برخی از استانداردها تا آنجا که توصیه می شود، برای نرم افزار مهم، از برخی زبان های برنامه نویسی اجتناب می شود. به عنوان مثال، یک استاندارد نرم افزاری کنترل راه آهن از برنامه نویسان استفاده می کند که از دستورالعمل برنامه نویسی \”GoTo\” استفاده کنند. در بخش بعدی، استاندارد IEEE 1012 توضیح داده می شود، سپس سایر استانداردها به طور خلاصه پوشش داده می شوند.

استاندارد vv و IEEE

این استاندارد برای تأیید و اعتبار سنجی سیستم و نرم افزاربرای دستیابی، تهیه، توسعه، بهره برداری و نگهداری سیستم ها، نرم افزارها و سخت افزارها کاربرد دارد. این استاندارد در مورد انواع چرخه های زندگی کاربرد دارد

دامنه ieee

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

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

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

– برآورده کردن استانداردها ، شیوه ها و کنوانسیون ها در طی مراحل چرخه زندگی.

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

– الزامات اختصاص یافته به آن را در پایان هر فعالیت چرخه زندگی برآورده می کند.

– حل مسئله صحیح (به عنوان مثال ، به طور صحیح قوانین جسمی را الگوبرداری کنید ، قوانین تجارت را به کار بگیرید و از فرضیات مناسب سیستم استفاده کنید)

– نیازهای کاربر و کاربر مورد نظر را برآورده سازد.

هدف IEEE

هدف این استاندارد انجام موارد زیر است:

 – ایجاد یک چارچوب مشترک برای همه فرآیندهای V* V، فعالیت ها و وظایف مربوط به پشتیبانی از سیستم، نرم افزار و فرآیندهای چرخه عمر سخت افزار.

– وظایف V * V، ورودی های مورد نیاز و خروجی های مورد نیاز را در هر فرآیند چرخه زندگی تعریف کنید.

– حداقل وظایف V * V مربوط به یک طرح یکپارچگی چهار سطح را مشخص کنید.

– محتوای برنامه V * V را تعریف کنید.

زمینه کاربرد ieee

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

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

– اپراتورها یا کاربران: تعیین می کند که سیستم وضعیت، وضعیت مناسب سیستم را به اپراتور، کاربر ارتباط می دهد و کلیه ورودی های اپراتور، کاربر را بطور صحیح پردازش می کند تا نتایج لازم را بدست آورد. برای ورودی های نادرست اپراتور / کاربر ، اطمینان حاصل کنید که سیستم از ورود به وضعیت خطرناک یا کنترل نشده محافظت می شود. تأیید کنید که خط مشی ها و رویه های اپراتور / کاربر (به عنوان مثال ، امنیت ، پروتکل های رابط ، نمایش داده ها و مفروضات سیستم) بطور مداوم در هر رابط مؤلفه استفاده و استفاده می شوند.

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

مزایای مورد انتظار V * V

مزایای مورد انتظار IEE است:

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

– بینش مدیریت نسبت به خطرات فرآیند و محصول را ارتقاء دهد.

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

– ارزیابی اولیه عملکرد

– ارائه شواهد عینی از انطباق برای حمایت از یک فرآیند صدور گواهینامه رسمی.

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

– پشتیبانی از فعالیتهای بهبود فرآیند.

سطح یکپارچگی IEEE 1012

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

سطح یکپارچگی یک مقدار، نمایانگر ویژگی های منحصر به فرد پروژه (به عنوان مثال ، پیچیدگی ، حساسیت ، خطر ، سطح ایمنی ، سطح امنیتی ، عملکرد مطلوب و قابلیت اطمینان) است که اهمیت سیستم ، نرم افزار یا سخت افزار را برای کاربر تعیین می کند.در جدول 7.1 تعریف IEEE 1012 از هر چهار سطح یکپارچگی و پیامدهای مورد انتظار آنها را نشان می دهد. جدول 7.2 نمونه ای از چهارچوب یکپارچگی چهار سطح را نشان می دهد که مفهوم ریسک را در نظر می گیرد. این مبتنی بر عواقب احتمالی و کاهش ریسک است. جدول 7.3 چارچوب مبتنی بر ریسک را با استفاده از چهار سطح صداقت و پیامدهای احتمالی آنها شرح داده شده در جداول 7.1 و 7.2 نشان می دهد. هر سلول از جدول 7.3 بر اساس پیامد احتمالی یک نقص و احتمال بروز آن در یک حالت عملیاتی که به خرابی کمک می کند ، سطح یکپارچگی را به وجود می آورد. برخی از سلولهای این جدول بیش از یک سطح یکپارچگی را منعکس می کنند. این نشانه ای است که می توان انتساب نهایی سطح صداقت توسط یک تیم پروژه را انتخاب کرد تا منعکس کننده الزامات سیستم و نیاز به کاهش ریسک باشد.

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

فعالیت های پیشنهادی vv

 در مورد نیازهای نرم افزاری [IEE 12] فعالیتهای پیشنهادی V * V برای نیازهای نرم افزاری، نیازهای نرم افزاری کاربردی و غیر کاربردی، الزامات رابط، شرایط لازم برای سیستم، امنیت و ایمنی، تعریف داده ها، اسناد کاربر، نصب، پذیرش، بهره برداری و نگهداری مداوم نرم افزار. برنامه آزمون * V * V همزمان با فعالیتهای V * V برای نیازهای نرم افزاری آغاز می شود و در بسیاری از فعالیت های V * V دیگر ادامه می یابد. اهداف فعالیتهای V * V در مورد نیازهای نرم افزاری، اطمینان از صحت، کامل، دقیق بودن، آزمایش و مطابق با نیازهای نرم افزار سیستم است. تلاش V * V برای نیازهای نرم افزاری، برای هر سطح صداقت، باید انجام شود.

– ارزیابی نیازها؛

– تجزیه و تحلیل رابط؛

– تجزیه و تحلیل قابلیت ردیابی.

– تحلیل انتقادی؛

– طرح آزمون واجد شرایط بودن نرم افزار VV؛

– طرح آزمون پذیرش نرم افزار VV؛

– تجزیه و تحلیل خطر؛

– تحلیل امنیتی؛

– تحلیل ریسک.

صلاحیت

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

جدول زیر، که در IEEE 1012 ارائه شده است، حداقل VV را نشان می دهد, که باید در هر سطح صداقت انجام شود. به عنوان مثال، در مورد اثری کار تجزیه و تحلیل توانایی، استاندارد \”X\” را توصیه می کند که این کار توصیه می شود (به عنوان مثال، برای سه سطح صداقت نشان داده شده در جدول 7.4). از طرف دیگر، تجزیه و تحلیل ایمنی ) فقط برای سطح 3 و 4 توصیه می شود.

مطابق با IEEE, IEC, ISO

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

پایان

جدید ترین ها

جدید ترین محصولات ما

محصولات بیشتر
ترجمه مقاله Strong structuration theory in accounting research ( ترجمه مقاله نظریه ساختار قوی در تحقیقات حسابداری )

ترجمه مقاله Strong structuration theory in accounting research ( ترجمه مقاله نظریه ساختار قوی...

10000 تومان

ترجمه مقاله Are There Any Volatility Spill Over Effects among Cryptocurrencies and Widely Traded Asset Classes (ترجمه مقاله  آیا کلاسهای دارایی گسترده و معامله شده دارای اثرات ناپایداری هستند )

ترجمه مقاله Are There Any Volatility Spill Over Effects among Cryptocurrencies and Widely Traded...

10000 تومان

Capacity and Frequency Optimization of Wireless Backhaul Network Using Traffic Forecasting ( ظرفیت و بهینه سازی فرکانس شبکه بی سیم با استفاده از پیش بینی ترافیک )

Capacity and Frequency Optimization of Wireless Backhaul Network Using Traffic Forecasting ( ظرفیت و...

35000 تومان

Automatic  Coverage Based Neighbour Estimation System: A Cloud-Based Implementation ( سیستم تخمین همسایگان مبتنی بر پوشش خودکار: یک پیاده سازی مبتنی بر ابر )

Automatic Coverage Based Neighbour Estimation System: A Cloud-Based Implementation ( سیستم تخمین همسایگان مبتنی...

35000 تومان

An approach to measuring business-IT alignment maturity via DoDAF 2.0 (رویکردی برای اندازه گیری بلوغ تراز تجاری IT- از طریق DoDAF 2.0 )

An approach to measuring business-IT alignment maturity via DoDAF 2.0 (رویکردی برای اندازه گیری...

35000 تومان

Tehran Stock Exchange Prediction Using Sentiment Analysis of Online Textual Opinions ( پیش بینی بورس اوراق بهادار تهران با استفاده از تحلیل احساسات نظرات متنی آنلاین )

Tehran Stock Exchange Prediction Using Sentiment Analysis of Online Textual Opinions ( پیش بینی...

35000 تومان

Opinion Mining in Persian Language Using Supervised Algorithms ( استخراج نظرات به زبان فارسی با استفاده از الگوریتم های نظارت شده )

Opinion Mining in Persian Language Using Supervised Algorithms ( استخراج نظرات به زبان فارسی...

35000 تومان

ترجمه مقاله Mechanism of negative surface charge formation on biochar and its effect on the fixation of soil Cd ( ترجمه مقاله مکانیسم تشکیل بار منفی سطح بر روی بیوچار(کود حاصل از ضایعات گیاهی) و تأثیر آن بر روی ثابت شدن سی دی خاک )

ترجمه مقاله Mechanism of negative surface charge formation on biochar and its effect on...

10000 تومان

error: شما فقط اجازه مطالعه دارید
قیمت می خواهید؟ ما ارزانترین قیمت را ارائه می کنیم. کافیست فایل خود را یا از طریق منوی خدمات و سرویس ها => سفارش ترجمه ارسال کنید یا برای ما به آدرس research.moghimi@gmail.com ایمیل کنید یا در تلگرام و واتس آپ با شماره تلفن 09191732587 ارتباط بگیرید و ارزانترین قیمت ترجمه را از ما بخواهید
+