Давно хотел задать такой вопрос, вообще говоря, не знаю есть ли такая проблема в разработке или она мною надумана, у нас в фирме разработчиков мало и все делается на память. А именно: Как организовывается хранение привязки требований и кусков кода, где эти требования реализованы. Если за требование отвечает класс, то, казалось бы, можно вести табличку требование-класс. А если требование размазано по триггерам и слою доступа к данным. Скорее всего это ошибка проектирования (или я не прав), но такое теоретически возможно. Как строится процесс согласованности такой привязки требований с кодом? Т.е. если я поменял код я должен дисциплинированно пойти подкорректировать документ.. Есть ли такая проблема в современном мире разработки программного обеспечения? Как она решается?
Если не вести привязку в документе, может быть можно писать номер требования в комментарии в коде и какой-то сборщик соберет ссылочную документацию?
Или когда я в гите коммичу в комментариях могу написать идентификатор требования. Потом в будущем смогу посмотреть какой код отвечает за требование по этому комментарию?
Re: Документирование соответствий бизнес-требований к коду
Здравствуйте, hyp1k, Вы писали:
H>Как организовывается хранение привязки требований и кусков кода, где эти требования реализованы. Если за требование отвечает класс, то, казалось бы, можно вести табличку требование-класс. А если требование размазано по триггерам и слою доступа к данным. Скорее всего это ошибка проектирования (или я не прав), но такое теоретически возможно. Как строится процесс согласованности такой привязки требований с кодом? Т.е. если я поменял код я должен дисциплинированно пойти подкорректировать документ.. Есть ли такая проблема в современном мире разработки программного обеспечения? Как она решается?
Это не во всех проектах реально нужно. Если проект небольшой (скажем, до 500 к строк кода) и со внятной бизнес-моделью, то часто бывает быстрее найти зависимость по коду и спецификации, чем искать отдельный документ.
Надо понимать, что поддержка такого документа (кстати, для поиска, он обычно называется traceability matrix) дело достаточно хлопотное.
H>Если не вести привязку в документе, может быть можно писать номер требования в комментарии в коде и какой-то сборщик соберет ссылочную документацию? H>Или когда я в гите коммичу в комментариях могу написать идентификатор требования. Потом в будущем смогу посмотреть какой код отвечает за требование по этому комментарию?
На практике, в небольших проектах лучше всего связывать требования и код через юнит-тесты: к каждому тесту писать атрибут, перечисляющий пункты требований. А весь код, который выполняется под этим тестом считать реализующим требование.
Это позволяет автоматически генерировать зависимости и собирать их в документ хоть каждый билд. Да и документ в этом случае не особо нужен, можно прямо по тестам смотреть.
Ведь конечная цель такого документа обычно как раз выяснить, на какие требования может влиять изменение данного куска кода.
И поиск кода по номеру требования становится простым.
Re: Документирование соответствий бизнес-требований к коду
Здравствуйте, hyp1k, Вы писали:
H>Если не вести привязку в документе, может быть можно писать номер требования в комментарии в коде и какой-то сборщик соберет ссылочную документацию? H>Или когда я в гите коммичу в комментариях могу написать идентификатор требования. Потом в будущем смогу посмотреть какой код отвечает за требование по этому комментарию?
Если есть должность аналитика — он уже должен всё это дело организовать.
Если нет тасктрекера — завести и скрестить с вашим репо исходников.
Если есть тасктрекер — помечать все тикеты метками функционала, дальше нужное находится банальным поиском тикета и просмотром коммитов.
Ну, или в обратном направлении: находим проблемный файл, смотрим, в каком коммите поменялось проблемное место. Из коммита достаём номер тикета, дальше всё просто.
Re: Документирование соответствий бизнес-требований к коду
Здравствуйте, hyp1k, Вы писали:
H>Если не вести привязку в документе, может быть можно писать номер требования в комментарии в коде и какой-то сборщик соберет ссылочную документацию? H>Или когда я в гите коммичу в комментариях могу написать идентификатор требования. Потом в будущем смогу посмотреть какой код отвечает за требование по этому комментарию?
H> Как организовывается хранение привязки требований и кусков кода, где эти требования реализованы.
Простейший вариант — через тикет в Jira/Bugzilla/etc.. В тикете указаны требования. Тикет имеет тип "feature" (или "user story", это где как принято). Если у вас есть более чем один уровень (например, каждая feature состоит из многих user story), введите этот уровень в виде дополнительно поля "идентификатор фичи".
Каждый commit в SCM (git, SVN, whatever) содержит номер тикета, где описано все, что должно быть сделано для этой конкретной задачи.
Тикеты, открытые на баги, также могут содержать ссылку на feature/UserStory, чтобы было понятно, кому и что фиксили.
H> Т.е. если я поменял код я должен дисциплинированно пойти подкорректировать документ.. Есть ли такая проблема в современном мире разработки программного обеспечения? Как она решается?
Отдельный документ не нужен. Если нужно найти всю документацию по данной фиче, ее либо ведет аналитик (у вас такового нет), либо достается банальным поиском по Jira/Bugzilla.
Re: Документирование соответствий бизнес-требований к коду
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, hyp1k, Вы писали:
H>>Если не вести привязку в документе, может быть можно писать номер требования в комментарии в коде и какой-то сборщик соберет ссылочную документацию? H>>Или когда я в гите коммичу в комментариях могу написать идентификатор требования. Потом в будущем смогу посмотреть какой код отвечает за требование по этому комментарию?
S>Если есть должность аналитика — он уже должен всё это дело организовать.
не понятно. откуда аналитику что-то про код знать? вопрос же про соответствие требований/фич коду.
S>Если нет тасктрекера — завести и скрестить с вашим репо исходников.
самая бесполезная фича VCS. ниже расскажу.
S>Если есть тасктрекер — помечать все тикеты метками функционала, дальше нужное находится банальным поиском тикета и просмотром коммитов.
наконец-то увидел правильное слово — коммит.
в вопросе ничего не написано зачем все эти соответствия с кодом.
по своему опыту рабочий/годный сценарий примерно такой:
что-то накомитил --> отписался про багфикс/фичу --> в письме обязательно перечислил все фичи/багфиксы которые надо перетестировать.
это ручная работа. вносить в какую-то систему — не нужно. кто это будет делать?
и зачем? что бы коммиты джуниоров автоматически рассылали такое письмо с перечислением 1) фиксов/фич 2) зависимых фич/багфиксов?
не возможно такое автоматичсеки отслеживать.
S>Ну, или в обратном направлении: находим проблемный файл, смотрим, в каком коммите поменялось проблемное место. Из коммита достаём номер тикета, дальше всё просто.
а кто его искать будет. у продуктов от 5-10 лет есть полно вообще непонятного никому кода.
Re: Документирование соответствий бизнес-требований к коду
Здравствуйте, hyp1k, Вы писали:
H>Если не вести привязку в документе, может быть можно писать номер требования в комментарии в коде и какой-то сборщик соберет ссылочную документацию? H>Или когда я в гите коммичу в комментариях могу написать идентификатор требования. Потом в будущем смогу посмотреть какой код отвечает за требование по этому комментарию?
Чисто теоретически, это можно сделать через связку "Requirement<->Task<->Changeset", если брать TFS. Т.е. по каждому требованию можно собрать все коммиты.
Но это не решает проблемы актуализации требования, если что-то поменяли потом в рамках реализации ДРУГОГО требования.
Re[3]: Документирование соответствий бизнес-требований к коду
Здравствуйте, VladCore, Вы писали:
H>>>Если не вести привязку в документе, может быть можно писать номер требования в комментарии в коде и какой-то сборщик соберет ссылочную документацию? S>>Если есть должность аналитика — он уже должен всё это дело организовать. VC>не понятно. откуда аналитику что-то про код знать? вопрос же про соответствие требований/фич коду.
Как бы очевидно, что весь процесс документирования должен быть организован так, что результатом могут пользоваться вся команда разработки. В том числе и QA, и разработчики.
Для этого нужно решить тонну мелочей и вопрос о привязке кода к ТЗ — наименьший из них.
Если в команде есть тех-аналитик — это его вотчина. Иначе этим занимается биз-аналитик пополам с архитектором. Если ни того, ни другого нет — документация вам и не нужна. Ваш кэп
S>>Если нет тасктрекера — завести и скрестить с вашим репо исходников. VC>самая бесполезная фича VCS. ниже расскажу. VC>что-то накомитил --> отписался про багфикс/фичу --> в письме обязательно перечислил все фичи/багфиксы которые надо перетестировать.
Какие письма?
Все пристойные таск-трекеры лет 10 как умеют ticket workflow, который в себя включает автоперевод в тестирование тикетов, упомянутых в сообщение коммита. Серьёзно, кто-то ещё городит свои схемы вместо стандартных таск-трекеров?
VC>и зачем? что бы коммиты джуниоров автоматически рассылали такое письмо с перечислением 1) фиксов/фич 2) зависимых фич/багфиксов? VC>не возможно такое автоматичсеки отслеживать.
Какие нафиг письма? Вы ещё скажите, что регрессии у вас люди ловят, а не ui-тесты.
S>>Ну, или в обратном направлении: находим проблемный файл, смотрим, в каком коммите поменялось проблемное место. Из коммита достаём номер тикета, дальше всё просто. VC>а кто его искать будет. у продуктов от 5-10 лет есть полно вообще непонятного никому кода.
Не обижайтесь, но полное отсутствие процесса разработки — это ненормально. Код может быть непонятен, но он обязательно должен быть привязан к истории коммитов и к тикетам/таскам. Иначе это не код, а неподдерживаемое легаси, которое надо закопать чем скорее, тем лучше.
Re[4]: Документирование соответствий бизнес-требований к коду
Здравствуйте, SkyDance, Вы писали:
SD>Да ладно SD>Подавляющее большинство контор как-то живут же.
Не, ну понятно, что "Ну да. Ну ужас. Но ведь не "ужас! ужас! ужас!"(с)
Но это не значит, что к такому положению дел надо стремиться. А то фигня какая-то выходит: и зарегулировано всё вплоть до рассылки писем, и толку никакого нет — старый код неподдерживаемый получается
Re[6]: Документирование соответствий бизнес-требований к коду
S>Но это не значит, что к такому положению дел надо стремиться. А то фигня какая-то выходит: и зарегулировано всё вплоть до рассылки писем, и толку никакого нет — старый код неподдерживаемый получается
Теперь, кажется, ты начинаешь понимать разницу между законодательной, исполнительной и судебной ветками власти.
Re[3]: Документирование соответствий бизнес-требований к коду
Здравствуйте, VladCore, Вы писали:
VC>наконец-то увидел правильное слово — коммит. VC>в вопросе ничего не написано зачем все эти соответствия с кодом. VC>по своему опыту рабочий/годный сценарий примерно такой:
VC>что-то накомитил --> отписался про багфикс/фичу --> в письме обязательно перечислил все фичи/багфиксы которые надо перетестировать.
Ты это серьезно что ли?! Вы письма пишете?! Вручную?! Жуть какая.
IMHO, соответствие с кодом — важнейшая вещь, которая жизненно необходима при длительной поддержке продукта.
Чтобы понимать, откуда какая-то @#$ взялась и @#$ она нужна. Ворох писем здесь вообще никак не помогает.
Re: Документирование соответствий бизнес-требований к коду
Здравствуйте, hyp1k, Вы писали:
H>Если не вести привязку в документе, может быть можно писать номер требования в комментарии в коде и какой-то сборщик соберет ссылочную документацию? H>Или когда я в гите коммичу в комментариях могу написать идентификатор требования. Потом в будущем смогу посмотреть какой код отвечает за требование по этому комментарию?
Вы находитесь на правильном пути. Правильный (для проектов больше 100 чел/лет и длинной историей) сценарий такой:
Если есть система трекинга требований то она связывает: требование — задача — тестовые сценарии
Если такой системы нет, можно делать частично вручную.
В системе работы с требованиями указываем номера задач которые реализуют требование
В базе знаний проектируем как требование/подсистема будет реализовано, и ссылаемся на требования как ограничения реализации. Помним что документация устаревает с момента выхода.
В задаче в постановке задачи пишем что делать надо детально.
в VCS создаем бранч по номеру задачи
пишем модульные тесты к требованию, и код
После завершения работы над задачей мержим и пишем в задаче ОТЧЕТ, что ФАКТИЧЕСКИ сделано.
Трекинг от требования: Находим все задачи которые касались требования, смотрим что там сделано самого интересного кроме переименования переменных по всему проекту
Делаем diff бранчей задач, изучаем.
Трекинг от кода: спрашиваем в VCS в каких бранчах менялся этот код, получаем номера задач
смотрим по задачам , что там было и почему.
от задач идем к требованиям, выясняем ограничения.
Здравствуйте, comm, Вы писали: C> В базе знаний проектируем как требование/подсистема будет реализовано, и ссылаемся на требования как ограничения реализации. Помним что документация устаревает с момента выхода.
