Apa contoh yang bagus dari ide atau teknik pengembangan perangkat lunak yang gagal?

Khususnya apa saja contoh dari mana ide-ide massa di mana salah. Mengapa orang mengaitkan ide-ide itu? Dan mengapa gagasan itu dibubarkan? Atau mungkin idenya masih hidup dan baik dan jika demikian mengapa?

Sebagai contoh saya mungkin menggambarkan CORBA (dan teknologi serupa lainnya) sebagai sesuatu yang berusaha memecahkan masalah komunikasi antara komponen perangkat lunak. Banyak yang merasa perlu mendefinisikan kontrak antara berbagai komponen. Pada akhirnya, HTTP + JSON memecahkan masalah bagi massa dan berbagai mekanisme RPC lainnya seperti Thrift dan Proto-bufs telah muncul.

Pada dasarnya, sama seperti di dunia di luar komputer, ide dan teknologi bersaing untuk mendapatkan perhatian, pengungkitan, dll. Sebagian menang, sebagian kalah; dan beberapa mungkin tampaknya menjadi Pemenang untuk beberapa waktu, kemudian menghilang menjadi kabur dengan munculnya The Next Big Thing. Mungkin ada atau tidak ada hubungannya dengan yang sebenarnya lebih baik. Saksikan VHS vs Betamax, atau perang yang lebih baru antara berbagai format DVD.

CORBA sangat besar, canggung dan sulit digunakan, tetapi itu adalah yang terbaik yang dapat ditemukan beberapa orang pada saat itu (perhatikan bahwa itu dirancang sebelum World Wide Web - dan HTTP, Java, XML, ... - menjadi dikenal luas). Dan itu juga merupakan contoh klasik desain oleh panitia , di mana mereka menjejalkan dalam setiap ide untuk memuaskan semua orang, pada akhirnya membuatnya membengkak sia-sia (setidaknya dilihat oleh mata hari ini). Belum lagi harganya, yang dengan munculnya FOSS segera menjadi penghalang.

Pada akhirnya, HTTP + JSON memecahkan masalah bagi massa

Setidaknya untuk seseorang yang belum melihat beberapa "solusi akhir" yang serupa naik dan akhirnya jatuh ... Adalah baik untuk diingat bahwa ada sentimen serupa tentang CORBA pada masanya ;-)

Saya merasa pantas mengutip dari The Rise and Fall of CORBA :

Sejarah CORBA adalah salah satu yang industri komputasi telah lihat berkali-kali, dan sepertinya upaya middleware saat ini, khususnya layanan Web, akan menampilkan kembali sejarah yang sama. [...]

Secara keseluruhan, proses adopsi teknologi OMG harus dilihat sebagai alasan utama penurunan CORBA. Proses mendorong desain oleh komite dan manuver politik ke titik di mana sulit untuk mencapai mediokritas teknis, apalagi keunggulan teknis. Selain itu, penambahan fitur terputus-putus mengarah ke erosi bertahap dari visi arsitektur. [...]

Proses demokratis seperti OMG tidak cocok untuk membuat perangkat lunak yang baik. Meskipun ada masalah prosedural yang diketahui, industri ini lebih suka mengandalkan konsorsium besar untuk menghasilkan teknologi. Layanan web, peluru perak middleware saat ini, menggunakan proses seperti OMG dan, oleh banyak akun, juga menderita pertikaian, fragmentasi, kurangnya koherensi arsitektur, desain oleh komite, dan fitur mengasapi. Tampaknya tidak terhindarkan bahwa layanan Web akan membuat sejarah yang sangat mirip dengan CORBA.

Sekarang dari sudut pandang yang berbeda: setelah membaca istilah "ide massa" Anda, saya memikirkan hal-hal yang sangat berbeda dari CORBA atau standar lain; ini biasanya ide satu orang atau kelompok kecil. Saya berpikir tentang praktik / poin pandangan terkenal seperti "koboi pengkodean", "kode dan berdoa", "itu bekerja pada mesin saya" dll pengembang secara naluriah mulai menulis kode. Dan mereka salah, karena mereka tidak skala baik dalam ruang maupun waktu - orang tidak dapat membuat program besar, dikelola, dapat diperpanjang dengan cara ini. Namun saya merasa sayangnya itu masih merupakan norma dan bukan pengecualian bagi orang untuk mencoba bekerja dengan cara ini di toko-toko profesional di seluruh dunia.

Ekstrem lain dari ini adalah ide-ide banyak manajer dan teori tentang "pendekatan yang tepat" untuk pengembangan SW, bermanifestasi dalam Metodologi besar-M seperti CMM, RUP, Air Terjun dll. Gagasan di balik semua ini adalah bahwa semua yang Anda butuhkan adalah Proses yang Tepat, dan akan mulai secara otomatis menghasilkan perangkat lunak berkualitas dengan cara deterministik, terlepas dari siapa sebenarnya pengembangnya. Perhatikan bahwa permainan yang sama dapat dimainkan menggunakan metode Agile juga - itu hanya perubahan label. Setiap manajer yang percaya bahwa memilih (dan menjaga) anggota yang tepat untuk tim pengembangannya kurang penting daripada proses pengembangan, pasti akan gagal, yang mana pun proses itu terjadi. Namun, kepercayaan pada Proses ini tampaknya masih lazim - mungkin masih diajarkan di sekolah manajemen?

Contoh yang sering terjadi tentang kesalahan orang adalah model air terjun. Ini adalah diagram dari model air terjun stereotip, yang juga muncul dalam makalah Winston Royce "Mengelola Pengembangan Sistem Perangkat Lunak Besar" .

Gambar ini diikuti oleh teks ini:

Saya percaya pada konsep ini, tetapi implementasi yang dijelaskan di atas berisiko dan mengundang kegagalan ... Fase pengujian yang terjadi pada akhir siklus pengembangan adalah peristiwa pertama yang waktu, penyimpanan, input / output, transfer, dll., adalah pengalaman yang dibedakan dari yang dianalisis. Fenomena ini tidak dapat dianalisis dengan tepat. Mereka bukan solusi untuk persamaan diferensial parsial standar fisika matematika misalnya. Namun jika fenomena ini gagal memenuhi berbagai kendala eksternal, maka diperlukan desain ulang besar. Patch oktal sederhana atau mengulang beberapa kode yang terisolasi tidak akan memperbaiki kesulitan semacam ini. Perubahan desain yang disyaratkan cenderung sangat mengganggu sehingga persyaratan perangkat lunak yang menjadi dasar desain dan yang memberikan alasan untuk semuanya dilanggar. Entah persyaratan harus diubah, atau perubahan besar dalam desain diperlukan. Akibatnya proses pengembangan telah kembali ke asal dan seseorang dapat mengharapkan hingga 100 persen kelebihan jadwal dan / atau biaya.

Kemudian dalam makalah, Royce menyajikan model proses alternatif yang melibatkan iterasi antara fase saat ini dan fase sebelumnya dan siklus antara persyaratan-analisis-desain dan siklus lain antara desain-kode-tes. Dia juga mengidentifikasi sejumlah dokumen dan selama fase mana mereka harus diselesaikan, dan menganjurkan keterlibatan pelanggan dan beberapa air terjun dalam setiap fase untuk memasukkan analisis, pengujian, dan penggunaan semua artefak yang terlibat. Dalam semua aktualitas, apa yang dibahas Royce mungkin dianggap sebagai pendekatan awal untuk metode gesit - meskipun masih sangat banyak didorong oleh rencana, tetapi merupakan dasar untuk gerakan gesit.

Mengapa orang menempel pada air terjun pertama, saya tidak tahu. Saya kira mereka suka mengambil risiko dan mengundang kegagalan.

Pembuatan kode secara otomatis dari level abstraksi yang lebih tinggi, atau pemrograman otomatis .

Artikel Wikipedia agak kurang dalam informasi historis, tetapi ini telah menjadi impian manajer sejak programmer menjadi lebih mahal daripada komputer.

Setelah pengembangan bahasa tingkat tinggi seperti Fortran dan Cobol, muncullah pengembangan bahasa untuk domain khusus seperti penulisan laporan. Easytrieve dan SAS adalah beberapa contoh.

Selama tahun 1980-an, alat CASE sangat populer. CASE adalah singkatan dari rekayasa perangkat lunak berbantuan komputer. Diperkirakan bahwa penerapan prinsip-prinsip teknik yang ketat akan membuat pengembangan perangkat lunak lebih cepat. Alasan utama alat-alat ini tidak menangkap, selain biaya, adalah tingginya standardisasi data yang diperlukan agar alat dapat bekerja secara efektif.

Internet mulai dikenal pada 1990-an. Jenis-jenis pemrograman yang difasilitasi Internet meledak. Pemrogram diminta untuk menangani ilustrasi, peta, foto, dan gambar lain, ditambah animasi sederhana, pada tingkat yang belum pernah dilihat sebelumnya, dengan beberapa metode terkenal. Jumlah teknologi untuk menghasilkan objek-objek ini berlipat ganda. Mimpi pemrograman otomatis memudar.

Pengalihdayaan pemrograman ke lokasi yang lebih murah adalah salah satu dari sedikit metode yang tersisa untuk mengurangi biaya programmer. Masalah dengan outsourcing termasuk masalah komunikasi dan masalah spesifikasi.

Metode Formal

Sekali waktu, diusulkan agar perangkat lunak dapat dibuktikan benar. (Gagasannya adalah pengujian tidak dapat menunjukkan bahwa tidak ada kesalahan, tetapi bukti akan mampu.) Sayangnya, menyusun bukti untuk suatu program memiliki beberapa kelemahan utama:

• Lebih sulit dan menghabiskan waktu daripada menulis program.
• Itu harus mencakup seluruh program, artinya Anda perlu bukti untuk perpustakaan, OS, dll ...
• Itu tidak membuktikan tidak adanya bug, karena bug itu mungkin disebabkan oleh kecelakaan.

Konsep ini sangat populer di tahun 70-an.

Tautan: http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods