MAKALAH

REKAYASA PERANGKAT LUNAK

“Extreme Programming”

DISUSUN OLEH

HONASAN SIRAIT

LUKY ILYAS SAPUTRO

REEZKY ILLMAWATI

RIZQY FITRIANTO

SETO SULISTIYONO

TEKNIK INORMATIKA

TEKNOLOGI INDUSTRI

UNIVERSITAS GUNADARMA

0
 2018-2019

KATA PENGANTAR

Puji dan syukur kami panjatkan kehadirat Allah SWT, karena dengan rahmat dan karunia-
Nya kami dapat menyelesaikan makalah ini dengan baik. Makalah ini disusun agar pembaca dapat
memperluas pengetahuan dan wawasan ilmu “Extreme Programing” .

Penyusun juga mengucapkan terimakasih kepada dosen yang telah memberikan arahan
kepada kami dalam menyelesaikan tugas ini. Kami berharap semoga para pembaca dapat
mempelajari isi dari makalah ini. Penyusunan makalah ini, kita ketahui belum sempurna. Oleh
karena itu, semua kritik, saran, atau pendapat akan diterima dengan terbuka.

Walaupun makalah ini mempunyai kelebihan dan kekurangannya. Oleh karena itu, kami
mengharapkan saran,kritik, dan pendapat yang membangun untuk kesempurnaan makalah ini .

Terimakasih

Jakarta,November 2018

Penyusun

1
 DAFTAR ISI

KATA PENGANTAR 1

DAFTAR ISI 2

BAB I PENDAHULUAN

1.1 Latar Belakang 4

1.2 Tujuan 4
1.3 Ruang Lingkup 5

BAB II LANDASAN TEORI

2.1 Sejarah Extreme Programming 6

2.2 Tujuan Extreme Programming 7

2.3 Prinsip Dasar Extreme Programming 8

2.4 Tahapan Extreme Programming 8

2.5 Kelebihan dan Kelemahan Extreme Programming 11

BAB III PEMBAHASAN

3.1 Pengertian Extreme Programming 16

3.2 Penerapan Extreme Programming 16

3.3 Aspek Dasar Extreme Programming 17

3.4 Cara Kerja Extreme Programming 18

3.5 Kasus dengan Metodelogi Extreme Programming 20

BAB IV PENUTUP

4.1 Kesimpulan 28

2
4.2 Saran 28

DAFTAR PUSTAKA 29

LAMPIRAN 31

3
 BAB I

PENDAHULUAN

1.1 Latar Belakang

Pengembangan perangkat lunak merupakan salah satu bagian yang sangat penting dari
pengembangan Teknologi Informasi secara keseluruhan. Teknologi Informasi yang semakin
kokoh menancapkan fungsi-fungsinya dalam berbagai aspek saat ini sangat bervariasi dalam
pengimplementasian perangkat lunaknya. Untuk mendukung hal tersebut, paradigma atau
metodologi pengembangan perangkat lunak pun menjadi semakin pesat perkembangannya.
Perkembangan metodologi tersebut berjalan sesuai dengan perkembangan tingkat kebutuhan
akan perangkat lunak sebagai unsur yang penting dalam teknologi informasi.
Perangkat lunak merupakan kumpulan objek yang membentuk konfigurasi yang dapat berupa
program, dokumen, atau data. Perangkat lunak adalah sesuatu yang dikembangkan, bukan
dibuat secara pabrikan seperti perangkat keras. Pengembangan perangkat lunak memerlukan
langkah-langkah yang tepat, efektif dan efisien untuk menjamin terpenuhinya kebutuhan user.
Untuk itulah berkembang berbagai metodologi pengembangan perangkat lunak.
Metodologi pengembangan perangkat lunak berawal dengan model waterfall yang sangat
linear dan sekuensial, hingga unified process yang merupakan metodologi pengembangan
untuk sistem berorientasi objek. Semua metodologi tersebut masih memiliki kelemahan
mendasar yaitu masih kurang bisa mengatasi perubahan requirements yang begitu cepat dari
pihak user. Hal ini kemudian mendorong berkembangnya metodologi yang terkenal dengan
sebutan Agile Methods. Salah satu agile methods yang sangat populer ialah extreme
programming (XP). XP bahkan bisa digolongkan ke dalam metodologi pengembangan
perangkat lunak yang semi formal karena berbagai practice-nya yang sangat fleksibel.
Berdasarkan latar belakang pada makalah ini, yang akan dibahas mengenai metodelogi
Extreme Programming.

4
1.2 Tujuan
Berdasarkan latar belakang diatas dapat disimpulkan bahwa makalah ini bertujuan
1. Untuk mengetahui Penerapan dari Extreme Programming
2. Untuk mengetahui Aspek Dasar dari Extreme Programming
3. Untuk mengetahui Cara Kerja dari Extreme Programming
4. Untuk mengetahui Contoh Kasus dengan Metodelogi Extreme Programming
1.3 Ruang Lingkup
Berdasarkan latar belakang permasalahan diatas dapat disimpulkan bahwa dalam makalah ini
menjelaskan rekayasa perangkat lunak dengan metodelogi extreme programming.

5
 BAB II

LANDASAN TEORI

2.1 Sejarah Extreme Programming

Extreme programming dimunculkan untuk menangani perubahan-perubahan yang biasanya
sering terjadi pada saat pengembangan berlangsung bahkan pada saat proses pengembangan
sudah hampir berakhir. Selain itu XP juga dimunculkan untuk mengatasi berbagai
requirements yang tidak jelas dari user. Sebagai sebuah metodologi untuk mengembangkan
peragkat lunak XP tentu memiliki siklus hidup. Siklus hidup pada XP ini terdapat lima fase.
Extreme Programming diciptakan oleh Kent Beck selama bekerja di Chrysler Menyeluruh
Sistem Kompensasi (C3) proyek penggajian. Beck C3 menjadi pemimpin proyek Maret 1996
dan mulai untuk memperbaiki metode pengembangan yang digunakan dalam proyek dan
menulis sebuah buku tentang metode (pada Oktober 1999, Extreme Programming Explained
diterbitkan). Chrysler membatalkan proyek C3 pada Februari 2000, setelah perusahaan
diakuisisi oleh Daimler-Benz. Meskipun Extreme Programming itu sendiri adalah relatif baru,
banyak dari praktik sudah ada selama beberapa waktu, metodologi, setelah semua, diperlukan
praktek terbaik untuk tingkat ekstrem. Sebagai contoh, tes-praktek pembangunan pertama,
perencanaan dan tes tertulis sebelum setiap mikro-increment digunakan sebagai awal NASA
Project Mercury, pada awal 1960-an (Larman 2003). Refactoring, modularitas, bottom-up dan
desain inkremental digambarkan oleh Leo Brodie dalam bukunya yang diterbitkan pada tahun
198.
2.2 Tujuan Extreme Programming
Tujuan utama dalam extreme programming adalah menurunkan biaya dari adanya perubahan
software. Dalam metodologi pengembangan sistem tradisional, kebutuhan sistem ditentukan
pada tahap awal pengembangan proyek dan bersifat xed. 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
eksibel terhadap perubahan. Sasaran XP adalah tim yang dibentuk berukuran antara kecil

6
 sampai medium saja, tidak perlu menggunakan sebuah tim yang besar. Hal ini dimaksudkan
untuk menghadapi requirements yang tidak jelas maupun terjadinya perubahan-perubahan
requirements yang sangat cepat. XP dimunculkan untuk menangani perubahan-perubahan
yang biasanya sering terjadi pada saat pengembangan berlangsung bahkan pada saat proses
pengembangan sudah hampir berakhir.
2.3 Prinsip Dasar Extreme Programming
1. Tracker
Sekitar sekali atau dua kali seminggu, tracker meminta setiap programmer menjelaskan
mengenai proses, mengambil tindakan jika hal-hal tampaknya akan keluar jalur.
Tindakan termasuk menyarakankan sesi CRC, menyiapkan pertemuan dengan
customer, meminta pelatih atau programmer lain untuk membantu.
2. Customer
Menulis UserStories dan FunctionalTest menentukan prioritas set, menjelaskan cerita,
pandangan sesi CRC. Sesuai dengan GoalDonor C3 ini, mungkin atau tidak mungkin
juga menjadi gold owner tersebut.
3. Programmer
Memperkirakan user Story, mendefinisikan teknik tugas dari story, memperkirakan
bagaimana cerita panjang dan tugas akan mengambil, menerapkan cerita dan unit
pengujian.
4. Coach
Mengamati semuanya, mengirimkan sinyal jelas, memastikan proyek terus
StayExtreme. Membantu dengan apapun.
5. Tester
Mengimplementasikan dan menjalanjan Functional Tests. Grafik hasil, membuat orang
yakin tahu kapan hasil uji penurunan. (catatan : programmer melakukan unitTest
merekan sendiri.
6. Doomsayer
Yang memberika relaksasi pada saat terjatuh, dan ketika anda berada dalam masalah
besar.
7. IT manager

7
 Diharapka mengerti tugas-tugas IT staff agar dapat mengetahui jangka waktu suatu
projek dari IT staff terebut guna memanage tugas mereka agar tidak bentrok dengan
tugas lainnya dan setidaknya IT manager harus dapat memutuskan solusi yang tepat
ketika IT staff tersebut mengalami kendala dalam tugas.
2.4 Siklus Extreme Programming
Extreme Programing dimunculkan untuk menangani perubahan-perubahan yang biasanya
sering terjadi pada saat pengembangan berlangsung bahkan pada saat proses pengembangan
sudah hampir berakhir. Selain itu XP juga dimunculkan untuk mengatasi berbagai
requirements yang tidak jelas dari user. Sebagai sebuah metodologi untuk mengembangkan
peragkat lunak XP tentu memiliki siklus hidup. Siklus hidup pada XP ini terdapat enam fase
yaitu :
1. Exploration Phase
Pada fase eksplorasi dilakukan pendataan fitur apa saja yang diinginkan oleh pengguna
pada rilis pertama. Tahap ini dapat menggunkaan media yang disebut user story cards.
Kartu ini akan menggambarkan beberapa fitur yang terdapat pada sistem nantinya. Tim
pengembang akan secara simultan mengeksplorasi arsitektur sistem yang akan dibuat
beradasarkan kartu tersebut, dengan membangun prototipe pertama sistem.
2. Planning Phase
Tahap perencanaan mengutamakan kebutuhan pengguna dan kesepakatan terhadap
konten yang telah dilakukan di tahap rilis pertama tadi. Programmer akan mengestimasi
upaya yang akan dilakukan untuk membuat fitur-fitur yang dibutuhkan dan membuat
jadwal kemajuan (progress) kerja.
3. Iteration to Release Phase
Tahap Iteration to release mencakup beberapa iterasi kecil ke sistem sebelum rilis
pertama dari sistem. Jadwal yang dibuat dalam tahap perencanaan dipecah menjadi
beberapa iterasi kecil dengan durasi antara 1 hingga 4 minggu. Arsitektur keseluruhan
sistem dibangun pada iterasi pertama. Kebutuhan pengguna yang relevan diprioritaskan
dan dipilih dan dimasukkan dalam urutan kerja. Fitur yang akan dibuat kemudian
dipilih oleh pengguna berdasarkan kebutuhannya. Pada akhir iterasi terakhir, sistem
siap diproduksi. Pengujian terhadap fungsional sistem dilakukan pada akhir iterasi.
4. Productionizing Phase

8
 Tahap Productinizing melibatkan pengecekan performansi sistem dan pengujian
tambahan sistem, sebelum sistem dirilis ke pengguna. Perubahan-perubahan yang
terjadi pada sistem dapat dideteksi pada fase ini dan keputusan harus dibuat jika fitur
tersebut akan dimasukkan pada rilis ini. Ide-ide yang tertunda akan dilaksanakan pada
fase berikutnya dan akan terus didokumentasikan.
Setelah produk dirilis ke pengguna, sangat penting untuk menjaga agar sistem tetap
berjalan dan mencari iterasi baru. Pemeliharaan sistem dilakukan pada fase
maintenance. Iterasi baru diidentifikasi dari aktivitas-aktivitas dukungan terhadap
pelanggan. Hal ini dapat mengakibatkan melambatnya kecepatan untuk
mengembangkan sistem, sehingga dibutuhkan restrukturisasi dan penambahan tim.
5. Maintenance Phase
Fase Pemeliharaan adalah tahap normal proyek karena harus berkembang dari tahun
ke tahun.
6. Fase Death
Fase death dimulai ketika pengguna tidak lagi membutuhkan penambahan fitur. Ini
berarti bahwa sistem yang dikembangkan memenuhi kebutuhan pelanggan dan aspek-
aspek lain seperti kinerja dan kehandalan. Fase ini merupakan fase penutupan siklus
hidup proyek, dan diperlukan dokumentasi terhadap sistem yang telah dibuat.
2.5 Kelebihan dan Kelemahan Extreme Programming
1. Berikut ini adalah kelebihan dari Extreme Programming:
a. Menjalin komunikasi yang baik dengan klien. (Planning Phase)
b. Menurunkan biaya pengembangan (Implementation Phase)
c. Meningkatkan komunikasi dan sifat saling menghargai antar developer.
(Implementation Phase)
d. Extreme Programming merupkan metodologi yang semi formal.
(Planning Developer harus selalu siap dengan perubahan karena perubahan akan
selalu diterima, atau dengan kata lain eksibel. (Maintenance Phase)
2. Berikut ini adalah kelemahan dari Extreme Programming:
a. Developer harus selalu siap dengan perubahan karena perubahan akan selalu
diterima.

9
 b. Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran
untuk melakukan apa yang diperlukan hari itu juga).

Selain dari keunggulan dan kelemahan Extreme Programming yang telah disebutkan
diatas, Extreme Programming juga memiliki keunggulan yang sekaligus menjadi
kelemahannya, yaitu Extreme Programming tidak memiliki dokumentasi formal yang dibuat
selama pengembangan. Satu-satunya dokumentasi adalah dokumentasi awal yang dilakukan
oleh user.

10
 BAB III

PEMBAHASAN

3.1 Pengertian Extreme Programming

Extreme Programming (XP) merupakan salah satu metodologi dalam rekayasa

perangkat lunak dan juga merupakan satu dari beberapa agile software development
methodologies yang berfokus pada coding sebagai aktivitas utama di semua tahap pada
siklus pengembangan perangkat lunak (software development lifecycle). Metodologi ini
mengedepankan proses pengembangan yang lebih responsive terhadap kebutuhan
customer (”agile”) dibandingkan dengan metode-metode tradisional sambil membangun
suatu software dengan kualitas yang lebih baik.

Terdapat empat prinsip dalam Extreme Programming. Prinsip-prinsip ini

digunakan untuk menentukan apa/bagaimana tindakan yang telah dilakukan akan sukses
atau sebaliknya (sesuai dengan alur Extreme Programming). Empat karakteristik itu
diantaranya :

1. Komunikasi (Communication)
Tugas utama developer dalam membangun suatu sistem perangkat lunak adalah
mengkomunikasikan kebutuhan sistem kepada pengembang perangkat lunak.
Komunikasi dalam Extreme Programming (XP) dibangun dengan melakukan
pemrograman berpasangan (pair programming). Developer didampingi oleh pihak
klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung
dalam pemrograman sambil berkomunikasi dengan developer. Tujuannya untuk
memberikan pandangan pengembang sesuai dengan pandangan pengguna sistem.
2. Kesederhanaan (Simplicity)
Extreme Programming (XP) mencoba untuk mencari solusi paling sederhana dan
praktis. Perbedaan metode ini dengan metodologi pengembangan sistem konvensional
lainnya terletak pada proses desain dan coding yang terfokus pada kebutuhan saat ini
daripada kebutuhan besok, seminggu lagi atau sebulan lagi. Lebih baik melakukan hal
yang sederhana dan mengembangkannya besok jika diperlukan.

11
 3. Umpan balik (Feedback)
Hal ini diperlukan untuk mengetahui kemajuan dari proses dan kualitas dari aplikasi
yang dibangun. Informasi ini harus dikumpulkan setiap interval waktu yang singkat
secara konsisten. Ini dimaksudkan agar hal-hal yang menjadi masalah dalam proses
pengembangan dapat diketahui sedini mungkin. Setiap feed back ditanggapi dengan
melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan
membengkak (uang, tenaga, waktu).
4. Keberanian (Courage)
Berani mencoba ide baru. Berani mengerjakan kembali dan setiap kali kesalahan
ditemukan, langsung diperbaiki. Contoh dari courage adalah komitmen untuk selalu
melakukan design dan coding untuk saat ini dan bukan untuk esok. Ketika ada kode
yang terlalu rumit, sulit dibaca dan dipahami, tidak sesuai dengan kemauan pelanggan,
dll maka seharusnya kode program seperti itu di refactor (kalau perlu dibangun ulang).
Hal ini menjadikan pengembang merasa nyaman dengan refactoring program ketika
diperlukan.
5. Menghormati (Respect)
Pentingnya respect terhadap anggota team lainnya karena dengan siklus pendek dan
integrasi continue, programmer tidak boleh melakukan perubahan yang dapat merusak
kompilasi dan menyebabkan keberadaan unit uji gagal atau memperlambat kerja team.
Respects tiap individu akan selalu menghasilkan kualitas tinggi.
3.2 Penerapan Extreme Programming
Beberapa hal yang harus dipertimbangkan sebelum seseorang masuk dalam dunia Extreme
Programming (XP) adalah sebagai berikut:
1. User harus memahami konteks bisnis yang akan dikembangkan sistemnya, sehingga
developer dapat menangkap sistem secara aplikatif dan dapat mengusulkan teknologi
apa yang dapat dikembangkan dalam sistem barunya.
2. Akan lebih efektif apabila developer pernah menangani proyek pengembangan sistem
yang sejenis sehingga dapat memberikan usulan model sistem baru, di samping alasan
bahwa developer telah memiliki template aplikasi sistem tersebut untuk dijadikan
prototype sistem baru. Hal ini akan berimplikasi kepada kemudahan dalam konstruksi
sistem karena dikembangkan berdasarkan template yang sudah ada.

12
 3. Extreme Programming (XP) menuntut komunikasi antar developer dan user secara
intensif dan komunikasi internal antar developer secara komprehensif, sehingga akan
lebih representatif apabila tahap pengembangan sistem dilakukan di lokal yang
mendukung proses komunikasi tersebut.
3.3 Aspek Dasar Extreme Programming

Aspek dasar Extreme Programming (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 Extreme Programming (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 Extreme Programming (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 Extreme Programming (XP).
Setiap developer menyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil
tersebut harus segera dipresentasikan dan didiskusikan dengan klien. Jika memungkinkan

13
 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 Extreme Programming (XP).
Pada Extreme Programming (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 Extreme Programming (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 Extreme Programming (XP) karena Refactoring
mengusung konsep penyederhanaan dari proses desain maupun struktur baris kode
program. Dengan Refactoring tim pengembang dapat melakukan berbagai usaha untuk

14
 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
Extreme Programming (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
Extreme Programming (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 Extreme
Programming (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 Extreme Programming (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.
Extreme Programming (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

15
 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 Extreme Programming (XP) hal tersebut adalah
maksimum. Pada Extreme Programming (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 Extreme Programming (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.

3.4 Cara Kerja Extreme Programming

16
Berikut ini adalah blok diagram dan penjelasan cara kerja dari Extreme Programming:

1. Perencanaan Extreme Programming (XP)

Pengumpulan user stories dari klien yang klien tetapkan prioritasnya. Setiap story
ditetapkan harga dan lama pembangunan, jika terlalu besar, story dapat dipecah menjadi
beberapa story yang lebih kecil. Periksa dan pertimbangkan resiko.
2. Desain Extreme Programming (XP)
Dalam desain Extreme Programming (XP) berprinsip sederhana yaitu memanfaatkan kartu
CRC (Class-Responsibility-Collaborator) untuk identifikasi dan mengatur class-class di
konsep OO. Jika temui kesulitan, prototype dibangun (ini namanya spike solution).
Lakukan refactoring, yaitu mengembangkan desain dari program setelah ditulis.
3. Pengkodean Extreme Programming (XP)

Siapkan unit test sebelum pengkodean dipakai sebagai fokus pemrogram untuk membuat
program. Pair programming dilakukan untuk real time program solving dan real time
quality assurance

4. Pengujian Extreme Programming (XP)

Dalam pengujian Extreme Programming (XP) yaitu menggunakan unit test yang
dipersiapkan sebelum pengkodean.

3.5 Proses Pembuatan Aplikasi dengan Metodelogi Extreme Programming

Penerapan Extreme Programming Pada Perusahaan

17
PT. Yubi Citra Karyadikara.

Jenis penelitian yang akan digunakan dalam penelitian ini adalah deskriptif dan metode
penelitiannya adalah studi kasus dan survey yang menganalisis tentang perencanaan bahan baku
material dengan menggunakan metode Material Requirement Planning (MRP) serta unit
analisisnya adalah PT. Yubi Citra Karyadikara. Pro l Perusahaan PT. Yubi Citra Karyadikara
adalah perusanaan industri swasta yang bergerak dalam bidang industri mebel yaitu memproduksi
o rice chairs atau kursi _ kursi kantor yang memiliki pabrik berlokasi di jalan peternakan II no.15,
Kapuk Jagal jakarta 11720 dan letak kantornya di jalan tanjung duren barat 1 no.31. Ditinjau dari
segi hukum PT. Yubi Citra Karyadikara telah berdiri sejak tahun 1989 dengan no SIUP
7237/09.03/PM/VIII/1991. Perusahaan ini sudah berjalan selama 18 tahun, dengan modal awal
adalah sebesar Rp 300.000.000. Perusahaan sebelumnya tidak hanya di bidang industri o rice
chairs saja, tetapi memproduksi mebel lainnya seperti lemari, meja meja tetapi karena produk
tersebut kurang diminati oleh pelanggan, maka perusahaan hanya menciptakan kursi kursi kantor,
karena perusahaan bekerja sama dengan beberapa kantor juga, sehingga sudah memilki pelanggan
tetap. Banyak perkembangan dalam perusahaan ini, perusahaan terus menciptakan produk produk
baru, sehingga perusahaan memiliki banyak sekali jenis dan model kursi- kursi dengan fungsinya
yang berbeda. PT. Yubi Citra Karyadikara banyak memproduksi kursi-kursi kantor yang
mempunyai tipe dan model pilihan yaitu sta chair, secretary chair, executive secretary chair, bar
chair, manager chair, executive manager chair, director chair, executive director chair, meeting
chair, salon chair dan visitor chair. Dalam Master Production Schedule ini menyatakan bahwa
adanya pesanan untuk produk kursi OX 830 secara keseluruhan adalah sebanyak 950 unit kursi,
untuk memproduksi kursi tersebut memerlukan waktu 10 menit per-unit. Kursi yang sudah
diproduksi harus di proses lebih lanjut ke dalam proses nishing yang memerlukan waktu 2 menit
Iamanya dan proses nishing ini akan dimulai di menit ke-8 dan selesai pada menit ke-10. Jika
perusahaan menerima banyak pesanan maka perusahaan akan menambah waktu lembur. Biasanya
dalam sehari perusahaan bisa memproduksi sebanyak 60 - 80 unit, tetapi jika menambah waktu
lembur maka dalam sehari perusahaan bisa memproduksi sebanyak 100-120 unit. Secara garis
besar penambahan fase requirements management pada eXtreme Programming sangat membantu
untuk lebih menstrukturkan metode ini. Requirements Management yang disisipkan terutama
difokuskan dalam hal dokumentasi. Pendokumentasian pada eXtreme Programming ini tidak akan
mengganggu proses secara keseluruhan karena dilaksanakan secara paralel dengan planning phase.
Hasil pengukuran yang dilaksanakan terhadap penambahan fase requirements management yang
paralel dengan planning phase pada siklus hidup eXtreme Programming menunjukkan bahwa
metodologi ini tetap pada posisi agile. Pengukuran yang dilakukan dengan menggunakan statistik
yaitu dengan menilai indikator-indikator agile-nya yang kemudian diklasikasikan dengan
menggunakan distribusi normal memperoleh empat klasifikasi. Klasifikasi itu adalah A untuk
posisi sangat agile, B untuk posisi agile, C untuk posisi cukup agile, dan D untuk posisi tidak agile.
Setelah pengukuran, penambahan fase ini menunjukkan berada pada posisi B. Dengan hasil
tersebut berarti penambahan fase requirements management tidak menjadikan eXtreme
Programming keluar dari metodologi Agile. Mempunyai RE yang bagus adalah penting karena

18
dampaknya mampu mengurangi biaya proyek, dan diterimanya sistem oleh stakeholder sehingga
bisa mengarah kepada keuntungan yang tinggi. Namun juga harus diakui dibutuhkan tenaga dan
waktu yang tidak sedikit untuk berinvestasi dalam pembuatan requirement yang benar-benar
bagus. Untuk mendapatkan requirement yang bagus, ada banyak pekerjaan/tasks harus dilakukan,
untuk itu tim RE tidak hanya bekerja pada awal dari proyek namun bekerja melalui tahap
pengembangan sampai tahap delivery untuk memastikan requirement benar-benar sesuai. Dengan
dilakukannya penelitian mengenai penerapan metode Material Ruirement Planning dalam
perencanaan kebutuhan material kursi OX 830 pada PT. Yubi Citra Karyadikara maka dapat
disimpulkan bahwa :

1. Dalam memenuhi pesanan pelanggan akan permintaan produkJcursi OX 830 sebanyak

950 unit ,maka PT. Yubi Citra Karyadikara memerlukan komponen komponen sebagai
berikut, komponenpapan dudukan sebanyak 950 unit, papan senderan sebanyak 950
unit, kaki cakar lima sebanyak 950 unit, busa atau foam dudukan sebanyak 950 unit,
seat mechanis sebanyak 950 unit, busa atau foam senderan sebanyak 950 unit, kote kote
sebanyak 950 unit, roda castor sebanyak 4750 unit, gas lift atau hydraulic sebanyak 950
unit, kain alabama sebanyak 1900 unit, dan list karet sebanyak 1900 unit.

2. Dalam memproduksi seluruh pesanan pelanggan akan permintaan kursi OX 830

sebanyak 950 unit maka setelah diperhitungkan biaya biaya yang akan dikeluarkan oleh
perusahaan dibagi menjadi 2 yaitu total biaya material berdasarkan perencanaan
kebutuhan material (MRP) yaitu sebesar Rp 298.775.000 dan total biaya material
berdasarkan analisis sistem berjalan yaitu s.'-tesar Rp 302.899.994. Jadi dapat
disimpulkan bahwa untuk memproduksi pesanan kursi OX 830 sebanyak 950 unit
sebaiknya perusahaan menerapkan sistem Material Reqiurement Planning (MRP)
karena total biaya material yang dikeluarkan perusahaan lebih minimal sehingga biaya
biaya yang dikeluarkan untuk memproduksi oleh perusahaan tidak besar dan
memberikan keuntungan bagi perusahaan.

Beta Mart.

Profil l: perusahaan

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

19
sebagai staf warehouse (gudang). Sedangkan di toko itu sendiri terdapat 4 pramuniaga toko untuk
membantu pembeli yang bekerja secara shift.

Proses:

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.

Penerapan Aplikasi Dengan Extreme Programming.

(1) Planning

20
* Use Case Diagram

21
Transaksi Member

Transaksi Pembayaran

22
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.

23
1. Login

2. Pelanggan

24
3.Input Data Pelanggan

4.Pencarian Data Pelanggan

25
5.Transaksi pembayaran

26
6. Incremental Release

Setelah melalui unit testing akan dilakukan incremental release, yaitu release software secara
bertahap.

Release Texts :

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

-Au-tomated 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

27
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)

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

6. Verifikasi Dan Validasi

LOGIN:

· Tujuan yang ingin dicapai : User dapat melakukan login sesuai dengan
autorisasinya.

· Data Test > > Data Login :

- Username : C31198

28
- Password : *******

· Skenario :

- User mengisikan username & password

- User menekan button Login

- Apabila terjadi kesalahan penulisan, user dapat menekan button Reset dan eld username &
password akan kembali kosong pabila terjadi kesalahan username atau password

· Hasil yang diharapkan :

- User dapat masuk ke dalam sistem

· Hasil yang diperoleh : 1

· Status : Ok

PRE: TRANSACTION

· Tujuan yang ingin dicapai : user dapat memilih jenis transaksi (member atau non
member) dan mencari data pelanggan

· Data Test > > Data Input :

-Member Code : M121

-Name : Rino Andriya (manual or automatic lled)

-Address : Karang Menur I No. 10 (automatic lled)

-Deposit : Rp 750.000, 00 (automatic lled)

-Last Transaction : 10 May 2009 (automatic lled)

· Skenario :

-User mengisikan member code

-Data lainnya (name, address, deposit, last transaction) akan muncul secara otomatis

-User dapat menggunakan metode lain dengan mengisikan name

-Data lainnya (member code, address, deposit, last transaction) akan muncul secara otomatis

-Untuk nama yang similar, user dapat menekan button > > dan < <

29
-Setelah data member sesuai, user dapat menekan button Next

-Untuk member baru, user dapat menekan button Register

-Untuk nonmember, user dapat menekan button Non Member

· Hasil yang diharapkan :

- Jenis transaksi (member/non member) dapat diidenti kasi dan data member dapat ditampilkan.

· Hasil yang diperoleh : 1

· Status : OK

MEMBER: REGISTRATION

· Tujuan yang ingin dicapai :

- user dapat mendata member baru atau mengubah data member

· Data Test > > Data Input :

- Member Code : M203 (automatic generated)

- Name : Samantha Rosalia (manual lled)

- Address : Gajahmada I No. 30 (manual lled)

- Phone No. : +62812339876087

- Deposit : Rp 500.000, 00 (manual lled)

· Skenario :

- User menginput data member seperti nama, alamat, no. telp, dan jumlah deposit awal

- User menekan button Save

- Untuk mengubah data member, user dapat menekan button Edit dan menekan button Save
setelah melakukan perubahan

· Hasil yang diharapkan :

- Member baru dapat atau perubahan data member dapat tercatat pada system.

· Hasil yang diperoleh : 1

30
· Status : OK

TRANSACTION:

· Tujuan yang ingin dicapai : user dapat mencatat transaksi yang dilakukan
pelanggan

· Data Test > > Data Input :

- Cashier : Ranie (Automatic lled from login data)

- Member Code : M121 (automatic lled from )

- Item Code : S141

- Discount : 10%

· Skenario :

- User menginput item code & quantity, lalu menekan button Insert (bisa dilakukan
denganbarcode)

- User dapat menginput data barang berdasar nama, dengan memasukkan nama barang pada

- Textbox Search lalu menekan button Search

- Field discount akan otomatis terisi apabila pelanggan adalah member Betamart

- Field total akan otomatis terisi (automatic calculate)

- Untuk barang yang tidak jadi dibeli, user dapat menekan button Cancel: untuk mengeluarkan
barang tersebut dari list.

- Apabila pencatatan transaksi sudah selesai, user dapat menekan button OK untuk mencetak
struk sekaligus menyimpan data transaksi pada database.

- Untuk membatalkan transaksi dan kembali ke halaman sebelumnya, user dapat menekan button
Cancel

Untuk mengosongkan eld, user dapat menekan tombol Reset

· Hasil yang diharapkan :

- transaksi dapat tercatat pada system dan pencetakan struk dapat dilakukan

· Hasil yang diperoleh : 1

31
· Status : OK

BAB IV

PENUTUP

4.1 Kesimpulan
Extreme Programming adalah salah satu dari beberapa Proses Agile populer. Sudah
terbukti sangat sukses di banyak perusahaan dari berbagai ukuran dan industri di seluruh
dunia.Extreme Pemrograman berhasil karena menekankan kepuasan pelanggan. Alih-alih
memberikan semua yang anda mungkin inginkan pada tanggal beberapa jauh di masa depan
proses ini memberikan perangkat lunak yang Anda butuhkan saat Anda membutuhkannya.
Extreme Pemrograman memberdayakan pengembang Anda untuk percaya diri menanggapi
perubahan kebutuhan pelanggan, bahkan terlambat dalam siklus hidup.Extreme Pemrograman
menekankan kerja sama tim. Pengelola, pelanggan, dan pengembang semua mitra setara dalam
sebuah tim kolaboratif. Extreme Pemrograman menerapkan, sederhana namun efektif yang
memungkinkan tim lingkungan menjadi sangat produktif.

4.2 Saran

User harus memahami konteks bisnis yang akan dikembangkan sistemnya, sehingga
developer dapat menangkap sistem secara aplikatif dan dapat mengusulkan teknologi apa yang
dapat dikembangkan dalam sistem barunya.

· Akan lebih efektif apabila developer pernah menangani proyek pengembangan sistem yang
sejenis sehingga dapat memberikan usulan model sistem baru, di samping alasan bahwa developer
telah memiliki template aplikasi sistem tersebut untuk dijadikan prototype sistem baru.

32
 DAFTAR PUSTAKA

http://www.docstoc.com/docs/78775507/Extreme-Programming---DOC (diakses pada tanggal

20 November 2018 pukul 15.00 WIB)

http://ruangketjil.wordpress.com/2009/12/22/teknik-testing-menggunakan-junit-pada-extreme-
programming/ (diakses pada tanggal 20 November 2018 pukul 15.10 WIB)

http://itcompro.wordpress.com/2009/09/07/xp/(diakses pada tanggal 20 November 2018 pukul

15.30 WIB)

http://cmasyta.files.wordpress.com/2007/09/extremeprogramming.gif (diakses pada tanggal 20

November 2018 pukul 19.00 WIB)

33