Anda di halaman 1dari 17

Tugas Kelompok

Makassar, 04 Mei 2016

REKAYASA PERANGKAT LUNAK+PROJECT BASE


METHODOLOGY PERANGKAT LUNAK
(PURNAWANSYAH, S.KOM,M.KOM)

SITI HARTINA

13020140198

AISYAH HAIRUNNISA

13020140179

SEPTIKA NURPIANI

13020140190
B2

PROGRAM STUDI TEKNIK INFORMATIKA


FAKULTAS ILMU KOMPUTER
UNIVRSITAS MUSLIM INDONESIA
MAKASSAR
2016

1. Metode Waterfall
1.1 Pengertian Metode Waterfall
Menurut Pressman (2010), model waterfall adalah model klasik
yang bersifat sistematis, berurutan dalam membangun software. Nama
model ini sebenarnya adalah Linear Sequential Model. Model ini
sering disebut dengan classic life cycle atau model waterfall. Model
ini termasuk kedalam model generic pada rekayasa perangkat lunak
dan pertama kali diperkenalkan oleh Winston Royce sekitar tahun 1970
sehingga sering dianggap kuno, tetapi merupakan model yang paling
banyak dipakai didalam Software Engineering (SE). Model ini
melakukan pendekatan secara sistematis dan berurutan. Disebut
dengan waterfall karena tahap demi tahap yang dilalui harus
menunggu selesainya tahap sebelumnya dan berjalan berurutan.
Waterfall adalah suatu metodologi pengembangan perangkat lunak
yang mengusulkan pendekatan kepada perangkat lunak sistematik dan
sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh
analisis, design, kode, pengujian dan pemeliharaan.
1.2 Tahapan Metode Waterfall
Langkah-langkah yang harus dilakukan pada metodologi Waterfall
adalah sebagai berikut :
A. Analisis kebutuhan perangkat lunak
Proses pengumpulan kebutuhan

diintensifkan

dan

difokuskan, khususnya pada perangkat lunak. Untuk memahami


sifat program yang dibangun, rekayasa perangkat lunak (analisis)
harus memahami domain informasi, tingkah laku, unjuk kerja dan
antar muka (interface) yang diperlukan. Kebutuhan baik untuk
sistem maupun perangkat lunak di dokumentasikan dan dilihat
dengan pelanggan.
Mengumpulkan kebutuhan secara lengkap kemudian
dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh
software yang akan dibangun. Hal ini sangat penting, mengingat
software harus dapat berinteraksi dengan elemen-elemen yang lain

seperti hardware, database, dsb. Tahap ini sering disebut dengan


Project Definition.
B. Desain
Desain perangkat lunak sebenarnya adalah proses multi
langka yang berfokus pada empat atribut sebuah program yang
berbeda; struktur data, asitektur perangkat lunak, representasi
interface dan detail (algoritma) prosedural.

Proses desain

menerjemahkan syarat/kebutuhan kedalam sebuah representasi


perangkat lunak yang dapat di perkirakan demi kualitas sebelum
dimulai pemunculan kode. Sebagaimana persyaratan, desain
didokumentasikan dan menjadi bagian dari konfigurasi perangkat
lunak.
Proses pencarian kebutuhan diintensifkan dan difokuskan
pada software. Untuk mengetahui sifat dari program yang akan
dibuat, maka para software engineer harus mengerti tentang
domain informasi dari software, misalnya fungsi yang dibutuhkan,
user interface, dsb. Dari dua aktivitas tersebut (pencarian
kebutuhan sistem dan software) harus didokumentasikan dan
ditunjukkan kepada user. Proses software design untuk mengubah
kebutuhan-kebutuhan di atas menjadi representasi ke dalam bentuk
"blueprint" software sebelum coding dimulai. Desain harus dapat
mengimplementasikan kebutuhan yang telah disebutkan pada tahap
sebelumnya. seperti dua aktivitas sebelumnya, maka proses ini juga
harus didokumentasikan sebagai konfigurasi dari software.
C. Generasi Kode
Desain harus diterjemahkan dalam bentuk mesin yang bisa
di baca. Langkah pembuatan kode melakukan tugas ini. Jika desain
dilakukan dengan cara yang lengkap, pembuatan kode dapat
diselesaikan secara mekanis.
Untuk dapat dimengerti oleh mesin, dalam hal ini adalah
komputer, maka desain tadi harus diubah bentuknya menjadi

bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa


pemrograman melalui proses coding. Tahap ini merupakan
implementasi dari

tahap design yang secara teknis nantinya

dikerjakan oleh programmer.


D. Pengujian
Proses Pengujian dilakukan pada logika internal untuk
memastikan semua pernyataan sudah diuji. Pengujian eksternal
fungsional

untuk

menemukan

kesalahan-kesalahan

dan

memastikan bahwa input akan memberikan hasil yang aktual


sesuai yang dibutuhkan.
E. Pemeliharaan
Perangkat lunak yang sudah disampaikan kepada pelanggan
pasti akan mengalami perubahan. Perubahan tersebut bisa karena
mengalami kesalahan karena perangkat lunak harus menyesuaikan
dengan lingkungan (periperal atau sistem operasi baru) baru, atau
karena pelanggan membutuhkan perkembangan fungsional atau
unjuk kerja.
Sesuatu yang dibuat haruslah diujicobakan. demikian juga
dengan

software.

Semua

fungsi-fungsi

software

harus

diujicobakan, agar software bebas dari error, dan hasilnya harus


benar-benar sesuai dengan kebutuhan yang sudah didefinisikan
sebelumnya.
Pemeliharaan suatu software diperlukan, termasuk di
dalamnya adalah pengembangan, karena software yangdibuat tidak
selamanya hanya seperti itu ketika dijalankan mungkin saja masih
ada error kecil yang tidak ditemukan sebelumnya atau ada
penambahan fitur-fitur yang belum ada pada software tersebut.
Pengembangan diperlukan ketika adanya perubahan dari eksternal
perusahaan seperti ketika ada pergantian sistem operasi, atau
perangkat lainnya.
1.3 Kelebihan dan Kekurangan
a. Kelebihan

Kelebihan

dari

model

ini

adalah

selain

karena

pengaplikasian menggunakan model ini mudah, kelebihan model


ini adalah ketika semua kebutuhan sistem dapat didefinisikan
secara utuh, eksplisit, dan benar di awal proyek, maka Software
Engineering(SE) dapat berjalan dengan baik dan tanpa masalah
meskipun seringkali kebutuhan sistem tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak, problem pada
kebutuhan sistem di awal proyek lebih ekonomis dalam hal uang
(lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika
dibandingkan problem yang muncul pada tahap-tahap selanjutnya.
b. Kekurangan
Kekurangan yang utama dari model ini adalah kesulitan
dalam mengakomodasi perubahan setelah proses dijalani. Fase
sebelumnya harus lengkap dan selesai sebelum mengerjakan fase
berikutnya.
1.4. Contoh Kasus
Masalah dengan waterfall :
a. Perubahan sulit dilakukan karena sifatnya yang kaku
b. Karena sifat kakunya, model ini cocok ketika kebutuhan
dikumpulkan secara lengkap sehingga perubahan bisa ditekan
sekecil mungkin. Tapi pada kenyataannya jarang sekali
konsumen/pengguna yang bisa memberikan kebutuhan secara
lengkap, perubahan kebutuhan adalah sesuatu yang wajar
terjadi.
c. Waterfall pada umumnya digunakan untuk rekayasa sistem
yang besar yaitu dengan proyek yang dikerjakan di beberapa
tempat berbeda, dan dibagi menjadi beberapa bagian subproyek.
Berikut ini gambaran dari waterfall model.
Fase-fase dalam model waterfall menurut referensi Sommerfille :

Metode Waterfall (Sommerfille, 2010)


Contoh Kasus:
John Chen adalah General Manager A Company, sebuah
perusahaan perkapalan yang berbasis di Singapura. Sebagai perusahaan
UKM muda yang terus berkembang, John Chen menginvestasikan
sebagian modal perusahaan untuk promosi di media cetak dan elektronik,
serta melatih kemampuan karyawan melalui berbagai kursus. Untuk
mendukung kerja karyawan, A Company menggunakan komputer dasar
(Basic PC) yang dilengkapi dengan office software. Seperti kebanyakan
UKM lainnya, A Company juga memiliki akses internet yang hanya dapat
digunakan secara terbatas di beberapa PC. A Company memiliki satu buah
email resmi yang masih menggunakan domain dari ISP (Internet Service
Provider).
Untuk komunikasi dilingkungan karyawan, mereka menggunakan
fasilitas email gratis yang banyak tersedia di internet. Email gratis ini
kadang juga digunakan untuk berkomunikasi dengan supplier dan
pelanggan. Sebagai perusahaan UKM yang terus berkembang cepat, John
Chen

mulai

berfikir

untuk

mengembangkan A Company lebih

professional. Harapan John Chen, calon pelanggan potensial, pelanggan,


supplier dan karyawan lebih mengenal A Company. Disisi lain, ia juga
berharap agar cara yang digunakan lebih efisien, hemat biaya, tetapi
menampilkan sosok perusahaan yang meyakinkan atau bonafit. John Chen
meyakini, bahwa berkomunikasi menggunakan alamat email atau domain
sendiri; promosi melalui website sendiri; data yang terintegrasi dan dapat

diakses disemua komputer perusahaan akan dapat membawa perusahaan


menjadi lebih profesional.
A Company tidak memiliki departemen khusus untuk menangani
TI. Untuk mewujudkan keinginannya, John Chen meminta bantuan
perusahaan khusus TI. Implementasi TI dikerjakan oleh perusahaan TI
(sebagai pemenang tender) dalam jangka waktu kontrak 1 tahun, Dalam
proses implementasi, John Chen menyerahkan tugas dan tanggung-jawab
kepada bawahannya. Semua karyawan dilibatkan dalam pertemuan dan
diskusi dengan perusahaan pembangun TI. Dari waktu kontrak 1 tahun
yang disepakati, TI yang bisa diimplementasikan adalah pembangunan
jaringan komputer, akses internet, email, dan pembangunan data terpusat.
Sedangkan untuk website belum bisa dikerjakan sepenuhnya karena
sebagian besar waktu yang tersedia habis digunakan untuk menyatukan
keinginan para pihak yang terkait dalam implementasi. Meskipun
demikian, sistem yang dibangun mulai dirasakan manfaatnya oleh A
Company. Komunikasi melalui email mulai dapat dilakukan karyawan
dengan supplier dan pelanggan. Pengambilan keputusan sudah mulai bisa
dilakukan dengan cepat karena data yang diperlukan sudah terpusat. John
Chen juga merasakan terjadinya penghematan dalam penggunaan kertas
dan alat tulis, karena perusahaan mulai menerapkan e-document.
Namun demikian, kepuasan John Chen tidak bertahan lama, karena
sistem TI mulai menimbulkan masalah. Hal itu misalnya terjadi pada email
yang mengalami over quota dan dibanjiri virus, sehingga komunikasi
perusahaan dengan pelanggan menjadi terputus dan komputer perusahaan
menjadi rusak.Hal yang terjadi tidak hanya membuat kerjaan perusahaan
menjadi terganggu, tetapi berbagai peluang bisnis menjadi hilang. Citra
perusahaan dimana supplier dan pelanggan menjadi berubah dan A
Company harus menanggung kerugian investasi. John Chen baru
menyadari bahwa implementasi TI yang dilakukan belum memberikan
hasil positif secara keseluruhan kepada perusahaannya. Ditambah lagi ia
harus menyiapkan budget tambahan untuk memperbaiki sistem jaringan
yang rusak. Kekecewaan John Chen bertambah ketika budget yang

diusulkan dalam proposal implementasi tidak termasuk biaya perawatan.


John Chen akhirnya memutuskan untuk menghentikan proyek pengerjaan
website, karena TI yang sudah diimplementasikan merugikan perusahaan
dan menghabiskan budget yang sudah dialokasikan sebelum keseluruhan
proyek selesai
sistem

informasi

dilaksanakan. Secara umum tujuan pengembangan


adalah

untuk

memberikan

kemudahan

dalam

penyimpanan informasi, mengurangi biaya dan menghemat waktu,


meningkatkan pengendalian, mendorong pertumbuhan, meningkatkan
produktifitas serta profitabilitas organisasi. Dalam beberapa tahun terakhir
ini

peningkatan

produktifitas

organisasi

ini

dibantu

dengan

berkembangnya teknologi komputer baik hardware maupun softwarenya.


Tetapi tidak semua kebutuhan sistem informasi dengan komputer
itu dapat memenuhi kebutuhan dan menyelesaikan masalah yang dihadapi
organisasi. Keterbatasan sumber daya dan anggaran pemeliharaan
memaksa para pengembang sistem informasi untuk menemukan jalan
untuk mengoptimalkan kinerja sumber

daya

yang

telah

ada.

Karakteristik dari suatu sistem informasi manajemen yang lengkap


tergantung dari masalah yang dihadapi, proses pengembangannya dan
tenaga kerja yang akan dikembangkannya. Seiring dengan perkembangan
permasalahan karena berubahnya lingkungan yang berdampak kepada
perusahaan maka yang menjadi parameter proses pengembangan sistem
informasi yaitu masalah yang dihadapi, sumber daya yang tersedia dan
perubahan, sehingga hasil pengembangan sistem informasi manajemen
baik yang diharapkan oleh perorangan maupun oleh organisasi turut
berubah. Perubahan tersebut pada akhirnya menimbulkan ketidakpastian
dan menambah kompleks/rumit masalah yang dihadapi oleh para analis
sistem informasi.
Metode tradisional seperti SDLC dianggap tidak lagi mampu
memenuhi tantangan perubahan dan kompleksnya masalah yang dihadapi
tersebut. Sekitar awal tahun delapan puluhan, para profesional dibidang
sistem informasi memperkenalkan satu metode pengembangan sistem
informasi baru, yang dikenal dengan nama metode prototyping. Metode

prototyping sebagai suatu paradigma baru dalam pengembangan sistem


informasi manajemen, tidak hanya sekedar suatu efolusi dari metode
pengembangan sistem informasi yang sudah ada, tetapi sekaligus
merupakan refolusi dalam pengembangan sistem informasi manajemen.
Metode ini dikjatakan refolusi karena merubah proses pengembangan
sistem informasi yang lama (SDLC).

2. Parallel Development
2.1 Pengertian
adalah proses di mana beberapa orang bekerja pada program
komputer atau proyek lain secara bersamaan.
Parallel Development Method adalah Suatu metode pengembangan
system yang

berdasarkan SDLC tradisional dan menyerupai SDLC.

Dalam pengembangan system yg pararel, fase desain dan implementasi


dibagi menjadi banyak salinan mengikuti fase analisis. Masing-masing
salinan melibatkan pengembangan sebuah subsistem atau subproyek
terpisahSemua salinan ini disatukan dalam fase implementasi tunggal
dimana sebuah integratorsistem memasang bagian-bagian secara bersamasama didalam sebuah system kohesif(padu. Semua ini dikembangkan
secara parallel.
2.2. Tahapan

2.3 Kelebihan dan Kekurangan


Parallel Development Methodology merupakan suatu cara pada
SDLC yang melakukan fase design dan implementation secara paralel.
1. Kelebihan dari Parallel Development Methodology adalah :
a. Meminimalisasi waktu penjadwalan
b. Meminimalisasi kesempatan untuk dikerjakan ulang
2. Kekurangan dari Parallel Development Methodology adalah :
a. Masih menggunakan dokument di kertas
b. Menggabungkan subproyek memerlukan suatu keahlian
yang khusus. Biasanya banyak terjadi kegagalan pada saat
proses penggabungannya
2.4 Contoh Kasus
Implementasi Parallel Development Methoad pada perangkat lunak
yang merupakan Software yang dikembangkan untuk menyelesaikan
system persamaan linear yang kaku.
3. Rapid
Merupakan model pengembangan system yang melakukan beberapa
penyesuaian terhadap SDLC pada beberapa bagian sehingga lebih cepat untuk
sampai ke tangan pengguna system. metodologi ini biasanya mensyaratkan
beberapa teknik dan alat-alat khusus agar proses bisa cepat, misalnya
melakukan sesi Joint Application Development (JAD), penggunaan alat-alat

Computer Aided Software Engineering (CASE Tools), kode generator dan


lain-lain.
Model RAD ini digambarkan pada gambar 2.2.2 sebagai berikut :
3.2 Berikut ini adalah penjelasan fase-fase dari model RAD (Rapid
Application Development)
1. Business modelling
Dalam fase ini RAD model mendefinisikan kebutuhan sistem. Fase
menjawab pertanyaan-pertanyaan sbb:
a. Informasi apa yang mengendalikan proses bisnis?
b. Informasi apa yang dihasilkan?
c.
Siapa yang menghasilkan informasi? Kemana informasi itu
diberikan?
d. Siapa yang mengolah informasi?
2. Data modeling
Pada data modeling RAD memodelkan aliran informasi yang sudah
didefinisikan, disusun menjadi sekumpulan objek data. Fase menyusun
aliran informasi yang sudah didefinisikan, menjadi sekumpulan objek data.
Pada fase ini pula ditentukan karakteristik/atribut dan hubungan antar
objek-objek tersebut.
3. Process Modelling
Objek data yang sudah didefinisikan diubah menjadi aliran informasi
yang diperlukan untuk menjalankan fungsifungsi bisnis.
4. Application Generation
RAD menggunakan component program yang sudah ada atau membuat
component yang bisa digunakan lagi, selama diperlukan.
5. Testing and Turnover
Karena menggunakan component yang sudah ada, maka kebanyakan
component sudah melalui uji atau testing. Namun component baru dan
interface harus tetap diuji.
RAD tidak cocok untuk proyek skala besar. Proyek bisa gagal karena
waktu yang disepakati tidak dipenuhi. Untuk Pembuatan sisstem yag tidak
dapat dimodularisasi tidak cocok untuk model ini. Sistem dengan resiko
teknis yang tinnggi juga kurang cocok untuk model ini.

3.3 Kelebihan dan Kekurangan


Berikut ini adalah keuntungan dan kelemahan dari model RAD :
1. Kelebihan :
a. RAD mengikuti tahapan pengembangan sistem sepeti umumnya,
tetapi mempunyai kemampuan untuk menggunakan kembali
komponen yang ada (reusable object).
b. Setiap fungsi dapat dimodulkan dalam waktu tertentu dan dapat
dibicarakan oleh tim RAD yang terpisah dan kemudian
diintegrasikan sehingga waktunya lebih efesien.
2. Kekurangan :
a. Tidak cocok untuk proyek skala besar.
b. Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi.
c. Sistem yang tidak bisa dimodularisasi tidak cocok untuk model
ini.
d. Resiko teknis yang tinggi juga kurang cocok untuk model ini.
3.4 Dalam penerapannya, RAD memiliki beberapa masalah, antara lain :
1. Tidak semua proyek bisa dipecah (dimodularisasi), sehingga belum
tentu RAD bisa dipakai pada semua proyek.
2. Karena proyek dipecah menjadi beberapa bagian, maka dibutuhkan
banyak orang untuk membentuk suatu tim yang mengerjakan tiap
bagian tersebut.
3. Membutuhkan komitmen antara pihak pengembang dan pelanggan.
RAD melibatkan user pada proses desain menyebabkan kebutuhan
user dapat terpenuhi dengan baik. RAD juga melibatkan user dalam
proses testing sehingga dapat memangkas proses development yang
panjang untuk dapat deliver on schedule.
4. Extreme Programming
4.1 Pengertian
Proyek Pemrograman Extreme pertama dimulai 6 Maret 1996. 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 Tahap
Dalam extreme programming menggambarkan empat kegiatan dasar yang
dilakukan dalam proses pengembanganperangkat lunak yaitu :
1. Coding: Pendukung XP berpendapat bahwa satu-satunya benar-benar
produk yang penting dari proses pengembangan sistem kode instruksi
perangkat lunak komputer dapat menafsirkan. Tanpa kode, tidak ada
produk kerja.Coding juga dapat digunakan untuk mengetahui solusi
yang paling cocok. Sebagai contoh, XP akan menganjurkan bahwa
dihadapkan dengan beberapa alternatif untuk masalah pemrograman,
satu kode hanya perlu semua solusi dan menentukan dengan tes yang
otomatis solusi yang paling sesuai. Coding juga dapat membantu untuk
mengkomunikasikan pikiran tentang masalah pemrograman. Seorang
pemrogram berurusan dengan masalah pemrograman yang kompleks
dan sulit untuk menjelaskan solusi untuk sesama programer mungkin
kode ini dan gunakan kode untuk menunjukkan apa yang dia berarti.
Kode, mengatakan para pendukung posisi ini, selalu jelas dan ringkas
dan tidak dapat ditafsirkan dengan lebih dari satu cara. Pemrogram lain
dapat memberikan umpan balik kode ini oleh juga pengkodean pikiran
mereka.
2. Pengujian: Satu tidak bisa memastikan bahwa fungsi bekerja kecuali
satu tes itu. Desain bug dan masalah kesalahan yang meresap dalam
pengembangan software. Extreme Programming Pendekatan adalah
bahwa jika sedikit pengujian dapat menghilangkan beberapa
kekurangan,

banyak

pengujian

dapat

menghilangkan

banyak

kelemahan. Unit tes menentukan apakah tur yang diberikan bekerja


sebagaimana dimaksud. Seorang pemrogram menulis sebagai banyak
tes otomatis mereka bisa memikirkan yang dapat memecahkan kode;

jika semua tes berjalan dengan sukses, maka pengkodean selesai.


Setiap potongan kode yang tertulis diuji sebelum pindah ke tur
berikutnya. * Tes Penerimaan memveri kasi bahwa persyaratan
sebagaimana yang dipahami oleh para programer memenuhi
persyaratan pelanggan yang sebenarnya. Ini terjadi pada tahap
eksplorasi perencanaan rilisSebuah testathon adalah sebuah peristiwa
ketika programmer bertemu untuk melakukan tes kolaboratif menulis,
semacam brainstorming relatif terhadap pengujian perangkat lunak.
3. Mendengarkan: Programmer harus mendengarkan apa yang pelanggan
membutuhkan sistem untuk melakukan, apa yang logika bisnis
diperlukan. Mereka harus memahami kebutuhan-kebutuhan ini cukup
baik untuk memberikan umpan balik pelanggan tentang aspek teknis
bagaimana masalah bisa dipecahkan, atau tidak dapat dipecahkan.
Pemahaman masalah nya. Komunikasi antara pelanggan dan
pemrogram adalah dibahas lebih lanjut dalam The Perencanaan Game.
4. Merancang: Dari sudut pandang kesederhanaan, orang bisa
mengatakan bahwa pengembangan sistem tidak membutuhkan lebih
dari coding, pengujian dan mendengarkan. Jika kegiatan tersebut
dilakukan dengan baik, hasilnya harus selalu menjadi sistem yang
bekerja. Dalam prakteknya, ini tidak akan bekerja. Satu dapat datang
jauh tanpa merancang tetapi pada waktu tertentu seorang pun akan
terjebak. Sistem menjadi terlalu kompleks dan dependensinya di dalam
sistem berhenti menjadi jelas. Satu dapat menghindari hal ini dengan
menciptakan sebuah desain struktur yang mengatur logika dalam
sistem. Desain yang baik akan menghindari banyak dependensi dalam
sistem ini berarti bahwa mengubah salah satu bagian dari sistem tidak
akan mempengaruhi bagian lain dari sistem.
4.3 Kelebihan dan Kekurangan
1. Kelebihan:
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. XP 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. Kelemahan :
a. 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 XP yang telah disebutkan
diatas, XP juga memiliki keunggulan yang sekaligus menjadi
kelemahannya, yaitu XP tidak memiliki dokumentasi formal yang
dibuat selama pengembangan. Satu-satunya dokumentasi adalah
dokumentasi awal yang dilakukan oleh user.
4.4 Contoh Kasus
Penerapan Extreme Programmning
Beberapa hal yang harus dipertimbangkan sebelum seseorang masuk dalam
dunia Extreme Programmning 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.
3. Extreme programming 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.
5. Scrum Metodologi
5.1 Pengertian

Scrum merupakan salah satu komponen dari metodologi pengembangan


Agile mengenai pertemuan harian untuk membahas kemajuan sedangkan XP
adalah menekankan metodologi yang berbeda yaitu ujian, pemrograman dan
pembangunan. Scrum menguraikan proses untuk mengidenti kasi dan
katalogisasi pekerjaan yang perlu dilakukan, memprioritaskan yang bekerja
dengan berkomunikasi dengan pelanggan atau wakil pelanggan, dan
pelaksanaanyang bekerja menggunakan rilis iterative dan memiliki tujuan
utama untuk mendapatkan perkiraan berapa lama akan pembangunan. XP
lebih lanjut tentang pengembang membantu menyelesaikan pekerjaan secepat
dan maintainably mungkin Scrum merupakan suatu kerangka kerja. Jadi,
bukannya menyediakan deskripsi rinci tentang bagaimana segala sesuatu
yang harus dilakukan pada proyek seperti diserahkan kepada tim
pengembangan perangkat lunak pada umumnya.
5.2 Tahap
1. Product owner mewakili suara customer dan bertanggungjawab terhadap
team yang akan mengimplementasi dari requirement ke implementasi.
Product owner biasanya menulis daftar fitur produk berdasarkan diskusi
dalam model user story dan memperioritaskan daftar fitur yang
dimasukkan kedalam product backlog. Satu team Scrum akan mempunyai
satu

product

owner

dan

juga

anggota

team

development.

Direkomendasikan bahwa role product owner tidak digabungkan dengan


role ScrumMaster.
2. ScrumMaster bertugas untuk membawa team dari hambatan-hambatan
dalam pengembangan produk. ScrumMaster bertanggungjawab atas
kemajuan pengembangan produk.
3. Team yang bertanggungjawab dalam realisasi produk jadinya. Biasanya
satu team terdiri sampai 5-9 orang dengan ketrampilan yang dimiliki
bervariasi yaitu analisa, desain, develop, test, technical communication
hingga dokumentasi. Setiap anggota team dituntut untuk bekerja sendiri
dan mengatur manajemen sendiri dalam koridor dalam satu team.
5.3 Kelebihan dan Kekurangan
1. Kelebihan:

a. Keperluan berubah dengan cepat


b. Tim berukuran kecil sehingga melancarkan komunikasi, mengurangi
biaya dan memberdayakan satu sama lain
c. Pekerjaan terbagi-bagi sehingga dapat diselesaikan dengan cepat
d. Dokumentasi dan pengujian terus menerus dilakukan setelah software
dibangun
e. Proses Scrum mampu menyatakan bahwa produk selesai kapanpun
diperlukan
2. Kekurangan:
a. Developer harus selalu siap dengan perubahan karena perubahan akan
selalu diterima.
5.4 Contoh Kasus
Proyek AdWords menggunakan Scrum dalam pengembangannya, dengan
memiliki tim yang disebar secara terdistribusi di lima lokasi dan menyatukan
secara virtual semua produk Google disetiap dilakukan perilisan. Dalam
perkembangannya, manajer dari proyek Google dibutuhkan untuk mengisi
beberapa struktur tim. Hadirnya manajer ini pada tim Scrum bertujuan untuk
membantu memberikan arahan untuk menyelesaikan prioritas

pekerjaan

yangtertinggi yang dirasa sulit diimplementasikan oleh tim. Dengan hal ini,
tim tidak lagi membutuhkan ScrumMaster, dikarenakan tim sudah dapat
berjalan dengan sendirinya