Modul 2. Siklus Hidup Pengembangan Perangkat Lunak-OK

Analisis Perancangan Perangkat Lunak
MATERI 2
SIKLUS HIDUP
PENGEMBANGAN
PERANGKAT LUNAK
Direkonstruksi Oleh :
Muhammad Adri, S.Pd., M.T
Email : mhd.adri@unp.ac.id
Lisensi Dokumen:
Copyright © 2020 Universitas Negeri Padang
Seluruh dokumen di e-Learning Universitas Negeri Padang, hanya digunakan untuk kalangan
Internal Universitas, untuk kebutuhan Perkuliahan Online. Penggunaan dokumen ini di luar UNP tidak
diizinkan dan tidak diperbolehkan melakukan penulisan ulang, kecuali mendapatkan ijin terlebih dahulu
dari Penulis dan Universitas Negeri Padang.
Kami dapat mendefinisikan siklus sebagai 'suksesi peristiwa yang diulang secara
teratur dalam periode waktu tertentu' atau 'putaran tahun atau periode waktu berulang,
di mana peristiwa tertentu berulang sendiri'. 'Siklus hidup' adalah urutan peristiwa atau
pola yang mengungkapkan diri mereka sendiri di masa kehidupan suatu organisme.
Produk perangkat lunak terlihat menampilkan urutan pola seperti itu dalam masa
pakainya. Dalam bab ini, kita akan membahas pola umum yang umumnya diamati dalam
masa pakai produk perangkat lunak. Pengakuan siklus hidup pengembangan perangkat
lunak seperti itu memegang kunci keberhasilan pengembangan perangkat lunak.
A. PROSES PENGEMBANGAN PERANGKAT LUNAK
Proses pengembangan perangkat lunak telah mengambil rute yang berbeda pada
waktu yang berbeda di masa lalu. Seseorang dapat melihat model ideal dari proses
pengembangan perangkat lunak:
M O D U L 2 A P P L – 19 | T E K N I K I N F O R M A T I K A
Materi 2. Siklus Hodup Perangkat Lunak
1. Model Code-and-fix
2. Model Air Terjun (Waterfall)
3. Model Evolusi (Evolution)
4. Model Spiral
1. Model Code-and-Fix
Selama tahun-tahun awal pengembangan perangkat lunak (tahun lima

puluhan dan enam puluhan), pengembangan perangkat lunak adalah tugas satu
orang, ditandai dengan yang berikut: 1. Itu adalah aplikasi sains atau rekayasa. 2.
Pengembang juga adalah pengguna perangkat lunak. 3. Persyaratan sepenuhnya
diketahui. 4. Pengembangan produk perangkat lunak terutama melibatkan
pengkodean dan perbaikan bug, jika ada. Ghezzi et al. (1994) menyebut jenis
proses pengembangan ini model kode-dan-perbaiki.
Namun, seiring berlalunya waktu, model proses jenis ini ternyata sangat
tidak memadai karena banyak perubahan yang terjadi di lingkungan
pengembangan perangkat lunak. Perubahan yang memiliki pengaruh sangat
signifikan terhadap proses pengembangan adalah sebagai berikut:
a. Komputer mulai menjadi populer dan domain aplikasinya meluas, dari sains
dan teknik ke bisnis, industri, layanan, militer, dan pemerintah.
b. Pengembang menjadi berbeda dari pengguna. Sepotong perangkat lunak
dikembangkan baik sebagai tanggapan terhadap permintaan dari pelanggan
tertentu atau ditargetkan untuk kebutuhan umum kelas pengguna di pasar.
c. Pengembang menghabiskan banyak waktu dan upaya untuk memahami
kebutuhan pengguna. Pengembang mengubah kode mereka beberapa kali,
kadang-kadang bahkan setelah mereka pikir mereka telah menyelesaikan
pengembangan perangkat lunak, untuk memasukkan persyaratan pengguna.
b. Aplikasi sering menjadi sangat kompleks dan besar sehingga perangkat
lunak harus dikembangkan oleh sekelompok orang, daripada satu orang,
membutuhkan perencanaan yang cukup besar untuk pembagian pekerjaan,
koordinasi untuk kelancaran pelaksanaannya, dan kontrol sehingga
perangkat lunak dikembangkan dalam waktu yang ditentukan.
20 | A n a l i s i s P e r a n c a n g a n P e a n g k a t L u n a k
Materi 2. Siklus Hodup Perangkat Lunak|
c. Produk perangkat lunak besar dan pengembangannya oleh sekelompok

orang selalu menyebabkan seringnya produk perangkat lunak tidak
berfungsi selama pengujian (oleh pengembang) dan digunakan (di situs
pengguna). Mengidentifikasi cacat dan memperbaikinya menjadi semakin
sulit. Omset besar pengembang perangkat lunak menekankan masalah ini.
Penjaminan kualitas dan pemeliharaan, oleh karena itu, membutuhkan
desain dan pengkodean yang disiplin. Itu juga membutuhkan dokumentasi
yang cermat. Pengujian di berbagai tingkatan dianggap sangat penting.
Pemeliharaan perangkat lunak menjadi tambahan yang tak terhindarkan dari
proses pengembangan.
d. Persyaratan pelanggan yang berubah sering menyerukan modifikasi dan
peningkatan perangkat lunak yang ada. Ditambah dengan peluang yang
disediakan oleh perangkat keras dan perangkat lunak baru, modifikasi dan
peningkatan seperti itu kadang-kadang menyebabkan membuang perangkat
lunak lama dan membuka jalan bagi perangkat lunak baru.
Perubahan ini mengarah pada cara yang lebih sistematis untuk
mengembangkan produk perangkat lunak.
2. Model Air Terjun
Untuk waktu yang lama industri perangkat lunak berada dalam

kebingungan tentang pedoman apa yang harus diikuti selama proses
pengembangan perangkat lunak. Dipengaruhi oleh proses pengembangan yang
diikuti dalam proyek perangkat lunak pertahanan udara yang terkenal yang
disebut SAGE (Semi-Automated Ground Environment) dan oleh konsep yang
diteruskan oleh Bennington (1956) dan Rosove (1976), Royce (1970)
mengusulkan 'Model Air Terjun' yang terkenal dari proses pengembangan
perangkat lunak (Gbr. 2.1). Model ini menjadi populer dan memberikan pedoman
praktis yang sangat dibutuhkan untuk mengembangkan perangkat lunak. Boehm
telah menjadi pendukung kuat model air terjun. Dia memberikan alasan ekonomi
di balik model ini (Boehm 1976) dan mengusulkan berbagai penyempurnaan di
dalamnya (Boehm 1981).
A n a l i s i s P e r a n c a n a n P e r a n g k a t L u n a k | 21
Terkait erat dengan model air terjun adalah konsep 'siklus hidup
pengembangan perangkat lunak'. Perangkat lunak dipahami sebagai makhluk
hidup dengan urutan fase pengembangan yang jelas, mulai dari konseptualisasi
masalah (kelahiran ide — fase pertama) hingga membuang perangkat lunak
(kematian perangkat lunak — fase terakhir) .
Model air terjun mendapatkan namanya dari kesamaan struktural

(geometris) dari proses pengembangan perangkat lunak dengan air terjun. Model
ini membuat asumsi utama berikut:
a. Proses pengembangan perangkat lunak terdiri dari sejumlah fase secara

berurutan, sehingga hanya setelah fase selesai, pekerjaan pada fase
berikutnya dapat dimulai. Dengan demikian, mengandaikan aliran kontrol
searah di antara fase.
b. Dari fase pertama (konseptualisasi masalah) ke fase terakhir (pensiun),
terdapat arus informasi primer dan upaya pengembangan yang menurun
(Sage 1995).
c. Pekerjaan dapat dibagi, menurut fase, di antara berbagai kelas spesialis.
Analisis dan
Spesifikasi
Kebutuhan
Analisis dan
Spesifikasi
Kebutuhan
Pengkodean
dan Pengujian
Unit
Integrasi dan
Pengujian
Sistem
Pengiriman
dan
Pemeliharaan
Gambar 2.1. Model air terjun Royce (1970)

d. Dimungkinkan untuk mengaitkan tujuan untuk setiap fase dan karenanya
merencanakan hasil kerja (kondisi keluar atau output) dari setiap fase.
e. Output dari satu fase menjadi input (mis., Titik awal) ke fase berikutnya.
f. Sebelum output dari satu fase digunakan sebagai input ke fase berikutnya,
itu dikenakan berbagai jenis ulasan dan verifikasi dan pengujian validasi.
Hasil pengujian memberikan informasi umpan balik ke atas yang digunakan
untuk pengerjaan ulang dan memberikan output yang benar. Dengan
demikian, meskipun keseluruhan strategi pembangunan mendukung aliran
searah (atau berurutan), itu juga memungkinkan aliran iteratif terbatas dari
fase yang segera berhasil.
g. Biasanya, output dibekukan, dan dokumen output ditandatangani oleh staf

dari fase produksi, dan ini menjadi dokumen penting dengan bantuan yang
bekerja di fase penerima dimulai. Output semacam itu membentuk garis
dasar, produk 'beku' dari fase siklus hidup, yang menyediakan titik
pemeriksaan atau titik referensi yang stabil dan tidak berubah tanpa
persetujuan semua pihak yang berkepentingan. Versi definitif dari output ini
biasanya tersedia untuk pengontrol proses manajemen konfigurasi
(Pustakawan Proyek).
h. Dimungkinkan untuk mengembangkan alat pengembangan yang berbeda

sesuai dengan persyaratan setiap fase.
i. Fase memberikan dasar untuk manajemen dan kontrol karena mereka

menentukan segmen dari alur kerja, yang dapat diidentifikasi untuk tujuan
manajerial, dan menentukan dokumen atau hasil lainnya yang akan
dihasilkan dalam setiap fase.
Dengan demikian, model ini menyediakan pendekatan praktis dan disiplin

dalam pengembangan perangkat lunak.
Penulis yang berbeda menggambarkan fase untuk siklus hidup

pengembangan sistem secara berbeda. Perbedaannya terutama karena jumlah
detail dan cara kategorisasi. Kategorisasi yang kurang rinci dan luas adalah
bahwa siklus hidup pengembangan dibagi menjadi tiga tahap (Davis dan Olson
1985, Sage 1995) : a) Definisi, b) Pengembangan, dan c) Penempatan (instalasi
dan operasi).
Tahap definisi berkaitan dengan perumusan masalah aplikasi, analisis

kebutuhan pengguna, analisis kelayakan, dan analisis persyaratan perangkat
lunak pendahuluan. Tahap pengembangan berkaitan dengan spesifikasi
perangkat lunak, desain produk (mis., Desain arsitektur perangkat keras, desain
struktur kontrol dan struktur data untuk produk), desain terperinci, pengkodean,
serta pengintegrasian dan pengujian. Tahap terakhir Penempatan berkaitan
dengan implementasi, operasi dan pemeliharaan, dan evolusi sistem (pasca
audit).
Yang lain tidak membagi siklus hidup menjadi beberapa tahap, tetapi
memandang siklus sebagai terdiri dari berbagai fase. Jumlah fase bervariasi dari
lima hingga empat belas. Tabel 2.1 memberikan tiga urutan fase yang dirinci oleh
berbagai pekerja di lapangan. Pembagian siklus hidup yang jauh lebih terperinci
ke dalam fase dan sub-fase diberikan oleh Jones (1986, hal. 118) dan diberikan
dalam Tabel 2.2.
Menurut Kamus Webster Baru, satu tahapan adalah ‘satu langkah atau
tingkatan dalam proses; periode tertentu dalam perjalanan kemajuan, tindakan
atau pengembangan; level dalam serangkaian level ’. Fase, di sisi lain, adalah
‘salah satu dari penampilan atau aspek di mana sesuatu dari berbagai model atau
kondisi memanifestasikan dirinya ke mata atau pikiran; tahap perubahan atau
pengembangan '. Kami mengambil tahap yang terdiri dari sejumlah fase.
Gambar 2.2. Model Air Terjun Boehm (1981)
Gambar 2.1 dan 2.2 menunjukkan, masing-masing, model air terjun oleh
Royce dan model air terjun yang dimodifikasi oleh Boehm. Perhatikan bahwa
model asli oleh Royce adalah model umpan maju tanpa umpan balik, sedangkan
model Boehm memberikan umpan balik ke fase sebelumnya. Selanjutnya, model
Boehm membutuhkan verifikasi dan validasi sebelum output fase dibekukan.
Tabel 2.1: Fase Siklus Hidup oleh Berbagai Penulis
Thibodeau dan Boehm (1981) Sage (1995)

Dodson (1985)
Analisis Kelayakan system Perencanaan proyek
Rancangan Paket dan persyaratan Membangun lingkungan
perangkat lunak pengembangan
perangkat lunak
Coding Desain yang rinci Analisis persyaratan
system
Tes dan Integrasi Kode Desain system
Operasi dan Integrasi Analisis persyaratan
Pemeliharaan Penerapan perangkat lunak
Operasi dan Desain arsitektur
Pemeliharaan perangkat lunak
Perancangan perangkat
lunak yang terperinci
Pengkodean dan
pengujian unit Integrasi
dan pengujian unit Item
Konfigurasi Perangkat
Lunak Komputer (CSCI)
pengujian Integrasi dan
pengujian CSCI Persiapan
untuk penggunaan dan
dukungan perangkat
lunak Persiapan untuk
pengiriman perangkat
lunak
Model air terjun itu praktis tetapi memiliki masalah berikut (Royce, 2000):
a. Integrasi Berkepanjangan dan Kerusakan Desain Akhir. Penekanan berat

pada analisis dan desain yang sempurna sering mengakibatkan terlalu
banyak pertemuan dan terlalu banyak dokumentasi dan secara substansial
menunda proses integrasi dan pengujian, dengan perbaikan yang tidak
optimal, waktu yang sangat sedikit untuk mendesain ulang, dan dengan
keterlambatan pengiriman produk yang tidak dapat dipelihara.
b. Resolusi Risiko Terlambat. Selama fase elisitasi persyaratan, risiko
(probabilitas kehilangan biaya, jadwal, fitur, atau sasaran mutu) sangat
tinggi dan tidak dapat diprediksi. Melalui berbagai fase, risiko menjadi stabil
(fase desain dan pengkodean), diselesaikan (fase integrasi) dan dikendalikan
(fase pengujian). Resolusi risiko yang terlambat menghasilkan perubahan

desain yang terlambat dan, akibatnya, dalam kode dengan rawatan yang
rendah.
c. Dekomposisi Fungsional Berbasis Kebutuhan. Model air terjun membutuhkan
persyaratan yang ditentukan secara lengkap dan jelas. Tetapi juga
mengasumsikan bahwa semua persyaratan sama pentingnya, dan mereka
tidak berubah selama fase pengembangan. Asumsi pertama bertanggung
jawab untuk membuang banyak orang-hari upaya sedangkan asumsi kedua
dapat membuat rekayasa perangkat lunak tidak berguna bagi pengguna
akhir. Dalam kebanyakan pengembangan berbasis model air terjun,
persyaratan diuraikan dan dialokasikan untuk fungsi-fungsi program.
Dekomposisi dan alokasi seperti itu tidak dimungkinkan dalam
pengembangan berorientasi objek yang merupakan urutan hari itu.
b. Hubungan Stakeholder Adversarial. Seperti yang sudah dibahas, setiap
dokumen ditandatangani oleh dua pihak pada akhir fase dan sebelum
dimulainya fase selanjutnya. Dengan demikian, dokumen semacam itu
menyediakan hubungan kontraktual untuk kedua belah pihak. Hubungan
semacam itu dapat berubah menjadi ketidakpercayaan, khususnya antara
pelanggan dan kontraktor.
Tabel 2.2: Fase dan Sub-Fase Siklus Hidup Perangkat Lunak
Fase I Definisi masalah Analisis masalah Pilihan teknologi

Inventarisasi keterampilan
Fase 2 Persyaratan Requirements exploration
Requirements documentation
Requirements analysis
Fase 3 Perencanaan Keputusan buat-atau-beli Pemilihan
implementasi alat Perencanaan proyek
Fase 4 Desain tingkat tinggi Analisis data dasar Analisis fungsi
dasar Analisis struktur dasar
Inspeksi, perbaikan dan pengerjaan
ulang
Fase 5 Desain yang rinci Spesifikasi fungsional Spesifikasi
logika Prototipe system
Fase 6 Penerapan Pengambilan kembali kode yang
dapat digunakan kembali
Kustomisasi pengembangan kode
baru
Fase 7 Integrasi dan Inspeksi, perbaikan dan pengerjaan

pengujian ulang. Integrasi lokal dan
komponen Lingkungan uji
konstruksi Integrasi penuh dan
perbaikan, pengerjaan ulang
Fase 8 Penerimaan Efisiensi penghapusan cacat
pelanggan Kalibrasi penghapusan cacat
Pengemasan dan pengiriman
Bantuan di tempat
Fase 9 Maintenance Pelaporan cacat
(perbaikan) Analisis cacat
Perbaikan cacat
Fase 10 Perangkat tambahan Perangkat tambahan yang berasal
fungsional dari pelanggan Perangkat
tambahan yang berasal secara
teknis
Kinerja Proses Perangkat Lunak Konvensional dalam Praktek
Boehm (1987) menyajikan daftar sepuluh aturan praktis yang menjadi ciri
proses perangkat lunak konvensional seperti yang dipraktikkan selama tiga
dekade terakhir.
a. Menemukan dan memperbaiki masalah perangkat lunak setelah pengiriman

membutuhkan biaya 100 kali lebih banyak daripada menemukan dan
memperbaiki masalah pada fase desain awal.
b. Satu dapat kompres jadwal pengembangan perangkat lunak 25% dari
nominal, tetapi tidak lebih.
c. Untuk setiap US $ 1 yang dihabiskan untuk pengembangan, ia akan
menghabiskan $ 2 untuk pemeliharaan.
d. Biaya pengembangan dan pemeliharaan perangkat lunak terutama
merupakan fungsi dari jumlah baris sumber kode.
e. Variasi di antara orang-orang bertanggung jawab atas perbedaan terbesar
dalam produktivitas perangkat lunak.
f. Rasio keseluruhan biaya perangkat lunak dan perangkat keras masih terus
meningkat. Pada tahun 1955 adalah 15:85; pada tahun 1985 adalah 85:15.
g. Hanya sekitar 15% dari upaya pengembangan perangkat lunak dikhususkan
untuk pemrograman.
h. Sistem perangkat lunak dan produk biasanya berharga 3 kali lebih banyak
per SLOC (Source Lines of Code) dibandingkan dengan program perangkat
lunak individual. Produk sistem perangkat lunak harganya 3 kali lipat.
i. Walk-throughs menangkap 60% kesalahan.
j. 80% dari kontribusi berasal dari 20% dari kontribusi.
Boehm (1976, 1981) memberikan alasan ekonomi berikut di balik fase dan
urutan berurutan mereka:
1. Semua fase dan tujuan terkait mereka diperlukan. Dimungkinkan, seperti

pada model code dan fix, untuk aplikasi yang sangat sederhana,
terstruktur, dan akrab untuk langsung menulis kode tanpa melalui fase
sebelumnya. Tetapi praktik informal ini hampir selalu menyebabkan
kekurangan serius, terutama dalam masalah besar dan kompleks.
2. Pemesanan fase yang berbeda akan menghasilkan produk perangkat
lunak yang kurang berhasil. Banyak penelitian (misalnya, Boehm 1973,
1976, 1981; Myers 1976 dan Fagan 1976) telah menunjukkan bahwa
biaya yang dikeluarkan untuk memperbaiki kesalahan meningkat secara
geometris jika terdeteksi terlambat. Sebagai contoh, memperbaiki
kesalahan bisa 100 kali lebih mahal pada fase pemeliharaan daripada
pada fase persyaratan (Boehm 1981). Dengan demikian, ada premi yang
sangat tinggi pada nilai analisis dan fase desain sebelum fase
pengkodean.
Davis et al. (1988) mengutip penggunaan model air terjun berikut:
1. Model ini mendorong seseorang untuk menentukan apa yang seharusnya

dilakukan sistem (mis., Mendefinisikan persyaratan) sebelum membangun
sistem (mis., Merancang).
2. Ini mendorong seseorang untuk merencanakan bagaimana komponen
akan berinteraksi (mis., Merancang sebelum pengkodean).
3. Ini memungkinkan manajer proyek untuk melacak kemajuan secara

lebih akurat dan untuk menemukan kemungkinan selip dini.
4. Menuntut agar proses pengembangan menghasilkan serangkaian

dokumen yang dapat digunakan nanti untuk menguji dan
memelihara sistem.
5. Ini mengurangi biaya pengembangan dan pemeliharaan karena

semua alasan yang disebutkan di atas.
6. Ini memungkinkan organisasi yang akan mengembangkan sistem

menjadi lebih terstruktur dan dapat dikelola.
Kritik Model Air Terjun
Model air terjun telah memberikan pedoman yang sangat dibutuhkan

untuk pendekatan disiplin dalam pengembangan perangkat lunak. Tetapi ini
bukan tanpa masalah.
1. Model air terjunnya kaku. Kekakuan fase, bahwa hasil dari setiap fase harus
dibekukan sebelum fase berikutnya dapat dimulai, sangat kuat.
2. Itu monolitik. Perencanaan berorientasi pada tanggal pengiriman tunggal.
Jika ada kesalahan yang terjadi pada tahap analisis, maka itu akan diketahui
hanya ketika perangkat lunak dikirimkan kepada pengguna. Jika persyaratan
pengguna tidak diperoleh dengan benar atau jika persyaratan pengguna
berubah selama fase desain, pengkodean, dan pengujian, maka model air
terjun menghasilkan produk perangkat lunak yang tidak memadai.
3. Model ini sangat didorong oleh dokumen hingga menjadi birokratis.
Untuk mengatasi kesulitan-kesulitan ini, dua pendekatan luas telah

dikembangkan dalam bentuk penyempurnaan model air terjun: 1). Model evolusi
dan 2) Model spiral.
3. Model Evolusioner
Model air terjun adalah pendekatan level-by-level murni, dari atas ke

bawah. Oleh karena itu, pelanggan tidak mengetahui apa-apa tentang perangkat
lunak sampai akhir siklus hidup pengembangan. Dalam suatu pendekatan
evolusioner, oleh konstrast, model kerja perangkat lunak dikembangkan dan

disajikan kepada pelanggan untuk umpan baliknya, untuk penggabungan dan
pengiriman perangkat lunak akhir.
Pendekatan evolusi dapat diimplementasikan dalam dua bentuk :
1. Implementasi Incremental.
2. Prototyping.
Implementasi Incrimental (Boehm 1981, Gilb 1988)
Di sini perangkat lunak dikembangkan dalam peningkatan (incremental)

kemampuan fungsional; yaitu, pengembangan ini dalam langkah-langkah,
dengan bagian-bagian dari beberapa tahap ditunda untuk menghasilkan fungsi
kerja yang berguna sebelumnya dalam pengembangan proyek. Fungsi-fungsi lain
secara perlahan ditambahkan kemudian sebagai peningkatan. Jadi, sementara
analisis dan desain dilakukan mengikuti model proses air terjun, pengkodean,
integrasi dan pengujian dilakukan secara bertahap.
Sebagai contoh, IGRASP, Paket Simulasi Grafis Interaktif, dikembangkan

dalam tiga langkah, satu kernel dan dua peningkatan (Gbr. 2.3). Awalnya, kernel
menyertakan rutinitas yang ditulis ke :
1. Periksa kesalahan dan urutkan secara manual pernyataan program

yang dimasukkan,
2. Sertakan fungsi dan subrutin, dan
3. Buat perhitungan dan berikan output tabular.
Peningkatan 1 menambahkan fitur :

a. Input diagrammatic berbasis ikon,
b. Pembuatan kode otomatis, dan
c. Output grafis.
Selisih 2 menyediakan fasilitas :
a. Animasi output dan
c. Gaming.
Gambar 2.3. Pengembangan IGRASP secara bertahap
Pendekatan tambahan telah mendapat banyak keuntungan:

1. Pengguna dapat memberikan saran pada bagian-bagian yang akan
disampaikan pada titik waktu kemudian.
2. Para pengembang terlibat dalam pengembangan fitur fungsional paling
mendasar dari perangkat lunak ini dalam peningkatan pertamanya.
Dengan demikian, fitur-fitur ini mendapatkan perhatian maksimal, dan
paling terkonsentrasi, dari para pengembang. Oleh karena itu, ada
kemungkinan besar bahwa program tersebut bebas dari kesalahan.
3. Waktu untuk menunjukkan beberapa hasil kepada pengguna sangat

berkurang. Reaksi pengguna, jika ada, dapat dimasukkan ke dalam
perangkat lunak dengan sangat mudah.
4. Pengujian, deteksi kesalahan, dan koreksi kesalahan menjadi tugas
yang relatif mudah.
Masalah-masalah tertentu, umumnya terkait dengan pengembangan

perangkat lunak secara bertahap, adalah sebagai berikut:
1. Kerangka arsitektural keseluruhan produk harus ditetapkan di awal
dan semua penambahan harus sesuai dengan kerangka ini.
2. Kontrak pelanggan-pengembang yang berorientasi pada
pengembangan inkremental tidak biasa.
Prototyping
Metode ini didasarkan pada prosedur eksperimental di mana prototipe

kerja perangkat lunak diberikan kepada pengguna untuk komentar dan umpan
balik. Ini membantu pengguna untuk mengekspresikan persyaratannya dalam
istilah yang lebih definitif dan konkret. Prototipe dapat terdiri dari dua jenis:
1. Prototyping throwaway cepat (perancah) (Gbr. 2.4) dan

2. Prototipe evolusioner (Gbr. 2.5)
Gambar 2.4. Model pengembangan prototipe sistem aplikasi

(Diadaptasi dari Davis dan Olson, 1985)
Prototipe lempar mengikuti prinsip 'lakukan dua kali' yang dianjurkan

oleh Brooks (1975). Di sini, versi awal perangkat lunak dikembangkan hanya
sementara untuk memperoleh persyaratan informasi dari pengguna. Ini
kemudian dibuang, dan versi kedua dikembangkan mengikuti model air terjun,
yang berpuncak pada pengembangan skala penuh.
Dalam hal prototipe evolusi, prototipe awal tidak dibuang. Alih-alih,

secara progresif diubah menjadi aplikasi akhir.
a. Prototyping Evolutionary vs Throwaway
Karakteristik dari kedua metode prototyping diberikan di bawah ini:
1) Kedua jenis prototipe mengasumsikan bahwa pada awalnya beberapa

set abstrak, persyaratan tidak lengkap telah diidentifikasi.
2) Keduanya memungkinkan umpan balik pengguna.
3) Sebuah prototipe evolusi terus dimodifikasi dan disempurnakan dalam
terang aliran pengguna beedback sampai pengguna puas. Pada tahap
itu, produk perangkat lunak dikirim ke pelanggan.
4) Di sisi lain, prototipe sekali pakai memungkinkan pengguna untuk
memberikan umpan balik, dan karenanya memberikan dasar untuk
secara jelas menetapkan serangkaian spesifikasi persyaratan yang
lengkap. Spesifikasi ini digunakan untuk memulai de novo
mengembangkan perangkat lunak lain mengikuti tahapan biasa siklus
hidup pengembangan perangkat lunak.
5) Berbagai revisi yang dilakukan prototipe evolusi biasanya menghasilkan
struktur program yang buruk dan membuatnya sangat buruk dari sudut
pandang rawatan.
6) Prototipe sekali pakai biasanya tidak cocok untuk menguji persyaratan
non-fungsional dan mode penggunaan prototipe ini mungkin tidak
sesuai dengan lingkungan implementasi aktual dari produk perangkat
lunak akhir.
b. Manfaat Prototyping
Sommerville (1999) menyatakan manfaat prototyping berikut:
1) Kesalahpahaman antara pengembang perangkat lunak dan pengguna
dapat diidentifikasi.
2) Layanan pengguna yang hilang dapat dideteksi.
3) Layanan pengguna yang sulit digunakan atau membingungkan dapat
diidentifikasi dan disempurnakan.
4) Pengembang mungkin menemukan persyaratan yang tidak lengkap dan
/ atau tidak konsisten.
5) Ini membantu dalam mendapatkan kepercayaan pengguna.
6) Ini membantu dalam menulis spesifikasi.
7) Spesifikasi persyaratan yang benar mengurangi kesalahan terkait
persyaratan dan karenanya biaya pengembangan keseluruhan.
8) Dapat digunakan untuk melatih pengguna sebelum sistem final

disampaikan.
9) Test case untuk prototipe dapat digunakan untuk produk perangkat
lunak akhir (back-to-back testing). jika hasilnya sama, tidak perlu untuk
memeriksa manual yang membosankan.
10) Dua manfaat terakhir yang disebutkan adalah karena Ince dan
Hekmatpour (1987)
c. Pedoman untuk Mengembangkan Prototipe
Pedoman berikut tersedia untuk mengembangkan prototipe:
1) Tujuan dari prototipe harus eksplisit sehingga pengguna jelas
menyadarinya. Mereka mungkin mengembangkan antarmuka pengguna,
memvalidasi persyaratan fungsional, atau mencapai sejenis tujuan
spesifik.
2) Prototyping membutuhkan biaya tambahan. Jadi prototipe harus
dikembangkan untuk subset dari fungsi-fungsi yang seharusnya dimiliki
produk perangkat lunak akhir. Karena itu harus diabaikan persyaratan
non-fungsional, dan tidak perlu mempertahankan penanganan
kesalahan, kualitas dan standar keandalan sebagaimana yang
diperlukan untuk produk perangkat lunak akhir.
3) Pengembang harus menggunakan bahasa dan alat yang memungkinkan
untuk mengembangkan prototipe cepat dan dengan biaya rendah.
Bahasa dan alat ini dapat berupa satu atau kombinasi dari yang berikut:
a) Bahasa tingkat sangat tinggi, seperti Smalltalk (berbasis objek),
Prolog (berbasis logika), APL (berbasis vektor), dan Lisp (berbasis
struktur daftar), memiliki fasilitas manajemen data yang kuat.
Sementara masing-masing bahasa ini didasarkan pada paradigma
tunggal, Loops adalah spektrum yang luas bahasa yang mencakup
banyak paradigma seperti objek, pemrograman logika, dan
konstruksi imperatif, dll. Dengan tidak adanya Loops, seseorang
dapat menggunakan bahasa campuran pendekatan, dengan
berbagai bagian prototipe menggunakan bahasa yang berbeda.
b) Bahasa generasi keempat, seperti SQL, Report generator,
spreadsheet, dan layar generator, adalah alat yang sangat baik
untuk aplikasi pemrosesan data bisnis. Mereka sering digunakan

bersama dengan alat CASE dan berpusat di sekitar aplikasi basis
data.
c) Komponen yang dapat digunakan kembali dari perpustakaan dapat
dirakit untuk mengembangkan prototipe dengan cepat. Namun,
karena spesifikasi komponen dan persyaratan mungkin tidak cocok,
komponen-komponen ini mungkin berguna untuk prototyping sekali
pakai.
d) Bahasa spesifikasi yang dapat dieksekusi, seperti Z, dapat
digunakan untuk mengembangkan prototipe jika persyaratannya
ditentukan dalam bahasa matematika formal. Bahasa fungsional,
seperti Miranda dan ML, dapat digunakan sebagai gantinya, bersama
dengan perpustakaan antarmuka pengguna grafis untuk
memungkinkan pengembangan prototipe cepat.
Summerville (1999) merangkum bahasa, tipe mereka, dan domain aplikasi

mereka (Tabel 2.3).
Tabel 2.3: Bahasa untuk prototyping cepat
Bahasa Tipe Domain Aplikasi

Smalltalk Object-oriented Interactive Systems
Loops Wide-spectrum Interactive Systems
Prolog Logic Symbolic Processing
Lisp List-base Symbolic Processing
Miranda Functional Symbolic Processing
SETL Set-based Symbolic Processing
APL Mathematical Scientific Systems
4GLs Database Business Data Processing
CASE tools Graphical Business Data Processing
4. Model Spiral
Boehm (1988) telah mengembangkan model spiral pengembangan

perangkat lunak. Model mengintegrasikan karakteristik model air terjun,
implementasi inkremental, dan prototipe evolusi pendekatan. Dalam pengertian
ini, ini adalah metamodel (Ghezzi et al. 1994). Model ini memiliki fitur-fitur
berikut:
a. Proses pengembangan perangkat lunak dapat digambarkan dalam bentuk

spiral yang bergerakdengan cara searah jarum jam (Gbr. 2.6).
b. Setiap siklus spiral menggambarkan fase tertentu dari siklus hidup
pengembangan perangkat lunak. Jadi siklus terdalam mungkin berurusan
dengan analisis kebutuhan, siklus berikutnya dengan desain, dan
sebagainya. Model tidak mengasumsikan fase tetap apa pun. Manajemen
memutuskan fase-fase; dengan demikian jumlah siklus dalam model spiral
dapat bervariasi dari satu organisasi ke yang lain, dari satu proyek ke proyek
lain, atau bahkan dari satu proyek ke proyek lain dalam organisasi yang
sama.
Gambar 2.6. Model Spiral oleh Boehm

c. Setiap kuadran spiral berhubungan dengan serangkaian aktivitas tertentu
untuk semua fase. Itu empat rangkaian kegiatan adalah sebagai berikut:
1) Tentukan tujuan, alternatif, dan kendala. Untuk setiap fase perangkat
lunak pengembangan, tujuan ditetapkan, kendala pada proses dan
produk ditentukan, dan strategi alternatif direncanakan untuk
memenuhi tujuan dalam menghadapi kendala.
2) Mengevaluasi alternatif dan mengidentifikasi dan menyelesaikan risiko

dengan bantuan prototipe. Sebuah analisis dilakukan untuk
mengidentifikasi risiko yang terkait dengan setiap alternatif. Prototyping
adalah diadopsi untuk menyelesaikannya.
3) Kembangkan dan verifikasi produk tingkat selanjutnya, dan evaluasi. Di
sini perkembangan dominan model dipilih. Ini bisa berupa prototipe
evolusi, tambahan, atau air terjun. Hasil kemudian dikenakan uji
verifikasi dan validasi.
4) Rencanakan fase selanjutnya. Kemajuan ditinjau dan keputusan diambil
apakah akan lanjutkan atau tidak. Jika keputusan mendukung
kelanjutan, maka rencana disusun untuk fase selanjutnya dari produk.
d. Jari-jari spiral (Gbr. 2.6) menunjukkan biaya pengembangan kumulatif; sudut
Dimensi mewakili kemajuan; jumlah siklus mewakili fase perangkat lunak
pengembangan; dan kuadran mewakili set kegiatan yang dilakukan pada
perangkat lunak pengembangan pada titik waktu tertentu.
e. Fitur penting dari model spiral adalah pertimbangan eksplisit (identifikasi
dan penghapusan) risiko. Risiko adalah keadaan yang berpotensi merugikan
yang dapat mengganggu proses pengembangan dan kualitas produk
perangkat lunak. Penilaian risiko mungkin diperlukan berbagai jenis kegiatan
yang akan direncanakan, seperti prototyping atau simulasi, wawancara
pengguna, benchamarking, pemodelan analitik, atau kombinasi dari
semuanya.
f. Jumlah siklus yang diperlukan untuk mengembangkan perangkat lunak tentu
saja tergantung atas risiko yang terlibat. Jadi, dalam hal sistem yang
dipahami dengan baik dengan pengguna yang stabil persyaratan di mana
risiko sangat kecil, prototipe pertama dapat diterima sebagai produk akhir;
oleh karena itu, dalam hal ini, hanya satu siklus spiral yang cukup.
Pada Gambar 2.6, kami mengasumsikan bahwa empat prototipe

diperlukan sebelum kesepakatan tercapai untuk spesifikasi persyaratan sistem.
Setelah kesepakatan akhir, model desain air terjun standar adalah diikuti untuk
fase siklus hidup pengembangan perangkat lunak yang tersisa.
Namun, model spiral mewakili beberapa iteraksi dari model air terjun. Di
setiap iteraction, pendekatan alternatif untuk pengembangan perangkat lunak
dapat diikuti, fungsionalitas baru dapat ditambahkan (implementasi tambahan),
atau bangunan baru dapat dibuat (pembuatan prototipe). Model spiral, oleh
karena itu, adalah generalisasi dari model siklus hidup lainnya.
Davis et al. (1988) mempertimbangkan dua alternatif model perangkat

lunak berikut pengembangan:
a. Perangkat lunak yang dapat digunakan kembali, di mana desain dan kode
yang sebelumnya terbukti digunakan kembali dalam perangkat lunak baru
produk,
b. Sintesis perangkat lunak otomatis, di mana kebutuhan pengguna atau
spesifikasi desain tingkat tinggi secara otomatis diubah menjadi kode
operasional baik dengan teknik algoritmik atau berbasis pengetahuan
menggunakan bahasa tingkat tinggi (VHLL).
Reusability membantu mempersingkat waktu pengembangan dan

mencapai keandalan yang tinggi. Namun, institusional upaya sering kurang di
perusahaan perangkat lunak untuk menyimpan, katalog, mencari, dan
mengambil komponen yang dapat digunakan kembali. Sintesis perangkat lunak
otomatis melibatkan pemrograman otomatis dan merupakan disiplin ilmu yang
sangat teknis di dalamnya hak pribadi.
B. PENGGUNAAN KEMBALI PERANGKAT LUNAK
Dengan pemrograman berorientasi objek menjadi populer, konsep reusability

telah diperoleh momentum. Objek merangkum data dan fungsi, membuatnya mandiri.
Fasilitas warisan tersedia dalam pemrograman berorientasi objek memfasilitasi
memanggil objek-objek ini untuk dapat digunakan kembali. Tapi ekstra upaya diperlukan
untuk menyamaratakan bahkan objek / kelas objek ini. Organisasi harus siap memenuhi
biaya jangka pendek ini untuk potensi keuntungan jangka panjang.
Bentuk penggunaan ulang yang paling umum adalah pada tingkat keseluruhan
sistem aplikasi. Dua jenis kesulitan yang dihadapi selama penggunaan ulang ini : 1)
Portabilitas dan 2) Kustomisasi
1. Portabilitas
Setiap kali perangkat lunak dikembangkan di satu lingkungan komputer

tetapi digunakan di yang lain lingkungan, masalah portabilitas dapat ditemui.
Masalahnya mungkin salah satu dari (1) transportasi atau (2) adaptasi.
Transportasi melibatkan transfer fisik perangkat lunak dan data terkait.

Masalah terkait transportasi hampir menghilang sekarang-sehari dengan
produsen komputer dipaksa, di bawah tekanan komersial, untuk
mengembangkan sistem yang dapat membaca kaset dan disk yang ditulis oleh
jenis mesin lain dan dengan standardisasi internasional dan meluasnya
penggunaan jaringan komputer.
Namun, adaptasi ke lingkungan lain merupakan masalah yang lebih halus.

Ini melibatkan komunikasi dengan perangkat keras (memori dan CPU) dan
dengan perangkat lunak (sistem operasi, perpustakaan, dan sistem pendukung
run-time bahasa). Perangkat keras komputer host mungkin memiliki representasi
data skema (misalnya, panjang kata 16-bit) yang berbeda dari panjang kata
mesin di mana perangkat lunak dikembangkan (misalnya, panjang kata 32-bit).
Panggilan sistem operasi yang digunakan oleh perangkat lunak untuk fasilitas
tertentu mungkin tidak tersedia dengan sistem operasi komputer host. Demikian
pula, fitur run-time dan library yang diperlukan oleh perangkat lunak mungkin
tidak tersedia di komputer host.
Sedangkan masalah run-time dan perpustakaan sulit untuk dipecahkan,

perangkat keras dan operasinya masalah terkait sistem dapat diatasi dengan
meminta bantuan untuk menciptakan antarmuka portabilitas menengah.
Perangkat lunak aplikasi memanggil tipe data abstrak daripada sistem operasi
dan prosedur input-output langsung. Antarmuka portabilitas kemudian
menghasilkan panggilan yang kompatibel dengan yang ada di komputer host.
Tentu saja, antarmuka ini harus diimplementasikan kembali ketika perangkat
lunak harus berjalan dalam arsitektur yang berbeda.
Dengan munculnya standar yang terkait dengan (1) bahasa pemrograman

(seperti Pascal, COBOL, C, C ++, dan Ada), (2) sistem operasi (seperti MacOS untuk
PC, Unix untuk workstation), (3) jaringan (seperti protokol TCP / IP), dan (4)
sistem windows (seperti Microsoft Windows untuk PC dan Windows 7) Sistem X-

window untuk antarmuka pengguna grafis untuk workstation), masalah
portabilitas telah berkurang secara signifikan dalam beberapa hari terakhir.
2. Kustomisasi.
Sekarang menjadi kebiasaan untuk mengembangkan paket perangkat

lunak umum dan kemudian menyesuaikan paket semacam itu untuk memenuhi
kebutuhan pengguna tertentu.
C. SINTESIS PERANGKAT LUNAK OTOMATIS
Generator program untuk fungsi stereotip dan generator kode dalam alat CASE
adalah contohnya sintesis perangkat lunak otomatis. Mereka sangat berguna dalam
menghasilkan kode untuk fungsi seperti:
1. Membuat layar,
2. Mengedit data input,
3. Mempersiapkan laporan,
4. Memproses transaksi, dan
5. Memperbarui basis data.
Jelas, generator ini tidak terlalu digeneralisasi dan perlu pemahaman mendalam
tentang fitur-fiturnya domain aplikasi.
D. PERBANDINGAN MODEL ALTERNATIF SIKLUS HIDUP PERANGKAT LUNAK
Dari uarian materi di atas, dicatat fitur khusus dari model siklus hidup perangkat
lunak :
1. Model air terjun memandang siklus hidup pengembangan perangkat lunak sebagai
terdiri dari urutan fase, dengan umpan balik terbatas dan interaksi antara fase.
Prototipe model memungkinkan sejumlah iterasi antara pengembang dan pengguna
dengan maksud untuk menerima umpan balik tentang sistem perangkat lunak
sebagian yang dibangun dan tidak lengkap yang dapat ditingkatkan dan dibangun
kembali. Pengembangan tambahan memungkinkan penambahan fungsionalitas

pada awalnya dibangun kernel untuk membangun sistem final. Model spiral
mencerminkan pendekatan umum untuk perangkat lunak pengembangan di mana
strategi inkremental atau strategi prototyping diikuti mengidentifikasi dan
menghilangkan risiko dan untuk menetapkan persyaratan pengguna dan desain
perangkat lunak terperinci, sebelum melakukan pengkodean, pengujian, dan
implementasi akhir dalam garis model air terjun.
2. Model air terjun berbasis dokumen, pendekatan evolusioner berbasis pengguna, dan
spiral Model berbasis risiko.
Ould (1990) membandingkan karakteristik model siklus hidup yang berbeda

dengan bantuan tampilan proses berikut:
a. Tampilan proses V (Gbr. 2.8) dari model air terjun,
Gambar 2.8. Tampilan proses-V dari model air terjun
b. Tampilan proses VP (Gbr. 2.9) dari model siklus kehidupan spiral awal,
c. Pandangan proses evolusi (bangunan berurutan) (Gbr. 2.10, yang merupakan

pengulangan dari Gambar 2.5) dari model prototyping, dan
d. Pandangan proses berulang (Gbr. 2.11) dari pendekatan pengembangan
tambahan.
Davis et al. (1988) menyarankan strategi untuk membandingkan model siklus

hidup pengembangan perangkat lunak alternatif. Mereka menentukan lima metrik
pengembangan perangkat lunak berikut untuk tujuan ini :
1. Kekurangan. Ukuran seberapa jauh perangkat lunak, kapan saja, dari

memenuhi pengguna yang sebenarnya persyaratan pada saat itu.
2. Keterlambatan. Ukuran waktu tunda antara kemunculan persyaratan baru
dan persyaratannya kepuasan.
3. Kemampuan beradaptasi. Tingkat di mana solusi perangkat lunak dapat
beradaptasi dengan persyaratan baru, sebagaimana diukur oleh kemiringan
kurva solusi.
4. Umur panjang. Waktu suatu solusi sistem dapat beradaptasi terhadap
perubahan dan tetap dapat berjalan, miswaktu dari pembuatan sistem
hingga diganti.
5. Ketidaksesuaian. Ukuran perilaku kekurangan dari waktu ke waktu, seperti
yang digambarkan oleh area yang dibatasi antara kurva kebutuhan pengguna
dan kurva solusi sistem.
Gambar 2.9. Tampilan proses-VP dari model spiral awal
Gambar 2.10. Prototipe evolusi
Gambar 2.12, yang merupakan pengulangan dari Gambar 2.3, menggambarkan

situasi di mana kebutuhan pengguna terus berlanjut berkembang dalam waktu. Gambar
2.13 menunjukkan pengembangan satu perangkat lunak diikuti oleh yang lain.
Perangkat lunak pekerjaan pengembangan dimulai pada waktu t0. Ini diterapkan pada
waktu t1. Kemampuan perangkat lunak yang sebenarnya (ditunjukkan oleh garis vertikal
pada t1) kurang dibandingkan dengan kebutuhan pengguna. Kemampuan perangkat
lunak terus berlanjut ditingkatkan untuk memenuhi kebutuhan pengguna yang
berkembang. Pada waktu t3, keputusan diambil untuk mengganti perangkat lunak yang
ada oleh yang baru. Perangkat lunak baru diimplementasikan pada waktu t4. Dan siklus
berlanjut. Semua lima metrik diilustrasikan pada Gambar. 2.14.
Gambar 2.11. Pengembangan inkremental
Gambar 2.12. Pengembangan terus menerus kebutuhan pengguna
Gambar 2.13. Kemampuan sistem tertinggal dari kebutuhan pengguna
Gambar 2.15 hingga Gambar 2.19 membandingkan berbagai model

pengembangan perangkat lunak dalam kerangka kerja dari lima metrik pengembangan
yang dibahas di atas. Angka-angka ini menunjukkan evolusi pengguna persyaratan
secara mendasar diabaikan selama pengembangan perangkat lunak dan dalam situasi
yang dinamis perubahan dalam persyaratan pengguna, paradigma prototyping

evolusioner dan sintesis perangkat lunak otomatis menghasilkan produk perangkat
lunak yang memenuhi kebutuhan pengguna yang terbaik.
Gambar 2.14. Metrik produktivitas perangkat lunak
Gambar 2.15. Kemampuan sistem tertinggal dari kebutuhan pengguna
Gambar 2.16. Pendekatan inkremental versus konvensional
Gambar 2.17. Prototipe evolusi versus pendekatan konvensional
Gambar 2.18. Penggunaan kembali perangkat lunak versus pendekatan

konvensional
Gambar 2.19. Sintesis perangkat lunak otomatis versus pendekatan konvensional
E. UPAYA FASILITAS DISTRIBUSI
Distribusi fase-bijaksana dari upaya yang dikeluarkan dalam pengembangan

perangkat lunak cukup terbuka. Populer distribusi upaya secara arif diberikan oleh
aturan empiris 40-20-40:
Analisis dan Desain: 40% dari total upaya
Coding dan Debugging: 20% dari total upaya
Pengujian dan Pemeriksaan: 40% dari total upaya
Wolverton (1974) memberikan distribusi upaya yang lebih rinci secara bertahap
sebagai:
Phase % Effort spend

Requirements analysis 8
Preliminary design 18
46%
Interface definition 4
Detailed design 16
Code and debug 20 20%
Development testing 21
Validation testing and
34%
Operational 13
demonstration
Berdasarkan data yang dipublikasikan tentang upaya bertahap yang dihabiskan

di sebelas proyek dan yang dilaporkan oleh dua belas penulis dan perusahaan,
Thibodeau dan Dodson (1985) melaporkan bahwa upaya rata-rata dihabiskan dalam
berbagai hal fase adalah sebagai berikut:
Analisis dan Desain: 37% dari total upaya
Coding dan Debugging: 20% dari total upaya
Pengujian dan Checkout: 43% dari total upaya
Fagan (1976) menyarankan kurva berbentuk siput (Gambar 2.20) untuk

menunjukkan jumlah orang yang biasanya dikaitkan dengan setiap fase siklus hidup.
Gambar 2.20. Pengembangan sumber daya manusia dan jadwal (Fagan 1986)
F. INTERRELASI SIKLUS HIDUP
Hubungan fase dapat sering divisualisasikan secara jelas dengan menggunakan

grafik kemajuan (Thibodeau dan Dodson, 1985). Diagram kemajuan menunjukkan nilai
awal dan akhir kegiatan yang direncanakan dan aktual terkait dengan setiap fase dan
pemuatan sumber daya (orang-jam) untuk setiap fase.
Gambar 2.21 menunjukkan grafik kemajuan seperti itu. Sumbu horizontal bagan
menunjukkan 'waktu' dan sumbu vertikal pemuatan sumber daya (orang-jam). Garis
solid menunjukkan nilai yang direncanakan dan garis putus-putus nilai aktual. Panjang
persegi panjang menunjukkan awal, akhir, rentang waktu fase, dan luasnya sumber daya
yang digunakan. Bagan menunjukkan bahwa analisis menggunakan lebih sedikit sumber
daya dan membutuhkan lebih banyak waktu daripada nilai yang direncanakan; kegiatan
desain dimulai kemudian dan berakhir lebih awal tetapi menggunakan lebih banyak
sumber daya dari yang direncanakan; pengkodean dimulai dan berakhir kemudian tetapi
menggunakan lebih banyak sumber daya dari yang direncanakan, yang adalah kasus
dengan pengujian juga. Bagan ini juga menggambarkan jumlah waktu tumpang tindih
yang signifikan fase (fase yang berdekatan). Dengan demikian dimungkinkan untuk
membuat hipotesis bahwa keterlambatan penyelesaian kegiatan dalam satu fase

memiliki pengaruh besar pada sumber daya yang digunakan, dan jadwal waktu, fase
segera berikut (dan fase selanjutnya lainnya juga).
Gambar 2.21. Aktivitas terjadwal dan aktual dalam pengembangan perangkat

lunak
Berdasarkan pengamatan di atas, Thibodeau dan Dodson berhipotesis dan

mengamati itu untuk perangkat lunak dengan ukuran tertentu, dalam rentang tertentu,
trade-off dimungkinkan antara sumber daya dalam satu fase dan sumber daya dalam
fase selanjutnya (atau fase sebelumnya). Gambar 2.21, misalnya, menunjukkan bahwa
jika upaya yang diberikan untuk desain berkurang (meningkat), maka lebih banyak
(kurang) upaya akan dibutuhkan dalam pengkodean. Thibodeau dan Dodson,
bagaimanapun, tidak dapat secara meyakinkan mendukung hipotesis ini, karena proyek
(yang datanya mereka gunakan) memiliki rentang usaha yang sangat kecil yang
dihabiskan dalam berbagai fase.
Ased pada karya Nordon (1970) dan pada studi data pada sekitar 150 sistem
lainnya dilaporkan oleh berbagai penulis, Putnam (1978) mengemukakan bahwa profil
dari upaya tersebut pada umumnya digunakan perangkat lunak per tahun (disebut kurva
proyek) atau (keseluruhan kurva siklus hidup tenaga kerja) diproduksi oleh
menambahkan ordinat kurva tenaga kerja untuk masing-masing fase. Gambar 2.22
menunjukkan individu kurva tenaga kerja dan kurva proyek.
Gambar 2.22. Kurva proyek
Orang mungkin memperhatikan itu
1. Sebagian besar kurva sub-siklus (kecuali untuk ekstensi) memiliki tingkat dan
terus menerus yang bervariasi ekor panjang yang menunjukkan bahwa 10%
akhir dari setiap fase upaya membutuhkan waktu yang relatif lama lengkap.
2. Kurva proyek memiliki serangkaian karakteristik yang sama dengan sub-siklus
konstituennya: bangkit, memuncak, dan ekor eksponensial.
3. Ada sejumlah besar tumpang tindih di antara fase-fase.
4. Upaya yang dihabiskan untuk manajemen proyek (meskipun kecil, hanya 10%)
juga termasuk dalam kehidupan perhitungan siklus tenaga kerja.
5. Perhitungan tenaga kerja, dibuat di sini, tidak termasuk persyaratan tenaga
kerja untuk analisis.
G. MEMILIH STRATEGI PENGEMBANGAN APLIKASI
Pada bagian sebelumnya kami membahas berbagai strategi pengembangan

perangkat lunak. Dalam kehidupan nyata, pengembang harus memilih strategi
pengembangan spesifik sebelum memulai tugas pengembangan. Dua pendekatan
direkomendasikan untuk pilihan ini :
1. Pendekatan Kontinjensi dan

2. Pendekatan Penilaian Risiko.
1. Pendekatan Kontingensi
Pendekatan ini disarankan oleh Naumann et al. (1980) dan Davis dan
Olson (1985). Davis dan Olson membedakan strategi pengembangan sebagai :
a. Strategi jaminan penerimaan (setara dengan model kode-dan-perbaiki),

b. Strategi jaminan linier (setara dengan model air terjun),
c. Strategi jaminan berulang (setara dengan model inkremental dan spiral), dan
d. Strategi jaminan eksperimental (setara dengan model prototyping).
Pemilihan strategi pengembangan tertentu didasarkan pada estimasi

kontribusi empat kontingensi pada tingkat ketidakpastian sehubungan dengan
kemampuan pengguna untuk mengetahui dan memperoleh pengguna
Persyaratan. Keempat kontinjensi adalah:
a. Ukuran proyek (kecil atau besar),

b. Tingkat struktur (terstruktur atau tidak terstruktur),
c. Pemahaman tugas pengguna (lengkap atau tidak lengkap), dan
d. Kemahiran tugas pengembang (tinggi atau rendah).
Gambar 2.23 menunjukkan model kontingensi untuk memilih

pengembangan persyaratan informasi strategi jaminan (Naumann et al. 1980).
Strategi jaminan penerimaan dapat direkomendasikan untuk masalah

kecil dan terstruktur untuk pengguna yang memiliki pemahaman lengkap
tentang area masalah, dan yang dikembangkan oleh tim yang memiliki
kemampuan tinggi dalam mengembangkan tugas-tugas tersebut. Di sisi lain,
strategi jaminan eksperimental adalah direkomendasikan untuk masalah besar
dan tidak terstruktur untuk pengguna, yang memiliki pemahamannya yang tidak
lengkap area masalah, dan yang dikembangkan oleh tim yang memiliki
kemampuan rendah dalam tugas pengembangan tersebut.
Gambar 2.23. Model kontingensi untuk memilih strategi jaminan

pembangunan
2. Pendekatan Penilaian Risiko
Sage (1995) menyarankan analisis kebutuhan risiko dan operasional

untuk setiap pengembangan perangkat lunak kesempatan untuk memutuskan
strategi pengembangan spesifik. Item yang dicakup dalam analisis ini dan skor
mereka untuk air terjun, inkremental, dan strategi prototyping ditunjukkan pada
Tabel 2.4a dan Tabel 2.4b. Strategi yang mendapat skor terendah diikuti untuk
pengembangan perangkat lunak.
Tabel 2.4 (a). Analisis resiko
Item Resiko Air terjun Incrimental Prototyping

Sistem terlalu besar untuk Tinggi Sedang Rendah
Pembuatan Sekali Kali
Persyaratan Pengguna Tidak Sedang Rendah Rendah
Cukup Memahami Media
Perubahan Cepat Tinggi Sedang Rendah
Diharapkan dalam Teknologi
Staf atau Anggaran Terbatas Sedang Tinggi Sangat Tinggi
Persyaratan Sistem Volatile Sangat Tinggi Sedang
Tinggi
Tabel 2.4 (b). Analisis Kebutuhan Operasional
Item kebutuhan Air terjun Incrimental Prototyping

operasional
Sistem terlalu besar untuk Tinggi Sedang Rendah
Pembuatan Sekali Kali
Persyaratan Pengguna Tidak Sedang Rendah Rendah
Cukup Memahami Media
Perubahan Cepat Tinggi Sedang Rendah
Diharapkan dalam Teknologi
Staf atau Anggaran Terbatas Sedang Tinggi Sangat Tinggi
Persyaratan Sistem Volatile Sangat Tinggi Sedang
Tinggi
H. PROSES PEMBANGUNAN PERANGKAT LUNAK NON-TRADISIONAL
Dalam dekade terakhir, sejumlah ide telah muncul tentang proses

pengembangan perangkat lunak baru. Fitur umum dari semua proses ini adalah
pengembangan berulang dan bertahap, dengan maksud untuk mematuhi perubahan
kebutuhan pengguna. Di bagian ini, kami menyoroti fitur tujuh seperti itu proses :
1. Pengembangan Perangkat Lunak Berbasis Komponen

2. Rational Unified Process
3. Model Spiral Menang-Menang
4. Pengembangan Aplikasi yang Cepat
5. Teknik Cleanroom
6. Teknik Serentak
7. Proses Pengembangan Agile
1. Pengembangan Perangkat Lunak Berbasis Komponen (CBSD)
Seperti yang akan dibahas dengan sangat rinci nanti, entitas yang sangat
mendasar dari metodologi berorientasi objek adalah kelas objek. Kelas
merangkum data dan operasi untuk memanipulasi data. Kelas-kelas ini, jika
dirancang dengan hati-hati, dapat digunakan di berbagai aplikasi. Kelas generik
seperti itu bisa saja disimpan di perpustakaan kelas (atau repositori) dan
merupakan komponen dasar perangkat lunak yang dapat digunakan kembali. Di

rumah perpustakaan kelas dan komponen komersial (COTS) telah memberikan
kesempatan untuk membangun sistem aplikasi perangkat lunak keseluruhan
dengan merakitnya dari komponen individu. Mengembangkan perangkat lunak
menggunakan pra-diuji, komponen yang dapat digunakan kembali membantu
mengurangi kesalahan dan pengerjaan ulang, mempersingkat waktu
pengembangan, dan meningkatkan produktivitas, keandalan, dan pemeliharaan.
Sayangnya, "komponen" adalah istilah yang terlalu sering digunakan dan

disalahpahami dalam industri perangkat lunak (Herzum dan Sims 2000).
Komponen dapat berkisar dari beberapa baris kode dan objek GUI, seperti sebuah
tombol, untuk subsistem lengkap dalam aplikasi ERP (Vitharana et al. 2004). Pree
(1997) mempertimbangkan komponen sebagai kapsul data dan sebagai tipe data
abstrak (ADT) yang merangkum data dan operasi dan menggunakan informasi
yang disembunyikan sebagai prinsip konstruksi inti. Dua definisi, layak
disebutkan di sini, adalah sebagai berikut:
“Komponen adalah paket perangkat lunak yang koheren yang dapat

dikembangkan dan dikirim secara independen sebagai unit, dan yang
menawarkan antarmuka yang dapat dihubungkan, tidak berubah, dengan
komponen lain menyusun sistem yang lebih besar. " (D'Souza dan Wills 1997).
“Komponen perangkat lunak adalah unit komposisi dengan antarmuka

yang ditentukan terus-menerus dan eksplisit hanya dependensi konteks.
Komponen perangkat lunak dapat digunakan secara independen dan tunduk pada
komposisi oleh pihak ketiga. " (Szyperki 1998)
Definisi-definisi ini menunjuk pada karakteristik komponen perangkat

lunak berikut (Cox dan Song 2001):
a. Komponen perangkat lunak adalah paket independen.

b. Memiliki antarmuka yang terdefinisi dengan baik.
c. Dapat dimasukkan tanpa memperhatikan bagaimana penerapannya.
Berlandaskan pada prinsip-prinsip rekayasa manufaktur, pengembangan

perangkat lunak berbasis komponen menganggap reusability sebagai esensi dan
menyembunyikan informasi sebagai properti inti dari komponen yang dapat
digunakan kembali. Pandangan terhadap historisitas bahasa pemrograman

menunjukkan beberapa pendekatan pada usabilitas dan menyembunyikan
informasi:
a. Subrutin dalam bahasa berorientasi prosedur (seperti Fortran, Cobol, dan

Pascal).
b. Modul dalam bahasa berorientasi modul (seperti Modula-2 dan Ada).
c. Kelas dalam bahasa berorientasi objek (seperti Smalltalk, C ++, dan Java).
d. Objek interaktif di lingkungan pemrograman komponen visual (seperti Visual
Basic) aktif atas bahasa prosedur-, modul-, atau berorientasi objek.
Pemrograman berorientasi objek membawa serta fasilitas warisan,

komposisi, desain pola, dan kerangka kerja yang membantu meningkatkan
penggunaan kembali ke status filsafat (pengembangan perangkat lunak berbasis
komponen). Kelas adalah komponen berbutir halus. Beberapa kelas terkait
biasanya membentuk satu komponen berbutir kasar — suatu subsistem.
Komponen COTS seperti kotak hitam yang memungkinkan seseorang

untuk menggunakannya tanpa mengetahui sumbernya kode. Komponen seperti
itu harus dihubungkan, sama seperti komponen perangkat keras harus
disambungkan bersama, untuk menyediakan layanan yang dibutuhkan. Metafora
kotak-dan-kawat (Pour 1998) ini ditemukan dalam penggunaan Java Beans di
pemrograman antarmuka pengguna dan protokol Object Linking and Embedding
(OLE) yang memungkinkan objek berbagai jenis (seperti dokumen pengolah kata,
spreadsheet, dan gambar) untuk berkomunikasi tautan.
Untuk merakit komponen yang berbeda yang ditulis dalam bahasa yang
berbeda, perlu komponen itu kompatibilitas dipastikan. Standar interoperabilitas
telah dikembangkan untuk memberikan definisi yang jelas infrastruktur
komunikasi dan koordinasi. Empat standar semacam itu layak disebutkan:
1. CORBA (Arsitektur Broker Permintaan Objek Umum) yang dikembangkan oleh

Manajemen Objek Grup (OMG).
2. COM + (Common Object Model) dari Microsoft.
3. Enterprise JavaBeans dari Sun.
4. Broker Komponen dari IBM.
Tidak ada kerangka kerja yang diterima secara universal untuk

pengembangan perangkat lunak berbasis komponen. Kami hadir yang diusulkan
oleh Capretz, et al. (2001) yang membedakan empat fase yang direncanakan
dalam pengembangan ini kerangka:
a. Domain Engineering
Dalam fase ini seseorang mensurvei kesamaan di antara berbagai

aplikasi dalam satu domain aplikasi untuk mengidentifikasi komponen yang
dapat digunakan kembali dalam keluarga aplikasi di domain itu. Jadi, dalam
sistem penggajian, karyawan, gaji kotor, tunjangan, dan potongan dapat
dianggap sebagai komponen, yang dapat digunakan berulang kali tanpa
memperhatikan sistem penggajian tertentu yang digunakan. Bergantung
pada ahli domain dan pengalaman yang diperoleh dalam aplikasi masa lalu,
rekayasa domain membantu memilih komponen yang harus dibangun dan
disimpan dalam repositori untuk digunakan dalam aplikasi masa depan
dalam domain yang sama.
b. System Analysis
fase nya seperti fase analisis persyaratan dalam model air terjun. Di
sini fungsional persyaratan, persyaratan (kualitas) non-fungsional, dan
kendala didefinisikan. Pada fase ini kita menciptakan model aplikasi yang
abstrak dan membuat analisis awal dari komponen yang diperlukan aplikasi.
Pilihannya adalah memilih arsitektur yang ada untuk perangkat lunak
berbasis komponen baru sistem atau membuat arsitektur baru yang
dirancang khusus untuk sistem baru.
c. Design
Fase desain melibatkan pembuatan model yang melibatkan

komponen yang berinteraksi. Di sini sang desainer memeriksa komponen-
komponen dalam repositori dan memilih komponen yang cocok dengan
komponen yang diperlukan untuk membangun perangkat lunak.
Pengembang mengevaluasi setiap kandidat komponen yang tidak tersedia
untuk menentukan komponennya kesesuaian, interoperabilitas dan
kompatibilitas. Terkadang komponen dikustomisasi untuk memenuhi

kebutuhan khusus kebutuhan. Seringkali komponen yang dipilih
disempurnakan lebih lanjut untuk membuatnya generik dan kuat. Jika
komponen tertentu tidak ditemukan dalam repositori, mereka harus
dibangun dalam fase implementasi.
d. Implementation
Fase ini melibatkan pengembangan komponen baru, memperluas

ruang lingkup komponen yang dipilih dan membuatnya generik, jika
diperlukan, dan menghubungkan kedua set komponen ini dengan yang dipilih
komponen yang tidak perlu diubah. Menghubungkan atau mengintegrasikan
komponen adalah kegiatan utama di pengembangan perangkat lunak
berbasis komponen. Masalah utama di sini adalah ketidakcocokan
komponen, karena komponen dikembangkan oleh sumber internal atau
eksternal yang berbeda, dan mungkin berdasarkan asumsi arsitektur yang
saling bertentangan — ketidakcocokan arsitektural. Brown dan Wallnau
(1996) menyarankan informasi berikut yang harus tersedia untuk komponen
agar cocok untuk digunakan kembali:
1) Antarmuka pemrograman aplikasi (API) - detail antarmuka komponen

2) Perangkat pengembangan dan integrasi yang diperlukan
3) Persyaratan penyimpanan run-time sekunder
4) Persyaratan prosesor (kinerja)
5) Persyaratan jaringan (kapasitas)
6) Layanan perangkat lunak yang disyaratkan (sistem operasi komponen
lain)
7) Asumsi keamanan (kontrol akses, peran pengguna, dan otentikasi)
8) Asumsi desain tertanam (seperti penggunaan teknik pemungutan suara
khusus dan pengecualian, deteksi dan pemrosesan)
Seperti dapat dilihat pada Gambar 2.24, setiap fase pengembangan

mempertimbangkan ketersediaan dapat digunakan kembali komponen.
Perkiraan kasar distribusi waktu untuk pengembangan adalah sebagai
berikut:
Gambar 2.24. Kerangka kerja untuk CBSD
a) Rekayasa domain: 25%

b) Analisis sistem: 25%
c) Desain: 40%
d) Implementasi: 10%
Seperti yang diharapkan, fase desain membutuhkan waktu

maksimum dan fase implementasi membutuhkan waktu minimum.
Selection of Components
Masalah yang sering menghantui pengembang sistem adalah pemilihan

komponen yang sangat dibutuhkan dari jumlah komponen yang sangat besar.
Masalah muncul bukan hanya karena ukuran besar repositori tetapi juga karena
terminologi yang tidak dikenal atau tidak terduga. Untuk memudahkan
pencarian, itu diinginkan untuk mengatur komponen dalam repositori dengan
mengekspresikan hubungan komponen. Hubungan seperti itu memungkinkan
komponen untuk diklasifikasikan dan dipahami. Empat hubungan besar telah

diusulkan oleh Capretz, et al. (2001):
a. Menulis (Memiliki-hubungan) (<komponen-1>, <list-komponen>).

Komponen adalah terdiri dari sejumlah komponen sederhana.
b. Mewarisi (Is-a relationship) (<component-1>, <komponen-2>).
Hubungan ditemukan di kelas diagram hierarki juga dapat didefinisikan
antara dua kelas.
c. Gunakan (Menggunakan-a hubungan) (<komponen-1>, <list-
komponen>). Ini mendefinisikan operasi apa pun didefinisikan dalam
komponen apa pun dalam daftar komponen.
d. Konteks (Is-part-of relationship) (<component-1>, <context-1>). Relasi
ini mengasosiasikan komponen dengan konteks yang bisa menjadi
kerangka kerja.
Lebih baik untuk mengembangkan kerangka kerja pembangunan

antarmuka — koleksi spesifik domain yang dapat digunakan kembali komponen
— untuk domain aplikasi tertentu. Juga, lebih baik untuk mengembangkan
beberapa yang dapat digunakan kembali secara independen perpustakaan, satu
untuk setiap domain aplikasi, dari satu perpustakaan besar komponen.
Pengembangan perangkat lunak berbasis komponen memerlukan

keterampilan baru
a. mengevaluasi dan membuat arsitektur perangkat lunak,

b. mengevaluasi, memilih, dan mengintegrasikan komponen perangkat
lunak yang tidak tersedia,
c. menguji sistem berbasis komponen, dan
d. mendokumentasikan keputusan trade-off.
2. Rational Unified Process (RUP)
Dikembangkan oleh Royce (2000) dan Kruchten (2000) dan dipopulerkan

oleh Booch, et al. (2000), Rational Unified Process (RUP) adalah pendekatan
siklus hidup independen-proses yang dapat digunakan dengan a sejumlah proses
rekayasa perangkat lunak. Berikut ini adalah daftar karakteristik proses:
a. Ini adalah proses berulang, menuntut perbaikan atas model dasar melalui
beberapa siklus sambil mengakomodasi persyaratan baru dan
menyelesaikan risiko.
b. Ini menekankan model daripada dokumen kertas dan karena itu cocok untuk
UML lingkungan Hidup.
c. Pengembangannya adalah arsitektur-sentris, menekankan pada
pengembangan arsitektur perangkat lunak yang kuat baseline, sehingga
dapat memfasilitasi pengembangan paralel dan berbasis komponen yang
menurunkan terjadinya kegagalan dan pengerjaan ulang.
d. Ini adalah objek-driven, memunculkan informasi dengan memahami cara
perangkat lunak yang dikirim adalah untuk digunakan.
e. Berorientasi objek, menggunakan konsep objek, kelas, dan hubungan.
f. Dapat dikonfigurasi (disesuaikan) untuk kebutuhan proyek kecil dan besar.
Fase RUP
Rational Unified Process mendefinisikan empat fase pengembangan

(Tabel 2.5) yang dapat dikelompokkan di bawah dua kategori besar:
Awal Rekayasa :
1) Inception: Persyaratan
2) Elaborasi: Analisis dan Desain
Produksi:
3) Konstruksi: Kode dan Uji

4) Transisi: Penempatan
1) Inception : Persyaratan Awal
Mencakup dalam periode yang relatif singkat sekitar satu minggu atau lebih,
fase ini berkaitan dengan pendapat tentang tujuan dan kelayakan sistem
baru dan untuk memutuskan apakah itu menginvestasikan waktu dan
sumber daya berharga untuk mengembangkan produk. Jawaban untuk

pertanyaan-pertanyaan berikut dicari dalam fase ini (Larman, 2002):
a. Apa ruang lingkup produk, visi, dan kasus bisnis?

b. Apakah layak?
c. Haruskah itu dibeli atau dibuat?
d. Bagaimana urutan besarnya estimasi kasar?
e. Apakah bermanfaat untuk melanjutkan proyek?
Seperti dapat dilihat, permulaan bukanlah fase persyaratan; ini lebih

seperti fase kelayakan.
Tabel 2.5: Deskripsi Fase tentang Proses Terpadu
Tahap Kegiatan Tonggak pencapaian Kiriman

titik jangkar
Lahirnya Tinjauan umum dan Review Life-Cycle Ringkasan dan
studi kelayakan Objectives (LCO) laporan
kelayakan
Elaborasi Tujuan dan ruang Review Life-Cycle Arsitektur

lingkup sistem Objectives (LCO)
terperinci
Konstruksi Pengkodea, Tinjauan Perangkat lunak

pengujian, dan Kemampuan teruji
integrasi Operasional Awal
(IOC)
Transisi Perencanaan Review Rilis Produk Perangkat lunak

konversi dan (PRR) yang diterapkan
pelatihan pengguna
2) Elaborasi,
Terdiri hingga empat iterasi dan setiap iterasi mencakup maksimal enam
minggu, inifase mengklarifikasi sebagian besar persyaratan, menangani
masalah berisiko tinggi, mengembangkan (program dan tes) itu arsitektur
inti dalam iterasi pertama dan peningkatan dalam iterasi berikutnya. Ini
bukan fase desain dan tidak membuat prototipe yang dibuang; produk
akhir dari fase ini adalah arsitektur yang dapat dieksekusi atau dasar
arsitektur.
Pada akhir fase ini, seseorang memiliki tujuan sistem terperinci dan ruang
lingkup, arsitektur yang dipilih, mitigasi risiko utama, dan keputusan
untuk maju (atau sebaliknya).
3) Konstruksi
Dalam fase ini, sejumlah iterasi dilakukan untuk mengembangkan produk
perangkat lunak secara bertahap.Ini termasuk pengkodean, pengujian,
pengintegrasian, dan persiapan dokumentasi dan manual, dll., Sehingga
produk dapat dibuat operasional.
4) Transisi
Dimulai dengan rilis beta dari sistem, fase ini termasuk melakukan
pengembangan tambahan diuntuk memperbaiki kesalahan yang
sebelumnya tidak terdeteksi dan menambahkan ke beberapa fitur yang
ditunda.
Boehm, dkk. (2000) telah menentukan tonggak titik jangkar tertentu (Gbr.
2.25) yang ditentukan pada bagian akhir poin dari fase-fase ini. Tonggak titik
jangkar ini dijelaskan di bawah ini:
Gambar 2.25. Tonggak sejarah dalam model RUP
Inception Readiness Review (IRR)
a. Tujuan, ruang lingkup, dan batas sistem kandidat: Pemangku kepentingan

utama.
b. Dukungan untuk fase awal: Komitmen untuk mencapai paket LCO yang
sukses.
Ulasan Life-Cycle Objectives (LCO)
a. Paket LCO: Tujuan dan ruang lingkup sistem, batas sistem, parameter
lingkungan dan asumsi, kekurangan sistem saat ini, skenario nominal utama,
peran pemangku kepentingan dan tanggung jawab, skenario penggunaan
utama, persyaratan, prototipe, prioritas, pemangku kepentingan 'persetujuan
pada hal-hal penting, arsitektur perangkat lunak, elemen dan hubungan fisik
dan logis,COTS dan komponen yang dapat digunakan kembali, pemangku
kepentingan siklus hidup dan model proses siklus hidup.
b. Kelayakan dijamin untuk setidaknya satu arsitektur: Jaminan konsistensi.
c. Kelayakan divalidasi oleh Dewan Peninjau: Diterima oleh Dewan Peninjau,
persetujuan pemangku kepentingan pada hal-hal penting, dan berkomitmen
untuk mendukung fase elaborasi. Sumber daya berkomitmen untuk mencapai
paket LCA yang sukses.
Ulasan Life-Cycle Architecture (LCO)
a. Paket LCA: Elaborasi tujuan sistem dan ruang lingkup dengan kenaikan, kunci
di luar nominal skenario, skenario penggunaan, resolusi risiko luar biasa,
desain fungsi dan antarmuka, arsitektur, komponen fisik dan logis, COTS dan
daftar pilihan penggunaan ulang, yang harus dilakukan (TBD) untuk
peningkatan di masa depan, dan jaminan konsistensi.
b. Kelayakan terjamin untuk arsitektur yang dipilih.
c. Kelayakan divalidasi oleh Dewan Peninjau.
d. Sumber Daya Berkomitmen untuk mencapai Kemampuan Operasional Awal
Kemampuan Operasional Awal (IOC)
a. Persiapan perangkat lunak: Perangkat lunak operasional dan dukungan

dengan komentar dan dokumentasi,persiapan atau konversi data awal, lisensi
yang diperlukan dan hak untuk COTS dan digunakan kembali perangkat lunak,
dan pengujian kesiapan yang sesuai.
b. Persiapan lokasi: Fasilitas awal, peralatan, persediaan, dan pengaturan
dukungan vendor COTS.
c. Pengguna awal, persiapan operator dan pemelihara: pembangunan tim,
pelatihan, pengenalan penggunaan, operasi, dan pemeliharaan.
d. Tinjauan Kesiapan Transisi: Rencana konversi, instalasi, pelatihan, dan
peralihan operasional,dan komitmen pemangku kepentingan untuk
mendukung fase transisi dan pemeliharaan.
Ulasan Rilis Produk (PRR)
a. Jaminan keberhasilan peralihan dari sistem sebelumnya untuk lokasi

operasional utama.
b. Tim untuk operasi dan pemeliharaan.
c. Kepuasan pemangku kepentingan tentang kinerja sistem.
d. Komitmen pemangku kepentingan untuk mendukung fase pemeliharaan.
Tiga konsep penting dalam RUP. Mereka adalah: Iterasi, Disiplin, dan
Artefak.
Iterasi
Produk perangkat lunak dikembangkan dalam sejumlah iterasi. Padahal,

ide yang paling penting RUP yang mendasarinya adalah pengembangan
perangkat lunak yang iteratif dan bertahap. Iterasi adalah lengkap siklus
pengembangan, mulai dari persyaratan hingga pengujian yang
menghasilkan produk yang dapat dieksekusi, merupakan bagian dari
produk akhir yang sedang dikembangkan. Setiap iterasi adalah kotak
waktu (mis. Dengan panjang waktu tetap),waktu biasanya
kecil.Pengulangan
Disiplin
Dikenal sebelumnya sebagai alur kerja, model Unified Process

mendefinisikan sembilan disiplin satu atau ebih banyak yang terjadi dalam
setiap iterasi. Sembilan disiplin ilmu adalah: Pemodelan Bisnis,
Persyaratan,Desain, Implementasi, Uji, Penempatan, Konfigurasi dan
Manajemen Perubahan, Proyek Manajemen, dan Lingkungan.
Artefak
Suatu disiplin terdiri dari serangkaian kegiatan dan tugas konseptualisasi,

implementasi, dan peninjauan dan seperangkat artefak (dokumen terkait
atau yang dapat dieksekusi yang diproduksi, dimanipulasi, atau
dikonsumsi).Artefak adalah produk kerja (seperti kode, dokumen teks,
diagram, model, dll.) Yang dihasilkan sebagai hasil kontrak (output) dari
kegiatan disiplin dan digunakan sebagai baseline (atau referensi) untuk,
dan masukan untuk, kegiatan selanjutnya.
Model adalah bentuk artefak paling penting yang digunakan dalam RUP.
Sembilan jenis model tersebut tersedia di RUP: Model bisnis, Model domain, Use
case model, Model analisis, Model desain, Model proses, model penyebaran,
model implementasi, dan model tes. Analisis dan Proses model bersifat opsional.
3. Model Wins Spiral
Boehm dan Ross (1989) memperluas model spiral asli dengan

memasukkan pertimbangan terkait kepada para pemangku kepentingan. Model
spiral win-win menggunakan pendekatan manajemen teori W, yang
membutuhkan bahwa agar proyek berhasil, para pemangku kepentingan utama
sistem harus menjadi pemenang. Cara untuk mencapainya kondisi win-win ini
adalah menggunakan pendekatan berbasis negosiasi untuk menentukan
sejumlah langkah tambahan siklus pengembangan spiral normal. Langkah-
langkah tambahan adalah sebagai berikut (Gbr. 2.26):
a. Identifikasi pemangku kepentingan tingkat berikutnya.

b. Identifikasi kondisi kemenangan pemangku kepentingan.
c. Rekonsiliasi kondisi kemenangan.
d. Menetapkan tujuan, kendala, dan alternatif tingkat selanjutnya.
e. Mengevaluasi produk dan memproses alternatif.
f. Atasi risiko.
g. Menentukan level produk dan proses selanjutnya, termasuk partisi.
h. Validasi definisi produk dan proses.
i. Tinjau dan komit.
Keuntungan dari model spiral win-win adalah keterlibatan kolaboratif dari

para pemangku kepentingan yang menghasilkan lebih sedikit pengerjaan ulang
dan pemeliharaan, eksplorasi awal rencana arsitektur alternatif, lebih cepat
pengembangan, dan kepuasan pemangku kepentingan yang lebih besar dimuka.
Gambar 2.26. Model Wins Spiral
4. Model Pengembangan Aplikasi Cepat (RAD)
Respons IBM terhadap kekurangan model air terjun adalah

pengembangan aplikasi yang cepat (RAD) model (Martin, 1991). Fitur-fitur model
ini adalah sebagai berikut:
a. Pengguna terlibat dalam semua fase siklus kehidupan — dari persyaratan

hingga pengiriman akhir. Pengembangan alat GUI memungkinkan.
b. Prototipe ditinjau dengan pelanggan, menemukan persyaratan, jika ada.
Pengembangan dari setiap pengiriman terintegrasi adalah kotak waktu
(katakanlah, dua bulan).
c. Fase dari model ini adalah sebagai berikut:
1) Perencanaan Kebutuhan dengan bantuan Workshop Kebutuhan
(Persyaratan Bersama Perencanaan, JRP) — diskusi terstruktur
tentang masalah bisnis.
2) Deskripsi Pengguna dengan bantuan teknik desain aplikasi bersama
(JAD) untuk mendapatkan pengguna Keterlibatan, di mana alat
otomatis digunakan untuk menangkap informasi pengguna.
3) Konstruksi ("lakukan sampai selesai") yang menggabungkan desain
terperinci, pengkodean dan pengujian, dan rilis kepada pelanggan
dalam kotak waktu. Penggunaan kode generator yang banyak,

generator layar, dan alat produktivitas lainnya dibuat.
4) Cutover yang mencakup pengujian penerimaan, instalasi sistem, dan
pelatihan pengguna.
5. Rekayasa Perangkat Lunak Cleanroom
Awalnya diusulkan oleh Mills, et al. (1987) dan dipraktekkan di

IBM, filosofi Cleanroom memiliki asal dalam pembuatan perangkat keras. Bahkan,
istilah "Cleanroom" digunakan dengan menggambar analogi dengan unit fabrikasi
semikonduktor (kamar bersih) di mana cacat dihindari oleh manufaktur di sebuah
suasana sangat bersih. Pendekatan "perangkat keras" untuk fabrikasi perangkat
keras mensyaratkan hal itu membuat produk yang lengkap dan kemudian
berusaha menemukan dan menghilangkan cacat, orang harus menggunakan
metode yang ketat untuk menghilangkan kesalahan dalam spesifikasi dan desain
sebelum membuat produk. Idenya adalah untuk sampai pada produk akhir yang
tidak membutuhkan proses pengerjaan ulang cacat atau mahal, dan dengan
demikian menciptakan "Cleanroom"lingkungan Hidup.
Ketika diterapkan pada pengembangan perangkat lunak, ia

memiliki karakteristik sebagai berikut:
a. Produk perangkat lunak dikembangkan mengikuti strategi tambahan.

b. Desain, konstruksi, dan verifikasi setiap kenaikan membutuhkan urutan
yang jelas langkah-langkah ketat berdasarkan prinsip-prinsip metode
formal untuk spesifikasi dan desain dan metode berbasis statistik untuk
sertifikasi untuk kualitas dan keandalan. Pendekatan Cleanroom
bertumpu pada lima prinsip utama:
1) Strategi pengembangan tambahan.
2) Spesifikasi formal persyaratan.
3) pemrograman terstruktur.
4) Verifikasi statis bangunan individu menggunakan argumen kebenaran
berbasis matematika.
5) Pengujian statistik dengan bantuan model pertumbuhan keandalan.
Pendekatan Cleanroom menggunakan spesifikasi kotak-struktur.

"Kotak" analog dengan a modul dalam bagan hierarki atau objek dalam diagram
kolaborasi. Setiap kotak mendefinisikan fungsi menjadi dilakukan dengan
menerima satu set input dan menghasilkan satu set output. Kotak sangat
didefinisikan bahwa kapan mereka terhubung, mereka bersama-sama
menentukan fungsi perangkat lunak yang dikirimkan.
Kotak dapat terdiri dari tiga jenis dengan urutan penyempurnaan

yang meningkat: Kotak Hitam, Kotak Negara, dan Kosongkan Kotak. Kotak hitam
mendefinisikan input dan output yang diinginkan. Kotak negara mendefinisikan,
menggunakan konsep diagram transisi negara, data dan operasi yang diperlukan
untuk menggunakan input untuk menghasilkan output yang diinginkan.
Clear box mendefinisikan prosedur pemrograman terstruktur berdasarkan

prinsip penyempurnaan bertahap itu mendefinisikan bagaimana input digunakan
untuk menghasilkan output. Verifikasi formal merupakan bagian integral dari
pendekatan clearnroom . Seluruh tim pengembangan, bukan hanya tim
pengujian, yang terlibat dalam proses verifikasi. Prinsip yang mendasari formal
verifikasi adalah untuk memastikan bahwa untuk input yang benar, transformasi
yang dilakukan oleh sebuah kotak menghasilkan yang benar keluaran . Dengan
demikian, kondisi masuk dan keluar kotak ditentukan terlebih dahulu. Karena
fungsi transformasi adalah berdasarkan pemrograman terstruktur, seseorang
mengharapkan untuk memiliki urutan, pemilihan, dan struktur iterasi. Seseorang
mengembangkan aturan verifikasi sederhana untuk setiap struktur tersebut.
Dapat dicatat bahwa metode formal, diperkenalkan pada bab 7, juga digunakan
untuk em syst yang lebih kompleks yang melibatkan sistem multiplelogic yang
saling berhubungan .
6. Rekayasa Serentak (Concurrent Process Model)
Dalam proyek perangkat lunak, terutama ketika mereka besar, orang

menemukan bahwa pada suatu titik waktu, kegiatan milik fase yang berbeda
sedang dilakukan bersamaan (bersamaan). Selanjutnya beragam kegiatannya
bisa di berbagai negara. Melacak status setiap aktivitas cukup sulit. Acara
dihasilkan dalam suatu kegiatan atau di tempat lain dapat menyebabkan transisi
aktivitas dari satu negara ke negara lain. Misalnya, aktivitas pengembangan unit
uji kasus mungkin dalam kondisi seperti tidak dimulai, sedang dikembangkan,
sedang ditinjau, sedang direvisi, dan dikembangkan.
Kwitansi desain terperinci, mulai desain kasus uji, dan akhir desain kasus
uji, dll., adalah peristiwa yang memicu perubahan status. Model proses
bersamaan mendefinisikan aktivitas, tugas, keadaan terkait, dan peristiwa yang
seharusnya memicu transisi negara (Davis dan Sitaram , 1994). Prinsip-prinsip
model ini digunakan di client-server lingkungan pengembangan tempat aktivitas
tingkat-sistem dan server (komponen) terjadi secara bersamaan .
7. Proses Pengembangan Agile
Untuk mematuhi persyaratan pengguna yang berubah, proses

pengembangan perangkat lunak harus dilakukan lincah . Proses pengembangan
lincah mengikuti urutan pengembangan yang berbeda (Gbr. 2.27).
Gambar 2.27. Proses Pengembangan Agile
Proses gesit lebih disukai di mana persyaratan berubah dengan cepat. Di

awal masing-masing skenario pengembangan , fungsi sistem dicatat dalam
bentuk cerita pengguna. Pelanggan dan tim pengembangan mendapatkan situasi
pengujian dari spesifikasi. Pemrograman desain pengembang antarmuka untuk
mencocokkan kebutuhan tes dan mereka menulis kode untuk mencocokkan tes
dan antarmuka. Mereka sempurnakan desain agar sesuai dengan kode. Extreme
Programming (XP) adalah salah satu proses lincah yang paling matang dan paling
terkenal. Beck (2000) dan Beck and Fowler (2000) memberikan perincian tentang
proses agile berbasis XP. SCRUM juga popular proses agile .
Kami membahas di bawah pendekatan mereka untuk pengembangan

agile dalam beberapa detail. Gambar 2.28 menunjukkan proses agile dalam
beberapa detail. Cerita pengguna adalah deskripsi dari fungsi yang diharapkan
dilakukan sistem. Pelanggan menulis cerita pengguna tentang masing-masing
fungsionalitas di tidak lebih dari tiga kalimat di / nya kata-katanya sendiri. Kisah
pengguna berbeda dari kasus penggunaan dalam hal itu mereka tidak hanya
menggambarkan antarmuka pengguna. Mereka berbeda dari persyaratan
tradisional spesifikasi bahwa mereka tidak begitu rumit; mereka tidak
menyediakan tata letak layar, tata letak basis data, algoritma tertentu , atau
bahkan teknologi spesifik. Mereka hanya memberikan detail yang cukup untuk
dapat dibuat perkiraan waktu risiko rendah untuk dikembangkan dan diterapkan.
Pada saat implementasi, pengembang mengumpulkan persyaratan tambahan
dengan berbicara langsung dengan pelanggan.
Gambar 2.28. Pemrograman yang ekstrim - proses yang disederhanakan
Cerita pengguna digunakan untuk membuat perkiraan waktu untuk

mengimplementasikan solusi. Setiap cerita idealnya membutuhkan waktu antara
1 hingga 3 minggu untuk diterapkan jika pengembang benar-benar terlibat dalam
pengembangannya, dengantidak ada lembur atau tugas lainnya selama periode
ini. Jika dibutuhkan kurang dari 1 minggu, itu berarti bahwa cerita pengguna
menggambarkan persyaratan yang sangat rinci. Dalam kasus seperti itu, dua atau
tiga cerita pengguna terkait bisa jadi digabungkan untuk membentuk satu cerita
pengguna. Jika implementasinya membutuhkan waktu lebih dari 3 minggu, itu
artinya pengguna cerita mungkin telah menanamkan lebih dari satu cerita dan
perlu dirinci lebih lanjut.
Cerita pengguna digunakan untuk perencanaan rilis dan membuat tes

penerimaan. Rencana rilis diputuskan dalam pertemuan perencanaan rilis.
Rencana rilis menentukan cerita pengguna yang akan dikembangkan dan
diimplementasikan dalam rilis tertentu. Antara 60 dan 100 cerita merupakan
rencana rilis . Sebuah rilis plan juga menentukan tanggal untuk rilis. Pelanggan,
pengembang, dan manajer menghadiri perencanaan rilis pertemuan . Pelanggan
memprioritaskan cerita pengguna, dan cerita prioritas tinggi diambil untuk
pengembangan pertama .
Setiap rilis membutuhkan beberapa iterasi. Beberapa iterasi pertama

mengambil pengguna prioritas tinggi cerita . Kisah-kisah pengguna ini kemudian
diterjemahkan ke dalam tugas-tugas pemrograman yang ditugaskan ke grup
programmer . Kisah-kisah pengguna akan diambil dan waktu untuk
mengembangkannya dalam satu iterasi diputuskan dalam pertemuan
perencanaan iterasi.
Cerita pengguna juga digunakan untuk merencanakan tes penerimaan.

Pemrograman ekstrem mengharapkan itu setidaknya satu tes penerimaan
otomatis dibuat untuk memverifikasi bahwa cerita pengguna diimplementasikan
dengan benar. Setiap iterasi memiliki kumpulan cerita pengguna yang jelas dan
serangkaian tes penerimaan yang ditentukan. Biasanya, sebuah iterasi tidak
boleh memakan waktu kurang dari 2 minggu atau lebih dari 3 minggu. Pertemuan
perencanaan iterasi berlangsung sebelum iterasi berikutnya akan dimulai.
Maksimal selusin iterasi biasanya dilakukan untuk rilis rencana .
Solusi Spike sering dibuat untuk mengatasi masalah desain yang sulit
yang juga terkait perkiraan waktu yang tidak pasti. Solusi spike adalah program
sekali pakai sederhana untuk mengeksplorasi solusi potensial dan membuat
estimasi waktu yang lebih andal. Biasanya, 1 atau 2 minggu dihabiskan dalam
mengembangkan solusi spike.
Pengodean yang diperlukan untuk cerita pengguna biasanya dilakukan

oleh dua programmer. Tes unit dilakukan untuk memastikan bahwa setiap unit
100% bebas bug. Programmer fokus pada iterasi saat ini dan sepenuhnya
abaikan pertimbangan apa pun di luar iterasi ini. Kode tersebut milik grup, artinya
kode apa saja tidak bekerja adalah tanggung jawab seluruh kelompok dan bukan
hanya programmer yang menulis kode.
Ketika kecepatan proyek tinggi, artinya kecepatan kemajuan proyek

sangat bagus, pertemuan perencanaan rilis berikutnya biasanya diadakan untuk
merencanakan rilis berikutnya.
Karakteristik pengembangan agile adalah sebagai berikut:
a. Tes-pemrograman pertama — Tes mendahului desain atau pengkodean.

b. Incremental — rilis perangkat lunak kecil dengan iterasi cepat.
c. Pengembangan berulang, setiap iterasi membahas kebutuhan pengguna
tertentu.
d. Pengembangan tepat waktu dengan perencanaan mikro berlangsung
untuk setiap iterasi
e. Kooperatif — klien dan pengembang bekerja secara konstan bersama
dengan komunikasi yang erat.
f. Kepemilikan kode kolektif, dengan menulis kode bebas cacat sebagai
tanggung jawab keseluruhan sekelompok programmer.
g. Mudah — model itu sendiri mudah dipelajari dan dimodifikasi serta
didokumentasikan dengan baik.
h. Adaptif — perubahan menit terakhir dapat dilakukan.
i. Keterlibatan pengguna intensif dalam menentukan persyaratan,
memprioritaskannya, membuat rencana rilis, dan membuat tes
penerimaan.
SCRUM mirip dengan pemrograman ekstrem yang terdiri dari serangkaian

prinsip manajemen proyek berdasarkan pada tim swakelola lintas fungsi kecil
(tim Scrum). Tim bekerja pada iterasi 30 hari ( sprint ) dengan minggu kerja 40
jam. Setiap iterasi berakhir dengan ulasan sprint. Seorang tenaga pemasaran
bertindak a pemilik produk dan menentukan fitur yang harus diimplementasikan
dalam rilis untuk memuaskan segera kebutuhan pelanggan . Seorang master
Scrum melatih tim melalui proses dan menghilangkan segala hambatan. Di
sebuah 15 menit pertemuan stand-up, anggota tim mengambil persediaan setiap
pagi dan berbicara hambatan dan rencana harian.
Fowler (2000) telah membagi spektrum proses pengembangan sebagai

berat atau ringan dan prediktif atau adaptif. Proses berat ditandai oleh kekakuan,
birokrasi, dan perencanaan jangka panjang. Proses prediktif ditandai dengan
prediksi kebutuhan pengguna pada awal fase pengembangan dan perencanaan
rinci kegiatan dan sumber daya dalam rentang waktu yang lama, dan biasanya
ikuti proses pengembangan berurutan. Proses lincah ringan dan adaptif.
I. KONSEP YANG BERBEDA DARI 'SIKLUS HIDUP'
Jones (1986, hlm. 117–120), dalam kata pengantarnya tentang pemrograman

analisis siklus hidup, merasakan hal itu Ungkapan 'siklus hidup' adalah ambigu dan
menyampaikan tiga konsep yang berbeda ketika dianalisis dengan cermat. Pertama dari
konsep-konsep ini berkaitan dengan urutan kelahiran-to-kematian konvensional
peristiwa tunggal, baru sistem pemrograman .
Konsep kedua yang mendasari ungkapan 'siklus hidup' adalah '' lebih global
dalam cakupan dan mengacu pada pertumbuhan kegiatan pemrograman dan
pengolahan data dalam suatu perusahaan. Item yang menarik adalah hal - hal seperti
besarnya aplikasi yang ditumpuk, proporsi relatif personil bekerja dalam pengembangan
sistem baru vis -A- vis bekerja dalam pemeliharaan, tren bertahap dalam perangkat
lunak kualitas dan produktivitas di seluruh perusahaan ... dan semakin lambat (atau
cepat dalam beberapa kasus) berkembang seperangkat program sistem dan aplikasi
yang akan dijalankan perusahaan untuk memenuhi kebutuhan pemrosesan datanya ''
(Jones 1986, hlm. 117–118).
Konsep ketiga berhubungan dengan orang-orang yang dipekerjakan oleh suatu
perusahaan untuk mengerjakan program dan kegiatan pengolahan data. Item yang
menarik di sini adalah perkembangan karier para praktisi perangkat lunak mulai dari
masuk hingga pensiun, kebutuhan pelatihan di berbagai tingkatan, dan sejenisnya.
Modul telah membahas berbagai bentuk siklus hidup pengembangan perangkat
lunak. Dan selanjutnya bahasan lengkap akan memberikan rincian berbagai fase dari
siklus hidup ini.

Modul 2. Siklus Hidup Pengembangan Perangkat Lunak-OK

Diunggah oleh

Informasi Dokumen

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

Modul 2. Siklus Hidup Pengembangan Perangkat Lunak-OK

Diunggah oleh

Hak Cipta:

Format Tersedia

Analisis Perancangan Perangkat Lunak

A. PROSES PENGEMBANGAN PERANGKAT LUNAK

Selama tahun-tahun awal pengembangan perangkat lunak (tahun lima

c. Produk perangkat lunak besar dan pengembangannya oleh sekelompok

2. Model Air Terjun

Untuk waktu yang lama industri perangkat lunak berada dalam

Model air terjun mendapatkan namanya dari kesamaan struktural

a. Proses pengembangan perangkat lunak terdiri dari sejumlah fase secara

Gambar 2.1. Model air terjun Royce (1970)

g. Biasanya, output dibekukan, dan dokumen output ditandatangani oleh staf

h. Dimungkinkan untuk mengembangkan alat pengembangan yang berbeda

i. Fase memberikan dasar untuk manajemen dan kontrol karena mereka

Dengan demikian, model ini menyediakan pendekatan praktis dan disiplin

Penulis yang berbeda menggambarkan fase untuk siklus hidup

Tahap definisi berkaitan dengan perumusan masalah aplikasi, analisis

Gambar 2.2. Model Air Terjun Boehm (1981)

Tabel 2.1: Fase Siklus Hidup oleh Berbagai Penulis

Thibodeau dan Boehm (1981) Sage (1995)

a. Integrasi Berkepanjangan dan Kerusakan Desain Akhir. Penekanan berat

(fase pengujian). Resolusi risiko yang terlambat menghasilkan perubahan

Tabel 2.2: Fase dan Sub-Fase Siklus Hidup Perangkat Lunak

Fase I Definisi masalah Analisis masalah Pilihan teknologi

Fase 7 Integrasi dan Inspeksi, perbaikan dan pengerjaan

Kinerja Proses Perangkat Lunak Konvensional dalam Praktek

a. Menemukan dan memperbaiki masalah perangkat lunak setelah pengiriman

1. Semua fase dan tujuan terkait mereka diperlukan. Dimungkinkan, seperti

Davis et al. (1988) mengutip penggunaan model air terjun berikut:

1. Model ini mendorong seseorang untuk menentukan apa yang seharusnya

3. Ini memungkinkan manajer proyek untuk melacak kemajuan secara

4. Menuntut agar proses pengembangan menghasilkan serangkaian

5. Ini mengurangi biaya pengembangan dan pemeliharaan karena

6. Ini memungkinkan organisasi yang akan mengembangkan sistem

Kritik Model Air Terjun

Model air terjun telah memberikan pedoman yang sangat dibutuhkan

Untuk mengatasi kesulitan-kesulitan ini, dua pendekatan luas telah

Model air terjun adalah pendekatan level-by-level murni, dari atas ke

evolusioner, oleh konstrast, model kerja perangkat lunak dikembangkan dan

Pendekatan evolusi dapat diimplementasikan dalam dua bentuk :

Implementasi Incrimental (Boehm 1981, Gilb 1988)

Di sini perangkat lunak dikembangkan dalam peningkatan (incremental)

Sebagai contoh, IGRASP, Paket Simulasi Grafis Interaktif, dikembangkan

1. Periksa kesalahan dan urutkan secara manual pernyataan program

Peningkatan 1 menambahkan fitur :

Gambar 2.3. Pengembangan IGRASP secara bertahap

Pendekatan tambahan telah mendapat banyak keuntungan:

3. Waktu untuk menunjukkan beberapa hasil kepada pengguna sangat

Masalah-masalah tertentu, umumnya terkait dengan pengembangan

Metode ini didasarkan pada prosedur eksperimental di mana prototipe

1. Prototyping throwaway cepat (perancah) (Gbr. 2.4) dan

Gambar 2.4. Model pengembangan prototipe sistem aplikasi

Prototipe lempar mengikuti prinsip 'lakukan dua kali' yang dianjurkan

Dalam hal prototipe evolusi, prototipe awal tidak dibuang. Alih-alih,

a. Prototyping Evolutionary vs Throwaway

Karakteristik dari kedua metode prototyping diberikan di bawah ini:

1) Kedua jenis prototipe mengasumsikan bahwa pada awalnya beberapa

8) Dapat digunakan untuk melatih pengguna sebelum sistem final

untuk aplikasi pemrosesan data bisnis. Mereka sering digunakan

Summerville (1999) merangkum bahasa, tipe mereka, dan domain aplikasi

Tabel 2.3: Bahasa untuk prototyping cepat

Bahasa Tipe Domain Aplikasi

Boehm (1988) telah mengembangkan model spiral pengembangan

a. Proses pengembangan perangkat lunak dapat digambarkan dalam bentuk

Gambar 2.6. Model Spiral oleh Boehm

2) Mengevaluasi alternatif dan mengidentifikasi dan menyelesaikan risiko