Pertemuan 10 Sistem Informasi Viska Armalina, S.T., M.Eng

 Sifatnya kaku, sehingga susah melakukan perubahan di tengah proseskaku  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

Versi Produksi Pengembang merampungkan sistem sesuai masukan terakhir pemakai Memperbaiki Prototipe Modifikasi sesuai masukan pemakai Menguji Prototipe Pemakai menguji dan memberikan kritik atau saran Membuat Prototipe Pengembang mulai membuat prototipe Identifikasi Kebutuhan Pemakai Pemakai dan pengembang bertemu Pemakai menjelaskan kebutuhan sistem

 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