MODEL-MODEL PENGEMBANGAN

PERANGKAT LUNAK

TUGAS MATA KULIAH PENGEMBANGAN SISTEM INFORMASI

Oleh :
Bimas Bukin 10540010

Dosen Pengajar : Freddy Kurnia Wijaya, M.Eng.,

Halaman Sampul
PROGRAM STUDI SISTEM INFORMASI
FAKULTAS DAKWAH DAN KOMUNIKASI
UNIVERSITAS ISLAM NEGERI RADEN FATAH
PALEMBANG
 KATA PENGANTAR
Kata Pengantar
Puji syukur kami panjatkan kehadirat Tuhan Yang Maha Esa karena
dengan rahmat, karunia, serta taufik dan hidayah-Nya kami dapat menyelesaikan
makalah tentang Model-model Pengembangan Perangkat Lunak ini dengan
baik meskipun banyak kekurangan didalamnya. Dan juga kami berterima kasih
pada Bapak Freddy Kurnia Wijaya, M.Eng., selaku Dosen mata kuliah
Pengembangan Sistem Informasi yang telah memberikan tugas ini kepada kami.
Kami sangat berharap makalah ini dapat berguna dalam rangka menambah
wawasan serta pengetahuan kita mengenai dampak yang ditimbulkan dari sampah,
dan juga bagaimana membuat sampah menjadi barang yang berguna. Kami juga
menyadari sepenuhnya bahwa di dalam makalah ini terdapat kekurangan dan jauh
dari kata sempurna. Oleh sebab itu, kami berharap adanya kritik, saran dan usulan
demi perbaikan makalah yang telah kami buat di masa yang akan datang,
mengingat tidak ada sesuatu yang sempurna tanpa saran yang membangun.
Semoga makalah sederhana ini dapat dipahami bagi siapapun yang
membacanya. Sekiranya laporan yang telah disusun ini dapat berguna bagi kami
sendiri maupun orang yang membacanya. Sebelumnya kami mohon maaf apabila
terdapat kesalahan kata-kata yang kurang berkenan dan kami memohon kritik dan
saran yang membangun demi perbaikan di masa depan.

Palembang, 31 Oktober 2015

Penulis

ii
 DAFTAR ISI
Daftar Isi
Halaman Sampul...............................................................................................................i

Kata Pengantar.................................................................................................................ii

Daftar Isi..........................................................................................................................iii

Daftar Gambar................................................................................................................iv

BAB I PENDAHULUAN.................................................................................................1

1.1 Latar Belakang.................................................................................................1

1.2 Rumusan Masalah............................................................................................1

1.3 Tujuan dan Manfaat........................................................................................2

1.4 Sistematika Penulisan......................................................................................2

BAB II PEMBAHASAN..................................................................................................3

2.1 Model Proses Perangkat Lunak......................................................................3

2.2 WaterFall Modell..............................................................................................6

2.3 Unified Software Development Modell.............................................................7

2.4 Agile Modell.....................................................................................................12

2.5 Extreme Programming....................................................................................13

2.6 SCRUM............................................................................................................17

2.7 Component-based Development Model...........................................................17

2.8 Prototype Modell..............................................................................................20

BAB III PENUTUP........................................................................................................26

3.1 Kesimpulan.....................................................................................................26

3.2 Saran...............................................................................................................26

DAFTAR PUSTAKA.....................................................................................................27

iii
 DAFTAR GAMBAR
Daftar Gambar
Gambar Halaman
2.1 Waterfall ...................................................................................... 4
2.2 USDP.......................................................................................... 7
2.3 Agille ......................................................................................... 12

iv
 BAB I
PENDAHULUAN
BAB I PENDAHULUAN
1.1 Latar Belakang
Dalam dunia teknologi sekarang pengembangan dalam bidang informatikan
telah mengalami perkembangan yang sangat pesat. Dengan perkembangan ini,
dalam bidang informatika tidak hanya menghasilkan hanya dalam pengembangan
program perangkat lunak saja, melainkan pengambangan dalam bidang suatu
permodelan yang bersifat komplek.
Dalam pembuatan sebuah perangkat lunak yang haruslah memiliki Teknik
analisa kebutuhan dan teknim permodelan yang baik, supaya terwujudnya suatu
perangkat lunak yang baik. 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 Waterfall dan Agile Model. Yang dimana dari setiap model ini
memiliki macam macam model lainnya.
Berdasarkan tugas yang kami peroleh, kami hanya membatasi penjelasan
mengenai permodelan ini, hanya memberikan konsep mengenai kekurangan,
kelebihan dari WaterFall Modell, Unified Software Development Modell, Agille
Modell, Extreme Programming, SCRUM, Component-based Development Modell,
dan Prototype Modell. Memberikan penjelasan menganai Agile Process yang
mencakupi Extreme Programming (XP) dan SCRUM.
1.2 Rumusan Masalah
Berdasarkan penjelasan yang terdapat pada latar belakang masalah diatas,
kami dihadapkan untuk menganalisa mengenai kekurangan serta kelebihan dari
permodelan perangkat lunak yakni WaterFall Modell, Unified Software
Development Modell, Agille Modell, Extreme Programming, SCRUM,
Component-based Development Modell, dan Prototype Modell. Memberikan
penjelasan menganai Agile Process yang mencakupi Extreme Programming (XP)
dan SCRUM.

1
1.3 Tujuan dan Manfaat
Tujuan dan manfaat secara keseluruhan untuk memahami lebih mendalam
serta bisa mengetahui perbedaan pada model-model dari konsep permodelan
proccess tersebut.
1.3.1 Tujuan
Adapun tujuan pembuatan makalah ini adalah :
2 Untuk memenuhi tugas makalah dari mata kuliah Pengembangan Sistem
Informasi.
3 Memahami lebih mendalam akan konsep permodelan Proccess baik dalam
hal, penjelasa, kekurangan, kelebihan dan perbandingan diantara model-model
tersebut.
4 Memahami lebih mendalam akan konsep analisa dan pemodelan pada
perangkat lunak terutama waterfall, Agille,Extremme Programming (XP) dan
SCRUM.
4.1.1 Manfaat
Manfaat dari pembuatan makalah ini agar kita tahu bagaimana cara kerja dari
permodelan permodelan pada perangkat lunak, bagaimana cara membuatnya dan
kapan permodelan tersebut diperlukan
4.2 Sistematika Penulisan
Sistematika penulisan makalah ini dengan membaca dari artikel artikel
yang ada di internet serta studi literatur yakni pengambilan informasi melaluin
pencarian dari buku.

2
 BAB II
PEMBAHASAN
BAB II PEMBAHASAN
2.1 Model Proses Perangkat Lunak
Pengertian Rekayasa Perangkat Lunak (Software Engineering)
Fritz Bauer menyatakan tentang rekayasa perangkat lunak,
[Software engineering is] the establishment and use of sound engineering
principles in order to obtain economically software that is reliable and works
efficiently on real machines.
Rekayasa perangkat lunak adalah teknologi berlapis. Hal itu dapat ditunjukan
dengan gambar sebagai berikut,

Dari gambar di atas dapat diartikan bahwa setiap pendekatan rekayasa

(termasuk rekayasa perangkat lunak) harus menekankan pada kualitas.
Dasar untuk rekayasa perangkat lunak adalah lapisan proses. Proses
rekayasa perangkat lunak adalah proses yang terus berulang, karena karakteristik
perangkat lunak yang membutuhkan pemeliharaan dan pengembangan
berkelanjutan agar perangkat lunak tidak kadarluasa. Dalam proses pemeliharaan
dilakukan koreksi kesalahan, adaptasi kebutuhan, peningkatan kemampuan atau
fungsi dan bentuk pencegahan lainnya agar perangkat lunak tersebut tidak
kadarluasa.
Metode rekayasa perangkat lunak menyediakan teknis untuk membangun
perangkat lunak dan mengandalkan seperangkat prinsip-prinsip dasar yang
mengatur setiap bidang teknologi dan mencakup kegiatan pemodelan dan teknik
deskriptif lainnya.

3
Alat rekayasa perangkat lunak merupakan unsur yang mendukung proses dan
metode. Ketika alat-alat yang terhubung satu sama lain dan memberi informasi,
serta informasi yang dibuat oleh salah satu alat dapat digunakan oleh yang lain,
sistem untuk mendukung pengembangan perangkat lunak dapat dibangun dengan
menggunakan bantuan komputer.

Pekerjaan yang berhubungan dengan rekayasa perangkat lunak dapat

dikategorikan ke dalam tiga fase generik, yaitu:
1. Tahap definisi berfokus pada what. Pada fase ini mengidentifikasi
informasi apa yang akan diproses, apa fungsi dan kinerja yang diinginkan,
perilaku system apa yang dapat diharapkan, apa antarmuka yang akan
didirikan, apa desain kendala yang ada, dan apa kriteria validasi yang
diperlukan untuk menentukan sistem yang sukses. Persyaratan utama dari
sistem dan perangkat lunak diidentifikasi. Meskipun metode yang
diterapkan selama fase definisi akan bervariasi tergantung pada paradigma
rekayasa perangkat lunak (atau kombinasi paradigma) yang diterapkan,
tiga tugas utama akan terjadi dalam beberapa bentuk: sistem atau teknik
informasi, perencanaan proyek perangkat lunak, dan analisis kebutuhan.
2. Tahap pengembangan berfokus pada how. Selama pengembangan
perangkat lunak didefinisikan bagaimana data harus terstruktur, bagaimana
fungsi diimplementasikan dalam arsitektur perangkat lunak, bagaimana
detail prosedural untuk dilaksanakan, bagaimana interface yang akan
ditandai, bagaimana desain akan diterjemahkan ke dalam bahasa
pemrograman (atau bahasa nonprocedural), dan bagaimana pengujian akan
dilakukan. Metode yang diterapkan dalam tahap pengembangan akan
bervariasi, tetapi tiga tugas teknis tertentu harus selalu terjadi: desain
perangkat lunak generasi kode, dan pengujian perangkat lunak.
3. Fase dukungan berfokus pada perubahan yang terkait dengan koreksi
kesalahan.

4
Model Proses dalam Rekayasa Perangkat Lunak
Sebuah model proses rekayasa perangkat lunak dipilih berdasarkan pada sifat
proyek dan aplikasi, metode dan alat-alat yang akan digunakan, dan kontrol dan
kiriman yang diperlukan.

Lingkaran fase pemecahan masalah dan lingkaran fase dalam fase pemecahan
masalah.

5
2.2 Waterfall Modell
Model Waterfall adalah model yang paling tua dan paling banyak digunakan.

Gb.2.1 Waterfall Modell

Tahapan dari model ini meliputi,

- Sistem / teknik informasi dan pemodelan. Perangkat lunak merupakan
bagian dari sistem yang lebih besar (atau bisnis). Pandangan sistem ini
penting ketika perangkat lunak harus berinteraksi dengan unsur-unsur lain
seperti perangkat keras, orang, dan database.
- Analisis kebutuhan perangkat lunak. Persyaratan proses pengumpulan
diintensifkan dan difokuskan secara khusus pada software.
- Rancangan. Desain perangkat lunak merupakan langkah yang berfokus
pada empat atribut yang berbeda dari sebuah program, yaitu struktur data,
arsitektur perangkat lunak, representasi interface, dan prosedural
(algoritmik) rinci.
- Pembuatan kode (Coding). Desain harus diterjemahkan ke dalam bentuk
mesin yang dapat dibaca. Dalam tahap ini dilakukan pembuatan kode.
- Pengujian(Testing). Setelah kode telah dihasilkan, pengujian program
dimulai. Pengujian yang dilakukan secara internal (benar tidaknya
pernyataan yang dibuat dalam coding) dan eksternal (melakukan tes untuk
menemukan kesalahan dan memastikan bahwa input sesuai dengan apa
yang dibutuhkan).
- Dukungan (Support). Perangkat lunak akan mengalami perubahan setelah
disampaikan kepada pelanggan.

6
2.3 Unified Software Development Modell
Unified Software Development Modell merupakan metodologi untuk
pengembangan perangkat lunak, utamanya perangkat lunak yang berorientasikan
objek. Metodologi ini pertama kali diperkenalkan oleh Rational Team, yang pada
perkembangan selanjutnya metodologi ini disempurnakan kembali menjadi
metodologi baru yang bernama Rational Unified Process (RUP), yang sekaligus
menjadi cikal bakal tebentuknya kurang lebih tujuh metodologi lainnya.
Berbicara tentang USDP, maka proses yang dicakup tidaklah sesederhana jika
dibandingkan dengan metodologi klasik, seperti waterfall dan iterative model. Hal
ini dikarenakan USD lebih digunakan untuk membangun sebuah kerangka kerja
(framework) yang bisa dikustomisasi untuk kepentingan organisasi dan proyek
yang lebih spesifik. Dengan framework, bisa tercipta beragam aplikasi karena
adanya konsep coding reuse, dimana coding yang sama bisa dipakai untuk
keperluan aplikasi yang sejenis.

Gb.2.2 Unified Software Depelovment Modell

Referensi Gambar : http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process

Dari gambar di atas terlihat bahwa USDP terbagi aras 4 fase, yaitu
Inception, Elaboration, Construction, dan Transition. Di tiap-tiap fase tersebut
terdapat 6 tahap kerja (iterasi) yang harus dilakukan, yaitu Business Modeling,
Requirements, Analysis & Design, Implementation, Test, dan Deployment. Ada
juga referensi lain yang membagi fase tersebut menjadi 5 tahap saja (Business
Modeling dan Requirements dijadikan satu) dan ada pula yang membaginya
menjadi 7 tahap (fase akhir ditambah dengan Maintenance). Fase kerja ini

7
berkaitan erat dengan peran seorang project manager, sedangkan tahap kerja
(iterasi) berkaitan erat dengan peran seorang developer atau programmer.

Penjelasan setiap Fase USDP

1.A. Inception
Dalam fase ini pengembang perangkat lunak dituntut untuk bisa
melakukan interaksi dengan customer, sebagai langkah awal untuk
pengidentifikasian kebutuhan-kebutuhan sistem yang hendak dibuat. Langkah ini
cukup penting agar para pengembang perangkat lunak punya kesamaan persepsi
antara sistem yang akan dibuat dengan kebutuhan pengguna.
Berikut adalah tahap-tahap iterasi kerja yang dilakukan developer pada
fase ini:
1. Business Modeling dan Requirements: menganalisa, merumuskan, dan
menentukan perencanaan, cakupan, dan kebutuhan utama bisnis.
2. Analysis: mengadakan studi kelayakan terhadap proyek yang akan
dijalani.
3. Design: mendesain konsep atau prototipe teknisnya.
4. Implementation: membuat prototipe konsepnya.
5. Test: tahap ini tidak terlalu dipentingkan atau belum diperlukan pada fase
ini.
Adapun hasil akhir dan tujuan yang ingin dicapai pada fase ini adalah:
1. Ruang lingkup sistem sudah terdefinisikan.
2. Kebutuhan sistem sudah bisa diidentifikasi dan telah mendapat persetujuan
dari stakeholder.
3. Arsitektur sistem sudah jelas, walaupun mungkin masih dalam tahap
perencanaan awal dan masih bisa berubah di fase selanjutnya.
4. Sudah melakukan analisa terhadap segala kemungkinan resiko yang
mungkin akan terjadi selama pengerjaan proyek.
5. Sudah mempunyai perencanaan bisnis yang matang untuk memperlancar
jalannya proyek kelak.
Studi kelayakan proyek sudah jelas dan pasti.

8
Stakeholder sudah menyetujui kerangka kerja proyek tersebut.
Dokumen atau produk yang dihasilkan dalam fase ini adalah System Charter atau
Vision Document.
1.B. Elaboration
Fase ini digunakan untuk mematangkan konsep-konsep yang sudah
terbentuk di fase Inception. Fase ini belum masuk ke tahap pembuatan perangkat
lunak secara langsung, tetapi lebih kepada pemantapan konsep dan peninjauan
kembali terhadap rencara-rencana yang sudah ditentukan sebelumnya. Dengan
demikian diharapkan proyek yang akan berjalan, resikonya dapat ditekan
seminimal mungkin.
Berikut adalah tahap-tahap iterasi kerja yang dilakukan developer pada
fase ini:
1. Business Modeling dan Requirements: memperbaiki cakupan dan
kebutuhan sistem.
2. Analysis: menganalisa kebutuhan sistem dan cara membangun sistem
tersebut.
3. Design: membuat arsitektur yang stabil.
4. Implementation: membuat garis besar arsitektur.
5. Test: mengetes garis besar arsitektur yang sudah dibuat.
Adapun hasil akhir dan tujuan yang ingin dicapai pada fase ini adalah:
1. Membuat garis besar dari arsitektur proyek yang lebih baik dan handal.
2. Memperbaiki analisa atau meminimalkan segala kemungkinan resiko yang
ada.
3. Mendefinisikan atribut kualitas (misal: atribut atau parameter apa saja
yang mempengaruhi keberhasilan dan kegagalan proyek).
4. Merangkum use case menjadi suatu kebutuhan fungsional.
5. Membuat perencanaan detail untuk fase selanjutnya.
6. Memformulasikan perencanaan kebutuhan peralatan, waktu, staf, biaya,
dan sumber daya lainnya.
7. Memperoleh persetujuan dari stakeholder untuk melanjutkan ke fase
berikutnya.

9
 Dokumen atau produk yang dihasilkan dalam fase ini adalah UML Model,
Software Requirements Specification (SRS), System/Subsystem Specification
(SSS), System/Subsystem Design Description (SSDD), Interface Control
Description (ICD), dan Software Architecture Description (SAD).
1.C. Construction
Fase ini merupakan fase coding, dimana pengembang perangkat lunak sudah
melakukan pembuatan sistem secara nyata. Pembuatan sistem tersebut tentunya
harus mengacu kepada hal-hal atau parameter-parameter yang sudah ditentukan
dan digariskan dari fase-fase sebelumnya.
Berikut adalah tahap-tahap iterasi kerja yang dilakukan developer pada fase
ini:
1. Business Modeling dan Requirements: menyelidiki lebih lanjut kebutuhan-
kebutuhan proyek yang mungkin belum terpikirkan sebelumnya.
2. Analysis: menyelesaikan analisis model.
3. Design: menyelesaikan desin model.
4. Implementation: membangun Initial Operational Capability.
5. Test: melaukan pengetesan terhadap Initial Operational Capability yang
telah dibuat.
Adapun hasil akhir dan tujuan yang ingin dicapai pada fase ini adalah:
1. Menyelesaikan identifikasi, deskripsi, dan realisasi dari use case.
2. Menjaga integritas dari arsitektur sistem.
3. Merevisi analisa resiko yang ada.
4. Menyelesaikan beberapa kebutuhan yang terlewatkan sebelumnya.
5. Menyelesaikan analisis dan desain model.
6. Membangun dan melakukan pengetesan terhadap Initial Operational
Capability, yang mengarah kepada pembentukan produk yang siap untuk
dilakukan pengetesan awal oleh pengguna (produk perangkat lunak versi
beta).
Dokumen atau produk yang dihasilkan dalam fase ini adalah Software
Development Plan (SDP).

10
 1.D. Transition
Tahap ini dilakukan untuk mematangkan produk akhir yang sudah jadi.
Pematangan ini perlu dilakukan untuk menganalisa apakah perangkat lunak yang
sudah dibuat sesuai dengan kebutuhan pengguna, atau mungkin terdapat bug yang
perlu diperbaiki, dan lain-lain.
Berikut adalah tahap-tahap iterasi kerja yang dilakukan developer pada
fase ini:
1. Business Modeling dan Requirements: tahapan ini seharusnya sudah tidak
dipakai lagi karena fase ini merupakan fase akhir, tetapi tetap dapat
dilakukan jika memang masih dibutuhkan.
2. Analysis: tahapan ini seharusnya sudah terselesaikan di fase sebelumnya
sehingga tidak dipakai lagi, tetapi tidak menutup kemungkinan tetap dapat
dilakukan jika memang masih dibutuhkan.
3. Design: melakukan modifikasi terhadap desain sistem jika ditemukan
masalah selama beta testing.
4. Implementation: melakukan penyesuaian setting perangkat lunak agar
bisa dipakai di sisi pengguna (misal, install dan setting database di server
pengguna, penyesuaian setting IP) dan melakukan perbaikan coding yang
ditemukan selama beta testing.
5. Test: melakukan proses beta testing dan melakukan testing akhir di sisi
pengguna.
Adapun hasil akhir dan tujuan yang ingin dicapai pada fase ini adalah:
1. Memperbaiki cacat yang ditemukan pada perangkat lunak.
2. Mempersiapkan perangkat lunak agar bisa dipakai oleh pengguna secara
langsung.
3. Memodifikasi perangkat lunak jika ditemukan masalah yang terlewatkan
pada versi beta.
4. Membuat buku manual dan dokumentasi lainnya.
5. Menyediakan konsultasi dan pelatihan kepada pengguna atas pemanfaatan
perangkat lunak tersebut.

11
 6. Melakukan peninjauan atau analisa setelah proyek selesai (post project
review).
Jika semua aspek sudah diselesaikan, maka dilakukan penyerahan perangkat
lunak tersebut secara resmi kepada pengguna untuk kemudian diimplementasikan.
Dokumen atau produk yang dihasilkan dalam fase ini adalah Software Test
Description (STD) dan Software Test Report (STR).

Hubungan Antar Fase USDP

Fase-fase yang sudah dijelaskan di atas, memiliki tingkat kepentingan
yang berbeda-beda antara proyek satu dengan lainnya. Utamanya dalam hal
kompleksitas proyek atau perangkat lunak yang akan dibuat. Ada dua pendekatan
yang bisa dipakai, yaitu pendekatan waktu yang dibutuhkan dan pendekatan
sumber daya yang dibutuhkan.

2.4 Agile Model

Dalam situasi pengembangan sofware harus membangun sistem bisnis yang
besar dan penting. Jangkauan dan kompleksitas sistem harus dimodelkan sehingga
dapat dimengerti, masalah dapat dibagi menjadi lebih kecil dan kualitas dapat
dijaga pada tiap langkah pembangunan sofware.
Agile Modeling adalah suatu metodologi yang praktis untuk dokumentasi dan
pemodelan system software. Agile Modeling adalah kumpulan nilai-nilai, prinsip
dan praktek-praktek untuk memodelkan software agar dapat diaplikasikan pada
sofware development proyek secara efektif.

Gb.2.3 Agile Model

12
2.5 Extreme Programming
Pengertian
Extreme Programming yang selanjutnya disingkat dengan XP merupakan
salah satu dari sekian banyaknya metodologi dalam rekayasa perangkat lunak dan
juga merupakan bagian dari metodologi pengembangan perangkat lunak agile.
Secara umum Extreme Programming (XP) dapat dijabarkan sebagai sebuah
pendekatan pengembangan perangkat lunak yang mencoba meningkatkan efisiensi
dan fleksibilitas dari sebuah proyek pengembangan perangkat lunak dengan
mengkombinasikan berbagai ide simpel/sederhana tanpa mengurangi kualitas
software yang akan dibagun.
XP dikembangkan oleh Beck, Cunningham, dan Jeffries
dan ini merupakan lightweight disciplinepengembangan perangkat lunak
berdasarkan empat core value.
Kelebihan dan Kekurangan XP
Kelebihan :
- Meningkatkan kepuasan kepada klien
- Pembangunan system dibuat lebih cepat
- Menjalin komunikasi yang baik dengan client.
- Meningkatkan komunikasi dan sifat saling menghargai antar developer.
Kekurangan :
- User story kemungkinan besar tidak lengkap sehingga Developer harus
selalu siap dengan perubahan karena perubahan akan selalu diterima.
- Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga
anjuran untuk melakukan apa yang diperlukan hari itu juga).
- XP tidak memiliki dokumentasi formal yang dibuat selama
pengembangan. Satu-satunya dokumentasi adalah dokumentasi awal yang
dilakukan oleh user.

13
Core Value XP

 Komunikasi (Communication)
Kurangnya komunikasi merupakan penyebab utama kegagalan
pengembangan software, maka XP mengfokuskan pada hubungan
komunikasi yang baik antar tim-klien, anggota tim, dan manajer
proyek.Komunikasi dalam XP dibangun dengan melakukan pemrograman
berpasangan (pair programming).Klien harus dilibatkan dalam proses
pengembangan perangkat lunaknya dengan tujuannya untuk memberikan
pandangan pengembang sesuai dengan pandangan pengguna sistem yang
dibangun.
 Kesederhanaan (Simplicity)
XP melakukan semua dengan sederhana dan praktis tanpa mengurangi
fungsi utamanya. Diusahakan mengunakan method yang pendek dan
simpel, jangan terlalu rumit dalam membuat desain, hilangkan fitur yang
tidak ada gunanya atau menghapus fungsi yang tidak terpakai. Dengan
kata lain lebih baik melakukan hal yang sederhana saat sekarang (sesuai
kebutuhan) dan mengembangkannya besok jika diperlukan.
 Umpan balik (Feedback)
Selalu mengevaluasi perkembangan terhadap perangkat lunak yang sedang
dikerjakan, segala informasi harus dikumpulkan setiap interval waktu yang
konsisten dan diskusikan kesalahan-kesalahan yang muncul selama proses
pengembangan. Umpan balik tersebut berfungsi sebagai indikator

14
 kemajuan proyek dan menginformasikan pemimpin
proyek apabila perubahan perlu dibuat.
 Keberanian (Courage).
Programmer XP didorong untuk berani bereksperimen dan menulis
ulang kode jika mereka tidak puas dengan kode yang sudah ada atau
desain. Hal ini membantu mempertahankan moral serta intgritas para
pengembang proyek dan dapat mendukung lebih lanjut komunikasi dengan
anggota proyek lainnya.
Tahapan XP

Planning, Aktivitas planning dimulai dengan membentuk user stories.

Anggota XP team kemudian menilai setiap story dan menentukan cost –
diukur dalam development week. Customer dan XP team bekerja bersama
untuk memutuskan bagaimana grup story untuk release berikutnya (software
increment berikutnya) untuk dibangun oleh XP team. Jika komitmen telah
dibuat, XP team akan membangun story-story dengan cara :
- Semua story segera diimplemetasikan (dalam beberapa minggu)
- Story dengan value tertinggi akan dipindahkan dari jadwal dan
dimplementasikan pertama.
- Story dengan resiko paling tinggi akan diimplemetasikan lebih dulu.
Setelah project pertama direlease dan didelivery, XP team
memperhitungkan kecepatan project. Selama development, customer dapat
menambah story, merubah value, membagi story atau menghapusnya.

15
 Design. XP menggunakan CRC card, untuk mengenali dan mengatur object
oriented class yang sesuai dengan software increment.
Coding. Sebelum membuat code, lebih baik membuat unit test tiap story
untuk dimasukkan dalam software increment. XP menyarankan agar dua
orang bekerja bersama pada satu komputer workstation untuk membuat code
dari satu story (pair programming), untuk menyediakan real time problem
solving dan jaminan real time quality. Setelah pair programming selesai, code
diintegrasikan dengan kerja laiinnya (continuous integration).
Testing. Unit test yang telah dibuat harus diimplementasikan menggunakan
suatu framework dan diatur ke dalam universal testing suite, integrasi dan
validasi sistem dapat dilakukan setiap hari. Customer test (acceptance test)
dilakukan oleh customer dan fokus pada keseluruhan fitur dan fungsional
sistem. Acceptance test diperoleh dari customer stories yang telah
diimplemetasikan sebagai bagian dari software release.
Artefak XP

Siklus Hidup

16
2.6 SCRUM
Pertama kali diperkenalkan oleh Jeff Sutherland tahun awal tahun 1990an, dan
dikembangkan selanjutnya dilakukan oleh Schwaber dan Beedle. Pada dasarnya
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 mengidentifikasi dan katalogisasi pekerjaan
yang perlu dilakukan, memprioritaskan yang bekerja dengan berkomunikasi
dengan pelanggan atau wakil pelanggan, dan pelaksanaan yang 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. Hal ini
dilakukan supaya tim akan tahu bagaimana cara terbaik untuk memecahkan
masalah yang mereka disajikan.
Ada 3 elemen organisasi utama pada scrum yaitu product owner, Scrum
master, dan the Scrum team. Scrum Master dapat dianggap sebagai pelatih bagi
tim, membantu anggota tim menggunakan kerangka Scrum untuk tampil di
tingkat tertinggi. Product Owner mewakili bisnis, pelanggan atau pengguna dan
memandu tim ke arah pegembangan produk yang tepat. Sedangkan The Scrum
Team merupakan grup pengembang kecil biasanya terdiri dari 5-9 orang. Untuk
projek yang sangat besar, pekerjaan biasanya dibagi dan didelegasikan ke grup-
grup kecil. Jika sangat dibutuhkan the scrum master juga dapat ikut membantu
dalam koordinasi team.

2.7 Component-based Development Modell

Seperti yang telah dijelaskan sebelumnya mengenai definisi CBD, Lalu
bagaimana proses pengembangan CBD sendiri? CBD merupakan perancangan

17
dan pengembangan sistem perangkat lunak yang disusun dari komponen-
komponen. Untuk lebih jelas dapat diuraikan melalui bagan atau gambar 1 dari
proses pengembangan CBD.

Gambar menunjukkan pengembangan model V yang diadopsi ke pendekatan

component-based. Dengan memnggunakan model V sebagai model yang
digunakan di banyak organisasi-organisasi besar. Biasanya, organisasi besar
membangun product dengan komplek dan long-life, seperti mobil dan robot.
Dalam model ini proses umumnya dimulai pada kebutuhan engineering dan
kebutuhan spesifikasi, diikuti dengan spesifikasi sistem. Dalam pendekatan
noncomponents-based, proses akan continue dengan unit design, implementation
dan test. Tetapi bukannya menjalankan aktivitas tetapi malah sering memakan
waktu dan usaha, dengan hanya memilih komponen yang sesuai dan
mengintegrasikannya ke dalam sistem. Bagaimanapun, dua masalah muncul disini
yang memecahkan kemudahan tersebut yaitu:

18
 1. Ketidakjelasan adanya komponen yang dipilih
2. Komponen yang dipiih hanya sebagian yang cocok/sesuai untuk didesain
secara keseluruhan

Fakta pertama menunujukkan bahwa harus memiliki proses untuk menemukan

komponen. Proses tersebut meliputi kegiatan atau aktivitas untuk menemukan
komponen dan kemudian mengevaluasi komponen. Fakta kedua mengindikasikan
suatu kebutuhan dari komponen yang diadopsi dan pengujian sebelum dapat
diintegrasikan kedalam sistem. Dan tentunya harus ada proses pengembangan
komponen, hal ini menjadi proses pengembangan sistem yang bebas/independen.
Pengembangan CBD model V menunjukkan proses yang disederhanakan dan
proses yang ideal , dengan asumsi bahwa komponen dipilih dan digunakan dengan
unit identifikasi yang paling dekat didalam proses desain, sehingga proses
peyesuaian (adaptasi) membutuhkan upaya sedikit daripada unit implementation.
Selebihnya tidak mempertimbangkan apa yang terjadi dalam proses maintenance.

Proses pengembangan CBD model V masih disederhankan dan proses masih

diidealkan/ belum terlalu sempurna, detail pengambangan CBD dapat dilihat di
gambar 2.

19
Detail pengembangan CBD lebih nyata. proses bertahap dimulai dari analisis
kebutuhan dan spesifikasi, rancangan sistem, implementasi dan unit pengujian,
integrasi sistem, verifikasi dan validasi sistem serta operasi pendukung dan
pemeliharaan. pengembangan ini lebih detail dengan memodifikasi sebagian tahap
operasi pendukung dan maintenance. Modifikasi dengan meyebarkan atau
menempatkan komponen(component deployed) dalam sistem. Tetapi dalam
sebagian besar kasus, komponen yang diubah atau versi baru dari komponen yang
sama akan diintegrasikan dalam sistem. Sehingga maslah akan muncul kembali
yaitu ketidakcocokan antara komponen, atau dengan dependensi rusak yang
mungkin saja dapat terjadi. Ini berarti, satu hal lagi bahwa sistem harus
diverifikasi(baik secara formal ataupun dengan simulasi dan pengujian)

2.8 Prototype Modell

Metode Prototype merupakan suatu paradigma baru dalam metode pengembangan

perangkat lunak dimana metode ini tidak hanya sekedar evolusi dalam dunia
pengembangan perangkat lunak, tetapi juga merevolusi metode pengembangan
perangkat lunak yang lama yaitu sistem sekuensial yang biasa dikenal dengan
nama SDLC atau waterfall development model.

20
Dalam Model Prototype, prototype dari perangkat lunak yang dihasilkan
kemudian dipresentasikan kepada pelanggan, dan pelanggan tersebut diberikan
kesempatan untuk memberikan masukan sehingga perangkat lunak yang
dihasilkan nantinya betul-betul sesuai dengan keinginan dan kebutuhan
pelanggan.

Perubahan dan presentasi prototype dapat dilakukan berkali-kali sampai dicapai

kesepakatan bentuk dari perangkat lunak yang akan dikembangkan.

Teknik – teknik Prototyping Meliputi :

 Perancangan Model
 Perancangan Dialog

 Simulasi

Berikut adalah 4 langkah yang menjadi karakteristik dalam proses pengembangan

pada metode prototype, yaitu :

 Pemilihan fungsi
 Penyusunan Sistem Informasi

21
  Evaluasi

 Penggunaan Selanjutnya

Metode ini menyajikan gambaran yang lengkap dari suatu sistem perangkat lunak,
terdiri atas model kertas, model kerja dan program. Pihak pengembang akan
melakukan identifikasi kebutuhan pemakai, menganalisa sistem dan melakukan
studi kelayakan serta studi terhadap kebutuhan pemakai, meliputi model interface,
teknik prosedural dan teknologi yang akan dimanfaatkan.

Berikut adalah Tahapan – tahapan Proses Pengembangan dalam Model Prototype,

yaitu :

 Pengumpulan kebutuhan

Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh

perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem
yang akan dibuat.

 Membangun prototyping

22
Membangun prototyping dengan membuat perancangan sementara yang berfokus
pada penyajian kepada pelanggan (misalnya dengan membuat input dan format
output).

 Evaluasi protoptyping

Evaluasi ini dilakukan oleh pelanggan, apakah prototyping yang sudah dibangun
sudah sesuai dengan keinginan pelanggan atau belum. Jika sudah sesuai, maka
langkah selanjutnya akan diambil. Namun jika tidak, prototyping direvisi dengan
mengulang langkah-langkah sebelumnya.

 Mengkodekan sistem

Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam

bahasa pemrograman yang sesuai.

 Menguji sistem

Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, kemudian
dilakukan proses Pengujian. Pengujian ini dilakukan dengan White Box, Black
Box, Basis Path, pengujian arsitektur, dll.

 Evaluasi Sistem

Pelanggan mengevaluasi apakah perangkat lunak yang sudah jadi sudah sesuai
dengan yang diharapkan . Jika ya, maka proses akan dilanjutkan ke tahap
selanjutnya, namun jika perangkat lunak yang sudah jadi tidak/belum sesuai
dengan apa yang diharapkan, maka tahapan sebelumnya akan diulang.

 Menggunakan sistem

Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.

23
Model Prototyping ini sangat sesuai diterapkan untuk kondisi yang beresiko tinggi
di mana masalah-masalah tidak terstruktur dengan baik, terdapat fluktuasi
kebutuhan pemakai yang berubah dari waktu ke waktu atau yang tidak terduga,
bila interaksi dengan pemakai menjadi syarat mutlak dan waktu yang tersedia
sangat terbatas sehingga butuh penyelesaian yang segera. Model ini juga dapat
berjalan dengan maksimal pada situasi di mana sistem yang diharapkan adalah
yang inovatif dan mutakhir sementara tahap penggunaan sistemnya relatif singkat.

Berikut merupakan Jenis – jenis dari Prototyping :

 Feasibility prototyping

digunakan untuk menguji kelayakan dari teknologi yang akan digunakan untuk
system informasi yang akan disusun.

 Requirement prototyping

digunakan untuk mengetahui kebutuhan aktivitas bisnis user.

 Desain Prototyping

digunakan untuk mendorong perancangan sistem informasi yang akan digunakan.

 Implementation prototyping

merupakan lanjutan dari rancangan prototype, prototype ini langsung disusun

sebagai suatu sistem informasi yang akan digunakan.

 Contoh Penerapan Metode Prototype.

Sebuah rumah sakit ingin membuat aplikasi sistem database untuk pendataan
pasiennya. Seorang atau sekelompok programmer akan melakukan identifikasi
mengenai apa saja yang dibutuhkan oleh pelanggan, dan bagaimana model kerja
program tersebut. Kemudian dilakukan rancangan program yang diujikan kepada

24
pelanggan. Hasil/penilaian dari pelanggan dievaluasi, dan analisis kebutuhan
pemakai kembali di lakukan.

 Kelebihan Model Prototype :

 Pelanggan berpartisipasi aktif dalam pengembangan sistem, sehingga hasil
produk pengembangan akan semakin mudah disesuaikan dengan
keinginan dan kebutuhan pelanggan.

 Penentuan kebutuhan lebih mudah diwujudkan.

 Mempersingkat waktu pengembangan produk perangkat lunak.

 Adanya komunikasi yang baik antara pengembang dan pelanggan.

 Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan

pelanggan.

 Lebih menghemat waktu dalam pengembangan sistem.

 Penerapan menjadi lebih mudah karena pelanggan mengetahui apa yang

diharapkannya.

 Kekurangan Model Prototype :

 Proses analisis dan perancangan terlalu singkat.

 Biasanya kurang fleksibel dalam mengahadapi perubahan.

 Walaupun pemakai melihat berbagai perbaikan dari setiap versi prototype,

tetapi pemakai mungkin tidak menyadari bahwa versi tersebut dibuat tanpa
memperhatikan kualitas dan pemeliharaan jangka panjang.

 Pengembang kadang-kadang membuat kompromi implementasi dengan

menggunakan sistem operasi yang tidak relevan dan algoritma yang tidak
efisien.

25
 BAB III
PENUTUP
BAB III PENUTUP
3.1 Kesimpulan
Kesimpulan dari makalah ini adalah ada banyak model dari pengembangan
perangkat lunak, tinggal dari kita sebagai pelaku ingin memakai model yang
mana.
3.2 Saran
Adapun saran dari makalah ini adalah kebanyakan dari tulisan ini diambil dari
internet, dan catatan catanan perkuliahan, jadi referensi dari makalah ini sangat
kurang sekali.

26
DAFTAR PUSTAKA

http://raymondsutjiadi.wordpress.com/2009/05/19/unified-software-
development-process-usdp/ (diakses pada Sabtu, 31 Oktober 2015)
https://id.wikipedia.org/wiki/
Agile_Development_Methods#Model_proses_agile (diakses pada Sabtu,
31 Oktober 2015)
https://keinatralala.wordpress.com/2013/12/13/metodologi-extreme-
programming/ (diakses pada Sabtu, 31 Oktober 2015)

27