Learning Moments

I.[β] BetaMart
BetaMart adalah sebuah minimarket yang menjual beberapa kebutuhan keluarga dan kebutuhan lainnya. BetaMart mempunyai 2 orang kasir untuk menjaga toko dengan bergantian. Sedangkan untuk mempermudah pengontrolan barang, BetaMart mempunyai 2 karyawan lagi sebagai staf warehouse (gudang). Sedangkan di toko itu sendiri terdapat 4 pramuniaga toko untuk membantu pembeli yang bekerja secara shift.

II.Proses Bisnis
Proses bisnis dimulai ketika pelanggan memilih/berbelanja, setelah puas dalam memilih kebutuhannya, pelanggan akan melakukan pembayaran, bila pelanggan tersebut belum
bergabung menjadi member maka pelangan tersebut ditawarkan untuk menjadi member dan pelayan/kasir menjelaskan keuntungan bergabung sebagai member. Prosedur menjadi member yaitu dengan memberikan deposit kepada BetaMart, maka pelanggan akan diberikan voucher belanja dengan nilai sesuai dengan deposit yang disetorkan, dan akan mendapatkan diskon 10% disetiap transaksi dan diskon promo lainnya. Nantinya sistem pembayaran dengan deposit disebut sebagai sistem voucher. Bila tidak maka transaksi dilakukan dengan pembayaran tunai, dimana petugas tidak mencatat nama & identitas pembeli. Petugas kasir akan memberikan laporan penjualan secara harian kepada petugas gudang sehingga petugas gudang dapat mengecek persediaan barang di toko. Apabila stok barang yang dijual sudah habis atau memerlukan tambahan stock, petugas gudang akan mengirim barang ke toko dan petugas kasir akan melakukan pencatatan data barang yang dikirimkan. Petugas gudang juga melakukan pengecekan harian stok barang pada gudang untuk melakukan purchase order.

III. Pengembangan Aplikasi Dengan Metode Extreme Programming
1.Planning
* Use Case Diagram


2.Designing
* Class Diagram


* User Interface
•Login


•Transaksi Member


•Transaksi Pembayaran


3.Coding
Setelah metode designing dilakukan, maka akan dilakukan pengkodean untuk membuat program dari sistem penjualan/kasir Beta Mart.

4.Testing
Testing yang saya lakukan hanya pada proses pembayaran/kasir dan tidak pada semua menu. Saya melakukan testing pada menu pelanggan, menu pembayaran dan cetak faktur. Data yang bisa di cari yaitu data barang atau pelanggan.
1.Login


2.Pelanggan


3.Input Data Pelanggan


4.Pencarian Data Pelanggan


5.Transaksi


5.Incremental Release
Setelah melalui unit testing akan dilakukan incremental release, yaitu release software secara bertahap.
Release Texts :
1. Betamart System V.1.1
* Fitur pada Betamart V.1.1
•Login : access database karyawan dengan authorisasi
•Member checking : access database member
•Member added : penambahan database member
•Transaction recording : access database transaksi, detail barang, metode bayar
•Automated calculation: kalkulasi otomatis diskon & jumlah pembayaran
•Automated stock calculation: kalkulasi otomatis pengurangan stok barang di toko
•Stock added : penambahan stok barang di toko

* Issue
•Rejection stock added (bug130875)
•Temp solution : restart system

2. Betamart System V.1.2
* Pembaharuan & Fitur Tambahan pada Betamart V.1.2
•Fix bug130875
•Search member
Pada versi sebelumnya, search member dilakukan secara manual dengan button next.
Dengan search member, petugas tinggal memasukkan nama member, kemudian akan
muncul list member dengan nama sesuai keyword.
* Issue
•Manual synchronization stock data system penjualan & data warehouse (based on
kasir report yang dibuat secara manual)

3. Betamart System V.1.3
* Pembaharuan & Fitur Tambahan pada Betamart V.1.3
•Automatic synchronization stock data system penjualan & data warehouse
- Automatic generate cashier report
- Automatic amount checking of stock data


IV.Verifikasi Dan Validasi
1)LOGIN
1.Tujuan yang ingin dicapai : User dapat melakukan login sesuai dengan
autorisasinya.
2.Data Test >> Data Login :
Username : C31198
Password : *******
3.Skenario :
a.User mengisikan username & password
b.User menekan button “Login”
c.Apabila terjadi kesalahan penulisan, user dapat menekan button “Reset” dan
field username & password akan kembali kosong
d.Apabila terjadi kesalahan username atau password
4.Hasil yang diharapkan : User dapat masuk ke dalam sistem
5.Hasil yang diperoleh : 1
6.Status : OK

2)PRE TRANSACTION
1.Tujuan yang ingin dicapai : user dapat memilih jenis transaksi (member atau non
member) dan mencari data pelanggan
2.Data Test >> Data Input :
Member Code : M121
Name : Rino Andriya (manual or automatic filled)
Address : Karang Menur I No. 10 (automatic filled)
Deposit : Rp 750.000, 00 (automatic filled)
Last Transaction : 10 May 2009 (automatic filled)
3.Skenario :
a.User mengisikan member code
b.Data lainnya (name, address, deposit, last transaction) akan muncul secara
otomatis
c.User dapat menggunakan metode lain dengan mengisikan name
d.Data lainnya (member code, address, deposit, last transaction) akan muncul
secara otomatis
e.Untuk nama yang similar, user dapat menekan button “>>” dan “<<”
f.Setelah data member sesuai, user dapat menekan button “Next”
g.Untuk member baru, user dapat menekan button “Register”
h.Untuk nonmember, user dapat menekan button “Non Member”
4.Hasil yang diharapkan : Jenis transaksi (member/non member) dapat diidentifikasi
dan data member dapat ditampilkan.
5.Hasil yang diperoleh : 1
6.Status : OK

3)MEMBER REGISTRATION
1.Tujuan yang ingin dicapai : user dapat mendata member baru atau mengubah data
member
2.Data Test >> Data Input :
Member Code : M203 (automatic generated)
Name : Samantha Rosalia (manual filled)
Address : Gajahmada I No. 30 (manual filled)
Phone No. : +62812339876087
Deposit : Rp 500.000, 00 (manual filled)
3.Skenario :
a.User menginput data member seperti nama, alamat, no. telp, dan jumlah deposit
awal
b.User menekan button “Save”
c.Untuk mengubah data member, user dapat menekan button “Edit” dan menekan button
“Save” setelah melakukan perubahan
4.Hasil yang diharapkan : Member baru dapat atau perubahan data member dapat
tercatat pada system.
5.Hasil yang diperoleh : 1
6.Status : OK

4)TRANSACTION
1.Tujuan yang ingin dicapai : user dapat mencatat transaksi yang dilakukan
pelanggan
2.Data Test >> Data Input :
Cashier : Ranie (Automatic filled from login data)
Member Code : M121 (automatic filled from )
Item Code : S141
Discount : 10%
3.Skenario :
a.User menginput item code & quantity, lalu menekan button “Insert” (bisa
dilakukan dengan barcode)
b.User dapat menginput data barang berdasar nama, dengan memasukkan nama barang
pada “Textbox Search” lalu menekan button “Search”
c.Field discount akan otomatis terisi apabila pelanggan adalah member Betamart
d.Field total akan otomatis terisi (automatic calculate)
e.Untuk barang yang tidak jadi dibeli, user dapat menekan button “Cancel: untuk
mengeluarkan barang tersebut dari list.
f.Apabila pencatatan transaksi sudah selesai, user dapat menekan button “OK”
untuk mencetak struk sekaligus menyimpan data transaksi pada database.
g.Untuk membatalkan transaksi dan kembali ke halaman sebelumnya, user dapat
menekan button “Cancel”
h.Untuk mengosongkan field, user dapat menekan tombol “Reset”
4.Hasil yang diharapkan : transaksi dapat tercatat pada system dan pencetakan struk
dapat dilakukan
5.Hasil yang diperoleh : 1
6.Status : OK

Question :
Suppose we have an application that includes an interface (method) whose purpose is to find a "matching" record in a collection, if one exists. If none exists, the method is to return null.
The collection is large. Some users of this method have partial knowledge of the collection's order, so that they know that the record they want, if it is in there at all, occurs at or after some integer index in the collection.
So the method accepts a value, let's say a string /find/, to match the record on, and an integer /hint/, to be used as a hint to start the search. The first record in the table is numbered zero. The largest meaningful /hint/ value is therefore N-1, where N is the number of records in the table.
We want the search to always find a record if one exists, so that if /hint/ is wrong, but /find/ is in some record, we must still return a matching record, not null.
Now then. Assuming a black box, what questions do we want to ask, what tests do we want to write, against our method

Answer :
1. Generate various data sets to run the 'search' method against.

1a. Vary the number of items in the collection: create collections with 0, 1, 10, 100, 1000, 10000, 100000, 1 million items for starters; it may be the case that we hit an operating system limit at some point, for example if the items are files in the same directory (ever done an ls only to get back a message like "too many arguments"?)

1b. For each collection in 1a., generate several orderings: increasing order, decreasing order, random, maybe some other statistical distributions.

1c. Vary the length of the names of the items in the collection: create collections with 0, 1, 10, 100, 1000 items, where the names of the items are generated randomly with lengths between 1 and 1000 (arbitrary limit, which may change as we progress testing).

1d. Generate item names with 'weird' characters (especially /, \, :, ; -- since they tend to be used as separators by the OS).

1e. Generate item names that are Unicode strings.

2. Run (and time) the 'search' method against the various collections generated in 1. Make sure you cover cases such as:

2a. The item we search for is not in the collection: verify that the search method returns Null.

2b. The item we search for is in position p, where p can be 0, N/2, N-1, N.

2c. For each case in 2b, specify a hint of 0, p-1, p, p+1, N-1: verify that in all combinations of 2b and 2c, the search method returns the item in position p.

2d. Investigate the effect of item naming on the search. Does the search method work correctly when item names keep getting longer? When the item names contain 'weird' or Unicode characters?

2e. Graph the running time of the search method against collection size, when the item is or is not in the collection (so you generate 2 graphs). See if there is any anomaly.

2f. Run the tests in 2a-2d in a loop, to see if the search method produces a memory leak.

2g. Monitor various OS parameters (via top, vmstat, Windows PerfMon) to see how well-behaved the search functionality is in regards to the resources on that machine.

2h. See how the search method behaves when other resource-intensive processes are running on that machine (CPU-, disk-, memory-, network- intensive).


source : www.agiletesting.blogspot.com

1. Planning

User stories :

· Petugas memasukkan data authentikasi pada system (dilakukan sekali pada saat mulai bekerja sesuai shift yang telah ditentukan).

· Petugas memasukkan data nomor kendaraan pada system.

· System secara otomatis akan merekam jam pencatatan data sebagai jam masuk serta nama petugas yang log in pada shift tersebut

· Petugas akan melakukan print out data yang dimasukkan dan menyerahkannya pada pengemudi kendaraan yang bersangkutan.

· Pada saat kendaraan keluar, petugas akan kembali memasukkan nomor kendaraan pada system.

· Secara otomatis system akan mencari data kendaraan yang dimaksud, merekam jam pencatatan data sebagai jam keluar, melakukan kalkulasi lamanya parkir, dan memberikan keluaran (output) berupa jumlah biaya parkir yang harus dibayarkan.

· Petugas akan melakukan print out data dan menyerahkan pada pengemudi.

· Petugas akan menerima pembayaran dari pengemudi.

2. Designing

Mendefinisikan class diagram beserta atributnya:

1. user :

iduser

pass

name

2. trx :

idTrx

platNo

createdDate

startTime

createdBy

finishTime

totalPayment

3. chargeParameter :

chargesPerHour

Note :

karena pada perangkat lunak yang akan dikembangkan hanya memiliki 1 jenis user (petugas parkir) yang akan memegang role ‘responsibility’ pada system, maka CRC card (class, responsibility, collaboration) untuk menentukan kolaborasi pada system digantikan dengan class diagram, sebagai berikut :

3. Coding

Setelah metode designing dilakukan, maka akan dilakukan pengkodean untuk membuat program dari sistem smart parking.

4. Testing

Setelah dilakukan pengkodean, dilakukan unit testing, apabila terdapat bug, system akan di-review kembali.

5. Incremental Release

Setelah melalui unit testing akan dilakukan incremental release, yaitu release software secara bertahap, misal SmartParking System V 1.1

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.

Abstrak

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.

Tujuan XP

Tujuan utama XP adalah menurunkan biaya dari adanya perubahan software. Dalam metodologi pengembangan sistem tradisional, kebutuhan sistem ditentukan pada tahap awal pengembangan proyek dan bersifat fixed. Hal ini berarti biaya terhadap adanya perubahan kebutuhan yang terjadi pada tahap selanjutnya akan menjadi mahal. XP diarahkan untuk menurunkan biaya dari adanya perubahan dengan memperkenalkan nilai-nilai basis dasar, prinsip dan praktis. Dengan menerapkan XP, pengembangan suatu sistem haruslah lebih fleksibel terhadap perubahan.P

Penggunaan XP

XP tepat digunakan saat

• Keperluan berubah dengan cepat

• Resiko tinggi dan ada proyek dengan tantangan yang baru

• Tim programmer sedikit, yaitu antara 2-10 orang

• Mampu mengotomatiskan tes

• Ada peran serta pelanggan secara langsung

Variabel XP

Terdapat 4 variabel XP, yaitu antara lain :

1. Cost (biaya) Dengan meningkatkan biaya, kita bisa menciptakan program yang lebih baik. Sebaliknya mengurangi biaya untuk proyek tidak akan menyelesaikan masalah customer. Tetapi, biaya yang tiak terbatas juga akan menimbulkan kerusakan.
2. Time (waktu) Dengan meningkatkan waktu makan kita akan mampu menciptakan program yang berkualitas dan dengan feature-feature yang lebih banyak.Akan tetapi waktu yang berlebihan tidak baik, karena dapat merusak terhadap diri sendiri. Waktu yang sedikit juga tidak baik karena kualitas yang dihasilkan akan jauh dari yang diharapkan.
3. Quality (mutu) Mutu merupakan suatu variabel pengendali yang sangat “mengerikan” karena merupakan suatu hal yang sangat diperhatikan oleh konsumen.
4. Scope (feature) Scope merupakan varibel primer. Jika kita mengurangi Scope,maka kita bisa mengurangi biaya dan meningkatkan kualitas.

Kunci utama XP (XP Value)

Menurut penggagas dari metode XP, Kent Beck mendefinisikan lima kunci utama dari XP, yaitu :

1. Communication XP memfokuskan 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 programmer yang biasanya cukup tinggi harus ditekan dan mereka harus membuka diri untuk bekerjasama dengan programmer lain dalam menuliskan kode program.
2. Courege Para anggota tim dan penanggungjawab pengembangan perangkat lunakharus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya. Integritas ini harus selalu dijaga bahkan dalam kondisi adanya tekanan dari situasi sekitar. Untuk dapat melakukan sesuatu dengan penuh integritas, terlebih dahulu para anggota tim 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 metode 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 dimana kita melakukan pekerjaan dengan berkualitas. Denagn proses yang berkualitas maka akan muncul pula implikasi perangkat lunak yang berkualitas sebagai hasil akhir.

Prinsip utama XP

Dalam penerapannya, Extreme Programming memiliki lima prinsip utama, yaitu:

1. Rapid Feedback Menurut ilmu psikologi, waktu antara sebuah aksi dengan feedbacknya sangat penting untuk dipelajari. Dalam sebuah proyek XP, developer memperoleh feedback sesegera mungkin, menginterpretasikannya, lalu mengambil inti sarinya dan meletakkannya ke dalam system. Feedback dari pelanggan terhitung harian, bukan bulanan, dan feedback dari developer terhitung menitan, bukan mingguan!
2. Assume Simplicity Hanya mendesain untuk masalah saat ini dan menghemat waktu 98% dari masalah tersebut dan hanya menekuni sekitar 2% untuk bagian yang sulit. XP berencana untuk masa depan sehingga desainnya bias di-reuse, lakukan pekerjaan yang penting, dan percayalah bahwa untuk kekompleksitasan bias ditambahkan kemudian.
3. Incremental Change Pemecahan problem yaitu dengan bagian-bagian kecil perubahan saja. Jadi perubahan-perubahan yang terjadi pada XP melalui tahap-tahap kecil dan waktu yang singkat.
4. Embracing Change Mencari dan menyediakan terlebih dahulu sebanyak mungkin pilihan ketika menyelesaikan masalah yang begitu menekan.
5. Quality Work Setiap orang suka mengerjakan pekerjaan yang bagus dan layak dan kualitas yang dimaksud di sini adalah kualitas yang sempurna dan kualitas yang sempurna secara ekstrim. Karena tanpa kualitas kita tidak akan suka melakukan pekerjaan tersebut, hasilnya tidak akan sempurna dan proyeknya akan jatuh berantakan.

Aspek Dasar XP

Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project. Teknik-teknik tersebut dapat diamati pada gambar berikut ini:

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.