Learning Moments

Saat ini metodologi cerdas telah diadopsi oleh professional software engineer dan penerapan metode tersebut telah lama menjadi pro & kontra. Beberapa orang berpendapat bahwa proses hanya sesuai untuk pengembangan software berukuran kecil & menengah, karena itu para peneliti berusaha untuk memperluas metode cerdas ke arah pengembangan enterprise software.

Seperti proses software engineering lainnya, extreme programming berusaha untuk meningkatkan kualitas, produktivitas, dan performance software. Proses extreme programming harus dapat diukur agar dapat mengetahui kondisi sekompleks apakah yang bisa diselesaikan oleh proses tersebut.

Tulisan ini akan membahas setiap langkah di model proses pada extreme programming. Pertanyaan utama dalam study ini adalah “kompleksitas model seperti apa yang sesuai dengan extreme programming”. Study ini akan menghasilkan beberapa argumentasi dasar mengenai kompleksitas model yang sesuai dengan extreme programming.

1. Kompleksitas Software

Kompleksitas software adalah pendekatan untuk mendefinisikan bagaimana program software menjadi komplex. Kompleksitas software diukur oleh konsep yang disebut pengukuran software. Pengukuran produk difokuskan pada pengukuran dan prediksi karakteristik produk seperti kompleksitas komputasi dan reabilitas model, sebaik model evaluasinya. Proses pengukuran pada umumnya akan berfokus pada estimasi biaya, produktivitas model, pengukuran design, dan kualitas palayanan model.

1. 1 Pengukuran Software

Banyak sekali model pengukuran software yang dapat diadopsi untuk mengukur kompleksitas software. Basili [1983] mendefinisikan kompleksitas sebagai pengukuran dari sumber daya yang diekspansi oleh sistem pada saat berinteraksi dengan software pada saat melakukan suatu pekerjaan. Apabila sistem yang berinteraksi tersebut adalah pengembang, kompleksitas akan didefinisikan dengan tingkat kesulitan dalam melakukan pekerjaan, seperti coding, debugging, dan testing. Oleh karena itu kompleksitas software sering diaplikasikan pada interaksi antara software dengan pengembangnya.

Interaksi software dengan pengembangnya akan dilakukan menggunakan bahasa pemrograman khusus. Pada pendekatan Halstead [1973], pengukuran software dilakukan dengan sum LOC (Line of Codes), jumlah operan, dan operator. Metode ini dikembangkan oleh McCabe [1976] melalui pengukuran yang mendalam mengenai tipe data, tipe pengulangan, cabang, dan pernyataan kondisional.

Pengukuran lebih awal dapat dilakukan dengan mempertimbangkan kebutuhan dan rancangan. Pengukuran kebutuhan dapat dilihat dari spesifikasi yang diminta. Pengukuran rancangan didapatkan dari struktur diagram, derajat hubungan, dan alur informasi [shepperd, 1988].

Pendekatan lain untuk mengukur kompleksitas adalah dengan menggunakan notasi standard diagram seperti UML. Hal lain yang tak kalah penting dalam model rancangan software adalah arsitektur.

Arsitektur pada suatu sistem dinyatakan sebagai komposisi dari beberapa komponen yang saling berhubungan dalam menyelesaikan suatu pekerjaan.

Aktivitas pusat dari arsitektur rancangan adalah dekomposisi dari system menjadi sub system. Dekomposisi tersebut bertujuan untuk mengurangi kompleksitas konstruksi. Alsharif, et al [2004] menggunakan metode fungsi point secara penuh untuk menghitung kompleksitas dari software dalam komponen dan antar komponen satu dengan komponen lainnya.

1.2 Ukuran Software & Jenis Software yang Dikembangkan

Prinsip pengukuran membawa kita kepada pengetahuan yang lebih baik mengenai kompleksitas software. Software yang kompleks berarti ukuran dari project juga besar. Project size merupakan pendefinisi yang signifikan mengenai upaya, biaya, dan penjadwalan. Ukuran project dapat dihubungkan dengan jenis software yang dikembangkan seiring dengan berjalannya waktu, dan factor-faktor personal seperti keahlian, pengetahuan, dan komunikasi [McConnell, 2006].

Banyak ukuran project yang ditentukan dari jumlah baris pada kode program. Tabel I mengilustrasikan hubungan yang umum antara ukuran project dengan baris kode.

Angka pada table ini valid hanya untuk bentangan tujuan dari perbandingan antar bentangan ukuran. Nominal cocomo menunjukkan semakin tinggi produktivitas, semakin tinggi pencapaian.

Setelah ukuran, jenis project yang dikembangkan juga dapat menimbulkan kompleksitas. Product based software atau tailor based software adalah kategori dasar yang dapat memberikan perbedaan level kompleksitas. Contohnya pada prodect based, tim pengembang dapat dengan mudah mendefinisikan kebutuhan dan mengacu pada fitur yang ingin dicapai. Hal ini berbeda dengan tailore based yang harus memperhatikan kepentingan dan keinginan stakeholders yang disepakati dalam kontrak pengembangan software.

Contoh lain dari pengembangan software adalah seperti riset yang dilakukan Putnam & Mayers (1992). Putnam & Mayers menyajikan berbagai hasil dari tipe project yang umum beserta tingkat produktivitasnya, yang dapat dilihat pada table berikut :

Tabel tersebut menunjukkan pahwa pengembangan 10 KLOC project untuk system bisnis 5 kali lebih produktif daripada creative driver. Hasil ini dapat dikombinasikan dengan kategori utama yang telah dinyatakan sebelumnya (product based atau tailor based)

2. Faktor Personel dan Bahasa Pemrograman

Personel atau orang juga merupakan factor penting dalam hasil suatu project. Martin [2007] menyatakan bahwa prinsip, pola, dan pelatihan adalah hal yang penting, namun oranglah yang membuat elemen-elemen tersebut bekerja. Fakta ini dapat dengan mudah diketahui dengan mengamati developer baru yang akan membangun intranet system, dibandingkan dengan developer yang sudah 30 tahun berpengalaman, untuk membangun system sejenis. Implikasi dari hasil ini adalah bahwa pemilik project tidak dapat memperkirakan secara akurat mengenai kompleksitas suatu project apabila mereka tida mengetahui dengan tepat siapa yang akan mengerjakan project mereka.

Orang-orang yang akan bergabung dalam pengembangan project harus memiliki dasar pendidikan atau pengalaman yang sesuai. Secara teknis, kasus spesifik seperti bahasa pemrograman dapat mempengaruhi estimasi dari kompleksitas software di 4 bagian : pengalaman personel, fungsionalitas dari bahasa pemrograman, kekayaan dari piranti, dan tipe bahasa pemrograman. Riset Prechelt [2000] menunjukkan bahwa menggunakan bahasa yang diinterpretasikan dapat lebih produktif daripada bahasa tersusun. Riset lain yang dilakukan Jones [1998] menunjukkan bahwa perbandingan dari pernyataan bahasa pemrograman tingkat tinggi sepadan dengan kode C, seperti yang ditunjukkan pada table di bawah ini :

Riset ini menunjukkan bahwa menggunakan bahasa seperti java, C#, dan VB akan lebih produktif daripada menggunakan C atau bahasa assembly.

3. Kompleksitas Software Pada Extreme Programming

Extreme programming adalah disiplin dari pengembangan software berdasarkan pada nilai simplicity, komunikasi, feedback, dan keberanian [Jeffries, 2006]. Semua nilai direfleksikan pada kunci dari aktivitas XP yang disimpulkan dengan menggunakan gambar sbb :

Berdasar Pressman [2005] kunci dari aktivitas yang diilustrasikan pada gambar di atas mengarah pada poin-poin sebagai berikut :

1. Aktivitas perencanaan (planning) yang membentuk suatu rangkaian cerita user.

2. Aktivitas perancangan designing) yang menekankan pada kesederhanaan, mengikuti aturan KIS (keep it simple).

3. Aktivitas pengkodean (coding). Dalam melakukan pengkodean, developer harus mengikuti coding standard, sehingga code pada system tetap konsisten, mudah dibaca, dan mudah di-refactor.

4. Testing. Testing pada XP dilakukan melalui unit test, yaitu uji coba pada setiap unit yang ada pada system. Sekali unit test tersebut dilakukan, pengembang akan berfokus pada apa yang harus diimplementasikan untuk melewati unit tersebut.

5. Release. Dalam merilis software, XP menggunakan suatu metode pengurutan. Hal ini berarti bahwa proses pada XP tidak berjalan sekali pada satu baris. Proses pada XP berjalan pada model incremental dan berututan.

Berbagai langkah pada extreme programming menghasilkan mindset bahwa XP sangat simple dan sesuai untuk pengembangan software berukuran kecil hingga medium.

4. Pengukuran Model Pada Extreme Programming

Kesederhanaan pada model proses extreme programming dapat menumbuhkan kesimpulan yang menunjukkan bahwa hasil dari proses model akan memberikan model kompleksitas yang kecil-menengah.

Kecenderungan ini berdasar pada teori Krebs [2009] yang dapat diselidiki dengan melihat tiga elemen kunci daei project cerdas, yaitu kemajuan, kualitas, dan moral dari tim. Pengukuran kemajuan berarti membandingkan rencana awal dengan dengan nilai actual. Pada extreme programming, kebutuhan dapat dirumuskan secara cerdas sehingga perencanaan (untuk perkiraan usaha yang diperlukan software) dan nilai actual (untuk perkiraan usaha yang dibutuhkan untuk mengkonversi kebutuhan) dapat didefinisikan secara berbeda. Dalam hal ini pengukuran progress/kemajuan dapat berubah-ubah selama siklus extreme programming berjalan. Bagaimanapun terdapat dua metode yang umum digunakan, yaitu metode story point & use case points.

Karena metode story point relative dekat dengan cerita/penjelasan user, maka metode story point dapat digunakan secara linear. Metode story point berubah-ubah namun konsisten karena ada angka-angka yang digunakan oleh tim untuk mengukur cerita/penjelasan user. Cerita/penjelasan user merefleksikan kebutuhan dari project. Cerita/penjelasan yang panjang lebar menunjukkan bahwa project tersebut cukup compleks dan sebaliknya. Metode story point lebih berfokus pada ukuran dibandingkan durasi, sehingga metode ini dapat diadopsi dengan memberikan nilai numeric pada setiap cerita. Contohnya ukuran cerita dapat diberi nilai small (kecil) = 5, medium (menengah) = 10, large (besar) = 20. Story point dapat dikelompokkan dengan index seperti gambar berikut :

Kompleksitas dari software dapat dihitung dengan menambahkan semua story point dalam urutan. Apabila tim project dapat membuat definisi yang baik mengenai skala ukuran cerita (low, medium, high), tim tersebut dapat dengan cepat membangun kategori yang tepat.

Model pengukuran lain pada extreme programming berasal ari arsitektur dari software. Pada sudut pandang yang sederhana, arsitekur merupakan pambagian pemahaman mengenai rancangan system [Fowler, 2002]. Arsitektur berfokus pada bagaimana komponen dan interface menunjukkan metamorfosis pada extreme programming. Metamorfosis tersebut membentuk system dengan mengidentifikasi object kunci dan memberi masukan mengenai aspek-aspek pada system. Kartu CRC adalah salah satu model rancangan yang menunjukkan hubungan antar kelas (class), dimana rancangan ini dapat menjadi framework untuk menghitung kompleksitas arsitektur berdasarkan metode function point secara penuh [Al Sharif et al, 2004]. Gambar di bawah ini menunjujjan software arsitektur yang dideskripsikan dengan kartu CRC.

Berdasar kartu CRC, function point secara penuh dihitung dengan seberapa banyak kelas (class) pada kartu CRC yang menangani input/masukan dan ouput/hasil keluaran dari komunikasi. Panah-panah tersebut menunjukkan setiap kelas berkolaborasi dengan kelas lain. Function point secara penuh dapat dihitung sesuai deskripsi pada table berikut

Hasil dari table tersebut menyediakan informasi untuk tim extreme programming mengenai kompleksitas dari software melalui arsitekturnya. Hasil dari table tersebut dikombinasikan dengan story point akan menghasilkan model kompleksitas yang lebih jelas untuk tim sebelum memulai sesi pengkodean (coding).

Pada sesi pengkodean, beberapa aktivitas seperti tes untuk setiap unit dan pemfaktoran adalah aktivitas utama yang dilakukan tim pengembang. Pada sesi ini pengukuran model seperti LOC atau Cocomo akan menyediakan hasil yang lebih tajam untuk tim mengenai kompleksitas model. Bagaimanapun, karena nilai dari extreme programming adalah kesederhanaan, maka berbagai metode oengukuran sebaiknya tidak membatasi produktivitas dari tim. Orang-orang dalam tim dapat memilih model pengukuran software yang mereka butuhkan, sejak pra pengkodean hingga sesi pengkodean.

5. Menyesuaikan Kompleksitas Model Dengan Extreme Programming

Sebagai salah satu metode cerdas yang cukup terkenal, extreme programming mengalami banyak perubahan definisi kebutuhan sebagai bagian dari style cerdas [Beck, 2000]. Hal ini berarti bahwa setiap permintaan dari client akan didiskusikan dalam team meeting. Ketika perubahan definisi kebutuhan dapat diterima sesuai dengan waktu, sumber daya, dan perencanaan anggaran, tim akan mengkonfirmasi rencana rilis selanjutnya. Sebaliknya, apabila tidak dapat diterima, tim akan melakukan negosiasi ulang dengan client. Pendekatan ini mungkin dilakukan pada skala software yang kecil hingga menengah atau software yang dibangun sebagai produk. Bagaimanapun, pendekatan ini tidak mungkin dilakukan untuk software dengan skala besar (untuk kebutuhan enterprise). Pada skala enterprise, esensi dari bisnis dapat menjadi pemicu utama untuk segala sesuatu termasuk pengembangan software. Situasi ini sering disebut sebagi “kematian yang tiba-tiba (sudden death situation)“, ketika stakeholder memiliki keinginan agar tim pengembang dapat menemukan cara untuk memenuhi berbagai kebutuhan proses bisnis. Apabila situasi ini terjadi, banyak pengembang yang melakukan berbagai macam tindakan, seperti memperpanjang waktu project atau menambahkan anggota tim. Tindakan kedua dapat menyebabkan tim berkembang menjadi besar dan hal ini tidak disarankan pada extreme programming. Extreme programming menyarankan untuk membuat komposisi tim yang kecil atau tidak lebih dari 12 orang [Wake, 2000]. Argumen Wake tersebut berkaitan dengan teori McConnell [2006] mengenai ukuran project. Teori tersebut menyatakan bahwa project dengan skala kecil dimulai dengan individu hingga 5 orang dan project dengan skala menengah terdiri dari 5-25 orang.

Tabel berikut ini mengilustrasikan hubungan antara banyaknya member dalam suatu tim dengan ukuran project.

Rancangan yang sederhana adalah kunci dari model rancangan pada extreme programming. Nilai ini diadopsi dengan sedikit sekali diagram pada extreme programming. Extreme programming dimulai dengan pemodelan menggunakan prototype yang disebut ‘spike solution’. Cerita/penjelasan user dapat dituliskan pada dua sisi kartu yang mendeskribsikan apa yang dapat dilakukan user. Cerita/penjelasan user menyediakan informasi mengenai software behavior dan struktur software. Pada extreme programming penggunaan UML sebagai model rancangan cukup baik, namun software yang dapat bekerja dengan baik adalah yang paling utama. UML yang terlalu banyak akan mengakibatkan kondisi yang disebut paralys atau biasa disebut “hanya rancangan, tidak ada software yang dapat digunakan“. Bagaimanapun peneliti menyimpulkan bahwa model rancangan tidak cukup untuk mendefinisikan degala kebutuhan informasi yang akan dimunculkan pada pengembangan software. Extreme programming memiliki kelemahan pada blueprint yang detail.

Tabel di bawah ini akan mengilustrasikan model rancangan dibandingkan dengan kejelasan dari UML model proses yang disebut ICONIX [Rosenberg, 2000].

Kualitas pengkodean yang tinggu dan software yang dapat bekerja dengan baik adalah hal yang sangat penting pada extreme programming. Konsep yang disebut oemfaktoran dan uji coba (testing) akan memberikan jaminan kualitas dan performansi kode. Kode yang telah diuji coba adalah kode yang baik. Metode pengujian pada extreme programming disebut pengujian unit (unit testing). Unit testing dimulai dengan kerangka kode yang menunjukkan scenario ujicoba. Unit testing dan pengkodean yang ideal pada extreme programming akan memakan banyak waktu dan menghadapi kompleksitas software yang memiliki sangat banyak ketergantungan dan komponen-komponen yang sangat kompleks.

KESIMPULAN

• Pengukutan software dapat diterapkan pada metodologi cerdas seperti extreme programming
• Pengukuran proses yang sudah ada dapat diadopsi untuk mengumpulkan informasi mengenai model kompleksitas software untuk extreme programming. Study mengenai madalah ini menunjukkan dua macam pengukuran, yaitu pada arsitektor dan code metric.
• Kompleksitas yang dapat ditangani pada extreme programming sangat bergantung pada tim sebagai fackor personal. Karena tim pada extreme programming relative kecil, maka ukuran tim akan menjadi tolak ukr dari ukuran dan jenis software yang akan dikembangkan. Hal ini berarti pada kasus normal, ukuran software dan kompleksitas dari software yang dikembangkan dengan extreme programming akan memiliki skala kompleksitas kecil-menengah.
• Penyesuaian model kompleksitas dengan extreme programming melalui kebutuhan, rancangan, dan pengkodean memberikan pemahaman yang lebih baik bahwa model roses pada extreme programming paling sesuai untuk model kompleksitas dengan ukuran kecil sampai menengah.

• Kompleksitas model pada extreme programming dapat ditingkatkan dengan memperluas dan mengadopsi metode framework terstruktur yang tidak sesuai dengan software untuk skala enterprise.