Proses desain sistem adalah proses yang saling bergantung, sangat berulang dan rekursif yang menghasilkan seperangkat persyaratan yang divalidasi dan solusi desain yang memenuhi seperangkat harapan pemangku kepentingan. Ada empat proses desain sistem: mengembangkan ekspektasi pemangku kepentingan, persyaratan teknis, dekomposisi logis, dan solusi desain.

_{^{Sumber: nasa.gov gambar 4.0-1 keterkaitan di antara proses-proses desain sistem}}

Gambar 4.0-1 mengilustrasikan hubungan rekursif di antara empat proses desain sistem. Proses-proses ini dimulai dengan tim studi yang mengumpulkan dan mengklarifikasi harapan-harapan pemangku kepentingan, termasuk tujuan misi, kendala, pendorong desain, tujuan operasional, dan kriteria untuk mendefinisikan keberhasilan misi. Kumpulan ekspektasi pemangku kepentingan dan persyaratan tingkat tinggi ini digunakan untuk mendorong loop desain berulang di mana arsitektur/desain manusia, konsep operasi, 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 memungkinkan tim proyek untuk memvalidasi desain yang diusulkan terhadap ekspektasi pemangku kepentingan. Validasi yang disederhanakan mengajukan pertanyaan-pertanyaan: Apakah sistem akan bekerja seperti yang diharapkan? Apakah sistem dapat dicapai sesuai dengan batasan anggaran dan jadwal? Apakah sistem menyediakan fungsionalitas dan memenuhi kebutuhan operasional yang mendorong persetujuan pendanaan proyek? Jika jawaban dari pertanyaan-pertanyaan tersebut adalah tidak, maka perubahan pada desain atau ekspektasi pemangku kepentingan akan diperlukan, dan prosesnya dimulai lagi. Proses ini terus berlanjut hingga sistem - arsitektur, ConOps, dan persyaratan - memenuhi ekspektasi pemangku kepentingan.

Kedalaman upaya desain harus cukup untuk memungkinkan verifikasi analitis dari desain terhadap persyaratan. Desain harus layak dan kredibel jika dinilai oleh tim peninjau independen yang berpengetahuan luas dan harus memiliki kedalaman yang cukup untuk mendukung pemodelan biaya dan penilaian operasional.

Setelah sistem memenuhi harapan pemangku kepentingan, tim studi membuat garis dasar produk dan mempersiapkan tahap berikutnya. Seringkali, tingkat dekomposisi menengah divalidasi sebagai bagian dari proses. Pada tingkat dekomposisi berikutnya, persyaratan yang diturunkan (dan dialokasikan) berdasarkan garis dasar menjadi serangkaian persyaratan tingkat tinggi untuk elemen yang didekomposisi dan prosesnya dimulai lagi. Proses desain sistem ini terutama diterapkan di Pra-Fase A dan berlanjut hingga Fase C.

Proses desain sistem selama Pra-Fase A berfokus pada menghasilkan desain yang layak yang akan mengarah pada persetujuan Formulasi. Selama Fase A, desain alternatif dan kematangan analitis tambahan diupayakan untuk mengoptimalkan arsitektur desain. Fase B menghasilkan desain awal yang memenuhi kriteria persetujuan. Selama Fase C, desain yang terperinci dan siap pakai diselesaikan.

Ini adalah deskripsi yang disederhanakan yang dimaksudkan untuk menunjukkan hubungan rekursif di antara proses desain sistem. Proses-proses ini harus digunakan sebagai panduan dan disesuaikan untuk setiap tim studi tergantung pada ukuran proyek dan tingkat hirarki tim studi. Bagian selanjutnya menjelaskan masing-masing dari empat proses desain sistem dan produk terkait untuk misi NASA yang diberikan.

Kunci desain sistem

1. Berhasil memahami dan mendefinisikan tujuan misi dan konsep operasi adalah kunci untuk menangkap harapan pemangku kepentingan, yang akan diterjemahkan ke dalam persyaratan kualitas dan efisiensi operasional selama siklus hidup proyek.
2. Penelusuran persyaratan yang lengkap dan menyeluruh merupakan faktor penting dalam keberhasilan validasi persyaratan.
3. Persyaratan yang jelas dan tidak ambigu akan membantu menghindari kesalahpahaman ketika mengembangkan sistem secara keseluruhan dan ketika membuat perubahan besar atau kecil.
4. Dokumentasikan semua keputusan yang dibuat selama pengembangan konsep desain awal dalam paket data teknis. Hal ini akan membuat filosofi desain asli dan hasil negosiasi tersedia untuk menilai perubahan dan modifikasi yang diusulkan di masa depan.
5. Validasi solusi desain merupakan proses rekursif dan berulang yang berkelanjutan di mana solusi desain dievaluasi terhadap ekspektasi pemangku kepentingan.

4.1 definisi harapan pemangku kepentingan

Proses Definisi Ekspektasi Pemangku Kepentingan adalah proses awal dalam mesin SE yang menetapkan fondasi dari mana sistem dirancang dan produk direalisasikan. Tujuan utama dari proses ini adalah untuk mengidentifikasi siapa saja pemangku kepentingan dan bagaimana mereka berniat untuk menggunakan produk. Hal ini biasanya dicapai melalui skenario kasus penggunaan (kadang-kadang disebut sebagai Design Reference Missions [DRMs]) dan ConOps.

4.1.1 Deskripsi proses

Gambar 4.1-1 memberikan diagram alir tipikal untuk Proses Definisi Ekspektasi Pemangku Kepentingan dan mengidentifikasi input, output, dan aktivitas tipikal yang perlu dipertimbangkan dalam mendefinisikan ekspektasi pemangku kepentingan.

^{_{Sumber: nasa.gov gambar 4.1-1 pposes definisi harapan pemangku kepentingan}}

4.1.1.1 masukan

Masukan umum yang diperlukan untuk Proses Definisi Ekspektasi Pemangku Kepentingan meliputi hal-hal berikut:

• Ekspektasi Pelanggan Awal: Ini adalah kebutuhan, tujuan, sasaran, keinginan, kemampuan, dan kendala lain yang diterima dari pelanggan untuk produk dalam lapisan produk. Untuk produk tingkat atas (produk akhir), ini adalah harapan pelanggan awal yang meminta produk tersebut. Untuk produk akhir dalam lapisan produk, ini adalah harapan dari penerima produk akhir ketika ditransisikan.
• Harapan Pemangku Kepentingan Lainnya: Ini adalah harapan pemangku kepentingan utama selain pelanggan. Misalnya, pemangku kepentingan tersebut dapat berupa tim penguji yang akan menerima produk yang ditransisikan (produk akhir dan produk pendukung) atau pelatih yang akan menginstruksikan operator atau manajer yang bertanggung jawab atas produk pada lapisan ini.
• Persyaratan Aliran ke Bawah Pelanggan: Ini adalah setiap persyaratan yang dialirkan ke bawah atau dialokasikan dari tingkat yang lebih tinggi (yaitu persyaratan induk). Mereka sangat membantu dalam menetapkan harapan pelanggan pada lapisan ini.

4.1.1.2 aktivitas proses

4.1.1.2.1 Mengidentifikasi pemangku kepentingan

“Pemangku kepentingan” adalah kelompok atau individu yang terpengaruh atau memiliki kepentingan dalam produk atau proyek. Para pemain kunci untuk sebuah proyek/produk disebut pemangku kepentingan utama. Salah satu pemangku kepentingan utama adalah “pelanggan”. Pelanggan dapat bervariasi tergantung di mana insinyur sistem bekerja di PBS. Misalnya, di tingkat paling atas, pelanggan mungkin adalah orang atau organisasi yang membeli produk. Untuk insinyur sistem yang bekerja tiga atau empat tingkat di bawah di PBS, pelanggan mungkin adalah pemimpin tim yang mengambil elemen dan mengintegrasikannya ke dalam perakitan yang lebih besar. Terlepas dari di mana insinyur sistem bekerja di dalam PBS, penting untuk memahami apa yang diharapkan oleh pelanggan.

Pihak-pihak lain yang berkepentingan adalah mereka yang memengaruhi proyek dengan memberikan batasan yang luas dan menyeluruh di mana kebutuhan pelanggan harus dicapai. Pihak-pihak ini mungkin terpengaruh oleh produk yang dihasilkan, cara penggunaan produk, atau memiliki tanggung jawab untuk menyediakan layanan dukungan siklus hidup. Contohnya adalah Kongres, tim perencanaan penasihat, manajer program, pengelola, dan mitra misi. Daftar pemangku kepentingan harus diidentifikasi di awal proses, serta pemangku kepentingan utama yang akan memiliki pengaruh paling signifikan terhadap proyek.

Pelanggan dan pengguna sistem biasanya mudah diidentifikasi. Pemangku kepentingan utama lainnya mungkin lebih sulit untuk diidentifikasi dan mereka dapat berubah tergantung pada jenis proyek dan fase proyek. Tabel 4.1-1 memberikan beberapa contoh pemangku kepentingan dalam fase siklus hidup yang harus dipertimbangkan.

^{_{Sumber: nasa.gov Tabel 4.1-1 Identifikasi Pemangku Kepentingan di Seluruh Siklus Hidup}}

4.1.1.2.2 memahami harapan pemangku kepentingan

Memahami secara menyeluruh harapan pelanggan dan pemangku kepentingan utama lainnya terhadap proyek/produk adalah salah satu langkah terpenting dalam proses rekayasa sistem. Hal ini memberikan fondasi yang menjadi dasar bagi semua pekerjaan rekayasa sistem lainnya. Hal ini membantu memastikan bahwa semua pihak memiliki pemahaman yang sama dan bahwa produk yang dihasilkan akan memuaskan pelanggan. Ketika pelanggan, pemangku kepentingan lainnya, dan perekayasa sistem saling menyetujui fungsi, karakteristik, perilaku, tampilan, dan kinerja yang akan ditunjukkan oleh produk, hal ini akan menetapkan ekspektasi yang lebih realistis dari pihak pelanggan dan membantu mencegah persyaratan yang signifikan merambat di kemudian hari dalam siklus hidup.

Melalui wawancara/diskusi, survei, kelompok pemasaran, email, Pernyataan Pekerjaan (SOW), serangkaian persyaratan awal pelanggan, atau cara lain, pemangku kepentingan menentukan apa yang diinginkan sebagai kondisi akhir atau sebagai barang yang akan diproduksi dan memberikan batasan pada pencapaian tujuan. Batasan ini dapat mencakup pengeluaran (sumber daya), waktu untuk menghasilkan, ekspektasi dukungan siklus hidup, tujuan kinerja, kendala operasional, tujuan pelatihan, atau jumlah lain yang kurang jelas seperti kebutuhan organisasi atau tujuan geopolitik. Informasi ini ditinjau, dirangkum, dan didokumentasikan sehingga semua pihak dapat mencapai kesepakatan tentang harapan-harapan tersebut.

Gambar 4.1-2 menunjukkan jenis informasi yang dibutuhkan ketika mendefinisikan ekspektasi pemangku kepentingan dan menggambarkan bagaimana informasi tersebut berkembang menjadi seperangkat persyaratan tingkat tinggi. Garis kuning menggambarkan jalur validasi. Contoh jenis informasi yang akan didefinisikan selama setiap langkah juga disediakan.

^{_{Sumber: nasa.gov gambar 4.1-2 aliran informasi untuk harapan pemangku kepentingan}}

Mendefinisikan ekspektasi pemangku kepentingan dimulai dengan otoritas misi dan tujuan strategis yang ingin dicapai oleh misi tersebut. Otoritas misi berubah tergantung pada kategori misi. Sebagai contoh, misi sains biasanya didorong oleh rencana strategis Direktorat Misi Sains NASA, sedangkan misi eksplorasi mungkin didorong oleh arahan Presiden. Memahami tujuan misi membantu memastikan bahwa tim proyek bekerja untuk mencapai visi yang sama. Tujuan dan sasaran ini menjadi dasar untuk mengembangkan misi, sehingga perlu didefinisikan dan diartikulasikan dengan jelas.

Tim proyek juga harus mengidentifikasi kendala yang mungkin ada. “Kendala” adalah kondisi yang harus dipenuhi. Terkadang kendala ditentukan oleh faktor eksternal seperti mekanika orbit, sistem yang ada yang harus digunakan (antarmuka eksternal), pembatasan peraturan, atau keadaan teknologi; terkadang kendala adalah hasil dari lingkungan anggaran secara keseluruhan. Konsep operasi dan kendala juga perlu disertakan dalam mendefinisikan ekspektasi pemangku kepentingan. Hal ini mengidentifikasi bagaimana sistem harus dioperasikan untuk mencapai tujuan misi.

CATATAN: Sangatlah penting untuk melibatkan para pemangku kepentingan dalam semua fase proyek. Keterlibatan tersebut harus dibangun sebagai lingkaran umpan balik yang mengoreksi diri sendiri yang secara signifikan akan meningkatkan peluang keberhasilan misi. Melibatkan para pemangku kepentingan dalam sebuah proyek akan membangun kepercayaan diri dalam produk akhir dan berfungsi sebagai validasi dan penerimaan dengan audiens target.

Dalam mengidentifikasi serangkaian ekspektasi, insinyur sistem perlu berinteraksi dengan berbagai komunitas, seperti mereka yang bekerja di bidang puing-puing orbital, perlindungan aset ruang angkasa, integrasi sistem manusia, jaminan kualitas, dan keandalan. Memastikan bahwa serangkaian ekspektasi yang lengkap ditangkap akan membantu mencegah fitur “kejutan” muncul di kemudian hari dalam siklus hidup. Sebagai contoh, perlindungan aset ruang angkasa mungkin memerlukan enkripsi tambahan untuk perintah forward link, perisai atau penyaringan tambahan untuk sistem RF, penggunaan frekuensi yang berbeda, atau perubahan desain lainnya yang mungkin mahal untuk ditambahkan ke sistem yang telah dikembangkan.

4.1.1.2.3 mengidentifikasi kebutuhan, sasaran, dan tujuan

Untuk menentukan tujuan dan sasaran, perlu untuk mendapatkan kebutuhan, keinginan, keinginan, kemampuan, antarmuka eksternal, asumsi, dan kendala dari para pemangku kepentingan. Mencapai tujuan dan sasaran yang telah disepakati dapat menjadi tugas yang panjang dan sulit. Iterasi proaktif dengan para pemangku kepentingan selama proses rekayasa sistem adalah cara agar semua pihak dapat mencapai pemahaman yang benar tentang apa yang harus dilakukan dan apa yang diperlukan untuk melakukan pekerjaan tersebut. Penting untuk mengetahui siapa pemangku kepentingan utama dan siapa yang memiliki otoritas keputusan untuk membantu menyelesaikan konflik.

Kebutuhan, Sasaran, dan Tujuan (KST) menyediakan mekanisme untuk memastikan bahwa semua orang (pelaksana, pelanggan, dan pemangku kepentingan lainnya) sepakat di awal proyek dalam hal mendefinisikan masalah yang perlu diselesaikan dan ruang lingkupnya. LSM bukanlah persyaratan atau desain kontrak.

Kebutuhan didefinisikan sebagai jawaban dari pertanyaan “Masalah apa yang ingin kita selesaikan?” Sasaran membahas apa yang harus dilakukan untuk memenuhi kebutuhan; yaitu, apa yang pelanggan ingin sistem lakukan. Sasaran memperluas tujuan dan menyediakan sarana untuk mendokumentasikan ekspektasi yang spesifik. (Alasan harus diberikan jika diperlukan untuk menjelaskan mengapa kebutuhan, tujuan, atau sasaran itu ada, asumsi yang dibuat, dan informasi lain yang berguna dalam memahami atau mengelola LSM).

NGO yang ditulis dengan baik memberikan penelusuran yang jelas dari kebutuhan, kemudian ke tujuan, dan kemudian ke sasaran. Sebagai contoh, jika tujuan tertentu tidak mendukung kebutuhan, atau tujuan tidak mendukung sasaran, maka tujuan tersebut tidak boleh menjadi bagian dari rangkaian LSM yang terintegrasi. Ketertelusuran ini membantu memastikan bahwa tim benar-benar menyediakan apa yang dibutuhkan.

Definisi berikut (sumber: Rekayasa Sistem Ruang Angkasa Terapan yang diedit oleh Larson, Kirkpatrick, Sellers, Thomas, dan Verma) disediakan untuk membantu pembaca menginterpretasikan LSM yang terkandung dalam produk ini.

• Kebutuhan: Sebuah pernyataan tunggal yang mendorong segala sesuatu yang lain. Pernyataan ini harus berhubungan dengan masalah yang seharusnya dipecahkan oleh sistem, namun bukan merupakan solusi. Pernyataan kebutuhan bersifat tunggal. Mencoba untuk memenuhi lebih dari satu kebutuhan membutuhkan pertukaran antara keduanya, yang dapat dengan mudah mengakibatkan kegagalan untuk memenuhi setidaknya satu, dan mungkin beberapa, harapan pemangku kepentingan.
• Tujuan: Penjabaran dari kebutuhan, yang merupakan seperangkat harapan spesifik untuk sistem. Tujuan membahas isu-isu kritis yang diidentifikasi selama penilaian masalah. Tujuan tidak harus dalam bentuk kuantitatif atau terukur, tetapi harus memungkinkan kita untuk menilai apakah sistem telah mencapainya.
• Sasaran: Tingkat target spesifik dari output yang harus dicapai oleh sistem. Setiap sasaran harus berhubungan dengan tujuan tertentu. Secara umum, sasaran harus memenuhi empat kriteria. (1) Tujuan harus cukup spesifik untuk memberikan arahan yang jelas, sehingga pengembang, pelanggan, dan penguji dapat memahaminya. Tujuan harus mengarah pada hasil dan mencerminkan apa yang harus dilakukan oleh sistem, tetapi tidak menguraikan bagaimana cara mengimplementasikan solusi. (2) Sasaran harus dapat diukur, dikuantifikasi, dan diverifikasi. Proyek perlu memantau keberhasilan sistem dalam mencapai setiap tujuan. (3) Sasaran harus agresif namun dapat dicapai, menantang namun dapat dijangkau, dan target harus realistis. Tujuan “Untuk Ditentukan” (TBD) dapat dimasukkan sampai studi perdagangan dilakukan, konsep operasi dimantapkan, atau teknologi menjadi matang. Tujuan harus dapat dilaksanakan sebelum persyaratan ditulis dan sistem dirancang. (4) Tujuan harus berorientasi pada hasil yang berfokus pada keluaran dan hasil yang diinginkan, bukan pada metode yang digunakan untuk mencapai target (apa, bukan bagaimana). Penting untuk selalu diingat bahwa tujuan bukanlah persyaratan. Tujuan diidentifikasi selama pengembangan pra-Fase A dan membantu perumusan persyaratan yang akhirnya ditetapkan, tetapi persyaratan itu sendiri yang mengikat secara kontraktual dan akan diverifikasi terhadap desain sistem “as-built”.

Harapan para pemangku kepentingan ini ditangkap dan dianggap sebagai awal hingga dapat disempurnakan lebih lanjut melalui pengembangan konsep operasi dan kesepakatan akhir oleh para pemangku kepentingan.

4.1.1.2.4 menetapkan konsep operasi dan strategi dukungan

Setelah ekspektasi awal pemangku kepentingan ditetapkan, pengembangan Konsep Operasi (ConOps) selanjutnya akan memastikan bahwa tim teknis sepenuhnya memahami ekspektasi dan bagaimana mereka dapat dipuaskan oleh produk, dan pemahaman tersebut telah disetujui oleh para pemangku kepentingan. Hal ini dapat mengarah pada penyempurnaan lebih lanjut dari serangkaian ekspektasi pemangku kepentingan awal jika ditemukan kesenjangan atau pernyataan yang ambigu. Skenario dan konsep tentang bagaimana sistem akan berperilaku ini memberikan pemahaman bebas implementasi tentang harapan pemangku kepentingan dengan mendefinisikan apa yang diharapkan tanpa membahas bagaimana (desain) untuk memenuhi kebutuhan. Hal ini menangkap karakteristik perilaku yang dibutuhkan dan cara orang akan berinteraksi dengan sistem. Strategi dukungan mencakup ketentuan untuk fabrikasi, pengujian, penerapan, operasi, keberlanjutan, dan pembuangan.

ConOps adalah komponen penting dalam menangkap harapan pemangku kepentingan dan digunakan dalam mendefinisikan persyaratan dan arsitektur proyek. Hal ini merangsang pengembangan persyaratan dan arsitektur yang terkait dengan elemen pengguna sistem. Ini berfungsi sebagai dasar untuk dokumen definisi berikutnya seperti rencana operasi, rencana peluncuran dan orbit awal, dan buku pedoman operasi, dan memberikan dasar untuk kegiatan perencanaan operasional jangka panjang seperti fasilitas operasional, staf, dan penjadwalan jaringan.

ConOps adalah pendorong penting dalam persyaratan sistem dan oleh karena itu harus dipertimbangkan di awal proses desain sistem. Memikirkan ConOps dan kasus penggunaan sering kali mengungkapkan persyaratan dan fungsi desain yang mungkin terlewatkan. Sebagai contoh, menambahkan persyaratan sistem untuk memungkinkan komunikasi selama fase tertentu dari sebuah misi mungkin memerlukan antena tambahan di lokasi tertentu yang mungkin tidak diperlukan selama misi nominal. ConOps harus mencakup skenario untuk semua situasi operasional yang signifikan, termasuk situasi di luar nominal yang diketahui. Untuk mengembangkan serangkaian skenario yang berguna dan lengkap, kerusakan penting dan situasi operasional mode degradasi harus dipertimbangkan. ConOps juga merupakan alat bantu yang penting untuk mengkarakterisasi tujuan staf siklus hidup dan alokasi fungsi antara manusia dan sistem. Dalam menjalani pencapaian tujuan misi, harus menjadi jelas kapan keputusan perlu dibuat tentang apa yang dikontribusikan oleh operator manusia vs. apa yang menjadi tanggung jawab sistem.

ConOps harus mempertimbangkan semua aspek operasi termasuk operasi nominal dan di luar nominal selama integrasi, pengujian, dan peluncuran hingga pembuangan. Informasi umum yang terkandung dalam ConOps mencakup deskripsi fase utama; jadwal operasi; skenario operasional dan/atau DRM (lihat Gambar 4.1-3 untuk contoh DRM); strategi manajemen kesalahan, deskripsi interaksi manusia dan pelatihan yang diperlukan, strategi komunikasi ujung ke ujung; arsitektur komando dan data; fasilitas operasional; dukungan logistik terintegrasi (pasokan ulang, pemeliharaan, dan perakitan); tingkat staf dan keahlian yang diperlukan; dan peristiwa kritis. Skenario operasional menggambarkan pandangan dinamis dari operasi sistem dan mencakup bagaimana sistem dianggap berfungsi di seluruh berbagai mode dan transisi mode, termasuk interaksi dengan antarmuka eksternal, respons terhadap bahaya dan kesalahan yang diantisipasi, dan selama mitigasi kegagalan. Untuk misi eksplorasi, beberapa DRM membentuk sebuah ConOps. Desain dan analisis kinerja yang mengarah pada persyaratan harus memenuhi semuanya.

_{^{Sumber: nasa.gov gambar 4.1-3 contoh DRM sortie bulan di awal siklus hidup}}

Lampiran S berisi satu garis besar yang memungkinkan untuk mengembangkan ConOps. Bagian-bagian spesifik dari ConOps akan bervariasi tergantung pada ruang lingkup dan tujuan proyek.

Konsep operasi vs konsep operasi

Konsep operasi

Dikembangkan di awal Pra-Fase A oleh tim teknis, menggambarkan konsep tingkat tinggi secara keseluruhan tentang bagaimana sistem akan digunakan untuk memenuhi harapan pemangku kepentingan, biasanya dengan cara yang berurutan. Ini menggambarkan sistem dari perspektif operasional dan membantu memfasilitasi pemahaman tentang tujuan sistem. Ini merangsang pengembangan persyaratan dan arsitektur yang terkait dengan elemen pengguna sistem. Ini berfungsi sebagai dasar untuk dokumen definisi berikutnya dan memberikan dasar untuk kegiatan perencanaan operasional jangka panjang.

Konsep operasi

Deskripsi tentang bagaimana sistem penerbangan dan sistem darat digunakan bersama untuk memastikan bahwa konsep operasi masuk akal. Hal ini dapat mencakup bagaimana data misi yang menarik, seperti data teknik atau ilmiah, diambil, dikembalikan ke Bumi, diproses, disediakan untuk pengguna, dan diarsipkan untuk referensi di masa mendatang. Ini biasanya dikembangkan oleh tim operasional. (Lihat NPR 7120.5.)

4.1.1.2.5 mendefinisikan harapan pemangku kepentingan dalam pernyataan yang dapat diterima

Setelah ConOps dikembangkan, kesenjangan atau ambiguitas telah diselesaikan, dan pemahaman antara tim teknis dan pemangku kepentingan tentang apa yang diharapkan/dimaksudkan untuk sistem/produk telah tercapai, harapan dapat didokumentasikan secara formal. Hal ini sering kali muncul dalam bentuk LSM, kriteria keberhasilan misi, dan pendorong desain. Hal ini dapat dicatat dalam dokumen, spreadsheet, model, atau bentuk lain yang sesuai dengan produk.

Penggerak desain akan sangat bergantung pada ConOps, termasuk lingkungan operasional, orbit, dan persyaratan durasi misi. Untuk misi sains, pendorong desain mencakup, setidaknya, tanggal peluncuran misi, durasi, dan orbit, serta pertimbangan operasional. Jika orbit alternatif harus dipertimbangkan, konsep terpisah diperlukan untuk setiap orbit. Misi eksplorasi harus mempertimbangkan tujuan, durasi, urutan operasional (dan perubahan konfigurasi sistem), interaksi kru, kegiatan pemeliharaan dan perbaikan, pelatihan yang diperlukan, dan kegiatan eksplorasi in-situ yang memungkinkan eksplorasi berhasil.

4.1.1.2.6 menganalisis pernyataan harapan untuk mengukur efektivitas

Kriteria keberhasilan misi mendefinisikan apa yang perlu dicapai oleh misi agar berhasil. Hal ini dapat berupa misi sains, konsep eksplorasi untuk misi eksplorasi manusia, atau tujuan teknologi untuk misi demonstrasi teknologi. Kriteria keberhasilan juga mendefinisikan seberapa baik pengukuran konsep atau kegiatan eksplorasi harus dicapai. Kriteria keberhasilan menangkap harapan pemangku kepentingan dan, bersama dengan persyaratan dan kendala program, digunakan dalam persyaratan tingkat tinggi.

Ukuran Efektivitas (Measures of Effectiveness/MOE) adalah ukuran keberhasilan yang dirancang untuk sesuai dengan pencapaian tujuan sistem sebagaimana didefinisikan oleh harapan pemangku kepentingan. Ukuran-ukuran ini dinyatakan dari sudut pandang pemangku kepentingan dan mewakili kriteria yang harus dipenuhi agar pemangku kepentingan dapat menganggap proyek tersebut berhasil. Dengan demikian, mereka dapat disamakan dengan kriteria keberhasilan misi/proyek. MOE dikembangkan ketika LSM atau dokumentasi ekspektasi pemangku kepentingan lainnya dikembangkan. Informasi tambahan mengenai MOE terdapat di Bagian 6.7.2.4 dari dokumen NASA Expanded Guidance for SE di https://nen.nasa.gov/web/se/doc-repository.

4.1.1.2.7 memvalidasi bahwa pernyataan harapan yang ditetapkan mencerminkan ketertelusuran dua arah

LSM atau dokumentasi ekspektasi pemangku kepentingan lainnya juga harus menangkap sumber ekspektasi. Bergantung pada lokasi dalam lapisan produk, ekspektasi dapat ditelusuri ke LSM atau persyaratan produk lapisan yang lebih tinggi, ke rencana strategis organisasi, atau sumber lainnya. Fungsi dan persyaratan selanjutnya akan ditelusuri ke LSM ini. Penggunaan alat atau model manajemen persyaratan atau aplikasi lain sangat berguna dalam menangkap dan menelusuri harapan dan persyaratan.

4.1.1.2.8 mendapatkan komitmen pemangku kepentingan terhadap kumpulan harapan yang telah divalidasi

Setelah pemangku kepentingan dan tim teknis sepakat dengan ekspektasi pemangku kepentingan yang diungkapkan dan konsep operasi, tanda tangan atau bentuk komitmen lainnya diperoleh. Untuk mendapatkan komitmen ini, tinjauan konsep biasanya dilakukan secara formal atau informal, tergantung pada ruang lingkup dan kompleksitas sistem (lihat Bagian 6.7). Harapan pemangku kepentingan (misalnya LSM), KLH, dan konsep operasi dipresentasikan, didiskusikan, dan disempurnakan seperlunya untuk mencapai kesepakatan akhir. Kesepakatan ini menunjukkan bahwa kedua belah pihak telah berkomitmen untuk pengembangan produk ini.

4.1.1.2.9 harapan pemangku kepentingan dasar

Kumpulan ekspektasi pemangku kepentingan (misalnya, LSM dan KLH) dan konsep operasi yang telah disepakati saat ini telah menjadi dasar. Setiap perubahan lebih lanjut akan diminta untuk melalui proses persetujuan formal atau informal (tergantung pada sifat produk) yang melibatkan pemangku kepentingan dan tim teknis.

4.1.1.2.10 Mengabadikan produk kerja

Selain mengembangkan, mendokumentasikan, dan membuat garis dasar ekspektasi pemangku kepentingan, ConOps dan MOE yang dibahas di atas dan produk kerja lainnya dari proses ini harus dicatat. Hal ini dapat mencakup keputusan-keputusan penting yang dibuat, alasan dan asumsi pendukung keputusan, dan pelajaran yang dipetik dalam melakukan kegiatan ini.

4.1.1.3 Keluaran

Keluaran yang umum untuk menangkap harapan pemangku kepentingan meliputi yang berikut ini:

• Harapan Pemangku Kepentingan yang telah divalidasi: Ini adalah serangkaian harapan yang telah disepakati untuk lapisan produk ini. Mereka biasanya ditangkap dalam bentuk kebutuhan, tujuan, dan sasaran dengan kendala dan asumsi yang diidentifikasi. Harapan tersebut juga dapat berupa model atau bentuk grafis lainnya.
• Konsep operasi: ConOps menjelaskan bagaimana sistem akan dioperasikan selama fase siklus hidup yang akan memenuhi harapan pemangku kepentingan. Hal ini menggambarkan karakteristik sistem dari perspektif operasional dan membantu memfasilitasi pemahaman tentang tujuan dan sasaran sistem serta ekspektasi pemangku kepentingan lainnya. Contohnya adalah dokumen ConOps, model, atau Design Reference Mission (DRM).
• Mengaktifkan strategi dukungan produk: Ini mencakup ketentuan khusus yang mungkin diperlukan untuk fabrikasi, pengujian, penerapan, keberlanjutan operasi, dan pembuangan produk akhir. Strategi ini mengidentifikasi dukungan apa saja yang diperlukan dan produk pendukung apa saja yang perlu dikembangkan untuk menghasilkan produk akhir.
• Ukuran efektivitas: Satu set MOE dikembangkan berdasarkan ekspektasi pemangku kepentingan. Ini adalah ukuran yang mewakili harapan yang sangat penting bagi keberhasilan sistem, dan kegagalan untuk memenuhi ukuran ini akan menyebabkan pemangku kepentingan menganggap sistem tersebut tidak dapat diterima.

Output lain yang mungkin dihasilkan:

• Alokasi fungsi manusia atau sistem: Ini menggambarkan interaksi sistem perangkat keras dan perangkat lunak dengan seluruh personel dan infrastruktur pendukungnya. Dalam banyak desain (misalnya penerbangan manusia ke luar angkasa), operator manusia merupakan komponen keseluruhan sistem yang penting dan peran serta tanggung jawab manusia dalam sistem harus dipahami dengan jelas. Hal ini harus mencakup semua interaksi manusia/sistem yang diperlukan untuk suatu misi termasuk perakitan, operasi darat, logistik, pemeliharaan dalam penerbangan dan darat, operasi dalam penerbangan, dll.

Disadur dari: nasa.gov

4.2 definisi persyaratan teknis

Catatan: Penting untuk diperhatikan bahwa tim tidak boleh hanya mengandalkan persyaratan yang diterima untuk merancang dan membangun sistem. Komunikasi dan pengulangan dengan pemangku kepentingan yang relevan sangat penting untuk memastikan pemahaman bersama tentang setiap persyaratan. Jika tidak, para perancang akan menghadapi risiko kesalahpahaman dan mengimplementasikan solusi yang tidak diinginkan untuk interpretasi yang berbeda dari persyaratan. Komunikasi pemangku kepentingan yang berulang ini merupakan bagian yang sangat penting dalam validasi proyek. Selalu pastikan bahwa produk dan hasil yang tepat sedang dikembangkan.

Proses Definisi Persyaratan Teknis mengubah ekspektasi pemangku kepentingan menjadi definisi masalah dan kemudian menjadi satu set lengkap persyaratan teknis tervalidasi yang dinyatakan sebagai pernyataan “harus” yang dapat digunakan untuk mendefinisikan solusi desain untuk Struktur Perincian Produk (PBS) dan produk pendukung terkait. Proses definisi persyaratan adalah proses rekursif dan berulang yang mengembangkan persyaratan pemangku kepentingan, persyaratan produk, dan persyaratan produk/komponen tingkat yang lebih rendah. Persyaratan harus memungkinkan deskripsi semua input, output, dan hubungan yang diperlukan antara input dan output, termasuk batasan, dan interaksi sistem dengan operator, pengelola, dan sistem lainnya. Dokumen persyaratan mengatur dan mengkomunikasikan persyaratan kepada pelanggan dan pemangku kepentingan lainnya serta komunitas teknis.

Kegiatan definisi persyaratan teknis berlaku untuk definisi semua persyaratan teknis dari tingkat program, proyek, dan sistem hingga ke dokumen persyaratan produk/komponen tingkat terendah.

4.2.1 deskripsi proses

Gambar 4.2-1 memberikan diagram alir tipikal untuk Proses Definisi Persyaratan Teknis dan mengidentifikasi input, output, dan aktivitas tipikal yang perlu dipertimbangkan dalam menangani definisi persyaratan teknis.

^{_{Sumber: nasa.gov gambar 4.2-1 proses definisi persyaratan teknis}}

4.2.1.1 Masukan

Masukan umum yang diperlukan untuk proses persyaratan meliputi hal-hal berikut:

• Harapan pemangku kepentingan dasar: Ini adalah serangkaian harapan pemangku kepentingan yang telah disepakati (misalnya, kebutuhan, tujuan, sasaran, asumsi, kendala, antarmuka eksternal) untuk produk dari lapisan produk ini.
• Konsep dasar operasi: Ini menjelaskan bagaimana sistem akan dioperasikan selama fase siklus hidup untuk memenuhi harapan pemangku kepentingan. Hal ini menggambarkan karakteristik sistem dari perspektif operasional dan membantu memfasilitasi pemahaman tentang tujuan, sasaran, dan batasan sistem. Ini mencakup skenario, kasus penggunaan, dan/atau Design Reference Missions (DRM) yang sesuai untuk proyek tersebut. Hal ini dapat berupa dokumen, grafik, video, model, dan/atau simulasi.
• Strategi dukungan pendukung dasar: Hal ini menjelaskan produk pendukung yang diidentifikasi dalam Proses Definisi Harapan Pemangku Kepentingan yang diperlukan untuk mengembangkan, menguji, memproduksi, mengoperasikan, atau membuang produk akhir. Strategi ini juga mencakup deskripsi tentang bagaimana produk akhir akan didukung sepanjang siklus hidup.
• Ukuran efektivitas: MOE ini diidentifikasi selama Proses Definisi Harapan Pemangku Kepentingan sebagai ukuran yang dianggap perlu dipenuhi oleh para pemangku kepentingan agar proyek dapat dianggap sukses (yaitu, untuk memenuhi kriteria keberhasilan).

Masukan lain yang mungkin berguna dalam menentukan persyaratan teknis:

• Alokasi Fungsi Manusia/Sistem: Hal ini menjelaskan interaksi sistem perangkat keras dan perangkat lunak dengan semua personil dan infrastruktur pendukungnya. Ketika operator manusia merupakan komponen sistem total yang penting, peran dan tanggung jawab manusia di dalam sistem harus dipahami dengan jelas. Hal ini harus mencakup semua interaksi manusia/sistem yang diperlukan untuk sebuah misi termasuk perakitan, operasi di darat, logistik, pemeliharaan di dalam dan di darat, operasi di dalam pesawat, dll.

4.2.1.2 kegiatan proses

4.2.1.2.1 Mendefinisikan Kendala, Harapan Fungsional dan Perilaku

Persyaratan dan ekspektasi tingkat atas pada awalnya dinilai untuk memahami masalah teknis yang harus dipecahkan (ruang lingkup masalah) dan menetapkan batas desain. Batasan ini biasanya ditetapkan dengan melakukan aktivitas berikut:

• Mendefinisikan batasan yang harus dipatuhi oleh desain atau yang membatasi bagaimana sistem akan digunakan. Batasan ini biasanya tidak dapat diubah berdasarkan analisis trade-off.
• Mengidentifikasi elemen-elemen yang sudah berada di bawah kendali desain dan tidak dapat diubah. Hal ini membantu menentukan area-area di mana pertukaran lebih lanjut akan dilakukan untuk mempersempit solusi desain potensial.
• Mengidentifikasi sistem eksternal dan pendukung yang harus berinteraksi dengan sistem dan menetapkan antarmuka fisik dan fungsional (misalnya, mekanik, listrik, termal, manusia, dll.).
• Mendefinisikan ekspektasi fungsional dan perilaku untuk berbagai penggunaan sistem yang diantisipasi seperti yang diidentifikasi dalam ConOps. ConOps menjelaskan bagaimana sistem akan dioperasikan dan skenario kasus penggunaan yang mungkin terjadi.

4.2.1.2.2 mendefinisikan persyaratan

Satu set lengkap persyaratan proyek mencakup persyaratan yang diuraikan dan dialokasikan ke elemen desain melalui PBS dan persyaratan yang melintasi batas-batas produk. Persyaratan yang dialokasikan ke PBS dapat berupa persyaratan fungsional (fungsi apa yang perlu dilakukan), persyaratan kinerja (seberapa baik fungsi-fungsi ini harus dilakukan), dan persyaratan antarmuka (persyaratan interaksi produk ke produk). Persyaratan lintas sektoral termasuk lingkungan, keselamatan, faktor manusia, dan yang berasal dari “-kemampuan” dan dari standar Desain dan Konstruksi (D&C). Gambar 4.2-2 adalah gambaran umum tentang aliran persyaratan, apa namanya, dan siapa yang bertanggung jawab (memiliki) untuk menyetujui pengabaian.

^{_{Sumber: nasa.gov gambar 4.2-2 aliran, jenis dan kepemilikan persyaratan}}

• Persyaratan fungsional mendefinisikan fungsi apa yang perlu dilakukan untuk mencapai tujuan.
• Persyaratan kinerja mendefinisikan seberapa baik sistem harus menjalankan fungsi-fungsi tersebut.

Dengan pemahaman menyeluruh tentang batasan, antarmuka fisik/fungsional, dan ekspektasi fungsional/perilaku, persyaratan dapat didefinisikan lebih lanjut dengan menetapkan kinerja dan kriteria teknis lainnya. Kinerja yang diharapkan dinyatakan sebagai ukuran kuantitatif untuk menunjukkan seberapa baik setiap fungsi produk harus dicapai.

Catatan: Persyaratan dapat dihasilkan dari pemangku kepentingan yang tidak jelas dan mungkin tidak secara langsung mendukung misi saat ini dan tujuannya, tetapi memberikan peluang untuk mendapatkan manfaat atau informasi tambahan yang dapat mendukung Agensi atau Negara. Di awal proses, perekayasa sistem dapat membantu mengidentifikasi area potensial di mana sistem dapat digunakan untuk mengumpulkan informasi unik yang tidak terkait langsung dengan misi utama. Seringkali kelompok luar tidak menyadari tujuan dan kemampuan sistem hingga hampir terlambat dalam prosesnya.

Persyaratan teknis berasal dari sejumlah sumber termasuk fungsional, kinerja, antarmuka, lingkungan, keselamatan, antarmuka manusia, standar dan untuk mendukung “kemampuan” seperti keandalan, keberlanjutan, kemampuan produksi, dan lainnya. Pertimbangan dan penyertaan semua jenis persyaratan diperlukan untuk membentuk seperangkat persyaratan teknis yang lengkap dan konsisten yang darinya sistem akan diarsiteki dan dirancang. Gambar 4.2-3 menunjukkan contoh dari alur kebutuhan induk dan anak.

Pernyataan fungsi awal

Pengendali Vektor Dorong (TVC) harus menyediakan kontrol kendaraan tentang sumbu pitch dan yaw.

Pernyataan ini menjelaskan fungsi tingkat tinggi yang harus dilakukan oleh TVC. Tim teknis perlu mengubah pernyataan ini menjadi serangkaian persyaratan desain-ke-fungsional dan kinerja.

Persyaratan fungsional dengan persyaratan kinerja terkait

• TVC harus melakukan gimbal pada mesin maksimal 9 derajat, ± 0,1 derajat.
• TVC harus mengimbangi mesin dengan kecepatan maksimum 5 derajat/detik ± 0,3 derajat/detik.
• TVC harus memberikan kekuatan 40.000 pound, ± 500 pound.
• TVC harus memiliki respons frekuensi 20 Hz, ± 0,1 Hz.

^{_{Sumber: nasa.gov gambar 4.2-3 alur persyaratan}}

4.2.1.2.3 mendefinisikan persyaratan dalam pernyataan yang dapat diterima

Terakhir, persyaratan harus didefinisikan dalam pernyataan “harus” yang dapat diterima, yang merupakan kalimat lengkap dengan satu kata “harus” per pernyataan. Alasan untuk persyaratan juga harus dicantumkan untuk memastikan alasan dan konteks dari persyaratan tersebut dapat dipahami. Persyaratan Pendorong Utama (Key Driving Requirements/KDR) harus diidentifikasi. Ini adalah persyaratan yang dapat berdampak besar pada biaya atau jadwal ketika diimplementasikan. KDR dapat memiliki prioritas atau kekritisan. Mengetahui dampak KDR terhadap desain memungkinkan pengelolaan persyaratan yang lebih baik.

Lihat Lampiran C untuk panduan dan daftar periksa tentang cara menulis persyaratan yang baik dan Lampiran E untuk memvalidasi persyaratan. Dokumen persyaratan yang ditulis dengan baik memberikan beberapa manfaat khusus bagi para pemangku kepentingan dan tim teknis seperti yang ditunjukkan pada Tabel 4.2-1.

Berguna untuk menangkap informasi tentang setiap persyaratan, yang disebut metadata, untuk referensi dan penggunaan di masa mendatang. Banyak alat bantu manajemen kebutuhan akan meminta atau memiliki opsi untuk menyimpan jenis informasi ini. Tabel 4.2-2 memberikan contoh jenis metadata yang mungkin berguna.

^{_{Sumber: nasa.gov}}

Alasan harus selalu diperbarui dan mencakup informasi berikut:

• Alasan untuk Pprsyaratan: Seringkali alasan untuk persyaratan tidak jelas, dan mungkin hilang jika tidak dicatat saat persyaratan didokumentasikan. Alasannya dapat mengarah pada batasan atau konsep operasi. Jika ada persyaratan induk yang jelas atau studi perdagangan yang menjelaskan alasannya, maka itu harus direferensikan.
• Asumsi dokumen: Jika persyaratan ditulis dengan asumsi penyelesaian program pengembangan teknologi atau misi teknologi yang sukses, asumsi tersebut harus didokumentasikan.
• Hubungan dokumen: Hubungan dengan operasi produk yang diharapkan (misalnya, harapan tentang bagaimana pemangku kepentingan akan menggunakan produk) harus didokumentasikan. Hal ini dapat dilakukan dengan menghubungkannya dengan ConOps.
• Kendala desain dokumen: Kendala yang dikenakan oleh hasil dari keputusan yang dibuat saat desain berkembang harus didokumentasikan. Jika persyaratan menyatakan metode implementasi, alasannya harus menyatakan mengapa keputusan dibuat untuk membatasi solusi pada satu metode implementasi.

4.2.1.2.4 memvalidasi persyaratan teknis

Bagian penting dari definisi persyaratan adalah validasi persyaratan terhadap harapan pemangku kepentingan, tujuan dan kendala misi, konsep operasi, dan kriteria keberhasilan misi. Memvalidasi persyaratan dapat dibagi menjadi enam langkah:

1. Apakah Persyaratan Ditulis dengan Benar? Mengidentifikasi dan memperbaiki kesalahan format pernyataan “harus” dan kesalahan editorial.
2. Apakah Persyaratan Secara Teknis Sudah Benar? Beberapa peninjau terlatih dari tim teknis mengidentifikasi dan menghapus sebanyak mungkin kesalahan teknis sebelum meminta semua pemangku kepentingan yang relevan untuk meninjau persyaratan. Peninjau harus memeriksa bahwa pernyataan persyaratan (a) memiliki penelusuran dua arah ke ekspektasi pemangku kepentingan yang telah ditetapkan; (b) dibentuk dengan menggunakan asumsi yang valid; dan (c) sangat penting dan konsisten dengan merancang dan mewujudkan bentuk solusi produk yang sesuai yang akan memenuhi kriteria keberhasilan fase siklus hidup produk yang berlaku.
3. Apakah Persyaratan Memuaskan Pemangku Kepentingan? Semua kelompok pemangku kepentingan yang relevan mengidentifikasi dan menghilangkan cacat.
4. Apakah Persyaratan Dapat Dilaksanakan? Semua persyaratan harus masuk akal secara teknis dan memungkinkan untuk dicapai.
5. Apakah Persyaratan Dapat Diverifikasi? Semua persyaratan harus dinyatakan dengan cara dan dengan informasi yang cukup sehingga memungkinkan untuk memverifikasi persyaratan setelah produk akhir diimplementasikan.
6. Apakah Persyaratannya Berlebihan atau Terlalu Spesifik? Semua persyaratan harus unik (tidak redundan dengan persyaratan lain) dan diperlukan untuk memenuhi fungsi, kinerja, atau perilaku yang diperlukan.

Hasil validasi persyaratan sering kali menjadi faktor penentu apakah akan melanjutkan ke proses berikutnya yaitu Logical Decomposition atau Design Solution Definition. Tim proyek harus siap untuk:

1. Menunjukkan bahwa persyaratan proyek sudah lengkap dan dapat dimengerti;
2. Menunjukkan bahwa kriteria evaluasi konsisten dengan persyaratan dan konsep operasi dan logistik;
3. Mengkonfirmasi bahwa persyaratan dan MOE konsisten dengan kebutuhan pemangku kepentingan;
4. Menunjukkan bahwa konsep operasi dan arsitektur mendukung kebutuhan misi, tujuan, sasaran, asumsi, pedoman, dan kendala; dan Menunjukkan bahwa proses untuk mengelola perubahan persyaratan telah dibuat, didokumentasikan dalam repositori informasi proyek, dan dikomunikasikan kepada para pemangku kepentingan.

4.2.1.2.5 mendefinisikan MOP dan TPM

Ukuran Kinerja (Measures of Performance/MOPs) mendefinisikan karakteristik kinerja yang harus ditunjukkan oleh sistem ketika digunakan dan dioperasikan di lingkungan yang dimaksudkan. MOPs berasal dari MOE tetapi dinyatakan dalam istilah yang lebih teknis dari sudut pandang pemasok. Biasanya, beberapa MOP, yang bersifat kuantitatif dan terukur, diperlukan untuk memenuhi MOE, yang dapat bersifat kualitatif. Dari sudut pandang verifikasi dan penerimaan, MOP mencerminkan karakteristik sistem yang dianggap perlu untuk mencapai MOE.

Ukuran Kinerja Teknis (TPM) adalah karakteristik fisik atau fungsional dari sistem yang terkait dengan atau ditetapkan dari MOP yang dianggap penting atau kunci keberhasilan misi. TPM dipantau selama implementasi dengan membandingkan pencapaian aktual saat ini atau estimasi terbaik dari parameter dengan nilai-nilai yang diantisipasi untuk waktu saat ini dan diproyeksikan untuk tanggal di masa depan. TPM digunakan untuk mengonfirmasi kemajuan dan mengidentifikasi kekurangan yang dapat membahayakan pemenuhan persyaratan sistem yang kritis atau menempatkan proyek pada risiko biaya atau jadwal.

4.2.1.2.6 menetapkan dasar persyaratan teknis

Setelah persyaratan teknis diidentifikasi dan divalidasi sebagai persyaratan yang baik (jelas, benar, lengkap, dan dapat dicapai), dan persetujuan telah diperoleh oleh pelanggan dan pemangku kepentingan utama, persyaratan tersebut dibuat berdasarkan garis dasar dan ditempatkan di bawah kendali konfigurasi. Biasanya, Tinjauan Persyaratan Sistem (System Requirements Review/SRR) diadakan untuk memberikan komentar pada setiap perubahan yang diperlukan dan untuk mendapatkan kesepakatan pada serangkaian persyaratan sehingga dapat di-baseline. Untuk informasi tambahan tentang SRR, lihat Bagian 6.7.

4.2.1.2.7 menangkap produk kerja

Produk kerja yang dihasilkan selama kegiatan di atas harus dicatat bersama dengan keputusan-keputusan penting yang dibuat, alasan dan asumsi pendukung keputusan, dan pelajaran yang dipetik dalam melakukan kegiatan ini.

4.2.1.3 keluaran

• Persyaratan Teknis yang divalidasi: Ini adalah serangkaian persyaratan yang disetujui yang mewakili deskripsi lengkap dari masalah yang harus diselesaikan dan persyaratan yang telah divalidasi dan disetujui oleh pelanggan dan pemangku kepentingan. Contoh dokumen yang menangkap persyaratan adalah Dokumen Persyaratan Sistem (SRD), Dokumen Persyaratan Proyek (PRD), Dokumen Persyaratan Antarmuka (IRD), dan Spesifikasi Persyaratan Perangkat Lunak (SRS).
• Ukuran Kinerja: Ini adalah ukuran kuantitatif yang teridentifikasi yang, ketika dipenuhi oleh solusi desain, membantu memastikan bahwa satu atau lebih MOP akan terpenuhi. Mungkin ada dua atau lebih MOP untuk setiap MOE.
• Ukuran Kinerja Teknis: Ini adalah serangkaian ukuran kinerja yang dipantau dan menjadi tren dengan membandingkan pencapaian aktual saat ini dari parameter dengan yang diharapkan atau diperlukan pada saat itu. TPM digunakan untuk mengonfirmasi kemajuan dan mengidentifikasi kekurangan.

Disadur dari: nasa.gov

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.

Teori karakteristik pekerjaan adalah sebuah teori desain pekerjaan. Teori ini menyediakan “seperangkat prinsip-prinsip penerapan untuk memperkaya pekerjaan dalam pengaturan organisasi. Versi asli teori karakteristik pekerjaan mengusulkan sebuah model lima karakteristik pekerjaan “inti” (yaitu variasi keterampilan, identitas tugas, signifikansi tugas, otonomi, dan umpan balik) yang memengaruhi lima hasil yang berhubungan dengan pekerjaan (yaitu motivasi, kepuasan, kinerja, dan ketidakhadiran dan perputaran) melalui tiga kondisi psikologis (yaitu kebermaknaan yang dialami, tanggung jawab yang dialami, dan pengetahuan tentang hasil).

Sejarah

Desain ulang pekerjaan pertama kali dimulai pada tahun 1960-an. Hingga saat itu, sikap yang berlaku adalah bahwa pekerjaan harus disederhanakan untuk memaksimalkan produksi, namun ditemukan bahwa ketika mengalami tugas yang sangat rutin dan berulang, manfaat penyederhanaan terkadang hilang karena ketidakpuasan pekerja. Diusulkan bahwa pekerjaan harus diperkaya dengan cara-cara yang dapat meningkatkan motivasi, bukan hanya disederhanakan menjadi serangkaian tugas yang berulang-ulang.[3] Dari sudut pandang inilah Teori Karakteristik Pekerjaan muncul.

Pada tahun 1975, Greg R. Oldham dan J. Richard Hackma membuat versi asli dari Job Characteristics Theory (JCT), yang didasarkan pada karya sebelumnya oleh Turner dan Lawrence dan Hackman dan Lawler. Turner dan Lawrence, memberikan dasar karakteristik objektif dari pekerjaan dalam desain pekerjaan. Lebih lanjut, Hackman dan Lawler mengindikasikan efek langsung dari karakteristik pekerjaan terhadap sikap dan perilaku terkait pekerjaan karyawan dan, yang lebih penting lagi, perbedaan individu dalam kebutuhan untuk berkembang, yang disebut Growth Need Strength dalam Teori Karakteristik Pekerjaan.

Pada tahun 1980, Hackman dan Oldham mempresentasikan bentuk akhir dari Teori Karakteristik Pekerjaan dalam buku mereka yang berjudul Work Redesign. Perubahan utama yang dilakukan termasuk penambahan dua moderator - Pengetahuan dan Keterampilan serta Kepuasan Konteks, penghapusan hasil kerja berupa ketidakhadiran dan perputaran, dan peningkatan fokus pada Motivasi Kerja Internal. Beberapa variabel hasil kerja juga dihilangkan atau diganti namanya. Konsentrasi dialihkan ke hasil afektif menyusul hasil dari studi empiris yang menunjukkan dukungan yang lemah terhadap hubungan antara kondisi psikologis dan hasil perilaku.

Selain teori tersebut, Oldham dan Hackman juga menciptakan dua instrumen, yaitu Job Diagnostic Survey (JDS) dan Job Rating Form (JRF), untuk menilai konstruk dari teori tersebut. JDS secara langsung mengukur persepsi pemegang jabatan terhadap lima karakteristik pekerjaan inti, kondisi psikologis yang mereka alami, Growth Need Strength (Kekuatan Kebutuhan Bertumbuh), dan hasil. JRF dirancang untuk mendapatkan penilaian dari pengamat eksternal, seperti supervisor atau peneliti, terhadap karakteristik pekerjaan inti.

Variabel-variabel penting

Menurut versi terakhir dari teori ini, lima karakteristik pekerjaan inti akan mendorong tiga kondisi psikologis yang kritis, yang akan menghasilkan banyak hasil pribadi dan pekerjaan yang baik. Moderator Kekuatan Kebutuhan Pertumbuhan, Pengetahuan dan Keterampilan, dan Kepuasan Konteks harus memoderasi hubungan antara karakteristik pekerjaan dan kondisi psikologis, dan kondisi psikologis dan hasil.

Karakteristik pekerjaan inti

• Variasi Keterampilan: Sejauh mana sebuah pekerjaan membutuhkan berbagai aktivitas, yang mengharuskan pekerja untuk mengembangkan berbagai keterampilan dan bakat. Pekerja dapat merasakan lebih banyak kebermaknaan dalam pekerjaan yang membutuhkan beberapa keterampilan dan kemampuan yang berbeda dibandingkan dengan pekerjaan yang bersifat dasar dan rutin.[2]
• Identitas Tugas: Sejauh mana pekerjaan mengharuskan pemegang pekerjaan untuk mengidentifikasi dan menyelesaikan benda kerja dengan hasil yang terlihat. Pekerja akan lebih merasakan kebermaknaan dalam suatu pekerjaan ketika mereka terlibat dalam keseluruhan proses, bukan hanya bertanggung jawab atas sebagian pekerjaan.[2]
• Signifikansi Tugas: Sejauh mana pekerjaan itu memengaruhi kehidupan orang lain. Pengaruhnya dapat berupa pengaruh di dalam organisasi atau di lingkungan eksternal. Karyawan merasa lebih berarti dalam pekerjaan yang secara substansial meningkatkan kesejahteraan psikologis atau fisik orang lain daripada pekerjaan yang hanya memiliki pengaruh terbatas pada orang lain.
• Otonomi: Sejauh mana pekerjaan tersebut memberikan kebebasan, kemandirian, dan keleluasaan yang signifikan bagi karyawan untuk merencanakan pekerjaan dan menentukan prosedur dalam pekerjaan. Untuk pekerjaan dengan tingkat otonomi yang tinggi, hasil pekerjaan bergantung pada upaya, inisiatif, dan keputusan pekerja itu sendiri; bukan pada instruksi dari manajer atau manual prosedur pekerjaan. Dalam kasus seperti itu, pemegang pekerjaan mengalami tanggung jawab pribadi yang lebih besar atas keberhasilan dan kegagalan mereka sendiri di tempat kerja.
• Umpan balik: Sejauh mana pekerja memiliki pengetahuan tentang hasil. Ini adalah informasi yang jelas, spesifik, terperinci, dan dapat ditindaklanjuti tentang efektivitas kinerja pekerjaannya. Ketika pekerja menerima informasi yang jelas dan dapat ditindaklanjuti tentang kinerja pekerjaan mereka, mereka memiliki pengetahuan yang lebih baik secara keseluruhan tentang efek dari aktivitas kerja mereka, dan tindakan spesifik apa yang perlu mereka lakukan (jika ada) untuk meningkatkan produktivitas mereka.

Kondisi psikologis yang kritis

• Kebermaknaan Pekerjaan yang Dialami: Sejauh mana pemegang pekerjaan mengalami pekerjaan sebagai sesuatu yang bermakna secara intrinsik dan dapat menunjukkan nilainya kepada orang lain dan/atau lingkungan eksternal.
• Tanggung Jawab yang Dirasakan atas Hasil Pekerjaan: Sejauh mana pekerja merasa bahwa ia bertanggung jawab dan bertanggung jawab atas hasil pekerjaannya.
• Pengetahuan tentang Hasil Kegiatan Kerja: Sejauh mana pekerja mengetahui seberapa baik kinerjanya.

Hasil

Diadopsi dari penelitian sebelumnya tentang hasil pribadi dan hasil kerja dari teori awal: Motivasi Kerja Internal, Kepuasan Kerja, Ketidakhadiran dan Perputaran, dan Kualitas Kinerja. Namun, revisi tahun 1980 terhadap model awal termasuk menghilangkan ketidakhadiran dan pergantian, dan memecah kinerja menjadi Kualitas Kerja dan Kuantitas Kerja.

Moderator

Kekuatan Kebutuhan Pertumbuhan (Growth Need Strength/GNS): GNS adalah kekuatan dari kebutuhan seseorang akan pencapaian pribadi, pembelajaran, dan pengembangan. Teori ini menyatakan bahwa Growth Need Strength memoderasi hubungan karakteristik pekerjaan inti dan kondisi psikologis, dan hubungan antara kondisi psikologis dan hasil.

• Pengetahuan dan Keterampilan: Tingkat pengetahuan dan keterampilan yang dimiliki pekerja dapat memoderasi hubungan antara mediator dengan karakteristik pekerjaan dan hasil. Untuk pekerjaan yang memotivasi, pengetahuan dan keterampilan yang memadai akan membuat pekerja mengalami kondisi psikologis yang kritis dan hasil yang lebih baik, sementara pengetahuan dan keterampilan yang tidak memadai akan menghambat kondisi psikologis dan menghasilkan hasil yang lebih negatif. Pekerjaan yang tidak memotivasi tidak memungkinkan pekerja untuk mengalami kondisi psikologis sama sekali, sehingga pengetahuan dan keterampilan tidak berpengaruh.
• Kepuasan Konteks: Konteks pekerjaan juga mempengaruhi pengalaman karyawan. Para penulis menyarankan bahwa ketika pekerja merasa puas dengan hal-hal seperti manajer, gaji, rekan kerja, dan keamanan kerja, mereka akan merespons secara lebih positif terhadap pekerjaan yang sangat memotivasi dan kurang positif ketika mereka tidak puas. Alasannya adalah karena mereka harus menggunakan sumber daya yang penuh perhatian untuk menangani konteks pekerjaan yang tidak diinginkan, yang mengalihkan perhatian dari kekayaan yang seharusnya melekat pada pekerjaan tersebut.

Proposisi

Tiga kondisi psikologis kritis dari teori karakteristik pekerjaan (JCT) mengacu pada teori motivasi kognitif dan beberapa penelitian sebelumnya dalam mengidentifikasi keberadaan kondisi psikologis tertentu yang dapat mengarah pada hasil yang baik.[16] [17] [18] JCT memberikan kesempatan untuk menilai secara sistematis hubungan antara kondisi psikologis yang ditemukan sebelumnya ('Kebermaknaan yang Dialami,' Tanggung Jawab yang Dialami, dan Pengetahuan tentang Hasil) dan hasil. Lebih penting lagi, penelitian sebelumnya tentang desain pekerjaan menunjukkan karakteristik pekerjaan dapat memprediksi kinerja individu, tetapi tidak memberikan “mengapa” dan “bagaimana” hubungan ini ada. Teori Karakteristik Pekerjaan mengisi kesenjangan ini dengan membangun jembatan antara karakteristik pekerjaan dan hasil yang berhubungan dengan pekerjaan melalui penggunaan tiga kondisi psikologis yang penting.

Tiga kondisi psikologis, yang juga merupakan inti konseptual dari teori ini, meliputi

1. Kebermaknaan yang Dialami dari Pekerjaan
2. Tanggung Jawab yang Dialami atas Hasil Pekerjaan
3. Pengetahuan tentang Hasil dari Aktivitas Pekerjaan.

Kondisi psikologis ini diteorikan untuk memediasi hubungan antara karakteristik pekerjaan dan hasil yang berhubungan dengan pekerjaan. Menurut teori tersebut, ketiga kondisi psikologis kritis ini merupakan kondisi non-kompensasi, yang berarti pemegang pekerjaan harus mengalami ketiga kondisi psikologis kritis untuk mencapai hasil yang diusulkan dalam model tersebut. Sebagai contoh, ketika pekerja mengalami ketiga kondisi psikologis tersebut, mereka merasa nyaman dengan diri mereka sendiri saat berkinerja baik. Perasaan positif ini, pada gilirannya, memperkuat para pekerja untuk terus berkinerja baik.

Menurut teori tersebut, karakteristik pekerjaan inti tertentu bertanggung jawab atas setiap kondisi psikologis: variasi keterampilan, identitas tugas, dan signifikansi tugas membentuk kebermaknaan yang dialami; otonomi memengaruhi tanggung jawab yang dialami, dan umpan balik berkontribusi pada pengetahuan tentang hasil. Penelitian sebelumnya menemukan bahwa empat karakteristik pekerjaan (otonomi, variasi, identitas, dan umpan balik) dapat meningkatkan kinerja, kepuasan, dan kehadiran pekerja. Signifikansi tugas diperoleh dari pengalaman kerja Greg Oldham sendiri sebagai pekerja di lini perakitan. Meskipun pekerjaannya tidak memberikan variasi tugas atau identitas, dia masih mengalami kebermaknaan melalui kesadaran bahwa orang lain bergantung pada pekerjaannya. Kesadaran ini menyebabkan dimasukkannya signifikansi tugas sebagai karakteristik pekerjaan lain yang akan mempengaruhi kebermaknaan yang dialami dari pekerjaan tersebut. Dengan demikian, teori karakteristik pekerjaan mengusulkan lima karakteristik pekerjaan inti yang dapat memprediksi hasil yang berhubungan dengan pekerjaan.

Ketika sebuah pekerjaan memiliki skor yang tinggi pada lima karakteristik inti, maka akan menghasilkan tiga kondisi psikologis, yang dapat menghasilkan hasil kerja yang positif, seperti motivasi kerja internal yang tinggi, kepuasan yang tinggi terhadap pekerjaan, performa kerja yang berkualitas tinggi, serta tingkat ketidakhadiran dan perputaran karyawan yang rendah. Kecenderungan karakteristik pekerjaan yang tinggi untuk menghasilkan hasil yang positif dapat dirumuskan dengan skor potensi motivasi (MPS). Hackman dan Oldham menjelaskan bahwa MPS adalah indeks dari “sejauh mana sebuah pekerjaan memiliki kedudukan yang tinggi secara keseluruhan pada tingkat motivasi seseorang ... dan, oleh karena itu, cenderung mendorong hasil kerja dan pribadi yang baik”:

Skor potensi memotivasi (MPS) dapat dihitung dengan menggunakan dimensi-dimensi inti yang telah dibahas di atas, sebagai berikut:

\({\displaystyle {\text{MPS}}={\frac {\text{Skill Variety + Task Identity + Task Significance }}{\text{3}}}{\text{ x Autonomy x Feedback}}} \)

Pekerjaan yang memiliki potensi memotivasi yang tinggi harus memiliki setidaknya satu dari tiga faktor yang mengarah pada kebermaknaan yang dialami, dan juga harus memiliki nilai yang tinggi untuk Otonomi dan Umpan Balik.[20] Jika suatu pekerjaan memiliki MPS yang tinggi, model karakteristik pekerjaan memprediksi bahwa motivasi, kinerja, dan kepuasan kerja akan terpengaruh secara positif dan kemungkinan hasil yang negatif, seperti ketidakhadiran dan perputaran, akan berkurang.[20]

Menurut persamaan di atas, nilai yang rendah pada otonomi atau umpan balik secara substansial akan mengganggu MPS suatu pekerjaan, karena otonomi dan umpan balik adalah satu-satunya karakteristik pekerjaan yang diharapkan dapat menumbuhkan tanggung jawab yang berpengalaman dan pengetahuan tentang hasil. Sebaliknya, skor rendah pada salah satu dari tiga karakteristik pekerjaan yang mengarah pada kebermaknaan yang dialami mungkin tidak selalu mengurangi MPS suatu pekerjaan, karena kehadiran yang kuat dari salah satu dari tiga atribut tersebut dapat mengimbangi ketiadaan atribut lainnya.

Faktor perbedaan individu

Menanggapi salah satu kelemahan Teori Motivator-Hygiene, Teori Karakteristik Pekerjaan menambahkan faktor perbedaan individu ke dalam model. Meskipun Herzberg dkk. memperhitungkan pentingnya karakteristik pekerjaan yang memotivasi secara intrinsik dan ekstrinsik, namun tidak ada pertimbangan mengenai perbedaan individu. Pentingnya perbedaan individu telah ditunjukkan oleh penelitian sebelumnya yang menunjukkan bahwa beberapa individu lebih cenderung merespons secara positif terhadap lingkungan pekerjaan yang diperkaya dibandingkan yang lain. Dengan demikian, versi asli teori ini mengajukan karakteristik perbedaan individu, Growth Need Strength (GNS), yang memoderasi pengaruh karakteristik pekerjaan inti terhadap hasil. Pemegang pekerjaan dengan Growth Need Strength yang tinggi harus merespons lebih positif terhadap peluang yang diberikan oleh pekerjaan dengan tingkat tinggi dari lima karakteristik inti dibandingkan dengan pemegang pekerjaan dengan GNS yang rendah.

Teori Manajemen ilmiah Taylor menekankan efisiensi dan produktivitas melalui penyederhanaan tugas dan pembagian kerja.

Teori motivator-higiene

Teori Motivator-Hygiene dari Herzberg dkk, alias Teori Dua Faktor, yang merupakan pengaruh dari Teori Karakteristik Pekerjaan, berusaha meningkatkan motivasi dan kepuasan melalui pengayaan pekerjaan. Teori ini memprediksi perubahan dalam “motivator”, yang bersifat intrinsik terhadap pekerjaan, (seperti pengakuan, kemajuan, dan pencapaian) akan mengarah pada tingkat motivasi dan kepuasan karyawan yang lebih tinggi; sementara “faktor higiene”, yang bersifat ekstrinsik terhadap pekerjaan itu sendiri, (seperti kebijakan perusahaan dan gaji) dapat mengarah pada tingkat ketidakpuasan yang lebih rendah, tetapi tidak akan benar-benar mempengaruhi kepuasan atau motivasi.

Teori sistem sosioteknis

Teori sistem sosioteknis memprediksi peningkatan kepuasan dan produktivitas melalui perancangan pekerjaan yang mengoptimalkan interaksi manusia dan teknologi.

Teori peningkatan kualitas

Teori peningkatan kualitas didasarkan pada gagasan bahwa pekerjaan dapat ditingkatkan melalui analisis dan pengoptimalan proses kerja.

Teori strukturisasi adaptif

Teori strukturisasi adaptif menyediakan cara untuk melihat interaksi antara penggunaan teknologi yang dimaksudkan dan yang sebenarnya dalam sebuah organisasi, dan bagaimana hal itu dapat memengaruhi hasil yang berbeda terkait pekerjaan.

Variasi

Koreksi penilaian terbalik

Idaszak dan Drasgow memberikan versi perbaikan dari Job Diagnostic Survey yang mengoreksi salah satu kesalahan pengukuran pada instrumen. Disebutkan bahwa penilaian terbalik pada beberapa pertanyaan adalah penyebab dari studi yang tidak konsisten dalam melihat faktor-faktor yang terlibat dalam Job Diagnostic Survey. Setelah melakukan analisis faktor, Idaszak dan Drasgow menemukan enam faktor, bukan lima karakteristik yang diusulkan oleh Teori Karakteristik Pekerjaan. Setelah diselidiki lebih lanjut, mereka dapat menunjukkan bahwa faktor keenam terdiri dari item-item dengan kode terbalik. Para penulis menyusun ulang pertanyaan-pertanyaan tersebut, menjalankan analisis lagi, dan menemukan bahwa hal tersebut dapat menghilangkan kesalahan pengukuran.

Model GN-GO

Karena temuan yang tidak konsisten tentang validitas Kekuatan Kebutuhan Pertumbuhan sebagai moderator dari hubungan karakteristik pekerjaan-hasil, Graen, Scandura, dan Graen mengusulkan model GN-GO, yang menambahkan Peluang Pertumbuhan sebagai moderator lain. Mereka menyarankan bahwa tidak ada hubungan positif yang sederhana antara motivasi dan Growth Need Strength, melainkan ada hubungan inkremental (anak tangga) yang mendasari dengan berbagai tingkat Growth Opportunity. Kenaikan Growth Opportunity digambarkan sebagai “peristiwa yang mengubah karakteristik pekerjaan itu sendiri atau pemahaman tentang pekerjaan itu sendiri. Dihipotesiskan bahwa ketika orang-orang yang memiliki Growth Need Strength yang tinggi memenuhi setiap tingkat Growth Opportunity, mereka dapat termotivasi untuk meningkatkan kinerjanya, namun ketika orang-orang yang memiliki Growth Need Strength yang rendah memenuhi kenaikan yang sama, kinerjanya akan tetap sama, atau bahkan menurun. Studi lapangan menemukan lebih banyak dukungan untuk model GN-GO dibandingkan dengan moderasi Growth Need Strength yang asli.

Perluasan karakteristik dan hasil

Humphrey, Nahrgang, dan Morgeson memperluas model asli dengan memasukkan berbagai hasil dan karakteristik pekerjaan. Para penulis membagi set Karakteristik Pekerjaan yang telah direvisi menjadi tiga bagian - Karakteristik Motivasi, Sosial, dan Konteks Pekerjaan; dan hasil dibagi menjadi empat bagian - Perilaku, Sikap, Persepsi Peran, dan Hasil Kesejahteraan. Hasil penelitian menunjukkan hubungan yang kuat antara beberapa karakteristik dan hasil yang diperluas, menunjukkan bahwa ada lebih banyak pilihan untuk memperkaya pekerjaan daripada yang disarankan oleh teori asli.

Kepemilikan psikologis

Mengambil dari penelitian empiris sebelumnya tentang Teori Karakteristik Pekerjaan dan Kepemilikan Psikologis, para peneliti mengembangkan sebuah model yang menggabungkan kedua teori tersebut. Mereka mengganti kondisi psikologis Teori Karakteristik Pekerjaan dengan Kepemilikan Psikologis pekerjaan sebagai mediator antara karakteristik pekerjaan dan hasil. Selain hasil pribadi dan pekerjaan yang positif dari Teori Karakteristik Pekerjaan, hasil negatif (misalnya Perilaku Teritorial, Resistensi terhadap Perubahan, dan Beban Tanggung Jawab) juga ditambahkan.

Uji empiris

Sejak awal kemunculannya, Teori Karakteristik Pekerjaan telah diteliti secara ekstensif. Uji empiris pertama dari teori ini berasal dari Hackman dan Oldham sendiri. Para penulis menemukan “reliabilitas konsistensi internal skala dan validitas diskriminan dari item-itemnya sebagai memuaskan. Mereka juga mencoba menilai objektivitas pengukuran dengan meminta para supervisor dan para peneliti mengevaluasi pekerjaan tersebut di samping para pemegang pekerjaan. Lebih penting lagi, para penulis melaporkan bahwa hubungan yang diprediksi oleh model tersebut didukung oleh analisis mereka.

Setelah publikasi ini, lebih dari 200 artikel empiris diterbitkan untuk meneliti Teori Karakteristik Pekerjaan selama dekade berikutnya. Fried dan Ferris merangkum penelitian tentang Teori Karakteristik Pekerjaan dan menemukan “dukungan sederhana” secara keseluruhan. Fried dan Ferris menyebutkan tujuh bidang kritik umum dalam ulasan mereka, yang dibahas di bawah ini:

Hubungan antara karakteristik pekerjaan yang objektif dan yang dirasakan: Ada tidaknya akurasi dalam persepsi pekerja terhadap karakteristik pekerjaan merupakan topik penting yang menjadi perhatian Teori Karakteristik Pekerjaan. Penilaian yang tidak akurat terhadap lima karakteristik pekerjaan dapat merugikan proses pengayaan pekerjaan karena Survei Diagnostik Pekerjaan, yang berperan penting dalam menentukan pengayaan apa yang perlu dilakukan, bergantung pada persepsi pemegang pekerjaan.

Kekuatan yang berpengaruh pada persepsi pekerjaan: Isyarat sosial, faktor pribadi, dan urutan bagian dari Survei Diagnostik Pekerjaan yang diberikan dapat memengaruhi persepsi pekerjaan. Isyarat-isyarat yang tidak relevan” ini dapat mewarnai persepsi seseorang terhadap karakteristik pekerjaan.

Hubungan karakteristik pekerjaan yang dipersepsikan versus karakteristik pekerjaan yang objektif-hasil: Para peneliti juga mengkhawatirkan objektivitas penilaian pemegang jabatan terhadap karakteristik pekerjaan dan hasil kerja, namun penelitian cenderung menunjukkan bahwa kekhawatiran ini sebagian besar tidak berdasar.

• Faktor-faktor survei diagnostik pekerjaan: Dukungan terhadap lima dimensi karakteristik pekerjaan dalam Teori Karakteristik Pekerjaan memiliki dukungan yang beragam di antara penelitian-penelitian yang menguji solusi faktor dari Job Diagnostic Survey.
• Hubungan karakteristik pekerjaan-hasil: Para peneliti berpendapat bahwa karakteristik pekerjaan memiliki hubungan yang lebih kuat dengan hasil pribadi, dibandingkan dengan hasil pekerjaan. Lebih penting lagi, ditemukan bahwa Motivating Potential Score tidak seprediktif menjumlahkan penilaian penilai terhadap lima karakteristik pekerjaan.
• Efek mediator dari kondisi psikologis yang kritis: Para peneliti telah menemukan dukungan untuk peran mediasi kondisi psikologis antara karakteristik pekerjaan dan hasil pribadi, namun tidak menemukan bukti yang sama untuk mediasi pada hasil pekerjaan.
• Penggunaan Growth Need Strength sebagai moderator: Ada beberapa penelitian yang menyelidiki validitas Growth Need Strength sebagai moderator. Banyak dari penelitian tersebut melaporkan bahwa efek moderasi dari Growth Need Strength adalah rendah.

Perkembangan baru

Selama bertahun-tahun sejak Teori Karakteristik Pekerjaan diperkenalkan ke dalam literatur organisasi, telah terjadi banyak perubahan dalam bidang ini dan dalam pekerjaan itu sendiri. Oldham dan Hackman menyarankan bahwa area yang lebih bermanfaat untuk pengembangan dalam desain pekerjaan adalah motivasi sosial, pembuatan pekerjaan, dan tim.[3]

Sumber motivasi sosial menjadi lebih penting karena perubahan sifat pekerjaan di negara ini. Semakin banyak pekerjaan yang membutuhkan tingkat interaksi yang lebih tinggi antara klien dan karyawan, serta meningkatkan saling ketergantungan di antara karyawan. Dengan pemikiran ini, masuk akal untuk menyelidiki pengaruh aspek sosial terhadap hasil afektif dan perilaku.

Sementara Teori Karakteristik Pekerjaan terutama difokuskan pada tanggung jawab organisasi untuk memanipulasi karakteristik pekerjaan untuk memperkaya pekerjaan, telah ada banyak diskusi dalam literatur mengenai job crafting. Dalam job crafting, karyawan memiliki kendali atas peran mereka dalam organisasi. Hackman dan Oldham menunjukkan bahwa ada banyak cara untuk menyelidiki tentang job crafting seperti: apa saja manfaat dari job crafting, apakah manfaatnya karena proses job crafting itu sendiri atau perubahan aktual yang dilakukan pada pekerjaan, dan apa saja dampak negatif dari job crafting?

Terakhir, mereka mengemukakan arah penelitian potensial yang relevan dengan desain kerja tim. Secara khusus, mereka mendiskusikan kebutuhan untuk memahami kapan harus menggunakan desain pekerjaan yang ditujukan pada tingkat individu atau tim untuk meningkatkan kinerja, dan tipe tim seperti apa yang paling sesuai untuk tugas-tugas tertentu.

Implikasi praktis

Teori Karakteristik Pekerjaan tertanam kuat dalam literatur desain pekerjaan (juga disebut pengayaan pekerjaan), apalagi teori ini telah menjadi salah satu yang paling banyak dikutip di seluruh bidang perilaku organisasi. Secara praktis, Teori Karakteristik Pekerjaan memberikan kerangka kerja untuk meningkatkan motivasi, kepuasan, dan kinerja karyawan melalui pengayaan karakteristik pekerjaan.

Teori Karakteristik Pekerjaan telah dianut oleh para peneliti dan digunakan di banyak profesi dan organisasi. Dalam domain terapan, Hackman dan Oldham telah melaporkan bahwa sejumlah perusahaan konsultan telah menggunakan model mereka atau memodifikasinya untuk memenuhi kebutuhan mereka.

Saat ini, sangat abstrak untuk membayangkan penerapan sistem perangkat keras atau perangkat lunak yang berfungsi penuh tanpa menjalani proses desain yang ekstensif dan menyeluruh. Desain sistem adalah proses mengkonseptualisasikan, mendefinisikan, dan menggambarkan berbagai modul, komponen, dan unit sistem atau produk baru. Proses desain sistem yang komprehensif akan menguraikan segala sesuatu tentang sebuah sistem, mulai dari komponen dan firmware hingga antarmuka perangkat lunak-manusia. Seiring berkembangnya inovasi teknologi, rekayasa desain sistem telah menjadi bidang studi tersendiri. Desain sistem sekarang distandarisasi menjadi disiplin ilmu formal dan insinyur sistem memainkan peran penting dalam sebagian besar organisasi teknik.

Metodologi pengembangan produk

Proses pengembangan sistem menggambarkan aliran aktivitas dan tahapan yang terlibat dalam pengembangan sistem atau produk, mulai dari konseptualisasi hingga komersialisasi. Ada dua metodologi pengembangan sistem yang utama:

• Proses Pengembangan Air Terjun (Langkah demi Langkah)
• Proses Pengembangan Agile (Pergeseran ke Kiri)

Pengembangan air terjun

Untuk waktu yang lama, sistem dan produk sebagian besar dikembangkan dalam urutan berurutan. Dari studi kelayakan, implementasi, hingga pengujian. Langkah-langkah tersebut sering kali diikuti dengan urutan yang ketat, meninggalkan pengujian produk hingga akhir pengembangan. Hal ini dikenal sebagai proses pengembangan waterfall. Proses ini menggambarkan rangkaian peristiwa yang tak tergoyahkan dengan kekakuan yang tinggi dan sedikit ruang untuk pengujian cepat.

Karena proses waterfall, banyak organisasi akan memulai pengembangan produk dan tidak pernah melihatnya sampai akhir, karena beberapa kesalahan dan bug terlalu rumit dan praktis tidak dapat diperbaiki pada saat terdeteksi. Selain itu, proses ini hanya menyisakan sedikit ruang untuk inovasi dan peningkatan konsep yang berkelanjutan.

Saat ini, proses pengembangan waterfall dapat berguna untuk proyek-proyek idealis dengan sedikit atau tanpa kerumitan. Namun, untuk sistem yang rumit dan masif, menjadi tidak mungkin untuk mengembangkan produk tanpa secara berulang-ulang memeriksa keberhasilan dengan tugas-tugas yang lebih kecil dan mengembangkannya dari sana.

Pengembangan agile - gerakan bergeser ke kiri

Beberapa dekade yang lalu, para insinyur sistem menemukan pendekatan yang lebih baik yang dikenal sebagai Proses Pengembangan Tangkas, yang juga disebut Gerakan Bergeser ke Kiri, di mana pengujian dilakukan berulang kali dan dengan unit-unit kecil di awal proses pengembangan. Dengan cara ini, bug dapat ditemukan lebih awal, perbaikan dapat dilakukan tepat waktu, dan anggaran tidak akan membengkak.

Jika dilakukan dengan baik, hal ini memungkinkan para insinyur untuk secara berulang kali mengurangi risiko pengembangan produk dengan memulai dari bagian pengembangan yang paling berisiko ketika biaya untuk mengubahnya rendah, kemampuan untuk mengubahnya tinggi, dan tingkat investasinya masih rendah.

_{^{Sumber: collimator.ai}}

Manfaat bergeser ke kiri dalam desain sistem

Berbeda dengan proses pengembangan waterfall di mana sebagian besar bentuk pengujian ditunda hingga akhir, mengikuti metodologi agile, menggeser ke kiri, dan menguji lebih awal memiliki beberapa manfaat sebagai berikut: 

• Bug diidentifikasi saat unit dikembangkan
• Kesalahan diselesaikan secara efektif sebelum menyebar ke bagian lain dari sistem
• Fitur baru dapat diperkenalkan kemudian tanpa membahayakan produk inti
• Menghindari kejutan di menit-menit terakhir pada jadwal dan menyederhanakan verifikasi dan validasi
• Memungkinkan pengembang membuat produk dan sistem yang solid, berkualitas tinggi, dan stabil

Proses pengembangan produk

Umumnya, produk terdiri dari beberapa sistem yang perlu dirancang, diuji, dan divalidasi sebelum diluncurkan. Untuk mempermudah, kami akan mengelompokkan semua sistem ke dalam dua kategori besar: perangkat keras dan perangkat lunak. CATATAN: untuk tujuan tulisan ini, kami menyertakan pengembangan firmware sebagai bagian dari perangkat lunak, bukan perangkat keras. Hal ini biasanya bervariasi dari satu perusahaan ke perusahaan lainnya.

Proses desain produk dimulai dengan cara yang sama untuk semua komponen sistem dengan konsep produk dan studi kelayakan, tetapi bercabang agar sesuai dengan kebutuhan proses desain masing-masing sistem. Kemudian bergabung kembali bersama dengan peluncuran prototipe yang berfungsi penuh yang secara iteratif ditingkatkan hingga siap untuk memasuki proses peluncuran produk.

_{^{Sumber: collimator.ai}}

Konsep produk

Konsep produk adalah tanda kehidupan pertama untuk sebuah produk yang dimaksudkan. Konsep produk adalah ide atau inovasi yang ingin Anda kembangkan. Konsep ini mencakup tujuan dari produk baru, gambaran umum tentang produk tersebut, dan analisis masalah pengguna yang ingin dipecahkan.

Dalam beberapa kasus, ini juga dapat mencakup hal-hal seperti sketsa kasar atau konsep pikiran dari desain yang diinginkan, ukuran pasar, analisis pesaing dan posisi, dan analisis desain.

Analisis kelayakan

Lebih dikenal sebagai studi kelayakan, analisis kelayakan menguraikan kebutuhan pengguna atau masalah yang akan diselesaikan oleh produk yang dimaksud secara lebih rinci. Tujuan utamanya adalah untuk menentukan di mana area utama yang tidak pasti dan apakah kebutuhan pengguna dapat dipenuhi dengan cara yang hemat biaya.

Untuk sistem yang rumit seperti yang ditemukan di sektor otomotif, kedirgantaraan dan pertahanan, serta energi, studi kelayakan dan analisis ketidakpastian dilakukan dengan membuat model virtual dengan ketelitian rendah dari sistem yang perlu dibuat. Model ini akan menampilkan cara kerja sistem dan menunjukkan antarmuka yang perlu dikembangkan di antara sistem yang berbeda. Ketika model sudah siap, model tersebut akan disimulasikan dalam ratusan atau ribuan kali percobaan untuk memvariasikan parameter yang data pengujiannya belum tersedia. 

Dokumentasi desain sistem kemudian akan diperbarui dengan hasil yang mencakup peluang keberhasilan, kriteria penerimaan, dan area risiko utama. Tergantung pada tingkat kesiapan teknologi (TRL) dari sistem yang sedang dikembangkan, kriteria untuk masuk ke tahap implementasi akan bervariasi. Sebagai contoh, sebuah pesawat komersial mungkin perlu menunjukkan bahwa ada lebih dari 99% peluang keberhasilan dari simulasi ini, tetapi pesawat hipersonik yang hanya memiliki sedikit data historis yang tersedia mungkin hanya perlu menunjukkan 50% keberhasilan. 

Proses desain sistem

Seperti yang telah disebutkan di atas, dalam blog ini kami akan mengelompokkan proses desain sistem menjadi: 

• Sistem perangkat keras
• Sistem perangkat lunak (termasuk firmware)

Sistem perangkat keras adalah bagian fisik dari sebuah produk. Sistem ini berisi komponen aktif dan bagian aktif yang bergerak di dalam ruang dari waktu ke waktu. Pengembangan perangkat keras memerlukan pertimbangan berbagai bagian material, elektrik, dan mekanik, yang semuanya diperhitungkan dalam proses desain.

Sistem perangkat lunak adalah kumpulan instruksi, prosedur, dan dokumentasi yang menjalankan berbagai tugas pada sistem komputer. Perangkat lunak terdiri dari perangkat lunak tertanam (juga dikenal sebagai firmware) dan perangkat lunak aplikasi. Perangkat lunak tertanam menyediakan kontrol tingkat rendah untuk perangkat keras spesifik perangkat. Desain perangkat lunak tertanam melibatkan pembuatan fungsi dasar perangkat dan menyediakan layanan untuk perangkat lunak abstraksi tingkat tinggi seperti sistem operasi dan aplikasi. Perangkat lunak aplikasi menjalankan fungsi tertentu secara langsung untuk pengguna akhir atau dalam beberapa kasus, aplikasi lain. Desain perangkat lunak aplikasi melibatkan pembuatan aplikasi perangkat lunak sebagai bagian dari sistem yang lebih besar untuk memenuhi kebutuhan pengguna akhir.

Desain dan implementasi perangkat keras

_{^{Sumber: collimator.ai}} 

Ada tiga komponen penting dalam sistem perangkat keras yang perlu dirancang:

• Komponen listrik
• Komponen mekanis
• Komponen sistem

Berlawanan dengan asumsi umum, proses desain perangkat keras sebenarnya kompleks dan rumit. Sedemikian rumitnya sehingga ada pepatah umum di antara para insinyur perangkat keras yang mengatakan bahwa “perangkat keras itu sulit”. Hal ini karena sistem fisik beroperasi di dunia nyata di mana permutasi yang perlu diperhitungkan tidak terbatas. Akibatnya, proses desain perangkat keras tidak pernah linier dan banyak insinyur perangkat keras akan mengikuti proses standar de-risking yang berulang-ulang.

Insinyur perangkat keras biasanya akan memulai dengan model virtual yang dibuat dalam studi kelayakan dan meningkatkan tingkat ketepatan simulasi secara khusus untuk bagian sistem yang paling berisiko. Mereka akan memastikan bahwa mereka meningkatkan tingkat kesiapan teknologi (TRL) sistem untuk bagian tersebut sebelum beralih ke bagian sistem yang tidak terlalu berisiko. Untuk komponen perangkat keras yang tidak dapat disimulasikan, mereka akan mengembangkan prototipe dengan cepat menggunakan teknologi pencetakan 3D, papan tempat memotong roti, dan komponen sederhana yang tersedia di pasaran untuk mengembangkan prototipe yang berfungsi yang kemudian dapat diuji.

Proses pengurangan risiko berulang dan pergeseran ke kiri ini memungkinkan para insinyur perangkat keras untuk mendapatkan wawasan lebih cepat dan menyelesaikan area ketidakpastian tertinggi sejak dini. Dengan demikian, mengurangi risiko pembengkakan jadwal dan kejutan di menit-menit terakhir.

Komponen listrik

Spesifikasi papan

• Spesifikasi papan adalah proses terperinci yang memberikan informasi tentang semua komponen papan sirkuit pusat yang mengontrol semua aktivitas listrik dan transmisi data. Ini menentukan jenis papan sirkuit tercetak yang tepat untuk dibuat dengan rincian jumlah dan peringkat komponen seperti transistor, kapasitor, resistor, jalur transmisi, pin, chip memori, dan lainnya. Langkah ini sangat penting karena satu kesalahan perhitungan atau kesalahan penentuan jenis peringkat komponen dapat membuat seluruh produk tidak dapat digunakan.

Diagram skematik

• Diagram skematik memberikan gambaran yang jelas tentang interkonektivitas komponen pada papan sirkuit. Ini adalah diagram fungsional yang terdiri dari simbol dan garis listrik yang menunjukkan aliran sinyal dari satu titik ke titik lain di papan. Umumnya dilakukan dengan menggunakan perangkat lunak CAD dan simulasi elektronik, tahap skematik dalam desain sistem digital diperlukan untuk menganalisis jalur aliran data, membuka peluang baru untuk transmisi yang lebih cepat, dan mengidentifikasi kemungkinan redundansi papan.

Tata letak papan

• Tata letak papan sering disalahartikan sebagai diagram skematik, dan meskipun keduanya merupakan representasi grafis, keduanya memiliki tujuan yang sangat berbeda dalam pengembangan perangkat keras. Tata letak papan adalah gambar implementasi fisik dari diagram skematik, tidak harus difokuskan untuk menunjukkan interkonektivitas tetapi pada penempatan fisik komponen. Tata letak papan sangat penting untuk merencanakan posisi komponen dan membuat penyesuaian awal dan konfigurasi ulang.

Fabrikasi PCB

• Ini adalah proses pembuatan atau pembuatan papan sirkuit tercetak. Desain PCB ditranskripsikan dari tata letak dan skema ke papan yang sebenarnya. Komponen dilaminasi ke papan dengan penyolderan yang hati-hati dan sesuai dengan metodologi shift left, komponen-komponen tersebut diuji konduktivitasnya saat dalam perjalanan. PCB tersedia dalam berbagai bentuk: lapisan tunggal, multilayer, lentur, kaku, dan kaku-lentur. Papan ini sangat sensitif dan mudah rusak, sehingga perlu kehati-hatian ekstra selama proses penyolderan untuk menghindari kerusakan pada jalur.

Perakitan papan

• PCB dapat menjadi bagian dari papan yang lebih besar dan dengan demikian, setelah fabrikasi, semua komponen lain dari papan pengendali utama ditempatkan dengan hati-hati dalam urutan tata letak dan disiapkan untuk perakitan desain akhir.

Komponen mekanis

Spesifikasi mekanis

• Komponen mekanis mencakup semua komponen rumah eksternal produk termasuk tombol, casing, penutup komponen, pegangan, roda, dan komponen non-listrik statis atau bergerak lainnya. Titik keputusan besar di sini adalah memutuskan apakah komponen mekanis akan dibeli atau dibuat khusus oleh tim internal. Dengan asumsi suku cadang yang sudah jadi yang dipilih, maka tim dapat langsung melompat ke langkah perakitan mekanis.

Desain berbantuan komputer

• Spesifikasi mekanis dibuat dan diimpor ke dalam perangkat lunak CAD untuk memodelkan semua pengukuran, skala, dan elemen-elemen yang diperlukan dari komponen mekanis. Desain CAD adalah tahap teknis yang tinggi dan memakan banyak waktu dalam tahap desain mekanis. Namun, desainer harus melakukannya dengan benar untuk menghindari komplikasi pada tahap selanjutnya. Setelah selesai, file CAD diteruskan ke fabrikator atau insinyur mesin untuk menghasilkan prototipe komponen mekanis.

Fabrikasi mekanis

• Fabrikator atau insinyur mesin menggunakan printer 3D atau mesin penggilingan industri untuk membangun komponen fisik berdasarkan spesifikasi CAD. Perusahaan biasanya akan menggunakan printer 3D pada tahap awal siklus pengembangan karena printer ini cepat, mudah dibuat, dan sangat fleksibel. Pada tahap pengembangan selanjutnya, mereka biasanya akan menggunakan komponen yang dicetak dengan injeksi karena lebih hemat biaya untuk produksi massal.

Perakitan mekanis

• Ini sering kali menjadi momen kebenaran bagi perancang dan perakit CAD. Akankah komponen-komponen tersebut cocok satu sama lain saat selubung dan penutup mekanis dirakit? Apakah proses perakitannya akan mudah, tidak berbelit-belit, dan dapat diandalkan? Akankah perakitan akhir mudah diperiksa? Selama tahap perakitan desain ini, para insinyur merakit komponen mekanis, sering kali menganalisis prosesnya dengan saksama dengan mata yang tajam untuk perbaikan.

Komponen sistem

Spesifikasi sistem

• Di sinilah setiap komponen lain atau bahan tugas berat didaftarkan untuk tahap yang akan datang. Semua komponen listrik dan mekanik yang akan digunakan dalam desain, khususnya dengan peringkat, ukuran, jumlah, dan bahkan merek pemasok yang disukai ditentukan dalam tahap ini. Bill of Material dibuat dan digunakan untuk memperkirakan margin kotor dari produk baru dan perbaikan yang dilakukan jika diperlukan untuk memastikan bahwa produk baru tersebut akan menguntungkan.

Perakitan sistem

• Pada tahap ini, unit mekanis dan elektrik yang terpisah sepenuhnya dibangun dan diuji fungsionalitasnya, seluruh sistem perangkat keras kumulatif digabungkan dan diuji lagi. Pada tahap ini, perangkat keras mungkin tidak berfungsi sepenuhnya atau dengan baik tanpa firmware/perangkat lunak pengontrol, tetapi faktor-faktor lain seperti konektivitas, transmisi, gerakan, kekuatan material, dan daya tahan juga diuji.

Desain dan implementasi perangkat lunak

Proses desain perangkat lunak menghasilkan perangkat lunak/firmware tertanam dan aplikasi yang melekat pada perangkat keras untuk menjalankan fungsionalitas yang dibutuhkan. Secara umum, sebagian besar perusahaan mengikuti turunan dari metodologi pengembangan perangkat lunak tangkas. Ini adalah pendekatan berulang untuk pengembangan perangkat lunak yang membantu tim mendapatkan nilai lebih cepat dan lebih andal.

Pendekatan ini melibatkan tim rekayasa perangkat lunak yang memecah hasil yang lebih besar menjadi bagian-bagian yang lebih kecil. Tim akan bekerja dalam langkah-langkah kecil dan bertahap yang disebut “sprint” yang biasanya berlangsung selama satu hingga empat minggu. Tujuan dari setiap sprint adalah untuk menghasilkan versi produk yang berfungsi. Sprint berikutnya akan menambahkan lebih banyak fungsionalitas ke versi yang dikirimkan pada sprint terakhir dan siklus ini akan terus berlanjut hingga produk siap untuk dirilis.

Spesifikasi perangkat lunak

Semua persyaratan pelanggan dan spesifikasi teknis dari sistem perangkat lunak yang dimaksudkan diuraikan pada tahap ini, dalam dokumen yang dikenal sebagai Product Requirements Document (PRD). Hal ini harus dilakukan untuk mendapatkan gambaran yang jelas dan tepat tentang apa yang akan dikembangkan oleh para insinyur perangkat lunak.

Aspek teknis perangkat lunak kemudian diuraikan berdasarkan persyaratan pelanggan. Terjemahan ini biasanya dilakukan oleh insinyur perangkat lunak, didokumentasikan bersama PRD dan diserahkan sebagai Permintaan Komentar (RFC) sebelum implementasi. Spesifikasi perangkat lunak mencakup semua detail kecil dari basis kode, seperti nama dan tanggung jawab sub-sistem tertentu, program, unit, driver perangkat, dan detail antarmuka yang akan digunakan untuk mengendalikan setiap sub-unit.

Bergantung pada jenis sistem, RFC juga dapat berisi hal-hal seperti kompatibilitas dengan sistem operasi yang berbeda, kompatibilitas ke belakang dengan sistem lama, kondisi penerapan, aplikasi prasyarat untuk menjalankan perangkat lunak, dan frekuensi pembaruan.

Arsitektur sistem dan pemilihan sistem operasi

Arsitektur desain sistem perangkat lunak adalah pengorganisasian komponen dan alur kerja yang dimaksudkan dalam sistem. Arsitektur ini menunjukkan bagaimana setiap sub-unit berinteraksi satu sama lain untuk melakukan berbagai tugas dalam sistem. Arsitektur ini juga mempertimbangkan perangkat keras dan komponennya.

Arsitektur ini sering dianggap sebagai “cetak biru sistem perangkat lunak” karena memberikan gambaran umum yang terperinci tentang komponen teknis, operasional, dan jaminan kualitas sistem. Hal ini juga menciptakan abstraksi untuk kemungkinan evolusi perangkat lunak di masa depan.

Setelah arsitektur sistem diuraikan, sistem operasi (OS) dipilih untuk memenuhi spesifikasi teknis.

Pemilihan pengontrol, prosesor, dan periferal

Mikrokontroler dan mikroprosesor bertanggung jawab atas sub-unit tertentu dari sistem dan mengendalikan tugas yang ditentukan. Periferal adalah perangkat penyimpanan internal dan driver perangkat. Jumlahnya bisa berkisar dari hanya beberapa buah hingga puluhan, berdasarkan ukuran dan fungsionalitas sistem.

Selama tahap desain sistem ini, insinyur perangkat lunak akan bekerja sama dengan insinyur perangkat keras untuk secara hati-hati memilih mikroprosesor dan mikrokontroler yang tepat sesuai dengan spesifikasi produk. Mereka biasanya akan mempertimbangkan daya pemrosesan, kebutuhan kecepatan, target efisiensi, waktu kerja yang diperlukan, spesifikasi listrik, di antara persyaratan lainnya untuk membuat pilihan yang tepat.

Pemilihan lingkungan pengembangan terpadu

Umumnya dikenal sebagai IDE, ini adalah platform pengembangan tempat para insinyur akan membuat kode. Insinyur biasanya akan memilih bahasa pemrograman, memilih IDE, menyesuaikannya dengan alat dan ekstensi tambahan, lalu menghubungkannya ke alat CI/CD untuk penerapan guna mempermudah proses desain sistem.

Firmware adalah sekumpulan program komputer dasar dan instruksi tingkat sangat rendah yang mengontrol perilaku inti perangkat keras dan interaksinya dengan perangkat lunak tingkat tinggi lainnya. Firmware biasanya ditulis menggunakan bahasa pemrograman tingkat rendah seperti C, C++, dan C#. IDE yang umum digunakan untuk pengembang firmware antara lain Eclipse, Geany, emacs, dan Visual Studio, serta banyak lagi.

Aplikasi adalah perangkat lunak yang melayani berbagai penggunaan tertentu dengan sendirinya tanpa komponen perangkat keras yang terpasang. Desain aplikasi mencakup pengembangan program front-end (sisi klien) dan back end (sisi server). Secara kolektif, aplikasi front end dan back end disebut “fullstack” dan mereka berkomunikasi satu sama lain melalui API. Perangkat lunak aplikasi biasanya ditulis dalam bahasa pemrograman tingkat tinggi seperti Java, Python, HTML, dan JavaScript. IDE yang umum digunakan oleh pengembang fullstack antara lain Jupyter Notebooks, Adam, Sublime, AWS Cloud9, dan banyak lagi.

Implementasi

Di sinilah sebagian besar waktu yang dihabiskan dalam desain sistem perangkat lunak dihabiskan. Insinyur biasanya akan menulis, menguji, men-debug, dan mengoptimalkan kode mereka pada tahap ini. Ada banyak alat yang dapat membantu termasuk perpustakaan sumber terbuka, repositori kode Github, dan platform kode rendah / tanpa kode.

Insinyur yang membangun sistem tertanam dapat memangkas sebagian besar waktu dan sumber daya yang dihabiskan untuk langkah ini dengan menggunakan alat rekayasa yang kuat dan perangkat lunak desain sistem seperti Collimator. Collimator memungkinkan para insinyur untuk membuat kontrol atau algoritme pemrosesan sinyal dengan cara yang alami dan intuitif menggunakan diagram blok dan secara instan mengubah algoritme tersebut menjadi kode bahasa C standar ANSI berkualitas tinggi yang kemudian dapat digunakan pada sistem tertanam.

Verifikasi dan validasi

Verifikasi adalah proses untuk memastikan bahwa kode bekerja pada sistem atau platform yang dirancang. Menurut prinsip-prinsip desain perangkat lunak, verifikasi hanyalah salah satu bagian dari proses pengujian. Sebuah sistem yang tertanam dapat sepenuhnya bebas dari bug dan masih gagal bekerja pada sistem host. Sebuah aplikasi fullstack bisa saja tidak memiliki kesalahan dan masih tidak dapat berjalan pada sistem operasi yang ditentukan. Oleh karena itu, kode harus melalui langkah pengujian tambahan: validasi.

Validasi memeriksa apakah kinerja sistem secara keseluruhan sesuai dengan spesifikasi yang dibutuhkan. Proses verifikasi dan validasi biasanya akan dimulai dalam lingkungan pengujian sandbox, kemudian diperluas ke sistem host. Sebelum pindah ke tahap produksi, sistem harus melalui proses verifikasi dan validasi yang ekstensif untuk memastikan sistem end-to-end memenuhi persyaratan dan bahwa sistem tersebut aman secara fungsional.

Untuk perusahaan yang mengikuti desain berbasis model (MBD), simulasi in-the-loop digunakan untuk melakukan verifikasi dan validasi sistem perangkat keras dan perangkat lunak. Simulasi MIL, SIL, PIL, HIL, dan manusia/pengemudi dalam loop digunakan secara berurutan untuk memvalidasi hasil model. Sebagai contoh, simulasi MIL akan dijalankan dan hasil yang terekam dibandingkan dengan simulasi SIL. Jika hasilnya berbeda, model atau persyaratan akan dimodifikasi sebelum melanjutkan ke langkah berikutnya. 

Penerapan

Setelah perangkat lunak diselesaikan dan telah melalui proses verifikasi dan validasi yang sesuai, perangkat lunak aplikasi disebarkan ke sistem operasi melalui file yang dapat dieksekusi dan firmware disebarkan ke perangkat keras target yang dapat berupa mikrokontroler, FPGA, atau bahkan PLC.

Untuk mengurangi risiko operasional dan meningkatkan kualitas perangkat lunak bahkan setelah sistem masuk ke produksi, banyak perusahaan memilih untuk terus mengintegrasikan dan terus menggunakan kode baru. Ini berarti bahwa bahkan setelah produksi, tim insinyur memantau fungsi sistem, menentukan perbaikan yang harus dilakukan, kemudian membangun, menguji, dan menggabungkan pembaruan.

Alat rekayasa seperti Collimator dapat digunakan sebagai bagian dari pipeline CI/CD untuk meningkatkan kecepatan pembaruan dan mendapatkan keunggulan kompetitif. Manfaat utama menggunakan Collimator adalah model Anda tetap menjadi satu-satunya sumber kebenaran - bahkan setelah produksi selesai - dan perubahan yang dibuat pada model dapat langsung didorong dan digabungkan ke perangkat atau produk di lapangan.

Proses peluncuran produk

Proses peluncuran produk adalah upaya terkoordinasi untuk membawa produk baru ke pasar. Karena ada begitu banyak bagian yang bergerak, proses ini dapat menimbulkan risiko baru yang tidak terlihat pada produk pada tahap ini. Perencanaan yang matang sangat diperlukan terutama bagi perusahaan yang harus memenuhi persyaratan sertifikasi seperti DO178 dan standar ISO. Empat tahap utama verifikasi dan validasi, mulai dari yang paling awal dan semakin mendekati produksi massal, adalah Prototipe, EVT, DVT, dan PVT.

_{^{Sumber: collimator.ai}} 

Prototipe

Prototipe seharusnya menjadi keputusan “opsional” dalam proses desain sistem, tetapi di dunia nyata, tidak ada insinyur yang akan memproduksi massal suatu produk tanpa membuat prototipe fungsional karena anomali yang tidak terdeteksi dapat menjadi bencana ekonomi dan operasional.

Pembuatan prototipe produk adalah proses pembuatan model kecil atau replika produk target untuk menguji konsep, memeriksa kegunaan di dunia nyata, dan kelayakan produksi massal secara keseluruhan. Perancang sistem akan mengulang beberapa prototipe melalui proses pengembangan dan menggunakan wawasan yang dihasilkan untuk pengujian, verifikasi, jaminan kualitas, dan sebagai dasar untuk perbaikan lebih lanjut. Pembuatan prototipe dapat dilakukan untuk setiap komponen sistem produk: 

• Perangkat keras melalui pencetakan 3D dan komponen listrik/mekanik yang tersedia di pasaran
• Perangkat lunak melalui simulasi sistem

Pembuatan prototipe cepat adalah proses pengembangan tangkas yang memangkas jumlah waktu yang dihabiskan untuk membuat prototipe. Ini adalah metode yang cepat dan umumnya berbiaya rendah untuk mengembangkan versi kerja dari produk atau sistem yang diinginkan. Jika dilakukan dengan baik, prototipe rekayasa dapat diselesaikan dalam hitungan hari tergantung pada ukuran dan kompleksitas sistem. Metode ini memungkinkan para desainer dan insinyur untuk secara berulang-ulang membuat tiruan antarmuka dan memvalidasinya dengan pelanggan sehingga mengurangi risiko pengembangan.

Pengujian validasi teknik (EVT)

Tahap Pengujian Validasi Teknik (EVT) adalah proses untuk mengonfirmasi bahwa semua sub-unit desain prototipe bekerja sesuai dengan persyaratan. Ini adalah tahap yang sangat penting dalam desain dan analisis sistem karena EVT akan dinilai “tidak berhasil” jika setidaknya satu persyaratan fungsional dalam Dokumen Persyaratan Produk (PRD) tidak terpenuhi.

Poin-poin yang divalidasi selama EVT dapat mencakup:

• Kapasitas dan penggunaan daya
• Margin EMI
• Toleransi termal
• Pengujian papan listrik
• Pengujian kekuatan mekanis
• Kecepatan transmisi sinyal
• Jika suatu produk gagal dalam tahap EVT, spesifikasi akhir dapat dibuka untuk modifikasi dan perbaikan.

Pengujian validasi desain (DVT)

Fase Pengujian Validasi Desain (DVT) adalah dasar desain sistem yang bertujuan untuk mengonfirmasi integritas desain sesuai dengan spesifikasi dan ekspektasi PRD. Prototipe dikenai tekanan fisik yang nyata agar para perancang memiliki gambaran umum tentang toleransi, margin kekuatan, daya tahan, ketahanan terhadap kondisi lingkungan, dan kesan kegunaan secara umum.

Pengujian DVT mencakup aktivitas seperti merendam ke dalam air untuk memeriksa integritas kedap air, pembakaran dalam intensitas api yang meningkat, dihancurkan oleh cetakan yang berat, dan terpapar pada kondisi alam yang keras. Proses ini memungkinkan modifikasi dilakukan pada desain atau pilihan material jika terdeteksi adanya anomali atau penyimpangan.

Pengujian validasi produksi (PVT)

Fase Pengujian Validasi Produksi (PVT) adalah proses untuk memastikan bahwa produk baru layak untuk produksi massal. Ini adalah pengujian lini produksi dan belum tentu produk itu sendiri sekarang. Jika ada kegagalan batching, ketidaksejajaran mesin, dan hambatan kecil lainnya yang dapat menyebabkan waktu henti selama produksi, maka hal tersebut akan diselesaikan atau diganti sebelum produksi dimulai.

Fase PVT terkadang diabaikan dalam desain sistem karena beberapa insinyur secara otomatis berasumsi bahwa jika EVT dan DVT bagus dan optimal, PVT tidak memiliki alasan untuk gagal. Asumsi ini paling sering terjadi ketika produksi dialihdayakan ke perusahaan lain dan merupakan kesalahan karena efek hilirnya masih dapat merugikan jadwal dan anggaran pengembangan produk baru.

Produksi massal (MP)

Secara tradisional, ini dianggap sebagai bagian akhir dari proses pengembangan produk. Namun, hal ini tidak lagi dianggap benar saat ini. Kemajuan dalam IoT, komputasi awan, dan 5G telah membuka banyak peluang untuk terus meningkatkan sistem, menghadirkan lebih banyak fungsionalitas, pembaruan, dan perbaikan bahkan setelah produk telah memenuhi spesifikasi desain sistem asli dan dalam produksi.

Mengapa memilih collimator untuk desain sistem?

Dunia di sekitar kita saat ini jauh lebih kompleks daripada beberapa tahun yang lalu. Saat ini, sistem di sekitar kita mulai dari sikat gigi hingga mobil mengumpulkan zettabyte data dan mengalirkan data tersebut secara real time ke produsen dan pengguna. 

Alat pengembangan tradisional yang berbasis desktop tidak dapat mencerna dan memproses jumlah data yang diperlukan, apalagi melakukannya secara tepat waktu. Alat-alat yang menjalankan bahasa proprietary telah ketinggalan dengan Python, bahasa pengantar AI, ML, dan Reinforcement Learning. Menjalankan alat bantu tersebut menghasilkan proses pengembangan waterfall yang menunda pembuatan wawasan dan menghasilkan masalah desain yang menghentikan pertunjukan di akhir proses pengembangan yang menyebabkan pembengkakan biaya dan peluncuran yang tertunda.

Oleh karena itu, perusahaan yang ingin sukses dalam jangka panjang dan melindungi keunggulan kompetitif mereka harus berinvestasi dalam alat bantu teknik yang dirancang untuk masalah di masa depan. Mereka harus menggunakan perangkat lunak yang dibangun untuk dunia di mana: 

• Data besar digunakan untuk memvalidasi setiap keputusan desain
• AI dan ML digunakan dalam desain DAN pengoperasian sistem
• Orang dapat merancang sistem yang kompleks tanpa harus memiliki gelar ilmu komputer
• Tim dapat berkolaborasi secara real time dengan pelanggan dan pemasok mereka

Collimator menyediakan lingkungan terpadu untuk mendesain, mensimulasikan, menguji, dan terus meningkatkan pengontrol tertanam di dunia di mana data besar dan AI/ML digunakan untuk meningkatkan desain sistem, mengurangi risiko pengembangan, dan membawa produk ke pasar lebih cepat. Coba Collimator hari ini untuk: 

• Merancang sistem Anda menggunakan UI grafis atau Python Notebook
• Menganalisis sistem Anda menggunakan toolkit terintegrasi dan blok fungsi yang dapat digunakan kembali
• Menggunakan AI dan ML secara langsung dalam model Anda untuk mensimulasikan kinerja sistem secara menyeluruh
• Memanggil pustaka dan model Python sumber terbuka eksternal secara langsung di dalam model Anda
• Jalankan jutaan kasus uji menggunakan HPC di cloud sebelum menerapkannya ke pengontrol
• Membandingkan operasi dunia nyata dengan operasi virtual secara real-time, terus menerus

Disadur dari: collimator.ai

Jika Anda memiliki pekerjaan yang sangat bagus, atau pekerjaan yang buruk - bagaimana perasaan Anda terhadap pekerjaan tersebut? Aspek apa dari pekerjaan itu yang sangat baik (atau buruk)?

Desain pekerjaan dapat didefinisikan sebagai “isi dari tugas, aktivitas, hubungan, dan tanggung jawab pekerjaan, serta bagaimana tugas, aktivitas, dan tanggung jawab tersebut diorganisir” (Parker, 2014). Desain kerja yang baik memperhatikan karakteristik fisik, biomekanik, kognitif, dan psikososial dari pekerjaan, serta kebutuhan dan kemampuan orang-orang yang terlibat di dalamnya.

Desain pekerjaan dapat digambarkan dengan serangkaian karakteristik pekerjaan yang memengaruhi perasaan orang terhadap pekerjaan mereka - dan seberapa baik kinerjanya. Karakteristik ini membedakan antara apa yang orang gambarkan sebagai pekerjaan yang 'baik' atau 'buruk'. Desain dan pengaturan kerja merupakan aspek kunci dari faktor manusia dan keandalan manusia.

Sebagai contoh, jika Anda ditugaskan untuk menciptakan peran perawat baru di rumah sakit, desain pekerjaan ini dapat dipertimbangkan:

1. Tugas-tugas apa saja yang harus dilakukan oleh orang ini?
2. Bagaimana keseimbangan antara perawatan pasien dan dokumen?
3. Tugas-tugas apa saja yang harus dialokasikan kepada tenaga medis profesional lainnya?
4. Tugas-tugas mana yang harus dialokasikan kepada staf non-medis?
5. Keputusan apa yang harus diambil oleh perawat?
6. Apakah peran ini bekerja sebagai bagian dari tim?
7. Siapa lagi yang harus ada dalam tim ini?
8. Bagaimana pola shift atau daftar jaga untuk perawat ini?
9. Apa saja ukuran kinerja utama untuk peran tersebut?
10. Mengapa desain pekerjaan itu penting?

Kita menghabiskan, rata-rata, 90000 jam dalam hidup kita di tempat kerja sehingga dapat dimengerti bahwa sifat pekerjaan kita dapat memiliki dampak yang signifikan terhadap kesejahteraan kita. Pekerjaan dapat memberikan kita hubungan, kontak sosial, rasa memiliki tujuan, identitas sosial, dan aktivitas rutin yang memberikan struktur dalam hidup kita.

Kesejahteraan mental di tempat kerja 

Desain kerja yang buruk meningkatkan kemungkinan terjadinya masalah kinerja manusia, seperti 'kesalahan manusia'

Desain kerja dapat berdampak besar pada kesehatan, keselamatan, dan kesejahteraan pekerja, serta motivasi dan produktivitas mereka. Hal ini mempengaruhi bagaimana kita merasa dan berperilaku di tempat kerja. “Pekerjaan yang baik” adalah ketika desain atau manajemen pekerjaan mengoptimalkan kinerja manusia, kepuasan kerja, dan produktivitas. Pekerjaan yang baik dapat memberikan dampak positif pada berbagai hasil, namun pekerjaan yang dirancang dengan buruk dapat menyebabkan

• Masalah kesehatan mental
• Gangguan muskulo-skeletal yang berhubungan dengan pekerjaan
• Penyakit kardiovaskular
• Kecelakaan dan cedera
• Kesalahan dan kekeliruan manusia
• Masalah kualitas.

Survei Angkatan Kerja Inggris (2009/10 hingga 2011/12) menemukan bahwa penyebab utama stres, depresi, atau kecemasan yang berkaitan dengan pekerjaan adalah beban kerja, khususnya tenggat waktu yang ketat, terlalu banyak pekerjaan, atau terlalu banyak tekanan atau tanggung jawab. Faktor-faktor lain yang diidentifikasi termasuk kurangnya dukungan manajerial, perubahan organisasi, kekerasan, dan ketidakpastian peran. Ini semua adalah faktor-faktor yang harus kita pertimbangkan ketika merancang atau mendesain ulang pekerjaan.

Jumlah total kasus stres, depresi, atau kecemasan terkait pekerjaan pada tahun 2019/20 adalah 828.000 kasus. Jumlah total hari kerja yang hilang karena kondisi ini pada tahun 2019/20 adalah 17,9 juta hari. Pada tahun 2019/20 - stres, depresi, atau kecemasan menyumbang 51% dari semua kasus kesehatan yang berhubungan dengan pekerjaan dan 55% dari semua hari kerja yang hilang karena kesehatan yang berhubungan dengan pekerjaan.

Sejarah desain pekerjaan

Selama Revolusi Industri pada akhir abad ke-18, terjadi pergeseran radikal dari orang yang bekerja sendiri atau dalam kelompok kecil, menjadi pengembangan pabrik-pabrik besar.

Sayangnya bagi para pekerja, pekerjaan mereka berubah secara drastis. Sebelumnya, mereka mungkin bertanggung jawab untuk membuat produk secara keseluruhan - mulai dari mengatur bahan baku hingga menjual produk mereka. Mereka memiliki kebebasan untuk mengambil keputusan, memiliki beragam tugas, mengembangkan berbagai keterampilan dan memiliki pekerjaan yang berarti di mana mereka dapat melihat hasil kerja mereka.

Di pabrik-pabrik, pekerjaan dibagi menjadi tugas-tugas kecil dan sederhana. Bagaimana tugas-tugas itu harus dilakukan ditentukan dengan sangat rinci, dengan asumsi bahwa ada satu cara terbaik untuk mengatur pekerjaan. Beberapa karyawan ditugaskan untuk melakukan pekerjaan manual (pekerja) dan beberapa lainnya ditugaskan untuk melakukan pekerjaan mental (manajer). Dalam pendekatan ini, para manajer membuat semua keputusan dan para pekerja hanya memiliki sedikit suara. Pendukung yang berpengaruh dalam hal ini adalah Frederick Taylor, yang menciptakan istilah Manajemen Ilmiah, yang kadang-kadang dikenal sebagai Taylorisme. Keuntungan dari Taylorisme termasuk waktu pelatihan yang jauh lebih singkat (karena tugas-tugasnya sangat sempit) dan individu menjadi sangat terampil dalam menyelesaikan tugas-tugas kecil ini dengan cepat.

Pembuatan mobil 

Beberapa tahun kemudian, Henry Ford menciptakan jalur perakitan pertama untuk memproduksi mobil secara massal. Seperti halnya Taylorisme, para pekerja individu di jalur produksi ini menyelesaikan tugas-tugas kecil, dan jalur perakitan menyerahkan tugas tersebut kepada mereka. Pekerjaan-pekerjaan ini sangat berulang, dengan variasi keterampilan yang rendah dan otonomi yang rendah. Sifat dari pekerjaan-pekerjaan ini di pabrik-pabrik dan lini produksi awal akan mempengaruhi kesehatan mental dan fisik para pekerja.

Menyadari bahwa penyederhanaan pekerjaan memiliki dampak negatif terhadap karyawan, sejumlah strategi untuk merancang atau (mendesain ulang) pekerjaan dikembangkan, yang lebih populer diuraikan di bawah ini:

• Rotasi pekerjaan - memindahkan orang di antara tugas-tugas yang berbeda akan meningkatkan variasi keterampilan, yang membuat pekerjaan menjadi lebih menarik. Hal ini juga memberikan pemahaman yang lebih baik kepada karyawan tentang tempat kerja yang lebih luas, yang akan membantu mereka menjadi lebih efektif. Rotasi pekerjaan untuk pekerjaan yang sangat fisik juga dapat digunakan untuk mengurangi risiko gangguan muskuloskeletal yang berhubungan dengan pekerjaan (MSDs), terutama jika otot-otot yang berbeda digunakan dalam berbagai tugas yang membentuk pekerjaan tersebut.
• Perluasan pekerjaan - pekerjaan tersebut mencakup berbagai tugas yang lebih luas, dan memungkinkan pekerja untuk melihat keseluruhan pekerjaan dari awal hingga akhir - yang memberikan identifikasi tugas yang lebih tinggi dan lebih banyak kepuasan kerja. Strategi ini dapat membuat pekerjaan terasa lebih bermakna.

Namun, kedua strategi di atas cukup terbatas, karena hanya menangani satu atau dua karakteristik pekerjaan. Sebagai contoh, keduanya hanya akan berdampak kecil pada tanggung jawab pengambilan keputusan, atau otonomi. Pendekatan-pendekatan berikut ini menawarkan perbaikan:

• Pengayaan pekerjaan memberikan fleksibilitas tambahan dengan berfokus pada peningkatan otonomi karyawan atas perencanaan dan pelaksanaan pekerjaan mereka sendiri. Hal ini memungkinkan karyawan untuk, misalnya, membuat keputusan yang sebelumnya dilakukan oleh supervisor atau manajer. Hal ini dapat meningkatkan variasi keterampilan dan otonomi pekerjaan. Model Karakteristik Pekerjaan mengidentifikasi lima unsur penting untuk pekerjaan yang bermakna, produktif dan sehat: variasi keterampilan, identitas tugas, signifikansi tugas, otonomi dan umpan balik tugas.
• Multiskilling melibatkan individu yang diberi tanggung jawab untuk berbagai tugas yang berbeda dan lebih luas, yang memperluas kompetensi. Strategi ini memungkinkan orang untuk melaksanakan tugas yang sebelumnya dilakukan oleh fungsi lain. Strategi ini dapat menggabungkan perluasan pekerjaan dan pengayaan pekerjaan. Lebih sedikit orang yang terlibat dalam tugas-tugas tersebut, sehingga hal ini mengurangi peluang terjadinya kesalahan komunikasi.
• Tim yang mengelola sendiri - pendekatan ini membawa strategi pengayaan pekerjaan selangkah lebih maju dengan memungkinkan desain ulang sekelompok pekerjaan. Hal ini sering kali melibatkan pengurangan atau penghapusan peran penyelia lini pertama (meskipun mungkin ada koordinator atau pelatih tim) dan tim bertanggung jawab untuk membuat keputusan sehari-hari mereka sendiri. Penekanannya beralih dari orang-orang yang diberitahu apa yang harus dilakukan, menjadi mengelola sendiri apa yang mereka lakukan dan bagaimana mereka melakukannya, dalam tujuan dan batasan yang ditentukan dengan cermat. Kelompok kerja yang otonom ini memiliki tujuan yang sama, misalnya, bekerja sama untuk mendukung klien atau proyek tertentu.

Dalam semua strategi di atas, beberapa langkah harus diambil untuk memastikan keberhasilannya, termasuk - kejelasan peran dan batas-batas tim; batas-batas otonomi yang jelas; definisi yang cermat tentang tugas-tugas tim; penyediaan pelatihan teknis dan non-teknis yang sesuai dan tinjauan yang terencana atas pelaksanaannya.

Model dan kerangka kerja desain kerja

Salah satu model teoritis yang paling berpengaruh dalam desain kerja adalah Model Kontrol-Tuntutan Pekerjaan (Karasek, 1979). Tingkat ketegangan (tuntutan) yang tinggi seperti kecepatan kerja dan tekanan waktu dapat menyebabkan stres kerja atau kelelahan. Rendahnya tingkat kebebasan untuk mengontrol dan mengatur pekerjaan juga memiliki dampak negatif pada kesehatan fisik dan mental. Gagasan utama di balik model ini adalah bahwa tingkat kontrol yang tinggi (yaitu otonomi) sampai batas tertentu dapat bertindak sebagai penyangga dari tuntutan pekerjaan yang tinggi. Tuntutan yang tinggi dapat dirasakan secara positif sebagai 'tantangan', dan bukan sebagai 'stres'.

Model ini telah disempurnakan oleh penelitian terbaru yang menunjukkan bahwa tidak semua tuntutan berdampak buruk bagi karyawan, dan bahwa ada aspek-aspek lain dalam pekerjaan selain kontrol yang dapat membantu karyawan menghadapi tuntutan yang tinggi (seperti dukungan sosial). Hal ini tercermin dalam Model Tuntutan-Sumber Daya Pekerjaan (Bakker & Demerouti, 2007) yang mencakup tuntutan dan sumber daya yang lebih luas, yang dapat diterapkan di banyak industri. (Sumber daya pada dasarnya adalah hal-hal positif dalam pekerjaan yang membantu orang mencapai tujuan mereka).

Health and Safety Executive (HSE) Inggris mengeluarkan serangkaian Standar Manajemen untuk menangani stres terkait pekerjaan. Standar ini dirancang untuk berguna bagi semua organisasi, apa pun ukuran dan jenisnya. Standar Manajemen ini mencakup enam area utama dari desain pekerjaan yang, jika tidak dikelola dengan baik, akan menyebabkan kesehatan dan kesejahteraan yang buruk, produktivitas yang lebih rendah, dan meningkatnya ketidakhadiran karena sakit.

Keenam area desain kerja tersebut adalah sebagai berikut. Faktor-faktor ini tidak selalu berjalan sendiri-sendiri, tetapi sering kali saling berkombinasi, tumpang tindih, atau berinteraksi:

1. Tuntutan: termasuk isu-isu seperti beban kerja, pola kerja dan lingkungan kerja.
2. Kontrol: seberapa banyak orang yang memiliki suara dalam cara mereka melakukan pekerjaan mereka.
3. Dukungan: termasuk dorongan, sponsor dan sumber daya yang disediakan oleh organisasi, manajemen lini dan rekan kerja.
4. Hubungan: termasuk mendorong kerja yang positif untuk menghindari konflik dan menangani perilaku yang tidak dapat diterima.
5. Peran: apakah orang-orang memahami peran mereka dalam organisasi dan apakah organisasi memastikan bahwa mereka tidak memiliki peran yang saling bertentangan.
6. Perubahan: bagaimana perubahan organisasi (besar atau kecil) dikelola dan dikomunikasikan.

Karakteristik desain kerja

Ada sejumlah variabel yang dapat dimodifikasi untuk meningkatkan kinerja manusia di tempat kerja, serta kesejahteraan fisik dan mental. Faktor-faktor ini dikenal sebagai desain kerja atau karakteristik pekerjaan. Ketika Anda memikirkan tentang pekerjaan terbaik Anda (atau pekerjaan terburuk!) di awal artikel ini, kemungkinan besar Anda telah mempertimbangkan beberapa karakteristik ini. Luangkan waktu sejenak untuk memikirkan aspek mana dari pekerjaan tersebut yang penting bagi Anda. Bagi banyak dari kita, sebagian besar hari-hari kita dihabiskan di tempat kerja. Apakah Anda bahagia di tempat di mana Anda menghabiskan sebagian besar hidup Anda? Karakteristik desain kerja seperti apa yang optimal untuk peran Anda?

Karakteristik Desain Pekerjaan

1. Tuntutan pekerjaan mental atau kognitif
2. Tekanan waktu atau kelebihan peran
3. Tuntutan emosional 
4. Tuntutan fisik 
5. Jam kerja yang menantang 
6. Kontrol pekerjaan
7. Dukungan dari orang lain 
8. Hubungan di tempat kerja 
9. Kejelasan peran atau konflik peran
10. Pengakuan dan penghargaan 
11. Keadilan organisasi
12. Manajemen perubahan organisasi 
13. Pekerjaan jarak jauh atau terisolasi
14. Peristiwa kekerasan atau traumatis

Deskripsi dan contoh

1. Pekerjaan yang memerlukan tingkat konsentrasi yang sangat tinggi atau perhatian yang berkelanjutan dalam jangka waktu yang lama, seperti menganalisis informasi terperinci atau membuat keputusan yang rumit. Pekerjaan yang tidak menuntut secara kognitif dapat mencakup tugas-tugas yang monoton, berulang-ulang atau tidak memerlukan banyak perhatian atau konsentrasi.
2. Tekanan waktu yang berlebihan atau beban kerja yang menuntut. Juga ekspektasi berlebihan terhadap pekerja baru atau tugas baru. Tenggat waktu yang tidak masuk akal, atau kurangnya sumber daya.
3. Tugas atau aktivitas yang mengharuskan pekerja menunjukkan emosi palsu seperti kebahagiaan dan antusiasme, bahkan dalam situasi yang membuat frustrasi, stres, atau memicu kemarahan. Pekerjaan yang menuntut secara emosional juga dapat berupa pekerjaan di mana pekerja dihadapkan pada situasi yang menyusahkan secara emosional, sensitif, atau konflik; atau harus menyampaikan kabar buruk
4. Mengharuskan pekerja menggunakan tubuhnya untuk menghasilkan, menahan atau menyerap kekuatan dan gerakan atau mengeluarkan energi tingkat tinggi. Ini termasuk gerakan berulang atau posisi tubuh yang tidak nyaman. Risiko yang timbul dari tuntutan pekerjaan fisik meningkat ketika aktivitas fisik harus diselesaikan dalam jangka waktu yang ketat atau dalam kondisi lingkungan yang sulit.
5. Kerja shift atau jam kerja tidak teratur yang sulit diprediksi. Jenis pekerjaan ini dikaitkan dengan risiko kelelahan yang lebih besar.
6. Melibatkan kemampuan pekerja untuk mempengaruhi apa yang terjadi di lingkungan kerja mereka, serta membuat keputusan tentang bagaimana pekerjaan mereka dilakukan dan tujuan yang ingin mereka capai. Pengendalian pekerjaan dapat mencakup pengendalian terhadap tugas-tugas pekerjaan, lingkungan kerja, tempat pekerjaan dilakukan, cara pelaksanaannya, dan kebebasan dari pengawasan. Dukungan diperlukan untuk melaksanakan tanggung jawab ini
7. Mengacu pada bantuan praktis dan dukungan emosional yang diberikan manajer atau rekan kerja sehari-hari, seperti memberikan informasi dan nasihat, mendukung penyelesaian tugas, pembinaan dan pendampingan, dan membantu memecahkan masalah.
8. Hubungan dengan manajer, rekan kerja, dan bawahan dapat berdampak positif atau negatif terhadap perasaan pekerja. Ambil langkah proaktif untuk mencegah atau meminimalkan konflik sedini mungkin.
9. Kejelasan peran adalah tingkat kepastian mengenai persyaratan peran dan tanggung jawab. Persyaratan, tujuan, dan tanggung jawab yang terus berubah juga dapat mengakibatkan rendahnya kejelasan peran. Kejelasan peran yang rendah dapat menyebabkan kebingungan mengenai aktivitas kerja apa yang harus dilakukan seorang pekerja dan apa yang harus mereka lakukan. Konflik peran terjadi ketika seorang pekerja diminta untuk menjalankan peran yang bertentangan dengan nilai-nilai pribadinya atau ketika tuntutan pekerjaannya tidak sesuai.
10. Pengakuan dan penghargaan mengacu pada pengakuan yang diberikan kepada pekerja yang mengakibatkan meningkatnya perasaan percaya diri, bangga, dan dihargai atas kontribusi pekerjaan. Pengakuan dan penghargaan dari supervisor, manajer, dan rekan kerja dapat berupa dorongan, rasa terima kasih, pujian, dan bentuk penghargaan lainnya, dan tidak perlu melibatkan imbalan finansial.
11. Mengacu pada persepsi pekerja mengenai keadilan di tempat kerja dan mencakup keadilan prosedural dan relasional. Keadilan prosedural berkaitan dengan bagaimana prosedur diterapkan dan keadilan relasional berkaitan dengan tingkat martabat dan rasa hormat yang diberikan kepada pekerja.
12. Manajemen proses perubahan yang buruk seperti perampingan atau relokasi dapat menyebabkan pekerja merasa cemas dan tidak yakin mengenai aspek pekerjaan atau status pekerjaan mereka.
13. Insiden di tempat kerja yang melibatkan paparan terhadap pelecehan, ancaman, atau bahaya nyata yang menyebabkan ketakutan dan kesusahan serta dapat menyebabkan stres dan/atau cedera fisik. Hal ini biasa terjadi di kelompok-kelompok seperti petugas tanggap darurat, layanan bencana dan darurat, layanan pelanggan, dan personel pertahanan.
14. Ini adalah pekerjaan yang terisolasi dari bantuan orang lain karena lokasi, waktu atau sifat pekerjaan yang dilakukan. Bantuan dari orang lain meliputi penyelamatan, bantuan medis, dan layanan darurat.

Bahaya psikososial

Karakteristik desain pekerjaan pada tabel di atas terkadang disebut sebagai bahaya psikososial. Dengan kata lain, karakteristik desain pekerjaan ini berpotensi memberikan dampak buruk terhadap kesejahteraan fisik dan mental seseorang. Hal ini dapat terjadi ketika seorang pekerja merasa bahwa tuntutan pekerjaan mereka melebihi kemampuan atau sumber daya yang mereka miliki untuk mengatasinya. Jika hal ini berkepanjangan dan/atau parah, hal ini dapat menyebabkan cedera psikologis dan fisik.

Pekerja kemungkinan besar akan terpapar pada kombinasi bahaya dan faktor psikososial - beberapa faktor mungkin selalu ada, sementara yang lain hanya terjadi sesekali. Paparan terhadap bahaya dan faktor psikososial dapat berdampak pada kesehatan mental dan fisik melalui stres, ketegangan psikologis, kelelahan kerja, kecemasan, depresi, nyeri dan sakit otot, mudah tersinggung, konsentrasi buruk, dan gangguan tidur.

Video yang dibuat oleh Center for Transformative Work Design ini memberikan pengenalan mengenai desain kerja, mengapa hal tersebut penting, dan dampak dari desain kerja yang buruk.

Keharusan hukum

Desain pekerjaan sudah tertanam dalam kerangka peraturan kesehatan dan keselamatan di banyak negara. Hal ini mungkin merupakan bagian dari tugas umum untuk melindungi kesehatan dan keselamatan pekerja - dan orang lain yang mungkin terkena dampak pekerjaan tersebut. Perhatikan bahwa di sebagian besar peraturan perundang-undangan, kesehatan mengacu pada kesehatan fisik dan mental (psikologis). Di beberapa negara atau negara bagian, mungkin terdapat tugas khusus untuk mengelola risiko terhadap kesehatan dan keselamatan psikologis.

Undang-undang Kesehatan dan Keselamatan di Tempat Kerja dll tahun 1974 adalah undang-undang utama yang mencakup kesehatan dan keselamatan kerja di Inggris Raya. Hal ini memberikan tanggung jawab umum bagi pemberi kerja untuk melakukan apa yang 'dapat dilakukan secara wajar' untuk menjamin kesehatan dan keselamatan (termasuk kesehatan mental).

Undang-undang Kesehatan dan Keselamatan Kerja (WHS) di Australia memiliki tugas serupa. 'Kesehatan' didefinisikan dalam UU WHS sebagai kesehatan fisik dan psikologis. Orang yang Melakukan Usaha atau Usaha (PCBU) memiliki tugas utama berdasarkan UU WHS untuk mengelola risiko yang terkait dengan paparan bahaya yang timbul dari pekerjaan yang dapat mengakibatkan kerugian fisik atau psikologis.

. . tugas utama untuk memastikan, sejauh dapat dilakukan secara wajar, pekerja dan orang lain tidak terkena risiko kesehatan dan keselamatan psikologis yang timbul dari bisnis atau usaha. Tugas ini mengharuskan Anda untuk 'mengelola' risiko terhadap kesehatan dan keselamatan psikologis yang timbul dari bisnis atau usaha dengan menghilangkan paparan terhadap bahaya psikososial sejauh dapat dilakukan secara wajar. Jika menghilangkan risiko tersebut tidak dapat dilakukan secara wajar, Anda harus meminimalkan risiko tersebut sejauh dapat dilakukan secara wajar.

Safe Work Australia telah membuat lembar fakta tentang cara mengatasi risiko kesehatan psikologis berdasarkan Undang-Undang Kesehatan dan Keselamatan Kerja (WHS) (lihat Sumberdaya Lebih Lanjut).

Namun, ada manfaat dari desain pekerjaan yang baik bagi individu dan organisasi selain kepatuhan terhadap persyaratan hukum ini.

Mengidentifikasi bahaya desain pekerjaan

Seringkali, desain pekerjaan hanya dapat dipertimbangkan ketika ada indikasi bahwa ada sesuatu yang tidak beres, seperti tingkat kelelahan yang tinggi, tingginya pergantian orang berbakat, atau seringnya terjadi kecelakaan atau insiden.

Penilaian risiko

Banyak negara telah menetapkan kerangka penilaian risiko sehubungan dengan bahaya fisik. Bahaya desain kerja (atau psikososial) dapat dikelola dengan cara yang sama seperti bahaya fisik. Prosedur penilaian risiko yang serupa dapat digunakan dalam identifikasi dan pengendalian bahaya ini di tempat kerja.

Karakteristik desain pekerjaan yang tidak memadai dapat diidentifikasi dengan:

Daftar karakteristik desain pekerjaan pada tabel di atas dapat digunakan sebagai petunjuk untuk diskusi ini, atau dapat menjadi dasar survei karyawan.

Kesehatan dan Keselamatan Tempat Kerja Queensland (Australia) telah menghasilkan alat penilaian risiko yang dirancang untuk membantu pemberi kerja memenuhi kewajiban hukum mereka untuk mengelola risiko yang terkait dengan cedera psikologis (lihat Sumberdaya Lebih Lanjut). Alat ini memberikan struktur yang berguna untuk penilaian, berdasarkan karakteristik desain pekerjaan pada tabel di atas.

Merancang karya yang baik

Meskipun terdapat banyak penelitian mengenai desain kerja dan bukti mengenai dampak desain kerja yang buruk terhadap kesejahteraan fisik dan mental - serta dampaknya terhadap kinerja manusia - banyak tempat kerja yang tidak memiliki desain kerja yang optimal.

Desain kerja yang baik harus fokus pada seluruh aspek pekerjaan. Pendekatan holistik ini harus memperhatikan karakteristik fisik, biomekanikal, kognitif dan psikologis pekerjaan. Karakteristik ini berhubungan dengan bahaya yang berbeda-beda. Perlu diingat bahwa beberapa bahaya fisik di tempat kerja (seperti tingkat kebisingan yang tinggi) dapat menyebabkan kerugian psikologis.

Desain ulang pekerjaan harus dipertimbangkan ketika diarahkan oleh penilaian risiko, atau setelah terjadinya insiden, nyaris celaka, atau pengaduan. Ketika seseorang kembali bekerja setelah mengalami cedera, mungkin perlu desain ulang pekerjaan untuk mengakomodasi hal ini. Desain ulang pekerjaan juga dapat mengikuti restrukturisasi organisasi.

Model ini, yang dipaparkan oleh Safe Work Australia dalam “Prinsip-Prinsip Perancangan Pekerjaan yang Baik”, merupakan kerangka kerja yang berguna untuk memastikan bahwa semua bahaya dari suatu tugas dipertimbangkan selama perancangan pekerjaan.

Perancangan pekerjaan terkadang membutuhkan trade-off atau kompromi; misalnya, pekerjaan yang baik dari sudut pandang psikososial mungkin tidak ideal dalam hal risiko biomekaniknya. Perubahan teknologi telah mengubah sifat beberapa pekerjaan, misalnya dengan mengurangi tuntutan fisik dan pada saat yang sama meningkatkan tuntutan kognitif. Oleh karena itu, keseimbangan karakteristik yang berbeda dalam kerangka di atas dapat berubah seiring dengan perubahan sifat pekerjaan.

Meskipun model hierarki pengendalian dikembangkan untuk mengatasi bahaya fisik di tempat kerja, model ini juga relevan untuk bahaya psikososial. Perubahan desain pekerjaan dapat meminimalkan risiko dengan mengganti bahaya, mengisolasi bahaya dari manusia, atau menerapkan pengendalian teknis. Di banyak negara, undang-undang mewajibkan hal ini dilakukan sejauh hal tersebut dapat dilakukan secara wajar. Hanya ketika pengendalian substitusi, isolasi dan teknik telah diterapkan untuk meminimalkan risiko barulah pengendalian administratif dapat digunakan (seperti rotasi pekerjaan, pengawasan atau pelatihan - termasuk pelatihan ketahanan).

Pada tabel di bawah ini, saya telah memberikan beberapa contoh pendekatan merancang pekerjaan yang baik untuk setiap karakteristik desain pekerjaan. Ini bukanlah daftar lengkap, lihat dokumen yang diterbitkan oleh Workplace Health and Safety Queensland untuk mengetahui daftar yang lebih lengkap mengenai pengendalian dan cara memitigasi dampak dari karakteristik ini (lihat Sumberdaya Lebih Lanjut). Diadaptasi dari “Mencegah dan mengelola risiko terhadap kesehatan psikologis terkait pekerjaan”, Negara Bagian Queensland 2019.

Karakteristik Desain Pekerjaan

Contoh kontrol desain pekerjaan (ulang)

Karakteristik pekerjaan yang menjadi fokus dalam desain (ulang) pekerjaan akan bergantung pada sifat pekerjaan. Misalnya, orang yang bekerja di call center mungkin mendapat manfaat dari peningkatan kontrol pekerjaan, sedangkan petugas layanan kesehatan mungkin memerlukan peningkatan dukungan emosional. Dengan meninjau konteks yang lebih luas, akan terlihat karakteristik pekerjaan mana yang menjadi kuncinya. Dan ketika mendesain ulang pekerjaan, Anda harus selalu memastikan bahwa Anda tidak menimbulkan bahaya baru secara tidak sengaja.

Ingatlah bahwa kebutuhan setiap orang berbeda-beda, misalnya tidak semua orang menginginkan (atau membutuhkan) desain pekerjaan yang sama. Kepribadian, kemampuan, usia, jenis kelamin, dan tanggung jawab keluarga, dan lain-lain akan membentuk desain pekerjaan yang paling sesuai untuk seorang individu.

Rancang pekerjaan yang anda inginkan: 'pekerjaan kerajinan'

Penciptaan pekerjaan adalah proses kreatif untuk membuat perubahan pada pekerjaan Anda agar lebih menarik dan bermakna. Ada tiga bentuk utama yang dapat dilakukan oleh kerajinan kerja:

Oleh karena itu, penciptaan pekerjaan adalah perubahan fisik dan kognitif yang dilakukan individu dalam tugas atau batasan relasional pekerjaan mereka. Hal ini dapat dilakukan oleh tim, maupun oleh karyawan secara individu. Daripada mencari peran baru di tempat lain, penciptaan lapangan kerja memberdayakan orang untuk menjadikan pekerjaan mereka saat ini lebih menarik dan memuaskan.

Pikirkan karakteristik desain pekerjaan pada tabel di atas - apa yang lebih Anda sukai? Apa yang ingin Anda kurangi? Dengan menggunakan struktur ini untuk mengidentifikasi apa yang perlu diubah, Anda mungkin dapat menyarankan perubahan praktis pada pekerjaan Anda.

Ada banyak pilihan untuk membantu Anda merancang pekerjaan Anda sendiri. Anda bisa menjadi sukarelawan untuk proyek khusus, menjadi mentor internal, mengakui pencapaian orang lain, memperkenalkan diri kepada kolega baru, mencari peluang pembelajaran dan pengembangan, atau sesekali bekerja dari lokasi yang berbeda.

“Tugas kerja dan interaksi yang membentuk hari-hari, pekerjaan, dan, pada akhirnya, kehidupan karyawan adalah bahan mentah yang digunakan karyawan untuk membangun pekerjaan mereka”

Prinsip-prinsip utama

Sumber daya lebih lanjut

Studi kasus: Kerja yang bagus melalui desain yang efektif (19 menit). Video ini menunjukkan bagaimana sepuluh prinsip desain kerja yang baik dapat diterapkan dalam praktik, menggunakan studi kasus industri nyata untuk meningkatkan kesehatan dan keselamatan pekerja serta kinerja bisnis secara keseluruhan.

Prinsip desain kerja yang baik . Buku pegangan kesehatan dan keselamatan kerja. Diterbitkan oleh Safe Work Australia. Buku pegangan ini berisi sepuluh prinsip desain pekerjaan yang baik yang dapat diterapkan untuk membantu mendukung hasil kesehatan dan keselamatan kerja serta produktivitas bisnis yang lebih baik. Prinsip-prinsip ini sengaja dibuat tingkat tinggi dan harus dapat diterapkan secara luas di berbagai bidang bisnis dan tempat kerja.

Mencegah dan mengelola risiko terhadap kesehatan psikologis terkait pekerjaan. Diterbitkan oleh Workplace Health and Safety Queensland, Negara Bagian Queensland, Australia, 2019. Ini adalah sumber praktis yang sangat bagus yang memberikan saran untuk perubahan desain kerja untuk berbagai risiko psikososial (atau desain kerja). Panduan ini juga mencakup pendekatan empat langkah untuk mengelola bahaya-bahaya ini dan garis besar faktor penentu keberhasilan ketika menerapkan pengendalian. Sepenuhnya berlaku untuk semua negara dan industri.

Alat penilaian risiko psikososial . Diterbitkan oleh Kesehatan dan Keselamatan Kerja Queensland. Alat penilaian risiko ini dirancang untuk membantu pemberi kerja memenuhi kewajiban hukum mereka dalam mengelola risiko yang terkait dengan cedera psikologis. Hal ini dirancang untuk digunakan dengan sumber daya di atas, yang berisi serangkaian saran pengendalian risiko untuk faktor risiko desain pekerjaan yang diidentifikasi dalam penilaian risiko.

Mengatasi stres terkait pekerjaan menggunakan pendekatan Standar Manajemen: Buku kerja langkah demi langkah. Diterbitkan oleh Health and Safety Executive (HSE) Inggris, 2019. Buku kerja ini akan membantu organisasi Anda memenuhi kewajiban hukumnya untuk menilai risiko stres terkait pekerjaan bagi karyawannya dan memberikan saran serta panduan praktis tentang cara mengelola stres terkait pekerjaan. Hal ini mempromosikan pendekatan Standar Manajemen untuk mengatasi stres terkait pekerjaan - sebuah pendekatan sistematis untuk menerapkan prosedur organisasi untuk mengelola stres terkait pekerjaan.

Mencegah Cedera Psikologis Berdasarkan Undang-Undang Kesehatan dan Keselamatan Kerja: Lembar Fakta ini memberikan informasi kepada Pelaku Usaha atau Perusahaan (PCBU) dan pekerja tentang cara mengatasi risiko kesehatan psikologis berdasarkan Undang-Undang Kesehatan dan Keselamatan Kerja (K3) untuk memastikan kesehatan, keselamatan dan kesejahteraan semua orang di tempat kerja. Diterbitkan oleh Safe Work Australia, Mei 2014.

Implikasi keselamatan dari tim yang dikelola sendiri, Laporan Teknologi Lepas Pantai OTO 1999/025. Diterbitkan oleh Eksekutif Kesehatan dan Keselamatan Inggris (HSE), 1999. Dokumen ini mengulas literatur mengenai tim kerja yang dikelola sendiri - khususnya untuk mempertimbangkan implikasinya terhadap kesehatan dan keselamatan. Laporan ini menyajikan empat studi kasus tentang organisasi yang telah menerapkan tim swakelola untuk memahami pendorong perubahan, dan mengidentifikasi pembelajaran yang dapat diambil.

Pengembangan model siklus hidup multi-keterampilan, Laporan Penelitian Kontrak 328/2001. Diterbitkan oleh Health and Safety Executive (HSE) Inggris, 2001. Dokumen ini memberikan tinjauan mengenai berbagai jenis multiskilling, dan memberikan contoh bagaimana aspek kesehatan dan keselamatan multiskilling dikelola di sejumlah organisasi. Laporan ini juga mengidentifikasi serangkaian faktor penentu keberhasilan penerapan intervensi multi-keterampilan.

Disadur dari: humanfactors101.com

• Melakukan percakapan dengan pekerja, supervisor, dan spesialis kesehatan dan keselamatan
• Menginspeksi tempat kerja untuk melihat bagaimana pekerjaan dilakukan (misalnya: mencatat adanya kesibukan, penundaan, atau penumpukan pekerjaan)
• Memperhatikan bagaimana orang berinteraksi satu sama lain selama aktivitas kerja
• Meninjau informasi dan catatan yang relevan (misalnya: laporan insiden, klaim kompensasi pekerja, survei staf, keluhan, data ketidakhadiran dan pergantian staf, wawancara keluar)
• Menggunakan kelompok fokus untuk mengumpulkan informasi dari pekerja, supervisor dan manajer.

1. Tuntutan pekerjaan mental atau kognitif
2. Tekanan waktu atau kelebihan peran
3. Tuntutan emosional
4. Tuntutan fisik
5. Jam kerja yang menantang
6. Kontrol pekerjaan
7. Dukungan dari orang lain
8. Hubungan di tempat kerja
9. Kejelasan peran atau konflik peran
10. Pengakuan dan penghargaan
11. Keadilan organisasi
12. Manajemen perubahan organisasi
13. Pekerjaan jarak jauh atau terisolasi
14. Peristiwa kekerasan atau traumatis
15. Berikan lebih banyak waktu untuk tugas-tugas yang sulit atau rumit (terutama bagi pekerja yang belum berpengalaman, atau untuk tugas-tugas baru). Rancang pekerjaan sehingga tugas-tugas kompleks dapat dibagikan oleh anggota tim. Menerapkan sistem untuk mendukung keputusan sulit.
16. Memberi pekerja kendali atas kecepatan pekerjaan mereka. Pantau beban kerja selama periode permintaan puncak, dan rencanakan tingkat staf yang memadai . Terlibat dalam diskusi rutin dengan staf tentang harapan kerja, beban kerja, tuntutan dan instruksi.
17. Daftarkan aktivitas kerja untuk memastikan pekerja tidak diharuskan menghadapi situasi sulit sendirian. Putar tugas untuk mengurangi paparan dan memberikan jeda dari situasi yang menuntut. Berikan pekerja kendali lebih besar atas keputusan yang akan meredakan situasi yang menuntut emosi.
18. Memperbaiki lingkungan kerja fisik (misalnya, mengurangi penanganan manual dan tuntutan fisik lainnya; mengurangi paparan kebisingan; meningkatkan tingkat pencahayaan; memasang penghalang untuk melindungi pekerja dari serangan atau penyakit). Rancang daftar nama dan shift untuk memungkinkan istirahat dan tidur yang cukup.
19. Konsultasikan dengan pekerja saat merancang atau mengubah daftar nama kerja. Secara proaktif mengelola risiko kelelahan . Minimalkan tugas-tugas penting antara pukul 02.00 dan 06.00. Pastikan daftar nama memungkinkan Anda tidur selama 7-8 jam dalam setiap periode 24 jam. Batasi waktu lembur dan jangan biarkan pekerja melebihi shift 12 jam secara rutin.
20. Libatkan pekerja dalam pengambilan keputusan seputar praktik kerja. Menerapkan proses untuk memberi pekerja kendali atas alur kerja, antrian pelanggan, pengambilan tugas, dll. Memberikan kesempatan bagi pekerja untuk mendapatkan masukan tentang cara mereka melakukan pekerjaan, menentukan tujuan kerja dan kerangka waktu.
21. Perjelas siapa pekerja yang bertanggung jawab (baik secara keseluruhan atau untuk tugas tertentu) dan ke mana mereka dapat mencari bantuan. Pastikan supervisor dilatih dalam keterampilan manajemen sumber daya manusia dan pastikan bahwa mereka memiliki waktu dan sumber daya untuk melakukan tugas pengawasan.
22. Identifikasi masalah desain yang mungkin berdampak negatif pada komunikasi tim. Mengembangkan, menerapkan dan menegakkan kode etik. Pastikan semua manajer memiliki keterampilan untuk mengidentifikasi dan mengelola konflik. Atasi konflik di tempat kerja dengan segera. Perjelas aturan tim, dan berikan penghargaan kepada tim.
23. Definisikan dengan jelas peran individu dan tim, tanggung jawab, struktur pelaporan, KPI, dll. Pastikan pekerja memiliki deskripsi posisi saat ini, termasuk tujuan peran, hubungan pelaporan, dan tugas utama. Hindari menjadikan pekerja bertanggung jawab kepada lebih dari satu atasan langsung.
24. Menghargai pekerja atas gagasan dan perilakunya, serta atas kerja kerasnya. Menyediakan supervisor dan pekerja dengan berbagai strategi untuk mengenali orang lain. Pastikan umpan balik diberikan tepat waktu, spesifik, praktis, dan dikaitkan dengan apa, bagaimana, dan mengapa kinerja dilakukan.
25. Menumbuhkan budaya transparansi, keterbukaan, rasa hormat, keadilan dan kesetaraan. Rancang dan terapkan prosedur secara konsisten di seluruh pekerja dan kelompok kerja. Libatkan pekerja dalam pengembangan kebijakan, prosedur, dan pengambilan keputusan. Tetapkan ekspektasi yang jelas dan atasi masalah dengan segera.
26. Pastikan pendekatan sistematis untuk memahami, merencanakan, mengembangkan, menerapkan dan mengevaluasi perubahan organisasi . Menerapkan praktik konsultasi dan keterlibatan yang kuat. Ubah deskripsi pekerjaan agar sesuai dengan tugas dan tugas baru. Tinjau rencana kerja tim dan individu setelah perubahan.
27. Rancang tata letak tempat kerja dengan menyertakan penghalang fisik, CCTV yang dipantau, dan tingkatkan visibilitas. Pastikan sistem komunikasi yang ada sesuai dengan lokasinya. Pastikan pengawasan dan pemantauan pekerja sudah tepat (misalnya, pelacakan, alarm pekerja yang sendirian, masuk/keluar).
28. Rancang lingkungan kerja fisik (misalnya, pertimbangkan keamanan, jarak pandang, pemisahan). Kurangi frustrasi pelanggan melalui desain. Pekerjaan desain harus diselesaikan secara berpasangan atau tim. Tandai file atau amankan akses ke file tersebut, untuk menghindari paparan konten yang menyusahkan.
29. Pembuatan tugas mengacu pada perubahan fisik pada tugas itu sendiri, seperti jumlah tugas yang membentuk suatu pekerjaan, atau urutan pelaksanaannya.
30. Keterampilan kognitif adalah tentang membuat perubahan pada cara Anda berpikir atau menafsirkan tugas-tugas tersebut. Sebagai contoh, seseorang mungkin melihat pekerjaannya sebagai serangkaian bagian yang terpisah atau sebagai keseluruhan yang terintegrasi. Seseorang yang bekerja di perusahaan telekomunikasi dapat mengubah peran mereka dari sekadar melakukan penjualan, menjadi menghubungkan orang-orang dengan seluruh dunia.
31. Kerajinan relasional mengacu pada penerapan kebijaksanaan terhadap orang-orang yang berinteraksi dengan Anda dalam pekerjaan Anda.
32. Bagaimana pekerjaan dirancang dan dikelola akan mempunyai dampak yang signifikan terhadap kinerja manusia.
33. Rancangan pekerjaan harus merupakan proses yang proaktif, bukan hanya ditangani setelah seseorang mengalami kerugian atau kesulitan.
34. Rancangan pekerjaan merupakan bagian penting dari proses penilaian risiko yang harus diikuti oleh pemberi kerja, untuk menghilangkan atau meminimalkan risiko terhadap kesehatan dan keselamatan pekerja.
35. Setiap penilaian pekerjaan, atau perubahan desain pekerjaan, harus melibatkan konsultasi (bukan hanya komunikasi) dengan pihak yang melakukan pekerjaan (ahli tugas).
36. Pertimbangkan sistem dan praktik yang lebih luas yang mendukung desain pekerjaan baru - misalnya, strategi seleksi dan perekrutan, analisis kebutuhan pelatihan, strategi remunerasi.
37. Komitmen kepemimpinan akan menjadi kunci keberhasilan setiap inisiatif untuk meningkatkan desain dan pengorganisasian kerja.

Disadur dari: humanfactors101.com