Apa perbedaan antara prototipe dan solusi tingkat produksi?

Pertanyaan ini murni untuk belajar dan untuk meningkatkan pemahaman teknis saya. Saya tahu tidak ada solusi yang sempurna dan pertanyaan ini memiliki daftar solusi yang mungkin tidak pernah berakhir tetapi saya pikir sangat penting bagi setiap arsitek untuk memahami perbedaan antara demo dan proyek langsung.

Saya membuat banyak solusi demo di .Net di masa lalu. Sekarang saya telah ditugaskan untuk arsitek dan mengimplementasikan solusi web tingkat produksi, jadi saya ingin bertanya - pada tingkat yang sangat tinggi, apa yang diperlukan untuk mengubah demo menjadi solusi tingkat produksi. Dari pemahaman saya, ini akan membutuhkan (selain mengimplementasikan persyaratan klien secara fungsional):

1. Unit menguji setiap metode
2. Memastikan ~ cakupan kode 100% tercapai
3. Mencatat semua pengecualian dan kemungkinan titik potong - mungkin dengan AOP
4. Menggunakan pola desain antarmuka, injeksi ketergantungan, mungkin dengan menggunakan kerangka kerja misalnya spring.net
5. Menggunakan penghitung kinerja dan profiler untuk instrumentasi
6. Menerapkan keamanan yang sesuai - yaitu otentikasi windows (jika itu yang diperlukan oleh klien).
7. Manajemen transaksi pada setiap metode
8. Cadangkan file aplikasi web sebelum penerapan solusi baru

Apa lagi?

Pertanyaan saya lebih terkait dengan sisi teknis daripada fungsional / dokumentasi karena kalau tidak kita akan pergi ke jalur lain :-)

Terima kasih.

Saya pikir perbedaan yang paling penting adalah bahwa tujuan prototipe adalah:
1. Untuk membuktikan bahwa masalah dapat diselesaikan dengan cara tertentu ATAU
2. Memberi kesan klien / manajemen tentang apa yang akan terlihat dan dirasakan oleh produk

sedangkan tujuan dari sistem live adalah:
1. Untuk memecahkan masalah tertentu / mengatasi suatu masalah.

Perhatikan bahwa tujuan keduanya sangat berbeda .
Karena itu, menurut saya prototipe harus dibuang sebelum mengembangkan sistem live .

Ini juga karena prototipe biasanya merupakan proyek 'cepat dan kotor', disatukan tanpa pertimbangan apa pun yang telah Anda tunjukkan dengan benar dalam pertanyaan Anda (seperti pengujian, kinerja, keamanan, dan banyak lagi).
Jadi Anda akan lebih baik memulai proyek baru yang tepat daripada mencoba membuat proyek yang buruk menjadi lebih baik.

Tidak semua hal itu diperlukan, tergantung pada kebutuhan Anda, atau mungkin ada cara yang lebih dibutuhkan. Jika Anda tahu apa yang saya maksud;) Pengujian unit dan cakupan kode adalah hal yang baik, tetapi tergantung pada bagaimana Anda melakukan bagian lain dari proses, mungkin tidak diperlukan. Beberapa orang akan mengatakan bahwa yang lebih penting daripada profil kinerja adalah kode yang terdokumentasi dengan baik, atau manual pelatihan. Bervariasi!

Saya menyadari Anda sedang melihat sisi teknis tetapi mudah-mudahan Anda akan mengerti maksud saya, itu bervariasi tergantung pada sisi non-teknis. Atau setidaknya, seharusnya begitu.

Menggunakan penghitung kinerja dan profiler untuk instrumentasi .. mungkin cocok, tetapi mungkin berlebihan secara besar-besaran. Mungkin tidak diperlukan.

Apa yang Anda lewatkan di sini adalah gagal menjelaskan konteks, ruang lingkup, dan persyaratan bisnis proyek.

Yang saya maksud dengan konteks dan ruang lingkup - apakah Anda menciptakan sesuatu untuk digunakan secara internal oleh bisnis? Menghadapi pelanggan? Digunakan oleh pengguna akhir? Apakah ini sebenarnya Notepad versi jazzy, atau RDBMS baru dari awal? Apa yang harus dimasukkan akan sangat bervariasi (secara besar-besaran!) Oleh proyek yang Anda lihat.

Dengan persyaratan bisnis, saya tidak bermaksud menggunakan kasus untuk perangkat lunak, tetapi persyaratan manajemen proyek / proses produksi. Jika Anda bersikeras bahwa Anda memerlukan semua itu untuk proyek produksi, biayanya akan tercermin (sangat tinggi). Itu bisa berarti sudah melebihi anggaran, terlambat, atau bahkan tidak diberi lampu hijau untuk memulai pembangunan.

Bisa jadi yang lebih penting daripada memiliki seperangkat kriteria tetap sekarang hanya memiliki kerangka kerja produksi / pengembangan yang baik, visibilitas tinggi dan rilis reguler sehingga kualitas dapat dinilai seperti itu. Bisa jadi tidak ada yang terlibat memberikan omong kosong tentang cakupan kode.

Menariknya, saya pikir poin 1, 2, 4 dan 7 sudah harus dilakukan selama konsepsi prototipe Anda, kecuali bahwa saya tidak berpikir Anda harus menguji setiap metode di setiap kelas. Uji kode kritis, bukan apakah metode get / set berperilaku dengan benar.

Tergantung pada tujuan aplikasi Anda, di mana keamanan merupakan masalah besar, poin 6 mungkin cukup kritis sehingga Anda perlu mencapainya dalam prototipe. Tergantung pada tujuan aplikasi Anda, di mana kinerja adalah kuncinya, poin 5 mungkin kritis ... Anda tahu apa yang saya maksud. Pendapat saya adalah bahwa poin 3, 5, dan 6 mungkin diperlukan dalam prototipe jika dianggap kritis (poin 8 benar-benar valid untuk aplikasi produksi)

Sunting: tampaknya pendapat saya sepenuhnya berbeda dari sJhonny karena saya menyiratkan bahwa saya menganggap prototipe sebagai dasar / kerangka / kerangka pengembangan masa depan Anda, jadi bagi saya prototipe tidak boleh dibuang.

Selain apa yang telah disebutkan, dalam proyek produksi Anda memerlukan yang berikut ini (antara lain):

0-Pilih metodologi implementasi

1-Finalisasi dan publikasikan persyaratan utama (termasuk kasus penggunaan, dll.)

2-Dapatkan arsitektur yang benar

3-Pilih alat yang benar

Database 4-Desain untuk kinerja

5-Produce desain kelas Anda dan desain alur kerja

6-Tentukan dan terapkan strategi untuk mengintegrasikan basis data / sumber data / umpan yang didukung

7-Tentukan dan Terapkan persyaratan keamanan

8-Atur untuk implementasi fisik (Server, konektivitas, lisensi dll.)

9-Plan untuk persyaratan penyimpanan dan menentukan ukuran kinerja

10-Hasilkan semua artefak dan pasang di lingkungan produksi

11-Test

12-Memberikan solusi akhir dan mengimplementasikan umpan balik

Fitur paling penting dari solusi kualitas produksi adalah - menurut saya - ketahanan .

Terlepas dari apa yang terjadi, solusinya menangani situasi dengan bijaksana, memberi tahu mereka yang perlu tahu, dan terus berjalan (jika kesalahan dapat dipulihkan).

Ada dua jenis prototipe:

• Aplikasi "bukti konsep" yang cepat dan kotor yang "dibersihkan" dan menjadi kode produksi. Tahap "pembersihan" cenderung menjadi mimpi buruk, atau itu benar-benar tahap "menyapu masalah di bawah permadani", menghasilkan utang teknis yang besar.

• Prototipe "Mockup" atau "gambar rangka". Ini bisa berupa sketsa UI kertas dan pensil, atau bahkan mockup interaktif yang dilakukan dalam bahasa di mana Anda dapat dengan cepat membuang hal-hal semacam ini bersama-sama tanpa banyak pemikiran di balik bagaimana hal itu cocok bersama. Seharusnya menggunakan data palsu, tidak ada arsitektur nyata, dll. Intinya adalah bahwa mereka memberi para pemangku kepentingan gagasan tentang seperti apa sistemnya, sehingga Anda dapat memperbaiki persyaratan Anda, tetapi mereka TIDAK BISA digunakan sebagai bagian dari solusi akhir Anda .

Saya lebih suka jenis kedua. Mereka diusir, karena sebenarnya tidak ada pilihan.

Saya katakan membangunnya seperti proyek tanpa demo, tetapi sekarang Anda dapat memasukkan apa yang telah Anda pelajari dari demo dalam desain Anda. Pengkodean awal dapat menjadi buruk bahkan setelah Anda memulai produksi. Anda harus memperbaiki sebagian besar dari itu.

Masalah sebenarnya yang harus diatasi adalah batasan waktu Anda. Ketika pembuat keputusan ingin Anda terus mengerjakan demo, mereka mendapat kesan bahwa sebagian besar aplikasi sudah siap, jadi itu tidak akan lama. Saya pernah mendengar orang lain menggunakan logika ini tentang mengapa mereka lebih suka menunjukkan sketsa kepada klien daripada mockup yang terlalu realistis. Perhatikan kode demo karena mungkin telah menemukan masalah yang tidak pernah Anda pikirkan dan mungkin tidak mendokumentasikan dalam proses ini. Anda sekarang harus mempertimbangkannya (Terlalu disederhanakan, tapi ya, database mungkin tidak dapat diakses misalnya.).

Semua prototipe dan demo tidak dibuat sama. Seluruh kode bisa jadi tidak berharga atau bagian-bagian tertentu mungkin telah dilakukan dengan sangat baik. Tidak masalah apakah itu demo, Anda harus tahu bedanya. Anda tidak akan hanya membuang aplikasi legacay dan memulai lagi bukan? Lupakan aku bertanya.