Имея многолетний опыт разработки программного обеспечения, я еще не придумал передовой метод документирования деловых и технических решений и требований.
Например, я хочу знать, почему мы приняли решение реализовать модуль определенным образом и почему впоследствии изменили его. Эту документацию могут использовать новички в проекте, а также другие члены команды, чтобы резюмировать причины принятых решений.
С другой стороны, я хочу знать, какие бизнес-решения мы приняли, и иметь подробный отчет об изменениях.
До сих пор я использовал типичные инструменты, такие как MS Word, Excel, изображения и т. д.
Но я чувствую, что должен быть шаблон или практика для средних и крупных проектов, которые могли бы быть более удобными и удобными в использовании.
Есть идеи?
Я хочу знать, почему мы приняли решение реализовать модуль таким образом и почему впоследствии изменили его.
Это может осуществляться на нескольких уровнях. Я коснусь уровней управления проектами и разработки, но для более глубокого понимания того, как отслеживать эти вещи как процесс разработки, вы должны задать вопрос на Programmers Stack Exchange .
С точки зрения управления проектом это один или несколько из следующих элементов:
В некоторых случаях это может быть даже комбинация всех трех. Спецификации версий могут быть или не быть на самом деле ценными, за исключением, возможно, каскадных сред, где все требует запроса на изменение. В модели итеративной разработки ожидается, что объем и спецификации будут меняться со временем, поэтому, как правило, просмотр исторических версий требований или стратегических решений практически бесполезен.
С инженерной точки зрения командные решения о коде или архитектуре относятся к инженерным артефактам, таким как:
Если вы храните эти вещи в репозитории документов или под контролем исходного кода, вы можете сравнить исторические версии, если когда-нибудь сочтете это необходимым. Это редко имеет значение в итеративных моделях, но ваш пробег может варьироваться.
Многие решения по проектированию или управлению проектом являются результатом «анализа компромиссов», а компромиссы представляют собой метод проверки требований и/или проектов.
Надлежащий системный инженерный подход к проектам будет давать эти артефакты валидации ежедневно, с течением времени. Без необходимости вспоминать, в чем была причина.
Процессы управления конфигурацией также разрешают и запрашивают документирование изменений (и их последствий).
Практики SE иногда обходят стороной, чтобы выиграть время и быстрее получить результаты. Это усложняет отслеживание прошлых решений, а проекты становятся более «ориентированными на людей», где наличие и наличие талантливых и опытных дизайнеров/разработчиков жизненно важно для проекта.
Системы управления проблемами также позволяют собирать огромное количество уроков по мере развития дизайна. Однако на первом этапе использования Task Management проблемы решаются без особого понимания картины. Но по мере развития проекта руководство может начать искать более глубокие решения, а не ежедневные. Но это во многом зависит от личностей и открытости к критике.
Большинство фреймворков SE различаются между тем, что (требования) и как (дизайн). Безусловно, все проектные решения должны быть связаны с требованием. Если появятся новые выводы, например, во время реализации, они должны вернуться в проектную документацию или даже в документацию по требованиям.
До проектного решения (левый или правый поворот) у вас обычно есть какая-то документация, например, протокол собрания, фотографии с доски. Если вы ссылаетесь на эти данные в дизайн-документе, золотого покрытия можно избежать, хотя все еще можно понять проектные решения.
Даже неудобно, имея документацию от чего реализовать и как реализовать отражающую реализацию, в т.ч. решения и рассуждения необходимы для извлечения уроков, аналогичной оценки и, следовательно, будущего успеха проекта.
Марв Миллс
МСВ
Тодд А. Джейкобс
Мори
Мори