FEATURE DRIVEN DEVELOMENT

Nama : Muh. Abdul Syahid
NIM   : F1D015049

Feature Driven Development (FDD)

Menurut Palmer (2001), FDD adalah proses yang didesain dan dilaksanakan untuk menyajikan (deliver) hasil kerja secara berulang-ulang dalam waktu tertentu dan dapat diukur. FDD adalah pendekatan yang mengacu pembuatan sistem menggunakan metode yang mudah dimengerti dan mudah diimplementasikan, teknik problem solving, dan pelaporan yang mudah dimengerti dan dikontrol oleh stakeholders.

Pemrogram diberikan informasi yang cukup dan diberikan alat bantu yang baik untuk menyelesaikan aplikasi yang diberikan. Team leader dan manajer proyek diberikan informasi yang baik berdasarkan waktu mengenai tim dan proyek yang berjalan untuk menghindari resiko yang mungkin terjai. Pelaporan menjadi lebih mudah, tidak membebani, periodik dan akurat.

Pengguna (sposor, end user, customer) secara langsung dapat melihat bagian mereka sebagian hasil progress proyek dan memberikan umpan balik semasih dalm tahap pengembangan. Dengan hal ini diharapkan proyek dapat menghasilkan sebuah sistem yang benar-benar diinginkan oleh klien.

A. Nilai - Nilai dalam FDD

Menurut calberg, nilai-nilai utama yang terkandung dalam FDD sehingga FDD mampu memberikan nilai lebih bagi proses pengembangan software adalah:

l  Tangible result rather than Process Pride

Proses dalam FDD lebih mengutamakan memberikan nilai-nilai yang dapat diukur dari pada sederet proses yang rumit dan menghabiskan banyak tenaga dan sumber daya.

l  A system for building system is necessary

Sangat penting untuk membentuk sebuah sistem yang solid dan rapi untuk membuat sistem (software) bekerja sesuai dengan yang diharapkan.

l  Simple is better

Desain yang dibuat harus sesederhana mungkin namun mampu menggali semua requirement yang disyaratkan oleh klien.

l  Process steps should be obviously valuable to each team member

l  Good processes move to the background

B. 6 Pemeran Utama

Menurut Palmer dan Flesing (2001), Calberg, Abrahamsson dan Juhani (2002) setiap proses dalam FDD melalui orang-orang di dalamnya dan kelebihan serta kekurangan setiap orang sangat berpengaruh pada keluaran proyek, terdapat 6 pemeran utama prses FDD yaitu:

l  Project Manager berperan sebagai pemimpin adminstratif terhadap budget, orang-per-orang dan laporan pencapaian, mengopreasikan sistem proyek seta melindungi pekerja dari gangguan luar.

l  Chief Architect berperan sebagai penanggung jawab desain sistem secara keseluruhan, menjalankan workshop desain, dan mengarahkan proyek terkai kendala teknis.

l  Development Manager berperan sebagai pemimpin pengembangan dari hari-ke-hari, mengatasi konflik sumberdaya, biasanya juga dikombinasikan dengan Project Manager dan Chief Architect.

l  Chief Programmer adalah developer yang berpengalaman memimpin grup kecil dari sekumpulan developer individual.

l  Class Owner adalah developer individual yang mendesain, mengkodekan dan menguji dan mendekomentasikan fitur.

l  Domain Expert yaitu user, klien, sponsor dll. Dikenal baik oleh developer.

Selain enam pemeran utama tersebut diatas juga terdapat pemeran pembantu seperti domain, manager, release manager, language guru, bild engineer, tolsmith, dan system administrator. Selain itu juga terkadang cukup membantu adalah tester, deployer, dan technical writer.

C. 5 Proses FDD

FDD terdiri dari 5 proses berurut selama mendesain dan membangun sistem. Proses FDD yang iteratif dalam mendesain dan membangun (design and build) mendukung metode Agile dengan adaptasi yang cepat terhadap perubahan requirement dan kebutuhan bisnis.^[3]:

Gambar 5 Proses FDD

l  Build an Overall Model

Ketika fase ini dimulai, Domain Expert telah menyadari scope, konteks dan requirement dari sistem yang akan dibangun.^[1] Pembuatan dokumen requirement seperti use case atau spesifikasi fungsional ada dalam fase ini. Namun FDD tidak secaara eksplisit menggali, mencari dan mengatur requirement ini. Domain expert menyajikan apa yang disebut “walkthrough” yang mana anggota tim dan Chief Architect diinformasikan dengan deskripsi level tinggi dari sistem.^[3] Domain keseluruhan (overal domain) lebih lanjut dibagi kedalam area domain yang berbeda sedangkan walthrought yang lebih detail diberikan oleh anggota domain. Kemudian anggota tim developer bekerja dalam grup-grup kecil untuk mengerjakan project model dari domain area yang telah diterima.^[1]

l  Build a feature list

Walkthrough, object model dan dokumentasi requirement yang ada memberikan dasar yang kuat dalam membangun feature list yang komprehensif untuk sistem yang dikerjakan. Dalam daftar (list), tim menyajikan masing-masing client valued functions ke dalam sistem. Fungsi-fungsi tersebut dibagikan kepada masing-masing domain area dan masing-masing grup dari fungsi tersebut disebut sebagai major feature set. Sebagai tambahan, major feature sets kemudian dibagi lagi menjadi feature sets. Ini merepresentasikan aktifiti yang berbeda di setiap domain area. Feature list adalah yang dilihat oleh user atau sponsor untuk validitas dan kelengkapan merekan.^[3]

Feature dalam hal ini adalah langkah-langkah aktifitas bisnis, berbasis customer bukan teknologi. Bahasa yang digunakan mencakup bahasa yang dimengerti oleh customer. Nomenklatur untuk menunjukannya terdiri atas:

<aksi><hasil><obyek>

Misalnya:

<berikan><nomor akun>untuk<anggota baru>. ^[2]

l  Plan by Features

Plan by feature mencakup perncanaan pada lebel yang lebih tinggi, dimana feature set diatur sedemikian rupa sesuai dengan prioritas dan hubungannya. Prioritas ditentukan sesuai dengan kebutuhan customer yang disetujui oleh Chief Programmer.^[3] Dalam fase ini, Project Manager, Development Manager dan Chief Programmer merencanakan urutan feature-feature yang akan dikerjakan dengan demikian class owenership telah dilengkapi. ^[4]

l  Design by feature dan build by feature

Gambar Design by feture dan build by feature

Sekelompok kecil fitur diambil dari feature set dan diperlukan feature team untuk membangun fitur terpilih yang disebut sebagai class owner. Proses design by feature dan build by feature bersifat iteratif selama fitur yang dipilih tersebut diproduksi. Satu kali iterasi memerlukan waktu beberapa hari samapai 2 minggu. Proses iteratif ini mencakup beberapa tugas seperti inspeksi rancangan, pengkodean, pengujian unit, integrasi dan inspeksi kode.

D. Project Tracking Methodology

Penelusuran proyek (Project Tracking) diperlukan untuk mengetahui sejauh mana proyek telah berjalan dan mengevaluasi strategi dan kemungkinan yang akan dijalankan terkait stuasi itu. Menurut Pulla, untuk mengukur kemajuan tiap feature dalam prses FDD terdiri dari 6 milestone di setiap featurenya menggunakan ukuran prosentase, mencatat waktu feature selesai, diatur dari feature set dan feature area, direpresentasikan secara grafis kepada manajemen di level yang lebih tinggi, juga disusu tren dan grafik digunakan untuk menunjukkan kemajuan.

E. Karakteristik

Menurut Calberg, penggunaan FDD sebaiknya digunakan jika, memekerjakan 10 - 250 developer yang memiliki kemampuan teknis lebih dari rata-rata, dan jangan digunakan jika jumlah tim kurang dari 10, tim sedang berjalan menguasai pekerjaan dan jika kurang dukungan dari sistem. FDD lebih terhirarki dari pada Extreme Programming, memiliki class owenership yang terpisah-pisah, sukses jika dalam rentang jumlah developer diatas rata-rata, klien tidak dilibatkan dalam seluruh urutan proses dan menghargai developer sebagai individu manusia yang menentukan suskses atau tidaknya pengembangan.

F. Kesimpulan

Metode FDD memiliki proses dengan tingkat hirarkis yang tinggi sehingga setiap proses merupakan rangkaian tugas yang baku dan klien hanya berperan dalam sebagian proses saja tidak dalam keseluruhan proses. Fleksibilitas dan kemampuannya menghadapi perubahan masih bisa dilakukan walaupun melalui proses iteratif yang panjang karena melampau beberapa prosesdur samapi feature diberikan ke klien. Pengubahan feature hanya dapat dilakukan hanya pada proses pertama dan secara keseluruhan hanya mampu memberikan penambahan kurang dari 10%. dibandingkan dengan Extreme Programming, FDD terlalu banyak memberikan pemodelan dari pada langsung melakukan pengkodean membuat hasil akan terlihat dalam waktu yang lama, walaupun hal ini memberikan keuntungan untuk proyek dengan skala dan kerumitan lebih besar. Walaupun proses dalam FDD tidak mendukung sepenuhnya ciri-ciri dari motode agile yang ideal, namun masih tetap mampu memberikan keuntungan sebagai metode yang fokus dalam memberikan hasil nyata bagi konsumen dan tanggap akan perubahan yang mungkin terjadi dalam masa pengembangan. Dengan kerumitan yang lebih tinggi, orang-orang yang lebih banyak dan waktu yang lebih lama membuat FDD cocok diaplikasikan untuk proyek-proyek dengan sekala lebih besar.

[1] Stephen R. Palmer dan John M. Felsing, Practical Guide to Feature- Driven Development, Prentice Hall, 2001.

[2]        Reid S. Calberg, Featur Driven Development, SE470,                      www.fivesticks.com/intoo/fdd

[3] Pekka Abrahamsson and Juhani Warsta , Agile Software Development Methods Review and Analysis, Julkaisija-Utgivare-Publisher, 2002.

[4]        Amith Pulla, Feature Driven Development (FDD), a presentation, NJIT.