Model Pengembangan Sistem - dinus.ac.iddinus.ac.id/repository/docs/ajar/3#APS_Model_Pengembangan_Sistem... · bereaksi terhadap resiko setiap tingkat evolusi karena perangkat lunak

MODEL PENGEMBANGAN

SISTEM

CHAPTER 3

08/03/2014 Model Pengembangan Sistem -- Ika Menarianti, M.Kom

1

Pada pengembangan sistem terdapat beberapa model yaitu:

1. Waterfall

2. Prototype

3. Spiral

08/03/2014

Model Pengembangan Sistem -- Ika Menarianti, M.Kom 2

WATERFALL

• Model yang mengusulkan pendekatan perkembangan perangkat lunak

yang sistematik dan sekunsial yang dimulai pada tingkat dan kemajuan

sistem pada seluruh analisis, desain , kode, pengujian, dan

pemeliharaan

08/03/2014


WATERFALL LANJ. 2

Tahapan Pengujian

Proses pengujian dilakukan pada logika internal untuk memastikan semua pernyataan

sudah diuji.

Pengujian eksternal fungsional untuk menemukan kesalahan-kesalahan dan

memastikan bahwa input akan memberikan hasil yang aktual sesuai yang dibutuhkan.

Tahapan Pemeliharaan

Perangkat lunak yang sudah disampaikan kepada pelanggan pasti akan mengalami

perubahan.

Perubahan terjadi karena mengalami kesalahan karena perangkat lunak harus

menyesuaikan dengan lingkungan baru atau pelanggan membutuhkan perkembangan

fungsional.

08/03/2014


WATERFALL LANJ. 3

Keunggulan Waterfall:

Mudah diaplikasikan

Memberikan template tentang metode analisis, desain,

pengkodean, pengujian, dan pemeliharaan

08/03/2014


WATERFALL LANJ. 4

KelemahanWaterfall:

Jarang sekali proyek riil mengikuti aliran sekuensial yang dianjurkan

model ini.

Pelanggan sulit untuk menyatakan kebutuhan secara eksplisit

sehingga sulit untuk megakomodasi ketidakpastian pada saat awal

proyek

Pelanggan harus bersikap sabar karena harus menunggu sampai

akhir proyek dilalui.

Pengembang sering malakukan penundaan karena anggota tim

proyek harus menunggu tim lain untuk melengkapi tugas

waktu tidak efesien

08/03/2014


PROTOTYPE

Merupakan salah satu metode pengembangan

perangkat lunak yang banyak digunakan.

Dengan metode ini pengembang dan pelanggan dapat

saling berinteraksi selama proses pembuatan sistem.

Customer hanya mendefinisikan secara umum apa

yang dikehendakinya tanpa menyebutkan secara

detail output apa saja yang dibutuhkan, pemrosesan

dan data-data apa saja yang dibutuhkan.

08/03/2014


PROTOTYPE LANJ. 1

Kunci keberhasilan model ini adalah dengan

mendefinisikan aturan-aturan main pada saat

awal, yaitu pelanggan dan pengembang harus

setuju bahwa prototype dibangun untuk

mendefinisikan kebutuhan.

08/03/2014


TAHAPAN PROTOTYPE

1. Pengumpulan Kebutuhan

Pelanggan dan pengembang mendefinisikan format

seluruh perangkat lunak, mengidentifikasikan semua

kebutuhan, dan garis besar sistem yang akan dibuat.

2. Membangun Prototype

Membuat perancangan sementara (membuat format input

dan output)

08/03/2014


TAHAPAN PROTOTYPE

3. Evaluasi

Evaluasi dilakukan oleh pelanggan apakah prototye yang dibangun

sudah sesuai dengan keinginan pelanggan.

Jika sudah sesuai proses dilanjutkan, jika tidak proses diulang dari

awal

4. Mengkodekan Sistem

prototype yang sudah disepakati diterjemahkan ke dalam bahasa

pemrograman.

5. Menguji Sistem

Pengujian dilakukan dengan White Box, Black Box, Basis Path,

pengujian arsitektur dan lain-lain.

08/03/2014


TAHAPAN PROTOTYPE

6. Evaluasi Sistem

Apakah sistem yang sudah jadi sudah sesuai dengan

yang diharapkan. Jika sudah sesuai tahapan dilanjutkan,

jika tidak diulangi dari proses ke 4

7. Menggunakan Sistem

Perangkat lunak yang telah diuji dan diterima

pelanggan siap untuk digunakan

08/03/2014


PROTOTYPE LANJ. 2

Keunggulan :

Adanya komunikasi yang baik antara pengembang dan pelanggan

Pengembang dapat bekerja lebih baik dalam menentukan

kebutuhan pelanggan

Pelanggan berperan aktif dalam pengembangan sistem

Lebih menghemat waktu dalam pengembangan sistem

Penerapan menjadi lebih mudah karena pemakai mengetahui apa

yang diharapkannya

08/03/2014


PROTOTYPE LANJ. 3

Kelemahan :

Pelanggan kadang tidak menyadari bahwa perangkat lunak yang ada

belum mencantumkan kualitas perangkat lunak secara keseluruhan

dan belum memikirkan kemampuan pemeliharaan untuk jangka

waktu lama.

Pengembang ingin cepat menyelesaikan proyek, sehingga

menggunakan algoritma dan bahasa pemrograman yang sederhana.

Hubungan pelanggan dengan komputer yang disediakan mungkin

tidak mencerminkan teknik perancangan yang baik.

08/03/2014


PROTOTYPE LANJ. 4

Kapan model ini digunakan:

• Resiko tinggi untuk masalahyang tidak terstruktur dengan baik, ada

perubahan yang besar dari waktu ke waktu, dan adanya persyaratan

data yang tidak menentu.

• Interaksi pemakai penting sistem harus menyediakan dialog on-line

antara pelanggan dan komputer.

• Perlunya penyelesaian yang cepat

• Perilaku pemakai yang sulit ditebak

• Sitem yang inovatif sistem membutuhkan cara penyelesaian

masalah dan penggunaan perangkat keras yang mutakhir.

• Perkiraan tahap penggunaan sistem yang pendek

08/03/2014


SPIRAL

Model spiral pada awalnya diusulkan oleh Boehm.

Adalah model proses perangkat lunak evolusioner yang merangkai

sifat iteratif dari prototype dengan cara kontrol dan aspek sistematis

model sequensial linier.

Model iteratif ditandai dengan tingkah laku yang memungkinkan

pengembang mengembangkan versi perangkat lunak yang lebih

lengkap secara bertahap.

Perangkat lunak dikembangkan dalam deretan pertambahan.

Selama awal iterasi, rilis dapat berupa model/prototype kertas,

kemudian sedikit demi sedikit dihasilkan versi sistem yang lebih

lengkap.

08/03/2014


TAHAPAN SPIRAL

08/03/2014


TAHAPAN SPIRAL LANJ. 1

Komunikasi pelanggan: tugas-tugas untuk membangun

komunikasi antara pelanggan dan kebutuhan-kebutuhan

yang diinginkan oleh pelanggan.

Perencanaan: tugas-tugas untuk mendefinisikan sumber

daya, ketepatan waktu, dan proyek informasi lain yg

berhubungan.

Analisa Resiko: tugas-tugas yang dibutuhkan untuk

menaksir resiko manajemen dan teknis.

08/03/2014


TAHAPAN SPIRAL LANJ. 2

Perekayasaan: tugas yang dibutuhkan untuk membangun

satu atau lebih representasi dari aplikasi.

Konstruksi dan Peluncuran: tugas-tugas yang dibutuhkan

untuk mengkonstruksi, menguji, memasang dan memberi

pelayanan kepada pemakai.

Evaluasi: tugas-tugas untuk mendapatkan umpan balik

dari pelanggan.

08/03/2014


SPIRAL LANJ. 1

Kelebihan :

• Lebih cocok untuk pengembangan sistem dan perangkat lunak skala

besar.

• Pengembang dan pemakai dapat lebih mudah memahami dan

bereaksi terhadap resiko setiap tingkat evolusi karena perangkat

lunak terus bekerja selama proses.

• Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan

memasukkannya ke dalam kerangka kerja iteratif.

• Membutuhkan pertimbangan langsung terhadap resiko teknis

sehingga mengurangi resiko sebelum menjadi permasalahan yang

serius.

08/03/2014


SPIRAL LANJ. 2

Kelemahan :

• Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner

ini bisa dikontrol.

• Memerlukan penaksiran resiko yang masuk akal dan akan menjadi

masalah yang serius jika resiko mayor tidak ditemukan dan diatur.

• Butuh waktu lama untuk menerapkan paradigma ini menuju

kepastian yang absolut.

08/03/2014


RAPID APPLICATION

DEVELOPMENT (RAD)

• RAD adalah model proses pembangunan perangkat lunak

yang menggunakan batas waktu.

• RAD menekankan pada siklus pembangunan yang

pendek/singkat karena mengadopsi model waterfall.

• Waktu yang singkat adalah batasan yang penting, jika

kebutuhan lengkap dan jelas maka waktu yang dibutuhkan

untuk menyelesaikan secara komplit perangkat lunak yang

dibuat.

08/03/2014


FASE RAD

• Business modelling: harus dapat menjawab pertanyaan: informasi

apa yang mengendalikan proses bisnis? Informasi apa yang

dihasilkan? Siapa yang menghasilkan informasi? Kemana informasi

diberikan? Siapa yang mengolah informasi?

kebutuhan dari sistem

• Data modelling: aliran informasi yang sudah didefinisikan, disusun

menjadi sekumpulan objek data. Ditentukan karakteristik/atribut dan

hubungan antar objek

analisis kebutuhan dan data

08/03/2014


FASE LANJ. 1

• Process Modelling: objek data yang sudah didefinisikan diubah

menjadi aliran informasi yang diperlukan untuk menjalankan fungsi-

fungsi bisnis.

• Application Generation: RAD menggunakan komponen program yang

sudah ada atau membuat komponen yang bisa digunakan lagi,

selama diperlukan.

• Testing and Turnover: karena menggunakan komponen yang sudah

ada, maka kebanyakan komponen sudah melalui uji, tapi setiap

komponen dan interface masih tetap harus di uji

08/03/2014


KELEMAHAN

• Tidak cocok untuk proyek skala besar

• Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi

• Sistem yang tidak bisa di modularisasi tidak cocok untuk

model ini

• Resiko teknis yang tinggi juga kurang cocok

08/03/2014


Documents

Model Pengembangan Sistem - dinus.ac.iddinus.ac.id/repository/docs/ajar/3#APS_Model_Pengembangan_Sistem... · bereaksi terhadap resiko setiap tingkat evolusi karena perangkat lunak