تحليل النظم الهيكلية وطرق التصميم

1. 1980 م: وكالة الحاسوب المركزي والاتصالات (CCTA) قامت بتقييم طرق التحليل والتصميم المتاحة.
2. 1981 م: تم اختيار طريقة أنظمة الإدارة من شركة Learmonth & Burchett Management Systems (LBMS) من بين قائمة قصيرة تضم خمس طرق.
3. 1983 م: أصبحت SSADM إلزامية لجميع مشاريع تطوير أنظمة المعلومات الحديثة في الحكومة البريطانية.
4. 1984 م: إصدار النسخة الثانية المعدلة من SSADM.
5. 1986 م: إصدار النسخة الثالثة المعدلة من SSADM، وتم تبنيها من قبل المركز الوطني للحوسبة (National Computing Centre - NCC).
6. 1988 م: تم تدشين شهادة كفاءة SSADM، وتم الترويج لها كمعيار "مفتوح".
7. 1989 م: بدأت الجهود لتوحيد الطريقة على المستوى الأوروبي، من خلال إطلاق مشروع شهادة منتجات هندسة البرمجيات بمساعدة الحاسوب (Computer-Aided Software Engineering - CASE).
8. 1990 م: إطلاق النسخة الرابعة المعدلة من SSADM.
9. 1993 م: إطلاق النسخة الرابعة من SSADM (V4)، بالإضافة إلى مشروع أدوات نظام التوافق.
10. 1995 م: تم الإعلان عن النسخة الرابعة المطورة (SSADM V4+)، وإطلاق النسخة V4.2.
11. 2000 م: قامت وكالة الحاسوب المركزي والاتصالات (CCTA) بإعادة تسمية SSADM لتصبح "Business Systems Development" (تطوير أنظمة العمل). تم إعادة هيكلة الطريقة إلى 15 وحدة نمطية، مع إضافة 6 وحدات أخرى.

1. نمذجة البيانات المنطقية (Logical Data Modeling):
   • هذه هي عملية تحديد، ونمذجة، وتوثيق متطلبات بيانات النظام المزمع تصميمه.
   • يتم تقسيم البيانات إلى وحدات مستقلة (وهي الأشياء التي يحتاجها العمل لتسجيل المعلومات) وعلاقات (وهي الروابط بين هذه الوحدات المستقلة).
2. نمذجة تدفق البيانات (Data Flow Modeling):
   • هذه هي عملية تحديد، ونمذجة، وتوثيق كيفية تحرك البيانات داخل نظام المعلومات.
   • تقوم نمذجة تدفق البيانات بفحص:
     • العمليات: وهي الأنشطة التي تحوّل البيانات من صيغة إلى أخرى.
     • مخازن البيانات: وهي المناطق التي تُخزّن البيانات.
     • الوحدات المستقلة الخارجية: وهي الكيانات التي ترسل البيانات إلى النظام أو تستقبل البيانات منه.
     • تدفقات البيانات: وهي المسارات (الطرق) التي تنتقل من خلالها البيانات.
3. نمذجة سلوك الوحدات المستقلة (Entity Behavior Modeling):
   • هذه هي عملية تحديد، ونمذجة، وتوثيق الأحداث التي تؤثر في كل وحدة مستقلة، والتسلسل الذي تحدث فيه هذه الأحداث.

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

وعند البدء بدراسة جدوى، فإن هناك أربعة جوانب رئيسية لا بُد من أخذها بعين الاعتبار:

• تقني: هل هذا المشروع ممكن تقنياً؟
• مالي: هل تستطيع المنشأة التجارية تحمل الأعباء المالية للمشروع؟
• تنظيمي: هل سيكون النظام الجديد متوافقاً مع التدريبات الحاليّة؟
• أخلاقي: هل سيكون الأثر للنظام الجديد مقبولاً اجتماعياً؟

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

مُنتج هذه المرحلة هو وثيقة دراسة جدوى رسمية ويُحدد سادم SSADM الأقسام التي ينبغي أن تحتويها الدراسة بما فيها أي نماذج أوليّة قد تم بناءها بالإضافة إلى تفاصيل الخيارات المرفوضة وأسباب رفضها.

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

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

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

منتجات هذه المرحلة هي:

• كتالوج المستخدمين يصف جميع مستخدمي النظام وكيفية تفاعلهم معه.
• كتالوج المتطلبات يذكر بالتفصيل كل متطلبات النظام الجديد.
• وصف الخدمات الحالية مؤلّف من مزيد.
• بناء بيانات منطقيّة بيئية حالية (ERD).
• مخطط السياق لمخطط تدفق البيانات (DFD) DATA FLOW DIAGRAM.
• مجموعة من مستويات من مخطط تدفق البيانات (DFDs)لنظام منطقي محلي.
• قاموس بيانات كامل يحتوي على العلاقة ما بين مخازن البيانات والوحدات المستقلة.

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

وفي عملية إعداد النماذج، سيكتشف المحلّل المعلومات التي تصنع كتالوجات المستخدمين والمتطلبات.

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

ثم يتم جمع الأفكار لتُشكّل مجموعة أو اثنتان أو ثلاث مجموعات من الخيارات المختلفة التي تٌقدّم للمستخدم، وتأخذ الخيارات بعين الاعتبار مايلي:

• درجة الأتمتة.
• الحدود ما بين النظام والمستخدمين.
• توزيع النظام، على سبيل المثال، هل هو مركزّ على مكتب واحد أم موزّع على عدة مكاتب؟
• التكلفة/الفائدة.
• تأثير النظام الجديد.

عند الضرورة، فإن الخيار سيكون موثقاً مع بناء بيانات منطقية ومخطط تدفق بيانات مستوى.

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

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

لإنتاج المواصفات المنطقيّة، يبني المحلّل النماذج المنطقيّة المطلوبة لكل من مخططات تدفق البيانات (DFDs) ومخططات علاقة الوحدات المستقلة (ERDs) وتُستخدم هذه في إنتاج تعاريف وظيفة النظام لكل وظيفة نظام سوف يتطلبها المستخدمون من النظام، والمحفوظات الدائمة للوحدات المستقلة (ELHs)و مخططات رسائل التأثير، هذه نماذج مُنتَج هذه المرحلة وهو توثيق كامل لمواصفات المتطلبات والذي يتكون من:

• كتالوج البيانات المُحدّث.
• كتالوج المُتطلبات المُحدّث.
• المواصفات المُعالجة والتي بدورها تتكون من:
• دور المستخدم/مصفوفة وظائف النظام.
• تعريفات وظيفة النظام.
• نموذج بيانات منطقي مطلوب.
• محفوظات دائمة للوحدات المستقلة.
• مخططات رسائل التأثير.

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

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

إلا أن الاعتبارات مختلفة إلى حد ما في كونها:

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

يجب أن تتوافق هذه النواحي مع أي قيود مفروضة من قِبل العمل كتوفر المال وتوحيد الأجهزة والبرامج.

مُخرِج هذه المرحلة هو خيَار نظام تقني تم اختياره.

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

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

مُنتج هذه المرحلة هو التصميم المنطقي والمكوّن من:

• كتالوج البيانات.
• بُنية البيانات المنطقيّة المطلوبة.
• نموذج عمليّة منطقيّة يشمل الحوارات ونموذج لعمليات التحديث والاستعلام.
• لحظة الإجهاد والانحناء.

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

تتحول بُنْيَة البيانات المنطقية إلى فن معماري مادي من حيث أبنية قاعدة البيانات. ويتم تحديد البُنية الدقيقة للوظائف وكيف يتم تنفيذها. كما تتم ترقية بُنية البيانات المادية عند الضرورة لتلبي متطلبات الحجم والأداء.

المُنتج هو تصميم مادي كامل والذي يُمكن أن يُخبر مهندسي البرنامج كيف يبنون النظام بتفاصيل محددة عن الجهاز والبرنامج وبمعايير ملائمة.