Pengertian Rekayasa Perangkat Lunak (RPL)

Rekayasa Perangkat Lunak (RPL, atau dalam bahasa Inggris: Software Engineering atau SE) adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembanganan perangkat lunak dan manajemen kualitas.

IEEE Computer Society mendefinisikan rekayasa perangkat lunak sebagai penerapan suatu pendekatan yang sistematis, disiplin dan terkuantifikasi atas pengembangan, penggunaan dan pemeliharaan perangkat lunak, serta studi atas pendekatan-pendekatan ini, yaitu penerapan pendekatan engineering atas perangkat lunak.

Perencanaan Proyek RPL

Tulisan ini berisi beberapa hal yang perlu dikuasai oleh seorang Project Manager untuk dapat menyusun suatu rencana proyek rekayasa perangkat lunak. Tulisan ini juga dilengkapi dengan contoh-contoh dokumen dalam perencanaan proyek rekayasa perangkat lunak.

Latar Belakang

Proyek Software adalah manajemen proyek yang berfokus hanya pada membuat dan mengupdate software. Sifat manajemen proyek haruslah seperti berikut ini:

-          Menyeselsaikan masalah,

-          Mengerjakan sesuatu hingga selesai,

-          Memiliki batas waktu mulai dan selesainya,

-          Membutuhkan resource/sumber daya dan waktu,

-          Bagi beberapa orang merupakan kesempatan/opportunity dan menarik.

Untuk itu sebuah proyek software perlu di menej. Manajemen itu berupa persiapan pekerjaan, pelaksanaan rencana, mengendalikan proyek tersebut dan terakhir menutup proyek dengan sebuah kesimpulan, yaitu sukses.

1.      Initiating: proyek sedang dalam proses untuk dipilih/disetujui, disponsori, didanai, dan diluncurkan.

2.      Planning: perencanaan adalah proses yang berulang (perhatikan gambar). Perencanaan pada dasarnya menggambarkan proses bagaimana proyek akan dilaksanakan hingga selesai.

3.      Executing: setelah proyek direncanakan, tim proyek memulai pekerjaannya.

4.      Controlling: selama tim proyek mengerjakan tugasnya, project manager mengontrolnya.

5.      Closing: setelah proyek diselesaikan project manager akan menutup proyek software.

Banyak proyek gagal di awal, bukan di akhir. Artinya, persiapan adalah bagian yang sangat penting bagi proyek software. Persiapan diwujudkan dalam bentuk perencanaan proyek. Tulisan ini menjelaskan point kedua yaitu Planning.

Tujuan Perencanaan Proyek

Perencanaan proyek Rekayasa Perangkat Lunak dari berbagai sudut pandang kurang lebih memiliki tujuan sebagai berikut:

1. Bagi Project Manager:
1. untuk menggambarkan status proyek kepada manajer senior dan stakeholder,
2. untuk merencanakan aktivitas tim proyek.
2. Bagi anggota Tim Proyek: untuk memahami konteks pekerjaan.
3. Bagi Manajer Senior:
1. untuk memastikan apakah biaya dan waktu yang dialokasikan masuk akal dan terkendali,
2. untuk melihat apakah proyek dilaksanakan secara efisien dan cost effective.
4. Bagi Stakeholder:
1. untuk memastikan apakah proyek masih berada pada jalurnya,
2. untuk memastikan kebutuhan mereka sedang diakomodir oleh proyek.

Perencanaan proyek rekayasa perangkat lunak membahas berbagai tindakan atau pekerjaan yang perlu dilakukan oleh semua yang terlibat di dalam proyek, termasuk dokumen-dokumen yang sebaiknya dibuat. Dokumen Perencanaan Proyek Rekayasa Perangkat Lunak akan terdiri atas sub-sub dokumen berikut ini:

1. Vision and Scope
2. Statement of Work
3. Resource List
4. Work Breakdown Structure
5. Project Schedule
6. Risk Plan

Berikutnya tiap-tiap dokumen tersebut akan dibahas secara lebih terperinci.

Vision and Scope

Dokumen ini adalah hasil kerja pertama dari seorang project manager. Berikutnya dokumen ini akan menjadi tool utama bagi project manager untuk acuan bagi dokumen-dokumen dan proses-proses berikutnya. Dokumen Vision and Scope yang baik dapat mencegah terjadinya masalah-masalah yang dapat memakan biaya yang besar. Dengan menunjukkan dokumen ini, baik kepada stakeholder maupun anggota tim proyek, diharapkan pemahaman yang sama tentang proyek yang sedang berjalan dapat diraih. Dokumen ini dapat dibagi menjadi dua bagian,yaitu:

1.      Problem Statement

Bagian Problem Statement terdiri atas empat sub bab, antara lain:

a.       Latar belakang proyek

Sub bab ini menceritakan dengan cukup mendalam baik latar belakang masalah maupun penjelasan mengenai mengapa organisasi memutuskan untuk membangun software untuk mengatasi masalah tersebut. Pada sub bab ini diceritakan sebab munculnya masalah, sejarah organisasi dengan permasalahan tersebut dan mengapa akhirnya diputuskan untuk membangun software yang diproyekkan.

b.      Stakeholder

Pada sub bab ini akan diberikan daftar stakeholder yang dilibatkan dalam proyek. Mulai dari customer hingga manajer-manajer senior. Stakeholder ini bisa berupa nama atau jabatan. Tim proyek harus paham dengan siapa mereka bekerja dan apa bidang kerja mereka. Daftar juga dilengkapi dengan alasan dicantumkannya stakeholder tersebut. Untuk proyek-proyek besar tentu saja pencantuman nama tidak relevan karena akan menjadi terlalu panjang daftarnya.

c.       Pengguna

Sub bab ini berisi daftar calon pengguna software. Sama dengan stakeholder, bisa berupa nama atau jabatan. Daftar juga dilengkapi dengan alasan dicantumkannya pengguna tersebut.

d.      Resiko

Sub bab ini akan diisi dengan faktor-faktor yang mungkin menjadi pemicu munculnya masalah, seperti keterlambatan dan permasalahan lain. Resiko yang dimaksud pada sub bab ini bisa faktor internal maupun eksternal.

2.      Vision of the Solution

Bagian Vision of the Solution juga akan terdiri atas empat sub bab, yaitu:

a.       Vision statement

Tujuan vision statement adalah menggambarkan apa yang ingin dicapai setelah proyek berjalan. Di dalam sub bab ini disebutkan faktor-faktor apa yang harus terpenuhi untuk menandakan kapan proyek dinyatakan selesai. Selain itu tujuan dari proyek juga harus jelas disebutkan di dalam sub bab ini. Waktu terbaik untuk membuat vision statement adalah setelah tim melakukan proses Requirement Engineering.

Gambaran produk yang ingin dicapai tersebut akan menjadi batasan ruang lingkup (scope) yang harus diperhatikan oleh semua pihak yang terlibat di dalam project. Ruang lingkup ini membutuhkan biaya dan waktu tertentu. Project manager yang baik akan mempersembahkan software tepat seperti yang telah dijanjikan kepada stakeholder dan user, tepat pada waktunya dengan menghabiskan biaya (menerima bayaran) tepat sama dengan perjanjiannya dengan customer.

Mungkin ada pendapat bahwa memberikan sedikit bonus fungsi terhadap software, dengan asumsi bahwa stakeholder atau user akan menyukainya, maka pendapat itu adalah kesalahan. Antara ruang lingkup, waktu dan biaya/harga harus ada keseimbangan. Jika ada penambahan pada ruang lingkup, maka seharusnya ada penambahan waktu atau biaya, jika tidak maka akan menyebabkan ketidak adilan bagi tim proyek/pengembang. Begitu juga sebaliknya. Perubahan ruang lingkup mestinya diatur dengan Change Control System.

b.      Daftar fitur

Sebuah paket software umumnya dapat dibagi-bagi menjadi beberapa fitur. Jumlah yang umumnya dapat diterima adalah sekitar sepuluh fitur. Jumlah ini sudah cukup menggambarkan kompleksitas software namun tetap nyaman dibaca oleh tim pengembang. Tiap fitur sebaiknya ditulis dalam paragraph yang terpisah atau dalam bentuk pointer-pointer. Deskripsi fitur-fitur ini tidak perlu sangat detil, cukup beberapa kalimat yang menggambarkan penjelasan umum tentang fitur tersebut. Fitur-fitur ini mungkin mengalami penambahan atau pengurangan, sesuai dengan permintaan stakeholder. Jika perlu, sebuah fitur dapat dilengkapi dengan use case. Namun tentu saja use case dibuat agar cukup simpel untuk dipahami oleh semua stakeholder.

c.       Ruang lingkup tiap fase (jika perlu)

Terkadang deadline yang diberikan untuk mengerjakan sebuah proyek software membuat pengerjaan seluruh fitur yang diajukan tidak mungkin selesai. Oleh karenanya dibuat solusi untuk membagi software menjadi beberapa fase rilis. Software akan dirilis pada saat deadline tercapai, namun dengan fitur yang dikurangi. Sedangkan rilis berikutnya lah yang memuat semua fitur.

Fitur-fitur yang ada pada rilis awal seharusnya adalah fitur yang sifatnya lebih penting daripada fitur lainnya, menurut stakeholder. Hal semacam ini perlu dikonsultasikan kepada tim pengembang.

d.      Fitur yang tidak akan dibuat

Terkadang stakeholder meminta fitur yang memang harus dibuang/ditinggalkan karena tidak masuk akal untuk diselesaikan dalam waktu yang tersedia, atau karena sebab-sebab lain. Fitur-fitur semacam ini perlu dicantumkan pada sub bab ini. Ini dicantumkan untuk diketahui semua pihak agar ada kesepahaman dan agar semua setuju dengan penghapusan fitur ini.

Statement of Work

Statement of Work adalah dokumen yang menggambarkan semua produk yang akan dihasilkan selama proyek berjalan dan siaa yang akan mengerjakannya. Secara lebih detil, di dalam SOW akan dirinci:

1.      Daftar fitur yang akan dibuat; jika software akan dirilis dalam fase-fase, maka fiturnya juga harus dibagi ke dalam fase-fase tersebut.

2.      Deskripsi hasil kerja (work product: spesifikasi kebutuhan, source code, test plan, laporan defect, dll) yang akan dibuat.

3.      Estimasi usaha setiap work product tersebut.

Estimasi dibutuhkan agar proyek dapat berjalan dan selesai tepat waktu. Project manager perlu membantu timnya untuk membuat estimasi yang tepat. Sebuah pendekatan perlu diambil untuk menyeragamkan teknik estimasi ini. Salah satu teknik estimasi yang dapat dipilih adalah Wideband Delphi. Berikut ini langkah-langkah di dalam Wideband Delhi:

1.      Memilih tim estimasi

Project manager memilih seorang moderator dan tim estimasi yang terdiri atas 3 hingga 7 orang. Jika tim yang telah dipilih merasa bahwa dokumen Vision and Scope kurang memberikan informasi, maka project manager harus memperbaiki dokumen tersebut.

2.      Kickoff Meeting

Pada rapat ini, tim akan membuat sebuah Work Breakdown Structure dan mendiskusikan berbagai asumsi yang muncul. Langkah-langkah yang dapat dijadikan acuan ketika rapat berlangsung kurang lebih sebagai berikut:

a.       Moderator menjelaskan metode Wideband Delphi,

b.      Moderator mereview dokumen Vision and Scope dan dokumen-dokumen pendukungnya, jika ada anggota tim yang belum membacanya,

c.       Tim mendiskusikan produk yang akan dibuat dengan berbagai asumsinya,

d.      Tim membuat 10 hingga 20 pekerjaan utama sebagai representasi pekerjaan level tertinggi pada WBS,

e.       Tim mendiskusikan estimasi terhadap WBS (jam, minggu, halaman, dll) tersebut hingga mendapatkan kata sepakat.

3.      Individual Preparation

Setelah kicoff meeting tiap anggota berusaha mengestimasi tiap-tiap pekerjaan di dalam WBS secara mandiri. Tahapan ini disebut sebagai Individual Preparation. Sebelumnya, moderator mencatat semua asumsi dan WBS kemudian membagikannya kepada semua anggota tim. 

4.      Estimation Session

Pada rapat ini, anggota tim bersama-sama merevisi estimasi-estimasiyang telah dibuat hingga menemukan kata sepakat. Dokumen berikut dapat dijadikan acuan sebagai contoh untuk membuat dokumentasi selama Estimation Session. Kepada setiap anggota tim akan dibagikan dokumen semacam ini (yang kosong) untuk kemudian direvisi selama jalannya Estimatin Session.

Berikutnya:

a.       Moderator dapat mengumpulkan Estimation Form. Estimasi tersebut kemudian ditabulasikan di papan tulis kemudian ditunjukkan kepada hadiri.

Estimation Form kemudian dikembalikan kepada anggota tim.

b.      Anggota kemudian akan melihat tabulasi tersebut. Jika diskusi meminta perubahan estimasi, maka perubahan tersebut dapat langsung dituliskan pada Estimation Form yang ada di tangan setiap anggota tim.

c.       Anggota tim mungkin akan menyampaikan perbedaanpendapat. Tetapi di dalam rapat ini tidak akan dibahas estimasi individu. Jadi yang mungkin diperdebatkan justru pekerjaannya. Tahap ini mugkin terbagi menjadi dua sesi, sesi pertama 40 menit dan sesi kedua 20 menit.

d.      Rapat akan merevisi estimasi individu dengan mengisikan kolom Delta berikutnya pada form Estimation Form. Isinya bisa +3, +2, -4 dsb. Nilai total barunya akan dituliskan pada bagian bawah form.

Tahap-tahap di atas dapat berulang hingga selesai, yaitu jika semua anggota tim menyetujui estimasi hasil rapat, atau jika rapat sudah berlangsung selama dua jam. 

5.      Review

Project manager akan meringkas, mengkompail kemudian mereview hasil estimasi untuk kemudian digunakan sebagai dasar perencanaan proyek software.

Resource List

Resource list adalah daftar resource/sumber daya yang digunakan selama proyek berlangsung. Daftar ini berisi apa saja yang dibutuhkan berdasarkan jadwal proyek dengan mencantumkan deskripsi resource tersebut serta limit ketersediaan resource tersebut. Daftar semacam ini umumnya dapat dibuat menggunakan software manajemen proyek. Tetapi bisa juga dibuat dengan worksheet atau word processor. Setelah SOW dan Resource List dibuat, seorang project manager harus membuat jadwal proyek (project schedule). Ini bisa dilakukan dengan urutan sebagai berikut:

1.      Membuat Work Breakdown Structure

2.      Estimasi usaha yang dibutuhkan oleh setiap pekerjaan pada WBS

3.      Project schedule dibuat dengan mengalokasikan resource dan waktu, berdasarkan kalender, untuk tiap pekerjaan pada WBS.

Jika WBS mengalami revisi (setelah melakukan estimasi, misalnya), misalnya penambahan, perubahan atau penghapusan pekerjaan, maka revisi ini harus tercatat di dalam dokumen Project Plan dengan disertai dengan keterangan waktu kapan dibuatnya perubahan tersebut.

Work Breakdown Structure

Work Breakdown Structure, disingkat WBS, berisi daftar pekerjaan yang jika diselesaikan akan menghasilkan work product. WBS menyebutkan:

1.      Apa saja pekerjaan yang akan dilakukan,

2.      Tipe-tipe resource yang dibutuhkan untuk bekerja,

3.      Estimasi tiap elemen pekerjaan,

4.      Identifikasi lokasi penyimpanan.

Tetapi tidak mencantumkan:

1.      Siapa yang mengerjakan pekerjaan-pekerjaan itu,

2.      Dan kapan pekerjaan itu akan diselesaikan.

Project Schedule

Project Schedule atau jadwal proyek dibuat oleh project manager untuk mengatur manusia di dalam proyek dan menunjukkan kepada organisasi bagaimana pekerjaan (proyek) akan dilaksanakan. Ini adalah alat untuk memantau (bagi project manager) apakah proyek dan tim masih terkendali atau tidak.

Project schedule berbentuk kalender yang dihubungkan dengan pekerjaan yang harus dikerjakan dan daftar resource yang dibutuhkan. Sebelum jadwal dibuat, WBS harus terlebih dahulu ada, jika tidak maka jadwal tersebut akan terkesan mengada-ada.

Untuk membuat project schedule, ada beberapa software yang bisa dijadikan pilihan. Pilihan software yang gratis dan open source antara lain: Open Workbench, dotProject, netOffice dan Tutos. Beberapa hal perlu diperhatikan ketika membuat project schedule, seperti:

1.      Alokasi resource pada tiap pekerjaan,

Resource bisa berupa berbagai hal seperti manusia, barang, peralatan (komputer, proyektor, dll), tempat (ruang rapat, misalnya) atau layanan (seperti training atau tim pendukung out source) yang dibutuhkan dan mungkin ketersediaannya terbatas. Bagaimanapun juga resource yang utama adalah manusia.

Pertama, project manager akan mengalokasikan orang(-orang) tertentu untuk suatu pekerjaan. Kemudian, selama pekerjaan tersebut berlangsung, orang tersebut mungkin menjadi terlalu sibuk sehingga tidak bisa dialokasikan untuk pekerjaan lainnya. Perhatikan bahwa pemilihan pelaku perlu disesuaikan dengan kemampuan dan berbagai hal lain karena ada pekerjaan yang dapat dilakukan oleh siapa saja, tetapi umumnya pekerjaan hanya dapat dikerjakan oleh satu atau beberapa orang saja.

2.      Identifikasikan setiap ketergantungan,

Sebuah pekerjaan disebut memiliki ketergantungan jika melibatkan aktivitas, resource atau work product yang dihasilkan pekerjaan/aktivitas lain. Contoh: test plan tidak mungkin dilaksanakan selama software belum diimplementasikan/ditulis, program baru dapat ditulis setelah class atau modul dibuat dan dideskripsikan pada tahapan desain.

Tiap pekerjaan pada WBS perlu diberi nomor, dengan angka tersebut bergantung pada nomor pekerjaan syaratnya.

3.      Buat jadwalnya

Tiap pekerjaan juga memiliki jangka waktu pekerjaan. Dengan demikian jadwal bisa dibuat.

Tiap pekerjaan ditunjukkan dengan kotak, sedangkan ketergantungan antar pekerjaan ditunjukkan dengan gambar panah. Kotak hitam berbentuk wajik antara D dan E (pada gambar di atas) disebut milestone atau pekerjaan tanpa durasi. Milestone digunakan untuk menunjukkan kejadian penting pada jadwal. Sedangkan kotak hitam panjang antara C dan D yang juga mengandung potongan wajik menunjukkan summary task atau dua sub pekerjaan yang memiliki induk yang sama.

Jadwal bisa dibuat dalam bentuk Gantt Chart, PERT atau diagram semacamnya.

Risk Plan

Risk plan adalah daftar resiko/masalah yang mungkin terjadi selama proyek berlangsung dan bagaimana menangani terjadinya resiko tersebut. Bagaimanapun juga ketidakpastian adalah musuh semua rencana, termasuk rencana proyek. Terkadang ada saja waktu-waktu yang tidak menyenangkan bagi proyek, banyak kesulitan terjadi misalnya suatu resource tiba-tiba tidak tersedia. Oleh karenanya risk plan adalah persiapan terbaik menghadapi ketidakpastian.

Langkah-langkah berikut dapat menjadi acuan untuk mendapatkan Risk Plan:

1.      Pembahasan resiko potensial

Project manager akan memimpin sebuah sesi/rapat untuk mengidentifikasikan masalah-masalah yang mungkin akan muncul. Anggota tim akan dipancing untuk mengemukakan resiko-resiko yang terpikirkan. Project manager akan menuliskannya di papan tulis setiap ada yang mengemukakan pendapat yang relevan. Sedikit pendapat mungkin akan muncul pada awalnya, kemudian berlanjut dengan tanggapan yang susul-menyusul hingga akhirnya suasana mendingin sampai akhirnya pendapat terakhir diutarakan.

Resiko yang dimaksud di sini adalah resiko spesifik. Jika suatu resiko dirasa belum spesifik maka project manager akan memancing agar permasalahan disampaikan secara lebih spesifik. Sumber masalah yang baik lainnya adah asumsi-asumsi yang muncul ketika membuat Vision and Scope dan melakukan estimasi dengan metode Wideband Dephi.

2.      Estimasi dampat tiap resiko/masalah

Tim akan memberikan rating untuk setiap resiko. Nilainya berkisar dari 1 (masalah dengan resiko kecil) hingga 5 (masalah dengan resiko besar, kemungkinan munculnya besar, mungkin menghabiskan biaya besar dan sulit untuk membereskannya).

3.      Buat sebuah risk plan

Tim akan mengidentifikasi langkah-langkah yang akan di ambil untuk mengatasi masalah-masalah yang akan muncul tersebut, dimulai dari resiko bernilai 5.

Pengembangan Perangkat Lunak

Permasalahan utama yang sering muncul dalam sebuah proyek pengembangan perangkat lunak adalah perubahan requirement yang begitu cepat. Hal ini terjadi sebagai akibat perubahan-perubahan yang muncul baik pada aspek bisnis maupun teknologi yang berlangsung lebih cepat daripada proses pengembangan perangkat lunak itu sendiri. Extreme Programming (XP) adalah sebuah pendekatan pengembangan perangkat lunak yang mencoba meningkatkan efisiensi dan fleksibilitas dari sebuah proyek pengembangan perangkat lunak dengan mengkombinasikan berbagai ide sederhana.

Bayangkan diri anda seorang project leader pada sebuah proyek pengembangan perangkat lunak. Setelah berbulan-bulan mengembangkan perangkat lunak dan proyek hampir selesai tiba-tiba saja di perusahaan klien anda terjadi perubahan kebijakan yang berimplikasi pada perangkat lunak anda. Betapa frustrasinya anda dan tim karena anda tidak bisa menolak perubahan-perubahan yang diajukan klien tersebut karena kontrak anda mengakomodasi adanya perubahan-perubahan tersebut. Hal tersebut seringkali terjadi disebabkan lamanya proses pengembangan perangkat lunak. Proses pengembangan perangkat lunak yang kompleks dapat menghabiskan waktu berbulan-bulan bahkan bertahun-tahun sebelum perangkat lunak dapat digunakan. Padahal seringkali dalam waktu tersebut terjadi perubahan besar pada situasi bisnis maupun teknologi yang bisa membuat perangkat lunak menjadi tidak relevan lagi.

Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. Walaupun menggunakan kata programming, XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak.

Sejarah XP

Proyek pengembangan perangkat lunak yang dianggap sebagai yang pertama kali menerapkan XP adalah C3 (Chrysler Comprehensive Compensation) Project dari Chrysler. Proyek ini adalah proyek penggajian 10.000 karyawan Chrysler, terdiri dari kira-kira 2000 class dan 30.000 method. Proyek yang dimulai pertengahan dekade 90-an ini terancam gagal karena rumitnya sistem yang dibangun dan kegagalan pada saat testing. Chrysler kemudian menyewa Kent Beck, seorang pakar software engineering yang di kemudian hari dikenal sebagai pencetus awal dari XP, untuk menyelamatkan proyek tersebut. Beck bersama rekannya Ron Jeffries dengan kewenangan yang diberikan oleh Chrysler melakukan berbagai perubahan di C3 Project untuk membuatnya lebih efisien, adaptif, dan fleksibel. Hal yang paling penting bagi mereka adalah harus mampu memenuhi permintaan utama dari Chrysler, untuk melakukan launching perangkat lunak tersebut dalam waktu tidak lebih dari dua tahun sejak saat Beck dikontrak.

Beck dan Jeffries pada akhirnya berhasil menyelesaikan target Chrysler dengan menerapkan berbagai metode dalam proses pengembangan perangkat lunak tersebut. Kumpulan metode inilah yang kemudian dikenal sebagai model atau pendekatan XP dalam pengembangan perangkat lunak. Begitu sederhananya metode-metode tersebut sehingga bagi orang yang belum menerapkan, XP terlihat sebagai kumpulan ide lama yang terlalu sederhana dan tidak akan memberikan efek apapun pada sebuah proyek pengembangan perangkat lunak.

Kent Beck sendiri mengakui dan menegaskan bahwa XP tidak selalu cocok untuk setiap proyek pengembangan perangkat lunak. Kelebihan XP adalah sesuai untuk digunakan pada proyek yang memiliki dynamic requirements. Proyek semacam ini memerlukan adaptasi cepat dalam mengatasi perubahan-perubahan yang terjadi selama proses pengembangan perangkat lunak. XP juga cocok untuk proyek dengan jumlah anggota tim tidak terlalu banyak (sekitar 10-20 orang) dan berada pada lokasi yang sama.

Nilai-nilai Dasar XP

            Berikut adalah nilai-nilai mendasar yang menjadi roh dari XP pada setiap tahapan proses pengembangan perangkat lunak:

1.      Communication

XP mengfokuskan pada hubungan komunikasi yang baik antar anggota tim. Para anggota tim harus membangun saling pengertian, mereka juga wajib saling berbagi pengetahuan dan keterampilan dalam mengembangkan perangkat lunak. Ego dari para programer yang biasaanya cukup tinggi harus ditekan dan mereka harus membuka diri untuk bekerjasama dengan programer lain dalam menuliskan kode program.

2.      Courage

Para anggota tim dan penanggungjawab pengembangan perangkat lunak harus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya. Integritas ini harus selalu dijaga bahkan dalam kondisi adanya tekanan dari situasi sekitar (misalnya oleh klien atau pemilik perusahaan). Untuk dapat melakukan sesuatu dengan penuh integritas terlebih dahulu para anggota tim harus terlebih dahulu memiliki rasa saling percaya. Rasa saling percaya inilah yang coba dibangun dan ditanamkan oleh XP pada berbagai aspeknya. 

3.      Simplicity

Lakukan semua dengan sederhana. Hal tersebut adalah salah satu nilai dasar dari XP. Gunakan method yang pendek dan simpel, jangan terlalu rumit dalam membuat desain, hilangkan fitur yang tidak ada gunanya, dan berbagai proses penyederhanaan lain akan selalu menjadi nilai utama dari setiap aspek XP.

4.      Feedback

Berikan selalu feedback kepada sesama anggota tim maupun pihak-pihak lain yang terlibat dalam pengembangan perangkat lunak. Utarakan selalu pikiran anda dan diskusikan kesalahan-kesalahan yang muncul selama proses pengembangan. Dengarkan selalu pendapat rekan yang lain, dengan adanya feedback inilah seringkali kita menyadari bagian mana yang salah atau bisa ditingkatkan lagi dari perangkat lunak yang dikembangkan.

5.      Quality Work

Semua nilai di atas berujung pada sebuah kondisi di mana kita melakukan pekerjaan dengan berkualitas. Dengan proses yang berkualitas maka implikasinya akan muncul pula perangkat lunak yang berkualitas sebagai hasil akhirnya.

Aspek Dasar XP

Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project.

1.      The Planning Game

Pendekatan XP dalam perencanaan sangat mirip dengan metode yang diterapkan pada RAD (Rapid Application Development). Proses pendek dan cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur teknis dan pertemuan intensif antara klien dengan developer. Pada XP proses ini menggunakan terminologi “game” karena Beck menyarankan untuk menggunakan teknik score card dalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana tersebut.

2.      Small Releases

Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developer menyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil tersebut harus segera dipresentasikan dan didiskusikan dengan klien. Jika memungkinkan untuk menerapkan unit tersebut pada perusahaan, hal itu juga dapat dilakukan sekaligus sebagai tes awal dari penerapan keseluruhan sistem. Kendati demikian hal ini tidak selalu perlu dilakukan karena harus dihitung terlebih dahulu sumberdaya yang dibutuhkan. Apakah lebih menguntungkan langsung melakukan tes terhadap unit tersebut atau melakukan tes setelah unit tersebut terintegrasi secara sempurna pada sistem.

3.      Metaphor

Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan perangkat lunak. Beck sendiri seperti para penandatangan Agile Manifesto lainnya bercita-cita menyederhanakan proses pengembangan perangkat lunak yang saat ini sudah dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi diagram dan kode semacam UML dianggap terlalu rumit untuk dimengerti, terutama oleh klien. Metaphor, walaupun mirip dengan arsitektur lebih bersifat naratif dan deskriptif. Dengan demikian diharapkan komunikasi antara klien dengan developer akan berlangsung lebih baik dan lancar dengan penggunaan metaphor.

4.      Simple Design

Sebagai salah seorang penandatangan Agile Manifesto, Beck adalah seorang yang tidak menyukai desain yang rumit dalam sebuah pengembangan perangkat lunak. Tidak heran jika dia memasukkan Simple Design sebagai salah satu unsur XP. Pada XP desain dibuat dalam lingkup kecil dan sederhana. Tidak perlu melakukan antisipasi terhadap berbagai perubahan di kemudian hari. Dengan desain yang simpel apabila terjadi perubahan maka membuat desain baru untuk mengatasi perubahan tersebut dapat dengan mudah dilakukan dan resiko kegagalan desain dapat diperkecil.

5.      Refactoring

Refactoring adalah salah satu aspek paling khas dari XP. Refactoring seperti didefinisikan oleh Martin Fowler adalah ”Melakukan perubahan pada kode program dari perangkat lunak dengan tujuan meningkatkan kualitas dari struktur program tersebut tanpa mengubah cara program tersebut bekerja”. Refactoring sendiri sangat sesuai untuk menjadi bagian XP karena Refactoring mengusung konsep penyederhanaan dari proses desain maupun struktur baris kode program. Dengan Refactoring tim pengembang dapat melakukan berbagai usaha untuk meningkatkan kualitas program tanpa kembali mengulang-ulang proses desain. Fowler adalah salah satu kolega dekat dari Kent Beck karena itu tidak mengherankan bahwa cara berpikir mereka terhadap proses pengembangan perangkat lunak sangat mirip satu dengan lainnya.

6.      Testing

XP menganut paradigma berbeda dalam hal tes dengan model pengembangan perangkat lunak lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru dikembangkan setelah perangkat lunak selesai menjalani proses coding maka pada XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani oleh perangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat lunak pada sistem dikembangkan terlebih dahulu. Saat proses coding selesai dilakukan maka perangkat lunak diuji dengan model tes yang telah dibuat tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada setiap unit perangkat lunak dalam lingkup sekecil mungkin daripada menunggu sampai seluruh perangkat lunak selesai dibuat. Dengan memahami tahap ini kita dapat melihat bahwa siklus pada XP adalah requirement analysis à test à code à design. Sekilas terlihat hal ini tidak mungkin dilakukan tetapi pada kenyataannya memang gambaran inilah yang paling dapat menjelaskan tentang XP.

7.      Pair Programming

Pair programming adalah melakukan proses menulis program dengan berpasangan. Dua orang programer saling bekerjasama di komputer yang sama untuk menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya selalu dapat berdiskusi dan saling melakukan koreksi apabila ada kesalahan dalam penulisan program. Aspek ini mungkin akan sulit dijalankan oleh para programer yang memiliki ego tinggi dan sering tidak nyaman untuk berbagi komputer bersama rekannnya.

8.      Collective Ownership

Tidak ada satupun baris kode program yang hanya dipahami oleh satu orang programer. XP menuntut para programer untuk berbagi pengetahuan untuk tiap baris program bahkan beserta hak untuk mengubahnya. Dengan pemahaman yang sama terhadap keseluruhan program, ketergantungan pada programer tertentu ataupun berbagai hambatan akibat perbedaan gaya menulis program dapat diperkecil. Pada level yang lebih tinggi bahkan dimungkinkan para programer dapat bertukar unit yang dibangunnya.

9.      Coding Standards

Pair programming dan collective ownership hanya akan dapat berjalan dengan baik apabila para programer memiliki pemahaman yang sama terhadap penulisan kode program. Dengan adanya coding standards yang telah disepakati terlebih dahulu maka pemahaman terhadap program akan menjadi mudah untuk semua programer dalam tim. Hal ini dapat diterapkan sebagai contoh pada penamaan variabel dan penggunaan tipe data yang sama untuk tiap elemen semua record atau array pada program.

10.   Continous Integration

Melakukan build setiap hari kerja menjadi sebuah model yang disukai oleh berbagai tim pengembang perangkat lunak. Hal ini terutama didorong oleh keberhasilan penerapan sistem ini oleh Microsoft dan telah sering dipublikasikan. Dengan melakukan build sesering mungkin berbagai kesalahan pada program dapat dideteksi dan diperbaiki secepat mungkin. Apabila banyak tim pengembang perangkat lunak meyakini bahwa build sekali sehari adalah minimum maka pada XP hal tersebut adalah maksimum. Pada XP tim disarankan untuk melakukan build sesering mungkin misalnya setiap 4 jam atau bahkan lebih cepat lagi.

11.   40-hours Week

Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu adalah maksimal untuk tiap programer. Lebih dari itu programer akan cenderung membuat berbagai error pada baris-baris kode programnya karena kelelahan.

12.   On-Site Customer

Sebuah pendekatan klasik, di mana XP menganjurkan bahwa ada anggota dari klien yang terlibat pada proses pengembangan perangkat lunak. Yang lebih penting lagi ia harus ada di tempat pemrogaman dan turut serta dalam proses build dan test yang dilakukan. Apabila ada kesalahan dalam pengembangan diharapkan klien dapat segera memberikan masukan untuk koreksinya.

Demikianlah sedikit introduksi tentang XP, ke-12 aspek tersebut saat ini telah banyak mengalami modifikasi seiring meluasnya penerapan XP. Sehingga berbagai model turunan dari XP mungkin terlihat sedikit berbeda. Yang paling penting bagi Kent Beck dan para koleganya sendiri adalah semua model yang mengadaptasi XP tersebut tetap setia pada nilai-nilai dasar XP dan menghindari kerumitan berlebihan dalam proses pengembangan perangkat lunak.