Трассировка требований
Трассировка требований - звучит как пассеровка котлет, это про какие-то трассы?
Котлеты, конечно, всегда уместны, но сейчас не о них. А вот ассоциация с трассой ближе к делу. Ранее мы говорили с вами об артефактах анализа. И не зря упомянули системное мышление, помогающее видеть и сопровождать проектные работы в их взаимосвязи и развитии. Трассировка для аналитиков - это объединение артефактов в сеть, в которой понятно происхождение (виден путь) и обусловленность (ясны правила движения) каждого документа, причём не только собственно требований к системе.
Зачем нужна трассировка? Представим группу аналитиков. Один трудится над моделями бизнес-процессов, другой - над логической структурой данных, третий взялся за макеты интерфейсов, четвёртый - за функциональные требования и юзкейсы. Допустим, они работают в команде и даже синхронизируют результаты. Внезапно представитель заказчика решил добавить пару нюансов в модель to-be, а системный архитектор описал новые ограничения по реализации функционала.
И вот незадача - сообщили они это разным специалистам группы. Те внесли правки в СВОИ артефакты, и весь комплект документов ушёл в постановку на разработку. Как вы думаете, кого лишат премии за вынужденный рефакторинг кода вследствие рассогласования?
Существуют разные подходы к тому, как обеспечить надёжную взаимосвязь (см. рис.) проектной документации - непротиворечивость и транспарентность требований. На мой взгляд, достаточно инструмента совместной работы - Confluence и аналогов, - поддерживающего версионирование, где с помощью гипертекста в каждой постановке на разработку требования будут указаны ссылки на соответствующие документы с описанием юзкейса, схемы данных, интерфейса, функциональной и бизнес-моделей и прочих артефактов по целесообразности.
Важно, чтобы программист мог взять вашу постановку и с листа понять, грубо говоря, какие данные и как обрабатывать, чтобы выдать тот или иной результат на экран, и в каком сценарии эта обработка нужна пользователю.
Котлеты, конечно, всегда уместны, но сейчас не о них. А вот ассоциация с трассой ближе к делу. Ранее мы говорили с вами об артефактах анализа. И не зря упомянули системное мышление, помогающее видеть и сопровождать проектные работы в их взаимосвязи и развитии. Трассировка для аналитиков - это объединение артефактов в сеть, в которой понятно происхождение (виден путь) и обусловленность (ясны правила движения) каждого документа, причём не только собственно требований к системе.
Зачем нужна трассировка? Представим группу аналитиков. Один трудится над моделями бизнес-процессов, другой - над логической структурой данных, третий взялся за макеты интерфейсов, четвёртый - за функциональные требования и юзкейсы. Допустим, они работают в команде и даже синхронизируют результаты. Внезапно представитель заказчика решил добавить пару нюансов в модель to-be, а системный архитектор описал новые ограничения по реализации функционала.
И вот незадача - сообщили они это разным специалистам группы. Те внесли правки в СВОИ артефакты, и весь комплект документов ушёл в постановку на разработку. Как вы думаете, кого лишат премии за вынужденный рефакторинг кода вследствие рассогласования?
Существуют разные подходы к тому, как обеспечить надёжную взаимосвязь (см. рис.) проектной документации - непротиворечивость и транспарентность требований. На мой взгляд, достаточно инструмента совместной работы - Confluence и аналогов, - поддерживающего версионирование, где с помощью гипертекста в каждой постановке на разработку требования будут указаны ссылки на соответствующие документы с описанием юзкейса, схемы данных, интерфейса, функциональной и бизнес-моделей и прочих артефактов по целесообразности.
Важно, чтобы программист мог взять вашу постановку и с листа понять, грубо говоря, какие данные и как обрабатывать, чтобы выдать тот или иной результат на экран, и в каком сценарии эта обработка нужна пользователю.
Вместе с тем, с течением жизненного цикла информационной системы мы все чаще ловим себя на мысли, что по какой-то причине чем дальше, тем сложнее разобраться, как и что с чем связано, почему выбраны те или иные решения, как должно меняться поведение системы в ответ на действия пользователя вне рамок стандартных операционных процедур и т. п. Без четких ответов на подобные вопросы довольно трудно говорить о какой-либо разработке с целью дальнейшего развития программного продукта, тем более, о модернизации и сопутствующем реинжиниринге.
Авторы фундаментального учебника в области ИТ-проектирования "Системная инженерия: принципы и практика" (Косяков, Свит, Сеймур, Бимер):
"Важнейшая цель системной инженерии заключается в достижении высокой степени модульности для того, чтобы интерфейсы и взаимодействия были максимально простыми. Достижение этой цели позволяет эффективно организовать производство и комплексирование системы [процесс сборки системы согласно проекту архитектуры - прим. мое], её испытания, техническое обслуживание и ремонт в процессе эксплуатации, а также повысить надежность и облегчить модернизацию без вывода из эксплуатации".
При этом, продолжают они, "за удобство разбиения системы на отдельные составные части приходится платить. Этой платой является комплексирование... Успешное комплексирование означает, что каждая из частей идеально состыкована со своими соседями и с внешним окружением...".
На первый взгляд, какой-то сизифов труд - разбиваем продукт на модули, чтобы потом собрать в одно целое, чтобы снова разобрать по частям для доработки, изменения функционала или апгрейда. Но на самом деле речь о том, как оптимизировать моделирование и разработку ИТ в необходимой и достаточной для ключевых показателей проекта степени - назовем это проблемой комплексного проектирования. Её суть в том, как упростить создание системы и её частей с помощью проектной документации.
Одна из задач, решение которой ведёт нас к этой цели - усиление связности, целостности множества проектных артефактов. И трассировка, о которой говорили выше - здесь лишь частный случай. Нам как аналитикам следует стремиться обеспечивать не только наличие и актуальность связей между документами с описаниями различных видов требований к системе, но и качество самой документальной поддержки этих требований.
Условно говоря, базовый минимум - когда функциональное требование обуславливается запросом целевых пользователей в соответствующей юзерстори, хорошо, если описана постановка на реализацию этой функции во взаимосвязи со смежным по юзкейсу функционалом, очень хорошо - описаны и привязаны к постановкам статусные модели и диаграммы классов используемых информационных сущностей, отрисованы схематичные макеты интерфейсов, описаны проверки данных при попытке записи результатов выполнения функции и отработка ошибок, связь с ролевой моделью прав доступа и логирование действий.
Опустим тяжёлый люкс. Важно, что количество само по себе не перейдет в нужное качество, в каждом проекте, в зависимости от целей и ограничений, придется искать свой баланс глубины и масштаба анализа и объёма техно-рабочей документации. Тем не менее, центральная идея останется прежней - минимально необходимыми средствами проектных артефактов дать ответы на максимально возможное число потенциальных системных "почему", в поддержку проектируемой информационной системы создать достаточно связную мета-систему - базу знаний ИТ-проекта.
Авторы фундаментального учебника в области ИТ-проектирования "Системная инженерия: принципы и практика" (Косяков, Свит, Сеймур, Бимер):
"Важнейшая цель системной инженерии заключается в достижении высокой степени модульности для того, чтобы интерфейсы и взаимодействия были максимально простыми. Достижение этой цели позволяет эффективно организовать производство и комплексирование системы [процесс сборки системы согласно проекту архитектуры - прим. мое], её испытания, техническое обслуживание и ремонт в процессе эксплуатации, а также повысить надежность и облегчить модернизацию без вывода из эксплуатации".
При этом, продолжают они, "за удобство разбиения системы на отдельные составные части приходится платить. Этой платой является комплексирование... Успешное комплексирование означает, что каждая из частей идеально состыкована со своими соседями и с внешним окружением...".
На первый взгляд, какой-то сизифов труд - разбиваем продукт на модули, чтобы потом собрать в одно целое, чтобы снова разобрать по частям для доработки, изменения функционала или апгрейда. Но на самом деле речь о том, как оптимизировать моделирование и разработку ИТ в необходимой и достаточной для ключевых показателей проекта степени - назовем это проблемой комплексного проектирования. Её суть в том, как упростить создание системы и её частей с помощью проектной документации.
Одна из задач, решение которой ведёт нас к этой цели - усиление связности, целостности множества проектных артефактов. И трассировка, о которой говорили выше - здесь лишь частный случай. Нам как аналитикам следует стремиться обеспечивать не только наличие и актуальность связей между документами с описаниями различных видов требований к системе, но и качество самой документальной поддержки этих требований.
Условно говоря, базовый минимум - когда функциональное требование обуславливается запросом целевых пользователей в соответствующей юзерстори, хорошо, если описана постановка на реализацию этой функции во взаимосвязи со смежным по юзкейсу функционалом, очень хорошо - описаны и привязаны к постановкам статусные модели и диаграммы классов используемых информационных сущностей, отрисованы схематичные макеты интерфейсов, описаны проверки данных при попытке записи результатов выполнения функции и отработка ошибок, связь с ролевой моделью прав доступа и логирование действий.
Опустим тяжёлый люкс. Важно, что количество само по себе не перейдет в нужное качество, в каждом проекте, в зависимости от целей и ограничений, придется искать свой баланс глубины и масштаба анализа и объёма техно-рабочей документации. Тем не менее, центральная идея останется прежней - минимально необходимыми средствами проектных артефактов дать ответы на максимально возможное число потенциальных системных "почему", в поддержку проектируемой информационной системы создать достаточно связную мета-систему - базу знаний ИТ-проекта.