Gambar 3.2 Mekanisme Pengembangan Sistem dengan Prototype
Sumber :
Abdul Kadir. 2003. Pengenalan Sistem Informasi. Andi. Yogyakarta
Tahapan-tahapan prototyping yaitu : 1. Identifikasi Kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar system
yang akan dibuat. 2. Membangun Prototyping
Membangun Prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan misalnya dengan membuat input
dan formatoutput
3. Evaluasi Protoptyping Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun
sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai maka langkah 4 akan diambil, jika tidak prototyping direvisi dengan mengulangi 1, 2 dan 3.
4. Mengkodekan Sistem Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam
bahasa pemrograman yang sesuai. 5. Menguji Sistem
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black
Box, Basis Path, pengujian arsitektur dan lain-lain 6. Evaluasi Sistem
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan
5. 7. Menggunakan sistem
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.
Kelebihan Prototype
1. Pendefinisian kebutuhan pemakai menjadi lebih baik karena keterlibatan pemakai yang lebih intensif.
2. Meningkatkan kepuasan pemakai dan mengurangi resiko pemakai tidak menggunakan sistem mengingat keterlibatan mereka yang sangat tinggi
sehinga sistem memenuhi kebutuhan mereka dengan lebih baik.
3. Mempersingkat waktu pengembangan. 4. Memperkecil kesalahan disebabkan pada setiap versi prototipe, kesalahan
segera terdeteksi oleh pemakai. 5. Pemakai memiliki kesempatan yang lebih banyak dalam meminta perubahan-
perubahan. 6. Menghemat biaya.
Kelemahan Prototype
1. Prototype hanya bisa berhasil jika pemakai bersungguh-sungguh dalam menyediakan waktu dan pikiran untuk menggarap prototype.
2. Kemungkinan dokumentasi
terabaikan karena
pengembang lebih
berkonsentrasi pada pengujian dan pembuatan prototype. 3. Mengingat target waktu yang pendek, ada kemungkinan sistem yang dibuat
tidak lengkap dan bahkan sistem kurang teruji. 4. Jika terlalu banyak proses pengulangan dalam membuat prototype, ada
kemungkinan pemakai menjadi jenuh dan memberikan reaksi yang negatif. 5. Apabila tidak dikelola dengan baik, prototype menjadi tidak pernah berakhir.
Hal ini disebabkan permintaan terhadap perubahan terlalu mudah untuk dipenuhi.
3.2.3.3. Alat Bantu Analisis dan Perancangan
Sesuai dengan metode pendekatan sistem yang digunakan yaitu metode berorientasi objek, maka penulis memakai pemodelan dengan notasi UML
Unified Modeling Language. Untuk mendapatkan banyak pandangan terhadap sistem informasi yang akan dibangun, UML menyediakan beberapa diagram
visual yang menunjukkan berbagai aspek dalam sistem. Ada 6 diagram yang digunakan oleh penulis, yaitu:
a. Diagram Use Case
Diagram Use Case atau use case diagram merupakan pemodelan untuk kelakuan behaviour sistem informasi yang akan dibuat. Use case
mendeskripsikan sebuah interaksi antara satu atau lebih aktor dengan sistem informasi yang akan dibuat. Secara kasar, use case digunakan untuk
mengetahui fungsi apa saja yang ada di dalam sebuah sistem informasi dan siapa saja yang berhak menggunakan fungsi-fungsi itu. Syarat penamaan pada
use case adalah nama didefinisikan sesimpel mungkin dan dapat dipahami. Ada dua hal utama pada use case yaitu pendefinisian apa yang disebut aktor
dan use case.
b. Diagram Activity
Activity Diagram atau diagram aktivitas menggambarkan workflow aliran kerja atau aktivitas dari sebuah sistem atau proses bisnis. Yang perlu
diperhatikan disini adalah bahwa diagram aktivitas menggambarkan aktivitas sistem bukan apa yang dilakukan aktor, jadi aktivitas yang dapat dilakukan
oleh sistem.
c. Diagram Sequential
Diagram sequential atau sequence diagram menggambarkan kelakuan objek pada use case dengan mendeskripsikan waktu hidup objek dan message yang
dikirimkan dan diterima antar objek. Oleh karena itu untuk menggambar diagram sekuen maka harus diketahui objek-objek yang terlibat dalam sebuah
use case beserta metode-metode yang dimiliki kelas yang diinstansiasi menjadi objek itu. Banyaknya diagram sequence yang harus digambar adalah
sebanyak pendefinisian use case yang memiliki proses sendiri atau yang penting semua use case yang telah didefinisikan interaksi jalannya pesan
sudah dicakup pada diagram sequence sehingga semakin banyak use case yang didefinisikan maka diagram sequence yang harus dibuat juga semakin
banyak
d. Diagram Class
Class diagram atau kelas diagram menggambarkan struktur sistem dari segi pendefinisian kelas-kelas yang akan dibuat untuk membangun sistem. Kelas
memiliki apa yang disebut atribut variabel-variabel yang dimiliki oleh suatu kelas dan metode atau operasi fungsi-fungsi yang dimiliki oleh suatu kelas.
Kelas-kelas yang ada pada struktur sistem harus dapat melakukan fungsi- fungsi sesuai dengan kebutuhan sistem.
e. Diagram Component
Component diagram atau komponen diagram dibuat untuk menunjukkan organisasi dan ketergantungan di antara kumpulan komponen dalam sebuah
sistem. Diagram komponen fokus pada komponen sistem yang dibutuhkan dan ada di dalam sistem. Komponen dasar yang biasanya ada dalam suatu
sistem adalah komponen user interface yang menangani tampilan, komponen business processing yang menangani fungsi-fungsi proses bisnis, komponen
data yang menangani manipulasi data, dan komponen security yang menangani keamanan sistem.
f. Diagram
Deployment
Deployment diagram atau deployment diagram menunjukkan konfigurasi komponen dalam proses eksekusi aplikasi. Diagram deployment juga dapat
digunakan untuk memodelkan hal-hal berikut: 1. Sistem tambahan embedded system yang menggambarkan rancangan
device, node, dan hardware. 2. Sistem clientserver
3. Sistem terdistribusi murni 4. Rekayasa ulang aplikasi
3.2.4. Pengujian Software
Pengujian perangkat lunak software menggunakan metode pengujian Black Box. Pengujian Black Box berfokus pada persyaratan fungsional perangkat
lunak software yang dibuat. Dengan demikian, pengujian Black Box memungkinkan perekayasa
perangkat lunak mendapatkan serangkaian kondisi input yang sepenuhnya menggunakan semua persyaratan fungsional untuk suatu program.
Pengujian Black Box berusaha menemukan kesalahan dalam kategori sebagai berikut:
1. Fungsi-fungsi yang tidak benar atau hilang 2. Kesalahan interface
3. Kesalahan dalam struktur data atau akses database eksternal 4. Kesalahan kinerja
5. Inisialisasi dan kesalahan terminasi.