‫‪Project management‬‬

‫المادة‪ :‬إدارة مشاريع ‪PM‬‬

‫الفصل الثامن‪ :‬إدارة المخاطر‬

‫الكلمات المفتاحية‪:‬‬

‫إدارة المخاطر‪ ،‬االستراتيجيات المنفعلة للمخاطرة‪ ،‬االستراتيجيات الفاعلة للمخاطرة‪ ،‬الخسارة‪ ،‬مخاطر‬
‫المشروع‪ ،‬المخاطر التقنية‪ ،‬مخاطر األعمال‪ ،‬المخاطر المعروفة‪ ،‬المخاطر القابلة للتنبؤ‪ ،‬المخاطر غير القابلة‬
‫للتنبؤ‪ ،‬تحديد المخاطرة‪ ،‬المخاطرة العمومية‪ ،‬المخاطرة الخاصة بالمنتج‪ ،‬قائمة تفقُّد عناصر المخاطرة‪ ،‬مكونات‬
‫المخاطرة البرمجية‪ ،‬توقُّع المخاطرة‪ ،‬أثر المخاطرة‪ ،‬احتمال المخاطرة‪ ،‬جدول المخاطرة‪ ،‬مراقبة المخاطرة‪،‬‬
‫تخفيف المخاطرة‪ ،‬تجنب المخاطرة‪.‬‬

‫ملخص‪:‬‬
‫في هذا الفصل نتعرف على المخاطر في مشاريع تطوير البرمجيات‪ ،‬وخطة إدارة المخاطر والتي توضع عادة‬
‫في مرحلة التخطيط للمشروع‪.‬‬

‫أهداف تعليمية‪:‬‬
‫يهدف هذا الفصل إلى التعريف بـ‪:‬‬
‫‪ ‬تعريف المخاطر المحتملة في إدارة مشاريع تطوير البرمجيات‪.‬‬
‫‪ ‬التعرف على عناصر خطة إدارة المخاطر في مشاريع تطوير البرمجيات‪.‬‬

‫‪1 / 15‬‬
 ‫‪ .1‬إدارة المخاطر‪:‬‬

‫المقصود بالمخاطر في مشاريع تطوير البرمجيات‪ ،‬هو احتمال الخسارة نتيجة لعدم القدرة على تحقيق الهدف‬
‫ضمن الموارد المتاحة في أي مرحلة من مراحل تطوير المنتج‪.‬‬
‫عوامل الخطورة ال يمكن إلغاؤها ولكن يمكن إدارتها‪ ،‬وخطة إدارة المخاطر هي عامل حاسم جداً في نجاح‬
‫مشاريع تطوير البرمجيات كما سنرى الحقاً‪.‬‬

‫و بالرغم من أن هناك العديد من االقتراحات لتعريف المخاطرة البرمجية (‪ ،)Software Risk‬إال أن هناك اتفاق‬
‫عام على أن المخاطرة تتصف دوما ً بصفتين‪:‬‬
‫‪ -‬عدم اليقين (‪)Uncertainty‬‬
‫قد يحصل الحدث المميِّز للمخاطرة وقد ال يحصل‪ ،‬أي ال يوجد مخاطر احتمالها ‪.%011‬‬
‫‪ -‬الخسارة (‪)Loss‬‬
‫إذا أصبحت المخاطرة حقيقية فإن التبعات أو الخسائر الناتجة عن ذلك ستحصل‪.‬‬

‫‪ .2‬مفاهيم أساسية‪:‬‬

‫تقدير حجم المشروع‪:‬‬

‫من أصعب المهام التي تواجه مدير المشروع‪ ،‬هي تقدير الحجم النهائي للمشروع‪ ،‬والذي يؤثر بدوره‬
‫على تقدير زمن التنفيذ والكلفة‪.‬‬
‫من المؤشرات التي يمكن تقدير حجم المشروع انطالقا ً منها‪ :‬عدد الوثائق الناتجة عنه (التقارير‬
‫واالحصائات)‪ ،‬عدد الواجهات التخاطبية‪ ،‬عدد اجراءات العمل المطلوب أتمتتها‪.‬‬
‫إال أن الوثائق الناتجة عن المشروع تختلف في الحجم واإلخراج وصعوبة التوليد‪ ،‬ونفس األمر ينطبق‬
‫على الواجهات التخاطبية‪ .‬وإجراءات العمل يمكن أن تكون بسيطة أو مركبة‪ ،‬والنتيجة أن هذه العوامل‬
‫الثالث مجتمعة يمكن أن تعطي تقديراً لحجم العمل‪ ،‬وإذا أضفنا لها خبرة مدير المشروع وقدرته على‬
‫التببؤ بالمشكالت فيمكن لمدير المشروع وضع خطة زمنية للمشروع بأقل قدر من االرتياب‪.‬‬
‫على الرغم من ذلك يبقى تقدير حجم المشروع والوقت الالزم لتنفيذه من األخطار المحتملة‪ ،‬وال بد‬
‫لمدير المشروع من تتبع التنفيذ أوالً بأول وإعادة تقييم وقت التنفيذ والقدرة على االلتزام بالخطة الزمنية‪،‬‬
‫وال بد له من وضع خطة إدارة مخاطر يلجأ للحلول المقترحة فيها عند ظهور أي تأخير‪.‬‬

‫من االجراءات المحتملة والممكن ادراجها كحلول للتأخير في خطة إدارة المخاطر‪ ،‬زيادة حجم كادر‬
‫العمل (يجب أن يكون لدى مدير المشروع قاعدة معطيات بأشخاص محتملين بكفاءات مناسبة ممكن‬
‫ضمهم لفريق العمل عند الحاجة)‪ ،‬أو زيادة ساعات العمل (عمل إضافي)‪ ،‬أو االستعانة باستشاريين‬
‫لتقديم حلول لمشاكل تؤخر سير العمل‪.‬‬

‫الكلفة‪:‬‬
‫عند تقديركلفة المشروع‪ ،‬ال بد من أن نأخذ بعين االعتبار العوامل التالية‪:‬‬
‫‪ -‬تقدير حجم الشروع‪.‬‬
‫‪ -‬جودة المنتج النهائي‪.‬‬
‫‪ -‬العتاد المادي الالزم‪.‬‬
‫‪ -‬األدوات البرمجية الالزمة والتراخيص المطلوبة‪.‬‬
‫‪ -‬المهارات الشخصية المطلوبة في فريق العمل‪.‬‬
‫‪ -‬نفقات السفر واإلقامة في حال وجودها‪.‬‬
‫‪ -‬االتصاالت‪.‬‬
‫‪ -‬التدريب والدعم الفني‪.‬‬

‫‪2‬‬
 ‫عوامل الخطورة‪:‬‬
‫يمكن تصنيف عوامل الخطورة في مشاريع تطوير البرمجيات ضمن ثالث فئات‪:‬‬
‫‪ -‬مخاطر المشروع (‪)Project Risks‬‬
‫‪ o‬عدم االلتزام بالخطة الزمنية للمشروع‪.‬‬
‫‪ o‬االنزياح في الجدول الزمني للمشروع يؤدي إلى زيادة الكلفة‪.‬‬
‫‪ o‬الكادر‪ ،‬الموارد‪ ،‬الزبون‪ ،‬ومشاكل المتطلبات‪.‬‬

‫التقنية (‪)Technical Risks‬‬ ‫المخاطر‬ ‫‪-‬‬

‫تهدد جودة ودقة وتوقيت البرمجية المطلوب إنتاجها‬ ‫‪o‬‬
‫يصبح تحقيق البرمجية صعبا ً أو مستحيالً‬ ‫‪o‬‬
‫تحدِّد المشاكل المحتملة في التصميم‪ ،‬التحقيق‪ ،‬الواجهات‪ ،‬االختبار‪ ،‬والصيانة‬ ‫‪o‬‬
‫عوامل أخرى للمخاطرة في هذا اإلطار‬ ‫‪o‬‬
‫غموض المواصفات (‪)Specification Ambiguity‬‬ ‫‪o‬‬
‫عدم اليقين التقني (‪)Technical Uncertainty‬‬ ‫‪o‬‬
‫التقادم التقني‬ ‫‪o‬‬
‫ظهور التقنيات الجديدة‬ ‫‪o‬‬

‫األعمال (‪)Business Risks‬‬ ‫مخاطر‬ ‫‪-‬‬

‫بناء منتج أو نظام ممتاز ال يرغب فيه أحد (مخاطرة السوق)‬ ‫‪o‬‬
‫بناء منتج لم يعد متناسبا ً مع اإلستراتيجية العامة ألعمال الشركة (مخاطرة إستراتيجية)‬ ‫‪o‬‬
‫بناء منتج ال يعرف فريق المبيعات كيفية بيعه أو تسويقه‬ ‫‪o‬‬
‫فقدان دعم اإلدارة العليا بسبب تغيير اهتمامها أو إجراء تغير في األشخاص (مخاطرة‬ ‫‪o‬‬
‫إدارية)‬
‫فقدان توفر الميزانية أو الموظفين (مخاطرة الميزانية)‬ ‫‪o‬‬

‫و يمكن تصنيف عوامل الخطورة حسب امكانية توقعها ضمن ثالث فئات‪:‬‬
‫‪ -‬المخاطر المعروفة (‪)Known Risks‬‬
‫متأن لخطة المشروع‪ ،‬ولبيئة األعمال والبيئة التقنية‬
‫ٍ‬ ‫هي المخاطر التي يمكن اكتشافها بعد تقييم‬
‫التي يجري فيها تطوير المشروع‪ ،‬والمصادر الموثوقة األخرى للمعلومات (مثل‪ :‬تاريخ توريد‬
‫غير معقول‪ ،‬افتقار للمتطلبات الموثَّقة أو لنطاق البرمجية‪ ،‬أو بيئة تطوير فقيرة)؛‬
‫‪ -‬المخاطر القابلة للتنبؤ (‪)Predictable Risks‬‬
‫تستخلص من الخبرة السابقة‪ ،‬مثل تغيير العاملين‪ ،‬اتصاالت ضعيفة مع الزبون‪ ،‬تخفيف جهود‬
‫الموظفين مع تخديم طلبات الصيانة المستمرة‪.‬‬
‫‪ -‬المخاطر غير القابلة للتنبؤ (‪)Unpredictable Risks‬‬
‫وهذه تشبه "جوكر" ورق اللعب‪ ،‬يمكن أن تحدث‪ ،‬وقد تحدث فعليا ً ولكن يصعب فعلياً تعيين‬
‫هويتها مق َّدماً‪.‬‬

‫أهم عوامل الخطورة والتي تتكرر في كثير من مشاريع تطوير البرمجيات‪:‬‬

‫‪ -‬خروج المطورين ذوي الخبرة من فريق العمل‪ ،‬ودخول أعضاء جدد‪.‬‬
‫‪ -‬تغير البنية التنظيمية للمشروع‪.‬‬
‫‪ -‬تغير المتطلبات الوظيفية‪.‬‬
‫‪ -‬التقدير السئ لزمن التنفيذ‪.‬‬
‫‪ -‬تغير األدوات والبنى التحتية‪.‬‬

‫‪3‬‬
 ‫‪ .3‬خطة إدارة المخاطر‪:‬‬
‫يمكن تلخيص محتوى خطة إدارة المخاطر‪ ،‬بأربعة موضوعات هي‪:‬‬
‫‪ ‬تحديد المخاطر‬
‫تحديد المخاطر هي إجرائية لتوصيف التهديدات التي تعترض خطة المشروع (التقديرات‪ ،‬الجدول‬
‫الزمني‪ ،‬تحميل الموارد‪ .)... ،‬عندما يقوم مدير المشروع بتعيين هوية المخاطر‪ ،‬فإنه يكون قد خطا‬
‫الخطوة األولى باتجاه تجنبها عند اإلمكان والتحكم فيها أيضا ً عند الضرورة‪.‬‬

‫‪ ‬تقييم المخاطر‬
‫تقييم احتمال حدوث كل مخاطرة وتأثيرها على المشروع‪.‬‬

‫‪ ‬وضع اإلجراءات المضادة‬

‫تحديد المخاطر ذات التأثير الكبير على المشروع‪ ،‬ومحاولة التخفيف منها ووضع اإلجراءات المناسبة‬
‫لذلك‪.‬‬

‫‪ ‬مراقبة وإدارة المخاطر‬

‫مر اقبة آلية التعامل مع المخاطر‪ ،‬وتوثيق جميع المعلومات المتعلقة بذلك وبالمشاكل التي قد تنتج عن‬
‫مخاطرة معينة‪ ،‬واعتماد نظام سليم للتواصل بين أعضاء فريق المشروع‪.‬‬

‫‪ .4‬تحديد المخاطر‪:‬‬
‫إحدى طرائق تحديد المخاطر هي أن نقوم بإنشاء قائمة حصر لعناصر المخاطرة ( ‪Risk Item‬‬
‫‪ ،)Checklist‬من البنود الممكن ادراجها في هذه القائمة‪:‬‬

‫المخاطر المتعلقة بالحجم الكلي‬

‫‪Product Size‬‬ ‫حجم المنتج أو المشروع‬ ‫‪PS‬‬
‫للبرمجية المراد بناؤها أو تعديلها‪.‬‬
‫المخاطر المتعلقة بالقيود التي تفرضها‬
‫‪Business Impact‬‬ ‫أثر األعمال‬ ‫‪BI‬‬
‫اإلدارة أو يفرضها مكان التسويق‪.‬‬
‫المخاطر المتعلقة بمستوى تمرُّ س‬
‫الزبون وقابلية المطور لالتصال‬ ‫‪Client Characteristics‬‬ ‫مزايا الزبون‬ ‫‪CC‬‬
‫بالزبون بطريقة مخططة زمنيا ً‪.‬‬
‫المخاطر المتعلقة بالدرجة التي وصل‬
‫إليها تعريف اإلجرائية البرمجية‬ ‫‪Process Definition‬‬ ‫تعريف إجرائيات العمل‬ ‫‪PD‬‬
‫والتي تتَّبعها مؤسسة التطوير‪.‬‬
‫المخاطر المتعلقة بتوفُّر وجودة‬ ‫‪Development‬‬
‫بيئة التطوير‬ ‫‪DE‬‬
‫األدوات المستخدمة لبناء المنتج‪.‬‬ ‫‪Environment‬‬
‫المخاطر المتعلقة بتعقيد النظام‬
‫المطلوب بناؤه ومستوى التقنيات‬ ‫‪Required Technology‬‬ ‫التقنيات المطلوبة‬ ‫‪RT‬‬
‫المطلوب توفريها في النظام‪.‬‬
‫المخاطر المتعلقة بخبرة مهندسي‬
‫البرمجيات الذين سيقومون بالعمل‬ ‫‪Staff Size and‬‬
‫حجم الكادر وخبرته‬ ‫‪SS‬‬
‫فيما يخص خبرتهم التقنية الكلية‬ ‫‪Experience‬‬
‫وخبرتهم في المشروع‪.‬‬

‫‪4‬‬
 ‫مخاطر حجم المشروع‪--:‬‬ ‫‪.a‬‬

‫قائمة حصر عناصر المخاطرة‬ ‫‪‬‬

‫‪ o‬الحجم التقديري للمنتج مقاسا ً باستخدام عدد أسطر الترميز (‪ )LOC‬أو نقاط الوظيفة‬
‫(‪.)FP‬‬
‫‪ o‬درجة الثقة في تقدير الحجم التقديري للبرمجية‪.‬‬
‫‪ o‬الحجم التقديري للمنتج مقاسا ً بعدد البرامج والملفات والمناقالت‪.‬‬
‫‪ o‬االنزياح النسبي (‪ )Relative Shift‬في حجم المنتج عن وسطي المنتجات السابقة‪.‬‬
‫‪ o‬حجم قاعدة المعطيات (‪ )Database‬التي يُنشئها أو يستخدمها المنتج‪.‬‬
‫‪ o‬عدد مستخدمي المنتج‪.‬‬
‫‪ o‬عدد التغيرات المتوقعة في متطلبات المنتج‪ ،‬قبل التسليم‪ ،‬وبعد التسليم‪.‬‬
‫‪ o‬مقدار البرمجيات التي أُعيد استخدامها‪.‬‬

‫يجب في كل حالة من هذه الحاالت إجراء مقارنة معلومات المنتج المطلوب تطويره بالخبرة السابق‬ ‫‪‬‬

‫إذا حصلت نسبة انزياح كبيرة‪ ،‬أو كانت األرقام متماثلة ولكن النتائج السابقة أقل بكثير من المقبول‪،‬‬ ‫‪‬‬
‫فإن احتمال المخاطرة عا ٍل جداً‬

‫مخاطر أثر األعمال‪:‬‬ ‫‪.b‬‬

‫قائمة حصر عناصر المخاطرة‬ ‫‪‬‬

‫‪ o‬أثر هذا المنتج في عائدات الشركة‪.‬‬
‫‪ o‬وضوح هذا المنتج في نظر اإلدارة العليا‪.‬‬
‫‪ o‬إمكانية االلتزام بالمواعيد النهائية للتسليم (هل هذه مواعيد معقولة ومنطقية؟)‪.‬‬
‫‪ o‬عدد الزبائن الذين سيستخدمون هذا المنتج وانسجام احتياجاتهم معه‪.‬‬
‫‪ o‬درجة تم ُّرس المستخدم النهائي‪.‬‬
‫‪ o‬مقدار وجودة توثيق المنتج الالزم توفيرها وتسليمها للزبون‪.‬‬
‫‪ o‬القيود الحكومية على بناء المنتج (إن وجدت)‪.‬‬
‫‪ o‬الكلفة المترتبة على التسليم المتأخر‪.‬‬
‫‪ o‬الكلفة المترتبة على منتج فيه عيوب‪.‬‬

‫يجب في كل حالة من هذه الحاالت إجراء مقارنة معلومات المنتج المطلوب تطويره بالخبرة السابقة‪.‬‬ ‫‪‬‬

‫إذا حصلت نسبة انزياح كبيرة‪ ،‬أو كانت األرقام متماثلة ولكن النتائج السابقة أقل بكثير من المقبول‪،‬‬ ‫‪‬‬
‫فإن احتمال المخاطرة عا ٍل جداً‪.‬‬

‫مزايا الزبون‪:‬‬ ‫‪.c‬‬

‫تختلف االحتياجات من زبون آلخر‪:‬‬ ‫‪o‬‬

‫فزبون يعرف ما يريد‪ ،‬وآخر يعرف ما ال يريد‪ .‬وزبون يبذل قصارى جهده لمعرفة‬
‫التفاصيل‪ ،‬على حين يكتفي زبون آخر بالوعود حتى لو كانت غير دقيقة‪.‬‬

‫تختلف الشخصية من زبون آلخر‪:‬‬ ‫‪o‬‬

‫فزبون يستمتع بكونه زبوناً‪ ،‬ويستمتع بالمفاوضات وبالنتائج السيكولوجية للمنتج الجديد‪،‬‬
‫ضل آخر عدم كونه زبوناً‪ .‬وزبون يقبل سعيداً أي شيء يُسلَّم إليه‪ ،‬ويجعل أسوأ‬ ‫بينما يف ِّ‬
‫منتج هو األفضل‪ ،‬في حين يشتكي آخر بأس ًى عندما يفتقر المنتج إلى الجودة‪ .‬ويبدي‬
‫البعض تقديره عندما تكون الجودة عالية‪ ،‬وقلة منهم يشتكون لمجرد الشكوى بقطع النظر‬
‫عن األسباب‪.‬‬

‫‪5‬‬
 ‫تختلف الصلة بالموردين من زبون آلخر‪:‬‬ ‫‪o‬‬
‫فزبون يعرف جيداً المنتَج والمنتِج‪ ،‬وآخر ال يتواصل مع المنتِج إال بمراسالت مكتوبة‪،‬‬
‫وببعض المكالمات الهاتفية المختصرة‪.‬‬

‫غالبا ً ما يناقض الزبون نفسه‪:‬‬ ‫‪o‬‬

‫ً‬ ‫ً‬
‫فهو يريد الحصول على كل شيء "البارحة" ومجانا‪ .‬غالبا ما يعاني المنتِج من تناقض‬
‫الزبون مع نفسه‪.‬‬

‫قائمة حصر عناصر المخاطر المتعلقة بالزبون‬ ‫‪‬‬

‫‪ o‬هل عملت مع الزبون في الماضي؟‬
‫‪ o‬هل يمتلك الزبون فكرة واضحة عن المطلوب؟ هل قضى الزبون وقتا ً كافيا ً لكتابتها؟ أو‬
‫هل كتبها باألصل؟‬
‫ت في اجتماعات رسمية لجمع المتطلبات بهدف تحيد‬ ‫‪ o‬هل سيوافق الزبون على قضاء وق ٍ‬
‫نطاق المشروع؟‬
‫‪ o‬هل الزبون مستعد لتأسيس قنوات اتصال سريعة مع المط ِّور؟‬
‫‪ o‬هل الزبون متم ِّرس تقنيا ً في مجال المنتج؟‬
‫‪ o‬هل الزبون مستعد ليدع موظفيك يقومون بعملهم‪ ،‬أي هل سيقاوم الزبون نفسه بأال يقف‬
‫فوق رأسك خالل األعمال التقنية التفصيلية؟‬
‫‪ o‬هل يفهم الزبون اإلجرائية البرمجية (‪ )Software Process‬التي يتَّبعها الفريق لتطوير‬
‫المنتَج البرمجي؟‬

‫ي من األسئلة السابقة نفياً‪ ،‬فيجب إجراء تقصٍّ آخر لتقييم احتمال المخاطرة‪.‬‬
‫إذا كان الجواب عن أ ٍّ‬ ‫‪‬‬

‫تعريف اجرائيات العمل‪:‬‬ ‫‪.d‬‬

‫هل تدعم إدارتك العليا سياسة مكتوبة تؤكد أهمية اإلجرائية القياسية لهندسة البرمجيات؟‬ ‫‪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‬‬

‫إذا أجيب بالنفي عن معظم هذه األسئلة‪ ،‬فإن اإلجرائية البرمجية ضعيفة ويكون احتمال المخاطرة‬
‫عالياً‪ .‬يجب االنتباه إلى أن قائمة تف ُّقد عناصر المخاطرة المتعلقة باإلجرائية قد تختلف من مشروع‬
‫إلى آخر ولكن النقاط المحددة سابقا ً تعتبر أكثر شيوعا ً وأهمية بين المشاريع البرمجية‬

‫بيئة التطوير‪:‬‬ ‫‪.e‬‬

‫تدعم بيئة هندسة البرمجيات فريق العمل واإلجرائية والمنتَج‪ ،‬إذا كان هناك عيوب في هذه البيئة‪،‬‬ ‫‪‬‬
‫فقد تكون مصدر مخاطرة كبيرة‪.‬‬

‫قائمة حصر عناصر المخاطر المتعلقة ببيئة التطوير‬ ‫‪‬‬

‫هل تتوفر األدوات المناسبة إلدارة المشروع البرمجي؟‬ ‫‪o‬‬

‫هل تتوفر األدوات المناسبة إلدارة اإلجرائية البرمجية؟‬ ‫‪o‬‬
‫هل تتوفر األدوات المناسبة للتحليل والتصميم؟‬ ‫‪o‬‬
‫هل تتوفر مترجمات (‪ )Compilers‬أو مولِّدات ترميز (‪ ،)Code Generator‬مناسبة‬ ‫‪o‬‬
‫للمنتَج المراد بناؤه؟‬
‫هل تستخدم البيئة قاعدة معطيات أو مخزن (‪)Repository‬؟‬ ‫‪o‬‬
‫هل جميع األدوات البرمجية المستخدمة متكاملة مع بعضها؟‬ ‫‪o‬‬
‫هل جرى تدريب أعضاء فريق المشروع على األدوات التي تالءم مهام كل عضو؟‬ ‫‪o‬‬
‫هل هناك خبراء محليين لإلجابة عن األسئلة المتعلقة باألدوات؟‬ ‫‪o‬‬
‫كاف لهذه األدوات؟‬
‫ٍ‬ ‫هل هناك توثيق‬ ‫‪o‬‬
‫هل المساعدة المتاحة (بطريق ٍة ما‪ ،‬عبر الهاتف‪ ،‬اإلنترنت‪ )... ،‬كافية؟‬ ‫‪o‬‬

‫إذا كانت اإلجابة عن معظم هذه األسئلة بالنفي‪ ،‬فإن بيئة تطوير البرمجيات ضعيفة واحتمال‬ ‫‪‬‬
‫المخاطرة عا ٍل جداً‪.‬‬

‫التقنيات المطلوبة‪:‬‬ ‫‪.f‬‬

‫قائمة حصر بنود المخاطر المتعلقة بالتكنولوجيا‬ ‫‪‬‬

‫هل التكنولوجيا التي ستبنى جديدة على المؤسسة؟‬ ‫‪o‬‬

‫هل تحتاج متطلبات الزبون إلى بناء خوارزميات جديدة أو تقنية دخل أو خرج جديدة؟‬ ‫‪o‬‬
‫هل للبرمجيات واجهة مع أجهزة جديدة أو غير مجرَّبة؟‬ ‫‪o‬‬
‫هل للبرمجيات التي ستُبنى واجهة مع نظام قواعد معطيات لم تثبت بعد وظيفته وأداؤه في‬ ‫‪o‬‬
‫مجال التطبيق المراد بناؤه؟‬
‫هل تحتاج متطلبات المنتَج إلى واجهة مستخدم خاصة؟‬ ‫‪o‬‬
‫هل تحتاج متطلبات المنتَج إلى استخدام طرائق جديدة للتحليل والتصميم واالختبار؟‬ ‫‪o‬‬
‫هل تحتاج المتطلبات إلى استخدام طرائق غير تقليدية لتطوير البرمجيات‪ ،‬مثل الطرائق‬ ‫‪o‬‬
‫الصورية (‪)Formal Methods‬؟ والطرائق المعتمدة على الذكاء االصطناعي‬
‫(‪ ،)Artificial Intelligence‬والشبكات العصبونية (‪)Neural Networks‬؟‬
‫هل تضع المتطلبات قيود أداء فائقة على المنتج؟‬ ‫‪o‬‬
‫هل الزبون غير متأكد من إمكانية تحقيق الوظيفة المطلوبة؟‬ ‫‪o‬‬

‫‪7‬‬
‫إذا كان الجواب على أي من هذه األسئلة باإليجاب (نعم)‪ ،‬فيجب إجراء تحليل إضافي لتقييم احتمال‬ ‫‪‬‬
‫المخاطرة‪.‬‬

‫حجم الكادر وخبرته‪:‬‬ ‫‪.g‬‬

‫قائمة حصر عناصر المخاطر المتعلقة بحجم وخبرة الكادر‬ ‫‪‬‬

‫‪ o‬هل يتوفر أفضل العاملين؟‬
‫‪ o‬هل يمتلك العاملون المزيج المناسب من المهارات؟‬
‫كاف؟‬
‫ٍ‬ ‫‪ o‬هل عدد العاملين‬
‫‪ o‬هل العاملون ملتزمون بالعمل طوال مدة المشروع؟‬
‫‪ o‬هل سيعمل بعض العاملين جزئيا ً في هذا المشروع؟‬
‫‪ o‬هل لدى العاملين التوقُّعات أو التصورات الصحيحة عن العمل الذي يعملون فيه؟‬
‫‪ o‬هل تلقى العاملون التدريب الضروري؟‬
‫‪ o‬هل سيكون تغيير العاملين منخفضا ً إلى درجة تسمح باالستمرار؟‬

‫إذا كان الجواب على أي من هذه األسئلة بالنفي‪ ،‬فيجب إجراء المزيد من التحليل والتقصي لتقييم‬ ‫‪‬‬
‫احتمال المخاطرة‪.‬‬

‫‪8‬‬
 ‫‪ .5‬تقييم المخاطر‪+:‬‬
‫‪ .a‬مكونات المخاطرة البرمجية‪+:‬‬
‫يمكن تعريف مكونات المخاطرة البرمجية على النحو التالي‪:‬‬
‫‪ ‬مخاطرة األداء (‪)Performance Risk‬‬
‫وهي درجة الشك في أن يتوافق المنتَج مع المتطلبات المطلوبة منه‪ ،‬وأن يناسب االستخدام‬
‫المخطَّط له‪.‬‬
‫‪ ‬مخاطرة الكلفة (‪)Cost Risk‬‬
‫وهي درجة الشك في أن يتحقق االلتزام بموازنة المشروع‪.‬‬
‫‪ ‬مخاطرة الدعم (‪)Support Risk‬‬
‫وهي درجة الشك في أن تكون البرمجيات سهلة التصحيح والتكييف والتحسين‪.‬‬
‫‪ ‬مخاطرة الجدول الزمني (‪)Schedule Risk‬‬
‫وهي درجة الشك في أن يحافَظ على الجدول الزمني للمشروع وأن يُسلَّم المنتَج في موعده‪.‬‬

‫‪ .b‬تقييم المخاطر‪+:‬‬
‫من المفيد أن يقوم مدير المشروع بتعريف مكونات المخاطرة البرمجية (األداء‪ ،‬الكلفة‪ ،‬الدعم‪ ،‬الجدول‬
‫الزمني)‪.‬‬

‫يُصنَّف أثر كل من مكونات المخاطرة‪ ،‬في واحدة من أربع فئات تأثير‪:‬‬

‫‪ ‬تافه (‪.)Negligible‬‬
‫‪ ‬هامشي (‪.)Marginal‬‬
‫‪ ‬حرج (‪.)Critical‬‬
‫‪ ‬كارثي (‪.)Catastrophic‬‬

‫يبيِّن الجدول التالي النتائج الممكنة لألخطاء (األسطر ذات الرقم ‪ )0‬أو اإلخفاق في تحقيق الخرج‬
‫المطلوب (األسطر ذات الرقم ‪ . )2‬يجري اختيار فئة التأثير اعتماداً على التوصيف األكثر مالئمة‬
‫للوصف في الجدول‪:‬‬

‫األداء‬ ‫الدعم‬ ‫الكلفة‬ ‫الجدول الزمني‬

‫كارثي‬ ‫‪0‬‬ ‫اإلخفاق في تحقيق المتطلبات ينتج عنه‬ ‫ينتج عن اإلخفاق كلف زائدة وتأخير في‬
‫إخفاق المهمة‬ ‫البرنامج بقيم تقديرية تفوق ‪$511K‬‬
‫‪2‬‬ ‫تراجع كبير عائد لعدم‬ ‫برمجيات‬ ‫قصور مالي كبير‪،‬‬ ‫موعد تسليم غير‬
‫غير مستجيبة تحقيق األداء التقني‬ ‫احتمال تجاوز‬ ‫قابل للتحقيق‬
‫أو غير قابلة‬ ‫الميزانية‬
‫للدعم‬
‫حرج‬ ‫‪0‬‬ ‫يؤدي اإلخفاق في تحقيق المتطلبات إلى‬ ‫ينتج عن اإلخفاق تأخيرات تشغيل و‪/‬أو‬
‫تراجع أداء النظام إلى درجة يصبح فيها‬ ‫زيادة في الكلفة بقيمة تقديرية من ‪$011K‬‬
‫نجاح المهمة موضع شك‬ ‫إلى ‪$500K‬‬
‫‪2‬‬ ‫بعض التخفيض في‬ ‫تأخيرات‬ ‫انزالق محتمل في بعض النقص في‬
‫األداء التقني‬ ‫ثانوية في‬ ‫الموارد المالية‪،‬‬ ‫تاريخ التسليم‬
‫تعديالت‬ ‫وتجاوز محتمل لها‬
‫البرمجيات‬
‫هامشي‬ ‫‪0‬‬ ‫اإلخفاق في تحقيق المتطلبات ينتج عنه‬ ‫انزالق في الكلفة‪ ،‬انزالق للجدول الزمني‬
‫تراجع في المهمات الثانوية‬ ‫قابل لالستدراك بقيمة تقديرية من ‪ $0K‬إلى‬
‫‪$011K‬‬
‫‪2‬‬ ‫تخفيض أصغري إلى‬ ‫دعم استجابي‬ ‫موارد مالية كافية‬ ‫جدول زمني‬
‫صغير في األداء التقني‬ ‫للبرمجيات‬ ‫معقول قابل‬
‫للتحقيق‬

‫‪0‬‬
 ‫تافه‬ ‫‪0‬‬ ‫اإلخفاق في تحقيق المتطلبات يخلق أثراً‬ ‫ينتج عن الخطا أثر جزئي في الكلفة و‪/‬أو‬
‫غير مناسب أو غير قابل للتشغيل‬ ‫الجدول الزمني بكلفة تقديرية أقل من ‪$0K‬‬
‫‪2‬‬ ‫ال تخفيض في األداء‬ ‫برمجيات‬ ‫اقتصاد محتمل في‬ ‫موعد تسليم مبكر‬
‫التقني‬ ‫قابلة للدعم‬ ‫الموازنة‬ ‫قابل للتحقيق‬
‫بسهولة‬

‫‪ .c‬توقُّع المخاطرة (‪+)Risk Projection‬‬

‫يقوم توقُّع المخاطرة (ويسمى أيضاً تقدير المخاطرة ‪ )Risk Estimation‬بمحاولة تقدير المخاطرة‬
‫بطريقتين‪:‬‬
‫‪ o‬األرجحية (‪)Likelihood‬‬
‫احتمال أن تكون المخاطرة حقيقية‪.‬‬
‫‪ o‬العواقب (‪)Consequences‬‬
‫النتائج أو التبعات الناتجة عن المشاكل المتعلقة بالمخاطرة عند وقوعها‪.‬‬

‫و ينفِّذ مدير المشروع بالتعاون مع المديرون اآلخرين والكادر التقني أربع فعاليات لتوقُّع المخاطرة‪:‬‬
‫‪ o‬تأسيس مقياس يعطي األرجحية المتوقعة للمخاطرة‪.‬‬
‫‪ o‬وصف عواقب المخاطرة‪.‬‬
‫‪ o‬تخمين أثر المخاطرة في المشروع والمنتَج‪.‬‬
‫‪ o‬مالحظة الدقة اإلجمالية لتوقُّع المخاطرة حتى ال يكون هنالك مستقبالً أي سوء فهم‪.‬‬

‫‪ .d‬إنشاء جدول المخاطرة‪+‬‬

‫يزود جدول المخاطرة (‪ )Risk Table‬مدير المشروع بتقنية بسيطة لتوقُّع المخاطرة‪ .‬الحظ الجدول‬ ‫ِّ‬
‫التالي والذي يمثِّل جزءاً من جدول المخاطرة لمشروع ما‪:‬‬

‫المخاطر‬ ‫الفئة‬ ‫االحتمال‬ ‫األثر‬ ‫‪RMMM‬‬

‫‪ PS‬تقييم الحجم قد يكون منخفض جداً‬ ‫‪60%‬‬ ‫‪2‬‬
‫‪ PS‬عدد المستخدمين اكبر من المخطط له‬ ‫‪30%‬‬ ‫‪3‬‬
‫‪ PS‬إعادة استخدام أقل من المخطط لها‬ ‫‪70%‬‬ ‫‪2‬‬
‫‪ BU‬المستخدم النهائي ال يتقبَّل النظام ويقاومه‬ ‫‪40%‬‬ ‫‪3‬‬
‫‪ BU‬سيجري التشدد في الموعد النهائي للمشروع‬ ‫‪50%‬‬ ‫‪2‬‬
‫‪ CU‬سيحدث فقدان التمويل‬ ‫‪40%‬‬ ‫‪1‬‬
‫‪ PS‬سيغير الزبون المتطلبات‬ ‫‪80%‬‬ ‫‪2‬‬
‫‪ TE‬لن تحقق التكنولوجيا التوقعات‬ ‫‪30%‬‬ ‫‪1‬‬
‫‪ DE‬نقص في التدريب على األدوات‬ ‫‪80%‬‬ ‫‪3‬‬
‫‪ ST‬الكادر غير خبير‬ ‫‪30%‬‬ ‫‪2‬‬
‫‪ ST‬التغيير في الكادر سيكون كثيراً‬ ‫‪60%‬‬ ‫‪2‬‬
‫‪...‬‬ ‫…‬ ‫…‬ ‫‪...‬‬

‫يبدأ فريق المشروع بسرد جميع المخاطر بمساعدة قائمة تفقُّد عناصر المخاطرة‪.‬‬ ‫‪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‬تعني مخاطرة محتملة جداً)‪.‬‬

‫‪ .e‬تقييم أثر المخاطرة‪+‬‬

‫تؤثر ثالثة عوامل في النتائج المحتملة لحدوث مخاطرة وهي‪ :‬طبيعة المخاطرة‪ ،‬ونطاقها‪ ،‬وتوقيتها‪.‬‬
‫‪ ‬طبيعة المخاطرة‬
‫تشير طبيعة المخاطرة إلى المشاكل المحتملة الحدوث عند وقوعها‪ .‬على سبيل المثال‪ ،‬تُعيق واجهة‬
‫خارجية ألجهزة الزبون ُع ِّرفت تعريفاً سيئا ً (مخاطرة تقنية) التصميم المب ِّكر واالختبار‪ ،‬ويُحتمل أن‬
‫تُؤدي الحقاً إلى مشاكل في تكامل النظام‪.‬‬
‫‪ ‬نطاق المخاطرة‬
‫يجمع نطاق المخاطرة شدة المخاطرة (كم هي جدية؟) إلى توزعها الكلي (كم جانبا ً من المشروع سيتأثر‬
‫؟ أو كم زبونا ً سيتأذى؟)‪.‬‬
‫‪ ‬توقيت المخاطرة‬
‫يتعلق توقيت المخاطرة بالسؤال‪ :‬متى ستحدث؟ وكم من الوقت سيستمر الشعور بأثرها؟‪.‬‬
‫‪ ‬تحديد النتائج الكلية للمخاطرة‪+‬‬
‫قد يريد مدير المشروع في معظم الحاالت أن تقع "األشياء السيئة" أبكر ما يمكن‪ ،‬ولكن في بعض‬
‫الحاالت كلما تأ َّخر ذلك كان أفضل‪ .‬ينصح أحد مناهج تحليل المخاطرة بالخطوات التالية لتحديد النتائج‬
‫الكلية للمخاطرة‪:‬‬
‫‪ o‬حدد االحتمال الوسطي لقيمة حدوث كل مكون من مكونات المخاطرة؛‬
‫‪ o‬حدد أثر كل مكون باالعتماد على المعايير المبينة؛‬
‫‪ o‬أكمل جدول المخاطرة وحلل النتائج‪.‬‬
‫تطبَّق تقنيات توقع المخاطرة وتحليلها تكراريا ً مع تقدم المشروع البرمجي‪ .‬يجب على فريق المشروع‬
‫أن يعيد النظر في جدول المخاطرة بشكل منتظم‪ ،‬وإعادة تقويم كل مخاطرة ليحدِّد متى قد تؤدي ظروف‬
‫جديدة إلى تغيير احتمال حدوثها وأثرها‪ .‬وقد يكون ضروريا ً نتيجةً لهذه الفعالية إضافة مخاطر جديدة‬
‫إلى الجدول أو إزالة بعض المخاطر التي لم تعد ذات عالقة‪ ،‬وكذلك تغيير التوضع النسبي للبعض‬
‫اآلخر الباقي‪.‬‬

‫نفحص‪ ،‬خالل تقييم المخاطرة‪ ،‬دقة التقديرات التي أجريت أثناء توقُّع المخاطرة‪ ،‬ونحاول ترتيب‬
‫أولويات المخاطر التي ُك ِشف عنها والبدء بالتفكير بطرائق لضبط و‪/‬أو تجنب المخاطر التي يُحتمل‬
‫حدوثها‪. .‬يتوفر لدينا قبل البدء بتقييم المخاطرة مجموعة من الثالثيات من الشكل ]‪ ،[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‬إدارة المخاطرة والتخطيط للطوارئ‬

‫‪ ‬تخفيف المخاطرة (‪)Risk Mitigation‬‬

‫إذا اعتمد الفريق البرمجي منهجا ً فاعالً إلدارة المخاطرة‪ ،‬فإن التجنُّب هو دوما ً أفضل إستراتيجية‪،‬‬
‫ويتحقق ذلك بتطوير خطة لتخفيف المخاطرة (‪:)Risk Mitigation‬‬
‫‪ o‬االجتماع بالعاملين حاليا ً لتحديد أسباب التغيير (مثل ظروف عمل سيئة‪ ،‬أجور منخفضة‪،‬‬
‫سوق عمل منافسة)‬
‫‪ o‬التصرَّف لتخفيف األسباب التي تقع ضمن سيطرة اإلدارة قبل بدء المشروع‬
‫‪ o‬االفتراض‪ ،‬حالما يبدأ المشروع‪ ،‬بأن التغيير سيحدث‪ ،‬وتطوير تقنيات لضمان االستمرار‬
‫عندما يغادر بعض العاملين‬
‫‪ o‬تنظيم فرق المشروع بحيث يجري توزيع المعلومات حول كل فعالية تطوير توزيعاً‬
‫مناسباً‬
‫‪ o‬تعريف مقاييس للتوثيق‪ ،‬ووضع آليات للتحقق من أن الوثائق تط َّور في الوقت المناسب‬
‫‪ o‬إجراء مراجعات لكامل العمل بحيث يكون هناك أكثر من شخص معتاد لهذا العمل‬
‫‪ o‬تعيين عنصراً احتياطيا ً لكل تقني ذو دور هام‬

‫‪ ‬مراقبة المخاطرة‬
‫ُّ‬
‫تبدأ فعاليات مراقبة المخاطرة مع تقدم المشروع‪ .‬فيراقب مدير المشروع العوام َل التي قد تقدِّم داللة فيما‬
‫إذا كانت المخاطرة ستصبح أكثر أو أقل احتماالً‪ .‬يمكن مراقبة العوامل التالية في حالة التغيير الكبير‬
‫للعاملين‪:‬‬
‫ً‬
‫‪ o‬السلوك العام ألعضاء الفريق اعتمادا على ضغوط المشروع؛‬
‫‪ o‬العالقات الداخلية الشخصية بين أعضاء الفريق؛‬
‫‪ o‬المشاكل المحتملة في التعويضات والفوائد؛‬
‫‪ o‬توافر العمل ضمن الشركة وخارجها‪.‬‬
‫ً‬
‫يجب على المدير إضافةً إلى مراقبة العوامل المذكورة آنفا‪ ،‬أن يراقب فعالية خطوات تخفيف المخاطرة‬

‫‪ ‬إدارة المخاطرة والتخطيط للمخاطر‬

‫تفترض إدارة المخاطرة والتخطيط للطوارئ أن جهود التخفيف قد أخفقت‪ ،‬وأن المخاطرة أصبحت‬
‫حقيقية‪.‬‬
‫ً‬
‫قد يعيد مدير المشروع –مؤقتا‪ -‬تركيز الموارد (وإعادة ضبط الجدول الزمني للمشروع) باتجاه تلك‬
‫الوظائف التي اكتمل فيها عدد العاملين‪ ،‬ممكنا بذلك القادمين الجدد الذين يجب إضافتهم إلى الفريق من‬
‫أن يصلوا إلى السرعة المطلوبة في العمل‪ .‬يطلب من األفراد الذين سيغادرون أن يتوقفوا عن جميع‬
‫األعمال وأن يقضوا أسابيعهم األخيرة في طور نقل المعرفة (‪.)Knowledge Transfer Mode‬‬

‫‪03‬‬
 ‫‪ .7‬تدريبات‪:‬‬

‫‪ -1‬من أهم الصعوبات التي تميز مشااريع تطاوير البرمجياات عان ايرهاا مان المشااريعص صاعوبة التحقاق‬
‫وقياس جودة المنتج ؟ (اختر ‪ 1‬من اإلجابات)‬

‫‪ -0‬صح‪.‬‬
‫‪ -2‬خطأ‪.‬‬

‫(‪)1‬‬

‫(قد يتطلب التحقق من بعض الميزات وقتاً طوي ً‬

‫الص وقد ال تظهر بعض الثغرات إال بعد فترة تشاغيل‬
‫طويلة للمنتج البرمجي)‬

‫‪ -2‬المخاطر القابلة للتنبؤ تستخلص مان الخبارات الساابقةص وخاصاة لادى مادير المشاروع ؟ (اختار ‪ 1‬مان‬
‫اإلجابات)‬

‫‪ -0‬صح‪.‬‬
‫‪ -2‬خطأ‪.‬‬

‫(‪)1‬‬

‫(قدرة مدير المشروع على التنبؤ بالمخاطر هي مؤشر على خبرتهص ومنها تقييم الزبون و القادرة‬
‫على التواصل معهص وتوضيح متطلباته بشكل اير قابل للتأويل)‬

‫‪ -3‬من المخاطر التي يمكن إدراجها تحت تصنيف أثر األعمال‪:‬‬

‫أثر هذا المنتج في عائدات الشركة‪.‬‬ ‫‪-0‬‬
‫هل جميع األدوات البرمجية المستخدمة متكاملة مع بعضها؟‬ ‫‪-2‬‬
‫عدد الزبائن الذين سيستخدمون هذا المنتج وانسجام احتياجاتهم معه‪.‬‬ ‫‪-3‬‬
‫القيود الحكومية على بناء المنتج (إن وجدت)‪.‬‬ ‫‪-4‬‬

‫(اختر اإلجابة الخاطئة)‬

‫(‪)2‬‬

‫(يندرج هذا البند تحت عنوان بيئة التطوير)‬

‫‪ -4‬عند تحديد عوامل الخطورة في حجم الكادر وخبرتهص وفي حال كانات المخااطرة موجاودةص فالن الحلاول‬
‫الممكنة والتي تدرج عادة في الخطة‪:‬‬
‫وجود مرشحين محتملين كبدائل بنفس الخبرة ويمكن توظيفهم‪.‬‬ ‫‪-0‬‬
‫التعاقد مع خبرات خارجية متاح وسلس‪.‬‬ ‫‪-2‬‬
‫امكانية التعاقد الضمني (‪ )Subcontracting‬متاح وممكن‪.‬‬ ‫‪-3‬‬
‫جميع الخيارات السابقة صحيحة‪.‬‬ ‫‪-4‬‬

‫(‪)4‬‬

‫‪04‬‬
‫(يجب على مدير المشروع التفكير فاي هاذا البادائل واألخاذ بعاين االعتباار امكانياة االساتعانة بهاا‬
‫عند الضرورة)‬

‫‪ -5‬تقدير أرجحية المخاطرة يتم بـ‪:‬‬

‫بنا ًء على رأي مدير المشروع‪.‬‬ ‫‪-0‬‬
‫وسطي تقديرات فريق العمل‪.‬‬ ‫‪-2‬‬
‫من التقييمات السابقة لمشاريع مشابهة‪.‬‬ ‫‪-3‬‬
‫بالتشاور مع الزبون‪.‬‬ ‫‪-4‬‬

‫(‪)2‬‬

‫(ماان المفيااد تضاامين رأي أعضاااء فريااق العماال فااي المخاااطر المحتملااةص فهااذا يرفااع ماان وعاايهم‬
‫للمخاطر وأثرها ويحفزهم على بذل الجهد لتالفيها)‬

‫‪05‬‬