Professional Documents
Culture Documents
10 11 Risk Plan
10 11 Risk Plan
10 11 Risk Plan
الكلمات المفتاحية:
إدارة المخاطر ،االستراتيجيات المنفعلة للمخاطرة ،االستراتيجيات الفاعلة للمخاطرة ،الخسارة ،مخاطر
المشروع ،المخاطر التقنية ،مخاطر األعمال ،المخاطر المعروفة ،المخاطر القابلة للتنبؤ ،المخاطر غير القابلة
للتنبؤ ،تحديد المخاطرة ،المخاطرة العمومية ،المخاطرة الخاصة بالمنتج ،قائمة تفقُّد عناصر المخاطرة ،مكونات
المخاطرة البرمجية ،توقُّع المخاطرة ،أثر المخاطرة ،احتمال المخاطرة ،جدول المخاطرة ،مراقبة المخاطرة،
تخفيف المخاطرة ،تجنب المخاطرة.
ملخص:
في هذا الفصل نتعرف على المخاطر في مشاريع تطوير البرمجيات ،وخطة إدارة المخاطر والتي توضع عادة
في مرحلة التخطيط للمشروع.
أهداف تعليمية:
يهدف هذا الفصل إلى التعريف بـ:
تعريف المخاطر المحتملة في إدارة مشاريع تطوير البرمجيات.
التعرف على عناصر خطة إدارة المخاطر في مشاريع تطوير البرمجيات.
1 / 15
.1إدارة المخاطر:
المقصود بالمخاطر في مشاريع تطوير البرمجيات ،هو احتمال الخسارة نتيجة لعدم القدرة على تحقيق الهدف
ضمن الموارد المتاحة في أي مرحلة من مراحل تطوير المنتج.
عوامل الخطورة ال يمكن إلغاؤها ولكن يمكن إدارتها ،وخطة إدارة المخاطر هي عامل حاسم جداً في نجاح
مشاريع تطوير البرمجيات كما سنرى الحقاً.
و بالرغم من أن هناك العديد من االقتراحات لتعريف المخاطرة البرمجية ( ،)Software Riskإال أن هناك اتفاق
عام على أن المخاطرة تتصف دوما ً بصفتين:
-عدم اليقين ()Uncertainty
قد يحصل الحدث المميِّز للمخاطرة وقد ال يحصل ،أي ال يوجد مخاطر احتمالها .%011
-الخسارة ()Loss
إذا أصبحت المخاطرة حقيقية فإن التبعات أو الخسائر الناتجة عن ذلك ستحصل.
.2مفاهيم أساسية:
من االجراءات المحتملة والممكن ادراجها كحلول للتأخير في خطة إدارة المخاطر ،زيادة حجم كادر
العمل (يجب أن يكون لدى مدير المشروع قاعدة معطيات بأشخاص محتملين بكفاءات مناسبة ممكن
ضمهم لفريق العمل عند الحاجة) ،أو زيادة ساعات العمل (عمل إضافي) ،أو االستعانة باستشاريين
لتقديم حلول لمشاكل تؤخر سير العمل.
الكلفة:
عند تقديركلفة المشروع ،ال بد من أن نأخذ بعين االعتبار العوامل التالية:
-تقدير حجم الشروع.
-جودة المنتج النهائي.
-العتاد المادي الالزم.
-األدوات البرمجية الالزمة والتراخيص المطلوبة.
-المهارات الشخصية المطلوبة في فريق العمل.
-نفقات السفر واإلقامة في حال وجودها.
-االتصاالت.
-التدريب والدعم الفني.
2
عوامل الخطورة:
يمكن تصنيف عوامل الخطورة في مشاريع تطوير البرمجيات ضمن ثالث فئات:
-مخاطر المشروع ()Project Risks
oعدم االلتزام بالخطة الزمنية للمشروع.
oاالنزياح في الجدول الزمني للمشروع يؤدي إلى زيادة الكلفة.
oالكادر ،الموارد ،الزبون ،ومشاكل المتطلبات.
و يمكن تصنيف عوامل الخطورة حسب امكانية توقعها ضمن ثالث فئات:
-المخاطر المعروفة ()Known Risks
متأن لخطة المشروع ،ولبيئة األعمال والبيئة التقنية
ٍ هي المخاطر التي يمكن اكتشافها بعد تقييم
التي يجري فيها تطوير المشروع ،والمصادر الموثوقة األخرى للمعلومات (مثل :تاريخ توريد
غير معقول ،افتقار للمتطلبات الموثَّقة أو لنطاق البرمجية ،أو بيئة تطوير فقيرة)؛
-المخاطر القابلة للتنبؤ ()Predictable Risks
تستخلص من الخبرة السابقة ،مثل تغيير العاملين ،اتصاالت ضعيفة مع الزبون ،تخفيف جهود
الموظفين مع تخديم طلبات الصيانة المستمرة.
-المخاطر غير القابلة للتنبؤ ()Unpredictable Risks
وهذه تشبه "جوكر" ورق اللعب ،يمكن أن تحدث ،وقد تحدث فعليا ً ولكن يصعب فعلياً تعيين
هويتها مق َّدماً.
3
.3خطة إدارة المخاطر:
يمكن تلخيص محتوى خطة إدارة المخاطر ،بأربعة موضوعات هي:
تحديد المخاطر
تحديد المخاطر هي إجرائية لتوصيف التهديدات التي تعترض خطة المشروع (التقديرات ،الجدول
الزمني ،تحميل الموارد .)... ،عندما يقوم مدير المشروع بتعيين هوية المخاطر ،فإنه يكون قد خطا
الخطوة األولى باتجاه تجنبها عند اإلمكان والتحكم فيها أيضا ً عند الضرورة.
تقييم المخاطر
تقييم احتمال حدوث كل مخاطرة وتأثيرها على المشروع.
.4تحديد المخاطر:
إحدى طرائق تحديد المخاطر هي أن نقوم بإنشاء قائمة حصر لعناصر المخاطرة ( Risk Item
،)Checklistمن البنود الممكن ادراجها في هذه القائمة:
4
مخاطر حجم المشروع--: .a
يجب في كل حالة من هذه الحاالت إجراء مقارنة معلومات المنتج المطلوب تطويره بالخبرة السابق
إذا حصلت نسبة انزياح كبيرة ،أو كانت األرقام متماثلة ولكن النتائج السابقة أقل بكثير من المقبول،
فإن احتمال المخاطرة عا ٍل جداً
يجب في كل حالة من هذه الحاالت إجراء مقارنة معلومات المنتج المطلوب تطويره بالخبرة السابقة.
إذا حصلت نسبة انزياح كبيرة ،أو كانت األرقام متماثلة ولكن النتائج السابقة أقل بكثير من المقبول،
فإن احتمال المخاطرة عا ٍل جداً.
5
تختلف الصلة بالموردين من زبون آلخر: o
فزبون يعرف جيداً المنتَج والمنتِج ،وآخر ال يتواصل مع المنتِج إال بمراسالت مكتوبة،
وببعض المكالمات الهاتفية المختصرة.
ي من األسئلة السابقة نفياً ،فيجب إجراء تقصٍّ آخر لتقييم احتمال المخاطرة.
إذا كان الجواب عن أ ٍّ
هل تدعم إدارتك العليا سياسة مكتوبة تؤكد أهمية اإلجرائية القياسية لهندسة البرمجيات؟ o
هل طورت مؤسستك وصفا ً مكتوبا ً لإلجرائية البرمجية التي ستطب َّق في هذا المشروع؟ o
هل يحبِّذ أعضاء الكادر المكلَّف بالعمل اإلجرائيةَ البرمجية كما هي موثقة ومستعدون o
الستخدامها؟
هل تُستخدم اإلجرائية البرمجية لمشاريع أخرى؟ o
هل طورت مؤسستك أو طلبت سلسلة من الدورات التدريبية في هندسة البرمجيات o
للمديرين والكادر التقني؟
هل تُق َّدم معايير منشورة لهندسة البرمجيات لكل مط ِّور برمجيات أو مدير برمجيات؟ o
هل تجرى المراجعات التقنية الرسمية ( )Formal Technical Reviewsلتوصيف o
المتطلبات والتصميم والترميز بشكل منتظم؟
هل تُجرى المراجعات التقنية الرسمية لإلجراءات االختبار وحاالت االختبار بشكل o
منتظم؟
هل توثق نتائج كل مراجعة تقنية رسمية ،بما في ذلك األخطاء الموجودة والموارد َّ o
المستخدمة؟
هل توجد آلية ما لضمان توافق العمل المنفَّذ ضمن المشروع مع قياسات هندسة o
البرمجيات؟
هل استُخدمت آلية للتحكم في تغيير متطلبات الزبون التي تؤثِّر في البرمجية؟ o
هل يوجد توثيق لبيان العمل ،توصيف متطلبات البرمجية ،وخطة تطوير البرمجية، o
وغيرها ،وذلك لكل عقد فرعي؟
هل يُتَّبع إجراء ما لمتابعة ومراجعة أداء المتعاقدين الفرعيين؟ o
هل تُستَخدم وسائل مناسبة للمساعدة على التواصل بين الزبون والمطور ،مثل تقنيات o
توصيف التطبيق الميسَّرة؟
هل تُستَخدم طرائق محددة لتحليل البرمجيات؟ o
هل تُستَخدم طريقة محددة لتصميم المعطيات وتصميم بنية البرمجية؟ o
ب أكثر من %01من ترميز برنامجك بلغة عالية المستوى؟ هل ُكتِ َ o
هل ُع ِّرفَت واستخدمت مصطلحات محددة لتوثيق الترميز؟ o
6
هل تُستخدم طرائق محددة لتصميم حاالت اختبار البرمجية؟ o
هل تُستخدم أدوات برمجية لدعم فعاليات التخطيط والمتابعة؟ o
هل تُستخدم أدوات برمجية لدعم إجرائية تحليل البرمجيات وتصميمها؟ o
هل تُستخدم أدوات إلنشاء نماذج أولية ( )Prototypeبرمجية؛ o
هل تُستخدم أدوات برمجية لدعم إنتاج الوثائق وإدارتها؟ o
هل تُجمع مقاييس الجودة لجميع المشاريع البرمجية؟ o
هل تُجمع مقاييس اإلنتاجية لجميع المشاريع البرمجية؟ o
إذا أجيب بالنفي عن معظم هذه األسئلة ،فإن اإلجرائية البرمجية ضعيفة ويكون احتمال المخاطرة
عالياً .يجب االنتباه إلى أن قائمة تف ُّقد عناصر المخاطرة المتعلقة باإلجرائية قد تختلف من مشروع
إلى آخر ولكن النقاط المحددة سابقا ً تعتبر أكثر شيوعا ً وأهمية بين المشاريع البرمجية
تدعم بيئة هندسة البرمجيات فريق العمل واإلجرائية والمنتَج ،إذا كان هناك عيوب في هذه البيئة،
فقد تكون مصدر مخاطرة كبيرة.
إذا كانت اإلجابة عن معظم هذه األسئلة بالنفي ،فإن بيئة تطوير البرمجيات ضعيفة واحتمال
المخاطرة عا ٍل جداً.
7
إذا كان الجواب على أي من هذه األسئلة باإليجاب (نعم) ،فيجب إجراء تحليل إضافي لتقييم احتمال
المخاطرة.
إذا كان الجواب على أي من هذه األسئلة بالنفي ،فيجب إجراء المزيد من التحليل والتقصي لتقييم
احتمال المخاطرة.
8
.5تقييم المخاطر+:
.aمكونات المخاطرة البرمجية+:
يمكن تعريف مكونات المخاطرة البرمجية على النحو التالي:
مخاطرة األداء ()Performance Risk
وهي درجة الشك في أن يتوافق المنتَج مع المتطلبات المطلوبة منه ،وأن يناسب االستخدام
المخطَّط له.
مخاطرة الكلفة ()Cost Risk
وهي درجة الشك في أن يتحقق االلتزام بموازنة المشروع.
مخاطرة الدعم ()Support Risk
وهي درجة الشك في أن تكون البرمجيات سهلة التصحيح والتكييف والتحسين.
مخاطرة الجدول الزمني ()Schedule Risk
وهي درجة الشك في أن يحافَظ على الجدول الزمني للمشروع وأن يُسلَّم المنتَج في موعده.
.bتقييم المخاطر+:
من المفيد أن يقوم مدير المشروع بتعريف مكونات المخاطرة البرمجية (األداء ،الكلفة ،الدعم ،الجدول
الزمني).
يبيِّن الجدول التالي النتائج الممكنة لألخطاء (األسطر ذات الرقم )0أو اإلخفاق في تحقيق الخرج
المطلوب (األسطر ذات الرقم . )2يجري اختيار فئة التأثير اعتماداً على التوصيف األكثر مالئمة
للوصف في الجدول:
0
تافه 0 اإلخفاق في تحقيق المتطلبات يخلق أثراً ينتج عن الخطا أثر جزئي في الكلفة و/أو
غير مناسب أو غير قابل للتشغيل الجدول الزمني بكلفة تقديرية أقل من $0K
2 ال تخفيض في األداء برمجيات اقتصاد محتمل في موعد تسليم مبكر
التقني قابلة للدعم الموازنة قابل للتحقيق
بسهولة
و ينفِّذ مدير المشروع بالتعاون مع المديرون اآلخرين والكادر التقني أربع فعاليات لتوقُّع المخاطرة:
oتأسيس مقياس يعطي األرجحية المتوقعة للمخاطرة.
oوصف عواقب المخاطرة.
oتخمين أثر المخاطرة في المشروع والمنتَج.
oمالحظة الدقة اإلجمالية لتوقُّع المخاطرة حتى ال يكون هنالك مستقبالً أي سوء فهم.
يبدأ فريق المشروع بسرد جميع المخاطر بمساعدة قائمة تفقُّد عناصر المخاطرة. o
تصنف كل مخاطرة في العمود الثاني من الجدول(مثال PS :تعني مخاطرة حجم o
المشروع BU ،يعني مخاطرة األعمال).
يمكن تقدير قيمة احتمال حدوث كل مخاطرة من قبل كل عضو من أعضاء الفريق ،ومن ثم o
أخذ وسطي القيم االفرادية للوصول إلى إجماع (موافقة جماعية) على قيمة واحدة لالحتمال.
يقيَّم بعد ذلك أثر كل مخاطرة ،قيم األثر لها المعاني التالية ( -0كارثي-2 ،حرج-3 ،هامشي، o
-4تافه).
تحديد فئة األثر ( )Impact Categoryثم يجري توسيط فئات كل من مكونات المخاطرة o
األربعة (األداء والدعم والكلفة والجدول الزمني) لتحديد قيمة األثر الكلي.
01
عند اكتمال ملء األعمدة األربعة األولى من جدول المخاطرة يفرز الجدول اعتمادا على االحتمال
واألثر .تنتقل المخاطر ذات االحتمال األعلى واألثر األعلى إلى قمة الجدول ،وتسقط المخاطر ذات
االحتمال األقل إلى أسفله .يحقق هذا ترتيبا ً من الدرجة األولى ألولوية المخاطر.
إن ألثر المخاطرة واحتمالها وقعاً متميزاً على اهتمام اإلدارة .ولكن يجب أن ال يأخذ عامل مخاطرة
( )Risk Factorأثره كبير واحتمال حدوثه صغير جداً الكثير من وقت اإلدارة .في حين أنه يجب
االنتباه إلى المخاطر الشديدة األثر التي احتمال حدوثها كبير أو متوسط ،وكذلك المخاطر التي لها أثر
ضئيل واحتمال حدوث كبير ،وذلك في الخطوات التالية إلدارة المشروع.
يحتوي العمود المشار إليه بـ "Risk Mitigation, Monitoring and ( "RMMM
طورت بهدف التعامل )Managementمؤشراً إلى تخفيف المخاطرة وخطة المراقبة واإلدارة التي ِّ
مع المخاطر.
يمكن تحديد احتمال المخاطرة بإجراء تقديرات إفرادية ثم تطوير قيمة واحدة متفق عليها .ومع أن هذه
طورت طرائق أكثر تطوُّ راً لتحديد احتمال المخاطرة .يمكن على سبيل الطريقة قابلة للتطبيق ،فقد ِّ
المثال تقييم سواقات المخاطرة ( )Risk Driversوفق مقياس كيفي لالحتمال له القيم التالية :مستحيل،
غير محتمل ،متكر ر .ويمكن إرفاق قيمة رياضية لالحتمال مع كل قيمة كيفية (مثال :احتمال بقيمة 0.7
إلى 0تعني مخاطرة محتملة جداً).
نفحص ،خالل تقييم المخاطرة ،دقة التقديرات التي أجريت أثناء توقُّع المخاطرة ،ونحاول ترتيب
أولويات المخاطر التي ُك ِشف عنها والبدء بالتفكير بطرائق لضبط و/أو تجنب المخاطر التي يُحتمل
حدوثها. .يتوفر لدينا قبل البدء بتقييم المخاطرة مجموعة من الثالثيات من الشكل ] ،[ri, li, xiحيث
( )riتمثِّل المخاطرة )li( ،هو أرجحية (احتمال) المخاطرة ،و( )xiهو أثر المخاطرة.
المستوى المرجعي للمخاطرة (2222--)Risk Referent Level
يجب تعريف المستوى المرجعي للمخاطرة حتى يكون التقييم مفيداً .في حالة معظم المشاريع البرمجية،
تمثِّل أيضا ً مكونات المخاطرة (األداء والكلفة والدعم والجدول الزمني) مستويات مرجعية للمخاطرة.
أي أن هناك مستوى لـ :انحطاط األداء ،أو تجاوز الكلفة ،أو صعوبة في توفر الدعم ،أو انزالق الجدول
00
الزمني ،أو مزيج من األربعة ،سوف يؤدي إلى إيقاف المشروع .يتوقف العمل إذا سبب مزيج من
المخاطر مشاك َل تؤدي إلى تجاوز واحد أو أكثر من المستويات المرجعية.
النقطة المرجعية (--)Reference Point
في سياق تحليل المخاطر البرمجية ،يكون لمستوى المخاطرة نقطة مفردة ،تسمى النقطة المرجعية
( )Referent Pointأو نقطة االنكسار ( ،)Break Pointيكون فيها القرار باستمرار المشروع أو
إنهائه (حين تكون المشاكل كبيرة) مقبوالً بنفس القدر.
إذا أدى مزيج من المخاطر إلى مشكلة تتسبب بتجاوز الكلفة والجدول الزمني فسيكون هناك مستوى ما،
سيتسبب (عند تجاوزه) بإنهاء المشروع .يبيِّن الشكل التالي المستوى المرجعي للمخاطرة:
يكون لقرارات االستمرار أو اإلنهاء عند النقطة المرجعية الوزن ذاته .نادراً ما يمكن تمثيل المستوى
المرجعي على المخطط البياني بخط أملس .بل يكون في معظم الحاالت منطقة فيها مساحات من الشك
(أي غالبا ما تكون محاولة التنبؤ بقرار اإلدارة اعتماداً على مزيج من قيم مرجعية هي محاولة
مستحيلة) .لهذا نقوم خالل تقييم المخاطرة بالخطوات التالية:
oنُع ِّرف مستويات مرجعية للمخاطرة في المشروع؛
oنحاول تطوير عالقة بين كل ثالثية ] [ri, li, xiوكل من المستويات المرجعية؛
oنتنبأ بمجموعة من النقاط المرجعية التي تع ِّرف منطقة اإلنهاء ،محدودة بمنح ٍن أو
مساحات من الشك؛
oنحاول التنبؤ بكيفية تأثير خلطات من المخاطر في مستوى مرجعي ما.
02
.6وضع االجراءات المضادة ومراقبة المخاطر--:
مراقبة المخاطرة
ُّ
تبدأ فعاليات مراقبة المخاطرة مع تقدم المشروع .فيراقب مدير المشروع العوام َل التي قد تقدِّم داللة فيما
إذا كانت المخاطرة ستصبح أكثر أو أقل احتماالً .يمكن مراقبة العوامل التالية في حالة التغيير الكبير
للعاملين:
ً
oالسلوك العام ألعضاء الفريق اعتمادا على ضغوط المشروع؛
oالعالقات الداخلية الشخصية بين أعضاء الفريق؛
oالمشاكل المحتملة في التعويضات والفوائد؛
oتوافر العمل ضمن الشركة وخارجها.
ً
يجب على المدير إضافةً إلى مراقبة العوامل المذكورة آنفا ،أن يراقب فعالية خطوات تخفيف المخاطرة
03
.7تدريبات:
-1من أهم الصعوبات التي تميز مشااريع تطاوير البرمجياات عان ايرهاا مان المشااريعص صاعوبة التحقاق
وقياس جودة المنتج ؟ (اختر 1من اإلجابات)
-0صح.
-2خطأ.
()1
-2المخاطر القابلة للتنبؤ تستخلص مان الخبارات الساابقةص وخاصاة لادى مادير المشاروع ؟ (اختار 1مان
اإلجابات)
-0صح.
-2خطأ.
()1
(قدرة مدير المشروع على التنبؤ بالمخاطر هي مؤشر على خبرتهص ومنها تقييم الزبون و القادرة
على التواصل معهص وتوضيح متطلباته بشكل اير قابل للتأويل)
()2
-4عند تحديد عوامل الخطورة في حجم الكادر وخبرتهص وفي حال كانات المخااطرة موجاودةص فالن الحلاول
الممكنة والتي تدرج عادة في الخطة:
وجود مرشحين محتملين كبدائل بنفس الخبرة ويمكن توظيفهم. -0
التعاقد مع خبرات خارجية متاح وسلس. -2
امكانية التعاقد الضمني ( )Subcontractingمتاح وممكن. -3
جميع الخيارات السابقة صحيحة. -4
()4
04
(يجب على مدير المشروع التفكير فاي هاذا البادائل واألخاذ بعاين االعتباار امكانياة االساتعانة بهاا
عند الضرورة)
()2
(ماان المفيااد تضاامين رأي أعضاااء فريااق العماال فااي المخاااطر المحتملااةص فهااذا يرفااع ماان وعاايهم
للمخاطر وأثرها ويحفزهم على بذل الجهد لتالفيها)
05