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

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

هفت اصل مدیریت ریسک

موسسه SEI، هفت اصل را جهت مدیریت ریسک تعیین کرده است که چارچوبی را برای مدیریت موثر ریسک ایجاد می کنند. این اصول عبارتنداز:

► حفظ دیدگاهی سراسری : ریسک های نرم افزاری را در حوزه سیستمی ببینیم که قرار است نرم افزار در آن بعنوان یک مولفه قرار گیرد و مسائل کسب وکاری که قرار است نرم افزار آنها را رفع کند.

► اتخاذ دیدگاهی پیش بینانه : به ریسکهایی که ممکن است در آینده رخ دهند فکر کنیم و طرح های احتمالی را برای قابل مدیریت کردن آن وقایع وضع کنیم.

► ترغیب محاورات با افراد دیگر : اگر فردی یک ریسک محتمل را بیان کرد، آن را ناچیز نبینیم حتی اگر به صورتی غیررسمی بیان شده باشد. تمامی ذی نفعان و کاربران را برای پیشنهاد دادن ریسک ترغیب کنید.

► یکپارچه سازی : ملاحظات ریسک را با فرآیند نرم افزار یکپارچه کنید.

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

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

► ترغیب کار تیمی : حین انجام فعالیت های مدیریت ریسک، استعداد، مهارت و دانش تمامی ذی نفعان باید مورد استفاده قرار گیرد.

انواع ریسک ها

ریسک های پروژه : ریسکهایی هستند که طرح پروژه را به مخاطره می اندازند.

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

ریسک کسب وکار : ریسکهایی که ماندگاری نرم افزار در دست ساخت را تحلیل می کنند. این مدل ریسک ها معمولا پروژه و محصول را به خطر می اندازند.

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

ریسکهای قابل پیش بینی : ریسکهایی هستند که از تجارب گذشته قابل کشف هستند.

ریسکهای غیر قابل پیش بینی : این ریسک ها می توانند و گاهی حتما اتفاق می افتند اما تشخیص پیشاپیش آنها بسیار مشکل است.

تعیین تاثیر ریسک

عواملی که بر نتایج ریسک تاثیر می گذارند عباتنداز :

► محیط : نوع مشکلاتی که ایجاد میشوند.

► حوزه : ترکیبی است از شدت ریسک و اندازه پروژه ای که متاثر از ریسک است.

► مدت زمان : چه موقع و چقدر تاثیر ریسک حس می شود.

برای تعیین نتایج کلی یک ریسک مراحل زیر انجام میگیرد :

► تعیین احتمال وقوع متوسط هر ریسک

► تعیین تاثیر هر جزء ریسک براساس معیارهای از پیش تعریف شده

► تکمیل جدول ریسک و تحلیل نتایج

پالایش ریسک

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

تسکین، پایش و مدیرت ریسک

یک راهبرد موثر باید سه مبحث فوق را مورد توجه قرار دهد : 1) پیشگیری از ریسک،  2) پایش ریسک و 3) مدیریت و طرح ریزی احتمالات . پیشگیری یکی از بهترین راهبرد هاست که این کار از طریق ایجاد طراحی برای تسکین ریسک انجام می شود.

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

مدیریت ریسک فرض را بر این میگذارد که تلاش های تسکین ریسک موثر واقع نشده اند و ریسک به وقوع پیوسته است. اگر راهبرد تسکین ریسک به خوبی دنبال شده باشد تاثیر این ریسک قطعا کم خواهد شد.

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

طرح RMMM

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

معیارهای فرآیند و پروژه نرم افزاری

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

معیارهای فرآیند

نشانگرهای فرآیند، مدیران پروژه نرم افزاری را قادر میسازد تا :

► وضعیت پروژه را تعیین کنند

► ریسکهای محتمل را ردیابی کنند

► حوزه های مشکل زا را زود بیابند

► وظایف و جریان کاری را تنظیم کنند

► قابلیت تیم را برای کنترل کیفیت محصول ارزیابی کنند

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

► معیارهای خصوصی فرآیند : همانند نرخ خطای اشخاص یا ماژول ها که تنها فردی خاص یا تیم مرتبط آنها را میدانند.

► معیارهای عمومی فرآیند : که سازمان را قادر میسازند تا جهت بهبود فرآیند نرم افزاری، تغییراتی راهبردی را انجام دهند.

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

معیارهای پروژه

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

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

► برای کاهش زمانبندی توسعه با انجام تنظیمات مورد نیاز جهت جلوگیری از تغییرات و کاهش مسائل و مخاطرات احتمالی.

► تعیین کیفیت محصول به صورت مداوم و دستکاری راه حل فنی جهت بهبود کیفیت.

اندازه گیری نرم افزاری

 اندازه گیری نرم افزاری به دو دسته زیر تقسیم می شود:

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

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

با ترکیب معیارهای پروژه میتوان معیارهای فرآیندی ایجاد نمود که برای تمامیئ سازمان های نرم افزاری قابل ارائه باشد. معیارها را باید نرمال سازی کرد تا بتوان معیارهای مختلف را با هم مقایسه و یا ترکیب نمود. دو دسته معیار اندازه گرا و عملیات گرا که در ادامه آمده اند برای این منظور نرمال سازی شده اند.

معیارهای اندازه گرا

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

معیارهای عملیات گرا

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

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

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

► تعریف صریح فرآیند کیفیت نرم افزار

► ایجاد مجموعه وظایفی که به افزایش کیفیت نرم افزار کمک می کند.

► انجام کنترل کیفیت و فعالیت های تضمین کیفیت در هر پروژه نم افزاری

► استفاده از معیارهایی برای توسعه راهبرد های بهبود فرآیند نرم افزار و در نتیجه بهبود کیفیت محصول نهایی.

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

مفاهیم کنترل

قلب کنترل کیفیت، کنترل دگرگونی است. در حوزه مهندسی نرم افزار، کنترل دگرگونی به معنای کمینه کردن تفاوت بین تخمین نیاز به منابع، تیم پروژه ، ابزار و زمان تقویمی برای تکمیل پروژه با منابعی است که در عمل استفاده گردیده اند.

کیفیت

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

► کیفیت طراحی : به خصایصی برمیگردد که طراحان برای آن عنصر بیان می کنند.

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

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

کنترل کیفیت

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

تضمین کیفیت

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

تضمین کیفیت نرم افزار

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

فعالیت های SQA

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

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

بازنگری نرم افزار

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

تضمین آماری کیفیت نرم افزار

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

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

2. علت ایجاد هر نقصان ردیابی می شود.

3. با استفاده از اصل Pareto، علل نقصان های حیاتی پیدا میشوند.

4. سعی را بر رفع مشکلاتی میگذاریم که باعث نقصان های حیاتی شده اند.

سازماندهی تیم نرم افزاری

به همان اندازه که ساختارهایی برای توسعه نرم افزار وجود دارد ساختارهای سازمانی انسانی نیز وجود دارد. برای اینکه بتوان منابع انسانی را به پروژه ای که به n نفر و به مدت k سال نیاز دارد اختصاص دهیم گزینه های زیر وجود دارند:

1- n نفر را به m کار عملیاتی مختلف تخصیص دهیم به طوریکه کار ترکیبی نسبتا کمی اتفاق افتد. هماهنگی بین اینها از وظایف مدیر پروژه خواهد بود.

2- nنفر را به m کار عملیاتی مختلف تخصیص دهیم  بطوریکه در داخل، تیمهای غیر رسمی تشکیل گردند. هر تیم یک مدیر آنی را انتخاب می کند اما هماهنگی بین تیم ها از وظایف مدیر پروژه است

3- nنفر در t تیم سازماندهی میشوند. به هر تیم یک یا بیشتر از یک کار عملیاتی اختصاص می یابد. هر تیم یک ساختار خاص دارد و هماهنگی توسط خود تیم و مدیر پروژه انجام می شود.

قابلیت تولید گزینه سوم بیشتر از سایر گزینه هاست. بعبارت دیگر هر چه ساختار تیمها رسمی تر تعریف گردد بهتر است.

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

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

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

► متمرکز کنترل شده : حل مسأله در سطح بالا و هماهنگی داخل تیم توسط مدیر تیم انجام می شود. ارتباط بین مدیر و اعضای تیم بصورت عمودی است.

هفت عامل پروژه ای وجود دارند که هنگام برنامه ریزی برای سازماندهی تیم های نرم افزاری باید در نظر گرفته شوند:

► درجه سختی مساله ای که باید حل شود.

► اندازه برنامه های نتیجه شده برحسب تعداد خطوط یا نقاط عملیاتی

► مدت زمان حیات تیم.

► درجه ای که به آن اندازه میتوان مساله را به پیمانه های مختلف تقسیم نمود.

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

► میزان تعهد در تحویل به موقع

► درجه اجتماعی بودن مورد نیاز در پروژه

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

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

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

ساختارهای کنترل شده خطاهای کمتری را به نسبت ساختار دموکراتیک تولید می کنند.