MAKALAH
ANALISIS KEBUTUHAN PERANGKAT LUNAK
NAMA : RANI JUITA
NIM
: 41813120165
DOSEN : WACHYU HARI HAJI. S.Kom.MM
JURUSAN SISTEM INFORMASI
FAKULTAS ILMU KOMPUTER
UNIVERSITAS MERCU BUANA
JAKARTA
2015
ANALISIS KEBUTUHAN PERANGKAT LUNAK
Analisis kebutuhan perangkat lunak (software requirements analysis) merupakan aktivitas awal dari siklus hidup pengembangan perangkat lunak. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem information engineering dan software project planning. Tahap analisis adalah tahapan pengumpulan kebutuhan-kebutuhan dari semua elemen sistem perangkat lunak yang akan di bangun. Pada tahap ini dibentuk spesifikasi kebutuhan perangkat lunak, fungsi perangkat lunak yang dibutuhkan, performansi (unjuk kerja) sistem perangkat lunak, penjadwalan proyek, identifikasi sumber daya (manusia, perangkat keras dan perangkat lunak yang dibutuhkan) dan taksiran biaya pengembangan perangkat lunak. Kegunaan analisis adalah untuk memodelkan permasalahan dunia nyata agar dapat dimengerti. Permasalahan dunia nyata harus dimengerti dan dipelajari supaya spesifikasi kebutuhan perangkat lunak dapat diungkapkan. Tujuan aktivitas ini adalah untuk mengetahui ruang lingkup produk (product space) dan pemakai yang akan menggunakannya. Analisis yang baik akan mengungkapkan hal-hal yang penting dari permasalahan, dan mengabaikan yang tidak penting.
Setiap metode analisis mempunyai pandangan yang berbeda. Tetapi pada dasarnya semua metode analisis memiliki prinsip analisis yang sama, yaitu :
1. Menggambarkan domain informasi masalah 2. Mendefinisikan fungsi perangkat lunak
3. Menghasilkan model yang menggambarkan informasi, fungsi dan kelakuan yang dibagi secara rinci pada sebuah model lapisan (hirarki)
4. Informasi pokok pada tahap analisis memudahkan tahap implementasi yang lebih rinci. Tujuan tahap analisis adalah :
1. Menjabarkan kebutuhan pemakai
2. Meletakkan dasar-dasar untuk tahap perancangan perangkat lunak
3. Mendefinisikan semua kebutuhan pemakai sesuai dengan lingkup kontrak yang disepakati kedua belah pihak (pengembang dan pengguna).
A. KEBUTUHAN (REQUIREMENT)
Pengertian Kebutuhan Menurut arti kamus, kebutuhan adalah sesuatu yang diminta, sesuatu yang dibutuhkan. Sedangkan menurut IEEE (The Institute of Electrical and Electronics Engineers) kebutuhan adalah :
Kondisi atau kemampuan yang diperlukan pemakai untuk menyelesaikan suatu persoalan, atau untuk mencapai sebuah objek.
Kondisi atau kemampuan yang harus dipenuhi oleh sistem, dalam arti memenuhi kontrak, standar, spesifikasi atau dokumen formal lain yang diinginkan.
Tahap kebutuhan akan perangkat lunak dimulai dengan:
1. Dikenalinya adanya sebuah permasalahan yang membutuhkan sebuah penyelesaian. Identifikasi sebuah permasalahan mungkin dapat dilakukan dengan berorientasi pada aplikasi, berorientasi pada bisnis, atau berorientasi pada kenaikan produktivitas (product improvement oriented).
2. Munculnya ide untuk membuat sebuah perangkat lunak baru (sebagai sebuah kemajuan).
Ada dua jenis kebutuhan: 1). Behavioral
Adalah apa yang dilakukan oleh sistem (input dan output dari dan ke sistem), hubungan informasi antara input dan output sehingga menghasilkan sebuah fungsi transformasi. 2). Non-behavioral
Mendefinisikan atribut sistem yang terkait untuk membentuk pekerjaan tersebut. Termasuk deskripsi lengkap tentang efisiensi, keamanan (security), rehability maintenability (bagaimana perawatan untuk sistem), dan portability (bisa dipindahkan dari satu perangkat keras ke perangkat keras lainnya).
B. PRINSIP – PRINSIP ANALISIS
Lebih dari dua decade terakhir, para peneliti mengidentifikasi masalah – masalah analisis dan penyebab – penyebabnya, serta mengembangkan berbagai notasi pemodelan dan serangkaian penelitian yang sesuai untuk menanggulanginya. Masing – masing metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional:
Dominan informasi dari suatu masalah harus direpresentasikan dan dipahami. Fungsi – fungsi yang akan dilakukan oleh perangkat lunak harus di definisikan. Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus
diwakilkan.
Model – model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah – pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan (atau hirarki).
Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
Dengan mengaplikasikan prinsip – prinsip tersebut, analis mendekati suatu masalah secara sistematis. Domain informasi diuji sehingga fungsi itu dapat di pahami secara lebih lengkap. Model – model digunakan sehingga karakteristik fungsi dan tingkah laku dapat dikomunikasikan dengan cara yang rapi. Pembagian diterapkan untuk mengurangi keruwetan. Pandanagan esensial dan implementasi dari perangkat lunak diperlukan untuk mengakomodasi batasan logis yang dibebankan oleh persyaratan pemrosesan dan batasan fisik yang dibebankan oleh elemen system yang lain. Sebagai tambahan untuk prinsip analisis operasional tersebut, Davis [DAV95a] mengusulkan serangkaian 5 prinsip panduan untuk “rekayasa persyaratan”.
Mengembangkan prototype yang memungkinkan seorang pemakai memahami bagaimana interaksi manusia dengan mesin terjadi. Karena persepsi mengenai kualitas prangkat lunak sering di dasarkan pada persepsi “friendliness” interface, maka prototyping (dan terasi yang dihasilkan) sangatlah dianjurkan.
1. Merekam asal dan alas an untuk setiap persyaratan. Hal ini merupakan langkah pertama dalam membangun kemampuan penelusuran kembali ke pelanggan.
2. Menggunakan pandangan persyaratan bertingkat. Pembangunan data, fungsional, dan model tingkah laku member perekayasa perangkat lunak tiga pandangan berbeda. Hal ini mengurangi kemungkinan bahwa inkonsistensi akan diketahui.
3. Memprioritaskan persyaratan. Batas waktu yang tegas dapat menghalangi implementasi setiap persyaratan perangkat lunak. Bila model proses inkremental (Bab2) diaplikasikan, maka persyaratan yang disampaikan dalam inkremental pertama harus di identifikasi.
4. Berusaha mengurangi ambiguitas. Karena sebagian besar persyaratan di gambarkan dalam bahasa natural, kemungkinan untuk terjadinya ambiguitas selalu ada. Penggunaan kajian teknis formal merupakan satu – satunya cara untuk mengurangi ambiguitas tersebut.
5. Perekayasa perangkat lunak yang mempercayai prinsip tersebut akan dapat lebih mengembangkan spesifikasi perangkat lunak yang kemudian akan menjadi dasar yang kuat bagi desain.
1. Domain Informasi
Semua aplikasi perangkat lunak secara kolektif dapat disebut data processing. Menarik bahwa istilah itu berisi sebuah kunci ke pemahaman terhadap persyaratan perangkat lunak. Perangkat lunak dibangun untuk memproses data, menstraformasi data dari bentuk yang satu kebentuk yang lain, yaitu untuk menerima input, memanipulasinya dengan berbagai cara, dan menghasilkan output. Pernyataan mendasar dari sasaran ini benar bila kita membangun perangkat lunak batch untuk system daftar gaji atau perangkat lunak real-time embedded untuk mengontrol aliran bahan bakar ke mesin kendaraan bermotor.
Tetapi sangat penting untuk dicatat bahwa perangkat lunak juga memproses event. Event mewakili banyak aspek dari control system dan tidak lebih daripada data Boolean – baik on atau off, true or false, there or not there. Sebagai contoh, sensor tekanan mendeteksi bahwa tekanan melampaui batas nilai aman dan mengirimkan sebuah sinyal alarm ke monitoring perangkat lunak. Sinyal alarm tersebut merupakan suatu event yang mengontrol tingkah laku system. Dengan demikian, data (bilangan, karakter, citra, suara, dll) dan control (kejadian), keduanya ada pada domain informasi dari suatu masalah.
Prinsip analisis operasional yang pertama membutuhkan suatu pengujian domain informasi. Domain informasi berisi tiga pandangan yang berbeda dari data dan control ketika masing – masing dip roses oleh program computer:
a. Muatan dan hubungan informasi b. Aliran informasi
c. Struktur informasi
Untuk benar – benar memahami domain informasi, masing – masing dari pandangan tersebut harus diperhatikan. Muatan Informasi mewakili data dan objek control individual yang terdiri dari beberapa kumpulan informasi yang lebih besar yang di transformasikan oleh perangkat lunak. Misalnya, objek data paycheck merupakan sebuah gabungan dari sejumlah data yang penting : nama pembayar, jumlah bersih yang dibayarkan, pembayaran keseluruhan, potongan, dan seterusnya. Demikianlah, muatan dari paycheck ditentukan oleh atribut – atribut yang dibutuhkan untuk membuatnya. Dengan cara yang sama, muatan dari suatu objek control yang disebut status system dapat dibatasi oleh sebuah string dari banyak bit. Masing – masing bit mewakili jenis
informasi yang berbeda yang menunjukkan apakah perangkat tertentu itu on-line atau off-line.
Objek data dan control dapat dihubungkan dengan objek data dan control lainnya. Sebagai contoh, objek data paycheck memiliki satu hubungan atau lebih dengan objek timecard, employee, bank dan lain – lain. Selama analisis domain informasi, hubungan – hubungan itu harus ditetapkan.
Aliran informasi mewakili cara dimana data dan kontrol berubah pada saat masing – masing bergerak melalui sebuah system. Spereti diperlihatkan pada Gambar 11.3, objek input ditransformasikan ke informasi intermediate ( data dan atau control), dan lebih jauh lagi ditransformasikan ke output. Sepanjang jalur transformasi tersebut, informasi tambahan dapat dimunculkan dari penyimpanan data yang ada (seperti, file disket atau memory buffer). Transformasi yang diaplikasikan merupakan fungsi atau subfungsi yang harus dilakukan oleh sebuah program. Data dan control yang bergerak diantara dua (fungsi) transformasi menentukan interface dari masing” fungsi.
Struktur informasi mewakili organisasi internal dari berbagai jenis data dan control. Apakah jenis data akan diorganisasi sebagai sebuah table n-dimensi atau sebagai sebuah struktur pohon hirarki? Dalam konteks struktur, informasi apa yang dihubungkan dengan informasi lain? Apakah semua informasi di isikan ke dalam sebuah struktur tunggal atau akan digunakan struktur yang berbeda? Bagaimana informasi dalam suatu struktur informasi berhubungan dengan informasi pada struktur yang lain? Pertanyaan – pertanyaan tersebut dijawab dengan suatu penilaian struktur informasi. Harus dicatat juga bahwa struktur data, konsep yang berhubungan yang akan di diskusikan pada buku ini, mengacu pada perancangan dan implementasi informasi.
2. Pemodelan
Kita menciptakan model untuk memperoleh pemahaman yang lebih baik mengenai entitas actual yang akan dibangun. Bila entitas tersebut berupa sebuah bentuk fisik (bangunan, pesawat, mesin), kita dapat membangun model yang identik dalam bentuk dan potongan, tetapi dalam skala yang lebih kecil. Tetapi bila entitas yang akan dibangun adalah perangkat lunak, maka model harus memakai bentuk yang berbeda. Model harus dapat memodelkan informasi yang di transformasikan oleh perangkat lunak, fungsi (dan subfungsi) yang memungkinkan transformasi terjadi, dan tingkah laku system pada saat transformasi terjadi.
Selama analisis persyaratan perangkat lunak, kita menciptakan model system yang akan dibuat. Model tersebut berfokus pada apa yang harus dilakukan oleh system, bukan pada bagaimana system melakukannya. Dalam beberapa kasus, model yang kita buat menggunakan notasi grafis yang menggambarkan informasi, pemrosesan, tingkah laku system, dan karakteristik lain sebagai symbol yang berbeda dan dapat dikenali. Bagian lain dari model dapat benar – benar tekstual. Informasi deskriptif dapat diberikan dengan menggunakan bahasa natural atau bahasa khusus untuk menggambarkan persyaratannya.
Prinsip analisis operasional kedua dan ketiga mengharuskan kita membangun model fungsi dan tingkah laku :
1. Model fungsional.
Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat lunak harus melakukan paling tidak tiga fungsi genetic: input, pemrosesan, dan output. Pada saat model fungsional dari suatu aplikasi dibuat, perekayasa perangkat lunak memfokuskan dri pada fungsi – fungsi masalah khusus. Model fungsi dimulai dengan sebuah model tingkat konteks tunggal (yakni nama perangkat lunak yang akan dibuat). Dengan serangkaian iterasi , maka lebih banyak lagi detail fungsional diberikan, smapai seluruh rancangan dari semua fungsionalitas system terwakili. 2. Model tingkah laku.
Sebagian besar perangkat lunak merespon kejadian – kejadian dari dunia luar. Karakteristik stimulus-respon ini membentuk dasar dari model tingkah laku. Program computer selalu ada dalam pernyataan – suatu mode tingkah laku yang dapat di obeservasi secara eksternal (misalnya, penungguan, penghitungan, pencetakan, polling) yang diubah hanya pada saat beberapa event berlangsung. Contohnya, perangkat lunak akan tetap berada dalam wait state sampai (1) jam internal menunjukkan bahwa beberapa interval waktu telah berlalu, (2) satu event eksternal (misalnya, pergerakan mouse) menyebabkan suatu interupsi, atau (3) sebuah system eksternal member sinyal kepada perangkat lunak agar bergerak dengan beberapa cara. Model tingkah laku menciptakan representasi pernyataan – pernyataan perangkat lunak dan event – event yang menyebabkan perangkat lunak mengubah pernyataan.
Model yang diciptakan selama analisis persyaratan melayani sejumlah peran penting : Model membantu analisis dalam memahami informasi, fungsi, dan tingkah laku
suatu system, sehingga membuat tugas analisis persyaratan menjadi lebih mudah dan lebih sistematis.
Model menjadi titik focus bagi kajian sehingga merupakan kunci bagi penetuan kelengkapan, konsistensi, dan akurasi dari spesifikasi.
Model menjadi dasar bagi pengerjaan desain, member perancang suatu representasi esensial dari perrangkat lunak yang dapat diterjemahkan ke dalam suatu konteks implementasi.
3. Pembagian
Masalah sering menjadi terlalu luas atau terlalu rumit untuk dipahami sebagai salah satu kesatuan. Karena itulah kita cenderung membagi masalah seperti itu ke dalam bagian – bagian sehingga dapat dipahami dengan mudah dan kemudian membangun interface antara bagian – bagian tersebut, sehingga keseluruhan fungsi dapat dilakukan. Prinsip analisis operasional keempat menyatakan bahwa domain informasi, fungsional, dan tingkah laku perangkat lunak tidak dapat dibagi – bagi. Secara konseptual, kita membangun sebuah representasi hirarki dari informasi atau fungsi dan kemudian membagi elemen bagian paling atas (1). mengekpos detail pertambahan dengan bergerak secara vertical dalam hirarki (2). Mendekomposisi masalah dengan bergerak secara horizontal dalam hirarki.
Persyaratan untuk perangkat lunak Safe Home dapat dianalisis dengan pembagian domain informasi, fungsional, dan tingkah laku produk. Untuk mengilustrasikannya, domain fungsional dari masalah tersebut akan di bagi – bagi.
Pendekatan pembagian yang telah di aplikasikan pada fungsi – fungsi Safe-home juga dapat di aplikasikan padadomain informasi dan kelakuan system akan memberikan wawasan tambahan ke dalam persyaratan system. Pada saat masalah di bagi – bagi, interface di antara system – system ditarik. Data dan control yang bergerak melewati suatu interface harus dibatasi untuk input yang diperlukan untuk melakukan fungsi yang dinyatakan dan outputyang diperlukan oleh elemen fungsi atau system yang lain.
4. Pandangan Esensial dan Implementasi
Pandangan esensial persyaratan perangkat lunak menyajikan fungsi yang akan dikerjakan dan informasi yang akan diproses tanpa melihat detail implementasinya. Sebagai contoh, pandangan esensial dari fungsi Safe Home read sensor status tidak tergantung pada bentuk fisik dari data atau tipe sensor yang digunakan. Pada dasarnya, dapat diperdebatkan bahwa read status akan menjadi nama yang lebih sesuai bagi fungsi tsb, karena fungsi itu tidak mengabaikan detail mekanisme input keseluruhan. Dengan cara yang sama, sebuah model data esensial dari item data phone number (diimplikasikan oleh fungsi dial phone number) dpt di representasikan pada tahap ini tanpa menghiraukan struktur data yang utama (bila ada) yang digunakan untuk mengimplementasi item data.
Pandangan implementasi dari persyaratan menyajikan manifestasi dunia nyata dari pemrosesan fungsi – fungsi dan struktur informasi. Perangkat input Safe Home merupakan sebuah sensor perimeter. Sensor tsb mendeteksi masukan ilegal dengan “mengendus” adanya break dalam sebuah rangkaian listrik. Analisis harus mengenali batasan yang dikenakan oleh elemen system yang diberlakukan oleh elemen (sensor) system sebelumnya dan mempertimbangkan pandangan implementasi fungsi dan informasi bila pandangan semacam itu sesuai.
C. PROTOTYPING PERANGKAT LUNAK
Analisis harus dilakukan tanpa mengabaikan pardigma rekayasa perangkat lunak yang di aplikasikan; tetapi bentuk yang di ambil oleh analisis akan bermacam – macam. Dalam situasi yang lain, dilakukan pengumpulan persyaratan (melalui FAST, QFD, atau teknik “cuci otak” yang lain [JOR89], pengaplikasian prinsip analisis, dan penyusunan model perangkat lunak yang akan di bangun yang disebut prototype, untuk penilaian pelanggan dan pengembang.
1. Pemilihan Pendekatan Prototyping
Paradigma protyping dapat terbatas atau tidak terbatas. Pendekatan terbatas sering disebut throwaway prototyping. Dengan menggunakan pendekatan tsb, prototype melulu sebagai sebuah demonstrasi kasar dari persyaratan. Pendekatan tidak terbatas, yang disebut juga evolutionary prototyping, menggunakan prototype sebagai bagian pertama dari aktivitas analisis yang akan diteruskan kedalam desain dan kontruksi. Prototipe perangkat lunak merupakan evolusi pertama dari system yang diselesaikan. Secara umum, sembarang aplikasi yang menciptakan tampilan visual yang dinamis, berinteraksi erat dengan pemakai manusia, atau membutuhkan algoritma atau pemrosesan kombinatorial yang harus dikembangkan dalam sebuah gaya evolusioner, adalah calon untuk prototyping
2. Metode dan peranti prototyping
Supaya prototyping perangkat lunak efektif, maka harus dikembangkan suatu prototype dengan cepat sehingga pelanggan dapat menilai hasil dan perubahan yang di rekomendasi. Untuk melakukan prototyping secara cepat, ada tiga kelas metode dan peranti generic: teknik generasi keempat, komponen perangkat lunak reusable, spesifikasi formal, dan lingkungan prototyping.
Teknik Generasi Keempat (4GT). Teknik generasi keempat meliputi suatu array yang luas dari query database dan bahasa pelaporan, program dan generator aplikasi, serta bahasa nonprocedural. Karena 4GT memungkinkan perekayasa perangkat lunak memunculkan kode yang dapat dieksekusi dengan cepat, maka 4GT ideal untuk prototyping yang cepat. Komponen Perangkat Lunak Reusable. Pendektan lain ke rapid prototyping adalah dengan memasang, bukan membangun, prototype dengan menggunakan serangkaian komponen perangkat lunak yangada.Pada setiap kasus, komponen perangkat lunak harus dirancang dengan cara terntentu sehingga memungkinkannya untuk dipakai kembali tanpa harus mempunyai pengetahuan yang mendetail mengenai kerja internalnya. Perlu di catat bahwa sebuah produk perangkat lunak yabg ada dapat digunakan sebagai sebuah prototype bagi produk kompetitif yang “baru dan telah dikembangkan”. Dengan cara tertentu, hal tsb merupakan suatu bentuk dari reusabilitas untuk prototyping perangkat lunak.
Lingkungan Prototyping dan Spesifikasi Formal. Selama dua decade terakhir, sejumlah bahasa spesifikasi formal dan peranti telah dikembangkan sebagai pengganti bagi teknik spesifikasi bahasa natural. Sekarang pengembang bahasa formal itu berada dalam proses pengembangan lingkungan interaktif yang (1) memungkinkan seorang analisis untuk secara interaktif menciptakan spesifikasi system atau perangkat lunak yang berdasarkan pada bahasa, (2) memanggil peranti otomatis yang menerjemahkan spesifikasi berdasarkan bahasa kedalam kode yang dapat di eksekusi, dan (3) memungkinkan pelanggan untuk menggunakan kode prototype yang dapat di eksekusi untuk menyaring persyaratan – persyaratan formal.
Dalam pembuatan software, dikenal beberapa metode untuk membuat software yang dibutuhkan untuk memenuhi kebutuhan user yang memerlukan software tersebut. Pada kesempatan kali ini, saya akan membahas salah satu metode pembuatan software yang dimana baru-baru ini saya dan kelompok saya bahas dikampus untuk menyelesaikan tugas mata kuliah rekayasa perangkat lunak yaitu model prototype(Prototyping Model)
Sebelum memasuki lebih mendalam mengenai pembuatan software menggunakan metode prototype, kita harus terlebih dahulu mengetahui apa yang dimaksud dengan prototype itu sendiri. Prototype adalah model atau simulasi dari semua aspek produk sesungguhnya yang akan dikembangkan yang dimana model tersebut harus representative dari produk akhirnya. Setelah mengetahui arti prototype mungkin masih menganjal dibenak kita bagaimana sih software itu terbentuk menggunakan metode prototype? Apakah model prototype lebih bagus digunakan daripada model lain? Apakah resiko-resiko dari penggunaan model tersebut? Dan mungkin masih banyak pertanyaan lain yang akan muncul. Oleh sebab itu, pada postingan kali ini saya sendiri akan menjelaskan lebih lanjut mengenai pembuatan software dengan menggunakan metode prototype tersebut.
Model Prototype
Menurut saya sendiri prototyping model adalah suatu proses pembuatan software yang yang bersifat berulang dan dengan perencanaan yang cepat yang dimana terdapat umpan balik yang memungkinkan terjadinya perulangan dan perbaikan software sampai dengan software tersebut memenuhi kebutuhan dari si pengguna. Sedangkan dari beberapa referensi yang saya temukan, prototyping model adalah salah satu model sederhana pembuatan software yang dimana mengijinkan pengguna memiliki suatu gambaran awal/dasar tentang program serta melakukan oengujian awal yang didasarkan pada konsep model kerja(working model).
Tujuan Prototype
Prototyping model sendiri mempunyai tujuan yaitu mengembangkan model awal software menjadi sebuah sistem yang final.
Proses-prosesnya
Proses-proses dalam model prototyping yaitu:
Komunikasi terlebih dahulu yang dilakukan antara pelanggan dengan tim pemgembang perangkat lunak mengenai spesifikasi kebutuhan yang diinginkan
Akan dilakukan perencanaan dan pemodelan secara cepat berupa rancangan cepat(quick design) dan kemudian akan memulai konstruksi pembuatan prototype Prototipe kemudian akan diserahkan kepada para stakeholder untuk dilakukan evaluasi
lebih lanjut sebelum diserahkan kepada para pembuat software
Pembuatan software sesuai dengan prototype yang telah dievaluasi yang kemudian akan diserahkan kepada pelanggan
Jika belum memenuhi kebutuhan dari pelanggan maka akan kembali ke proses awal sampai dengan kebutuhan dari pelanggan telah terpenuhi
Sedangkan proses-proses dalam model prototyping secara umum adalah sebagai berikut: 1. Pengumpulan kebutuhan
developer dan klien akan bertemu terlebih dahulu dan kemudian menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya 2. Perancangan
perancangan dilakukan dengan cepat dan rancangan tersebut mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype
3. Evaluasi Prototype
klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.
Tahapan-tahapannya
Selain itu, untuk memodelkan sebuah perangkat lunak dibutuhkan beberapa tahapan di dalam proses pengembangannya. Tahapan inilah yang akan menentukan keberhasilan dari sebuah softwareitu .Pengembang perangkat lunak harus memperhatikan tahapan dalam metode prototyping agar software finalnya dapat diterima oleh penggunanya. Dan tahapan-tahapan dalam prototyping tersebut adalah sebagai berikut :
1. Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format dan kebutuhan kesseluruhan perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
2. Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berpusat pada penyajian kepada pelanggan (misalnya dengan membuat input dan contoh outputnya). 3. Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai maka langkah keempat akan diambil. Jika tidak, maka prototyping diperbaiki dengan mengulang langkah 1, 2 , dan 3.
4. Mengkodekan system
Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.
5. Menguji system
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 sudah, maka langkah ketujuh dilakukan, jika belum maka mengulangi langkah 4 dan 5.
7. Menggunakan system
Keunggulan dan kelemahan metode prototype Keunggulan prototyping :
1. Komunikasi akan terjalin baik antara pengembang dan pelanggan.
2. Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan setiap pelanggannya.
3. Pelanggan berperan aktif dalam proses pengembangan sistem. 4. Lebih menghemat waktu dalam pengembangan sistem.
5. Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya
Kelemahan prototyping :
1. Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangka waktu lama.
2. Pengembang biasanya ingin cepat menyelesaikan proyek sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan sebuah kerangka kerja(blueprint) dari sistem .
3. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik dan benar.
Dalam setiap metode mempunyai kelebihan maupun kekurangan, namun kekurangan tersebut dapat diminimalisir yaitu dengan mengetahui kunci dari model prototype tersebut. Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan aturan-aturan main pada saat awal, yaitu pelanggan dan pengembang harus setuju bahwa prototype dibangun untuk mendefinisikan kebutuhan.
