System Development Life Cycle
Nama : Refky Ahmad Fauzi
Npm : 16116136
Dosen : Arbi Pramana
System
Development Life Cycle
System Development Life Cycle ( SDLC) atau Daur
hidup pengembangan system adalah suatu proses yang yang digunakan oleh analis
sistem untuk mengembangkan suatu sistem informasi, mulai dari requirement
(kebutuhan), study kelayakan, analisa & design system, Pengkodean dan
Testing.
Berikut gambar dari model daur hidup pengembangan
perangkat lunak :
Sebelumnya kita harus mengetahui tahapan-tahapan
dari daur hidup pengembangan Software :
1.
Definisi
Masalah ( Kebutuhan User)
Lebih dulu hal yang paling penting diperlukan
untuk pengembangan software apapun
adalah sistem. Persyaratan sistem boleh bercycle didasarkan dengan menghasilkan
perangkat lunak yang akan dikembangkan ke depan. Maka suatu analisa harus
hati-hati tentang persyaratan sistem yang diperlukan untuk pengembangan dari
produk itu. Setelah analisa dan disain dari tahap persyaratan sistem sistem
yang diperlukan untuk pengembangan akan lengkap dan konsentrasi dapat l kedalam
proses pengembangan software.
2.
Studi
Kelayakan
Setelah membuat suatu pendefinisian masalah maka
dilanjutkan pada langkah berikutnya yaitu untuk membuat analisa dari perangkat
lunak persyaratan itu. Dengan kata lain studi kelayakan adalah jsering disebut
juga analisa persyaratan perangkat lunak. Di tahap pengembangan ini harus
membuat komunikasi dengan pelanggan dan analisa dengan cara dilakukan suatu
penelitian. Dengan pembuatan analisa ini adalah mungkin membuat suatu laporan
mengenai masalah. Dengan pembuatan suatu analisa terperinci yang disajikan
dalam dokumen atau laporan sehingga dapat dilanjutkan ke dalam perencanaan
proyek, perancangan , penjadwalan serta biaya yang diperkirakan untuk
mengembangkan dan melaksanakan sistem itu.
3.
Analisis
& Design sistem
Ini tahap yang penting dalam pengembangan sistem
dimana melakukan perancangan sistem yang akan dikembangkan. Dengan kata lain
database mendisain, perancangan arsitektur yang dipilih, spesifikasi fungsional
disain, disain yang tingkat rendah dokumen, dokumen disain yang tingkat tinggi dan
seterusnya berlangsung. Kita harus menyiapkan dokumen disain ini sebab tahap
yang berikutnya yakni tahap pengembangan didasarkan pada dokumen disain ini.
Jika suatu sumur yang tersusun dan dianalisa dokumen disain disiapkan maka akan
mengurangi waktu untuk melakukan langkah-langkah berikutnya yakni pengembangan
dan menguji tahap dari pengembangan software.
4.
Pengkodean
pada tahap ini akan secara langsung dipraktekan pada
sistem yang sedang berlangsung. Desain Dokumen sudah disiapkan di nulai dari
tahap pengkodean awal ditulis di teknologi programming yang dipilih. Setelah
kode dikembangkan generasi dari kode juga berlangsung di tahap ini. Dengan kata
lain kode diubah jadi executables di tahap ini setelah generasi kode.
5.
Testing
Suatu perangkat lunak akan dilakukan pengujian untuk
menghasilkan produk yang berkwalitas. tahap ini akan mengetahui debugger atau
kesalahan dalam sistem yang sedang dibangun. Pada tahap ini berbeda dan metoda
uji didasarkan untuk koreksi dari kesalahan. Proses ini melanjut sampai sistem
dibebaskan dari kesalahan.
Suatu perangkat lunak akan dilakukan pengujian untuk
menghasilkan produk yang berkwalitas. tahap ini akan mengetahui debugger atau
kesalahan dalam sistem yang sedang dibangun. Pada tahap ini berbeda dan metoda
uji didasarkan untuk koreksi dari kesalahan. Proses ini melanjut sampai sistem
dibebaskan dari kesalahan.
SDLC akan menghasilkan suatu sistem yang berkualitas
sesuai requirement (kebutuhan) user dan dapat diselesaikan dalam waktu dan
biaya yang telah diperkirakan secara efektif dalam infrastruktur tehologi
informasi saat ini dan yang akan datang.
SDLC mudah dikembangkan dalam merespon berbagai
kebutuhan pemakai (user) dan lebih murah pemeliharaan serta hemat biaya dalam
pengembangan.
Sistem komputer sudah menjadi lebih kompleks dan
sering juga merupakan arsitektur yang berorientasi memenuhi kebutuhan user
dengan cara mengembangkan berbagai sistem yang konvensional (tradisional) agar
berpotensi sehingga dapat menyajikan berbagai perangkat lunak yang berbeda.
SDLC merupakan alur kerja standart yang biasa
dipakai oleh perusahaan-perusahaan vendor software dalam mengembangkan software
aplikasi produksinya. SDLC ini tidak hanya penting untuk proses produksi
software saja, namun terlebih juga sangat penting untuk proses maintenance
software itu sendiri, karena tanpa pengarsipan data-data development suatu
software, maka akan sangat menyulitkan perusahaan dalam maintenance software
tersebut dikemudian hari.
Beberapa model SDLC yang dikembangkan :
o
Waterfall
o
Concurrent
o
Spiral
o
Build and fix
o
Rapid prototyping
o
Incremental
o
Formal
Dari ke tujuh model SDLC lebih menandakan suatu
metodologi waterfall.
o
Waterfall
Waterwall Model, yang sering disebut juga classic
life cycle, adalah model klasik yang bersifat sistematis, berurutan dalam
membangun software (Proboyekti, 2006).
Model ini menyampaikan suatu pendekatan yang
berurutan untuk pengembangan perangkat lunak. Pengembangan dimulai dari
spesifikasi kebutuhan dan berlanjut dengan perencanaan, pemodelan, konstruksi,
dan penyerahan.
Langkah-langkah dalam waterfall sebagi berikut :
a. Spesifikasi Kebutuhan user
(Requirment User)
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.
b. Software Design
Desain dikerjakan setelah kebutuhan selesai
dikumpulkan secara lengkap.
c. Construction Coding (pengkodean)
Desain program diterjemahkan ke dalam kode-kode
dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang
dibangun langsung diuji baik secara unit.
d. Integrasi (integration)
Penyatuan unit-unit program secara keseluruhan.
e. Testing
Setalah penyatuan program secara keseluruhan maka
dilakukan pengujian (system testing).
Beberapa macam bentuk testing :
o
Data set testing
o
Unit testing
o
Sistem testing
o
Integrasi testing
o
Blackbox testing
o
Whitebox testing
o
Modul testing
o
Regresi testing
o
Otomasi testing
f. Implementasi
Mengoperasikan program dilingkungannya oleh pengguna/user
g. Pemeliharaan (Maintenance)
Melakukan pemeliharaan, seperti penyesuaian atau
perubahan karena adaptasi dengan situasi sebenarnya.
Model ini juga mencerminkan kepraktisan engineering
karena ketika sudah berada diakhir fase jika terjadi kesalahan akan lebih mudah
diperbaiki. Namun kelemahan metode ini adalah ketika suatu fase sudah terlewati
dan ada perubahan kebutuhan sesuai keinginan pemakai/user terkadang model ini
sulit untuk diakomodasi. Dampaknya akan menyebabkan kebingungan bagi tim
pembuat. Sehingga keadaan ‘block state’ atau status terblok akan terjadi. Block
state bisa terjadi ketika beberapa anggota tim harus menunggu anggota lain team
ini untuk menyelesaikan tugas yang ada kaitannya. Akibatnya, waktu yang
diperlukan untuk menunggu bisa melebihi waktu produktif yang diperlukan untuk
mengerjakan tugasnya.
Secara umum masalah-masalah yang sering terjadi
dalam model ini adalah :
Perubahan sulit dilakukan karena sifatnya yang kaku.
Karena sifat kakunya, model ini cocok ketika kebutuhan
dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin.
Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan
kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar
terjadi.
Waterfall pada umumnya digunakan untuk rekayasa
sistem yang besar dimana Proyek dikerjakan di beberapa tempat berbeda, dan
dibagi menjadi beberapa bagian sub-Proyek
Concurrent
Model ini dapat direpresentasikan secara sistematis
sebagai sederatan aktifitas teknis utama, pekerjaan dan state berikutnya.
Spiral
Spiral model memadukan prototyping model dengan
waterfall model. Sistem dikembangkan dengan menggabungkan antara
langkah-langkah pengembangan sistem yang menekankan pada
pengulangan-pengulangan dengan cara pengembangan sistem yang menekankan pada
sistematika dan kontrol.
Spiral model adalah model proses yang dipicu oleh
resiko, dimana digunakan untuk memandu banyak stakeholder bersama-sama membangun
perangkat lunak sistem.
Spiral model merupakan suatu pendekatan realistis
untuk pengembangan sistem skala besar. Hal ini karena sistem berkembang
sebagaimana proses berkembang, pengembang dan pengguna memiliki pemahaman yang
lebih baik dan reaksi terhadap resiko pada level evolusioner. Pengguna dan
pembangung bisa memahami dengan baik software yang dibangun karena setiap
kemajuan yang dicapai diamati dengan baik.
Langkah-langkah pada model spiral :
a. Menentukan tujuan
Menentukan tujuan dari fase yang ditentukan.
Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah
disiapkan. Resiko dari Proyek sudah diketahui. Alternatif strategi sudah
disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan.
b. Menilai resiko dan pengurangannya
Setiap resiko dianalisis secara detil pada sektor
ini. Langkah-langkah penanganan dilakukan, misalnya membuat prototype untuk
mengetahui ketidakcocokan kebutuhan.
c. Pengembangan dan validasi
Setelah evaluasi resiko, maka model pengembangan
sistem dipilih. Misalnya jika resiko user interface dominan, maka membuat
prototype User Interface. Jika bagian keamanan yang bermasalah, maka
menggunakan model formal dengan perhitungan matematis, dan jika masalahnya
adalah integrasi sistem model waterfall lebih cocok.
d. Perencanaan
Proyek dievaluasi atau ditinjau-ulang dan diputuskan
untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase
berikutnya rencana untuk loop selanjutnya.
Build
And Fix
Model Build dan Fix yang juga diketahui sebagai
pembangunan Ad-Hoc adalah struktur yang paling lemah dari metodologi putaran
hidup pembangunan sistem ( System Development Life Cycle ). Model ini sangat
mengandalkan keahlian individu dari anggota tim, kebanyakan tugas-tugasnya
dikerjakan oleh satu orang. Dengan metode Build dan Fix, pembangun /developers
menulis beberapa kode, kemudian berlanjut untuk memodifikasinya sampai kode
tersebut dapat bekerja dan konsumen puas. Dengan perencanaan yang kurang,
strategi ini dapat beresiko, dan jika dijalankan seenaknya dapat menyusahkan si
pembangun dalam melakukan maintenance / pemeliharaan terhadap softwaretersebut.
Model ini tidak cocok digunakan pada saat ini karena
alasan sebagai berikut :
o
Software dibangun untuk orang atau
instansi yang tidak memiliki keahlian komputer.
o
Kebutuhan tahan uji dan kenyamanan yang
lebih besar.
o
Aktifitas group atau team work yang
sangat perlu dilakukan.
Selain itu di model paling sederhana dalam
pembangunan software ini, produk dibangun dengan kebutuhan yang minimal dan
umumnya tidak ada spesifikasi ataupun usaha di dalam desainnya dan tes terhadap
softwarepun sering kali dilupakan. Model ini adalah representasi dari segala
hal yang terjadi di banyak Proyel pembangunan software. Walaupun begitu model
ini memiliki keuntungannya sendiri di dalam beberapa situasi
RAPID
PROTOTYPING
Rapid Prototyping mengacu pada pembuatan model yang
pada akhirnya lebih banyak ditolak daripada diterima oleh client sebagai bagian
dari produk akhir. Setelah apa yang dibutuhkan terkumpul maka dibuatlah suatu
model simpel yang dapat bekerja sehingga bisa menunjukkan kepada pemakai/user
apa yang ada dalam model tersebut merupakan gambaran singkat terhadap produk
akhir yang akan dihasilkan nantinya.
Jika pemakai/user cepat memberikan masukan pada apa
yang mereka butuhkan maka dapat dilakukan perubahan dalam pengembangannya lebih
cepat.
Incremental
Incremental model memadukan elemen-elemen waterfall
model yang diterapkan dalam suatu cara yang berulang-ulang. Ketika incremental
model digunakan, maka produk pertama adalah selalu core product (produk inti).
Ini adalah kebutuhan dasar yang harus diselesaikan, dan fasilitas-fasilitas
pendukung belum diselesaikan. Produk inti tersebut bukanlah berupa prototype,
melainkan produk yang sudah bisa berfungsi dengan spesifikasi dasar. Produk
inti digunakan oleh customer atau menjalani evaluasi terinci. Sebagai hasil
dari penggunaan dan atau evaluasi adalah pembuatan rencana untuk produk
tambahan berikutnya. Perencanaan mencakup modifikasi produk inti menjadi lebih
baik memenuhi kebutuhan customer dan memberikan fasilitas dan fungsi tambahan.
Proses ini diulang-ulang hingga produk yang lengkap dihasilkan.
Pengembangan secara incremental sangat berguna
ketika staf yang dimiliki tidak mencukupi untuk implementasi menyeluruh dari
batas waktu yang tersedia untuk menyelesaikan Proyek. Produk awal dapat
diimplementasikan dengan jumlah orang yang lebih sedikit. Jika produk inti
diterima dan disetujui, staf tambahan (jika diperlukan) dapat ditambahkan untuk
mengimplementasikan produk tambahan berikutnya.
Formal
Metoda Formal ini digunakan di bidang software.
Bahkan, sebetulnya Metoda Formal lebih awal digunakan di bidang software. Akan
tetapi tampaknya hasil yang positif lebih banyak terlihat di bidang hardware,
hal ini mungkin disebabkan oleh beberapa hal :
o
Hardware memiliki kompleksitas lebih
kecil dibandingkan software
o
Disainer hardware lebih terbiasa
menggunakan paradigma reuse, yaitu menggunakan komponen dasar yang sudah
standar yang bisa diverifikasi secara individual (misalnya, jarang disainer
membuat AND gate sendiri, biasanya tinggal menggunakan standard cell, bahkan
untuk skala besar menggunakan IP core), sementar software designer belum
dipaksa menggunakan metoda reuse (berapa banyak metoda untuk melakukan sort
Setiap disainer dapat membuat metoda sendiri-sendiri).
Sebagian besar
perusahaan menggunakan metodologi proses pengembangan software.
Diantaranya perusahaan industri dalam proses industrinya memerlukan otomasi
guna mempercepat pekerjaan dan menghemat biaya.
Kendala dalam pengembangan software adalah :
o
Dana
o
Waktu
o
Struktur organisasi
Suatu Organisasi boleh menciptakan suatu Proses
Software/Perangkat Lunak yang rancang-bangun
guna peningkatan proses. Terdiri atas praktisi yang sudah memiliki
ketrampilan dalam organisasi tersebut.
Sebagian besar Software dibuat secara custom-built, serta
tidak dapat
dirakit dari komponen yang sudah ada.
Karakteristik dari produk software :
1. Maintainanbility
2. Dependability
3. Efficiency
4. Usability
Proses (produksi) software, yaitu:
o
Spesifikasi software
o
Pengembangan software
o
Validasi (pengetesan dan pengujian).
o
Evolusi, pengembangan lanjutan IEEE
telah mengembangkan definisi yang lebih komprehensif
Software engineering : aplikasi dari sebuah
pendekatan kuantifiabel, disiplin, dan sistematis kepada pengembangan, operasi,
dan pemeliharaan software.
software telah berkembang dari sebuah alat analisis
dan pemecahan masalah yang terspesialisasi di dalam industri itu sendiri.
Tetapi budaya dan sejarah pemrograman sebelumnya telah menciptakan serangkain
masalah yang sekarang muncul. Software telah menjadi faktor pembatas dalam
evolusi sistem berbasis komputer. Software dirancang dari program-program,
data, dan dokumen. Masing – masing dari item tersebut terdiri dari sebuah
konfigurasi yang diciptakan sebagai bagian dari proses pengembangan software.
Tujuan software engineering adalah menyediakan sebuah kerangka kerja guna
membangun software dengan kualitas yang lebihtinggi.
Software engineering adalah sebuah disiplin ilmu
yang mengintergrasikan
proses, metode, dan alat – alat bantu bagi
perkembangan proses perangkat lunak komputer.
Model – model proses untuk software engineering
seperti model sekuensial linier, model prototipe, model RAD, model inkremental,
model spiral, model asembli komponen, model pengembangan kongkuren dan model
metode formal.
Model
sekuensial linier
model sekuensial linier melingkupi aktivitas –
aktivitas sebagai berikut :
1. Rekayasa dan pemodelan
sistem/informasi
Pandangan sistem ini penting ketika software harus
berhubungan dengan elemen-elemen yang lain seperti software, manusia, dan
database. Rekayasa dan anasisis system menyangkut pengumpulan kebutuhan pada
tingkat sistem dengan sejumlah kecil analisis serta disain tingkat puncak.
Rekayasa informasi mancakup juga pengumpulan kebutuhan pada tingkat bisnis
strategis dan tingkat area bisnis.
v Analisis
kebutuhan Software
Proses pengumpulan kebutuhan diintensifkan dan
difokuskan, khususnya pada software. Untuk memahami sifat program yang
dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja,
dan interface yang diperlukan. Kebutuhan baik untuk sistem maupun software
didokumentasikan dan dilihat lagi dengan pelanggan.
v Desain
Desain software sebenarnya adalah proses multi
langkah yang berfokus pada empat atribut sebuah program yang berbeda, struktur
data, arsitektur software, representasi interface, dan detail (algoritma)
prosedural.
v Generasi
Kode
Desain harus diterjemahkan kedalam bentuk mesin yang
bisa dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan
dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.
v Pengujian
Sekali program dibuat, penujian Software akan
mengalami perubahan setelah disampaikan kepada pelanggan (perkecualian yang
mungkin adalah software yang dilekatkan). Perubahan akan terjadi karena
kesalahan – kesalahan ditentukan, karena software harus disesuaikan untuk
mengakomodasi perubahan – perubahan di dalam lingkungan eksternalnya (contohnya
perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem
operasi yang baru), atau karena pelanggan membutuhkan perkembangan fungsional
atau unjuk kerja.
Pemeliharaan
Software mengaplikasikan lagi setiap fase program
sebelumnya dan tidak membuat yang baru lagi.gujian program dimulai. Proses
pengujian berfokus pada logika internal software, memastikan bahwa semua
pernyataan sudah diuji, dan pada eksternal fungsional, yaitu mengarahkan
pengujian untuk menemukan kesalahan – kesalahan dan memastikan bahwa input yang
dibatasi akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.
Model
prototype
Prototyping paradigma dimulai dengan pengumpulan
kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif
keseluruhan dari software, mengidentifikasi segala kebutuhan yang diketahui,
dan area garis besar diman definisi lebih jauh merupakan keharusan kemudian
dilakukan “perancangan kilat”. Perancangan kilat berfokus pada penyajian dari
aspek – aspek software tersebut yang akan nampak bagi pelanggan atau pemakai
(contohnya pendekatan input dan format output). Perancangan kilat membawa kepada
konstruksi sebuah prototipe. Prototipe tersebut dievaluasi oleh
pelanggan/pemakai dan dipakai untuk menyaring kebutuhan pengembangan software.
Iterasi terjadi pada saat prototipe disetel untuk memenuhi kebutuhan pelanggan,
dan pada saat yang sama memungkinkan pengembang untuk secara lebih baik memahami
apa yang harus dilakukannya.
Penjelasan mengenai model RAD, model inkremental,
model spiral, model asembli komponen, model pengembangan kongkuren dan model
metode formal sudah diterangkan sebelumnya.
Build
And Fix
Model Build dan Fix yang juga diketahui sebagai
pembangunan Ad-Hoc adalah struktur yang paling lemah dari metodologi putaran
hidup pembangunan sistem ( System Development Life Cycle ). Model ini sangat
mengandalkan keahlian individu dari anggota tim, kebanyakan tugas-tugasnya
dikerjakan oleh satu orang. Dengan metode Build dan Fix, pembangun /developers
menulis beberapa kode, kemudian berlanjut untuk memodifikasinya sampai kode
tersebut dapat bekerja dan konsumen puas. Dengan perencanaan yang kurang,
strategi ini dapat beresiko, dan jika dijalankan seenaknya dapat menyusahkan si
pembangun dalam melakukan maintenance / pemeliharaan terhadap softwaretersebut.
Model ini tidak cocok digunakan pada saat ini karena
alasan sebagai berikut :
o
Software dibangun untuk orang atau
instansi yang tidak memiliki keahlian komputer.
o
Kebutuhan tahan uji dan kenyamanan yang
lebih besar.
o
Aktifitas group atau team work yang
sangat perlu dilakukan.
Selain itu di model paling sederhana dalam
pembangunan software ini, produk dibangun dengan kebutuhan yang minimal dan
umumnya tidak ada spesifikasi ataupun usaha di dalam desainnya dan tes terhadap
softwarepun sering kali dilupakan. Model ini adalah representasi dari segala
hal yang terjadi di banyak Proyel pembangunan software. Walaupun begitu model
ini memiliki keuntungannya sendiri di dalam beberapa situasi
Sumber
https://anitamegayanti.wordpress.com/category/software-engineering/system-development-life-cycle/
Komentar
Posting Komentar