[ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط]يمكن وصف عملية البرمجة كما هو مبين في الشكل أدناه. حيث يوضع هيكل عام لعملية البرمجة common process framework وذلك بتعريف عدد صغير من نشاطات الهيكل التي يمكن تطبيقها على جميع المشاريع البرمجية بغض النظر عن حجمها أو تعقيدها، وعدد من مجموعات المهام حيث كل منها عبارة عن مجموعة من: مهام عمل هندسة البرامجيات، معالم مشروع، منتجات عمل برمجية ونواتج، ونقاط ضمان الجودة( التي تمكّن من تكييف نشاطات الهيكل مع خصائص المشروع البرمجي ومتطلبات فريق العمل في المشروع ). وأخيراً تغلف نشاطات المظلة نموذج عملية البرمجة. إن نشاطات المظلة مستقلة عن أي نشاط للهيكل، وهي حدث يجري طوال عملية البرمجة.
[ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط]هنالك إلحاح شديد في السنوات الأخيرة على نضج عملية البرمجة وقد طور معهد هندسة البرامجيات SEI نموذجا شاملا يستند إلى مجموعة من مقدرات هندسة البرامجيات التي يجب أن تكون مكتسبة مع وصول المؤسسات إلى مستويات مختلفة من نضج عملية البرمجة. ولتحديد حالة المؤسسة الراهنة لنضج عملية البرمجة يستعمل معهد الـ SEI استمارة تقييم وسلم تصحيح ذي خمسة مستويات. يحدد سلم التصحيح هذا مدى التوافق مع نموذج نضج القدرات CMM (Capability Maturity Model) (الذي يعرف نشاطات أساسية مطلوبة على مستويات مختلفة من نضج عملية البرمجة. يرسم منهج معهد الـ SEI خمسة مستويات لنضج عملية البرمجة تعرّف على النحو التالي:
المستوى 1: ابتدائي- توصف عملية البرمجة بأنها منسابة ad hoc وأحيانا فوضوية chaotic .
عمليات برمجة قليلة فقط هي المحدد جيداً، ويعتمد نجاحها على المجهود الفردي.
المستوى 2: متكرر - توضع عمليات برمجة أساسية لإدارة المشروع وذلك لمتابعة الكلفة والجدول الزمني والوظائفية، ويكون نظام عملية البرمجة الضروري جاهزا لتكرار النجاحات السابقة التي حصلت في المشاريع ذات تطبيقات مشابهة.
المستوى 3: معرّف - تكون عملية البرمجة للنشاطات الإدارية الهندسية موثقة وقياسية ومتكاملة مع عملية البرمجة لكل المؤسسة. تستخدم جميع المشاريع نسخة مصدقة وموثقة من عملية المؤسسة لتطوير وصيانة البرامجيات. يتضمن هذا المستوى جميع الخصائص المعّرفة للمستوى 2 .
المستوى 4: مُدار – يجمع قياسات تفصيلية لعملية البرمجة وجودة المنتج. وتفهم كل من عملية البرمجة والمنتجات كمّياً، ويتحكم بهما باستخدام قياسات تفصيلية. يتضمن هذا المستوى جميع الخصائص المعّرفة للمستوى 3.
المستوى 5: مثالي – تتحقق تحسينات مستمرة على عملية البرمجة بتكرار كمية منها، ومن اختبار أفكار وتكنولوجيات مبتكرة. يتضمن هذا المستوى جميع الخصائص المعّرفة للمستوى 4.
نماذج عملية البرمجة :
لكي يتمكن مهندس البرمجيات أو فريق المهندسين من حل مسائل حقيقية في بيئة صناعية، عليهم استخدام إستراتيجية تطوير تشمل(عملية البرمجة، الطرق وطبقات الأدوات المشروحة سابقا، والمراحل العامة التي ناقشناها، عادة تسمى هذه الإستراتيجية (نموذج عملية البرمجة) Process mode أو (نموذج هندسة البرمجيات). يتم اختيار نموذج عملية هندسة البرمجيات بناءً على طبيعة المشروع أو التطبيقات، الطرق والأدوات المستخدمة، والتحكم والأداء المطلوبين.وقد استخدم L.B.S. [RAC95] Raccoon في مقالته العلمية المثيرة للاهتمام حول طبيعة عملية البرمجة : Fractals (المتشابهات ذاتياً أو المتجزّئات) أساساً لمناقشة الطبيعة الحقيقية لعملية البرمجة.
يمكن وصف كل التطوير البرمجي بحلقة لحل أي مشكلة (الشكل أدناه) حيث تواجه أربع مراحل مختلفة هي : الوضع الراهن (Status quo)، وتعريف المشكلة، والتطوير التقني، ومكاملة الحل .
[ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط]يمثل الوضع الراهن "الحالة الراهنة للمشكلة" [RAC95]، إما تعريف المشكلة فيميز المشكلة المحددة المطلوب حلها، في حين إن التطوير التقني يحل المشكلة عن طريق تطبيق تكنولوجيا ما، ومكاملة الحل تقدم النتائج (كوثائق، برامج، بيانات، وظائف الإعمال الجيدة، منتج جديد) لأولئك الذين طلبوا الحل أول مرة يمكن إسقاط الخطوات والمراحل العامة لهندسة البرمجيات بسهولة على هذه المراحل.
تنطبق حلقة حل المشكلة الموصوفة سابقاً على إعمال هندسة البرمجيات عند عدة مستويات مختلفة، ويمكن استخدامها عند المستوى الماكروي (Macro Level ) عند النظر إلى كامل التطبيق أو البرنامج، وعند المستوى المتوسط عندما تتم هندسة مكونات البرنامج، أو حتى عند مستوى كتابة شيفرة البرنامج. لذا يمكن استخدام تمثيل المتجزئات (Fractals)( ) ، لتقديم رؤية مثالية لعملية البرمجة، تتضمن كل مرحلة في حلقة حل المشكلة وهكذا (يستمر هذا إلى حد معقول، في البرمجيات : سطر من الشيفرة).
يصعب واقعياً تقسيم النشاطات إلى أجزاء مستقلة تقسيماً أنيقا كما يوحي الشكل أعلاه (a ) وذلك بسبب وجود تداخل ضمن المراحل وفيما بينها، ومع ذلك تقود هذه الرؤية المبسطة إلى فكرة هامة جداً وهي انه : بغض النظر عن نموذج عملية البرمجة المختارة للمشروع البرمجي فان جميع المراحل ( الوضع الراهن، تعريف المشكلة، التطوير التقني، مكاملة الحل) تتواجد معاً بمستوى معين من التفصيل، وبملاحظة الطبيعة التكرارية للشكل أعلاه (b) فان المراحل الأربع المناقشة سابقاً تنطبق بنفس القدر على تحليل تطبيق أو برنامج كامل أو على توليد مقاطع صغيرة من الشيفرة.
يقترح [RAC95] Raccoon نموذجاً فوضوياً (chaos model) وهو يصف تطوير البرمجيات كاستمرار من المستخدم إلى المطور إلى التكنولوجيا. ومع تقدم العمل نحو إنشاء نظام متكامل، يتم تطبيق المراحل الموصوفة سابقاً تطبيقاً متكرراً وفقاً لمتطلبات المستخدم والمواصفات التقنية للبرمجيات التي يضعها المطور.
ستناقش الفقرات القادمة نماذجاً مختلفة للعمليات برمجة في هندسة البرمجيات يمثل كل نموذج منها محاولة لإضفاء ترتيب وتنظيم على نشاط فوضوي (غير منتظم). ومن المهم أن نتذكر إننا قد شرحنا كل نموذج من النماذج بطريقة تساعد على التحكم والتنسيق في المشاريع البرمجية الحقيقية، ومع ذلك يبدي جميع النماذج بعض خصائص النموذج الفوضوي.
1. بناء ثم إصلاح Build-and-Fix :
من المؤسف أن يكون هنالك العديد من المنتجات قد طورت باستخدام ما يسمى طريقة بناء-ثم-إصلاح. حيث إن المنتج الذي بني دون محددات أو أي محاولة للتصميم. بدل ذلك، فان المطورين بكل بساطة يقومون ببناء المنتج ويعيدون العمل عليه بقدر عدد المرات الضرورية لإرضاء الزبون. وهذه الطريقة موضحة في الشكل التالي:
شكل يوضح نموذج بناء-ثم-إصلاح
تعمل هذه الطريقة بصورة جيدة على تمارين البرمجة ذات طول يتراوح من 100 إلى 200 سطر. إن هذا الموديل بصورة عامة لا يستخدم لبناء منتج، مهما كان حجمه معقول. حيث إن كلفة التغيرات على منتج برمجي تكون صغيرة إذا ارتبطت مع طور التحليل، تحديد متطلبات، أو التصميم. ولكنها تكبر و تتنامى بصورة غير مقبولة إذا حدثت التغيرات بعد وضع شيفرة البرنامج، وتكون أسوء إذا كان البرنامج في طور العمل. لذالك فان كلفة طريقة بناء-ثم-إصلاح هي في الواقع اكبر بكثير من كلفة المنتجات المصممة جيدا أو الموضوع محددات لها بصورة مناسبة. بالإضافة إلى ذلك فان الصيانة المنتج ممكن أن تكون صعبة جداً من دون توثيقات وضع المحددات والتصميم، وفرص الوقوع في الأخطاء ابر بصورة ملحوظة.
2. النموذج ألتتابعي الخطي :
يوضح الشكل أدناه النموذج ألتتابعي الخطي (Linear sequential) لهندسة البرمجيات يقترح هذا النموذج الذي يسمى أحياناً "دورة الحياة التقليدية"أو"النموذج ألشلالي"(waterfall model) منهجاً تتابعياً منتظماً( ) .لتطوير البرمجيات، يبدأ عند مستوى النظام ويتقدم تباعاً إلى التحليل فالتصميم فالتشفير فالاختبار فالصيانة.
يشتمل النموذج ألتتابعي الخطي، الذي جرت نمذجته على شاكلة الدورة الهندسية المألوفة، على النشاطات التالية:
أ. هندسة ونمذجة النظام / المعلومات : نظراً إلى إن البرنامج هو دوماً جزء من النظام أو (إعمال) اكبر فان العمل يبدأ بوضع متطلبات لجميع مكونات النظام ، ثم تخصيص مجموعة جزئية من هذه المتطلبات للبرنامج وهذه الرؤيا للنظام أساسية عندما يجب ربط البرنامج بالمكونات الأخرى، مثل العتاد والأشخاص وقواعد البيانات . تشمل هندسة النظام وتحليله على تجميع المتطلبات عند مستوى النظام، مع قدر بسيط من التحليل والتصميم عند المستوى الأعلى . أما هندسة البرنامج فتشتمل على تجميع المتطلبات عند المستوى الاستراتيجي للأعمال وعند مستوى مجال الأعمال.
ب. تحليل متطلبات البرنامج : تتوقف عملية تجميع المتطلبات وتركز على البرنامج بوجه خاص، وحتى يفهم المهندس (المحلل) طبيعة البرنامج أو (البرنامج) المطلوب بناؤه، يجب عليه فهم نطاق معلومات البرنامج، إضافة إلى الوظيفة أو السلوك والأداء والواجهات المطلوبة، ويجب أن يجري توثيق متطلبات النظام والبرنامج ومراجعتها مع الزبون.
ج. التصميم : تصميم البرمجيات هو عملية برمجة متعددة الخطوات تهتم بأربع مميزات للبرنامج :- ( بنية البيانات، بنيان البرمجية، تمثيلات الواجهة، وتفاصيل عملية البرمجة (الخوارزمية)) تقوم عملية التصميم بترجمة المتطلبات إلى تمثيل البرمجيات يمكن تقييمه من حيث الجودة قبل البدء بتوليد الشقرة وكما جرى للمتطلبات يتم توثيق التصميم بحيث يصبح هذا التوثيق جزءً من تشكيلة البرنامج .
د. توليد الشفرة : يجب ترجمة التصميم إلى صيغة تستطيع الآلة ( الكومبيوتر) قرأتها وتقوم بهذه المهمة مرحلة توليد الشفرة وإذا نفذ التصميم بطريقة مفصلة يمكن عندها تحقيق توليد الشفرة ميكانيكياً .
ه. الاختبار : يبدأ اختبار البرنامج حال توليد الشفرة وتركز عملية الاختبار على منطقية العلاقات الداخلية للبرنامج بحيث تضمن اختبار جميع العبارات وعند مستوى العلاقات الخارجية أي تنفيذ اختبارات لكشف الأخطاء ولضمان أن الدخل المعرف سيعطي نتائج فعلية تتوافق مع النتائج المطلوبة.
و. الصيانة : تخضع البرمجيات بلا شك لتعديلات بعد تسليمها للزبون (الاستثناء المحتمل هو برمجيات الأجهزة،embedded software)، يتم التغيير بسبب الأخطاء التي جرت مواجهتها، أو لأنه يجب تكييف البرمجيات لتستوعب التغييرات في بيئتها الخارجية ( مثال: يطلب تغيير بسبب شراء نظام تشغيل جديد أو جهاز جديد)، أو لان الزبون طلب تنفيذ تحسينات على الأداء أو الوظيفة عند تنفيذ الصيانة، ستطبق كل مرحلة من المراحل السابقة على البرنامج الموجود عوضاً عن تطبيقها على برنامج جديد.
إن النموذج ألتتابعي الخطي هو النموذج الأقدم والأكثر استخداماً لهندسة البرمجيات، إلا إن النقد الذي تم التعرض له في البدء أدى إلى التشكيك في فعاليته، حتى من داعميه النشطين [HAN95]، من المشاكل التي تظهر أحيانا عند تطبيق النموذج ألتتابعي الخطي هي :
1. نادراً ما تتبع المشاريع الحقيقية التقدم ألتتابعي الذي يقترحه النموذج ، ومع إن النموذج الخطي يمكن أن يستوعب التكرار، إلا انه يفعل ذلك بأسلوب غير مباشر، ونتيجة لذلك، قد تسبب التعديلات ارتباكا (فوضى) مع تقدم فريق المشروع.
2. يصعب غالبا على الزبون طرح جميع متطلباته بوضوح، والنموذج الخطي يحتاج إلى ذلك، ولهذا تبرز صعوبات في استيعاب عدم التحديد الطبيعي للمتطلبات الذي يتم في العديد من المشاريع.
3. يجب أن يتحلى الزبون بالصبر، إذ لن تتوفر نسخة عاملة من البرنامج أو (البرامج) حتى وقت متأخر من الجدول الزمني للمشروع، وقد يكون الخطأ الفادح كارثيا إذا لم يكشف إلا عند مراجعة البرنامج العامل (المنتج النهائي).
4. غالبا ما يتأخر المطورون لأسباب غير ضرورية ، فقد وجد [BRA94] Bradac في تحليل مثير للاهتمام إن الطبيعة الخطية لدورة الحياة التقليدية تقود إلى "حالات انتظار"(blocking states) يضطر فيها بعض أعضاء فريق المشروع أشخاص آخرين من الفريق لإنهاء مهام مترابطة (غير مستقلة)، وفي الواقع قد يتجاوز وقت الانتظار هذا الزمن المصروف على إعمال منتجة هناك مثل كان تحصل حالات انتظار بكميات اكبر في بداية ونهاية عملية البرمجة التتابعية الخطية.
ومع إن كل هذه المشاكل هي مشاكل حقيقية، إلا إن لنموذج دورة الحياة التقليدية مكانا محددا وهاما في عمل هندسة البرمجيات، فهو يزودنا بقالب توضع فيه طرق للتحليل والتصميم والتشفير والاختبار والصيانة ولا تزال دورة الحياة التقليدية لهندسة البرمجيات هي نموذج عملية البرمجة الأكثر استخداماً.وبالرغم من وجود نقاط ضعف فيها، إلا أنها أفضل بكثير من تطوير البرمجيات وفق منهج المصادفة.
3. نموذج "النمذجة الأولية" :
غالبا ما يعرف الزبون مجموعة من الأهداف العامة للبرنامج، ولا يحدد بالتفصيل كل متطلبات الدخل أو المعالجة أو الخرج، وقد يكون المطور في حالات أخرى غير متأكد من فعالية الخوارزمية، أو من تكيف نظام التشغيل، أو الشكل الذي يجب أن يأخذه تفاعل الإنسان مع الآلة، لذلك فان نموذج النمذجة الأولية (Prototyping Paradigm) يقدم الطريقة الفضلى في هذه الحالات وحالات كثيرة غيرها.
تبدأ النمذجة الأولية (الشكل أدناه) بجمع المتطلبات لذلك يجتمع المطور والزبون لتعريف الأهداف الإجمالية للبرنامج، وتحديد أية متطلبات معروفة، وتحديد عناوين المجالات التي تتطلب تعريفات أكثر ويوضع عندئذ "تصميم سريع" يركز التصميم السريع على تمثيل نواح محددة من البرنامج، وخاصة تلك التي ستكون مرئية للزبون أو المستخدم (كطرق الإدخال وصيغ الإخراج) يقود التصميم السريع إلى نموذج أولي (Prototype) ، يعيد الزبون أو المستخدم تقييم النموذج الأولي ويستخدم ذلك التقييم لتصفية متطلبات البرنامج التي يجب تطويرها ويحدث تكرار من خلال ضبط النموذج الأولي لتحقيق متطلبات الزبون، وهذا يمكّن المطور في الوقت ذاته من إيجاد فهم أفضل للحاجات الواجب تلبيتها.
مثالياً يستخدم النموذج الأولي كآلية لتحديد متطلبات البرنامج وبناء نموذج أولي ويحاول المطور الاستفادة من أجزاء البرنامج الموجودة أو تطبيق أدوات (مثل مولدات التقارير، إدارة الأطر، ...الخ)تمكنه من توليد برامج عاملة بسرعة.
ولكن ماذا تفعل بالنموذج الأولي بعد انتهاء الأهداف المحددة سابقاً ؟ يقدم [BRO75] Brooks جوابا عن ذلك :
في معظم المشاريع، بالكاد يكون أول نظام يبنى قابلا للاستخدام فقد يكون بطيئا جدا، أو كبيرا جدا، أو صعب الاستخدام ، أو الثلاثة معا. فلا بديل عن البدء من جديد وبناء نسخة أعيد تصميمها بحيث تحل هذه المشاكل. . . ويجب عند استخدامك مفهوم نظام جديد أو تقنية جديدة أن تبني نظاما وأنت على علم بأنه سيرمى جانبا، ذلك لأنه حتى مع وجود أفضل تخطيط لن يكون ملما بكل شيء إلى درجة بناء نظام صحيح من المرة الأولى، لذلك فان السؤال الإداري هو: هل نبني نظاما رائداً ونرميه جانبا ؟ عمليا سوف نفعل ذلك. ويبقى السؤال الوحيد: هل التخطيط المسبق هو لبناء نظام ثم لرميه؟ أو للوعد بتسليم هذه النسخة (التي سترمى) إلى الزبون؟
يمكن استعمال النموذج الأولي كـ "النظام الأول" (the first system) الذي ينصح Brooks برميه، ولكن هذا الرأي قد يكون مثاليا، صحيح إن كلا من المطور والزبون يحب نموذج النمذجة الأولية، إذ يتمكن الزبون من اخذ فكرة عن النظام الفعلي، ويستطيع المطورون بعد ذلك البدء فورا بتنفيذ شيء ما، ولكن النمذجة الأولية قد تكون مليئة بالمشاكل للأسباب التالية:
1. يرى الزبون في النموذج الأولي ما يبدو انه نسخة صحيحة (عاملة) من البرنامج وهو غير مدرك إن هذا النموذج الأولي قد حوفظ عليه مترابطا ترابطا واهيا جدا، ولا يدرك إننا بسبب السرعة في انجازه لم نأخذ بالحسبان الجودة الكلية للبرنامج أو لقابلية صيانته(maintainability) على المدى الطويل. وعندما يتم إبلاغ الزبون بوجوب إعادة بناء المنتج بحيث يراعى تحقيق معايير عالية الجودة فانه يصرخ كالمجنون ويطلب إجراء "بعض الإصلاحات" لجعل النموذج الأولي منتجا يعمل جيدا، وغالبا ما تستجيب إدارة تطوير البرمجيات لهذا الطلب.
2. غالبا ما يجري المطور بعض التجاوزات في الانجاز (implementation) لجعل النموذج الأولي يعمل بسرعة. فقد يستخدم نظام تشغيل أو لغة برمجة غير مناسبين، فقط لأنهما متوافران ومعروفان، وقد يعتمد خوارزمية غير كافية، فقط لإيضاح الإمكانيات. وقد يصبح المطور بعد مدة أكثر معرفة والماماً بهذه الخيارات وينسى كل أسباب كونها غير مناسبة، ويصبح الآن الخيار الأقل مثالية جزءاً متكاملاً من النظام.
بالرغم من إمكانية حصول مشاكل إلا إن استخدام النموذج الأولي يمكن أن يكون منهجا فعالا لهندسة البرمجيات والسر هو تحديد قواعد اللعبة منذ البداية، أي ، يجب أن يتفق المطور والزبون على إن النموذج الأولي يبنى لكي يستخدم كآلية لتعريف المتطلبات، ثم بهمل (على الأقل جزئيا) وتبنى البرمجيات الفعلية مع مراعاة الجودة والصيانة.
4. نموذج التطوير السريع للبرنامج :
التطوير السريع للبرنامج (RAD) أو(Rapid Application Development) هو نموذج تتابعي خطي لعملية تطوير البرمجيات يهتم بدورة تطوير قصيرة جدا، النموذج RAD هو تكييف "سريع جدا" للنموذج ألتتابعي الخطي، حيث يجري تطوير سريع باستخدام أسلوب بناء يعتمد على المكونات إذا فهمت المتطلبات جيدا وحصرت أفق المشروع( ) ، فان عملية البرمجة RAD تسمح لفريق التطوير بإيجاد "نظام يعمل تماماً" (fully functional system) خلال مدة قصيرة جدا (من 60 إلى 120 يوما) [MAK91] يتضمن الأسلوب RAD، الذي تم استخدامه استخداما أوليا في تطبيقات أنظمة المعلومات، المراحل التالية [KER94
