4.2.2 Panduan Definisi Persyaratan Teknis

4.3 dekomposisi logis

Dekomposisi logis adalah proses untuk membuat persyaratan fungsional terperinci yang memungkinkan program dan proyek NASA memenuhi harapan pemangku kepentingan. Proses ini mengidentifikasi “apa” yang harus dicapai oleh sistem di setiap tingkat untuk memungkinkan proyek yang sukses. Dekomposisi logis menggunakan analisis fungsional untuk membuat arsitektur sistem dan menguraikan persyaratan tingkat atas (atau induk) dan mengalokasikannya ke tingkat proyek yang paling rendah yang diinginkan.

Proses Dekomposisi Logis digunakan untuk:

• Meningkatkan pemahaman tentang persyaratan teknis yang ditentukan dan hubungan di antara persyaratan (misalnya, fungsional, kinerja, perilaku, dan temporal, dll.), dan
• Menguraikan persyaratan induk menjadi satu set model dekomposisi logis dan set persyaratan teknis turunan yang terkait untuk dimasukkan ke dalam Proses Definisi Solusi Desain.

4.3.1 deskripsi proses

Gambar 4.3-1 memberikan diagram alir tipikal untuk Proses Dekomposisi Logis dan mengidentifikasi input, output, dan aktivitas tipikal yang perlu dipertimbangkan dalam menangani dekomposisi logis

4.3.1.1 Masukan

Masukan umum yang diperlukan untuk Proses Dekomposisi Logis meliputi yang berikut ini:

• Persyaratan teknis: Sekumpulan persyaratan yang telah divalidasi yang mewakili deskripsi masalah yang akan diselesaikan, telah ditetapkan oleh analisis fungsional dan kinerja, dan telah disetujui oleh pelanggan dan pemangku kepentingan lainnya. Contoh dokumen yang mencakup persyaratan adalah SRD, PRD, dan IRD.
• Tindakan teknis: Serangkaian tindakan yang ditetapkan berdasarkan ekspektasi dan persyaratan yang akan dilacak dan dinilai untuk menentukan efektivitas sistem atau produk secara keseluruhan dan kepuasan pelanggan.

^{_{Sumber: nasa.gov gambar 4.4‑2  doktrin pemurnian berturut-turut}}

4.3.1.2 aktivitas proses

4.3.1.2.1 mendefinisikan satu atau lebih model dekomposisi logis

Langkah pertama yang penting dalam Proses Dekomposisi Logis adalah menetapkan model arsitektur sistem. Aktivitas arsitektur sistem mendefinisikan struktur dan hubungan yang mendasari perangkat keras, perangkat lunak, manusia di dalam lingkaran, personil pendukung, komunikasi, operasi, dan lain-lain, yang menyediakan untuk implementasi Badan, direktorat misi, program, proyek, dan tingkat persyaratan berikutnya. Aktivitas arsitektur sistem mendorong partisi elemen dan persyaratan sistem ke fungsi dan persyaratan tingkat yang lebih rendah hingga pekerjaan desain dapat diselesaikan. Antarmuka dan hubungan antara subsistem dan elemen yang dipartisi juga didefinisikan.

Setelah persyaratan dan batasan fungsional tingkat atas (atau induk) telah ditetapkan, perancang sistem menggunakan analisis fungsional untuk mulai merumuskan arsitektur sistem konseptual. Arsitektur sistem dapat dilihat sebagai organisasi strategis dari elemen-elemen fungsional sistem, yang ditata untuk memungkinkan peran, hubungan, ketergantungan, dan antarmuka antar elemen didefinisikan dan dipahami dengan jelas. Arsitektur sistem bersifat strategis karena fokusnya pada struktur sistem secara keseluruhan dan bagaimana elemen-elemennya saling cocok untuk memberikan kontribusi pada keseluruhan, dan bukan pada cara kerja elemen-elemen itu sendiri. Hal ini memungkinkan elemen-elemen tersebut dikembangkan secara terpisah satu sama lain sambil memastikan bahwa mereka bekerja sama secara efektif untuk mencapai persyaratan tingkat atas (atau induk).

Sama seperti elemen-elemen dekomposisi fungsional lainnya, pengembangan arsitektur tingkat sistem yang baik adalah proses kreatif, rekursif, kolaboratif, dan berulang yang menggabungkan pemahaman yang sangat baik tentang tujuan akhir proyek dan kendala dengan pengetahuan yang sama baiknya tentang berbagai cara teknis potensial untuk memberikan produk akhir.

Berfokus pada tujuan akhir proyek, persyaratan tingkat atas (atau induk), dan kendala, arsitek sistem harus mengembangkan setidaknya satu, tetapi lebih disukai beberapa, konsep arsitektur yang mampu mencapai tujuan program. Setiap konsep arsitektur melibatkan spesifikasi elemen-elemen fungsional (apa yang dilakukan oleh bagian-bagiannya), hubungan mereka satu sama lain (definisi antarmuka), dan ConOps, yaitu, bagaimana berbagai segmen, subsistem, elemen, personil, unit, dan lain-lain, akan beroperasi sebagai sebuah sistem ketika didistribusikan oleh lokasi dan lingkungan dari awal operasi hingga akhir misi.

Proses pengembangan konsep arsitektur harus bersifat rekursif dan berulang dengan umpan balik dari para pemangku kepentingan dan peninjau eksternal, serta dari para perancang dan operator subsistem, yang diberikan sesering mungkin untuk meningkatkan kemungkinan pencapaian tujuan program yang diinginkan secara efektif sekaligus mengurangi kemungkinan pembengkakan biaya dan jadwal.

Pada tahap awal pengembangan, banyak konsep yang dihasilkan. Kendala biaya dan jadwal pada akhirnya akan membatasi berapa lama sebuah program atau proyek dapat mempertahankan beberapa konsep arsitektur. Untuk semua program NASA, desain arsitektur diselesaikan selama Fase Perumusan. Untuk sebagian besar proyek NASA (dan program-program yang digabungkan secara ketat), garis dasar arsitektur tunggal terjadi selama Fase A. Perubahan arsitektur pada tingkat yang lebih tinggi kadang-kadang terjadi karena penguraian ke tingkat yang lebih rendah menghasilkan kerumitan dalam desain, biaya, atau jadwal yang mengharuskan perubahan tersebut. Namun, seperti yang ditunjukkan pada Gambar 2.5-1, semakin akhir dalam proses pengembangan, perubahan yang terjadi akan semakin mahal.

Selain dari pikiran kreatif para arsitek, ada beberapa alat yang dapat digunakan untuk mengembangkan arsitektur sistem. Alat-alat tersebut terutama adalah alat pemodelan dan simulasi, alat analisis fungsional, kerangka kerja arsitektur, dan studi perdagangan. (Sebagai contoh, salah satu cara untuk melakukan arsitektur adalah Kerangka Kerja Arsitektur Departemen Pertahanan (DODAF). Konsep pencarian dikembangkan, dan model analitis arsitektur, elemen-elemennya, dan operasinya dikembangkan dengan ketepatan yang semakin meningkat seiring dengan perkembangan proyek. Dekomposisi fungsional, pengembangan persyaratan, dan studi perdagangan kemudian dilakukan. Beberapa iterasi dari kegiatan ini memberikan umpan balik pada konsep arsitektur yang berkembang seiring dengan turunnya persyaratan dan semakin matangnya desain.

4.3.1.2.2 mengalokasikan persyaratan teknis, menyelesaikan konflik, dan baseline

Analisis fungsional adalah metode utama yang digunakan dalam pengembangan arsitektur sistem dan dekomposisi kebutuhan fungsional. Ini adalah proses sistematis untuk mengidentifikasi, menggambarkan, dan menghubungkan fungsi-fungsi yang harus dilakukan oleh sebuah sistem untuk memenuhi tujuan dan sasarannya. Analisis fungsional mengidentifikasi dan menghubungkan fungsi sistem, studi perdagangan, karakteristik antarmuka, dan alasan untuk persyaratan. Biasanya didasarkan pada ConOps untuk sistem yang diminati.

Tiga langkah utama dalam melakukan analisis fungsional adalah:

1. Menerjemahkan persyaratan tingkat atas ke dalam fungsi-fungsi yang harus dilakukan untuk mencapai persyaratan.
2. Menguraikan dan mengalokasikan fungsi-fungsi tersebut ke tingkat yang lebih rendah dari struktur rincian produk.
3. Mengidentifikasi dan menggambarkan antarmuka fungsional dan subsistem.

Proses ini melibatkan analisis setiap persyaratan sistem untuk mengidentifikasi semua fungsi yang perlu dilakukan untuk memenuhi persyaratan. Setiap fungsi yang diidentifikasi dijelaskan dalam bentuk input, output, mode kegagalan, konsekuensi kegagalan, dan persyaratan antarmuka. Proses ini diulangi dari atas ke bawah sehingga sub-fungsi dikenali sebagai bagian dari area fungsional yang lebih besar. Fungsi-fungsi disusun dalam urutan logis sehingga setiap penggunaan operasional tertentu dari sistem dapat ditelusuri dalam jalur ujung ke ujung.

Proses ini bersifat rekursif dan berulang dan terus berlanjut hingga semua tingkat arsitektur/sistem yang diinginkan telah dianalisis, didefinisikan, dan ditetapkan. Hampir pasti akan ada cara alternatif untuk menguraikan fungsi. Sebagai contoh, mungkin ada beberapa cara untuk berkomunikasi dengan kru: Frekuensi Radio (RF), laser, Internet, dll. Oleh karena itu, hasilnya sangat tergantung pada kreativitas, keterampilan, dan pengalaman para insinyur yang melakukan analisis. Ketika analisis berlanjut ke tingkat yang lebih rendah dari arsitektur dan sistem, dan sistem lebih dipahami, insinyur sistem harus tetap berpikiran terbuka dan bersedia untuk kembali dan mengubah arsitektur yang telah ditetapkan sebelumnya dan persyaratan sistem. Perubahan ini kemudian harus diuraikan kembali melalui arsitektur dan sub-fungsi dengan proses rekursif yang terus berlanjut hingga sistem sepenuhnya didefinisikan dengan semua persyaratan yang dipahami dan diketahui layak, dapat diverifikasi, dan konsisten secara internal. Hanya pada saat itu arsitektur dan persyaratan sistem harus menjadi dasar.

4.3.1.2.3 menangkap produk kerja

Produk kerja lain yang dihasilkan selama Proses Dekomposisi Logis harus ditangkap bersama dengan keputusan-keputusan utama yang dibuat, alasan dan asumsi pendukung keputusan, dan pelajaran yang dipetik dalam melakukan kegiatan.

4.3.1.3 keluaran

Keluaran umum dari Proses Dekomposisi Logis meliputi hal-hal berikut ini:

• Model Dekomposisi Logis: Model-model ini mendefinisikan hubungan antara persyaratan dan fungsi serta perilakunya. Model-model ini mencakup model arsitektur sistem yang mendefinisikan struktur dan hubungan yang mendasari elemen-elemen sistem (misalnya, perangkat keras, perangkat lunak, manusia di dalam lingkaran, personel pendukung, komunikasi, operasi, dll.) Dan dasar untuk mempartisi persyaratan ke tingkat yang lebih rendah ke titik di mana pekerjaan desain dapat diselesaikan.
• Persyaratan Teknis yang diturunkan: Ini adalah persyaratan yang muncul dari definisi arsitektur yang dipilih yang tidak secara eksplisit dinyatakan dalam persyaratan dasar yang berfungsi sebagai masukan untuk proses ini. Baik persyaratan dasar maupun turunan dialokasikan ke arsitektur dan fungsi sistem.
• Produk Kerja Dekomposisi Logis: Ini adalah produk lain yang dihasilkan oleh aktivitas proses ini.

4.3.2 panduan dekomposisi logis

Lihat Bagian 4.3.2 dan Lampiran F dalam Panduan yang Diperluas NASA untuk Rekayasa Sistem di https://nen.nasa.gov/web/se/doc-repository untuk panduan tambahan tentang:

Struktur Penguraian Produk dan

Teknik analisis fungsional

4.4 definisi solusi sesain

Proses Definisi Solusi Desain digunakan untuk menerjemahkan persyaratan tingkat tinggi yang berasal dari ekspektasi pemangku kepentingan dan output dari Proses Dekomposisi Logis ke dalam solusi desain. Proses ini melibatkan transformasi model dekomposisi logis yang telah ditentukan dan kumpulan persyaratan teknis turunannya menjadi solusi alternatif. Solusi alternatif ini kemudian dianalisis melalui studi perdagangan terperinci yang menghasilkan pemilihan alternatif yang lebih disukai. Alternatif yang dipilih ini kemudian sepenuhnya didefinisikan menjadi solusi desain akhir yang memenuhi persyaratan teknis. Definisi solusi desain ini digunakan untuk menghasilkan spesifikasi produk akhir yang digunakan untuk menghasilkan produk dan untuk melakukan verifikasi produk. Proses ini dapat disempurnakan lebih lanjut tergantung pada apakah ada subsistem tambahan dari produk akhir yang perlu didefinisikan.

4.4.1 deskripsi proses

Gambar 4.4-1 memberikan diagram alir tipikal untuk Proses Definisi Solusi Desain dan mengidentifikasi input, output, dan aktivitas tipikal yang perlu dipertimbangkan dalam menangani definisi solusi desain.

4.4.1.1 masukan

Ada beberapa masukan mendasar yang diperlukan untuk memulai Proses Definisi Solusi Desain:

• Persyaratan Teknis: Ini adalah kebutuhan pelanggan dan pemangku kepentingan yang telah diterjemahkan ke dalam satu set lengkap persyaratan yang telah divalidasi untuk sistem, termasuk semua persyaratan antarmuka.
• Model Dekomposisi Logis: Persyaratan dianalisis dan didekomposisi dengan satu atau beberapa metode yang berbeda (misalnya, fungsi, waktu, perilaku, aliran data, status, mode, arsitektur sistem, dll.) untuk mendapatkan pemahaman yang lebih komprehensif tentang interaksi dan perilakunya. (Lihat definisi model di Lampiran B.)

4.4.1.2 kegiatan proses

4.4.1.2.1 mendefinisikan solusi desain alternatif

Realisasi sebuah sistem selama siklus hidupnya melibatkan serangkaian keputusan di antara berbagai alternatif tindakan. Jika alternatif didefinisikan secara tepat dan dipahami secara menyeluruh untuk dibedakan dengan baik dalam ruang efektivitas biaya, maka insinyur sistem dapat membuat pilihan di antara mereka dengan percaya diri.

Untuk mendapatkan penilaian yang cukup tajam untuk memfasilitasi keputusan yang baik, sering kali perlu untuk menyelidiki lebih dalam ke dalam ruang desain yang mungkin daripada yang telah dilakukan, seperti yang diilustrasikan pada Gambar 4.4-2. Namun, perlu disadari bahwa ilustrasi ini tidak mewakili siklus hidup proyek, yang mencakup proses pengembangan sistem dari awal hingga pembuangan, atau proses pengembangan produk yang dengannya desain sistem dikembangkan dan diimplementasikan.

Setiap langkah “membuat konsep” pada Gambar 4.4-2 melibatkan loop desain rekursif dan berulang yang didorong oleh seperangkat ekspektasi pemangku kepentingan di mana arsitektur/desain manusia jerami, ConOps yang terkait, dan persyaratan turunannya dikembangkan dan kendala program seperti biaya dan jadwal dipertimbangkan. Ketiga produk ini harus konsisten satu sama lain dan akan membutuhkan iterasi dan keputusan desain untuk mencapai konsistensi ini. Lingkaran desain rekursif dan berulang ini diilustrasikan pada Gambar 4.0-1.

Setiap langkah “membuat konsep” pada Gambar 4.4-2 juga melibatkan penilaian kemampuan potensial yang ditawarkan oleh keadaan teknologi yang terus berubah dan potensi jebakan yang ditangkap melalui tinjauan berbasis pengalaman dari data pembelajaran program/proyek sebelumnya. Sangat penting bahwa ada interaksi yang berkelanjutan antara proses pengembangan teknologi, proses lintas sektoral seperti integrasi sistem manusia, dan proses desain untuk memastikan bahwa desain mencerminkan realitas teknologi yang tersedia dan bahwa ketergantungan yang berlebihan pada teknologi yang belum matang dapat dihindari. Selain itu, kondisi teknologi apa pun yang dianggap memungkinkan harus dipantau dengan baik, dan harus diperhatikan ketika menilai dampak teknologi ini terhadap kinerja konsep. Interaksi ini difasilitasi melalui penilaian desain secara berkala sehubungan dengan kematangan teknologi yang diperlukan untuk mengimplementasikan desain. (Lihat Bagian 4.4.2.1 dalam Panduan yang Diperluas untuk Rekayasa Sistem NASA di https://nen.nasa.gov/web/se/doc-repository untuk diskusi yang lebih rinci tentang penilaian teknologi). Elemen-elemen teknologi ini biasanya ada di tingkat yang lebih rendah dalam PBS. Meskipun proses pengembangan konsep desain dengan integrasi elemen-elemen tingkat yang lebih rendah merupakan bagian dari proses rekayasa sistem, selalu ada bahaya bahwa proses top-down tidak dapat mengimbangi proses bottom-up. Oleh karena itu, masalah arsitektur sistem perlu diselesaikan lebih awal agar sistem dapat dimodelkan dengan realisme yang memadai untuk melakukan studi perdagangan yang andal.

Ketika sistem direalisasikan, rinciannya menjadi lebih jelas-tetapi juga lebih sulit untuk diubah. Lihat “Biaya untuk Mengubah Arah Desain” yang meningkat pada Gambar 2.5-1. Tujuan dari rekayasa sistem adalah untuk memastikan bahwa Proses Definisi Solusi Desain terjadi dengan cara yang mengarah pada sistem akhir yang paling fungsional, aman, dan hemat biaya, sementara bekerja dalam batas-batas jadwal yang diberikan. Ide dasarnya adalah bahwa sebelum keputusan yang sulit dibatalkan dibuat, alternatif harus dinilai secara hati-hati dan berulang-ulang, terutama yang berkaitan dengan kematangan teknologi yang dibutuhkan dan ekspektasi pemangku kepentingan untuk operasi yang efisien dan efektif.

4.4.1.2.2 membuat konsep desain alternatif

Setelah dipahami apa yang ingin dicapai oleh sistem, maka dimungkinkan untuk merancang berbagai cara agar tujuan-tujuan tersebut dapat dicapai. Terkadang, hal tersebut muncul sebagai konsekuensi dari mempertimbangkan alokasi fungsional alternatif dan mengintegrasikan pilihan desain subsistem yang tersedia, yang semuanya dapat memiliki teknologi dengan tingkat kematangan yang berbeda-beda. Idealnya, berbagai alternatif yang masuk akal dan konsisten dengan piagam organisasi desain harus didefinisikan, dengan mengingat tahap saat ini dalam proses penyempurnaan yang berurutan. Ketika proses bottom-up beroperasi, masalah bagi insinyur sistem adalah bahwa para desainer cenderung menyukai desain yang mereka buat, sehingga mereka kehilangan objektivitas mereka; insinyur sistem harus tetap menjadi “orang luar” sehingga ada lebih banyak objektivitas. Hal ini terutama berlaku dalam penilaian kematangan teknologi subsistem dan komponen yang diperlukan untuk implementasi. Ada kecenderungan dari pihak pengembang teknologi dan manajemen proyek untuk melebih-lebihkan kematangan dan penerapan teknologi yang diperlukan untuk mengimplementasikan desain. Hal ini terutama terjadi pada peralatan “warisan”. Hasilnya adalah bahwa aspek-aspek penting dari rekayasa sistem sering diabaikan.

Penciptaan solusi desain alternatif melibatkan penilaian kemampuan potensial yang ditawarkan oleh keadaan teknologi yang terus berubah. Interaksi yang berkelanjutan antara proses pengembangan teknologi dan proses desain memastikan bahwa desain tersebut mencerminkan realitas teknologi yang tersedia. Interaksi ini difasilitasi melalui penilaian desain secara berkala sehubungan dengan kematangan teknologi yang diperlukan untuk mengimplementasikan desain.

Setelah mengidentifikasi kesenjangan teknologi yang ada dalam konsep desain yang diberikan, sering kali perlu untuk melakukan pengembangan teknologi untuk memastikan kelangsungan hidup. Mengingat sumber daya akan selalu terbatas, maka perlu untuk mengejar hanya teknologi yang paling menjanjikan yang diperlukan untuk memungkinkan konsep tertentu.

Jika persyaratan ditentukan tanpa memahami sepenuhnya sumber daya yang dibutuhkan untuk mencapai pengembangan teknologi yang dibutuhkan, maka program/proyek tersebut berisiko. Penilaian teknologi harus dilakukan secara berulang hingga persyaratan dan sumber daya yang tersedia selaras dalam postur risiko yang dapat diterima. Pengembangan teknologi memainkan peran yang jauh lebih besar dalam siklus hidup program/proyek daripada yang telah dipertimbangkan secara tradisional, dan ini adalah peran insinyur sistem untuk mengembangkan pemahaman tentang sejauh mana dampak program/proyek-memaksimalkan manfaat dan meminimalkan efek samping. Secara tradisional, dari perspektif program/proyek, pengembangan teknologi telah dikaitkan dengan pengembangan dan penggabungan teknologi “baru” apa pun yang diperlukan untuk memenuhi persyaratan. Namun, area yang sering diabaikan adalah yang terkait dengan modifikasi sistem “warisan” yang digabungkan ke dalam arsitektur yang berbeda dan beroperasi di lingkungan yang berbeda dari yang dirancang. Jika modifikasi yang diperlukan dan/atau lingkungan operasi berada di luar ranah pengalaman, maka hal ini juga harus dipertimbangkan sebagai pengembangan teknologi.

Untuk memahami apakah pengembangan teknologi diperlukan atau tidak-dan kemudian mengukur biaya, jadwal, dan risiko yang terkait-perlu dilakukan penilaian secara sistematis terhadap kematangan setiap sistem, subsistem, atau komponen dalam hal arsitektur dan lingkungan operasional. Kemudian perlu untuk menilai apa yang diperlukan dalam cara pengembangan untuk memajukan kematangan ke titik di mana ia dapat berhasil dimasukkan dalam batasan biaya, jadwal, dan kinerja. Proses untuk mencapai penilaian ini dijelaskan dalam Lampiran G. Karena pengembangan teknologi memiliki potensi dampak yang signifikan terhadap program/proyek, maka penilaian teknologi perlu berperan dalam seluruh proses desain dan pengembangan mulai dari pengembangan konsep sampai dengan Preliminary Design Review (PDR). Pelajaran yang dapat dipetik dari sudut pandang pengembangan teknologi kemudian harus ditangkap pada fase akhir program.

Pada giliran pertama dari penyempurnaan yang berurutan pada Gambar 4.4-2, subjeknya sering kali berupa pendekatan atau strategi umum, terkadang konsep arsitektur. Pada giliran berikutnya, kemungkinan besar adalah desain fungsional, kemudian desain rinci, dan seterusnya. Alasan untuk menghindari fokus yang terlalu dini pada satu desain adalah untuk memungkinkan penemuan desain yang benar-benar terbaik. Bagian dari tugas insinyur sistem adalah memastikan bahwa konsep desain yang akan dibandingkan mempertimbangkan semua persyaratan antarmuka. Pertanyaan yang umum diajukan antara lain: “Apakah Anda menyertakan kabel?” atau “Apakah Anda mempertimbangkan bagaimana para pemelihara dapat memperbaiki sistem?” Jika memungkinkan, setiap konsep desain harus dijelaskan dalam hal parameter desain yang dapat dikontrol sehingga masing-masing mewakili kelas desain seluas mungkin. Dalam melakukan hal tersebut, insinyur sistem harus mengingat bahwa potensi perubahan dapat mencakup struktur organisasi, batasan personil, jadwal, prosedur, dan hal-hal lain yang membentuk sistem. Jika memungkinkan, kendala juga harus dijelaskan dengan parameter.

4.4.1.2.3 menganalisis setiap alternatif solusi desain

Tim teknis menganalisis seberapa baik masing-masing alternatif desain memenuhi tujuan sistem (kesenjangan teknologi, efektivitas, pencapaian teknis, kinerja, biaya, jadwal, dan risiko, baik yang dapat dikuantifikasi maupun tidak). Penilaian ini dilakukan dengan menggunakan studi perdagangan. Tujuan dari proses studi perdagangan adalah untuk memastikan bahwa arsitektur sistem, operasi yang diinginkan (yaitu, ConOps) dan keputusan desain bergerak menuju solusi terbaik yang dapat dicapai dengan sumber daya yang tersedia. Langkah-langkah dasar dalam proses tersebut adalah:

• Merancang beberapa cara alternatif untuk memenuhi persyaratan fungsional. Pada fase awal siklus hidup proyek, hal ini berarti berfokus pada arsitektur sistem; pada fase selanjutnya, penekanan diberikan pada desain sistem.
• Mengevaluasi alternatif-alternatif ini dalam hal MOP dan biaya siklus hidup sistem. Model matematis berguna dalam langkah ini tidak hanya untuk memaksa pengenalan hubungan di antara variabel-variabel hasil, tetapi juga untuk membantu menentukan berapa MOP yang seharusnya secara kuantitatif.
• Beri peringkat alternatif sesuai dengan kriteria pemilihan yang tepat.
• Buang alternatif yang kurang menjanjikan dan lanjutkan ke tingkat penyelesaian berikutnya, jika diperlukan.

Proses studi perdagangan harus dilakukan secara terbuka dan inklusif. Meskipun teknik dan aturan kuantitatif digunakan, subjektivitas juga memainkan peran penting. Agar prosesnya berjalan efektif, para peserta harus berpikiran terbuka, dan individu dengan keahlian yang berbeda-insinyur sistem, insinyur desain, insinyur lintas bidang dan insinyur domain, analis program, pengguna akhir sistem, ilmuwan pengambilan keputusan, pemelihara, operator, dan manajer proyek-harus bekerja sama. Metode kuantitatif dan kriteria pemilihan yang tepat harus digunakan. Asumsi, model, dan hasil studi perdagangan harus didokumentasikan sebagai bagian dari arsip proyek. Para peserta harus tetap fokus pada persyaratan fungsional, termasuk persyaratan untuk produk yang memungkinkan. Untuk diskusi mendalam mengenai proses studi perdagangan, lihat Bagian 6.8. Kemampuan untuk melakukan studi ini ditingkatkan dengan pengembangan model sistem yang menghubungkan parameter desain dengan penilaian tersebut, tetapi tidak tergantung pada mereka.

Tim teknis harus mempertimbangkan berbagai konsep ketika mengembangkan model sistem. Model tersebut harus mendefinisikan peran kru, operator, pemelihara, logistik, perangkat keras, dan perangkat lunak dalam sistem. Model ini harus mengidentifikasi teknologi penting yang diperlukan untuk melaksanakan misi dan harus mempertimbangkan seluruh siklus hidup mulai dari fabrikasi hingga pembuangan. Kriteria evaluasi untuk memilih konsep harus ditetapkan. Biaya selalu menjadi faktor pembatas. Namun, kriteria lain, seperti waktu untuk mengembangkan dan mengesahkan unit, risiko, dan keandalan, juga sangat penting. Tahap ini tidak dapat dicapai tanpa membahas peran operator dan pemelihara. Hal ini berkontribusi secara signifikan terhadap biaya siklus hidup dan keandalan sistem. Analisis keandalan harus dilakukan berdasarkan perkiraan tingkat kegagalan komponen untuk perangkat keras dan pemahaman tentang konsekuensi dari kegagalan ini. Jika model penilaian risiko probabilistik diterapkan, mungkin perlu menyertakan tingkat kejadian atau probabilitas untuk kesalahan perangkat lunak atau peristiwa kesalahan manusia. Model-model ini harus mencakup analisis bahaya dan kontrol yang diterapkan melalui manajemen kesalahan. Penilaian terhadap kematangan teknologi yang dibutuhkan harus dilakukan dan rencana pengembangan teknologi dikembangkan.

Modifikasi terkendali dan pengembangan konsep desain, bersama dengan model sistem tersebut, sering kali mengizinkan penggunaan teknik optimasi formal untuk menemukan wilayah ruang desain yang memerlukan penyelidikan lebih lanjut.

Apakah model sistem digunakan atau tidak, konsep desain dikembangkan, dimodifikasi, dinilai ulang, dan dibandingkan dengan alternatif yang bersaing dalam proses loop tertutup yang mencari pilihan terbaik untuk pengembangan lebih lanjut. Ukuran sistem dan subsistem sering kali ditentukan selama studi perdagangan. Hasil akhirnya adalah penentuan batas-batas efektivitas biaya relatif dari alternatif desain, yang diukur dalam hal tujuan sistem yang dikuantifikasi. (Hanya batas-batas, dan bukan nilai akhir, yang dimungkinkan karena penentuan detail akhir desain sengaja ditangguhkan). Peningkatan detail yang terkait dengan resolusi yang terus meningkat akan mengurangi penyebaran antara batas atas dan bawah seiring dengan berjalannya proses.

4.4.1.2.4 memilih alternatif solusi desain terbaik

Tim teknis memilih solusi desain terbaik dari antara konsep desain alternatif, dengan mempertimbangkan faktor-faktor subjektif yang tidak dapat diukur oleh tim, seperti kekokohan, serta perkiraan seberapa baik alternatif tersebut memenuhi persyaratan kuantitatif; kematangan teknologi yang tersedia; dan efektivitas, biaya, jadwal, risiko, atau kendala lainnya.

Proses Analisis Keputusan, seperti yang dijelaskan pada Bagian 6.8, harus digunakan untuk melakukan evaluasi terhadap konsep-konsep desain alternatif dan merekomendasikan solusi desain “terbaik”.

Jika memungkinkan, biasanya akan sangat bermanfaat untuk mengembangkan ekspresi matematis, yang disebut “fungsi obyektif”, yang mengekspresikan nilai-nilai kombinasi hasil yang mungkin sebagai ukuran tunggal efektivitas biaya, seperti yang diilustrasikan pada Gambar 4.4-3, meskipun biaya dan efektivitas harus dijelaskan dengan lebih dari satu ukuran.

Fungsi tujuan kuantitatif

^{_{Sumber: nasa.gov gambar 4.4-3 fungsi tujuan kuantitatif, bergantung pada biaya siklus hidup dan semua aspek efektivitas}}

Catatan: Area yang diarsir berbeda menunjukkan tingkat ketidakpastian yang berbeda. Garis putus-putus menunjukkan nilai konstan dari fungsi tujuan (efektivitas biaya). Nilai efektivitas biaya yang lebih tinggi dicapai dengan bergerak ke arah kiri atas. A, B, dan C adalah konsep desain dengan pola risiko yang berbeda.

Fungsi objektif (atau “fungsi biaya”) memberikan bilangan riil pada kandidat solusi atau “solusi yang layak” dalam ruang alternatif atau “ruang pencarian”. Solusi yang layak yang meminimalkan (atau memaksimalkan, jika itu tujuannya) fungsi objektif disebut “solusi optimal”. Ketika pencapaian tujuan dapat dinyatakan secara kuantitatif dengan fungsi objektif seperti itu, desain dapat dibandingkan dalam hal nilainya. Risiko yang terkait dengan konsep desain dapat menyebabkan evaluasi ini menjadi samar-samar karena tidak pasti dan paling baik dijelaskan dengan distribusi probabilitas.

Pada Gambar 4.4-3, risiko relatif tinggi untuk konsep desain A. Hanya ada sedikit risiko dalam hal efektivitas atau biaya untuk konsep B, sementara risiko kegagalan yang mahal tinggi untuk konsep C, seperti yang ditunjukkan oleh awan probabilitas di dekat sumbu x dengan biaya tinggi dan pada dasarnya tidak ada efektivitas. Faktor jadwal dapat mempengaruhi nilai efektivitas dan biaya serta distribusi risiko.

Kriteria keberhasilan misi untuk sistem berbeda secara signifikan. Dalam beberapa kasus, tujuan efektivitas mungkin jauh lebih penting daripada yang lainnya. Proyek lain mungkin menuntut biaya rendah, memiliki jadwal yang tidak dapat diubah, atau memerlukan minimalisasi beberapa jenis risiko. Jarang sekali (jika pernah) ada kemungkinan untuk menghasilkan ukuran kuantitatif gabungan yang menghubungkan semua faktor penting, meskipun dinyatakan sebagai vektor dengan beberapa komponen. Bahkan ketika hal itu dapat dilakukan, sangat penting bahwa aktor dan hubungan yang mendasarinya harus diungkapkan secara menyeluruh dan dipahami oleh insinyur sistem. Insinyur sistem harus mempertimbangkan pentingnya faktor-faktor yang tidak dapat dikuantifikasi bersama dengan data kuantitatif.

Tinjauan teknis terhadap data dan analisis, termasuk penilaian kematangan teknologi, merupakan bagian penting dari paket dukungan keputusan yang disiapkan untuk tim teknis. Keputusan yang dibuat umumnya dimasukkan ke dalam sistem manajemen konfigurasi sebagai perubahan pada (atau penjabaran dari) dasar sistem. Studi perdagangan pendukung diarsipkan untuk penggunaan di masa mendatang. Fitur penting dari proses rekayasa sistem adalah bahwa studi perdagangan dilakukan sebelum keputusan dibuat. Studi ini kemudian dapat dijadikan dasar dengan lebih percaya diri.

4.4.1.2.5 meningkatkan resolusi desain

Proses penyempurnaan yang berurutan pada Gambar 4.4-2 mengilustrasikan penyempurnaan desain sistem yang berkelanjutan. Pada setiap tingkat dekomposisi, persyaratan yang diturunkan (dan dialokasikan) secara mendasar menjadi himpunan persyaratan tingkat tinggi untuk elemen-elemen yang didekomposisi, dan proses dimulai lagi. Orang mungkin bertanya, “Kapan kita berhenti menyempurnakan desain?” Jawabannya adalah bahwa upaya desain berlanjut hingga kedalaman yang cukup untuk memenuhi beberapa kebutuhan: desain harus menembus cukup untuk memungkinkan validasi analitis desain terhadap persyaratan dan ConOps; juga harus memiliki kedalaman yang cukup untuk mendukung pemodelan biaya dan operasi serta untuk meyakinkan tim peninjau tentang desain yang layak dengan kinerja, biaya, dan margin risiko.

Mesin rekayasa sistem diterapkan berulang kali saat sistem dikembangkan. Ketika sistem direalisasikan, masalah yang ditangani berevolusi dan rincian aktivitas berubah. Sebagian besar keputusan sistem utama (tujuan, arsitektur, biaya siklus hidup yang dapat diterima, dll.) dibuat selama fase awal proyek, sehingga penyempurnaan yang dilakukan secara berurutan tidak sesuai dengan fase siklus hidup sistem. Sebagian besar arsitektur sistem dapat dilihat bahkan sejak awal, sehingga penyempurnaan yang dilakukan secara berurutan juga tidak sesuai dengan perkembangan hirarki arsitektur. Sebaliknya, mereka sesuai dengan resolusi yang lebih besar secara berurutan dimana sistem didefinisikan.

Masuk akal untuk mengharapkan sistem didefinisikan dengan resolusi yang lebih baik seiring berjalannya waktu. Kecenderungan ini diformalkan di beberapa titik (di Fase B) dengan mendefinisikan definisi sistem dasar. Biasanya, tujuan, sasaran, dan batasan ditetapkan sebagai bagian persyaratan dari baseline. Seluruh baseline kemudian ditempatkan di bawah kontrol konfigurasi dalam upaya untuk memastikan bahwa setiap perubahan berikutnya memang dibenarkan dan terjangkau.

Pada titik ini dalam proses rekayasa sistem, ada titik cabang logis. Untuk masalah-masalah yang proses penyempurnaannya telah berjalan cukup jauh, langkah selanjutnya adalah mengimplementasikan keputusan pada tingkat resolusi tersebut. Untuk isu-isu yang masih belum cukup terselesaikan, langkah selanjutnya adalah menyempurnakan pengembangan lebih lanjut.

4.4.1.2.6 menggambarkan solusi desain secara penuh

Setelah alternatif desain yang disukai telah dipilih dan tingkat penyempurnaan yang tepat telah diselesaikan, maka desain tersebut sepenuhnya didefinisikan menjadi solusi desain akhir yang akan memenuhi persyaratan teknis dan ConOps. Definisi solusi desain akan digunakan untuk menghasilkan spesifikasi produk akhir yang akan digunakan untuk menghasilkan produk dan untuk melakukan verifikasi produk. Proses ini dapat disempurnakan lebih lanjut tergantung pada apakah ada subsistem tambahan dari produk akhir yang perlu didefinisikan.

Cakupan dan isi deskripsi desain lengkap harus sesuai dengan fase siklus hidup produk, kriteria keberhasilan fase, dan posisi produk dalam PBS (struktur sistem). Bergantung pada faktor-faktor ini, bentuk definisi solusi desain dapat berupa model simulasi atau laporan studi kertas. Paket data teknis berkembang dari fase ke fase, dimulai dengan sketsa konseptual atau model dan diakhiri dengan gambar lengkap, daftar komponen, dan detail lain yang diperlukan untuk implementasi produk atau integrasi produk. Definisi keluaran yang umum dari Proses Definisi Solusi Desain ditunjukkan pada Gambar 4.4-1 dan dijelaskan pada Bagian 4.4.1.3.

4.4.1.2.7 verifikasi solusi desain

Setelah solusi desain yang dapat diterima telah dipilih dari berbagai desain alternatif dan didokumentasikan dalam paket data teknis, solusi desain selanjutnya harus diverifikasi terhadap persyaratan dan batasan sistem. Metode untuk mencapai verifikasi ini adalah dengan melakukan tinjauan sejawat untuk mengevaluasi definisi solusi desain yang dihasilkan. Panduan untuk melakukan tinjauan sejawat dibahas di Bagian 6.7.2.4.5.

Selain itu, tinjauan sejawat memainkan peran penting sebagai komponen teknis yang terperinci dari tinjauan teknis dan program yang lebih tinggi. Misalnya, tinjauan sejawat terhadap desain baterai komponen dapat membahas lebih banyak detail teknis pada baterai daripada tinjauan subsistem daya terintegrasi. Tinjauan sejawat dapat mencakup komponen subsistem hingga ke tingkat yang sesuai untuk memverifikasi desain terhadap persyaratan. Kekhawatiran yang muncul pada tinjauan sejawat mungkin memiliki implikasi pada desain dan verifikasi subsistem daya dan oleh karena itu harus dilaporkan pada tinjauan tingkat yang lebih tinggi berikutnya dari subsistem daya.

Verifikasi harus menunjukkan bahwa definisi solusi desain:

• Dapat direalisasikan dalam batasan yang diberlakukan pada upaya teknis;
• Memiliki persyaratan tertentu yang dinyatakan dalam pernyataan yang dapat diterima dan memiliki penelusuran dua arah dengan persyaratan teknis dan harapan pemangku kepentingan; dan
• Memiliki keputusan dan asumsi yang dibuat dalam membentuk solusi yang konsisten dengan serangkaian persyaratan teknis dan kendala produk dan layanan sistem yang teridentifikasi.
• Verifikasi solusi desain ini berbeda dengan verifikasi produk akhir yang dijelaskan dalam rencana verifikasi produk akhir yang merupakan bagian dari paket data teknis. Verifikasi tersebut terjadi pada fase siklus hidup selanjutnya dan merupakan hasil dari Proses Verifikasi Produk (lihat Bagian 5.3) yang diterapkan pada realisasi solusi desain sebagai produk akhir.

4.4.1.2.8 memvalidasi solusi desain

Validasi solusi desain merupakan proses rekursif dan berulang seperti yang ditunjukkan pada Gambar 4.0-1. Setiap konsep desain alternatif divalidasi terhadap sekumpulan ekspektasi pemangku kepentingan. Harapan pemangku kepentingan mendorong loop desain berulang di mana arsitektur/desain manusia jerami, ConOps, dan persyaratan turunan dikembangkan. Ketiga produk ini harus konsisten satu sama lain dan akan membutuhkan iterasi dan keputusan desain untuk mencapai konsistensi ini. Setelah konsistensi tercapai, analisis fungsional memungkinkan tim studi untuk memvalidasi desain terhadap ekspektasi pemangku kepentingan. Validasi yang disederhanakan mengajukan pertanyaan-pertanyaan: Apakah sistem bekerja seperti yang diharapkan? Bagaimana sistem merespons kegagalan, kesalahan, dan anomali? Apakah sistem terjangkau? Jika jawaban dari pertanyaan-pertanyaan tersebut adalah tidak, maka perubahan pada desain atau ekspektasi pemangku kepentingan akan diperlukan, dan prosesnya dimulai dari awal lagi. Proses ini terus berlanjut hingga sistem - arsitektur, ConOps, dan persyaratan - memenuhi ekspektasi pemangku kepentingan.

Validasi solusi desain ini berbeda dengan validasi produk akhir yang dijelaskan dalam rencana validasi produk akhir, yang merupakan bagian dari paket data teknis. Validasi tersebut terjadi pada fase siklus hidup selanjutnya dan merupakan hasil dari Proses Validasi Produk (lihat Bagian 5.4) yang diterapkan pada realisasi solusi desain sebagai produk akhir.

4.4.1.2.9 mengidentifikasi produk pendukung

Produk pendukung adalah produk dan layanan pendukung siklus hidup (misalnya, produksi, pengujian, penerapan, pelatihan, pemeliharaan, dan pembuangan) yang memfasilitasi perkembangan dan penggunaan produk akhir operasional melalui siklus hidupnya. Karena produk akhir dan produk pendukungnya saling bergantung, keduanya dipandang sebagai sebuah sistem. Oleh karena itu, tanggung jawab proyek mencakup tanggung jawab untuk memperoleh layanan dari produk pendukung yang relevan dalam setiap fase siklus hidup. Ketika produk pendukung yang sesuai belum ada, proyek yang bertanggung jawab atas produk akhir juga dapat bertanggung jawab untuk membuat dan menggunakan produk pendukung.

Oleh karena itu, aktivitas penting dalam Proses Definisi Solusi Desain adalah identifikasi produk dan personel pendukung yang akan diperlukan selama siklus hidup solusi desain yang dipilih dan kemudian memulai akuisisi atau pengembangan produk dan personel pendukung tersebut. Tanggal kebutuhan untuk produk pendukung harus diidentifikasi secara realistis pada jadwal proyek, dengan memasukkan kelonggaran jadwal yang sesuai. Kemudian komitmen yang kuat dalam bentuk kontrak, perjanjian, dan/atau rencana operasional harus dibuat untuk memastikan bahwa produk pendukung akan tersedia saat dibutuhkan untuk mendukung aktivitas fase siklus hidup produk. Persyaratan produk pendukung didokumentasikan sebagai bagian dari paket data teknis untuk Proses Definisi Solusi Desain.

Ruang uji lingkungan adalah contoh produk pendukung yang penggunaannya akan diperoleh pada waktu yang tepat selama fase pengujian sistem penerbangan luar angkasa.

Perlengkapan uji khusus atau perangkat penanganan mekanis khusus adalah contoh produk pendukung yang harus dibuat oleh proyek. Karena waktu pengembangan yang panjang serta fasilitas yang terlalu banyak dipesan, penting untuk mengidentifikasi produk pendukung dan mendapatkan komitmen untuk produk tersebut sedini mungkin dalam fase desain.

4.4.1.2.10 membuat garis dasar solusi desain

Seperti yang ditunjukkan sebelumnya pada Gambar 4.0-1, setelah solusi desain sistem yang dipilih memenuhi harapan pemangku kepentingan, tim studi membuat garis dasar produk dan mempersiapkan fase siklus hidup berikutnya. Karena sifat rekursif dari penyempurnaan yang berurutan, tingkat dekomposisi menengah sering kali divalidasi dan dijadikan dasar sebagai bagian dari proses. Pada tingkat dekomposisi berikutnya, persyaratan dasar menjadi serangkaian persyaratan tingkat tinggi untuk elemen yang didekomposisi, dan prosesnya dimulai lagi.

Membuat garis dasar solusi desain tertentu memungkinkan tim teknis untuk fokus pada satu desain dari semua konsep desain alternatif. Ini adalah titik kritis dalam proses desain. Hal ini menempatkan taruhan di tanah dan membuat semua orang di tim desain fokus pada konsep yang sama. Ketika berhadapan dengan sistem yang kompleks, sulit bagi anggota tim untuk mendesain bagian mereka dari sistem jika desain sistem adalah target yang bergerak. Desain dasar didokumentasikan dan ditempatkan di bawah kontrol konfigurasi. Ini termasuk persyaratan sistem, spesifikasi, dan deskripsi konfigurasi.

Meskipun membuat garis dasar desain bermanfaat untuk proses desain, ada bahaya jika dilakukan terlalu dini dalam Proses Definisi Solusi Desain. Eksplorasi awal desain alternatif harus bebas dan terbuka untuk berbagai ide, konsep, dan implementasi. Membuat garis dasar terlalu dini akan menghilangkan sifat inventif dari eksplorasi konsep. Oleh karena itu, baselining harus menjadi salah satu langkah terakhir dalam Proses Definisi Solusi Desain.

4.4.1.3 keluaran

Keluaran dari Proses Definisi Solusi Desain adalah spesifikasi dan rencana yang diteruskan ke proses realisasi produk. Keluaran ini berisi dokumentasi design-to, build-to, train-to, dan code-to yang sesuai dengan baseline yang disetujui untuk sistem.

Seperti yang telah disebutkan sebelumnya, ruang lingkup dan isi dari deskripsi desain lengkap harus sesuai dengan fase siklus hidup produk, kriteria keberhasilan fase, dan posisi produk dalam PBS.

Keluaran dari Proses Definisi Solusi Desain meliputi yang berikut ini:

• Spesifikasi Sistem: Spesifikasi sistem berisi garis dasar fungsional untuk sistem yang merupakan hasil dari Proses Definisi Solusi Desain. Spesifikasi desain sistem memberikan panduan, batasan, dan persyaratan sistem yang memadai bagi insinyur desain untuk mulai mengembangkan desain.
• Spesifikasi Antarmuka Eksternal Sistem: Spesifikasi antarmuka eksternal sistem menggambarkan garis dasar fungsional untuk perilaku dan karakteristik semua antarmuka fisik yang dimiliki sistem dengan dunia luar. Ini termasuk semua antarmuka struktural, termal, listrik, dan sinyal, serta antarmuka sistem manusia.
• Spesifikasi Produk Akhir: Spesifikasi produk akhir berisi persyaratan pembuatan dan kode-ke yang terperinci untuk produk akhir. Spesifikasi ini merupakan pernyataan rinci dan tepat tentang rincian desain, seperti pernyataan yang menentukan bahan, dimensi, dan kualitas pekerjaan untuk membangun, memasang, atau memproduksi produk akhir.
• Spesifikasi Antarmuka Produk Akhir: Spesifikasi antarmuka produk akhir berisi persyaratan build-to dan code-to yang terperinci untuk perilaku dan karakteristik semua antarmuka logis dan fisik yang dimiliki produk akhir dengan elemen eksternal, termasuk antarmuka sistem manusia.
• Spesifikasi Subsistem Awal: Spesifikasi awal subsistem produk akhir memberikan informasi terperinci tentang subsistem jika diperlukan.
• Persyaratan Produk Pendukung: Persyaratan untuk produk pendukung terkait yang mendukung memberikan rincian semua produk pendukung. Produk pendukung adalah produk pendukung siklus hidup, infrastruktur, personel, logistik, dan layanan yang memfasilitasi perkembangan dan penggunaan produk akhir operasional melalui siklus hidupnya. Produk pendukung dipandang sebagai bagian dari sistem karena produk akhir dan produk pendukungnya saling bergantung.
• Rencana Verifikasi Produk: Rencana verifikasi produk akhir (yang dihasilkan melalui Proses Perencanaan Teknis) menyediakan konten dan kedalaman detail yang diperlukan untuk memberikan visibilitas penuh terhadap semua aktivitas verifikasi produk akhir. Bergantung pada cakupan produk akhir, rencana tersebut mencakup aktivitas verifikasi kualifikasi, penerimaan, prapeluncuran, operasional, dan pembuangan untuk perangkat keras dan perangkat lunak penerbangan.
• Rencana Validasi Produk: Rencana validasi produk akhir (dihasilkan melalui Proses Perencanaan Teknis) menyediakan konten dan kedalaman detail yang diperlukan untuk memberikan visibilitas penuh terhadap semua aktivitas untuk memvalidasi produk akhir terhadap ekspektasi pemangku kepentingan yang telah ditetapkan. Rencana tersebut mengidentifikasi jenis validasi, prosedur validasi, dan lingkungan validasi yang sesuai untuk memastikan bahwa produk akhir yang direalisasikan sesuai dengan harapan pemangku kepentingan.
• Prosedur Logistik dan Pengoperasian: Prosedur logistik dan pengoperasian yang berlaku untuk sistem menjelaskan hal-hal seperti penanganan, transportasi, pemeliharaan, penyimpanan jangka panjang, dan pertimbangan operasional untuk solusi desain tertentu.

Keluaran lain mungkin termasuk:

• Rencana Integrasi Sistem Manusia: Rencana HSI sistem harus diperbarui untuk menunjukkan jumlah, keterampilan, dan pengembangan (misalnya, pelatihan) yang diperlukan untuk manusia di seluruh penyebaran siklus hidup penuh dan operasi sistem.