جلسه سوم
مدیریت ریسک
مفهوم ریسک: نمیدانیم چه مشکلی رخ میدهد اما میدانیم 80% احتمال بروز مشکل وجود دارد. هر ریسکس نتیجهاش یک فقدان است. اگر احتمال آن 100% باشد دیگر ریسک نیست بلکه یک محدودیت برای پروژه است.
انواع ریسکها:
قابل پیشبینی: ریسکهایی که میتوان آنها را نام برد, تعیین میشوند.
غیر قابل پیشبینی: بستگی به مدیر یا فردی که ریسکها را تحلیل میکند دارد. آنچه که اصلا به آن فکر نکردیم.
مراحل تحلیل ریسک:
1) شناسایی ریسکها: ریسکهای پروژه را در یک چک لیست مینویسیم.
2) تعیین احتمال ریسکها: به هر یک از ریسکها یک احتمال بر حسب درصد میدهیم .
3) تعیین تاثیر ریسکها در پروژه: میزان تاثیر ریسکها را مشخص میکنیم. کم اهمیت, متوسط, بحرانی, فاجعه آمیز
4) مدیریت ریسک: برنامهای برای مدیریت ریسکها تهیه میکنیم.
5) اولویتبندی ریسکها: ریسکهایی که تاثیر زیاد و احتمال وقوع آن متوسط رو به بالاست را در اولویت قرار میدهیم.
مولفهها: برای تعیین تاثیر هر ریسک چهار مولفه را در نظر میگیریم و احتمال آنها را تعیین میکنیم و میانگین احتمالات را محاسبه کرده و به عنوان احتمال ریسک در جدول ثبت میکنیم:
1) کارایی: اگر ریسک تعیین شده اتفاق افتد چقدر در عدم انطباق محصول با نیازهای تعیین شده تاثیر دارد.
2) هزینه: اگر ریسک تعیین شده اتفاق افتد چقدر احتمال دارد هزینه واقعی از هزینه برآورد شده بیشتر یا کمتر باشد.
3) حمایت: با وقوع این ریسک این محصول چقدر امکان پشتیبانی, تصحیح و تغییر دارد.
4) زمانبندی: اگر ریسک تعیین شده اتفاق افتد چقدر احتمال دارد از زمانبندی عقب بیفتیم.
برنامه RMMM :
1) کاهش ریسک: مدیر در این زمینه سعی میکند که مشکلات موجود را رفع کند و شرایطی را به وجود آورد که ریسک اتفاق نیفتد.
2) نظارت بر ریسک: در این مرحله اولین کار این است که در حین پروژه ریسک را بررسی کند. ببیند آیا ریسک اتفاق میافتد یا خیر و از این تجزیهها و تخمینها در پروژههای بعدی استفاده کند. بررسی کند که آیا کارهای کاهش پروژه به خوبی انجام میشود. دلیل وقوع ریسکها را مشخص میکند.
3) مدیریت ریسک: همه کارها برای کاهش و نظارت بر وقوع ریسک انجام شده ولی حالا ریسک اتفاق افتاده. چه کارهایی باید انجام دهیم و چه برنامهریزیهایی برای آینده داریم.
انواع ریسکهای نرمافزاری:
1) ریسکهای پروژهای
2) ریسکهای فنی
3) ریسکهای تجاری
4) ریسکهای بازاریابی
5) ریسکهای استراتژیک
6) ریسکهای حمایت مدیران ارشد
7) ریسکهای تکنیکی
8) ریسکهای محیط توسعه نرمافزار
مدیریت پیکربندی
مدیریت پیکربندی مجموعهای از فعالیتهای پیگیری و کنترل میباشد که در زمان شروع پروژه آغاز میشود و فقط زمانی خاتمه مییابد که نرمافزار از رده خارج شود.مدیریت پیکربندی در برگیرنده تغیرات است.
فعالیتهای مدیریت پیکربندی:
1) شناسایی اقلام پیکربندی: اولین گام شناسایی اقلام است.که هریک میتواند منفرد باشد یا ترکیبی.
قلم پیکربندی: هرمحصول یا هرچیزی که در حین فرآیند تولید میشود. در مدیریت پیکربندی مخزنی وجود دارد که همه اقلام پیکربندی در آن قرار میگیرد.هر یک از این اقلام یک نام و توصیفی هستند که نشان میدهد این قلم مربوط به کدام یک از این گامهاست.
پس از آنکه محصول تووسط تولید کننده تولید و به مدیریت ارائه شد, مرور تکنیک رسمیروی آن انجام میشود و پس از تایید به عنوان خط مبنا در مخزن ذخیره میشود. بعد از اینکه خط مبنا در مخزن اضافه شد, هر تغییری روی آن نیاز به درخواست تغییر اجازه مدیریت دارد.
2) کنترل نسخه: در این مرحله گراغ تکامل مربوط به نسخههای مختلف هریک از اقلام پیکربندی رسم میشود. شمارهگذاری نسخهها همان فرآیند کنترل نسخه است که تعیین میکند کدام نسخه از روی چه نسخهای ساخته شده است.
گراف نکامل نرمافزار: هرگاه نسخهای از یک قلم پیکربندی تغییر میکند و نسخهی جدیدی تولید میشود, نرمافزار هم تغییر میکند و نسخهی جدیدی از نرمافزار تولید میشود.
3) کنترل تغییر: مدیر باید کنترلهای زیر را انجام شود تا کنترل تغییر انجام شود:
الف) کنترل دسترسی: قلم پیکربندی تایید شده و عنوان خط مبنا به مخزن اضافه میشود. کسی که درخواست تغییر میدهد باید کنترل شود او اجازه دسترسی و تغییر دارد یا خیر. ابزارهایی وجود دارند که این دسترسیها را به افراد میدهند.
ب) کنترل همزمانی: دونفر به طور همزمان نتوانند یک قلم پیکربندی را تغییر دهند, با دسترسی هر فرد قلم قفل شود.
4) برسی پیکربندی: بررسی وضعیت پیکربندی, بررسی میشود آنچه انجام شده از نظر تکنیکی درست بوده یا خیر. تغییرات انجام شده مطابق با استانداردها انجام شده یا خیر.
5) گزارش وضعیت: هرگاه درخواست تغییری تصویب شود, رکوردی به این گزارش اضافه میشود که نشان میدهد چه
زمانی, چه تغییری, توسط چه کسی انجام شده و نتیجهی ان چه بوده است.
اطمینان از کیفیت نرمافزار (SQA)
قابلیت اطمینان : با Kloc و FP نیز سنجیده میشود اما MTBF ( متوسط زمان بین خرابیها) نهتر است زیرا به کاربر وابسته است.
MTBF = MTTF + MTTR
قابلیت در دسترس بودن: برای وظیفه تعیین شده کاربرد دارد یا خیر. هرچه MTTR کمتر باشد قابلیت در دسترس بودن بالاتر خواهد بود.
قابلیت امنیت: سنجش امنیت مانند تحلیل ریسک برای امنیت جدول رسم میکنیم. گروه SQA احتمال و تاثیر هریک از بحرانها را بررسی میکنیم و در نهایت نتیجهگیری میکنیم برای رفع آنها باید چه کاری انجام دهیم. نبود امنیت باعث شکست در پروژه و کنار گذاشتن نرمافزار میشود.
تیم FTR : این تیم از 3 تا 5ر نفر مهندس نرمافزار تشکیل میشود. این تیم محصولات را از نظر مطابقت با استانداردها بررسی میکند. سپس جلسهای برای بررسی تشکیل میشود. حاضران این جلسه اعضای FTR و تولیدکنندگان هستند. در پایان جلسه یا نرمافزار مردود میشود و پس از اصلاح دوباره جلسهای تشکیل میشود یا تایید میشود و به مخزن اضلفه میشود یا با وجود مشکلات کوچک, تایید میشود تا پس از اصلاح بدون تشکیل جلسه به مخزن سپرده شود.
تیم SQA : از مهندسین نرمافزار تشکیل شده که کارهای تکنیکی را انجام میدهند. افراد SQA مرورها, آزمایشها و تستها را در میآورند. برنامهریزیهایی برای مرورها, بازبینیهای نرمافزار و ثبت اطلاعات امنیتی و آماری و تولید گزارشات را انجام میدهند.
زمانبندی و پیگیری پروژه
زمانبندی پروژه: بینظمی, رخداد ریسکهای پیش بینی نشده, تغییرات خواستههای مشتری, ناهماهنگی تیمها, ناتوانی مدیر پروژه در شناسایی وحل بحران و معقول نبودن زمان تعیین شده توسط مشتری همه از دلایلی است که سبب عقب ماندن پروژهها از زمانبندی میشود.
اصول زمانبندی:
§ سیستم را به زیر سیستمها تقسیم نموده و در مورد هریک از آنها گامهای مهندسی را تعیین کنیم.
§ تخمین نفر ماه برا یانجام هر یک از فعالیتها
§ به هریک از فعالیتهای تعیین شده فردی را اختصاص دهیم
§ اعتبارسنجی فعالیت
§ برای هر بخش فعالیتها, خروجی تعیین کنیم.
§ میزان فعالیت یعنی زمان شروعو پایان هر فعالیت را تعیین کنیم.
به طور کلی سه درجه دقت در انتخاب کارهای مهندسی وجود دارد:
1) معمولی: تمام کارهای مربوط به طور حداقل انجام شودو فعالیتهای چتری به طور حداقل انجام میشود
2) ساختاریافته: SQA و مستندسازی هم انجام میشوند, تاحدی که کیفیت تضمین شود.
3) اکید: دقیقا همه کارها با دقت تمام و شدت زیاد انجام میدهیم برای رسیدن به حداکثر کیفیت
4) تولید سریع: میخواهیم محصول به سرعت وارد بازار شود. حداقل کارها را انجام میدهیم. مستندسازی و مرورها را پس از تحویل انجام میدهیم.
پیگیری پروژه: مدیر مرورها, گزارشات مدیران تیمها را بررسی میکند, جلسات رسمی یا غیر رسمی برای وضعیت پروژه برگزار میکند تا ببیند پروژه چطور پیش میرود.
بررسی آماری پیگیری پروژه: مدیر تعیین میکند, هرنفرماه چقدر هزینه دارد و هزینه برنامهریزی شده را تعیین میکند. مدیر زمان ثابتی مثل t را در نظر میگیرد, کل هزینههای زمانبندی شده برای پروژه تا زمان t را محاسبه کند و هزینههای واقعی صرف شده تا این زمان را نیز تعیین کند.
هزینه زمانبندی شده CS = ∑ CSi
هزینه واقعی زمانبندی شده CP = ∑ CPi
کارایی زمانبندی Spl = CP / CS
