أساليب ومناهج تطوير أنظمة المعلومات

أساليب ومناهج تطوير أنظمة المعلومات
تصميم وتحليل النظم أساليب ومناهج تطوير أنظمة المعلومات د/ مازن عمر خيرو

أساليب تطوير النظم ومناهجه
يمكن تطوير أنظمة المعلومات باستخدام أساليب تطوير مختلفة وفقاً لطبيعة وحجم النظام ومتطلبات استخدامه، أما منهجيات التطوير فيقصد بها مجموعة الأدوات المستخدمة لنمذجة النظام والطرق المتبعة لتحديد متطلبات المستخدم (احتياجات المستخدم )،تحويلها إلى نظام معلومات حاسوبي. وهكذا فإن تطوير أنظمة المعلومات الحاسوبية يمكن أن يتم وفق أسس متعددة، وباستخدام منهجيات تطوير مختلفة، وعلى فريق تطوير النظام أن يحدد في البداية أسلوب التطوير الذي سيعتمده والمنهجية التي سيستخدمها في ذلك.

أساليب تطوير النظم SDLC Prototyping Rapid Application Development RAD
Extreme Programming XP Staged Development Team Centered Development Synthesis Ready Made Software Packages

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

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

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

تحديد متطلبات المعلومات
دورة حياة تطوير النظم SDLC تحديد متطلبات المعلومات وهناك عدة طرق لتعريف متطلبات معلومات العمل منها: طريق مباشرة كالمقابلات الشخصية والإستبانات وأخذ عينات من البيانات الورقية ودراستها، ومنها طرق غير مباشرة مثل مراقبة سلوك صناع القرار وبيئات المكاتب، وهناك طرق تجمع الصفتين مثل النمذجة الأولية. في هذه المرحلة يبذل المحللون أقصى جهدهم لتحديد احتياجات المستخدمين اللازمة لإنجاز مهامهم. هناك عدة طرق لتحديد متطلبات المعلومات وجميعها يتطلب التفاعل المباشر مع المستخدمين، إن هذه المرحلة تساهم في إكمال الصورة التي رسمها المحلل عن المنظمة وأهدافها. في بعض الأحيان يتم إنجاز المرحلتين الأولى والثانية فقط من دورة حياة تطوير النظم بقصد هدف آخر وغالباً ما يقوم بها محلل المعلومات Information Analyst (IA). أما الأشخاص المشاركون في هذه المرحلة هم: المحللون والمستخدمون ومدراء العمليات والعاملون في العمليات. يجب أن يعرف محلل النظم وظائف النظام الحالي بالتفصيل: الأشخاص المشاركين فيه، أنشطة العمل، مكان العمل، زمن إنجاز العمل، كيفية إنجاز إجراءات العمل الحالية، يجب أن يسأل المحلل عن سبب تسيير العمل بالطرق الحالية وأن يأخذ هذا السبب بعين الاعتبار عند تصميم أي نظام جديد. إذا كان الجواب عن استخدام العمليات الحالية هو: أنه يؤدّى دائماً على هذا النحو وبهذه الطريقة، عندها يجب على المحلل تطوير تلك الإجراءات، وقد يساعد مفهوم إعادة هندسة عمليات الأعمال Business Process Reengineering على وضع طريقة لإعادة التفكير في العمل بطريقة إبداعية. عند إتمام هذه المرحلة يجب أن يكون المحلل قد استوعب سير العمل وامتلك معلومات عن كل من له علاقة بالعمل من أشخاص وأهداف وبيانات وإجراءات.

تحليل احتياجات النظام هناك أدوات وتقنيات خاصة تساعد المحلل على تحديد المتطلبات مثل: مخططات تدفق البيانات Data Flow Diagrams لتمثيل البيانات الداخلة إلى العمل وآلية معالجة هذه البيانات والمعلومات الناتجة بشكل رسومي هيكلي، ثم يستفاد من مخططات تدفق البيانات في إنشاء قاموس البيانات الذي يحتوي على جميع عناصر البيانات المستخدمة في النظام مع وصف تفصيلي لكل عنصر منها. أثناء هذه المرحلة يقوم المحلل بتحليل القرارات الهيكلية وهي القرارات التي يمكن فيها تحديد الشروط وبدائلها والأفعال وقواعدها، وهناك ثلاث طرق رئيسية لتحليل القرارات الهيكلية: اللغة الإنجليزية الهيكلية وجداول القرار وأشجار القرار. في هذه النقطة من دورة حياة تطوير النظم يقوم المحلل بإعداد عرض يلخص ما قام بجمعه ويقدم بعض الاقتراحات والنصائح إلى الإدارة بخصوص ما ينصح به فإذا وافقت الإدارة على هذه المقترحات يتابع المحلل عمله في إنشاء النظام. كل مشكلة من مشاكل النظام فريدة ويمكن أن تحل بعدة طرق وتعتمد الطريقة التي يشكل بها الاقتراح على مقومات شخصية محلل النظم وعلى مدى احترافه.

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

تطوير وتوثيق البرمجيات
دورة حياة تطوير النظم SDLC تطوير وتوثيق البرمجيات يعمل المحلل والمبرمجون على تطوير البرامج الجديدة، وهناك تقنيات هيكلية لتصميم وتوثيق البرامج منها: مخططات البنية Structure Chart ومخططات ناسي- شنايدرمان، والشيفرة الوهمية Pseudocode، حيث يمكن للمحلل أن يستخدم واحدة أو أكثر من هذه الأدوات ويعطيه للمبرمج ليعرف ما الذي سيقوم ببرمجته. يتعاون المحلل والمستخدمون على وضع وثائق البرامج وهي: دليل الاستخدام والمساعدة الفورية ومواقع الويب التي تقدم الأسئلة الأكثر طرحاً FAQS وذلك ضمن ملفات Read Me التي سترفق مع البرامج الجديدة، فائدة الوثائق هي أنها ترشد المستخدمين إلى كيفية استخدام البرامج وإلى كيفية حل مشاكل البرامج في حال ظهورها. يلعب المبرمجون دوراً هاماً في هذه المرحلة لأنهم يقومون بتصميم البرنامج ووضع شيفرته وإزالة الأخطاء القواعدية منه. إذا كانت ستشغل البرامج في بيئة حاسوب مركزي Mainframe يجب إنشاء لغة التحكم بالأعمال Job Control Language (JCL)، ويمكن للمبرمج أن يأخذ التصميم أو الشيفرة التي كتبها ويشرح الأجزاء المعقدة من البرنامج لفريق من المبرمجين الآخرين لرفع مستوى الجودة.

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

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

أسلوب دورة حياة النظم SDLC
وبالرغم من أهمية أسلوب دورة تطوير حياة النظام وما يوفره من خطوات متسلسلة ومحددة يتم اتباعها لضمان تطوير أنظمة معلومات تلبي الاحتياجات المطلوبة للمستخدمين، إلا أنه يعتبر غير مناسباً لتطوير أنظمة المعلومات الكبيرة جداً، وكذلك تلك الأنظمة التي تتصف بعدم الوضوح Imprecise System كأنظمة دعم القرارات والأنظمة الجديدة عموماً، نظراً لعدم توفر الخبرة الكافية بها لحدثاتها أو لكونها لم تستخدم بعد في بيئة العمل. وهكذا فإن أسلوب دورة حياة تطوير الأنظمة يعتبر مثالياً وجيداً لتطوير الأنظمة التي يمكن تحديدها بدقة Precisely Defined (أي تحديد مخرجاتها وعملياتها ومدخلاتها بالدقة الكافية) إما في الحالات التي لا يمكن الوصول فيها إلى مثل هذا التحديد الدقيق ( نظراً لضخامة حجمها أو لعدم توفر المعلومات الكافية بمكوناتها ) فإنه لابد من اللجوء إلى استخدام أساليب تطوير أخرى كالتطوير التدريجي Staged Approach أو استخدام النماذج التشبيهية Prototypes أو غيرها.

مشاريع البرمجة الحدّية
Extreme Programming XP مشاريع البرمجة الحدّية البرمجة الحدّية XP هي إحدى الطرق المستخدمة في تطوير النظم تقوم على مبدأ تبني ممارسات التطوير الجيدة، ثم القيام بدفعها إلى أقصى مدى ممكن. هناك أربعة متحولات يمكن لمحلل النظم أن يتحكم بها و هي: الزمن والكلفة والجودة والمجال. و هناك أربعة أنشطة في البرمجة الحدّية: كتابة الشيفرة، الاختيار، الاستماع، و التصميم.

Extreme Programming XP
الأنشطة المتحولات الزمن الكلفة المجال الجودة الشيفرة الاستماع التصميم الاختيار

المتحولات الأربعة الأساسية في طريقة البرمجة الحدية
Extreme Programming XP المتحولات الأربعة الأساسية في طريقة البرمجة الحدية تفترض فلسفة البرمجة الحدّية أنه إذا قام المحلل بتحديد كمية المجال و الجودة و الفترة الزمنية اللازمة لإتمام المشروع فإنه يستطيع بحساب تلك المتحولات الثلاثة أن يضبط المتحول الرابع و هو الكلفة و بأحسن قيمة ممكنة له، و هذا هو معنى Extreme أي أن المتحول يبلغ أقصى غاية ممكنة. المتحول الرابع المتحولات الثلاثة الزمن المجال الجودة الكلفة المتحول الرابع المتحولات الثلاثة الزمن المجال الكلفة الجودة

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

البرمجة الحدّية و طريقتها في زيادة و إنقاص المورد
Extreme Programming XP البرمجة الحدّية و طريقتها في زيادة و إنقاص المورد لا شك أن إنهاء المشروع في الزمن المحدد و ضمن كل القيود هو أمر عظيم، ولكن كي يتم ذلك لا بد من الاعتناء بمسألة إدارة المشروع لأهميتها البالغة، فإدارة المشروع لا تعني مجرد تحديد الأنشطة وفق الموارد فقط، بل يعني أيضاً أن المحلل يجب أن يقوم ببعض المقايضات، فأحياناً يتم تحديد الكلفة في البداية، و في ظروف أخرى يكون الزمن أهم العوامل، و فيما يلي سنناقش المتحولات الأربعة للتحكم بالموارد و هي الزمن و الكلفة و الجودة و المجال.

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

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

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

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

الأنشطة الأربعة الأساسية في طريقة البرمجة الحدية
Extreme Programming XP الأنشطة الأربعة الأساسية في طريقة البرمجة الحدية هناك أربعة أنشطة تطويرية في البرمجة الحدية هي : كتابة الشيفرة البرمجية والاختبار والاستماع والتصميم، ويجب على المحلل الذي يتبع طريقة البرمجة الحدية أن يعرف مقدار الجهد اللازم في كل نشاط ثم موازنة ذلك مع الموارد المتوفرة لإنجاز المشروع، على شكل ميزان قد وضع في كتفيه عدد من الأوزان، تمثل الأوزان الموضوعة في الكفة اليمنى في طريقة البرمجة الحدية الأنشطة في حين تمثل الأوزان الموضوعة في الكفة اليسرى الموارد التي تحدثنا عنها سابقاً.

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

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

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

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

الممارسات الجوهرية الأربع في البرمجة الحدّية
Extreme Programming XP الممارسات الجوهرية الأربع في البرمجة الحدّية إن موازنة الموارد لإتمام مشروع ما في الوقت المطلوب هي إحدى طرق المشاريع إلا أن الطريقة الأفضل هي : تطوير ممارسات تعطى نتائج مدهشة، فقد طوّرت حركة البرمجة الحدّية مجموعة من الممارسات الجوهرية التي غيرت طريقة تطوير النظم، و سنذكر فيما يلي أربع ممارسات حدّية و هي حدية مقارنةً بما ناقشناه حتى الآن في إدارة المشاريع. XP short release working 40 hours per week Onsite Customer Pair Programming

الإصدار المؤقت short release
Extreme Programming XP الإصدار المؤقت short release حتى تنجح طريقة تطوير البرمجة الحدّية يجب إصدار المنتج في الوقت المحدد في الجدول الزمني حتى لو لم يستطيع المبرمجون وضع كافة المزايا في البرنامج. ربما تكون هذه مبالغة لكن الزبائن سيكونون عندها سعداء لحصولهم على المنتج، أما التحسينات فيمكن القيام بها لاحقاً، و هذه الممارسة شائعة الاستخدام في مجال تطوير برمجيات الحاسوب و أكثر شيوعاً في عالم الأجهزة الكفية، ففي الولايات المتحدة يتم إصدار برامج الضرائب في بداية موسم الضرائب قبل الانتهاء من وضع قوانين الضرائب في البلاد، لأن مطوري برامج الضرائب يعرفون جيداً أن الزبون يريد المنتج في أقرب وقت ممكن.

زمن أسبوع العمل 40 ساعة working 40 hours per week
Extreme Programming XP زمن أسبوع العمل 40 ساعة working 40 hours per week لقد شجع هذا النموذج المبرمجين على قضاء حياتهم في المكتب و هم يعملون على مدار الساعة، و الأمر ليس كذلك في البرمجة الحدّية. حيث يقوم فريق تطوير البرمجة الحدّية هنا بتوقيع اتفاقية على ممارسة ثقافية جوهرية و هي أن يعملوا معاً بجد طيلة أسبوع عمل تقليدي مدته 40 ساعة. تهدف هذه الممارسة الجوهرية إلى تحفيز أعضاء الفريق على العمل بجد أثناء الدوام ثم أخذ استراحة كافية بحيث يكونون في حالة استرخاء عند العودة إلى العمل و غير متوترين و قادرين على اكتشاف المشاكل، و يقل احتمال ارتكابهم للأخطاء المكلفة و احتمال الوقوع في النسيان نتيجة الأداء المتعب و استهلاك طاقة المبرمج و هذا ما يحدث عندما لا تكون هناك فترة راحة.

إحضار الزبون إلى موقع العمل Onsite Customer
Extreme Programming XP إحضار الزبون إلى موقع العمل Onsite Customer معظم مطوري النظم يوافقون على ضرورة وجود الزبون و أهميته في نجاح النظام لكنهم يكتفون بعد ذلك بإجراء لقاء أو لقائين مع الزبون ليحددوا متطلبات النظام. إن وجود الزبون في موقع العمل يبلغ أقصى قوته عند وجود الزبون الخبير في شؤون العمل في مكان العمل أثناء فترة التطوير، و هو الشخص الفعال في تحديد آلية معالجة البيانات، و كتابة قصص المستخدمين و التواصل مع أعضاء الفريق و المساعدة في تحديد الأولويات.

البرمجة الزوجية Pair Programming
Extreme Programming XP البرمجة الزوجية Pair Programming إن البرمجة الزوجية هي في غاية القوة. فطالما أن هناك فريق من محللي النظم لماذا لا يكون هناك فريق من المبرمجين ؟ لا نعني بالبرمجة الزوجية أن يقوم المبرمج الأول باختلاس النظر إلى شيفرة المبرمج الثاني لاكتشاف الأخطاء التي ارتكبها، بل المقصود : أن يقوم المبرمجان بالعمل معاً لكتابة الشيفرة البرمجية و إجراء الاختبارات و مناقشة أفضل الطرق و أكثرها فاعلية في إنجاز العمل. إن البرمجة الزوجية توفر الوقت و تقلل من التفكير اللامبالي و تشغل حس الإبداع و تضفي على البرمجة جواً من المرح.

عملية التطوير لمشروع البرمجة الحدّية
Extreme Programming XP عملية التطوير لمشروع البرمجة الحدّية هناك عدد من الأنشطة و السلوكيات تشكل طريقة أعضاء فريق التطوير و الزبائن أثناء تطوير مشروع البرمجة الحدّية، هناك كلمتان تصفان المشروع المنجز بهذه الطريقة هما : التفاعل و التدرج.

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

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

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

ويختلف أسلوب النماذج التجريبية Prototype عن أسلوب التطوير الارتقائي بأن النموذج الأولي Pilot System الذي يتم إعداده خلال عملية التطوير يتحول إلى النهاية ليصبح جزءاً من النظام النهائي الذي يجري بناءه. أما في أسلوب النماذج التجريبية فإن هذا النموذج يتم استبداله في النهاية بالنظام الأصلي، أي يستخدم فقط كأداة للتحليل وتحديد الاحتياجات. أما أهم مجالات استخدام النماذج التجريبية فهي: اختبار الحلول التصميمية الجديدة بشكل عملي. تحليل المتطلبات Requirement Analysis باعتبارها أداة هامة تساعد في ذلك توضيح متطلبات المستخدم. عرض الإمكانات والخيارات التي يمكن أن يوفرها النظام المقترح.

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

أنواع النماذج الأولية النموذج الأولي المجمع النموذج غير القابل للتشغيل
نموذج الأول في السلسلة النموذج الاولي ذو المزايا المنتقاة

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

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

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

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

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

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

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

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

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

التطوير السريع للتطبيقاتRapid Application Development RAD
هي طريقة كائنيه التوجه في تطوير النظم تتألف من: طريقة التطوير. أدوات برمجة. تهدف إلى اختصار الزمن الطويل الذي يفصل بين تصميم النظام وتنفيذه في دورة حياة تطوير النظم، وبالتالي إلى تلبية متطلبات العمل المتغيرة بسرعة في وقت قصير. ينظر بعض المطورين إلى التطوير السريع للتطبيقات على أنه طريقة مساعدة في بيئات التجارة الإلكترونية الجديدة المعتمدة على الويب حيث يكتسب ظهور العمل على الويب قبل الأعمال المنافسة له أهمية خاصة، فإذا أراد المحلل وضع تطبيق ما على الويب بسرعة قبل أن تفعل الأعمال المنافسة له فالأفضل أن يتبنى هو وفريقه طريقة التطور السريع للتطبيقات.

مراحل التطوير السريع للتطبيقات RAD

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

المرحلة الثانية: ورشة التصميم
وتسمى أيضاً مرحلة: صمم و حسّن design-and-refine وأدق ما يعبر عنها هو كلمة ورشة workshop، فعندما نتخيل ورشة العمل تقفز إلى أذهاننا صورة المشاركة القوية للأفراد وعدم السلبية. يجب على المستخدمين أثناء هذه المرحلة إبداء ردود أفعالهم واستجاباتهم للنماذج الأولية القابلة للتشغيل، وعلى المحللين أن يقوموا بتحسين الوحدات البرمجية التي تم تصميمها اعتماداً على ردود أفعال المستخدمين.

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

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

التطوير المعتمد على فريق عمل Team Centered Development
يقوم هذا الأسلوب على فلسفة مناقضة تماماً لمفهوم دورة حياة تطوير الأنظمة، حيث يترك الحرية الكاملة لفريق التطوير، لتطوير نظام المعلومات، دون اية قيود تتعلق بتسلسل عمليات التطوير. فبدلاً من التركيز على تنفيذ عمليات وأنشطة التطوير بشكل رسمي ومتسلسل كما هو الحال في دورة حياة تطوير النظام، يُسمح للفريق بالعمل في هذه الأنشطة بالأسلوب الذي يراه مناسباً وأكثر فعالية لإنجاز النظام المطلوب. وتستند فلسفة هذا الأسلوب لتطوير أنظمة المعلومات التي تكون في البداية غير واضحة التحديد Imprecise Systems، ووفقاً لذلك يتم تطوير النظام بطريقة تجريبية وبشكل ارتقائي. ففي البداية يتم تطوير نظام أولي بسيط Pilot System يوضع قيد الاستخدام والاختبار ثم تجري ترقيته Upgrading بشكل متدرج على خطوات حيث يتم في كل خطوة تالية إضافة إمكانات وقدرات جديدة إلى هذا النظام الموجود قيد الاختبار. وهكذا فإنه نتيجة لاستخدام هذا النظام واختباره في كل مرة يتم اكتساب المعرفة والخبرة لتحديد متطلبات التطوير للخطوة التالية.

أسلوب التركيب Synthesis
وفقاً لهذا الأسلوب، يتم تطوير أنظمة المعلومات من وحدات وظيفية Modules موجودة، وهذا يتطلب أن يتوفر لدى المنظمة مكتبة برمجيات Software Library تضم العديد من الوحدات الوظيفية Modules والتي يمكن إعادة استخدامها مرات عديدة Reusable عند بناء أنظمة ا لمعلومات الجديدة. ولكي تتوفر مثل هذه المكتبة يجب أن تعتمد المنظمة الأسلوب الهيكلي لتصميم النظم Structural Design، الذي يقوم على تقسيم النظام إلى مجموعة من الوحدات الوظيفية Program Modules التي تقوم كل منها بوظيفة محددة تماماً. وأهم ميزات هذا الأسلوب هو إعادة استخدام هذه الوحدات الوظيفية عند تصميم الأنظمة الجديدة.

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

اختيار الأسلوب الأمثل لتطوير النظام
درجة وضوح وتحديد بنية النظام: فالنظام ذات البنية الواضحة Well Defined يمكن تطويرها باستخدام أسلوب دورة حياة تطوير النظام المشار إليها أعلاه، أما بالنسبة للأنظمة التي تكون بينتها غير واضحة فيمكن تطويرها باستخدام الأسلوب التدريجي أو النماذج التجريبية. توفر الخبرة والمعرفة بتقنية الأنظمة: أي عندما يكون المستخدمين على معرفة و إطلاع بتقنية المعلومات، يمكن تطوير النظام باستخدام أسلوب دورة حياة النظام، أما عندما يكون المستخدمين غير عارفين بهذه التقنية ويستخدمونها للمرة الأولى فإنه يفضل تطوير النظام باستخدام الأسلوب التجريبي. حجم النظام الذي يجري تطويره، عندما يكون النظام كبير جداً يفضل تجزئته إلى نظم فرعية محددة بشكل واضح ثم اتباع الأسلوب المرحلي Staged لتطويره، أي التطوير على مراحل.

مناهج تطوير النظم يقصد بمنهجية التطوير مجموعة الطرق والأدوات المستخدمة في تطوير النظام بدءاً من تجميع المعلومات و تحديد احتياجات المستخدم، مروراً بعمليات النمذجة ووصولاً إلى بناء النظام الحاسوبي الجديد بالطريقة التي تلبي الاحتياجات بالكفاءة والفاعلية المطلوبة. وهكذا فإن المنهجية تحدد الخطوات التي سيتم من خلالها تطوير النظام والأدوات Tools اللازمة لكل خطوة ونظراً للتنوع الشديد في أساليب تطوير النظم ووجود العديد من الأدوات التي يمكن استخدامها في كل خطوة أو مرحلة من عملية التطوير، فإنه نظرياً يمكن اشتقاق العديد من المنهجيات الممكنة لتطوير النظم ولكن من الناحية العملية يفضل أن تستخدم المنظمات منهجية واحدة عامة لتطوير أنظمتها Standard Methodology نظراً للمزايا التالية: تنميط وتوحيد عمليات وأنشطة التطوير لكي تتم بأسلوب موحد ومنسق مما يسهل عمليات التوثيق والمتابعة. تركيز جهود المحللين والمصممين على دراسة النظم التي يقومون بتطويرها، وإعفائهم من المهام المتعلقة باختيار الأدوات والأساليب المختلفة للنمذجة والتوثيق لكل مشروع على حدة. اعتماد منهجية موحدة يساعد المحللين والمصممين ومساعديهم وبقية أعضاء فريق التطوير في إتقان استخدام أدوات وأساليب هذه المنهجية كما يجعل المستخدمين أكثر فهماً لها مما يوفر الكثير من الوقت والجهد اللازم للتفاعل مع هؤلاء الأفراد في حالة استخدام منهجيات تطوير مختلفة لكل مشروع.

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

أساليب ومناهج تطوير أنظمة المعلومات

Similar presentations

Presentation on theme: "أساليب ومناهج تطوير أنظمة المعلومات"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

أساليب ومناهج تطوير أنظمة المعلومات

Similar presentations

Presentation on theme: "أساليب ومناهج تطوير أنظمة المعلومات"— Presentation transcript:

Similar presentations

About project

Feedback