Laporan tentang macam macam model SDLC

(System Development Life Cycle)

Oleh:
Muhammad Rikzan
Sistem Informasi 2019A
19051214014

Sistem Informasi
Universitas Negeri Surabaya
 Model - Model SDLC (System Development Life Cycle)
1. Tradional Model

Pendekatan sistem adalah sebuah metodologi. Metodologi adalah suatu cara

yang direkomendasikan dalam melakukan sesuatu. Pendekatan sistem adalah
metodologi dasar dalam memecahkan segala jenis masalah. Siklus hidup
pengembangan sistem (System Development Life Cycle-SDLC) adalah aplikasi
dari pendekatan sistem bagi pengembangan suatu sistem informasi.
SDLC tradisional adalah metode pengembangan sistem informasi klasik yang
mengikuti suatu pola teratur secara bertahap yang dikerjakan dari atas ke
bawah. SDLC tradisional seringkali disebut pendekatan waterfall. Aktivitas dalam
siklus ini memiliki aliran satu arah menuju penyelesaian proyek. Tahapan dalam
SDLC tradisional adalah sebagai berikut :
• Perencanaan
Sasaran Tahap perencanaan adalah diperolehnya cakupan dari proyek
pengembangan sistem dan dasar-dasar untuk kendali. Tahap perencanaan
terdiri dari :

1. Menyadari adanya masalah atau pemicu masalah

2. Menetaplan masalah
3. Mengidentifikasi kendala sistem
4. Membuat studi kelayakan

• Analisis
Tujuan dari tahap analisis adalah memahami permasalahan secara menyeluruh
dan mendefinisikan kebutuhan pemakai (apa yg harus dilakukan oleh sistem utk
memenuhi keinginan pemakai). Tahap analisis terdiri dari :

1. Mengumumkan penelitian sistem

2. Mengorganisasik tim proyek
3. Mendefinisikan kebutuhan informasi
4. Mendefinisikan kriteria kinerja sistem
5. Menyiapkan usulan perancangan
6. Menerima atau menolak perancangan

• Perancangan
Tujuan dari tahap perancangan adalah menentukan solusi yang dapat memenuhi
kebutuhan informasi pemakai yang sudah didefinisikan dan membuat suatu
model implementasi yang akan dibangun kemudian. Tahap perancangan terdiri
dari :

1. Menyiapkan perancangan sistem rinci

2. Mengidentifikasi alternatif konfigurasi sistem
3. Mengevaluasi alternatif konfigurasi sistem
4. Memilih konfigurasi terbaik
5. Menyiapkan usulan penerapan
6. Menyetujui atau menolak penerapan sistem

• Implementasi
Tujuan tahap implementasi adalah mendapatkan sistem informasi sesuai dengan
kebutuhan pemakai.
Tahapan implementasi tesdiri dari :

1. Merencanakan penerapan
2. Mengumumkan penerapan
3. Mendapatkan sumber daya HW
4. Mendapatkan sumber daya SW
5. Menyiapkan basis data
6. Menyiapkan fasilitas fisik
7. Pelatihan pemakai
8. Masuk/peralihan ke sistem baru

• Penggunaan
Tujuan tahap penggunaan adalah menjaga agar sistem tetap beroperasi secara
normal, dapat mengantisipasi penyimpangan yang mungkin dialami sistem dan
melakukan evaluasi sistem.
2. Agile Development Model

Agile development adalah sebuah filosofi dan serangkaian panduan untuk

mengembangkan sistem informasi di dalam lingkungan yang sering berubah dan
dapat digunakan dengan metodologi pengembangan sistem apapun. Metodologi
agile adalah sebua filosofi tentang bagaimana membangun model, beberapa
diantaranya formal dan detil, namun yang lainnya hanya berupa sketsa dan
sangat ringkas.

Nilai-nilai dari Agile Developement

Filosofi agile menggunakan pendekatan yang fleksibel terhadap jadwal proyek
dan memberikan kesempatan bagi tim proyek untuk merencanakan dan
menjalankan pekerjaan mereka sesuai dengan perkembangan proyek. Filosofi
utama dalam pengembangan agile adalah
1. Value responding to change over following a plan
2. Value individuals and interactions over processes and tools
3. Value working software over comprehensive documentation
4. Value customer collaboration over contract negotiation

Di dalam proyek yang menggunakan filosofi agile dikenal istilah “chaordic” atau
“chaos” dan “order”. Filosofi agile menyadari ketidakpastian ini, penanganan
dengan meningkatkan flesibilitas dan mempercayakan tim proyek untuk
mengembangkan solusi terhadap masalah yang ada. Aspek penting lainnya
dalam pengembangan Agile adalah pelanggan harus secara terus terlibat di
dalam tim proyek. Mereka tidak bisa hanya duduk dengan tim proyek dalam
beberapa sesi untuk mengembangkan spesifikasi. Mereka menjadi bagian dari
tim teknis.

Model Prinsip Agile Development

Pemodelan agile bukan berarti melakukan pemodelan lebih sedikit namun
membuat pemodelan yang tepat untuk tujuan yang tepat pada level tertentu.
Pemodelan agile tidak menentukan model mana yang harus dibuat dan
bagaimana membuat model tersebut. Sebaliknya, pemodelan agile hanya
membantu pengembang untuk tetap pada jalurnya dengan pemodelan yang
mereka buat sebagai alat untuk mencapai tujuan namun bukan tujuan akhirnya.
Prinsip pemodelan agile berikut mengindikasikan membangan model adalah
teknik yang utama dalam pengembangan software namun model adalah sarana
bukan tujuan.
1. Membangun software sebagai tujuan utama
2. Menjalankan usaha berikutnya sebagai tujuan sekunder
3. Meminimalkan kegiatan pemodelan – sedikit dan sederhana
4. Merangkul perubahan dan perubahan bertahap
5. Membuat model dengan tujuan
6. Membuat beberapa model
7. Membuat model dengan kualitas baik dan mendapatkan umpan balik
8. Fokus pada isi daripada tampilan
9. Belajar dari yang lain dengan komunikasi terbuka
10. Mengetahui model yang dibuat dan cara menggunakannya
11. Beradaptasi pada kebutuhan proyek yang spesifik
3. Waterfall Model

Waterfall adalah pendekatan SDLC paling awal yang digunakan untuk

pengembangan perangkat lunak. Hal ini juga disebut sebagai model SDLC
linear-sekuensial. Hal ini sangat sederhana untuk memahami dan
menggunakanya dalam mengimplementasikan sebuah sistem.
Dalam Model Waterfall, setiap tahap harus berurutan, dan tidak dapat meloncat
ketahap berikutnya, harus menyelesaikan tahap pertama baru lanjut ke tahap ke
dua dst.
Langkah-langkah Waterfall SDLC. Pendekatan Waterfall digunakan secara luas
dalam Pengembangan sistem, step-step nya terdiri dari

1. Requirement Gathering and analysis

Mengumpulkan kebutuhan secara lengkap kemudian kemudian dianalisis dan
didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun.
Fase ini harus dikerjakan secara lengkap untuk bisa menghasilkan desain yang
lengkap.

2. System Design
Desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap

3. Implementation
Desain program diterjemahkan ke dalam kode-kode dengan menggunakan
bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung
diuji baik secara unit.

4. Integration and Testing

Penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing)

5. Deployment of system
Mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti
penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya.

6. Maintenance
Proses pemeliharaan sistem yang sudah dibangun

Kelebihan Waterfall Model

Keuntungan dari Waterfall model adalah Jadwal dapat diatur dengan tenggat
waktu untuk setiap tahap pengembangan dan produk dapat dilanjutkan melalui
proses pengembangan model fase satu per satu. Pembangunan bergerak dari
konsep, melalui desain, implementasi, pengujian, instalasi, pemecahan masalah,
dan berakhir di operasi dan pemeliharaan

Berikut Keuntungan lainya dari Waterfall Model

• Simple, mudah dimengerti dan di implemetasikan
• Mudah untuk mengelola karena model yang sederhana. Setiap fase memiliki
spesifik requirement dan proses review
• Fase diproses dan diselesaikan satu per satu
• Cocok untuk project skala kecil dimana kebutuhan project dapat mudah
dimengerti
• Jelas dalam mendefinisikan setiap tahap
• Mudah menentukan pencapaian suatu sistem
• Mudah dalam menentukan tugas setiap individu
• Proses pendokumentasian lebih mudah.

Kekurangan Waterfall Model

Kerugian dari Waterfall model adalah tidak memungkinkan banyak refleksi atau
revisi. Setelah aplikasi dalam tahap pengujian, sangat sulit untuk kembali dan
mengubah sesuatu yang tidak terdokumentasi dengan baik atau pikiran pada
dalam tahap konsep.

Berikut Kerugian lainya dari Waterfall Model:

• Aplikasi yang dihasilkan cenderung lama karena step-step tidak dapat
dilongkap
• Resiko yang tinggi karena proses nya terlalu lama
• Tidak cocok untuk project yang terlalu complex dan Object Oriented Projects
• Tidak cocok untuk project jangka lama dan untuk project yang sedang berjalan
• Tidak cocok untuk project yang mudah berganti-ganti model proses
• Sulit untuk mengukur kemajuan dalam tahap
4. Scrum Model

Scrum Pada dasarnya merupakan salah satu komponen dari metodologi

pengembangan sistem Agile . Akhir-akhir ini scrum mulai marak di
implemntasikan di perusahaan IT di Indonesia, dikarenakan maraknya
perusahaan IT mengimplementasikan agile development. 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 development
akan dilakukan.

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
Element-Element dalam Scrum

Ada 3 elemen organisasi utama pada scrum yaitu product owner, Scrum master,
dan the Scrum team.
• Product Owner mewakili bisnis, pelanggan atau pengguna dan memandu tim
ke arah pegembangan produk yang tepat.
• Scrum Master dapat dianggap sebagai pemersatu bagi product owner dan
scrum team (developer, QA, technical wirter dll), membantu anggota tim
menggunakan kerangka Scrum untuk menyelesaikan suatu project berdasarkan
timeline yang ditentukan di awal.
• 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
Scrum tepat digunakan saat kondisi:
• Keperluan berubah dengan cepat
• Tim programmer sedikit, yaitu 5-9 orang

• Pelanggan tidak terlalu paham dengan apa yang diinginkan

Scrum memiliki prinsip yaitu:
• Ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan
memberdayakan satu sama lain
• Proses dapat beradaptasi terhadap perubahan teknis dan bisnis
• Proses menghasilkan beberapa software increment
• Pembangunan dan orang yang membangun dibagi dalam tim yang kecil
• Dokumentasi dan pengujian terus menerus dilakukan setelah software
dibangun
• Proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

Kelebihan Scrum antara lain:

• Keperluan berubah dengan cepat
• Tim berukuran kecil sehingga melancarkan komunikasi, mengurangi biaya dan
memberdayakan satu sama lain
• Pekerjaan terbagi-bagi sehingga dapat diselesaikan dengan cepat
• Dokumentasi dan pengujian terus menerus dilakukan setelah software
dibangun
• Proses Scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

Kelemahan Scrum antara lain:

• Developer harus selalu siap dengan perubahan karena perubahan akan selalu
diterima.
5. Iterative Model

Dalam Iterative model SDLC, proses iterative dimulai dengan implementasi

sederhana dari komponen kecil dari software sampai dengan meningkatkan versi
dari sebuah software dengan update-updateanya sehingga software siap
digunakan ke user.
Di setiap Iterative nya, perubahan baik design maupun fungsi ditambahkan. Ide
dasar di balik metode ini adalah untuk mengembangkan sistem melalui siklus
berulang (iterative) dan dalam porsi kecil di setiap updatetanya.

Ilutstrasi dibawah merupakan iterative model yang sering digunakan oleh

perusahaan-perusahaan IT/Software house.

Iterative dan Incremental development adalah kombinasi dari kedua desain

iterative dan incremental, untuk sebuah development. Selama development lebih
dari satu iterasi dari sebuah software development life cycle.

Kunci dari keberhasilan dari Iterative model SDLC (Software development life
cycle) adalah validasi kebutuhan yang ketat dan melakukan testing yang detail di
setiap version dari sebuah software. Sebuah update version software pastinya
harus memberikan fitur-fitur baru yang membuat software tersebut menjadi
semakin baik, untuk dari itu versi software terbaru harus dilakukan testing yang
berulang-ulang agar fungsi lama nya tetap berjalan dengan baik.

Spesifikasi Iterative Model

Seperti model SDLC lainya, Iterative model memiliki spesifikasi khusus di dalan
industri software. Model ini paling sering digunakan dalam kondisi seperti:
• Requirement sistem dan design harus jelas dan mudah di pahami.
• Persyaratan Utama harus didefinisikan, namun nantinya akan ada request baru
untuk penambahan fungsi pada saat sistem sedang berjalan.
• Teknologi yang sedang digunakan dalam pengembangan software bisa diganti
apabila ada teknologi baru yang lebih bagus.
• Ada beberapa fitur berisiko tinggi dan tujuan yang mungkin berubah di masa
depan.

Kelebihan dari Iterative Model SDLC

• Beberapa fungsi dapat di kembangkan dengan cepat di awal pembuatan versi
baru.
• hasil yang di peroleh secara berkala
• Kemajuan sebuah sistem dapat di ukur
• Development software mudah di rencanakan
• Biaya yang dikeluarkan kecil apabila ingin merubah requirement
• Testing dan debugging selama proses iterasi lebih mudah.
• Analisis resiko yang lebih baik
• Mendukung perubahan requirement
• Waktu operasional yang lebih singkat
• Cocok untuk project besar

Kekurangan dari Iterative Model SDLC

• Membutuhkan resource yang cukup banyak
• Meski biaya perubahan rendah, tetapi sangat tidak cocok untuk mengubah
persayaratan
• Memerlukan Perhatian manajemen
• Permasalahan sistem arsitektur dan desain mungkin akan timbul, karena tidak
semua persyaratan di tentukan di awal pengambangan sistem.
• tidak cocok untuk project kecil
• Kompleksitas manajemen
• Membutuhkan tenaga ahli untuk analisis resiko yang timbul
6. Sprial Model

Model Spiral SDLC adalah sebuat metode pengabungan antara Iterative Model
dengan Waterfall Model. dengan penekanan yang tinggi pada analisis resiko
yang akan di hadapi. Spiral model bertujuan untuk meningkatkan tingkat
keberhasilan pada saat pengembangan suatu sistem.

Fase Spriral Model

1) Identification
Pada fase ini bertujuan untuk mengumpulkan kebutuhan bisnis di dasar spiral,
Dalam spiral berikutnya disebut sebagai produk deawsa. Identifikasi persyaratan
sistem, persyaratan subsistem, persyaratan unit dilakukan pada fase ini. Fase ini
juga mencakup komunikasi antar sistem analis dengan klien.

2) Design
Pada fase ini dimulai dengan desain konseptual di dasar spiral dan melibatkan
desain arsitektur, desain logis dari modul, desain produk fisik dan desain akhir
dalam spiral berikutnya.

3) Construct or Build
Pada fase ini mengacu produksi produk perangkat lunak yang sebenarnya di
setiap spiral.

4) Evaluation and Risk Analysis

Pada fase ini mengidentifikasi, memperkirakan dan memantau kelayakan teknis
dan risiko manajemen, seperti jadwal selip dan biaya lebih. Setelah pengujian
sistem, akhir dari iterasi klien akan mengevaluasi produk yang sudah dibangun
dan akan memberikan feedback.
Berikut adalah spesifikasi dari Spiral Model:
• Penting saat ada kendala anggaran dan evaluasi resiko
• Untuk project beresiko menengah – tinggi
• Pelanggan tidak yakin kebutuhan mereka yang biasanya terjadi.
• Perubahan signifikan diharapkan dalam produk selama siklus pengembangan
sistem
• Persyaratan yang kompleks dan perlu evaluasi untuk mendapatkan kejelasan

Kelebihan dari Spiral Model

• Perubahan kebutuhan dapat diakomodir.
• Persyaratan dapat diketahui lebih akurat.
• Pengguna dapat melihat sistem awal.
• Pembangunan dapat dibagi menjadi bagian-bagian yang lebih kecil dan
bagian-bagian yang berisiko dapat dikembangkan sebelumnya yang membantu
dalam manajemen risiko yang lebih baik

Kekurangan dari Spiral Model

• Manajemen lebih kompleks.
• Akhir proyek mungkin tidak diketahui di awal.
• Tidak cocok untuk proyek-proyek berisiko kecil atau rendah dan bisa menjadi
mahal untuk proyek-proyek kecil.
• Proses yang kompleks
• Spiral mungkin berlangsung tanpa batas.
7. V model

The V-Model adalah model SDLC dimana pelaksanaan proses yang terjadi
secara berurutan dalam bentuk-V. Dikenal juga sebagai model Verifikasi dan
Validasi.

The V-Model merupakan perluasan dari waterfall model dan didasarkan pada
asosiasi dari fase pengujian untuk setiap tahap pengembangan yang sesuai. Ini
berarti bahwa untuk setiap fase tunggal dalam siklus pengembangan, ada tahap
pengujian terkait langsung. Ini adalah model yang sangat disiplin dan tahap
berikutnya dimulai setelah selesainya tahap sebelumnya.

Ada beberapa tahapan verifikasi di V-Model, masing-masing dijelaskan secara

rinci di bawah:
1) Business Requirement Analysis
Ini adalah tahap pertama dalam siklus pengembangan di mana persyaratan
produk dipahami dari perspektif pelanggan. Fase ini melibatkan komunikasi rinci
dengan pelanggan untuk memahami harapan dan kebutuhan yang tepat. Ini
merupakan kegiatan yang sangat penting dan perlu dikelola dengan baik, karena
sebagian besar pelanggan tidak yakin tentang apa yang sebenarnya mereka
butuhkan Acceptance test desain dilakukan pada tahap ini sebagai kebutuhan
bisnis dapat digunakan sebagai masukan untuk pengujian penerimaan.

2) System Design
Setelah Anda memiliki persyaratan produk yang jelas dan rinci, sekarang
saatnya untuk merancang
sistem yang lengkap. Desain sistem akan memiliki pemahaman dan merinci
hardware lengkap dan setup komunikasi untuk produk dalam pengembangan.
Rencana pengujian sistem dikembangkan berdasarkan desain sistem.
Melakukan hal ini pada tahap awal membuat lebih banyak waktu untuk
pelaksanaan tes yang sebenarnya nanti

3) Architectural Design
spesifikasi arsitektur dipahami dan dirancang dalam fase ini. Biasanya lebih dari
satu pendekatan teknis diusulkan dan berdasarkan kelayakan teknis dan
finansial keputusan akhir diambil. Desain sistem dipecah lebih jauh ke dalam
modul mengambil fungsi yang berbeda. Hal ini juga disebut sebagai “Desain
Tingkat Tinggi”

4) Module Design
Pada fase ini, desain internal rinci untuk semua modul sistem yang ditentukan,
disebut “Desain Tingkat Rendah”. Penting bahwa desain tersebut kompatibel
dengan modul lain dalam arsitektur sistem dan sistem eksternal lainnya.

5) Coding Phase
Bahasa pemrograman yang paling cocok ditentukan berdasarkan sistem dan
persyaratan arsitektur. pengkodean dilakukan berdasarkan pedoman coding dan
standar. Kode berjalan melalui berbagai ulasan kode dan dioptimalkan untuk
kinerja terbaik sebelum final membangun diperiksa ke dalam repositori

Fase Validasi berbeda dalam V-Model dijelaskan secara rinci di bawah ini:
– Unit Testing
unit testing adalah pengujian pada tingkat kode dan membantu menghilangkan
bug pada tahap awal, meskipun semua cacat tidak dapat ditemukan oleh unit
testing.
– Integration Testing
Integration testing dikaitkan dengan fase desain arsitektur. tes integrasi
dilakukan untuk menguji koeksistensi dan komunikasi dari modul internal dalam
sistem.
– System Testing
System testing secara langsung berhubungan dengan tahap desain sistem.
System testing memeriksa seluruh fungsi sistem dan komunikasi sistem dalam
pengembangan dengan sistem eksternal. Sebagian besar perangkat lunak dan
perangkat keras masalah kompatibilitas dapat ditemukan selama pelaksanaan
test ini
– Acceptance Testing
Acceptance testing dikaitkan dengan tahap analisis kebutuhan bisnis dan
melibatkan pengujian produk di lingkungan pengguna. Acceptance testing
mengungkap masalah kompatibilitas dengan sistem lain yang tersedia di
lingkungan pengguna. Juga menemukan masalah non-fungsional seperti beban
dan kinerja cacat pada aktual lingkungan pengguna.

Kelebihan dari V-Model SDLC

• Ini adalah model yang sangat-disiplin dan Tahapan selesai satu per satu.
• Bekerja dengan baik untuk proyek-proyek yang lebih kecil dimana persyaratan
dipahami dengan baik.
• Sederhana dan mudah dimengerti dan digunakan.
• Mudah dikelola karena setiap fase memiliki spesifik kiriman dan proses review.

Kekurangan dari V-Model SDLC

• Berisiko tinggi dan ketidakpastian.
• Tidak cocok untuk proyek-proyek yang kompleks dan berorientasi objek.
• Tidak cocok untuk proyek-proyek dimana persyaratan beresiko tinggi
• Tidak cocok untuk proyek-proyek yang lama dan berkelanjutan.
• Setelah aplikasi dalam tahap pengujian, sulit untuk kembali dan mengubah
fungsionalitas.
8. Big Bang Model

Pengertian dari SDLC Big Bang Model adalah Dimana kita tidak mengikuti
proses tertentu. Perkembangan hanya dimulai dengan uang dan usaha yang
dibutuhkan sebagai masukan, dan hasilnya adalah perangkat lunak yang
dikembangkan yang mungkin atau mungkin tidak sesuai dengan kebutuhan
pelanggan. Model Big Bang ini tidak mengikuti dan hanya ada sedikit
perencanaan yang diperlukan. Bahkan pelanggan pun tidak yakin dengan apa
yang sebenarnya dia inginkan dan persyaratannya diimplementasikan dengan
cepat tanpa banyak analisis.

Biasanya model ini di implementasi untuk proyek kecil dimana tim developernya
sangat sedikit.

Spesifikasi Big Bang Model SDLC

Model Big Bang terdiri dari memfokuskan semua sumber daya yang mungkin
dalam pengembangan perangkat lunak dan pembuatan code / coding, dengan
perencanaan yang sangat sedikit atau tidak sama sekali. Requirement yang
dibutuhkan terkadang datang pada saat pembuatan code. Setiap perubahan
yang diperlukan mungkin atau mungkin tidak perlu mengubah perangkat lunak
yang lengkap.

Big Bang Model ini sangat ideal untuk proyek kecil dengan satu atau dua
pengembang yang bekerja sama dan juga berguna untuk pembelajaran atau
project-project yang sangat kecil
Keuntungan dan Kelebihan Big Bang Model SDLC
Keuntungan dari Model Big Bang ini adalah sangat sederhana dan memerlukan
perencanaan yang sangat sedikit atau tidak sama sekali. Mudah untuk
mengelola dan tidak ada prosedur formal yang diperlukan.

Namun Big Bang model ini sangat beresiko tinggi dikarenakan dipastikan
seringnya terjadi perbuhaan mengakibatkan kesalah pahaman antar developer
yang mengerjakan project tersebut. Ini sangat ideal untuk proyek berulang atau
kecil dengan risiko minimum.

Keuntungan Big Bang Model antara lain:

• Model yang sangat sederhana
• Sedikit atau tidak ada perencanaan yang dibutuhkan
• Mudah dikelola
• Sangat sedikit sumber daya yang dibutuhkan
• Memberikan fleksibilitas kepada pengembang
• Bagus untuk developer yang ingin belajar atau developer pendatang baru.

Kekurangan Big Bang Model antara lain:

• Beresiko tinggi dan kepastian dari requirement yang tidak jelas
• Tidak cocok untuk project skala besar dan berorientasi objek
• Model yang buruk untuk proyek yang panjang dan sedang berlangsung.
• Bisa berubah menjadi sangat mahal jika persyaratan disalahpahami
9. Rational Unified Process (RUP Model)

Menurut IBM adalah kerangka proses yang menyediakan simulasi sistem pada
industri untuk sistem, software, implementasi, dan manajemen proyek yang
efektif. RUP adalah salah satu dari sekian banyak proses yang terdapat di dalam
Rational Process Library, yang memberikan simulasi terbaik untuk
pengembangan atau kebutuhan proyek. RUP mempunyai beberapa tahapan,
yaitu :
1. Inception
merupakan tahap untuk mengidentifikasi sistem yang akan dikembangkan.
Aktivitas yang dilakukan pada tahap ini antara lain mencakup analisis sistem
existing, perumusan sistem target, penentuan arsitektur global target, identifikasi
kebutuhan, perumusan persyaratan (fungsional, performansi, keamanan, GUI,
dll), perumusan kebutuhan pengujian (level unit, integrasi, sistem, performansi,
fungsionalitas, keamanan, dll), UML diagram, dan pembuatan dokumentasi.

2. Elaboration
merupakan tahap untuk melakukan desain secara lengkap berdasarkan hasil
analisis pada tahap inception. Aktivitas yang dilakukan pada tahap ini antara lain
mencakup pembuatan desain arsitektur subsistem (architecture pattern), desain
komponen sistem, desain format data (protokol komunikasi), desain database,
desain user interface, pemodelan diagram UML (diagram sequence, class,
component, deployment, dll.), dan pembuatan dokumentasi

3. Construction
merupakan tahap untuk mengimplementasikan hasil desain dan melakukan
pengujian hasil implementasi. Pada tahap awal construction, ada baiknya
dilakukan pemeriksaan ulang hasil analisis dan desain, terutama desain pada
sequence diagram, class diagram, component dan deployment. Apabila desain
yang dibuat telah sesuai dengan analisis sistem, maka implementasi dengan
bahasa pemrogramanan tertentu dapat dilakukan. Aktivitas yang dilakukan pada
tahap ini antara lain mencakup pengujian hasil analisis dan desain, pendataan
kebutuhan implementasi lengkap (berpedoman pada identifikasi kebutuhan di
tahap analisis), penentuan coding pattern yang digunakan, pembuatan program,
pengujian, optimasi program, pendataan berbagai kemungkinan pengembangan
atau perbaikan lebih lanjut, dan pembuatan dokumentasi.

4. Transition
merupakan tahap untuk menyerahkan sistem aplikasi kepada user (roll-out),
yang umumnya mencakup pelatihan dan beta testing aplikasi
Aliran Kerja Rational Unified Process (RUP)
RUP juga mempunyai aliran kerja yang terbagi menjadi dua bagian, yaitu: Aliran
kerja utama dan Aliran kerja pendukung, dimana keduanya merupakan suatu
kesatuan dalam proses pengembangan sistem (SDLC)

Aliran Kerja Utama Rational Unified Process (RUP)

1. Business Modeling Pada tahap ini, terdapat identifikasi dan deskripsi langsung
dari area dan permasalahan untuk redesign atau reengineering, beserta struktur
dan proses–proses bisnis organisasi.

2. Requirements Tujuan utama pada fase ini adalah menyusun sistem apa yang
seharusnya ada dan mengapa perlu dibuat, mendefinisikan batas dari sistem,
melihat kemungkinan ancaman keamanan serta bagaimana cara
penanggulangannya, dan mengestimasi biaya dan skala waktu yang rumit. Isi
dari sistem dibangun yang kemudian diterjemahkan kedalam use case model
dengan tambahan spesifikasi kebutuhan. Baik kebutuhan fungsional dan
nonfungsional akan dikumpulkan dan dianalisis. Kebutuhan user dan stakeholder
serta fitur high-level didefinisikan dan kemudian diubah menjadi specific software
requirements.

3. Analysis and Design Pada fase ini, semua requirement pada tahap kedua
akan diubah menjadi spesifikasi implementasi.
4. Implementation Pada tahap ini, semua analisa dan desain yang telah dibuat
pada fase sebelumnya akan diimplementasikan dan diterjemahkan menjadi kode
program.

5. Testing Pada tahap ini, pengembang software akan menguji dan

memverifikasi semua interaksi komponen, kebutuhan yang telah
diimplementasikan dan kualitas dari software yang telah dikembangkan.

6. Deployment Pada tahap ini, pengembang software menyebarkan software

yang telah selesai kepada user. Pengembang software juga menyediakan
dokumentasi untuk semua fitur dan fungsi. Pada tahap ini juga, pengembang
software mendapatkan umpan balik dan masukan terhadap software yang
berujung pada modifikasi fungsi dan fitur agar menjadi lebih baik.

Aliran Kerja Pendukung Rational Unified Process (RUP)

1. Configuration and Change Management Tahap ini menjalankan dan merawat
integritas dari proyek. Kegiatannya meliputi monitoring dan mengatur perubahan
permintaan, perubahan biaya, dan tetap mengontrol berbagai versi produk.
Tahap ini juga meliputi manajemen konfigurasi hardware dan software.

2. Project Management Tahap ini menyediakan framework untuk mengatur

software dan resiko. Tahap ini juga menyediakan pedoman untuk planning,
staffing, monitoring dan secara umum menunjukan manajemen proyek.

3. Enviroment Tahap ini menjelaskan tentang infrastruktur dan metode yang

dibutuhkan untuk mengembangkan sistem
10. Prototype Model

Prototyping menjadi sangat populer sebagai model pengembangan software,

karena Memungkinkan untuk memahami kebutuhan pelanggan pada tahap awal
pengembangan. Ini membantu mendapatkan feedback yang berharga dari
pelanggan dan membantu developer memahami apa sebenarnya yang
diharapkan dari produk yang sedang dikembangkan.

Prototyping digunakan untuk memungkinkan client/user mengevaluasi sistem

yang di rancang di awal oleh developer dan mencobanya sebelum di
implementasikan. Hal ini dapat membantu memahami persyaratan
pembangunan sistem yang spesifik oleh user dan mungkin belum
implementasikan oleh developer selama perancangan produk.

Berikut adalah fase-fase garis besar perancangan prototype model:

1) Mengidentifikasi Kebutuhan Dasar
Fase ini untuk pemahaman kebutuhan dasar produk terutama dalam hal user
interface. Rincian desain internal dan eksternal yang lebih rumit seperti kinerja
dan keamanan dapat di abaikan pada tahap ini.

2) Develop Prototype awal

Fase ini untuk mengembangkan protype awal. dimana persyaratan yang sangat
mendasar dipamerkan dan user interface selesai di buat. Fitur-fitur ini mungkin
tidak bekerja dengan cara yang sama secara internal dalam perangkat lunak
yang sebenarnya dikembangkan. Sementara, workarounds digunakan untuk
memberikan tampilan dan nuansa yang sama kepada pelanggan dalam prototipe
yang dikembangkan.
3) Review Prototype
Fase ini untuk user/client melakukan review prototype yang sudah dirancang
oleh developer untuk memberikan feedback yang bertujuan untuk
penyempurnaan lebih lanjut sistem/software yang sedang dikembangkan.

Revisi dan Penyempurnaan Prototype

fase ini untuk membahas Feedback dan review yang sudah di dapatkan di fase
sebelumnya. Negosiasi antara client dan developer terjadi disini untuk
menentukan waktu perancangan serta biaya untuk perubahan sistem tersebut.
Perubahan sistem ini seharusnya sudah di setujui oleh ke 2 pihak (client &
developer) dan siklus development pun kembali dilanjutkan sesuai dengan revisi
dan client agar ekpektasi client terpenuhi.

Kelebihan Prototype
• Meningkatnya keterlibatan pengguna dalam produk bahkan sebelum
diimplementasi
• Karena model sistem yang di bangun di share ke user, maka user
mendapatkan pemahaman yang lebih baik tentang sistem yang sedang
dikembangkan.
• Mengurangi waktu dan biaya karena cacat dapat dideteksi jauh lebih awal.
• Feedback user yang cepat di awal dapat memberikan solusi yang lebih baik
• Fungsi yang tidak ada dapat diidentifikasi dengan mudah dan cepat
• Fungsi yang membingungkan dapat di hilangkan

Kekurangan Prototype
• Risiko analisis kebutuhan yang tidak mencukupi karena terlalu banyak
ketergantungan pada Prototipe
• Pengguna mungkin bingung dalam prototipe dan sistem sebenarnya.
• Upaya yang diinvestasikan dalam membangun prototip mungkin terlalu banyak
jika tidak dipantau tepat.
• Pengembang dapat mencoba untuk menggunakan kembali prototipe yang ada
untuk membangun sistem yang sebenarnya, Bahkan bila hal itu tidak layak
secara teknis.
11. RAD (Rapid Application Development) Model

metodologi pengembangan perangkat lunak (SDLC) yang menggunakan

pengabungan antara Prototype Model dengan Iterative Model. Prototipe adalah
model kerja yang secara fungsional setara dengan komponen produk.
Dalam model RAD (Rapid Application Development), modul fungsional
dikembangkan secara paralel sebagai prototip dan terintegrasi untuk membuat
produk yang lengkap untuk pengiriman produk yang lebih cepat. Dikarenakan
tidak ada rincian planning yang detail, maka memudahkan untuk melakukan
perubahan pada saat development berjalan.

RAD Model Design

Model RAD mendistribusikan tahap analisis, perancangan, pembuatan dan
pengujian ke dalam rangkaian siklus pengembangan jangka pendek yang
singkat.

Berikut adalah fase-fase dari RAD:

1) Business Modeling (Bisnis Model)
fase ini untuk perancangan dasar dari pengembangan produk berdasarkan
informasi dan distribusi informasi antar saluran bisnis. Analisis bisnis yang
lengkap dilakukan untuk menemukan informasi penting untuk bisnis, bagaimana
hal itu dapat diperoleh, bagaimana dan kapan informasi diproses dan faktor apa
yang mendorong arus informasi yang berhasil

2) Data Modeling (Data Model)

Fase ini untuk menganalisa informasi yang sudah dikumpulan dari fase Business
Modeling. semua kumpulan data diidentifikasi dan didefinisikan secara rinci
untuk mencari model bisnis yang tepat.

3) Process Modeling (Proses Pemodelan)

Fase ini untuk untuk menetapkan arus informasi bisnis yang diperlukan untuk
mencapai tujuan bisnis yang spesifik sesuai model bisnis. perubahan atau
penyempurnaan pada kumpulan objek data didefinisikan dalam fase ini.
Deskripsi proses untuk menambahkan, menghapus, mengambil atau
memodifikasi objek data diberikan.

4) Application Generation (Generasi Aplikasi)

Fase ini untuk Sistem yang sebenarnya dibangun dan pengkodean dilakukan
dengan menggunakan automatic tools i untuk mengubah model proses dan data
menjadi prototype yang aktual

5) Testing and Turnover

fase ini untuk pengujian keseluruhan sistem yang dibangun semua komponen
perlu diuji secara menyeluruh dengan cakupan uji yang lengkap. Dengan
pengujian yang lengkap dapat mengurangi risiko cacat sistem.

Kelebihan RAD (Rapid Application Development)

• Mudah mengakomodasi peruabahan sistem
• Progress development bisa di ukur
• Waktu iterasi bisa di perpendek menggunakan RAD Tools
• Mengurangi waktu development
• Mudah dalam menentukan dasar sistem
• Mempermudah feedback customer
• Cocok untuk proyek yang membutuhkan waktu pengembangan yang lebih
pendek.
• Cocok untuk sistem yang berbasis komponen dan terukur.

Kekurangan RAD (Rapid Application Development)

• Ketergantungan pada anggota bisnis tim untuk mengidentifikasi persyaratan
bisnis
• Hanya sistem yang bisa di modularized yang bisa dibangun menggunakan RAD
• Membutuhkan developer / designer yang berpengalaman
• Ketergantungan pada keterampilan model
• Kompleksitas manajemen
• Tidak dapat diterapkan pada proyek yang kecil / murah
12. Unified Process (UP) Model

Unified Process (UP) adalah metodologi pengembangan sistem berbasis objek.

Metode ini sudah menjadi salah satu metode yang banyak digunakan dalam
pengembangan sistem berorientasi objek. UP memperkenalkan pendekatan baru
untuk siklus hidup pengembangan sistem yang menggabungkan perulangan
(iterations) dan tahapan (phases) yang disebut dengan siklus hidup UP (UP life
cycle). UP mendefinisikan empat tahapan siklus hidup yaitu inception,
elaboration, construction, dan transition.

Langkah–Langkah Unified Process (UP)

1) Inception phase
Seperti di dalam setiap tahap perencanaan proyek, fase awal dimulai dari
seorang manajer proyek mengembangkan dan menyempurnakan visi untuk
sistem baru, menunjukkan bagaimana hal tersebut akan meningkatkan operasi
dan memecahkan masalah yang ada. Pada dasarnya, manajer proyek akan
membuat kasus bisnis untuk sistem baru, membuktikan bahwa manfaat sistem
baru akan lebih besar daripada biaya pembangunan (construction). Ruang
lingkup sistem juga harus didefinisikan sehingga jelas apakah proyek ini akan
berhasil dicapai atau tidak. Mendefinisikan ruang lingkup meliputi identifikasi
semua persyaratan utama untuk sistem. Tahap awal biasanya diselesaikan
dalam satu iterasi, dan di dalam iterasi tersebut, bagian dari sistem yang
sebenarnya dapat dirancang, dilaksanakan dan diuji. Sebagai perangkat lunak
yang dikembangkan, anggota tim harus mengkonfirmasi bahwa visi system
masih sesuai harapan pengguna.

2) Elaboration phase
Fase elaborasi biasanya melibatkan beberapa iterasi, dan iterasi awal biasanya
menyelesaikan identifikasi dan definisi dari semua persyaratan sistem. Karena
UP adalah pendekatan adaptif untuk pembangunan, persyaratan diharapkan
berkembang dan berubah setelah dimulainya proyek. Tahapan iterasi pada
elaborasi juga melengkapi analisis, desain, dan pelaksanaan arsitektur inti
sistem. Biasanya, aspek dari sistem yang menimbulkan resiko terbesar
diidentifikasi dan dilaksanakan terlebih dahulu sampai pengembang mengetahui
persis bagaimana aspek tertinggi resiko proyek akan bekerja. Pada akhir fase
elaborasi, manajer proyek harus memiliki perkiraan yang lebih realistis untuk
biaya proyek dan jadwal, dan kasus bisnis atas proyek dapat dikonfirmasi
terlebih dahulu.

Salah satu tujuan utama dari fase elaborasi adalah untuk melakukan penelitian
yang diperlukan data atau fakta sehingga semua kebutuhan pengguna
diidentifikasikan secara jelas dan rinci.

3) Construction phase
Tahap konstruksi melibatkan beberapa iterasi yang meneruskan atau
melanjutkan desain dan implementasi sistem. Arsitektur inti dan aspek tertinggi
resiko sistem sudah selesai pada tahap ini. Fokus utama di dalam tahap ini
adalah bagaimana merinci sistem kontrol, seperti validasi data, fine-tuning antar
muka pengguna desain, menyelesaikan fungsi pemeliharaan data rutin, dan
menyelesaikan bantuan serta preferensi penggunaan fungsi.

4) Transistion phase
Selama fase transisi atau tahap akhir dari UP, satu atau lebih iterasi akhir yang
melibatkan penerimaan pengguna (end users), beta tes akhir, dan sistem dibuat
siap untuk dioperasikan. Setelah sistem ini beroperasi, maka akan perlu
didukung dan dipertahankan fungsi kegunaan dari sistem tersebut.
Unified Process Discipline (UDP)
Unified Process Discipline adalah sekumpulan kegiatan–kegiatan fungsional
yang saling terkait atau berhubungan satu sama lain, yang mengabungkan dan
memungkinkan pengembangan proses di dalam proyek UP.
13. Extreme Programming

Extreme Programming (XP) merupakan suatu pendekatan yang paling banyak

digunakan untuk pengembangan perangkat lunak cepat. Alasan menggunakan
metode Extreme Programming (XP) karena sifat dari aplikasi yang di
kembangkan dengan cepat melalui tahapan-tahapan yang ada meliputi :
Planning/Perencanaan, Design/Perancangan, Coding/Pengkodean dan
Testing/Pengujian. (Pressman, 2012:88).

Adapun tahapan pada Extreme Programming dapat di jelaskan sebagai berikut

1) Planning/Perencanaan
Pada tahap perencanaan ini dimulai dari pengumpulan kebutuhan yang
membantu tim teknikal untuk memahami konteks bisnis dari sebuah aplikasi.
Selain itu pada tahap ini juga mendefinisikan output yang akan dihasilkan, fitur
yang dimiliki oleh aplikasi dan fungsi dari aplikasi yang dikembangkan.

2) Design/Perancangan
Metode ini menekankan desain aplikasi yang sederhana, untuk mendesain
aplikasi dapat menggunakan Class-Responsibility-Collaborator (CRC) cards
yang mengidentifikasi dan mengatur class pada object-oriented.

3) Coding/Pengkodean
Konsep utama dari tahapan pengkodean pada extreme programming adalah pair
programming, melibatkan lebih dari satu orang untuk menyusun kode.

4) Coding/Pengujian
Pada tahapan ini lebih fokus pada pengujian fitur dan fungsionalitas dari aplikasi.