Model-model SDLC (System Development Life Cycle)
blog postingan pertama
1. Tradisional 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
• Integrasi dilakukan sebagai “big-bang. Di akhir, yang tidak
memungkinkan mengidentifikasi setiap teknologi atau bisnis hambatan atau
tantangan awal.
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. Spiral 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
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.
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.
Konsep utama dari tahapan pengkodean pada extreme programming adalah
pair programming, melibatkan lebih dari satu orang untuk menyusun kode.
Pada tahapan ini lebih fokus pada pengujian fitur dan fungsionalitas dari aplikasi.
