3.9 هندسة الأنظمة

نظرة عامة والدافع

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

هذا مختلف عن عمارة البرمجيات. تقرر عمارة البرمجيات (الفصل 3.1) كيف تُهيكَل مكونات البرمجيات وكيف تتحدث مع بعضها. تجلس هندسة الأنظمة مستوى أعلى. تسأل ماذا يجب أن يفعل النظام ككل، وكيف تقسّم البرمجيات والعتاد والمشغّلون البشريون العمل، وكيف ستثبت أن الشيء المُنجَز يعمل. موطنها المهني INCOSE، المجلس الدولي لهندسة الأنظمة، ومعيارها المرجعي ISO/IEC/IEEE 15288، الذي يحدد عمليات عمر النظام.

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

يرتبط هذا الفصل بمتطلبات البرمجيات (الفصل 2.8)، وأساسيات العمارة (الفصل 3.1)، ونماذج البرمجيات وأساليبها (الفصل 2.12)، والتشغيل البيني والمعايير المفتوحة (الفصل 3.8)، وإدارة المشروع (الفصل 10.6).

المبادئ الأساسية

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

التوصيات

أدر دورة حياة النظام الكاملة

عامل النظام كأن له عمرًا كاملًا، وخطط لكل مرحلة. تسير دورة حياة شائعة: المفهوم (فهم الحاجة واستكشاف الخيارات)، والمتطلبات (ذكر بدقة ماذا يجب أن يفعل النظام)، والتصميم (تقرير العمارة والأجزاء)، والتكامل (جمع الأجزاء معًا)، والتحقق والتحقق من الصحة (إثبات أنه يعمل وأنه النظام الصحيح)، والتشغيل (تشغيله وصيانته)، والتقاعد (إيقاف تشغيله بأمان، بما يشمل البيانات والتخلص). يمنحك ISO/IEC/IEEE 15288 إطار عملية لهذا. لا يجب أن تكون المراحل شلالًا صارمًا؛ تستطيع التكرار والنمذجة الأولية والتسليم بزيادات. الهدف هو أنك تعالج كل مرحلة بوعي، بما يشمل المراحل المتأخرة المكلفة التي غالبًا تتجاهلها الخطط المبكرة.

التقط احتياجات أصحاب المصلحة وخصّص المتطلبات بقابلية تتبع

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

أدر الواجهات صراحة

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

كامِل ثم تحقق وتحقق من الصحة

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

تبنَّ هندسة الأنظمة القائمة على النماذج

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

طبّق التفكير النظمي على السلوك الناشئ

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

اهندس العتاد والبرمجيات معًا

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

المفاضلات: الإيجابيات والسلبيات

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

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

أسئلة للنقاش مع فريقك

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

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

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

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

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

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

المنظور القطاعي

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

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

المؤسسة الكبرى. على نطاق واسع المشكلة هي الاتساق عبر فرق وموردين كثيرين: عملية دورة حياة مشتركة موائمة لـISO/IEC/IEEE 15288، ووثيقة ضبط واجهة ومالك مسمى لكل حد مورّد، وقابلية تتبع من طرف إلى طرف بحيث لا يطلق تغيير مكون واحد هرولة على مستوى البرنامج. استثمر في MBSE حيث يبقي نموذج مشترك المتطلبات والواجهات والاختبارات متوائمة عبر المتعاقدين. احكم العملية بحيث يبقى التحقق والتحقق من الصحة متمايزين ويُخصَّص كل متطلب لجزء مسؤول.

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

أمثلة

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

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

الحكومة. تحدّث هيئة ملاحة جوية وطنية نظام إدارة مرور جوي، نظام أنظمة حرج للسلامة يمتد عبر رادارات، ومحطات عمل مراقبين، واتصالات، وبرمجيات، يعمل على مدار الساعة. يتبع البرنامج ISO/IEC/IEEE 15288 عبر دورة الحياة الكاملة. يثبت التحقق أن كل نظام فرعي يلبي مواصفته، ويثبت التحقق من الصحة عبر محاكاة مع مراقبين حقيقيين أن النظام المتكامل يدعم عمليات آمنة قبل أن تعتمد عليه أي حركة مرور حية. يتيح V&V الصارم للهيئة التحويل على مراحل، بخيار احتياطي عند كل خطوة، لأن هنا فشلًا ناشئًا غير مختبَر حدث سلامة عامة.

حالة العمل: الدوافع والعائد على الاستثمار وتكلفة الملكية الإجمالية

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

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

الأنماط المضادة والمزالق

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

نموذج النضج

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

المستوى 2: التطوير. توجد ممارسات أساسية على البرامج الكبرى. تُلتقَط المتطلبات ويُحدَّد خط أساسها، وتحمل الواجهات الرئيسية وثائق ضبط، وتوجد خطة تحقق. الممارسة غير متسقة بين الفرق وتعتمد على أفراد لا طريقة مشتركة.

المستوى 3: التوحيد القياسي. هندسة الأنظمة انضباط موثق على نطاق المؤسسة موائم لـISO/IEC/IEEE 15288 ومفروض عبر الفرق. تُخطَّط دورة الحياة الكاملة، تُصان قابلية التتبع من طرف إلى طرف، تُضبَط الواجهات رسميًا، والتحقق والتحقق من الصحة متمايزان ومخططان. تُستخدَم MBSE على البرامج المعقدة.

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

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

أفكار للنقاش

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

النقاط الرئيسية

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

المراجع والقراءات الإضافية

• INCOSE, INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
• ISO/IEC/IEEE 15288, Systems and Software Engineering: System Life Cycle Processes
• ISO/IEC/IEEE 29148, Systems and Software Engineering: Requirements Engineering
• Sanford Friedenthal, Alan Moore, and Rick Steiner, A Practical Guide to SysML: The Systems Modeling Language
• NASA, NASA Systems Engineering Handbook (NASA/SP-2016-6105)
• Andrew P. Sage and William B. Rouse, Handbook of Systems Engineering and Management
• Dennis M. Buede and William D. Miller, The Engineering Design of Systems: Models and Methods
• Donella H. Meadows, Thinking in Systems: A Primer
• Eberhardt Rechtin and Mark W. Maier, The Art of Systems Architecting
• U.S. Department of Defense, Defense Acquisition Guidebook (systems engineering guidance)