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