Systems analysis in IT — تحليل النظم في تقنية المعلومات

From Systems analysis wiki
Jump to navigation Jump to search

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

تحليل النظم الكلاسيكي يغطي مجموعة واسعة من مجالات التطبيق، لا يقتصر على تطوير البرمجيات فحسب، بل يشمل أيضًا التغييرات التنظيمية، والاستراتيجيات، وجوانب أخرى.[١] [٢]

موضوع ومهام تحليل النظم في تقنية المعلومات

موضوع تحليل النظم في تقنية المعلومات هو نظام المعلومات (منتج برمجي و/أو خدمة) طوال دورة حياته — من الفكرة والتبرير إلى التنفيذ والتشغيل.

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

تشمل مهام تحليل النظم:

  • تحديد احتياجات وأهداف أصحاب المصلحة. يجمع المحلل ويوضح توقعات العملاء والمستخدمين والأطراف المعنية الأخرى؛ تُستخدم المقابلات والاستطلاعات والمراقبة وتحليل العمليات الحالية. تكون المخرجات عبارة عن مواصفات أولية للمتطلبات مع تقسيمها إلى متطلبات وظيفية («ما يجب أن يفعله النظام») وغير وظيفية (الموثوقية، الأداء، الأمان، إلخ).[1][2]
  • الصياغة الرسمية للمتطلبات وتوثيقها. يتم تحويل الطلبات إلى متطلبات قابلة للتحقق. يجب أن يكون المتطلب المصاغ جيدًا واضحًا لا لبس فيه، وكاملاً، وغير متناقض، وقابلاً للتحقق والتتبع إلى أهداف ذات مستوى أعلى؛ ويجب أن تكون مجموعة المتطلبات متسقة ومتكاملة.[3][4] في الممارسة العملية، تُستخدم وثائق موحدة: SRS (Software Requirements Specification) وفقًا لمعيار ISO/IEC/IEEE 29148، وكذلك في بعض الصناعات، URS (User Requirements Specification) والمواصفات الوظيفية.[5][6][7]
  • تحليل ونمذجة النظام. لفهم كيف سيعمل النظام ويتفاعل مع العالم الخارجي، تُبنى نماذج: مخططات حالات الاستخدام (Use Case) لسيناريوهات الاستخدام، ومخططات تدفق البيانات (DFD) لتدفقات البيانات وعمليات الأعمال، ومخططات الأصناف/المكونات وغيرها. تعمل النماذج كأساس لمقارنة الحلول والبنى البديلة.[8][9][10]
  • تقييم الجدوى واختيار الحل. تُجرى feasibility study (دراسة الجدوى الفنية والتنظيمية والاقتصادية والزمنية) ومقارنة البدائل المعمارية (trade-off). لتقييم جودة البنية وفقًا للسمات (مثل الأداء، قابلية التوسع، قابلية التعديل)، تُستخدم أساليب مثل ATAM (Architecture Tradeoff Analysis Method).[11][12] الاختيار بين، على سبيل المثال، البنية المتجانسة (monolithic) والبنية القائمة على الخدمات المصغرة (microservices) [٣] يعتمد على مفاضلات واضحة (تعقيد التشغيل مقابل قابلية التوسع المستقلة وسرعة التسليم) وفقًا لتوصيات الأدلة الصناعية.[13][14]
  • إعداد مخرجات المشروع. بناءً على نتائج التحليل، يتم تشكيل ما يلي:
    • مواصفات المتطلبات المعتمدة (مع تحديد أهميتها)،
    • النموذج المفاهيمي للنظام (مخططات/أوصاف)،
    • الحلول المعمارية والتصميمية (مخططات البيانات، واجهات الأنظمة الخارجية)،
    • خطة التنفيذ (مراحل/وحدات).
    • من الأهمية بمكان ضمان التتبع (bidirectional traceability) للمتطلبات إلى عناصر التصميم والاختبارات.[15][4]

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

المناهج والمنهجيات في تحليل النظم بتقنية المعلومات

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

  • المناهج الصلبة والناعمة. في مشاريع تقنية المعلومات، يفترض النهج الصلب (hard systems) أهدافًا ومتطلبات قابلة للصياغة الرسمية مسبقًا، والتفكيك والتصميم «من أعلى إلى أسفل». يُستخدم النهج الناعم (soft systems) عندما تكون الأهداف غير واضحة وتوجد وجهات نظر متعددة: تُستخدم عناصر من Soft Systems Methodology (SSM) (مثل rich picture، والتعريفات الجذرية، وCATWOE) لتنسيق فهم المشكلة والتغييرات المرغوبة؛ ثم تُترجم النتائج إلى متطلبات رسمية.[17][18]
  • منهجية SSM (Soft Systems Methodology). تم تطويرها في الأصل من قبل بيتر تشيكلاند للتغييرات التنظيمية، وتُعد SSM مفيدة في المراحل التمهيدية لمشاريع تقنية المعلومات: من دراسة الموقف الإشكالي وصياغة التعريفات الجذرية (بما في ذلك من خلال CATWOE) إلى مقارنة النماذج المفاهيمية بالواقع وتحقيق التوافق بين أصحاب المصلحة.[19][20]
  • المنهجيات المهيكلة: SADT/IDEF0. تقوم SADT بنمذجة النظام كتسلسل هرمي للوظائف؛ يحدد الترميز القياسي IDEF0 (IEEE 1320.1) الوظائف وواجهاتها من نوع I-C-O-M (Inputs, Controls, Outputs, Mechanisms). هذه الطريقة ملائمة للتفكيك الوظيفي وتنسيق حدود النظام بغض النظر عن الخوارزميات.[21][22]
  • التحليل الموجه للكائنات: UML و SysML (MBSE). أصبحت UML اللغة الأساسية للمتطلبات والتصميم (مخططات حالات الاستخدام، الأصناف، التسلسل، إلخ) وتسهل التحقق من صحة السيناريوهات مع المستخدمين؛ SysML يوسع UML لهندسة النظم (مخططات المتطلبات، المخططات البارامترية) ويعتمد على نهج MBSE، حيث يكون النموذج هو المخرج المركزي عبر جميع المراحل من المتطلبات إلى الاختبارات.[23][24][25]
  • نمذجة عمليات الأعمال: BPMN. يُستخدم معيار BPMN لوصف العمليات بيانيًا (pools, workflows, events, gateways)، بما في ذلك مقارنة الوضع الحالي as-is بالوضع المستهدف to-be في مواصفات المتطلبات والتكامل.[26][27]
  • العلاقة مع هندسة المتطلبات. تتضمن العملية مراحل elicitation–analysis–specification–validation–change management؛ معايير «المتطلب الجيد» وهيكل SRS منظمة بواسطة ISO/IEC/IEEE 29148. لتحديد الأولويات، تُستخدم تقنيات MoSCoW (Must/Should/Could/Won’t) وأساليب الاختيار متعدد المعايير، مثل AHP. في العمليات المرنة، ينعكس نشاط تحليل النظم في تحسين قائمة المنتجات (backlog refinement) وتتبع المتطلبات.[28][29][30][31]
  • العلاقة مع هندسة النظم. للأنظمة المعقدة (السيبرانية-الفيزيائية)، يُستخدم نموذج V: على الفرع «الأيسر» — تحليل النظم والبنية، وعلى الفرع «الأيمن» — التكامل، التحقق (verification) و التحقق من الصحة (validation) مع ربطها بمخرجات الفرع الأيسر. تشمل أساليب تقييم البنية حسب سمات الجودة ATAM (تحليل المفاضلات).[32][33]

يجمع تحليل النظم في تقنية المعلومات بين مناهج مجربة — من المنهجيات الناعمة لتنسيق الرؤية إلى الترميزات والمعايير الرسمية. يعتمد اختيار الأدوات على درجة وضوح المهمة: مع عدم اليقين المرتفع، تزداد أهمية SSM والتيسير، بينما مع الحدود الواضحة، تُستخدم النماذج الرسمية (UML/SysML, IDEF0, BPMN) واللوائح.

العلاقة مع بنية تقنية المعلومات وبنية المؤسسة

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

  • بنية أنظمة تقنية المعلومات. بالمعنى الضيق، بنية البرمجيات هي تنظيم المكونات وعلاقاتها والمبادئ التي يُسترشد بها عند تصميم الحل. من المهم أن يأخذ المحلل في الاعتبار الأساليب المعمارية (الطبقية، العميل-الخادم، الخدمات المصغرة، الموجهة بالأحداث، إلخ)، لأن المتطلبات غير الوظيفية (الموثوقية، قابلية التوسع، قابلية التعديل) غالبًا ما تحدد القرارات المعمارية ومفاضلاتها.[34][35] في مرحلة مبكرة من التحليل، يتم تشكيل الرؤية المعمارية (high-level vision) وتطوير مخطط أولي للحل للتحقق من قابلية المتطلبات للحياة (تعتمد مدة التكرارات ومستوى التفصيل على المنهجية).[36]
  • الأنماط والحلول الأولية. لتلبية المتطلبات غير الوظيفية، تُستخدم الأنماط المعمارية (architectural patterns). على سبيل المثال، للتفاعل غير المتزامن والارتباط الضعيف — نمط النشر-الاشتراك (publish–subscribe) عبر وسيط رسائل في بنية موجهة بالأحداث.[37]
  • TOGAF (The Open Group Architecture Framework). أحد أكثر أطر عمل بنية المؤسسات شيوعًا؛ يتضمن طريقة ADM (Architecture Development Method) ومخرجات لإدارة البنية (مستودع، كتالوجات/مصفوفات، مبادئ). في TOGAF، تعد إدارة المتطلبات عملية شاملة ومتكاملة في جميع مراحل ADM.[36] لدعم المتطلبات والتتبع، تُستخدم الكتالوجات والمصفوفات (على سبيل المثال، المتطلبات ↔ الخدمات، الوظائف ↔ المكونات)، كما يتم التمييز بين Architecture Building Blocks و Solution Building Blocks.[38][39] تُسجل مبادئ ومعايير المؤسسة في الكتالوجات المقابلة وتعمل كـمتطلبات غير وظيفية خارجية لفرق المشروع.[40] يتم تأكيد توافق الحلول مع البنية المستهدفة من خلال إجراء مراجعة الامتثال المعماري (Architecture Compliance Review).[41] يفترض نهج TOGAF وجود Architecture Vision أولية وتفصيل لاحق (البيانات/التطبيقات/التقنيات) مع خطة ترحيل وإدارة تغييرات المتطلبات.[42][43]
  • Zachman Framework. أنطولوجيا مبكرة ومؤثرة لمخرجات بنية المؤسسة، مقدمة كمصفوفة 6×6 (وجهات نظر × جوانب «ماذا/كيف/أين/من/متى/لماذا»). يتوافق صف «المصمم» مع تحليل النظم والتصميم؛ تحدد الأعمدة اكتمال النظر في البيانات والوظائف/العمليات والأدوار والموقع والدافع. يعمل الإطار كتصنيف (وليس كمنهجية) ويساعد على ضمان اكتمال وصف الحل في مشهد المؤسسة.[44]
  • العلاقة مع بنية المؤسسة (Enterprise Architecture, EA). يعمل محلل النظم في سياق EA: يتم تتبع المتطلبات الجديدة إلى قدرات الأعمال والنموذج التشغيلي؛ تُطبق معايير وقيود مبدئية للمؤسسة (الأمان، التوافق، إلخ).[45][36] في مرحلة البدء، يتم تشكيل Architecture Vision (الأهداف/القيود، المتطلبات عالية المستوى)، ثم يقوم المحلل بالتفصيل، مع الحفاظ على التتبع إلى الرؤية والمعايير المؤسسية؛ يتم الكشف عن عدم الامتثال للمعايير في المراجعات المعمارية وقد يؤدي إلى تعديلات على الحل.[36][46]

الخلاصة: يشكل تحليل النظم والتصميم المعماري رابطًا «المتطلبات → الحلول المعمارية → المفاضلات حسب سمات الجودة». يعتمد اختيار الأساليب (الأنماط/القوالب، مخرجات TOGAF، تصنيف Zachman) على طبيعة المشروع وأطر البنية المؤسسية.

العمليات والممارسات

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

  • SDLC الكلاسيكي (Waterfall). تسبق مرحلة تحليل النظم وتحديد المتطلبات (System Analysis & Requirements Definition) مرحلتي التصميم والتنفيذ؛ تُثبت المتطلبات في وثيقة SRS مفصلة كأساس للتخطيط والعقود. يكون فعالاً في المجالات المستقرة والمنظمة؛ تُقلل مخاطر «تجميد» المتطلبات من خلال مراجعات SRR ومراجعات أخرى وإدارة التغيير عبر CCB.[47][48][49]
  • المنهجيات المرنة (Agile). التحليل مستمر: بدلاً من وثيقة SRS نهائية، تتم إدارة قائمة مهام المنتج (product backlog) المكونة من قصص المستخدم (user stories) مع معايير القبول، والتي يتم تحسينها في جلسات (backlog refinement)؛ يُطبق BDD (Given–When–Then)؛ يتم تعويض خطر فقدان بنية متكاملة من خلال التطوير المعماري المبكر والتتبع الشفاف للمتطلبات ↔ التنفيذ/الاختبارات.[50][51][52]
  • DevOps و SRE. تتطلب الإصدارات المتكررة متطلبات تشغيلية «افتراضية»: الأتمتة، القابلية للمراقبة، التراجع. تُصاغ المتطلبات غير الوظيفية كـ SLO/SLI، وتُدار ميزانية الخطأ (error budget)؛ تُضاف مهام السجلات/المقاييس/التتبعات/التنبيهات إلى قائمة المهام؛ للإصدار دون توقف — تُستخدم أنماط blue/green وغيرها.[53][54][55]
  • إدارة المتطلبات والمخاطر. للمتطلبات في ALM حالات وروابط مع المهام/الإصدارات/العيوب؛ من الضروري التحكم في الإصدارات، وتحليل تأثير التغيير، وإعادة تحديد الأولويات بانتظام.[56][57]
  • ضمان الجودة (QA). تُبنى الجودة في مرحلة المتطلبات: المراجعات، «Three Amigos»، خطة Acceptance Test Plan، الاختبارات الآلية لمعايير القبول (BDD/ATDD).[58][59]
  • القابلية للمراقبة والموثوقية. تُدرج في المتطلبات SLA/SLO، و MTTR، و MTBF مع أهداف قابلة للقياس وطرق للتحكم؛ تأتي المعلمات من قطاع الأعمال/التشغيل وتُدمج في البنية واختبارات الموثوقية.[60][61]

المقاييس وجودة المخرجات

لتقييم عمل محلل النظم وجودة نتائجه، تُستخدم معايير مقبولة عمومًا. المتطلبات والنماذج عالية الجودة هي أساس المشروع الناجح، لذا تتم إدارتها طوال دورة الحياة (elicitation → specification → verification/validation → change management). سمات جودة المتطلبات الأساسية مثبتة في معايير ISO/IEC/IEEE 29148 و (تاريخيًا) IEEE 830.[3][62][1]

  • الصحة (Correctness) — يعكس المتطلب حاجة حقيقية ومتفق عليه مع خبراء مجال العمل؛ يتم تأكيده من خلال التحقق من الصحة (review/inspection، النماذج الأولية، السيناريوهات).[1][4]
  • الاكتمال (Completeness) — تم أخذ الجوانب والشروط الأساسية في الاعتبار.
    • اكتمال المتطلب الفردي: يتم تحديد التفاصيل الضرورية (على سبيل المثال، «يتحول المؤشر إلى اللون الأحمر عند حدوث عطل»، وليس فقط «يصبح أحمر»).
    • اكتمال المواصفات: تغطية السيناريوهات/الأدوار، تحديد المتطلبات غير الوظيفية (NFR)؛ يتم تحقيق ذلك من خلال قوائم التحقق والتتبع إلى أهداف العمل؛ من المفيد إجراء تدقيق مستقل للاكتمال (QA/review).[3][63]
  • الوضوح وعدم الغموض (Unambiguity) — تُفسر الصياغات بطريقة واحدة فقط؛ يساعد في ذلك استخدام مسرد للمصطلحات، وقوالب مثل «يجب على النظام القيام بـ A، عندما B، إذا C»، والأمثلة؛ تُرفق المخططات بدليل للرموز. يتم التحقق من خلال مبدأ «الأربعة أعين».[3][1]
  • الاتساق (Consistency) — لا تتعارض المتطلبات مع بعضها البعض أو مع القيود الخارجية؛ تُستخدم الهيكلة، والجداول المجمعة للسمات، والمراجعات الجماعية؛ يتم التحقق من اللوائح/المعايير.[3][63]
  • القابلية للتحقق/الاختبار (Verifiability) — يتم تأكيد تحقيق المتطلب من خلال اختبار/عرض/تحليل؛ تُستبدل الصياغات غير القابلة للتحقق بمعايير قابلة للقياس؛ للمتطلبات غير الوظيفية، تُحدد مقاييس وتُثبت معايير القبول مسبقًا.[3][63]
  • القابلية للتعديل والتتبع (Modifiability & Traceability) — معرفات فريدة، هيكل منطقي («فكرة واحدة — فقرة واحدة»)، عدم وجود تكرار؛ يتم دعم الروابط «المتطلب ↔ المصدر/الهدف/التصميم/الاختبار»، وتُدار مصفوفة التتبع (RTM).[64][3]
  • الترتيب وتحديد الأولويات — جودة مجموعة المتطلبات؛ تُستخدم تقنيات MoSCoW و MCDM (مثل AHP)؛ يؤثر تحديد الأولويات بالتعاون مع قطاع الأعمال على التخطيط والمخاطر.[65][66]

مقاييس جودة المتطلبات (أمثلة):[63][1]

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

في العمليات الناضجة (مثل CMMI المستوى 3+)، توجد لوائح لجودة المتطلبات: فحوصات رسمية، تدقيق الامتثال للقوالب، جمع/تحليل المقاييس.[67] في المجالات الحرجة (إلكترونيات الطيران، الفضاء، إلخ)، تُستخدم الأساليب الرسمية لزيادة الموثوقية.[68]

الأخطاء الشائعة

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

المشاكل النموذجية، عواقبها، وطرق الوقاية منها.

  • عدم الاكتمال والمتطلبات المفقودة. يتم إغفال الأدوار ذات الصلاحيات الخاصة، والحالات الحدية، والمتطلبات غير الوظيفية (NFR). العواقب: إعادة تصميم البنية وتأجيل الإطلاق. كيفية التجنب: قوائم التحقق، جلسات العصف الذهني «ماذا لو...»، إشراك المختبرين مبكرًا، التتبع إلى أهداف العمل.[1][69]
  • صياغات غير واضحة وغامضة. العواقب: ينفذ المطورون «شيئًا خاطئًا»، والعميل غير راضٍ. كيفية التجنب: معايير قابلة للقياس، مسرد للمصطلحات، قوالب «A، عندما B، إذا C»، مراجعة الأقران (peer‑review).[3][69]
  • متطلبات متناقضة. العواقب: تأخيرات للتوضيحات، إعادة عمل عند التكامل. كيفية التجنب: الهيكلة، التحقق من قواعد العمل/اللوائح، جلسات حل النزاعات، التحقق من الاتساق في المراجعات.[3][1]
  • متلازمة «الطلاء بالذهب» (gold‑plating). العواقب: زيادة الحجم، التعقيد، نقاط فشل جديدة. كيفية التجنب: ربط كل متطلب بهدف/مقياس؛ في Agile — عدم إدراج ما هو غير ضروري في قائمة المهام؛ تحديد النطاق (scope)؛ انظر YAGNI.
  • التفصيل المفرط حيث لا حاجة له. كيفية التجنب: فصل ماذا/لماذا (المتطلبات) عن كيف (التصميم/التنفيذ)؛ استخدام design‑free requirements حيثما كان ذلك مناسبًا.[3]
  • انتهاك قابلية إدارة المتطلبات. العواقب: ارتباك في الإصدارات، تنفيذ «الشيء الخاطئ». كيفية التجنب: مصدر موحد للحقيقة في ALM، تأريخ وحالات، مصفوفة تتبع المتطلبات (RTM) وتحليل تأثير التغيير؛ إدارة التغييرات عبر CCB.[64][1]
  • عدم مشاركة المستخدمين. كيفية التجنب: المقابلات، المراقبة، النماذج الأولية، العروض التقديمية المنتظمة؛ التحقق الصريح من الصحة مع أصحاب المصلحة.[3][1]
  • «الشلل التحليلي» المطول جدًا. كيفية التجنب: منطقة الاكتفاء، التكرارية وتحديد الأطر الزمنية (timeboxing)؛ إطلاق MVP/زيادات وتصحيح بناءً على التغذية الراجعة.[1]
  • تجاهل المتطلبات غير الوظيفية. كيفية التجنب: تحديد المتطلبات غير الوظيفية (NFR) (مثل FURPS+)، وضع معايير قابلة للقياس، إدراجها في خطة الاختبار والحلول المعمارية.[1][3]
  • أخطاء التواصل و«العامل البشري». كيفية الحل: تطوير مهارات إجراء المقابلات والتيسير، الحفاظ على الحياد، توثيق القرارات ومصادر المتطلبات (التتبع إلى الأهداف).[1]

تُختزل معظم المشاكل في جودة الصياغات، واكتمال المتطلبات وقابليتها للإدارة؛ تطبيق معايير ISO/IEC/IEEE 29148 وممارسات SWEBOK (القابلية للتحقق من الصحة، التتبع، التكرارية) يقلل بشكل كبير من مخاطر تجاوز المواعيد النهائية وإعادة العمل.[3][1]

القيود

على الرغم من فعالية تحليل النظم في تقليل عدم اليقين، إلا أن له قيوده:

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

تأثير التقنيات الحديثة على تحليل النظم في تقنية المعلومات

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

  • البيانات و AI/ML: ما يضاف إلى التحليل. بالنسبة للأنظمة التي تستخدم الذكاء الاصطناعي، يتم منذ البداية تحديد أهداف وسياق التطبيق، ومتطلبات مصادر وجودة البيانات، بالإضافة إلى مقاييس الثقة في قرارات النموذج (الموثوقية، الأمان، القابلية للتفسير، الخصوصية، العدالة). يتم التخطيط لفحوصات TEVV (testing, evaluation, verification, validation)، والمراقبة أثناء التشغيل، والإيقاف/السحب الآمن للنموذج. تتوافق هذه الخطوات مع وظائف GOVERN–MAP–MEASURE–MANAGE من إطار عمل NIST لإدارة مخاطر الذكاء الاصطناعي؛ وتنعكس في وثيقة SRS، والبنية، وخطط التحقق/التشغيل.[70]
  • DevSecOps: الأمان «منذ البداية» وبشكل افتراضي. أصبح دمج الأمان في كل مرحلة من مراحل CI/CD هو القاعدة: الفحوصات التلقائية (SAST/DAST)، فحص التبعيات والحاويات، سياسات النشر، المراقبة الأساسية. تُستخدم سجلات موثوقة للمخرجات وصور قياسية «مُحصنة»؛ تُطبق مبادئ الثقة الصفرية. في تحليل النظم، يتم وصف نقاط التحكم في خط الأنابيب مسبقًا (شروط اجتياز المراحل)، والربط بين المتطلبات وضوابط الأمان، وقواعد الانتقال بين البيئات (dev/test/stage/prod).[71]
  • ما الذي يتغير في الوثائق (المخرجات). القسم الذي يظهر أو يتم توضيحه في الوثائق الرئيسية عند وجود البيانات الضخمة (Big Data) و AI/ML وعند العمل وفقًا لـ DevSecOps:
    • SRS / مواصفات المتطلبات: أهداف وسياق تطبيق الذكاء الاصطناعي؛ متطلبات البيانات (المصدر، الجودة، القيود الأخلاقية والقانونية)؛ مقاييس النموذج (الدقة، الموثوقية، زمن الاستجابة)؛ خطة TEVV (testing, evaluation, verification, validation)؛ متطلبات الشفافية/القابلية للتفسير والخصوصية؛ معايير إيقاف/سحب النموذج من التشغيل.[70]
    • البنية والحلول (Architecture, ADR): نتائج نمذجة التهديدات؛ تدابير «الأمان افتراضيًا» (التشفير، التحكم في الوصول، إدارة الأسرار، مبدأ الامتياز الأقل)؛ قيود على استخدام البيانات/النماذج؛ سجلات ADR مع تقييم المخاطر والمفاضلات.[71][70]
    • خطة التحقق والتأكد من الصحة (V&V / TEVV): سيناريوهات اختبار النماذج والبيانات؛ عتبات القبول لمقاييس الجودة؛ مراقبة انحراف البيانات/النموذج؛ إجراءات إعادة التقييم الدوري وإعادة التحقق من الصحة.[70]
    • سياسات CI/CD و«بوابات» خط الأنابيب: الفحوصات التلقائية SAST/DAST، SCA (التبعيات)، فحص الحاويات؛ توقيع وتخزين المخرجات في سجلات موثوقة؛ قواعد الترقية بين البيئات (dev/test/stage/prod) وشروط حظر البناء عند فشل الفحوصات؛ متطلبات المراقبة الافتراضية.[71]
    • خطة إدارة البيانات والنماذج: كتالوج المصادر وسلالة البيانات (lineage)؛ معايير جودة وتوفر البيانات؛ إصدارات مجموعات البيانات/النماذج؛ جدول (إعادة) التدريب ومراقبة التحيز (bias)؛ سياسة الوصول والتخزين؛ خطة التعطيل الآمن للنموذج وحذف البيانات إذا لزم الأمر.[70]
    • التشغيل والمراقبة (Ops/Runbook): مقاييس الثقة في الذكاء الاصطناعي و SLO؛ التدقيق والتسجيل؛ تنبيهات على التدهور/الحالات الشاذة؛ خطة الاستجابة للحوادث؛ آلية احتياطية/إيقاف طارئ (fallback/kill‑switch) لمكونات الذكاء الاصطناعي؛ متطلبات إعداد التقارير والتحليل بعد الحادث.[70][71]
    • التتبع (end‑to‑end): روابط واضحة «المتطلب ↔ التحكم/الفحص في خط الأنابيب» و «المتطلب ↔ الاختبار/المراقبة في التشغيل»، بحيث يمكن التحقق بشكل مثبت من الأمان والجودة طوال دورة الحياة.[71][70]
  • دور محلل النظم.
    • يدير سياق ومخاطر الذكاء الاصطناعي (الجهات الفاعلة، سيناريوهات التطبيق، الافتراضات وقيود البيانات)؛
    • يضمن التتبع «المتطلب ↔ التحكم الأمني في خط الأنابيب»؛
    • يصيغ متطلبات غير وظيفية قابلة للتحقق (الأمان، الشفافية، القابلية للمراقبة) طوال دورة حياة النظام.[70][71]

الاختلافات عن تحليل النظم الكلاسيكي

مصطلح «системный анализ» تاريخيًا أوسع من تطوير البرمجيات. تحليل النظم الكلاسيكي هو نهج لحل المشكلات المعقدة متعددة التخصصات (الاجتماعية، الاقتصادية، الإدارية)، يعتمد على التفكير المنظومي والأساليب الكمية، وعادة ما يكون لدعم القرارات الإدارية. في تقنية المعلومات، يُفهم تحليل النظم على أنه تخصص تطبيقي في مجال هندسة البرمجيات، يركز على إنشاء نظم المعلومات.

فيما يلي الاختلافات الرئيسية.

  • الأهداف وموضوع التحليل. يحلل التحليل الكلاسيكي المشكلات سيئة التنظيم و«الغامضة» ويحسن الأنظمة الاجتماعية-التقنية القائمة بالفعل (شبكة النقل الحضرية، استراتيجية الشركة، السياسة البيئية). الموضوع هو نظام حقيقي؛ والمهمة هي مساعدة صانع القرار على اختيار مسار العمل. بالنسبة لتحليل النظم في تقنية المعلومات، الهدف هو تصميم وإنشاء نظام معلومات جديد أو منتج برمجي يلبي المتطلبات. الموضوع هو النظام المُصمم؛ والتركيز على السلوك والخصائص التي يحتاجها المستخدمون.
  • الأسس المنهجية. تعتمد المدارس الكلاسيكية على التفكير المنظومي وغالبًا على الرياضيات. النهج الصلب (hard systems) — صياغة المشكلة بشكل رسمي، معايير كمية، التحسين (كما في operations research). تعترف المنهجيات الناعمة (soft systems) بتعدد وجهات النظر؛ مثال على ذلك Soft Systems Methodology (SSM)، حيث يتم من خلال المناقشات والنماذج المفاهيمية الاتفاق على التغييرات المرغوبة. في تقنية المعلومات، الأساس هو التخصصات الهندسية: هندسة المتطلبات، تصميم البرمجيات، الأطر المعمارية. تُطبق عمليات موحدة (ISO/IEC/IEEE 15288, 12207, 29148)، وترميزات UML/SysML، وممارسات إدارة التغيير.
  • الأدوار والمخرجات. في التحليل الكلاسيكي، غالبًا ما يكون دور «محلل النظم» غير رسمي؛ النتائج هي تقرير تحليلي، توصيات، نماذج رياضية، سيناريوهات «ماذا لو». في تقنية المعلومات، دور المحلل (أو محلل الأعمال) رسمي؛ يتم إصدار مواصفات المتطلبات، نماذج النظام (UML, ER)، مواصفات الواجهات، قصص المستخدم وقائمة المهام — وهي مخرجات يستخدمها المطورون والمختبرون مباشرة.
  • دورة الحياة والعملية. لا يوجد للتحليل الكلاسيكي قالب موحد: تعتمد الخطوات على المشكلة (في SSM — من دراسة الموقف إلى تنفيذ التغييرات). في تقنية المعلومات، تُعتمد دورات SDLC القياسية: في النموذج الشلالي، توجد مرحلة منفصلة لتحليل المتطلبات؛ في المناهج التكرارية والمرنة، التحليل هو نشاط مستمر في كل سباق (sprint). توسع الممارسات الحديثة (DevOps, CI/CD) نطاق التحليل ليشمل التشغيل: تؤخذ في الاعتبار متطلبات الصيانة والمراقبة وقابلية التحديث. بعبارة أخرى، تحليل النظم في تقنية المعلومات مدمج في دورة حياة التطوير، بينما يُنفذ التحليل الكلاسيكي غالبًا كنشاط استشاري أو مشروع.

محلل النظم

محلل النظم في تقنية المعلومات — هو متخصص مسؤول عن التفكير المنظومي في تصميم وتطوير نظم المعلومات: صياغة المتطلبات والتحقق من صحتها، النمذجة (UML/BPMN)، تنسيق الحلول المعمارية وضمان التكامل. يتم تحديد الدور ومتطلبات التأهيل في روسيا الاتحادية في المعيار المهني والمعايير التعليمية الفيدرالية للدولة.

الهدف الرئيسي لنوع النشاط المهني: ضمان توافق خدمة تقنية المعلومات، النظام الآلي، نظام المعلومات الآلي، نظام التحكم الآلي، المنتج البرمجي أو المعلوماتي أو الأداة (المشار إليها فيما يلي بـ«النظام») مع البيئة والمتطلبات والقيود الأولية، وأهداف الأتمتة والنشاط المؤتمت من خلال تطوير وتقديم حلول تصميمية عالية الجودة ومترابطة للأطراف المعنية عند إطلاق وتنسيق أعمال المنفذين الفرديين طوال دورة حياة النظام (المعيار المهني «محلل النظم» (أمر وزارة العمل الروسية رقم 367ن بتاريخ 27.04.2023).[72]

مسرد المصطلحات الرئيسية

المفاهيم الأساسية والمشاركون

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

المتطلبات: الأنواع والتوثيق

  • المتطلبات الوظيفية — تصف ما يجب أن يفعله النظام؛ وظائفه وسلوكه.
  • المتطلبات غير الوظيفية — تصف سمات جودة النظام (الموثوقية، الأداء، الأمان، سهولة الاستخدام، قابلية التوسع، إلخ).
  • مواصفات المتطلبات (الأولية) — وثيقة تحتوي على المجموعة الأولية من المتطلبات التي تم جمعها في المراحل الأولى من المشروع.
  • SRS (Software Requirements Specification) — وثيقة موحدة تصف بالتفصيل متطلبات البرمجيات وفقًا للمعايير الدولية (مثل ISO/IEC/IEEE 29148).
  • URS (User Requirements Specification) — وثيقة تصف متطلبات المستخدم للنظام من منظور عمليات الأعمال وتوقعات المستخدم النهائي.
  • المتطلبات ذات الأهمية المعمارية (ASR) — المتطلبات التي تؤثر بشكل كبير على القرارات والمفاضلات المعمارية.
  • المتطلبات الشاملة (CFR) — مرادف للمتطلبات غير الوظيفية، يؤكد على طبيعتها الشاملة عبر النظام.
  • معايير القبول (Acceptance Criteria) — شروط قابلة للتحقق، عند استيفائها، يعتبر العمل على المتطلب مقبولاً.
  • تعريف الجاهزية (Definition of Ready - DoR) — اتفاق على جاهزية عنصر في قائمة المهام للتطوير (الوضوح، التقدير، المعايير).
  • تعريف الإنجاز (Definition of Done - DoD) — اتفاق على «اكتمال» العمل (الكود، الاختبارات، التوثيق، النشر).
  • القيد (Constraint) — شرط صارم يحد من الحلول (المواعيد النهائية، المنصات، المعايير، التراخيص).
  • الافتراض (Assumption) — فرضية تُقبل دون دليل، وتتطلب التحقق من صحتها لاحقًا.
  • جودة المتطلبات — الخصائص وفقًا لـ ISO 29148: الوضوح، الاكتمال، عدم التناقض، القابلية للتحقق، الذرية.

الصياغة الرسمية، التتبع، وتحديد أولويات المتطلبات

  • الصياغة الرسمية للمتطلبات — عملية تحويل الطلبات غير الرسمية إلى متطلبات واضحة وقابلة للتحقق ولا لبس فيها.
  • تتبع المتطلبات — القدرة على تتبع دورة حياة المتطلب من مصدره إلى التنفيذ والاختبار والنشر.
  • Bidirectional traceability (التتبع ثنائي الاتجاه) — القدرة على تتبع الروابط بين المتطلبات وعناصر التصميم وسيناريوهات الاختبار في كلا الاتجاهين، الأمامي والعكسي.
  • MoSCoW — تقنية لتحديد أولويات المتطلبات، تصنفها إلى Must-have (يجب أن يكون)، Should-have (يفضل أن يكون)، Could-have (يمكن أن يكون)، و Won't-have (لن يكون).
  • BDD (Behavior-Driven Development) — منهجية تطوير تُكتب فيها الاختبارات بلغة طبيعية تركز على سلوك النظام من وجهة نظر المستخدم (تنسيق Given–When–Then).

الترميزات والنمذجة

  • UML (Unified Modeling Language) — لغة نمذجة رسومية موحدة لتحديد وتصور وبناء وتوثيق مكونات أنظمة البرمجيات.
  • SysML (Systems Modeling Language) — امتداد لـ UML لهندسة النظم، يدعم نمذجة جوانب مختلفة من الأنظمة المعقدة، بما في ذلك المتطلبات والسلوك والهيكل والمعلمات.
  • BPMN (Business Process Model and Notation) — معيار ترميز رسومي لوصف عمليات الأعمال، يسمح بتصور تدفقات العمل والأحداث والبوابات والمجموعات.
  • MBSE (Model-Based Systems Engineering) — نهج لهندسة النظم حيث يكون النموذج هو المخرج المركزي في جميع مراحل دورة حياة النظام، من المتطلبات إلى الاختبار.
  • ArchiMate — ترميز لبنية المؤسسة (الأعمال، التطبيقات، التقنيات) وعلاقاتها.
  • DMN (Decision Model and Notation) — نمذجة قرارات الأعمال وجداول القواعد.
  • DFD (Data Flow Diagram) — مخططات تدفق البيانات (السياق، مستويات التفكيك).
  • ERD (Entity-Relationship Diagram) — نموذج لمجال العمل مع الكيانات والعلاقات والسمات.
  • مصفوفة CRUD — مطابقة عمليات الإنشاء/القراءة/التحديث/الحذف (Create/Read/Update/Delete) مع الكيانات والأدوار/الوظائف.

الأساليب المعمارية وتقييم الحلول

  • البنية المتجانسة (Monolithic architecture) — نهج معماري يتم فيه تطوير النظام بأكمله كوحدة واحدة غير قابلة للتجزئة.
  • بنية الخدمات المصغرة (Microservice architecture) — نهج معماري يتم فيه بناء النظام كمجموعة من الخدمات الصغيرة القابلة للنشر والتوسع بشكل مستقل.
  • Trade-off (المفاضلة) — الاختيار بين خصائص أو حلول متعارضة أو متنافية، حيث يحدث تحسين إحدى الخصائص على حساب تدهور الأخرى.
  • ATAM (Architecture Tradeoff Analysis Method) — طريقة لتقييم بنية البرمجيات، تُستخدم لتحليل المفاضلات بين سمات الجودة (مثل الأداء وقابلية التوسع).

بنية المؤسسة وأطر العمل

  • TOGAF (The Open Group Architecture Framework) — أحد أكثر أطر عمل بنية المؤسسات شيوعًا، يتضمن طريقة ADM (Architecture Development Method) لتطوير وإدارة البنية.
  • Zachman Framework — أنطولوجيا لمخرجات بنية المؤسسة، مقدمة كمصفوفة 6×6، تصنف جوانب مختلفة من البنية من وجهات نظر مختلفة.

مناهج التحليل وعمليات التطوير

  • النهج الصلب (Hard Systems) — منهجية تحليل النظم التي تفترض أهدافًا ومتطلبات قابلة للصياغة الرسمية مسبقًا، والتفكيك والتصميم «من أعلى إلى أسفل»، وتكون فعالة للمهام المحددة بوضوح.
  • النهج الناعم (Soft Systems) — منهجية تحليل النظم التي تُطبق عندما تكون الأهداف غير واضحة وتوجد وجهات نظر متعددة لأصحاب المصلحة، وتهدف إلى تنسيق فهم المشكلة والتغييرات المرغوبة.
  • SSM (Soft Systems Methodology) — منهجية محددة للنهج الناعم لتحليل النظم، طورها بيتر تشيكلاند، وتستخدم أدوات مثل rich picture، والتعريفات الجذرية، وCATWOE.
  • Waterfall (النموذج الشلالي) — منهجية تطوير برمجيات كلاسيكية، حيث يتم تنفيذ المراحل (التحليل، التصميم، التنفيذ، الاختبار، النشر) بشكل تسلسلي، مع اكتمال المرحلة السابقة بالكامل قبل بدء المرحلة التالية.
  • Agile — مجموعة من منهجيات تطوير البرمجيات المرنة، تركز على التطوير التكراري، والتكيف مع التغييرات، والتفاعل مع العميل، والتسليم المستمر للقيمة.

أساليب الاختيار والأخطاء الشائعة

  • AHP (Analytic Hierarchy Process) — طريقة اختيار متعددة المعايير، تسمح بهيكلة المشكلات المعقدة وتقييم البدائل على أساس تسلسل هرمي للمعايير.
  • Gold-plating (متلازمة «الطلاء بالذهب») — خطأ في تحليل النظم يتمثل في إضافة وظائف لا يطلبها أصحاب المصلحة، مما يؤدي إلى زيادة حجم وتعقيد المشروع.

روابط

مراجع

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 5-е изд.
  • ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
  • IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
  • The Open Group (2022). The TOGAF® Standard, 10th Edition. نسخة مجانية رسمية.
  • OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
  • OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
  • OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
  • The Open Group (2022). ArchiMate® 3.2 Specification. تحميل مجاني رسمي (بموجب ترخيص).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4-е изд.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3-е изд.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2-е изд.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (rev. ed.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5-е изд.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3-е изд.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, 4-е изд.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11-е изд.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8-е изд.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7-е изд.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3-е изд.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2-е изд.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4-е изд.
  • Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
  • Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
  • Keeling, M. (2017). Design It!: From Programmer to Software Architect.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
  • Vernon, V. (2013). Implementing Domain-Driven Design.
  • Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
  • Simsion, G.; Witt, G. (2015). Data Modeling Essentials, 4-е изд.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (rev. eds.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2-е изд.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

ملاحظات

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 IEEE Computer Society (2025). Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
  2. ↑ Zowghi, D.; Coulin, C. (2005/2014). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. https://eecs481.org/readings/requirements.pdf
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 ISO/IEC/IEEE 29148 (2011/2018). Systems and software engineering — Requirements engineering. ISO overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html
  4. ↑ 4.0 4.1 4.2 NASA (2020). NPR 7123.1C — Systems Engineering Processes and Requirements. Определение «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all
  5. ↑ GMU (George Mason University). IEEE Software Requirements Specification Template (SRS). https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc
  6. ↑ Westfall, L. (Cal Poly, .edu). The What, Why, Who, When and How of Software Requirements (упоминает URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf
  7. ↑ Stanford University IT (.edu). Functional Specification Document Template. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx
  8. ↑ Penn State (.edu). Elements of a Use Case Diagram. https://www.e-education.psu.edu/geog468/l8_p4.html
  9. ↑ UC Irvine (.edu). Data Flow Diagram. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/
  10. ↑ ISO/IEC/IEEE 42010 (2011/2022). Architecture description — требования к описанию архитектуры и точкам зрения. https://standards.ieee.org/ieee/42010/5334/
  11. ↑ Cornell University (.edu). CS 5150 — Feasibility Studies. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf
  12. ↑ Carnegie Mellon SEI. Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  13. ↑ Microsoft Azure Architecture Center. Architecture styles: microservices — benefits & complexity. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  14. ↑ Google Cloud. What Is Microservices Architecture? — Monolithic vs. microservices (обзор). https://cloud.google.com/learn/what-is-microservices-architecture
  15. ↑ NASA (2023). Requirements Management — Traceability, Bidirectional traceability (definitions). https://www.nasa.gov/reference/6-2-requirements-management/
  16. ↑ McKinsey (2012). Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  17. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM) — CATWOE, 3Es. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  18. ↑ Lancaster University (ePrints). Soft Systems Methodology and root definitions. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf
  19. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM). https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  20. ↑ UCL Discovery (.ac.uk). M. Haklay. Soft System Methodology (SSM). https://discovery.ucl.ac.uk/1296/1/paper13.pdf
  21. ↑ IEEE Std 1320.1-1998 (R2004). Functional Modeling Language — Syntax and Semantics for IDEF0. https://standards.ieee.org/ieee/1320.1/2003/
  22. ↑ ISO/IEC/IEEE 31320-1:2012. IDEF0: Function Modeling. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf
  23. ↑ University of Washington (.edu). UML Class Diagrams / UML overview (course material). https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf
  24. ↑ JHU/APL (.edu). Modeling with SysML — tutorial. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  25. ↑ MIT OCW (.edu). O. de Weck. Introduction to Systems Modeling Languages (incl. SysML, MBSE). https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf
  26. ↑ IBM. What is Business Process Modeling and Notation (BPMN)?. https://www.ibm.com/think/topics/bpmn
  27. ↑ IBM Docs. Business Process Modeling Notation (BPMN) model. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model
  28. ↑ IEEE/ISO/IEC 29148:2018. Systems and software engineering — Requirements engineering (overview). https://standards.ieee.org/ieee/29148/6937/
  29. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  30. ↑ T. L. Saaty. How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19
  31. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  32. ↑ MIT OCW (.edu). V-Model — Fundamentals of Systems Engineering. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/
  33. ↑ Carnegie Mellon SEI (.edu). Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  34. ↑ Microsoft Azure Architecture Center. Architecture styles. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  35. ↑ Kazman, R.; Klein, M.; Clements, P. ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf
  36. ↑ 36.0 36.1 36.2 36.3 The Open Group. Introduction — The TOGAF® Standard. https://www.togaf.org/chap01.html
  37. ↑ Microsoft Azure Architecture Center. Event-Driven Architecture style. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  38. ↑ Jonkers, H. et al. ArchiMate® and the TOGAF® Framework. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf
  39. ↑ Estrem, W. Building Blocks Revisited. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf
  40. ↑ The Open Group. Architecture Principles. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf
  41. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  42. ↑ The TOGAF® Standard, Version 9.2 (спецификация). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf
  43. ↑ Engelsman, W.; van Sinderen, M. Supporting Requirements Management in TOGAF and ArchiMate. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf
  44. ↑ Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276
  45. ↑ MIT CISR. Classic Topics — Enterprise Architecture (определение EA как «organizing logic for business process and IT capabilities…»). https://cisr.mit.edu/content/classic-topics-enterprise-architecture
  46. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  47. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON. Репринт (PDF): https://www.praxisframework.org/files/royce1970.pdf
  48. ↑ Defense Acquisition University. System Requirements Review (SRR) — Acquipedia. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/
  49. ↑ NASA (2023). Requirements Management — baseline, change control (CCB). https://www.nasa.gov/reference/6-2-requirements-management/
  50. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  51. ↑ MSDN Magazine (Microsoft). BDD Primer: Behavior‑Driven Development with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin
  52. ↑ Microsoft Learn. End‑to‑end traceability in Azure DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability
  53. ↑ Google SRE. Service Level Objectives; Error Budget Policy. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/
  54. ↑ Microsoft Learn. Azure Monitor — Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
  55. ↑ AWS Whitepaper. Blue/Green Deployments on AWS. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html
  56. ↑ Microsoft Learn. Manage change — track, triage, and implement change requests. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change
  57. ↑ Microsoft Learn (Azure Boards). Backlogs overview — create and manage your product backlog. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview
  58. ↑ Microsoft Learn (Azure Test Plans). What is Azure Test Plans?. https://learn.microsoft.com/en-us/azure/devops/test/overview
  59. ↑ MSDN Magazine. Behavior‑Driven Design with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow
  60. ↑ IBM. MTTR vs. MTBF: What’s the difference?. https://www.ibm.com/think/topics/mttr-vs-mtbf
  61. ↑ Google Cloud. Google Cloud Observability. https://cloud.google.com/products/observability
  62. ↑ IEEE Std 830‑1998. IEEE Recommended Practice for Software Requirements Specifications (исторический стандарт). Учебная копия (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  63. ↑ 63.0 63.1 63.2 63.3 NASA. Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2). https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  64. ↑ 64.0 64.1 NASA (2023). Requirements Management — traceability, baseline, CCB. https://www.nasa.gov/reference/6-2-requirements-management/
  65. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  66. ↑ Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19
  67. ↑ SEI / CMMI Institute. Capability Maturity Model Integration (CMMI) — Overview. https://www.sei.cmu.edu/cmmi/
  68. ↑ NASA Langley. What is Formal Methods?; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf
  69. ↑ 69.0 69.1 SEI (CMU). Common Testing Problems: Pitfalls to Prevent and Mitigate (о типичных проблемах требований/трассируемости). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/
  70. ↑ 70.0 70.1 70.2 70.3 70.4 70.5 70.6 70.7 NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
  71. ↑ 71.0 71.1 71.2 71.3 71.4 71.5 U.S. DoD CIO (2021). DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf
  72. ↑ Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н).
Retrieved from "https://systems-analysis.ru/int/index.php?title=Systems_analysis_in_IT_—_تحليل_النظم_في_تقنية_المعلومات&oldid=9058"