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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:

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

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

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

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

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

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