لا توجد منتجات في سلة المشتريات.
اختبارات التكامل بين الأنظمة وتحدياتها أكبر من تصورات أغلب مدراء المشاريع
0 تعليق
ما اكتشفته خلال سنوات عملي كمدير للمشاريع التقنية أن أكبر خطر على نجاح المشاريع التقنية في المؤسسات الكبرى هو التكامل Integration.
يكون التكامل على مستويين:
- على مستوى إدارة المشاريع والإجراءات المتعلقة بها وهي مهمة مدير المشروع
- على مستوى تكامل الأنظمة والتواؤم التقني الفني والإداري، وهي مهمة مدير المشروع بصورة اساسية ولكن يشارك معه عدد كبير من فريق المشروع.
يصل فريق المشروع لمرحلة اختبار النظام من دورة حياة تطوير النظم SDLC مع عدد معتبر من التحديات ويكون فريق اختبار النظام تحت ضغط مهول من جميع الأطراف لإكمال الاختبارات في أقرب وقت وبنجاح -برغم أن نجاح الاختبارات ليس بمسؤوليتهم- لذلك وجب على مدير المشروع أن يهتم بدقة وتفصيل ومبادرة بتكامل الاختبارات.
في هذه التدوينة سأتطرق لتحديات ومهام ونقاط قطعاً ستواجهك كمدير مشروع للأنظمة إذا كنت مديراً لتطوير نظام كبير (مؤسسي) يتكامل مع عدد من الأنظمة. ولا ينفي ذلك أن مدراء المشاريع المتوسطة والصغيرة سيواجهون بعض هذه التحديات كذلك.
تضارب المصالح بين الموردين
في حال لم تكن معتاداً على سماع مسمى “مورد” فالمورد هو الشركة التي تتعاقد معها من أجل تنفيذ مهمة محددة.
التعاقد مع الموردين المحترفين والمتخصصين أحد النعم في عالم المشاريع التي تساعد على إنجاز المشاريع الكبيرة بمشاركة عدد كبير من الموردين (الفرق) بحيث يؤدي كل مورد مهمة محددة سلفاً من قبل مدير المشروع. ويتبقى على مدير المشروع الحرص على تكامل جميع مخرجات الموردين بنجاح.
كل مورد يحرص تمام الحرص على أمرين:
- أن يكمل جميع مهامة، ومهامه فقط دون زيادة.
- أن يحرص على مصالحه، ومن أكثرها شيوعاً عدم تلقي الملامة على فشل المشروع وتقليل التكاليف.
ستجد خلال سير المشروع أن هناك تضارباً بين مصالح الموردين والتي يجب عليك إدارتها لأنها من أهم مسببات تدني مؤشرات نجاح المشروع.
مثلاً، إن لم يخطط بصورة جيّدة للمشروع، ربما تواجه معضلة أن أيام عمل الموردين الرسمية تختلف بينما يحتاج الموردون للعمل سوياً. وكل مورد يرفض أن يطلب من موظفيه العمل في أيام العطلة لأن ذلك سيكلفه أجور إضافية.
الموردين الذين يتعامل معهم مدير المشروع خلال مرحلة الاختبار هم موردي تطوير النظام، وموردي تحليل النظام، وموردي اختبار النظام، وأصحاب مصلحة نقاط التكامل.
لا يوجد حل سحري لتحديات العمل مع الموردين، أفضل ما يقلل من مخاطر العمل مع الموردين هو التخطيط فوق الممتاز وبناء علاقة مربحة للطرفين والمحافظة عليها. بقية المهارات سيكتسبها مدير المشروع أثناء عمله على أرض الواقع.
الهيكل الصحيح للمشروع والمسؤول الحقيقي عن إدارة اختبارات التكامل
التوقعات الخاطئة قاتل صامت لنجاح مرحلة اختبارات النظام.
يرزح مختبروا النظم تحت ضغط هائل من الإدارات المختلفة حولهم أثناء مرحلة اختبار النظام بسبب التوقعات الخاطئة وهو ما قد يؤدي بمختبري النظام كفريق وأفراد إلى تدني في الأداء أو ضعف في الولاء أو قلة في الجودة.
بمفهوم خاطئ تماماً يحمل بعض مدراء المشاريع وكثير من الإدارات مختبري النظام مسؤولية نجاح الاختبارات، وهو في حقيقة الأمر ليس في نطاق مسؤوليتهم المهنية اطلاقاً. وأعتبر أن هذا التوقع هو أكبر سبب لفشل اختبارات التكامل والاختبارات المعتادة كذلك!
فمختبر النظام يُساءل عن إكمال الاختبارات المخطط لها فقط، ومن الممكن أن تكون نتيجة جميع الاختبارات الفشل. فمرحلة اختبار النظام هي نقطة تحقق من جودة مخرجات مطوري النظام، وفي حال ارتفاع كفاءة الاختبارات وانخفاض جودة التطوير سيكون ناتج الاختبار فشل فحص النظام وهي النتيجة المطلوبة حقاً وحقيقة من مختبري النظام الفعليين.
يجب على مدير المشروع أن يتأكد أن المفهوم الصحيح لاختبار النظم ومسؤوليات الاختبار والنتائج المتوقعة ومسبباتها واضحة لجميع الأطراف وأهمهم الإدارة العليا.
ولا ننسى أن اختبار النظم يتم في شكل دورات، في كل دورة تُنفذ الاختبارات المخطط لها وتُشارك النتائج مع مطوري النظام لحل أخطاء النظام، وبعد حل الأخطاء تبدأ دورة أخرى للتحقق من سلامة النظام من الأخطاء مرة أخرى.
تعدد دورات الاختبار يعني -في الغالب وليس دائماً- انخفاض جودة النظام المطور وعدم توائمه مع متطلبات النظام، وتعدد الاختبارات يؤدي إلى تمدد الوقت المخطط للاختبار وبالتالي وفي الأغلب تمدد وقت تنفيذ المشروع كذلك.
فما لم تكن الإدارات المحيطة بالمشروع واعية بمفاهيم الاختبار ومسؤوليات كل طرف فإنها ستضع الملامة والضغط على مختبري النظام خطئاً متوقعين أن ذلك سيحل المشاكل بينما النتيجة الحتمية هي انغماس أعمق في بركة ضحلة من التحديات التي قد تؤدي إلى فشل المشروع كليةً.
استغلال أدوات التكامل في تسريع اكتشاف أخطاء التكامل
يخطط مختبرو النظم لاختبارات التكامل قبل أو أثناء تطوير النظام، ويكتبوا حالات اختبار النظام والتي تستخدم لاحقاً في توزيع الأعمال بين مختبري النظم.
لأنني أعتبر أن نجاح تكامل الأنظمة من أهم أسباب نجاح المشروع فهناك مهمة أهتم بوجودها وتنفيذها عندما أدير مثل هذا النوع من المشاريع.
المهمة هي الاختبار التقني لنقاط التكامل فور اكتمال تطويرها، حتى لو لم يكتمل تطوير النظام.
من ناحية مفاهيمية، نقطة التكامل تكون لديها احدى المهمتين التاليتين أو كلاهما:
- إرسال البيانات إلى الطرف الآخر.
- استقبال البيانات من الطرف الآخر.
وفور أن ينتهي الطرف الآخر من ميكانيكية إرسال واستقبال البيانات احرص على أن تكون هناك مهمة لاختبار إرسال واستقبال البيانات حتى لو لم يكن النظام على الطرف الآخر جاهزاً لأداء هذه المهمة.
وطريقة أداء هذه المهمة هي عبر استخدام أدوات تقنية مثل برنامج SoapUI لمحاكاة البيانات التي سترسل وقراءة البيانات المعادة ومقارنتها مع مستند المتطلبات. وفي حال وجود مهام متوقعة من الطرف الذي أكمل التطوير مثل تخزين البيانات أو أداء مهام عند استقبال البيانات من الممكن أن يتدخل مختبروا النظام بتقديم حالات الاختبار المتعلقة بالطرف الجاهز وتنفيذها بشكل مستقل قبل أن تُنفذ بعد اكتمال التكامل.
في النهاية..
ما رأيك في هذه التحديات والنصائح؟ أعتقد أنها شائعة وربما قد مر بك بعضها. سيسعدني أن تضيف إليها أو تعدل فيها بناءً على خبرتك ونوع المشاريع التي أدرتها وتضعها في التعليقات أدناه. وإن أردت جزءاً آخر من تحديات ونصائح تكامل الأنظمة لا تنسى ذكر ذلك في التعليق. شكراً لك.