مهندس برمجيات

مهندس البرمجيات هو مهندس برمجيات مسؤول عن خيارات التصميم عالية المستوى المتعلقة ببنية النظام وسلوكه بشكل عام. ^{[ 1 ]}

تقع على عاتق مهندس البرمجيات مسؤولية مطابقة الخصائص المعمارية (المعروفة أيضًا بالمتطلبات غير الوظيفية ) مع متطلبات العمل. على سبيل المثال: ^{[ 2 ]}

• يتطلب تحقيق رضا العملاء العالي التوافر، وتحمل الأعطال ، والأمان، وقابلية الاختبار، وقابلية الاسترداد، والمرونة، والأداء في النظام.
• يتطلب القيام بعمليات الاندماج والاستحواذ (M&A) قابلية التوسع ، وقابلية التكيف، وقابلية التشغيل البيني.
• يتطلب ضيق الميزانية والوقت مراعاة الجدوى والبساطة.
• يتطلب الوصول إلى السوق بشكل أسرع إمكانية الصيانة والاختبار والنشر.

يتعامل تصميم البرمجيات، وبالتالي مهندسو البرمجيات، بطبيعتهم مع حالات عدم اليقين. ومن مهام مهندس البرمجيات تحديد حجم مكونات التصميم، الذي قد يؤثر بشكل كبير على نتائج النظام، إيجابًا وسلبًا. يقترح نيل فورد ومارك ريتشاردز منهجًا تكراريًا لمواجهة تحدي تحديد المكونات وتحديد حجمها الأمثل. يركز هذا المنهج على التحسين المستمر مع تطور فهم الفرق لسلوك النظام ومتطلباته بشكل أدق. ^{[ 2 ]}

يتضمن هذا النهج عادةً دورة تتكون من عدة مراحل: ^{[ 2 ]}

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

تُشكل هذه الدورة إطاراً عاماً ويمكن تكييفها مع مجالات مختلفة.

قد تنشأ الأنماط المعمارية السلبية التالية عندما يتخذ المعماريون قراراتهم. غالباً ما تتبع هذه الأنماط السلبية تسلسلاً تصاعدياً، حيث قد يؤدي حل أحدها إلى ظهور نمط آخر. ^{[ 2 ]}

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

• هندسة البرمجيات
• هندسة البرمجيات
• قائمة أنماط وأساليب هندسة البرمجيات

• الرابطة الدولية لمهندسي البرمجيات (IASA)