‫فصل هفتم‪:‬توسعه نرم‬
‫افزار‬
‫درس آداب فناوری اطالعات‪-‬دانشکده مهندس ی کامپیوتر‪-‬دانشگاه صنعتی شریف‬
‫راهبرد های مهندس ی نرم افزار های با کیفیت‬
‫‪ ‬اجرای سریع و و کارآمد‬
‫‪ ‬عمل کردن به صورت امن و قابل اتکا‬
‫‪ ‬مبحث کیفیت در موارد زیر ضروری تر به نظر می آید ‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫کنترل حمل و نقل هوایی‬
‫نیروی هسته ای‬
‫امنیت وسائل نقلیه‬
‫مسائل دفاعی‬
‫راهبرد های مهندس ی نرم افزار با کیفیت(‪)2‬‬
‫‪ ‬نقص و حفره در نرم افزار‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫می تواند سیستم را از رفع نیاز های اساس ی کاربر باز دارد‪.‬‬
‫این تاثیر می تواند کم اهمیت یا بسیار پر خطر باشد‪.‬‬
‫می تواند آشکار باشد یا این که پنهان و غیر قابل تشخیص باشد‪.‬‬
‫‪ ‬کیفیت نرم افزار ‪:‬‬
‫‪‬‬
‫درجه ای از کیفیت که در آن درجه نرم افزار انتظارات کاربران را فراهم و‬
‫برآورده می نماید‪.‬‬
‫مدیریت کیفیت‬
‫‪ ‬مدیریت کیفیت ‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫تعریف‪،‬اندازه گیری و بهبود کیفیت پروسه تولید و همچنین محصوالت تولید‬
‫شده‬
‫تحویل دادنی ها می توانند گام مهمی در مدیریت فرآیند مدیریت کیفیت ایفا‬
‫نمایند‪.‬‬
‫تحویل دادنی ها محصوالتی هستند نظیر ‪:‬‬
‫‪ ‬بیان نیازمندی ها‬
‫‪ ‬فلوچارت ها‬
‫‪ ‬مستندسازی ها‬
‫کیفیت نرم افزار‬
‫‪‬‬
‫‪‬‬
‫مهم ترین علل کیفیت ضعیف یک محصول نرم افزاری می تواند عوامل زیر را‬
‫در بر گیرد ‪:‬‬
‫‪ ‬بسیاری از تولید کنندگان نمی دانند که چگونه می توان کیفیت نرم افزار را از‬
‫نقطه شروع پروژه لحاظ نمود‪.‬‬
‫‪ ‬بسیاری از تولید کنندگان زمان کافی برای توجه به این مورد را ندارند‪.‬‬
‫تولید کنندگان باید ‪:‬‬
‫‪ ‬قواعد مهندس ی نرم افزار را به صورت دقیق و جدی دنبال نمایند‪.‬‬
‫‪ ‬از اشتباهات گذشته درس گیرند‪.‬‬
‫‪ ‬محیط اجرایی سامانه تولیدی را بشناسند‪.‬‬
‫مسئولیت کاالی نرم افزاری‬
‫‪‬‬
‫مسئولیت کاال ‪:‬‬
‫‪ ‬مسئولیت تولید کنندگان ‪،‬فروشندگان و سایرین در قبال صدماتی که ناش ی از یک‬
‫محصول معیوب است را گویند‪.‬‬
‫‪‬‬
‫مسئولیت شدید ‪:‬‬
‫‪ ‬مسئولیت کاال را گویند صرف نظر از آن که عیب مورد نظر به صورت عمدی یا‬
‫تصادفی رخ داده شود‪.‬‬
‫‪ ‬وقتی کاالیی مسئولیت شدید دارد هیچ نیازی نیست که در دادگاه نشان داده شود‬
‫که اتفاق از روی عمد بوده است‪.‬چه عمدی و چه سهوی فرد مسئول محکوم‬
‫است‪.‬‬
‫بد ارائه دادن عمدی‬
‫‪ ‬مواقعی که فروشندگان و توزیع کنندگان محصول اقدام به معرفی‬
‫نادرست محصول به منظور جلب مشتری می نمایند‪.‬‬
‫‪ ‬این رفتار غیر اخالقی می تواند به عناوین گوناگون صورت پذیرد ‪:‬‬
‫‪ ‬تبلیغات‬
‫‪ ‬نظرات نادرست‬
‫‪ ‬برچسب های نادرست بر روی محصول‬
‫فراروش تولید نرم افزار‬
‫‪ ‬رویه اثبات شده و استاندارد در تولید نرم افزار‬
‫‪ ‬پایش شده و دارای ترتیب خاص‬
‫‪ ‬تعریف فعالیت ها در هر مرحله این ترتیب‬
‫‪ ‬تعریف اشخاص مربوطه در هر مرحله این ترتیب‬
‫‪ ‬شامل توصیه ها و بهترین تجارب موجود‬
‫آزمون نرم افزار‬
‫‪‬به منظور اطمینان از عدم وجود حفره در نرم افزار انجام می‬
‫شود‪.‬‬
‫‪‬آزمون جعبه سیاه ‪ :‬آزمون گران هیچ گونه اطالعی از کدی که‬
‫دارند آزمون می کنند ندارند‪.‬‬
‫‪‬آزمون جعبه سفید ‪ :‬آزمون مبتنی بر تحلیل کد و نظریه گراف‬
‫برای افزایش اطمینان از آزمون کل کد انجام می شود‪.‬‬
‫آزمون نرم افزار‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫تحلیل ایستا ‪ :‬جست و جو برای یافتن الگو های مولد خطر در کد مورد آزمون‬
‫تحلیل یک پارچه ‪ :‬تحلیل کل سامانه به صورت واحد بعد از تحلیل ماژول های‬
‫آن به صورت مجزا‬
‫تحلیل سامانه‪:‬‬
‫‪ ‬اطمینان نهایی از درست بودن سامانه مورد طراحی‬
‫‪ ‬تحلیل کل سامانه به صورت واحد بعد از اتصال اجرای اصلی سامانه‬
‫‪‬‬
‫تحلیل پذیرش کاربر ‪:‬‬
‫‪ ‬این آزمون به کمک کاربران انجام می شود و به منظور اطمینان از این مورد است‬
‫که سامانه خواسته کاربران را بر آورده می کند‪.‬‬
‫مسائل کلیدی در تولید نرم افزار‬
‫‪ ‬تصمیم گیری های اخالقی سازمان از قبیل تزاحم کیفیت و هزینه‬
‫‪،‬آسانی استفاده و زمان آماده شده محصول برای بازار‬
‫‪ ‬سامانه های بحرانی امنیت‪:‬‬
‫‪ ‬سامانه هایی که هر گونه شکست در آن ها می تواند منجر به حادثه‬
‫و مرگ شود‪.‬‬
‫‪ ‬نیروگاه های اتمی‬
‫‪ ‬مراکز درمانی‬
‫سامانه های بحرانی امنیت‬
‫‪‬‬
‫‪‬‬
‫مهندس امنیت پروژه ‪ :‬فردی که مسئولیت صریح وی امنیت سامانه می باشد‪.‬‬
‫استفاده از روش های ثبت ماوقع ‪ logging‬و نظارت ‪monitoring‬‬
‫‪ ‬دنبال کردن خطرات از آغاز تا پایان پروژه‬
‫‪N version programming‬‬
‫برنامه سازی چند نسخه ای‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫نوعی ساز و کار یافتن خطا در سامانه ها می باشد‪.‬‬
‫به این صورت که یک کد به صورت همزمان توسط دو یا چند برنامه نویس‬
‫نوشته و سامانه در چند نسخه اجرا می شود‪.‬‬
‫هر سامانه با الگوریتم متفاوتی که به نتایج یکسانی می انجامد اجرا می شود‪.‬‬
‫نتیجه حاصل از سامانه ها مقایسه می شود‪.‬‬
‫در صورت مشاهده تفاوت بین نتایج ساز و کار دیگری به منظور یافتن سامانه‬
‫ای که اشتباه جواب می دهد پیاده سازی می شود‪.‬‬
‫)‪N version programming(2‬‬
‫‪‬‬
‫احتمال آن که تمام گونه های یک سامانه با هم به یک نتیجه غلط برسند‬
‫ناچیز و تقریبا محال است‪.‬‬
‫اتکا پذیری و تعامل پذیری‬
‫‪ ‬اتکا پذیری ‪ :‬احتمال آن که یک مولفه یا سامانه بدون شکست در طی عمر‬
‫مفید خود فعالیت کند‪.‬‬
‫‪ ‬لحاظ کردن واسط انسانی ‪:‬‬
‫‪‬‬
‫‪‬‬
‫یکی از دشوار ترین مباحث در تامین امنیت و بی خطر بودن سامانه ها‬
‫طراحی ضعیف سامانه می تواند به گیج شدن کاربر در استفاده از آن و در‬
‫نتیجه خطرات مختلف بیانجامد‪.‬‬
‫‪ ‬طراحی ضعیف یک دستگاه چرخ گوشت‬
‫استاندارد کیفیت ‪ISO 9000‬‬
‫‪ ‬راهنمایی برای تامین کیفیت محصوالت‬
‫‪ ‬سازمان ها مورد آزمون یک سازمان خارجی قرار می گیرند پس کامال بی‬
‫طرفانه می تواند باشد‪.‬‬
‫‪ ‬نیازمندی ها ‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫وجود رویه برای تمام کار هایی که در سازمان انجام می شود‪.‬‬
‫پیروی از رویه‬
‫اثبات و اطمینان از این که دو مرحله قبل به خوبی در سازمان پیاده سازی می‬
‫شود‪.‬‬
‫تحلیل حالت و تاثیر شکست‬
‫‪ ‬تحلیل حالت و تاثیر شکست(‪)Failure mode and effect‬‬
‫عبارت است از فنی که به منظور ارزیابی اتکا پذیری سامانه و تعیین تاثیر‬
‫شکست سامانه و تجهیزات آن به کار می رود‪.‬‬
‫‪ ‬این شکست ها در رده های زیر طبقه بندی می شود ‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫تاثیر بر موفقیت پروژه‬
‫امنیت شخص ی‬
‫امنیت تجهیزات‬
‫امنیت مشتری‬
‫لیست پایش ی بهبود کیفیت‬
‫سوال‬
‫آیت مدیران و تیم پروژه در‬
‫استفاده از فراروش تولید‬
‫محصول آموزش دیده اند؟‬
‫آیا از هر دو شیوه آزمون جعبه‬
‫سفید و آزمون جعبه سیاه‬
‫استفاده شده است؟‬
‫آیا تالش جدیدی در حذف خطا‬
‫ها و باغلطهای سامانه انجام می‬
‫شود؟‬
‫آیا قضاوت بی طرفانه در سازمان‬
‫در مورد امن بودن محصول‬
‫تولید شده انجام می شود؟‬
‫بلی‬
‫خیر‬
‫مساله‬
‫‪ « ‬هزینه یافتن و بهبود حفره در نرم افزاری که در دست هزاران مشتری‬
‫هست ‪ 100‬مرتبه سخت تر از نرم افزاری است که هنوز وارد بازار نشده‬
‫است >>‬
‫جمله باال را تحلیل کرده و بگویید به نظر شما درست است یا خیر؟‬
‫منابع‬
 Ethics
in information technology ,
Reynolds , third edition , 2010.