Paradigma Prototyping Untuk Pengembangan Perangkat Lunak

Seringkali, pelanggan mendefinisikan seperangkat tujuan umum untuk pembuatan atau pengembangan perangkat lunak, tetapi tidak mengidentifikasi persyaratan atau kebutuhan secara terperinci untuk fungsi dan fitur. Dalam kasus lain, pengembang perangkat lunak mungkin tidak yakin dengan efisiensi algoritma, kemampuan beradaptasi sistem operasi, atau bentuk interaksi manusia-mesin yang harus diambil. Dalam situasi ini, dan banyak situasi lainnya, paradigma pembuatan prototipe mungkin menawarkan pendekatan terbaik.

Meskipun prototyping dapat digunakan sebagai model proses yang berdiri sendiri, ini lebih umum digunakan sebagai teknik yang dapat diimplementasikan dalam konteks salah satu model proses yang disebutkan dalam kebutuhan pengembangan perangkat lunak. Terlepas dari cara penerapannya, paradigma pembuatan prototipe membantu Anda dan pemangku kepentingan lainnya untuk lebih memahami apa yang akan dibangun ketika persyaratan atau kebutuhan perangkat lunak tidak jelas.

Gambar 1. Paradigma Prototyping

Communication

Dimulai dengan komunikasi. sebagai pengembang perangkat lunak bertemu dengan pemangku kepentingan lain untuk menentukan tujuan keseluruhan perangkat lunak, mengidentifikasi persyaratan atau kebutuhan apa pun yang diketahui, dan menguraikan area yang mengharuskan definisi lebih lanjut.

Quick Plan

Sebuah iterasi prototipe planned quickly, dan pemodelan (dalam bentuk “desain cepat”) terjadi.

Modeling Quick Design & Construction of prototype

Desain cepat berfokus pada representasi aspek perangkat lunak yang akan terlihat oleh pengguna akhir (misalnya, tata letak antarmuka manusia atau format tampilan keluaran). Desain cepat mengarah pada pembangunan prototipe.

Deployment Delivery & Feedback

Prototipe digunakan dan dievaluasi oleh para pemangku kepentingan, yang memberikan umpan balik yang digunakan untuk menyempurnakan persyaratan atau kebuthan lebih lanjut. Iterasi terjadi saat prototipe diatur untuk memenuhi kebutuhan berbagai pemangku kepentingan, sementara pada saat yang sama memungkinkan pengembang peragkat untuk lebih memahami apa yang perlu dilakukan.

Meskipun beberapa prototipe dibuat sebagai “lemparan”, yang lain bersifat evolusioner dalam arti bahwa prototipe tersebut perlahan-lahan berkembang menjadi sistem yang sebenarnya. Baik pemangku kepentingan dan pengembang perangkat lunak menyukai paradigma pembuatan prototipe. Pengguna bisa merasakan sistem yang sebenarnya, dan pengembang bisa segera membangun sesuatu.

Pembuatan prototipe bisa menjadi masalah karena alasan berikut:

  1. Pemangku kepentingan melihat apa yang tampak sebagai versi yang berfungsi dari perangkat lunak, tetapi tidak menyadari bahwa prototipe disatukan secara sembarangan, tidak menyadari bahwa pembuatan perangkat lunak tersebut terburu-buru dalam membuatnya berfungsi, Pengembang perangkat lunak belum mempertimbangkan kualitas perangkat lunak secara keseluruhan atau pemeliharaan jangka panjang. Ketika diinformasikan bahwa produk harus dibangun kembali sehingga tingkat kualitas yang tinggi dapat dipertahankan, para pemangku kepentingan akan marah dan menuntut agar “beberapa perbaikan” diterapkan untuk membuat prototipe produk yang berfungsi. Terlalu sering, manajemen pengembangan perangkat lunak mengalah.
  2. Sebagai seorang pengembang perangkat lunak, sering membuat kompromi implementasi untuk membuat prototipe bekerja dengan cepat. penggunaan sistem operasi atau bahasa pemrograman yang tidak sesuai digunakan hanya karena tersedia dan diketahui; algoritma yang tidak efisien dapat diimplementasikan hanya untuk mendemonstrasikan kemampuan

Setelah beberapa saat, pengembang perangkat lunak mungkin merasa nyaman dengan pilihan ini dan melupakan semua alasan mengapa itu tidak pantas. Pilihan yang kurang ideal kini telah menjadi bagian integral dari sistem.

Sumber Pustaka:
Pressman, R. S., & Maxim, B. R. (2015). Software Engineering: A Practitioner’s Approach. In McGraw-Hill Education (Eighth, Vol. 8). New York City: McGraw-Hill Education. PDF