Transcript Pertemuan11_Pengembangan-Sistem-Informasi-3

Pertemuan 10
Sistem Informasi
Viska Armalina, S.T., M.Eng

Sifatnya kaku, sehingga susah melakukan perubahan di
tengah proses

Proyek nyata sulit untuk mengikuti alur proses

Membutuhkan daftar kebutuhan yang lengkap di awal

Kesulitan jika terjadi perubahan kebutuhan
◦ Waktu pengerjaan bertambah
◦ Ada anggota tim yang harus menunggu pekerjaan tim lain
◦ Kesabaran customer/klien




Membuat suatu program dengan cepat dan bertahap
sehingga dapat segera dievaluasi oleh pemakai
Waterfall  spesifikasi harus rinci
Prototipe  hasilkan  evaluasi
Model ini cocok untuk digunakan pada kondisi
dimana kebutuhan pemakai sulit untuk
diidentifikasi
Pada dasarnya prototipe akan membuat versi kasar
dari program/bagian dari program dengan cepat
untuk bisa dicoba dan dianalisis oleh pengguna

Menurut Lucas (2000), sasaran dari prototipe
adalah sbb :
◦ Memberikan “wujud” dari usaha pengembangan sistem
◦ Menyediakan umpan balik yang cepat dari pemakai kepada
pengembang
◦ Membantu menggambarkan kebutuhan pemakai dengan
kesalahan yang lebih sedikit
◦ Meningkatkan pemahaman pengembang dan pemakai
terhadap sasaran yang seharusnya dicapai oleh sistem
◦ Menjadikan keterlibatan pemakai sangat berarti dalam
analisis dan desain sistem
Identifikasi
Kebutuhan
Pemakai
• Pemakai dan
pengembang
bertemu
• Pemakai
menjelaskan
kebutuhan
sistem
Membuat
Prototipe
• Pengembang
mulai membuat
prototipe
Menguji
Prototipe
• Pemakai
menguji dan
memberikan
kritik atau
saran
Memperbaiki
Prototipe
Versi
Produksi
• Modifikasi
sesuai masukan
pemakai
• Pengembang
merampungkan
sistem sesuai
masukan
terakhir
pemakai

◦
◦
◦
◦

◦
◦
◦
◦
Prototipe Evolusioner
Prototipe yang secara terus menerus diperbaiki
Mencapai pemenuhan kriteria sistem
Setelah itu baru memasuki proses produksi
Hasil akhirnya suatu sistem yang nyata
Prototipe Requirement
Digunakan ketika pengguna tidak mampu mengungkapkan
dengan tepat apa yang mereka butuhkan
Model ini akan ditinjau seiring dengan ditambahkannya
fitur-fitur
Harapannya yaitu pengguna akan mampu mendefinisikan
pemrosesan yangdibutuhkan dari sistem yang baru
Prototipe ini tidak selalu menjadi sistem yang nyata




Identifikasi kebutuhan pengguna
Mengembangkan Prototipe
Identifikasi kekurangan Prototipe
Pengembangan sistem final






Identifikasi kebutuhan pengguna
Mengembangkan Prototipe
Menentukan apakah prototipe bisa digunakan atau
tidak
Memprogram sistem baru
Menguji sistem baru
Mempertimbangkan apakah suatu sistem dapat
diterima atau tidak




Komunikasi antara pengguna dan pengembang
meningkat
Pengembang dapat mempelajari dan mengetahui
kebutuhan-kebutuhan pengguna secara tepat
Implementasi akan lebih mudah sebab pengguna
mengetahui apa yang akan didapat dari sistem
yang baru
Dpat menekan biaya-biaya pengembangan dan
meningkatkan kepuasan pengguna terhadap
sistem yang disediakan



Kebutuhan akan kecepatan dapat menyebabkan
pengembang mengambil jalan pintas
Pengguna mungkin sangat terkesan terhadap prototipe,
sehingga produk akhir tidak sempurna
Biaya yang membengkak terkadang menjadikan
pengembangan terhenti ditengah jalan






Keterlibatan pemakai lebih intensif  definisi
kebutuhan lebih baik
Kepuasan pemakai  sistem digunakan
Mempersingkat waktu pengembangan
Memperkecil kesalahan pada versi-versi prototipe
 koreksi cepat
Pemakai memiliki kesempatan yang lebih banyak
dalam meminta perubahan
Menghemat biaya  10%-20% daripada SDLC
tradisional





Pembuatan prototipe membutuhkan kesungguhan
pemakai dalam meluangkan waktu dan pikiran
Pembuatan + Pengujian  kemungkinan
dokumentasi terabaikan
Harus cepat  sistem tidak lengkap, kurang teruji
Terlalu banyak prototipe  pemakai jenuh, respon
negatif
Never ending prototyping  pengelolaan buruk,
perubahan selalu dipenuhi