Adaptive Software Develpoment (ASD)

1. Pengertian Adaptive Software Development

Adaptive Software Development adalah pendekatan Extreme Programming yang
dimodifikasi, yang merupakan agile model yang paling banyak digunakan. Adaptive Software
Development (ASD) telah diusulkan oleh Jim Highsmith sebagai teknik untuk membangun
perangkat lunak dan sistem yang kompleks. Dasar-dasar filosofis ASD fokus pada kolaborasi
manusia dan pengaturan diri tim. Highsmith berpendapat bahwa pendekatan pengembangan
yang agile dan adaptif berdasarkan kolaborasi adalah "sebanyak-banyaknya sumber order
dalam interaksi kompleks sebagai disiplin dan rekayasa." Highsmith mendefinisikan siklus
hidup ASD yang terdiri dari tiga fase, spekulasi (speculation), kolaborasi (collaboration) , dan
pembelajaran (learning).

2. Siklus hidup ASD

2.1. Speculate: Initiation and Planning

Ada lima langkah umum dalam "berspekulasi" meskipun kata "langkah" agak keliru,
karena setiap langkah dapat direvisi beberapa kali selama fase inisiasi (initiation) dan
perencanaan (planning). Pertama, inisiasi proyek melibatkan pengaturan misi dan tujuan
proyek, memahami kendala, menetapkan organisasi proyek, mengidentifikasi dan
menguraikan kebutuhan, membuat perkiraan ukuran dan ruang lingkup awal, dan
mengidentifikasi risiko proyek utama. Karena kecepatan biasanya menjadi pertimbangan
utama dalam menggunakan ASD, banyak data inisiasi proyek harus dikumpulkan dalam sesi
awal JAD. Inisiasi dapat diselesaikan dalam upaya dua hingga lima hari terkonsentrasi untuk
proyek berukuran kecil hingga menengah atau memakan waktu dua atau tiga minggu untuk
proyek yang lebih besar. Selama sesi JAD, kebutuhan dikumpulkan secara cukup rinci untuk
mengidentifikasi fitur dan menetapkan kerangka objek, data, atau model arsitektur lainnya.
Selanjutnya, kotak waktu (time-box) untuk seluruh proyek ditetapkan berdasarkan
ruang lingkup, kebutuhan set fitur, perkiraan, dan ketersediaan sumber daya yang dihasilkan
dari pekerjaan inisiasi proyek. Berspekulasi tidak mengabaikan estimasi, itu hanya berarti
menerima bahwa estimasi itu lemah. Langkah ketiga adalah memutuskan jumlah iterasi dan
menetapkan kotak waktu untuk masing-masing. Untuk aplikasi kecil hingga menengah, iterasi
biasanya bervariasi dari empat hingga delapan minggu. Beberapa proyek bekerja paling baik
dengan iterasi dua minggu, sementara yang lain mungkin membutuhkan lebih dari delapan
minggu (walaupun ini jarang terjadi). Ukuran proyek keseluruhan dan tingkat ketidakpastian
adalah dua faktor yang menentukan panjang iterasi individu.
Setelah menetapkan jumlah iterasi dan jadwal untuk masing-masing, anggota tim
mengembangkan tema atau tujuan untuk masing-masing iterasi. Seperti sama pentingnya untuk
menetapkan tujuan proyek secara keseluruhan, setiap iterasi harus memiliki tema sendiri (ini
mirip dengan Sprint Goal in Scrum). Setiap iterasi memberikan serangkaian fitur yang dapat
dibuktikan ke proses tinjauan pelanggan, membuat produk terlihat oleh pelanggan. Di dalam
iterasi, "builds" menghadirkan fitur-fitur kerja ke proses integrasi harian (atau lebih sering),
menjadikan produk terlihat oleh tim pengembangan. Pengujian merupakan bagian integral dan
berkelanjutan dari pengembangan fitur — bukan aktivitas yang dilakukan pada tahap akhir.
Pengembang dan pelanggan menetapkan fitur untuk setiap iterasi. Kriteria paling
penting untuk penugasan fitur adalah bahwa setiap iterasi harus memberikan serangkaian fitur
yang visible dan tangible kepada pelanggan. Dalam proses penugasan, pelanggan memutuskan
prioritas fitur, menggunakan perkiraan fitur, risiko, dan informasi ketergantungan yang
disediakan oleh tim pengembangan. Spreadsheet adalah alat yang efektif untuk perencanaan
iterasi berbasis fitur. Pengalaman menunjukkan bahwa jenis perencanaan ini — dilakukan
sebagai tim dan bukan oleh manajer proyek — memberikan pemahaman yang lebih baik
tentang proyek daripada pendekatan berbasis tugas tradisional. Perencanaan berbasis fitur
mencerminkan keunikan masing-masing proyek.
2.2. Collaborate: Concurrent Feature Develompent
Sementara tim teknis menyediakan perangkat lunak yang berfungsi, manajer proyek
memfasilitasi kolaborasi dan kegiatan pengembangan bersamaan. Untuk proyek yang
melibatkan tim terdistribusi, berbagai mitra aliansi, dan pengetahuan yang luas, bagaimana
orang berinteraksi dan bagaimana mereka mengelola ketergantungan adalah masalah penting.
Untuk proyek yang lebih kecil di mana anggota tim bekerja dalam kedekatan fisik, kolaborasi
dapat terdiri dari obrolan informal dan papan tulis. Namun, proyek yang lebih besar
membutuhkan praktik tambahan, alat kolaborasi, dan interaksi manajer proyek. Kolaborasi,
suatu tindakan penciptaan bersama, dipupuk oleh kepercayaan dan rasa hormat. Penciptaan
bersama mencakup tim pengembangan, pelanggan, konsultan luar, dan vendor. Tim harus
berkolaborasi dalam masalah teknis, kebutuhan bisnis, dan pengambilan keputusan yang cepat.

2.3. Learn: Quality Review

Belajar menjadi semakin sulit di lingkungan di mana mantra "lakukan dengan benar
pertama kali" mendominasi dan perkembangan berlangsung secara linear (waterfall). Jika
orang terus dipaksa untuk melakukannya dengan benar, mereka tidak akan bereksperimen dan
belajar. Dalam pengembangan waterfall, setiap penyelesaian fase menghambat mundur karena
tidak boleh ada kesalahan. Belajar dari kesalahan dan eksperimen mengharuskan anggota tim
membagikan kode dan artefak yang diselesaikan sebagian lebih awal, untuk menemukan
kesalahan, belajar dari mereka, dan mengurangi jumlah total pengerjaan ulang dengan
menemukan masalah kecil sebelum menjadi masalah besar. Tim harus belajar membedakan
antara pekerjaan jelek dan pekerjaan setengah jadi. Terdapat 4 kategori umum untuk hal yang
harus dipelajari pada setiap iterasi pengembangan, yaitu kualitas hasil dari perspektif
pelanggan, kualitas hasil dari perspektif teknikal, fungsi tim penyampaian dan tim praktik
dimanfaatkan, dan status proyek. Proses pembelajaran proyek ini bisa dilakukan 3 cara yaitu
sebagai berikut :
1) Focus Group adalah klien dan pengguna memberi masukan terhadap software.
2) Formal Technique Reviews adalah tim ASD lengkap melakukan review.
3) Postmortems adalah tim ASD lakukan instrospeksi pada kinerja dan proses.

3. Karakteristik Adaptive Software Development

1) Mission driven
 Umumnya terjadi dengan tim pengembangan pada awalnya bahwa persyaratannya
kabur dan tidak pasti tetapi misi keseluruhan yang memandu tim diekspresikan dengan
benar. Pada awalnya, misi ini berfungsi sebagai batas eksplorasi yang tidak memiliki
tujuan tetap tetapi perlahan-lahan mengarahkan tim pengembangan untuk mencapai
tujuan dengan memenuhi semua persyaratan, permintaan, dan kebutuhan pasar yang
berubah. Dan fakta yang lebih menarik adalah bahwa dalam setiap siklus
pengembangan kegiatan dibenarkan terhadap misi proyek secara keseluruhan.
2) Feature based
Dalam Pengembangan Perangkat Lunak Adaptif, semua kegiatan yang dilakukan tidak
berbasis tugas melainkan didasarkan pada fitur aplikasi dan fokusnya adalah pada
pengembangan perangkat lunak yang berfungsi dan memberikan produk yang
diperlukan. Dalam setiap iterasi, persyaratan pelanggan ditambahkan ke produk sebagai
fitur baru dan yang terakhir, produk yang baik diharapkan sebagai hasilnya.
3) Iterative
Pengembangan Perangkat Lunak Adaptif didasarkan pada proses berulang. Fitur baru
ditambahkan di setiap iterasi. Ini mengikuti prinsip perubahan konstan dan evaluasi
ulang. Ini tidak benar untuk pertama kalinya melainkan mengulang pengembangan
berulang kali dengan mengambil umpan balik sebagai masukan dan mengerjakannya
dan sekali lagi menetapkan arah yang benar untuk pengembangan lebih lanjut. Jadi ini
didasarkan pada proses penambahan fitur yang berkelanjutan dengan tujuan
membangun solusi perangkat lunak yang kompleks secara berulang dan memberikan
hasil pada akhirnya.
4) Time boxed
Waktu yang terkotak-kotak dalam proses Pengembangan Perangkat Lunak Adaptif
mengacu pada tidak menggunakan tenggat waktu secara tidak benar, melainkan tentang
menetapkan waktu pengiriman tetap untuk iterasi dan proyek secara minimal dan sangat
fokus dan memaksa lingkungan kerja yang baik untuk menyelesaikan pekerjaan ketika
tingkat perubahan sangat tinggi dan lingkungan terlihat seperti tidak pasti.
5) Risk driven
Dalam Pengembangan Perangkat Lunak Adaptif, dalam setiap iterasi tantangan baru
datang dan prosesnya bertujuan untuk menyelesaikan item / aktivitas berisiko tinggi
dengan cepat. Jadi dalam hal ini, iterasi adaptif diidentifikasi dan dianalisis dengan
risiko kritis dan juga dievaluasi juga.
6) Change tolerant
 Seperti yang telah kita bahas, Pengembangan Perangkat Lunak Adaptif didasarkan pada
perubahan konstan, evaluasi ulang, dan produk yang berkembang dengan perencanaan
yang ringan dan pembelajaran berkelanjutan. Jadi proses ini mengambil perubahan
berkelanjutan sebagai keuntungan dan menyambutnya. Ia tidak membuat perubahan
sebagai masalah melainkan menganggap perubahan sebagai tantangan baru.

4. Kelebihan adaptive sotfware development

● Dirancang untuk perkembangan pesat produk perangkat lunak yang kompleks.
● Iterasi pendek membantu mencegah kesalahan fatal.
● Meninggalkan banyak kesempatan untuk menjelajahi arah yang tidak direncanakan,
memungkinkan kemunculannya.
● Mendorong transparansi tingkat tinggi antara tim pengembangan dan sponsor proyek.
● Pengguna akhir dan umpan balik mereka terintegrasi erat ke dalam proses
pengembangan, meningkatkan peluang hasil yang mereka lihat sebagai positif dan
meningkatkan keragaman pengetahuan yang tersedia untuk fase kolaborasi.
● Pengujian intens iterasi pendek mengurangi bug dan kerentanan.
● Berorientasi pada hasil. Beban tanggung jawab atas hasil yang buruk tidak dapat
dibelokkan.

5. Kekurangan adaptive software development

● Ketidakpastian lingkungan mendukung tim yang berpengalaman dengan pola pikir
adaptif.
● Rencana awal yang longgar yang hanya terdiri dari misi proyek berarti
mempertahankan fokus bisa menjadi tantangan.
● Persyaratan untuk tingkat keterlibatan pengguna yang tinggi di seluruh siklus iterasi
tidak selalu mudah untuk dipastikan.
● Pengujian intensif pada setiap iterasi meningkatkan biaya dasar.
● Perubahan yang sering terjadi pada proyek dapat mengakibatkan tingkat dokumentasi
yang rendah. Ini dapat dimitigasi secara retrospektif setelah perubahan dikunci ke
dalam produk yang berkembang.

6. Implementasi ASD
Contoh:
Pengembangan Sistem Daftar Ulang (Timeboxed 1)
1) Tahap Spekulasi (Speculation Phase)
Pada tahap spekulasi, akan dilakukan misi proyek, batasan proyek, dan kebutuhan dasar pada sistem
daftar ulang. Berikut ini adalah penjabaran dari tahap spekulasi.
2) Misi Proyek
Dalam pengembangan sistem daftar ualng, misi dari proyek ini adalah untuk membangun sistem sistem
daftar ulang yang difungsikan sebagai sarana mahasiswa agar dapat memasukkan data diri yang
dibutuhkan untuk menghitung UKT.
3) Batasan Proyek
Batasan dari proyek ini adalah mahasiswa yang dapat memasukkan data adalah mahasiswa angkatan
2018 di UIN Maulana Malik Ibrahim Malang.
4) Kebutuhan Dasar
Kebutuhan dasar pada sistem didasarkan pada pengaturan pengembangan dan penyerahan secara
berkala dengan membuat timeboxed waktu deliver. Berikut merupakan timeboxed pembangunan sistem
daftar ulang.

Berdasarkan Gambar , diketahui bahwa dalam pengembangan sistem daftar ulang terdapat 9 tahapan
pengembangan dan penyerahan. 9 tahapan tersebut adalah pengembangan halaman login, halaman
biodata diri, halaman biodata ayah, halaman biodata ibu, halaman kondisi rumah, halaman riwayat
pondok, halaman riwayat sekolah, halaman riwayat prestasi, dan halaman berkas.
5) Tahap Kolaborasi (collaboration phase)
Tahap kolaborasi dalam ASD adalah tahap tahap koordinasi pengembangan sistem. Pengembangan
sistem di tahap ini menggunakan model JAD (Joint Application Development).
6) Implementasi Joint Application Development (JAD)
Adapun tahapan model joint application development (JAD) adalah sebagai berikut.
a) Analisis Sistem Daftar Ulang
Sistem daftar ulang adalah salah satu rangkaian sistem untuk membuat sistem penentuan UKT. Pada
tahap penentuan UKT dibutuhkan data-data mahasiswa yang menjadi parameter penentuan UKT. Data
tersebut didapatkan dari mahasiswa dengan cara memasukkan data diri dan berkas ke dalam sistem
daftar ulang, sehingga dapat diolah nantinya.
b) Perancangan Sistem Daftar Ulang
Dalam perancangan sistem yang akan dibuat, dengan menggunakan UML (Unified Modeling
Language) adalah suatu metode pemodelan secara visual untuk sarana perancangan sistem berorientasi
objek.
a. Use Case

b. Activity Diagram
c. Class Diagram

d. Sequence Diagram Admin

7. Referensi:
https://binus.ac.id/malang/2022/05/metode-pada-agile-development-adaptive-software-development-
asd/

https://p2k.stekom.ac.id/ensiklopedia/Adaptive_software_development

https://www.productplan.com/glossary/adaptive-software-development/

https://www.digite.com/agile/adaptive-software-development-asd/

https://www.geeksforgeeks.org/adaptive-software-development-asd/

https://sites.google.com/a/student.unsika.ac.id/metodologi-penelitian-septian-maulana-
1141177004039/documents/adaptive-software-development-asd

https://kruschecompany.com/adaptive-software-development-asd/

http://etheses.uin-malang.ac.id/17032/1/14650088.pdf
https://www.researchgate.net/publication/360083381_An_Analysis_on_Adaptive_Software_Develop
ment_ASD_Framework

https://www.tutorialspoint.com/adaptive_software_development/adaptive_software_development_tut
orial.pdf

https://users.exa.unicen.edu.ar/catedras/agilem/cap23asd.pdf

https://www.academia.edu/190448/Applying_Adaptive_Software_Development_ASD_Agile_Modeli
ng_on_Predictive_Data_Mining_Applications_ASD_DM_Methodology

https://www.scribd.com/doc/315799807/Adaptive-Software-Development