emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

В предыдущем посте мы установили, почему ADR не содержит трассировок - за ненадобностью в своем историческом контексте ввиду того, что они создавались для такой SDLC-модели, в которой преобладает эмпирический способ обработки неопределенности (adaptation)…

Если мы посмотрим на шаблоны ADR, то мы увидим следующее:

💬 "Related requirements: Decisions should be business driven. To show accountability, explicitly map your decisions to the objectives or requirements. You can enumerate these related requirements here, but we’ve found it more convenient to reference a traceability matrix. You can assess each architecture decision’s contribution to meeting each requirement, and then assess how well the requirement is met across all decisions. If a decision doesn’t contribute to meeting a requirement, don’t make that decision."
-- https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-jeff-tyree-and-art-akerman/index.md

💬 Requirement: The text that details the requirement itself
...
Priority: A statement of priority and claim on resources
Stakeholders: Parties materially affected by the requirement"
-- https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-using-planguage/index.md

💬 "List all relevant use case / requirements documents."
-- https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-edgex/index.md

💬 "An ADR should log the resolution of at least one architecturally significant requirement"
💬 "trace the decision back to requirements"
-- https://ozimmer.ch/practices/2023/04/03/ADRCreation.html

Как видно, Максим Смирнов - не единственный, кто задумался об этой проблеме. И я с ним полностью солидарен в этом вопросе. Как сделать так, чтоб сохранить простоту текстовых файлов ADR, но при этом иметь возможность явно выражать ассоциации и трассировку требований, ограничений, целей, драйверов, стейкхолдеров и т.п.?

Присмотрел для себя два инструмента:
- https://github.com/melexis/sphinx-traceability-extension
- https://sphinx-needs.readthedocs.io/en/latest/

Пока еще не имел возможности опробовать их на практике. Попробую - расскажу. Наверняка есть и другие инструменты - было бы интересно услышать альтернативные варианты.

GitHub

GitHub - joelparkerhenderson/architecture-decision-record: Architecture decision record (ADR) examples for software planning, IT…

Architecture decision record (ADR) examples for software planning, IT leadership, and template documentation - joelparkerhenderson/architecture-decision-record

www.tgoop.com/emacsway_log/1074

1.7K viewsIvan Zakrevsky, edited  May 20, 2023 at 19:47

Если мы посмотрим на шаблоны ADR, то мы увидим следующее:

💬 "Related requirements: Decisions should be business driven. To show accountability, explicitly map your decisions to the objectives or requirements. You can enumerate these related requirements here, but we’ve found it more convenient to reference a traceability matrix. You can assess each architecture decision’s contribution to meeting each requirement, and then assess how well the requirement is met across all decisions. If a decision doesn’t contribute to meeting a requirement, don’t make that decision."
-- https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-jeff-tyree-and-art-akerman/index.md

💬 Requirement: The text that details the requirement itself
...
Priority: A statement of priority and claim on resources
Stakeholders: Parties materially affected by the requirement"
-- https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-using-planguage/index.md

💬 "List all relevant use case / requirements documents."
-- https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-edgex/index.md

💬 "An ADR should log the resolution of at least one architecturally significant requirement"
💬 "trace the decision back to requirements"
-- https://ozimmer.ch/practices/2023/04/03/ADRCreation.html

Как видно, Максим Смирнов - не единственный, кто задумался об этой проблеме. И я с ним полностью солидарен в этом вопросе. Как сделать так, чтоб сохранить простоту текстовых файлов ADR, но при этом иметь возможность явно выражать ассоциации и трассировку требований, ограничений, целей, драйверов, стейкхолдеров и т.п.?

Присмотрел для себя два инструмента:
- https://github.com/melexis/sphinx-traceability-extension
- https://sphinx-needs.readthedocs.io/en/latest/

Пока еще не имел возможности опробовать их на практике. Попробую - расскажу. Наверняка есть и другие инструменты - было бы интересно услышать альтернативные варианты.

BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.