Возможна ли разработка итеративной документации и обеспечивает ли она эффективную документацию?

У меня есть проект для университета, который я не начну сразу, но долго размышлял над этим. Я понимаю, что разработка университетских проектов не похожа на индустрию (сейчас я сам стажер), поэтому ситуация, на которую я сейчас укажу, может показаться нелепой разработчикам программного обеспечения. ^^

Сам проект требует, чтобы мы документировали большую часть нашей работы. Таким образом, помимо предоставления кода, который учитывает некоторые оценки, мы должны доставлять документы, в том числе:

• Документ анализа требований
• План проекта
• Запланированный список вариантов использования, объектных и динамических моделей и приемочных испытаний
• Документирование процесса тестирования и насколько успешными были тесты
• Некоторые другие обсуждения и анализ использования времени и т. Д.

Эти результаты должны быть доставлены следующим образом:

• RAD первый
• Затем следует план проекта, варианты использования, модели и тесты (примерно через 3 недели)
• Наконец, документация по фактической программе, процессу тестирования и т. Д. + Собственно собственно программирование (примерно через 5 недель)

Итак, насколько я понимаю, это действительно направлено на подход в стиле Waterfall. Единственная проблема (на мой взгляд) заключается в том, что это университетский проект, и студенты уже испытывают достаточное давление, как и в случае попыток разработки проектов в конце семестра в течение проектной недели. Я действительно не хочу кодировать / разрабатывать / тестировать все в конце семестра, когда я буду паниковать со многими другими оценками, с которыми мне придется иметь дело.

Я хотел бы, по крайней мере, попытаться сделать какой-то итерационный цикл разработки, который означает, что мы можем начать кодирование / создание прототипов на ранней стадии, иметь непрерывный цикл разработки, который не сфокусирован на выполнении всего в последнюю минуту, и не оказывать такого большого давления на конец семестра, чтобы закончить этот проект. И теперь приходит мой актуальный вопрос (ы):

• Могу ли я как-то примирить необходимость доставки всей этой документации с быстрым итеративным циклом разработки / создания прототипа?
• Существуют ли стратегии для создания документации итеративным способом?
• Я совершенно необоснованно спрашиваю об этом и ожидаю, что это будет выполнимо в университете?

Кроме того, я понимаю, что этот вопрос чрезвычайно локализован, поэтому я хотел бы задать те же вопросы, которые я задавал выше с точки зрения отрасли, а также то, различаются ли многие из этих проблем, с которыми сталкиваются гибкие процессы, для каждой команды. или компания.

В любом случае, извините за то, как долго это продолжается, и если вы закончили чтение до конца, спасибо! Если бы вы могли найти время, чтобы ответить, я был бы очень благодарен! Спасибо!

Основная проблема (у меня похожая проблема с моей работой) заключается в том, что если «Процесс» требует, чтобы вы доставили определенные артефакты в определенное время, и никому не позволено оспаривать всемогущий «Процесс», то, если вы попытаетесь, вы потеряет! Это не просто вопрос лучшего способа (что такое итеративная разработка документации).

Так что вам нужно работать внутри процесса, но найти способ работать так, как вы хотите. Например, разрешает ли ваш процесс модификацию документа после отправки? Если нет, то итеративное развитие невозможно. Если это так, то вам нужно подумать о стоимости доставки (с точки зрения вашего времени, вашего доверия и т. Д.) И управлять этой стоимостью. Если, например, это копия файла и ничего более, то пойти на это. Если (как и я) это рецензирование, выпуск ревизий, оно затрагивает десятки людей и стоит тысячи долларов, то подумайте внимательно и убедитесь, что новый документ действительно добавляет ценность.

Обычный способ работы - это минимальные документы, минимальный документ, который вначале отвечает требованиям «Процесса», за которым следует окончательное обновление «как построено», которое не только отражает реальность, но и содержит детали, где это необходимо, и является Кратко, где код говорит сам за себя.