7 tahap siklus hidup pengembangan produk adalah penciptaan ide, riset pasar, perencanaan, pembuatan prototipe, pengadaan, penetapan harga, dan komersialisasi.

Baik produk berupa komputer canggih atau sabun batangan, kemungkinan besar produk tersebut melalui proses yang panjang mulai dari pengembangan konsep awal hingga peluncuran produk. Secara khusus, produk tersebut melewati siklus hidup pengembangan produk-sebuah proses yang dimulai dengan pembuatan ide dan diakhiri dengan peluncuran ke publik. Berikut ini adalah ikhtisar dari proses pengembangan produk dan faktor-faktor yang dapat mempengaruhinya.

Apa yang dimaksud dengan siklus hidup pengembangan produk?

Siklus hidup pengembangan produk dapat dibagi menjadi tujuh langkah yang melacak bagaimana sebuah produk berubah dari ide menjadi barang komersial yang layak. Dimulai dengan konsep produk awal yang diikuti dengan riset pasar, perencanaan, pembuatan prototipe, pencarian sumber, penilaian biaya dan harga, dan pengenalan komersial.

Siklus hidup pengembangan produk vs. siklus hidup produk

Siklus pengembangan produk adalah pendahulu dari proses yang lebih panjang yang disebut siklus hidup produk. Siklus hidup pengembangan produk mencakup setiap tahap mulai dari pembuatan ide hingga komersialisasi. Siklus hidup produk mengambil tempat di mana siklus pengembangan berakhir, menggambarkan kemajuan produk dari pengenalan ke pasar hingga akhirnya menurun dan bahkan dihentikan.

Siklus hidup produk memiliki empat tahap. Pada tahap perkenalan, produk masuk ke pasar. Pada tahap pertumbuhan, kampanye pemasaran meningkat, basis pelanggan meluas, sumber dan produksi menjadi lebih efisien, dan produk dapat diubah untuk perbaikan. Selanjutnya, pada tahap kedewasaan, produk mencapai pangsa pasar maksimum. Siklus diakhiri dengan tahap penurunan, ketika lini produk dapat berakhir atau dijual ke perusahaan lain. 

7 tahap siklus hidup pengembangan produk

1. Pencetusan ide
2. Riset pasar
3. Perencanaan
4. Pembuatan prototipe
5. Sumber
6. Penetapan biaya dan harga
7. Komersialisasi

Siklus hidup pengembangan produk terjadi dalam tujuh tahap. Setiap tahap pengembangan produk melibatkan tonggak-tonggak tertentu saat produk berkembang dari konsep menjadi barang yang tersedia secara komersial.

Pembuatan ide

Pada tahap ide, tim pengembangan produk mempresentasikan konsep produk. Mereka mungkin mengejar keunggulan kompetitif dengan mengisi kesenjangan di pasar dan memenuhi kebutuhan pelanggan yang tampaknya tidak dapat dipenuhi oleh produk yang sudah ada. Tim produk dapat menggunakan tahap ini untuk mempertimbangkan faktor-faktor pembatas seperti sumber dan biaya produksi, tetapi tahap ini menempatkan konsep di depan dan di tengah. 

Riset pasar

Pada tahap riset pasar, tim pengembangan dan pemasaran mengidentifikasi target audiens untuk penawaran baru. Riset pasar Anda dapat dimulai dengan asumsi tentang apa yang diinginkan oleh calon pelanggan. Anda bisa melanjutkannya dengan pengujian konsep, di mana Anda mempresentasikan ide produk kepada audiens uji coba dan meminta umpan balik dari pelanggan. Tujuannya adalah untuk memastikan bahwa benar-benar ada pasar untuk produk Anda. Perusahaan yang sudah mapan sering kali menargetkan pelanggan yang sudah ada saat meluncurkan produk baru karena pelanggan ini sudah berada dalam saluran penjualan bisnis.

Perencanaan

Pada tahap ini, tim manajemen produk perusahaan meluncurkan peta jalan produk. Hal ini menyelaraskan semua pemangku kepentingan, mulai dari tim desain dan pengembangan hingga tim penjualan dan pemasaran, di sekitar rencana umum untuk membawa produk baru ke pasar. Tim mempertimbangkan strategi pengembangan untuk membuat produk secara efisien dan terjangkau, serta strategi pemasaran untuk menempatkannya di depan jenis pelanggan yang tepat.

Pembuatan prototipe

Siklus pengembangan produk selanjutnya beralih ke pembuatan prototipe dan pengujian produk. Prototipe bisa jadi mahal, tetapi prototipe diperlukan untuk mengevaluasi dan meningkatkan produk Anda sebelum Anda berkomitmen untuk memproduksi dalam skala penuh. Apakah Anda membuat prototipe DIY atau memesannya dari produsen, Anda akan membutuhkan produk yang memiliki fungsionalitas yang cukup untuk meniru penggunaan di dunia nyata. Tahap ini juga melibatkan pengujian produk untuk memastikan keamanan dan kepuasan pelanggan.

Sumber

Setelah Anda memiliki prototipe yang baik, Anda akan mengalihkan fokus Anda ke rantai pasokan: bahan baku, vendor, logistik pengiriman, dan sumber daya yang dibutuhkan untuk membuat produk Anda dalam skala komersial. Tahap ini juga harus mencakup rencana untuk pergudangan dan pengiriman produk jadi Anda. Untuk perusahaan yang lebih besar, logistik rantai pasokan memerlukan tim manajemen proyek khusus.

Penetapan biaya dan harga

Penetapan biaya adalah proses memperkirakan harga pokok penjualan Anda. Ini termasuk biaya seperti bahan baku, peralatan pabrik, dan tenaga kerja. Anda juga akan memperhitungkan biaya logistik pengiriman, penyimpanan, dan impor jika Anda menggunakan produksi di luar negeri. Setelah Anda memperhitungkan biaya sepenuhnya, Anda akan mengembangkan strategi penetapan harga yang memungkinkan Anda menghasilkan uang dalam jangka panjang. 

Salah satu strategi penetapan harga yang umum adalah metode biaya-plus, yang hanya menambahkan persentase tetap di atas biaya. Sebagai alternatif, banyak perusahaan rintisan yang mengandalkan harga yang kompetitif dan secara agresif mendiskon produk mereka untuk mendapatkan pangsa pasar. Hal ini bisa berarti kehilangan uang pada awalnya, tetapi jika perusahaan mencapai pertumbuhan pasar yang diinginkan, pada akhirnya dapat menghasilkan lebih banyak uang melalui volume penjualan yang lebih besar. 

Komersialisasi

Siklus hidup pengembangan produk berujung pada pengenalan produk Anda secara komersial. Pada titik ini, Anda memproduksi barang dalam skala besar. Anda mungkin mengirimkannya ke pengecer atau menjualnya langsung ke konsumen melalui toko e-niaga Anda. Rencana pemasaran Anda sekarang sudah berjalan. Komersialisasi juga meluncurkan Anda ke dalam siklus hidup produk secara penuh-fase perkenalan, fase pertumbuhan, fase kedewasaan, dan fase penurunan-yang menawarkan banyak peluang untuk peningkatan produk, jangkauan pemasaran, dan layanan pelanggan.

Siklus hidup pengembangan produk 7 langkah dari penciptaan ide/ide hingga komersialisasi.

Faktor-faktor apa saja yang dapat mempengaruhi siklus hidup pengembangan produk?

Bahkan tim pengembangan produk yang paling berpengalaman sekalipun dapat keluar dari jalurnya karena faktor luar yang berada di luar kendali mereka. Ini termasuk:

Tanggapan negatif dari pelanggan. Pengujian konsep atau pembuatan prototipe Anda mungkin menunjukkan bahwa pelanggan tidak menyukai produk Anda. Anda harus memutuskan apakah akan melakukan perbaikan atau membatalkan produk.

Keterbatasan rantai pasokan. Anda hanya dapat memproduksi produk dalam skala besar jika Anda memiliki akses ke pasokan bahan baku, peralatan, dan pekerja yang memadai. Tanpa itu, Anda mungkin perlu mengubah desain produk atau menunda produksi.

Masalah pengiriman. Jika Anda mencari barang atau suku cadang dari berbagai wilayah, Anda bergantung pada pengirim. Kegagalan untuk menerima barang tepat waktu dan dengan biaya yang wajar dapat menggagalkan produksi, penjualan, dan pengiriman.

Prioritas yang tidak selaras. Peluncuran produk yang sukses membutuhkan keselarasan antara tim pengembangan dan desain Anda. Produk Anda harus fungsional, menarik secara estetika, dan dibuat dengan target pasar tertentu. Pastikan tim Anda memiliki prioritas yang sama.

Pertanyaan Umum Siklus Hidup Pengembangan Produk

Berapa lama siklus hidup pengembangan produk biasanya berlangsung?

Siklus hidup pengembangan produk dapat berlangsung dari beberapa bulan hingga beberapa tahun. Siklus ini berkembang paling cepat di perusahaan mapan yang membuat perubahan berulang pada produk yang sudah ada dan menjualnya ke basis pelanggan yang serupa. Ini bisa memakan waktu lebih lama jika startup mengembangkan produk dari awal dan tidak memiliki koneksi ke rantai pasokan atau basis pelanggan.

Apakah bisnis biasanya memiliki anggaran dan jadwal yang ditetapkan untuk siklus hidup pengembangan produk?

Ya. Manajer produk menetapkan anggaran dan jadwal untuk setiap tahap siklus pengembangan produk. Dokumen-dokumen ini menyelaraskan semua departemen di sekitar tujuan yang sama dan berbagi harapan.

Apakah siklus hidup pengembangan produk biasanya melibatkan beberapa iterasi pada setiap tahap?

Siklus hidup pengembangan produk dapat melibatkan beberapa iterasi tahap. Misalnya, prototipe awal mungkin gagal mengesankan calon pelanggan, yang berarti tim produk akan mengulangi tahap pembuatan prototipe. Atau, desain produk dapat berubah, yang kemudian mengharuskan pencarian pemasok yang berbeda. Dalam kasus lain, siklus pengembangan produk berjalan dengan lancar, dan tidak ada tahap yang perlu diulang.

Bagaimana umpan balik pelanggan mempengaruhi siklus hidup pengembangan produk?

Umpan balik pelanggan memainkan peran penting dalam siklus hidup pengembangan produk. Setiap fase dari siklus ini didasarkan pada penciptaan produk yang layak yang akan bertahan selama bertahun-tahun di pasar. Jika pelanggan tidak merespons dengan baik terhadap suatu desain, itu menjadi pertanda buruk bagi kesuksesan jangka panjang produk tersebut. Oleh karena itu, perusahaan menanggapi masukan dari pelanggan dengan sangat serius dan menyesuaikan konsep dan prototipe mereka agar sesuai dengan minat pasar.

Apakah penting untuk terus mengevaluasi dan meningkatkan produk setelah diluncurkan?

Ya. Ketika siklus hidup pengembangan produk berakhir, siklus hidup produk baru saja dimulai. Bisnis memantau produk mereka setelah diluncurkan dengan memperhatikan daya tahan dan keamanan. Mereka juga mempertimbangkan umpan balik dari pelanggan, apakah itu saran untuk perbaikan atau kasus penggunaan yang tidak terduga. Dengan terus menyesuaikan produk untuk mengatasi daya tahan, keamanan, fungsionalitas, dan kepuasan pelanggan, perusahaan dapat meningkatkan masa pakai lini produk.

Disadur dari: shopify.com

Peran penting spesifikasi produk dalam pengembangan produk

Pengembangan produk lebih dari sekadar usaha kreatif; itu adalah proses terstruktur yang mengubah ide menjadi solusi yang nyata. Meskipun terdapat gagasan romantisme tentang pendiri jenius yang bekerja sendirian, produk yang sukses muncul dari pendekatan sistematis yang didasarkan pada kebutuhan pelanggan dan wawasan pasar. Mari kita jelajahi kompleksitas pengembangan produk, bahas langkah-langkah kuncinya, dan terangkan penerapannya secara praktis.

Memahami pengembangan produk

Pengembangan produk adalah perjalanan membawa produk ke pasar, mencakup proses ideasi, penciptaan, dan pengiriman. Ini tentang menerjemahkan kebutuhan pelanggan menjadi solusi inovatif dan mengembangkannya secara berulang untuk memenuhi tuntutan yang berkembang. Dengan menetapkan proses yang dapat diulang, tim dapat menavigasi kompleksitas pengembangan produk dengan jelas dan efisien.

Membedakan pengembangan produk dari manajemen produk

Sementara manajemen produk berfokus pada pengawasan seluruh siklus hidup produk, pengembangan produk adalah proses praktis mengubah konsep menjadi kenyataan. Manajer produk bekerja sama dengan berbagai tim, termasuk desain, rekayasa, dan pemasaran, untuk menjalankan visi produk dengan efektif.

Sembilan tahapan pengembangan produk

1. Pembentukan tim: Membangun tim yang kuat dan multidisiplin adalah dasar pengembangan produk yang sukses. Dari manajer produk yang visioner hingga desainer kreatif dan pengembang yang terampil, setiap anggota tim memberikan keahlian unik untuk proses tersebut.
2. Penemuan pelanggan: Memahami kebutuhan dan masalah pelanggan sangat penting dalam membentuk solusi produk. Melalui wawancara mendalam dan pengembangan persona, tim mendapatkan wawasan berharga yang memandu upaya pengembangan produk.
3. Ideasi: Ideasi adalah fase kreatif di mana tim menghasilkan solusi potensial untuk masalah yang diidentifikasi. Dengan menetapkan batasan yang jelas dan memanfaatkan umpan balik pelanggan, tim fokus pada memberikan satu hal dengan sangat baik.
4. Definisi produk: Mendefinisikan produk melibatkan membentuk konsep menjadi tawaran yang nyata, mempertimbangkan faktor seperti bentuk, metode pengiriman, dan pasar target. Penting untuk menghindari memperumit produk pada tahap ini dan tetap fokus pada fungsionalitas inti.
5. Pembuatan prototype: Pembuatan prototipe memungkinkan tim untuk memvalidasi asumsi dan menyempurnakan konsep produk melalui iterasi yang cepat. Memanfaatkan alat seperti pencetakan 3D dan pengembangan kode yang rendah mempercepat proses pembuatan prototipe sambil meminimalkan biaya.
6. Produk minimal yang layak (MVP): MVP mewakili versi paling sederhana dari produk yang mengatasi kebutuhan inti pelanggan. Dengan merilis versi awal kepada pengguna nyata, tim mengumpulkan umpan balik dan melakukan iterasi berdasarkan data penggunaan aktual.
7. Pengujian pengguna: Pengujian pengguna melibatkan pengamatan interaksi pelanggan dengan produk untuk menilai tingkat kepuasan dan mengidentifikasi area yang perlu diperbaiki. Melalui eksperimen yang terkontrol dan perbandingan, tim menyempurnakan produk secara berulang.
8. Peta Jalan Produk: Peta jalan produk memvisualisasikan arah strategis dan tonggak kunci perjalanan produk. Dengan menangkap wawasan dari tahap MVP dan pengujian pengguna, tim memprioritaskan fitur dan inisiatif untuk mendorong pertumbuhan produk.
9. Peluncuran dan literasi: Dengan produk yang telah divalidasi dan peta jalan yang tersedia, tim meluncurkan produk ke pasar. Iterasi berkelanjutan berdasarkan umpan balik pelanggan memastikan peningkatan produk yang berkelanjutan dan relevan.

Contoh pengembangan produk

Setiap produk memiliki kisahnya sendiri yang layak diceritakan. Berikut adalah beberapa contoh yang membantu mengilustrasikan bagaimana menemukan fokus produk, mendengarkan masukan pelanggan, dan memulai kembali ketika hal-hal tidak berjalan seperti yang diharapkan.

1. Instagram: Dengan menonjolkan fitur filter, Instagram menjadi populer di antara aplikasi berbagi foto lainnya.
2. Play-doh: Awalnya produk pembersih, Play-doh menjadi mainan yang sukses setelah menyesuaikan pemasaran mereka.
3. Google+: Meskipun gagal, Google+ membantu Google meluncurkan produk baru seperti Hangouts dan Google Photos yang sukses.

Selama proses ini, Anda akan membuat dokumen, peta jalan, dan item kerja lainnya. Untuk mendukung upaya Anda, Anda memerlukan alat dan sistem manajemen produk yang sefleksibel kreativitas tim Anda. Alat ini harus dapat bekerja sama sehingga Anda dapat dengan lancar bergerak dari penemuan, pembuatan peta jalan, menyelesaikan aliran kerja pertama, dan mendokumentasikan semuanya. 

Bagaimana jira product discovery membantu dalam proses pengembangan produk

Hingga saat ini, bagian paling menantang dari proses ini untuk dikelola adalah alasannya di balik apa yang Anda bangun. Secara tradisional, tugas manajer produk adalah untuk menyampaikan "mengapa" ini, dan menunjukkan bukti arah tim. Jira Product Discovery adalah pusat utama di mana Anda dapat memprioritaskan, berkolaborasi, dan menghasilkan ide-ide produk baru - semuanya di dalam Jira. Ini dirancang untuk membantu Anda mengintegrasikan data dari penemuan pelanggan ke dalam proses pengembangan Anda. Dengan membangun data tersebut, Anda kemudian memprioritaskan peluang Anda, berkomunikasi arah Anda, dan merencanakan pekerjaan ke depan. Cobalah Jira Product Discovery untuk membangun tim Anda dan berkontribusi pada dampak yang positif.

Mengoptimalkan proses pengembangan produk

Untuk memperlancar upaya pengembangan produk, tim mengandalkan alat dan sistem yang fleksibel yang mendukung kolaborasi dan inovasi. Platform seperti Jira Product Discovery menawarkan pusat yang terpusat untuk memprioritaskan ide, merencanakan peta jalan, dan menjalankan workstream dengan lancar, memberdayakan tim untuk membangun produk yang berdampak.

Tujuan spesifikasi produk

Spesifikasi produk berfungsi sebagai panduan atau cetakan biru untuk semua aspek proyek selama proses pengembangan. Ini menyelaraskan tim Anda dengan memberikan:

1. Peran dan tanggung jawab: Daftar anggota tim dan keputusan yang mereka tangani selama siklus pengembangan.
2. Lingkup: Ini adalah daftar fitur dan fungsi, ukuran keberhasilan utama, risiko dan asumsi yang diketahui, serta fitur yang dikecualikan jika sesuai.
3. Desain produk: Mock-up atau prototipe menunjukkan alur kerja, antarmuka pengguna, proses, dan arsitektur tingkat tinggi.
4. Rencana pengujian: Ini menguraikan metode pengujian produk dan penanganan informasi pribadi.
5. Rencana rilis: Ini mencakup kegiatan seperti pelatihan untuk agen layanan, dokumentasi, dan keterlibatan tim bisnis.
6. Manajemen: Ini menguraikan kegiatan manajemen berkelanjutan, seperti membuat peningkatan di masa depan dan mengumpulkan umpan balik.
7. Meskipun anggota tim memiliki elemen spesifikasi produk yang berbeda, semua orang di tim harus setuju. Kolaborasi awal dan sering membuat semua orang selaras.

Mengapa spesifikasi produk penting bagi tim produk?

Setiap proyek pengembangan produk memiliki potensi untuk terjadi ketidakpahaman, perambahan fitur, dan perselisihan. Namun, hal itu tidak harus menjadi kenyataan. Spesifikasi produk yang jelas adalah referensi umum bagi anggota tim produk lintas fungsional dan menguraikan prioritas.

Dengan menyelaraskan semua orang tentang apa yang mereka bangun, mengapa, dan bagaimana mengukur kesuksesan, spesifikasi produk membantu tim mengantisipasi dan mempersiapkan tantangan. Ketika manajer produk, desainer, insinyur, dan pemangku kepentingan lainnya bekerja dengan visi bersama, mereka dapat mengidentifikasi hambatan lebih awal dan meningkatkan kolaborasi serta pengambilan keputusan.

Jira Product Discovery menawarkan tim alat terpusat untuk berpikir dan mengatur ide. Ini membantu mengendalikan kekacauan dalam pembuatan ide dengan data pendukung untuk memprioritaskan fitur yang memberikan dampak terbesar. Data pendukung dapat berasal dari umpan balik pelanggan, tiket layanan, laporan, atau penjualan—di mana pun Anda menemukan masukan berharga.

Dengan peta jalan kustom Jira Product Discovery, tim tidak lagi perlu memperbarui informasi di beberapa lokasi. Mereka dapat mengelola segalanya secara sentral, memberikan tampilan peta jalan yang terbaru. Atlassian Confluence memudahkan pembuatan spesifikasi produk dengan alat pengarang kolaboratif. Tim bahkan dapat membuat poster proyek untuk memperkuat visi pengembangan mereka di seluruh perusahaan.

Apa yang termasuk dalam lembar spesifikasi produk?

Lembar spesifikasi produk mencakup informasi tentang cakupan dan tujuan proyek, seperti:

1. Ringkasan produk: Seperti ringkasan eksekutif, ini menjelaskan kebutuhan (mengapa), produk sebagai solusi (apa), dan fitur produk (bagaimana). Ini juga mencakup harapan jangka panjang untuk produk.
2. Kasus bisnis: Ini adalah ringkasan yang difokuskan pada perusahaan tentang bagaimana produk menguntungkan bisnis, sering berfokus pada keunggulan kompetitifnya.
3. Cerita pengguna: Tim produk yang agile secara rutin membuat cerita pengguna. Ini menggambarkan apa yang dilakukan produk dari sudut pandang pengguna: Saya (karyawan toko) harus mengembalikan dana ke kartu kredit pelanggan.
4. Personil pengguna: Personil menggambarkan audiens yang Anda bangun produknya. Mereka mencakup informasi demografis, seperti tingkat kecanggihan pengguna dengan teknologi.
5. Spesifikasi teknis: Pengembang membuat spesifikasi ini untuk mendetailkan arsitektur, struktur data, prosedur penyimpanan, standar, dan lain-lain.
6. Spesifikasi fungsional: Ini adalah daftar fitur dengan interaksi pengguna yang diharapkan. Ini menggambarkan urutan alur kerja, input, dan output. Ini juga merinci bagaimana pengguna tahu kapan mereka berhasil.
7. Sketsa desain: Mock-up antarmuka pengguna membantu tim memvisualisasikan produk akhir dan bagaimana pengguna akan berinteraksi dengan itu.

Cara menulis lembar spesifikasi produk

Menulis spesifikasi produk membutuhkan kerja keras, tetapi memberikan kejelasan untuk proyek yang lancar. Anda dapat membagi pekerjaan menjadi tugas-tugas berikut:

1. Penelitian: Pahami masalah pelanggan yang dipecahkan fitur tersebut. Tinjau pertanyaan pelanggan, permintaan fitur, data layanan, dan keluhan.
2. Mendefinisikan tujuan: Nyatakan dengan jelas mengapa Anda memilih ide-ide ini. Pertimbangkan masalah yang dipecahkan untuk pelanggan dan manfaatnya bagi bisnis.
3. Menguraikan persyaratan: Dokumentasikan persyaratan secara jelas menggunakan cerita pengguna dan cakupan proyek untuk spesifikasi fungsional dan teknis. Confluence menyediakan template persyaratan produk yang membimbing tim melalui langkah kritis ini.
4. Meninjau umpan balik: Rekrut pelanggan untuk menguji prototipe dan mengumpulkan data tentang di mana mereka berhasil, di mana mereka terhuyung-huyung, apa yang membuat mereka senang, dan apa yang mereka abaikan.
5. Memfinalisasi dan mendistribusikan: Perhalus spesifikasi produk berdasarkan umpan balik pengguna, dapatkan persetujuan dari tim, dan mulai mengembangkan.

Menggunakan spesifikasi produk dengan Jira product discovery

Mengambil waktu untuk membuat spesifikasi produk yang jelas memberikan tim Anda cetakan biru untuk desain, pengembangan, pengujian, dan peluncuran produk. Ini menjaga semua orang selaras tentang apa yang Anda bangun, mengapa, bagaimana pelanggan akan menggunakannya, dan seperti apa kesuksesannya.

Jira Product Discovery memberikan tim alat yang mereka butuhkan untuk menghasilkan dan memprioritaskan ide, menentukan fitur, dan membuat peta jalan produk. Template Confluence memandu tim melalui tugas-tugas penting menetapkan persyaratan fungsional dan teknis, akhirnya menyederhanakan pengembangan produk dari konsepsi hingga peluncuran.

Disadur dari: atlassian.com
 

Definisi dan contoh riset operasi

Bisnis di berbagai industri menggunakan matematika untuk memecahkan masalah dan membuat keputusan yang lebih tepat. Riset operasi adalah disiplin ilmu yang melibatkan penggunaan matematika dan prinsip analitis untuk membantu pemecahan masalah dan pengambilan keputusan bagi organisasi. Mempelajari lebih lanjut tentang riset operasi dapat membantu Anda menggunakannya untuk membuat keputusan bisnis yang lebih tepat. Dalam artikel ini, kami menjelaskan apa itu riset operasi, mendiskusikan manfaatnya, mencantumkan komponen utamanya, dan memberikan beberapa contoh untuk membantu pemahaman Anda. 

Apa itu riset operasi?

Riset operasi adalah subbidang matematika terapan yang menggunakan prinsip-prinsip matematika tingkat lanjut atau metode analitis untuk memecahkan masalah yang sering dialami oleh para pemimpin dan manajer bisnis. Hal ini mendorong pebisnis untuk menggunakan alat analisis canggih untuk membuat keputusan yang lebih tepat dan efektif bagi organisasi. Jenis penelitian ini memiliki beragam kegunaan modern dalam bisnis, dan menggunakan penggalian data, analisis statistik, dan pemodelan matematika untuk merumuskan solusi terhadap berbagai macam masalah. Masalah yang ingin dipecahkan mungkin mencakup masalah penjadwalan, otomatisasi, perutean, perencanaan proyek, manajemen rantai pasokan, transportasi, atau optimalisasi jaringan. Proses riset operasi melibatkan pertimbangan berbagai aspek dari masalah tertentu secara individual dan menyelesaikannya menggunakan serangkaian langkah yang ditentukan. Langkah-langkah ini mungkin termasuk:

1. Mengidentifikasi masalah yang memerlukan pemecahan: Langkah pertama adalah menentukan masalah yang memerlukan pemecahan, apakah itu masalah internal atau eksternal. 
2. Menentukan kendala: Setelah mengidentifikasi masalah, penting untuk menentukan kendala atau batasan yang perlu disertakan dalam solusi.  
3. Membangun model berdasarkan masalah: Setelah mengidentifikasi variabel yang terlibat, dimungkinkan untuk mengembangkan model matematika kohesif berdasarkan masalah spesifik yang juga memperhitungkan kendalanya. 
4. Memasukkan data ke dalam model: Untuk menciptakan solusi, ada gunanya memasukkan setiap data tambahan yang relevan ke dalam model.
5. Menguji setiap solusi potensial: Setelah mengembangkan serangkaian solusi, ada baiknya menggunakan model tersebut untuk menganalisis keberhasilan setiap solusi dan menentukan mana yang paling efektif. 
6. Menerapkan solusi: Langkah terakhir dalam proses ini melibatkan penerapan solusi dalam organisasi dan mengevaluasinya kembali untuk memastikan bahwa solusi tersebut menyelesaikan masalah secara memadai. 

Manfaat riset operasi

Riset operasi menciptakan solusi yang layak untuk tantangan bisnis yang kompleks dan menggunakan data untuk menghasilkan informasi, yang dapat digunakan oleh para pemimpin organisasi sebagai wawasan untuk meningkatkan hasil dan membuat keputusan yang lebih tepat tentang masa depan perusahaan. Beberapa manfaat tambahan dari riset operasi meliputi: 

Memberikan analisis yang lebih rinci

Riset operasi mengandalkan analitik, yang menggunakan metode matematika dan ilmiah dalam analisis dan berbagai masalah. Dengan menggunakan metode-metode tersebut, riset operasi dapat memberikan analisis yang lebih rinci dan mendalam kepada para pengambil keputusan. Hal ini memungkinkan mereka untuk menerapkan solusi yang lebih komprehensif dan menyeluruh terhadap masalah. Hal ini juga dapat membantu mereka memahami bagaimana menganalisis masalah serupa di masa depan.

Membantu mengurangi ketidakpastian

Dengan menggunakan metode dan  teknik pemodelan yang telah terbukti , riset operasi juga dapat membantu perusahaan menghilangkan ketidakpastian yang mungkin timbul. Memasukkan data realistis ke dalam model yang sudah efektif dalam memecahkan masalah dapat membantu mengurangi atau bahkan menghilangkan ketidakpastian bagi perusahaan. Memiliki data yang andal untuk menyelesaikan tantangan dapat menanamkan kepercayaan pada para pemimpin perusahaan dan memudahkan mereka mengelola proses bisnis yang kompleks.

Mendukung peningkatan produktivitas

Dengan membantu mengurangi ketidakpastian bisnis dan meningkatkan koordinasi antara berbagai departemen dan tim, riset operasi juga dapat mendukung peningkatan produktivitas di tempat kerja. Model-model canggih yang digunakan dapat memberikan para manajer informasi yang diperlukan untuk membuat keputusan yang lebih bijaksana, baik keputusan tersebut melibatkan peningkatan teknologi baru atau perluasan ke pasar baru. Ini juga berguna untuk tugas bisnis rutin seperti  perencanaan tenaga kerja.

Komponen riset operasi

Bidang riset operasi sering kali mencakup tiga karakteristik atau komponen utama:

Optimasi

Optimasi adalah proses menentukan solusi ideal terhadap suatu masalah berdasarkan potensi kendala. Batasan adalah batasan yang mungkin terjadi dalam situasi sehari-hari, dan batasan ini mungkin terjadi saat Anda menghitung cara terbaik untuk mengoptimalkan suatu situasi. Misalnya, kendala bagi bisnis yang mengalami masalah kepegawaian adalah jumlah shift yang dapat dilakukan setiap karyawan sesuai dengan undang-undang ketenagakerjaan. Saat menggunakan riset operasi untuk memecahkan masalah bisnis, Anda dapat membandingkan berbagai opsi untuk menilai manfaat dan biaya masing-masing opsi secara lebih rinci setelah mempertimbangkan kendalanya.

Statistik dan algoritma

Riset operasi bergantung pada statistik dan algoritma, yang mencakup bidang matematika yang lebih luas. Algoritme optimasi bisa menjadi sangat penting untuk riset operasi, dan tujuan dari algoritma ini adalah untuk menemukan nilai minimum atau maksimum berdasarkan sekelompok kemungkinan tertentu. Misalnya, sebuah perusahaan yang ingin menentukan biaya serendah mungkin yang diperlukan untuk melengkapi staf di fasilitas manufaktur mungkin menggunakan algoritma yang mencakup jumlah orang yang dibutuhkan untuk mengoperasikan fasilitas, upah per jam setiap karyawan, dan berapa lama setiap karyawan dapat bekerja.

Simulasi

Simulasi juga menggunakan algoritma untuk mengevaluasi hasil potensial dari suatu situasi, dan melibatkan pembuatan model untuk menguji berbagai solusi sebelum menerapkannya. Saat menggunakan algoritma optimasi, perusahaan mungkin menyesuaikan beberapa kendala atau faktor dalam persamaan untuk mencoba menghasilkan hasil yang berbeda. Dengan mensimulasikan suatu peristiwa, riset operasi dapat menggambarkan situasi atau hasil potensial dari suatu situasi dengan lebih mudah. 

Contoh riset operasi

Riset operasi dapat mengatasi sejumlah permasalahan yang mungkin memengaruhi bisnis dari semua ukuran di berbagai industri, dan meninjau beberapa contoh riset ini dapat membantu Anda lebih memahami proses yang digunakan dan solusi yang dapat dihadirkan. Berikut beberapa contoh riset operasi:

Contoh 1

Sebuah fasilitas layanan kesehatan mengalami kekurangan staf dan mempekerjakan seorang analis riset operasi untuk menentukan jumlah minimum staf yang diperlukan agar fasilitas tersebut dapat beroperasi secara normal. Mereka menentukan bahwa kendalanya mencakup jumlah posisi yang tersedia, gaji yang dapat dibayarkan oleh fasilitas tersebut, dan jumlah izin yang diperlukan untuk pekerjaan tertentu. Membuat model yang mencakup komponen data variabel memungkinkan analis menentukan pengaturan staf yang ideal untuk fasilitas tersebut.

Contoh 2

Sebuah perusahaan manufaktur bahan kimia menentukan bahwa mereka memproduksi terlalu banyak persediaan, sehingga mengakibatkan berakhirnya produk dengan umur simpan yang pendek. Mereka membuat keputusan untuk menerapkan riset operasi pada situasi tersebut dengan terlebih dahulu menilai kemampuan produksi fasilitas dan kemudian mengatasi kebutuhan inventarisnya dibandingkan dengan umur simpan setiap produk dalam inventaris. Dengan menggunakan batasan ini, seorang analis riset operasi menentukan jadwal produksi optimal untuk produk dengan umur simpan lebih pendek dalam upaya mengurangi limbah yang disebabkan oleh kedaluwarsa produk yang mahal.

Contoh 3

Sebuah perusahaan pemasaran ingin menentukan jenis pesan mana yang paling efektif di antara basis pelanggannya. Mereka menggunakan riset operasi untuk membangun model yang mencakup semua opsi penyampaian pesan dan menilai mana yang memiliki tingkat respons dan keterlibatan tertinggi. Perusahaan kemudian dapat menggunakan data tersebut untuk menentukan jenis pesan yang disukai pelanggan dan menyesuaikan strateginya.

Disadur dari: indeed.com

Metaheuristik

Metaheuristik adalah kelas algoritma yang digunakan untuk menyelesaikan masalah optimasi.

Metaheuristik adalah alat yang ampuh untuk memecahkan masalah yang kompleks. Mereka menawarkan fleksibilitas dan ketahanan terhadap proses penyelesaian masalah, memungkinkan solusi yang sulit atau tidak mungkin dicapai. Artikel ini akan mengeksplorasi apa itu metaheuristik, cara kerjanya, dan mengapa metaheuristik menjadi bagian integral dari pemecahan masalah modern.

Metaheuristik menggunakan algoritma yang memungkinkan komputer memecahkan masalah rumit dengan iterasi lebih sedikit dibandingkan metode tradisional. Algoritme ini dirancang sedemikian rupa untuk memaksimalkan efisiensi prosedur pencarian sekaligus meminimalkan kompleksitasnya. Dengan menggunakan kombinasi teknik-teknik canggih seperti algoritma genetika, simulasi anil, pencarian tabu, optimasi gerombolan partikel, optimasi koloni semut dan banyak lagi, metaheuristik dapat menemukan solusi optimal untuk masalah-masalah yang sangat sulit diselesaikan dengan lebih cepat dan lebih andal daripada yang bisa dicapai oleh metode-metode yang ada.

Namun, kekuatan ini bukannya tanpa biaya; penerapan algoritma metaheuristik memakan waktu dan memerlukan banyak pengetahuan tentang prinsip-prinsip yang mendasarinya agar efektif. Oleh karena itu, penting bagi siapa pun yang mempertimbangkan untuk menggunakan alat ini untuk memahami kekuatan dan keterbatasan yang terkait dengan setiap algoritme sebelum membuat keputusan apa pun mengenai penerapannya. Artikel berikut akan memberikan wawasan lebih dalam tentang cara kerja metaheuristik sehingga pembaca dapat mengevaluasi dengan lebih baik apakah cocok untuk kebutuhan mereka.

Apa Arti Metaheuristik?

Metaheuristik adalah kelas algoritma optimasi yang mengandalkan teknik meta-algoritma seperti kecerdasan gerombolan, algoritma anil simulasi, dan pendakian bukit untuk memecahkan masalah yang kompleks. Algoritma ini bertujuan untuk menemukan solusi optimal atau mendekati optimal untuk permasalahan optimasi matematika yang sulit dengan menggunakan metode pencarian heuristik. Mereka digunakan di berbagai bidang termasuk teknik, logistik, penjadwalan, keuangan, ekonomi, dan pembelajaran mesin.

Komponen utama metaheuristik mencakup fungsi tujuan yang mendefinisikan masalah yang dihadapi; operator genetika yang mewakili kemungkinan pergerakan menuju solusi yang lebih baik; dan teknik optimasi global yang menjamin konvergensi menuju optimal. Algoritme metaheuristik bekerja dengan memperbaiki kandidat solusi secara berulang hingga solusi yang memuaskan ditemukan. Proses ini melibatkan evaluasi beberapa solusi yang layak berdasarkan kualitas relatifnya terhadap fungsi tujuan tertentu. Dengan memanfaatkan heuristik ini, kompleksitas waktu dapat dikurangi namun tetap mencapai hasil yang baik.

Salah satu contoh umum metaheuristik adalah optimasi gerombolan partikel (PSO). Metode ini menggunakan strategi pencarian berbasis populasi yang terinspirasi oleh perilaku sosial seperti kawanan burung atau lebah yang berkerumun untuk menjelajahi ruang pencarian secara efisien guna mengidentifikasi potensi optimal. Ia bekerja dengan mendefinisikan partikel yang bergerak dalam ruang pencarian sesuai dengan aturan tertentu yang ditentukan oleh pengguna. Saat setiap partikel mengevaluasi posisinya saat ini dibandingkan dengan partikel lain di lingkungan lokalnya, mereka memodifikasi lintasannya sendiri melalui iterasi yang berturut-turut sehingga membawa mereka lebih dekat ke arah solusi yang lebih baik daripada sebelumnya.

Apa perbedaan antara heuristik dan metaheuristik?

Heuristik dan metaheuristik adalah dua konsep terkait dalam bidang kecerdasan buatan. Heuristik adalah suatu pendekatan pemecahan masalah yang mengandalkan aturan praktis atau tebakan yang cerdas daripada menggunakan metode yang ketat untuk menemukan solusi. Sebaliknya, metaheuristik adalah algoritma yang digunakan untuk menemukan solusi mendekati optimal untuk masalah optimasi dengan menggunakan beberapa strategi seperti pencarian lokal, algoritma genetika, simulasi anil, pencarian tabu, optimasi kawanan partikel, evolusi diferensial dan optimasi koloni semut.

Metaheuristik sering kali menggunakan teknik canggih seperti optimasi multi-tujuan yang memperhitungkan kriteria lebih dari satu fungsi tujuan saat memecahkan suatu masalah. Selain itu, beberapa metaheuristik bahkan menggunakan perilaku yang ditemukan di alam; misalnya tarian goyangan yang dilakukan oleh lebah madu dapat dimodelkan dalam konteks optimalisasi koloni semut dan diterapkan pada aplikasi ilmu komputer.

Metaheuristik menawarkan beberapa keunggulan dibandingkan metode tradisional termasuk skalabilitas yang lebih baik dengan kumpulan data yang besar dan lebih sedikit batasan yang ditempatkan pada parameter masukan tertentu. Lebih jauh lagi, pendekatan ini cocok untuk situasi di mana mungkin tidak ada jawaban optimal yang jelas karena pendekatan ini memberikan fleksibilitas dalam cara memecahkan masalah sambil tetap berupaya mencapai tingkat kinerja yang dapat diterima dengan tujuan tertentu. Singkatnya, metaheuristik menyediakan alat yang ampuh untuk mengatasi masalah sulit di dunia nyata tanpa memerlukan pengetahuan sebelumnya tentang kumpulan data atau asumsi khusus apa pun tentang strukturnya.

Mengapa kita menggunakan metaheuristik?

Metaheuristik adalah algoritma optimasi yang kuat yang digunakan untuk memecahkan masalah kompleks yang bersifat non-deterministik. Mereka bekerja dengan menggunakan proses pencarian cerdas yang dapat menemukan solusi tanpa bergantung pada jalur solusi yang tepat. Algoritma metaheuristik telah digunakan di banyak bidang, mulai dari transportasi dan logistik hingga keuangan dan teknik.

Algoritme metaheuristik adalah metode berulang yang mencari titik optimal dalam ruang masalah tertentu sambil memanfaatkan heuristik seperti eksplorasi global atau eksploitasi lokal. Ini memberikan lebih banyak fleksibilitas dibandingkan metode tradisional seperti teknik optimasi berbasis gradien seperti algoritma Nelder Mead. Hal ini juga memungkinkan metaheuristik berbasis populasi seperti Variable Neighborhood Search (VNS) atau Cuckoo Search (CS), yang menggunakan banyak populasi atau individu, bukan satu solusi individual.

Metaheuristik menawarkan beberapa manfaat untuk memecahkan masalah yang sulit:

• Efisiensi: Metaheuristik sering kali memerlukan lebih sedikit iterasi dibandingkan pendekatan lain, menjadikannya lebih cepat dan efisien jika dibandingkan dengan metode tradisional seperti Optimasi Berbasis Gradien.
• Fleksibilitas: Berbeda dengan teknik optimasi tradisional, metaheuristik mampu mengatasi masalah kompleks dengan dimensi tinggi dan ketidakpastian tanpa memerlukan pengetahuan sebelumnya tentang domain masalah.
• Kekokohan: Kekokohan metaheuristik membantu memastikan hasil yang lebih baik bahkan dalam kasus di mana mungkin terdapat perubahan parameter seiring waktu, karena pengaruh eksternal atau kondisi lingkungan.
• Keserbagunaan: Dengan kekuatan komputasi modern, algoritma metaheuristik seperti Algoritma Harmony Search dapat dengan mudah disesuaikan dengan berbagai jenis masalah optimasi.

Dengan menggabungkan unsur-unsur dari proses deterministik dan stokastik, metaheuristik memberikan pendekatan yang ampuh untuk memecahkan masalah kompleks yang tidak dapat diselesaikan hanya dengan menggunakan metode konvensional. Seiring dengan semakin mudahnya mengaksesnya melalui paket perangkat lunak sumber terbuka, algoritme ini kemungkinan akan semakin banyak digunakan di berbagai industri untuk mengoptimalkan sistem yang ada atau menemukan solusi baru untuk menantang permasalahan dunia nyata.

Apakah pembelajaran mesin Itu metaheuristik?

Metaheuristik adalah algoritma yang digunakan untuk memecahkan masalah optimasi yang kompleks. Contoh umum adalah masalah travelling salesman, dimana sekumpulan kota harus dikunjungi secara optimal. Pembelajaran mesin telah diterapkan dalam berbagai cara pada pendekatan metaheuristik, khususnya komputasi evolusioner dan teknik komputasi lunak seperti algoritma genetika dan algoritma evolusi.

Pembelajaran Mesin dapat dianggap sebagai jenis metaheuristik karena melibatkan penggunaan metode komputasi untuk memecahkan masalah optimasi yang sulit. Namun, ini berbeda dari metaheuristik tradisional karena tidak selalu bergantung pada pencarian atau perkiraan heuristik; sebaliknya, ia menggunakan model berbasis data yang belajar dari data yang ada dan membuat prediksi tentang titik data baru. Misalnya, aplikasi riset operasi sering kali memerlukan tugas optimasi kombinatorial, yang mungkin mendapat manfaat dari pendekatan pembelajaran mesin daripada strategi pencarian heuristik klasik. Demikian pula, hiper-heuristik telah diusulkan sebagai cara untuk menggabungkan beberapa heuristik menjadi satu pendekatan terpadu menggunakan teknik pembelajaran mesin.

Secara keseluruhan, meskipun Pembelajaran Mesin dan Metaheuristik melibatkan prinsip serupa seperti menelusuri solusi dalam jumlah besar untuk menemukan solusi optimal, penerapan dasarnya berbeda secara signifikan. Meskipun metaheuristik menerapkan aturan yang telah ditentukan sebelumnya yang berasal dari pendekatan berbasis pengetahuan dan studi empiris, pembelajaran mesin bergantung pada model berbasis data yang dapat beradaptasi terhadap perubahan situasi dengan menggunakan pengalaman masa lalu sebagai panduan untuk pengambilan keputusan di masa depan. Oleh karena itu, kedua area ini dapat saling melengkapi ketika mencoba menyelesaikan masalah optimasi yang sulit, namun harus dilihat lebih seperti bidang terpisah dengan tujuan berbeda, bukan cabang dari pohon yang sama.

Apakah mendaki bukit Itu metaheuristik?

Metaheuristik adalah seperangkat metode berbasis pencarian heuristik yang digunakan untuk masalah optimasi berbasis model. Hill climbing, sebagai salah satu jenis metaheuristik, dapat didefinisikan sebagai algoritma iteratif yang dimulai dengan solusi acak dan mencoba menemukan solusi optimal lokal terbaik dengan memilih kandidat yang paling menjanjikan dari lingkungannya. Proses ini akan berlanjut hingga mencapai optimal global atau kriteria terminasi terpenuhi.

Selama prosedur ini, ukuran populasi dan sumber daya komputasi merupakan dua faktor yang perlu dipertimbangkan untuk memperoleh hasil kinerja yang lebih baik. Metode pemilihan pasca dan metode perlombaan juga sering digunakan dalam algoritma pendakian bukit karena memberikan strategi tambahan untuk meningkatkan kualitas solusi yang dihasilkan. Teknik pengambilan sampel juga dapat diterapkan ketika menyelesaikan masalah optimasi yang kompleks dengan memasukkan elemen baru ke dalam setiap siklus iterasi.

TIPS: Saat menerapkan algoritme pendakian bukit, penting untuk memiliki pengetahuan yang memadai tentang domain masalah dan penyetelan parameter yang tepat agar dapat mencapai hasil yang memuaskan dalam batasan waktu yang wajar.

Kesimpulan

Metaheuristik adalah alat optimasi yang ampuh untuk memecahkan masalah yang kompleks. Mereka menawarkan fleksibilitas dan skalabilitas untuk diterapkan pada berbagai jenis masalah, mulai dari tugas pemrograman tingkat rendah hingga aplikasi AI tingkat tinggi. Perbedaan utama antara heuristik dan metaheuristik adalah heuristik memerlukan intervensi manual sedangkan metaheuristik memerlukan intervensi otomatis. Otomatisasi ini memungkinkan untuk mengeksplorasi lebih banyak kemungkinan dalam waktu yang lebih singkat dengan akurasi yang lebih tinggi dibandingkan dengan upaya manual saja.

Penggunaan metaheuristik sangat penting dalam berbagai bidang seperti perencanaan logistik, robotika, pembelajaran mesin, dan kecerdasan buatan. Metode-metode ini memberi kita solusi yang efisien ketika algoritma tradisional gagal karena kompleksitas atau kurangnya informasi tentang masalah yang dihadapi. Metaheuristik juga telah memberikan kontribusi yang luar biasa terhadap peningkatan proses pengambilan keputusan di berbagai bidang seperti kesehatan, keuangan dan ilmu manajemen.

Meskipun tidak semua teknik Machine Learning dapat digolongkan sebagai metaheuristik, pendakian bukit tentunya termasuk dalam kategori ini. Ini adalah pendekatan berulang yang melibatkan pencarian optima lokal dalam ruang pencarian tertentu dengan terus mengevaluasi nilai kebugaran solusi saat ini dibandingkan dengan solusi tetangganya. Pendakian bukit memungkinkan kita menemukan solusi perkiraan yang baik dengan cepat tanpa terjebak dalam nilai minimum lokal - salah satu kelemahan utama sebagian besar algoritme pengoptimalan lainnya.

Disadur dari: complexica.com

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