REKAYASA PERANGKAT LUNAK

Isnandar Agus, S.Pd., M.Kom

5TI-P1

TEKNIK INFORMATIKA
FAKULTAS ILMU KOMPUTER
INSTITUT INFORMATIKA DAN BISNIS DARMAJAYA
2021
 BAB 3.AGA ILITY DAN P ROSES
Pada tahun 2001, sekelompok pengembang perangkat lunak terkenal, penulis, dan
konsultan menandatangani "Manifesto untuk Pengembangan Perangkat Lunak Agile" di
mana mereka mendukung "individu dan interaksi atas proses dan alat, perangkat lunak yang
berfungsi daripada dokumentasi yang komprehensif, kolaborasi pelanggan atas kontrak
dan menanggapi untuk mengubah lebih mengikuti sebuah rencana.”

Agile metode
yang kadangkadang disebut untuk sebagai cahaya metode atau ramping metod
tangkas pengembangan pendekatan, menghilangkan semua tapi yang paling penting kerja pro
duk dan menjaga mereka bersandar, dan menekankan suatu inkremental pengiriman strategi y
ang akan bekerja perangkat
lunak untuk para pelanggan sebagai cepat sebagai layak untuk jenis produk dan
operasional lingkungan

Kebijaksanaan konvensional dalam pengembangan perangkat

adalah bahwa yang biaya dari perubahan meningkatkan nonlinearly sebagai sebuah proyek
kemajuan. Sebuah penggunaan skenario mungkin memiliki untuk dapat dimodifikasi, daftar
fungsi dapat diperpanjang, atau spesifikasi tertulis dapat diedit. Biaya untuk melakukan
pekerjaan ini minimal, dan waktu yang dibutuhkan tidak akan mempengaruhi hasil proyek
secara negatif . Tetapi bagaimana jika kita mempercepat beberapa bulan? Tim
ini di dalam tengah dari validasi pengujian (sesuatu yang terjadi relatif terlambat di dalam p
royek), dan stakeholder yang penting adalah meminta perubahan fungsional
utama. Perubahan ini membutuhkan modifikasi pada arsitektur desain perangkat lunak,
desain dan con- struction dari tiga komponen baru, modifikasi lima komponen,
desain dari baru tes, dan sebagainya pada. Biaya meningkat dengan
cepat, dan pada waktu dan upaya
yang diperlukan untuk memastikan bahwa para perubahan yang dibuat tanpa disengaja sam
ping efek yang trivial.

Setiap tangkas software

yang ditandai dalam sebuah cara yang alamat suatu jumlah dari kunci asumsi tentang yang
mayoritas dari software proyek:
1. Ini adalah sulit untuk memprediksi di muka yang lunak persyaratan akan bertahan d
an yang akan berubah.
2. Untuk banyak jenis dari software, desain dan konstruksi yang disisipkan. Itu adalah
, kedua kegiatan harus dapat dilakukan di tandem sehingga yang desain model yang
terbukti sebagai mereka yang dibuat.
3. Analisis, desain, konstruksi
& pengujian yang tidak seperti diprediksisebagai kita mungkin suka.
3.3.1 Prinsip Kelincahan
Agile Alliance mendefinisikan 12 prinsip bagi organisasi-organisasi perangkat lunak
yang ingin untuk mencapai kelincahan.

The Agile Alliance rumah halaman berisi banyak berguna informasi

https: //www.agilealliance.or g /.
menyadari bahwa persyaratan akan berubah. Mereka sering mengirimkan peningkatan pera
ngkat lunak dan bekerja sama dengan semua pemangku kepentingan sehingga umpan balik
pada pengiriman mereka cepat dan bermakna.
Tidak setiap model proses agile berlaku karakteristik yang dijelaskan dalam bagian ini
dengan sama berat, dan beberapa model memilih untuk mengabaikan (atau di setidaknya m
engecilkan) yang penting dari satu atau lebih lincah prinsip. Namun, ini prinsip mendefinis
ikan sebuah lincah semangat yang sedang dipelihara di setiap dari dalam proses model yan
g disajikan dalam ini bab.

3.3.2 The Politics of Agile Pengembangan

Ada perdebatan yang cukup
tentang yang manfaat dan penerapan dari tangkas software pengembangan sebagai lawan u
ntuk lebih konvensional software engineering proses.

Jim Highsmith menyatakan

“Tradisional methodologists adalah sebuah sekelompok.Sebaiknya agak memproduksi
sempurna dokumentasi dari suatu kerja sistem yang memenuhi bisnis kebutuhan.”

Sebagai sebuah tandingan, ia menyatakan yang posisi dari yang tradisional software engine
ering
methodologists adalah sebuah sekelompok dari dimuliakan hacker yang sedang akan ke me
njadi di untuk sebuah heck dari sebuah kejutan ketika mereka mencoba untuk skala up mer
eka mainan dalam perusahaan software.

Scrum (nama ini berasal dari aktivitas yang terjadi selama pertandingan
rugby) adalah sangat populer tangkas software pengembangan metode yang telah dikandun
g oleh Jeff Sutherland dan tim pengembangan di awal 1990-an. Pengembangan lebih lanjut
pada Scrum metode itu dilakukan oleh Schwaber dan Beedle.

3.4.1 Tim dan Artefak Scrum

Tim Scrum adalah tim interdisipliner yang mengatur diri sendiri yang terdiri
dari pemilik produk , master Scrum, dan tim pengembangan kecil (tiga hingga enam
orang) . The artefak Scrum prinsip adalah backlog produk , yang sprint backlog , dan
kode kenaikan . Pengembangan hasil dengan melanggar proyek menjadi serangkaian
tambahan prototipe pengembangan periode 2 ke 4 minggu di panjang disebut sprint .

Product backlog adalah daftar prioritas persyaratan atau fitur produk yang memberikan
nilai bisnis bagi pelanggan. Produk yang dapat ditambahkan ke backlog.
3.4.2 Rapat Perencanaan Sprint
Setiap pengembangan tim bekerja dengan para produk pemilik dan semua pemangku
kepentingan lainnya untuk mengembangkan item dalam backlog produk.

Pemilik produk dan tim pengembangan mengurutkan item dalam backlog produk
berdasarkan pentingnya kebutuhan bisnis pemilik dan kompleksitas tugas rekayasa
perangkat lunak ( pemrograman dan pengujian) diperlukan untuk menyelesaikan masing -
masing .

Scrum master dan tim pengembang memilih item yang akan dipindahkan ke sprint
backlog. Pengembangan tim menentukan apa yang dapat disampaikan dalam selisih
tersebut dalam batasan dari waktu, kotak yang dialokasikan untuk itu
dengan para Scrum Master.

Pekerjaan akan dapat dibutuhkan untuk memberikan yang kenaikan.The pengembangan ti

m memutuskan yang peran yang diperlukan dan bagaimana mereka akan perlu untuk dapat
diisi.

3.4.3Rapat Scrum Harian

Pertemuan Scrum harian adalah 15 menit acara yang dijadwalkan pada awal setiap hari
kerja untuk memungkinkan tim anggota untuk melakukan
sinkronisasi mereka kegiatan dan membuat rencana untuk 24 jam berikutnya.

The Scrum Master dan para pengembangan tim selalu hadir dalam harian Scrum. Beberapa
tim memungkinkan para produk pemilik untuk menghadiri sesekali.
Tiga kunci pertanyaan yang ditanyakan dan dijawab oleh semua tim anggota:
 Apa yang tidak Anda lakukan sejak yang terakhir tim pertemuan?
 Apa kendala yang Anda hadapi?
 Apa yang Anda berencana untuk mencapai oleh para berikutnya tim pertemuan?
The Scrum Master mengarah pada pertemuan dan menilai para tanggapan dari masing-
masing orang. The Scrum pertemuan membantu tim untuk mengungkap potensi
masalah sedini mungkin.

3.4.4 Rapat Tinjauan Sprint

Tinjauan sprint terjadi di akhir sprint ketika tim pengembangan telah menilai kenaikan
selesai. Tinjauan sprint sering dibatasi waktu sebagai pertemuan 4 jam untuk sprint 4
minggu. Master Scrum, tim pengembangan, pemilik produk , dan pemangku
kepentingan terpilih menghadiri tinjauan ini . utama kegiatan adalah sebuah demo dari
selisih software diselesaikan selama sprint.

3.4.5 Retrospektif Sprint

Idealnya, sebelum memulai yang
lain berlari perencanaan pertemuan, yang Scrum Master akan menjadwalkan pertemuan 3
jam (untuk sprint 4 minggu) dengan tim pengembangan
disebut berlari retrospektif . Selama ini pertemuan para tim dibahas:
 Apa yang pergi baik di dalam lari
 Apa yang bisa dilakukan ditingkatkan
 Apa yang tim akan berkomitmen untuk meningkatkan di dalam berikutnya lari
Scrum Master mengarah pada pertemuan para tim untuk meningkatkan
pengembangan praktek untuk menjadi lebih efektif untuk berikutnya.

3.5.1The XP Kerangka
Pada bagian ini kami memberikan gambaran singkat tentang Extreme Programming (XP),
salah satu pendekatan yang paling banyak digunakan untuk pengembangan perangkat
lunak tangkas. Kent Beck menulis yang mani bekerja pada XP.

Perencanaan.
Kegiatan perencanaan (juga disebut permainan perencanaan ) dimulai
dengan kegiatan persyaratan yang disebut mendengarkan . Mendengarkan mengarah ke dal
am penciptaan dari sebuah set dari “cerita” (juga disebut cerita pengguna ) yang
menggambarkan output yang diperlukan, fitur, dan fungsi untuk perangkat lunak yang
akan dibangun

Pemrograman proses
Setelah itu pertama proyek rilis (juga disebut sebuah software increment) telah telah disam
paikan, para XP tim Toedjoe menghitung proyek kecepatan.

proyek kecepatan adalah yang jumlah cerita pelanggan dilaksanakan selama rilis
pertama. Kecepatan proyek kemudian dapat digunakan untuk membantu memperkirakan
tanggal pengiriman dan jadwal untuk rilis berikutnya.

Desain
Desain XP secara ketat mengikuti prinsip KIS (keep it simple). Desain fungsionalitas
tambahan (karena pengembang menganggap itu akan diperlukan nanti) tidak disarankan.
XP mendorong penggunaan kartu CRC (Bab 8) sebagai mekanisme yang efektif
untuk memikirkan perangkat lunak dalam konteks berorientasi objek. Kartu CRC (class-
responsibility- collaborator) mengidentifikasi dan mengatur kelas berorientasi objek 9 yang
relevan dengan peningkatan perangkat lunak saat ini. Kartu CRC adalah satu-satunya
karya desain pro produk teknya sebagai bagian dari yang XP proses.Desain Gagasan utama
di XP adalah bahwa desain terjadi sebelum dan sesudah pengkodean dimulai. Refactoring-
memodifikasi / mengoptimalkan tersebut kode di sebuah cara yang tidak tidak mengubah
perilaku eksternal dari perangkat lunak means desain yang terjadi terus menerus karena
sistem dibangun.

Pengkodean
Setelah cerita pengguna dikembangkan dan pekerjaan desain awal selesai, tim tidak beralih
ke kode, melainkan mengembangkan serangkaian tes unit yang akan melatih setiap cerita
yang akan disertakan dalam rilis saat ini. Setelah uji unit telah dibuat, pengembang lebih
mampu fokus pada apa yang harus dilakukan diimplementasikan untuk lulus dalam ujian.
Setelah itu kode adalah lengkap, itu bisa diuji segera, sehingga memberikan seketika umpa
n balik untuk para pengembang. Konsep kunci selama aktivitas pengkodean (dan salah satu
aspek XP yang paling banyak dibicarakan ) adalah pemrograman berpasangan. XP
merekomendasikan bahwa dua orang bekerja bersama di satu komputer untuk membuat
kode untuk sebuah cerita. Ini menyediakan mekanisme untuk real-time
masalah pemecahan (dua kepala yang sering lebih baik daripada satu) dan real-
time kualitas jaminan (yang kode tersebut Ulasan sebagai hal yang dibuat).

Pengujian
Tes unit yang dibuat harus diimplementasikan menggunakan kerangka kerja yang
memungkinkannya.Ini mendorong menerapkan suatu regresi pengujian strategi. Tes
penerimaan XP , juga disebut tes pelanggan, ditentukan oleh pelanggan dan fokus pada
fitur dan fungsionalitas sistem secara keseluruhan yang terlihat dan dapat ditinjau
oleh pelanggan.

3.5.2 Kanban
The Kanban metode adalah metodologi ramping yang menjelaskan metode
untuk memperbaiki setiap proses atau alur kerja. Kanban berfokus pada manajemen
perubahan dan penyampaian layanan. Manajemen perubahan mendefinisikan proses di
mana perubahan yang diminta diintegrasikan ke dalam sistem berbasis perangkat lunak.

Kanban berasal dari Toyota sebagai seperangkat praktik teknik industri dan diadaptasi
untuk pengembangan perangkat lunak oleh David Anderson. Kanban sendiri
bergantung pada enam praktik inti :
1. Memvisualisasikan alur kerja menggunakan sebuah Kanban papan.
The Kanban papan yang diselenggarakan dalam kolom mewakili dalam pengemban
gan tahap untuk masing-masing elemen dari perangkat lunak fungsi.
Membatasi yang jumlah dari pekerjaan di progress (WIP) pada setiap diberikan wak
tu. Pengembang yang didorong untuk menyelesaikan mereka saat
ini tugas sebelum memulai yang lain.
Halini mengurangi lead time, meningkatkan kerja berkualitas, dan meningkatkan ya
ng tim kemampuan untuk memberikan software fungsi sering ke mereka pemangku
kepentingan.

2. Mengelola alur kerja untuk mengurangi limbah dengan memahami aliran nilai saat
ini, menganalisis tempat di mana ia terhenti, mendefinisikan perubahan, dan
kemudian menerapkan itu perubahan.

3. Membuat kebijakan proses eksplisit (misalnya, menulis turun alasan Anda untuk
memilih item untuk bekerja di dan yang kriteria yang
digunakan untuk mendefinisikan “dilakukan”).

4. Berfokus pada terus menerus perbaikan dengan menciptakan umpan balik loop di
mana perubahan yang diperkenalkan berdasarkan pada proses data
yang dan yang efek dari para perubahan pada para proses yang diukur setelah satu
perubahan yang dibuat.
 5. Lakukan perubahan secara kolaboratif dan libatkan semua anggota tim dan pemang
ku kepentingan lainnya sesuai kebutuhan.

3.5.3 DevOps
DevOps dibuat oleh Patrick DeBois untuk menggabungkan Pengembangan dan
Operasi . DevOps mencoba menerapkan prinsip pengembangan yang gesit dan ramping
di seluruh rantai pasokan perangkat lunak. Pendekatan DevOps melibatkan beberapa tahap
yang berulang terus menerus sampai produk yang diinginkan ada:
 Pembangunan berkelanjutan . Software kiriman yang rusak turun dan dikembangka
n di beberapa sprint dengan para bertahap disampaikan ke para kualitas jaminan 14 a
nggota dari satu pengembangan tim untuk pengujian
 Pengujian terus
menerus . Otomatis pengujian alat 15 yang digunakan untuk bantuan tim anggota me
nguji beberapa kode bertahap pada yang sama waktu untuk memastikan mereka ada
lah bebas dari cacat sebelum ke integrasi.
 Integrasi berkelanjutan . The kode potongan dengan baru fungsi yang ditambahkan
ke dalam yang ada kode dan untuk yang run-
time lingkungan dan kemudian diperiksa untuk memastikan ada yang tidak
ada kesalahan setelah penyebaran.
 Penyebaran terus
menerus . Pada ini tahap yang terintegrasi kode yang digunakan (dipasang) ke dala
m produksi lingkungan, yang mungkin termasuk beberapa situs global yang perlu u
ntuk harus dipersiapkan untuk menerima yang baru fungsionalitas.
 Pemantauan terus
menerus . Operasi staf yang merupakan anggota dari satu mengembangkan-
ment tim bantuan untuk meningkatkan perangkat
lunak kualitas dengan pemantauan yang kinerja di dalam produksi lingkungan dan
proaktif mencari untuk kemungkinan masalah sebelum pengguna menemukan mere
ka.
DevOps meningkatkan pengalaman pelanggan dengan bereaksi cepat terhadap
perubahan kebutuhan atau keinginan mereka. Hal ini dapat meningkatkan loyalitas merek
dan meningkatkan pangsa pasar.
 BAB 4. Model Proses Direkomendasikan
Makalah oleh Rajagoplan [Raj14] mengulas kelemahan umum dari preskriptif
pendekatan siklus hidup perangkat lunak (misalnya, model air terjun) dan berisi
beberapa saran yang harus dipertimbangkan ketika mengatur pengembangan proyek
perangkat lunak modern.
1. Beresiko menggunakan model proses linier tanpa umpan balik yang cukup.
2. Tidak pernah mungkin atau tidak diinginkan untuk merencanakan pengumpulan
persyaratan besar di muka.
3. Pengumpulan persyaratan di muka mungkin tidak mengurangi biaya atau mencegah
selip waktu.
4. Manajemen proyek yang tepat merupakan bagian integral dari pengembangan
perangkat lunak.
5. Dokumen harus berkembang dengan perangkat lunak dan tidak boleh menunda
dimulainya konstruksi.
6. Libatkan pemangku kepentingan lebih awal dan sering dalam proses pembangunan.
7. Penguji harus terlibat dalam proses sebelum konstruksi perangkat lunak.
Model air terjun tidak dapat menerima perubahan yang mungkin perlu diperkenalkan
sekali pengembang mulai coding. Oleh karena itu, umpan balik pemangku kepentingan
terbatas pada permulaan dan akhir proyek. Sebagian alasannya adalah model air terjun
menunjukkan bahwa semua produk kerja analisis dan desain diselesaikan sebelum
pemrograman atau pengujian terjadi. Hal ini membuat sulit untuk beradaptasi dengan
proyek dengan persyaratan yang terus berkembang.
Salah satu godaan adalah untuk beralih ke model inkremental (Gambar 4.1) seperti
model prototyp ing atau Scrum. Model proses tambahan melibatkan pelanggan lebih
awal dan sering dan oleh karena itu mengurangi risiko menciptakan produk yang tidak
diterima oleh pelanggan.
Ada godaan untuk mendorong banyak perubahan karena pemangku kepentingan melihat
setiap prototype dan menyadari bahwa fungsi dan fitur yang sekarang mereka sadari
telah hilang. Sering pengembang tidak merencanakan evolusi prototipe dan membuat
prototipe sekali pakai.
Ingat bahwa tujuan rekayasa perangkat lunak adalah untuk mengurangi upaya yang
tidak perlu, sehingga tipe proto perlu dirancang dengan mempertimbangkan penggunaan
kembali. Model tambahan memang memberikan yang lebih baik dasar untuk
menciptakan proses yang dapat beradaptasi jika perubahan dapat dikelola dengan bijak.
Model proses tangkas sangat baik dalam mengakomodasi ketidak pastian pengetahuan
tentang kebutuhan dan masalah nyata para pemangku kepentingan. Karakteristik utama
model proses tangkas adalah:
 Prototipe yang dibuat dirancang untuk diperluas dalam peningkatan perangkat
lunak di masa mendatang.
 Pemangku kepentingan terlibat selama proses pengembangan.
 Persyaratan dokumentasi ringan, dan dokumentasi harus berkembang seiring
dengan perangkat lunak.
 Pengujian direncanakan dan dilaksanakan lebih awal.
Scrum dan Kanban memperluas karakteristik ini. Scrum terkadang dikritik karena
membutuhkan terlalu banyak pertemuan. Tapi rapat harian menyulitkan pengembang
untuk menyimpang terlalu jauh dari membangun produk yang menurut pemangku
kepentingan berguna.
Baik Scrum dan Kanban memungkinkan pengenalan persyaratan baru yang terkontrol
(cerita pengguna). Tim yang gesit memiliki desain kecil dan mungkin tidak cocok untuk
proyek membutuhkan sejumlah besar pengembang, kecuali jika proyek dapat dipartisi
menjadi kecil dan komponen yang dapat ditetapkan secara independen. Namun, model
proses tangkas menawarkan banyak hal baik fitur yang dapat dimasukkan ke dalam
model proses yang dapat disesuaikan.
keterlibatan dan dirancang untuk tim besar dan proyek besar. Tujuannya adalah untuk
membuat prototipe yang dapat diperluas setiap kali proses diulang. Pengujian awal
sangat penting. Dokumentasi berkembang dengan pembuatan setiap prototipe baru.
Model spiralnya adalah agak unik karena penilaian risiko formal dibangun dan
digunakan sebagai dasar untuk memutuskan apakah akan menginvestasikan sumber
daya yang dibutuhkan untuk membuat prototipe berikutnya. Beberapa orang
berpendapat bahwa mungkin sulit untuk mengelola proyek menggunakan model spiral,
karena lingkup proyek mungkin tidak diketahui pada awal proyek. Ini tipikal
kebanyakan model proses tambahan. Spiral adalah dasar yang baik untuk membangun
yang mudah beradaptasi model proses.
Karakteristik Model Agile :
1. Tidak cocok untuk misi atau misi berisiko tinggi besar proyek-proyek kritis.
2. Aturan minimal dan dokumentasi minimal
3. Keterlibatan penguji yang berkelanjutan
4. Mudah mengakomodasi perubahan produk
5. Sangat bergantung pada pemangku kepentingan interaksi
6. Mudah dikelola
7. Pengiriman awal solusi parsial
8. Manajemen risiko informal
9. Proses berkelanjutan bawaan perbaikan

Spiral :
1. Tidak cocok untuk proyek kecil dan berisiko rendah
2. Beberapa langkah yang diperlukan, bersama dengan dokumentasi yang dilakukan di
depan
3. Keterlibatan awal penguji (mungkin dilakukan oleh tim luar)
4. Sulit untuk mengakomodasi perubahan produk sampai prototipe selesai
5. Keterlibatan pemangku kepentingan yang berkelanjutan dalam perencanaan dan
penilaian risiko
6. Memerlukan manajemen proyek formal dan koordinasi
7. Akhir proyek tidak selalu jelas
8. Manajemen risiko yang baik
9. Perbaikan proses ditangani di akhir proyek
4.1 Definisi Persyaratan
Setiap proyek perangkat lunak dimulai dengan tim yang mencoba memahami masalah
yang akan dihadapi diselesaikan dan menentukan hasil apa yang penting bagi pemangku
kepentingan. Ini termasuk memahami kebutuhan bisnis yang memotivasi proyek dan
masalah teknis yang membatasi itu.
Persyaratan rekayasa tidak dapat diabaikan, juga tidak dapat dibiarkan berulang-ulang
sebelum melanjutkan ke konstruksi produk.
Masuk akal untuk menanyakan praktik terbaik apa yang harus diikuti untuk mencapai
hasil yang menyeluruh dan persyaratan rekayasa tangkas. Scott Ambler [Amb12]
menyarankan beberapa praktik terbaik untuk definisi persyaratan tangkas:
1. Mendorong partisipasi aktif pemangku kepentingan dengan mencocokkan
ketersediaan dan menghargai masukan mereka.
2. Gunakan model sederhana (mis., Post-it note, sketsa cepat, cerita pengguna) untuk
mengurangi hambatan partisipasi.
3. Luangkan waktu untuk menjelaskan teknik representasi kebutuhan Anda sebelum
menggunakan mereka.
4. Mengadopsi terminologi pemangku kepentingan, dan menghindari jargon teknis bila
memungkinkan.
5. Gunakan pendekatan luas-pertama untuk mendapatkan gambaran besar dari proyek
yang dilakukan sebelumnya terjebak dalam detail.
6. Izinkan tim pengembangan untuk menyempurnakan (dengan masukan pemangku
kepentingan) persyaratan merinci "tepat pada waktunya" karena cerita pengguna
dijadwalkan untuk diterapkan.
7. Perlakukan daftar fitur yang akan diimplementasikan seperti daftar prioritas, dan
implementasikan cerita pengguna yang paling penting terlebih dahulu.
8. Berkolaborasi erat dengan pemangku kepentingan Anda dan hanya
mendokumentasikan persyaratan di tingkat yang berguna untuk semua saat membuat
prototipe berikutnya.
9. Mempertanyakan perlunya memelihara model dan dokumen yang tidak akan dirujuk
untuk di masa depan.
10. Pastikan Anda memiliki dukungan manajemen untuk memastikan pemangku
kepentingan dan sumber daya ketersediaan selama definisi persyaratan.

Jika Anda bisa meminta pemangku kepentingan untuk menentukan kriteria penerimaan
untuk setiap cerita pengguna, Anda tim memulai dengan baik. Tampaknya pemangku
kepentingan perlu melihat cerita pengguna dikodekan dan dijalankan untuk mengetahui
apakah telah diimplementasikan dengan benar atau tidak. Oleh karena itu, pendefinisian
kebutuhan perlu dilakukan secara iteratif dan mencakup pengembangan prototipe untuk
tinjauan pemangku kepentingan.

4.2 Desain Arsitektur Awal

Persyaratan dapat digunakan untuk menginformasikan desain arsitektur. Menjelajahi
arsitektur sebagai prototipe dikembangkan memfasilitasi proses merinci persyaratan.
Dia yang terbaik adalah melakukan kegiatan ini secara bersamaan untuk mencapai
keseimbangan yang tepat. Ada empat elemen kunci untuk desain arsitektur tangkas:

1. Fokus pada atribut kualitas utama, dan masukkan ke dalam prototipe saat mereka
dibangun.
2. Saat merencanakan prototipe, perlu diingat bahwa produk perangkat lunak yang
sukses menggabungkan fitur yang terlihat oleh pelanggan dan infrastruktur untuk
mengaktifkannya.
3. Mengakui bahwa arsitektur tangkas memungkinkan pemeliharaan kode dan
kemampuan berevolusi jika perhatian yang cukup diberikan pada keputusan arsitektur
dan terkait masalah kualitas.
4. Terus mengelola dan menyinkronkan dependensi antara fungsional dan persyaratan
arsitektur diperlukan untuk memastikan arsitektur yang berkembang fondasi akan siap
tepat pada waktunya untuk peningkatan di masa mendatang.
4.3 Estimasi Sumber Daya
Salah satu aspek yang lebih kontroversial dalam menggunakan prototyping spiral atau
tangkas adalah memperkirakan waktu yang dibutuhkan untuk menyelesaikan sebuah
proyek ketika tidak dapat didefinisikan sepenuhnya. Penting untuk dipahami sebelum
Anda mulai apakah Anda memiliki peluang yang masuk akal pengiriman produk
perangkat lunak tepat waktu dan dengan biaya yang dapat diterima sebelum Anda setuju
untuk mengambil proyek.
metode perlu disesuaikan dengan jumlah pengembang dan jumlah cerita pengguna yang
dapat diselesaikan secara bersamaan.
1. Gunakan data historis, dan bekerja sebagai tim untuk mengembangkan perkiraan
berapa hari yang diperlukan untuk menyelesaikan setiap cerita pengguna yang diketahui
di dimulainya proyek.
2. Atur cerita pengguna secara longgar ke dalam set yang akan membentuk setiap
sprint1 direncanakan untuk menyelesaikan prototipe.
3. Jumlahkan jumlah hari untuk menyelesaikan setiap sprint untuk memberikan
perkiraan untuk durasi keseluruhan proyek.
4. Merevisi perkiraan saat persyaratan ditambahkan ke proyek atau prototype
disampaikan dan diterima oleh pemangku kepentingan.

4.4 Struktur Prototipe Pertama

Para insinyur yang bekerja di National Instruments menerbitkan kertas putih yang
menguraikan proses mereka untuk pembuatan prototipe fungsional pertama. Langkah-
langkah ini dapat diterapkan ke berbagai proyek perangkat lunak:
1. Transisi dari prototipe kertas ke desain perangkat lunak
2. Prototipe antarmuka pengguna
3. Buat prototipe virtual
4. Tambahkan input dan output ke prototipe Anda
5. Rancang algoritme Anda
6. Uji prototipe Anda
7. Prototipe dengan mempertimbangkan penyebaran
Mengacu pada tujuh langkah ini, membuat prototipe kertas untuk suatu sistem sangat
murah dan dapat dilakukan pada awal proses pengembangan. Pelanggan dan pemangku
kepentingan biasanya bukan pengembang yang berpengalaman. Pengguna nonteknis
sering dapat mengenali apa yang mereka suka atau tidak suka tentang antarmuka
pengguna dengan sangat cepat begitu mereka lihat sketsanya. Komunikasi antar
manusia seringkali dipenuhi dengan kesalahpahaman. Orang lupa memberi tahu satu
sama lain apa yang benar-benar perlu mereka ketahui atau asumsikan bahwa setiap
orang memiliki pemahaman yang sama.
Membuat antarmuka pengguna prototipe sebagai bagian dari prototipe fungsional
pertama adalah ide yang bijaksana. Banyak sistem diimplementasikan di Web atau
sebagai aplikasi seluler dan sangat bergantung pada antarmuka pengguna sentuh. Game
komputer dan aplikasi realitas virtual membutuhkan banyak komunikasi dengan
pengguna akhir untuk beroperasi dengan benar. Jika pelanggan menemukan produk
perangkat lunak mudah dipelajari dan digunakan, mereka cenderung menggunakannya.
Banyak kesalah pahaman antara pengembang dan pemangku kepentingan dapat
dikurangi dengan dimulai dengan prototipe kertas dari antarmuka pengguna. Terkadang
pemangku kepentingan perlu lihat dasar-dasar antarmuka pengguna dalam tindakan
untuk dapat menjelaskan apa yang benar-benar mereka sukai dan tidak suka tentang hal
itu. Lebih murah untuk membuang desain antarmuka pengguna awal daripada
menyelesaikan prototipe dan mencoba menempatkan antarmuka pengguna baru di
atasnya.
Membuat prototipe dengan mempertimbangkan penerapan sangat penting karena
membantu Anda untuk hindari mengambil jalan pintas yang mengarah pada pembuatan
perangkat lunak yang akan sulit dikelola masa depan. Ini tidak berarti bahwa setiap
baris kode akan sampai ke perangkat lunak akhir produk. Seperti banyak tugas kreatif,
mengembangkan prototipe bersifat iteratif. Draf dan revisi diharapkan.
Saat pengembangan prototipe terjadi, Anda harus mempertimbangkan dengan cermat
pilihan arsitektur perangkat lunak yang Anda buat. Relatif murah untuk mengubah
beberapa baris kode jika Anda menemukan kesalahan sebelum penerapan. Sangat mahal
untuk mengubah arsitektur dari aplikasi perangkat lunak setelah dirilis ke pengguna
akhir di seluruh dunia.

4.5 Evaluasi Prototipe

Pengujian dilakukan oleh pengembang saat prototipe sedang dibangun dan menjadi
bagian penting dari evaluasi prototipe. Pengujian menunjukkan bahwa komponen
prototipe beroperasi, tetapi kecil kemungkinan kasus uji akan menemukan semua cacat.
Dalam model spiral, hasil evaluasi memungkinkan para pemangku kepentingan dan
pengembang untuk menilai apakah diinginkan untuk melanjutkan pengembangan dan
membuat prototipe berikutnya.
Sebagian dari keputusan ini didasarkan pada kepuasan pengguna dan pemangku
kepentingan, dan sebagian lagi diturunkan dari penilaian risiko pembengkakan biaya
dan kegagalan untuk memberikan hasil kerja produk ketika proyek selesai. Dam dan
Siang menyarankan beberapa kiat praktik terbaik untuk mengumpulkan umpan balik
tentang prototipe Anda.
1. Berikan perancah saat meminta umpan balik prototipe.
2. Uji prototipe Anda pada orang yang tepat.
3. Ajukan pertanyaan yang tepat.
4. Bersikaplah netral saat menyajikan alternatif kepada pengguna.
5. Beradaptasi saat pengujian.
6. Izinkan pengguna untuk menyumbangkan ide.
Menyediakan perancah adalah mekanisme yang memungkinkan pengguna untuk
menawarkan umpan balik yang tidak konfrontatif. Pengguna sering enggan memberi
tahu pengembang bahwa mereka membenci produk yang mereka gunakan.
Mendapatkan orang yang tepat untuk mengevaluasi prototipe sangat penting untuk
mengurangi risiko mengembangkan produk yang salah. Memiliki anggota tim
pengembangan melakukan semua pengujian tidak bijaksana karena mereka tidak
mungkin mewakili pengguna yang dituju populasi. Sangat penting untuk memiliki
campuran pengguna yang tepat (mis., pemula, tipikal, dan lanjutan) untuk memberi
Anda umpan balik tentang prototipe.
Mengajukan pertanyaan yang tepat menyiratkan bahwa semua pemangku kepentingan
menyetujui tujuan prototipe. Sebagai pengembang, penting untuk tetap berpikiran
terbuka dan melakukan yang terbaik untuk meyakinkan pengguna bahwa umpan balik
mereka berharga. Umpan balik mendorong pembuatan prototype proses saat Anda
merencanakan kegiatan pengembangan produk di masa depan. Selain umum umpan
balik, coba ajukan pertanyaan spesifik tentang fitur baru apa pun yang disertakan dalam
prototipe.

4.6 Keputusan Pergi, Tidak Pergi

Sirkuit pertama di sekitar spiral dapat digunakan untuk memperkuat persyaratan proyek.
Tapi itu benar-benar harus lebih. Di dalam metode yang kami usulkan di sini, setiap
perjalanan di sekitar spiral mengembangkan makna peningkatan produk perangkat
lunak akhir. Anda dapat bekerja dengan cerita pengguna proyek atau backlog fitur untuk
mengidentifikasi subset penting dari produk akhir untuk disertakan dalam prototipe
pertama dan ulangi ini untuk setiap prototipe berikutnya.
Setelah melewati wilayah perencanaan mengikuti proses evaluasi. Biaya revisi
perkiraan dan perubahan jadwal diusulkan berdasarkan apa yang ditemukan ketika
mengevaluasi prototipe perangkat lunak saat ini. Ini mungkin melibatkan penambahan
cerita pengguna baru atau fitur ke backlog proyek saat prototipe dievaluasi. Risiko
melebihi anggaran dan kehilangan tanggal pengiriman proyek dinilai dengan
membandingkan biaya baru dan perkiraan waktu terhadap yang lama. Risiko gagal
memenuhi harapan pengguna adalah juga dipertimbangkan dan didiskusikan dengan
para pemangku kepentingan dan terkadang manajemen senior sebelum memutuskan
untuk membuat prototipe lain.
Tujuan dari proses penilaian risiko adalah untuk mendapatkan komitmen dari semua
pemangku kepentingan dan manajemen perusahaan untuk menyediakan sumber daya
yang dibutuhkan untuk menciptakan prototipe berikutnya.

4.7 Evolusi Prototipe

Setelah prototipe telah dikembangkan dan ditinjau oleh tim pengembangan dan
pemangku kepentingan lainnya, saatnya untuk mempertimbangkan pengembangan
prototipe berikutnya. langkah pertama adalah mengumpulkan semua umpan balik dan
data dari evaluasi prototipe saat ini. Pengembang dan pemangku kepentingan kemudian
memulai negosiasi untuk merencanakan pembuatan prototipe lain. Setelah fitur yang
diinginkan untuk prototipe baru telah disetujui atas, pertimbangan diberikan untuk
setiap kendala waktu dan anggaran yang diketahui serta kelayakan teknis implementasi
prototipe. Jika risiko pengembangan adalah dianggap dapat diterima, pekerjaan
dilanjutkan.
Model proses prototyping evolusioner digunakan untuk mengakomodasi perubahan
yang pasti terjadi saat perangkat lunak dikembangkan. Setiap prototipe harus dirancang
untuk memungkinkan untuk perubahan di masa mendatang untuk menghindari
membuangnya dan membuat prototipe berikutnya dari menggores. Ini menyarankan
untuk menyukai fitur yang dipahami dengan baik dan penting ketika menetapkan tujuan
untuk setiap prototipe. Seperti biasa, kebutuhan pelanggan harus diberikan sangat
penting dalam proses ini.
4.7.1 Lingkup Prototipe Baru
Proses penentuan ruang lingkup prototipe baru seperti proses menentukan ruang lingkup
prototipe awal. Pengembang akan: (1) memilih fitur untuk dikembangkan dalam waktu
yang dialokasikan untuk sprint, atau (2) mengalokasikan cukup waktu untuk
mengimplementasikan fitur yang diperlukan untuk memenuhi tujuan yang ditetapkan
oleh pengembang dengan masukan pemangku kepentingan. Pendekatan mana pun
mengharuskan pengembang untuk mempertahankan daftar fitur atau cerita pengguna
yang diprioritaskan. Prioritas yang digunakan untuk mengurutkan daftar harus
ditentukan oleh tujuan yang ditetapkan untuk prototipe oleh pemangku kepentingan dan
pengembang.
4.7.2 Membangun Prototipe Baru
Kisah pengguna harus berisi deskripsi tentang bagaimana pelanggan berencana untuk
berinteraksi dengan sistem untuk mencapai tujuan tertentu dan deskripsi tentang apa
yang pelanggan pengertian penerimaan adalah. Tugas tim pengembangan adalah
membuat tambahan komponen perangkat lunak untuk mengimplementasikan cerita
pengguna yang dipilih untuk dimasukkan dalam yang baru prototipe bersama dengan
kasus uji yang diperlukan. Pengembang perlu melanjutkan komunikasi dengan semua
pemangku kepentingan saat mereka membuat prototipe baru.
4.7.3 Menguji Prototipe Baru
Menguji prototipe baru harus relatif mudah jika tim pengembangan membuat kasus uji
sebagai bagian dari proses desain sebelum pemrograman selesai. Setiap cerita pengguna
seharusnya memiliki kriteria penerimaan yang melekat padanya seperti itu dibuat.
Pernyataan penerimaan ini harus memandu pembuatan kasus uji dimaksudkan untuk
membantu memverifikasi bahwa prototipe memenuhi kebutuhan pelanggan. Prototipe
akan perlu diuji untuk cacat dan masalah kinerja juga.
Satu perhatian pengujian tambahan untuk prototipe evolusioner adalah untuk
memastikan bahwa penambahan fitur baru tidak secara tidak sengaja merusak fitur yang
berfungsi dengan benar di prototipe sebelumnya. Pengujian regresi adalah proses
memverifikasi perangkat lunak yang sebelumnya dikembangkan dan diuji masih
melakukan cara yang sama setelah itu berubah. Penting untuk menggunakan waktu
pengujian Anda dengan bijak dan memanfaatkan kasus uji yang dirancang untuk
mendeteksi cacat pada komponen yang paling mungkin terpengaruh oleh fitur-fitur
baru.

4.8 Rilis Prototipe

Ketika proses prototyping evolusioner diterapkan, mungkin sulit bagi pengembang
untuk mengetahui kapan suatu produk selesai dan siap untuk dirilis ke pelanggan.
Pengembang perangkat lunak tidak ingin merilis produk perangkat lunak buggy ke
pengguna akhir dan memilikinya memutuskan perangkat lunak memiliki kualitas yang
buruk. Sebuah prototipe sedang dipertimbangkan sebagai kandidat rilis harus dikenakan
pengujian penerimaan pengguna selain fungsional dan nonfungsional (kinerja)
pengujian yang akan dilakukan selama konstruksi prototipe.
Saat menguji kandidat rilis, tes fungsional dan nonfungsional harus diulang
menggunakan kasus uji yang dikembangkan selama fase konstruksi prototipe
inkremental. Tes nonfungsional tambahan harus dibuat untuk memverifikasi bahwa
kinerja prototipe konsisten dengan tolok ukur yang disepakati untuk produk akhir.
Tolak ukur kinerja tipikal mungkin berhubungan dengan respons system waktu,
kapasitas data, atau kegunaan. Salah satu persyaratan nonfungsional yang paling
penting untuk memverifikasi adalah memastikan bahwa kandidat rilis akan berjalan di
semua lingkungan run-time yang direncanakan dan di semua perangkat yang
ditargetkan. Prosesnya harus difokuskan pada pengujian terbatas dengan kriteria
penerimaan yang ditetapkan sebelum prototipe dibuat. Pengujian tidak bias
membuktikan produk perangkat lunak bebas bug, hanya saja kasus uji berjalan dengan
benar.
Umpan balik pengguna selama pengujian penerimaan harus diatur oleh fungsi yang
terlihat oleh pengguna seperti yang digambarkan melalui antarmuka pengguna.
Pengembang harus memeriksa perangkat di pertanyaan dan buat perubahan pada layar
antarmuka pengguna jika menerapkan perubahan ini tidak akan menunda rilis prototipe.
Jika perubahan dibuat, mereka harus diverifikasi dalam pengujian putaran kedua
sebelum melanjutkan. Anda seharusnya tidak merencanakan lebih banyak dari dua
iterasi pengujian penerimaan pengguna.

4.9 Rilis Pemeliharaan Perangkat Lunak

Pemeliharaan didefinisikan sebagai kegiatan yang diperlukan untuk menjaga perangkat
lunak tetap beroperasi setelah telah diterima dan disampaikan (dirilis) di lingkungan
pengguna akhir. Pemeliharaan akan berlanjut selama masa pakai produk perangkat
lunak. Beberapa insinyur perangkat lunak percaya bahwa sebagian besar uang yang
dihabiskan untuk produk perangkat lunak akan dihabiskan untuk kegiatan pemeliharaan.
Pemeliharaan korektif adalah modifikasi reaktif perangkat lunak untuk memperbaiki
masalah.
Pemeliharaan Adaptif adalah modifikasi reaktif perangkat lunak setelah pengiriman
untuk menjaga perangkat lunak dapat digunakan dalam lingkungan pengguna akhir
yang berubah. Pemeliharaan sempurna adalah proaktif modifikasi perangkat lunak
setelah pengiriman untuk menyediakan fitur pengguna baru, program yang lebih baik
struktur kode, atau dokumentasi yang ditingkatkan. Pemeliharaan preventif adalah
proaktif modifikasi perangkat lunak setelah pengiriman untuk mendeteksi dan
memperbaiki kesalahan produk sebelumnya mereka ditemukan oleh pengguna di
lapangan.
Penting untuk memahami kode program sebelum melakukan perubahan. Jika
pengembang telah mendokumentasikan kode, akan lebih mudah untuk memahami jika
orang lain perlu melakukan pekerjaan pemeliharaan. Jika perangkat lunak dirancang
untuk diperpanjang, pemeliharaan utama juga dapat dilakukan dengan lebih mudah,
selain perbaikan cacat darurat.

4.10 Ringkasan
Setiap proyek adalah unik, dan setiap tim pengembangan terdiri dari individu-individu
yang unik. Setiap proyek perangkat lunak membutuhkan peta jalan, dan proses
pengembangan perangkat lunak membutuhkan serangkaian tugas dasar yang dapat
diprediksi (komunikasi, perencanaan, pemodelan, konstruksi, dan penyebaran). Namun,
tugas-tugas ini tidak boleh dilakukan secara terpisah dan mungkin perlu disesuaikan
untuk memenuhi kebutuhan setiap proyek baru. Dalam bab ini, kita menyarankan
penggunaan proses prototyping inkremental yang sangat interaktif.
Membatasi persyaratan artefak rekayasa ke set minimal berguna dokumen dan model
memungkinkan produksi awal prototipe dan kasus uji. Merencanakan untuk membuat
prototipe evolusioner mengurangi waktu yang hilang untuk mengulangi pekerjaan yang
diperlukan untuk membuat prototipe sekali pakai. Memanfaatkan prototipe kertas di
awal desain proses juga dapat membantu menghindari produk pemrograman yang tidak
memuaskan harapan pelanggan. Mendapatkan desain arsitektur yang tepat sebelum
memulai pengembangan sebenarnya juga penting untuk menghindari selip jadwal dan
pembengkakan biaya.
Perencanaan itu penting tetapi harus dilakukan dengan cepat untuk menghindari
penundaan awal pembangunan. Pengembang harus memiliki gambaran umum tentang
berapa lama proyek akan menyelesaikannya, tetapi mereka perlu menyadari bahwa
mereka tidak mungkin mengetahui semua persyaratan proyek sampai produk perangkat
lunak dikirimkan. Pengembang akan bijaksana untuk menghindari perencanaan rinci
yang melampaui perencanaan prototipe saat ini.
Pengembang dan pemangku kepentingan harus mengadopsi proses untuk menambahkan
fitur agar diimplementasikan dalam prototipe masa depan dan untuk menilai dampak
dari perubahan ini pada jadwal dan anggaran proyek.
Penilaian risiko dan pengujian penerimaan adalah bagian penting dari prototype proses
penilaian. Memiliki filosofi tangkas tentang mengelola persyaratan dan menambahkan
fitur baru ke produk akhir juga penting. Tantangan terbesar pengembang dengan model
proses evolusi mengelola ruang lingkup creep sementara memberikan produk yang
memenuhi harapan pelanggan dan melakukan semua ini sambil mengirimkan produk
tepat waktu dan sesuai anggaran. Itulah yang membuat rekayasa perangkat lunak sangat
menantang dan bermanfaat.
 Soal dan Jawaban :

1. Berikut ini yang bukan proses yang harus terpenuhi dalam pengembangan
software dengan menggunakan Waterfall adalah ?
a. Setiap fase membutuhkan dokumentasi yang tepat
b. Jumlah sumber daya yang dibutuhkan minimal
c. Setiap fase selesai dalam periode waktu tertentu, setelah itu pindah ke fase
berikutnya
d. Pelanggan dapat diyakinkan dengan sampel cara aplikasi sebelum
pengembangan tercapai*

2. Metodologi Pengembangan Perangkat Lunak dikenal juga dengan istilah berikut,

kecuali ?
a. System Development Methodology
b. Software Development Process
c. Software Model*
d. Software Development Lifecycle

3. serangkaian tindakan yang direncanakan dan dilaksanakan oleh sekelompok

orang untuk mencapai tujuan, dibatasi oleh tenggat waktu, dan memiliki biaya
tertentu. Pernyataan tersebut merupakan pengertian dari ?
a. Proyek*
b. Proses Pengembangan Perangkat Lunak
c. Metodelogi Pengembagan Perangkat Lunak*
d. Manajemen Proyek

4. Berikut pernyataan yang benar terkait dengan Agile Metodologies, kecuali ?

a. Merupakan jenis atau kelompok iterative model*
b. Setiap aspek pengembangan (requirements, design, …) secara terus-menerus
ditinjau kembali sepanjang siklus hidup pengembangan Software
c. Menggunakan Pendekatan inspeksi dan adaptasi
d. Memungkinkan ternjadinya perubahan arah saat proyek sedang berjalan

5. Berikut pernyataan yang benar terkait dengan Agile Metodologies, kecuali ?

a. Menggunakan Pendekatan inspeksi dan adaptasi
b. Merupakan gabungan incremental dan iterative model
c. Setiap aspek pengembangan (requirements, design, …) secara terus-menerus
ditinjau kembali sepanjang siklus hidup pengembangan Software
d. Merupakan jenis atau kelompok iterative model*
6. Dalam metode pengembangan SCRUM, Siapakah orang yang bertanggung
jawab untuk memberikan hasil yang diharapkan dan mengetahui cara
menyelesaikan sesuatu ?
a. Stakeholders
b. Setiap aspek pengembangan (requirements, design, …) secara terus-menerus
ditinjau kembali sepanjang siklus hidup pengembangan Software
c. Product Owner
d. Scrum Master*

7. Berikut ini merupakan urutan yang tepat dari kegiatan umum dalam proses
pengembangan perangkat lunak ?
a. Software : Specification -> Design -> Development -> Evolution ->
Validation
b. Software : Specification -> Design -> Development -> Validation ->
Evolution*
c. Software : Design -> Specification -> Development -> Evolution ->Validation
d. Software : Specification -> Design -> Development -> Evolution ->Validation

8. Manakah diantara beikut ini yang bukan merupakan Software Development

Methodologies ?
a. Agile
b. Iterative Model*
c. V-Model
d. Prototyping

9. Berikut ini adalah pernyataan yang benar terkait dengan Waterfall, kecuali?
a. Hanya mensimulasikan beberapa aspek dari produk akhir*
b. Persyaratan Harus jelas sebelum langkah berikutnya dilaksankan
c. Merupakan salah satu dari Linear Model
d. Periode waktu didefinisikan untuk setiap langkah

10. kerangka kerja manajemen proyek tangkas ringan yang terutama digunakan
untuk pengembangan perangkat lunak adalah ?
a. Scrum*
b. Serum
c. strum
d. Screm