MSF – Fase Developing (Developing Phase)

it's time to build the solution

Fase selanjutnya dalam Microsoft Solutions Framework (MSF) setelah fase Planning adalah fase Developing. Dalam fase ini, solusi  dibuat sesuai dengan rencana dan rancangan yang telah ditetapkan pada fase Planning.  Sesuai dengan tuntunan MSF, maka pembuatan solusi sebaiknya dilakukan dalam sebuah lingkungan yang telah dibuat khusus untuk pembuatan solusi tersebut. Lingkungan ini disebut lingkungan pengembangan, testing dan persiapan, dimana lingkungan ini dibuat semirip mungkin dengan kondisi pada lingkungan end-user namun tetap independen terhadap lingkungan end-user. Selama fase planning lingkungan ini seharusnya sudah dibuat sehingga siap untuk dipakai dalam fase developing. Tujuannya agar selain membuat solusi, tim proyek sekaligus mempersiapkan segala infrastruktur yang diperlukan oleh solusi, dan memastikan solusi dapat berjalan di infrastruktur yang telah direncanakan.

During the developing phase, the project team creates the solution. This process includes creating the code that implements the solution and documenting the code. In addition to developing code, the team also develops the infrastructure for the solution. (~ MCSD Self-Paced Training Kit: Analyzing Requirements and Defining Microsoft .NET Solution Architectures)

Proses-proses dalam fase Developing

Secara garis besar proses-proses yang terjadi dalam fase Developing adalah:

1. Memulai siklus pemrograman dengan verifikasi kembali bahwa tugas-tugas yang terlah didefinisikan pada fase envisioning dan planning terpenuhi, yaitu:
   • Development objectives yaitu sasaran-sasaran yang harus dicapai pada proses pengembangan telah jelas dan dimengerti oleh seluruh anggota tim pengembangan (programmer)
   • Overall delivery strategy yaitu strategi yang digunakan untuk membuat dan menghasilkan solusi telah jelas, antara lain strategi yang sering digunakan adalah:
     • Staged delivery (solusi dihasilkan secara bertahap sesuai fungsional, satu fungsi selesai baru fungsi berikutnya dibuat)
     • Depth-first (solusi dihasilkan dimulai dari satu komponen terluar, kemudian komponen-komponen lain yang mendukung komponen tersebut sampai ke fitur paling dalam/detail yang merupakan cabang dari komponen itu dibuat dulu, baru kemudian mengerjakan komponen luar berikutnya)
     • Breadth-first (solusi dihasilkan dimulai dari satu komponen terluar, kemudian tanpa mengerjakan komponen-komponen dan fitur-fitur pendukungnya, mulai mengerjakan komponen luar berikutnya, setelah semua komponen permukaan selesai, baru membuat komponen-komponen pada lapisan yang lebih dalam)
     • Features then performance (solusi dihasilkan dengan semua fitur dibuat dulu tanpa memperhitungkan kinerja, baru kemudian kinerja produk diperbaiki)
   • Tradeoff approach yaitu cara-cara mengambil keputusan apabila ada yang perlu dikorbankan untuk hal lainnya, misalnya mengorbankan fitur demi jadwal atau mengorbankan fitur demi kinerja
   • Key design goals yaitu prioritas dari sasaran-sasaran sesuai desain/rancangan solusi yang dibuat telah jelas
   • Development and build environment adalah lingkungan pengembangan, testing dan persiapan yang sebelumnya telah disinggung diawal tulisan ini
   • Guidelines and standards, apakah standar (lokal ataupun internasional) dan tuntunan yang akan digunakan telah jelas dan dapat diakses/dilihat dengan mudah oleh tim pengembang
   • Versioning and source control yaitu bagaimana kebijakan versi dan source code (pemberian nama versi, nama source code, dimana penyimpanan (repository) dari source code baru maupun lama, prosedur perubahan dan backup dari source code, tools yang akan digunakan untuk mendokumentasikan dan menyimpan sejarah versi-versi, dsb) apakah telah jelas. Contoh dari kebijakan pemberian nama versi dapat dilihat pada gambar berikut, perhatikan version number nya:
     

     Penomoran Versi pada IE

     Penomoran versi pada IE diatas menunjukkan bahwa Microsoft sangat rapi dalam penomoran versinya. Maksud dari angka ini adalah versi besar 6, versi kecil 0, nomor seri build 2900, sedangkan 2180 artinya service pack 2 update 180, sedangkan xpsp_sp2_gdr.050301-1519 adalah keterangan versi (jika ingin tahu, itu adalah kombinasi dari version name, service pack number, language pack, dan hotfix update) dari Microsoft Windows XP yang menjalankannya

   • Build process yaitu kebijakan pembuatan (build) dari source code menjadi executable file (seberapa sering semua source code yang telah jadi harus di-build/compile, bagaimana aturan dan tahapnya, dsb)  apakah telah jelas dipahami oleh seluruh anggota tim pengembang
   • Components yaitu daftar komponen-komponen yang akan dibuat sesuai desain/rancangan yang ada apakah telah jelas
   • Configuration and development management tools daftar tools yang akan digunakan untuk pembuatan (contohnya: perangkat lunak untuk bahasa pemrograman yang digunakan, alat untuk testing, tools untuk dokumentasi, dll) apakah telah tersedia dan dapat diakses oleh seluruh anggota tim pengembang
   • Design patterns yaitu pola-pola atau template yang mungkin perlu digunakan oleh tim pengembang telah ada, mudah diakses dan siap digunakan oleh tim pengembang. Adanya design patterns dapat banyak mempersingkat waktu pengembangan. Bila belum memiliki design pattern maka tim pengembang nantinya boleh mengembangkan sendiri berdasarkan hal-hal yang sering diulangi atau problem-problem yang sering ditemui, untuk digunakan pada pengembangan selanjutnya atau proyek lain, contohnya:
     • Class templates untuk operasi-operasi yang sering dilakukan seperti operasi string dan lain-lain,
     • Singletons
     • Tried and true solutions untuk problem-problem yang sering ditemui,
     • Ready-to-use objects,
     • Javabeans,
     • CSS template untuk website
   • Development team training yaitu memastikan bahwa seluruh anggota tim pengembang telah terlatih dan siap untuk melaksanakan tugasnya masing-masing
   • Development team support yaitu daftar hal-hal yang dibutuhkan oleh tim pengembang sebagai penunjang kerja mereka, misalnya dukungan teknis untuk hardware yang digunakan bila rusak, dukungan ketersediaan cadangan aksesoris seperti mouse, blank cd, bahkan pasokan kopi yang terjamin pun terkadang harus diperhitungkan sebagai development team support 😀
2. Membuat prototipe aplikasi (proof-of-concept application/mock-up), prototipe ini biasanya berupa kasaran dari tampilan antar-muka, menu dan cara mengakses fungsi-fungsi (walaupun fungsi-fungsi tersebut belum ada).  Seperti kita ketahui bahwa Microsoft dalam pengembangan perangkat lunaknya biasanya memang mendahulukan tampilan yang user-friendly, ini karena dalam proses pembuatannya, prototipe dari user interface dibuat lebih dulu, setelah prototipe selesai baru pemrograman dapat dimulai berdasarkan prototipe tadi. Bila perlu prototipe harus disetujui oleh costumer/end-user. Hal ini dilakukan agar dikemudian hari tidak banyak perubahan yang harus dibuat hanya karena ketidakcocokan costumer dengan cara mengakses suatu fungsi, bayangkan berapa banyak komponen yang harus dirubah hanya karena perubahan sebuah menu penting
3. Mengembangkan komponen-komponen solusi, sesuai desain dan strategi yang telah disepakati
4. Menyusun solusi dalam perkembangan versi-versi kecil yang membentuk versi-versi besar ketika tim development telah sukses membuat fitur-fitur inti. Dalam membuat versi-versi ini tim harus berpegang pada overall delivery strategy, versioning and source control dan build process yang telah disepakati
5. Internal test yaitu dilakukan uji coba oleh tim testing dan tim developing sendiri (uji coba tidak melibatkan pihak diluar tim proyek)
   atas versi-versi yang dihasilkan, untuk menguji fungsionalitas dan fitur-fiturnya
6. Menutup fase developing dengan melengkapi seluruh fitur-fitur dan menghasilkan produk beserta dokumentasinya dan pernyataan Scope Complete dimana seluruh ruang lingkup (scope) yang disepakati sebelumnya, telah terpenuhi

Gambaran Developing Phase (~ Wikipedia)

Milestones dalam fase Developing

Dalam fase Developing seperti pada fase-fase lain, terdapat beberapa milestones yang harus dicapai, yaitu:

1. Proof-of-concept application (prototype/mock up) selesai dibuat dan divalidasi oleh tim-tim lain dan bila perlu pengguna akhir juga dituntun menggunakannya oleh tim user experience
2. Internal builds complete yaitu peluncuran versi gabungan seluruh segmen-segmen yang telah selesai dibuat menjadi versi baru dari produk, secara bertahap sesuai strategi delivery dan standar versioning. Disebut internal build karena versi yang diluncurkan ini hanya beredar di internal tim pengembang (programmer) saja. Contoh penamaan yang biasa dilakukan untuk internal builds ini (mulai dari tingkatan versi yang paling awal) adalah: nightly builds version, kemudian milestone version, lalu pre-alpha version, dan alpha version. Namun MSF mengingatkan untuk tidak sembarangan memberi nama versi dan harus ada kejelasan (dalam standar versioning) sehingga tidak terjadi kerancuan mengenai makna alpha, beta, dsb.
3. Setelah melalui beberapa internal builds akhirnya akan dicapai Scope Complete yaitu semua fitur selesai dan  seluruh ruang lingkup (fungsi dan kebutuhan) terpenuhi, dan produk siap untuk diuji coba. Walaupun versi ini sering disebut beta version, namun MSF mengingatkan untuk tidak sembarangan memberi nama versi dan harus ada kejelasan (dalam standar versioning) sehingga tidak terjadi kerancuan mengenai makna alpha, beta, dsb.

Deliverables dalam fase Developing

Fase developing menghasilkan beberapa keluaran antara lain:

• Source code dan executables (build)
• Program instalasi dan konfigurasi (installer/setup)
• Final Functional Specification yaitu dokumen Functional Specification yang telah direvisi dan tidak akan direvisi lagi
• Elemen-elemen yang mendukung kinerja produk, contohnya: readme.txt, tutorial,  recommended system requirements, user manual, dan lain lain yang bisa membantu pengguna meningkatkan kinerja produk. Contoh dari elemen-elemen ini bisa dilihat di gambar-gambar berikut ini:

Tutorial di eBay (~ pcd-innovations.com)

Windows Vista Recommended System (~ microsoft.com)

• Testing and Bug Report yaitu dokumen yang berisi keterangan internal test yang dilakukan dan laporan bug yang diterima. Dokumen ini dibuat secara periodik dimana frekuensi pembuatan dokumen ini telah disebutkan pada sub-topik Test Plan di dokumen Master Project Plan. Bentuk dokumen yang sama akan digunakan pada fase Stabilizing untuk melaporkan hasil testing dan bug pada fase itu. Misalkan fase Developing adalah 6 minggu dan Stabilizing 8 minggu, mungkin seminggu sekali dokumen ini dibuat pada fase Developing dan dua minggu sekali pada fase Stabilizing sehingga secara total dokumen ini dibuat 10 kali (6 saat Developing dan 4 kali saat Stabilizing).
  • Contoh (template) dari Testing and Bug Report ini dalam bahasa Indonesia telah saya buat, silahkan download (PDF) –> Template Testing and Bug Report

• Test Specification and Test Cases yaitu dokumen yang berisi spesifikasi uji coba dan daftar kasus-kasus untuk diuji coba. Dokumen ini akan menjadi panduan menjalani uji coba produk/solusi pada fase Stabilizing
  • Contoh (template) dari Test Specification and Test Cases ini dalam bahasa Indonesia telah saya buat, silahkan download (PDF) –> Template Test Specification and Test Cases
    

Berakhirnya fase Developing ditandai dengan pernyataan Scope Complete yaitu semua fitur selesai dan seluruh ruang lingkup (fungsi dan kebutuhan) terpenuhi dan telah diuji coba internal oleh tim pengembang (programmer).  Setelah pernyataan ini dikeluarkan maka proyek pun tiba pada fase Stabilizing