Lewati ke konten utama
← Semua Artikel
Suar Darurat

Standar DO178 dan Dokumen DO178, Standar ARP4754, Tahapan Desain, dan SOI

Pharus Tech
Standar DO178 dan Dokumen DO178, Standar ARP4754, Tahapan Desain, dan SOI

DO-178B dan DO-178C standar sertifikasi perangkat lunak menjadi panduan untuk memproduksi sistem udara yang laik terbang. Pertama kali diterbitkan pada tahun 1992, DO-178B (Software Considerations in Airborne Systems and Equipment Certification) merupakan dokumen penting yang dipertimbangkan untuk memperoleh sertifikasi yang diperlukan dari otoritas komersial seperti EASA (European Union Aviation Safety Agency) dan FAA (Federal Aviation Administration) untuk sistem udara berbasis perangkat lunak. Namun, Federal Aviation Regulations menerima DO-178C sebagai metode untuk menunjukkan kepatuhan kelaikan udara pada tahun 2013. Untuk informasi umum lebih lanjut mengenai standar DO-178B dan DO-178C, Anda dapat membaca artikel ini.

Standar DO-178B atau DO178C harus dipenuhi oleh dokumen-dokumen contoh berikut dan lainnya.

  • 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)

Dokumen yang diperlukan untuk memenuhi standar DO-178B dan DO-178C tidak terbatas pada dokumen-dokumen ini saja. Terdapat banyak dokumen lain yang akan memperkaya kelaikan udara. Anda dapat memeriksa dan membeli dokumen-dokumen ini di sini.

Dokumen DO178

Dokumen PSAC

Dokumen PSAC (Plan for Software Aspects of Certification), selain menghasilkan data siklus hidup, juga menjelaskan standar, proses, protokol, dan metodologi yang perlu diikuti. Dengan demikian, standar DO-178 dapat dipenuhi. PSAC juga menetapkan jadwal pengembangan perangkat lunak dan status sistem secara keseluruhan. Baik otoritas yang menyetujui maupun pemohon sama-sama mendapatkan manfaat dari dokumen ini. PSAC harus disusun selama proses perencanaan perangkat lunak awal dan disetujui oleh otoritas sertifikasi. Silakan klik di sini untuk memeriksa dokumen PSAC kami.

Dokumen SDP

Dokumen SDP (Software Development Plan) bertujuan untuk memeriksa apakah informasi yang diperlukan seperti prosedur pengembangan, protokol, standar, siklus hidup, dan lingkungan pengembangan telah ditentukan. Dokumen SDP merupakan bagian penting dari proses perencanaan perangkat lunak. Silakan klik di sini untuk memeriksa dokumen SDP kami.

Dokumen SVP

Dokumen SVP (Software Verification Plan) menetapkan skenario dan cakupan pengujian, prosedur, protokol, verifikasi persyaratan, dan verifikasi kode sumber yang diperlukan, sekaligus menyediakan kontrol versi yang sesuai. SVP juga merupakan bagian penting dari proses perencanaan. Silakan klik di sini untuk memeriksa dokumen SVP kami.

Dokumen SCMP

Dokumen SCMP (Software Configuration Management Plan) merupakan elemen penting lain dalam proses perencanaan. Rencana awal yang disusun sepanjang proses pengembangan perangkat lunak sering mengalami perubahan. SCMP membantu kita mendeteksi, mengendalikan, memelihara, dan melacak perubahan-perubahan ini. SCMP diterapkan sepanjang proses pengembangan perangkat lunak. SCMP bertujuan meminimalkan kesalahan dan memaksimalkan efisiensi. Anggota tim harus berupaya melaporkan dan saling memberi tahu mengenai perubahan yang terjadi. Silakan klik di sini untuk memeriksa dokumen SCMP kami.

Dokumen SQAP

Dokumen SQAP (Software Quality Assurance Plan) berisi alat, metode, dan teknik yang digunakan untuk memastikan bahwa suatu produk atau layanan memenuhi spesifikasi yang tercantum dalam SRS (Software Requirement Specification). SQAP menjelaskan bagaimana Aktivitas Jaminan Mutu Perangkat Lunak akan dilaksanakan dalam proyek. Tim SQA menetapkan milestone dan mengevaluasi mutu proyek pada setiap milestone. SQA dilaksanakan sepanjang siklus hidup perangkat lunak. Silakan klik di sini untuk memeriksa dokumen SQAP kami

Dokumen SAS

SAS (Software Accomplishment Summary) merangkum setiap tahapan komponen perangkat lunak selama proses pengembangan dan verifikasi. SAS harus mencakup ringkasan temuan dari kualifikasi alat verifikasi. FAA harus diberi tahu mengenai SAS. Dokumen ini memberikan validasi terhadap temuan data verifikasi kepada otoritas sertifikasi dan berfungsi sebagai bukti status kualifikasi alat tersebut. Silakan klik di sini untuk memeriksa dokumen SAS kami

Standar ARP4754 dan Standar DO178

ARP4754 merupakan singkatan dari "Aerospace Recommended Practice ARP4754A Guidelines for Development of Civil Aircraft and Systems". Standar ARP4754 menyediakan panduan untuk sistem pesawat udara secara keseluruhan, sementara Standar DO178 hanya digunakan untuk perangkat lunak penerbangan. Kedua standar ini diterima oleh otoritas seperti FAA dan EASA.

ARP4754 dikembangkan dan diterbitkan oleh SAE (Society of Automotive Engineers) pada tahun 1996. Pada tahun 2010, SAE menerbitkan ARP4754A, yang merupakan singkatan dari Guidelines for Development of Civil Aircraft and Systems. ARP4754A memperkaya konsep design assurance yang digunakan pada tingkat pesawat udara dan sistem, sekaligus menstandardisasi penggunaan istilah development assurance. ARP4754 disetujui oleh FAA pada November 2011.

ARP4754 mencakup keseluruhan siklus pengembangan pesawat udara, mulai dari identifikasi persyaratan hingga akhir proses integrasi dan verifikasi. ARP4754 menyediakan abstraksi untuk pesawat udara, sistem, dan komponen. Untuk desain komponen, ARP4754 secara eksplisit merujuk pada DO-178 dan DO-254. ARP4754 berfokus pada penilaian keselamatan melalui berbagai proses seperti pengembangan, desain, dan verifikasi. Namun, perlu dicatat bahwa ARP4754 tidak mencakup lingkup spesifik pengembangan perangkat lunak atau perangkat keras elektronik, aktivitas keselamatan selama masa layanan (in-service), dan proses pengembangan struktur pesawat udara.

Tahapan Desain

Preliminary Design Review (PDR)

Preliminary design merupakan tahap penting dalam proses pengembangan perangkat lunak. Selama preliminary design, persyaratan tingkat tinggi dan use case diidentifikasi untuk membentuk arsitektur sistem. Dokumen untuk antarmuka, basis data, dan arsitektur, serta diagram hubungan antar komponen, dapat digunakan dalam desain. Preliminary design akan memberikan gambaran visual sistem pada awal proyek berdasarkan input-input tersebut. Preliminary design juga meletakkan dasar bagi tahap desain yang lebih rinci selanjutnya. Tahap ini dapat dipandang sebagai draf.

Preliminary Design Review (PDR) menandai berakhirnya tahap preliminary design pada proyek. PDR harus memberikan jaminan yang memadai untuk melanjutkan ke desain rinci. Tujuan PDR adalah memastikan bahwa preliminary design dan arsitektur dasar sistem telah lengkap, serta terdapat keyakinan teknis bahwa persyaratan dapat dipenuhi dalam batas anggaran dan jadwal.

Critical Design Review (CDR)

Critical Design Review (CDR) menandai berakhirnya tahap critical design pada proyek. Desain akhir dipresentasikan melalui CDR melalui analisis komprehensif, simulasi, skema, kode perangkat lunak, dan data pengujian. CDR memastikan bahwa sistem dapat melanjutkan ke tahap pengujian dan produksi. CDR juga menyatakan bahwa persyaratan yang dimaksud dapat dipenuhi dalam batas anggaran dan lini waktu. Gambar dan spesifikasi komprehensif yang dihasilkan memberikan baseline akhir beserta product baseline awal. CDR harus memiliki cakupan yang luas dan rinci.

Tahap Desain Akhir

Tahap Desain Akhir menyediakan gambar arsitektural dan rekayasa yang rinci untuk setiap komponen dalam proyek. Untuk beberapa proyek, laporan desain akhir mungkin perlu dibuat. Masalah desain yang teridentifikasi harus diselesaikan sebelum tahap desain akhir selesai. Gambar dan laporan harus menyediakan detail yang cukup agar memungkinkan estimasi yang terencana. Laporan desain akhir harus mencakup lini waktu terbaru, estimasi biaya, dan spesifikasi. Kelayakan ekonomi proyek juga harus dipastikan. Setiap perubahan yang dilakukan selama Tahap Desain Akhir lebih mahal dibandingkan tahap-tahap lainnya. Oleh karena itu, perubahan tersebut harus dilaksanakan dengan sangat hati-hati.

SOI (Stages of Involvement)

Untuk mengevaluasi kepatuhan DO-178B suatu proyek, evaluasi SOI dilaksanakan oleh otoritas penerbangan negara terkait pada berbagai tahap proyek, seperti perencanaan, pengembangan, dan verifikasi. Idealnya, direncanakan total empat tinjauan SOI.

Evaluasi SOI pertama mencakup tahap perencanaan pekerjaan kepatuhan sertifikasi proyek. Tinjauan SOI kedua berfokus pada tahap-tahap pengembangan proyek. Dimulai dengan pengembangan persyaratan perangkat lunak tingkat tinggi, tinjauan ini mempertanyakan apakah desain, persyaratan perangkat lunak tingkat rendah, dan kode sumber telah dihasilkan sesuai dengan DO178B. Tinjauan SOI ketiga berfokus pada tahap-tahap verifikasi. Bukan hanya aktivitas pengujian, tetapi seluruh aktivitas yang dilakukan untuk tujuan verifikasi turut ditinjau. SOI keempat adalah evaluasi penutup yang dilaksanakan menjelang akhir proyek, mempertanyakan apakah masih ada aktivitas yang belum selesai dan apakah muncul masalah baru sejak evaluasi-evaluasi sebelumnya.

Harapan DO-178B terhadap produk perangkat lunak yang dihasilkan pada tahap perencanaan adalah untuk menyepakati seperangkat aturan bersama antara otoritas dan perusahaan yang melaksanakannya, serta mematuhi seperangkat aturan tersebut sepanjang proyek. Dengan kata lain, saat menyusun rencana dan standar, perusahaan tidak hanya menentukan prosesnya sendiri, tetapi juga menuliskan aturan mengenai bagaimana otoritas akan mengevaluasi dirinya sendiri sepanjang proses sertifikasi.

Penulis: Can Önal ([email protected])