Le développement itératif de la documentation est-il possible et fournit-il une documentation efficace?

J'ai un projet d'université auquel je ne vais pas commencer immédiatement, mais je réfléchis depuis assez longtemps. Je comprends que le développement de projets universitaires n'est pas comme l'industrie (je suis moi-même actuellement stagiaire), donc la situation que je vais signaler pour le moment semblera probablement quelque peu ridicule aux développeurs de logiciels. ^^ '

Le projet lui-même exige que nous documentions une grande partie de notre travail. Ainsi, en plus de fournir du code, qui compte pour certaines des marques, nous devons fournir des documents, notamment:

• Un document d'analyse des exigences
• Un plan de projet
• Une liste planifiée de cas d'utilisation, de modèles d'objets et dynamiques et de tests d'acceptation
• Documentation du processus de test et du succès des tests
• Quelques autres discussions et analyses de l'utilisation du temps, etc.

Ces livrables doivent être livrés de la manière suivante:

• RAD en premier
• Suivi du plan de projet, des cas d'utilisation, des modèles et des tests (environ 3 semaines plus tard)
• Enfin, la documentation du programme réel, le processus de test, etc. + la programmation proprement dite (environ 5 semaines plus tard)

Donc, d'après ce que je comprends, cela est vraiment orienté vers une approche de style cascade du projet. Le seul problème (à mon avis) est qu'il s'agit d'un projet universitaire, et les étudiants ont déjà suffisamment de pression comme c'est le cas pour essayer de développer des projets à la fin du semestre pendant la semaine du projet. Je ne veux pas vraiment tout coder / développer / tester tout à la fin du semestre, quand je paniquerai avec les nombreuses autres évaluations auxquelles je dois faire face.

J'aimerais au moins essayer de faire une sorte de cycle de développement itératif qui signifie que nous pouvons commencer le codage / prototypage tôt, avoir un cycle de développement continu qui ne se concentre pas sur tout faire à la dernière minute et ne pas avoir autant de pression à la fin du semestre pour terminer ce projet. Et voici maintenant ma ou mes questions:

• Puis-je en quelque sorte concilier l'obligation de fournir toute cette documentation avec un cycle de développement rapide, itératif / de prototypage?
• Existe-t-il des stratégies pour générer de la documentation de manière itérative?
• Suis-je totalement déraisonnable de demander cela et de m'attendre à ce que ce soit faisable à l'université?

De plus, je comprends que cette question est extrêmement localisée, je voudrais donc poser les mêmes questions que j'ai posées ci-dessus en termes d'industrie, et si beaucoup de ces types de problèmes auxquels les processus agiles sont confrontés sont différents pour chaque équipe ou entreprise.

Quoi qu'il en soit, désolé pour la durée de cette opération, et si vous avez terminé la lecture jusqu'au bout, merci! Si vous pouviez prendre le temps de répondre, je vous en serais très reconnaissant! Je vous remercie!

La principale préoccupation (j'ai un problème similaire avec mon travail) est que si "The Process" exige que vous livriez certains artefacts à certains moments, et que personne ne soit autorisé à contester le tout-puissant "The Process", alors si vous essayez, vous va perdre! Ce n'est pas seulement une simple question d'être un meilleur moyen (Quel est le développement de doc itératif).

Donc, ce que vous devez faire, c'est travailler dans le cadre du processus, mais trouvez également un moyen de travailler comme vous le souhaitez. Par exemple, votre processus permet-il la modification du document une fois soumis? Sinon, aucun développement itératif n'est possible. Si oui, alors vous devez penser au coût de livraison (en termes de temps, de crédibilité, etc.) et gérer ce coût. Si, par exemple, c'est une copie de fichier et rien de plus, alors allez-y. Si (comme moi) il s'agit d'un examen par les pairs, d'une version de révision, qui affecte des dizaines de personnes et coûte des milliers de dollars, alors réfléchissez bien et assurez-vous que le nouveau document ajoute vraiment de la valeur.

Une façon courante de travailler est un strict minimum, un document minimum qui répond aux besoins de "The Process" au début, suivi plus tard par une mise à jour finale "telle que construite" qui non seulement reflète la réalité, mais a les détails si nécessaire, et est bref où le code parle de lui-même.