16
SISTEM IDENTIFIKASI KONFIGURASI DAN KOMPONEN
SELEKSI STRATEGI
Dari saat awal sistem, Sistem Pengguna, Acquirers, Pengembang,
Maintainers, dan lain-lain mulai membuat keputusan pengembangan sistem yang
berevolusi dari waktu ke waktu. Seperti halnya untuk Sistem Teknik dan
Pengembangan ... memberikan sistem fisik yang diverifikasi dalam batasan
proyek tiga kepatuhan dengan persyaratan teknis, jadwal, dan dalam biaya. Hal
ini memerlukan sangat terstruktur, terorganisir, dan mengatur pendekatan untuk
semakin mengukur dan melaporkan statusnya teknis dan kematangan solusi desain
sistem berkembang. Dari sudut pandang perencanaan, akuntabilitas, tindakan
korektif, dan berkala pelaporan kemajuan status dan kematangan solusi
desain sistem berkembang tinggal dengan insinyur proyek atau Memimpin SE
(LSE) di acara-acara program teknis kunci seperti ulasan, laporan status teknis, dan
lain-lain
Sebagai bagian dari akuntabilitas mereka, insinyur proyek atau LSE harus
menangkap keadaan solusi desain sistem berkembang yang mewakili
“snapshot dalam waktu” dari keputusan teknis. Contohnya termasuk
kebutuhan stakeholder operasional, kasus penggunaan dan skenario yang paling
mungkin atau mungkin, kemampuan operasional yang diperlukan, operasi, perilaku,
pelaksanaan fisik, dan lain-lain. rantai topik juga merupakan dependensi yang
berevolusi dan jatuh tempo pada titik-titik pementasan kunci seluruh Sistem / Produk
fase Siklus Hidup. Karena manusia harus memiliki bukti obyektif fisik untuk
meninjau, dokumentasi seperti spesifikasi, arsitektur, desain, gambar, dll .; prototipe;
demonstrasi; dan model dan simulasi menjadi dasar untuk penilaian. Sebagai
“snapshot dalam waktu,” mereka mewakili pengaturan dan interaksi tergantung waktu
operasional, perilaku,
Sistem Analisis Teknik, Desain, dan Pengembangan: Konsep, Prinsip, dan Praktek, Edisi kedua. Charles S. Wasson. © 2016 Wasson Strategics, LLC. Diterbitkan 2016 oleh John Wiley &
Sons, Inc. Companion Website: www.wiley.com/go/systemengineeringanalysis2e
yang membutuhkan identifikasi yang unik konfigurasi, versi, dan cap waktu-
yang, Konfigurasi A, Versi 1.1, Bulan / Hari / Tahun.
Secara kolektif, set konfigurasi menjadi bagian dari apa yang disebut sebagai
Konfigurasi Developmental dari sistem, produk, atau layanan. Seperti ulasan
teknis dilakukan sepanjang proyek, Developmental Konfigurasi berkembang
menjadi kerangka kerja untuk mengukur dan melaporkan kemajuan, status, dan
kematangan solusi desain sistem berkembang.
Salah satu kelemahan dari kondisi manusia adalah kemampuan untuk: (1) membuat
dan berkomitmen untuk tepat waktu, keputusan yang bila diperlukan dan (2) untuk
membangun keputusan-keputusan yang mengarah ke keputusan lain dan kemudian untuk
pengiriman sistem, produk, atau layanan. Dr William McCumber dan Sloan (2002, p. 4)
mengamati bahwa tugas SES (dan Project Engineer) adalah untuk “mempertahankan
kontrol intelektual dari solusi masalah”(Prinsip 1.3). Jika tidak, AD hoc,
Plug dan Chug ... Tentukan-Build-Test-Fix (SBTF) - Proses Desain Model (DPM)
Paradigma Rekayasa akan menang dan menyebabkan kebingungan dan
kekacauan.
LSE atau Project Engineer bekerjasama dengan Arsitek Sistem, tim
yang sesuai memimpin atau insinyur, Manajer Konfigurasi, dan lain-lain harus
menentukan strategi yang mengidentifikasi kapan dan bagaimana perkembangan
Konfigurasi Solusi Desain Sistem berkembang dan konfigurasi dari entitas
hirarki tingkat yang lebih rendah akan diidentifikasi, ditangkap, Ulasan, disetujui,
baselined, dirilis, dan dikendalikan.
Perencanaan untuk keputusan ini dan kriteria mereka disinkronisasi dan
didokumentasikan dalam

proyek Rencana Sistem Manajemen Rekayasa (SEMP) dan Rencana
Pengelolaan Konfigurasi (CMP).
Bab ini menjelaskan bagaimana unsur-unsur dari konfigurasi arsitektur sistem
diidentifikasi dan ditetapkan untuk kontrol konfigurasi dan pelacakan. Diskusi kami mulai
dengan mendirikan Manajemen Konfigurasi (CM) semantik dan menjelaskan mengapa
hal ini sering membingungkan. Kami menjelajahi bagaimana item arsitektur yang
dipilih dari vendor eksternal
Commercial-Off-the-Shelf (COTS) item atau Produk Non-Developmental (NDIS),
atau Acquirer Furnished Properti (AFP), atau dikembangkan di rumah dari desain
warisan atau perkembangan baru. Kami menyediakan ilustrasi tentang bagaimana
item yang ditugaskan untuk pengembangan rekayasa teams.We menyimpulkan
dengan diskusi tentang kapan untuk menetapkan baseline Konfigurasi Pembangunan
dan kontras SE dan CM sudut pandang.
16,1 DEFINISI ISTILAH KUNCI
• dialokasikan Dasar - “Dokumentasi yang menunjuk Item Konfigurasi (CI)
membuat sebuah sistem dan kemudian mengalokasikan fungsi sistem dan
persyaratan kinerja seluruh CI (maka istilah - dasar dialokasikan). Ini
mencakup semua karakteristik fungsional dan antarmuka yang dialokasikan
dari orang-orang dari CI tingkat yang lebih tinggi atau dari sistem itu
sendiri, persyaratan berasal, persyaratan antarmuka dengan CI lain,
pembatasan desain, dan verifikasi diminta untuk menunjukkan pencapaian
karakteristik fungsional dan antarmuka yang ditentukan. Kinerja masing-
masing CI di dasar dialokasikan dijelaskan dalam spesifikasi kinerja barang
nya”(DAU 2012, p. B-10).
• Acquirer Furnished Properti (AFP) - “aset fisik seperti peralatan, Misi
Sumber Daya, Hardware, Software, dan Fasilitas yang disediakan
oleh Pengguna atau organisasi lain melalui kontrak Acquirer ke Sistem
Developer untuk modifikasi dan / atau integrasi ke sistem, produk, atau
layanan penyampaian”
• garis belakang Koleksi -A konfigurasi dikendalikan, spesifikasi dan
desain persyaratan dokumentasi untuk Item Konfigurasi (CI) atau set CI
yang mewakili versi saat ini, disetujui, dan merilis dokumen atau data item
yang tersedia untuk pengambilan keputusan.
• Manajemen dasar - “Dalam manajemen konfigurasi, penerapan arah
teknis dan administratif untuk menunjuk dokumen dan perubahan
dokumen-dokumen yang secara resmi mengidentifikasi dan menetapkan
baseline pada waktu tertentu selama siklus hidup dari item konfigurasi”
(SEVOCAB, 2014, p 28 -. Copyright 2012 ISO
/ IEC Digunakan dengan izin) (ISO / IEC / IEEE 24.765. 2010).
• Permintaan Perubahan (CR) -A dokumen formal yang disampaikan
kepada Manajemen Konfigurasi (CM) meminta dan menentukan tindakan
korektif untuk dokumen Developmental Konfigurasi Dasar yang berisi cacat
laten seperti kesalahan, ketidakakuratan, kekurangan, desain
DEFINISI ISTILAH KUNCI 345
cacat, dan sebagainya. CR biasanya: (1) dimulai sebagai hasil dari analisis
investigasi dipicu oleh ProblemReport (PR); (2) ditinjau oleh Control Dewan
Konfigurasi (CCB); (3) dan disetujui, ditolak, atau ditunda oleh CCB; dan
(4) dilacak sampai selesai dengan CM berdasarkan verifikasi
keberhasilan tindakan korektif. CR untuk tindakan korektif software
yang disebut sebagai Software Perubahan Permintaan (SCR); SCRs
mengikuti proses yang sama seperti CR dengan pengecualian dan
persetujuan oleh Software Konfigurasi Kontrol Dewan (SCCB).
• Dijual Lagi Off-the-Shelf (COTS) - “A Barang Komersial (CI) dijual
dalam jumlah besar di pasar komersial dan ditawarkan kepada
pemerintah di bawah kontrak atau subkontrak pada tingkatan apa pun, tanpa
modifikasi, dalam bentuk yang sama di mana itu dijual di pasar. Definisi ini
tidak termasuk kargo curah seperti produk pertanian atau minyak
bumi”(FAR, Sub 2,101) DAU 2012,
p. B-34.
• Komersial-Off-the-Shelf (COTS) Produk -SEBUAH
produk yang tersedia melalui katalog atau situs web yang dirancang untuk
lingkungan operasi ambien atau industri.
• Komputer Software Konfigurasi Barang (CSCI) - “Sebuah agregasi dari
perangkat lunak yang memenuhi fungsi penggunaan akhir dan ditujukan untuk
manajemen konfigurasi terpisah oleh pengakuisisi. CSCIs dipilih berdasarkan
trade-off antara fungsi perangkat lunak, ukuran, tuan rumah atau target komputer,
pengembang, konsep dukungan, rencana untuk digunakan kembali, kekritisan,
pertimbangan antarmuka, perlu secara terpisah didokumentasikan dan
dikendalikan, dan faktor lainnya”(MIL-STD- 498, 1994, hal. 5).
• Konfigurasi - “Koleksi deskriptif dan pemerintahan karakteristik item, yang
dapat dinyatakan dalam hal fungsional, yaitu, apa kinerja item diharapkan
untuk mencapai; dan dalam hal fisik, yaitu, apa yang
item akan terlihat seperti dan terdiri dari ketika dibangun”(DAU 2012, p. B-39).
• konfigurasi Dasar snapshot -A pada suatu saat tertentu dalam waktu
yang mewakili keadaan saat ini sistem, produk, atau Developmental
Konfigurasi produk pekerjaan teknis layanan ini seperti spesifikasi,
desain, gambar, skema, daftar komponen, analisis, studi perdagangan,
dan sebagainya yang baru atau telah direvisi, Ulasan, disetujui oleh otoritas
persetujuan, dan dirilis untuk pengambilan keputusan proyek.
• Kontrol konfigurasi - “(1) Suatu proses yang sistematis yang
memastikan bahwa perubahan dirilis dokumentasi konfigurasi
diidentifikasi, didokumentasikan, dievaluasi untuk dampak, disetujui oleh
tingkat yang tepat dari otoritas, dimasukkan, dan diverifikasi. (2) Kegiatan
manajemen konfigurasi mengenai: proposal sistematis, pembenaran,
evaluasi, koordinasi, dan disposisi dari perubahan yang diusulkan; dan
pelaksanaan semua perubahan yang disetujui dan dirilis
346 SISTEM IDENTIFIKASI KONFIGURASI DAN KOMPONEN SELEKSI STRATEGI
menjadi (a) konfigurasi yang berlaku dari produk, (b) terkait informasi
produk, dan (c) mendukung dan interfacing produk dan informasi produk
yang terkait.”(MIL-STD-61A (SE), p. 3-4 dan 3 -5)
• Manajemen Perubahan konfigurasi - Proses CM administrasi
prosedur perubahan manajemen formal. kegiatan proses formal meliputi
penerimaan dan penebangan produk kerja dokumen baru atau Ubah
Permintaan (CR) ke baseline saat ini, koordinasi dan pelaksanaan review
dari perubahan yang diusulkan, persetujuan perubahan dengan otoritas
persetujuan, tindak lanjut tindakan korektif, penggabungan perubahan menjadi
arus dasar, dan rilis resmi untuk pengambilan keputusan proyek.
• Identifikasi konfigurasi - “(1) Proses sistematis memilih produk atribut,
mengorganisir informasi yang terkait tentang atribut, dan menyatakan
atribut. (2) pengidentifikasi unik untuk produk dan dokumen
konfigurasinya. (3) Kegiatan manajemen konfigurasi yang mencakup
memilih dokumen konfigurasi; menugaskan dan menerapkan
pengidentifikasi unik untuk produk,
komponen-komponennya, dan dokumen-dokumen terkait; dan
mempertahankan hubungan revisi dokumen untuk konfigurasi
produk”(MIL-STD-61A, p. 3-5).
• konfigurasi Barang Sistem -A atau Badan pada setiap tingkat
abstraksi seperti Equipment, Hardware, Software, atau item
Courseware yang telah diidentifikasi secara terpisah dan ditujukan untuk: (1)
pengembangan di bawah resmi Pengendalian Konfigurasi prosedur
Manajemen dan kontrol versi dan (2) penugasan Model nomor dan
nomor seri.
• Manajemen konfigurasi - “Sebuah proses manajemen untuk
membangun dan mempertahankan konsistensi kinerja suatu produk,
fungsional, dan atribut fisik dengan persyaratan, desain dan informasi
operasional sepanjang hidupnya. (MIL-STD-61A,
p. 3-5)
• Status konfigurasi Akuntansi (CSA) - Sebuah proses CM bahwa:
(1) menerapkan salah satu dari empat fungsi CM, (2) secara resmi
mendokumentasikan keadaan Developmental Konfigurasi dari sistem
atau produk di contoh spesifik dalam waktu, (3) memelihara dan
menyumbang status konfigurasi saat ini dari Konfigurasi Pembangunan
dan setiap dokumen yang baselined, (4) mencatat disposisi saat Acquirer
Furnished Equipment (AFP) dan dokumen kontrak, dan (5) arsip dan trek
disetujui Perubahan Permintaan (CR).
• Data -Informasi didokumentasikan dalam bentuk apapun media seperti
dokumen, rekaman audio dan video, foto, gambar, catatan pribadi,
pengukuran,
dan sebagainya yang mengandung Enterprise, kontrak, keamanan,
program, teknis, dan informasi personil yang dapat dibaca, diuraikan,
agregat, ditransfer, dan dianalisis untuk pengambilan keputusan.
• Konfigurasi perkembangan: Lihat Bab 12
Definisi Istilah Key.
• efektivitas -Designation mendefinisikan titik waktu, acara, atau berbagai
produk (misalnya, serial, nomor lot, model, tanggal) di mana perubahan
atau variasi untuk produk tertentu harus dilakukan. Resmi dan titik
penggunaan didokumentasikan untuk konfigurasi tertentu dari bagian /
perakitan / instalasi, dll (FAA SEM 2006, Vol. 3, p. B-3).
• firmware - “Kombinasi dari perangkat keras dan instruksi komputer atau
data komputer yang berada sebagai read-only perangkat lunak pada
perangkat keras. Perangkat lunak ini tidak dapat langsung diubah di
bawah kontrol program”(DAU 2012, p. B-85.).
• Konfigurasi Hardware Barang (HWCI) - “Sebuah agregasi dari
hardware yang memenuhi fungsi penggunaan akhir dan ditujukan untuk
manajemen konfigurasi terpisah oleh Acquirer” (MIL-STD-498, p 5.).
• Barang - “Suatu istilah spesifik digunakan untuk menunjukkan produk apapun,
termasuk sistem, materiels, bagian, subassemblies, set, aksesoris, dll” (MIL-HDBK-
61A (SE), tahun 2001,
p. 3-8).
• Legacy Sistem -Sebuah desain sistem yang ada yang telah diverifikasi dan dikenai
penggunaan lapangan dan mungkin atau mungkin tidak akan beroperasi.
• Baris diganti Unit (LRU) - “Item dukungan penting dihapus dan diganti
di tingkat lapangan untuk mengembalikan item mengakhiri kondisi
operasional siap” (DAU,
2012, p. B-144).
• Membuat Membeli-Modifikasi-Keputusan keputusan-Teknis yang menentukan
apakah untuk mengembangkan item atau item tingkat yang lebih rendah secara internal,
pengadaan sebagai COTS / NDI atau subkontrak item dari vendor eksternal, atau
pengadaan item dari vendor eksternal dan memodifikasi internal untuk memenuhi
Entity Pembangunan Spesifikasi (EDS) persyaratan .
• Ketidaksesuaian - “Kegagalan unit atau produk untuk memenuhi
persyaratan yang ditentukan” (MIL-HDBK-61A (SE), 2001, hal 3-8.).
• Non-Developmental Barang (NDI) produk -A COTS yang telah
dimodifikasi atau disesuaikan (yaitu, disesuaikan atau disesuaikan) oleh
pengembang untuk memenuhi persyaratan spesifikasi pengadaan untuk aplikasi
dalam lingkungan operasi yang ditentukan.
• Out-of-the-Box Fungsi kemampuan -Specified dan tingkat kinerja yang
melekat pada produk COTS atau NDI sebagaimana ditentukan dalam
katalog vendor atau Produksi Keterangan.
 MEMAHAMI KONFIGURASI SEMANTIK IDENTIFIKASI
• outsourcing keputusan bisnis -A untuk pengadaan sistem, produk, atau jasa
dari organisasi eksternal berdasarkan ketersediaan sumber daya menghindari
biaya, atau faktor lainnya.
• Struktur Breakdown produk (PBS) -The struktur hirarki fisik dari
sistem, produk, atau layanan.
• Melepaskan -A resmi acara CM diumumkan oleh surat resmi dan / atau
pemberitahuan elektronik yang menyatakan bahwa item telah secara resmi baselined
dan ditempatkan di bawah CMControl formal atau versi terbaru sekarang disetujui
untuk pengambilan keputusan.
• Data Paket Teknis (TDP) “Sebuah deskripsi teknis dari item yang
memadai untuk mendukung strategi akuisisi, produksi, teknik, dan dukungan
logistik. deskripsi mendefinisikan konfigurasi desain yang diperlukan dan
prosedur yang diperlukan untuk memastikan kecukupan kinerja barang.
Ini terdiri dari semua data teknis yang berlaku seperti gambar dan daftar
terkait, spesifikasi, standar, persyaratan kinerja, ketentuan jaminan
kualitas, dan detail kemasan.”(MIL-HDBK-61A (SE), 2001, hal. 3-10)
• Perbedaan -A non-kepatuhan seperti kesalahan atau
ketidaktelitian informasi; item fisik seperti peralatan, Hardware,
Software, atau Courseware; komposisi bahan; atau praktik pengerjaan
yang menyimpang dari standar acuan untuk kepatuhan seperti spesifikasi,
gambar, dan sebagainya.
Dalam diskusi sebelumnya, semantik kami telah
menggunakan istilah-istilah seperti entitas
dan komponen yang memiliki definisi
kontekstual. Komunitas CM menggunakan istilah barang
Catatan penulis 16,1
berkonotasi en- fisik
tities di SES cara yang sama merujuk komponen. Dalam bab ini, kita akan
menggunakan barang karena konteks bab ini. Ketika Anda membaca barang, menyamakan ke entitas
atau komponen.
16,2 ITEM: BLOK BANGUNAN SISTEM
Konfigurasi Item (CI) Prinsip
Setiap komponen fisik dalam sistem sebagai barang oleh CM.
Beberapa item ditunjuk sebagai CI untuk
prinsip 16,1 pengembangan internal; oth-
ers sebagai produk COTS atau NDIS tersedia untuk pengadaan dari vendor
eksternal untuk pengadaan.
Tergantung pada ukuran dan kompleksitas sistem atau item yang
dikembangkan, Pengembangan Produk Tim (PDT) seperti Tim Produk Terpadu (induktor
interphasa) ditugaskan peran dan tanggung jawab untuk menentukan, merancang,
mengembangkan, mengintegrasikan, dan memverifikasi berbagai komponen dalam
sistem. Ini menyajikan beberapa tantangan yang signifikan:
347
• Bagaimana Anda partisi arsitektur Peralatan Elemen menjadi PBS
dengan beberapa tingkat CI Fisik?
• Bagaimana proyek dapat membangun semantik yang memungkinkan mereka untuk
berkomunikasi dengan orang lain tentang jenis item yang dikembangkan secara internal
atau diperoleh dari vendor eksternal?
• Bagaimana bisa memproyeksikan tim berkomunikasi tentang evolusi item sistem yang
melalui berbagai tahapan dari entitas systemspecification abstrak menjadi komponen-
komponen fisik yang digunakan untuk membangun sistem?
Solusinya tinggal di “blok bangunan” yang terintegrasi disebut sebagai
item, CI, HWCIs, dan CSCIs. Masing-masing blok bangunan ini mewakili semantik
digunakan untuk mengidentifikasi entitas abstrak dalam suatu sistem atau produk dan
evolusi mereka dari Sistem Kinerja Keterangan (SPS) atau Badan Pembangunan
Keterangan (EDS) untuk kiriman.
16,3 MEMAHAMI SEMANTIK CONFIGURATION
IDENTIFIKASI
Konfigurasi identifikasi pengetahuan untuk sebagian SES biasanya berasal dari paparan
resmi melalui diskusi verbal dalam pertemuan dan On-the-Job Training (OJT) selama
bertahun-tahun. Kebanyakan insinyur:
• Memiliki sedikit atau tidak ada pelatihan formal dalam empat fungsi dari CM:
Konfigurasi Identifikasi, Kontrol Configuration, CSA, dan Konfigurasi
Audit.
• Apakah otodidak melalui observasi dan pengetahuan pengalaman
standar CM umum dan konsep.
Akibatnya, beberapa mungkin menganggap diri mereka sebagai ahli konfigurasi.
Keterampilan dasar memberikan wawasan dasar tentang sistem
keputusan konfigurasi arsitektur. Alih-alih mencari
berwawasan bimbingan dari CM yang kompeten, lead teknis menjalankan wewenang mereka,
membuat keputusan, dan mengembara turun pengambilan keputusan jalur mandiri
meninggalkan insinyur proyek, LSE, atau CM dan lain-lain untuk sia-sia mengeluarkan
waktu dan sumber daya bersaing dengan Hukum Unintended Consequences berharga dan
membersihkan setelah efek dari keputusan mereka yang buruk. Jadi, untuk memperkecil
kebingungan dan kekacauan, mari kita mulai dengan
memperkenalkan beberapa istilah kunci. Gambar 16.1 menggambarkan hubungan badan
untuk mendukung diskusi kami.
16.3.1 Produk Konfigurasi (CI)
Ketika Sistem Pengembang memutuskan untuk mengembangkan sebuah item besar
seperti sebuah Produk, Subsystem, atau Majelis, atau Subassembly di rumah, proyek
menunjuk barang - entitas atau komponen - sebagai CI a. Sejak item akan baru,
348 SISTEM IDENTIFIKASI KONFIGURASI DAN KOMPONEN SELEKSI STRATEGI

Dimana:

AFP = Acquirer / End User Furnished CSC Property =

saya nclude
item Computer Software Komponen CSU = Software Komputer Satuan
COTS = Commercial-Off-the-Shelf CSCI = Konfigurasi
memasukkan Software Komputer Barang HWCI = Konfigurasi Hardware Barang
Konfigurasi NDI = Non-Developmental Barang
COTS NDI Produk
item
Produk Produk AFP
Sertakan *

HWCIs CSCIs CSC CSUs

terpadu
ke*
sistem Developmental
Konfigurasi

integra t ed di t Hai*

Diintegrasikan ke *

Dimana:

* = Sistem / Aplikasi Dependent

= Mungkin atau mungkin tidak terdiri dari
Yang ada, internal Dikembangkan, Komponen Reusable

Gambar 16.1 Konfigurasi Sistem Identifikasi Elemen

memiliki terbukti solusi desain, dan memerlukan verifikasi, CI biasanya memerlukan spesifikasi
yang menspesifikasikan dan batas
kemampuan dan kinerja.
Sebuah CI, sebagai item besar seperti Produk, Subsystem, atau Majelis,
mengintegrasikan item tingkat yang lebih rendah - entitas atau komponen - yang mungkin
terdiri dari kombinasi dari AFP, produk COTS, NDIS, dan dua jenis lainnya yang
dikembangkan oleh in Sistem Developer rumah:
• Untuk item yang ditunjuk sebagai HWCI, persyaratan didokumentasikan dalam
HWCI Persyaratan Spesifikasi (HRS). Biasanya, ruang lingkup masing-
masing HRS alamat hanya satu HWCI.
• Untuk item yang ditunjuk CSCI, persyaratan biasanya didokumentasikan
dalam CSCI Persyaratan Software Spesifikasi (SRS). Biasanya, ruang
lingkup masing-masing SRS alamat hanya satu CSCI.

Pedoman ini untuk HWCIs dan CSCIs dapat berkembang dari waktu ke waktu. Selalu
• Konfigurasi Hardware Produk (HWCIs) berkonsultasi kontrak Anda dan Project Engineer untuk bimbingan.
• Konfigurasi Software Komputer Produk (CSCIs)

16.3.2 HWCIs dan CSCIs

Spesifikasi CSCIs dan HWCIs
HWCIs item hardware utama dan CSCIs adalah aplikasi perangkat lunak utama
yang ditunjuk untuk kontrol konfigurasi formal. Menggunakan mobil sebagai contoh: Secara tradisional, salah satu spesifikasi mendokumentasikan sebuah

HWCI atau CSCI. Dalam konteks itu, Sistem Acquirer dapat dengan mudah
• HWCIs mungkin terdiri dari penggunaan akhir Systems, Produk, atau SEPATAH KATA
memperoleh HWCI tunggal atau CSCI. Untuk alasan yang aneh, beberapa
Perhatian 16,1

Assemblies seperti mesin, sistem komputer misi, sistem hiburan, dan
sebagainya.
• CSCIs mungkin terdiri dari perangkat lunak penggunaan akhir operasi pada
komputer seperti komputer misi, Anti-Lock Braking System (ABS) komputer
terdistribusi, dan lain sebagainya.
Mengacu pada Gambar 16.1, seorang HWCI atau CSCI dapat terdiri dari produk COTS,
NDIS, AFP dikembangkan secara internal atau barang warisan, atau kombinasi dari ini.
hari ini dokumen perusahaan beberapa HWCIs atau CSCIs dalam spesifikasi tunggal
seperti HRS atau SRS. Yang mungkin dapat diterima untuk pengembangan ketat
internal terutama perangkat lunak. Namun, Anda pasti tidak akan mengirim SRS
menetapkan semua CSCIs Anda ke pesaing Anda ketika persyaratan untuk satu dan
hanya satu CSCI diperlukan - ya, pesaing lakukan tim bersama-sama. Pikirkan cerdas
sebelum Anda memutuskan untuk mendokumentasikan beberapa CSCIs dalam SRS
tunggal. Praktek Teknik tradisional mengatakan menghindarinya!
 MEMAHAMI KONFIGURASI SEMANTIK IDENTIFIKASI 349

Batas 16.3.3 CI Ketika aplikasi perangkat lunak mencapai kematangan dan siap untuk instalasi
akhir pada SBC, kode CSCI ini secara elektronik diprogram ke dalam perangkat
CI Batas Prinsip firmware, baik secara terpisah atau sekali diinstal pada SBC. Setelah diprogram,
firmware adalah:
CI dibatasi dengan batas-batas batas fisik seperti
Subsystem, Majelis, Subassembly, HWCI, CSCI,
prinsip 16.2
• Ditunjuk sebagai HWCI.
atau Bagian; mereka tidak secara fisik ada di luar batas itu.
• Diberi nomor bagian, nomor seri, versi, dan tanggal.

Item dan CI tidak harus dipartisi melintasi batas-batas perangkat fisik; ini adalah
pelanggaran Prinsip 16,2 dan dibahas kemudian dalam Gambar 27.8. Secara umum,
Kedua CSCI dan HWCI dikendalikan sesuai dengan prosedur
CI:
manajemen perubahan CM formal.
• Dibatasi oleh SPS, EDS, HRS atau CSCI SRS.
N Diskusi sebelumnya memperkenalkan semantik
• Berada dalam batas-batas item-seperti Sistem, Subsistem, Majelis,
identifikasi konfigurasi. Kami tindak diskusi
atau Subassembly seperti sistem fisik komputer, papan sirkuit cetak, E

menggambarkan mengapa sifat referensial semantik Identifikasi

atau aplikasi perangkat lunak.
SW Konfigurasi bila diterapkan ke tingkat
Heading 16,1
• Harus diverifikasi kesesuaian terhadap HRS masing-masing atau SRS.
abstraksi kadang-kadang mengakibatkan kebingungan.

Untuk menggambarkan hal ini, perhatikan contoh hipotesis di bawah ini. 16.3.5 Konfigurasi Semantik Sintesis

Untuk memahami bagaimana Identifikasi Konfigurasi semantik berhubungan dengan

arsitektur sistem multi-level, Gambar 16.1 dan
Komputer Perangkat Lunak Pengolah Kata
16.3 menggambarkan Hubungan Entitas (ER). Tabel 16.1 memberikan
Aplikasi Contoh
daftar aturan ER yang mengatur pelaksanaan grafis ini.
Asumsikan Anda bertugas untuk mengembangkan aplikasi
contoh 16.1 perangkat lunak pengolah kata untuk
N Pada saat ini, kami telah menetapkan kerangka
Peralatan Elemen sistem komputer desktop yang (HWCI) dan printer (HWCI)
semantik untuk memahami Cls. Pertanyaannya adalah: Bagaimana kita
yang dikembangkan oleh proyek Anda. Tim menunjuk aplikasi pengolah kata E

menentukan item mana yang harus ditunjuk

sebagai CSCI. Ketika dipasang dengan benar, Firman Processing CSCI berada
SW sebagai Cls?
pada Sistem Komputer Desktop (HWCI), bukan Printer (HWCI). Ketika pengolah
Heading 16,2 Ini membawa kita ke topik berikutnya pada Pemilihan CI.
kata Pengguna memutuskan untuk mencetak dokumen, Firman Processor CSCI
memanggil layanan (HWCI) sistem operasi Sistem Komputer Desktop untuk
mentransfer dokumen ke
16.3.6 Pemilihan CI
Printer CSCI untuk pencetakan.
Diskusi sebelumnya menetapkan bahwa CI biasanya item, terutama item utama,
mengembangkan internal untuk Sistem Developer. Sementara ini adalah kriteria

16.3.4 Firmware penting, CI sering membutuhkan pertimbangan tambahan. Pendekatan terbaik untuk
memilih CI adalah dengan hanya menetapkan satu set kriteria seleksi. Kemudian,
Beberapa aplikasi berbasis prosesor seperti Single-Dewan Komputer (SBC) software
melakukan cek kewajaran untuk memastikan
mempekerjakan dikodekan ke dalam Integrated Circuit (IC) disebut sebagai firmware. Firmware,
bahwa seleksi:
yang merupakan perangkat memori nonvolatile, dapat diimplementasikan sebagai tunggal digunakan,
read-only, atau perangkat diprogram ulang seperti yang ditunjukkan
pada Gambar 16.2. 1. Apakah logis.

2. Menyediakan visibilitas yang tepat mengenai teknis, biaya, dan kinerja

Awalnya, sebuah program perangkat lunak yang akan dieksekusi oleh SBC
dikembangkan sebagai aplikasi perangkat lunak CSCI dan debugged pada prototipe laboratorium
SBC hardware menggunakan emulator dan perangkat lainnya. Emulator hardware pada perangkat
pengembangan perangkat lunak biasanya memiliki kabel dengan konektor yang dihubungkan ke
soket di mana sebuah mikroprosesor akan berada di papan PC. Sebagai hasil emulator - meniru
sebenarnya prosesor - dapat melaksanakan SBC I / O, memori, dan lain sebagainya sebagai
bagian dari proses debugging software.
jadwal; risiko; dan kontrol konfigurasi.
3. Paparan kegiatan pembangunan pada tingkat yang dapat digunakan untuk menilai
risiko.
Beberapa organisasi menetapkan kriteria khusus untuk memilih CI yang
melampaui hanya memutuskan untuk mengembangkan item internal.
keputusan ini harus dibuat bekerja sama dengan CM proyek.
350 SISTEM IDENTIFIKASI KONFIGURASI DAN KOMPONEN SELEKSI STRATEGI

Komputer
Software
Konfigurasi
Barang (CSCI)

firmware

pemrograman
Alat

XXX-YYYY-2
Konfigurasi
Hardware Barang
(HWCI)

Gambar 16.2 Evolusi Firmware dari Software untuk Hardware

Terdiri
ditunjuk
dari Commercial- Cons saya st s Hai f
sebagai
Off-the-Shelf
produk
(COTS) Item (s)

Ditunjuk
sebagai
Sistem kontra saya s t s dari

dDitiunjuk Konfigurasi (CI)

sebagai
Produk (NDIS)
Subsistem
Kesatuan
Produk Non
Perkembangan consis t s dari
ditunjuk
sebagai

terdiri
dari
Sidang ditunjuk solusi Set
sebagai
Terdiri dari
subassemblies SLoalu si Fisik
PerirluatkaunSolusi CSCI (s)
HWCI (s) syaratan
operasional
ditunjuk Solusi
sebagai
Bagian
Acquirer Terdiri
Terdiri dari dari
Furnished
Terdiri dari Properti
Dimana: (AFP)

= Mei atau mungkin tidak

Gambar 16.3 Item / CI komposisional Entity Hubungan (ER)

Pemilihan CI sering bervariasi dari satu organisasi atau domain bisnis yang 2. Akan CI penunjukan meningkatkan tingkat yang diperlukan kontrol dan
lain. Untuk standarisasi berpikir tentang memilih CI, MIL-HDBK-61A, misalnya, verifikasi kemampuan ini?
menawarkan bimbingan berikut dalam memilih CI: 3. Akan item membutuhkan pengembangan desain baru atau modifikasi yang signifikan

untuk desain yang sudah ada?

4. Apakah item perangkat keras komputer atau perangkat lunak?

1. Apakah item menerapkan kemampuan kritis (misalnya, perlindungan keamanan, 5. Apakah item menggabungkan teknologi terbukti?

menghindari tabrakan, keselamatan manusia, keselamatan nuklir)? 6. Apakah item memiliki antarmuka dengan CI dikembangkan di bawah kontrak
lain?
 MEMAHAMI KONFIGURASI SEMANTIK IDENTIFIKASI 351

TABEL 16.1 Konfigurasi Semantik Aturan

Aturan Judul Konfigurasi Identifikasi dan Pengembangan Peraturan

16-1 Item Setiap komponen fisik dalam sebuah sistem, terlepas dari tingkat abstraksi, disebut sebagai barang

16-2 CI item di semua tingkat abstraksi yang dipilih untuk intern pengembangan disebut sebagai CI

16-3 CI item berasal dari beberapa jenis sumber:

1. direplikasi dari desain komponen warisan yang ada

2. Acquired sebagai COTS, NDI, atau AFP komponen atau bahan

3. Acquired sebagai COTS, NDI, atau AFP komponen atau bahan dan dimodifikasi di rumah

4. Dikembangkan sebagai desain baru seperti HWCI (s) atau CSCI (s)

16-4 CI Komposisi Komposisi CI dapat terdiri dari satu atau produk COTS lebih, NDIS, HWCIs, CSCIs, AFP, atau
kombinasinya

16-5 HWCIs dan CSCIs Mengembangkan HRS untuk setiap HWCI; mengembangkan CSCI SRS untuk setiap CSCI

16-6 CI Solusi Domain Setiap CI, HWCI, dan CSCI dicirikan dengan Empat Domain Solutions (Bab 11 dan 14)
Persyaratan Domain, Domain Operasi, seorang Perilaku Domain, dan Solusi Fisik Domain

16-7 CSCIs Struktur Produk untuk setiap CSCI terdiri dari setidaknya dua atau lebih Komponen Software Komputer
(CSC), yang masing-masing terdiri dari setidaknya dua atau lebih Unit Perangkat Lunak Komputer (CSUs)

16-8 Kepemilikan CI Setiap CI, HWCI, dan CSCI harus ditugaskan untuk individu bertanggung jawab atau tim yang bertanggung jawab untuk perusahaan

desain, pengembangan, dan integrasi dan verifikasi

7. Dapat item dengan mudah ditandai untuk mengidentifikasi sebagai terpisah, barang
dikendalikan?
8. Apakah antarmuka barang dengan CI dikendalikan oleh aktivitas desain
lain?
9. Apakah akan perlu untuk memiliki catatan yang akurat dari konfigurasi yang
tepat item dan status perubahan selama siklus hidupnya?
Pada titik ini, kami telah membentuk set dasar Konfigurasi semantik
Identifikasi dan bagaimana mereka diterapkan ke arsitektur sistem
multi-level. Diskusi ini menyoroti kebutuhan selama pengembangan internal untuk
mempersiapkan EDS untuk setiap CI, HWCI, dan integrasi. Untuk artikel
pertama yang diproduksi sebagai bagian dari konfigurasi Developmental, ini
adalah proses langsung. Namun, dua pertanyaan kunci muncul:

10. Bisa (atau harus) item akan diuji secara independen? • Bagaimana spesifikasi ini dipertahankan untuk sistem produksi yang berevolusi

11. Apakah item yang diperlukan untuk dukungan logistik? dari waktu ke waktu sebagai kemampuan baru dan perbaikan ditambahkan ke
desain didirikan sebagai model baru atau versi?
12. Apakah itu, atau apakah itu memiliki potensi yang akan ditunjuk untuk pengadaan terpisah?

13. Apakah kegiatan yang berbeda telah diidentifikasi untuk logistik

• Bagaimana dampak tersebut mempengaruhi sistem atau produk yang sudah menerjunkan
mendukung berbagai bagian dari sistem?

14. Apakah item pada tingkat yang sesuai untuk kontrol konfigurasi tetapi mungkin memerlukan perkuatan? Ini membawa kita ke topik berikutnya, Konfigurasi

Pemerintah? (MIL-HDBK-61A, Tabel 5.2. Efektivitas.

p. 5-8)
16.3.8 Konfigurasi Efektivitas

16.3.7 Identifikasi Konfigurasi Tanggung Jawab sistem produksi atau produk dapat berkembang selama beberapa tahun sebagai

Konfigurasi Identifikasi, sebagai proses pengambilan keputusan, multidisiplin,,

teknologi yang lebih baru, kemampuan, dan perbaikan dimasukkan ke dalam evolusi

membutuhkan kolaborasi dengan pemangku kepentingan. Bertentangan dengan

Desain Sistem Solution. Dengan demikian, kemampuan dan CI bisa berubah.

apa yang banyak orang percaya, itu bukan keputusan satu individu menjalankan
Pertanyaannya menjadi: Bagaimana kita menggambarkan perubahan konfigurasi

kewenangan diskresioner mereka tanpa masukan dari pemangku kepentingan keputusan untuk diberikan CI, HWCI, atau CSCI? CM membahas konfigurasi ini melalui konsep

kunci. Sebagai sistem multi-level atau badan arsitektur berkembang, CM, Software disebut sebagai konfigurasi efektifitas?

Configuration Manager (SCM), LSE, lead tim pengembangan, dan lain-lain bekerja
sama untuk menetapkan kriteria untuk item mengidentifikasi dan CI dan menghindari
tindakan korektif mahal. Setiap CI, HWCI, dan CSCI secara resmi ditugaskan unik
identifier yang menggambarkan dari semua orang lain. Contohnya termasuk (1) nomor
model dan (2) nomor seri. Sebagai Sistem atau
352 SISTEM IDENTIFIKASI KONFIGURASI DAN KOMPONEN SELEKSI STRATEGI
konfigurasi fisik produk berevolusi selama bertahun-tahun membutuhkan perubahan
pada SPS, HRS, atau SRS, ada kebutuhan untuk menggambarkan barang-barang dari
para pendahulu mereka. Secara umum, organisasi hanya referensi efektifitas dimulai
dengan Serial Number XXX; lain menambahkan “sejumlah dash” pada nomor model
seperti Model 123456-1 untuk menunjukkan versi tertentu. Kebanyakan Usaha
membubuhkan label barcode untuk CI, HWCIs, andCSCIs untuk memfasilitasi versi scanner
otomatis atau pelacakan konfigurasi.
versi menyediakan Pengembang Sistem beberapa pilihan: (1) memungkinkan
evolusioner pelacakan dari lini produk selama masa hidupnya dan (2) menyediakan
sarana untuk memperhitungkan kustomisasi khusus dikirimkan ke Acquirer. Sebagai
pengganti nomor model dan versi, beberapa vendor mungkin diperlukan untuk
merancang dan label item dengan nomor kontrak, nomor seri, dan informasi lainnya.
Berikut ini adalah contoh.
Sistem atau Badan CI Pelabelan
Pengembang sistem militer mungkin diperlukan untuk
menginstal CI label sesuai dengan versi saat
contoh 16.2 MIL-STD-130.
pelabelan produk komersial mungkin diperlukan sesuai dengan pemerintah atau
industri standar seperti Underwriters' Laboratories (UL).
Perubahan diversi melalui gambar baru, daftar bagian, dll dan diberi label sesuai.
Tapi apa yang terjadi pada SPS, HRS, atau SRS yang berfungsi sebagai sumber
atau persyaratan yang berasal untuk lini produk? Ini membawa kita ke kami Spesifikasi
Topik selanjutnya, Efektivitas Berbasis.
16.3.9 Spesifikasi Efektivitas Berbasis
Selama pengembangan Sistem atau Produk, SES multi-disiplin
mempersiapkan EDSS untuk Produk atau Subsistem, HRSS untuk HWCIs, dan
SRSs untuk CSCIs yang membentuk konfigurasi Developmental.
Meskipun biaya merupakan kendala utama, sebagian besar sistem artikel pertama
atau produk mungkin tidak mewakili solusi yang paling hemat biaya karena jadwal
dan kendala lainnya. artikel pertama hanya solusi Teknik yang sesuai dengan
persyaratan spesifikasi. Biasanya, setiap deliverable ditugaskan kontrak, model,
dan nomor seri.
Jika sistem direncanakan untuk produksi, Produk Rekayasa berfokus pada
pengurangan berulang biaya per unit produksi melalui perbaikan desain,
komponen dan bahan seleksi dan pengadaan, metode manufaktur, dan lain
sebagainya. Selanjutnya, perbaikan berujung pada EDSwith efektifitas
direvisi dimulai dengan S / N XXX maju.
Setelah mulai produksi, CI, HWCIs, dan CSCIs berkembang dari waktu ke
waktu. Sedangkan selama pengembangan sistem yang asli, revisi spesifikasi
Developmental Konfigurasi dikeluarkan ketika perubahan terjadi. Jadi, ketika
produksi
perubahan item yang terjadi, Anda harus merevisi tidak hanya tingkat spesifikasi tetapi juga
ruang lingkup efektifitas S / N.
Ketika ini terjadi, SES dihadapkan dengan keputusan.
Apakah kita (1) membuat spesifikasi baru yang unik untuk efektifitas konfigurasi tertentu -
model dan S / Ns atau (2) memperbarui spesifikasi asli untuk menggambarkan yang
persyaratan berlaku untuk model tertentu dan nomor seri efektifitas dalam dokumen? Update
Pendekatan memungkinkan persyaratan untuk disimpan dalam satu dokumen, tetapi dapat
menjadi membingungkan dan sulit untuk mengelola dari waktu ke waktu.
16,4 KONFIGURASI ITEM (CI) IMPLEMENTASI
16.4.1 Menyelaraskan CI dengan Pohon Spesifikasi
Setelah CI diidentifikasi, pertanyaan kunci adalah: Bagaimana Anda menentukan lokasi
mereka dalam struktur produk sistem? Jawabannya adalah: CI harus secara eksplisit
diidentifikasi di Pohon Spesifikasi berdasarkan pada komponen itu menentukan dalam
Arsitektur System hirarkis PBS seperti yang ditunjukkan pada Gambar 16.4.
Di sini, Tim Pengembangan Sistem (SDT) menganalisis persyaratan SPS untuk
menciptakan arsitektur SystemLevel, seperti yang ditunjukkan di sudut kiri bawah
grafik. Arsitektur terdiri dari Produk A dan B. Produk B, yang akan dikembangkan
secara internal, ditunjuk sebagai CI yang terdiri dari Produk B_1 melalui B_3.
Sebagai arsitektur sistem berkembang, pohon spesifikasi berubah sesuai
seperti yang ditunjukkan di sisi kanan grafik. Berdasarkan penunjukan CI dan
barang-barang, EDSS diidentifikasi:
• Persyaratan untuk Produk A ditentukan dalam Produk A
Pengembangan Spesifikasi.
• Persyaratan untuk Produk B ditentukan dalam Produk B
Pengembangan Spesifikasi.
Sebagai arsitektur Produk B berkembang, Produk B_1-B_3 diidentifikasi sebagai komponen
arsitektur. Studi perdagangan dilakukan untuk setiap item untuk menentukan apakah mereka yang
tersedia sebagai produk COTS, dikembangkan secara internal, diperoleh eksternal, dan
sebagainya:
• Sejak Produk tertentu persyaratan B Pembangunan Keterangan dapat
dipenuhi oleh dua produk COTS terpisah, Produk B_1 dan B_2 diidentifikasi
dan akan diperoleh sebagai produk COTS dari vendor yang berbeda.
• Sisanya Produk persyaratan B Pengembangan Keterangan akan ragu-
ragu dialokasikan untuk Barang B_3. Persyaratan dianalisis dan
keputusan dibuat untuk mengembangkan Barang B_3 internal sebagai CI
a. Dengan demikian, persyaratan dialokasikan dan mengalir turun dari
Produk B Pengembangan Spesifikasi Item B_3
 KONFIGURASI
MEMAHAMI KONFIGURASI SEMANTIK ITEM (CI) IMPLEMENTASI
IDENTIFIKASI 353

Sistem CI
Sistem Struktur Produk
Kinerja
Spesifikasi Sistem
(SPS)

produk A produk B
Konfigurasi konfigurasi Barang
Arsitektur Tingkat sistem
Barang

produk A
konfigurasi Barang
Item Item Item B_3
Konfigurasi
B_1 B_2
PRODUK B Barang
konfigurasi Barang

Item Item
B_1 B_2

Konfigurasi Produk B
Produk A Pengembangan
Barang Pengembangan
Pengembangan Produk B_3 atau
B_3 Spesifikasi
atau Spesifikasi Spesifikasi
Produk Produk

Gambar 16.4 Arsitektur sistem dan Struktur Breakdown Produk (PBS) Keterangan Pohon Konfigurasi
Dokumentasi nya

akan dimasukkan ke Item B_3 Pembangunan Spesifikasi. kompleksitas, dan risiko item multi-level, sebuah IPT dapat ditugaskan akuntabilitas
item seperti digambarkan pada Gambar 16.5. Akuntabilitas untuk mengembangkan Produk A
dan B, yang memiliki tingkat moderat kompleksitas dan risiko, ditugaskan untuk IPT # 1.
Sebaliknya, akuntabilitas untuk Produk C ditugaskan untuk IPT # 2 karena yang
16.4.2 Menetapkan Kepemilikan CI dan Produk
kompleksitas dan risiko. Hal ini membawa kita ke titik akhir.
Kepemilikan CI dan Akuntabilitas Prinsip

Proyek sering mendapatkan kesulitan karena mereka membangun

Setiap Konfigurasi Barang (CI) harus diserahkan
prinsip 16.3 fungsional memproyeksikan struktur tim organisasi - EE, ME, SWE, dan
kepada pemilik jawab atas nya
sebagainya - sebagai gantinya menggunakan SystemArchitecture sebagai
desain, implementasi, integrasi & tes, verifikasi, dan validasi.
dasar untuk memperoleh struktur tim proyek. Dengan pengecualian SE,
organisasi fungsional proyek menjadi dekade usang lalu.

Seperti Pohon Keterangan berkembang, akuntabilitas untuk pengembangan CI harus

diserahkan kepada pemilik seperti PDT atau induktor interphasa. Gambar
16.5 memberikan contoh ilustratif. Perhatikan bagaimana arsitektur System terurai
sepanjang garis PBS. Ini adalah titik kunci, terutama kata kuncinya produk.
Untuk program yang menggunakan PDT atau induktor interphasa, setiap IPT berfokus
pada pengembangan “produk” dan bekerjasama dengan induktor interphasa
mengembangkan item yang antarmuka ke produk mereka ditugaskan. Misalnya, IPT # 1 melakukan kolaborasi
dengan IPT # 2 definisi antarmuka concerningmutual dan kompatibilitas desain
dan masalah interoperabilitas.
Organisasi proyek
Jika struktur organisasi proyek ini dikembangkan pertama, Produk A
dan B, yang telah benar-benar terpisah “end
contoh 16.3 menggunakan,” mungkin
semena-mena dan amateurishly dibundel bersama dan diberi label sebagai Produk atau Subsystem. Net
hasil-Sebuah tim ditugaskan untuk mengembangkan spesifikasi kebutuhan untuk dua entitas yang
berbagi tidak ada interface atau memiliki relevansi dengan satu sama lain.

Ingat bahwa prinsip-prinsip SE memerlukan Produk, Subsystem,

Akuntabilitas untuk mengembangkan satu produk ditugaskan untuk satu dan hanya satu PDT Majelis, dll terdiri dari serangkaian terpadu
atau IPT. Tergantung pada ukuran,
354 SISTEM IDENTIFIKASI KONFIGURASI DAN KOMPONEN SELEKSI STRATEGI

Konfigurasi
Sistem
Barang Hierarchy

Dimana: produk A produk B produk C

• CI = Konfigurasi Barang konfigurasi Barang konfigurasi Barang konfigurasi Barang
• PDT = Tim Pengembangan Produk

Barang Barang Barang B_3 Barang Barang

B_1 B_2 Konfigurasi C_1 C_2
Barang

Tanggung Jawab & PDT # 1 Ac c ountabi li ty PDT # 2 A c coun t abil saya t y

PDT
Akuntabilitas

CI Timbal ITEM B_1

PDT
#1 Memimpin ITEM B_2

P
Memimpin C
TIim
B_P3DTTim#ba
1l

PDT # 2
PDT
#2 ITEM C_1 Timbal ITEM C_2

Gambar 16.5 Konfigurasi Barang (CI) Tugas Akuntabilitas Matrix

komponen untuk menghasilkan hasil yang lebih besar dari masing-masing Secara umum, sistem sering terdiri dari dua kelas Produk atau
komponen dapat mencapai-misalnya, munculnya Subsistem:
(Bagian 3).
Kenyataannya adalah proyek mengembangkan “akhir penggunaan” Sistem, • Misi khusus Produk atau Subsistem - Misi Systems.
Produk, Subsistem, dan sebagainya yang membutuhkan multi-disiplin Teknik, bukan
“cerobong asap” disiplin. Akibatnya, proyek struktur organisasi biasanya didirikan di • Infrastruktur Produk atau Subsistem - Mengaktifkan Sistem
sepanjang lini produk penyampaian. Perhatikan contoh berikut.

16.4.3 Menyadari Jenis Batas Butir Arsitektur Gambar 16.6 mengilustrasikan jenis arsitektur. Perhatikan contoh berikut.

Subsistem Versus Mengaktifkan

Revolusi Industri memperkenalkan konsep-konsep baru untuk standardisasi
dan mereproduksi komponen modular dan saling dipertukarkan via berulang dan diprediksi
metode. Standardisasi memungkinkan kita untuk memanfaatkan manfaat skala ekonomi
dengan menyederhanakan jumlah komponen dan,
pada gilirannya, mengurangi biaya persediaan. diskusi kita tentang Sistem, Produk,
Subsystem, Majelis, Subassembly, dan tingkat Bagian abstraksi menjelaskan pada
tema ini.
Konsep modularitas dapat dengan mudah menyebabkan SE mind-set yang semua
item dan CI dibangun sebagai modular
Pasang dan mainkan kotak. Namun, ada sistem yang membutuhkan integrasi di
tradisional “kotak” batas-batas. Kita cenderung berpikir dalam hal struktur hirarkis murni
yang terdiri dari Subsistem rekan tingkat, Majelis, dan sebagainya. Hirarki, ini benar.
Namun, beberapa Subsistem tingkat rekan atau Sidang yang Mengaktifkan Sistem
menyediakan kemampuan yang mendukung rekan-rekan otherMission Sistem
yang melakukan misi tertentu.
subsistem
sistem gedung perkantoran telah didefinisikan dengan baik
misalnya 16,4 arsitektur “kotak” batas-batas terdiri
lantai dan area kantor yang unik untuk Usaha didukung oleh pipa dan listrik;
Pemanasan, Ventilasi, dan penyejuk udara (HVAC); komunikasi; dan
lain-lain merupakan bangunan infrastruktur sistem seperti yang ditunjukkan pada
Gambar 16,6. Sebagai ilustrasi, infrastruktur atau Mengaktifkan Subsistem
mengatasi dan mendukung masing-masing theMission Subsistem. Bahan
bakar, listrik, komunikasi, dan subsistem udara melintasi seluruh struktur-misalnya,
propulsi, kabin penumpang, dan penyimpanan subsistem-pesawat dan mobil.
16.4.4 Beberapa Contoh Implementasi CI
Meskipun kita cenderung berpikir bahwa setiap barang dalam suatu sistem unik, Sistem
dan Produk sering memiliki beberapa
 BASELINE KONFIGURASI PEMBANGUNAN 355

Misi Subsistem
Dimana:
Sistem Spesifik
HVAC = Pemanas, Ventilasi, & Ac

Subsistem kantor Subsistem Subsistem

infrastruktur Subsystem laboratorium laboratorium
konfigurasi Barang konfigurasi Barang konfigurasi Barang

Distribusi tenaga
subsistem
konfigurasi Barang

komunikasi
subsistem
konfigurasi Barang

HVAC
Subsystem
konfigurasi Barang

Fire Protection
Subsystem
konfigurasi Barang

Gambar 16.6 Arsitektur Sistem Ilustrasi Jalur vs lintas sektoral Configuration Items (CI)

contoh dari CI tunggal di seluruh sistem. Salah satu peran dari SE dan Seit adalah Desain muncul dan jatuh tempo ke titik dimana persyaratan desain seperti gambar dan
untuk mengurangi total biaya kepemilikan (TCO) - biaya pengembangan dan desain perangkat lunak
siklus hidup, jadwal, dan risiko. Anda melakukan ini dengan menyelidiki yg cukup secara rinci untuk mendukung pengadaan, fabrikasi, dan coding dari semua item dalam
mengembangkan sistem.

Desain Sistem Solusi dan mencari kesempatan untuk tingkat yang lebih rendah dari keputusan desain, sebagai perbaikan dari keputusan tingkat

membakukan komponen dan interface. Intinya adalah: menghindari “menciptakan yang lebih tinggi, benar-benar tergantung pada pematangan dan

kembali roda” dengan menciptakan desain CI khusus yang dapat dipenuhi oleh satu
desain CI umum. Bagaimana hal ini dapat dicapai?
Salah satu metode untuk standardisasi untuk reuse desain adalah dengan hanya
melakukan Analisis Domain Sistem atau Produk untuk mengidentifikasi kebutuhan desain
yang sama seperti peluang untuk memanfaatkan solusi, desain multi-tujuan tunggal dalam
perangkat keras atau perangkat lunak. Sebuah contoh umum terjadi dengan standarisasi
interface seperti protokol komunikasi data, sinyal-sinyal listrik, dan jenis layout mekanik.
stabilitas dari keputusan desain tingkat yang lebih tinggi (Prinsip 14,2). Jika tidak,
seluruh Solusi Desain Sistem berkembang menjadi multi-level kebingungan dan kekacauan.
Jadi, sebagai keputusan tingkat yang lebih tinggi menstabilkan, penting untuk menangkap
dan mengontrol keadaan solusi desain sistem berkembang disebut sebagai Konfigurasi
Developmental.
Primer Konfigurasi Baseline Prinsip

CM memandang setiap Sistem memiliki tiga Baseline

prinsip 16,4 Konfigurasi Developmental utama:
16,5 BASELINE KONFIGURASI PEMBANGUNAN

1. Persyaratan Sistem atau Dasar Fungsional

pengembangan sistem membutuhkan penjabaran abstrak persyaratan SPS menjadi 2. Alokasi Dasar
solusi fisik penyampaian. terjemahan terurai atau memurnikan kompleksitas 3. Produk Dasar
abstrak ke tingkat yang lebih rendah lebih mudah dikelola detail. Pada akhirnya, rinci
Sistem produksi memiliki Production baseline.
356 SISTEM IDENTIFIKASI KONFIGURASI DAN KOMPONEN SELEKSI STRATEGI

The Developmenta l Konfigurasi ditandai oleh serangkaian konfigurasi
“snapshot” yang menangkap berkembang Desain Sistem Solusi di tahap strategis
kematangan. manajemen dasar dari konfigurasi Developmental menyediakan
mekanisme untuk SES untuk mempertahankan “ kontrol intelektual ”(Prinsip 1,3 -
. McCumber dan Sloan, 2002, hal 4) dari yg mengembangkan dan jatuh tempo
Solusi Desain sistem melalui manajemen perubahan konfigurasi. Oleh karena itu,
ruang lingkup Konfigurasi Pembangunan mencakup periode waktu dari
pemberian kontrak sampai System atau Produk pengiriman dan penerimaan
atau kemudian berkomitmen untuk Produksi baseline.
sesuai dengan arah kontrak berwenang dan disediakan oleh Pejabat
Persetujuan Acquirer (ACO).
The “As-Ditentukan” Konfigurasi mewakili tambahan keadaan Sistem
berkembang, Subsystem, Majelis, dan persyaratan spesifikasi lain, kolektif dan
individual, yang terdiri Persyaratan Sistem Baseline Configuration
Developmental seperti yang berkembang dari waktu ke waktu. Contoh awal dari “As-
Ditentukan” Konfigurasi didirikan sebagai Persyaratan Sistem Dasar oleh
beberapa organisasi berdasarkan telaah formal dan persetujuan dari SPS oleh
Sistem Acquirer dan Sistem Pengembang di Sistem Ulasan Spesifikasi (SSR)
(Bab 18).

SE Desain Konfigurasi Prinsip

Setiap Sistem atau Badan pada setiap tingkat abstraksi memiliki delapan
konfigurasi desain SE: Sebagai Ditentukan, Sebagai Dialokasikan,
16.5.2 “As-Dialokasikan” Konfigurasi
prinsip 16,5 Sebagai De-
ditandatangani, Sebagai Dibangun, Seperti Terverifikasi, Sebagai Divalidasi, Sebagai dipertahankan, dan As The “As-Dialokasikan” Konfigurasi mewakili negara inkremental dari
Diproduksi yang harus saat ini dan konsisten satu sama lain. berkembang tambahan keadaan Sistem berkembang, Subsystem, Majelis, dan
persyaratan spesifikasi alokasi lain untuk item dalam arsitektur masing-
masing. Misalnya, alokasi:
Dari perspektif Pengembangan Sistem, ada serangkaian Sistem / Produk
Life Cycle Tahap ulasan teknis atau peristiwa yang menilai kemajuan, status,
dan kematangan Sistem Developmental Konfigurasi berkembang sebagai syarat
• persyaratan SPS untuk Subsistem dalam arsitektur Tingkat Sistem
untuk melakukan sumber daya untuk memulai
tahap pembangunan selanjutnya. Tabel 16.2 memberikan daftar kunci pementasan
• spesifikasi subsistem persyaratan untuk Sidang dalam arsitektur
subsistem Tingkat
atau titik kontrol.
Mari kita secara singkat synopsize masing-masing konfigurasi SE ini. Setiap
konfigurasi ditinjau, disetujui, baselined, dirilis, dan dikontrol melalui prosedur CM
16.5.3 “As-Dirancang” Konfigurasi Developmental
formal.
The “As-Dirancang” Konfigurasi mewakili negara tambahan berkembang Sistem,

16.5.1 “As-Ditentukan” Konfigurasi Developmental Subsistem, Majelis, dan dokumentasi desain rinci lain berasal dari spesifikasi
masing-masing di SystemRequirements Dasar. Contoh awal dari “As-Dirancang”
Konfigurasi dimulai dengan ulasan formal dan persetujuan Tingkat
SPS Kepemilikan Prinsip
Arsitektur Sistem oleh beberapa organisasi di SystemDesignReview (SDR)
Sebagai elemen kontrak, Sistem Acquirer memiliki dan (Bab 18).
kontrol SPS kontrak; yang SystemDeveloper
prinsip 16,6 mempertahankan SPS di

TABEL 16.2 Key Developmental Konfigurasi Staging Poin sebagai Fungsi Sistem / Produk Life Cycle Tahap

Konfigurasi perkembangan
Sistem Life Cycle Tahap Proses Baseline SE Ulasan teknis

Pengembangan sistem Desain sistem “Sebagai Ditentukan” Sistem Ulasan Spesifikasi (SSR)
Desain sistem “Sebagai Dialokasikan” Sistem Design Review (SDR)
Desain sistem "Seperti yang dirancang" Desain Tinjauan Kritis (CDR)
Komponen Pengadaan dan “Sebagai Dibangun” Verifikasi komponen
Pengembangan
sistem Verifikasi “Sebagai Verified” Sistem Verifikasi Ulasan (SVR)
sistem Validasi “Sebagai Divalidasi”

Produksi sistem Proses produksi “Sebagai Diproduksi” Produksi Kesiapan Ulasan (PRR)
Sistem Operasi, Pemeliharaan dan “Sebagai Maintained” Sistem menerjunkan

Memelihara kelestarian (OM & S)

 BASELINE KONFIGURASI PEMBANGUNAN 357

16.5.4 “As-Built” Konfigurasi Developmental dokumentasi, yang merupakan faktor risiko utama untuk Sistem Developer.

The “As-Built” Konfigurasi mewakili keadaan Developmental Konfigurasi dari setiap

fisik entitas seperti Sistem, Subsistem, Majelis, dan lain-lain yang telah:
16.5.8 “As-Diproduksi” Konfigurasi Produksi
1. procurato, dimodifikasi, dan / atau dikembangkan secara internal maupun eksternal.
The “As-Diproduksi” Konfigurasi mewakili keadaan Produksi Dasar yang digunakan
untuk memproduksi sistem atau produk dalam jumlah produksi. Contoh awal dari “As-
2. Secara fisik label dengan Model, Serial Number (S / N), dan versi
Diproduksi” Konfigurasi didirikan pada Ulasan Produksi Kesiapan (PRR) (Bab
sebutan.
18).
3. Secara formal diverifikasi untuk kepatuhan terhadap SPS, EDS, atau
persyaratan desain seperti gambar teknik, dll

16.5.9 Perkembangan Staging Konfigurasi atau Control

16.5.5 “As-Terverifikasi” Konfigurasi Developmental
Points

The “As-Terverifikasi” Konfigurasi mewakili negara tambahan dari

multi-level dokumentasi Developmental Konfigurasi dan sistem fisik pada
penyelesaian yang SystemVerification Ulasan formal (SVR) (Bab 18). Pada
tahap ini, “As-Ditentukan,” “As-Dirancang,” dan “As-Built” Konfigurasi harus identik masing-masing pihak memiliki dalam proses pengambilan keputusan, kita
konsisten satu sama lain, lengkap, dan compliant dengan multi-level
Persyaratan Sistem persyaratan spesifikasi baseline.
16.5.6 “As-Divalidasi” Developmental Konfigurasi
Sebagai theDevelopmental Konfigurasi berkembang melalui serangkaian tahapan desain
dan pengembangan, penting untuk menetapkan kesepakatan antara Acquirer,
Pengguna, dan SystemDeveloper tentang Sistem Desain Solusi berkembang dan
jatuh tempo. Tergantung pada jenis kontrak dan kuasa
melakukan ini melalui
pementasan atau titik kontrol.
Pementasan atau kontrol poin, yang terdiri dari tinjauan peristiwa teknis utama,
dimaksudkan untuk mewakili tahap kematangan solusi desain sistem berkembang karena
kemajuan dalam tingkat yang lebih rendah dari abstraksi atau rinci dari waktu ke waktu. Kami
melakukan ini melalui serangkaian Konfigurasi Baseline.

The “As-Divalidasi” Konfigurasi mewakili keadaan dokumentasi

Dari perspektif CM, ada empat baseline konfigurasi:
Developmental Konfigurasi dan sistem fisik sebagai divalidasi oleh Pengguna
atau Badan Uji Independen (ITA) yang mewakili Pengguna selama
Operasional Test dan Evaluasi (OT & E) di bawah lingkungan operasi
• Persyaratan sistem atau Dasar Fungsional
lapangan yang ditentukan dan kondisi .
• dialokasikan Dasar
• Dasar produk
• Dasar produksi
16.5.7 “As-Maintained” Developmental atau Produksi Konfigurasi

Perhatikan bahwa diskusi kami mengidentifikasi dua perspektif Konfigurasi

The “As-Maintained” Konfigurasi mewakili keadaan Konfigurasi Developmental berkembang dan jatuh tempo: (1) perspektif konfigurasi SE dan
Developmental atau Konfigurasi Produksi sistem menerjunkan atau produk sebagai (2) CMperspective. Meskipun semantik, kedua set berkorelasi seperti yang
dikelola oleh Pengguna atau perwakilan mereka yang ditunjuk. Dari Pengguna, SE, digambarkan dalam Tabel 16.2.
dan perspektif CM, kegagalan untuk menjaga
“As-Maintained” dokumentasi Konfigurasi saat ini dan disinkronisasi dengan sistem fisik
atau entitas adalah risiko utama daerah, terutama untuk sistem perkembangan
16.5.10 Konfigurasi Identifikasi dan Dasar Manajemen
direncanakan untuk produksi.
Ringkasan

Selama diskusi Identifikasi Konfigurasi kami, kami:

Pemeliharaan menerjunkan Dokumentasi
System Configuration • Memperkenalkan satu set CM istilah seperti item, CI, COTS, NDI, dan AFP.

The “As-Maintained” Konfigurasi adalah titik

Catatan penulis 16,2 pementasan penting untuk SE. ini • opsi yang diidentifikasi tersedia untuk mengembangkan item dan CI.

tidak luar biasa untuk Pengguna untuk melupakan mempertahankan Sistem atau
dokumentasi Produk karena kurangnya disiplin, manajemen, atau anggaran. • Mencatat bahwa CI dibatasi dengan batas-batas itu sendiri sebagai entitas
Hasilnya adalah Sistem fisik atau Produk yang tidak identik cocok konfigurasi fisik.
• Mengatasi masalah yang terkait dengan Konfigurasi Efektivitas.
358 SISTEM IDENTIFIKASI KONFIGURASI DAN KOMPONEN SELEKSI STRATEGI
Ini membawa kita ke topik berikutnya tentang bagaimana komponen dipilih
untuk Produk dan CI.
16,6 SELEKSI KOMPONEN DAN PENGEMBANGAN
Alokasi persyaratan SPS dan EDS untuk menurunkan item tingkat adalah sangat berulang
Proses didorong oleh keputusan pemilihan komponen. Secara umum, Sistem Pengembang
harus menjawab pertanyaan: Berapa nilai terbaik, biaya terendah, dan pendekatan risiko
yang dapat diterima untuk memilih komponen untuk memenuhi persyaratan kontrak?
1. Apakah ada di rumah, desain komponen dapat digunakan kembali sudah
tersedia?
2. Apakah kita mendapatkan komponen yang tersedia secara komersial dari vendor
eksternal?
3. Apakah ada komponen yang tersedia secara komersial yang memerlukan hanya
modifikasi kecil untuk memenuhi persyaratan kami?
4. Apakah kita mendapatkan komponen yang tersedia secara komersial dari vendor eksternal
dan memodifikasi mereka di rumah atau telah vendor memodifikasi mereka?
5. Apakah kita mendapatkan komponen dari Pengguna sebagai AFP?
6. Apakah kita membuat komponen di rumah sebagai perkembangan baru?
Tergantung pada hasil pertanyaan-pertanyaan ini dan
item persyaratan yang ditentukan, persyaratan awal mungkin harus dialokasikan kembali
untuk mendamaikan kemampuan yang disediakan oleh komponen komersial.
diskusi kita di bagian ini berfokus pada Komponen seleksi dan Pengembangan Praktek
yang mendorong SE pengambilan keputusan. Setelah diskusi singkat dari pilihan yang
tersedia untuk pengembangan sistem, kami memperkenalkan konsep COTS dan NDIS.
Berikutnya, kita mendefinisikan metodologi yang menjelaskan metode pengambilan
keputusan untuk memilih strategi untuk pengembangan komponen. Kami menyimpulkan
dengan ringkasan mengemudi masalah yang mempengaruhi COTS / NDI seleksi.
16.6.1 Mengurangi Biaya Sistem dan Risiko
Salah satu tujuan utama dari SE adalah untuk memperkecil TCO -
pengembangan dan siklus hidup - biaya serta risiko. Pencapaian tujuan ini memerlukan
strategi wawasan yang mencakup pemilihan komponen di semua tingkat
abstraksi.
Kebanyakan Engineers memasuki dunia kerja dengan aspirasi mulia untuk berinovasi
dan menciptakan anggun desain. Meskipun ini adalah sebagian benar, juga merupakan cerminan
dari prioritas disalahpahami. Desain baru harus resor setelah upaya untuk menemukan
komponen yang ada yang memenuhi persyaratan spesifikasi telah habis (Prinsip
4,19).
Desain sebagai Resort Prinsip terakhir
desain sistem dari CI baru harus menjadi pilihan terakhir setelah
semua upaya praktis telah habis untuk mengidentifikasi
prinsip 16,7 desain warisan
yang COTS dapat digunakan kembali, NDI, atau komponen AFP untuk memenuhi kebutuhan entitas.
Jadi, apa yang harus prioritas menjadi? Ini membawa kita ke Butir Desain
Implementasi Options dan Prioritas.
16.6.2 Barang Desain Implementasi Options dan
Prioritas
Froma CMperspective, setiap itemor entitywithin Sistem atau Produk, terlepas dari
tingkat abstraksi, secara generik disebut sebagai barang. Item berasal dari
setidaknya tujuh pilihan yang tersedia untuk Teknik pengembangan
komponen fisik:
Opsi # 1: Pengadaan Komponen (s) dari eksternal
Katalog vendor.
Opsi # 2: Pengadaan Penjual Komponen (s) dan cus-
tomize In-House
Pengadaan komponen dari katalog vendor dan menyesuaikan atau
beradaptasi di-rumah untuk complywith Teknik gambar.
Opsi # 3: Pengadaan Disesuaikan Komponen (s) dari
Penjual eksternal
Pengadaan komponen dari katalog vendor dan membayar mereka untuk
memodifikasi atau menyesuaikan sesuai dengan kontrak pengadaan dan
spesifikasi, dengan asumsi layanan ini tersedia.
Option # 4: Reuse Legacy Komponen Desain (s)
Pengadaan suku cadang, komponen, atau bahan baku dari pemasok eksternal. Kemudian,
fabrikasi, Merakit, Mengintegrasikan, dan Test (FAIT) di rumah dengan menggunakan
kembali yang ada, desain warisan.
Opsi # 5: Desain dan Mengembangkan Komponen Baru (s)
In-House
Desain komponen baru di-rumah; pengadaan suku cadang, komponen,
atau bahan baku dari pemasok eksternal; dan fait sesuai dengan komponen
persyaratan desain baru yang ditentukan dalam gambar teknik.
Option # 6: Subkontrak Komponen Baru (s) mengembangkan-
ment
Desain komponen di-rumah dan pengadaan dari vendor eksternal.
Opsi # 7: subkontrak Komponen New mengembangkan-
ment
Pengadaan desain komponen dan pengembangan dari
 SEMANTIK
BASELINE KONFIGURASI VENDOR PRODUK
PEMBANGUNAN 359

Sistem Pengembang eksternal sesuai dengan spesifikasi kinerja. properti - yang mungkin tersedia untuk dipertimbangkan sebagai pilihan desain atau dibutuhkan oleh kontrak
untuk dimodifikasi dan / atau terintegrasi ke dalam sistem penyampaian, mereka disebut sebagai Acquirer
Furnished Properti (AFP).
Legacy Reuse Masalah Desain

Maklum bahwa penggunaan kembali ada atau warisan

Acquirer Furnished Properti (AFP)
desain dapat hadir hukum dan kontraktual
SEPATAH KATA isu mengenai jenis pendanaan yang digunakan untuk
Perhatian 16,2 mengembangkan produk, hak data, dan sebagainya Ketika Sistem Acquirer melayani sebagai
sebagainya. Selalu berkonsultasi dengan Program, kontrak, dan organisasi kontrol ekspor kontrak Pengguna dan perwakilan teknis
hukum Enterprise Anda untuk bimbingan di daerah-daerah. Catatan penulis 16,3 memberikan prop- AFP
erty ke Sistem Developer, setiap item harus secara resmi login, ditandai,
dilacak, dan dikendalikan sesuai dengan Syarat dan Ketentuan (Ts & Cs) kontrak.
Berdasarkan pilihan desain / pengadaan tersebut, Solusi Desain Sistem untuk setiap Direncanakan modifikasi AFP biasanya memerlukan otorisasi tertulis
barang pada setiap tingkat abstraksi dalam Sistem atau Produk dapat terdiri dari satu atau oleh ACO. Pastikan bahwa Ts & Cs jelas menggambarkan yang bertanggung jawab untuk:
lebih kombinasi implementasi tersebut. Sebagai hasilnya, dipan / NDI / komposisi
perkembangan baru dari setiap pelaksanaan desain tergantung pada aplikasi seperti • Menyediakan set lengkap dokumentasi AFP
digambarkan pada Gambar 16.7. Perhatikan bahwa rentang pelaksanaan desain dari
• Berurusan dengan pemeliharaan AFP dan kegagalan sementara dalam
dua ekstrem: 100% COTS 100% pembangunan baru. Jadi, tantangan untuk Seit
kepemilikan Sistem Developer
dan pemilihan komponen pengambil keputusan adalah untuk menentukan kanan kombinasi
pilihan yang mengurangi TCO - pengembangan dan biaya siklus hidup - serta risiko.
1
16,7 VENDOR SEMANTIK PRODUK

Item diperoleh dari katalog vendor disebut sebagai produk COTS. Ketika Secara umum, ada dua kelas dasar produk vendor komersial: produk COTS

produk COTS dikontrak untuk menjadi disesuaikan atau diubah oleh vendor untuk dan NDIS. Ruang lingkup Mari masing-masing kelas.

aplikasi tertentu, mereka disebut sebagai Non-Developmental Produk (NDIS). Ketika

Sistem Acquirer menyediakan item -

16.7.1 COTS Produk

1 Rujukan-Untuk informasi tambahan tentang Membuat dibandingkan Beli dibandingkan produk COTS mewakili kelas produk yang dapat diperoleh dari katalog vendor
Beli-Memodifikasi keputusan, mengacu pada edisi terbaru dari Project Management Institute (PMI) Sebuah dengan nomor bagian. Pengadaan produk COTS dicapai melalui pesanan
Panduan untuk PMBOK ( PMBOK ®). pembelian atau

Pengembangan
baru
Solusi
Pendekatan Terbaik

Persyaratan Ruang
solusi New Hybrid Solusi
• xxxxxxxxxxxxxxxxx
COTS / NDI / Pengembangan
• xxxxxxxxxxxxxxxx Reuse baru
• xxxxxxxxxxxxxxxxx
• xxxxxxxxxxxxxx
Solusi Larutan
• ......
• xxxxxxxxxxxxxx
COTS-NDI-Reuse atau Pengembangan

Pendekatan COTS Solusi Terbaik

Rentang Solusi Alternatif

Gambar 16.7 Pengambilan Keputusan untuk Menemukan Optimal Mix dari COTS / NDI / Reuse / New Pengembangan Produk untuk
Memenuhi Konfigurasi Barang (CI) Teknis, Biaya Total Kepemilikan (TCO), Jadwal, dan Risiko Faktor.
360 SISTEM IDENTIFIKASI KONFIGURASI DAN KOMPONEN SELEKSI STRATEGI

mekanisme pengadaan lainnya. Umumnya, vendor menyediakan Sertifikat Kepatuhan Salah satu solusi adalah untuk membangun metodologi dasar yang
(C C) memverifikasi bahwa produk tersebut memenuhi persyaratan Spesifikasi Produk memfasilitasi pemilihan komponen didasarkan pada Analisis Alternatif (AoA)
yang diterbitkan. (Bab 32). Meskipun ada sejumlah cara metodologi dapat dibuat, Gambar 16,8
mengilustrasikan salah satu contoh.

16.7.2 NDIS

NDIS mewakili produk COTS yang telah dimodifikasi atau disesuaikan untuk
memenuhi seperangkat persyaratan Pengadaan Spesifikasi. Metodologi 16.8.1 COTS Seleksi
Pengadaan NDIS dicapai melalui pesanan pembelian yang referensi
Metodologi yang digunakan untuk memilih komponen barang dapat dijelaskan dalam enam langkah,
Keterangan pengadaan yang menentukan dan batas kemampuan dan kinerja dari
proses yang sangat berulang seperti digambarkan pada Gambar 16.8.
produk COTS yang dimodifikasi. Sebelum pengiriman, Sistem Pengembang
sebagai Acquirer (peran) memverifikasi NDI, di hadapan Acquirer (peran) saksi,
biasanya untuk kepatuhan dengan spesifikasi pengadaan.
• Langkah 1: Mengidentifikasi komponen kandidat.

∘ Langkah 1.1. Mengidentifikasi potensi di-rumah warisan

solusi desain dapat digunakan kembali.
16,8 KOMPONEN SELEKSI METODOLOGI
∘ Langkah 1.2. Menilai solusi in-house (s) kelayakan,
kemampuan, dan kinerja.
Pemilihan komponen untuk memenuhi kebutuhan EDS membutuhkan metodologi yang
∘ Langkah 1.3. Mengidentifikasi potensi COTS / NDI begitu- produk
memungkinkan tim pengembangan item untuk meminimalkan teknis, biaya, jadwal, dan
lution (s).
risiko. Secara umum, proses seleksi melibatkan menjawab pertanyaan-pertanyaan

yang diajukan selama pengenalan praktek ini. Jadi, bagaimana kita menjawab
∘ Langkah 1.4. Menilai COTS / solusi NDI (s) kelayakan,
kemampuan, dan kinerja.
pertanyaan-pertanyaan ini?
∘ Langkah 1.5. Menyelidiki kelayakan memodifikasi
produk COTS di rumah.

Negara
mengidentifikasi Calon Mengidentifikasi Potensi In-
awal
komponen Rumah Reusable
Solusi

• Sesuaikan Batas Solusi

Evaluasi Sistem
Ruang Kelayakan
Dampak Komponen
• EDS Pembaruan
pendekatan
diterima Reusable
? In-House
Solusi
Validasi Pendekatan tidak dapat diterima

Komponen seleksi
Mengidentifikasi Potensi
COTS / NDI Solusi

Modifikasi COTS menilai

Mintalah & Evaluasi COTS /
NDI vendor Proposal menilai Kelayakan

Solusi COT NDI Solusi

COTS S ?
NDI
Pilih Pengembangan Tidak
Komponen Pendekatan

Menilai In-House

Melaksanakan Pemilihan
Negara
Komponen Keputusan memodifikasi
akhir Baru Dev.
In-House COTS COTS Pengembangan
Modifikasi ? baru
Solusi Larutan

Gambar 16.8 Contoh Metodologi Pengembangan Komponen

 MENGEMUDI BASELINE
• Langkah 2: Evaluasi dampak keseluruhan dari pendekatan
komponen ke item dan kinerja sistem.
• Langkah 3: Validasi pendekatan pemilihan komponen (ulangi langkah 1).
• Langkah 4: Mintalah dan mengevaluasi vendor yang Cots / proposal NDI.
• Langkah 5: pendekatan pembangunan Pilih komponen.
• Langkah 6: Melaksanakan keputusan pemilihan komponen.
Persyaratan COTS Produk Rapat Keterangan
Hindari gagasan bahwa Anda hanya dapat menemukan solusi
SEPATAH KATA COTS “off-the-shelf” yang memenuhi persyaratan spesifikasi.
Perhatian 16,3 Anda mungkin dis-
menutupi Anda memiliki paradoks: pilih produk COTS yang cukup atau agak keluhan
dengan persyaratan spesifikasi versus produk NDI atau perkembangan baru yang
mungkin biaya dan / atau jadwal mahal.
Solusinya mungkin untuk menilai kembali persyaratan mengemudi, jika masuk akal
dan praktis, untuk mengakomodasi kemampuan COTS produk dan tingkat kinerja.
Boehm (. 2006, p 10) mengamati bahwa “COTS ekonomi umumnya
membuat proses terjun berurutan (di mana persyaratan sistem
pra-ditentukan menentukan kemampuan) tidak sesuai dengan COTS berbasis
solusi (di mana kemampuan COTS sangat menentukan persyaratan, sebuah
diinginkan kemampuan bukan persyaratan jika Anda tidak mampu solusi non-
COTS yang akan memberikan itu).”
16.8.2 Komponen Seleksi Ringkasan
Ketika komponen seleksi dan pengembangan pengambilan keputusan proses
selesai, masing-masing itemwithin multi-level Arsitektur Sistem hirarki dan
Struktur Breakdown Produk (PBS) mungkin memiliki kombinasi dari berbagai jenis
komponen seperti di rumah, COTS, NDI, atau AFP bahwa memenuhi
persyaratan spesifikasi dialokasikan untuk item.
Sekarang kami telah menetapkan metodologi dasar, mari kita periksa
beberapa isu mengemudi yang mempengaruhi COTS / NDI seleksi.
16,9 DRIVING ISU YANG MEMPENGARUHI COTS / NDI
SELEKSI
COTS / produk NDI mungkin atau mungkin tidak berlaku untuk aplikasi kontrak
Anda. Hanya Anda, Enterprise Anda atau proyek dan Acquirer / User, jika sesuai,
dapat membuat penentuan itu. Mari kita lihat contoh dari beberapa jenis pertanyaan
yang harus Anda pertimbangkan ketika memilih meminta COTS / produk NDI.
ISU YANG KONFIGURASI
MEMPENGARUHI COTS / NDI SELEKSI
PEMBANGUNAN 361
Akuisisi Pertanyaan COTS / Vendor NDI
Daftar pertanyaan yang mengikuti adalah contoh ilustrasi untuk
SEPATAH KATA
setiap kategori. Setiap set persyaratan Acquirer, aplikasi,
Perhatian 16,4
COTS / produk NDI, dan perspektif adalah unik. Konsultasikan dengan Subject Matter
Ahli (UKM) di Enterprise atau menggunakan jasa dari, konsultan kredibel berkualitas
pilihan Anda dan biaya untuk membantu Anda dalam merumuskan daftar pertanyaan.
Menyelidiki potensi produk COTS solusi dan melakukan due diligence sebelum Anda
berkomitmen untuk keputusan.
Jalur COTS Product Contoh Pertanyaan
1. Apa warisan, kematangan, dan masa depan dari garis COTS produk dan
keluarga?
2. Apa komitmen vendor dan perusahaan induk ke garis COTS produk dan
keluarga?
3. Apa ukuran COTS produk basis pengguna?
4. Apa Usaha atau industri adalah pengguna utama produk COTS?
5. Apa tren teknologi saat ini relatif terhadap arah lini produk?
6. Pada tahap apa kematangan adalah COTS produk dalam siklus jatuh tempo
serta pasar?
7. Berapa lama versi ini produk COTS diproduksi?
8. Apakah COTS produk di Alpha dan Beta testing? Jika tidak, berapa lama yang lalu itu
ini terjadi?
Kepuasan Pelanggan Contoh Pertanyaan
1. Apakah vendor bersedia untuk memberikan daftar referensi pelanggan untuk
mendiskusikan pengalaman mereka dengan produk?
2. Apa tingkat pelanggan satisfactionwith produk COTS saat ini dan versi
sebelumnya?
3. Do pelanggan testimonial, keluhan, dan aplikasi penggunaan
berkorelasi?
4. Apakah kepuasan pelanggan berdasarkan menggunakan produk sesuai
dengan lingkungan operasi yang ditentukan vendor?
16.9.1 Komitmen Perusahaan untuk dan Stabilitas COTS Produk
Contoh Pertanyaan
1. Berapa lama vendor akan berkomitmen atas kertas ke (1)
memproduksi dan (2) mendukung versi produk COTS
dipertimbangkan?
2. Bagaimana finansial yang stabil adalah vendor dan perusahaan induk?
362 SISTEM IDENTIFIKASI KONFIGURASI DAN KOMPONEN SELEKSI STRATEGI
3. Bagaimana stabil adalah tenaga kerja vendor (yaitu, omset) yang
mengembangkan dan mendukung produk COTS.
4. Untuk referensi di masa mendatang, yang adalah UKM vendor dan berapa
lama mereka telah dengan organisasi dan bekerja pada produk COTS?
5. Apa peran mereka relatif terhadap produk COTS?
Desain COTS Produk Contoh Pertanyaan
1. Dengan asumsi Anda memiliki beberapa tingkat akses ke
dokumentasi vendor, apa kualitas dan kedalaman dokumentasi produk
COTS?
2. Apa tingkat verifikasi dan validasi (V & V) telah dilakukan pada produk
COTS?
3. Apakah Verifikasi Produk dan Validasi (V & V) dilakukan secara internal, oleh
laboratorium independen, atau melakukan vendor bergantung pada komunitas
pengguna untuk “menemukan cacat”?
4. Apakah produk COTS telah mendokumentasikan tes diakses poin, tes kait,
titik masuk / keluar dalam desain? Apakah ini tersedia untuk para
pengembang dan pengelola?
5. Apakah produk COTS menggunakan antarmuka standar industri yang
sepenuhnya sesuai dengan standar atau hanya subset dari standar?
Apa pengecualian kepatuhan?
6. Apa kebebasan seperti interpretasi dan asumsi telah vendor diambil dengan
menerapkan standar?
7. Apakah vendor bersedia untuk memodifikasi antarmuka COTS produk untuk
memenuhi sistem atau antarmuka produk? Untuk apa gelar?
8. Apa sistem atau produk yang vendor menyatakan bahwa produk COTS
kompatibel dan interoperable dengan? Sebagai contoh, Microsoft
Windows, MAC OS, dan lain-lain.
9. Apa yang saat ini dikenal cacat di yang ada
produk COTS? Apakah ada rencana dan prioritas untuk memperbaikinya?
10. Berapa banyak dikenal dan cacat laten tetap berada di
saat ini versi produk “baru dan ditingkatkan”?
11. Berapa banyak berdokumen dan belum dicoba "fitur"
seperti cacat laten tidak dapat atau tidak akan diperbaiki tetap dalam
produk COTS?
12. Apa informasi dan “on call” desain rinci dukungan tersedia untuk mendukung
integrasi SystemDeveloper produk COTS ke dalam produk systemor
mereka? Apakah ada biaya yang diperlukan untuk dukungan ini?
13. Akan versi masa depan dari produk COTS menjadi maju dan mundur
kompatibel dengan versi saat ini sedang dipertimbangkan?
COTS Produk Contoh Produksi Pertanyaan
1. Apa kualitas dan disiplin dari COTS vendor
jaminan kualitas (QA) organisasi serta sistem CM dan kontrol versi, dengan
asumsi itu ada?
2. Apakah produk COTS serial dan dilacak untuk
upgrade dan penarikan?
Dukungan COTS Produk Contoh Pertanyaan
1. Apa tingkat dukungan 24/7 (yaitu, 24 jam per hari / 7 hari per minggu) adalah
vendor bersedia untuk mendukung produk COTS? Dari apa negara, zona
waktu, dan jam ketersediaan; Internet on-line dukungan dan
dokumentasi; dan “dukungan live” melalui 800 angka atau “membaca apa
yang on-line”?
2. Apa tingkat responsivitas untuk dukungan teknis
adalah vendor bersedia untuk memberikan (4 jam, satu minggu, dll)?
3. Apa tingkat aksesibilitas dengan produk COTS UKM
vendor bersedia untuk memberikan?
4. Apakah produk COTS memiliki Operasi dan Dukungan (O & S) dan
manual teknis?
5. Apakah Operasi dan Pemeliharaan (O & M) dan teknis manual disampaikan
dengan produk COTS, tersedia secara bebas on-line, atau apakah Anda harus
membeli mereka? Jika pembelian, bagaimana tersedia mereka?
6. Apa rencana yang vendor miliki untuk memelihara kelestarian produk COTS?
Berapa lama?
7. Apakah penjajaran dan kalibrasi prosedur dan data
didokumentasikan dan tersedia untuk Sistem Pengembang?
8. Apakah vendor menyediakan dukungan layanan lapangan? Bagaimana
responsif? kendala apa (hari dalam seminggu, liburan, jam, dll)?
9. Jika Anda membeli COTS / produk NDI, yang Anda diminta untuk
menghubungi vendor untuk melakukan layanan lapangan di lokasi untuk
“menghapus dan mengganti, menyelaraskan, dan mengkalibrasi,” atau dapat
System Developer melakukan ini?
10. Siapa yang membayar untuk layanan panggilan lapangan dan biaya?
COTS Garansi Produk Contoh Pertanyaan
1. Apakah setiap COTS produk ditutupi oleh menyatakan
atau garansi tersirat? Akan vendor memberikan salinan?
2. Apa tindakan atau fisik modifikasi oleh Acquirer tersebut
mungkin membatalkan atau kosong garansi pabrik?
3. Apa yang dapat diterima modifikasi Sistem Pengembang ke COTS produk
yang tidak membatalkan garansi?
4. Apakah vendor bersedia untuk memodifikasi produk COTS atau melakukan mereka
merekomendasikan pihak ketiga?

5. Apakah modifikasi pihak ketiga untuk dampak produk garansi? otorisasi apa yang
diperlukan untuk memodifikasi produk dan mempertahankan garansi
COTS Pengadaan Produk Contoh Pertanyaan
1. Apakah produk COTS membutuhkan lisensi penggunaan untuk
software, hardware, dan kontrol ekspor (Bab 18)?
2. Apakah lisensi berdasarkan pada basis per platform atau lisensi situs yang tersedia
dikenakan sejumlah maksimum “mengambang” pengguna?
3. Jika lisensi situs tersedia, bagaimana jumlah pengguna Pembatasan (
simultan, jumlah penduduk, jumlah yang tersedia “kunci,” dll)?
4. Apakah ada “lain dibundel” produk yang termasuk dalam produk COTS atau
harus diperoleh untuk biaya tambahan kecil? Apakah mereka memerlukan
lisensi?
5. Apakah ada buy minimum persyaratan kuantitas untuk
produk COTS?
6. Jika ada buy minimum, adalah ini pada per pembelian
dasar, kumulatif selama setahun, atau kumulatif selama beberapa tahun?
7. Apa jumlah adalah batas harga breakpoint?
8. Proses apa jaminan kualitas produk berada di tempat untuk
memastikan kualitas produk COTS?
9. Apa sertifikasi adalah vendor bersedia untuk memberikan re-
Garding integritas produk dan bahan-bahan yang?
10. Apakah COTS spesifikasi produk, proses, dan prosedur pengujian yang tersedia
untuk diperiksa dan pemeriksaan?
Peringatan Emptor Prinsip
Ketika pengadaan COTS / NDI, menyeluruh
menyelidiki dan memahami TCO - pengembangan dan
prinsip 16,8 siklus hidup - dan dukungan; jika tidak, caveat emptor -buyer berhati-
hatilah!
• Karena vendor hanya akan menjawab pertanyaan Anda bertanya, selalu bertanya
apa yang Anda perlu tahu tentang produk yang Anda mungkin tidak diminta.
• Akhirnya, caveat emptor -Biarkan pembeli berhati-hati!
Singkatnya, Anda, proyek Anda, dan Enterprise Anda sepenuhnya dan semata-
mata bertanggung jawab untuk keputusan yang Anda buat. Benar-benar melakukan 360 ∘
mencari semua faktor sekeliling
sebuah dipan / produk NDI atau jenis sistem, produk, atau layanan pemanfaatan
termasuk Stakeholder - Pengguna dan Pengguna Akhir ... sebelum ... Anda
membuat keputusan.
16,10 BAB RINGKASAN
Singkatnya, diskusi kami dalam Bab 16 berfokus pada System Configuration
Identifikasi dan Seleksi Komponen. Meskipun ditujukan sebagai sebuah bab, mereka
aturan yang mengikat
LATIHAN BAB
BASELINE KONFIGURASI PEMBANGUNAN 363
pengembangan Sistem architecting dan Arsitektur dibahas dalam Bab 26.
Bagaimana hal ini berhubungan dengan SE?
System Configuration Identifikasi dan Seleksi Komponen dapat disuling menjadi
tiga kata Dr. William McCumber. Tugas Anda sebagai SE adalah untuk
“mempertahankan kontrol intelektual” (McCumber dan Sloan, 2002, hal. 4) (Prinsip
1.3
- McCumber dan Sloan, 2002, hal. 4) Sistem Desain Solusi berkembang dan jatuh tempo.
melalui pengawasan manajemen dasar. Jika Anda gagal melakukan hal ini, Anda telah
kehilangan kendali proyek.
Misi Anda lainnya adalah untuk memastikan bahwa komponen fisik Desain Solution
Sistem yang dipilih, dibeli, atau dikembangkan untuk tidak hanya untuk memenuhi
persyaratan spesifikasi tetapi juga untuk memperkecil Biaya Total Kepemilikan (TCO) -
pengembangan dan siklus hidup biaya - dan mencapai risiko yang dapat diterima
dalam risiko anggaran, jadwal, dan teknologi. Pemilihan komponen-komponen
dapat berasal dari berbagai sumber.
COTS / solusi NDI mungkin menjadi pilihan tepat untuk Anda dan aplikasi Anda; dalam
kasus lain, mereka mungkin tidak menjadi. Sebagai SE memimpin proses seleksi, Anda harus
membuat keputusan berdasarkan:
1. Fakta dikuatkan oleh bukti-bukti lapangan.
2. Trade-off untuk memenuhi persyaratan, memperkecil mengembangkan-
ment dan biaya siklus hidup, dan mengurangi risiko ke tingkat yang dapat diterima.
3. Lain pengalaman aplikasi Pengguna. produk COTS bisa sangat ampuh untuk
mengurangi biaya pengembangan dan siklus hidup; mereka juga bisa menjadi masalah
besar juga. Mungkin cara terbaik untuk berpikir COTS adalah dengan menggunakan
analogi fatamorgana: memastikan bahwa apa yang Anda
menemukan ketika Anda menerapkan produk sesuai dengan gambar virtual Anda
dirasakan. Apapun keputusan yang Anda buat, Anda akan harus hidup dengan tindakan Anda
(s) dan konsekuensi. Pilihan komponen penelitian dan vendor
hati-hati dan teliti menggabungkan fleksibilitas untuk perencanaan kontingensi dan membuat
pilihan yang bijak. Intinya adalah caveat emptor -Biarkan pembeli berhati-hati!
16.11 LATIHAN BAB
16.11.1 Level 1: Bab Pengetahuan Latihan
Jawaban masing-masing dari Apa yang Harus Anda Pelajari dari Bab ini
pertanyaan yang diidentifikasi dalam bab Pendahuluan.
1. What is Configuration Management (CM)?
2. What are the four functions of CM?
3. What is Configuration Identification? Give examples.
4. What is Configuration Status Accounting (CSA)? Give
examples.
364 SYSTEM CONFIGURATION IDENTIFICATION AND COMPONENT SELECTION STRATEGY
5. What is Configuration Change Management?
6. If you wanted to know the current status of a drawing,
which of the four CM functions would provide the information?
7. What is a Developmental Configuration, when and
how does it evolve, and who is accountable for its establishment and
maintenance?
8. Delineate the differences between components, entities,
items, and CIs and their Entity Relationships (ERs)?
9. Who is responsible for identifying CIs?
10. What decision-making criteria are used to select CIs?
11. How do CIs relate to the specification tree?
12. What are COTS products and NDIs and how do they
relate to items and CIs?
13. What is a configuration baseline?
14. What is the relationship between baselines and the
Developmental Configuration?
15. What is meant by configuration effectivity?
16. Describe the evolution of the Developmental Configura-
tion and its baseline.
17. What is the “As-Specified” Configuration, and when is
it established?
18. What is the “As-Designed” Configuration, and when is
it established?
19. What is the “As-Built” Configuration, and when is it
established?
20. What is the “As-Verified” Configuration, and when is it
established?
21. What is the “As-Validated” Configuration, and when is
it established?
22. What is the “As-Maintained” Configuration, and when
is it established?
23. What is the “As-Produced” Configuration, and when is
it established?
24. What is the difference between Mission System versus
Enabling System CIs? What are their relationships. Using an office
building, automobile, and an aircraft, illustrate the relationships.
25. What is the difference between baseline management and
CM?
26. What are the six primary approaches for developing
components?
27. What is a COTS product?
28. What is a NDI?
29. What is AFP?
30. Who is the source of AFP?
31. How are COTS products procured?
32. How are NDIs procured?
33. What are the steps of the Component Selection Method-
ology?
34. What questions should you ask vendors that may have
products or services you are considering selecting?
16.11.2 Level 2: Knowledge Application Exercises
Refer to www.wiley.com/go/systemengineeringanalysis2e
16.12 REFERENCES
Boehm, Barry, (2006), “Some Future Trends and Implications for
Systems and Software Engineering,” International Council on Systems Engineering
(INCOSE), Journal of Systems Engineering, Vol. 9, No. 1, Malden, MA: John Wiley &
Sons, Inc. DAU (2012), Glossary: Defense Acquisition Acronyms and Terms,
15th ed. Ft. Belvoir, VA: Defense Acquisition University (DAU) Press. Retrieved
on 6/1/15 from http://www.dau.mil/
publications/publicationsDocs/Glossary_15th_ed.pdf FAA SEM (2006), System
Engineering Manual, Version 3.1, Vol.
3, National Airspace System (NAS), Washington, DC: Federal Aviation
Administration (FAA). McCumber, William H. and Sloan Crystal (2002), Educating Sys-
tems Engineers: Encouraging Divergent Thinking, Rockwood, TN: EagleRidge
Technologies, Inc. MIL-HDBK-61A(SE) (2001), Military Handbook: Configuration
Management Guidance, Washington, DC: US Department of Defense (DoD). MIL-
STD-498 (1994), Software Development and Documentation,
Washington, DC: US Department of Defense (DoD). SEVOCAB (2014), Software and
Systems Engineering Vocabulary,
New York, NY: IEEE Computer Society. Accessed on 5/19/14 from
www.computer.org/sevocab