Computer Programming

It is FUN Programming ^_^

Arsip untuk Uncategorized

Prototyping

Sebuah prototipe adalah jenis asli, bentuk, atau contoh dari sesuatu yang berfungsi sebagai contoh, dasar, atau standar untuk hal-hal lain dari kategori yang sama. Kata ini berasal dari bahasa Yunani πρωτότυπον (prototypon), “pola dasar, asli”, netral dari πρωτότυπος (prototypos), “asli, primitif”, dari πρώτος (protos), “pertama” + τύπος (kesalahan ketik), “kesan”.

Semantik

Dalam semantik, prototip atau contoh proto menggabungkan atribut yang paling representatif dari suatu kategori. Prototipe adalah contoh khas kategori yang berfungsi sebagai tolok ukur terhadap yang di sekitarnya, kurang representatif contoh yang dikategorikan (lihat Prototype Theory).

Desain dan pemodelan

Dalam banyak bidang, ada ketidakpastian besar apakah desain baru akan benar-benar melakukan apa yang diinginkan. Desain baru sering memiliki masalah yang tak terduga. Sebuah prototipe sering digunakan sebagai bagian dari proses desain produk untuk memungkinkan para insinyur dan perancang kemampuan untuk mengeksplorasi alternatif-alternatif desain, tes teori dan kinerja mengkonfirmasi sebelum memulai produksi sebuah produk baru. Insinyur menggunakan pengalaman mereka untuk menyesuaikan prototipe sesuai dengan yang tidak diketahui spesifik masih hadir dalam desain yang diinginkan. Sebagai contoh, beberapa prototipe digunakan untuk mengkonfirmasi dan memverifikasi minat konsumen dalam desain yang diusulkan sedangkan prototipe lainnya akan berusaha untuk memverifikasi kinerja atau kesesuaian pendekatan desain tertentu.

Secara umum, serangkaian berulang-ulang prototipe akan dirancang, dibangun dan diuji sebagai desain akhir muncul dan siap untuk produksi. Dengan pengecualian langka, beberapa iterasi dari prototipe yang digunakan untuk semakin menyempurnakan desain. Strategi umum adalah untuk merancang, menguji, mengevaluasi dan kemudian memodifikasi desain berdasarkan analisis prototipe.

Dalam banyak produk ini, sudah lazim menetapkan pengulangan prototipe huruf Yunani. Sebagai contoh, sebuah prototipe iterasi pertama dapat disebut sebagai “Alpha” prototipe. Sering kali iterasi ini tidak diharapkan untuk melakukan sebagaimana dimaksud dan sejumlah kegagalan atau masalah yang diantisipasi. Iterasi prototyping berikutnya (Beta, Gamma, dll) akan diharapkan untuk menyelesaikan masalah dan melakukan lebih dekat dengan maksud produksi akhir.

Dalam banyak organisasi pengembangan produk, prototipe spesialis dipekerjakan – individu dengan keterampilan khusus dan pelatihan dalam teknik fabrikasi umum yang dapat membantu menjembatani antara teori desain dan fabrikasi prototipe.

Dasar Prototype Kategori

Tidak ada kesepakatan umum tentang apa yang disebut sebagai “prototipe” dan kata tersebut sering digunakan bergantian dengan kata “model” yang dapat menyebabkan kebingungan. Secara umum, “prototipe” jatuh ke dalam empat kategori dasar:

Bukti-of-Prinsip Prototype (Model) (juga disebut papan tempat memotong roti). Jenis prototipe digunakan untuk menguji beberapa aspek desain yang dimaksud tanpa mencoba mensimulasikan persis tampilan visual, pilihan bahan atau dimaksudkan proses manufaktur. Prototipe seperti itu dapat digunakan untuk “membuktikan” keluar pendekatan desain yang potensial seperti berbagai gerakan, mekanik, sensor, arsitektur, dll model jenis ini sering digunakan untuk mengidentifikasi pilihan desain tidak akan bekerja, atau di mana pengembangan dan pengujian lebih lanjut diperlukan.

Studi bentuk Prototype (Model). Jenis prototipe ini akan memungkinkan desainer untuk mengeksplorasi ukuran dasar, tampilan dan nuansa dari suatu produk tanpa simulasi fungsi aktual atau sama persis tampilan visual dari produk. Mereka dapat membantu menilai faktor-faktor ergonomis dan memberikan wawasan tentang aspek-aspek visual dari bentuk akhir produk. Formulir Studi Prototip sering diukir dengan tangan atau dengan mesin model dari mudah diukir, bahan murah (misalnya, urethane busa), tanpa mewakili warna yang dimaksud, selesaikan, atau tekstur. Karena bahan yang digunakan, model ini dimaksudkan untuk pengambilan keputusan internal dan biasanya tidak tahan lama cukup atau cocok untuk digunakan oleh perwakilan pengguna atau konsumen.

Visual Prototype (Model) akan menangkap yang dimaksud mensimulasikan desain estetika dan penampilan, warna dan tekstur permukaan produk yang dimaksud, namun tidak akan benar-benar mewujudkan fungsi (s) dari produk akhir. Model ini akan cocok untuk digunakan dalam riset pasar, eksekutif tinjauan dan persetujuan, kemasan mock-up, dan foto tunas untuk literatur penjualan.

Fungsional Prototype (Model) (juga disebut bekerja prototipe) akan, dengan semaksimal praktis, berusaha untuk mensimulasikan rancangan akhir, estetika, bahan dan fungsionalitas dari desain yang dimaksud. Prototipe fungsional dapat dikurangi dalam ukuran (skala bawah) dalam rangka untuk mengurangi biaya. Pembangunan bekerja sepenuhnya prototipe skala penuh dan ujian akhir konsep, adalah insinyur pemeriksaan terakhir cacat desain dan memungkinkan perbaikan menit-menit terakhir harus dilakukan sebelum produksi yang lebih besar berjalan diperintahkan.

Perbedaan antara prototipe dan desain produksi

Secara umum, prototipe akan berbeda dari produksi akhir mendasar varian dalam tiga cara:

Prototipe sering dibangun melalui non-produksi bahan niat. Bahan produksi mungkin memerlukan proses manufaktur yang melibatkan biaya modal lebih tinggi daripada apa yang praktis untuk prototyping. Sebaliknya, insinyur dari prototipe spesialis akan berusaha untuk mengganti bahan-bahan dengan sifat-sifat yang mensimulasikan materi akhir yang dimaksud.

Prototipe umumnya dibangun melalui tujuan non-produksi proses manufaktur. Sering mahal dan memakan waktu tooling unik diperlukan untuk mengarang desain kustom. Prototipe akan sering kompromi dengan menggunakan proses yang lebih fleksibel.

Prototipe umumnya dibangun dari desain yang telah dikembangkan ke tingkat yang lebih rendah daripada produksi kesetiaan niat. Desain produksi akhir sering memerlukan upaya luas untuk menangkap detail manufaktur volume tinggi. Rincian seperti umumnya tidak beralasan untuk prototipe sebagai beberapa penyempurnaan dengan desain yang kita harapkan. Sering prototipe dibangun dengan menggunakan teknik detail sangat terbatas dibandingkan dengan produksi akhir maksud.

Karakteristik dan Keterbatasan Prototip

Insinyur dan spesialis prototipe berusaha untuk memahami keterbatasan prototipe untuk mensimulasikan persis karakteristik desain yang dimaksudkan mereka. Sebuah tingkat keahlian dan pengalaman yang diperlukan untuk secara efektif menggunakan prototyping sebagai alat verifikasi desain.

Adalah penting untuk menyadari bahwa dengan mereka definisi, prototipe akan mewakili beberapa kompromi dari desain produksi akhir. Disebabkan oleh perbedaan pada material, proses dan desain kesetiaan, adalah mungkin bahwa sebuah prototipe mungkin gagal untuk melakukan bisa diterima sedangkan desain produksi mungkin suara. Sebuah ide counter-intuitif adalah bahwa prototip mungkin sebenarnya bisa diterima sedangkan melakukan desain produksi mungkin cacat karena bahan dan proses prototyping mungkin kadang-kadang mengalahkan rekan-rekan produksi mereka.

Secara umum, dapat diharapkan bahwa prototipe individu biaya akan jauh lebih besar dari biaya produksi terakhir akibat inefisiensi di material dan proses. Prototipe juga digunakan untuk merevisi desain untuk tujuan mengurangi biaya melalui pengoptimalan dan perbaikan.

Hal ini memungkinkan untuk menggunakan pengujian prototipe untuk mengurangi risiko bahwa desain mungkin tidak berfungsi bisa diterima, namun umumnya prototipe tidak bisa menghilangkan semua risiko. Ada pragmatis dan praktis keterbatasan kemampuan prototipe dimaksudkan agar sesuai dengan kinerja akhir produk dan beberapa tunjangan dan teknik penilaian sering diharuskan sebelum bergerak maju dengan desain produksi.

Membangun rancangan lengkap sering mahal dan dapat memakan waktu, terutama ketika diulang beberapa kali – desain bangunan yang lengkap, mencari tahu apa permasalahan dan bagaimana untuk menyelesaikannya, kemudian membangun rancangan lengkap lagi. Sebagai alternatif, “cepat-prototipe” atau “pengembangan aplikasi cepat” teknik yang digunakan untuk prototipe awal, yang mengimplementasikan bagian, tapi tidak semua, dari desain yang lengkap. Hal ini memungkinkan para desainer dan pabrik untuk secara cepat dan murah menguji bagian-bagian desain yang paling mungkin mengalami masalah, memecahkan masalah-masalah itu, dan kemudian membangun rancangan lengkap.

Kontra-intuitif ini ide-bahwa cara tercepat untuk membangun sesuatu adalah, pertama untuk membangun sesuatu yang lain-dibagi oleh perancah dan aturan teleskop.

Tren modern

Dengan kemajuan terbaru dalam pemodelan komputer ini menjadi praktis untuk menghilangkan penciptaan prototipe fisik (kecuali mungkin pada skala sangat dikurangi untuk tujuan promosi), bukan model semua aspek produk akhir sebagai model komputer. Contoh perkembangan seperti dapat dilihat pada Boeing 787 Dreamliner, di mana ukuran penuh pertama realisasi fisik dibuat pada seri produksi. Model komputer sekarang sedang banyak digunakan dalam desain otomotif, baik untuk bentuk (dalam gaya dan aerodinamis dari kendaraan) dan fungsi – terutama untuk memperbaiki kendaraan crashworthiness dan dalam penurunan berat badan untuk meningkatkan jarak tempuh.

Mekanik dan teknik listrik
Sebuah prototipe dari perekonomian Polandia mobil hatchback Beskid 106 dirancang pada 1980-an
Artikel utama: cepat prototyping

Penggunaan yang paling umum dari kata prototipe yang berfungsi, walaupun eksperimental, versi militer non-mesin (misalnya, mobil, peralatan rumah tangga, elektronik) desainer yang mau dibangun oleh sarana produksi massal, sebagai lawan dari mockup , yang merupakan representasi inert mesin penampilan, sering terbuat dari bahan non-tahan lama.

Perancang elektronik sering membangun prototipe pertama dari papan tempat memotong roti atau papan strip atau perfboard, biasanya menggunakan “DIP” paket. Namun, lebih dan lebih sering fungsional prototipe yang pertama dibangun di atas sebuah “prototipe PCB” hampir identik dengan produksi PCB, sebagai manufaktur PCB harga turun dan karena banyak komponen yang tidak tersedia dalam DIP paket, tetapi hanya tersedia dalam paket TPS dioptimalkan untuk menempatkan pada sebuah PCB.

Pembangun mesin militer dan penerbangan lebih suka istilah “eksperimental” dan “pelayanan test”.

Electronics prototyping

Dalam elektronika, prototipe berarti membangun sirkuit yang sebenarnya untuk desain teoretis untuk memverifikasi bahwa itu bekerja, dan untuk menyediakan platform untuk debug fisik jika tidak. Prototipe sering dibangun dengan menggunakan teknik seperti kawat bungkus atau menggunakan veroboard atau papan tempat memotong roti, yang menghasilkan listrik rangkaian benar, tapi satu yang tidak secara fisik identik dengan produk akhir.

Sebuah alat yang berguna untuk dokumen elektronik prototip (terutama yang berbasis papan tempat memotong roti) dan untuk bergerak maju ke produk sebenarnya adalah perangkat lunak open source Fritzing.

Seorang teknisi dapat membangun prototipe (dan membuat tambahan dan modifikasi) lebih cepat dengan teknik ini – namun, jauh lebih cepat dan biasanya lebih murah untuk memproduksi massal PCB kustom dari jenis lain ini prototipe papan. Ini untuk alasan yang sama bahwa menulis sebuah puisi yang tercepat dengan tangan untuk satu atau dua, tapi lebih cepat dengan mencetak tekan jika Anda membutuhkan beberapa ribu eksemplar.

Perkembangan cepat putar PCB perusahaan hebat dan cepat-rumah perakitan PCB gilirannya telah memungkinkan konsep prototyping cepat diterapkan pada desain sirkuit elektronik. Sekarang mungkin, bahkan dengan komponen pasif yang terkecil dan terbesar baik-pitch paket, untuk memiliki papan dan komponen fabbed berkumpul dalam hitungan hari.

Computer Programming / Computer Science
Bagian ini masih diperdebatkan akurasi faktual. Silakan lihat diskusi yang relevan pada halaman pembicaraan. (Mei 2008)
Artikel utama: Software prototyping

Dalam banyak bahasa pemrograman, fungsi prototipe adalah deklarasi subroutine atau fungsi. (Istilah ini agak C / C + +-spesifik; istilah lain untuk pengertian ini adalah tanda tangan, jenis dan antarmuka.) Dalam pemrograman berbasis prototipe (bentuk pemrograman berorientasi objek), baru objek kloning dihasilkan oleh benda-benda yang ada, yang disebut prototipe.

Istilah mungkin juga merujuk pada Prototype Javascript Framework.

Selain itu, istilah dapat mengacu kepada pola desain prototipe.

Lunak prototipe sering disebut sebagai nilai alpha, yang berarti itu adalah versi pertama untuk menjalankan. Sering hanya beberapa fungsi tersebut di implementasikan, fokus utama dari alfa adalah memiliki dasar fungsional kode pada fitur yang dapat ditambahkan. Setelah perangkat lunak kelas alfa memiliki sebagian besar fitur yang dibutuhkan terintegrasi ke dalamnya, menjadi perangkat lunak untuk pengujian beta dari seluruh perangkat lunak dan untuk menyesuaikan program untuk merespon dengan benar saat situasi tak terduga selama pengembangan.

Sering kali pengguna akhir mungkin tidak dapat menyediakan satu set lengkap tujuan aplikasi, rinci masukan, pengolahan, atau output persyaratan dalam tahap awal. Setelah pengguna evaluasi, prototipe lain akan dibangun berdasarkan masukan dari pengguna, dan sekali lagi siklus evaluasi kembali ke pelanggan. Siklus dimulai dengan mendengarkan pengguna, diikuti dengan membangun atau merevisi sebuah mock-up, dan membiarkan pengguna tes mock-up, lalu kembali. Sekarang ada generasi baru dari alat yang disebut Simulasi Aplikasi Software yang membantu dengan cepat mensimulasikan aplikasi sebelum pembangunan mereka.

Extreme pemrograman menggunakan desain iteratif untuk secara bertahap menambahkan satu fitur pada satu waktu untuk prototipe awal.

Pendekatan pembelajaran yang berkesinambungan di dalam organisasi atau bisnis juga dapat menggunakan konsep bisnis atau proses prototipe melalui model perangkat lunak.

Prototipe, Software Prototyping dan Alpha Software
Bagian ini nada atau gaya mungkin tidak cocok untuk Wikipedia. Keprihatinan spesifik dapat ditemukan di halaman pembicaraan. Lihat Wikipedia panduan untuk menulis artikel untuk saran yang lebih baik. (Maret 2009)
Bagian ini mungkin mengandung riset asli atau klaim belum diverifikasi. Harap memperbaiki artikel ini dengan menambahkan referensi. Lihat halaman pembicaraan untuk perincian. (Maret 2009)

Banyak yang berpendapat atas fakta bahwa prototipe perangkat lunak dan perangkat lunak alfa bukanlah hal yang sama, karena fakta bahwa mereka kurang lebih adalah hal yang sama. Satu-satunya perbedaan antara mereka yang secara umum perangkat lunak prototipe yang disebut sebagai perangkat lunak alpha karena kata dan makna dari kata prototipe ini pada umumnya digunakan ketika seseorang berbicara tentang showreel fisik, atau dalam beberapa kasus simulasi sedangkan biaya membuat skala penuh atau skala ukuran acak konsep yang pada awalnya diperkenalkan pada awal proyek.

Untuk lebih penjelasan lebih lanjut tentang masalah apa prototipe adalah kita bisa melihat pada perbandingan ini karena setiap proyek memiliki tahapan yang berbeda mengenai apa atau di mana mereka dalam pembangunan. (Menerima pertimbangan bahwa ini mungkin tidak akan 100% akurat)

Hardware Software Penjelasan
* Konsep * Konsep * Idea
* Bukti * Bukti Konsep Konsep * Kemungkinan cara untuk menunjukkan bahwa teori di balik konsep fungsional.
Bahkan tidak mungkin bekerja sama sekali, tetapi hanya menunjukkan apakah atau tidak mungkin untuk menciptakan.
* Prototype * Alpha * versi pertama produk dimaksudkan untuk showreels dan untuk tujuan pengujian ONLY.
Juga di sini mungkin tidak bekerja sebagai program atau unit, tetapi itu adalah untuk memberikan presentasi visual
dari produk yang mungkin nyata.
* Work In Progress Work In Progress * * Beberapa tahap-tahap perkembangan yang berbeda.
*??? * Beta * Sebagai for Beta, digunakan untuk perangkat lunak yang hampir selesai, tapi masih perlu beberapa perbaikan
dan sering dilakukan oleh umpan balik dari pilihan acak orang (atau Anda dapat mendaftar sebagai
beta tester), tetapi secara umum pengujian produk yang harus diperlakukan sebagai TIDAK DONE.
(tidak ada data mengenai istilah yang sama untuk Hardware)
*??? * Release Candidate * Lebih umum dikenal dari dan digunakan oleh Microsoft dalam pengembangan Sistem Operasi baru
(ex. Windows Longhorn, Vista, Blackcombe, Tujuh) untuk menunjukkan massa bahwa produk dalam
tahap terakhir sebelum dilepaskan sebagai “Finale Produk”. Diketahui telah beberapa RC’s.
(Lihat Windows ME dan perbandingan ke Windows Vista on belum selesai dan bergegas OS’s.)
* Final Produk * Final Produk * Produk yang telah diuji baik di dalam kelompok tes tertutup dan terbuka kelompok uji. Masih
mengandung beberapa masalah kecil, tapi secara umum hal tersebut merupakan suatu produk kerja yang akan bekerja sebagai
itu dibuat untuk, bagi mayoritas pengguna. Jika isu-isu secara bertahap menjadi semakin
masalah langkah-langkah seperti “patch” dan “perbaikan bug” diciptakan untuk produk-produk perangkat lunak, dan
“perbaikan”, “swap” dan / atau “mengingat dan kehancuran” perangkat keras digerakkan untuk menyelamatkan
reputasi perusahaan.

Tapi ingat bahwa baru, versi update produk juga dapat didistribusikan, ex. videogame akan mendapatkan perbaikan bug dan konten tambahan yang mungkin akan dikemas seperti baru, sama, tetapi “tetap” produk, di bawah nama yang sedikit berbeda seperti “Game of the Year” atau “Special Edition” (jangan dikelirukan dengan akhirnya “Special Edition” yang mungkin telah dilepaskan ketika pertandingan pertama kali diluncurkan, mengandung tambahan atau untuk barang dari permainan sebagai promosi), dan hardware mungkin akan diubah dan dirilis di bawah nama perusahaan yang memodifikasi itu. Adalah seperti Shelby Mustang, AMG adalah untuk Mercedes dan Top Secret adalah mobil-mobil lain.

Ini hanya cara yang lebih umum digunakan kata prototipe (seperti untuk tidak menjadi perangkat lunak), tetapi secara umum alfa dan prototipe adalah hal yang sama.

Skala model

Di bidang pemodelan skala (termasuk railroading model, model kendaraan, pesawat model, model militer, dll), prototipe adalah dunia nyata dasar atau sumber untuk model skala seperti nyata EMD GP38-2 lokomotif – yang merupakan prototipe dari Athearn’s (di antara produsen lain) lokomotif model. Secara teknis, setiap objek non-hidup dapat berfungsi sebagai prototipe untuk model, termasuk struktur, peralatan, dan peralatan, dan sebagainya, tetapi pada umumnya prototipe telah datang berarti ukuran penuh dunia nyata kendaraan termasuk mobil (1957 Chevy prototipe telah melahirkan banyak model), peralatan militer (seperti M4 Sherman, menjadi favorit di antara modelers Militer AS), peralatan kereta api, truk-truk, motor, pesawat, dan ruang-kapal (di dunia nyata seperti Apollo / Saturnus Vs, atau ISS) .

Ada perdebatan apakah ‘fiktif’ atau imajiner item dapat dianggap sebagai prototipe (seperti Star Wars atau Star Trek pesawat angkasa, karena kapal-kapal sendiri fitur model atau CGI-artefak), namun, manusia dan benda-benda hidup lainnya tidak pernah disebut prototipe, bahkan ketika mereka adalah dasar untuk model dan boneka (terutama – tindakan angka).

Pada tahun 2005, mesin prototipe cepat konvensional biaya sekitar £ 25.000. [1]

Metrologi

Dalam ilmu dan praktek metrologi, prototipe adalah objek buatan manusia yang digunakan sebagai standar pengukuran kuantitas fisik untuk mendasarkan semua pengukuran kuantitas fisik melawan. Kadang-kadang objek standar ini disebut artefak. Dalam Sistem Internasional Satuan (SI), satu-satunya yang tersisa pada saat prototipe digunakan adalah International Prototype Kilogram, yang solid silinder platinum-iridium yang disimpan di Bureau International des Poids et Mesures (Bureau International des Poids et Mesures) di Sèvres Perancis ( pinggiran Paris) yang menurut definisi adalah massa tepat satu kilogram. Salinan prototipe ini ketinggalan jaman dan dikeluarkan untuk banyak negara untuk mewakili standar nasional kilogram dan secara berkala dibandingkan dengan prototipe Paris.

Sampai tahun 1960, meteran ditentukan oleh platinum-iridium prototipe bar dengan dua tanda guratan di atasnya (yang ada, menurut definisi, terpisah oleh jarak satu meter), International Prototype Metre, dan pada tahun 1983 adalah ulang meter menjadi jarak di ruang tertutup oleh cahaya dalam 1 / 299, 792.458 detik (dengan demikian mendefinisikan kecepatan cahaya menjadi 299.792.458 meter per detik).

Dipercaya secara luas bahwa prototipe kilogram standar akan diganti dengan definisi kilogram yang akan menentukan konstanta fisika yang lain (kemungkinan besar konstanta Planck baik atau biaya dasar) untuk ditetapkan konstan, sehingga menghindarkan kebutuhan untuk prototipe dan menghapus kemungkinan dari prototipe (dan dengan demikian standar dan definisi kilogram) berubah sangat sedikit selama bertahun-tahun karena kerugian atau keuntungan dari atom.

Patologi

Dalam patologi, prototipe mengacu pada penyakit, virus, dll yang menetapkan contoh yang baik untuk seluruh kategori. Misalnya, virus vaccina dianggap sebagai prototipe virus poxviridae.

Keuntungan dan kerugian

Keuntungan dari prototipe

* Mei memberikan bukti konsep yang diperlukan untuk menarik dana
* Awal visibilitas prototipe pengguna memberikan gambaran tentang apa sistem akhir tampak seperti
* Mendorong partisipasi aktif di antara pengguna dan produsen
* Mengaktifkan output yang lebih tinggi untuk user
* Biaya efektif (biaya Pengembangan dikurangi)
* Meningkatkan kecepatan pengembangan sistem
* Membantu untuk mengidentifikasi masalah dengan manfaat desain sebelumnya, persyaratan kegiatan analisis dan coding
* Membantu memperbaiki potensi risiko yang terkait dengan pengiriman sistem yang dikembangkan
* Berbagai aspek dapat diuji dan lebih cepat dapat mendapatkan umpan balik dari pengguna
* Membantu untuk memberikan kualitas produk dengan mudah
* Pengguna interaksi tersedia dalam selama siklus pengembangan prototype

Kerugian prototipe

* Produser bisa menghasilkan sistem yang tidak memadai untuk kebutuhan organisasi secara keseluruhan
* Pengguna dapat terlalu terlibat sedangkan program tidak dapat ke standar yang tinggi
* Struktur sistem dapat rusak karena banyak perubahan yang dapat dibuat
* Produser mungkin terlalu melekat padanya (mungkin menyebabkan keterlibatan hukum) [verifikasi diperlukan]
* Tidak cocok untuk aplikasi besar

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.

List of rapid application development tools

Cross-platform RAD tools

  • Boa constructor is a cross-platform, wxPython based Python RAD IDE
  • Code::Blocks is a cross-platform C/C++ RAD IDE using wxWidgets; the latest developmental builds have a built-in form designer wxSmith, so it’s similar to Borland C++ Builder and Microsoft Visual C++/MFC now.
  • HyperNext is a freeware cross-platform software development system for Macintosh OS X & OS 9, and Microsoft Windows XP & Vista. It has many similarities with HyperCard and can compile to both stand alone applications and stacks for the cross-platform HyperNext Player.
  • IBM Rational Business Developer Extension is a cross-platform, Rapid Application Development IDE for creating enterprise and web applications and services for Windows, Linux, Unix (Solaris, HPUX, AIX), System z and System i
  • IBM Rational Application Developer is a cross-platform, Rapid Application Development IDE for creating enterprise and web applications and services for Windows, Linux and Unix (Solaris, HPUX, AIX)
  • LANSA is a development environment for generating applications on multiple computer systems. The main feature of the LANSA environment is the RDML language. It is classified as a 4GL (4th generation computing language). It runs on many systems including MS Windows, Unix, and Linux. In its first release in 1987, the RDML language was known as lambda
  • Lazarus is a cross-platform IDE similar to Borland Delphi.
  • m-Power is a Software Development tool which automates application development and rapidly creates enterprise-class Web applications over any database or platform.
  • NetBeans is a cross-platform, RAD IDE for creating visual desktop, mobile, web, and SOA applications for Linux, Windows and Mac OS X. The IDE officially supports Java, Ruby, PHP , JavaScript and C/C++ programming languages.
  • Omnis Studio is a cross-platform, Rapid Application Development tool or IDE for creating enterprise and web applications for Windows, Linux, Solaris, and Mac OS X.
  • OpenObject (OpenERP) is a RAD framework in python.
  • OpenROAD is a cross-platform IDE for Linux/Unix, Windows with embedded SQL support
  • Panther (and its open source version POSSL) is a cross-platform (Windows, Unix, Linux; TUI, GUI, Web), cross-database RAD toolset for development of C/S and n-tier database oriented applications.
  • REALbasic is a cross-platform IDE for creating desktop applications for Windows, Linux and Mac OS X.
  • Runtime Revolution is a cross-platform RAD which creates desktop applications for Mac Classic, Mac OS X, Windows 98/Me/XP/Vista, and various flavors of Linux.
  • Web Dynpro is SAP’s RAD to create web applications connected to function modules in mySAP ERP.
  • RadRails is a cross-platform IDE for creating Ruby on Rails web applications.
  • Servoy Servoy is a cross-platform application development and deployment environment. Servoy consists of a GUI designer, is event-driven and runs scripts through JavaScript. Servoy allows applications to be deployed to both a native Smart client / Rich client and to a pure HTML Web client from the same codebase and user interface
  • WideStudio is an open source integrated development environment for desktop applications purely
  • XVT is a cross-platform, Rapid Application Development IDE for creating enterprise and desktop applications in C/C++ on Windows, Linux, Unix (Solaris, HPUX, AIX), and Mac
  • CA Plex, a software development tool that combines the techniques of model-based development, patterns and code generation to accelerate the delivery and maintenance of multi-platform, distributed business applications

Desktop Rapid Application Development Tools

Database Rapid Application Development Tools

Embedded Control Rapid Application Development Tools

  • VisSim is a block diagram language for model based embedded system development
  • LabVIEW is a graphical programming language that allows you to program embedded off-the-shelf systems, FPGAs, custom designs

Web Based Rapid Application Development Tools

  • Active Agenda‘s code generator is a RAD development framework using XML specification files and the PHP development language.
  • Alpha Five is a commercial RAD development environment for both client and web-server based database driven applications. This tool is typically classified with commercial packages such as Microsoft Access and FileMaker.
  • Axiom Stack is an open source web application framework designed to foster rapid development through the use of ECMAscript (JavaScript) and Java. Tools such as the Axiom CMS and Inspector are written to aid in application development.
  • BFC is a RAD framework for both client and server-side development in the .NET environment.
  • CakePHP is a RAD development framework using the PHP development language.
  • CodeCharge Studio is a visual RAD development environment for web-based database driven application development. CodeCharge Studio places emphasis on code generation technology to provide ASP.NET, PHP, JSP, Servlets, ColdFusion and Perl language support.
  • Zend Framework is an open source, object-oriented web application framework licensed under the New BSD License.
  • Django is an open source web application framework, written in Python, which loosely follows the model-view-controller design pattern
  • IBM Rational Business Developer Extension is a cross-platform, Rapid Application Development IDE for creating enterprise and web applications and services for Windows, Linux, Unix (Solaris, HPUX, AIX), System z and System i
  • LibreSource
  • NConstruct is Windows and Web rapid enterprise application development tool and environment for .NET framework.
  • nuBuilder is an open source browser based database development tool which stores all forms, reports, data and any custom code in MySQL and displays the content dynamically.
  • Oracle Application Development Framework uses Oracle’s JDeveloper a FREE IDE that supports ADF’s J2EE based framework.
  • Panther (and its open source version POSSL) is a cross-platform (Windows, Unix, Linux; TUI, GUI, Web), cross-database RAD toolset for development of C/S and n-tier database oriented applications.
  • Pylons is an open source web application framework, written in Python, which makes extensive use of the Web Server Gateway Interface (WSGI) standard to promote re-usability and to separate functionality into distinct modules.
  • Radicore is a RAD development framework using the PHP development language. It is for building administrative web applicatons, not web sites, and includes a Role Based Access Control (RBAC) system, Audit Logging system (without database triggers), Data Dictionary and Workflow system.
  • Ruby on Rails sponsored by 37signals
  • SednaSpace is a browser based Rapid Application Development tool, that generates code in technologies like AJAX, C#, VB.Net, Java and many other.
  • Symfony
  • Thoroughbred T-WEB is a Web RAD tool
  • Web2py is a RAD framework for web-based database driven applications with key features including in-browser coding support, admin/design interface, DAL (database abstraction layer), and translation support.
  • WebDev
  • Wavemaker Visual Ajax Studio is an open-source, browser-based IDE based on Dojo, Spring and Hibernate.
  • Wolf Frameworks is a 100% AJAX, XML & .NET based Platform for designing and delivering cross platform web applications using a browser.
  • Visual WebGui Visual WebGui (VWG) is an open-source rapid application development (RAD) framework for AJAX & Silverlight GUIs. The platform presents a new approach to applying desktop usability to the web by viewing it as an extension to a desktop rather than web
  • cakeApp an online rapid development tool with WYSIWYG SQL editor and framework based on CakePHP.
  • Wavemaker Visual Ajax Studio is an open-source, browser-based IDE based on Dojo, Spring and Hibernate.
  • Genesys Designer is a web based development and design tool for designing forms and pages for mobile and hand-held devices as well as delivering cross platform web applications using a standard internet browser.

Components based on Rapid Application Development paradigm

  • Add-in Express – Visual RAD tool for developing COM add-ins, smart tags, RTD servers and Excel user defined functions in Visual Studio .NET and Delphi.
  • Panther is a cross-platform (Windows, Unix, Linux; TUI, GUI, Web), cross-database RAD toolset for development of n-tier component based database oriented applications. It builds native components employing the same visual paradigm used for client screens. Editions for middleware from IBM, BEA and Microsoft exist (and can be combined).

Rapid Application Development

Model RAD adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek/singkat/cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan :

  1. Component based construction ( pemrograman berbasis komponen ).
  2. Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.
  3. Pembangkitan kode program otomatis/semi otomatis.
  4. Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tapi tidak sama. Banyaknya tim tergantung dari area dan komplekstasnya sstem yang dibangun.

Jika keutuhan yang diinginkan pada tahap analisa kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan untuk menyelesakan secara lengkap perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari.

Model RAD ini sebenarnya hampr sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model in sangat pendek dengan penerapan teknk yang cepat.

System dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tmm dalam waktu yang hampir bersamaan dalam waktu yang sudah ditentukan. Model in melibatkan banyak tim, dan setiap tm mengerjakan tugas yang selevel, namun berbeda. Sesuai dengan pembagian modul system.

Beberapa hal (kelebhan dan kekurangan) yang perlu diperhatikan dalam implementasi pengembangan menggunakan model RAD :

  1. Model RAD memerlukan sumber daya yang cukup besar, terutama untuk proyek dengan skala besar.
  2. Model ini cocok untuk proyek dengan skala besar.
  3. Model RAD memerlukan komitmen yang kuat antara pengembang dan pemesssan, bahkan keduanya bisa tergabung dalam 1 tim
  4. kinerja dari perangkat lunak yang dihasilkan dapat menjadi masalah manakala kebutuhan-kebutuhan diawal proses tidak dapat dimodulkan, sehingga pendekatan dengan model ini kurang bagus.
  5. sisttem yang tidak bisa dimodularisasi tidak cocok untuk model ini.
  6. penghalusan dan penggabungan dari beberapa tim di akhir proses sangat diperlukan dan ini memerlukan kerja keras.
  7. proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
  8. resiko tekns yang tinggi juga kurang cocok untuk model ini.

Diperoleh dari “http://id.wikipedia.org/wiki/Rapid_Application_Development

XP

Extreme Programming (XP) adalah metodologi rekayasa perangkat lunak yang dimaksudkan untuk meningkatkan kualitas perangkat lunak dan responsif terhadap perubahan kebutuhan pelanggan. Sebagai jenis gesit pengembangan perangkat lunak, [1] [2] [3] itu para pendukung sering “rilis” dalam siklus pembangunan pendek (timeboxing), yang dimaksudkan untuk meningkatkan produktivitas dan memperkenalkan pos pemeriksaan di mana persyaratan pelanggan baru dapat diadopsi.

Unsur-unsur lain Extreme Programming meliputi: pemrograman berpasangan atau kode ekstensif melakukan peninjauan, pengujian unit semua kode, menghindari fitur-fitur pemrograman sampai mereka benar-benar diperlukan, struktur manajemen yang datar, kesederhanaan dan kejelasan dalam kode, mengharapkan perubahan dalam kebutuhan pelanggan sebagai waktu berlalu dan masalah lebih baik dimengerti, dan sering komunikasi dengan pelanggan dan di antara programer. [2] [3] [4] Metodologi mengambil namanya dari gagasan bahwa unsur menguntungkan rekayasa perangkat lunak tradisional praktik dibawa ke “ekstrem “tingkatan, berdasarkan teori bahwa jika ada yang baik, lebih banyak lebih baik. Hal ini tidak berhubungan dengan “coding koboi”, yang lebih bebas bentuk dan tidak direncanakan. Tidak menganjurkan “kematian march” jadwal kerja, tapi malah bekerja di sebuah langkah berkelanjutan. [5]

Kritikus melihat adanya beberapa potensi kelemahan, [6] termasuk masalah dengan persyaratan yang tidak stabil, tidak ada kompromi pengguna didokumentasikan konflik, dan kurangnya desain keseluruhan spec atau dokumen.

Sejarah

Extreme Programming diciptakan oleh Kent Beck selama bekerja di Chrysler Menyeluruh Sistem Kompensasi (C3) proyek penggajian. [6] Beck C3 menjadi pemimpin proyek Maret 1996 dan mulai untuk memperbaiki metode pengembangan yang digunakan dalam proyek dan menulis sebuah buku tentang metode (pada Oktober 1999, Extreme Programming Explained diterbitkan). [6] Chrysler membatalkan proyek C3 pada Februari 2000, setelah perusahaan diakuisisi oleh Daimler-Benz. [7]

Meskipun Extreme Programming itu sendiri adalah relatif baru, banyak dari praktik sudah ada selama beberapa waktu, metodologi, setelah semua, diperlukan “praktek terbaik” untuk tingkat ekstrem. Sebagai contoh, “tes-praktek pembangunan pertama, perencanaan dan tes tertulis sebelum setiap mikro-increment” digunakan sebagai awal NASA Project Mercury, pada awal 1960-an (Larman 2003). Refactoring, modularitas, bottom-up dan desain inkremental digambarkan oleh Leo Brodie dalam bukunya yang diterbitkan pada tahun 1984 [8].

Asal

Sebagian besar pengembangan perangkat lunak pada 1990-an dibentuk oleh dua pengaruh utama: internal, pemrograman berorientasi objek pemrograman prosedural digantikan sebagai paradigma pemrograman yang disukai oleh beberapa orang dalam industri; eksternal, munculnya internet dan booming dot-com-untuk menekankan kecepatan pasar dan perusahaan-pertumbuhan sebagai faktor bisnis kompetitif. Persyaratan berubah dengan cepat menuntut lebih pendek siklus hidup produk, dan sering tidak sesuai dengan metode tradisional pengembangan perangkat lunak.

Chrysler Menyeluruh Sistem Kompensasi dimulai dalam rangka untuk menentukan cara terbaik untuk menggunakan teknologi obyek, dengan menggunakan sistem penggajian di Chrysler sebagai objek penelitian, dengan sebagai bahasa Smalltalk dan batu permata sebagai lapisan akses data. Mereka dibawa di Kent Beck, [6] Smalltalk praktisi terkemuka, untuk melakukan kinerja tuning pada sistem, tetapi perannya diperluas ketika ia melihat adanya beberapa persoalan yang mereka hadapi dengan proses pembangunan mereka. Dia mengambil kesempatan ini untuk mengusulkan dan mengimplementasikan beberapa perubahan dalam praktik mereka didasarkan pada sering bekerja dengan kolaborator, Ward Cunningham.

Pertama kali saya diminta untuk memimpin sebuah tim, saya meminta mereka untuk melakukan sedikit hal yang saya pikir itu masuk akal, seperti pengujian dan ulasan. Kedua kali ada lebih banyak di telepon. Saya pikir, “Sialan torpedo, setidaknya ini akan membuat artikel yang baik,” [dan] meminta tim untuk mendongkrak semua tombol-tombol untuk 10 pada hal-hal yang saya pikir sangat penting dan meninggalkan segala sesuatu yang lain. -Kent Beck

Ron Jeffries Beck diundang ke proyek untuk membantu mengembangkan dan memperbaiki metode ini. Jeffries kemudian bertindak sebagai pelatih untuk menanamkan praktek-praktek sebagai kebiasaan dalam tim C3.

Informasi tentang prinsip-prinsip dan praktek-praktek di belakang XP ini disebarluaskan ke dunia yang lebih luas melalui diskusi di Wiki asli, WikiWikiWeb Cunningham. Berbagai kontributor dibahas dan dikembangkan atas ide-ide, dan beberapa spin-off metodologi yang mengakibatkan (lihat gesit pengembangan perangkat lunak). Selain itu, konsep XP telah dijelaskan, selama beberapa tahun, menggunakan sistem teks hiper-peta di website XP di “www.extremeprogramming.org” sekitar tahun 1999 (website XPorg).

Beck edited serangkaian buku on XP, mulai dengan dirinya sendiri “Extreme Programming Explained (1999, ISBN 0-201-61641-6)”, menyebarkan ide-idenya ke yang lebih besar, namun sangat reseptif, penonton. Penulis dalam seri melewati berbagai aspek menghadiri XP dan praktik, bahkan sebuah buku kritis terhadap praktek-praktek.

Current state

XP cukup menciptakan buzz di akhir 1990-an dan awal 2000-an, melihat adopsi dalam sejumlah lingkungan yang sangat berbeda dari asal-usulnya.

Disiplin tinggi yang diperlukan oleh praktek-praktek asli sering pergi di pinggir jalan, menyebabkan beberapa praktik yang dianggap terlalu kaku untuk menjadi usang atau kiri dibatalkan di setiap situs. Praktek-praktek pembangunan tangkas tidak berdiri diam, dan XP masih berkembang, asimilasi lebih banyak pelajaran dari pengalaman di lapangan. Dalam edisi kedua Extreme Programming Dijelaskan, Beck menambahkan lebih banyak nilai-nilai dan praktik-praktik dan dibedakan antara primer dan praktek wajar.

Konsep

Tujuan

“Extreme Programming Explained” Extreme Programming menggambarkan sebagai pengembangan perangkat lunak disiplin yang mengatur orang untuk menghasilkan perangkat lunak berkualitas tinggi lebih produktif.

Dalam metode pengembangan sistem tradisional (seperti SSADM atau model air terjun) persyaratan untuk sistem ditentukan pada awal proyek pengembangan dan sering kali tetap dari saat itu. Ini berarti bahwa biaya mengubah persyaratan pada tahap berikutnya (fitur yang umum proyek rekayasa perangkat lunak) akan menjadi tinggi. Seperti metode pengembangan perangkat lunak gesit, XP upaya untuk mengurangi biaya perubahan dengan memiliki banyak siklus pengembangan yang pendek, bukan dari satu panjang. Dalam perubahan doktrin ini adalah alami, tak terhindarkan dan aspek diinginkan proyek-proyek pengembangan perangkat lunak, dan harus direncanakan untuk alih-alih mencoba untuk mendefinisikan sebuah set persyaratan stabil.

Extreme Programming juga memperkenalkan sejumlah nilai-nilai dasar, prinsip dan praktek-praktek di atas kerangka pemrograman lincah.

Kegiatan

XP menggambarkan empat kegiatan dasar yang dilakukan dalam proses pengembangan perangkat lunak.

Coding
Pendukung XP berpendapat bahwa satu-satunya benar-benar produk yang penting dari proses pengembangan sistem kode – instruksi perangkat lunak komputer dapat menafsirkan. Tanpa kode, tidak ada produk kerja.

Coding juga dapat digunakan untuk mengetahui solusi yang paling cocok. Sebagai contoh, XP akan menganjurkan bahwa dihadapkan dengan beberapa alternatif untuk masalah pemrograman, satu kode hanya perlu semua solusi dan menentukan dengan tes yang otomatis solusi yang paling sesuai. [Rujukan?] Coding juga dapat membantu untuk mengkomunikasikan pikiran tentang masalah pemrograman. Seorang pemrogram berurusan dengan masalah pemrograman yang kompleks dan sulit untuk menjelaskan solusi untuk sesama programer mungkin kode ini dan gunakan kode untuk menunjukkan apa yang dia berarti. Kode, mengatakan para pendukung posisi ini, selalu jelas dan ringkas dan tidak dapat ditafsirkan dengan lebih dari satu cara. Pemrogram lain dapat memberikan umpan balik kode ini oleh juga pengkodean pikiran mereka.

Pengujian
Satu tidak bisa memastikan bahwa fungsi bekerja kecuali satu tes itu. Desain bug dan masalah kesalahan yang meresap dalam pengembangan software. Extreme Programming Pendekatan adalah bahwa jika sedikit pengujian dapat menghilangkan beberapa kekurangan, banyak pengujian dapat menghilangkan banyak kelemahan.

* Unit tes menentukan apakah fitur yang diberikan bekerja sebagaimana dimaksud. Seorang pemrogram menulis sebagai banyak tes otomatis mereka bisa memikirkan yang dapat “memecahkan” kode; jika semua tes berjalan dengan sukses, maka pengkodean selesai. Setiap potongan kode yang tertulis diuji sebelum pindah ke fitur berikutnya.
* Tes Penerimaan memverifikasi bahwa persyaratan sebagaimana yang dipahami oleh para programer memenuhi persyaratan pelanggan yang sebenarnya. Ini terjadi pada tahap eksplorasi perencanaan rilis.

Sebuah “testathon” adalah sebuah peristiwa ketika programmer bertemu untuk melakukan tes kolaboratif menulis, semacam brainstorming relatif terhadap pengujian perangkat lunak.

Mendengarkan
Programmer harus mendengarkan apa yang pelanggan membutuhkan sistem untuk melakukan, apa yang “logika bisnis” diperlukan. Mereka harus memahami kebutuhan-kebutuhan ini cukup baik untuk memberikan umpan balik pelanggan tentang aspek teknis bagaimana masalah bisa dipecahkan, atau tidak dapat dipecahkan. Pemahaman masalah nya. Komunikasi antara pelanggan dan pemrogram adalah dibahas lebih lanjut dalam The Perencanaan Game.

Merancang
Dari sudut pandang kesederhanaan, orang bisa mengatakan bahwa pengembangan sistem tidak membutuhkan lebih dari coding, pengujian dan mendengarkan. Jika kegiatan tersebut dilakukan dengan baik, hasilnya harus selalu menjadi sistem yang bekerja. Dalam prakteknya, ini tidak akan bekerja. Satu dapat datang jauh tanpa merancang tetapi pada waktu tertentu seorang pun akan terjebak. Sistem menjadi terlalu kompleks dan dependensinya di dalam sistem berhenti menjadi jelas. Satu dapat menghindari hal ini dengan menciptakan sebuah desain struktur yang mengatur logika dalam sistem. Desain yang baik akan menghindari banyak dependensi dalam sistem ini berarti bahwa mengubah salah satu bagian dari sistem tidak akan mempengaruhi bagian lain dari sistem. [Rujukan?]

Nilai

Extreme Programming awalnya empat nilai diakui pada tahun 1999. Sebuah nilai baru ditambahkan dalam edisi kedua Extreme Programming Explained. Kelima nilai:

Komunikasi
Membangun sistem perangkat lunak mengharuskan persyaratan sistem komunikasi untuk para pengembang sistem. Dalam metodologi pengembangan perangkat lunak formal, tugas ini dilakukan melalui dokumentasi. Extreme Programming teknik dapat dipandang sebagai metode untuk cepat membangun dan menyebarkan pengetahuan kelembagaan di antara anggota suatu tim pengembangan. Tujuannya adalah untuk memberikan semua pengembang pandangan bersama sistem yang cocok dengan pandangan yang dipegang oleh para pengguna sistem. Untuk tujuan ini, Extreme Programming menyukai desain sederhana, Common metafora, kolaborasi antara pengguna dan pemrogram, sering komunikasi verbal, dan umpan balik.

Kesederhanaan
Extreme Programming mendorong dimulai dengan solusi sederhana. Fungsionalitas tambahan kemudian dapat ditambahkan kemudian. Perbedaan antara pendekatan ini dan lebih banyak metode pengembangan sistem konvensional adalah fokus pada perancangan dan coding untuk kebutuhan hari ini daripada orang-orang yang besok, minggu depan, atau bulan depan. Ini kadang-kadang disimpulkan sebagai “Anda tidak akan memerlukannya” pendekatan. [5] Para pendukung XP mengakui kerugian yang terkadang hal ini bisa berarti besok lebih banyak usaha untuk mengubah sistem klaim mereka adalah bahwa ini adalah lebih dari kompensasi untuk oleh keuntungan dari tidak berinvestasi dalam masa depan mungkin persyaratan yang mungkin akan berubah sebelum mereka menjadi relevan. Coding dan merancang untuk kebutuhan masa depan tidak pasti menyiratkan risiko mengeluarkan sumber daya untuk sesuatu yang mungkin tidak diperlukan. Terkait dengan “komunikasi” nilai, kesederhanaan dalam desain dan pengkodean harus meningkatkan kualitas komunikasi. Sebuah desain sederhana dengan kode yang sangat sederhana dapat dengan mudah dipahami oleh sebagian besar programmer dalam tim.

Umpan balik
Dalam Extreme Programming, umpan balik berkaitan dengan dimensi yang berbeda dari pengembangan sistem:

* Saran atau masukan dari sistem: dengan menulis unit test, [6] atau menjalankan tes integrasi periodik, programer umpan balik langsung dari keadaan sistem setelah menerapkan perubahan.
* Umpan balik dari pelanggan: tes fungsional (alias penerimaan tes) yang ditulis oleh pelanggan dan penguji. Mereka akan mendapatkan umpan balik yang konkret tentang keadaan saat ini sistem mereka. Tinjauan ini direncanakan sekali dalam setiap dua atau tiga minggu sehingga pelanggan dapat dengan mudah mengarahkan pembangunan.
* Saran atau masukan dari tim: Ketika pelanggan datang dengan persyaratan baru dalam permainan perencanaan tim langsung memberikan perkiraan waktu yang akan dibutuhkan untuk melaksanakan.

Saran atau masukan sangat erat terkait dengan komunikasi dan kesederhanaan. Kelemahan dalam sistem dengan mudah dikomunikasikan dengan menulis sebuah unit tes yang membuktikan suatu potongan kode tertentu akan pecah. Umpan balik langsung dari sistem recode mengatakan pemrogram untuk bagian ini. Seorang pelanggan dapat menguji sistem secara berkala sesuai dengan persyaratan fungsional, yang dikenal sebagai pengguna cerita. [6] Untuk kutipan Kent Beck, “Optimisme adalah risiko pekerjaan pemrograman, umpan adalah pengobatan.” [Rujukan?]

Keberanian
Beberapa praktek mewujudkan keberanian. Salah satunya adalah perintah untuk selalu desain dan kode untuk hari ini dan tidak untuk besok. Ini adalah upaya untuk menghindari macet dalam desain dan memerlukan banyak upaya untuk menerapkan apa-apa lagi. Keberanian memungkinkan pengembang untuk merasa nyaman dengan refactoring kode mereka bila diperlukan. [6] Ini berarti meninjau sistem yang ada dan memodifikasi sehingga perubahan masa depan dapat dilaksanakan dengan lebih mudah. Contoh lain dari keberanian adalah mengetahui kapan harus membuang kode menjauh: keberanian untuk menghapus kode sumber yang is obsolete, tidak peduli seberapa banyak usaha yang digunakan untuk membuat kode sumber itu. Juga, keberanian berarti ketekunan: Seorang pemrogram mungkin akan terjebak pada masalah yang kompleks untuk satu hari, lalu memecahkan masalah dengan cepat pada hari berikutnya, jika hanya mereka gigih.

Respect
Nilai penghormatan mewujud dalam beberapa cara. Dalam Extreme Programming, anggota tim saling menghormati satu sama lain karena pemrogram tidak boleh melakukan perubahan yang melanggar kompilasi, yang membuat unit-tes yang ada gagal, atau yang lain menunda pekerjaan teman mereka. Anggota menghormati pekerjaan mereka dengan selalu berusaha untuk kualitas tinggi dan mencari desain yang terbaik untuk solusi di tangan melalui refactoring.

Mengadopsi empat sebelumnya mengarah untuk menghormati nilai-nilai yang diperoleh dari orang lain dalam tim. Tak seorang pun di tim harus merasa tidak dihargai atau diabaikan. Hal ini memastikan tingkat tinggi motivasi dan mendorong loyalitas terhadap tim, dan tujuan proyek. Nilai ini sangat tergantung pada nilai-nilai lain, dan sangat banyak berorientasi terhadap orang-orang dalam tim.

Aturan

Versi pertama dari peraturan XP diusulkan oleh Ken Hauer [9] di XP / Agile Universe 2003. Dia merasa XP ditentukan oleh aturan, bukan praktek (yang tunduk pada lebih variasi dan ambiguitas). Dia mendefinisikan dua kategori: “Rules of Engagement” yang mendikte lingkungan di mana pengembangan perangkat lunak dapat berlangsung secara efektif, dan “Rules of Play” yang mendefinisikan menit-demi-menit kegiatan dan aturan dalam rangka Rules of Engagement.

Dalam lokakarya di ICSE Apso 2008 Konferensi, Mehdi mengusulkan Mirakhorli yang baru dan lebih tepat dan komprehensif versi Extreme Programming Aturan, lebih independen dari praktek, dan dimaksudkan untuk menjadi lebih “lincah”.

Aturan keterlibatan

Menurut Mehdi Mirakhorli, ini adalah: [rujukan?]

* Bisnis orang dan pengembang melakukan kerja bersama: Bisnis orang dan pengembang harus bekerja sama setiap hari sepanjang proyek.
* Prioritas tertinggi kami adalah kepuasan pelanggan: Pelanggan harus menetapkan dan terus-menerus menyesuaikan tujuan dan prioritas yang didasarkan pada perkiraan dan informasi lain yang disediakan oleh pengembang atau anggota tim. Tujuan ditetapkan dalam hal apa yang tidak seberapa.
* Memberikan perangkat lunak bekerja sering: Memberikan perangkat lunak bekerja sering, dari beberapa minggu sampai beberapa bulan, dengan preferensi untuk skala waktu yang lebih pendek (timeboxing).
* Bekerja perangkat lunak: perangkat lunak Bekerja ukuran utama kemajuan.
* Global kesadaran: Pada setiap titik, setiap anggota tim harus mampu mengukur kemajuan tim pelanggan tujuan dan tim mencerminkan tentang bagaimana untuk menjadi lebih efektif, maka lagu-lagu dan mengatur perilakunya sesuai.
* Tim harus bertindak sebagai jaringan sosial yang efektif, yang berarti:
o Jujur komunikasi terkemuka untuk terus belajar dan penekanan pada orang-ke-orang interaksi, bukan dokumentasi.
o Minimal derajat pemisahan dari apa yang dibutuhkan oleh tim untuk membuat kemajuan dan orang-orang / sumber daya yang dapat memenuhi kebutuhan tersebut.
o Alignment wewenang dan tanggung jawab.

Prinsip

Prinsip-prinsip yang membentuk dasar XP didasarkan pada nilai-nilai yang baru saja dijelaskan dan ditujukan untuk mendorong keputusan dalam suatu proyek pengembangan sistem. Prinsip-prinsip ini dimaksudkan untuk menjadi lebih konkret daripada nilai-nilai dan lebih mudah diterjemahkan untuk panduan dalam situasi praktis.

Umpan balik
Extreme Programming melihat umpan balik yang paling berguna jika hal itu dilakukan dengan cepat dan mengungkapkan bahwa waktu antara aksi dan umpan balik yang sangat penting untuk belajar dan membuat perubahan. Tidak seperti metode pengembangan sistem tradisional, kontak dengan pelanggan lebih sering terjadi pada iterasi. Pelanggan memiliki pandangan yang jelas ke dalam sistem yang sedang dikembangkan. Ia dapat memberikan umpan balik dan mengarahkan pembangunan sesuai dengan kebutuhan.

Unit test juga berkontribusi terhadap prinsip umpan balik yang cepat. Ketika menulis kode, pengujian unit langsung menyediakan umpan balik tentang bagaimana sistem bereaksi terhadap perubahan yang telah dibuat. Jika, misalnya, perubahan mempengaruhi bagian dari sistem yang tidak dalam lingkup para programmer yang membuat mereka, bahwa programmer tidak akan melihat cacat. Ada kemungkinan besar bug ini akan muncul ketika sistem sedang dalam produksi.

Mengasumsikan kesederhanaan
Ini tentang memperlakukan setiap masalah sebagai jika solusi yang “sangat sederhana”. Metode pengembangan sistem tradisional mengatakan untuk merencanakan masa depan dan untuk kode untuk usabilitas. Extreme pemrograman menolak ide-ide ini.

Pendukung Extreme Programming bilang bahwa membuat perubahan besar sekaligus tidak bekerja. Extreme Programming berlaku perubahan tambahan: misalnya, sistem mungkin rilis kecil setiap tiga minggu. Ketika banyak langkah-langkah kecil yang dibuat, pelanggan memiliki lebih banyak kontrol atas proses pembangunan dan sistem yang sedang dikembangkan.

Merangkul perubahan
Prinsip perubahan merangkul tentang tidak bekerja melawan perubahan tetapi memeluk mereka. Sebagai contoh, jika pada salah satu pertemuan berulang-ulang tampak bahwa persyaratan pelanggan telah berubah secara dramatis, programer adalah untuk merangkul rencana ini dan persyaratan baru untuk iterasi berikutnya.

Praktek
Untuk detail lebih lanjut tentang topik ini, lihat Extreme Programming Praktek.

Extreme Programming telah digambarkan memiliki 12 praktek-praktek, yang dikelompokkan ke dalam empat bidang:

Fine skala umpan

* Pair programming [6]
* Perencanaan permainan
* Test pembangunan berbasis
* Seluruh tim

Proses Continuous

* Continuous integrasi
* Refactoring atau perbaikan desain [6]
* Kecil rilis

Shared pemahaman

* Coding standar
* Kode kepemilikan kolektif [6]
* Wikipedia desain [6]
* Sistem metafora

Programmer kesejahteraan

* Berkelanjutan kecepatan

Coding

* Pelanggan selalu tersedia
* Kode Unit pertama tes
* Hanya satu pasang kode terintegrasi pada satu waktu
* Tinggalkan Optimasi sampai terakhir
* Tidak Lembur

Pengujian

* Semua kode harus memiliki tes Unit
* Semua kode harus lulus semua tes Unit sebelum dapat dilepaskan.
* Ketika sebuah Bug ditemukan tes diciptakan sebelum bug tersebut ditujukan (bug bukan kesalahan dalam logika, itu adalah ujian Anda lupa untuk menulis)
* Tes Penerimaan dijalankan sering dan hasilnya dipublikasikan

kontroversial aspek

Praktik di XP telah sangat diperdebatkan [6] dengan pendapat yang kuat untuk atau melawan menggunakan XP.

Extreme Programming pendukung klaim bahwa dengan memiliki on-site pelanggan [6] perubahan permintaan informal, proses menjadi fleksibel, dan menghemat biaya overhead formal. Kritik terhadap klaim XP ini dapat mengakibatkan proyek mahal mengolah dan scope creep di luar apa yang sebelumnya setuju atau didanai.

Ubah papan pengendalian adalah suatu tanda bahwa ada potensi konflik dalam tujuan proyek dan kendala antara beberapa pengguna. Metodologi yang dipercepat XP agak tergantung pada programmer yang bisa menganggap sudut pandang klien yang bersatu sehingga pemrogram dapat berkonsentrasi pada dokumentasi coding daripada kompromi tujuan dan kendala. Hal ini juga berlaku bila beberapa organisasi pemrograman yang terlibat, terutama organisasi yang bersaing untuk saham proyek. [Rujukan?]

Lain yang mungkin aspek-aspek kontroversial Extreme Programming meliputi:

* Persyaratan otomatis dinyatakan sebagai bukan tes penerimaan dokumen spesifikasi.
* Persyaratan didefinisikan secara bertahap, daripada mencoba untuk mendapatkan mereka semua di muka.
* Software pengembang biasanya diperlukan untuk bekerja berpasangan.
* Ada Big Design Up Front. Sebagian besar kegiatan desain terjadi pada terbang dan secara bertahap, dimulai dengan “hal yang paling sederhana yang bisa bekerja” dan menambahkan kompleksitas hanya ketika itu diperlukan oleh tes gagal. Kritikus bandingkan untuk “debug sistem menjadi penampilan” dan ketakutan ini akan menghasilkan desain yang lebih ulang upaya daripada hanya merancang ulang ketika persyaratan perubahan.
* Seorang pelanggan perwakilan dilampirkan pada proyek. Peran ini dapat menjadi satu-point-of-kegagalan untuk proyek, dan beberapa orang telah menemukan itu untuk menjadi sumber stres. Juga, ada bahaya mikro-manajemen oleh perwakilan non-teknis mencoba mendikte penggunaan fitur-fitur software teknis dan arsitektur.
Dependensi * atas semua aspek lain dari XP: “XP adalah seperti lingkaran ular berbisa, daisy-dirantai bersama-sama. Yang dibutuhkan adalah untuk salah satu dari mereka meronta lepas, dan kau punya sangat marah, ular berbisa menuju jalan . [10]

Skalabilitas

Secara historis, XP hanya bekerja pada tim dari dua belas atau lebih sedikit orang. Salah satu cara untuk menghindari keterbatasan ini adalah untuk memecah proyek ke beberapa bagian dan tim tersebut menjadi kelompok-kelompok kecil. Telah menyatakan bahwa XP telah digunakan dengan sukses di tim yang terdiri dari lebih dari seratus pengembang [rujukan?]. ThoughtWorks telah menyatakan keberhasilan wajar pada proyek XP didistribusikan hingga enam puluh orang [rujukan?].

Pada tahun 2004 Industri Extreme Programming (IXP) [11] diperkenalkan sebagai suatu evolusi dari XP. Hal ini dimaksudkan untuk membawa kemampuan untuk bekerja dalam tim besar dan didistribusikan. Sekarang memiliki 23 praktek-praktek dan nilai-nilai yang fleksibel. Karena ini adalah anggota baru keluarga Agile, tidak ada cukup data untuk membuktikan kegunaan, namun mengklaim sebagai sebuah jawaban untuk XP ketidaksempurnaan.

Pemutusan dan tanggapan

Pada tahun 2003, Matt Stephens dan Doug Rosenberg menerbitkan sebuah buku di bawah disebut Apress Extreme Programming Refactored: Kasus Against XP yang mempertanyakan nilai proses XP dan menyarankan cara-cara yang dapat ditingkatkan. Hal ini memicu perdebatan panjang di artikel, internet newsgroup, dan situs web daerah bercakap-cakap. Argumen inti dari buku ini adalah bahwa praktek XP saling bergantung tetapi hanya sedikit organisasi praktis yang bersedia / mampu mengadopsi semua praktek-praktek sehingga seluruh proses gagal. Buku ini juga membuat kritik lain dan menarik patung XP “kepemilikan kolektif” model untuk sosialisme di cara negatif.

Aspek-aspek tertentu dari XP telah berubah sejak buku Extreme Programming Refactored (2003) diterbitkan; pada khususnya, XP sekarang menampung modifikasi pada praktik selama tujuan yang dibutuhkan masih terpenuhi. Semakin XP juga menggunakan istilah generik untuk proses. Beberapa berpendapat bahwa perubahan ini membatalkan kritik sebelumnya; lain mengklaim bahwa ini hanyalah proses menyiram ke bawah.

RDP Praktek adalah teknik untuk menjahit Extreme Programming. Praktek ini awalnya diusulkan sebagai penelitian panjang kertas ke dalam lokakarya yang diselenggarakan oleh Philippe Kruchten dan Steve Adolph (Lihat Apso lokakarya di ICSE 2008) dan namun adalah satu-satunya metode yang diusulkan dan berlaku untuk mengkustomisasi XP. Berharga RDP konsep di balik praktik, dalam waktu singkat memberikan alasan untuk penerapan dalam industri. RDP Praktek mencoba untuk menyesuaikan XP dengan mengandalkan teknik XP Rules.

Penulis lain telah berusaha untuk mendamaikan XP dengan metode yang lebih tua untuk membentuk metodologi yang bersatu. Beberapa XP ini berusaha untuk menggantikan, seperti metode air terjun; contoh: siklus hidup Proyek: Air Terjun, Rapid Application Development, dan All That. JPMorgan Chase & Co mencoba menggabungkan XP dengan pemrograman komputer metodologi CMMI (CMMI), dan Six Sigma. Mereka menemukan bahwa sistem tiga satu sama lain diperkuat dengan baik, mengarah pada pembangunan yang lebih baik, dan tidak saling bertentangan.

Extreme Programming

xtreme Programming pertama proyek dimulai 6 Maret 1996. Extreme Programming adalah salah satu dari beberapa Agile populer Processes. Telah terbukti sangat sukses pada banyak perusahaan dari semua ukuran dan industri yang berbeda di seluruh dunia.
Extreme Programming berhasil karena menekankan kepuasan pelanggan. Alih-alih memberikan semua yang anda mungkin ingin pada beberapa tanggal jauh di masa depan proses ini memberikan perangkat lunak yang Anda butuhkan saat Anda membutuhkannya. Extreme Programming memberdayakan pengembang untuk percaya diri Anda menanggapi perubahan kebutuhan pelanggan, bahkan terlambat dalam siklus kehidupan.
Extreme Programming menekankan kerja tim. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming mengimplementasikan sederhana, namun lingkungan yang efektif memungkinkan tim untuk menjadi sangat produktif. Tim mengorganisir diri di sekitar pemecahan masalah itu seefisien mungkin. Jika saya hanya bisa menggunakan kata-kata lusin untuk menggambarkan Extreme Programming Aku akan menggunakan ini: Jujur perencanaan, proyek detak jantung, intens umpan, tanpa ampun penyederhanaan, dan tim pemberdayaan.
Extreme Programming meningkatkan suatu proyek perangkat lunak dalam empat cara penting; komunikasi, kesederhanaan, umpan balik, dan keberanian. Pemrogram ekstrim terus-menerus berkomunikasi dengan pelanggan mereka dan sesama programer. Desain Mereka tetap sederhana dan

Seperti puzzle-nya teka-teki
bersih. Mereka mendapatkan umpan balik dengan menguji perangkat lunak mereka dimulai pada hari pertama. Sistem yang mereka berikan kepada pelanggan sedini mungkin dan menerapkan perubahan seperti yang disarankan. Dengan Extreme Programmer yayasan ini mampu menanggapi perubahan berani persyaratan dan teknologi.
Extreme Programming adalah banyak seperti teka-teki puzzle-nya. Ada banyak potongan-potongan kecil. Individual potongan tidak masuk akal, tapi ketika digabungkan bersama-sama gambaran yang lengkap dapat dilihat. Alur menunjukkan bagaimana aturan Extreme Programming bekerja sama. Kegiatan yang tidak produktif telah dipangkas untuk mengurangi biaya dan frustrasi.
Aspek yang paling mengejutkan dari Extreme Programming adalah aturan dan praktek-praktek yang sederhana. Mereka tampak canggung dan bahkan mungkin naif pada awalnya, tetapi segera menjadi menyambut perubahan. Pelanggan menikmati menjadi mitra dalam proses dan pengembang perangkat lunak berkontribusi secara aktif tanpa tingkat pengalaman.
Cari buku dan diskusi-diskusi atau melihat apakah proyek Anda cocok. Ambil tur Extreme Programming dengan mengikuti jejak littleSoftware rotsbuttons, mulai di sini.

The Rules and Practices
of Extreme Programming.

Planning

User Stories User stories are written.
release plan Release planning creates the schedule.
release often Make frequent small releases.
project velocity The Project Velocity is measured.
iterative The project is divided into iterations.
iteration planning Iteration planning starts each iteration.
move people around Move people around.
stand-up meeting A stand-up meeting starts each day.
fix xp Fix XP when it breaks.

Designing

simplicity Simplicity.
System Metaphor Choose a system metaphor.
CRC cards Use CRC cards for design sessions.
Spike solution Create spike solutions to reduce risk.
nothing early No functionality is added early.

refactor Refactor whenever and wherever possible.

Coding

customer on-site The customer is always available.
coding standard Code must be written to agreed standards.
Test Driven Development Code the unit test first.
pair programming All production code is pair programmed.
serial integration Only one pair integrates code at a time.
continuous integration Integrate often.
collective ownership Use collective ownership.
optimize last Leave optimization till last.
steady pace No overtime.

Testing

unit tests All code must have unit tests.
unit tests All code must pass all unit tests before it  can
be released.
tests When a bug is found tests are created.

acceptance tests Acceptance tests are run often and the score
is published.


Internet Gratis Dengan Antena Kaleng!

Jangan buang kaleng di rumah Anda. Daur ulang sebagai antena wireless murah meriah.

Konsep dasar gaya hidup hijau, yakni reuse, refill, dan recycle, juga berlaku di dunia teknologi informasi. Hal ini dibuktikan oleh Muhammad Salahuddien Manggalany atau yang akrab dipangil Didin atau Pataka. Didin mendaur ulang kaleng menjadi antena wireless LAN. Awalnya memang isengiseng sebagai wadah eksperimental, namun kini, bisnis ini telah menjadi lahan baru yang cukup menjanjikan.

Sebenarnya isitilah antena kaleng bukan penyebutan yang benar. Sebab, kaleng dalam keseluruhan antena ini, hanya berfungsi sebagai balancing saja.Didin menganalogikan dengan antena helical pada HT yang sebenarnya hanya balancing, bukan antena.

Didin mulai menekuni bisnis pembuatan antena kaleng sejak tahun 2002. Awalnya, Didin yang melakukan bersama Bino Utomo ini, menggunakan kaleng susu anaknya sebagai bahan eksperimen. Sayang sekali, saat itu spectrum analyzer susah dicari sehingga Didin dan Bino tidak bisa menganalisis performance antena kaleng buatan sendiri.

Mereka hanya menganalisis berdasarkan jarak jangkauan dan stabilitas koneksi saja. Sedangkan signaling tidak bisa dianalisis tanpa tool. Jadi, saat itu tidak diperoleh data kebocoran sinyal, adanya spletter ke frekuensi lain, dan lain sebagainya.

Lambat laun, Didin mulai menganalisis sendiri berdasarkan trial and error. Dan berhasil menemukan beberapa titik kritis dalam pembuatan antena kaleng. Misalnya, antena kaleng itu umumnya punya sudut pancaran (beamwidth) 15 derajat. Hal ini diketahui dengan membandingkan sudut pancaran signal antena jadi.

Didin juga memanfaatkan secara maksimal panduan-panduan mengenai antena wireless yang ada di Internet.Tak jarang Didin mencari orang yang dianggap pakar untuk diajak berdiskusi.

Dari hasil trial and error, diskusi, mencoba lagi, eksperimen, dan panduan di Internet, Didin akhirnya menemukan cara optimal merakit antena kaleng.

Cara-cara optimal tersebut meliputi perhitungan ideal, teknis pemasangan, hingga mekanisme pointing yang benar. Hasilnya, antena kaleng buatan Didin berani diadu dengan antena wireless orisinal.

Saat sudah menemukan teknik ideal perakitan antena kaleng, terjadi hal yang menguntungkan di dunia Internet Indonesia. Yakni tren layanan baru Internet Service Provider (ISP) yang menyediakan aplikasi wireless mulai marak. Di samping itu, banyak ISP yang mengubah topologinya dengan misi mendekatkan diri ke konsumen. Yakni konfigurasi dan topologi jaringan wireless LAN outdoor low range dengan maximum density.

“Maksudnya,” lanjut Didin, “ISP mendirikan Base Transmission Station (BTS) baru di sekitar konsentrasi kliennya, dengan jangkauan rendah (sekitar 1-2 km) untuk menjangkau pelanggan yang terkonsentrasi di daerah tersebut.”

Teknik Pemasangan
Pembuatan antena kaleng sendiri melalui beberapa tahap. Tahap pertama adalah pembuatan antena kaleng itu sendiri. Dilanjutkan dengan pemasangan dan pointing. Panduan langkah demi langkah pembuatan antena kaleng kami sertakan dalam boks khusus di akhir artikel ini. Panduan tersebut dibuat khusus untuk PC Media. Dan diperagakan oleh dua orang staf Didin, yakni Andi Fauzi Firdaus dan Erwan Noor.

Ada beberapa hal yang perlu dipahami sebelum melakukan instalasi. Yakni, gunakan perhitungan Link Budget Calculator dari http://www.satsig.net/link-budget.htm. Dan untuk kalkulasi site survey menggunakan situs http://www.cplus.org/rmw/english1.html.

Setelah terpasang dan sudah di-pointing, bandingkan gain antena wave guide dengan antena existing link yang sudah ada. Pasang antena di tower atau pipa kemudian lakukan pointing sampai maksimal dan siap digunakan.

Jangan lupa, perhatikan cuaca untuk keselamatan antena dan radio. Jangan pernah melakukan pointing saat mendung, apalagi hujan. Baik di lokasi pemasangan atau di ISP yang hendak dituju. Bagaimanapun, antena wave LAN, baik kaleng atau orisinal, masih sensitif terhadap cuaca.

Beragam Bentuk Berbeda Cara
Ada perangkat radio yang sudah memiliki mini HUB di dalamnya. Seperti produk Iconnect. Namun, ada juga yang masih konektornya UTP biasa, seperti produk Compex, Senao, Planet, dan lain sebagainya.

Untuk perangkat radio yang sudah memiliki mini HUB atau mini router atau NAT gateway, bisa langsung dipasang ke komputer pengguna, tanpa melewati router lagi. Namun, jika model perangkat radio yang dipasang masih tipe bridging biasa, dibutuhkan router. Terutama jika koneksi hendak di-share ke beberapa klien.

Namun jika hanya untuk satu single user, bisa langsung dipasang melalui ethernet card. Menurut Didin, ISP di Indonesia umumnya memilih produk yang sudah memiliki router atau NAT gateway. Sebab, selain lebih mudah pengaturan atau setting-nya, juga topologinya lebih fleksibel.

Setelah siap dipasang, tinggal pointing untuk mencapai sinyal dari ISP. Menurut Didin, antena yang sudah dirakit dengan cara seperti ini bisa menjangkau 1 hingga 2 km.

Untung Wafer
Sayangnya, Didin yang juga menjadi Dewan Presidium IndoWLI (komunitas pegiat wireless Indonesia) ini belum tertarik menjadikan bisnis antena kaleng sebagai usaha dalam skala besar. Dengan entengnya, Didin mengaku bahwa sering kali dia mengerjakan antena kaleng hanya memperoleh keuntungan berupa wafer yang dimakan karena kalengnya hendak digunakan sebagai bahan utama antena.

Naluri bisnis Didin yang rendah, muncul karena alasan idealis. Menurut Didin, “Membuat antena kaleng itu dasarnya cuma eksperimen dan hobi. Selain mengajak orang supaya jadi pintar.” Didin, khususnya dalam penyediaan jasa pembuatan antena kaleng, sebenarnya hanya melayani kalangan pengguna yang suka eksperimen, bukan komersial murni. Dan ongkos pengerjaan pun disebutnya sebagai “biaya kemalasan” orang yang tidak mau eksperimen sendiri atau masih takut mengambil risiko peralatan radio.

Sering kali orang datang ke Didin membawa material sendiri. Di tempat Didin, mereka meminjam peralatan yang relatif lengkap dan meminta supervisi saja. Jangankan menerima ongkos, Didin malah lebih sering harus menyediakan suguhan kepada para tamu yang seperti ini. Namun dia tidak keberatan. Sebab, klien tipe seperti ini kebanyakan adalah mahasiswa dan teman-teman sendiri.

Ke depannya, Didin tidak berharap banyak dari bisnis yang semestinya sangat prospektif ini. Pria yang masih menjalani kuliah di Pascasarjana Universitas Muhammadiyah Malang ini, hanya berharap semakin banyak orang mencoba dan berani menggunakan antena buatan sendiri. Secara bisnis, Didin masih banyak menerima pendapatan dari penjualan antena orisinal. Apalagi perusahaan Lintas Langit yang dikelolanya juga menjadi reseller beberapa produk antena impor. Baik dari Eropa, Cina, ataupun Taiwan. Namun, nama Didin lebih dikenal sebagai perakit antena kaleng daripada sebagai reseller
antena impor.

Didin juga melayani banyak permintaan pesanan dari luar kota, bahkan luar pulau. Saat diwawancarai, Didin tengah membuat beberapa antena kaleng pesanan dari pengguna di Pontianak dan Pekan Baru.

Bahkan di Malang, banyak warung Internet menggunakan antena kaleng buatan Didin untuk menghemat investasi perangkat. Warung Internet menggunakan antena kaleng untuk berhubungan dengan ISP, atau menghubungkan beberapa warung Internet dalam satu grup. Hampir semua ISP, memang tidak keberatan jika klien menggunakan antena kaleng. Sebab, yang terpenting adalah koneksinya, bukan fisiknya.

Namanya juga perakit antena, untuk suvenir sahabat pun Didin memberi sebuah antena kaleng buatannya sendiri. Berbeda dengan antena lain yang dibuat apa adanya, antena khusus hadiah ini diberi banyak polesan. Misalnya dilapisi antikarat, diberi tutup yang cantik, dan dudukan antena yang bagus. Tidak kalah kemasannya dengan antena biasa.

Jadi sekarang ada dua pilihan bagi kita. Membisniskan antena kaleng, atau menjadi penggunanya. Yang jelas, kita tahu sekarang, mengapa begitu banyak kaleng susu dan wafer di atas rumah tetangga.

CARA PEMBUATAN ANTENA KALENG

1. Pertama, siapkan peralatan dan bahan-bahan. Mulai bor, penggaris, hingga kaleng bekas dengan profil dimensi yang sesuai. Dalam contoh yang diperagakan, digunakan kaleng bekas Quaker Outmeal. Kaleng ini setara dengan kaleng susu instan ukuran 400 gr, Twister Stick Snack, atau kaleng buah produk Cina.

Kemudian, kaleng dibersihkan dan diratakan mulutnya agar tidak melukai tangan. Pastikan kaleng sudah bersih dan kering sebelum masuk ke tahap berikutnya. 1

2. Dilanjutkan dengan pengukuran diameter dan tinggi kaleng. Masukkan ukurannya dalam rumus untuk menentukan titik wave guide dan penguatannya. Rumus bisa dilihat di situs pada akhir artikel ini.

Siapkan konektor N Female Panel Mount dan membuat wave guide sesuai hasil kalkulasi dimensi kaleng dan frekuensi yang telah diperoleh sebelumnya dari rumus.

3. Ukur lokasi dari dasar kaleng dan bor titik wave guide. Kemudian buat lubang baut dudukan konektor N Female Panel Mount.

Tahap berikutnya adalah perkabelan. Kupas inner tembaga kabel CNT/LMR-200 yang memiliki nilai resistansi 50 Ohm untuk wave guide. Lanjutkan dengan menyambung kabel inner Wave Guide ke konektor N Female Panel Mount.

Panjang kabel jumper adalah kelipatannya hasil yang diperolehdari rumus: berdasarkan rumus (3 x 108 (rambatan sinyal di udara)/frekuensi dalam khz) x 0,92 (koefisien kabel).

Sedangkan loss akibat kabel dihitung berdasar situs http://www.swisswireless.org/wlan_calc_en.html.

4. Pasang wave guide yang sudah tersolder di ke lubang di kaleng. Eratkan baut konektor ke kaleng. Jangan lupa untuk segera menutup dengan rubber silicon sebagai pelindung dari kebocoran air dan mencegah terjadinya karat pada konektor.

Bor dasar kaleng untuk memasang clamp mounting ke tower atau dudukan antena. Solusi lain, bisa juga menggunakan besi plat untuk stang kaleng. Intinya, kaleng bisa ditempelkan kuat ke tower atau tiang tanpa kesulitan. Tentu saja, wave guide tidak boleh bergeser atau bergerak ke titik yang lain.

5. Potong kabel RG-8 9913/CNT/LMR-400 yang memiliki nilai resistansi 50 Ohm untuk jumper dengan panjang kelipatan 11,5 cm. Perhatikan situs referensi untuk melihat rumus perhitungan cable balancing.

Pasangkan konektor N Male atau N Female ke jumper. Lalu lindungi sambungan konektor dengan rubber silicon.

Setelah terpasang kuat, baru masuk tahap finishing, yakni pemasangan tutup depan kaleng. Tutup depan ini perlu diperhatikan bahannya, tidak dari bahan metal. Jadi bisa plastik atau PVC. Kemudian semua celah diberi silicon gel, untuk penahan air. Lalu dimulailah pengecatan bodi kaleng sesuai selera.

6. Setelah terangkai semua dengan kuat dan enak dilihat, maka antena kaleng siap dipasang. Ada dua cara pemasangan antena kaleng ini. Keduanya tidak jauh berbeda dengan pemasangan antena wave LAN biasa. Kedua cara ini tergantung pada jenis perangkat radio yang digunakan.

Ada perangkat yang langsung ke komputer, ada juga yang membutuhkan router. Setelah terpasang, uji coba antena dengan teknik War Driving. Teknik ini menggunakan software Site Survey seperti Netstumbler.

Tips Menjaga Kesehatan Mata Saat Bekerja Di Depan Monitor

Komputer dan berbagai perlengkapannya, seperti monitor, sudah menjadi barang awam dalam setiap pekerjaan kantor. Bukan hal yang asing jika banyak orang harus bekerja di depan monitor sepanjang hari. Pada awalnya kita mungkin sedikit khawatir mengenai pengaruh komputer dan sinar radiasi yang dipancarkan monitor dapat mengganggu kesehatan tubuh, terutama mata. Namun, para ahli pun tak pernah menyerah untuk menciptakan peralatan yang semakinramah dengan lingkungan dan kesehatan.
Meski begitu, bekerja terlalu lama di depan layar monitor tetap saja dapat mempengaruhi kesehatan, seperti mata lelah, nyeri punggung, bahu dan leher. Berikut beberapa tips mengatasi kelelahan dan ketegangan mata di saat bekerja di depan monitor. Mudah-mudahan kita bisa menjaga karunia mata yangtetap, meski harus beke

rja berjam-jam.

1–Bekerjalah dalam ruangan yang cukup cahaya.

Perhatikan pencahayaan dalam ruang kerja anda. Jangan bekerja dalam ruangan yang terlalu terang dan menyilaukan mata. Gunakan kerai untuk mengatur cahaya dari jendela. Letakkan lampu di atas kepala. Hindari anda menatap cahayanya secara langsung. Sebaliknya, jangan pula bekerja dalam ruangan yang terlalu gelap atau redup. Usahakan agar ruangan anda cukup terang agarmata anda tidak bekerja terllau keras.

2–Gunakan filter monitor.

Untuk mengurangi sinar yang menyilaukan dan radiasi yang dipancarkan layar monitor, gunakan filter glass monitor. Berbicaralah pada vendor perlengkapan komputer anda untuk mendapatkan filter yang baik dan mampu mengurangipengaruh radiasi, bukan hanya sekedar meredupkan cahaya monitor.

3–Periksa monitor anda.

Periksa apakah monitor anda masih bekerja dengan baik? Bandingkan dengan monitor lain. Bila gambar yang tampak semakin buram, berkedip-kedip atau tidak nyaman bagi mata anda, maka sudah waktunya untuk memperbaiki atau mengganti monitor itu. Lebih baik mengganti monitor daripada membiarkan mata anda terganggu. Sering-seringlah membersihkan monitor dari debu dan kotoranyang mengganggu layar.

4–Letakkan kertas kerja agar mudah dibaca.

Jika anda harus bekerja dengan menyalin atau membaca kertas kerja, maka letakkan kertas kerja tersebut dalam jarak yang seimbang dengan monitor anda. Ini agar anda tidak perlu bolak-balik memfokuskan pandangan untuk membaca kertas kerja anda, setelah membaca di layar monitor.

5–Perhatikan posisi monitor.

Letakkan layar monitor sedemikian rupa sehingga membentuk sudut antara 10-15 derajat dari posisi sejajar dengan pandangan lurus anda. Hal ini selain agar tidak melelahkan mata anda, juga menjaga agar bahu dan leher anda cukupnyaman bekerja.

5–Bekerjalah dengan “font” yang cukup besar.

Bila anda harus mengedit tulisan di depan komputer, pastikan ukuran atau “font” hurup yang anda gunakan cukup besar. Jangan paksa mata anda untuk membaca hurup kecil pada monitor. Mata anda bukanlah mikroskop bagi tulisan yang ada di layar monitor. Gunakan fasilitas untuk memperbesar atau menyesuaikan besar tampilan gambar di monitor anda. Bila anda telah selesai mengedit atau membacanya, anda bisa kembalikan font tersebut ke posisisemula.

6–Istirahatkan mata anda.

Relakskan mata anda. Pejamkan atau kerjap-kerjapkan. Jangan kucek-kucek mata anda. Namun, sering-seringlah berkedip. Ini dapat menurunkan ketegangan dan menjaga mata anda tetap basah dan sejuk. Bila anda terlalu lama melihat dalam jarak dekat, alihkan pandangan anda ke arah yang jauh. Lakukan iniselama beberapa menit setiap 30 menit.

7–Periksa kacamata atau lensa kontak.

Bila anda menggunakan kacamata atau lensa kontak dan anda harus bekerja sepanjang hari di depan monitor, ada baiknya anda konsultasikan dengan dokter mata atau optik anda agar anda bisa mendapatkan kacamata yang sesuai. Baik, ukuran lensa dan framenya. Bila anda merasa lelah menggunakan kacamata, tanggalkan saja. Kacamata bisa membuat mata lelah. Sesekali
biarkan mata anda melihat bebas. Namun, segera kenakan kacamata anda bila merasa harus mengenakannya. Jangan paksa mata anda melihat tanpa bantuan kacamata anda.

Rich Internet application

Aplikasi Internet yang kaya (RIA) adalah aplikasi web yang memiliki sebagian besar karakteristik aplikasi desktop, biasanya disampaikan melalui browser web berbasis standar plug-in atau secara independen melalui kotak pasir atau mesin virtual. [1] Contoh mencakup kerangka RIA Curl, Adobe Flash / Adobe Flex / AIR, Jawa / JavaFX, [2] uniPaaS [3] dan Microsoft Silverlight. [4]

Istilah ini diperkenalkan Maret 2002 oleh vendor seperti Macromedia yang mengatasi keterbatasan pada waktu dalam “kekayaan aplikasi interface, media dan konten, dan keseluruhan kecanggihan dari solusi” dengan memperkenalkan kepemilikan ekstensi. [5] [meragukan -- membahas] Seperti standar web (seperti HTML 5) telah mengembangkan dan web browser ‘kepatuhan telah membaik masih memerlukan ekstensi seperti itu, ketika perusahaan ingin membawa yang benar-benar high-end tanpa cacat pengalaman pengguna mereka. Javascript compiler dengan desktop yang terkait seperti widget set mengurangi kebutuhan ekstensi browser lebih jauh. HTML 5 memberikan sebuah pseudo-platform aplikasi.

Hal ini masih tidak mungkin untuk membangun RIA-seperti aplikasi Web yang berjalan di semua browser modern tanpa perlu menjalankan khusus-kali atau plug-in. Ini berarti bahwa jika seseorang bisa menjalankan Ajax modern berbasis aplikasi Web di luar sebuah web browser (misalnya menggunakan Mozilla Prism atau fluida) pada dasarnya akan menjadi sebuah RIA, [1] meskipun ada beberapa pendapat mengenai apakah ini sebenarnya adalah kasus . [6]

Deployment

Dengan beberapa tapi semakin banyak pengecualian (khususnya YouTube yang saat ini bergantung pada Adobe Flash untuk pemutaran video) sebagian besar dari situs web yang paling populer adalah aplikasi web asli. Meskipun demikian, setiap situs besar memanfaatkan kerangka RIA seperti JavaScript / JavaFX dan Adobe Flash. Dengan Adobe Flash Player memiliki 98% atau lebih penetrasi pasar di pasar matang, [7] itu sebenarnya lebih banyak tersedia daripada salah satu dari browser web yang ada. Adobe Flash berjalan pada platform lebih banyak dan lebih banyak perangkat dan dapat dijalankan di luar lingkungan browser web, sehingga membuatnya menjadi saat yang paling umum milik web standar dan secara luas penyebaran pra-instal lingkungan untuk Rich Internet Applications. Online game adalah salah satu daerah di mana RIA yang lazim. Aplikasi (seperti Dimdim) yang membutuhkan akses ke video capture juga cenderung untuk menggunakan RIA (dengan pengecualian dari Gmail yang menggunakan tugas sendiri-browser tertentu plug-in [8]).

Karakteristik

* Aksesibilitas Adobe Flash adalah sebuah kerangka RIA yang secara universal dapat dicari. [9]
* Advanced komunikasi dengan server yang mendukung dapat meningkatkan pengalaman pengguna, misalnya dengan menggunakan protokol jaringan dioptimalkan, asynchronous I / O dan pra-mengambil [disambiguasi diperlukan] data (misalnya Google Maps). Oleh karena itu, dapat diandalkan koneksi broadband sering diharuskan.
* Kompleksitas solusi canggih dapat membuat mereka lebih sulit untuk merancang, mengembangkan, menyebarkan dan debug dari aplikasi web tradisional (tapi biasanya kurang begitu daripada perangkat lunak aplikasi).
* Konsistensi pengalaman user interface dan dapat dikendalikan di sistem operasi. Kinerja pemantauan dan diagnosis kesalahan dapat sangat sulit.
* Instalasi dan Pemeliharaan dari plug-in, kotak pasir atau mesin virtual yang dibutuhkan (tetapi aplikasi lebih kecil daripada para pendahulu mereka dan pembaruan biasanya otomatis). Instalasi biasanya lebih cepat daripada perangkat lunak aplikasi tetapi lebih lambat dibandingkan dengan aplikasi web asli dan otomatisasi tidak mungkin dilakukan.
* Offline penggunaan dapat didukung oleh negara mempertahankan klien secara lokal pada komputer, tapi perkembangan di web standar (prototyped di Google Gears) juga telah memungkinkan hal ini untuk aplikasi web asli.
* Keamanan dapat meningkatkan atas bahwa aplikasi perangkat lunak (misalnya melalui penggunaan kotak pasir dan automatic update) tapi ekstensinya sendiri tunduk pada kerentanan dan akses mungkin sering jauh lebih besar daripada aplikasi web asli. [10]
* Kinerja dapat meningkatkan tergantung pada aplikasi dan karakteristik jaringan. Secara khusus, aplikasi yang dapat menghindari latency [disambiguasi diperlukan] bulat-perjalanan ke server dengan pengolahan secara lokal pada klien sering jauh lebih cepat. Pembongkaran bekerja untuk klien juga dapat meningkatkan kinerja server. Sebaliknya kebutuhan sumber daya dapat menjadi penghalang bagi kecil, tertanam dan perangkat mobile.
* Kekayaan melalui fitur tidak didukung secara native oleh browser web seperti video capture (mis. Adobe Flash).
* Standar Flash merevolusi pengiriman konten video di web, stalwarts sebagai dethroning seperti Media Player dan Quicktime.

Kerangka

Lihat juga kategori: Kaya aplikasi Internet kerangka

Yang sesuai kerangka aplikasi Rich Internet biasanya diperlukan untuk menjalankan sebuah RIA, dan harus diinstal menggunakan sistem operasi komputer sebelum meluncurkan aplikasi. Kerangka kerja perangkat lunak biasanya bertanggung jawab untuk men-download, update, memverifikasi dan melaksanakan RIA. [11]

Kaya Klien Internet

Rich Internet Klien (Ric) adalah aplikasi-aplikasi client yang kaya instal dari dan berjalan dengan baik melalui Internet. Mereka menggabungkan pengalaman pengguna yang kaya klasik klien kaya dengan jangkauan (kemampuan untuk menjalankan dari komputer manapun, di mana saja) dari web klien, sementara mengatasi banyak kerugian dari kedua teknologi.

Klien-klien kaya tradisional sering membutuhkan Virtual Private Network, Citrix hosting beberapa atau lain infrastruktur tersebut akan aman diakses di luar perusahaan intranet lokal. Tradisional juga klien-klien kaya biasanya perlu ditingkatkan secara manual oleh pengguna akhir. Internet kaya Klien tidak dibatasi oleh keterbatasan ini, dan dengan demikian mampu mengambil banyak peran tradisional disediakan untuk aplikasi web.

Sebuah Rich Internet Klien biasanya ditandai dengan fitur berikut:

* Web-Based Deployment dan Instalasi
* Kemampuan untuk menjalankan secara aman melalui internet terbuka tanpa memerlukan infrastruktur
* Kemampuan untuk dijalankan pada beberapa sistem operasi (Setidaknya Windows, Macintosh & Linux)
* Fully upgrade perangkat lunak otomatis.

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

Ikuti

Get every new post delivered to your Inbox.