تاییدیه نرم‌افزاری شناخت‌محور

نویسنده اصلی این فصل

Wolfgang A. Halang

ریاست سیستم های مهندسی کامپیوتر و سیستم های همزمان

دانشکده مهندسی برق

FemUniversitfit

58084 هاگن

آلمان

مقدمه

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

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

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

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

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

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

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

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

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

امنیت

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

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

کنترل زمان واقعی

سیستمهای همزمان در پروسه های اتوماسیون و کنترلی به کار میروند که به طور فزاینده با برنامه های امنیتی سرو کار دارند. حالت اجرائی همزمان در استاندارد صنعتی آلمان DIN 44300 (1985) به عنوان حالت اجرائی یک سیستم کامپیوتری تعریف شده که در آن برنامه ها دائما برای پردازش اطلاعات ورودی آماده هستند ، همانگونه که نتایج این برنامه ها در دوره های زمانی از پیش تعیین شده در دسترس هستند . زمان دسترسی به اطلاعات میتواند به صورت تصادفی وبر مبنای برنامه های مختلف تعیین و مشخص شود . از این رو سیستمهای کامپیوتری همزمان در محیط های بزرگی که نیاز به همگام سازی پویا دارند جاسازی شده و به کار گرفته میشوند . بنابر این این سیستم ها اغلب مترادف با سیستم های جاسازی شده به شمار می آیند .

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

مشکلات ذاتی یک نرم‌افزار

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

شناخت امنیتی نرم‌افزار محور

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

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

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

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

سادگی به عنوان اصل هدایتگر

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

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

وقت آن رسیده است که جامعه کاربران کامپیوتر را به عنوان یک جامعه پنهان برای ایجاد و حفاظت از پیچیدگی مصنوعی نمایان کنیم (دایکسترا۱۹۸۹) این مورد به هیچ وجه برای به دست آوردن طرح‌های ساده آسان نیست، درمقابل (Biedeukopf(1994 بیان کرده است که:«راه حل های ساده، مشکل‌ترین راه حل ها هستند»؛ این راه‌حل‌ها نیاز به نو آوری زیاد و نفوذ فکری به مسایل دارد (biedeukopf 1994).

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

سادگی=از لحاظ فکری آسان واز لحاظ اقتصادی امکان پذیر

قابل پیش بینی بودن--+قابل اعتماد بودن

سادگی--=به سادگی قابل فهم بودن =قابل تایید بودن

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

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

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

" verum est quod valde dare distinct " تایید نرم افزاربه عنوان فر ایند شناخت

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

ارزیابی متد‌های تایید نرم‌افزار

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

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

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

در سوابق پژوهشی در این زمینه، تعداد زیادی از روش‌های تایید واعتبارسنجی نرم‌افزار گزارش شده است مقاله ی تحقیقی توسط (Mausenetal(1987، یک بررسی اجمالی خوبی را در رابطه با روش‌های شناخته شده‌ی آزمون نرم افزار را ارایه می‌دهد. منبع اطلاعاتی دیگر در این زمینه، کار اساسی انجام شده توسط (EWICSTC7(1985 می‌باشد. با این حال در اصل هیچ تکنیکی که بتواند تمام خطاهای نرم افزار را خودش تشخیص دهد وجود ندارد. بنابراین تکنیک‌ها باید همیشه ترکیبی مورد استفاده قرار گیرند .... یکی باید بین روش های آنالیزی ،استاتیک ودینامیک نرم‌افزار تمایز قائل شود.

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

آزمون شامل اجرای اجزاء نر‌م‌افزارها تحت شرایط خاص، ثبت نتایج و ارزیابی آنها در برابرانتظارات مربوطه می‌باشد. برای تألیف سیستماتیک روش های عمده‌ی آزمون نرم‌افزار ما به (trauboth(1993 مراجعه می‌کنیم.

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

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

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

1. آزمون بیانیه، که در آن هر جمله از جزء نرم‌افزار تحت آزمون حداقل یک بار اجرا شده است
2. آزمون شعبه که در آن هر نتیجه از هر نقطه تقسیم در جزءنرم افزار حداقل یک بار اجرا شده است
3. آزمون مسیر، که در آن هر مسیر در میان جزء نرم افزلر حداقل یک بار اجرا شده است

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

• گروه روش های تجزیه و تحلیل نرم‌افزار استاتیک شامل:
• بررسی و ممیزی
• بازرسی
• walk through
• اثبات صحت رسمی
• اجرای نمادین و
• ترجمه معکوس گوناگون می‌شود

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

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

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

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

همانطور که دربازبینی و بررسی‌های بالا شامل جلسات رسمی انجام شده، توضیح داده شد، مدیریت پروژه‌ها برای ارزیابی وضعیت پروژها.

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

حقیقت امر این است که دو روش inspections و walkthroughs جزو گسترده ترین روش‌ها برای بازبینی کدها هستند.

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

روش طراحی و بررسی کدها (inspections) در جایی مابین بررسی رسمی و (walkthroughs) غیر رسمی قرار می‌گیرد.

اینها ملاقات های رسمی هستند که در دو ناحیه از چرخه توسعه نرم‌افزار: تغییرات جزئیات طراحی و تغییرات پیاده سازی قرار می گیرند.

هدف از روش inspections تشخیص بسیاری از خطاهای ممکن در بررسی محصولات و دسترسی به میزان کارائی طراحان و برنامه نویسان می‌باشد. عضویت در این هیئت بررسی معمولا به چهار نفر محدود می شود:

1. رئیس هیئت بررسی: که وظیفه کنترل فعالیت ها را بر عهده دارد.
2. طراح نرم افزار: که کامپوننت‌های اولیه نرم‌افزار را توسعه داده است و شروع به طراحی و بررسی کدها می‌کند.
3. برنامه نویس: کسی که وظیفه برنامه‌نویسی کامپوننت ها را برعهده دارد.
4. تست کننده: کسی که مسئولیت تست کامپوننت‌ها را بر عهده دارد.

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

ساختار walkthroughs (جلسه بررسی که در آن یک مرحله از توسعه سیستم یا برنامه برای معرفی کردن خطاها مرور می شود.) نیز شباهت زیادی به بررسی گروهی از افراد که همدیگر را برای بررسی بخشی از کار ملاقات می‌کنند، دارد. اگرچه تکنیک walkthroughs به صورت غیر رسمی می‌باشد و هدف اصلی آن ارزیابی کار نمی‌باشد، بلکه ترجیحا برای کمک به طراح و یا برنامه‌نویس در پیداکردن بسیاری از خطاهای ممکن در پروژه افراد می‌باشد. نمایندگان مدیریت معمولا در چنین جلساتی شرکت نمی کنند ولی ممکن است افراد برای جلوگیری از هرگونه خطا درکار، به عنوان بحث آزاد، پروژه خود را برای آن ها ارائه کنند. جلسات walkthroughs می توانند برای بررسی خصوصیات نرم‌افزار، طراحی برنامه، کد ،تست طرح و یا تست نتایج و یا document سازی نرم افزار، سازماندهی شوند. برخلاف جلسات رسمی، اگرچه جلسات walkthrough به کامل شدن محصول نهایی رسیدگی نمی کنند اما با بخش کوچکی از آن سر و کار دارند. تعداد جلسات می‌تواند متناسب با هر مرحله از چرخه توسعه نرم‌افزار سازماندهی شود. ماجول های مورد بررسی توسط افراد ناظر تشابه زیادی به ماجول‌های مورد بررسی در جلسات رسمی بررسی نرم‌افزار دارد. کلمه "ساختار" استفاده شده برای نامگذاری این تکنیک معادل «به خوبی سازماندهی شده» می باشد. نشان می‌دهد که برای اطمینان از موفقیت باید از قبل مکانی مناسب را آماده ساخت. شرکت کنندگان باید قبل از تاریخ ملاقات، کپی ازموارد لازم برای بررسی را فراهم کرده باشند. تجربه نشان داده است که میزان موارد لازم برای بررسی نباید از صد خط کد برنامه تجاوز کند و یا بیش از پنج تا ده صفحه از مشخصات یا توضیحات نباشد. برای جلوگیری از بحث‌های طولانی مدت ، اعضای جلسات walkthrough باید به حداکثر شش نفر محدود شوند و طول جلسات متنهی به نیم ساعت حداکثر چهل و پنج دقیقه باشد. این ضروریست که شرکت کنندگان در جلسات، تمرکز خود به جای طراح و برنامه نویس، بر خود محصول معطوف نمایند. این کار باعث ایجاد فضایی دوستانه و صمیمی بین افراد تیم می‌شود.

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

سابقه مشخصات آغاز فرایند توسعه نرم افزار، برای مثال مشخصات مورد نیاز و جزئیات مشخصات مورد نیاز می تواند با توجه به وضعیت کنونی پروژه، تنها به روش های غیر ریاضی و غیر اتوماتیک مانند inspections و walkthroughs انجام شده توسط تیم های بازرسی انسانی و البته تحت نظر مدیران، مورد تایید قرار گیرند. تجربه حاکی از آن است که چیزی حدود 80% از خطاها در هر دوره از روش inspection قابل شناسایی هستند، به خصوص تایید مشخصات بزرگترین تلاش ؛ از آنجایی که غالبا به دلیل پیچیدگی و استفاده از زبان طبیعی، خطاها به آسانی می توانند در تمامی قسمت های پروژه‌های کامل گسترش یابند. مشخصات فنی باید در صورت امکان به صورت نیمه رسمی فرموله شوند، اینکار به گسترش درجه صحت آنها کمک می کند. جداول تصمیم گیری ابزارهای مناسبی برای این منظور هستند زیرا تمامی خاصیت های نمادهای رسمی را بدون به خطر انداختن درک عمومی، ارائه می دهند. این جداول اجازه شرح جریان کنترل منطقی زیر پروسس ها را با استفاده از وضعیت های درونی خود؛ می‌دهند. بنابراین امکان بررسی کامل را تسهیل می‌کنند.

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

البته بطور کلی و به صورت خاص در زمینه امنیت مرتبط با سیستم‌های اتوماسیون فاصله بسیار زیادی بین پژوهش‌های علمی و نیاز های کاربر و عمل بصورت صنعتی وجود دارد. با توجه به روش های رسمی که در سال 1992 توسط ناتو منعقد شد، موسسه مطلعات پیشرفته در زمان واقعی محاسبه کرد: "... با اینکه توضیحات رسمی با ارزش هستند ، ولی وضعیت این هنر هنوز تکامل نیافته است ، جایی که می توان از آنها بصورت گسترده استفاده کرد ، و بطور خاص گروهی از مردم که می توانند به توضیحات رسمی در مورد سیستم های غیر بدیهی اعتماد کنند، بسیار محدود است" (چه برسد به تعداد افرادی که به دستکاری این توضیحات برای افزایش صحت آنها دست بزنند)( Halang and Stoyenko, 1994) رویکرد رسمی دارای ضعف ها و اشکالاتی هستند و این دلیلیست مبنی از عدم استفاده عملی از آن.

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

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

توسعه این تکنیک برای صدور مجوز ایمنی برنامه های کامپیوتری هنوز در مرحله بسیار ابتدایی قرار دارد. ملاحظات ما تاکنون نشان داده اند که روش های غیر رسمی (بر پایه مفهوم ریاضی) تجزیه و تحلیل استاتیک (بررسی reviews، ممیزی audits، بازرسی inspections و walkthroughs) ذاتا فاقد دقت لازم برای تشخیص تمامی خطاهای موحود در بعضی از نرم افزار های مشخص، می‌باشند. از سویی دیگر روش های رسمی به طور باید و شاید مناسب نیستند زیرا در این زمینه اصلا انسان را به حساب نمی آورند. اخیرا برای اثبات اینکه یک برنامه بزرگ و جامع نیاز امنیت وابسته به سیستم اتوماسیون را بر آورده کند مثلا صحت کارکرد و دقت نتایج به همراه در نظر گرفتن خواسته های مقطعی و زمانی محیط ,تنها فن ترجمه معکوس میتواند تاییدی بر این نرم افزار باشد. (Krebs and Haspel,1984) که به طور مشترک توسط (Technischer Uberwachungsverein (TUV ارائه شده است Rheinland, Cologne, Gesellschaft ftir Reaktorsicherheit, Garching (هر دو در آلمان) و موسسه Energitechnikk, Halden, در نروژ، در پروژه آزمایشی نیروگاه هسته ای هالدن

این روش قابل توسعه است و به نظر می آید نه تنها موثرترین بلکه مناسبترین و عموما شناخته شده ترین روش(با مجوز مقامات) برای تایید برنامه ها می باشد.