Pengembangan Perangkat Lunak Dan Dokumentasi

Machine Translated by Google BUKAN PENGUKURAN
PEKA
MIL-STD-498
5 Desember 1994
(versi PDF)
Menggantikan
DOD-STD-2167A
29 Februari 1988
DOD-STD-7935A
31 Oktober 1988
DOD-STD-1703(NS)
12 Februari 1987
STANDAR MILITER
PENGEMBANGAN PERANGKAT LUNAK
DAN DOKUMENTASI
AMSC NO. N7069 AREA: IPSC/MCCR
PERNYATAAN DISTRIBUSI A. Aroved untuk distribusi rilis publik tidak terbatas.

Machine Translated
MIL-STD-498 (versi by Google
PDF) Kata pengantar Halaman ii
KATA PENGANTAR
1. Standar Militer ini disetujui untuk digunakan oleh semua Departemen dan Lembaga Departemen
Pertahanan.
2. Komentar bermanfaat (rekomendasi, tambahan, penghapusan) dan setiap data terkait yang mungkin
berguna dalam menyempurnakan dokumen ini harus ditujukan ke SPAWAR 10-12, 2451 Crystal Drive (CPK-5),
Arlington, VA 22245-5200. Tanggapan dapat disampaikan melalui surat atau dengan menggunakan Proposal
Perbaikan Dokumen Standardisasi (Formulir DD 1426) yang terdapat di bagian akhir dokumen ini.
3. Standar ini menggabungkan DOD-STD-2167A dan DOD-STD-7935A untuk menentukan serangkaian

aktivitas dan dokumentasi yang sesuai untuk pengembangan sistem senjata dan Sistem Informasi Otomatis.
Panduan konversi dari standar ini ke MIL-STD-498 disediakan di Lampiran I. Perubahan lainnya mencakup
peningkatan kompatibilitas dengan model pengembangan inkremental dan evolusioner; peningkatan kompatibilitas
dengan metode desain non-hierarkis; peningkatan kompatibilitas dengan alat rekayasa perangkat lunak
berbantuan komputer (CASE); alternatif untuk, dan lebih banyak fleksibilitas dalam, menyiapkan dokumen;
persyaratan yang lebih jelas untuk menggabungkan perangkat lunak yang dapat digunakan kembali; pengenalan
indikator manajemen perangkat lunak; penekanan tambahan pada dukungan perangkat lunak; dan tautan yang
lebih baik ke rekayasa sistem. Standar ini menggantikan DOD-STD-2167A, DOD-STD 7935A, dan DOD-
STD-1703 (NS).
4. Standar ini dapat diterapkan di setiap fase siklus hidup sistem. Ini dapat diterapkan pada kontraktor,
subkontraktor, atau lembaga internal Pemerintah yang melakukan pengembangan perangkat lunak.
Untuk keseragaman, istilah "pengakuisisi" digunakan untuk organisasi yang membutuhkan upaya teknis, istilah
"pengembang" untuk organisasi yang melakukan upaya teknis, dan istilah "kontrak" untuk kesepakatan di antara
mereka. Istilah "pengembangan perangkat lunak" digunakan sebagai istilah inklusif yang mencakup
pengembangan baru, modifikasi, penggunaan kembali, rekayasa ulang, pemeliharaan, dan semua aktivitas lain
yang menghasilkan produk perangkat lunak.
5. Standar ini tidak dimaksudkan untuk menentukan atau mencegah penggunaan metode pengembangan
perangkat lunak tertentu. Pengembang bertanggung jawab untuk memilih metode pengembangan perangkat
lunak yang mendukung pencapaian persyaratan kontrak.
6. Standar ini mengimplementasikan proses pengembangan dan dokumentasi ISO/IEC DIS 12207.
Standar ini menafsirkan semua klausul yang berlaku dalam MIL-Q-9858A (Persyaratan Program Kualitas) dan
ISO 9001 (Sistem Kualitas) untuk perangkat lunak.
7. Standar ini mencakup semua kegiatan yang berkaitan dengan pengembangan perangkat lunak. Itu
tidak memerlukan standar lain. Standar tersebut dapat diterapkan sendiri atau dilengkapi dengan standar lain,
seperti yang disebutkan dalam Bagian 6. Jika standar lain diterapkan, pihak pengakuisisi bertanggung jawab
untuk menyelesaikan setiap konflik yang timbul.
8. Deskripsi Item Data (DID) yang berlaku untuk standar ini tercantum di Bagian 6. DID ini menjelaskan
informasi yang diperlukan oleh standar ini.
9. Standar ini dan Deskripsi Item Data (DID) dimaksudkan untuk disesuaikan oleh pengakuisisi guna
memastikan bahwa hanya persyaratan yang diperlukan dan hemat biaya yang diterapkan pada upaya
pengembangan perangkat lunak. Panduan penjahitan umum dapat ditemukan di Bagian 6 dan di DOD-HDBK
248. Panduan penjahitan khusus untuk standar ini dapat ditemukan di Lampiran G dan H dan di buku panduan
dan buku pegangan yang direncanakan untuk standar ini.
1.Machine
RUANGTranslated
LINGKUP by ...............................................
Google .......... 1 1.1 Tujuan ............................................... ................ 1 1.2
Penerapan ............................................... .................... 1 Organisasi dan perjanjian .......................... .... 1
Aplikasi khusus kontrak .............................. 1 Menjahit ....... .............................................. 1 Interpretasi dari
1.2.1 istilah yang dipilih ...... ....................... 1 1.2.4.1 Pengertian “sistem” .................. ........ 1 1.2.4.2
1.2.2 Pengertian “berpartisipasi” dalam pengembangan sistem …… 2 1.2.4.3 Pengertian
1.2.3 “mengembangkan”, “menentukan”, dll......... ...... 2 1.2.4.4 Interpretasi "catatan" .........................
1.2.4 2 1.3 Urutan prioritas .... .............................................. 2
2. DOKUMEN REFERENSI .............................................. 3
3. DEFINISI ............................................... ...... 4
4. PERSYARATAN UMUM .............................................. 8 4.1 Proses pengembangan perangkat

lunak ................................... 8 4.2 Persyaratan umum untuk pengembangan perangkat lunak ....... ................. 8
4.2.1 Metode pengembangan perangkat lunak .......................... ... 8 4.2.2 Standar untuk produk perangkat
lunak ........................... 8 4.2.3 Produk perangkat lunak yang dapat digunakan kembali ... ............................
8 4.2.3.1 Memasukkan produk perangkat lunak yang dapat digunakan kembali ............. 8 4.2.3.2
Mengembangkan produk perangkat lunak yang dapat digunakan kembali ............... 9 Penanganan
kebutuhan kritis .............................. ......... 9 Jaminan keamanan .............................. 9 4.2.4.1
Jaminan keamanan . ............................ 9 4.2.4.2 4.2.4.3 Jaminan privasi ............ ...................
4.2.4 9 4.2.4.4 Kepastian persyaratan penting lainnya ............... 9 . 10 . 10 . 10
4.2.5 Pemanfaatan sumber daya perangkat keras komputer. . . . . . . . . . . . ... . . . . ...

4.2.6 Pencatatan alasan . . . . . . . . ... . . . . ... . . . . . . . . ... . . . . ...
4.2.7 Akses untuk tinjauan pengakuisisi. . . ... . . . . ... . . . . . . . . ... . . . . ...
5. PERSYARATAN RINCI . . . . ... . . . . . . . . . . . . . . . ... . . . . ... . . . . . . . . 11 .

5.1 Perencanaan dan pengawasan proyek . . . . . . . ... . . . . . ... . . . . . . . ... . . . . ... 12 .
5.1.1 Perencanaan pengembangan perangkat lunak. . . . . . . ... . . . . . . . ... . . . . ... 12 .
5.1.2 Perencanaan pengujian CSCI . . . . . . . . . . . . . . . . ... . . . . . . . ... . . . . ... 12 .
5.1.3 Perencanaan pengujian sistem . . . . . . . . . . . . . . . ... . . . . . . . ... . . . . ... 12 .
5.1.4 Perencanaan instalasi perangkat lunak . ... . . . . . ... . . . . . . . ... . . . . ... 12 .
5.1.5 Perencanaan transisi perangkat lunak . . ... . . . . . ... . . . . . . . ... . . . . ... 12 .
5.1.6 Mengikuti dan memperbarui rencana. ... . . . . . ... . . . . . . . ... . . . . ... 13 .
5.2 Membangun lingkungan pengembangan perangkat lunak. . . . . . ... . . . . . . . . ... 13 .
5.2.1 Lingkungan rekayasa perangkat lunak. . . . ... . . . . . . . . ... . . . . ... 13 .
5.2.2 Lingkungan pengujian perangkat lunak. . . . . . . . . . . . . . . . . . . . . ... . . . . ... 13 .
5.2.3 Perpustakaan pengembangan perangkat lunak. . . . . . . . . . . . . . . . . . . ... . . . . ... 13
Machine Translated
5.2.4 by Google
File pengembangan perangkat lunak. . . . . . . . . . . . . . . . . . . . ... . . . . ... . 13 .
5.2.5 perangkat lunak yang tidak dapat dikirimkan. . . . ... . . . . . . . . . . . . . . . ... . . . . ... 13 .
5.3 Analisis kebutuhan sistem . . . . . . . ... . . . . . . . . ... . . . . ... . . . . . . . 13 .
Analisis input pengguna. . 5.3.1 . . . . ... . . . . . . . . ... . . . . ... . . . . . . . 14
Konsep operasional . . . 5.3.2 5.3.3 . . . . ... . . . . . . . . ... . . . . ... . . . . . . . . 14 .
Persyaratan sistem . . . . . . . ... . . . . . . . . ... . . . . ... . . . . . . . 14 .
5.4 Desain sistem . 5.4.1 . . . . . . . . . . . . . . . . . . . .. . ... . . . ... . . . . . . . . ... . . . 14 .
Keputusan desain seluruh sistem . . . . . . . . . . . . . . . . . . ... . . . . ... 14 .
5.4.2 Perancangan arsitektur sistem . . ... . . . . . . . . . . . . . . . ... . . . . ... 14 .
5.5 Analisis kebutuhan perangkat lunak. . . . . . ... . . . . . . . . ... . . . . ... . . . . . . . 15 .
5.6 Desain perangkat lunak . . . . . . . . . . . . . . . . . . . . . . ... . . . ... . . . . . . . . ... . . . 15 .
5.6.1 Keputusan desain skala CSCI . . . . . . . . . . . . . . . . . . . . ... . . . . ... 15 .
5.6.2 Desain arsitektur CSCI . . . ... . . . . . . . . . . . . . . . ... . . . . ... 15 .
5.6.3 Desain detail CSCI . . . . . . . ... . . . . . . . . . . . . . . . ... . . . . ... 15 .
5.7 Implementasi perangkat lunak dan pengujian unit . . . . . . . . . . . . . . . . . ... . . . . ... 16 .
5.7.1 Implementasi perangkat lunak . 5.7.2 . . . ... . . . . . . . . . . . . . . . ... . . . . ... 16 .
Mempersiapkan pengujian unit . 5.7.3 . . . ... . . . . . . . . . . . . . . . ... . . . . ... 16 .
Melakukan pengujian unit . . 5.7.4 Revisi . . . . ... . . . . . . . . . . . . . . . ... . . . . ... 16 .
dan pengujian ulang . . 5.7.5 Menganalisis . . . . . . . . . . . . . . . . . . . . . . ... . . . . ... 16 .
dan mencatat hasil pengujian unit. . . . . . . . . . . ... . . . . ... 16 .
5.8 Integrasi dan pengujian unit . 5.8.1 . ... . . . . ... . . . . . . . . ... . . . . ... . . . . . . . 16 .
Mempersiapkan integrasi dan pengujian unit. 5.8.2 Melakukan . . . . . . . . . . ... . . . . ... 17 .
integrasi dan pengujian unit. 5.8.3 Revisi dan pengujian . . . . . . . . . . . ... . . . . ... 17 .
ulang . . 5.8.4 Menganalisis dan mencatat . . . . . . . . . . . . . . . ... . . . . ... . . . . . . . 17 .
integrasi unit dan hasil pengujian. . . . . . ... 17 .
5.9 Pengujian kualifikasi CSCI . . . ... . . . . ... . . . . . . . . ... . . . . ... . . . . . . . 17 .
5.9.2 Independensi dalam pengujian kualifikasi CSCI. 5.9.1 . . . . ... . . . . . . . . ... 17
Pengujian pada sistem komputer target. 5.9.3 Mempersiapkan . . . . . . . . . . . ... . . . . ... . 17 .
pengujian kualifikasi CSCI. . . . . . . . . . . . ... . . . . ... 17 .
5.9.4 Uji coba kualifikasi CSCI yang kering. . . . . . . . . . . . . . ... . . . . ... 18 .
5.9.5 Melakukan pengujian kualifikasi CSCI . 5.9.6 Revisi . . . . . . . . . . . . ... . . . . ... 18 .
dan pengujian ulang . . 5.9.7 Menganalisis . . . . . . . . . . . . . . . ... . . . . ... . . . . . . . 18 .
dan mencatat hasil tes kualifikasi CSCI. . . . . . . ... 18 .
5.10 Integrasi dan pengujian CSCI/HWCI . . . ... . . . . . . . . . . . . . . . ... . . . . ... 18 .
5.10.1 Mempersiapkan integrasi dan pengujian CSCI/HWCI . ... . . . . . . . . ... 18 .
5.10.2 Melakukan integrasi dan pengujian CSCI/HWCI . . . .. . . . . . . . . ... 18 .
5.10.3 Revisi dan pengujian ulang . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . ... 18 .
5.10.4 Menganalisis dan merekam integrasi CSCI/HWCI dan hasil pengujian . . . 19 .
5.11 Pengujian kualifikasi sistem . . ... . . . . ... . . . . . . . . ... . . . . ... . . . . . . . 19 .
5.11.1 Kemandirian dalam pengujian kualifikasi sistem. . . . ... . . . . . . . . ... 19 .
5.11.2 Pengujian pada sistem komputer target. . . . . . . . . . . . ... . . . . ... 19 .
5.11.3 Mempersiapkan pengujian kualifikasi sistem. . . . . . ... . . . . . . . . ... 19 .
5.11.4 Uji coba kualifikasi sistem secara kering. . . . . . . . . . . . . ... . . . . ... 19 .
5.11.5 Melakukan pengujian kualifikasi sistem . . . . . . . . . . . . ... . . . . ... 19 .
5.11.6 Revisi dan pengujian ulang . . . . . . . . . . . . . . . . . ... . . . . ... . . . . . . . 19 .
5.11.7 Menganalisis dan mencatat hasil uji kualifikasi sistem. . . . . . ... 20
Machine Translated by Google
5.12 Mempersiapkan penggunaan perangkat lunak . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 .
5.12.1 Menyiapkan perangkat lunak yang dapat dieksekusi . . . . . . . . . . . . . . . . . . . . . . . . . 20 .
5.12.2 Menyiapkan deskripsi versi untuk situs pengguna . . . . . . . . . . . . . . . . . . 20 .
5.12.3 Menyiapkan manual pengguna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 .
5.12.3.1 Panduan pengguna perangkat lunak . . . . . . . . . . . . . . . . . . . . . . . . . 20 .
5.12.3.2 Manual input/output perangkat lunak . . . . . . . . . . . . . . . . . . . . 20 .
5.12.3.3 Panduan operator pusat perangkat lunak . . . . . . . . . . . . . . . . . 21 .
5.12.3.4 Manual pengoperasian komputer . . . . . . . . . . . . . . . . . . . . . 21 .
5.12.4 Pemasangan di situs pengguna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 .
5.13 Mempersiapkan transisi perangkat lunak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 .
5.13.1 Menyiapkan perangkat lunak yang dapat dieksekusi . . . . . . . . . . . . . . . . . . . . . . . . . 21 .
5.13.2 Menyiapkan file sumber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 .
5.13.3 Menyiapkan deskripsi versi untuk situs dukungan. . . . . . . . . . . . . . 21 .
5.13.4 Menyiapkan desain CSCI "as built" dan informasi terkait . . . . . . 21 .
5.13.5 Memperbarui deskripsi desain sistem . . . . . . . . . . . . . . . . . . . . . 22 .
5.13.6 Menyiapkan manual dukungan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 .
5.13.6.1 Manual pemrograman komputer . . . . . . . . . . . . . . . . . . 22 .
5.13.6.2 Manual dukungan firmware . . . . . . . . . . . . . . . . . . . . . . . 22 .
5.13.7 Transisi ke lokasi pendukung yang ditunjuk . . . . . . . . . . . . . . . . . . . . . 22 .
5.14 Manajemen konfigurasi perangkat lunak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 .
5.14.1 Identifikasi konfigurasi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 .
5.14.2 Kontrol konfigurasi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 .
5.14.3 Akuntansi status konfigurasi . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 .
5.14.4 Audit konfigurasi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 .
5.14.5 Pengemasan, penyimpanan, penanganan, dan pengiriman . . . . . . . . . . . . . . . . . . . 23 .
5.15 Evaluasi produk perangkat lunak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 .
5.15.1 Evaluasi produk perangkat lunak dalam proses dan akhir . . . . . . . . . . . . . . 24
5.15.2 Catatan evaluasi produk perangkat lunak. . . . . . . . . . . . . . . . . . . . . . . . . 24 .
5.15.3 Kemandirian dalam evaluasi produk perangkat lunak. . . . . . . . . . . . . . . . . 24 .
5.16 Jaminan kualitas perangkat lunak. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 .
5.16.1 Evaluasi jaminan kualitas perangkat lunak. . . . . . . . . . . . . . . . . . . . . . 24 .
5.16.2 Catatan jaminan kualitas perangkat lunak. . . . . . . . . . . . . . . . . . . . . . . . 24 .
5.16.3 Kemandirian dalam jaminan kualitas perangkat lunak. . . . . . . . . . . . . . . . . . 25 .
5.17 Tindakan perbaikan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 .
5.17.1 Laporan masalah/perubahan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 .
5.17.2 Sistem tindakan perbaikan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 .
5.18 Tinjauan teknis dan manajemen bersama . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 .
5.18.1 Tinjauan teknis bersama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 .
5.18.2 Tinjauan manajemen bersama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 .
5.19 Kegiatan lainnya . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 .
5.19.1 Manajemen risiko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 .
5.19.2 Indikator manajemen perangkat lunak . . . . . . . . . . . . . . . . . . . . . . . . . . 27 .
5.19.3 Keamanan dan privasi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 .
5.19.4 Manajemen subkontraktor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 .
5.19.5 Antarmuka dengan agen perangkat lunak IV&V . . . . . . . . . . . . . . . . . . . . . . . . 27 .
5.19.6 Koordinasi dengan pengembang mitra . . . . . . . . . . . . . . . . . . . . . 27 .
5.19.7 Peningkatan proses proyek . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.Machine
CATATAN Translated
. by
. Google
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 .
6.1 Tujuan penggunaan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 .
6.2 Persyaratan data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 .
6.3 Hubungan antara standar dan CDRL . . . . . . . . . . . . . . . . . . . . . . . . . . 29 .
6.4 Pengiriman isi alat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 .
6.5 Panduan menjahit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 .
6.6 Pelaporan biaya/jadwal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 .
6.7 Dokumen standardisasi terkait. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 .
6.8 Daftar istilah subjek (kata kunci) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
LAMPIRAN
Lampiran Halaman
DAFTAR AKRONIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 .
A.1 Lingkup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 .
A.2 Dokumen yang berlaku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 .
A.3 Akronim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
B MENAFSIRKAN MIL-STD-498 UNTUK PENGGABUNGAN PRODUK PERANGKAT LUNAK YANG

DAPAT DIGUNAKAN KEMBALI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 .
B.1 Cakupan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 .
B.2 Dokumen yang berlaku. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 .
B.3 . . . . . . . . . . . . . . . . . . . . . 33
Mengevaluasi produk perangkat lunak yang dapat digunakan kembali.
B.4 Menafsirkan aktivitas MIL-STD-498 untuk produk perangkat lunak yang dapat
. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
digunakan kembali . . . . 33
C KATEGORI DAN KLASIFIKASI PRIORITAS MASALAH

LAPORAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 .
C.1 Lingkup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 .
C.2 Dokumen yang berlaku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 .
C.3 Klasifikasi berdasarkan kategori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 .
C.4 Klasifikasi berdasarkan prioritas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
D EVALUASI PRODUK PERANGKAT LUNAK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 .

D.1 Cakupan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 .
D.2 Dokumen yang berlaku. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 .
D.3 Evaluasi yang diperlukan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 .
D.4 Definisi kriteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
TINJAUAN MANAJEMEN BERSAMA KANDIDAT . . . . . . . . . . . . . . . . . . . . . . . 44 .

E.1 Cakupan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 .
E.2 Dokumen yang berlaku. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 .
E.3 Asumsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 .
E.4 Review kandidat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
F INDIKATOR MANAJEMEN KANDIDAT . . . . . . . . . . . . . . . ... . . . . ... . 46 .
F.1 Cakupan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . ... . . . 46 .
F.2 Dokumen yang berlaku. . . . . . ... . . . . . . . . ... . . . . ... . . . . ... 46 .
F.3 Indikator kandidat. . . . . . . ... . . . . . . . . ... . . . . ... . . . . ... 46
G PEDOMAN STRATEGI PROGRAM, TAILORING, DAN BUILD

PERENCANAAN . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . ... . . . . . . . . ... . . . . 47 .
G.1 Lingkup . . . . ... . . . . . . . . . . . . . . . ... . . . . ... . . . . . . . . ... . . . 47 .
G.2 Dokumen yang berlaku . . . . . . ... . . . . . . . . ... . . . . ... . . . . ... 47 .
G.3 Strategi program calon . . . . . . . . . . . ... . . . . ... . . . . ... 47 .
G.4 Memilih strategi program yang tepat. . . . . ... . . . . . . . . ... 48 .
G.5 Hubungan MIL-STD-498 dengan strategi program . . . . . . . . . . ... 48 .
G.6 Pembuatan perangkat lunak perencanaan dan penyesuaian MIL-STD-498 . . . . . . . . . ... 48
H PEDOMAN PEMESANAN HASIL . . . . . . ... . . . . ... . . . . ... . 56 .

H.1 Cakupan . . . . . . . . . . . . . . . . . . . . . . ... . . . . ... . . . . . . . . ... . . . 56 .
H.2 Dokumen yang berlaku. . . . . . ... . . . . . . . . ... . . . . ... . . . . . . . 56 .
H.3 Memesan kiriman. . . . . . . ... . . . . . . . . ... . . . . ... . . . . . . . 56 .
H.4 Menjadwalkan kiriman. . . . . ... . . . . . . . . ... . . . . ... . . . . . . . 56 .
H.5 Format kiriman. . . . . . ... . . . . . . . . ... . . . . ... . . . . . . . 56 .
H.6 Menyesuaikan DID . . ... . . . . ... . . . . . . . . ... . . . . ... . . . . . . . 56
PANDUAN KONVERSI DARI DOD-STD-2167A DAN DOD-STD-7935A . . . . . 57 .

I.1 Cakupan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 .
I.2 Dokumen yang berlaku. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
I.3 Pemetaan istilah kunci. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
I.4 Pemetaan DID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
INDEKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Angka Halaman
1 Satu kemungkinan pemetaan aktivitas MIL-STD-498 ke beberapa build . . . . . . . . . 11
2 Dokumen standardisasi terkait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 Menafsirkan MIL-STD-498 untuk penggabungan perangkat lunak yang dapat digunakan kembali. . . . . . . . . . . 34
4 Kategori yang akan digunakan untuk mengklasifikasikan masalah dalam produk perangkat lunak. . . . . . . . 37
5 Prioritas yang akan digunakan untuk mengklasifikasikan masalah. . . . . . . . . . . . . . . . . . . . . . . . . 37
6 Produk perangkat lunak dan kriteria evaluasi terkait. . . . . . . . . . . . . . . . . . . . 39
7 Fitur utama dari tiga strategi program DOD. . . . . . . . . . . . . . . . . . . . . . . . 47
8 Contoh analisis risiko untuk menentukan strategi program yang tepat. . . . . . . 49
9 Salah satu cara yang mungkin untuk menerapkan MIL-STD-498 pada Desain Utama
strategi program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10 Salah satu cara yang mungkin untuk menerapkan MIL-STD-498 ke Inkremental

11 Salah satu cara yang mungkin untuk menerapkan MIL-STD-498 ke Evolutionary

12 Salah satu cara yang mungkin untuk menerapkan MIL-STD-498 pada proyek rekayasa ulang . . . . . . . 53
13 Contoh perencanaan pembangunan untuk proyek MIL-STD-498 . . . . . . . . . . . . . . . . . . . 54
14 Pemetaan istilah kunci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
15 Pemetaan DID DOD-STD-7935A ke DID MIL-STD-498 . . . . . . . . . . . . . . . . 58
16 Pemetaan DOD-STD-2167A DID ke MIL-STD-498 DID . . . . . . . . . . . . . . . . 59
17 Pemetaan DID MIL-STD-498 ke DID DOD-STD-2167A dan DOD-

STD-7935A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Machine Translated
MIL-STD-498 by Google
(versi PDF) 1. Lingkup Halaman 1
1. RUANG LINGKUP
1.1 Tujuan. Tujuan dari standar ini adalah untuk menetapkan persyaratan yang seragam untuk pengembangan dan
dokumentasi perangkat lunak.
1.2 Aplikasi. MIL-STD-498 dimaksudkan untuk diterapkan sebagai berikut.
1.2.1 Organisasi dan perjanjian. Standar ini dapat diterapkan pada kontraktor, subkontraktor, atau lembaga internal
Pemerintah yang melakukan pengembangan perangkat lunak. Untuk keseragaman, istilah "pengakuisisi" digunakan
untuk organisasi yang membutuhkan upaya teknis, "pengembang" untuk organisasi yang melakukan upaya teknis,
"kontrak" untuk kesepakatan antara pihak-pihak tersebut, "Pernyataan Kerja" (SOW) untuk daftar tugas yang harus
dilakukan oleh pengembang, "Daftar Persyaratan Data Kontrak" (CDRL) untuk daftar produk perangkat lunak yang
dapat dikirim, dan "subkontraktor" untuk setiap organisasi yang ditugaskan oleh pengembang untuk melakukan
bagian dari upaya yang diperlukan. "Pengembangan perangkat lunak" digunakan sebagai istilah inklusif yang
mencakup pengembangan baru, modifikasi, penggunaan kembali, rekayasa ulang, pemeliharaan, dan semua
aktivitas lain yang menghasilkan produk perangkat lunak.
1.2.2 Aplikasi khusus kontrak. Standar ini dipanggil dengan mengutipnya pada kontrak. Ini berlaku untuk setiap
produk perangkat lunak dan untuk setiap jenis perangkat lunak yang tercakup dalam kontrak, apa pun media
penyimpanannya, sejauh yang ditentukan dalam kontrak. Contoh jenis perangkat lunak termasuk dapat disampaikan
versus tidak dapat disampaikan, perangkat lunak yang dirancang untuk memenuhi kebutuhan pengguna versus
perangkat lunak dalam lingkungan teknik dan pengujian, dan perangkat lunak yang dirancang untuk memenuhi satu
kebutuhan pengguna versus perangkat lunak yang dirancang untuk memenuhi yang lain. Pihak pengakuisisi
diharapkan untuk menentukan jenis perangkat lunak yang menerapkan standar dan menyesuaikan standar secara
tepat untuk setiap jenis perangkat lunak. Jika standar dipanggil tanpa pernyataan aplikasi selektif seperti itu, akan
dipahami untuk menerapkan secara keseluruhan untuk semua perangkat lunak yang dapat dikirim, dengan
persyaratan mengenai lingkungan pengembangan perangkat lunak yang berlaku untuk lingkungan pengembangan
perangkat lunak untuk perangkat lunak yang dapat dikirim. Meskipun standar ini ditulis dalam istilah Item Konfigurasi
Perangkat Lunak Komputer (CSCI), standar ini dapat diterapkan pada perangkat lunak yang tidak ditetapkan sebagai
CSCI, dengan istilah "CSCI" yang ditafsirkan dengan tepat. Perangkat lunak yang dipasang di firmware tunduk pada se
Standar ini tidak berlaku untuk elemen perangkat keras firmware.
1.2.3 Menjahit. Standar ini dan Deskripsi Item Data (DID) dimaksudkan untuk disesuaikan untuk setiap jenis
perangkat lunak yang diterapkan. Meskipun penjahitan adalah tanggung jawab pengakuisisi, penjahitan yang
disarankan dapat disediakan oleh calon dan pengembang terpilih. Panduan menjahit umum dapat ditemukan di
Bagian 6 dan di DOD-HDBK-248. Panduan penyesuaian khusus untuk standar ini dapat ditemukan di Lampiran G
dan H dan di buku panduan dan buku pegangan yang direncanakan untuk standar ini.
1.2.4 Interpretasi istilah yang dipilih. Istilah berikut memiliki interpretasi khusus seperti yang digunakan dalam standar
ini.
1.2.4.1 Interpretasi "sistem". Interpretasi berikut berlaku:
A. Istilah "sistem", seperti yang digunakan dalam standar ini, dapat berarti: (1) sistem perangkat keras-perangkat
lunak (misalnya, sistem radar) yang standar ini hanya mencakup bagian perangkat lunak, atau (2) sistem
perangkat lunak (untuk misalnya, sistem penggajian) di mana standar ini mengatur pengembangan secara
keseluruhan.
Machine Translated
(versi PDF) 1. Lingkup Halaman 2
B. Jika suatu sistem terdiri dari subsistem, semua persyaratan dalam standar ini mengenai sistem juga berlaku
untuk subsistem. Jika kontrak didasarkan pada alternatif sistem dan subsistem, seperti item kompleks,
persyaratan dalam standar ini mengenai sistem dan spesifikasinya berlaku untuk alternatif ini dan
spesifikasinya.
1.2.4.2 Interpretasi "berpartisipasi" dalam pengembangan sistem. Istilah "berpartisipasi" dalam paragraf mengenai
aktivitas tingkat sistem harus ditafsirkan sebagai berikut: Jika perangkat lunak yang tercakup dalam standar ini
merupakan bagian dari sistem perangkat keras-perangkat lunak yang standar ini hanya mencakup bagian perangkat
lunak, istilah "berpartisipasi" adalah untuk ditafsirkan sebagai "ikut serta, seperti yang dijelaskan dalam rencana
pengembangan perangkat lunak." Jika perangkat lunak (mungkin dengan komputernya) dianggap sebagai suatu
sistem, istilah "berpartisipasi" harus diartikan sebagai "bertanggung jawab atas".
1.2.4.3 Interpretasi dari "mengembangkan," "mendefinisikan," dll. Sepanjang standar ini, persyaratan untuk
"mengembangkan," "mendefinisikan," "membangun," atau "mengidentifikasi" informasi harus ditafsirkan untuk
memasukkan pengembangan baru, modifikasi, penggunaan kembali , rekayasa ulang, pemeliharaan, atau aktivitas
lain atau kombinasi aktivitas apa pun yang menghasilkan produk perangkat lunak.
1.2.4.4 Interpretasi dari "rekaman". Sepanjang standar ini, persyaratan untuk "mencatat" informasi harus ditafsirkan
sebagai "diatur dengan cara yang dapat diambil dan dilihat." Hasilnya dapat berupa banyak bentuk, termasuk, namun
tidak terbatas pada, catatan tulisan tangan, hard copy atau dokumen elektronik, dan data yang direkam dalam
rekayasa perangkat lunak berbantuan komputer (CASE) dan alat manajemen proyek.
1.3 Urutan prioritas. Jika terjadi pertentangan antara persyaratan standar ini dan dokumen standardisasi lain yang
berlaku, pihak pengakuisisi bertanggung jawab untuk menyelesaikan pertentangan tersebut.
Machine Translated
MIL-STD-498 byPDF)
(versi Google 2. Dokumen Referensi Halaman 3
2. DOKUMEN REFERENSI
Bagian ini tidak berlaku untuk standar ini, karena tidak ada dokumen yang diacu dalam Bagian 3, 4,
atau 5. Bagian 6 berisi daftar dokumen standardisasi yang dapat digunakan dengan standar ini.
Machine Translated
(versi PDF) 3. Definisi Halaman 4
3. DEFINISI
Catatan: Selain definisi yang diberikan di sini, Bagian 1 menjelaskan interpretasi MIL-STD-498 atau
penggunaan khusus istilah berikut: pengakuisisi, kontrak, Daftar Persyaratan Data Kontrak, definisikan,
kembangkan, pengembang, bangun, identifikasi, berpartisipasi, rekam, pengembangan perangkat lunak,
Pernyataan Kerja, subkontraktor, subsistem, dan sistem.
Penerimaan. Suatu tindakan oleh perwakilan resmi pengakuisisi dimana pengakuisisi 3.1 mengambil
alih kepemilikan atas produk perangkat lunak sebagai kinerja sebagian atau seluruhnya dari suatu
kontrak.
3.2 Pengakuisisi. Sebuah organisasi yang membeli produk perangkat lunak untuk dirinya sendiri atau organisasi
lain.
3.3 Persetujuan. Pemberitahuan tertulis oleh perwakilan resmi pihak pengakuisisi bahwa rencana pengembang,
desain, atau aspek lain dari proyek tampak baik dan dapat digunakan sebagai dasar untuk pekerjaan lebih lanjut.
Persetujuan tersebut tidak mengalihkan tanggung jawab dari pengembang untuk memenuhi persyaratan kontrak.
3.4 Arsitektur. Struktur organisasi suatu sistem atau CSCI, mengidentifikasi komponen-komponennya, antarmuka
mereka, dan konsep eksekusi di antara mereka.
3.5 Pengembang asosiasi. Organisasi yang bukan kontraktor utama atau subkontraktor
kepada pengembang, tetapi memiliki peran pengembangan pada sistem atau proyek yang sama atau terkait.
3.6 Desain perilaku. Rancangan bagaimana keseluruhan sistem atau CSCI akan berperilaku, dari sudut pandang
pengguna, dalam memenuhi persyaratannya, mengabaikan implementasi internal sistem atau CSCI. Desain ini
kontras dengan desain arsitektur, yang mengidentifikasi komponen internal dari sistem atau CSCI, dan dengan
desain rinci dari komponen tersebut.
3.7 Bangun. (1) Versi perangkat lunak yang memenuhi subset tertentu dari persyaratan yang akan dipenuhi oleh
perangkat lunak yang telah selesai. (2) Periode waktu di mana versi tersebut dikembangkan.
Catatan: Hubungan istilah "build" dan "version" terserah developer; misalnya, mungkin diperlukan beberapa
versi untuk mencapai sebuah build, sebuah build mungkin dirilis dalam beberapa versi paralel (seperti ke situs
yang berbeda), atau istilah tersebut dapat digunakan sebagai sinonim.
3.8 Basis data komputer. Lihat basis data.
3.9 Perangkat keras komputer. Perangkat yang mampu menerima dan menyimpan data komputer, menjalankan
urutan operasi yang sistematis pada data komputer, atau menghasilkan output kontrol. Perangkat tersebut dapat
melakukan interpretasi substansial, perhitungan, komunikasi, kontrol, atau fungsi logis lainnya.
3.10 Program komputer. Kombinasi instruksi komputer dan definisi data yang memungkinkan perangkat keras
komputer untuk melakukan fungsi komputasi atau kontrol.
3.11 Perangkat lunak komputer. Lihat perangkat lunak.

Machine Translated
3.12 Item Konfigurasi Perangkat Lunak Komputer (CSCI). Agregasi perangkat lunak yang memenuhi fungsi
penggunaan akhir dan ditujukan untuk manajemen konfigurasi terpisah oleh pengakuisisi.
CSCI dipilih berdasarkan pertukaran antara fungsi perangkat lunak, ukuran, host atau komputer target, pengembang,
konsep dukungan, rencana penggunaan kembali, kekritisan, pertimbangan antarmuka, perlu didokumentasikan dan
dikendalikan secara terpisah, dan faktor lainnya.
3.13 Item Konfigurasi. Kumpulan perangkat keras, perangkat lunak, atau keduanya yang memenuhi fungsi penggunaan
akhir dan ditujukan untuk manajemen konfigurasi terpisah oleh pengakuisisi.
3.14 Basis data. Kumpulan data terkait yang disimpan dalam satu atau lebih file terkomputerisasi dengan cara yang
dapat diakses oleh pengguna atau program komputer melalui sistem manajemen basis data.
3.15 Sistem manajemen basis data. Seperangkat program komputer terintegrasi yang menyediakan kemampuan yang
diperlukan untuk membuat, memodifikasi, menyediakan, dan memelihara integritas database.
3.16 Produk perangkat lunak yang dapat disampaikan. Produk perangkat lunak yang diwajibkan oleh kontrak untuk
diserahkan kepada pengakuisisi atau penerima lain yang ditunjuk.
3.17 Desain. Karakteristik sistem atau CSCI yang dipilih oleh pengembang sebagai respons terhadap persyaratan.
Beberapa akan cocok dengan persyaratan; yang lain akan berupa penjabaran persyaratan, seperti definisi semua
pesan kesalahan sebagai tanggapan atas persyaratan untuk menampilkan pesan kesalahan; yang lain akan terkait
implementasi, seperti keputusan tentang unit perangkat lunak dan logika apa yang akan digunakan untuk memenuhi
persyaratan.
3.18 Pengembang. Organisasi yang mengembangkan produk perangkat lunak ("mengembangkan" dapat mencakup
pengembangan baru, modifikasi, penggunaan kembali, rekayasa ulang, pemeliharaan, atau aktivitas lain apa pun
yang menghasilkan produk perangkat lunak). Pengembang dapat berupa kontraktor atau lembaga Pemerintah.
3.19 Dokumen/dokumentasi. Kumpulan data, terlepas dari media yang merekamnya, yang umumnya bersifat
permanen dan dapat dibaca oleh manusia atau mesin.
3.20 Evaluasi. Proses penentuan apakah suatu item atau aktivitas memenuhi kriteria yang ditentukan.
3.21 Perangkat tegar. Kombinasi perangkat keras dan instruksi komputer dan/atau data komputer yang berada sebagai
perangkat lunak hanya-baca pada perangkat keras.
3.22 Item Konfigurasi Perangkat Keras (HWCI). Agregasi perangkat keras yang memenuhi fungsi penggunaan akhir
dan ditujukan untuk manajemen konfigurasi terpisah oleh pengakuisisi.
3.23 Verifikasi dan validasi independen (IV&V). Evaluasi sistematis produk dan aktivitas perangkat lunak oleh lembaga
yang tidak bertanggung jawab untuk mengembangkan produk atau melakukan aktivitas yang sedang dievaluasi. IV&V
tidak termasuk dalam ruang lingkup standar ini.
3.24 Antarmuka. Dalam pengembangan perangkat lunak, hubungan antara dua atau lebih entitas (seperti CSCI-CSCI,
CSCI-HWCI, pengguna CSCI, atau unit perangkat lunak-unit perangkat lunak) di mana entitas berbagi, menyediakan,
atau bertukar data. Antarmuka bukanlah CSCI, unit perangkat lunak, atau komponen sistem lainnya; itu adalah
hubungan di antara mereka.
Machine Translated
3.25 Tinjauan bersama. Suatu proses atau pertemuan yang melibatkan perwakilan dari pengakuisisi dan pengembang, di mana
status proyek, produk perangkat lunak, dan/atau masalah proyek diperiksa dan didiskusikan.
3.26 Produk perangkat lunak yang tidak dapat dikirimkan. Produk perangkat lunak yang tidak diwajibkan oleh kontrak untuk
diserahkan kepada pengakuisisi atau penerima lain yang ditunjuk.
3.27 Proses. Serangkaian kegiatan terorganisir yang dilakukan untuk tujuan tertentu; misalnya, proses pengembangan perangkat
lunak.
3.28 Pengujian Kualifikasi. Pengujian dilakukan untuk menunjukkan kepada pengakuisisi bahwa CSCI atau sistem memenuhi
persyaratan yang ditentukan.
3.29 Rekayasa ulang. Proses memeriksa dan mengubah sistem yang ada untuk menyusunnya kembali dalam bentuk baru.
Mungkin termasuk rekayasa balik (menganalisis sistem dan menghasilkan representasi pada tingkat abstraksi yang lebih tinggi,
seperti desain dari kode), restrukturisasi (mengubah sistem dari satu representasi ke representasi lain pada tingkat abstraksi
yang sama), redokumentasi (menganalisis sistem dan menghasilkan dokumentasi pengguna atau pendukung), rekayasa maju
(menggunakan produk perangkat lunak yang berasal dari sistem yang ada, bersama dengan persyaratan baru, untuk
menghasilkan sistem baru), penargetan ulang (mengubah sistem untuk menginstalnya pada sistem target yang berbeda), dan
terjemahan (mengubah kode sumber dari satu bahasa ke bahasa lain atau dari satu versi bahasa ke bahasa lain).
3.30 Persyaratan. (1) Karakteristik yang harus dimiliki suatu sistem atau CSCI agar dapat diterima oleh pengakuisisi. (2)
Pernyataan wajib dalam standar ini atau bagian lain dari kontrak.
3.31 Produk perangkat lunak yang dapat digunakan kembali. Produk perangkat lunak yang dikembangkan untuk satu penggunaan
tetapi memiliki kegunaan lain, atau yang dikembangkan secara khusus agar dapat digunakan pada banyak proyek atau dalam
berbagai peran pada satu proyek. Contohnya termasuk, namun tidak terbatas pada, produk perangkat lunak siap pakai
komersial, produk perangkat lunak yang dilengkapi pengakuisisi, produk perangkat lunak dalam pustaka penggunaan ulang, dan
produk perangkat lunak pengembang yang sudah ada sebelumnya. Setiap penggunaan dapat mencakup semua atau sebagian
dari produk perangkat lunak dan dapat melibatkan modifikasinya. Istilah ini dapat diterapkan pada produk perangkat lunak apa
pun (misalnya, persyaratan, arsitektur, dll.), tidak hanya pada perangkat lunak itu sendiri.
3.32 Perangkat Lunak. Program komputer dan database komputer. Catatan: Meskipun beberapa definisi perangkat lunak
mencakup dokumentasi, MIL-STD-498 membatasi definisi pada program komputer dan database komputer sesuai dengan
Tambahan Peraturan Akuisisi Federal Pertahanan 227.401.
3.33 Pengembangan perangkat lunak. Serangkaian aktivitas yang menghasilkan produk perangkat lunak. Pengembangan
perangkat lunak dapat mencakup pengembangan baru, modifikasi, penggunaan kembali, rekayasa ulang, pemeliharaan, atau
aktivitas lain apa pun yang menghasilkan produk perangkat lunak.
3.34 File pengembangan perangkat lunak (SDF). Repositori untuk materi yang berkaitan dengan pengembangan badan
perangkat lunak tertentu. Konten biasanya mencakup (baik secara langsung atau melalui referensi) pertimbangan, alasan, dan
batasan yang terkait dengan analisis kebutuhan, desain, dan implementasi; informasi pengujian internal pengembang; dan
informasi jadwal dan status.
Machine Translated
3.35 Pustaka pengembangan perangkat lunak (SDL). Kumpulan perangkat lunak yang terkontrol, dokumentasi, produk perangkat
lunak perantara dan akhir lainnya, serta alat dan prosedur terkait yang digunakan untuk memfasilitasi pengembangan yang teratur
dan dukungan selanjutnya dari perangkat lunak.
3.36 Proses pengembangan perangkat lunak. Serangkaian aktivitas terorganisir yang dilakukan untuk menerjemahkan kebutuhan
pengguna menjadi produk perangkat lunak.
3.37 Rekayasa perangkat lunak. Dalam penggunaan umum, sinonim untuk pengembangan perangkat lunak. Seperti yang digunakan
dalam standar ini, subset pengembangan perangkat lunak yang terdiri dari semua aktivitas kecuali pengujian kualifikasi. Standar
membuat perbedaan ini hanya untuk tujuan memberikan nama terpisah untuk rekayasa perangkat lunak dan lingkungan pengujian
perangkat lunak.
3.38 Lingkungan rekayasa perangkat lunak. Fasilitas, perangkat keras, perangkat lunak, firmware, prosedur, dan dokumentasi yang
diperlukan untuk melakukan rekayasa perangkat lunak. Elemen dapat mencakup tetapi tidak terbatas pada alat rekayasa perangkat
lunak berbantuan komputer (CASE), kompiler, perakit, penghubung, pemuat, sistem operasi, debugger, simulator, emulator, alat
dokumentasi, dan sistem manajemen basis data.
3.39 Produk perangkat lunak. Perangkat lunak atau informasi terkait yang dibuat, dimodifikasi, atau dimasukkan untuk memenuhi
kontrak. Contohnya termasuk rencana, persyaratan, desain, kode, database, informasi pengujian, dan manual.
3.40 Kualitas perangkat lunak. Kemampuan perangkat lunak untuk memenuhi persyaratan yang ditentukan.
3.41 Dukungan perangkat lunak. Serangkaian aktivitas yang dilakukan untuk memastikan bahwa perangkat lunak yang diinstal untuk
penggunaan operasional terus berfungsi sebagaimana mestinya dan memenuhi peran yang dimaksudkan dalam operasi sistem.
Dukungan perangkat lunak mencakup pemeliharaan perangkat lunak, bantuan untuk pengguna, dan aktivitas terkait.
3.42 Sistem perangkat lunak. Suatu sistem yang hanya terdiri dari perangkat lunak dan mungkin peralatan komputer tempat
perangkat lunak tersebut beroperasi.
3.43 Lingkungan pengujian perangkat lunak. Fasilitas, perangkat keras, perangkat lunak, firmware, prosedur, dan dokumentasi yang
diperlukan untuk melakukan kualifikasi, dan mungkin lainnya, pengujian perangkat lunak. Elemen dapat mencakup tetapi tidak
terbatas pada simulator, penganalisa kode, generator kasus uji, dan penganalisa jalur, dan juga dapat mencakup elemen yang
digunakan dalam lingkungan rekayasa perangkat lunak.
3.44 Transisi perangkat lunak. Serangkaian aktivitas yang memungkinkan tanggung jawab untuk pengembangan perangkat lunak
berpindah dari satu organisasi, biasanya organisasi yang melakukan pengembangan perangkat lunak awal, ke organisasi lain,
biasanya organisasi yang akan melakukan dukungan perangkat lunak.
3.45 Unit perangkat lunak. Elemen dalam desain CSCI; misalnya, subdivisi utama dari CSCI, komponen dari subdivisi tersebut,
kelas, objek, modul, fungsi, rutin, atau database.
Unit perangkat lunak dapat terjadi pada tingkat hirarki yang berbeda dan dapat terdiri dari unit perangkat lunak lainnya. Unit perangkat
lunak dalam desain mungkin atau mungkin tidak memiliki hubungan satu-ke-satu dengan kode dan entitas data (rutinitas, prosedur,
database, file data, dll.) yang mengimplementasikannya atau dengan file komputer yang berisi entitas tersebut.
3.46 Dukungan (perangkat lunak). Lihat dukungan perangkat lunak.
3.47 Transisi (perangkat lunak). Lihat transisi perangkat lunak.
3.48 Definisi singkatan yang digunakan dalam standar ini. Lihat Lampiran A.
Machine Translated
(versi PDF) 4. Persyaratan Umum Halaman 8
4. PERSYARATAN UMUM
4.1 Proses pengembangan perangkat lunak. Pengembang harus menetapkan proses pengembangan perangkat lunak yang
konsisten dengan persyaratan kontrak. Proses pengembangan perangkat lunak harus mencakup aktivitas utama berikut,
yang mungkin tumpang tindih, dapat diterapkan secara iteratif, dapat diterapkan secara berbeda pada elemen perangkat
lunak yang berbeda, dan tidak perlu dilakukan dalam urutan yang tercantum di bawah ini.
Lampiran G memberikan contoh. Proses pengembangan perangkat lunak pengembang harus dijelaskan dalam rencana
pengembangan perangkat lunak.
A. Perencanaan dan pengawasan proyek (bagian 5.1) b.

Menetapkan lingkungan pengembangan perangkat lunak (5.2) c. Analisis
kebutuhan sistem (5.3) d. Desain sistem (5.4) e.
Analisis kebutuhan perangkat
lunak (5.5) f. Perancangan perangkat lunak (5.6) g.
Implementasi perangkat lunak
dan pengujian unit (5.7) h. Integrasi dan pengujian unit (5.8) i.
Pengujian kualifikasi CSCI (5.9) j. Integrasi
dan pengujian CSCI/HWCI (5.10) k.
Pengujian kualifikasi sistem (5.11) l. Mempersiapkan
penggunaan perangkat lunak (5.12) m.
Mempersiapkan transisi perangkat lunak (5.13)
n. Proses integral: 1) Manajemen konfigurasi perangkat
lunak (5.14)
2) Evaluasi produk perangkat lunak (5.15)

3) Jaminan kualitas perangkat lunak (5.16)
4) Tindakan korektif (5.17)
5) Tinjauan teknis dan manajemen bersama (5.18)
6) Kegiatan lain (5.19)
4.2 Persyaratan umum untuk pengembangan perangkat lunak. Pengembang harus memenuhi hal-hal berikut
persyaratan umum dalam melaksanakan persyaratan rinci dalam bagian 5 standar ini.
4.2.1 Metode pengembangan perangkat lunak. Pengembang harus menggunakan metode yang sistematis dan terdokumentasi
untuk semua aktivitas pengembangan perangkat lunak. Metode ini harus dijelaskan dalam, atau direferensikan dari, rencana
4.2.2 Standar untuk produk perangkat lunak. Pengembang harus mengembangkan dan menerapkan standar untuk mewakili
persyaratan, desain, kode, kasus uji, prosedur uji, dan hasil uji. Standar ini harus dijelaskan dalam, atau dirujuk dari, rencana
4.2.3 Produk perangkat lunak yang dapat digunakan kembali. Pengembang harus memenuhi persyaratan berikut.
4.2.3.1 Memasukkan produk perangkat lunak yang dapat digunakan kembali. Pengembang harus mengidentifikasi dan
mengevaluasi produk perangkat lunak yang dapat digunakan kembali untuk digunakan dalam memenuhi persyaratan
kontrak. Lingkup pencarian dan kriteria yang akan digunakan untuk evaluasi harus seperti yang dijelaskan dalam rencana
pengembangan perangkat lunak. Produk perangkat lunak yang dapat digunakan kembali yang memenuhi kriteria harus
digunakan jika memungkinkan. Lampiran B memberikan kriteria yang diperlukan dan kandidat serta menginterpretasikan
standar ini untuk penggabungan produk perangkat lunak yang dapat digunakan kembali. Produk perangkat lunak yang
dimasukkan harus memenuhi persyaratan hak data dalam kontrak.
Machine Translated
4.2.3.2 Mengembangkan produk perangkat lunak yang dapat digunakan kembali. Selama masa kontrak, pengembang
harus mengidentifikasi peluang untuk mengembangkan produk perangkat lunak untuk digunakan kembali dan harus
mengevaluasi manfaat dan biaya dari peluang tersebut. Peluang yang memberikan manfaat biaya dan sesuai dengan
tujuan program harus diidentifikasi oleh pengakuisisi.
Catatan: Selain itu, pengembang mungkin diminta oleh kontrak untuk mengembangkan produk perangkat lunak
khusus untuk digunakan kembali.
4.2.4 Penanganan kebutuhan kritis. Pengembang harus memenuhi persyaratan berikut.
4.2.4.1 Jaminan keamanan. Pengembang harus mengidentifikasi CSCI atau bagiannya yang kritis terhadap keselamatan
yang kegagalannya dapat menyebabkan status sistem yang berbahaya (salah satu yang dapat mengakibatkan kematian,
cedera, kehilangan harta benda, atau kerusakan lingkungan yang tidak diinginkan). Jika ada perangkat lunak seperti itu,
pengembang harus mengembangkan strategi jaminan keselamatan, termasuk pengujian dan analisis, untuk memastikan
bahwa persyaratan, rancangan, penerapan, dan prosedur pengoperasian untuk perangkat lunak yang diidentifikasi
meminimalkan atau menghilangkan potensi kondisi berbahaya. Strategi harus mencakup program keamanan perangkat
lunak, yang harus diintegrasikan dengan program keamanan sistem jika ada.
Pengembang harus mencatat strategi tersebut dalam rencana pengembangan perangkat lunak, menerapkan strategi
tersebut, dan menghasilkan bukti, sebagai bagian dari produk perangkat lunak yang diperlukan, bahwa strategi jaminan
keamanan telah dilaksanakan.
4.2.4.2 Jaminan keamanan. Pengembang harus mengidentifikasi CSCI atau bagian darinya sebagai keamanan kritis yang
kegagalannya dapat menyebabkan pelanggaran keamanan sistem. Jika ada perangkat lunak seperti itu, pengembang
harus mengembangkan strategi jaminan keamanan untuk memastikan bahwa persyaratan, desain, penerapan, dan
prosedur operasi untuk perangkat lunak yang diidentifikasi meminimalkan atau menghilangkan potensi pelanggaran
keamanan sistem. Pengembang harus mencatat strategi dalam rencana pengembangan perangkat lunak,
mengimplementasikan strategi, dan menghasilkan bukti, sebagai bagian dari produk perangkat lunak yang diperlukan,
bahwa strategi jaminan keamanan telah dilakukan.
4.2.4.3 Jaminan privasi. Pengembang harus mengidentifikasi CSCI atau bagiannya sebagai kritis terhadap privasi yang
kegagalannya dapat menyebabkan pelanggaran privasi sistem. Jika ada perangkat lunak seperti itu, pengembang harus
mengembangkan strategi jaminan privasi untuk memastikan bahwa persyaratan, desain, penerapan, dan prosedur
pengoperasian untuk perangkat lunak yang diidentifikasi meminimalkan atau menghilangkan potensi pelanggaran privasi
sistem. Pengembang harus mencatat strategi dalam rencana pengembangan perangkat lunak, mengimplementasikan
strategi, dan menghasilkan bukti, sebagai bagian dari produk perangkat lunak yang dibutuhkan, bahwa strategi jaminan
privasi telah dilaksanakan.
4.2.4.4 Jaminan persyaratan penting lainnya. Jika suatu sistem bergantung pada perangkat lunak untuk memenuhi
persyaratan lain yang dianggap penting oleh kontrak atau spesifikasi sistem, pengembang harus mengidentifikasi CSCI
atau bagiannya yang kegagalannya dapat menyebabkan pelanggaran terhadap persyaratan penting tersebut;
mengembangkan strategi untuk memastikan bahwa persyaratan, desain, penerapan, dan prosedur pengoperasian untuk
perangkat lunak yang diidentifikasi meminimalkan atau menghilangkan potensi pelanggaran tersebut; merekam strategi
dalam rencana pengembangan perangkat lunak; menerapkan strategi; dan menghasilkan bukti, sebagai bagian dari produk
perangkat lunak yang dibutuhkan, bahwa strategi penjaminan telah dilaksanakan.
Machine Translated
4.2.5 Pemanfaatan sumber daya perangkat keras komputer. Pengembang harus menganalisis persyaratan kontrak
mengenai penggunaan sumber daya perangkat keras komputer (seperti penggunaan kapasitas prosesor, kapasitas
memori, kapasitas perangkat input/output, kapasitas perangkat penyimpanan tambahan, dan kapasitas peralatan
komunikasi/jaringan yang diizinkan). Pengembang harus mengalokasikan sumber daya perangkat keras komputer di
antara CSCI, memantau penggunaan sumber daya ini selama durasi kontrak, dan merealokasi atau mengidentifikasi
kebutuhan akan sumber daya tambahan yang diperlukan untuk memenuhi persyaratan kontrak.
4.2.6 Dasar pemikiran pencatatan. Pengembang harus mencatat alasan yang akan berguna bagi lembaga pendukung
untuk keputusan penting yang dibuat dalam menentukan, merancang, mengimplementasikan, dan menguji perangkat lunak
Dasar pemikiran harus mencakup pertukaran yang dipertimbangkan, metode analisis, dan kriteria yang digunakan untuk
membuat keputusan. Dasar pemikiran harus dicatat dalam dokumen, komentar kode, atau media lain yang akan dialihkan
ke lembaga pendukung. Arti dari "keputusan kunci" dan pendekatan untuk memberikan alasan harus dijelaskan dalam
rencana pengembangan perangkat lunak.
4.2.7 Akses untuk tinjauan pengakuisisi. Pengembang harus memberikan akses kepada pengakuisisi atau perwakilan
resminya ke fasilitas pengembang dan subkontraktor, termasuk rekayasa perangkat lunak dan lingkungan pengujian,
untuk meninjau produk dan aktivitas perangkat lunak yang diwajibkan oleh kontrak.
Machine Translated
(versi PDF) 5. Persyaratan Lengkap Halaman 11
5. PERSYARATAN RINCI
Urutan persyaratan dalam bagian ini tidak dimaksudkan untuk menentukan urutan pelaksanaannya. Banyak kegiatan yang
mungkin berlangsung pada satu waktu; produk perangkat lunak yang berbeda dapat berjalan dengan kecepatan yang
berbeda; dan kegiatan yang ditentukan dalam subbagian awal mungkin bergantung pada masukan dari kegiatan di
subbagian berikutnya. Jika perangkat lunak dikembangkan dalam beberapa build, beberapa aktivitas dapat dilakukan di
setiap build, yang lain mungkin dilakukan hanya dalam build yang dipilih, dan aktivitas serta produk perangkat lunak
mungkin tidak lengkap hingga beberapa atau semua build diselesaikan.
Gambar 1 memberikan contoh bagaimana setiap aktivitas dapat diterapkan dalam satu atau beberapa bangunan. Catatan
tidak wajib di seluruh bagian 5 memberi tahu cara menginterpretasikan setiap aktivitas pada proyek yang melibatkan
banyak bangunan. Proyek yang melibatkan satu build akan menyelesaikan semua aktivitas yang diperlukan dalam build
tersebut. Lampiran G memberikan panduan untuk merencanakan pembangunan, menentukan aktivitas mana yang berlaku
untuk setiap pembangunan, dan menjadwalkan aktivitas ini.
Bangun
Aktivitas
Membangun 1 Bangun 2 Bangun 3 Bangun 4
5.1 Perencanaan dan pengawasan proyek X X X X
5.2 Membangun lingkungan pengembangan perangkat lunak X X X X
5.3 Analisis kebutuhan sistem X X
5.4 Desain sistem X X X
5.5 Analisis kebutuhan perangkat lunak X X X X
5.6 Desain perangkat lunak X X X X
5.7 Implementasi perangkat lunak dan pengujian unit X X X X
5.8 Integrasi dan pengujian unit X X X X
5.9 Pengujian kualifikasi CSCI X X X
5.10 Integrasi dan pengujian CSCI/HWCI X X X
5.11 Pengujian kualifikasi sistem X X
5.12 Mempersiapkan penggunaan perangkat lunak X X X X
5.13 Mempersiapkan transisi perangkat lunak X
Proses integral:
5.14 Manajemen konfigurasi perangkat lunak X X X X
5.15 Evaluasi produk perangkat lunak X X X X
5.16 Jaminan kualitas perangkat lunak X X X X
5.17 Tindakan korektif X X X X
5.18 Tinjauan teknis dan manajemen bersama X X X X
5.19 Kegiatan lainnya X X X X
GAMBAR 1. Satu kemungkinan pemetaan aktivitas MIL-STD-498 ke beberapa bangunan.

Machine Translated
(versi PDF) 5. Persyaratan Lengkap halaman 12
5.1 Perencanaan dan pengawasan proyek. Pengembang harus melakukan perencanaan dan pengawasan proyek
sesuai dengan persyaratan berikut.
Catatan: Jika sistem atau CSCI dikembangkan dalam beberapa build, perencanaan untuk setiap build harus
ditafsirkan untuk mencakup: a) perencanaan keseluruhan untuk kontrak, b) perencanaan terperinci untuk build
saat ini, dan c) perencanaan untuk build mendatang yang tercakup dalam kontrak ke tingkat detail yang kompatibel
dengan informasi yang tersedia.
5.1.1 Perencanaan pengembangan perangkat lunak. Pengembang harus mengembangkan dan merekam rencana
untuk melakukan aktivitas yang disyaratkan oleh standar ini dan persyaratan terkait perangkat lunak lainnya dalam
kontrak. Perencanaan ini harus konsisten dengan perencanaan tingkat sistem dan harus mencakup semua item yang
berlaku dalam DID Rencana Pengembangan Perangkat Lunak (SDP) (lihat 6.2).
Catatan 1: Kata-kata di sini dan di seluruh MIL-STD-498 dirancang untuk: 1) Menekankan bahwa pengembangan
dan pencatatan informasi perencanaan dan perekayasaan merupakan bagian intrinsik dari proses pengembangan
perangkat lunak, yang harus dilakukan terlepas dari apakah penyampaian diperlukan ; 2) Gunakan DID sebagai
daftar item yang harus dicakup dalam kegiatan perencanaan atau rekayasa; dan 3) Representasi izin selain
dokumen tradisional untuk merekam informasi (misalnya, alat rekayasa perangkat lunak berbantuan komputer
(CASE)).
Catatan 2: Jika CDRL menetapkan pengiriman informasi yang dihasilkan oleh paragraf ini atau paragraf lainnya,
pengembang diharuskan untuk memformat, merakit, menandai, menyalin, dan mendistribusikan pengiriman
sesuai dengan CDRL. Tugas ini diakui terpisah dari tugas menghasilkan dan merekam informasi yang diperlukan
dan membutuhkan waktu dan upaya tambahan dari pihak pengembang.
Catatan 3: Rencana pengembangan perangkat lunak mencakup semua aktivitas yang diperlukan oleh standar ini.
Bagian dari rencana dapat diikat atau dipertahankan secara terpisah jika pendekatan ini meningkatkan kegunaan
informasi. Contohnya termasuk rencana terpisah untuk jaminan kualitas perangkat lunak dan manajemen
konfigurasi perangkat lunak.
5.1.2 Perencanaan pengujian CSCI. Pengembang harus mengembangkan dan merekam rencana untuk melakukan
pengujian kualifikasi CSCI. Perencanaan ini harus mencakup semua item yang berlaku dalam Software Test Plan
(STP) DID (lihat 6.2).
5.1.3 Perencanaan pengujian sistem. Pengembang harus berpartisipasi dalam mengembangkan dan merekam
rencana untuk melakukan pengujian kualifikasi sistem. Untuk sistem perangkat lunak, perencanaan ini harus mencakup
semua item yang berlaku dalam Software Test Plan (STP) DID (lihat 6.2). (Maksud untuk sistem perangkat lunak
adalah satu rencana pengujian perangkat lunak yang mencakup CSCI dan pengujian kualifikasi sistem.)
5.1.4 Perencanaan instalasi perangkat lunak. Pengembang harus mengembangkan dan merekam rencana untuk
melakukan instalasi dan pelatihan perangkat lunak di lokasi pengguna yang ditentukan dalam kontrak. Perencanaan
ini harus mencakup semua item yang berlaku dalam DID Rencana Instalasi Perangkat Lunak (SIP) (lihat 6.2).
5.1.5 Perencanaan transisi perangkat lunak. Pengembang harus mengidentifikasi semua sumber daya pengembangan
perangkat lunak yang akan dibutuhkan oleh agen pendukung untuk memenuhi konsep dukungan yang ditentukan
dalam kontrak. Pengembang harus mengembangkan dan mencatat rencana yang mengidentifikasi sumber daya ini
dan menjelaskan pendekatan yang harus diikuti untuk mentransisikan item yang dapat dikirim ke lembaga pendukung.
Perencanaan ini harus mencakup semua item yang berlaku dalam Software Transition Plan (STrP) DID (lihat 6.2).
Machine Translated
5.1.6 Mengikuti dan memperbarui rencana. Setelah pengakuisisi menyetujui salah satu rencana dalam bagian ini,
pengembang harus melakukan kegiatan yang relevan sesuai dengan rencana tersebut. Manajemen pengembang
harus meninjau proses pengembangan perangkat lunak pada interval yang ditentukan dalam rencana pengembangan
perangkat lunak untuk memastikan bahwa proses tersebut sesuai dengan kontrak dan sesuai dengan rencana. Dengan
pengecualian penjadwalan internal pengembang dan informasi kepegawaian terkait, pembaruan rencana harus tunduk
pada persetujuan pengakuisisi.
5.2 Membangun lingkungan pengembangan perangkat lunak. Pengembang wajib menetapkan a

lingkungan pengembangan perangkat lunak sesuai dengan persyaratan berikut.
Catatan: Jika sistem atau CSCI dikembangkan dalam beberapa build, menetapkan lingkungan pengembangan
perangkat lunak di setiap build harus diartikan sebagai menetapkan lingkungan yang diperlukan untuk
menyelesaikan build tersebut.
5.2.1 Lingkungan Rekayasa Perangkat Lunak. Pengembang harus menetapkan, mengontrol, dan memelihara
lingkungan rekayasa perangkat lunak untuk melakukan upaya rekayasa perangkat lunak. Pengembang harus
memastikan bahwa setiap elemen lingkungan menjalankan fungsi yang dimaksudkan.
5.2.2 Lingkungan pengujian perangkat lunak. Pengembang harus menetapkan, mengontrol, dan memelihara lingkungan
pengujian perangkat lunak untuk melakukan kualifikasi, dan mungkin pengujian perangkat lunak lainnya. Pengembang
harus memastikan bahwa setiap elemen lingkungan menjalankan fungsi yang dimaksudkan.
5.2.3 Pustaka pengembangan perangkat lunak. Pengembang harus menetapkan, mengontrol, dan memelihara
perpustakaan pengembangan perangkat lunak (SDL) untuk memfasilitasi pengembangan yang teratur dan dukungan
selanjutnya dari perangkat lunak. SDL dapat menjadi bagian integral dari rekayasa perangkat lunak dan lingkungan peng
Pengembang harus memelihara SDL selama durasi kontrak.
5.2.4 File pengembangan perangkat lunak. Pengembang harus membuat, mengontrol, dan memelihara file
pengembangan perangkat lunak (SDF) untuk setiap unit perangkat lunak atau grup unit perangkat lunak yang terkait
secara logis, untuk setiap CSCI, dan, sebagaimana berlaku, untuk grup logis CSCI, untuk subsistem, dan untuk
keseluruhan sistem. Pengembang harus mencatat informasi tentang pengembangan perangkat lunak di SDF yang
sesuai dan harus memelihara SDF selama durasi kontrak.
5.2.5 Perangkat lunak yang tidak dapat dikirimkan. Pengembang dapat menggunakan perangkat lunak yang tidak dapat dikirim
dalam pengembangan perangkat lunak yang dapat dikirim selama operasi dan dukungan dari perangkat lunak yang dapat dikirim
setelah pengiriman ke pihak pengakuisisi tidak bergantung pada perangkat lunak yang tidak dapat dikirim atau ketentuan dibuat
untuk memastikan bahwa pihak pengakuisisi telah atau dapat memperoleh perangkat lunak yang sama. Pengembang harus
memastikan bahwa semua perangkat lunak non-deliverable yang digunakan pada proyek menjalankan fungsi yang dimaksudkan.
5.3 Analisis kebutuhan sistem. Pengembang harus berpartisipasi dalam analisis persyaratan sistem sesuai dengan
persyaratan berikut.
Catatan: Jika sistem dikembangkan dalam beberapa build, persyaratannya mungkin tidak ditentukan sepenuhnya
hingga build final. Perencanaan pengembang harus mengidentifikasi subset persyaratan sistem yang akan
ditentukan di setiap build dan subset yang akan diterapkan di setiap build.
Analisis persyaratan sistem untuk build yang diberikan harus ditafsirkan dengan mendefinisikan persyaratan
sistem yang diidentifikasi untuk build tersebut.
Machine Translated
5.3.1 Analisis masukan pengguna. Pengembang harus berpartisipasi dalam menganalisis input pengguna yang diberikan
oleh pengakuisisi untuk mendapatkan pemahaman tentang kebutuhan pengguna. Masukan ini dapat berupa pernyataan
kebutuhan, survei, laporan masalah/perubahan, umpan balik pada prototipe, wawancara, atau masukan atau umpan
balik pengguna lainnya.
5.3.2 Konsep operasional. Pengembang harus berpartisipasi dalam mendefinisikan dan merekam konsep operasional
untuk sistem. Hasilnya harus mencakup semua item yang berlaku dalam DID Deskripsi Konsep Operasional (OCD)
(lihat 6.2).
5.3.3 Persyaratan sistem. Pengembang harus berpartisipasi dalam mendefinisikan dan merekam persyaratan yang
harus dipenuhi oleh sistem dan metode yang digunakan untuk memastikan bahwa setiap persyaratan telah dipenuhi.
Hasilnya harus mencakup semua item yang berlaku dalam DID Spesifikasi Sistem/Subsistem (SSS) (lihat 6.2).
Bergantung pada ketentuan CDRL, persyaratan terkait antarmuka sistem dapat disertakan dalam SSS atau dalam
spesifikasi persyaratan antarmuka (IRS).
Catatan: Jika suatu sistem terdiri dari subsistem, aktivitas pada 5.3.3 dimaksudkan untuk dilakukan secara iteratif
dengan aktivitas pada 5.4 (Desain sistem) untuk menentukan persyaratan sistem, merancang sistem dan
mengidentifikasi subsistemnya, menentukan persyaratan untuk subsistem tersebut, merancang subsistem dan
mengidentifikasi komponen-komponennya, dan seterusnya.
5.4 Desain sistem. Pengembang harus berpartisipasi dalam desain sistem sesuai dengan persyaratan berikut.
Catatan: Jika sistem dikembangkan dalam beberapa build, desainnya mungkin tidak sepenuhnya ditentukan hingga
build final. Perencanaan pengembang harus mengidentifikasi bagian dari desain sistem yang akan didefinisikan di
setiap build. Desain sistem untuk build tertentu harus ditafsirkan dengan mendefinisikan bagian dari desain sistem
yang diidentifikasi untuk build tersebut.
5.4.1 Keputusan desain seluruh sistem. Pengembang harus berpartisipasi dalam mendefinisikan dan merekam
keputusan desain seluruh sistem (yaitu, keputusan tentang desain perilaku sistem dan keputusan lain yang mempengaruh
pemilihan dan desain komponen sistem). Hasilnya harus mencakup semua item yang berlaku di bagian desain seluruh
sistem DID Deskripsi Desain Sistem/Subsistem (SSDD) (lihat 6.2). Bergantung pada ketentuan CDRL, desain yang
berkaitan dengan antarmuka dapat disertakan dalam SSDD atau dalam deskripsi desain antarmuka (IDD) dan desain
yang berkaitan dengan database dapat disertakan dalam SSDD atau dalam deskripsi desain database (DBDD).
Catatan: Keputusan desain tetap menjadi kebijaksanaan pengembang kecuali secara formal diubah menjadi
persyaratan melalui proses kontrak. Pengembang bertanggung jawab untuk memenuhi semua persyaratan dan
menunjukkan pemenuhan ini melalui pengujian kualifikasi (lihat 5.9, 5.11).
Keputusan desain bertindak sebagai "persyaratan" internal-pengembang untuk diimplementasikan, dikenakan pada
subkontraktor, jika berlaku, dan dikonfirmasi oleh pengujian internal-pengembang, tetapi pemenuhannya tidak perlu
diperlihatkan kepada pihak pengakuisisi.
5.4.2 Desain arsitektur sistem. Pengembang harus berpartisipasi dalam mendefinisikan dan merekam desain arsitektur
sistem (mengidentifikasi komponen sistem, antarmuka mereka, dan konsep eksekusi di antaranya) dan ketertelusuran
antara komponen sistem dan persyaratan sistem. Hasilnya harus mencakup semua item yang berlaku di desain arsitektur
dan bagian ketertelusuran DID Deskripsi Desain Sistem/Subsistem (SSDD) (lihat 6.2).
Bergantung pada ketentuan CDRL, desain yang berkaitan dengan antarmuka dapat disertakan dalam SSDD atau dalam
deskripsi desain antarmuka (IDD).
Machine Translated
5.5 Analisis kebutuhan perangkat lunak. Pengembang harus menentukan dan merekam persyaratan perangkat
lunak yang harus dipenuhi oleh setiap CSCI, metode yang akan digunakan untuk memastikan bahwa setiap
persyaratan telah dipenuhi, dan ketertelusuran antara persyaratan CSCI dan persyaratan sistem.
Hasilnya harus mencakup semua item yang berlaku dalam DID Spesifikasi Kebutuhan Perangkat Lunak (SRS)
(lihat 6.2). Bergantung pada ketentuan CDRL, persyaratan terkait antarmuka CSCI dapat disertakan dalam SRS
atau dalam spesifikasi persyaratan antarmuka (IRS).
Catatan: Jika CSCI dikembangkan dalam beberapa build, persyaratannya mungkin tidak ditentukan
sepenuhnya hingga build final. Perencanaan developer harus mengidentifikasi subset dari setiap persyaratan
CSCI yang akan ditentukan di setiap build dan subset yang akan diterapkan di setiap build.
Analisis persyaratan perangkat lunak untuk build yang diberikan harus diartikan dengan mendefinisikan
persyaratan CSCI yang teridentifikasi untuk build tersebut.
5.6 Desain perangkat lunak. Pengembang harus melakukan desain perangkat lunak sesuai dengan
Catatan: Jika CSCI dikembangkan dalam beberapa build, desainnya mungkin tidak sepenuhnya ditentukan
hingga build final. Desain perangkat lunak di setiap build harus diartikan sebagai desain yang diperlukan
untuk memenuhi persyaratan CSCI untuk diimplementasikan dalam build tersebut.
5.6.1 Keputusan desain skala CSCI. Pengembang harus menentukan dan mencatat keputusan desain CSCI-wide
(yaitu, keputusan tentang desain perilaku CSCI dan keputusan lain yang memengaruhi pemilihan dan desain unit
perangkat lunak yang terdiri dari CSCI). Hasilnya harus mencakup semua item yang berlaku di bagian desain luas
CSCI dari DID Deskripsi Desain Perangkat Lunak (SDD) (lihat 6.2). Bergantung pada ketentuan CDRL, desain
yang berkaitan dengan antarmuka dapat disertakan dalam SDD atau dalam deskripsi desain antarmuka (IDD)
dan desain yang berkaitan dengan database dapat disertakan dalam SDD atau dalam deskripsi desain database
(DBDD).
5.6.2 Desain arsitektur CSCI. Pengembang harus mendefinisikan dan merekam desain arsitektur dari setiap CSCI
(mengidentifikasi unit perangkat lunak yang terdiri dari CSCI, antarmukanya, dan konsep eksekusi di antara
mereka) dan ketertelusuran antara unit perangkat lunak dan persyaratan CSCI. Hasilnya harus mencakup semua
item yang berlaku di desain arsitektur dan bagian ketertelusuran DID Deskripsi Desain Perangkat Lunak (SDD)
(lihat 6.2). Bergantung pada ketentuan CDRL, desain yang berkaitan dengan antarmuka dapat disertakan dalam
SDD atau dalam deskripsi desain antarmuka (IDD).
Catatan: Unit perangkat lunak dapat terdiri dari unit perangkat lunak lain dan dapat diatur ke dalam banyak
tingkatan yang diperlukan untuk mewakili arsitektur CSCI. Misalnya, CSCI dapat dibagi menjadi tiga unit
perangkat lunak, yang masing-masing dibagi menjadi unit perangkat lunak tambahan, dan seterusnya.
5.6.3 Desain detail CSCI. Pengembang harus mengembangkan dan merekam deskripsi dari setiap unit perangkat
lunak. Hasilnya harus mencakup semua item yang berlaku di bagian desain detail DID Deskripsi Desain Perangkat
Lunak (SDD) (lihat 6.2). Bergantung pada ketentuan CDRL, desain yang berkaitan dengan antarmuka dapat
disertakan dalam SDD atau dalam deskripsi desain antarmuka (IDD) dan desain unit perangkat lunak yang
merupakan basis data atau yang mengakses atau memanipulasi basis data dapat disertakan dalam SDD atau
dalam deskripsi desain basis data (DBDD).
Machine Translated
5.7 Implementasi perangkat lunak dan pengujian unit. Pengembang harus melakukan perangkat lunak
implementasi dan pengujian unit sesuai dengan persyaratan berikut.
Catatan: Istilah "perangkat lunak" mencakup program komputer dan basis data komputer. Istilah "implementasi" berarti
mengubah desain perangkat lunak menjadi program komputer dan basis data komputer. Jika CSCI dikembangkan dalam
beberapa build, implementasi perangkat lunak dan pengujian unit CSCI tersebut tidak akan selesai hingga build final.
Implementasi perangkat lunak dan pengujian unit di setiap build harus ditafsirkan untuk menyertakan unit tersebut, atau
bagian dari unit, yang diperlukan untuk memenuhi persyaratan CSCI untuk diimplementasikan dalam build tersebut.
5.7.1 Implementasi perangkat lunak. Pengembang harus mengembangkan dan merekam perangkat lunak yang sesuai
dengan setiap unit perangkat lunak dalam desain CSCI. Kegiatan ini harus mencakup, sebagaimana berlaku, pengkodean
instruksi komputer dan definisi data, pembuatan basis data, pengisian basis data dan file data lainnya dengan nilai data, dan
aktivitas lain yang diperlukan untuk mengimplementasikan desain. Untuk perangkat lunak yang dapat dikirim, pengembang
harus memperoleh persetujuan pengakuisisi untuk menggunakan bahasa pemrograman apa pun yang tidak ditentukan dalam
kontrak.
Catatan: Unit perangkat lunak dalam desain mungkin atau mungkin tidak memiliki hubungan satu-ke-satu dengan entitas
kode dan data (rutinitas, prosedur, database, file data, dll.) yang mengimplementasikannya atau dengan file komputer
yang berisi entitas tersebut.
5.7.2 Mempersiapkan pengujian unit. Pengembang harus menetapkan kasus uji (dalam hal masukan, hasil yang diharapkan,
dan kriteria evaluasi), prosedur uji, dan data uji untuk menguji perangkat lunak yang sesuai dengan masing-masing unit
perangkat lunak. Kasus uji harus mencakup semua aspek desain detail unit. Pengembang harus mencatat informasi ini dalam
file pengembangan perangkat lunak (SDF) yang sesuai.
5.7.3 Melakukan pengujian unit. Pengembang harus menguji perangkat lunak yang sesuai dengan masing-masing unit
perangkat lunak. Pengujian harus sesuai dengan kasus dan prosedur pengujian unit.
5.7.4 Revisi dan pengujian ulang. Pengembang harus membuat semua revisi yang diperlukan untuk perangkat lunak,
melakukan semua pengujian ulang yang diperlukan, dan memperbarui file pengembangan perangkat lunak (SDF) dan produk
perangkat lunak lainnya sesuai kebutuhan, berdasarkan hasil pengujian unit.
5.7.5 Menganalisis dan mencatat hasil pengujian unit. Pengembang harus menganalisis hasil pengujian unit dan harus
mencatat hasil pengujian dan analisis dalam file pengembangan perangkat lunak (SDF) yang sesuai.
5.8 Integrasi dan pengujian unit. Pengembang harus melakukan integrasi unit dan pengujian di
Catatan 1: Integrasi dan pengujian unit berarti mengintegrasikan perangkat lunak yang sesuai dengan dua atau lebih
unit perangkat lunak, menguji perangkat lunak yang dihasilkan untuk memastikan bahwa perangkat lunak tersebut
berfungsi sebagaimana mestinya, dan melanjutkan proses ini hingga semua perangkat lunak di setiap CSCI terintegrasi da
Tahap terakhir dari pengujian ini adalah pengujian CSCI internal pengembang. Karena unit dapat terdiri dari unit lain,
beberapa integrasi dan pengujian unit dapat dilakukan selama pengujian unit. Persyaratan dalam bagian ini tidak
dimaksudkan untuk menduplikasi aktivitas tersebut.
Catatan 2: Jika CSCI dikembangkan dalam beberapa build, integrasi unit dan pengujian CSCI tersebut tidak akan selesai
hingga build final. Integrasi dan pengujian unit di setiap build harus ditafsirkan berarti mengintegrasikan perangkat lunak
yang dikembangkan di build saat ini dengan perangkat lunak lain yang dikembangkan di build itu dan sebelumnya, dan
menguji hasilnya.
Machine Translated
5.8.1 Mempersiapkan integrasi dan pengujian unit. Pengembang harus membuat kasus uji (dalam hal masukan, hasil
yang diharapkan, dan kriteria evaluasi), prosedur uji, dan data uji untuk melakukan integrasi dan pengujian unit.
Kasus uji harus mencakup semua aspek desain arsitektur CSCI dan CSCI. Pengembang harus mencatat informasi
ini dalam file pengembangan perangkat lunak (SDF) yang sesuai.
5.8.2 Melakukan integrasi dan pengujian unit. Pengembang harus melakukan integrasi dan pengujian unit. Pengujian
harus sesuai dengan kasus dan prosedur pengujian integrasi unit.
5.8.3 Revisi dan pengujian ulang. Pengembang harus membuat semua revisi yang diperlukan untuk perangkat lunak,
melakukan semua pengujian ulang yang diperlukan, dan memperbarui file pengembangan perangkat lunak (SDF)
dan produk perangkat lunak lainnya sesuai kebutuhan, berdasarkan hasil integrasi dan pengujian unit.
5.8.4 Menganalisis dan mencatat integrasi unit dan hasil pengujian. Pengembang harus menganalisis hasil integrasi
dan pengujian unit dan harus mencatat hasil pengujian dan analisis dalam file pengembangan perangkat lunak (SDF)
yang sesuai.
5.9 Pengujian kualifikasi CSCI. Pengembang harus melakukan pengujian kualifikasi CSCI sesuai dengan persyaratan
berikut.
Catatan 1: Pengujian kualifikasi CSCI dilakukan untuk menunjukkan kepada pengakuisisi bahwa persyaratan
CSCI telah dipenuhi. Ini mencakup persyaratan CSCI dalam spesifikasi kebutuhan perangkat lunak (SRS) dan
dalam spesifikasi persyaratan antarmuka terkait (IRS). Pengujian ini berbeda dengan pengujian CSCI internal
pengembang, yang dilakukan sebagai tahap akhir integrasi dan pengujian unit.
Catatan 2: Jika CSCI dikembangkan dalam beberapa build, pengujian kualifikasi CSCI-nya tidak akan selesai
hingga build final untuk CSCI tersebut, atau mungkin hingga build selanjutnya yang melibatkan item yang
diperlukan untuk berinteraksi dengan CSCI. Pengujian kualifikasi CSCI di setiap build harus diartikan sebagai
perencanaan dan pelaksanaan pengujian build saat ini dari setiap CSCI untuk memastikan bahwa persyaratan
CSCI yang akan diterapkan di build tersebut telah terpenuhi.
5.9.1 Kemandirian dalam pengujian kualifikasi CSCI. Orang(-orang) yang bertanggung jawab untuk pengujian
kualifikasi dari CSCI tertentu tidak boleh menjadi orang yang melakukan desain detail atau implementasi CSCI
tersebut. Hal ini tidak menghalangi orang yang melakukan desain detail atau implementasi CSCI untuk berkontribusi
pada proses tersebut, misalnya, dengan memberikan kasus pengujian yang bergantung pada pengetahuan tentang
implementasi internal CSCI.
5.9.2 Pengujian pada sistem komputer target. Pengujian kualifikasi CSCI harus mencakup pengujian pada sistem
komputer target atau sistem alternatif yang disetujui oleh pengakuisisi.
5.9.3 Mempersiapkan pengujian kualifikasi CSCI. Pengembang harus menentukan dan merekam persiapan pengujian,
kasus pengujian, dan prosedur pengujian yang akan digunakan untuk pengujian kualifikasi CSCI dan ketertelusuran
antara kasus pengujian dan persyaratan CSCI. Hasilnya harus mencakup semua item yang berlaku dalam Software
Test Description (STD) DID (lihat 6.2). Pengembang harus menyiapkan data pengujian yang diperlukan untuk
melaksanakan kasus pengujian dan memberikan pemberitahuan sebelumnya kepada pengakuisisi tentang waktu
dan lokasi pengujian kualifikasi CSCI.
Machine Translated
5.9.4 Uji coba kualifikasi CSCI yang kering. Jika pengujian kualifikasi CSCI akan disaksikan oleh pengakuisisi, pengembang
harus menjalankan kasus dan prosedur pengujian CSCI untuk memastikan bahwa semuanya lengkap dan akurat dan bahwa
perangkat lunak siap untuk pengujian disaksikan. Pengembang harus merekam hasil aktivitas ini dalam file pengembangan
perangkat lunak (SDF) yang sesuai dan harus memperbarui kasus uji dan prosedur CSCI sebagaimana mestinya.
5.9.5 Melakukan pengujian kualifikasi CSCI. Pengembang harus melakukan pengujian kualifikasi CSCI untuk setiap CSCI.
Pengujian harus sesuai dengan kasus dan prosedur pengujian CSCI.
5.9.6 Revisi dan pengujian ulang. Pengembang harus membuat revisi yang diperlukan untuk perangkat lunak, memberikan
pemberitahuan terlebih dahulu kepada pengakuisisi tentang pengujian ulang, melakukan semua pengujian ulang yang
diperlukan, dan memperbarui file pengembangan perangkat lunak (SDF) dan produk perangkat lunak lainnya sesuai kebutuhan,
berdasarkan hasil pengujian kualifikasi CSCI.
5.9.7 Menganalisis dan merekam hasil tes kualifikasi CSCI. Pengembang harus menganalisis dan mencatat hasil pengujian
kualifikasi CSCI. Hasilnya harus mencakup semua item yang berlaku dalam Software Test Report (STR) DID (lihat 6.2).
5.10 Integrasi dan pengujian CSCI/HWCI. Pengembang harus berpartisipasi dalam kegiatan pengujian dan integrasi CSCI/
HWCI sesuai dengan persyaratan berikut.
Catatan 1: Integrasi dan pengujian CSCI/HWCI berarti mengintegrasikan CSCI dengan interfacing HWCI dan CSCI,
menguji pengelompokan yang dihasilkan untuk menentukan apakah mereka bekerja bersama sebagaimana dimaksud,
dan melanjutkan proses ini hingga semua CSCI dan HWCI dalam sistem terintegrasi dan diuji. Tahap terakhir dari
pengujian ini adalah pengujian sistem internal pengembang.
Catatan 2: Jika sistem atau CSCI dikembangkan dalam beberapa build, integrasi dan pengujian CSCI/HWCI mungkin
tidak selesai hingga build final. Integrasi dan pengujian CSCI/HWCI di setiap build harus ditafsirkan berarti
mengintegrasikan build saat ini dari setiap CSCI dengan build saat ini dari CSCI dan HWCI lainnya dan menguji hasilnya
untuk memastikan bahwa persyaratan sistem yang akan diimplementasikan dalam build tersebut telah terpenuhi.
5.10.1 Mempersiapkan integrasi dan pengujian CSCI/HWCI. Pengembang harus berpartisipasi dalam mengembangkan dan
merekam kasus pengujian (dalam hal masukan, hasil yang diharapkan, dan kriteria evaluasi), prosedur pengujian, dan data
pengujian untuk melakukan integrasi dan pengujian CSCI/HWCI. Kasus uji harus mencakup semua aspek desain sistem dan
sistem secara keseluruhan. Pengembang harus merekam informasi terkait perangkat lunak dalam file pengembangan
perangkat lunak (SDF) yang sesuai.
5.10.2 Melakukan integrasi dan pengujian CSCI/HWCI. Pengembang harus berpartisipasi dalam integrasi dan pengujian CSCI/
HWCI. Pengujian harus sesuai dengan kasus dan prosedur pengujian integrasi CSCI/HWCI.
5.10.3 Revisi dan pengujian ulang. Pengembang harus melakukan revisi yang diperlukan pada perangkat lunak, berpartisipasi
dalam semua pengujian ulang yang diperlukan, dan memperbarui file pengembangan perangkat lunak (SDF) yang sesuai dan
produk perangkat lunak lainnya sesuai kebutuhan, berdasarkan hasil integrasi dan pengujian CSCI/HWCI.
Machine Translated
5.10.4 Menganalisis dan mencatat integrasi CSCI/HWCI dan hasil pengujian. Pengembang harus berpartisipasi dalam
menganalisis hasil integrasi dan pengujian CSCI/HWCI. Analisis terkait perangkat lunak dan hasil pengujian harus dicatat
dalam file pengembangan perangkat lunak (SDF) yang sesuai.
5.11 Pengujian kualifikasi sistem. Pengembang harus berpartisipasi dalam pengujian kualifikasi sistem sesuai dengan
Catatan 1: Pengujian kualifikasi sistem dilakukan untuk menunjukkan kepada pengakuisisi bahwa persyaratan sistem
telah dipenuhi. Ini mencakup persyaratan sistem dalam spesifikasi sistem/subsistem (SSS) dan dalam spesifikasi
persyaratan antarmuka (IRS) terkait. Pengujian ini berbeda dengan pengujian sistem internal pengembang, yang
dilakukan sebagai tahap akhir integrasi dan pengujian CSCI/HWCI.
Catatan 2: Jika sistem dikembangkan dalam beberapa build, pengujian kualifikasi dari sistem yang telah selesai tidak
akan dilakukan hingga build final. Pengujian kualifikasi sistem di setiap build harus diartikan sebagai perencanaan dan
pelaksanaan tes build saat ini dari sistem untuk memastikan bahwa persyaratan sistem yang akan diimplementasikan
dalam build tersebut telah terpenuhi.
5.11.1 Kemandirian dalam pengujian kualifikasi sistem. Orang(-orang) yang bertanggung jawab untuk memenuhi persyaratan
di bagian ini bukanlah orang yang melakukan desain detail atau implementasi perangkat lunak dalam sistem. Hal ini tidak
menghalangi orang yang melakukan desain detail atau implementasi perangkat lunak dalam sistem untuk berkontribusi pada
proses, misalnya, dengan memberikan kasus pengujian yang bergantung pada pengetahuan tentang implementasi internal
sistem.
5.11.2 Pengujian pada sistem komputer target. Pengujian kualifikasi sistem pengembang harus mencakup pengujian pada
sistem komputer target atau sistem alternatif yang disetujui oleh pengakuisisi.
5.11.3 Mempersiapkan pengujian kualifikasi sistem. Pengembang harus berpartisipasi dalam mengembangkan dan merekam
persiapan pengujian, kasus pengujian, dan prosedur pengujian yang akan digunakan untuk pengujian kualifikasi sistem dan
ketertelusuran antara kasus pengujian dan persyaratan sistem. Untuk sistem perangkat lunak, hasilnya harus mencakup
semua item yang berlaku dalam Software Test Description (STD) DID (lihat 6.2). Pengembang harus berpartisipasi dalam
menyiapkan data uji yang diperlukan untuk melaksanakan kasus uji dan dalam memberikan pemberitahuan terlebih dahulu
kepada pengakuisisi tentang waktu dan lokasi pengujian kualifikasi sistem.
5.11.4 Uji coba kualifikasi sistem secara kering. Jika pengujian kualifikasi sistem akan disaksikan oleh pihak pengakuisisi,
pengembang harus berpartisipasi dalam menjalankan kasus dan prosedur pengujian sistem untuk memastikan bahwa
semuanya lengkap dan akurat dan bahwa sistem siap untuk pengujian yang disaksikan. Pengembang harus merekam hasil
terkait perangkat lunak dari aktivitas ini dalam file pengembangan perangkat lunak (SDF) yang sesuai dan harus berpartisipasi
dalam memperbarui kasus dan prosedur uji sistem yang sesuai.
5.11.5 Melakukan pengujian kualifikasi sistem. Pengembang harus berpartisipasi dalam pengujian kualifikasi sistem. Partisipasi
ini harus sesuai dengan kasus dan prosedur pengujian sistem.
5.11.6 Revisi dan pengujian ulang. Pengembang harus membuat revisi yang diperlukan untuk perangkat lunak, memberikan
pemberitahuan terlebih dahulu kepada pengakuisisi tentang pengujian ulang, berpartisipasi dalam semua pengujian ulang
yang diperlukan, dan memperbarui file pengembangan perangkat lunak (SDF) dan produk perangkat lunak lainnya sesuai
kebutuhan, berdasarkan hasil pengujian kualifikasi sistem.
Machine Translated
MIL-STD-498 (versi PDF)by Google 5. Persyaratan Lengkap halaman 20
5.11.7 Menganalisis dan mencatat hasil uji kualifikasi sistem. Pengembang harus berpartisipasi dalam menganalisis dan mencatat
hasil pengujian kualifikasi sistem. Untuk sistem perangkat lunak, hasilnya harus mencakup semua item yang berlaku dalam Laporan
Pengujian Perangkat Lunak (STR) DID (lihat 6.2).
5.12 Mempersiapkan penggunaan perangkat lunak. Pengembang harus mempersiapkan penggunaan perangkat lunak sesuai dengan
Catatan: Jika perangkat lunak dikembangkan dalam beberapa build, perencanaan pengembang harus mengidentifikasi perangkat
lunak apa, jika ada, yang akan diterjunkan ke pengguna di setiap build dan tingkat penerjunan (misalnya, penerjunan penuh atau
penerjunan hanya untuk evaluator yang dipilih). Mempersiapkan penggunaan perangkat lunak di setiap build harus ditafsirkan
untuk menyertakan aktivitas yang diperlukan untuk menjalankan rencana fielding untuk build tersebut.
5.12.1 Mempersiapkan perangkat lunak yang dapat dieksekusi. Pengembang harus menyiapkan perangkat lunak yang dapat
dieksekusi untuk setiap situs pengguna, termasuk file batch, file perintah, file data, atau file perangkat lunak lain yang diperlukan untuk
menginstal dan mengoperasikan perangkat lunak pada komputer targetnya. Hasilnya harus mencakup semua item yang berlaku di
bagian perangkat lunak yang dapat dieksekusi dari Spesifikasi Produk Perangkat Lunak (SPS)
DID (lihat 6.2).
Catatan: Untuk memesan perangkat lunak yang dapat dijalankan saja (menunda pengiriman file sumber dan informasi dukungan
terkait ke build selanjutnya), pengakuisisi dapat menggunakan SPS DID, menyesuaikan semua kecuali bagian perangkat lunak
yang dapat dijalankan dari DID tersebut.
5.12.2 Menyiapkan deskripsi versi untuk situs pengguna. Pengembang harus mengidentifikasi dan merekam versi persis perangkat
lunak yang disiapkan untuk setiap situs pengguna. Informasi harus mencakup semua item yang berlaku dalam DID Deskripsi Versi
Perangkat Lunak (SVD) (lihat 6.2).
5.12.3 Menyiapkan manual pengguna. Pengembang harus menyiapkan manual pengguna sesuai dengan persyaratan berikut.
Catatan: Sedikit, jika ada, sistem memerlukan semua manual di bagian ini. Tujuannya adalah agar pihak pengakuisisi, dengan
masukan dari pengembang, menentukan manual mana yang sesuai untuk sistem tertentu dan hanya membutuhkan
pengembangan manual tersebut. Semua DID mengizinkan penggantian manual komersial atau lainnya yang berisi informasi yang
diperlukan. Manual di bagian ini biasanya dikembangkan secara paralel dengan pengembangan perangkat lunak, siap digunakan
dalam pengujian CSCI.
5.12.3.1 Panduan pengguna perangkat lunak. Pengembang harus mengidentifikasi dan mencatat informasi yang dibutuhkan oleh
pengguna langsung perangkat lunak (orang yang akan mengoperasikan perangkat lunak dan memanfaatkan hasilnya). Informasi harus
mencakup semua item yang berlaku dalam Panduan Pengguna Perangkat Lunak (SUM)
DID (lihat 6.2).
5.12.3.2 Manual input/output perangkat lunak. Pengembang harus mengidentifikasi dan mencatat informasi yang dibutuhkan oleh
orang yang akan mengirimkan masukan ke, dan menerima keluaran dari, perangkat lunak, mengandalkan orang lain untuk
mengoperasikan perangkat lunak di pusat komputer atau instalasi perangkat lunak terpusat atau jaringan lainnya. Informasi tersebut
harus mencakup semua item yang berlaku dalam Software Input/Output Manual (SIOM) DID (lihat 6.2).
Machine Translated
5.12.3.3 Panduan operator pusat perangkat lunak. Pengembang harus mengidentifikasi dan mencatat informasi yang
dibutuhkan oleh orang yang akan mengoperasikan perangkat lunak di pusat komputer atau instalasi perangkat lunak
terpusat atau jaringan lainnya, sehingga dapat digunakan oleh orang lain. Informasi harus mencakup semua item yang
berlaku dalam Software Center Operator Manual (SCOM) DID (lihat 6.2).
5.12.3.4 Manual pengoperasian komputer. Pengembang harus mengidentifikasi dan mencatat informasi yang diperlukan
untuk mengoperasikan komputer tempat perangkat lunak akan dijalankan. Informasi tersebut harus mencakup semua
item yang berlaku dalam Computer Operation Manual (COM) DID (lihat 6.2).
5.12.4 Pemasangan di lokasi pengguna. Pengembang harus:
A. Instal dan periksa perangkat lunak yang dapat dijalankan di situs pengguna yang ditentukan dalam kontrak.
B. Memberikan pelatihan kepada pengguna sebagaimana ditentukan dalam kontrak.
C. Memberikan bantuan lain ke situs pengguna sebagaimana ditentukan dalam kontrak.
5.13 Mempersiapkan transisi perangkat lunak. Pengembang harus mempersiapkan transisi perangkat lunak sesuai
dengan persyaratan berikut.
Catatan: Jika perangkat lunak dikembangkan dalam beberapa versi, perencanaan pengembang harus
mengidentifikasi perangkat lunak apa, jika ada, yang akan dialihkan ke agen dukungan di setiap versi.
Mempersiapkan transisi perangkat lunak di setiap build harus ditafsirkan untuk menyertakan aktivitas yang
diperlukan untuk melaksanakan rencana transisi untuk build tersebut.
5.13.1 Mempersiapkan perangkat lunak yang dapat dieksekusi. Pengembang harus menyiapkan perangkat lunak yang
dapat dijalankan untuk dialihkan ke situs dukungan, termasuk file batch, file perintah, file data, atau file perangkat lunak
lain yang diperlukan untuk menginstal dan mengoperasikan perangkat lunak pada komputer targetnya. Hasilnya harus
mencakup semua item yang berlaku di bagian perangkat lunak yang dapat dijalankan dari DID Spesifikasi Produk
Perangkat Lunak (SPS) (lihat 6.2).
5.13.2 Menyiapkan file sumber. Pengembang harus menyiapkan file sumber untuk dialihkan ke situs dukungan,
termasuk file batch, file perintah, file data, atau file lain yang diperlukan untuk membuat ulang perangkat lunak yang
dapat dijalankan. Hasilnya harus mencakup semua item yang berlaku di bagian file sumber DID Spesifikasi Produk
Perangkat Lunak (SPS) (lihat 6.2).
5.13.3 Menyiapkan deskripsi versi untuk situs dukungan. Pengembang harus mengidentifikasi dan merekam versi persis
perangkat lunak yang disiapkan untuk situs dukungan. Informasi harus mencakup semua item yang berlaku dalam DID
Deskripsi Versi Perangkat Lunak (SVD) (lihat 6.2).
5.13.4 Menyiapkan desain CSCI "as built" dan informasi terkait. Pengembang harus memperbarui deskripsi desain
setiap CSCI agar sesuai dengan perangkat lunak "as built" dan harus mendefinisikan dan mencatat: metode yang akan
digunakan untuk memverifikasi salinan perangkat lunak, penggunaan sumber daya perangkat keras komputer terukur
untuk CSCI, informasi lain yang diperlukan untuk mendukung perangkat lunak, dan ketertelusuran antara file sumber
CSCI dan unit perangkat lunak dan antara pengukuran pemanfaatan sumber daya perangkat keras komputer dan
persyaratan CSCI yang terkait dengannya. Hasilnya harus mencakup semua item yang berlaku di bagian kualifikasi,
dukungan perangkat lunak, dan ketertelusuran dari DID Spesifikasi Produk Perangkat Lunak (SPS) (lihat 6.2).
Machine Translated
Catatan: Dalam pengembangan perangkat keras, produk akhir adalah desain yang disetujui dari mana item perangkat
keras dapat diproduksi. Desain ini disajikan dalam spesifikasi produk. Sebaliknya, dalam pengembangan perangkat
lunak, produk akhirnya adalah perangkat lunak, bukan desainnya, dan "manufaktur" terdiri dari penggandaan perangkat
lunak secara elektronik, bukan menciptakannya kembali dari desain. Rancangan "as built" disertakan dalam spesifikasi
produk perangkat lunak bukan sebagai produk tetapi sebagai informasi yang dapat membantu agen pendukung
memahami perangkat lunak untuk memodifikasi, meningkatkan, dan sebaliknya mendukungnya.
5.13.5 Memperbarui deskripsi desain sistem. Pengembang harus berpartisipasi dalam memperbarui deskripsi desain sistem
agar sesuai dengan sistem "as built". Hasilnya harus mencakup semua item yang berlaku dalam DID Deskripsi Desain Sistem/
Subsistem (SSDD) (lihat 6.2).
5.13.6 Mempersiapkan manual pendukung. Pengembang harus menyiapkan manual pendukung sesuai dengan persyaratan
berikut.
Catatan: Tidak semua sistem membutuhkan manual di bagian ini. Tujuannya adalah agar pihak pengakuisisi, dengan
masukan dari pengembang, menentukan manual mana yang sesuai untuk sistem tertentu dan hanya membutuhkan
pengembangan manual tersebut. Semua DID mengizinkan penggantian manual komersial atau lainnya yang berisi
informasi yang diperlukan. Manual di bagian ini melengkapi deskripsi desain sistem/subsistem (SSDD) dan spesifikasi
produk perangkat lunak (SPS), yang berfungsi sebagai sumber informasi utama untuk dukungan perangkat lunak.
Panduan pengguna yang disebutkan di 5.12.3 juga berguna untuk mendukung personel.
5.13.6.1 Manual pemrograman komputer. Pengembang harus mengidentifikasi dan merekam informasi yang diperlukan untuk
memprogram komputer tempat perangkat lunak dikembangkan atau yang akan dijalankan.
Informasi harus mencakup semua item yang berlaku dalam Manual Pemrograman Komputer (CPM)
DID (lihat 6.2).
5.13.6.2 Manual dukungan firmware. Pengembang harus mengidentifikasi dan mencatat informasi yang diperlukan untuk
memprogram dan memprogram ulang setiap perangkat firmware tempat perangkat lunak akan dipasang.
Informasi tersebut harus mencakup semua item yang berlaku dalam Firmware Support Manual (FSM) DID (lihat 6.2).
5.13.7 Transisi ke lokasi pendukung yang ditunjuk. Pengembang harus:
A. Instal dan periksa perangkat lunak yang dapat dikirimkan di lingkungan dukungan yang ditentukan
kontrak.
B. Menunjukkan kepada pihak pengakuisisi bahwa perangkat lunak yang dapat dikirimkan dapat dibuat ulang (dikompilasi/
ditautkan/dimuat ke dalam produk yang dapat dijalankan) dan dipelihara menggunakan perangkat lunak dan
perangkat keras yang tersedia secara komersial, milik pengakuisisi, atau dapat dikirimkan secara kontraktual yang
ditetapkan dalam kontrak atau disetujui oleh pihak pengakuisisi.
C. Memberikan pelatihan kepada lembaga pendukung sebagaimana ditentukan dalam kontrak.
D. Memberikan bantuan lain kepada lembaga pendukung sebagaimana ditentukan dalam kontrak.
Machine Translated
5.14 Manajemen konfigurasi perangkat lunak. Pengembang harus melakukan manajemen konfigurasi perangkat lunak
Catatan: Jika sistem atau CSCI dikembangkan dalam beberapa build, produk perangkat lunak dari setiap build
mungkin merupakan penyempurnaan, atau tambahan, produk perangkat lunak dari build sebelumnya. Manajemen
konfigurasi perangkat lunak di setiap build harus dipahami terjadi dalam konteks produk perangkat lunak dan
kontrol yang ada di awal build.
5.14.1 Identifikasi konfigurasi. Pengembang harus berpartisipasi dalam memilih CSCI, seperti yang dilakukan di bawah
desain arsitektur sistem di 5.4.2, harus mengidentifikasi entitas yang akan ditempatkan di bawah kendali konfigurasi,
dan harus menetapkan pengidentifikasi unik proyek untuk setiap CSCI dan setiap entitas tambahan yang akan
ditempatkan di bawah konfigurasi kontrol. Entitas ini harus mencakup produk perangkat lunak yang akan dikembangkan
atau digunakan berdasarkan kontrak dan elemen lingkungan pengembangan perangkat lunak. Skema identifikasi
harus berada pada tingkat di mana entitas sebenarnya akan dikendalikan, misalnya file komputer, media elektronik,
dokumen, unit perangkat lunak, item konfigurasi. Skema identifikasi harus mencakup status versi/revisi/rilis dari setiap
entitas.
5.14.2 Kontrol konfigurasi. Pengembang harus menetapkan dan menerapkan prosedur yang menetapkan tingkat
pengendalian yang harus dilalui oleh setiap entitas yang teridentifikasi (misalnya, pengendalian penulis, pengendalian
tingkat proyek, pengendalian pengakuisisi); orang atau kelompok yang berwenang untuk mengotorisasi perubahan
dan membuat perubahan di setiap tingkat (misalnya, pemrogram/analis, pimpinan perangkat lunak, manajer proyek,
pengakuisisi); dan langkah-langkah yang harus diikuti untuk meminta otorisasi perubahan, memproses permintaan
perubahan, melacak perubahan, mendistribusikan perubahan, dan memelihara versi sebelumnya. Perubahan yang
mempengaruhi entitas yang sudah berada di bawah kendali pengakuisisi harus diusulkan kepada pengakuisisi sesuai
dengan bentuk dan prosedur yang ditetapkan dalam kontrak, jika ada.
Catatan: Sejumlah persyaratan dalam standar ini mengacu pada "kontrol konfigurasi tingkat proyek atau yang
lebih tinggi". Jika "tingkat proyek" bukan tingkat kontrol yang dipilih untuk proyek, rencana pengembangan
perangkat lunak harus menyatakan bagaimana persyaratan ini dipetakan ke tingkat yang dipilih.
5.14.3 Akuntansi status konfigurasi. Pengembang harus menyiapkan dan memelihara rekaman status konfigurasi
semua entitas yang telah ditempatkan di bawah kendali konfigurasi tingkat proyek atau yang lebih tinggi. Catatan-
catatan ini harus dipelihara selama masa kontrak. Mereka harus mencakup, sebagaimana berlaku, versi/revisi/rilis
saat ini dari setiap entitas, catatan perubahan entitas sejak ditempatkan di bawah kendali konfigurasi tingkat proyek
atau yang lebih tinggi, dan status laporan masalah/perubahan yang memengaruhi entitas.
5.14.4 Audit konfigurasi. Pengembang harus mendukung audit konfigurasi yang dilakukan pengakuisisi sebagaimana
ditentukan dalam kontrak.
Catatan: Audit konfigurasi ini dapat disebut Audit Konfigurasi Fungsional dan Audit Konfigurasi Fisik.
5.14.5 Pengemasan, penyimpanan, penanganan, dan pengiriman. Pengembang harus menetapkan dan menerapkan
prosedur untuk pengemasan, penyimpanan, penanganan, dan pengiriman produk perangkat lunak yang dapat dikirim.
Pengembang harus menyimpan salinan induk dari produk perangkat lunak yang dikirim selama masa kontrak.
Machine Translated
5.15 Evaluasi produk perangkat lunak. Pengembang harus melakukan evaluasi produk perangkat lunak sesuai dengan
Catatan: Jika sistem atau CSCI dikembangkan dalam beberapa build, produk perangkat lunak dari setiap build
harus dievaluasi dalam konteks tujuan yang ditetapkan untuk build tersebut. Produk perangkat lunak yang
memenuhi tujuan tersebut dapat dianggap memuaskan meskipun tidak ada informasi yang ditujukan untuk
pengembangan di build selanjutnya.
5.15.1 Evaluasi produk perangkat lunak dalam proses dan akhir. Pengembang harus melakukan evaluasi dalam
proses produk perangkat lunak yang dihasilkan dalam melaksanakan persyaratan standar ini.
Selain itu, pengembang harus melakukan evaluasi akhir dari setiap produk perangkat lunak yang dapat dikirimkan
sebelum pengirimannya. Produk perangkat lunak yang akan dievaluasi, kriteria yang akan digunakan, dan definisi
untuk kriteria tersebut diberikan dalam Lampiran D.
5.15.2 Rekaman evaluasi produk perangkat lunak. Pengembang harus menyiapkan dan memelihara catatan dari
setiap evaluasi produk perangkat lunak. Catatan-catatan ini harus dipelihara selama masa kontrak. Masalah dalam
produk perangkat lunak di bawah kendali konfigurasi tingkat proyek atau lebih tinggi harus ditangani seperti yang
dijelaskan dalam 5.17 (Tindakan perbaikan).
5.15.3 Kemandirian dalam evaluasi produk perangkat lunak. Orang yang bertanggung jawab untuk mengevaluasi
produk perangkat lunak bukanlah orang yang mengembangkan produk. Ini tidak menghalangi orang yang
mengembangkan produk perangkat lunak untuk mengambil bagian dalam evaluasi (misalnya, sebagai peserta dalam
penelusuran produk).
5.16 Jaminan kualitas perangkat lunak. Pengembang harus melakukan jaminan kualitas perangkat lunak sesuai
dengan persyaratan berikut.
Catatan: Jika sistem atau CSCI dikembangkan dalam beberapa build, aktivitas dan produk perangkat lunak dari
setiap build harus dievaluasi dalam konteks tujuan yang ditetapkan untuk build tersebut.
Suatu aktivitas atau produk perangkat lunak yang memenuhi tujuan tersebut dapat dianggap memuaskan
meskipun kehilangan aspek yang ditujukan untuk pembangunan selanjutnya. Perencanaan untuk jaminan kualitas
perangkat lunak termasuk dalam perencanaan pengembangan perangkat lunak (lihat 5.1.1).
5.16.1 Evaluasi jaminan kualitas perangkat lunak. Pengembang harus melakukan evaluasi berkelanjutan terhadap
aktivitas pengembangan perangkat lunak dan produk perangkat lunak yang dihasilkan untuk:
A. Pastikan bahwa setiap aktivitas yang diminta oleh kontrak atau yang dijelaskan dalam rencana pengembangan
perangkat lunak dilakukan sesuai dengan kontrak dan dengan rencana pengembangan perangkat lunak.
B. Pastikan bahwa setiap produk perangkat lunak yang disyaratkan oleh standar ini atau ketentuan kontrak lainnya
ada dan telah menjalani evaluasi produk perangkat lunak, pengujian, dan tindakan korektif sebagaimana
disyaratkan oleh standar ini dan ketentuan kontrak lainnya.
5.16.2 Catatan jaminan kualitas perangkat lunak. Pengembang harus menyiapkan dan memelihara catatan dari setiap
aktivitas jaminan kualitas perangkat lunak. Catatan-catatan ini harus dipelihara selama masa kontrak. Masalah dalam
produk perangkat lunak di bawah kendali konfigurasi tingkat proyek atau lebih tinggi dan masalah dalam aktivitas yang
diperlukan oleh kontrak atau dijelaskan dalam rencana pengembangan perangkat lunak harus ditangani seperti yang
dijelaskan dalam 5.17 (Tindakan perbaikan).
Machine Translated
5.16.3 Kemandirian dalam jaminan kualitas perangkat lunak. Orang yang bertanggung jawab untuk melakukan
evaluasi jaminan kualitas perangkat lunak bukanlah orang yang mengembangkan produk perangkat lunak, melakukan
aktivitas, atau bertanggung jawab atas produk atau aktivitas perangkat lunak. Ini tidak menghalangi orang-orang
tersebut untuk mengambil bagian dalam evaluasi ini. Orang yang bertanggung jawab untuk memastikan kepatuhan
terhadap kontrak harus memiliki sumber daya, tanggung jawab, wewenang, dan kebebasan organisasi untuk
mengizinkan evaluasi jaminan kualitas perangkat lunak yang objektif dan untuk memulai dan memverifikasi tindakan
korektif.
5.17 Tindakan korektif. Pengembang harus melakukan tindakan korektif sesuai dengan persyaratan berikut.
5.17.1 Laporan masalah/perubahan. Pengembang harus menyiapkan laporan masalah/perubahan untuk menjelaskan
setiap masalah yang terdeteksi dalam produk perangkat lunak di bawah kendali konfigurasi tingkat proyek atau lebih
tinggi dan setiap masalah dalam aktivitas yang diperlukan oleh kontrak atau dijelaskan dalam rencana pengembangan
perangkat lunak. Laporan masalah/perubahan harus menjelaskan masalah, tindakan perbaikan yang diperlukan, dan
tindakan yang diambil sampai saat ini. Laporan-laporan ini akan berfungsi sebagai masukan untuk sistem tindakan
korektif.
5.17.2 Sistem tindakan korektif. Pengembang harus menerapkan sistem tindakan korektif untuk menangani setiap
masalah yang terdeteksi dalam produk perangkat lunak di bawah kendali konfigurasi tingkat proyek atau lebih tinggi
dan setiap masalah dalam aktivitas yang diperlukan oleh kontrak atau dijelaskan dalam rencana pengembangan
perangkat lunak. Sistem harus memenuhi persyaratan berikut:
A. Input ke sistem terdiri dari laporan masalah/perubahan.
B. Sistem harus loop tertutup, memastikan bahwa semua masalah yang terdeteksi segera dilaporkan dan
dimasukkan ke dalam sistem, tindakan dimulai pada masalah tersebut, resolusi dicapai, status dilacak, dan
rekaman masalah dipertahankan selama masa kontrak.
C. Setiap masalah harus diklasifikasikan berdasarkan kategori dan prioritas, menggunakan kategori dan
prioritas dalam Lampiran C atau alternatif yang disetujui.
D. Analisis harus dilakukan untuk mendeteksi kecenderungan masalah yang dilaporkan.
e. Tindakan korektif harus dievaluasi untuk menentukan apakah masalah telah diselesaikan, tren yang merugikan
telah dibalik, dan perubahan telah diterapkan dengan benar tanpa menimbulkan masalah tambahan.
5.18 Tinjauan teknis dan manajemen bersama. Pengembang harus merencanakan dan mengambil bagian dalam
tinjauan teknis dan manajemen bersama (pengakuisisi/pengembang) sesuai dengan persyaratan berikut.
Catatan: Jika sistem atau CSCI dikembangkan dalam beberapa bangunan, jenis tinjauan bersama yang diadakan
dan kriteria yang diterapkan akan bergantung pada tujuan setiap bangunan. Produk perangkat lunak yang
memenuhi tujuan tersebut dapat dianggap memuaskan meskipun mereka kehilangan informasi yang ditujukan
untuk pengembangan di build selanjutnya.
Machine Translated
5.18.1 Tinjauan teknis bersama. Pengembang harus merencanakan dan mengambil bagian dalam kajian teknis bersama di
lokasi dan tanggal yang diusulkan oleh pengembang dan disetujui oleh pihak pengakuisisi. Tinjauan ini harus dihadiri oleh orang
yang memiliki pengetahuan teknis tentang produk perangkat lunak yang akan ditinjau.
Tinjauan harus fokus pada produk perangkat lunak dalam proses dan akhir, daripada materi yang dihasilkan khusus untuk
tinjauan. Review harus memiliki tujuan sebagai berikut:
A. Tinjau produk perangkat lunak yang berkembang, dengan menggunakan kriteria evaluasi produk perangkat lunak dalam
Lampiran D; meninjau dan menunjukkan solusi teknis yang diusulkan; memberikan wawasan dan mendapatkan umpan
balik tentang upaya teknis; memunculkan dan menyelesaikan masalah teknis.
B. Tinjau status proyek; memunculkan risiko jangka pendek dan jangka panjang mengenai teknis, biaya, dan
masalah jadwal.
C. Sampai pada strategi mitigasi yang disepakati untuk risiko yang teridentifikasi, dalam kewenangan mereka
hadiah.
D. Identifikasi risiko dan masalah yang akan diangkat pada tinjauan manajemen bersama.
e. Pastikan komunikasi terus-menerus antara pihak pengakuisisi dan personel teknis pengembang.
5.18.2 Tinjauan pengelolaan bersama. Pengembang harus merencanakan dan mengambil bagian dalam tinjauan manajemen
bersama di lokasi dan tanggal yang diusulkan oleh pengembang dan disetujui oleh pihak pengakuisisi. Tinjauan ini harus dihadiri
oleh orang-orang yang berwenang untuk membuat keputusan biaya dan jadwal dan harus memiliki tujuan sebagai berikut.
Contoh ulasan tersebut diidentifikasi dalam Lampiran E.
A. Selalu beri tahu manajemen tentang status proyek, arah yang diambil, teknis
kesepakatan tercapai, dan status keseluruhan dari produk perangkat lunak yang berkembang.
B. Selesaikan masalah yang tidak dapat diselesaikan pada tinjauan teknis bersama.
C. Sampai pada strategi mitigasi yang disepakati untuk risiko jangka pendek dan jangka panjang yang tidak mungkin terjadi
diselesaikan pada tinjauan teknis bersama.
D. Identifikasi dan selesaikan masalah dan risiko tingkat manajemen yang tidak diangkat pada teknis bersama
ulasan.
e. Dapatkan komitmen dan persetujuan pengakuisisi yang diperlukan untuk penyelesaian tepat waktu
proyek.
5.19 Kegiatan lainnya. Pengembang harus melakukan kegiatan berikut.
5.19.1 Manajemen risiko. Pengembang harus melakukan manajemen risiko selama proses pengembangan perangkat lunak.
Pengembang harus mengidentifikasi, menganalisis, dan memprioritaskan area proyek pengembangan perangkat lunak yang
melibatkan potensi risiko teknis, biaya, atau jadwal; mengembangkan strategi untuk mengelola risiko tersebut; merekam risiko
dan strategi dalam rencana pengembangan perangkat lunak; dan menerapkan strategi sesuai dengan rencana.
Machine Translated
5.19.2 Indikator manajemen perangkat lunak. Pengembang harus menggunakan indikator manajemen perangkat lunak
untuk membantu mengelola proses pengembangan perangkat lunak dan mengkomunikasikan statusnya kepada
pengakuisisi. Pengembang harus mengidentifikasi dan menetapkan serangkaian indikator manajemen perangkat lunak,
termasuk data yang akan dikumpulkan, metode yang akan digunakan untuk menginterpretasikan dan menerapkan data,
dan mekanisme pelaporan yang direncanakan. Pengembang harus mencatat informasi ini dalam rencana pengembangan
perangkat lunak dan harus mengumpulkan, menginterpretasikan, menerapkan, dan melaporkan indikator tersebut
sebagaimana dijelaskan dalam rencana. Indikator kandidat diberikan dalam Lampiran F.
5.19.3 Keamanan dan privasi. Pengembang harus memenuhi persyaratan keamanan dan privasi yang ditentukan dalam
kontrak. Persyaratan ini dapat mempengaruhi upaya pengembangan perangkat lunak, produk perangkat lunak yang
dihasilkan, atau keduanya.
5.19.4 Manajemen subkontraktor. Jika subkontraktor digunakan, pengembang harus memasukkan dalam subkontrak
semua persyaratan kontrak yang diperlukan untuk memastikan bahwa produk perangkat lunak dikembangkan sesuai
dengan persyaratan kontrak utama.
5.19.5 Antarmuka dengan agen perangkat lunak IV&V. Pengembang harus berinteraksi dengan agen Verifikasi dan
Validasi Independen (IV&V) perangkat lunak sebagaimana ditentukan dalam kontrak.
5.19.6 Koordinasi dengan pengembang rekanan. Pengembang harus berkoordinasi dengan pengembang rekanan,
kelompok kerja, dan kelompok antarmuka sebagaimana ditentukan dalam kontrak.
5.19.7 Peningkatan proses proyek. Pengembang harus secara berkala menilai proses yang digunakan pada proyek
untuk menentukan kesesuaian dan efektivitasnya. Berdasarkan penilaian ini, pengembang harus mengidentifikasi
perbaikan yang diperlukan dan bermanfaat untuk proses, harus mengidentifikasi perbaikan ini kepada pihak pengakuisisi
dalam bentuk pembaruan yang diusulkan untuk rencana pengembangan perangkat lunak dan, jika disetujui, harus
menerapkan perbaikan pada proyek.
Machine Translated
(versi PDF) 6. Catatan halaman 28
6. CATATAN
(Bagian ini berisi informasi yang bersifat umum atau penjelasan yang mungkin bermanfaat, tetapi tidak wajib.)
6.1 Penggunaan yang dimaksudkan. Standar ini berisi persyaratan untuk pengembangan dan
dokumentasi perangkat lunak. Penerapannya dijelaskan dalam 1.2.
6.2 Persyaratan data. Deskripsi Item Data (DID) berikut harus dicantumkan, sebagaimana berlaku, pada Daftar
Persyaratan Data Kontrak (Formulir DD 1423) saat standar ini diterapkan pada kontrak, untuk mendapatkan data, kecuali
di mana DOD FAR Supplement 227.405-70 membebaskan persyaratan untuk Formulir DD 1423.
Referensi Para Nomor DID DID Judul
5.1.1 DI-IPSC-81427 Rencana Pengembangan Perangkat Lunak (SDP)

5.1.2, 5.1.3 Rencana Uji Perangkat Lunak DI-IPSC-81438 (STP)
5.1.4 DI-IPSC-81428 Paket Instalasi Perangkat Lunak (SIP)
5.1.5 DI-IPSC-81429 Rencana Transisi Perangkat Lunak (STrP)
5.3.2 Deskripsi Konsep Operasional DI-IPSC-81430 (OCD)
5.3.3 DI-IPSC-81431 Spesifikasi Sistem/Subsistem (SSS)
5.3.3, 5.5 DI-IPSC-81434 Spesifikasi Persyaratan Antarmuka (IRS)
5.4.1, 5.4.2, 5.13.5 DI-IPSC-81432 Deskripsi Desain Sistem/Subsistem (SSDD)
5.4.1, 5.4.2, 5.6.1, DI-IPSC-81436 Deskripsi Desain Antarmuka (IDD)
5.6.2, 5.6.3
5.5 DI-IPSC-81433 Spesifikasi Kebutuhan Perangkat Lunak (SRS) 5.6.1, 5.6.2,
5.6.3 DI-IPSC-81435 Deskripsi Desain Perangkat Lunak (SDD) 5.4.1, 5.6.1, 5.6.3 Database DI-
IPSC-81437 Deskripsi Desain (DBDD) 5.9.3, 5.11.3 DI-IPSC-81439 Deskripsi Uji Perangkat Lunak
(STD) 5.9.7, 5.11.7 DI-IPSC-81440 Laporan Uji Perangkat Lunak (STR)
5.12.1, 5.13.1, 5.13.2, DI-IPSC-81441 Spesifikasi Produk Perangkat Lunak (SPS) 5.13.4
5.12.2, 5.13.3 DI-IPSC-81442 Deskripsi Versi Perangkat Lunak (SVD)

5.12.3.1 Panduan Pengguna Perangkat Lunak DI-IPSC-81443 (SUM)
5.12.3.2 DI-IPSC-81445 Panduan Input/Output Perangkat Lunak (SIOM)
5.12.3.3 DI-IPSC-81444 Panduan Operator Pusat Perangkat Lunak (SCOM)
5.12.3.4 DI-IPSC-81446 Panduan Pengoperasian Komputer (COM)
5.13.6.1 DI-IPSC-81447 Manual Pemrograman Komputer (CPM)
5.13.6.2 DI-IPSC-81448 Panduan Dukungan Firmware (FSM)
DID di atas adalah yang dibersihkan pada tanggal standar ini. Masalah DOD 5010.12 saat ini, Sistem Manajemen
Akuisisi dan Daftar Kontrol Persyaratan Data (AMSDL), harus diteliti untuk memastikan bahwa hanya DID yang sudah
dibersihkan yang dikutip pada Formulir 1423.
Machine Translated
MIL-STD-498 (versi PDF)by Google 6. Catatan halaman 29
6.3 Hubungan antara standar dan CDRL. Jika CDRL memanggil DID yang berbeda dari yang disebutkan dalam paragraf yang sesuai dari
standar ini, semua referensi ke DID dalam standar harus ditafsirkan berarti yang ada di CDRL.
6.4 Pengiriman isi alat. Bergantung pada ketentuan kontrak, pengembang dapat diizinkan untuk memenuhi persyaratan CDRL dengan
mengirimkan: 1) repositori atau basis data yang berisi informasi yang ditentukan dalam DID yang dikutip; 2) cara untuk mengakses
repositori atau database tersebut, seperti alat KASUS, jika belum tersedia untuk penerima yang ditunjuk di CDRL; dan 3) hard copy atau
daftar isi yang disimpan secara elektronik, yang menjelaskan bagaimana dan di mana mengakses informasi yang diperlukan di setiap
paragraf DID.
6.5 Panduan menjahit. Standar ini dan Deskripsi Item Data (DID) diterapkan atas kebijakan pengakuisisi. Dalam setiap aplikasi, standar
dan DID harus disesuaikan dengan persyaratan khusus dari program, fase program, atau struktur kontrak tertentu. Kehati-hatian harus
diambil untuk menghilangkan tugas yang menambah biaya dan data yang tidak perlu yang tidak menambah nilai pada proses atau produk.
Penyesuaian untuk standar mengambil bentuk penghapusan kegiatan, perubahan kegiatan untuk secara lebih eksplisit mencerminkan
penerapan upaya tertentu, atau penambahan kegiatan untuk memenuhi persyaratan program. Penjahit ini ditentukan dalam Pernyataan
Kerja.
Menyesuaikan untuk DID terdiri dari menghapus persyaratan untuk informasi yang tidak dibutuhkan dan membuat perubahan lain, seperti
menggabungkan dua dokumen di bawah satu sampul, yang tidak menambah beban kerja yang diperlukan. Penyesuaian DID untuk kiriman
ditentukan di Blok 16 dari CDRL.
6.6 Pelaporan biaya/jadwal. Laporan biaya/jadwal pengembang harus disiapkan di tingkat CSCI. Laporan biaya harus menunjukkan
pengeluaran yang dianggarkan versus pengeluaran aktual dan harus sesuai dengan Work Breakdown Structure (WBS) yang berlaku untuk
upaya pengembangan. Laporan-laporan ini juga harus menunjukkan kemajuan yang direncanakan, aktual, dan diprediksi oleh pihak
pengakuisisi.
6.7 Dokumen standardisasi terkait. Gambar 2 mengidentifikasi sekumpulan dokumen standardisasi yang terkait dengan pengembangan
perangkat lunak. Ini dan dokumen standardisasi lainnya dapat dikenakan atau dikutip dalam Pernyataan Kerja untuk melengkapi
persyaratan dalam MIL-STD-498. MIL-STD 498 tidak meminta dokumen-dokumen ini. Pihak pengakuisisi harus berhati-hati untuk
memastikan bahwa standar tambahan sesuai dengan proyek dan bahwa setiap konflik antara standar ini atau dengan MIL-STD-498
diidentifikasi dan diselesaikan.
6.8 Daftar istilah subjek (kata kunci). Daftar kata kunci berikut dapat digunakan untuk membuat katalog
atau mencirikan topik utama dalam standar ini.
Pembangunan/pengembangan bertahap Dokumentasi perangkat lunak

Item konfigurasi perangkat lunak komputer Implementasi perangkat lunak
Basis data Indikator manajemen perangkat lunak
Tinjauan teknis/manajemen bersama Evaluasi produk perangkat lunak
Konsep operasional Jaminan kualitas perangkat lunak
perangkat lunak yang dapat digunakan kembali
Analisis kebutuhan perangkat lunak
Manajemen risiko Keamanan perangkat lunak
Keamanan/privasi Dukungan perangkat lunak

Perangkat lunak Pengujian perangkat lunak
Manajemen konfigurasi perangkat lunak Satuan perangkat lunak
Pengembangan perangkat lunak Jahitan

Machine Translated
(versi PDF) 6. Catatan halaman 30
Topik dan Dokumen Standardisasi Terkait

Paragraf MIL-STD-498 (Tentukan versi terbaru sebelum digunakan)
Desain perilaku (5.4.1, MIL-STD-1801, Antarmuka Komputer Pengguna

5.6.1) MIL-HDBK-761, Panduan Rekayasa Manusia untuk Informasi Manajemen
Sistem
Keamanan komputer (4.2.4.2) DOD-5200.28 STD, Kriteria Evaluasi Sistem Komputer Tepercaya DoD
Manajemen konfigurasi (5.14) ANSI/IEEE Std 828, Standar untuk Konfigurasi Perangkat Lunak
Rencana Manajemen
ANSI/IEEE Std 1042, Panduan Manajemen Konfigurasi Perangkat Lunak
MIL-STD-973, Manajemen Konfigurasi
Pedoman MIL-HDBK-61 untuk Manajemen Konfigurasi
Akuisisi berkelanjutan dan MIL-STD-1840, Pertukaran Informasi Teknis Otomatis

dukungan siklus hidup (CALS) MIL-STD-1556, Program Pertukaran Data Pemerintah-Industri
MIL-HDBK-59, Program Akuisisi Berkelanjutan dan Dukungan Siklus Hidup
Panduan Implementasi
MIL-HDBK-800, Penyederhanaan Dokumentasi
MIL-D-28000, Representasi Digital untuk Komunikasi Data Produk:
Subset Aplikasi IGES dan Protokol Aplikasi IGES
MIL-M-28001, Persyaratan Markup dan Spesifikasi Gaya Generik untuk
Output Cetak Elektronik dan Pertukaran Teks
MIL-R-28002, Persyaratan untuk Representasi Grafik Raster dalam Biner
Format
MIL-D-28003, Representasi Digital untuk Komunikasi Data Ilustrasi:
Profil Aplikasi CGM
Tinjauan teknis dan ANSI/IEEE Std 1028, Standar untuk Tinjauan dan Audit Perangkat Lunak
manajemen bersama (5.18, App.E) MIL-STD-499, Manajemen Rekayasa
MIL-STD-1521, Tinjauan Teknis dan Audit untuk Sistem, Peralatan, dan Perangkat Lunak
Komputer (bagian audit digantikan oleh MIL-STD-973)
Bahasa pemrograman (5.7.1) FIPS-PUB-119, Ada (Juga diterbitkan sebagai ANSI/ISO/IEC 8652;
sebelumnya ANSI/MIL-STD-1815, Bahasa Pemrograman Ada)
Desain perangkat ANSI/IEEE Std 1016, Praktik yang Direkomendasikan untuk Deskripsi Desain
lunak (5.4, 5.6) Perangkat
Lunak IEEE Std 1016.1, Panduan untuk Deskripsi Desain Perangkat
Lunak IEEE/ANSI Std 990, Praktik yang Direkomendasikan untuk Ada sebagai Bahasa
Desain Program
Lingkungan pengembangan IEEE Std 1209, Praktik yang Direkomendasikan untuk Evaluasi dan
perangkat lunak Pemilihan Alat KASUS
(5.2) DOD-STD-1467 (AR), Lingkungan Dukungan Perangkat Lunak
MIL-HDBK-782 (AR), Akuisisi Lingkungan Dukungan Perangkat Lunak
Perencanaan pengembangan ANSI/IEEE Std 1058.1, Standar untuk Manajemen Proyek Perangkat Lunak
perangkat lunak (5.1.1) Rencana
Proses pengembangan ISO/IEC 12207 (saat diterbitkan), Proses Siklus Hidup Perangkat Lunak
perangkat ANSI/IEEE Std 1074, Standar untuk Mengembangkan Kehidupan Perangkat Lunak
lunak (4.1, App.G) Proses Siklus
MIL-STD-1803 (USAF), Program Integritas Pengembangan Perangkat Lunak
Buku panduan tentang MIL-STD-498 (saat dikeluarkan)
MIL-HDBK-498 (saat dikeluarkan)
Catatan: MIL-STD-498 tidak meminta dokumen-dokumen ini.
GAMBAR 2. Dokumen standardisasi terkait.

Machine Translated
(versi PDF) 6. Catatan Halaman 31
Topik dan Dokumen Standardisasi Terkait

Paragraf MIL-STD-498 (Tentukan versi terbaru sebelum digunakan)
Indikator manajemen ISO/IEC 9126, Karakteristik Kualitas dan Pedoman Penggunaannya ANSI/IEEE Std
perangkat 982.2, Panduan: Penggunaan Ukuran Standar untuk Menghasilkan Perangkat Lunak yang
lunak (5.19.2, App.F) Andal
IEEE Std 1045, Standar untuk Metrik Produktivitas Perangkat Lunak
IEEE Std 1061, Standar Metodologi Metrik Kualitas Perangkat Lunak
Kategori/prioritas IEEE Std 1044, Klasifikasi Standar untuk Anomali Perangkat Lunak
masalah perangkat lunak
(Lampiran C)
Evaluasi produk perangkat lunak ANSI/IEEE Std 1012, Standar untuk Rencana Verifikasi dan Validasi
(5.15) Perangkat Lunak
IEEE Std 1059, Panduan untuk Rencana Verifikasi dan Validasi
Jaminan kualitas perangkat lunak ISO 9001, Sistem Mutu - Model Jaminan Mutu di
(5.16) Desain/Pengembangan, Produksi, Instalasi, dan Servis
ISO 9000-3, Pedoman Penerapan ISO 9001 pada Pengembangan,
Pasokan, dan Pemeliharaan Perangkat Lunak
ANSI/IEEE Std 730, Standar untuk Rencana Penjaminan Kualitas Perangkat Lunak IEEE
Std 1298/A3563.1, Sistem Manajemen Kualitas Perangkat Lunak DOD-STD-2168,
Program Kualitas Perangkat Lunak Sistem Pertahanan MIL-HDBK-286,
Panduan untuk DOD-STD-2168
Persyaratan perangkat lunak ANSI/IEEE Std 830, Praktik yang Direkomendasikan untuk Perangkat Lunak
(5.3.3, 5.5) Spesifikasi Persyaratan
MIL-STD-490, Praktik Spesifikasi
Keamanan perangkat lunak (4.2.4.1) MIL-STD-882, Persyaratan Program Keamanan Sistem

MIL-HDBK-272, Desain Keselamatan dan Kriteria Evaluasi Senjata Nuklir
Sistem
IEEE Std 1228, Standar Rencana Keamanan Perangkat Lunak
Dukungan perangkat IEEE Std 1219, Standar Pemeliharaan Perangkat Lunak

lunak (semua paragraf) MIL-HDBK-347, Dukungan Perangkat Lunak Sumber Daya Komputer Misi Penting
Pengujian perangkat ANSI/IEEE Std 829, Standar untuk Dokumentasi Pengujian Perangkat Lunak
lunak (5.1.2, ANSI/IEEE Std 1008, Standar Pengujian Unit Perangkat Lunak
5.1.3, 5.7 - 5.11) ANSI/IEEE Std 1012, Standar untuk Verifikasi Perangkat Lunak
dan Rencana Validasi
IEEE Std 1059, Panduan untuk Rencana Verifikasi dan Validasi
Pengguna perangkat lunak ANSI/IEEE Std 1063, Standar untuk Dokumentasi Pengguna Perangkat Lunak
dokumentasi (5.12.3)
Rekayasa sistem (5.1.3, MIL-STD-499, Manajemen Rekayasa

5.3, 5.4, 5.10, 5.11) MIL-HDBK-805, Panduan Perangkat Lunak dan Perangkat Keras Komputer Mikro
Menjahit DOD-HDBK-248, Panduan Penerapan dan Penyesuaian Persyaratan untuk

(1.2.3, 6.5, Akuisisi Material Pertahanan
App.G, H MIL-HDBK-498 (saat dikeluarkan)
Pelatihan (5.12.4, 5.13.7) MIL-STD-1379, Program Pelatihan Militer
Struktur perincian pekerjaan (6.6) MIL-STD-881, Struktur Perincian Kerja untuk Item Material Pertahanan
Catatan: MIL-STD-498 tidak meminta dokumen-dokumen ini.
GAMBAR 2. Dokumen terkait standardisasi - lanjutan.

Machine Translated
(versi PDF) Lampiran A Halaman 32
LAMPIRAN A
DAFTAR SINGKATAN
A.1 Lingkup. Apendiks ini memberikan daftar akronim yang digunakan dalam standar ini, beserta artinya yang terkait. Apendiks ini
bukan merupakan bagian wajib dari standar. Informasi yang diberikan dimaksudkan untuk panduan saja.
A.2 Dokumen yang berlaku. Bagian ini tidak berlaku untuk lampiran ini.
A.3 Akronim.
KASUS Rekayasa Perangkat Lunak Berbantuan Komputer

CDRL Daftar Persyaratan Data Kontrak
COM Manual Pengoperasian Komputer
BPS Buku Panduan Pemrograman Komputer
CSCI Butir Konfigurasi Perangkat Lunak Komputer
DBDD Deskripsi Desain Basis Data
TELAH MELAKUKAN
Deskripsi Butir Data
DoD Departemen Pertahanan
FSM Panduan Dukungan Firmware
HWCI Item Konfigurasi Perangkat Keras
SLI Deskripsi Desain Antarmuka
IRS Spesifikasi Kebutuhan Antarmuka
IV&V Verifikasi dan Validasi Independen
OCD Deskripsi Konsep Operasional
SCOM Manual Operator Pusat Perangkat Lunak
SDD Deskripsi Desain Perangkat Lunak
SDF File Pengembangan Perangkat Lunak
SDL Perpustakaan Pengembangan Perangkat Lunak
SDP Rencana Pengembangan Perangkat Lunak
SIOM Panduan Input/Output Perangkat Lunak
MENYESAP Rencana Instalasi Perangkat Lunak
MENABUR Laporan kerja
SPS Spesifikasi Produk Perangkat Lunak
SRS Spesifikasi Kebutuhan Perangkat Lunak
SSDD Deskripsi Desain Sistem/Subsistem
SSS Spesifikasi Sistem/Subsistem
STD Deskripsi Tes Perangkat Lunak
STP Rencana Uji Perangkat Lunak
STR Laporan Uji Perangkat Lunak
STRP Rencana Transisi Perangkat Lunak
JUMLAH Panduan Pengguna Perangkat Lunak
SVD Deskripsi Versi Perangkat Lunak
SW Perangkat lunak
WBS Struktur rincian kerja

Machine Translated
(versi PDF) Lampiran B Halaman 33
LAMPIRAN B
MENAFSIRKAN MIL-STD-498 UNTUK PENGGABUNGAN PRODUK PERANGKAT LUNAK YANG DAPAT DIGUNAKAN KEMBALI
B.1 Lingkup. Apendiks ini menafsirkan MIL-STD-498 bila diterapkan pada penggabungan produk perangkat lunak yang
dapat digunakan kembali. Apendiks ini merupakan bagian wajib dari standar ini, tunduk pada penyesuaian oleh pengakuisisi.
B.2 Dokumen yang berlaku. Bagian ini tidak berlaku untuk lampiran ini.
B.3 Mengevaluasi produk perangkat lunak yang dapat digunakan kembali. Pengembang harus menentukan dalam rencana
pengembangan perangkat lunak kriteria yang akan digunakan untuk mengevaluasi produk perangkat lunak yang dapat
digunakan kembali untuk digunakan dalam memenuhi persyaratan kontrak. Kriteria umum harus menjadi kemampuan
produk perangkat lunak untuk memenuhi persyaratan yang ditentukan dan hemat biaya selama umur sistem. Contoh
kriteria khusus yang tidak wajib meliputi, namun tidak terbatas pada:
A. Kemampuan untuk memberikan kemampuan yang dibutuhkan dan memenuhi batasan

yang dibutuhkan b. Kemampuan untuk memberikan keselamatan,
keamanan, dan privasi yang diperlukan c. Keandalan/kedewasaan, yang dibuktikan
dengan track
record yang mapan d. Testabilitas e. Interoperabilitas dengan sistem lain dan elemen
eksternal sistem f. Masalah fielding,
termasuk: 1) Pembatasan penyalinan/pendistribusian perangkat lunak atau dokumentasi
2) Lisensi atau biaya lain yang berlaku untuk setiap salinan g.
Pemeliharaan, antara lain:
1) Kemungkinan produk perangkat lunak perlu diubah 2) Kelayakan untuk
mencapai perubahan itu 3) Ketersediaan dan kualitas
dokumentasi dan file sumber 4) Kemungkinan versi saat ini akan terus
didukung oleh pemasok 5) Dampak pada sistem jika versi saat ini tidak didukung 6) Hak data pengakuisisi
atas produk perangkat lunak 7) Jaminan tersedia h. Dampak biaya jangka pendek
dan jangka panjang dari penggunaan produk perangkat lunak i.
Risiko dan pengorbanan teknis,
biaya, dan jadwal dalam menggunakan produk perangkat lunak
B.4 Menafsirkan aktivitas MIL-STD-498 untuk produk perangkat lunak yang dapat digunakan kembali. Aturan berikut
berlaku dalam menafsirkan standar ini:
A. Setiap persyaratan yang memerlukan pengembangan produk perangkat lunak dapat dipenuhi oleh produk perangkat
lunak yang dapat digunakan kembali yang memenuhi persyaratan dan memenuhi kriteria yang ditetapkan dalam
rencana pengembangan perangkat lunak. Produk perangkat lunak yang dapat digunakan kembali dapat digunakan
apa adanya atau dimodifikasi dan dapat digunakan untuk memenuhi sebagian atau seluruh persyaratan. Misalnya,
persyaratan dapat dipenuhi dengan menggunakan rencana, spesifikasi, atau desain yang ada.
B. Ketika produk perangkat lunak yang dapat digunakan kembali yang digabungkan adalah perangkat lunak itu sendiri,
beberapa persyaratan dalam standar ini memerlukan interpretasi khusus. Gambar 3 memberikan interpretasi ini.
Masalah utama adalah apakah perangkat lunak akan dimodifikasi, apakah perangkat lunak yang tidak dimodifikasi
merupakan keseluruhan CSCI atau hanya satu atau lebih unit perangkat lunak, dan apakah perangkat lunak yang
tidak dimodifikasi memiliki catatan kinerja positif (tidak ada kriteria tegas untuk membuat penentuan ini). Gambar
tersebut disajikan dengan cara bersyarat: Jika aktivitas di kolom kiri diperlukan untuk jenis perangkat lunak
tertentu, gambar tersebut menjelaskan cara menginterpretasikan aktivitas untuk perangkat lunak yang dapat
digunakan kembali dari te tersebut.
Machine Translated
MIL-STD-498 (versi PDF)by Google Lampiran B halaman 34
Interpretasikan aktivitas sebagai berikut untuk setiap jenis perangkat lunak yang ada dan dapat digunakan kembali:
Jika ini
Aktivitas MIL- Untuk CSCI yang akan digunakan tidak dimodifikasi Untuk unit perangkat lunak yang akan digunakan Untuk perangkat lunak
STD-498 tidak dimodifikasi unit yang

diperlukan: dimodifikasi untuk /
Positif Tidak ada atau Positif Tidak ada atau selama proyek
catatan kinerja catatan kinerja catatan kinerja catatan kinerja
yang buruk yang buruk
5.1 Perencanaan
dan pengawasan Sertakan kegiatan dalam gambar ini dalam rencana proyek
proyek
5.2 Membangun Menetapkan dan menerapkan lingkungan pengujian perangkat lunak, pustaka pengembangan perangkat Terapkan
pengembangan perangkat lunak lunak, dan file pengembangan perangkat lunak yang sesuai untuk melakukan aktivitas pada gambar ini persyaratan lengkap
lingkungan
5.3 Analisis Pertimbangkan kemampuan perangkat lunak dalam menentukan konsep operasional & persyaratan sistem
kebutuhan sistem
Gunakan tes/ Uji untuk mengonfirmasi Gunakan tes/ Tes untuk Gunakan tes atau
catatan kinerja kemampuan memenuhi catatan kinerja mengkonfirmasi kemampuan catatan ke

untuk kebutuhan untuk untuk memenuhi kebutuhan menentukan
mengkonfirmasi kemampuan mengkonfirmasi kemampuan potensial untuk

untuk memenuhi kebutuhan untuk memenuhi kebutuhan memenuhi kebutuhan
5.4.1 Desain lebar Pertimbangkan kemampuan dan karakteristik perangkat lunak dalam merancang perilaku sistem dan dalam membuat keputusan
sistem desain sistem lainnya
5.4.2 Arsitektur Sertakan CSCI dalam arsitektur sistem; Pertimbangkan kemampuan dan karakteristik unit dalam menunjuk CSCI
sistem mengalokasikan persyaratan sistem dan mengalokasikan persyaratan sistem untuknya
desain untuk itu
5.5 Perangkat Lunak Tentukan persyaratan khusus proyek Pertimbangkan kemampuan dan karakteristik unit dalam menentukan
Analisa Kebutuhan yang harus dipenuhi CSCI; memverifikasi melalui persyaratan untuk CSCI yang menjadi bagiannya
catatan atau tes ulang bahwa
CSCI dapat menemui mereka
5.6.1 desain luas CSCI Tidak ada persyaratan: keputusan desain luas CSCI Pertimbangkan kemampuan dan karakteristik unit dalam mendesain perilaku
telah dibuat (mencatat desain "as built" di bawah CSCI dan membuat keputusan desain luas CSCI lainnya
5.13)
5.6.2 Desain Tidak ada persyaratan: arsitektur CSCI Sertakan unit dalam arsitektur CSCI dan alokasikan
arsitektur CSCI sudah ditentukan (mencatat desain "as Persyaratan CSCI untuk itu
built" di bawah 5.13)
5.6.3 Desain Tidak ada persyaratan: desain detail CSCI sudah Tidak ada persyaratan: unit sudah Modifikasi
detail CSCI ditentukan (mencatat desain "as built" di bawah 5.13) dirancang (mencatat desain "as built" di desain unit sesuai
bawah 5.13) kebutuhan
5.7.1 Implementasi Tidak ada persyaratan: perangkat lunak untuk Tidak ada persyaratan: perangkat lunak untuk Memodifikasi
perangkat lunak Unit CSCI sudah diimplementasikan unit sudah diterapkan perangkat lunak
untuk unit
5.7.2-5.7.5 Pengujian Tidak ada persyaratan: Lakukan secara selektif Tidak ada persyaratan: Lakukan pengujian ini
unit unit CSCI sudah diuji jika pertanyaan dan unit unit sudah
dapat diuji
diakses
GAMBAR 3. Menafsirkan MIL-STD-498 untuk penggabungan perangkat lunak yang dapat digunakan kembali.
Machine Translated
(versi PDF) Lampiran B halaman 35
Interpretasikan aktivitas sebagai berikut untuk setiap jenis perangkat lunak yang ada dan dapat digunakan kembali:
Jika ini
Aktivitas MIL- Untuk CSCI yang akan digunakan tidak dimodifikasi Untuk unit perangkat lunak yang akan digunakan Untuk perangkat lunak
STD-498 tidak dimodifikasi unit yang

diperlukan: dimodifikasi untuk /
Positif Tidak ada atau Positif Tidak ada atau selama proyek
catatan kinerja catatan kinerja catatan kinerja catatan kinerja
yang buruk yang buruk
5.8 Satuan Tidak ada persyaratan: Lakukan secara selektif Lakukan kecuali di Lakukan pengujian ini
integrasi dan unit CSCI jika pertanyaan dan mana integrasi
pengujian sudah unitnya ada sudah diuji/
terintegrasi dapat diakses dibuktikan
5.9 CSCI Tidak ada persyaratan: Lakukan ini Sertakan unit dalam pengujian kualifikasi CSCI
pengujian CSCI sudah teruji & pengujian
kualifikasi terbukti
5.10 Lakukan, kecuali jika Sertakan CSCI dalam Sertakan unitnya

Integrasi dan integrasi sudah integrasi dan Integrasi dan pengujian CSCI/HWCI
pengujian CSCI/ teruji/terbukti pengujian CSCI/
HWCI HWCI
5.11 Pengujian Sertakan CSCI dalam Sertakan unit dalam pengujian kualifikasi sistem
kualifikasi sistem pengujian kualifikasi sistem
5.12 Mempersiapkan Sertakan perangkat lunak untuk CSCI atau unit dalam perangkat lunak yang dapat dijalankan; sertakan dalam deskripsi
penggunaan perangkat lunak versi; menangani masalah lisensi apa pun; mencakup penggunaan CSCI atau unit, sebagaimana mestinya, melalui manual
pengguna/operator yang ada, baru, atau yang telah direvisi; pasang CSCI atau unit sebagai bagian dari keseluruhan sistem;
sertakan penggunaannya, sebagaimana mestinya, dalam pelatihan yang ditawarkan
5.13 Mempersiapkan Sertakan perangkat lunak untuk CSCI atau unit dalam perangkat lunak yang dapat dijalankan; menyiapkan file sumber untuk
transisi perangkat CSCI atau unit, jika tersedia; sertakan dalam deskripsi versi; menangani masalah lisensi apa pun; menyiapkan atau memberikan
lunak deskripsi desain "as built" untuk perangkat lunak yang desainnya diketahui; pasang CSCI atau unit di situs dukungan;
mendemonstrasikan kemampuan regenerasi jika sumber tersedia; termasuk dalam pelatihan yang ditawarkan
5.14 Manajemen Berlaku untuk semua produk perangkat lunak yang disiapkan, dimodifikasi, atau digunakan dalam menggabungkan perangkat lunak ini
konfigurasi
perangkat lunak
5.15 Evaluasi Berlaku untuk semua produk perangkat lunak yang disiapkan atau dimodifikasi dalam menggabungkan perangkat lunak ini; untuk
produk produk perangkat lunak yang digunakan tanpa perubahan, terapkan kecuali catatan kinerja positif atau bukti evaluasi masa
perangkat lunak lalu menunjukkan bahwa evaluasi semacam itu akan bersifat duplikatif
5.16 Kualitas Berlaku untuk semua aktivitas yang dilakukan dan semua produk perangkat lunak yang disiapkan, dimodifikasi, atau digunakan
perangkat lunak dalam menggabungkan perangkat lunak ini
jaminan
5.17 Korektif Terapkan untuk semua aktivitas yang dilakukan dan semua produk perangkat lunak yang disiapkan atau dimodifikasi dalam menggabungkan
tindakan perangkat lunak ini
5.18 Bersama Tutupi produk perangkat lunak yang disiapkan atau dimodifikasi dalam menggabungkan perangkat lunak ini
ulasan
5.19 Lainnya Terapkan persyaratan lengkap dari bagian ini

kegiatan
GAMBAR 3. Menafsirkan MIL-STD-498 untuk penggabungan perangkat lunak yang dapat digunakan kembali - lanjutan.
Machine Translated
(versi PDF) Lampiran C halaman 36
LAMPIRAN C
KATEGORI DAN KLASIFIKASI PRIORITAS

UNTUK PELAPORAN MASALAH
C.1 Lingkup. Lampiran ini berisi persyaratan untuk kategori dan skema klasifikasi prioritas untuk diterapkan pada
setiap masalah yang diajukan ke sistem tindakan korektif. Apendiks ini merupakan bagian wajib dari standar,
tunduk pada kondisi berikut: 1) persyaratan ini dapat disesuaikan oleh pihak pengakuisisi, dan 2) pengembang
dapat menggunakan kategori alternatif dan skema prioritas jika disetujui oleh pihak pengakuisisi.
C.2 Dokumen yang berlaku. Bagian ini tidak berlaku untuk lampiran ini.
C.3 Klasifikasi berdasarkan kategori. Pengembang harus:
A. Tetapkan setiap masalah dalam produk perangkat lunak ke satu atau lebih kategori pada Gambar 4.
B. Tetapkan setiap masalah dalam aktivitas ke satu atau lebih kategori pada Gambar 1 (ditunjukkan pada
awal Bagian 5).
C.4 Klasifikasi berdasarkan prioritas. Pengembang harus menetapkan setiap masalah dalam produk atau aktivitas
perangkat lunak ke salah satu prioritas pada Gambar 5.
Machine Translated
(versi PDF) Lampiran C Halaman 37
Kategori Berlaku untuk masalah di:
A. Rencana Salah satu rencana yang dikembangkan untuk proyek tersebut
B. Konsep Konsep operasional
C. Persyaratan Persyaratan sistem atau perangkat lunak
D. Desain Desain sistem atau perangkat lunak
e. Kode Kode perangkat lunak
F. Basis data/berkas data Database atau file data
G. Informasi tes Rencana pengujian, deskripsi pengujian, atau laporan pengujian
H. Manual Manual pengguna, operator, atau dukungan
Saya. Lainnya Produk perangkat lunak lainnya
GAMBAR 4. Kategori yang akan digunakan untuk mengklasifikasikan masalah pada produk perangkat lunak.
Prioritas Berlaku jika masalah dapat:
1 A. Mencegah pencapaian suatu operasional atau misi penting

kemampuan
B. Membahayakan keselamatan, keamanan, atau persyaratan lain yang disebut "kritis"
2 A. Berdampak buruk pada pencapaian kemampuan penting operasional atau misi dan
tidak ada solusi penyelesaian yang diketahui
B. Berdampak buruk pada risiko teknis, biaya, atau jadwal terhadap proyek atau dukungan siklus
hidup sistem, dan tidak ada solusi penyelesaian yang diketahui
3 A. Berdampak buruk pada pencapaian kemampuan penting operasional atau misi tetapi
solusi penyelesaian diketahui
B. Berdampak buruk pada risiko teknis, biaya, atau jadwal terhadap proyek atau dukungan siklus
hidup sistem, tetapi solusi penyelesaian diketahui
4 A. Mengakibatkan ketidaknyamanan atau gangguan pengguna/operator tetapi tidak mempengaruhi a

diperlukan kemampuan esensial operasional atau misi
B. Mengakibatkan ketidaknyamanan atau gangguan bagi personel pengembangan atau

pendukung, tetapi tidak menghalangi pemenuhan tanggung jawab tersebut
5 Efek lainnya
GAMBAR 5. Prioritas yang akan digunakan untuk mengklasifikasikan masalah.

Machine Translated
MIL-STD-498 (versiby Google
PDF) Lampiran D Halaman 38
LAMPIRAN D
EVALUASI PRODUK PERANGKAT LUNAK
D.1 Lingkup. Apendiks ini mengidentifikasi produk perangkat lunak yang menjalani evaluasi produk
perangkat lunak, mengidentifikasi kriteria yang akan digunakan untuk setiap evaluasi, dan berisi serangkaian
definisi default untuk kriteria evaluasi. Lampiran ini merupakan bagian wajib dari standar, sesuai dengan
kondisi berikut: 1) persyaratan ini dapat disesuaikan oleh pengakuisisi, 2) pengembang dapat menggunakan
kriteria atau definisi alternatif jika disetujui oleh pengakuisisi, dan 3) jika pengembangan produk perangkat
lunak tertentu telah disesuaikan dari standar, persyaratan untuk mengevaluasi produk tersebut tidak berlaku.
D.2 Dokumen yang berlaku. Bagian ini tidak berlaku untuk lampiran ini.
D.3 Evaluasi yang diperlukan. Gambar 6 mengidentifikasi produk perangkat lunak yang menjalani evaluasi
produk perangkat lunak dan menyatakan kriteria untuk diterapkan pada masing-masing produk. Setiap
produk dan kriteria perangkat lunak diberi label untuk tujuan identifikasi dan penyesuaian. Untuk mudahnya,
kriteria tersebut dapat diperlakukan sebagai sub-paragraf dari paragraf ini (merujuk pada kriteria pertama,
misalnya D.3.1.a). Produk perangkat lunak dinyatakan dalam huruf kecil untuk menyampaikan produk
generik, tidak harus dalam bentuk dokumen hard copy. Evaluasi produk tingkat sistem harus ditafsirkan
sebagai partisipasi dalam evaluasi ini. Beberapa kriteria bersifat subyektif. Karena itu, tidak ada persyaratan
untuk membuktikan bahwa kriteria telah terpenuhi; persyaratannya adalah melakukan evaluasi dengan
menggunakan kriteria ini dan mengidentifikasi kemungkinan masalah untuk didiskusikan dan diselesaikan.
D.4 Definisi kriteria. Paragraf berikut memberikan definisi untuk kriteria pada Gambar 6 yang mungkin tidak
cukup jelas. Kriteria dicantumkan dalam urutan abjad, sedekat mungkin dengan kata-kata yang digunakan
pada Gambar 6.
D.4.1 Mendeskripsikan (sebuah item) secara akurat. Kriteria ini, yang diterapkan pada instruksi pengguna/
operator/programmer dan pada desain "as built" dan deskripsi versi, berarti bahwa instruksi atau deskripsi
adalah gambaran yang benar dari perangkat lunak atau item lain yang dijelaskan.
D.4.2 Uji kasus, prosedur, data, hasil yang memadai. Kasus uji memadai jika mencakup semua persyaratan
yang berlaku atau keputusan desain dan menentukan masukan yang akan digunakan, hasil yang diharapkan,
dan kriteria yang akan digunakan untuk mengevaluasi hasil tersebut. Prosedur pengujian dianggap memadai
jika menentukan langkah-langkah yang harus diikuti dalam melaksanakan setiap kasus pengujian. Data uji
memadai jika memungkinkan pelaksanaan kasus uji dan prosedur uji yang direncanakan. Hasil uji atau uji
coba cukup jika menggambarkan hasil semua kasus uji dan menunjukkan bahwa semua kriteria telah
terpenuhi, mungkin setelah direvisi dan diuji ulang.
D.4.3 Konsisten dengan produk yang ditunjukkan. Kriteria ini berarti bahwa: (1) tidak ada pernyataan atau
representasi dalam satu produk perangkat lunak yang bertentangan dengan pernyataan atau representasi
dalam produk perangkat lunak lain, (2) istilah, akronim, atau singkatan tertentu berarti hal yang sama di
semua produk perangkat lunak, dan (3) item atau konsep tertentu disebut dengan nama atau deskripsi yang
sama di semua produk perangkat lunak.
D.4.4 Berisi semua informasi yang berlaku di (DID yang ditentukan). Kriteria ini menggunakan DID untuk
menentukan konten produk perangkat lunak yang diperlukan, terlepas dari apakah dokumen yang dapat
dikirim telah dipesan. Kelonggaran harus dibuat untuk penerapan setiap topik DID. Pemformatan yang
ditentukan dalam DID (paragraf dan penomoran wajib) tidak relevan dengan evaluasi ini.
Kriteria evaluasi
Perangkat lunak Mengandung Memenuhi Memenuhi Di bawah Magang. Mengikuti

Produk semua SOW, jika CDRL, jika berdiri terdiri- SW dev Kriteria Tambahan
aplikasi. info di: berlaku. berlaku. mampu tenda rencana
1. Perangkat lunak A. SDP B. C. D. e. F. G. Mencakup semua kegiatan/kiriman dalam SOW dan CDRL h. Konsisten dengan
rencana pengembangan TELAH MELAKUKAN
rencana proyek lainnya i. Menyajikan pendekatan suara
(5.1.1) (Tanggal terbaru)untuk pembangunan
2. Rencana pengujian perangkat A. STP B. C. D. e. F. G. Mencakup semua aktivitas kualifikasi terkait perangkat lunak di
lunak (5.1.2, 5.1.3) BERHASIL MENABUR
H. Mencakup semua persyaratan untuk item yang diuji i. Konsisten dengan

rencana proyek lainnya j. Menyajikan pendekatan suara
untuk pengujian
3. Instalasi perangkat lunak A. SIP B. C. D. e. F. G. Mencakup semua aktivitas instalasi situs pengguna di SOW h. Konsisten dengan
rencana (5.1.4) BERHASIL rencana proyek lainnya i. Menyajikan pendekatan suara
untuk instalasi
4. Rencana transisi perangkat lunak A. STRP DID B. C. D. e. F. G. Mencakup semua kegiatan terkait transisi di SOW h. Konsisten dengan
(5.1.5) rencana proyek lainnya i. Menyajikan pendekatan suara
untuk transisi
5. Konsep operasional (5.3.2) A. OCD B. C. D. e. F. G. Bisa dilakukan

MELAKUKAN
6. Persyaratan sistem (5.3.3) A. SSS, IRS B. C. D. e. F. G. Meliputi konsep operasional h. Layak saya. Dapat
DID diuji
7. Keputusan desain seluruh sistem A. DID SSDD, B. C. D. e. F. G. Konsisten dengan persyaratan sistem h. Bisa dilakukan
(5.4.1) IDD,
DBDD
8. Desain arsitektur sistem (5.4.2) A. SSDD, IDD B. C. D. e. F. G. Meliputi persyaratan sistem h. Konsisten dengan
DID keputusan desain seluruh sistem i. Bisa dilakukan
9. Persyaratan CSCI (5.5) A. SRS, IRS B. C. D. e. F. G. Meliputi persyaratan sistem yang dialokasikan ke CSCI h. Bisa dilakukan
DID Saya. Dapat diuji
GAMBAR 6. Produk perangkat lunak dan kriteria evaluasi terkait.

Kriteria evaluasi

10. Keputusan desain di seluruh A. SDD, B. C. D. e. F. G. Konsisten dengan persyaratan CSCI h. Bisa dilakukan
CSCI SLI,
(5.6.1) DBDD
DID
11. Arsitektur CSCI A. SDD, SLI B. C. D. e. F. G. Meliputi persyaratan CSCI h. Konsisten

desain dengan keputusan desain CSCI-wide i. Bisa dilakukan
(5.6.2) DID
12. Desain detail CSCI (5.6.3) A. SDD, B. C. D. e. F. G. Mencakup persyaratan CSCI yang dialokasikan untuk setiap unit h.
SLI, Konsisten dengan keputusan desain di seluruh CSCI
DBDD
DID
13. Perangkat lunak yang T/A B. C. D. e. F. G. Meliputi desain detail CSCI
diimplementasikan (5.7.1)
14. Deskripsi tes kualifikasi CSCI A. STD B. C. D. e. F. G. Mencakup semua persyaratan CSCI
(5.9.3) MELAKUKAN
15. Hasil tes kualifikasi CSCI A. STR DID B. C. D. e. F. G. Mencakup semua kasus uji kualifikasi CSCI yang direncanakan h.
(5.9.7) Menunjukkan bukti bahwa CSCI memenuhi persyaratannya
16. Uraian uji kualifikasi sistem A. STD B. C. D. e. F. G. Mencakup semua persyaratan sistem
(5.11.3) MELAKUKAN
17. Hasil uji kualifikasi sistem A. STR B. C. D. e. F. G. Mencakup semua kasus uji kualifikasi sistem yang direncanakan h.
TELAH MELAKUKAN
Menunjukkan bukti bahwa sistem memenuhi persyaratannya
(5.11.7)
18. Perangkat lunak yang dapat dijalankan T/A B. C. D. e. F. G. Memenuhi persyaratan pengiriman h.
(5.12.1, 5.13.1) Semua perangkat lunak yang diperlukan untuk eksekusi hadir i. Versi
sama persis dengan versi yang lolos pengujian j. Media yang dapat dikirim diberi
label secara akurat
GAMBAR 6. Produk perangkat lunak dan kriteria evaluasi terkait - lanjutan.

Kriteria evaluasi

19. Versi perangkat lunak A. SVD B. C. D. e. F. G. Secara akurat mengidentifikasi versi setiap komponen perangkat lunak (file,
deskripsi (5.12.2, TELAH MELAKUKAN
unit, CSCI, dll.) yang dikirimkan h. Secara akurat mengidentifikasi
5.13.3) perubahan yang dimasukkan
20. Panduan pengguna A. JUMLAH B. C. D. e. F. G. Secara akurat menjelaskan penginstalan dan penggunaan perangkat lunak ke
perangkat lunak TERJADI audiens yang dituju dari manual ini
(5.12.3.1)
21. Manual input/output A. SIOM B. C. D. e. F. G. Secara akurat menjelaskan masukan/keluaran perangkat lunak ke
perangkat lunak MELAKUKAN audiens yang dituju dari manual ini
(5.12.3.2)
22. Manual operator pusat A. SCOM B. C. D. e. F. G. Secara akurat menjelaskan penginstalan dan pengoperasian perangkat lunak kepada
perangkat lunak (5.12.3.3) MELAKUKAN audiens yang dituju dari manual ini
23. Manual pengoperasian komputer A. COM DID B. C. D. e. F. G. Secara akurat menggambarkan karakteristik operasional komputer
(5.12.3.4)
24. File sumber (5.13.2) A. SPS B. C. D. e. F. G. Memenuhi persyaratan pengiriman h. Semua

MELAKUKAN perangkat lunak yang diperlukan hadir i. Versi sama
persis dengan versi yang lolos pengujian j. Media yang dapat dikirim diberi label
secara akurat
25. Desain CSCI "As built" A. SPS B. C. D. e. F. G. Secara akurat menjelaskan desain "as built" dari CSCI h. Secara akurat menjelaskan
dan informasi terkait (5.13.4) MELAKUKAN prosedur kompilasi/membangun i. Menjelaskan prosedur modifikasi secara akurat
j. File sumber mencakup semua unit dalam desain CSCI k. Pemanfaatan
sumber daya terukur memenuhi persyaratan CSCI
26. Desain sistem "As built" (5.13.5) A. SSDD B. C. D. e. F. G. Secara akurat menggambarkan desain sistem "as built".
MELAKUKAN

Kriteria evaluasi

27. Manual A. BPS B. C. D. e. F. G. Secara akurat menggambarkan fitur pemrograman dari

pemrograman TELAH MELAKUKAN
komputer
komputer
(5.13.6.1)
28. Manual dukungan firmware A. FSM B. C. D. e. F. G. Menjelaskan fitur pemrograman firmware secara akurat
TELAH MELAKUKAN
(5.13.6.2)
29. Pengambilan sampel file T/A B. T/A D. e. F. G. Isi adalah saat ini dengan upaya yang sedang berlangsung h.
pengembangan perangkat Kasus/prosedur/data/hasil uji unit yang memadai i. Kasus/prosedur/ uji
lunak (5.7.2, 5.7.3, 5.8.1, integrasi unit yang memadai
5.8.4, 5.9.4, 5.10.1, 5.10.4, data/hasil j. Hasil
5.11.4) dry run kualifikasi CSCI yang memadai k. Kasus uji integrasi CSCI/
HWCI yang memadai/
prosedur/data/hasil
l. Hasil uji coba kualifikasi sistem yang memadai

Machine Translated
(versi PDF) Lampiran D Halaman 43
D.4.5 Sampul (seperangkat barang tertentu). Produk perangkat lunak "mencakup" sekumpulan item tertentu jika
setiap item dalam set telah ditangani dalam produk perangkat lunak. Misalnya, sebuah rencana mencakup SOW
jika setiap ketentuan dalam SOW diatur dalam rencana tersebut; desain mencakup seperangkat persyaratan jika
setiap persyaratan telah ditangani dalam desain; rencana pengujian mencakup serangkaian persyaratan jika
setiap persyaratan adalah subjek dari satu atau lebih pengujian. "Penutup" terkait dengan ketertelusuran ke
bawah (misalnya, dari persyaratan hingga desain) dalam DID perencanaan/deskripsi persyaratan, desain, dan
pengujian.
D.4.6 Layak. Kriteria ini berarti bahwa, dalam pengetahuan dan pengalaman evaluator, konsep tertentu,
serangkaian persyaratan, desain, pengujian, dll. Tidak melanggar prinsip atau pelajaran yang diketahui yang
membuatnya tidak mungkin untuk dilaksanakan.
D.4.7 Mengikuti rencana pengembangan perangkat lunak. Kriteria ini berarti bahwa produk perangkat lunak
menunjukkan bukti telah dikembangkan sesuai dengan pendekatan yang dijelaskan dalam rencana pengembangan
perangkat lunak. Contohnya termasuk standar desain dan pengkodean berikut yang dijelaskan dalam rencana.
Untuk rencana pengembangan perangkat lunak itu sendiri, kriteria ini berlaku untuk pembaruan rencana awal.
D.4.8 Konsisten secara internal. Kriteria ini berarti bahwa: (1) tidak ada dua pernyataan atau representasi dalam
produk perangkat lunak yang bertentangan satu sama lain, (2) istilah, akronim, atau singkatan tertentu berarti hal
yang sama di seluruh produk perangkat lunak, dan (3) item atau konsep tertentu. disebut dengan nama atau
deskripsi yang sama di seluruh produk perangkat lunak.
D.4.9 Memenuhi CDRL, jika ada. Kriteria ini berlaku jika produk perangkat lunak yang dievaluasi ditentukan
dalam CDRL dan telah diformat untuk dikirimkan pada saat evaluasi. Ini berfokus pada format, penandaan, dan
ketentuan lain yang ditentukan dalam CDRL, bukan pada konten, yang tercakup dalam kriteria lain.
D.4.10 Memenuhi SOW, jika ada. Kriteria ini berarti bahwa produk perangkat lunak memenuhi ketentuan
Pernyataan Kerja apa pun yang terkait dengannya. Misalnya, Pernyataan Kerja dapat menempatkan kendala
pada konsep operasional atau desain.
D.4.11 Menyajikan pendekatan suara. Kriteria ini berarti bahwa berdasarkan pengetahuan dan pengalaman
evaluator, suatu rencana yang diberikan merupakan cara yang masuk akal untuk melaksanakan kegiatan yang
diperlukan.
D.4.12 Menunjukkan bukti bahwa (barang yang diuji) memenuhi persyaratannya. Kriteria ini berarti bahwa hasil
tes yang direkam menunjukkan bahwa item yang diuji lulus semua tes pertama kali atau direvisi dan diuji ulang
sampai tes lulus.
D.4.13 Dapat diuji. Persyaratan atau serangkaian persyaratan dianggap dapat diuji jika pengujian yang objektif
dan layak dapat dirancang untuk menentukan apakah setiap persyaratan telah dipenuhi.
D.4.14 Dapat Dimengerti. Kriteria ini berarti "dapat dipahami oleh audiens yang dituju". Misalnya, produk
perangkat lunak yang dimaksudkan untuk komunikasi pemrogram-ke-pemrogram tidak perlu dipahami oleh non-
pemrogram. Produk yang mengidentifikasi audiensnya dengan benar (berdasarkan informasi di Blok 3 dari DID
yang sesuai) dan dianggap dapat dipahami oleh audiens tersebut memenuhi kriteria ini.
Machine Translated
(versi PDF) Lampiran E Halaman 44
LAMPIRAN E
TINJAUAN MANAJEMEN BERSAMA KANDIDAT
E.1 Lingkup. Apendiks ini menjelaskan sekumpulan kandidat tinjauan manajemen bersama yang mungkin diadakan
selama proyek pengembangan perangkat lunak. Apendiks ini bukan merupakan bagian wajib dari standar ini. Informasi
yang diberikan dimaksudkan untuk panduan saja.
E.2 Dokumen yang berlaku. Bagian ini tidak berlaku untuk lampiran ini.
E.3 Asumsi. Lampiran ini membuat asumsi berikut:
A. Pihak pengakuisisi telah meninjau produk yang bersangkutan sebelumnya, dan satu atau lebih tinjauan teknis
bersama telah diadakan untuk menyelesaikan masalah, meninggalkan tinjauan manajemen bersama sebagai
forum untuk menyelesaikan masalah terbuka dan mencapai kesepakatan mengenai penerimaan setiap produk.
B. Setiap tinjauan dapat dilakukan secara bertahap, menangani setiap tinjauan dengan subset dari item yang
terdaftar atau subset dari sistem atau CSCI yang sedang ditinjau.
E.4 Peninjauan kandidat. Diberikan di bawah ini adalah serangkaian tinjauan manajemen bersama kandidat yang
mungkin diadakan selama proyek pengembangan perangkat lunak. Tidak ada niat untuk meminta tinjauan ini atau untuk
menghalangi alternatif atau kombinasi dari tinjauan ini. Tujuan melengkapi yang diberikan dalam 5.18.2.
E.4.1 Tinjauan rencana perangkat lunak. Peninjauan ini diadakan untuk menyelesaikan masalah terbuka terkait satu
atau beberapa hal berikut:
A. Rencana pengembangan perangkat lunak

b. Rencana pengujian perangkat
lunak c. Rencana instalasi perangkat
lunak d. Rencana transisi perangkat lunak
E.4.2 Tinjauan konsep operasional. Tinjauan ini diadakan untuk menyelesaikan masalah terbuka mengenai konsep
operasional untuk sistem perangkat lunak.
E.4.3 Tinjauan persyaratan sistem/subsistem. Tinjauan ini diadakan untuk menyelesaikan masalah terbuka mengenai
persyaratan yang ditentukan untuk sistem atau subsistem perangkat lunak.
E.4.4 Tinjauan desain sistem/subsistem. Peninjauan ini diadakan untuk menyelesaikan masalah terbuka terkait satu
A. Keputusan desain seluruh sistem atau subsistem b. Desain

arsitektur dari sistem perangkat lunak atau subsistem
E.4.5 Tinjauan persyaratan perangkat lunak. Tinjauan ini diadakan untuk menyelesaikan masalah terbuka mengenai
persyaratan yang ditentukan untuk CSCI.
Machine Translated
(versi PDF) Lampiran E halaman 45
E.4.6 Tinjauan desain perangkat lunak. Peninjauan ini diadakan untuk menyelesaikan masalah terbuka terkait satu
A. Keputusan desain CSCI-wide b. Desain

arsitektur CSCI c. Desain detail CSCI atau
bagiannya (seperti database)
E.4.7 Tinjauan kesiapan uji. Peninjauan ini diadakan untuk menyelesaikan masalah terbuka terkait satu atau
beberapa hal berikut:
A. Status lingkungan pengujian perangkat lunak b. Kasus

pengujian dan prosedur pengujian yang akan digunakan untuk pengujian kualifikasi CSCI atau pengujian
kualifikasi sistem
C. Status perangkat lunak yang akan diuji
E.4.8 Review hasil pengujian. Tinjauan ini diadakan untuk menyelesaikan masalah terbuka terkait hasil pengujian
kualifikasi CSCI atau pengujian kualifikasi sistem.
E.4.9 Tinjauan kegunaan perangkat lunak. Peninjauan ini diadakan untuk menyelesaikan masalah terbuka terkait
satu atau beberapa hal berikut:
A. Kesiapan perangkat lunak untuk instalasi di situs pengguna b. Manual

pengguna dan operator c. Deskripsi versi
perangkat lunak d. Status persiapan dan
kegiatan instalasi
E.4.10 Tinjauan dukungan perangkat lunak. Peninjauan ini diadakan untuk menyelesaikan masalah terbuka terkait
satu atau beberapa hal berikut:
A. Kesiapan perangkat lunak untuk transisi ke lembaga pendukung b. Spesifikasi

produk perangkat lunak c. Perangkat lunak
pendukung manual d. Deskripsi versi
perangkat lunak e. Status persiapan dan
aktivitas transisi, termasuk transisi lingkungan pengembangan perangkat lunak, jika ada
E.4.11 Tinjauan kebutuhan kritis. Peninjauan ini diadakan untuk menyelesaikan masalah terbuka terkait penanganan
persyaratan penting, seperti persyaratan keselamatan, keamanan, dan privasi.
Machine Translated
(versi PDF) Lampiran F Halaman 46
LAMPIRAN F
INDIKATOR MANAJEMEN KANDIDAT
F.1 Lingkup. Lampiran ini mengidentifikasi seperangkat indikator manajemen yang mungkin digunakan pada proyek
pengembangan perangkat lunak. Apendiks ini bukan merupakan bagian wajib dari standar ini. Informasi yang diberikan
dimaksudkan untuk panduan saja.
F.2 Dokumen yang berlaku. Bagian ini tidak berlaku untuk lampiran ini.
F.3 Indikator Kandidat. Diberikan di bawah ini adalah seperangkat indikator manajemen kandidat yang mungkin digunakan pada
proyek pengembangan perangkat lunak. Tidak ada niat untuk memaksakan indikator-indikator ini atau menghalangi orang lain.
A. Volatilitas persyaratan: jumlah total persyaratan dan perubahan persyaratan dari waktu ke waktu.
B. Ukuran perangkat lunak: jumlah unit yang direncanakan dan aktual, baris kode, atau ukuran lainnya
pengukuran dari waktu ke waktu.
C. Kepegawaian perangkat lunak: tingkat kepegawaian yang direncanakan dan aktual dari waktu ke waktu.
D. Kompleksitas perangkat lunak: kompleksitas setiap unit perangkat lunak.
e. Kemajuan perangkat lunak: jumlah unit perangkat lunak yang direncanakan dan aktual yang dirancang, diimplementasikan,
unit diuji, dan terintegrasi dari waktu ke waktu.
F. Masalah/perubahan status laporan: jumlah total, jumlah ditutup, nomor dibuka pada periode pelaporan saat ini, usia,
prioritas.
G. Bangun konten rilis: jumlah unit perangkat lunak yang direncanakan dan aktual yang dirilis di masing-masing
membangun.
H. Pemanfaatan sumber daya perangkat keras komputer: penggunaan sumber daya perangkat keras komputer yang
direncanakan dan aktual (seperti kapasitas prosesor, kapasitas memori, kapasitas perangkat input/output, kapasitas
perangkat penyimpanan tambahan, dan kapasitas peralatan komunikasi/jaringan) dari waktu ke waktu.
Saya. Kinerja tonggak: tanggal yang direncanakan dan aktual dari tonggak proyek utama.
J. Memo/pengerjaan ulang: jumlah sumber daya yang dikeluarkan untuk mengganti atau merevisi produk perangkat lunak
setelah ditempatkan di bawah kendali konfigurasi tingkat proyek atau yang lebih tinggi.
k. Pengaruh penggunaan kembali: pemecahan dari masing-masing indikator di atas untuk digunakan kembali versus perangkat lunak baru
produk.
Machine Translated
(versi PDF) Lampiran G Halaman 47
LAMPIRAN G
PEDOMAN STRATEGI PROGRAM, TAILORING, DAN BUILD PLANNING
G.1 Lingkup. Apendiks ini mengidentifikasi tiga strategi program yang digunakan oleh DoD dan menunjukkan bagaimana
MIL-STD-498 dapat diterapkan di bawah masing-masing strategi ini dan pada proyek yang melibatkan rekayasa ulang.
Apendiks ini bukan merupakan bagian wajib dari standar. Informasi yang diberikan dimaksudkan untuk panduan saja.
G.2 Dokumen yang berlaku. Dokumen yang dikutip dalam lampiran ini adalah sebagai berikut:
A. DODI 5000.2, Kebijakan dan Prosedur Manajemen Akuisisi Pertahanan
B. DODI 8120.2, Proses Manajemen Siklus Hidup Sistem Informasi Otomatis, Tinjauan,
dan Persetujuan Pencapaian
G.3 Strategi program kandidat. DODI 8120.2 menjelaskan tiga strategi program dasar ditambah strategi umum yang disebut
"lainnya", yang mencakup variasi, kombinasi, dan alternatif dari ketiganya. DODI 5000.2 mengidentifikasi strategi serupa,
yang disebut strategi akuisisi. Tiga strategi dasar dirangkum di bawah ini dan di Gambar 7.
A. Rancangan Induk. Strategi "rancangan besar" (tidak disebutkan dalam DODI 5000.2 tetapi diperlakukan sebagai
satu strategi) pada dasarnya adalah strategi "sekali jalan, lakukan setiap langkah-sekali". Sederhananya:
menentukan kebutuhan pengguna, menentukan persyaratan, merancang sistem, mengimplementasikan sistem,
menguji, memperbaiki, dan mengirimkan.
B. Tambahan. Strategi "tambahan" (disebut "Peningkatan Produk yang Direncanakan" di DODI 5000.2) menentukan
kebutuhan pengguna dan menentukan persyaratan sistem, kemudian melakukan pengembangan selanjutnya
dalam urutan pembangunan. Build pertama menggabungkan sebagian dari kapabilitas yang direncanakan, build
berikutnya menambahkan lebih banyak kapabilitas, dan seterusnya, hingga sistem selesai.
C. Evolusioner. Strategi "evolusioner" (disebut "evolusioner" di kedua Instruksi DOD) juga mengembangkan sistem
dalam build, tetapi berbeda dari strategi inkremental dalam mengakui bahwa kebutuhan pengguna tidak
sepenuhnya dipahami dan semua persyaratan tidak dapat ditentukan sebelumnya. Dalam strategi ini, kebutuhan
pengguna dan persyaratan sistem ditentukan sebagian di awal, kemudian disempurnakan di setiap build berikutnya.
Tentukan Beberapa Perangkat Lunak
Strategi Program Semua Persyaratan Terlebih Dahulu? Siklus Sementara Lapangan?
Pengembangan?
Rancangan Induk Ya TIDAK TIDAK
Inkremental (Direncanakan sebelumnya Ya Ya Mungkin

Peningkatan Produk)
Evolusioner TIDAK Ya Ya
GAMBAR 7. Fitur utama dari tiga strategi program DOD.

Machine Translated
(versi PDF) Lampiran G Halaman 48
G.4 Memilih strategi program yang tepat. Strategi program dipilih oleh pengakuisisi, tetapi dapat diusulkan oleh calon
atau pengembang terpilih. Gambar 8 mengilustrasikan pendekatan analisis risiko untuk memilih strategi yang tepat.
Pendekatannya terdiri dari daftar item risiko (negatif) dan item peluang (positif) untuk setiap strategi; menugaskan
setiap item tingkat risiko atau peluang Tinggi, Sedang, atau Rendah; dan membuat keputusan tentang strategi mana
yang akan digunakan berdasarkan trade-off antara risiko dan peluang. Isian yang ditampilkan hanya sebagai contoh
pertimbangan. Analisis yang sebenarnya dapat menggunakan orang lain. Entri "KEPUTUSAN" pada garis bawah
menunjukkan strategi mana yang dipilih.
G.5 Hubungan MIL-STD-498 dengan strategi program. Strategi program biasanya berlaku untuk keseluruhan sistem.
Perangkat lunak di dalam sistem dapat diperoleh di bawah strategi yang sama atau di bawah strategi yang berbeda,
seperti mensyaratkan agar semua perangkat lunak diselesaikan dalam pembuatan sistem yang pertama. Gambar 9,
10, dan 11 menunjukkan bagaimana MIL-STD-498 dapat diterapkan di bawah masing-masing strategi program yang
diidentifikasi dalam G.3. Gambar 12 menunjukkan bagaimana MIL-STD-498 dapat diterapkan pada proyek rekayasa
ulang. Keempat angka tersebut, karena kebutuhan, disederhanakan. Misalnya, mereka menunjukkan aktivitas MIL
STD-498 secara berurutan ketika mereka mungkin benar-benar sedang berlangsung, tumpang tindih, atau berulang;
mereka menunjukkan setiap produk perangkat lunak sebagai satu kesatuan, tanpa menggambarkan draf atau
pembaruan awal; dan mereka mewakili setiap produk perangkat lunak dengan nama DID yang sesuai, ketika produk
perangkat lunak sebenarnya adalah informasi yang diminta oleh DID, tidak harus dalam bentuk dokumen cetak.
G.6 Pembuatan perangkat lunak perencanaan dan penyesuaian MIL-STD-498. Merencanakan pembuatan perangkat
lunak pada proyek dan menyesuaikan MIL-STD-498 untuk setiap pembuatan dapat dilakukan dengan beberapa cara.
Pihak pengakuisisi dapat, misalnya, memilih keseluruhan strategi program dan menyesuaikan standar untuk
keseluruhan kontrak, menyerahkannya kepada pengembang untuk menyusun perangkat lunak yang dibangun dan
mengusulkan penyesuaian untuk setiap bangunan. Sebagai alternatif, pihak pengakuisisi dapat menyusun perangkat
lunak dan menentukan penyesuaian untuk masing-masing perangkat lunak sebagai bagian dari kontrak. Pendekatan
yang dipilih akan bergantung pada proyek. Paragraf di bawah memberikan panduan untuk merencanakan pembangunan
dan menyesuaikan standar tanpa mencoba membagi aktivitas ini antara pengakuisisi dan pengembang.
G.6.1 Mengidentifikasi bangunan dan tujuannya. Langkah pertama dalam perencanaan pembangunan perangkat lunak
adalah menyusun rangkaian satu atau lebih pembangunan dan mengidentifikasi tujuan dari setiap pembangunan.
Bagian atas Gambar 13 mengilustrasikan perencanaan tersebut. Dalam contoh, spesifikasi sistem/subsistem (SSS)
sudah ada dan pemenuhan persyaratannya dibagi menjadi empat build, dua di antaranya akan menjadi prototipe yang
dikirim ke kumpulan pengguna terpilih, dan dua di antaranya akan benar-benar diterjunkan. Tujuan selanjutnya dari
Build 4 adalah mentransisikan perangkat lunak ke lembaga pendukung yang ditunjuk. Proyek yang sebenarnya akan
memperluas tujuan ini.
G.6.2 Mengidentifikasi kegiatan MIL-STD-498 yang akan dilakukan di setiap bangunan. Langkah selanjutnya dalam
perencanaan pembangunan adalah mengidentifikasi aktivitas MIL-STD-498 mana yang berlaku di setiap pembangunan
dan menentukan sejauh mana penerapannya. Bagian bawah Gambar 13 menunjukkan awal dari perencanaan
tersebut. Tercantum di sebelah kiri adalah paragraf MIL-STD-498. Entri lembar kerja menunjukkan di build mana setiap
aktivitas akan dilakukan dan menyertakan catatan apa pun terkait sifat setiap aktivitas di setiap build. Misalnya, gambar
menunjukkan bahwa setiap build akan mencakup perencanaan pengembangan perangkat lunak (5.1.1), tetapi sifat
perencanaan tersebut berubah di setiap build. Beberapa aktivitas tidak akan diterapkan sama sekali di build tertentu,
beberapa akan diterapkan secara identik di semua build, dan beberapa akan diterapkan secara berbeda di build yang
berbeda. Karena beberapa aspek proyek, seperti jumlah dan jenis CSCI, mungkin belum teridentifikasi pada saat
lembar kerja diisi, penyelesaian lembar kerja itu sendiri mungkin bersifat inkremental. Pedoman berikut berlaku:
Rancangan Induk Tambahan Evolusioner
Barang Risiko Mempertaruhkan Barang Risiko Mempertaruhkan Barang Risiko Mempertaruhkan
(Alasan menentang strategi ini) Tingkat (Alasan menentang strategi ini) Tingkat (Alasan menentang strategi ini) Tingkat
- Persyaratan tidak dipahami dengan H - Persyaratan tidak dipahami dengan H

baik baik
- Sistem terlalu besar untuk melakukan semuanya M - Pengguna lebih memilih semua kemampuan pada M - Pengguna lebih memilih semua kemampuan pada M
sekali pengiriman pertama pengiriman pertama
- Perubahan cepat dalam misi H - Perubahan cepat dalam misi H

teknologi diantisipasi - dapat teknologi diharapkan - dapat mengubah
mengubah persyaratan persyaratan
- Staf atau anggaran terbatas M

tersedia sekarang
Barang Peluang Op. Barang Peluang Op. Barang Peluang Op.

(Alasan menggunakan strategi ini) Tingkat (Alasan menggunakan strategi ini) Tingkat (Alasan menggunakan strategi ini) Tingkat
- Pengguna lebih memilih semua kemampuan pada M - Diperlukan kemampuan awal H - Diperlukan kemampuan awal H
pengiriman pertama
- Pengguna lebih suka menghapus sistem L - Sistem pecah secara alami M - Sistem pecah secara alami menjadi M
lama sekaligus kenaikan bertahap
- Pendanaan/staffing akan bersifat H - Pendanaan/staffing akan bersifat H

inkremental inkremental
- Umpan balik pengguna dan pemantauan H

perubahan teknologi diperlukan
untuk memahami persyaratan
lengkap
KEPUTUSAN: GUNAKAN STRATEGI INI
GAMBAR 8. Contoh analisis risiko untuk menentukan strategi program yang tepat.
Perencanaan dan pengawasan proyek
SDP STP SIP/STRP
CSCI
Satuan Kual
CSCI 1: Perangkat lunak Integ/ Tes Bersiaplah
Mengimplementasikan / Menguji Perangkat Lunak untuk SW
Desain perangkat lunak Tes Satuan STR Menggunakan
Persyaratan
STD
Analisis SW yang dapat dieksekusi
SDD/IDD/DBDD SVD
SRS/IRS Sistem Manual pengguna/operasi
CSCI Kualifikasi CSCI/HWCI
Satuan Kual Integ/ Tes
CSCI 2: Perangkat lunak Integ/ Tes Tes
Sistem Mengimplementasikan / Menguji Perangkat Lunak STD STR Bersiaplah
Sistem Desain Desain perangkat lunak Tes Satuan STR untuk SW
Persyaratan Persyaratan
STD Transisi
Analisis Analisis
SSDD/IDD SDD/IDD/DBDD SW yang dapat dieksekusi
OCD SSS/IRS SRS/IRS File sumber
SVD
SPS
SSDD yang diperbarui
HWCI(s) (Tidak dicakup oleh MIL-STD-498) Dukungan manual
Lingkungan pengembangan SW, manajemen konfigurasi SW, evaluasi produk SW, jaminan kualitas SW, tindakan korektif, tinjauan bersama, manajemen risiko, indikator manajemen perangkat lunak, keamanan/privasi, antarmuka dengan IV&V,
koordinasi dengan pengembang rekanan, peningkatan proses proyek
Catatan: Semua aktivitas mungkin lebih berkelanjutan, tumpang tindih, dan berulang daripada yang dapat ditunjukkan oleh gambar.
GAMBAR 9. Satu cara yang mungkin untuk menerapkan MIL-STD-498 pada strategi program Rancangan Besar.
BUILD 1: Tetapkan persyaratan sistem dan perangkat lunak dan instal perangkat lunak yang mengimplementasikan subset dari persyaratan tersebut di situs pengguna
SDP (fokus pada Build 1) STP untuk Build 1 SIP untuk Build 1; STRP pendahuluan
CSCI Bersiaplah
Satuan Kual untuk SW
CSCI 1: Perangkat lunak Integ/ Tes Menggunakan
Mengimplementasikan / Menguji Perangkat Lunak

Desain perangkat lunak Tes Satuan STR untuk Build 1 SW yang dapat dieksekusi
Persyaratan
STD untuk Build 1 SVD
Analisis Sistem Manual pengguna/operasi untuk
Sebagian SDD/IDD/DBDD CSCI Kualifikasi CSCI/HWCI Membangun 1
SRS/IRS* Satuan Kual Integ/ Tes
Perangkat lunak Integ/ Tes Tes
Sistem CSCI 2: Mengimplementasikan / Menguji Perangkat Lunak STR STD untuk (TIDAK
Sistem Desain Desain perangkat lunak Tes Satuan STR untuk Build 1 Perangkat lunak
STD untuk Membangun 1 Transisi)
Analisis Analisis Membangun 1
SSDD/IDD* Sebagian SDD/IDD/DBDD
OCD* SSS/IRS* SRS/IRS* (Semua aktivitas mungkin lebih berkelanjutan,
tumpang tindih, dan berulang daripada yang dapat
* Dimaksudkan untuk menjadi ditunjukkan oleh gambar tersebut)
lengkap dan stabil HWCI(s) (Tidak dicakup oleh MIL-STD-498)
Lingkungan pengembangan SW, manajemen konfigurasi SW, evaluasi produk SW, jaminan kualitas SW, tindakan korektif, tinjauan bersama, aktivitas lainnya
BUILD 2: Instal perangkat lunak yang telah selesai di situs pengguna dan alihkan perangkat lunak ke agen dukungan perangkat lunak
SDP diperbarui STP diperbarui untuk Build 2 SIP untuk Build 2; menyelesaikan STRP
untuk Build 2 CSCI Bersiaplah
CSCI 1: Perangkat lunak Integ/ Tes Menggunakan

Persyaratan
SDD/IDD/DBDD lengkap CSCI Kualifikasi CSCI/HWCI Membangun 2
Sistem CSCI 2: Mengimplementasikan / Menguji Perangkat Lunak STR STD untuk Bersiaplah
Sistem Desain Desain perangkat lunak Tes Satuan STR untuk Build 2 untuk SW
STD untuk Build 2 Transisi
SSDD/IDD* SDD/IDD/DBDD lengkap SW yang dapat dieksekusi
OCD* SSS/IRS* SRS/IRS* File sumber
SVD
* Diperbarui hanya jika SPS, SSDD yang diperbarui
perlu; tidak dimaksudkan untuk berubah HWCI(s) (Tidak dicakup oleh MIL-STD-498) Dukungan manual
GAMBAR 10. Salah satu cara yang mungkin untuk menerapkan MIL-STD-498 pada strategi program Inkremental.
Machine
BUILD Translated
1: Tetapkan by Google
persyaratan sistem/perangkat lunak awal dan instal prototipe yang mengimplementasikan subset dari persyaratan tersebut di lokasi pengguna yang dipilih
SDP (fokus pada Build 1) (Tidak ada STP untuk Build 1: tidak SIP untuk Build 1; STRP pendahuluan
ada pengujian yang berkualitas) (TIDAK Bersiaplah
CSCI 1: Perangkat lunak
Integ/ Tes) Menggunakan

Desain perangkat lunak Tes Satuan (Tidak ada STR untuk Build 1) SW yang dapat dieksekusi
Persyaratan (Tidak ada STD untuk Build 1) SVD
Analisis (Tidak Sist Manual pengguna/operasi untuk
Sebagian SDD/IDD/DBDD (TIDAK Kualifikasi CSCI/HWCI Membangun 1
SRS/IRS sebagian Satuan Kual Integ/ Tes)
Perangkat lunak Integ/ Tes) Tes
Sistem CSCI 2: Mengimplementasikan / Menguji Perangkat Lunak (Tidak ada STD/ (TIDAK
Sistem Desain Desain perangkat lunak Tes Satuan (Tidak ada STR untuk STR untuk Build 1) Perangkat lunak
Persyaratan Persyaratan (Tidak ada STD untuk Bangun 1) Transisi)
Analisis Analisis Bangun 1)
SSDD/IDD* Sebagian SDD/IDD/DBDD
OCD* SSS/IRS* SRS/IRS sebagian (Semua aktivitas mungkin lebih berkelanjutan,
tumpang tindih, dan berulang daripada yang dapat ditunjukkan oleh
*Pendahuluan/ sebagian gambar tersebut)
HWCI(s) (Tidak dicakup oleh MIL-STD-498)
BUILD 2: Sempurnakan dan lengkapi persyaratan; instal perangkat lunak yang telah selesai di situs pengguna; transisi perangkat lunak ke agen dukungan perangkat lunak
SDP diperbarui untuk STP untuk Build 2 SIP untuk Build 2; menyelesaikan STRP
Build 2 CSCI Bersiaplah
CSCI 1: Perangkat lunak
Integ/ Tes Menggunakan

Persyaratan
SDD/IDD/DBDD* CSCI Kualifikasi CSCI/HWCI Membangun 2
Sistem CSCI 2: Mengimplementasikan / Menguji Perangkat Lunak STR STD untuk Bersiaplah
Sistem Desain Desain perangkat lunak Tes Satuan STR untuk Build 2 untuk SW
STD untuk Build 2 Transisi
SSDD/IDD* SDD/IDD/DBDD* SW yang dapat dieksekusi
OCD* SSS/IRS* SRS/IRS* File sumber
SVD
* Disempurnakan dari Build 1 SPS, SSDD yang diperbarui
dan selesai HWCI(s) (Tidak dicakup oleh MIL-STD-498) Dukungan manual
GAMBAR 11. Salah satu cara yang mungkin untuk menerapkan MIL-STD-498 pada strategi program Evolutionary.
Machine Translated by Google REENGINEER
TEKNIK KE DEPAN
SDP STP SIP/STRP
REDOKUMENTASI TERJEMAHAN
CSCI 1: Terjemahkan CSCI

kepada Ada Satuan Kual
Perangkat lunak Integ/ Tes
Perangkat lunak Implementasi/ Tes
Desain Permintaan SW: Tes Unit: STR
Analisis: merevisi dan menerjemahkan redocument STD
redocument perangkat lunak permintaan yang
diturunkan turunan des Bersiaplah
untuk SW
SDD/IDD/DBDD Menggunakan
SRS/IRS
SW yang dapat dieksekusi
REDOKUMENTASI RESTRUKTURISASI SVD
Sistem Manual pengguna/operasi
CSCI 2: Restrukturisasi ke CSCI Kualifikasi CSCI/HWCI
TEKNIK TERBALIK berorientasi objek Satuan Kual Integ/ Tes
Perangkat lunak Pelaksana/ Tes STD STR
Sistem SW Sistem Desain Permintaan SW: Tes Unit: STR Bersiaplah
Persyaratan Persyaratan Perangkat Lunak Desain Analisis: restrukturisasi/restrukturisasi redocument perangkat STD untuk SW
Analisis Desain Analisis lunak redocument yang diturunkan Transisi
turunan des
OCD SSS/IRS Permintaan SSDD/IDD permintaan SW yang dapat dieksekusi
Desain turunan SDD/IDD/DBDD File sumber
turunan dari warisan SRS/IRS SVD
dari perangkat lunak perangkat SPS
lunak lawas REDOKUMENTASI PENARGETAN ULANG SSDD yang diperbarui
Dukungan manual
Tentukan Kumpulkan yang ada Desain CSCI 3: Penargetan ulang ke CSCI
produk perangkat lunak yang diminta; menganalisisnya kembali; sistem komputer baru Satuan Kual
turunan untuk Perangkat lunak Integ/ Tes
sistem Desain/permintaan SW; berdasarkan desain/ Perangkat lunak Implementasi/ Tes
reeng'd permintaan sistem temuan Desain Permintaan SW: Tes Unit: STR
turunan untuk sistem Analisis: merevisi dan menargetkan ulang merevisi STD
perangkat lunak dan mendokumentasikan ulang perangkat lunak yang
diturunkan dari permintaan yang
diturunkan (Semua aktivitas mungkin lebih berkelanjutan,
SDD/IDD/DBDD tumpang tindih, dan berulang daripada
SRS/IRS yang dapat ditunjukkan oleh gambar
tersebut)
Lingkungan pengembangan SW, manajemen konfigurasi SW, evaluasi produk SW, jaminan kualitas SW, tindakan korektif, tinjauan bersama, manajemen risiko, indikator manajemen perangkat lunak, keamanan/privasi, antarmuka dengan IV&V,
koordinasi dengan pengembang rekanan, peningkatan proses proyek
GAMBAR 12. Salah satu cara yang mungkin untuk menerapkan MIL-STD-498 pada proyek rekayasa ulang.
LEMBAR KERJA PERENCANAAN BANGUNAN Membangun
UNTUK MIL-STD-498 1 2 3 4
1. Identifikasi dengan benar tujuan dari setiap bangunan Kirim ke yang dipilih Kirim ke yang dipilih Kirim ke semua pengguna a Kirim ke semua pengguna a
pengguna prototipe pengguna prototipe sistem teruji yang sistem teruji yang
operasional yang memenuhi operasional yang memenuhi memenuhi persyaratan Build 1 memenuhi semua persyaratan
2. Tunjukkan di bawah ini kegiatan mana yang akan dilakukan persyaratan tingkat sistem persyaratan Build 1 plus: dan 2 plus: SSS-4, SSS-7, tingkat sistem; transisi ke lembaga
dicapai selama pengembangan setiap bangunan. berikut: SSS-1, SSS-5, ... SSS-2, SSS-3, SSS-15, ..., SSS-10, ..., SSS-1248 pendukung yang ditunjuk
Tambahkan catatan klarifikasi sesuai kebutuhan. SSS-1249
SSS-1250
Para Aktivitas
5.1 PERENCANAAN PROYEK DAN

KELALAIAN
5.1.1 Rencanakan upaya pengembangan perangkat Ya: Rencanakan Build 1 in Ya: Rencanakan Build 2 in Ya: Rencanakan Build 3 in Ya: Rencanakan Build 4 in
lunak rinci; Membangun 2-4 rinci; Membangun 3-4 rinci; Bangun 4 secara umum detail
secara umum secara umum
5.1.2 Rencanakan pengujian kualifikasi Tidak: Tidak ada pengujian Tidak: Tidak ada pengujian Ya: Rencanakan pengujian qual Ya: Perbarui untuk pengujian
CSCI qual CSCI di build ini qual CSCI di build ini CSCI di build ini qual CSCI di build ini
5.1.3 Merencanakan pengujian kualifikasi Tidak: Tidak ada pengujian Tidak: Tidak ada pengujian Ya: Rencanakan pengujian Ya: Pembaruan untuk pengujian
sistem kualitas sistem dalam versi ini kualitas sistem dalam versi ini kualitas sistem dalam build ini kualitas sistem di build ini
5.1.4 Rencanakan untuk menginstal perangkat lunak Tidak: Izinkan pengguna Tidak: Izinkan pengguna Ya: Rencanakan untuk memasang Ya: Perbarui sesuai kebutuhan
di situs pengguna menginstal sendiri menginstal sendiri di situs pengguna untuk pemasangan Bld 4
5.1.5 Rencanakan untuk mengalihkan perangkat Ya: Hanya perencanaan yang Ya: Perbarui rencana awal Ya: Perbarui rencana awal Ya: Selesaikan perencanaan
lunak ke agen pendukung sangat awal transisi
5.1.6 Ikuti rencana; melakukan Ya: Untuk rencana yang Ya: Untuk rencana yang Ya: Untuk rencana yang Ya: Untuk rencana yang
tinjauan manajemen berlaku berlaku berlaku berlaku
5.2 MENYUSUN PERANGKAT LUNAK

KEMBANGKAN LINGKUNGAN
5.2.1 Menetapkan lingkungan rekayasa perangkat Ya: Sesuai kebutuhan untuk Ya: Perbarui sesuai kebutuhan Ya: Perbarui sesuai kebutuhan Ya: Perbarui sesuai kebutuhan
lunak Membangun 1 untuk Build 2 untuk Build 3 untuk Build 4
5.2.2 Menetapkan tes perangkat lunak Ya: Sesuai kebutuhan untuk Ya: Sesuai kebutuhan untuk Ya: Atur sepenuhnya untuk Ya: Perbarui sesuai kebutuhan
lingkungan Membangun 1 pengujian Membangun 2 pengujian Membangun 3 pengujian untuk pengujian kualifikasi Build
kualifikasi 4
GAMBAR 13. Contoh perencanaan bangunan untuk proyek MIL-STD-498.

Machine Translated
(versi PDF) Lampiran G halaman 55
A. Keputusan yang berbeda akan berlaku untuk berbagai jenis perangkat lunak pada suatu proyek. Perbedaan ini dapat
ditunjukkan dalam entri satu lembar kerja atau dengan menggunakan lembar kerja yang berbeda untuk berbagai jenis
perangkat lunak pada suatu proyek.
B. Jika pembangunan awal dikhususkan untuk eksperimentasi, mengembangkan perangkat lunak "sekali pakai" untuk sampai
pada konsep sistem atau persyaratan sistem, mungkin tepat untuk melupakan formalitas tertentu, seperti standar
pengkodean, yang akan diterapkan nanti pada perangkat lunak "nyata". .
Jika perangkat lunak awal akan digunakan nanti, formalitas seperti itu mungkin sudah sesuai sejak awal.
Keputusan ini bergantung pada proyek.
G.6.3 Mencatat keputusan penjahitan. Menjahit keputusan yang dibuat oleh pengakuisisi sebelum proyek dimulai ditentukan dalam
Pernyataan Kerja. Penyesuaian yang diusulkan oleh pengembang dapat dikomunikasikan melalui umpan balik pada draf permohonan,
proposal yang ditulis sebagai tanggapan atas permohonan, rencana pengembangan perangkat lunak, tinjauan bersama selama
proyek, atau dengan cara komunikasi lainnya. Penyempurnaan pada keputusan penyesuaian mungkin sedang berlangsung seiring
berjalannya proyek.
Hal-hal yang melibatkan perubahan kontrak harus ditangani sebagaimana mestinya.
G.6.4 Menjadwalkan kegiatan yang dipilih di setiap bangunan. Langkah penting lainnya dalam perencanaan bangunan adalah
menjadwalkan aktivitas di setiap bangunan. Seperti penjahitan, pihak pengakuisisi dapat menetapkan tonggak umum dan meminta
pengembang memberikan spesifikasi atau jadwal tertentu. Pedoman berikut berlaku:
A. Kesalahan umum adalah memperlakukan semua CSCI seolah-olah mereka harus dikembangkan dalam "langkah kunci",
mencapai tonggak penting pada saat yang bersamaan. Mengizinkan CSCI berada pada jadwal yang berbeda dapat
menghasilkan pengembangan yang lebih optimal.
B. Kesalahan serupa adalah memperlakukan unit perangkat lunak seolah-olah harus dikembangkan dalam "langkah kunci",
semuanya dirancang pada tanggal tertentu, diimplementasikan pada tanggal tertentu, dll. Fleksibilitas dalam penjadwalan
unit perangkat lunak juga bisa efektif.
C. Aktivitas dalam MIL-STD-498 tidak perlu dilakukan secara berurutan. Beberapa mungkin terjadi pada satu waktu, dan aktivitas
dapat dilakukan terus menerus atau sebentar-sebentar di seluruh build atau lebih dari beberapa build. Kegiatan di setiap
bangunan harus ditata dengan cara yang paling sesuai dengan pekerjaan yang akan dilakukan.
Machine Translated
(versi PDF) Lampiran H halaman 56
LAMPIRAN H
PANDUAN PEMESANAN PENGIRIMAN
Ruang Lingkup H.1. Apendiks ini memberikan panduan kepada pengakuisisi tentang hasil kerja yang diperlukan
dalam proyek pengembangan perangkat lunak. Apendiks ini bukan merupakan bagian wajib dari standar ini.
Informasi yang diberikan dimaksudkan untuk panduan saja.
H.2 Dokumen yang berlaku. Bagian ini tidak berlaku untuk lampiran ini.
H.3 Memesan kiriman. MIL-STD-498 telah disusun untuk membedakan antara kegiatan perencanaan/
perekayasaan yang membentuk proyek pengembangan perangkat lunak dan pembuatan hasil kerja. Tujuan
utama dari kata-kata ini adalah untuk menghilangkan anggapan bahwa pengakuisisi harus memesan penyerahan
tertentu agar perencanaan atau pekerjaan rekayasa dilakukan. Di bawah MIL STD-498, pekerjaan perencanaan
dan perekayasaan dilakukan terlepas dari pengiriman mana yang dipesan, kecuali aktivitas tertentu disesuaikan
di luar standar. Selain itu, tinjauan teknis bersama telah disertakan untuk meninjau hasil pekerjaan tersebut
dalam bentuk aslinya, tanpa menghasilkan kiriman. Kiriman harus dipesan hanya ketika ada kebutuhan nyata
untuk memiliki informasi perencanaan atau rekayasa diubah menjadi kiriman, menyadari bahwa transformasi ini
membutuhkan waktu dan upaya yang seharusnya dihabiskan untuk upaya rekayasa.
Blok 3 dari setiap DID memberikan informasi yang membantu dalam memutuskan apakah pengiriman yang
sesuai harus dipesan.
H.4 Penjadwalan kiriman. MIL-STD-498 telah disusun untuk mendukung berbagai strategi program dan untuk
memberikan fleksibilitas pengembang dalam menyusun proses pengembangan perangkat lunak yang paling
sesuai dengan pekerjaan yang akan dilakukan. Semua fleksibilitas ini dapat dibatalkan dengan penjadwalan
pengiriman yang kaku pada CDRL. Jika CDRL menjabarkan urutan pengiriman "air terjun" yang ketat, hanya
sedikit ruang yang tersisa untuk mengusulkan proses pengembangan yang inovatif. Jika CDRL memaksa
semua CSCI untuk saling mengunci satu sama lain, sedikit ruang yang tersisa untuk mengembangkan CSCI
dalam urutan optimal. Sedapat mungkin, CDRL harus menghindari penentuan awal tersebut, membiarkan pintu
terbuka untuk pengiriman tambahan produk perangkat lunak, pengembangan CSCI yang terhuyung-huyung,
dan variasi lain untuk mengoptimalkan upaya pengembangan perangkat lunak. Rencana pengembangan
perangkat lunak pengembang akan menyusun jadwal yang diusulkan yang memenuhi batasan dalam CDRL.
Kesepakatan akhir tentang penjadwalan dapat dilakukan pada saat itu.
H.5 Format kiriman. Kiriman tradisional berbentuk dokumen kertas persis mengikuti format DID. Meskipun
formulir ini bekerja dengan baik untuk beberapa kiriman, ini bukan satu-satunya formulir, dan alternatif harus
dipertimbangkan. Salah satu variasi dari dokumen kertas adalah file pengolah kata yang berisi dokumen
tersebut. Format ini menghemat kertas, tetapi tetap mengharuskan pengembang untuk memformat informasi
seperti yang diminta oleh DID. Variasi lain menentukan bahwa kertas atau dokumen pengolah kata harus
menyertakan semua konten DID tetapi mungkin dalam format pengembang.
Namun variasi lain memungkinkan pengiriman untuk mengambil bentuk yang sama sekali bukan dokumen
tradisional, seperti data dalam alat rekayasa perangkat lunak berbantuan komputer (CASE). Variasi dalam
format yang diperlukan ini dapat ditentukan pada CDRL, meminimalkan waktu yang dihabiskan untuk mengubah
produk kerja aktual menjadi hasil kerja.
H.6 Menyesuaikan DID. Menyesuaikan DID terdiri dari menghapus persyaratan untuk informasi yang tidak
dibutuhkan dan membuat perubahan lain yang tidak menambah beban kerja yang diperlukan, seperti
menggabungkan dua dokumen dalam satu sampul. Penyesuaian DID untuk kiriman ditentukan di Blok 16 dari
CDRL.
Machine Translated
(versi PDF) Lampiran I halaman 57
LAMPIRAN I
PANDUAN KONVERSI DARI

DOD-STD-2167A DAN DOD-STD-7935A
I.1 Lingkup. Lampiran ini memberikan panduan konversi dari DOD-STD-2167A dan DOD-STD 7935A, dua
standar yang digabungkan menjadi MIL-STD-498. Ini memetakan istilah kunci dari masing-masing standar ini ke
pasangannya di MIL-STD-498 dan menunjukkan hubungan DID yang diperlukan oleh standar ini dengan
pasangannya di MIL-STD-498. Apendiks ini bukan merupakan bagian wajib dari standar. Informasi yang diberikan
dimaksudkan untuk panduan saja.
I.2 Dokumen yang berlaku. Apendiks ini mengacu pada standar berikut, yang keduanya digantikan oleh standar
ini:
A. DOD-STD-2167A, Pengembangan Perangkat Lunak Sistem Pertahanan, 29 Februari 1988
B. DOD-STD-7935A, Standar Dokumentasi Sistem Informasi Otomatis DoD, 31 Oktober 1988
I.3 Pemetaan istilah kunci. Gambar 14 mengidentifikasi istilah yang dipilih dalam MIL-STD-498 dan menyatakan
pasangannya dalam DOD-STD-2167A dan DOD-STD-7935A.
Istilah MIL-STD-498 Mitra DOD-STD-2167A Mitra DOD-STD-7935A
Pengakuisisi Agen kontraktor Grup Pengguna (tidak ada perbedaan antara

peran pengakuisisi dan pengguna)
Pengembang Kontraktor (mencakup instansi Pemerintah Kelompok Pengembangan (meliputi

atau kontraktor) Instansi atau kontraktor pemerintah)
Penerapan Pengkodean Pengembangan, produksi, pengkodean,

pembuatan basis data
Instalasi (di situs pengguna) Penyebaran Deployment, implementasi, instalasi
Satuan perangkat lunak Komponen perangkat lunak komputer dan Satuan perangkat lunak
unit perangkat lunak komputer
Perangkat lunak komputer Perangkat lunak komputer Program, program komputer

Item Konfigurasi (CSCI) Item Konfigurasi (CSCI)
Dukungan perangkat lunak Dukungan perangkat lunak Pemeliharaan perangkat lunak
Sistem perangkat Sistem (Tidak ada istilah khusus yang Sistem Informasi Otomatis, sistem
lunak (terdiri dari perangkat lunak digunakan untuk membedakan
dan mungkin komputer) jenis sistem ini)
Sistem perangkat keras-perangkat Sistem (Tidak ada istilah khusus yang (Jenis sistem ini tidak dicakup oleh DOD-
lunak (di mana perangkat kerasnya digunakan untuk membedakan STD-7935A)
mungkin selain komputer) jenis sistem ini)
GAMBAR 14. Pemetaan istilah kunci.

Machine Translated
(versi PDF) Lampiran I halaman 58
I.4 Pemetaan DID. Gambar 15 mengidentifikasi DID DOD-STD-7935A dan memberitahukan DID MIL STD-498 mana yang berisi
kontennya. Gambar 16 memberikan pemetaan serupa dari DID DOD-STD 2167A ke DID MIL-STD-498. Gambar 17 memberikan
pemetaan terbalik, mengidentifikasi MIL-STD-498 DID dan memberi tahu DOD-STD-2167A dan/atau DOD-STD-7935A DID
mana yang membentuk dasar untuk masing-masing.
DOD-STD-7935A DID Dimasukkan ke dalam DID MIL-STD-498 ini
Deskripsi Fungsional (FD) Konsep sistem menjadi Deskripsi Konsep Operasional

(OCD)
Persyaratan sistem ke dalam Sistem/Subsistem
Spesifikasi (SSS)
Perencanaan pengembangan menjadi Pengembangan Perangkat Lunak
Rencana (SDP)
Sistem/Subsistem Persyaratan sistem ke dalam Sistem/Subsistem

Spesifikasi (SS) Spesifikasi (SSS)
Perancangan sistem menjadi Desain Sistem/Subsistem
Deskripsi (SSDD)
Spesifikasi Unit Perangkat Lunak Informasi kebutuhan ke dalam Persyaratan Perangkat Lunak
(KITA) Spesifikasi (SRS) dan Persyaratan Antarmuka
Spesifikasi (IRS)
Informasi desain ke dalam Deskripsi Desain Perangkat Lunak
(SDD) dan Deskripsi Desain Antarmuka (IDD)
Spesifikasi Basis Data (DS) Deskripsi Desain Basis Data (DBDD)
Rencana Uji (PT) Perencanaan tingkat tinggi ke dalam Software Test Plan (STP)
Perencanaan terperinci ke dalam Software Test Description (STD)
Laporan Analisis Uji (RT) Laporan Uji Perangkat Lunak (STR)
Panduan Pengguna (UM) Panduan Input/Output Perangkat Lunak (SIOM)
Panduan Pengguna Akhir (EM) Panduan Pengguna Perangkat Lunak (SUM)
Manual Pengoperasian Komputer Manual Operator Pusat Perangkat Lunak (SCOM)

(OM)
Manual Pemeliharaan (MM) Merencanakan informasi ke dalam Rencana Transisi Perangkat Lunak
(STrP)
Deskripsi perangkat lunak menjadi Deskripsi Desain Perangkat Lunak
(SDD)
Prosedur pemeliharaan ke dalam Produk Perangkat Lunak
Spesifikasi (SPS)
Prosedur Implementasi (IP) Rencana Instalasi Perangkat Lunak (SIP)
GAMBAR 15. Pemetaan DOD-STD-7935A DID ke MIL-STD-498 DID.

Machine Translated
(versi PDF) Lampiran I Halaman 59
DOD-STD-2167A DID Dimasukkan ke dalam DID MIL-STD-498 ini
Rencana Pengembangan Perangkat Lunak (SDP) Rencana Pengembangan Perangkat Lunak (SDP)
Spesifikasi Sistem/Segmen (SSS) Spesifikasi Sistem/Subsistem (SSS)
Dokumen Desain Sistem/Segmen Konsep Operasional menjadi Operasional

(SSDD) Deskripsi Konsep (OCD)
Perancangan sistem ke dalam Sistem/Subsistem
Deskripsi Desain (SSDD)
Spesifikasi Kebutuhan Perangkat Lunak (SRS) Spesifikasi Kebutuhan Perangkat Lunak (SRS)
Spesifikasi Kebutuhan Antarmuka (IRS) Spesifikasi Kebutuhan Antarmuka (IRS)
Dokumen Desain Perangkat Lunak (SDD) Deskripsi Desain Perangkat Lunak (SDD)
Dokumen Desain Antarmuka (IDD) Deskripsi Desain Antarmuka (IDD)
Rencana Uji Perangkat Lunak (STP) Rencana Uji Perangkat Lunak (STP)
Deskripsi Uji Perangkat Lunak (STD) Deskripsi Uji Perangkat Lunak (STD)
Laporan Uji Perangkat Lunak (STR) Laporan Uji Perangkat Lunak (STR)
Manual Operator Sistem Komputer Panduan Pengoperasian Komputer (COM)

(OMSK)
Panduan Pengguna Perangkat Lunak (SUM) Panduan Pengguna Perangkat Lunak (SUM)
Dukungan Sumber Daya Komputer Terintegrasi Merencanakan informasi ke dalam Perangkat Lunak
Dokumen (CRISD) Rencana Transisi (STrP)
Modifikasi prosedur menjadi Software
Spesifikasi Produk (SPS)
Spesifikasi Produk Perangkat Lunak (SPS) Spesifikasi Produk Perangkat Lunak (SPS)
Manual Pemrogram Perangkat Lunak (SPM) Manual Pemrograman Komputer (CPM)
Manual Dukungan Firmware (FSM) Manual Dukungan Firmware (FSM)
Dokumen Deskripsi Versi (VDD) Deskripsi Versi Perangkat Lunak (SVD)
GAMBAR 16. Pemetaan DOD-STD-2167A DID ke MIL-STD-498 DID.

MIL-STD-498 (versi
Machine Translated byPDF)
Google Lampiran I halaman 60
MIL-STD-498 DID Sumber DID DOD-STD-2167A dan DOD-STD-7935A
Rencana Pengembangan Perangkat Lunak (SDP) Rencana Pengembangan Perangkat Lunak (SDP) 2167A
7935A Deskripsi Fungsional (FD), bagian 7
Paket Instalasi Perangkat Lunak (SIP) Prosedur Implementasi (IP) 7935A
Rencana Transisi Perangkat Lunak (STrP) 2167A Comp Res Integ Sup Doc (CRISD) - info perencanaan
7935A Maintenance Manual (MM) - info perencanaan
Deskripsi Konsep Operasional (OCD) 2167A System/Segment Design Doc (SSDD), bagian 3
7935A Deskripsi Fungsional (FD), bagian 2
Spesifikasi Sistem/Subsistem (SSS) Spesifikasi Sistem/Segmen (SSS) 2167A

7935A Deskripsi Fungsional (FD) - sistem tidak membutuhkan info
7935A Spesifikasi Sistem/Subsistem (SS) - info yang tidak diperlukan sistem
Deskripsi Desain Sistem/Subsistem (SSDD) Dokumen Desain Sistem/Segmen (SSDD) 2167A

7935A Spesifikasi Sistem/Subsistem - info desain sistem
Spesifikasi Kebutuhan Perangkat Lunak (SRS) Spesifikasi Kebutuhan Perangkat Lunak (SRS) 2167A
Spesifikasi Unit Perangkat Lunak 7935A (AS) - info yang diminta
Spesifikasi Kebutuhan Antarmuka (IRS) Spesifikasi Persyaratan Antarmuka 2167A (IRS)

7935A SW Unit Specification (US) - antarmuka memerlukan info
Deskripsi Desain Perangkat Lunak (SDD) Dokumen Desain Perangkat Lunak (SDD) 2167A
Spesifikasi Unit Perangkat Lunak 7935A (AS) - info desain
7935A Maintenance Manual (MM) - info desain "as built".
Deskripsi Desain Antarmuka (IDD) Dokumen Desain Antarmuka (IDD) 2167A

7935A SW Unit Specification (US) - info desain antarmuka
Deskripsi Desain Basis Data (DBDD) Spesifikasi Basis Data (DS) 7935A
Rencana Uji Perangkat Lunak (STP) Rencana Uji Perangkat Lunak (STP) 2167A
7935A Test Plan (PT) - informasi tingkat tinggi
Deskripsi Uji Perangkat Lunak (STD) Deskripsi Uji Perangkat Lunak 2167A (STD)
Rencana Uji (PT) 7935A - informasi terperinci
Laporan Uji Perangkat Lunak (STR) Laporan Uji Perangkat Lunak (STR) 2167A
Laporan Analisis Uji (RT) 7935A
Spesifikasi Produk Perangkat Lunak (SPS) Spesifikasi Produk Perangkat Lunak (SPS) 2167A
2167A CRSD - prosedur modifikasi
7935A MM - prosedur pemeliharaan
Deskripsi Versi Perangkat Lunak (SVD) Dokumen Deskripsi Versi 2167A (VDD)
Panduan Pengguna Perangkat Lunak (SUM) Panduan Pengguna Perangkat Lunak (SUM) 2167A
7935A Panduan Pengguna Akhir (EM)
Manual Operator Pusat Perangkat Lunak (SCOM) 7935A Panduan Pengoperasian Komputer (OM)
Panduan Input/Output Perangkat Lunak (SIOM) 7935A Panduan Pengguna (UM)
Panduan Pengoperasian Komputer (COM) 2167A Panduan Operator Sistem Komputer (CSOM)
Manual Pemrograman Komputer (CPM) Manual Pemrogram Perangkat Lunak (SPM) 2167A
Manual Dukungan Firmware (FSM) Panduan Dukungan Firmware 2167A (FSM)
GAMBAR 17. Pemetaan MIL-STD-498 DID ke DOD-STD-2167A dan DOD-STD-7935A DID.

Machine Translated
(versi PDF) Indeks Halaman 61
INDEKS
Indeks ini mencakup MIL-STD-498 dan DID-nya. Paragraf dalam DID ditandai dengan akronim DID diikuti
dengan nomor paragraf; keseluruhan DID ditunjukkan dengan akronim DID saja; paragraf dan angka dalam
standar tidak memiliki akronim sebelumnya. Referensi DID yang dimulai dengan "10.1" mengacu pada
paragraf di Blok 10, bagian 10.1 dari DID (Petunjuk Umum). Semua referensi DID lain yang tidak
mencantumkan nomor Blok mengacu pada paragraf di Blok 10, bagian 10.2 dari DID (Persyaratan Konten).
Entri yang dicetak tebal menunjukkan sumber informasi utama tentang suatu topik. Entri "et al" menunjukkan
bahwa suatu topik (seperti "perangkat lunak") muncul terlalu sering untuk mengutip semua referensi.
penerimaan 3.1, 3.30, E.3; IRS 3; RSK 3; SSS 3 kepatuhan terhadap kontrak 5.1.6, 5.16.3 rekayasa
mengakses perangkat lunak berbantuan komputer (KASUS)
akses untuk review pengakuisisi 4.2.7; SDP 4.2.7 Kata Pengantar-3, 1.2.4.4, 3.38, 5.1.1, 6.4, Gambar 2,
akses ke informasi dalam repositori 6.4 acquirer H.5; semua DID: Blok 7; Pusat
(penggunaan istilah "acquirer" di MIL-STD-498) komputer STrP 3.3, pusat perangkat lunak 5.12.3.2, 5.12.3.3;
Prakata-4, 1.2.1, 3.2, Gambar 14 OCD 7.1; SCOM; SDP 5.12.3; SIOM; SIP 4; JUMLAH
strategi akuisisi (lihat strategi program) akronim Lampiran
A alokasi karakteristik perangkat keras komputer CPM 3, 4;
FSM 3.x.1, 3.x.4, 4.1; SRS 3.10.1; SSDD 4.1; SSS
alokasi sumber daya perangkat keras komputer 4.2.5; 3.10.1; STRP 3.2
SDP 4.2.5; SDD 4.1; Alokasi persyaratan pemanfaatan sumber daya perangkat keras komputer 4.2.5, 5.13.4,
SSDD 4.1 Gambar 3, Gambar 6; SDD 4.1, 6; F.3; OCD 8.2; SDD 4.1; SDP 4.2.5; SPS 5.4, 6; SRS 3.10.2;
RSK 5; SSDD 4.1, 5; SSS 5 ANSI/ SSDD 4.1; SSS 3.10.2 Panduan
IEEE/EIA 1498 Prakata-1 aplikasi MIL- Pengoperasian Komputer (COM) 5.12.3.4, 6.2,
STD-498 1.2 persetujuan (oleh Gambar 4, Gambar 6, E.4.9, Gambar 9-12, Gambar 16,
pengakuisisi) 3.3, 5.1.6, 5.7.1, 5.9.2, 5.13.7, 5.18.1, 5.18.2 , Gambar 17;
5.19.7, C.1, D.1 COM; SDP 5.12.3 program
arsitektur 3.4 (lihat juga desain arsitektur CSCI, desain arsitektur komputer 3.10 Computer Programming Manual (CPM) 5.13.6.1, 6.2,
sistem) deskripsi desain "as built" Gambar 6, Gambar 9-12, Gambar 16, Gambar 17; BPS; SDP 5.13.6
5.13.4, 5.13.5, Gambar 2, Item Konfigurasi Perangkat Lunak Komputer (CSCI) 1.2.2, 3.12,
Gambar 3, Gambar 6, D.4.1, Gambar 17; SDP 5.13.4, 3.24, Gambar 14, dkk
5.13.5; SPS Desain arsitektur CSCI 3.4, 5.6.2, Gambar 3,
3, 5.1 pengembang asosiasi 3.5, 5.19.6, Gambar 9-12; SDP 5.19.6 Gambar 6, E.4.6; SDD 4; SDP 5.6.2; SPS 5.1
penjaminan 4.2.4; SDP 4.2.4 (lihat Desain detail CSCI 3.45, 5.6.3, 5.13.4, Gambar 3, Gambar
juga jaminan kualitas perangkat lunak) 6, E.4.6; SDD 5; SDP 5.6.3, 5.13.4; SPS 5.1
jaminan privasi 4.2.4.3; SDP 4.2.4.3 jaminan (lihat juga Deskripsi Desain Database,
keamanan 4.2.4.1; SDP 4.2.4.1 jaminan Deskripsi Desain Antarmuka)
keamanan 4.2.4.2; SDP 4.2.4.2 audit (audit Integrasi dan pengujian CSCI/HWCI 4.1, Gambar 1, 5.10,
konfigurasi) 5.14.4; SDP 5.14.4 Gambar 3, Gambar 6, Gambar 9-12;
Ujian kualifikasi SDP 5.10 CSCI 3.28, 3.43, 4.1, Gambar 1,
desain perilaku 3.6, 5.4.1, 5.6.1, Gambar 2, Gambar 3; 5.1.2, 5.2.2, 5.9, 5.9.5, Gambar 3, Gambar 6, E.4.7, E.4.8,
DBD 3; OCD 3.3, 5.3; SDD 3; SSDD 3 Gambar 9-13; IRS 4; SDP 5.1.2, 5.9; RSK 4; STD;
build 3.7, 5, Fig 1, G.3, G.5, Fig 10, Fig 11 build STP; Persyaratan
planning guidance G.6, Fig 13 catatan STR CSCI 5.5, 5.6.2, 5.7, 5.9, 5.9.3,
tentang interpretasi aktivitas untuk beberapa build Gambar 2-4, Gambar 6, Gambar 9-12; DBDD 3, 4, 6;
5.1-5.16, 5.18 SLI 4; SDD 4.1, 5, 6; SDP 5.5; SPS 5.4, 6; RSK 3; STD
4.xy1, 5; STP 6 (lihat juga
klasifikasi kategori untuk pelaporan masalah 5.17.2, analisis kebutuhan perangkat lunak, Spesifikasi
Gambar 2, C.1, C.3, Gambar 4; SDP Kebutuhan Perangkat Lunak, Spesifikasi
5.17.2 (lihat juga tindakan korektif) Kebutuhan Antarmuka)
kode standar 4.2.2, D.4.7, G.6.2; SDP 4.2.2; Pengkodean Keputusan desain luas CSCI 3.6, 5.6.1, Gambar 3,
SPS 5.3 Gambar 6, E.4.6; SDD 3, 4.1; SDP 5.6.1, 5.13.4;
(lihat implementasi perangkat lunak dan pengujian unit) komersial
off-the-shelf (COTS) (lihat penggunaan kembali, produk Manajemen konfigurasi SPS
perangkat lunak yang dapat 5.1 (lihat manajemen konfigurasi perangkat lunak)
digunakan kembali) kompiler, prosedur kompilasi/bangun 3.38, 5.13.7, Akuisisi berkelanjutan dan dukungan siklus hidup (CALS)
Fi PM P .2 . TP .x.1 TrP .
Machine Translated
kontrak, aplikasi khusus kontrak 1.2.2 penggunaan definisi istilah3

istilah "kontrak" dalam MIL-STD-498 kiriman, produk perangkat lunak kiriman 1.2.1, 1.2.2, 3.16, 5.1.1
Kata Pengantar-4, 1.2.1 Catatan 1-2, 5.2.5, 5.13.7, 5.14.5, 5.15.1; semua DID: Blok
referensi ke kontrak Kata Pengantar-4, Kata Pengantar-5, 7
1.2.1, 1.2.2, 1.2.4.1, 3.1, 3.3, 3.16, 3.18, 3.26, 3.30, panduan memesan kiriman 6.5, Lampiran H
3.39, 4.1, 4.2.3.1, 4.2.3.2, 4.2. 4.4, 4.2.5, 4.2.7, 5.1, design 3.17 (lihat juga deskripsi desain "as built", desain
5.1.1, 5.1.4-5.1.6, 5.2.3, 5.2.4, 5.4.1, 5.7.1, 5.12.4, perilaku, desain arsitektur CSCI, desain detail CSCI,
5.13.7, 5.14. 1-5.14.5, 5.15.2, 5.16.1-5.16.3, keputusan desain seluruh CSCI, Deskripsi Desain Database,
5.17.1, 5.17.2, 5.19.3-5.19.6, 6.2, 6.4, 6.5, B.3, G.6, G. Deskripsi Desain Antarmuka, desain perangkat lunak,
6.3; semua DID: Blok 7 (7.1), 10.1.c, 10.1.h; SDP 4.1, Deskripsi Desain Perangkat Lunak, desain arsitektur
4.2.1, 4.2.2, 4.2.3.1, 4.2.3.2, 4.2.4-4.2.7, 5.1-5.19; sistem, Sistem/ Desain Subsistem Deskripsi,
RSK 3.11; SS 3.16; STRP 7 keputusan desain seluruh sistem) standar
desain 4.2.2, D.4.7; DBDD 3, 4, 5;
Daftar Persyaratan Data Kontrak (CDRL) 1.2.1, 5.1.1, 6.3, 6.4, SLI 3; SDD 3, 4, 5; SDP 4.2.2; SPS 5.3; SSDD 3, 4 persyaratan
6.5, Gambar 6, D.4.9, H.4, H.5, H.6; semua terperinci dari MIL-STD-498 5 develop (interpretasi
DID: Blok 7, 10.1.c agen "mengembangkan" dalam MIL-STD-498) 1.2.4.3
kontraktor (lihat pengakuisisi) kontraktor pengembang (penggunaan istilah "pengembang" dalam MIL-
(lihat pengembang) panduan STD-498)
konversi dari DOD-STD-2167A dan DOD-STD-7935A
Lampiran I tindakan korektif , sistem Kata Pengantar-4, 1.2.1, 3.18,
tindakan korektif 4.1, Gambar 1, 5.17, Gambar 3, Gambar 14 dokumentasi Kata Pengantar-3,
Lampiran C, Gambar 9-12; SDP 5.17 (lihat juga pelaporan 3.19, 5.1.1; semua DID: Blok 7,
masalah) 10.1.a, 10.1.i (juga lihat Deskripsi Item Data)
biaya DOD-STD-1703 Kata Pengantar-3
manfaat biaya, efektivitas biaya Kata Pengantar-9, DOD-STD-2167A Kata Pengantar-3
4.2.3.2, 6.5, B.3 pemetaan antara DID MIL-STD-498 dan
pelaporan biaya/jadwal, risiko biaya/jadwal 5.18.1, DOD-STD-2167A DIDS I.4, Gambar 16, Gambar
5.18.2, 5.19.1, 6.6, B.3, Gambar 5 17 pemetaan istilah kunci MIL-STD-498 ke
persyaratan kritis 4.2.4, Gambar 5; DBD 3; IRS 3.y; MIL-STD-2167A I.3, Gambar 14
SDD 3; SDP 4.2.4; RSK 3.18; SSDD 3; SSS 3.18 ulasan DOD-STD-7935A Kata Pengantar-3
persyaratan kritis E.4.11 jaminan privasi pemetaan antara MIL-STD- 498 DID dan
4.2.4.3, 5.19.3, B.3, E.4.11 jaminan keamanan 4.2.4.1, DOD-STD-7935A DIDs I.4, Gambar 15, Gambar
Gambar 2, B.3, Gambar 5, E.4.11 jaminan keamanan 17 pemetaan istilah kunci MIL-STD-498 ke
4.2.4.2, 5.19.3, Gambar 2, B.3, Gambar 5, E.4.11 MIL-STD-7935A I.3, Gambar 14
tes kualifikasi 5.9.4, 5.11.4, Gambar 14, Gambar 6, D.4.2;
SDP 5.9.4, 5.11.4
elemen data/himpunan elemen data semua DID: 10.1.h; DBDD 3,
4.x, 5.x; SLI 3.x; IRS 3.x; SDD 3, 4.3.x, 5.x; SIOM 5.1; SRS pelaporan kesalahan (lihat pelaporan masalah)
3.2.x, 3.3.x, 3.4, 3.5; SSDD 3, 4.3.x; SSS 3.2.x, evaluasi 3.20 (juga lihat Verifikasi dan Validasi Independen, produk
3.3.x, 3.4, 3.5 hak data 4.2.3.1, B.3; STP 3.x.4; perangkat lunak yang dapat digunakan kembali, evaluasi
STrP 3.2, 3.3, 3.4 (lihat juga lisensi, lisensi) standardisasi data, produk perangkat lunak, jaminan kualitas perangkat
deskripsi data standar semua lunak, kriteria evaluasi uji kasus)
DID: 10.1.h Strategi program evolusi Kata Pengantar-3, G.3, Gambar 7, Gambar 8,
Gambar 11
Data Item Description (DID) Kata Pengantar-9, 1.2.3, 5.1.1, software yang dapat dieksekusi Gambar 6
5.13.6, 6.2, 6.3, 6.4, 6.5, D.4.4, G.5, Lampiran H, I.4, prosedur kompilasi/bangun Gambar 6; SPS 5.2, 5.3 pengiriman perangkat lunak
Gambar 15-17 yang dapat dijalankan SPS 3.1 menggabungkan perangkat lunak
basis data 3.14, 3.15, 3.32, 3.45, 5.7.1, 5.12.1, yang dapat digunakan kembali ke dalam perangkat lunak yang dapat dijalankan
5.13.1, 5.13.2, 6.4, Gambar 4; SCOM 3.2, 3.3, 5.5.x.3; software Gambar 3
SIOM 3.2, 3.4, 5.1; SIP 4.x.5; SPS 3.1, 3.2; SRS menginstal software yang dapat dieksekusi 5.12.4
3.5, 3.10.3, 3.12; SSS 3.5, 3.10.3; STD 4.xy6; menyiapkan software yang dapat dieksekusi untuk transisi
STP 3.x.1; SUM 3.2, 3.3 desain basis data, software 5.13.1; SDP 5.13.1 menyiapkan
Deskripsi Desain Basis Data (DBDD) perangkat lunak yang dapat dieksekusi untuk penggunaan perangkat
5.4.1, 5.6.1, 5.6.3, 6.2, Gambar 9-12, Gambar 15, lunak 5.12.1; SDP 5.12.1
Gambar 17; DBDD; SDD 3, 4.1, 5, 5.x, 6; SPS 5.1, meregenerasi perangkat lunak yang dapat dieksekusi 5.13.2,
5.3; SSDD 3, 4.1 5.13.7; SPS 3.2
define (interpretasi "define" dalam MIL-STD-498) 1.2.4.3 deskripsi versi (lihat
Deskripsi Versi Perangkat Lunak)
definisi kriteria evaluasi produk perangkat lunak D.4
Machine Translated
firmware 1.2.2, 3.21, 3.38, 3.43; SPS 5.2; STP 3.x.2 Firmware Support keputusan kunci (mencatat alasan untuk keputusan kunci) 3.34,
Manual (FSM) 5.13.6.2, 6.2, Gambar 6, Gambar 9-12, Gambar 16, 4.2.6, 5.2.4; semua DID: bagian Catatan; SDP 4.2.6
Gambar 17; FSM; SDP 5.13.6 forward engineering 3.29,
Gambar 12 daftar kata kunci dalam istilah kunci MIL-STD-498
6.8 (pemetaan istilah kunci MIL-STD-498 ke
persyaratan umum MIL-STD-498 4 Instansi internal DOD-STD-2167A, DOD-STD-7935A) I.3, Gambar 14
pemerintah (sebagai pengembang)
Kata Pengantar-4, 1.2.1 lisensi, lisensi B.3, Gambar 3; STP 3.x.4;
Strategi program Grand Design G.3, Gambar 7, Gambar 8, Gambar 9 STrP 3.2, 3.3, 3.4 (lihat juga hak data) siklus hidup
Kata Pengantar-4, Gambar 2, Gambar 5, G.2; SDP 3 logistik
Item Konfigurasi Perangkat Keras (HWCI) 3.22, 3.24, 5.10; SRS 3.15; SSS 3.15 (lihat juga Continuous acquisition and life-cycle
SDP 5.10; SRS 3.10.1; SSDD 4, 4.1; SSS 3.10.1 support (CALS))
sistem perangkat keras-perangkat lunak 1.2.4.1, 1.2.4.2, Gambar 14;
SSDD 3; SSS 3.9, 3.10, 3.12 pemeliharaan Kata Pengantar-4, 1.2.1, 1.2.4.3, 3.33, 3.41,
Gambar 14 (lihat juga dukungan perangkat
implementasi (lihat lunak) indikator manajemen
implementasi perangkat lunak dan pengujian unit) (lihat indikator manajemen perangkat lunak)
Strategi program tambahan Kata Pengantar-3, G.3, Gambar 7, Gambar tinjauan manajemen 5.1.6; Metrik SDP 5.1.6 (lihat
8, Gambar 10 indikator manajemen perangkat lunak)
evaluasi
produk perangkat lunak dalam proses dan akhir 5.15.1; SDP produk perangkat lunak yang tidak dapat dikirimkan 1.2.2, 3.26, 5.2.5;
5.15.1 tinjauan bersama SDP 5.2.5
produk perangkat lunak dalam proses dan akhir 5.18.1 Catatan 6; semua DID: bagian Catatan
kemandirian dalam
evaluasi produk konsep operasional, Operational Concept Description (OCD) 5.3.2,
perangkat lunak 5.15.3; SDP 5.15.3 kemandirian dalam 6.2, Gambar 3, Gambar 4, Gambar 6, E.4.2, Gambar
jaminan kualitas perangkat 9-12, Gambar 15-17; OCD; SDP 5.3.2
lunak 5.16.3; SDP 5.16.3 tinjauan konsep operasional E.4.2
independensi dalam uji kualifikasi 5.9.1, 5.11.1; pengemasan, persyaratan pengemasan 5.14.5; SDP 5.14.5; SPS 3.3; RSK
SDP 5.9.1, 5.11.1 3.17; SS 3.17; STRP 7
Verifikasi dan Validasi Independen (IV&V) 3.23, 5.19.5, Gambar 9-12; berpartisipasi (interpretasi "berpartisipasi" dalam MIL-
Instalasi SDP 5.19.5 STD-498) 1.2.4.2 partisipasi
dalam aktivitas tingkat sistem 5.1.3, 5.3, 5.4,
instalasi di situs dukungan 5.13.7; Instalasi STrP 7 di lokasi 5.10, 5.11, 5.13.5, D.3; Perencanaan SDP 5.3,
pengguna 5.12.4, Gambar 6, E.4.9, Gambar 14; SCOM 4; SDP 5.4, 5.10, 5.11 (lihat
5.12.4; MENYESAP; SS 3.16; JUMLAH 4.1.3; perencanaan pembangunan, perencanaan proyek,
Perencanaan instalasi perencanaan pengembangan perangkat
perangkat lunak SVD 3.6 5.1.4, 6.2, Gambar 6, lunak, perencanaan instalasi perangkat
E.4.1, Gambar 9-13, Gambar 15, Gambar 17; SDP 5.1.4; lunak, perencanaan transisi perangkat lunak,
Proses pengembangan perangkat lunak integral SIP perencanaan pengujian) klasifikasi prioritas untuk pelaporan masalah 5.17.2,
integrasi 4.1 (lihat integrasi dan pengujian CSCI/HWCI, integrasi dan C.1, C.4, Gambar 5, F.3 (lihat juga tindakan korektif)
pengujian unit) antarmuka 3.24 privasi 4.2.4.3, 5.19.3, B.3, E.4.11, Gambar 9-12;
desain antarmuka, semua DID 1.3; COM 3.2.4; DBDD 3, 4.x, 5.x; FSM 3.x.5;
Deskripsi Desain Antarmuka (IDD) SLI 3.x; IRS 3.x, 3.y; OCD 3.3, 5.3; SCOM 3.2, 3.4, 3.6, 5.5.x;
5.4.1, 5.4.2, 5.6.1, 5.6.2, 5.6.3, 6.2, Gambar 6, Gambar SDD 3, 4.3.x; SDP 3, 4.2.4.3, 5.19.3; SIOM 3.2, 3.4, 3.6, 4.2.1,
9-12, Gambar 15-17; DBDD 3, 5.x; SLI; SDD 3, 4.3, 4.3.1, 4.3.2; SIP 3.7, SRS 3.3.x, 3.8, 3.18; SSDD 3, 4.3.x; SSS
5, 5.x, 6; SPS 5.1; SSDD 3, 4.3, 5 3.3.x, 3.8, 3.18; STD 3, 4; STP 3.x.1, 3.x.2, 3.x.3, 4.2.xy;
persyaratan antarmuka, Persyaratan Antarmuka STRP 3.1-3.4; JUMLAH 3.2, 3.4, 3.6, 4.1.2; SVD 3.1, 3.2, 3.6 (lihat
Spesifikasi (IRS) 5.3.3, 5.5, 5.9, 5.11, 6.2, Gambar 6, juga jaminan)
Gambar 9-12, Gambar 15-17; IRS; SRS 3.3, 3.4; SSS 3.3,
3.4; STD 5; STP 6 ISO/IEC DIS 12207 pelaporan masalah, laporan masalah/perubahan 5.3.1, 5.14.3,
Kata Pengantar-6 5.15.2, 5.16.2, 5.17.1, 5.17.2, Gambar 2, Lampiran C,
Gambar 4, Gambar 5, F.3; SDP 5.17.1; STR 3.1, 4.x.2.y;
tinjauan teknis dan manajemen bersama 3.25, 4.1, Gambar 1 5.18, SVD 3.3, 3.7 perbaikan proses 5.19.7,
Gambar 2-3, Gambar 9-12, G.6.3, H.3; Ulasan manajemen Gambar 9-12; Program SDP 5.19.7 (program komputer) 3.10
bersama kandidat SDP 5.18 Lampiran E
Machine Translated
strategi program Lampiran G, Gambar 7, Gambar 8, keamanan 4.2.4.1, Gambar 2, B.3, Gambar 5, E.4.11; COM 3;
Gambar 9-11, H.4; bahasa DBDD 3, 5.x; FSM 3.x.6; SLI 3.x; IRS 3.x, 3.y; OCD 3.3, 5.3;
pemrograman SDP 3 3.29, 4.2.2, 5.7.1, Gambar 2; SCOM 4, 5; SDD 3, 4.3.x; SDP 4.2.4.1; SIOM 4, 6;
DBDD 5.x; SDD 5.x; SDP 4.2.2; RSK 3.12; SS 3.12 SIP 4.x.5, 5.x.2; SRS 3.3.x, 3.7, 3.18; SSDD 3,
4.3.x; SSS 3.3.x, 3.7, 3.18; STD 3, 4; STP
(lihat juga Manual Pemrograman Komputer) 4.2.xy; STRP 3.1; JUMLAH 4, 5; SVD 3.6 (lihat juga
perencanaan proyek 4.1, Gambar 1, 5.1, Gambar 3, Gambar 6, jaminan) jadwal 3.34; SDP 3, 6, 7.2;
Gambar 9-13; SDP 1.4, 5.1; SIP 1.4; STP 1.4; STrP SIP 3.1, 4.x.1, 5.x.1;
1.4 (lihat juga perencanaan pengembangan perangkat lunak)
pengidentifikasi unik proyek 5.14.1; STP 5; STrP 5, 7
DBDD 3, 4, 4.x, 5, 5.x; SLI 3, 3.1, 3.x; IRS 3, pelaporan biaya/jadwal, risiko biaya/jadwal 5.18.1,
3.1, 3.x; SDD 3, 4, 4.1, 4.3.1, 4.3.x, 5, 5.x; SRS 3, 3.3.1, 3.3.x; 5.18.2, 5.19.1, 6.6, B.3, Gambar 5
SSDD 3, 4, 4.1, 4.3.1, 4.3.x; SSS 3, 3.3.1, 3.3.x; STD 3.x, panduan aktivitas penjadwalan G.6.4 panduan
4.x, 4.xy; STP 4.2.x, 4.2.xy; STR 4.x, 4.x.2.y, penjadwalan kiriman H.4 lingkup keamanan MIL-
4.x.3.y prototipe 5.3.1, G.6.1, Gambar 11, Gambar 13 STD-498 1 4.2.4.2, 5.19.3,
Gambar 2, B.3, Gambar 5, E.4.11, Gambar 9-12; semua DID
10.1.c, 1.3; COM 3.2.4; DBDD 3, 4.x, 5.x; FSM 3.x.5;
metode kualifikasi IRS 3, 4; SPS 4; RSK 3, 4; SSS 3, 4; Uji SLI 3.x; IRS 3.x, 3.y; OCD 3.3, 5.3; SCOM 3.3, 3.4.1, 3.4.2,
kualifikasi STP 4.2.xy 3.28, 3.7, 5.5.x; SDD 3, 4.3.x; SDP 3, 4.2.4.2, 5.19.3, 7.2; SIOM
3.43, 5.2.2, 5.4.1, 5.9, 5.11 3.2, 3.4, 3.6, 4.2.1, 4.3.1, 4.3.2; SIP 3.7, 4.x.2; SRS 3.3.x,
(lihat juga pengujian kualifikasi CSCI, 3.8, 3.18; SSDD 3, 4.3.x; SSS 3.3.x, 3.8, 3.18; STD 3, 4;
pengujian kualifikasi sistem) STP 3.x.1, 3.x.2, 3.x.3, 4.2.xy; STRP 3.1-3.5; JUMLAH
jaminan kualitas (lihat jaminan kualitas perangkat lunak) faktor 3.2, 3.4, 3.6, 4.1.2; SVD 3.1, 3.2, 3.6 (lihat juga jaminan)
kualitas (keandalan, pemeliharaan, dll.)
B.3; DBD 3; OCD 3.3, 5.3; SDD 3; RSK 3.11; SSDD 3; SS
3.11 software 3.32, et al
Software Center Operator Manual (SCOM) 5.12.3.3, 6.2, Gambar
rasional (rekaman rasional) 3.34, 4.2.6, 5.2.4; semua DID: 6, Gambar 9-12, Gambar 15, Gambar 17; SCOM
bagian Catatan; Catatan SDP 4.2.6 (lihat juga Software Input/Output Manual, Software
(interpretasi "catatan" dalam MIL-STD-498) 1.2.4.4 User Manual) manajemen
konfigurasi perangkat lunak 3.12, 4.1, Gambar 1, 5.14, Gambar 2,
redocumentation 3.29, Gambar 12 Gambar 3, Gambar 9-12; SDP 5.14 mengaudit
reengineering Prakata-4, 1.2.1, 1.2.4.3, 3.29, 3.33, G.5, Gambar konfigurasi 5.14.4; Kontrol konfigurasi SDP 5.14.4,
12; SDD 4.1; Persyaratan SSDD 4.1 kontrol penulis, tingkat proyek
(definisi persyaratan) 3.30 analisis persyaratan (lihat pengendalian, pengendalian pengakuisisi 5.14.1, 5.14.2,
analisis persyaratan perangkat lunak, analisis persyaratan sistem, 5.14.3, 5.15.2, 5.16.2, 5.17.1, 5.17.2, F.3; SDP 5.14.2
ketertelusuran) pemanfaatan sumber daya identifikasi konfigurasi 5.14.1; SDP 5.14.1 status konfigurasi
akuntansi 5.14.3; SDP 5.14.3 pengemasan, penyimpanan,
(lihat pemanfaatan sumber daya perangkat keras komputer) penanganan, dan pengiriman (dari
restrukturisasi 3.29, Gambar 12 produk perangkat lunak) 5.14.5; Desain perangkat
retargeting 3.29, Gambar 12 lunak SDP 5.14.5, Deskripsi Desain Perangkat Lunak (SDD)
reuse, produk perangkat lunak yang dapat digunakan kembali Kata 3.17, 3.39, 3.45, 4.1, 4.2.6, Gambar 1, 5.2.4, 5.6, 5.7 , 5.9.1,
Pengantar-4, 1.2.1, 1.2.4.3, 3.31, 3.33, 4.2.3; 5.11.1, 6.2, Gambar 2, Gambar 4, Gambar 6, F.3, Gambar
SDP 4.2.3 mengembangkan produk perangkat lunak yang dapat 9-12 , Gambar 15-17; DBD 5; SDD; SDP 5.6; SPS 5.1
digunakan kembali 4.2.3.2; SDP 4.2.3.2; SDD (lihat juga deskripsi desain "as built", desain
4.1; SSDD 4.1 mengevaluasi produk perangkat lunak yang dapat perilaku, desain arsitektur CSCI, desain detail CSCI,
digunakan kembali keputusan desain seluruh CSCI, Deskripsi Desain Basis Data,
4.2.3.1, B.3; SDP 4.2.3.1 menggabungkan produk Deskripsi Desain Antarmuka, desain
perangkat lunak yang dapat digunakan kembali Kata arsitektur sistem, Deskripsi Desain
Pengantar-3, 3.12, 4.2.3.1, Lampiran B, Gambar 3; Sistem/Subsistem, seluruh sistem
semua DID: 10.1.i; SDP 4.2.3.1; SDD 4.1; SSDD 4.1 keputusan desain)
reverse engineering 3.29, Gambar 12
tinjauan (lihat tinjauan teknis dan manajemen bersama) revisi dan tinjauan desain perangkat lunak E.4.6
pengujian ulang 5.7.4, 5.8.3, 5.9.6, 5.10.3, standar desain perangkat lunak 4.2.2, D.4.7;
5.11.6; SDP 5.7.4, 5.8.3, 5.9.6, 5.10.3, 5.11.6; STD 4.xy, DBDD 3, 4, 5; SLI 3; SDD 3, 4, 5; SDP 4.2.2; SPS 5.3;
4.xy3, 5; STP 4.1.3, 5 SSDD 3, 4 pengembangan
manajemen risiko 5.18.1, 5.18.2, 5.19.1, B.3, Gambar 5, G.4, perangkat lunak (arti istilah "perangkat lunak
Gambar 8-12; SDP 4, 5, 5.19.1 pengembangan" dalam MIL-STD-498) Kata Pengantar-4, 1.2.1,
3.33
Machine Translated
(versi PDF) Indeks halaman 65
lingkungan pengembangan perangkat lunak 1.2.2, 4.1, Gambar 1, 5.2, 5.14.1, jaminan kualitas perangkat lunak 4.1, Gambar 1, 5.16, Gambar 2,
Gambar 2, Gambar 3, E.4.10, Gambar 9-13; SDP 5.2 (lihat juga Gambar 3, Gambar 9-12; SDP 5.16
lingkungan rekayasa perangkat lunak, pengujian - lingkungan independensi dalam jaminan kualitas perangkat lunak 5.16.3; SDP
pengujian perangkat lunak) 5.16.3
file pengembangan perangkat lunak (SDF) 3.34, 5.2.4, 5.7.2, evaluasi jaminan kualitas perangkat lunak 5.16.1; SDP 5.16.1
5.7.4, 5.7.5, 5.8.1, 5.8.3, 5.8.4, 5.9.4, 5.9.6, 5.10.1, 5.10.3, 5.10.4,
5.11.4, 5.11.6, Gambar 3 , Gambar 6; SDP 5.2.4 catatan jaminan kualitas perangkat lunak 5.16.2; SDP 5.16.2
perpustakaan pengembangan perangkat lunak (SDL) 3.35, 5.2.3, Gambar persyaratan perangkat lunak, Persyaratan Perangkat Lunak
3; SDP 5.2.3 Spesifikasi (SRS) 5.5, 5.9, 6.2, Gambar 2-4, Gambar 6, Gambar
metode pengembangan perangkat lunak Kata Pengantar-5, 4.2.1; 9-12, Gambar 15-17; SRS; STP 6 (lihat juga
SDP 4.2.1 persyaratan CSCI) analisis kebutuhan
perencanaan pengembangan perangkat lunak, Software Development Plan perangkat lunak 4.1, Gambar 1, 5.5, Gambar 3, Gambar 9-12;
(SDP) 1.2.4.2, 4.1, 5.1.1, 5.14.2, 5.16.1, 5.16.2, 5.17.1, 5.17.2, Tinjauan persyaratan perangkat
5.19.1, 5.19. 2, 5.19.7, 6.2, Gambar 2, B.3, Gambar 4, Gambar 6, lunak SDP 5.5 Dukungan perangkat lunak E.4.5
D.4.7, E.4.1, Gambar 9-13, G.6.3, H.4, Gambar Kata Pengantar-3, 3.35, 3.41, 3.44, 4.2.6, 5.2.3, 5.2.5, 5.13.4, Gambar 2,
15-17; SDP Gambar 3, Gambar 6, Gambar 14; SPS 5; RSK 3.15; SS 3.15;
proses pengembangan perangkat lunak 3.36, 4.1, Gambar 1, 5.19.1, 5.19.2, STRP (lihat juga pemeliharaan)
5.19.7, 6.5, Gambar 2, Lampiran G, H.4 lingkungan
rekayasa perangkat lunak 1.2.2, 3.37, 3.38, 4.2.7, 5.2. 1, 5.2.3, Gambar lembaga pendukung 3.44, 4.2.6 5.1.5, 5.13, 5.13.4, 5.13.7, E.4.10,
13; SDP 5.2.1; Implementasi perangkat lunak CPM 3 dan G.6.1, Gambar 13; OCD 3.6, 5.5, 7.1,
pengujian unit 4.1, Gambar 1, 7.2, 7.3 mendukung konsep 3.12,
5.7, 5.9.1, 5.11.1, Gambar 3, Gambar 6, Gambar 9-12, Gambar 5.1.5; OCD 3.5, 5.5 manual dukungan 5.13.6, Gambar 4,
14; SDP 5.7 Gambar 6, E.4.10; SDP 5.13.6; STRP 3.2, 3.3, 3.4
Software Input/Output Manual (SIOM) 5.12.3.2, 6.2, Gambar 6, Gambar
9-12, Gambar 15, Gambar 17; SIOM (lihat juga situs dukungan 5.13.1-5.13.3, 5.13.7; SDP
Software Center Operator Manual, Software User Manual) 5.13.3, 5.13.7 tinjauan
perencanaan instalasi perangkat dukungan E.4.10 sistem perangkat lunak
lunak, Software Installation Plan (SIP) 5.1.4, 6.2, Gambar 4, Gambar 6, 1.2.4.1, 1.2.4.2, 3.42, Gambar 14;
E.4.1, Gambar 9-13, Gambar 15, Gambar 17; SDP 5.1.4; SSS 3.9, 3.10
Pemeliharaan perangkat lunak SIP (lihat pengujian perangkat lunak (lihat
dukungan perangkat lunak) indikator manajemen perangkat pengujian) transisi perangkat lunak 3.44
lunak Kata Pengantar-3, 5.19.2, Gambar 2, Lampiran F, Gambar 9-12; perencanaan transisi perangkat lunak, Software Transition Plan (STrP)
SDP 5.19.2 tinjauan rencana perangkat lunak E.4.1 Gambar 1, 5.1.5, 6.2, Gambar 4, Gambar 6, E.4.1, Gambar
produk perangkat lunak 1.2.1, 3.16, 9-12, Gambar 15-17; SDP 5.1.5; Transisi perangkat
3.26, 3.31, 3.39, dkk (lihat juga standar untuk produk perangkat lunak) lunak STRP (persiapan untuk) 4.1, Gambar 1, 5.13, Gambar 3,
evaluasi produk perangkat lunak 4.1, Gambar 1, 5.15, Gambar 9-12; SDP 5.13
5.16.1, unit perangkat lunak 3.24, 3.45, 5.2.4, 5.6, 5.7, 5.8, 5.13.4,
Gambar 2, Gambar 3, Lampiran D, Gambar 6, Gambar 9-12; SDP 5.15 5.14.1, B.4, Gambar 3, Gambar 6, F.3, G.6.4, Gambar 14, Gambar
independensi dalam evaluasi produk perangkat lunak 5.15.3; 15, Gambar 17; DBDD 5, 5.x, 6;
SDP 5.15.3 evaluasi SDD 3, 4.1, 4.2, 4.3, 4.3.1, 5, 5.x, 6; SPS 5.4, 6; SRS 3.12 (lihat
produk perangkat lunak dalam proses dan akhir 5.15.1; SDP juga pengujian) penggunaan perangkat
5.15.1 kriteria evaluasi lunak (persiapan untuk) 4.1, Gambar 1, 5.12, Gambar 3, Gambar 9-12
produk perangkat lunak 5.15.1, 5.18.1, Gambar 6, D.4; SDP 5.15.1 tinjauan
kegunaan perangkat lunak E.4.9 Panduan
catatan evaluasi produk perangkat lunak 5.15.2; Pengguna Perangkat Lunak (SUM) 5.12.3, 5.12.3.1, 6.2,
SDP 5.15.2 Gambar 2, Gambar 3, Gambar 4, Gambar 6, E.4.9, Gambar 9-12,
produk perangkat lunak tunduk pada evaluasi D.3, Gambar 6 Gambar 15-17; SDP 5.12.3; SIP 3.5, 4.x.6, 5.x.2, 5.x.3;
Spesifikasi Produk Perangkat Lunak (SPS) 5.12.1, 5.13.1, STRP 3.2-3.4; SUM (lihat juga Manual Operator Pusat Perangkat
5.13.2, 5.13.4, 5.13.6, 6.2, Gambar 6, E.4.10, Gambar 9-12, Gambar Lunak, Manual Input/Output Perangkat Lunak)
15-17; Kualitas Deskripsi Versi Perangkat Lunak (SVD) 5.12.2, 5.13.3,
perangkat lunak SPS 3.40 6.2, Gambar 3, Gambar 6, D.4.1, E.4.9, E.4.10, Gambar 9-12,
Gambar 16, Gambar 17; SDP 5.12.2, 5.13.3; Kode
sumber SVD (lihat juga versi/revisi/rilis), file
sumber 3.29, 5.7.1, 5.12.1, 5.13.2,
5.13.4, B.3, Gambar 3, Gambar 4, Gambar 6,
F.3; SDP 5.7.1, 5.13.2; SPS 3.2, 3.3, 5.1; SVD 3.2
pengiriman file sumber SPS 3.2
Machine Translated
kepegawaian F.3, Gambar 8; OCD 3.4, 5.4, 7.2; SDP 7; Pengujian kualifikasi CSCI 3.28, 3.43, 4.1, Gambar 1,
SIP 3.5, 3.6, 4.x.4; STP 3.x.6, 3.x.7; STrP 3.5 dokumen 5.1.2, 5.2.2, 5.9, 5.9.5, Gambar 3, Gambar 6, E.4.7, E.4.8,
standardisasi terkait MIL-STD-498 Gambar 2 standar untuk produk Gambar 9-13; IRS 4; SDP 5.1.2, 5.9; RSK 4; STD;
perangkat lunak 4.2.2, SDP 4.2.2; SPS 5.3 (lihat juga standar STP; Pengujian
kode, standar desain perangkat lunak) status internal pengembang STR 3.34, 5.4.1, 5.8, 5.9,
dan mode operasi COM 3.2; DBDD 5.10, 5.11; SDP 5.9.4, 5.11.4 dry run
3, 4, 5; SLI 3; IRS 3; OCD 3.3, 5.3, 6, 7.1, 7.2; SCOM 3.5; SDD 3, 4, 5; pengujian kualifikasi 5.9.4, 5.11.4, Gambar 6, D.4.2 revisi dan
SIOM 3.5; RSK 3.1; SSDD 3, 4; SSS 3.1; JUMLAH
3.5 pengujian ulang 5.7.4, 5.8.3, 5.9.6, 5.10.3,
5.11.6; SDP 5.7.4, 5.8.3, 5.9.6, 5.10.3, 5.11.6; STD 4.xy3,
Pernyataan Kerja (SOW) 1.2.1, 6.5, 6.7, Gambar 6, D.4.5, 4.xy5; STP 4.1.3, 5
D.4.10, G.6.3 Software Test Description (STD) 5.9.3, 5.11.3, 6.2, Gambar 2,
subkontraktor, manajemen subkontraktor Kata Pengantar-4, 1.2.1, 3.5, Gambar 4, Gambar 6, D.4.2, E.4.7, Gambar 9-12,
4.2.7, 5.4.1, 5.19.4; SDP 4.2.7, 5.19.4 Gambar 15-17;
subsistem 1.2.4.1, 5.2.4, 5.3.3, E.4.3, E.4.4; SSDD; Lingkungan pengujian perangkat lunak STD 1.2.2, 3.37, 3.43, 4.2.7,
Dukungan SSS (juga lihat sistem/subsistem) 5.2.2, Gambar 3, E.4.7, Gambar 13; SDP 5.2.2; STP 3; STR
(perangkat lunak) (lihat dukungan perangkat lunak, 3.2
perencanaan transisi perangkat lunak) perencanaan pengujian perangkat lunak, Rencana Pengujian Perangkat Lunak (STP)
sistem (lihat juga konsep operasional) interpretasi 5.1.2, 5.1.3, 6.2, Gambar 4, Gambar 6, E.4.1, Gambar
"sistem" dalam MIL-STD-498 1.2.4.1, Gambar 14 desain arsitektur 9-12, Gambar 15-17; SDP 5.1.2, 5.1.3;
sistem Laporan Uji Perangkat Lunak STP (STR) 5.9.7, 5.11.7, 6.2,
3.4, 5.4.2, Gambar 3, Gambar 4, Gambar 6, E.4.4; SDP 5.4.2, Gambar 4, Gambar 6, D.4.2, E.4.8, Gambar 9-12, Gambar
5.13.5; Desain sistem SSDD 4 3.17, 4.1, Gambar 1, 15-17; SDP 5.9.7, 5.11.7;
5.4, 5.13.5, Gambar 3, pengujian kualifikasi sistem STR 3.28, 3.43, 4.1, Gambar 1, 5.1.3,
Gambar 4, E.4.4, Gambar 9-12; SDP 5.4, 5.13.5 5.2.2, 5.11, 5.11.5, Gambar 3, Gambar 6, E.4.7, E.4.8,
pengujian kualifikasi sistem 3.28, 3.43, 4.1, Gambar 1, 5.1.3, Gambar 9-13; IRS 4; SDP 5.11; SS 4; STD; STP; STR
5.2.2, 5.11, 5.11.5, Gambar 3, Gambar 6, E.4.7, E.4.8, sistem komputer target
Gambar 9-13; IRS 4; SDP 5.11; SS 4; STD; STP; (pengujian pada) 5.9.2, 5.11.2; SDP 5.9.2, 5.11.2
Persyaratan sistem
STR 5.3.3, 5.4.2, 5.5, 5.11.3, Gambar 3, kelas pengujian (pengaturan waktu, input yang
Gambar 4, Gambar 6; DBDD 3, 4, 6; SLI 4; SDP 5.3.3; SSDD salah, kapasitas maksimum) STP 4.1.2, 4.2.xy
3, 4, 4.1, 5; STD 4.xy1, 5; STP 6 (lihat juga Spesifikasi informasi pengujian untuk pengujian internal pengembang
Kebutuhan Antarmuka, Spesifikasi Sistem/Subsistem) (kasus uji, uraian uji, prosedur uji, hasil uji) 3.34, 3.39,
analisis kebutuhan sistem 4.1, Gambar 1, 5.2.4, 5.7.2, 5.8.1, 5.10.1, Gambar 2-4, Gambar 6,
5.3, Gambar 3, Gambar 9-12; SDP 5.3 perencanaan pengujian D.4.2 tinjauan kesiapan uji E.4.7
sistem 5.1.3; Keputusan review hasil pengujian E.4.8 unit
desain seluruh sistem STP 3.6, 5.4.1, 5.10.1, testing 5.7, Gambar 3, F.3, Gambar
9-12; Integrasi dan pengujian unit SDP 5.7 4.1, Gambar 1,
Gambar 3, Gambar 6, E.4.4; SDP 5.4.1; SSDD 3, 4.1 5.8, Gambar 3, F.3, Gambar 9-12; SDP 5.8 menyaksikan
Deskripsi Desain Sistem/Subsistem (SSDD) pengujian 5.9.4, 5.11.4; STR
5.4.1, 5.4.2, 5.13.5, 5.13.6, 6.2, Gambar 6, Gambar 9-12, 5 ketertelusuran 5.4.2, 5.5, 5.6.2, 5.9.3, 5.11.3,
Gambar 15-17; 5.13.4;
Tinjauan desain sistem/subsistem SSDD E.4.4 DBDD 6; SLI 4; IRS 3, 5; SDD 6; SPS 5.4, 6; RSK 3, 5; SSDD
tinjauan persyaratan sistem/subsistem E.4.3 Spesifikasi 5; SSS 3, 5; STD 4.xy1, 5; STP 4.2.xy, 6 pelatihan 5.1.4,
Sistem/Subsistem (SSS) 5.3.3, 5.11, 6.2, Gambar 6, Gambar 9-12, Gambar 2, Gambar
Gambar 15-17; SSS 3; OCD 7.1, 7.2; SIP 3.4, 3.5; RSK 3.14; SS 3.14; STRP
5, 7
menyesuaikan MIL-STD-498 dan DID-nya Kata Pengantar-9, 1.2.2, pelatihan lembaga pendukung 5.13.7; STrP 5, 7 pelatihan
1.2.3, 5.12.1, 6.5, Gambar 2, G.6, G.6.3, H.3, H.6; semua pengguna 5.12.4; SIP 3.4, 3.5; STP 3.x.8
DID: 10.1.f transisi (perangkat lunak) (lihat transisi perangkat lunak)
sistem komputer target (pengujian pada) 5.9.2, 5.11.2; pengujian terjemahan 3.29, Gambar 12
SDP 5.9.2, 5.11.2
Gambar 2, D.4.13; STD; STP; Pemberitahuan awal unit, pengujian unit, integrasi unit dan pengujian (lihat
STR tentang pengujian kualifikasi 5.9.3, 5.9.6, 5.11.3, 5.11.6 unit perangkat lunak, pengujian)
Integrasi dan manual pengguna (lihat manual pengguna perangkat lunak)
pengujian CSCI/HWCI 4.1, Gambar 1, 5.10, Gambar 3, Gambar 6,
Gambar 9-12; SDP 5.10
Machine Translated
versi/revisi/rilis 3.7, 5.14.1-5.14.3, B.3; Work Breakdown Structure (WBS) 6.6, Gambar 2
semua DID: 10.1.c; DBDD 3, 5.x; FSM 3.x.4;
SDD 4.1, 4.3.1; SDP 4.2.2, 5.17.1; SIP 4.x.2; SPS
5.2; SRS 3.3.1, 3.10.3; SSDD 4.1, 4.3.1; SSS
3.3.1, 3.10.3; STR 5; STRP 3.2-3.4; SVD
Penjaga: Mempersiapkan Kegiatan:

Angkatan Darat - SC Angkatan Laut - EC
Angkatan Laut - EC
Angkatan Udara - 10 (Proyek IPSC-0230)
DISA - DC
DLA - DH
Kegiatan Tinjauan:
OSD - JADI, IR, NT
Tentara - AR, CR, MI, AV
Angkatan Laut - AS, SH, SA, TD, OM, MC
Angkatan Udara - 02, 06, 11, 13, 17, 19
DMA - MP
DNA-DS
NSA - NS
Kegiatan koordinasi Instansi Sipil:

NASA - NA
TITIK - FAA, USCG
COM - NIS
CIA
Kegiatan DoD lainnya:

DSMC
SEI
Instansi selain Pemerintah AS:

DND Kanada
DoD Jerman
MoD Inggris
Industri AS - CODSIA
PROPOSAL PERBAIKAN DOKUMEN STANDARDISASI
INSTRUKSI
1. Kegiatan penyiapan harus melengkapi blok 1, 2, 3, dan 8. Pada blok 1, baik nomor dokumen maupun revisi
surat harus diberikan.
2. Pengirim formulir ini harus melengkapi blok 4, 5, 6, dan 7.
3. Kegiatan persiapan harus memberikan balasan dalam waktu 30 hari sejak diterimanya formulir.
CATATAN: Formulir ini tidak boleh digunakan untuk meminta salinan dokumen, atau untuk meminta keringanan, atau
klarifikasi persyaratan kontrak saat ini. Komentar yang dikirimkan pada formulir ini bukan merupakan atau menyiratkan
otorisasi untuk mengesampingkan bagian mana pun dari dokumen yang direferensikan atau untuk mengubah persyaratan kontrak
1. DOKUMEN NOMOR 2. TANGGAL DOKUMEN YYMMDD)
SAYA MEREKOMENDASIKAN PERUBAHAN: MIL-STD-498 ( 941205
3. JUDUL DOKUMEN
Pengembangan dan Dokumentasi Perangkat Lunak

4. SIFAT PERUBAHAN (Identifikasi nomor paragraf dan sertakan usulan penulisan ulang, jika memungkinkan.
Lampirkan lembar tambahan yang diperlukan.) as
5. ALASAN REKOMENDASI
6. PENGIRIM
A. NAMA (Terakhir, Pertama, Tengah Awal) B. ORGANISASI
C. ALAMAT (Termasuk Ritsleting Kode) D. TELEPON (Termasuk Daerah Kode) 7. TANGGAL PENGIRIMAN
(YYMMDD)
(1) Komersial
(2) MOBIL
(jika ada)
8. KEGIATAN PERSIAPAN
A. NAMA B. TELEPON (Termasuk Daerah Kode)
Komando Sistem Perang Luar Angkasa & Angkatan Laut (1) Komersial (2) AUTOVON
(703)602-4491 332-4491
C. ALAMAT (Termasuk Ritsleting Kode) JIKA ANDA TIDAK MENERIMA BALASAN DALAM WAKTU 45 HARI, HUBUNGI:
SPAWAR 10-12 Kantor Mutu dan Standardisasi Pertahanan
2451 Penggerak Kristal (CPK-5) 5203 Leesburg Pike, Suite 1403, Falls Church, VA 22041-3466
Arlington, VA 22245-5200 Telepon (703)756-2340 AUTOVON 289-2340
Formulir DD 1426, Oktober 89 Edisi sebelumnya sudah usang 198/290

Pengembangan Perangkat Lunak Dan Dokumentasi

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Pengembangan Perangkat Lunak Dan Dokumentasi

Diunggah oleh

Hak Cipta:

Format Tersedia

Machine Translated by Google BUKAN PENGUKURAN

PENGEMBANGAN PERANGKAT LUNAK

AMSC NO. N7069 AREA: IPSC/MCCR

PERNYATAAN DISTRIBUSI A. Aroved untuk distribusi rilis publik tidak terbatas.

3. Standar ini menggabungkan DOD-STD-2167A dan DOD-STD-7935A untuk menentukan serangkaian

2. DOKUMEN REFERENSI .............................................. 3

3. DEFINISI ............................................... ...... 4

4. PERSYARATAN UMUM .............................................. 8 4.1 Proses pengembangan perangkat

4.2.5 Pemanfaatan sumber daya perangkat keras komputer. . . . . . . . . . . . ... . . . . ...

5. PERSYARATAN RINCI . . . . ... . . . . . . . . . . . . . . . ... . . . . ... . . . . . . . . 11 .

B MENAFSIRKAN MIL-STD-498 UNTUK PENGGABUNGAN PRODUK PERANGKAT LUNAK YANG

C KATEGORI DAN KLASIFIKASI PRIORITAS MASALAH

D EVALUASI PRODUK PERANGKAT LUNAK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 .

TINJAUAN MANAJEMEN BERSAMA KANDIDAT . . . . . . . . . . . . . . . . . . . . . . . 44 .

G PEDOMAN STRATEGI PROGRAM, TAILORING, DAN BUILD

H PEDOMAN PEMESANAN HASIL . . . . . . ... . . . . ... . . . . ... . 56 .

PANDUAN KONVERSI DARI DOD-STD-2167A DAN DOD-STD-7935A . . . . . 57 .

1 Satu kemungkinan pemetaan aktivitas MIL-STD-498 ke beberapa build . . . . . . . . . 11

2 Dokumen standardisasi terkait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Prioritas yang akan digunakan untuk mengklasifikasikan masalah. . . . . . . . . . . . . . . . . . . . . . . . . 37

6 Produk perangkat lunak dan kriteria evaluasi terkait. . . . . . . . . . . . . . . . . . . . 39

7 Fitur utama dari tiga strategi program DOD. . . . . . . . . . . . . . . . . . . . . . . . 47

8 Contoh analisis risiko untuk menentukan strategi program yang tepat. . . . . . . 49

10 Salah satu cara yang mungkin untuk menerapkan MIL-STD-498 ke Inkremental

11 Salah satu cara yang mungkin untuk menerapkan MIL-STD-498 ke Evolutionary

13 Contoh perencanaan pembangunan untuk proyek MIL-STD-498 . . . . . . . . . . . . . . . . . . . 54

14 Pemetaan istilah kunci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

15 Pemetaan DID DOD-STD-7935A ke DID MIL-STD-498 . . . . . . . . . . . . . . . . 58

16 Pemetaan DOD-STD-2167A DID ke MIL-STD-498 DID . . . . . . . . . . . . . . . . 59

17 Pemetaan DID MIL-STD-498 ke DID DOD-STD-2167A dan DOD-

1.2 Aplikasi. MIL-STD-498 dimaksudkan untuk diterapkan sebagai berikut.

1.2.4.1 Interpretasi "sistem". Interpretasi berikut berlaku:

3.8 Basis data komputer. Lihat basis data.

3.11 Perangkat lunak komputer. Lihat perangkat lunak.

3.46 Dukungan (perangkat lunak). Lihat dukungan perangkat lunak.

3.47 Transisi (perangkat lunak). Lihat transisi perangkat lunak.

A. Perencanaan dan pengawasan proyek (bagian 5.1) b.

2) Evaluasi produk perangkat lunak (5.15)

4.2.4 Penanganan kebutuhan kritis. Pengembang harus memenuhi persyaratan berikut.

5.1 Perencanaan dan pengawasan proyek X X X X

5.2 Membangun lingkungan pengembangan perangkat lunak X X X X

5.3 Analisis kebutuhan sistem X X

5.4 Desain sistem X X X

5.5 Analisis kebutuhan perangkat lunak X X X X

5.6 Desain perangkat lunak X X X X

5.7 Implementasi perangkat lunak dan pengujian unit X X X X

5.8 Integrasi dan pengujian unit X X X X

5.9 Pengujian kualifikasi CSCI X X X

5.10 Integrasi dan pengujian CSCI/HWCI X X X

5.11 Pengujian kualifikasi sistem X X

5.12 Mempersiapkan penggunaan perangkat lunak X X X X

5.13 Mempersiapkan transisi perangkat lunak X

5.14 Manajemen konfigurasi perangkat lunak X X X X

5.15 Evaluasi produk perangkat lunak X X X X

5.16 Jaminan kualitas perangkat lunak X X X X

5.17 Tindakan korektif X X X X

5.18 Tinjauan teknis dan manajemen bersama X X X X

5.19 Kegiatan lainnya X X X X

GAMBAR 1. Satu kemungkinan pemetaan aktivitas MIL-STD-498 ke beberapa bangunan.

5.2 Membangun lingkungan pengembangan perangkat lunak. Pengembang wajib menetapkan a

5.12.4 Pemasangan di lokasi pengguna. Pengembang harus:

B. Memberikan pelatihan kepada pengguna sebagaimana ditentukan dalam kontrak.

C. Memberikan bantuan lain ke situs pengguna sebagaimana ditentukan dalam kontrak.