Throw Away [PDF]

Citation preview

Ver 1 Software prototyping adalah aktivitas menciptakan prototipe aplikasi perangkat lunak, yaitu, versi tidak lengkap dari program perangkat lunak yang sedang dikembangkan. Ini adalah aktivitas yang dapat terjadi dalam pengembangan perangkat lunak dan sebanding dengan prototipe seperti yang diketahui dari bidang lain, seperti teknik mesin atau manufaktur.



Sebuah prototipe biasanya hanya mensimulasikan beberapa aspek, dan mungkin benar-benar berbeda dari, produk akhir.



Prototyping memiliki beberapa manfaat: perancang dan pelaksana perangkat lunak dapat memperoleh umpan balik yang berharga dari pengguna di awal proyek. Klien dan kontraktor dapat membandingkan jika perangkat lunak yang dibuat sesuai dengan spesifikasi perangkat lunak, sesuai dengan program perangkat lunak yang dibangun. Hal ini juga memungkinkan insinyur perangkat lunak beberapa wawasan keakuratan perkiraan proyek awal dan apakah tenggat waktu dan tonggak yang diusulkan dapat berhasil dipenuhi. Tingkat kelengkapan dan teknik yang digunakan dalam prototipe telah dikembangkan dan diperdebatkan sejak proposal pada awal 1970-an. [6] Tujuan dari prototipe adalah untuk memungkinkan pengguna perangkat lunak untuk mengevaluasi proposal pengembang untuk desain produk akhirnya dengan benar-benar mencoba mereka, daripada harus menafsirkan dan mengevaluasi desain berdasarkan deskripsi. Software prototyping memberikan pemahaman tentang fungsi perangkat lunak dan potensi ancaman atau masalah. [1] Prototyping juga dapat digunakan oleh pengguna akhir untuk menggambarkan dan membuktikan persyaratan yang belum dipertimbangkan, dan itu bisa menjadi faktor kunci dalam hubungan komersial antara pengembang dan klien mereka. [2] Desain interaksi khususnya membuat penggunaan prototyping berat dengan tujuan itu.



Proses ini bertolak belakang dengan siklus pengembangan monolitik pada 1960-an dan 1970an untuk membangun seluruh program terlebih dahulu dan kemudian mengerjakan inkonsistensi antara desain dan implementasi, yang menyebabkan biaya perangkat lunak lebih tinggi dan perkiraan waktu dan biaya yang buruk. [Rujukan?] Monolitik pendekatan telah dijuluki teknik "Slaying the (software) Dragon", karena mengasumsikan bahwa perancang perangkat lunak dan pengembang adalah pahlawan tunggal yang harus membunuh seluruh naga sendirian. Prototyping juga dapat menghindari biaya besar dan kesulitan karena harus mengubah produk perangkat lunak yang sudah jadi.



Praktik pembuatan prototipe adalah salah satu poin yang dibuat Frederick P. Brooks dalam bukunya tahun 1975, The Mythical Man-Month, dan artikel peringatan 10 tahun "No Silver Bullet".



Contoh awal dari prototipe perangkat lunak berskala besar adalah implementasi penerjemah Ada / ED NYU untuk bahasa pemrograman Ada. [3] Ini diimplementasikan dalam SETL dengan maksud menghasilkan model semantik yang dapat dieksekusi untuk bahasa Ada, menekankan kejelasan desain dan antarmuka pengguna atas kecepatan dan efisiensi. Sistem NYU Ada / ED adalah implementasi Ada yang divalidasi pertama, disertifikasi pada 11 April 1983. [4]



Garis besar proses pembuatan prototipe Proses pembuatan prototipe melibatkan langkah-langkah berikut [rujukan?]



Identifikasi persyaratan dasar Tentukan persyaratan dasar termasuk informasi input dan output yang diinginkan. Detail, seperti keamanan, biasanya dapat diabaikan. Kembangkan prototipe awal Prototipe awal dikembangkan yang hanya mencakup antarmuka pengguna. (Lihat Prototipe Horisontal, di bawah) Ulasan Pelanggan, termasuk pengguna akhir, memeriksa prototipe dan memberikan umpan balik tentang penambahan atau perubahan potensial. Merevisi dan meningkatkan prototipe Menggunakan umpan balik baik spesifikasi dan prototipe dapat ditingkatkan. Negosiasi tentang apa yang ada dalam lingkup kontrak / produk mungkin diperlukan. Jika perubahan diperkenalkan maka pengulangan langkah # 3 dan # 4 mungkin diperlukan. Dimensi prototipe Nielsen merangkum berbagai dimensi prototipe dalam bukunya Usability Engineering:



Prototipe horizontal Istilah umum untuk prototipe antarmuka pengguna adalah prototipe horizontal. Ini memberikan pandangan yang luas dari keseluruhan sistem atau subsistem, berfokus pada interaksi pengguna lebih dari fungsi sistem tingkat rendah, seperti akses database. Prototipe horizontal berguna untuk:



Konfirmasi persyaratan antarmuka pengguna dan lingkup sistem, Versi demonstrasi sistem untuk mendapatkan dukungan dari bisnis, Kembangkan perkiraan awal waktu pengembangan, biaya dan usaha.



Prototipe vertikal Prototipe vertikal merupakan elaborasi lengkap yang disempurnakan dari satu subsistem atau fungsi. Ini berguna untuk memperoleh persyaratan rinci untuk fungsi yang diberikan, dengan manfaat sebagai berikut:



Desain basis data perbaikan, Dapatkan informasi tentang volume data dan kebutuhan antarmuka sistem, untuk ukuran jaringan dan rekayasa kinerja, Perjelas persyaratan kompleks dengan melakukan pengeboran ke fungsi sistem yang sebenarnya.



jenis prototipe Software prototyping memiliki banyak varian. Namun, semua metode dalam beberapa cara didasarkan pada dua bentuk utama prototyping: prototyping sekali pakai dan prototipe .evolutionary.



Prototipe pelempar Juga disebut prototipe close-ended. Pembuatan prototipe yang cepat atau cepat mengacu pada pembuatan model yang pada akhirnya akan dibuang daripada menjadi bagian dari perangkat lunak yang dikirimkan akhir. Setelah pengumpulan persyaratan awal tercapai, model kerja sederhana dari sistem ini dibangun untuk secara visual menunjukkan kepada pengguna apa yang tampak seperti persyaratan mereka ketika mereka diimplementasikan ke dalam sistem selesai. Ini juga merupakan prototyping cepat Pembuatan prototipe cepat melibatkan pembuatan model kerja dari berbagai bagian sistem pada tahap yang sangat awal, setelah penyelidikan yang relatif singkat. Metode yang digunakan dalam membangunnya biasanya cukup informal, faktor yang paling penting adalah kecepatan dengan model yang disediakan. Model kemudian menjadi titik awal dari mana pengguna dapat memeriksa kembali harapan mereka dan mengklarifikasi persyaratan mereka. Ketika tujuan ini telah tercapai, model prototipe 'dibuang', dan sistem ini secara resmi dikembangkan berdasarkan persyaratan yang teridentifikasi. [7] Alasan paling jelas untuk menggunakan prototyping sekali pakai adalah bahwa hal itu dapat dilakukan dengan cepat. Jika pengguna bisa mendapatkan umpan balik cepat tentang persyaratan mereka, mereka mungkin dapat menyempurnakannya di awal pengembangan perangkat lunak. Membuat perubahan di awal siklus hidup pengembangan sangat efektif karena tidak ada yang perlu dikerjakan ulang. Jika suatu proyek berubah setelah sejumlah besar pekerjaan telah dilakukan maka perubahan kecil dapat memerlukan upaya besar untuk diterapkan karena sistem perangkat lunak memiliki banyak dependensi. Kecepatan sangat penting dalam menerapkan prototipe sekali pakai, karena dengan anggaran waktu dan uang yang terbatas, sedikit yang dapat dikeluarkan pada prototipe yang akan dibuang.



Kekuatan lain dari prototipe lembaran adalah kemampuannya untuk membangun antarmuka yang dapat diuji oleh pengguna. Antarmuka pengguna adalah apa yang dilihat oleh pengguna sebagai sistem, dan dengan melihatnya di depan mereka, akan jauh lebih mudah untuk memahami bagaimana sistem akan berfungsi.



… Ditegaskan bahwa prototipe revolusioner yang cepat adalah cara yang lebih efektif untuk menangani masalah-masalah yang terkait dengan kebutuhan pengguna, dan oleh karena itu peningkatan yang lebih besar terhadap produktivitas perangkat lunak secara keseluruhan. Persyaratan dapat diidentifikasi, disimulasikan, dan diuji jauh lebih cepat dan murah ketika masalah evolvabilitas, pemeliharaan, dan struktur perangkat lunak diabaikan. Ini, pada gilirannya, mengarah pada spesifikasi persyaratan yang akurat, dan pembangunan selanjutnya dari sistem yang valid dan dapat digunakan dari perspektif pengguna, melalui model pengembangan perangkat lunak konvensional. [8] Prototype dapat diklasifikasikan sesuai dengan kesetiaan yang dengannya mereka menyerupai produk yang sebenarnya dalam hal penampilan, interaksi dan waktu. Salah satu metode untuk menciptakan prototipe lembaran ketepatan rendah adalah prototipe kertas. Prototipe ini diimplementasikan menggunakan kertas dan pensil, dan dengan demikian meniru fungsi dari produk yang sebenarnya, tetapi tidak terlihat sama sekali seperti itu. Metode lain untuk dengan mudah membangun prototipe cepat kesetiaan kesetiaan adalah dengan menggunakan GUI Builder dan membuat boneka klik, prototipe yang terlihat seperti sistem tujuan, tetapi tidak menyediakan fungsi apa pun.



Penggunaan storyboard, animatika atau gambar tidak persis sama dengan prototyping sekali pakai, tetapi jelas termasuk dalam keluarga yang sama. Ini adalah implementasi nonfungsional tetapi menunjukkan bagaimana sistem akan terlihat.



Ringkasan: Dalam pendekatan ini prototipe dibangun dengan gagasan bahwa itu akan dibuang dan sistem akhir akan dibangun dari awal. Langkah-langkah dalam pendekatan ini adalah:



Tuliskan persyaratan awal Rancang prototipe Pengalaman pengguna / menggunakan prototipe, menetapkan persyaratan baru Ulangi jika perlu Tulis persyaratan akhir



Evolusi prototipe



Evolusioner prototyping (juga dikenal sebagai prototyping papan roti) sangat berbeda dari prototyping. Tujuan utama ketika menggunakan prototipe evolusi adalah membangun prototipe yang sangat kuat dengan cara yang terstruktur dan terus menyempurnakannya. Alasan untuk pendekatan ini adalah bahwa prototipe evolusi, ketika dibangun, membentuk jantung dari sistem baru, dan perbaikan dan persyaratan selanjutnya akan dibangun.



Ketika mengembangkan sistem menggunakan prototipe evolusi, sistem ini terus disempurnakan dan dibangun kembali.



"... prototipe evolusi mengakui bahwa kita tidak memahami semua persyaratan dan hanya membangun yang dipahami dengan baik." [5] Teknik ini memungkinkan tim pengembangan untuk menambahkan fitur, atau membuat perubahan yang tidak dapat dikandung selama persyaratan dan fase desain.



Agar suatu sistem menjadi berguna, sistem harus berevolusi melalui penggunaan dalam lingkungan operasional yang diinginkan. Suatu produk tidak pernah "selesai;" itu selalu jatuh tempo karena lingkungan penggunaan berubah ... kita sering mencoba mendefinisikan suatu sistem menggunakan kerangka acuan yang paling kita kenal — di mana kita berada sekarang. Kami membuat asumsi tentang cara bisnis akan dilakukan dan basis teknologi di mana bisnis akan dilaksanakan. Sebuah rencana diberlakukan untuk mengembangkan kemampuan, dan, cepat atau lambat, sesuatu yang menyerupai sistem yang diharapkan diberikan. [9] Prototipe evolusioner memiliki keunggulan dibandingkan prototip sekali pakai karena mereka adalah sistem fungsional. Meskipun mereka mungkin tidak memiliki semua fitur yang telah direncanakan pengguna, mereka dapat digunakan secara sementara sampai sistem akhir dikirimkan.



"Ini tidak biasa dalam lingkungan prototyping bagi pengguna untuk menempatkan prototipe awal untuk penggunaan praktis sambil menunggu versi yang lebih maju ... Pengguna dapat memutuskan bahwa sistem 'cacat' lebih baik daripada tidak ada sistem sama sekali." [7] Dalam pembuatan prototipe evolusi, pengembang dapat memfokuskan diri untuk mengembangkan bagian-bagian dari sistem yang mereka pahami alih-alih bekerja mengembangkan keseluruhan sistem.



Untuk meminimalkan risiko, pengembang tidak mengimplementasikan fitur yang kurang dipahami. Sistem parsial dikirim ke situs pelanggan. Saat pengguna bekerja dengan sistem, mereka mendeteksi peluang untuk fitur baru dan memberikan permintaan untuk fitur ini kepada pengembang. Pengembang kemudian mengambil permintaan peningkatan ini bersama dengan mereka sendiri dan menggunakan praktik manajemen konfigurasi suara untuk



mengubah spesifikasi persyaratan perangkat lunak, memperbarui desain, pengodean ulang dan tes ulang. [10] Prototipe tambahan Produk akhir dibangun sebagai prototipe terpisah. Pada akhirnya, prototipe yang terpisah digabungkan dalam desain keseluruhan. Dengan bantuan prototipe inkremental kesenjangan waktu antara pengguna dan pengembang perangkat lunak berkurang.



Prototipe ekstrem Prototipe ekstrem sebagai proses pengembangan digunakan terutama untuk mengembangkan aplikasi web. Pada dasarnya, ini memecah pengembangan web menjadi tiga fase, masingmasing berdasarkan yang sebelumnya. Fase pertama adalah prototipe statis yang sebagian besar terdiri dari halaman HTML. Pada tahap kedua, layar diprogram dan berfungsi penuh menggunakan lapisan layanan yang disimulasikan. Pada fase ketiga, layanan diimplementasikan. Proses ini disebut prototipe ekstrem untuk menarik perhatian pada fase kedua dari proses, di mana UI yang berfungsi penuh dikembangkan dengan sangat sedikit memperhatikan layanan selain kontrak mereka.



Keuntungan dari prototyping Ada banyak keuntungan menggunakan prototipe dalam pengembangan perangkat lunak beberapa yang nyata, beberapa abstrak. [11]



Mengurangi waktu dan biaya: Prototyping dapat meningkatkan kualitas persyaratan dan spesifikasi yang diberikan kepada pengembang. Karena perubahan biaya secara eksponensial lebih banyak untuk diterapkan karena mereka kemudian terdeteksi dalam pengembangan, penentuan awal dari apa yang benar-benar diinginkan pengguna dapat menghasilkan perangkat lunak yang lebih cepat dan lebih murah. [8]



Peningkatan dan peningkatan keterlibatan pengguna: Prototyping membutuhkan keterlibatan pengguna dan memungkinkan mereka untuk melihat dan berinteraksi dengan prototipe yang memungkinkan mereka untuk memberikan umpan balik dan spesifikasi yang lebih baik dan lebih lengkap. [7] Kehadiran prototipe sedang diperiksa oleh pengguna mencegah banyak kesalahpahaman dan miskomunikasi yang terjadi ketika masing-masing pihak percaya yang lain mengerti apa yang mereka katakan. Karena pengguna tahu domain masalah lebih baik daripada siapa pun di tim pengembangan, interaksi yang meningkat dapat menghasilkan produk akhir yang memiliki kualitas nyata dan tidak nyata. Produk akhir lebih cenderung memenuhi keinginan pengguna untuk tampilan, nuansa, dan kinerja.



Kekurangan prototipe



Menggunakan, atau mungkin menyalahgunakan, membuat prototipe juga dapat memiliki kerugian.



Analisis tidak mencukupi: Fokus pada prototipe terbatas dapat mengalihkan perhatian pengembang dari menganalisis dengan tepat proyek yang lengkap. Hal ini dapat mengarah pada solusi yang lebih baik, persiapan spesifikasi yang tidak lengkap atau konversi prototipe yang terbatas menjadi proyek akhir yang dirancang dengan buruk yang sulit dipelihara. Lebih jauh lagi, karena prototipe terbatas dalam fungsionalitasnya mungkin tidak skala baik jika prototipe digunakan sebagai dasar dari penyampaian akhir, yang mungkin tidak diperhatikan jika pengembang terlalu fokus pada pembuatan prototipe sebagai model.



Kebingungan pengguna akan prototipe dan sistem akhir: Pengguna dapat mulai berpikir bahwa prototipe, yang dimaksudkan untuk dibuang, sebenarnya adalah sistem akhir yang hanya perlu diselesaikan atau dipoles. (Mereka, misalnya, sering tidak menyadari upaya yang diperlukan untuk menambahkan pengecekan kesalahan dan fitur keamanan yang mungkin tidak dimiliki oleh prototipe.) Hal ini dapat menyebabkan mereka mengharapkan prototipe untuk secara akurat memodelkan kinerja sistem akhir saat ini tidak maksud dari para pengembang. Pengguna juga bisa menjadi melekat pada fitur yang dimasukkan dalam prototipe untuk dipertimbangkan dan kemudian dihapus dari spesifikasi untuk sistem akhir. Jika pengguna dapat meminta semua fitur yang diusulkan dimasukkan dalam sistem akhir, ini dapat menyebabkan konflik.



Kesalahpahaman pengembang tentang sasaran pengguna: Pengembang dapat berasumsi bahwa pengguna berbagi tujuan mereka (misalnya untuk memberikan fungsi inti tepat waktu dan sesuai anggaran), tanpa memahami masalah komersial yang lebih luas. Misalnya, perwakilan pengguna yang menghadiri perangkat lunak Enterprise (misalnya PeopleSoft) acara mungkin telah melihat demonstrasi "audit transaksi" (di mana perubahan dicatat dan ditampilkan dalam tampilan perbedaan grid) tanpa diberitahu bahwa fitur ini menuntut pengkodean tambahan dan sering membutuhkan lebih banyak perangkat keras untuk menangani akses basis data tambahan. Pengguna mungkin percaya bahwa mereka dapat meminta audit di setiap bidang, sedangkan pengembang mungkin berpikir ini fitur creep karena mereka telah membuat asumsi tentang tingkat persyaratan pengguna. Jika pengembang telah melakukan pengiriman sebelum persyaratan pengguna ditinjau, pengembang berada di antara batu dan tempat yang sulit, terutama jika manajemen pengguna memperoleh beberapa keuntungan dari kegagalan mereka untuk menerapkan persyaratan.



Keterikatan pengembang dengan prototipe: Pengembang juga dapat menjadi melekat pada prototipe yang telah mereka habiskan dengan banyak usaha menghasilkan; ini dapat menyebabkan masalah, seperti mencoba mengubah prototipe terbatas menjadi sistem akhir ketika tidak memiliki arsitektur dasar yang sesuai. (Ini mungkin menunjukkan bahwa prototipe sekali-pakai, daripada prototipe evolusi, harus digunakan.)



Waktu pengembangan prototipe yang berlebihan: Kunci properti untuk membuat prototipe adalah kenyataan bahwa ini seharusnya dilakukan dengan cepat. Jika pengembang melupakan fakta ini, mereka sangat mungkin mencoba mengembangkan prototipe yang terlalu rumit. Ketika prototipe tersebut dibuang, persyaratan yang dikembangkan secara tepat yang diberikannya mungkin tidak menghasilkan peningkatan produktivitas yang cukup untuk menebus waktu yang dihabiskan untuk mengembangkan prototipe. Pengguna dapat terjebak dalam perdebatan tentang rincian prototipe, menahan tim pengembangan dan menunda produk akhir.



Biaya penerapan prototyping: biaya start up untuk membangun tim pengembangan yang berfokus pada prototyping mungkin tinggi. Banyak perusahaan memiliki metodologi pengembangan di tempat, dan mengubahnya dapat berarti pelatihan ulang, retooling, atau keduanya. Banyak perusahaan cenderung hanya memulai prototipe tanpa repot-repot untuk melatih kembali pekerja mereka sebanyak yang seharusnya.



Masalah umum dengan mengadopsi teknologi prototyping adalah harapan tinggi untuk produktivitas dengan upaya yang tidak memadai di belakang kurva belajar. Selain pelatihan untuk penggunaan teknik prototyping, ada kebutuhan yang sering diabaikan untuk mengembangkan struktur dasar perusahaan dan proyek yang spesifik untuk mendukung teknologi. Ketika struktur dasar ini dihilangkan, produktivitas yang lebih rendah sering dapat terjadi. [13]



Proyek terbaik untuk menggunakan prototyping Telah dikemukakan bahwa prototipe, dalam beberapa bentuk atau lainnya, harus digunakan sepanjang waktu. Namun, prototipe paling bermanfaat dalam sistem yang akan memiliki banyak interaksi dengan pengguna.



Telah ditemukan bahwa prototyping sangat efektif dalam analisis dan desain sistem on-line, terutama untuk pemrosesan transaksi, di mana penggunaan layar dialog jauh lebih dalam bukti. Semakin besar interaksi antara komputer dan pengguna, semakin besar manfaat yang dapat diperoleh dari membangun sistem cepat dan membiarkan pengguna bermain dengannya. [7] Sistem dengan sedikit interaksi pengguna, seperti pemrosesan batch atau sistem yang kebanyakan melakukan perhitungan, sedikit bermanfaat dari prototyping. Terkadang, pengkodean yang diperlukan untuk menjalankan fungsi sistem mungkin terlalu intensif dan potensi keuntungan yang dapat diberikan prototipe terlalu kecil. [7]



Prototyping sangat baik untuk mendesain antarmuka manusia-komputer yang baik. "Salah satu penggunaan paling produktif dari prototipe cepat hingga saat ini adalah sebagai alat untuk rekayasa kebutuhan pengguna berulang dan desain antarmuka manusia-komputer." [8]



Metode pengembangan sistem dinamis Metode Pengembangan Sistem Dinamis (DSDM) [18] adalah kerangka kerja untuk memberikan solusi bisnis yang sangat bergantung pada prototipe sebagai teknik inti, dan itu sendiri ISO 9001 disetujui. Ini memperluas definisi paling dipahami dari prototipe. Menurut DSDM, prototipe itu bisa berupa diagram, proses bisnis, atau bahkan sistem yang ditempatkan ke dalam produksi. Prototipe DSDM dimaksudkan untuk menjadi inkremental, berkembang dari bentuk-bentuk sederhana menjadi yang lebih komprehensif.



Prototipe DSDM terkadang dapat dibuang atau evolusioner. Evolusi prototipe dapat berevolusi secara horizontal (luasnya kemudian kedalaman) atau secara vertikal (setiap bagian dibangun secara rinci dengan iterasi tambahan yang merinci bagian-bagian berikutnya). Prototipe evolusioner akhirnya bisa berkembang menjadi sistem final.



Empat kategori prototipe seperti yang direkomendasikan oleh DSDM adalah:



Bisnis prototipe - digunakan untuk merancang dan menunjukkan proses bisnis yang sedang otomatis. Usability prototypes - digunakan untuk mendefinisikan, memperbaiki, dan menunjukkan kegunaan desain antarmuka pengguna, aksesibilitas, tampilan dan nuansa. Performa dan kapasitas prototipe - digunakan untuk mendefinisikan, mendemonstrasikan, dan memprediksi bagaimana sistem akan bekerja di bawah beban puncak serta untuk menunjukkan dan mengevaluasi aspek non-fungsional lainnya dari sistem (tarif transaksi, volume penyimpanan data, waktu respons, dll.) Kemampuan / teknik prototipe - digunakan untuk mengembangkan, menunjukkan, dan mengevaluasi pendekatan atau konsep desain. Daur hidup DSDM dari prototipe adalah untuk:



Identifikasi prototipe Setujui rencana Buat prototipe Tinjau prototipe



Prototipe operasional Operasional prototyping diusulkan oleh Alan Davis sebagai cara untuk mengintegrasikan prototyping throwaway dan evolusi dengan pengembangan sistem konvensional. "Ini



menawarkan yang terbaik dari kedua dunia pengembangan cepat dan kotor dan konvensional dengan cara yang masuk akal. Desainer hanya mengembangkan fitur yang dipahami dengan baik dalam membangun baseline evolusioner, sementara menggunakan prototipe tempat kosong untuk bereksperimen dengan fitur yang kurang dipahami." [ 5]



Keyakinan Davis adalah bahwa untuk mencoba "retrofit kualitas ke prototipe cepat" bukanlah metode yang benar ketika mencoba untuk menggabungkan dua pendekatan. Idenya adalah untuk terlibat dalam metodologi prototyping evolusi dan dengan cepat prototipe fitur sistem setelah setiap evolusi.



Metodologi spesifik mengikuti langkah-langkah ini: [5]



Prototipe evolusioner dibangun dan dibuat menjadi garis dasar menggunakan strategi pengembangan konvensional, menetapkan dan menerapkan hanya persyaratan yang dipahami dengan baik. Salinan baseline dikirim ke beberapa situs pelanggan bersama dengan prototyper yang terlatih. Di setiap situs, prototidper melihat pengguna di sistem. Setiap kali pengguna menemui masalah atau berpikir tentang fitur atau persyaratan baru, prototigper akan mencatatnya. Ini membebaskan pengguna dari keharusan untuk merekam masalah, dan memungkinkan dia untuk terus bekerja. Setelah sesi pengguna berakhir, pembuat prototip membangun prototipe sekali pakai di atas sistem baseline. Pengguna sekarang menggunakan sistem baru dan mengevaluasi. Jika perubahan baru tidak efektif, prototyper menghapusnya. Jika pengguna menyukai perubahan, prototyper menulis permintaan peningkatan fitur dan meneruskannya ke tim pengembangan. Tim pengembangan, dengan permintaan perubahan di tangan dari semua situs, kemudian menghasilkan prototipe evolusi baru menggunakan metode konvensional. Tentunya, kunci untuk metode ini adalah memiliki prototipe terlatih yang tersedia untuk menuju ke situs pengguna. Metodologi prototipe operasional memiliki banyak manfaat dalam sistem yang kompleks dan memiliki beberapa persyaratan yang diketahui sebelumnya.



Pengembangan sistem evolusioner Evolutionary Systems Development adalah kelas metodologi yang mencoba menerapkan prototipe evolusi secara formal. Satu jenis khusus, yang disebut Systemscraft dijelaskan oleh John Crinnion dalam bukunya Evolutionary Systems Development.



Systemscraft dirancang sebagai metodologi 'prototipe' yang harus dimodifikasi dan disesuaikan agar sesuai dengan lingkungan tertentu di mana ia diterapkan.



Systemscraft tidak dirancang sebagai 'buku masak' pendekatan kaku untuk proses pengembangan. Sekarang secara umum diakui bahwa metodologi yang baik harus cukup fleksibel untuk disesuaikan agar sesuai dengan semua jenis lingkungan dan situasi ... [7] Dasar Systemscraft, tidak seperti prototipe evolusi, adalah menciptakan sistem kerja dari persyaratan awal dan membangunnya dalam serangkaian revisi. Systemscraft menempatkan penekanan besar pada analisis tradisional yang digunakan di seluruh pengembangan sistem.



Evolusi perkembangan yang cepat Evolutionary Rapid Development (ERD) [12] dikembangkan oleh Perangkat Lunak Produktivitas Konsorsium, pengembangan teknologi dan agen integrasi untuk Kantor Teknologi Informasi dari Badan Penelitian Pertahanan Advanced (DARPA).



Dasar untuk ERD adalah konsep menyusun sistem perangkat lunak berdasarkan penggunaan kembali komponen, penggunaan templat perangkat lunak dan pada templat arsitektur. Evolusi kemampuan sistem secara terus-menerus dalam respons cepat terhadap perubahan kebutuhan pengguna dan teknologi disorot oleh arsitektur yang dapat berevolusi, mewakili kelas solusi. Proses ini berfokus pada penggunaan tim berbasis artisan kecil yang mengintegrasikan perangkat lunak dan disiplin rekayasa sistem yang bekerja banyak, sering kali paralel dengan timebox durasi pendek dengan interaksi pelanggan yang sering. Kunci keberhasilan proyek-proyek berbasis ERD adalah analisis eksplorasi paralel dan pengembangan fitur, infrastruktur, dan komponen dengan dan adopsi teknologi terdepan yang memungkinkan reaksi cepat terhadap perubahan dalam teknologi, pasar, atau persyaratan pelanggan. [9] Untuk mendapatkan input pelanggan / pengguna, sering dijadwalkan dan ad hoc / pertemuan dadakan dengan para pemangku kepentingan diadakan. Demonstrasi kemampuan sistem diadakan untuk mengumpulkan umpan balik sebelum keputusan desain / implementasi dipadatkan. Rilis frekuensi (misalnya, beta) tersedia untuk digunakan guna memberikan wawasan tentang bagaimana sistem dapat lebih mendukung kebutuhan pengguna dan pelanggan. Ini memastikan bahwa sistem berevolusi untuk memenuhi kebutuhan pengguna yang ada.



Kerangka desain untuk sistem didasarkan pada penggunaan standar yang sudah ada atau standar de facto. Sistem ini diatur untuk memungkinkan pengembangan serangkaian kemampuan yang mencakup pertimbangan untuk kinerja, kapasitas, dan fungsionalitas. Arsitektur didefinisikan dalam bentuk antarmuka abstrak yang merangkum layanan dan



implementasinya (misalnya, aplikasi COTS). Arsitektur berfungsi sebagai template yang digunakan untuk membimbing pengembangan lebih dari satu instan dari sistem. Ini memungkinkan beberapa komponen aplikasi digunakan untuk mengimplementasikan layanan. Satu set fungsi inti yang tidak mungkin diubah juga diidentifikasi dan ditetapkan.



Proses ERD disusun untuk menggunakan fungsi yang ditunjukkan daripada produk kertas sebagai cara bagi para pemangku kepentingan untuk mengkomunikasikan kebutuhan dan harapan mereka. Inti dari tujuan pengiriman cepat ini adalah penggunaan metode "timebox". Timebox adalah periode waktu yang tetap di mana tugas-tugas tertentu (misalnya, mengembangkan seperangkat fungsi) harus dilakukan. Daripada membiarkan waktu untuk memperluas untuk memenuhi beberapa tujuan yang samar-samar, waktu tetap (baik dalam hal minggu kalender dan jam orang) dan satu set tujuan didefinisikan yang secara realistis dapat dicapai dalam batasan-batasan ini. Untuk menjaga pengembangan dari merosot menjadi "perjalanan acak," rencana jangka panjang didefinisikan untuk memandu iterasi. Rencana ini memberikan visi untuk keseluruhan sistem dan menetapkan batas (misalnya, batasan) untuk proyek. Setiap iterasi dalam proses dilakukan dalam konteks rencana jangka panjang ini.



Setelah arsitektur ditetapkan, perangkat lunak terintegrasi dan diuji setiap hari. Ini memungkinkan tim untuk menilai kemajuan secara obyektif dan mengidentifikasi potensi masalah dengan cepat. Karena sejumlah kecil sistem diintegrasikan pada satu waktu, mendiagnosis dan menghapus cacat cepat. Demonstrasi pengguna dapat dilakukan dalam waktu singkat karena sistem umumnya siap untuk berolahraga setiap saat.



Alat-alat Secara efisien menggunakan prototyping mensyaratkan bahwa organisasi memiliki alat yang tepat dan staf yang terlatih untuk menggunakan alat-alat tersebut. Alat yang digunakan dalam pembuatan prototipe dapat bervariasi dari masing-masing alat, seperti bahasa pemrograman generasi ke-4 yang digunakan untuk pembuatan prototipe cepat ke alat CASE terpadu yang kompleks. Bahasa pemrograman visual generasi ke-4 seperti Visual Basic dan ColdFusion sering digunakan karena murah, terkenal dan relatif mudah dan cepat digunakan. Alat CASE, analisis persyaratan pendukung, seperti Persyaratan Lingkungan Rekayasa (lihat di bawah) sering dikembangkan atau dipilih oleh militer atau organisasi besar. Alat berorientasi objek juga sedang dikembangkan seperti LYMB dari Pusat Penelitian dan Pengembangan GE. Pengguna dapat membuat prototipe elemen dari aplikasi itu sendiri dalam spreadsheet.



Karena aplikasi berbasis web terus berkembang dalam popularitas, demikian juga, memiliki alat untuk membuat prototipe aplikasi tersebut. Kerangka kerja seperti Bootstrap, Foundation, dan AngularJS menyediakan alat yang diperlukan untuk dengan cepat menyusun bukti konsep. Kerangka kerja ini biasanya terdiri dari serangkaian kontrol, interaksi, dan pedoman desain yang memungkinkan pengembang untuk dengan cepat membuat prototipe aplikasi web.



Generator layar, alat desain, dan pabrik perangkat lunak Program penghasil layar juga umum digunakan dan mereka memungkinkan prototipe untuk menunjukkan sistem pengguna yang tidak berfungsi, tetapi menunjukkan seperti apa tampilan layar. [5] Mengembangkan Antarmuka Komputer Manusia kadang-kadang dapat menjadi bagian penting dari upaya pengembangan, karena bagi pengguna antarmuka pada dasarnya adalah sistem.



Pabrik perangkat lunak dapat menghasilkan kode dengan menggabungkan komponen modular siap pakai. Ini membuat mereka ideal untuk aplikasi prototyping, karena pendekatan ini dapat dengan cepat memberikan program dengan perilaku yang diinginkan, dengan jumlah minimal pengkodean manual.



Definisi aplikasi atau perangkat lunak simulasi Kelas baru perangkat lunak yang disebut definisi Aplikasi atau perangkat lunak simulasi memungkinkan pengguna untuk dengan cepat membuat simulasi animasi ringan dari program komputer lain, tanpa menulis kode. Perangkat lunak simulasi aplikasi memungkinkan pengguna teknis dan non-teknis untuk mengalami, menguji, berkolaborasi dan memvalidasi program simulasi, dan menyediakan laporan seperti anotasi, tangkapan layar, dan skema. Sebagai teknik spesifikasi solusi, Aplikasi Simulasi jatuh antara risiko rendah, tetapi terbatas, teks atau gambar berbasis-mock-up (atau wireframes) kadang-kadang disebut prototipe berbasis kertas, dan memakan waktu, prototipe kode berbasis risiko tinggi, memungkinkan perangkat lunak profesional untuk memvalidasi persyaratan dan pilihan desain sejak awal, sebelum pengembangan dimulai. Dengan demikian, risiko dan biaya yang terkait dengan implementasi perangkat lunak dapat dikurangi secara dramatis. [6]



Untuk mensimulasikan aplikasi, seseorang juga dapat menggunakan perangkat lunak yang mensimulasikan program perangkat lunak dunia nyata untuk pelatihan berbasis komputer, demonstrasi, dan dukungan pelanggan, seperti perangkat lunak screencasting karena area tersebut terkait erat. Ada juga alat yang lebih khusus. [7] [8] [9]



Persyaratan Lingkungan Rekayasa "The Requirements Engineering Environment (REE), yang sedang dikembangkan di Rome Laboratory sejak 1985, menyediakan toolset terintegrasi untuk secara cepat mewakili, membangun, dan mengeksekusi model-model aspek penting dari sistem yang kompleks." [15]



Persyaratan Rekayasa Lingkungan saat ini digunakan oleh Angkatan Udara Amerika Serikat untuk mengembangkan sistem. Ini:



seperangkat alat yang terintegrasi yang memungkinkan analis sistem untuk dengan cepat membangun fungsional, antarmuka pengguna, dan model prototipe kinerja dari komponen sistem. Kegiatan pemodelan ini dilakukan untuk mendapatkan pemahaman yang lebih besar dari sistem yang kompleks dan mengurangi dampak yang spesifikasi spesifikasi yang tidak akurat terhadap biaya dan penjadwalan selama proses pengembangan sistem. Model dapat dibuat dengan mudah, dan pada berbagai tingkat abstraksi atau granularity, tergantung pada aspek perilaku spesifik dari model yang sedang dilaksanakan. [15] REE terdiri dari tiga bagian. Yang pertama, yang disebut proto adalah alat CASE yang dirancang khusus untuk mendukung pembuatan prototipe yang cepat. Bagian kedua disebut Rapid Interface Prototyping System atau RIP, yang merupakan kumpulan alat yang memfasilitasi pembuatan antarmuka pengguna. Bagian ketiga REE adalah antarmuka pengguna untuk RIP dan proto yang bersifat grafis dan dimaksudkan agar mudah digunakan.



Rome Laboratory, pengembang REE, bermaksud untuk mendukung metodologi pengumpulan persyaratan internal mereka. Metode mereka memiliki tiga bagian utama:



Elicitation dari berbagai sumber (pengguna, antarmuka ke sistem lain), spesifikasi, dan pemeriksaan konsistensi Analisis bahwa kebutuhan pengguna beragam diambil bersama-sama tidak bertentangan dan secara teknis dan ekonomis layak Validasi bahwa persyaratan yang dihasilkan adalah cerminan akurat dari kebutuhan pengguna. [15] Pada tahun 1996, Rome Labs mengontrak Software Productivity Solutions (SPS) untuk lebih meningkatkan REE untuk menciptakan "REE kualitas komersial yang mendukung spesifikasi persyaratan, simulasi, prototipe antarmuka pengguna, pemetaan persyaratan untuk arsitektur perangkat keras, dan pembuatan kode ..." [16] Ini sistem diberi nama Advanced Requirements Engineering Workstation atau AREW. LYMB LYMB [17] adalah lingkungan pengembangan berorientasi objek yang ditujukan untuk mengembangkan aplikasi yang memerlukan penggabungan antarmuka pengguna berbasis grafis, visualisasi, dan pembuatan prototipe cepat.



Lingkungan non-relasional Definisi data non-relasional (misalnya menggunakan model Caché atau asosiatif) dapat membantu membuat prototipe pengguna akhir lebih produktif dengan menunda atau menghindari kebutuhan untuk menormalkan data pada setiap iterasi simulasi. Ini dapat menghasilkan kejelasan awal / lebih besar dari persyaratan bisnis, meskipun tidak secara



khusus menegaskan bahwa persyaratan secara teknis dan ekonomis layak dalam sistem target produksi.



PSDL PSDL adalah bahasa deskripsi prototipe untuk menggambarkan perangkat lunak real-time. [10] Set alat terkait adalah CAPS (Computer Aided Prototyping System). [11] Prototyping sistem perangkat lunak dengan persyaratan real-time yang sulit sangat menantang karena kendala waktu memperkenalkan implementasi dan ketergantungan perangkat keras. PSDL mengatasi masalah ini dengan memperkenalkan abstraksi kontrol yang mencakup batasan waktu deklaratif. CAPS menggunakan informasi ini untuk secara otomatis menghasilkan kode dan jadwal waktu nyata yang terkait, memantau batasan waktu selama eksekusi prototipe, dan mensimulasikan eksekusi dalam waktu nyata proporsional relatif terhadap serangkaian model perangkat keras yang diparameterisasi. Ini juga menyediakan asumsi standar yang memungkinkan pelaksanaan deskripsi prototipe yang tidak lengkap, mengintegrasikan konstruksi prototipe dengan repuse ulang penggunaan perangkat lunak untuk implementasi efisien yang cepat menyadari, dan menyediakan dukungan untuk evolusi cepat persyaratan dan desain. [12]



Ver 2 Prototipe lempar-jauhnya ( Throwaway Prototyping ) Pembuatan prototipe pelempar adalah tentang membuat, secepat mungkin, bagian dari aplikasi masa depan untuk memastikan bahwa fitur tersebut secara teknis layak atau untuk menunjukkan fitur kepada pemangku kepentingan atau pengguna potensial untuk mengumpulkan umpan balik dari mereka.



Karena kode sumber dari prototipe ini tidak digunakan kembali kemudian ketika mengembangkan aplikasi itu sendiri, itu membuatnya menjadi prototipe lempar-jauhnya. Mengetahui bahwa itu adalah kode membuang-buang membantu memfokuskan pada fitur yang sebenarnya, sementara mengesampingkan aspek-aspek seperti pemeliharaan kode, gaya, pola desain atau pengujian. Ini memungkinkan untuk menyelesaikan prototipe dengan sangat cepat, tanpa mempengaruhi secara negatif hutang teknis dari produk akhir.



Prototipe lempar-pergi berbeda dari membuat sketsa. Sketsa lebih bersifat grafis dan berorientasi pada antarmuka pengguna dan pengalaman pengguna, dan tidak terdiri dari penulisan kode pemrograman. Prototipe throw-away biasanya digunakan ketika membuat sketsa tidak cukup (misalnya ketika Anda perlu menunjukkan bagaimana suatu fitur akan tampil pada smartphone yang berbeda atau ketika Anda perlu menunjukkan kinerja aktual dan responsif).



Prototipe throw-away dapat menghadirkan risiko ketika berhadapan dengan pemangku kepentingan tanpa latar belakang teknis dan dalam konteks tenggat waktu yang ketat dan sumber daya yang sangat terbatas: pemangku kepentingan dapat mencoba meyakinkan Anda untuk menggunakan kembali produk akhir kode sumber dari prototipe. Itu wajar untuk percaya bahwa itu akan mempersingkat waktu yang diperlukan untuk merilis produk, tetapi sebenarnya, itu hanya akan menunda tanggal pengiriman. Salah satu cara untuk mencegah hal ini adalah dengan menggunakan prototipe bahasa yang tidak dapat digunakan dalam produksi (misalnya gunakan C # ketika Anda tahu bahwa produk akhir akan di-host di server Linux dengan hanya Python yang diinstal).



Evolusi prototipe Evolusioner prototipe terdiri dari membangun prototipe yang kemudian disempurnakan berdasarkan umpan balik reguler dari para pemangku kepentingan atau pengguna potensial.



Di sini, pemeliharaan kode, gaya, pola desain atau pengujian dihitung dari awal, yang memungkinkan untuk mengembangkan prototipe menjadi produk unggulan yang berkualitas tinggi. Langkah-langkah awal dari prototipe hanya berisi bagian inti dari produk masa depan, dan kemudian, fitur ditambahkan secara progresif.



Evolusi prototipe berbeda dari prototipe inkremental. Prototipe tambahan terdiri dari membangun beberapa prototipe, masing-masing mewakili bagian dari sistem masa depan, dan kemudian menggabungkannya. Evolusioner prototipe lebih dekat ke Agile: sering, Anda akan dapat memperoleh awal produk yang bekerja dengan fitur terbatas dan memperpanjangnya sampai stakeholder punya uang. Tambahan prototyping, di sisi lain, lebih cocok untuk proyek-proyek besar dengan banyak tim yang berkontribusi, masing-masing tim bekerja pada prototipe yang terpisah.



Evolusi prototipe berbeda dari metodologi Agile juga. Tangkas adalah tentang iterasi dan tonggak yang sering terjadi di mana produk yang berfungsi penuh dapat dilepaskan ke manufaktur. Jika Anda memiliki produk kerja setiap hari Kamis, Anda melakukan Agile. Dalam pembuatan prototipe evolusi, Anda memperluas prototipe, tetapi tidak ada yang memaksa Anda memiliki produk yang berfungsi penuh secara teratur. Anda dapat menghabiskan waktu dua bulan untuk membuat prototipe pertama, daripada mengembangkannya dengan beberapa fitur masing-masing dua dan tiga hari, dan kemudian menghabiskan tiga bulan di fitur lain. Anda tidak dapat memiliki pola tidak teratur semacam ini di Agile.



Metodologi khusus Agile menerapkan aturan tambahan. Misalnya, jika Anda tidak melakukan pair programming, Anda tidak dapat menyatakan bahwa Anda sedang melakukan Extreme Programming. Jika tim Anda tidak mengadakan rapat harian, Anda tidak melakukan Scrum.