Bangun satu untuk dibuang vs. Efek sistem kedua

Di satu sisi ada saran yang mengatakan "Bangun satu untuk dibuang". Hanya setelah menyelesaikan sistem perangkat lunak dan melihat produk akhirnya kami menyadari apa yang salah pada fase desain dan memahami bagaimana kami seharusnya benar-benar melakukannya.

Di sisi lain ada "efek sistem kedua" yang mengatakan bahwa sistem kedua dari jenis yang sama yang dirancang biasanya lebih buruk daripada yang pertama; ada banyak fitur yang tidak sesuai dengan proyek pertama dan didorong ke versi kedua biasanya mengarah ke terlalu rumit dan terlalu direkayasa.

Bukankah di sini ada kontradiksi antara prinsip-prinsip ini? Apa pandangan yang benar atas masalah dan di mana perbatasan antara keduanya?

Saya percaya bahwa "praktik baik" ini pertama kali dipromosikan dalam buku mani The Mythical Man-Month oleh Fred Brooks.

Saya tahu bahwa beberapa masalah ini diselesaikan dengan metodologi Agile, tetapi jauh di lubuk hati, masalahnya masih tetap prinsip; misalnya kita tidak akan membuat perubahan desain penting 3 sprint sebelum ditayangkan.

Membangun satu untuk dibuang berasal dari "tidak tahu apa yang tidak Anda ketahui" pada awalnya, jadi Anda belajar saat Anda melakukan apa yang seharusnya Anda lakukan di awal.

Efek Sistem Kedua berasal dari "sekarang tahu apa yang Anda tidak tahu, namun tidak tahu apa yang Anda masih belum tahu" yaitu efek sistem Kedua berasal dari mencoba membangun sistem yang lebih besar, lebih bersinar, lebih kompleks daripada yang pertama, tanpa sepengetahuan diperlukan di awal - terdengar seperti apa yang terjadi dengan sistem pertama.

Karena itu efek sistem kedua bukanlah kontradiksi. Membangun sistem kedua ke fungsi yang sama seperti yang pertama (setahu saya) tidak pernah dilakukan. Sistem kedua selalu harus "lebih baik", karena itu lebih kompleks, oleh karena itu masalah yang mirip dengan sistem pertama diharapkan - yang harus dibuang.

Jadi buat satu untuk dibuang, buang dengan cara itu dan bangun lagi tanpa pembesaran ruang lingkup, dan Anda tidak akan memiliki masalah sistem kedua. (Ini cenderung dilakukan lebih sering di planet dengan langit ungu, laut merah muda, dan babi terbang.)

Masalah yang Anda maksudkan berarti beberapa hal dilewati, maka sistem yang dihasilkan salah. Izinkan saya menjelaskan beberapa langkah yang hilang:

Manajemen Kualitas - Lakukan dengan benar pertama kali! Jangan pernah gunakan peretasan sementara, atau kompromi sementara. Tidak akan ada pengerjaan ulang yang dibutuhkan. Semua sumber daya digunakan secara efisien dan semua yang Anda lakukan adalah kontribusi yang tepat untuk proyek.

Analisis Kelayakan - Temukan kebutuhan bisnis. Buat kasus bisnis untuk proyek tersebut.

Rencana Proyek - Jelas mendefinisikan ruang lingkup awal Anda, rencanakan bagaimana solusi akan disampaikan, buat garis dasar, patuhi rencana tersebut. Jangan habiskan waktu untuk apa pun yang tidak berada di jalur kritis.

Rekayasa Persyaratan - Menuntut persyaratan bisnis (mis. Menangkap proses bisnis dan menentukan operasi bisnis apa yang harus didukung oleh sistem yang terkomputerisasi, menerjemahkan operasi bisnis 1: 1 ke kasus penggunaan sistem). Validasi & verifikasi! (Apakah kita membangun hal yang benar? Apakah kita membangunnya dengan benar?) Semua persyaratan harus dikaitkan dengan kebutuhan bisnis semula.

Desain Perangkat Lunak - Terjemahkan kasus penggunaan dan model domain ke dalam desain komponen dan arsitektur solusi. Semua komponen harus ditautkan dengan persyaratan dari RE.

Implementasi - Kode perangkat lunak seperti dalam desain. Semua kode harus ditautkan ke komponen dari SD.

Validasi - Pengujian unit, pengujian integrasi, kinerja, ... (semua kasus penggunaan dari RE sekarang perlu diuji)

Ini adalah beberapa aspek kunci dari proses perangkat lunak. Aktivitas yang disebutkan adalah bagian dari Rekayasa Perangkat Lunak. Ini adalah bagaimana Anda membangun solusi perangkat lunak yang tepat untuk kebutuhan bisnis nyata, dan Anda membangunnya tepat waktu, sesuai anggaran, sesuai spesifikasi.

Cari istilah-istilah ini untuk membangun perangkat lunak yang lebih baik dan untuk melakukannya dengan benar pertama kali

• Analisis Kelayakan (khususnya cara membangun Kasus Bisnis)
• Manajemen Proyek (khususnya Rencana Proyek dan Daftar Risiko dengan Mitigasi Risiko)
• Rekayasa Persyaratan (elisitasi, analisis, spesifikasi, validasi)
• Desain Perangkat Lunak (UML dan rekayasa perangkat lunak berbasis komponen)
• Konstruksi Perangkat Lunak (pola desain, kerangka kerja, pemrograman defensif)
• Validasi Perangkat Lunak (pengujian unit, UAT, dll.)