خطوات مرحلة التخطيط STEPS OF THE PLANNING PHASE

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

1) تمييز المشكلة Recognizing the Problem .
عادة ما يميز المديرون , وغير المديرين , والعناصر البيئية للمنشأة الحاجة لنظام معلومات معتمد على الحاسب . ونادرا فقطً ما يوفر المتخصصون في المعلومات العاملون في وحدة خدمات البداية , نظراً لأنهم ليسوا في الساحة دائماً لملاحظة أعراض المشاكل .

2) تعريف المشكلة Define Problem .
بمجرد أن يتحقق المدير من وجود مشكلة , فإنه يجب أن يفهمها بصورة جيدة تكفي للبحث عن الحل , إلا أن المدير لا يحاول جمع كل المعلومات عند هذه النقطة . وبدلاً من ذلك , يبحث المدير عن تحديد أين توجد المشكلة وما سببها فقط .
فإذا كان للمنشأة سياسات تشجع حوسبة المستخدم النهائي ويريد المدير إتباع هذا المنهج في تطوير النظام , فعليه تقع مسؤولية التعريف . وإلا فعلى المدير أن يحصل على مساعدة محلل النظم . وسوف نفترض أن المدير و المحلل يعملان معاً .
3) تحديد أهداف النظام Set System Objectives .
يطور المدير و محلل النظم قائمة بالأهداف التي يجب أن يحققها النظام لإشباع حاجات المستخدمين . وعند هذه النقطة , تحدد الأهداف بمصطلحات عامة فقط . و فيما بعد سيقومان بجعلها أكثر تحديداً .
4) تعريف قيود النظام Identify System Constraints .
لن يعمل النظام الجديد دون قيود . وتفرض البيئة بعض القيود , مثل طلب الحكومة تقارير الضرائب و حاجة العملاء إلى معلومات عن الفواتير . كما تفرض إدارة المنشأة قيوداً أخرى , مثل استخدام نظم المكونات الموجودة أو تحديد تاريخ محدد ليعمل فيه النظام .

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

5) إجراء دراسة الجدوى Coduct a Feasibility Study .
دراسة الجدوى Feasibility Study عبارة عن نظرة تلخيصية للعوامل الرئيسية التي تؤثر على مقدرة النظام على تحقيق الأهداف المرجوة منه . وتوجد ستة أبعاد للجدوى .
· بعد تقني هل هناك نظم مكونات و نظم برامج متاحة لأداء التشغيل اللازم ؟
· بعد اقتصادي هل يمكن تبرير النظام المقترح مالياً عن طريق مقارنة منافعه مع تكاليفه؟
· بعد العائد غير الاقتصادي هل يمكن تبرير النظام المقترح اعتماداً على منافع لا يمكن قياسها مالياً؟
· بعد قانوني و أخلاقي هل سيعمل النظام المقترح في حدود القانونية و الأخلاقية ؟
· بعد تشغيلي هل سيكون تصميم النظام بحيث إنه سيتلقى الدعم من الناس الذين يجب أن يجعلوه يعمل ؟
ويجمع محلل النظم المعلومات اللازمة للإجابة على هذه الأسئلة بصورة أولية عن طريق عقد مقابلات مع العاملين الرئيسيين في مجال المستخدم .

6) إعداد اقتراح دراسة النظام Prepare a System Study Proposal .
إذا بدا النظام والمشروع ممكنين , سوف تصبح هناك حاجة إلى دراسة كاملة للنظام . وسوف توفر دراسة النظام System Study الأساس التفصيلي لتصميم النظام الجديد بالنسبة إلى ما يجب أن يؤديه وكيف يجب تأديته . ويعد المحلل اقتراح دراسة النظام System Study Proposal والذي يوفر أساساً للمدير ليحدد إذا كان سيستمر في التحليل أم لا .
ترتبط أول خمسة أقسام بالنظام المراد تحقيقه . ويرتبط القسم السابع بمشروع الدراسة الذي يقود إلى النظام , ويحدد المهام المشمولة في أداء مراحل التحليل , والتصميم , والتنفيذ .
والنقطة الهامة المراد فهمها عن الاقتراح هي اعتماد الكثير من المحتويات على التقديرات وسوف يتم تعلم المزيد مع الانتهاء من دورة الحياة . إلا أنه عند هذه النقطة تكون التقديرات أفضل معلومات متاحة , وتكون أفضل كثيراً من عدم وجود معلومات على الإطلاق ! ويقدم محلل النظم نسخاً تحريرية من الاقتراح للمدير و لجنة قيادة نظام المعلومات الإداري ,
وفي بعض الحالات يقدم عرضاً شفوياً .
7 ) الموافقة , أو عدم الموافقة , على مشروع الدراسة
Project Approve or Disapprove the Study
يزن المدير ولجنة القيادة مميزات وعيوب المشروع , وتصميم النظام المقترحين , ويحددوا ما إذا كانوا سيستمرون أم لا – قرار الاستمرار / عدم الاستمرار go /no go decision .

وعند اتخاذ اللجنة قرارها , يطرح سؤالان :
1- هل سيحقق النظام المقترح أهدافه ؟
2- هل مشروع الدراسة المقترح هو أفضل طريقة لإجراء تحليل النظم ؟
فإذا كان القرار الاستمرار , يستمر المشروع بمرحلة الدراسة . وإذا كان القرار عكس ذلك , يوجه كل الأطراف انتباههم لأمور أخرى .
تشييد آلة المراقبة Establish a Control Mechanism .
قبل أن تبدأ دراسة النظام , تعد لجنة قيادة نظام المعلومات الإداري مراقبة للمشروع عن طريق تحديد ما الذي سيتم عمله , ومن الذي سيؤديه , وفي أي وقت سيؤدى .ويوفر جدول (7-1) مثالاً لكيفية الإجابة على مثل هذه الأسئلة . وتسرد قيمة الوقت اللازم لكل مهمة بعدد الأشهر فرد . ويكون الشهر- فرد person-month الوقت الذي يحتاجه فرداً واحداً يعمل لمدة شهر كامل لإنجاز المهمة .وبتحديد العديد من الأفراد لنفس المهمة . من الممكن أن يقل عدد الأشهر الذي تستغرقه المهمة لإتمامها . وليس من الضروري أن يحدث هذا بصورة خطية .

توجيه التقدم في المشروع بمجرد إعداد جدولة المشروع , يجب توثيقها في صورة تسهل من عملية المراقبة . ويمكن استخدام أساليب التوثيق المختلفة .بما في ذلك الأنواع المختلفة من الخرائط , والرسومات, والأشكال .ويوجد عدد كبير من نظم برامج إدارة المشروع متاح لإنتاج التوثيق اللازم . وأحد الأمثلة الشعبية هو ميكروسوفت بروجكت Microsoft Project .
مرحلة التحليل
THE ANALYSIS PHASE

.مع إتمام التخطيط ووضع آلية المراقبة , يتحول فريق المشروع إلى تحليل النظام الموجود . ويمثل تحليل النظم system analysis دراسة النظام الموجود بغرض تصميم نظام جديد أو نظام معدل.

وخلال مرحلة التحليل , يستمر محلل النظم في العمل مع المدير , مع شمول لجنة قيادة نظام المعلومات الإدارية عند النقاط الحاسمة , كما هو مبين في الشكل (7-4).
1- الإعلان عن دراسة النظام Announce the System Study .
عندما تنفذ المنشأة تطبيق حاسب جديد , تتخذ الإدارة خطوات لضمان تعاون الحاسب بها . وينصب الاهتمام الأولي على مخاوف العاملين من كيفية تأثير الحاسب على أعمالهم . وأفضل طريقة لتبديد هذه المخاوف هي الاتصالات مع العاملين بغرض توصيل :
ü أسباب المنشأة الخاصة بهذا المشروع .
ü كيف سيفد النظام الجديد كلا ً من المنشأة والعاملين .

ويمكن أن تلتقي الإدارة مع العاملين في جلسات جماعية أو فردية ويمكنها أن تستخدم وسط تحريري مثل المذكرات والخطابات الإخبارية للشركة للإعلان عن الدراسة . وبالنسبة للمنشآت التي لها عمليات واسعة الانتشار , يمكن أن يأخذ الإعلان شكل شريط فيديو أيضاً .
2- تنظيم فريق المشروع Organize the Project Team .
يتم تجميع فريق المشروع الذي سيؤدي دراسة النظام . ولدى العديد المنشآت سياسة بأن المستخدم , بدلاً من المتخصص في المعلومات , يجب أن يعمل كقائد للمشروع . ومن الحاسم لنجاح المشروع أن يلعب المستخدمون أدواراً نشطة . بدلاً من لعبهم أدواراً سلبية .

- تعريف الاحتياجات من المعلومات Define Information Needs .
يتعلم المحللون ما هي احتياجات المستخدمين من المعلومات عن طريق الدخول في أنشطة جمع معلومات مختلفة , بما في ذلك المقابلات الشخصية , والملاحظات , والبحث المسجل , والاستبيانات . ويكون اللقاء الفردي المفضل من كل هذا الطرق للأسباب التالية :
· أنه يوفر الفرصة لاتصالات في اتجاهين وملاحظة لغة الجسم .
· أنه يمكن أن يحفز الحماس للمشروع على كل من جانبي المتخصص في المعلومات والمستخدم .
· أنه يمكن أن يشيد ثقة مشتركة بين المستخدمين والمتخصصين في المعلومات .
· أنه يوفر الفرصة في المشاركة للتعبير بوجهات نظر مختلفة في المشروع .
وتكون هذه هي النقطة في دورة حياة المشروع التي يجمع فيها المحلل التوثيق للنظام الموجود . ويراجع المحلل التوثيق الذي يمكن أن يكون قد أعد عندما طور النظام الحالي أول مرة ويضيف توثيقاً جديداً كلما دعت الحاجة إلى ذلك . وشمل التوثيق خرائط مسار , وخرائط مسار بيانات , ورسومات أخرى وأوصاف تحريرية للعمليات والبيانات . وعادة يستخدم مصطلح قاموس البيانات data dictionary في وصف كل التوثيق الذي يصف النظام . ويكون الاتجاه لصيانة قاموس المشروع في صورة الكترونية بدلاً من الصورة الورقية .
4- تعريف معايير أداء النظامPerformance Criteria System Define.
مع تعريف احتياجات المدير من المعلومات , يصبح من الممكن الآن تحديد مصطلحات دقيقة لما يجب أن يحققه النظام – معايير أدائه performance criteria مثال ذلك , يمكن أن يصر مدير التسويق الذي يحتاج إلى تقرير مصاريف شهرية على معايير الأداء التالية :
· يجب أن يعد التقرير في صورة معروضة .
· يجب أن يكون التقرير متاحاً في موعد أقصاه 3 أيام بعد انتهاء الشهر .
· يقارن التقرير العائد والمصاريف الفعلية و المحددة في الميزانية لكل من الشهر المنصرم وقيمها منذ بداية العام وحتى نهاية هذا الشهر .

وبالطبع , تؤخذ هذه المواصفات كمعايير أداء عندما يوافق فريق المشروع أنها يمكن تحقيقها فقط .
5- إعداد اقتراح التصميم Prepare Design Proposal .
يوفر محلل النظم الفرصة للمدير لاتخاذ قرار ثاني للاستمرار أو عدم الاستمرار . وهنا , يجب أن يوافق المدير على مراحل التصميم , مع شمول الدعم لهذا القرار في اقتراح التصميم .
6- الموافقة أو عدم الموافقة على مشروع التصميم
Approve or Disapprove the Design Project .
يقوم المدير ولجنة قيادة نظام المعلومات الإدارية اقتراح التصميم ويحددوا ما إذا كانوا سيوافقون عليه أم لا . في بعض الحالات , يمكن أن يطلب من الفريق أن يجري تحليلاً آخر ويعيد تسليم اقتراح التصميم , أو يمكن إلغاء المشروع . وعندما تتم الموافقة , ينتقل المشروع إلى مرحلة التصميم .
مرحلة التصميم
THE DESIGN PHASE
مع فهم النظام الحالي ومتطلبات النظام الجديد , يمكن لفريق المشروع أن يتناول تصميم النظام الجديد . ويمثل تصميم النظام system design تحديد العمليات والبيانات اللازمة للنظام الجديد . وعندما يكون النظام معتمداً على الحاسب , يمكن أن يشمل التصميم مواصفات أنواع المعدات التي ستستخدم فيه . وتظهر خطوات مرحلة التصميم في الشكل (7-6) .
1- إعداد التصميم التفصيلي للنظام Prepare the Detailed System Design .
يعمل المحلل مع المستخدم ويوثق تصميم النظام الجديد باستخدام أدوات مثل تلك الموصوفة في الملاحق . ويسرد جدول (7-2) الأدوات الأكثر شيوعاً .
نمذجة البيانات
رسم الكينونة – العلاقة
قاموس البيانات
شكل تخطيط للشاشة / الطابعة
نمذجة العملية
خريطة مسار النظام
خريطة مسار البرنامج
خريطة مسار البيانات
الإنجليزية المهيكلة
نمذجة الشيئ
نموذج علاقة الشيء
مواصفات الطبقة
وتمكن بعض الأدوات المحلل من إعداد التوثيق بطريقة من أعلى لأسفل , بداية بالصورة الكبيرة والدخول التدريجي في مزيد من التفاصيل . ويعد منهج من أعلى لأسفل خاصية للتصميم المهيكل structured design , والذي يستمر فيه التصميم من مستوى النظام إلى مستوى النظام الفرعي .
ويوضح الشكلين (7-7) و (7-8) عملية من أعلى لأسفل . فشكل (7-7) عبارة عن رسم سريان بيانات data flow diagram(DFD) , والذي يبين كيف تربط أربعة نظم تشغيل بيانات عن طريق سريان البيانات . ونشرح تفاصيل رسومات السريان في ملحق (ب).
ويبين شكل (7-8) كيف يوثق النظام الفرعي لإدخال الأوامر بمزيد من التفاصيل . فيحتوي نظام إدخال الأوامر على أربعة نظم فرعية , مرقمة بالأرقام من (1-1-1) وحتى (1-1-4) , والتي يمكن أن توثق على مستويات نظم فرعية أقل مستوى أيضاً .
ويمثل كل سهم من الأسهم المبينة في الشكل سريان بيانات ويمكن توثيقه بأحد محتويات قاموس البيانات . ويكون قاموس البيانات data dictionary الوصف الرسمي لمحتويات قاعدة البيانات . ويوفر قاموس البيانات لغة مشتركة لكل مطوري النظم تستخدم وصف مورد البيانات للمنشأة .
2- تعريف تشكيلات النظام البديلة Identify Alternative System Configurations .
يجب أن يعرف المحلل الآن التشكيل- configurations ليس العلامة التجارية أو الطراز لمعدات الحوسبة التي تمكن النظام من تحقيق التشغيل بصورة أفضل . ويكون التعريف عبارة عن عملية متتابعة , بداية بتعريف مجموعات الخليط المختلفة التي يمكن أن تحقق كل مهمة .

3- تقويم تشكيلات النظام البديلة Configurations System Evaluate Alternative .
ويقوم المحلل , بعمله بنجاح إلى جانب المدير , البديل الذي يقع عليه الاختيار بأنه لأفضل النظام الفرعي من تحقيق معايير الأداء , بمعرفة القيود على النظام .
4- اختيار أفضل تشكيل Select the Best Configurations .
يقوم المحلل تشكيلات النظم الفرعية المختلفة ويضبط خليط الوحدات بحيث تتفق كل النظم الفرعية مع تشكيل واحد . وعند عمل ذلك , يقدم المحلل التوصيات للمدير بغرض الموافقة عليها . وعند موافقة المدير على التشكيل , يرفع الأمر إلى لجنة قيادة نظام المعلومات الإدارية بغرض الموافقة عليها .
وتكون نتيجة عملية التصميم هذه تشكيل المعدات التي تجعل النظام قادراً على تحقيق أهدافه بأفضل صورة في إطار القيود الموضوعة عليه . وسوف توفر مواصفات النظام هذه الأساس الذي يؤدي في مرحلة التنفيذ .

5- إعداد اقتراح التنفيذ prepare the Implementation Proposal .
يعد المحلل اقتراح تنفيذ implementation proposal يخطط فيه عمل التنفيذ المراد أداؤه , وكذلك التكاليف . ويظهر في شكل (7-9) شكلاً للاقتراح .

1) ملخص لمنفذ الإدارة العليا
2) مقدمة
3) تعريف المشكلة
4) أهداف النظام و القيود
5) معايير الأداء
6) تصميم النظام
1-6 / وصف تلخيصي
2-6 / تشكيل المعدات
7) تأثير النظام المتوقع
1-7 / التأثير على الهيكل التنظيمي للمنشأة
2-7 / التأثير على عمليات المنشأة
3-7 / التأثير على موارد المنشأة
مشروع التنفيذ المقترح

6 - الموافقة , أو عدم الموافقة , على تنفيذ النظام

Approve or Disapprove the System Implementation
يكون قرار الاستمرار بالتنفيذ هاماً بصفة خاصة , حيث إن التنفيذ سوف يزيد عدد المشاركين بصورة كبيرة . فإذا تعدت المنافع المتوقعة من النظام تكاليفه , ستتم الموافقة على النظام .

مرحلة التنفيذTHE IMPLEMENTATION PHASE
التنفيذ- Implementationهو الحصول على الموارد الطبيعية و المفاهيمية التي تنتج النظام العام .

1- تخطيط التنفيذ Plan the Implementation .
مع بقاء مرحلة تطوير واحدة باقية قبل أن يعد النظام الجديد للاستخدام , يكون لدى المديرين و المتخصصين في المعلومات فهماً جيداً للعمل اللازم لتنفيذ تصميم النظام . ويمكنهم استخدام هذه المعرفة في تطوير خطة تنفيذ تفصيلية جداً .

2- الإعلان عن التنفيذ Announce the Implementation .
يعلن للعاملين مشروع التنفيذ بنفس الطريقة المتبعة في الإعلان عن دراسة النظام . ويكون الغرض من هذا الإعلان إخطار العاملين بقرار تنفيذ النظام الجديد وطلب التعاون منهم .

3- الحصول على موارد نظم المكونات Obtain the Hardware Resources .
يصبح تصميم النظام الموجود في تشكيل المعدات الذي حصل على الموافقة متاحاً لموردي أنواع معدات الحوسبة . ويقدم لكل مورد طلب عروض request for proposal (RFP) . والمبين شكل تخطيطي له في شكل (7-11) . ويمكن وصف تصميم النظم الموجود في القسم رقم (3) الموردين من اختيار وحدات الحوسبة التي ستؤدي أفضل عمل . وتذكر جدولة التشييد الموجودة في القسم رقم (4) للموردين متى يجب تسليم المعدات وجعلها معدة للاستخدام .
وعند وصول كل العروض وتحليلها , تختبر لجنة قيادة نظام المعلومات الإدارية المورد أو الموردين . ويوفر المتخصصين في المعلومات دعماً لهذا القرار عن طريق دراسة العروض وعمل التوصيات اللازمة .ومع الموافقة على الحصول على المعدات , تصدر المنشأة أوامرها .
4- الحصول على موارد نظم البرامج Obtain the Software Resources .
عندما تقرر المنشأة أن تنتج نظم برامج تطبيقاتها , يستخدم المبرمج التوثيق الذي أعده محلل النظم كنقطة بداية . ويمكن أن يعد المبرمج توثيقاً أكثر تفصيلاً , مثل الإنجليزية المهيكلة أو خرائط مسار البرامج . وتتم كتابة الشفرة ويختبر البرنامج ويكون المنتج النهائي مكتبة نظم برامج ببرامج التطبيقات .

وعند شراء نظم برامج تطبيقات سابقة الإعداد (جاهزة) , يمكن أن يتبع اختيار مورد نظم البرامج نفس الطريقة التي أتبعت في اختيار موردي نظم المكونات – طلب عروض والحصول على عروض وتقويمها و الاختيار منها .

5- إعداد قاعدة البيانات Prepare the Database .
يكون إداري قاعدة البيانات مسئولا عن كل الأنشطة المتعلقة بالبيانات , بما في ذلك إعداد قاعدة البيانات . وفي بعض الحالات سيلزم جمع بيانات جديدة , وفي حالات أخرى سيلزم إعادة تشكيل البيانات الموجودة بحيث تتفق مع تصميم النظام الجديد , وتنفذ هذه المهام ويتم إدخال البيانات في قاعدة البيانات .
فإذا لم تكن المنشأة تستخدم نظام إدارة قواعد البيانات database management system بالفعل , سيلعب إداري قاعدة البيانات دوراً رئيسياً في اختيار نظم البرامج هذه . وتوصف نظم برامج نظام إدارة قواعد البيانات في الفصل العاشر .
6- إعداد التسهيلات الطبيعية Prepare the Physical Facilities .
عندما لا يمكن أن تتفق نظم مكونات النظام الجديد مع التسهيلات الموجودة بالفعل , يلزم الدخول في تشييد تسهيلات جديدة أو إدخال تعديلات على التسهيلات الموجودة . فتشمل غرفة الحاسب الموجود بها حاسب كبير أو حاسب صغير بحجم كبير خليطاً من أرضيات مرتفعة , ومراقبات خاصة لدرجات الحرارة والرطوبة , ومعايير أمن معينة , ومعدات اكتشاف الحرائق ومقاومتها , وما شابه ذلك . ويجب جدولة مثل هذه التسهيلات بحيث إنها تتفق مع الخطة الشاملة للمشروع .
7- تعليم المشاركين والمستخدمين Educate the Participants and Users .
من الأكثر ترجيحاً أن يؤثر النظام الجديد على العديد من الأفراد .وبعضهم سيجعل النظام يعمل . هؤلاء هم المشاركين participants , ويشملون عمال إدخال البيانات , وموظفي كتابة الشفرة ,وموظفين آخرين وأفراد إداريين آخرين . وسوف يستخدم أفراد آخرون مخرجات النظام . ويجب تعلم كل هؤلاء الأفراد الأدوار التي سيلعبونها في النظام .

8- إعداد اقتراح التحويل Prepare the Cutover Proposal .
تسمى عملية إيقاف استخدام النظام القديم وبداية استخدام النظام الجديد تحويلا- cutover. وعندما يصبح واضحاً أن كل عمل التطوير على وشك الانتهاء , يوصي فريق المشروع المدير بإنجاز التحويل . ويمكن أن يأخذ الاقتراح شكل مذكرة أو تقرير شفوي .
9- الموافقة , أو عدم الموافقة , على التحويل إلى النظام الجديد
Approve or Disapprove Cutover to the New System
يراجع المدير ولجنة قيادة نظام المعلومات الإدارية حالة المشروع وإما أن يوافقوا , أو لا يوافقوا , على التوصية بالتحويل . وعندما توافق الإدارة على التوصية , فإنها تحدد الإجراءات التي ستتخذ والمهام التي ستكتمل قبل اعتبار التحويل مرة أخرى ثم تجدول بعد ذلك تاريخاً جديداً .
10- التحويل إلى النظام الجديد Cutover to the System
توجد أربعة مناهج أساسية للتحويل : تحويل إرشادي , وفوري , ومرحلي , ومتوازي. وهي مبينة في شكل (7-13) .

1- التحويل الإرشادي pilot يكون الإرشاد محاولة تنفيذ النظام في جزء من العمليات الشاملة , مثل أحد المكاتب أو إحدى المناطق الجغرافية . مثال ذلك , يمكن أن تجرب قوات الدفاع الجوي نظام مخزون نظام جديد في قاعدة جوية واحدة . فإذا نجح الإرشاد , ينفذ النظام في بقية العمليات , باستخدام إحدى مناهج التحويل الثلاثة الأخرى .
2- التحويل الفوري immediate أبسط منهج للتحويل هو التحويل من النظام القديم إلى النظام الجديد مرة واحدة في تاريخ معين . إلا أن هذا المنهج يكون ممكناً للمنشآت الصغيرة أو النظم الصغيرة فقط . حيث إن مشكلة التوقيت يمكن أن تزداد مع زيادة حجم العمليات .
3- التحويل المرحلي phased في التحويل المرحلي , يبدأ استخدام النظام الجديد في إحدى أجزاء المنشأة في كل مرة . مثال ذلك , يمكن أن تحول المنشأة نظام إدخال الأوامر , ثم بعد ذلك نظام المخزون , وهكذا , أو يمكن تحقيق التحويل لكل النظم في أحد المواقع الجغرافية , ثم في موقع جغرافي آخر , وهكذا . ويكون التحويل المرحلي شائعاً بالنسبة إلى النظم كبيرة الحجم .
4- التحويل المتوازي parallel يحتاج التحويل المتوازي الاحتفاظ بالنظام القديم حتى يختبر النظام الجديد بالكامل . ويقدم هذا المنهج أقصى درجة أمن ضد فشل النظام الجديد إلا أنه الأكثر تكلفة أيضاً , حيث يجب الاحتفاظ بمجموعتين من الموارد ( النظام القديم والنظام الجديد) .
شكل ( 7 - 13) مناهج التحويل
ويشير التحويل إلى نهاية جزء التطوير لدورة حياة النظام . ويمكن أن يبدأ استخدام النظام الآن .

مرحلة الاستخدامThe Use Phase
تحتوي مرحلة الاستخدام على خمس خطوات كما هو مبين في شكل (14:7).
1- استخدام النظام Use the system:
يستخدم المستخدمون النظام لتحقيق الأهداف التي سبق تحديدها له في مرحلة التخطيط.
2- مراجعة النظام Audit the system:
بعد أن أخذ النظام الجديد الفرصة للتواجد، تؤدي دراسة نظامية لتحديد مدى تحقيقه معايير الأداء، وتسمى مثل هذه الدراسة مراجعة ما بعد التنفيذ post implementation review ويمكن أن يؤديها أحد أفراد خدمات المعلومات أو أحد مراجعي الحسابات الداخليين، وترفع نتيجة المراجعة المحاسبية إلى ضابط المعلومات الرئيسي، وإلى لجنة قيادة نظام المعلومات الإدارية، وإلى المستخدم.
وتتكرر العملية، ربما على أساس سنوي، طالما أن النظام لا يزال مستخدماً.

3- صيانة النظام Maintain the system:
خلال وقت استخدام المدير للنظام، تجرى تعديلات عليه بحيث يستمر النظام في توفير اللازم، وتسمى هذه التعديلات صيانة النظم systems maintenance وتؤدى صيانة النظم لثلاثة أسباب:
1. تصحيح الأخطاء تستخدم النظم برامج بها أخطاء بسيطة أو نقاط ضعف في التصميم لم تكتشف عند اختبار النظام، وتصحح هذه الأخطاء.
2. الاحتفاظ بالنظام مجدداً على مدار الوقت، تحدث تغييرات في بيئة النظام والتي تتطلب تعديلات في التصميم أو نظم البرامج، مثال ذلك: يمكن أن تغير الحكومة الفيدرالية الشكل لحساب ضريبة الضمان الاجتماعي.
3. تحسين النظم مع استخدام المديرين النظم، فإنهم يجدوا طرقاً لإدخال تعديلات عليها، وتمرر هذه الاقتراحات إلى المتخصصين في المعلومات، الذين يدخلوا التعديلات على النظم طبقاً لها.
4- إعداد اقتراح إعادة الهندسة Prepare Reengineering Proposal:
عندما يصبح من الواضح للمستخدمين والمتخصصين في المعلومات أن النظام لم يعد صالحاً للاستخدام، يعد اقتراح للجنة قيادة نظام المعلومات الإدارية أن النظام في حاجة إلى إعادة هندسة Reengineering، ويمكن أن يأخذ الاقتراح شكل مذكرة أو تقرير يشمل دعماً للدخول في دورة حياة نظام جديدة، ويشمل مثل هذا الدعم أوصافاً لنقاط الضعف الداخلية في النظام، وإحصائيات خاصة بتكلفة الصيانة، وما إلى ذلك.
5- الموافقة، أو عدم الموافقة على إعادة هندسة النظام
Approval or Disapproval the Reengineering of the System
تحدد لجنة قيادة نظام المعلومات الإدارية ما إذا كان سيتم الدخول في دورة حياة نظام جديدة أم لا، فإذا كان هذا هو الحال يتخذ قرار خاص بمتى تبدأ بالمرحلة الأولى من دورة حياة النظام (مرحلة التخطيط)، ويمكن أن تتبع دورة الحياة الجديدة أنماط إعادة تصميم عملية الأعمال، وسوف يستخدم النظام الحالي حتى يحين وقت التحويل إلى نظام إعادة الهندسة.
وضع دورة حياة النظام في منظور
PUTTING THE SYSTEM LIFE CYCLE IN PERSPECTIVE
ربما تكون دورة حياة النظام أقدم منهجية في مجال الحاسب، فقد كان مطورا النظم المبكرة جداً ملمين بالحاجة إلى التخطيط أولاً، ثم التحليل، فالتصميم، فالتنفيذ.

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

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

ومن ضمن العديد من التعديلات التي تمت تجربتها، يجذب اثنان منها انتباها كبيراً، وهما عمل النماذج الأولية، والتطوير السريع للتطبيق rapid application development (RAD)، وعندما يصبح من الواضح لإدارة المنشأة أن أحد نظم المنشأة المعتمدة على الحاسب لا يتمتع بالمميزات الكاملة لتقنية الحاسب فإنها تتخذ قرارا بالإصلاح الكامل عن طريق استخدام إعادة تصميم عملية الأعمال BPR.

عمل النماذج الأوليةPROTOTYPING
يوفر النموذج الأولي Prototype فكرة للمطورين والمستخدمين المتوقعين عن كيف سيعمل النظام في صورته النهائية، وتسمى عملية إنتاج النموذج الأولي (عمل النموذج الأولي prototyping)

أنواع النماذج الأولية types of prototypes:
يوجد نوعان من النماذج الأولية: نموذج أولي من النوع الأول type 1 prototype والمحتمل أن يصبح نظاما عاملاً، ويكون النموذج الأولي من النوع الثاني type 2 prototype نموذج إعلانياً يعمل كنموذج للنظام العامل.

تطوير النموذج الأولي من النوع الأول: يبين شكل (15:7) الخطوات المشمولة في تطوير النموذج الأولي من النوع الأول، وتوجد هناك أربع خطوات على النحو التالي:

1) تعريف احتياجات المستخدم: يعد محلل النظم لقاءات مع المستخدم للحصول على فكرة عن المطلوب من النظام.
2) تطوير نموذج أولي: يستخدم محلل النظم، ربما يعمل مع متخصصين آخرين في المعلومات، أداة عمل نماذج أولية أو أكثر في تطوير النموذج الأولي، ومن أمثلة أدوات عمل النماذج الأولية منتجات التطبيقات المتكاملة وصناديق أدوات عمل النماذج الأولية، ويكون منتج التطبيقات المتكاملة Integrated application generator مجموعة من نظم برامج الإعداد (جاهزة( قادرة على إنتاج كل السمات المرجوة في النظام الجديد – قوائم، وتقارير، وشاشات، وقاعدة بيانات، وما إلى ذلك- ويشمل صندوق أدوات عمل النماذج الأولية prototype toolkit مجموعة من نظم برامج مستقلة، يكون كل منها قادراً على إنتاج جزء فقط من سمات النظام المرجوة.
شكل(15:7) تطوير النموذج الأولي من النوع الأول.
3) تحديد إذا كان النموذج الأولي مقبولاً أم لا، يعلم المحلل المستخدم استخدام النموذج الأولي ويوفر له الفرصة ليصبح معتاداً على النظام، وينصح المستخدم المحلل بما إذا كان النموذج الأولي كافياً أم لا، فإذا كان كافياً تتخذ الخطوة الرابعة، أما إذا لم يكن كذلك، يراجع النموذج الأولي عن طريق تكرار الخطوات الأولى والثانية والثالثة مع فهم أفضل لاحتياجات المستخدم.
4) استخدام النموذج الأولي، يصبح النموذج الأولي نظاماً عاملاً.
ويكون المنهج ممكناً عندما تمكن أدوات عمل النماذج الأولية النموذج الأولي من أن يحتوي
على كل العناصر الضرورية للنظام الجديد فقط .
تطوير النموذج الأولي من النوع الثاني: يبين الشكل (16:7) الخطوات المشمولة في تطوير نموذج أولي من النوع الثاني، وتكون أول ثلاث خطوات مثل نظيراتها في النموذج الأولي من النوع الأول، وتأخذ الخطوات التالية الشكل التالي:
4) كتابة شفرة النظام العامل: يستخدم المبرمج النموذج الأولي كأساس لكتابة شفرة النظام العامل.
5) اختبار النظام العامل: يختبر المبرمج النظام.
6) تحديد إذا كان النظام العامل مقبولاً أم لا: ينصح المستخدم المحلل بما إذا كان النظام مقبولاً أم لا، فإذا كان مقبولاً تتخذ الخطوة السابعة، وإلا تتكرر الخطوتين الرابعة والخامسة.
7) استخدام النظام العامل.

ويتبع هذا المنهج عندما يميل النموذج الأولي إلى أن يأخذ شكل Appearance النظام العامل فقط وليس عندما يحتوي على كل العناصر الضرورية للنظام العامل.
عمل النموذج الأولي ودورة حياة تطوير النظام
Prototyping and the system Development Life Cycle

بالنسبة إلى النظم صغيرة الحجم، يمكن أن يحل عمل النماذج الأولية محل دورة حياة تطوير النظام، إلا أنه بالنسبة إلى النظم كبيرة الحجم أو تلك التي تؤثر على وحدات تنظيمية كبيرة، يدخل عمل النماذج الأولية في دورة تطوير النظام، مثال ذلك: يمكن استخدام عمل النماذج الأولية في مرحلة التحليل لمساعدة المستخدمين على تعريف احتياجاتهم من المعلومات، وفي مرحلة التصميم لتقويم بدائل تشكيلات النظم.
جاذبية عمل النماذج الأولية The Attraction of Prototyping
يحب كل من المستخدمين والمتخصصين في المعلومات عمل النماذج أولية للأسباب التالية :
أنها تحسن الاتصالات بين محلل النظم والمستخدم
شكل (16:7) تطوير نموذج أولي من النوع الثاني.
يستطيع المحلل أن يؤدي عملاً أفضل في تحديده احتياجات المستخدم.
يلعب المستخدم دوراً أكثر نشاطاً في تطوير النظام.
يقضي المتخصص في المعلومات وقتاً أقل وجهداً أقل في تطوير النظام.
يكون التنفيذ أكثر سهولة لأن المستخدم يعرف ما يتوقعه.
وتمكن هذه المميزات عمل النماذج الأولية من تقليل تكاليف التطوير وزيادة رضاء المستخدم بالنظام الذي يسلم له.
أوجه القصور في عمل النماذج الأولية Potential Pitfalls of Prototyping
لا يكون عمل النماذج الأولية بدون أوجه قصور، والتي تشمل ما يلي:
يمكن أن ينتج عن الإسراع في تسليم النموذج الأولي قصور في تعريف المشكلة، وتقويم البديل، والتوثيق، ويستخدم مصطلح "سريع وغير متقن quick and dirty" في وصف بعض جهود عمل النماذج الأولية.
يمكن ألا تكون النماذج الأولية من النوع الأول كفؤة مثل النظم المكتوبة شفرتها بإحدى لغات البرمجة.
يمكن ألا يعكس التداخل بين الحاسب والإنسان الذي توفره بعض أدوات عمل النماذج الأولية أساليب تصميم جيدة.
ويجب أن يكون كل من المستخدم والمتخصص في المعلومات ملماً بأوجه القصور، هذه الممكنة عند اختيارهما اتباع منهج عمل النموذج الأولي.

تطبيقات تعد مرشحة جيدة لعمل النماذج الأولية Applications The Are Good Prospects for prototyping
يعمل عمل النماذج الأولية بصورة أفضل مع التطبيقات التي تتسم بما يلي:
مخاطرة مرتفعة لا تكون المشكلة مهيكلة جيداً، ويوجد معدل مرتفع للتغير عبر الوقت، وتكون متطلبات البيانات غير مؤكدة.
تداخل كبير من المستخدم تتسم النظم بحوار في الخط المفتوح بين المستخدم والحاسب المصغر أو النهاية الطرفية.
عدد كبير من المستخدمين يكون الاتفاق على تفاصيل التصميم صعب التحقيق دون الممارسة العملية.
الحاجة إلى تسليم سريع.
فترة استخدام قصيرة متوقعة للنظام.
نظام ابتكاري يكون النظام حديثاً جداً، إما في الطريقة التي يحل بها المشكلة أو في استخدامه لنظم المكونات.
سلوك المستخدم غير المتنبأ به ليس لدى المستخدم خبرة سابقة مع مثل هذا النظام.
ويمكن تطوير التطبيقات التي لا تعكس هذه الخواص عن طريق اتباع دورة حياة تطوير النظام بالطريقة التقليدية.
التطوير السريع للتطبيق
RAPID APPLICATION DEVELOPMENT
يعد التطوير السريع للتطبيق منهجية تستهدف الاستجابة السريعة لاحتياجات المستخدم مثلما يحدث من عمل النموذج الأولي إلا أنها أوسع في مداها، ويرتبط مصطلح التطوير السريع للتطبيق Rapid application development (RAD) بجيمس مارتن James Martin استشاري الحاسب والكاتب في مجال الحاسب، ويشير إلى دورة حياة التطوير التي تميل إلى إنتاج نظم بسرعة دون التضحية بالجودة.
ويكون التطوير السريع للتطبيق عبارة عن مجموعة متكاملة من الاستراتيجيات، والمنهجيات، والأدوات الموجودة في إطار شامل يسمى هندسة المعلومات، وتكون هندسة المعلومات information engineering (IE) الاسم الذي أعطاه مارتن لمنهجه الشامل لتطوير النظام، والذي يعالج الأمر كنشاط على مستوى المنشأة.
ويوضح شكل (17:7) طبيعة هندسة المعلومات من أعلى لأسفل، بما في ذلك كل من البيانات (الوجه الأيسر للهرم) والأنشطة (الوجه الأيمن للهرم)، وتبدأ هندسة المعلومات عند مستوى منفذي الإدارة العليا، مع تطبيق التخطيط الاستراتيجي لموارد المعلومات على المنشأة كلها، ويستخدم مارتن مصطلح التخطيط الاستراتيجي للمعلومات، وبعد ذلك تكون كل وحدة أعمال داخل المنشأة معرضة لتحليل مجال الأعمال business area analysis (BAA) لتعريف الأنشطة أو العمليات والبيانات اللازمة للوحدة لكي تعمل كما هو متوقع لها، ومع إتمام تحليل مجال الأعمال، يمكن الاستمرار في التطوير السريع للتطبيق.

المكونات الأساسية للتطوير السريع للتطبيقThe Essential Ingredients of RAD
يتطلب التطوير السريع للتطبيق مكونات أساسية: إدارة، وأفراد، ومنهجيات، وأدوات.
الإدارة: يجب أن تكون الإدارة، خاصة الإدارة العليا، صاحبة تجربة experimenter، راغبة في تأدية الأشياء بطريقة جديدة، أو تكون مطبقة مبكرة early adaptors والتي تتعلم بسرعة كيفية استخدام المنهجيات الجديدة، ويجب أن تكون الإدارة مدعمة تماما للتطوير السريع للتطبيق وتوفر بيئة العمل التي تجعل النشاط ممتعاً بقدر الإمكان.
شكل (17:7) يعد التطور السريع للتطبيق جزءاً متكاملاً من هندسة المعلومات.
الأفراد: بدلاً من استغلال فريق واحد في كل أنشطة دورة النظام، يميز التطوير السريع للتطبيق الكفاءات التي يمكن اكتسابها من خلال استخدام فرق متخصصة متعددة، ويمكن أن تكون هناك فرق لتخطيط المتطلبات، وتصميم المستخدم، والتشييد، ومراجعة المستخدم، والتحويل، ويكون أعضاء هذه الفرق متفهمين للمنهجيات والأدوات اللازمة لأداء مهامهم المتخصصة، ويستخدم مارتن مصطلح فريق ماهر في الأدوات المتقدمة skilled with advanced tools (SWAT) team.
المنهجيات: تكون منهجية التطوير السريع للتطبيق دورة حياة التطوير السريع
للتطبيق RAD life cycle، والتي تحتوي على أربع مراحل:
(1) تخطيط المتطلبات، و (2) تصميم المستخدم، و(3) التشييد، و(4) التحويل، وتعكس هذه المراحل، مثل دورة حياة تطوير النظام، منهج النظم، ويلعب المستخدمون الأدوار الرئيسية في كل مرحلة، باشتراكهم مع المتخصصين في المعلومات.
الأدوات: تحتوي أدوات التطوير السريع للتطبيق على لغات الجيل الرابع وأدوات هندسة نظم البرامج بمساعدة الحاسب التي تسهل عمل النماذج الأولية وإنتاج الشفرة أساساً.
وتمكن لغات الجيل الرابع المتخصصين في المعلومات أو المستخدمين من إنتاج شفرة حاسب دون استخدام لغات البرمجة التقليدية، ومن أمثلة لغات الجيل الرابع توجد SQL, FOCUS, Natural.

إعادة تصميم عملية الأعمالBUSINESS PROCESS REDESIGN (BPR)
يسمي استبدال العمليات المتقادمة بأخرى احدث إعادة تصميم عملية الأعمال Business process redesign (BPR)، كما يستخدم مصطلح إعادة هندسة عملية الأعمال business process reengineering أيضاً.

تؤثر إعادة تصميم عملية الأعمال على خدمات المعلومات بطريقتين:
أولاً: يمكن أن تطبق خدمات المعلومات إعادة تصميم عملية الأعمال لإعادة تصميم نظم معتمدة على الحاسب لا يمكن الاحتفاظ بها على قيد الحياة عن طريق الصيانة المعتادة، وتسمي مثل هذه النظم نظم التراث legacy systems، نظراً لأنها مرتفعة القيمة جداً إذا تم التفكير في الاستغناء عنها، إلا أنها تمثل استنزافاً لموارد خدمات المعلومات.
ثانيا: عندما تطبق المنشأة إعادة تصميم عملية الأعمال على عملياتها الرئيسية، يكون للجهد تأثير متموج ثابت ينتج عنه إعادة تصميم للنظم المعتمدة على الحاسب.
وقد استنبطت خدمات المعلومات ثلاثة أساليب لتطبيق إعادة تصميم عملية الأعمال على نظام المعلومات المعتمد على الحاسب، وتعرف هذه الأساليب الثلاثة بأنها (الثلاثة آر three Rs – الهندسة العكسية reverse engineering، وإعادة الهيكلة restructuring، وإعادة الهندسة reengineering، ويمكن تطبيق هذه المكونات مستقلة أو مع بعضها بعضاً.
الهندسة العكسية Reverse Engineering:
وجدت الهندسة العكسية أصلها في ذكاء الأعمال، فقد احتفظت المنشآت على مدى طويل بالتعرف على الحالة الحالية لمنتجات منافسيها عن طريق شراء عينات منها وفكها لمعرفة كيف تعمل هذه الأجزاء مع بعضها بعضاً، وتستخلص مواصفات التصميم لمنتجات المنافسين من المنتجات نفسها، بعكس النمط الذي به التصميم أولاً.

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

إعادة الهيكلة Restructuring:
تكون إعادة الهيكلة Restructuring تحويل النظام إلى صيغة أخرى دون تغيير وظيفته.
والمثال الجيد هو تحويل برنامج مكتوب في السنوات المبكرة للحوسبة، عندما كانت هناك قلة من نمطيات البرمجة، إلى برنامج آخر في صورة مهيكلة من المقاطع الهرمية، وبمجرد إعادة هيكلة البرنامج، فإنه يعاد استخدامه مرة أخرى، منتجاً نمطاً دورياً كما هو مبين في شكل (19:7) وكما في الهندسة العكسية يمكن عمل إعادة الهيكلة في اتجاه من الخلف خلال مرحلة من مراحل دورة حياة النظام، وتكون النتيجة نظاماً مهيكلاً بالكامل- من الخطة إلى الشفرة.

إعادة الهندسة Reengineering:
تكون إعادة الهندسة Reengineering التصميم الكامل للنظام بهدف تغيير وظيفيتهن وهي ليست منهجاً "نقي السريرة" لأن معرفة النظام الحالي لا تهمل بالكامل، ويتم الحصول على هذه المعرفة عن طريق الدخول في الهندسة العكسية أولاً، ثم يطور بعد ذلك النظام الجديد بطريقة معتادة، ويعطي اسم الهندسة للأمام forward engineering للعملية التي تتبع دورة حياة النظام بالطريقة المعتادة أثناء العمل في إعادة تصميم عملية الأعمال، ويبين الشكل (20:7) أنماط إعادة الهندسة للهندسة العكسية والهندسة للأمام.
شكل (20:7) تحتوي إعادة الهندسة على الهندسة العكسية تتبعها الهندسة للأمام.
اختيار مكونات إعادة تصميم عملية الأعمال selection of the BPR Components
يمكن تطبيق مكونات إعادة تصميم عملية الأعمال (the three Rs) مستقلة أو مع بعضها بعضاً، اعتماداً على درجة التغير المطلوبة، ويعتمد الخليط المناسب على الحالة الحالية للنظام بالنسبة إلى وظيفته وجودته التقنية، ويمثل شكل (21:7) رسماً يبين هذين التأثيرين، فتكون الجودة الوظيفية functional quality مقياساً لما يؤديه النظام، وتكون الجودة التقنية technical quality مقياساً لكيفية تأديته.
شكل (21:7) اختيار مكونات إعادة تصميم عملية الأعمال بناء على كل من الجودة الوظيفية والجودة التقنية.
طبقاً للربع السفلي الأيسر من الشكل، عندما تكون كل من الجودة الوظيفية والجودة التقنية ضعيفة، تكون هناك حاجة إلى مشروع هندسة للأمام، وتكون الأشياء رديئة لدرجة أنه من الأفضل البدء من البداية، واتباع خطوات دورة حياة النظام بطريقة معتادة.
وعندما تكون الوظيفية جيدة، بينما تكون الجودة التقنية ضعيفة، يجب أن تأتي إعادة الهيكلة بعد الهندسة العكسية، وتنتج الهندسة العكسية التوثيق الذي يمكن من إعادة الهيكلة.
وعندما تكون الوظيفية ضعيفة، بينما تكون الجودة التقنية جيدة تستدعى إعادة الهندسة، وفي هذه الحالة يعكس النظام أساليب حديثة إلا أنه لا يؤدي العمل ببساطة.وأخيراً، في الربع العلوي الأيمن، عندما تكون كل من الجودة الوظيفية والجودة التقنية جيدة، من الأفضل ترك الأشياء كما هي.

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

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

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