تصميم كوبر التفاعلي

Cooper Interactive Design

 

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

 

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

 

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

 

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

 

1.    مرحلة الأبحاث (Research):

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

·        المقابلات مع كل من له علاقة بالنظام من الأفراد.

·        مراجعة المقالات والتقارير والمواد المقروءة أو المرئية والتي لها علاقة بالنظام

·        ملاحظة المستخدمين المتوقعين للنظام ومحاولة تحليل سلوكهم في العمل والتفاعل معه

 

2.    مرحلة وضع النماذج (Modeling):

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

 

3.    مرحلة تعريف المتطلبات (Requirements Definition)

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

 

4.    مرحلة تعريف إطار العمل (Framework Definition)

في هذه المرحلة يقوم فريق عمل كوبر ببناء مسارات للنظام أقرب ما تكون للطبيعية (طبيعية تعني كما تتم في النظام على أرض الواقع) ومن خلالها يقومون بتعريف الميزات والوسائل التي تمكن كل عنصر من عناصر النظام من تحقيق متطلباته بيسر وسهولة. ليخرجوا في النهاية برؤية واضحة للتصميم.

 

5.    مرحلة التصميم (Design)

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

 

6.    مرحلة دعم التطوير (Development Support)

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