تعتمد عملية تطوير البرامج الثابتة لدينا على نهج مكون من خمس خطوات

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

الخطوة 1: تحديد المتطلبات

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

إن قابلية الاختبار هي عامل أساسي؛ فالمتطلب المكتوب جيدًا يجب أن يسمح بإنشاء اختبار مباشر للتحقق من استيفائه. تتكون المجموعة المناسبة من المتطلبات من عبارات تبدأ بـ "يجب أن يكون [المنتج] ..."، مع التركيز على ما هو مطلوب وليس كيفية تحقيقه، وضمان الوضوح وقابلية الاختبار. وبالتالي، تعتمد الهندسة المعمارية الفعّالة على متطلبات محددة جيدًا.

الخطوة 2: التمييز بين الهندسة المعمارية والتصميم

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

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

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

الخطوة 3: إدارة الوقت

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

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

الخطوة 4: التصميم مع وضع الاختبار في الاعتبار

من الضروري اختبار كل نظام مضمن على مستويات متعددة. وفي كثير من الحالات، لا يكون الاختبار على مستويات مختلفة مفيدًا فحسب، بل إنه إلزامي أيضًا.

تشمل المستويات الأكثر شيوعًا للاختبار ما يلي

:

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

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

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

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

الخطوة 5: الاستعداد للتغيير

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