كلية الهندسة


المـحـاضـرة الـخامسـة




عملية البرمجة:
يمكن وصف عملية البرمجة كما هو مبين في الشكل أدناه. حيث يوضع هيكل عام لعملية البرمجة 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]، إما تعريف Click Hereالمشكلة فيميزالمشكلة المحددة المطلوب حلها، في حين إن التطويرالتقني يحل المشكلة عن طريق تطبيق تكنولوجيا ما، ومكاملة الحل تقدمالنتائج (كوثائق، برامج، بيانات، وظائف الإعمال الجيدة، منتج جديد) لأولئك الذين طلبوا الحل أول مرة يمكن إسقاط الخطوات والمراحل العامة لهندسة البرمجيات بسهولة على هذه المراحل.
تنطبق حلقة حل المشكلة الموصوفة سابقاً على إعمال هندسة البرمجيات عند عدة مستويات مختلفة، ويمكن استخدامهاعند المستوى الماكروي (Macro Level ) عند النظر إلى كامل التطبيق أو البرنامج، وعند المستوى المتوسط عندما تتم هندسة مكونات البرنامج، أو حتى عند مستوى كتابة شيفرة البرنامج. لذا يمكن استخدام تمثيل المتجزئات (Fractals)( ) ، لتقديم رؤية مثالية لعملية البرمجة، تتضمن كل مرحلة في حلقة حل المشكلة وهكذا (يستمر هذا إلى حد معقول، في البرمجيات : سطر من الشيفرة).
يصعب واقعياً تقسيم النشاطات إلى أجزاء مستقلة تقسيماً أنيقا كما يوحي الشكل أعلاه (a ) وذلك بسبب وجود تداخل ضمن المراحلوفيما بينها، ومع ذلك تقود هذه الرؤية المبسطة إلى فكرة هامة جداً وهي انه : بغض النظر عن نموذج عملية البرمجة المختارة للمشروع البرمجي فان جميع المراحل( الوضع الراهن، تعريف المشكلة، التطوير التقني، مكاملة الحل) تتواجدمعاً بمستوى معين من التفصيل، وبملاحظة الطبيعة التكرارية للشكل أعلاه (b) فان المراحل الأربع المناقشة سابقاً تنطبق بنفس القدر على تحليل تطبيق أو برنامج كامل أو على توليد مقاطع صغيرة من الشيفرة.
يقترح [RAC95] Raccoon نموذجاً فوضوياً (chaos model) وهو يصف تطوير البرمجيات كاستمرار من المستخدم إلى المطور إلى التكنولوجيا. ومع تقدم العمل نحو إنشاء نظام متكامل، يتم تطبيق المراحل الموصوفة سابقاً تطبيقاً متكرراً وفقاً لمتطلبات المستخدم والمواصفات التقنية للبرمجيات التي يضعها المطور.
ستناقش الفقرات القادمة نماذجاً مختلفة للعمليات برمجة في هندسة البرمجيات يمثل كل نموذج منها محاولة لإضفاء ترتيب وتنظيم على نشاط فوضوي (غير منتظم). ومن المهم أن نتذكر إننا قد شرحنا كل نموذج من النماذج بطريقة تساعد على التحكم والتنسيق في المشاريع البرمجية الحقيقية، ومع ذلك يبدي جميع النماذج بعض خصائص النموذج الفوضوي.
1. بناء ثم إصلاح Build-and-Fix :
من المؤسف أن يكون هنالك العديد من المنتجات قد طورت باستخدام ما يسمى طريقة بناء-ثم-إصلاح. حيث إن المنتج الذي بني دون محددات أو أي محاولة للتصميم. بدل ذلك، فان المطورين بكل بساطة يقومون ببناء المنتج ويعيدون العمل عليه بقدر عدد المرات الضرورية لإرضاء الزبون. وهذه الطريقة موضحةفي الشكلالتالي:












شكليوضح نموذج بناء-ثم-إصلاح

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

2. النموذج ألتتابعي الخطي :
يوضح الشكل أدناه النموذج ألتتابعي الخطي (Linear sequential) لهندسة البرمجيات يقترح هذا النموذج الذي يسمى أحياناً "دورة الحياة التقليدية"أو"النموذج ألشلالي"(waterfall model) منهجاً تتابعياً منتظماً( ) .لتطوير البرمجيات، يبدأ عند مستوى النظام ويتقدم تباعاً إلى التحليل فالتصميم فالتشفيرفالاختبار فالصيانة.







يشتمل النموذج ألتتابعي الخطي، الذي جرت نمذجته على شاكلة الدورة الهندسية المألوفة، على النشاطات التالية:
‌أ. هندسة ونمذجة النظام / المعلومات : نظراً إلى إن البرنامج هو دوماً جزء من النظام أو (إعمال) اكبر فان العمل يبدأ بوضع متطلبات لجميع مكونات النظام ، ثم تخصيص مجموعة جزئية من هذه المتطلبات للبرنامج وهذه الرؤيا للنظام أساسية عندما يجب ربط البرنامج بالمكونات الأخرى، مثل العتاد والأشخاص وقواعد البيانات . تشمل هندسة النظام وتحليله على تجميع المتطلباتعند مستوى النظام، مع قدر بسيط من التحليل والتصميم عند المستوى الأعلى . أما هندسة البرنامج فتشتمل على تجميع المتطلبات عند المستوى الاستراتيجي للأعمال وعند مستوى مجال الأعمال.
‌ب. تحليل متطلبات البرنامج : تتوقف عملية تجميع المتطلبات وتركز على البرنامج بوجه خاص، وحتى يفهم المهندس (المحلل) طبيعة البرنامج أو (البرنامج) المطلوب بناؤه، يجب عليه فهم نطاق معلومات البرنامج، إضافة إلى الوظيفة أو السلوك والأداء والواجهات المطلوبة، ويجب أن يجري توثيق متطلبات النظاموالبرنامج ومراجعتها مع الزبون.Details
‌ج. التصميم : تصميم البرمجيات هو عملية برمجة متعددة الخطوات تهتم بأربع مميزات للبرنامج :- ( بنية البيانات، بنيان البرمجية، تمثيلات الواجهة، وتفاصيل عملية البرمجة (الخوارزمية)) تقوم عملية التصميم بترجمة المتطلبات إلى تمثيل البرمجيات يمكن تقييمه من حيث الجودة قبل البدء بتوليد الشقرة وكما جرى للمتطلبات يتم توثيق التصميم بحيث يصبح هذا التوثيق جزءً من تشكيلة البرنامج .
‌د. توليد الشفرة : يجب ترجمة التصميم إلى صيغة تستطيع الآلة ( الكومبيوتر) قرأتها وتقوم بهذه المهمة مرحلة توليد الشفرة وإذا نفذ التصميم بطريقة مفصلة يمكن عندها تحقيق توليد الشفرة ميكانيكياً .
‌ه. الاختبار : يبدأ اختبار البرنامج حال توليد الشفرة وتركز عمليةالاختبار على منطقية العلاقات الداخلية للبرنامج بحيث تضمن اختبار جميع العبارات وعند مستوى العلاقات الخارجية أي تنفيذ اختبارات لكشف الأخطاء ولضمان أن الدخل المعرف سيعطي نتائج فعلية تتوافق مع النتائج المطلوبة.
‌و. الصيانة : تخضع البرمجيات بلا شك لتعديلات بعد تسليمها للزبون (الاستثناء المحتمل هو برمجيات الأجهزة،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] .



















نمذجة الأعمال (business) : ينمذج تدفق المعلومات بين وظائف الأعمال بطريقة تجيب عن الأسئلة التالية: ما المعلومات التي تقود (تسير) عملية برمجة الأعمال؟ ما المعلومات التي يجري توليدها؟ من الذي يولدها؟ أين تذهب المعلومات؟ من يعالجها؟
نمذجة البيانات : نلخص أولا تدفق المعلومات،الذي عرف انه جزء من مرحلة نمذجة الأعمال وتدفقه، في مجموعة من أهداف البيانات اللازمة لدعم الأعمال ثم نحدد المميزات (تسمى سمات، attributes) لكل هدف ويتم تعريف العلاقات بين هذه الأهداف.
نمذجة عملية البرمجة : تحول أهداف البيانات، التي تم تعريفها في مرحلة نمذجة البيانات لتحقيق تدفق المعلومات الضروري، اللازمة بدورها لتحقيق وظيفة الأعمال، ثم نعمل على توليد سمات معالجة لكل عملية من عمليات إضافة أو تعديل أو حذف أو استرجاع أهداف البيانات.
توليد التطبيق: يفترض التطوير السريع للبرنامج RAD استخدم تكنولوجيات الجيل الرابع 4GT (Fourth Generation Technology) . فبدلا من إيجاد برمجيات باستخدام لغات برمجة تقليدية من الجيل الثالث، تعمل عملية التطوير السريع للبرنامج RAD على إعادة استخدام مكونات البرنامج الموجودة(عندما يكون ممكنا)أو إنشاء مكونات قابلة لإعادة الاستخدام (عند الضرورة) وتستخدم الأدوات المؤتمتة في كل الأحوال لتسهيل بناء البرنامج.
الاختبار والتطوير( Turnover ) : لما كان التطوير السريع للبرنامج RAD يشدد على إعادة الاستخدام، سيكون قد سبق وتم اختبار العديد من مكونات البرنامج، وهذا ما يقلل من زمن الاختبار الكلي ومع ذلك يجب اختبار المكونات الجديدة وتجربة كل الواجهات تجريبا كاملا.
إن نموذج عملية البرمجة RADالموضح في الشكل السابق يوضح إن التقييد الزمني المفروض على مشروع RAD يتطلب أفقا قابلا للتحجيم [KER94] (scalable scope) .فإذا أمكن تقسيم تطبيق الأعمال بحيث نستطيع انجاز كل وظيفة رئيسة في اقل من ثلاثة أشهر (باستخدام المنهج الموصوف سابقا) يكون هذا التطبيق مرشحا جيدا لـ RAD ، يمكن تناول كل وظيفة رئيسة بواسطة فريق RAD مستقل، ثم تتكامل لتشكل كيانا واحداً.
الأسلوب RAD ككل نماذج عملية البرمجة له بعض المساوئ [BUT94]:
• يتطلب RAD في حالة المشاريع الكبيرة القابلة للتحجيم موارد بشرية كافية لإنشاء العدد المطلوب من الفرق RAD ,
• يتطلب RAD مطورين وزبائن ملتزمين بالنشاطات السريعة والمتلاحقة الضرورية لإتمام النظام في زمن مختصر جدا، فإذا فقد الالتزام من احد الطرفين، ستخفق مشاريع RAD.
ليست كل أنماط التطبيقات مناسبة لاستعمال RAD فان لم يكن ممكنا تقسيم النظام بشكل مناسب ستبرز مشاكل عند بناء المكونات الضرورية لـ RAD ، وكذلك إذا كان الأداء العالي هو احد المتطلبات وكان علينا تحقيقه بتوليف الواجهات مع مكونات النظام، فقد لا يعمل الأسلوب RAD من جهة أخرى، RADغير مناسب أيضا عندما تكون المخاطر التقنية عالية، ويحدث هذا عندما يستخدم تطبيق جديد تكنولوجيا جديدة استخداما كثيفا أو عندما تتطلب البرمجيات الجديدة درجة عالية من التشغيلية البينية ( interoperability أو قابلية العمل المتبادل) لبرامج الكمبيوتر.
يركز نموذج التطوير السريع للبرنامج RAD على إيجاد مكونات برامج قابلة لإعادة استخدام فإعادة الاستخدام هي حجر الزاوية للتكنولوجيات الغرضية وسنصادفمبدأ إعادة الاستخدام أيضا في نموذج عملية تجميع المكونات.
هناك اعتراف متزايد إن البرمجيات، مثلجميع الأنظمة المعقدة، تتطورعلى مر الزمن [GII88] إذ تتغير غالبا متطلبات الأعمال والمنتج مع تقدم عملية تطوير هذا المنتج، وهذا ما يجعل المسار المستقيم باتجاهإنتاجه غير واقع، يضاف إلى ذلك إن المواعيد المقيدة لطرح المنتج في السوق تجعلإكمال منتج برمجي شامل

Leave a Reply

Your email address will not be published. Required fields are marked *