System Development Life
Cycle disingkat dengan SDLC. SDLC merupakan siklus
pengembangan sistem. Pengembangan sistem teknik (engineering system
development). SDLC berfungsi untuk menggambarkan tahapan-tahapan utama dan
langkah-langkah dari setiap tahapan.
Tahapan System Development Life
Cycle (SDLC)
SDLC meliputi tahapan berikut:
1. System
initiation ialah
perencanaan awal untuk sebuah proyek guna mendefinisikan lingkup, tujuan,
jadwal dan anggaran bisnis awal yang diperlukan untuk memecahkan masalah atau kesempatan
yang direpresentasikan oleh proyek. Lingkup proyek mendefinisikan area bisnis
yang akan ditangani oleh proyek dan tujuan-tujuan yang akan dicapai. Lingkup
dan tujuan pada akhirnya berpengaruh pada komitmen sumber yaitu jadwal dan
anggaran yang harus dibuat supaya berhasil menyelesaikan proyek.
2. System
analysis ialah
studi domain masalah bisnis untuk merekomendasikan perbaikan dan
menspesifikasikan persyaratan dan prioritas bisnis untuk solusi. Analisis
system ditujukan untuk menyediakan tim proyek dengan pemahaman yang lebih
menyeluruh terhadap masalah-masalah dan kebutuhan-kebutuhan yang memicu proyek.
Area bisnis dipelajari dan dianalisis untuk memperoleh pemahaman yang lebih
rinci mengenai apa yang bekerja, apa yang tidak bekerja dan apa yang dibutuhkan.
3. System
design ialah
spesifikasi atau konstruksi solusi yang teknis dan berbasis komputer untuk
persyaratan bisnis yang diidentifikasikan dalam analisis sistem. Selama desain
sistem, pada awalnya akan mengekspolarasi solusi teknis alternatif. Setelah
alternatif solusi disetujui, fase desain sistem mengembangkan cetak biru
(blueprint) dan spesifikasi teknis yang dibutuhkan untuk mengimplementasikan
database, program, antarmuka pengguna dan jaringan yang dibutuhkan untuk sistem
informasi, System implementation ialah konstruksi, instalasi, pengujian dan
pengiriman sistem ke dalam produksi (artinya operasi sehari-hari). Implementasi
sistem mengontruksi sistem informasi baru dan menempatkannya ke dalam operasi,
selanjutnya dilaksanakan pengujian.
Sejarah Perkembangan SDLC
Sejarah perkembangan System
Development Life Cycle (SDLC) diawali pada pertengahan tahun 60-an dimana
terjadi kegagalan yang sangat besar dalam penerapan aplikasi EDP (Electronic
Data Processing) untuk sistem-sistem besar, sebagian besar disebabkan tidak
adanya pengembangan sistem.
Sesudah terjadinya kegagalan
tersebut pada akhir tahun 60-an dan awal 70-an, kesadaran akan pentingnya
metodologi pengembangan sistem mulai tumbuh. Sejak itulah berbagai proposal
metodologi mulai dibuat dan penerapan mulai terlihat. Para desainer dari hampir
semua bidang metodologi pengembangan sistem informasi mempunyai pandangan yang
sama, yaitu: mereka telah mengetahui bahwa proses pengembangan sistem
informasi, baik yang berdasarkan komputer atau tidak, menyerupai dengan proses
pengembangan sistem engineering.
Hubungan dengan konstruksi dan
operasi berbagai jenis gedung, mesin, peralatan kimia yang merupakan contoh
perkembangan sistem informasi engineering, kita dapat meringkas tahap-tahap
proses secara umum perkembangan tersebut adalah perencanaan (planning),
analisis (analysis), desain (design), pelaksanaan (implementation) dan
perawatan (maintenance).
Dalam tahap perencanaan, kita
mengumpulkan informasi tentang permasalahan serta persyaratannya. Kemudian kita
menentukan kriteria dan pembatasan pemecahan, serta memberikan alternatif jalan
keluarnya. Dalam tahap analisis, kita menguji alternatif pemecahan berdasarkan
kriteria dan batasan-batasan. Analisis merupakan pusat dari semua proses
perkembangan. Tahap berikutnya yaitu desain, dapat dikatakan sebagai hasil dari
sistem baru. Tahap desain juga dapat dikatakan sebagai pemecahan yang optimum
atas sejumlah kebutuhan penting dari suatu set pada keadaan khusus atau sebagai
kegiatan kreativitas yang meliputi pembuatan barang baru dan berguna yang belum
pernah ada sebelumnya. Sistem yang tersusun dibentuk dan dioperasikan.
Perawatan dilakukan pada tiap sistem operasional.
Istilah daur/siklus hidup (life
cycle) pada suatu sistem digunakan untuk menjelaskan tahap-tahap perkembangan
sistem, serta langkah-langkah dalam proses perkembangannya. Untuk mengetahui
proses sistem informasi dan proses sistem engineering, kita harus membandingkan
daur/siklus hidup kedua sistem tersebut. Dengan mengetahui daur/siklus hidup
sistem informasi tahun 1960 sampai dengan tahun 1983, kita akan mengetahui
perbedaannya. Daur hidup sistem informasi sangat dekat dengan daur hidup yang
terjadi dalam sistem engineering; perencanaan, analisis, desain, pelaksanaan,
dan perawatan. Proses perkembangan sistem informasi merupakan proses
engineering.
Meskipun selama hampir dua puluh
tahun putaran sistem informasi, yang kurang lebih berisi langkah-langkah yang
sama, namun pemberian nama dan dukungan pada langkah-langkah tersebut belum
cukup untuk mengembangkan sistem informasi yang baik. Kekurangan tersebut
adalah bahwa pada tiap perkembangan sistem engineering terdapat beberapa
peralatan dan metodologi yang digunakan secara paralel dengan daur/siklus hidup
sistem tersebut. Kegagalan dalam menentukan tuntutan dan peran serta pemakai
dalam perkembangan sistem juga penyebab lain dari kegagalan sistem informasi,
demikian juga masalah sulitnya memperoleh komputer dari produsen, staf yang
tidak memenuhi syarat, batas waktu yang tidak realistis dan manajemen yang
tidak memadai.
Kesalahan interpretasi mengenai
tahap-tahap perkembangan sistem di atas adalah linier. Seolah olah semua fase
dan tahap terlihat berderet secara berurutan. Tetapi sebenarnya tidak demikian.
Semua tahap pada proses perkembangan sistem tersebut mempunyai sifat dasar yang
iteratif yaitu pekerjaan pada suatu tahap sering harus diulang-ulang, dan apa
pun yang dikerjakan pada suatu tahap mungkin perlu dikoreksi secara
keseluruhan.
Meskipun terdapat beberapa variasi
diantara masing-masing tahap, metode sistem klasik ternyata tidak cukup untuk
menghasilkan sistem informasi yang baik, kemudian sebagai tambahan pada
penamaan tahap-tahap dari suatu daur/siklus hidup sistem, kita harus mempunyai
beberapa peralatan dan teknik baku untuk mengembangkan sistem tersebut.
Aktifitas
di Tahapan SDLC
1. Project Planning
Definisi terhadap masalah bisnis
yang dihadapi oleh organisasi, perihal apa saja yang kiranya menghambat laju
kembangnya bisnis. Membuat project schedule yang disetujui bersama oleh para
stakeholders yang berkepentingan. Melaksanakan studi kelayakan (feasibility
study) dari projek yang akan dibangun. Memperkerjakan tim projek serta
mengalokasikan sumber daya yang dirasa perlu guna menunjang perampungan
projek. Meresmikan berjalannya projek.
2. Analysis
Mengumpulkan kebutuhan-kebutuhan
bisnis apa saja dari berbagai stakeholders yang berkepentingan. Mendefinisikan
kebutuhan-kebutuhan bisnis yang akan ditindaklanjuti guna diakomodir oleh
sistem yang akan dibangun. Membuat prototypes sederhana untuk memenuhi
kebutuhan-kebutuhan tersebut. Melakukan prioritasasi terhadap
kebutuhan-kebutuhan bisnis yang telah didefinisikan. Membuat dan mengevaluasi
alternatif-alternatif solusi untuk masing-masing kebutuhan tersebut. Mengulas
rekomendasi-rekomendasi solusi dengan pihak manajemen.
3. Design
Melakukan perancangan dengan
mengintegrasikannya dengan jaringan. Merancang arsitektur aplikasi yang akan
digunakan. Merancang tampilan layar untuk pengguna. Merancang system
interfaces. Merancang dan mengintegrasikan sistem dengan database. Membuat
prototypes untuk detil-detil perancangan. Membuat dan mengintegrasikan sistem
dengan system controls.
4. Implementation
Membangun komponen-komponen
perangkat lunak. Melakukan verifikasi dan uji coba terhadap sistem yang telah
selesai dibangun. Melakukan konversi data. Melatih para pengguna untuk
berinteraksi serta menyelesaikan tugas kerjanya dengan menggunakan sistem.
Membuat dokumentasi terhadap sistem yang telah selesai dibangun, yang dapat
berupa manual book, etc. Meng-install sistem di terminal-terminal PC yang
membutuhkan.
5. Activities
Melakukan pemeliharaan sistem dengan
pengecekan secara berkala/periodik. Memperkaya atau mengembangkan sistem dengan
penambahan fitur-fitur baru yang dapat meningkatkan kinerja kerja user guna
mendukung kinerja bisnis. Memberikan pelayanan kepada para users, seperti dalam
bentuk call center ataupun IT support.
Model-model SDLC
1.
Tradisional
SDLC
2.
Agile
SDLC
3.
Waterfall
SDLC
4.
Scrum
SDLC
5.
Iterative
SDLC
6.
Spiral
SDLC
7.
V
SDLC
8.
Big
Bang SDLC
9.
Rational
Unified Process (RUP) SDLC
10. Prototype SDLC
11. Rapid Aplication Development (RAD)
SDLC
12. Unified Process SDLC
1. Tradisional SDLC
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
·
Analisis
·
Perancangan
·
Implementasi
·
Penggunaan
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 SDLC
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 SDLC
3. Waterfall SDLC
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
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 SDLC
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
SDLC
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.
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.
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
SDLC
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 SDLC
Spiral
model memiliki 4 fase utama yaitu : Identification, Design, Construct or
Build, Evaluation and Risk Analysis
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.
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.
Construct or Build
Pada fase ini mengacu produksi produk perangkat lunak yang sebenarnya di setiap spiral.
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.
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.
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.
Construct or Build
Pada fase ini mengacu produksi produk perangkat lunak yang sebenarnya di setiap spiral.
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.
Berdasarkan
evaluasi pelanggan, proses pengembangan perangkat lunak memasuki tahap
iterative kemudian mengikuti pendekatan linier untuk menyelesaikan hasil
feedback klien Proses iterasi sepanjang spiral berlanjut sepanjang development
life cycle.
Spesifikasi Spiral Model
Spiral
model banyak digunakan dlam industri perangkat lunak seperti di sinkron dengan
proses perkembangan alami dari setiap produk, yaitu belajar dengan wakt
deadline yang melibatkan resiko minimum bagi klient serta perusahaan pengembang
sistem
Berikut adalah spesifikasi dari Spiral Model:
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 SDLC
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.
Ilustrasi
berikut menggambarkan berbagai tahap dalam V-Model SDLC.
Ada
beberapa tahapan verifikasi di V-Model, masing-masing dijelaskan secara rinci
di bawah:
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.
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
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"
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.
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 repository.
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 SDLC
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.
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
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:
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) SDLC
Apa
itu Rational Unified Process (RUP)? Pengertian Rational
Unified Process (RUP) 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
2. Elaboration
3. Construction
4. Transition
·
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.
·
Elaboration - 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
·
Construction - 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.
·
Transition - 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)
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.
10. Prototype Model SDLC
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:
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.
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.
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.
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.
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.
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) SDLC
Apa
itu RAD (Rapid Application Development)? RAD (Rapid Application
Development) Adalah 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.
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:
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
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.
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.
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
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.
Berikut adalah fase-fase dari RAD:
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
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.
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.
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
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 SDLC
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)
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.
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.
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.
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.
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.
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.
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.
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.
Setelah
kita tahu model-model SDLC, apasih manfaatnya belajar model-model itu ?
Sebagai standarisasi dalam pengembangan perangkat
lunak (software), dan model itu diakui oleh standarisasi IEEE, dan perlu
diingat model-model SDLC ini hanya digunakan untuk mengembangkan perangkat
lunak.
Tidak ada komentar:
Posting Komentar