17/10/19

ADAPTIVE SOFTWARE DEVELOPMENT - GROUP 3


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:
  1. Prioritas utama adalah memuaskan klien dengan menghasilkan perangkat lunak yang bernilai secara cepat dan rutin.
  2. Siap terhadap perubahan kebutuhan. Proses Agile memanfaatkan perubahan untuk keuntungan klien.
  3. Menghasilkan perangkat lunak yang bekerja secara rutin, dari jangka waktu beberapa minggu sampai beberapa bulan, dengan mengutamakan jangka waktu yang pendek.
  4. Rekan bisnis dan pengembang perangkat lunak harus bekerjasama sepanjang proyek.
  5. Lingkungan pengembang proyek memiliki suasana yang motivatif. Berikan mereka lingkungan dan dukungan yang dibutuhkan, dan percayai mereka untuk dapat menyelesaikan pekerjaan dengan baik.
  6. Metode yang paling efisien dan efektif untuk bertukar informasi dari dan dalam tim pengembang adalah dengan komunikasi secara langsung.
  7. Perangkat lunak yang bekerja adalah ukuran utama kemajuan suatu tim.
  8. Proses Agile mendukung pengembangan yang berkelanjutan dengan kecepatan pengembangan yang konsisten.
  9. Perhatian terhadap detail-detail teknis dan desain akan meningkatkan agility.
  10. Kesederhanaan (memaksimalkan jumlah pekerjaan yang belum dilakukan) adalah hal yang sangat penting.
  11. Self-organizing team mendukung arsitektur, kebutuhan, dan rancangan perangkat lunak yang baik.
  12. 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.

di

Tidak ada komentar:

Posting Komentar

Langganan: Posting Komentar (Atom)

ADAPTIVE SOFTWARE DEVELOPMENT - GROUP 3