Future Drive Devlopment

Future Drive Devlopment
Abd haris kusandi(F1D016002) Dan Patriaji Ibrahim maulana(F1D016068)

1.      Sejarah Future Drive Devlopment

Feature Driven Development (FDD) adalah salah satu model Agile
FDD pertama kali diperkenalkan ke dunia pada tahun 1999 melalui buku Java Modeling In Color dengan UML, kombinasi dari proses perangkat lunak diikuti oleh perusahaan Jeff DeLuca dan konsep fitur Peter Coad. FDD pertama kali diterapkan pada proyek 15 bulan, 50 orang untuk sebuah bank besar Singapura pada tahun 1997, yang segera diikuti oleh proyek 250 orang kedua, 18 bulan. Deskripsi yang lebih substansial diterbitkan dalam buku Panduan Praktis untuk Pengembangan Berbasis-Fitur serta situs web Pengembangan Berbasis Fitur.

2.      Proses Future Drive Devlopment

a.       Develop an Overall model

Proyek perangkat lunak dimulai dengan penelusuran tingkat tinggi dari ruang lingkup sistem dan konteksnya. Selanjutnya, penelusuran domain terperinci diadakan untuk setiap area pemodelan. Model area domain digabung menjadi model keseluruhan, dan bentuk model keseluruhan disesuaikan di sepanjang jalan.

b.      Build a Features List

Pengetahuan yang dikumpulkan selama pemodelan awal digunakan untuk mengidentifikasi daftar fitur. Ini dilakukan dengan secara fungsional mendekomposisi domain menjadi area subyek. Subjek masing-masing berisi kegiatan bisnis, langkah-langkah dalam setiap kegiatan bisnis membentuk daftar fitur yang dikategorikan. Fitur dalam hal ini adalah bagian kecil dari fungsi bernilai klien yang diekspresikan dalam bentuk "<action> <result> <object>", misalnya: 'Hitung total penjualan' atau 'Validasi kata sandi pengguna'. Fitur tidak boleh lebih dari dua minggu untuk selesai, kalau tidak mereka harus dipecah menjadi potongan-potongan kecil.

c.       Plan by Feature

Setelah daftar fitur selesai, langkah selanjutnya adalah membuat rencana pengembangan. Kepemilikan kelas telah dilakukan dengan memesan dan menetapkan fitur (atau set fitur) sebagai kelas ke kepala programmer.

d.      Design by Feature

Paket desain diproduksi untuk setiap fitur. Seorang programmer kepala memilih sekelompok kecil fitur yang akan dikembangkan dalam dua minggu. Bersama-sama dengan pemilik kelas yang sesuai, programmer kepala bekerja diagram urutan rinci untuk setiap fitur dan memperbaiki model keseluruhan. Selanjutnya, kelas dan prolog metode ditulis dan akhirnya inspeksi desain diadakan

e.       Build by Feature

Setelah inspeksi desain yang berhasil, aktivitas per fitur untuk menghasilkan fungsi (fitur) bernilai klien yang lengkap sedang diproduksi. Pemilik kelas mengembangkan kode aktual untuk kelas mereka. Setelah pengujian unit dan inspeksi kode yang berhasil, fitur yang lengkap dipromosikan ke bangunan utama.

3.      Keuntungan Dan Kerugian Menggunakan Metode FDD Model

a.       Keuntungan

1)      Proses lima langkah yang sederhana memungkinkan untuk pengembangan yang lebih cepat.

2)      Memungkinkan tim yang lebih besar untuk memajukan produk dengan kesuksesan yang berkelanjutan.

3)      Memanfaatkan standar pengembangan yang telah ditentukan, sehingga tim dapat bergerak cepat.

b.      Kerugian

1)      Tidak bekerja secara efisien untuk proyek yang lebih kecil

2)      Dokumentasi yang kurang tertulis, yang dapat menyebabkan kebingungan

3)      Sangat tergantung pada pengembang atau pemrogram utama

4)      Tidak fokus pada proyek kecil

4.      MEMBANDINGKAN FDD, XP PROGRAMMING & SCRUM

a.       User centric approaches

Perangkat lunak atau setidaknya harus dirancang dan dikembangkan dengan pendekatan yang berpusat pada pengguna. Dengan pemrograman XP misalnya, Anda memerlukan partisipasi pengguna selama proses pengembangan karena kami mengembangkan dengan iterasi singkat di mana perangkat lunak yang berfungsi selalu diuji oleh pengguna.

Dalam Feature Driven Development, pengguna akhir juga terlibat dalam proses tetapi dengan cara yang berbeda, ini sebenarnya saat melaporkan. Dan di Scrum, pengguna akhir tidak benar-benar terlibat, itu adalah pemilik produk yang dilihat sebagai pengguna akhir.

b.       Meetings

Karena komunikasi itu penting, tentu saja, pertemuan penting dengan metodologi Agile. Dengan pemrograman Scrum & XP, ada pertemuan harian di mana semua anggota tim dilibatkan dan di mana mereka berbicara tentang proyek dan memutuskan bersama bagaimana proyek harus berjalan. Pertemuan-pertemuan itu secara umum cukup informal dan cepat.

Dengan FDD sangat berbeda karena secara umum informasi akan dikomunikasikan melalui dokumentasi.

c.       Project size

Ketika memilih metodologi Agile, itu semua benar-benar tergantung pada persyaratan proyek. Misalnya, untuk proyek kecil yang tidak rumit, Anda dapat dengan mudah menggunakan pemrograman XP. Sementara Scum & FDD akan direkomendasikan ketika datang ke proyek perangkat lunak yang lebih kompleks dan yang lebih besar.

5.      SKALA APLIKASI

Sangat cocok untuk aplikasi proyek skala besar dengan lebih fokus pada aktivitas desain dan pembangunan pengembangan perangkat lunak.

6.     Kesimpulan

Feature Driven Development (FDD) adalah model proses pengembangan perangkat lunak yang gesit. Ini memberikan proses yang berorientasi dan metode berulang dengan lebih fokus pada kualitas perangkat lunak. Sangat cocok untuk proyek skala besar dengan lebih fokus pada aktivitas desain dan pembangunan pengembangan perangkat lunak.

Refrensi

S. Aftab, Z. Nawaz, F. Anwer, M. S. Bashir, M. Ahmad, and M. Anwar, “Empirical Evaluation of Modified Agile Models,” vol. 9, no. 6, pp. 284–290, 2018.

Z. Nawaz, S. Aftab, and F. Anwer, “Simplified FDD Process Model,” no. September, pp. 53–59, 2017.

S. Aftab, Z. Nawaz, M. Anwar, F. Anwer, and M. S. Bashir, “Comparative Analysis of FDD and SFDD,” vol. 18, no. 1, pp. 63–70, 2018.

S. Ahmed, K. Gahyyur, and A. Razzaq, “Evaluation for Feature Driven Development Paradigm in Context of Architecture Design Augmentation and Perspective Implications,” vol. 9, no. 3, pp. 236–247, 2018.