System Development life

Nama : Rico Septa Dwi A

Npm : 16116332

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

http://refky27.blogspot.co.id