TUGAS

MEMBUAT PEPER TENTANG :

SOFTWARE DEVEFELOPMENT LIFT CYCLE

EXTRAME PROGRAMING

AGILE MODELING

DISUSUN OLEH :

M.HAMDAN.R

NIM 42316012

SAINS DAN TEKNOGI

UNIVERSITAS PERADABAN BUMIAYU

2018
 Abstract

Tujuan penulisan makalah ini adalah untuk membandingkan proses perangkat lunak Extreme
Programming dan Waterfall Modeling. Siklus Hidup Pengembangan Perangkat Lunak
(Software Development Life Cycle - SDLC) menjelaskan proses di mana perangkat lunak
komputer berubah dari konsepsi menjadi pengiriman dan seterusnya. Ada banyak model
proses yang merinci langkah-langkah dalam SDLC, masing-masing dengan kekuatan dan
kelemahan yang berbeda. Model berguna untuk menjelaskan, mengevaluasi, dan
mengeksplorasi berbagai proses yang digunakan tim untuk bergerak melalui SDLC. Extreme
Programming (XP) sangat berbeda dengan Waterfall. XP sendiri adalah kumpulan praktik
untuk Pengembangan Perangkat Lunak, beberapa di antaranya menciptakan proses
pengembangan yang sebanding dengan Air Terjun. Ini juga mengandung nilai-nilai dan
praktik terbaik untuk membantu dalam SDLC. Pada intinya adalah pendekatan multi-iteratif
dengan fokus pada apa yang diinginkan pelanggan [1]. Kata kunci: membandingkan, sdlc, xp,
proses
 PENDAHULUAN

1.1 Latar Belakang SDLC

Perkembangkan teknologi seperti sekarang ini sangat bermanfaat dan telah mengalami
perkembangan sangat pesat khususnya dalam bidang informatika. Dimana dengan
perkembangan ini, bidang informatika tidak lagi hanya menghasilkan pengembangan
program perangkat lunak saja, tetapi juga dapat menghasilkan pengembangan dalam bidang
permodelan yang bersifat komplek dan menyeluruh.
Pembuatan sebuah perangkat lunak yang baik haruslah memiliki teknik analisa kebutuhan
dan teknik permodelan yang baik pula. Hal tersebut dimaksudkan agar terwujudnya suatu
perangkat lunak yang baik dan bermanfaat. Dengan hal tersebut maka perlulah suatu
pengenalan mengenai permodelan dalam suatu pembangunan suatu Perangkat Lunak
(Software). Terdapat banyak permodelan mengenai pembangunan suatu Perangkat lunak
seperti SDLC.

Model waterfall dicetuskan pada tahun 1970 sebagai contoh metodologi pengembangan
perangkat lunak yang tidak bekerja secara baik [2]. Dokumen model waterfall, yang dibuat
oleh Winston W. Royce, yang terdiri dari dua kategori: satu dari model itu sendiri dan yang
kedua menggambarkan masalah utama yang melekat dalam model, atau alasan untuk tidak
menggunakan model waterfall. Mungkin tampak aneh, kemudian, bahwa model waterfall
menjadi salah satu metodologi pemrograman yang paling populer setelah publikasi dan tetap
seperti itu selama bertahun-tahun. Bahkan saat ini, menurut beberapa survei, model waterfall
digunakan oleh sebagian besar dunia rekayasa perangkat lunak [3]. Mengapa begitu banyak
perusahaan perangkat lunak masih menggunakan model waterfall untuk mengembangkan
perangkat lunak, terutama ketika berkembangnya agile sistem, seperti XP dan scrum, telah
menjadi "topik panas" dari komunitas rekayasa perangkat lunak untuk beberapa tahun ini?
Ada banyak alasan mengapa, tapi yang paling penting adalah daya tahan alami untuk
mengubah tradisi dan komplikasi dari isu tersebut. Dalam rekayasa perangkat lunak,
metodologi baru umumnya ditawarkan sebagai pembawa perbaikan yang murah pada waktu
untuk rilis, efisiensi, dan jumlah kesalahan per rilis. Tapi perbaikan setiap kata sangat berarti
bahwa harus ada sistem mapan atau badan hasil terhadap yang untuk membandingkan klaim
metodologi baru. Banyak kali, sistem dibandingkan pengembangan perangkat lunak adalah
model waterfall, dan perbaikan diukur terhadap keuntungan yang ada dan kerugian dari
model tersebut. Jadi, ketika mengusulkan sebuah sistem yang, misalnya, "lebih efisien" dan
menghasilkan lebih sedikit kesalahan per baris kode, seseorang harus menambahkan "dari
model waterfall" atau sesuatu yang lebih generik, seperti "daripada metode sebelumnya
digunakan perangkat lunak pembangunan "untuk memungkinkan klaim kepercayaan. Untuk
membuat motif untuk kepentingan kita dalam berapa banyak pengembang menggunakan
model waterfall dibandingkan pemrograman ekstrim, kita harus menetapkan bahwa ada
beberapa alasan untuk mengharapkan pengembang untuk memilih satu atau yang lain.
Manfaat lebih gesit model waterfall di berbagai daerah dari proses pengembangan perangkat
lunak dasar yang cukup untuk menjamin kepentingan.
1.3. ASAL EXTREME PROGRAMMING

Sebagian besar pengembangan perangkat lunak pada 1990-an dibentuk oleh dua pengaruh
utama: internal, pemrograman berorientasi objek pemrograman prosedural digantikan sebagai
paradigma pemrograman yang disukai oleh beberapa orang dalam industri; eksternal,
munculnya internet dan booming dot-com-untuk menekankan kecepatan pasar dan
perusahaan-pertumbuhan sebagai faktor bisnis kompetitif. Persyaratan berubah dengan cepat
menuntut lebih pendek siklus hidup produk, dan sering tidak sesuai dengan metode
tradisional pengembangan perangkat lunak. Chrysler Menyeluruh Sistem Kompensasi
dimulai dalam rangka untuk menentukan cara terbaik untuk menggunakan teknologi obyek,
dengan menggunakan sistem penggajian di Chrysler sebagai objek penelitian, dengan sebagai
bahasa Smalltalk dan batu permata sebagai lapisan akses data. Mereka dibawa di Kent Beck,
Smalltalk praktisi terkemuka, untuk melakukan kinerja tuning pada sistem, tetapi perannya
diperluas ketika ia melihat adanya beberapa persoalan yang mereka hadapi dengan proses
pembangunan mereka. Dia mengambil kesempatan ini untuk mengusulkan dan
mengimplementasikan beberapa perubahan dalam praktik mereka didasarkan pada sering
bekerja dengan kolaborator, Ward Cunningham. Pertama kali saya diminta untuk memimpin
sebuah tim, saya meminta mereka untuk melakukan sedikit hal yang saya pikir itu masuk
akal, seperti pengujian dan ulasan. Kedua kali ada lebih banyak di telepon. Saya pikir, Sialan
torpedo, setidaknya ini akan membuat artikel yang baik, dan meminta tim untuk
mendongkrak semua tombol-tombol untuk 10 pada hal-hal yang saya pikir sangat penting dan
meninggalkan segala sesuatu yang lain. -Kent Beck Ron Je ries Beck diundang ke proyek
untuk membantu mengembangkan dan memperbaiki metode ini. Je ries kemudian bertindak
sebagai pelatih untuk menanamkan praktek-praktek sebagai kebiasaan dalam tim C3.
Informasi tentang prinsip-prinsip dan praktek-praktek di belakang XP ini disebarluaskan ke
dunia yang lebih uas melalui diskusi di Wiki asli, WikiWikiWeb Cunningham. Berbagai
kontributor dibahas dan dikembangkan atas ide-ide, dan beberapa spin-o metodologi yang
mengakibatkan (lihat gesit pengembangan perangkat unak). Selain itu, konsep XP telah
dijelaskan, selama beberapa tahun, menggunakan sistem teks hiper-peta di website XP di
www.extremeprogramming.org sekitar tahun 1999 (website XPorg). Beck edited serangkaian
buku on XP, mulai dengan dirinya sendiri Extreme Programming Explained (1999, ISBN 0-
201-61641-6) , menyebarkan ide-idenya ke yang lebih besar, namun sangat reseptif,
penonton. Penulis dalam seri melewati berbagai aspek menghadiri XP dan praktik, bahkan
sebuah buku kritis terhadap praktek-praktek. XP cukup menciptakan buzz di akhir 1990-an
dan awal 2000-an, melihat adopsi dalam sejumlah lingkungan yang sangat berbeda dari asal-
usulnya. Disiplin tinggi yang diperlukan oleh praktek-praktek asli sering pergi di pinggir
jalan, menyebabkan beberapa praktik yang dianggap terlalu kaku untuk menjadi usang atau
kiri dibatalkan di setiap situs. Praktek-praktek pembangunan tangkas tidak berdiri diam, dan
XP masih berkembang, asimilasi lebih banyak pelajaran dari pengalaman di lapangan. Dalam
edisi kedua Extreme Programming Dijelaskan, Beck menambahkan lebih banyak nilai-nilai
dan praktik-praktik dan dibedakan antara primer dan praktek wajar.

Requirement yang berubah dengan cepat menuntut lifecycles yang lebih pendek, dan tidak
selaras dengan metoda pengembangan tradisional, yang pada umumnya memerlukan disain
luas di awal dan mengakibatkan perubahan desain yang terjadi kemudian memerlukan biaya
yang lebih tinggi atau kehilangan milestones. Berdasarkan hal ini kemudian dilahirkan
konsep XP yang digagas oleh Kent Beck dan Ward Cunningham pada Maret 1996. Metode
XP merupakan yang terpopuler dari beberapa metodologi pengembangan software yang
dipakai untuk mengimplementasikan proyek pengembangan perangkat lunak.
ASAL AGILE MODELING

Bidang pengembangan perangkat lunak berkembang sangat pesat dewasa ini. Dalam
perkembangannya ini tidak terlepas dari peran metodologi yang digunakan untuk
membangun. Jika kita lihat kembali ke belakang, berbagai metodologi untuk
mengembangkan perangkat lunak telah cukup banyak diperkenalkan. Mulai dari model
waterfall sampai dengan model-model incremental. Semua metodologi yang berkembang
sebelumnya tidak mampu menangani kemungkinan perubahan atau penambahan
requirements yang terjadi pada saat pengembangan dilaksanakan atau bahkan pada waktu
fase terakhir pengembangan. Hal inilah yang mendorong munculnya metodologi atau model
pengembangan perangkat lunak yang baru yang mampu mengatasi kekurangan tersebut. Pada
dekade 90-an diperkenalkan metodologi baru yang dikenal dengan nama Agile
Methodologies. Metodologi ini sangat revolusioner perubahannya jika dibandingkan dengan
berbagai metode sebelumnya. Agile Methodologies dikembangkan karena pada metodologi
tradisional terdapat banyak hal yang membuat proses pengembangan tidak dapat berhasil
dengan baik sesuai tuntutan user. Saat ini model proses dari Agile sudah cukup banyak
berkembang, di antaranya adalah: 1. eXtreme Programming (XP) 2. Scrum 3. Crystal Family
4. Dynamic Systems Development Method (DSDM) 5. Adaptive Software Development
(ASD) .

Tujuan Pembahasan Dari perumusan masalah yang telah dikaji menghasilkan tujuan yaitu:

1. Mendapat gambaran mengenai tim yang menggunakan Scrum.

2. Mengetahui siklus dari Scrum.
3. Mengetahui kelebihan dari menggunakan Scrum.
4. Mengetahui kekurangan dari menggunakan Scrum
5.Untuk mendefinisikan dan menunjukkan bagaimana mempraktekkan, sekumpulan nilai,
prinsip prinsip dan praktek yang lebih efektif, suatu modeling yang ringan. Rahasia dari
Agile Modeling bukan teknik modelingnya sendiri, seperti use case model, class model, data
model, or user interface model tetapi bagaimana mereka diaplikasikan.
6 Selain itu adalah untuk menempatkan persoalan bagaimana cara untuk mengaplikasikan
teknik modeling pada suatu proyek software yang menggunakan pendekatan agile seperti
eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), atau
SCRUM. Mengambil komentar Kent Beck dari eXtreme Programming Explained (XPE)
"kita akan terus menerus memperbaiki design dari sistem, mulai dari suatu awal yang
sederhana. Kita akan menghapus fleksibilitas yang tidak terbukti berguna.” Berkebalikan
dengan klaim dari beberapa kritikus eXtreme Programming bahwa akan memakan banyak
waktu untuk memodelkan pada kenyataanya ketika menggunakan suatu pendekatan eXtreme
Programming, tetapi jika kita tidak mempunyai pilihan lain. Terkadang lebih produktif bagi
developer untuk menggambar bubble dan garis daripada memikirkan suatu ide, atau untuk
membandingkan beberapa pendekatan yang berbeda untuk mengatasi permasalahan, daripada
memulai membajak kode yang sederhana.
7.Untuk menempatkan permasalaha bagaimana memodelkan sesuatu dengan lebih efektif
pada suatu proyek Unified Process (UP), instansiasi yang biasa yang meliputi Rational
Unified Process (RUP) dan Enterprise Unified Process (EUP). EUP meliputi beberapa
workflow yang berorientasi modeling pada requirement, Business Modeling, Analysis &
Design, Infrastructure Management dimana ketika mengaplikasikan pada suatu nilai akan
lebih memberatkan. Agile Modeling membantu untuk meningkatkan keefektifan dari usaha
memodelkan pada suatu proyek Unified Process atau beberapa proyek lain yang terjadi.

Tujuan Extreme Programming

Tujuan utama dalam extreme programming adalah menurunkan biaya dari adanya perubahan
software .Dalam metodologi pengembangan sistem tradisional, kebutuhan sistem ditentukan
padatahap 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 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.