Computer Programming

It is FUN Programming ^_^

Software Prototyping

Software prototipe, suatu kegiatan selama pengembangan perangkat lunak tertentu, adalah penciptaan prototipe, yaitu versi lengkap dari program perangkat lunak yang dikembangkan.

Sebuah prototipe biasanya hanya mensimulasikan beberapa aspek dari fitur dari program akhirnya, dan mungkin sama sekali berbeda dari pelaksanaan akhirnya.

Tujuan konvensional prototipe adalah memungkinkan pengguna perangkat lunak untuk mengevaluasi pengembang ‘proposal untuk desain produk yang akhirnya dengan benar-benar mencoba mereka keluar, daripada harus menafsirkan dan mengevaluasi desain berdasarkan deskripsi. Prototyping juga dapat digunakan oleh pengguna akhir untuk menjelaskan dan membuktikan bahwa pengembang persyaratan tidak dianggap, jadi “mengendalikan prototipe” dapat menjadi faktor kunci dalam hubungan komersial antara penyedia solusi dan klien mereka.

Prototyping memiliki beberapa keuntungan: Software desainer dan pelaksana dapat memperoleh umpan balik dari para pengguna di awal proyek. Klien dan kontraktor dapat membandingkan apakah perangkat lunak yang dibuat sesuai dengan spesifikasi perangkat lunak, sesuai dengan program perangkat lunak yang dibangun. Hal ini juga memungkinkan software engineer beberapa wawasan ke dalam akurasi perkiraan awal proyek dan apakah tenggat waktu dan tonggak diusulkan dapat berhasil bertemu. Tingkat kelengkapan dan teknik yang digunakan dalam prototipe telah dalam pembangunan dan perdebatan sejak usulan pada awal 1970-an. [6]

Proses ini kontras dengan tahun 1960-an dan 1970-an siklus pengembangan monolitik dari seluruh program pembangunan terlebih dahulu dan kemudian bekerja apa pun inkonsistensi antara desain dan implementasi, yang menyebabkan biaya perangkat lunak yang lebih tinggi dan miskin perkiraan waktu dan biaya. Pendekatan yang monolitik telah dijuluki sebagai “pembunuhan yang (perangkat lunak) Dragon” teknik, karena mengasumsikan bahwa perancang dan pengembang perangkat lunak adalah satu pahlawan yang telah membunuh seluruh naga sendirian. Prototyping juga dapat menghindari biaya besar dan kesulitan untuk mengubah perangkat lunak yang sudah jadi produk.

Praktek prototipe adalah salah satu poin Fred Brooks di tahun 1975 membuat buku The Mythical Man-Bulan dan tahun ulang tahun 10-buku Tidak Silver Bullet.

Tinjauan

Proses prototyping meliputi langkah-langkah berikut

1. Mengidentifikasi persyaratan dasar

Tentukan persyaratan dasar termasuk masukan dan keluaran informasi yang diinginkan. Rincian, seperti keamanan, biasanya dapat diabaikan.

2. Mengembangkan Initial Prototype

Prototipe awal dikembangkan yang hanya mencakup user interface.

3. Tinjauan

Pelanggan, termasuk pengguna akhir, menguji prototipe dan memberikan umpan balik mengenai penambahan atau perubahan.

4. Merevisi dan Meningkatkan Prototype

Menggunakan umpan baik spesifikasi dan prototipe dapat ditingkatkan. Negosiasi tentang apa yang dalam lingkup kontrak / produk mungkin diperlukan. Jika perubahan yang diperkenalkan kemudian ulangi langkah # 3 ands # 4 mungkin diperlukan.

Jenis-jenis prototyping

Software prototipe memiliki banyak varian. Namun, semua metode-metode tersebut dalam beberapa cara yang didasarkan pada dua jenis utama prototyping: throwaway Prototyping dan Evolutionary Prototyping.

Throwaway prototyping

Dekat berakhir juga disebut prototyping. Rapid Prototyping throwaway atau mengacu pada penciptaan model yang pada akhirnya akan dibuang daripada menjadi bagian dari perangkat lunak disampaikan akhir. Setelah persyaratan awal pengumpulan selesai, model kerja yang sederhana dari sistem yang dibangun untuk visual menunjukkan pengguna apa persyaratan mereka mungkin terlihat seperti ketika mereka selesai diimplementasikan ke dalam sistem.

Rapid Prototyping terlibat menciptakan model kerja dari berbagai bagian dari sistem pada tahap yang sangat awal, setelah penyelidikan yang relatif singkat. Metode yang digunakan dalam membangun itu biasanya cukup informal, faktor yang paling penting karena kecepatan dengan model yang disediakan. Model kemudian menjadi titik awal dari mana pengguna dapat memeriksa kembali harapan mereka dan menjelaskan persyaratan mereka. Saat ini telah tercapai, model prototipe ‘dibuang’, dan sistem secara formal dikembangkan berdasarkan persyaratan yang telah diidentifikasi. [7]

Alasan yang paling jelas untuk menggunakan throwaway Prototyping adalah bahwa hal itu bisa dilakukan dengan cepat. Jika pengguna dapat dengan cepat umpan balik pada persyaratan mereka, mereka mungkin dapat menyempurnakan mereka pada awal pengembangan perangkat lunak. Membuat perubahan-perubahan di awal siklus hidup pengembangan biaya sangat efektif karena tidak ada pada saat itu mengulagi. Jika proyek ini berubah setelah kerja cukup telah dilakukan maka perubahan kecil dapat memerlukan upaya besar untuk mengimplementasikan sistem perangkat lunak karena memiliki banyak dependensi. Kecepatan sangat penting dalam mengimplementasikan prototipe yang sekali pakai, karena dengan anggaran terbatas waktu dan uang sedikit yang dapat dihabiskan pada prototipe yang akan dibuang.

Kekuatan lain throwaway Prototyping adalah kemampuannya untuk membangun antarmuka bahwa pengguna dapat menguji. User interface adalah apa yang user lihat sebagai sistem, dan dengan melihat hal itu di depan mereka, jauh lebih mudah untuk memahami bagaimana sistem akan bekerja.

… Itu menegaskan bahwa prototipe cepat revolusioner adalah cara yang lebih efektif yang berhubungan dengan kebutuhan pengguna-isu terkait, dan karena itu perangkat tambahan yang lebih besar untuk perangkat lunak produktivitas secara keseluruhan. Persyaratan dapat diidentifikasi, simulasi, dan diuji jauh lebih cepat dan murah ketika isu-isu evolvability, Kemampu-rawatan, dan struktur perangkat lunak diabaikan. Hal ini, pada gilirannya, mengarah ke spesifikasi akurat persyaratan, dan pembangunan berikutnya dan bermanfaat yang valid sistem dari perspektif pengguna melalui model pengembangan perangkat lunak konvensional. [8]

Prototipe dapat diklasifikasikan menurut kesetiaan yang mereka menyerupai produk sebenarnya dari segi penampilan, interaksi dan waktu. Salah satu metode untuk menciptakan kesetiaan yang rendah throwaway Prototipe adalah Kertas Prototyping. Prototipe dilaksanakan dengan menggunakan kertas dan pensil, dan dengan demikian meniru fungsi produk yang sebenarnya, tetapi tidak terlihat sama sekali seperti itu. Metode lain untuk dengan mudah membangun kesetiaan tinggi throwaway Prototip adalah dengan menggunakan GUI Builder dan menciptakan klik bodoh, prototipe yang kelihatan seperti sistem tujuan, tetapi tidak memberikan fungsi apapun.

Tidak persis sama dengan throwaway Prototyping, tapi jelas dalam keluarga yang sama, adalah penggunaan storyboard, animatics atau gambar. Ini adalah implementasi non-fungsional tapi menunjukkan bagaimana sistem akan terlihat.

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

1. Menulis persyaratan pendahuluan
2. Desain prototipe
3. Pengguna pengalaman / menggunakan prototipe, menentukan syarat-syarat baru.
4. Menulis persyaratan akhir
5. Mengembangkan produk nyata.

Evolutionary prototyping

Evolutionary Prototyping (juga dikenal sebagai prototipe papan tempat memotong roti) adalah sangat berbeda dari throwaway Prototyping. Tujuan utama ketika menggunakan Evolutionary Prototyping adalah untuk membangun prototipe yang sangat kuat dengan cara yang terstruktur dan terus-menerus memperbaikinya. “Alasan untuk ini adalah bahwa evolusi prototipe, ketika dibangun, bentuk jantung dari sistem baru, dan perbaikan dan persyaratan lebih lanjut akan dibangun.

Ketika mengembangkan sistem dengan menggunakan Evolutionary Prototyping, sistem ini terus-menerus disempurnakan dan dibangun kembali.

“… Evolusi prototipe mengakui bahwa kita tidak memahami semua persyaratan dan membangun hanya mereka yang dipahami dengan baik.” [5]

Teknik ini memungkinkan tim pengembangan untuk menambahkan fitur, atau membuat perubahan yang tidak dapat dipahami selama persyaratan dan tahap perancangan.

Untuk sistem yang akan berguna, itu harus berkembang melalui penggunaan dimaksudkan dalam lingkungan operasional. Sebuah produk tidak pernah “dilakukan;” itu selalu jatuh tempo sebagai perubahan lingkungan penggunaan … kita sering mencoba untuk mendefinisikan sebuah sistem dengan menggunakan kita yang paling akrab — kerangka acuan di mana kita sekarang. Kita membuat asumsi tentang cara bisnis akan dilakukan dan berbasis teknologi bisnis yang akan dilaksanakan. Sebuah rencana dijalankan untuk mengembangkan kemampuan, dan, cepat atau lambat, sesuatu yang mirip dengan sistem membayangkan dikirimkan. [9]

Prototip evolusi memiliki keuntungan lebih throwaway Prototip dalam bahwa mereka adalah sistem fungsional. Walaupun mereka mungkin tidak memiliki semua fitur yang pengguna telah direncanakan, mereka dapat digunakan pada basis sementara sampai sistem terakhir dikirim.

“Sudah lazim dalam lingkungan prototipe bagi pengguna untuk menempatkan prototipe awal untuk penggunaan praktis sambil menunggu versi yang lebih maju … pengguna dapat memutuskan bahwa sebuah ‘cacat’ sistem yang lebih baik daripada tidak ada sistem sama sekali.” [7]

Dalam Evolutionary Prototyping, pengembang dapat memfokuskan diri untuk mengembangkan bagian-bagian dari sistem yang mereka mengerti daripada bekerja pada pengembangan sistem secara keseluruhan.

Untuk meminimalkan risiko, pengembang tidak mengimplementasikan fitur kurang dipahami. Sistem parsial dikirim ke situs pelanggan. Sebagai pengguna bekerja dengan sistem, mereka mendeteksi kesempatan untuk fitur-fitur baru dan memberikan permintaan fitur ini untuk pengembang. Pengembang kemudian mengambil permintaan tambahan ini bersama-sama dengan mereka sendiri dan menggunakan konfigurasi suara-praktik manajemen untuk mengubah perangkat lunak-persyaratan spesifikasi, update desain, recode dan tes ulang. [10]

Incremental prototyping

Produk akhir ini dibangun sebagai prototipe terpisah. Pada akhir prototipe terpisah digabung dalam desain keseluruhan.

Extreme prototyping

Extreme Prototyping sebagai proses pembangunan terutama digunakan untuk mengembangkan aplikasi web. Pada dasarnya, itu rusak pengembangan web menjadi tiga tahap, masing-masing didasarkan pada yang terdahulu. Tahap pertama adalah prototipe yang statis terdiri dari halaman HTML. Dalam fase kedua, layar terprogram dan berfungsi penuh menggunakan layanan simulasi lapisan. Pada tahap ketiga layanan dilaksanakan. Proses ini disebut Extreme Prototyping untuk menarik perhatian pada tahap kedua dari proses, di mana fungsi-lengkap UI ini dikembangkan dengan sedikit sehubungan dengan layanan selain kontrak mereka.

Keuntungan dari prototipe

Ada banyak keuntungan menggunakan prototyping dalam pengembangan perangkat lunak – beberapa nyata, beberapa abstrak. [11]

Mengurangi waktu dan biaya: Prototyping dapat meningkatkan kualitas persyaratan dan spesifikasi yang diberikan kepada pengembang. Karena biaya perubahan secara eksponensial lebih untuk melaksanakan seperti yang terdeteksi kemudian dalam pembangunan, penentuan awal apa yang benar-benar ingin pengguna dapat menghasilkan lebih cepat dan lebih murah perangkat lunak. [8]

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

Kerugian prototipe

Menggunakan, atau mungkin menyalahgunakan, prototipe dapat juga memiliki kelemahan. [11]

Analisis tidak mencukupi: Fokus pada prototipe yang terbatas dapat mengalihkan perhatian pengembang dari benar menganalisis proyek lengkap. Hal ini dapat mengakibatkan menghadap solusi yang lebih baik, persiapan spesifikasi tidak lengkap atau konversi terbatas rekayasa prototipe menjadi buruk proyek akhir yang sulit untuk mempertahankan. Lebih lanjut, karena prototipe fungsionalitas terbatas dalam skala yang mungkin tidak baik jika prototipe digunakan sebagai dasar penyampaian akhir, yang mungkin tidak akan melihat jika pengembang terlalu berfokus pada pembangunan suatu prototipe sebagai model.

Pengguna kebingungan dan menyelesaikan prototipe sistem: Pengguna dapat mulai berpikir bahwa sebuah prototipe, dimaksudkan untuk dibuang, sebenarnya merupakan sistem final yang hanya perlu selesai atau dipoles. (Mereka, misalnya, sering tidak menyadari upaya yang diperlukan untuk menambahkan pengecekan error dan fitur keamanan yang prototipe mungkin belum.) Hal ini dapat memimpin mereka untuk mengharapkan prototipe model secara akurat kinerja sistem akhir ini tidak maksud dari pengembang. Pengguna dapat juga menjadi melekat pada fitur yang dimasukkan dalam prototipe untuk dipertimbangkan dan kemudian dihapus dari spesifikasi untuk sistem akhir. Jika pengguna dapat mewajibkan semua fitur yang diusulkan akan dimasukkan ke dalam sistem terakhir ini dapat menimbulkan konflik.

Pengembang kesalahpahaman tujuan pengguna: Pengembang boleh berasumsi bahwa pengguna berbagi tujuan mereka (misalnya untuk memberikan fungsionalitas inti tepat waktu dan sesuai anggaran), tanpa memahami masalah-masalah komersial yang lebih luas. Sebagai contoh, wakil-wakil pengguna perangkat lunak Enterprise menghadiri (misalnya PeopleSoft) kejadian mungkin telah melihat demonstrasi dari “transaksi audit” (di mana perubahan akan dicatat dan ditampilkan dalam grid perbedaan pandangan) tanpa harus diberitahu bahwa fitur ini menuntut coding tambahan dan seringkali memerlukan lebih banyak hardware untuk menangani mengakses database tambahan. Pengguna mungkin percaya bahwa mereka dapat menuntut audit pada setiap bidang, sedangkan pengembang mungkin berpikir ini adalah fitur merayap karena mereka telah membuat asumsi tentang sejauh mana kebutuhan pengguna. Jika penyedia solusi pengiriman sebelumnya telah melakukan persyaratan-persyaratan pengguna ditinjau ulang, pengembang adalah antara batu dan tempat yang keras, terutama jika manajemen pengguna berasal beberapa keuntungan dari kegagalan mereka untuk menerapkan persyaratan.

Pengembang lampiran untuk prototipe: Pengembang dapat juga menjadi melekat pada prototipe mereka telah menghabiskan banyak usaha yang memproduksi; hal ini dapat menimbulkan masalah seperti mencoba untuk mengubah prototipe yang terbatas ke dalam sistem final jika tidak memiliki arsitektur dasar yang tepat. (Hal ini mungkin menunjukkan bahwa throwaway prototipe, daripada evolusi prototipe, harus digunakan.)

Berlebihan waktu pengembangan dari prototipe: properti kunci untuk prototipe adalah kenyataan bahwa hal itu seharusnya dilakukan dengan cepat. Jika pengembang kehilangan jejak mengenai kenyataan ini, mereka sangat baik mungkin mencoba untuk mengembangkan prototipe yang terlalu rumit. Ketika dibuang prototipe yang tepat persyaratan yang dikembangkan memberikan mungkin tidak menghasilkan peningkatan produktivitas yang cukup untuk menebus waktu yang dihabiskan untuk mengembangkan prototipe. Pengguna dapat terjebak dalam perdebatan rincian prototipe, sambil mengangkat tim pengembangan dan menunda produk akhir.

Biaya pelaksanaan prototyping: biaya awal untuk membangun sebuah tim pengembangan berfokus pada prototipe mungkin tinggi. Banyak perusahaan memiliki metodologi pengembangan di tempat, dan mengubah mereka dapat berarti pelatihan ulang, memperbarui peralatan, atau keduanya. Banyak perusahaan cenderung hanya melompat ke dalam prototipe tanpa repot-repot melatih pekerja mereka sebanyak yang seharusnya.

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

Proyek terbaik untuk menggunakan prototyping

Telah dikemukakan bahwa prototipe, dalam beberapa bentuk atau lainnya, harus digunakan sepanjang waktu. Namun, prototipe yang paling menguntungkan dalam sistem yang akan memiliki banyak interaksi dengan pengguna.

Telah ditemukan bahwa prototipe ini sangat efektif dalam analisis dan desain sistem on-line, terutama untuk proses transaksi, di mana penggunaan layar dialog jauh lebih dalam bukti. Semakin besar interaksi antara komputer dan pengguna, semakin besar manfaat yang yang dapat diperoleh dari membangun sistem yang cepat dan membiarkan user bermain dengan itu. [7]

Sistem dengan sedikit interaksi dari pemakai, seperti batch processing atau sistem yang sebagian besar melakukan perhitungan, manfaat sedikit dari prototyping. Kadang-kadang, pengkodean dibutuhkan untuk melaksanakan fungsi-fungsi sistem mungkin terlalu intensif dan potensi keuntungan yang prototipe dapat memberikan terlalu kecil. [7]

Prototyping ini terutama baik untuk merancang-manusia yang baik antarmuka komputer. “Salah satu yang paling produktif menggunakan prototipe cepat hingga saat ini telah sebagai alat untuk kebutuhan pengguna iteratif rekayasa dan manusia-komputer desain antarmuka.” [8]

Metode

Ada beberapa metodologi prototyping formal meskipun kebanyakan Metode Agile sangat tergantung pada teknik prototyping.

Metode pengembangan sistem dinamis

Dynamic Systems Development Method (DSDM) [18] adalah kerangka untuk memberikan solusi bisnis yang sangat bergantung pada prototipe sebagai teknik inti, dan itu sendiri ISO 9001 disetujui. Mengembang atas paling mengerti definisi dari sebuah prototipe. Menurut prototipe DSDM dapat berupa diagram, proses bisnis, atau bahkan ditempatkan dalam suatu sistem produksi. DSDM prototipe dimaksudkan untuk menjadi tambahan, berkembang dari bentuk sederhana ke yang lebih komprehensif.

Mungkin prototipe DSDM throwaway atau evolusi. Evolusi prototipe dapat berkembang secara horisontal (luas kemudian kedalaman) atau vertikal (setiap bagian yang dibangun secara rinci dengan rincian iterasi tambahan bagian berikutnya). Evolusi prototipe akhirnya dapat berkembang menjadi sistem final.

Keempat kategori prototipe seperti yang dianjurkan oleh DSDM adalah:

* Bisnis prototipe – digunakan untuk merancang dan menunjukkan proses bisnis yang otomatis.
* Kegunaan prototipe – digunakan untuk mendefinisikan, memperbaiki, dan menunjukkan kegunaan desain antarmuka pengguna, aksesibilitas, lihat dan rasakan.
* Kinerja dan kapasitas prototipe – digunakan untuk mendefinisikan, menunjukkan, dan memprediksi bagaimana sistem ini akan tampil di bawah beban puncak dan juga untuk menunjukkan dan mengevaluasi non-aspek fungsional dari sistem (harga transaksi, volume penyimpanan data, waktu tanggap, dll)
* Kemampuan / teknik prototipe – digunakan untuk mengembangkan, menunjukkan, dan mengevaluasi pendekatan desain atau konsep.

Siklus hidup yang DSDM prototipe adalah untuk:

1. Identifikasi prototipe
2. Setuju rencana
3. Buat prototipe
4. Review prototipe

Operasional prototyping

Prototyping operasional diusulkan oleh Alan Davis sebagai cara untuk mengintegrasikan throwaway dan evolusi prototipe dengan pengembangan sistem konvensional. “[Itu] menawarkan yang terbaik dari baik-dan-cepat kotor dan pengembangan dunia konvensional dalam cara yang masuk akal. Desainer hanya mengembangkan fitur dipahami dengan baik dalam membangun dasar evolusi, sementara menggunakan prototyping sekali pakai untuk bereksperimen dengan fitur yang kurang dipahami. “[5]

Davis ‘keyakinan adalah bahwa untuk mencoba untuk “kualitas retrofit ke prototipe cepat” bukanlah pendekatan yang benar ketika mencoba menggabungkan dua pendekatan. Idenya adalah untuk terlibat dalam suatu evolusi prototipe metodologi dan cepat prototipe fitur dari sistem setelah setiap evolusi.

Metodologi spesifik berikut langkah-langkah berikut: [5]

* Sebuah evolusi prototipe dibangun dan dibuat menjadi dasar menggunakan strategi pembangunan konvensional, hanya menetapkan dan menerapkan persyaratan yang dipahami dengan baik.
* Salinan dari baseline dikirim ke beberapa situs pelanggan bersama dengan prototyper terlatih.
* Pada setiap situs, watches prototyper pengguna pada sistem.
* Setiap kali bertemu pengguna masalah atau berpikir tentang fitur baru atau persyaratan, yang prototyper log itu. Hal ini membebaskan pengguna dari keharusan untuk mencatat masalah, dan memungkinkan mereka untuk terus bekerja.
* Setelah sesi pengguna selesai, prototyper membangun prototipe yang sekali pakai di atas sistem dasar.
* Pengguna sekarang menggunakan sistem baru dan mengevaluasi. Jika perubahan baru tidak efektif, prototyper menghapus mereka.
* Jika pengguna menyukai perubahan, menulis prototyper permintaan fitur-fitur tambahan dan ke depan mereka ke tim pengembangan.
* Tim Pengembangan, dengan perubahan permintaan di tangan dari semua situs, kemudian menghasilkan evolusi baru prototipe menggunakan metode konvensional.

Jelas, kunci untuk metode ini adalah memiliki prototypers terlatih tersedia untuk pergi ke situs pengguna. Prototyping Operasional metodologi memiliki banyak keuntungan dalam sistem yang sangat kompleks dan memiliki sedikit persyaratan yang dikenal di muka.

Pengembangan sistem evolusioner

Pengembangan Sistem evolusioner adalah kelas metodologi yang berusaha secara resmi mengimplementasikan Prototyping Evolusioner. Salah satu tipe tertentu, yang disebut Systemscraft digambarkan oleh John Crinnion dalam bukunya: Evolusi Sistem Pembangunan.

Systemscraft dirancang sebagai ‘prototipe’ metodologi yang harus diubah dan disesuaikan agar sesuai dengan lingkungan spesifik di mana ia diterapkan.

Systemscraft tidak dirancang sebagai kaku ‘buku resep’ pendekatan proses pembangunan. Sekarang umumnya diakui [sic] bahwa metodologi yang baik harus cukup fleksibel untuk dapat disesuaikan agar sesuai dengan segala macam lingkungan dan situasi … [7]

Dasar Systemscraft, tidak seperti Evolutionary Prototyping, adalah untuk menciptakan sebuah sistem kerja dari persyaratan awal dan membangun di atasnya dalam serangkaian revisi. Tempat Systemscraft penekanan pada analisis tradisional yang digunakan selama pengembangan sistem.

Evolusi perkembangan pesat

Evolusioner Rapid Development (ERD) [12] ini dikembangkan oleh Konsorsium Produktivitas Perangkat Lunak, pengembangan teknologi dan integrasi agen untuk Kantor Teknologi Informasi dari Defense Advanced Research Projects Agency (DARPA).

Mendasar untuk ERD adalah konsep yang menyusun sistem perangkat lunak yang didasarkan pada penggunaan kembali komponen, penggunaan perangkat lunak template dan template arsitektur. Continuous sistem evolusi kemampuan dalam respon cepat terhadap perubahan kebutuhan pengguna dan teknologi ditandai oleh evolvable arsitektur, mewakili kelas solusi. Proses berfokus pada penggunaan pengrajin kecil berbasis tim mengintegrasikan sistem rekayasa perangkat lunak dan disiplin bekerja beberapa, seringkali paralel timeboxes durasi pendek dengan sering interaksi pelanggan.

Kunci keberhasilan proyek berbasis ERD sejajar analisis eksplorasi dan pengembangan fitur, infrastruktur, dan komponen dengan dan adopsi teknologi mutakhir yang memungkinkan reaksi cepat perubahan dalam teknologi, pasar, atau persyaratan pelanggan. [9]

Untuk memperoleh pelanggan / user input, sering dijadwalkan dan ad hoc / dadakan pertemuan dengan para pemangku kepentingan diadakan. Kemampuan sistem demonstrasi yang diadakan untuk mengumpulkan umpan balik sebelum desain / pelaksanaan keputusan yang dipadatkan. Frequent rilis (misalnya, beta) yang dibuat tersedia untuk digunakan untuk memberikan pemahaman tentang bagaimana sistem dukungan yang lebih baik dapat pengguna dan kebutuhan pelanggan. Hal ini menjamin bahwa sistem berkembang untuk memenuhi kebutuhan pengguna yang ada.

Kerangka desain untuk sistem ini didasarkan pada pemakaian yang ada secara de facto diterbitkan atau standar. Sistem ini disusun untuk memungkinkan berkembang serangkaian kemampuan yang mencakup pertimbangan kinerja, kapasitas, dan fungsionalitas. Arsitektur didefinisikan dalam istilah antarmuka abstrak yang merangkum layanan dan pelaksanaannya (misalnya, aplikasi Cots). Arsitektur berfungsi sebagai template yang akan digunakan untuk pengembangan membimbing lebih dari satu contoh dari sistem. Hal ini memungkinkan aplikasi untuk beberapa komponen yang akan digunakan untuk melaksanakan layanan. Sebuah set fungsionalitas inti tidak mungkin mengubah juga diidentifikasi dan ditetapkan.

The ERD Proses ini disusun untuk menggunakan fungsi menunjukkan daripada produk kertas sebagai cara bagi para pemangku kepentingan untuk mengkomunikasikan kebutuhan dan harapan mereka. Pusat untuk tujuan ini adalah pengiriman cepat penggunaan “timebox” metode. Timeboxes adalah tetap periode waktu di mana tugas-tugas tertentu (misalnya, mengembangkan sebuah set fungsionalitas) harus dilakukan. Alih-alih membiarkan waktu untuk memperluas untuk memuaskan samar-samar serangkaian tujuan, waktu adalah tetap (baik dari segi kalender minggu dan orang-jam) dan satu set tujuan yang didefinisikan secara realistis dapat dicapai dalam batasan ini. Untuk menjaga pembangunan dari memburuk menjadi “acak berjalan,” rencana jangka panjang yang didefinisikan untuk memandu iterasi. Rencana ini memberikan sebuah visi untuk sistem secara keseluruhan dan menetapkan batas-batas (misalnya, kendala) untuk proyek. Setiap iterasi dalam proses ini dilakukan dalam konteks ini rencana jangka panjang.

Setelah arsitektur didirikan, perangkat lunak terintegrasi dan diuji setiap hari. Ini memungkinkan tim untuk menilai kemajuan objektif dan mengidentifikasi potensi masalah dengan cepat. Karena sejumlah kecil dari sistem yang terintegrasi pada satu waktu, mendiagnosis dan menghilangkan cacat cepat. Pengguna demonstrasi dapat diadakan dalam waktu singkat karena sistem umumnya siap untuk berolahraga di sepanjang waktu.

Scrum

Scrum adalah metode gesit untuk manajemen proyek. Pendekatan ini pertama kali dideskripsikan oleh Takeuchi dan Nonaka dalam “The New New Product Development Game” (Harvard Business Review, Jan-Feb 1986).

Peralatan

Efisien dengan menggunakan prototyping mensyaratkan bahwa sebuah organisasi memiliki alat yang tepat dan staf terlatih untuk menggunakan alat-alat tersebut. Alat yang digunakan dalam prototipe dapat bervariasi dari individu tool seperti bahasa pemrograman generasi 4 digunakan untuk cepat terpadu prototipe yang kompleks CASE tools. 4 generasi bahasa pemrograman seperti Visual Basic dan ColdFusion sering digunakan karena mereka yang murah, terkenal dan relatif mudah dan cepat untuk digunakan. CASE tools, seperti Rekayasa Persyaratan Lingkungan adalah sering dikembangkan atau dipilih oleh militer atau organisasi besar. Alat berorientasi objek juga sedang dikembangkan seperti GE LYMB dari Pusat Penelitian dan Pengembangan. Pengguna unsur prototipe aplikasi diri dalam sebuah spreadsheet.

Screen generator, desain alat & Software Factories

Juga sering digunakan adalah menghasilkan layar program yang memungkinkan pengguna prototypers untuk menunjukkan sistem yang tidak berfungsi, tetapi menunjukkan apa yang mungkin terlihat seperti layar. Mengembangkan Human Computer Interface kadang-kadang dapat menjadi bagian penting dari usaha pembangunan, karena ke antarmuka pengguna pada dasarnya adalah sistem.

Lunak Pabrik adalah Kode Generator yang memungkinkan Anda untuk model domain model dan kemudian drag dan drop UI. Juga mereka memungkinkan Anda untuk menjalankan prototipe dan menggunakan fungsionalitas database dasar. Pendekatan ini memungkinkan Anda untuk menjelajahi domain model dan pastikan sudah sinkron dengan prototipe GUI. Anda juga dapat menggunakan Kontrol UI yang akan nanti akan digunakan untuk pembangunan nyata.

Definisi aplikasi perangkat lunak

Sebuah kelas baru perangkat lunak disebut juga aplikasi perangkat lunak definisi memungkinkan pengguna untuk secara cepat membangun ringan, animasi simulasi program komputer lain, tanpa menulis kode. Aplikasi perangkat lunak simulasi memungkinkan baik teknis dan non-teknis pengguna untuk pengalaman, menguji, berkolaborasi dan memvalidasi program simulasi, dan menyediakan laporan seperti penjelasan, screenshot dan skema. Sebagai solusi spesifikasi teknik, Aplikasi Simulasi jatuh antara berisiko rendah, tetapi terbatas, teks atau gambar berbasis mock-up (atau wireframes) kadang-kadang disebut prototipe berbasis kertas, dan memakan waktu, kode berisiko tinggi berbasis prototip, perangkat lunak yang memungkinkan profesional untuk memvalidasi persyaratan dan pilihan desain awal, sebelum pembangunan dimulai. Dalam melakukannya, risiko dan biaya yang terkait dengan implementasi perangkat lunak dapat dikurangi secara dramatis [1].

Untuk mensimulasikan aplikasi juga dapat menggunakan perangkat lunak yang mensimulasikan dunia nyata program perangkat lunak untuk pelatihan berbasis komputer, demonstrasi, dan dukungan pelanggan, seperti perangkat lunak screencasting daerah-daerah tersebut sangat erat terkait. Ada juga lebih alat-alat khusus. [2] [3] Salah satu alat terkemuka dalam kategori ini adalah iRise.

Visual Basic

Salah satu alat yang paling populer untuk Rapid Prototyping adalah Visual Basic (VB). Microsoft Access, yang mencakup modul Extensibility Visual Basic, juga yang diterima secara luas prototipe alat yang digunakan oleh banyak non-teknis analis bisnis. Meskipun VB adalah bahasa pemrograman yang memiliki banyak fitur yang memudahkan menggunakannya untuk membuat prototip, termasuk:

* Sebuah interaktif / visual desain antarmuka pengguna alat.
* Mudah sambungan dari antarmuka pengguna komponen untuk mendasari perilaku fungsional.
* Mudah untuk belajar dan menggunakan bahasa pelaksanaan (yaitu Dasar).
* Modifikasi untuk perangkat lunak yang dihasilkan mudah dilakukan.

Persyaratan Teknik Lingkungan

“The Persyaratan Teknik Lingkungan (REE), sedang dikembangkan di Roma Laboratorium sejak tahun 1985, menyediakan toolset yang terintegrasi untuk mewakili cepat, bangunan, dan melaksanakan model aspek kritis sistem yang kompleks.” [15]

Persyaratan Teknik Lingkungan saat ini digunakan oleh Angkatan Udara untuk mengembangkan sistem. Ini adalah:

terpadu set alat yang memungkinkan analis sistem untuk secara cepat membangun fungsional, antarmuka pengguna, dan kinerja sistem model prototipe komponen. Kegiatan pemodelan ini dilakukan untuk mendapatkan pemahaman yang lebih kompleks sistem dan mengurangi dampak yang memiliki spesifikasi persyaratan yang tidak akurat pada biaya dan penjadwalan selama proses pengembangan sistem. Model dapat dibangun dengan mudah, dan pada berbagai tingkat abstraksi atau rincian, tergantung pada aspek-aspek perilaku khusus dari model yang dijalankan. [15]

REE terdiri dari tiga bagian. Pertama, yang disebut proto adalah alat KASUS dirancang khusus untuk mendukung pembuatan prototipe cepat. Bagian kedua disebut Rapid Prototyping Interface System atau RIP, yang merupakan kumpulan alat yang memfasilitasi penciptaan user interface. Bagian ketiga dari REE adalah antarmuka pengguna untuk RIP dan proto yang ditujukan untuk grafis dan mudah digunakan.

Roma Laboratorium, pengembang REE, dimaksudkan bahwa untuk mendukung kebutuhan internal mereka metodologi pengumpulan. Metode mereka memiliki tiga bagian utama:

[Satu:] pendatangan dari berbagai sumber yang berarti u longgar (pengguna, interface ke sistem lain), spesifikasi, dan konsistensi memeriksa [Dua:] Analisis bahwa kebutuhan pengguna yang beragam diambil bersama-sama tidak bertentangan dan layak secara teknis dan ekonomis [dan Tiga:] Validasi bahwa persyaratan sehingga diturunkan adalah cerminan akurat kebutuhan pengguna. [15]

Pada tahun 1996, Roma Labs dikontrak Produktivitas Software 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 kode generasi …” [16] Ini Sistem ini bernama Persyaratan Advanced Engineering Workstation atau AREW.

LYMB

LYMB [17] adalah sebuah object-oriented lingkungan pengembangan bertujuan untuk mengembangkan aplikasi yang membutuhkan grafis menggabungkan antarmuka pengguna berbasis, visualisasi, dan cepat prototyping.

Lingkungan non-relasional

Definisi non-relasional data (misalnya menggunakan model asosiatif Cache atau dapat membantu membuat prototipe pengguna akhir lebih produktif dengan menunda atau menghindari kebutuhan untuk menormalkan data pada setiap pengulangan simulasi. Hal ini dapat menghasilkan lebih awal / lebih jelas dari kebutuhan bisnis, meskipun itu tidak secara khusus memastikan bahwa persyaratan secara teknis dan ekonomi layak dalam sistem produksi target.

PSDL

PSDL adalah bahasa deskripsi prototipe untuk menggambarkan perangkat lunak waktu-nyata.

No comments yet»

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: