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]

Proses FDD

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

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]

1. 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]
2. Fitur dapat diatur ke dalam pengelompokan terkait bisnis hierarkis.^[4]
3. Karena suatu fitur adalah software increment yang dapat dikirimkan oleh FDD, tim mengembangkan fitur operasional setiap dua minggu.^[4]
4. Karena fiturnya kecil, desain dan representasi kodenya lebih mudah untuk diperiksa secara efektif.^[4]
5. 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]