Fase Iterasi pada GXP

Fase iterasi adalah siklus pengembangan software sering dikenal dengan fase konstruksi. Fase konstruksi adalah fase terpanjang dan menjadi fase kritis suatu proyek berhasil dikembangkan atau tidak. Fase iterasi pada GXP melakukan berbagai hal umum yang dilakukan dalam pengembangan kode software meliputi, (1) Pengembangan dan desain arsitektur solusi (2) pembuatan dan pengujian unit kode (3) penjaminan kualitas dan integrasi modul. Pada proyek GXP dapat dimungkinkan satu atau lebih iterasi.

Solusi arsitektur, pada pengembangan aplikasi yang berorientasi pada konvensional, tahapan ini dikenal juga dengan tahapan analisis dan desain system. Pada GXP, tahap ini secara formal dikenal dengan solusi arsitektur yang banyak dikenal dengan istilah spike solution. Hal ini menekankan agar tim tidak terlalu focus pada desain yang berlebihan dan langsung mengaitkan desain yang sudah ada dengan solusi teknis kode yang ada. Tujuan spike solution, menghindari kondisi demikian dengan segera menguji desain ke implementasi kode. Ini menjamin desain dikembangkan divalidasi dalam bentuk implementasi teknis.

Kondisi lingkungan dan batasan pengembangan, mendiskusikan pemilihan teknologi dan platform yang dilakukan oleh tim. Hal ini bergantung pada tiga factor, (1) Legacy system, platform yang dikembangkan sebisa mungkin dapat terintegrasi dengan system terdahulu (2) Kemampuan teknis, bagian ini meliputi berbagai hal teknis yang dipahami oleh tim yang dapat diadopsikan sebagai solusi proyek (3) Keterbatasan kondisi teknis, keterbatasan sumber daya yang memahami dan mau belajar system baru, keterbatasan anggaran perangkat lunak keras dan lunak, hingga keterbatasan operasional juga dikemukakan disini.

Kebergantungan pengembangan solusi berdasar platform klien, solusi yang dikembangkan oleh tim teknis harus secara tersurat disampaikan kepada klien. Pemilihan teknologi ini tentu berdasar pada platform yang digunakan oleh klien. Rancangan arsitektur solusi, arsitektur solusi didefinisikan sebagai suatu model yang menjelaskan bagaimana suatu model atau komponen solusi paling berintegrasi dan tersusun dalam suatu struktur dan pola yang dipahami oleh tim teknis dan klien.

Kebutuhan perangkat lunak dan perangkat keras produksi, sesuatu yang perlu dikemukakan pada saat penyusunan solusi yang diusulkan pada klien. Hal yang penting dalam hal ini menentukan perangkat keras dan lunak di sisi produksi dan sisi pengembangan. Kombinasi hardware dan software dibutuhkan antara system produksi dan system pengembangan tentu secara general.

Pengujian unit solusi, pada GXP ada teknik test first, code later yang diusulkan berdasar pada model utama dari XP. Inti dari test first design pada GXP memfokuskan bahwa pengujian aplikasi harus terencana dan sama pentingnya dengan pengkodean itu sendiri dengan mengikuti langkah (1) Memahami user stories dari aplikasi (2) menyusun arsitektur yang hendak dikembangkan (3) Memahami arsitektur solusi dan memcahnya menjadi modul terkecil (4) Membuat suatu daftar fungsi dari tiap modul (5) Mengaitkan daftar tiap modul dengan user stories (6) Menyusun tiap pengujian fungsi modul berdasar rencana iterasi yang telah dikemukakan pada fase perencanaan

Proses pembuatan kode, proses paling menantang dari sisi teknis. Pada tahap ini, kemampuan logika dan analisis tim teknis diuji dalam menyelesaikan permasalahan dengan pendekatan yang paling hemat biaya dan juga tentu optimal dari sisi performa. Hal mendasar yang harus disiapkan adalah (1) penentuan standar penulisan kode. Tim teknis harus memiliki panduan mengenai standar penulisan code. Sebagai contoh tata cara penamaan variable, metode, dan class (2) penentuan framework solusi, salah satu yang penting. Pada tahap ini, tim teknis diharapkan memiliki kesepakatan dalam pengembangan aplikasi (3) Pembagian beban kerja pengkodean, pembagian kerja menjadi sesuatu yang esensial untuk memecah konsentrasi kelelahan dalam pengkodean. Hal ini dapat dilakukan dengan mengidentifikasi user story yang dikembangkan.

Penjaminan kualitas dan integrasi modul, hal ini ditentukan oleh klien. Proses pengujian yang berakhir pada kesimpulan baik atau buruk kualitas pada GXP dikenal dengan nama User Acceptence Test. UAT disetiap iterasi menjamin beberapa hal (1) UAT dilakukan berkali – kali sehingga kualitas software lebih dapat terjamin (2) Perbaikan dan revisi solusi masih memberikan waktu sehingga dapat dilakukan terencana dan tidak terburu (3) UAT berharap memudahkan tim solusi melakukan integrasi hasil dan memonitor hasil secara lebih presisi.

Fase perencanaan pada GXP

Fase ini dimulai setelah setelah fase eksplorasi dimulai. Fase perencanaan terbagi menjadi tiga sub fase yang mengikuti implementasi Global Software Development, yaitu (1) Sub fase perencanaan yang terdapat di fase eksplorasi dinamakan dengan sub fase inception (2) Sub fase perencanaan yang terdapat di fase iterasi dinamakan dengan sub fase elaboration (3) Sub fase perencanaan yang terdapat di fase produksi dinamakan dengan sub fase constructions.

Sub face inception, tahap awal fase perencanaanyan. Sub fase ini menekankan pada kesepakatan awal antara klien dan tim untuk melakukan prioritas sebagai hal yang telah diusulkan oleh klien dalam user stories. Hal yang terpenting dalam hal ini adalah kesamaan visi terkait dengan berbagai hal akana dikembangkan dalam solusi. Kesamaan visi pada umumnya dapat terwujud melalui diskusi yang intens dan komunnikasi secara langsung antara tim dan klien.

Skala prioritas pada penyusunannya disusun berdasarkan pada masukan klien. Yang akan dikuantitatifkan pada model Low, Medium, High. Proritas High dikenal sebagai prioritas tinggi. Menekankan pada user stories dan sangat penting untuk kebutuhan solusi. Pada prioritas ini user story tidak dapat diabaikan dan diganggu gugat keberadaannya. Prioritas Medium, memfokuskan pada fitur yang menyongkong fitur pada prioritas High. Prioritas Low lebih kea rah eye candy atau sesuatu yang akan menjadi nilai tambah bila hal ini ada. Pada implementasinya, kecenderungan klien menganggap semua user story penting. Hal ini harus dihindari karena bagaimanapun user story harus diprioritaskan dan dipilih pada saat penyusunan dokumen perencanaan rilis.

Rencana rilis dan versioning, menjelaskan suatu model penyampaian software yang bersifat incremental.  Versioning didefinisikan sebagai rencana jangka panjang suatu software. Model versioning secara simbolis menjelaskan “it is a different project” sebagai contoh versi 1 dan versi 2 dapat dikatakan proyek yang berbeda. GXP mengimplementasinya dimulai dari angka 1 untuk sebuah rilis, angka 0 untuk iterasi, dan angka 1 untuk tiap penambahan, perbaikan atau perubahan user story.

Penyusunan Dokumen Rilis, isi dari dokumen antara lain (1) Ringkasan eksklusif, bagian ini berisi ringkasan solusi yang tengah dikembangkan dan waktu yang disepakati dalam pengembangan (2) Rencana rilis, bagian ini berisi daftar user story yang telah diproriatiskan (3) Rencana iterasi, bagian ini berisi daftar user story yang sudah dipisahkan dalam sekumpulan iterasi (4) Kesimpulan, berisi ringkasan kuantitatif mengenai user story yang disepakati, yang tidak dilanjutkan pengembangannya dan user story yang disinyalir masih membutuhkan analisis lebih dalam.

                Ringkasan eksklusif, diambil dari informasi yang bisa diambil dari langkah estimasi pada fase eksplorasi. Selanjutnya menentukan rencana rilis. Rencana rilis mengklarifikasi user story berdasar pada prioritas. Hal ini dapat dengan mudah dilakukan dengan memodifikasi spreadsheetuser stories kemudian melabeli prioritas berdasarkan kebutuhan.

                Penyusunan rencana iterasi, melakukan pemisahan dari rencana rilis yang sudah diurutkan kedalam tahapan-tahapan. Setiap tahapan akan dilaporkan pada klien. Dengan demikian, klien tidak perlu menunggu hingga proyek selesai. Pihak klien dapat memberi masukan sebelum semuanya terlambat, dengan beberapa tahap (1) menentukan banyak iterasi dalam sebuah rilis (2) menentukan banyakanya user stories untuk setiap iterasi (3) menyusun dokumen itersi.

                Kesimpulan pada dokumen perencanaan adalah dengan tetap menyebutkan fakta kuantitatif namun menghindari aspek dan istilah teknis karena baik kesimpulan dan ringkasan eksklusif menjadi dua bagian yang umum dibaca oleh stakeholder yang mungkin saja berlatar belakang non teknis.

                Sub fase elaboration, dilakukan pada fase iterasi. Tepat dilakukan pada saat tim sudah melakukan mock-up prototyping. Planning pada tahap ini dilakukan berdasar pada mock-up yang telah dikembangkan dan menghasilkan sebuah lembar kerja pengujian yang dikenal dengan dokumen rencana pengujian. Dokumen ini memfokuskan pada pengujian fungsional, yakni pengujian yang menilai aspek system. Pengujian lain yang meliputi aspek non-fungsional seperti keamanan, realibitas, skalabilitas, dan performa yang akan diuji bersamaan pada fase produksi aplikasi.

                Sub fase construction adalah sub fase perencanaan yang dilakukan pada tahap produksi. Pada tahap ini yang dilakukan adalah perencanaan quality assurance dan strategi deployment system dari lokasi staging ke lokasi produksi. Sesi pengujian oleh klien atau yang dikenal UAT (user acceptance test), memvalidasi 3 hal utama yaitu (1) kesesuaian struktur data yang disimpan dan dikelola oleh system (2) kesesuaian bisnis proses solusi dengan bisnis proses yang diinginkan klien (3) kesesuaian antarmuka yang diinginkan oleh klien dengan apa yang sudah dikembangkan oleh tim teknis.

Fase Eksplorasi pada GXP

Fase eksplorasi memfokuskan pada penyamaan visi antara tim dank lien, penentuan strategi pengerjaan, hingga kesepakatan kedua belah pihak bahwa hal-hal yang tercantum dalam dokumen eksplorasi adalah apa yang diinginkan oleh klien. Penekanan pada tiga hal utama yaitu (1) penentuan visi produk dan kebutuhan bisnis yang diharapkan klien (2) Identifikasi actor dan pihak-pihak yang berkepentingan terhadap produk yang akan dikembangkan (3) pemahaman terhadap proses bisnis yang akan diselesaikan dan bagaimana system menfasilitasinya.

Fase eksplorasi terbagi menjadi dua bagian yakni visi produk dan tujuan bisnis. Visi Produk dapat mendefinisikan tujuan produk dan mengungkapkan manfaat apabila produk dapat dikembangkan dengan baik. Tujuan bisnis adalah sebuah latar belakang kenapa software yang hendak dikembangkan itu dibutuhkan, meliputi (1) berbagai masalah yang hendak diselesaikan yang disusun secara prioritas (2) implikasi dan manfaat yang diharapkan apabila software berhasil dikembangkan (3) kebutuhan yang terdapat pada kondisi klien.

                User stories didefinisikan sebagai fungsi yang bermakna bagi pengguna atau yang membeli software. User stories terbagi menjadi beberapa aspek (1) Aspek pengguna, actor yang melakukan fungsi tersebut (2) Aspek fitur, aksi yang difasilitasi oleh system (3) Aspek manfaat, keluaran yang akan diberikan oleh system setelah aktor melakukan aksi (4) Aspek prioritas dari fitur yang akan dikembangkan (5) Aspek estimasi dari tim developer yang menggambarkan komplesitas suatu system.

                Estimasi proyek adalah suatu teknik pendekatan yang bertujuan untuk memperoleh rentang kompleksitas suatu proyek perangkat lunak. Estimasi terbagi menjadi 3, yaitu Estimasi A, B, dan C. Estimasi A adalah estimasi yang menggunakan kisaran cukup lebar, estimasi ini bukan sesuatu yang nyaman bagi klien. Estimasi B adalah estimasi yang menggunakan kisaran tidak terlalu lebar, estimasi ini lebih baik dari estimasi A. Estimasi C adalah estimasi yang sempurna, terjadi apabila pekerjaan yang sama dilakukan berulang-ulang dan telah dapat diprediksi dengan sempurna oleh tim pengembang.

                Estimasi harus memperhitungkan kompleksitas perangkat lunak, manajemen risiko hingga pengalaman dan kecepatan tim. Bahkan hal tak terduga seperti bencana alam, server hilang, computer crash, hingga klien yang berubah ide.

                Estimasi kompleksitas teknis, pada langkah ini coach mempersiapkan sebuah table yang akan diisi ratingnya secara bersama-sama dengan proyek manajer dan anggota tim lainnya. Pada umumnya, angka sebarannya antara 0 sampai 5. Nilai 0 berarti hal tersebut tidak terkait atau tidak berimplikasi pada efek yang disebutkan. Nilai 5 berarti hal tersebut sangat berefek pada proyek

                Estimasi Risiko Proyek, dikaitkan dengan hal non- teknis yang terkait dengan aspek manusia, karena manusia merupakan factor utama dalam keberhasilan dan kegagalan sebuah proyek. Untuk nilainya sama dengan Estimasi kompleksitas teknis.

                Estimasi Panjang Proyek, cara menetukan estimasi panjang proyek dengan menyatakan tiga kemungkinan yaitu bad case, best case, dan good case. Untuk elemen penilaian bisa dilakukan dengan kesepakatan bersama. GXP mengikuti prinsip XP yang menyarankan jam kerja berada dalam rentang 5 sampai 7 jam efektif.

                Proposal proyek, sebuah dokumen administrative yang disampaikan kepada klien secara formal. Tujuan dari proposal proyek ini membuat tim pengembang dan juga klien memahami berbagai hal yang akan dilakukan selama proyek berlangsung.

Executive Summary menjelaskan ringkasan proposal yang berisi kebutuhan bisnis dan visi proyek. Hal yang harus ditekankan adalah mengungkapkan kumpulan kebutuhan yang dibutuhkan oleh klien dan bagaimana proyek atau solusi memenuhi kebutuhan yang diharapkan.

Proposed Solution, menjelaskan rinci wujud visi proyek yang diusulkan dalam solusi yang ditawarkan, meliputi (1) batasan system arsitektur yang akan dikembangkan meliputi pilihan jenis solusi yang dikembangkan (2) Paramater fungsi dan teknis yang akan dikembangkan dalam aplikasi (3) Fungsi bisnis yang akan diselesaikan. Sehingga hasil akhirnya akan dikenal sebagai SOW (Statement Of Work) yang berisi berbagai hal yang dikerjakan dan berbagai hal yang tidak dibatasi untuk dikerjakan.

Project timeline berisi jadwal yang akan dikerjakan dalam kurun waktu yang diusulkan. Bagian ini diperoleh dari estimasi proyek. Jadwal yang ditampilkan pada umumnya adalah jadwal yang memiliki overhead yakni bad case time. Hal ini menjamin proyek dalam keadaan cukup dari sisi waktu pada saat pengajuan proyek.

Project governance, pendekatan kebijakan proyek ini berisi berbagai aspek-aspek prosedur non-teknis yang menjawab manajemen proyek seperti (1) model komunikasi yang ditawarkan antara klien dan tim pengembang (2) Prosedut dan manajemen isu. Bagian ini menjelaskan berbagai langkah yang dilakukan pada saat masalah ditemukan dalam waktu pengerjaan proyek.

Project organization, bagian ini menjelaskan tiga hal terkait dengan organization proyek yang meliputi struktur organisasi dari proyek, tanggung jawab juga peran masing-masing anggota tim, dan utusan dari stakeholder yang akan secara intens memberi masukan dan memberi saran terhadap pengembangan proyek.

Project Fee, biaya proyek meliputi tiga poin yaitu (1) pembiayaan SDM, berupa pembiayaan jasa terkait dengan pengembangan solusi (2) pembiayaan perangkat bantu, berupa biaya yang dibuthkan untuk mengakuisisi perangkat keras dan perangkat lunak yang dibutuhkan dalam pengembangan solusi (3) Pembiayaan administrasi dan transportasi, berupa biaya yang dikeluarkan untuk melakukan perjalanan dinas dan kegiatan lainnya.

Project Assumptions, sesi masukan dari tim pengembang terhadap tim klien untuk menjamin bahwa proyek yang dikembangkan dapat berjalan baik. Pada umumnya hal tersebut mengemukakan kondisi dan prasyarat bagaimana proyek berhasil, seperti (1) prasyarat kombinasi perangkat keras dan perangkat lunak yang sesuai (2) prasyarat model komunikasi yang ditekankan (3) Prasyarat keterbatasan perubahan fitur dan juga kondisi pengerjaan yang efektif. Bagian ini seperti kesimpulan pada laporan penelitian. Kesemuanya berisi penekanan terhadap berbagai kondisi dan prasyarat yang membuat proyek berhasil.

Software Crisis

Software saat ini bisa kita dapatkan dari memesan  dari situs penyedia, mendapatkan DVD dari majalah yang terdistribusi atau membeli dari pasar spesifik seperti iTunes sampai mengunduh secara legal ataupun illegal. Sekarang kita berada di era yang memiliki sisi kompleksitas kebutuhan dan ketersediaan yang berlebih (information over flood). Inilah yang menggerakkan penelitian yang terkait software crisis pada era internet.

Pada jaman sebelum ada internet. Pembengan software masih dimiliki oleh kampus dengan kartu plong atau computer 486 yang dipasangkan turbo pascal. Pada saat itu, itulah software crisis yang dikarenakan pengetahuan, aliran informasi yang terbatas, dan mahalnya harga software. Era ini mulai bergeser saat diperkenalkannya system operasi yang dikenal ddengan Windows dan Linux yang bisa terhubung ke software yang dinamakan browser Internet Explorer, Yang menjanjikan teknologi pengembangan perangkat lunak menjadi lebih maju dan effisien.

Software pada masa kini bukanlah suatu komoditas yang berada di laboratorium komputasi atau berada di perkantoran canggih semata. Software kini sudah menyentuh berbagai lini kehidupan dan menyentuh pasar baik yang bersifat vertical (perusahaan) dan horizontal (pengguna langsung)

Rekayasa perangkat lunak adalah suatu tahapan demi tahapan yang dibahas satu demi setu dan memiliki hasil dari setiap tahapannya. Mulai dari pengambilan kebutuhan, analisis, desain, pembuatan kode dan diakhiri dengan pendistribusian aplikasi. Software Development Life Cycle adalah penggambaran secara abstrak langkah apa saja yang dikerjakan untuk membuat software yang lenih terprediksi dari segi hasil dan kualitas. Kita membutuhkan SDLC saat (1) proyek dengan kerangka kerja lebih dari 1 bulan atau bahkan multiyear project (2) klien membutuhkan suatu laporan administrative selain source codes dan software (3) komposisi tim lebih dari 3 orang dan tiap orang memiliki role spesifik untuk bekerja fulltime. Kita tidak membutuhkan SDLC saat (1) mengembangkan software sederhana dengan jangka waktu kurang dari 1minggu (2) memiliki pengalaman mengembangkan software yang identic / mirip (3) mampu dan paham saat menceritakan secara sederhana mengenai proses bisnis aplikasi yang dikembangkan.

Masalah dalam pengembangan perangkat lunak mencakup masalah teknis dan non teknis. Masalah non teknis seperti (1) aspek komunikasi yang kurang baik, (2) pengelolaan sumber daya tidak mencukupi (waktu, dana, dan manusia), (3) manajemen risiko yang tidak terkendali hingga aspek kenyamanan bekerja adalah faktor-faktor kegagalan sebagian besar pengembangan perangkat lunak.

Masalah teknis seperti (1) Sisem kompleks makin banyak diusulkan dank lien makin membutuhkannya untuk kebutuhan bisnisnya, (2) Terlalu banyak teknologi yang bisa dipilih, sebenarnya itu memudahkan tetapi terkadang membuat bingung dalam memilihnya (3) Semakin banyak system yang terdistribusi dan terintegrasi (machine to machine), (4) Inisialiasi kebuuthan yang kurang baik dari klien, (5) Pengujian yang tidak mencukupi atau kurang detail.

Dalam lapisan software engineering ada tools, method, process, dan quality focus. Tools adalah perangkat bantu yang membantu pengembangan software sehingga menjadi lebih mudah dan produktif. Metode adalah sekumpulan langkah teknis yang dilakukan untuk mengembangkah perangkat lunak. Proses adalah berbagai hal yang dapat dilakukan oleh tim untuk mewujudkan suatu perangkat lunak berkualitas. Quality focus adalah keberfokusan pada kualitas bukan hanya dengan rendahnya kesalahan tetapi juga seberapa besar klien bersedia menerima software yang telah dikembangkan dengan kelebihan dan kekurangannya.