مصادر المخاطر
بالنسبة لاختبار النظام فإن الاستخدام المختلف للنظام يرتب بناء على أهميته للمستخدم و العملية المناسبة للنظام
كذلك المخاطر لها ارتباط بلغة البرمجة او الأداة المستخدمة للتطوير

تقنية تحليل المخاطر تشمل ثلاث مهمات :
تحديد الخطر : كل حالة استخدام للنظام تكلف جهد في عملية التطوير و تحتوي على مخاطرة .. فتصنف كالتالي ( مرتفع - متوسط - منخفض - وربما مرتفع جداً)
قياس المخاطرة
إصدار قائمة مرتبة لحالات الاستخدام

مستويات المخاطر
استراتيجية الحذر : اختيار أعلى قيمة
استراتيجية المتوسط : اختيار قيمة بين قيمتين

المشاكل التي يجب حلها لتعطي شكل أساسي لعملية الاختبار هي :

مشاكل التخطيط : اختبار النماذج - اختبار الـ Calss - اختبار التفاعل - اختبار النظام - اختبار الـ Regression

أسئلة :

من يقوم بعملية الاختبار ؟
المطورون - المختبرون المستقلون - مجموعة مكونة من الاثنين

ماهي الأجزاء التي سيتم اختبارها ؟
اختبار لا شيء - اختبار عينة - اختبار كل شيء - اختبار الأعلى مخاطرة

متى يتم عمل الاختبار ؟
كل يوم - اختبار العناصر كما طورت - اختبار جميع العناصر في نهاية المشروع - اختبار عند نقاط تسليم محددة

كيف يتم الاختبار ؟
بمعرفة المواصفات فقط - بمعرفة المواصفات و طريقة التنفيذ

How much testing is adequate?
No testing, exhaustive testing (consider the expected lifetime of the software), is the software life-critical,

Coverage: is a measure of how completely a test suite exercises the capabilities of a piece of software

تحليل المخاطر جزء من العملية التخطيط و التطوير
المخاطر هي : أي شيء يهدد التحقيق الناجح لأهداف المشروع

الخطر هو حدث له بعض احتماليات الحدوث ، وعند حدوثه سيكون هناك شيء من خسارة ( سواء في الوقت أو في المادة )

المبدأ الأساسي للاختبار المعتمد على المخاطر هو : قم باختبار الأجزاء الأثقل وزناً في النظام التي يمكن أن تضع المشروع في مخاطر كبيرة لكي تضمن أن الأخطاء الأكثر تأثيراً قد تم تحديدها.

أنواع المخاطر :

مخاطر المشروع
تشمل المخاطر الإدارية و البيئية مثل : عدم وجود شخص مؤهل بدرجة كافية
مخاطر عملية
ترتبط بمفاهيم مجال العمل المشترك و المهام الرئيسة فيه مثل : تغيير على بورصة التأمين الصحي
مخاطر تقنية
تشمل المفاهيم في التنفيذ مثل جودة الشفرة المصدرية

تحليل المخاطر
طريقة تحديد المخاطر لإيجاد طرق لتفادي أن تصبح المشاكل حقيقية

نتيجة تحليل المخاطر هي قائمة بالمخاطر المحددة حسب درجة الخطر فيها .. هذا يساهم في توزيع المصادر المحدودة لترتيب أولوية القرارات

المخاطر في المشاريع الكائنية التوجه OO لها هذه الخصائص الهيكلية :

• تفاعل معقد بين الـ Objects
• سلوك معقد مرتبط بخصائص الـ Classes
• تغيير أو تطور في مواصفات المشروع
• تعقيد الـ class يقاس بحجم مواصفاته
• عدد العلاقات : الـ class مع الـ classes الأخرى

• عمليات الاختبار الأساسية : الاختبار المبكر Early - الاختبار المعتاد Often - الاختبار الكافي Enough

• العنصر الأساسي للاختبار هو حالات الاختبار Test cases

• حالات الاختبار تتكون من :

1 - المدخلات: وصف المدخلا تاتي يتم إدخالها إلى البرنامج وقت الاختبار
2 - المخرجات المتوقعة : وصف للمخرجات التي من المفترض أن يخرجها البرنامج بناء على المدخلات السابقة

• لا يشترط أن تكون المدخلات و المخرجات مبسطة بل قد تكون معقدة جداً و عشوائية

• تنفيذ حالات الاختبار : هي تشغيل البرنامج الذي تم إدخال المدخلات فيه ثم ملاحظة المخرجات و مقارنتها بالنتائج المتوقعة لحالات الاختبار

• اختبار المجموعات : اختبار له ترتيب و تنظيم يعتمد على أنواع حالات الاختبار مثل اختبار مجموعة سعة النظام

• سلبيات اختبار المجموعات :

الصحة Correctness
ملاحظة النتائج Observability of results
الكفاية Adequacy

• تقنية STEP Testing

التحليل
اختبار المنتج لتحديد أي خاصية معينة تستلزم عناية خاصة و كذلك تحديد حالات الاختبار التي تستلزم التشييد
التشييد
يتم إنشاء النتائج التي نحتاج إليها للاختبار .. بالنسبة لحالات الاختبار فيتم تحديدها أثناء ترجمة التحليل إلى لغة البرمجة
التنفيذ و التقييم
بحيث تكون النتائج محددة هل البرنامج تجاوز الاختبار أم لا

• التطوير الكائني الموجه هو أكثر الأنواع ملائمة للتطوير المسمى Evolutionary

• لأن التصميم و التنفيذ و التحليل في OO يستلزم التحسين الناجح في كل نموذج

• في مرحلة التحليل في OO فأننا نفهم المشكلة عن طريق تمثيلها بـ classes و Objects و العلاقات بينها

• في مرحلة التصميم في OO فإننا نحل المشكلة بالتعامل مع الـ Objects المتشابهة و العلاقات بينها التي تحددت في مرحلة التحليل .. ثم نقدم الحل الخاص بالـ classes , objects, relationships and responsibilities

• الاختبار لابد أن يتم في كل مرحلة

• Regression Test لابد أن يكون بين المراحل Increments و خلال الدورات Iterations

• التطوير و الاختبار بينهما عوامل مشتركة وتتقاطع أنشطة كل واحد منهما مع الآخر عندما نقوم بتصميم و تنفيذ حالات الاختبار test cases مهام التطوير و مهام الاختبار عادة تسند إلى أشخاص مختلفين

• قابلية الاختبار Testability : تعني إلى أي مدى من السهولة يمكنك تقييم نتائج الاختبارات

• الاختبار يحتاج إلى الكثير من المصادر

• الاستخدام الأمثل و الأكثر فعالية لهذه المصادر يتطلب تخطيطاً جيداً و إدارة جيدة

• في المرحلة التقنية Technical level فإن التخطيط يسير حسب قالب محدد حسب حاجة المطورين مثل IEEE test plan standard

• ما هي العملية process ؟

هي سلسلة مستمرة من الأنشطة التي توصلك إلى نهاية محددة

• الأنشطة الأربعة الرئيسة للبرنامج هي

التحليل
ترتكز على فهم المشكلة و تحديد المتطلبات لأجزاء النظام
التصميم
تركز على حل مشاكل النظام
التنفيذ
تركز على تحويل التصميم إلى شفرة قابلة للتنفيذ
الاختبار
تركز على ضمان أن تكون المخرجات للنظام مطابقة للمتطلبات المحددة و المطلوبة

أعطانا المدرس اليوم دراساً لا ينسى في مادة الإحصاء..
ياويلك تنسى الآلة الحاسبة

ضاق خلقي كثيرا .. الاختبار سهل بس الحاسبة خانتني
طبعاً القانون .. ممنوع الإستلاف ممنوع إستخدام الجوال

يالله الحمدلله، لعل هذا درس عشان ما ننساه وقت المياجر

دار نقاش في محاضرة اليوم حول مشروع التخرج .. حيث أننا درسنا في هندسة البرمجيات أن هناك عدة طرق لتطوير المشاريع كالبرمجة القصوى (Extream Programing) و نموذج اللولب (Spiral Model) والبرمجة المتزايدة (Incremental development) وغيرها ..

و مع تعدد الطرق .. إلا أننا ملزمين باستخدام نموذج الشلال (Waterfall Model) ..

وهنا أثير النقاش .. عن سبب إلزامنا في مشروع التخرج بالعمل على هذا النموذج .. مع وجود غيرها من النماذج اللتي قد تكون أفضل منها في إنجاز المشروع ..

وهنا أتت الإجابة المقنعة من الدكتور محمد الشايب .. فيقول:

إن سبب إلزام الطلاب بنموذج الشلال The Waterfall Model هو لعدةأسباب أهمها:

 

1. أنها النموذج الأفضل للتعليم .. حيث أن كمية الخبرة اللتي يكتسبها الطالب خلال عمله بالمشروع إذا كان يستعمل نموذج الشلال هي أكثر من غيرها من النماذج خلال هذه الفترة القصيرة (سنة دراسية واحدة)
2. أنها مناسبة جدًا عندما تكون المتطلبات كاملة من العميل Full Requirements
3. أنها ما زالت تستخدم في بعض الشركات والمؤسسات

وبهذا أقتنعت نوعــًا ما بتحمل العمل على هذا النموذج .. حيث أنني لا أحبذه شخصيــًا ..

مشاريع تقنية المعلومات IT في ازدياد متسارع و بنسب كبيرة جداً ففي عام 2005 بلغت أكثر من 1.8 تريليون بزيادة نسبة مقدارها 6% عن العام 2004 ثم استمرت الزيادة بنسبة 8 % في العام 2006 و بنسبة 4% في العام 2007.

ولعل من أبرز الإحصاءات في مجال المشاريع التقنية هي الإحصاءات التي تقوم بها مجموعة Standish Group و التي ذكرت أنه في العام 2005 كانت نسبة المشاريع التقنية الناجحة 16.2% فقط .. بينما 31% ألغيت تماماً قبل اكتمالها و كلفت في الولايات المتحدة لوحدها 81 بليون دولار !!

بسبب هذه الأرقام برزت الحاجة إلى وجود نظام و معايير عالمية في إدارة المشاريع للسعي الحقيقي نحو نجاحها وهذا النظام سيحقق عدد كبير جداً من الأهداف منها على سبيل المثال :

• تحكم أفضل للموارد المالية و البشرية
• تقوية العلاقات بالعملاء
• وقت أقصر في بناء المشروع و تطويره
• تكلفة أقل
• جودة أعلى وزيادة في الوثوقية reliability
• ارتفاع هوامش الربح
• زيادة الإنتاجية
• تنسيق داخلي جيد

نعود الآن لـ Standish Group  وونعرض هذه الإحصائية

stat

ذكروا أن أسباب هذه الزيادة في نسبة نجاح المشاريع تعود إلى أسباب متنوعة منها :

• معدل تكلفة للمشاريع قل بمعدل النصف
• وجود أدوات أجود لمتابعة المشاريع و التحكم في سير العمل
• الاهتمام بمهارات إدارة المشاريع بشكل أكبر من السابق
• استخدام عمليات ومسارات الإدارة بشكل أكثر من السابق

بسم الله الرحمن الرحيم

هنا بداية انطلاقة التلاخيص و الفوائد التي تمر بي في هذا الكورس الرائع : إدارة المشاريع
متحمس جداً خاصة أنه بداية لمشروع التخرج الذي سنبدأ به خلال أسابيع من الآن
لكل مهتم بمتابعة هذه المادة و معرفة بعض أسرارها و فوائدها
تابعونا هنا