Чи можлива розробка ітеративної документації та чи вона забезпечує ефективну документацію?

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

Сам проект вимагає, щоб ми документували багато своєї роботи. Отже, окрім доставки коду, який зараховується до деяких знаків, ми повинні доставити документи, зокрема:

• Документ з аналізу вимог
• План проекту
• Плановий перелік випадків використання, об'єктних та динамічних моделей та тестів прийнятності
• Документація процесу тестування та наскільки успішні були тести
• Деякі інші дискусії та аналізи використання часу тощо.

Ці результати поставляються наступним чином:

• RAD спочатку
• Дотримується план проекту, випадки використання, моделі та випробування (приблизно через 3 тижні)
• Нарешті, документація фактичної програми, процес тестування тощо + власне програмування (приблизно через 5 тижнів)

Отже, наскільки я розумію, це дійсно спрямовано на підхід до проекту у стилі Waterfall. Єдина проблема (на мою думку) полягає в тому, що це проект університету, і студенти вже мають достатній тиск, як це намагаються розробляти проекти в кінці семестру протягом тижня проекту. Мені дуже не хочеться кодувати / розробляти / тестувати все наприкінці семестру, коли я буду панікувати з усіма іншими оцінками, з якими мені доводиться мати справу.

Я хотів би хоча б спробувати зробити якийсь ітераційний цикл розробки, який означає, що ми можемо почати кодування / складання прототипів рано, мати безперервний цикл розробки, який не зосереджений на тому, щоб робити все в останню хвилину і не мати такого сильного тиску на в кінці семестру, щоб закінчити цей проект. І ось тепер виникають мої фактичні питання:

• Чи можу я якось погодитись з тим, щоб доставити всю цю документацію за допомогою швидкого циклу розробки прототипів?
• Чи існують стратегії генерування документації в ітераційному порядку?
• Я зовсім нерозумно запитую це і сподіваюсь, що це стане можливо в університеті?

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

У будь-якому випадку, вибачте, як довго це триває, і якщо ви закінчили читати до кінця, дякую! Якщо ви знайдете час, щоб відповісти, я буду дуже вдячний! Дякую!

Основне занепокоєння (у мене є аналогічна проблема зі своєю роботою) полягає в тому, що якщо "Процес" вимагає, щоб ви доставили певні артефакти в певний час, і нікому не дозволено оскаржувати всемогутнього "Процесу", то, якщо ви спробуєте, ви втратить! Це не просто простий спосіб - це кращий спосіб (який ітеративний розвиток доктора).

Тож, що вам потрібно зробити, - це працювати в процесі, але знайти спосіб працювати так, як ви хочете. Наприклад, чи дозволяє ваш процес змінювати документи після подання? Якщо ні, то ніяких ітеративних розробок неможливо. Якщо так, то вам потрібно подумати про вартість доставки (з точки зору вашого часу, вашої надійності тощо), і керувати цією вартістю. Якщо, наприклад, його копія файлу і більше нічого, тоді перейдіть до цього. Якщо (як я) це експертний огляд, випуск редакції, впливає на десятки людей і коштує тисячі доларів, тоді ретельно продумайте і переконайтеся, що новий документ дійсно додає цінності.

Поширений спосіб роботи - це найголовніший необхідний мінімальний документ, який відповідає потребам "Процесу" на початку, а пізніше - остаточне оновлення "як вбудоване", яке не тільки відображає реальність, але містить деталі, де це потрібно, і є коротко, де код говорить сам за себе.