ADAPTIVE SOFTWARE
DEVELOPMENT
 
        GROUP 3 :
•     
Annisa Maulana Majid (001201907006)
•     
Dede
Lutfi Siregar (001201907004)
•     
Rachma
Oktari (001201907023)
•     
Wilson
Sasongko Purnomo (001201907023)
Software Development Methodology
Lecturer : Rusdianto Roestam
1. Tinjauan Literatur
Agile
Value [5]
•     
Interaksi dan
personel
lebih penting dari pada proses dan alat -> People
•     
Software yang
berfungsi
lebih penting dari pada dokumentasi yang lengkap -> Product
•     
Kolaborasi
dengan klien
lebih penting dari pada negosiasi kontrak -> Communication
•     
Sikap tanggap
terhadap perubahan
lebih penting dari pada mengikuti rencana -> Responsivness
“That is, while there is value in the items on the right, we value the
items on the left more.”
Prinsip Agility
[5]
Berikut 12 prinsip agility
antara lain yaitu:
- Prioritas utama
     adalah memuaskan klien dengan
     menghasilkan perangkat lunak yang bernilai secara cepat dan rutin.
- Siap
     terhadap perubahan kebutuhan. Proses Agile
     memanfaatkan perubahan untuk keuntungan klien.
- Menghasilkan
     perangkat lunak yang bekerja secara rutin,
     dari jangka waktu beberapa minggu sampai beberapa bulan, dengan
     mengutamakan jangka waktu yang pendek.
- Rekan bisnis dan
     pengembang perangkat lunak harus bekerjasama
     sepanjang proyek.
- Lingkungan
     pengembang proyek memiliki suasana
     yang motivatif. Berikan mereka lingkungan dan dukungan yang
     dibutuhkan, dan percayai mereka untuk dapat menyelesaikan pekerjaan dengan
     baik.
- Metode yang paling
     efisien dan efektif untuk bertukar informasi dari dan dalam tim pengembang
     adalah dengan komunikasi secara
     langsung.
- Perangkat
     lunak yang bekerja adalah ukuran utama kemajuan
     suatu tim.
- Proses Agile
     mendukung pengembangan yang
     berkelanjutan dengan kecepatan pengembangan yang konsisten.
- Perhatian terhadap
     detail-detail teknis dan desain
     akan meningkatkan agility.
- Kesederhanaan
     (memaksimalkan jumlah pekerjaan yang belum dilakukan) adalah hal yang
     sangat penting.
- Self-organizing
     team mendukung arsitektur, kebutuhan, dan rancangan
     perangkat lunak yang baik.
- Secara
     berkala, tim pengembang
     berefleksi tentang bagaimana agar pengembangan lebih efektif, kemudian menyesuaikan cara bekerja mereka.
Perbedaan Agile Development dengan traditional [4]
 
 
 
 
2. Metodologi : Adaptive
Software Development [5]
Diusulkan oleh Jim Highsmith
ASD — Fitur
A.   
Perencanaan
yang digerakkan dari misi: mengevaluasi misi setiap hari
B.    
Fokus
berbasis komponen
C.    Menggunakan
"time-boxing"
D.   
Pertimbangan risiko yang eksplisit
E.    
Menekankan kolaborasi untuk pengumpulan persyaratan
F.     
Menekankan "belajar" di seluruh proses
ASD
- Value [3]
1.            
Value pertama adalah menawarkan
alternatif untuk keyakinan bahwa optimisasi
adalah satu-satunya solusi untuk masalah yang semakin kompleks. Budaya yang
optimal percaya bahwa mereka memegang kendali, dapat memaksakan ketertiban pada
ketidakpastian di sekitar mereka.
2.            
Value kedua adalah menawarkan
serangkaian kerangka kerja atau model
untuk membantu organisasi menerapkan prinsip-prinsip adaptif. Siklus Hidup
Pengembangan Adaptif, misalnya, menyediakan kerangka kerja yang memperkuat
konsep dan perincian cara praktis untuk bergerak dari konseptual yang dapat
ditindaklanjuti.
3.            
Value ketiga adalah untuk membangun kolaborasi — interaksi
orang-orang dengan minat yang sama dan terkadang berbeda, untuk bersama-sama menciptakan dan melakukan
inovasi — organisasi untuk memecahkan solusi dari masalah pengembangan
produk.
4.            
Value keempat Pengembangan Perangkat
Lunak Adaptif adalah untuk menyediakan jalur bagi organisasi yang perlu
menggunakan pendekatan adaptif pada
proyek-proyek yang lebih besar. 
5.            
Value terakhir adalah untuk menawarkan
gaya manajemen adaptif yang baru, Kepemimpinan-Kolaborasi,
untuk menggantikan Command-Control.
Kemampuan untuk beradaptasi dan bergerak cepat mengharuskan "kepemimpinan" menggantikan
"perintah" dan "kolaborasi"
menggantikan "kontrol"
Tahapan pada
model ASD, yaitu: Speculation, Collaboration, dan Learning. [5]
a.             
Pada tahap Speculation, proyek dimulai dan
adaptive cycle planning
diselenggarakan. Pada tahapan ini, didefinisikan visi dan misi pengguna terhadap sistem yang akan dibuat,
selanjutnya mendefinisikan project
constraints, misalnya: waktu deliver.
dan selanjutnya mendefinisikan satu set dari requirements yang akan dikerjakan
dalam suatu cycle.
b.            
Pada tahap Collaboration, pada tahap ini
diorganisasikan tim kerja untuk
membangun sistem. Direkomendasikan menggunakan
model Joint Application Development (JAD).  Orang-orang yang bermotivasi tinggi bekerja sama: saling melengkapi, rela
membantu, kerja keras, trampil di bidangnya, dan komunikasikan masalah untuk hasilkan penyelesaian yang efektif.
c.             
Pada tahap Learning, terdapat tiga aktifitas
yaitu: pelanggan atau end-user
menyediakan feedback terhadap hasil incremental delivery, tim ASD melakukan
review terhadap komponen perangkat
lunak untuk memperbaiki dan meningkatkan
kualitas perangkat lunak yang sedang dibuat. Learning: tim pembangun sering
merasa sudah tahu semua hal tentang proyek, padahal tidak selamanya begitu.
Karena itu proses ini membuat mereka belajar lebih
tentang proyek melalui 3 cara:
Ø  Focus group: klien dan pengguna memberi masukan
terhadap software
Ø  Formal Technique Reviews: Tim ASD lengkap melakukan
review
Ø  Postmortems: Tim ASD lakukan instrospeksi pada kinerja
dan proses
ASD – Detail [3]
a.             
Ini menggabungkan
tujuan khusus, batas-batas perilaku, dan kebebasan yang luas untuk
implementasi.
b.            
Pernyataan misi perlu difokuskan. Mencoba untuk unggul dalam beberapa dimensi
biasanya menghasilkan suatu produk yang biasa-biasa saja di dalamnya dan tidak
ada yang unggul.
c.             
Profil misi produk memaksa fokus pada area tunggal — fitur, jadwal, defect, atau sumber daya
yang harus dimiliki oleh tim pengembangan. Profil ini memberikan strategi
trade-off tingkat tinggi untuk proyek tersebut.
d.            
Pernyataan misi memfasilitasi
pengumpulan informasi yang relevan
dengan hasil yang diinginkan proyek.
e.             
Misi harus menetapkan arahan, menginspirasi para peserta, dan memberikan detail
yang cukup untuk pengambilan keputusan
yang berkelanjutan.
f.             
Komponen misi adalah visi proyek (or charter), lembar data
proyek, dan garis besar spesifikasi produk.
g.            
Membuat misi yang mudah, Menciptakan
rasa tanggung jawab bersama untuk
mencapai misi. Membangun visi dengan kerjasama yang berkelanjutan, tanpa
akhir, dan kolaboratif.
h.            
Kemampuan untuk fokus secara berkala
adalah penting. 
i.              
Visi atau charter proyek menetapkan fokus dan tema motivasi utama untuk proyek
tersebut. Ini menetapkan arah untuk membawa ke kabut yang tidak diketahui.
Ini memberikan batasan untuk fase eksplorasi dari siklus hidup
Speculate-Collaborate-Learn.
j.              
Lembar
data proyek adalah ringkasan satu halaman dari informasi utama tentang proyek.
Ini berfungsi sebagai titik fokus dan
pengingat cepat elemen paling penting tentang proyek. Ini sederhana, tetapi
kuat.
k.            
Garis besar spesifikasi produk
menjelaskan fitur-fitur produk secara
cukup rinci sehingga pengembang dapat memahami ruang lingkup upaya, membuat
rencana siklus adaptif yang lebih rinci, dan memperkirakan besarnya umum dari
upaya pengembangan.
l.              
Karakteristik
kualitas adalah bagian dari definisi misi. Pengembang
perangkat lunak sering gagal membedakan antara keunggulan dan kinerja. Mereka
juga gagal memberikan dasar untuk melakukan pertukaran yang diperlukan selama
dalam proyek.
m.          
Kualitas
ada di mata para pemegang saham. Dalam kata-kata Jerry
Weinberg, "Quality is value to some person”.
Parameter All
Method Agile [6]
 
 
  
 3. Studi kasus
Mengembangkan sistem yang kritis terhadap keselamatan
bukan hanya proses memproduksi perangkat lunak, tetapi juga memberikan bukti
bahwa perangkat lunak yang dihasilkan tidak akan menyebabkan atau berkontribusi
pada situasi berbahaya, dan proses menghasilkan bukti semacam itu harus
dilakukan bersamaan dengan proses pengembangan perangkat lunak; jadi untuk
menghasilkan perangkat lunak yang aman secara bertahap proses pembuatan bukti
juga harus dilakukan secara bertahap.
- Proses
     pengembangan keselamatan pertama-tama dimulai dengan proses identifikasi bahaya dan dalam
     proses ini semua bahaya yang terkait dengan sistem spesifik harus
     diidentifikasi dan tidak ada bahaya yang harus ditinggalkan karena
     konsekuensinya bisa sangat berbahaya.
- Proses
     kedua adalah proses penilaian
     risiko di mana masing-masing dan setiap bahaya diberikan tingkat risiko
     semakin tinggi risiko semakin berbahaya itu.
- Fase
     ketiga adalah penilaian keamanan
     sistem awal, dalam fase ini setelah
     bahaya telah diidentifikasi dan dinilai penyebab kegagalan diidentifikasi
     dan persyaratan keselamatan diminta untuk mencegah atau mengendalikan
     kemungkinan penyebab kegagalan.
- Proses
     keempat adalah analisis penyebab
     umum yang digunakan di seluruh siklus pengembangan yang digunakan untuk
     mendukung penilaian keamanan sistem awal dan penilaian keamanan sistem.
     Banyak analisis teknik keselamatan
     mengasumsikan bahwa kegagalan tidak tergantung satu sama lain, jika asumsi
     itu tidak benar dan ada fakta penyebab umum maka integritas keselamatan
     sistem akan rusak.
- Fase
     kelima yang merupakan penilaian
     keamanan sistem, setelah desain diimplementasikan, perlu untuk
     mengkonfirmasi bahwa persyaratan keselamatan yang diperoleh dari penilaian
     keamanan sistem awal telah dipenuhi, dan di sinilah proses seperti itu
     terjadi.
- Fase
     spekulasi: fase ini dibuat dari dua tahap inisiasi dan siklus perencanaan adaptif di sini persyaratan
     proyek (fungsional dan keselamatan) harus dikumpulkan secara cukup rinci
     untuk dijadikan masukan bagi rencana proyek dan arsitektur perangkat
     lunak, untuk dijadikan sebagai masukan bagi kegiatan Preliminary  System 
     Safety  Assessment  PAAS , juga proses identifikasi bahaya
     harus dilakukan dan risiko bahaya harus dinilai pada tahap ini.
- Fase
     kolaborasi: Jumlah siklus pengembangan ditentukan oleh jumlah modul yang
     dibentuk oleh dekomposisi modular. Setiap modul akan menjadi siklus
     pengembangan. Pada akhir setiap siklus modul perangkat lunak dengan bukti
     keamanannya harus dihasilkan. Kegiatan proses keselamatan yang akan
     berlangsung dalam fase ini adalah PAAS dan proses analisis sebab-akibat
     umum, tergantung pada jenis proyek yang akan digunakan, teknik analisis
     keselamatan yang paling cocok akan digunakan, hasil yang dihasilkan dari
     proses tersebut akan dimasukkan fase selanjutnya dalam model ini.
- Fase
     pembelajaran: kekuatan pada aspek teknis dan manajerial, dari masalah
     perspektif manajemen waktu, biaya dan masalah manajerial lainnya
     dipertimbangkan dan juga jika ada komplikasi yang dihadapi oleh tim selama
     fase sebelumnya. Dan mengenai tinjauan teknis, produk yang dihasilkan
     harus diuji dan argumen keselamatan ditinjau untuk memastikan bahwa
     persyaratan keselamatan untuk kenaikan ini terpenuhi, proses Analisis
     Keselamatan Sistem (SSA) dilakukan untuk memastikan hal ini, dan teknik
     yang sesuai harus digunakan tergantung pada jenis proyek, dan selama
     proses SSA argumen keselamatan untuk sistem dikembangkan sehingga pada
     saat iterasi terakhir tercapai, argumen keselamatan harus lengkap.
Examples
of safety-critical systems
A.   
Infrastructure
B.    
Medicine
The technology requirements can go beyond
avoidance of failure, and can even facilitate medical intensive care (which deals with healing
patients), and also life support
(which is for stabilizing patients). 
C.   
Nuclear
engineering
D.   
Recreation
E.    
Transport
Railway
- Railway signalling
     and control systems
- Platform
     detection to control train doors
- Automatic
     train stop
Automotive
Aviation
Spaceflight
4.            
Kesimpulan
Metode agile memiliki
banyak keuntungan, dan keunggulan ini menarik software engineers dari semua
disiplin ilmu termasuk safety domain, jika ada yang berhasil diterapkan ke
banyak domain keselamatan akan diuntungkan dari mereka.
Kerangka kerja ASD dengan
tiga tahap sangat baik untuk melakukan proses pengembangan safety critical software, karena sangat cocok untuk melaksanakan
proses keselamatan dengan proses pengembangan perangkat lunak. Gambar tersebut
menunjukkan tiga fase konseptual dari kerangka kerja, pertama fase spekulasi,
kemudian fase kolaborasi, dan akhirnya fase pembelajaran.
Dalam jurnal tersebut
diusulkan penggunaan ASD dan beberapa teknik pengembangan lainnya disatukan
untuk memfasilitasi pengembangan sistem ini dengan cara agile. Proposisi yang
diusulkan berlaku untuk dalam lingkungan non-produksi, tetapi masih tingkat
penerapan dan efektivitas proposisi harus diuji dalam lingkungan produksi
nyata.
Jelas bahwa metode yang
diperlukan dapat diterapkan pada pengembangan sistem keselamatan dan
pengurangan waktu yang diperlukan secara substansial.
5.            
Daftar
Pustaka
[1] Adil A Abdelaziz, Yaseen El-Tahir, Raheeg Osman.
(2015). Adaptive Software Development for Developing Safety Critical Software.
[2] Alnokari, M.
(2008, 09 01). Applying Adaptive Software Development (ASD) Agile
Modeling on Predictive Data Mining Applications: ASD-DM Methodology.
Retrieved 10 06, 2019, from ResearchGate: https://www.researchgate.net/publication/4376306_Applying_Adaptive_Software_Development_ASD_agile_modeling_on_predictive_data_mining_applications_ASD-DM_methodology
[3] Highsmith, J.
A. (2000). Adaptive Software Development A Collaborative Approach To
Managing Complex Systems. New York: Dorset House Publishing Co.
[4] Leau, Y.B,
Loo, W.K., Tharn, W.Y., Tan, S.F. (2012). Software development life cycle AGILE
vs traditional approach. International Conference on Information and
Network, (pp. 162-167).
[5] Pressman, R.
S. (2010). Software Engineering A Practitioner Approach, 7th ed. New
York: McGraw-Hill.
[6] Soukaina M,
Sakina E Hassan E, Abdelaziz M, Nawal S. (2017). A Comparative Study of Agile
Methods. Towards a New Model-based Method. . International Journal of
Web Application, 4.