يشكّل معيارا اعتماد البرمجيات DO-178B وDO-178C دليلًا لإنتاج أنظمة جوية صالحة للطيران. وقد كان معيار DO-178B (Software Considerations in Airborne Systems and Equipment Certification)، الصادر لأول مرة عام 1992، وثيقة مهمة يُستند إليها للحصول على الاعتماد اللازم من جهات تجارية مثل وكالة الاتحاد الأوروبي لسلامة الطيران (EASA) وإدارة الطيران الفيدرالية (FAA) للأنظمة الجوية القائمة على البرمجيات. غير أن لوائح الطيران الفيدرالية اعتمدت DO-178C عام 2013 وسيلةً لإثبات المطابقة لمتطلبات صلاحية الطيران. وللمزيد من المعلومات العامة حول معياري DO-178B وDO-178C، يمكنكم قراءة هذا المقال.
يجب استيفاء معايير DO-178B أو DO178C من خلال الوثائق النموذجية التالية وغيرها.
- PSAC (Plan for Software Aspects of Certification)
- SDP (Software Development Plan)
- SVP (Software Verification Plan)
- SCMP (Software Configuration Management Plan)
- SQAP (Software Quality Assurance Plan)
- SAS (Software Accomplishment Summary)
ولا تقتصر الوثائق اللازمة لاستيفاء معياري DO-178B وDO-178C على ما سبق؛ فهناك وثائق أخرى عديدة تعزز صلاحية الطيران. يمكنكم الاطلاع على هذه الوثائق وشراؤها من هنا.
وثائق DO178
وثيقة PSAC
توضح وثيقة PSAC (Plan for Software Aspects of Certification)، إضافة إلى إنتاج بيانات دورة الحياة، المعايير والعمليات والبروتوكولات والمنهجيات اللازمة الواجب اتباعها. وبذلك يمكن استيفاء معايير DO-178. كما تحدد PSAC الجدول الزمني لتطوير البرمجيات والحالة العامة للنظام. ويستفيد من هذه الوثيقة كل من الجهة المعتمِدة وطالب الاعتماد. ويجب إعداد PSAC خلال عملية التخطيط الأولي للبرمجيات واعتمادها من جهة الاعتماد. يُرجى النقر هنا للاطلاع على وثيقة PSAC لدينا.
وثيقة SDP
تهدف وثيقة SDP (Software Development Plan) إلى التحقق من تحديد المعلومات اللازمة كإجراءات التطوير والبروتوكولات والمعايير ودورات الحياة وبيئة التطوير. وتُعد وثيقة SDP جزءًا مهمًا من عملية تخطيط البرمجيات. يُرجى النقر هنا للاطلاع على وثيقة SDP لدينا.
وثيقة SVP
تحدد وثيقة SVP (Software Verification Plan) سيناريوهات الاختبار المطلوبة ونطاق التغطية والإجراءات والبروتوكولات والتحقق من المتطلبات والتحقق من الشيفرة المصدرية، مع توفير ضبط ملائم للإصدارات. وتُعد SVP أيضًا جزءًا مهمًا من عملية التخطيط. يُرجى النقر هنا للاطلاع على وثيقة SVP لدينا.
وثيقة SCMP
وثيقة SCMP (Software Configuration Management Plan) عنصر مهم آخر من عناصر عملية التخطيط. فالخطة الأولية المعدّة على امتداد عملية تطوير البرمجيات كثيرًا ما تطرأ عليها تغييرات، وتساعدنا SCMP على اكتشاف هذه التغييرات وضبطها وصيانتها وتتبعها. وتُطبَّق على امتداد عملية تطوير البرمجيات، وتهدف إلى تقليل الأخطاء إلى أدنى حد ورفع الكفاءة إلى أقصاها. وعلى أعضاء الفريق الحرص على الإبلاغ عن التغييرات وإخطار بعضهم بعضًا بها. يُرجى النقر هنا للاطلاع على وثيقة SCMP لدينا.
وثيقة SQAP
تتضمن وثيقة SQAP (Software Quality Assurance Plan) الأدوات والأساليب والتقنيات المستخدمة لضمان مطابقة المنتج أو الخدمة للمواصفات الواردة في وثيقة متطلبات البرمجيات (SRS). وتشرح SQAP كيفية تنفيذ أنشطة ضمان جودة البرمجيات في المشروع. ويضع فريق SQA محطات رئيسية ويقيّم جودة المشروع عند كل محطة. ويُنفَّذ ضمان الجودة على امتداد دورة حياة البرمجيات. يُرجى النقر هنا للاطلاع على وثيقة SQAP لدينا
وثيقة SAS
تلخّص وثيقة SAS (Software Accomplishment Summary) كل خطوة من خطوات مكونات البرمجيات خلال عمليتي التطوير والتحقق. وينبغي أن تتضمن SAS ملخصًا لنتائج تأهيل أدوات التحقق، وأن تُبلَّغ FAA بها. ويوفر ذلك لجهة الاعتماد إثباتًا لنتائج بيانات التحقق، ودليلًا على حالة تأهيل الأداة. يُرجى النقر هنا للاطلاع على وثيقة SAS لدينا
معايير ARP4754 ومعايير DO178
يشير ARP4754 إلى «Aerospace Recommended Practice ARP4754A Guidelines for Development of Civil Aircraft and Systems». وتوفر معايير ARP4754 إرشادات لأنظمة الطائرات في مجملها، بينما تُستخدم معايير DO178 لبرمجيات الطيران فقط. وكلا المعيارين مقبول لدى جهات مثل FAA وEASA.
وقد طوّرت جمعية مهندسي السيارات (SAE) معيار ARP4754 ونشرته عام 1996. وفي عام 2010، نشرت SAE معيار ARP4754A، الذي يشير إلى Guidelines for Development of Civil Aircraft and Systems. ويثري ARP4754A مفهوم ضمان التصميم المستخدم على مستويي الطائرة والنظام، كما يوحّد استخدام مصطلح ضمان التطوير. وقد اعتمدت FAA معيار ARP4754 في نوفمبر 2011.
يغطي ARP4754 دورة تطوير الطائرة بأكملها، من تحديد المتطلبات حتى نهاية عمليتي التكامل والتحقق. ويوفر المعيار تجريدًا للطائرات والأنظمة والمكونات. أما في تصميم المكونات، فيحيل صراحةً إلى DO-178 وDO-254. ويركّز ARP4754 على تقييم السلامة عبر عمليات مختلفة كالتطوير والتصميم والتحقق. غير أنه تجدر الإشارة إلى أنه لا يشمل النطاق الخاص بتطوير البرمجيات أو العتاد الإلكتروني، ولا أنشطة السلامة أثناء الخدمة، ولا عملية تطوير هيكل الطائرة.
مراحل التصميم
المراجعة الأولية للتصميم (PDR)
التصميم الأولي مرحلة مهمة من مراحل عملية تطوير البرمجيات. فخلاله تُحدد المتطلبات عالية المستوى وحالات الاستخدام لتشكيل معمارية النظام. ويمكن الاستعانة في التصميم بوثائق الواجهات وقواعد البيانات والمعمارية، وبمخططات علاقات المكونات. ويوفر التصميم الأولي تصويرًا مرئيًا للنظام في بداية المشروع استنادًا إلى هذه المدخلات، كما يمهّد لمراحل التصميم الأكثر تفصيلًا اللاحقة، ويمكن اعتباره مسودة.
وتُختتم مرحلة التصميم الأولي للمشروع بإجراء المراجعة الأولية للتصميم (PDR). ويجب أن توفر PDR ضمانًا كافيًا للمضي في التصميم التفصيلي. وتهدف إلى التأكد من اكتمال التصميم الأولي والمعمارية الأساسية للنظام، ومن توفر الثقة الفنية بإمكانية استيفاء المتطلبات ضمن الميزانية والجدول الزمني.
المراجعة الحرجة للتصميم (CDR)
تُختتم مرحلة التصميم الحرج للمشروع بإجراء المراجعة الحرجة للتصميم (CDR). وتُعرض التصاميم النهائية خلالها عبر تحليلات شاملة وعمليات محاكاة ومخططات وشيفرات برمجية وبيانات اختبار. وتضمن CDR إمكانية انتقال النظام إلى الاختبار والإنتاج، كما تقرر إمكانية استيفاء المتطلبات المعنية ضمن الميزانية والجدول الزمني. وتوفر الرسومات والمواصفات الشاملة الناتجة خط أساس نهائيًا إلى جانب خط أساس أولي للمنتج. ويجب أن تكون CDR واسعة النطاق ومفصّلة.
مرحلة التصميم النهائي
توفر مرحلة التصميم النهائي رسومات معمارية وهندسية مفصّلة لكل مكوّن في المشروع. وقد يلزم في بعض المشاريع إعداد تقرير تصميم نهائي. ويجب حل مشكلات التصميم المحددة قبل إتمام هذه المرحلة. كما يجب أن توفر الرسومات والتقارير تفاصيل كافية لإتاحة التقديرات المخططة. وينبغي أن يتضمن تقرير التصميم النهائي جدولًا زمنيًا محدّثًا وتقديرات الكلفة والمواصفات، وأن يُتأكد أيضًا من الجدوى الاقتصادية للمشروع. وأي تغييرات تُجرى خلال مرحلة التصميم النهائي أعلى كلفة مقارنة بالمراحل الأخرى، ولذلك يجب تنفيذها بعناية بالغة.
SOI (Stages of Involvement)
لتقييم امتثال المشاريع لمعيار DO-178B، تُجري هيئات الطيران في الدول المعنية تقييمات SOI في مراحل مختلفة من المشروع، كالتخطيط والتطوير والتحقق. ويُخطط في الوضع الأمثل لأربع مراجعات SOI.
يغطي تقييم SOI الأول مرحلة التخطيط لأعمال المطابقة الخاصة باعتماد المشروع. وتركّز مراجعة SOI الثانية على مراحل تطوير المشروع؛ فبدءًا من تطوير متطلبات البرمجيات عالية المستوى، تفحص ما إذا كان التصميم ومتطلبات البرمجيات منخفضة المستوى والشيفرة المصدرية قد أُنتجت وفق DO178B. وتركّز مراجعة SOI الثالثة على مراحل التحقق، إذ تُراجَع جميع الأنشطة المنفذة لأغراض التحقق وليس أنشطة الاختبار وحدها. أما SOI الرابعة فهي تقييم الإغلاق الذي يُجرى قرب نهاية المشروع، ويفحص ما إذا كانت هناك أنشطة معلقة وما إذا كانت مشكلات جديدة قد ظهرت منذ التقييمات السابقة.
وما يتوقعه معيار DO-178B من منتجات البرمجيات المعدّة في مرحلة التخطيط هو الاتفاق على مجموعة قواعد مشتركة بين الجهة الرقابية والشركة المنفذة، والالتزام بهذه القواعد طوال المشروع. وبعبارة أخرى، فإن الشركة عند صياغة الخطط والمعايير لا تحدد عملياتها الخاصة فحسب، بل تكتب أيضًا القواعد التي ستقيّمها بها الجهة الرقابية على امتداد عملية الاعتماد.
الكاتب: Can Önal ([email protected])
