Feature-driven development
Feature-driven development (FDD) adalah proses pengembangan perangkat lunak yang iterative dan incremental. Kerangka kerja ini termasuk metode Agile untuk mengembangkan perangkat lunak. FDD memadukan sejumlah praktik terbaik yang diakui industri menjadi satu kesatuan yang utuh. Praktik-praktik ini didorong dari perspektif fungsionalitas (fitur) yang dihargai klien. Tujuan utamanya adalah untuk memberikan perangkat lunak yang nyata dan berfungsi berulang kali secara tepat waktu sesuai dengan prinsip di balik Agile Manifesto.[1]
Feature-driven Development (FDD) awalnya dirancang oleh Peter Coad dan rekan-rekannya[2] sebagai model proses praktis untuk rekayasa perangkat lunak berorientasi objek. Stephen Palmer dan John Felsing [3] telah memperluas dan meningkatkan pekerjaan Coad, menggambarkan proses yang agile dan adaptif yang dapat diterapkan pada proyek perangkat lunak berukuran sedang dan lebih besar.[4] Seperti pendekatan agile lainnya, FDD mengadopsi filosofi yang (1) menekankan kerja sama di antara orang-orang dalam tim FDD; (2) mengelola masalah dan kompleksitas proyek menggunakan dekomposisi berbasis fitur diikuti oleh integrasi software increment, dan (3) komunikasi detail teknis menggunakan cara verbal, grafis, dan berbasis teks. FDD menekankan kegiatan jaminan kualitas perangkat lunak (software quality assurance) dengan mendorong strategi pengembangan tambahan, penggunaan desain dan inspeksi kode, penerapan audit jaminan kualitas perangkat lunak, pengumpulan metrik, dan penggunaan pola (untuk analisis, desain, dan konstruksi).[4]
Fitur FDD sunting
Dalam konteks FDD, fitur (feature) adalah fungsi bernilai klien (client-valued) yang dapat diimplementasikan dalam dua minggu atau kurang" [Coa99]. Penekanan pada definisi fitur memberikan manfaat berikut:[4]
- Karena fitur adalah blok kecil dari fungsionalitas yang dapat disampaikan, pengguna dapat menggambarkannya dengan lebih mudah; memahami bagaimana mereka berhubungan satu sama lain dengan lebih mudah; dan meninjau ambiguitas, kesalahan, atau kelalaian dengan lebih baik.[4]
- Fitur dapat diatur ke dalam pengelompokan terkait bisnis hierarkis.[4]
- Karena suatu fitur adalah software increment yang dapat dikirimkan oleh FDD, tim mengembangkan fitur operasional setiap dua minggu.[4]
- Karena fiturnya kecil, desain dan representasi kodenya lebih mudah untuk diperiksa secara efektif.[4]
- Perencanaan (planning), penjadwalan (scheduling), dan pelacakan (tracking) proyek didorong oleh hierarki fitur, dan bukannya kumpulan tugas rekayasa perangkat lunak yang diadopsi secara sewenang-wenang.[4]
Coad dan rekan-rekannya[2] menyarankan templat berikut untuk mendefinisikan fitur: <action> the <result> <by | for | of | to> a(n) <object> <object> adalah orang, tempat, atau benda (termasuk peran, momen dalam waktu atau interval waktu, atau deskripsi seperti entri katalog).[4]
Contoh fitur untuk aplikasi e-commerce: "Tambahkan produk ke keranjang belanja", "Tampilkan spesifikasi teknis produk" , "Simpan informasi pengiriman untuk pelanggan". Kumpulan fitur mengelompokkan fitur terkait ke dalam kategori bisnis terkait dan didefinisikan[2] sebagai: <action> <-ing> a (n) <object>. Sebagai contoh: "Melakukan penjualan produk" adalah seperangkat fitur yang akan mencakup fitur-fitur yang disebutkan sebelumnya dan lainnya.[4]
Proses FDD sunting
Pendekatan FDD mendefinisikan lima kegiatan kerangka kerja "berkolaborasi"[2](dalam FDD ini disebut "proses"), yaitu mengembangkan model keseluruhan (develop an overall model), membangun daftar fitur (build a features list) , membangun rencana dengan fitur (plan by feature), mendesain dengan fitur (design by feature), dan membangun dengan fitur (build by feature)[4]
- Mengembangkan model keseluruhan (develop an overall model): Proyek FDD dimulai dengan penelusuran tingkat tinggi dari ruang lingkup sistem dan konteksnya.[4]
- Membangun daftar fitur (build a features list): Seperangkat fitur digabungkan menjadi seperangkat area subjek[4]
- Membangun rencana dengan fitur (plan by feature): Setelah daftar fitur selesai, langkah selanjutnya adalah membuat rencana pengembangan dan menetapkan kepemilikan fitur (atau kumpulan fitur) sebagai kelas untuk programmer.[4]
- Mendesain dengan fitur (design by feature): Menghasilkan paket desain (design package) untuk setiap fitur[4]
- Membangun dengan fitur (build by feature): Setelah inspeksi desain yang berhasil untuk setiap kegiatan untuk menghasilkan fitur yang telah direncanakan, pemilik kelas mengembangkan kode untuk kelas mereka. Setelah pengujian unit dan inspeksi kode yang berhasil, fitur yang lengkap (complete feature) dipromosikan ke main build[4].
FDD memberikan penekanan lebih besar pada pedoman dan teknik manajemen proyek daripada banyak metode agile lainnya. Ketika proyek tumbuh dalam ukuran dan kompleksitasnya, manajemen proyek ad hoc sering kali tidak memadai. Sangat penting bagi pengembang, manajer, dan pemangku kepentingan lainnya untuk memahami status proyek — pencapaian apa yang telah dibuat dan masalah yang dihadapi. Jika tekanan tenggat waktu signifikan, sangat penting untuk menentukan apakah software increment (fitur) dijadwalkan dengan benar. Untuk mencapai hal ini, FDD mendefinisikan enam tonggak selama desain dan implementasi fitur: "penelusuran desain (design walkthrough), desain (design), inspeksi desain (design inspection), kode (code), inspeksi kode (code inspection), promosi untuk membangun (promote to build)" [2].
- ^ "Principles behind the Agile Manifesto". Diarsipkan dari versi asli tanggal 2013-02-15.
- ^ a b c d e Coad, Peter, Auteur. (1999). Java modeling in color with UML : enterprise components and process. Prentice Hall PTR. ISBN 013011510X. OCLC 490503092.
- ^ Palmer, S., and J. Felsing, A Practical Guide to Feature Driven Development, Prentice Hall, 2002.
- ^ a b c d e f g h i j k l m n o p Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534. Diarsipkan dari versi asli tanggal 2023-07-16. Diakses tanggal 2019-07-31.