Ist eine iterative Dokumentationsentwicklung möglich und liefert sie eine effektive Dokumentation?

Ich habe ein Projekt für die Universität, mit dem ich nicht sofort anfangen werde, über das ich aber ziemlich lange nachgedacht habe. Ich verstehe, dass die Entwicklung von Universitätsprojekten nicht wie die Industrie ist (ich bin derzeit selbst Praktikant), daher wird die Situation, auf die ich im Moment hinweisen werde, für tatsächliche Softwareentwickler wahrscheinlich etwas lächerlich erscheinen. ^^ '

Das Projekt selbst erfordert, dass wir einen Großteil unserer Arbeit dokumentieren. Neben der Bereitstellung von Code, der für einige der Marken zählt, müssen wir also Dokumente liefern, darunter:

• Ein Anforderungsanalyse-Dokument
• Ein Projektplan
• Eine geplante Liste von Anwendungsfällen, Objekt- und dynamischen Modellen sowie Abnahmetests
• Dokumentation des Testprozesses und wie erfolgreich die Tests waren
• Einige andere Diskussionen und Analysen zur Zeitnutzung usw.

Diese Leistungen sind wie folgt zu erbringen:

• RAD zuerst
• Gefolgt von Projektplan, Anwendungsfällen, Modellen und Tests (ca. 3 Wochen später)
• Zuletzt die Dokumentation des eigentlichen Programms, des Testprozesses usw. + die eigentliche Programmierung selbst (ca. 5 Wochen später)

Soweit ich weiß, ist dies wirklich auf einen Ansatz im Stil eines Wasserfalls für das Projekt ausgerichtet. Das einzige Problem (meiner Meinung nach) ist, dass dies ein Universitätsprojekt ist und die Studenten bereits genug Druck haben, Projekte am Ende des Semesters während der Projektwoche zu entwickeln. Ich möchte am Ende des Semesters nicht wirklich alles codieren / entwickeln / testen, wenn ich mit so vielen anderen Einschätzungen in Panik gerate, mit denen ich mich befassen muss.

Ich möchte zumindest versuchen, einen iterativen Entwicklungszyklus durchzuführen, der bedeutet, dass wir früh mit dem Codieren / Prototyping beginnen können, einen kontinuierlichen Entwicklungszyklus haben, der sich nicht darauf konzentriert, alles in letzter Minute zu tun, und nicht so viel Druck haben das Ende des Semesters, um dieses Projekt abzuschließen. Und jetzt kommt meine eigentliche Frage (n):

• Kann ich es irgendwie vereinbaren, all diese Dokumentation mit einem schnellen, iterativen / Prototyping-Entwicklungszyklus liefern zu müssen?
• Gibt es Strategien, um Dokumentation iterativ zu generieren?
• Bin ich völlig unvernünftig, wenn ich das frage und erwarte, dass es an der Universität machbar ist?

Ich verstehe auch, dass diese Frage extrem lokalisiert ist, daher möchte ich dieselben Fragen stellen, die ich oben in Bezug auf die Branche gestellt habe, und ob viele dieser Probleme, mit denen agile Prozesse konfrontiert sind, für jedes Team unterschiedlich sind oder nicht oder Firma.

Wie auch immer, entschuldigen Sie, wie lange das dauert, und wenn Sie den ganzen Weg durchgelesen haben, danke! Wenn Sie sich die Zeit nehmen könnten, um zu antworten, wäre ich Ihnen sehr dankbar! Vielen Dank!

Das Hauptanliegen (ich habe ein ähnliches Problem mit meinem Job) ist, dass wenn "The Process" verlangt, dass Sie bestimmte Artefakte zu bestimmten Zeiten liefern, und niemand das allmächtige "The Process" herausfordern darf, dann, wenn Sie es versuchen, Sie wird verlieren! Es ist nicht nur eine einfache Sache, dass es ein besserer Weg ist (welche iterative Dokumententwicklung ist).

Sie müssen also innerhalb des Prozesses arbeiten, aber auch einen Weg finden, wie Sie möchten. Ermöglicht Ihr Prozess beispielsweise die Änderung von Dokumenten nach der Übermittlung? Wenn nicht, ist keine iterative Entwicklung möglich. Wenn ja, müssen Sie über die Kosten der Lieferung nachdenken (in Bezug auf Ihre Zeit, Ihre Glaubwürdigkeit usw.) und diese Kosten verwalten. Wenn es sich zum Beispiel um eine Dateikopie handelt und nicht mehr, dann versuchen Sie es. Wenn es sich (wie ich) um eine Peer-Review- oder Revisionsversion handelt, die Dutzende von Menschen betrifft und Tausende von Dollar kostet, dann überlegen Sie genau und stellen Sie sicher, dass das neue Dokument wirklich einen Mehrwert bietet.

Eine übliche Arbeitsweise ist ein wesentliches Mindestdokument, das zu Beginn die Anforderungen von "The Process" erfüllt, gefolgt von einem endgültigen "as built" -Update, das nicht nur die Realität widerspiegelt, sondern bei Bedarf auch die erforderlichen Details enthält kurz, wo der Code für sich selbst spricht.