مهندس أنظمة

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

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

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

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

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

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

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

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

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

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

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

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

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

يُعد اختبار القبول مسؤولية رئيسية لمهندس النظم. وهو الوسيلة الأساسية التي يثبت بها قائد البرنامج للمستخدمين أن النظام يعمل وفقًا للخطة الأصلية وأن جميع المهندسين المعماريين والمهندسين المعنيين قد حققوا أهدافهم.

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