ترجمه اول - بخش اول - فصل بیست

واسط انسانی : سوال از روش ها و عملکرد در تکنولوژی شناختی

J.P. Marsh, B. Gorayska and J.L. Mey (Editors)

فصل 20: تاییدیه نرم افزارهای شناخت گرا

Wolfgang A. Halang ریاست سیستم های مهندسی کامپیوتر و سیستم های همزمان دانشکده مهندسی برق FemUniversitfit 58084 هاگن آلمان

مقدمه

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

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

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

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

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

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

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

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

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

مفاهیم اساسی

امنیت

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

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

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

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

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

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

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

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

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

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

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

همانطور که در بالا بحث شد ، دستیابی به ایمنی مطلوب در سیستم های کامپیوتری تنها از طریق تعیین نیازها و اهداف در کمال سادگی و به عنوان اصل و مرکز بنیادی طراحی مناسب قابل دستیابی خواهد بود . الگوریتم Dijkstra به عنوان نمایان گر و سمبل مقابله با این پیچیدگی هاست : وقت آن رسیده است که جامعه کاربران کامپیوتر را به عنوان یک جامعه پنهان برای ایجاد و حفاظت از پیچیدگی مصنوعی نمایان کنیم (دایکسترا1989) این مورد به هیچ وجه برای به دست آوردن طرح های ساده آسان نیست،درمقابلBiedeukopf(1994) بیان کرده است که:"راه حل های ساده ،مشکل ترین راه حل ها هستند" این راه حل ها نیاز به نو آوری زیاد و نفوذ فکری به مسایل دارد (biedeukopf 1994)

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

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

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

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

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

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

این مورد، مفهوم قابل پیش بینی بودن را به وسیله ی ادای احترام به تلاش اقتصادی وفکری که نیازمند سرمایه گذاری برای ایجاد این خصوصیت برای سیستم مورد نظر است، ضمانت میکند.اگر این موضوع ساده باشد، می تواند به راحتی درک شود ،که گام اصلی در جهت رفتار درست آن در حس دکارت است (1641) " 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, در نروژ، در پروژه آزمایشی نیروگاه هسته ای هالدن این روش قابل توسعه است و به نظر می آید نه تنها موثرترین بلکه مناسبترین و عموما شناخته شده ترین روش(با مجوز مقامات) برای تایید برنامه ها می باشد.