Metodologi pengembangan perangkat lunak mana yang dapat dilihat sebagai dasar

Saya sedang menulis makalah penelitian kecil yang melibatkan metodologi pengembangan perangkat lunak. Saya mencari semua metodologi yang tersedia dan saya bertanya-tanya, dari semua metodologi, apakah ada yang menyediakan dasar untuk yang lain?

Sebagai contoh, melihat metodologi berikut:
Agile, Prototyping, Cleanroom, Iterative, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model, TDD.

Bisakah kita mengatakan bahwa:
Prototyping, Iterative, Spiral dan Waterfall adalah "fondasi" bagi yang lain?

Atau adakah yang namanya "yayasan" dan apakah setiap metodologi memiliki sejarah uniknya sendiri?

Saya tentu ingin menggambarkan semua metodologi dalam makalah penelitian saya, tetapi saya tidak punya waktu untuk melakukannya dan itulah sebabnya saya ingin tahu metodologi mana yang dapat dilihat sebagai perwakilan.

Nama-nama dalam daftar Anda tidak semua metodologi dan berskala pada tingkat yang berbeda:

• Iteratif adalah karakteristik, sifat yang dimiliki oleh beberapa metode dan teknik. Scrum adalah metodologi berulang, TDD adalah teknik berulang.
• Saya melihat Agile sebagai superset metodologi yang tetap pada tingkat konseptual / filosofis. Dalam pemrograman berorientasi objek Anda bisa menggambarkannya sebagai abstrak - itu adalah seperangkat nilai dan prinsip yang tidak dapat dipakai dan harus diturunkan dan diimplementasikan. Itulah yang dilakukan Scrum dan XP.
• Cleanroom, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model adalah metodologi yang tepat, yaitu proses pengembangan perangkat lunak (meskipun Scrum mengklaim sebagai "kerangka" ringan yang bertentangan dengan proses yang berat)
• Prototyping dan TDD adalah teknik, aktivitas. TDD adalah praktik XP.

Membedakan yang merupakan fondasi yang merupakan pekerjaan yang sulit. Anda dapat menggambar garis sejarah dengan jelas, tetapi metodologi jarang secara langsung didasarkan pada yang lain. Mereka agak tumpang tindih, meminjam satu sama lain, kadang-kadang saling merespons ... Saya tidak dapat melihat klasifikasi yang jelas, meskipun Anda mungkin bisa menjabarkan beberapa keluarga besar.

Cara lain untuk melihatnya adalah dari perspektif generasi. Dalam hal perangkat lunak perusahaan saya akan mengatakan kami telah mengetahui 2 generasi metodologi. Yang pertama, di antaranya Waterfall dan V-Model, sebagian besar proses yang sudah ada sebelumnya dari disiplin ilmu teknik lain yang diterapkan untuk perangkat lunak. Generasi kedua (Anda dapat menyebutnya Agile tetapi dimulai jauh sebelum istilah Agile diciptakan) dimulai sebagai reaksi terhadap beratnya proses generasi pertama, ketika orang-orang mulai menyadari bahwa perangkat lunak adalah binatang yang sama sekali berbeda dan bahwa kriteria yang membuat baik perangkat lunak dan langkah-langkah yang dapat memastikan kriteria ini benar-benar spesifik dan masih harus dieksplorasi.

Akhirnya Anda harus mencatat bahwa, dalam perangkat lunak mungkin bahkan lebih dari disiplin ilmu lain, metodologi bukanlah resep yang hanya dapat Anda terapkan untuk membuat semuanya berfungsi. Pengembangan perangkat lunak memiliki aspek manusia sebanyak aspek teknis dan tim atau manajer yang datang dengan metodologi peluru perak dan daftar hal-hal untuk diterapkan secara membabi buta dapat mengharapkan beberapa kejutan. Hanya dengan melihat studi tentang tingkat keberhasilan proyek perangkat lunak seperti Chaos Report tahun demi tahun, Anda dapat mengatakan bahwa sejarah metodologi perangkat lunak lebih terkait dengan serangkaian upaya yang gagal daripada aturan proses yang solid, secara ilmiah, dan dapat diulang.

Ada tiga:

1. tidak ada (alias koboi coding)
2. air terjun
3. pengembangan aplikasi yang cepat (RAD atau spiral)

sisanya adalah varian dan kombinasi dari semuanya

perhatikan bahwa artefak dari air terjun (awal, persyaratan, spek fungsional, spek desain, spek pengujian, spek kontrol kualitas, dll.) semuanya mencakup hal-hal yang penting bagi proyek, sebagian besar jika tidak semuanya dicakup oleh metodologi lain tetapi dalam cara yang sangat berbeda. Misalnya, dalam TDD fitur, cerita pengguna, dan deskripsi pengujian mencakup persyaratan, spesifikasi fungsional, dan spesifikasi pengujian dari air terjun. Dalam RUP bahkan lebih banyak artefak yang ditambahkan yang memecah sepotong spesifikasi air terjun (dokumen Stakeholder, misalnya, adalah bagian dari dokumen Inception) tetapi menghasilkan secara spiral

tolong terbitkan tautan ke hasil Anda setelah selesai, itu terdengar seperti kertas yang menarik!

Mungkin Anda hanya ingin menyebutkan metodologi antik (bukan 'metodologi) seperti:

1. pemrosesan batch: kirim setumpuk kartu dan dapatkan kembali hasilnya pada hari berikutnya. Kelemahan: terlalu banyak waktu antara pengiriman; untuk debugging, pelajari dump inti.

2. metode cli - gunakan vi atau emacs, lalu kompilasi; semua dari baris perintah seperti dilakukan di shell linux bahkan sampai hari ini. Kelemahan: sulit di-debug (gdb? Apakah Anda akan menanyai saya?), Perintah shell yang tidak jelas berusia 40 tahun.

Hanya pemikiran saja.

Anda dapat menyebutkan tiga pendekatan dasar: Prototyping, Spiral and Waterfall. Saya tidak akan menganggap Lean, TDD atau Cleanroom sebagai metodologi, melainkan proses yang dapat menjadi bagian dari metodologi.