Apakah pengembangan dokumentasi iteratif dimungkinkan, dan apakah ia menghasilkan dokumentasi yang efektif?

Saya memiliki proyek untuk universitas yang tidak akan saya mulai dengan segera, tetapi telah memikirkan untuk waktu yang cukup lama. Saya mengerti bahwa pengembangan proyek Universitas tidak seperti industri (saya sendiri sedang magang) sehingga situasi yang akan saya tunjukkan saat ini mungkin akan tampak agak konyol bagi pengembang perangkat lunak yang sebenarnya. ^^ '

Proyek itu sendiri mengharuskan kami mendokumentasikan banyak pekerjaan kami. Jadi, selain mengirimkan kode, yang diperhitungkan pada beberapa merek, kami harus mengirimkan dokumen termasuk:

• Dokumen Analisis Persyaratan
• Rencana Proyek
• Daftar terencana Kasus Penggunaan, Obyek dan Model Dinamis dan Tes Penerimaan
• Dokumentasi proses pengujian dan seberapa sukses pengujian itu
• Beberapa diskusi lain dan analisis penggunaan waktu, dll.

Hasil ini harus disampaikan dengan cara berikut:

• RAD dulu
• Diikuti oleh Rencana Proyek, Kasus Penggunaan, Model dan Tes (sekitar 3 minggu kemudian)
• Terakhir, dokumentasi program aktual, proses pengujian, dll. + Pemrograman aktual itu sendiri (sekitar 5 minggu kemudian)

Jadi, dari apa yang saya mengerti, ini benar-benar diarahkan pada pendekatan gaya air terjun ke proyek. Satu-satunya masalah (menurut saya) adalah ini adalah proyek Universitas, dan para siswa sudah memiliki tekanan yang cukup karena mencoba mengembangkan proyek pada akhir semester selama minggu proyek. Saya tidak benar-benar ingin menjadi pengkodean / pengembangan / pengujian segalanya pada akhir semester, ketika saya akan panik dengan banyak penilaian lain yang harus saya tangani.

Saya ingin setidaknya mencoba dan melakukan semacam siklus pengembangan berulang yang berarti kita dapat memulai pengkodean / pembuatan prototipe lebih awal, memiliki siklus pengembangan berkelanjutan yang tidak fokus melakukan segala sesuatu pada menit terakhir dan tidak memiliki banyak tekanan pada akhir semester untuk menyelesaikan proyek ini. Dan sekarang muncul pertanyaan saya yang sebenarnya:

• Dapatkah saya entah bagaimana mendamaikan harus menyerahkan semua dokumentasi itu dengan siklus pengembangan yang cepat, berulang / membuat prototip?
• Apakah ada strategi untuk menghasilkan dokumentasi secara iteratif?
• Apakah saya sepenuhnya tidak masuk akal menanyakan hal ini dan berharap hal itu dapat dilakukan di Universitas?

Juga, saya mengerti bahwa pertanyaan ini sangat terlokalisasi, jadi saya ingin mengajukan pertanyaan yang sama dengan yang saya tanyakan di atas dalam hal industri, dan apakah banyak masalah seperti ini yang dihadapi proses tangkas berbeda untuk setiap tim atau perusahaan.

Ngomong-ngomong, maaf tentang berapa lama ini, dan jika Anda telah selesai membaca semuanya, terima kasih! Jika Anda bisa meluangkan waktu untuk menjawab, saya akan sangat berterima kasih! Terima kasih!

Perhatian utama (saya memiliki masalah yang sama dengan pekerjaan saya) adalah bahwa jika "Proses" menuntut Anda memberikan artefak tertentu pada waktu tertentu, dan tidak ada yang diizinkan untuk menantang "Proses" yang maha kuasa, maka jika Anda mencoba, Anda akan lepas! Ini bukan hanya masalah sederhana menjadi cara yang lebih baik (Yang mana pengembangan dokumen iteratif adalah).

Jadi yang perlu Anda lakukan adalah bekerja di dalam proses, tetapi temukan cara untuk bekerja dengan cara yang Anda inginkan juga. Misalnya, apakah proses Anda mengizinkan modifikasi dokumen setelah dikirimkan? Jika tidak, maka tidak mungkin terjadi pengembangan berulang. Jika demikian, maka Anda perlu memikirkan biaya pengiriman (Dalam hal waktu Anda, kredibilitas Anda, dll), dan mengelola biaya itu. Jika, misalnya, ini adalah salinan file dan tidak lebih, maka lakukanlah. Jika (seperti saya) ini adalah peer review, rilis revisi, berdampak pada puluhan orang dan menelan biaya ribuan dolar, maka pikirkan baik-baik dan pastikan dokumen baru benar-benar menambah nilai.

Cara umum untuk bekerja adalah dokumen esensial, dokumen minimum yang memenuhi kebutuhan "Proses" pada awalnya, diikuti kemudian dengan pembaruan "sebagaimana dibangun" final yang tidak hanya mencerminkan kenyataan, tetapi memiliki detail di mana diperlukan, dan singkat di mana kode berbicara sendiri.