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

تحليل النُظم الهيكلية وطرق التَّصميم  هو مدخل نُظم إلى تحليل وتصميم أنظمة المعلومات. تم تطوير SSADM لصالح وكالة الحاسوب المركزي والاتصالات (Central Computer and Telecommunications Agency - CCTA) في المملكة المتحدة، والتي تُعرف حاليًا بمكتب التجارة الحكومية (Office of Government Commerce - OGC)، وهو مكتب حكومي بريطاني يهتم باستخدام التقنية في الحكومة، وذلك منذ عام 1980وحتى الآن.

 نظرة عامة 

 SSADM هي منهجية تحليل وتصميم النظم المهيكلة، تُستخدم في تحليل وتصميم أنظمة المعلومات.
 تم تطوير SSADM لصالح وكالة الحاسوب المركزي والاتصالات (Central Computer and Telecommunications Agency - CCTA) في المملكة المتحدة، والتي تُعرف حاليًا بمكتب التجارة الحكومية (Office of Government Commerce - OGC).
 تُعتبر SSADM منهجية تعتمد على نموذج الشلال (Waterfall Model) وتتميز بدقة توثيقية عالية في تصميم النظام، مقارنةً بطرق أحدث مثل تطوير التطبيقات السريعة (Rapid Application Development) ومنهجية تطوير الأنظمة الديناميكية (Dynamic Systems Development Method - DSDM).
 تستند SSADM إلى أعمال مدارس مختلفة في التحليل والتصميم الهيكلي، مثل:
 منهجية الأنظمة اللينة لبيتر تشيكلاند (Peter Checkland's Soft Systems Methodology).
 التصميم الهيكلي للاري كونستانتاين (Larry Constantine's Structured Design).
 منهجية يوردن الهيكلية لإدوارد يوردن (Edward Yourdon's Yourdon Structured Method).
 البرمجة الهيكلية لميشيل أ. جاكسون (Michael A. Jackson's Jackson Structured Programming).
 التحليل الهيكلي لتوم ديماركو (Tom DeMarco's Structured Analysis).
 أصبحت أسماء "Structured Systems Analysis and Design Method"و"SSADM" علامات تجارية مسجلة لمكتب التجارة الحكومية (OGC)، وهو مكتب تابع لوزارة المالية في المملكة المتحدة.

 تاريخ 

 المراحل الأساسية لتطور SSADM (Structured Systems Analysis and Design Method): 

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

 تقنيات SSADM 

 أهم ثلاث تقنيات مُستخدمة في SSADM (Structured Systems Analysis and Design Method) هي: 

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

 مراحل 
تتضمن طريقة سادم SSADM تطبيق سلسلة من التحليل، والتوثيق، ومهام التصميم
ذات الاهتمام بما سيأتي ذكره.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 ميزات وعيوب 
إن استخدام علم الطرق هذا يتضمن مشروعاً هاماً قد لا يُلائم جميع المشاريع.

وتُعد الميزات الأساسية لسادم SSADM هي:
 ثلاث وجهات نظر مختلفة للنظام.
 فصل الأوجه المنطقيّة والماديّة للنظام.
 تقنيات مُعرّفة جيداً وتوثيق.
 مُشاركة المُستخدم.

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

 المراجع 

OGC-Annex1  مكتب التجارة الحكومية OGC، تم الاسترجاع في 17/12/2010

History of SSADM لمؤلفيه مايك قودلاند، وكارل ريها (20يناير 1999م)مقدمة عن SSADM، تم الاسترجاع في 17_12_2010م

mModel Systems and SSADM أنظمة النموذج المحدودة، تم الاسترجاع في 17_12_2010م

 روابط خارجية 
What is SSADM? At webopedia.com

SSADM Version 4.3 structural standards

Introduction to Methodologies and SSADM 

Case study using pragmatic SSADM

Structured Analysis

Development Methodologies

تصنيف:أنظمة إدارة المحتوى
تصنيف:أنظمة معلومات
تصنيف:تحليل النظم
تصنيف:تصميم البرمجيات