نام نویسنده: فحميد مشرف
همکاران سیستم – Tim Gilb مى گويد : “اگر فعالانه به ريسک ها حمله نکنيد، بيدرنگ آنها حمله خواهند کرد”[1]. هر پروژه از هر نوع که باشد همواره در معرض ريسک هايى است که مى تواند مانع به انجام رسيدن آن شده و يا حداقل موجب تاخير آن شود. شناخت ريسک هاى يک پروژه و کاهش و يا حذف آنها يکى از مهمترين ضرورتهاى فراروى يک پروژه محسوب مى گردد. به راحتى مى توان مشاهده کرد که در پروژه هاى نرم افزارى جارى در کشور ما کمتر به اين مسئله دقت مى شود. اغلب بدون توجه به مخاطرات پيش رو، پروژه ها آغاز و پيگيرى مى شوند. کمترين نتيجه اين عدم توجه مواجه شدن با شکلات و موانعى پرهزينه است که گاه مى تواند به ناکامى يک پروژه منجر شود.
در تعريفى ساده ريسک عبارت از هر چيز ممکنى است که سد راه پيشرفت پروژه شده و باعث عدم موفقيت و يا حداقل تاخير آن گردد. کلمه ” ممکن است ” نشان از احتمال دارد. به بيان ديگر احتمال وقوع حالت خاصى در آينده پيش بينى مى گردد. بنا بر اين هر ريسک دو ويژگى مهم دارد: ميزان تاثير و احتمال وقوع.
توجه به ريسک ها در پروژه هاى نرم افزارى آن گونه که اغلب تصور مى شود تشريفاتى نبوده و اهميت آن به خصوص در آن است که مى تواند ميزان عدم تعين پروژه هاى نرم افزارى را به دليل ماهيت انتزاعى شان، تا حد قابل قبولى کاهش داده و سطحى از اطمينان را در روند پيشرفت پروژه فراهم آورد.
به خصوص از همان ابتداى پروژه و در تمامى فعاليتهاى آن لازم است ريسک هاى مهم تشخيص داده شده و اولويت بندى گردد و در گام بعد راههايى براى کاهش آنها پيش بينى شود. در پاسخ به اين سئوال که چرا بايد ريسک هاى مهم در همان ابتداى راه پروژه مشخص شده و مورد هدف قراگيرد بايد گفت که – براى مثال عدم توجه به ريسک ها در ابتداى پروژه مى تواند به معنى آن باشد که بالقوه روى معمارى معيوب و يا نيازهاى ناپخته و ناقصى سرمايه گذارى مى شود. چنين سرمايه گذارى در اقتصاد نرم افزار نتيجه اى جز ضرر و زيان ندارد.
به علاوه تعداد و اهميت يسک ها مستقيما روى فاصله ميان حداقل و حداکثر زمان پيش بينى شده پروژه نيز موثر است. به همين دليل در ارزيابى اندازه پروژه هاى نرم افزارى يکى از ضرورتهاى اصلى تعيين ريسک هاى آن محسوب مى شود. توجه به ريسک ها و کشف راههايى براى کاهش آنها، فعاليتى مداوم در طول پروژه محسوب شده و نبايد فراموش کرد که نا ديده انگاشتن آنها پروژه را با موانع جدى روبرو مى نمايد.
RUP فرآيندى ريسک محور
RUP به عنوان روش توليد و توسعه تکرارى(Iterative) سيستم هاى نرم افزارى بر تشخيص، اولويت بندى و کاهش ريسک ها تاکيد بسيار دارد به گونه اى که اغلب از RUP با عنوان فرايندى ريسک محور [2] نام برده مى شود. هما گونه که در شکل ديده مى شود، يکى از اولين مزاياى روشهاى تکرارى و از جمله RUP آن است که امکان تشخيص ريسک هاى اصلى را از همان ابتداى پروژه فراهم نموده و بر کاهش آنها تاکيد دارد. در روشهاى تکرارى سرعت کاهش ريسک ها نيز در مقايسه با روشهاى سنتى آبشارى افزايش مى يابد و پروژه را از مواجه شدن با خطرات در گذشت زمان مصون مى دارد.
استراتژى هاى مختلفى براى برخورد با ريسک ها پيشنهاد شده که از مهمترين آنها مى توان “استراتژى کاهش ريسک” و “استراتژى اجتناب از ريسک ” نام برد.
بهترين استراتژى با توجه به شرايط خاص هر پروژه انتخاب مى شود. مهم آنست که نگاه ريسک محور در سازمانهاى توليد نرم افزار و اعضاى تيمهاى نرم افزارى به شکلى بسط يابد و همه گير شود که تمامى اعضاى تيم کشف، اولويت بندى و يافتن راهها براى کاهش ريسک ها را به عنوان بخشى از وظايف خود قلمداد نمايند و بطور خلاصه آنها را از همان ابتداى کار خود هدف قرار دهند. نيازى به تشريفات فراوان نيست و اين کار مى تواند کاملا بدون تشريفات صورت گيرد. گرچه در پروژه هاى بزرگ رعايت نظم و الگوى منسجمى براى مديريت ريسک ها توصيه مى گردد.
حال ببينيم RUP برخورد با ريسک ها را از همان ابتداى پروژه چگونه توصيه مى کند. در ابتداى هر چرخه تکرار، RUP توصيه مى کند ليستى از ريسک هاى مهم را آماده کرده و آنها را اولويت بندى نماييم ( معمولا بر اساس ميزان اهميت آنها و درصد احتمال وقوع آنها ) و در صورت امکان راه حلهاى کاهش و يا از ميان بردن آنها را نيز معين کرده و سپس تصميم گرفته شود که آيا لازم است در مورد کاهش آنها فعاليتى صورت گيرد.
از آنجا که ليست ريسک ها مى تواند طولانى باشد، معمولا در هر چرخه تکرار به 3 تا 5 ريسک مهم اشاره مى گردد. ريسک هايى که مى تواند بيشترين اثر را در ممانعت از رسيدن به اهداف هر چرخه داشته باشد و احتمال وقوع آنها هم قابل توجه باشد. براى مثال به ريسک هاى زير توجه کنيد:
ريسک 1 : با توجه به تجربيات گذشته اين نگرانى وجود دارد که اداره x درک درستى از نيازهاى سستم آن گونه که تحليلگران تشخيص داده اند نداشته و بنا بر اين نيازهاى سيستم بعد از تحويل نسخه بتاى سيستم دچار تغيير شود.
ريسک 2 : چگونگى ارتباط سيستم در حال توسعه را با سيستم مکانيزه موجود که از نيازهاى سيستم تشخيص داده شده مبهم است.
ريسک 3 : تيم تجربه اى در زمينه توليد سيستم در محيط Microsoft.NET يا با استفاده از Rational Rose ندارد.
ريسک 4: و …
همان طور که قبلا نيز گفته شد، شناخت و هدف قرار دادن ريسک ها بايد يکى از اولويت هاى همه اعضاى تيم در طول پروژه باشد. اما چگونه بايد از ليست مخاطرات استفاده نمود؟ طرح تشخيص و مقابله با ريسک ها با توجه به آنچه معمولا در هر مرحله تکار انجام مى شود، متفاوت است. عموما ريسک ها بايد از جنبه هاى مختلفى اداره شوند مثلا در تشخيص نيازها، در طراحى، در پياده سازى و در تست. بمنظور هدف قرار دادن ريسک ها و کاهش اثرات آنها در هر يک از جنبه هاى کار، طرحى کلى تهيه مى گردد و سپس به جزييات پرداخته مى شود. هدف هميشه آنست که تا حد امکان ريسک ها کاهش يابند. براى مثال براى کاهش مخاطراتى که در بالا به آن اشاره شد فعاليتهاى زير را مى توان در نظر گرفت:
· ريسک 1: زمانى که يوزکيس هاى مرتبط با اداره x توليد شدند، پروتوتايپ تصويرى (يا اجرايى) آن ساخته و به آن ضميمه شود. جلسه اى با اداره x سازمان داده شود و هر يوزکيس با استاده از پروتوتايپ در حضور کاربران مرور گردد. نتيجه بحث بايد بصورت صورت جلسه امضا شده اى مستند شود. در طول پروژه، هميشه اداره x در جريان پيشرفت کار قرار داده و نظر آنها در هرمرحله پس از ساخت اجزاى مختلف سيستم خواسته شود.
· ريسک 2: تيمى متشکل از يک يا دو تن از اعضاى با مهارت و اجرايى پروژه تشکيل شود تا بتوانند پروتوتايپ واقعى سيستم بگونه اى که بتواند ارتباط با سيستم موجود مکانيزه y را نشان دهد بسازند. پروتوتايپ ساخته شده ممکن است کنار گذاشته شود اما همين پروتوتايپ بايد اثبات کند که ايجاد ارتباط لازم ميان سيستم در حال توسعه با سيستم موجود عملا امکان پذير است. در طول پروژه بطور مداوم با انجام آزمون هاى لازم از صحت عملکرد ارتباط با سيستم y اطمينان حاصل گردد.
در اين مثال روش جايگزين ديگر مى تواند آن باشد که محدوده پروژه کوچک شده تا ضرورتى براى اين ارتباط اساسا وجود نداشته باشد. اين استراتژى “اجتناب از ريسک” ناميده شده و معمولا بسيار موثر است. توجه داشته باشيد که در ديگر مثالها استراتژى “کاهش ريسک” برگزيده شده است.
· ريسک 3 : دو نفر از اعضاى تيم براى آموزش Microsoft.NET و Rational Rose به کلاسهاى آموزشى اعزام شوند و بودجه لازم براى استخدام مشاور RUP به منظور هدايت و راهنمايى تيم در استفاده از Rational Rose براى دو روز در هفته در سه هفت اول و در فاز Elaboration در نظر گرفته شود. و يا يک کارشناس جديد که با محيط .NET به خوبى آشناست استخدام شود.
· ريسک 4: و …
به اين نکته نيز توجه کنيد که ليست ريسک ها مرتب تغيير مى کند. به همين علت اداره کردن ريسک هاى پروژه مبارزه اى دائمى تلقى مى شود. در هر مرحله از تکرار، تيم قادر خواهد بود که بعضى از آنها را کاهش داده و يا حذف کند در حالى که همزمان احتمال وقوع ريسک هاى ديگر رشد کرده و يا حتى ريسک هاى جديدى سربلند مى کنند. پس براى موفقيت در پروژه، ريسک ها را جدى بگيريم.
——————————————————————————–
[1] Gilb 1988 Tom Gilb. Principles of Software Engineering Management. Reading, MA: Addison-Wesley, 1988. [2] Risk Oriented退ܑ?
