Rekayasa Perangkat Lunak: Prinsip Dan Praktek: Hans Van Vliet

Rekayasa Perangkat Lunak: Prinsip
dan Praktek
Hans van Vliet
(c) Wiley, 2007

Isi
1 Perkenalan 1
Bab 1 Perkenalan 1
1.1 Apa itu Rekayasa Perangkat Lunak? . . . . . . . . . . . . . . . . . . . . . 5
1.2 Tahapan dalam Pengembangan Perangkat Lunak . . . . . . . . . . . . . . . . 10
1.3 Pemeliharaan atau Evolusi . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Dari Parit . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.1 Ariane 5, Penerbangan 501 . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.2 Therac-25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.3 Layanan Ambulans London. . . . . . . . . . . . . . . . 21
1.4.4 Siapa yang Menghitung Suara? . . . . . . . . . . . . . . . . . . . . 23
1.5 Etika Rekayasa Perangkat Lunak . . . . . . . . . . . . . . . . . . . . . . 25
1.6 Ke mana engkau pergi? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.7 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.8 Bacaan lebih lanjut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Latihan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
SAY Manajemen Perangkat Lunak 33

A
2 Pengantar Manajemen Rekayasa Perangkat Lunak 34
Bab 2 Pengantar Manajemen Rekayasa Perangkat Lunak 34

2.1 Merencanakan Proyek Pengembangan Perangkat Lunak . . . . . . . . . . . . . . . 37
2.2 Mengontrol Proyek Pengembangan Perangkat Lunak ............
. 40
2.3 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Latihan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3 Siklus Hidup Perangkat Lunak Ditinjau Kembali 45
bagian 3 Siklus Hidup Perangkat Lunak Ditinjau Kembali 45

3.1 Model Air Terjun. . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2 Metode Agile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.1 Pembuatan prototipe . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2 Pengembangan Inkremental. . . . . . . . . . . . . . . . . . . 56
3.2.3 Pengembangan Aplikasi Cepat dan DSDM .......
. . 57
3.2.4 Pemrograman Ekstrim. . . . . . . . . . . . . . . . . . . . . 61
3.3 Rasional Unified Process (RUP) . . . . . . . . . . . . . . . . . . 64
3.4 Selingan: Pemeliharaan atau Evolusi . . . . . . . . . . . . . . . . . 66
3.5 Lini Produk Perangkat Lunak . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.6 Pemodelan Proses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.7 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Latihan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4 Manajemen konfigurasi 7
8
Bab 4 Manajemen konfigurasi 7
8
4.1 Tugas dan Tanggung Jawab . . . . . . . . . . . . . . . . . . . . . . . . 80
4.2 Rencana Manajemen Konfigurasi . . . . . . . . . . . . . . . . . . . . 85
4.3 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Latihan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5 Manajemen Orang dan Organisasi Tim 8

9
Bab 5 Manajemen Orang dan Organisasi Tim 8
9
5.1 Manajemen Orang . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.1.1 Mekanisme Koordinasi . . . . . . . . . . . . . . . . . . . 93
5.1.2 Gaya Manajemen. . . . . . . . . . . . . . . . . . . . . . . 94
5.2 Organisasi Tim. . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.2.1 Organisasi Hirarki. . . . . . . . . . . . . . . . . . . 96
5.2.2 Organisasi Matriks. . . . . . . . . . . . . . . . . . . . . . 98
5.2.3 Ketua Tim Programmer. . . . . . . . . . . . . . . . . . . . 99
5.2.4 Tim SWAT. . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.5 Tim Gesit. . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.6 Pengembangan Perangkat Lunak . . . . . . . . . . . . . 101
Sumber Terbuka
5.2.7 Prinsip Umum Pengorganisasian Tim . . . . . . . . . . . 103
5.3 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Latihan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6 Tentang Mengelola Kualitas Perangkat Lunak 1

0
7
Bab 6 Tentang Mengelola Kualitas Perangkat Lunak 1
0
7
6.1 Tentang Ukuran dan Bilangan . . . . . . . . . . . . . . . . . . . . . . . 110
6.2 Taksonomi Atribut Kualitas . . . . . . . . . . . . . . . . . . . 116
6.3 Perspektif Kualitas . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.4 Sistem Mutu. . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.5 Jaminan Kualitas Perangkat Lunak. . . . . . . . . . . . . . . . . . . . . . . 128
6.6 Model Kematangan Kemampuan (CMM) . . . . . . . . . . . . . . . . 130
6.7 Beberapa Catatan Kritis. . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.8 Mulai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.9 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.10 Bacaan Lebih Lanjut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Latihan . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 141
7 Perkiraan biaya 1
4
4
Bab 7 Perkiraan biaya 1
4
4
7.1 Model Algoritma . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7.1.1 Walston--Felix . . . . . . . . . . . . . . . . . . . . . . . . . 151
7.1.2 COCOMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7.1.3 Putnam. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
7.1.4 Analisis Titik Fungsi . . . . . . . . . . . . . . . . . . . . . 156
7.1.5 COCOMO 2: Variasi Tema . . . . . . . . . . . . . 159
7.2 Pedoman Memperkirakan Biaya . . . . . . . . . . . . . . . . . . . . . 166
7.3 Distribusi Tenaga Kerja dari Waktu ke Waktu . . . . . . . . . . . . . . . . . . 169
7.4 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Latihan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
8 Perencanaan dan Kontrol Proyek 1

7
6
Bab 8 Perencanaan dan Kontrol Proyek 1
7
6
8.1 Tampilan Sistem Kontrol Proyek . . . . . . . . . . . . . . . . . . . 177
8.2 Taksonomi Proyek Pengembangan Perangkat Lunak . . . . . . . . . . . . 179
8.3 Manajemen risiko . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
8.4 Teknik Perencanaan dan Pengendalian Proyek ......
......
. 189
8.5 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Latihan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
II Siklus Hidup Perangkat Lunak 1

9
7
9 Rekayasa Persyaratan 1
9
9
Bab 9 Rekayasa Persyaratan 1
9
9
9.1 Eliminasi Persyaratan ..................
. . . . . . 205
9.1.1 Paradigma Rekayasa Kebutuhan ......
......
. 210
9.1.2 Persyaratan Teknik Elisitasi . . . . . . . . . . . . . . 212
9.1.3 Tujuan dan Sudut Pandang . . . . . . . . . . . . . . . . . . . . . 220
9.1.4 Memprioritaskan Persyaratan . . . . . . . . . . . . . . . . . . . 223
9.1.5 pilihan COTS . . . . . . . . . . . . . . . . . . . . . . . . 224
9.2 Persyaratan Dokumentasi dan Manajemen . . . . . . . . . . . . 227
9.2.1 Manajemen Persyaratan. . . . . . . . . . . . . . . . . . . 234
9.3 Persyaratan Spesifikasi Teknik ................
236
9.3.1 Menentukan Persyaratan Non-Fungsional . . . . . . . . . . . 238
9.4 Verifikasi dan Validasi . . . . . . . . . . . . . . . . . . . . . . . 239
9.5 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Latihan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
10 Pemodelan 246
Bab 10Pemodelan 246

10.1 Teknik Pemodelan Klasik . . . . . . . . . . . . . . . . . . . . . . 24810.1.1 Entitas--Pemodelan
Hubungan . . . . . . . . . . . . . . . . . 24810.1.2 Mesin Negara Hingga . . . . . . . . . . . . . . . . . . . . .
. 250
10.1.3 Diagram Aliran Data (DFD) . . . . . . . . . . . . . . . . . . 252
10.1.4 Kartu CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 25210.2 Tentang Objek dan Barang
Terkait . . . . . . . . . . . . . . . . . . . . . . 25410.3 Bahasa Pemodelan Terpadu . . . . . . . . . . . . . . . .
. . . . 26010.3.1 Diagram Kelas . . . . . . . . . . . . . . . . . . . . . . . 26010.3.2 Diagram Mesin
Negara . . . . . . . . . . . . . . . . . . 26510.3.3 Diagram Urutan . . . . . . . . . . . . . . . . . . . . .
26810.3.4 Diagram Komunikasi . . . . . . . . . . . . . . . . . 271
10.3.5 Diagram Komponen . . . . . . . . . . . . . . . . . . . 272

10.3.6 Kasus Penggunaan . . . . . . . . . . . . . . . . . . . . . . . . . . 273
10.4 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
10.5 Bacaan Lebih Lanjut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Latihan . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 274
11 Arsitektur Perangkat Lunak 276
Bab 11Arsitektur Perangkat Lunak 276

11.1 Arsitektur Perangkat Lunak dan Siklus Hidup Perangkat Lunak ......
....
280
11.2 Desain arsitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 28111.2.1 Arsitektur sebagai
seperangkat keputusan desain . . . . . . . . . . . . 28411.3 Tampilan Arsitektur . . . . . . . . . . . . . .
. . . . . . . . . . . . . 28511.4 Gaya Arsitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
11.5 Penilaian Arsitektur Perangkat Lunak . . . . . . . . . . . . . . . . . . . 306

11.6 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
11.7 Bacaan Lebih Lanjut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Latihan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
12 Desain Perangkat Lunak 313
Bab 12Desain perangkat lunak 313

12.1 Pertimbangan Desain . . . . . . . . . . . . . . . . . . . . . . . . . 317
12.1.1 Abstraksi . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
12.1.2 Modularitas . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
12.1.3 Penyembunyian Informasi . . . . . . . . . . . . . . . . . . . . . . . 325
12.1.4 Kompleksitas . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
12.1.5 Struktur Sistem . . . . . . . . . . . . . . . . . . . . . . . . 333
12.1.6 Metrik Berorientasi Objek . . . . . . . . . . . . . . . . . . . . 337
12.2 Metode Desain Klasik . . . . . . . . . . . . . . . . . . . . . . . . 34012.2.1 Dekomposisi Fungsional . . . .
. . . . . . . . . . . . . . . 342
12.2.2 Desain Aliran Data (SA/SD) . . . . . . . . . . . . . . . . . . . 346
12.2.3 Desain berdasarkan Struktur Data . . . . . . . . . . . . . . . . 351
12.3 Metode Analisis dan Perancangan Berorientasi Objek . . . . . . . . . . . . 35912.3.1 Metode
Booch . . . . . . . . . . . . . . . . . . . . . . . 366
12.3.2 Penggabungan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
12.3.3 RUP Dikunjungi Kembali . . . . . . . . . . . . . . . . . . . . . . . . . 369

12.4 Cara Memilih Metode Desain . . . . . . . . . . . . . . . . . . . . 37012.4.1 Orientasi Objek: Hype atau
Jawabannya? . . . . . . . . . . . 373
12.5 Pola Desain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37512.6 Dokumentasi Desain . . . . . . . . . . .
. . . . . . . . . . . . . . 38012.7 Verifikasi dan Validasi . . . . . . . . . . . . . . . . . . . . . . . 383
12.8 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384

12.9 Bacaan Lebih Lanjut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Latihan . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 389
13 Pengujian Perangkat Lunak 394
Bab 13Pengujian Perangkat Lunak 394

13.1 Tujuan Tes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39813.1.1 Kriteria Kecukupan Uji . . . .
. . . . . . . . . . . . . . . . . 40113.1.2 Deteksi Kesalahan Versus Membangun Keyakinan . . . . . . .
. . . 402
13.1.3 Dari Deteksi Kesalahan ke Pencegahan Kesalahan . . . . . . . . . . . 403
13.2 Pengujian dan Siklus Hidup Perangkat Lunak . . . . . . . . . . . . . . . . . . 40613.2.1 Rekayasa
Persyaratan . . . . . . . . . . . . . . . . . . . 407
13.2.2 Desain
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
13.2.3 Implementasi . . . . . . . . . . . . . . . . . . . . . . . . . 409
13.2.4 Pemeliharaan . . . . . . . . . . . . . . . . . . . . . . . . . . 409
13.2.5 Test-Driven Development (TDD) . . . . . . . . . . . . . . . 410
13.3 Verifikasi dan Validasi Perencanaan dan Dokumentasi . . . . . . . 41113.4 Teknik Tes Manual . .
. . . . . . . . . . . . . . . . . . . . . . 413
13.4.1 Membaca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41413.4.2 Panduan dan Pemeriksaan
. . . . . . . . . . . . . . . . . 41513.4.3 Bukti Kebenaran . . . . . . . . . . . . . . . . . . . . . . . 41713.4.4
Abstraksi Bertahap . . . . . . . . . . . . . . . . . . . . . . 41813.5 Teknik Pengujian Berbasis
Cakupan . . . . . . . . . . . . . . . . . . . . 419
13.5.1 Cakupan Aliran Kontrol . . . . . . . . . . . . . . . . . . . . 420

13.5.2 Cakupan Aliran Data . . . . . . . . . . . . . . . . . . . . . . . 423
13.5.3 Pengujian Persyaratan Berbasis Cakupan . . . 424
13.6 Teknik Pengujian Berbasis Kesalahan . . . . . . . . . . . . . . . . . . . . . . 42513.6.1
Kesalahan Pembibitan . . . . . . . . . . . . . . . . . . . . . . . . . . 42513.6.2 Pengujian Mutasi . . . . . .
. . . . . . . . . . . . . . . . . . 42813.7 Teknik Pengujian Berbasis Kesalahan . . . . . . . . . . . . . . . . . .
. . . . 42913.8 Perbandingan Teknik Uji . . . . . . . . . . . . . . . . . . . . 431
13.8.1 Perbandingan Kriteria Kecukupan Tes . . . . . . . . . . . . 432

13.8.2 Sifat Kriteria Kecukupan Uji . . . . . . . . . . . . . . 43413.8.3 Hasil Eksperimen . . . . . . . . .
. . . . . . . . . . . . . 43613.9 Berbagai Tahapan Uji . . . . . . . . . . . . . . . . . . . . . . . . . .
43813.10Memperkirakan Keandalan Perangkat Lunak . . . . . . . . . . . . . . . . . . . . . 439
13.11Ringk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
asan
13.12Bacaan Lebih Lanjut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 Latihan . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 449
14 Pemeliharaan 453
Perangkat Lunak
Bab 14Pemeliharaan 453
Perangkat Lunak
14.1 Tinjauan Kembali Kategori Pemeliharaan . . . . . . . . . . . . . . . . . . . 45614.2 Penyebab
Utama Masalah Pemeliharaan . . . . . . . . . . . . . . . . 45914.3 Rekayasa Balik dan
Pemfaktoran Ulang . . . . . . . . . . . . . . . . . . 46314.3.1 Pemfaktoran Ulang . . . . . . . . . . . . . . .
. . . . . . . . . . . . 466
14.3.2 Batasan Inheren . . . . . . . . . . . . . . . . . . . . . . 469
14.3.3 Alat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47314.4 Evolusi Perangkat Lunak Ditinjau
Kembali . . . . . . . . . . . . . . . . . . . . . . 474
14.5 Masalah Organisasi dan Manajerial . . . . . . . . . . . . . . . . . 476
14.5.1 Organisasi Kegiatan Pemeliharaan . . . . . . . . . . . . 47714.5.2 Pemeliharaan
Perangkat Lunak dari Perspektif Layanan . . . . . . . 48014.5.3 Pengendalian Tugas
Pemeliharaan . . . . . . . . . . . . . . . . . 48614.5.4 Masalah Kualitas . . . . . . . . . . . . . . . . . .
. . . . . . . . 489
14.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Ringkasan
14.7 Bacaan Lebih Lanjut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 Latihan . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 492
15 Alat Perangkat 494

Lunak
Bab 15Alat Perangkat 494
Lunak
15.1 Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49915.2 Lingkungan Berpusat Bahasa .
. . . . . . . . . . . . . . . . . . 50015.3 Lingkungan dan Meja Kerja Terintegrasi . . . . . . . . . . . . . . 501
15.3.1 Meja Kerja Analis . . . . . . . . . . . . . . . . . . . . . 501

15.3.2 Meja Kerja Programmer . . . . . . . . . . . . . . . . . . . 503
15.3.3 Meja Kerja Manajemen ..................
507
15.3.4 Lingkungan Dukungan Proyek Terpadu . . . . . . . . . . . 508
15.4 Lingkungan yang Berpusat pada Proses . . . . . . . . . . . . . . . . . . . . 508
15.5 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
15.6 Bacaan Lebih Lanjut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511 Latihan . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 512
Bibliografi 514
1
Perkenalan
TUJUAN PEMBELAJARAN
�
2 PERKENALAN
Rekayasa perangkat lunak menyangkut metode dan teknik untuk

mengembangkan besar
sistem perangkat lunak. Metafora rekayasa digunakan untuk menekankan
sistematika
pendekatan untuk mengembangkan sistem yang memenuhi persyaratan
organisasi dan
kendala. Bab ini memberikan gambaran singkat tentang bidang dan poin di
tren yang muncul yang mempengaruhi cara perangkat lunak
dikembangkan.
Ilmu komputer masih merupakan bidang yang muda. Komputer pertama dibangun
pada pertengahan 1940-an, sejak saat itu bidang tersebut berkembang pesat.
Aplikasi dari tahun-tahun awal komputerisasi dapat dicirikan sebagai berikut:
programnya cukup kecil, tentunya jika dibandingkan dengan program yang sedang
dibangun; mereka ditulis oleh satu orang; mereka ditulis dan digunakan oleh para
ahli di bidang aplikasi yang bersangkutan. Masalah yang harus dipecahkan
sebagian besar bersifat teknis, dan penekanannya adalah pada ekspresi algoritma
yang dikenal secara efisien dalam beberapa bahasa pemrograman. Input biasanya
terdiri dari data numerik, dibaca dari media seperti punched tape atau punched card.
Outputnya, juga numerik, dicetak di atas kertas. Program dijalankan secara off-line.
Jika program berisi kesalahan, pemrogram mempelajari dump memori oktal atau
heksadesimal. Terkadang, eksekusi program akan diikuti oleh register mesin
pembaca biner di konsol.
Perusahaan pengembangan perangkat lunak independen hampir tidak ada pada
masa itu. Perangkat lunak sebagian besar dikembangkan oleh vendor perangkat
keras dan diberikan secara gratis. Vendor ini terkadang membuat grup pengguna
untuk mendiskusikan persyaratan, dan selanjutnya memasukkannya ke dalam
perangkat lunak mereka. Dukungan pengembangan perangkat lunak ini dilihat
sebagai layanan kepada pelanggan mereka.
Aplikasi masa kini agak berbeda dalam banyak hal. Program masa kini
seringkali sangat besar dan sedang dikembangkan oleh tim yang berkolaborasi
selama beberapa tahun. Tim-tim ini mungkin tersebar di seluruh dunia. Pemrogram
bukan pengguna masa depan dari sistem yang mereka kembangkan dan mereka
tidak memiliki pengetahuan ahli tentang area aplikasi yang dimaksud. Masalah yang
dihadapi semakin menjadi perhatian kehidupan sehari-hari: teller bank otomatis,
reservasi maskapai penerbangan, administrasi gaji, perdagangan elektronik, sistem
otomotif, dll. Menempatkan manusia di bulan tidak dapat dibayangkan tanpa
komputer.
Pada tahun 1960-an, orang mulai menyadari bahwa teknik pemrograman telah
tertinggal dari perkembangan perangkat lunak baik dalam ukuran maupun
kompleksitasnya. Bagi banyak orang, pemrograman masih merupakan sebuah seni
dan belum pernah menjadi keahlian. Masalah tambahan adalah bahwa banyak
pemrogram belum dididik secara formal di lapangan. Mereka telah belajar dengan
melakukan. Di sisi organisasi, upaya solusi untuk masalah sering melibatkan
penambahan lebih banyak programmer ke proyek, yang disebut pendekatan
'juta-monyet'.
Akibatnya, perangkat lunak sering dikirimkan terlambat, program tidak berfungsi
seperti yang diharapkan pengguna, program jarang dapat disesuaikan dengan
keadaan yang berubah, dan banyak kesalahan terdeteksi hanya setelah perangkat
lunak dikirimkan ke pelanggan. Ini
3
dikenal sebagai 'krisis perangkat lunak'.
Jenis masalah ini benar-benar menjadi nyata di tahun 1960-an. Di bawah naungan
NATO, dua konferensi dikhususkan untuk topik pada tahun 1968 dan 1969 (Naur dan
Randell, 1968), (Buxton dan Randell, 1969). Di sini, istilah 'rekayasa perangkat lunak' adalah
diciptakan dalam arti agak provokatif. Bukankah mungkin untuk membangun perangkat lunak
dalam cara membangun jembatan dan rumah, mulai dari landasan teori dan penggunaan
teknik desain dan konstruksi yang baik dan terbukti, seperti di bidang teknik lainnya?
Perangkat lunak melayani beberapa tujuan organisasi. Alasan untuk memulai
proyek pengembangan perangkat lunak bervariasi. Terkadang, solusi untuk suatu masalah tidak
layak tanpa bantuan komputer, seperti prakiraan cuaca, atau otomatis
memberitahu bank. Terkadang, perangkat lunak dapat digunakan sebagai kendaraan untuk teknologi
baru, misalnya
sebagai penyusunan huruf, produksi chip, atau perjalanan luar angkasa berawak. Dalam kasus lain
perangkat lunak dapat meningkatkan layanan pengguna (otomatisasi perpustakaan, e-commerce) atau
hanya menyimpan
uang (kontrol stok otomatis).
Dalam banyak kasus, keuntungan ekonomi yang diharapkan akan menjadi kekuatan pendorong
utama. Mungkin
Namun, tidak selalu mudah untuk membuktikan bahwa otomatisasi menghemat uang (bayangkan saja
otomatisasi kantor) karena selain penghematan biaya langsung, keuntungan ekonomi mungkin
juga memanifestasikan dirinya dalam hal-hal seperti produksi yang lebih fleksibel atau lebih cepat atau
lebih baik
layanan pengguna. Dalam kedua kasus, itu adalah aktivitas yang menciptakan nilai.
Boehm (1981) memperkirakan total pengeluaran untuk perangkat lunak di AS menjadi $40
miliar pada tahun 1980. Ini kira-kira 2% dari GNP. Pada tahun 1985, total pengeluaran
telah meningkat menjadi $70 miliar di AS dan $140 miliar di seluruh dunia. Boehm dan Sullivan
(1999) memperkirakan pengeluaran tahunan untuk pengembangan perangkat lunak pada tahun 1998
menjadi
$300-400 miliar di AS, dan dua kali jumlah itu di seluruh dunia.
Sehingga biaya perangkat lunak sangat penting. Ini tidak hanya menyangkut biaya
mengembangkan perangkat lunak, tetapi juga biaya untuk menjaga agar perangkat lunak tetap
beroperasi satu kali
itu telah disampaikan kepada pelanggan. Dalam perjalanan waktu, biaya perangkat keras telah
menurun drastis. Biaya perangkat keras sekarang biasanya kurang dari 20% dari total
pengeluaran (gambar 1.1). 80% sisanya terdiri dari semua biaya non-perangkat keras: itu
biaya pemrogram, analis, manajemen, pelatihan pengguna, bantuan kesekretariatan, dll.
Aspek yang terkait erat dengan biaya adalah produktifitas. Pada 1980-an, pencarian data
personel pengolah meningkat 12% per tahun, sedangkan populasi orang
bekerja dalam pemrosesan data dan produktivitas orang-orang itu masing-masing tumbuh
sekitar 4% per tahun (Boehm, 1987a). Situasi ini belum fundamental
berubah (Jones, 1999). Efek bersihnya adalah kesenjangan yang semakin besar antara permintaan dan
penawaran.
Hasilnya adalah backlog sehubungan dengan pemeliharaan perangkat lunak yang ada dan
memperlambat pengembangan aplikasi baru. Efek gabungan mungkin
memiliki dampak pada keunggulan kompetitif organisasi, terutama ketika
ada kendala waktu-ke-pasar yang parah. Perkembangan ini telah menyebabkan pergeseran
dari memproduksi perangkat lunak untuk menggunakan perangkat lunak. Kami akan kembali ke topik ini
di bagian 1.6
dan bab ??.
Masalah biaya dan produktivitas pengembangan perangkat lunak patut kita serius
Perhatian. Namun, ini bukan cerita lengkapnya. Masyarakat semakin tergantung
4 PERKENALAN
Gambar 1.1 Distribusi relatif dari biaya perangkat

keras/perangkat lunak. (Sumber: B.W. Boehm,
Rekayasa Perangkat Lunak, Transaksi IEEE di Komputer, 1976 IEE.)
pada perangkat lunak. Kualitas sistem yang kita kembangkan semakin menentukan
kualitas keberadaan kita. Pertimbangkan sebagai contoh pesan berikut dari surat
kabar Belanda pada tanggal 6 Juni 1980, dengan judul 'Orang Amerika melihat
orang Rusia datang':
Untuk waktu yang singkat Selasa lalu, Amerika Serikat membuat

pembom atom dan misil nuklir mereka dalam keadaan waspada ketika,
karena kesalahan komputer, alarm palsu menunjukkan bahwa Uni
Soviet telah memulai serangan misil.
Upaya untuk memperbaiki kesalahan itu tampaknya sia-sia, karena pada tanggal 9
Juni 1980 surat kabar yang sama melaporkan:
Untuk kedua kalinya dalam beberapa hari, komputer yang rusak

melaporkan bahwa Uni Soviet telah memulai serangan nuklir terhadap
Amerika Serikat. Sabtu lalu, DoD menegaskan pesan palsu, yang
mengakibatkan mesin pesawat angkatan udara strategis dihidupkan.
Tidak selalu dunia yang dalam bahaya. Pada skala yang lebih kecil, kesalahan dalam
perangkat lunak mungkin memiliki konsekuensi yang sangat disayangkan, seperti
kesalahan transaksi dalam lalu lintas bank; pengingat untuk akhirnya membayar
tagihan sebesar $0,00; sistem kontrol stok yang mengeluarkan pesanan terlambat
dan dengan demikian memberhentikan seluruh divisi pabrik.
1.1. APA ITU REKAYASA PERANGKAT LUNAK? 5
Contoh terakhir menunjukkan bahwa kesalahan dalam sistem perangkat lunak mungkin serius
konsekuensi finansial bagi organisasi yang menggunakannya. Salah satu contoh keuangan semacam itu
kerugian adalah perusahaan penerbangan besar AS yang kehilangan $50 juta karena kesalahan dalam
sistem reservasi kursi. Sistem secara keliru melaporkan bahwa kursi murah telah terjual
keluar, padahal tersedia banyak. Masalahnya terdeteksi hanya setelah
hasil kuartalan jauh tertinggal dari kedua periode mereka sebelumnya
dan orang-orang dari pesaing mereka.
Kesalahan dalam sistem otomatis bahkan dapat berakibat fatal. Salah satu ilmu komputer
majalah mingguan berisi pesan berikut pada bulan April 1983:
Pengadilan di Düsseldorf telah membebaskan seorang wanita (54),
yang diadili karena membunuh putrinya. Pesan yang salah dari sistem
komputerisasi membuat perusahaan asuransi memberitahunya bahwa
dia sakit parah. Dia dikatakan menderita sifilis yang tidak dapat
disembuhkan. Apalagi, dia dikatakan telah menulari kedua anaknya.
Dalam kepanikan, dia mencekik anak perempuannya yang berusia 15
tahun dan mencoba membunuh anak laki-lakinya yang berusia 13 tahun
dan dirinya sendiri. Anak laki-laki itu melarikan diri, dan dengan bantuan
dia meminta seorang wanita untuk mencegah kematian karena
overdosis. Hakim menyalahkan kesalahan komputer dan menganggap
wanita itu tidak bertanggung jawab atas perbuatannya.
Ini semua menandai pentingnya bidang rekayasa perangkat lunak.
Metode dan teknik yang lebih baik untuk pengembangan perangkat lunak dapat menghasilkan keuangan
yang besar
penghematan, dalam metode pengembangan perangkat lunak yang lebih efektif, dalam sistem yang
lebih sesuai
kebutuhan pengguna, dalam sistem perangkat lunak yang lebih andal, dan dengan demikian dalam
lingkungan yang lebih andal
di mana sistem tersebut berfungsi. Kualitas dan produktivitas adalah dua tema sentral dalam
bidang rekayasa perangkat lunak.
Sisi positifnya, sangat penting untuk menunjukkan kemajuan besar yang telah dicapai
telah dibuat sejak tahun 1960-an. Perangkat lunak ada di mana-mana dan banyak sistem yang dapat
dipercaya
telah dibangun. Ini berkisar dari aplikasi spreadsheet kecil hingga pengaturan huruf
sistem, sistem perbankan, browser Web dan perangkat lunak Space Shuttle. Itu
teknik dan metode yang dibahas dalam buku ini telah menyumbangkan tungau mereka ke
keberhasilan ini dan banyak proyek pengembangan perangkat lunak lainnya.
1.1 Apa itu Rekayasa Perangkat

Lunak?
Dalam berbagai teks tentang topik ini, seseorang menjumpai definisi istilah rekayasa
perangkat lunak. Definisi awal diberikan pada konferensi NATO pertama (Naur dan
Randell, 1968):
Rekayasa perangkat lunak adalah pembentukan dan penggunaan
prinsip-prinsip rekayasa suara untuk mendapatkan perangkat lunak
ekonomis yang dapat diandalkan dan bekerja secara efisien pada
mesin nyata.
Definisi yang diberikan dalam IEEE Standard Glossary of Software Engineering Terminol-
ogy (IEEE610, 1990) adalah sebagai berikut:
6 PERKENALAN
Rekayasa perangkat lunak adalah penerapan pendekatan yang
sistematis, disiplin, terukur untuk pengembangan, pengoperasian, dan
pemeliharaan perangkat lunak; yaitu, penerapan rekayasa pada
perangkat lunak.
Ini dan definisi lain dari istilah rekayasa perangkat lunak menggunakan kata-kata
yang agak berbeda. Namun, karakteristik esensial bidang selalu, secara eksplisit
atau implisit, hadir:
�
begitu banyak disebabkan oleh kompleksitas intrinsik dari masalah (seperti
dalam kasus algoritma pengoptimalan kompiler atau algoritma numerik untuk
menyelesaikan persamaan diferensial parsial), melainkan oleh banyaknya
detail yang harus ditangani.
�
8 PERKENALAN
�
Bahkan dalam disiplin teknik yang matang, katakanlah desain jembatan, kecelakaan bisa saja terjadi.
Jembatan runtuh sesekali. Sebagian besar masalah dalam desain jembatan terjadi saat desainer
mengekstrapolasi di luar model dan keahlian mereka. Contoh terkenal adalah Tacoma
Narrows Bridge gagal pada tahun 1940. Para perancang jembatan itu memperkirakan lebih jauh
pengalaman mereka untuk membuat balok pengaku yang lebih fleksibel untuk jembatan gantung.
Mereka
tidak memikirkan aerodinamika dan respons jembatan terhadap angin. Sebagai akibat,
jembatan itu runtuh tak lama setelah selesai. Jenis ekstrapolasi ini tampaknya
menjadi aturan daripada pengecualian dalam pengembangan perangkat lunak. Kami secara teratur
memulai
pada proyek pengembangan perangkat lunak yang jauh melampaui keahlian kami.
Ada alasan tambahan untuk mempertimbangkan pembangunan perangkat lunak sebagai
sesuatu yang sangat berbeda dari konstruksi produk fisik. Biaya dari
membangun perangkat lunak terjadi selama pengembangan dan bukan selama produksi.
Menyalin perangkat lunak hampir gratis. Perangkat lunak lebih bersifat logis daripada fisik.
Produk fisik aus pada waktunya dan oleh karena itu harus dipertahankan. Perangkat lunak
tidak aus. Kebutuhan untuk memelihara perangkat lunak disebabkan oleh kesalahan yang terdeteksi
terlambat
atau dengan mengubah kebutuhan pengguna. Keandalan perangkat lunak ditentukan oleh
manifestasi kesalahan sudah ada, bukan oleh faktor fisik seperti keausan.
Kami bahkan mungkin berpendapat bahwa perangkat lunak habis dipakai Karena itu sedang
dipertahankan.
Melihat rekayasa perangkat lunak sebagai cabang teknik merupakan masalah bagi
alasan lain juga. Metafora teknik mengisyaratkan pekerjaan yang disiplin, tepat
perencanaan, manajemen yang baik, dan sejenisnya. Ini menunjukkan bahwa kita berurusan dengan
definisi yang jelas
kebutuhan, yang dapat dipenuhi jika kita mengikuti semua langkah yang benar. Banyak pengembangan
perangkat lunak
proyek meskipun melibatkan terjemahan dari beberapa fenomena dunia nyata menjadi digital
membentuk. Pengetahuan yang tertanam dalam fenomena kehidupan nyata ini bersifat diam-diam, tidak
terdefinisi,
tidak terkodifikasi, dan mungkin telah berkembang dalam jangka waktu yang lama. Asumsi bahwa
kita sedang berhadapan dengan masalah yang terdefinisi dengan baik tidak berlaku. Sebaliknya,
desainnya
prosesnya terbuka, dan solusinya muncul seiring berjalannya waktu. dikotomi ini
tercermin dalam pandangan bidang yang ditempatkan di garis depan dari waktu ke waktu (Eischen,
2002). Dalam
hari-hari awal, lapangan dipandang sebagai kerajinan. Sebagai gerakan tandingan, istilah perangkat
lunak
teknik diciptakan, dan banyak konsep pabrik diperkenalkan. Pada akhir 1990-an,
pendulum berayun kembali dan aspek kerajinan ditekankan lagi, di
gerakan lincah (lihat bab 3). Keduanya memiliki aspek seperti teknik dan kerajinan
tempat mereka, dan kami akan memberikan perlakuan yang seimbang dari keduanya.
Dua karakteristik yang membuat proyek pengembangan perangkat lunak menjadi sangat sulit
mengelola adalah visibilitas dan kontinuitas. Jauh lebih sulit untuk melihat kemajuan
konstruksi perangkat lunak daripada memperhatikan kemajuan dalam membangun jembatan. Satu
sering
mendengar ungkapan bahwa program 'hampir selesai'. Seseorang sama-sama sering meremehkan
waktu yang dibutuhkan untuk menyelesaikan potongan-potongan terakhir.
Sindrom '90% selesai' ini sangat meresap dalam pengembangan perangkat lunak. Bukan
mengetahui bagaimana mengukur kemajuan nyata, kita sering menggunakan ukuran pengganti, laju
dari pengeluaran sumber daya. Misalnya, sebuah proyek yang memiliki anggaran 100 orang-
hari dianggap 50% selesai setelah 50 orang-hari dihabiskan. Dengan ketat
berbicara, kami kemudian mengacaukan kecepatan dengan kemajuan. Karena pengukuran yang tidak
tepat
10 PERKENALAN
kemajuan dan kebiasaan meremehkan upaya total, masalah menumpuk seiring
berjalannya waktu.
Sistem fisik seringkali kontinu dalam arti bahwa perubahan kecil pada spesifikasi
menyebabkan perubahan kecil pada produk. Ini tidak benar dengan perangkat
lunak. Perubahan kecil dalam spesifikasi perangkat lunak dapat menyebabkan
perubahan besar pada perangkat lunak itu sendiri. Dengan cara yang sama,
kesalahan kecil dalam perangkat lunak mungkin memiliki efek yang cukup besar.
Roket luar angkasa Mariner ke Venus misalnya hilang karena kesalahan pengetikan
dalam program FORTRAN. Pada tahun 1998, Mars Climate Orbiter hilang, karena
satu tim pengembang menggunakan satuan bahasa Inggris seperti inci dan kaki,
sementara tim lain menggunakan satuan metrik.
Kami juga dapat menarik perbandingan antara rekayasa perangkat lunak dan
ilmu komputer. Ilmu komputer muncul sebagai disiplin yang terpisah pada 1960-an.
Ini terpisah dari matematika dan sangat dipengaruhi oleh matematika. Topik yang
dipelajari dalam ilmu komputer, seperti kompleksitas algoritme, bahasa formal, dan
semantik bahasa pemrograman, memiliki rasa matematika yang kuat. Tesis PhD
dalam ilmu komputer selalu berisi teorema dengan bukti yang menyertainya.
Karena bidang rekayasa perangkat lunak muncul dari ilmu komputer, ia memiliki
kecenderungan yang sama untuk fokus pada aspek bersih pengembangan
perangkat lunak yang dapat diformalkan, baik dalam pengajaran maupun penelitian.
Kami dulu berasumsi bahwa persyaratan dapat sepenuhnya dinyatakan sebelum
proyek dimulai, berkonsentrasi pada sistem yang dibangun dari awal, dan
mengabaikan kenyataan memperdagangkan aspek kualitas dengan anggaran yang
tersedia. Belum lagi parit pemeliharaan perangkat lunak.
Rekayasa perangkat lunak dan ilmu komputer memang memiliki banyak
tumpang tindih. Praktik rekayasa perangkat lunak bagaimanapun juga harus
berurusan dengan hal-hal seperti manajemen proyek pengembangan besar, faktor
manusia (mengenai tim pengembangan dan calon pengguna sistem) dan estimasi
dan kontrol biaya. Insinyur perangkat lunak harus insinyur perangkat lunak.
Rekayasa perangkat lunak memiliki banyak kesamaan baik dengan bidang
teknik lainnya maupun dengan ilmu komputer. Ia juga memiliki wajahnya sendiri
dalam banyak hal.
1.2 Tahapan dalam

Pengembangan Perangkat
Lunak
Saat membangun rumah, pembangunnya tidak dimulai dengan menumpuk batu
bata. Sebaliknya, persyaratan dan kemungkinan klien dianalisis terlebih dahulu,
dengan mempertimbangkan faktor-faktor seperti struktur keluarga, hobi, keuangan,
dan sejenisnya. Arsitek mempertimbangkan faktor-faktor ini saat mendesain rumah.
Hanya setelah desain disetujui barulah konstruksi yang sebenarnya dimulai.
Adalah bijaksana untuk bertindak dengan cara yang sama saat membangun
perangkat lunak. Pertama, masalah yang akan dipecahkan dianalisis dan
persyaratan dijelaskan dengan cara yang sangat tepat. Kemudian dibuat desain
berdasarkan kebutuhan tersebut. Terakhir, proses konstruksi, yaitu pemrograman
sebenarnya dari solusi, dimulai. Ada sejumlah fase yang dapat dibedakan dalam
pengembangan perangkat lunak. Fase-fase yang dibahas dalam buku ini
digambarkan pada gambar 1.2.
1.2. TAHAP DALAM PENGEMBANGAN 11
PERANGKAT LUNAK
Gambar 1.2 Tampilan sederhana dari pengembangan perangkat lunak
Itu model proses digambarkan pada gambar 1.2 agak sederhana. Pada kenyataannya, banyak hal
akan terjadi
biasanya menjadi lebih kompleks. Misalnya, fase desain sering dibagi menjadi global,
fase desain arsitektur dan fase desain terperinci, dan seringkali berbagai fase uji
dibedakan. Elemen dasar, bagaimanapun, tetap seperti yang diberikan pada gambar 1.2. Ini
fase harus dilalui dalam setiap proyek. Tergantung jenis proyeknya
dan lingkungan kerja, skema yang lebih rinci mungkin diperlukan.
Pada Gambar 1.2, fase telah digambarkan secara berurutan. Untuk proyek tertentu ini
kegiatan tidak harus dipisahkan secara ketat seperti yang ditunjukkan di sini. Mereka mungkin dan
biasanya akan tumpang tindih. Misalnya, sangat mungkin untuk memulai penerapannya
bagian dari sistem sementara beberapa bagian lainnya belum sepenuhnya dirancang.
Seperti yang akan kita lihat di bagian 1.3, tidak ada perkembangan linier yang ketat dari persyaratan
teknik ke desain, dari desain ke implementasi, dll. Mundur ke sebelumnya
fase terjadi, karena kesalahan ditemukan atau persyaratan berubah. Satu lebih baik
12 PERKENALAN
pikirkan fase-fase ini sebagai rangkaian alur kerja. Sejak awal, sebagian besar
sumber daya dihabiskan untuk alur kerja rekayasa persyaratan. Kemudian, upaya
beralih ke alur kerja implementasi dan pengujian.
Di bawah ini, deskripsi singkat diberikan dari masing-masing elemen dasar dari
gambar 1.2. Berbagai model proses alternatif akan dibahas dalam bab 3.
Model-model alternatif ini dihasilkan dari kritik yang dapat dibenarkan terhadap
model pemikiran sederhana yang digambarkan pada gambar 1.2. Satu-satunya
tujuan dari model sederhana kami adalah untuk menyediakan penataan topik yang
memadai untuk ditangani. Fase pemeliharaan dibahas lebih lanjut di bagian 1.3.
Semua elemen model proses kami akan diperlakukan lebih rumit di bab selanjutnya.
Rekayasa kebutuhan. Tujuan dari tahap rekayasa kebutuhan adalah untuk

mendapatkan gambaran lengkap tentang masalah yang harus dipecahkan dan
persyaratan yang diajukan oleh dan pada lingkungan di mana sistem akan
berfungsi. Persyaratan yang ditentukan oleh lingkungan dapat berupa perangkat
keras dan perangkat lunak pendukung atau jumlah calon pengguna sistem yang
akan dikembangkan. Sebagai alternatif, analisis persyaratan dapat menyebabkan
kendala tertentu yang dikenakan pada perangkat keras yang belum diperoleh atau
organisasi tempat sistem berfungsi. Uraian masalah yang akan dipecahkan
mencakup hal-hal seperti:
– fungsi perangkat lunak yang akan dikembangkan;
– kemungkinan perluasan sistem di masa mendatang;
– jumlah dan jenis dokumentasi yang diperlukan;
– waktu respons dan persyaratan kinerja sistem lainnya.
Bagian dari rekayasa kebutuhan adalah a studi kelayakan. Tujuan dari studi
kelayakan adalah untuk menilai apakah ada solusi untuk masalah yang layak secara
ekonomi dan teknis.
Semakin hati-hati kita selama fase rekayasa kebutuhan, semakin besar
kemungkinan bahwa sistem pamungkas akan memenuhi harapan. Untuk itu,
berbagai orang (antara lain pelanggan, calon pengguna, desainer, dan pemrogram)
yang terlibat harus berkolaborasi secara intensif. Orang-orang ini seringkali memiliki
latar belakang yang sangat berbeda, yang tidak memudahkan komunikasi.
Dokumen di mana hasil dari kegiatan ini diletakkan disebutspesifikasi
kebutuhan.
Desain. Selama fase desain, model dari keseluruhan sistem dikembangkan yang,
ketika dikodekan dalam beberapa bahasa pemrograman, memecahkan masalah
bagi pengguna. Untuk tujuan ini, masalahnya didekomposisi menjadi bagian-bagian
yang dapat dikelola yang disebut komponen; fungsi dari komponen tersebut dan
antarmuka di antara mereka ditentukan dengan cara yang sangat tepat. Fase
desain sangat penting. Rekayasa dan desain persyaratan kadang-kadang dilihat
sebagai pengantar pemrograman yang mengganggu, yang sering terlihat
PERANGKAT LUNAK
sebagai karya nyata. Sikap ini memiliki pengaruh yang sangat negatif pada kualitas
perangkat lunak yang dihasilkan.
Keputusan desain awal berdampak besar pada kualitas sistem akhir.
Keputusan desain awal ini dapat ditangkap dalam deskripsi global sistem,
yaitu Arsitektur. Arsitektur selanjutnya dapat dievaluasi, berfungsi sebagai template
untuk pengembangan keluarga sistem serupa, atau digunakan sebagai kerangka untuk
pengembangan komponen yang dapat digunakan kembali. Dengan demikian, deskripsi arsitektur dari
sistem adalah dokumen tonggak penting dalam pengembangan perangkat lunak saat ini
proyek.
Selama fase desain kami mencoba untuk memisahkan Apa dari Bagaimana. Kami berkonsentrasi
pada masalah dan tidak boleh membiarkan diri kita terganggu oleh masalah implementasi.
Hasil dari fase desain, (teknis) spesifikasi, berfungsi sebagai awalan
poin untuk tahap implementasi. Kalau spesifikasinya sifatnya formal juga bisa
digunakan untuk memperoleh bukti kebenaran.
Penerapan. Selama fase implementasi, kami berkonsentrasi pada individu

komponen. Titik awal kami adalah spesifikasi komponen. Ini sering diperlukan
untuk memperkenalkan fase 'desain' ekstra, langkah dari spesifikasi komponen ke
kode yang dapat dieksekusi seringkali terlalu besar. Dalam kasus seperti itu, kami dapat mengambil
keuntungan dari
beberapa notasi seperti bahasa pemrograman tingkat tinggi, seperti a kodesemu. (A
pseudocode adalah sejenis bahasa pemrograman. Sintaks dan semantiknya ada di
kurang ketat, sehingga algoritma dapat diformulasikan pada tingkat yang lebih tinggi, lebih abstrak,
tingkat.)
Penting untuk dicatat bahwa tujuan pertama seorang programmer adalah
pengembangan program yang terdokumentasi dengan baik, andal, mudah dibaca, fleksibel, benar.
Tujuannya adalah bukan untuk menghasilkan program yang sangat efisien penuh trik. Kami akan
kembali
ke banyak dimensi kualitas perangkat lunak dalam bab 6.
Selama fase desain, struktur global dipaksakan melalui pendahuluan
komponen dan antarmuka mereka. Dalam bahasa pemrograman yang lebih klasik, banyak
struktur ini cenderung hilang dalam transisi dari desain ke kode. Lebih baru
bahasa pemrograman menawarkan kemungkinan untuk mempertahankan struktur ini dalam kode akhir
melalui konsep modul atau kelas.
Hasil dari fase implementasi adalah program yang dapat dieksekusi.
Pengujian. Sebenarnya, salah jika mengatakan bahwa pengujian adalah fase setelah implementasi.
Ini menunjukkan bahwa Anda tidak perlu repot dengan pengujian sampai implementasi selesai.
Ini tidak benar. Bahkan adil untuk mengatakan bahwa ini adalah salah satu kesalahan terbesar yang
Anda bisa
membuat.
Perhatian harus diberikan pada pengujian bahkan selama rekayasa persyaratan
fase. Selama fase berikutnya, pengujian dilanjutkan dan disempurnakan. Sebelumnya
bahwa kesalahan terdeteksi, semakin murah untuk memperbaikinya.
Pengujian pada batas fase hadir dalam dua rasa. Kita harus menguji bahwa
transisi antara fase berikutnya benar (ini dikenal sebagai verifikasi). Kami
juga harus memeriksa apakah kami masih berada di jalur yang benar dalam hal memenuhi pengguna
14 PERKENALAN
persyaratan (validasi). Hasil penambahan kegiatan verifikasi dan validasi pada

model linier gambar 1.2 menghasilkan apa yang disebut model air terjun
pengembangan perangkat lunak (lihat juga bab 3).
Pemeliharaan. Setelah pengiriman perangkat lunak, sering terjadi kesalahan yang
masih tidak terdeteksi. Jelas, kesalahan ini harus diperbaiki. Selain itu, penggunaan
sistem yang sebenarnya dapat menyebabkan permintaan untuk perubahan dan
peningkatan. Semua jenis perubahan ini dilambangkan dengan istilah pemeliharaan
yang agak disayangkan. Pemeliharaan dengan demikian menyangkut semua
aktivitas yang diperlukan untuk menjaga agar sistem tetap beroperasi setelah
dikirimkan ke pengguna.
Kegiatan yang mencakup semua fase adalah manajemen proyek. Seperti proyek
lainnya, proyek pengembangan perangkat lunak harus dikelola dengan baik untuk
memastikan bahwa produk dikirimkan tepat waktu dan sesuai anggaran. Visibilitas
dan karakteristik kontinuitas pengembangan perangkat lunak, serta fakta bahwa
banyak proyek pengembangan perangkat lunak dilakukan dengan pengalaman
sebelumnya yang tidak mencukupi, sangat menghambat pengendalian proyek.
Banyak contoh proyek pengembangan perangkat lunak yang gagal memenuhi
jadwal mereka memberikan banyak bukti fakta bahwa kami belum menangani
masalah ini dengan memuaskan. Bab 2--8 berurusan dengan aspek-aspek utama
manajemen proyek perangkat lunak, seperti perencanaan proyek, organisasi tim,
masalah kualitas, perkiraan biaya dan jadwal.
Kegiatan penting yang tidak diidentifikasi secara terpisah adalah dokumentasi.

Sejumlah bahan kunci dari dokumentasi proyek perangkat lunak akan diuraikan
pada bab-bab selanjutnya. Komponen utama dokumentasi sistem meliputi rencana
proyek, rencana kualitas, spesifikasi kebutuhan, deskripsi arsitektur, dokumentasi
desain, dan rencana pengujian. Untuk proyek yang lebih besar, sejumlah besar
upaya harus dikeluarkan untuk mendokumentasikan proyek dengan benar. Upaya
dokumentasi harus dimulai sejak awal proyek. Dalam praktiknya, dokumentasi
seringkali dipandang sebagai item penyeimbang. Karena banyak proyek terdesak
waktu, dokumentasi cenderung mendapatkan yang terburuk. Pemelihara dan
pengembang perangkat lunak mengetahui hal ini, dan menyesuaikan cara kerja
mereka. Sebagai patokan, Lethbridge et al. (2003) menyatakan bahwa, semakin
dekat dengan kode, semakin akurat dokumentasi yang harus digunakan oleh
perekayasa perangkat lunak. Dokumen persyaratan yang kedaluwarsa dan
dokumentasi tingkat tinggi lainnya mungkin masih memberikan petunjuk berharga.
Mereka berguna untuk orang yang harus belajar tentang sistem baru atau harus
mengembangkan test case, misalnya. Dokumentasi tingkat rendah yang ketinggalan
zaman tidak berguna, dan membuat pemrogram berkonsultasi dengan kode
daripada dokumentasinya. Karena sistem akan mengalami perubahan setelah
pengiriman, karena kesalahan yang tidak terdeteksi atau perubahan kebutuhan
pengguna, dokumentasi yang tepat dan terkini sangat penting selama pemeliharaan.
Elemen dokumentasi yang sangat penting adalah dokumentasi pengguna.
Pengembangan perangkat lunak harus berorientasi pada tugas dalam arti bahwa
perangkat lunak yang akan dikirimkan harus mendukung pengguna dalam
lingkungan tugas mereka. Demikian juga, dokumentasi pengguna harus berorientasi
pada tugas. Manual pengguna seharusnya tidak hanya menggambarkan fitur
sistem, mereka harus membantu orang menyelesaikan sesuatu (Rettig, 1991). Kami
PERANGKAT LUNAK
tidak bisa hanya mengandalkan struktur antarmuka untuk mengatur dokumentasi pengguna
(sama seperti manual referensi bahasa pemrograman bukanlah sumber yang tepat untuk
belajar memprogram).
Gambar 1.3 menggambarkan upaya relatif yang dikeluarkan untuk berbagai aktivitas hingga
pengiriman
dari sistem. Dari data ini muncul tren yang sangat jelas, yang disebut 40--20--40
aturan: hanya 20% dari upaya yang dihabiskan untuk benar-benar memprogram (mengkode) sistem,
sedangkan tahapan sebelumnya (persyaratan rekayasa dan desain) dan pengujian masing-masing
mengkonsumsi sekitar 40% dari total usaha.
Gambar 1.3 Upaya relatif untuk berbagai kegiatan
Tergantung pada kondisi batas tertentu, sifat-sifat sistem menjadi

dibangun, dan sejenisnya, variasi aturan ini dapat ditemukan. Untuk pengembangan berulang
proyek, perbedaan antara rekayasa persyaratan, desain, implementasi
dan pengujian (unit) menjadi kabur, misalnya. Untuk sebagian besar proyek, bagaimanapun,
aturan praktis ini cukup bisa diterapkan.
Ini tidak berarti bahwa aturan 40--20--40 adalah aturan yang harus diperjuangkan. Kesalahan
dibuat selama rekayasa persyaratan adalah yang paling mahal untuk diperbaiki (lihat
juga bab tentang pengujian). Jauh lebih baik untuk memasukkan lebih banyak energi ke dalam
persyaratan
fase rekayasa, daripada mencoba menghilangkan kesalahan selama pengujian yang memakan waktu
fase atau, lebih buruk lagi, selama pemeliharaan. Menurut (Boehm, 1987b), berhasil
proyek mengikuti distribusi 60--15--25: 60% persyaratan rekayasa dan desain,
Implementasi 15% dan pengujian 25%. Pesannya jelas: semakin lama Anda menunda
coding, semakin awal Anda selesai.
Gambar 1.3 tidak menunjukkan sejauh mana upaya pemeliharaan. Ketika kita mempertimbangkan
total biaya sistem perangkat lunak selama masa pakainya, ternyata, rata-rata,
pemeliharaan saja menghabiskan 50--75% dari biaya ini; lihat juga gambar 1.1. Dengan demikian,
pemeliharaan saja menghabiskan lebih banyak daripada berbagai fase pengembangan yang diambil
bersama.
16 PERKENALAN
1.3 Pemeliharaan atau

Evolusi
Satu-satunya hal yang kami jaga adalah kepuasan pengguna
(Lehman, 1980)
Setelah perangkat lunak dikirimkan, biasanya masih mengandung kesalahan yang,

setelah ditemukan, harus diperbaiki. Perhatikan bahwa jenis perawatan ini tidak
disebabkan oleh pemakaian. Sebaliknya, ini menyangkut perbaikan cacat
tersembunyi. Jenis perbaikan ini sebanding dengan yang ditemui setelah rumah
yang baru dibangun pertama kali ditempati.
Cerita menjadi sangat berbeda jika kita mulai berbicara tentang perubahan atau
peningkatan sistem. Mengecat ulang kantor kita atau memperbaiki atap rumah kita
yang bocor disebut perawatan. Menambahkan sayap ke kantor kami jarang disebut
pemeliharaan. Ini lebih dari permainan sepele dengan kata-kata. Selama masa
hidup total sistem perangkat lunak, lebih banyak uang dihabiskan untuk memelihara
sistem itu daripada pengembangan awal. Jika semua pengeluaran ini hanya
berkaitan dengan perbaikan kesalahan yang dibuat selama salah satu fase
pengembangan, bisnis kami akan berjalan sangat buruk. Untungnya, bukan itu
masalahnya.
Kami membedakan empat jenis kegiatan pemeliharaan:
– perbaikan pemeliharaan -- perbaikan kesalahan yang sebenarnya;
– adaptif pemeliharaan -- menyesuaikan perangkat lunak dengan perubahan lingkungan,

seperti perangkat keras baru atau rilis berikutnya dari sistem operasi atau basis data;
– perfeksionis pemeliharaan -- menyesuaikan perangkat lunak dengan

persyaratan pengguna baru atau yang diubah, seperti fungsi tambahan yang
akan disediakan oleh sistem. Perawatan sempurna juga mencakup pekerjaan
untuk meningkatkan kinerja sistem atau untuk meningkatkan antarmuka
penggunanya;
– preventif pemeliharaan -- meningkatkan kemampuan pemeliharaan sistem di

masa mendatang. Memperbarui dokumentasi, menambahkan komentar, atau
meningkatkan struktur modular sistem adalah contoh kegiatan pemeliharaan
preventif.
Hanya kategori pertama yang berhak disebut pemeliharaan. Namun, kategori ini
hanya menyumbang sekitar seperempat dari total upaya pemeliharaan. Kira-kira
seperempat dari upaya pemeliharaan menyangkut mengadaptasi perangkat lunak
untuk perubahan lingkungan, sementara setengah dari biaya pemeliharaan
dihabiskan untuk perubahan untuk mengakomodasi perubahan kebutuhan
pengguna, yaitu peningkatan sistem (lihat gambar 1.4).Perubahan dalam lingkungan
sistem dan persyaratan pengguna tidak dapat dihindari. Model perangkat lunak
adalah bagian dari realitas, dan realitas berubah, suka atau tidak suka. Jadi
perangkat lunak juga harus berubah. Dia memiliki untuk berkembang. Sebagian
besar dari apa yang biasa kita sebut pemeliharaan sebenarnya adalah evolusi.
Pemeliharaan karena kebutuhan pengguna baru terjadi baik pada sistem berkualitas
tinggi maupun rendah. Sebuah sistem yang sukses memerlukan fungsionalitas baru
yang tidak terduga, karena penggunaannya oleh banyak pengguna yang puas.
Sistem yang kurang berhasil harus diadaptasi untuk memuaskan pelanggannya.
1.4. DARI PARU 17
Gambar 1.4 Sebaran kegiatan pemeliharaan
Hasilnya adalah proses pengembangan perangkat lunak menjadi siklik, demikian

ungkapannya siklus hidup perangkat lunak. Backtracking ke fase sebelumnya,
disinggung di atas, tidak hanya terjadi saat maintenance. Selama fase lain, kami
juga akan mengulangi fase sebelumnya dari waktu ke waktu. Selama desain,
mungkin ditemukan bahwa spesifikasi persyaratan tidak lengkap atau berisi
persyaratan yang bertentangan. Selama pengujian, kesalahan yang diperkenalkan
pada fase implementasi atau desain dapat muncul. Dalam kasus ini dan serupa,
iterasi fase sebelumnya diperlukan. Kita akan kembali ke siklus proses
pengembangan perangkat lunak ini di bab 3, saat kita membahas model alternatif
dari proses pengembangan perangkat lunak.
1.4 Dari Parit

Dan begitulah cara semua takhayul, baik dalam astrologi, mimpi, pertanda, ketuhanan
putusan atau sejenisnya; di mana pria, yang senang dengan kesombongan seperti itu,
menandai peristiwa-peristiwa itu
ketika mereka terpenuhi, tetapi ketika mereka gagal, meskipun ini lebih sering terjadi,
pengabaian dan
melewati mereka. Tetapi dengan jauh lebih halus kerusakan ini menyusup ke dalam filsafat
dan sains; di mana kesimpulan pertama mewarnai dan menyesuaikan dengan
sendiri semua yang datang setelahnya, meskipun jauh lebih sehat dan lebih baik. Selain itu,
terlepas dari itu
kesenangan dan kesia-siaan yang telah saya uraikan, itu adalah kesalahan yang aneh dan
terus-menerus dari
intelek manusia lebih tergerak dan bersemangat oleh afirmatif daripada negatif; sedangkan
itu harus dengan benar menahan diri dengan sikap acuh tak acuh terhadap keduanya.
Memang di
pembentukan aksioma yang benar, contoh negatif lebih kuat dari keduanya.
Sir Francis Bacon, The New Organon, Kata Mutiara XLVI (1611) .
Studi kasus sejarah mengandung kekayaan kebijaksanaan tentang sifat desain dan
metode rekayasa.
(Petroski, 1994)
Dalam bukunya yang luar biasa Paradigma Desain, Sejarah Kasus Kesalahan dan Penilaian dalam
Rekayasa,
Henri Petroski memberi tahu kita tentang beberapa kesuksesan teknik terbesar dan, terutama,
18 PERKENALAN
kegagalan sepanjang masa. Beberapa kisah kegagalan tentang profesi kami juga
muncul. Empat di antaranya dibahas di bagian ini.
Kisah-kisah ini menarik karena mengajarkan kita bahwa rekayasa perangkat
lunak memiliki banyak sisi. Kegagalan dalam proyek pengembangan perangkat
lunak seringkali tidak satu dimensi hanya disebabkan oleh kesalahan teknis dalam
beberapa rutinitas. Mereka tidak hanya disebabkan oleh manajemen yang buruk.
Mereka tidak hanya hasil dari masalah komunikasi manusia. Ini seringkali
merupakan kombinasi dari banyak slip kecil, yang terakumulasi dari waktu ke waktu,
dan akhirnya menghasilkan kegagalan besar. Untuk memparafrasekan pepatah
terkenal Fred Brooks tentang proyek yang terlambat:
'Bagaimana sebuah proyek benar-benar mendapat masalah?'

'Satu slip pada satu waktu.'
Setiap cerita yang dibahas di bawah ini menunjukkan efek kumulatif. Keberhasilan
dalam pengembangan perangkat lunak tidak akan terjadi jika kita hanya
mempekerjakan pemrogram paling cerdas. Atau terapkan filosofi desain terbaru.
Atau dapatkan konsultasi pengguna yang paling ekstensif. Atau bahkan
mempekerjakan manajer terbaik. Anda harus melakukan semua itu. Dan bahkan
lebih.
1.4.1 Ariane 5, Penerbangan 501

Penerbangan perdana peluncur Ariane 5 berlangsung pada 4 Juni 1996. Setelah
sekitar 40 detik, pada ketinggian kurang dari 4 kilometer, peluncur pecah dan
meledak. Kerugian $500 juta ini pada akhirnya disebabkan oleh luapan konversi dari
a64-bit angka floating point ke bilangan bulat bertanda 16-bit. Dari sudut pandang
rekayasa perangkat lunak, kisah Ariane 5 menarik karena kegagalan dapat dikaitkan
dengan penyebab yang berbeda, pada tingkat pemahaman yang berbeda:
pengujian yang tidak memadai, penggunaan kembali yang salah, atau filosofi desain
yang salah.
Ketinggian peluncur dan pergerakannya di ruang angkasa diukur oleh Sistem
Referensi Inersia (SRI - Système de Référence Inertielle). Ada dua SRI yang
beroperasi secara paralel. Perangkat keras dan perangkat lunak mereka identik.
Sebagian besar perangkat keras dan perangkat lunak untuk SRI dipertahankan dari
Ariane 4. Konversi fatal terjadi pada perangkat lunak di SRI yang hanya berarti
sebelum lepas landas. Meskipun bagian dari perangkat lunak ini tidak berguna
setelah roket diluncurkan, ia terus bekerja selama beberapa detik. Persyaratan ini
dinyatakan lebih dari 10 tahun sebelumnya karena alasan yang agak aneh. Ini
memungkinkan untuk memulai ulang hitungan mundur dengan cepat, jika terputus
saat dekat dengan lepas landas. Persyaratan ini tidak berlaku untuk Ariane 5, tetapi
perangkat lunaknya dibiarkan tidak berubah -- lagipula, itu berhasil. Karena Ariane 5
jauh lebih cepat daripada Ariane4, roket mencapai kecepatan horizontal yang jauh
lebih tinggi dalam waktu singkat setelah lepas landas, yang mengakibatkan luapan
yang disebutkan di atas. Karena luapan ini, SRI pertama berhenti berfungsi. SRI
kedua kemudian diaktifkan, tetapi karena perangkat keras dan lunak kedua SRI
identik, SRI kedua juga gagal. Akibatnya, data yang salah dikirim dari SRI ke
komputer on-board.
1.4. DARI PARU 19
Berdasarkan data yang salah ini, defleksi nosel penuh diperintahkan. Ini
menyebabkan beban aerodinamis yang sangat tinggi yang menyebabkan terpisahnya booster dari
roket utama. Dan ini pada gilirannya memicu penghancuran diri peluncur.
Ada beberapa level di mana kegagalan Ariane 5 dapat dipahami dan
menjelaskan:
�
20 PERKENALAN
Salah satu malfungsi Therac-25 telah dikenal sebagai 'Malfunction54'. Seorang

pasien disiapkan untuk perawatan. Operator memasukkan data yang diperlukan
pada konsol di ruangan yang berdekatan. Saat melakukannya, dia membuat
kesalahan: dia mengetik 'x' (untuk mode sinar-X) alih-alih 'e' (untuk mode elektron).
Dia memperbaiki kesalahannya dengan memindahkan kursor ke bidang yang
sesuai, mengetikkan kode yang benar dan menekan tombol kembali beberapa kali
hingga kursor berada di baris perintah lagi. Dia kemudian menekan 'B' (beam on).
Mesin berhenti dan mengeluarkan pesan 'Masalah 54'. Pesan kesalahan khusus ini
menunjukkan dosis yang salah, terlalu tinggi atau terlalu rendah. Konsol
menunjukkan underdosis yang substansial. Operator tahu bahwa mesin sering
memiliki keanehan, dan ini biasanya dapat diselesaikan hanya dengan menekan 'P'
(lanjutkan). Jadi dia melakukannya. Pesan kesalahan yang sama muncul lagi.
Biasanya, operator akan melakukan kontak audio dan video dengan pasien di ruang
perawatan. Namun kali ini tidak: audionya rusak dan videonya dimatikan. Kemudian
diperkirakan bahwa pasien telah menerima 16.000--25.000 rad pada permukaan
yang sangat kecil, bukannya dosis yang dimaksudkan sebesar 180 rad. Pasien
menjadi sakit parah dan meninggal lima bulan kemudian.
Penyebab kejadian berbahaya ini ditelusuri kembali ke perangkat lunak yang
mengoperasikan mesin radiasi. Setelah operator selesai memasukkan data,
pengaturan fisik mesin dapat dimulai. Pembengkokan magnet membutuhkan waktu
sekitar delapan detik. Setelah magnet ditempatkan pada posisinya, ia kembali
memeriksa apakah ada yang berubah. Jika operator berhasil melakukan perubahan
Dan kembalikan kursor ke posisi baris perintah dalam delapan detik yang diperlukan
untuk menyetel magnet, sebagian dari perubahan ini akan mengakibatkan
perubahan dalam parameter sistem internal, tetapi sistem tetap 'berpikir' bahwa
tidak ada yang terjadi dan terus berlanjut. Dengan konsekuensi seperti yang
dijelaskan di atas.
Kecelakaan seperti ini dilaporkan ke Federal Drugs Administration (FDA). FDA
meminta produsen untuk mengambil tindakan yang tepat. 'Perbaikan' yang
disarankan adalah sebagai berikut:
Efektif segera, dan sampai pemberitahuan lebih lanjut, tombol yang
digunakan untuk memindahkan kursor kembali melalui urutan resep
(yaitu kursor 'UP' bertuliskan panah menunjuk ke atas) tidak boleh
digunakan untuk mengedit atau tujuan lain.
Untuk menghindari penggunaan kunci ini secara tidak disengaja, tutup
kunci harus dilepas dan kontak sakelar dipasang pada posisi terbuka
dengan pita listrik atau bahan isolasi lainnya. . . .
Menonaktifkan kunci ini berarti bahwa jika ada data resep yang
dimasukkan salah, maka perintah reset 'R' harus digunakan dan
seluruh resep dimasukkan kembali.
FDA tidak membeli obat ini. Secara khusus, mereka menilai nada notifikasi tidak
sepadan dengan urgensi untuk melakukannya. Diskusi antara FDA dan pabrikan
berlanjut selama beberapa waktu sebelum tanggapan yang memadai diberikan
untuk kegagalan Therac-25 ini dan lainnya.
1.4. DARI PARU 21
Mesin Therac-25 dan perangkat lunaknya berevolusi dari model sebelumnya

kurang canggih. Di versi perangkat lunak sebelumnya, misalnya, hal itu tidak mungkin dilakukan
untuk bergerak ke atas dan ke bawah layar untuk mengubah masing-masing bidang. Operator
memperhatikan itu
perlakuan yang berbeda seringkali membutuhkan data yang hampir sama, yang harus dimasukkan
semuanya
lagi. Untuk meningkatkan kegunaan, fitur untuk memindahkan kursor dan mengubah
bidang individu ditambahkan. Rupanya, keramahan pengguna mungkin bertentangan dengan
keamanan.
Pada model sebelumnya juga, posisi meja putar dan peralatan lainnya benar
dipastikan dengan interlock elektromekanis sederhana. Interlock ini adalah hal yang umum
mekanisme untuk menjamin keselamatan. Misalnya, mereka digunakan di lift untuk memastikannya
pintu tidak dapat dibuka jika lift berada di antara lantai. Di Therac-25, ini
perangkat keamanan mekanis digantikan oleh perangkat lunak. Perangkat lunak demikian dibuat
menjadi satu titik kegagalan. Terlalu percaya diri pada perangkat lunak ini berkontribusi pada
Kecelakaan Therac-25, bersama dengan praktik rekayasa perangkat lunak yang tidak memadai dan
reaksi manajemen yang tidak memadai terhadap insiden.
1.4.3 Layanan Ambulans London

Layanan Ambulans London (LAS) menangani lalu lintas ambulans di
GreaterLondon. Ini mencakup area seluas lebih dari 600 mil persegi dan membawa
lebih dari 5000 pasien per hari di 750 kendaraan. LAS menerima lebih dari 2000
panggilan telepon per hari, termasuk lebih dari 1300 panggilan darurat. Sistem yang
kita diskusikan di sini adalah sistem pengiriman berbantuan komputer (CAD). Sistem
CAD semacam itu memiliki fungsi sebagai berikut:
�
22 PERKENALAN
diputuskan untuk kembali ke mode operasi semi-manual. Pada tanggal 4 November
1992, sistem mengalami crash. Otoritas Kesehatan Daerah membentuk Tim Inkuiri
untuk menyelidiki kegagalan dan sejarah yang menyebabkannya. Mereka datang
dengan laporan setebal 80 halaman, yang terbaca seperti novel ketegangan. Di
bawah ini, kami menyoroti beberapa masalah yang diangkat dalam laporan ini.
Sistem CAD yang dibayangkan akan menjadi usaha besar. Tidak ada layanan
darurat lain yang berusaha sejauh ini. Rencananya adalah beralih dari proses yang
sepenuhnya manual -- di mana formulir diisi dan dipindahkan dari satu karyawan ke
karyawan berikutnya melalui sabuk konveyor -- untuk menyelesaikan otomatisasi,
dalam satu kesempatan. Skema itu sangat ambisius. Para peserta tampaknya
belum sepenuhnya menyadari risiko yang mereka ambil.
Jauh sebelum proyek benar-benar dimulai, sebuah firma konsultan manajemen
telah dimintai saran. Mereka menyarankan bahwa solusi paket akan dikenakan
biaya $1.5Man dan ambil 19 bulan. Laporan mereka juga menyatakan bahwa jika
solusi paket tidak dapat ditemukan, estimasi harus ditingkatkan secara signifikan.
Akhirnya, solusi non-paket dipilih, tetapi hanya nomor dari laporan ini yang diingat,
atau begitulah tampaknya.
Iklan tersebut menghasilkan balasan dari 35 perusahaan. Spesifikasi dan jadwal
selanjutnya didiskusikan dengan perusahaan-perusahaan ini. Jadwal yang diusulkan
adalah 11 bulan (ini bukan salah ketik). Meskipun banyak pemasok menyampaikan
kekhawatiran tentang jadwal tersebut, mereka diberitahu bahwa itu tidak dapat
dinegosiasikan. Akhirnya, 17 pemasok memberikan proposal lengkap. Tender
terendah, kira-kira $1M, dipilih. Tender ini adalah tentang $700.000 lebih murah dari
penawaran terendah berikutnya. Sepertinya tidak ada yang mempertanyakan
perbedaan besar ini. Proposal yang dipilih secara dangkal menunjukkan bahwa
perusahaan memiliki pengalaman dalam merancang sistem untuk layanan darurat.
Ini bukan kebohongan: mereka telah mengembangkan sistem administrasi untuk
layanan semacam itu. Sistem LAS juga jauh lebih besar dari apa pun yang pernah
mereka tangani sebelumnya.
Sistem yang diusulkan akan berdampak cukup signifikan pada cara kru
ambulans melakukan pekerjaan mereka. Oleh karena itu, sangat penting untuk
memiliki kerja sama penuh mereka. Jika kru tidak menekan tombol yang tepat pada
waktu dan urutan yang tepat, kekacauan dapat terjadi. Namun, hanya ada sedikit
keterlibatan pengguna selama proses rekayasa kebutuhan.
Sistem CAD yang dimaksudkan akan beroperasi dengan cara yang benar-benar
objektif dan tidak memihak dan akan selalu memobilisasi sumber daya yang optimal
untuk setiap kejadian. Ini akan mengatasi banyak praktik kerja yang ada saat ini
yang dianggap sudah ketinggalan zaman oleh manajemen dan tidak sesuai dengan
kepentingan LAS. Misalnya, sistem baru akan mengalokasikan sumber daya
terdekat yang tersedia terlepas dari stasiun asalnya. Skenario berikut dapat terjadi:
�
1.4. DARI PARU 23
�
24 PERKENALAN
Audit semacam itu dilakukan oleh pihak independen. Perlindungan ini berfungsi
untuk membangun kepercayaan pada hasilnya.
Tapi bagaimana jika pemilu ini didukung oleh komputer? Sebagai pemilih, Anda
cukup menekan sebuah tombol. Tapi apa selanjutnya? Pencatatan dan
penghitungan disembunyikan. Bagaimana Anda tahu suara Anda tidak diutak-atik?
Bagaimana penipuan dapat dihindari? Untuk individu tersebut, diperlukan surat
suara pemilih, misalnya selembar kertas yang mirip dengan tanda terima ATM, yang
berfungsi untuk memverifikasi pilihan pemilih. Surat suara dari semua pemilih
selanjutnya dapat digunakan dalam audit independen atas hasil pemilu. Sebagian
besar sistem pemilihan otomatis saat ini tidak memberikan perlindungan ini.
Bagaimana jika kita melangkah lebih jauh, dan memberi pemilih kita aplikasi web
untuk memberikan suara mereka? Di bawah ini adalah cerita tentang sistem nyata
semacam ini. Aplikasi ini dikembangkan di Jawa. Karena peraturan pemerintah,
model pemungutan suara yang diterapkan meniru model tradisional. Aplikasi ini
memiliki daftar pemilih yang berisi identitas semua pemilih, dan kotak suara tempat
menyimpan suara. Salah satu aturan yang harus dipatuhi sistem adalah anonimitas:
suara di kotak suara tidak boleh dilacak ke nama dalam daftar pemilih. Peraturan
lain menyangkut keamanan: kedua register harus disimpan secara terpisah.
Desain teknis mempertimbangkan dua database terpisah, satu untuk pemilih
dan satu lagi untuk surat suara. Menempatkan suara dan menandai pemilih sebagai
'telah memilih' harus dilakukan dalam satu transaksi: baik kedua tindakan dilakukan,
atau tidak satu pun dari keduanya. Desain ini memenuhi persyaratan kebenaran:
jumlah suara di kotak suara sama dengan jumlah pemilih yang ditandai 'telah
memilih'.
Setidaknya, inilah yang kami harapkan. Pengujian sistem menunjukkan bahwa,
tampaknya pada saat-saat yang serampangan, ada lebih banyak suara di kotak
suara daripada pemilih yang ditandai sebagai 'telah memilih'. Jadi sistem
memungkinkan pemilih lebih dari satu suara.
Melihat ke balik terpal, kesalahan pengkodean terungkap dalam proses
pemungutan suara. Bagian dari algoritme berjalan sebagai berikut:
1. Identifikasi pemilih.
2. Cocokkan pemilih dengan entri dalam daftar.
3. Jika ditemukan kecocokan, periksa apakah dia belum memberikan

suara.
Tes pada langkah terakhir memiliki bentuk
pemilih.getIdentifi
asi()==identifikasi
asi
1.5. ETIKA REKAYASA PERANGKAT LUNAK 25
1.5 Etika Rekayasa

Perangkat Lunak
Misalkan Anda sedang menguji bagian dari sistem perangkat lunak besar. Anda menemukan beberapa
kesalahan dan
Anda pasti belum siap untuk menyampaikan. Namun, manajer Anda menekan Anda. Itu
jadwal sudah melorot beberapa minggu. Manajer Anda pada gilirannya ditekan
oleh atasannya. Pelanggan sangat menantikan pengiriman sistem. Manajer Anda
menyarankan agar Anda mengirimkan sistem apa adanya, melanjutkan pengujian, dan mengganti
sistem dengan versi yang lebih baik dalam bulan berikutnya. Bagaimana Anda akan bereaksi terhadap
hal ini
skema? Apakah Anda akan menyerah begitu saja? Berdebat dengan manajer Anda? Pergi ke bosnya?
Pergi ke
pelanggan?
Pengembangan sistem perangkat lunak yang kompleks melibatkan banyak orang: perangkat lunak
pengembang, penguji, manajer teknis, manajer umum, pelanggan, dll. Di dalamnya
organisasi sementara, hubungan antar individu seringkali asimetris:
satu orang yang berpartisipasi dalam hubungan memiliki lebih banyak pengetahuan tentang sesuatu
dari yang lain. Misalnya, seorang pengembang perangkat lunak memiliki lebih banyak pengetahuan
tentang
sistem yang sedang dibangun daripada manajernya. Hubungan asimetris seperti itu diminta
kepercayaan: jika pengembang mengatakan bahwa pengembangan beberapa komponen sesuai jadwal,
dia
manajer tidak bisa tidak mempercayai pesan ini. Setidaknya untuk sementara. Ketergantungan seperti
itu memberikan
peluang untuk perilaku tidak etis, seperti penggelapan. Ini lebih jadi jika
ada juga hubungan kekuasaan antara individu-individu ini.
Maka tidak mengherankan jika orang-orang dalam komunitas rekayasa perangkat lunak
telah membahas kode etik rekayasa perangkat lunak. Dua organisasi besar
profesional di bidang kami, IEEE Computer Society dan ACM, telah bekerja sama
mengembangkan kode seperti itu. Versi singkat dari kode ini diberikan pada gambar 1.5.
Dalam versi kode yang panjang, masing-masing prinsip disempurnakan lebih lanjut menjadi satu set
dari klausa. Beberapa klausul ini adalah pernyataan aspirasi: misalnya, perangkat lunak
insinyur harus berusaha untuk memahami sepenuhnya spesifikasi perangkat lunak yang digunakan
dia bekerja. Aspirasi mengarahkan perilaku profesional. Mereka membutuhkan etika yang signifikan
pertimbangan. Klausa lain mengungkapkan kewajiban para profesional secara umum: misalnya,
seorang insinyur perangkat lunak harus, seperti profesional lainnya, hanya menyediakan layanan di area
dari kompetensinya. Jenis klausa ketiga diarahkan pada perilaku profesional tertentu
dalam rekayasa perangkat lunak: misalnya, seorang insinyur perangkat lunak harus memastikan realistis
perkiraan biaya dan jadwal setiap proyek di mana dia bekerja.
Ada sejumlah klausul yang sesuai dengan situasi penguji
disebutkan di atas:
�
26 PERKENALAN
Pembukaan
Versi singkat dari kode merangkum aspirasi pada abstraksi tingkat tinggi.
Klausa yang disertakan dalam versi lengkap memberikan contoh dan detail
tentang bagaimana aspirasi ini mengubah cara kita bertindak sebagai
profesional rekayasa perangkat lunak. Tanpa aspirasi, detail dapat menjadi
legalistik dan membosankan; tanpa perincian, aspirasi bisa terdengar tinggi
tetapi kosong; bersama-sama, aspirasi dan detail membentuk kode yang
kohesif.
Insinyur perangkat lunak harus berkomitmen untuk membuat analisis,
spesifikasi, desain, pengembangan, pengujian, dan pemeliharaan perangkat
lunak sebagai profesi yang bermanfaat dan dihormati. Sesuai dengan komitmen
mereka terhadap kesehatan, keselamatan, dan kesejahteraan publik,
perekayasa perangkat lunak harus mematuhi Delapan Prinsip berikut:
1. Publik. Insinyur perangkat lunak harus bertindak secara konsisten dengan
kepentingan publik2. Klien dan majikan. Insinyur perangkat lunak harus
bertindak dengan cara yang sesuai dengan kepentingan klien dan pemberi kerja
mereka sesuai dengan kepentingan publik
3. Produk. Insinyur perangkat lunak harus memastikan bahwa produk mereka
dan modifikasi terkait memenuhi standar profesional setinggi mungkin
4. Pertimbangan. Insinyur perangkat lunak harus menjaga integritas dan
independensi dalam penilaian profesional mereka
5. Pengelolaan. Manajer dan pemimpin rekayasa perangkat lunak harus
berlangganan dan mempromosikan pendekatan etis untuk manajemen
pengembangan dan pemeliharaan perangkat lunak
6. Profesi. Insinyur perangkat lunak harus memajukan integritas dan reputasi
profesi yang konsisten dengan kepentingan publik
7. Rekan kerja. Insinyur perangkat lunak harus adil dan mendukung kolega
mereka
8. Diri sendiri. Insinyur perangkat lunak harus berpartisipasi dalam
pembelajaran seumur hidup mengenai praktik profesi mereka dan harus
mempromosikan pendekatan etis terhadap praktik profesi
Gambar 1.5 Kode etik rekayasa perangkat lunak
�
1.6. KEMANA ANDA PERGI? 27
Kode tersebut bukanlah algoritma sederhana untuk membedakan antara yang dapat diterima dan yang
tidak dapat diterima.
perilaku yang dapat diterima. Sebaliknya, prinsip-prinsip yang dinyatakan harus memengaruhi Anda,
sebagai perangkat lunak
insinyur, untuk mempertimbangkan siapa yang terpengaruh oleh pekerjaan Anda. Perangkat lunak yang
Anda kembangkan memengaruhi
masyarakat. Kesehatan, keselamatan dan kesejahteraan masyarakat adalah perhatian utama dari
kode etik ini. Mematuhi kode etik ini, atau yang serupa, bukanlah sesuatu untuk dilakukan
pertimbangkan saja pada hari Jumat sore. Itu harus menjadi cara hidup.
Kode tidak hanya membahas insinyur perangkat lunak. Ini juga membahas manajer, di
bahwa kode menunjukkan apa yang mungkin diharapkan dari perangkat lunak profesional
insinyur.
1.6 Ke mana engkau pergi?

Banyak kemajuan telah dibuat selama 30 tahun terakhir. Untuk masing-masing jurusan
fase, banyak teknik dan alat telah dikembangkan. Beberapa di antaranya memiliki
menemukan penggunaan luas. Dalam penilaian mereka tentang desain dan praktik pengkodean
misalnya,
DeMarco dan Lister menemukan bahwa sejumlah teknik yang diakui secara luas (seperti
penggunaan unit kecil, pengikatan komponen yang kuat, dan pemrograman terstruktur).
memang diterapkan dalam praktek dan membayar (DeMarco dan Lister, 1989). Namun,
sketsa pendek di bagian sebelumnya (dan pembahasan yang lebih rumit di
bab-bab berikut) menunjukkan bahwa banyak penelitian masih diperlukan untuk membuat perangkat
lunak
teknik menjadi disiplin teknik yang benar-benar matang.
Butuh beberapa waktu sebelum teknologi yang dikembangkan di laboratorium penelitian didapat
diterapkan secara rutin. Ini berlaku untuk produk fisik seperti transistor,
tetapi juga untuk metode, teknik, dan alat di bidang teknologi perangkat lunak. Itu
versi pertama sistem operasi UNIX kembali ke tahun 1971. Hanya sejak itu
akhir 1980-an, minat terhadap UNIX tersebar luas. Pada awal 1960-an, studi tentang
biaya perangkat lunak pertama kali dibuat. Pada tahun 1980-an minat terhadap
model kuantitatif untuk memperkirakan biaya perangkat lunak (lihat juga bab selanjutnya tentang biaya
perkiraan). Artikel Dijkstra tentang pemrograman sebagai aktivitas manusia muncul pada tahun 1965.
Pada akhir 1970-an buku teks pengantar pertama tentang pemrograman terstruktur adalah
diterbitkan. Istilah rekayasa perangkat lunak diperkenalkan pada tahun 1968. Pada tahun 1980-an besar
program nasional dan internasional dimulai untuk mendorong transisi yang baru ini
teknologi. Daftar di atas dapat diperluas dengan banyak contoh lain (Redwine dan
Teka-teki, 1985). Proses pematangan ini umumnya memakan waktu setidaknya 10 hingga 15 tahun.
Dalam artikel mani berjudul 'No silver bullet: esensi dan kecelakaan perangkat lunak
rekayasa ', Brooks (1987) membahas sejumlah pendekatan yang berpotensi bermanfaat untuk
secara dramatis meningkatkan produktivitas perangkat lunak. Kesimpulan utamanya adalah: tidak ada
perak
peluru. Tapi kita juga tidak perlu takut pada werewolf. Dengan studi yang cermat dari
banyak inovasi dan penyelidikan tentang keunggulan mereka yang sebenarnya, banyak perbaikan
dalam
kualitas dan produktivitas dapat tercapai. Sisa dari teks ini dikhususkan
untuk penilaian kritis terhadap perkembangan teknologi dan non-teknologi ini.
Beberapa perkembangan yang relatif baru memiliki dampak dramatis di lapangan:
28 PERKENALAN
�
1.7. RINGKASAN 29
– Jurnal Sistem dan Perangkat Lunak (Elsevier), jurnal bulanan yang mencakup keduanya
makalah penelitian dan laporan pengalaman praktis;
– Prosiding Konferensi Internasional tentang Rekayasa Perangkat Lunak

(ACM/IEEE), prosiding konferensi internasional paling penting di lapangan,
diselenggarakan setiap tahun;
– Prosiding Konferensi Internasional tentang Pemeliharaan Perangkat Lunak (IEEE), terorganisir

tahunan;
– Pemeliharaan dan Evolusi Perangkat Lunak: Penelitian dan Praktek (Wiley), jurnal dua bulanan
dikhususkan untuk topik dalam pemeliharaan dan evolusi perangkat lunak.
1.7 Ringkasan
Rekayasa perangkat lunak berkaitan dengan masalah yang berkaitan dengan
konstruksi dari besar program. Saat mengembangkan program semacam itu, pendekatan bertahap
adalah
diikuti. Pertama, masalahnya dianalisis, dan kemudian sistem dirancang, diimplementasikan
dan diuji. Praktek ini memiliki banyak kesamaan dengan rekayasa fisik
produk. Oleh karena itu istilah rekayasa perangkat lunak. Rekayasa perangkat lunak, bagaimanapun,
juga
berbeda dari rekayasa produk fisik dalam beberapa hal penting.
Model perangkat lunak bagian dari dunia nyata di sekitar kita, seperti perbankan atau
vasi kursi maskapai penerbangan. Dunia di sekitar kita ini berubah seiring waktu. Jadi yang sesuai
perangkat lunak juga harus berubah. Itu harus berkembang bersama dengan realitas yang berubah.
Banyak
dari apa yang kami sebut pemeliharaan perangkat lunak, sebenarnya berkaitan dengan memastikan
bahwa
perangkat lunak mengimbangi dunia nyata yang dimodelkan.
Kami kemudian mendapatkan model proses di mana kami mengulangi fase sebelumnya dari waktu
ke waktu.
Kami berbicara tentang siklus hidup perangkat lunak.
Metode tangkas, penggunaan kembali komponen, dan globalisasi adalah beberapa di antaranya
tren terkini yang berdampak besar pada cara kita memandang lapangan. Ada pergeseran
dari memproduksi perangkat lunak hingga menggunakan perangkat lunak. Konsekuensi utama dari sini
adalah bahwa a
organisasi pengembangan kehilangan kendali atas apa yang diberikannya.
1.8 Bacaan lebih lanjut

Johnson (1998) menjelaskan sejarah awal industri perangkat lunak. Semakin baru
keadaan praktek dijelaskan dalam (Software, 2003).
Untuk pembahasan yang lebih mendalam tentang perbedaan dan persamaan antar perangkat lunak
teknik dan disiplin teknik yang matang, yaitu. desain jembatan, lihat (Spector dan
Gifford, 1986).(Leveson, 1992) membandingkan rekayasa perangkat lunak dengan pengembangan
dari mesin uap bertekanan tinggi.
Empat jenis kegiatan pemeliharaan berasal dari (Lientz dan Swanson, 1980).
30 PERKENALAN
Kegagalan Ariane dijelaskan dalam (J'ez'equel dan Meyer, 1997). Saya menemukan laporan
dari
Tim Penyelidikan http://www.
nes.fr/ARCHIVES/news/rapp
1.8. BACAAN LEBIH LANJUT 31
sering menganjurkan bahwa alat otomatis (alat KASUS) akan meningkat secara dramatis
baik kualitas maupun produktivitas. Pelajari alat KASUS komersial dan nilai
sejauh mana itu meningkatkan proses pengembangan perangkat lunak dan itu
hasil.
12. ~
32 PERKENALAN
E. Menetapkan proses perangkat lunak yang memberikan

fleksibilitas.
F. Menerapkan pendekatan disiplin dan meningkatkannya terus
menerus.
G. Berinvestasi dalam pemahaman masalah.
H. Kelola kualitas sepanjang siklus hidup seformal mungkin.
I. Minimalkan interaksi komponen perangkat lunak.
J. Menghasilkan perangkat lunak secara bertahap.
K. Tetapkan sasaran mutu untuk setiap produk yang dapat
dikirim.
L. Karena perubahan melekat pada perangkat lunak, rencanakan
dan kelola.
M. Karena pengorbanan melekat pada rekayasa perangkat lunak, buatlah
secara eksplisit dan mendokumentasikannya.
N. Untuk meningkatkan desain, pelajari solusi sebelumnya untuk
masalah serupa.
O. Ketidakpastian tidak dapat dihindari dalam rekayasa perangkat lunak.
Mengidentifikasi dan mengelola dia.
Untuk setiap prinsip ini, tunjukkan apakah Anda (sangat) setuju atau
(sangat) tidak setuju, dan mengapa. Anda mungkin ingin menilai kembali prinsip-prinsip
ini
setelah mempelajari sisa buku ini.
Bagian I
Manajemen Perangkat
Lunak
ISI
Bab 2 Pengantar Manajemen Rekayasa 34

Perangkat Lunak
45
bagian 3 Siklus Hidup Perangkat Lunak Ditinjau
Kembali
78
Bab 4 Manajemen konfigurasi
89
Bab 5 Manajemen Orang dan Organisasi Tim
107
Bab 6 Tentang Mengelola Kualitas Perangkat
Lunak 144
Bab 7 Perkiraan biaya 176
Bab 8 Perencanaan dan Kontrol Proyek
Proyek pengembangan perangkat lunak seringkali melibatkan beberapa orang untuk

jangka waktu yang lama. Proyek besar bahkan dapat berkisar selama beberapa
tahun dan melibatkan ratusan orang. Proyek semacam itu harus direncanakan dan
dikendalikan dengan hati-hati. Aspek-aspek utama yang memerlukan perhatian
terus-menerus dari manajer proyek diperkenalkan di bab 2, dan selanjutnya dibahas
di bab 3--7: kemajuan, informasi, orang, kualitas, biaya, dan jadwal. Bagian
manajemen diakhiri dengan bab 8 di mana berbagai pendekatan yang diuraikan
dalam bab 3--7 direkonsiliasi.
2
Pengantar Perangkat
Lunak
Manajemen Rekayasa
TUJUAN PEMBELAJARAN
�
35
Proyek pengembangan perangkat lunak seringkali melibatkan beberapa orang secara

berkepanjangan
periode waktu. Proyek besar bahkan dapat berkisar selama beberapa tahun dan melibatkan
ratusan orang. Proyek semacam itu harus direncanakan dan dikendalikan dengan hati-hati.
Aspek utama yang patut mendapat perhatian terus menerus dari manajer proyek
diperkenalkan dalam bab ini.
Tidak mudah menyelesaikan proyek pengembangan perangkat lunak dengan sukses. Buku ini
terutama berkaitan dengan aspek teknis pengembangan perangkat lunak: desain, spesifikasi,
implementasi dan pengujian sistem perangkat lunak. Saat kita belajar mengendalikan aspek-aspek ini
lebih baik, kami juga akan belajar untuk memenuhi permintaan pelanggan kami dengan lebih baik.
Organisasi
dan aspek manajerial dari proyek pengembangan perangkat lunak setidaknya sama pentingnya dengan
aspek teknis, meskipun.
Sebelum kita memulai diskusi tentang aspek organisasi dan manajerial ini,
mari kita perhatikan dulu batas-batas proyek pengembangan perangkat lunak sebagai
mereka tergambar dalam buku ini.
Proyek pengembangan perangkat lunak biasanya tidak dimulai dengan isolasi lengkap.
Ada proyek lain dalam organisasi yang dibutuhkan proyek khusus ini
untuk disetel, prioritas antar proyek harus diputuskan, dll. Istilahnya
perencanaan informasi sering digunakan untuk merujuk pada proses perencanaan meta-proyek ini.
Juga dalam pengertian yang lebih teknis, proyek tidak dimulai secara terpisah. Meningkatkan
interoperabilitas antara sistem, pedoman keseluruhan mengenai, misalnya, penggunaan tertentu
standar, format pertukaran data, kebijakan keamanan, tata letak halaman web dan sejenisnya
ditetapkan untuk seluruh organisasi dan dikenakan pada setiap proyek. Dalam produk
pengembangan lini, arsitektur lini produk memandu pengembangan
produk individu.
Proyek yang melebihi aturan ini menghasilkan serangkaian kondisi batas untuk masing-masing
proyek, seperti peraturan zonasi mengatur kondisi untuk proyek bangunan.
Menetapkan aturan di seluruh perusahaan ini merupakan masalah tersendiri, dan tidak akan demikian
ditujukan di sini. (Kami akan, bagaimanapun, memberikan perhatian yang cukup untuk beberapa
masalah yang
umumnya melampaui batas-batas proyek pengembangan perangkat lunak individu, seperti
kontrol konfigurasi, jaminan kualitas dan pengembangan lini produk.)
Juga dalam pengertian yang lebih teknis, perangkat lunak umumnya tidak dikembangkan secara
terpisah.
Dalam kebanyakan kasus, perangkat lunak tidak ditulis dari awal. Itu harus berinteraksi dengan yang
ada
perangkat lunak, memperluas perangkat lunak yang ada, menggunakan pustaka subrutin yang ada,
membangun berdasarkan
kerangka kerja yang ada, dan sebagainya.
Dalam arti tertentu, gagasan 'proyek pengembangan perangkat lunak' adalah keliru.
Kami tidak hanya mengembangkan perangkat lunak, kami mengembangkan sistem. Secara garis besar,
sebuah sistem
mengubah input menjadi output. Perangkat lunak adalah unsur penting dari sistem
kami kembangkan, tetapi itu bukan satu-satunya bahan. Teknis dan pengguna
dokumentasi, perangkat keras, prosedur yang mengatur penggunaan sistem, dan
bahkan orang yang menggunakan perangkat lunak, dapat dianggap sebagai bagian dari sistem yang
sama.
Pertimbangkan misalnya sistem untuk otomatisasi perpustakaan. Sistem akan berisi
36 PENGANTAR MANAJEMEN REKAYASA
PERANGKAT LUNAK
berbagai komponen perangkat lunak, seperti komponen database untuk menyimpan
informasi buku dan pelanggan dan komponen interaksi untuk memproses
permintaan pengguna. Selain pengembangan komponen-komponen tersebut,
perhatian harus diberikan pada hal-hal seperti:
�
2.1. PERENCANAAN PROYEK 37
PENGEMBANGAN PERANGKAT LUNAK
buku pelajaran ilmu komputer. Secara umum, proyek pengembangan perangkat lunak menghasilkan a
kumpulan komponen yang secara kolektif memberi kita fungsionalitas yang diinginkan.
Mengingat kondisi batas proyek, proyek pengembangan perangkat lunak mungkin berhasil
dimulai. Merencanakan proyek adalah langkah pertama yang harus dilakukan. Bagian dari ini
proses perencanaan adalah untuk mengidentifikasi karakteristik proyek dan dampaknya terhadap
proses pengembangan. Hasil dari tahap perencanaan dituangkan dalam sebuah dokumen,
itu rencana proyek, yang bertujuan untuk memberikan gambaran proyek yang jelas kepada kedua
belah pihak
pelanggan dan tim pengembangan. Isi rencana proyek dibahas
di bagian 2.1.
Selama pelaksanaan proyek, sejumlah elemen harus dikelola:
waktu, informasi, organisasi, kualitas, dan uang (lihat bagian 2.2). Masing-masing
elemen diuraikan lebih lanjut dalam bab tersendiri.
2.1 Merencanakan Proyek

Lunak
Sebelum kita memulai proyek pengembangan perangkat lunak, itu harus direncanakan dengan hati-hati.
Ini memerlukan, antara lain, penilaian properti proyek yang mungkin mempengaruhi
proses pembangunan. Sejumlah properti, bagaimanapun, tidak akan cukup
dipahami dengan baik sampai fase rekayasa persyaratan telah berakhir. Seperti banyak
aspek lain dari proyek pengembangan perangkat lunak, perencanaan bukanlah kegiatan sekali pakai.
Sebaliknya, sifatnya sangat dinamis. Rencana proyek dapat berfungsi sebagai panduan selama
proyek.
Jumlah perencanaan di muka tergantung pada karakteristik masalah di
tangan. Dalam proyek yang sangat eksploratif, di mana sebagian besar persyaratan tidak diketahui di
mulai, perencanaan awal yang terlalu ketat dapat menyesakkan dan dapat meningkatkan kemungkinan
dari kegagalan besar. Sikap 'rencanakan pekerjaan dan kerjakan rencana' yang ketat tidak berhasil
dalam keadaan ini. Sebaliknya, proyek semacam itu membutuhkan perencanaan awal nominal dan
gaya manajemen yang mendorong menanggapi perubahan. Hal ini tercermin dalam
isi dan ukuran rencana proyek. Bab 3 dan 8 lebih lanjut membahas perbedaan
antara apa yang disebut pendekatan gesit dan berbasis perencanaan untuk pengembangan perangkat
lunak.
Konstituen utama dari rencana proyek adalah:
1. Perkenalan Dalam pengantar rencana proyek, latar belakang dan sejarah

proyek diberikan, bersama dengan tujuannya, penyampaian proyek, nama-nama
orang yang bertanggung jawab, dan ringkasan proyek.
2. Model proses Dalam bab 1, kami memperkenalkan model siklus hidup

sederhana untuk membahas berbagai aktivitas yang harus ditangani dalam
proyek pengembangan perangkat lunak. Ada banyak variasi model proses ini,
beberapa di antaranya dibahas dalam bab 3. Untuk setiap proyek, ada satu
untuk memutuskan model proses yang tepat untuk diikuti: kegiatan mana yang
dilakukan, tonggak mana yang dapat diidentifikasi, bagaimana kita memastikan
apakah tonggak tersebut tercapai, dan jalur kritis mana.
PERANGKAT LUNAK
Jenis proyek yang berbeda memiliki karakteristik yang berbeda, sehingga
memerlukan model proses yang berbeda.
3. Organisasi proyek Hubungan proyek dengan entitas lain dan organisasi

proyek itu sendiri ditangani di bawah judul ini. Proyek akan memiliki hubungan
dengan organisasi pengguna, organisasi induk, dan mungkin dengan organisasi
lain.
Calon pengguna akan dari waktu ke waktu terlibat dalam proyek. Rencana
proyek harus menyatakan informasi, layanan, sumber daya, dan fasilitas
mana yang harus disediakan oleh pengguna dan kapan harus disediakan.
Dalam tim proyek, berbagai peran dapat diidentifikasi: manajer proyek,
penguji, pemrogram, analis, dll. Seseorang harus menggambarkan dengan
jelas peran-peran ini dan mengidentifikasi tanggung jawab masing-masing.
Jika terdapat kesenjangan dalam pengetahuan yang dibutuhkan untuk
memenuhi salah satu peran tersebut, pelatihan dan pendidikan yang
diperlukan untuk mengisi kesenjangan tersebut harus diidentifikasi. Berbagai
bentuk organisasi tim dibahas dalam bab 5.
4. Standar, pedoman, prosedur Proyek perangkat lunak adalah proyek besar.

Biasanya, banyak orang yang terlibat. Oleh karena itu diperlukan disiplin kerja
yang kuat, dimana setiap orang yang terlibat mengikuti standar, pedoman dan
prosedur yang telah disepakati. Selain dinyatakan di atas kertas, banyak di
antaranya dapat didukung atau ditegakkan dengan alat. Yang paling penting
adalah kesepakatan yang jelas tentang dokumentasi: kapan dokumentasi akan
dikirimkan, bagaimana kualitas dokumentasi dinilai, bagaimana cara memastikan
bahwa dokumentasi selalu diperbarui?
Untuk sebagian besar, standar dan prosedur ini akan dijelaskan dalam
dokumen terpisah, seperti Rencana Kontrol Konfigurasi atau Rencana
Jaminan Kualitas.
5. Kegiatan manajemen Kegiatan manajemen dipandu oleh tujuan dan prioritas

yang ditetapkan untuk proyek. Misalnya, manajemen harus menyerahkan laporan
berkala tentang status dan kemajuan proyek. Itu juga harus mengikuti prioritas
tertentu dalam menyeimbangkan persyaratan, jadwal dan biaya.
6. Risiko Risiko potensial harus diidentifikasi sedini mungkin. Akan selalu ada
risiko: perangkat keras mungkin tidak dikirimkan tepat waktu, personel yang
memenuhi syarat mungkin tidak tersedia saat dibutuhkan, informasi penting
mungkin kurang saat dibutuhkan, dan seterusnya. Agak naif untuk menganggap
bahwa proyek pengembangan perangkat lunak berjalan lancar. Bahkan di bidang
yang mapan seperti konstruksi, selalu ada yang tidak beres. Seseorang harus
mendiagnosis risiko proyek perangkat lunak sejak dini, dan memberikan
langkah-langkah untuk menghadapinya; lihat juga bab 8.
Semakin tidak pasti berbagai aspek proyek, semakin besar risikonya.
2.1. PERENCANAAN PROYEK 39
7. Kepegawaian Pada titik waktu yang berbeda, proyek akan membutuhkan
jumlah personel yang berbeda, dengan keahlian yang berbeda. Awal, durasi,
jumlah, dan keahlian kategori personel tercantum di bawah judul ini.
8. Metode dan teknik Di bawah judul ini, metode dan teknik yang akan
digunakan selama rekayasa persyaratan, desain, implementasi dan pengujian
diberikan. Biasanya, cara kontrol versi dan konfigurasi untuk komponen
perangkat lunak ditangani juga dijelaskan di sini. Sebagian besar dokumentasi
teknis akan diproduksi selama fase ini. Oleh karena itu, seseorang harus
menyatakan bagaimana dokumentasi ini akan diurus.
Lingkungan pengujian yang diperlukan dan peralatan pengujian dijelaskan.
Selama pengujian, tekanan yang cukup besar biasanya akan diberikan pada
alat uji. Oleh karena itu, kegiatan ini harus direncanakan dengan matang.
Urutan di mana komponen diintegrasikan dan diuji harus dinyatakan secara
eksplisit. Juga, prosedur yang harus diikuti selama pengujian penerimaan,
yaitu pengujian di bawah pengawasan pengguna, harus diberikan. Pengujian
akan dibahas pada bab 13.
9. Kualitas asuransi Organisasi dan prosedur mana yang akan digunakan untuk
memastikan perangkat lunak yang dikembangkan memenuhi persyaratan
kualitas yang dinyatakan? Banyak aspek Rencana Penjaminan Mutu juga dapat
ditangani dalam dokumen terpisah. Topik penjaminan mutu dibahas pada bab 6.
10. Paket kerja Proyek yang lebih besar harus dipecah menjadi aktivitas,
bagian-bagian yang dapat dikelola yang dapat dialokasikan ke masing-masing
anggota tim. Masing-masing kegiatan ini harus diidentifikasi dalam rencana
proyek. Dekomposisi hirarkis proyek digambarkan dalam struktur perincian
pekerjaan (lihat juga bagian 8.4).
11. Sumber daya Selama proyek, banyak sumber daya yang dibutuhkan.
Perangkat keras, siklus CPU, dan alat yang diperlukan untuk mendukung proyek
dicantumkan di bawah entri ini. Seseorang juga harus menunjukkan personel yang
diperlukan untuk berbagai fase proses.
12. Anggaran dan jadwal Total anggaran untuk proyek harus dialokasikan ke
berbagai kegiatan seperti yang ditunjukkan dalam struktur rincian pekerjaan.
Kegiatan juga harus dijadwalkan pada waktunya, mis. menggunakan grafik PERT
(lihat bagian 8.4). Cara di mana sumber daya dan pengeluaran lainnya dilacak
juga ditunjukkan di bawah judul ini. Topik perkiraan biaya dan waktu akan dibahas
secara luas di bab 7.
13. Perubahan Telah dinyatakan sebelumnya bahwa perubahan tidak bisa

dihindari. Kita harus memastikan bahwa perubahan ini ditangani dengan cara yang
teratur. Oleh karena itu, diperlukan prosedur yang jelas tentang bagaimana
perubahan yang diusulkan akan ditangani. Jika prosesnya gesit, setiap iterasi
melibatkan perubahan, dan ini ditangani dengan cara yang ringan. Nyatanya,
mereka tidak lagi dilihat sebagai perubahan. Dalam proses yang lebih berat, setiap
perubahan yang diusulkan harus didaftarkan dan ditinjau. Ketika sebuah
PERANGKAT LUNAK
permintaan perubahan telah disetujui, dampaknya (biaya) harus diperkirakan.
Akhirnya, perubahan harus dimasukkan ke dalam proyek. Perubahan yang
dimasukkan melalui pintu belakang menyebabkan kode terstruktur dengan
buruk, dokumentasi yang tidak memadai, dan biaya serta waktu yang
berlebihan. Karena perubahan menyebabkan versi dokumentasi dan kode
yang berbeda, prosedur yang harus diikuti dalam menghadapi perubahan
tersebut sering ditangani dalam konteks Rencana Kontrol Konfigurasi.
14. Pengiriman Prosedur yang harus diikuti dalam penyerahan sistem ke

pelanggan harus dinyatakan.
Rencana proyek bertujuan untuk memberikan gambaran yang jelas tentang proyek
kepada pelanggan dan tim proyek. Jika tujuan tidak jelas, tujuan tersebut tidak akan
tercapai. Meskipun direncanakan dengan hati-hati, kejutan masih akan muncul
selama proyek berlangsung. Namun, perencanaan yang hati-hati sejak awal
menghasilkan lebih sedikit kejutan dan membuat seseorang tidak terlalu rentan
terhadap kejutan ini. Rencana proyek membahas sejumlah pertanyaan yang
mengantisipasi kemungkinan kejadian di masa depan. Ini memberikan prosedur
yang teratur untuk menangani peristiwa tersebut, sehingga keputusan yang dapat
dibenarkan dapat dicapai.
2.2 Mengontrol Proyek

Lunak
Setelah rencana proyek disusun dan disetujui, pelaksanaan proyek dapat dimulai.
Selama proyek berlangsung, kontrol harus diberikan sepanjang dimensi berikut:
- waktu,
– informasi,
- organisasi,
- kualitas,
- uang.
Kemajuan proyek pengembangan perangkat lunak (mis waktu aspek) sulit untuk
diukur. Sebelum sistem yang diusulkan selesai, hanya ada tumpukan kertas (besar).
Ucapan seperti '90% dari kode telah ditulis' harus diambil dengan sedikit garam.
Gambaran yang terlalu cerah tentang keadaan sebenarnya biasanya diberikan.
Pendekatan bertahap yang diperkenalkan di bab 1, dan variannya, bertujuan untuk
menyediakan alat bagi manajer untuk mengukur dan mengendalikan kemajuan.
Waktu yang dibutuhkan untuk membangun sebuah sistem jelas berhubungan
dengan ukuran sistem, dan dengan demikian total tenaga kerja yang dibutuhkan.
Sistem yang lebih besar membutuhkan lebih banyak waktu untuk berkembang,
meskipun kami mungkin mencoba mempersingkat waktu pengembangan dengan
mengalokasikan lebih banyak personel. Bagian dari masalah kontrol untuk proyek
pengembangan perangkat lunak adalah menukar waktu dengan orang.
Menambahkan lebih banyak orang untuk mempersingkat waktu pengembangan
tidak gratis. Semakin banyak orang yang terlibat, semakin banyak waktu yang
dibutuhkan untuk koordinasi dan komunikasi. Setelah titik tertentu, penambahan
orang justru memperpanjang waktu pengembangan.
2.2. PENGENDALIAN PROYEK 41
Bagian dari masalah kontrol waktu diutarakan dalam Hukum Brooks: 'Menambahkan orang terlambat
proyek hanya membuatnya nanti '. Kami akan kembali ke masalah ini di bab tentang biaya
perkiraan.
Itu informasi yang harus dikelola, di atas segalanya, adalah dokumentasi. Di samping itu
dokumentasi teknis dan pengguna, ini juga memerlukan dokumentasi pada proyek
diri. Dokumentasi mengenai proyek mencakup hal-hal seperti: keadaan saat ini
urusan, perubahan yang telah disepakati, dan keputusan yang telah dibuat.
Jenis dokumentasi ini paling baik ditangani dalam konteks konfigurasi
pengelolaan. Dalam proyek tangkas, kurang perhatian diberikan pada dokumentasi selama
perkembangan. Pengetahuan yang diperlukan diam-diam, itu berada di kepala orang-orang
terlibat. Namun di sini juga, setelah sistem siap dan diserahkan kepada pelanggannya,
dokumentasi harus disediakan.
Semua anggota tim pengembangan harus memahami peran mereka dalam tim dan
apa yang diharapkan dari mereka. Sangat penting bahwa harapan ini jelas
semua orang yang terlibat. Harapan yang tidak terucapkan dan tidak jelas mengarah pada situasi di
mana
anggota tim individu menetapkan tujuan mereka sendiri, baik secara sadar atau tidak sadar.
Ini organisasiaspek layak perhatian terus menerus dari manajer proyek.
Kedua, pengorganisasian tim dan koordinasi orang-orang yang terlibat
akan, setidaknya sebagian, bergantung pada karakteristik proyek dan lingkungannya.
Ketergantungan ini harus dikenali dan diperhitungkan saat menyiapkan a
tim proyek.
Itu kualitas aspek merupakan hal yang sangat penting. Pelanggan tidak puas dengan
solusi murni teknis yang ditawarkan oleh spesialis komputer. Mereka menginginkan sistem itu
sesuai dengan kebutuhan nyata mereka. Persyaratan kualitas untuk perangkat lunak dan
pengembangannya seringkali
konflik satu sama lain. Pada waktu arsitektur, persyaratan kualitas diseimbangkan dalam a
dialog dengan semua pemangku kepentingan yang terlibat. Selama proyek kita harus menilai apakah
atau tidak persyaratan kualitas terpenuhi. Penilaian kualitas ini harus terjadi
secara teratur, sehingga tindakan tepat waktu dapat dilakukan. Kualitas bukanlah tambahan
fitur, itu harus dibangun di.
Mengontrol pengeluaran (yang uang aspek) sebagian besar berarti mengendalikan biaya tenaga
kerja.
Meskipun biaya perangkat keras dan peralatan tidak dapat diabaikan, hal ini biasanya dapat diabaikan
diperkirakan cukup tepat di awal proyek. Selain itu, ini biasanya jauh lebih sedikit
dari masalah dari biaya personil.
Memperkirakan biaya perangkat lunak berarti kita harus memperkirakan tenaga kerja
diperlukan untuk membangun perangkat lunak. Tenaga kerja yang dibutuhkan sangat tergantung pada
ukuran perangkat lunak, misalnya diukur sebagai jumlah kode yang akan dikirimkan.
Namun, banyak faktor lain yang memengaruhi biaya ini atau, alternatifnya, produktivitas
dengan mana perangkat lunak dapat diproduksi. Tim yang seimbang dengan pengalaman
orang akan jauh lebih produktif daripada tim yang baru dibentuk dengan tidak berpengalaman
rakyat. Kendala kualitas yang sangat ketat, seperti keandalan yang sangat tinggi atau sangat cepat
waktu respons, juga dapat sangat mengurangi produktivitas.
Sejumlah model telah diusulkan yang mencoba mengukur efek dari
pemicu biaya yang berbeda pada tenaga kerja yang dibutuhkan (lihat bab 7). Daripada
PERANGKAT LUNAK
memperkirakan ukuran terlebih dahulu, dan kemudian biayanya, seseorang juga
dapat menetapkan ambang biaya terlebih dahulu, dan bekerja secara bertahap,
pertama pada kebutuhan pengguna yang paling mendesak dan, jika waktu
memungkinkan, pada kebutuhan yang tidak terlalu mendesak. Atau seseorang
dapat menyepakati ambang pertama, dan memutuskan apakah lebih banyak uang
akan dibelanjakan ketika ambang ini tercapai. Pendekatan tambahan untuk estimasi
biaya ini cocok dengan pengembangan proyek yang gesit.
Pengembangan perangkat lunak adalah proses yang sangat padat karya. Salah
satu harapan kami adalah bahwa alat yang lebih baik dan peningkatan penggunaan
alat tersebut akan menghasilkan peningkatan produktivitas yang signifikan dan,
akibatnya, penurunan biaya yang signifikan dalam pengembangan perangkat lunak.
Cara kedua, untuk meningkatkan produktivitas secara dramatis, adalah
menggunakan perangkat lunak daripada membangunnya sendiri. Kedua topik ini
akan dibahas dalam bab-bab berikutnya. Seiring tren ini berlanjut, pengembangan
perangkat lunak mulai menjadi aktivitas padat modal, bukan padat karya (Wegner,
1984). Penilaian berkelanjutan terhadap proyek sehubungan dengan aspek
pengendalian ini adalah yang paling penting dan dari waktu ke waktu akan
mengarah pada penyesuaian waktu, biaya, organisasi, informasi, atau kualitas, atau
beberapa kombinasinya. Manajemen proyek adalah aktivitas yang sangat dinamis.
Agar dapat mengontrol proyek secara memadai, kami membutuhkan data
kuantitatif yang dikumpulkan saat proyek sedang dilaksanakan. Misalnya, data
tentang kesalahan yang ditemukan selama pengujian unit dapat membantu kami
memperkirakan upaya pengujian lebih lanjut yang diperlukan. Data tentang waktu
dan tenaga yang dihabiskan hingga titik tertentu akan memandu kita dalam
memperkirakan ulang jadwal dan biaya. Mengukur adalah mengetahui.
Data ini juga berharga dalam evaluasi post-mortem proyek. Dalam evaluasi
post-mortem kami menilai proyek saat ini untuk meningkatkan kinerja kami pada
proyek yang akan datang: kesalahan apa yang telah kami lakukan, apa yang telah
kami pelajari, apa yang perlu dilakukan secara berbeda pada proyek berikutnya?
Sayangnya, dalam praktiknya sangat sedikit data keras yang pernah
dikumpulkan, apalagi disimpan untuk digunakan nanti. Sebagian besar organisasi
pengembangan perangkat lunak memiliki sedikit wawasan tentang apa yang mereka
lakukan. Mereka cenderung beroperasi dengan cara yang agak kacau, terutama
saat menghadapi krisis. Dengan mengidentifikasi faktor-faktor kunci yang
memengaruhi pengendalian proses pengembangan perangkat lunak, kami dapat
menemukan cara untuk memperbaikinya. Topik ini dibahas lebih lanjut dalam bab 6,
di mana kita membahas Model Kematangan Kemampuan Perangkat Lunak.
2.3 Ringkasan
Bab ini memberikan pengenalan manajemen proyek rekayasa perangkat lunak.
Sebelum kita memulai proyek pengembangan perangkat lunak, itu harus
direncanakan dengan hati-hati. Proses perencanaan ini menghasilkan sebuah
dokumen, rencana proyek, yang memberikan gambaran yang jelas tentang proyek
kepada pelanggan dan tim proyek. Setelah rencana proyek disusun dan proyek
dimulai, pelaksanaannya harus dikontrol. Kami mengidentifikasi lima entitas yang
membutuhkan perhatian berkelanjutan kami untuk pengendalian proyek:
2.3. RINGKASAN 43
�
PERANGKAT LUNAK
9.
~
3
Siklus Hidup Perangkat Lunak
Dikunjungi kembali
TUJUAN PEMBELAJARAN
�
46 SIKLUS HIDUP PERANGKAT LUNAK
DIKUNJUNGI
Untuk dapat menilai kemajuan selama pengembangan perangkat lunak,

seseorang memilih a
pendekatan bertahap dengan sejumlah peristiwa tonggak yang terdefinisi
dengan baik. Linier
urutan kegiatan yang mendasari pengembangan perangkat lunak tradisional
model, model air terjun, menjadikannya idealisasi realitas yang mustahil
meskipun. Ini mengasumsikan hasil pengembangan perangkat lunak secara
teratur, berurutan
tata krama. Proyek nyata berjalan dengan cara yang jauh lebih tidak rasional.
Model air terjun dari
pengembangan perangkat lunak tidak layak, seperti Air Terjun Escher,
direproduksi
di sampul depan, tidak layak. Bab ini membahas berbagai alternatif
model proses pembangunan.
Di bab 1, kami memperkenalkan model sederhana dari siklus hidup perangkat lunak.
Kami membedakan beberapa fase berturut-turut: rekayasa persyaratan, desain,
implementasi, pengujian, pemeliharaan. Dinyatakan bahwa, dalam praktiknya,
seseorang sering menggunakan model proses yang lebih canggih. Dalam bab ini
kita melanjutkan diskusi ini. Kami memperkenalkan berbagai model alternatif untuk
menyusun proses pengembangan perangkat lunak.
Proyek pengembangan perangkat lunak seringkali merupakan proyek yang
sangat besar. Sejumlah orang bekerja pada proyek semacam itu untuk waktu yang
lama dan oleh karena itu seluruh proses perlu direncanakan dan dikendalikan
dengan hati-hati: kemajuan perlu dipantau, orang dan sumber daya perlu
dialokasikan pada titik waktu yang tepat, dll. menunjukkan bahwa kemajuan proyek
pengembangan perangkat lunak sangat sulit untuk diukur. Untuk mengontrol
kemajuan, kami menggunakan pengembangan bertahap di mana sejumlah tonggak
yang dapat diidentifikasi dengan jelas ditetapkan antara awal dan akhir proyek. Kami
menggunakan mekanisme serupa saat membangun rumah: fondasi diletakkan,
lantai pertama tercapai, rumah tahan cuaca, dan seterusnya. Seringkali,
pembayaran cicilan digabungkan untuk mencapai tonggak sejarah tersebut.
Secara umum, tonggak yang diidentifikasi dalam proyek pengembangan
perangkat lunak sesuai dengan titik waktu di mana dokumen tertentu tersedia:
– setelah rekayasa persyaratan, ada spesifikasi persyaratan;
– setelah tahap desain ada spesifikasi (teknis) dari sistem;
– setelah implementasi ada serangkaian program;
– setelah pengujian selesai ada laporan pengujian.
Model tradisional untuk pengembangan bertahap perangkat lunak, sebagian besar,

'didorong oleh dokumen'. Tumpukan kertas yang dihasilkan selama proyek
memandu proses pengembangan. Proses pembangunan dipandang sebagai
rangkaian transformasi. Dimulai dengan dokumen persyaratan yang jelas, dan
diakhiri dengan runningcode. Pada bagian selanjutnya kita membahas model air
terjun, variasi terkenal dari model proses yang diperkenalkan di bab 1. Dalam variasi
ini, pengecekan dilakukan setelah setiap transformasi, untuk menentukan apakah
kita masih berada di jalur yang benar.
47
Metode berbasis dokumen ini juga dikenal sebagai didorong oleh perencanaan atau kelas berat
metode. Didorong oleh perencanaan, karena penekanan pada rencana di muka untuk keseluruhan
proses. Kelas berat, karena menitikberatkan pada proses.
Dalam banyak proyek pengembangan perangkat lunak, perubahan adalah fakta kehidupan. Bahkan
mungkin
kasus di mana klien hanya memiliki gagasan yang kabur tentang persyaratan untuk sistem dia
meminta. Dalam beberapa tahun terakhir, sejumlah ringan, lincah metode telah diusulkan bahwa
sengaja menghadapi keadaan yang berubah dengan cepat ini. Metode ini menganjurkan
untuk tidak 'membuang-buang' waktu untuk kegiatan perencanaan dan desain yang mahal sejak dini,
tetapi untuk mewujudkannya
sesuatu yang berharga bagi pelanggan secepat mungkin. Berdasarkan umpan balik dari
pengguna, langkah selanjutnya kemudian diambil. Metode tangkas telah berevolusi dari pendekatan
seperti pembuatan prototipe dan Pengembangan Aplikasi Cepat yang mencoba membuang beberapa
atau semua kelemahan dari pendekatan berbasis dokumen yang disebutkan di atas. Kami akan
membahas sejumlah pendekatan ringan untuk pengembangan perangkat lunak di bagian 3.2.
Model evolusioner memperhitungkan bahwa banyak dari apa yang disebut pemeliharaan
benar-benar evolusi. Maka akan tampak wajar untuk secara eksplisit menanggung evolusi yang
diantisipasi ini
dalam pikiran sejak awal. Ini biasanya tidak terjadi. Baik di kelas berat maupun
pendekatan pengembangan ringan, pengembangan awal dari sistem perangkat lunak
pada umumnya dipisahkan secara ketat dari fase pemeliharaan berikutnya. Mayor
tujuan proyek pengembangan perangkat lunak kemudian bermuara pada pengiriman versi pertama
dari sistem kepada pengguna. Ini dapat mengakibatkan biaya perawatan yang berlebihan di kemudian
hari.
Agar dapat menilai biaya dan manfaat dengan benar, lebih baik total biaya siklus hidup
dari sekedar biaya pengembangan harus menjadi fokus utama kami. Melangkah lebih jauh, kita
mungkin berpendapat bahwa manajemen harus berkonsentrasi pada serangkaian produk serupa
(disebut
keluarga produk) daripada produk individu, sehingga memberikan insentif keduanya
untuk membangun bagian yang dapat digunakan kembali dan penggunaan kembali (bagian dari) produk
yang ada saat
mengembangkan yang baru.
Dari semua kemungkinan model siklus hidup kita harus memilih salah satu model tertentu
proyek yang diberikan. Pada umumnya, metode kelas berat lebih cocok (sangat) proyek besar, dan
situasi di mana persyaratan dapat diputuskan pada tahap awal. Ringan
metode sesuai dengan situasi perubahan yang cepat, dan proyek yang tidak melibatkan lebih dari,
katakanlah 50 orang. Karakteristik proyek yang berbeda, dan cara yang tepat untuk mengontrol
mereka secara efektif, dibahas dalam bab 8.
Pilihan untuk model siklus hidup tertentu juga melibatkan pendefinisian individu
langkah dan fase, kemungkinan interaksinya, penyampaiannya, dll. Dengan menggunakan an
bahasa pemodelan proses eksplisit, yang mungkin didukung oleh alat, kami mungkin
meningkatkan pemahaman kita tentang proses perangkat lunak, kita diberikan pegangan untuk
meningkatkan kendali kami atas pengembangan perangkat lunak, dan kami diberi garis dasar untuk
proses
peningkatan. Jenis pemodelan proses ini dibahas di bagian 3.6. Karena
dari penekanan yang jauh lebih besar pada perencanaan, jenis pemodelan ini lebih cocok
metode kelas berat.
48 SIKLUS HIDUP PERANGKAT
LUNAK DIKUNJUNGI
3.1 Model Air Terjun
Model air terjun pada dasarnya merupakan variasi kecil dari model yang
diperkenalkan pada bab 1. Model air terjun umumnya dikaitkan dengan Royce
(1970). Namun, pendekatan bertahap yang jelas untuk pengembangan perangkat
lunak, termasuk iterasi dan umpan balik, sudah dapat ditemukan dalam publikasi
dari awal 1960-an.
Model air terjun secara khusus mengekspresikan interaksi antara fase-fase
berikutnya. Menguji perangkat lunak bukanlah aktivitas yang secara ketat mengikuti
fase implementasi. Di dalam setiap fase proses pengembangan perangkat lunak,
kita harus membandingkan hasil yang diperoleh dengan yang dibutuhkan. Dalam
semua fase, kualitas harus dinilai dan dikendalikan.
Pada gambar 3.1, V & V adalah singkatan dari Verifikasi dan Validasi. Verifikasi
menanyakan apakah sistem memenuhi persyaratannya (apakah kita membangun
sistem dengan benar) dan dengan demikian mencoba menilai kebenaran transisi ke
fase berikutnya. Validasi menanyakan apakah sistem memenuhi persyaratan
pengguna (apakah kita membangun sistem yang tepat).
Gambar 3.1 Model air terjun

3.1. MODEL AIR TERJUN 49
Baik model yang diperkenalkan di Bab 1 maupun model air terjun memiliki tempat yang cukup besar
menekankan pada analisis yang cermat sebelum sistem benar-benar dibangun. Kami ingin mencegah
mengerahkan banyak energi untuk membangun sistem yang kemudian ternyata tidak memuaskan
kebutuhan pengguna.
Karena itu kami mencoba mengidentifikasi dan mengikat kebutuhan pengguna sedini mungkin
mungkin. Persyaratan ini didokumentasikan dalam spesifikasi persyaratan. Pada
berdasarkan dokumen ini kami dapat memverifikasi pada tahap selanjutnya apakah ini atau tidak
persyaratan sedang dipenuhi. Karena dalam praktiknya sulit, jika bukan tidak mungkin, untuk
melakukannya
benar-benar menentukan kebutuhan pengguna, tes reguler juga harus dilakukan
dengan calon pengguna. Tes ini disebut validasi. Melalui validasi tersebut
langkah-langkah kami dapat mencegah sistem yang sedang dikembangkan menyimpang dari, mungkin
ditentukan secara tidak lengkap, persyaratan pengguna.
McCracken dan Jackson (1981) membandingkan model air terjun dengan toko mana
pelanggan wajib memberikan perintah pada saat masuk. Tidak ada kesempatan untuk
melihat-lihat, membandingkan harga, berubah pikiran, atau memutuskan menu yang berbeda untuk
makan malam hari ini. Beberapa hal dapat dipesan melalui surat, tetapi tidak semuanya.
Model air terjun pengembangan perangkat lunak, seperti air terjun Escher, tidak realistis.
Ada banyak bukti kuantitatif yang dimiliki model berbasis dokumen klasik
banyak kekurangan. Dalam banyak proyek pengembangan perangkat lunak, urutan yang ketat dari
fase yang dianjurkan oleh model air terjun sebenarnya tidak dipatuhi. Gambar 3.2 menunjukkan
perincian rata-rata aktivitas di seluruh fase siklus hidup untuk sejumlah proyek. Di dalam
gambar, label 'coding' mengacu pada fase yang mencakup kedua implementasi
dan pengujian unit.
Aktivitas Fase
Desain Pengkodean Integrasi Penerimaan
pengujian pengujian
Tes integrasi 4.7 43.4 26.1 25.8

Pengkode 6.9 70.3 15.9 6.9
an
Desain 49.2 34.1 10.3 6.4
Gambar 3.2 Perincian aktivitas lintas fase siklus hidup, setelahnya (Zelkowitz, 1988)
Jadi, misalnya, hanya 50% dari upaya desain ditemukan terjadi selama
fase desain aktual, sementara sepertiga dari upaya desain terjadi selama pengkodean
periode. Lebih buruk lagi, lebih dari 16% upaya desain terjadi setelah sistem selesai
seharusnya selesai.
Perilaku desain perangkat lunak dari masing-masing desainer dapat dicirikan sebagai
proses oportunistik (Guindon dan Curtis, 1988). Desainer bergerak bolak-balik
DIKUNJUNGI
melintasi tingkat abstraksi mulai dari masalah domain aplikasi hingga masalah
pengkodean. Tanggal tonggak tampaknya agak arbitrer, dan sebagian besar
aktivitas melintasi batas fase.
3.2 Metode Agile

Definisi Agility dari American Kennel's Club adalah: ”Olahraga Agility yang
mengasyikkan telah menggemparkan dunia. Cincin Agility memungkinkan pawang
dan anjing untuk berlari dengan kecepatan penuh, sambil harus tampil akurat dan
aman di A-Frames, Dog Walks, See-Saws, dan berbagai macam lompatan dan
terowongan”. Insinyur perangkat lunak bukanlah anjing, tetapi analoginya jelas.
Saat menggunakan metode pengembangan kelas berat, sulit untuk mengubah
arah. Setelah kontrak ditandatangani, tugas tim pengembangan adalah memberikan
fungsionalitas sebagaimana ditetapkan dalam kontrak. Jika kenyataan berubah, atau
pengguna mendapatkan wawasan yang berbeda, itu sulit dicapai. Tidak sesuai
dengan arsitekturnya, membutuhkan pengerjaan ulang yang tidak diperhitungkan,
memperpanjang jadwal yang telah disepakati, dan sebagainya. Ini adalah kereta api
yang tidak mudah berubah arah.
Ini telah diakui selama bertahun-tahun, dan metode seperti prototyping dan
pengembangan evolusi terjadi. Tetapi metode ini entah bagaimana masih membawa
cita rasa teknik. Intinya, mereka masih menganggap dunia ini teratur. Mungkin sulit
untuk menentukan persyaratan yang sebenarnya dengan segera, tetapi persyaratan
tersebut akan bertambah seiring waktu. Metode tangkas sejati memandang
dunia sebagai sesuatu yang kacau secara fundamental. Mereka menganggap
perubahan tidak bisa dihindari. Fokus mereka adalah untuk memberikan nilai
kepada pelanggan secepat mungkin, dan tidak peduli dengan rencana dan proses
ekstensif yang toh tidak akan diikuti. Inti dari metode agile tercantum dalam
Manifesto for Agile Software Development, yang diterbitkan pada tahun 2001 oleh
sebuah kelompok perintis terkenal di daerah ini (Becket al., 2001). Nilai-nilai kunci
dari gerakan tangkas adalah:
�
3.2. METODE CEPAT 51
belum final, sementara. "Kode kerja" membawa makna yang lebih positif. Itu menandakan
sesuatu yang bernilai langsung, meskipun belum sempurna.
Metode tangkas tidak memiliki fase arsitektur atau desain yang luas di muka.
Lagi pula, tidak masuk akal untuk menghabiskan banyak upaya pada desain jika Anda mengetahui
keinginan ini
sangat mungkin membuang-buang waktu. Lebih efektif untuk hanya melakukan desain sejauh
diperlukan untuk langkah segera berikutnya. Metode tangkas seringkali memiliki aktivitas terpisah
meningkatkan desain setelah setiap kenaikan, yang dikenal sebagai pemfaktoran ulang.
Metode tangkas berorientasi pada orang, bukan berorientasi pada proses. Mereka menekankan
elemen manusia dalam pengembangan perangkat lunak. Semangat tim dianggap sangat penting.
Hubungan tim sangat erat. Seringkali, tim yang gesit menempati satu ruangan besar. Para pengguna
berada di lokasi juga. Metode tangkas memiliki siklus komunikasi yang singkat antar pengembang
dan pengguna, dan antara pengembang.
Terakhir, metode tangkas tidak menghabiskan banyak energi untuk dokumentasi. Itu akan terjadi
untuk berubah, jadi mengapa menghabiskan waktu untuk sesuatu yang akan segera usang.
Sebaliknya, metode gesit mengandalkan pengetahuan diam-diam dari orang-orang yang terlibat. kalau
sudah
sebuah pertanyaan, tanyakan pada salah satu temanmu. Jangan berjuang dengan tumpukan kertas
yang besar, cukup
kemungkinan besar tidak akan memberikan jawabannya.
Beberapa orang berpendapat bahwa metode gesit harus 'murni', dan menunjukkan semuanya
karakteristik yang disebutkan di atas. Yang lain percaya bahwa campuran didorong oleh perencanaan
dan metode gesit juga bisa produktif. Kami setuju dengan pandangan yang terakhir. Di dalam
subbagian berikut, pertama kita membahas prototyping dan pengembangan inkremental,
metode awal yang menyadari bahwa pendekatan berbasis perencanaan seringkali tidak cocok dengan
situasi yang tidak stabil di tangan. Pengembangan Aplikasi Cepat dan DSDM menekankan
kolaborasi pelanggan dan peran orang dalam proses, dan dengan demikian menunjukkan a
sejumlah karakteristik kunci dari metode tangkas. Akhirnya, XP adalah metode gesit 'murni'.
3.2.1 Pembuatan prototipe

Seringkali sulit untuk mendapatkan dan mempertahankan persepsi yang cukup akurat tentang
kebutuhan calon pengguna. Ini tidak mengherankan. Secara umum tidak
cukup untuk mengambil yang ada situasi sebagai satu-satunya titik awal untuk menyiapkan
persyaratan perangkat lunak. Alasan penting untuk memulai pengembangan perangkat lunak
proyek adalah bahwa seseorang tidak senang dengan situasi saat ini. Apa yang diinginkan sebagai
gantinya
situasi saat ini seringkali tidak mudah ditentukan. Ini bahkan lebih berlaku dalam kasus
di mana kami khawatir dengan aplikasi baru dan pelanggan tidak tahu
kemungkinan penuh otomatisasi. Dalam kasus seperti itu, pengembangan satu atau lebih
prototipe dapat membantu.
Analogi dengan pengembangan produk lain sangat menarik di sini. Kapan
mengembangkan mobil atau chip baru, seseorang juga akan membangun satu atau lebih prototipe. Ini
prototipe diuji secara intensif sebelum lini produksi nyata disiapkan. Untuk
pengembangan telepon tombol-tekan, sekitar 2000 prototipe diuji,
dengan variasi bentuk, ukuran dan posisi tombol, ukuran dan berat
corong, dll.
DIKUNJUNGI
Dimungkinkan untuk mengikuti jalan yang sama dengan pengembangan
perangkat lunak. Dalam konteks ini, prototipe dapat digambarkan sebagai model
kerja (kemungkinan bagian dari) sistem perangkat lunak, yang menekankan
aspek-aspek tertentu. Akan tetapi, ada satu perbedaan besar antara pengembangan
perangkat lunak dan pengembangan produk fisik seperti mobil, chip, atau telepon:
dalam mengembangkan produk fisik, biaya tertinggi umumnya dikeluarkan selama
produksi, ketika banyak salinan produk diproduksi. Dalam pengembangan perangkat
lunak, membuat banyak salinan produk hampir gratis. Jika kita mengikuti
pendekatan perangkat keras untuk membuat prototipe dalam pengembangan
perangkat lunak, dan menghasilkan prototipe dengan fungsionalitas yang sama
dengan produk akhir, kita sebenarnya akan mengembangkan sistem operasional,
dengan biaya yang tinggi. Maka tampaknya tidak masuk akal untuk memulai dari
awal lagi dan mengembangkan sistem 'nyata' dengan cara yang berbeda.
Menggunakan definisi yang diberikan di atas dan dengan tujuan
mengembangkan prototipe perangkat lunak yang relatif murah, aspek-aspek tertentu
harus ditekankan. Hal ini dapat dicapai melalui, misalnya:
– penggunaan bahasa tingkat sangat tinggi, di mana versi yang dapat dieksekusi
dapat dibuat dengan cepat. Versi yang dapat dieksekusi tetapi mungkin agak
tidak efisien ini dapat digunakan untuk menguji kegunaan dari sistem yang
diusulkan;
– pengembangan sistem dengan fungsionalitas yang lebih sedikit, khususnya

dalam hal atribut kualitas seperti kecepatan dan ketahanan.
Salah satu kesulitan utama bagi pengguna adalah untuk mengungkapkan

kebutuhan mereka secara tepat. Wajar untuk mencoba mengklarifikasi ini melalui
pembuatan prototipe. Ini dapat dicapai dengan mengembangkan antarmuka
pengguna dengan cepat. Calon pengguna kemudian dapat bekerja dengan sistem
yang berisi komponen interaksi tetapi tidak, atau pada tingkat yang jauh lebih
rendah, perangkat lunak yang benar-benar memproses input. Dengan cara ini,
pengguna dapat memperoleh kesan yang baik tentang apa yang akan diberikan
sistem di masa depan kepadanya, sebelum investasi besar dibuat untuk
mewujudkan sistem. Prototyping dengan demikian menjadi alat untuk rekayasa
kebutuhan. Hal ini diilustrasikan secara grafis pada gambar 3.3.
Gambar ini menunjukkan bahwa berbagai fase dilalui dalam dua cara. Sisi kiri
gambar berkaitan dengan tahap prototyping. Iterasi sesuai dengan proses validasi
pengguna, di mana persyaratan baru atau yang diubah memicu siklus berikutnya.
Sisi kanan menyangkut produksi aktual dari sistem operasional. Perbedaan antara
kedua cabang tersebut adalah, dengan menggunakan teknik dan alat yang berbeda,
sisi kiri dapat dilalui jauh lebih cepat dan dengan biaya yang jauh lebih rendah.
Pada Gambar 3.3, fase pembuatan prototipe dan fase produksi selanjutnya telah
dipisahkan dengan jelas. Ini tepat, karena kita akan menggunakan teknik yang
berbeda selama fase produksi aktual, lebih menekankan pada dokumentasi, dan
seterusnya. Bahkan mungkin untuk tidak membawa produk perangkat lunak dari
fase prototyping ke fase produksi aktual, tetapi secara eksplisit membuang itu pergi
setelah fase prototyping telah berakhir. Ini dikenal sebagai pembuatan prototipe
sekali pakai. Itu tidak perlu
DIKUNJUNGI
dan cara kotor.
Keuntungan
- Sistem yang dihasilkan lebih mudah digunakan

- Kebutuhan pengguna lebih terakomodir
- Sistem yang dihasilkan memiliki fitur yang lebih sedikit
- Masalah terdeteksi lebih awal
- Desainnya lebih berkualitas
- Sistem yang dihasilkan lebih mudah perawatannya
- Pengembangan membutuhkan lebih sedikit usaha
Kekurangan
- Sistem yang dihasilkan memiliki lebih banyak fitur

- Kinerja sistem yang dihasilkan lebih buruk
- Desainnya memiliki kualitas yang lebih rendah
- Sistem yang dihasilkan lebih sulit untuk dipertahankan
- Pendekatan prototyping membutuhkan anggota tim yang lebih
berpengalaman
Gambar 3.4 Pro dan kontra dari prototyping
Pengguna serta pengembang umumnya lebih positif tentang sistem yang

dikembangkan menggunakan pendekatan prototyping. Sikap positif ini menyangkut
baik proses pengembangan maupun produk yang dihasilkan. Pengguna merasa
lebih terlibat dalam proses pengembangan dan memiliki lebih sedikit konflik dengan
para desainer. Keterlibatan pengguna yang luas menghasilkan sistem yang lebih
memuaskan kebutuhan pengguna.
Karena pengguna tidak perlu mengungkapkan semua kebutuhan mereka di
muka dalam pendekatan prototyping, ada sedikit kecenderungan untuk meminta bel
dan peluit. Akibatnya, hasil akhirnya adalah sistem yang lebih ramping yang
fungsionalitasnya lebih mendekati kebutuhan pengguna sebenarnya. Jika pengguna
diperlihatkan sistem yang berfungsi pada tahap awal dan diberi kesempatan untuk
mencobanya, kemungkinan besar masalah juga terdeteksi pada tahap awal. Hal ini
mencegah pemborosan tenaga kerja yang seharusnya diperlukan untuk mengulang
sebagian pekerjaan. Jika pengguna berada dalam posisi untuk mempengaruhi dan
memodifikasi desain, fitur sistem akan mencerminkan kebutuhan mereka dengan
lebih baik dan sistem akan lebih mudah digunakan.
Penggunaan alat atau bahasa prototyping tujuan khusus membuatnya mudah
untuk menambahkan fitur. Karena interval waktu antara versi prototipe yang
berurutan kecil, pengguna mungkin berpikir bahwa mudah untuk mewujudkan fitur
baru dan dapat menentukan persyaratan tambahan. Kedua efek ini dapat
menghasilkan sistem yang memiliki fitur lebih banyak, bukan lebih sedikit.
Pembuatan prototipe melibatkan langkah-langkah desain berulang dan, karena perhatian berulang
untuk desain, kualitasnya dapat meningkat. Karena diketahui secara apriori bahwa desainnya
akan berkembang selama langkah pembuatan prototipe berikutnya, perhatian yang lebih besar akan
diberikan kepada
faktor kualitas seperti fleksibilitas dan modularitas dan, sebagai hasilnya, kualitas desain mungkin
meningkatkan juga. Dalam pembuatan prototipe sekali pakai, kualitas desain akhir seringkali ditentukan
lebih tinggi karena pengalaman belajar dari langkah-langkah prototyping. Juga, final ini
langkah desain hampir tidak, jika ada, ditambal karena tindakan pengerjaan ulang. Karena ini
aspek, sistem yang dihasilkan sering ditemukan lebih mudah untuk dipelihara juga.
Di sisi lain, prototyping umumnya tidak menerapkan desain yang ketat dan
standar pembangunan. Jika kita prihatin dengan waktu pengembangan yang singkat, pasti
kegiatan yang diperlukan akan kurang mendapat perhatian. Kemungkinan besar dokumentasi itu
dikorbankan untuk kecepatan. Karena penambahan yang dihasilkan dari langkah pengerjaan ulang yang
sering,
kualitas desain prototipe evolusioner dapat memburuk. Untuk alasan itu juga,
sistem yang dihasilkan kurang dapat dipelihara. Terutama dalam prototipe evolusioner, the
kekokohan sistem seringkali akan kurang dari biasanya dengan yang lebih tradisional
mendekati. Dalam metode tangkas, refactoring diterapkan untuk mengatasi fenomena ini.
Terakhir, performa cenderung lebih buruk karena perhatian difokuskan pada fungsionalitas
dan ukuran kinerja tidak diambil sama sekali atau pada titik waktu tertentu
mereka menjadi terlalu sulit untuk disadari.
Secara umum dirasakan bahwa proyek prototyping membutuhkan tim yang berpengalaman.
Prototipe-
ing melibatkan pengambilan keputusan desain yang luas, terutama selama iterasi awal.
Dalam setiap iterasi, permintaan pengguna harus dipertimbangkan, baik secara timbal balik maupun
terhadap
kemudahan dan biaya realisasinya. Anggota tim yang tidak berpengalaman lebih mungkin
melakukannya
membuat pilihan yang buruk, sehingga sangat mengancam keberhasilan upaya pembuatan prototipe.
Dari diskusi ini, kami dapat mengumpulkan rekomendasi berikut untuk digunakan
teknik pembuatan prototipe:
– pembuatan prototipe sangat berguna dalam situasi di mana persyaratan
pengguna tidak jelas atau ambigu. Pembuatan prototipe tampaknya merupakan
cara yang baik untuk mengklarifikasi persyaratan tersebut;
– pembuatan prototipe juga sangat berguna untuk sistem dengan penekanan yang cukup besar
pada antarmuka pengguna dan yang menunjukkan tingkat interaksi pengguna yang tinggi;
– pengguna dan desainer harus sangat menyadari pendekatan prototyping dan

jebakannya. Pengguna harus menyadari bahwa mengubah perangkat lunak
tidak semudah itu. Pengguna juga harus menyadari bahwa prototipe adalah
prototipe dan bukan sistem kualitas produksi. Desainer harus menyadari
karakteristik prototyping proyek dan tidak menjadi frustrasi oleh perubahan
kebutuhan pengguna yang sering terjadi;
– pembuatan prototipe juga harus direncanakan dan dikendalikan. Kita harus

membatasi jumlah iterasi. Kita harus menetapkan prosedur eksplisit untuk
mendokumentasikan dan menguji prototipe. Aspek positif dari pendekatan
tradisional, yang membuat proses dapat dikelola dan dikendalikan, juga harus
diterapkan dalam kasus ini.
DIKUNJUNGI
Dengan mengambil tindakan balasan yang tepat, potensi kerugian prototyping dapat
dicegah. Prototyping kemudian menjadi model proses alternatif yang layak untuk
banyak proyek pengembangan perangkat lunak.
3.2.2 Pengembangan Inkremental

Pada bagian sebelumnya, kita membahas cara menggunakan prototipe yang sistem
finalnya adalah yang terakhir dari serangkaian prototipe. Di bawah kontrol
manajemen yang hati-hati untuk memastikan konvergensi, versi berikutnya
direncanakan untuk mengakomodasi kebutuhan pengguna baru atau yang berubah.
Ada cara lain untuk bekerja menuju sistem final dalam sejumlah iterasi.
Kami melanjutkan secara bertahap. Fungsionalitas sistem diproduksi dan dikirim
ke pelanggan sedikit demi sedikit. Berawal dari situasi yang ada kita bergerak
menuju situasi yang diinginkan dalam beberapa langkah (kecil). Dalam setiap
langkah ini, pendekatan bertahap yang kita ketahui dari model air terjun digunakan.
Mengembangkan perangkat lunak dengan cara ini menghindari efek 'Big Bang',
yaitu untuk waktu yang lama tidak terjadi apa-apa dan kemudian, tiba-tiba, ada
situasi yang benar-benar baru. Alih-alih membangun perangkat lunak, perangkat
lunak tumbuh. Dengan pendekatan inkremental ini, pengguna terlibat erat dalam
merencanakan langkah selanjutnya. Mengarahkan ulang proyek menjadi lebih
mudah karena kami dapat memasukkan keadaan yang berubah lebih cepat.
Pengembangan tambahan juga dapat digunakan untuk melawan sindrom
'kelebihan fungsi'. Karena pengguna merasa sulit untuk merumuskan kebutuhan
mereka yang sebenarnya, mereka cenderung menuntut terlalu banyak. Kurangnya
pengetahuan yang diperlukan tentang kelenturan perangkat lunak dan proses
pengembangannya, mereka mungkin cenderung berpikir bahwa semuanya dapat
dicapai. Akibatnya, fitur-fitur penting muncul di samping bel dan peluit dalam daftar
persyaratan. Analis tidak dapat membedakan satu dari yang lain, juga tidak dapat
secara akurat memperkirakan upaya yang diperlukan untuk mengimplementasikan
fitur individual. Kemungkinannya adalah bahwa banyak upaya dihabiskan untuk
mewujudkan fitur yang tidak benar-benar dibutuhkan. Akibatnya, banyak sistem saat
ini menawarkan fungsionalitas yang kaya, namun pada saat yang sama tidak cocok
untuk tugas yang ada. Untuk satu hal, sistem ini sulit digunakan hanya karena
kerumitan yang ditimbulkan oleh fungsionalitasnya yang kaya.
Dengan pendekatan inkremental, pertama-tama perhatian difokuskan pada
fitur-fitur penting. Fungsionalitas tambahan hanya disertakan jika dan saat
diperlukan. Sistem yang dikembangkan dengan demikian cenderung lebih ramping
namun memberikan dukungan yang memadai kepada penggunanya. Dengan
pendekatan inkremental, bagian yang paling sulit sering ditangani terlebih dahulu,
atau bagian yang memiliki risiko tertinggi sehubungan dengan keberhasilan
penyelesaian proyek. Mengikuti garis pemikiran ini, Boehm (1988)
menyarankan model spiral dari proses pengembangan perangkat lunak, di mana
setiap belitan dari spiral memunculkan aktivitas berikut:
– mengidentifikasi sub-masalah yang memiliki risiko terkait tertinggi;
– menemukan solusi untuk masalah itu;

Berbagai model proses yang dibahas sebelumnya dapat digabungkan dengan spiral Boehm
model dengan cara alami (lihat gambar 3.5):
– Jika mendapatkan kumpulan persyaratan pengguna yang tepat dipandang
sebagai area dengan risiko tertinggi, ikuti spiral beberapa kali untuk
menyelesaikan sub-masalah ini (yaitu, prototipe).
– Jika, mulai dari spesifikasi persyaratan yang tepat, pertanyaan utamanya
adalah untuk mendapatkan sistem yang kuat dan terdokumentasi dengan baik,
ikuti spiral sekali, menggunakan model proses tradisional dengan fase dan
tonggak yang sesuai sebagai langkah perantara.
– Jika mengembangkan perangkat lunak secara bertahap, lacak spiral beberapa kali, sekali
untuk setiap kenaikan.
– Selama pemeliharaan, kesalahan yang dilaporkan atau persyaratan yang berubah menjadi
pemicu
untuk melacak spiral.
Dilihat dengan cara ini, model spiral memasukkan model proses lain yang dibahas
jauh.
Pengembangan inkremental sangat dianjurkan oleh Gilb (1988). Itu diragukan
apakah penambahan waktu yang dianjurkan oleh Gilb, hingga maksimal beberapa minggu,
selalu masuk akal. Tetapi keuntungan dari pengembangan inkremental dipertimbangkan
bahkan dengan peningkatan waktu yang berbeda. Kejutan yang mengintai di dalam tradisional
pendekatan dan yang menimbulkan kesulitan yang cukup besar pada sisi manajemen perangkat lunak
proyek pengembangan dapat sangat berkurang ketika perangkat lunak dikembangkan dan
disampaikan secara bertahap.
3.2.3 Pengembangan Aplikasi Cepat dan

DSDM
Rapid Application Development (RAD) memiliki banyak kesamaan dengan iteratif lainnya
model proses pembangunan. Ini menekankan keterlibatan pengguna, membuat prototipe, menggunakan
kembali, dan
penggunaan alat otomatis, dan tim pengembangan kecil. Selain itu juga mempekerjakan
pengertian dari a kotak waktu, kerangka waktu tetap di mana kegiatan dilakukan. Di sebagian besar
model pengembangan, serangkaian persyaratan diperbaiki dan kemudian proyek mencoba
melakukannya
memenuhi persyaratan ini dalam beberapa perkiraan periode waktu. Di dalam RAD,
kerangka waktu diputuskan terlebih dahulu dan kemudian proyek mencoba mewujudkan permintaan
tersebut
fungsi dalam jangka waktu tersebut. Jika ternyata tidak semua fungsi bisa
direalisasikan dalam kerangka waktu, beberapa fungsi dikorbankan. Yang setuju
batas waktu namun tidak bergerak.
Siklus hidup RAD terdiri dari empat fase:
– perencanaan kebutuhan,
– desain pengguna,
– konstruksi,
DIKUNJUNGI
Gambar 3.5 Model spiral (Sumber: B.W. Boehm, Model spiral pengembangan dan
peningkatan perangkat lunak, Komputer IEEE 21:5 (1988) 1988 IEEE.)
– pemotongan.
Fase perencanaan kebutuhan dan desain pengguna memiliki banyak kesamaan dan
mungkin digabungkan untuk proyek yang lebih kecil. Bersama-sama, mereka
biasanya memakan waktu kurang dari dua bulan. Teknik utama yang digunakan
dalam fase ini dikenal sebagai Perencanaan Kebutuhan Bersama (JRP) dan Desain
Aplikasi Bersama (JAD). Kedua teknik ini banyak menggunakan bengkel tempat
pengembang dan calon pengguna bekerja bersama (maka kata sifat Persendian).
Tujuan dari lokakarya JRP adalah untuk mendapatkan persyaratan yang benar
pada kali pertama. Oleh karena itu, sangat penting bagi pemain kunci, yaitu
pengguna akhir sistem,
hadir. Selama lokakarya JRP juga, persyaratan diprioritaskan, karena kemungkinan
tidak semuanya akan diterapkan di versi pertama sistem. Prioritas kebutuhan ini
dikenal sebagai triase. Triase biasanya berarti proses yang digunakan di medan
perang dan di ruang gawat darurat untuk memilah orang yang terluka ke dalam
kelompok berdasarkan kebutuhan mereka atau kemungkinan mendapat manfaat
dari perawatan medis segera. Di RAD, proses triase digunakan untuk memastikan
bahwa persyaratan yang paling penting ditangani terlebih dahulu. Hasil dari proses
ini sering kali berupa prioritas yang dilambangkan dengan akronim MoSCoW:
�
DIKUNJUNGI
Ada banyak variasi model proses RAD yang dijelaskan di atas. Sebagai contoh,
dimungkinkan untuk memiliki kotak waktu yang eksplisit untuk pembangunan
masing-masing prototipe perantara juga. Dimungkinkan juga untuk mengadakan
sesi JRP atau JAD setelah setiap siklus pembuatan prototipe. Namun, bahan
utamanya tetap: pembuatan prototipe, keterlibatan pengguna yang cukup besar, tim
SWAT, dan kotak waktu.
JRP dan JAD memiliki banyak kesamaan dengan metode desain yang dikenal
sebagai ParticipatoryDesign (PD), atau sekolah pengembangan perangkat lunak
Skandinavia. Keduanya menekankan keterlibatan pengguna akhir. Namun, mereka
berbeda dalam tujuan mereka. Keterlibatan pengguna dalam JRP dan JAD terutama
ditujukan untuk mempercepat proses menghasilkan sistem yang tepat. Keterlibatan
pengguna dalam PD dilatarbelakangi oleh minat yang kuat terhadap konteks sosial
lingkungan kerja.
Kerangka kerja terkenal yang dibangun di atas RAD adalah DSDM. DSDM
adalah singkatan dari Metode Pengembangan Sistem Dinamis. DSDM didasarkan
pada sembilan prinsip yang digambarkan pada Gambar 3.6. DSDM adalah kerangka
nirlaba, dikelola oleh DSDMConsortium1. Deskripsi kerangka kerja tingkat tinggi
diberikan dalam (Stapleton, 2003). Rangkaian lengkap praktik DSDM hanya tersedia
untuk anggota Konsorsium DSDM. Proses DSDM memiliki lima fase; lihat juga
gambar 3.7:
�
3.2. METODE CEPAT 6
1
Prinsip
Keterlibatan pengguna aktif sangat penting
DSDM tim harus menjadi

diberdayakan untuk membuat keputusanFokusnya adalah pada pengiriman produk
yang sering Pengguna
Kecocokan untuk tujuan bisnis adalah kriteria penting untuk penerimaan kiriman mendukung
tim di
seluruh
proyek,
bukan
hanya
Iteratif Dan tambahan selama
pengembangan diperlukan untuk berkumpul pada solusi bisnis yang akurat persyaratan
Semua perubahan selama pengembangan bersifat reversibel elisitasi dan
Persyaratan didasarkan pada tingkat tinggi penerimaan
pengujian.
Pengujian terintegrasi sepanjang siklus hidup
Saluran
komunikasi
pendek
disimpan
antara tim
pengemban
g dan
pengguna.
A kolaboratif Dan bersama Tim harus
bisa
pendekatan operatif antara semua pemangku kepentingan sangat penting
mengambil
keputusan
dengan
cepat.
Momentum
hilang jika
tim harus
menunggu
persetujuan
eksternal
dari setiap
keputusan
kecil
Pengiriman
yang sering
memungkin
kan umpan
balik yang
sering dari
komunitas
pengguna,
dan kontrol
yang sering
pada
proses
pengambila
n keputusan
oleh
manajer
Penekanann
ya adalah
pada
penyampaia
n produk
yang tepat,
bukan pada
pelapisan
emas atau
kesesuaian
dengan
spesifikasi
P
er
sy
ar
at
a
n
ti
d
a
k
d
a
p
at
s
e
p
e
n
u
h
n
y
a
di
te
nt
u
k
a
n
di
m
u
k
a.
Si
st
e
m
p
er
lu
b
er
e
v
ol
u
si,
d
a
n
p
e
n
g
er
ja
a
n
ul
a
n
g
a
d
al
a
h
fa
kt
a
k
e
hi
d
u
p
a
n
Jalan yang
salah dapat
diambil, dan
mundur
adalah
kemudian
diharuskan
untuk
sampai ke
titik aman
lagi
Persyaratan
tingkat tinggi
ditentukan
selama
fase studi
bisnis,
sementara
persyaratan
rinci-
ments
ditentukan
selama fase
iteratif
kemudian
Pengujian
tidak
ditunda
sampai
setelah
pengkodean
selesai
selesai. Hal
ini dilakukan
secara
bertahap,
setelah
setiap com-
komponen
ditulis
Tanggung
jawab
dibagi, dan
kebutuhan
pengemban
g
dukungan
dari
pengguna
akhir untuk
memutuska
n apa yang
akan
dikembangk
an
Gambar 3.6 Prinsip-prinsip DSDM
�
DIKUNJUNGI
Kelayakan
Belajar
Bisnis
Belajar
Model Fungsional Penerapan

Pengulangan
Desain & Bangun

Pengulangan
Gambar 3.7 Proses DSDM
tingkat.
Misalnya, kami tahu bahwa pembacaan kode oleh teman Anda, seperti yang
dilakukan dalam penelusuran dan pemeriksaan kode (lihat juga bab 13) adalah
metode pengujian yang sangat efektif. Di XP, seseorang melakukan ini sepanjang
waktu: dua pemrogram bekerja bersama di belakang satu layar komputer. Salah
satu dari mereka melakukan pengkodean, yang lain melihat ke belakang, memberi
nasihat, memperhatikan kesalahan kecil, mengajukan pertanyaan, dan sejenisnya.
Mereka berperan sebagai pilot dan co-pilot. Kapan saja, peran dapat berubah.
Praktek ini disebutpasangan pemrograman.
Kumpulan lengkap praktik XP diberikan pada gambar 3.8. Biasanya, tim XP
tidak terlalu besar, dan menempati satu ruangan. Rapat perencanaan sangat
singkat, dan melibatkan fungsionalitas langsung untuk dikirimkan ke pelanggan.
Perencanaan melibatkan pelanggan dan orang-orang teknis. Pelanggan harus
menetapkan prioritas, menentukan tanggal rilis, dan sejenisnya. Pelanggan
menjelaskan fitur yang diinginkan dari sistem instories, pada kartu indeks.
Orang-orang teknis memperkirakan berapa lama waktu yang diperlukan untuk
mengimplementasikan sebuah cerita, memutuskan urutan cerita mana dalam satu
rilis yang akan diimplementasikan, dll.
Di XP, desain dibuat sesederhana mungkin. Karena masa depan,
bagaimanapun, tidak jelas, tidak ada gunanya merancang skema besar yang
bagaimanapun juga tidak akan diikuti. Sehingga
praktek XP Keterangan
Permainan Perencanaan
Cakupan rilis berikutnya ditentukan dengan cepat.
Rilis kecil Bila perlu, rencana diperbarui
Pertama-tama wujudkan sistem yang sederhana, lalu rilis
Metafora berikutnya
versi dalam siklus pendek
Desain sederhana Penggunaan metafora sederhana untuk keseluruhan sistem
Pastikan desainnya sesederhana mungkin
Pengujian setiap titik waktu. Hapus kerumitan sesegera mungkin
mungkin
Pemfaktoran ulang Pemrogram terus-menerus menulis unit test,
tomers menulis tes penerimaan
Pasangan pemrograman
Restrukturisasi sistem tanpa merubahnya
Kepemilikan kolektif perilaku, untuk meningkatkan kualitas
Semua kode ditulis oleh dua programmer sekaligus
Integrasi berkelanjutan40 mesin
Siapa pun dapat mengubah kode apa pun, di mana pun, kapan
jam seminggu pun
waktu
Pelanggan di tempat Sistem terintegrasi dan dibangun berkali-kali a
hari
Standar pengkodean Sebagai aturan, bekerja 40 jam seminggu. Kerja lembur
harus menjadi pengecualian
Miliki pengguna nyata di tim, penuh waktu
Tetapkan standar pengkodean untuk memudahkan komunikasi
Gambar 3.8 Praktik XP
desain hanya mencakup versi sistem saat ini. Setelah suatu tugas diselesaikan,
sistem diperiksa untuk melihat bagaimana hal itu dapat ditingkatkan (hapus kode duplikat, buat
sederhana, membuatnya lebih fleksibel). Ini disebut pemfaktoran ulang. Refactoring ini tidak perlu
terbatas pada kode sendiri. Setiap orang bertanggung jawab atas keseluruhan sistem. Untuk membuat
pekerjaan ini, seseorang perlu menetapkan standar pengkodean.
Ketika sebuah tim bekerja untuk mengimplementasikan sebuah cerita, tim tersebut menulis tes untuk
memeriksa
pelaksanaan cerita itu pada saat yang sama. Sebelum kode baru diperiksa,
semua tes ini harus berjalan dengan sukses. Setelah kode diperiksa, lengkap
test suite dijalankan, dan sekali lagi semua tes harus berjalan dengan sukses. Jika tidak, kode baru
dihapus lagi untuk memperbaikinya. Dengan cara ini, selalu ada sistem yang berjalan.
XP didasarkan pada lima prinsip yang mendorong praktiknya:
�
DIKUNJUNGI
bekerja dan apa yang tidak. Dengan sering mengirimkan sistem yang sedang
berjalan kepada pelanggan, pelanggan mempelajari nilai apa yang ditawarkan
sistem, dan fitur apa yang dibutuhkan selanjutnya.
�
3.3. PROSES TERPADU RASIONAL (RUP) 65
Gambar 3.9 Struktur proses RUP (Sumber: P. Kruchten, Proses Kesatuan Rasional, An
Perkenalan, 2003, Addison-Wesley)
di sebelah setiap alur kerja pada gambar 3.9. Struktur ini memungkinkan kita untuk membedakan antara
iterasi yang berurutan, dan tekankan bahwa iterasi yang berbeda memiliki penekanan yang berbeda. Dia
mengakui bahwa rekayasa persyaratan, desain, dll adalah kegiatan yang sedang berlangsung
daripada fase dengan waktu mulai dan akhir yang ketat.
Fase awal berfokus untuk memperjelas tujuan: apa ruang lingkupnya
proyek ini, apa batasannya, apa kriteria penerimaan yang akan
digunakan ketika sistem dikirim ke pelanggannya? Selama fase ini juga, secara keseluruhan
biaya, jadwal dan risiko diperkirakan. Kasus penggunaan kritis dikembangkan, serta a
calon arsitektur. Pada akhir fase ini, kasus bisnis untuk sistem harus
menjadi jelas. Ini mungkin menjadi masukan untuk keputusan go/no-go.
Fase elaborasi terutama ditujukan untuk menganalisis domain masalah, dan
memperoleh arsitektur suara. Pada akhir fase ini, sebagian besar kasus penggunaan akan terjadi
diidentifikasi, dan semua risiko utama harus diselesaikan.
Tahap konstruksi adalah manufaktur, proses pembangunan. Penekanannya
sedang mengembangkan produk yang dapat diterapkan. Komponen lengkap dikembangkan dan
diuji secara menyeluruh. Manual pengguna ditulis. Di akhir fase ini, yang pertama
versi operasional sistem, yaitu rilis beta, siap.
Pada fase transisi, sistem dirilis ke komunitas pengguna dan beta-
diuji. Selama fase ini, database mungkin harus diubah, pengguna dilatih dan,
dalam hal sistem pengganti, sistem lama yang diganti akan dihapus.
RUP didasarkan pada serangkaian praktik terbaik yang telah berkembang selama bertahun-tahun.
Ini
DIKUNJUNGI
praktik terbaik tercantum dalam Tabel 3.10. Banyak dari praktik terbaik ini tentu saja
juga hadir dalam model pengembangan lainnya. Poin kuat dari RUP adalah
menyediakan integrasi yang seimbang dari mereka. Mengingat latar belakangnya,
tidak mengherankan jika RUP diarahkan pada pengembangan sistem berorientasi
objek. Tapi RUP cocok untuk proyek dengan karakteristik yang sangat berbeda.
Penyesuaian RUP ke situasi di tangan meskipun diserahkan kepada pengguna
metode.
3.4 Selingan: Pemeliharaan atau

Evolusi
Program penggajian lama tidak pernah mati;
mereka hanya menjadi gemuk di bagian tengah
Robert Granholm (Datamasi, 1971)
Dalam bab 1, ditunjukkan bahwa upaya pemeliharaan yang cukup besar tidak dapat
dihindari. Setiap tugas pemeliharaan, apakah itu berkaitan dengan memperbaiki
kesalahan atau menyesuaikan sistem dengan kebutuhan pengguna baru, pada
prinsipnya memerlukan semua aspek siklus pengembangan awal. Selama
pemeliharaan, kami juga harus menganalisis masalah dan menyusun desain yang
kemudian diimplementasikan dan diuji.
Perbedaan besar pertama adalah bahwa perubahan ini dilakukan pada produk
yang sudah ada. Namun, selama pengembangan awal, kami juga sering tidak
memulai dari awal. Jika organisasi yang ada memutuskan untuk mengotomatiskan
administrasi pesanannya, sistem mungkin harus berinteraksi dengan sistem yang
sudah ada untuk, katakanlah, administrasi stok dan pembukuan. Dengan demikian,
aktivitas pemeliharaan berbeda derajatnya dari pengembangan awal, bukan secara
fundamental. Perbedaan relatif ini bahkan lebih jelas ketika sistem dibuat prototipe
atau dikembangkan secara bertahap.
Perbedaan utama kedua, tekanan waktu, memiliki dampak yang jauh lebih
besar. Tekanan waktu paling terasa saat memperbaiki kesalahan, karena itu sangat
mungkin bagian tertentu dari organisasi harus ditutup karena perangkat lunak tidak
beroperasi. Dalam kasus seperti itu, kami harus bekerja melawan waktu untuk
mengidentifikasi dan memperbaiki kesalahan. Seringkali seseorang menambal kode
dan melewatkan langkah analisis dan desain yang menyeluruh. Struktur sistem
cenderung menderita karena tambalan semacam itu. Entropi sistem meningkat,
yang menghambat aktivitas pemeliharaan selanjutnya. Lebih buruk lagi,
dokumentasi sistem mungkin tidak diperbarui. Perangkat lunak dan dokumentasi
terkait kemudian terpisah, yang sekali lagi akan menghambat aktivitas pemeliharaan
di masa mendatang. Pembahasan yang lebih rinci tentang masalah pemeliharaan
diberikan di bab 14.
Lehman dan rekan kerjanya telah secara ekstensif mempelajari dinamika sistem
perangkat lunak yang perlu dipertahankan dan diperbesar ukurannya. Berdasarkan
studi kuantitatif tersebut, mereka merumuskan hukum evolusi perangkat lunak
berikut (dijelaskan di bawah):
1. Hukum perubahan yang berkelanjutan Sebuah sistem yang digunakan

mengalami perubahan terus menerus, sampai dinilai lebih hemat biaya untuk
merestrukturisasi sistem atau menggantinya dengan versi yang benar-benar
baru.
3.4. INTERMEZZO: PEMELIHARAAN ATAU EVOLUSI 67
Praktek terbaik K
e
t
e
r
a
n
g
a
n
Pengembangan berulang Sistem dikembangkan dengan cara
iteratif. Ini
bukan proses yang tidak terkendali. Iterasi direncanakan,
dan kemajuan diukur dengan hati-hati.
Manajemen persyaratan RUP memiliki pendekatan
sistematis untuk memunculkan,
menangkap
ing dan mengelola persyaratan, termasuk kemungkinan
perubahan persyaratan ini.
Arsitektur dan Penggunaan com- Fase awal RUP menghasilkan
arsitektur
komponen mendatang Arsitektur ini digunakan
di sisa tahun
proyek. Itu dijelaskan dalam pandangan yang berbeda. RUP
mendukung pengembangan sistem berbasis komponen, di
mana setiap komponen adalah perangkat lunak nontrivial
dengan batasan yang jelas.
Pemodelan dan UML Sebagian besar RUP adalah
tentang mengembangkan model,
seperti
model kasus penggunaan, model pengujian, dll. Model ini
dijelaskan dalam UML.
Kualitas proses dan produk Kualitas bukanlah tambahan, tetapi
tanggung jawab dari
uct semua orang yang terlibat. Alur
kerja pengujian ditujukan
dengan sangat yakin bahwa tingkat kualitas yang
diharapkan terpenuhi.
Konfigurasi Dan mengubah Proyek pengembangan berulang
memberikan hasil yang luas
pengelolaan jumlah produk, banyak yang sering
diubah. Ini meminta prosedur yang baik untuk
melakukannya, dan dukungan alat yang sesuai.
Pengembangan berbasis kasus penggunaan Use case menggambarkan perilaku
sistem.
Mereka memainkan peran utama dalam berbagai alur kerja,
terutama persyaratan, desain, pengujian, dan alur kerja
manajemen.
Konfigurasi proses Tidak ada ukuran yang cocok untuk
semua. Meskipun RUP dapat
digunakan "sebagaimana adanya",
itu juga dapat dimodifikasi dan disesuaikan agar lebih sesuai
dengan keadaan tertentu.
Dukungan alat Agar efektif, pengembangan
perangkat lunak membutuhkan alat
mendukung. RUP didukung oleh berbagai macam alat,
terutama di bidang pemodelan visual dan manajemen
konfigurasi.
Gambar 3.10 Praktik terbaik RUP

DIKUNJUNGI
2. Hukum meningkatnya kompleksitas Suatu program yang diubah menjadi
semakin tidak terstruktur (entropi meningkat) dan dengan demikian menjadi lebih
kompleks. Seseorang harus menginvestasikan upaya ekstra untuk menghindari
peningkatan kompleksitas.
3. Hukum pengaturan diri Proses evolusi perangkat lunak mengatur sendiri dan
mempromosikan kelancaran pertumbuhan perangkat lunak.
4. Hukum kekekalan stabilitas organisasi (tingkat kerja invarian) Itu

kemajuan global dalam proyek pengembangan perangkat lunak secara statistik
tidak berubah.
5. Hukum konservasi keakraban Suatu sistem mengembangkan peningkatan

pertumbuhan yang konstan untuk mempertahankan keakraban organisasi
dengan sistem tersebut. Ketika peningkatan ini terlampaui, masalah yang
berkaitan dengan kualitas dan penggunaan akan terjadi.
6. Hukum pertumbuhan yang berkelanjutan Fungsionalitas suatu sistem perlu

terus menerus meningkat untuk menjaga kepuasan pengguna.
7. Hukum penurunan kualitas Kualitas sistem menurun, kecuali jika aktif

dipelihara dan disesuaikan dengan perubahan lingkungannya.
8. Hukum umpan balik sistem Evolusi perangkat lunak harus dilihat sebagai
sistem umpan balik untuk mencapai perbaikan.
Dalam publikasi awal, Lehman (1974) membandingkan pertumbuhan sistem
perangkat lunak dengan pertumbuhan kota dan birokrasi. Dia membuat perbedaan
antara aktivitas progresif dan anti-regresif dalam pengembangan perangkat lunak.
Lehman menganggap model ini juga berlaku untuk sistem sosial ekonomi. Di kota,
misalnya, kegiatan progresif berkontribusi pada peningkatan taraf hidup atau
kualitas hidup. Kegiatan anti-regresif, seperti pengumpulan sampah, berfungsi untuk
mempertahankan status quo. Jika perhatian tidak cukup diberikan pada aktivitas
anti-regresif tersebut, penurunan akan terjadi. Aktivitas anti-regresif seringkali tidak
menarik, secara politis. Ini adalah investasi di masa depan, yang sebaiknya
diserahkan kepada orang lain. (Fenomena yang sama dapat diamati dalam
pertumbuhan industri kimia dan masalah polusi yang diakibatkannya.) Menurut
Lehman, jenis aktivitas yang sama terjadi dalam proyek pengembangan perangkat
lunak. Menghasilkan kode baru dan mengubah kode yang ada adalah aktivitas
progresif. Ini adalah kegiatan yang menarik, menantang dan bermanfaat. Mereka
memberi pengguna fungsionalitas baru atau lebih baik. Menulis dokumentasi,
memperbaiki struktur kode, dan memelihara komunikasi yang baik antara
orang-orang yang terlibat adalah aktivitas anti-regresi. Mengabaikan aktivitas ini
mungkin tidak berbahaya dalam jangka pendek, tetapi pasti dalam jangka panjang.
Untuk setiap sistem, kita harus mencari keseimbangan yang tepat antara kedua
jenis aktivitas tersebut.
Cara kerja hukum ketiga (hukum pengaturan diri) dapat diilustrasikan melalui
gambar 3.11 yang menggambarkan pola pertumbuhan atribut sistem dari waktu ke
waktu. Atribut sistem meliputi panjang (diukur dalam baris kode), jumlah modul,
jumlah fungsi yang dapat dipanggil pengguna, dll. Sumbu waktu dapat menunjukkan
nomor rilis, jumlah bulan sistem beroperasi, atau sejenisnya. (Itu
3.4. INTERMEZZO: PEMELIHARAAN ATAU 69
EVOLUSI
data aktual yang dipelajari oleh Lehman menyangkut hubungan antara jumlah modul
dan nomor rilis sistem operasi OS360.)
Hubungan yang digambarkan pada gambar 3.11 hampir linier. Riak pada gambar adalah
sangat teratur juga. Periode lebih dari pertumbuhan linier bergantian dengan periode
kurang dari pertumbuhan linier. Lehman menjelaskan lebih dari pertumbuhan linier dengan menunjuk
tekanan dari pengguna untuk mendapatkan lebih banyak fungsi secepat mungkin. Para pengembang
atau pengelola cenderung membungkuk di bawah tekanan ini. Akibatnya, seseorang menggunakan trik
dan pintasan dalam kode, dokumentasi tertinggal, kesalahan diperkenalkan dan
sistem tidak cukup diuji. Setelah beberapa saat, lebih banyak perhatian diberikan pada anti-regresi
aktivitas: kode perlu difaktorkan ulang dan dokumentasi diperbarui sebelumnya
pertumbuhan lebih lanjut adalah mungkin. Kedua jenis aktivitas ini stabil dari waktu ke waktu.
Gambar 3.11 Pertumbuhan atribut sistem dari waktu ke waktu
Hukum keempat (hukum kekekalan stabilitas organisasi) tampaknya lebih baik

mengejutkan pada pandangan pertama. Lehman dan Belady menemukan hal-hal seperti tenaga kerja
dan sumber daya lain tidak berkorelasi sama sekali dengan kecepatan pertumbuhan sistem atau
mengubah. Rupanya, sistem besar berada dalam kondisi jenuh. Lebih banyak orang
dapat tetap bekerja tetapi, dalam jangka panjang, mereka tidak memiliki dampak yang dirasakan pada
evolusi sistem.
Pertumbuhan lebih dari rata-rata dalam beberapa versi sistem, di Lehman dan
Pengamatan Belady, hampir selalu diikuti oleh pertumbuhan yang kurang dari rata-rata di
versi berikutnya (seperti yang diungkapkan dalam hukum kelima - hukum kekekalan keakraban).
DIKUNJUNGI
Dalam salah satu sistem yang mereka selidiki, pertumbuhan yang jauh lebih tinggi
pasti menimbulkan masalah: keandalan yang lebih rendah, biaya yang lebih tinggi,
dll. Rupanya, sebuah organisasi harus mempertahankan keakraban yang cukup
dengan perangkat lunaknya. Di sini juga, umpan balik yang mengatur diri sendiri
diamati.
Dari pembahasan sebelumnya, maka kita harus waspada selama pemeliharaan.
Kami harus menjaga kualitas di setiap langkah. Kami dapat mencoba untuk
menghindari bahaya yang digambarkan di atas dengan melibatkan diri kami secara
eksplisit dalam berbagai fase pengembangan selama pemeliharaan. Proses siklik
yang diikuti selama pengembangan awal kemudian terjadi selama pemeliharaan
juga. Seperti prototyping, waktu yang dibutuhkan untuk melewati siklus lengkap
pada umumnya akan jauh lebih singkat daripada selama pengembangan awal. Cara
memandang pemeliharaan ini sangat mirip dengan pandangan evolusi
pengembangan perangkat lunak. Menyadari versi pertama dari sistem perangkat
lunak hanyalah langkah pertama. Cukup benar, langkah pertama ini lebih mahal
daripada kebanyakan langkah berikutnya, tetapi tidak berbeda secara mendasar.
Dalam bab 1 kita telah memperhatikan bahwa pendekatan semacam itu mungkin
juga memiliki efek positif pada lingkungan sosial dan organisasi tempat
pengembangan perangkat lunak berlangsung.
Model air terjun memberi kita a statis melihat sistem yang akan dikembangkan.
Realitas berbeda. Dalam mengembangkan perangkat lunak, dan khususnya selama
pemeliharaan, kami memperhatikan sistem yang berkembang. Seperti yang
dikatakan sebelumnya: perangkat lunak tidak dibangun, ia tumbuh.
3.5 Lini Produk Perangkat Lunak

Ketika produk serupa dikembangkan, kita mungkin berharap untuk menggunakan
kembali elemen dari produk sebelumnya selama pengembangan produk baru.
Seperti itu bukan kebiasaan dalam pengembangan perangkat lunak. Di banyak
organisasi tidak ada insentif untuk menggunakan kembali elemen (kode, desain,
atau artefak lainnya) dari sistem lain karena bukan itu yang kami bayar. Demikian
pula, tidak ada insentif untuk memproduksi elemen yang dapat digunakan kembali,
karena proyek saat ini adalah yang terpenting.
Sebagai alternatif, kita dapat memahami gagasan tentang a lini produk
perangkat lunak, satu set sistem perangkat lunak yang berbagi elemen. Dalam lini
produk perangkat lunak, penggunaan ulang direncanakan, bukan disengaja. Untuk
menjaga ruang lingkup dalam batas yang masuk akal, penggunaan kembali yang
direncanakan ini terkait dengan domain tertentu.
Misalkan kita telah mengembangkan sistem perpustakaan yang sukses untuk
perpustakaan fakultas ilmu komputer kita. Kemungkinan besar kita akan diminta
untuk mengembangkan sistem serupa untuk, katakanlah, fakultas ilmu bumi. Kami
menggunakan kembali sebanyak mungkin dari sistem pertama kami. Kemungkinan
juga, beberapa penyesuaian diperlukan untuk memuaskan fakultas lain. Mungkin,
mereka memiliki peta yang dapat dipinjam dan membutuhkan cara khusus untuk
menanganinya. Selanjutnya, fakultas lain mungkin datang dan meminta sistem
ketiga. Dan seterusnya. Daripada bertindak reaktif, dan menggunakan kembali
elemen yang sesuai dari upaya sebelumnya, kami juga dapat bertindak proaktif, dan
merencanakan pengembangan serangkaian sistem dalam domain otomatisasi
perpustakaan sejak awal.
3.6. PEMODELAN PROSES 71
Cara melakukan ini melibatkan dua proses: rekayasa domain dan aplikasi
rekayasa.
Dalam rekayasa domain, kami menganalisis domain yang akan kami kembangkan. Ini
proses memiliki siklus hidupnya sendiri. Ini menghasilkan satu set komponen yang dapat digunakan
kembali yang terbentuk
dasar produk yang akan dikembangkan. Biasanya juga, referensi arsitektur untuk
semua produk yang akan dikembangkan diproduksi juga. Langkah penting dalam proses ini
adalah untuk memutuskan ruang lingkup lini produk. Apakah kita akan mengembangkan produk
baris hanya untuk perpustakaan universitas, atau untuk perpustakaan pada umumnya? Yang pertama
lebih sederhana, tapi
memiliki pasar yang lebih terbatas. Yang terakhir berpotensi memiliki pasar yang lebih besar, tetapi
kemungkinan besar
menghasilkan arsitektur keseluruhan yang lebih kompleks dan produk yang lebih kompleks. Pelingkupan
untuk lini produk adalah masalah yang sulit. Itu dipengaruhi oleh strategi organisasi
dan membutuhkan wawasan tentang kemungkinan evolusi domain. Terakhir, domain
proses rekayasa menghasilkan rencana produksi, panduan bagaimana mengembangkan produk
dalam keluarga produk.
Rekayasa aplikasi menyangkut pengembangan produk individual. Dia
biasanya mengikuti skema seperti air terjun. Inputnya adalah output dari domain
proses rekayasa: arsitektur referensi, rencana produksi, dan himpunan
aset yang dapat digunakan kembali.
Organisasi lini produk sering kali memisahkan aktivitas rekayasa domain dari
kegiatan rekayasa aplikasi. Secara efektif, kegiatan ini kemudian menjadi terpisah
proyek. Pengembangan produk individu dapat menghasilkan produk baru atau diadaptasi
komponen yang mengarah pada adaptasi di tingkat keluarga produk, yang pada gilirannya
mempengaruhi
pengembangan produk selanjutnya. Akibatnya, ada loop umpan balik
dari proses rekayasa aplikasi ke proses rekayasa domain dan sebaliknya
sebaliknya.
Lini produk perangkat lunak sangat cocok di domain yang memiliki banyak
variasi produk yang cukup mirip, seperti ponsel, televisi, kamera.
Perusahaan yang beroperasi di domain ini telah memelopori bidang lini produk.
Diskusi yang lebih rumit tentang penggunaan kembali perangkat lunak dan lini produk perangkat
lunak diberikan
dalam bab ??. Arsitektur perangkat lunak dibahas dalam bab 11.
3.6 Pemodelan Proses

Tanpa proses berulang, satu-satunya hasil berulang yang mungkin Anda hasilkan adalah
kesalahan.
(Makala et al., 1996)
Pada 1980-an, Osterweil meluncurkan ide untuk menggambarkan proses

pengembangan perangkat lunak sebagai program. Ini program proses ditulis dalam
a memproses bahasa pemrograman. Seperti bahasa pemrograman lainnya,
bahasa pemrograman proses memiliki sintaks dan semantik yang didefinisikan
secara ketat. Sebagai contoh sederhana, perhatikan seperti Pascal
DIKUNJUNGI
deskripsi proses review pada gambar 3.12.2 Ini menggambarkan langkah-langkah
berurutan dari proses peninjauan. Prosesnya memiliki dua masukan: dokumen yang
akan ditinjau dan beberapa nomor yang berfungsi sebagai ambang batas. Rutin
mengembalikan boolean yang menunjukkan apakah tinjauan lain akan dijadwalkan
atau tidak.
fungsi ulasan (dokumen, ambang batas): boolean;

mulai mempersiapkan-review;
hold-review(dokumen, tidak ada masalah);
buat-laporan;
kembali tidak ada masalah <
3.6. PEMODELAN PROSES 73
Gambar 3.13 Diagram transisi status dari proses peninjauan
Gambar 3.14 Tampilan jaring petri dari proses peninjauan
Jaring petri adalah teknik pemodelan yang menarik untuk proses, karena memungkinkan a
sejumlah nondeterminisme dan paralelisme. Misalnya proses pada gambar
3.14 tidak menentukan urutan aktivitas pengkodean dan penjadwalan
dilakukan. Mereka mungkin berjalan secara paralel; sinkronisasi terjadi ketika keduanya
selesai.
Deskripsi yang tepat dari proses perangkat lunak, baik itu dalam bahasa pemrograman
notasi, notasi grafis, atau lainnya, melayani tiga tujuan utama:
�
DIKUNJUNGI
proyek, orang harus bekerja sama. Oleh karena itu, mereka perlu memiliki
pandangan bersama tentang proses yang akan dilakukan dan peran yang
harus mereka mainkan dalam proses tersebut. Model proses peninjauan yang
diberikan di atas dapat digunakan untuk tujuan ini.
�
3.7. RINGKASAN 75
�
76 SIKLUS HIDUP PERANGKAT
LUNAK DIKUNJUNGI
3.8 Bacaan lebih
lanjut
Model air terjun umumnya dikaitkan dengan Royce (1970) dan menjadi terkenal
melalui Boehm (1976). Namun, pendekatan bertahap yang jelas untuk
pengembangan perangkat lunak, termasuk iterasi dan umpan balik, sudah dapat
ditemukan di publikasi sebelumnya: (Benington, 1983) dan (Hosier, 1961).
Keuntungan dan kerugian prototyping, berdasarkan analisis dari 22 studi kasus
yang diterbitkan dan 17 akun tangan pertama, diberikan di (Gordon dan Bieman,
1994). (Verner dan Cerpa, 1997) membahas pandangan berbeda yang dipegang
oleh analis dan manajer profesional. dan kontra dari pembuatan prototipe.
Untuk pembahasan RAD yang sangat rumit, lihat (Martin, 1991). DSDM dibahas
dalam (Stapleton, 2003). Desain Partisipatif dijelaskan dalam (Floyd et al.,
1989).(CACM, 1993a) adalah edisi khusus tentang Desain Partisipatif. Ini berisi
artikel yang menjelaskan pengalaman dengan Desain Partisipatif, serta
perbandingan RAD dan Desain Partisipatif. (Kruchten, 2003) memberikan
pengenalan yang baik tentang RUP. Ada banyak buku tentang metode tangkas.
Buku standar XP dibuat oleh penemunya, Kent Beck (2000). Volume pendamping
yang baik adalah (Jeffries et al., 2001). Metode gesit lainnya termasuk Scrum
(Schwaber dan Beedle, 2002) dan keluarga Crystal dari metodologi (Cockburn,
2002). Untuk perbandingan sejumlah metode tangkas, lihat (Abrahamsson et al.,
2002). Boehm dan Turner (2003) membandingkan perencanaan-driven dan metode
gesit, dan memberikan saran kapan menggunakan jenis metode yang mana.
Lehman dan Belady (1985) memberikan ikhtisar tentang karya awal mereka
tentang hukum evolusi perangkat lunak. Lehman dkk. (1997) dan Cook et al. (2006)
memberikan perspektif yang diperbarui. Rumusan yang diberikan dalam bab ini
didasarkan pada (Lehman et al., 1997). Pandangan pengembangan perangkat
lunak seperti pabrik disarankan pada konferensi pertama tentang Rekayasa
Perangkat Lunak (McIlroy, 1968). Istilah 'pabrik perangkat lunak' juga sering
dikaitkan dengan upaya Jepang untuk meningkatkan produktivitas pengembangan
perangkat lunak (Cusumano, 1989). Gagasan lini produk perangkat lunak muncul di
tahun 80-an sebagai cara untuk meningkatkan skala ekonomi. Clements dan
Northrop (2001) dan Pohlet al. (2005) memberikan pembahasan mendalam tentang
rekayasa lini produk perangkat lunak. (Osterweil, 1987) meluncurkan ide
untuk menggambarkan proses pengembangan perangkat lunak sebagai program.
Penilaian kritis terhadap pandangan ini diberikan dalam (Lehman, 1987), (Curtiset
al., 1987) dan (Curtis, 1989). Kecenderungan saat ini dalam pemodelan proses
perangkat lunak dijelaskan dalam (Fuggetta dan Wolf, 1996).
Latihan
1. Jelaskan model pengembangan perangkat lunak air terjun.
2. Jelaskan pendekatan Rapid Application Development (RAD) untuk perangkat

lunak perkembangan.
3. Diskusikan perbedaan utama antara prototyping dan pengembangan inkremental

ment.
4. Diskusikan perbedaan utama antara pengembangan inkremental dan RUP.
5. Diskusikan hukum perubahan yang berkelanjutan.
6. Bagaimana model spiral menggolongkan prototyping, pengembangan inkremental,

dan model air terjun?
7. Jelaskan praktik XP 'pair programming' dan 'refactoring'.
8. Apa yang dimaksud dengan lini produk perangkat lunak?
9. Apa tujuan utama memiliki deskripsi eksplisit tentang perangkat lunak

proses pengembangan dalam model proses?
10. Apa itu pemberlakuan proses?
11. Diskusikan nilai kunci gerakan tangkas.
12. �
DIKUNJUNGI
proses proyek. Apakah menurut Anda ukuran ini cukup? Dapatkah Anda memikirkan
cara yang lebih baik untuk mengukur kemajuan?
18. ~
4
Manajemen konfigurasi
TUJUAN PEMBELAJARAN
�
80 MANAJEMEN KONFIGURASI
Prosedur yang hati-hati diperlukan untuk mengelola sejumlah besar elemen

(sumber
komponen kode, dokumentasi, permintaan perubahan, dll.) yang dibuat dan
diperbarui selama masa pakai sistem perangkat lunak besar. Ini terutama
berlaku di
proyek pembangunan terdistribusi. Ini disebut manajemen konfigurasi.
Selama proyek pengembangan perangkat lunak, cukup banyak dokumen yang

dihasilkan. Dokumen-dokumen ini juga berubah dari waktu ke waktu. Kesalahan
harus diperbaiki, permintaan perubahan harus diurus, dll. Jadi, pada setiap titik
waktu selama proyek, versi berbeda dari dokumen yang sama mungkin ada secara
paralel. Seringkali juga, sistem perangkat lunak itu sendiri tidak monolitik. Sistem
perangkat lunak ada versi atau konfigurasi yang berbeda. Versi yang berbeda
muncul ketika perubahan diimplementasikan setelah sistem dikirimkan ke
pelanggan. Dari waktu ke waktu, pelanggan dihadapkan dengan rilis baru. Versi
berbeda dari komponen sistem mungkin juga ada selama pengembangan. Misalnya,
jika permintaan perubahan telah disetujui, programmer dapat mengimplementasikan
perubahan tersebut dengan menulis ulang satu atau lebih komponen. Pemrogram
lain, bagaimanapun, mungkin masih menggunakan versi sebelumnya dari
komponen yang sama.
Konfigurasi yang berbeda juga muncul jika satu set komponen dapat dirakit ke
dalam sistem dengan lebih dari satu cara. Ambil contoh, sistem yang disebut ACK,
Amsterdam Compiler Kit (Tanenbaum et al., 1983). ACK terdiri dari sekumpulan
program untuk mengembangkan kompiler untuk bahasa mirip ALGOL. Komponen
penting dari ACK adalah:
– ujung depan untuk bahasa seperti Pascal, C, atau Modula-2. Ujung depan
untuk languageX akan menerjemahkan program dalam bahasa itu ke dalam
codeEM perantara universal;
– pengoptimal EM yang berbeda;
– ujung belakang, yang menerjemahkan kode EM ke kode assembler untuk

berbagai nyata mesin.
Kompiler kemudian diperoleh dengan memilih ujung depan untuk bahasa tertentu,
ujung belakang untuk mesin tertentu dan, secara opsional, satu atau lebih
pengoptimal. Setiap kompiler adalah konfigurasi, kombinasi elemen tertentu dari
sistem ACK. Sistem ACK adalah contoh lini produk, dari era sebelum gagasan itu
digunakan. Tugas utama manajemen konfigurasi dibahas di bagian 4.1.
Rencana Manajemen Konfigurasi menetapkan prosedur yang menjelaskan cara
mendekati manajemen konfigurasi. Isi dokumen ini dibahas di bagian 4.2.
Manajemen konfigurasi seringkali didukung oleh alat. Pembahasan alat-alat tersebut
sebagian besar ditunda hingga bab 15.
4.1. TUGAS DAN TANGGUNG JAWAB 81
4.1 Tugas dan

Tanggung Jawab
Manajemen konfigurasi berkaitan dengan manajemen semua artefak yang disediakan
dihasilkan selama proyek pengembangan perangkat lunak. Padahal konfigurasi
manajemen juga berperan selama fase operasional sistem, ketika berbeda
kombinasi komponen yang berbeda dapat dirakit menjadi satu sistem dan baru
rilis sistem dihasilkan, diskusi di bawah berpusat pada peran
manajemen konfigurasi selama pengembangan sistem.
Untuk saat ini kami akan berasumsi bahwa, kapan saja, ada satu pejabat
versi set lengkap dokumen yang terkait dengan proyek. Ini disebut
garis dasar. Garis dasar adalah 'spesifikasi atau produk yang telah ditinjau secara formal
dan disepakati, yang selanjutnya berfungsi sebagai dasar untuk pengembangan lebih lanjut, dan itu
dapat diubah hanya melalui prosedur kontrol perubahan formal '(IEEE610, 1990).
Dengan demikian, baseline adalah database proyek bersama, yang berisi semua item yang disetujui. Itu
baseline mungkin atau mungkin tidak disimpan dalam database nyata dan didukung oleh alat untuk
membantu
dalam mengambil dan memperbarui elemen-elemennya. Hal-hal yang terkandung dalam garis dasar
adalah
item konfigurasi. Item konfigurasi adalah 'kumpulan perangkat keras, perangkat lunak, atau
keduanya, yang ditujukan untuk manajemen konfigurasi dan diperlakukan sebagai satu kesatuan
dalam proses manajemen konfigurasi '(IEEE610, 1990). Konfigurasi yang memungkinkan
item adalah:
– komponen kode sumber,
– spesifikasi kebutuhan,
– dokumentasi desain,
– rencana pengujian,
- kasus uji,
- hasil tes,
– panduan pengguna.
Pada suatu saat, baseline akan berisi spesifikasi kebutuhan. Seiring waktu
lanjutkan, elemen akan ditambahkan: dokumen desain, komponen kode sumber, tes
laporan, dll. Tugas utama manajemen konfigurasi adalah menjaga integritas
set artefak ini.
Hal ini sangat penting jika perubahan harus dimasukkan. Seandainya,
selama pengujian, cacat utama pada beberapa komponen ditemukan. Kami kemudian harus
telusuri kembali langkah-langkah kami dan perbaiki tidak hanya komponen itu tetapi juga komponen
yang sesuai
dokumen desain, dan bahkan mungkin spesifikasi kebutuhan. Ini dapat mempengaruhi
pekerjaan yang dilakukan oleh orang lain masih menggunakan versi lama. Lebih buruk lagi, seseorang
lain mungkin ingin membuat perubahan pada komponen yang sama pada waktu yang sama.
4.1. TUGAS DAN TANGGUNG JAWAB 83
�
beberapa urutan angka misterius, sekarang diidentifikasi oleh beberapa garis dasar
ditambah serangkaian perubahan. Kumpulan perubahan mungkin kosong. Kami
dengan demikian menentukan
baseline X plus 'perbaiki masalah ukuran tabel'
daripada
F
4.3. RINGKASAN 87
bagaimana permintaan perubahan ditangani, bagaimana fase pengembangan
ditutup, bagaimana status sistem dipertahankan, bagaimana antarmuka antar
komponen diidentifikasi? Juga, hubungan dengan organisasi fungsional lainnya,
seperti pengembangan perangkat lunak dan penjaminan mutu, digambarkan.
Kegiatan Bagian ini menjelaskan bagaimana konfigurasi akan diidentifikasi dan dikendalikan
dan bagaimana statusnya akan dipertanggungjawabkan dan dilaporkan. Sebuah konfigurasi
diidentifikasi oleh a
baseline: deskripsi konstituen konfigurasi itu. Konfigurasi seperti itu
harus disetujui secara formal oleh pihak-pihak yang terlibat.
Diperlukan prosedur yang jelas dan tepat sehubungan dengan pemrosesan perubahan
permintaan jika proyek pengembangan perangkat lunak akan dikendalikan. Sebuah Konfigurasi
Control Board (CCB) biasanya memiliki tanggung jawab untuk mengevaluasi dan menyetujui atau
menolak
perubahan yang diusulkan. Kewenangan, tanggung jawab, dan keanggotaan CCB harus
dinyatakan. Karena komponen perangkat lunak biasanya tergabung dalam pustaka, prosedur
untuk mengendalikan perpustakaan ini harus ditetapkan juga.
Untuk dapat mengontrol proyek pengembangan perangkat lunak, data harus
dikumpulkan dan diproses. Informasi yang biasanya diperlukan meliputi: saat ini
status komponen, versi dan permintaan perubahan, serta laporan yang disetujui
perubahan dan penerapannya.
Perubahan pada item konfigurasi dapat memengaruhi item di luar cakupan rencana,
seperti barang-barang perangkat keras. Item eksternal ini harus diidentifikasi dan antarmuka mereka
dikendalikan. Dengan nada yang sama, antarmuka ke item yang dikembangkan di luar proyek harus
diidentifikasi dan dikendalikan.
4.3 Ringkasan
Manajemen konfigurasi berkaitan dengan manajemen semua artefak yang
dihasilkan selama proyek pengembangan perangkat lunak. Ini memerlukan kegiatan
utama berikut:
�
88 MANAJEMEN
KONFIGURASI
1. Perkenalan
A. Tujuan
B. Cakupan
C. Definisi dan singkatan
D. Referensi
2. manajemen SCM
A. Organisasi
B. tanggung jawab SCM
C. Kebijakan, arahan dan
3. prosedur yang berlaku
kegiatan SCM
A. Identifikasi konfigurasi
B. Kontrol konfigurasi
C. Akuntansi status konfigurasi
D. Audit dan tinjauan
konfigurasi
e. Kontrol antarmuka
F. Kontrol subkontraktor/vendor
4.
Jadwal SCM
5. sumber daya SCM
6. pemeliharaan rencana SCM
Gambar 4.4 Contoh struktur rencana manajemen konfigurasi perangkat lunak

(SCM)(Sumber: Standar IEEE untuk Rencana Manajemen Konfigurasi Perangkat
Lunak, IEEE Std828-1990. Direproduksi dengan izin IEEE.)
set lengkap dokumen yang berhubungan dengan proyek. Tugasnya dan prosedur
lebih lanjut untuk manajemen konfigurasi diatur dalam dokumen terpisah, Rencana
Manajemen Konfigurasi.
Sejarah dan pengembangan manajemen konfigurasi terkait erat dengan sejarah
dan pengembangan alat manajemen konfigurasi. Pada awalnya, alat ini
menekankan pencatatan perubahan file fisik. Ada sedikit dukungan untuk aspek
proses. Sistem manajemen konfigurasi masa kini menangani aspek proses juga
(manajemen alur kerja) dan banyak yang telah mengadopsi orientasi perubahan di
samping atau alih-alih tampilan konfigurasi berorientasi versi. Semakin banyak, alat
manajemen konfigurasi berfungsi sebagai alat manajemen dokumen yang
mendukung kerja sama di antara sekelompok orang, mungkin didistribusikan ke
beberapa situs, bekerja bersama pada kumpulan objek bersama.
4.4 Bacaan lebih

lanjut
Pengantar yang dapat dibaca untuk topik manajemen konfigurasi diberikan di
(Babich, 1986). Sumber yang lebih baru adalah (Jonassen Hass, 2002). Estublier et al. (2005)
memberikan gambaran yang sangat baik dari perkembangan utama di lapangan. weber (1996)
dan Wiborg-Weber (1997) menjelaskan manajemen konfigurasi yang berorientasi pada perubahan
teknologi.
Referensi lebih lanjut tentang aspek teknis manajemen konfigurasi diberikan di
bab selanjutnya, ketika alat untuk konfigurasi dan kontrol versi dibahas.
Latihan
1. Apa tugas utama manajemen konfigurasi?
2. Jelaskan peran Papan Kontrol Konfigurasi.
3. Apa itu item konfigurasi?
4. Apa itu garis dasar?
5. Jelaskan perbedaan antara konfigurasi berorientasi versi dan berorientasi perubahan

manajemen urasi.
6. Diskusikan isi utama rencana manajemen konfigurasi.
7. ~
5
Manajemen Orang dan
Organisasi Tim
TUJUAN PEMBELAJARAN
�
91
Menemukan kerangka kerja organisasi yang tepat dan campuran keterampilan yang tepat
untuk a
tim pengembangan adalah masalah yang sulit. Sedikit teori beralasan tersedia
untuk ini. Namun, banyak cerita tentang proyek yang berhasil dan kurang berhasil
beberapa seluk-beluk masalah tim proyek. Bab ini menggambarkan jurusan
masalah yang terlibat.
Orang adalah aset organisasi yang paling penting

(Humphrey, 1997a)
Di sebagian besar organisasi yang mengembangkan perangkat lunak, pemrogram, analis, dan
profesional lainnya
sional bekerja sama dalam tim. Struktur tim yang memadai bergantung pada banyak faktor,
seperti jumlah orang yang terlibat, pengalaman dan keterlibatan mereka dalam
proyek, jenis proyek, perbedaan individu dan gaya. Faktor-faktor ini juga mempengaruhi
ence cara proyek yang akan dikelola. Dalam bab ini, kita membahas berbagai aspek
manajemen orang, serta beberapa organisasi tim yang lebih umum untuk
proyek pengembangan perangkat lunak.
Pekerjaan yang harus dilakukan dalam kerangka proyek, baik itu perangkat lunak
proyek pengembangan, pembangunan rumah, atau desain mobil baru, melibatkan sejumlah hal
tugas. Bagian penting dari tanggung jawab manajemen adalah untuk mengkoordinasikan tugas semua
peserta.
Koordinasi ini dapat dilakukan dengan berbagai cara. Ada keduanya eksternal
dan pengaruh internal pada mekanisme koordinasi. Pengaruh internal berasal
dari karakteristik proyek. Pengaruh eksternal berasal dari proyek
lingkungan organisasi. Jika pengaruh ini meminta koordinasi yang bertentangan
mekanisme, konflik antara proyek dan lingkungan mengintai
sudut.
Pertimbangkan sebagai contoh proyek pengembangan perangkat lunak yang sangat inovatif, untuk
dilakukan di lingkungan instansi pemerintah. Karakteristik proyek mungkin
mintalah jenis mekanisme koordinasi yang fleksibel dan informal, di mana komitmennya
individu khusus, bukan kepatuhan ketat terhadap prosedur formal, adalah a
faktor penentu keberhasilan. Di sisi lain, lingkungan dapat diarahkan
sebuah birokrasi dengan kontrol terpusat, yang mencoba memaksakan prosedur formal
ke manajemen proyek. Kedua mekanisme ini tidak bekerja secara harmonis. Sebagai
konsekuensinya, manajemen dapat dihancurkan di antara kekuatan-kekuatan yang berlawanan itu.
Bagian 5.1 menguraikan lebih lanjut berbagai faktor internal dan eksternal yang mempengaruhi
cara proyek dikelola, dan menekankan perlunya memberi banyak perhatian
unsur manusia dalam manajemen proyek.
Pengembangan perangkat lunak melibatkan kerja sama tim. Anggota tim harus
mengoordinasikan pekerjaan mereka, mengomunikasikan keputusan mereka, dll. Untuk proyek kecil, tim
akan terdiri dari beberapa individu. Seiring bertambahnya ukuran proyek, demikian juga
tim. Namun, tim besar sulit dikelola. Mengkoordinasikan pekerjaan dari
tim besar itu sulit. Komunikasi antar anggota tim cenderung meningkat
eksponensial dengan ukuran tim (lihat juga bab 7). Oleh karena itu, tim besar
92 MANAJEMEN ORGANISASI DAN
ORGANISASI TIM
biasanya dibagi menjadi tim yang lebih kecil dengan cara yang membatasi sebagian
besar koordinasi dan komunikasi dalam sub-tim.
Bagian 5.2 membahas beberapa cara untuk mengatur tim pengembangan
perangkat lunak. Dari jumlah tersebut, organisasi hierarkis dan matriks juga dapat
ditemukan dalam jenis bisnis lain, sedangkan kepala pemrogram, SWAT, dan tim
tangkas agak spesifik untuk pengembangan perangkat lunak. Meskipun proyek open
source tidak memiliki sarana untuk memaksakan struktur tim, mereka biasanya
menyatu dengan organisasi seperti bawang seperti yang dibahas di bagian 5.2.6.
Karena outsourcing, perusahaan jaringan dan globalisasi, pengembangan
perangkat lunak telah menjadi kegiatan terdistribusi. Tim di, katakanlah, Amsterdam,
Boston, dan Bangalore mungkin harus bekerja sama dalam pengembangan sistem
yang sama. Bagaimana kita harus membagi tugas di antara kelompok-kelompok ini?
Bagaimana memastikan bahwa komunikasi antara kelompok-kelompok ini efektif?
Perbedaan budaya juga berperan dalam pembangunan multi-lokasi. Misalnya,
orang-orang di Asia menghormati otoritas. Di Amerika Utara, biasanya anggota tim
berdebat dengan manajer mereka. Manajer serta anggota tim harus menyadari
perbedaan tersebut, dan bertindak sesuai dengan itu. Masalah orang yang
memengaruhi pengembangan perangkat lunak multi-situs dibahas dalam bab ??.
5.1 Manajemen Orang

Sebuah tim terdiri dari individu-individu, yang masing-masing memiliki tujuan pribadi.
Merupakan tugas manajemen proyek untuk mengeluarkan tim dari individu-individu
ini, di mana tujuan individu direkonsiliasi menjadi satu tujuan proyek secara
keseluruhan.
Meskipun tujuan individu orang mungkin berbeda, penting untuk mengidentifikasi
tujuan proyek pada tahap awal, dan mengkomunikasikannya dengan jelas kepada
anggota proyek. Anggota proyek harus tahu apa yang diharapkan dari mereka. Jika
ada ketidakpastian dalam hal ini, anggota tim akan menentukan tujuan mereka
sendiri: satu pemrogram mungkin memutuskan bahwa efisiensi memiliki prioritas
tertinggi, yang lain mungkin memilih penggunaan memori yang efisien, sedangkan
yang ketiga akan memutuskan bahwa menulis banyak kode adalah yang terpenting.
Tujuan yang sangat berbeda dapat menyebabkan masalah yang parah.
Setelah tujuan proyek ditetapkan dan proyek sedang berjalan, kinerja anggota
proyek sehubungan dengan tujuan proyek harus dipantau dan dinilai. Ini bisa sulit,
karena banyak dari apa yang sedang dilakukan tidak terlihat dan kemajuan sulit
diukur.
Idealnya, kami ingin memiliki indikasi fungsionalitas yang dikirimkan dan
mendefinisikan produktivitas sebagai jumlah fungsionalitas yang dikirimkan per unit
waktu. Produktivitas sebagian besar didefinisikan sebagai jumlah baris kode yang
dikirimkan per bulan-orang. Semua orang akan setuju bahwa ukuran ini tidak
optimal, tetapi tidak ada yang lebih baik yang ditemukan. Salah satu bahaya besar
menggunakan ukuran ini adalah orang cenderung menghasilkan kode sebanyak
mungkin. Ini memiliki efek yang sangat merugikan. Pengemudi biaya yang paling
penting dalam proyek pengembangan perangkat lunak adalah jumlah kode yang
harus dikirimkan (lihat juga bab estimasi biaya). Menulis lebih sedikit kode lebih
murah,
5.1. MANAJEMEN ORANG 93
oleh karena itu, dan penggunaan kembali kode yang ada adalah salah satu cara untuk menghemat
waktu dan uang. Itu harus
oleh karena itu sangat dianjurkan. Menggunakan jumlah kode yang dikirimkan per orang-bulan
sebagai indikator produktivitas tidak menawarkan insentif untuk penggunaan kembali perangkat lunak.
Aspek lain dari penilaian orang terjadi dalam proses kelompok seperti peer review,
inspeksi dan walkthrough. Teknik ini digunakan selama verifikasi dan
kegiatan validasi, untuk menemukan kesalahan atau menilai kualitas kode atau dokumentasi
stasiun. Untuk membuat proses ini efektif, perlu dipisahkan dengan jelas
dokumen yang akan dinilai dari penulisnya. Weinberg Weinberg (1971) digunakan
istilah pemrograman tanpa ego dalam Konteks ini. Penilaian produk dari
pekerjaan seseorang tidak boleh menyiratkan penilaian terhadap orang itu.
Salah satu masalah utama dalam pengembangan perangkat lunak adalah koordinasi
kegiatan anggota tim. Sebagai proyek pembangunan tumbuh lebih besar dan menjadi
lebih kompleks, masalah koordinasi dengan cepat menumpuk. Untuk menangkal ini
masalah, manajemen memformalkan komunikasi, misalnya dengan formal
rapat proyek, inspeksi yang dipantau secara ketat, dan kontrol konfigurasi resmi
papan. Namun, komunikasi informal dan interpersonal dikenal sebagai yang utama
cara di mana informasi mengalir ke dalam dan melalui organisasi pengembangan. Dia
tidak bijaksana untuk mengesampingkan jenis komunikasi ini sama sekali.1 Informal, antarpribadi
komunikasi paling mudah dicapai jika orang-orang secara fisik berada dalam jarak dekat.
Lebih buruk lagi, orang cenderung memperdagangkan kemudahan informasi
diperoleh dengan kualitasnya. Mereka akan dengan mudah menerima nasihat tetangganya, sekalipun
mereka tahu bahwa nasihat yang jauh lebih baik dapat ditemukan di lantai berikutnya. Untuk menangkal
Kecenderungan ini, adalah bijaksana untuk menyatukan berbagai pemangku kepentingan dengan cara
yang terkendali
misalnya dengan melibatkan pakar domain dalam tim desain, dengan melibatkan pengguna
pengujian perangkat lunak, atau melalui pendekatan desain partisipatif. Kolokasi
semua pemangku kepentingan merupakan aspek utama dari tim tangkas.
Tim pengembangan perangkat lunak yang sukses menunjukkan perpaduan kualitas: teknis
kompetensi, empati pengguna akhir, dan kesadaran organisasi. Kompetensi teknis
tentu saja diperlukan untuk menghadirkan sistem berkualitas tinggi sejak awal. Pengguna akhir
empati dan kesadaran organisasi ada hubungannya dengan pengakuan individu
dan organisasi yang harus mengatasi sistem. Perpaduan dari orientasi ini
dalam tim membantu memastikan perhatian yang cukup diberikan pada masing-masing aspek ini (Klein
et al. (2002)).
Manajemen tim memerlukan banyak aspek, tidak kalah pentingnya
memperhatikan kepedulian terhadap unsur manusia. Keberhasilan di antara pengembangan perangkat
lunak
proyek sering dapat ditelusuri ke fokus yang kuat pada masalah budaya dan sosiologis,
seperti upaya menciptakan budaya bebas menyalahkan, atau ajakan komitmen dan
kemitraan. Bab ini hanya menyentuh beberapa aspek saja. (Brooks, 1995)
1Salah satu contoh cemerlang di sini adalah anekdot berikut dari (Weinberg, 1971). Manajer pusat
komputasi universitas mendapat keluhan tentang mahasiswa dan pemrogram yang mengobrol dan
menertawakan mesin kopi departemen. Menjadi manajer sejati, dan peduli dengan produktivitas, dia
memindahkan mesin kopi ke suatu tempat terpencil. Segera setelah itu, beban pada konsultan pusat
komputasi meningkat pesat. Kerumunan di dekat mesin kopi sebenarnya merupakan saluran komunikasi
informal yang efektif, yang melaluinya sebagian besar masalah diselesaikan.
ORGANISASI TIM
dan (DeMarco dan Lister, 1999) memberikan banyak pengamatan mendalam
mengenai elemen manusia dari manajemen proyek perangkat lunak.
Di sisa bagian ini kita akan membatasi diri pada dua taksonomi yang agak
umum untuk mekanisme koordinasi dan gaya manajemen.
5.1.1 Mekanisme Koordinasi

Dalam teks klasiknya Struktur dalam Panca: Merancang Organisasi yang Efektif,
Mintzberg membedakan antara lima konfigurasi organisasi yang khas. Konfigurasi
ini mencerminkan lingkungan yang khas dan ideal. Masing-masing konfigurasi ini
dikaitkan dengan mekanisme koordinasi tertentu: mekanisme yang lebih disukai
untuk mengkoordinasikan tugas-tugas yang harus dilakukan dalam tipe konfigurasi
tersebut. Konfigurasi Mintzberg dan mekanisme koordinasi terkait adalah sebagai
berikut:
�
5.1. MANAJEMEN ORANG 95
Mekanisme koordinasi yang dibedakan oleh Mintzberg sesuai dengan tipikal
konfigurasi organisasi, seperti rumah sakit, atau pabrik perakitan. Dalam pandangannya,
organisasi yang berbeda membutuhkan mekanisme koordinasi yang berbeda. Organisasi
tidak semuanya sama. Mengikuti garis pemikiran ini, faktor-faktor di luar perangkat lunak
proyek pembangunan cenderung memberikan pengaruh pada mekanisme koordinasi
untuk proyek itu.
Perhatikan bahwa sebagian besar organisasi nyata tidak cocok dengan jenis konfigurasi tunggal.
Berbeda
bagian dari satu organisasi mungkin diatur secara berbeda. Juga, Mintzberg's
konfigurasi mewakili cita-cita abstrak. Pada kenyataannya, organisasi mungkin cenderung ke arah itu
salah satu dari konfigurasi ini, tetapi membawa aspek yang lain juga.
5.1.2 Gaya Manajemen

Pengembangan sistem perangkat lunak, pembangunan rumah, dan perencanaan
dan partisipasi dalam liburan keluarga dapat dibandingkan karena masing-masing menyangkut a
usaha terkoordinasi yang dilakukan oleh sekelompok orang. Meskipun proyek-proyek ini mungkin
untuk ditangani dengan cara yang sangat berbeda, asumsi dasar yang mendasari mereka
struktur organisasi dan gaya manajemen memiliki banyak kesamaan.
Asumsi dasar ini dapat disorot dengan membedakan antara keduanya
dimensi dalam mengelola orang:
– Pengarahan hubungan Ini menyangkut perhatian pada individu dan hubungannya

hubungan dengan individu lain dalam organisasi.
– Pengarahan tugas Hal ini menyangkut perhatian terhadap hasil yang akan dicapai dan
cara di mana hasil ini harus dicapai.
Hubungan dan pengarahan tugas bisa tinggi atau rendah. Ini mengarah pada empat
kombinasi dasar, seperti yang digambarkan pada gambar 5.1. Jelas, kombinasi ini
sesuai dengan orientasi ekstrim. Untuk setiap dimensi, ada seluruh spektrum
kemungkinan.
Gambar 5.1 Empat gaya manajemen dasar, lih (Reddin, 1970)

ORGANISASI TIM
Gaya yang paling sesuai untuk situasi tertentu bergantung pada jenis pekerjaan
yang harus dilakukan:
�
5.2. ORGANISASI TIM 97
proyek. Perlu dicatat bahwa mekanisme koordinasi yang disarankan dalam bab 8
berasal dari faktor internal, yaitu karakteristik proyek di tangan. Seperti dicatat sebelumnya,
lingkungan proyek juga akan memberikan pengaruh pada organisasinya.
Perhatikan bahwa kami melihat dari manajer ke tim dan anggotanya di atas
diskusi. Atau, kita dapat melihat hubungan dan tugas kematangan individu
anggota tim. Kematangan hubungan menyangkut sikap karyawan terhadap mereka
pekerjaan dan manajemen. Kematangan tugas berkaitan dengan kompetensi teknis. Dia
penting bahwa manajer menyelaraskan urusannya dengan anggota tim dengan mereka
hubungan masing-masing dan kematangan tugas. Misalnya, lulusan baru mungkin memiliki nilai tinggi
kematangan tugas dan kematangan hubungan yang rendah, dan pengenalannya ke dalam tim yang
terampil
mungkin memerlukan beberapa panduan hati-hati.
5.2 Organisasi Tim

Dalam sebuah tim, peran yang berbeda dapat dibedakan. Ada manajer, penguji,
designer, programmer, dan sebagainya. Bergantung pada ukuran proyek, lebih dari
satu peran dapat dilakukan oleh satu orang, atau orang yang berbeda dapat memainkan peran yang
sama
peran. Tanggung jawab dan tugas dari masing-masing peran ini harus didefinisikan dengan tepat
dalam rencana proyek.
Orang bekerja sama dalam tim untuk mencapai hasil yang optimal. Namun demikian
disarankan untuk secara ketat memisahkan peran tertentu. Merupakan ide bagus untuk membuat tim
penguji
yang independen dari tim pengembangan. Demikian pula, jaminan kualitas harus, di
prinsipnya dilakukan oleh orang-orang yang tidak terlibat langsung dalam proses pembangunan.
Tim besar sulit dikelola dan karena itu sering dipecah menjadi lebih kecil
tim. Dengan jelas mendefinisikan tugas dan tanggung jawab dari berbagai sub-tim,
komunikasi dapat sebagian besar terbatas pada komunikasi antara anggota
sub-tim yang sama. Mengukur biaya komunikasi interpersonal menghasilkan wawasan
menjadi efek ukuran tim pada produktivitas dan membantu menyusun pengembangan besar
tim secara efektif. Beberapa rumus sederhana untuk melakukan hal itu diturunkan di bab 7.
Dalam subbagian berikut kita membahas beberapa bentuk organisasi perangkat lunak
tim pengembangan.
5.2.1 Organisasi Hirarki

Dalam lingkungan yang sepenuhnya didedikasikan untuk produksi perangkat lunak,
kita sering menjumpai struktur tim hierarkis. Tergantung pada ukuran
organisasi atau proyek, tingkat manajemen yang berbeda dapat dibedakan.
Gambar 5.2 memberikan contoh organisasi hierarkis. Persegi panjang menunjukkan
berbagai sub-tim di mana pekerjaan yang sebenarnya dilakukan. Node yang dilingkari menunjukkan
manajer. Dalam contoh ini, dua tingkat manajemen dapat dibedakan. Pada
tingkat yang lebih rendah, tim yang berbeda bertanggung jawab atas berbagai bagian proyek.
Para manajer pada tingkat ini memiliki tanggung jawab utama dalam mengkoordinasikan pekerjaan
ORGANISASI TIM
dalam tim masing-masing. Pada tingkat yang lebih tinggi, pekerjaan tim yang
berbeda dikoordinasikan.
Gambar 5.2 Sebuah organisasi tim hirarkis
Jenis organisasi hirarkis sering mencerminkan struktur global dari sistem yang
akan dikembangkan. Jika sistem memiliki tiga subsistem utama, mungkin ada tiga
tim, satu untuk setiap subsistem, seperti yang ditunjukkan pada gambar 5.2. Seperti
yang ditunjukkan dalam gambar ini, mungkin juga ada unit fungsional yang terkait
dengan tanggung jawab proyek yang spesifik, seperti penjaminan mutu dan
pengujian.
Tidaklah mungkin mengasosiasikan organisasi hierarkis hanya dengan salah
satu mekanisme koordinasi yang diperkenalkan di atas. Untuk setiap unit yang
diidentifikasi, salah satu dari mekanisme koordinasi
disebutkan sebelumnya adalah mungkin. Juga, seseorang tidak perlu
menerapkan mekanisme yang sama di setiap simpul hierarki. Namun, memiliki
mekanisme koordinasi yang berbeda dalam satu proyek yang sama bukan tanpa
masalah.
Berdasarkan analisis karakteristik berbagai subsistem, masing-masing manajer
mungkin ingin memilih gaya manajemen dan mekanisme koordinasi yang paling
sesuai dengan karakteristik tersebut. Jika satu atau lebih dari subsistem bersifat
sangat inovatif, manajemen mereka dapat memilih jenis koordinasi penyesuaian
timbal balik. Tingkat yang lebih tinggi dalam hierarki biasanya akan cenderung ke
arah mekanisme koordinasi berdasarkan beberapa bentuk standarisasi, dengan
memberlakukan aturan dan prosedur seperti dalam birokrasi mesin, atau mengukur
keluaran seperti dalam konfigurasi yang terdivisi. Dalam kasus seperti itu, kekuatan
internal dan eksternal mungkin berbenturan di satu atau lebih tingkat menengah.
Titik kritis lain dalam organisasi hierarki mana pun adalah jarak antara bagian
atas dan bagian bawah piramida hierarki. Pekerjaan 'nyata' umumnya dilakukan di
tingkat yang lebih rendah dari piramida ini. Orang-orang di tingkat yang lebih rendah
ini umumnya memiliki pengetahuan aplikasi yang sebenarnya. Semakin tinggi naik
dalam hierarki, semakin tidak spesifik pengetahuannya (inilah alasan utama
mengapa manajemen pada tingkat yang lebih tinggi ini cenderung ke arah
koordinasi melalui standardisasi). Namun, sebagian besar
keputusan diambil pada tingkat yang cukup tinggi. Dalam banyak kasus, sinyal dari level yang lebih
rendah
entah bagaimana dimasukkan di salah satu tingkat menengah.
Jika informasi merembes melalui berbagai tingkatan dalam hierarki, ia cenderung menjadi
semakin berwarna mawar. Skenario berikut ini tidak sepenuhnya fiktif:
– bawah: kami mengalami masalah parah dalam mengimplementasikan modul X;
– level 1: ada beberapa masalah dengan modul X;
– level 2: kemajuan stabil, saya tidak melihat adanya masalah nyata;
– atas: semuanya berjalan sesuai rencana kita.
Distorsi semacam ini sulit untuk dihindari sama sekali. Mereka, bagaimanapun,
diperkuat oleh fakta bahwa garis organisasi di mana kemajuan dilaporkan
juga merupakan garis di mana kinerja anggota tim diukur dan
dievaluasi. Setiap orang disukai oleh evaluasi positif dan karenanya cenderung berwarna
laporan sebagaimana mestinya. Jika data tentang kemajuan proyek sedang dikumpulkan dan diproses
oleh orang yang tidak terlibat langsung dalam penilaian anggota tim, Anda punya banyak
kemungkinan yang lebih tinggi bahwa informasi yang dikumpulkan memiliki keandalan yang memadai.
Aspek yang sama bermasalahnya dari organisasi hierarkis terletak pada kenyataan bahwa
seseorang dinilai, baik secara sosial maupun finansial, menurut tingkat di mana seseorang berdiri
dalam organisasi. Oleh karena itu wajar untuk bercita-cita ke tingkat yang lebih tinggi dan lebih tinggi di
dalam
hierarki. Namun, sama sekali tidak jelas bahwa ini diinginkan. Prinsip Petrus
mengatakan: dalam organisasi hierarkis setiap karyawan pada umumnya naik hingga mencapai a
tingkat di mana dia tidak kompeten. Programmer yang baik tidak harus menjadi manajer yang baik.
Pemrograman yang baik membutuhkan keterampilan tertentu. Untuk menjadi manajer yang baik,
diperlukan keterampilan yang berbeda
diperlukan. Dalam jangka panjang, tampaknya lebih bijaksana untuk mempertahankan orang pada
tingkat di mana mereka berada
bekerja dengan baik, dan berikan penghargaan yang sesuai.
5.2.2 Organisasi Matriks

Di lingkungan di mana perangkat lunak hanyalah produk sampingan, kita sering menjumpai beberapa
semacam organisasi matriks. Orang-orang dari departemen yang berbeda kemudian dialokasikan ke
proyek pengembangan perangkat lunak, mungkin paruh waktu. Dalam jenis organisasi ini
kadang-kadang sulit untuk mengontrol kemajuan. Seorang karyawan harus memuaskan beberapa
atasan dan
mungkin memiliki kecenderungan untuk mempermainkan satu bos melawan bos lainnya.
Kami juga dapat menggunakan organisasi matriks di lingkungan yang sepenuhnya berdedikasi
untuk pengembangan perangkat lunak. Jadi, unit dasarnya adalah kelompok kecil yang terspesialisasi.
Di sana
boleh lebih dari satu unit dengan spesialisasi yang sama. Spesialisasi yang mungkin adalah,
misalnya, pemrograman grafik, basis data, antarmuka pengguna, kontrol kualitas. Itu
unit diatur sesuai dengan spesialisasi mereka. Proyek, di sisi lain, mungkin
melibatkan unit dengan spesialisasi yang berbeda. Individu demikian diatur sepanjang dua sumbu,
satu mewakili berbagai kelompok spesialis dan satu mewakili proyek
yang ditugaskan kepada mereka. Jenis organisasi matriks ini digambarkan pada Gambar 5.3.
ORGANISASI TIM
Gambar 5.3 Sebuah organisasi

matriks
Dalam situasi seperti itu, manajer proyek bertanggung jawab atas keberhasilan
penyelesaian proyek. Manajer yang membawahi satu atau lebih unit dengan
spesialisasi yang sama memiliki misi jangka panjang, seperti mempertahankan atau
memperluas pengetahuan dan keahlian anggota timnya. Diungkapkan dalam hal
dimensi manajemen dasar yang dibahas sebelumnya, manajer proyek cenderung
menekankan pengarahan tugas, sedangkan manajer unit akan menekankan
pengarahan hubungan. Organisasi seperti itu bisa sangat efektif, asalkan ada rasa
saling percaya yang cukup dan kemauan untuk bekerja sama dan mengejar tujuan
proyek.
5.2.3 Ketua Tim Programmer

Sebuah organisasi tim yang dikenal sebagai kepala tim programmer diusulkan oleh
HarlanMills sekitar tahun 1970. Inti dari tim semacam itu terdiri dari tiga orang.
Chiefprogrammer adalah pemimpin tim. Dia menangani desain dan
mengimplementasikan bagian-bagian penting dari sistem. Kepala pemrogram
memiliki asisten yang dapat menggantikan kepala pemrogram, jika diperlukan.
Ketiga, pustakawan mengurus administrasi dan dokumentasi. Selain tiga orang ini,
tambahan (kecil) ahli dapat ditambahkan ke tim kepala pemrogram.
Dalam jenis organisasi ini, tuntutan yang cukup tinggi diberikan kepada kepala
pemrogram. Chief programmer harus sangat kompeten di bidang teknis, tetapi dia
juga harus memiliki kemampuan manajemen yang memadai. Dengan kata lain,
apakah ada cukup kepala pemrogram? Juga, pertanyaan tentang kompetensi
mungkin muncul. Chiefprogrammer memainkan peran yang sangat sentral. Dia
mengambil semua keputusan. Anggota tim lain mungkin menantang beberapa
kualitasnya.
Gagasan awal tentang tim kepala pemrogram tampaknya agak elitis. Itu mirip
dengan tim ahli bedah dalam penekanannya pada tugas yang sangat terspesialisasi
dan kepemimpinan yang karismatik. Manfaat dari sebuah tim yang terdiri dari
sekelompok kecil rekan-rekan dibandingkan tim pengembangan besar yang
berjuang untuk menghasilkan sistem perangkat lunak yang lebih besar dapat
diperoleh kembali dalam bentuk yang dimodifikasi dari tim kepala pemrogram.
Dalam bentuk yang dimodifikasi ini, aspek peer group berlaku. Tim
pengembangan kemudian terdiri dari sekelompok kecil orang yang secara kolektif
bertanggung jawab atas tugas yang ada. Secara khusus, pekerjaan tidak terstruktur
di sekitar tahapan siklus hidup. Tidak ada analis,
desainer, atau pemrogram, meskipun peran penguji dapat ditugaskan ke spesifik

orang. Tingkat keahlian yang berbeda dapat terjadi di dalam grup. Yang paling berpengalaman
masing-masing bertindak sebagai chief programmer dan wakil chief programmer. Pada
ujung skala lainnya, satu atau dua peserta pelatihan dapat berasimilasi dan mendapatkan yang
diperlukan
pelatihan di tempat kerja. Seorang peserta pelatihan dapat bertindak sebagai pustakawan tim.
5.2.4 Tim SWAT

Dalam proyek dengan model proses evolusioner atau iteratif seperti RAD, sebuah proyek
organisasi yang dikenal sebagai tim SWAT terkadang digunakan. SWAT adalah singkatan dari Terampil
Dengan Alat Canggih. Kami dapat melihat tim SWAT sebagai pengembangan perangkat lunak
versi tim proyek di mana baik tugas dan hubungan diarahkan tinggi.
Tim SWAT relatif kecil. Biasanya memiliki empat atau lima anggota. Lebih disukai,
tim menempati satu ruangan. Saluran komunikasi dibuat sangat pendek. Tim
tidak memiliki pertemuan formal yang panjang dengan risalah formal. Melainkan menggunakan bengkel
dan sesi curah pendapat yang tidak lebih dari cuplikan papan tulis
gambar dipertahankan.
Tim SWAT biasanya membangun versi inkremental dari sistem perangkat lunak. Di dalam
untuk melakukannya secara efektif, ia menggunakan komponen yang dapat digunakan kembali, bahasa
tingkat sangat tinggi,
dan generator perangkat lunak yang kuat. Pekerjaan anggota tim didukung dan
dikoordinasikan melalui groupware atau perangkat lunak manajemen alur kerja.
Seperti dalam tim kepala pemrogram, pemimpin tim SWAT seperti mandor
dalam industri bangunan: dia adalah seorang manajer sekaligus rekan kerja. Anggota dari a
Tim SWAT adalah generalis. Mereka mungkin memiliki spesialisasi tertentu, tetapi mereka juga harus
demikian
mampu melakukan berbagai tugas, seperti berpartisipasi dalam lokakarya dengan pelanggan,
membangun
prototipe, dan menguji perangkat lunak.
Motivasi tim sangat penting dalam tim SWAT. Tim SWAT sering mengadopsi
nama, moto, atau logo yang menarik. Label ini kemudian mengekspresikan visi mereka. Individu
memperoleh kebanggaan dan harga diri dari keanggotaan mereka dalam tim SWAT.
5.2.5 Tim Gesit

Pendekatan tangkas untuk pengembangan perangkat lunak tumbuh dari, dan memiliki banyak
kesamaan
dengan, berbagai pendekatan pembangunan iteratif. Dalam nada yang sama, tim yang gesit
memiliki banyak kesamaan dengan, misalnya, tim SWAT: kolokasi, komunikasi singkat
saluran, sikap yang berorientasi pada orang daripada yang formalistik. Seringkali, orang bekerja
berpasangan, dengan pilot dan co-pilot, tetapi tanpa hierarki.
Karena proses tangkas memiliki sedikit disiplin yang dipaksakan dari luar,
mereka membutuhkan disiplin untuk datang dari dalam tim. Tim yang tangkas membutuhkan disiplin diri.
Jika sepasang pemrogram mengembangkan beberapa kode dan pengujian berikutnya gagal, mereka
harus mengambilnya
mundur selangkah dan mengulang pekerjaan mereka. Setelah mereka menggabungkan sebuah karya,
mereka
harus mempertimbangkan sistem secara keseluruhan dan refactor jika diperlukan.
ORGANISASI TIM
Agar ini berhasil, tim yang gesit membutuhkan orang yang lebih baik daripada tim
yang bekerja sesuai dengan pendekatan yang didorong oleh perencanaan. Dalam
pendekatan yang digerakkan oleh perencanaan, rencana tersebut bekerja seperti
jaket pelampung yang dapat digunakan kembali oleh orang-orang. Dalam tim yang
gesit, tidak ada jaket pelampung seperti itu, dan orang harus memiliki keterampilan
berenang. Dalam hal tingkat pemahaman Cockburn (lihat Gambar 5.4), tim tangkas
membutuhkan orang level 2 atau 3, dan dianggap berisiko dengan orang level 1.
Dalam lingkungan yang digerakkan oleh perencanaan, orang level 2 atau 3 hanya
diperlukan selama tahap definisi pengembangan. Setelah itu, beberapa orang level
1 dapat diakomodasi.
Tingkat K
e
Fasih - t
3 e
r
Memisahkan- 2 a
n
Mengikuti- 1 g
a
n
Orang-orang di fasih tingkat bergerak secara

fleksibel dari satu pendekatan ke pendekatan
lainnya. Sebagai pengembang perangkat lunak,
mereka dapat merevisi metode agar sesuai dengan
situasi baru yang belum pernah terjadi sebelumnya
Orang-orang di memisahkan tingkat mahir dalam
pendekatan tunggal, dan siap untuk belajar
alternatif. Mereka mampu menyesuaikan metode
dengan situasi baru yang telah ada sebelumnya
Orang-orang di mengikuti tingkat mematuhi satu
pendekatan dan menjadi bingung ketika dihadapkan
dengan sesuatu yang baru. Mereka mampu
melakukan langkah-langkah metode, seperti
menyusun pola atau menjalankan tes.
Gambar 5.4 Tingkat pemahaman
5.2.6 Pengembangan Perangkat Lunak

Sumber Terbuka
Salah satu buku awal tentang pengembangan perangkat lunak open source berjudul
Katedral dan Bazaar (Raymond, 1999). Katedral mengacu pada pengembangan
perangkat lunak tradisional, kelas berat, hierarkis seperti yang umum dalam
pengembangan perangkat lunak sumber tertutup. Sebaliknya, pengembangan
perangkat lunak open source seperti bazaar: gerombolan pengembang anarkis
dengan santai diatur dalam organisasi jaringan virtual. Metafora bazaar dipilih untuk
mencerminkan bentuk pasar Timur Tengah yang mengoceh, mengobrol, dan
tampaknya tidak terorganisir. Meskipun metafora bazaar mungkin cocok dengan
beberapa grup pengembangan open source, banyak komunitas open source yang
sukses telah mengadopsi struktur seperti bawang yang lebih terorganisir yang
digambarkan pada Gambar 5.5.
Dalam struktur komunitas open source berbentuk bawang, empat lapisan
partisipasi dibedakan:
�
Tim inti
Co−Developer
Pengguna Aktif
Pengguna Pasif
Gambar 5.5 Struktur berbentuk bawang dari komunitas open source
�
ORGANISASI TIM
– Komunikasi antar pengembang
Komunitas open source adalah "perusahaan tanpa dinding" (Fang dan Neufeld,
2006). Orang dapat dengan bebas masuk dan keluar dari komunitas. Pengembang
yang berpartisipasi dalam proyek sumber terbuka jarang melakukannya tanpa
pamrih. Mereka mengharapkan imbalan, seperti kemampuan untuk mempelajari
hal-hal baru, status yang lebih tinggi dalam pekerjaan normal mereka, perhatian
karena merupakan bagian dari proyek yang sukses, dan sejenisnya. Ini seharusnya
tidak mengherankan. Profesional perangkat lunak memiliki kebutuhan pertumbuhan
yang tinggi (Couger dan Zawacki, 1980). Proyek open source yang menantang
keterampilan pengembang, memiliki basis kode termodulasi dengan baik, dan
menggunakan alat canggih memiliki peluang lebih tinggi untuk menarik komunitas
yang berkelanjutan.
Salah satu hal terburuk yang mungkin terjadi pada proyek open source adalah
ketidaksepakatan antara pengembang. Kendala umum dalam proyek open source
adalah ketidaksepakatan tentang kecepatan pengembangan Godfrey dan Tu (2000).
Beberapa pengembang mungkin ingin sering mengeluarkan rilis baru, sementara
yang lain mungkin lebih berhati-hati. Sumber ketidaksepakatan potensial lainnya
adalah ketika pengguna mulai merasa tidak nyaman dengan 'demokrasi yang tidak
demokratis' dari proyek sumber terbuka. Meskipun banyak orang mungkin
mengirimkan perbaikan bug atau permintaan fitur, kekuatan dari apa yang
sebenarnya terjadi biasanya terletak pada satu atau beberapa orang di Tim Inti. Jika
pengajuan pengembang ditolak berkali-kali, dia mungkin frustrasi dan meninggalkan
komunitas atau memutuskan untuk membuat fork: pengembang mengambil salinan
kode sumber dan memulai jalur pengembangan independen.
Komunikasi antar pengembang merupakan masalah di setiap tim yang
didistribusikan. Namun dalam proyek open source, situasinya lebih buruk karena
keanggotaan komunitas mengambang dan kurangnya dokumentasi formal.
Modularisasi kode yang jelas merupakan sarana penting untuk mengurangi
kebutuhan akan komunikasi ekstensif. Komunitas opensource selanjutnya
cenderung menggunakan alat kontrol konfigurasi dan milis untuk komunikasi.
5.2.7 Prinsip Umum untuk Mengorganisir

Tim
Tidak peduli bagaimana kita mencoba mengatur tim, poin kuncinya adalah itu harus
a tim.Dari sekian banyak pengujian mengenai produktivitas dalam proyek
pengembangan perangkat lunak, ternyata lagi-lagi faktor mengenai kemampuan tim
memiliki pengaruh yang jauh lebih besar dari apapun. Faktor-faktor seperti moral,
norma kelompok, dan gaya manajemen memainkan peran yang lebih penting
daripada hal-hal seperti penggunaan bahasa tingkat tinggi, kompleksitas produk, dan
sejenisnya (lihat, misalnya, (Lawrence, 1981)).
Beberapa prinsip umum untuk organisasi tim diberikan dalam (Koontz dan
O'Donnell, 1972). Secara khusus, prinsip umum ini juga berlaku untuk organisasi
proyek pengembangan perangkat lunak:
�
5.3. RINGKASAN 105
dan orang lain yang bekerja di bidang perangkat lunak. Selain itu, kelompok
besar membutuhkan lebih banyak komunikasi, yang berdampak negatif pada
produktivitas dan menyebabkan lebih banyak kesalahan.
�
ORGANISASI TIM
manajemen proyek perangkat lunak dibahas pada bagian 5.1, bersama dengan
taksonomi terkenal dari mekanisme koordinasi dan gaya manajemen.
Ada berbagai cara untuk mengatur pengembang perangkat lunak dalam sebuah
tim. Bentuk organisasi ini dan beberapa peringatannya dibahas di bagian 5.2.
Organisasi hierarkis dan matriks tidak spesifik untuk pengembangan perangkat
lunak, sedangkan kepala pemrogram, SWAT, dan tim tangkas berasal dari bidang
perangkat lunak. Masing-masing dari yang terakhir entah bagaimana mencoba
untuk mendamaikan dua jenis manajemen yang biasanya diperlukan dalam proyek
pengembangan perangkat lunak: pendekatan pribadi individualistis di mana
seseorang mencoba untuk mendapatkan yang terbaik dari anggota tim, dan gaya
manajemen hierarkis dari atas ke bawah untuk menyelesaikan sesuatu tepat waktu
dan dalam. anggaran. Proyek open source yang sukses biasanya memiliki
organisasi berbentuk bawang.

Sumber informasi yang masih sangat relevan tentang faktor psikologis yang terkait
dengan pengembangan perangkat lunak adalah (Weinberg, 1971). (Brooks, 1995)
dan (DeMarco dan Lister, 1999) juga memuat sejumlah observasi berharga.
Masalah koordinasi dalam pengembangan perangkat lunak dibahas dalam (Kraut
dan Streeter, 1995). (Perangkat Lunak, 1996a) dan (CACM, 1993b) adalah isu jurnal
khusus dalam mengelola proyek perangkat lunak.
(Mintzberg, 1983) adalah teks klasik tentang organisasi manajemen. Gaya
manajemen dasar yang dibahas dalam bagian 5.1.2 didasarkan pada (Reddin,
1970) dan (Constantine, 1993).
Kepala tim pemrogram dijelaskan dalam (Baker, 1972). Bentuk modifikasinya
dijelaskan dalam (Macro dan Buxton, 1987). SWAT dibahas dalam (Martin, 1991).
Tim tangkas dijelaskan antara lain dalam (Highsmith, 2004). Tiga tingkat
pemahaman dibahas dalam (Cockburn, 2002). (Perangkat Lunak, 2005) berisi
sejumlah artikel tentang cara mengadopsi metode tangkas.
(SPIP, 2006) berisi kumpulan artikel tentang proses pengembangan open
source. Crowston dan Howison (2006) membahas kesehatan komunitas open
source. Aberdour (2007) membahas cara untuk mencapai kualitas dalam
pengembangan perangkat lunak open source.
Latihan
1. Jelaskan klasifikasi konfigurasi organisasi Mintzberg dan mereka

mekanisme koordinasi terkait.
2. Diskusikan gaya manajemen dasar Reddin.
3. Apa isu kritis dalam organisasi tim hierarkis?
4. Soroti perbedaan antara kepala tim pemrogram, tim SWAT dan tim
yang gesit.
5. Manakah dari gaya manajemen Reddin yang paling cocok dengan tim yang tangkas?
6. Apa itu Prinsip Peter? Di mana itu muncul dalam pengembangan perangkat lunak?
7. Mengapa tim yang tangkas membutuhkan orang yang lebih baik daripada tim yang mengikuti
a
pendekatan berbasis perencanaan?
8. ~
6
Tentang Mengelola Kualitas
Perangkat Lunak
TUJUAN PEMBELAJARAN
�
109
Kualitas perangkat lunak adalah topik penting. Dengan meningkatnya penetrasi

otomatisasi dalam kehidupan sehari-hari, semakin banyak orang melakukan kontak
dengan sistem perangkat lunak, dan kualitas sistem tersebut menjadi perhatian utama.
Kualitas tidak dapat ditambahkan sebagai renungan. Itu harus dibangun dari awal
awal. Bab ini membahas banyak dimensi kualitas dari keduanya
produk perangkat lunak dan proses perangkat lunak.
Dalam buku tengara mereka Mencari Keunggulan, Peters dan Waterman mengidentifikasi a
sejumlah faktor kunci yang membedakan perusahaan yang sangat sukses di dunia
yang kurang berhasil. Salah satu faktor kunci tersebut adalah komitmen terhadap kualitas
perusahaan yang sangat sukses. Rupanya, kualitas terbayar.
Profitabilitas jangka panjang bukan satu-satunya alasan mengapa perhatian terhadap kualitas itu
penting
dalam pengembangan perangkat lunak. Karena kerumitan produk perangkat lunak dan
perubahan sering sering yang harus dimasukkan selama pengembangan
perangkat lunak, perhatian terus menerus, dan penilaian, kualitas produk di bawah
pengembangan diperlukan jika kita ingin mewujudkan produk yang memuaskan. Kebutuhan ini
diperparah dengan meningkatnya penetrasi teknologi perangkat lunak ke dalam kehidupan sehari-hari.
Produk berkualitas rendah akan membuat pelanggan tidak puas, akan membuat pengguna
mengabaikannya
sistem yang seharusnya mendukung pekerjaan mereka, dan bahkan mungkin menelan biaya hidup.
Salah satu contoh menakutkan tentang apa yang mungkin terjadi jika perangkat lunak mengandung
bug, adalah
menjadi dikenal sebagai 'Kerusakan 54'. Therac-25, mesin radiasi terkomputerisasi,
disalahkan dalam insiden yang menyebabkan kematian dua orang dan luka serius
yang lain. Misteri maut itu akhirnya ditelusuri kembali ke bug perangkat lunak, bernama
'Kerusakan 54' setelah pesan ditampilkan di konsol; lihat juga bagian 1.4.2.
Komitmen terhadap kualitas dalam pengembangan perangkat lunak tidak hanya terbayar, tetapi juga
sangat besar
kebutuhan.
Komitmen ini membutuhkan proses pengembangan yang hati-hati. Perhatian ini untuk
proses pengembangan didasarkan pada premis bahwa kualitas suatu produk sebagian besar
berdasarkan kualitas proses yang mengarah ke produk itu, dan proses ini
memang dapat didefinisikan, dikelola, diukur, dan ditingkatkan.
Selain dikotomi produk--proses, dikotomi kesesuaian--perbaikan
dapat dibedakan juga. Jika kami memberlakukan persyaratan kualitas tertentu pada produk
atau proses, kami dapat menyusun teknik dan prosedur untuk memastikan atau menguji bahwa
produk atau proses memang demikian sesuai dengan tujuan-tujuan ini. Atau, skema mungkin
ditujukan membaik kualitas produk atau proses.
Gambar 6.1 memberikan contoh dari empat pendekatan kualitas yang berbeda ini. Paling
rekayasa perangkat lunak berkaitan dengan peningkatan kualitas produk
kami kembangkan, dan label 'praktik terbaik' dalam gambar ini mengacu pada semua kebaikan
disebutkan di tempat lain dalam buku ini. Tiga pendekatan lainnya dibahas dalam hal ini
bab.
Sebelum kita memulai diskusi tentang berbagai pendekatan kualitas, kami akan
pertama menguraikan pengertian kualitas perangkat lunak itu sendiri, dan bagaimana mengukurnya.
Kapan
110 MENGELOLA KUALITAS PERANGKAT
LUNAK
Gambar 6.1 Berbagai pendekatan kualitas
berbicara tentang ketinggian orang, frasa 'Jasper tingginya 7 kaki' menyampaikan

lebih banyak informasi daripada 'Jasper tinggi'. Demikian pula, kami ingin
mengungkapkan semua jenis atribut kualitas dalam angka. Kami lebih suka
pernyataan dalam bentuk 'Ketersediaan sistem adalah 99%' daripada sekadar
'Ketersediaan sistem tinggi'. Beberapa peringatan dari masalah pengukuran yang
terlibat dibahas di bagian 6.1. Pada bagian 6.2, kita akan membahas berbagai
taksonomi atribut kualitas, termasuk ISO 9126. Ini bukanlah kata terakhir tentang
kualitas perangkat lunak, tetapi merupakan titik referensi yang baik untuk memulai.
Pembahasan ini juga memungkinkan kita untuk mengilustrasikan lebih jauh
beberapa masalah dengan mengukur kualitas secara kuantitatif.
'Kualitas perangkat lunak' adalah gagasan yang agak sulit dipahami. Orang yang
berbeda akan memiliki perspektif yang berbeda pada kualitas sistem perangkat
lunak. Penguji sistem dapat melihat kualitas sebagai 'kepatuhan terhadap
persyaratan', sedangkan pengguna dapat melihatnya sebagai 'kesesuaian untuk
digunakan'. Kedua sudut pandang itu valid, tetapi tidak perlu bersamaan. Faktanya,
mereka mungkin tidak akan melakukannya. Bagian dari kebingungan tentang apa
yang diperlukan oleh kualitas suatu sistem dan bagaimana penilaiannya,
disebabkan oleh percampuran perspektif yang berbeda ini. Alih-alih membedakan
antara berbagai perspektif tentang kualitas, Total Quality Management (TQM)
mendukung pandangan eklektik: kualitas adalah pengejaran keunggulan dalam
segala hal. Bagian 6.3 menguraikan tentang berbagai perspektif tentang kualitas.
ISO, Organisasi Standar Internasional, telah menetapkan beberapa standar
yang berkaitan dengan manajemen kualitas. Yang paling dapat diterapkan di bidang
kami, pengembangan dan pemeliharaan perangkat lunak, adalah ISO 9001. Standar
ini akan dibahas di bagian 6.4.
ISO 9001 dapat ditambah dengan prosedur yang lebih spesifik, ditujukan khusus
untuk jaminan kualitas dan kontrol untuk pengembangan perangkat lunak. Standar
IEEE untuk Rencana Penjaminan Mutu dimaksudkan untuk menyediakan prosedur
tersebut. Ini dibahas di bagian 6.5.
Prosedur jaminan kualitas perangkat lunak menyediakan sarana untuk meninjau
dan mengaudit proses pengembangan perangkat lunak dan produknya. Jaminan
kualitas dengan sendirinya tidak menjamin kualitas produk. Jaminan kualitas hanya
memastikan bahwa pekerjaan selesai
6.1. PADA UKURAN DAN ANGKA 111
cara yang seharusnya dilakukan.
Model Kematangan Kemampuan (CMM)1 adalah upaya arah yang paling dikenal
tentang bagaimana meningkatkan proses pembangunan. Ini menggunakan skala lima poin untuk menilai
organisasi dan menunjukkan bidang fokus utama untuk maju ke tingkat yang lebih tinggi
tingkat kedewasaan. SPICE dan Bootstrap adalah pendekatan serupa untuk peningkatan proses.
CMM dibahas di bagian 6.6.
Tindakan berkualitas dalam organisasi pengembangan perangkat lunak ditujukan untuk menemukan
kesempatan untuk memperbaiki proses pembangunan. Perbaikan ini membutuhkan sebuah
pemahaman tentang proses pembangunan, yang hanya dapat diperoleh melalui
hati-hati mengumpulkan dan menafsirkan data yang berkaitan dengan aspek kualitas proses
dan produknya. Beberapa petunjuk tentang bagaimana memulai program peningkatan kualitas tersebut
adalah
diberikan di bagian 6.8.
6.1 Tentang Ukuran dan Bilangan

Ketika Anda dapat mengukur apa yang Anda bicarakan, dan mengungkapkannya dalam
angka, Anda
tahu sesuatu tentang itu; tetapi ketika Anda tidak dapat mengukurnya, ketika Anda tidak
dapat mengungkapkannya
dalam jumlah, pengetahuan Anda sedikit dan tidak memuaskan; itu mungkin
awal pengetahuan, tetapi Anda hampir tidak pernah berpikir untuk maju ke tahap
ilmu pengetahuan.
[Lord Kelvin, 1900]
Itu adalah tanda dari pikiran yang diinstruksikan untuk beristirahat dengan puas dengan
tingkat presisi yang dimiliki
sifat subjek mengakui, dan tidak mencari ketepatan ketika hanya perkiraan dari
kebenaran itu mungkin.
[Aristoteles, 330 SM]
Misalkan kita ingin mengungkapkan beberapa atribut kualitas, katakanlah kompleksitas suatu program
teks, dalam nilai numerik tunggal. Nilai yang lebih besar dimaksudkan untuk menunjukkan lebih kompleks
program. Jika seperti pemetaan
C
1 MENGELOLA KUALITAS PERANGKAT LUNAK
1
2 1 prosedur gelembung
2 (dulu A: Himpunan [1..n] dari bilangan bulat; n: bilangan bulat);
3 dulu i, j, temp: bilangan bulat;
4 mulai
5 untuk saya:= 2 ke N Mengerjakan
6 j:= saya;
(A) 7 ketika J
>
hasilnya juga sesuai dengan intuisi kita. Pemetaan mana yang dicari?
Apakah salah satu dari mereka 'valid' untuk memulai? Apa arti 'valid' dalam konteks ini?
Sejumlah aspek pengukuran yang relevan, seperti atribut, satuan dan skala
jenis dapat diperkenalkan dan terkait satu sama lain menggunakan kerangka pengukuran
digambarkan pada gambar 6.3. Kerangka kerja ini juga memungkinkan kami untuk menunjukkan
bagaimana metrik dapat melakukannya
digunakan untuk menggambarkan dan memprediksi sifat produk dan proses, dan bagaimana caranya
memvalidasi prediksi ini.
LUNAK
pada gambar 6.3 menunjukkan bahwa hubungan ini n ke m.
�
pada gambar 6.3 menunjukkan bahwa kita dapat memiliki lebih dari satu model yang sama
relasi atribut.
Pengukuran adalah pemetaan dari dunia empiris, 'nyata' ke dunia formal, relasional
dunia. A ukuran adalah nomor atau simbol yang diberikan pada atribut suatu entitas oleh
pemetaan ini. Nilai yang diberikan jelas memiliki unit tertentu, mis. baris kode. Itu
unit pada gilirannya milik skala tertentu, seperti skala rasio untuk
baris kode, atau skala ordinal untuk keparahan kegagalan.
Dalam matematika, istilah metrik memiliki arti yang sangat spesifik: itu menggambarkan seberapa
jauh
terpisah dua titik. Di bidang kami, istilah ini sering digunakan dengan cara yang agak ceroboh.
Terkadang itu menunjukkan ukuran, terkadang satuan ukuran. Kami akan menggunakan
istilah untuk menunjukkan kombinasi dari:
– atribut entitas,
– fungsi yang memberikan nilai pada atribut tersebut,
– unit di mana nilai ini dinyatakan, dan
- tipe skalanya.
Untuk setiap jenis timbangan, operasi tertentu diperbolehkan, sementara yang
lainnya tidak. Secara khusus, kita tidak dapat menghitung rata-rata untuk skala
ordinal, tetapi hanya mediannya (nilai tengah). Misalkan kita mengklasifikasikan
sistem sebagai 'sangat kompleks', 'kompleks', 'rata-rata', 'sederhana' atau 'sangat
sederhana'. Penempatan angka pada nilai-nilai ini agak sewenang-wenang.
Satu-satunya prasyarat adalah bahwa sistem yang diklasifikasikan sebagai,
katakanlah, 'sangat kompleks' diberi nilai yang lebih besar daripada sistem yang
diklasifikasikan sebagai, katakanlah, 'kompleks'. Jika kita sebut pemetaan ini
DI DALAM
LUNAK
Kita seringkali tidak dapat mengukur nilai suatu atribut secara langsung.
Misalnya, kecepatan sebuah mobil dapat ditentukan dari nilai dua atribut lainnya:
jarak dan waktu yang dibutuhkan mobil untuk menempuh jarak tersebut. Kecepatan
kemudian diukur secara tidak langsung, dengan mengambil hasil bagi dari dua
ukuran langsung. Dalam hal ini, model atribut-relasi meresmikan hubungan antara
jarak yang ditempuh, waktu, dan kecepatan.
Kita dapat membedakan antara intern Dan luar atribut. Atribut internal dari suatu
entitas dapat diukur murni dalam kaitannya dengan entitas itu sendiri. Modularitas,
ukuran, cacat yang ditemui, dan biaya adalah contoh khas dari atribut internal.
Atribut eksternal suatu entitas adalah atribut yang hanya dapat diukur sehubungan
dengan bagaimana entitas tersebut berhubungan dengan lingkungannya.
Pemeliharaan dan kegunaan adalah contoh dari atribut eksternal. Sebagian besar
faktor kualitas yang kita bahas dalam bab ini adalah atribut eksternal. Atribut
eksternal hanya dapat diukur secara tidak langsung, karena mereka melibatkan
pengukuran atribut lainnya.
Relasi empiris antar objek di dunia nyata harus dipertahankan dalam sistem
relasi numerik yang kita gunakan. Jika kita mengamati mobil itu A
6.2. TAKSONOMI ATRIBUT KUALITAS 117
6.2 Taksonomi Atribut

Kualitas
Beberapa studi rumit pertama tentang gagasan 'kualitas perangkat lunak' muncul di
akhir 1970-an (McCall et al., 1977), (Boehm et al., 1978). Dalam studi ini, sejumlah
aspek sistem perangkat lunak diselidiki yang entah bagaimana berhubungan dengan gagasan
kualitas perangkat lunak. Pada tahun-tahun berikutnya, sejumlah besar orang telah mencoba
mengatasinya
masalah yang sama ini. Banyak taksonomi faktor kualitas telah dipublikasikan. Itu
masalah mendasar belum terpecahkan secara memuaskan. Berbagai faktor tersebut
yang berhubungan dengan kualitas perangkat lunak sulit untuk didefinisikan. Bahkan lebih sulit untuk
mengukurnya
secara kuantitatif. Di sisi lain, kualitas nyata seringkali dapat diidentifikasi secara mengejutkan
dengan mudah.
Dalam IEEE Glosarium Terminologi Rekayasa Perangkat Lunak, kualitas didefinisikan sebagai 'the
sejauh mana suatu sistem, komponen, atau proses memenuhi kebutuhan pelanggan atau pengguna
atau
ekspektasi’. Diterapkan ke perangkat lunak, maka, kualitas harus diukur terutama terhadap
sejauh mana persyaratan pengguna terpenuhi: kebenaran, keandalan, kegunaan,
dan sejenisnya. Perangkat lunak bertahan lama dan diadaptasi dari waktu ke waktu secara berurutan
untuk mengakomodasi perubahan keadaan. Ini penting bagi pengguna
mungkin dengan biaya yang masuk akal. Oleh karena itu, pelanggan juga tertarik pada kualitas
faktor yang berhubungan dengan struktur sistem daripada penggunaannya: pemeliharaan,
testabilitas, portabilitas, dll.
Kami akan memulai diskusi kami tentang atribut kualitas dengan taksonomi McCall. McCall
membedakan antara dua tingkat atribut kualitas. Atribut kualitas tingkat lebih tinggi,
dikenal sebagai faktor kualitas, adalah atribut eksternal dan karenanya hanya dapat diukur
secara tidak langsung. McCall memperkenalkan atribut kualitas tingkat kedua, disebut kualitas
kriteria. Kriteria kualitas dapat diukur baik secara subjektif maupun objektif. Oleh
menggabungkan peringkat untuk kriteria kualitas individu yang mempengaruhi kualitas tertentu
faktor, kami memperoleh ukuran sejauh mana faktor kualitas itu berada
puas. Pengguna dan manajer cenderung tertarik pada level yang lebih tinggi, eksternal
atribut kualitas.
Sebagai contoh, kita tidak dapat secara langsung mengukur keandalan sistem perangkat lunak.
Kami
namun dapat secara langsung mengukur jumlah cacat yang ditemui sejauh ini. Ini langsung
ukuran dapat digunakan untuk memperoleh wawasan tentang keandalan sistem. Ini melibatkan
sebuah teori tentang bagaimana jumlah cacat yang dihadapi berkaitan dengan keandalan, yang dapat
dipastikan dengan alasan yang baik. Untuk sebagian besar aspek kualitas lainnya, hubungannya
antara atribut yang dapat diukur secara langsung dan atribut eksternal kita
tertarik kurang jelas, untuk sedikitnya.
Tabel 6.2 mencantumkan faktor kualitas dan definisinya, seperti yang digunakan oleh McCall
et al.2 Faktor kualitas ini dapat dikategorikan secara luas menjadi tiga kelas. Pertama
class berisi faktor-faktor yang berkaitan dengan penggunaan perangkat lunak setelah menjadi
2Iniadalah definisi keandalan perangkat lunak yang agak sempit. Definisi yang lebih lengkap terdapat dalam
Daftar Istilah Rekayasa Perangkat Lunak IEEE: 'Kemampuan suatu sistem atau komponen untuk
menjalankan fungsi yang diperlukan dalam kondisi yang ditentukan untuk jangka waktu tertentu.' Ini sering
dinyatakan sebagai probabilitas.
LUNAK
Tabel 6.2 faktor kualitas (Sumber: J.A. McCall, P.K. Richards

& G.F. Walters, Faktor
dalam Kualitas Perangkat Lunak, RADC-TR-77-369, Departemen Perdagangan AS,
1977.)
Ketepatan: Sejauh mana suatu program memenuhi spesifikasinya dan
memenuhi tujuan misi pengguna.
Keandalan: Sejauh mana suatu program dapat diharapkan untuk melakukan
fungsi yang diinginkan dengan presisi yang diperlukan.
Efisiensi: Jumlah sumber daya komputasi dan kode yang diperlukan oleh
suatu program untuk menjalankan suatu fungsi.
Integritas: Sejauh mana akses ke perangkat lunak atau data oleh orang yang
tidak berwenang dapat dikendalikan.
Kegunaan: Upaya yang diperlukan untuk mempelajari, mengoperasikan,
menyiapkan input, dan menginterpretasikan output suatu program.
Pemeliharaan: Upaya yang diperlukan untuk menemukan dan memperbaiki
kesalahan dalam program operasional.
Testabilitas: Upaya yang diperlukan untuk menguji program untuk
memastikan bahwa program tersebut menjalankan fungsi yang diinginkan.
Fleksibilitas: Upaya yang diperlukan untuk memodifikasi program
operasional.
Portabilitas: Upaya yang diperlukan untuk mentransfer program dari satu
lingkungan perangkat keras dan/atau perangkat lunak ke lingkungan lainnya.
Dapat digunakan kembali: Sejauh mana suatu program (atau bagiannya)
dapat digunakan kembali dalam aplikasi lain.
Interoperabilitas: Upaya yang diperlukan untuk memasangkan satu sistem
dengan sistem lainnya.
operasional. Kelas kedua berkaitan dengan pemeliharaan sistem. Kelas ketiga berisi
faktor-faktor yang mencerminkan kemudahan transisi ke lingkungan baru. Ketiga
kategori ini digambarkan dalam tabel 6.3.
Dalam standar ISO 9126, upaya serupa telah dilakukan untuk mendefinisikan
serangkaian karakteristik dan sub-karakteristik kualitas (lihat tabel 6.4). Definisi
mereka diberikan dalam tabel 6.5 dan 6.6. Sedangkan faktor dan kriteria kualitas
seperti yang didefinisikan oleh McCall dan lainnya sangat terkait, yaitu
Skema ISO bersifat hierarkis: setiap sub-karakteristik terkait dengan tepat satu
karakteristik.
Karakteristik kualitas ISO secara ketat mengacu pada perangkat lunak produk.
Definisi mereka tidak menangkap proses masalah kualitas. Misalnya, keamanan
sebagian dapat ditangani oleh ketentuan dalam perangkat lunak dan sebagian lagi
dengan prosedur yang tepat. Hanya yang pertama yang dicakup oleh 'keamanan'
sub-karakteristik dari skema ISO. Selanjutnya, sub-karakteristik menyangkut aspek
kualitas yang ada bisa dilihat kepada pengguna. Reusability, misalnya, tidak
termasuk dalam skema ISO.
Tabel 6.3 Tiga kategori faktor kualitas perangkat lunak

(Sumber: J.A. McCall,
P.K. Richards & G.F. Walters, Faktor Kualitas Perangkat Lunak,
RADC-TR-77-369, Departemen Perdagangan AS, 1977.)
Operasi produk:
Ketepatan Apakah itu
melakukan apa
yang saya
inginkan?
Keandalan Apakah itu
melakukannya
secara akurat
sepanjang
waktu?
Efisiensi Apakah ini akan
berjalan di
perangkat keras
saya sebaik
mungkin?
Integritas Apakah ini
aman?
Kegunaan Dapatkah saya
menjalankannya
?
Revisi produk:
Pemeliharaan Dapatkah saya
memperbaikinya
?
Testabilitas Bisakah saya
mengujinya?
Fleksibilitas Dapatkah saya
mengubahnya?
Transisi produk:
Portabilitas Apakah saya
dapat
menggunakanny
a di komputer
lain?
Dapat digunakan kembali Apakah saya
dapat
menggunakan
kembali
beberapa
perangkat
lunak?
Interoperabilitas Apakah saya dapat
menghubungkannya
dengan sistem lain?
Karakteristik dan subkarakteristik ISO, bersama dengan serangkaian ekstensif

langkah-langkah, membuat ISO model kualitas eksternal dan internal. Kualitas internal mengacu pada
produk itu sendiri, akhirnya kode sumber. Kualitas eksternal mengacu pada kualitas kapan
perangkat lunak dijalankan. Misalnya, jumlah rata-rata pernyataan dalam suatu metode
adalah ukuran kualitas internal, sedangkan jumlah cacat ditemui selama
pengujian adalah ukuran kualitas eksternal.
Pada akhirnya, pengguna tertarik pada kualitas dalam penggunaan, didefinisikan dalam (ISO9126,
2001) sebagai
”pandangan pengguna tentang kualitas produk perangkat lunak ketika dijalankan secara spesifik
lingkungan dan konteks penggunaan tertentu.” Ini mengukur sejauh mana pengguna bisa
mencapai tujuannya, bukan hanya properti perangkat lunak (lihat juga bagian 6.3).
Kualitas yang digunakan dimodelkan dalam empat karakteristik: efektivitas, produktivitas, keamanan,
dan kepuasan. Definisi untuk kualitas dalam karakteristik penggunaan ini diberikan dalam
tabel 6.7.
Secara teoritis, kualitas internal, kualitas eksternal dan kualitas yang digunakan saling terkait
bersama-sama: kualitas internal menunjukkan kualitas eksternal, yang pada gilirannya menunjukkan
kualitas dalam
menggunakan. Secara umum, memenuhi kriteria pada satu tingkat tidak cukup untuk memenuhi kriteria
pada
tingkat berikutnya. Misalnya, kepuasan sebagian ditentukan oleh internal dan eksternal
ukuran kualitas, tetapi juga mencakup sikap pengguna terhadap produk. Yang terakhir
harus diukur secara terpisah. Perhatikan bahwa kualitas internal dan kualitas eksternal dapat
diukur secara langsung. Kualitas yang digunakan pada umumnya hanya dapat diukur secara tidak
langsung.
120 MENGELOLA KUALITAS PERANGKAT LUNAK
Tabel 6.4 Karakteristik kualitas dan sub-karakteristik

model kualitas eksternal dan internal ISO 9126
Ciri Subkarakteri
stik
Kegunaan Kesesuaian
Ketepatan
Interoperabilitas
Keamanan
Kepatuhan fungsionalitas
Keandalan Kematangan
Toleransi kesalahan
Dapat dipulihkan
Kepatuhan keandalan
Kegunaan Dapat
dimengerti
Kemampuan belajar
Operabilitas
Daya tarik
Kepatuhan
kegunaan
Efisiensi Perilaku
waktu
Pemanfaatan sumber
daya Pemenuhan
efisiensi
Pemeliharaan Kemampuan
analisis
Dapat diubah
Stabilitas
Testabilitas
Kepatuhan pemeliharaan
Portabilitas Kemampuan
beradaptasi
Dapat diinstal
Hidup berdampingan
Dapat diganti
Kepatuhan portabilitas
Tabel 6.5 Karakteristik kualitas dari model kualitas eksternal dan internal
ISO 9126 (Sumber: Standar ISO 9126: Karakteristik dan Metrik Kualitas Perangkat Lunak.
Direproduksi dengan izin ISO.)
Kegunaan: Kemampuan produk perangkat lunak untuk menyediakan fungsi

yang memenuhi kebutuhan yang dinyatakan dan tersirat ketika perangkat
lunak digunakan dalam kondisi tertentu.
Keandalan: Kemampuan produk perangkat lunak untuk mempertahankan tingkat tertentu
kinerja ketika digunakan dalam kondisi tertentu.
Kegunaan: Kemampuan produk perangkat lunak untuk dipahami, dipelajari,
digunakan dan menarik bagi pengguna, bila digunakan dalam kondisi tertentu.
Efisiensi: Kemampuan produk perangkat lunak untuk memberikan kinerja
yang sesuai, relatif terhadap jumlah sumber daya yang digunakan, dalam
kondisi yang dinyatakan.Pemeliharaan: Kemampuan produk perangkat lunak
untuk dimodifikasi. Modifikasi mungkin termasuk koreksi, perbaikan atau
adaptasi perangkat lunak terhadap perubahan lingkungan, dan persyaratan
dan spesifikasi fungsional.
Portabilitas: Kemampuan produk perangkat lunak untuk ditransfer dari satu
lingkungan ke lingkungan lain.
LUNAK
dilanjutkan di halaman berikutnya
Tabel 6.6 Sub-karakteristik kualitas dari model kualitas

eksternal dan internal
ISO 9126 (Sumber: Standar ISO 9126: Karakteristik dan Metrik Kualitas Perangkat Lunak.
Direproduksi dengan izin ISO.)
Kesesuaian: Kemampuan produk perangkat lunak untuk menyediakan

serangkaian fungsi yang sesuai untuk tugas dan tujuan pengguna tertentu.
Ketepatan: Kemampuan produk perangkat lunak untuk memberikan hasil atau
efek yang benar atau disetujui dengan tingkat presisi yang diperlukan.
Interoperabilitas: Kemampuan produk perangkat lunak untuk berinteraksi
dengan satu atau lebih sistem yang ditentukan.
Keamanan: Kemampuan produk perangkat lunak untuk melindungi informasi
dan data sehingga orang atau sistem yang tidak berwenang tidak dapat
membaca atau memodifikasinya dan orang atau sistem yang berwenang tidak
menolak aksesnya.
Kepatuhan fungsionalitas: Kemampuan produk perangkat lunak untuk
mematuhi standar, konvensi, atau peraturan dalam undang-undang dan
ketentuan serupa yang berkaitan dengan fungsionalitas.
Kematangan: Kemampuan produk perangkat lunak untuk menghindari
kegagalan akibat kesalahan pada perangkat lunak.
Toleransi kesalahan: Kemampuan produk perangkat lunak untuk
mempertahankan tingkat kinerja tertentu jika terjadi kesalahan perangkat
lunak atau pelanggaran antarmuka yang ditentukan.
Dapat dipulihkan: Kemampuan produk perangkat lunak untuk membangun
kembali tingkat kinerja tertentu dan memulihkan data yang terpengaruh secara
langsung jika terjadi kegagalan. Kepatuhan keandalan: Kemampuan produk
perangkat lunak untuk mematuhi standar, konvensi, atau peraturan yang
berkaitan dengan keandalan.
Dapat dimengerti: Kemampuan produk perangkat lunak untuk
memungkinkan pengguna memahami apakah perangkat lunak tersebut
sesuai, dan bagaimana perangkat lunak tersebut dapat digunakan untuk tugas
dan kondisi penggunaan tertentu.
Kemampuan belajar: Kemampuan produk perangkat lunak untuk
memungkinkan pengguna mempelajari aplikasinya.
Operabilitas: Kemampuan produk perangkat lunak untuk memungkinkan
pengguna mengoperasikan dan mengontrolnya.
Daya tarik: Kemampuan produk perangkat lunak untuk menarik bagi
pengguna.
Kepatuhan kegunaan: Kemampuan produk perangkat lunak untuk mematuhi
standar, konvensi, panduan gaya, atau peraturan yang berkaitan dengan
kegunaan
Perilaku waktu: Kemampuan produk perangkat lunak untuk menyediakan yang sesuai
waktu respons dan pemrosesan serta tingkat throughput saat menjalankannya
fungsi, di bawah kondisi yang dinyatakan.
Pemanfaatan sumber daya: Kemampuan produk perangkat lunak untuk digunakan dengan tepat
jumlah dan jenis sumber daya ketika perangkat lunak menjalankan fungsinya di bawah
kondisi yang dinyatakan.
Kepatuhan efisiensi: Kemampuan produk perangkat lunak untuk mematuhi
standar atau konvensi yang berkaitan dengan efisiensi.
Kemampuan analisis: Kemampuan produk perangkat lunak yang akan didiagnosis
kekurangan atau penyebab kegagalan dalam perangkat lunak, atau untuk bagian yang akan
dimodifikasi
untuk diidentifikasi.
Dapat diubah: Kemampuan produk perangkat lunak untuk mengaktifkan yang ditentukan
modifikasi yang akan diterapkan.
Stabilitas: Kemampuan produk perangkat lunak untuk menghindari efek yang tidak diharapkan
dari modifikasi perangkat lunak.
Testabilitas: Kemampuan produk perangkat lunak untuk mengaktifkan perangkat lunak yang
dimodifikasi
untuk divalidasi.
Kepatuhan pemeliharaan: Kemampuan produk perangkat lunak untuk mematuhi
dengan standar atau konvensi yang berkaitan dengan pemeliharaan.
Kemampuan beradaptasi: Kemampuan produk perangkat lunak diadaptasi untuk berbeda
lingkungan tertentu tanpa menerapkan tindakan atau sarana selain itu
disediakan untuk tujuan ini untuk perangkat lunak yang dipertimbangkan.
Dapat diinstal:Kemampuan produk perangkat lunak untuk diinstal dalam spesifikasi
lingkungan.
Hidup berdampingan: Kemampuan produk perangkat lunak untuk hidup berdampingan dengan yang
lain
perangkat lunak independen dalam lingkungan yang sama berbagi sumber daya yang sama.
Dapat diganti: Kemampuan produk perangkat lunak untuk digunakan di tempat
dari produk perangkat lunak lain yang ditentukan untuk tujuan yang sama di tempat yang sama
lingkungan.
Kepatuhan portabilitas: Kemampuan produk perangkat lunak untuk mematuhi
standar atau konvensi yang berkaitan dengan portabilitas.
Faktor kualitas tidak berdiri sendiri. Beberapa faktor akan mempengaruhi satu sama
lain dalam arti positif, sementara yang lain akan berdampak negatif. Contoh dari
kategori pertama adalah reliabilitas versus kebenaran. Efisiensi, di sisi lain, secara
umum akan berdampak negatif pada sebagian besar faktor kualitas lainnya. Ini
berarti bahwa kita harus membuat trade-off antara faktor kualitas. Jika persyaratan
tinggi diputuskan untuk satu faktor, kita mungkin harus melonggarkan yang lain.
Pengorbanan ini harus diselesaikan pada tahap awal. Tujuan penting dari fase
arsitektur perangkat lunak adalah untuk membawa faktor-faktor kualitas ini ke garis
depan dan membuat pengorbanannya eksplisit, sehingga para pemangku
kepentingan tahu untuk apa mereka berada (lihat bab 11). Dengan melakukan itu,
kita lebih mampu membangun kualitas yang diinginkan, daripada hanya menilainya
setelah fakta.
LUNAK
Tabel 6.7 Karakteristik kualitas kualitas yang digunakan

model ISO 9126 (Sumber:
Standar ISO 9126: Karakteristik dan Metrik Kualitas Perangkat Lunak. Direproduksi dengan
izin ISO.)
Efektivitas: Kemampuan produk perangkat lunak untuk memungkinkan

pengguna mencapai tujuan tertentu dengan akurasi dan kelengkapan dalam
konteks penggunaan tertentu.
Produktifitas: Kemampuan produk perangkat lunak untuk memungkinkan
pengguna mengeluarkan jumlah sumber daya yang sesuai sehubungan
dengan efektivitas yang dicapai dalam konteks penggunaan yang ditentukan.
Keamanan: Kemampuan produk perangkat lunak untuk mencapai tingkat
risiko bahaya yang dapat diterima bagi orang, bisnis, perangkat lunak,
properti, atau lingkungan dalam konteks penggunaan yang ditentukan.
Kepuasan: Kemampuan produk perangkat lunak untuk memuaskan
pengguna dalam konteks penggunaan tertentu.
6.3 Perspektif Kualitas

Apa yang saya (dan orang lain) maksudkan dengan kata kualitas tidak
dapat dipecah menjadi subjek dan predikat [. . . ] Jika kualitas ada pada
suatu objek, maka Anda harus menjelaskan mengapa instrumen ilmiah
tidak dapat mendeteksinya [. . . ] Di sisi lain, jika kualitas itu subyektif,
hanya ada [di mata] pengamat, maka Kualitas ini hanyalah nama
mewah untuk apa pun yang Anda suka [. . . ] Kualitas tidak objektif. Itu
tidak berada di dunia material [. . . ] Kualitas tidak subyektif. Itu tidak
hanya tinggal di pikiran. [Robert Pirsig, Zen dan Seni Perawatan
Sepeda Motor, 1974]
Pengguna akan menilai kualitas sistem perangkat lunak dengan sejauh mana itu
membantu mereka menyelesaikan tugas dan dengan kegembiraan yang mereka
miliki dalam menggunakannya. Manajer pengguna tersebut cenderung menilai
kualitas sistem yang sama berdasarkan manfaatnya. Manfaat ini dapat dinyatakan
dalam penghematan biaya atau dalam layanan yang lebih baik dan lebih cepat
kepada klien.
Selama pengujian, dimensi kualitas yang berlaku adalah jumlah cacat yang
ditemukan dan dihilangkan, atau keandalan yang diukur, atau kesesuaian dengan
spesifikasi. Bagi pemrogram pemeliharaan, kualitas akan dikaitkan dengan
kompleksitas sistem, dokumentasi teknisnya, dan sejenisnya.
Sudut pandang yang berbeda ini semuanya valid. Mereka juga sulit untuk
didamaikan. Garvin membedakan lima definisi kualitas perangkat lunak:
�
6.3. PERSPEKTIF TERHADAP KUALITAS 125
�
LUNAK
istilah terukur, seperti jumlah cacat yang ditemukan per bulan orang, atau jumlah
keputusan per modul. Atribut kualitas yang dibahas pada bagian sebelumnya
termasuk dalam kategori ini. Namun persyaratan kualitas tersebut tidak dapat
secara langsung dipetakan ke sudut pandang kualitas pengguna yang agak
subyektif, seperti 'kesesuaian untuk digunakan'. Namun demikian, pengguna dan
pengembang perangkat lunak harus mencapai kesepakatan tentang persyaratan
kualitas yang harus dipenuhi.
Salah satu cara untuk menjembatani kesenjangan ini adalah dengan
mendefinisikan bahasa yang sama antara pengguna dan pengembang perangkat
lunak di mana persyaratan kualitas dapat dinyatakan. Pendekatan ini diambil dalam
(Bass et al., 2003), di mana persyaratan kualitas dinyatakan dalam apa yang disebut
skenario atribut kualitas. Gambar 6.4 memberikan satu contoh bagaimana atribut
kualitas dapat dinyatakan dalam istilah pengguna. Skenario atribut kualitas memiliki
peran tidak hanya dalam menentukan persyaratan, tetapi juga dalam menguji
apakah persyaratan ini (akan) dipenuhi. Misalnya, skenario atribut kualitas banyak
digunakan dalam penilaian arsitektur (lihat juga bab 11).
Atribut kualitas: Kegunaan

Sumber: Pengguna akhir
Rangsangan: Pelajari fitur sistem
Artefak: Sistem
Lingkungan: Saat runtime
Tanggapan: Pelajari tugas yang disediakan oleh sistem untuk karyawan
baru
Ukuran respons: hari di tempat kerja
Tes: 90% berhasil menyelesaikan tugas yang diberikan dalam pengujian
karyawan untuk sistem, dalam dua kali waktu rata-rata pengguna
berpengalaman
Terburuk: 1 sampai 7 hari
Rencana: kurang dari 1 hari (hingga lulus ujian)
Terbaik: kurang dari 2 jam
Gambar 6.4 Skenario atribut kualitas yang dapat digunakan oleh pengguna dan
pengembang
Kualitas tidak hanya didefinisikan pada tingkat keseluruhan sistem. Dalam

pengembangan berbasis komponen, kualitas didefinisikan pada tingkat komponen.
Untuk layanan, kualitas didefinisikan pada tingkat layanan individual. Lingkungan
komponen atau jasa, yaitu beberapa komponen atau jasa lain, akan membutuhkan
kualitas tertentu juga. Jadi untuk komponen dan jasa, ada aspek kebutuhan dan
penyediaan kualitas. Karena suatu komponen atau jasa umumnya tidak mengenal
konteks di mana yang akan ditanamkan, sulit untuk menentukan tingkat kualitas
yang 'tepat'. Satu mungkin
6.3. PERSPEKTIF TERHADAP KUALITAS 127
kemudian memilih untuk menawarkan tingkat kualitas yang berbeda. Misalnya, video penanganan
layanan
streaming mungkin cepat dengan kualitas gambar rendah, atau lambat dengan kualitas gambar tinggi.
Itu
pengguna layanan tersebut kemudian memilih tingkat kualitas layanan (QoS) yang sesuai.
Pengembang cenderung memiliki pandangan mekanistik, berorientasi produk pada kualitas, di mana
kualitas dikaitkan dengan fitur produk. Dalam pandangan ini, kualitas didefinisikan oleh
melihat dari program ke pengguna (keramahan pengguna, penerimaan, dll.). Untuk menilai
kualitas sistem yang digunakan dalam organisasi, kita harus mengadopsi proses yang berorientasi
melihat kualitas juga, dimana kualitas didefinisikan dengan melihat dari pengguna ke
program. Ini mengarah pada gagasan seperti 'kecukupan' dan 'relevansi'. Misalnya, meja bantuan
staf dengan orang-orang terampil dapat memberikan kontribusi cukup untuk kualitas sistem
seperti yang dirasakan oleh penggunanya, tetapi atribut kualitas ini umumnya tidak mengikuti dari a
pandangan berbasis produk pada kualitas.
Pandangan yang sangat eklektik tentang kualitas diambil dalam Total Quality Management (TQM). Di
dalam
TQM, kualitas berlaku untuk setiap aspek organisasi, dan itu dikejar
oleh setiap karyawan organisasi tersebut. TQM memiliki tiga pilar:
1. Strategi nilai pelanggan Kualitas adalah kombinasi manfaat yang diperoleh

dari suatu produk dan pengorbanan yang dibutuhkan pelanggan. Keseimbangan
yang tepat antara manfaat dan pengorbanan ini harus dicari. Pemangku
kepentingan utama dalam tindakan penyeimbangan ini adalah pelanggan, bukan
bos pelanggan. Sikapnya bukan 'Kami tahu apa yang terbaik untuk pelanggan',
tetapi 'Mari kita tentukan dulu apa yang dibutuhkan pelanggan'.
2. Sistem organisasi Sistem mencakup lebih dari perangkat lunak dan

perangkat keras. Bahan lain, manusia, praktik kerja, termasuk dalam sistem juga.
Terlebih lagi, sistem melintasi batas unit atau departemen. Dalam pandangan
TQM, sistem menghilangkan kompleksitas daripada manusia. Dalam TQM,
budaya tidak didominasi oleh perebutan kekuasaan. Sebaliknya, organisasi
memanfaatkan kebanggaan karyawan dalam keahlian. Sumber daya manusia
dianggap sebagai sumber daya kritis daripada faktor biaya belaka.
3. Perbaikan terus-menerus Lingkungan 'tradisional' bersifat reaktif: perbaikan

dipicu jika ada masalah atau pengembangan produk baru. InTQM, kualitas
dikejar secara proaktif. Kesalahan tidak dipandang sebagai kegagalan pribadi
yang membutuhkan hukuman, tetapi sebagai kesempatan untuk belajar. Kinerja
tidak dievaluasi dalam retrospeksi baik atau buruk, tetapi variasi kinerja dianalisis
secara statistik untuk memahami penyebab kinerja yang buruk. Otoritas tidak
dipaksakan oleh posisi dan aturan, tetapi diperoleh dengan mengomunikasikan
visi.
TQM dengan demikian menekankan peningkatan daripada kesesuaian. CMM (lihat

bagian 6.6) dibangun di atas TQM, dan banyak teknik rekayasa persyaratan yang
dibahas dalam bab 9 juga merupakan penghargaan untuk TQM.
128 MENGELOLA KUALITAS
PERANGKAT LUNAK
6.4 Sistem Mutu
ISO, Organisasi Internasional untuk Standardisasi, telah mengembangkan ISO 9000,
serangkaian standar untuk sistem manajemen mutu. Seri ini terdiri dari tiga bagian:
ISO 9000:2000, ISO 9001:2000, dan ISO 9004:2000. ISO 9000 memberikan dasar
dan kosa kata dari rangkaian standar pada sistem mutu. ISO 9001 mengintegrasikan
tiga standar sebelumnya (berlabel ISO 9001, ISO 9002 dan ISO 9003). Ini
menentukan persyaratan sistem mutu untuk setiap organisasi yang perlu
menunjukkan kemampuannya untuk memberikan produk yang memenuhi
persyaratan pelanggan. ISO 9004 berisi pedoman untuk peningkatan kinerja. Ini
berlaku setelah penerapan ISO9001.
ISO 9001 adalah standar generik. Itu dapat diterapkan pada produk apa pun.
Pelengkap perangkat lunak yang bermanfaat adalah ISO/IEC 90003:2004, yang
berisi pedoman penerapan ISO 9001 pada perangkat lunak komputer. Ini adalah
standar bersama ISO dan IEC, Komite Elektroteknik Internasional. Ruang lingkup
ISO/IEC 90003 dijelaskan sebagai ”Standar Internasional ini menetapkan
persyaratan untuk sistem manajemen mutu di mana organisasi
�
6.5. JAMINAN KUALITAS PERANGKAT LUNAK 129
�
LUNAK
segera menjadi bantalan yang mahal dan sekadar gangguan bagi organisasi
pembangunan;
�
6.6. MODEL KEMATANGAN KAPABILITAS 131
(CMM)
Rencana Penjaminan Kualitas Perangkat Lunak menjelaskan bagaimana kualitas
perangkat lunak akan dinilai. Beberapa faktor kualitas dapat ditentukan secara
objektif. Sebagian besar faktor saat ini hanya dapat ditentukan secara subyektif.
Paling sering kemudian, kami akan mencoba untuk menilai kualitas dengan
membaca dokumen, dengan inspeksi, dengan langkah-langkah dan dengan tinjauan
sejawat. Dalam beberapa kasus, kami mungkin menguntungkan menggunakan alat
selama jaminan kualitas, khususnya, untuk analisis kode program statis dan
dinamis. Teknik aktual yang akan diterapkan di sini akan dibahas dalam bab tentang
pengujian.
6.6 Model Kematangan

Kemampuan (CMM)
Pertimbangkan rangkaian peristiwa berikut dalam pengembangan perangkat lunak hipotetis
proyek. Beberapa organisasi akan mengembangkan sistem otomasi perpustakaan terdistribusi.
Komputer terpusat menampung perangkat lunak dan basis data. Sejumlah
perpustakaan lokal terhubung ke mesin pusat melalui antarmuka berbasis web.
Organisasi memiliki beberapa pengalaman dengan otomasi perpustakaan, meskipun hanya dengan
sistem yang berdiri sendiri.
Dalam perjalanan proyek, sejumlah masalah muncul dengan sendirinya. Pertama
mereka tampaknya terputus dan tidak ada manajemen alarm. Ternyata itu
analisis kebutuhan belum terlalu menyeluruh. Persyaratan lokal berubah
untuk berbeda pada beberapa poin kecil. Padahal penyimpangan seperti itu yang pertama bisa ditangani
dengan cukup baik
dengan mudah, melacak semua permintaan perubahan menjadi masalah nyata setelah beberapa saat.
Ketika bagian dari sistem telah direalisasikan, tim mulai menguji antarmuka web.
Antarmuka ternyata terlalu rumit dan memakan waktu.
Proyek akhirnya mengalami krisis. Manajemen tidak memiliki sarana yang tepat untuk itu
menangani situasi. Ia mencoba untuk mengurangi fungsionalitas dan kualitas di a
cara yang agak serampangan. Pada akhirnya, sistem yang agak tidak memuaskan disampaikan dua
bulan terlambat. Selama fase pemeliharaan berikutnya, sejumlah masalah yang
dipecahkan, tetapi sistem tidak pernah menjadi sukses nyata.
Meskipun uraian di atas bersifat hipotetis, tidak semuanya tidak realistis. Banyak
sebuah organisasi memiliki kontrol yang tidak memadai atas proses pengembangan perangkat lunaknya.
Jika sebuah
proyek mendapat masalah, biasanya ditemukan cukup terlambat dan organisasi memilikinya
tidak ada cara lain selain bereaksi dengan cara yang agak kacau. Lebih sering daripada tidak,
kecepatan
bingung dengan kemajuan.
Langkah penting dalam mencoba mengatasi masalah ini adalah menyadari bahwa
proses pengembangan perangkat lunak memang dapat dikontrol, diukur, dan ditingkatkan.
Untuk mengukur proses peningkatan proses pengembangan perangkat lunak,
Watts Humphrey mengembangkan kerangka kerja kematangan perangkat lunak yang telah berkembang
menjadi
itu Model Kematangan Kemampuan (CMM). Kerangka kerja ini berutang pada Total Quality
Manajemen (TQM), yang pada gilirannya didasarkan pada prinsip-prinsip pengendalian kualitas statistik
seperti yang dirumuskan oleh Walter Shewart pada tahun 1930-an dan dikembangkan lebih lanjut oleh
W. Edwards
Deming dan Joseph Juran pada 1980-an. Awalnya, ada model CMM yang terpisah
untuk rekayasa perangkat lunak, rekayasa sistem, dan beberapa lainnya. Ini sekarang
LUNAK
telah terintegrasi, dan membawa label CMMI3. Versi yang dijelaskan di sini adalah
CMMIversi 1.1 untuk rekayasa perangkat lunak dan rekayasa sistem (Tim Produk
CMMI,2002). CMM dan CMMI dikembangkan di Software Engineering Institute (SEI)
of Carnegie Mellon University.
Dalam CMM (dan CMMI), proses perangkat lunak dicirikan menjadi salah satu
dari limatingkat kematangan, tingkat evolusi menuju pencapaian proses perangkat
lunak yang matang. Untuk mencapai tingkat kematangan tertentu, sejumlah area
proses harus di tempat. Area proses ini menunjukkan masalah penting yang harus
ditangani untuk mencapai level tersebut. Secara bersama-sama, area proses dari
suatu level mencapai serangkaian tujuan untuk level tersebut. Gambar 6.6
mencantumkan tingkat kematangan dan area proses terkait CMMI. Tingkat
kematangan CMMI dapat dicirikan sebagai berikut:
�
6.6. MODEL KEMATANGAN KAPABILITAS (CMM) 133
Level 5: Mengoptima
Inovasi dan
penyebaran organisasi
Analisis kausal dan
resolusi
Level 4: Level yang dikelola secara kuantitatif
Kinerja proses organisasi
Manajemen proyek kuantitatif
Tingkat 3: Tingkat yang ditentukan
Pengembangan kebutuhan
Solusi teknis
Integrasi produk
Verifikasi
Validasi
Fokus proses organisasi
Definisi proses organisasi
Pelatihan organisasi
manajemen proyek terintegrasi
Manajemen risiko
Analisis keputusan dan resolusi
Level 2: Level yang dapat diulang
Manajemen persyaratan
Perencanaan proyek
Pemantauan dan pengendalian proyek
Manajemen perjanjian pemasok
Pengukuran dan analisis
Jaminan kualitas proses dan produk
Manajemen konfigurasi
Tingkat 1: Tingkat awal
Gambar 6.6 Tingkat kematangan dan area proses terkait CMMI

– Jaminan kualitas proses dan produk melibatkan peninjauan dan audit
produk dan proses untuk memvalidasi bahwa mereka mematuhi standar
dan prosedur yang disepakati.
LUNAK
- Manajemen konfigurasi berkaitan dengan membangun dan memelihara
integritas semua item pekerjaan selama seluruh siklus hidup proyek. Ini
melibatkan identifikasi item konfigurasi dan garis dasar, dan prosedur
untuk mengontrol perubahannya.
�
6.6. MODEL KEMATANGAN KAPABILITAS 135
(CMM)
peningkatan kapabilitas proses organisasi dibuat menjadi tanggung
jawab organisasi secara keseluruhan, bukan manajer proyek individu.
– Definisi proses organisasi. Organisasi mengembangkan dan
memelihara sekumpulan aset proses perangkat lunak, seperti elemen
proses, model siklus hidup, pedoman untuk menyesuaikan model proses.
Setiap proyek menggunakan proses yang dibangun dari aset proses ini.
– Pelatihan organisasi. Tujuan dari program pelatihan adalah untuk
mengembangkan keterampilan dan pengetahuan individu yang diperlukan
untuk melakukan peran mereka. Kebutuhan pelatihan diidentifikasi pada
tingkat organisasi, proyek, dan individu. Pemenuhan kebutuhan ini juga
diperhatikan.
– Manajemen proyek terpadu melibatkan pengembangan proyek-spesifik
proses perangkat lunak dari serangkaian proses standar organisasi, juga
sebagai manajemen sebenarnya dari proyek menggunakan proses yang
disesuaikan. Sejak
proses perangkat lunak dari proyek yang berbeda memiliki nenek moyang yang
sama,
proyek sekarang dapat berbagi data dan pelajaran.
- Manajemen risiko menyangkut identifikasi potensi masalah, jadi
bahwa tindakan tepat waktu dapat diambil untuk mengurangi efek samping.
– Analisis keputusan dan resolusi Berkaitan dengan penetapan garis
pedoman tentang masalah mana yang harus tunduk pada proses evaluasi
formal, dan penerapan proses formal tersebut. Pemilihan komponen COTS
dan tinjauan arsitektur adalah contoh area di mana proses evaluasi formal
dapat diterapkan.
�
LUNAK
�
6.7. BEBERAPA CATATAN KRITIS 137
cacat yang ditemukan, menggunakan formulir sederhana untuk mengumpulkan data ini. Pada tingkat
berikutnya, data ini
digunakan untuk memperkirakan waktu dan kualitas. Pada tingkat yang lebih tinggi, data pribadi
digunakan
ke memperbaiki kinerja individu.
Prinsip dasar CMM dan PSP sangat mirip: kenali dirimu
proses, ukur kinerja Anda, dan dasarkan tindakan peningkatan Anda pada analisis
dari data yang dikumpulkan.
BOOTSTRAP dan SPICE adalah dua model kematangan mirip CMM lainnya. BOOT-
STRAP menggunakan peringkat jatuh tempo terpisah untuk setiap praktiknya. Salah satu yang menarik
fitur BOOTSTRAP adalah semua hasil penilaian dikumpulkan dalam database,
sehingga memungkinkan sebuah organisasi untuk memposisikan dirinya dengan membandingkan
skornya dengan yang ada
organisasi serupa.
SPICE adalah inisiatif internasional dan telah menjadi standar internasional
(ISO/IEC 15504). SPICE adalah singkatan dari Peningkatan dan Kemampuan Proses Perangkat Lunak
tekad. SPICE membedakan berbagai kategori proses, seperti manajemen
proses ment, proses pelanggan-pemasok dan proses rekayasa. Kemampuan
(kematangan) tingkat ditentukan untuk setiap kategori proses dan setiap proses. Menyukai
BOOTSTRAP, SPICE menghasilkan profil kematangan. Metodologi SPICE
sangat menekankan pada cara penilaian proses dilakukan.
6.7 Beberapa Catatan Kritis

Organisasi pengembangan perangkat lunak ada untuk mengembangkan perangkat lunak
daripada proses.
(Fayad, 1997)
Besarnya perhatian organisasi untuk mendapatkan sertifikasi CMM atau ISO 9000
memegang bahaya bahwa fokus bergeser dari pengembangan perangkat lunak ke proses
pengembangan.
Namun, organisasi bersertifikat tidak menjamin kualitas perangkat lunak
dikembangkan di bawahnya. Proses pengembangan yang matang bukanlah peluru perak. Sebuah
bingkai
sertifikat pasti tidak.
Model Kematangan Kemampuan SEI tampaknya paling cocok untuk yang sangat besar
perusahaan. Diragukan apakah perusahaan kecil mampu membayar waktu dan uang
diperlukan oleh program perbaikan proses seperti yang dianjurkan oleh CMM. Itu juga
diragukan apakah mereka mampu untuk menerapkan beberapa bidang proses, seperti
sebagai area proses 'fokus proses organisasi', yang memerlukan pengaturan dan
kelompok proses organisasi. Meskipun Proses Perangkat Lunak Pribadi dapat meringankan sebagian
atas kritik tersebut, PSP tidak memiliki status yang sama dengan CMM.
CMM berfokus pada disiplin: proses kerja terstruktur, rencana ketat, standar-
isasi. Ini lebih cocok untuk perusahaan besar daripada perusahaan kecil. Ini juga lebih cocok untuk
aktivitas
yang memberikan pendekatan yang ketat, seperti manajemen konfigurasi dan
pengujian. Analisis kebutuhan dan desain meminta sejumlah kreativitas, dan
pendekatan CMM murni mungkin memiliki efek mencekik di sini. Dikotomi yang dicatat dalam
bab 1 antara aspek permukaan rekayasa perangkat lunak seperti pabrik dan kerajinan
disini juga.
LUNAK
Tingkat kematangan asli CMM merupakan skala lima poin yang agak kasar. Jika
penilaian terhadap organisasi tingkat 2 mengungkapkan bahwa ia gagal memenuhi
kriteria tingkat 3 hanya pada satu masalah kecil, putusannya agak keras: organisasi
tersebut tetap berada pada tingkat 2. Hal ini mungkin tidak meningkatkan moral
setelah dua tahun kerja keras dan investasi yang signifikan. Untuk satu Hal ini,
implikasi dari penilaian jatuh tempo menempatkan tuntutan tinggi pada
keandalannya.
Penilaian organisasi yang agak kasar pada skala lima poin mungkin memiliki
konsekuensi luas lainnya. Pemerintah AS mewajibkan sertifikasi level 3 untuk
memenuhi syarat kontrak. Apakah ini berarti bahwa organisasi level 1 dan level 2
harus bekerja di bawah standar? Jika sertifikasi level 3 adalah yang terpenting,
apakah layak untuk membidik level 4 atau 5?
Level asli CMM seperti panel instrumen pesawat terbang dengan satu pengukur,
yang lebih dari itu hanya dapat menampilkan beberapa nilai diskrit dan dengan
demikian memberikan informasi yang sangat sedikit kepada pilot. Seseorang juga
dapat membayangkan 'panel instrumen' kematangan perangkat lunak dengan
banyak pengukur, yang masing-masing menunjukkan banyak detail. BOOTSTRAP
danSPICE adalah kerangka kerja yang menghasilkan profil kematangan, bukan skor
tunggal. Hal yang sama berlaku untuk CMMI, yang hadir dalam dua varian: a model
bertahap yang, seperti CMM asli, hanya memiliki lima tingkat kematangan, dan a
model kontinu di mana peningkatan proses dilakukan berdasarkan per area
proses.
6.8 Mulai
Pada bagian sebelumnya kita membahas berbagai cara untuk meninjau kualitas
produk perangkat lunak dan proses pengembangan terkait. Organisasi
pengembangan itu sendiri harus secara aktif mengejar produksi produk berkualitas,
dengan menetapkan sasaran kualitas, menilai kinerjanya sendiri, dan mengambil
tindakan untuk meningkatkan proses pengembangan. Ini membutuhkan
pemahaman tentang kemungkinan ketidakcukupan dalam proses pengembangan
dan kemungkinan penyebabnya. Pemahaman tersebut diperoleh melalui
pengumpulan data baik proses maupun produk yang dihasilkan, serta interpretasi
yang tepat atas angka-angka tersebut. Agak mudah untuk mengumpulkan data
dalam jumlah besar dan menerapkan berbagai jenis teknik pemasangan kurva untuk
data tersebut. Agar dapat menafsirkan tren yang diamati dengan benar, mereka
harus didukung oleh hipotesis yang masuk akal. Sebuah contoh yang
memang konyol diberikan dalam gambar 6.7. Angka pada tabel ini menunjukkan
bahwa sapi hitam menghasilkan lebih banyak susu daripada sapi putih. Penafsiran
yang agak naif adalah bahwa produktivitas dapat ditingkatkan secara signifikan
dengan mengecat ulang semua sapi putih.
Meskipun contoh itu sendiri konyol, mitranya dalam rekayasa perangkat lunak
tidak terlalu dibuat-buat. Banyak penelitian, misalnya, mencoba menentukan
hubungan antara angka yang menunjukkan kompleksitas komponen perangkat
lunak dan kualitas komponen tersebut. Beberapa dari studi tersebut menemukan
korelasi positif antara angka kompleksitas tersebut dan, katakanlah, jumlah cacat
yang ditemukan selama pengujian. Interpretasi langsung dari temuan tersebut
kemudian adalah untuk memaksakan
6.8. MULAI 139
Warn Produksi rata-rata

a
Putih 10
Hita 40
m
Gambar 6.7 Hubungan hipotesis antara warna sapi dan susu rata-rata
produksi
beberapa batas atas pada kompleksitas yang diizinkan untuk setiap komponen. Namun, ada
mungkin menjadi alasan bagus untuk komponen tertentu yang memiliki kompleksitas tinggi. Contohnya,
(Redmond dan Ah-Chuen, 1990) mempelajari metrik kompleksitas sejumlah besar
modul dari sistem operasi MINIX. Beberapa di antaranya, seperti modul itu
menangani urutan karakter melarikan diri dari keyboard, dianggap dapat dibenarkan
kompleks. Para ahli menilai dekomposisi lebih lanjut dari modul-modul ini tidak dibenarkan.
Menempatkan hanya batas atas pada nilai yang diizinkan dari metrik kompleksitas tertentu juga
pendekatan yang sederhana.
Organisasi harus menemukan peluangnya untuk perbaikan proses. Itu
cara yang lebih disukai untuk melakukannya adalah dengan mengikuti pendekatan bertahap dan
evolusioner di mana
langkah-langkah berikut dapat diidentifikasi:
1. Merumuskan hipotesis
2. Pilih metrik yang sesuai dengan hati-hati
3. Kumpulkan data
4. Menafsirkan data tersebut
5. Memulai tindakan untuk perbaikan

Langkah-langkah ini diulangi, sehingga efek dari tindakan tersebut divalidasi, dan selanjutnya
hipotesis dirumuskan. Dengan mengikuti pendekatan ini, pencarian akan kualitas akan berhasil
menembus organisasi Anda, yang selanjutnya akan menuai keuntungan.
Salah satu contoh dari pendekatan ini dibahas dalam (van Genuchten, 1991). Ia menjelaskan
studi empiris tentang alasan keterlambatan dalam pengembangan perangkat lunak. Studi ini mencakup
enam
proyek pengembangan dari satu departemen. Perhatian difokuskan pada koleksi
data yang berkaitan dengan waktu dan usaha, yaitu. perbedaan antara rencana dan kenyataan. A
formulir pengumpulan data satu halaman digunakan untuk tujuan ini (lihat gambar 6.8).
Sekitar tiga puluh alasan penundaan diidentifikasi. Ini diklasifikasikan menjadi enam
kategori setelah diskusi dengan pemimpin proyek, dan diselesaikan setelah studi percontohan.
Alasan penundaan ditemukan khusus untuk lingkungan.
Sebanyak 160 kegiatan dipelajari dari pertengahan 1988 hingga pertengahan 1989. Sekitar 50%
kegiatan melampaui rencana mereka lebih dari 10%. Perbandingan direncanakan
LUNAK
Berencan Sebenarnya Perbedaan Alasan

Upaya a
--- --- --- ---
Tanggal mulai --- --- --- ---
Tanggal --- --- --- ---
berakhir
Durasi --- --- --- ---
Gambar 6.8 Lembar waktu untuk setiap

kegiatan
dan angka aktual menunjukkan bahwa perbedaan relatif meningkat menjelang akhir
proyek. Ditemukan bahwa salah satu alasan utama perbedaan antara rencana dan
kenyataan adalah 'lebih banyak waktu dihabiskan untuk pekerjaan lain daripada
yang direncanakan'. Hasilnya ditafsirkan selama pertemuan dengan pemimpin
proyek dan manajer departemen. Diskusi mengkonfirmasi dan mengukur beberapa
kesan yang ada. Bagi sebagian orang, diskusi tersebut memberikan informasi baru.
Ini menunjukkan bahwa tindakan pemeliharaan terus-menerus mengganggu
pekerjaan pengembangan. Pertemuan tersebut mencakup diskusi tentang
kemungkinan tindakan untuk perbaikan. Diputuskan untuk menjadwalkan
pemeliharaan sejauh mungkin dalam 'pekan pemeliharaan' dan memasukkannya ke
dalam rencana triwulanan. Studi analisis lain dimulai untuk mendapatkan wawasan
lebih lanjut tentang kegiatan pemeliharaan.
Studi ini memberikan sejumlah wawasan yang berguna, beberapa di antaranya
memperkuat pernyataan yang dibuat sebelumnya:
�
6.9. RINGKASAN 141
metrik. Pendekatannya bersifat inkremental, di mana studi memberi peluang
untuk perbaikan kecil, dan menunjukkan jalan untuk studi selanjutnya.
6.9 Ringkasan
Dalam bab ini, kami menaruh banyak perhatian pada gagasan kualitas. Kualitas perangkat lunak
tidak datang secara gratis. Itu harus dikejar secara aktif. Penggunaan model yang terdefinisi dengan baik
dari proses pengembangan perangkat lunak dan analisis yang baik, desain dan implementasi
teknik adalah prasyarat. Namun, kualitas juga harus dikontrol dan dikelola.
Untuk dapat melakukannya, itu harus didefinisikan secara ketat. Ini bukan tanpa masalah,
seperti yang telah kita lihat di bagian 6.2 dan 6.3. Ada banyak taksonomi kualitas
atribut. Untuk setiap atribut ini, kita memerlukan definisi yang tepat, bersama dengan a
metrik yang dapat digunakan untuk menyatakan tujuan kualitas, dan untuk memeriksa bahwa tujuan
kualitas tersebut
memang merasa puas. Sebagian besar atribut kualitas berhubungan dengan aspek yang terutama dari
kepentingan pengembang perangkat lunak. Pandangan kualitas yang berorientasi pada insinyur ini sulit
untuk berdamai dengan aspek 'kesesuaian penggunaan' yang berorientasi pada pengguna.
Untuk sebagian besar atribut kualitas, hubungan antara apa yang sebenarnya diukur
(struktur modul, cacat yang ditemui, dll.) dan atribut yang kami minati adalah
tidak cukup didukung oleh hipotesis yang kuat. Misalnya, meskipun program dengan a
sejumlah besar keputusan seringkali rumit, ada contoh tandingan yang menunjukkan hal itu
jumlah keputusan (pada dasarnya kompleksitas siklomatik McCabe) bukanlah hal yang baik
ukuran kompleksitas program. Masalah metrik perangkat lunak dan yang terkait
masalah lebih lanjut dibahas dalam bab 12.
Standar utama untuk sistem mutu telah ditetapkan oleh ISO dan IEEE. Ini
standar memberikan pedoman rinci mengenai pengelolaan kualitas. Kualitas
jaminan dengan sendirinya tidak menjamin kualitas produk. Itu harus ditambah
oleh program kualitas dalam organisasi pengembangan. Bagian 6.8 menganjurkan an
pendekatan evolusioner untuk membangun program kualitas. Pendekatan seperti itu memungkinkan kita
untuk secara bertahap membangun keahlian dalam penggunaan data kuantitatif untuk menemukan
peluang
perbaikan proses.
Kami akhirnya membuat sketsa kerangka kerja kematangan perangkat lunak yang dikembangkan
oleh Perangkat Lunak
Institut Teknik. Kerangka kerja ini menawarkan sarana untuk menilai keadaan perangkat lunak
praktik rekayasa, serta sejumlah langkah untuk meningkatkan pengembangan perangkat lunak
proses. Salah satu kontribusi utama CMM dan inisiatif serupa adalah fokus mereka
pada perbaikan terus-menerus. Garis pemikiran ini kemudian berhasil
diterapkan ke daerah lain, menghasilkan antara lain People-CMM, Formal
spesifikasi-CMM, dan Pengukuran-CMM.

Fenton dan Pfleeger (1996) memberikan gambaran yang sangat menyeluruh dari bidang
metrik perangkat lunak. Kerangka pengukuran yang dibahas pada bagian 6.1 didasarkan
LUNAK
pada (Kitchenham et al., 1995). Kaner dan Bond (2004) juga memberikan kerangka
kerja untuk mengevaluasi metrik. (Perangkat Lunak, 1997b) dan (JSS, 1995) adalah
terbitan jurnal khusus tentang metrik perangkat lunak. Banyak artikel dalam edisi ini
membahas penerapan metrik dalam program kualitas.
Salah satu publikasi besar pertama tentang topik program pengukuran adalah
(Grady dan Caswell, 1987). Faktor keberhasilan program pengukuran dapat
ditemukan dalam (Hall dan Fenton, 1997) dan (Gopal et al., 2002). Pfleeger (1995)
menguraikan hubungan antara program metrik dan tingkat kematangan. Niessink dan
van Vliet (1998b) memberikan kerangka mirip CMM untuk kemampuan pengukuran
organisasi perangkat lunak.
Taksonomi atribut kualitas perangkat lunak yang paling terkenal diberikan dalam
(McCallet al., 1977) dan (Boehm et al., 1978). Atribut kualitas ISO dijelaskan dalam
(ISO9126, 2001) dan (Côté et al., 2006). Diskusi kritis skema ini diberikan dalam
(Kitchenham dan Pfleeger, 1996) dan (Fenton dan Pfleeger, 1996). Suryanet al.
(2004) memberikan gambaran tentang ISO/IEC 90003.
Definisi kualitas Garvin diberikan dalam (Garvin, 1984). Berbagai jenis manfaat
dalam definisi kualitas berbasis nilai dibahas dalam (Simmons, 1996). Untuk
pembahasan lebih lanjut tentang Total Quality Management, lihat (Bounds et al., 1994)
atau (Ishikawa, 1985).
Model Kematangan Kemampuan didasarkan pada karya seminal WattsHumphrey
(Humphrey, 1988, 1989). Untuk penjelasan lengkap tentang Model Maturitas
Kemampuan Terintegrasi, lihat (Tim Produk CMMI, 2002). Pengalaman praktis dengan
program peningkatan proses perangkat lunak dibahas dalam (Wohlwend dan
Rosenbaum, 1994), (Diaz dan Sligo, 1997) dan (Fitzgerald dan O'Kane, 1999). Rainer
dan Hall (2003) mendiskusikan faktor kesuksesan, dan Baddoo dan Hall (2003)
mendiskusikan demotivator untuk SPI. Sebuah survei manfaat dan biaya program
perbaikan proses perangkat lunak diberikan dalam (Herbsleb et al., 1997) dan
(Gartner, 2001). Kedewasaan tinggi, organisasi CMM level 5 dibahas dalam
(Software, 2000).
Proses Perangkat Lunak Pribadi (PSP) dijelaskan dalam (Humphrey, 1996) dan
(Humphrey, 1997a). BOOTSTRAP dijelaskan dalam (Kuvaja et al., 1994) dan SPICEin
(El Emam et al., 1997).
Kritik terhadap pendekatan mirip CMM ditemukan dalam (Fayad, 1997), (Fayad
dan Laitinen, 1997) dan (Conradi dan Fuggetta, 2002). El Emam dan Madhavji (1995)
membahas reliabilitas penilaian proses.
Perbaikan proses merupakan topik dari beberapa terbitan jurnal khusus; lihat
(CACM,1997), (Perangkat Lunak, 1994). Jurnal Proses Perangkat Lunak: Peningkatan
dan Praktek sepenuhnya dikhususkan untuk topik ini.
Latihan
1. Definisikan istilah-istilah berikut: pengukuran, ukuran, metrik.
2. Apa perbedaan antara atribut internal dan eksternal?

3. Definisikan istilahnya kondisi representasi. Mengapa penting bahwa suatu ukuran

memenuhi syarat representasi?
4. Apa perbedaan utama antara skala ordinal dan skala interval?

Dan antara skala interval dan skala rasio?
5. Apa perbedaan utama antara berbasis pengguna dan berbasis produk

definisi kualitas?
6. Yang merupakan tiga kategori faktor kualitas perangkat lunak dibedakan oleh
McCall?
7. Diskusikan pandangan transenden kualitas perangkat lunak.
8. Manakah dari definisi kualitas Garvin yang paling banyak digunakan oleh perangkat lunak
pengembang? Dan mana yang paling banyak digunakan oleh pengguna?
9. Sudut pandang kualitas mana yang ditekankan oleh ISO 9126?
10. Diskusikan landasan Total Quality Management.
11. Apa tujuan dari Jaminan Kualitas Perangkat Lunak?
12. Mengapa organisasi Penjaminan Kualitas Perangkat Lunak harus mandiri

organisasi pembangunan?
13. Mengapa anggota proyek harus mendapatkan umpan balik tentang penggunaan data
berkualitas mereka
serahkan ke Grup Penjaminan Mutu?
14. Mendeskripsikan tingkat maturitas Model Capability Maturity.
15. Apa perbedaan utama antara level 2 dan level 3 dari Capability
Model Kedewasaan?
16. Apa perbedaan antara versi CMMI bertahap dan berkelanjutan?
17. Mengapa penting untuk mengukur persyaratan mutu?
18. �
LUNAK
20.~
Dapatkah Anda memikirkan kemungkinan kesimpulan negatif dari kumpulan data yang
sama ini,
yaitu bahwa situasinya telah menjadi lebih buruk sejak 1988?
7
Perkiraan biaya
TUJUAN PEMBELAJARAN
�
147
Pengembangan perangkat lunak membutuhkan waktu dan uang. Saat menugaskan sebuah
bangunan
proyek, Anda mengharapkan estimasi biaya dan waktu pengembangan yang andal
depan. Mendapatkan perkiraan biaya dan jadwal yang dapat diandalkan untuk
pengembangan perangkat lunak
proyek sebagian besar masih mimpi. Biaya pengembangan perangkat lunak terkenal
sulit diperkirakan secara andal pada tahap awal. Karena kemajuan sulit untuk 'melihat'
--kapan sebuah perangkat lunak 50% selesai? --schedule selip sering terjadi
tidak terdeteksi selama beberapa waktu, dan overruns jadwal adalah aturannya, bukan
pengecualian. Dalam bab ini, kita melihat berbagai cara untuk memperkirakan perangkat
lunak
biaya dan jadwal.
Saat menugaskan konstruksi rumah, mendekorasi kamar mandi, atau meletakkan-

keluar taman, kami mengharapkan perkiraan yang tepat dari biaya yang harus dikeluarkan sebelum
operasi dimulai. Seorang tukang kebun mampu memberikan indikasi kasar tentang biaya
dasar, katakanlah, luas tanah, ukuran teras atau area rumput yang diinginkan, apakah
atau tidak kolam diperlukan, dan informasi serupa. Estimasi bisa dibuat lebih
tepat dalam dialog lebih lanjut, sebelum bit bumi pertama diputar. Jika Anda mengharapkan yang serupa
akurasi sehubungan dengan perkiraan biaya untuk proyek pengembangan perangkat lunak, Anda
berada
untuk sebuah kejutan.
Memperkirakan biaya proyek pengembangan perangkat lunak adalah bidang yang belum dijelajahi,
di mana seseorang terlalu sering mengandalkan perkiraan belaka. Ada pengecualian untuk ini
prosedur, untungnya. Sekarang ada sejumlah model algoritmik yang memungkinkan kita
untuk memperkirakan total biaya dan waktu pengembangan proyek pengembangan perangkat lunak,
berdasarkan
perkiraan untuk sejumlah pemicu biaya yang relevan. Beberapa yang penting
model estimasi biaya algoritmik dibahas pada bagian 7.1.
Dalam sebagian besar model estimasi biaya, hubungan sederhana antara biaya dan usaha adalah
diasumsikan. Upaya dapat diukur dalam man-months, misalnya, dan setiap man-
bulan diambil untuk dikenakan jumlah tetap, katakanlah, $5000. Total estimasi biaya adalah
kemudian diperoleh hanya dengan mengalikan perkiraan jumlah bulan kerja dengan ini
faktor konstanta. Dalam bab ini, kami dengan bebas menggunakan istilah biaya dan upaya seolah-olah
memang demikian adanya
sinonim.
Gagasan biaya total biasanya diambil untuk menunjukkan biaya awal
upaya pengembangan perangkat lunak, yaitu biaya rekayasa persyaratan, desain,
tahap implementasi dan pengujian. Sehingga, biaya perawatan tidak diperhitungkan
akun. Kecuali secara eksplisit dinyatakan sebaliknya, pengertian biaya ini juga akan digunakan oleh
kita. Dengan nada yang sama, waktu pengembangan akan diartikan: waktu antara
mulai dari fase rekayasa persyaratan dan titik waktu ketika perangkat lunak
disampaikan kepada pelanggan. Terakhir, pengertian biaya seperti yang digunakan di sini, tidak
termasuk kemungkinan biaya perangkat keras juga. Ini hanya menyangkut biaya personel yang terlibat
dalam
pengembangan perangkat lunak.
Penelitian di bidang estimasi biaya jauh dari kristalisasi. Model yang berbeda
menggunakan ukuran dan penggerak biaya yang berbeda, sehingga perbandingan timbal balik menjadi
sangat sulit.
148 PERKIRAAN BIAYA
Misalkan beberapa model menggunakan persamaan bentuk:

1:05
149
mencirikan hubungan-hubungan ini. Contoh relasi seperti itu adalah yang diberikan di atas,
yang berhubungan DAN
150 PERKIRAAN BIAYA
�
7.1. MODEL ALGORITMI 151
jadi, kami memperkirakan biaya yang diharapkan karena terukur properti dari proyek
di tangan. Sama seperti biaya menata taman mungkin merupakan kombinasi
tertimbang dari sejumlah atribut yang relevan (ukuran taman, ukuran area rumput,
ya/tidak untuk kolam), jadi kami ingin memperkirakan biaya pengembangan
perangkat lunak proyek. Pada bagian ini, kita membahas upaya untuk mendapatkan
model algoritmik untuk memperkirakan biaya perangkat lunak. Pada pendahuluan
bab ini, kita melihat bahwa upaya pemrograman berkorelasi kuat dengan ukuran
program. Ada berbagai model (non-linear) yang mengekspresikan korelasi ini.
Bentuk umumnya adalah
DAN
15 PERKIRAAN BIAYA
2
menurunkan biaya per unit. Dengan demikian, kami menyadari peningkatan laba atas investasi.
Dalam kasus sebaliknya, kita menemukan skala disekonomis: setelah titik tertentu, produksi
unit tambahan menimbulkan biaya tambahan.
Dalam hal perangkat lunak, baris kode adalah produknya. Jika kita berasumsi bahwa
memproduksi banyak kode akan lebih murah per baris kode, formula seperti itu
Walston-Felix (
menyetel parameter model ke lingkungan tertentu (proses yang disebut kalibrasi)

diperlukan.
Masalah terpenting dengan jenis model ini adalah mendapatkan a dapat diandalkan memperkirakan
dari ukuran perangkat lunak sejak dini. Bagaimana seharusnya kita memperkirakan jumlah halaman
dalam a
novel belum ditulis? Bahkan jika kita mengetahui jumlah karakter, jumlah
lokasi dan interval waktu di mana cerita terjadi, kita tidak boleh berharap
perkiraan ukuran realistis di depan. Semakin maju kita dengan proyek ini, semakin
lebih akurat perkiraan ukuran kami akan mendapatkan. Jika desainnya kurang lebih selesai, kami boleh
(mungkin) membentuk kesan yang masuk akal tentang ukuran perangkat lunak yang dihasilkan. Hanya
jika
sistem sudah disampaikan, apakah kita tahu angka pastinya.
Pelanggan, bagaimanapun, membutuhkan perkiraan biaya yang dapat diandalkan sejak dini. Dalam
kasus seperti itu,
baris kode adalah ukuran yang terlalu eksak untuk bertindak sebagai dasar perkiraan biaya. Kami
sehingga harus mencari alternatif. Pada bagian 7.1.4 kita membahas berbasis model
pada jumlah yang diketahui pada tahap sebelumnya.
Kami juga dapat beralih ke model lain selama pelaksanaan proyek, karena kami
mungkin berharap untuk mendapatkan data yang lebih andal karena proyek sedang membuat kemajuan.
Kami kemudian mendapatkan a
kaskade model estimasi biaya yang semakin rinci. COCOMO 2 adalah contohnya
ini; lihat bagian 7.1.5.
7.1.1 Walston--Felix
Persamaan dasar model Walston dan Felix (Walston dan Felix, 1977) adalah
0:91
1 PERKIRAAN BIAYA
5
4
Nilai variabel J
Jumlah faktor yang dipertimbangkan dalam model ini cukup tinggi (29 faktor dari
51 proyek). Juga tidak jelas sejauh mana berbagai faktor mempengaruhi masing-masing
lainnya. Terakhir, jumlah alternatif per faktor hanya tiga, dan sepertinya tidak
untuk menawarkan pilihan yang cukup dalam situasi praktis.
Namun demikian, pendekatan yang diambil oleh Walston dan Felix serta daftar biayanya
driver telah memainkan peran yang sangat penting dalam mengarahkan penelitian selanjutnya di bidang
ini.
7.1.2 KELAPA
COCOMO (COst COst MODel) adalah salah satu model estimasi biaya algoritmik
yang paling baik didokumentasikan. Dalam bentuknya yang paling sederhana,
disebut Basic COCOMO, rumus yang menghubungkan upaya dengan ukuran
perangkat lunak, berbunyi
DAN
156
ME organik
MBL 1:05
OKI
R
Gambar 7.5 Kurva Rayleigh untuk jadwal perangkat lunak (Sumber: M.L. Shooman, Tutorial
pada model biaya perangkat lunak, Katalog IEEE nr TH0067-9 (1979), 1979 IEEE.)
karena informasi yang diperlukan untuk menentukan peringkat dari berbagai pemicu biaya adalah
pada umumnya tidak tersedia. Jadi kita hanya memiliki kemungkinan untuk menguji dasar
model. Di sini, kami memperoleh perbedaan yang cukup besar antara upaya yang diperkirakan dan
upaya nyata yang diperlukan.
Keuntungan utama COCOMO adalah kami mengetahui semua detailnya. Pembaruan besar
dari model COCOMO, lebih mencerminkan praktik perangkat lunak saat ini dan masa depan
dibahas di bagian 7.1.5.
7.1.3 Putnam
Norden mempelajari distribusi tenaga kerja dari waktu ke waktu di sejumlah proyek
pengembangan perangkat lunak pada 1960-an. Dia menemukan bahwa distribusi ini
seringkali memiliki bentuk yang sangat khas yang dapat didekati dengan baik oleh
distribusi Rayleigh. Berdasarkan temuan ini, Putnam mengembangkan model
estimasi biaya dimana tenaga kerja yang dibutuhkan (
TN
158 PERKIRAAN BIAYA
untuk produk dari kapasitas pemecahan masalah yang tersedia dan sebagian kecil
dari masalah yang belum terpecahkan. Jika jumlah total pekerjaan yang harus
dilakukan diatur ke 1, ini menghasilkan:
D DI DALAM
indikator ukuran. FPA sangat cocok untuk proyek yang ditujukan untuk mewujudkan bisnis
aplikasi untuk, dalam aplikasi ini, struktur data memainkan peran yang sangat dominan
peran. Metode ini kurang cocok untuk proyek yang struktur datanya berperan a
peran yang kurang menonjol, dan penekanannya adalah pada algoritma (seperti kompiler dan
kebanyakan
perangkat lunak waktu nyata).
Lima entitas berikut memainkan peran sentral dalam model FPA:
�
160 PERKIRAAN BIAYA
Tingkat kerumitan
Jenis
Sederhana Rata-ra Komple
ta ks
Memasukkan ( SAYA
komunikasi data
Fungsi terdistribusi
Pertunjukan
Konfigurasi yang banyak digunakan
Tingkat transaksi
entri data online
Efisiensi pengguna akhir
Pembaruan daring
Pemrosesan yang kompleks
Dapat digunakan kembali
Kemudahan instalasi
Kemudahan operasional
Beberapa situs
Memfasilitasi perubahan
Gambar 7.8 Karakteristik aplikasi pada FPA
antarmuka tetap agak kabur. Grup Pengguna Titik Fungsi Internasional

(IFPUG) telah menerbitkan pedoman ekstensif tentang cara mengklasifikasikan dan menghitung
berbagai
entitas yang terlibat. Ini harus mengatasi banyak kesulitan yang dialami analis
menghitung titik fungsi dengan cara yang seragam.
Masalah lebih lanjut dengan FPA berkaitan dengan penggunaan skala ordinal dan caranya
kompleksitas ditangani. FPA membedakan tiga tingkat kompleksitas komponen saja.
Sebuah komponen dengan 100 elemen mendapatkan paling banyak dua kali jumlah titik fungsi
komponen dengan satu elemen. Telah disarankan bahwa model yang menggunakan
data kompleksitas mentah, yaitu jumlah elemen data dan tipe file yang direferensikan,
mungkin bekerja sebaik, atau bahkan lebih baik daripada, model yang menggunakan turunan ordinal
daripadanya. Dalam artian, kompleksitas dihitung dua kali: baik melalui tingkat kompleksitas
komponen dan melalui salah satu karakteristik aplikasi. Namun dirasakan bahwa
sistem yang sangat kompleks tidak ditangani secara memadai, karena FPA dominan
berkaitan dengan penghitungan input dan output yang terlihat secara eksternal.
Dalam menerapkan metode estimasi biaya FPA, masih perlu dilakukan kalibrasi
berbagai entitas ke lingkungan Anda sendiri. Ini memegang lebih untuk koreksi
yang mencerminkan karakteristik aplikasi yang berbeda, dan transisi dari fungsi
menunjuk ke baris kode.
7.1.5 COCOMO 2: Variasi Tema

COCOMO 2 adalah revisi dari model COCOMO 1981, disesuaikan dengan siklus hidup
praktik tahun 1990-an dan 2000-an. Ini mencerminkan pengalaman kumulatif kami dengan dan
162 PERKIRAAN BIAYA
pengetahuan estimasi biaya. Dengan membandingkan konstituennya dengan model
estimasi biaya sebelumnya, ini juga memberi kita sarana untuk belajar tentang
perubahan signifikan dalam perdagangan kita selama beberapa dekade terakhir.
COCOMO 2 menyediakan tiga model estimasi biaya yang semakin rinci.
Model-model ini dapat digunakan untuk berbagai jenis proyek, serta selama
berbagai tahapan proyek tunggal:
– itu Komposisi Aplikasi model, terutama ditujukan untuk upaya pembuatan

prototipe, misalnya untuk menyelesaikan masalah antarmuka pengguna
(Namanya menunjukkan penggunaan berat komponen yang ada, mungkin
dalam konteks lingkungan CASE yang kuat.)
– itu Desain Awal model, ditujukan pada tahap desain arsitektur
– itu Post-Arsitektur model untuk tahap pengembangan sebenarnya dari

perangkat lunak produk
Model Post-Arsitektur dapat dianggap sebagai pembaruan dari model COCOMO

asli; model Desain Awal adalah model mirip FPA; dan model Komposisi Aplikasi
didasarkan pada penghitungan komponen sistem dengan perincian besar, seperti
layar dan laporan.
Model Komposisi Aplikasi didasarkan pada penghitungan Poin Objek.
ObjectPoints tidak ada hubungannya dengan objek seperti pada pengembangan
berorientasi objek. Dalam konteks ini, objek adalah layar, laporan, dan modul 3GL.
Akar dari jenis model ini dapat ditelusuri kembali ke beberapa variasi ukuran
ukuran tipe FPA. Poin fungsi seperti yang digunakan dalam FPA dimaksudkan untuk
menjadi ukuran fungsi sistem yang berorientasi pada pengguna. Fungsi pengguna
yang diukur adalah input, output, pertanyaan, dll. Kami dapat menduga bahwa
fungsi pengguna ini bergantung pada teknologi, dan bahwa FPA terutama
mencerminkan dunia berorientasi batch pada tahun 1970-an.
Sistem administrasi masa kini mungkin lebih baik ditandai dengan jumlah menu
atau layarnya. Garis pemikiran ini telah diikuti dalam berbagai penelitian. Banker et
al. (1991) membandingkan Object Points dengan Function Points untuk sampel
proyek perangkat lunak, dan menemukan bahwa Object Points hampir sama
baiknya dengan Function Points. Namun, Object Points lebih mudah untuk
ditentukan, dan pada titik waktu yang lebih awal. Upaya total diperkirakan
dalam model Komposisi Aplikasi sebagai berikut:
1. Perkirakan jumlah layar, laporan, dan komponen 3GL di aplikasi tion.
2. Tentukan tingkat kerumitan setiap layar dan laporan (sederhana, sedang, atau
sulit). Komponen 3GL dianggap selalu sulit. Kompleksitas layar bergantung pada
jumlah tampilan dan tabel yang ada di dalamnya. Kompleksitas laporan
bergantung pada jumlah bagian dan tabel yang ada di dalamnya. Sebuah tabel
klasifikasi mirip dengan FPA (lihat gambar 7.9 untuk contoh) digunakan untuk
menentukan tingkat kompleksitas.
3. Gunakan angka yang diberikan pada gambar 7.10 untuk menentukan usaha relatif (pada Object
Points) untuk mengimplementasikan objek.
4. Jumlah Poin Objek untuk masing-masing objek menghasilkan jumlah

Poin Objek untuk keseluruhan sistem.
5. Perkirakan persentase penggunaan ulang, yang menghasilkan jumlah Poin Objek Baru
(NOP) sebagai berikut:
NOP
164 PERKIRAAN BIAYA
Model Desain Awal menggunakan titik fungsi yang tidak disesuaikan (UFP) sebagai
ukuran dasarnya. Poin fungsi yang tidak disesuaikan ini dihitung dengan cara yang
sama seperti dihitung di FPA. Selanjutnya, titik fungsi yang tidak disesuaikan diubah
menjadi Source Lines Of Code (SLOC), menggunakan rasio SLOC/UFP yang
bergantung pada bahasa pemrograman yang digunakan. Dalam lingkungan tipikal,
setiap UFP dapat berhubungan dengan, katakanlah, 91 baris Pascal, 128 baris C,
29 baris C++, atau 320 baris bahasa rakitan. Jelas, angka-angka ini spesifik untuk
lingkungan.
Model Early Design tidak menggunakan skema FPA untuk memperhitungkan
karakteristik aplikasi. Sebagai gantinya, ia menggunakan tujuh penggerak biaya,
yang merupakan kombinasi dari penggerak biaya lengkap model Post-Arsitektur.
Penggerak biaya menengah dan tereduksi adalah:
�
Ini berbeda dari model COCOMO asli dalam set driver biayanya, penggunaan jalur
kode sebagai ukuran dasarnya, dan rentang nilai eksponen B
166 PERKIRAAN BIAYA
�
7.1. 167
MODEL
ALGORI
TMI Peringkat
P Sangat Rendah Nominal Tinggi Sangat Tambaha
e n
m
i
c
u
b
i
a
y
a
rendah tinggi tinggi
F
a 0,75 0,88 1.00 1.15 1.39
k
t
o
r
p
r
o
d
u
k
D
i
p
e
r
l
u
k
a
n
k
e
a
n
d
a
l
a
n
U 0,93 1.00 1.09 1.19
k 0,75 1.66
u
r
a
n
b
a
s
i
s
d
a
t
a
K 0,88 1.00 1.15 1.30
o
m
p
l
e
k
s
i
t
a
s
p
r
o
d
u
k
D 0,91 1.00 1.14 1.29 1.49
i 0,89
p
e
r
l
u
k
a
n
p
e
n
g
g
u
n
a
a
n
k
e
m
b
a
l
i
Kebutuhan 0,95 1.00 1.06 1.13
dokumentasi
F
a 1.00 1.11 1.31 1.67
k
t
o 0,87
r
p
l 1,50
a
t
f
o
r
m
K
e
n
d
a
l
a
w
a
k
t
u
e
k
s
e
k
u
s
i
K 1.00 1.06 1.21 1.57
e
n
d
a
l
a
p
e
n
y
i
m
p
a
n
a
n
u
t
a
m
a
V 1.00 1.15 1.30
o
l
a
t
i
l
i
t
a
s
p
l
a
t
f
o
r
m
F
a 1.22 1.00 0,83 0,67
k
t
o
r
p
e
r
s
o
n
e
l
K
e
m
a
m
p
u
a
n
a
n
a
l
i
s
Kemampuan 1.37 1.16 1.00 0,87 0,74
pemrogram
Pengalaman 1.22 1.10 1.00 0,89 0,81
aplikasi
P 1.24 1.10 1.00 0,92 0,84
e
n
g
a
l
a 0,78
m
a
n
p
l
a
t
f
o
r
m
Peng 1.25 1.12 1.00 0,88 0,81
alama
n
bahas
a dan
alat
K 1.24 1.10 1.00 0,92 0,84
o
n
t
i
n
u
i
t
a
s
p
e
r
s
o
n
i
l
F
a 1.24 1.12 1.00 0,86 0,72
k
t
o
r
p
r
o
y
e
k
P
e
n
g
g
u
n
a
a
n
p
e
r
a
n
g
k
a
t
l
u
n
a
k
P 1.25 1.10 1.00 0,92 0,84
e
n
g
e
m
b
a
n
g
a
n
m
u
l
t
i
-
s
i
t
u
s
Jadwal 1.29 1.10 1.00 1.00 1.00
pengemb
angan
yang
dibutuhka
n
Gambar 7.11 Penggerak biaya dan pengganda upaya terkait di COCOMO 2

(Sumber: B.W.Boehm et al., Manual Definisi Model COCOMO II, Universitas
California Selatan, 1997.)
berkisar dari 0% (tidak diperlukan usaha ekstra) hingga 8% (ujian ekstensif, evaluasi dan
dokumentasi yang diperlukan).
Kedua persentase ini ditambahkan ke faktor penyesuaian AAF
168 PERKIRAAN BIAYA
7.2 Pedoman
Memperkirakan
Biaya
Model-model yang dibahas di bagian sebelumnya didasarkan pada data tentang
proyek-proyek sebelumnya. Salah satu masalah utama dalam menerapkan model-model
ini adalah semata-mata kekurangan data kuantitatif tentang proyek masa lalu. Tidak ada
cukup data yang tersedia. Meskipun pentingnya basis data seperti itu sekarang telah
diakui secara luas, kami masih belum secara rutin mengumpulkan data pada
proyek-proyek saat ini. Sepertinya kita tidak bisa menyisihkan waktu untuk
mengumpulkan data; kita harus menulis perangkat lunak. DeMarco (1982) membuat
perbandingan dengan tukang cukur abad pertengahan yang juga bertindak sebagai
dokter. Dia bisa membuat keberatan yang sama: 'Kami tidak punya waktu untuk
mengukur suhu pasien kami, karena kami harus memotong rambutnya.' Karena itu kami
harus beralih ke metode lain untuk memperkirakan biaya. Metode lain ini
didasarkan pada keahlian estimator. Dalam melakukannya, perangkap tertentu harus
dielakkan. Sangat penting untuk mencegah argumen politik memasuki arena. Garis
penalaran khas yang mencerminkan penalaran politik adalah:
�
7.2. PEDOMAN UNTUK ESTIMASI BIAYA 169
– Memberikan kesempatan belajar, dan
– Pertimbangkan untuk menunda atau menghindari estimasi upaya.

Metode estimasi bernuansa politis yang disebutkan di atas semuanya mencampuradukkan estimasi,
perencanaan dan penawaran. Ini memiliki tujuan yang berbeda. Satu-satunya tujuan estimasi adalah
ketepatan. Perencanaan melibatkan penilaian risiko dan jadwal. Penawaran adalah tentang
memenangkan a
kontrak. Meskipun kegiatan ini memiliki tujuan yang berbeda, mereka tentu saja terkait. A
tawaran rendah misalnya umumnya menimbulkan jadwal yang ketat dan risiko yang lebih tinggi.
Eksperimen yang menarik tentang efek penawaran pada sisa proyek
dijelaskan dalam (Jørgensen dan Grimstad, 2004). Dalam percobaan ini, penulis mempelajari
apa yang disebut kutukan pemenang, sebuah fenomena yang diketahui dari lelang, di mana para
pemain berada
tidak yakin akan nilai suatu barang ketika mereka menawar. Tawaran tertinggi menang, tetapi
pemenangnya
mungkin tersisa dengan item yang nilainya kurang dari yang dibayarkan. Istilah ini pertama kali
diciptakan di
tahun 1950-an, ketika industri minyak tidak memiliki cara yang akurat untuk memperkirakan nilai minyak
mereka
bidang. Di bidang perangkat lunak, ia memiliki karakteristik sebagai berikut:
– Penyedia perangkat lunak berbeda dalam optimisme dalam perkiraan biaya yang paling
mungkin:
ada yang terlalu optimis, ada yang realistis, dan ada yang pesimis.
– Penyedia perangkat lunak dengan perkiraan terlalu optimis cenderung memiliki tawaran
terendah.
– Klien perangkat lunak memerlukan kontrak harga tetap.
– Klien perangkat lunak cenderung memilih penyedia dengan tawaran rendah.

Hasilnya seringkali adalah kemenangan Pyrrhic, kontrak yang menghasilkan keuntungan rendah atau
negatif
kepada penawar. Tetapi kontrak semacam itu mungkin juga berisiko bagi klien. Jørgensen dan
Grimstad (2004) menjelaskan sebuah percobaan di mana mereka benar-benar menanyakan 35
perusahaan
untuk penawaran pada spesifikasi persyaratan tertentu. Selanjutnya, empat perusahaan diminta
mengimplementasikan sistem. Mereka menemukan bahwa perusahaan dengan tawaran terendah
dikeluarkan
risiko terbesar.
Menyedot karpet dengan dua arah ortogonal kemungkinan akan mengangkat lebih banyak kotoran
daripada menyedot karpet itu dua kali ke arah yang sama. Demikian juga kombinasi dari
metode estimasi yang cukup berbeda memberikan estimasi yang lebih baik. Jadi satu dapat
menggabungkan
perkiraan COCOMO dengan ahli, atau perkiraan dari ahli dengan a
latar belakang yang berbeda. Dengan cara ini, bias yang melekat pada suatu metode atau kelas
ahli dikurangi.
Estimator harus bertanggung jawab atas perkiraan mereka. Lederer dan Prasad
(2000) menemukan bahwa penggunaan estimasi dalam evaluasi kinerja perangkat lunak
manajer dan profesional adalah satu-satunya praktik yang mengarah pada estimasi yang lebih baik. Di
sebuah
bentuk yang sedikit lebih lemah, setidaknya seseorang dapat meminta pembenaran perkiraan tersebut.
Misalnya
pembenaran bisa merujuk pada model terkalibrasi yang digunakan, atau struktur rincian kerja
mana perkiraan biaya komponen berasal dari proyek serupa.
Karena kurangnya data keras, biaya proyek pengembangan perangkat lunak seringkali mahal
diperkirakan melalui perbandingan dengan proyek-proyek sebelumnya. Jika estimatornya sangat
170 PERKIRAAN BIAYA
berpengalaman, perkiraan biaya yang masuk akal dapat dihasilkan. Namun, efek
pembelajaran dari pengalaman sebelumnya dapat menyebabkan perkiraan yang terlalu
pesimis dalam kasus ini. Kami mungkin berharap bahwa pengalaman yang diperoleh
dengan jenis aplikasi tertentu mengarah pada produktivitas yang lebih tinggi untuk proyek
selanjutnya. Aplikasi serupa sehingga menimbulkan biaya yang lebih rendah. (McClure,
1968) menjelaskan situasi di mana tim diminta untuk mengembangkan
Kompiler FORTRAN untuk tiga mesin berbeda. Usaha yang dibutuhkan (dalam
man-months) untuk ketiga proyek ini disajikan pada Gambar 7.12.
Penyusun Jumlah man-month yang dibutuhkan
123 72361
4
Gambar 7.12 Efek pembelajaran dalam penulisan compiler

FORTRAN
Di sisi lain, keadaan khusus dan karakteristik tertentu dari proyek tertentu
cenderung kurang mendapat perhatian jika biaya diestimasi melalui perbandingan
dengan proyek sebelumnya. Misalnya, perubahan skala yang sederhana
(otomatisasi perpustakaan lokal dengan 25.000 volume sebagai kebalikan dari
perpustakaan universitas dengan lebih dari 1.000.000 volume), persyaratan kinerja
yang sedikit lebih keras, jadwal yang dipadatkan (yang memerlukan tim yang lebih
besar dan dengan demikian meningkatkan biaya overhead karena komunikasi )
mungkin berdampak signifikan pada upaya yang diperlukan dalam hal man-months.
Penerapan metode perbandingan perkiraan biaya yang ceroboh menyebabkan
perkiraan seperti: biaya proyek ini sama dengan biaya proyek sebelumnya.
Kami juga dapat melibatkan lebih dari satu pakar dalam proses estimasi. Dalam
melakukannya, setiap ahli memberikan perkiraan berdasarkan pengalaman dan
keahliannya sendiri. Faktor-faktor yang sulit diukur, seperti karakteristik kepribadian
dan karakteristik proyek yang khas, dapat diperhitungkan. Di sini juga, kualitas
estimasi tidak bisa melebihi kualitas para ahli. Para ahli yang berpartisipasi dalam
estimasi harus memiliki pengalaman dalam proyek serupa. Itu tidak banyak
membantu untuk meminta saran dari seorang ahli dalam jenis sistem otomatisasi
kantor untuk memberikan perkiraan untuk sistem kontrol lalu lintas udara.
Estimasi menimbulkan ketidakpastian. Perkiraan biaya, katakanlah, 100 bulan
kerja mungkin berarti ada kemungkinan 75% bahwa biaya sebenarnya dari proyek
ini adalah antara 80 dan 120 bulan kerja. Dia bukan estimasi titik. Salah satu
metode yang bertujuan untuk mendapatkan estimasi yang lebih andal adalah
dengan meminta pakar menghasilkan lebih dari satu estimasi. Kita semua memiliki
kecenderungan untuk menganggap perkiraan optimis sebagai realistis. (Pernahkah
Anda mendengar tentang sistem perangkat lunak yang disampaikan sebelumnya?)
Untuk menghindari kecenderungan ini, kita dapat menggunakan teknik di mana
pakar diminta untuk tiga perkiraan:
7.3. DISTRIBUSI TENAGA KERJA SEPANJANG 171
WAKTU
estimasi optimis
A
172
Walston- T
-Felix
7.4. 173
RING
KASA
N
anggota P
lain,
jumlah
link
komunika
si
174 PERKIRAAN
BIAYA
Individu T
Ukuran tim o
t
a
l
produktifitas produ
ktifita
s
1 5 5
0 0
0 0
2 4 9
5 0
0 0
3 4 1
0 2
0 0
0
4 3 1
5 4
0 0
0
5 3 1
0 5
0 0
0
5.5 2 1
7 5
5 1
2
6 2 1
5 5
0 0
0
7 2 1
0 4
0 0
0
8 1 1
5 2
0 0
0
Gambar 7.14 Dampak ukuran tim terhadap

produktivitas
pengganda upaya, kemudian dapat ditentukan. Dalam perjalanan waktu, model

tersebut menjadi lebih dekat dengan lingkungan organisasi, menghasilkan estimasi
yang lebih baik dan lebih baik. Reifer (2000) misalnya menjelaskan bagaimana
COCOMO II dapat diadaptasi untuk memperkirakan proyek pengembangan
perangkat lunak berbasis web.
Meskipun kami menganjurkan penggunaan model estimasi biaya algoritmik,
peringatan harus dibuat. Model masa kini seperti ini belum begitu bagus.
Paling-paling, mereka menghasilkan perkiraan yang paling banyak diskon 25%, 75%
dari waktu, untuk proyek yang digunakan untuk mendapatkan model. Untuk saat ini,
perkiraan biaya berbasis ahli adalah alternatif yang layak. Bahkan ketika
kinerja yang jauh lebih baik direalisasikan, masih ada beberapa masalah ketika
menggunakan jenis model estimasi biaya yang diperoleh dengan cara ini:
�
7.4. RINGKASAN 175
Gambar 7.15 Wilayah yang mustahil (Sumber: B.W. Boehm, Ekonomi Rekayasa
Perangkat Lunak, ara. 27-8/halaman 471, 1981, Dicetak ulang atas izin
Prentice-Hall, Inc., Englewood Cliffs,NJ)
jarang diperhitungkan. Selain itu, faktor-faktor seperti jumlah dokumentasi

yang diperlukan, jumlah perjalanan bisnis (dalam kasus pengembangan
multisite) seringkali kurang. Namun, faktor-faktor ini mungkin memiliki dampak
yang signifikan terhadap upaya yang dibutuhkan.
Model algoritmik biasanya dihasilkan dari penerapan teknik statistik seperti regresi
analisis terhadap sekumpulan data proyek tertentu. Untuk proyek baru, parameter dari
model harus ditentukan, dan model menghasilkan perkiraan dan, dalam beberapa kasus, a
selang kepercayaan.
Masalah yang sifatnya agak berbeda adalah sebagai berikut: Dalam pengantar ini
bab kita membandingkan estimasi biaya perangkat lunak dengan estimasi biaya untuk lay out a
kebun. Saat menata taman, kita sering mengikuti garis pemikiran yang agak berbeda,
yaitu: diberi anggaran, katakanlah, $10.000, kemungkinan apa yang ada? Apa yang terjadi
176 PERKIRAAN BIAYA
jika kita menukar kolam dengan sesuatu yang lain?
Hal serupa juga dimungkinkan dengan perangkat lunak. Dengan anggaran
sebesar $100.000 untuk otomatisasi perpustakaan, kemungkinan apa yang ada?
Antarmuka pengguna mana yang dapat kita harapkan, berapa kecepatan
transaksinya, seberapa andal sistemnya? Untuk dapat menjawab jenis pertanyaan
ini, kita harus dapat menganalisis sensitivitas estimasi terhadap berbagai nilai atribut
yang relevan. Mengingat ketidakpastian tentang atribut mana yang relevan untuk
memulai, masalah trade-off ini sebagian besar masih belum terpecahkan.
Akhirnya, memperkirakan biaya proyek pengembangan perangkat lunak adalah
aktivitas yang sangat dinamis. Kami tidak hanya dapat beralih dari satu model ke
model lainnya selama proyek berlangsung, perkiraan juga akan disesuaikan
berdasarkan pengalaman yang diperoleh. Beralih ke model lain selama pelaksanaan
proyek dimungkinkan, karena kami mungkin berharap untuk mendapatkan data yang
lebih andal saat proyek sedang berjalan. Kita dapat, misalnya, membayangkan
menggunakan rangkaian model COCOMO 2 yang semakin detail.
Kami tidak dapat, dan tidak boleh, mengandalkan perkiraan biaya statistik sekali
pakai. Mengontrol proyek pengembangan perangkat lunak menyiratkan
pemeriksaan kemajuan secara teratur, pemeriksaan perkiraan yang dibuat secara
teratur, menetapkan kembali prioritas dan menimbang taruhan, saat proyek sedang
berlangsung.

Model estimasi biaya awal dijelaskan dalam (Nelson, 1966) dan (Wolverton, 1974).
Model Walston-Felix dijelaskan dalam (Walston dan Felix, 1977). Model Putnam dan
Norden dijelaskan dalam (Norden, 1970), (Putnam, 1978). (Boehm, 1981) adalah
sumber pasti dari model COCOMO asli. COCOMO 2 dijelaskan dalam (Boehm et
al., 1995) dan (Boehm et al., 1997).
Analisis titik fungsi (FPA) dikembangkan oleh Albrecht (Albrecht, 1979; Albrecht
dan Gaffney, 1983). Penilaian kritis FPA dapat ditemukan di (Symons, 1988),
(Kemerer, 1993), (Kemerer dan Porter, 1992), (Abran dan Robillard, 1992) dan
(Abran dan Robillard, 1996). Pembahasan rinci tentang titik fungsi, proses
penghitungannya dan beberapa studi kasus, disediakan oleh (Garmus dan Herron,
1996).
Hubungan antara perilaku proyek dan estimasi biayanya dibahas dalam
(Abdel-Hamid et al., 1993). Pedoman estimasi biaya diberikan dalam (Boehm dan
Sullivan, 1999), (Fairley, 2002) dan (Jørgensen, 2005). (Perangkat Lunak, 2000)
adalah isu khusus yang dikhususkan untuk estimasi perangkat lunak.
Latihan
1. Dengan cara apa argumen politik dapat memengaruhi estimasi

biaya?
2. Seperti apa model Walston-Felix?
3. Bagaimana kurva Rayleigh terkait dengan estimasi biaya perangkat lunak?

4. Berikan sketsa Function Point Analysis (FPA).
5. Berikan sketsa COCOMO 2.
6. Diskusikan perbedaan utama antara COCOMO 2 dan FPA.
7. Berikan alasan untuk Hukum Brooks.
8. Dalam pengertian apa Function Point Analysis (FPA) mencerminkan orientasi batch
dunia tahun 1970-an?
9. Bagaimana perkiraan biaya awal dapat memengaruhi cara proyek

dieksekusi?
10. Mengapa sulit untuk membandingkan berbagai model estimasi biaya?
11. Misalkan Anda terlibat dalam sebuah proyek yang diperkirakan memakan
waktu 100 bulan kerja. Bagaimana Anda memperkirakan waktu kalender
nominal yang diperlukan untuk ini
proyek? Misalkan proyek akan selesai dalam waktu enam bulan kalender. Melakukan
menurut Anda kompresi jadwal seperti itu layak dilakukan?
12. Mengapa model biaya perangkat lunak harus dikalibrasi ulang dari waktu ke waktu?
13. �
8
Perencanaan dan Kontrol
Proyek
TUJUAN PEMBELAJARAN
�
8.1. TINJAUAN SISTEM KONTROL PROYEK 179
Dalam bab ini saya mencoba merekonsiliasi berbagai pendekatan yang diuraikan dalam
bab-bab
3--7. Taksonomi proyek pengembangan perangkat lunak diberikan, bersama dengan
praktik manajemen yang direkomendasikan untuk menangani proyek semacam itu. Itu
bab juga membahas manajemen risiko dan beberapa teknik terkenal untuk
perencanaan dan pengendalian proyek.
Proyek pengembangan perangkat lunak sangat berbeda. Perbedaan-perbedaan ini tercermin dalam
cara di mana proyek-proyek ini diatur dan dikelola. Untuk beberapa proyek,
anggaran tetap dan tujuan proyek adalah untuk memaksimalkan kualitas
produk akhir. Bagi yang lain, kendala kualitas ditetapkan sebelumnya, dan
tujuannya adalah untuk menghasilkan sistem yang efektif yang memenuhi batasan kualitas tersebut. Jika
mengembangkan organisasi memiliki pengalaman yang cukup dengan domain aplikasi
dan persyaratannya tetap dan stabil, pendekatan yang terstruktur dengan ketat dapat menghasilkan
solusi yang memuaskan. Dalam aplikasi dengan persyaratan kabur dan sedikit sebelumnya
pengalaman dalam tim pengembangan, pendekatan yang lebih gesit mungkin diinginkan.
Penting untuk mengidentifikasi karakteristik proyek tersebut sejak dini, karena mereka
akan mempengaruhi cara proyek diatur, direncanakan dan dikendalikan. Di bagian 8.1,
kita akan membahas kontrol proyek dari sudut pandang sistem. Ini memungkinkan kita untuk
mengidentifikasi dimensi utama di mana proyek pengembangan perangkat lunak berbeda.
Dimensi ini mengarah pada taksonomi proyek pengembangan perangkat lunak, yang akan
dibahas di bagian 8.2. Untuk setiap kategori proyek yang dibedakan, kami akan
menunjukkan cara terbaik untuk mengontrol berbagai entitas yang diidentifikasi dalam bab sebelumnya.
Ini
jenis penilaian harus dilakukan pada tahap perencanaan proyek.
Penilaian ini menghubungkan kategori risiko global dengan situasi kontrol pilihan. Sehari-hari
prakteknya, bagaimanapun, adalah lebih kompleks. Proyek aktual menghadapi banyak risiko,
masing-masing
yang harus ditangani secara bergantian. Bahkan risiko yang kami harapkan telah ditemukan
solusi yang memadai, dapat berubah menjadi masalah di kemudian hari. Oleh karena itu, faktor risiko
harus
dipantau, dan rencana darurat harus dikembangkan. Identifikasi awal
risiko dan pengembangan dan pelaksanaan strategi untuk mengurangi risiko ini
dikenal sebagai manajemen risiko. Manajemen risiko dibahas di bagian 8.3.
Proyek pengembangan perangkat lunak terdiri dari sejumlah tugas yang saling terkait. Beberapa
ini harus ditangani secara berurutan (modul tidak dapat diuji sampai selesai
telah diimplementasikan), sementara yang lain dapat ditangani secara paralel (modul yang berbeda bisa
dilaksanakan secara bersamaan). Ketergantungan antar tugas dapat digambarkan dalam
jaringan dari mana jadwal proyek dapat diturunkan. Ini dan alat serupa untuk
perencanaan tingkat mikro dan kontrol proyek pengembangan perangkat lunak dibahas
di bagian 8.4.
8.1 Tampilan Sistem Kontrol

Proyek
Pada bab-bab sebelumnya, kita membahas beberapa entitas yang perlu dikontrol.
Selama pelaksanaan proyek pengembangan perangkat lunak, masing-masing entitas ini membutuhkan
180 PERENCANAAN DAN PENGENDALIAN
PROYEK
untuk dipantau dan dinilai. Dari waktu ke waktu, penyesuaian harus dilakukan.
Untuk dapat melakukannya, kita harus mengetahui entitas mana yang dapat
divariasikan, bagaimana mereka dapat divariasikan, dan apa efek dari penyesuaian
tersebut.
Untuk tujuan ini, kami akan mempertimbangkan kontrol proyek dari sudut
pandang sistem. Kami sekarang menganggap proyek pengembangan perangkat
lunak itu sendiri sebagai suatu sistem. Kontrol proyek kemudian dapat dijelaskan
dalam hal:
– sistem yang akan dikendalikan, yaitu proyek pengembangan

perangkat lunak;
– entitas yang mengontrol sistem, yaitu manajer proyek, organisasinya

dan aturan keputusan yang dia gunakan;
– informasi yang digunakan untuk memandu proses pengambilan keputusan.

Informasi ini dapat berasal dari dua sumber. Itu bisa berasal dari sistem yang
dikendalikan (seperti pemberitahuan masalah teknis dengan komponen tertentu)
atau mungkin memiliki sumber di luar sistem (seperti permintaan untuk
mempersingkat waktu pengembangan).
Variabel-variabel yang berperan dalam pengendalian suatu sistem dapat
dikategorikan ke dalam tiga kelas: variabel tidak teratur, variabel tujuan, dan variabel
kontrol.
Variabel tak beraturan adalah variabel yang merupakan input ke sistem yang
dikendalikan. Variabel tak beraturan tidak dapat divariasikan oleh entitas yang
mengontrol sistem. Nilai mereka ditentukan oleh lingkungan sistem. Contoh variabel
tidak teratur adalah pengalaman komputer pengguna atau tingkat kepegawaian
proyek.
Prasyarat penting untuk pengendalian yang efektif adalah pengetahuan tentang
tujuan proyek. Dalam mengembangkan perangkat lunak, berbagai tujuan yang
saling bertentangan dapat dibedakan. Satu tujuan yang mungkin adalah untuk
meminimalkan waktu pengembangan. Karena waktu sering mendesak, tujuan ini
tidak biasa. Tujuan lain mungkin untuk memaksimalkan efisiensi, yaitu
pembangunan harus dilakukan semurah mungkin. Penggunaan sumber daya yang
optimal (kebanyakan tenaga kerja) kemudian dibutuhkan. Namun tujuan ketiga yang
mungkin adalah untuk memaksimalkan kualitas. Masing-masing tujuan ini mungkin,
tetapi hanya dapat dicapai jika diketahui tujuan mana yang sedang dikejar. Sasaran
ini secara kolektif membentuk serangkaian variabel sasaran.
Akhirnya, proses pengambilan keputusan dipandu oleh seperangkat variabel
kontrol. Variabel kontrol adalah entitas yang dapat dimanipulasi oleh manajer proyek
untuk mencapai tujuan yang ditetapkan. Contoh variabel kontrol yang mungkin
adalah alat yang akan digunakan, organisasi proyek, efisiensi perangkat lunak yang
dihasilkan.
Tidak mungkin untuk membuat pemisahan yang kaku antara berbagai set
variabel. Itu tergantung pada situasi yang dihadapi apakah variabel tertentu harus
diambil sebagai variabel tidak teratur, variabel tujuan, atau variabel kontrol. Jika
persyaratannya stabil dan tetap, misalnya seseorang dapat mencoba
mengendalikan proyek dengan mempekerjakan personel yang memadai dan
menggunakan seperangkat alat yang tepat. Untuk proyek lain, tenaga kerja dapat
diperbaiki dan seseorang dapat mencoba mengendalikan proyek dengan
memperpanjang tanggal pengiriman, melonggarkan batasan kualitas, dll.
Namun, untuk dapat mengontrol sebuah proyek, kumpulan variabel yang
berbeda harus diketahui. Harus diketahui di mana kontrol itu, dan tidak, mungkin. ini
hanya
8.2. TAKSONOMI PROYEK PENGEMBANGAN 181
PERANGKAT LUNAK
satu prasyarat, meskipun. Dalam teori sistem, syarat-syarat berikut berlaku
pengendalian sistem yang digunakan:
– entitas pengendali harus mengetahui tujuan sistem;
– entitas pengendali harus memiliki variasi pengendalian yang memadai;

– entitas pengendali harus memiliki informasi tentang keadaan, masukan dan keluaran
sistem;
– entitas pengendali harus memiliki model pengendalian konseptual. Itu harus

tahu bagaimana dan sejauh mana variabel yang berbeda bergantung dan
mempengaruhi satu sama lain.
Ketika semua kondisi ini terpenuhi, kontrol bisa menjadi rasional, dalam hal ini tidak ada
ketidakpastian, karena entitas pengendali mendapat informasi lengkap tentang setiap hal yang relevan
aspek. Masalah kontrol kemudian dapat disusun dan diformalkan. Praktek sehari-hari dari
pengembangan perangkat lunak berbeda. Tidak ada cukup ruang untuk kontrol atau
pengaruh tindakan pengendalian tidak diketahui. Kontrol kemudian menjadi jauh lebih intuitif
atau primitif. Itu didasarkan pada intuisi, pengalaman, dan aturan praktis.
Sejauh mana proyek pengembangan perangkat lunak dapat dikendalikan meningkat
seiring bertambahnya varietas kontrol. Varietas kontrol ini ditentukan oleh banyaknya
variabel kontrol dan sejauh mana mereka dapat bervariasi. Seperti yang diperhatikan sebelumnya, the
variasi kontrol bergantung pada proyek.
Mengontrol pengembangan perangkat lunak berarti kita harus bisa mengukur keduanya
proyek dan produk. Mengukur suatu proyek berarti kita harus mampu
menilai kemajuan. Mengukur suatu produk berarti kita harus dapat menentukan
sejauh mana persyaratan kualitas dan fungsional terpenuhi.
Mengontrol proyek pengembangan perangkat lunak menyiratkan bahwa tindakan kontrol yang efektif
mungkin. Tindakan korektif mungkin diperlukan jika kemajuan tidak memadai atau
perangkat lunak tidak memenuhi persyaratannya. Kontrol yang efektif berarti bahwa kita
mengetahui apa efek dari tindakan pengendalian. Jika kemajuan tidak mencukupi dan kami memutuskan
untuk
mengalokasikan tenaga ekstra, kita harus memahami dampak dari tenaga ekstra ini
jadwal waktu. Jika kualitas komponen tertentu kurang dari yang dibutuhkan dan kami
memutuskan untuk mengalokasikan waktu ujian ekstra, kita harus tahu berapa banyak waktu ujian yang
diperlukan
rangka mencapai kualitas yang diinginkan.
Dalam praktiknya, mengendalikan proyek pengembangan perangkat lunak bukanlah proses yang
rasional.
Situasi teori sistem ideal tidak terpenuhi. Ada sejumlah ketidakpastian
yang membuat pengelolaan proyek semacam itu menjadi kegiatan yang menantang. Di bawah ini akan
dibahas a
beberapa situasi ideal, berdasarkan ketidakpastian dari berbagai aspek yang relevan.
8.2 Taksonomi Proyek

Lunak
Pada bagian sebelumnya, kami mengidentifikasi beberapa kondisi yang perlu
dipenuhi agar dapat mengendalikan proyek secara rasional. Karena kondisi ini
seringkali tidak terpenuhi, dalam banyak kasus kita harus bergantung pada
mekanisme kontrol yang berbeda. Itu
PROYEK
mekanisme kontrol yang paling cocok untuk situasi tertentu jelas tergantung pada
karakteristik proyek yang relevan.
Berdasarkan analisis karakteristik proyek pengembangan perangkat lunak yang
penting untuk pengendalian proyek, kami akan membedakan beberapa situasi
proyek, dan menunjukkan bagaimana proyek dapat berhasil dikendalikan dalam
situasi ini.
Kami akan mengelompokkan karakteristik proyek menjadi tiga kelas:
karakteristik produk, karakteristik proses, dan karakteristik sumber daya. Dari sudut
pandang kontrol proyek, kami tertarik pada tingkat kepastian dari karakteristik
tersebut. Misalnya, jika kita memiliki persyaratan pengguna yang jelas dan stabil,
kepastian produk tinggi. Jika bagian dari masalah adalah untuk mengidentifikasi
persyaratan pengguna, atau persyaratan pengguna sering berubah selama proyek
pengembangan, kepastian produk rendah.
Jika kepastian produk tinggi, pengendalian bisa sangat rasional, sejauh hal itu
bergantung pada karakteristik produk. Karena kami tahu apa yang seharusnya
dicapai oleh produk, kami dapat memeriksa kepatuhan terhadap persyaratan dan
melakukan tindakan korektif jika diperlukan. Jika kepastian produk rendah, ini tidak
layak. Kami juga tidak tahu apa yang kami tuju, atau targetnya terus bergerak.
Masuk akal untuk berharap bahwa kontrol akan berbeda dalam kasus tersebut.
Untuk diskusi saat ini, kami hanya tertarik pada karakteristik proyek yang
mungkin berbeda antar proyek. Karakteristik umum untuk sebagian besar atau
semua proyek pengembangan perangkat lunak, seperti fakta bahwa mereka
melibatkan kerja tim, tidak akan mengarah pada paradigma kontrol yang berbeda.
Kami selanjutnya akan menggabungkan karakteristik dari masing-masing dari
tiga kategori yang diidentifikasi di atas, menjadi satu metrik, kepastian kategori yang
sesuai. Ini memberi kita tiga dimensi di mana proyek pengembangan perangkat
lunak mungkin berbeda:
�
PERANGKAT LUNAK
sasaran. Demikian pula, jika kita tidak tahu bagaimana melakukan proses pembangunan, kita
juga tidak tahu sumber daya apa yang dibutuhkan.
Ini menyisakan empat situasi pola dasar, seperti yang digambarkan dalam Gambar 8.1. Di bawah,
kami
akan membahas masing-masing situasi kontrol ini pada gilirannya. Dengan demikian, kami akan
memperhatikan
aspek-aspek berikut dari situasi pengendalian tersebut:
– jenis masalah kontrol;
– tujuan utama yang harus ditetapkan dalam mengendalikan proyek;
– mekanisme koordinasi yang akan digunakan;
– strategi pengembangan, atau model proses, yang akan diterapkan;
- cara dan sejauh mana biaya dapat diperkirakan.
Realisasi Alokasi Desain Eksplorasi
Kepastian tinggi tinggi tinggi renda

produk h
Kepastian tinggi tinggi rendah renda
proses h
Kepastian tinggi rendah rendah renda
sumber daya h
Gambar 8.1 Empat situasi kontrol pola dasar
�
PROYEK
Mengenai estimasi biaya, kita mungkin berhasil menggunakan salah satu
model biaya yang lebih formal. Alternatifnya, para ahli di bidang tersebut
dapat memberikan perkiraan yang andal. Perkiraan biaya yang diperoleh
dapat digunakan untuk menjaga kemajuan proyek dan menghasilkan target
yang ingin dicapai.
�
PERANGKAT LUNAK
untuk beralih dari model pengembangan linier ke model bertahap. Preferensi ini
akan meningkat seiring dengan meningkatnya ketidakpastian.
Estimasi biaya harus bergantung pada pengalaman masa lalu. Kami biasanya
tidak memiliki cukup data untuk menggunakan salah satu model estimasi
biaya yang lebih formal. Dalam situasi ini juga, kita memerlukan analisis
sensitivitas. Kebutuhan ini akan lebih mendesak daripada situasi sebelumnya,
karena ketidakpastiannya lebih besar. Manajer proyek akan tertarik pada
kepekaan estimasi biaya terhadap penggerak biaya tertentu. Dia mungkin
tertarik pada pertanyaan seperti: apa yang akan terjadi pada jadwal
pengembangan jika dua analis tambahan ditugaskan untuk proyek ini, atau:
apa pengaruhnya terhadap biaya total jika kita mempersingkat waktu
pengembangan dengan
X
PROYEK
panduan tentang besarnya proyek. Berdasarkan perkiraan ini, upaya dan
waktu dapat dialokasikan untuk proyek tersebut, misalnya untuk
menghasilkan sejumlah prototipe, studi kelayakan, implementasi percontohan
sebagian produk, atau untuk memulai sejumlah kotak waktu tertentu.
Harapannya adalah pada waktunya ketidakpastian akan cukup berkurang
sehingga proyek bergeser ke salah satu situasi lainnya.
Keempat situasi pengendalian yang dibahas di atas sekali lagi digambarkan dalam
Gambar 8.2, bersama dengan karakterisasi singkat dari berbagai aspek
pengendalian yang dibahas di atas. Untuk proyek besar, mungkin efektif untuk
menggunakan mekanisme kontrol yang berbeda pada tingkat makro dan mikro,
masing-masing (Karlström dan Runeson, 2005). Di tingkat makro, manajemen
mungkin harus mengoordinasikan pekerjaan tim yang berbeda, dan melapor ke
manajemen yang lebih tinggi. Ini mungkin memerlukan pendekatan di mana tahapan
eksplisit dan tonggak yang sesuai dibedakan. Namun, pada tingkat subtim kecil,
seseorang mungkin masih menerapkan metode gesit untuk mengontrol pekerjaan
sehari-hari.
Dengan mempertimbangkan berbagai aspek kontrol selama tahap perencanaan
proyek pengembangan perangkat lunak, kita dapat menyesuaikan manajemen
proyek dengan situasi yang dihadapi. Dengan demikian, kami menyadari bahwa
proyek pengembangan perangkat lunak tidak semuanya sama. Mengabaikan
karakteristik khusus proyek tersebut kemungkinan besar akan mengakibatkan
kegagalan proyek, kegagalan yang sering dilaporkan dalam literatur, tetapi sama
seringnya tetap tersembunyi dari publik secara luas.
8.3 Manajemen risiko

Manajemen risiko adalah manajemen proyek untuk orang dewasa
Daftar Tim
Pada bagian sebelumnya, kami mengidentifikasi kategori risiko global dan
mengaitkannya dengan situasi kontrol pilihan. Pada bagian ini, penekanannya
adalah pada risiko individu dan pengelolaannya selama eksekusi projek. Dalam
beberapa hal juga, diskusi di bawah ini mengambil sudut pandang yang lebih
realistis, karena kami juga mempertimbangkan situasi yang merugikan seperti
jadwal yang sangat ketat dan desain pelapisan emas.
Potensi risiko suatu proyek harus diidentifikasi sedini mungkin. Agak naif untuk
menganggap bahwa proyek perangkat lunak akan berjalan lancar dari awal sampai
akhir. Tidak akan. Kita harus mengidentifikasi risiko proyek perangkat lunak sejak
dini dan memberikan langkah-langkah untuk menghadapinya. Melakukan hal itu
bukanlah tanda pesimisme yang tidak beralasan. Sebaliknya, itu adalah tanda
kebijaksanaan.
Dalam pengembangan perangkat lunak, kita cenderung mengabaikan risiko.
Kami mengasumsikan skenario optimis dalam semua keadaan dan kami tidak
mencadangkan dana untuk menghadapi risiko. Kami mengandalkan kepahlawanan
ketika kekacauan terjadi. Jika risiko teridentifikasi sama sekali, tingkat keparahannya
sering diremehkan, terutama oleh pengamat yang lebih tinggi dalam hierarki.
Seorang desainer mungkin telah memperhatikan bahwa subsistem tertentu
menimbulkan masalah kinerja yang serius. Manajernya menganggap bahwa
masalahnya dapat diselesaikan. Manajer manajernya menganggap masalahnya
memiliki telah dipecahkan.
8.3. MANAJEMEN RISIKO 187
Jenis masalah Realisasi Alokasi Desain Eksplorasi
Kepastian produk tinggi tinggi tinggi rendah

Kepastian proses tinggi tinggi rendah rendah
Kepastian sumber daya tinggi rendah rendah rendah
Tujuan utama Optimalkan Akuisisi, Kontrol dari Maksimalkan

terkendali penggunaan pelatihan dari proses hasil
sumber daya
Efisiensi personil Risiko lebih
dan jadwal rendah
Koordinasi, Standardisasi Standardisasi Standardisasi Saling

Pengelolaan produk, produk dan proses pengaturan
gaya proses, dan proses Komitmen
sumber daya Gaya relasi
Hirarki,
gaya pemisahan
Perkembangan Air terjun Air terjun Tambahan Tambahan

strategi Pembuatan
prototipe
Lincah
Model Estimasi ahli
Perkiraan biaya Model Estimasi ahli
Proses penjaga Kepekaan Kepekaan Analisis resiko
analisis analisis Menyediakan
panduan
Gambar 8.2 Empat situasi kontrol (Sesudah: F.J. Heemstra, Berapa biaya perangkat lunak,
Administrasi Bisnis Kluwer, 1989.)
Risiko adalah kemungkinan peristiwa negatif di masa depan yang dapat

memengaruhi keberhasilan suatu usaha. Jadi, risiko belum menjadi masalah. Ini
mungkin menjadi satu, dan manajemen risiko menjadi perhatian mencegah risiko
menjadi masalah. Beberapa contoh umum dari risiko dan cara untuk
menghadapinya, adalah:
�
PROYEK
�
8.3. MANAJEMEN RISIKO 189
Mempertaruhkan Keterangan
Kekurangan Dapat memanifestasikan dirinya

personel dalam berbagai cara, seperti
sebagai pengalaman dengan
domain, alat atau
teknik pengembangan yang akan
digunakan, orang-
pergantian nel, kehilangan
anggota tim yang kritis,
Jadwal/anggaran yang tidak atau hanya ukuran tim.
realistis
Perkiraan mungkin tidak realistis
sehubungan dengan
persyaratan.
Fungsi salah Mungkin memiliki berbagai
penyebab, seperti an
pemahaman yang tidak
sempurna tentang pelanggan
kebutuhan, kompleksitas
komunikasi
dengan klien, pengetahuan
domain yang tidak memadai
Antarmuka tepi pengembang dan
pengguna yang desainer.
salah
Dalam situasi tertentu,
keramahan pengguna dari
antarmuka sangat penting
untuk keberhasilannya.
Pelapisan emas
Pengembang mungkin ingin
mengembangkan fitur 'bagus'
barang yang tidak diminta oleh
pelanggan.
Persyaratan volatilitas
Jika banyak persyaratan berubah
selama pengembangan
op, jumlah pengerjaan ulang
meningkat.
Komponen eksternal
yang buruk Kualitas atau fungsionalitas
eksternal
komponen yang disediakan
mungkin di bawah apa
diperlukan untuk proyek ini.
Tugas eksternal
yang buruk Subkontraktor dapat memberikan
produk yang tidak memadai
ucts, atau keterampilan yang
diperoleh dari luar
tim mungkin tidak memadai.
Kekurangan waktu
nyata Kinerja real-time dari (bagian
dari) tersebut
sistem mungkin tidak
memadai.
Kekurangan
kemampuan Lingkungan yang tidak stabil atau
baru atau belum dicoba
teknologi menimbulkan risiko
bagi pembangunan
jadwal.
Gambar 8.3 Sepuluh faktor risiko teratas
�
PROYEK
�
8.4. TEKNIK UNTUK PERENCANAAN DAN PENGENDALIAN 191
PROYEK
8.4 Teknik Perencanaan

dan Pengendalian
Proyek
Sebuah proyek terdiri dari serangkaian kegiatan. Kami dapat secara grafis
menggambarkan proyek dan kegiatan konstituennya dengan a struktur rincian
kerja (WBS). WBS mencerminkan penguraian proyek menjadi subtugas hingga ke
tingkat yang diperlukan untuk perencanaan dan pengendalian yang efektif. Gambar
8.3 berisi contoh yang sangat sederhana dari struktur perincian kerja untuk proyek
pengembangan perangkat lunak. Aktivitas yang digambarkan pada struktur rincian
kerja sesuai dengan tugas unit, sedangkan node tingkat yang lebih tinggi
merupakan tugas gabungan. Kami akan berasumsi bahwa setiap aktivitas memiliki
awal dan akhir yang terdefinisi dengan baik yang ditunjukkan oleh tonggak sejarah,
acara terjadwal di mana seseorang bertanggung jawab dan yang digunakan untuk
mengukur dan mengontrol kemajuan. Akhir dari suatu aktivitas sering kali
merupakan penyampaian, seperti dokumen desain, sedangkan awal suatu aktivitas
sering kali dipicu oleh akhir beberapa aktivitas lainnya.
Proyek
Desain Renc Kode

pengu
Kode B
Gambar 8.5 Struktur perincian kerja sederhana untuk proyek pengembangan perangkat lunak
Aktivitas biasanya menghabiskan sumber daya, seperti orang atau waktu komputer,
dan selalu memiliki durasi tertentu. Kegiatan harus sering dijalankan dalam urutan
tertentu. Misalnya, kita tidak dapat menguji modul sebelum dikodekan. Jenis
hubungan antara tugas dapat dinyatakan sebagai kendala. Biasanya, kendala
menyangkut hubungan temporal antara kegiatan. Kendala semacam itu juga disebut
hubungan prioritas. Perencanaan proyek melibatkan penjadwalan semua kegiatan
sehingga kendala terpenuhi dan batas sumber daya tidak terlampaui. Beberapa
teknik tersedia untuk mendukung tugas penjadwalan ini.
PROYEK
Kegiatan dari WBS sederhana dari proyek pengembangan perangkat lunak,
bersama-sama dengan durasi dan kendala temporal, diberikan pada Gambar 8.6.
Perhatikan bahwa gambar 8.6 berisi lebih banyak informasi tentang hubungan
temporal daripada yang diberikan dalam WBS. Meskipun pembacaan WBS dari kiri
ke kanan menyarankan urutan waktu tertentu, itu tidak memberikan hubungan
prioritas yang tepat antara aktivitas.
Aktivitas Durasi K
e
n
d
a
l
a
Desain 10 -
-
Rencana pengujian 5 De
sai
n
sel
esa
i
Kode A 10 De
sai
n
sel
esa
i
Kode B 5 De
sai
n
sel
esa
i
Tes 10 Kode selesai,
Rencana pengujian
selesai
Gambar 8.6 Kegiatan, durasi dan batasan waktu
Himpunan aktivitas dan batasannya juga dapat digambarkan dalam sebuah jaringan.
Sebagai contoh, jaringan ini diberikan pada Gambar 8.7. Node dalam jaringan
menunjukkan aktivitas. Jenis jaringan ini oleh karena itu dikenal sebagai jaringan
'aktivitas-on-node'. Setiap node juga membawa bobot, durasi aktivitas yang sesuai.
Panah dari simpul A ke simpul B menunjukkan bahwa aktivitas A harus diselesaikan
sebelum aktivitas B dapat dimulai.
Diagram jaringan ini sering disebut grafik PERT. PERT adalah singkatan dari
Program Evaluation and Review Technique. Bagan PERT dikembangkan dan pertama
kali berhasil digunakan dalam pengelolaan program misil Polaris pada tahun 1950-an.
Sementara teknik PERT asli hanya berkaitan dengan rentang waktu aktivitas dan
keterkaitannya, perkembangan selanjutnya telah menghasilkan berbagai teknik yang
mengakomodasi semakin banyak faktor proyek.
Dari grafik PERT kita dapat menghitung titik waktu paling awal di mana proyek dapat
diselesaikan. Mari kita asumsikan bahwa jaringan memiliki simpul awal B dan simpul
akhir E yang unik. Jika ada lebih dari satu simpul dengan derajat 0 (yaitu tidak memiliki
pendahulu dalam jaringan), simpul awal baru B dibuat dengan tepi keluar ke semua
simpul yang memiliki in-degree 0. Node baru B ini mendapat bobot nol (durasi).
Prosedur serupa diikuti untuk membuat simpul akhir E jika ada lebih dari satu simpul
yang memiliki derajat di luar 0.
Kami selanjutnya memberi label pada setiap node
Saya
8.4. TEKNIK UNTUK PERENCANAAN DAN PENGENDALIAN 193
PROYEK
Rencana uji 5
Desain 10 Kode A 10
Kode B5
Gambar 8.7 Contoh grafik PERT
2. Untuk semua simpul tak berlabel yang semua pendahulunya adalah simpul berlabel, paling
awal
waktu mulai yang mungkin adalah waktu selesai paling akhir dari semua node sebelumnya:
S
8.4. TEKNIK UNTUK PERENCANAAN DAN 195
PENGENDALIAN PROYEK
Rencana pengujian
5
Desain Kode Tes

A
10 1 10
0
Kode B
5
Gambar 8.9 Jaringan aktivitas-pada-panah
kegiatan A telah dimulai. Kami juga dapat memperluas teknik sehingga menangani sumber daya
kendala. Misalnya, jika kita hanya memiliki satu programmer yang tersedia, bagan Gantt
Gambar 8.6 tidak akan berfungsi, karena diasumsikan bahwa pengkodean modul A dan B telah selesai
secara paralel. Teknik PERT bahkan dapat diperluas lebih jauh untuk memungkinkan kepekaan
analisis. Dengan mengizinkan apa yang disebut pertanyaan 'bagaimana-jika' ('bagaimana jika kita
mengalokasikan tiga desainer
daripada empat ',' bagaimana jika modul pengkodean A memakan waktu dua bulan daripada satu ') kami
merasakan kepekaan jadwal terhadap variasi tertentu dalam tingkat sumber daya,
jadwal overruns, dan sejenisnya.
Metode Jalur Kritis -- CPM -- adalah, seperti namanya, teknik yang sangat mirip
untuk PERT dan dikembangkan di sekitar waktu yang sama.
Dalam diskusi kami, kami menyajikan bagan Gantt sebagai visualisasi grafis dari a
jadwal yang dihasilkan dari analisis jaringan. Sebenarnya, kita dapat menggunakan Gantt chart sebagai
a
mekanisme penjadwalan dengan sendirinya. Kami mungkin hanya mendaftar semua kegiatan dan
menunjukkan
waktu mulai paling awal dan waktu berakhir paling akhir di kalender. Bagan Gantt oleh
sendiri, bagaimanapun, tidak membawa informasi tentang ketergantungan antar aktivitas.
Hal ini membuat sulit untuk menyesuaikan jadwal, misalnya saat ada aktivitas tertentu yang meleset.
Sejauh
seiring berjalannya perencanaan, oleh karena itu kami lebih memilih penggunaan bagan Gantt sebagai
sarana untuk memvisualisasikan
hasil analisis jaringan.
Menggunakan informasi yang terdapat dalam bagan Gantt dan pengetahuan personel
sumber daya yang diperlukan untuk setiap aktivitas, kami dapat menetapkan rencana personel yang
menunjukkan caranya
banyak orang yang dibutuhkan dalam setiap satuan waktu. Karena biaya orang adalah bagian utama
pengeluaran proyek, rencana personalia ini menyediakan sarana langsung untuk merencanakan proyek
pengeluaran.
Ketika proyek sedang berjalan, kontrolnya didasarkan pada pemantauan proyek
kemajuan dan pengeluaran. Waktu yang dihabiskan per kegiatan per anggota proyek bisa
dicatat pada kartu waktu. Kartu waktu ini adalah dasar untuk menentukan kumulatif
usaha dan pengeluaran. Data kumulatif ini dapat dibandingkan dengan yang direncanakan
tingkat usaha dan pengeluaran. Untuk benar menilai apakah proyek tersebut masih
di jalur, manajemen membutuhkan informasi kemajuan juga. Cara paling umum untuk
asalkan ini melalui laporan tonggak: kegiatan tidak dapat dianggap selesai sampai
PROYEK
laporan yang tepat telah diproduksi dan diterima.
Bagan Gantt menyediakan sarana yang sangat langsung untuk membandingkan
status proyek aktual dengan jadwal proyek. Slippage jadwal segera muncul dengan
sendirinya. Slippage aktivitas pada jalur kritis memerlukan tindakan manajemen
yang cepat: negosiasi ulang jadwal, penyampaian proyek, atau keduanya.
Perhatikan bahwa selip jadwal adalah urusan yang licik; proyek tertinggal satu hari
pada suatu waktu. Perhatikan juga bahwa jadwal proyek harus mencerminkan
proyek yang sebenarnya. Perubahan yang diterima memerlukan pertimbangan
ulang jadwal.
8.5 Ringkasan
Dalam bab ini kita melihat kontrol proyek dari sudut pandang sistem dan
memperoleh wawasan tentang bagaimana berbagai jenis proyek dapat dikelola dan
dikendalikan. Kami mengidentifikasi empat situasi pola dasar, yang menuntut model
proses, mekanisme koordinasi, dan gaya manajemen yang berbeda.
Proyek nyata menghadapi banyak risiko, dan manajer proyek yang bijaklah yang
memperhatikannya sejak dini. Risiko adalah kemungkinan peristiwa negatif di masa
depan yang dapat memengaruhi kesuksesan. Ini belum menjadi masalah, tetapi
mungkin menjadi masalah. Manajemen risiko berkaitan denganmencegah risiko
menjadi masalah. Ini melibatkan langkah-langkah berikut:
1. Identifikasi faktor risiko.
2. Menentukan eksposur risiko, yaitu kemungkinan terjadinya suatu risiko,

dikalikan dengan biayanya.
3. Mengembangkan strategi untuk memitigasi risiko, terutama yang memiliki

paparan risiko tinggi. Risiko dapat dihindari (misalnya dengan mempekerjakan
lebih banyak orang), dialihkan (misalnya dengan memilih strategi pengembangan
yang berbeda), atau diterima.
4. Tangani risiko: pantau faktor risiko dan ambil tindakan bila diperlukan.
Di bagian 8.4, kami berfokus pada perencanaan dan pengendalian aktivitas dalam
proyek. Dengan menggambarkan serangkaian aktivitas dan hubungan temporalnya
dalam grafik, teknik seperti PERT menawarkan cara yang sederhana namun kuat
untuk menjadwalkan dan mengontrol aktivitas ini (lihat, misalnya, (Boehm, 1981)).

Beberapa sumber manajemen proyek perangkat lunak umum adalah: (Boehm,
1981), (Brooks, 1995), (Humphrey, 1997b) dan (Royce, 1998). Highsmith (2004)
berfokus pada manajemen proyek tangkas, sementara Boehm dan Turner (2003)
dan Karlström dan Runeson (2005) membahas bagaimana menggabungkan
pendekatan tangkas dan berbasis rencana.
Pembahasan di bagian 8.2 didasarkan pada (Heemstra, 1989).
(Boehm, 1989) memberikan gambaran yang baik tentang manajemen risiko
perangkat lunak. Pengalaman manajemen risiko dilaporkan dalam (Software,
1997a). Kategori risiko yang dibahas pada bagian 8.3 berasal dari (Wallace dan
Keil, 2004). Pfleeger (2000) membandingkan perangkat lunak manajemen risiko
dengan manajemen risiko dalam disiplin lain.
Latihan
1. Buat daftar kondisi untuk pengendalian sistem yang efektif.
2. Apakah pendekatan air terjun cocok untuk masalah tipe realisasi? Jika demikian, mengapa?
3. Apakah pendekatan air terjun cocok untuk masalah tipe eksplorasi? Jika demikian, mengapa?
4. Apa itu manajemen risiko?
5. Bagaimana risiko dapat dikurangi?
6. Ulangi pemicu biaya dari model estimasi biaya COCOMO sebagai risiko
faktor.
7. Apa yang dimaksud dengan struktur rincian kerja?
8. Apa itu grafik PERT?
9. Apa itu bagan Gantt?
10. �
PROYEK
dia pekerjaan ini karena dia melakukan dengan sangat baik. Diskusikan kemungkinan
tindakan
untuk mencegah karyawan tersebut meninggalkan organisasi.
15. ~
Bagian II
Siklus Hidup Perangkat
Lunak
ISI
Bab 9 Rekayasa Persyaratan 199
Bab 10Pemodelan 246
Bab 11Arsitektur Perangkat Lunak 276
Bab 12Desain perangkat lunak 313
Bab 13Pengujian Perangkat Lunak 394
Bab ?? Pemeliharaan Perangkat Lunak 453
Bab ?? Alat Perangkat Lunak 494
Saat mendesain taman, Anda mulai dengan merumuskan persyaratan Anda -

seberapa besar area rumput seharusnya, haruskah Anda meninggalkan sudut untuk
menanam kentang, di mana tempat sampah harus diletakkan, apakah persyaratan
tersebut tidak mengganggu pekerjaan pemeliharaan di masa mendatang. rumah (!),
dll. Setelah itu, dibuat desain yang didokumentasikan dengan cermat dalam cetak
biru. Hanya dengan begitu tukang kebun akan memotong tanah pertama.
Pendekatan serupa diikuti saat mengembangkan perangkat lunak. Dalam sejumlah
fase -- rekayasa kebutuhan, desain, implementasi, pengujian -- sistem perangkat
lunak akan terbentuk. Setelah perangkat lunak dikirimkan ke klien, perangkat lunak
tersebut harus dipelihara. Pengulangan fase terjadi karena perubahan harus
digabungkan dan kesalahan harus diperbaiki. Hasilnya adalah proses yang sangat
bersiklus, yang disebut siklus hidup perangkat lunak. Berbagai fase dari siklus
pengembangan awal adalah topik dari bab9--13, dan bab 14 dikhususkan untuk
pemeliharaan perangkat lunak. Dalam setiap fase, teknik pemodelan digunakan
untuk merepresentasikan hasil dari fase tersebut. Contoh terkenal
200
teknik pemodelan dibahas dalam bab 10. Dalam setiap fase juga, alat digunakan.
Kelas utama alat dan perannya dalam proses pengembangan perangkat lunak
dibahas dalam bab 15.
9
Rekayasa Persyaratan
TUJUAN PEMBELAJARAN
�
202 TEKNIK PERSYARATAN
Bab ini mencakup rekayasa persyaratan, fase utama pertama dalam a

proyek pengembangan perangkat lunak. Aspek yang paling menantang dan
sulit dari
Rekayasa kebutuhan adalah untuk mendapatkan gambaran lengkap dari
masalah
untuk dipecahkan. Kami membahas sejumlah teknik untuk memunculkan
persyaratan
dari pengguna. Setelah elisitasi, persyaratan ini harus dinegosiasikan,
divalidasi, dan didokumentasikan.
Bagian tersulit dalam membangun sistem adalah memutuskan

apa yang akan dibangun
(Brooks, 1987)
Fase rekayasa persyaratan adalah langkah besar pertama menuju solusi dari
masalah pemrosesan data. Selama fase ini, persyaratan pengguna sehubungan
dengan sistem masa depan diidentifikasi dan didokumentasikan dengan hati-hati.
Persyaratan ini menyangkut baik fungsi yang akan disediakan maupun sejumlah
persyaratan tambahan, seperti yang menyangkut kinerja, keandalan, dokumentasi
pengguna, pelatihan pengguna, biaya, dan sebagainya. Selama fase rekayasa
persyaratan, kami belum menjawab pertanyaan tentang Bagaimana untuk mencapai
persyaratan pengguna ini dalam hal komponen sistem dan interaksinya. Ini ditunda
sampai tahap desain.
Persyaratan adalah 'kondisi atau kemampuan yang dibutuhkan oleh pengguna
untuk memecahkan masalah atau mencapai tujuan' (IEEE610, 1990). 'Pengguna'
yang disinggung dalam definisi ini mungkin merupakan pengguna akhir sistem,
seseorang di belakang layar. Namun, ini juga dapat menunjukkan beberapa kelas
pengguna tidak langsung, seperti orang yang tidak memutar kenop sendiri
melainkan menggunakan informasi yang diberikan sistem. Ini juga dapat
menunjukkan klien (pelanggan) yang membayar tagihan. Selama rekayasa
persyaratan, tipe pengguna yang berbeda mungkin menjadi sumber dari tipe
persyaratan yang berbeda. Mudah-mudahan, pengguna akhir akan menjadi sumber
informasi utama mengenai persyaratan fungsional terkait tugas. Persyaratan lain,
mis. yang terkait dengan masalah keamanan, mungkin juga diungkapkan oleh
pemangku kepentingan lainnya.
Kata 'persyaratan' menunjukkan bahwa, sekali dinyatakan, itu memiliki untuk
bertemu. Pada kenyataannya, ini hampir tidak pernah terjadi. Sebagian besar
persyaratan dapat dinegosiasikan. Waktu ke pasar, biaya, persyaratan kualitas yang
bertentangan, dan kebutuhan pemangku kepentingan yang bertentangan semuanya
mengarah pada situasi di mana pengorbanan mungkin harus dilakukan.
Hasil dari tahap rekayasa persyaratan didokumentasikan dalam spesifikasi
kebutuhan. Spesifikasi kebutuhan mencerminkan saling pengertian dari masalah
yang harus dipecahkan antara analis dan klien. Ini adalah dasar untuk kontrak, baik
formal maupun informal, antara klien sistem dan organisasi pengembangan. Pada
akhirnya, sistem yang dikirimkan akan dinilai dengan menguji kesesuaiannya
dengan spesifikasi kebutuhan.
Spesifikasi kebutuhan berfungsi sebagai titik awal untuk fase berikutnya, fase
desain. Pada tahap desain arsitektur sistem dirancang dalam hal komponen sistem
dan interface antara komponen tersebut. Fase desain juga menghasilkan
spesifikasi: deskripsi yang tepat -- sebaiknya dalam beberapa bahasa formal -- dari
arsitektur desain, komponennya, dan antarmukanya.
203
Gagasan 'spesifikasi' dengan demikian memiliki beberapa arti. Untuk mencegah kebingungan, kami
akan selalu menggunakan awalan 'persyaratan' jika itu menunjukkan hasil dari persyaratan
fase rekayasa.
Lebih buruk lagi, fase di mana persyaratan pengguna dianalisis
dan didokumentasikan juga terkadang disebut spesifikasi. Kami merasa ini agak
dari nama yang salah dan tidak akan menggunakan istilah seperti itu.
Kami menggunakan istilah rekayasa persyaratan daripada pengertian yang lebih sempit tentang
Analisa Kebutuhan untuk menekankan bahwa ini adalah proses yang iteratif dan kooperatif
menganalisis masalah, mendokumentasikan pengamatan yang dihasilkan, dan memeriksa
ketepatan pemahaman yang didapat. Rekayasa kebutuhan tidak hanya melibatkan
masalah teknis tentang bagaimana merepresentasikan persyaratan. Aspek sosial dan kognitif
memainkan peran dominan juga.
Persyaratan rekayasa dan desain umumnya tidak dapat dipisahkan secara ketat
waktu. Dalam beberapa kasus, spesifikasi kebutuhan sangat formal dan dapat dilihat
sebagai spesifikasi desain tingkat tinggi dari sistem yang akan dibangun. Seringkali, pendahuluan
desain dilakukan setelah serangkaian persyaratan awal telah ditentukan. Berdasarkan
hasil dari upaya desain ini, spesifikasi kebutuhan dapat diubah dan
Dihilangkan. Jenis iterasi ini juga terjadi ketika teknik pembuatan prototipe sedang dilakukan
digunakan. Dalam proyek pengembangan tangkas murni, persyaratan muncul bersamaan dengan
sistem up-and-running. Teknik terkenal seperti diagram aliran data dan UML
diagram kelas digunakan untuk menyusun dan mendokumentasikan kedua spesifikasi kebutuhan
dan desain.
Hanya untuk kemudahan presentasi persyaratan rekayasa dan desain
fase dipisahkan secara ketat dan diperlakukan secara berurutan dalam buku ini.
Selama rekayasa persyaratan, sejumlah hal yang sangat berbeda sedang dilakukan
ditujukan. Mari kita lihat sebuah contoh dan pertimbangkan kasus (hipotetis) dari a
perpustakaan universitas mengotomatiskan operasinya. Kami akan mulai dengan perpustakaan yang
berisi
sejumlah lemari. Lemari ini menyimpan banyak sekali kartu, satu per buku.
Setiap kartu berisi nama penulis, judul buku, ISBN, tahun terbit,
dan data berguna lainnya. Kartu diurutkan berdasarkan abjad dengan nama yang pertama
penulis setiap buku.
Sistem pemesanan ini sebenarnya menghadirkan masalah besar karena hanya berfungsi dengan
baik jika kita
tahu nama penulis pertama. Jika kita hanya tahu judulnya, atau jika kita tertarik dengan buku
pada topik tertentu, katalog penulis sedikit atau tidak membantu.
Solusi perangkat lunak tampak jelas. Jika kita menyimpan data untuk setiap buku satu kali dalam a
database, kami selanjutnya dapat mengurutkan entri dengan berbagai cara. Sesuai
alat dapat memungkinkan pengguna untuk mencari database secara interaktif. Dengan menyediakan
internet
akses ke database, layanan dapat sangat ditingkatkan.
Selama fase rekayasa persyaratan, sejumlah persyaratan pengguna akan
dinaikkan. Beberapa dari persyaratan tersebut akan menyangkut memperbarui database, yaitu
menambah, menghapus dan mengubah record. Orang lain akan memperhatikan fungsi yang akan
disediakan
kepada anggota biasa perpustakaan, seperti:
– Berikan daftar semua buku yang ditulis oleh X;
– Berikan daftar semua buku yang judulnya mengandung Y;
– Berikan daftar semua buku tentang topik Z;
– Berikan daftar semua buku yang datang setelah tanggal D.
Adalah bijaksana untuk mencoba mengelompokkan persyaratan pengguna ke

dalam beberapa kategori, mulai dari 'persyaratan penting' hingga 'fitur bagus'.
Seperti disebutkan dalam Bab 3, pengguna cenderung mengalami kesulitan dalam
mengartikulasikan kebutuhan mereka yang sebenarnya. Maka, kemungkinannya
adalah bahwa banyak upaya dihabiskan untuk mewujudkan fitur-fitur yang kemudian
berubah menjadi lonceng dan peluit belaka. Dengan menggunakan skema berlapis
baik dalam perumusan kebutuhan pengguna dan realisasi selanjutnya, beberapa
masalah yang menimpa proyek pengembangan perangkat lunak dapat dielakkan.
Dalam contoh sistem perpustakaan kami, misalnya, persyaratan 'Berikan daftar
semua buku yang tiba setelah tanggal D' dapat diklasifikasikan sebagai fitur yang
bagus. Layanan tidak mengalami penurunan serius jika fungsi ini tidak tersedia,
karena kami mungkin sementara menempatkan akuisisi di rak khusus.
Dimungkinkan juga untuk mencoba memprediksi sejumlah persyaratan di masa
mendatang, yang tidak akan diterapkan dalam proyek saat ini. Namun, masuk akal
untuk memperhatikan hal-hal ini pada tahap awal, sehingga dapat diakomodasi
selama perancangan sistem. Kemungkinan persyaratan sistem perpustakaan kami
di masa mendatang dapat mencakup hal-hal seperti:
– Menyimpan informasi tentang buku yang sudah dipesan tetapi belum

diterima;
– Menyimpan informasi tentang anggota perpustakaan, seperti nama dan alamat

mereka, dan tanggal peminjaman buku kepada mereka, yang kemudian dapat
digunakan untuk menghasilkan pemberitahuan pengingat untuk buku yang tidak
dikembalikan tepat waktu.
Fungsi di atas menyangkut penggunaan perangkat lunak oleh anggota

perpustakaan dan petugas perpustakaan. Namun, ada pemangku kepentingan lain
juga. Misalnya, manajemen perpustakaan mungkin ingin menggunakan sistem untuk
mendapatkan informasi tentang profil anggota untuk meningkatkan proses akuisisi
judul.
Selain persyaratan ini, yang secara langsung berkaitan dengan fungsi perangkat
lunak yang akan dikirimkan, sejumlah hal lain harus ditangani selama fase rekayasa
persyaratan. Untuk contoh perpustakaan kami, minimal, poin-poin berikut harus
diperhatikan:
�
205
kelas pengguna? Anggota perpustakaan normal mungkin tidak akan diizinkan untuk
memperbarui
database atau mencetak isi database.
�
�
9.1. PEMERIKSAAN PERSYARATAN 207
�
Spesifikasi
Pendatangan Dokumentasi & Validasi

Pengelolaan
Perundingan
Gambar 9.1 Kerangka kerja untuk proses rekayasa persyaratan

(diadaptasi dari
(Sommerville, 2005))
Gambar 9.2 Bagian pertama dari siklus hidup

perangkat lunak
Dalam contoh perpustakaan kami, kami dapat dengan mudah mengabaikan fakta bahwa dalam
sebuah angka
Dalam beberapa kasus, nama penulis seperti yang tertera di sampul buku bukan 'kanonik'
nama penulis. Fenomena ini terjadi khususnya dengan penulis dari negara-negara itu
menggunakan skrip non-Latin. Transkripsi nama Rusia 4EXOB berbunyi 'Chekhov'
dalam bahasa Inggris dan 'Tsjechow' dalam bahasa Belanda. Dalam kasus seperti itu, pustakawan ingin
memasukkan
nama penulis dua kali: sekali nama dieja seperti yang tertera di buku, dan sekali
nama dieja seperti yang digunakan dalam berbagai proses pencarian. Sebuah jawaban atas sebuah
pertanyaan
seperti 'buku Chekhov mana yang dimiliki perpustakaan kita?' juga harus memberi tahu kita
judul non-Inggris.
Ketidakcocokan halus antara gagasan analis tentang istilah dan konsep dan mereka
makna yang tepat dalam domain yang dimodelkan dapat memiliki efek mendalam. Seperti
ketidakcocokan paling mudah terjadi di domain yang sudah kita 'ketahui', seperti perpustakaan. Sebuah
menerangi diskusi tentang masalah potensial dalam (secara formal) menentukan persyaratan
dari sistem perpustakaan dapat ditemukan di (Wing, 1988). Masalah yang dicatat antara lain:
�
cara lengkap. Itu harus dikomunikasikan kepada orang yang pada umumnya
memiliki latar belakang yang agak berbeda. Analis seringkali tidak memiliki
pengetahuan yang cukup mendalam tentang domain aplikasi di mana masalah
tersebut berasal. Dia harus mempelajari bahasa domain aplikasi dan mengenal
terminologi, konsep, dan prosedurnya. Terutama dalam proyek-proyek besar,
pengetahuan aplikasi cenderung tersebar di antara para spesialis yang terlibat, yang
dengan mudah menyebabkan kesulitan integrasi dan koordinasi.
Dalam contoh kita sebelumnya, pustakawanlah yang harus mengungkapkan
keinginannya. Ada kemungkinan pencantuman dua nama penulis ('Tsjechow' dan
'Chekhov') dipandang sebagai detail yang jelas yang tidak perlu dikemukakan
secara eksplisit. Analis di sisi lain meja mungkin masih mendapat kesan bahwa dia
memiliki gambaran lengkap tentang sistem. Jenis kelalaian ini mungkin memiliki
konsekuensi yang parah.
Beberapa tahun yang lalu sistem pertahanan udara otomatis yang
besar sedang dikembangkan di AS. Selama salah satu pengujian akhir
sistem ini, sinyal alarm dikeluarkan. Salah satu komputer mendeteksi
rudal yang tidak dikenal. Ternyata itu adalah bulan. Kemungkinan ini
belum terpikirkan.
Mendapatkan informasi yang benar dan lengkap merupakan prasyarat penting untuk
sukses. Hal ini ternyata agak bermasalah dalam praktiknya. Menanyakan kepada
calon pengguna apa yang diinginkan biasanya tidak berhasil. Seringkali kita
mendapatkan gambaran situasi yang agak tidak lengkap dan tidak akurat. Alasan
penting untuk ini adalah keterbatasan manusia untuk memproses informasi, memilih
informasi, dan memecahkan masalah. Kemampuan manusia yang terbatas ini
diperparah oleh faktor-faktor seperti:
– kompleksitas dan variasi persyaratan yang dapat dikenakan perangkat
lunak;
– perbedaan latar belakang antara klien, atau pengguna, dan perangkat lunak
spesialis.
Dalam penelitian tentang pemrosesan informasi manusia sering menggunakan
model di mana memori manusia terdiri dari dua komponen: memori jangka pendek
di mana informasi sedang diproses, dan memori jangka panjang di mana
pengetahuan permanen disimpan. Memori jangka pendek memiliki kapasitas
terbatas: sering dikatakan memiliki sekitar tujuh slot. Memori jangka panjang di sisi
lain memiliki kapasitas yang sangat besar.
Jadi, informasi diproses dalam bagian memori manusia yang relatif kecil. Memori
jangka panjang diakses dengan cara tidak langsung. Selain itu, manusia juga
menggunakan ingatan eksternal ketika informasi sedang diproses: papan tulis,
selembar kertas, dll.
Jika seseorang yang diwawancarai selama rekayasa persyaratan hanya
menggunakan memori jangka pendeknya, keterbatasannya dapat berdampak pada
hasil. Hal ini dapat dengan mudah terjadi jika memori eksternal tidak digunakan.
Banyak hal bisa dilupakan, hanya karena ingatan jangka pendek kita memiliki
kapasitas yang terbatas.
Manusia juga cenderung berprasangka buruk dalam memilih dan menggunakan
informasi. Kita, khususnya, cenderung membiarkan peristiwa terkini berlaku. Dalam
membuat persyaratan
spesifikasi, ini mengarah pada persyaratan yang sesuai dengan situasi saat ini, saat ini
informasi yang tersedia, peristiwa terkini, dll.
Manusia tidak terlalu mampu berpikir rasional. Mereka akan menyederhanakan banyak hal dan
menggunakan model yang tidak sesuai dengan kenyataan. Keterbatasan lain yang mempengaruhi kami
model realitas ditentukan oleh faktor-faktor seperti pendidikan, prasangka, praktik, dll.
Jenis penyederhanaan yang sama ini terjadi ketika persyaratan perangkat lunak disusun.
Dan hasilnya akan dibatasi oleh faktor yang sama.
Kami tidak selalu dapat mengharapkan pengguna untuk dapat secara tepat menyatakan
kebutuhannya di
tahap awal. Salah satu alasan untuk menyelidiki peluang otomatisasi sering kali
karena ketidakpuasan tertentu dengan situasi saat ini. Seseorang tidak puas dengan
situasi saat ini dan memiliki kesan bahwa otomatisasi akan membantu. Apakah ini
benar atau tidak -- banyak masalah pemrosesan data adalah masalah organisasi -- secara sederhana
mengotomatiskan situasi saat ini tidak selalu menjadi solusi. Sesuatu yang berbeda adalah
diinginkan, meskipun tidak jelas apa. Hanya ketika wawasan tentang kemungkinan
otomatisasi diperoleh, akankah persyaratan nyata muncul dengan sendirinya. Ini adalah salah satu dari
alasan untuk besarnya masalah pemeliharaan. Sekitar setengah dari pemeliharaan
upaya menyangkut penyesuaian perangkat lunak dengan persyaratan (baru) pengguna. Untuk
menangkal
tren ini, model proses pengembangan perangkat lunak yang mengakui pembelajaran ini
proses, seperti pembuatan prototipe, pengembangan inkremental, dan metode gesit harus dilakukan
disukai daripada yang tidak, yaitu model air terjun dan variannya.
Melalui analisis yang cermat, kami berharap dapat membangun perspektif pengguna yang baik
persyaratan dan mengantisipasi perubahan di masa depan. Namun, tidak peduli berapa banyak waktu
dihabiskan dalam dialog dengan calon pengguna, perubahan di masa depan tetap sulit diramalkan.
Kami
bahkan mungkin melangkah lebih jauh dan menetapkan bahwa persyaratan akan tidak pernah menjadi
lengkap. Di dalam
dalam hal ini, menentukan persyaratan memiliki banyak kesamaan dengan prakiraan cuaca:
ada batas seberapa jauh masa depan dapat diprediksi.
Dalam situasi di mana tujuan proyek pengembangan perangkat lunak adalah untuk meningkatkan
'sistem' yang ada, baik itu proses manual atau (sebagian) otomatis, umumnya
membantu untuk secara eksplisit membedakan dua langkah pemodelan. Pada langkah pertama, arus
situasi dimodelkan. Berdasarkan analisis kekuatan dan kelemahan dari
situasi saat ini, situasi-to-be selanjutnya dimodelkan. Desain Ulang Proses Bisnis, di
khususnya, menekankan perbedaan antara dua langkah pemodelan ini.
Agar tahap rekayasa persyaratan berhasil, kita memerlukan metode dan
teknik yang mencoba melewati kesulitan yang digambarkan di atas. Sejauh mana
teknik yang kuat diperlukan tergantung pada pengalaman orang-orang yang terlibat di dalamnya
fase rekayasa persyaratan (baik pengguna dan analis) dan keahlian dari
analis dengan domain aplikasi. Bagian 9.1.2 membahas sejumlah teknik
untuk elisitasi persyaratan.
Namun sebelum kita membahas teknik-teknik tersebut, terlebih dahulu kita uraikan di bagian 9.1.1
bagaimana caranya
pandangan dunia yang berbeda menghasilkan pendekatan yang berbeda untuk rekayasa kebutuhan.
Di bagian 9.1.3 kita membahas bagaimana persyaratan terkait dengan sasaran tingkat yang lebih tinggi,
dan
bagaimana sudut pandang yang berbeda dapat menghasilkan kumpulan yang berbeda, dan terkadang
saling bertentangan
persyaratan. Mengikuti bagian 9.1.3 kita membahas bagaimana memprioritaskan persyaratan, dan
bagaimana persyaratan berhubungan dengan pemilihan komponen COTS.
9.1.1 Paradigma Rekayasa Kebutuhan

Sebagian besar metode rekayasa kebutuhan, dan metode pengembangan perangkat
lunak secara umum, bersifat Taylorian. Sekitar pergantian abad ini, Taylor
memperkenalkan gagasan 'manajemen ilmiah', di mana tugas secara rekursif
diuraikan menjadi tugas yang lebih sederhana dan setiap tugas memiliki satu 'cara
terbaik' untuk menyelesaikannya. Dengan observasi dan eksperimen yang cermat,
satu cara terbaik ini dapat ditemukan dan diformalkan ke dalam prosedur dan aturan.
Manajemen ilmiah telah berhasil diterapkan di banyak operasi pabrik. Setara dengan
rekayasa persyaratan adalah mewawancarai pakar domain dan mengamati
pengguna akhir di tempat kerja untuk mendapatkan persyaratan pengguna 'nyata'.
Setelah ini, para ahli mulai bekerja dan menerapkan persyaratan ini. Selama proses
terakhir tidak perlu lagi berinteraksi dengan komunitas pengguna. Pandangan
pengembangan perangkat lunak ini adalah pandangan yang fungsional dan rasional.
Asumsi dasarnya adalah bahwa ada satu kebenaran objektif, yang hanya perlu
ditemukan selama proses analisis.
Padahal pandangan ini memiliki kelebihan dalam menyusun kebutuhan secara
murni teknisalam, banyak kepentingan UoD melibatkan orang juga - orang yang
model dunianya tidak lengkap, subyektif, irasional, dan mungkin bertentangan
dengan pandangan dunia orang lain. Dalam kasus seperti itu, analis bukanlah
pengamat luar yang pasif dari UoD. Sebaliknya, ia aktif berpartisipasi dalam
membentuk dari UoD.
Semakin diakui bahwa pendekatan Taylorian, fungsional, bukan satu-satunya,
dan tidak perlu menjadi pendekatan yang paling tepat untuk proses rekayasa
kebutuhan.
Analis memiliki seperangkat asumsi tentang sifat subjek studi. Serangkaian
asumsi seperti itu biasanya disebut 'paradigma'. Di bidang kami, asumsi ini
menyangkut cara analis memperoleh pengetahuan (asumsi epistemologis) dan
pandangan mereka tentang dunia sosial dan teknis (asumsi ontologis).
Asumsi tentang pengetahuan menghasilkan dimensi objektivis-subjektivis. Jika
analis mengambil sudut pandang objektivis, ia menerapkan model dan metode yang
berasal dari ilmu alam untuk sampai pada satu-satunya kebenaran. Dalam posisi
subjektivis, perhatian utamanya adalah untuk memahami bagaimana individu
menciptakan, memodifikasi, dan menginterpretasikan dunia tempat dia berada.
Asumsi tentang dunia menghasilkan dimensi ketertiban-konflik. Sudut pandang
tatanan menekankan keteraturan, stabilitas, integrasi, dan konsensus. Di sisi lain,
pandangan konflik menekankan pada perubahan, konflik, dan disintegrasi.
Dua dimensi ini dan posisi ekstrem terkaitnya menghasilkan empat paradigma
untuk rekayasa kebutuhan dan, secara lebih umum, pengembangan sistem
informasi:
Fungsionalisme (tujuan--urutan). Dalam paradigma fungsionalis, pengembang

adalah pakar sistem yang mencari hubungan sebab-akibat yang terukur. Realitas
organisasi empiris diyakini ada, independen dari pengamat. Sistem dikembangkan
untuk mendukung operasi organisasi yang rasional. Efektivitas mereka dan
efisiensi dapat diuji secara objektif, dengan tes yang serupa dengan yang digunakan dalam rekayasa
lainnya
disiplin ilmu.
Sosial-relativisme (subjektif--urutan). Dalam paradigma ini, analis beroperasi
sebagai fasilitator. Realitas bukanlah sesuatu yang tidak dapat diubah 'di luar sana',
tetapi dibangun di dalam pikiran manusia. Analis adalah agen perubahan. Dia
berusaha memfasilitasi pembelajaran semua orang yang terlibat.
Radikal-strukturalisme (objektif--konflik). Dalam paradigma radikal asumsi
kuncinya adalah bahwa pengembangan sistem campur tangan dalam konflik antara
dua atau lebih kelas sosial untuk kekuasaan, prestise, dan sumber daya. Sistem
sering dikembangkan untuk mendukung kepentingan pemilik, dengan
mengorbankan kepentingan tenaga kerja. Untuk memulihkan keseimbangan
kekuatan, paradigma ini menunjukkan bahwa analis harus bertindak sebagai
partisan buruh. Persyaratan sistem harus berkembang dari kerjasama antara tenaga
kerja dan analis. Pendekatan ini dianggap mengarah pada sistem yang
meningkatkan keahlian dan kondisi kerja.
Neohumanisme (subyektif--konflik). Tema sentral dalam paradigma ini adalah
emansipasi. Sistem dikembangkan untuk menghilangkan pengaruh distorsi dan
hambatan lain untuk wacana rasional. Pengembang sistem bertindak sebagai
terapis sosial dalam upaya untuk menyatukan, dalam diskusi terbuka, kelompok
individu yang beragam, termasuk pelanggan, tenaga kerja, dan berbagai tingkat
manajemen.
Diakui, paradigma ini mencerminkan orientasi ekstrim. Dalam praktiknya, beberapa campuran
asumsi biasanya akan memandu proses rekayasa kebutuhan. Namun itu adil untuk
mengatakan bahwa mayoritas teknik pengembangan sistem menekankan fungsionalis
melihat.
Dalam dimensi subjektivis-objektivis, penting untuk menyadari bahwa suatu kebaikan
kesepakatan subjektivisme mungkin terlibat dalam pembentukan UoD. Jika kita harus
mengembangkan sistem untuk, katakanlah, mengendalikan mesin fotokopi, kita dapat dengan aman
menggunakan fungsional
berdiri. Kita mungkin berharap mesin seperti itu beroperasi secara rasional murni. Dalam analisis
proses, kami mencantumkan fungsi mesin, sinyal internalnya, kondisi, dan sebagainya
untuk mendapatkan gambaran yang memuaskan tentang sistem yang akan dikembangkan. Setelah ini
persyaratan diidentifikasi, mereka dapat dibekukan dan beberapa model proses seperti air terjun
dapat digunakan untuk merealisasikan sistem.
Namun, jika tugas kita adalah mengembangkan sistem untuk mendukung orang dalam melakukan
pekerjaan mereka
pekerjaan, seperti beberapa sistem otomasi kantor, pandangan dunia yang murni fungsional
dapat dengan mudah mengarah pada sistem yang disalahpahami. Dalam kasus tersebut, partisipasi
pengguna akhir dalam
membentuk UoD adalah sangat penting. Melalui dialog terbuka dengan
orang yang bersangkutan, kami dapat mendorong calon pengguna untuk mempengaruhi sistem
untuk dikembangkan. Bagian dari tugas analis dalam hal ini adalah mendamaikan pandangan
peserta dalam proses analisis. Umpan balik terus menerus selama aktual
fase konstruksi dengan kemungkinan pengalihan dapat semakin meningkatkan peluang
kesuksesan. Ini adalah pengguna masa depan yang akan bekerja dengan sistem. Itu tidak
memanfaatkan untuk menghadapi mereka dengan sistem yang tidak memenuhi kebutuhan mereka.
Otomasi mengubah organisasi, dan dengan demikian memengaruhi karyawan

organisasi. Ini dapat menimbulkan ketakutan dan emosi lain dengan karyawan yang
terpengaruh. Misalnya, sistem perpustakaan kami berpotensi memberi orang akses
ke lebih banyak informasi daripada sebelumnya. Namun beberapa orang mungkin
lebih suka memiliki akses hanya ke informasi yang berkaitan dengan tugas dan
tanggung jawab mereka. Selama rekayasa persyaratan, kita harus menyadari efek
ini. Paradigma fungsionalis murni kemudian tidak ada gunanya.
Pengguna yang tidak puas akan mencoba untuk mengabaikan sistem atau,
paling banter, mengungkapkan persyaratan tambahan dengan segera. Hasil
bersihnya adalah keuntungan yang diharapkan dalam efisiensi atau efektivitas tidak
tercapai.
Contoh yang mencerahkan dan terdokumentasi dengan baik tentang
kemungkinan efek dari mengikuti paradigma yang cukup radikal diberikan dalam
(Page et al., 1993); lihat juga bagian 1.4.3.Sistem tersebut berkaitan dengan Sistem
Pengiriman Berbantuan Komputer untuk Layanan Ambulans London. Meskipun
sistem tersebut akan berdampak signifikan terhadap cara kru ambulans melakukan
pekerjaan mereka, hanya ada sedikit konsultasi dengan mereka. Beberapa
konsekuensi dari pendekatan ini adalah sebagai berikut (Page et al., 1993, pp
40--41):
– Sistem mengalokasikan sumber daya terdekat yang tersedia terlepas dari

stasiun asal, sehingga kru sering kali harus beroperasi lebih jauh dan lebih jauh
dari pangkalan mereka.
– Sistem baru menghilangkan fleksibilitas yang sebelumnya dimiliki kru stasiun

untuk memutuskan sumber daya mana yang akan dialokasikan. Hal ini pasti
menimbulkan masalah ketika sumber daya yang berbeda digunakan dengan
yang dialokasikan.
– Kurangnya kontak suara membuat keseluruhan proses lebih impersonal dan

memperburuk situasi 'mereka dan kita'.
Jika model konseptual peserta berbeda, kita dapat mencari kompromi, atau memilih
salah satu pandangan yang diungkapkan. Tidak mungkin untuk memberikan
pedoman umum tentang bagaimana menangani kasus-kasus seperti itu. Mencari
kompromi bisa menjadi urusan yang membosankan dan dapat mengarah pada
sistem yang tidak disukai siapa pun. Memilih satu pandangan tertentu tentang dunia
akan membuat satu pihak senang, tetapi dapat mengakibatkan pihak lain sama
sekali mengabaikan sistem yang dikembangkan. Lebih buruk lagi, mereka mungkin
memutuskan untuk mengembangkan sistem persaingan.
9.1.2 Teknik Elisitasi Persyaratan

Dua sumber informasi utama untuk proses elisitasi persyaratan adalah pengguna
dan domain (aplikasi). Sumber-sumber ini mengandaikan bahwa ada sesuatu 'di
luar sana' untuk memulai, dan dari mana persyaratan dapat diperoleh. Namun,
dalam pengembangan perangkat lunak yang digerakkan oleh pasar, hal ini sering
tidak terjadi, dan elisitasi persyaratan dalam proyek semacam itu lebih seperti
penemuan persyaratan atau perumusan masalah, dipandu oleh pertimbangan
pemasaran dan penjualan.
Gambar 9.3 mencantumkan sejumlah teknik elisitasi, yang dijabarkan lebih lanjut
di bawah. Angka tersebut juga memberi tahu kita bahwa pengguna adalah sumber utama informasi
dalam beberapa teknik, sementara domain dominan pada yang lain. Selanjutnya,
angka menunjukkan apakah setiap teknik sangat berguna untuk memodelkan arus, seperti
bertentangan dengan masa depan yang diantisipasi, situasi.
Biasanya Anda harus menyedot karpet dalam dua arah, bukan satu arah; juga,
Anda harus menggunakan beberapa teknik elisitasi persyaratan.
Gambar 9.3 Contoh teknik elisitasi kebutuhan
Meminta Kami mungkin hanya bertanya kepada pengguna apa yang mereka harapkan dari sistem.
Sebuah pra-
posisinya kemudian adalah bahwa pengguna dapat melewati batasan dan prasangkanya sendiri.
Bertanya dapat berupa wawancara, curah pendapat, atau kuesioner. Dalam sebuah
wawancara terbuka, pengguna dengan bebas berbicara tentang tugasnya. Ini adalah bentuk yang paling
mudah
persyaratan elisitasi, tetapi menderita dari semua kekurangan yang disebutkan sebelumnya.
Dalam wawancara terstruktur, analis mencoba mengatasinya dengan mengarahkan pengguna, untuk
misalnya melalui pertanyaan tertutup atau menyelidik.
Dalam sesi diskusi dengan sekelompok pengguna, kami sering menemukan beberapa pengguna
jauh lebih artikulatif daripada yang lain, dan dengan demikian memiliki pengaruh yang lebih besar pada
hasilnya.
Konsensus yang dicapai dengan demikian tidak perlu seimbang. Untuk mengatasi masalah tersebut, a
Teknik Delphi dapat digunakan. Teknik Delphi adalah teknik iteratif
di mana informasi dipertukarkan dalam bentuk tertulis sampai konsensus tercapai.
Misalnya, peserta dapat menuliskan kebutuhannya, diurutkan berdasarkan urutannya
pentingnya. Set persyaratan yang diperoleh didistribusikan ke semua peserta,
yang merefleksikannya untuk mendapatkan serangkaian persyaratan yang telah

direvisi. Prosedur ini diulang beberapa kali sampai konsensus yang cukup tercapai.
Untuk produk konsumen, seperti paket pengolah kata, perangkat lunak antivirus,
atau perangkat lunak untuk administrasi pribadi Anda, pengguna sering kali memiliki
pilihan untuk memberikan masukan, mengajukan pertanyaan, melaporkan bug, dan
sejenisnya, secara elektronik. Jenis informasi ini juga dikumpulkan dan disimpan
secara teratur oleh staf penjualan dan pemasaran selama kontak mereka dengan
pelanggan. Log ini dapat ditambang dan dengan cara ini memberikan sumber
informasi yang berharga saat mencari persyaratan untuk rilis berikutnya dari
perangkat lunak tersebut.
Analisis tugas Karyawan yang bekerja di beberapa domain melakukan sejumlah
tugas, seperti menangani permintaan untuk meminjam buku, membuat katalog buku
baru, memesan buku, dll. Tugas tingkat tinggi dapat didekomposisi menjadi
subtugas. Misalnya, tugas 'permintaan penangan untuk meminjam buku' dapat
mengarah ke subtugas berikut:
– periksa identitas anggota,
– periksa batas jumlah buku yang boleh dipinjam,
– Mendaftarkan buku yang dipinjam oleh anggota perpustakaan,
– mengeluarkan slip yang menunjukkan tanggal jatuh tempo.
Analisis tugas adalah teknik untuk mendapatkan hierarki tugas dan subtugas yang
harus dilakukan oleh orang yang bekerja di domain tersebut. Salah satu teknik lain
yang dibahas dapat digunakan untuk mendapatkan informasi yang diperlukan untuk
menggambar hierarki ini. Tidak ada aturan yang jelas tentang kapan harus
menghentikan tugas yang membusuk. Heuristik utama adalah bahwa pada
beberapa titik pengguna cenderung 'menolak' untuk menguraikan tugas lebih jauh.
Misalnya, ketika ditanya bagaimana identifikasi anggota diperiksa, petugas
perpustakaan mungkin mengatakan 'Baiklah, saya periksa saja identitasnya.' Pada
titik ini, dekomposisi lebih lanjut tidak ada artinya.
Analisis tugas sering diterapkan pada tahap ketika (detail tentang) komponen
interaksi manusia-komputer diputuskan. Ini meremehkan potensinya sebagai teknik
elisitasi persyaratan umum. Ini juga memberikan kesan (salah) bahwa pengguna
hanya mementingkan 'tampilan dan nuansa' antarmuka.
Analisis berbasis skenario Alih-alih mencari rencana umum seperti dalam
wawancara atau analisis tugas, analis dapat belajar contoh tugas. Skenario adalah
cerita yang memberi tahu kita bagaimana contoh tugas tertentu dijalankan. Skenario
bisa nyata atau buatan. Contoh skenario nyata adalah analis mengamati bagaimana
pegawai perpustakaan menangani permintaan pengguna yang sebenarnya. Kami
dapat meminta pegawai perpustakaan untuk mengungkapkan secara lisan apa yang
dia lakukan dan membuat rekaman audio atau videonya. Ini berpikir keras metode
adalah teknik yang cukup tidak mencolok untuk mempelajari orang di tempat kerja.
Ini sering digunakan untuk menilai prototipe atau sistem informasi yang ada.
Alternatifnya, kami dapat membuat skenario buatan dan mendiskusikannya
dengan pengguna. Sebagai langkah pertama, kami dapat, misalnya, membuat
skenario berikut untuk mengembalikan buku:
1. Tanggal jatuh tempo buku diperiksa. Jika buku terlambat, anggota
diminta untuk membayar denda yang sesuai.
2. Buku dicatat sebagai kembali layak untuk check-out.
3. Buku diletakkan kembali pada tempatnya yang semestinya.

Saat skenario ini didiskusikan dengan pegawai perpustakaan, sejumlah masalah
terkait mungkin muncul, baik melalui pertanyaan menyelidik dari analis, atau karena
pengguna mengontraskan skenario dengan praktik sehari-hari. Contoh pertanyaan
yang dapat diajukan mencakup hal-hal seperti:
– Apa yang terjadi jika orang yang mengembalikan buku bukan anggota terdaftar
dari perpustakaan?
– Apa yang terjadi jika buku yang dikembalikan rusak?
– Apa yang terjadi jika anggota yang mengembalikan buku ini memiliki buku lain yang ada
terlambat atau reservasi luar biasa untuk buku lain?
Intinya, jenis penceritaan ini memberi pengguna versi mock-up buatan

perangkat lunak yang akhirnya akan dikirimkan. Ini berfungsi sebagai prototipe berbasis kertas untuk
mendapatkan pemahaman yang lebih baik tentang persyaratan. Jika dikaitkan dengan pemodelan tipe
UML,
analisis berbasis skenario sering disebut analisis kasus penggunaan; lihat bagian 10.3.6. Skenario
dan kasus penggunaan adalah metode elisitasi yang paling sering digunakan.
Analisis berbasis skenario sering dilakukan dengan cara yang agak serampangan. Dalam hal itu,
tidak ada cara untuk mengetahui apakah cukup banyak skenario yang telah disusun dan a
diperoleh gambaran persyaratan yang cukup akurat dan lengkap. Menulis
skenario yang baik sama sekali tidak mudah. Meskipun mungkin terlihat sepele untuk 'hanya merekam
pengguna
episode ', diperlukan keahlian domain yang adil untuk mendapatkan rangkaian yang baik dan andal
skenario.
Skenario dapat dilihat dari berbagai perspektif. Dalam contoh di atas
skenario pengembalian buku, skenario mencantumkan serangkaian tindakan atau peristiwa yang
bersama membuat beberapa episode. Fokusnya kemudian adalah pada aspek proses, menunjukkan
bagaimana sistem berjalan melalui keadaan-keadaan yang berurutan. Atau, skenario yang sama
dapat dilihat dari perspektif pengguna: bagaimana pengguna berinteraksi dengan sistem,
fungsi apa yang akan dia tawarkan? Perspektif lain adalah skenarionya
mengarah ke diskusi tentang alternatif dari mana pilihan tertentu harus dibuat, seperti
dalam pertanyaan yang dimunculkan oleh contoh skenario di atas.
Etnografi Kerugian utama dari memunculkan persyaratan melalui, misalnya,
wawancara adalah bahwa analis memaksakan pandangannya tentang bagaimana
dunia diatur kepada pengguna. Metode tersebut mungkin gagal jika analis dan
pengguna tidak berbagi sistem kategori. Analis dapat, misalnya, menanyakan hal
berikut:
‘Jika anggota ingin meminjam buku sementara dia masih memiliki tunggakan denda, akan
Anda:
a) Menolak permintaan, atau
b) Tetap tangani permintaan’
Pilihan biner ini tidak perlu memetakan praktik yang sebenarnya. Pegawai
perpustakaan dapat, misalnya, mengabulkan permintaan asalkan bagian dari denda
yang belum dibayar diselesaikan atau jika dia mengetahui bahwa anggota tersebut
dapat dipercaya.
Protokol berpikir keras didasarkan pada gagasan bahwa pengguna memiliki
tujuan dan subtujuan yang terdefinisi dengan baik, dan bahwa mereka melintasi
pohon tujuan tersebut dengan cara top-down yang rapi. Namun orang-orang sering
tidak memiliki rencana yang telah terbentuk sebelumnya, melainkan melanjutkan
dengan cara yang agak oportunistik.
Kerugian dari analisis tugas adalah menganggap tugas individu dari individu,
tanpa memperhitungkan lingkungan sosial dan organisasi di mana tugas-tugas ini
dilaksanakan.
Metode etnografi diklaim tidak memiliki kekurangan seperti itu. Dalam etnog-rafi,
sekelompok orang dipelajari dalam latar alamiahnya. Ini terkenal dari sosiologi, di
mana misalnya suku-suku Polinesia dipelajari dengan tinggal bersama mereka
untuk jangka waktu yang lama. Demikian pula, persyaratan pengguna dapat
dipelajari dengan berpartisipasi dalam pekerjaan sehari-hari mereka untuk jangka
waktu tertentu, misalnya dengan menjadi pegawai perpustakaan. Analis magang,
mengakui bahwa pengguna sistem di masa depan adalah ahli nyata dalam
pekerjaan mereka. Metode etnografi lebih mungkin mengungkap pengetahuan
diam-diam daripada kebanyakan teknik elisitasi lainnya.
Analisis bentuk Banyak informasi tentang domain yang dimodelkan seringkali
dapat ditemukan dalam berbagai bentuk yang digunakan. Misalnya, untuk meminta
beberapa prosiding konferensi dari perpustakaan lain, pengguna mungkin harus
mengisi formulir seperti yang diberikan pada gambar 9.4.
Gambar 9.4 Contoh formulir

Formulir memberi kami informasi tentang objek data domain, mereka

sifat, dan keterkaitannya. Mereka sangat berguna sebagai masukan untuk pemodelan
aspek data dari sistem; lihat juga bagian 10.1.1.
Pengguna perpustakaan seringkali memiliki pengetahuan yang tidak lengkap tentang sumber
informasi yang mereka miliki
tertarik. Misalnya, seseorang mungkin mencari proses dari
itu Konferensi Internasional tentang Rekayasa Perangkat Lunak yang terjadi di Berlin. Hanya jika
berbagai entri dari formulir di atas digunakan sebagai entitas dalam model data pokok,
pertanyaan seperti itu dapat dijawab dengan mudah. Dalam hal ini, formulir langsung menunjuk pada
yang bermanfaat
persyaratan yang mungkin tidak diperhatikan.
Deskripsi bahasa alami Seperti formulir, deskripsi bahasa alami memberikan
banyak informasi berguna tentang domain yang akan dimodelkan. Petunjuk
pengoperasian untuk pegawai perpustakaan misalnya dapat berisi paragraf seperti
yang diberikan pada Gambar 9.5. Teks ini memberi kita informasi seperti:
– Ada (setidaknya) dua akun yang dapat ditagih pesanan;
– Ada daftar anggota staf yang berwenang untuk menandatangani permintaan tersebut;
– Ada kemungkinan memesan banyak salinan judul, seperti buku ini

pada Rekayasa Perangkat Lunak, atas nama mahasiswa.
Akuisisi judul
Sebelum permintaan untuk memperoleh gelar dapat dipenuhi, formulir B harus diisi
dengan tidak lengkap. Permintaan tidak dapat ditangani jika tidak ditandatangani
oleh anggota staf yang berwenang atau akun yang akan diisi ('Siswa' atau 'Staf')
tidak disebutkan. Permintaan tidak akan dikabulkan jika judul yang diminta sudah
ada dalam katalog judul, kecuali ditandai 'Dicuri' atau 'Hilang', atau akunnya adalah
'Siswa'.
Gambar 9.5 Contoh instruksi untuk pegawai perpustakaan
Seringkali, deskripsi (dan formulir) bahasa alami memberikan latar belakang kepada analis
informasi yang akan digunakan bersama dengan teknik elisitasi lainnya seperti
wawancara. Deskripsi bahasa alami khususnya cenderung menganggap banyak diam-diam
pengetahuan oleh pembaca. Misalnya, jika formulir B berisi ISBN, ini akan menyimpan
pegawai perpustakaan beberapa pekerjaan, tetapi permintaan mungkin masih akan ditangani jika ini
informasi tidak disediakan. Masalah praktis dengan deskripsi bahasa alami
adalah bahwa mereka sering tidak diperbarui. Seperti dokumentasi perangkat lunak, validitasnya
cenderung memburuk seiring berjalannya waktu.
Deskripsi bahasa alami sering diambil sebagai titik awal dalam berorientasi objek
teknik analisis. Ini dibahas lebih lanjut di bagian 12.3.
Turunan dari sistem yang ada Mulai dari sistem yang sudah ada, misalnya sistem
serupa di beberapa organisasi lain atau deskripsi dalam buku teks, kami dapat
merumuskan persyaratan sistem baru. Jelas, kita harus berhati-hati dan
mempertimbangkan keadaan khusus dari situasi saat ini.
Daripada melihat satu sistem tertentu, kita juga dapat mempelajari sejumlah
sistem dalam beberapa domain aplikasi. Proses analisis persyaratan meta ini dikenal
sebagai analisis domain. Tujuannya umumnya adalah untuk mengidentifikasi
komponen, konsep, struktur, dan sejenisnya yang dapat digunakan kembali.
Berbahaya untuk mencari persyaratan yang dapat digunakan kembali di domain yang
belum matang. Persyaratan kemudian dapat digunakan kembali hanya karena
tersedia, bukan karena sesuai dengan situasi yang dihadapi. Mereka menjadi 'kayu
mati'. Dalam konteks analisis kebutuhan, analisis domain dapat dilihat sebagai teknik
untuk menurunkan model 'referensi' untuk sistem dalam domain tertentu. Model
referensi semacam itu menyediakan kerangka (arsitektur) yang dapat ditambah dan
diadaptasi agar sesuai dengan situasi spesifik yang dihadapi.
Analisis domain dibahas lebih lanjut dalam bab ??, dalam konteks penggunaan
kembali perangkat lunak dan pengembangan lini produk perangkat lunak.
Desain Ulang Proses Bisnis (BPR). Dalam banyak proyek pengembangan

perangkat lunak, orang-orang yang terlibat langsung mengambil kesimpulan:
otomatisasi adalah jawabannya. Lebih buruk lagi, kesimpulan mereka mungkin
bahwa mengotomatisasi situasi saat ini adalah jawabannya. Dalam Perancangan
Ulang Proses Bisnis (atau Rekayasa Ulang Proses Bisnis), diikuti strategi yang agak
berbeda. Ini adalah aktivitas organisasi untuk mendesain ulang proses bisnis secara
radikal untuk mencapai terobosan kompetitif, mis. kualitas, biaya, atau kepuasan
pengguna. Di BPR, kami berangkat sepenuhnya dari cara-cara yang ada dalam
melakukan sesuatu. Di BPR, langkah-langkah berikut dibedakan:
1. Identifikasi proses inovasi. Dua pendekatan utama untuk melakukannya

adalah pendekatan yang lengkap dan berdampak tinggi. Dalam pendekatan
lengkap, upaya dilakukan untuk mengidentifikasi semua proses, yang kemudian
diprioritaskan untuk mendesain ulang urgensinya. Pendekatan berdampak tinggi
mencoba mengidentifikasi proses yang paling penting saja, atau proses yang
bertentangan dengan visi bisnis.
2. Identifikasi tuas perubahan. Pada langkah ini, peluang memfasilitasi

peningkatan proses diidentifikasi. Tiga jenis pengungkit dapat dikenali: pengaktif
organisasi (seperti memberdayakan tim), pengaktif sumber daya manusia
(seperti pengayaan tugas), dan pengaktif teknologi informasi.
3. Mengembangkan visi proses. Agar desain ulang berhasil, organisasi perlu

mengetahui tujuan mana yang ingin dicapai. Ini dijelaskan dalam visi proses.
Komponen utama dari visi proses adalah: tujuan proses (target terukur dari
kinerja sistem di masa depan), atribut proses (properti kualitatif dan deskriptif dari
proses masa depan), faktor penentu keberhasilan dan kendala (organisasi,
budaya , dan teknologi).
4. Memahami proses yang ada. Ini termasuk mendokumentasikan proses yang
ada, mengukurnya, dan mengidentifikasi aspek-aspek bermasalah. Ini
memungkinkan kita menilai kesehatan proses yang ada, dan membawa masalah
ke permukaan.
5. Desain dan prototipe proses baru. Ini adalah langkah terakhir. Pembuatan prototipe
mungkin untuk mencoba struktur baru, sehingga mengurangi risiko kegagalan.
BPR sebenarnya bukan teknik elisitasi kebutuhan yang tepat. Disebutkan di sini
karena menekankan masalah penting untuk ditangani selama persyaratan
fase rekayasa. Proses bisnis tidak boleh didorong oleh teknologi informasi
ogy. Sebaliknya, teknologi informasi harus memungkinkan mereka. Padahal BPR lengkap
upaya tidak diperlukan atau layak dalam banyak situasi, memikirkan kembali proses yang ada
dan prosedur adalah langkah yang terlalu sering dilewati tanpa berpikir dalam perangkat lunak
proyek pengembangan.
Sebagai contoh, pertimbangkan proyek otomasi perpustakaan kami sekali lagi. Hati-hati
pemeriksaan situasi saat ini mungkin mengungkapkan bahwa semuanya tidak terlalu buruk.
Namun, kesannya adalah jumlah permintaan yang tidak bisa dikabulkan
terus meningkat dalam beberapa tahun terakhir. Hal ini ditengarai sebagai penyebab utama kenaikan
tersebut
jumlah pengguna yang tidak puas. Karena pelayanan kepada pelanggannya memiliki prioritas tinggi,
salah satunya
tujuannya adalah untuk mengurangi jumlah permintaan yang tidak dapat dipenuhi sebesar 50%
dalam waktu dua tahun. Untuk ini menjadi mungkin, perpustakaan harus diperbolehkan untuk
menghabiskan
anggaran yang tersedia atas kebijakannya sendiri, bukannya dipicu oleh sinyal dari
peneliti saja (ini terdengar radikal, bukan). Oleh karena itu diputuskan untuk menambah
sistem otomatis yang ada dengan modul untuk melacak keberhasilan dan
permintaan yang gagal. Berdasarkan wawasan yang diperoleh dari proses pengukuran ini
dalam jangka waktu tiga bulan akan diambil keputusan berapa besar persentasenya
anggaran tahunan akan dialokasikan kembali.
Pembuatan prototipe Mengingat fakta bahwa sulit, jika bukan tidak mungkin, untuk
membangun sistem yang benar dari awal, kita dapat memutuskan untuk
menggunakan prototipe. Mulai dari persyaratan pertama, prototipe sistem dibangun.
Prototipe ini digunakan untuk percobaan, yang mengarah pada persyaratan baru
dan lebih banyak wawasan tentang kemungkinan penggunaan sistem. Dalam satu
atau lebih langkah berikutnya, serangkaian persyaratan yang lebih pasti
dikembangkan. Pembuatan prototipe dibahas di bagian 3.2.1. Proses tangkas
lainnya mengikuti strategi serupa di mana persyaratan dengan cepat diterjemahkan
ke dalam sistem yang berjalan untuk dinilai oleh penggunanya.
Dari teknik-teknik elisitasi persyaratan ini, bertanya adalah strategi yang paling tidak
pasti, sedangkan pembuatan prototipe adalah yang paling tidak pasti. Selain
pengalaman baik pengguna maupun analis, ketidakpastian proses juga dipengaruhi
oleh stabilitas lingkungan, kompleksitas produk yang akan dikembangkan dan
keakraban dengan bidang masalah yang dimaksud. Kami dapat mencoba
memperkirakan dampak dari faktor-faktor tersebut pada kerentanan dari spesifikasi
persyaratan yang dihasilkan, dan kemudian memutuskan metode utama tertentu
untuk memperoleh persyaratan berdasarkan perkiraan ini.
Untuk masalah yang dipahami dengan baik, dengan analis yang sangat
berpengalaman, mewawancarai calon pengguna mungkin cukup. Namun, jika
menyangkut masalah lanjutan dan kurang dipahami dari dalam lingkungan yang
berubah dengan cepat dan analis memiliki sedikit atau tidak ada pengalaman dalam
domain tersebut, tampaknya bijaksana untuk mengikuti proses yang gesit.
Ketidakpastian persyaratan bukanlah satu-satunya masalah yang harus dihadapi
manajer proyek, dan proses yang berbeda bukanlah satu-satunya solusi yang
mereka pilih. Aspek politik (seperti agenda tersembunyi dan konflik antar pemangku
kepentingan) seringkali dipandang sebagai risiko yang lebih besar daripada sekadar
ketidakpastian persyaratan (Moynihan, 2000). Tentu saja, ini terkait. Dalam kedua
kasus tersebut, kemungkinan besar persyaratan akan berubah. Manajer proyek
sering mengikuti rute formal untuk menangani perbedaan pendapat antara
pemangku kepentingan, dan membiarkan pelanggan menandatangani dokumen
persyaratan. Apakah ini jawaban dalam jangka panjang masih dipertanyakan.
Ketika ketidakpastian berkurang, efek menguntungkan dari partisipasi pengguna
dalam rekayasa persyaratan berkurang. Namun, jika ketidakpastian meningkat,
partisipasi pengguna yang lebih besar memiliki efek positif pada kualitas rekayasa
persyaratan. Biasanya bijaksana untuk memiliki banyak tautan
pelanggan-pengembang dalam proyek pengembangan perangkat lunak, dan
khususnya selama rekayasa persyaratan. Keil dan Carmel (1995) mempelajari
hubungan antara keberhasilan proyek dan jumlah dan jenis hubungan
pelanggan-pengembang tersebut. Penulis mengamati korelasi yang kuat antara
jumlah tautan dan keberhasilan proyek: lebih banyak tautan menyiratkan lebih
banyak proyek yang berhasil. Kontribusi relatif terhadap kesuksesan proyek
berkurang seiring bertambahnya jumlah mata rantai; tidak perlu memiliki lebih dari,
katakanlah, setengah lusin tautan. Pengamatan lebih lanjut yang menarik dari
penelitian ini adalah bahwa link dengan langsung pengguna memiliki lebih banyak
dampak pada keberhasilan proyek daripada tautan tidak langsung pengguna seperti
perwakilan pengguna atau tenaga penjualan. Akhirnya, dicatat bahwa proyek
pengembangan yang didorong oleh pelanggan cenderung menggunakan dan lebih
menyukai jenis tautan yang berbeda daripada proyek pengembangan yang
digerakkan oleh pasar. Misalnya, tautan favorit untuk pengembangan kustom -- tim
yang difasilitasi -- tidak digunakan oleh pengembang paket, sedangkan tautan
favorit untuk pengembang paket -- jalur dukungan -- jarang digunakan untuk proyek
kustom.
Kita harus sangat berhati-hati dalam menilai teknik elisitasi persyaratan mana
yang harus dipilih. Terlalu umum untuk terlalu optimis tentang kemampuan kita untuk
menilai persyaratan perangkat lunak dengan benar.
Sebagai contoh, perhatikan anekdot berikut dari sebuah surat kabar Belanda.
Sebuah perusahaan dalam bisnis otomasi peternakan telah mengembangkan
sebuah sistem di mana microchip dimasukkan ke dalam telinga sapi. Selanjutnya,
setiap individu sapi dapat dilacak: pasokan makanan dan air diatur dan disesuaikan,
jumlah dan kualitas susu secara otomatis dicatat dan dianalisis, dll. Secara alami,
teknik yang sama ini selanjutnya berhasil diterapkan pada babi. Setelah itu,
dicobakan pada kambing. Peternakan kambing otomatis bernilai jutaan dolar
dibangun. Namun sayang, semuanya tidak berjalan dengan baik untuk kambing.
Berbeda dengan sapi dan babi, kambing memakan segalanya, termasuk keripik
temannya.
9.1.3 Tujuan dan Sudut

Pandang
Pada bagian ini kita membahas dua cara untuk menyusun seperangkat persyaratan. Salah satu cara
untuk dilakukan
begitu juga dalam struktur hierarkis: persyaratan tingkat yang lebih tinggi didekomposisi menjadi
persyaratan yang lebih rendah.
yang tingkat. Persyaratan tingkat tinggi sering disebut tujuan. Penataan lainnya
metode link persyaratan untuk pemangku kepentingan tertentu. Misalnya, manajemen dapat
memiliki satu set persyaratan, dan pengguna akhir mungkin memiliki (lain) set persyaratan.
Serangkaian persyaratan yang berbeda ini disebut sudut pandang. Dalam kedua kasus, elisitasi
dan penataan berjalan beriringan.
Misalnya, salah satu persyaratan yang ditimbulkan untuk sistem perpustakaan kami adalah
bahwa sistem harus memungkinkan pengguna untuk mencari database untuk buku tertentu. Oleh
bertanya kepada diri sendiri atau para pemangku kepentingan Mengapa persyaratan ini diperlukan,
tingkat yang lebih tinggi
kebutuhan terdeteksi, yaitu. kebutuhan untuk memiliki fasilitas pencarian. Sekali lagi bertanya
mengapa, tujuan tingkat tinggi untuk melayani pelanggan tercapai. Pergi ke arah lain, oleh
meminta Bagaimana sistem perpustakaan dapat membantu melayani pelanggan, persyaratan untuk
belajar
tentang preferensi pengguna dan menggunakan pengetahuan ini saat berinteraksi dengan pengguna,
mungkin
muncul. Dengan cara ini, dengan bertanya Mengapa Dan Bagaimana pertanyaan, struktur hirarkis tujuan
dan persyaratan berkembang. Gambar 9.6 berisi contoh hierarki seperti itu
struktur.
melayani pelanggan
mencari pelajari pengguna

fasilitas preferensi
buku pencarian mencari item berita
Gambar 9.6 Hierarki persyaratan

Gambar 9.6 menggambarkan struktur penyempurnaan, di mana setiap

persyaratan disempurnakan (diuraikan) menjadi satu set subpersyaratan yang
bersama-sama memenuhi persyaratan induk. Subpersyaratan terkait DAN: 'buku
pencarian' dan 'pencarian berita' bersama-sama membentuk persyaratan 'fasilitas
pencarian'.
Kami juga dapat menyertakan jenis hubungan lainnya. Misalnya, kami mungkin
memiliki opsi tertentu untuk persyaratan tertentu, dan untuk tujuan itu memiliki
relasi-OR di sebelah relasi-AND. Kami juga dapat menyertakan jenis tautan lainnya.
Jika kami memiliki persyaratan untuk mengenakan denda pada pelanggan yang
mengembalikan barang terlambat, kami mungkin menganggapnya bertentangan
dengan tujuan kami melayani pelanggan, dan menghubungkan kedua persyaratan
ini dengan tautan jenis 'konflik dengan'.
Yang disebut ini rekayasa persyaratan yang digerakkan oleh tujuan
menghasilkan grafik yang menghubungkan sasaran tingkat tinggi dengan
persyaratan tingkat rendah. Grafik ini dapat dijadikan alasan, misalnya untuk
memvalidasi bahwa tujuan tertentu memang tercapai, atau untuk mendeteksi konflik
(Lamsweerde, 2001).
Seringkali berguna untuk mengumpulkan dan mengatur persyaratan dari
perspektif yang berbeda, atau sudut pandang. Pemangku kepentingan yang
berbeda mungkin memiliki rangkaian persyaratan yang berbeda. Masalah kualitas
yang berbeda juga dapat menyebabkan rangkaian persyaratan yang berbeda,
misalnya mengarah ke sudut pandang keamanan. Jenis perspektif yang terakhir
biasanya ditangani selama desain arsitektur perangkat lunak, dan akan dibahas
dalam bab 11. Teknik yang dibahas dalam bagian 9.3 secara implisit juga
menunjukkan sudut pandang yang berbeda, seperti sudut pandang data dalam
model hubungan-entitas. Di sini, kami fokus pada sudut pandang berbeda yang
disebabkan oleh pemangku kepentingan yang berbeda. Sudut pandang yang
berbeda ini mungkin menimbulkan konflik, dan konflik ini perlu dikenali dan ditangani
selama rekayasa persyaratan.
Computer Aided Dispatch System untuk London Ambulance Service sekali lagi
memberikan kasus yang jelas tentang sudut pandang yang saling bertentangan:
manajemen menginginkan sistem yang efektif, anggota kru ingin pulang dalam
waktu yang wajar setelah giliran kerja mereka berakhir (lihat juga bagian 1.4.3 dan
9.1.1). Untuk sistem perpustakaan kami, konflik antar pemangku kepentingan juga
dapat terjadi.
Pertimbangkan, misalnya, masalah berikut yang mungkin muncul selama fase
elisitasi kebutuhan untuk sistem perpustakaan kita. Sistem ini menawarkan fitur-fitur
tertentu untuk mendaftar dan menangani denda. Barang yang tidak dikembalikan
tepat waktu akan dikenakan denda, katakanlah, $0,25 per hari. John, salah satu
pegawai perpustakaan yang terlibat dalam proses spesifikasi, mengambil posisi
berikut (dilambangkan 'Pos A' pada gambar 9.7): anggota harus diperingatkan
tentang denda yang belum dibayar sedini mungkin. Argumennya ('ArgA') adalah
bahwa layanan terdegradasi jika seorang anggota tidak dapat meminjam barang
karena beberapa anggota lain belum mengembalikan barang itu tepat waktu. Mary,
manajer perpustakaan, mengambil posisi yang agak berbeda ('Pos B'): anggota
harus bukan diperingatkan tentang denda yang belum dibayar sampai tanggal jatuh
tempo telah kedaluwarsa satu bulan. Argumennya ('Arg B') adalah bahwa denda
adalah tambahan yang paling disambut baik untuk anggaran perpustakaan, yang
berada di bawah tekanan berat karena kenaikan harga langganan jurnal yang terus
berlanjut.
Situasi ini digambarkan secara grafis dalam grafik pada gambar 9.7. Grafik berisi
simpul tipe 'masalah', 'posisi' dan 'argumen', dan tautan terarah dari tipe
'respons-ke',
Gambar 9.7 Representasi grafik dari sudut pandang yang saling bertentangan
'diambil oleh' dan 'pendukung'. Menangkap jenis informasi ini dalam sistem otomatis
menawarkan kemungkinan untuk menyimpan, melacak, dan memanipulasi jenis informasi yang sangat
beragam
dikumpulkan selama fase rekayasa persyaratan. Sistem awal bersama
baris ini adalah gIBIS, sebuah sistem yang dirancang untuk menangkap keputusan desain awal.
Dua sudut pandang khususnya penting selama rekayasa persyaratan: itu
sudut pandang bisnis dan sudut pandang pribadi. Sudut pandang bisnis biasanya
disebarkan oleh pemangku kepentingan manajemen, sedangkan sudut pandang pribadi biasanya
disebarkan oleh pengguna akhir. Namun, pengguna akhir cenderung juga menganggap bisnis
persyaratan, setidaknya pada tahap awal. Misalnya, ketika John ditanya apakah
denda adalah tambahan yang disambut baik untuk subsidi yang didapat perpustakaan dari pemerintah,
a
kemungkinan jawabannya adalah 'ya'. Persyaratan ini dipandang sebagai persyaratan bisnis, bukan
kebutuhan pribadi John. Hanya ketika dia dihadapkan dengan konsekuensinya,
akankah dia menyadari bahwa ini bukanlah yang dia inginkan. Dan permintaan untuk mengubah
sistem akan mengikuti.
9.1.4 Memprioritaskan Persyaratan

Tugas kami bukanlah menyediakan setiap tombol dan peningkatan menu pull-down yang
kami miliki
pelanggan meminta, tetapi untuk menemukan cara kerja yang benar-benar baru -- yang
akan menggetarkan hati
dan memukau mereka.

(Robertson, 2002)
Dalam kebanyakan kasus, tidak semua persyaratan dapat direalisasikan, jadi kami
harus membuat pilihan. Di bagian 3.2.3 kami menyebutkan bentuk prioritas
persyaratan yang sangat sederhana yang disebuttriase. Varian yang sering
digunakan dikenal sebagai MoSCoW (huruf o hanya ada untuk dapat melafalkan
kata). Menggunakan MoSCoW, kami membedakan empat jenis persyaratan:
�
Menarik Pelanggan akan lebih puas jika persyaratan ini

persyaratan terpenuhi, tetapi tidak kurang puas jika tidak.
Misalnya, peringatan otomatis jika buku baru dari penulis tercinta
tiba.
Harus Pelanggan akan tidak puas jika persyaratan ini
tidak terpenuhi, tetapi kepuasannya tidak akan pernah meningkat
di atas netral. Contohnya adalah kemampuan untuk mencari
katalog perpustakaan.
Satu dimensi Untuk persyaratan kategori ini, kepuasan diutamakan
sebagian dari berapa banyak dari persyaratan ini yang dipenuhi.
Cara alternatif untuk mencari katalog perpustakaan bisa
termasuk dalam kategori ini.
Cuek Pelanggan tidak terlalu peduli dengan persyaratan ini-
hal. Misalnya, pelanggan mungkin tidak peduli apakah kategori
item perpustakaan yang berbeda ditampilkan dengan warna
berbeda di layar.
Balik Penilaian pelanggan tentang persyaratan adalah
kebalikan dari apa yang menurut analis apriori. Misalnya, analis
mungkin mengira pelanggan perpustakaan ingin sistem
mengingat pola pencariannya agar dapat melayaninya dengan
lebih baik di lain waktu, sementara pelanggan ingin memulai dari
awal setiap saat.
Dipertanyakan Preferensi pelanggan tidak jelas. Dia keduanya
tampaknya menyukai dan tidak menyukai fitur tertentu.
Gambar 9.8 Kategori kebutuhan Kano
9.1.5 pilihan COTS

Hingga saat ini, kami menghadapi situasi di mana pelanggan mengutarakan persyaratannya,
setelah itu sistem yang memenuhi persyaratan ini dikembangkan. Dengan Komersial
Perangkat lunak Off The Shelf (COTS), pelanggan harus memilih dari apa yang tersedia.
Dalam praktiknya, situasinya tidak selalu jelas, dan sistem COTS mungkin demikian
diperluas atau disesuaikan dengan kebutuhan pelanggan. Untuk diskusi kami, kami menganggap itu
proses seleksi murni.
Pemilihan COTS merupakan proses iteratif yang terdiri dari langkah-langkah berikut:
1. Tentukan persyaratan. Seperti dalam proses elisitasi persyaratan biasa, daftar

persyaratan untuk produk diturunkan. Salah satu teknik elisitasi yang dibahas di
atas dapat digunakan dalam proses ini.
puas
satu dimensi
menarik
disfungsional fungsional
harus
tidak puas
Gambar 9.9 Diagram Kano
2. Pilih komponen. Satu set komponen yang mungkin dapat menangani

persyaratan yang diajukan ditentukan. Proses seleksi ini mungkin melibatkan
riset pasar, penjelajahan internet, dan berbagai teknik lainnya.
3. Beri peringkat komponen. Komponen diberi peringkat sesuai urutannya

memenuhi persyaratan.
4. Pilih komponen yang paling sesuai, atau ulangi.
Seringkali, kumpulan komponen dan persyaratan terlalu besar untuk membuat

analisis lengkap dan pemeringkatan dalam satu langkah menjadi layak. Proses
iteratif kemudian diikuti, dimana persyaratan yang paling penting digunakan untuk
membuat pilihan pertama dari kumpulan komponen yang tersedia. Pada langkah
selanjutnya, daftar persyaratan yang lebih besar dinilai terhadap sekumpulan
komponen yang lebih kecil. Dan seterusnya.
Ada berbagai cara untuk menentukan peringkat komponen. Metode yang mudah
adalah Weighted Scoring Method (WSM). Setiap persyaratan diberi bobot, dan
alternatif diberi skor untuk setiap persyaratan, katakanlah dalam skala dari 1 sampai
5. Pada tabel 9.1, tiga komponen berlabel A, B, dan C diberi skor berdasarkan tiga
kriteria: kinerja, reputasi pemasok, dan fungsionalitas. Dalam contoh, komponen
Band C mendapat skor tertinggi, dan ini selanjutnya dapat diteliti lebih lanjut.
9.2. PERSYARATAN DOKUMENTASI DAN MANAJEMEN 2
2
Tabel 9.1 Contoh WSM 9
Krit Berat A B C
eria
Pertunju 2 1 3 5
kan
Pe 1 2 2 5
mas
ok
Kegunaa 3 4 5 1
n
T 16 23 18
o
t
a
l
Kelemahan utama WSM adalah bahwa setiap kriteria dapat dikompensasi oleh
kriteria lainnya. Dalam contoh dari tabel 9.1, komponen C lolos ke babak berikutnya
meskipun skor fungsionalitasnya sangat rendah. Skema pemeringkatan yang lebih
kompleks, seperti Analytic Hierarchy Process (AHP) mengatasi kekurangan ini
((Saaty, 1990)).
9.2 Persyaratan Dokumentasi dan

Manajemen
Produk akhir dari fase rekayasa persyaratan dalam dokumen-driven
proyek pengembangan adalah spesifikasi kebutuhan. Spesifikasi persyaratan
merupakan rekonstruksi a posteriori dari hasil tahap analisis ini. Tujuannya adalah
untuk mengkomunikasikan hasil ini kepada orang lain. Ini berfungsi sebagai titik jangkar yang
melawannya
langkah selanjutnya dapat dibenarkan.
Spesifikasi kebutuhan adalah titik awal untuk fase berikutnya: desain.
Akibatnya, deskripsi matematis yang sangat tepat dan bahkan lebih disukai. Di
Selain itu, spesifikasi juga harus dapat dimengerti oleh pengguna. Ini sering
berarti dokumen yang dapat dibaca, menggunakan bahasa dan gambar alami. Dalam praktiknya, satu
harus mencari kompromi. Atau, spesifikasi persyaratan mungkin
disajikan dalam bentuk yang berbeda, tetapi konsisten, kepada audiens yang berbeda yang terlibat.
Selain keterbacaan dan pemahaman, berbagai persyaratan lain untuk ini
dokumen dapat dinyatakan (IEEE830, 1993):
�
seperti 'ditentukan' sangat berbahaya. Sayangnya, tidak selalu mungkin untuk
menyelesaikan spesifikasi pada tahap awal. Jika persyaratan tertentu hanya
dapat dibuat spesifik pada tahap selanjutnya, spesifikasi persyaratan
setidaknya harus mendokumentasikan titik akhir waktu di mana hal ini
seharusnya terjadi.
�
9.2. PERSYARATAN DOKUMENTASI DAN 231
MANAJEMEN
dokumen juga kurang penting. Poin penting adalah memilih struktur yang mengikuti
batasan di atas. Dalam Standar IEEE 830, struktur global seperti yang digambarkan
pada gambar 9.10, digunakan.
1.2.3.
Perkenalan
1.1 Tujuan
1.2 Lingkup
1.3 Definisi, akronim dan singkatan
1.4 Referensi
1.5 Gambaran Umum
Deskripsi keseluruhan
2.1 Perspektif produk
2.2 Fungsi produk
2.3 Karakteristik Pengguna
2.4 Kendala
2.5 Asumsi dan ketergantungan
2.6 Persyaratan subset
Persyaratan khusus
Gambar 9.10 Struktur global dari spesifikasi persyaratan (Sumber:

IEEERecommendedPractice for Software Requirements Specifications, IEEE Std
830, 1993. Direproduksi dengan izin IEEE.)
Untuk sistem nontrivial apa pun, persyaratan terperinci akan menjadi bagian
terbesar dari dokumen persyaratan. Oleh karena itu, akan sangat membantu untuk
mengkategorikan persyaratan terperinci ini. Hal ini dapat dilakukan sepanjang
dimensi yang berbeda, seperti:
�
�
MANAJEMEN
1.2 Cakupan. Produk yang dimaksud mengotomatiskan fungsi perpustakaan
yang dijelaskan di DOC1. Tujuannya adalah untuk memberikan pelayanan
yang lebih efektif kepada pengguna perpustakaan, khususnya melalui fasilitas
pencarian online yang ditawarkan. Rincian lebih lanjut dari persyaratan kinerja
diberikan di bagian 3.3 dokumen ini. Setelah sistem ini diinstal,
penggabungan judul baru akan berjalan dari rata-rata 15 menit menjadi
rata-rata 5 menit.
1.3 Definisi, akronim dan singkatan. Anggota perpustakaan: . . . , Petugas
perpustakaan:. . . , Pengguna: Istilah pengguna dapat merujuk pada anggota
perpustakaan dan personel perpustakaan, dan digunakan untuk menunjukkan
salah satu kelas pengguna. Katalog judul: . . . ,PICA: . . . , dll.
1.4 Referensi. DOC1: . . . , DOC2: . . . , dll.
1.5 Ringkasan. Bagian 2 dari dokumen ini memberikan gambaran umum
tentang sistem. Bagian 3 memberikan persyaratan yang lebih spesifik untuk
fungsi yang ditawarkan. Fungsi-fungsi ini dikategorikan menurut kelas
pengguna yang didukungnya: anggota (eksternal) perpustakaan dan petugas
perpustakaan.
2. Deskripsi keseluruhan.
2.1 Perspektif produk. Sistem database X yang telah terinstal akan digunakan
untuk menyimpan berbagai katalog serta administrasi anggota perpustakaan.
Tidak ada antarmuka ke sistem lain. Sistem akan direalisasikan pada
konfigurasi Y. Kapasitas penyimpanan eksternal maksimum untuk katalog
sistem adalah 1500 MB. Petugas perpustakaan akan menggunakan barcode
reader untuk memasukkan identitas anggota, buku dan jurnal. Protokol
antarmuka ke pembaca kode batang dijelaskan dalam DOC4.
2.2 Fungsi produk. Sistem menyediakan dua jenis fungsi:
– Fungsi dimana pengguna dapat mencari katalog buku dan jurnal
artikel. Daftar fungsi-fungsi ini diberikan dalam DOC1. Sebuah lebih rinci
deskripsi diberikan dalam bagian 3.2.1.
– Fungsi-fungsi dimana petugas perpustakaan dapat memperbaharui
administrasi
judul pinjaman dan katalog sistem; lihat bagian 3.2.2.
Pengguna sistem memilih salah satu fungsi yang ditawarkan melalui
menu utama (bagian 3.2.1.1 dan 3.2.2.1).
2.3 Karakteristik pengguna. Anggota perpustakaan adalah pengguna
insidental dari sistem dan memiliki sedikit pengetahuan tentang sistem
otomatis semacam ini. Oleh karena itu, sistem harus menginstruksikan diri
sendiri. Persyaratan khusus dirumuskan dalam bagian 3.1.1 dan 3.3. Petugas
perpustakaan akan dilatih dalam penggunaan sistem; lihat bagian 3.1.1.
2.4 Kendala. Anggota perpustakaan hanya dapat mencari katalog buku dan
artikel jurnal; mereka tidak diperbolehkan memperbarui katalog atau
administrasi pengguna. Fungsi yang terakhir ditawarkan hanya melalui
antarmuka khusus yang dilindungi kata sandi.
2.5 Asumsi dan ketergantungan. . . .

2.6 Subset persyaratan. . . .
3. Persyaratan khusus.
3.1 Persyaratan antarmuka eksternal.

3.1.1 Antarmuka pengguna. Format layar untuk berbagai fitur adalah
ditentukan dalam Lampiran A. Lampiran B mencantumkan pemetaan
perintahuntuk tombol fungsi. Pengguna bisa mendapatkan bantuan
online kapan saja dengan memberi perintah yang sesuai. Lampiran C
berisi daftar tipikal skenario penggunaan. Skenario penggunaan
ini akan digunakan sebagai penerimaan kriteria: 80% pengguna
harus dapat melewatinya di dalam sepuluh menit. Sesi instruksi untuk
personel perpustakaan harus dilakukan paling lama dua jam.
3.1.2 Antarmuka perangkat keras. Antarmuka pengguna berorientasi
pada layar. Sistem menggunakan hingga sepuluh tombol fungsi.
3.1.3 Antarmuka perangkat lunak. Antarmuka dengan sistem basis data X
dijelaskan di DOC2.
3.1.4 Antarmuka komunikasi. Tak dapat diterapkan.
3.2 Persyaratan fungsional.
3.2.1 fungsi anggota perpustakaan.
3.2.1.1 Pilih fitur anggota. Pengguna memilih salah satu opsi dari
menu utama. Tindakan selanjutnya dijelaskan di bagian
3.2.1.2 dan 3.2.1.3.
Kapan saja, pengguna memiliki opsi untuk kembali ke
utama menu (lihat Lampiran B).
3.2.1.2 Cari katalog buku. Diberikan (bagian dari) judul buku atau
penulis nama, pengguna dapat mencari katalog buku untuk
judul-judul itu sesuai dengan masukan yang diberikan. Pengguna
ditawari layar dengan dua area isi-kosong (satu untuk judul
dan satu untuk penulis), yang salah satunya harus diisi.
Memasukkan. Input mungkin berisi huruf besar dan kecil
surat. Simbol khusus yang diperbolehkan tercantum dalam DOC1.
Setiap mesin terbang lain yang dimasukkan dibuang dan tidak
ditampilkan layar. Input dianggap selesai bila perintah
pemrosesan dikeluarkan.
Pengolahan. Semua huruf kecil diubah menjadi huruf besar
huruf. String yang diperoleh digunakan saat melakukan
kueri basis data. Entri basis data cocok dengan string judul yang
diberikan jika input yang diubah adalah substring dari bidang judul
dari pintu masuk. Hal yang sama berlaku untuk bidang penulis
jika (bagian dari) an nama penulis adalah input.
MANAJEMEN
Keluaran. Daftar judul yang cocok dengan input ditampilkan. Ke atas
ke empat judul ditampilkan di layar. Pengguna dapat melintasi
daftar judul yang ditemukan menggunakan perintah pengguliran
layar
asalkan. Peringatan dikeluarkan jika tidak ada judul yang cocok
dengan input
diberikan.
3.2.1.3 Cari katalog artikel. . . .
3.2.2 fungsi personel perpustakaan.
3.2.2.1 Pilih fitur personel.Throughdedicated, dilindungi kata sandi
antarmuka, personel perpustakaan ditawarkan perpanjangan utama
menu, mencantumkan opsi yang tersedia untuk semua pengguna,
serta
opsi yang tersedia hanya untuk personel perpustakaan. Yang
terakhir adalah
dijelaskan dalam bagian 3.2.2.2 dan 3.2.2.3.
3.2.2.2 Pinjam judul. . . .
3.2.2.3 Modifikasi katalog. . . .
3.3 Persyaratan kinerja. Sistem awalnya akan mendukung 32 akses bersamaan
poin. Kapasitas maksimumnya adalah 128 titik akses bersamaan.
Database saat ini menampung 25.000 judul buku dan 500 langganan jurnal.
Kapasitas penyimpanan yang dibutuhkan untuk data ini adalah 300 MB. Rata-rata 1000
buku dan 2000 edisi jurnal masuk perpustakaan per tahun. Rata-rata
edisi jurnal memiliki enam artikel. Ini membutuhkan kapasitas penyimpanan 15 MB per
tahun.
Sistem harus mampu melayani 20 pengguna secara bersamaan. Dengan ini
beban maksimum dan ukuran basis data 450 MB, kueri pengguna seperti yang
tercantum dalam
bagian 3.2.1 dan 3.2.2 harus dijawab dalam waktu lima detik dalam 80% dari
kasus.
3.4 Kendala desain.
3.4.1 Kepatuhan standar. Deskripsi judul harus disimpan dalam format PICA.
Format ini dijelaskan dalam DOC3.
3.4.2 Keterbatasan perangkat keras. Lihat bagian 2.1.
3.5 Atribut sistem perangkat lunak.
3.5.1 Ketersediaan. Selama jam kantor normal (9 pagi - 5 sore) sistem
harus tersedia 95% dari waktu. Cadangan sistem dibuat
setiap hari jam 5 sore.
3.5.2 Keamanan. Fungsi yang dijelaskan di bagian 3.2.2 dibatasi untuk
karyawan perpustakaan dan dilindungi kata sandi. . . .
3.5.3 Pemeliharaan. . . .
3.6 Persyaratan lainnya. . . .
Kerangka kerja IEEE untuk spesifikasi persyaratan adalah model berbasis dokumen
yang sesuai untuk proses pengembangan perangkat lunak: model air terjun
Gambar 9.12 Spesifikasi persyaratan yang dikerjakan sebagian untuk contoh

perpustakaan
Gambar akhir 9.12
dan variannya. Ketika teknik prototyping digunakan untuk menentukan antarmuka

pengguna, framework IEEE dapat digunakan untuk menggambarkan hasil dari
proses prototyping tersebut. Framework tersebut mengasumsikan model di mana
hasil dari proses rekayasa persyaratan tidak ambigu dan lengkap. Meskipun
dinyatakan bahwa persyaratan harus diurutkan berdasarkan kepentingannya, dan
persyaratan yang mungkin ditunda hingga versi yang akan datang dapat
dimasukkan sebagai himpunan bagian, ini tidak berarti bahwa tampilan sistem
berlapis dapat dengan mudah diturunkan dari dokumen persyaratan yang dibuat
dengan cara ini.
Terlepas dari format yang dipilih untuk mewakili persyaratan, keberhasilan
produk sangat tergantung pada sejauh mana sistem yang diinginkan dijelaskan
dengan benar selama fase rekayasa persyaratan. Slip kecil dalam spesifikasi
persyaratan mungkin memerlukan perubahan besar dalam perangkat lunak akhir.
Perangkat lunak tidak kontinyu, seperti yang kita catat sebelumnya.
Pentingnya spesifikasi persyaratan yang solid tidak dapat ditekankan cukup
sering. Dalam beberapa kasus, hingga 95% dari kode sistem besar harus ditulis
ulang untuk memenuhi kebutuhan pengguna akhir.
9.2.1 Manajemen Persyaratan

Masalah mendasar dengan kerangka kerja IEEE yang dibahas di atas adalah hanya
menjelaskan produk akhir. Sebelum tahap akhir ini tercapai, rangkaian persyaratan
'saat ini' berada dalam keadaan fluks yang konstan. Dan bahkan setelah fase
persyaratan berakhir, persyaratan akan berubah dan persyaratan baru akan
diajukan. Fenomena terakhir dikenal sebagai persyaratan merayap, dan
merupakan penyebab banyak proyek lari.
Perubahan persyaratan tidak dapat dielakkan. Dalam banyak kasus, tidak
bijaksana juga untuk membekukan persyaratan lebih awal. Secara umum, situasi
yang disukai adalah seperti yang digambarkan pada gambar 9.13: seiring
berjalannya waktu, rangkaian persyaratan menjadi semakin stabil.
Jelas, rangkaian persyaratan yang berkembang ini harus dikelola. Manajemen
kebutuhan melibatkan tiga aktivitas:
– identifikasi kebutuhan,
– manajemen perubahan persyaratan, dan
– persyaratan ketertelusuran.
Setiap persyaratan harus memiliki identifikasi unik. Bentuk paling sederhana adalah
dengan memberi nomor saja. Jika ada organisasi hierarkis, seperti dalam hierarki
tujuan, hal itu dapat tercermin dalam skema penomoran. Karena persyaratan sering
diubah dan diperbarui, sebaiknya sertakan juga informasi pembuatan versi.
Akhirnya, kita mungkin
9.2. PERSYARATAN DOKUMENTASI DAN MANAJEMEN 237
terlalu dini
membekukan
stabilitas kebutuhan
persyaratan
orang aneh
waktu
Gambar 9.13 Persyaratan stabilitas dari waktu ke waktu
menambahkan beberapa atribut pada setiap persyaratan, seperti status, prioritas, pemangku
kepentingan utama
terlibat, dan sejenisnya. Kebutuhan alat teknik biasanya memiliki sarana untuk menyimpan
persyaratan dalam repositori terstruktur.
Perubahan persyaratan harus dikelola dengan baik. Dengan melihat setiap kebutuhan-
ment sebagai item konfigurasi, aturan dan prosedur dari manajemen konfigurasi
(bab 4) dapat diterapkan.
Kami dapat menghubungkan persyaratan ke elemen solusi seperti elemen desain atau
bahkan komponen perangkat lunak yang mewujudkan persyaratan tersebut. Dengan cara ini, kami
membangun
ketertelusuran dari persyaratan ke kode dan sebaliknya. Hal ini memungkinkan kita untuk melacak di
mana
persyaratan direalisasikan (forward traceability), dan mengapa solusi tertentu dipilih
(penelusuran mundur). Informasi ketertelusuran penting dalam semua pengembangan
fase. Dapat digunakan untuk menjawab berbagai pertanyaan, seperti:
– di mana persyaratan ini diterapkan?
– apakah kita memerlukan persyaratan ini?
– apakah semua persyaratan terkait dengan elemen solusi?
– persyaratan apa yang tercakup dalam kasus uji ini?
– apa dampak dari persyaratan ini?

– apakah kita memerlukan elemen desain ini (sepotong kode)?
Cara membuat hubungan antara persyaratan dan solusi ini secara eksplisit
terkait erat dengan analisis desain ruang. Dalam analisis ruang desain, tujuannya
adalah untuk secara eksplisit memodelkan semua kemungkinan kombinasi
kebutuhan dan solusi. Analisis ruang desain berasal dari bidang interaksi
manusia-komputer. Notasi terkenal untuk Analisis Ruang Desain dikenal sebagai
QOC (Pertanyaan, Pilihan, dan Kriteria). Pertanyaan sesuai dengan persyaratan,
Opsi adalah jawaban yang mungkin untuk persyaratan tersebut, dan Kriteria
mengacu pada alasan untuk memilih opsi tertentu. Misalnya, kami dapat
menampilkan hasil permintaan berita dari pelanggan perpustakaan (pertanyaan)
baik diurutkan berdasarkan tanggal publikasi, atau berdasarkan nama penulis (opsi).
Kriteria untuk menggunakan salah satu urutan dapat menjadi sumber item berita :
mengurutkan artikel koran berdasarkan tanggal, dan artikel jurnal berdasarkan nama
penulis.
Di satu sisi, analisis ruang desain menghasilkan struktur yang kaya di mana
catatan ekstensif dibangun dari alasan untuk solusi spesifik. Mengapa sistem ini
dibangun seperti itu? Alternatif mana yang kami pertimbangkan tetapi tolak?
Persyaratan mana yang selamat dari pengorbanan yang harus kami lakukan? Di sisi
lain, menangkap semua informasi ini mahal, dan manfaat langsungnya sulit
dibuktikan, jika memang ada. Ini adalah alasan utama mengapa pemikiran desain
pada umumnya gagal ditransfer ke praktik.
9.3 Persyaratan Spesifikasi Teknik

Dokumen yang dihasilkan selama rekayasa persyaratan -- spesifikasi persyaratan --
melayani dua kelompok orang. Untuk pengguna, spesifikasi kebutuhan adalah
deskripsi yang jelas dan tepat dari fungsionalitas yang ditawarkan sistem. Bagi
perancang, ini adalah titik awal untuk desain. Tidak mudah melayani kedua
kelompok dengan satu dokumen yang sama.
Pengguna pada umumnya paling baik dilayani oleh dokumen yang berbicara
dalam bahasanya, bahasa yang digunakan dalam domain aplikasi. Dalam contoh
yang digunakan sebelumnya, ini akan menghasilkan penggunaan istilah seperti
'deskripsi judul' dan 'katalog'.
Perancang di sisi lain, paling baik disajikan dengan bahasa di mana konsep dari
dunianya digunakan. Dalam hal contoh perpustakaan, dia mungkin lebih suka
konsep seperti catatan (contoh yang mungkin disebut 'deskripsi judul') atau file.
Pada satu sisi, ini bermuara pada perbedaan bahasa. Namun, perbedaan ini sangat
penting sehubungan dengan penggunaan deskripsi sistem selanjutnya. Jika sistem
dijelaskan dalam bahasa pengguna, spesifikasi kebutuhan sebagian besar
diungkapkan dalam beberapa bahasa alami. Jika kita mencoba memformalkan
deskripsi ini, kita mungkin berakhir dengan teknik di mana bentuk-bentuk tertentu
harus diisi atau teknik menggambar tertentu harus diterapkan.
Sebaliknya, jika bahasa ahli dari perekayasa perangkat lunak memainkan peran
sentral, kita sering menggunakan beberapa bahasa formal. Spesifikasi persyaratan
yang diutarakan dalam bahasa formal semacam itu dapat diperiksa menggunakan
teknik formal, misalnya berkenaan dengan konsistensi dan kelengkapan.
9.3. TEKNIK SPESIFIKASI KEBUTUHAN 239
Dalam praktiknya, prevalensi yang blak-blakan untuk bahasa ahli pengguna menunjukkan dirinya
sendiri.
Kami kemudian dapat menggunakan konsep yang ada dari lingkungan di mana sistem itu berada
akan digunakan. Memang, konsep-konsep ini tidak didefinisikan secara tajam, tetapi secara umum
tidak ada kesalahpahaman antara para ahli dalam domain aplikasi
makna dari konsep-konsep itu. Deskripsi dalam hal konsep-konsep itu masih bisa
menjadi sangat tepat. Karena tujuan pertama dari spesifikasi kebutuhan adalah untuk mendapatkan a
menyelesaikan
deskripsi masalah yang harus dipecahkan, bahasa ahli pengguna kemudian akan menjadi
bahasa terbaik untuk spesifikasi persyaratan.
Namun, ada kelemahan tertentu yang melekat pada penggunaan bahasa alami.
Meyer (1985) memberikan sebuah contoh yang mengilustrasikan dengan sangat baik apa yang salah
ketika terjadi
bahasa alami digunakan dalam spesifikasi kebutuhan. Meyer mendaftar tujuh dosa yang mana
mungkin menimpa analis saat menggunakan bahasa alami:
�
�
9.4. VERIFIKASI DAN VALIDASI 241
– keterbatasan perangkat keras yang disebabkan oleh infrastruktur yang tersedia.
Persyaratan non-fungsional yang tersisa juga dikenal sebagai persyaratan kualitas.

Persyaratan kualitas sangat sulit untuk ditentukan dan diverifikasi. Topik ini ditangani
dengan ekstensif di bab 6. Pada titik ini, kami hanya ingin menekankan kembali dua
masalah penting: persyaratan kualitas harus dinyatakan secara objektif, terukur
persyaratan dan kesempurnaan menimbulkan biaya tak terbatas.
Seperti semua persyaratan lainnya, persyaratan kualitas harus dapat diverifikasi. Memerlukan-
seperti 'sistem harus fleksibel', 'sistem harus mudah digunakan',
atau 'waktu respons harus cepat', tidak pernah dapat diverifikasi dan karenanya tidak seharusnya
muncul dalam spesifikasi kebutuhan. Ungkapan lain dapat digunakan seperti 'untuk
kegiatan tipe A sistem harus memiliki waktu respons maksimum satu detik
dalam 80% kasus, sementara waktu respons maksimum tiga detik diperbolehkan masuk
20% sisanya dari kasus '.
Sebaliknya, tingkat persyaratan kualitas yang ekstrim, seperti nol cacat atau
waktu respons kurang dari 1 detik dalam 100% kasus, umumnya sangat merugikan
biaya tinggi, atau tidak layak sama sekali. Mengingat fakta bahwa pengguna merasa sulit untuk
melakukannya
mengungkapkan kebutuhan mereka yang sebenarnya, mereka mungkin cenderung meminta terlalu
banyak di mana
persyaratan kualitas diperhatikan, hanya 'untuk berada di sisi yang aman'. Untuk analis dan
pengembang, juga sulit untuk menilai kelayakan persyaratan tersebut. Bagaimana
dapatkah kita yakin tentang waktu respons bahkan sebelum satu baris kode ditulis?
Pertimbangkan contoh berikut tentang apa yang mungkin dan mungkin tidak layak secara teknis.
Misalkan kita memiliki aplikasi di mana dua jenis transaksi dapat terjadi.
Transaksi tersebut dicirikan oleh frekuensinya, waktu CPU yang dibutuhkan, dan
jumlah transportasi I/O fisik. Rata-rata waktu akses I/O juga diberikan. Menggunakan sebuah
distribusi statistik yang menjelaskan dinamika sistem ini, orang kemudian dapat menjawab
pertanyaan seperti: 'berapa kapasitas yang harus dimiliki CPU untuk mencapai a
waktu respons paling banyak 2 detik dalam X% kasus?’ Beberapa konfigurasi mungkin
memenuhi batasan untuk kasus X = 80. Persyaratan yang agak lebih ketat
(X = 90) mungkin memerlukan penggandaan kapasitas CPU. Persyaratan yang lebih berat lagi
(X = 95) mungkin tidak dapat dicapai dengan berbagai mesin yang tersedia.
Pada pandangan pertama, perbedaan antara persyaratan ini tampak kecil. Mereka
ternyata memiliki efek yang luar biasa, meskipun. Sebuah analisis awal dan hati-hati dari
kelayakan teknis dapat menghasilkan jawaban yang mengejutkan atas sejumlah pertanyaan penting.
Biasanya, jenis analisis ini dilakukan pada waktu arsitektur perangkat lunak. ada banyak
contoh proyek di mana banyak uang dihabiskan untuk pengembangan perangkat lunak
upaya yang ternyata tidak layak secara praktis (Baber, 1982).
9.4 Verifikasi dan Validasi

Dalam bab 1, kami berpendapat bahwa studi yang cermat tentang kebenaran keputusan
dibuat pada setiap tahap merupakan faktor penentu keberhasilan. Ini berarti bahwa selama persyaratan
rekayasa kita harus sudah mulai memverifikasi dan memvalidasi keputusan yang
ditetapkan dalam spesifikasi persyaratan.
Spesifikasi persyaratan harus mencerminkan pemahaman bersama tentang
masalah yang harus diselesaikan oleh calon pengguna dan organisasi
pengembang: apakah semuanya telah dijelaskan, dan apakah sudah dijelaskan
dengan benar. Memvalidasi persyaratan dengan demikian berarti memeriksanya
untuk properti seperti kebenaran, kelengkapan, ambiguitas, dan konsistensi internal
dan eksternal. Karena kebutuhan, ini melibatkan partisipasi pengguna dalam proses
validasi. Mereka adalah pemilik masalah dan mereka adalah satu-satunya yang
memutuskan apakah spesifikasi kebutuhan menggambarkan masalah mereka
secara memadai.
Jika spesifikasi kebutuhan itu sendiri diekspresikan dalam bahasa formal,
sintaks dan semantik dari representasi tersebut dapat diverifikasi melalui sarana
formal. Namun, spesifikasi persyaratan tidak pernah dapat sepenuhnya divalidasi
secara formal, hanya karena titik tolak dari rekayasa persyaratan bersifat informal.
Sebagian besar teknik pengujian yang diterapkan pada tahap ini juga bersifat
informal. Mereka dimaksudkan untuk memastikan bahwa pihak-pihak yang terlibat
memiliki pemahaman masalah yang sama dan tepat. Batu sandungan utama pada
tahap ini adalah memastikan pengguna memahami isi dari spesifikasi kebutuhan.
Teknik-teknik yang diterapkan pada tahap ini sering diselesaikan dengan
menerjemahkan persyaratan menjadi bentuk yang sesuai untuk inspeksi pengguna:
parafrase bahasa alami, diskusi skenario penggunaan yang mungkin, pembuatan
prototipe, dan animasi.
Selain menguji spesifikasi kebutuhan itu sendiri, pada tahap ini kami juga
menghasilkan rencana pengujian untuk digunakan selama pengujian sistem atau
penerimaan. Rencana pengujian adalah dokumen yang menjelaskan ruang lingkup,
pendekatan, sumber daya, dan jadwal kegiatan pengujian. Ini mengidentifikasi item
dan fitur yang akan diuji, tugas pengujian yang akan dilakukan, dan personel yang
bertanggung jawab atas tugas ini. Pada titik ini kita dapat mengembangkan rencana
seperti itu untuk tahap pengujian sistem, yaitu tahap di mana organisasi
pengembang menguji sistem yang lengkap terhadap persyaratannya. Pengujian
penerimaan serupa, tetapi dilakukan di bawah pengawasan organisasi pengguna.
Pengujian penerimaan dimaksudkan untuk menentukan apakah pengguna
menerima sistem atau tidak.
Pembahasan yang lebih rinci tentang berbagai teknik verifikasi dan validasi akan
diberikan dalam bab 13.
9.5 Ringkasan
Selama rekayasa persyaratan kami mencoba untuk mendapatkan deskripsi yang
lengkap dan jelas tentang masalah yang harus dipecahkan dan kendala yang harus
dipenuhi oleh setiap solusi untuk masalah itu. Selama fase ini, kami tidak hanya
mempertimbangkan fungsi yang akan disampaikan, tetapi kami juga memperhatikan
persyaratan yang diberlakukan oleh lingkungan. Tahap rekayasa kebutuhan
menghasilkan serangkaian model yang berkonsentrasi pada berbagai aspek sistem
(seperti fungsinya, antarmuka pengguna, dan struktur komunikasi) dan perspektif
(audiens) yang berbeda. Hasil dari proses ini didokumentasikan dalam spesifikasi
kebutuhan. Kerangka kerja yang baik untuk isi persyaratan
9.5. RINGKASAN 243
spesifikasi diberikan dalam (IEEE830,1993). Perlu diingat bahwa dokumen ini

berisi rekonstruksi a posteriori dari proses iteratif yang belum dipahami dengan baik.
Proses berulang ini melibatkan empat jenis kegiatan:
– elisitasi kebutuhan, yaitu tentang memahami masalah,
– spesifikasi kebutuhan, yaitu tentang menggambarkan masalah,
– validasi persyaratan, yaitu tentang menyetujui masalahnya, dan
– Negosiasi persyaratan, yaitu tentang tepat masalah dengan situasi di

tangan.
Dalam banyak kasus, menyelesaikan rekayasa persyaratan secara penuh sebelum desain dan
konstruksi
tion mulai tidak layak. Dalam proses pengembangan yang gesit, rekayasa persyaratan adalah
terkait dengan desain dan konstruksi.
Selama rekayasa persyaratan, kami memodelkan bagian dari realitas. Bagian dari
realitas yang kita minati disebut sebagai semesta wacana (UoD). Itu
proses pemodelan disebut pemodelan konseptual.
Orang yang terlibat dalam UoD memiliki model konseptual implisit dari UoD tersebut.
Selama pemodelan konseptual, model implisit diubah menjadi model eksplisit. Itu
model konseptual eksplisit digunakan untuk berkomunikasi dengan orang lain, seperti pengguna
dan desainer, dan untuk menilai validitas sistem yang sedang dikembangkan selama ini
fase selanjutnya. Selama proses pemodelan, analis dihadapkan pada dua hal
jenis masalah: masalah analisis dan masalah negosiasi. Masalah analisis
harus dilakukan dengan mendapatkan persyaratan yang benar. Masalah negosiasi muncul karena
orang berbeda yang terlibat mungkin memiliki pandangan berbeda tentang UoD yang akan dimodelkan,
kepentingan yang bertentangan, dan sebagainya.
Pendekatan yang ada untuk rekayasa persyaratan sebagian besar bersifat Taylorian.
Mereka sesuai dengan pandangan fungsional pengembangan perangkat lunak di mana persyaratannya
fase rekayasa berfungsi untuk memperoleh persyaratan pengguna 'nyata'. Hal ini semakin menjadi
mengakui bahwa pendekatan Taylorian tidak perlu menjadi pendekatan yang paling tepat
untuk rekayasa kebutuhan. Banyak UoD yang dipertimbangkan melibatkan orang-orang yang
model dunia tidak lengkap, tidak rasional, atau bertentangan dengan pandangan dunia orang lain.
Dalam kasus seperti itu, analis bukanlah pengamat luar yang pasif dari UoD, tetapi secara aktif
berpartisipasi dalam membentuk UoD. Analis terlibat dalam masalah negosiasi
dan harus memilih pandangan dari beberapa pihak yang terlibat, atau membantu mendapatkan
beberapa
kompromi.
Teknik deskripsi berikut sering digunakan untuk persyaratan yang ditentukan
kation:
– bahasa alami,
- gambar, dan
- bahasa formal.
Keuntungan menggunakan bahasa alami adalah spesifikasinya sangat mudah

dibaca dan dimengerti oleh pengguna dan non-profesional lain yang terlibat.
Gambar dapat dimanfaatkan untuk menghadirkan arsitektur fungsional sistem.
Bahasa formal memungkinkan kita untuk menggunakan alat dalam menganalisis
persyaratan. Karena presisinya, ini merupakan titik awal yang baik untuk fase
desain. Kita juga dapat berargumen bahwa notasi formal dan informal digunakan,
karena mereka menambah dan melengkapi satu sama lain. Untuk masing-masing
pihak yang terlibat, sebuah notasi harus dipilih yang sesuai dengan tugas yang ada.

Ada banyak buku teks yang sepenuhnya dikhususkan untuk rekayasa persyaratan.
Davis (1993) memberikan cakupan yang cukup lengkap tentang teknik spesifikasi
persyaratan 'klasik'. Davis (2005) berfokus pada rekayasa persyaratan dalam
menghadapi batasan jadwal yang ketat. Wieringa (1996) membahas sejumlah teknik
spesifikasi kebutuhan secara cukup mendalam. Perbedaan antara model konseptual
implisit dan eksplisit dibuat di sana juga. Loucopoulos dan Karakostas (1995) dan
Kotonya dan Sommerville (1997) memiliki penekanan yang lebih kuat pada proses
rekayasa persyaratan penuh. Juristoet al. (2002) membahas keadaan praktek dalam
rekayasa kebutuhan. Hofmanand Lehner (2001) fokus pada praktik persyaratan
yang berhasil. Sommerville (2005) membahas perkembangan terakhir di lapangan.
Pohl (1993) dan Goguen dan Jirotka (1994) menekankan peran isu sosial dan
kognitif dalam rekayasa kebutuhan. Ramos dkk. (2005) berpendapat bahwa emosi
relevan dalam rekayasa kebutuhan. Penyebaran tipis pengetahuan aplikasi di antara
para spesialis yang terlibat dibahas dalam (Curtis et al., 1988). Kesulitan rekayasa
kebutuhan untuk pengembangan perangkat lunak berbasis pasar dibahas dalam
(Potts, 1993). Moynihan (2000) membahas bagaimana manajer mengatasi
ketidakpastian kebutuhan.
Dimensi objektivis-subjektivis dan ketertiban-konflik dan empat paradigma yang
dihasilkan untuk rekayasa persyaratan dibahas dalam (Hirschheim dan Klein, 1989).
Berbagai sosio-teknis, subjektivis, pendekatan untuk persyaratan elisitasi dibahas
dalam (Atkinson, 2000).
Analisis tugas dibahas dalam (Sebillotte, 1988). Teknik rekayasa persyaratan
berbasis skenario dibahas dalam (Weidenhaupt et al., 1998) dan (TrSE, 1998).
Sutcliffe dkk. (1998) menjelaskan cara membuat dan mendokumentasikan skenario
selama rekayasa persyaratan. Desain Ulang Proses Bisnis dijelaskan dalam (Keen,
1991) dan (Tapscott dan Caston, 1993). Sebuah kerangka untuk BPR diberikan
dalam (Davenport, 1993). Penelitian dalam elisitasi kebutuhan ditujukan untuk
mengembangkan teknik yang mengatasi keterbatasan kita sebagai manusia dalam
menyampaikan informasi. Gambaran awal dari jenis masalah ini diberikan dalam
(Davis, 1982). Survei dan evaluasi teknik elisitasi yang lebih baru diberikan dalam
(Goguen dan Linde, 1993). Contoh laporan pengalaman diberikan dalam
(Sommerville et al., 1994) dan (Coakes and Coakes,
2000) (pendekatan etnografi) dan (Beyer dan Holtzblatt, 1995) (analis sebagai
magang ke pengguna).
Lamsweerde (2001) memberikan gambaran yang sangat baik tentang persyaratan berorientasi
tujuan
rekayasa. Mylopoulos dkk. (2001) adalah artikel lain oleh para perintis di bidang ini. Gelap
dan Shanks (1996) dan Sommerville dan Sawyer (1997) memberikan gambaran yang baik tentang
sudut pandang dalam konteks rekayasa kebutuhan.
Leffingwell dan Widrig (2000) sepenuhnya dikhususkan untuk manajemen persyaratan. Satu
diskusi pertama tentang keterlacakan persyaratan adalah (Gotel dan Finkelstein, 1994).
Analisis desain ruang dibahas dalam (Moran dan Carroll, 1994). Pertanyaan, Pilihan,
Kriteria (QOC) berasal dari (MacLean et al., 1991). gIBIS, sistem hypertext yang dirancang
untuk menangkap keputusan desain awal, dijelaskan dalam (Conklin dan Begeman, 1988).
Model Kano dibahas dalam (Kano, 1993). Pencarian kreativitas dalam persyaratan
teknik lebih ditekankan dalam (Robertson, 2002), Austin dan Devin (2003) dan
(Maiden et al., 2004).
Morisio et al. (2002) memberikan taksonomi produk COTS. pilihan COTS
prosedur dibahas dalam (Maiden dan Ncube, 1998).
Latihan
1. Apa empat jenis aktivitas utama dalam rekayasa kebutuhan?
2. Apa yang dimaksud dengan elisitasi persyaratan?
3. Apa perbedaan antara model konseptual implisit dan eksplisit?
4. Dalam arti apa sebagian besar teknik rekayasa persyaratan Taylorian masuk
alam?
5. Jelaskan teknik elisitasi kebutuhan yang disebut analisis tugas.
6. Jelaskan teknik elisitasi kebutuhan yang disebut analisis berbasis skenario

kak.
7. Dalam keadaan apa etnografi merupakan elisitasi persyaratan yang layak

teknik?
8. Apa yang dimaksud dengan rekayasa kebutuhan berorientasi tujuan?
9. Bagaimana persyaratan yang bertentangan dapat direpresentasikan dalam sudut pandang?
10. Apa kepanjangan dari MoSCoW?
11. Mengapa perbedaan antara 'Menarik', 'Harus-menjadi' dan 'Satu Dimensi'

kategori persyaratan dalam model Kano relevan?
12. Bagaimana keberadaan komponen COTS mempengaruhi persyaratan

rekayasa pada?
13. Mengapa keterlacakan persyaratan penting?
14. Sebutkan dan diskusikan persyaratan kualitas utama untuk dokumen persyaratan.
15. Sebutkan dan diskusikan kelemahan utama penggunaan bahasa alami untuk
menentukan persyaratan.
16.�
sistem, diskusikan kemungkinan berdiri di subjektivis--objektivis dan ketertiban--

dimensi konflik. Apa argumen yang mendukung dan menentang pendirian ini?
26. �
10
Pemodelan
TUJUAN PEMBELAJARAN
�
249
Selama proyek pengembangan perangkat lunak, dan terutama selama

persyaratan rekayasa dan desain, banyak notasi pemodelan yang digunakan.
Ini berkisar dari sketsa fungsi sistem atau tata letak layar yang sangat informal,
untuk deskripsi yang sangat formal dari perilaku sistem. Notasi yang paling umum
digunakan adalah diagram kotak-dan-garis dengan semantik semi formal. Dalam bab ini kita
membahas sejumlah notasi diagram ini.
Selama pengembangan perangkat lunak, banyak komunikasi terjadi. Komunitas ini

nication didukung oleh segala macam notasi untuk menyampaikan pesannya. Sebuah sketsa
beberapa tata letak layar mungkin mendukung komunikasi antara pengguna dan kebutuhan
insinyur. Deskripsi antarmuka kelas yang jauh lebih formal dapat mendukung
komunikasi antara desainer dan pengembang.
Notasi yang paling umum digunakan untuk mendukung komunikasi antara
berbagai pemangku kepentingan yang terlibat dalam pengembangan perangkat lunak menggunakan
semacam kotak-dan-garis
diagram. Terkadang, diagram ini memiliki semantik yang sangat informal. Misalnya,
kotak dapat menunjukkan bagian dari sistem, di mana tidak jelas apa sebenarnya bagian itu.
Satu kotak mungkin menunjukkan subsistem utama, kotak lain mungkin menunjukkan set keamanan
tindakan yang diambil. Demikian juga, garis dapat menunjukkan bagian-hubungan, hubungan panggilan,
a
menggunakan relasi, dan sebagainya. Saat ditarik, semantik longgar ini mungkin bukan a
masalah. Namun keesokan harinya, kebingungan akan muncul.
Alternatifnya adalah dengan menggunakan diagram yang memang memiliki semantik yang lebih
tepat. Jika
pembaca mengetahui semantik ini, tidak perlu bingung apa sebenarnya itu
dimaksudkan. Jika semantiknya cukup tepat, diagram dapat dikenakan semua jenis
dari pemeriksaan konsistensi. Alat dapat menghasilkan diagram, membacanya, dan mungkin
bahkan menghasilkan kode yang dapat dieksekusi dari diagram. Dan akhirnya, kami dapat menautkan
diagram ke metode yang menghasilkannya, sehingga memberikan beberapa operasionalisasi
untuk proses konstruksi mereka. Misalnya, langkah-langkah dalam metode desain dapat dihubungkan
ke langkah-langkah untuk menghasilkan diagram yang sesuai. Jenis diagram yang terakhir
dibahas dalam bab 12, bersama dengan diskusi tentang desain yang sesuai
metode.
Dalam bab ini, kita membahas sejumlah notasi pemodelan semi formal. Kebanyakan
mereka menggunakan semacam diagram kotak dan garis. Beberapa menggunakan tata letak yang lebih
tekstual. Itu
diagram dan skema biasanya digambar selama rekayasa dan desain persyaratan.
Beberapa terutama melayani rekayasa persyaratan. Misalnya, diagram use case adalah
biasanya ditarik selama rekayasa persyaratan. Diagram struktur Jackson pada
sisi lain sebagian besar digunakan selama desain. Banyak notasi pemodelan melayani keduanya.
Saat ini, notasi pemodelan arus utama berasal dari UML - Unified
Bahasa Pemodelan. Namun, banyak diagram dari UML didasarkan pada atau diturunkan
dari yang sebelumnya. Dan, tentunya di aplikasi lawas, Anda mungkin menjumpai banyak
dari notasi yang lebih tua ini. Oleh karena itu, contoh dari keduanya disediakan dalam bab ini.
UML berevolusi dari beberapa analisis dan desain berorientasi objek utama
metode. Konsep orientasi objek pada gilirannya berakar pada perkembangan
250 PEMODELAN
bahasa pemrograman, terutama SIMULA-67 dan Smalltalk. Sehubungan dengan
analisis dan desain (dan analisis persyaratan), orientasi objek paling baik dilihat
dengan menyoroti perbedaan dengan metode desain yang lebih tradisional seperti
dekomposisi fungsional dan desain aliran data. Sedangkan teknik tradisional fokus
pada identifikasi fungsi bahwa sistem adalah untuk melakukan, metode berorientasi
objek fokus pada mengidentifikasi dan menghubungkan objek yang berperan dalam
sistem tersebut. Bagian 10.2 memperkenalkan sejumlah konsep yang relevan,
seperti objek, atribut, kelas, hubungan. Dengan satu atau lain cara, konsep-konsep
ini muncul dalam banyak jenis diagram UML.
10.1 Teknik Pemodelan Klasik

Kami membahas empat teknik pemodelan klasik yang telah ada cukup lama:
�
10.1. TEKNIK PEMODELAN KLASIK 251
diagram (ERD). Ada banyak varian ERM, yang berbeda dalam notasi grafis dan
ekstensi ke pendekatan asli Chen. Bahan dasar ERM diberikan pada gambar 10.1.
kesatuan objek yang dapat dibedakan dari beberapa jenis

tipe entitas jenis dari sekumpulan entitas
nilai atributatribut sepotong informasi (sebagian) yang
hubungan menggambarkan suatu entitas
jenis dari sekumpulan nilai atribut
asosiasi antara dua entitas atau lebih
Gambar 10.1 Konsep ERM dan Maknanya
Entitas adalah 'benda' yang dapat diidentifikasi secara unik. Entitas biasanya digambarkan
dalam ERD sebagai persegi panjang. Contoh entitas adalah:
– objek berwujud, seperti salinan buku, yang diidentifikasi dengan beberapa nomor;
– objek tidak berwujud, seperti buku yang diidentifikasi berdasarkan ISBN-nya,
atau anggota dari beberapa konstruksi organisasi, seperti pegawai perpustakaan
yang diidentifikasi berdasarkan nomor pegawainya.
Entitas memiliki sifat yang dikenal sebagai atribut. Misalnya, beberapa pegawai perpustakaan
mungkin memiliki nama 'Jones'. Di sini, 'Jones' adalah nilai atribut yang disebut 'nama'.
Atribut biasanya digambarkan sebagai lingkaran atau elips.
Baik entitas maupun nilai atribut memiliki a jenis. Sebagai pemodel, kita cenderung melihat sebuah
tipe
sebagai satu set properti yang dibagikan oleh instansnya. Sebagai pelaksana, kami cenderung melihat
tipe
sebagai seperangkat nilai dengan sejumlah operasi terkait. Untuk atribut 'nomor
buku pinjaman ', himpunan nilai bisa menjadi himpunan 0 .. 10 dengan operasi seperti itu
sebagai pertambahan dan pengurangan. Untuk 'salinan buku' jenis entitas, operasi kandidat
akan 'meminjam', 'mengembalikan', dan seterusnya.
Entitas terhubung melalui relasi. Misalnya, hubungan 'meminjam'
melibatkan entitas 'salinan buku' dan 'anggota perpustakaan'. Paling sering, suatu hubungan adalah
biner, yaitu menghubungkan dua entitas. Hubungan dilambangkan dengan berlian yang terkait dengan
entitas yang terlibat.
Entitas-model hubungan memberlakukan pembatasan pada kardinalitas hubungan.
Dalam bentuknya yang paling sederhana, hubungannya adalah 1--1, 1--N, atau N--M. Hubungan
'meminjam' adalah 1--N: salinan buku hanya dapat dipinjam oleh satu anggota, sedangkan a
anggota boleh meminjam lebih dari satu eksemplar buku. Dalam ERD, kardinalitas ini
kendala sering ditunjukkan dengan hiasan kecil panah yang menghubungkan entitas.
Contoh entitas--diagram hubungan diberikan pada gambar 10.2. Kardinalitas
kendala telah ditunjukkan dengan secara eksplisit menunjukkan serangkaian kemungkinan. Dengan
demikian,
252 PEMODELAN
ERD ini menyatakan bahwa satu salinan buku dapat dipinjam oleh paling banyak
satu anggota, dan seorang anggota dapat meminjam hingga 10 salinan buku.
Gambar 10.2 Diagram entitas-hubungan
Model hubungan entitas dapat diperoleh dengan menggunakan salah satu teknik
elisitasi yang telah dibahas sebelumnya. Secara khusus, analisis bentuk dan
analisis deskripsi bahasa alami sering digunakan. Karena ERM hanya menceritakan
sebagian dari cerita, teknik tambahan harus digunakan untuk memodelkan aspek
lain. Banyak teknik StructuredAnalysis, misalnya, menggabungkan ERM untuk
memodelkan aspek data. Pemodelan entitas-hubungan adalah hasil alami dari
pemodelan basis data. Awalnya, ERM dimaksudkan untuk memodelkan struktur
logis data, bukan struktur logis UoD. Dalam heuristik tentang cara mendapatkan
entitas--model hubungan yang 'baik', akar ini masih terlihat. Sebagai contoh,
beberapa heuristik menyerupai kendala normalisasi dari teori database. Ini mungkin
menjelaskan mengapa beberapa orang tidak memuji entitas - pemodelan hubungan
sebagai teknik spesifikasi persyaratan (lihat, misalnya (Davis, 1993)).
ERM masa kini memiliki banyak kesamaan dengan teknik analisis berorientasi
objek. Sebagai contoh, relasi subtipe-supertipe antara tipe entitas termasuk dalam
banyak teknik ERM. Sebaliknya, diagram kelas UML (lihat bagian 10.3.1) mencakup
banyak elemen dari ERM.
10.1.2 Mesin Negara Hingga

Pada satu titik waktu tertentu, perpustakaan kami berada di salah satu dari sejumlah
(banyak) kemungkinan keadaan. Keadaan perpustakaan dapat dinyatakan dalam
hal-hal seperti:
– koleksi judul yang tersedia,

– koleksi judul yang dipesan tetapi belum diterima,

– koleksi anggota perpustakaan,
- saldo akun dari mana akuisisi dibayar.
Setiap tindakan yang terjadi di perpustakaan, baik itu pengembalian buku atau penunjukan
karyawan baru, mengubah
S
keadaan saat ini

254 PEMODELAN
transisi negara. Pemodelan sistem dalam satu, besar dan monolitik, STD tidak
direkomendasikan. Struktur seperti itu segera menjadi berat dan sulit dipahami.
Meskipun kita dapat memodelkan sistem dalam serangkaian FSM, kita masih
memiliki masalah bagaimana mengintegrasikannya ke dalam satu model.
Jalan keluar yang mungkin adalah memungkinkan dekomposisi hierarki FSM. Ini
adalah inti dari notasi yang dikenal sebagai bagan negara. Dalam bagan negara,
kelompok negara bagian dapat dilihat sebagai entitas tunggal pada satu tingkat,
untuk disempurnakan pada tingkat abstraksi berikutnya. Dalam UML, FSM
dimodelkan dalam diagram mesin keadaan (bagian 10.3.2).
10.1.3 Diagram Aliran Data (DFD)

Metode desain aliran data berasal dari awal 1970-an dengan Yourdon dan
Constantine. Dalam bentuknya yang paling sederhana, desain aliran data hanyalah
dekomposisi fungsional sehubungan dengan aliran data. Komponen (modul) adalah
kotak hitam yang mengubah beberapa aliran masukan menjadi beberapa aliran
keluaran. Notasi utama yang digunakan adalah Data Flow Diagram (DFD).
Empat jenis entitas data dibedakan dalam diagram aliran data:
Entitas eksternal merupakan sumber atau tujuan transaksi. Entitas ini berada di
luar domain yang dipertimbangkan dalam diagram aliran data. Entitas eksternal
ditunjukkan sebagai kotak.
Proses mengubah data. Proses dilambangkan dengan lingkaran.
Arus data antara proses, entitas eksternal, dan penyimpanan data. Aliran data
ditunjukkan oleh panah. Aliran data adalah jalur yang dilalui oleh struktur data.
Penyimpanan data terletak di antara dua proses. Hal ini ditunjukkan dengan nama
penyimpan data di antara dua garis sejajar. Penyimpanan data adalah tempat di
mana struktur data disimpan hingga dibutuhkan.
Diagram aliran data dihasilkan dari proses dekomposisi top-down. Proses pada
level tertinggi hanya memiliki satu proses, yang menunjukkan 'sistem'. Selanjutnya,
diagram tingkat atas ini diuraikan lebih lanjut. Untuk contoh perpustakaan kami, ini
dapat mengarah ke diagram aliran data pada gambar 10.4. Permintaan klien
pertama kali dianalisis dalam proses berlabel 'pemrosesan awal'. Akibatnya, salah
satu 'meminjam judul' atau 'mengembalikan judul' diaktifkan. Kedua proses ini
memperbarui penyimpanan data berlabel 'administrasi katalog'. Permintaan klien
dicatat dalam 'file log' penyimpanan data. Penyimpanan data ini digunakan untuk
menghasilkan laporan manajemen.
Metode desain yang paling banyak digunakan bersama dengan diagram aliran
data dibahas di bagian 12.2.2. Di sana, kami juga akan memberikan lebih banyak
contoh diagram aliran data.
10.1.4 Kartu CRC

CRC adalah singkatan dari Kelas -- Tanggung Jawab -- Kolaborator. Kartu CRC hanya
berukuran 4” �
Gambar 10.4 Diagram aliran data untuk otomasi perpustakaan
Kolaborator. Kartu CRC dikembangkan sebagai tanggapan atas kebutuhan untuk mendokumentasikan
keputusan desain kolaboratif. Kartu CRC sangat membantu di fase awal
pengembangan perangkat lunak, untuk membantu mengidentifikasi komponen, mendiskusikan masalah
desain di berbagai
tim disipliner, dan menentukan komponen secara informal. Kartu CRC dapat disebut
alat berteknologi rendah, berbeda dengan alat berteknologi tinggi yang biasa kita gunakan. Namun
mereka
sangat berguna. Mereka juga menyenangkan untuk diajak bekerja sama dalam pertemuan bisnis kami
yang terlalu serius.
Kartu CRC tidak hanya digunakan dalam sesi desain kolaboratif. Di dalam desain
komunitas pola, misalnya, mereka digunakan untuk mendokumentasikan elemen-elemen itu
berpartisipasi dalam pola
Kata ‘kelas’ dalam CRC merupakan peninggalan sejarah. Kartu CRC dapat digunakan untuk
menggambarkan
setiap elemen desain. Namun, kami akan tetap menggunakan terminologi aslinya. Kelas
nama muncul di sudut kiri atas kartu. Daftar tanggung jawab
256 PEMODELAN
muncul di bawah nama kelas dan daftar kolaborator muncul di bagian kanan kartu.
Gambar 10.5 Kartu CRC
Gambar 10.5 memberikan contoh kartu CRC untuk sebuah komponen Reservasi
dalam sistem perpustakaan kami. Tanggung jawab utama komponen ini adalah
menjaga daftar reservasi terkini dan menangani reservasi berdasarkan FIFO.
Kolaboratornya adalah komponen katalog dan komponen sesi pengguna. Jenis
interaksi dengan komponen-komponen tersebut ditunjukkan pada gambar 10.16.
10.2 Pada Objek dan Hal Terkait

Yang penting bukanlah seberapa dekat kita memodelkan realitas saat
ini, tetapi seberapa luas dan dapat digunakan kembali perangkat lunak
kita.
(Meyer, 1996)
Dunia di sekitar kita penuh dengan benda, hidup dan mati, konkret dan
abstrak:pohon dan meja, mobil, dan kasus hukum. Menurut beberapa orang,
analisis dan desain adalah tentang memodelkan objek dunia nyata tersebut. Secara
umum, pandangan ini berasal dari sekolah desain bahasa pemrograman
Skandinavia (SIMULA-67) dan pengembangan perangkat lunak. Ini mungkin disebut
pandangan Eropa. Menurut yang lain, analisis dan desain adalah tentang
mengidentifikasi komponen yang dapat digunakan kembali dan membangun hierarki
warisannya. Pandangan yang terakhir ini, yang dapat disebut pandangan Amerika,
dengan jelas menunjukkan dirinya dalam kutipan di atas.
Lalu bagaimana adalah Sebuah Objek? Seperti yang mungkin diharapkan, ada
pandangan berbeda tentang apa yang dimaksud dengan gagasan objek. Kami
dapat membedakan sudut pandang berikut:
10.2. PADA BENDA DAN HAL-HAL TERKAIT 257
�
258 PEMODELAN
�
Hubungan di sisi lain menunjukkan saling properti, seperti makhluk karyawan

ditugaskan untuk proyek atau buku yang dipinjam oleh anggota. Di UML, ini
hubungan disebut asosiasi. Di UML, perbedaan antara atribut dan
hubungan secara formal tidak ada. Keduanya adalah properti dari suatu kelas. Itu dianggap
praktik yang baik di UML untuk memodelkan properti sederhana sebagai atribut, dan banyak lagi
sifat kompleks sebagai asosiasi.
Dalam konteks pemodelan berorientasi objek, istilah atribut terkadang digunakan
untuk menunjukkan bidang apa pun dalam struktur data yang mendasarinya. Dalam hal ini, identitas
objek
adalah atribut, status menunjukkan himpunan atribut 'struktural', dan operasinya
menunjukkan atribut 'perilaku'. Kami akan menggunakan istilah atribut untuk menunjukkan struktural
atribut. Secara kolektif, kumpulan atribut dari suatu objek ini membentuk keadaannya. Dia
termasuk sifat intrinsik, biasanya direpresentasikan sebagai nilai, serta saling menguntungkan
properti, biasanya direpresentasikan sebagai referensi ke objek lain.
Pada level bahasa pemrograman, objek yang memiliki kumpulan atribut yang sama
dikatakan milik yang sama kelas. Objek individual dari suatu kelas disebut contoh dari
kelas itu. Jadi kita mungkin satu kelas Meja, dengan contoh MyTable Dan Tabel Anda.
Instance ini memiliki atribut yang sama, dengan kemungkinan nilai yang berbeda.
Sebuah objek tidak hanya merangkumnya negara, tetapi juga miliknya perilaku, yaitu cara di mana
itu bertindak atas objek lain dan ditindaklanjuti oleh objek lain. Perilaku seorang
objek dijelaskan dalam hal jasa disediakan oleh objek tersebut. Layanan ini
dipanggil oleh mengirim pesan dari objek yang meminta layanan ke objek yang
ditindaklanjuti.
Agar kumpulan objek dapat beroperasi bersama sebagaimana dimaksud, masing-masing
objek harus dapat mengandalkan operasi yang tepat dari objek yang digunakannya
berinteraksi. Di sebuah server klien view, satu objek, klien, meminta beberapa layanan dari
objek lain, server. Saling ketergantungan ini dapat dilihat sebagai kontrak
antara objek yang terlibat. Klien tidak akan meminta lebih dari apa yang dinyatakan dalam
kontrak, sedangkan server berjanji untuk memberikan apa yang tercantum dalam kontrak. Di dalam
perspektif, layanan juga disebut sebagai tanggung jawab.
Aspek perilaku utama dari suatu objek menyangkut perubahan keadaan. Keadaan suatu
instance objek tidak statis, tetapi berubah seiring waktu: instance objek dibuat,
diperbarui, dan akhirnya dimusnahkan. Juga, informasi tertentu dapat diminta dari
Sebuah Objek. Informasi ini mungkin menyangkut keadaan instance objek, tetapi mungkin saja
juga melibatkan semacam perhitungan.
Misalnya, pelanggan perpustakaan mungkin memiliki atribut seperti Nama, Alamat,
Dan BooksOnLoan. Harus dimungkinkan untuk membuat turunan dari tipe objek
Pelanggan. Saat melakukannya, nilai yang sesuai untuk atributnya harus disediakan. Sekali
instance telah dibuat, perubahan status dimungkinkan: buku dipinjamkan dan
dikembalikan, pelanggan mengubah alamat, dll. Terakhir, instance dimusnahkan kapan
pelanggan berhenti menjadi anggota. Informasi yang diminta mungkin menyangkut hal-hal seperti itu
sebagai daftar buku yang dipinjamkan atau jumlah buku yang dipinjamkan. Yang pertama adalah bagian
dari
state yang menggambarkan pelanggan tertentu dan dapat diambil langsung dari state tersebut.
NumberofBooksOnLoan adalah layanan yang membutuhkan semacam perhitungan, untuk
260 PEMODELAN
contoh menghitung jumlah elemen di BooksOnLoan.

Kami umumnya tidak akan peduli dengan objek individu. Tujuan kami adalah
untuk mengidentifikasi dan menghubungkan tipe objek (yaitu kelas). Kita akan
sering menggunakan istilah objek untuk menunjukkan tipe objek. Salah satu
perhatian utama kami selama analisis dan desain adalah mengidentifikasi kumpulan
objek ini, bersama dengan atribut (status) dan layanan (perilaku) mereka.
Hubungan antar objek dapat dinyatakan dalam struktur klasifikasi. Jenis utama dari
relasi yang digambarkan dalam struktur tersebut tercantum dalam Gambar 10.6.
Hubungan Contoh
Spesialisasi/Generalisasi, adalah Meja adalah Mebel

bagian Utuh Meja memiliki Top table
Anggota-dari, memiliki Perpustakaan memiliki Anggota
Gambar 10.6 Jenis hubungan utama antar objek
Jika kita memiliki objek Meja Dan Kursi, kita juga dapat mendefinisikan objek
yang lebih umumMebel. Meja Dan Kursi dikatakan spesialisasi dari Mebel, ketika
Mebeladalah generalisasi dari Meja Dan Kursi. Relasi ini juga dikenal sebagai relasi
'is-a'. Relasi is-a adalah konsep terkenal dari Entity--Relationship Modeling.
Hubungan generalisasi/spesialisasi dapat diekspresikan dalam struktur hirarkis
seperti pada gambar 10.7. Dalam bentuknya yang paling umum, struktur klasifikasi
adalah grafik asiklik terarah (DAG). Banyak struktur klasifikasi dapat digambarkan
sebagai pohon, dalam hal ini setiap objek adalah turunan langsung dari satu objek
lainnya. Pada tingkat bahasa pemrograman, pewarisan tunggal sesuai dengan
struktur pohon, sementara pewarisan berganda sesuai dengan DAG.
Objek yang berbeda mungkin memiliki beberapa atribut yang sama. Baik meja
maupun kursi memiliki ketinggian, misalnya. Daripada mendefinisikan set lengkap
atribut untuk setiap objek, kita dapat mendefinisikan atribut umum pada tingkat yang
lebih tinggi dalam hierarki objek dan membiarkan turunannya mewarisi atribut
tersebut. Karena itu kami dapat mendefinisikan atribut Tinggi pada tingkatan Mebel
bukan pada tingkat masing-masing keturunannya. Jelas, ini hanyalah cara lain untuk
melihat hierarki objek. Fakta bahwa Kursi DanMeja sama-sama keturunan Mebel
sudah menunjukkan bahwa mereka berbagi properti tertentu, properti yang umum
untuk berbagai jenis furnitur. Fakta bahwa mereka adalah keturunan yang berbeda
Mebel juga menunjukkan bahwa mereka masing-masing memiliki sifat unik.
Atau, kita dapat melihat hierarki objek sebagai a jenis hirarki. Kursi DanMeja
adalah subtipe dari Mebel, seperti Kardinal adalah subtipe dari Bilangan bulat.
Dalam pandangan ini, sebuah objek adalah batasan dari objek-objek yang menjadi
spesialisasinya. Setiap kursi adalah perabot, tetapi kebalikannya umumnya tidak
benar.
262 PEMODELAN
seperti Ukuran, sehingga Meja juga dapat dilihat sebagai agregat dari jenis pertama.
Secara umum, objek majemuk terdiri dari sejumlah (referensi ke) objek lain dan
sejumlah atribut 'sederhana', yaitu nilai.
Dalam kasus Meja, bagian-dari relasi adalah bagian-dari relasi dunia nyata.
Dalam kasus Publikasi, Penerbit tidak sesuai dengan beberapa bagian dari objek
dunia nyata yang mendasarinya. Ini hanyalah bagian dari perwakilan dari objek
PublikasiKadang-kadang, perbedaan eksplisit dibuat antara bagian dunia nyata dari
relasi dan bagian representasional dari (atau komponen dari) relasi. Di UML mereka
dipanggilkomposisi Dan pengumpulan, masing-masing.
Dalam banyak metode pemodelan, bagian dari relasi menggolongkan anggota
dari relasi. Relasi anggota digunakan untuk memodelkan hubungan antara suatu
himpunan dan anggotanya. Namun demikian, terkadang berguna untuk dapat
membedakan antara sifat-sifat organisasi ini. Misalnya, bagian-dari relasi umumnya
dianggap transitif, sedangkan anggota-dari relasi tidak. Jika Buku adalah anggota
dari Perpustakaan,Dan Perpustakaan adalah anggota dari Lembaga Publik, kami
tidak ingin menyimpulkan itu Bukuadalah anggota dari Lembaga Publik.
10.3 Bahasa Pemodelan Terpadu

Bahasa Pemodelan Terpadu berakar pada analisis berorientasi objek dan metode
desain tahun 1980-an. Beberapa pemain kunci di bidang ini (Grady Booch, John
Rumbaugh dan Ivar Jacobson) bekerja untuk Rasional, dan mulai menyatukan
metode dan notasi mereka. Ini menghasilkan versi pertama UML. Pada tahap
selanjutnya, OMG --- Object Management Group, sebuah konsorsium terbuka
perusahaan --- mengambil alih. Mereka sekarang mengontrol aktivitas seputar UML,
dan mengadopsinya sebagai salah satu standar mereka. Versi saat ini dikenal
sebagai UML 2. UML sejauh ini merupakan notasi yang paling banyak digunakan
untuk keperluan rekayasa dan desain.
13 diagram UML 2 tercantum dalam gambar 10.8. Beberapa diagram, seperti
diagram kelas dan diagram mesin negara, telah ada sejak awal orientasi objek.
Lainnya lebih baru. Misalnya, diagram struktur gabungan dan diagram waktu
diperkenalkan di UML 2. Beberapa diagram memberikan tampilan statis. Misalnya,
diagram kelas menunjukkan struktur statis suatu sistem. Diagram lain memberikan
pandangan dinamis atau perilaku, yaitu menunjukkan apa yang terjadi ketika sistem
dijalankan. Misalnya, diagram urutan menunjukkan pesan mana yang dipertukarkan
antar instance kelas. Pada Gambar 10.8, diagram statis ditandai dengan S, dan
diagram dinamis ditandai dengan D. Pada subbagian berikutnya, kita akan
membahas diagram UML yang paling penting.
10.3.1 Diagram Kelas

Diagram kelas menggambarkan struktur statis dari suatu sistem. Diagram kelas adalah
grafik di mana node adalah objek (kelas) dan ujung-ujungnya adalah hubungan antara
10.3. BAHASA PEMODELAN TERPADU 263
Diagram Keterangan
Aktivitas (D) Untuk memodelkan proses bisnis, alur kerja, prosedural

logika. Mirip dengan diagram alur, tetapi diagram aktivitas
mendukung paralelisme, seperti di jaring Petri
Kelas (S) Untuk memodelkan kelas, fitur dan hubungannya.
Lihat bagian 10.3.1
Komunikasi (D) Untuk memodelkan aliran pesan antar instance
kelas. Sangat mirip dengan sequence diagram. Lihat bagian
10.3.4
Komponen (S) Untuk memodelkan sekumpulan komponen dan keterkaitannya
hubungan (melalui antarmuka). Lihat bagian 10.3.5
Struktur komposit Untuk memodelkan struktur dinamis internal kelas
Penyebaran Untuk memodelkan tata letak fisik, yaitu penugasan
dari elemen sistem ke elemen perangkat keras
Ikhtisar interaksi (S) Menggabungkan diagram aktivitas dan diagram urutan
Objek (S) Untuk memodelkan objek dan hubungannya di beberapa
titik waktu; juga dikenal sebagai diagram contoh
Paket (S) Untuk memodelkan pengelompokan elemen ke dalam paket
Urutan (D) Untuk memodelkan urutan pesan
dipertukarkan antara contoh kelas. Lihat bagian 10.3.3
Mesin negara (D) Untuk memodelkan keadaan di mana suatu objek dapat
berada, dan
transisi antar negara. Lihat bagian 10.3.2
Waktu (D) Untuk memodelkan perubahan status objek dari waktu ke
waktu
Gunakan kasus (D) Untuk memodelkan kasus penggunaan. Lihat bagian 10.3.6
Gambar 10.8 Jenis diagram UML 2
objek. Dengan mendekorasi ujung-ujungnya, banyak jenis hubungan yang bisa dimodelkan. Ini
hubungan jatuh ke dalam dua kelas: generalisasi Dan asosiasi.
Contoh paling umum dari diagram kelas tipe generalisasi adalah diagram
menggambarkan subclass--superclass hirarki. Gambar 10.7 adalah contoh kelas semacam itu
diagram. Kelas dilambangkan dengan persegi panjang yang memiliki tiga kompartemen. Ini
kompartemen berisi, dari atas ke bawah:
- nama kelas,
– daftar atribut kelas, dan
– daftar operasi kelas.

264 PEMODELAN
UML memungkinkan beberapa variasi dalam notasinya. Misalnya, kita dapat
menggambarkan kelas sebagai persegi panjang dengan satu kompartemen saja,
hanya dengan memberi nama kelas. Menambahkan sedikit lebih detail, kita dapat
menggambarkan kelas sebagai persegi panjang yang memiliki dua kompartemen, di
mana yang kedua mencirikan tanggung jawab kelas tersebut, yaitu, apa yang
seharusnya dilakukan, sebagai semacam komentar sebaris. Gambar 10.9
memberikan representasi tiga kompartemen di mana sejumlah detail tingkat analisis
telah ditambahkan. Kami bahkan dapat memperluas notasi lebih jauh dan
menambahkan detail tingkat implementasi, seperti apakah atribut dan operasi
bersifat publik atau pribadi. Kita mungkin menganggap representasi yang berbeda
ini sebagai pandangan berbeda dari elemen model yang sama. Kami mungkin
membayangkan dukungan alat yang memungkinkan pengguna beralih dari satu
representasi ke representasi lainnya, menekan atau menambahkan detail sesuai
kebutuhan.
Publikasi
isbn: String
penerbit: String
arsip()
Itu atribut dari kelas menunjukkan properti dari kelas itu. Misalnya., penerbit adalah properti
dari Publikasi. Di samping atribut, UML memiliki cara lain untuk menunjukkan properti
sebuah kelas, mis. asosiasi. Asosiasi UML digambarkan sebagai garis padat yang menghubungkan dua
kelas. Baris ini dapat dihiasi dengan berbagai mesin terbang dan informasi tekstual
memberikan rincian lebih lanjut dari hubungan tersebut. Sebuah asosiasi sederhana antara
perpustakaan
dan kliennya digambarkan pada gambar 10.10a. Nama asosiasi (opsional) adalah
dicetak di dekat jalan. Segitiga padat menunjukkan arah di mana kata kerja berada
untuk dibaca. Perhatikan bahwa asosiasi bersifat dua arah: klien adalah anggota perpustakaan,
dan perpustakaan memiliki anggota. Perhiasan lebih lanjut dapat ditambahkan untuk menunjukkan
properti
asosiasi. Pada gambar 10.10a kami telah menambahkan informasi multiplisitas: seorang klien bisa
menjadi anggota dari satu atau lebih perpustakaan, sedangkan perpustakaan mungkin memiliki nol atau
lebih klien.
Sebenarnya, tidak ada perbedaan antara atribut dan asosiasi.
Pada gambar 10.10b, kami telah menggambarkan Klien sebagai atribut dari Perpustakaan. Biasanya,
sederhana
properti seperti angka dan tanggal dimodelkan sebagai atribut, sementara lebih signifikan
konsep dimodelkan sebagai asosiasi.
Asosiasi seperti Anggota dari juga memiliki properti kelas. Misalnya, ini
asosiasi memiliki atribut, mis. Tanda Anggota, dan operasi, seperti Menjadi Anggota
Dan Berhenti Menjadi Anggota. Sebagai alternatif, kita dapat mengatakan kelas itu Keanggotaan
memiliki
sifat asosiasi. Di UML, elemen model ini disebut kelas asosiasi. Dia
dapat digambarkan sebagai simbol kelas yang dilampirkan oleh garis putus-putus ke jalur asosiasi,
seperti pada gambar 10.10c. Kami bahkan dapat mempromosikan kelas asosiasi ke kelas penuh, seperti
di figuUML10.10d. Perhatikan bahwa multiplisitas telah berpindah. Keanggotaan (dari
klien) dapat ke satu atau lebih perpustakaan, sedangkan keanggotaan (perpustakaan)
berhubungan dengan nol atau lebih klien.
Bagian dari relasi disebut pengumpulan atau komposisi di UML. Secara ag-
ation, objek dapat menjadi bagian dari lebih dari satu objek lainnya. Misalnya, jika perpustakaan kita
memelihara daftar bacaan wajib untuk mata kuliah tertentu, maka buku yang diberikan mungkin a
bagian dari lebih dari satu daftar bacaan wajib. Agregasi dilambangkan dengan terbuka
mengajukan berlian sebagai perhiasan peran asosiasi. Komposisi adalah gagasan yang kuat tentang
agregasi, di mana objek bagian mungkin hanya dimiliki oleh satu objek utuh. Dengan
komposisi, bagian-bagian diharapkan hidup dan mati bersama keseluruhan. Jika meja adalah
terdiri dari empat kaki dan meja, meja memiliki bagian-bagian ini. Mereka tidak bisa menjadi bagian
dari meja lain pada waktu yang sama. Komposisi dilambangkan dengan intan berisi padat sebagai
perhiasan peran asosiasi, seperti pada gambar 10.11a. Gambar 10.11a menunjukkan a Buku dengan
bagian judul, pengarang, Dan isbn. Sebuah buku memiliki satu judul dan satu ISBN, jadi bagian-bagian
ini memiliki
multiplisitas 1. Kami berasumsi di sini bahwa sebuah buku dapat memiliki hingga tiga penulis, jadi bagian
itu
memiliki kelipatan 1..3. Di seluruh akhir komposisi, multiplisitasnya adalah 1
atau 0..1. Bagian dari hubungan ini adalah hubungan antara kelas dan kelas
atributnya. Oleh karena itu, notasi alternatif untuk bagian-hubungan ini terdiri dari
dua bagian atas diagram untuk kelas, seperti pada gambar 10.11b.
Di samping generalisasi dan asosiasi, ada banyak cara lain
elemen dari diagram kelas dapat saling bergantung satu sama lain. Misalnya, satu kelas mungkin
memanggil operasi dari kelas lain, membuat instance dari kelas lain, dan seterusnya. Seperti
266 PEMODELAN
A
A) d
a
l
a
h
-
a
n
g
B) g
o
t
a
-
d
a
r
i
C) 1
.
.
*
Perpustakaan
*
D) Klien
Perpustakaan
K
Adal
ah-a
nggo
ta-da
ri1..
*
Perpustakaan
*
Gambar 10.11 Diagram kelas UML: komposisi sebagai (a) hiasan peran asosiasi dan
(b) diagram kelas sederhana
Kelas abstrak Daftar mungkin memiliki operasi abstrak juga, seperti mendapatkan, yang dapat
hanya dibuat konkrit pada tingkat subkelas. Pada tingkatan Daftar, kita kemudian hanya
nyatakan bahwa setiap subkelasnya akan menyediakan implementasi dari mendapatkan. Di
perpustakaan kami
contoh, kita bisa ditunjuk Publikasi sebagai kelas abstrak. Kelas abstrak
ditunjukkan dengan mencetak nama mereka dalam huruf miring.
Sebuah antarmuka adalah kelas yang semua fiturnya abstrak. Itu tidak memiliki implementasi.
Antarmuka adalah sarana yang berguna untuk membagi himpunan properti kelas menjadi himpunan
bagian, di
kasus kelas lain hanya membutuhkan akses ke himpunan bagian dari properti tersebut. Misalnya, kelas
Publikasi mungkin memiliki properti yang dapat diakses oleh pelanggan perpustakaan, seperti
serta properti yang hanya untuk penggunaan internal, seperti harganya, siapa yang berwenang
akuisisi, dan sebagainya. Kami kemudian dapat mendefinisikan dua antarmuka untuk Publikasi itu
dibuat tersedia untuk berbagai kelas lain dalam sistem. Publikasi Kemudian menyediakan
antarmuka yang berbeda untuk kelas klien yang berbeda, yang pada gilirannya memerlukan antarmuka.
Antarmuka
ditandai dengan kata kunci �
268 PEMODELAN
Karyawan
Publikasi
Klien
Gambar 10.12 UML class diagram: interfaces
Biasanya, model finite state machine dan diagram transisi keadaan terkaitnya (lihat
bagian 10.1.2) diperluas dalam beberapa cara saat digunakan dalam memodelkan
perilaku objek dari waktu ke waktu:
�
peristiwa memicu transisi. Saat seseorang menjadi anggota perpustakaan, ini
memicu transisi awal; ketika dia meminjam buku, itu memicu transisi dari
suatu keadaan, katakanlah, telah-meminjam-7-bukuke sebuah negara bagian
telah-meminjam-8-buku.Jika model memiliki variabel lokal, transisi keadaan
terakhir dapat mengakibatkan perubahan nilai variabel lokal tersebut. Pada
gambar 10.13, event input dinotasikan sebagai string yang melabeli transisi
state (seperti Awal Dan Meminjam).
Metode pemodelan yang berbeda memiliki cara yang berbeda untuk
menangani tindakan keluaran. Terkadang, tindakan keluaran dikaitkan dengan
transisi (ini dikenal sebagai mesin Mealy), terkadang tindakan keluaran
dikaitkan dengan keadaan (mesin Moore). Dalam kasus terakhir, aksi output
dilakukan segera setelah state dimasukkan. Secara formal, mesin Mealy dan
mesin Moore memiliki kekuatan ekspresif yang sama.
�
270 PEMODELAN
270
Seperti halnya diagram kelas, UML memiliki notasi yang kaya untuk diagram keadaan.
Kami akan mengilustrasikan bahan utama melalui beberapa contoh; lihat juga gambar 10.13
dan 10.14.
Keadaan adalah beberapa kondisi dalam kehidupan suatu objek. Itu ditampilkan sebagai
persegi panjang dengan sudut membulat. Keadaan awal (pseudo) ditampilkan sebagai
lingkaran kecil berisi. Kondisi awal ini hanyalah perangkat notasi; objek tidak bisa dalam
keadaan seperti itu. Ini menunjukkan transisi ke keadaan 'nyata' pertama. Keadaan akhir
(pseudo) ditampilkan sebagai lingkaran kecil yang mengelilingi lingkaran kecil berisi. Keadaan
akhir ini juga merupakan perangkat notasi. Transisi ditunjukkan sebagai panah padat dari satu
keadaan ke keadaan lainnya. Ketika perubahan keadaan terjadi, transisi itu dikatakan 'api'.
Transisi memiliki label yang terdiri dari tiga bagian. Bentuk umumnya adalah trigger-signature
[penjaga]/aktivitas. Ketiga bagian itu opsional. Tanda tangan pemicu menunjukkan peristiwa
yang memicu transaksi, seperti peminjaman buku. Acara tersebut mungkin dijaga oleh ekspresi
Boolean. Misalnya, transisi dari keadaan adalah anggota ke membersihkan pada gambar 10.13
dijaga oleh ekspresi
' N
Gambar 10.14 UML state diagram: object Buku, (a) tampilan global dan (b) diperluas
melihat
bagian 10.3.4. Dalam domain telekomunikasi dikenal sequence diagram

sebagai Message Sequence Charts dan menyediakan notasi standar untuk mendesain dan
menentukan protokol. Diagram urutan juga digunakan dalam pola desain
komunitas, untuk menggambarkan secara grafis interaksi antara dua objek atau lebih
berpartisipasi dalam pola desain.
Dalam sequence diagram, dimensi horizontal menunjukkan berbagai objek yang
berpartisipasi dalam interaksi. Objek ditampilkan sebagai garis putus-putus vertikal, 'garis hidup'.
Periode di mana objek aktif (dalam urutan pesan tertentu
digambarkan) ditampilkan sebagai persegi panjang tipis. Jika perbedaan antara aktif dan tidak aktif
tidak penting, seluruh lifeline dapat ditampilkan sebagai aktivasi, seperti pada gambar 10.15.
Urutan di mana objek ditampilkan tidak ada artinya.
Dimensi vertikal menunjukkan urutan waktu pesan. Biasanya, hanya
itu memesan di mana pesan ditampilkan membawa makna. Untuk aplikasi waktu nyata,
sumbu waktu dapat menunjukkan nilai numerik aktual.
Pesan ditampilkan sebagai busur berlabel dari satu objek ke objek lainnya. Vertikal
272 PEMODELAN
susunan pesan menunjukkan urutannya. Label juga dapat berisi nomor urut, yang
sangat berguna untuk menunjukkan konkurensi. Pesan juga dapat diberi label
dengan penjaga, ekspresi boolean yang menyatakan kondisi yang harus dipenuhi
agar pesan dapat dikirim.
pengguna katalog reservas

awal
1: l naik
juga
2: ya
3: [
jud
ul
6: b
6: r
dari luar, sumber yang tidak diketahui. Pesan ini disebut dengan menemukan pesan. Itu
pengguna kemudian mengirimkan permintaan ke katalog untuk mencari judul tertentu. Katalog bereaksi
dengan mengirimkan data tentang judul itu ke pengguna. Jika judul tidak tersedia (ini ditunjukkan
oleh ekspresi boolean, penjaga, di dalam tanda kurung siku), permintaan untuk mencadangkannya
judul dikirim ke objek yang menangani reservasi. Beberapa waktu kemudian, judul itu akan
menjadi tersedia lagi dan reservasi akan diberitahu. Objek reservasi
kemudian akan mengirim pesan ke katalog untuk menyimpan buku itu dan akan memberi tahu pengguna
bahwa judulnya sekarang tersedia. Urutan kedua pesan itu tidak relevan, jadi
mereka membawa nomor urut yang sama. Pengguna sekarang dapat meminjam judul dan
reservasi terkait akan dihapus.
Sekali lagi, UML memiliki kosa kata notasi yang kaya untuk diagram urutan. Itu mungkin
untuk membedakan pengiriman pesan asinkron dari pengiriman pesan sinkron, ke
menunjukkan iterasi, untuk menunjukkan pembuatan dan penghancuran objek, dan seterusnya. Itu
Namun tujuan utama dari sequence diagram tetap sama: mudah dibaca
ikhtisar penyampaian pesan dalam urutan interaksi tertentu.
10.3.4 Diagram Komunikasi

Diagram komunikasi adalah cara lain untuk menunjukkan satu kemungkinan
skenario untuk interaksi antara sejumlah objek terkait. Diagram komunikasi adalah
grafik terarah di mana node menunjukkan entitas dan ujungnya menunjukkan
komunikasi antara entitas tersebut.
awal
6: hapus res
6:
meminjam
judul
274 PEMODELAN
Gambar 10.16 menunjukkan urutan interaksi yang sama dengan skenario yang
digambarkan pada sequence diagram pada gambar 10.15. Diagram komunikasi
menekankan objek dan hubungannya yang relevan dengan interaksi tertentu. Untuk
memberikan detail lebih lanjut tentang interaksi, atribut yang relevan dapat
ditampilkan di dalam node (dengan menambahkan kompartemen lain seperti dalam
diagram kelas) dan atribut ini dapat dimasukkan ke dalam label tepi juga.
Sequence diagram menekankan urutan pesan. Dalam diagram urutan, nomor
urut bersifat opsional; dalam diagram komunikasi, mereka wajibkarena pemesanan
tidak menunjukkan dirinya secara grafis.
10.3.5 Diagram Komponen

Saat merancang sistem yang lebih besar, mungkin berguna untuk dapat
mengidentifikasi entitas yang lebih besar dari satu kelas. Hal tersebut dapat
dilakukan dalam a diagram komponen. Dalam deskripsi arsitektur perangkat lunak,
misalnya, diagram komponen adalah cara yang baik untuk menggambarkan
tampilan modul dari suatu sistem (lihat bagian 11.3).
�
Intinya, diagram komponen adalah diagram kelas dengan stereotip
10.3.6 Kasus Penggunaan

Salah satu teknik elisitasi persyaratan yang mungkin adalah analisis berbasis skenario; Lihat juga
bab 9. Skenario adalah cerita yang menceritakan bagaimana contoh tugas tertentu dijalankan.
Seringkali, skenario yang berbeda merupakan variasi dari tema yang sama. Misalnya, satu skenario
mungkin menggambarkan peminjaman biasa sebuah buku, yang lain mungkin menggambarkan
peminjaman
buku bila masih ada denda yang belum dilunasi, dan sebagainya. Satu set skenario memiliki
tujuan pengguna yang sama, dalam hal ini meminjam, disebut a kasus penggunaan.
Sebuah use case dapat didokumentasikan dengan berbagai cara: sebagai teks naratif, secara formal
menggunakan
pra dan pascakondisi, misalnya, atau secara grafis seperti pada diagram transisi keadaan.
Itu Gunakan diagram kasus memberikan ikhtisar dari serangkaian kasus penggunaan. Setiap kasus
penggunaan
ditampilkan sebagai elips dengan nama use case. Kasus penggunaan dilampirkan oleh a
persegi panjang yang menunjukkan batas sistem. Seorang aktor yang memprakarsai atau berpartisipasi
dalam a
skenario ditampilkan sebagai figur tongkat dengan nama aktor di bawah ini. Gambar 10.18
menunjukkan bagian dari diagram kasus penggunaan untuk sistem perpustakaan kami. Meminjam buku
melibatkan
dua aktor: klien dan karyawan perpustakaan. Banyak kasus penggunaan lain akan terlibat
kedua aktor itu juga. Pemesanan buku baru memerlukan persetujuan dari pengawas,
seperti halnya pengiriman uang denda.
Gambar 10.18 Diagram use case UML

276 PEMODELAN
10.4 Ringkasan
Selama persyaratan rekayasa dan desain, berbagai notasi pemodelan sedang
diterapkan. Sebagian besar menggunakan semacam diagram kotak dan garis.
Notasi pemodelan arus utama hari ini berasal dari UML --- Bahasa Pemodelan
Terpadu. Banyak diagram UML pada gilirannya didasarkan pada atau berasal dari
jenis diagram sebelumnya. Dalam bab ini, kita membahas pilihan notasi pemodelan
klasik serta jenis diagram UML utama.
Notasi pemodelan klasik yang dibahas adalah:
�
2. Definisikan istilah-istilah berikut: objek, status, atribut, pesan, dan pewarisan.
3. Jelaskan perbedaan antara hubungan spesialisasi-generalisasi dan

hubungan seluruh-bagian.
4. Jelaskan perbedaan antara diagram kelas dan diagram mesin negara.
5. Jelaskan perbedaan antara sequence diagram dan komunikasi

diagram.
6. Jelaskan perbedaan antara diagram kelas dan diagram komponen.
7. Untuk apa kartu CRC dan skenario kasus penggunaan digunakan dalam berorientasi objek
analisis dan desain?
8. Dalam hal apa diagram status UML berbeda dari transisi status
diagram?
9.~
11
Arsitektur Perangkat Lunak
TUJUAN PEMBELAJARAN
�
279
Arsitektur perangkat lunak menyangkut struktur berskala besar dari sistem perangkat
lunak.
Struktur skala besar ini mencerminkan keputusan desain awal yang penting. Ini
proses keputusan melibatkan negosiasi dan keseimbangan fungsional dan kualitas
persyaratan di satu sisi, dan kemungkinan solusi di sisi lain. Perangkat lunak
arsitektur bukanlah fase yang secara ketat mengikuti rekayasa persyaratan, tetapi
keduanya terjalin. Dalam bab ini, kita membahas bagaimana merancang,
mendokumentasikan
dan mengevaluasi arsitektur perangkat lunak.
Desain yang baik adalah kunci dari produk yang sukses. Hampir 2000 tahun yang lalu,
Arsitek Romawi Vitruvius mencatat apa yang membuat sebuah desain bagus: daya tahan (ketegasan),
kegunaan (utilitas), dan pesona (kecantikan). Persyaratan kualitas ini masih berlaku, untuk
bangunan serta sistem perangkat lunak. Sistem yang dirancang dengan baik mudah diimplementasikan
dimengerti dan dapat diandalkan, dan memungkinkan untuk kelancaran evolusi. Sistem yang dirancang
dengan buruk
mungkin berhasil pada awalnya, tetapi sulit dipertahankan, sulit diuji, dan tidak dapat diandalkan.
Selama fase desain, sistem didekomposisi menjadi sejumlah interaksi
komponen. Dekomposisi tingkat atas dari suatu sistem menjadi komponen-komponen utama
bersama dengan karakterisasi tentang bagaimana komponen ini berinteraksi, disebut its
arsitektur perangkat lunak. Dilihat dengan cara ini, arsitektur perangkat lunak identik dengan
desain global. Namun, ada lebih banyak arsitektur perangkat lunak daripada sekadar global
desain.
Arsitektur perangkat lunak melayani tiga tujuan utama:
�
280 ARSITEKTUR PERANGKAT LUNAK
�
281
Desain tradisional melihat ke dalam: diberi serangkaian persyaratan, bagaimana kita bisa
menghasilkan sistem yang memenuhi persyaratan tersebut. Arsitektur perangkat lunak memiliki tampilan
luar
fokus juga: memperhitungkan bagaimana sistem cocok dengan lingkungannya. Perangkat lunak
arsitek termasuk negosiasi dan keseimbangan persyaratan fungsional dan kualitas
di satu sisi, dan kemungkinan solusi di sisi lain. Ini dijabarkan lebih lanjut
di bagian 11.1. Persyaratan penyeimbang juga mengharuskan perangkat lunak kandidat
arsitektur dinilai. Ini adalah bentuk pengujian, dibahas di bagian 11.5.
Salah satu definisi awal arsitektur perangkat lunak adalah (Shaw et al., 1995):
Arsitektur sistem perangkat lunak mendefinisikan sistem itu dalam hal

komponen komputasi dan interaksi antar komponen tersebut.
Definisi yang lebih baru adalah (Bass et al., 2003):

Arsitektur perangkat lunak dari suatu program atau sistem komputasi
adalah struktur atau struktur sistem, yang terdiri dari elemen perangkat
lunak, properti yang terlihat secara eksternal dari elemen tersebut, dan
hubungan di antara mereka.
Definisi terakhir mencerminkan, antara lain, wawasan bahwa mungkin ada lebih dari
satu struktur yang menarik. Dalam konstruksi rumah, kami juga menggunakan gambar yang berbeda:
satu untuk kabel listrik, satu untuk suplai air, dll. Gambar-gambar ini mencerminkan
struktur yang berbeda yang semuanya merupakan bagian dari keseluruhan arsitektur yang sama. Kami
umumnya
amati arsitektur melalui salah satu tampilan yang lebih spesifik ini. Hal yang sama berlaku
untuk arsitektur perangkat lunak. Hal ini dijelaskan lebih lanjut di bagian 11.3.
Dalam arsitektur perangkat lunak, struktur global dari sistem telah diputuskan
pada. Struktur global ini menangkap keputusan desain utama awal. Apakah a
keputusan desain besar atau tidak benar-benar hanya dapat dipastikan dengan melihat ke belakang,
kapan
kami mencoba untuk mengubah sistem. Hanya dengan begitu itu akan menunjukkan keputusan mana
yang sebenarnya
penting. Apriori, seringkali sama sekali tidak jelas apakah dan mengapa ada lebih banyak keputusan
desain
penting dari yang lain (Fowler, 2003). Misalnya, kami dapat memutuskan untuk memisahkan
antarmuka pengguna dari bagian pemrosesan dan menyimpan data tentang buku dalam file datar di
kami
sistem perpustakaan. Kedua keputusan bisa menjadi penting, tetapi tidak perlu. Memisahkan
antarmuka pengguna dari bagian pemrosesan umumnya dianggap desain yang bagus. Jika, pada a
tahap selanjutnya, perubahan terjadi di kedua bagian, kami akan senang telah membuat keputusan ini.
Jika
tidak ada perubahan yang terjadi, keputusan itu tidak terlalu penting. Memutuskan untuk
menggunakan file datar untuk menyimpan data di sistem perpustakaan kami mungkin ternyata penting
jika
perpustakaan kami tumbuh dan kami terpaksa beralih ke penyimpanan data basis data. Tapi lagi,
jika tidak ada perubahan seperti itu, keputusannya juga tidak begitu penting.
Dilihat dengan cara ini, proses desain arsitektur adalah tentang membuat yang penting
keputusan desain. Selanjutnya, keputusan desain yang penting ini perlu didokumentasikan.
Baik proses pengambilan keputusan arsitektur maupun dokumentasinya untuk nanti
digunakan dibahas dalam bagian 11.2.
Bidang penelitian yang sangat aktif saat ini ditujukan untuk mengidentifikasi dan mendeskripsikan
komponen pada tingkat abstraksi yang lebih tinggi, yaitu di atas tingkat modul atau
tipe data abstrak. Abstraksi tingkat tinggi ini dikenal sebagai pola desain Dangaya
arsitektur perangkat lunak (atau pola arsitektur).
Bagian dari pekerjaan dalam arsitektur perangkat lunak ditujukan untuk
mengkarakterisasi dan mengklasifikasikan gaya arsitektur perangkat lunak ini, serta
mengembangkan notasi dan alat pendukung yang sesuai. Tujuan utamanya adalah
abstraksi yang dihasilkan menjadi bagian dari kosa kata insinyur perangkat lunak,
seperti tipe data abstrak yang sudah menjadi bagian dari kosa kata itu. Bagian 11.4
memberikan gambaran tentang isu-isu utama yang terlibat dalam gaya arsitektur
perangkat lunak. Pola desain dibahas lebih lanjut di Bab 12. Pekerjaan hari ini
dalam arsitektur perangkat lunak memiliki cakupan yang luas. Hampir semua topik
dalam rekayasa perangkat lunak sedang dipikirkan kembali dalam istilah arsitektur.
Pembahasan pada bab ini difokuskan pada bagaimana merancang, menamai,
mendokumentasikan, dan menilai arsitektur perangkat lunak.
11.1 Arsitektur Perangkat Lunak

dan Siklus Hidup Perangkat
Lunak
Jika arsitektur perangkat lunak hanyalah desain global, kami akan menjual anggur
lama di botol baru. Fase desain kemudian dibagi menjadi dua subfase: arsitektur,
desain global, dan desain detail. Metode yang digunakan dalam dua subfase ini
mungkin berbeda, tetapi keduanya pada dasarnya bermuara pada proses
dekomposisi, mengambil serangkaian persyaratan sebagai titik awalnya. Kedua fase
desain kemudian melihat ke dalam: mulai dari serangkaian persyaratan, dapatkan
sistem yang memenuhi persyaratan tersebut. Namun, fase arsitektur perangkat
lunak yang 'tepat' memiliki fokus ke luar juga. Ini mencakup negosiasi dan
penyeimbangan persyaratan fungsional dan kualitas di satu sisi, dan kemungkinan
solusi di sisi lain. Ini berarti rekayasa persyaratan dan arsitektur perangkat lunak
bukanlah fase-fase berikutnya yang kurang lebih dipisahkan secara ketat, melainkan
saling terkait erat. Serangkaian persyaratan fungsional dan kualitas awal adalah titik
awal untuk mengembangkan arsitektur awal. Arsitektur awal ini menghasilkan
sejumlah isu yang memerlukan diskusi lebih lanjut dengan para pemangku
kepentingan. Misalnya, solusi yang dipertimbangkan mungkin terlalu mahal,
integrasi dengan sistem yang sudah ada mungkin rumit, pemeliharaan mungkin
menjadi masalah karena kekurangan staf dengan keahlian tertentu, atau
persyaratan kinerja tidak dapat dipenuhi. Wawasan ini mengarah pada diskusi lebih
lanjut dengan pemangku kepentingan, serangkaian persyaratan yang direvisi, dan
arsitektur yang direvisi. Proses iteratif ini berlanjut sampai tercapai kesepakatan.
Hanya dengan demikian desain dan implementasi terperinci akan dilanjutkan.
Perbedaan antara kedua paradigma ini diilustrasikan pada Gambar 11.1.
Dengan demikian kami melihat perbedaan penting antara model proses
tradisional tanpa perhatian khusus pada arsitektur perangkat lunak, dan model
proses yang memperhatikan arsitektur perangkat lunak:
�
11.2. DESAIN ARSITEKTUR 283
pemangku kepentingan pemangku kepentingan

(sedikit) (banyak)
persyaratan kualitas persyaratan kualitas
Arsitektur
perjanjian
perjanjian
perkembangan
perkembangan)
(A) (B)
Gambar 11.1 Siklus hidup perangkat lunak tanpa (a) dan dengan (b) perhatian eksplisit terhadap
perangkat lunak
Arsitektur
dan persyaratan mutu. Hanya ketika set gabungan fungsional dan

persyaratan kualitas disepakati, apakah pengembangan akan dilanjutkan.
�
buktinya mungkin sangat berbeda. Hal yang sama berlaku untuk desain perangkat
lunak. Kita tidak boleh mencampuradukkan hasil dari proses desain dengan proses
itu sendiri. Hasil dari proses desain adalah 'rekonstruksi rasional' dari proses itu.
(Perhatikan bahwa kami membuat pernyataan yang sama sehubungan dengan hasil
dari proses rekayasa persyaratan.)
Selama desain, sistem diuraikan menjadi bagian-bagian yang masing-masing
memiliki kompleksitas yang lebih rendah daripada sistem secara keseluruhan,
sementara bagian-bagian tersebut bersama-sama menyelesaikan masalah
pengguna. Masalah desain sekarang dapat dirumuskan sebagai berikut: bagaimana
menentukan dekomposisi ini. Sebenarnya tidak ada metode universal untuk ini.
Proses desain adalah proses yang kreatif, dan kualitas serta keahlian para desainer
merupakan penentu penting bagi keberhasilannya. Namun, selama bertahun-tahun,
sejumlah ide dan pedoman telah muncul yang dapat membantu kita dalam
merancang perangkat lunak. Ini telah menghasilkan sejumlah besar metode desain,
yang merupakan topik bab 12.
Dalam nada yang sama, metode desain arsitektur telah dikembangkan. Sebuah
contoh yang baik di sini adalah Attribute Driven Design (ADD), dijelaskan dalam
(Bass et al., 2003). Masukan untuk proses ADD adalah persyaratan, dirumuskan
sebagai satu set skenario atribut kualitas yang diprioritaskan. Skenario atribut
kualitas adalah skenario yang diketahui dari rekayasa persyaratan, tetapi
deskripsinya secara eksplisit menangkap informasi kualitas; lihat juga bagian 6.3.
ADD digambarkan sebagai proses dekomposisi topdown. Dalam setiap iterasi,
satu atau beberapa komponen dipilih untuk dekomposisi lebih lanjut. Pada iterasi
pertama, hanya ada satu komponen, 'sistem'. Dari kumpulan skenario atribut
kualitas, atribut kualitas penting dipilih yang akan ditangani dalam langkah
penyempurnaan saat ini. Misalnya, dalam sistem perpustakaan kami, kami mungkin
telah memutuskan dekomposisi pertama dari sistem menjadi tiga lapisan: lapisan
presentasi, lapisan logika bisnis, dan lapisan data. Pada langkah ADD berikutnya,
kita dapat memutuskan untuk mendekomposisi lapisan presentasi, dan memilih
kegunaan sebagai atribut kualitas yang mendorong dekomposisi ini. Sebuah pola
kemudian dipilih yang memenuhi atribut kualitas. Misalnya, pola validasi data
(Folmer et al., 2003) dapat diterapkan untuk memverifikasi apakah item data telah
dimasukkan dengan benar. Akhirnya, kumpulan skenario atribut kualitas diverifikasi
dan disempurnakan, untuk mempersiapkan iterasi berikutnya.
ADD memberikan sedikit panduan untuk urutan yang tepat dan jenis langkah
penyempurnaan. Ini sangat tergantung pada keahlian arsitek. Dukungan agak global
yang sama diberikan oleh metode desain arsitektur lainnya, seperti yang dibahas
oleh Hofmeister et al. (2007). Alur kerja global yang umum untuk metode ini
digambarkan pada Gambar 11.2. Di pusat, the jaminan simpanan digambarkan.
Backlog berisi daftar masalah yang harus ditangani, masalah terbuka, ide yang
masih harus diselidiki, dan sebagainya. Nama ini berasal dari Scrum, sebuah
metode tangkas (Schwaber dan Beedle, 2002). Di sana, backlog mendorong proyek.
Dalam proyek desain (arsitektur), gagasan backlog biasanya tidak direpresentasikan
secara eksplisit. Namun, itu selalu ada, jika hanya di kepala arsitek. Ada tiga
masukan untuk backlog: konteks, persyaratan, dan hasil evaluasi. Konteks mengacu
pada hal-hal seperti gagasan awal yang mungkin dimiliki arsitek, aset yang tersedia
yang dapat digunakan, batasan yang ditetapkan, dan sejenisnya. Jelas,
persyaratannya
11.2. DESAIN ARSITEKTUR 285
merupakan input penting lainnya. Dalam setiap langkah proses arsitektur, satu atau
beberapa item dari backlog diambil dan digunakan untuk mengubah arsitektur yang
dikembangkan sejauh ini. Hasil transformasi ini dievaluasi (biasanya agak informal),
dan evaluasi ini pada gilirannya dapat mengubah isi backlog. Item baru dapat
ditambahkan (misalnya masalah baru), item mungkin hilang atau menjadi usang,
dan prioritas item backlog dapat berubah.
konteks
perpaduan
11.2.1 Arsitektur sebagai seperangkat

keputusan desain
Jika arsitektur adalah kumpulan keputusan desain, maka pendokumentasian
arsitektur bermuara pada pendokumentasian kumpulan keputusan desain. Ini
biasanya tidak dilakukan. Kita biasanya bisa sampai di hasil keputusan desain,
solusi yang dipilih, tetapi bukan pada alasan di baliknya. Banyak dari alasan di balik
solusi biasanya hilang selamanya, atau hanya tinggal di kepala beberapa orang
yang terkait dengannya, jika masih ada.
Jadi alasan di balik keputusan desain tidak ditangkap secara eksplisit. Ini adalah
pengetahuan diam-diam, penting untuk solusi yang dipilih, tetapi tidak
didokumentasikan. Pada tahap selanjutnya, menjadi sulit untuk melacak alasan
keputusan desain tertentu. Secara khusus, selama evolusi seseorang mungkin
tersandung pada keputusan desain ini, mencoba membatalkannya atau
mengerjakannya, dan mendapat masalah ketika ini ternyata mahal jika tidak
mungkin.
Ada berbagai jenis keputusan desain tidak berdokumen:
�
11.3. TAMPILAN ARSITEKTUR 287
Elemen Keterangan
Masalah Masalah desain sedang ditangani oleh keputusan
Keputusan ini
Status Keputusan diambil
Status keputusan, mis. tertunda, disetujui
Asumsi
Asumsi yang mendasari tentang lingkungan
Alternatif dimana keputusan diambil
Alasan Alternatif dipertimbangkan untuk keputusan ini
Implikasi Penjelasan mengapa keputusan itu dipilih
Implikasi dari keputusan ini, seperti kebutuhan
Catatan akan
keputusan atau persyaratan lebih lanjut
Setiap informasi tambahan yang mungkin
diinginkan
menangkap
Gambar 11.3 Elemen keputusan desain
menyukai. Hubungan antara keputusan desain ini menyerupai jenis hubungan yang
mungkin ada antara persyaratan, seperti yang dibahas di bagian 9.1.3. Demikian
pula, notasi dan alat yang digunakan untuk menangkap informasi ini juga sangat
mirip. Cara sederhana untuk menyusun keputusan desain secara hierarkis adalah
dalam bentuk pohon keputusan. Contoh di sini diberikan pada gambar 11.5.
11.3 Pandangan arsitektur

Arsitektur perangkat lunak berfungsi sebagai kendaraan untuk komunikasi antar pemangku kepentingan.
Contoh pemangku kepentingan adalah: pengguna akhir dari sistem yang diantisipasi, pakar keamanan,
perwakilan dari departemen pemeliharaan, pemilik sistem lain itu
sistem ini harus berinteraksi dengan, pengembang perangkat lunak, dan tentu saja arsitek
diri. Semua pemangku kepentingan ini memiliki kepentingan, tetapi taruhannya mungkin berbeda.
Pengguna akhir
akan tertarik untuk melihat bahwa sistem akan memberi mereka fungsionalitas
diminta. Pengembang perangkat lunak akan tertarik untuk mengetahui di mana menerapkannya
fungsi ini. Pemelihara ingin meyakinkan diri mereka sendiri bahwa komponen adalah sebagai
mandiri mungkin.
Dalam beberapa kasus, dimungkinkan untuk merancang satu representasi arsitektur tunggal
yang melayani semua pemangku kepentingan ini. Secara umum, ini tidak akan berhasil. spesifik
pemangku kepentingan paling baik dilayani oleh representasi arsitektur perangkat lunak yang
menyoroti kekhawatirannya. Pemangku kepentingan lain mungkin lebih baik dilayani oleh yang lain
perwakilan. Bayangkan saja teknik sipil, di mana satu representasi mungkin menonjol
tampilan luar, sementara yang lain menonjolkan aspek konstruksi.
Elemen Ket
Masalah era
ng
an
Keputusan Sistem harus terstruktur sedemikian rupa
sehingga dapat dipertahankan, dapat
digunakan kembali, dan kuat.
Status Arsitektur 3-tier, terdiri dari lapisan
presentasi, lapisan logika bisnis, dan
lapisan manajemen data.
Asumsi
Disetujui.
Sistem tidak memiliki persyaratan hard
Alternatif real-time Alternatifnya adalah Arsitektur
Berorientasi Layanan (SOA), atau jenis
arsitektur X-tier yang berbeda (misalnya
Alasan satu dengan klien gemuk termasuk
presentasi dan logika bisnis, dan tingkat
manajemen data). Pemeliharaan adalah
Implikasi didukung dan ekstensi mudah
direalisasikan karena sambungan
longgar antar lapisan. Lapisan presentasi
Catatan dan lapisan manajemen data dapat
digunakan kembali seperti pada aplikasi
lain. Kekokohan didukung karena lapisan
yang berbeda dapat dengan mudah
dipisahkan pada media yang berbeda,
dan antarmuka lapisan yang terdefinisi
dengan baik memungkinkan pengujian
yang lebih lancar.
Performa terhambat karena semua
lapisan harus dilalui untuk sebagian
besar tindakan pengguna.
Tidak ada.
Gambar 11.4 Elemen keputusan desain
Standar IEEE 1471 (IEEE, 2000) memberikan struktur umum untuk representasi
arsitektur perangkat lunak. Elemen utama dari standar ini adalah:
�
3 tingkat
pengamat
Penguraian. Dalam sudut pandang dekomposisi, elemen dihubungkan oleh

relasi 'isa submodule of'. Elemen yang lebih besar terdiri dari elemen yang lebih
kecil. Ini adalah hasil dari proses penyempurnaan top-down. Sudut pandang
dekomposisi sering membentuk dasar untuk organisasi proyek dan
dokumentasi sistem.
Penggunaan. Dalam sudut pandang penggunaan, hubungan antar elemen

adalah 'penggunaan' (A memanggil B, A meneruskan informasi ke B, dll). Relasi
penggunaan kembali ke Parnas (1972); lihat juga bab 12. Penting ketika kita
ingin menilai modifiabilitas: jika suatu elemen diubah, semua elemen yang
digunakan berpotensi harus diubah juga. Ini juga berguna untuk menentukan
subset inkremental dari sebuah sistem: jika sebuah elemen ada di subset
tertentu, semua elemen yang digunakannya juga harus ada di subset itu.
Berlapis. Sudut pandang berlapis adalah kasus khusus dari sudut pandang
penggunaan. Ini berguna jika kita ingin melihat sistem sebagai rangkaian
lapisan, dimana elemen dari lapisan N
Proses. Sudut pandang proses menggambarkan sistem sebagai serangkaian

proses, yang dihubungkan oleh tautan komunikasi atau sinkronisasi. Ini berguna
jika kita ingin alasan tentang kinerja atau ketersediaan sistem.
Konkurensi Untuk menentukan peluang paralelisme, urutan komputasi yang

dapat dialokasikan ke utas fisik terpisah nanti dalam proses desain dikumpulkan
dalam 'utas logis'. Ini digunakan untuk mengelola masalah yang terkait dengan
eksekusi bersamaan.
Data bersama Sudut pandang ini menunjukkan bagaimana data yang persisten
diproduksi, disimpan, dan dikonsumsi. Ini sangat berguna jika sistem berpusat
pada manipulasi data dalam jumlah besar. Ini dapat digunakan untuk menilai
kualitas seperti kinerja dan integritas data.
Server klien Untuk menggambarkan sistem yang terdiri dari klien dan server
yang bekerja sama. Penghubungnya adalah protokol dan pesan yang
dipertukarkan oleh klien dan server. Sudut pandang ini mengungkapkan
pemisahan perhatian dan distribusi fisik elemen pemrosesan.
Gambar 11.7 Sudut pandang komponen dan konektor
Penyebaran Sudut pandang ini menunjukkan bagaimana perangkat lunak

ditugaskan ke elemen perangkat keras, dan jalur komunikasi mana yang
digunakan. Sudut pandang ini memungkinkan seseorang untuk
mempertimbangkan, misalnya, kinerja, keamanan, dan ketersediaan.
Penerapan Sudut pandang ini menunjukkan bagaimana perangkat lunak dipetakan ke file
struktur. Ini digunakan dalam pengelolaan kegiatan pengembangan dan untuk membangun
proses.
Penugasan kerja Menunjukkan siapa melakukan apa. Sudut pandang ini

digunakan untuk menentukan pengetahuan mana yang dibutuhkan di mana.
Misalnya, seseorang dapat memutuskan untuk menetapkan kesamaan
fungsional ke satu tim.
Gambar 11.8 Sudut pandang alokasi
- A sudut pandang proses yang menggambarkan struktur dinamis dari sistem

dalam hal tugas, proses, komunikasi mereka, dan alokasi
292 ARSITEKTU
R
PERANGKA
Klien T LUNAK
lapisan presentasi K
l
i
e
n
l
a
p
i
s
a
n
p
r
e
s
e
n
t
a
s
i
Server
logika bisnis
pengelola data
basis data
Gambar 11.9 Arsitektur 3-tier
fungsionalitas untuk elemen run-time. Tampilan ini hanya diperlukan jika

sistem memiliki tingkat konkurensi yang signifikan;
- A sudut pandang penyebaran, yang berisi alokasi tugas ke fisik node.

Tampilan ini hanya diperlukan jika sistem terdistribusi.
Sudut pandang '+1' adalah serangkaian kasus penggunaan penting. Serangkaian

kasus penggunaan ini mendorong desain arsitektur, dan berfungsi sebagai perekat
untuk menghubungkan empat sudut pandang lainnya. 'Model 4+1' sekarang adalah
bagian dari metodologi pengembangan RUP (Kruchten, 2003). Sudut pandang di
atas semuanya bersifat teknis. Seringkali, juga berguna untuk membangun satu
atau lebih sudut pandang yang menekankan masalah bisnis. Gambar 11.10
memberikan pandangan berorientasi bisnis dari sistem perpustakaan kami. Ini
membahas tiga aspek arsitektur: komunikasi, penyimpanan, dan lapisan. Untuk
masing-masing, beberapa alternatif diberikan, dan untuk setiap alternatif risiko,
waktu ke pasar dan biaya diindikasikan. Satu alternatif untuk setiap aspek dipilih.
Alternatif-alternatif ini dihubungkan oleh garis lengkung. Dengan cara ini, gambaran
umum cepat diperoleh. Tampilannya mudah dipahami, terutama bagi pemangku
kepentingan non-teknis 1.
1Pandangan bisnis ini dibuat oleh Cuno de Boer, Raymond Backus, Yoeri op ’t Roodt dan ReinierL’abée,
mahasiswa kursus Arsitektur Perangkat Lunak tahun 2005 saya.
11.4. GAYA ARSITEKTUR 2
9
3
Server klien Mandiri

risiko: ++ resiko: o
waktu ke pasar: o waktu ke pasar:++
biaya: o biaya: + Komunikasi
Peramal
risiko: ++
waktu ke pasar: +
biaya: --
Penyimpanan
Mengajuka MySQL
n risiko: ++
mempertaruhkan: -- waktu ke pasar: +
waktu ke pasar: o biaya:++
biaya: +
MVC
risiko: ++
waktu ke pasar: +
Tingkat X tidak berlapis biaya: + Lapisan
mempertaruhkan: - mempertaruhkan: --
waktu ke pasar: - waktu ke pasar: +
biaya: - biaya: +
Gambar 11.10 Tampilan bisnis
11.4 Gaya Arsitektur

Satu teori menarik tentang pemecahan masalah dalam domain pemrograman menyatakan hal itu
pemrogram memecahkan masalah seperti itu menggunakan rencana pemrograman, fragmen program
itu
sesuai dengan tindakan stereotip, dan aturan yang menggambarkan konvensi pemrograman.
Misalnya, untuk menghitung jumlah deret angka, seorang pemrogram menggunakan
'menjalankan rencana putaran total'. Dalam rencana ini, beberapa penghitung diinisialisasi ke nol dan
ditambah dengan nilai berikutnya dari rangkaian di badan loop. Para ahli cenderung
mengingat fragmen program yang sesuai dengan struktur rencana sebelum mereka mengingat yang lain
elemen program. Ini dengan baik memetakan ke gagasan bahwa pengetahuan disimpan
memori manusia dalam satuan yang bermakna (potongan).
Seorang programmer ahli memiliki jumlah pengetahuan yang jauh lebih besar
potongan dari programmer pemula. Ini menyangkut pengetahuan pemrograman dan
pengetahuan tentang domain aplikasi. Baik selama mencari solusi maupun
selama pemahaman program, programmer mencoba menghubungkan dengan pengetahuan
sudah hadir. Sebagai konsekuensinya, bagian dari pendidikan kita sebagai programmer atau perangkat
lunak
insinyur harus terdiri dari memperoleh satu set potongan pengetahuan yang berguna.
Pada tingkat algoritme dan tipe data abstrak, badan pengetahuan seperti itu memilikinya
telah terakumulasi selama bertahun-tahun, dan telah dikodifikasikan dalam buku teks dan perpustakaan
dari komponen yang dapat digunakan kembali. Akibatnya, abstraksi, seperti QuickSort, diwujudkan
dalam
prosedur dan tipe data abstrak, seperti Tumpukan Dan Pohon Biner, telah menjadi bagian
kosakata kita dan secara rutin digunakan dalam pekerjaan kita sehari-hari.
Konsep yang terkandung dalam abstraksi ini berguna selama desain,

implementasi, dan pemeliharaan perangkat lunak karena alasan berikut:
�
arsitektur sering dibuat untuk menggambarkan peran pandangan yang berbeda, seperti yang
diungkapkan dalam
berbagai jenis cetak biru yang dihasilkan. Masing-masing cetak biru ini menekankan hal tertentu
aspek.
Bidang arsitektur klasik memberikan beberapa wawasan menarik lebih lanjut
arsitektur perangkat lunak. Wawasan ini menyangkut:
- pengertian gaya arsitektur,
– hubungan antara gaya dan teknik, dan
- hubungan antara gaya dan bahan.
Arsitektur adalah susunan (formal) dari elemen-elemen arsitektur. Sebuah arsitektur

gaya abstrak dari spesifikasi arsitektur. Dekomposisi perpustakaan kami
sistem mungkin misalnya menghasilkan arsitektur yang terdiri dari satu program utama
dan empat subrutin, berbagi tiga penyimpanan data. Jika kita abstrak dari spesifik ini, kita
mendapatkan gaya arsitekturnya, di mana kami berkonsentrasi pada jenis elemennya
dan interkoneksi mereka.
Dilihat dengan cara ini, gaya arsitektur menggambarkan kodifikasi tertentu
elemen dan susunannya. Sebaliknya, gaya arsitektur kendala keduanya
unsur-unsur dan keterkaitannya. Misalnya gaya Tudor menjelaskan Bagaimana
jenis rumah tertentu terlihat dan juga mengatur bagaimana desainnya akan terlihat. Di sebuah
nada serupa kita dapat mencirikan gaya arsitektur perangkat lunak seperti, katakanlah, itu
gaya pipa-dan-filter.
Prinsip teknik yang berbeda berlaku untuk gaya arsitektur yang berbeda. Ini sering
sejalan dengan jenis bahan yang digunakan. Rumah bergaya cottage dan tinggi
bangunan apartemen bertingkat berbeda dalam bahan yang digunakan dan prinsip-prinsip teknik
terapan. Desain perangkat lunak berdasarkan tipe data abstrak (= material) menekankan
pemisahan perhatian dengan merangkum rahasia (= prinsip rekayasa). Sebuah desain
berdasarkan pipa dan filter menekankan bundling fungsionalitas secara independen
proses.
Saat memilih gaya arsitektur tertentu dengan teknik yang sesuai
prinsip dan materi, kita dipandu oleh masalah yang akan dipecahkan juga
konteks yang lebih besar di mana masalah terjadi. Kita tidak bisa membangun gedung pencakar langit
dari
tiang kayu. Peraturan lingkungan mungkin melarang kita mendirikan gedung bertingkat tinggi
di daerah pedesaan. Dan, bagian depan sempit dari banyak rumah di kanal Amsterdam
sebagian karena fakta bahwa pajak daerah didasarkan pada jumlah jalan yang menghadap ke jalan
jendela. Elemen spesifik masalah dan konteks yang serupa memandu kita dalam pemilihan
gaya arsitektur perangkat lunak.
Kesamaan antara arsitektur klasik dan arsitektur perangkat lunak ini menyediakan
kami dengan petunjuk tentang apa yang merupakan gaya arsitektur perangkat lunak dan apa itu
deskripsi harus terlihat seperti.
Dalam bukunya Bahasa Pola, arsitek Christopher Alexander mempersembahkan
253 'pola', mulai dari skala bagaimana sebuah kota harus melihat ke aturan untuk
pembangunan beranda. Mungkin polanya yang paling terkenal adalah tentang
ketinggian bangunan:
'Ada banyak bukti yang menunjukkan bahwa bangunan tinggi membuat

orang gila.
...
Gedung-gedung tinggi tidak memiliki keuntungan sejati, kecuali
keuntungan spekulatif bagi bank dan pemilik tanah. Mereka tidak lebih
murah, mereka tidak membantu menciptakan ruang terbuka, mereka
mempersulit hidup anak-anak, mahal untuk dirawat, merusak ruang
terbuka di dekat mereka, dan merusak cahaya, udara, dan
pemandangan. Namun terlepas dari itu, bukti empiris menunjukkan
bahwa mereka benar-benar dapat merusak pikiran dan perasaan
orang.. . .
Di daerah perkotaan mana pun, betapapun padatnya, pertahankan
sebagian besar bangunan setinggi empat lantai atau kurang. Ada
kemungkinan bangunan tertentu melebihi batas ini, tetapi tidak boleh
menjadi bangunan untuk tempat tinggal manusia.’
Pola Aleksandria bukanlah buku masak, resep kotak hitam untuk arsitek, lebih dari
kamus adalah alat untuk seorang novelis. Sebaliknya, sebuah pola adalah skema
generik yang fleksibel yang memberikan solusi untuk suatu masalah dalam konteks
tertentu. Dalam bentuk naratif, aplikasinya terlihat seperti ini:
JIKA Anda menemukan diri Anda

<
di dalamnya
Jenis Keterangan
komputasional Komponen melakukan semacam

perhitungan.
Biasanya input dan output ke komponen cukup
sederhana, mis. parameter prosedur.
Komponen mungkin memiliki status lokal, tetapi
status ini hilang setelah komponen
menyelesaikan tugasnya. Contoh komponen
jenis ini adalah fungsi dan filter (matematis).
Penyimpanan Sebuah komponen memori
mempertahankan koleksi gigih,
data terstruktur, untuk digunakan bersama oleh
sejumlah komponen lain. Contohnya adalah
database, sistem file, atau tabel simbol.
Pengelola Komponen manajer berisi status
dan sejumlah
operasi terkait. Saat dipanggil, operasi ini
menggunakan atau memperbarui status, dan
status ini dipertahankan di antara pemanggilan
operasi manajer yang berurutan. Tipe data
abstrak dan server adalah komponen contoh
dari tipe ini.
pengontrol Pengontrol mengatur urutan
waktu dari peristiwa lain. A
modul kontrol tingkat atas dan penjadwal
adalah contohnya.
Gambar 11.11 Beberapa tipe komponen (Sumber: M. Shaw & D. Garlan, Arsitektur
Perangkat Lunak: Perspektif tentang Disiplin yang Muncul, halaman 149, 1996,
Dicetak ulang atas izin Prentice-Hall)
pola. Kami akan menggunakan kerangka kerja ini untuk menggambarkan sejumlah yang terkenal dan
klasik
gaya arsitektur. Kerangka memiliki entri berikut:
�
blok arsitektur perangkat lunak. Mereka biasanya mewujudkan semacam
elemen komputasi (seperti prosedur), tetapi komponen juga bisa menjadi
penyimpanan data (seperti database). Konektor menjelaskan bagaimana
komponen berinteraksi.3
Beberapa tipikal tipe komponen dan konektor diberikan pada gambar 11.11
dan 11.12.
Urutan eksekusi komponen diatur oleh struktur kontrol. Struktur kontrol
menangkap bagaimana kontrol ditransfer selama eksekusi.
Pilihan komponen dan konektor tidak independen. Biasanya, gaya dicirikan
oleh kombinasi jenis komponen dan konektor tertentu, serta struktur kontrol
tertentu. Itu model sistem menangkap intuisi di balik kombinasi semacam itu.
Ini menggambarkan rasa umum dari sistem.
�
Jenis Keterangan
panggilan prosedur Dengan jenis konektor ini, ada

satu utas
kontrol antara pemanggil dan komponen
yang dipanggil. Kontrol ditransfer ke
komponen yang dipanggil, dan komponen
ini tetap memegang kendali hingga
pekerjaannya selesai. Baru setelah itu
kontrol ditransfer kembali ke komponen
pemanggil. Panggilan prosedur tradisional
dan panggilan prosedur jarak jauh adalah
contoh dari jenis konektor ini.
aliran data Dengan konektor aliran data,
proses berinteraksi melalui
aliran data, seperti dalam pipa. Komponen
itu sendiri adalah independen. Setelah
input data ke komponen tersedia,
komponen tersebut dapat melanjutkan
pekerjaannya.
doa implisit Dengan doa implisit, perhitungan
dipanggil
ketika peristiwa tertentu terjadi, bukan
dengan interaksi eksplisit (seperti dalam
pemanggilan prosedur). Event yang
memunculkan komponen tidak mengetahui
komponen mana yang akan bereaksi dan
komponen yang dipanggil tidak
mengetahui komponen mana yang
memunculkan event yang mereka
tanggapi.
penyampaian pesan Message passing terjadi ketika
kita sudah mandiri
proses yang berinteraksi melalui transfer
data yang eksplisit dan diskrit, seperti pada
TCP/IP. Pengiriman pesan dapat sinkron
(dalam hal ini proses
pengiriman/penerimaan diblokir sampai
pesan telah benar-benar terkirim/diterima)
atau asinkron (dalam hal ini proses
melanjutkan pekerjaan mereka secara
mandiri).
data bersama Saat menggunakan konektor
data bersama, komponen
beroperasi secara bersamaan pada ruang
data yang sama, seperti pada sistem
papan tulis atau basis data multipengguna.
Biasanya, beberapa skema pemblokiran
mencegah penulisan bersamaan ke data
yang sama.
Instansiasi Dengan instantiation, satu
komponen (the instantiation
tor) menyediakan ruang untuk keadaan yang dibutuhkan oleh orang
lain
komponen (yang dipakai), seperti pada tipe data abstrak.
Gambar 11.12 Beberapa jenis konektor (Sumber: M.Shaw&D.Garlan, Arsitektur

Perangkat Lunak: Perspektif tentang Disiplin yang Muncul, halaman 149-150, 1996,
Dicetak ulang atas izin Prentice-Hall)
Gaya: Program utama dengan subrutin
Masalah Sistem dapat digambarkan sebagai hirarki definisi prosedur. Gaya ini
merupakan hasil alami dari dekomposisi fungsional suatu sistem (lihat bab 12).
Modul tingkat atas bertindak sebagai program utama. Tugas utamanya adalah
memanggil modul lain dalam urutan yang benar. Akibatnya, biasanya hanya ada
satu rangkaian kendali.
Konteks Gaya ini secara alami cocok dengan bahasa pemrograman yang
memungkinkan untuk bersarang definisi prosedur dan modul.
Larutan
Model sistem Prosedur dan modul didefinisikan dalam hierarki. Modul tingkat yang lebih tinggi
memanggil modul tingkat yang lebih rendah. Hirarki mungkin ketat, di
modul kasus
N
mana di
tingkat
Gaya: Tipe data abstrak
Masalah Masalah utama adalah untuk mengidentifikasi dan melindungi badan

informasi terkait. Gaya ini sangat cocok untuk kasus di mana representasi data
cenderung berubah selama masa pakai sistem. Ketika desain cocok dengan struktur
data dalam domain masalah, komponen yang dihasilkan merangkum entitas domain
masalah dan operasinya.
Konteks Banyak metode desain, terutama yang berorientasi objek, menyediakan

heuristik untuk mengidentifikasi objek dunia nyata. Objek-objek ini kemudian
dikemas dalam komponen sistem. Bahasa pemrograman berorientasi objek
menyediakan konsep kelas, yang memungkinkan kita untuk menghubungkan objek
serupa dan menggunakan kembali kode melalui mekanisme pewarisan.
Larutan
Model sistem Setiap komponen memelihara data lokalnya sendiri. Komponen

menyembunyikan rahasia, mis. representasi data mereka.
Komponen Komponen dari gaya ini adalah manajer, seperti server,
objek, dan tipe data abstrak.
Konektor Operasi dipanggil melalui panggilan prosedur (pesan).
Struktur kontrol Biasanya ada satu utas kontrol. Kontrol terdesentralisasi,
bagaimanapun; komponen dapat meminta komponen apa pun yang
layanannya diperlukan.
Varian Metode atau bahasa yang tidak berorientasi objek hanya memungkinkan kita
untuk menyembunyikan representasi data dalam modul. Metode atau bahasa
berorientasi objek berbeda dalam hal fasilitasnya untuk menghubungkan objek
serupa (pewarisan tunggal atau ganda) dan pengikatan pesan ke operasi (waktu
kompilasi atau waktu proses); lihat juga bab 12.
Contoh (Parnas, 1972); Booch (1994) memberikan sejumlah contoh yang berhasil.
Gambar 11.14 Gaya arsitektur tipe data abstrak (Sumber: M. Shaw, Beberapa Pola
untuk Arsitektur Perangkat Lunak, di dalam J.M. Vlissides et al., Pola Bahasa
Desain Program 2,Direproduksi atas izin Addison-Wesley.)
buat struktur data perantara ini. Sebaliknya, kita dapat menggunakan mode operasi
pipa-dan-filter yang terkenal dari UNIX dan secara langsung mengumpankan output
dari satu transformasi ke transformasi berikutnya. Komponen disebut filter dan
konektor FIFO disebut pipa. Karakteristik penting dari skema ini adalah bahwa
setiap struktur yang dikenakan pada data yang akan diteruskan antara filter yang
berdekatan harus secara eksplisit
Gaya: Doa implisit
Masalah Kami memiliki kumpulan komponen yang digabungkan secara longgar,

yang masing-masing melakukan beberapa tugas dan dapat mengaktifkan operasi
lain. Karakteristik utama dari gaya ini adalah tidak mengikat penerima sinyal kepada
pencetusnya. Ini sangat berguna untuk aplikasi yang harus dapat dikonfigurasi
ulang, dengan mengubah penyedia layanan atau dengan mengaktifkan dan
menonaktifkan operasi.
Konteks Gaya ini biasanya membutuhkan event handler yang mendaftarkan

kepentingan komponen dan memberi tahu orang lain. Karena sifat sistem yang
secara intrinsik terdesentralisasi yang dirancang dengan cara ini, argumen
kebenaran menjadi sulit. Untuk alasan yang sama, membangun model mental dari
sistem semacam itu selama pemahaman program juga sulit.
Larutan
Model sistem Proses bersifat independen dan reaktif. Proses tidak

dipanggil secara eksplisit, tetapi secara implisit melalui peningkatan suatu
peristiwa.
Komponen Komponen adalah proses yang memberi sinyal peristiwa tanpa
mengetahui komponen mana yang akan bereaksi terhadapnya. Sebaliknya,
proses bereaksi terhadap peristiwa yang muncul di suatu tempat di sistem.
Konektor Komponen terhubung melalui pemanggilan otomatis proses
yang telah mendaftarkan minat pada peristiwa tertentu.
Struktur kontrol Kontrol terdesentralisasi. Komponen individu tidak
menyadari penerima sinyal.
Varian Ada dua kategori utama sistem yang mengeksploitasi pemanggilan implisit.
Kategori pertama terdiri dari apa yang disebut kerangka integrasi alat seperti yang
dicontohkan oleh banyak lingkungan pendukung pengembangan perangkat lunak.
Mereka terdiri dari sejumlah 'alat' yang berjalan sebagai proses terpisah. Acara
ditangani oleh proses operator terpisah yang menggunakan beberapa dukungan
sistem operasi dasar seperti soket UNIX; lihat misalnya (Reiss, 1990). Kategori
kedua terdiri dari bahasa dengan notasi khusus dan dukungan untuk pemanggilan
implisit, seperti fitur 'saat diperbarui' dari beberapa bahasa berorientasi objek; lihat
misalnya (Sutton et al., 1990).
Contoh (Garlan et al., 1992); (Reiss, 1990); (Sutton et al., 1990).
Gambar 11.15 Gaya arsitektur implisit-doa (Sumber: M. Shaw, Beberapa Pola untuk
Arsitektur Perangkat Lunak, di dalam J.M. Vlissides et al., Pola Bahasa Desain
Program 2,Direproduksi atas izin Addison-Wesley.)
Gaya: Pipa dan filter
Masalah Serangkaian transformasi berurutan yang independen pada data yang

dipesan. Biasanya, transformasi bersifat inkremental. Seringkali, struktur aliran data
sangat sederhana: urutan karakter ASCII. Jika data memiliki struktur yang kaya, ini
akan menyiratkan beberapa overhead untuk parsing dan unparsing data.
Konteks Gaya ini mensyaratkan bahwa sistem dapat didekomposisi menjadi

serangkaian perhitungan, filter, yang mengubah satu atau lebih aliran input secara
bertahap. Biasanya bergantung pada operasi sistem operasi untuk mentransfer data
dari satu proses ke proses lainnya (pipa). Penanganan kesalahan sulit ditangani
secara seragam dalam kumpulan filter.
Larutan
Model sistem Sistem yang dihasilkan dicirikan oleh aliran data berkelanjutan
antar komponen, di mana komponen secara bertahap mengubah aliran data.
Komponen Komponennya adalah filter yang melakukan pemrosesan lokal;
yaitu mereka membaca sebagian dari data input mereka, mengubah data, dan
menghasilkan sebagian dari output mereka. Mereka memiliki sedikit keadaan
internal.
Konektor Datastreams (biasanya ASCII biasa, seperti di UNIX).
Struktur kontrol Aliran data antar komponen. Setiap komponen biasanya
memiliki alur kontrolnya sendiri.
Varian Filter murni memiliki sedikit keadaan internal dan memproses inputnya
secara lokal. Dalam kasus degenerasi, mereka mengkonsumsi semua masukan
mereka sebelum menghasilkan keluaran apa pun. Dalam hal ini, hasilnya bermuara
pada jenis sistem pemrosesan batch.
Contoh (Delisle dan Garlan, 1990)
Gambar 11.16 Gaya arsitektur pipa-dan-filter (Sumber: M. Shaw,

Beberapa Pola untuk
Arsitektur Perangkat Lunak, di dalam J.M. Vlissides et al., Pola Bahasa Desain Program 2,
Direproduksi atas izin Addison-Wesley.)
dikodekan dalam aliran data yang menghubungkan filter ini. Skema pengkodean ini
melibatkan keputusan yang banyak diketahui oleh kedua filter. Data harus diurai
oleh onefilter sedangkan filter berikutnya harus mengurai inputnya untuk
membangun kembali struktur itu. Tumit Achilles dari skema pipa-dan-penyaringan
adalah penanganan kesalahan. Jika satu filter mendeteksi kesalahan, akan sulit
untuk meneruskan pesan kesalahan yang dihasilkan melalui filter perantara sampai
ke hasil akhir. Filter juga harus dapat mensinkronisasi ulang setelah kesalahan
terdeteksi dan filter lebih jauh ke hilir harus dapat menoleransi
Gaya: Gudang
Masalah Masalah utamanya adalah mengelola dan memelihara kumpulan informasi

yang kaya struktur. Informasi biasanya harus dimanipulasi dengan berbagai cara.
Data berumur panjang dan integritasnya penting.
Konteks Gaya ini seringkali membutuhkan dukungan yang cukup besar, dalam
bentuk sistem runtime yang ditambah dengan database. Definisi data mungkin
harus diproses untuk menghasilkan dukungan untuk mempertahankan struktur data
yang benar.
Larutan
Model sistem Karakteristik utama dari model ini adalah kumpulan

informasinya yang tersentralisasi dan kaya struktur. Elemen komputasi yang
bekerja pada repositori seringkali independen.
Komponen Ada satu komponen memori dan banyak komputasi proses.
Konektor Unit komputasi berinteraksi dengan komponen memori dengan
akses langsung atau panggilan prosedur.
Struktur kontrol Struktur kontrol bervariasi. Dalam sistem basis data
tradisional, misalnya, kontrol bergantung pada input ke fungsi basis data.
Dalam kompiler modern, kontrol bersifat tetap: proses bersifat berurutan dan
inkremental. Dalam sistem papan tulis, kontrol bergantung pada keadaan
komputasi.
Varian Sistem basis data tradisional dicirikan oleh sifatnya yang berorientasi pada
transaksi. Proses komputasi independen dan dipicu oleh permintaan yang masuk.
Kompiler modern, dan lingkungan pendukung pengembangan perangkat lunak,
adalah sistem yang menambah informasi yang terkandung dalam repositori. Sistem
papan tulis berasal dari AI. Mereka telah digunakan untuk aplikasi yang kompleks
seperti pengenalan ucapan, di mana elemen komputasi yang berbeda
masing-masing memecahkan sebagian dari masalah dan memperbarui informasi di
papan tulis.
Contoh (Barstow et al., 1984) untuk lingkungan pengembangan perangkat lunak;

(Corkill, 1997) untuk arsitektur papan tulis.
Gambar 11.17 Gaya arsitektur repositori (Sumber: M. Shaw, Beberapa Pola untuk
Arsitektur Perangkat Lunak, di dalam J.M. Vlissides et al., Pola Bahasa Desain
Program 2, Direproduksi atas izin Addison-Wesley.)
Gaya: Berlapis
Masalah Kami dapat mengidentifikasi kelas layanan yang berbeda yang dapat
diatur secara hierarkis. Sistem dapat digambarkan sebagai rangkaian lingkaran
konsentris, dimana layanan dalam satu lapisan bergantung pada (panggilan)
layanan dari lapisan dalam. Cukup sering, sistem seperti itu dibagi menjadi tiga
lapisan: satu untuk layanan dasar, satu untuk utilitas umum, dan satu lagi untuk
utilitas khusus aplikasi.
Konteks Setiap kelas layanan harus ditugaskan ke lapisan tertentu. Kadang-kadang

mungkin sulit untuk mengidentifikasi fungsi lapisan secara ringkas dan, sebagai
konsekuensinya, menetapkan fungsi yang diberikan ke lapisan yang paling tepat. Ini
semakin berlaku jika kita membatasi visibilitas hanya pada satu lapisan.
Larutan
Model sistem Sistem yang dihasilkan terdiri dari hierarki lapisan. Biasanya,
visibilitas lapisan dalam dibatasi.
Komponen Komponen-komponen pada setiap layer biasanya terdiri dari
kumpulan-kumpulan dari
Prosedur.
Konektor Komponen umumnya berinteraksi melalui pemanggilan prosedur. Karena
dari visibilitas terbatas, interaksi terbatas.
Struktur kontrol Sistem ini memiliki satu utas kontrol.
Varian Lapisan dapat dilihat sebagai mesin virtual, menawarkan satu set 'instruksi'
ke lapisan berikutnya. Dilihat demikian, lapisan periferal menjadi semakin abstrak.
Lapisan juga dapat dihasilkan dari keinginan untuk memisahkan fungsionalitas, mis.
menjadi lapisan antarmuka pengguna dan lapisan logika aplikasi. Varian skema
berlapis mungkin berbeda dalam hal visibilitas komponen ke lapisan luar. Dalam
kasus yang paling terbatas, visibilitas terbatas pada lapisan berikutnya.
Contoh (van der Linden dan Müller, 1995), (Ho dan Olsson, 1996), (Bohrer et al.,
1998).
Gambar 11.18 Gaya arsitektur berlapis (Sumber: M. Shaw,

Beberapa Pola untuk Perangkat Lunak
Ilmu bangunan, di dalam J.M. Vlissides et al., Pola Bahasa Desain Program 2, Direproduksi
atas izin Addison-Wesley.)
masukan tidak lengkap.

Gaya repositori cocok dengan situasi di mana masalah utamanya adalah mengelola kekayaan
struktur informasi. Dalam contoh perpustakaan kami di bab 9, datanya menyangkut
hal-hal seperti stok buku yang tersedia dan koleksi anggota perpustakaan.
Data ini bersifat persisten dan penting untuk selalu mencerminkan keadaan sebenarnya
urusan. Pendekatan alami untuk masalah ini adalah merancang skema basis data
untuk berbagai jenis data dalam aplikasi (buku, jurnal, klien perpustakaan, reservasi,
dan sebagainya) dan menyimpan data dalam satu atau lebih basis data.
Fungsionalitas sistem tergabung dalam sejumlah elemen komputasi yang relatif
independen. Hasilnya adalah gaya arsitektur repositori.
Kompiler modern sering disusun dengan cara yang serupa. Compiler seperti itu
mempertahankan representasi sentral dari program yang akan diterjemahkan. Versi
dasar dari representasi tersebut dihasilkan dari fase pertama, leksikal,: urutan token,
bukan urutan mesin terbang karakter. Fase selanjutnya, seperti sintaksis dan
analisis semantik, semakin memperkaya struktur ini menjadi, misalnya, pohon
sintaksis abstrak. Pada akhirnya, kode dihasilkan dari representasi ini. Alat lain,
seperti debugger simbolik, program pencetakan cantik, atau alat analisis statis, juga
dapat menggunakan representasi internal yang dibuat oleh kompiler. Gaya arsitektur
yang dihasilkan sekali lagi adalah gaya repositori: satu komponen memori dan
sejumlah elemen komputasi yang bekerja pada repositori itu. Berbeda dengan
varian database, urutan pemanggilan elemen penting dalam kasus kompiler. Juga,
elemen komputasi yang berbeda memperkaya representasi internal, bukan hanya
memperbaruinya.
Gaya arsitektur repositori juga dapat ditemukan di aplikasi AI tertentu. Aplikasi
yang kompleks secara komputasi, seperti pengenalan ucapan, representasi internal
dibangun dan ditindaklanjuti oleh elemen komputasi yang berbeda. Sebagai contoh,
satu elemen komputasi dapat memfilter derau, yang lain membangun fonem, dll.
Representasi internal dalam jenis sistem ini disebut a papan tulis dan arsitektur
kadang-kadang disebut sebagai arsitektur papan tulis. Perbedaan utama dengan
sistem basis data tradisional adalah bahwa pemanggilan elemen komputasi dalam
arsitektur papan tulis dipicu oleh keadaan papan tulis saat ini, bukan oleh input
(eksternal). Elemen dari arsitektur papan tulis memperkaya dan memperhalus
representasi negara sampai solusi untuk masalah ditemukan.
Contoh terakhir kami dari gaya arsitektur adalah gaya arsitektur berlapis. Contoh
prototipikalnya adalah Model Interkoneksi Sistem Terbuka ISO untuk komunikasi
jaringan. Ini memiliki tujuh lapisan: fisik, data, jaringan, transportasi, sesi, presentasi,
dan aplikasi. Lapisan bawah menyediakan fungsionalitas dasar. Lapisan yang lebih
tinggi menggunakan fungsionalitas lapisan bawah. Lapisan yang berbeda dapat
dilihat sebagai mesin virtual yang 'instruksinya' menjadi lebih kuat dan abstrak saat
kita beralih dari lapisan bawah ke lapisan yang lebih tinggi.
Dalam skema berlapis, menurut definisi, level yang lebih rendah tidak dapat
menggunakan fungsionalitas yang ditawarkan oleh level yang lebih tinggi.
Sebaliknya, situasinya lebih bervariasi. Kami dapat memilih untuk mengizinkan
lapisan N
di samping ketika pernyataan dan panggilan prosedur. Jika visibilitas dibatasi, kita mungkin berakhir
up menyalin fungsionalitas ke tingkat yang lebih tinggi tanpa meningkatkan tingkat abstraksi.
van der Linden dan Müller (1995) memberikan contoh gaya arsitektur berlapis
untuk digunakan dalam telekomunikasi. Dalam contoh ini, lapisan tidak sesuai dengan yang berbeda
tingkat abstraksi. Sebaliknya, fungsionalitas sistem telah dipisahkan. Dua
pedoman utama mengarahkan penugasan fungsionalitas ke lapisan dalam arsitektur ini:
– fungsionalitas yang bergantung pada perangkat keras harus ditempatkan di lapisan tingkat
yang lebih rendah daripada
fungsionalitas yang bergantung pada aplikasi.
– fungsionalitas generik harus ditempatkan di lapisan bawah daripada fungsionalitas khusus.

Arsitektur yang dihasilkan memiliki empat lapisan:
�
11.5 Penilaian Arsitektur Perangkat

Lunak
Arsitektur perangkat lunak menangkap keputusan desain awal. Karena keputusan
awal ini berdampak besar, penting untuk memulai pengujian bahkan pada tahap
awal ini. Menguji arsitektur perangkat lunak biasanya disebut sebagai penilaian
arsitektur perangkat lunak. Dalam penilaian arsitektur perangkat lunak, arsitektur
perangkat lunak dinilai sehubungan dengan atribut kualitas seperti pemeliharaan,
fleksibilitas, dan sebagainya.
Penting untuk diingat bahwa dalam proses ini arsitektur dinilai, sambil berharap
hasilnya akan berlaku untuk sistem yang belum dibangun. Akibatnya, kesimpulan
seringkali berada pada tingkat yang cukup umum. Juga, ada beberapa
ketidakpastian tentang apakah hasil ini benar-benar akan terwujud. Misalkan
arsitektur dinilai untuk pemeliharaan. Bahkan jika hasilnya cukup positif, proses
implementasi yang ceroboh masih bisa merusak gambaran indah tersebut. Gambar
11.19 mengilustrasikan masalah ini. Penilaian arsitektur dilakukan di sisi kiri gambar,
sementara orang menganggap hasilnya akan valid untuk sisi kanan.
perangkat lunak penerapan diimplementasikan

Arsitektur sistem
Terjemahkan ke
properti kualitas
penilaian arsitektur sistem

perilaku
Gambar 11.19 Hubungan antara penilaian arsitektur perangkat lunak dan perilaku
sistem aktual
Ada dua kelas teknik yang luas untuk mengevaluasi arsitektur perangkat lunak.
Kelas pertama terdiri dari teknik pengukuran, dan bergantung pada informasi
kuantitatif. Contohnya termasuk metrik arsitektur dan simulasi. Kelas kedua terdiri
dari teknik bertanya, di mana seseorang menyelidiki bagaimana arsitektur bereaksi
11.5. PENILAIAN ARSITEKTUR PERANGKAT 309
LUNAK
situasi tertentu. Ini sering dilakukan dengan bantuan skenario. Di sekuelnya, kita
berkonsentrasi pada yang terakhir.
Ada berbagai jenis skenario yang dapat digunakan dalam penilaian arsitektur.
Jenis umum adalah:
�
pada akhir di mana laporan tertulis disampaikan. Langkah pertama dimaksudkan

untuk membuat peserta terbiasa dengan penggerak kualitas utama untuk sistem
(langkah 2), solusi yang dipilih (langkah 3), dan pendekatan serta pola yang
digunakan dalam solusi ini (langkah 4). Pada langkah 5, persyaratan kualitas
diartikulasikan secara lebih rinci. Pengambil keputusan proyek adalah kunci dalam
proses ini. Hasil akhir dari latihan ini adalah sebuah pohon. Simpul akar disebut
“utilitas”. Ini mengungkapkan kualitas arsitektur secara keseluruhan. Tingkat
selanjutnya berisi atribut kualitas yang akan dievaluasi. Ini sekali lagi dipecah
menjadi konstituen yang lebih rinci. Node daun adalah skenario konkret. Gambar
11.21 memberikan bagian dari pohon utilitas yang mungkin untuk menilai sistem
perpustakaan kita.
Waktu merespon
Pertunjukan
Hasil 100
transaksi/deti
k
Pelatihan
Kegunaan Kegunaan
Operasi normal
S
Dapat dipelihara ty Pelepasan Ini adalah

vendor versi database
baru
Gambar 11.21 Contoh pohon utilitas
Simpul daun pada gambar 11.21 dicetak miring. Deskripsi ini tidak lengkap.
Representasi penuh harus mengandung lebih banyak informasi, misalnya jenis
informasi yang terkandung dalam skenario atribut kualitas (lihat bagian 6.3).
Pohon utilitas lengkap mungkin berisi lebih banyak skenario daripada yang
dapat dianalisis selama penilaian. Ini kemudian berguna untuk memprioritaskan
skenario. ATAM menyarankan dua kriteria untuk melakukannya. Dengan
menggunakan kriteria pertama, pemangku kepentingan menunjukkan seberapa
penting skenario tersebut (misalnya menggunakan skala 3 poin sederhana: Tinggi,
Sedang, Rendah). Dengan menggunakan kriteria kedua, arsitek mengurutkan
skenario berdasarkan seberapa sulit dia percaya akan memenuhi skenario tersebut,
dengan menggunakan skala 3 poin yang sama. Di sisa penilaian, seseorang dapat
misalnya berkonsentrasi pada skenario yang mendapat skor Tinggi pada kedua
skala.
Pada langkah 6, skenario dibahas satu per satu. Untuk setiap skenario, arsitek
memandu pemangku kepentingan melalui arsitektur, menjelaskan bagaimana
arsitektur mendukung skenario tersebut. Ini dapat memicu diskusi lebih lanjut
tentang pendekatan arsitektur yang dipilih. Hasil akhirnya adalah daftar poin
sensitivitas yang terdokumentasi, tradeoff
11.6. RINGKASAN 311
poin, risiko dan nonrisiko, yang berkaitan dengan keputusan arsitektural yang dibuat dengan yang
relevan
atribut kualitas.
A titik kepekaan adalah properti dari arsitektur yang sangat penting untuk tertentu
atribut kualitas. Misalnya, kemungkinan untuk membatalkan tindakan pengguna sangat mempengaruhi
kegunaan sistem perpustakaan kami, dan oleh karena itu properti ini merupakan titik sensitif
sehubungan dengan kegunaan. Pada saat yang sama, keputusan ini juga merupakan titik sensitif
sehubungan dengan kinerja. Jika keputusan adalah titik sensitivitas untuk lebih dari satu
atribut kualitas, hal itu disebut a titik pertukaran. Jika kinerja adalah yang paling penting, maka
keputusan untuk memasukkan fasilitas undo mungkin a mempertaruhkan. Jika keputusan ini tidak kritis,
itu adalah a
tidak berisiko.
Pohon utilitas didasarkan pada driver utama yang digunakan selama desain
Arsitektur. Pembangunannya dilakukan dengan berkonsultasi dengan para pengambil keputusan utama.
Ada pemangku kepentingan lain, seperti manajer pemeliharaan atau pakar keamanan, yang
juga dapat disurvei untuk skenario tambahan. Ini dilakukan pada langkah 7. Dan mirip dengan langkah
5, skenario ini diprioritaskan, dan seleksi dibuat untuk studi lebih lanjut. Serupa
ke langkah 6, skenario tambahan ini dianalisis pada langkah 8. Terakhir, dikumpulkan
informasi dirangkum dan disajikan kepada semua pemangku kepentingan pada langkah 9.
Hasil penilaian arsitektur jauh melampaui daftar sensitivitas
poin, poin tradeoff, risiko dan nonrisiko. Para pemangku kepentingan, termasuk arsitek,
sering membangun pemahaman yang jauh lebih dalam tentang arsitektur, yang mendasarinya
keputusan, dan konsekuensinya. Juga, dokumentasi yang lebih baik seringkali
disampaikan sebagai produk sampingan dari penilaian. Ini mirip dengan manfaat tambahan
inspeksi dan penelusuran perangkat lunak memiliki selain identifikasi perangkat lunak
kesalahan (lihat bagian 13.4.2).
Dalam praktiknya, organisasi sering melakukan penilaian arsitektur perangkat lunak dalam waktu
yang lebih singkat
rasa kaku dari yang disarankan oleh deskripsi ATAM di atas. Biasanya, seperti kafetaria
pendekatan diikuti, dimana elemen-elemen dari ATAM dan metode serupa
dipilih yang paling sesuai dengan situasi yang dihadapi (Kazman et al., 2006).
11.6 Ringkasan
Arsitektur perangkat lunak berkaitan dengan deskripsi elemen dari mana
sistem dibangun, interaksi di antara elemen-elemen tersebut, pola yang memandu mereka
komposisi, dan kendala pada pola tersebut. Desain arsitektur perangkat lunak
didorong oleh masalah kualitas. Arsitektur perangkat lunak yang dihasilkan dijelaskan dalam
pandangan yang berbeda, yang masing-masing membahas masalah khusus atas nama tertentu
pemangku kepentingan. Ini menyerupai cara gambar bangunan yang berbeda ditekankan
aspek yang berbeda atas nama pemangku kepentingan yang berbeda.
Penting untuk tidak hanya mendokumentasikan solusi yang dihasilkan, tetapi juga keputusannya
yang mengarah ke solusi itu, alasannya, dan informasi lain yang berguna untuk memandu
evolusi selanjutnya.
Arsitektur perangkat lunak adalah gagasan penting, karena lebih dari satu alasan:
�
Arsitektur perangkat lunak dan pola desain sangat dipengaruhi oleh

karya arsitek Christopher Alexander. Ini tentu bermanfaat untuk dilihat
pada mereka (Alexander et al., 1977), (Alexander, 1979). Lea (1994) memberikan pengantar
untuk pekerjaannya untuk insinyur perangkat lunak. Alexander (1999) menjelaskan asal-usul pola
teori. Buschmann et al. (1996) adalah sumber yang bagus untuk pola arsitektur. Itu
teori rencana pemrograman berasal dari (Soloway, 1986).
Clements et al. (2002) membahas evaluasi arsitektur perangkat lunak secara mendalam.
Maranzano dkk. (2005) membahas pengalaman dengan tinjauan arsitektur. Sebuah survei dari
metode penilaian arsitektur diberikan dalam (Dobrica dan Niemelä, 2002).
Banyak masalah yang berkaitan dengan arsitektur perangkat lunak belum disinggung dalam hal ini
bab. Ini termasuk upaya untuk mengklasifikasikan gaya arsitektur perangkat lunak sepanjang berbeda
dimensi (Shaw dan Clements, 1996), bahasa deskripsi arsitektur dan
alat pendukung (Shaw et al., 1995), bahasa deskripsi arsitektur (Medvidovic
dan Taylor, 2000), rekonstruksi arsitektur (van Deursen et al., 2004), peran
arsitek perangkat lunak (Kruchten, 1999), (Mustapic et al., 2004).
Latihan
1. Berikan definisi istilah 'arsitektur perangkat lunak'. Jelaskan perbedaannya

unsur-unsur dalam definisi ini.
2. Apa perbedaan antara arsitektur perangkat lunak dan desain tingkat atas?
3. Apa tujuan utama dari arsitektur perangkat lunak?
4. Apa hubungan antara keputusan desain dan arsitektur perangkat lunak?
5. Menjelaskan metode perancangan arsitektur ADD (Attribute Driven Design).
6. Apa peran backlog dalam desain?
7. Apa perbedaan antara pengertian arsitektur dan desain perangkat lunak

pola?
8. Apa perbedaan antara sudut pandang konseptual atau logis dan

sudut pandang implementasi?
9. Jelaskan perbedaan modul, komponen dan konektor, dan

sudut pandang alokasi.
10. Jelaskan dengan kata-kata Anda sendiri inti dari arsitektur pemanggilan implisit
gaya tural.
11. Dalam arti apa gaya arsitektur tipe data abstrak membatasi
perancang?
12. Mengapa penanganan kesalahan sulit dalam gaya arsitektur pipa dan filter?
13. Mengapa bahasa sangat penting dalam desain perangkat lunak?
14. Tentukan jenis komponen berikut: komputasi, memori, manajer.
15. Tentukan jenis konektor berikut: aliran data, pengiriman pesan, bersama
data.
16. Dalam arti apa lapisan dalam arsitektur berlapis dapat dilihat sebagai virtual
mesin?
17. Apa yang dimaksud dengan penilaian arsitektur perangkat lunak?
18. Jelaskan langkah-langkah ATAM.
19. �
12
Desain perangkat lunak
TUJUAN PEMBELAJARAN
�
316 DESAIN PERANGKAT LUNAK
Desain perangkat lunak menyangkut dekomposisi sistem menjadi

konstituennya
bagian. Desain yang baik adalah kunci keberhasilan implementasi dan evolusi
dari sebuah sistem. Sejumlah prinsip panduan untuk dekomposisi ini
membantu
mencapai desain yang berkualitas. Prinsip-prinsip panduan ini mendasari
desain utama
metode yang dibahas dalam bab ini. Tidak seperti bidang desain klasik lainnya,
ada
tidak ada hubungan visual antara representasi desain dari sistem perangkat
lunak dan
produk akhir. Ini mempersulit komunikasi pengetahuan desain
dan meningkatkan pentingnya representasi desain yang tepat.
Selama pengembangan perangkat lunak, kita harus mematuhi pendekatan yang

direncanakan. Jika kita ingin melakukan perjalanan dari titik A ke titik B, kita
(mungkin) akan melihat peta terlebih dahulu. Menurut beberapa kriteria, kita
kemudian akan merencanakan skema perjalanan kita. Kehilangan waktu yang
disebabkan oleh kegiatan perencanaan pasti lebih besar daripada kesengsaraan
yang terjadi jika kita tidak merencanakan perjalanan kita sama sekali tetapi hanya
mengambil belokan pertama ke kiri, dengan harapan ini akan membawa kita lebih
dekat ke tujuan kita.
Dalam mendesain sebuah taman, kita juga akan mengikuti beberapa
perencanaan. Kita tidak akan mulai dengan menanam beberapa umbi di satu sudut,
pohon apel di sudut lain, dan poplar di samping pintu depan.
Contoh di atas terdengar konyol. Mereka. Namun, banyak proyek
pengembangan perangkat lunak dilakukan dengan cara ini. Agak dibesar-besarkan,
kami dapat menyebutnya 'pendekatan pemrogram' untuk pengembangan perangkat
lunak. Terlalu banyak perangkat lunak yang masih dikembangkan tanpa fase desain
yang jelas. Ada banyak alasan untuk sikap 'pertama kode, desain kemudian':
�
317
buktinya mungkin sangat berbeda. Hal yang sama berlaku untuk desain perangkat lunak. Kami
seharusnya tidak membingungkan hasil dari proses desain dengan proses itu sendiri. Itu
hasil dari proses desain adalah 'rekonstruksi rasional' dari proses itu. (Perhatikan bahwa
kami membuat pernyataan yang persis sama sehubungan dengan hasil persyaratan
proses rekayasa)
Desain perangkat lunak adalah 'masalah jahat'. Istilah ini berasal dari penelitian tentang
sifat masalah desain dalam masalah perencanaan sosial. Sifat masalah jahat di
area ini sangat mirip dengan properti desain perangkat lunak:
�
Daripada mendekati desain sistem dari sudut pandang bahwa kelemahan

manusia perlu dikompensasi, kita dapat mengambil sikap yang berbeda dan
mempertimbangkan sistem terkomputerisasi sebagai sarana untuk mendukung
kekuatan manusia. Demikian pula, sistem tidak hanya mencerminkan kepentingan
pemilik sistem saja. Dalam dunia yang demokratis, sistem dapat dirancang
sedemikian rupa sehingga semua pihak yang terlibat mendapat manfaat. Sikap yang
kurang teknokratis ini mengarah pada keterlibatan pengguna yang luas selama
semua tahap pengembangan sistem. Metode pengembangan tangkas mendukung
jenis pendekatan ini.
Sedangkan pengembangan sistem tradisional memiliki a produksi pandangan di
mana aspek teknis dioptimalkan, 'sekolah Skandinavia' memberikan perhatian yang
sama terhadap sistem manusia, dan memegang pandangan bahwa teknologi harus
sesuai dengan kebutuhan organisasi dan sosial. Berbagai kemungkinan mode
interaksi antara perancang atau analis di satu sisi dan pengguna di sisi lain juga
dibahas di bagian 9.1. Dalam bab ini, kami berkonsentrasi pada masalah teknis
desain perangkat lunak.
Pendekatan tangkas murni Mengerjakan sarankan untuk memulai dengan
hanya menanam beberapa umbi di salah satu sudut taman. Jika kita kebetulan
pindah ke rumah baru kita di akhir musim gugur dan menginginkan beberapa warna
saat musim semi tiba, ini terdengar seperti hal terbaik yang bisa kita lakukan. Jika
kita berubah pikiran di suatu saat nanti, kita selalu dapat memindahkan umbi dan
membuat desain taman tambahan. Dengan demikian tergantung pada situasi yang
dihadapi seberapa banyak desain awal yang layak. Dalam bab ini, kami
mengasumsikan konteks dan persyaratan yang cukup diketahui untuk menjamin
langkah desain yang eksplisit.
Dari sudut pandang teknis, masalah desain dapat dirumuskan sebagai berikut:
bagaimana kita dapat menguraikan sistem menjadi bagian-bagian sedemikian rupa
sehingga setiap bagian memiliki kompleksitas yang lebih rendah daripada sistem
secara keseluruhan, sementara bagian-bagian tersebut bersama-sama
menyelesaikan masalah pengguna. Karena kompleksitas masing-masing komponen
harus masuk akal, penting agar interaksi antar komponen tidak terlalu rumit.
Desain memiliki keduanya a produk aspek dan a proses aspek. Aspek produk
mengacu pada hasil, sedangkan aspek proses adalah tentang bagaimana kita
mencapainya. Pada tingkat desain arsitektural yang sangat global, ada sedikit
panduan proses, dan hasilnya sangat ditentukan oleh pengalaman perancang. Oleh
karena itu, bab 11 sebagian besar berfokus pada karakterisasi hasil proses desain
global, yaitu arsitektur perangkat lunak. Dalam bab ini, kita fokus pada tahapan
desain yang lebih rinci, di mana lebih banyak panduan proses telah terakumulasi
dalam sejumlah metode desain perangkat lunak. Tetapi untuk tahapan desain
perangkat lunak yang lebih rinci juga, aspek representasi adalah yang lebih penting.
Representasi ini adalah sarana komunikasi utama antara perancang dan pemangku
kepentingan lainnya. Tidak seperti bidang desain klasik lainnya, tidak ada hubungan
visual antara representasi desain sistem perangkat lunak dan produk akhir. Cetak
biru sebuah jembatan memberi kita banyak petunjuk visual tentang bagaimana
jembatan itu pada akhirnya akan terlihat. Tidak demikian halnya dengan perangkat
lunak, dan kami harus mencari cara lain untuk mengkomunikasikan pengetahuan
desain kepada pemangku kepentingan kami. Sebenarnya tidak ada metode desain
universal. Proses desain adalah proses yang kreatif, dan kualitas serta keahlian
para desainer merupakan penentu penting untuk keberhasilannya. Namun, selama
bertahun-tahun sejumlah ide dan panduan telah muncul yang mungkin
12.1. PERTIMBANGAN DESAIN 319
melayani kami dalam merancang perangkat lunak.
Prinsip terpenting dari desain perangkat lunak adalah penyembunyian informasi. Dia
mencontohkan cara melamar abstraksi dalam desain perangkat lunak. Abstraksi berarti kita
berkonsentrasi pada isu-isu penting dan mengabaikan, abstrak dari, detail yang tidak relevan
di panggung ini. Mempertimbangkan kompleksitas masalah yang harus kita selesaikan, terapkan
semacam abstraksi adalah kebutuhan belaka. Sangat tidak mungkin untuk menerima semuanya
rincian sekaligus.
Bagian 12.1 paling banyak membahas fitur desain yang diinginkan yang berkaitan dengan masalah
kualitas
terutama pemeliharaan dan penggunaan kembali. Lima masalah diidentifikasi yang memiliki kuat
berdampak pada kualitas desain: abstraksi, modularitas, penyembunyian informasi,
kompleksitas, dan struktur sistem. Penilaian desain sehubungan dengan masalah ini
memungkinkan kami untuk mendapatkan kesan kualitas desain, meskipun belum terlalu kuantitatif.
Upaya untuk mengukur heuristik tersebut telah menghasilkan sejumlah metrik khusus
ditujukan untuk sistem berorientasi objek.
Ada sejumlah besar metode desain, banyak di antaranya sangat terkait dengan a
notasi tertentu. Metode ini memberikan strategi dan heuristik untuk memandu desain
proses. Sebagian besar metode menggunakan notasi grafis untuk menggambarkan desain. Meskipun
rincian metode dan notasi tersebut sangat berbeda, dimungkinkan untuk memberikan luas
penokohan di beberapa kelas. Karakteristik penting dari kelas-kelas tersebut adalah
diuraikan dalam bagian 12.2 dan 12.3.
Pola desain adalah kumpulan dari beberapa modul (atau, dalam lingkaran berorientasi objek,
kelas) yang sering digunakan dalam kombinasi, dan yang bersama-sama memberikan manfaat
abstraksi. Pola desain adalah solusi berulang untuk masalah standar. Itu
kebalikan dari pola adalah antipattern: kesalahan sering dibuat. Prototipikal
contoh pola adalah pola MVC (Model--View--Controller) yang diketahui dari
Obrolan kecil. Pola desain dibahas pada bagian 12.5.
Selama proses desain pun, cukup banyak dokumentasi yang akan dihasilkan.
Dokumentasi ini melayani berbagai pengguna, seperti manajer proyek, desainer, penguji,
dan programmer. Bagian 12.6 membahas Standar IEEE 1016. Standar ini berisi
pedoman yang berguna untuk menggambarkan desain perangkat lunak. Standar mengidentifikasi
sejumlah
peran dan menunjukkan, untuk setiap peran, jenis dokumentasi desain yang diperlukan.
Terakhir, bagian 12.7 membahas beberapa teknik verifikasi dan validasi yang
dapat berhasil diterapkan pada tahap desain.
12.1 Pertimbangan Desain

Sampai sekarang kami telah menggunakan gagasan 'modul' dengan cara yang agak intuitif. Bukan itu
mudah untuk memberikan definisi yang akurat dari gagasan itu. Jelas, modul tidak
menunjukkan beberapa perangkat lunak acak. Kami menerapkan kriteria tertentu saat membusuk
suatu sistem menjadi modul.
Pada tingkat bahasa pemrograman, modul biasanya mengacu pada unit yang dapat diidentifikasi
sehubungan dengan kompilasi. Kami akan menggunakan definisi serupa dari istilah 'modul' dengan
sehubungan dengan desain: modul adalah unit yang dapat diidentifikasi dalam desain. Ini mungkin terdiri
dari a
prosedur tunggal, atau kelas, atau bahkan satu set kelas. Ini lebih disukai memiliki
antarmuka yang bersih ke dunia luar, dan fungsionalitas modul kemudian hanya
didekati melalui antarmuka itu.
Pada prinsipnya ada banyak cara untuk mendekomposisi sistem menjadi modul.
Jelas, tidak setiap dekomposisi sama-sama diinginkan. Pada bagian ini kita tertarik
pada fitur dekomposisi yang diinginkan, terlepas dari jenis sistem atau metode
desain yang digunakan. Fitur-fitur ini dalam arti tertentu dapat digunakan sebagai
ukuran kualitas desain. Desain yang memiliki fitur-fitur tersebut dianggap lebih
unggul daripada yang tidak memilikinya.
Fitur desain yang paling kami minati adalah fitur yang memfasilitasi
pemeliharaan dan penggunaan kembali: kesederhanaan, pemisahan konsep yang
jelas ke dalam modul yang berbeda, dan visibilitas terbatas (yaitu lokalitas)
informasi.1 Sistem yang memiliki sifat-sifat tersebut lebih mudah dipelihara karena
kita dapat memusatkan perhatian kita pada bagian-bagian yang secara langsung
dipengaruhi oleh suatu perubahan. Sifat-sifat ini juga berpengaruh pada usabilitas,
karena modul yang dihasilkan cenderung memiliki fungsionalitas yang terdefinisi
dengan baik yang sesuai dengan konsep dari domain aplikasi. Modul semacam itu
kemungkinan besar akan dimasukkan ke dalam sistem lain yang mengatasi
masalah dari domain yang sama.
Dalam subbab berikut kita membahas lima masalah yang saling terkait yang
berdampak kuat pada ciri-ciri di atas:
– abstraksi,
– modularitas,
- menyembunyikan informasi,
- kompleksitas, dan
– struktur sistem.
Untuk sistem berorientasi objek, serangkaian heuristik kualitas dan metrik terkait
telah ditentukan. Metrik berorientasi objek utama dibahas di bagian 12.1.6.
12.1.1 Abstraksi
Abstraksi berarti kita berkonsentrasi pada fitur-fitur esensial dan mengabaikan,
abstractfrom, detail yang tidak relevan dengan level yang sedang kami kerjakan.
Pertimbangkan, misalnya, modul pengurutan tipikal. Dari luar kita tidak bisa (dan
tidak perlu bisa) membedakan dengan tepat bagaimana proses penyortiran
berlangsung. Kita hanya perlu mengetahui bahwa output memang disortir. Pada
tahap selanjutnya, ketika rincian modul pengurutan sudah diputuskan, maka kita
dapat memeras otak tentang algoritma pengurutan yang paling cocok.
1Jelas, fitur desain yang lebih penting adalah bahwa sistem yang sesuai harus melakukan tugas yang
diperlukan dengan cara yang ditentukan. Untuk tujuan ini, desain harus divalidasi terhadap persyaratan.
Kompleksitas sebagian besar masalah perangkat lunak membuat penerapan abstraksi menjadi sulit
kebutuhan. Dalam diskusi selanjutnya, kami membedakan dua jenis abstraksi: prosedural
abstraksi Dan abstraksi data.
Gagasan abstraksi prosedural cukup tradisional. Sebuah bahasa pemrograman
gauge menawarkan if-constructs, loop-constructs, pernyataan penugasan, dan sejenisnya. Itu
transisi dari masalah yang harus dipecahkan ke konstruksi bahasa primitif ini adalah a
besar dalam banyak kasus. Untuk tujuan ini masalah pertama-tama didekomposisi menjadi submasalah,
yang masing-masing ditangani secara bergiliran. Submasalah ini sesuai dengan tugas utama untuk
dicapai. Mereka dapat dikenali dari deskripsi mereka di mana beberapa kata kerja
memainkan peran sentral (misalnya: membaca masukan, menyortir semua catatan, proses pengguna
berikutnya
meminta, menghitung gaji bersih). Jika perlu, submasalah didekomposisi lebih lanjut menjadi
submasalah yang lebih sederhana. Akhirnya kita sampai pada submasalah yang standarnya
solusi tersedia. Jenis dekomposisi (dari atas ke bawah) ini adalah inti dari
gaya arsitektur main-program-with-subroutines.
Hasil dari jenis dekomposisi bertahap ini adalah struktur hierarkis. Itu
node atas struktur menunjukkan masalah yang harus dipecahkan. Tingkat selanjutnya menunjukkannya
dekomposisi pertama menjadi submasalah. Daun menunjukkan masalah primitif. Ini
digambarkan secara skematis pada gambar 12.1.
Konsep prosedur memberi kita notasi untuk submasalah yang dihasilkan dari
proses dekomposisi ini. Penerapan konsep ini dikenal sebagai prosedural
abstraksi. Dengan abstraksi prosedural, nama prosedur (atau metode, dalam
bahasa berorientasi objek) digunakan untuk menunjukkan urutan tindakan yang sesuai.
Ketika nama itu digunakan dalam sebuah program, kita tidak perlu pusing tentang tepatnya
cara di mana efeknya direalisasikan. Yang penting, setelah panggilan, pasti
persyaratan prestated terpenuhi.
Cara menjalani proses ini sangat cocok dengan cara manusia
cenderung memecahkan masalah. Manusia juga cenderung untuk penanganan bertahap
masalah. Abstraksi prosedural dengan demikian menawarkan sarana penting untuk menangani
perangkat lunak
masalah.
Saat merancang perangkat lunak, kami cenderung menguraikan masalahnya sedemikian rupa
hasilnya memiliki orientasi waktu yang kuat. Suatu masalah didekomposisi menjadi submasalah
yang saling mengikuti dalam waktu. Dalam bentuknya yang paling sederhana, pendekatan ini
menghasilkan input-
-proses-skema keluaran: sebuah program pertama-tama harus membaca dan menyimpan datanya,
selanjutnya beberapa
proses menghitung output yang diperlukan dari data ini, dan hasilnya akhirnya adalah output.
Penerapan teknik ini dapat mengakibatkan program yang sulit diadaptasi dan
sulit untuk dipahami. Menerapkan abstraksi data menghasilkan dekomposisi yang
menunjukkan penderitaan ini ke tingkat yang jauh lebih rendah.
Abstraksi prosedural ditujukan untuk menemukan hierarki dalam kontrol program
struktur: langkah mana yang harus dijalankan dan urutannya. Abstraksi data adalah
bertujuan menemukan hierarki dalam data program. Penawaran bahasa pemrograman
struktur data primitif untuk bilangan bulat, bilangan real, nilai kebenaran, karakter dan
mungkin beberapa lagi. Menggunakan blok bangunan ini kita dapat membangun lebih rumit
struktur data, seperti tumpukan dan pohon biner. Struktur seperti itu digunakan secara umum di
Gambar 12.1 Gagasan abstraksi prosedural
aplikasi perangkat lunak. Mereka terjadi pada tingkat yang cukup rendah dalam
hierarki struktur data. Objek berorientasi aplikasi, seperti 'paragraf' dalam perangkat
lunak pengolah teks atau 'buku' dalam sistem perpustakaan kami, ditemukan di
tingkat yang lebih tinggi dari hierarki struktur data. Ini secara skematis digambarkan
pada Gambar 12.2.
Gambar 12.2 Gagasan abstraksi data
Untuk data juga, kami ingin mengabstraksi dari detail yang tidak relevan pada tingkat tertentu.
Faktanya, kami sudah melakukannya saat menggunakan struktur data primitif yang ditawarkan
oleh bahasa pemrograman kami. Dalam menggunakan ini, kami abstrak dari detail seperti
representasi internal angka dan cara penambahan dua angka direalisasikan. Pada tingkat
bahasa pemrograman kita dapat melihat bilangan bulat sebagai satu set
objek (0, 1, -1, 2, -2, . . .
) dan sekumpulan
operasi pada objek
tersebut ( +
objek (semua pohon biner yang dapat dibayangkan) dan serangkaian operasi pada objek tersebut.
Kapan
menggunakan pohon biner, representasi mereka dan implementasi yang sesuai
operasi tidak perlu menjadi perhatian kita. Kita hanya perlu memastikan efek yang diinginkan dari
operasi.
Menerapkan abstraksi data selama desain terkadang disebut Berorientasi pada objek
desain, karena jenis objek dan operasi terkait dienkapsulasi menjadi satu
modul. Namun kata kunci 'berorientasi objek' juga memiliki arti yang sedikit berbeda.
Kami akan menguraikan lebih lanjut gagasan ini di bagian 12.3.
Bahasa seperti Ada, Java dan C++ menawarkan konstruksi bahasa (disebut kemasan,
kelas, Dan struct, masing-masing) yang memungkinkan kita mempertahankan pemisahan sintaksis
antara implementasi dan spesifikasi tipe data. Perhatikan bahwa itu juga
mungkin untuk menerapkan abstraksi data selama desain ketika bahasa pamungkas tidak
menawarkan konsep Namun, kemudian menjadi lebih rumit untuk berpindah dari desain
untuk kode.
Kami perhatikan sebelumnya bahwa abstraksi prosedural sangat cocok dengan cara manusia
cenderung mengatasi masalah. Bagi kebanyakan orang, abstraksi data sedikit lebih rumit.
Saat mencari solusi untuk masalah perangkat lunak, kami akan menemukan bahwa
solusi membutuhkan struktur data tertentu. Pada titik tertentu kita juga harus memilih a
representasi untuk struktur data ini. Daripada membuat keputusan itu lebih awal
panggung dan memaksakan hasilnya pada semua komponen lain, Anda lebih baik jika Anda
membuatnya
submasalah terpisah dan hanya membuat prosedural, implementasi-independen,
antarmuka publik. Abstraksi data dengan demikian adalah contoh utama dari penyembunyian informasi.
Perkembangan teknik abstraksi ini berjalan beriringan dengan yang lain
perkembangan, khususnya yang ada di ranah bahasa pemrograman. Prosedur
awalnya diperkenalkan untuk menghindari pengulangan urutan instruksi. Nanti
tahap kami melihat nama prosedur sebagai abstraksi yang sesuai
urutan instruksi. Baru pada saat itulah gagasan abstraksi prosedural mendapatkan miliknya
konotasi kekinian. Dalam nada yang sama, perkembangan di bidang tipe data formal
spesifikasi dan gagasan bahasa untuk modul (dimulai dengan kelas konsep dari
SIMULA-67) sangat berkontribusi pada gagasan abstraksi data kami saat ini.
Sebagai catatan terakhir kami berkomentar bahwa kami dapat mengidentifikasi jenis abstraksi ketiga,
kontrol abstraksi.Dalam abstraksi kontrol, kami mengabstraksi dari urutan yang tepat
urutan peristiwa yang harus ditangani. Meskipun abstraksi kontrol seringkali tersirat
ketika abstraksi prosedural digunakan, terkadang nyaman untuk dapat secara eksplisit
memodelkan jenis ketidaktentuan ini, misalnya ketika menentukan sistem bersamaan.
Topik ini berada di luar cakupan buku ini.
12.1.2 Modularitas
Selama desain, sistem didekomposisi menjadi sejumlah modul dan hubungan antar
modul tersebut ditunjukkan. Dalam desain lain dari sistem yang sama, modul yang
berbeda mungkin muncul dan mungkin ada hubungan yang berbeda antar modul.
Kita dapat mencoba membandingkan desain tersebut dengan mempertimbangkan
keduanya a
tipologi untuk masing-masing modul dan jenis koneksi di antara mereka. Ini
membawa kita ke dua kriteria desain struktural: kohesi Dan kopel.
Kohesi dapat dipandang sebagai perekat yang menyatukan modul. Ini adalah
ukuran afinitas timbal balik dari elemen modul. Secara umum kami ingin membuat
kohesi sekuat mungkin. Dalam teks klasik mereka aktif Desain Terstruktur, Yourdon
dan Constantine mengidentifikasi tujuh tingkat kohesi kekuatan yang meningkat
berikut ini:
�
�
�
�
Dalam pengertian yang sangat umum, kompleksitas suatu masalah mengacu pada
jumlah sumber daya yang diperlukan untuk solusinya. Kita dapat mencoba
menentukan kompleksitas dengan cara ini dengan mengukur, katakanlah, waktu
yang dibutuhkan untuk menyelesaikan suatu masalah. Inilah yang disebut
luaratribut: kita tidak melihat entitas itu sendiri (masalahnya), tetapi bagaimana
perilakunya. Dalam konteks sekarang, kompleksitas mengacu pada atribut
perangkat lunak yang mempengaruhi upaya yang diperlukan untuk membangun
atau mengubah perangkat lunak. Ini adalah internatribut: mereka dapat diukur murni
dalam hal perangkat lunak itu sendiri. Misalnya, kita tidak perlu menjalankan
perangkat lunak untuk menentukan nilainya.
Kedua pengertian ini sangat berbeda dengan kompleksitas komputasi yang
dilakukan (berkaitan dengan waktu atau memori yang dibutuhkan). Yang terakhir
adalah bidang yang mapan di mana banyak hasil telah diperoleh. Ini kurang benar
untuk jenis kompleksitas yang kita minati. Kompleksitas perangkat lunak dalam
pengertian ini masih merupakan gagasan yang sulit dipahami.
Upaya serius telah dilakukan untuk mengukur kompleksitas perangkat lunak
secara kuantitatif. Metrik yang dihasilkan dimaksudkan untuk digunakan sebagai titik
jangkar untuk dekomposisi sistem, untuk menilai kualitas desain atau program,
untuk memandu upaya rekayasa ulang, dll. Kami kemudian mengukur atribut
tertentu dari sistem perangkat lunak, seperti panjangnya, jumlah pernyataan if, atau
aliran informasi antar modul, dan mencoba menghubungkan angka yang diperoleh
dengan kompleksitas sistem. Jenis atribut perangkat lunak yang dianggap dapat
dikategorikan secara luas menjadi dua kelas:
– atribut intra-modular adalah atribut modul individu, dan
– atribut inter-modular adalah atribut dari sistem yang dipandang sebagai

kumpulan dari modul dengan dependensi.
Dalam subbagian ini kita berurusan dengan atribut intra-modular. Atribut

inter-modular dibahas pada sub-bagian berikutnya. Kami dapat membedakan dua
kelas metrik kompleksitas:
�
ditelusuri kembali ke penelitian dalam psikologi, yang menunjukkan bahwa memori manusia
disusun secara hierarkis dengan memori jangka pendek sekitar tujuh slot, sementara di sana
adalah memori yang lebih permanen dengan kapasitas hampir tak terbatas. Jika ada lebih dari
tujuh potong informasi, semuanya tidak dapat disimpan dalam memori jangka pendek dan
informasi menjadi hilang.
Ada keberatan serius terhadap penggunaan langsung jumlah baris kode sebagai
metrik kompleksitas. Beberapa programmer menulis lebih banyak program verbose daripada yang lain.
Setidaknya kita harus menormalkan penghitungan untuk menangkal efek ini dan mampu melakukannya
membandingkan perangkat lunak yang berbeda. Ini dapat dicapai dengan menggunakan printer cantik,
perangkat lunak yang mereproduksi program dalam bahasa tertentu dengan cara yang seragam.
Keberatan kedua adalah bahwa teknik ini membuat sulit untuk membandingkan program
ditulis dalam berbagai bahasa. Jika masalah yang sama diselesaikan dalam bahasa yang berbeda,
hasilnya mungkin sangat berbeda panjangnya. Misalnya, APL lebih kompak dari
COBOL.
Akhirnya, beberapa baris lebih kompleks dari yang lain. Tugas seperti
a:=b
terlihat lebih sederhana daripada loop
ketika P "
330 DESAIN
PERANGKAT
1 prosedur menyortir(dulu x: larik; n: bilangan LUNAK
bulat);
2 dulu i, j, simpan: bilangan bulat;
3 mulai
5 untuk j:= 1 ke Saya
Mengerjakan
6 jika x[i]
<
Ini adalah jumlah bit minimal yang diperlukan untuk disimpan N
332 DESAIN
PERANGKAT
LUNAK
Tabel 12.2 Nilai untuk 'ilmu perangkat lunak'
entitas untuk contoh program di
gambar 12.3
Kesatuan Nilai
Kosakata ukuran 21
Panjang program 60
Perkiraan panjang program 73
Volume program 264
Tingkat abstraksi 0,044
Perkiraan tingkat abstraksi 0,040
Upaya pemrograman 6000
Perkiraan waktu pemrograman 333s
Orang yang berbeda menggunakan definisi yang sangat berbeda tentang pengertian
operator dan operan, yang dapat menyebabkan hasil yang sangat berbeda untuk
nilai entitas. Namun, karya Halstead sangat berpengaruh. Itu adalah badan
kerja besar pertama yang menunjukkan potensi metrik perangkat lunak untuk
pengembangan perangkat lunak.
Kelas kedua dari metrik kompleksitas intra-modular menyangkut metrik

berdasarkan struktur perangkat lunak. Jika kita mencoba menurunkan metrik
kompleksitas dari struktur perangkat lunak, kita dapat berfokus pada struktur kontrol,
struktur data, atau kombinasi dari semuanya.
Jika kita mendasarkan metrik kompleksitas pada penggunaan struktur data,
misalnya kita dapat melakukannya dengan mempertimbangkan jumlah instruksi
antara referensi berurutan ke satu dan objek yang sama. Jika angka ini besar,
informasi tentang variabel-variabel ini harus dipertahankan untuk jangka waktu yang
lama ketika kita mencoba untuk memahami teks program tersebut. Mengikuti garis
pemikiran ini, kompleksitas dapat dikaitkan dengan jumlah rata-rata variabel yang
informasinya harus disimpan oleh pembaca.
Metrik kompleksitas yang paling terkenal dari kelas metrik kompleksitas berbasis
struktur adalah milik McCabe kompleksitas siklomatis. McCabe mendasarkan metrik
kompleksitasnya pada grafik (diarahkan) yang menggambarkan aliran kontrol
program. Dia berasumsi bahwa grafik prosedur tunggal atau program utama tunggal
memiliki node awal dan akhir yang unik, bahwa setiap node dapat dijangkau dari
node awal, dan bahwa node akhir dapat dicapai dari setiap node. Dalam hal ini,
grafik terhubung. Jika program terdiri dari satu program utama dan satu atau lebih
prosedur, maka grafik kontrol memiliki sejumlah komponen yang terhubung, satu
untuk program utama dan satu untuk setiap prosedurnya. Kompleksitas
siklomatikCV
12.1. PERTIMBANGAN DESAIN
Metrik kompleksitas seperti yang dimiliki Halstead, McCabe, dan banyak lainnya,
semua atribut ukuran yang dalam arti tertentu terkait dengan ukuran tugas yang
harus diselesaikan, baik itu waktu dalam bulan kerja, jumlah baris kode, atau yang
lainnya. Dengan demikian mereka dapat melayani berbagai tujuan: menentukan
ukuran modul yang optimal, memperkirakan jumlah kesalahan dalam modul, atau
memperkirakan biaya perangkat lunak.
Namun, semua metrik kompleksitas yang diketahui mengalami beberapa
kekurangan serius:
�
seharusnya tidak mengejutkan. Program besar cenderung memiliki lebih banyak
pernyataan if daripada program kecil. Namun, yang penting adalah kepadatan
dengan mana pernyataan-jika itu terjadi. Ini menunjukkan metrik kompleksitas
formulir
CV
Gambar 12.5 Hirarki modul. (a) grafik berarah, (b) grafik asiklik berarah, (c) grafik
berlapis, (d) pohon
�
untuk mengidentifikasi prosedur UNIX yang rawan perubahan dan mengevaluasi
potensi perubahan desain. (Shepperd, 1990) mempelajari ukuran aliran informasi
secara ekstensif dan mengusulkan beberapa penyempurnaan, sehingga
memperoleh metrik yang 'lebih murni'. Menggunakan definisi Shepperd, ukuran
aliran informasi didasarkan pada gagasan aliran data lokal dan global berikut:
�
pengelompokan ini menghasilkan tipe data abstrak atau, lebih umum, modul yang memiliki tinggi
kohesi. Jika ukuran didasarkan pada jumlah pengikatan data antar elemen,
hasilnya cenderung memiliki nilai yang rendah untuk metrik arus informasi.
Ukuran yang dipilih, dalam arti tertentu, menentukan bagaimana kita mendefinisikan 'persahabatan'
antara
elemen. Teman dekat harus dikelompokkan dalam modul yang sama sedangkan kerabat jauh
mungkin berada di modul yang berbeda. Berbagai desain kualitatif dan kuantitatif
kriteria yang kita bahas di atas memiliki definisi yang berbeda, tetapi pada dasarnya sangat mirip
persahabatan.
Meskipun masih banyak pekerjaan yang harus dilakukan, penggunaan metrik desain yang tersedia
dengan bijaksana
sudah menjadi alat yang berharga dalam desain dan jaminan kualitas sistem perangkat lunak.
12.1.6 Metrik Berorientasi Objek

Pada tingkat metode individu dari sistem berorientasi objek, kita dapat menilai
karakteristik kualitas komponen dengan metrik yang sudah dikenal seperti: panjang,
kompleksitas siklomatis, dan sejenisnya. Pada tingkat abstraksi yang lebih tinggi,
sistem berorientasi objek terdiri dari kumpulan kelas yang berinteraksi dengan
mengirimkan pesan. Metrik antar-modular yang familiar yang berfokus pada
hubungan antar modul tidak memperhitungkan spesifikasi sistem berorientasi objek.
Pada bagian ini, kita membahas beberapa metrik yang secara khusus ditujukan
pada karakteristik sistem berorientasi objek. Metrik ini tercantum dalam gambar
12.6.
WMC Metode Berbobot per Kelas

DIA Kedalaman kelas di Pohon Warisan
MALAM Jumlah anak
CBO Kopling Antara kelas Obyek
RFC Tanggapan Untuk Kelas
LCOM Kurangnya Kohesi Metode
Gambar 12.6 Serangkaian metrik berorientasi objek
WMC adalah ukuran untuk ukuran kelas. Asumsinya adalah bahwa kelas yang lebih besar
pada umumnya kurang diminati. Mereka membutuhkan lebih banyak waktu untuk
mengembangkan dan memelihara, dan memang begitu
P
cenderung kurang dapat digunakan kembali.

Rumusnya adalah: WMC =
misalnya, konstruktor yang berbeda untuk satu operasi yang sama, seperti
kebiasaan di C++, dihitung sebagai metode yang berbeda.
Kelas dalam desain berorientasi objek terkait melalui subtipe-hierarki supertipe.
Jika hierarki kelas dalam dan sempit, pemahaman yang tepat tentang sebuah kelas
mungkin membutuhkan pengetahuan tentang banyak superkelasnya. Di sisi lain,
struktur pewarisan yang luas dan dangkal terjadi ketika kelas digabungkan secara
lebih longgar. Situasi terakhir mungkin menunjukkan bahwa kesamaan antar elemen
tidak cukup dieksploitasi. DIT adalah jarak kelas ke akar pohon warisannya.
Perhatikan bahwa nilai DIT agak bergantung pada bahasa. Di Smalltalk, misalnya,
setiap kelas adalah subkelas dari Obyek, dan ini meningkatkan nilai DIT. Heuristik
yang diterima secara luas adalah memperjuangkan hutan kelas, yaitu kumpulan
pohon warisan dengan tinggi sedang.
NOC menghitung jumlah keturunan langsung dari suatu kelas. Jika suatu kelas
memiliki jumlah keturunan yang banyak, hal ini mungkin menunjukkan abstraksi
yang tidak tepat dari kelas induknya. Sejumlah besar keturunan juga menunjukkan
bahwa kelas tersebut akan digunakan dalam berbagai pengaturan, yang akan
membuatnya lebih rawan kesalahan. Idenya adalah bahwa nilai NOC yang lebih
tinggi menunjukkan kompleksitas kelas yang lebih tinggi.
CBO adalah metrik kopling utama untuk sistem berorientasi objek. Dua kelas
digabungkan jika metode dari satu kelas menggunakan metode atau variabel status
dari kelas lainnya. CBO adalah hitungan jumlah kelas lain yang digabungkan
dengannya. Seperti dengan metrik kopling tradisional, nilai CBO yang tinggi
menunjukkan pengikatan yang ketat dengan komponen lain, dan ini tidak diinginkan.
Dalam definisi CBO, semua kopling dianggap sama. Namun, jika kita melihat
cara yang berbeda di mana kelas dapat digabungkan, masuk akal untuk
mengatakan bahwa:
– akses ke variabel status lebih buruk daripada sekadar melewati

parameter;
– akses ke elemen kelas asing lebih buruk daripada akses ke elemen a

kelas super;
– melewati banyak parameter kompleks lebih buruk daripada melewati beberapa

parameter sederhana;
– pesan yang sesuai dengan Hukum Demeter4 lebih baik daripada yang tidak.
Jika kita melihat metode sebagai gelembung, dan kopling sebagai koneksi antar
gelembung, CBO hanya menghitung jumlah koneksi untuk setiap gelembung. Pada
kenyataannya, kami menganggap beberapa jenis kopling lebih buruk daripada yang
lain: beberapa koneksi 'lebih tebal' daripada yang lain, dan beberapa koneksi ke
gelembung 'lebih jauh'. Untuk perwakilan
4Hukum Demeter adalah heuristik desain yang diterima secara umum untuk sistem berorientasi objek.
Dikatakan bahwa metode kelas seharusnya hanya bergantung pada struktur tingkat atas kelas mereka
sendiri. Lebih khusus lagi, dalam konteks kelas C dengan metode M, M seharusnya hanya mengirim pesan
ke:
– parameter C, atau
– variabel keadaan C, atau
– C itu sendiri.
kondisi teori pengukuran untuk dipegang, hubungan empiris ini harus tercermin
dalam sistem relasi numerik.
Martin (2002) mendefinisikan tindakan penggabungan pada tingkat paket:
�
selama desain, dan ditemukan memiliki hubungan yang kuat dengan upaya
pemeliharaan. Keunggulan DIT dan NCO masih belum jelas.
Perhatikan bahwa banyak dari metrik ini berkorelasi dengan ukuran kelas. Orang
mungkin berharap bahwa kelas yang lebih besar memiliki lebih banyak metode,
memiliki lebih banyak turunan, memiliki lebih banyak sambungan dengan kelas lain,
dll. El Emam et al. (2001) memang menemukan bahwa ukuran kelas memiliki efek
perancu pada nilai-nilai metrik di atas. Dengan demikian tetap dipertanyakan apakah
metrik ini memberi tahu lebih dari jumlah LOC biasa.
12.2 Metode Desain Klasik

Setelah membahas sifat-sifat dekomposisi sistem yang baik, sekarang kita sampai
pada pertanyaan yang setidaknya sama pentingnya: bagaimana cara memulai
dekomposisi yang baik?
Ada sejumlah besar metode desain, contoh yang diberikan dalam tabel 12.3.
Metode desain ini umumnya terdiri dari seperangkat pedoman, heuristik, dan
prosedur tentang cara merancang sistem. Mereka juga menawarkan notasi untuk
mengekspresikan hasil dari proses desain. Bersama-sama ini menyediakan a
sistematis berarti untuk mengatur dan menyusun proses desain dan produknya.
12.2. METODE DESAIN KLASIK 343
dilanjutkan di halaman berikutnya
Tabel 12.3 Contoh metode desain
Tabel keputusan Representasi matriks dari logika keputusan yang kompleks pada detailnya
tingkat desain.
E--R Entitas--Model Hubungan. Keluarga teknik grafis untuk
mengungkapkan data-hubungan; lihat juga bab 10.
Bagan alur Teknik diagram sederhana untuk menunjukkan aliran kontrol pada level
desain detail. Ada dalam banyak rasa; lihat (Tripp, 1988) untuk tinjauan
FSM umum.
Mesin Negara Hingga. Suatu cara untuk menggambarkan suatu sistem
JSD sebagai sekumpulan keadaan dan kemungkinan transisi antara keadaan
tersebut; diagram yang dihasilkan disebut diagram transisi keadaan;
lihat juga bab 10. Pengembangan Sistem Jackson; lihat bagian 12.2.3.
JSP Penerus, dan lebih rumit dari, JSP; memiliki rasa berorientasi objek.
Jackson Tersusun Pemrograman. Berorientasi

struktur data
LCP metode; lihat bagian 12.2.3.
Konstruksi Logis Program, juga dikenal sebagai Peringatan--
Kartu metode Orr; berorientasi struktur data, mirip dengan JSP.
Catatan
Contoh sistem hypertext. Sistem hypertext memungkinkan untuk
membuat dan menavigasi melalui organisasi kompleks dari potongan
teks yang tidak terstruktur (Conklin, 1987).
OBJ
metode spesifikasi aljabar; sangat matematis (Goguen,
1986).
OOD
Desain berorientasi objek; ada dalam banyak rasa; lihat bagian
PDL 12.3.Bahasa Desain Program; contoh bahasa alami yang dibatasi
('Bahasa Inggris terstruktur') untuk mendeskripsikan desain pada
berbagai tingkat abstraksi. Menawarkan konstruk kontrol yang umumnya
ditemukan dalam bahasa pemrograman. Lihat (Pintelas dan
Kallistros,1989) untuk tinjauan umum.
jaring Petri Representasi desain grafis, sangat cocok

untuk sistem konkuren. Suatu sistem
digambarkan sebagai sekumpulan
keadaan dan kemungkinan transisi
SA/SD antara keadaan tersebut. Status
diasosiasikan dengan token dan transisi
dijelaskan dengan aturan pemecatan.
SA/RT Dengan cara ini, kegiatan bersamaan
dapat disinkronkan (Peterson, 1981).
SSADM Analisis Terstruktur/Desain Terstruktur.
Teknik desain aliran data; lihat juga bagian
12.2.2.
Ekstensi untuk Analisis Terstruktur sehingga
aspek real-time dapat dijelaskan (Hatley dan
Pirbhai, 1988).
Metode Analisis dan Perancangan Sistem
Terstruktur. Metode yang sangat preskriptif
untuk melakukan tahapan analisis dan
desain; Standar Inggris (Downs et al.,
1992).
Untuk beberapa metode, seperti FSM atau jaring Petri, penekanannya adalah pada
notasi, sedangkan panduan tentang cara menangani desain tidak dikembangkan
dengan baik. Metode seperti JSD, di sisi lain, juga menawarkan pedoman preskriptif
yang ekstensif. Sebagian besar notasi bersifat grafis dan agak informal, tetapi OBJ
menggunakan bahasa matematika yang sangat formal. Beberapa metode
berkonsentrasi pada tahap desain yang tepat, sementara yang lain merupakan
bagian dari metodologi yang lebih luas yang mencakup fase siklus hidup lainnya
juga. Contoh yang terakhir adalah SSADM dan JSD. Terakhir, beberapa metode
menawarkan fitur yang membuat metode ini sangat berguna untuk desain jenis
aplikasi tertentu, seperti SA/RT (sistem real-time) atau jaring Petri (sistem
bersamaan).
Dalam subbagian berikut kita membahas tiga metode desain klasik:
�
dapat didekomposisi lebih lanjut menjadi fungsi yang lebih primitif, dan seterusnya. Fungsional
dekomposisi adalah filosofi desain daripada metode desain. Ini menunjukkan sebuah
pendekatan keseluruhan untuk dekomposisi masalah yang mendasari banyak metode desain.
Dengan dekomposisi fungsional kami terapkan memecah dan menaklukkan taktik. Ini
taktik analog dengan, tetapi tidak sama dengan, teknik penyempurnaan bertahap sebagai
itu diterapkan dalam pemrograman-dalam-kecil. Menggunakan penyempurnaan bertahap,
penyempurnaan
cenderung bergantung pada konteks. Sebagai contoh, perhatikan pseudo-code berikut
algoritma untuk memasukkan elemen ke dalam daftar yang diurutkan:
prosedur sisipkan(a, n, x);

mulai masukkan x di akhir daftar;
k:= n + 1;
ketika elemen k
sangat tepat, atau jika keluarga sistem harus dikembangkan. Bahaya nyata dari
teknik bottom-up adalah bahwa kita mungkin meleset dari sasaran.
Dalam bentuknya yang murni, baik teknik top-down maupun bottom-up sepertinya
tidak akan sering digunakan. Kedua teknik tersebut layak hanya jika proses
desainnya murni dan rasional. Dan ini adalah idealisasi realitas. Ada banyak alasan
mengapa proses desain tidak bisa rasional. Beberapa di antaranya berkaitan
dengan proses desain yang tidak berwujud, beberapa berasal dari kecelakaan yang
menimpa banyak proyek perangkat lunak. Parnas dan Clements (1986)
mencantumkan alasan berikut, antara lain:
– Sebagian besar, pengguna tidak tahu persis apa yang mereka inginkan dan
mereka tidak tahu semua yang mereka tahu.
– Bahkan jika persyaratannya diketahui sepenuhnya, banyak informasi tambahan

diperlukan. Informasi ini ditemukan hanya ketika proyek sedang berjalan.
– Hampir semua proyek dapat berubah. Perubahan memengaruhi keputusan

sebelumnya.
– Orang membuat kesalahan.
– Selama desain, orang menggunakan pengetahuan yang sudah mereka miliki,

pengalaman dari proyek sebelumnya, dan sejenisnya.
– Dalam banyak proyek kami tidak memulai dari awal, tetapi kami membangun
dari yang sudah ada perangkat lunak.
Desain menunjukkan karakter 'yo-yo': sesuatu dirancang, dicoba, ditolak lagi, ide-ide
baru muncul, dll. Desainer sering melakukan cara yang agak oportunistik. Mereka
sering beralih dari masalah domain aplikasi tingkat tinggi ke masalah pengkodean
dan desain terperinci, dan menggunakan berbagai cara untuk mengumpulkan
wawasan tentang masalah yang harus dipecahkan. Paling-paling, kami dapat
menyajikan hasil dari proses desain seolah-olah itu terjadi melalui proses yang
rasional.
Masalah umum dengan segala bentuk dekomposisi fungsional adalah bahwa
seringkali tidak jelas sepanjang dimensi mana sistem tersebut didekomposisi. Jika
kita mendekomposisi sepanjang sumbu waktu, hasilnya seringkali berupa program
utama yang mengontrol urutan pemanggilan sejumlah modul bawahan. Dalam
klasifikasi Yourdon, jenis kohesi yang dihasilkan bersifat sementara. Jika kita
menguraikan sehubungan dengan pengelompokan data, kita memperoleh tipe
kohesi data yang diperlihatkan dalam tipe data abstrak. Kedua dekomposisi
fungsional ini dapat dilihat sebagai contoh dari beberapa gaya arsitektur. Daripada
mengkhawatirkan dimensi mana yang menjadi fokus selama dekomposisi
fungsional, Anda lebih baik memilih gaya arsitektur tertentu dan membiarkan gaya
tersebut memandu dekomposisi.
Pada beberapa tingkat menengah, kumpulan komponen yang saling terkait
terdiri dari arsitektur perangkat lunak seperti yang dibahas dalam bab 11. Arsitektur
perangkat lunak ini adalah produk yang melayani berbagai tujuan: dapat digunakan
untuk mendiskusikan desain dengan
pemangku kepentingan yang berbeda; dapat digunakan untuk mengevaluasi
kualitas desain; itu bisa menjadi dasar untuk struktur rincian pekerjaan; itu dapat
digunakan untuk memandu proses pengujian, dll. Jika arsitektur perangkat lunak
diperlukan, itu memerlukan pendekatan desain di mana, pada tahap yang cukup
awal, setiap komponen dan koneksi hadir. Pendekatan bottom-up atau top-down
tidak tidak memenuhi persyaratan ini, karena dalam kedua pendekatan ini hanya
sebagian dari solusi yang tersedia pada titik tengah waktu. Parnas (1978)
menawarkan panduan berguna berikut untuk dekomposisi fungsional yang baik:
1. Cobalah untuk mengidentifikasi subsistem. Mulailah dengan a minimal subset dan tentukan
minimal
ekstensi untuk subset ini.
Gagasan di balik panduan ini adalah sangat sulit, jika bukan tidak mungkin,
untuk mendapatkan gambaran lengkap tentang sistem selama rekayasa
persyaratan. Orang terlalu banyak bertanya atau mereka menanyakan hal
yang salah. Mulai dari subsistem minimal, kami dapat menambahkan
fungsionalitas secara bertahap, menggunakan pengalaman yang diperoleh
dengan penggunaan sistem yang sebenarnya. Idenya sangat mirip dengan
pendekatan tangkas, dibahas di bab 3.
2. Terapkan prinsip penyembunyian informasi.

3. Coba tentukan ekstensi ke mesin dasar langkah demi langkah. Ini berlaku
untuk mesin minimal dan ekstensinya. Ekstensi inkremental seperti itu mengarah
pada konsep a mesin virtual. Setiap lapisan dalam hirarki sistem dapat dilihat
sebagai sebuah mesin. Operasi primitif mesin ini diimplementasikan oleh lapisan
hierarki yang lebih rendah. Tampilan mesin dari hierarki modul ini dipetakan
dengan baik ke gaya arsitektur berlapis. Hal ini juga menambah dimensi lebih
jauh pada pedoman penataan sistem yang ditawarkan di bagian 12.1.5.
4. Terapkan hubungan penggunaan dan coba tempatkan dependensi yang diperoleh di a

struktur hirarki.
Jelas, pedoman di atas sangat terkait satu sama lain. Telah dikatakan sebelumnya
bahwa struktur pohon yang sangat hierarkis dari komponen sistem seringkali tidak layak.
Kompromi yang seringkali layak adalah struktur sistem berlapis seperti yang digambarkan dalam
gambar 12.7.
Panah antara berbagai node dalam grafik menunjukkan hubungan penggunaan.
Berbagai tingkatan dapat dibedakan dalam struktur yang digambarkan. Komponen pada suatu tertentu
level hanya menggunakan komponen dari level yang sama atau lebih rendah. Lapisan dibedakan
dalam gambar ini tidak sama dengan yang diinduksi oleh asiklikitas grafik
(seperti yang dibahas di bagian 12.1.5) tetapi lebih merupakan hasil dari melihat kumpulan yang berbeda
modul sebagai abstrak, mesin virtual. Memutuskan bagaimana mengelompokkan modul ke dalam
lapisan
dengan cara ini melibatkan mempertimbangkan semantik modul tersebut. Tingkat yang lebih rendah
dalam hal ini
hierarki membawa kita lebih dekat ke mesin 'nyata' tempat sistem itu akan dibuat
dieksekusi. Level yang lebih tinggi lebih berorientasi pada aplikasi. Pilihan nomor
level dalam arsitektur seperti itu adalah keputusan desain yang bergantung pada masalah.
Gambar 12.7 Struktur sistem berlapis
Karya Parnas ini menandai beberapa gagasan yang kemudian diakui sebagai
prinsip panduan penting dalam bidang arsitektur perangkat lunak. Gagasan subset
minimal yang ekstensi didefinisikan sangat mirip dengan gagasan arsitektur lini
produk: arsitektur dasar dari mana keluarga sistem serupa dapat diturunkan.
Pendekatan berlapis adalah salah satu gaya arsitektur dasar yang dibahas pada
bagian 11.4.
12.2.2 Desain Aliran Data (SA/SD)

Metode desain aliran data berasal dari awal 1970-an dengan Yourdon dan
Constantine. Dalam bentuknya yang paling sederhana, desain aliran data hanyalah
dekomposisi fungsional sehubungan dengan aliran data. Komponen (modul) adalah
kotak hitam yang mengubah beberapa aliran masukan menjadi beberapa aliran
keluaran. Dalam desain aliran data, banyak digunakan representasi grafis yang
dikenal sebagai Diagram Aliran Data (DFD) dan Bagan Struktur. Diagram aliran data
diperkenalkan sebagai notasi pemodelan di bagian 10.1.3.
Desain aliran data biasanya dilihat sebagai proses dua langkah. Pertama,
desain logis diturunkan dalam bentuk satu set diagram aliran data. Langkah ini
disebut sebagai Analisis Terstruktur (SA). Selanjutnya, desain logis diubah menjadi
struktur program yang direpresentasikan sebagai sekumpulan bagan struktur.
Langkah terakhir disebut Desain Terstruktur (SD). Kombinasi ini disebut sebagai
SA/SD.
Analisis Terstruktur dapat dilihat sebagai metode analisis kebutuhan yang tepat
sejauh ini membahas pemodelan beberapa Semesta Wacana. Perlu dicatat bahwa,
karena diagram aliran data disempurnakan, analis juga melakukan dekomposisi
fungsional implisit (top-down) dari sistem. Pada saat yang sama, diagram
penyempurnaan menghasilkan penyempurnaan data yang sesuai. Proses analisis demikian memiliki
aspek desain juga.
Structured Design, menjadi strategi untuk memetakan arus informasi yang terkandung di dalamnya
diagram aliran data ke dalam struktur program, merupakan komponen asli dari (detail)
fase desain.
Hasil utama dari Analisis Terstruktur adalah rangkaian diagram aliran data. Empat jenis
entitas data dibedakan dalam diagram ini:
Entitas eksternal merupakan sumber atau tujuan transaksi. Entitas ini berada di
luar domain yang dipertimbangkan dalam diagram aliran data. Entitas eksternal
ditunjukkan sebagai kotak.
Proses mengubah data. Proses dilambangkan dengan lingkaran.
Arus data antara proses, entitas eksternal, dan penyimpanan data. Aliran data adalah
ditunjukkan oleh anak panah. Aliran data adalah jalur yang dilalui oleh struktur data.
Penyimpanan data terletak di antara dua proses. Hal ini ditunjukkan dengan nama
penyimpan data di antara dua garis sejajar. Penyimpanan data adalah tempat di
mana struktur data disimpan hingga dibutuhkan.
Kami akan mengilustrasikan berbagai langkah proses SA/SD dengan menganalisis dan merancang a
sistem otomasi perpustakaan sederhana. Sistem ini memungkinkan klien perpustakaan untuk meminjam
dan
mengembalikan buku. Ini juga melaporkan kepada manajemen perpustakaan tentang bagaimana
perpustakaan digunakan oleh
kliennya (misalnya, jumlah rata-rata buku yang dipinjamkan dan jumlah pengarang yang banyak
tuntutan).
Pada level tertinggi kita menggambar a diagram konteks. Diagram konteks adalah aliran data
diagram dengan satu proses, yang menunjukkan 'sistem'. Tujuan utamanya adalah untuk
menggambarkan
interaksi sistem dengan lingkungan (kumpulan entitas eksternal).
Untuk sistem perpustakaan sederhana kami ini dilakukan pada gambar 12.8. Diagram ini belum ada
dilengkapi dengan deskripsi struktur input dan output ke
proses sentral.
Gambar 12.8 Diagram konteks untuk otomasi perpustakaan
Selanjutnya, diagram tingkat atas ini diuraikan lebih lanjut. Sebagai contoh kita, ini
bisa mengarah ke diagram aliran data pada gambar 12.9. Dalam diagram ini, kami
telah memperluas
Gambar 12.9 Diagram aliran data untuk otomasi

perpustakaan
node proses pusat dari diagram konteks. Permintaan klien pertama kali dianalisis
dalam proses berlabel 'pemrosesan awal'. Akibatnya, salah satu dari 'hak pinjam'
atau 'hak pengembalian' diaktifkan. Kedua proses ini memperbarui penyimpanan
data berlabel 'administrasi katalog'. Permintaan klien dicatat dalam 'file log'
penyimpanan data. Penyimpanan data ini digunakan untuk menghasilkan laporan
manajemen.
Untuk aplikasi yang lebih rumit, berbagai diagram dapat digambar, satu untuk
setiap subsistem diidentifikasi. Subsistem ini selanjutnya diuraikan menjadi diagram
pada tingkat yang lebih rendah. Kami dengan demikian mendapatkan hierarki
diagram. Sebagai contoh, kemungkinan penyempurnaan node 'pemrosesan awal'
diberikan pada gambar 12.10. Dalam diagram tingkat rendah juga, entitas eksternal
biasanya dihilangkan.
Dekomposisi top-down berhenti ketika proses menjadi cukup lurus ke depan dan
tidak memerlukan perluasan lebih lanjut. Proses primitif ini adalah
Gambar 12.10 Diagram aliran data untuk 'pemrosesan awal'
dijelaskan di minispecs. Minispec berfungsi untuk mengkomunikasikan algoritma

proses kepada pihak terkait. Itu mungkin menggunakan notasi seperti bahasa alami
terstruktur, pseudocode, atau tabel keputusan. Tata letak layar contoh dapat
ditambahkan untuk mengilustrasikan bagaimana input dan output akan terlihat.
Contoh minispec untuk proses berlabel 'permintaan proses' diberikan pada gambar
12.11.
Identifikasi: Proses permintaan

Keterangan:
1. Masukkan jenis permintaan
1.1 Jika tidak valid, keluarkan peringatan dan ulangi langkah 1
1.2 Jika langkah 1 telah diulang sebanyak lima kali, hentikan transaksi
2. Masukkan identifikasi buku
2.1 Jika tidak valid, keluarkan peringatan dan ulangi langkah 2
2.2 Jika langkah 2 telah diulang lima kali, hentikan transaksi
3. Catat identifikasi klien, jenis permintaan, dan
identifikasi buku
4. ...
Gambar 12.11 Contoh minispec untuk 'permintaan proses'
Isi aliran data dalam DFD direkam dalam kamus data. Meskipun nama ini
menunjukkan sesuatu yang besar, itu tidak lebih dari deskripsi yang tepat dari
struktur data. Ini sering dilakukan dalam bentuk ekspresi reguler, seperti
sampai tidak dapat lagi dianggap masukan. Hal yang sama dilakukan, ke arah lain,
untuk keluaran. Gelembung di antara bertindak sebagai transformasi sentral. Jika kita melihat
gelembung dalam DFD sebagai manik-manik, dan data mengalir sebagai utas, kami mendapatkan yang
sesuai
bagan struktur dengan memilih manik-manik yang sesuai dengan transformasi pusat
dan mengocok DFD.5 Proses dalam diagram aliran data menjadi modul
dari bagan struktur yang sesuai dan aliran data menjadi panggilan modul. Catatan
bahwa panah dalam bagan struktur menunjukkan panggilan modul, sedangkan panah dalam data
diagram alir menunjukkan aliran data. Panah ini sering menunjuk ke arah yang berlawanan;
aliran data dari A ke B sering direalisasikan melalui pemanggilan B ke A. Kadang-kadang
sulit untuk memilih satu transformasi sentral. Dalam hal ini, elemen root dummy
ditambahkan dan skema Input--Proses--Output yang dihasilkan adalah dari bentuk yang digambarkan
gambar 12.13.
Karena orientasi transformasi bagan struktur, hubungan
antara modul dalam grafik memiliki karakter produsen-konsumen. Satu modul
menghasilkan aliran data yang kemudian dikonsumsi oleh modul lain. Kontrol
aliran adalah salah satu dimana modul memanggil modul bawahan untuk mewujudkan yang dibutuhkan
transformasi. Ada aliran informasi yang berpotensi kompleks antara
modul, sesuai dengan aliran data yang dilewatkan antara produsen dan
konsumen. Kontribusi utama Desain Terstruktur ditemukan dalam pedoman
yang bertujuan untuk mengurangi kompleksitas interaksi antar modul. Ini
pedoman menyangkut kriteria kohesi dan kopling yang dibahas di bagian 12.1.
12.2.3 Desain berdasarkan Struktur Data

Teknik paling terkenal untuk desain berdasarkan struktur data berasal dari Michael
Jackson. Teknik tersebut dikenal dengan Jackson Structured Programming (JSP). Penting
JSP telah dibawa ke Jackson System Development (JSD). JSP adalah sebuah teknik
untuk pemrograman-dalam-kecil dan JSD adalah teknik untuk pemrograman-dalam-besar.
Kami akan membahas kedua teknik secara bergantian.
Ide dasar dari JSP adalah bahwa program yang baik mencerminkan struktur keduanya
input dan output dalam semua aspeknya. Mengingat model yang benar dari struktur data ini, kami
dapat langsung menurunkan program yang sesuai dari model. Itu sering
mendalilkan bahwa struktur data jauh lebih tidak stabil daripada transformasi
diterapkan pada data. Akibatnya, desain yang mengambil data sebagai permulaannya
poin juga harus 'lebih baik'. Argumen yang sama ini juga digunakan dalam konteks
analisis dan desain berorientasi objek.
JSP membedakan komponen elementer dan majemuk. komposisi dasar
nents tidak terurai lebih lanjut. Ada tiga jenis komponen senyawa:
urutan, iterasi dan seleksi. Komponen majemuk diwakili oleh dia-
gram (disebut juga Diagram Jacksonataustructurediagrams) atau semacam fpseudocode
(ditelepon struktur teks atau logika skematik). Bentuk dasar dari keduanya diberikan dalam
5Kami melakukan hal yang sama saat mengubah pohon bebas menjadi pohon berorientasi. Pohon bebas tidak memiliki akar.
Dengan memilih
satu simpul pohon sebagai akar, hubungan orangtua-anak terjadi.
gambar 12.14. Dalam teks struktur, 'seq' menunjukkan urutan, 'itr' menunjukkan
iterasi, 'sel' menunjukkan pemilihan, dan 'alt' menunjukkan alternatif.
Gambar 12.14 Komponen majemuk dalam notasi Jackson
Sebagian besar bahasa pemrograman modern memiliki struktur (loop,

pernyataan if dan komposisi berurutan) untuk masing-masing notasi diagram ini
atau, dalam hal ini, kodesemu yang sesuai untuk struktur data. Inti dari teknik
Jackson adalah bahwa diagram struktur input dan output dapat digabungkan,
sehingga menghasilkan struktur global dari program tersebut.
Untuk mengilustrasikan garis pemikiran ini, pertimbangkan fragmen berikut dari
sistem perpustakaan. Sistem melacak buku mana dari penulis mana yang dipinjam
(dan dikembalikan). Dari log ini, kami ingin membuat laporan yang mencantumkan
seberapa sering setiap judul dipinjam. Menggunakan notasi Jackson, masukan
untuk fungsi ini dapat ditentukan pada gambar 12.15.6 Struktur yang mungkin untuk
keluaran diberikan pada Gambar 12.16.
Diagram program untuk mengubah log menjadi laporan sekarang diperoleh
dengan menggabungkan dua diagram; lihat gambar 12.17. Struktur program yang
dihasilkan dapat diturunkan secara langsung dari diagram ini, dan dalam bentuk
yang diberikan pada Gambar 12.18.
Penggabungan diagram ini tidak berfungsi untuk tingkat yang lebih rendah dari
masalah kita: 'mutasi proses' dan node bawahannya. Penyebabnya disebut a
structureclash: struktur data input dan output tidak benar-benar cocok. Alasannya
adalah input terdiri dari urutan mutasi. Dalam output, semua mutasi untuk satu
6Demi kesederhanaan, kami berasumsi bahwa input sudah diurutkan berdasarkan penulis.
Gambar 12.15 Log buku yang dipinjam dan dikembalikan, dalam notasi JSP
buku yang diberikan diambil bersama-sama. Jadi, mutasi harus disortir terlebih dahulu. Kita harus
merestrukturisasi sistem, misalnya seperti yang digambarkan pada gambar 12.19.
Kerugian yang jelas dari struktur yang diperoleh adalah bahwa sekarang ada
berkas perantara. Pemeriksaan lebih dekat menunjukkan bahwa kita tidak benar-benar membutuhkan
file ini. Ini
langsung jelas jika kita gambarkan strukturnya seperti pada gambar 12.20.
Di sini, kita mungkin membalikkan komponen A1 dan beri kode sedemikian rupa sehingga berfungsi
sebagai pengganti
dari komponen B2. Alternatifnya (dan dalam hal ini lebih mungkin), kami dapat membalikkan B1
dan gantikan hasilnya dengan komponen A2. Dalam kedua kasus, tipe first-in-first-out
file perantara antara dua komponen dihapus dengan membuat salah satunya
komponen menjadi bawahan dari yang lain.
Contoh ini menunjukkan masalah mendasar yang terlibat dalam penggunaan JSP:
1. Pemodelan input dan output menggunakan diagram struktur,
2. Menggabungkan diagram untuk membuat struktur program
3. Menyelesaikan kemungkinan benturan struktur, dan terakhir

Gambar 12.16 Laporan buku yang dipinjam, dalam notasi

JSP
4. Mengoptimalkan hasil melalui inversi program.

Jika kita memilih notasi linier untuk diagram struktur, hasilnya termasuk dalam kelas
'ekspresi reguler'. Jadi, kekuatan ekspresif dari diagram-diagram ini adalah sebuah
otomat terbatas. Beberapa struktur berbenturan muncul jika masalahnya tidak dapat
diselesaikan oleh robot yang terbatas.
Baik dalam dekomposisi fungsional maupun dalam metode desain aliran data,
struktur masalah dipetakan ke dalam struktur fungsional. Struktur fungsional ini
selanjutnya dipetakan ke dalam struktur program. Sebaliknya, JSP memetakan
struktur masalah ke dalam struktur data dan struktur program diturunkan dari
struktur data ini. JSP tidak terlalu peduli dengan pertanyaan tentang bagaimana
pemetaan dari struktur masalah ke struktur data dapat diperoleh.
Jackson System Development (JSD) mencoba mengisi celah ini. JSD
membedakan tiga tahap dalam proses pengembangan perangkat lunak:
�
Gambar 12.17 Hasil penggabungan diagram input dan output
membuat tajuk
sampai EOF lingkaran
penulis proses:
sampai akhir dari pengarang lingkaran
proses mutasi:
... akhir lari
akhir lari.
Gambar 12.18 Struktur tingkat atas dari program untuk menghasilkan laporan
Langkah pertama dalam JSD adalah memodelkan bagian dari realitas yang kita
minati, Universe of Discourse (UoD). JSD memodelkan UoD sebagai sekumpulan
entitas, objek di dunia nyata yang berpartisipasi dalam urutan tindakan yang diatur
waktu. Untuk setiap entitas proses
Gambar 12.19 Restrukturisasi sistem
Gambar 12.20 Tampilan sistem yang berbeda
dibuat yang memodelkan siklus hidup entitas itu. Tindakan adalah peristiwa yang
terjadi pada suatu entitas. Misalnya, di perpustakaan siklus hidup suatu entitas Buku
seperti yang digambarkan pada gambar 12.21. Siklus hidup sebuah buku dimulai
saat diperoleh. Setelah itu dapat dipinjam dan dikembalikan beberapa kali. Siklus
hidup berakhir saat buku diarsipkan atau dibuang. Siklus hidup digambarkan
menggunakandiagram struktur proses (PSD). PSD adalah diagram hierarkis yang
menyerupai diagram struktur JSP, dengan primitifnya untuk menunjukkan rangkaian
(pengurutan dalam waktu), pengulangan, dan pemilihan. PSD memiliki persamaan
pseudocode yang disebut strukturteks yang terlihat seperti logika skema JSP.
Diagram struktur proses adalah diagram keadaan terbatas. Dalam diagram
keadaan terbatas tradisional, gelembung (node) mewakili kemungkinan keadaan
entitas yang dimodelkan sementara panah menunjukkan kemungkinan transisi antar
keadaan. Kebalikannya berlaku untuk PSD. Dalam PSD, simpul menunjukkan
transisi keadaan dan panah menunjukkan keadaan.
Mengikuti alur pemikiran ini, sebuah entitas Anggota dapat digambarkan seperti
pada gambar 12.22: anggota memasuki sistem perpustakaan, setelah itu mereka
dapat meminjam dan mengembalikan buku sampai berhenti menjadi anggota.
Tahap pemodelan berkaitan dengan mengidentifikasi entitas dan peristiwa
(tindakan) yang terjadi pada mereka. Tindakan ini secara kolektif merupakan siklus
hidup suatu entitas.
Gambar 12.21 Diagram struktur proses untuk entitas Buku
Seperti metode desain lainnya, tidak ada resep sederhana untuk menentukan himpunan
entitas dan tindakan. Pendekatan yang diambil umumnya memiliki sikap linguistik. Dari catatan,
dokumentasi, wawancara dan sejenisnya, kami dapat menyusun daftar tindakan awal
dan entitas. Salah satu heuristik adalah mencari objek dunia nyata yang menjadi tujuan sistem
berinteraksi. Karena perpustakaan adalah tentang buku, sebuah entitas Buku segera menunjukkan
dirinya.
Dari pernyataan seperti 'anggota meminjam buku' kita dapat menyimpulkan bahwa suatu peristiwa
Meminjam
terjadi dalam siklus hidup buku dan anggota. Setelah daftar pendahuluan seperti itu
dibuat, refleksi lebih lanjut harus mengarah pada siklus hidup yang dibatasi dengan tepat
entitas yang diidentifikasi.
Entitas terdiri dari tindakan. Tindakan ini bersifat atomik, artinya tidak mungkin
diuraikan lebih lanjut menjadi sub-subaksi. Tindakan menanggapi peristiwa di dunia nyata. Itu
tindakan Mendapatkan yang merupakan bagian dari siklus hidup entitas Buku dipicu ketika a
peristiwa dunia nyata, akuisisi buku yang sebenarnya, terjadi. Dalam struktur proses
diagram, tindakan muncul sebagai simpul daun.
Acara dikomunikasikan ke sistem melalui pesan data, disebut atribut.
Dalam arti prosedural atribut ini merupakan parameter dari tindakan. Untuk
tindakan Mendapatkan kita mungkin memiliki atribut seperti ISBN, tanggal akuisisi, judul Dan
penulis.
Entitas juga memiliki atribut: variabel lokal yang menyimpan informasi dari
masa lalu dan secara kolektif menentukan keadaannya. Entitas Buku misalnya dapat dipertahankan
beberapa atau semua informasi yang diberikan pada saat akuisisi (ISBN, judul, dll).
Gambar 12.22 Diagram struktur proses untuk entitas Anggota
Entitas juga memiliki dua atribut khusus. Pertama, atribut pengenal secara unik
mengidentifikasi entitas. Kedua, setiap entitas memiliki atribut yang menunjukkan
statusnya. Atribut ini dapat dilihat sebagai penunjuk ke beberapa simpul daun dari
diagram struktur proses. Setiap entitas dapat dilihat sebagai proses yang terpisah
dan berjalan lama. Dalam contoh perpustakaan, setiap buku dan setiap anggota
memiliki siklus hidupnya sendiri. Proses meskipun tidak sepenuhnya independen.
Selama tahap jaringan, sistem dimodelkan sebagai jaringan proses yang saling
berhubungan. Jaringan ini digambarkan dalam a diagram spesifikasi sistem (SSD).
JSD memiliki dua mekanisme dasar untuk komunikasi antarproses:
�
12.3. METODE ANALISIS DAN DESAIN 361
BERORIENTASI OBJEK
berlian pada gambar 12.23. Dalam sebuah implementasi, komunikasi vektor negara adalah
biasanya ditangani melalui akses database.
Jika sistem kami adalah untuk mencatat informasi tentang buku yang dipinjam, kami dapat membuat
model
ini melalui aliran data dari suatu entitas Buku kepada suatu entitas Catatan. Aliran data
ditangani secara FIFO; itu berperilaku seperti filter UNIX. Notasi untuk
jenis komunikasi datastream diberikan pada gambar 12.24.
Gambar 12.23 State vector communication (SV) antara Anggota Dan Buku
Gambar 12.24 Datastream communication (DS) antara Buku Dan Catatan
Tahap akhir dari JSD adalah tahap implementasi. Pada tahap implementasi model
konkuren yang merupakan hasil dari tahap jaringan diubah menjadi sistem yang
dapat dieksekusi. Salah satu konsep kunci untuk tahap ini adalah inversi program:
komunikasi antar proses diganti dengan pemanggilan prosedur, sehingga satu
proses menjadi bawahan dari proses lainnya. Ini sangat mirip dengan gagasan
inversi program seperti yang ada di JSP.
12.3 Metode Analisis dan Desain

Berorientasi Objek
Konsep kunci yang berperan a
peran dalam pendekatan berorientasi objek untuk analisis dan desain telah disebutkan
sudah di bab 10: objek, atribut dan layanannya, dan hubungannya
antar objek. Ini mengikuti secara alami dari atas bahwa berorientasi objek
pendekatan analisis dan desain sistem melibatkan tiga langkah utama:
1. mengidentifikasi objek;
2. menentukan atribut dan layanan mereka;
3. menentukan hubungan antar objek.
Jelas, langkah-langkah ini sangat saling terkait dan beberapa bentuk iterasi akan
diperlukan sebelum desain akhir diperoleh. Gambaran yang dihasilkan dari sistem
sebagai kumpulan objek dan keterkaitannya menggambarkan statis struktur
(dekomposisi) dari sistem. Model statis ini secara grafis digambarkan dalam
beberapa varian diagram kelas seperti yang dijelaskan pada bagian 10.3.1.
Instance objek dibuat, diperbarui nol kali atau lebih, dan akhirnya dihancurkan.
Diagram status terbatas yang menggambarkan kemungkinan status objek dan
transisi di antara status tersebut merupakan bantuan yang baik dalam memodelkan
siklus hidup ini. Metode berorientasi objek umumnya menggunakan beberapa varian
diagram mesin keadaan UML untuk menunjukkan ini dinamis model perilaku
komponen sistem; lihat bagian 10.3.2. Komponen sistem berkomunikasi
dengan mengirimkan pesan. Pesan-pesan ini adalah bagian dari tugas yang harus
dilakukan sistem. Kita dapat mengetahui pesan mana yang dibutuhkan, dan dalam
urutan apa pesan tersebut harus ditukar, dengan mempertimbangkan skenario
penggunaan yang khas. Analisis skenario adalah teknik elisitasi kebutuhan. Di
kalangan berorientasi objek, teknik ini dikenal sebagai analisis kasus penggunaan.
Model yang dihasilkan dari komunikasi antar komponen sistem digambarkan dalam
urutan atau diagram komunikasi; lihat bagian 10.3.3 dan 10.3.4. Pandangan ini juga
merupakan bagian dari model dinamis.
Pedoman untuk menemukan objek dan atribut serta layanannya sebagian besar
bersifat linguistik, seperti yang disebutkan dalam pembahasan kita tentang JSD di
bagian 12.2.3. Memang, tahap pemodelan JSD juga berorientasi objek. Pedoman
yang disajikan di bawah ini secara longgar didasarkan pada (Coad dan Yourdon,
1991) dan (Rumbaughet al., 1991). Rasa umumnya mirip dengan yang ditemukan
dalam pendekatan berorientasi objek lainnya. Model proses global dari beberapa
metode berorientasi objek yang terkenal dibahas di bagian 12.3.1--12.3.2.
Pernyataan masalah untuk sistem otomasi perpustakaan yang diberikan pada
gambar 12.25 akan berfungsi sebagai contoh untuk mengilustrasikan
langkah-langkah utama dalam analisis dan desain berorientasi objek. Kami akan
mengelaborasi bagian dari masalah ini dalam teks, dan membiarkan sejumlah
masalah terperinci sebagai latihan.
Prinsip panduan utama untuk mengidentifikasi objek adalah mencari konsep
penting dari domain aplikasi. Objek yang dapat ditemukan di perpustakaan termasuk
Buku,Lemari File, Pelanggan, dll. Di lingkungan kantor, kita mungkin pernah
mengalaminya Folder,Surat, Pegawai, dll. Entitas khusus domain ini adalah kandidat
utama kami untuk objek. Mereka mungkin objek dunia nyata, seperti buku; peran
dimainkan, seperti pelanggan perpustakaan; unit organisasi, seperti departemen;
lokasi, seperti kantor; atau perangkat, seperti printer. Objek potensial juga dapat
ditemukan dengan mempertimbangkan struktur klasifikasi atau rakitan (seluruh
bagian) yang ada. Dari wawancara, dokumentasi, dan sebagainya, dapat dilakukan
inventarisasi objek terlebih dahulu.
BERORIENTASI OBJEK
Pernyataan masalah
Merancang perangkat lunak untuk mendukung pengoperasian perpustakaan umum. Sistem tersebut
memiliki
jumlah stasiun untuk transaksi pelanggan. Stasiun-stasiun ini dioperasikan oleh perpustakaan
karyawan. Ketika sebuah buku dipinjam, kartu identitas klien dibaca.
Selanjutnya, pembaca kode batang stasiun membaca kode buku. Ketika sebuah buku dikembalikan,
kartu identitas tidak diperlukan dan hanya kode buku yang perlu dibaca.
Klien dapat mencari katalog perpustakaan dari salah satu dari sejumlah PC yang terletak di
perpustakaan. Saat melakukannya, pertama-tama pengguna diminta untuk menunjukkan bagaimana
pencarian itu akan dilakukan
dilakukan: oleh penulis, judul, atau kata kunci.
...
Fungsionalitas khusus dari sistem menyangkut perubahan isi katalog dan
penanganan denda. Fungsionalitas ini terbatas pada personel perpustakaan. Kata sandi
diperlukan untuk fungsi-fungsi ini.
...
Gambar 12.25 Pernyataan masalah untuk otomasi perpustakaan
Dari paragraf pertama uraian masalah pada gambar 12.25 berikut ini
daftar objek kandidat dapat disimpulkan, hanya dengan mendaftar semua kata benda:
perangkat lunak
perpustakaan
sistem
stasiun
pelanggan
transaksi
buku
pegawai perpustakaan
kartu identitas
klien
pembaca barcode
kode buku
Namun, beberapa objek dalam daftar kandidat ini harus dihilangkan. Perangkat lunak, mis.,
adalah konstruk implementasi yang seharusnya tidak disertakan dalam model saat ini
titik waktu. Nasib serupa harus menimpa istilah seperti algoritma atau daftar tertaut. Pada
tahap desain rinci, mungkin ada alasan untuk memperkenalkan (atau memperkenalkan kembali) mereka
objek berorientasi solusi.
Istilah yang tidak jelas harus diganti dengan istilah yang lebih konkret atau dihilangkan. Sistem
adalah
istilah yang tidak jelas dalam daftar kandidat kami. Stasiun dan PC akan terhubung ke yang sama
komputer host, jadi sebaiknya kita gunakan gagasan itu komputer alih-alih sistem.
Pelanggan Dan klien adalah istilah sinonim dalam pernyataan masalah. Oleh
karena itu, hanya satu dari mereka yang dipertahankan. Kita harus berhati-hati
dalam membuat model klien Danpegawai perpustakaan. Satu orang fisik dapat
mengambil kedua peran. Apakah berguna untuk memodelkan ini sebagai objek
yang berbeda atau sebagai peran yang berbeda dari satu objek sulit untuk
diputuskan pada saat ini. Kami akan memperlakukannya sebagai objek terpisah
untuk saat ini, namun perlu diingat bahwa ini dapat berubah saat model
disempurnakan.
Syarat transaksi mengacu pada operasi yang diterapkan pada objek, bukan
objek itu sendiri. Ini melibatkan urutan tindakan seperti menyerahkan kartu identitas
dan salinan buku kepada karyawan, memasukkan kartu identitas di stasiun,
membaca kode batang buku, dan sebagainya. Hanya jika transaksi itu sendiri
memiliki fitur yang penting bagi sistem, mereka harus dimodelkan sebagai objek.
Misalnya, jika sistem harus menghasilkan informasi profil tentang preferensi klien,
akan berguna untuk memiliki objek transaksi.
Syarat buku agak rumit dalam konteks ini. Sebuah buku dalam sistem
perpustakaan dapat menunjukkan salinan fisik dan kunci abstrak yang menunjukkan
hal tertentu F
BERORIENTASI OBJEK
Dari pernyataan masalah:
karyawan mengoperasikan stasiun

stasiun memiliki pembaca kode batang
pembaca kode batang membaca salinan buku
pembaca kode batang membaca kartu identitas
Pengetahuan diam-diam:
perpustakaan memiliki komputer

perpustakaan memiliki stasiun
komputer berkomunikasi dengan stasiun
perpustakaan mempekerjakan karyawan
klien adalah anggota perpustakaan
klien memiliki kartu identitas
Gambar 12.26 Hubungan yang disimpulkan dari pernyataan masalah
Layanan ini menyangkut keadaan objek: mereka membaca dan menulis objek
atribut. Layanan yang memberikan informasi tentang keadaan suatu objek dapat atau
mungkin tidak melibatkan beberapa jenis perhitungan. Perhatikan bahwa selalu mungkin untuk
mengoptimalkan implementasi aktual dengan menjaga informasi yang berlebihan di negara sebagai
itu dipertahankan oleh objek. Misalnya, kami dapat memutuskan untuk memasukkan nomor
buku pinjaman di negara bagian sebagaimana diterapkan, daripada menghitungnya kapan
diperlukan. Ini tidak perlu menjadi perhatian kita pada tahap ini. Apakah layanan sebenarnya
diimplementasikan dengan cara komputasi atau dengan prosedur pencarian sederhana tidak terlihat
objek yang meminta informasi.
Wawasan lebih lanjut tentang layanan mana yang diperlukan dapat diperoleh dengan menyelidiki
skenario penggunaan. Kami dapat menyiapkan dialog tipikal antar komponen sistem
baik dalam situasi normal maupun luar biasa. Misalnya, kita dapat mempertimbangkan situasinya
di mana klien berhasil meminjam buku, yang di dalamnya identitas klien
kartu tidak berlaku lagi, di mana dia masih harus membayar denda terutang, dan sebagainya
pada. Diagram urutan untuk situasi normal peminjaman buku ditunjukkan pada
gambar 12.28. Sejumlah peristiwa terjadi saat interaksi ini berlangsung. Ini
peristiwa akan ditangani oleh operasi objek yang terlibat.
Layanan hanyalah salah satu cara di mana objek mungkin terkait. Hubungan
yang memberi sistem rasa yang benar-benar berorientasi objek adalah yang dihasilkan dari
klasifikasi keseluruhan-bagian dan generalisasi-spesialisasi.
Bagian dari klasifikasi objek dapat dihasilkan dari dunia nyata yang sudah ada sebelumnya
klasifikasi yang harus ditangani oleh sistem. Pengelompokan lebih lanjut objek menjadi an
hierarki objek melibatkan pencarian hubungan antar objek. Untuk mulai dengan, kami
Gambar 12.27 (Bagian dari) model objek awal untuk sistem

perpustakaan
dapat mempertimbangkan objek sebagai generalisasi objek lain yang mungkin.

Misalnya objek Buku dapat dilihat sebagai generalisasi objek Novel, Puisi DanBuku
pedoman. Apakah spesialisasi ini bermakna tergantung pada masalah yang
dihadapi. Jika sistem tidak perlu membedakan antara novel dan puisi, kita tidak
boleh mendefinisikan objek terpisah untuknya. Perbedaan antara novel dan puisi di
satu sisi dan buku referensi di sisi lain masuk akal, meskipun novel dan puisi dapat
dipinjam, tetapi buku referensi tidak bisa.
Dengan cara yang sama, kita dapat mempertimbangkan kesamaan antara
objek, sehingga melihat spesialisasi objek yang lebih umum. Jika sistem
perpustakaan kami memanggil objekBuku Dan Jurnal yang memiliki sejumlah atribut
yang sama, kita dapat memperkenalkan objek baru Publikasi sebagai generalisasi
dari objek-objek tersebut. Atribut umum diangkat ke objek Publikasi; Buku Dan
Jurnal kemudian mewarisi atribut ini. Perhatikan bahwa generalisasi harus tetap
mencerminkan entitas dunia nyata yang berarti. Tidak ada gunanya
memperkenalkan generalisasi Buku Dan Lemari arsip hanya karena mereka
memiliki atribut yang sama Lokasi.
Objek Publikasi diperkenalkan di atas adalah objek abstrak. Ini adalah objek
untuk
BERORIENTASI OBJEK
objek. Juga, instance dari suatu objek harus memiliki atribut yang sama. Jika
beberapa atribut hanya bermakna untuk subset dari semua instance, maka kita
benar-benar memiliki struktur klasifikasi. Jika beberapa buku dapat dipinjam, tetapi
yang lain tidak bisa, ini merupakan indikasi struktur klasifikasi tempat objek tersebut
Buku memiliki spesialisasi seperti Novel Dan Buku pedoman.
Perhatikan juga bahwa, dari waktu ke waktu, kumpulan atribut dan layanan yang
disediakan oleh objek cenderung berkembang, sedangkan hierarki objek relatif
stabil. Jika perpustakaan kami memutuskan untuk menawarkan layanan tambahan
kepada pelanggannya, katakanlah meminjam catatan, kami dapat dengan mudah
mengadaptasi kumpulan atribut dan memperluas kumpulan layanan untuk objek
tersebut.Pelanggan.
Desain berorientasi objek dapat diklasifikasikan sebagai a tengah-keluar
metode desain. Himpunan objek yang diidentifikasi selama tahap pemodelan
pertama merupakan tingkat menengah dari sistem. Untuk mengimplementasikan
entitas khusus domain ini, objek tingkat rendah digunakan. Objek tingkat rendah ini
seringkali dapat diambil dari perpustakaan kelas. Untuk berbagai bahasa
pemrograman berorientasi objek, perpustakaan kelas yang cukup luas sudah ada.
Tingkat desain yang lebih tinggi merupakan interaksi yang bergantung pada aplikasi
dari entitas spesifik domain.
Dalam subbagian berikut, kita membahas tiga metode desain yang
menggambarkan evolusi analisis dan desain berorientasi objek:
�
BERORIENTASI OBJEK
Gambar 12.29 Model proses Booch (Sumber: G.Booch, Analisis Berorientasi Objek
dan Desain, Benjamin Cummings, 1994. Direproduksi dengan izin.)
Langkah kedua berkaitan dengan menentukan perilaku dan atribut

masing-masing abstraksi, dan distribusi tanggung jawab atas komponen
sistem. Atribut dan perilaku yang diinginkan diidentifikasi dengan menganalisis penggunaan tipikal
skenario. Saat proses ini berlangsung, tanggung jawab dapat dialokasikan kembali untuk mendapatkan
lebih banyak
desain seimbang, atau dapat menggunakan kembali (mengais) desain yang sudah ada. Hasil dari
langkah ini adalah serangkaian tanggung jawab dan operasi yang cukup lengkap untuk masing-masing
abstraksi. Hasilnya didokumentasikan dalam kamus data dan, pada tahap selanjutnya,
dalam spesifikasi antarmuka untuk setiap abstraksi. Semantik skenario penggunaan adalah
ditangkap dalam urutan dan diagram komunikasi (disebut diagram interaksi Dan
diagram objek, masing-masing, dalam (Booch, 1994)).
Langkah ketiga berkaitan dengan menemukan hubungan antara objek. Selama
analisis, penekanannya adalah pada menemukan hubungan antara abstraksi. Selama desain,
keputusan taktis tentang pewarisan, pembuatan contoh, dan sejenisnya dibuat. Hasil
ditunjukkan dalam diagram kelas, diagram komunikasi, dan apa yang disebut diagram modul
yang menunjukkan struktur modular dari suatu sistem.
Terakhir, abstraksi disempurnakan hingga tingkat yang mendetail. Sebuah keputusan dibuat tentang
representasi dari setiap abstraksi, algoritma dipilih, dan berorientasi pada solusi
kelas ditambahkan jika diperlukan.
Karakteristik yang paling menonjol dari metode Booch adalah:
– Satu set kaya notasi: menggunakan enam jenis diagram, masing-masing
dengan cukup rumit kosakata; akibatnya, banyak aspek dari suatu sistem
dapat dimodelkan.
– Model proses yang buruk: sulit untuk memutuskan kapan harus mengulang,
dan apa yang harus dilakukan dalam iterasi tertentu.
12.3.2 Fusi
Metode Fusion untuk analisis dan desain berorientasi objek memiliki dua fase
utama: analisis dan desain. Model proses globalnya ditunjukkan pada gambar
12.30.
Tahap analisis ditujukan untuk menentukan objek sistem dan interaksinya.
Struktur statis ditunjukkan dalam diagram kelas (disebut an model objekdi Fusion),
dan didokumentasikan dalam kamus data. Dinamika ditampilkan dalam model
antarmuka. Model antarmuka terdiri dari model siklus hidup untuk setiap objek,
dilambangkan dengan ekspresi reguler (yaitu representasi datar dari diagram mesin
negara) dan spesifikasi semantik dari setiap operasi dalam gaya sebelum dan
sesudah kondisi. Proses analisis diasumsikan sebagai proses iteratif. Iterasi ini
berhenti ketika model sudah lengkap dan konsisten.
Fase desain Fusion menghasilkan empat model, yang pada dasarnya diturunkan
dalam urutan yang ditunjukkan pada Gambar 12.30. Grafik interaksi objek
menyerupai grafik komunikasi. Mereka menjelaskan bagaimana objek berinteraksi
saat runtime: objek apa yang terlibat dalam perhitungan dan bagaimana mereka
digabungkan untuk mewujudkan spesifikasi yang diberikan. Visibilitygraphs
menjelaskan bagaimana komunikasi antar objek diwujudkan. Untuk setiap objek,
ditentukan objek lain mana yang harus dirujuk dan bagaimana caranya. Berbagai
jenis referensi dibedakan, dengan mempertimbangkan aspek-aspek seperti masa
pakai referensi dan apakah referensi dapat dibagikan. Selanjutnya, model objek,
grafik interaksi, dan grafik visibilitas digunakan untuk mendapatkan deskripsi dari
setiap kelas. Operasi dan kumpulan atribut awal untuk setiap objek ditetapkan pada
tahap ini. Akhirnya, relasi pewarisan diputuskan, dan digambarkan dalam grafik
pewarisan, yang merupakan diagram kelas. Deskripsi kelas kemudian diperbarui
untuk mencerminkan struktur pewarisan ini.
Karakteristik Fusion yang paling menonjol adalah:
�
BERORIENTASI OBJEK
Gambar 12.30 Model proses Fusion
12.3.3 RUP Ditinjau Kembali

RUP, Rational Unified Process, adalah model proses penuh; lihat juga bagian 3.3.
RUP memiliki sejumlah alur kerja, seperti alur kerja persyaratan, alur kerja analisis
dan desain, dan alur kerja pengujian, dan empat fase: permulaan, elaborasi,
konstruksi
dan transisi. Alur kerja menggambarkan aktivitas yang akan dilakukan, sedangkan
fase menunjukkan organisasi sepanjang sumbu waktu. Sebagian besar alur kerja
meluas ke sebagian besar fase.
Di sini, kami membahas alur kerja analisis dan desain, di mana persyaratan
diubah menjadi desain. RUP merupakan proses iteratif, sehingga transformasi ini
dilakukan dalam beberapa iterasi juga. Iterasi pertama terjadi pada fase elaborasi
RUP. Pada fase itu, arsitektur sistem ditentukan. Cara RUP melakukan desain
arsitektur cukup sesuai dengan model alur kerja global yang dibahas pada bagian
11.2. Dalam iterasi berikutnya, mengenai desain tingkat rendah, aktivitas utama
disebut Menganalisis perilaku Dan Komponen desain.
Tujuan dari langkah Analisis perilaku adalah untuk mengubah kasus
penggunaan menjadi sekumpulan elemen desain yang bersama-sama berfungsi
sebagai model dari domain masalah. Ini adalah tentangApa sistem ini untuk
menyampaikan. Ini menghasilkan model kotak hitam dari solusi. Tujuan dari langkah
elemen Desain adalah untuk menyempurnakan definisi elemen desain ke dalam
kelas, hubungan, antarmuka, dan sejenisnya. Dalam kegiatan ini, kotak hitam
Apamodel berubah menjadi kotak putih Bagaimana model.
Selama kedua aktivitas, desain yang dihasilkan ditinjau, dan hasilnya
diumpankan kembali ke iterasi berikutnya.
Karakteristik penting dari RUP adalah:
�
12.4. CARA MEMILIH METODE DESAIN 373
berat pada pengetahuan heuristik dari para desainer. Teknik Jackson tampaknya
menderita kurang dari kebutuhan ini. Terutama jika benturan struktur tidak terjadi, JSP menyediakan
kerangka kerja yang terdefinisi dengan baik untuk bagaimana menangani desain. Sifat preskriptif JSP
mungkin menjelaskan sampai batas tertentu keberhasilannya, terutama di bidang administrasi
pengolahan data. JSD menawarkan keunggulan serupa. Tampilannya yang ketat untuk mendeskripsikan
data
struktur sebagai daftar peristiwa dapat menyebabkan masalah, bagaimanapun, jika struktur data
melakukannya
tidak cocok dengan model ini. JSP memiliki tampilan data statis. Lebih penting lagi, itu tidak memberi
tahu
kita Bagaimana untuk mengatur data. Dengan demikian, teknik ini tampaknya paling cocok untuk
masalah
dimana struktur datanya telah diperbaiki sebelumnya. JSD dan berorientasi objek
metode menawarkan dukungan yang lebih baik dalam hal penataan data. Padahal metode ini
memberikan heuristik yang berguna untuk identifikasi objek, mendapatkan set yang seimbang
objek masih sangat tergantung pada keterampilan desainer.
Teknik aliran data memiliki tampilan yang lebih dinamis dari aliran data yang ada
dasar dari sistem yang akan dibuat. Kita mungkin sering melihat gelembung dari aliran data
diagram sebagai pegawai yang melakukan transformasi tertentu pada data yang masuk untuk
menghasilkan
data petugas lainnya. Teknik ini tampaknya cocok untuk keadaan di mana sebuah
sistem manual yang ada harus diganti dengan yang terkomputerisasi. Bahaya nyata,
Namun, apakah sistem yang ada hanya disalin, sedangkan persyaratan tambahan
diabaikan.
Jika kita memperhitungkan bahwa sebagian besar dari biaya perangkat lunak dihabiskan
memelihara perangkat lunak itu, jelas bahwa faktor-faktor seperti fleksibilitas, kelengkapan
dan modularitas harus memainkan peran penting saat memilih teknik desain tertentu.
Gagasan dan pedoman Parnas sangat relevan dalam hal ini. Itu
filosofi berorientasi objek menggabungkan ide-ide ini dan cocok dengan arus
bahasa pemrograman, yang memungkinkan transisi yang lebih mulus antara yang berbeda
fase pengembangan.
Beberapa upaya telah dilakukan untuk mengklasifikasikan metode desain dengan berbagai cara
dimensi, seperti produk yang mereka berikan, jenis representasi yang digunakan, atau
tingkat formalitas mereka. Sebuah kerangka sederhana namun bermanfaat diusulkan dalam (Blum,
1994). Dia
memiliki dua dimensi: dimensi orientasi dan dimensi model.
Dalam dimensi orientasi, dibedakan antara berorientasi pada masalah
teknik dan teknik berorientasi produk. Teknik berorientasi masalah
berkonsentrasi pada menghasilkan pemahaman yang lebih baik dari masalah dan solusinya.
Teknik berorientasi masalah berorientasi pada manusia. Tujuan mereka adalah untuk menggambarkan,
berkomunikasi
bagus, dan mendokumentasikan keputusan. Teknik berorientasi masalah biasanya memiliki satu kaki
dalam domain rekayasa persyaratan. Sebaliknya, teknik berorientasi produk
fokus pada transformasi yang benar dari spesifikasi ke implementasi. Itu
Dimensi kedua berkaitan dengan produk, yaitu model yang merupakan hasil dari desain
proses. Dalam dimensi ini, perbedaan dibuat antara model konseptual dan
model formal. Model konseptual bersifat deskriptif. Mereka menggambarkan realitas eksternal,
semesta wacana. Kesesuaiannya ditetapkan melalui validasi.
Model formal di sisi lain bersifat preskriptif. Mereka menentukan perilaku dari
sistem yang akan dikembangkan. Model formal dapat diverifikasi.
374 DESAIN
PERANGKAT
LUNAK
Berorientasi
masalah Berorientasi
produk
Konseptual SA II
YA
pemodelan SI Desain
Terstruktur
Analisis Terstruktur Desain OO
Analisis OO
AKU AKU AKU I

Resmi V
JSD Dekomposisi fungsional
VDM J
S
P
Gambar 12.31 Klasifikasi teknik desain
Dengan menggunakan kerangka ini, kita dapat mengklasifikasikan sejumlah teknik

yang dibahas dalam buku ini seperti pada gambar 12.31. Empat kuadran matriks ini
memiliki ciri-ciri sebagai berikut:
SAYA) Pahami masalahnya Teknik-teknik ini berkaitan dengan pemahaman

masalah, dan mengungkapkan solusi dalam bentuk yang dapat didiskusikan
dengan spesialis domain (yaitu pengguna).
II) Berubah menjadi implementasi Teknik dalam kategori ini membantu

mengubah a kumpulan konsep terkait UoD ke dalam struktur implementasi.
AKU AKU AKU) Mewakili properti Teknik-teknik ini memfasilitasi penalaran

tentang masalah dan solusinya.
IV) Membuat unit implementasi Kategori ini berisi teknik khusus bertujuan
untuk membuat unit implementasi seperti modul.
Argumen di atas berhubungan dengan karakteristik masalah yang akan dipecahkan.

Ada beberapa faktor lingkungan lain yang dapat memengaruhi pilihan teknik desain
tertentu dan, sebagai konsekuensinya, desain yang dihasilkan (argumen serupa
berlaku untuk arsitektur perangkat lunak; lihat bab 11):
�
12.4. CARA MEMILIH METODE DESAIN 375
menyadari kendala dan keterbatasan metode dan akan mampu
berhasil melewati potensi masalah.
�
Sebagian besar metode berorientasi objek berasumsi bahwa persyaratan telah
ditetapkan sebelum analisis dimulai. Dari empat proses yang dibedakan dalam bab
9, elisitasi, spesifikasi, validasi, dan negosiasi, metode berorientasi objek pada
umumnya hanya mencakup persyaratan. spesifikasi subproses. Meskipun banyak
metode berorientasi objek telah memasukkan analisis kasus penggunaan, tujuannya
terutama adalah untuk memodelkan perilaku fungsional sistem daripada untuk
mendapatkan kebutuhan pengguna.
Pandangan yang agak umum dari pendukung OO adalah bahwa analisis
berorientasi objek (OOA) dan desain berorientasi objek (OOD) sangat mirip. OOD
hanya menambahkan kelas khusus implementasi ke model analisis. Pandangan ini,
bagaimanapun, dapat dibantah. OOA harus berorientasi pada masalah; tujuannya
adalah untuk meningkatkan pemahaman kita tentang masalah. Tujuan dari desain,
apakah berorientasi objek atau tidak, adalah untuk memutuskan bagian dari solusi,
interaksinya, dan spesifikasi dari masing-masing bagian ini. Perbedaan ruang
lingkup ini menempatkan OOA dan OOD pada 'jarak' relatif yang berbeda dari suatu
masalah dan solusinya, seperti yang ditunjukkan pada gambar 12.32.
Gambar 12.32 'Jarak' antara OOA, OOD dan masalah serta solusinya
Ada alasan bagus untuk membedakan aktivitas tipe OOA dan aktivitas tipe
OOD, seperti yang dilakukan di Fusion, misalnya. Selama desain, perhatian
difokuskan pada menentukan cara membuat dan menghancurkan objek, pada
identifikasi generalisasi (abstrak, jika perlu) objek untuk mempromosikan
penggunaan kembali atau pemeliharaan, dan sebagainya. Sebuah Objek Publikasi
sebagai generalisasi dari Buku Dan Jurnal tidak perlu dipertimbangkan selama
analisis, karena tidak meningkatkan pemahaman kita tentang domain. Di sisi lain,
objek seperti kartu identitas mungkin menghilang dari model selama desain.
Sebagian besar organisasi pengembangan perangkat lunak telah
mengumpulkan banyak pengalaman dalam mengembangkan perangkat lunak
mengikuti gaya tradisional, berorientasi pada fungsi atau proses. Banyak perangkat
lunak warisan telah dikembangkan dan didokumentasikan dengan cara itu.
Konsekuensinya, pengetahuan tentang metode ini masih dibutuhkan di banyak
organisasi.
12.5. POLA DESAIN 377
Banyak organisasi telah beralih ke semacam analisis berorientasi objek dan

pendekatan desain. Bukti keras peningkatan produktivitas atau kualitas belum
ditentukan, meskipun. Beberapa percobaan telah dilakukan untuk menguji efektivitasnya
paradigma OO, dan hasilnya tampaknya menunjukkan beberapa masalah yang lebih dalam
juga. Misalnya, dalam satu percobaan diuji seberapa efektif berorientasi objek
model adalah sebagai kendaraan utama komunikasi antara pelanggan biasa
dan pengembang (Moynihan, 1996). Ditemukan bahwa tradisional, fungsional
model lebih mudah dipahami, memancing lebih banyak pertanyaan dan komentar, memberi
pemahaman bisnis yang lebih holistik, dan lebih baik membantu mengevaluasi kemungkinan
implementasi. Dalam percobaan lain diuji apakah analis pemula
mampu mengembangkan persyaratan lebih mudah dengan metode tertentu dibandingkan dengan yang
lain,
dan apakah mereka belajar menggunakan metode tertentu lebih mudah daripada yang lain (Vessey
dan Conger, 1994). Dan lagi, hasilnya negatif untuk OO: analis pemula
lebih mampu menerapkan metode berorientasi proses, dan pembelajaran yang signifikan saja
terjadi untuk metode berorientasi proses.
Dalam nada yang sama, (Arisholm dan Sjøberg, 2004) menemukan bahwa pengguna pemula
memiliki lebih sedikit
masalah pemeliharaan sistem yang memiliki kontrol terpusat dibandingkan dengan sistem
memiliki kontrol yang didelegasikan. Dalam gaya kontrol terpusat, satu atau beberapa kelas besar
berada dalam kendali. Kelas-kelas besar ini mengoordinasikan pekerjaan banyak kelas yang lebih kecil.
Ini menyerupai gaya arsitektur utama-program-dengan-subrutin hierarkis.
Dalam gaya yang didelegasikan, tanggung jawab didistribusikan ke kelas yang lebih besar. OO
pendukung biasanya menganjurkan gaya kontrol yang didelegasikan. Sepertinya seseorang
membutuhkan sesuatu
kedewasaan untuk menjadi efektif dengan gaya ini.
Mekanisme pewarisan orientasi objek perlu ditangani dengan hati-hati
juga, sebagaimana dicatat dalam bagian 12.1.6. Hirarki yang dalam membutuhkan seseorang untuk
memahami desain
atau unit implementasi yang mungkin terpisah jauh. Desain seperti itu cenderung error
rawan (Bieman et al., 2001) dan lebih sulit untuk diperiksa (Dunsmore et al., 2002),
karena sifat informasi yang terdelokalisasi di dalamnya.
Mungkin ada beberapa kebenaran dalam pengamatan yang tidak dipikirkan oleh pengguna
benda; mereka berpikir dalam tugas. Dari sudut pandang itu, analisis use-case dapat dilihat sebagai
salah satu cara untuk memperkenalkan tampilan fungsional ke dalam pendekatan berorientasi objek.
12.5 Pola desain

Pola desain adalah struktur berulang dari komponen komunikasi yang memecahkan
masalah desain umum dalam konteks tertentu. Pola desain berbeda dari
gaya arsitektur yang tidak membahas struktur sistem yang lengkap,
tetapi hanya beberapa komponen (berinteraksi). Pola desain dengan demikian dapat disebut
arsitektur mikro. Di sisi lain, pola desain mencakup lebih dari satu
komponen tunggal, prosedur atau modul.
Contoh pola dasar dari pola desain adalah Model--View--Controller
(MVC) pola. Sistem interaktif terdiri dari elemen komputasi serta
elemen untuk menampilkan data dan menangani input pengguna. Ini dianggap praktik desain yang baik
untuk memisahkan elemen komputasi dari yang menangani I/O. Pemisahan
perhatian ini dicapai dengan pola MVC.
MVC melibatkan tiga komponen: Model, View, dan Controller. Komponen model
merangkum data sistem serta operasi pada data tersebut. Komponen model tidak
bergantung pada bagaimana data direpresentasikan atau bagaimana input
dilakukan. Komponen tampilan menampilkan data yang diperolehnya dari komponen
model. Mungkin ada lebih dari satu komponen tampilan. Terakhir, setiap tampilan
memiliki komponen pengontrol yang terkait. Pengontrol menangani tindakan
masukan. Tindakan masukan tersebut dapat menyebabkan pengontrol mengirimkan
permintaan ke model, misalnya untuk memperbarui datanya, atau ke tampilannya,
misalnya untuk menggulir.
Untuk situasi apa pun, uraian di atas harus disempurnakan dan dibuat lebih
tepat. Sebagai contoh, pengontrol mungkin atau mungkin tidak bergantung pada
keadaan model. Jika pengontrol tidak bergantung pada keadaan model, ada aliran
informasi satu arah: pengontrol memberi sinyal peristiwa input dan memberi tahu
model. Jika pengontrol bergantung pada keadaan model, informasi juga mengalir ke
arah lain. Jenis ketergantungan yang terakhir dapat diamati di sebagian besar
sistem pengolah kata misalnya, di mana entri menu dibuat aktif atau tidak aktif
tergantung pada keadaan model.
MVC pertama kali digunakan di lingkungan Smalltalk. Sejak itu telah diterapkan
di banyak aplikasi. Dalam berbagai platform antarmuka pengguna grafis, varian
telah diterapkan di mana perbedaan antara tampilan dan pengontrol telah
dilonggarkan. Varian ini disebut pola Tampilan Dokumen; lihat (Kruglinski, 1996).
Pola desain memiliki sejumlah properti yang menjelaskan apa yang mereka
tawarkan, serta mengapa dan bagaimana mereka melakukannya:
�
�
Konteks Seorang klien membutuhkan layanan dari komponen lain. Padahal akses
langsung mungkin, ini mungkin bukan pendekatan terbaik.
Masalah Kami tidak ingin meng-hard-code akses ke komponen ke klien. Terkadang,

akses langsung seperti itu tidak efisien; dalam kasus lain mungkin tidak aman.
Ketidakefisienan atau ketidakamanan ini akan ditangani oleh mekanisme kontrol
tambahan, yang harus dipisahkan dari klien dan komponen yang memerlukan
akses.
Larutan Klien berkomunikasi dengan perwakilan daripada komponen itu sendiri.

Perwakilan ini, the proxy, juga melakukan pemrosesan awal dan akhir tambahan
yang diperlukan.
Gambar 12.33 Proksi pola
komunikasi, dan sebagainya), yang Proksi Perlindungan (perlindungan dari akses

yang tidak sah) dan Proksi Firewall (perlindungan klien lokal dari dunia luar). Server
World Wide Web biasanya menggunakan pola Firewall Proxy untuk melindungi
pengguna dari dunia luar. Contoh lain penggunaan pola Proxy dapat ditemukan
dalam kerangka kerja untuk sistem klien/server berbasis objek, seperti Common
Object Request Broker Architecture (CORBA) dan Microsoft DCOM (Lewandowski,
1998).
Sebagian besar pengguna sistem perpustakaan adalah pengguna insidental
yang kami inginkan antarmuka yang ramah, termasuk fasilitas undo yang kuat. Di
sisi lain, karyawan perpustakaan yang berpengalaman menginginkan antarmuka
pengguna dengan pintasan keyboard untuk sebagian besar perintah. Selain itu,
kami ingin dapat mencatat permintaan pengguna untuk analisis selanjutnya,
misalnya untuk mengetahui penulis mana yang banyak diminati. Kami ingin
memisahkan 'tambahan' ini dari kode aplikasi sebenarnya. Itu Pengolah Perintah
pattern mengatasi masalah ini. Contoh penggunaan pola Command Processor
dapat ditemukan di toolkit antarmuka pengguna seperti ET++ dan MacApp.
Karakteristiknya diberikan pada Gambar 12.348. Aplikasi biasanya melibatkan
campuran detail yang berkaitan dengan bidang yang berbeda, seperti domain
aplikasi, representasi data ke pengguna, akses ke server komputasi jarak jauh, dan
sebagainya. Jika detail ini tercampur dalam perangkat lunak, hasilnya akan sulit
untuk dipahami dan dipertahankan.
Perancang ahli telah belajar untuk memisahkan aspek-aspek tersebut untuk
meningkatkan pemeliharaan, fleksibilitas, kemampuan beradaptasi (singkatnya,
kualitas) dari sistem yang mereka rancang. Jika diperlukan, mereka
memperkenalkan beberapa entitas abstrak perantara untuk menjembatani aspek
solusi yang ingin mereka pisahkan. Pola Prosesor Proksi dan Perintah, serta banyak
pola desain lain yang ditemukan di (Gamma et al., 1995) dan (Buschmannet al.,
1996), menawarkan solusi yang elegan dan fleksibel untuk situasi desain tipe
pembagian dan penaklukan yang tepat ini.
8lihat (Buschmann et al., 1996, hlm 277--290) untuk penjelasan yang lebih terperinci.
Konteks Antarmuka pengguna yang harus fleksibel atau menyediakan

fungsionalitas yang melampaui penanganan langsung fungsi pengguna. Contohnya
adalah undo fasilitas atau fungsi logging.
Masalah Kami menginginkan solusi terstruktur dengan baik untuk memetakan

antarmuka ke fungsi internal sistem. Semua 'ekstra' yang berkaitan dengan cara
perintah pengguna dimasukkan, perintah tambahan seperti undo atau redo, dan
pemrosesan perintah pengguna non-aplikasi khusus, seperti logging, harus
disimpan terpisah dari antarmuka ke fungsionalitas internal.
Larutan Komponen terpisah, yaitu pemroses perintah, menangani semua perintah.

Komponen pemroses perintah menjadwalkan eksekusi perintah, menyimpannya
untuk dibatalkan nanti, mencatatnya untuk analisis nanti, dan seterusnya. Eksekusi
sebenarnya dari perintah didelegasikan ke komponen pemasok dalam aplikasi.
Gambar 12.34 Pengolah Perintah pola
Pola menggambarkan praktik umum yang telah terbukti bermanfaat. Antipola

menggambarkan praktik berulang yang telah terbukti menimbulkan masalah. Di
samping kumpulan pola, orang telah mengembangkan kumpulan kesalahan yang
sering dibuat, dan menggambarkannya sebagai antipola. Pengetahuan tentang
antipola berguna selama desain untuk mencegah perangkap umum, dan selama
evolusi untuk meningkatkan desain yang berkembang. Dalam kasus terakhir,
seseorang benar-benar mencari antipola dan selanjutnya menerapkan teknik yang
disebutpemfaktoran ulang untuk meningkatkan desain; lihat juga bab 14. Deskripsi
antipatterns biasanya menyertakan perbaikan pemfaktoran ulang. Beberapa
antipattern terkenal adalah:
�
mereka harus menggunakan paket basis data X atau toolkit antarmuka Y,
hanya karena mereka memiliki lisensi, atau karena karyawan mereka memiliki
pengetahuan mendalam tentang teknologi tersebut. Pada tingkat seorang
desainer individu, itu muncul sebagai penggunaan obsesif dari sekumpulan
kecil pola.
�
12.6. DOKUMENTASI DESAIN 383
5. Itu penguji unit harus memiliki informasi rinci tentang komponen, seperti
algoritma yang digunakan, diperlukan inisialisasi, dan data yang diperlukan.
6. Itu penguji integrasi harus tahu tentang hubungan antara komponen dan
fungsi dan penggunaan komponen yang terlibat.
7. Itu pemrogram pemeliharaan harus memiliki gambaran tentang hubungan
antar komponen. Dia harus tahu bagaimana kebutuhan pengguna direalisasikan
oleh berbagai komponen. Ketika perubahan harus diwujudkan, ia berperan
sebagai perancang.
Dalam Standar IEEE 1016, dokumentasi proyek digambarkan sebagai model
informasi. Entitas dalam model ini adalah komponen yang diidentifikasi selama
tahap desain. Kami menggunakan istilah 'modul' untuk entitas ini. Masing-masing
modul ini memiliki sejumlah atribut yang relevan, seperti nama, fungsi, dan
dependensinya. Kita sekarang dapat membuat matriks yang menunjukkan atribut
mana yang diperlukan untuk peran pengguna mana. Matriks ini digambarkan pada
Gambar 12.35.
A
t 1
r
i
b �
u
t
�
12.6. DOKUMENTASI DESAIN 385
berkonsentrasi pada aspek-aspek tertentu dari desain. Ini dapat dianggap sebagai
aplikasi dari praktik yang direkomendasikan IEEE untuk deskripsi arsitektural IEEE
(2000) jauh sebelum standar tersebut dikembangkan.
Itu deskripsi dekomposisi menggambarkan dekomposisi sistem menjadi modul.

Dengan menggunakan deskripsi ini kita dapat mengikuti dekomposisi hierarkis dan
dengan demikian menjelaskan berbagai tingkat abstraksi.
Itu deskripsi dependensi memberikan kopling antar modul. Ini juga merangkum
sumber daya yang dibutuhkan. Kami kemudian dapat memperoleh bagaimana
parameter dilewatkan dan data umum mana yang digunakan. Informasi ini berguna
saat merencanakan perubahan pada sistem dan saat mengisolasi kesalahan atau
masalah dalam penggunaan sumber daya.
Itu deskripsi antarmuka memberitahu kita bagaimana fungsi yang akan digunakan.
Informasi ini merupakan kontrak antara desainer yang berbeda dan antara desainer
dan pemrogram. Kesepakatan yang tepat tentang hal ini sangat dibutuhkan dalam
proyek multi-orang.
Itu deskripsi detail memberikan rincian internal dari setiap modul. Pemrogram membutuhkan ini
detail. Informasi ini juga berguna saat menyusun pengujian modul.
Tabel Tampilan pada desain (Sumber: H.J. Barnard et al, Praktik yang direkomendasikan untuk
12.4
menjelaskan desain perangkat lunak: Proyek Standar IEEE 1016, Transaksi IEEE pada Perangkat Lunak
Rekayasa SE-12, 2, Hak Cipta 1986, IEEE.)
Tampilan Keterangan Atribut Peran

desain pengguna
Penguraian Dekomposisi dari Identifikasi, Manajer
proyek
sistem ke jeni tujuan,
dalam s,
modul fungsi, subkom-
komponen
Ketergantungan Hubungan antara Identifikasi, Konfigurasi
modul Dan jeni tujuan, Pengelola,
s,
antara sumber daya dependensi, pemeliharaa
n
sumber daya programmer,
penguji integrasi
Antarmuka Cara menggunakan mod- Identifikasi, Desainer,
integrasi-
ules fungsi, antar penguji tion
wajah
Detil Rincian internal dari Identifikasi, Modul pen
guji
,
modul komputasi, data programmer
12.7 Verifikasi dan

Validasi
Kesalahan yang dibuat pada tahap awal sulit diperbaiki dan menimbulkan biaya
tinggi jika tidak ditemukan hingga tahap akhir pengembangan. Oleh karena itu perlu
memberikan perhatian yang luas untuk masalah pengujian dan validasi selama
tahap desain.
Cara di mana hasil dari proses desain dapat diuji sangat tergantung pada cara di
mana desain dicatat. Jika beberapa teknik spesifikasi formal digunakan, spesifikasi
yang dihasilkan dapat diuji secara formal. Dimungkinkan juga untuk melakukan uji
statis, seperti pemeriksaan konsistensi. Spesifikasi formal terkadang dapat
dieksekusi, yang menawarkan cara tambahan untuk menguji sistem. Prototipe
semacam itu sangat cocok untuk menguji antarmuka pengguna. Pengguna sering
memiliki sedikit gagasan tentang kemungkinan yang diharapkan dan prototipe
berbasis spesifikasi menawarkan peluang bagus untuk menyelaraskan kebutuhan
pengguna dan ide perancang. Seringkali, desain dinyatakan dengan cara
yang kurang formal, membatasi kemungkinan untuk menguji bentuk membaca dan
mengkritisi teks, seperti inspeksi dan penelusuran. Namun, tinjauan desain
semacam itu memberikan sarana yang sangat kuat untuk menilai desain.
Selama proses desain, sistem didekomposisi menjadi sejumlah modul. Kami
dapat mengembangkan kasus uji berdasarkan proses ini. Kasus uji ini dapat
digunakan selama pengujian fungsional pada tahap selanjutnya. Sebaliknya,
arsitektur perangkat lunak dapat digunakan untuk memandu proses pengujian. Satu
set skenario penggunaan masa depan khas atau diantisipasi dapat digunakan untuk
menguji kualitas arsitektur perangkat lunak.
Pembahasan yang lebih komprehensif tentang berbagai teknik tes diberikan
pada bab 13.
12.8 Ringkasan
Sama seperti mendesain rumah, mendesain perangkat lunak adalah aktivitas yang
menuntut kreativitas dan pengerjaan yang adil. Kualitas desainer sangat penting
dalam proses ini. Desainer yang biasa-biasa saja tidak akan menghasilkan desain
yang luar biasa. Inti dari proses desain adalah bahwa sistem didekomposisi
menjadi bagian-bagian yang masing-masing memiliki kompleksitas yang lebih kecil
daripada keseluruhannya. Beberapa bentuk abstraksi selalu digunakan dalam
proses ini. Kami telah mengidentifikasi beberapa prinsip panduan untuk dekomposisi
sistem menjadi modul. Prinsip-prinsip ini menghasilkan properti yang diinginkan
untuk hasil dari proses desain, satu set modul dengan saling ketergantungan:
�
12.8. RINGKASAN 387
�
– desain struktur data, dan
– desain berorientasi objek.

Tiga metode desain pertama telah ada paling lama. Analisis dan desain berorientasi
objek datang kemudian, dan sekarang ini adalah pendekatan yang paling banyak
digunakan, sebagian disebabkan juga oleh popularitas notasi Unified Modeling
Language (UML), alat terkaitnya, dan metode pengembangan skala penuh seperti
RUP.
Pendukung metode berorientasi objek mengklaim sejumlah keuntungan dari
pendekatan berorientasi objek dibandingkan pendekatan yang lebih tradisional,
berorientasi fungsi, untuk desain:
�
12.8. RINGKASAN 389
pendekatan fokus pada mengidentifikasi fungsi. Di dunia yang berkembang, objek
cenderung stabil, sedangkan fungsinya cenderung berubah. Misalnya, di kantor
lingkungan fungsi yang dilakukan cenderung berubah dengan waktu, tapi ada
akan selalu berupa huruf, folder, dan sebagainya. Dengan demikian, desain berorientasi
objek lebih sedikit
rentan terhadap perubahan di dunia yang dimodelkan.
�
lebih dari satu komponen. Ini melibatkan beberapa, biasanya 2--5, komponen
komunikasi yang bersama memecahkan masalah. Masalah yang dipecahkan oleh
pola adalah masalah yang umum dan berulang, yang dapat dicirikan oleh konteks di
mana pola itu muncul. Pola desain berbeda dari gaya arsitektur karena tidak
membahas struktur sistem yang lengkap, tetapi hanya beberapa (berinteraksi)
komponen. Pola desain dengan demikian dapat disebut mikro-arsitektur. Tidak
mengherankan, hal-hal baik tentang pola desain pada dasarnya sama dengan yang
tercantum untuk arsitektur perangkat lunak di bab 11.
Pola desain menggambarkan praktik terbaik. Mereka mewakili pengalaman
kolektif dari beberapa perancang perangkat lunak yang paling berpengalaman dan
sukses. Demikian pula, antipattern menggambarkan pengalaman buruk yang
dibagikan secara luas. Deskripsi pola dan antipola, seperti yang ditemukan dalam
buku teks, adalah hasil dari ukiran dan pemulusan tanpa akhir. Beberapa
merupakan hasil lokakarya penulis, format yang biasa digunakan untuk meninjau
literatur, menyarankan agar kita meninjau literatur perangkat lunak dengan
kedalaman seperti dulu. review puisi (akibatnya, bengkel penulis ini juga dikenal
sebagai bengkel tulis buruh).
Perbedaan antara pengertian arsitektur perangkat lunak dan pola desain sama
sekali tidak tajam. Beberapa penulis misalnya menggunakan istilah 'pola arsitektur'
untuk menunjukkan gaya arsitektur yang kita bahas di bagian 11.4. Kerangka
aplikasi pengertian dan idiom umumnya digunakan untuk menunjukkan arsitektur
perangkat lunak dan pola desain, masing-masing, pada tingkat yang lebih konkret,
implementasi-spesifik. Tapi sekali lagi, perbedaannya tidak tajam.
Terakhir, desain itu sendiri juga harus didokumentasikan. IEEE Standard 1016
dapat menjadi panduan untuk dokumentasi ini. Ini mencantumkan sejumlah atribut
untuk setiap komponen desain. Atribut ini dapat dikelompokkan menjadi empat
kelompok, yang masing-masing mewakili pandangan tertentu pada desain. Ini
menyerupai cara IEEE 1471 menganjurkan untuk mendokumentasikan arsitektur
perangkat lunak.
Sayangnya, dokumentasi desain biasanya hanya menjelaskan desainnya
hasildan bukan proses yang mengarah pada hasil tertentu itu. Namun, informasi
tentang pilihan yang dibuat, alternatif yang ditolak, dan pertimbangan pada
keputusan desain merupakan sumber informasi tambahan yang berharga ketika
sebuah desain akan diterapkan, dinilai, atau diubah.

Budgen (2003) adalah buku teks yang bagus tentang desain perangkat lunak. Saya
menemukan analogi 'perangkat lunak sebagai masalah jahat' dalam teks itu.
Bergland dan Gordon (1981) dan Freemanand Wasserman (1983) adalah kompilasi
dari artikel mani pada desain perangkat lunak. Untuk diskusi yang menarik tentang
pendekatan 'Skandinavia' untuk pengembangan sistem, lihat (Floyd et al., 1989)
atau (CACM, 1993a). Wieringa (1998) memberikan survei ekstensif tentang metode
desain klasik dan berorientasi objek serta notasinya.
Teks klasik tentang Analisis dan Desain Terstruktur adalah (Yourdon and
Constantine,1975). Nama lain yang terkait dengan pengembangan SA/SD adalah
DeMarco
(DeMarco, 1979) dan Gane dan Sarson (Gane dan Sarson, 1979).
Untuk eksposisi lengkap JSP, pembaca dirujuk ke (Jackson, 1975) atau (King,
1988). JSP sangat mirip dengan metode yang dikembangkan oleh J.-D. Warner di Perancis di
sekitar waktu yang sama (Warnier, 1974). Yang terakhir ini dikenal sebagai Logical Construction of
Programs (LCP) atau metode Warnier--Orr, setelah Ken Orr yang berperan penting
dalam terjemahan karya Warner. Untuk eksposisi lengkap JSD, lihat (Jackson, 1983),
(Cameron, 1989) atau (Sutcliffe, 1988). Notasi grafis yang digunakan dalam bab ini
adalah dari (Sutcliffe, 1988).
Metode Booch untuk analisis dan desain berorientasi objek dibahas dalam (Booch,
1994). Fusion dijelaskan dalam (Coleman et al., 1994). Pembaruan untuk versi 1994 ini
dapat ditemukan dalam (Coleman, 1996). RUP dibahas dalam (Kruchten, 2003). Kritis
diskusi tentang perbedaan dan persamaan antara analisis berorientasi objek dan
desain berorientasi objek diberikan dalam (Davis, 1995) dan (Hødalsvik dan Sindre, 1993).
Fenton dan Pfleeger (1996) menyajikan pendekatan yang ketat untuk topik perangkat lunak
metrik. Para penulis menjelaskan esensi dari teori pengukuran dan mengilustrasikannya
ini menggunakan sejumlah metrik yang diusulkan (termasuk untuk kompleksitas, kualitas
penilaian, dan estimasi biaya).
Kohesi dan kopling diperkenalkan di (Yourdon dan Constantine, 1975).
Upaya untuk mengobyektifkan pengertian tersebut dapat ditemukan dalam (Offutt et al., 1993), (Patel et
al.,
1992) dan (Xia, 2000). Darcy (2005) menjelaskan studi empiris untuk memvalidasi
pentingnya kopling lemah dan kohesi yang kuat.
Metode Halstead, 'ilmu perangkat lunak', dijelaskan dalam (Halstead, 1977) dan
(Fitzsimmons dan Cinta, 1978). Bukti positif validitasnya dilaporkan dalam (Curtis
et al., 1979) dan (Elshoff, 1976). Tinjauan yang baik tentang kritik terhadap metode ini
(serta kompleksitas siklomatik McCabe dan arus informasi Henri dan Kafura
metrik) diberikan dalam (Shepperd dan Ince, 1993). Kompleksitas siklomatik McCabe adalah
diperkenalkan di (McCabe, 1976). Dalam kebanyakan diskusi tentang metrik ini, rumusnya salah
digunakan; lihat latihan 24 atau (Henderson Sellers, 1992). Diskusi yang mendukung penggunaan a
kompleksitas (siklomatik). kepadatan metrik dapat ditemukan di (Mata-Toledo dan Gustafson,
1992) dan (Hops dan Sherif, 1995).
Definisi metrik berorientasi objek yang diperkenalkan di bagian 12.1.6 dapat berupa
ditemukan dalam (Chidamber dan Kemerer, 1994). Penilaian kritis dari metrik ini adalah
diberikan dalam (Hitz dan Montazeri, 1996) dan (Churcher dan Shepperd, 1995). Bertemu
beberapa kritik ini, kami telah mengadopsi definisi LCOM, seperti yang disarankan dalam (Li
dan Henry, 1993). Eksperimen untuk memvalidasi suite metrik Chidamber--Kemerer
dilaporkan dalam (Succi et al., 2003), (Darcy dan Kemerer, 2005) dan (Gyimóthy et al.,
2005).
Pola desain berasal dari karya Cunningham dan Beck, yang
mengembangkan pola untuk antarmuka pengguna di Smalltalk, seperti 'tidak lebih dari tiga panel
per jendela '(Power dan Weiss, 1987, hal. 16). MVC pertama kali digunakan di Smalltalk
lingkungan (Krasner dan Pope, 1988). Sejak saat itu, banyak topik yang menarik
perhatian, terutama di kalangan berorientasi objek. Koleksi utama pola desain
diterbitkan oleh 'Gang of Four' pada tahun 1995 (Gamma et al., 1995). Bagus lainnya
kumpulan pola desain dapat ditemukan di (Buschmann et al., 1996). Teks terakhir
memiliki perspektif yang agak kurang berorientasi objek dibandingkan (Gamma et
al., 1995). Brownet al. (1998) menjelaskan kumpulan antipattern terkenal. Sejak
tahun 1994, telah diadakan konferensi tahunan tentang Pola Bahasa Pemrograman
(PLOP). Format untuk menggambarkan pola tidak hanya digunakan untuk pola
desain; ada juga kumpulan pola analisis, pola proses, pola pengujian, dll.
Latihan
1. Apa perbedaan antara abstraksi prosedural dan abstraksi data?
2. Sebutkan dan jelaskan tujuh tingkat kohesi Yourdon dan Constantine.
3. Jelaskan pengertian kohesi dan kopel.
4. Dalam arti apa berbagai pengertian ketergantungan teknologi kopling?
5. Apa inti dari penyembunyian informasi?
6. Berikan garis besar ilmu perangkat lunak Halstead.
7. Tentukan kompleksitas siklomatis dari program berikut:
TIDAK 6:= benar; jumlah:= 0;

untuk Saya ke TIDAK dari kursus
Mengerjakan 6:= salah berakhir
jika nilai[i]
<
jika;
9. Berikan rumus dan alasan untuk metrik kompleksitas aliran informasi.
10. Apakah kompleksitas siklomatik merupakan indikator yang baik dari kompleksitas sistem?
11. Gambarlah grafik panggilan untuk program nontrivial yang telah Anda tulis, dan tentukan
kenajisan pohonnya. Apakah angka yang didapat sesuai dengan ide intuitif kita
tentang 'kualitas' dekomposisi?
12. Hitung metrik aliran informasi Henri dan Kafura untuk desain dua
sistem tempat Anda terlibat. Apakah angka-angka ini sesuai dengan intuisi kami
memahami?
13. Mengapa DIT -- kedalaman kelas dalam pohon pewarisan -- merupakan metrik yang berguna
untuk
pertimbangkan ketika menilai kualitas sistem berorientasi objek?
14. Apa yang diukur oleh RFC -- Response For a Class?
15. Bagaimana Hukum Demeter berhubungan dengan pemeliharaan berorientasi objek

sistem?
16. Diskusikan kelebihan dan kekurangan relatif dari dalam dan sempit versus lebar
dan pohon warisan yang dangkal.
17. Apa itu dekomposisi fungsional?
18. Berikan sketsa global metode Desain Aliran Data.
19. Jelaskan apa yang dimaksud dengan structure clash di JSP.
20. Apa perbedaan utama antara berorientasi masalah dan berorientasi produk
metode desain?
21. Diskusikan rasa umum alur kerja Analisis dan Desain RUP.
22. Apa perbedaan antara desain berorientasi objek dan yang sederhana
penerapan prinsip penyembunyian informasi?
23. Apa sifat-sifat pola desain?
24. ~
prosedur P;
mulai
jika X Kemudian DAN kalau tidak
DENGAN berakhir jika
akhir P;
Gambarkan diagram alur untuk program ini serta untuk program yang diperoleh
dengan mengganti badan prosedur P Di barisan. Tentukan siklomatik
kompleksitas kedua varian, menggunakan kedua formula. Lihat juga (Henderson Sellers,
1992).)
25. �
9
5
D. Untuk semua
G
grafik
13
Pengujian Perangkat Lunak
TUJUAN PEMBELAJARAN
�
397
Pengujian tidak boleh dibatasi hanya untuk menjalankan sistem untuk melihat apakah
input yang diberikan menghasilkan output yang benar. Selama fase sebelumnya, menengah
produk dapat, dan harus, diuji juga. Pengujian yang baik itu sulit. Dia
memerlukan perencanaan dan dokumentasi yang cermat. Ada sejumlah besar
teknik tes. Kami membahas kelas utama teknik pengujian dengan mereka
karakteristik.
Misalkan Anda diminta untuk menjawab jenis pertanyaan yang diajukan (Baber, 1982):
– Apakah Anda akan mempercayai pembangkit listrik tenaga nuklir yang sepenuhnya otomatis?
– Apakah Anda mempercayai pilot yang sepenuhnya otomatis yang perangkat lunaknya ditulis
oleh
dirimu sendiri? Bagaimana jika itu ditulis oleh salah satu rekan Anda?
– Apakah Anda berani menulis sistem pakar untuk mendiagnosis kanker?

Bagaimana jika Anda secara pribadi dimintai pertanggungjawaban dalam kasus
di mana seorang pasien meninggal karena kerusakan perangkat lunak?
Anda (mungkin) akan kesulitan menjawab semua pertanyaan ini secara afirmatif.
Mengapa? Perangkat keras sebuah pesawat mungkin sama rumitnya dengan perangkat lunak untuk
pesawat terbang
pilot otomatis. Namun, kebanyakan dari kita naik pesawat tanpa berpikir dua kali.
Karena ketergantungan masyarakat kita pada otomatisasi semakin meningkat, kualitas
sistem yang kami berikan semakin menentukan kualitas keberadaan kami. Kita tidak bisa
bersembunyi dari tanggung jawab ini. Peran otomatisasi dalam aplikasi kritis dan
ancaman yang ditimbulkan oleh aplikasi ini harus membuat kita merenung. Catatan Rekayasa Perangkat
Lunak ACM
menjalankan kolom 'Risiko kepada publik dalam sistem komputer' di mana kami diberi tahu
banyak (hampir) kecelakaan yang disebabkan oleh kegagalan perangkat lunak. Pembahasan tentang
perangkat lunak
keandalan yang diprovokasi oleh Inisiatif Pertahanan Strategis adalah contohnya (Parnas,
1985; Myers, 1986; Parnas, 1987). Diskusi, seperti tentang Therac-25
kecelakaan atau penerbangan perdana Ariane 5 (lihat bagian 1.4), harus diwajibkan
membaca untuk setiap insinyur perangkat lunak.
Rekayasa perangkat lunak adalah rekayasa. Insinyur mengincar solusi sempurna, tapi
tahu tujuan ini umumnya tidak dapat dicapai. Selama konstruksi perangkat lunak, kesalahan adalah
dibuat. Untuk menemukan dan memperbaiki kesalahan tersebut melalui pengujian yang berlebihan
adalah urusan yang melelahkan dan
kebanyakan tidak semua kesalahan ditemukan. Pengujian yang baik setidaknya sama sulitnya dengan
desain yang baik.
Dengan keadaan terkini kami tidak dapat memberikan perangkat lunak bebas kesalahan.
Studi yang berbeda menunjukkan bahwa 30--85 kesalahan per 1000 baris kode sumber dibuat.
Angka-angka ini tampaknya tidak membaik dari waktu ke waktu. Selama pengujian, beberapa dari
mereka
kesalahan ditemukan dan kemudian diperbaiki. Namun, beberapa kesalahan tetap tidak terdeteksi.
Myers (1986) memberikan contoh perangkat lunak yang diuji secara ekstensif yang masih berisi 0,5--3
kesalahan per 1000 baris kode. Kesalahan dalam sistem reservasi kursi maskapai besar
perusahaan mengalami kerugian sebesar $50 juta dalam satu kuartal. Sistem komputerisasi dilaporkan
bahwa kursi murah sudah habis terjual padahal kenyataannya tidak demikian. Sebagai konsekuensi,
398 PENGUJIAN PERANGKAT LUNAK
klien dirujuk ke perusahaan lain. Masalahnya tidak ditemukan sampai hasil kuartalan
ditemukan jauh tertinggal dari para pesaing mereka. Pengujian sering diartikan
menjalankan program untuk melihat apakah itu menghasilkan output yang benar untuk
input yang diberikan. Ini melibatkan pengujian produk akhir, perangkat lunak itu sendiri.
Akibatnya, kegiatan pengujian seringkali tidak mendapatkan perhatian yang layak.
Pada saat perangkat lunak telah ditulis, kami sering terdesak waktu, yang tidak
mendorong pengujian menyeluruh.
Menunda kegiatan pengujian terlalu lama adalah salah satu kesalahan paling
parah yang sering dilakukan dalam proyek pengembangan perangkat lunak.
Penundaan ini membuat pengujian menjadi urusan yang agak mahal. Gambar 13.1
menunjukkan hasil studi awal Boehm tentang biaya koreksi kesalahan relatif terhadap
fase di mana kesalahan ditemukan. Gambaran ini menunjukkan bahwa kesalahan
yang tidak ditemukan sampai perangkat lunak telah menjadi operasional menimbulkan
biaya 10 sampai 90 kali lebih tinggi daripada kesalahan yang ditemukan selama fase
desain. Rasio ini masih berlaku untuk sistem besar dan kritis (Boehm dan Basili,
2001). Untuk sistem kecil dan tidak kritis rasionya mungkin lebih seperti 1 banding 5.
Metode dan teknik pengembangan yang diterapkan pada tahap pra implementasi
relatif kurang berkembang. Oleh karena itu tidak mengherankan jika sebagian besar
kesalahan terjadi pada fase awal tersebut. Sebuah studi awal oleh Boehm
menunjukkan bahwa lebih dari 60% kesalahan diperkenalkan selama fase desain,
berlawanan dengan 40% selama implementasi (Boehm, 1975). Lebih buruk lagi, dua
pertiga dari kesalahan yang diperkenalkan pada fase desain tidak ditemukan sampai
setelah perangkat lunak beroperasi. Oleh karena itu, kami berkewajiban
untuk merencanakan dengan hati-hati kegiatan pengujian kami sedini mungkin. Kita
juga harus memulai kegiatan pengujian yang sebenarnya pada tahap awal. Bentuk
ekstremnya adalah pengembangan yang digerakkan oleh tes, salah satu praktik XP, di
mana pengembangan dimulai dengan tes tertulis. Jika kita tidak memulai pengujian
sampai setelah tahap implementasi, kita benar-benar terlambat. Spesifikasi
persyaratan, desain, dan spesifikasi desain juga dapat diuji. Kekakuan di sini
bergantung pada bentuk pengungkapan dokumen-dokumen ini. Hal ini telah
diisyaratkan pada bab-bab sebelumnya. Pada bagian 13.2, kami akan menyoroti
kembali berbagai aktivitas verifikasi dan validasi yang dapat diterapkan pada berbagai
fase siklus hidup perangkat lunak. Perencanaan dan dokumentasi kegiatan ini dibahas
di bagian 13.3. Sebelum kita memutuskan
pendekatan tertentu untuk pengujian, kita harus menentukan tujuan pengujian kita.
Jika tujuannya adalah untuk menemukan kesalahan sebanyak mungkin, kami akan
memilih strategi yang ditujukan untuk mengungkap kesalahan. Jika tujuannya adalah
untuk meningkatkan kepercayaan diri kita pada berfungsinya perangkat lunak dengan
benar, kita mungkin akan memilih strategi yang sama sekali berbeda. Jadi tujuan akan
berdampak pada pendekatan pengujian yang dipilih, karena hasilnya harus ditafsirkan
sehubungan dengan tujuan yang ditetapkan. Tujuan pengujian yang berbeda dan
sejauh mana pendekatan pengujian sesuai dengan tujuan ini adalah topik bagian 13.1.
Perangkat lunak pengujian hanya menunjukkan adanya kesalahan, bukan
ketidakhadirannya. Dengan demikian, ini menghasilkan hasil yang agak negatif: hanya
sampai sekarang N
399
Gambar 13.1 Biaya Relatif Koreksi Kesalahan (Sumber: Barry B. Boehm, Ekonomi
Rekayasa Perangkat Lunak, ara. 4.2, halaman 40, 1981, Dicetak ulang atas izin
Prentice Hall, Inc.Englewood Cliffs, NJ)
benar. Dalam prakteknya hal ini jarang terjadi. Sebuah program sederhana seperti
untuk Saya dari 1 ke 100 Mengerjakan

cetak (jika a[i] = benar Kemudian 1 kalau tidak 0 berakhir jika);
2
memiliki
Dengan demikian kita dipaksa untuk membuat pilihan. Sangatlah penting untuk
memilih serangkaian kasus uji yang cukup kecil, namun memadai. Teknik pengujian
dapat diklasifikasikan menurut kriteria yang digunakan untuk mengukur kecukupan
serangkaian kasus uji:
Pengujian berbasis cakupan Dalam pengujian berbasis cakupan, persyaratan

pengujian ditentukan dalam hal cakupan produk (program, dokumen persyaratan,
dll.) yang akan diuji. Sebagai contoh, kita dapat menetapkan bahwa semua
pernyataan program harus dijalankan setidaknya sekali jika kita menjalankan
rangkaian pengujian lengkap, atau bahwa semua persyaratan dasar dari spesifikasi
persyaratan harus dijalankan setidaknya sekali.
Pengujian berbasis kesalahan Teknik berbasis kesalahan fokus pada mendeteksi
kesalahan. Kemampuan mendeteksi kesalahan dari set tes kemudian menentukan
kecukupannya. Sebagai contoh, kita mungkin secara artifisial menyebarkan
sejumlah kesalahan dalam sebuah program, dan kemudian mengharuskan
pengujian untuk mengungkapkan setidaknya, katakanlah, 95% dari kesalahan
buatan ini.
Pengujian berbasis kesalahan Teknik berbasis kesalahan berfokus pada titik
rawan kesalahan, berdasarkan pengetahuan tentang kesalahan khas yang
dilakukan orang. Misalnya, kesalahan off-by-1 sering dibuat pada nilai batas seperti
0 atau jumlah maksimum elemen dalam daftar, dan kami mungkin secara khusus
mengarahkan upaya pengujian kami pada titik batas ini.
Atau, kami dapat mengklasifikasikan teknik uji berdasarkan sumber informasi yang
digunakan untuk menurunkan kasus uji:
Pengujian kotak hitam, disebut juga fungsional atau pengujian berbasis

spesifikasi. Dalam pengujian black-box, kasus uji berasal dari spesifikasi perangkat
lunak, yaitu kami tidak mempertimbangkan detail implementasi.
Pengujian kotak putih, disebut juga struktural atau pengujian berbasis program.
Ini adalah pendekatan pelengkap, di mana kita Mengerjakan pertimbangkan struktur
logis internal perangkat lunak dalam penurunan kasus uji.
Kami akan menggunakan klasifikasi pertama, dan membahas berbagai teknik untuk
pengujian berbasis cakupan, berbasis kesalahan, dan berbasis kesalahan di bagian
13.5--13.7. Teknik-teknik ini melibatkan eksekusi sebenarnya dari sebuah program.
Teknik manual yang tidak melibatkan eksekusi program, seperti pembacaan kode
dan inspeksi, dibahas di bagian 13.4. Pada bagian 13.8 kami menilai beberapa studi
empiris dan teoretis yang bertujuan untuk menempatkan teknik pengujian yang
berbeda ini dalam perspektif.
Teknik di atas diterapkan terutama pada tingkat komponen. Tingkat pengujian ini
sering dilakukan bersamaan dengan tahap implementasi. Itu juga disebutpengujian
satuan. Selain level komponen, kita juga harus menguji integrasi sekumpulan
komponen ke dalam sistem. Kemungkinan juga, sistem final akan diuji sekali lagi di
bawah pengawasan langsung dari calon pengguna. Pada bagian 13.9 kita akan
membuat sketsa fase pengujian yang berbeda ini.
Pada tingkat sistem, tujuan yang dikejar sering bergeser dari mendeteksi
kesalahan menjadi membangun kepercayaan, dengan menilai keandalan secara
kuantitatif. Keandalan perangkat lunak dibahas pada bagian 13.10.
13.1. TUJUAN UJI 401
13.1 Tujuan Tes

Hingga saat ini, kami belum terlalu tepat dalam menggunakan gagasan 'kesalahan'.
Untuk menghargai diskusi berikut, penting untuk membuat perbedaan yang cermat
di antara gagasan-gagasan tersebut kesalahan, kesalahan Dan kegagalan.
Kesalahan adalah tindakan manusia yang menghasilkan hasil yang salah.
Konsekuensi dari kesalahan adalah perangkat lunak yang mengandung kesalahan.
Sebuah kesalahan dengan demikian adalah manifestasi dari kesalahan. Jika
ditemui, kesalahan dapat mengakibatkan kegagalan.1
Jadi, yang kami amati selama pengujian adalah kegagalan. Kegagalan ini disebabkan oleh
kesalahan,
yang pada gilirannya merupakan akibat dari kesalahan manusia. Kegagalan dapat disebabkan oleh lebih
dari
satu kesalahan, dan kesalahan dapat menyebabkan kegagalan yang berbeda. Demikian pula hubungan
antara
kesalahan dan kesalahan tidak harus 1--1.
Salah satu tujuan pengujian yang mungkin adalah untuk menemukan kesalahan dalam perangkat
lunak. Tes kemudian dimaksudkan
untuk mengekspos kegagalan. Tidak mudah untuk memberikan definisi yang tepat, unik, dari gagasan
tersebut
kegagalan. Seorang programmer dapat mengambil spesifikasi sistem sebagai titik referensi. Di dalam
pandangan ini, kegagalan terjadi jika perangkat lunak tidak memenuhi spesifikasi. Pengguna,
Namun, dapat menganggap perangkat lunak itu salah jika tidak sesuai dengan harapan.
'Kegagalan' dengan demikian adalah gagasan yang relatif. Jika perangkat lunak gagal, ia melakukannya
sehubungan dengan sesuatu
lain (spesifikasi, panduan pengguna, dll). Saat menguji perangkat lunak, kita harus selalu begitu
menyadari apa perangkat lunak sedang diuji terhadap.
Dalam hal ini perbedaan sering dibuat antara 'verifikasi' dan 'validasi'.
Itu Glosarium IEEE mendefinisikan verifikasi sebagai proses mengevaluasi suatu sistem atau
komponen untuk menentukan apakah produk dari fase pengembangan tertentu memuaskan
kondisi yang diberlakukan pada awal fase itu. Verifikasi demikian mencoba untuk menjawab
pertanyaan: Apakah sistem yang kita bangun sudah benar?
Istilah 'validasi' didefinisikan dalam Glosarium IEEE sebagai proses evaluasi a
sistem atau komponen selama atau pada akhir proses pengembangan untuk menentukan
apakah memenuhi persyaratan yang ditentukan. Validasi kemudian bermuara pada pertanyaan:
Sudahkah kita membangun sistem yang tepat?
Bahkan dengan pembedaan yang halus ini, situasinya tidak begitu jelas.
Secara umum, sebuah program dianggap benar jika secara konsisten menghasilkan output yang tepat.
Namun, kita dapat dengan mudah membayangkan situasi di mana niat programmer tidak demikian
tercermin dengan benar dalam program tetapi kesalahan tidak muncul dengan sendirinya.
Sebuah studi empiris awal menunjukkan bahwa banyak kesalahan tidak pernah diaktifkan selama
umur sistem (Adams, 1984). Apakah layak memperbaiki kesalahan itu? Misalnya, beberapa
entri dalam pernyataan kasus mungkin salah, tetapi kesalahan ini tidak pernah muncul karena itu
kebetulan dimasukkan oleh entri sebelumnya. Apakah program ini benar, atau haruskah
lebih suka diklasifikasikan sebagai program dengan kesalahan 'laten'? Bahkan jika itu dianggap benar
1Itu IEEE Glosarium Terminologi Rekayasa Perangkat Lunak memberikan empat definisi dari kata
'kesalahan'. Untuk membedakan antara definisi ini, kata 'kesalahan', 'kesalahan', 'kegagalan' dan 'kesalahan'
digunakan. Kata 'kesalahan' dalam Glosarium digunakan untuk menunjukkan kesalahan pengukuran,
sedangkan 'kesalahan' digunakan untuk menunjukkan kesalahan manusia. Meskipun 'kesalahan' memiliki
keuntungan karena tidak terlalu menyalahkan, kami mengikuti literatur rekayasa perangkat lunak yang
diterima dalam hal ini. Definisi kami tentang 'kesalahan' dan 'kegagalan' sama dengan yang ada
diGlosarium.
dalam konteks yang ada, kemungkinan besar kita mendapat masalah jika program
diubah atau sebagian digunakan kembali di lingkungan yang berbeda.
Sebagai contoh, perhatikan penerbangan perdana Ariane 5. Dalam waktu 40
detik setelah lepas landas, di ketinggian 3700 meter, peluncurnya meledak. Ini pada
akhirnya disebabkan oleh luapan dalam konversi variabel dari angka floating point
64-bit ke bilangan bulat bertanda 16-bit. Sepotong perangkat lunak yang
mengandung kesalahan ini digunakan kembali dari Ariane 4 dan telah tidak pernah
menyebabkan masalah di salah satu penerbangan Ariane 4. Hal ini dijelaskan oleh
fakta bahwa Ariane 5 membangun kecepatan jauh lebih cepat daripada Ariane 4,
yang pada gilirannya menghasilkan nilai yang berlebihan untuk parameter yang
dimaksud; lihat juga bagian 1.4.1.
Dengan definisi kesalahan dan kesalahan di atas, program semacam itu harus
dianggap salah, bahkan jika kita tidak dapat merancang kasus uji yang
mengungkapkan kesalahan tersebut. Ini masih menyisakan pertanyaan tentang
bagaimana mendefinisikan kesalahan. Karena kita tidak bisa tidak menebak apa
maksud sebenarnya dari programmer itu, ini hanya dapat diputuskan oleh seorang
oracle. Mengingat fakta bahwa pengujian lengkap tidak layak, proses pengujian
dapat dianggap seperti yang digambarkan pada Gambar 13.2. Kotak berlabel P
menunjukkan objek (program, dokumen desain, dll.) yang akan diuji. Strategi tes
melibatkan pemilihan subset dari domain input. Untuk setiap elemen subset ini, P
digunakan untuk 'menghitung' output yang sesuai. Output yang diharapkan
ditentukan oleh oracle, sesuatu di luar aktivitas pengujian. Terakhir, kedua jawaban
tersebut dibandingkan.
Gambar 13.2 Tampilan global dari proses

pengujian
Langkah yang paling penting dalam proses ini adalah pemilihan subset dari
inputdomain yang akan berfungsi sebagai test set. Set tes ini harus memadai
sehubungan dengan beberapa kriteria tes yang dipilih. Pada bagian 13.1.1 kami
menguraikan gagasan kecukupan pengujian.
Teknik pengujian umumnya menggunakan beberapa cara sistematis untuk
menurunkan kasus uji. Kasus-kasus uji ini dimaksudkan untuk memprovokasi
kegagalan. Jadi, tujuan utamanya adalah deteksi kesalahan. Sebagai alternatif,
tujuan pengujian kami adalah untuk meningkatkan kepercayaan diri kami pada
perilaku bebas kegagalan. Tujuan tes yang sangat berbeda ini, dan dampaknya
pada masalah pemilihan tes, adalah topik dari bagian 13.1.2.
Untuk menguji apakah tujuan tercapai, uji kasus diadili agar kesalahan itu terjadi
menampakkan diri. Pendekatan yang sangat berbeda adalah melihat pengujian sebagai pencegahan
kesalahan.
Ini membawa kita ke dimensi lain dari tujuan pengujian, yang sebagian besar paralel
evolusi strategi pengujian selama bertahun-tahun. Evolusi ini dibahas di
bagian 13.1.3.
Akhirnya, gambaran sejauh ini menganggap setiap kesalahan sama berbahayanya. Pada
kenyataannya,
ada berbagai jenis kesalahan, dan beberapa kesalahan lebih berbahaya daripada yang lain. Semua
teknik yang akan dibahas dalam bab ini dapat dengan mudah digeneralisasikan untuk mencakup banyak
hal
kelas kesalahan, masing-masing dengan kriteria penerimaannya sendiri.
Beberapa kesalahan sangat penting dan kami harus mengerahkan diri untuk menemukannya
kesalahan kritis. Teknik khusus, seperti analisis pohon kesalahan, telah dikembangkan
untuk akhir ini. Menggunakan analisis pohon kesalahan, kami mencoba menurunkan kontradiksi dengan
penalaran
mundur dari situasi akhir yang diberikan, tidak diinginkan. Jika kontradiksi tersebut dapat
diturunkan, kami telah menunjukkan bahwa situasi tertentu tidak pernah dapat dicapai.
13.1.1 Uji Kriteria Kecukupan

Pertimbangkan teks program pada gambar 13.3 dan satu set tes
S
Dalam arti tertentu, kriteria kecukupan tes yang diberikan dan teknik tes yang sesuai
adalah sisi berlawanan dari mata uang yang sama.
13.1.2 Deteksi Kesalahan Versus

Membangun Keyakinan
Kegagalan adalah jarum di tumpukan jerami dari domain input
(Hamlet dan Taylor, 1990)
Misalkan kita ingin menguji beberapa komponen P yang mengurutkan array

SEBUAH[1..n] bilangan bulat,1 �
prosedur seleksi-urutan (A, n);

bilangan bulat saya, j, kecil, temp;
mulai
untuk saya:= 1 ke n-1 Mengerjakan
kecil:= saya;
untuk j:= i+1 ke N Mengerjakan
jika abs(A[j])
<
13.1.3 Dari Deteksi Kesalahan ke

Pencegahan Kesalahan
Pada hari-hari awal komputasi, program ditulis dan kemudian di-debug untuk
memastikan program berjalan dengan benar. Testing dan debugging sebagian besar
adalah istilah yang sinonim. Keduanya merujuk pada aktivitas menjelang akhir
proses pengembangan ketika perangkat lunak telah ditulis, tetapi masih perlu
'diperiksa'.
Situasi hari ini agak berbeda. Kegiatan pengujian terjadi di setiap fase proses
pengembangan. Mereka direncanakan dan didokumentasikan dengan hati-hati.
Eksekusi perangkat lunak untuk membandingkan perilaku aktual dengan perilaku
yang diharapkan hanyalah salah satu dari banyak aspek.
Gelperin dan Hetzel (1988) mengidentifikasi empat model pengujian utama. Ini
kira-kira paralel dengan perkembangan historis praktik pengujian. Model dan tujuan
utamanya diberikan pada Gambar 13.4.
Model Tujuan utama

Model fase
Demonstrasi Pastikan bahwa perangkat lunak memenuhi
Penghancuran spesifikasinya
fikasi
Model siklus hidup
Mendeteksi kesalahan implementasi
Evaluasi Mendeteksi persyaratan, desain, dan
Pencegahan implementasi
kesalahan tasi
Mencegah persyaratan, desain, dan
implementasi
kesalahan tasi
Gambar 13.4 Model pengujian utama (Sumber: D Gelperin & B Hetzel,

Pertumbuhan pengujian perangkat lunak, Komunikasi ACM 31, 6 (1988) 687-695.
Direproduksi atas izin dari Association for Computing Machinery, Inc.)
Tujuan utama dari model demonstrasi adalah untuk memastikan bahwa program
berjalan dan memecahkan masalah. Strateginya seperti bukti matematis yang
konstruktif. Jika perangkat lunak lulus semua tes dari set tes, itu diklaim memenuhi
persyaratan. Strategi tersebut tidak memberikan panduan tentang bagaimana cara
mendapatkan perangkat tes semacam itu. Set pengujian yang dipilih secara salah
dapat menutupi kualitas perangkat lunak yang buruk.
Sebagian besar pemrogram akan terbiasa dengan proses pengujian program
mereka sendiri dengan membaca atau menjalankannya dengan hati-hati dengan
data masukan yang dipilih. Jika ini dilakukan dengan sangat hati-hati, itu bisa
bermanfaat. Namun, metode ini juga memiliki beberapa bahaya. Kita mungkin
cenderung menganggap bentuk pengujian ini sebagai metode untuk meyakinkan
diri kita sendiri atau orang lain yang dilakukan perangkat lunak tersebut bukan mengandung kesalahan.
Kami kemudian akan,
sebagian secara tidak sadar, mencari kasus uji yang mendukung hipotesis ini. Jenis ini
pendekatan berorientasi demonstrasi untuk pengujian tidak dianjurkan.
Pengujian yang tepat adalah proses yang sangat merusak. Suatu program harus diuji dengan
tujuan untuk menemukan kesalahan sebanyak mungkin. Tes hanya dapat dianggap berhasil
jika itu mengarah pada penemuan setidaknya satu kesalahan. (Dengan cara yang sama, kunjungan ke
dokter hanya berhasil jika dia menemukan 'kesalahan' dan kami biasanya akan mempertimbangkannya
kunjungan tidak memuaskan jika kami dipulangkan dengan pesan bahwa tidak ada yang salah
ditemukan.)
Untuk meningkatkan peluang menghasilkan sistem berkualitas tinggi, kita harus
membalikkan strategi dan mulai mencari kasus uji itu Mengerjakan mengungkapkan kesalahan. Ini
mungkin
disebut pembuktian dengan kontradiksi. Set tes kemudian dinilai dari kemampuannya untuk mendeteksi
kesalahan.
Karena kita tidak tahu apakah ada sisa kesalahan yang tersisa, sulit untuk memutuskannya
kapan harus menghentikan pengujian di salah satu model ini. Dalam model berorientasi demonstrasi,
kriteria yang paling sering digunakan untuk menentukan titik waktu ini tampaknya adalah sebagai
berikut:
– berhenti jika anggaran tes habis;
– berhenti jika semua test case telah dijalankan tanpa ada kegagalan yang terjadi.
Kriteria pertama tidak ada gunanya, karena tidak memberi tahu kami apa pun tentang kualitas
dari upaya pengujian. Jika tidak ada uang sama sekali, kriteria ini paling mudah dipenuhi.
Kriteria kedua juga tidak ada gunanya, karena tidak memberi tahu kita apa pun tentang
kualitas kasus uji.
Model yang berorientasi kehancuran biasanya memerlukan beberapa cara sistematis untuk
menurunkannya
kasus uji. Kami kemudian dapat mendasarkan kriteria berhenti kami pada kriteria kecukupan uji itu
sesuai dengan teknik tes yang digunakan. Contohnya mungkin: 'Kami berhenti menguji
jika 100% cabang dicakup oleh kumpulan kasus uji, dan semua kasus uji menghasilkan
hasil yang gagal’.
Kedua model ini memandang pengujian sebagai salah satu fase dalam proses pengembangan
perangkat lunak.
Seperti disebutkan sebelumnya, ini bukan strategi yang sangat baik. Model pengujian siklus hidup
diperpanjang
kegiatan pengujian ke fase sebelumnya. Dalam model berorientasi evaluasi, penekanannya
adalah teknik analisis dan peninjauan untuk mendeteksi kesalahan dalam persyaratan dan desain
dokumen. Dalam model pencegahan, penekanannya adalah pada perencanaan dan desain yang cermat
dari kegiatan tes. Misalnya, desain awal kasus uji dapat mengungkapkan hal itu
persyaratan tidak dapat diuji dan dengan demikian aktivitas semacam itu membantu mencegah
kesalahan
yang dibuat di tempat pertama. Pengembangan berbasis tes juga termasuk dalam kategori ini.
Kami dapat mengamati pergeseran penekanan secara bertahap dalam praktik pengujian, dari
demonstrasi-
seperti pendekatan metode berorientasi pencegahan. Padahal masih banyak organisasi
memusatkan upaya pengujian mereka di akhir siklus hidup pengembangan, berbagai organisasi
telah menunjukkan bahwa kegiatan pengujian hulu dapat menjadi yang paling efektif. Kuantitatif
buktinya diberikan di bagian 13.8.3.
Pengujian tidak hanya menghasilkan perangkat lunak dengan lebih sedikit kesalahan. Pengujian
juga menghasilkan
pengetahuan berharga (konstruksi rawan kesalahan dan sebagainya) yang dapat dimasukkan kembali
proses pembangunan. Dalam pandangan ini, pengujian adalah proses
pembelajaran, yang dapat diberikan tempat yang tepat dalam proses perbaikan.
13.2 Pengujian dan Siklus Hidup

Perangkat Lunak
Pada subbab berikut kita akan membahas berbagai kegiatan verifikasi dan validasi
yang dapat dilakukan selama fase rekayasa kebutuhan, desain, implementasi dan
pemeliharaan. Dalam melakukannya, kami juga akan menunjukkan teknik dan alat
yang dapat diterapkan. Teknik dan alat ini akan dibahas lebih lanjut di bagian
selanjutnya. Ringkasan diberikan pada gambar 13.5.
Fase Kegiatan
Rekayasa kebutuhanDesain
- menentukan strategi pengujian
-- spesifikasi persyaratan tes
- menghasilkan data uji fungsional
Penerapan -- periksa konsistensi antara desain dan
kebutuhan-
spesifikasi
- mengevaluasi arsitektur perangkat lunak
Pemeliharaan -- uji desainnya
- menghasilkan data uji struktural dan fungsional
-- periksa konsistensi antara desain dan
implementasi-
pemikiran
-- uji implementasi
- menghasilkan data uji struktural dan fungsional
-- jalankan tes
- ulangi tes di atas sesuai dengan
derajat pembangunan kembali
Gambar 13.5 Aktivitas dalam berbagai fase siklus hidup perangkat lunak (Diadaptasi
dariW.R. Adrion, M.A. Branstad & J.C. Cherniavski, Validasi, verifikasi, dan
pengujian perangkat lunak komputer, Survei Komputasi ACM 14, 2 (1982),
Direproduksi dengan izin dari Associationfor Computing Machinery, Inc.)
Pengembang perangkat lunak bertujuan untuk membersihkan kode yang berfungsi.

Kami mencoba melakukannya dengan terlebih dahulu berfokus pada bagian "kode
bersih", dan selanjutnya pada bagian "yang berfungsi". Bagian cleancode adalah
tentang analisis dan desain yang tepat, menulis kode yang elegan dan kuat, dan
sejenisnya. Hanya setelah kami selesai dengan itu, kami mulai menguji untuk
memastikan perangkat lunak berfungsi dengan baik. Test-driven development (TDD)
mengambil pendekatan sebaliknya: kami
13.2. PENGUJIAN DAN SIKLUS HIDUP 409
PERANGKAT LUNAK
pertama-tama pastikan perangkat lunak berfungsi, lalu tangani bagian kode bersih. Kita diskusikan
pengembangan berbasis tes di bagian 13.2.5.
13.2.1 Rekayasa Persyaratan

Teknik verifikasi dan validasi yang diterapkan selama fase ini sangat tergantung
pada cara di mana spesifikasi persyaratan telah ditetapkan. Sesuatu yang paling
tidak harus dilakukan adalah melakukan tinjauan atau inspeksi yang cermat untuk
memeriksa apakah semua aspek sistem telah dideskripsikan dengan benar. Seperti
yang kita lihat sebelumnya, kesalahan yang dibuat pada tahap ini sangat mahal
untuk diperbaiki jika tidak diketahui hingga akhir proses pengembangan. Boehm
memberikan empat kriteria penting untuk spesifikasi kebutuhan (Boehm, 1984b):
– kelengkapan;
– konsistensi;
- kelayakan;
– testabilitas.
Menguji spesifikasi persyaratan terutama harus ditujukan untuk menguji ini
kriteria.
Tujuan dari pengujian kriteria ketuntasan kemudian adalah untuk menentukan apakah semua
komponen hadir dan dijelaskan secara lengkap. Spesifikasi kebutuhan adalah
tidak lengkap jika mengandung frase seperti 'akan ditentukan' atau jika mengandung referensi
ke elemen yang tidak terdefinisi. Kita juga harus memperhatikan penghilangan fungsi atau
produk, seperti prosedur cadangan atau mulai ulang dan alat uji untuk dikirim ke
pelanggan.
Spesifikasi persyaratan konsisten jika komponennya tidak bertentangan
satu sama lain dan spesifikasi tidak bertentangan dengan spesifikasi eksternal. Kami
dengan demikian membutuhkan konsistensi internal dan eksternal. Selain itu, setiap elemen dalam
spesifikasi kebutuhan harus dapat dilacak. Itu harus, misalnya, mungkin untuk
memutuskan apakah antarmuka bahasa alami benar-benar dibutuhkan.
Menurut Boehm, kelayakan lebih dari fungsional dan
persyaratan kinerja. Manfaat dari sistem komputerisasi harus lebih besar daripada
biaya terkait. Ini harus ditetapkan pada tahap awal dan membutuhkan waktu yang tepat
memperhatikan kebutuhan pengguna, pemeliharaan, kehandalan, dan sebagainya. Dalam beberapa
kasus,
keberhasilan proyek sangat sensitif terhadap faktor kunci tertentu, seperti keamanan, kecepatan,
ketersediaan jenis personel tertentu; risiko ini harus dianalisis sejak dini
panggung.
Terakhir, spesifikasi persyaratan harus dapat diuji. Pada akhirnya, kita harus bisa
untuk memutuskan apakah suatu sistem memenuhi kebutuhannya atau tidak. Jadi persyaratan harus
spesifik, tidak ambigu, dan kuantitatif. Kerangka skenario atribut kualitas
dari (Bass et al., 2003) adalah contoh bagaimana menentukan persyaratan tersebut; Lihat juga
bagian 6.3.
Banyak dari poin-poin ini dikemukakan oleh Poston (1987). Menurut Poston,
kesalahan yang paling mungkin terjadi dalam spesifikasi persyaratan dapat
dikelompokkan ke dalam kategori berikut:
– informasi yang hilang (fungsi, antarmuka, kinerja, batasan, keandalan,

dan seterusnya);
– informasi yang salah (tidak dapat dilacak, tidak dapat diuji, ambigu, dan
sebagainya);
– informasi tambahan (lonceng dan peluit).
Menggunakan format standar untuk mendokumentasikan spesifikasi persyaratan,

seperti IEEEStandard 830 yang dibahas dalam bab 9, dapat sangat membantu
dalam mencegah jenis kesalahan ini terjadi sejak awal.
Teknik yang berguna untuk menguji sejauh mana kriteria telah dipenuhi,
sebagian besar manual (membaca dokumen, inspeksi, ulasan). Skenario untuk
penggunaan sistem yang diharapkan dapat dirancang dengan calon pengguna
sistem. Jika persyaratan sudah dinyatakan dalam kasus penggunaan, skenario
seperti itu sudah tersedia. Dengan cara ini, serangkaian pengujian fungsional
dihasilkan.
Pada tahap ini juga, strategi tes umum untuk fase selanjutnya harus dirumuskan.
Ini harus mencakup pilihan teknik tes tertentu; kriteria evaluasi; rencana uji; skema
pengujian; dan persyaratan dokumentasi pengujian. Tim penguji juga dapat dibentuk
pada tahap ini. Kegiatan perencanaan ini dibahas di bagian 13.3.
13.2.2 Desain
Kriteria yang disebutkan dalam sub-bagian sebelumnya (kelengkapan, konsistensi,
kelayakan, dan keterujian) juga penting untuk desain. Kesalahan yang paling
mungkin terjadi dalam desain menyerupai jenis kesalahan yang cenderung
dilakukan seseorang dalam spesifikasi persyaratan: informasi yang hilang, salah,
dan asing. Untuk desain juga, standar dokumentasi yang tepat sangat membantu
dalam mencegah jenis kesalahan ini. IEEE Standard1016, dibahas dalam bab 12,
adalah salah satu standar tersebut.
Selama fase desain, kami menguraikan sistem total menjadi subsistem dan
komponen, mulai dari spesifikasi kebutuhan. Kami kemudian dapat
mengembangkan tes berdasarkan proses dekomposisi ini. Desain bukanlah proses
sekali pakai. Selama proses desain sejumlah penyempurnaan berturut-turut akan
dilakukan, menghasilkan lapisan yang menunjukkan detail yang meningkat.
Mengikuti proses desain ini, tes yang lebih rinci dapat dikembangkan saat lapisan
bawah desain diputuskan.
Selama fase desain arsitektur, model konseptual tingkat tinggi dari sistem
dikembangkan dalam hal komponen dan interaksinya. Arsitektur ini dapat dinilai,
misalnya dengan membuat skenario yang mengungkapkan masalah kualitas seperti
pemeliharaan dan fleksibilitas dalam istilah yang sangat konkret, dan selanjutnya
mengevaluasi bagaimana arsitektur menangani skenario ini; lihat juga bagian 11.5.
Selama fase desain, kami juga dapat menguji desain itu sendiri. Ini termasuk
elemen penelusuran dari spesifikasi persyaratan ke elemen terkait di
13.2. PENGUJIAN DAN SIKLUS HIDUP 411
PERANGKAT LUNAK
deskripsi desain, dan sebaliknya. Teknik terkenal untuk melakukannya adalah, di antaranya
lainnya, simulasi, penelusuran desain, dan inspeksi desain.
Pada tahap rekayasa persyaratan, kemungkinan untuk secara formal mendokumentasikan
spesifikasi yang dihasilkan terbatas. Sebagian besar spesifikasi persyaratan dibuat
penggunaan deskripsi bahasa alami yang berlebihan. Untuk tahap desain, jumlahnya cukup banyak
peluang untuk secara resmi mendokumentasikan spesifikasi yang dihasilkan. Semakin formal
desain ditentukan, semakin banyak kemungkinan yang kita miliki untuk menerapkan teknik verifikasi,
serta pemeriksaan formal untuk konsistensi dan kelengkapan.
13.2.3 Penerapan
Selama fase implementasi, kami melakukan pengujian 'nyata'. Salah satu yang paling efektif
teknik untuk menemukan kesalahan dalam teks program adalah dengan hati-hati membaca teks itu, atau
membacanya.
Teknik ini telah berhasil diterapkan sejak lama. Agak diformalkan
varian dikenal sebagai pemeriksaan kode dan penelusuran kode. Kami juga dapat menerapkan
teknik abstraksi bertahap. Dalam abstraksi bertahap, fungsi kode adalah
ditentukan dalam beberapa langkah abstraksi, mulai dari kode itu sendiri. Berbagai
teknik uji manual akan dibahas pada bagian 13.4.
Ada banyak alat untuk mendukung pengujian kode. Kita dapat membedakan antara
alat untuk analisis statis dan alat untuk analisis dinamis. Alat analisis statis memeriksa
kode program tanpa mengeksekusinya. Mereka termasuk tes seperti: memiliki semua variabel
telah dideklarasikan dan diberi nilai sebelum digunakan?
Alat analisis dinamis digunakan bersamaan dengan eksekusi sebenarnya dari
kode, misalnya alat yang melacak bagian mana dari kode tersebut
ditutupi oleh tes sejauh ini.
Kami dapat mencoba membuktikan kebenaran kode menggunakan verifikasi formal
teknik.
Semua teknik di atas ditujukan untuk mengevaluasi kualitas kode sumber
serta kesesuaiannya dengan spesifikasi desain dan dokumentasi kode.
Sangat penting untuk mengontrol informasi pengujian dengan benar saat menguji kode. Peralatan
dapat membantu kami dalam melakukannya, misalnya test driver, test stubs dan test data generators.
Test driver adalah alat yang menghasilkan lingkungan pengujian untuk komponen yang akan dibuat
diuji. Rintisan uji melakukan yang sebaliknya: ia mensimulasikan fungsi komponen bukan
belum tersedia. Dalam pengujian bottom-up, secara umum kita akan banyak menggunakan test driver,
sementara pengujian top-down menyiratkan penggunaan bertopik uji. Strategi pengujian (top-down
versus bottom-up) mungkin sebagian dipengaruhi oleh teknik desain yang digunakan. Jika tinggi
tingkat, desain arsitektur diimplementasikan sebagai sistem kerangka yang belum memiliki lubang
untuk diisi, sistem kerangka itu dapat digunakan sebagai test driver.
Alat mungkin juga menguntungkan saat menjalankan tes (test harnesses dan test
sistem). Alat yang sederhana namun efektif adalah alat yang membandingkan hasil tes dengan
hasil yang diharapkan. Mata adalah media yang sangat tidak bisa diandalkan. Setelah waktu yang
singkat, semua hasil
terlihat baik-baik saja. Keuntungan tambahan dari jenis dukungan alat ini adalah membantu
mencapai format tes standar. Hal ini pada gilirannya membantu dengan pengujian regresi.
412 PENGUJIAN
PERANGKAT LUNAK
13.2.4 Pemeliharaan
Rata-rata, lebih dari 50% dari total biaya siklus hidup dihabiskan untuk
pemeliharaan. Jika kita memodifikasi perangkat lunak setelah sistem beroperasi
(karena kesalahan ditemukan belakangan, atau karena sistem harus diadaptasi
untuk mengubah persyaratan), kita harus menguji sistem lagi. Ini disebut pengujian
regresi. Agar ini berjalan lancar, kualitas dokumentasi dan kemungkinan dukungan
alat, merupakan faktor penting.
Di sebuah tes ulang-semua pendekatan, semua tes dijalankan kembali. Karena
ini mungkin menghabiskan banyak waktu dan tenaga, kami juga dapat memilih a tes
ulang selektif, di mana hanya beberapa tes yang dijalankan ulang. Teknik pemilihan
tes regresi kemudian digunakan untuk memutuskan subset mana yang harus
dijalankan. Kami ingin teknik ini menyertakan semua pengujian di mana program
yang dimodifikasi dan asli menghasilkan hasil yang berbeda, sambil menghilangkan
pengujian yang menghasilkan hasil yang sama.
13.2.5 Pengembangan Berbasis Tes (TDD)

Misalkan sistem perpustakaan kita harus bisa memblokir peminjaman barang
kepada anggota yang masuk daftar hitam. Kita bisa mulai dengan mendesain ulang
bagian dari sistem dan mengimplementasikan perubahan yang diperlukan: tabel
baru Daftar Hitam, dan metode pemeriksaan yang sesuaiMeminjam. Kami juga
harus memutuskan kapan anggota dimasukkan ke dalam daftar hitam, dan
bagaimana mengeluarkan mereka dari daftar itu. Setelah melakukan semua analisis
dan desain yang diperlukan, dan mengimplementasikan perubahan yang sesuai,
kami merancang kasus uji untuk menguji fungsionalitas baru.
Urutan peristiwa ini benar-benar terbalik pengembangan berbasis tes
(TDD).Dalam pengembangan berbasis pengujian, pertama-tama kami menulis
beberapa pengujian untuk fungsionalitas baru. Kami dapat memulai dengan sangat
sederhana, dan menambahkan tes dalam metode start-up untuk memastikan bahwa
daftar hitam pada awalnya kosong:
menegaskanEquals(0, Daftar Hitam)
Tentu saja, tes ini akan gagal. Untuk membuatnya berhasil, kita harus
memperkenalkan Daftar Hitam, dan atur sama dengan 0. Pada saat yang sama,
kami membuat daftar hal-hal yang masih harus dilakukan, seperti merancang jenis
yang tepat Daftar Hitam, termasuk operasi untuk menambah dan menghapus
anggota ke daftar itu, pembaruan dari Meminjam untuk memeriksa apakah orang
yang meminjam barang ada di daftar hitam, dan sejenisnya. Daftar hal-hal yang
harus dilakukan ini serupa dengan backlog yang digunakan oleh arsitek saat
merancang sistem (lihat bagian 11.2).
Setelah kami membuat tes sederhana untuk bekerja, versi baru dari sistem
diperiksa untuk melihat apakah dapat ditingkatkan. Dan selanjutnya perubahan kecil
lainnya sedang dipertimbangkan. Kita mungkin misalnya memutuskan untuk
membuat Daftar Hitam ke dalam daftar yang tepat, dan tulis beberapa tes
sederhana untuk melihat bahwa setelah menambahkan beberapa item ke daftar,
item tersebut memang ada dalam daftar. Sekali lagi, pengujian akan gagal, dan kami
memperbarui sistem sesuai dengan itu. Mungkin, perbaikan dapat dilakukan
sekarang karena sistem perpustakaan mungkin berisi kelas tipe daftar lain yang
dapat kami warisi, dan beberapa kode duplikat dapat dihapus. Dan seterusnya.
13.3. PERENCANAAN DAN DOKUMENTASI VERIFIKASI DAN VALIDASI413
Pengembangan berbasis tes adalah salah satu praktik Pemrograman eXtreme (lihat
bagian 3.2.4). Dengan demikian, itu adalah bagian dari pendekatan tangkas untuk pengembangan
sistem yang
mendukung peningkatan kecil dan mendesain ulang (refactoring) jika diperlukan daripada desain besar
upaya. Praktik ini biasanya didukung oleh kerangka pengujian unit otomatis,
seperti JUnit untuk Java, yang melacak set pengujian dan laporan kembali dapat dibaca
pesan kesalahan untuk tes yang gagal (Hunt dan Thomas, 2003). Itu menegaskan Sama
metode yang digunakan di atas adalah salah satu metode yang disediakan oleh framework JUnit. Itu
framework memungkinkan untuk integrasi pengkodean dan pengujian unit yang lancar. Dengan cepat, a
set pengujian dibangun yang membentuk aset yang dapat digunakan kembali selama evolusi lebih lanjut
dari sistem.
JUnit dan kerangka kerja serupa telah berkontribusi besar pada keberhasilan uji coba
perkembangan.
Cara kerja di setiap iterasi pengembangan berbasis tes terdiri dari
langkah-langkah berikut:
1. Tambahkan tes
2. Jalankan semua tes, dan amati bahwa yang ditambahkan akan gagal
3. Lakukan perubahan kecil pada sistem agar pengujian berhasil
4. Jalankan al tes lagi, dan amati apakah berjalan dengan baik
5. Refactor sistem untuk menghapus kode duplikat dan meningkatkan desainnya.
Dalam Pemrograman eXtreme murni, iterasi sangat kecil, dan mungkin memakan waktu beberapa menit
hingga, katakanlah, satu jam. Tetapi pengembangan yang digerakkan oleh tes juga dapat dilakukan
dengan lompatan yang lebih besar, dan
dikombinasikan dengan pendekatan yang lebih tradisional.
Pengembangan berbasis tes lebih dari sekadar metode pengujian. Ini adalah cara yang berbeda
mengembangkan perangkat lunak. Upaya dimasukkan ke dalam pengembangan dimuka kekuatan kasus
uji
satu untuk berpikir lebih hati-hati tentang apa artinya iterasi saat ini berhasil atau
gagal. Menulis kasus uji eksplisit memasukkan bagian dari pekerjaan analisis dan desain.
Daripada membuat diagram UML selama analisis kebutuhan, kami memproduksi
tes. Dan tes ini langsung digunakan, oleh orang yang sama yang mengimplementasikannya
fungsi yang latihan tes. Pengujian kemudian bukanlah renungan, tetapi menjadi
bagian integral dari proses pembangunan. Manfaat lain adalah bahwa kita memiliki tes
menetapkan dan kriteria uji untuk memutuskan keberhasilan iterasi. Eksperimen dengan
pengembangan berbasis tes menunjukkan bahwa itu meningkatkan produktivitas dan mengurangi cacat
tarif.
13.3 Verifikasi dan Validasi

Perencanaan dan
Dokumentasi
pemikiran
Seperti fase dan aktivitas lain dari proses pengembangan perangkat lunak, pengujian
kegiatan perlu direncanakan dan didokumentasikan dengan hati-hati. Sejak kegiatan ujian dimulai
di awal siklus hidup pengembangan dan menjangkau semua fase berikutnya,
perhatian tepat waktu terhadap perencanaan aktivitas ini adalah hal yang sangat
penting. Gambaran yang tepat dari berbagai kegiatan, tanggung jawab dan prosedur
harus disusun pada tahap awal.
Perencanaan kegiatan pengujian dijelaskan dalam dokumen yang disebut
Rencana Verifikasi dan Validasi Perangkat Lunak. Kami akan mendasarkan diskusi
kami tentang isinya pada Standar IEEE 1012 yang sesuai. Standar 1012
menjelaskan aktivitas verifikasi dan validasi untuk siklus hidup seperti air terjun di
mana fase-fase berikut diidentifikasi:
�
13.3. PERENCANAAN DAN DOKUMENTASI VERIFIKASI DAN VALIDASI415
1. Tujuan
2. Dokumen referensi
3. Definisi
4. Ikhtisar verifikasi dan validasi
4.1. Organisasi
4.2. Jadwal induk
4.3. Ringkasan sumber
daya
4.4. Tanggung jawab
4.5. Alat, teknik dan
metodologi
5. Verifikasi dan validasi siklus hidup (V&V)
5.1. Manajemen V&V
5.2. Persyaratan fase
V&V
5.3. Fase desain V&V
5.4. Fase implementasi
V&V
5.5. Fase uji V&V
5.6. Fase instalasi dan
checkout V&V
5.7. Fase operasi dan
pemeliharaan V&V
6. Pelaporan verifikasi dan validasi perangkat lunak
7. Prosedur administrasi verifikasi dan validasi
7.1. Pelaporan dan
resolusi anomali
7.2. Kebijakan iterasi
tugas
7.3. Kebijakan
penyimpangan
7.4. Prosedur kontrol
7.5. Standar, praktik, dan
konvensi
Gambar 13.6 p Rencana Verifikasi dan Validasi (Sumber: Standar IEEE untuk
Rencana Verifikasi dan Validasi Perangkat Lunak, Standar IEEE 1012, 1986. Direproduksi dengan izin
dari IEEE.)
urutan tindakan untuk pelaksanaan setiap tes. Bersama-sama, empat dokumen pertama
menggambarkan input untuk eksekusi tes.
Test Item Transmittal Report menentukan item mana yang akan diuji. Dia
mencantumkan item, menentukan di mana menemukannya, dan status setiap item. Itu membentuk
informasi rilis untuk eksekusi pengujian yang diberikan.
Tiga item terakhir adalah output dari pelaksanaan tes. Test Log memberi
catatan kronologis peristiwa. Test Incident Report mendokumentasikan semua kejadian
diamati yang memerlukan penyelidikan lebih lanjut. Secara khusus, ini termasuk tes yang
output tidak seperti yang diharapkan. Terakhir, Laporan Rangkuman Ujian memberikan ikhtisar
dan evaluasi temuan. Penjelasan rinci tentang isi dari berbagai ini
dokumen diberikan dalam Standar IEEE untuk Dokumentasi Perangkat Lunak (IEEE829,
1998).
Rencana Uji
Spesifikasi Desain Tes
Spesifikasi Kasus Uji
Spesifikasi Prosedur Uji
Laporan Pengiriman Butir Uji
Log Uji
Laporan Insiden Uji
Laporan Ringkasan Tes
Gambar 13.7 Konstituen utama dokumentasi pengujian, setelah (IEEE829, 1998)
13.4 Teknik Tes Manual

Banyak upaya penelitian dihabiskan untuk menemukan teknik dan alat untuk
mendukung pengujian. Namun, sejumlah besar teknik uji heuristik telah diterapkan
sejak awal era pemrograman. Teknik heuristik ini, seperti penelusuran dan inspeksi,
sering berhasil dengan baik, meskipun alasannya tidak selalu jelas.
Teknik tes dapat dipisahkan menjadi statis Dan dinamis teknik analisis. Selama
analisis dinamis, program dijalankan. Dengan bentuk pengujian ini, program diberi
beberapa masukan dan hasil eksekusinya dibandingkan dengan hasil yang
diharapkan. Selama analisis statis, perangkat lunak umumnya tidak dijalankan.
Banyak teknik uji statis juga dapat diterapkan pada artefak yang tidak dapat
dieksekusi seperti dokumen desain atau manual pengguna. Perlu dicatat, bahwa
batas antara analisis statis dan dinamis tidak terlalu tajam.
Sebagian besar analisis statis saat ini dilakukan oleh compiler bahasa. Compiler
kemudian memeriksa apakah semua variabel telah dideklarasikan, apakah setiap
pemanggilan metode memiliki jumlah parameter aktual yang tepat, dan seterusnya.
Kendala ini adalah bagian dari definisi bahasa. Kami juga dapat menerapkan
analisis teks program yang lebih ketat, seperti pemeriksaan untuk inisialisasi
variabel, atau pemeriksaan penggunaan konstruksi bahasa yang tidak standar, atau
rawan kesalahan. Dalam beberapa kasus, pemanggilan ke kompiler
diparameterisasi untuk menunjukkan pemeriksaan yang ingin dilakukan. Terkadang,
alat terpisah disediakan untuk pemeriksaan ini.
Teknik yang akan dibahas dalam subbagian berikut paling baik diklasifikasikan
sebagai teknik statis. Teknik untuk coverage-based, fault-based dan
error-basedtesting, yang akan dibahas pada bagian 13.5--13.7, sebagian besar
bersifat dinamis.
13.4. TEKNIK TES MANUAL 417
13.4.1 Membaca
Kita semua membaca, dan membaca ulang, dan membaca ulang, teks program kita. Ini adalah tes
paling tradisional
teknik yang kita ketahui. Ini juga merupakan teknik yang sangat berhasil untuk menemukan kesalahan
dalam suatu program
teks (atau spesifikasi, atau desain).
Secara umum, lebih baik meminta orang lain membaca teks Anda. Penulis sebuah
teks tahu betul apa yang seharusnya dilakukan oleh program (atau jenis dokumen lainnya).
mengangkut. Untuk alasan ini, penulis mungkin cenderung mengabaikan hal-hal yang menderita
semacam kebutaan perdagangan.
Alasan kedua mengapa membaca oleh penulis sendiri mungkin kurang bermanfaat adalah karena
sulit untuk mengadopsi sikap destruktif terhadap pekerjaan sendiri. Namun seperti itu
sikap diperlukan untuk keberhasilan pengujian.
Bentuk membaca program satu sama lain yang agak dilembagakan diketahui
sebagai tinjauan sejawat. Ini adalah teknik untuk menilai program secara anonim
kualitas, keterbacaan, kegunaan, dan sebagainya.
Setiap orang yang mengambil bagian dalam peer review diminta untuk menyerahkan dua program:
'terbaik'
program dan salah satu kualitas yang lebih rendah. Program-program ini kemudian didistribusikan
secara acak
diantara peserta. Setiap peserta menilai empat program: dua program 'terbaik'
dan dua program dengan kualitas lebih rendah. Setelah semua hasil dikumpulkan, masing-masing
peserta mendapatkan evaluasi (anonim) dari program mereka, serta
statistik dari seluruh tes.
Tujuan utama dari tes ini adalah untuk memberikan programmer wawasan sendiri
kemampuan. Praktik peer review menunjukkan bahwa programmer cukup mumpuni
menilai kualitas perangkat lunak rekan-rekan mereka.
Prasyarat yang diperlukan untuk berhasil membaca kode orang lain adalah bisnis-
seperti sikap. Weinberg (1971) menciptakan istilah tersebut pemrograman tanpa ego untuk ini. Banyak
programmer melihat kode mereka sebagai sesuatu yang pribadi, seperti buku harian. Komentar
menghina
('bagaimana Anda bisa begitu bodoh untuk melupakan inisialisasi itu') dapat merusak
efektivitas penilaian tersebut. Peluang untuk sikap antisosial seperti itu
terjadi tampaknya agak lebih kecil dengan teknik manual yang lebih formal.
13.4.2 Walkthrough dan Inspeksi

Panduan dan inspeksi keduanya adalah teknik manual yang muncul dari
meja-memeriksa kode program tradisional. Dalam kedua kasus itu menyangkut kerja sama tim,
dimana produk yang akan diperiksa dievaluasi dalam sesi formal, berikut
prosedur yang tepat.
Inspeksi terkadang disebut Inspeksi Fagan, setelah pencetusnya (Fagan,
1976, 1986). Dalam inspeksi, kode yang akan dinilai melalui pernyataan
oleh pernyataan. Anggota tim inspeksi (biasanya empat) mendapatkan kodenya
spesifikasi, dan dokumen terkait beberapa hari sebelum sesi berlangsung.
Setiap anggota tim inspeksi memiliki peran yang jelas. Itu moderator adalah
bertanggung jawab atas penyelenggaraan rapat inspeksi. Dia memimpin rapat
dan memastikan bahwa tindak lanjut yang disepakati selama pertemuan memang benar
dilakukan. Moderator harus memastikan bahwa rapat dilakukan dengan cara bisnis
yang konstruktif dan bahwa peserta mengikuti prosedur yang benar dan bertindak
sebagai tim. Tim biasanya memiliki dua inspektur atau pembaca, rekan-rekan
berpengetahuan yang memparafrasekan kode. Akhirnya, pembuat kode adalah
pengamat yang sebagian besar diam. Dia tahu kode yang harus diperiksa dengan
sangat baik dan dengan mudah cenderung mengungkapkan apa yang dia
maksudkan daripada apa yang sebenarnya ditulis. Namun, dia mungkin dimintai
pendapat oleh para inspektur.
Selama sesi formal, inspektur memparafrasakan kode, biasanya beberapa baris
sekaligus. Mereka mengungkapkan makna teks pada tingkat abstraksi yang lebih
tinggi daripada apa yang sebenarnya ditulis. Hal ini menimbulkan pertanyaan dan
diskusi yang dapat mengarah pada penemuan kesalahan. Pada saat yang sama,
kode tersebut dianalisis menggunakan daftar kesalahan yang sering terjadi. Contoh
entri yang mungkin dalam daftar periksa ini adalah:
– penggunaan data yang salah: variabel tidak diinisialisasi, indeks array di luar
batas,penunjuk yang menggantung, dll.;
– kesalahan dalam deklarasi: penggunaan variabel yang tidak dideklarasikan

atau deklarasi nama yang sama di blok bersarang, dll.;
– kesalahan dalam perhitungan: pembagian dengan nol, luapan (mungkin juga

dalam hasil antara), kesalahan penggunaan variabel dari tipe yang berbeda
dalam ekspresi yang sama, kesalahan yang disebabkan oleh pemahaman yang
salah tentang prioritas operator, dll.;
– kesalahan dalam ekspresi relasional: menggunakan operator yang salah ( >

Dalam penelusuran, tim dipandu melalui kode menggunakan data uji. Tes ini
data sebagian besar dari jenis yang cukup sederhana. Jika tidak, segera telusuri logika program
menjadi terlalu rumit. Data uji lebih berfungsi sebagai sarana untuk memulai diskusi
daripada sebagai ujian serius dari program. Dalam setiap langkah dari proses ini, perancang dapat
dipertanyakan tentang alasan keputusan tersebut. Dalam banyak kasus, panduan
bermuara pada semacam simulasi manual.
Baik penelusuran dan inspeksi dapat diterapkan secara menguntungkan pada semua tahap
siklus hidup perangkat lunak. Satu-satunya prasyarat adalah adanya dokumen yang jelas dan dapat
diuji.
Diperkirakan metode peninjauan ini mendeteksi 50 hingga 90% cacat (Boehm dan
Basili, 2001). Kedua teknik tersebut tidak hanya berfungsi untuk mencari kesalahan. Jika diterapkan
dengan benar, ini
teknik dapat membantu untuk mempromosikan semangat tim dan moral. Pada tingkat teknis, the
orang yang terlibat dapat belajar dari satu sama lain dan memperkaya pengetahuan mereka tentang
algoritma,
gaya pemrograman, teknik pemrograman, konstruksi rawan kesalahan, dan sebagainya.
Dengan demikian, teknik ini juga berfungsi sebagai kendaraan untuk perbaikan proses. Di bawah
payung umum 'peer review', mereka adalah bagian dari area proses kunci level 3 CMM
Verifikasi (lihat bagian 6.6).
Bahaya potensial dari jenis ulasan ini adalah bahwa ulasan tersebut masih terlalu dangkal. Itu
orang yang terlibat menjadi kewalahan dengan informasi, mereka mungkin tidak cukup
pengetahuan tentang domain masalah, tanggung jawab mereka mungkin belum jelas
digambarkan. Akibatnya, proses peninjauan tidak membuahkan hasil yang memadai.
Parnas dan Weiss (1987) menjelaskan jenis proses peninjauan di mana orang-orang
terlibat harus berperan lebih aktif. Parnas membedakan antara berbagai jenis
tinjauan desain khusus. Masing-masing ulasan ini berkonsentrasi pada keinginan tertentu
sifat dari desain. Konsekuensinya, tanggung jawab orang-orang yang terlibat
jelas. Peninjau harus menjawab daftar pertanyaan ('dalam kondisi apa
semoga fungsi ini disebut ',' apa efek dari fungsi ini pada perilaku
fungsi lain, dan sejenisnya). Dengan cara ini, peninjau dipaksa untuk belajar dengan hati-hati
informasi desain yang diterima. Masalah dengan kuesioner dan dokumentasi
dapat diajukan ke desainer, dan kuesioner yang telah diisi didiskusikan oleh
desainer dan reviewer. Eksperimen menunjukkan bahwa inspeksi dengan tinjauan khusus
peran lebih efektif daripada inspeksi di mana peran review tidak terspesialisasi.
Komponen yang sangat penting dari inspeksi Fagan adalah pertemuan di mana
dokumen dibahas. Karena pertemuan dapat menimbulkan biaya atau jeda waktu yang cukup besar,
seseorang dapat mencoba melakukannya tanpa mereka. Eksperimen menunjukkan bahwa nilai tambah
kelompok
pertemuan, sejauh menyangkut jumlah masalah yang teridentifikasi, cukup kecil.
13.4.3 Bukti Kebenaran

Teknik analisis statis yang paling lengkap adalah pembuktian kebenarannya.
Sebagai bukti kebenaran, kami mencoba membuktikan bahwa suatu program
memenuhi spesifikasinya. Untuk dapat melakukannya, spesifikasi harus dinyatakan
secara formal. Kami kebanyakan melakukan ini dengan mengungkapkan spesifikasi
dalam dua pernyataan yang masing-masing berlaku sebelum dan sesudah eksekusi
program. Selanjutnya, kami membuktikan bahwa program berubah
satu pernyataan (prekondisi) ke yang lain (kondisi akhir). Ini umumnya
dilambangkan sebagai
F
1 prosedur binsearch
2 (A: Himpunan [1..n] dari bilangan bulat; x: bilangan
bulat): bilangan bulat;
3 dulu rendah, tinggi, sedang: bilangan bulat; ditemukan:
boolean;
4 mulai rendah:= 1; tinggi:= n; ditemukan:= salah;
5 ketika (rendah
�
422 PENGUJIAN PERANGKAT
LUNAK
13.5 Teknik Tes Berbasis
Cakupan
Pertanyaan: Apa yang Anda lakukan ketika Anda melihat grafik?
Jawab: Tutupi!
(Beizer, 1995)
Dalam teknik coverage-based test, kecukupan pengujian dinyatakan dalam cakupan produk
yang akan diuji, misalnya persentase pernyataan yang dieksekusi atau persentase persyaratan
fungsional yang diuji.
Pengujian berbasis cakupan seringkali didasarkan pada jumlah instruksi, cabang, atau jalur
yang dikunjungi selama eksekusi suatu program. Sangat membantu untuk mendasarkan diskusi
tentang jenis pengujian berbasis cakupan ini pada gagasan tentang grafik kontrol. Dalam grafik
kontrol ini, simpul menunjukkan tindakan, sedangkan tepi (diarahkan) menghubungkan tindakan
dengan tindakan selanjutnya (dalam waktu). Path adalah urutan node yang dihubungkan oleh
edge.
Grafik mungkin berisi siklus, yaitu P
jalur
13.5. TEKNIK UJI BERBASIS CAKUPAN 4
2
1 prosedur gelembung 3
2 (dulu A: Himpunan [1..n] dari bilangan bulat; n:
bilangan bulat);
3 dulu i, j, temp: bilangan bulat;
4 mulai
6 jika a[i]
�
akan melakukan. Kemungkinan kombinasi lain dari nilai kebenaran predikat atom
(Saya = 1,J = 0 dan Saya = 0, J = 0) tidak perlu dipertimbangkan untuk mencapai
cakupan cabang. Cakupan berbagai kondisi mensyaratkan bahwa semua
kemungkinan kombinasi predikat elementer dalam kondisi dicakup oleh perangkat
uji. Kriteria ini disebut juga dengan cakupan cabang yang diperluas.
Terakhir, metrik kompleksitas siklomatik McCabe (McCabe, 1976) juga telah
diterapkan pada pengujian. Kriteria ini juga didasarkan pada representasi grafik
kontrol dari suatu program.
Himpunan basis adalah himpunan jalur bebas linier maksimal melalui grafik.
Kompleksitas siklomatis (
CV
13.5. TEKNIK UJI BERBASIS CAKUPAN 425
Sebagai contoh, perhatikan teks program pada gambar 13.10. Grafik kontrol yang
sesuai diberikan pada gambar 13.11. Untuk grafik ini,
Dia
dalam pernyataan selanjutnya. Definisi dalam pernyataan X adalah hidup dalam

pernyataan Y jika ada jalur dari X ke Y di mana variabel tersebut tidak diberi nilai
baru di beberapa node perantara. Pada contoh pada gambar 13.9, misalnya, definisi
dariJ di baris 7 masih hidup di baris 13 tetapi tidak di baris 14. Jalur seperti yang dari
baris 7 ke 13 disebut definisi-jelas (dengan hormat J). Algoritma untuk menentukan
fakta seperti itu biasanya digunakan dalam kompiler untuk mengalokasikan variabel
secara optimal ke register mesin.
Kami membedakan antara dua jenis penggunaan variabel: P-penggunaan Dan
C-menggunakan. Penggunaan P adalah penggunaan predikat, seperti yang ada di
bagian kondisional dari pernyataan if. Semua penggunaan lainnya adalah
penggunaan C. Contoh yang terakhir digunakan dalam perhitungan atau pernyataan
I/O.
Strategi pengujian yang mungkin adalah membangun pengujian yang melintasi
jalur yang jelas definisi antara setiap definisi variabel untuk setiap (P- atau C-)
penggunaan definisi tersebut dan setiap penerus penggunaan tersebut. (Kita harus
menyertakan setiap penerus penggunaan untuk memaksa semua cabang yang
mengikuti penggunaan-P diambil.) Kita kemudian yakin bahwa setiap kemungkinan
penggunaan definisi sedang diuji. Strategi ini dikenal dengan Cakupan Semua
Penggunaan. Kriteria yang sedikit lebih kuat mensyaratkan bahwa setiap jalur yang
jelas definisi bebas siklus atau siklus sederhana. Ini dikenal sebagai All-YOU-Paths
cakupan. Beberapa kriteria aliran data yang lebih lemah dapat didefinisikan juga:
– Cakupan semua def hanya membutuhkan set tes sedemikian rupa sehingga
setiap definisi digunakan setidaknya sekali.
– Cakupan All-C-uses/Some-P-uses membutuhkan jalur yang jelas definisi dari

setiap definisi ke setiap penggunaan komputasi. Jika definisi hanya digunakan
dalam predikat, setidaknya satu jalur yang jelas untuk penggunaan predikat
harus dilakukan.
– Cakupan All-P-Uses/Some-C-uses membutuhkan jalur yang jelas definisi

dari setiap definisi ke setiap penggunaan predikat. Jika definisi hanya digunakan
dalam perhitungan, setidaknya satu jalur yang jelas definisi untuk penggunaan
komputasi harus dilakukan.
– Cakupan All-P-Uses membutuhkan jalur definisi-jelas dari setiap definisi ke

setiap penggunaan predikat.
13.5.3 Pengujian Persyaratan Berbasis

Cakupan
Kode program dapat dengan mudah diubah menjadi model grafik, sehingga
memungkinkan untuk semua jenis kriteria kecukupan pengujian berdasarkan grafik.
Spesifikasi kebutuhan, bagaimanapun, juga dapat diubah menjadi model grafik.
Akibatnya, berbagai kriteria kecukupan berbasis cakupan dapat digunakan dalam
teknik pengujian kotak hitam dan kotak putih. Perhatikan contoh fragmen dokumen
spesifikasi kebutuhan untuk sistem perpustakaan kita pada gambar 13.12. Kami
dapat mengubah persyaratan ini sedikit dan menyajikannya dalam bentuk
persyaratan dasar dan hubungan di antara mereka. Hasilnya dapat digambarkan
sebagai grafik, di mana node menunjukkan persyaratan dasar dan tepi menunjukkan
hubungan antara persyaratan dasar; lihat gambar 13.13. Kita boleh
13.6. TEKNIK UJI BERBASIS KESALAHAN 427
gunakan model grafik ini untuk mendapatkan kasus uji dan menerapkan salah satu cakupan aliran
kontrol
kriteria untuk menilai kecukupannya.
Fungsi Memesan memungkinkan pengguna untuk memesan buku baru. Pengguna ditampilkan
mengisi-in-the-
layar kosong dengan bidang seperti Pengarang, Judul, Penerbit, Harga Dan Departemen. Itu
Judul, Harga Dan Departemen bidang adalah wajib. Itu Departemen lapangan digunakan
untuk memeriksa apakah anggaran departemen cukup besar untuk membeli buku ini. Jika
jadi, buku itu dipesan dan
anggaran departemen dikurangi sesuai dengan itu.
Gambar 13.12 Fragmen spesifikasi persyaratan
Rute yang sangat mirip dapat diikuti jika persyaratan dinyatakan dalam bentuk
kasus penggunaan. Gambar 13.14 memberikan kemungkinan penulisan ulang fragmen dari gambar
13.12.
Ini menggunakan format dari (Cockburn, 2001). Kasus penggunaan menggambarkan keduanya normal
kasus, yang disebut Skenario Sukses Utama, serta ekstensi yang mencakup situasi
yang bercabang dari jalur normal karena beberapa kondisi. Untuk setiap ekstensi,
kondisi dan langkah-langkah yang diambil dicantumkan. Perhatikan gambar 13.13 secara langsung
meniru deskripsi use case dari 13.14. Deskripsi use case juga memungkinkan kita
untuk secara langsung menurunkan kasus uji dan menerapkan kriteria cakupan aliran kontrol.
Secara umum, masalah utama dalam menentukan satu set kasus uji adalah
mempartisi domain program menjadi sejumlah (kecil) kelas kesetaraan. Kami mencoba untuk
lakukan sedemikian rupa sehingga menguji elemen representatif dari kelas sudah cukup untuk
seluruh kelas. Menggunakan kriteria cakupan aliran kontrol, misalnya, kami berasumsi bahwa ada
tes beberapa node atau cabang sama baiknya dengan tes lainnya. Dalam contoh di atas,
misalnya, kita berasumsi bahwa setiap eksekusi node berlabel 'check dept. anggaran'
akan melakukan.
Titik lemah dalam prosedur ini adalah asumsi yang mendasari program tersebut
berperilaku sama pada semua data dari kelas tertentu. Jika asumsi tersebut benar, maka
partisi sempurna dan begitu juga dengan set pengujian.
Akan tetapi asumsi tersebut pada umumnya tidak berlaku (lihat juga bagian 13.1.2).
13.6 Teknik Tes Berbasis

Kesalahan
Dalam teknik pengujian berbasis cakupan, kami mempertimbangkan struktur masalah atau
solusinya, dan asumsinya adalah bahwa cakupan yang lebih komprehensif lebih baik.
Dalam strategi pengujian berbasis kesalahan, kami tidak melakukannya secara langsung pertimbangkan
artefak yang sedang diuji
ketika menilai kecukupan tes. Kami hanya memperhitungkan set tes. Berbasis kesalahan
teknik ditujukan untuk menemukan set tes dengan kemampuan tinggi untuk mendeteksi kesalahan.
Kami akan membahas dua teknik pengujian berbasis kesalahan: penyemaian kesalahan dan mutasi
pengujian.
Gambar 13.13 Grafik model fragmen spesifikasi kebutuhan
13.6.1 Pembibitan Kesalahan

Buku teks tentang statistik sering berisi contoh seperti berikut: jika kita ingin
memperkirakan jumlah tombak di Danau Soft, kita lakukan sebagai berikut:
1. Tangkap sejumlah tombak, N

Kasus Penggunaan: Pesan Buku baru
Aktor Utama: pengguna perpustakaan

Cakupan: Perpustakaan
Tingkat: Tujuan pengguna
Pemangku Kepentingan dan Kepentingan:
Pengguna --- ingin mendapatkan buku baru
Departemen --- ingin menjaga anggarannya
Prasyarat: Pengguna masuk
Jaminan Minimal: ID pengguna telah divalidasi
Jaminan Sukses: Pesanan diterima
Skenario Sukses Utama:
1. Pengguna mengisi formulir
2. Informasi buku dicek
3. Anggaran departemen diperiksa
4. Pesanan ditempatkan
5. Pengguna diberitahu tentang pesanan yang dilakukan
Ekstensi:
2a. Informasi buku tidak valid
2a1. Pengguna diminta untuk memperbaiki informasi
3a. Anggaran departemen tidak memadai
3a1. Pesanan ditolak, pengguna diberitahu
Gambar 13.14 Kebutuhan dalam bentuk use case
Andaikan itu M
Teknik lain adalah membuat program diuji secara independen oleh dua
kelompok. Kesalahan yang ditemukan oleh kelompok pertama kemudian dapat
dianggap sebagai kesalahan unggulan untuk kelompok kedua. Namun, dalam
menggunakan teknik ini, kita harus menyadari bahwa ada kemungkinan bahwa
kedua kelompok akan mendeteksi kesalahan sederhana (jenis yang sama).
Akibatnya, gambar mungkin terdistorsi.
Aturan praktis yang berguna untuk teknik ini adalah sebagai berikut: jika kita
menemukan banyak kesalahan yang diunggulkan dan yang lainnya relatif sedikit,
hasilnya dapat dipercaya. Sebaliknya tidak benar. Fenomena ini berlaku lebih
umum: jika, selama pengujian komponen tertentu, banyak kesalahan ditemukan, ini
tidak boleh dianggap sebagai tanda positif. Justru sebaliknya, ini merupakan indikasi
bahwa komponen tersebut mungkin berkualitas rendah. Seperti yang diamati Myers:
'Kemungkinan adanya lebih banyak kesalahan dalam suatu bagian dari suatu
program sebanding dengan jumlah kesalahan yang sudah ditemukan di bagian itu.'
(Myers, 1979). Fenomena yang sama telah diamati dalam beberapa percobaan, di
mana kuat hubungan linier ditemukan antara jumlah cacat yang ditemukan selama
fase awal pengembangan dan jumlah cacat yang ditemukan kemudian.
13.6.2 Pengujian Mutasi

Misalkan kita memiliki beberapa program P
Ganti konstanta dengan konstanta lain

Mengganti variabel dengan variabel lain
Ganti konstanta dengan variabel
Ganti operator aritmatika dengan operator aritmatika lain
Ganti operator logika dengan operator logika lain
Masukkan operator unary
Hapus pernyataan
Gambar 13.15 Contoh operator mutasi
Ada dua varian utama dari pengujian mutasi: pengujian mutasi yang kuat Dan
pengujian mutasi lemah. Misalkan kita punya
P
program
2
13.7 Teknik Pengujian Berbasis Kesalahan

Misalkan sistem perpustakaan kita menyimpan daftar buku 'panas'. Setiap buku yang baru
diperoleh secara otomatis ditambahkan ke daftar. Setelah enam bulan, itu dihapus lagi. Juga,
jika sebuah buku lebih dari empat bulan dan dipinjam kurang dari lima kali sebulan atau lebih
dari dua bulan dan dipinjam paling banyak dua kali sebulan, itu dihapus dari daftar.
Persyaratan yang agak rumit ini dapat digambarkan secara grafis seperti pada gambar
13.16. Hal ini menunjukkan bahwa domain dua dimensi (usia, rata-rata jumlah pinjaman) dapat
dipartisi menjadi empat subdomain. Subdomain ini berhubungan langsung dengan persyaratan
sebagai
disebutkan di atas. Subdomain dipisahkan oleh batas seperti usia
garis
13.8. PERBANDINGAN TEKNIK PENGUJIAN 433
Salah satu strategi pengujian tersebut berkonsentrasi pada poin ON dan OFF. Titik ON adalah
titik di perbatasan subdomain. Jika subdomain terbuka sehubungan dengan suatu
perbatasan, maka titik OFF perbatasan adalah titik tepat di dalam perbatasan itu. Jika
subdomain ditutup sehubungan dengan beberapa perbatasan, maka titik OFF terletak tepat di
luar perbatasan itu. Dua subdomain yang berdekatan berbagi titik ON yang sama; mereka
mungkin berbagi OFF yang sama
titik. Pada gambar 13.16, lingkaran padat di garisusia
– Beberapa kesalahan unggulan ditemukan dengan cepat, beberapa
memerlukan beberapa pengujian, dan beberapa tetap tidak terdeteksi bahkan
setelah 25.000 pengujian. Pola ini ditemukan pada masing-masing dari 17
program;
– Dalam beberapa kasus, program asli gagal, sedangkan program yang

dimodifikasi menghasilkan hasil yang tepat.
Di masa lalu, beberapa upaya telah dilakukan untuk mendapatkan lebih banyak
wawasan tentang aspek teoretis dari teknik pengujian. Contohnya adalah penelitian
yang bertujuan untuk menghubungkan kriteria kecukupan tes yang berbeda. Kriteria
kecukupan tes berfungsi sebagai aturan yang digunakan untuk menentukan apakah
pengujian dapat dihentikan atau tidak. Isu penting kemudian adalah untuk
memutuskan apakah salah satu kriteria tersebut adalah 'lebih baik' dari yang lain.
Pada bagian 13.8.1, kami membandingkan kekuatan sejumlah kriteria kecukupan
pengujian yang dibahas pada bagian sebelumnya. Pada bagian 13.8.2 kami
menyelidiki sejumlah sifat mendasar dari kriteria kecukupan pengujian. Jenis
penelitian ini bertujuan untuk mendapatkan wawasan yang lebih dalam tentang
sifat-sifat teknik pengujian yang berbeda.
Beberapa percobaan telah dilakukan untuk membandingkan teknik pengujian
yang berbeda. Data nyata dari sejumlah proyek juga tersedia pada kemampuan
deteksi kesalahan dari teknik pengujian yang digunakan dalam proyek tersebut.
Pada bagian 13.8.3 kami membahas beberapa temuan ini yang dapat memberikan
beberapa wawasan praktis tentang keunggulan sejumlah teknik pengujian.
13.8.1 Perbandingan Kriteria Kecukupan Tes

Sebuah pertanyaan yang mungkin diajukan adalah apakah, katakanlah, kriteria
kecukupan All-Uses lebih kuat atau lebih lemah daripada kriteria kecukupan
All-Nodes atau All-Edges. Kami dapat mendefinisikan gagasan 'lebih kuat' sebagai
berikut: kriteria X lebih kuat dari kriteria Y jika, untuk semua program P dan semua
set tes T, kecukupan X mengimplikasikan kecukupan Y. Dalam literatur pengujian
hubungan ini dikenal sebagai 'subsume'. Dalam pengertian ini, kriteria All-Edges
lebih kuat dari (mengelompokkan) kriteria All-Nodes. Kriteria All-Uses,
bagaimanapun, tidak lebih kuat dari kriteria All-Nodes. Hal ini disebabkan oleh fakta
bahwa program mungkin berisi pernyataan yang hanya mengacu pada konstanta.
Untuk programnya
jika A <
jika BENAR
Kemudian x:= 1
kalau tidak x:= 2
Cabang-else tidak pernah dieksekusi, namun sebagian besar kriteria kecukupan mengharuskan cabang
ini
diambil. Jalur yang tidak layak juga dihasilkan dari perulangan. Jika sebuah loop berbentuk
untuk Saya dari 1 ke 10 Mengerjakan

tubuh
tidak akan ada jalur layak yang melintasi siklus yang dihasilkan dalam grafik yang lain
dari sepuluh kali.
Tidak ada skala linier sederhana yang menjadi kekuatan semua
kriteria kecukupan berbasis program dapat digambarkan. Untuk kriteria yang dibahas di
bagian 13.5--13.7, hierarki subsum digambarkan pada gambar 13.17, sejauh ini
diketahui. Sebuah anak panah A !
Gambar 13.17 Subsume hirarki untuk kriteria kecukupan berbasis program

�
�
Basili dan Selby membandingkan keefektifan teknik ini dalam mendeteksi
kesalahan, biaya terkait, dan jenis kesalahan yang ditemukan. Beberapa hasil dari
percobaan ini adalah:
�
Hasilnya menjadi jauh lebih miring jika kita memperhitungkan keefektifan biaya dari
berbagai teknik pengujian. Metrik efektivitas biaya yang digunakan adalah rasio
'biaya yang dihemat oleh proses' terhadap 'biaya yang dikonsumsi oleh proses'.
Biaya yang dihemat oleh proses adalah biaya yang akan dikeluarkan jika proses
tidak dilakukan dan kesalahan harus diperbaiki kemudian. Hasil efektivitas biaya
yang ditemukan dalam penelitian ini diberikan pada Gambar 13.19. Hasil ini
menunjukkan bahwa, untuk setiap jam yang dihabiskan dalam tinjauan desain dan
memperbaiki kesalahan desain, lebih dari delapan jam kerja dapat dihemat.
Keefektifan biaya dari tahap pengujian itu sendiri sangat rendah. Hal ini tidak
mengherankan, karena banyak waktu yang terbuang selama tahap pengujian yang
sebenarnya dalam melakukan pengujian yang tidak menunjukkan adanya
kesalahan. Temuan ini sekali lagi mengkonfirmasi pernyataan bahwa pengujian awal
benar-benar membuahkan hasil.
% kesalahan % dari kesalahan Gabungan

desain pengkodean
ditemuka ditemukan efisiensi
n
Tinjauan desain
54 -- 54
Tinjauan kode 33 84 64
Peng 38 38 38
ujian
Gambar 13.18 Efisiensi deteksi kesalahan
Tinjauan desain Tinjauan kode Pengujian
8.44 1.38 0,17
Gambar 13.19 Hasil efektivitas biaya ditemukan di (Collofello dan Woodfield, 1989)
13.9 Tahapan Tes yang Berbeda

Selama tahap desain, sistem yang akan dibangun telah didekomposisi menjadi
komponen-komponen. Umumnya, komponen-komponen ini membentuk beberapa
struktur hierarkis. Selama pengujian, kita sering membiarkan diri kita dipimpin oleh
struktur ini. Kami tidak segera mulai menguji sistem secara keseluruhan tetapi mulai
dengan menguji masing-masing komponen (disebut satuan
13.9. TAHAP UJI YANG BERBEDA 441
pengujian). Selanjutnya, komponen-komponen ini secara bertahap diintegrasikan ke dalam suatu
sistem. Pengujian
komposisi komponen disebut tes integrasi.
Dalam melakukan ini, kita dapat mengambil salah satu dari dua pendekatan. Pada pendekatan
pertama, kami
mulailah dengan menguji komponen tingkat rendah yang kemudian diintegrasikan dan digabungkan
dengan komponen pada tingkat berikutnya yang lebih tinggi. Subsistem yang diperoleh diuji
Berikutnya. Kemudian secara bertahap kami bergerak menuju komponen tingkat tertinggi. Ini diketahui
sebagai pengujian bottom-up. Pendekatan alternatif adalah pengujian top-down. Secara top-down
pengujian, komponen tingkat atas diuji terlebih dahulu dan secara bertahap diintegrasikan dengan
komponen tingkat rendah.
Dalam pengujian bottom-up, kita sering kali harus mensimulasikan lingkungan tempat
komponen yang diuji akan diintegrasikan. Ini lingkungan disebut tes
pengemudi. Dalam pengujian top-down, kebalikannya benar: kita harus mensimulasikan level yang lebih
rendah
komponen, melalui apa yang disebut bertopik uji.
Kedua metode memiliki kelebihan dan kekurangan. Misalnya, secara bottom-up
pengujian mungkin sulit untuk mendapatkan kesan suara dari sistem akhir selama awal
tahapan pengujian karena sementara komponen tingkat atas tidak terintegrasi, ada
tidak ada sistem, hanya sepotong-sepotong. Sebaliknya, dengan pengujian top-down, menulis
bertopik bisa agak melelahkan. Jika strategi implementasi adalah salah satu dimana a
sistem kerangka dibangun terlebih dahulu dan kemudian diisi dengan komponen, sistem kerangka ini
dapat digunakan sebagai test driver dan test order kemudian menjadi masalah yang jauh lebih sedikit.
Dalam praktiknya, seringkali berguna untuk menggabungkan kedua metode tersebut. Itu belum tentu
kasus bahwa beberapa teknik desain atau implementasi tertentu mendorong kita dalam memilih
teknik tes tertentu. Jika pengujian sebagian paralel dengan implementasi,
kendala pemesanan yang disebabkan oleh urutan implementasi harus dipatuhi,
meskipun.
Kriteria kecukupan berbasis program menggunakan model bahasa yang mendasarinya.
Perbedaan halus dalam model yang mendasari ini dapat menyebabkan perbedaan halus dalam
grafik aliran yang dihasilkan seperti yang digunakan dalam kriteria berbasis cakupan, misalnya. Dengan
kasar
berbicara, hasil yang dilaporkan bertahan pada tingkat prosedur atau subrutin di
bahasa seperti FORTRAN, Pascal, dan sebagainya.
Akibatnya, teknik tes yang sesuai berlaku di tingkat individu.
metode vidual dalam program berorientasi objek. Menguji komponen OO yang lebih besar
program, seperti kelas berparameter atau kelas yang mewarisi bagian fungsional-
ity dari kelas lain, menyerupai pengujian regresi seperti yang dilakukan selama pemeliharaan. Kami
kemudian harus memutuskan berapa banyak pengujian ulang yang harus dilakukan jika metode
didefinisikan ulang
subkelas, atau kelas dibuat dengan tipe lain sebagai parameter.
Ada bentuk pengujian lain selain pengujian unit dan pengujian integrasi. Satu
kemungkinan adalah untuk menguji keseluruhan sistem terhadap dokumentasi dan persyaratan
pengguna
spesifikasi setelah pengujian integrasi selesai. Ini disebut uji sistem. A
jenis pengujian serupa sering dilakukan di bawah pengawasan organisasi pengguna
dan kemudian dipanggil ujian penerimaan. Selama pengujian penerimaan, penekanannya adalah pada
menguji kegunaan sistem, daripada kepatuhan kode terhadap beberapa
spesifikasi. Pengujian penerimaan adalah kriteria utama yang menjadi dasar keputusan untuk
menerima atau menolak suatu sistem didasarkan. Untuk memastikan pengiriman
yang tepat dari semua artefak yang diperlukan dari proyek pengembangan
perangkat lunak, adalah berguna untuk membiarkan organisasi pemeliharaan masa
depan memiliki hak veto dalam proses pengujian penerimaan.
Jika sistem harus beroperasi di lingkungan yang berbeda dari yang telah
dikembangkan, maka terpisah tes instalasi biasanya dilakukan.Teknik pengujian
yang dibahas di bagian sebelumnya sering diterapkan selama pengujian unit dan
integrasi. Saat menguji sistem secara keseluruhan, pengujian sering menggunakan
input acak, meskipun input dipilih sedemikian rupa sehingga mewakili penggunaan
operasional sistem. Tes semacam itu juga dapat digunakan untuk menilai keandalan
sistem secara kuantitatif. Keandalan perangkat lunak adalah topik dari bagian 13.10.
Penggunaan input acak sebagai data uji terbukti berhasil dalam metode
Cleanroom development. Dalam beberapa percobaan, ditemukan bahwa pengujian
terpilih menghasilkan tingkat pernyataan dan cakupan cabang yang tinggi. Jika
sebuah cabang tidak dieksekusi, hal itu sering menyangkut penanganan kasus luar
biasa.
13.10 Memperkirakan Keandalan

Perangkat Lunak
Dalam sebagian besar buku ini, pembaca akan menemukan referensi tentang fakta
bahwa sebagian besar perangkat lunak tidak berfungsi dengan sempurna.
Kesalahan ditemukan di hampir setiap sistem perangkat lunak run-of-the-mill:
perangkat lunak tidak dapat diandalkan 100%. Pada bagian ini kami berkonsentrasi
pada pengertian kuantitatif, statistik, tentang keandalan perangkat lunak.
Salah satu manfaat dari informasi tersebut adalah dapat digunakan dalam
merencanakan upaya pemeliharaan kita. Alasan lain untuk mengumpulkan informasi
reliabilitas dapat berupa kewajiban kontrak mengenai tingkat reliabilitas yang
disyaratkan. Perangkat lunak untuk sistem peralihan telepon, misalnya,
membutuhkan pengetahuan kuantitatif tentang ketersediaan sistem yang
diharapkan. Kita perlu mengetahui kemungkinan koneksi yang salah karena
kesalahan pada perangkat lunak.
Aplikasi kedua dari data reliabilitas ditemukan dalam pengujian. Masalah utama
dengan pengujian adalah memutuskan kapan harus berhenti. Satu kemungkinan
adalah mendasarkan keputusan ini pada pencapaian tingkat keandalan tertentu.
Jika tingkat keandalan yang dibutuhkan tidak tercapai, kita perlu memperkirakan
waktu yang diperlukan untuk mencapai tingkat tersebut.
Untuk dapat menjawab jenis pertanyaan ini, sejumlah model keandalan
perangkat lunak telah dikembangkan yang sangat mirip dengan model keandalan
perangkat keras yang terkenal. Ini adalah model statistik di mana titik awalnya
adalah distribusi probabilitas tertentu untuk kegagalan yang diharapkan. Distribusi
yang tepat tidak diketahui secara apriori. Kita harus mengukur titik waktu di mana
yang pertama N
13.10. MEMPERKIRAKAN KEANDALAN 443
PERANGKAT LUNAK
gagal jika output tidak memenuhi spesifikasi. Kesalahan dalam suatu program bersifat statis
sifatnya, kegagalan bersifat dinamis. Sebuah program bisa gagal hanya ketika dijalankan. Dari
sudut pandang pengguna, kegagalan jauh lebih penting daripada kesalahan. Misalnya kesalahan
dalam perangkat lunak yang tidak pernah, atau hampir tidak pernah, digunakan, secara umum, kurang
penting
dari kesalahan yang memanifestasikan dirinya sering. Juga, satu dan kesalahan yang sama mungkin
muncul
dengan cara yang berbeda dan kegagalan dapat disebabkan oleh lebih dari satu kesalahan.
Dalam pembahasan berikut tentang keandalan, kami tidak akan peduli dengan
jumlah kesalahan yang diharapkan dalam suatu program. Sebaliknya, penekanannya akan pada yang
diharapkan
jumlah kegagalan. Gagasan waktu memainkan peran penting. Untuk saat ini, kami
akan mendefinisikan kehandalan sebagai: probabilitas bahwa program tidak akan gagal selama tertentu
periode waktu.
Gagasan tentang waktu patut mendapat perhatian lebih lanjut. Pada akhirnya, kami tertarik
dalam pernyataan tentang waktu kalender. Sebagai contoh, kita mungkin ingin mengetahui
probabilitas bahwa sistem tertentu tidak akan gagal dalam periode waktu satu minggu, atau kita mungkin
tertarik dengan jumlah minggu pengujian sistem yang masih diperlukan untuk mencapai hasil tertentu
tingkat keandalan.
Kedua model yang dibahas di bawah ini menggunakan pengertian waktu eksekusi. Waktu
pelaksanaan
adalah waktu yang dihabiskan oleh mesin yang benar-benar menjalankan perangkat lunak. Model
keandalan
berdasarkan waktu eksekusi menghasilkan hasil yang lebih baik daripada berdasarkan waktu kalender.
Di dalam
banyak kasus, terjemahan a posteriori dari waktu eksekusi ke waktu kalender dimungkinkan.
Untuk menekankan perbedaan ini, waktu eksekusi akan dilambangkan dengan �
Akhirnya, sistem perangkat lunak bukanlah entitas statis. Perangkat lunak sering
diimplementasikan dan diuji secara bertahap. Keandalan sistem yang berkembang
sulit diungkapkan. Dalam diskusi selanjutnya, kami berasumsi bahwa sistem kami
stabil dari waktu ke waktu. Kami dapat mencirikan perilaku kegagalan perangkat
lunak dengan cara yang berbeda. Misalnya, kita dapat mempertimbangkan waktu
yang diharapkan untuk kegagalan berikutnya, interval waktu yang diharapkan antara
kegagalan yang berurutan, atau jumlah kegagalan yang diharapkan dalam interval
waktu tertentu. Dalam semua kasus, kami memperhatikan variabel acak, karena
kami tidak tahu persis kapan perangkat lunak akan gagal. Setidaknya ada dua
alasan untuk ketidakpastian ini. Pertama, kami tidak tahu di mana pemrogram
membuat kesalahan. Kedua, hubungan antara input tertentu dan urutan eksekusi
set instruksi yang sesuai biasanya tidak diketahui. Oleh karena itu, kami dapat
memodelkan kegagalan berikutnya sebagai proses stokastik. Proses stokastik
seperti itu dicirikan oleh, antara lain, bentuk dan distribusi probabilitas dari variabel
acak.
Saat perangkat lunak gagal, kami mencoba menemukan dan memperbaiki
kesalahan yang menyebabkan kegagalan ini. Secara khusus, situasi ini muncul
selama fase pengujian siklus hidup perangkat lunak. Karena kita mengasumsikan
situasi yang stabil, penerapan model keandalan sangat tepat selama pengujian
sistem, ketika masing-masing komponen telah diintegrasikan ke dalam satu sistem.
Situasi pengujian sistem ini khususnya akan dibahas di bawah ini.
Dalam situasi ini, perilaku kegagalan tidak akan mengikuti pola konstan tetapi
akan berubah dari waktu ke waktu, karena kesalahan yang terdeteksi kemudian
diperbaiki. Proses stokastik yang distribusi probabilitasnya berubah dari waktu ke
waktu disebut tidak homogen. Variasi waktu antara kegagalan yang berurutan dapat
digambarkan dalam bentuk fungsi
�(�
13.10. MEMPERKIRAKAN KEANDALAN 445
PERANGKAT LUNAK
kami memperoleh
�(�)
gambar ini. Ini belum tentu demikian. Itu tergantung pada nilai sebenarnya dari parameter
model.)
�
Kedua model
memiliki dua
parameter:
13.10. MEMPERKIRAKAN KEANDALAN PERANGKAT LUNAK 4
4
7
sebesar penurunan intensitas kegagalan. Telah ditemukan bahwa BM masih memodelkan
situasi cukup baik dalam hal profil operasional yang cukup tidak seragam.
Dengan profil operasional non-seragam yang kuat, kurva intensitas kegagalan akan terjadi
bentuk cembung, seperti pada LPM. Beberapa kelas input kemudian akan dipilih secara relatif sering.
Akibatnya, kesalahan tertentu akan muncul lebih awal dan diperbaiki lebih cepat. Ini
koreksi akan berdampak lebih besar pada penurunan intensitas kegagalan.
Pada kedua model tersebut,
�
Probabilitas 0 kegagalan dalam jangka waktu

�
panjang
13.11. RINGKASAN 449
Gambar 13.22 Pandangan konseptual dari proses pendugaan parameter

(Sumber:J.D.Musa,A. Iannino dan K.Okumoto, Keandalan Perangkat Lunak, Hak
Cipta McGraw-Hill Book Company,1987. Direproduksi atas izin McGraw-Hill, Inc.)
berbasis proyek per proyek. Karena kita tidak mengetahui sebelumnya model mana
yang akan berkinerja terbaik, adalah bijaksana untuk mengadopsi pendekatan
eklektik, dan menggunakan sejumlah model yang berbeda secara bersamaan.
13.11 Ringkasan
Dalam bab ini kita membahas sejumlah besar teknik tes. Kami menekankan
pentingnya deteksi kesalahan dini. Penting untuk memperhatikan pengujian selama
tahap awal proses pengembangan perangkat lunak. Aktivitas pengujian awal adalah
aktivitas yang paling hemat biaya. Kegiatan pengujian awal memberikan peluang
untuk mencegah kesalahan dibuat sejak awal. Bentuk ekstrim dari pengembangan
yang digerakkan oleh tes, di mana tes menulis adalah hal pertama yang kami
lakukan.
Dalam praktiknya, berbagai teknik pengujian manual tampaknya paling sering

digunakan. Mereka ternyata setidaknya sama suksesnya dengan berbagai teknik
struktural dan fungsional. Inspeksi khususnya telah ditemukan sebagai teknik
pengujian yang sangat hemat biaya. Di samping teknik pengujian yang digunakan,
elemen utama dalam deteksi dan penghapusan kesalahan perangkat lunak adalah
pilihannya. personel - beberapa orang secara signifikan lebih baik dalam
menemukan dan menghilangkan kesalahan daripada yang lain.
Karena pengujian menyeluruh umumnya tidak layak, kita harus memilih
serangkaian kasus uji yang memadai. Teknik tes dapat diklasifikasikan menurut
kriteria yang digunakan untuk mengukur kecukupan perangkat tes ini. Tiga kategori
besar kriteria kecukupan tes dapat dibedakan:
– Pengujian berbasis cakupan, di mana persyaratan pengujian ditentukan

dalam hal cakupan produk yang akan diuji, misalnya, persentase pernyataan
yang dieksekusi.
– Pengujian berbasis kesalahan, di mana fokusnya adalah mendeteksi

kesalahan, misalnya, persentase kesalahan seeded terdeteksi.
– Pengujian berbasis kesalahan, yang berfokus pada pengujian titik rawan

kesalahan, seperti 0, 1, atau batas atas array.
Kriteria kecukupan tes dapat digunakan sebagai aturan penghentian, sebagai

instrumen pengukuran, atau sebagai generator kasus uji. Kriteria kecukupan tes dan
teknik tes yang sesuai dapat dilihat sebagai dua sisi dari mata uang yang sama.
Teknik pengujian berbasis cakupan memudahkan untuk mengukur kriteria berbasis
cakupan, tetapi tidak membantu kami dalam menilai apakah semua titik rawan
kesalahan telah diuji.
Evaluasi eksperimental menunjukkan bahwa tidak ada teknik pengujian terbaik
yang seragam. Teknik yang berbeda cenderung mengungkapkan jenis kesalahan
yang berbeda. Oleh karena itu, sebaiknya 'menyedot karpet ke lebih dari satu arah'.
Satu baris penelitian membahas kekuatan relatif dari kriteria kecukupan tes.
Ukuran yang terkenal untuk membandingkan kriteria kecukupan tes berbasis
program adalah hubungan subsummerasi: kriteria X memasukkan Y jika, untuk
semua program P dan semua perangkat tes T, kecukupan X menyiratkan kecukupan
Y. Banyak kriteria kecukupan terkenal telah terkait satu sama lain dalam hirarki
subsume.
Seperti aktivitas siklus hidup lainnya, pengujian harus direncanakan,
dikendalikan, dan didokumentasikan dengan hati-hati. Beberapa Standar IEEE
memberikan pedoman yang berguna untuk melakukan hal ini (IEEE829, 1998;
IEEE1012, 1986).
Bagian terakhir dari bab ini dikhususkan untuk diskusi tentang bagaimana
memperkirakan keandalan perangkat lunak secara kuantitatif. Model keandalan
perangkat lunak yang tersedia saat ini terbatas dalam nilai praktis langsungnya.
Secara khusus, nomodel secara konsisten berkinerja terbaik.
13.12 Bacaan lebih

lanjut
Buku teks terkenal tentang pengujian adalah (Myers, 1979) (atau versi terbarunya (Myers,
2004)) dan (Beizer, 1995). Whittaker (2000) memberikan gambaran singkat tentang lapangan.
Untuk pembahasan lebih lanjut tentang masalah keamanan, lihat (Leveson, 1991). Analisis pohon
kesalahan adalah
dibahas dalam (Leveson, 1986). Zhu dkk. (1997) memberikan gambaran yang sangat baik tentang
jenis strategi pengujian dibahas dalam bagian 13.5--13.7 dan kecukupan terkait
kriteria. Rothermel dan Harrold (1996) dan Harrold (1999) memberikan gambaran yang sangat bagus
teknik uji regresi. Pengujian perangkat lunak berorientasi objek dibahas dalam (Binder,
2000).
Upaya pertama untuk mengembangkan beberapa teori pada tanggal pengujian kembali ke
1970-an (Goodenough dan Gerhart, 1975), (Howden, 1982), dan (Howden, 1985).
Setelah itu, sebagian besar penelitian itu diarahkan untuk menemukan dan menghubungkan tes
kriteria kecukupan (Weyuker, 1988), (Clarke et al., 1989), (Weyuker, 1990), (Frankl
dan Weyuker, 1993a), (Frankl dan Weyuker, 1993b), (Parrish dan Zweben, 1995),
dan (Zhu, 1996). Evaluasi eksperimental kriteria kecukupan tes dapat ditemukan di
(Frankl dan Weiss, 1993), (Weyuker, 1993), (Offutt dan Lee, 1994), (Harrold et al.,
1997), dan (Frankl et al., 1997). Eksperimen yang membandingkan manual dan fungsional atau
teknik uji struktural dilaporkan dalam (Basili dan Selby, 1987), (Kamsties
dan Lott, 1995), dan (Wood et al., 1997). Juristo dkk. (2004) memberikan gambaran tentang 25
tahun percobaan teknik pengujian.
Metode pengembangan Cleanroom dijelaskan dalam (Selby et al., 1987) dan
(Mills et al., 1987). Pengalaman dengan Cleanroom dibahas dalam (Currit et al., 1986)
dan (Trammell et al., 1992). Abstraksi bertahap dijelaskan dalam (Linger et al., 1979).
Beck (2003) menjelaskan pengembangan berbasis tes. Janzen dan Saiedian (2005) memberi
perspektif yang agak lebih luas tentang potensinya. Hunt dan Thomas (2003) adalah salah satunya
banyak buku teks yang menjelaskan JUnit. Pengaruh pengembangan yang didorong oleh pengujian
terhadap produktivitas
dan kesalahan dilaporkan dalam (Maximilien dan Williams, 2003) dan (Erdogmus et al.,
2005).
Inspeksi diperkenalkan oleh Fagan pada tahun 1970-an (Fagan, 1976) dan (Fagan,
1986). Gilb dan Graham (1993) adalah buku teks tentang inspeksi; Wiegers (2002) adalah
buku teks tentang ulasan sejawat. Ada banyak evaluasi eksperimental
inspeksi; lihat misalnya (Knight dan Myers, 1993), (Weller, 1993), (Grady dan
van Slack, 1994), (Porter et al., 1995), (Porter et al., 1997), (Porter et al., 1998) dan
(Biffl dan Halling,2002). Parnas dan Lawford (2003a) dan Parnas dan Lawford (2003b)
adalah pengantar untuk dua masalah jurnal khusus pendamping tentang inspeksi perangkat lunak.
Ciolkowski dkk. (2003) membahas keadaan seni dalam ulasan perangkat lunak. Nilai
bukti kebenaran formal diperdebatkan di (DeMillo et al., 1979). Perdebatan panas di
literatur menunjukkan bahwa masalah ini sama sekali belum terselesaikan (Fetzer, 1988).
Model waktu eksekusi dasar dan model waktu eksekusi logaritmikPoisson
dibahas secara luas, dan dibandingkan dengan sejumlah model lain, di Musa
et al. (1987). Lyu (1995) adalah sumber yang sangat komprehensif tentang keandalan perangkat lunak.
Pengalaman dengan pemodelan keandalan perangkat lunak dilaporkan di (Jeske dan Zhang,
2005). Whittaker dan Voas (2000) memberikan kriteria selain waktu dan profil
operasional yang mempengaruhi reliabilitas.
Latihan
1. Apa yang dimaksud dengan kriteria kecukupan tes? Jenis kegunaan apa yang dimilikinya?
2. Jelaskan kategori teknik pengujian berikut: pengujian berbasis cakupan,

pengujian berbasis kesalahan, dan pengujian berbasis kesalahan.
3. Asumsi apa yang mendasari strategi pengujian mutasi?
4. Apa perbedaan antara pengujian kotak hitam dan pengujian kotak putih?
5. Definisikan istilah-istilah berikut: kesalahan, kesalahan, dan

kegagalan.
6. Apa itu inspeksi Fagan?
7. Apa yang dimaksud dengan pengembangan berbasis pengujian?
8. Tetapkan kategori cakupan aliran kontrol berikut: Cakupan All-Paths,

Cakupan All-Edges, cakupan All-Statements.
9. Pertimbangkan rutinitas berikut (dalam Modula-2):
prosedur SiftDown(dulu A: susunan dari bilangan bulat; k, n: bilangan

bulat);
dulu induk, anak, sisipkan, Ak: bilangan bulat;
mulai
induk:= k; anak:= k + k;
Ac:= A[k]; masukkan := Dan;
lingkaran
jika anak >
dapat berkonsultasi dengan teks apa pun tentang struktur data untuk mempelajari lebih
lanjut tentang tumpukan.) The
rutin diuji menggunakan input berikut:
n = 5, k = 2,
A[1] = 80, A[2] = 60, A[3] = 90, A[4] = 70, A[5] = 10.
Apakah tes di atas menghasilkan cakupan pernyataan 100%? Jika tidak, berikan satu atau
lebih banyak kasus uji tambahan sehingga cakupan pernyataan 100% diperoleh.
10. Untuk contoh rutin dari latihan 9, buatlah rangkaian tes yang menghasilkan 100%
cakupan cabang.
11. Untuk contoh rutin dari latihan 9, buatlah satu set tes yang mencapai
Cakupan Semua Penggunaan.
12. Pertimbangkan dua fragmen program berikut:
Fragmen 1:
ditemukan:= salah; penghitung:= 1;
ketika (menangkal <
16. Apa perbedaan antara uji sistem dan uji penerimaan?
17. Bandingkan pengujian integrasi top-down dan bottom-up.
18. Apa perbedaan utama antara model waktu eksekusi dasar dan model
waktu eksekusi logaritmik Poisson dari keandalan perangkat lunak?
19. Berikan definisi keandalan perangkat lunak. Berikan alasan untuk berbagai
bagian dari definisi ini.
20. Mengapa penting untuk mempertimbangkan profil operasional sistem

sementara menilai keandalannya?
21. Dapatkah Anda memikirkan alasan mengapa model keandalan berdasarkan

waktu eksekusi menghasilkan hasil yang lebih baik daripada berdasarkan waktu
kalender?
22. Apakah keandalan perangkat lunak dapat ditentukan secara objektif?
23. �
Tentukan fungsi (melalui kondisi awal dan akhir) dari rutin ini
menggunakan abstraksi bertahap.
26. ~
32. ~
14
Pemeliharaan Perangkat Lunak
TUJUAN PEMBELAJARAN
�
458 PEMELIHARAAN PERANGKAT LUNAK
Pemeliharaan perangkat lunak tidak terbatas pada koreksi kesalahan. Sebagian

besar
penawaran pemeliharaan dengan mengakomodasi kebutuhan pengguna baru
atau berubah
dan mengadaptasi perangkat lunak ke lingkungan yang berubah. Ini tentang
evolusi, lebih tepatnya
dari sekedar pemeliharaan. Kami membahas berbagai jenis tugas
pemeliharaan, dan
bagaimana mengaturnya.
Seperti organisme hidup dan sebagian besar fenomena alam, proyek

perangkat lunak mengikuti siklus hidup yang dimulai dari kehampaan,
diikuti oleh pertumbuhan yang cepat selama masa bayi, memasuki
masa kedewasaan yang lama, dan kemudian memulai siklus
pembusukan yang hampir menyerupai kepikunan. (Jones, 1989)
Perangkat lunak, tidak seperti anak kecil, tidak tumbuh lebih pintar dan
lebih cakap; sayangnya, tampaknya menjadi tua dan rewel.
(Lyons, 1981)
Pertimbangkan UBank, bank multinasional, tipikal organisasi besar yang sangat bergantung
pada otomatisasi untuk operasi hariannya. UBank adalah hasil dari sejumlah merger dan
pengambilalihan.
UBank memiliki ratusan kantor yang tersebar di seluruh dunia. Ini memiliki sejumlah
mainframe di situs pusat, serta ribuan workstation dan printer
terhubung. Ini memiliki 24
konektivitas internet, di
seluruh dunia, dan
diperjuangkan
459
Proses memodifikasi sistem atau komponen perangkat lunak setelah
pengiriman untuk memperbaiki kesalahan, meningkatkan kinerja atau
atribut lainnya, atau beradaptasi dengan lingkungan yang berubah.
Jadi pemeliharaan perangkat lunak, khususnya, bukan terbatas pada koreksi kesalahan laten.
Perbedaan antara pengembangan dan pemeliharaan kabur, untuk sedikitnya. Ini
membuat sulit untuk sangat berani tentang persentase dan jenis kategori pemeliharaan.
Pada bagian 14.1, kita meninjau kembali pembahasan tentang jenis kegiatan pemeliharaan dari
bab 1 dan memberikan pandangan yang lebih seimbang.
Perubahan lingkungan sistem dan kebutuhan pengguna tidak dapat dihindari.
Perangkat lunak memodelkan bagian dari realitas, dan realitas berubah, suka atau tidak suka. Sehingga
perangkat lunak juga harus berubah. Itu harus berkembang. Persentase besar dari apa yang kita
gunakan
untuk memanggil pemeliharaan, sebenarnya adalah evolusi.
Saat mencari cara untuk mengurangi masalah pemeliharaan, ada baiknya untuk ikut serta
perhatikan klasifikasi aktivitas pemeliharaan yang diberikan di bab 1. Solusi yang memungkinkan
untuk dipertimbangkan meliputi:
�
proyek pengembangan dengan fase analisis dan desain yang menghasilkan
presentasi logis dari fungsi sistem yang terjadi lebih tinggi biaya pemeliharaan
daripada proyek yang tidak menghasilkan presentasi seperti itu. Penjelasannya
adalah bahwa pengguna akhirnya mempelajari apa yang wajar ditanyakan selama
pemeliharaan. Jika mereka tahu pendekatan terstruktur telah diikuti, mereka
mengharapkan peningkatan dapat diminta, dan akan direalisasikan. Jadi mereka
akan meminta peningkatan. Jika mereka tahu tidak ada pendekatan terstruktur yang
diikuti, mereka berharap hanya perbaikan bug yang diperlukan yang dapat
dilakukan, dan permintaan pemeliharaan akan tetap moderat. Jadi kualitas yang
lebih tinggi mungkin memerlukan biaya perawatan yang lebih tinggi.
Masalah pemeliharaan tetap ada. Beberapa dari masalah ini bersifat inheren --
sistem menurun ketika diubah berulang kali -- sementara yang lain disebabkan oleh
fakta kehidupan yang sederhana: aktivitas pengembangan dan pemeliharaan nyata
dilakukan dengan cara yang kurang sempurna. Penyebab utama dari masalah
pemeliharaan yang dihasilkan dibahas di bagian 14.2.
Pembahasan masalah pemeliharaan ini menyarankan dua pendekatan untuk
memperbaiki situasi. Bagian 14.3 membahas berbagai cara untuk menemukan
kembali fakta yang hilang ('apa yang dicapai rutin ini', 'desain mana yang mendasari
sistem tertentu', dan sejenisnya) dan merestrukturisasi sistem perangkat lunak yang
ada untuk meningkatkan kemampuan pemeliharaannya. Pendekatan kedua,
dibahas dalam bagian 14.5, memerlukan sejumlah tindakan organisasi dan
manajerial untuk meningkatkan pemeliharaan perangkat lunak.
14.1 Kategori Pemeliharaan

Ditinjau Ulang
Mari kita mengingat kembali sebagian diskusi dari bab 1. Mengikuti Lientz dan
Swanson (1980), kami membedakan empat jenis aktivitas pemeliharaan.1:
�
14.1. KATEGORI PEMELIHARAAN 461
DIKUNJUNGI
Perhatikan bahwa aktivitas pemeliharaan 'nyata' -- koreksi kesalahan --
menyumbang sekitar 25% dari total upaya pemeliharaan saja. Separuh dari upaya
pemeliharaan berkaitan dengan perubahan untuk mengakomodasi perubahan
kebutuhan pengguna, sedangkan 25% sisanya sebagian besar berkaitan dengan
penyesuaian perangkat lunak terhadap perubahan lingkungan eksternal (lihat
gambar 14.1). Ingat juga bahwa total biaya pemeliharaan sistem diperkirakan terdiri
dari setidaknya 50 % dari total biaya siklus hidup. Angka serupa berlaku untuk
personel yang terlibat. Gambar 14.2 memberikan perkiraan jumlah orang yang
bekerja dalam pengembangan perangkat lunak dibandingkan dengan pemeliharaan
perangkat lunak menurut (Jones, 2006).
Gambar 14.1 Sebaran kegiatan pemeliharaan
Tahun Perkembangan Pemeliharaan Pemeliharaan

persentase
1975 350.000 75.000 17.65

1990 900.000 800.000 47.06
2005 775.000 2.500.000 76.34
Gambar 14.2 Distribusi pengembang dan pengelola di AS
Data pada gambar 14.1 didasarkan pada (Lientz dan Swanson, 1980) dan
mencerminkan keadaan praktik pada tahun 1970-an. Studi selanjutnya
menunjukkan bahwa situasinya tidak berubah menjadi lebih baik. Nosek dan Palvia
(1990) sekali lagi mengangkat masalah pemeliharaan utama dan sampai pada
kesimpulan yang mengganggu bahwa masalah pemeliharaan tetap hampir sama,
terlepas dari kemajuan dalam metodologi dan teknik pengembangan terstruktur.
Penelitian lain, seperti Basili et al. (1996) memberikan hasil yang kurang lebih sama.
Distribusi relatif kegiatan pemeliharaan adalah tentang
sama seperti 20 tahun yang lalu. Meskipun sistem telah menjadi lebih besar, staf
pemeliharaan telah bertambah, ada lebih banyak sistem, dan ada kecenderungan
yang pasti untuk peningkatan upaya pemeliharaan relatif terhadap upaya
pengembangan.
Beberapa penelitian memberikan hasil yang cukup berbeda dengan gambaran
umum di atas. Schach dkk. (2003), misalnya, menyelidiki upaya pemeliharaan
dalam tiga sistem dan menemukan persentase pemeliharaan korektif sebesar 50%
atau lebih, dan persentase yang sangat rendah untuk pemeliharaan adaptif. Tidak
ada argumen yang meyakinkan untuk perbedaan ini.
Di banyak organisasi, definisi pemeliharaan perangkat lunak tidak mengikuti
definisi IEEE. Beberapa organisasi misalnya mendefinisikan upaya perubahan lebih
besar dari, katakanlah, tiga bulan, sebagai pengembangan daripada pemeliharaan.
Ini mengaburkan gambar lebih jauh. Dalam praktiknya juga, orang sulit
membedakan antara pemeliharaan adaptif dan perfeksif. Yang tersisa kemudian
adalah perbedaan antara memperbaiki kesalahan dan 'sisanya'. Yang terakhir
sebagian besar melayani 75% atau lebih dari upaya pemeliharaan. Kategori
pemeliharaan dari (Lientz dan Swanson, 1980) mengacu pada perangkat lunak saja.
Menjaga perangkat lunak tetap hidup juga menimbulkan biaya lain. Misalnya,
pengguna baru harus dilatih, dan helpdesk perlu memiliki staf. Saat ini, tidak jarang
biaya pendukung ini mencapai sekitar 25% dari biaya pemeliharaan sistem.
Cara lain untuk melihat distribusi biaya pemeliharaan dan jenis tugas
pemeliharaan yang berlaku adalah sepanjang dimensi waktu. Kami dapat
membedakan tahapan siklus hidup pemeliharaan berikut:
�
14.2. PENYEBAB UTAMA MASALAH 463
PEMELIHARAAN
lazim. Bennett dan Rajlich (2000) menggunakan istilah tersebut tahap evolusi Dan pelayanan
panggung untuk membedakan antara periode di mana sistem dapat berhasil berkembang
dan periode berikutnya di mana hal ini tidak lagi terjadi. Pada tahap terakhir, perubahan
menjadi taktis. Misalnya, perubahan yang diperlukan diwujudkan melalui tambalan dan
pembungkus.
Akhirnya, kita dapat mempertimbangkan distribusi usaha atas aktivitas tunggal
tugas pemeliharaan. Untuk tugas-tugas terkait kode, kegiatan utamanya adalah:
�
JIKA tidak-baca1 (V1) GOTO DEF1;

tampilan (V1);
GOTO C;
DEF1: JIKA tidak dibaca2 (V2) GOTO DEF2;
tampilan (V2);
GOTO C;
DEF2: tampilan (3000);
C:
Gambar 14.3 Kode tidak terstruktur untuk membaca

altimeter
jika baca-meter1 (V1) Kemudian tampilan (V1) kalau tidak

jika baca-meter2 (V2) Kemudian tampilan (V2) kalau tidak
tampilan (3000)
berakhir jika;
Gambar 14.4 Kode terstruktur untuk membaca

altimeter
Orang yang merekayasa ulang perangkat lunak berhak berpikir bahwa ini
bukanlah cara yang tepat untuk bereaksi terhadap perangkat keras yang tidak
berfungsi. Pesawat tempur terbang di ketinggian yang sangat tinggi atau sangat
dekat dengan tanah. Mereka tidak terbang di antaranya. Jadi dia menghubungi
pejabat yang bertanggung jawab dan meminta izin untuk menampilkan pesan
peringatan yang jelas, seperti 'PULL UP' yang berkedip.
Izin untuk mengubah nilai yang ditampilkan ditolak. Generasi pilot tempur
sekarang dilatih untuk bereaksi dengan tepat terhadap pesan default saat ini.
Manual pelatihan mereka bahkan menyatakan frasa peringatan seperti 'Jika
pembaca altimeter menampilkan nilai 3000 selama lebih dari satu detik, PULL UP'.
Cerita ini tidak mungkin benar. Atau bisakah? Itu menggambarkan beberapa
penyebab utama masalah pemeliharaan:
- kode tidak terstruktur,
– Pemrogram pemeliharaan memiliki pengetahuan yang tidak memadai tentang

sistem atau domain aplikasi. Memahami alasan di balik kode adalah salah satu
masalah paling serius yang dihadapi pengelola.
– dokumentasi tidak ada, ketinggalan zaman, atau paling tidak tidak

cukup.
– pemeliharaan perangkat lunak memiliki citra buruk (ini tidak diilustrasikan oleh
anekdot tapi jelas merupakan masalah pemeliharaan).
14.2. PENYEBAB UTAMA MASALAH 465
PEMELIHARAAN
Kode tidak terstruktur digunakan di sini sebagai istilah umum untuk sistem yang dirancang dengan buruk
atau diberi kode. Itu memanifestasikan dirinya dalam berbagai cara: penggunaan gotos, prosedur
panjang,
penamaan yang buruk dan tidak konsisten, kompleksitas modul tinggi, kohesi lemah dan kuat
penggabungan, kode yang tidak dapat dijangkau, pernyataan if bersarang dalam, dan sebagainya.
Bahkan jika sistem pada awalnya dirancang dan dibangun dengan baik, mereka mungkin telah
menjadi seperti itu
lebih sulit untuk mempertahankan dalam perjalanan waktu. Banyak perangkat lunak yang harus
dipertahankan adalah
dikembangkan di era pemrograman pra-terstruktur. Sebagian darinya mungkin masih tertulis
bahasa campuran. Itu dirancang dan ditulis untuk mesin dengan pemrosesan terbatas
dan kapasitas memori. Itu mungkin telah dipindahkan ke perangkat keras atau perangkat lunak yang
berbeda
platform lebih dari sekali tanpa struktur dasarnya berubah.
Ini juga bukan keseluruhan cerita. Struktur buruk dari banyak sistem masa kini
pada tingkat desain dan kode tidak semata-mata disebabkan oleh usia mereka. Sebagai hasil dari
studi mereka tentang dinamika sistem perangkat lunak, Lehman dan Belady merumuskan a
serangkaian Hukum Evolusi Perangkat Lunak (lihat juga bab 3). Yang paling bertahan
pemeliharaan perangkat lunak adalah:
Hukum perubahan yang berkelanjutan Sebuah sistem yang digunakan terus

mengalami perubahan, sampai dinilai lebih hemat biaya untuk merestrukturisasi
sistem atau menggantinya dengan versi yang benar-benar baru.
Hukum meningkatnya kompleksitas Sebuah program yang diubah, menjadi

kurang terstruktur (entropi meningkat) dan dengan demikian menjadi lebih
kompleks. Seseorang harus menginvestasikan upaya ekstra untuk menghindari
peningkatan kompleksitas.
Sistem perangkat lunak besar cenderung bertahan dalam produksi untuk waktu yang lama. Setelah
dimasukkan ke dalam
produksi, peningkatan tidak bisa dihindari. Sebagai konsekuensi dari penerapan
perangkat tambahan ini, entropi sistem perangkat lunak meningkat dari waktu ke waktu. Inisial
struktur menurun dan kompleksitas meningkat. Ini pada gilirannya memperumit perubahan di masa
depan
ke sistem. Sistem perangkat lunak seperti itu menunjukkan tanda-tanda radang sendi. Pemeliharaan
preventif
dapat menunda timbulnya entropi tetapi, biasanya, hanya pencegahan dalam jumlah terbatas
pemeliharaan dilakukan.
Akhirnya, sistem tidak dapat dipertahankan dengan baik lagi. Dalam praktiknya, itu
seringkali tidak mungkin untuk sepenuhnya mengganti sistem lama dengan yang baru. Mengembangkan
sistem yang benar-benar baru dari awal terlalu mahal, atau akan berisi
terlalu banyak kesalahan sisa untuk memulai, atau tidak mungkin mengartikulasikan ulang yang asli
persyaratan. Biasanya, kombinasi dari faktor-faktor ini berlaku. Meningkatkan perhatian adalah
oleh karena itu diberikan cara untuk 'meremajakan' atau 'mendaur ulang' sistem perangkat lunak yang
ada, cara untuk
membuat versi terstruktur dari sistem operasional yang ada agar menjadi
lebih mudah dipelihara.
Entropi tidak hanya disebabkan oleh pemeliharaan. Dalam metode tangkas, seperti XP, memang
begitu
tahap perantara yang diterima. Metode ini memiliki langkah eksplisit untuk meningkatkan
kode. Ini dikenal sebagai pemfaktoran ulang. Refactoring didasarkan pada identifikasi 'bau tidak sedap'
dan ulang kode untuk menyempurnakan desainnya (lihat juga bagian 14.3.1).
Pada tingkat rendah proses perbaikan kode dapat didukung oleh alat-alat seperti
restruktur kode dan pemformat ulang. Untuk mendapatkan abstraksi tingkat yang
lebih tinggi umumnya membutuhkan bimbingan manusia dan pemahaman sistem
yang cukup.
Ini membawa kita ke masalah pemeliharaan kedua: sedikitnya pengetahuan
yang dimiliki pemrogram pemeliharaan tentang sistem atau domain aplikasi.
Perhatikan bahwa kurangnya pengetahuan domain aplikasi berkaitan dengan
pengembangan perangkat lunak secara umum (Curtiset al., 1988). Situasi
sehubungan dengan pemeliharaan perangkat lunak diperparah oleh fakta bahwa
biasanya hanya ada sedikit sumber yang dapat digunakan untuk membangun
pemahaman semacam itu. Dalam banyak kasus, kode sumber adalah satu-satunya
sumber terpercaya. Masalah utama dalam pemeliharaan perangkat lunak kemudian
adalah mendapatkan pemahaman yang cukup tentang sistem dari kode sumbernya.
Semakin mirip spageti kode ini, semakin sulit untuk menguraikannya. Pemahaman
yang tidak memadai menghasilkan perubahan yang mungkin memiliki efek riak tak
terduga yang pada gilirannya menimbulkan tugas pemeliharaan lebih lanjut.
Pemeliharaan juga terhambat jika dokumentasi tidak ada, tidak mencukupi, atau
kedaluwarsa. Pemrogram berpengalaman telah belajar untuk tidak mempercayai
dokumentasi: sebuah pengamatan yang mengecewakan, meskipun realistis.
Selama pengembangan awal, dokumentasi seringkali gagal karena tenggat waktu
dan batasan waktu lainnya. Pemeliharaan itu sendiri sering terjadi dalam mode
'perbaikan cepat' di mana kode ditambal untuk mengakomodasi perubahan.
Dokumentasi teknis dan deskripsi perangkat lunak tingkat tinggi lainnya kemudian
tidak diperbarui. Pemrogram pemeliharaan yang harus berurusan dengan sistem ini
telah menjadi sebagian sejarawan, sebagian detektif, dan sebagian peramal (Corby,
1989). Prosedur kerja yang hati-hati dan perhatian manajemen dapat mencegah
hal tersebut terjadi. Tetapi meskipun demikian kami tidak yakin bahwa jenis
dokumentasi yang tepat akan dihasilkan. Dua masalah patut mendapat perhatian
kita dalam hal ini:
�
14.3. REVERSE ENGINEERING DAN 467
REFACTORING
programmer pemeliharaan menghalangi mereka untuk menjadi cukup akrab dengan
perangkat lunak yang akan dipertahankan yang pada gilirannya menghambat pemeliharaan di masa
mendatang.
Akan jauh lebih baik untuk memiliki sikap yang lebih positif terhadap pemeliharaan.
Mempertahankan perangkat lunak adalah pekerjaan yang sangat sulit. Konten pekerjaan pemeliharaan
programmer lebih menuntut daripada konten pekerjaan programmer pengembangan.
Program biasanya ditulis oleh orang lain, orang yang seringkali tidak bisa
berkonsultasi karena mereka telah meninggalkan perusahaan atau terjerat dalam pengembangan
sistem baru. Saat membuat perubahan dalam sistem yang ada, seseorang terikat dengan sangat
struktur sistem itu. Biasanya ada tekanan waktu yang kuat pada pemeliharaan
personil. Pekerjaan pemeliharaan membutuhkan lebih banyak keterampilan dan pengetahuan daripada
pengembangan
melakukan. Ini lebih sulit (Chapin, 1987).
Kelompok pemeliharaan sangat penting. Merekalah yang membuat semuanya berjalan.
Adalah tugas mereka untuk memastikan bahwa perangkat lunak mengikuti realitas yang selalu berubah.
Dibandingkan dengan pengembangan perangkat lunak, pemeliharaan perangkat lunak lebih berdampak
pada
kesejahteraan suatu organisasi.
14.3 Reverse Engineering dan

Refactoring
Apa yang kami lakukan sekarang dengan rekayasa balik adalah Arkeologi. Kami mencoba
untuk mendapatkan
pemahaman sistem yang ada dengan memeriksa artefak kuno dan menyatukannya
perangkat lunak yang setara dengan pot tanah liat yang rusak. Kemudian kami melihat ke
restrukturisasi dan rekayasa ulang
untuk menyimpan tanah liat.
(Chikofsky, 1990)
Sangat modis dalam perdagangan kami untuk membuat istilah baru sesekali dan menawarkannya
sebagai
obat mujarab untuk krisis perangkat lunak. Salah satu istilah magisnya adalah rekayasa balik.
Itu datang dengan samaran yang berbeda dan berarti hal yang sama sekali berbeda untuk berbeda
rakyat. Dalam pembahasan di bawah ini kita akan menggunakan terminologi dari (Chikofsky dan
Lintas II, 1990). Istilah yang berbeda diilustrasikan pada Gambar 14.5.
Chikofsky mendefinisikan reverse engineering sebagai 'proses menganalisis sistem subjek
ke
- mengidentifikasi komponen sistem dan keterkaitannya dan
– membuat representasi sistem dalam bentuk lain atau pada tingkat yang lebih tinggi
abstraksi.'
Menurut definisi ini, rekayasa balik hanya menyangkut pemeriksaan suatu sistem.
Adaptasi sistem dan segala bentuk restrukturisasi, seperti mengubah gotos menjadi
konstruksi kontrol terstruktur, tidak termasuk dalam definisi ketat rekayasa balik.
Reverse engineering mirip dengan rekonstruksi cetak biru yang hilang. Mengisi
ulang kamar mandi atau menambah kamar tidur baru adalah urusan yang sama
sekali berbeda. Jika pembedaan ini tidak dibuat dengan hati-hati, arti dari istilah
reverseengineering terlalu encer dan direduksi menjadi sinonim mewah untuk
pemeliharaan.
Gambar 14.5 Reverse engineering dan gagasan terkait (Sumber: E.J. Chikofsky &
J.H. CrossII, Rekayasa balik dan pemulihan desain, Perangkat Lunak IEEE 7, 1
(1990) hlm 13--18, 1990 IEEE.)
Definisi di atas masih menyisakan pertanyaan apakah deskripsi yang dihasilkan

berada pada tingkat abstraksi yang lebih tinggi atau tidak. Untuk menekankan
perbedaan tersebut, Chikofsky menggunakan pengertian tentang pemulihan desain
Dan dokumentasi ulang, masing-masing.
Redocumentation menyangkut derivasi dari deskripsi semantik-setara pada
tingkat abstraksi yang sama. Contoh redocumentation adalah transformasi dari
program yang indentasinya buruk menjadi program yang memiliki lay-out yang rapi
atau pembuatan sekumpulan flowchart untuk program tertentu.
Pemulihan desain berkaitan dengan penurunan deskripsi semantik yang setara
pada tingkat abstraksi yang lebih tinggi. Beberapa orang membatasi istilah rekayasa
balik pada upaya yang menghasilkan deskripsi tingkat lebih tinggi dan dengan
demikian menyamakan istilah tersebut dengan apa yang kita sebut pemulihan
desain.
Perhatikan bahwa kesetaraan fungsional 100% sulit dicapai dalam rekayasa
balik. Orang yang melakukan proses (reengineer) mungkin mengalami kesalahan
dalam sistem asli dan mungkin ingin memperbaikinya. Kesalahan seperti itu
mungkin sangat dalam
REFACTORING
tersembunyi di sistem asli dan menjadi jauh lebih merepotkan di bagian belakang
sistem rekayasa. Bahasa pemrograman mungkin tidak sepenuhnya didefinisikan dan
implementasi mungkin bergantung pada karakteristik mesin tertentu. Kesetaraan data
mungkin sulit dicapai karena masalah pengetikan, perkiraan, konversi data,
dll. Dalam praktiknya, tampaknya masuk akal untuk menyelesaikan masalah ini dengan menyetujui
beberapa penerimaan
uji untuk sistem yang direkayasa ulang, sehingga melonggarkan kesetaraan fungsional 100%.
persyaratan.
Jelas, reverse engineering sering dilakukan dalam keadaan di mana tar-
dapatkan sistem diadaptasi juga. Dua subclass penting adalah restrukturisasi Dan
rekayasa ulang.
Restrukturisasi menyangkut transformasi sistem dari satu representasi
ke yang lain, pada tingkat abstraksi yang sama. Fungsionalitas sistem tidak
tidak berubah. Transformasi spaghetti-code menjadi structured code adalah salah satu bentuk dari
restrukturisasi. Desain ulang sistem (mungkin setelah langkah pemulihan desain).
contoh lain dari restrukturisasi. Dalam metode gesit, restrukturisasi kode menjadi lebih baik
desainnya merupakan langkah proses yang eksplisit. Di sana, itu dikenal sebagai pemfaktoran ulang.
Refactoring adalah
dibahas di bagian 14.3.1.
Refactoring adalah metode kotak putih, yang melibatkan pemeriksaan dan perubahan
ke kode. Dimungkinkan juga untuk memodernisasi sistem tanpa menyentuh kode. Untuk
Misalnya, sistem lawas dapat diberikan antarmuka pengguna modern. Yang lama, berbasis teks
antarmuka kemudian dibungkus untuk menghasilkan, misalnya, antarmuka pengguna grafis atau klien
berjalan di browser Web. Ini adalah metode kotak hitam. Kode dari sistem lama adalah
tidak diperiksa. Input dan output hanya dialihkan ke pembungkus. Kegunaan
ditingkatkan, meskipun kemampuan antarmuka jenis baru seringkali tidak sepenuhnya
dieksploitasi. Teknik kotak hitam serupa dapat digunakan untuk beralih ke database lain, atau
mengintegrasikan sistem melalui dokumen XML menengah. Pembungkus kotak hitam ketiga
teknik diterapkan pada tingkat komponen, di mana logika bisnis dan data
dibungkus dan selanjutnya diakses melalui antarmuka seolah-olah itu adalah, katakanlah, JavaBean.
Teknik pembungkusan ini tidak mengubah platform tempat perangkat lunak
sedang berlari. Jika perubahan platform terlibat dalam upaya restrukturisasi warisan
sistem, ini dikenal sebagai migrasi. Migrasi ke platform lain sering dilakukan
dalam hubungannya dengan aktivitas penambahan nilai seperti perubahan antarmuka, atau kode
perbaikan.
Restrukturisasi terkadang dilakukan bersamaan dengan upaya mengkonversi yang sudah ada
perangkat lunak menjadi blok bangunan yang dapat digunakan kembali. Upaya reklamasi semacam itu
mungkin lebih tinggi
(tidak langsung) hasil dari penghematan belaka dalam pengeluaran pemeliharaan untuk tertentu
sistem sedang direstrukturisasi, terutama jika upaya tersebut menyangkut keluarga sistem serupa.
Yang terakhir sering dilakukan dalam kombinasi dengan rekayasa domain dan pengembangan
arsitektur atau kerangka kerja (dapat digunakan kembali).
Dengan rekayasa ulang, juga disebut renovasi, perubahan nyata dilakukan pada sistem.
Langkah rekayasa balik diikuti oleh langkah rekayasa maju tradisional
mana perubahan yang diperlukan dimasukkan.
Setiap transformasi di atas dimulai dari deskripsi sistem yang diberikan
untuk diubah. Dalam kebanyakan kasus, ini akan menjadi kode program, yang
mungkin didokumentasikan secara memadai atau tidak. Namun, mungkin juga
untuk, katakanlah, merestrukturisasi desain yang sudah ada atau merekonstruksi
spesifikasi persyaratan untuk desain tertentu. Untuk transformasi ini juga, berlaku
istilah rekayasa balik.
Rekayasa balik dan restrukturisasi dapat dilakukan secara manual, tetapi ini
agak melelahkan. Cukup banyak alat telah dikembangkan untuk mendukung proses
ini. Alat-alat ini dibahas di bagian 14.3.3. Namun, ada beberapa batasan yang
melekat pada seberapa banyak yang dapat dicapai secara otomatis. Keterbatasan
ini dibahas di bagian 14.3.2.
14.3.1 Pemfaktoran ulang

Nama modern untuk restrukturisasi adalah pemfaktoran ulang. Refactoring
menjadi populer sebagai salah satu praktik dari XP (lihat bagian 3.2.4). Tentu saja,
pemrogram telah menerapkan teknik ini dalam beberapa bentuk sejak awal
pemrograman.2. Cukup sering, kegiatan refactoring tidak direncanakan secara
eksplisit, dan terjadi tanpa disadari dalam pekerjaan sehari-hari pengembang
perangkat lunak. Di XP dan metode gesit lainnya, mereka adalah langkah metode
eksplisit.
Ada argumen yang mendukung dan menentang refactoring. Aturan teknik klasik
"jika tidak rusak, jangan perbaiki" adalah argumen yang kuat untuk menentang
pemfaktoran ulang. Di sisi lain, hukum kedua evolusi perangkat lunak memberi tahu
kita bahwa perangkat lunak menjadi semakin kompleks dari waktu ke waktu. Jadi
kami terpaksa menerapkan refactoring untuk menjaga perangkat lunak tetap
terpelihara. Argumen pro dan kontra keduanya valid. Itu tergantung pada fase
perangkat lunak di mana argumen adalah yang menentukan. Selama tahap evolusi,
ketika pengetahuan tentang sistem masih ada, refactoring adalah pilihan yang layak.
Selama tahap servis, pengetahuan akan menguap sampai batas tertentu, dan
refactoring kemudian mungkin menimbulkan lebih banyak masalah daripada
memecahkannya. Selama tahap itu, seseorang dapat memutuskan misalnya untuk
menambahkan pembungkus, dan tidak lagi menyentuh perangkat lunak.
Refactoring diterapkan ketika struktur perangkat lunak berkualitas di bawah standar.
Fowler (1999) menggunakan istilah bau busuk untuk menunjukkan terjadinya
kualitas kode di bawah standar. Fowler (1999) mencantumkan 22 bau busuk
berikut3:
�
REFACTORING
�
�
REFACTORING
bau. Misalnya, jika kelas-kelas tertentu sering berubah, atau kelas diperkenalkan
dalam satu versi, menghilang di versi berikutnya, dan kemudian muncul kembali,
manfaat seperti itu untuk diperiksa lebih dekat. Fowler (1999) menyatakan bahwa
"tidak ada rangkaian metrik yang menyaingi intuisi manusia". Di sisi lain, beberapa
metrik yang ditentukan di bagian 12.1 memang berhubungan dengan sejumlah bau
tidak sedap yang tercantum di atas. Misalnya, nilai tinggi untuk kompleksitas
siklomatis McCabe dapat menunjukkan bau tidak sedap pada Pernyataan
Pengalihan, sedangkan nilai tinggi untuk metrik Coupling Between Object Classes
(CBO) dapat menunjukkan bau tidak enak pada Feature Envy. Metrik dengan
demikian dapat meningkatkan intuisi manusia dalam mencari bau tak sedap.
14.3.2 Keterbatasan Inheren

Jika Anda melewati kekacauan yang tidak terstruktur dan tidak modular melalui salah satu
sistem restrukturisasi ini,
Anda berakhir dengan yang terbaik, kekacauan yang terstruktur dan tidak modular.
(Wendel, 1986)
Rekayasa terbalik sebagian besar tidak akan terbatas pada dokumentasi ulang
dalam arti sempit. Kita akan sering cenderung bertanya mengapa hal-hal tertentu
dilakukan dengan cara yang sama, apa arti dari fragmen kode tertentu, dan
sejenisnya. Karena itu kita harus menyelidiki bagaimana programmer mempelajari
teks program. Relevansi isu-isu ini terlihat dari hasil studi kegiatan pemeliharaan
(Fjelstad dan Hamlen, 1979), dikonfirmasi oleh Yu dan Chen (2006):
�
Dalam bidang pemrograman, didalilkan bahwa para ahli mengetahui rencana

atau suar pemrograman. A rencana pemrograman adalah fragmen program yang
sesuai dengan tindakan stereotip. Misalnya, untuk menghitung jumlah rangkaian
angka, pemrogram menggunakan 'rencana putaran total berjalan'. Dalam rencana
ini, beberapa penghitung diinisialisasi ke nol dan ditambah dengan nilai berikutnya
dari rangkaian di badan loop. Asuar adalah fitur utama yang biasanya menunjukkan
adanya operasi struktur tertentu. Beacon tampaknya sangat diagnostik makna
program. Misalnya, ide kernel atau operasi sentral dalam program pengurutan
adalah operasi swap. Jika kita disajikan dengan program yang berisi operasi
penukaran, reaksi langsung kita adalah bahwa itu menyangkut beberapa program
penyortiran.
Jenis proses pemahaman program ini terjadi ketika mempelajari perangkat lunak
yang ada. Unit yang bermakna diisolasi dari teks sumber 'datar'. Pengetahuan dari
ingatan manusia dipanggil selama proses ini. Semakin banyak pengetahuan
pembaca tentang pemrograman atau domain aplikasi, semakin sukses proses ini.
Semakin baik kode sumber memetakan pengetahuan yang sudah tersedia bagi
pembaca, semakin efektif proses ini.
Selama proses pemahaman, pembaca membentuk hipotesis dan mengecek
hipotesis tersebut dengan teks yang sebenarnya. Program yang terstruktur dengan
baik dan dokumentasi yang tepat memudahkan proses ini. Jika konsep domain
aplikasi dipetakan ke unit program yang digambarkan dengan baik, maka teks
program akan lebih mudah dipahami. Jika struktur program tidak menunjukkan
hubungan dengan struktur domain aplikasi, atau pembaca tidak dapat membedakan
struktur ini, maka pemahaman teks program akan sangat terhambat.
Sebagai tambahan, kami mencatat bahwa ada dua strategi ekstrem untuk
mempelajari teks program:
– strategi yang diperlukan, dan
– strategi sistematis.
Dalam strategi sesuai kebutuhan, teks program dibaca dari awal sampai akhir
seperti sebuah prosa dan hipotesis dirumuskan berdasarkan informasi lokal.
Pemrogram yang tidak berpengalaman khususnya cenderung menggunakan
strategi ini. Dalam strategi sistematika, pemahaman keseluruhan tentang sistem
dibentuk oleh studi top-down yang sistematis dari teks program. Pendekatan
sistematis memberikan wawasan yang lebih baik tentang hubungan sebab akibat
antara komponen program.
Hubungan sebab akibat ini memainkan peran penting saat menerapkan
perubahan. Apa yang disebut rencana terdelokalisasi, di mana potongan kode yang
terkait secara konseptual terletak di bagian program yang terpisah secara fisik,
dapat menghambat aktivitas pemeliharaan secara serius. Penggunaan warisan yang
berlebihan meningkatkan penggunaan rencana yang terdelokalisasi. Jika
pemahaman kita didasarkan pada petunjuk lokal saja, modifikasi dapat dengan
mudah menghasilkan apa yang disebut efek riak, yaitu perubahan yang benar
secara lokal tetapi menimbulkan masalah baru di tempat yang berbeda dan tidak
terduga. Penggunaan strategi yang diperlukan meningkatkan kemungkinan efek
riak.
REFACTORING
Selama proses pemahaman programmer menggunakan pengetahuan yang berasal
dari luar teks program yang sebenarnya. Untuk mengilustrasikan fenomena ini,
pertimbangkan teks program dari gambar 14.7.
untuk saya:= 1 ke N Mengerjakan

untuk j:= 1 ke N Mengerjakan
jika A[j, saya] Kemudian
untuk k:= 1 ke N Mengerjakan
jika A[i, k] Kemudian A[j, k]:= benar berakhir jika
enddo
berakhir jika
enddo
enddo
Gambar 14.7 Algoritma Warshall untuk menghitung penutupan transitif suatu graf
Fragmen program pada gambar 14.7 memanipulasi matriks boolean A. Sebelum ini
fragmen dieksekusi matriks akan memiliki nilai tertentu. Matriks dilintasi di
cara yang agak rumit (berpotensi, setiap elemen dikunjungi N kali) dan sekali dalam a
sementara elemen array diatur ke BENAR. Tapi apa fragmen ini berarti? Apa
melakukannya Mengerjakan?
Seorang ahli akan 'mengenali' algoritme Warshall. Algoritma Warshall menghitung
penutupan transitif suatu relasi (grafik). Gagasan 'penutupan transitif', 'hubungan'
dan 'grafik' memiliki arti yang tepat dalam domain pengetahuan tertentu. Jika tidak
mengetahui arti dari gagasan-gagasan ini, engkau belum membuat kemajuan apa pun dalam
pemahaman
algoritma baik.
Pada tingkat abstraksi lainnya, makna fragmen ini dapat dijelaskan
sebagai berikut. Misalkan kita mulai dengan kumpulan kota.
A
Relasi
prosedur A(dulu x: w);

mulai b(y, n1);
b(x, n2);
m(w[x]);
y:= x;
r(p[x])
akhir;
Gambar 14.8 Fragmen kode yang tidak dapat

dipahami
batas jendela lain disorot. Kursor diposisikan di jendela yang sekarang disorot dan
proses jendela itu dimulai ulang. Jika kita menambahkan beberapa komentar pada
rutin, teksnya menjadi cukup mudah untuk diinterpretasikan. Nama dan komentar
yang bermakna bersama-sama menyediakan semantik informal dari kode ini yang
cukup untuk pemahaman yang tepat.
Semantik informal ini melangkah lebih jauh daripada membangun pengetahuan
lokal tentang makna suatu komponen. Pengembang menggunakan konvensi
penamaan juga untuk menemukan jalannya dalam sistem besar. Organisasi sering
meresepkan konvensi penamaan justru karena alasan ini. Ketika dokumentasi
desain dan arsitektur tidak diperbarui, konvensi penamaan ini berfungsi sebagai
proxy untuk dokumentasi tersebut.
prosedur mengubah jendela(dulu nw: jendela);

mulai perbatasan (saat ini jendela, tidak menyorot);
perbatasan (nw, sorot);
bergerak kursor(w[nw]);
saat ini jendela:= nw;
resume(proses[nw])
akhir;
Gambar 14.9 Penggalan kode dengan nama yang

bermakna
Umum untuk dua contoh ini serta anekdot altimeter dari bagian 14.2 adalah yang
kita butuhkan di luar informasi untuk interpretasi yang tepat dari fragmen kode.
Informasi luar menyangkut konsep dari domain pengetahuan tertentu atau alasan
desain yang hanya ada di kepala pemrogram.
Contoh manajemen jendela adalah ilustrasi untuk alasan lain. Alat memanipulasi
urutan simbol. Pada prinsipnya, alat tidak memiliki pengetahuan tentang makna
(eksternal) dari simbol yang dimanipulasi. Secara khusus, alat rekayasa balik tidak
memiliki pengetahuan tentang 'jendela', 'kursor', dan sejenisnya. Gagasan ini
REFACTORING
memperoleh maknanya dari domain aplikasi, bukan dari teks program itu sendiri.
Dari sudut pandang alat, teks dari gambar 14.8 dan 14.9 sama-sama bermakna.
Pengamatan di atas berdampak pada sejauh mana alat dapat mendukung rekayasa
balik dan restrukturisasi proses. Alat semacam itu tidak dapat mengubah sistem
yang dirancang dengan buruk menjadi sistem yang baik. Mereka tidak dapat
menyimpulkan pengetahuan dari teks sumber yang belum terkandung dalam teks itu
tanpa menggunakan pengetahuan eksternal sebagai bantuan. Secara khusus,
pemulihan desain yang sepenuhnya otomatis tidak dapat dilakukan. Anda tidak bisa
membuat babi dari sosis.
14.3.3 Peralatan
Selama proses reverse engineering, programmer membangun pemahaman tentang
apa yang coba dicapai oleh perangkat lunak dan mengapa hal-hal dilakukan dengan
cara yang sama. Beberapa kelas alat dapat mendukung tugas pemahaman
program:
�
�
14.4. EVOLUSI PERANGKAT LUNAK 479
DIKUNJUNGI
pada informasi dari masa lalu. Misalnya, kami dapat memutuskan komponen mana yang akan
merekayasa ulang dengan melihat komponen yang banyak berubah di masa lalu. Itu
asumsi kemudian adalah bahwa komponen yang banyak berubah di masa lalu, kemungkinan besar
untuk berubah dalam waktu dekat juga. Gˆırba et al. (2004) menggunakan istilah tersebut cuaca kemarin
ke
mencirikan gagasan ini: jika kita tidak memiliki informasi lebih lanjut, kita dapat menebaknya hari ini
cuaca akan seperti kemarin.
Gˆırba dan Ducasse (2006) membedakan dua jenis analisis evolusioner
data: analisis berpusat pada versi Dan analisis yang berpusat pada sejarah. Berpusat pada versi
analisis, perbedaan antara versi sistem yang berurutan dipelajari. Hasil
biasanya digambarkan dalam gambar dengan waktu (yaitu versi yang berurutan) sepanjang satu sumbu
dan aspek yang relevan dari sistem yang lain. Sebagai contoh, kita dapat mempertimbangkan
ukuran relatif dari komponen yang berbeda dari sistem dari waktu ke waktu, seperti yang diilustrasikan
dalam
gambar 14.10 (diadaptasi dari (Gˆırba dan Ducasse, 2006)).
komponen
1 2 3 4 5 versi
Gambar 14.10 Ukuran versus versi
Setiap persegi panjang pada gambar 14.10 menunjukkan sebuah komponen. Lebar
dan tinggi persegi panjang masing-masing berdiri untuk atribut komponen itu.
Misalnya, lebar menunjukkan jumlah kelas komponen, sedangkan tinggi
menunjukkan jumlah antarmuka. Gambar 14.10 memberitahu kita bahwa komponen
A stabil dan kecil,
sedangkan komponen D stabil dan besar. Komponen C menunjukkan pertumbuhan
yang stabil dari satu versi ke versi berikutnya, dan komponen B menunjukkan
beberapa efek riak di versi 2 dan 3, dan stabil sejak saat itu.
Dalam analisis yang berpusat pada sejarah, sudut pandang tertentu dipilih, dan
evolusi suatu sistem digambarkan sehubungan dengan sudut pandang tersebut.
Misalnya, gambar 14.11 menunjukkan seberapa sering komponen yang berbeda
diubah secara bersamaan. Setiap simpul menunjukkan komponen, dan ketebalan
tepi menunjukkan seberapa sering dua komponen yang terhubung diubah bersama
(disebut perubahan bersama). Tepi yang lebih tebal di antara komponen
menunjukkan perubahan bersama yang lebih sering. Informasi terakhir mungkin
misalnya berasal dari basis data versi.
alur kerja/utama
utilitas / ara alur kerja / gambar
utilitas/alat alur kerja/cat
Gambar 14.11 Komponen yang berubah secara

bersamaan
Dari gambar 14.11 kita mempelajari komponen-komponen tersebut /util/figs Dan

/util/alat sering diganti bersama. Hal yang sama berlaku untuk komponen /util/alat
Dan / alur kerja / cat. Nama-nama komponen menunjukkan bahwa komponen
/util/figs Dan/util/alat terkait secara struktural, sementara /util/alat Dan /alur kerja/cat
secara struktural tidak berhubungan. Dari informasi tambahan ini, kita dapat
menyimpulkan bahwa interaksi antar komponen /util/alat Dan /alur kerja/cat layak
mendapat perhatian kita. Alternatifnya, kita dapat melabeli komponen dengan fitur
(eksternal) yang mereka ikuti, dan tampilan kemudian menunjukkan apakah
perubahan sering memengaruhi fitur yang berbeda. Analisis berpusat pada versi
menggambarkan informasi versi apa adanya. Terserah pengguna untuk mendeteksi
pola apa pun. Pada gambar 14.10, penggunalah yang harus mendeteksi komponen
yang tumbuh atau menyusut; gambar hanya menyajikan fakta. Di pusat sejarah
14.5. MASALAH ORGANISASI DAN 481
MANAJERIAL
analisis, beberapa hipotesis memandu representasi, dan polanya kemudian dikodekan
dalam representasi, seperti pada gambar 14.11.
14.5 Masalah Organisasi dan

Manajerial
Tugas manajemen pemeliharaan tidak berbeda dengan fungsi organisasi lainnya,
dan pengembangan perangkat lunak pada khususnya. Dalam bab 2, kami
mengidentifikasi lima entitas yang memerlukan perhatian terus-menerus dari
manajemen:
– waktu, yaitu kemajuan menuju tujuan;
– informasi, khususnya integritas dari kumpulan dokumen yang lengkap,

termasuk permintaan perubahan;
– organisasi tim, termasuk koordinasi kegiatan;
– kualitas produk dan proses;
– uang, yaitu biaya proyek.
Pada bagian ini kami membahas masalah ini dari perspektif pemeliharaan. Kami
memberikan perhatian khusus pada masalah yang menimbulkan masalah dan
tantangan khusus untuk pemeliharaan. Isu-isu ini adalah: organisasi kegiatan
pemeliharaan, perbedaan utama antara pengembangan dan pemeliharaan,
pengendalian tugas pemeliharaan, dan penilaian kualitas.
14.5.1 Organisasi Kegiatan Pemeliharaan

Pertanyaan utama yang akan dibahas di sini adalah apakah pemeliharaan perangkat lunak atau tidak
harus ditugaskan ke unit organisasi yang terpisah. Pembahasan berikut ini sebagian besar
berdasarkan studi mendalam tentang berbagai bentuk departementalisasi staf sistem
disajikan dalam (Swanson dan Beath, 1990). Penulis artikel ini mengeksplorasi
kekuatan dan kelemahan dari tiga basis alternatif untuk departementalisasi staf. Itu
tiga bentuk organisasi dengan kekuatan dan kelemahan utama mereka terdaftar
gambar 14.12. Kami akan membuat sketsa organisasi Tipe-W dan A dan mendiskusikan tipe-L
organisasi dengan pro dan kontra lebih rumit.
Secara tradisional, departementalisasi dalam pengembangan perangkat lunak cenderung sesuai
ke tipe kerja (skema W-Type). Dalam skema seperti itu, orang menganalisis kebutuhan pengguna,
atau merancang sistem, atau mengimplementasikannya, atau mengujinya, dll. Meskipun mereka bekerja
sama
dalam sebuah tim, setiap anggota tim memiliki tanggung jawab dan peran yang cukup terpisah.
Dalam skema W-Type, penugasan kerja dapat berasal dari kedua pengembangan tersebut
dan proyek pemeliharaan. Misalnya, seorang desainer mungkin terlibat dalam desain a
(sub)sistem dalam konteks beberapa proyek pembangunan atau dalam rancangan perubahan
ke sistem yang ada. Demikian juga, seorang programmer dapat mengimplementasikan algoritma untuk
yang baru
sistem atau menyadari perubahan dalam program operasional.
W-TipeA-TipeL-Tipe
Departementalisasi menurut jenis pekerjaan
(analisis versus pemrograman)
Kekuatan fokus: pengembangan dan spesialisasi
pemrograman
pengetahuan dan kemampuan
Kelemahan fokus: biaya koordinasi antara analis
sistem dan
programmer
Departementalisasi berdasarkan domain aplikasi
(grup aplikasi A
versus grup aplikasi B)
pengetahuan aplikasi
tepian
Kelemahan fokus: biaya koordinasi dan integrasi
antar aplikasi
kelompok kation
Departementalisasi menurut fase siklus hidup
(pengembangan versus pemeliharaan
sewa)
orientasi pelayanan
dan keterampilan pemeliharaan
Kelemahan fokus: biaya koordinasi antara
pengembangan dan
unit pemeliharaan
Gambar 14.12 Pertukaran antara bentuk organisasi alternatif (Sumber: E.B.

Swanson & C.M. Beath, Departementalisasi dalam pengembangan dan
pemeliharaan perangkat lunak, Komunikasi ACM 33, 6 (1990) hlm 658-667.
Direproduksi dengan izin dari Association for ComputingMachinery, Inc.)
Perhatikan bahwa pengembangan sistem baru tidak terjadi dalam ruang hampa.
Perancang sistem baru akan menggunakan kembali desain yang ada dan harus
mempertimbangkan kendala yang ditimbulkan oleh sistem yang ada. Pemrogram
yang terlibat dalam proyek pengembangan harus berurusan dengan antarmuka ke
perangkat lunak yang ada, basis data yang ada, dll. Dalam skema Tipe-W,
perbedaan antara pekerjaan pengembangan dan pemeliharaan terutama
merupakan perbedaan antara berbagai asal dari penugasan kerja.
Bentuk kedua dari departementalisasi adalah sesuai dengan bidang aplikasinya,
yaitu skema Tipe-A. Saat ini, aplikasi terkomputerisasi telah merambah hampir ke
seluruh pelosok perusahaan. Sistem menjadi lebih beragam. Keahlian domain
aplikasi telah menjadi semakin penting untuk keberhasilan implementasi sistem
informasi. Pengetahuan mendalam tentang domain aplikasi adalah sumber daya
yang berharga tetapi langka. Memelihara keahlian ini di antara staf adalah salah
satu cara untuk meningkatkan kualitas dan produktivitas baik dalam pengembangan
maupun pemeliharaan. Oleh karena itu, dalam organisasi yang lebih besar, kami
dapat menemukan unit dengan keahlian khusus dalam domain aplikasi tertentu,
seperti sistem keuangan, otomatisasi kantor, atau kontrol proses waktu nyata.
Akhirnya, kita dapat melakukan departementalisasi menurut fase siklus hidup,
seperti yang dilakukan dalam skema Tipe-L. Secara khusus, kita dapat
membedakan antara pembangunan
MANAJERIAL
dan pemeliharaan. Dengan meningkatnya portofolio sistem yang harus dipertahankan dan
kebutuhan bisnis yang semakin meningkat untuk menjaga basis sistem informasi yang terus
berkembang
bekerja dengan memuaskan, pembagian pengembangan dan pemeliharaan menjadi terpisah
unit organisasi lebih sering ditemukan.
Memisahkan pengembangan dan pemeliharaan memiliki kelebihan dan kekurangan.
Keuntungan utamanya adalah:
�
perhatian manajerial yang tepat untuk pekerjaan pemeliharaan sangat
membantu mengurangi masalah moral. Misalnya, sebuah organisasi dapat
memutuskan untuk mempekerjakan orang baru dalam pengembangan saja
dan secara eksplisit mempertimbangkan transfer ke pemeliharaan sebagai
promosi. (Sebagian besar organisasi melakukan sebaliknya.)
�
14.5. MASALAH ORGANISASI DAN MANAJERIAL 485
14.5.2 Pemeliharaan
Perangkat Lunak dari
Perspektif Layanan
Organisasi pemeliharaan perangkat lunak perlu menyadari bahwa mereka berada dalam
layanan pelanggan
bisnis.
(Pigoski, 1996)
Pengembangan perangkat lunak menghasilkan produk, perangkat lunak. Pemeliharaan perangkat lunak
dapat dilihat sebagai penyediaan layanan. Ada perbedaan mencolok antara produk dan
layanan, yang berarti bahwa kualitas produk dan layanan dinilai berbeda.
Akibatnya, kualitas pengembangan perangkat lunak dan pemeliharaan perangkat lunak
juga dinilai berbeda dan organisasi pemeliharaan harus memperhatikan
aspek kualitas spesifik layanan.
Ternyata, hal ini belum banyak diketahui. Dalam pemeliharaan perangkat lunak
domain, fokusnya masih pada aspek produk. Tahap akhir dari pengembangan perangkat lunak
seharusnya menyangkut pengiriman manual operasi, menginstal perangkat lunak,
menangani permintaan perubahan dan memperbaiki bug. Dalam praktiknya, peran departemen TI
adalah
jauh lebih luas selama tahap penyebaran, seperti yang diilustrasikan oleh bantuan di mana-mana
meja.
Hal ini dikonfirmasi oleh St˚alhane et al. (1997) yang melaporkan survei untuk menemukannya
aspek kualitas perangkat lunak yang dianggap paling penting oleh pelanggan. Wawasan utama
yang akan diperoleh dari studi mereka adalah penekanan kuat pelanggan pada layanan
kualitas. Lima faktor teratas yang ditemukan dalam penelitian mereka adalah: ketanggapan layanan,
layanan
kapasitas, keandalan produk, efisiensi layanan, dan fungsionalitas produk. Mereka juga
mengutip hasil yang menarik dari studi berkualitas di domain telekomunikasi.
Untuk pertanyaan ‘Apakah Anda akan merekomendasikan orang lain untuk membeli dari perusahaan
ini?’, a
100% ya diperoleh dari kategori pengguna yang pernah mengeluh dan mendapat a
hasil yang memuaskan. Untuk kategori yang tidak mengeluh, persentasenya adalah
87%. Ternyata, lebih penting mendapatkan pelayanan yang memuaskan daripada tidak
masalah sama sekali.
Perbedaan utama antara produk dan layanan adalah sebagai berikut:
�
�
MANAJERIAL
pelanggan. Kualitas bauran produk-layanan semacam itu dinilai dari kedua produk
dan aspek pelayanan: apakah makanannya enak dan disajikan dengan cepat.
Mari kita kembali ke domain rekayasa perangkat lunak. Perbedaan utama antara
pengembangan perangkat lunak dan pemeliharaan perangkat lunak adalah fakta bahwa pengembangan
perangkat lunak
menghasilkan a produk, sedangkan pemeliharaan perangkat lunak menghasilkan a melayani sedang
dikirim
kepada pelanggan. Pemeliharaan perangkat lunak memiliki lebih banyak aspek seperti layanan daripada
perangkat lunak
pengembangan, karena nilai pemeliharaan perangkat lunak terletak pada aktivitas yang dihasilkannya
dalam manfaat bagi pelanggan, seperti kesalahan yang diperbaiki dan fitur baru. Kontras
ini dengan pengembangan perangkat lunak, di mana kegiatan pengembangan itu sendiri tidak
memberikan manfaat kepada pelanggan. Ini adalah sistem perangkat lunak yang dihasilkan yang
menyediakan
manfaat tersebut.
Sebagaimana dicatat, perbedaan antara produk dan layanan tidak jelas. Menipu-
secara berurutan, ini juga berlaku untuk pengembangan perangkat lunak dan pemeliharaan perangkat
lunak.
Gambar 14.14 menunjukkan rangkaian produk-layanan dengan contoh-contoh dari perangkat lunak
domain rekayasa.
Gambar 14.14 Kontinum layanan produk untuk pengembangan dan pemeliharaan perangkat lunak
nance
Pemasar jasa sering menggunakan model kesenjangan untuk mengilustrasikan

bagaimana perbedaan antara penyampaian jasa yang dirasakan dan jasa yang
diharapkan dapat terjadi. Model gap ini digambarkan pada gambar 14.15. Kualitas
layanan ditingkatkan jika celah tersebut ditutup. Adanya perbedaan persepsi kualitas
dengan kualitas yang diharapkan (gap 5) disebabkan oleh empat gap lainnya.
Keempat kesenjangan ini, dan solusi yang disarankan untuk menjembataninya,
adalah:
Gap 1 Layanan yang diharapkan seperti yang dirasakan oleh penyedia layanan
berbeda dengan pelayanan yang diharapkan oleh pelanggan. Di bidang
pemeliharaan perangkat lunak, perbedaan ini sering disebabkan oleh
kurangnya fokus hubungan penyedia layanan. Sebagai contoh, departemen
pemeliharaan mungkin bertujuan untuk memenuhi batasan ketersediaan
tertentu seperti ketersediaan 99%, sedangkan perhatian pelanggan
sebenarnya adalah dengan downtime maksimum.
MANAJERIAL
tidak sesuai dengan persyaratan layanan seperti yang dirasakan oleh
penyedia layanan. Misalnya, pelanggan mengharapkan sistem dimulai ulang
dengan cepat, sementara prosedur standar organisasi pemeliharaan
difokuskan pada analisis alasan kerusakan tersebut.
Kegiatan pemeliharaan sebagaimana ditentukan dalam perjanjian tingkat
layanan harus direncanakan. Ini termasuk perencanaan aktivitas itu sendiri,
transfer hasil ke pelanggan, perencanaan rilis, estimasi sumber daya yang
dibutuhkan, penjadwalan aktivitas pemeliharaan, dan identifikasi risiko yang
mungkin terjadi. Secara eksplisit mendasarkan perencanaan kegiatan
pemeliharaan pada komitmen yang disepakati dengan pelanggan membantu
menutup kesenjangan ini.
Kesenjangan 3 Penyampaian layanan yang sebenarnya berbeda dari layanan yang

ditentukan. Hal ini sering disebabkan oleh kekurangan dalam kebijakan sumber
daya manusia, kegagalan untuk mencocokkan permintaan dan penawaran, dan
pelanggan tidak memenuhi peran mereka. Misalnya, pelanggan dapat melewati
helpdesk dengan menelepon pengelola sistem mereka secara langsung, sehingga
menghambat proses manajemen insiden yang tepat.
Perjanjian tingkat layanan menyatakan kegiatan pemeliharaan mana yang
harus dilakukan, dan seberapa cepat, andal, dll. hal ini harus dilakukan.
Untuk dapat melaporkan kinerja organisasi pemeliharaan dalam hal ini,
informasi tentang kegiatan pemeliharaan yang sebenarnya harus
dikumpulkan. Informasi ini dapat digunakan untuk memantau aktivitas
perawatan dan mengambil tindakan korektif jika diperlukan.
Misalnya, saat pelanggan melaporkan bug, informasi tentang bug itu sendiri
(asal, jenis, dll.) dicatat, serta waktu pelaporan, waktu saat tindakan korektif
dimulai dan diakhiri, dan waktu saat bug dilaporkan telah diperbaiki. . Jika
data ini menunjukkan bahwa rata-rata downtime dari sistem melebihi tingkat
yang ditentukan dalam perjanjian tingkat layanan, organisasi pemeliharaan
dapat menugaskan lebih banyak staf pemeliharaan untuk sistem ini,
menempatkan staf pemeliharaan di lokasi pelanggan, menegosiasikan ulang
tingkat layanan yang disepakati, atau mengambil tindakan lain untuk
menyelaraskan kembali kesepakatan dan kenyataan.
Dengan mengawasi secara ketat kinerja organisasi pemeliharaan dan
menyesuaikan perencanaan pemeliharaan atau menegosiasikan ulang
komitmen dengan pelanggan bila diperlukan, celah 3 dipersempit.
Gap 4 Komunikasi tentang layanan tidak sesuai dengan penyampaian layanan yang
sebenarnya. Hal ini dapat disebabkan oleh pengelolaan harapan pelanggan yang
tidak efektif, terlalu banyak menjanjikan, atau komunikasi horizontal yang tidak
efektif. Misalnya, pelanggan tidak diberitahu tentang perbaikan bug yang dia
laporkan.
Instrumen penting untuk membantu menutup celah ini adalah manajemen
acara. Manajemen acara menyangkut pengelolaan acara yang
menyebabkan atau mungkin menyebabkan kegiatan pemeliharaan yang
dilakukan menyimpang dari tingkat yang dijanjikan.
dalam perjanjian tingkat layanan. Suatu peristiwa dapat berupa permintaan
perubahan, seperti permintaan pengguna untuk fitur baru, atau insiden.
Insiden adalah bug perangkat lunak dan bahaya lain yang telah dijanjikan
oleh organisasi pemeliharaan untuk ditangani, seperti, katakanlah, server
mati.
Tujuan utama manajemen acara adalah untuk mengelola semua acara
tersebut. Untuk melakukannya, sistem perpustakaan manajemen acara
digunakan, seringkali dalam bentuk 'sistem helpdesk'. Sistem perpustakaan
manajemen acara menyediakan penyimpanan, pembaruan, dan
pengambilan catatan acara, dan berbagi dan mentransfer catatan acara
antara pihak yang terlibat. Sistem perpustakaan manajemen acara ini
mendukung komunikasi dengan pelanggan tentang layanan pemeliharaan
yang disampaikan. Ini juga merupakan 'memori' yang sangat berharga bagi
para pengelola: mereka mungkin menggunakan perpustakaan acara untuk
mencari insiden serupa, untuk melihat mengapa komponen tertentu diubah
sebelumnya, dll.4
Karena gap kelima disebabkan oleh empat gap lainnya, persepsi kualitas layanan
dapat ditingkatkan dengan menutup keempat gap pertama tersebut, sehingga
membawa persepsi kualitas sejalan dengan kualitas yang diharapkan. Karena
organisasi pemeliharaan perangkat lunak pada dasarnya adalah penyedia layanan,
mereka perlu mempertimbangkan masalah di atas. Mereka perlu mengelola produk
mereka -- pemeliharaan perangkat lunak -- sebagai layanan agar dapat memberikan
kualitas tinggi.
14.5.3 Pengendalian Tugas Pemeliharaan

Kontrol produk yang hati-hati diperlukan selama pengembangan perangkat lunak.
Sejumlah besar informasi harus tetap terkendali. Dokumentasi harus tetap konsisten
dan up-to-date. Skema yang sesuai untuk melakukannya disediakan oleh rangkaian
prosedur yang menyusun kontrol konfigurasi; lihat bab 4. Kontrol konfigurasi
memberi perhatian khusus pada penanganan permintaan perubahan. Karena
menangani permintaan perubahan adalah inti dari pemeliharaan, kontrol konfigurasi
sangat penting selama pemeliharaan.
Pemeliharaan yang efektif bergantung pada metodologi yang ketat, tidak hanya
sehubungan dengan penerapan perubahan yang disepakati, tetapi juga sehubungan
dengan cara pengendalian perubahan. Mengikuti Standar IEEE 1219, kami
menyarankan proses berikut yang terdokumentasi dengan baik untuk
mengendalikan perubahan selama pemeliharaan:
1. Mengidentifikasi dan mengklasifikasikan permintaan perubahan Setiap
permintaan perubahan (CR) diberikan nomor identifikasi unik dan diklasifikasikan
ke dalam salah satu kategori pemeliharaan (korektif, adaptif, perfeksitif,
preventif). CR dianalisis untuk memutuskan apakah akan diterima, ditolak, atau
perlu evaluasi lebih lanjut. Analisis ini juga menghasilkan perkiraan biaya
pertama. CR akhirnya diprioritaskan dan dijadwalkan untuk implementasi.
4Perhatikan bahwa fokus sistem perpustakaan manajemen acara agak berbeda dari manajemen konfigurasi
seperti yang dibahas di bagian selanjutnya. Manajemen konfigurasi menekankan pada intern penggunaan
informasi tentang permintaan perubahan dan sejenisnya. Deskripsi kami tentang manajemen acara berfokus
padaluar penggunaan informasi yang pada dasarnya sama. Dalam praktiknya, kedua proses tersebut
mungkin digabungkan.
MANAJERIAL
2. Analisis permintaan perubahan Langkah ini dimulai dengan analisis CR
untuk menentukan dampaknya terhadap sistem, organisasi, dan kemungkinan
sistem antarmuka. Beberapa solusi alternatif untuk mengimplementasikan CR
dapat dirancang, termasuk biaya dan jadwalnya. Hasil analisis didokumentasikan
dalam laporan. Berdasarkan laporan ini, keputusan dibuat apakah CR akan
dilaksanakan atau tidak. Otoritas untuk keputusan ini biasanya ditugaskan ke
papan kontrol konfigurasi; lihat juga bab 4.
3. Menerapkan perubahan Ini melibatkan desain, implementasi dan pengujian

perubahan. Keluaran dari langkah ini adalah versi baru dari sistem, teruji
sepenuhnya, dan didokumentasikan dengan baik.
Langkah-langkah di atas menunjukkan model pemeliharaan di mana setiap

permintaan perubahan dianalisis secara hati-hati dan, jika (dan hanya jika)
permintaan disetujui, implementasinya dilakukan dengan cara yang teratur dan
disiplin, termasuk pembaruan dokumentasi yang tepat. Skema kontrol ini sangat
cocok dengan iteratif-peningkatanmodel pemeliharaan perangkat lunak; lihat
gambar 14.16. Inti dari model iterative-enhancement adalah bahwa kumpulan
dokumen dimodifikasi mulai dari dokumen tingkat tertinggi yang terpengaruh oleh
perubahan, menyebarkan perubahan ke bawah melalui kumpulan dokumen
lengkap. Misalnya, jika permintaan perubahan memerlukan perubahan desain, maka
desain akan diubah terlebih dahulu. Hanya sebagai konsekuensi dari perubahan
desain, kode akan diadaptasi.
Gambar 14.16 Iteratif-peningkatan model pemeliharaan perangkat lunak (Sumber:

V.R.
Basili, Melihat pemeliharaan sebagai pengembangan perangkat lunak berorientasi penggunaan ulang,
Perangkat Lunak IEEE 7, 1 (1990)
19--25, 1990 IEEE.)
Realitas seringkali berbeda. Gambar 14.17 menggambarkan apa yang disebut
perbaikan cepat model pemeliharaan perangkat lunak. Dalam model perbaikan
cepat, Anda mengambil kode sumber, membuat perubahan yang diperlukan pada
kode dan mengkompilasi ulang sistem untuk mendapatkan versi baru. Dokumentasi
kode sumber dan dokumen tingkat tinggi lainnya diperbarui setelah kode diperbaiki,
dan biasanya hanya jika waktu mengizinkan.
Gambar 14.17 Model perbaikan cepat pemeliharaan perangkat lunak (Sumber: V.R.
Basili, Melihat pemeliharaan sebagai pengembangan perangkat lunak berorientasi
penggunaan ulang, Perangkat Lunak IEEE 7, 1 (1990) 19--25, 1990IEEE.)
Dalam skema yang terakhir, tambalan dibuat di atas tambalan dan struktur
sistem menurun dengan cepat. Karena hasil peningkatan kompleksitas sistem dan
inkonsistensi dokumen, pemeliharaan masa depan menjadi jauh lebih sulit. Agar
realistis, model perbaikan cepat tidak dapat sepenuhnya dielakkan. Dalam situasi
darurat, hanya ada satu hal yang penting: mengaktifkan dan menjalankan kembali
sistem secepat mungkin. Namun jika memungkinkan, model perbaikan cepat harus
dihindari. Jika digunakan sama sekali, kegiatan pemeliharaan preventif harus
dijadwalkan untuk memperbaiki kerusakan struktural yang dilakukan.
Dalam situasi normal dan non-darurat, permintaan perubahan sering
digabungkanrilis. Pengguna kemudian tidak mendapatkan versi baru setelah setiap
perubahan direalisasikan, tetapi setelah sejumlah permintaan perubahan ditangani,
atau setelah jangka waktu tertentu. Tiga cara umum untuk memutuskan konten dan
waktu rilis berikutnya adalah:
�
MANAJERIAL
adalah beberapa fleksibilitas untuk konten rilis berikutnya, sejak pengelola
dan pelanggan tidak memperbaiki isinya terlebih dahulu.
�
�
Pemeliharaan yang sempurna terutama berkaitan dengan mengakomodasi pengguna baru atau yang
diubah
persyaratan.
Pemeliharaan preventif menyangkut kegiatan yang ditujukan untuk meningkatkan pemeliharaan sistem
kemampuan.
Pemeliharaan 'nyata', koreksi kesalahan, menghabiskan sekitar 25% dari pemeliharaan

upaya keuangan. Sejauh ini, sebagian besar pemeliharaan perangkat lunak berkaitan dengan evolusi
perangkat lunak. Evolusi ini tidak bisa dihindari. Model perangkat lunak bagian dari kenyataan. Realitas
berubah, begitu pula perangkat lunak yang memodelkannya.
Penyebab utama masalah pemeliharaan dibahas di bagian 14.2: keberadaan
tence dari sejumlah besar kode tidak terstruktur, pengetahuan yang tidak memadai tentang
domain sistem atau aplikasi pada bagian pemrogram pemeliharaan, tidak mencukupi
dokumentasi, dan citra buruk departemen pemeliharaan perangkat lunak.
Beberapa dari masalah ini tidak disengaja dan dapat diatasi dengan tindakan yang tepat.
Melalui organisasi yang lebih baik dan pengelolaan pemeliharaan perangkat lunak, substansial
peningkatan kualitas dan produktivitas dapat terwujud. Masalah-masalah ini dibahas
di bagian 14.5. Jelas, pemeliharaan yang lebih baik harus dimulai dengan pengembangan yang lebih
baik.
pilihan. Peluang untuk meningkatkan proses pengembangan adalah topik utama di sebagian besar
bab dari buku ini.
Masalah yang sangat relevan untuk pemeliharaan perangkat lunak adalah rekayasa balik
ing, proses merekonstruksi cetak biru yang hilang. Sebelum perubahan dapat diwujudkan, the
pengelola harus mendapatkan pemahaman tentang sistem. Karena mayoritas opera-
kode nasional tidak terstruktur dan tidak berdokumen, ini adalah masalah besar. Bagian 14.3
mengatasi rekayasa balik, keterbatasannya, dan alat untuk mendukungnya.
Masalah mendasar adalah pemeliharaan akan tetap menjadi masalah besar. Karena
perubahan yang dilakukan pada perangkat lunak, strukturnya menurun. Perhatian khusus untuk
pencegahan
kegiatan pemeliharaan yang ditujukan untuk memperbaiki struktur sistem diperlukan dari waktu ke waktu
waktu untuk melawan entropi sistem.
Pemeliharaan perangkat lunak biasanya menjadi topik yang agak diabaikan dalam perangkat lunak
literatur teknik. Seperti programmer, peneliti lebih tertarik untuk mengembangkan
metode dan alat baru yang mewah untuk pengembangan perangkat lunak. Situasi ini telah berubah.
Jurnal-jurnal besar secara berkala menampilkan artikel tentang pemeliharaan perangkat lunak, ada yang
tahunan
Konferensi IEEE tentang Pemeliharaan Perangkat Lunak (sejak 1985), dan jurnal Perangkat lunak
Pemeliharaan dan Evolusi: Penelitian dan Praktek (diluncurkan 1989) sepenuhnya dikhususkan untuk
itu.

(Pigoski, 1996) adalah buku teks yang sepenuhnya dikhususkan untuk
pemeliharaan perangkat lunak. Lientzand Swanson (1980) adalah buklet penting
tentang pemeliharaan perangkat lunak. Ini memperkenalkan kategori tugas
pemeliharaan yang dikenal luas dan menyediakan data tentang distribusinya. Data
yang lebih baru tentang distribusi tugas pemeliharaan diberikan dalam (Nosek dan
Palvia, 1990), (Dekleva, 1992) dan (Sousa dan Mozeira, 1998). Chapin et al. (2001)
memberikan klasifikasi baru kategori pemeliharaan, termasuk kategori tersendiri
untuk dukungan pengguna. Tahapan siklus hidup pemeliharaan dibahas dalam
(Burch dan Kung, 1997) dan (Kung dan Hsu, 1998). Perbedaan antara tahap evolusi
dan tahap pelayanan berasal dari (Bennett dan Rajlich, 2000). Distribusi kegiatan
pemeliharaan terkait kode dibahas dalam (Yu dan Chen, 2006). Praktik
pemeliharaan perangkat lunak dibahas dalam (Singer, 1998) dan (Tan dan Gable,
1998). Berbagai jenis reverse engineering dibahas dalam (Chikofsky dan Cross
II,1990). Masalah kesetaraan fungsional 100% dalam rekayasa balik dibahas dalam
(Bennett, 1998). Alat rekayasa balik dibahas dalam (Biggerstaff et al., 1994),
(Jarzabek dan Wang, 1998) dan (Bellay dan Gall, 1998). Fowler (1999) adalah teks
standar untuk refactorinig. Mens dan Tourwé (2004) memberikan survei tentang
pemfaktoran ulang perangkat lunak. Migrasi dibahas dalam (Rahgozar dan
Oroumchian, 2003) dan (Bisbalet al., 1999). Rencana pemrograman dan suar
awalnya diusulkan di (Solowayand Ehrlich, 1984) dan (Brooks, 1983). Penelitian
yang membahas peran konsep-konsep ini dalam proses pemahaman program
dijelaskan dalam (von Mayrhauser dan Vans, 1995) dan (von Mayrhauser et al.,
1997). La Toza dkk. (2006) membahas kebiasaan kerja pengembang, termasuk
pemahaman kode, selama pengembangan dan evolusi. Contoh alat untuk
membantu pemeliharaan perangkat lunak meliputi (Singer et al., 2005) (mendukung
penelusuran melalui perangkat lunak), (Rysselberghe dan Demeyer, 2004)
(memvisualisasikan riwayat perubahan) dan (Ducasse et al., 2006)
(memvisualisasikan distribusi properti sistem) .
Gˆırba dan Ducasse (2006) memberikan gambaran tentang jenis analisis evolusi
perangkat lunak. Perbedaan antara analisis yang berpusat pada versi dan yang
berpusat pada sejarah dibuat dalam artikel itu. Gˆırba et al. (2004) membahas
pendekatan 'cuaca kemarin' untuk membalikkan rekayasa. Fischer dan Gall (2004)
dan Greevy et al. (2006) membahas analisis yang berpusat pada sejarah.
Kemungkinan organisasi kegiatan pemeliharaan serta kelebihan dan kekurangan
utama dibahas dalam (Swanson dan Beath, 1990). Yeh dan Jeng (2002) membahas
pengaruh departementalisasi pada pemeliharaan perangkat lunak. Perspektif
layanan pada pemeliharaan perangkat lunak didiskusikan dalam (Niessink dan van
Vliet, 1999). Terjemahannya menjadi Model Kematangan Kemampuan yang
ditujukan untuk proses pemeliharaan dijelaskan dalam (Niessink dan van Vliet,
1998a).
Model Proses IEEE untuk pemeliharaan perangkat lunak dijelaskan dalam
(IEEE1219,1992). Iteratif-peningkatan dan perbaikan cepat model pemeliharaan
perangkat lunak dibahas dalam (Basili, 1990). Pendekatan penjadwalan rilis adalah
topik (Starkand Oman, 1997).
Biaya pemeliharaan perangkat lunak, dan hubungan empiris antara aspek
kualitas dan biaya adalah topik dari (Banker et al., 1993), (Kemerer dan Slaughter,
1997), (Henryand Cain, 1997) dan (Niessink dan van Vliet, 1997). Indikator
degradasi sistem diberikan dalam (Martin dan Osborne, 1983).
Latihan
1. Definisikan istilah-istilah berikut: pemeliharaan korektif, pemeliharaan

adaptif, pemeliharaan perfektif, dan pemeliharaan preventif.
2. Diskusikan penyebab utama masalah pemeliharaan perangkat lunak.
3. Apa itu rekayasa balik?
4. Apa itu refactoring?
5. Mencirikan tahap evolusi dan servis pemeliharaan perangkat lunak.
6. Apa perbedaan antara design recovery dan redocumentation?
7. Mencirikan analisis berorientasi versi dan analisis berpusat pada sejarah

data evolusi perangkat lunak.
8. Mengapa pemeliharaan korektif memiliki lebih banyak aspek seperti layanan daripada
aspek seperti produk?
9. Diskusikan model peningkatan iteratif dan perbaikan cepat dari pemeliharaan perangkat lunak
nance.
10. Diskusikan hambatan utama pemulihan desain otomatis penuh.
11. Diskusikan keuntungan dukungan kontrol konfigurasi perangkat lunak selama perangkat lunak
pemeliharaan.
12. Diskusikan kemungkinan struktur dan peran uji penerimaan oleh

keuangan organisasi sebelum rilis sistem.
13. ~
proses pemeliharaan? Jika tidak, bagaimana pemeliharaan direncanakan dan

dikendalikan?
17. �
15
Alat Perangkat
Lunak
TUJUAN PEMBELAJARAN
�
500 ALAT PERANGKAT LUNAK
Pengembangan perangkat lunak umumnya didukung oleh tools, mulai dari

tools
mendukung satu kegiatan untuk lingkungan yang terintegrasi mendukung
lengkap
proses pengembangan. Dalam bab ini kita membahas kelas utama perangkat
lunak
alat pengembangan dan peran mereka dalam proses pembangunan.
Permintaan perangkat lunak tumbuh lebih cepat daripada peningkatan produktivitas

pengembangan perangkat lunak dan tenaga kerja yang tersedia. Hasilnya adalah
kekurangan personel yang terus meningkat; kami semakin tidak dapat memuaskan
pencarian perangkat lunak. Untuk membalikkan keadaan, kita harus mencari teknik
yang menghasilkan peningkatan produktivitas yang signifikan.
Salah satu rute yang paling jelas untuk dikejar adalah otomatisasi itu sendiri. Kita
dapat menggunakan komputer sebagai alat bantu dalam pembuatan perangkat lunak.
Dulu, segala macam hal diotomatisasi, kecuali pengembangan perangkat lunak itu
sendiri. Pemrogram tahu lebih baik dari itu. Kita sudah lama terbiasa menggunakan
komputer sebagai alat untuk implementasi perangkat lunak. Untuk tujuan ini,
pemrogram memiliki beragam alat yang tersedia, seperti kompiler, penghubung, dan
pemuat. Juga selama pengujian, alat seperti test driver dan test harness telah
digunakan sejak lama. Pengembangan alat untuk mendukung fase awal siklus hidup
perangkat lunak lebih baru. Salah satu contoh yang terakhir adalah perangkat lunak
untuk membantu menggambar dan memvalidasi diagram UML.
Penggunaan alat perangkat lunak mungkin memiliki efek positif pada produktivitas
orang yang terlibat dan kualitas produk yang sedang dikembangkan. Alat dapat
mendukung pemeriksaan kesesuaian dengan standar. Alat dapat membantu
mengukur tingkat pengujian. Alat dapat mendukung pelacakan kemajuan. Dan
seterusnya.
Penerapan alat dalam proses pengembangan perangkat lunak disebut sebagai
Rekayasa Perangkat Lunak Berbantuan Komputer (KASUS). Terlepas dari alat
implementasi dan pengujian tradisional, CASE memiliki sejarah yang relatif singkat.
Alat pertama untuk mendukung aktivitas desain muncul pada awal 1980-an. Saat ini,
jumlah produk CASE sangat banyak.
Karena jumlah produk CASE yang tersedia berkembang biak, menjadi bijaksana
untuk mengklasifikasikannya. Salah satu cara melakukannya adalah sesuai dengan
luasnya dukungan yang mereka tawarkan. Gambar 15.1 memberikan klasifikasi
produk CASE sepanjang dimensi ini. Beberapa produk mendukung tugas tertentu
dalam proses pengembangan perangkat lunak. Lainnya mendukung seluruh proses
perangkat lunak. Yang pertama disebut peralatan, yang terakhir lingkungan. Di
antara dua ekstrem ini, penting untuk mengidentifikasi produk CASE yang
mendukung rangkaian aktivitas terbatas, seperti yang terdiri dari tahapan analisis dan
desain. Seperangkat alat yang koheren dengan ruang lingkup terbatas disebut
sebagai meja kerja. Lingkungan dapat diklasifikasikan lebih lanjut menurut
mekanisme yang mengikat alat individu yang membentuk lingkungan. Di sebuah
toolkit, alat umumnya tidak terintegrasi dengan baik. Dukungan yang ditawarkan
tidak bergantung pada bahasa pemrograman atau paradigma pengembangan
tertentu. Toolkit hanya menawarkan satu set blok bangunan yang berguna. A
lingkungan yang berpusat pada bahasa berisi alat yang secara khusus cocok untuk
mendukung pengembangan perangkat lunak dalam bahasa pemrograman tertentu.
Lingkungan seperti itu dapat dibuat dengan tangan atau dihasilkan dari deskripsi tata
bahasa
501
produk KASUS mendukung
Alat Satu tugas

meja kerja Seperangkat kegiatan terbatas
Lingkungan Seluruh proses perangkat lunak
Perangkat alat
Lingkungan yang berpusat pada bahasa
Lingkungan yang terintegrasi
Lingkungan yang berpusat pada proses
Gambar 15.1 Klasifikasi produk CASE
bahasa. Dalam kasus terakhir, lingkungan cenderung fokus pada manipulasi

dari struktur program.
Inti dari terintegrasi Dan lingkungan yang berpusat pada proses adalah berbagi dari
informasi antara alat-alat yang membentuk lingkungan. lingkungan terintegrasi
fokus pada produk yang dihasilkan. Inti dari lingkungan yang terintegrasi adalah data
repositori, berisi banyak informasi tentang produk yang akan dikembangkan, dari
persyaratan hingga menjalankan kode. Lingkungan yang berpusat pada proses fokus pada berbagi a
menjelaskan proses pengembangan perangkat lunak.
Jelas, tidak mengklasifikasikan produk CASE yang sebenarnya menurut kerangka kerja ini
selalu mudah. Misalnya, banyak lingkungan yang mencakup siklus hidup lengkap
berevolusi dari meja kerja yang mendukung aktivitas front-end (analisis dan
desain global) atau aktivitas back-end (implementasi dan pengujian). Lingkungan ini
cenderung berisi alat yang secara khusus ditujukan untuk mendukung tugas dari yang sesuai
bagian dari siklus hidup, ditambah dengan dukungan yang lebih umum untuk fase lainnya (seperti
seperti untuk pengeditan, pemrosesan teks, atau akses basis data).
Kerangka gambar 15.1 mengklasifikasikan produk CASE menurut bagian-bagiannya
siklus hidup yang mereka dukung. Gambar 15.2 mencantumkan sejumlah dimensi
Produk CASE dapat diklasifikasikan. Menggunakan semua dimensi ini untuk mengklasifikasikan KASUS
produk menghasilkan skema klasifikasi segi, yang menyediakan lebih banyak informasi dan
lebih fleksibel daripada kerangka satu dimensi dari gambar 15.1.
Tidak ada metode pengembangan yang cocok untuk semua kelas masalah. Begitu juga tidak ada
Produk CASE untuk semua kelas masalah. Sifat khusus dari kelas masalah tertentu
akan memengaruhi alat untuk kelas itu. Properti penting dari sistem tertanam adalah
bahwa perangkat lunak sering dikembangkan pada beberapa mesin host yang berbeda
mesin target akhir. Alat khusus akan diperlukan untuk pengembangan
sistem seperti itu, misalnya alat yang memungkinkan kita menguji perangkat lunak pada mesin host.
Dimensi Nilai tipikal
Keluasan Alat, meja kerja, atau lingkungan

dukungan Tertanam, bisnis, waktu nyata, . . .
Kelas masalah Kecil, sedang, atau besar
Ukuran Individu, keluarga, kota, atau negara bagian
sistem
Skal 1, >
a
pen
ggu
na
Jumlah situs
Skala
proses
Dukungan
proses
Paradigma eksekusi
503
banyak kebebasan diserahkan kepada pengembang individu, sementara sejumlah aturan
disepakati untuk mengatur interaksi kritis antara pengembang.
Model ini tidak sesuai lagi jika proyek menjadi sangat besar. Lebih besar
populasi membutuhkan aturan yang lebih rumit dan pembatasan kebebasan individu.
Dalam keluarga saya, beberapa aturan sederhana sudah cukup (Jasper dan Marieke mencuci secara
bergiliran
hidangan), dan penyesuaian serta penyimpangan lokal mudah dilakukan (Jasper mengadakan pesta
hari ini dan meminta Marieke untuk mengambil alih). Dalam sebuah perusahaan besar, kebijakan harus
dipatuhi lebih ketat dan kerjasama antar individu ditegakkan (seperti di kota).
Demikian pula, perangkat untuk mendukung pengembangan sistem besar harus menegakkan
kerjasama yang baik antara masing-masing pengembang.
Sebuah negara dapat dilihat sebagai kumpulan kota. Perusahaan dapat dipandang sebagai a
koleksi proyek. Dalam model negara, perhatian utamanya adalah pada kesamaan dan
standardisasi, untuk memungkinkan pengembang beralih antar proyek, agar dapat digunakan kembali
kode, desain, rencana pengujian, dll.
Jika pengembangan dilakukan di lebih dari satu situs, kami membutuhkan alat untuk memfasilitasi
kolaborasi dan koordinasi. Di satu sisi, alat seperti itu untuk konfigurasi
manajemen dan persyaratan manajemen perlu memberikan dukungan untuk berkoordinasi
pekerjaan pembangunan di beberapa lokasi. Di sisi lain, alat dari ranah
Kerja Koperasi yang Didukung Komputer (CSCW) dapat menjadi bagian dari rangkaian alat.
Dimensi ini juga terkait erat dengan skala pengguna dan dimensi ukuran sistem,
karena proyek yang lebih besar cenderung didistribusikan ke beberapa lokasi; lihat juga bab ??.
Skala proses menentukan apakah produk CASE mendukung produksi kode
aktivitas, aktivitas orang, atau keduanya. Produk CASE berfokus pada produksi kode
berkonsentrasi pada dukungan untuk evolusi perangkat lunak. Mereka berisi alat untuk menulis,
kompilasi, uji, debug, dan konfigurasikan kode. Ini semua adalah aktivitas yang dilakukan oleh komputer.
Produk CASE lainnya berkonsentrasi pada interaksi personel, seperti penjadwalan
dari pertemuan tinjauan. Yang lain lagi melakukan keduanya. Nilai sepanjang sumbu ini dapat disebut
produk, orang, dan produk-dan-orang.
Produk CASE mungkin mendukung atau tidak mendukung pengembangan proses. Jika
pengembangan-
didukung, beberapa alat melakukannya berdasarkan model yang telah ditentukan sebelumnya
proses. Lainnya memungkinkan pengguna untuk menentukan model prosesnya sendiri. Jika produk
KASUS
mendukung proses pembangunan, mungkin mempekerjakan berbagai sarana internal untuk memandu
eksekusi (atau pemberlakuan) proses pengembangan, seperti mesin negara, Petri
jaring, aturan produksi, atau prosedur.
Berbagai pendekatan untuk kumpulan alat perangkat lunak dibahas dalam beberapa bagian
15.1 sampai 15.4, menggunakan skema klasifikasi sederhana dari gambar 15.1. Toolkit adalah
dibahas di bagian 15.1. UNIX adalah contoh utama dari kategori ini. Bagian 15.2
membahas lingkungan yang berpusat pada bahasa. Ini mencakup kedua lingkungan
dibuat secara manual di sekitar beberapa bahasa pemrograman tertentu, dan lingkungan yang
dihasilkan
Dinilai dari deskripsi tata bahasa dari struktur program yang dimanipulasi. Di dalam
kedua kasus, dukungan yang ditawarkan sebagian besar menyangkut programmer individu. Bagian
15.3 dan 15.4 masing-masing membahas lingkungan yang terintegrasi dan berpusat pada proses.
Karena sebagian besar meja kerja dapat dilihat sebagai lingkungan terintegrasi yang dipangkas,
meja kerja juga dibahas di bagian 15.3.
Pembahasan di bawah ini cukup bersifat global. Kami akan membaca sekilas
detail masing-masing alat. Tujuan kami adalah untuk membuat sketsa tren yang
terlihat di area ini dan untuk melihat secara kritis kemungkinan peran alat dalam
proses pengembangan perangkat lunak.
15.1 Toolkit
Dengan toolkit, pengembang didukung oleh kumpulan alat yang agak longgar, yang
masing-masing melayani tugas spesifik yang terdefinisi dengan baik. Analogi
dengan tukang kayu sudah jelas. Perkakasnya berisi palu, obeng, gergaji, dan
sejenisnya. Alat-alat ini masing-masing melayani tugas tertentu. Namun, mereka
tidak 'terintegrasi' seperti bor dan lampirannya.
Contoh utama dari lingkungan toolkit adalah UNIX. UNIX dapat dipandang
sebagai lingkungan pendukung umum, tidak ditujukan untuk satu bahasa
pemrograman tertentu, metode pengembangan, atau model proses. UNIX
menawarkan sejumlah blok bangunan yang sangat nyaman, namun sangat
sederhana, yang dengannya hal-hal yang lebih rumit dapat direalisasikan
(Kernighan dan Mashey, 1981):
�
15.2. LINGKUNGAN YANG BERPUSAT 505
BAHASA
�
Lingkungan yang berpusat pada bahasa saat ini umumnya datang dengan sejumlah
komponen yang sangat memudahkan pengembangan perangkat lunak. Contoh
lingkungan tersebut termasuk Microsoft Studio .NET dan Eclipse. Dukungan yang
ditawarkan berkisar dari satu set API untuk menghasilkan antarmuka pengguna
(seperti Swing), hingga fasilitas untuk menangani persistensi (EJB) atau membuat
aplikasi web (Ajax). Kekayaan fitur datang dengan harga: kurva belajar yang agak
panjang.
15.3 Lingkungan dan Meja Kerja

Terpadu
Bagian ini dikhususkan untuk produk CASE yang mendukung (bagian dari) proses
pengembangan perangkat lunak. Bergantung pada cakupan seperangkat alat yang
tersedia, lingkungan seperti itu disebut Analyst WorkBench (AWB), Programmer
WorkBench (PWB), Management WorkBench (MWB), atau Lingkungan Dukungan
Proyek Terpadu (IPSE); lihat juga gambar 15.3. Akronim CASE (Computer-Aided
Software Engineering) sering digunakan untuk menunjukkan semua jenis dukungan
alat dalam proses pengembangan perangkat lunak. Istilah yang memenuhi syarat
KASUS Atas dan KASUS Rendah mengacu pada dukungan alat selama fase
analisis--desain dan implementasi--tes, masing-masing. Dalam kasus yang
ideal, pilihan seperangkat alat tertentu akan dibuat sebagai berikut. Pertama,
pendekatan tertentu untuk proses pengembangan perangkat lunak dipilih.
Selanjutnya, dipilih teknik-teknik yang mendukung berbagai fase dalam proses
pengembangan tersebut. Sebagai langkah terakhir, dipilih alat yang mendukung
teknik tersebut. Beberapa langkah dalam proses pengembangan mungkin tidak
didukung oleh teknik yang terdefinisi dengan baik. Beberapa teknik mungkin tidak
didukung oleh alat. Dengan demikian, lingkungan pengembangan tipikal akan
berbentuk piramida seperti pada gambar 15.4.
Dalam praktiknya, kita sering menemukan bentuk kerucut terbalik: model proses
pengembangan yang hampir tidak berkembang, beberapa teknik yang terdefinisi
dengan baik, dan banyak alat. Dengan cara ini, manfaat alat akan dibatasi
sebaik-baiknya. Mengutip situasi: untuk banyak KASUS, ada banyak
Computer-Aided, dan Rekayasa Perangkat Lunak yang berharga. Set alat
berbeda yang diidentifikasi di atas dibahas dalam subbagian berikutnya.
15.3.1 Meja Kerja Analis

Meja kerja analis berfungsi untuk mendukung aktivitas di fase awal pengembangan
perangkat lunak: rekayasa persyaratan dan desain (global). Dalam fase ini, data
analisis dan desain dikumpulkan. Seringkali, gambar grafis dari sistem dibuat,
misalnya dalam bentuk kumpulan diagram UML. Dari sudut pandang praktis,
masalah penting berkaitan dengan menggambar dan menggambar ulang diagram
tersebut dan menjaga konsistensi dan kelengkapan data yang dikumpulkan. Alat
AWB secara khusus membahas poin-poin ini.
Kernel dari AWB adalah database tempat informasi yang dikumpulkan disimpan.
Struktur database bisa agak bebas, atau bisa berasal dari teknik yang didukung.
AWB juga akan berisi alat untuk mendukung jenis aktivitas berikut:
15.3. LINGKUNGAN TERPADU DAN MEJA 507
KERJA
Gambar 15.3 Cakupan set alat
Gambar 15.4 Dukungan dalam lingkungan pengembangan tipikal

�
15.3. LINGKUNGAN TERPADU DAN MEJA 509
KERJA
– debugging;
– pembuatan data uji;
– simulasi;
– penentuan cakupan tes.
Alat yang mendukung kerja sama tim dalam proyek besar patut mendapat perhatian khusus. Di sebuah
lingkungan tipikal, sekelompok pemrogram akan bekerja pada sistem yang sama.
Sistem akan memiliki banyak komponen, dikembangkan, diuji, dan diubah secara berbeda
rakyat. Selama evolusi sistem, versi komponen yang berbeda akan berbeda
hasil. Dukungan otomatis untuk mengontrol rangkaian komponen tersebut, baik secara teknis
dan organisasi, adalah kebutuhan belaka.
Salah satu sistem awal untuk kontrol konfigurasi adalah Kontrol Kode Sumber
System (SCCS), awalnya dikembangkan untuk IBM OS dan paling dikenal dari UNIX. SCCS
memungkinkan pengguna untuk melacak modifikasi dalam file (yang mungkin berisi file tersebut
beragam hal seperti kode program, dokumentasi, atau set pengujian). Sistem memungkinkan
pengguna untuk menghasilkan versi sistem apa pun. Versi baru dapat dibuat tanpa
versi lama hilang. Aspek penting SCCS adalah:
– tidak ada salinan versi terpisah yang disimpan: hanya modifikasi (disebut delta)
ke versi sebelumnya disimpan;
– akses ke file dilindungi: hanya pengguna yang berwenang yang dapat membuat perubahan;
– setiap file diidentifikasi oleh penulis, nomor versi, dan tanggal dan waktu
modifikasi;
– sistem meminta informasi kepada pengguna tentang alasan perubahan, yang mana
perubahan dilakukan, di mana, dan oleh siapa.
Gambar 15.5 mengilustrasikan operasi utama yang disediakan oleh SCCS. Dalam SCCS, semua
informasi disimpan dalam apa yang disebut s-files. Operasi membuat membuat s-file untuk
pertama kali. Jika file asli bernama prog, maka file SCCS diberi nama s.prog.
Operasi mendapatkan menghasilkan salinan read-only dari file yang diminta. Salinan hanya-baca ini
dapat digunakan untuk kompilasi, pencetakan, dan sejenisnya. Dia bukan dimaksudkan untuk diedit.
Operasi sunting mengambil salinan untuk diedit. SCCS menangani perlindungan di
pengertian bahwa hanya satu orang yang dapat mengedit file pada satu waktu. Akhirnya, delta
operasi menyimpan versi revisi dari file yang diedit.
Versi file SCCS diberi nomor, 1.1, 1.2, 1.3, 2.1, dll. Nomor ke
kiri periode adalah nomor versi utama (nomor rilis). Nomor ke
kanan periode adalah nomor versi minor. Versi pertama diberi nomor 1.1.
Secara default, mendapatkan Dan sunting mengambil versi terbaru dari file, while delta menghasilkan
sebuah
peningkatan nomor versi minor. Jika diperlukan versi yang lebih lama atau yang utama
nomor versi akan ditingkatkan, ini harus ditentukan secara eksplisit.
Gambar 15.5 Operasi utama SCCS
Skema di atas menghasilkan urutan versi linier. SCCS juga menyediakan

kemungkinan untuk membuat cabang (garpu), seperti yang diilustrasikan pada
gambar 15.6. Misalnya, mulai dari versi 1.2 kami dapat membuat versi 1.3, 1.4, dll
untuk mewakili pengembangan normal komponen sistem, dan versi 1.2.1.1, 1.2.1.2,
dll untuk mewakili perbaikan bug di versi 1.2. Dalam SCCS, penggabungan jalur
pengembangan harus dilakukan secara manual.
Ketika versi berbeda dari sistem yang sama dipertahankan dengan cara ini,
kebutuhan untuk mengotomatisasi konstruksi versi baru yang dapat dieksekusi
muncul. Make adalah alat yang melakukan hal ini (Feldman, 1978). Make
menggunakan deskripsi berbagai komponen sistem dan ketergantungan timbal
baliknya. Saat membuat sistem baru yang dapat dieksekusi, Make memeriksa
tanggal dan waktu perubahan terakhir pada komponen dan hanya mengkompilasi
ulang komponen bila diperlukan (yaitu komponen yang telah diubah sejak kompilasi
terakhir). Alat seperti Make tidak hanya menghemat waktu mesin, tetapi juga
memastikan versi terbaru dari setiap komponen digunakan.
Fungsionalitas dasar dari sistem kontrol konfigurasi tidak berubah secara
mendasar sejak pengembangan SCCS pada awal 1970-an. Daripada menyimpan
salinan dari setiap versi, SCCS dan sistem serupa hanya melacak apa yang telah
berubah dari versi sebelumnya (disebut delta). Saat ini, penyimpanan disk tidak
menjadi masalah lagi, dan banyak sistem konfigurasi perangkat lunak menggunakan
kompresi seperti zip sederhana, bukan delta. Fitur tambahan yang ditawarkan dalam
sistem saat ini terutama diarahkan untuk meningkatkan fleksibilitas dan kegunaan
sistem tersebut:
�
15.4. LINGKUNGAN YANG BERPUSAT PROSES 513
15.3.4 Lingkungan Dukungan

Proyek Terintegrasi
Lingkungan Dukungan Proyek Terintegrasi dimaksudkan untuk mendukung semua fase dari
siklus hidup perangkat lunak. Dengan demikian, lingkungan seperti itu harus mengandung berbagai alat
seperti
dibahas pada bagian sebelumnya. Lingkungan yang merentang siklus hidup lengkap
biasanya menekankan dukungan baik kegiatan front-end (analisis dan desain global
-- Upper-CASE) atau kegiatan back-end (implementasi dan pengujian -- Lower-CASE).
Mereka kemudian berisi alat yang secara khusus ditujukan untuk mendukung tugas dari yang sesuai
bagian dari siklus hidup, ditambah dengan dukungan yang lebih umum untuk fase lainnya (seperti
seperti untuk pengeditan, pemrosesan teks, atau akses basis data).
Saat mengembangkan IPSE, kami dapat mengupayakan integrasi yang kuat atau lemah
alat-alatnya. Integrasi yang kuat, seperti yang diwujudkan dalam lingkungan yang berpusat pada bahasa
dibahas di bagian 15.2, memiliki keunggulan (seperti kemampuan kontrol yang lebih baik) dan
kerugian. Salah satu kelemahannya adalah IPSE seperti itu cenderung kurang fleksibel. Jika
alat tidak terintegrasi, seperti di UNIX, ada lebih banyak fleksibilitas. Di sisi lain, a
diperlukan kontrol manajemen yang lebih ketat.
Kami juga dapat mencari bentuk perantara. Misalnya, semua objek dapat disimpan
dalam sistem file UNIX, dikendalikan oleh SCCS, dan hubungan antar objek
dapat direpresentasikan menggunakan sistem basis data relasional.
Inti dari lingkungan terintegrasi adalah gudang data, yang berisi
berbagi informasi antara alat-alat yang membentuk lingkungan. Kendala
dikenakan pada struktur repositori ini mencerminkan sejauh mana alat
terintegrasi. Integrasi alat yang lebih ketat memungkinkan definisi yang lebih ketat
struktur data yang mereka bagikan, dan sebaliknya.
15.4 Lingkungan yang Berpusat

pada Proses
Dalam lingkungan rekayasa perangkat lunak yang berpusat pada proses (PSEE), deskripsi dari
proses pengembangan perangkat lunak dibagi oleh alat-alat yang membentuk lingkungan.
Tidak mengherankan, perkembangan dalam lingkungan yang berpusat pada proses sangat erat
kaitannya
untuk pengembangan dalam pemodelan proses, dan sebaliknya. Misalnya jenis-jenis
deskripsi yang digunakan dalam pemodelan proses (diagram transisi keadaan, jaring Petri, dan
seperti) juga formalisme yang digunakan dalam PSEE. Pemodelan proses dibahas di bagian ini
3.6.
Seperti lingkungan terintegrasi, lingkungan yang berpusat pada proses dapat mencakup
siklus hidup lengkap. Seperti IPSE, PSEE cenderung diarahkan untuk mendukung tugas
dari bagian tertentu dari siklus hidup pengembangan perangkat lunak. Sejak kegiatan back-end
(implementasi dan pengujian) agak lebih mudah untuk disusun dan diformalkan, dikerjakan
pemodelan proses dan PSEE berkonsentrasi pada pemodelan dan mendukung back-end
kegiatan, akibatnya.
Gambar 15.7 memberikan model proses melakukan review kode. Itu
notasinya adalah jaring Petri. Pada bagian 3.6, gambar yang sama digunakan untuk menjelaskan
peran formalisme yang berbeda dalam pemodelan proses. Di sini, kita akan
menggunakannya untuk membahas perannya dalam lingkungan rekayasa
perangkat lunak yang berpusat pada proses.
Gambar 15.7 Tampilan bersih petri dari proses

peninjauan
Jika pengembang menunjukkan bahwa beberapa bagian kode siap untuk

ditinjau, lingkungan akan diberitahukan dan masuk ke status seperti yang
ditunjukkan pada gambar 15.7. Sejalan dengan aktivitas pengkodean, manajemen
menjadwalkan rapat tinjauan. Setelah ini selesai, tempatnya1 berlabel tinjauan
dijadwalkan ditandai. Lingkungan pendukung kemudian 'mengetahui' bahwa tinjauan
dapat diadakan dan mungkin menawarkan dukungan untuk melakukannya. Dengan
cara ini, lingkungan memandu pengembang dan peserta lain melalui
langkah-langkah proses peninjauan, memberi tahu mereka ketika tindakan tertentu
diperlukan, mempertahankan informasi status produk kode dan potongan informasi
lainnya, dll. Dengan demikian, PSEE memberikan dukungan untuk pengembangan
perangkat lunak dengan mengotomatiskan rutin tugas, menerapkan alat
pengembangan yang sesuai, dan menegakkan aturan dan praktik.
Model formal dari proses perangkat lunak bersifat kaku. Dalam praktiknya,
kekakuan ini merupakan hambatan, karena akan selalu ada pengecualian. Misalnya,
risalah rapat tinjauan mungkin hilang, manajemen mungkin memutuskan untuk
melewatkan rapat tinjauan tertentu, rapat tinjauan mungkin harus dijadwalkan ulang
karena beberapa peserta sakit, dll. Model Petri dari gambar 15.7 tidak dapat
mengatasi situasi ini . Beberapa di antaranya dapat diakomodasi dengan membuat
model menjadi lebih kompleks. Tapi modelnya tidak akan pernah mencakup semua
situasi. Oleh karena itu, ada kebutuhan untuk dapat melakukan intervensi. Beberapa
PSEE, misalnya, menawarkan sarana untuk memperbarui model proses dengan
cepat. Solusi yang sepenuhnya memuaskan sulit ditemukan, dan kekakuan model
formal cenderung terus berkonflik dengan persyaratan fleksibilitas dalam dukungan
proses.
Ini lebih berlaku jika mendukung tahap awal pengembangan perangkat lunak.
Seorang perancang atau insinyur persyaratan tidak dibantu oleh lingkungan yang
menentukan
1Lihat bagian 3.6 untuk terminologi jaring Petri.
15.5. RINGKASAN 515
urutan rinci langkah-langkah proses yang akan diambil. Secara umum, kita dapat
membedakan dua jenis aktivitas: aktivitas tidak terstruktur, kreatif, dan kooperatif
yang menjadi ciri tahap awal pengembangan perangkat lunak; dan kegiatan
berulang dan terstruktur yang menjadi ciri tahap selanjutnya. Dikotomi serupa dapat
diamati pada PSEE. PSEE yang berfokus pada tahap awal memiliki banyak
kesamaan dengan sistem groupware dan Computer Supported Cooperative Work
(CSCW). PSEE ini mendukung koordinasi aktivitas, seperti akses ke dan berbagi
informasi, dan aktivitas kerja sama, seperti komunikasi antara orang dan
penjadwalan rapat. Jenis dukungan ini menjadi semakin penting dalam
pengembangan multisite saat ini; lihat juga bab ??. PSEE yang berfokus pada tahap
selanjutnya memiliki banyak kesamaan dengan manajemen alur kerja dan sistem
kontrol konfigurasi. Sistem kontrol konfigurasi saat ini tidak hanya menawarkan versi
dasar dan kemampuan akses yang dikenal dari sistem seperti SCCS (lihat bagian
15.3.2) tetapi mereka juga menawarkan cara untuk mendefinisikan dan
memberlakukan tugas dan kebijakan konfigurasi perangkat lunak. Beberapa bahkan
mengklaim bahwa alat manajemen konfigurasi adalah PSEE 'nyata' (Conradi et al.,
1998).
15.5 Ringkasan
Perkembangan di bidang koleksi alat (terintegrasi) bergerak sangat cepat. Untuk
banyak aspek dari proses pengembangan perangkat lunak, alat yang baik tersedia.
Dalam bab ini, kita telah membahas perkembangan utama dalam hal rekayasa
perangkat lunak berbantuan komputer (CASE). Kami telah melakukannya dengan
menggunakan klasifikasi produk CASE satu dimensi yang sederhana, yang
mengungkapkan bagian-bagian dari siklus hidup yang mereka dukung:
�
�
produk diberikan dalam (Lott, 1993). Paradigma sosiologis (individu, keluarga,
dll) untuk skala pengguna berasal dari (Perry dan Kaiser, 1991).
Barstow dkk. (1984) adalah kumpulan artikel mani tentang lingkungan pemrograman
ronments, termasuk pendekatan toolkit UNIX dan lingkungan awal yang berpusat pada bahasa
ronment seperti Interlisp. Sistem Kontrol Kode Sumber (SCCS) dijelaskan dalam
(Rochkind, 1975). Keadaan seni dalam manajemen konfigurasi tercermin dalam
(Estublier et al., 2005). Alat bangunan tidak banyak berubah sejak Make (Feldman,
1978). Perkembangan terkini di bidang ini di dunia Jawa adalah Semut (Serrano dan
Ciordia, 2004).
Pada 1980-an, penelitian alat berfokus pada penciptaan lingkungan yang terintegrasi. (Tah-
vanainen dan Smolander, 1990) adalah bibliografi beranotasi artikel tentang perangkat lunak
lingkungan teknik dari periode itu. Penelitian selanjutnya di bidang alat
berfokus pada PSEE. Keadaan seni di bidang ini tercermin dalam (Fuggetta dan Wolf,
1996) dan (Ambriola et al., 1997). Kasus untuk lebih banyak fleksibilitas dalam rekayasa perangkat lunak
lingkungan dibuat di (Jankowski, 1994), (Cugola et al., 1996), (Jarzabek dan
Huang, 1998) dan (Cugola dan Ghezzi, 1998).
Masalah integrasi alat dibahas di (Sharon dan Bell, 1995). Penilaian alat
adalah topik (Software, 1996b). Studi adopsi dan penggunaan alat dapat ditemukan di
(Iivari, 1996) dan (Post et al., 1998).
Latihan
1. Apa singkatan KASUS singkatan?
2. Definisikan istilah-istilah berikut:
- alat,
- meja kerja,
- lingkungan.
3. Apa ciri pembeda utama dari:
– alat bantu,
– lingkungan yang berpusat pada bahasa,
- lingkungan yang terintegrasi, dan
– lingkungan yang berpusat pada proses.
4. Apa perbedaan antara HURUF BESAR dan HURUF BESAR?
5. Apa fungsi dasar alat untuk manajemen konfigurasi?
6. Diskusikan ketegangan mendasar antara formalitas dan informalitas dalam alat.

7. Mengapa skala pengguna merupakan masalah penting saat

mempertimbangkan adopsi peralatan?
8. ~
Bibliografi
Abdel-Hamid, T., Sengupta, K., dan Ronan, D. (1993). Kontrol Proyek Perangkat
Lunak: Investigasi Eksperimental Penghakiman dengan Informasi yang Salah.
Rekayasa Perangkat Lunak Transaksi IEEE, 19(6):603--612.
Aberdour, M. (2007). Mencapai Kualitas dalam Perangkat Lunak Sumber Terbuka. Perangkat Lunak
IEEE,
24(1):58--64.
Abrahamsson, P., Salo, O., Ronkainen, J., dan Warsta, J. (2002). Perangkat Lunak Agile
Metode Pengembangan. Laporan teknis, Publikasi VTT 478, VTT, Finlandia.
Abran, A. dan Robillard, P. (1992). Poin Fungsi: Studi tentang Proses Pengukuran
dan Transformasi Skalanya. Jurnal Sistem dan Perangkat Lunak, 25(2):171--184.
Abran, A. dan Robillard, P. (1996). Analisis Poin Fungsi: Studi Empiris Proses
Pengukurannya. Transaksi IEEE pada Rekayasa Perangkat Lunak, 22(12):895--910.
Adams, E. (1984). Mengoptimalkan Layanan Preventif Produk Perangkat Lunak. Jurnal IBM
Penelitian dan Pengembangan, 28(1):2--14.
Albrecht, A. (1979). Mengukur Produktivitas Pengembangan Aplikasi. Di dalam Proses

Simposium Pengembangan Aplikasi, halaman 83--92. BAGIKAN/PANDUAN.
Albrecht, A. dan Gaffney, J. (1983). Fungsi Perangkat Lunak, Baris Sumber Kode,
dan Prediksi Upaya Pengembangan: Validasi Ilmu Perangkat Lunak. Transaksi IEEE
pada Rekayasa Perangkat Lunak, 9(6):639--648.
Alexander, C. (1979). Cara Membangun yang Abadi. Pers Universitas Oxford.
Alexander, C. (1999). Asal Usul Teori Pola. Perangkat Lunak IEEE, 16(5):71--82.
Alexander, C., Ishikawa, S., dan Silverstein, M. (1977). Bahasa Pola. Oxford
Pers Universitas.
Ambriola, V., Conradi, R., dan Fuggetta, A. (1997). Menilai Lingkungan Rekayasa
Perangkat Lunak yang Berpusat pada Proses. Transaksi ACM pada Rekayasa
Perangkat Lunak dan Metodologi, 6(3):283--328.
520 BIBLIOGRAFI
Arisholm, A. dan Sjøberg, D. (2004). Mengevaluasi Pengaruh Gaya Kontrol yang
Didelegasikan versus Terpusat pada Kemampuan Pemeliharaan Perangkat Lunak
Berorientasi Objek.Transaksi IEEE pada Rekayasa Perangkat Lunak,
30(8):521--534.
Armor, P. (2001). Zeppelin dan Pesawat Jet: Metafora untuk Perangkat Lunak
Modern Proyek. Komunikasi ACM, 44(10):13--15.
Atkinson, C. (2000). Pendekatan Sosio-Teknis dan Lunak untuk Persyaratan Informasi-

ments Elisitasi di Era Post-Metodologi. Jurnal Rekayasa Kebutuhan,
5(2):67--73.
Austin, R. dan Devin, L. (2003). Melampaui Persyaratan: Pembuatan Perangkat

Lunak sebagai Seni. IEEE Perangkat lunak, 20(1):93--95.
Baber, R. (1982). Perangkat Lunak Tercermin. Perusahaan Penerbitan

Belanda Utara.
Babich, W. (1986). Manajemen Konfigurasi Perangkat Lunak. Addison-Wesley.

Baddoo, N. dan Hall, T. (2003). De-motivator untuk peningkatan proses perangkat
lunak: analisis pandangan praktisi. Jurnal Sistem dan Perangkat Lunak,
66(1):23--34.
Baker, F. (1972). Kepala Tim Programmer Manajemen Pemrograman Produksi.

Jurnal Sistem IBM, 11(1):56--73.
Banker, R., Datar, S., Kemerer, C., dan Zweig, D. (1993). Kompleksitas Perangkat
Lunak dan Biaya perawatan. Komunikasi ACM, 36(11):81--94.
Bankir, R., Kauffman, R., dan Kumar, R. (1991). Uji Empiris Metrik Pengukuran
Output Berbasis Objek di Lingkungan Computer Aided Software Engineering
(CASE). Jurnal Sistem Informasi Manajemen, 8(3):127--150.
Baram, G. dan Steinberg, G. (1989). Kriteria Seleksi untuk Analisis dan Desain
KASUS Peralatan. Catatan Rekayasa Perangkat Lunak ACM, 14(6):73--80.
Barnard, H., Metz, R., dan Harga, A. (1986). Praktik yang Direkomendasikan untuk
Menggambarkan
Desain Perangkat Lunak: Proyek Standar IEEE Transaksi IEEE pada Perangkat Lunak
1016.
Rekayasa, 12(2):258--263.
Barstow, D., Shrobe, H., dan Sandewall, E., editor (1984). Pemrograman Interaktif
Lingkungan. McGraw-Hill.
Basili, V. (1990). Melihat Pemeliharaan sebagai Pengembangan Perangkat Lunak
Berorientasi Penggunaan Ulang. Perangkat Lunak IEEE, 7(1):19--25.
Basili, V., Briand, L., Condon, S., Kim, Y.-M., Melo, W., dan Valen, J. (1996).
Memahami dan Memprediksi Proses Rilis Pemeliharaan Perangkat Lunak. Di
dalamProsiding Konferensi Internasional tentang Pemeliharaan Perangkat Lunak
(ICSM’96), halaman 464--474.IEEE.
BIBLIOGRAFI 521
Basili, V. dan Selby, R. (1987). Membandingkan Efektivitas Pengujian Perangkat Lunak
Strategi. Transaksi IEEE pada Rekayasa Perangkat Lunak, 13(12):1278--1296.
Bass, L., Clements, P., dan Kazman, R. (2003). Arsitektur Perangkat Lunak dalam Praktek. Addison
Wesley, edisi kedua.
Batini, C., Ceri, S., dan Navathe, S. (1992). Desain Basis Data Konseptual: Entitas--
Pendekatan Hubungan. Benyamin Cummings.
Beck, K. (2000). Pemrograman Ekstrim Dijelaskan. Addison-Wesley.
Beck, K. (2003). Pengembangan Berbasis Tes. Addison-Wesley.
Beck, K. dan Cunningham, W. (1989). Laboratorium Untuk Mengajar Berorientasi Objek

Pemikiran. Di dalam Proses OOPSLA ’89, Pemberitahuan ACM SIGPLAN 24(10), halaman 1--6.
Beck, K. et al. (2001). Manifesto untuk Pengembangan Perangkat Lunak Agile.
Beizer, B. (1995). Pengujian Kotak Hitam. John Wiley & Sons.
Bellay, B. dan Gall, H. (1998). Evaluasi Kemampuan Alat Rekayasa Terbalik.

Jurnal Pemeliharaan Perangkat Lunak: Penelitian dan Praktek, 10:305--331.
Benington, H. (1983). Produksi Program Komputer Besar. Di dalam Prosiding ONR

Symposium (1956), dicetak ulang dalam Annals of the History of Computing 5(4), halaman 350--361.
Bennett, K. (1998). Apakah Transformasi Program Membantu Rekayasa Balik? Di

dalamProsiding Konferensi Internasional tentang Pemeliharaan Perangkat Lunak
Bennett, K. dan Rajlich, V. (2000). Pemeliharaan dan Evolusi Perangkat Lunak: Peta
Jalan. Dalam Finkelstein, A., editor, Masa Depan Rekayasa Perangkat Lunak,
halaman 73--87. Pers ACM.
Bergland, G. dan Gordon, R. (1981). Tutorial: Strategi Desain Perangkat Lunak. IEEE, EZ389.
Bersoff, E. dan Davis, A. (1991). Dampak Model Siklus Hidup pada Perangkat
Lunak
Manajemen konfigurasi. Komunikasi ACM, 34(8):104--118.
Beyer, H. dan Holtzblatt, K. (1995). Magang dengan Pelanggan. Komunikasi

dari ACM, 38(5):45--52.
Bieman, J., Jain, D., dan Yang, H. (2001). Pola Desain OO, Struktur Desain, dan
Perubahan Program: Studi Kasus Industri. Di dalam Prosiding Pemeliharaan
Perangkat Lunak Konferensi Internasional (ICSM’01), halaman 580--589. IEEE.
Biffl, S. dan Halling, M. (2002). Menginvestigasi Pengaruh Faktor Kapabilitas

Inspektur dengan Empat Teknik Inspeksi terhadap Kinerja Inspeksi. Di dalam
Prosiding Simposium Metrik Perangkat Lunak Internasional IEEE ke-8, halaman
107--17. IEEE.
522 BIBLIOGRAFI
Biggerstaff, J., Mitbander, B., dan Webster, D. (1994). Pengertian Program dan
Masalah Penugasan Konsep. Komunikasi ACM, 37(5):72--83.
Biggerstaff, T. (1989). Desain Pemulihan untuk Pemeliharaan dan Penggunaan

Kembali. Komputer IEEE, 22(7):36--50.
Binder, R. (2000). Menguji Sistem Berorientasi Objek. Addison-Wesley.
Bisbal, J., Lawless, D., Wu, B., dan Grimson, J. (1999). Sistem Informasi Warisan:
Isu dan Arah. Perangkat Lunak IEEE, 16(5):103--111.
Blum, B. (1994). Taksonomi Metode Pengembangan Perangkat Lunak. Komunikasi

dari ACM, 37(11):82--94.
Boehm, B. (1975). Beberapa Pengalaman dengan Alat Bantu Otomatis untuk

Merancang Perangkat Lunak Berskala Besar yang Andal. Di dalam Prosiding
Konferensi Internasional tentang Perangkat Lunak yang Andal, Pemberitahuan
ACMSIGPLAN 10(6), halaman 105--113. ACM.
Boehm, B. (1976). Rekayasa Perangkat Lunak. IEEETransaction pada Komputer,

K-25(12):1226- -1241.
Boehm, B. (1981). Ekonomi Rekayasa Perangkat Lunak. Prentice-Hall.
Boehm, B. (1983). Ekonomi Pemeliharaan Perangkat Lunak. Di dalam Perangkat

Lunak Prosiding Bengkel Pemeliharaan, halaman 9--37. IEEE, 83CH1982-8.
Boehm, B. (1984a). Faktor Siklus Hidup Perangkat Lunak. Dalam Vick, C. dan Ramamoorthy, C.,
editor, Buku Pegangan Rekayasa Perangkat Lunak, halaman 494--518. Van Nostrand Reinhold.
Boehm, B. (1984b). Memverifikasi dan Memvalidasi Persyaratan dan Desain

Perangkat Lunak Spesifikasi. Perangkat Lunak IEEE, 1(1):75--88.
Boehm, B. (1987a). Meningkatkan Produktivitas Perangkat Lunak. Komputer IEEE,

20(9):43--57.
Boehm, B. (1987b). Daftar 10 Teratas Metrik Perangkat Lunak Industri. Perangkat Lunak
IEEE, 4(5):84--85.
Boehm, B. (1988). Model Spiral Pengembangan dan Peningkatan Perangkat Lunak.

IEEE Komputer, 21(5):61--72.
Boehm, B. (1989). Manajemen Risiko Perangkat Lunak. IEEE.
Boehm, B. dan Basili, V. (2001). Daftar 10 Teratas Pengurangan Cacat Perangkat

Lunak. IEEE Komputer, 34(1):135--137.
Boehm, B., Brown, J., Kaspar, H., Lipow, M., MacLeod, G., dan Merrit, M.
(1978).Karakteristik Kualitas Perangkat Lunak. Nomor 1 dalam TRW Series of
Software Technology.North-Holland.
BIBLIOGRAFI 523
Boehm, B., Clark, B., Horowitz, E., Westland, C., Madachy, R., dan Selby, R. (1995).
Model Biaya untuk Proses Siklus Hidup Perangkat Lunak Masa Depan: COCOMO
2.0. Sejarah Rekayasa Perangkat Lunak, 1:57--94.
Boehm, B. dan Sullivan, K. (1999). Ekonomi perangkat lunak: status dan prospek.
Teknologi Informasi dan Perangkat Lunak, 41(14):937--946.
Boehm, B. dan Turner, R. (2003). Menyeimbangkan Agility dan Disiplin. Addison-Wesley.
Boehm et al., B. (1997). Manual Definisi Model COCOMO II. Laporan teknikal,
Universitas California Selatan.
Böhm, C. dan Jacopini, G. (1966). Diagram Alir, Mesin Turing, dan Bahasa
Dengan Hanya Dua Aturan Formasi. Komunikasi ACM, 9(5):366--371.
Bohrer, K., Johnson, V., Nilsson, A., dan Rudin, B. (1998). Proses bisnis
Komponen untuk Aplikasi Objek Komunikasi ACM,
Terdistribusi.
41(6):43--48.
Booch, G. Analisis dan Desain Berorientasi Objek dengan Aplikasi. Benyamin-

(1994).
Cummings, edisi kedua.
Booch, G., Rumbaugh, J., dan Jacobson, I. (1999). Panduan Pengguna UML. Addison Wesley.
Bounds, G., Yorks, L., Adams, M., dan Ranney, G. (1994). Melampaui Kualitas Total
Pengelolaan. McGraw-Hill.
Brooks, F. (1995). Bulan Manusia Mitos. Addison-Wesley, edisi kedua.

Brooks, Jr., F. (1987). No Silver Bullet: Esensi dan Kecelakaan Rekayasa Perangkat Lunak.
Komputer IEEE, 20(4):10--20.
Brooks, R. (1983). Menuju Teori Pemahaman Program Komputer.
Jurnal Internasional Studi Mesin Manusia, 18:543--554.
Brown, W., Malveau, R., III, H. M., dan Mowbray, T. (1998). AntiPola: Refactoring
Perangkat Lunak, Arsitektur, dan Proyek dalam Krisis. John Wiley & Sons.
Budgen, D. (2003). Desain perangkat lunak. Addison Wesley, edisi kedua.

Burch, E. dan Kung, H.-J. (1997). Permintaan Pemeliharaan Perangkat Lunak
Pemodelan: ACaseStudy. Di dalam Prosiding Konferensi Internasional tentang
Pemeliharaan Perangkat Lunak (ICSM’97), halaman 40--47.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., dan Stal, M. (1996). A
Sistem Pola. John Wiley & Sons.
Bush, E. (1985). Restrukturisasi Otomatis COBOL. Di dalam Konferensi Prosiding pada

Pemeliharaan Perangkat Lunak, halaman 35--41. IEEE.
524 BIBLIOGRAFI
Buxton, J. dan Randell, B., editor (1969). Teknik Rekayasa Perangkat Lunak,
Laporan a Konferensi. Divisi Urusan Ilmiah NATO, Roma.
CACM (1993a). Edisi Khusus Desain Partisipatif. Komunikasi ACM, 36(6).
CACM (1993b). Edisi Khusus Organisasi dan Manajemen Proyek. Komunikasi-

kation ACM, 36(10).
CACM (1997). Masalah khusus Pendekatan Kualitas: Apakah Menyampaikan.

Komunikasi dari ACM, 40(6).
Cameron, J. (1989). JSP & JSD, Pendekatan Jackson untuk Pengembangan Perangkat Lunak. IEEE.
Carmel, E., Whitaker, R., dan George, J. (1993). PD dan Desain Aplikasi Bersama:
A Perbandingan Transatlantik. Komunikasi ACM, 36(6):40--48.
Cha, S., Leveson, N., dan Shimeall, T. (1988). Verifikasi Keamanan di MURPHY
menggunakan Fault-Tree Analysis. Di dalam Prosiding Konferensi Internasional
ke-10 tentang Rekayasa Perangkat Lunak (ICSE10), halaman 377--386. IEEE.
Chapin, N. (1987). Pekerjaan Pemeliharaan Perangkat Lunak. Di dalam Konferensi

Prosiding pada Pemeliharaan Perangkat Lunak, halaman 4--12. IEEE.
Chapin, N., Hale, J., Khan, K., amil, J., dan Tan, W.-G. (2001). Jenis evolusi
perangkat lunak dan pemeliharaan perangkat lunak. Jurnal Pemeliharaan dan
Evolusi Perangkat Lunak: Penelitian dan Praktek, 13:3--30.
Chen, P. (1976). Entitas--Model Hubungan: Menuju Tampilan Data yang Menyatu.

Transaksi ACM pada Sistem Basis Data, 1(1):9--36.
Chidamber, S. dan Kemerer, C. (1994). Suite Metrik untuk Desain Berorientasi

Objek. Transaksi IEEE pada Rekayasa Perangkat Lunak, 20(6):476--493.
Chikofsky, E. (1990). KASUS & Reengineering: Dari Arkeologi ke Software

Pere-stroika. Di dalam Prosiding Konferensi Internasional ke-12 tentang Rekayasa
Perangkat Lunak (ICSE12), halaman122. IEEE.
Chikofsky, E. dan Cross II, J. (1990). Rekayasa Balik dan Pemulihan Desain: A
Taksonomi. Perangkat Lunak IEEE, 7(1):13--18.
Churcher, N. dan Shepperd, M. (1995). Komentar pada 'Suite Metrik untuk Objek
Desain Berorientasi '. Transaksi IEEE pada Rekayasa Perangkat Lunak,
21(3):263--265.
Ciolkowski , M. , Laitenberger , O. , & Biffl , S. (2003). Ulasan Perangkat Lunak:

Negara Bagian dari Praktek. Perangkat Lunak IEEE, 20(6):46--51.
BIBLIOGRAFI 525
Clarke, L., Podgurski, A., Richardson, D., dan Zeil, S. (1989). Evaluasi Formal
Kriteria Pemilihan Jalur Aliran Data. Transaksi IEEE pada Rekayasa Perangkat Lunak,
15(11):1318--1332.
Clements, P., Bachman, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R., dan
Stafford, J. (2003). Mendokumentasikan Arsitektur Perangkat Lunak: Views and
Beyond. AddisonWesley.
Clements, P., Kazman, R., dan Klein, M. (2002). Mengevaluasi Arsitektur Perangkat Lunak: Metode
dan Studi Kasus. Addison-Wesley.
Clements, P. dan Northrop, L. (2001). Lini Produk Perangkat Lunak: Praktik dan Pola.
Addison-Wesley.
Tim Produk CMMI C
(2002).
526 BIBLIOGRAFI
Conradi, R., Fuggetta, A., dan Jaccheri, M. (1998). Enam Tesis tentang Software
ProcessResearch. Di Gruhn, V., editor, Teknologi Proses Perangkat Lunak, bengkel
Eropa ke-6, EWSPT'98. Springer Verlag, LNCS 1487.
Constantine, L. (1993). Organisasi Kerja: Paradigma untuk Manajemen Proyek dan
Organisasi. Komunikasi ACM, 36(10):34--43.
Conte, S., Dunsmore, H., dan Shen, V. (1986). Metrik dan Model Rekayasa
Perangkat Lunak. Benyamin Cummings.
Cook, S., Harrison, R., Lehman, M., dan Wernick, P. (2006). Evolusi dalam sistem
perangkat lunak: dasar untuk skema klasifikasi SPE. Jurnal Pemeliharaan dan
Evolusi Perangkat Lunak: Penelitian dan Praktek, 18(1):1--35.
Corby, T. (1989). Pemahaman Program: Tantangan untuk tahun 1990-an. Sistem

IBM Jurnal, 28(2):294--306.
Corkill, D. (1997). Hitung Mundur Menuju Sukses: Objek Dinamis, GBB, dan
RADARSET- 1. Komunikasi ACM, 40(5):48--58.
Côt'e, M.-A., Suryn, W., dan Georgiadou, E. Model Kualitas Perangkat Lunak
(2006).
Persyaratan untuk Rekayasa Kualitas Perangkat Lunak. Di dalam Prosiding Manajemen
Kualitas Perangkat Lunak Internasional ke-14 & Konferensi INSPIRE.
Couger, J. dan Zawacki, R. (1980). Memotivasi dan Mengelola Personil Komputer.

Wiley.
Crowston, K. dan Howison, J. (2006). Menilai Kesehatan Open Source
Komunitas. Komputer IEEE, 39(5):89--91.
Cugola, G., di Nitto, E., Fuggetta, A., dan Ghezzi, C. (1996). Kerangka kerja untuk
Memformalkan Inkonsistensi dan Penyimpangan dalam Sistem yang Berpusat pada
Manusia. ACMTransactions tentang Rekayasa dan Metodologi Perangkat Lunak,
5(3):191--230.
Cugola, G. dan Ghezzi, C. (1998). Proses Perangkat Lunak: Retrospektif dan Jalan
menuju masa depan. Proses Perangkat Lunak -- Peningkatan dan Praktek,
4(3):101--123.
Currit, P., Dyer, M., dan Mills, H. (1986). Mensertifikasi Keandalan Perangkat Lunak.
Transaksi IEEE pada Rekayasa Perangkat Lunak, 12(1):3--11.
Curtis, B. (1989). Tiga Masalah Diatasi dengan Model Perilaku dari Proses
Pengembangan Perangkat Lunak. Di dalam Prosiding Konferensi Internasional
ke-11 tentang Rekayasa Perangkat Lunak (ICSE11), halaman 398--399. IEEE.
Curtis, B., Krasner, H., dan Iscoe, N. (1988). Studi Lapangan Desain Perangkat
Lunak Proses untuk Sistem Besar. Komunikasi ACM, 31(11):1268--1287.
Curtis, B., Krasner, H., Shen, V., dan Iscoe, N. (1987). Pada Membangun Model
Proses Perangkat Lunak Di Bawah Tiang Lampu. Di dalam Prosiding Konferensi
Internasional ke-9 tentang Rekayasa Perangkat Lunak (ICSE9), halaman 96--103.
BIBLIOGRAFI 527
Curtis, B., Sheppard, S., dan Milliman, P. (1979). Mantra Ketiga Kali: Lebih Kuat
Prediksi Kinerja Pemrogram dengan Metrik Di dalam
Kompleksitas Perangkat Lunak.
Prosiding Konferensi Internasional ke-4 tentang Rekayasa Perangkat Lunak (ICSE4), halaman
356--360.IEEE.
Cusumano, M. (1989). Pabrik Perangkat Lunak: Interpretasi Sejarah. IEEE

Perangkat lunak, 6(2):23--30.
Darcy, D. (2005). Kompleksitas Struktural Perangkat Lunak: Tes Eksperimental.

Darcy, D. dan Kemerer, C. (2005). Metrik OO dalam Praktek. Perangkat Lunak IEEE, 22(6):17--
19.
Darke, P. dan Shanks, G. (1996). Sudut Pandang Pemangku Kepentingan dalam

Definisi Persyaratan: Kerangka untuk Memahami Pendekatan Pengembangan
Sudut Pandang. Jurnal Rekayasa Persyaratan, 1:88--105.
Dart, S. (1990). Spektrum Fungsionalitas dalam Sistem Manajemen Konfigurasi.

Laporan teknis, CMU/SEI-90-TR-11, Institut Rekayasa Perangkat Lunak.
Dart, S., Ellison, R., Feiller, P., dan Habermann, A. (1987). pengembangan perangkat lunak
Lingkungan. Komputer IEEE, 20(11):18--28.
Davenport, T. (1993). Inovasi Proses: Pekerjaan Rekayasa Ulang melalui Teknologi Informasi.
Harvard Business School Press, Cambridge, MA.
Davis, A. (1993). Persyaratan Perangkat Lunak: Objek, Fungsi, dan Status. Prentice-Hall, kedua
mengedit.
Davis, A. (1995). Persyaratan Berorientasi Objek untuk Desain Berorientasi Objek: An

Transisi Mudah? Jurnal Sistem dan Perangkat Lunak, 30(1 & 2):151--159.
Davis, A. (2005). Manajemen Persyaratan Cukup. Rumah Dorset.
Davis, G. (1982). Strategi Penentuan Kebutuhan Informasi. IBM

Jurnal Sistem, 21(1):4--30.
Dekleva, S. (1992). Studi Delphi tentang Masalah Pemeliharaan Perangkat Lunak. Di dalam Proses
Konferensi Internasional tentang Pemeliharaan Perangkat Lunak (ICSM’92), halaman 10--17. IEEE.
Delisle, N. dan Garlan, D. (1990). Menerapkan Spesifikasi Formal untuk Industri

Masalah: Spesifikasi Osiloskop. Perangkat Lunak IEEE, 7(5):29--37.
DeMarco, T. (1979). Analisis Terstruktur dan Spesifikasi Sistem. Prentice-Hall.
DeMarco, T. (1982). Mengontrol Proyek Perangkat Lunak. Yourdon Press.

528 BIBLIOGRAFI
DeMarco, T. dan Lister, T. (1989). Pengembangan Perangkat Lunak: State of the Art
vs.State of the Practice. Di dalam Prosiding Konferensi Internasional ke-11 tentang
Rekayasa Perangkat Lunak (ICSE11), halaman 271--275. IEEE.
DeMarco, T. dan Lister, T. (1999). Peopleware: Proyek dan Tim Produktif. Dorset
Rumah, edisi kedua.
DeMillo, R., Lipton, R., dan Perlis, A. (1979). Proses Sosial dan Buktinya Teorema
dan Program. Komunikasi ACM, 22(5):271--280.
DeRemer, F. dan Kron, H. (1976). Pemrograman-dalam-besar Versus
Pemrograman- di-yang-kecil. Transaksi IEEE pada Rekayasa Perangkat Lunak,
2(2):80--86.
Devanbu, P., Brachman, R., Selfridge, P., dan Ballard, B. (1991). LASI: A
Sistem Informasi Perangkat Komunikasi ACM,
Lunak Berbasis Pengetahuan.
34(5):34--49.
Diaz, M. dan Sligo, J. (1997). Bagaimana Peningkatan Proses Perangkat Lunak

Membantu Motorola. Perangkat Lunak IEEE, 14(5):75--81.
Dobrica, L. dan Niemelä, E. (2002). Survei Analisis Arsitektur Perangkat Lunak

Metode. Transaksi IEEE pada Rekayasa Perangkat Lunak, 28(7):638--653.
Dolotta, T., Haight, R., dan Mashey, J. (1978). Sistem Berbagi Waktu UNIX: The
Meja Kerja Programmer. Jurnal Teknis Sistem Bell, 57(6):2177--2200.
Downs, E., Clare, P., dan Coe, I. (1992). SSADM: Analisis dan Desain Sistem
Terstruktur metode. Prentice-Hall, edisi kedua.
Ducasse, S., Gˆırba, T., dan Peta Distribusi. Di dalam Proses
Kuhn, A. (2006).
Konferensi Internasional tentang Pemeliharaan Perangkat Lunak (ICSM’06), halaman 203--212. IEEE.
Dunsmore, A., Roper, M., dan Wood, M. (2002). Investigasi Lebih Lanjut ke
Pengembangan dan Evaluasi Teknik Membaca untuk Inspeksi Kode Berorientasi
Objek. Di dalam Prosiding Konferensi Internasional ke-24 tentang Rekayasa
Perangkat Lunak (ICSE24), halaman 47--57. IEEE.
Eischen, K. (2002). Pengembangan Perangkat Lunak: Pandangan Orang Luar.

El Emam, K., Benlarbi, S., Goel, N., dan Rai, S. (2001). Efek Pembaur Ukuran Kelas
pada Validitas Metrik Berorientasi Objek. Transaksi IEEE pada Rekayasa Perangkat
Lunak, 27(7):630--650.
El Emam, K., Drouin, J., dan Melo, W. (1997). SPICE: Teori dan Praktek Perangkat
Lunak Peningkatan Proses dan Penentuan Kemampuan. IEEE.
El Emam, K. dan Madhavji, N. (1995). Keandalan Pengukuran Organisasi
Kematangan. Proses Perangkat Lunak -- Peningkatan dan Praktek, 1(1):3--25.
BIBLIOGRAFI 529
Elshoff, J. (1976). Mengukur Program PL-1 Komersial Menggunakan Kriteria Halstead.
Pemberitahuan SIGPLAN ACM, 11(5):38--76.
Epstein, R. (1997). Kasus Robot Pembunuh. John Wiley & Sons.

Erdogmus, H., Morisio, M., dan Torchiano, M. (2005). Tentang Keefektifan
Pendekatan Tes-Pertama untuk Pemrograman. Transaksi IEEE pada Rekayasa
Perangkat Lunak,31(3):226--237.
Estublier, J., Leblang, D., van der Hoek, A., Conradi, R., Clemm, G., Tichy, W., dan
Wiborg-Weber, D. (2005). Dampak Penelitian Rekayasa Perangkat Lunak terhadap
Praktik Manajemen Konfigurasi Perangkat Lunak. Transaksi ACM pada Rekayasa
dan Metodologi Perangkat Lunak, 14(4):383--430.
Fagan, M. (1976). Inspeksi Desain dan Kode untuk Mengurangi

Kesalahan dalam Program
Perkembangan. Jurnal Sistem IBM, 15(3):182--211.
Fagan, M. (1986). Kemajuan dalam Pemeriksaan. Transaksi IEEE pada Rekayasa Perangkat Lunak,
12(7):744--751.
Fairley, D. (2002). Membuat Estimasi Akurat. Perangkat Lunak IEEE, 19(6):61--63.

Fang, Y. dan Neufeld, D. (2006). Haruskah Saya Tetap atau Haruskah Saya Pergi?
Komitmen Pekerja terhadap Organisasi Virtual. Di dalam Prosiding Konferensi
Internasional Hawaii ke-39 tentang Ilmu Informasi (HICSS). IEEE.
Fayad, M. (1997). Proses Pengembangan Perangkat Lunak: Kejahatan yang Diperlukan. Komunikasi
dari ACM, 40(9):101--103.
Fayad, M. dan Laitinen, M. (1997). Penilaian Proses Dianggap Boros.

Komunikasi ACM, 40(11):125--128.
Feldman, S. (1978). Make : Program untuk Merawat Program Komputer. Teknis
laporan, AT&T.
Fenton, N. dan Pfleeger, S. L. (1996). Metrik Perangkat Lunak: Pendekatan Ketat & Praktis.
Thomson Computer Press, edisi kedua.
Fetzer, JH (1988). Verifikasi Program: Ide Yang Sangat Baik. Komunikasi

ACM,31(9):1048--1063. Lihat juga referensi: Komunikasi ACM 32(3):374--381
(1989) dan 32(4):506--512 (1989).
Fischer, G. (1986). Dari Interaktif ke Sistem Cerdas. Dalam Skwirzynski, J.,
editor,Metode Perancangan Sistem Perangkat Lunak, jilid 22 dari NATO ASI Seri F:
Ilmu Komputer dan Sistem, halaman 185--212. Springer Verlag.
Fischer, M. dan Gall, H. (2004). Memvisualisasikan evolusi fitur perangkat lunak
berskala besar berdasarkan data laporan masalah dan modifikasi. Jurnal
Pemeliharaan dan Evolusi Perangkat Lunak: Penelitian dan Praktek, halaman
385--403.
530 BIBLIOGRAFI
Fitzgerald, B. dan O'Kane, T. (1999). Studi Longitudinal Proses Perangkat Lunak
Peningkatan. Perangkat Lunak IEEE, 16(3):37--51.
Fitzsimmons, A. dan Cinta, T. (1978). Tinjauan dan Evaluasi Ilmu Perangkat Lunak.
Survei Komputasi ACM, 10(1):3--18.
Fjelstad, R. dan Hamlen, W. (1979). Studi Pemeliharaan Program Aplikasi: Laporan

kepada Responden kami. Di dalam Prosiding PANDUAN 48.
Bunga, S. (1996). Kegagalan Perangkat Lunak: Kegagalan Manajemen. John

Wiley & Sons.
Floyd, C., Mehl, W.-M., Reisin, F.-M., Schmidt, G., dan Wolf, G. (1989). Keluar dari
Skandinavia: Pendekatan Alternatif untuk Desain Perangkat Lunak dan
Pengembangan Sistem.Interaksi Manusia-Komputer, 4:253--350.
Folmer, E., van Gurp, J., dan Bosch, J. (2003). Kerangka Kerja untuk Menangkap
Hubungan antara Kegunaan dan Arsitektur Perangkat Lunak. Peningkatan dan
Praktek Proses Perangkat Lunak, 8(2):67--87.
Fowler, M. (1999). Refactoring: Meningkatkan Desain Kode yang Ada. Addison

Wesley.
Fowler, M. (2003). Siapa yang Membutuhkan Arsitek. Perangkat Lunak IEEE,

20(5):11--13.
Fowler, M. (2004). Distilasi UML. Addison Wesley, edisi ketiga.
Frankl, P. dan Weiss, S. (1993). Perbandingan Eksperimental Keefektifan Pengujian

Cabang dan Pengujian Aliran Data. Transaksi IEEE pada Rekayasa Perangkat
Lunak,19(8):774--787.
Frankl, P., Weiss, S., dan Hu, C. (1997). Semua Penggunaan vs Pengujian Mutasi: An
Perbandingan Eksperimental Efektivitas. Jurnal Sistem dan Perangkat Lunak,
38(3):235--253.
Frankl, P. dan Weyuker, E. (1993a). Analisis Formal dari Kemampuan

Deteksi-KesalahanMetode Pengujian. Transaksi IEEE pada Rekayasa Perangkat
Lunak, 19(3):202--213.
Frankl, P. dan Weyuker, E. (1993b). Peningkatan yang Dapat Dibuktikan pada

Pengujian Cabang. IEEE Transaksi pada Rekayasa Perangkat Lunak,
19(10):962--975.
Freeman, P. dan Wasserman, A., editor (1983). Tutorial: Teknik Desain Perangkat
Lunak. IEEE EZ514.
Fuggetta, A. (1993). Klasifikasi Teknologi CASE. Komputer IEEE, 26(12):25-

-38.
Fuggetta, A. dan Wolf, A., editor (1996). Proses Perangkat Lunak -- Peningkatan
dan Praktek. John Wiley & Sons.
BIBLIOGRAFI 531
Gamma, E., Helm, R., Johnson, R., dan Vlissides, J. (1995). Pola Desain: Elemen dari
Perangkat Lunak Berorientasi Objek yang Dapat Digunakan Kembali. Addison-Wesley.
Gane, C. dan Sarson, T. (1979). Analisis Terstruktur dan Analisis Sistem: Alat dan
Teknik. Prentice-Hall.
Garlan, D., Kaiser, G., dan Notkin, D. (1992). Menggunakan Abstraksi Alat untuk Menulis
Sistem. Komputer IEEE, 25(6):30--38.
Garmus, D. dan Herron, D. (1996). Mengukur Proses Perangkat Lunak: Panduan Praktis untuk
Pengukuran Fungsional. Prentice-Hall.
Gartner (2001). Mendeskripsikan Model Capability Maturity. Ukur itu.
Garvin, D. (1984). Apa yang sebenarnya dimaksud dengan 'Kualitas Produk'? Tinjauan Manajemen
Sloan.
Gelperin, D. dan Hetzel, B. (1988). Pertumbuhan Pengujian Perangkat Lunak. Komunikasi

dari ACM, 31(6):687--695.
Gibson, V. dan Senn, J. (1989). Struktur Sistem dan Pemeliharaan Perangkat

Lunak
Pertunjukan. Komunikasi ACM, 32(3):347--358.
Gilb, T. (1988). Prinsip Manajemen Rekayasa Perangkat Lunak. Addison-Wesley.
Gilb, T. dan Graham, D. (1993). Inspeksi Perangkat Lunak. Addison Wesley.
Gˆırba, T. dan Ducasse, S. (2006). Sejarah pemodelan untuk menganalisis evolusi perangkat lunak.
Jurnal Pemeliharaan dan Evolusi Perangkat Lunak: Penelitian dan Praktek, 18:207--236.
Gˆırba, T., Ducasse, S., dan Lanza, M. (2004). Cuaca Kemarin: Memandu upaya
rekayasa balik awal dengan meringkas evolusi perubahan. Di dalam
ProsidingKonferensi Internasional tentang Pemeliharaan Perangkat Lunak
(ICSM'04), halaman 40--49. IEEE.
Godfrey, M. dan Tu, Q. (2000). Evolusi dalam Perangkat Lunak Sumber Terbuka:
Studi Kasus.In Prosiding 2000 Konferensi Internasional tentang Pemeliharaan
Perangkat Lunak (ICSM’00), halaman131--142. IEEE.
Goguen, J. (1986). Pengantar OBJ: Bahasa untuk Menulis dan Menguji Spesifikasi
Program Aljabar Formal. Dalam Gehani, N. dan McGettrick, A., editor, Teknik
Spesifikasi Perangkat Lunak, halaman 391--419. Addison-Wesley.
Goguen, J. dan Jirotka, M., editor (1994). Rekayasa Persyaratan: Sosial dan Teknis
Masalah. Pers Akademik, Boston.
Goguen, J. dan Linde, C. (1993). Teknik untuk Di dalam

Elisitasi Persyaratan.
Prosiding 1st International Symposium on Requirements Engineering (RE93), halaman 152--164,San
Diego. IEEE.
532 BIBLIOGRAFI
Cukup baik, J. dan Gerhart, S. (1975). Menuju Teori Seleksi Data Uji. Transaksi
IEEE pada Rekayasa Perangkat Lunak, 1(2):156--173.
Gopal, A., Krishnan, M., Mukhopadhyay, T., dan Goldenson, D. (2002). Mea-
Tentu Program dalam Pengembangan Perangkat IEEE
Lunak: Penentu Kesuksesan.
Transaksi pada Rekayasa Perangkat Lunak, 28(9):863--875.
Gordon, V. dan Bieman, J. (1994). Pembuatan Prototipe Cepat: Pelajaran yang

Dipetik. Perangkat Lunak IEEE, 12(1):85--95.
Gotel, O. dan Finkelstein, A. (1994). Analisis Masalah Ketertelusuran Persyaratan.

Di dalam Prosiding Konferensi Internasional tentang Rekayasa Persyaratan,
halaman 94--101.IEEE.
Gotterbarn, D. (1999). Bagaimana Kode Etik Rekayasa Perangkat Lunak Baru

Mempengaruhi Anda. Perangkat Lunak IEEE, 16(6):58--64.
Grady, R. dan Caswell, D. (1987). Metrik Perangkat Lunak: Membangun Program

Seluruh Perusahaan. Prentice-Hall.
Grady, R. dan van Slack, T. (1994). Pelajaran Penting dalam Mencapai Inspeksi
Luas Menggunakan. Perangkat Lunak IEEE, 11(4):46--57.
Greevy, O., Ducasse, S., dan Gˆırba, T. (2006). Menganalisis evolusi perangkat
lunak melalui tampilan fitur. Jurnal Pemeliharaan dan Evolusi Perangkat Lunak:
Penelitian dan Praktek, halaman425--456.
Guindon, R. dan Curtis, B. (1988). Kontrol Proses Kognitif selama Desain:

Alat Apa yang Akan Mendukung Perancang Di dalam Prosiding CHI’88, halaman
Perangkat Lunak?
263--268. ACM.
Gunning, R. (1968). Teknik Menulis Jelas. McGraw-Hill.
Gyim'othy, T., Ferenc, R., dan Siket, I. (2005). Validasi Empiris Metrik Berorientasi
Objek pada Perangkat Lunak Sumber Terbuka untuk Prediksi Kesalahan. Rekayasa
Perangkat Lunak Transaksi IEEE, 31(10):897--910.
Hall, T. dan Fenton, N. (1997). Menerapkan Program Metrik Perangkat Lunak yang
Efektif. Perangkat Lunak IEEE, 14(2):55--65.
Halstead, M. (1977). Elemen Ilmu Perangkat Lunak. Perusahaan Penerbitan Belanda

Utara.
Hamlet, D. dan Taylor, R. (1990). Pengujian Partisi Tidak Menginspirasi Keyakinan.
Harel, D. (1988). Pada Formalisme Visual. Komunikasi ACM, 31(5):514--530.
Harrison, W. (2004). Clueless--dan Oblivious. Perangkat Lunak IEEE,

21(3):5--7.
BIBLIOGRAFI 533
Harrold, M. (1999). Menguji Perangkat Lunak yang Jurnal Sistem dan Perangkat
47(2/3):173--181. Berkembang. Lunak,
Harrold, M., Offutt, A., dan Tewary, K. (1997). Pendekatan Fault Modeling dan Fault
Seeding Menggunakan Program Dependence Graph. Jurnal Sistem dan Perangkat
Lunak,36(3):273--295.
Hatley, D. dan Pirbhai, I. (1988). Strategi untuk Spesifikasi Sistem Real-Time. Dorset
Rumah.
Heemstra, F. (1989). Berapa Biaya Perangkat Lunak. Tesis PhD, Universitas Teknik
Eindhoven, Belanda. Dalam bahasa Belanda.
Penjual Henderson, B. (1992). Modularisasi dan Kompleksitas Cyclomatic McCabe.

Henri, S. dan Kafura, D. (1981). Metrik Struktur Perangkat Lunak Berdasarkan Informasi
Mengalir. Transaksi IEEE pada Rekayasa Perangkat Lunak, 7(5):510--518.
Henry, J. dan Kain, J. (1997). Perbandingan Software Perfective dan Corrective

Pemeliharaan. Jurnal Pemeliharaan Perangkat Lunak: Penelitian dan Praktek, 9:281--297.
Herbsleb, J., Zubrow, D., Goldenson, D., Hayes, W., dan Paulk, M. (1997). Kualitas
Perangkat Lunak dan Model Kematangan Kemampuan. Komunikasi ACM,
40(6):30--40.
Highsmith, J. (2004). Manajemen Proyek Agile. Addison-Wesley.
Hirschheim, R. dan Klein, H. (1989). Empat Paradigma Sistem Informasi

Perkembangan. Komunikasi ACM, 32(10):1199--1216.
Hitz, M. dan Montazeri, B. (1996). Suite Metrik Chidamber dan Kemerer: Perspektif
Teori Pengukuran. IEEETransactionsonSoftware Engineering, 22(4):267--271.
Ho, W. dan Olsson, R. (1996). Model Berlapis untuk Membangun Debugging dan
Alat Pemantau. Jurnal Sistem dan Perangkat Lunak, 34(3):211--222.
Hødalsvik, G. dan Sindre, G. (1993). Untuk tujuan Analisis Berorientasi Objek.

Di dalam Proses OOPSLA'93, Pemberitahuan ACM SIGPLAN 28 (10), halaman 240--255.
Hofman, H. dan Lehner, F. (2001). Rekayasa Kebutuhan sebagai Faktor Keberhasilan dalam
Proyek Perangkat Lunak. Perangkat Lunak IEEE, 18(4):58--66.
Hofmeister, C., Kruchten, P., Nord, R., Obbink, H., Ran, A., and America, P. (2007).
Model Umum Desain Arsitektur Perangkat Lunak Berasal dari Lima Pendekatan
Industri. Jurnal Sistem dan Perangkat Lunak, 80(1):106--126.
534 BIBLIOGRAFI
Hops, J. dan Sherif, J. (1995). Pengembangan dan Penerapan Model Kompleksitas
Komposit dan Metrik Kompleksitas Relatif dalam Lingkungan Pemeliharaan
Perangkat Lunak. Jurnal Sistem dan Perangkat Lunak, 31(2):157--169.
Hosier, W. (1961). Jebakan dan Perlindungan dalam Sistem Digital Real-Time Dengan
Penekanan pada Pemrograman. Transaksi IRE pada Manajemen Rekayasa, halaman
99--115.
Howden, W. (1982). Validasi Program Ilmiah. Survei Komputasi ACM,

14(2):193--227.
Howden, W. (1985). Teori dan Praktek Pengujian Fungsional. Perangkat Lunak

IEEE, 2(5):6--17.
Humphrey, W. (1988). Mencirikan Proses Perangkat Lunak: Kerangka Kematangan.

Perangkat Lunak IEEE, 5(2):73--79.
Humphrey, W. (1989).Mengelola Proses Perangkat Lunak. Seri SEI dalam Rekayasa

Perangkat Lunak. Addison-Wesley.
Humphrey, W. (1996). Menggunakan Proses Perangkat Lunak Pribadi yang

Ditetapkan dan Diukur. Perangkat Lunak IEEE, 13(3):77--88.
Humphrey, W. (1997a). Pengantar Proses Perangkat Lunak Pribadi.

Addison-Wesley.
Humphrey, W. (1997b). Mengelola Orang Teknis. Addison-Wesley.

Humphrey, W., Kitson, D., dan Kasse, T. (1989). Praktik Rekayasa Perangkat Lunak:
Sebuah Laporan Pendahuluan. Di dalam Prosiding Konferensi Internasional ke-11
tentang Rekayasa Perangkat Lunak (ICSE11), halaman 277--288. IEEE.
Berburu, A. dan Thomas, D. (2003). Pengujian Unit Pragmatis. Rak Buku Pragmatis.
IEEE (2000). Praktik yang Direkomendasikan IEEE untuk Deskripsi Arsitektur
Perangkat Lunak- Sistem Intensif. Laporan teknis, IEEE.
IEEE1012 (1986). Standar IEEE untuk Paket Verifikasi dan Validasi Perangkat
Lunak. Standar IEEE 1012.
IEEE1219 (1992). Standar IEEE untuk Pemeliharaan Perangkat Lunak.

Standar IEEE 1219.
IEEE610 (1990). Daftar Istilah Standar IEEE untuk Terminologi Rekayasa Perangkat
Lunak. Standar IEEE 610.12.
IEEE730 (1989). Standar IEEE untuk Rencana Jaminan Kualitas Perangkat Lunak. IEEE Std 730.
IEEE828 (1990). Standar IEEE untuk Rencana Manajemen Konfigurasi Perangkat

Lunak. IEEE Std 828. Revisi IEEE Std 828-1983.
IEEE829 (1998). Standar IEEE untuk Dokumentasi Pengujian Perangkat

Lunak. IEEE Std 829.
BIBLIOGRAFI 535
IEEE830 (1993). Praktik yang Direkomendasikan IEEE untuk Spesifikasi Persyaratan Perangkat Lunak.
Standar IEEE
830.
IEEE983 (1986). Standar IEEE tentang perencanaan Jaminan Kualitas Perangkat Lunak. IEEE Std 983.
Iivari, J. (1996). Mengapa alat CASE tidak digunakan? Komunikasi ACM, 39(10):94-
-103.
Ishikawa, K. (1985). Apa itu Kontrol Kualitas Total? Cara Jepang. Prentice-Hall.
ISO9126 (2001). ISO/IEC 9126-1: Rekayasa Perangkat Lunak -- Kualitas Produk -- Bagian 1: Kualitas
Model. ISO.
Jackson, M. (1975). Prinsip Desain Program. Pers Akademik.
Jackson, M. (1983). Pengembangan sistem. Prentice-Hall.
Jankowski, D. (1994). Kelayakan Metodologi Analisis Terstruktur CASE

Mendukung. Catatan Rekayasa Perangkat Lunak ACM, 19(2):72--82.
Janzen, D. dan Saiedian, H. (2005). Pengembangan Berbasis Tes: Konsep, Taksonomi,

dan Arah Masa Depan. Komputer IEEE, 38(9):43--50.
Jarzabek, S. dan Huang, R. (1998). Kasus untuk Alat KASUS yang Berpusat pada Pengguna.
Jarzabek, S. dan Wang, G. (1998). Desain Berbasis Model Reverse Engineering

Peralatan. Jurnal Pemeliharaan Perangkat Lunak: Penelitian dan Praktek, 10:353--380.
Jeffries, R., Anderson, A., dan Hendrickson, C. (2001). Pemrograman Ekstrim Terpasang.
Addison-Wesley.
Jeske, D. dan Zhang, X. (2005). Beberapa pendekatan sukses untuk keandalan perangkat lunak
pemodelan dalam industri. Jurnal Sistem dan Perangkat Lunak, 74(1):85--100.
J'ez'equel, J.-M. dan Meyer, M. (1997). Desain dengan Kontrak: Pelajaran dari Ariane.
Johnson, L. (1998). Pandangan Dari Tahun 1960-an: Bagaimana Industri Perangkat Lunak Dimulai.
IEEE
Sejarah Sejarah Komputasi, 20(1):36--42.
Jonassen Hass, A. (2002). Prinsip dan Praktek Manajemen Konfigurasi. Addison-

Wesley.
Jones, C. (1986). Produktivitas Pemrograman. McGraw-Hill.
Jones, C. (1989). Pemodelan Peningkatan Perangkat Lunak. Jurnal Pemeliharaan Perangkat Lunak:
Penelitian dan Praktek, 1(2):91--100.
536 BIBLIOGRAFI
Jones, C. (1999). Euro, Y2K, dan Urut Tenaga Kerja Perangkat Lunak AS.
Jones, C. (2006). Ekonomi Pemeliharaan Perangkat Lunak di Dua Puluh Satu

Century, Versi 3, 14 Februari 2006. Laporan teknis, http://www.spr.com.
Jørgensen, M. (2005). Panduan Praktis untuk Upaya Perangkat Lunak Berbasis
Penilaian Pakar Perkiraan. Perangkat Lunak IEEE, 22(3):57--63.
Jørgensen, M. dan Grimstad, S. (2004). Optimisme berlebihan dalam

Pengembangan Perangkat Lunak Proyek: "Kutukan pemenang". Tingkatkan,
Buletin Peningkatan Proses Perangkat Lunak, (4).
JSS (1995). Edisi khusus tentang Metrik Perangkat Lunak. Jurnal Sistem dan
Perangkat Lunak, 31(2).
Juristo, N., Moreno, A., dan Silva, A. (2002). Apakah dia Industri Eropa Bergerak
menuju Memecahkan Masalah Rekayasa Persyaratan? Perangkat Lunak IEEE,
19(6):70--77.
Juristo, N., Moreno, A., dan Vegas, S. (2004). Meninjau 25 Tahun Pengujian
Eksperimen Teknik. Rekayasa Perangkat Lunak Empiris, 9:7--44.
Kamsties, E. dan Lott, C. (1995). Evaluasi Empiris dari Tiga Teknik Deteksi Cacat. Di
Schäfer, W. dan Botella, P., editor, Rekayasa Perangkat Lunak -- ESEC ’95,LNCS
989, halaman 362--383. Springer Verlag.
Kaner, C. dan Bond, W. (2004). Metrik Rekayasa Perangkat Lunak: Apa yang
Mereka Ukur dan Bagaimana Kita Tahu. Di dalam Prosiding Simposium Metrik
Perangkat Lunak Internasional ke-10 (Metrik 2004), halaman 1--12. IEEE.
Kano (1993). Metode Kano untuk Memahami Kualitas yang Ditentukan Pelanggan.
Tengah untuk Jurnal Kualitas Manajemen, 2(4):3--36.
Karlstrom, D. dan Runeson, P. (2005). Menggabungkan Metode Agile dengan
State-Gate Manajemen proyek. Perangkat Lunak IEEE, 22(3):43--49.
Kazman, R., Bass, L., dan Klein, M. (2006). Komponen penting dari perangkat lunak
desain dan analisis arsitektur. Jurnal Sistem dan Perangkat Lunak, 79(8):1207--1216.
Tertarik, P. (1991). Membentuk Masa Depan: Desain Bisnis melalui Teknologi

Informasi, Harvard Pers Sekolah Bisnis, Cambridge, MA.
Keil, M. dan Carmel, E. (1995). Tautan Pelanggan-Pengembang dalam
Pengembangan Perangkat Lunak. Komunikasi ACM, 38(5):33--44.
Kemerer, C. (1993). Keandalan Pengukuran Titik Fungsi. Komunikasi dari

ACM, 36(2):85--97.
Kemerer, C. dan Porter, B. (1992). Meningkatkan Keandalan Titik Fungsi

Pengukuran: Sebuah Studi Empiris. Transaksi IEEE pada Rekayasa Perangkat Lunak,
18(11):1011--1024.
BIBLIOGRAFI 537
Kemerer, C. dan Pembantaian, S. (1997). Penentu Pemeliharaan Perangkat Lunak

Profil: Investigasi Empiris. Jurnal Pemeliharaan Perangkat Lunak: Riset dan Praktik, 9:235--251.
Kernighan, B. dan Mashey, J. (1981). Lingkungan Pemrograman UNIX. IEEE

Komputer, 14(4):12--24.
Raja, D. (1988). Membuat Perangkat Lunak yang Efektif: Perancangan Program Komputer
Menggunakan Jackson
Metodologi. Yourdon Press.
Kitchenham, B. dan Pfleeger, S. (1996). Kualitas Perangkat Lunak: Target yang Sulit Dipahami. IEEE
Kitchenham, B., Pfleeger, S., dan Fenton, N. (1995). Menuju Kerangka

untuk Validasi Pengukuran Transaksi IEEE pada Rekayasa Perangkat Lunak,
Perangkat Lunak.
21(12):929--943.
Klein, G., Jiang, J., dan Tesch, D. (2002). Dicari: Tim Proyek dengan Perpaduan IS
Orientasi Profesional. Komunikasi ACM, 45(6):81--87.
Knight, J. dan Ammann, P. (1985). Evaluasi Eksperimental Metode Sederhana

untuk Kesalahan Program Pembibitan. Di dalam Prosiding Konferensi Internasional ke-8
tentang Perangkat Lunak
Rekayasa (ICSE8), halaman 337--342. IEEE.
Knight, J. dan Myers, E. (1993). Teknik Inspeksi yang Ditingkatkan. Komunikasi

dari ACM, 36(11):50--61.
Kohno, T., Stubblefield, A., Rubin, A., dan Wallach, D. (2004). Analisis Sistem
Pemungutan Suara Elektronik. Di dalam Prosiding Simposium IEEE tentang
Keamanan dan Privasi, halaman27--42.
Koontz, H. dan O'Donnell, C. (1972). Prinsip Manajemen: Sebuah Analisis Manajerial

Fungsi. McGraw-Hill.
Kotonya, G. dan Sommerville, I. (1997). Persyaratan Rekayasa, Proses dan Teknik.

John Wiley & Sons.
Krasner, G. dan Paus, S. (1988). Buku masak untuk menggunakan Model--View--Controller

paradigma antarmuka pengguna di Smalltalk-80. Jurnal Pemrograman Berorientasi Objek,
1(3):26--49.
Kraut, R. dan Streeter, L. (1995). Koordinasi dalam Pengembangan Perangkat Lunak. Komunikasi-
kation ACM, 38(3):69--81.
Krogstie, J. (1994).Tentang Perbedaan antara Pengembangan

Fungsional dan
Pemeliharaan Fungsional. Jurnal Pemeliharaan Perangkat Lunak: Penelitian dan Praktek,
7:383--403.
538 BIBLIOGRAFI
Kruchten, P. (1995). Model Arsitektur Tampilan 4 + 1. Perangkat Lunak IEEE,
12(6):42--50.
Kruchten, P. (1999). Arsitek Perangkat Lunak. Di dalam Arsitektur Perangkat Lunak

(WICSA1), halaman 563--583. Penerbit Akademik Kluwer.
Kruchten, P. (2003). Proses Kesatuan Rasional, Sebuah Pengantar.

Addison-Wesley, ketiga mengedit.
Kruglinski, D. (1996). Di dalam Visual C++. Microsoft Tekan.

Kung, H.-J. dan Hsu, C. (1998). Model Siklus Hidup Pemeliharaan Perangkat Lunak. Di dalam
Prosiding Konferensi Internasional tentang Pemeliharaan Perangkat Lunak (ICSM’98), halaman 113--121.
Kuvaja, P., Simila, J., Krzanik, L., Bicego, A., Koch, G., dan Saukonen, S. (1994).
Penilaian dan Peningkatan Proses Perangkat Lunak: pendekatan BOOTSTRAP.
Penerbit Blackwell, Oxford, Inggris.
Lamsweerde, A.v. (2001). Rekayasa Persyaratan Berorientasi Tujuan: Tur Terpandu

Prosiding 5th International Symposium on Requirements Engineering (RE’01),
halaman 1--13.IEEE.
LaToza, T., Venolia, G., dan DeLine, R. (2006). Mempertahankan Model Mental:
Studi Kebiasaan Kerja Developer. Di dalam Prosiding Konferensi Internasional ke-28
tentang Rekayasa Perangkat Lunak (ICSE28), halaman 492--501. ACM.
Lawrence, M. (1981). Metodologi Pemrograman, Lingkungan Organisasi, dan

Produktivitas Pemrograman. Jurnal Sistem dan Perangkat Lunak, 2:257--269.
Lea, D. (1994). Christopher Alexander: Pengantar untuk Desain Berorientasi Objek-
ers. Catatan Rekayasa Perangkat Lunak ACM, 19(1):39--46.
Lederer, A. dan Prasad, J. (2000). Manajemen perangkat lunak dan estimasi biaya
eroor. Jurnal Sistem dan Perangkat Lunak, 50(1):33--42.
Leffingwell, D. dan Widrig, D. (2000). Mengelola Kebutuhan Perangkat Lunak --

Sebuah Kesatuan Mendekati. Addison-Wesley.
Lehman, M. (1974). Program, Kota dan Pelajar: Batas Pertumbuhan? Nomor 9 di

Pelantikan Seri Kuliah. Imperial College, London.
Lehman, M. (1980). Program, Siklus Hidup, dan Hukum Evolusi Perangkat

Lunak.Proses dari IEEE, 68(9):1060--1076.
Lehman, M. (1987). Model Proses, Program Proses, Dukungan Pemrograman. Di
dalamProsiding Konferensi Internasional ke-9 tentang Rekayasa Perangkat Lunak
(ICSE9), halaman 14--16. IEEE.
Lehman, M. dan Belady, L., editor (1985). Evolusi Program. Nomor 27 di APIC
Studi dalam Pengolahan Data. Pers Akademik.
BIBLIOGRAFI 539
Lehman, M., Ramil, J., Wernick, P., Perry, D., dan Turski, W. (1997). Metrik dan
Hukum Evolusi Perangkat Lunak -- Pandangan Tahun Sembilan Puluh. Di dalam
Prosiding Simposium Internasional ke-4 Tentang Metrik Perangkat Lunak (Metrik
97), halaman 20--32. IEEE.
Lethbridge, T., Singer, J., dan Maju, A. (2003). Bagaimana Insinyur Perangkat Lunak Menggunakan
Dokumentasi: Keadaan Praktek. Perangkat Lunak IEEE, 20(6):35--39.
Leveson, N. (1986). Keamanan Perangkat Lunak: Apa, Mengapa, dan Bagaimana. Survei Komputasi
ACM,
18(2):125--164.
Leveson, N. (1991). Masalah Keamanan Perangkat Lunak dalam Sistem Komputer

Tertanam.
Leveson, N. (1992). Mesin Uap Tekanan Tinggi dan Perangkat Lunak Di dalam
Komputer.
Prosiding Konferensi Internasional ke-14 tentang Rekayasa Perangkat Lunak (ICSE14), halaman
2--14.IEEE.
Leveson, N. dan Turner, C. (1993). Investigasi Kecelakaan Therac-25.

Lewandowski, S. (1998). Kerangka Kerja untuk Komputer Klien/Server Berbasis Komponen

pada. Survei Komputasi ACM, 30(1):3--27.
Li, W. dan Henry, S. (1993). Metrik Berorientasi Objek yang Memprediksi Keterawatan.
Jurnal Sistem dan Perangkat Lunak, 23(2):111--122.
Lientz, B. dan Swanson, E. (1980). Manajemen Pemeliharaan Perangkat Lunak. Addison-Wesley.
Linger, R., Mills, H., dan Witt, B. (1979). Pemrograman Terstruktur, Teori dan Praktek.
Addison-Wesley.
Lott, C. (1993). Dukungan Proses dan Pengukuran di SEE. Rekayasa Perangkat Lunak ACM
Catatan, 18(4):83--93.
Loucopoulos, P. dan Karakostas, V. (1995). Rekayasa Persyaratan Sistem. McGraw-

Bukit.
Lubars, M., Meredith, G., Potts, C., dan Richter, C. (1992). Analisis Berorientasi
Objek untuk Sistem Berkembang. Di dalam Prosiding Konferensi Internasional ke-14
tentang Rekayasa Perangkat Lunak (ICSE14), halaman 173--185. IEEE.
Lyons, M. (1981). Menyelamatkan Aset Perangkat Lunak Anda (Pemeliharaan Berbasis Alat). Di dalam
Prosiding Konferensi AFIPS, jilid 50, halaman 337--341.
Lyu, M., editor (1995). Handbook Rekayasa Keandalan Perangkat Lunak. McGraw-Hill.
Macala, R., Stuckey, Jr., L., dan Gross, D. (1996). Mengelola Khusus Domain,
Pengembangan Lini Produk. Perangkat Lunak IEEE, 13(3):57--68.
540 BIBLIOGRAFI
MacLean, A., Muda, R., Bellotti, V., dan Moran, T. (1991). Pertanyaan, Pilihan, dan
Kriteria: Elemen Desain Analisis Ruang. Interaksi Manusia-Komputer, 6:201--250.
Makro, A. dan Buxton, J. (1987). Kerajinan Rekayasa Perangkat Lunak.

Addison-Wesley.
Maiden, N., Gizikis, A., dan Robertson, S. (2004). Memprovokasi Kreativitas:

Bayangkan Seperti Apa Kebutuhan Anda. Perangkat Lunak IEEE,
21(5):68--75.
Maiden,N.andNcube,C.(1998). Memperoleh Persyaratan Pemilihan Perangkat

Lunak COTS. Perangkat Lunak IEEE, 15(2):46--56.
Mäntylä, M., Vanhanen, J., dan Lassenius, C. (2003). Taksonomi dan Studi Empiris
Awal tentang Bau Buruk dalam Kode. Di dalam Prosiding Konferensi Internasional
tentang Pemeliharaan Perangkat Lunak (ICSM'03), halaman 381--384.
Maranzano, J., Rozsypal, S., Zimmerman, G., Warnken, G., Wirth, P., dan Weiss,
D.(2005). Ulasan Arsitektur: Praktek dan Pengalaman. Perangkat Lunak IEEE,
22(2):34--43.
Martin, J. (1991). Pengembangan Aplikasi Cepat. MacMillan.
Martin, R. (2002). Pengembangan Perangkat Lunak Agile, Prinsip, Pola, dan Praktik.
Prentice-Hall.
Martin, R. dan Osborne, W. (1983). Panduan Pemeliharaan Perangkat Lunak. Biro

Nasional Standar, Washington. Publikasi Khusus NBS 500-106.
Mata-Toledo, R. dan Gustafson, D. (1992). Analisis Faktor Kompleksitas Perangkat

Lunak Pengukuran. Jurnal Sistem dan Perangkat Lunak, 17(3):267--273.
Maximilien, E. dan Williams, L. (2003). Menilai Pengembangan Berbasis Tes diBM.

Di dalam Prosiding Konferensi Internasional ke-25 tentang Rekayasa Perangkat
Lunak (ICSE25), halaman564--569. IEEE.
McCabe, T. (1976). Ukuran Kompleksitas. Transaksi IEEE pada Rekayasa

Perangkat Lunak, 2(4):308--320.
McCall, J., Richards, P., dan Walters, G. (1977). Faktor-faktor dalam Kualitas Perangkat Lunak.
Laporan Teknis RADC-TR-77-369, Departemen Perdagangan AS.
McClure, R. (1968). Aspek Manajemen Produksi. Dalam Naur dan Randell (1968),
halaman 72.
McCracken, D. dan Jackson, M. (1981). Posisi Penolakan Minoritas. Di dalam et

al.,W. C., redaktur, Analisis dan Desain Sistem: Landasan untuk tahun 1980-an,
halaman 551--553.Belanda Utara.
McIlroy, M. (1968). Komponen Perangkat Lunak yang Diproduksi Secara Massal. Di

Naur dan Randell (1968), halaman 88--98.
BIBLIOGRAFI 541
Medvidovic, N. dan Taylor, R. (2000). Kerangka Klasifikasi dan Perbandingan

untuk Bahasa Deskripsi Arsitektur Perangkat Transaksi IEEE pada Perangkat Lunak
Lunak.
Rekayasa, 26(1):70--93.
Mens, T. dan Tourw'e, T. (2004). Survei Refactoring Perangkat Lunak. Transaksi IEEE
tentang Rekayasa Perangkat Lunak, 30(2):126--139.
Metzger, P. (1987). Mengelola Orang Pemrograman. Prentice-Hall.
Meyer, B. (1985). Pada Formalisme dalam Spesifikasi. Perangkat Lunak IEEE, 2(1):6--26.
Meyer, B. (1992). Desain berdasarkan Kontrak. Komputer IEEE, 25(10):40--51.
Meyer, B. (1996). Realitas: Sepupu dua kali dipindahkan. Komputer IEEE, 29(7):96--97.
Miller, B., Fredrikson, L., dan Jadi, B. (1990). Sebuah Studi Eksperimental Keandalan
Fasilitas UNIX. Komunikasi ACM, 33(12):32--44.
Mills, H., Dyer, M., dan Linger, R. (1987). Rekayasa Perangkat Lunak Kamar Bersih. IEEE
Mintzberg, H. (1983). Struktur dalam Panca: Merancang Organisasi yang Efektif. Prentice-Hall.
Mockus, A., Fielding, R., dan Herbsleb, J. (2000). Studi Kasus Pengembangan
Perangkat Lunak Sumber Terbuka: Server Apache. Di dalam Prosiding 22nd
International Conferenceon Software Engineering (ICSE22), halaman 263--272.
IEEE.
Moran, T. dan Carroll, J. (1994). Dasar Pemikiran Desain: Konsep, Teknik, dan Penggunaan. Lawrence
Asosiasi Erlbaum.
Morisio, M., Seaman, C., Basili, V., Parra, A., Kraft, S., and Condon, S. (2002).
Pengembangan perangkat lunak berbasis COTS: Proses dan masalah terbuka.
Motschnig-Pitrik, R. (1996). Menganalisis Pengertian Atribut, Agregat, Bagian dan

Anggota dalam Pemodelan Data/Pengetahuan. Jurnal Sistem dan Perangkat Lunak,
33(2):113--122.
Moynihan, T. (1996). Perbandingan Eksperimental Orientasi Objek dan Dekomposisi

Fungsional sebagai Paradigma untuk Mengkomunikasikan Fungsionalitas Sistem
kepada Pengguna. Jurnal Sistem dan Perangkat Lunak, 33(2):163--170.
Moynihan, T. (2000). Mengatasi 'persyaratan-ketidakpastian': teori-of-

tindakan manajer proyek IS/perangkat lunak yang berpengalaman. Jurnal Sistem dan Perangkat
Lunak,53(2):99--109.
Musa, J., Iannino, A., dan Okumoto, K. (1987). Keandalan Perangkat Lunak:
Pengukuran,
Prediksi, Aplikasi. McGraw-Hill.
542 BIBLIOGRAFI
Mustapic, G., Wall, A., Norström, C., Crnkovic, I., Sandström, K., Fröberg, J.,
andAndersson, J. (2004). Pengaruh Dunia Nyata pada Arsitektur Perangkat Lunak --
Wawancara dengan Pakar Sistem Industri. Di dalam Prosiding 4th Working
IEEE/IFIP Conference on Software Architecture (WICSA4), halaman 101--111.
IEEE.
Myers, G. (1979). Seni Pengujian Perangkat Lunak. John Wiley & Sons.
Myers, G. (2004). Seni Pengujian Perangkat Lunak. Wiley, edisi kedua.
Myers, W. (1986). Bisakah Perangkat Lunak untuk SDI Bebas dari Kesalahan?
Myers, W. (1988). Kode Shuttle Mencapai Tingkat Kesalahan Sangat Rendah.

Mylopoulos, J., Chung, L., Liao, S., Wang, Menjelajahi

H., dan Yu, E. (2001). Alternatif
selama Analisis Persyaratan. Perangkat
Lunak IEEE, 18(1):92--96.
Naur, P. dan Randell, B., editor (1968). Rekayasa Perangkat Lunak, Laporan
Konferensi. Divisi Urusan Ilmiah NATO, Garmisch.
Nelson, E. (1966). Buku Pedoman Manajemen Estimasi Biaya Pemrograman

Komputer. Perusahaan Pengembangan Sistem. AD-A648750.
Neumann, P. (1995). Risiko Terkait Komputer. Addison-Wesley.
Niessink, F. dan van Vliet, H. (1997). Memprediksi Upaya Pemeliharaan dengan

FunctionPoints. Di dalam Prosiding Konferensi Internasional tentang Pemeliharaan
Perangkat Lunak (ICSM’97), halaman32--39. IEEE.
Niessink, F. dan van Vliet, H. (1998a). Menuju Layanan TI yang Matang. Proses
Perangkat Lunak -- Peningkatan dan Latihan, 4(2):55--71.
Niessink, F. dan van Vliet, H. (1998b). Menuju Program Pengukuran Matang. Dalam
Nesi, P. dan Lehner, F., editor, Prosiding Konferensi Euromicro ke-2 tentang
Pemeliharaan dan Reengineering Perangkat Lunak, halaman 82--88. IEEE.
Niessink, F. dan van Vliet, H. (1999). Pemeliharaan Perangkat Lunak dari Layanan
Perspektif. Laporan teknis, Universitas Gratis.
Norden, P. (1970). Alat yang Berguna untuk Manajemen Proyek. Dalam Starr, M.,
editor, Manajemen Produksi, halaman 71--101. Buku Pinguin.
Nosek, J. dan Palvia, P. (1990). Manajemen Pemeliharaan Perangkat Lunak:

Perubahan pada Dekade terakhir. Jurnal Pemeliharaan Perangkat Lunak:
Penelitian dan Praktek, 2(3):157--174.
Offutt, A., Harrold, M., dan Kolte, P. (1993). Sistem Metrik Perangkat Lunak untuk
Modul Kopel. Jurnal Sistem dan Perangkat Lunak, 20(3):295--308.
BIBLIOGRAFI 543
Offutt, A. dan Lee, S. (1994). Evaluasi Empiris Mutasi Lemah. IEEE

Osterweil, L. (1987). Proses Perangkat Lunak Juga Di dalam Prosiding 9

Perangkat Lunak.
Konferensi Internasional tentang Rekayasa Perangkat Lunak (ICSE9), halaman 2--13. IEEE.
Oz, E. (1994). Ketika Standar Profesional Lax: Kegagalan CONFIRM dan itu
Pelajaran. Komunikasi ACM, 37(10):29--36.
Halaman, D., Williams, P., dan Boyd, D. (1993). Laporan Penyelidikan ke Ambulans London
Melayani. Otoritas Kesehatan Daerah Thames Barat Daya.
Parnas, D. (1972). Tentang Kriteria yang Akan Digunakan dalam Mengurai Sistem Menjadi Modul.
Komunikasi ACM, 15(12):1053--1058.
Parnas, D. (1978). Merancang Perangkat Lunak untuk Kemudahan Perpanjangan

dan Kontraksi. Di dalamProsiding Konferensi Internasional ke-3 tentang Rekayasa
Perangkat Lunak (ICSE3), halaman 264--277.IEEE.
Parnas, D. (1985). Aspek Perangkat Lunak Sistem Pertahanan Strategis. Perangkat Lunak ACM
Catatan Rekayasa, 10(5):15--23.
Parnas, D. (1987). SDI 'Red Herrings' Miss the Boat. Komputer IEEE, 20(2):6--7.
Parnas, D. dan Clements, P. (1986). Proses Desain Rasional: Bagaimana dan Mengapa
Berpura-pura. Transaksi IEEE pada Rekayasa Perangkat Lunak, 12(2):251--257.
Parnas, D. dan Lawford, M. (2003a). Peran Inspeksi dalam Asuransi Kualitas Perangkat Lunak.
Parnas, D. dan Lawford, M. (2003b). Peran Inspeksi dalam Kualitas Perangkat Lunak
Jaminan. Transaksi IEEE pada Rekayasa Perangkat Lunak, 29(8):674--676.
Parnas, D. dan Weiss, D. (1987). Tinjauan Desain Aktif: Prinsip dan Praktik.
Parrish, A. dan Zweben, S. (1995). Tentang Hubungan antara Kriteria Pengujian

All-Uses, All-DU-Paths, dan All-Edges. Transaksi IEEE pada Rekayasa Perangkat
Lunak,21(12):1006--1009.
Patel, S., Chu, W., dan Baxter, R. (1992). Ukuran untuk Kohesi Modul Komposit.In
Prosiding Konferensi Internasional ke-14 tentang Rekayasa Perangkat Lunak
(ICSE14), halaman 38--48.IEEE, Melbourne.
Perry, D. dan Kaiser, G. (1991). Model Lingkungan Pengembangan Perangkat Lunak.
Perry, D. dan Wolf, A. (1992). Dasar untuk Studi Arsitektur Perangkat Lunak.
Catatan Rekayasa Perangkat Lunak ACM, 17(4):40--52.
544 BIBLIOGRAFI
Peterson, J. (1981). Teori Jaringan Petri dan Pemodelan Sistem. Prentice-Hall.
Petroski, H. (1994). Paradigma Desain: Sejarah Kasus Kesalahan dan

Penghakiman dalam Rekayasa. Pers Universitas Cambridge.
Pfleeger, S. (1995). Kematangan, Model, dan Sasaran: Cara Membuat Rencana

Metrik. Jurnal Sistem dan Perangkat Lunak, 31(2):143--155.
Pfleeger, S. (2000). Bisnis berisiko: apa yang belum kita pelajari tentang manajemen
risiko. Jurnal Sistem dan Perangkat Lunak, 53(3):265--273.
Pigoski, T. (1996). Pemeliharaan Perangkat Lunak Praktis. John Wiley & Sons.
Pintelas, P. dan Kallistros, V. (1989).Gambaran Umum Beberapa Desain Perangkat

Lunak
Bahasa. Jurnal Sistem dan Perangkat Lunak, 10(2):125--138.
Pohl, K. (1993). Tiga Dimensi Rekayasa Kebutuhan. Di Rolland, C., Bodart, F., dan
Cauvet, C., editor, Prosiding Konferensi Internasional Kelima tentang Rekayasa
Sistem Informasi Lanjutan (CAiSE’93), halaman 275--292. Springer Verlag.
Pohl, K., Böckle, G., dan van der Linden, F. (2005). Rekayasa Lini Produk
Perangkat Lunak. penerbit Springer.
Porter, A., Siy, H., Mockus, A., dan Votta, L. (1998). Memahami Sumber Variasi
dalam Inspeksi Perangkat Lunak. Transaksi ACM pada Rekayasa Perangkat Lunak
dan Metodologi, 7(1):41--79.
Porter, A., Siy, H., Toman, C., dan Votta, L. (1997). Eksperimen untuk Menilai
Biaya-Manfaat dari Inspeksi Kode dalam Pengembangan Perangkat Lunak Skala
Besar. Transaksi IEEE pada Rekayasa Perangkat Lunak, 23(6):329--346.
Porter, A., Votta, Jr., L., dan Basili, V. (1995). Membandingkan Metode Deteksi untuk
Inspeksi Persyaratan Perangkat Lunak: Eksperimen yang Direplikasi. Transaksi
IEEE pada Rekayasa Perangkat Lunak, 21(6):563--575.
Post, G., Kagan, A., dan Keim, R. (1998). Evaluasi Komparatif Alat KASUS.
Poston, R. (1987). Mencegah Kemungkinan Besar Kesalahan dalam Persyaratan.

Potts, C. (1993). Penelitian Rekayasa Perangkat Lunak Ditinjau Kembali. Perangkat

Lunak IEEE, 10(5):19-- 28.
Power, L. dan Weiss, Z., editor (1987). Tambahan Prosiding OOPSLA87. ACM.
Putnam, L. (1978). Solusi Empiris Umum untuk Ukuran Perangkat Lunak Makro dan
Masalah Estimasi. Transaksi IEEE pada Rekayasa Perangkat Lunak,
4(4):345--361.
BIBLIOGRAFI 545
Raba (2004). Laporan Agen Tepercaya Sistem Pemungutan Suara Diebold AccuVote-TS. RABA
Teknologi.
Rahgozar, M. dan Oroumchian, F. (2003). Strategi yang efektif untuk evolusi sistem
lama. Jurnal Pemeliharaan dan Evolusi Perangkat Lunak: Penelitian dan Praktek,
15:325--344.
Rainer, A. dan Hall, T. (2003). Analisis faktor secara kuantitatif dan kualitatif
mempengaruhi proses perangkat lunak. Jurnal Sistem dan Perangkat Lunak, 66(1):7--22.
Ramos, I., Berry, D., dan Carvalho, J. (2005). Rekayasa kebutuhan untuk organisasi
transformasi zasional. Teknologi Informasi dan Perangkat Lunak, 47(5):479--495.
Raymond, E. (1999). Katedral dan Bazaar. O'Reilly.
Reddin, W. (1970). Efektivitas Manajerial. McGraw-Hill.
Redmond, J. dan Ah-Chuen, R. (1990). Metrik Perangkat Lunak: Perspektif Pengguna.

Redwine, S. dan Teka-teki, W. (1985). Pematangan Teknologi Perangkat Lunak. Di dalam Proses
Konferensi Internasional ke-8 tentang Rekayasa Perangkat Lunak (ICSE8), halaman 189--200. IEEE.
Reifer, D. (2000). Pengembangan Web: Memperkirakan Perangkat Lunak Cepat-ke-Pasar. IEEE

Reiss, S. (1990). Menghubungkan Alat Menggunakan Message Passing di Lingkungan Lapangan.

Rettig, M. (1991). Tidak Ada yang Membaca Komunikasi ACM,

34(7):19--24. Dokumentasi.
Robertson, J. (2002). Eureka! Mengapa Analis Harus Menciptakan Persyaratan. IEEE

Rochkind, M. (1975). Sistem Kontrol Kode Sumber. Transaksi IEEE pada Perangkat Lunak
Rekayasa, 1(4):364--370.
Rothermel, G. dan Harrold, M. (1996). Menganalisis Teknik Pemilihan Tes Regresi

persetan. Transaksi IEEE pada Rekayasa Perangkat Lunak, 22(8):529--551.
Royce, W. (1970). Mengelola Pengembangan Sistem Perangkat Lunak Besar: Konsep

dan Teknik. Di dalam Prosiding IEEE WESCON, halaman 1--9. IEEE.
Royce, W. (1998). Manajemen Proyek Perangkat Lunak: Kerangka Kerja Terpadu. Addison-Wesley.
Rozanski, N. dan Woods, E. (2005). Arsitektur Sistem Perangkat Lunak: Bekerja dengan Pemangku
Kepentingan
menggunakan Sudut Pandang dan Perspektif. Addison-Wesley.
546 BIBLIOGRAFI
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., dan Lorensen, W. (1991).
Pemodelan dan Desain Berorientasi Objek. Prentice-Hall.
Rumbaugh, J., Jacobson, I., dan Booch, G. (1999). Referensi Bahasa Pemodelan
Terpadu Manual. Addison Wesley.
Rysselberghe, F. v. dan Demeyer, S. (2004). Mempelajari Informasi Evolusi

Perangkat Lunak Dengan Memvisualisasikan Sejarah Perubahan. Di dalam
Prosiding Konferensi Internasional tentang Pemeliharaan Perangkat Lunak
(ICSM'04), halaman 328--337. IEEE.
Saaty, T. (1990). Pengambilan Keputusan Multikriteria -- Proses Hirarki Analitik. Jilid

I, Seri AHP, McGraw Hill.
Sawyer, S. (2001). Perspektif Berbasis Pasar pada Pengembangan Sistem

Informasi.Komunikasi ACM, 44(11):97--102.
Schach, S., Jin, B., Yu, L., Heler, G., dan Offutt, J. Menentukan
(2003).
Distribusi Kategori Pemeliharaan: Survei versus Pengukuran. Rekayasa Perangkat Lunak
Empiris, 8:351--365.
Schwaber, K. dan Beedle, M. (2002). Pengembangan Perangkat Lunak Agile dengan

Scrum. Prentice-Hall.
Sebillotte, S. (1988). Perencanaan Hirarki sebagai Metode Analisis Tugas: Contoh Analisis
Tugas Kantor. Perilaku dan Teknologi Informasi, 7(3):275--293.
Selby, R., Basili, V., dan Baker, F. (1987). Pengembangan Perangkat Lunak
Cleanroom. IEEE Transaksi pada Rekayasa Perangkat Lunak, 13(9):1027--1037.
Serrano, N. dan Ciordia, I. (2004). Ant: Mengotomatiskan Proses Membangun

Aplikasi. Perangkat Lunak IEEE, 21(6):89--91.
Sharon, D. dan Bell, R. (1995). Alat yang Mengikat: Menciptakan Lingkungan

Terpadu. Perangkat Lunak IEEE, 12(2):76--85.
Shaw, M. (1996). Beberapa Pola untuk Arsitektur Perangkat Lunak. Di dalam

Prosiding Kedua Workshop Pola Bahasa untuk Pemrograman. Addison-Wesley.
Shaw, M. dan Clements, P. Panduan Lapangan untuk Boxologi: Pendahuluan

(1996).
Klasifikasi Gaya Arsitektur untuk Sistem Perangkat Lunak. Laporan teknikal,
Universitas Carnegie Mellon/Institut Rekayasa Perangkat Lunak.
Shaw, M., DeLine, R., Klein, D., Ross, T., Young, D., dan Zelesnik, G. (1995).
Abstraksi untuk Arsitektur Perangkat Lunak dan Alat untuk
Mendukungnya.Rekayasa Perangkat Lunak IEEETransaction, 21(4):314--335.
Shaw, M. dan Garlan, D. (1996). Arsitektur Perangkat Lunak: Perspektif tentang

Disiplin yang Muncul. Prentice-Hall.
BIBLIOGRAFI 547
Shepperd, M. (1990). Metrik Desain: Analisis Empiris. Rekayasa Perangkat Lunak

Jurnal, 5(1):3--10.
Shepperd, M. dan Ince, D. (1993). Kritik terhadap Tiga Metrik. Jurnal Sistem dan
Simmons, P. (1996). Hasil Kualitas: Menentukan Nilai Bisnis. Perangkat Lunak IEEE,
13(1):25--32.
Penyanyi, J. (1998). Praktik Pemeliharaan Perangkat Di dalam Prosiding

Lunak. Internasional
Konferensi tentang Pemeliharaan Perangkat Lunak (ICSM’98), halaman 139--145. IEEE.
Singer, J., Eles, R., dan Storey, M.-A. (2005). NavTracks: Mendukung Navigasi
dalam Pemeliharaan Perangkat Lunak. Di dalam Prosiding Konferensi Internasional
tentang Pemeliharaan Perangkat Lunak (ICSM'05), halaman 325--334. IEEE.
Perangkat Lunak (1994). Masalah khusus tentang Peningkatan Proses. Perangkat Lunak IEEE, 11(4).
Perangkat Lunak (1996a). Edisi Khusus tentang Mengelola Proyek Perangkat Lunak Besar. Perangkat
Lunak IEEE,
13(4).
Perangkat Lunak (1996b). Edisi Khusus tentang Software Tools Assessment. Perangkat Lunak IEEE,
13(5).
Perangkat Lunak (1997a). Edisi khusus tentang Mengelola Risiko. Perangkat Lunak IEEE, 14(3).
Perangkat Lunak (1997b). Masalah khusus tentang Pengukuran. Perangkat Lunak IEEE, 14(2).
Perangkat Lunak (1999). Edisi Khusus tentang Faktor Kesuksesan Kritis. Perangkat Lunak IEEE, 16(3).
Perangkat Lunak (2000). Edisi Khusus: Estimasi Perangkat Lunak. Perangkat Lunak IEEE, 17(6):22--70.
Perangkat Lunak (2003). Edisi Khusus: Keadaan Praktik dalam Rekayasa Perangkat Lunak. IEEE
Perangkat lunak, 20(6).
Perangkat Lunak (2005). Masalah khusus: Mengadaptasi Agility. Perangkat Lunak IEEE, 22(3):17--49.
Perangkat Lunak (2006). Masalah khusus: Arsitektur Perangkat Lunak. Perangkat Lunak IEEE,
23(2):22--87.
Soloway, E. (1986). Belajar Memprogram = Belajar Menyusun Mekanisme dan
Penjelasan. Komunikasi ACM, 29(9):850--858.
Soloway, E. dan Ehrlich, K. (1984). Studi Empiris Pengetahuan Pemrograman.

Sommerville, I. (2005). Rekayasa Persyaratan IEEE

Perangkat lunak, 22(1):16--23. Terintegrasi: Tutorial.
Sommerville, I., Bentley, R., Rodden, T., dan Sawyer, P. (1994). Sistem Koperasi
Desain. Jurnal Komputer, 37(5):357--366.
548 BIBLIOGRAFI
Sommerville, I. dan Sawyer, P. (1997). Sudut pandang: prinsip, masalah dan a

pendekatan praktis untuk rekayasa kebutuhan. Sejarah Rekayasa Perangkat Lunak,
3:101--130.
Soni, D., Nord, R., dan Hofmeister, C. (1995). Arsitektur Perangkat Lunak dalam
Aplikasi Industri. Di dalam Prosiding Konferensi Internasional ke-17 tentang
Rekayasa Perangkat Lunak (ICSE17), halaman 196--207. IEEE.
Sousa, M. dan Mozeira, H. (1998). Survey Proses Maintenance Software.In

Prosiding Konferensi Internasional tentang Pemeliharaan Perangkat Lunak
Spector, A. dan Gifford, D. (1986). Perspektif Ilmu Komputer tentang Bridge

Desain. Komunikasi ACM, 29(4):267--283.
SPIP (2006). Masalah Khusus: Memahami Pengembangan Perangkat Lunak

Bebas/Sumber Terbuka Proses. Proses Perangkat Lunak: Peningkatan dan
Praktek, 11(2):93--211.
St˚alhane, T., Borgersen, P., dan Arnesen, K. (1997). Dalam Pencarian Pelanggan
Tampilan Berkualitas. Jurnal Sistem dan Perangkat Lunak, 38(1):85--94.
Stapleton, J., editor (2003). DSDM, Pengembangan Berfokus Bisnis.

Addison-Wesley, edisi kedua.
Stark, G. dan Oman, P. (1997). Strategi Manajemen Pemeliharaan Perangkat

Lunak: Pengamatan dari Lapangan. Jurnal Pemeliharaan Perangkat Lunak:
Penelitian dan Praktek,9:365--378.
Stevens, W., Myers, G., dan Constantine, L. (1974). Desain Terstruktur. Sistem IBM
Jurnal, 13(2):115--139.
Stroud, J. (1967). Struktur Halus Waktu Psikologis. Akademi Annals NY Ilmu,

138:623--631.
Succi, G., Pedrycz, W., Stefanovic, M., dan Miller, J. (2003). Penilaian praktis model
untuk identifikasi kelas rawan cacat dalam sistem komersial berorientasi objek
menggunakan metrik desain. Jurnal Sistem dan Perangkat Lunak, 65(1):1--12.
Suryn, W., Hailey, V., dan Coster, A. (Juli/Agustus 2004). Hoge basis pengguna
potensial untuk ISO/IEC 90003. Sistem Manajemen ISO, halaman 34--39.
Sutcliffe, A. (1988). Pengembangan Sistem Jackson. Prentice-Hall.
Sutcliffe, A., Maiden, N., Minocha, S., dan Manuel, Mendukung

D. (1998).
Rekayasa Persyaratan Berbasis Skenario. Transaksi IEEE pada Rekayasa Perangkat
Lunak,24(12):1072--1088.
BIBLIOGRAFI 549
Sutton, S., Heimbigner, D., dan Osterweil, L. (1990). Konstruksi Bahasa untuk
Mengelola Perubahan di Lingkungan yang Berpusat pada Proses. Di dalam
SIGSOFT'90, Prosiding Simposium Keempat tentang Lingkungan Pengembangan
Perangkat Lunak. ACM.
Swanson, E. dan Beath, C. (1990). Departementalisasi dalam Pengembangan Perangkat Lunak
dan pemeliharaan. Komunikasi ACM, 33(6):658--667.
Symons, C. (1988). Analisis Titik Fungsi: Kesulitan dan Perbaikan. IEEE

Tahvanainen, V.-P. dan Smolander, K. (1990). Bibliografi KASUS beranotasi.

Taivalsaari, A. (1993). Tentang Pengertian Obyek. Jurnal Sistem dan Perangkat Lunak,
21(1):3--16.
Tan, W.-G. dan Gable, G. (1998). Sikap Personil Pemeliharaan Terhadap Pekerjaan
Pemeliharaan: Sebuah Analisis Komparatif. Jurnal Pemeliharaan Perangkat Lunak:
Penelitian dan Praktek, 10:59--74.
Tanenbaum, A., van Staveren, H., Keizer, E., dan Stevenson, J. (1983). Alat Praktis
untuk Membuat Kompiler Portabel. Komunikasi ACM, 26(9):654--662.
Tapscott, D. dan Caston, A. (1993). Pergeseran Paradigma: Janji Informasi Baru

Teknologi. McGraw-Hill.
Trammell, C., Binder, L., dan Snyder, C. (1992). Sistem Dokumentasi Kontrol
Produksi Otomatis: Studi Kasus dalam Rekayasa Perangkat Lunak Cleanroom.
ACMTransactions tentang Rekayasa dan Metodologi Perangkat Lunak, 1(1):81--94.
Tripp, L. (1988). Survei Notasi Grafis untuk Desain Program -- Pembaruan.

TRSE (1998). Edisi Khusus Manajemen Skenario. Transaksi IEEE pada Perangkat Lunak
Rekayasa, 24(12).
Tyree, J. dan Akerman, A. (2005). ArchitectureDecisions: Demystifying Architecture.

van der Linden, F. dan Müller, J. (1995). Membuat Arsitektur dengan Blok Bangunan.
van Deursen, A., Hofmeister, C., Koschke, R., Moonen, L., dan Riva, C.
(2004).Symphony: Rekonstruksi Arsitektur Perangkat Lunak Berbasis Tampilan. Di
dalam Prosiding 4thWorking IEEE/IFIP Conference on Software Architecture
(WICSA4), halaman 122--132. IEEE.
van Genuchten, M. (1991). Menuju Pabrik Perangkat Lunak. Tesis PhD, Universitas Teknik
Eindhoven, Belanda.
550 BIBLIOGRAFI
Verner, J. dan Cerpa, N. (1997). Prototyping: Apakah Pandangan Anda tentang
Keuntungannya Tergantung Pekerjaan Anda. Jurnal Sistem dan Perangkat
Lunak, 36(1):3--16.
Vessey, I. dan Conger, S. (1994). Spesifikasi Persyaratan: Objek Pembelajaran,

Proses, dan Metodologi Data. Komunikasi ACM, 37(5):102--113.
von Mayrhauser, A. dan Vans, A. (1995). Pemahaman Program Selama Perangkat

Lunak Pemeliharaan dan Evolusi. Komputer IEEE, 28(8):44--55.
von Mayrhauser, A., Vans, A., dan Howe, A. Pengertian Program

(1997).
Perilaku selama Penyempurnaan Perangkat Lunak Berskala Besar. Jurnal Pemeliharaan
Perangkat Lunak: Penelitian dan Praktek, 9:299--327.
Wallace, L. dan Keil, M. (2004). Risiko Proyek Perangkat Lunak dan Pengaruhnya
terhadap Proyek Hasil. Komunikasi ACM, 47(4):68--73.
Walston, C. dan Felix, C. (1977). Metode Pengukuran Pemrograman dan Perkiraan.

Jurnal Sistem IBM, 16(1):54--73.
Warner, J.-D. (1974). Konstruksi Logis Program. Stephen Kroese.
Weber, D. (1996). Ubah Set versus Ubah Paket. Di Somerville, I.,

editor, Prosiding Lokakarya Manajemen Konfigurasi Perangkat Lunak (SCM6), halaman
25--35.Springer, LNCS1167.
Wegner, P. (1984). Teknologi Perangkat Lunak Padat Modal. Perangkat Lunak IEEE,
1(3):7--45.
Wegner, P. (1992). Dimensi Pemodelan Berorientasi Komputer IEEE,

25(10):12--21. Objek.
Weidenhaupt, K., Pohl, K., Jarke, M., dan Haumer, P. (1998). Skenario di System
Pengembangan: Praktik Saat Ini. Perangkat Lunak IEEE, 15(2):34--45.
Weinberg, G. (1971). Psikologi Pemrograman Komputer. Van Nostrand Reinhold.
Weller, E. (1993). Pelajaran dari Tiga Tahun Data Inspeksi. Perangkat Lunak IEEE,
10(5):38--45.
Wendel, I. (1986). Alat Perangkat Lunak Pleistosen. Berita Pemeliharaan Perangkat

Lunak, 4(10):20.
Weyuker, E. (1988). Evaluasi Kecukupan Data Uji Perangkat Lunak Berbasis

Program Kriteria. Komunikasi ACM, 31(6):668--675.
Weyuker, E. (1990). Biaya Pengujian Aliran Data: Studi Empiris. IEEE Transaksi
pada Rekayasa Perangkat Lunak, 16(2):121--128.
Weyuker, E. (1993). Lebih Banyak Pengalaman dengan Pengujian Aliran Data.

Transaksi IEEE aktif Rekayasa Perangkat Lunak, 19(9):912--919.
BIBLIOGRAFI 551
Whittaker, J. (2000). Apa itu Pengujian Perangkat Lunak? Dan Mengapa Begitu Sulit. IEEE
Whittaker, J. dan Voas, J. (2000). Menuju Teori Perangkat Lunak yang Lebih Andal
Keandalan. Komputer IEEE, 33(12):36--42.
Wiborg-Weber, D. (1997). Ubah Set versus Ubah Paket: Membandingkan

Implementasi SCM Berbasis Perubahan. Di dalam Prosiding Lokakarya Internasional ke-7 tentang
Manajemen Konfigurasi Perangkat Lunak (SCM’7), halaman 25--35. Springer LNCS 1235.
Wiegers, K. (2002). Ulasan Sejawat dalam Perangkat Lunak --- Panduan Praktis. Addison-Wesley.
Wieringa, R. (1996). Rekayasa Persyaratan: Kerangka Kerja untuk Pemahaman. John Wiley &
Anak laki-laki.
Wieringa, R. (1998). Survei Spesifikasi Perangkat Lunak Terstruktur dan Berorientasi Objek
Metode dan Teknik kation. Survei Komputasi ACM, 30(4):459--527.
Sayap, J. (1988). Kajian 12 Spesifikasi Masalah Perpustakaan. Perangkat Lunak IEEE,

5(4):66--76.
Wohlwend, H. dan Rosenbaum, S. (1994). Peningkatan Perangkat Lunak Schlumberger

Program. Transaksi IEEE pada Rekayasa Perangkat Lunak, 20(11):833--839.
Wolverton, R. (1974). Biaya Pengembangan Perangkat Lunak Berskala Besar. Transaksi IEEE
di Komputer, halaman 615--636.
Kayu, M., Roper, M., Brooks, A., dan Miller, J. (1997). Membandingkan dan
Menggabungkan Teknik Deteksi Cacat Perangkat Lunak. Dalam Jazayeri, M. dan
Schauer, H., editor,Prosiding Konferensi Rekayasa Perangkat Lunak Eropa ke-6,
LNCS 1301, halaman 262--277.Springer Verlag.
Xia, F. (2000). Tentang Konsep Kopling, Pemodelan dan Pengukurannya. Jurnal

Sistem dan Perangkat Lunak, 50(1):75--84.
Yeh, D. dan Jeng, J.-H. (2002). Studi empiris tentang pengaruh departementalisasi
dan posisi organisasi pada pemeliharaan perangkat lunak. Jurnal Pemeliharaan dan
Evolusi Perangkat Lunak: Penelitian dan Praktek, 14:65--82.
Yourdon, E. dan Constantine, L. (1975). Desain Terstruktur. Yourdon Press.
Yu, L. dan Chen, K. (2006). Studi Empiris Upaya Pemeliharaan. Di dalamProsiding

Konferensi Internasional ke-8 tentang Rekayasa Perangkat Lunak dan Rekayasa
Pengetahuan (SEKE), halaman 242--245.
Zelkowitz, M. (1988). Pemanfaatan Sumber Daya Selama Pengembangan Perangkat Lunak. Jurnal
Sistem dan Perangkat Lunak, 8(4):331--336.
552 BIBLIOGRAFI
Zhu, H. (1996). Analisis Formal Subsume Hubungan Antara Pengujian Perangkat
Lunak Kriteria Kecukupan. Transaksi IEEE pada Rekayasa Perangkat Lunak,
22(4):248--255.
Zhu, H., Hall, P., dan Mei, J. (1997). Cakupan dan Kecukupan Pengujian Unit
Perangkat Lunak. Survei Komputasi ACM, 29(4):366--427.
Zucconi, L. (1989). Memilih Alat KASUS. Catatan Rekayasa Perangkat Lunak ACM,
14(2):42- -44.

Rekayasa Perangkat Lunak: Prinsip Dan Praktek: Hans Van Vliet

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

Rekayasa Perangkat Lunak: Prinsip Dan Praktek: Hans Van Vliet

Diunggah oleh

Hak Cipta:

Format Tersedia

Rekayasa Perangkat Lunak: Prinsip

Hans van Vliet

(c) Wiley, 2007

SAY Manajemen Perangkat Lunak 33

Bab 2 Pengantar Manajemen Rekayasa Perangkat Lunak 34

3 Siklus Hidup Perangkat Lunak Ditinjau Kembali 45

bagian 3 Siklus Hidup Perangkat Lunak Ditinjau Kembali 45

5 Manajemen Orang dan Organisasi Tim 8

6 Tentang Mengelola Kualitas Perangkat Lunak 1

8 Perencanaan dan Kontrol Proyek 1

II Siklus Hidup Perangkat Lunak 1

Bab 10Pemodelan 246

10.3.5 Diagram Komponen . . . . . . . . . . . . . . . . . . . 272

11 Arsitektur Perangkat Lunak 276

Bab 11Arsitektur Perangkat Lunak 276

11.5 Penilaian Arsitektur Perangkat Lunak . . . . . . . . . . . . . . . . . . . 306

12 Desain Perangkat Lunak 313

Bab 12Desain perangkat lunak 313

12.3.3 RUP Dikunjungi Kembali . . . . . . . . . . . . . . . . . . . . . . . . . 369

12.8 Ringkasan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384

13 Pengujian Perangkat Lunak 394

Bab 13Pengujian Perangkat Lunak 394

13.5.1 Cakupan Aliran Kontrol . . . . . . . . . . . . . . . . . . . . 420

13.8.1 Perbandingan Kriteria Kecukupan Tes . . . . . . . . . . . . 432

15 Alat Perangkat 494

15.3.1 Meja Kerja Analis . . . . . . . . . . . . . . . . . . . . . 501

Rekayasa perangkat lunak menyangkut metode dan teknik untuk

Gambar 1.1 Distribusi relatif dari biaya perangkat

Untuk waktu yang singkat Selasa lalu, Amerika Serikat membuat

Untuk kedua kalinya dalam beberapa hari, komputer yang rusak

1.1 Apa itu Rekayasa Perangkat

1.2 Tahapan dalam

Gambar 1.2 Tampilan sederhana dari pengembangan perangkat lunak

Rekayasa kebutuhan. Tujuan dari tahap rekayasa kebutuhan adalah untuk

– fungsi perangkat lunak yang akan dikembangkan;

– kemungkinan perluasan sistem di masa mendatang;

– jumlah dan jenis dokumentasi yang diperlukan;

– waktu respons dan persyaratan kinerja sistem lainnya.

Penerapan. Selama fase implementasi, kami berkonsentrasi pada individu

persyaratan (validasi). Hasil penambahan kegiatan verifikasi dan validasi pada

Kegiatan penting yang tidak diidentifikasi secara terpisah adalah dokumentasi.

Gambar 1.3 Upaya relatif untuk berbagai kegiatan

Tergantung pada kondisi batas tertentu, sifat-sifat sistem menjadi

1.3 Pemeliharaan atau

Setelah perangkat lunak dikirimkan, biasanya masih mengandung kesalahan yang,

– perbaikan pemeliharaan -- perbaikan kesalahan yang sebenarnya;

– adaptif pemeliharaan -- menyesuaikan perangkat lunak dengan perubahan lingkungan,

– perfeksionis pemeliharaan -- menyesuaikan perangkat lunak dengan

– preventif pemeliharaan -- meningkatkan kemampuan pemeliharaan sistem di

Gambar 1.4 Sebaran kegiatan pemeliharaan

Hasilnya adalah proses pengembangan perangkat lunak menjadi siklik, demikian

1.4 Dari Parit

'Bagaimana sebuah proyek benar-benar mendapat masalah?'

1.4.1 Ariane 5, Penerbangan 501

Salah satu malfungsi Therac-25 telah dikenal sebagai 'Malfunction54'. Seorang

Mesin Therac-25 dan perangkat lunaknya berevolusi dari model sebelumnya

1.4.3 Layanan Ambulans London

2. Cocokkan pemilih dengan entri dalam daftar.

3. Jika ditemukan kecocokan, periksa apakah dia belum memberikan

Tes pada langkah terakhir memiliki bentuk

1.5 Etika Rekayasa

Gambar 1.5 Kode etik rekayasa perangkat lunak

1.6 Ke mana engkau pergi?