Трассировка требований к ас полезна для

Трассируемость требований (англ. requirements traceability) — в дисциплине «управление требованиями» программной инженерии — возможность отследить жизненный цикл требований по устанавливаемому между артефактами требований бинарному отношению, в общем случае транзитивному и не симметричному. Трассирование — пошаговый анализ плана, сценария или алгоритма.

Трассируемость позволяет описывать и отслеживать связи между различными артефактами требований — бизнес-требованиями, системными требованиями в различных формах (в том числе в виде вариантов использования), а в широком смысле и артефактами процесса разработки вообще.

При этом транзитивность может быть проиллюстрирована следующим образом: допустим, имеется высокоуровневая бизнес-потребность заказчика, трассирующаяся на функцию системы, в свою очередь трассирующуюся на вариант использования. В этом случае очевидно, что изменение бизнес-потребности может оказать влияние не только на непосредственно связанную с ней высокоуровневую функцию, но и на вариант использования, с которым функция связана. Исходя из тех же условий, не симметричность трактуется следующим образом: изменение бизнес-потребности требует анализа изменений в связанной с ней функции, при этом обратное в общем случае не верно. В зависимости от конкретной модели требований, трассировка может иметь и отличные от описанных свойства.

Трассировка требований является ключевым компонентом процесса управления изменяющимися требованиями к системе, позволяющим с использованием данных о связях определить масштаб влияния изменения в одном из источников требований (например, изменении законодательства, пожеланий заказчика) на артефакты требований (варианты использования, спецификации и т.д.), артефакты разрабатываемой ОС вообще и, следовательно, характеристики проекта в целом. Таким образом, трассировка является инструментом управления рисками проекта, снижающим вероятность превышения сроков и бюджета проекта за счет недооцененного влияния изменений требований.

В этом смысле трассируемость является важным свойством, поддерживающим определение системы как компромисса между конкурирующими интересами заинтересованных лиц, так как именно конкуренция интересов является одним из основных источников изменений требований.

Кроме того, трассировка может использоваться для определения приоритетов нижестоящих требований (вариантов использования, функциональных требований) по приоритету вышестоящих требований, описывающих бизнес-потребности заказчика, тем самым позволяя планировать проект, обеспечивая приоритетную реализацию функциональности системы, наиболее важной с точки зрения бизнеса, а не «удобной» команде разработчиков для реализации.

Инструменты трассируемости требований используются и для выявления артефактов системы, не связанных с другими артефактами, что позволяет выявить недостающие «звенья» разработки. Например, возможно выявление вариантов использования, с которыми не ассоциировано сценариев тестирования.

В зависимости от конкретной реализации в методологии или программном пакете управления с требованиями, трассировка может реализовываться в виде нетипизированной связи между артефактами. В таком случае причинно-следственные связи отслеживаются исходя из типа артефактов, между которыми устанавливается трассировка.

В более сложном случае, связь может принадлежать к одному из предопределенных фасетов (например «тестируется с помощью», «вытекает из», «является частью»). Таким образом увеличивается гибкость возможных выборок по связям между артефактами, однако, это происходит за счёт существенного усложнения модели. Очевидно, что использование второго подхода может быть оправдано только для крупных проектов со сложной структурой требований.

Трассируемость может осуществляться как исключительно между различными артефактами требований, так и между артефактами проекта вообще. В этом случае трассировки объединяют артефакты требований, проектирования, реализации, тестирования, позволяя оценивать влияние изменений требований не только на другие артефакты требований, но и на архитектурные решения, сценарии тестирования, исходный код системы. Таким образом повышается точность оценки влияния изменений требований на проект в целом, что позволяет повысить его управляемость, снизить риски некорректной оценки изменений.

Вместе с тем, реализация такой модели требует высокого уровня интеграции всех компонентов среды разработки, высокой методологической дисциплины в команде разработчиков и, в итоге, ограничивает выбор средств разработки, а также вариативность расходов, увеличивая одновременно затраты на обеспечение процесса. Поэтому очевидно, что степень такого рода интеграции должна тщательно оцениваться для каждого конкретного проекта с учётом его индивидуальных особенностей.

Трассируемость требований в проекте может поддерживаться и без использования специализированных инструментальных средств, с помощью соглашений об именовании и соблюдения аналитиками формализованных процедур управления требованиями. При этом может использоваться функционал ПО общего назначения, например, механизмы управления структурой документа и составными документами, а также перекрестных ссылок и гиперссылок текстовых редакторов, функционал сортировки и фильтрации данных в электронных таблицах, механизмы настольных СУБД.

Такой подход, однако, предполагает дополнительные трудозатраты на поддержание трассируемости и ограничивает её применимость в проекте, а также резко теряет эффективность по мере увеличения масштаба проекта.

Ещё один подход к обеспечению трассируемости в рамках управления требованиями может заключаться в использовании различных баг-трекинговых и аналогичных систем. Такой подход предполагает подстройку подобных систем для целей управления требованиями, при этом встроенные механизмы выборок и генерации отчетов, поддержки рабочих потоков артефактов этих систем, а также механизмы обеспечения зависимостей могут обуславливать применимость этих средств для обеспечения трассируемости и управления требованиями вообще. Вместе с тем, функционал таких систем может накладывать свои, подчас существенные, ограничения на модель требований, а отсутствие интеграции со средствами визуального моделирования и редактирования текстовых артефактов требований также не служит экономии трудозатрат на поддержание модели.

Специализированные семейства программных продуктов управления жизненным циклом ПО обычно включают средства управления требованиями с поддержкой трассируемости. Отличительной чертой таких средств является включение или интеграция средств импорта требований из различных источников, поддержка визуального моделирования (в основном, на основе UML), тесная интеграция со средствами документирования. При этом автоматизирована работа с трассировками — анализ изменений и генерация отчетности о них (в том числе матриц трассировок), настраиваемые механизмы уведомлений заинтересованных лиц об изменениях, с учётом зон ответственности и зависимостей. В целом, такие средства позволяют снизить трудозатраты на поддержку механизма трассировок, при этом обеспечивая более гибкое их использование. Успех их применения, однако, как и многих других средств автоматизации, зависит от особенностей конкретного проекта, качеств команды разработчиков, степени зрелости процесса разработки ПО в компании в целом.

К специализированным средствам управления требованиями, поддерживающим трассируемость, относятся, в частности, средства Borland Caliber, IBM Rational RequisitePro, (IBM) Telelogic DOORS, Sparx Enterprise Architect, 3SL Cradle,

В рамках проекта Eclipse инициировано создание Open Source Requirements Framework, предназначенного для создания модели управления требованиями, а также инструментов на её базе.

источник

Одной из главных проблем сбора требований является проблема их изменения. Требования создаются итерационно путем постоянного общения представителей заказчиков с аналитиками и разработчиками будущей системы в целях выявления потребностей. Требования изменяются в зависимости от задач и условий их определения, а также постоянного уточнения на этапе заключения договора на создание системы. На момент заключения договора состав требований, их виды и свойства становятся более полными, т.е. соответствуют взглядам заказчика на создаваемую систему [3.4].

Одним из инструментов установления зависимости между сформулированными требованиями и их изменениями является трассировка, т.е. поддерживается развитие и обработка требований с прослеживанием идентифицированных связей, которые должны быть зафиксированы по двум направлениям — от источника требований к реализации и, наоборот (рис. 3.3.). Выявляются причины появления разнообразных неточностей, добавлений и определяется необходимость внесения изменений в требования в одном из приведенных направлений.

Если после разработки некоторого рабочего продукта возникает потребность в изменении отдельных требований или необходимость проследить за происхождением внесенных требований в одном из направлений данной схемы трассирования, то уточняются связи между отдельными требованиями и элементами рабочих продуктов В случае трассирования требований от продукта, движение в обратном направлении, т.е. — к требованиям, можно выяснить, как написана каждая строка этого продукта и соответствует ли она отдельным атрибутам требований. Связи трассируемости требований помогают найти незапланированные и реализованные некоторые функции или фрагменты программ, не соответствующие заданным требованиям. И, наоборот, выявить нереализованные требования к функциональности. Взаимосвязи и зависимости между отдельными требованиями сохраняются, например, в таблице трассируемости, удаляются или модифицируются при различных изменениях.

Методы трассировки базируются на формальных спецификациях связей между элементами требований либо ограничиваются описаниями функций, ситуаций, контекста и возможных решений. Основу трассировки составляют:

• требования, которые изменяются при их формировании;
• некоторые детали выполнения функций в рабочем продукте системы, которые не предусматривались, но появились в связи с возникшей практической ситуацией;
• связи между различными моделями процесса проектирования системы на ЖЦ программного продукта и принятые решения о необходимости изменения требований в связи с появившимися недостатками в промежуточном продукте;
• информация о согласованных атрибутах требований на разных уровнях рассмотренной схемы трассирования и сохранение ее матрице трассирования;
• специальные системные требования, касающиеся повторного использования готовых компонентов или частей системы;
• результаты тестирования, по которым можно определить наиболее вероятные части кода, требующие проверки на наличие в них дефектов.

В матрице требований в строках указываются пользовательские требования , а столбцах — функциональные требования, элемент проектирования, вариант версии и др. В этих столбцах заполняются данные о степени выполнимости системных требований на каждом элементе создаваемого продукта. Механизм ссылок в таблице позволяет проверять связанные с каждым элементом продукта диаграммы вариантов использования , потоки данных, классы и др.

Процедура трассирования состоит в следующем:

• выбирается элемент (функция, фрагмент или некоторая часть) из матрицы трассирования требований, за которым проводится прослеживание на этапах ЖЦ;
• составляется список вопросов, по которым на каждом этапе проверяются связи при реализации требований в продукте, и если изменяется какое-то звено в цепочке требований (рис. 3.3.), то может модифицироваться процедура разработки этого элемента на последующем этапе ЖЦ;
• проводится мониторинг статуса каждого требования на соответствие выполнения согласно принятому плану;
• уточнение ресурсов выполнения проекта при необходимости проведения изменений в требования и в элементы проекта.

Условием принятия решения о возможных модификациях требований и результатов промежуточного проектирования, является обновленная информация о связях между различными частями системы и первоначально заданными требованиями к ним. Трассировка обеспечивает:

• ввод более сложных отношений вместо простых связей или специфических отношений;
• использование разных путей трассировки (между моделями или иерархическими связями);
• ведение базы данных объектов трассировки и отношений между ними.

Трассировка может быть выборочной для отдельных объектов или связанной с другими объектами, а также с возможными переходами от одной модели проектирования к другой путем проверки трансформации одних объектов в другие.

В объектно-ориентированных подходах и методах разработки программных систем главным является объект . Объектно-ориентированный подход , в частности UML моделирование позволяет с помощью вариантов использования задавать требований. Основные средства UML к формированию и представлению требований к системе и к ПО — это use case сценарии или прецеденты.

Представленные сценариями или прецедентами требования к системе в UML , последовательно трансформируются к другим сценариям, приближающим к логической структуре системы. Главные элементы сценариев — это объекты, классы объектов и акторы, задающие действия по выполнению системы.

Одним из методов построения проектной модели системы, логической и физической моделей являются сценарии use case, используемые для визуального представления требований в проектной модели системы. Эта модель уточняется и дополняется новыми сценариями для получения логической и физической моделей. Термин сценарий обозначает некоторый вариант представления модели выполнения системы [3.1, 3.5].

При применении сценарного подхода общая цель системы декомпозируется на отдельные подцели, для которых определяются функциональные или нефункциональные требования и проектные решения. Цели, как источники требований к системе, позволяют выявить противоречия и ограничения на выполнение функций и установить зависимости между ними, устранить конфликты между целевыми функциями, а также объединить некоторые из них между собою в определенные отношения.

После выявления целей определяются носители интересов, которым отвечает каждая цель, и возможные варианты удовлетворения составных целей в виде сценариев работы системы, которые помогают пользователю получить представление о назначении и функциях системы. Это соответствуют первой итерации определения требований к разработке системы.

Далее производится последовательная декомпозиция сложной проблемы к виду совокупности целей, каждая из которых трансформируется в совокупность возможных сценариев использования системы, а затем в совокупность взаимодействующих объектов.

Т.е. имеем цепочку трансформаций:

проблема цель сценарий объект.

Она отражает степень концептуализации анализируемой проблемы, и ее декомпозицию с помощью вариантов использования для снижения сложности системы. Трансформация данной цепочки выражается в терминах базовых понятий проблемной области и активно используется для представления и развития моделей системы.

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

Актор — это внешний фактор и его действия, носящие недетерминированный характер. В роли актора может выступать и программная система, если она инициирует выполнение некоторых работ, удовлетворяющих поставленной цели системы. Актор, как абстракция внешнего объекта, может быть человеком или внешней системой. В модели системы актор может быть представлен классом, а пользователь — экземпляром класса. Если актором является другая

ПС, то он будет представлять ее интересы. При этом одно лицо может быть экземпляром нескольких акторов.

Если актор находится вне системы, то он взаимодействует с ней через сценарий, который инициализирует последовательность операций для выполнения системы. Когда пользователь, как экземпляр актора, вводит определенный символ для старта экземпляра соответствующего сценария, то это приводит к выполнению ряда действий в системе, которые заканчиваются тогда, когда экземпляр сценария находится или в состоянии ожидания очередного входного символа или завершения сценария

Экземпляр сценария существует, пока он выполняется и его можно считать экземпляром класса, он имеет состояние и поведение. Взаимодействие между актором и системой порождает новый сценарий или объект, которые изменяют внутреннее состояние системы. Если несколько сценариев системы имеют одинаковое поведение, то их можно рассматривать как класс сценариев.

При внесении изменений осуществляется повторное моделирование акторов и запускаемых ими сценариев. Сценарий — это цепочка событий, инициированных актором, и реакции на них. Каждого актора обслуживает соответствующая совокупность сценариев.

Можно выделить базовую цель событий, существенную для сценария, и альтернативную в случае ошибок пользователя и др. Для задания модели сценариев используется специальная графическая нотация со следующими правилами:

• актор обозначается иконой человека, под которой указывается название;
• сценарий изображается овалом, в середине которого указывается название иконы;
• актор связывается стрелкой с каждым овалом запускаемого им сценария.

Пример диаграммы сценариев для читателя библиотеки в роли актора, который запускает заданный сценарий при обращении к автоматизированной системе обслуживания библиотеки, представлен на рис. 3.4.

Все сценарии, которые включены в систему, обведены рамкой, определяющей границы системы, а актор находится вне рамки, являясь внешним фактором по отношению к системе.

источник

Независимо от уровня первоначальной проработки требований к проекту не стоит думать, что требования всегда будут оставаться неизменными. Необходимо быть готовым к тому, что в любой момент могут появиться новые требования , одни старые требования изменятся, другие — отпадут. Но основная сложность управления процессом изменения требований заключается не в этом, а в том, что изменения одних требований влияют на другие, и такие влияния нужно отслеживать. Влияние изменений требований естественным образом распространяется на все рабочие продукты проекта, в том числе на программные рабочие продукты .

Любое предложение по развитию конструируемой системы может быть классифицировано как требование одного из трех видов:

• дополняющее, которое отражает ранее не рассматривавшийся аспект системы;
• модифицирующее , которое изменяет одно или несколько уже существующих требований ;
• отменяющее , принятие которого исключает одно или несколько ранее принятых требований .

Вид требования отражает различия анализа нового требования в контексте существующих соглашений. Целью такого анализа является поддержка целостности системы требований : нахождение противоречий между требованиями , разрешение противоречий , а при невозможности этого — достижение приемлемых компромиссов . Следует отметить, что требования могут оказаться противоречащими не только друг другу, но и уже принятым проектным решениям. В работах с меняющимися требованиями значительное место занимает отслеживание связей проекта, благодаря которому определяется деятельность , необходимая как для реализации требований , так и для распространения изменений , связанных с требованиями к проекту.

Таким образом, вопрос о том, принять или отклонить требование , является очень ответственным, зачастую влекущим за собой цепь связанных решений на всех уровнях проектирования. Чтобы сделать ответ на него обоснованным, необходимо выполнение как минимум двух условий:

• требования должны быть заданы в виде, допускающем однозначное представление в моделях уровня анализа и конструирования, и способ такого представления должен быть унифицирован для всего проекта;
• в проекте должны инструментально поддерживаться связи между требованиями и между требованиями и другими компонентами рабочих продуктов, и эта поддержка должна быть обеспечена.

Представление требований и пожеланий, исходящее от инициаторов работ , ни в коей мере не способствует соблюдению указанных условий. Следовательно, они должны быть трансформированы, т.е. преобразованы к виду, приспособленному для анализа. Прохождение исходного требования через последовательность трансформаций от одного представления к другому, сопровождающееся соответствующим анализом, называется трассировкой требования . Основное назначение трассировки в том, чтобы в любой момент развития проекта сохранялась целостность и непротиворечивость конструируемой системы, реализующей принятые требования 1 Следует обратить внимание, что целостность и непротиворечивость — не характеристика принимаемых требований, а качества, которыми должна обладать конструируемая система. Противоречия предъявляемых требований есть следствие различий интересов инициаторов работ , очень часто именно они становятся стимулом для поиска новых решений, для перехода от одной версии системы к другой, т.е. являются источником развития системы (см. предыдущий раздел). .

Трассировка — основа анализа, проводимого в рамках управления изменениями требований . В первую очередь трассировке подвергаются требования , предъявленные первоначально, т.е. до того, как проект начал развиваться. Но было бы неправильно ограничиваться только ими, поскольку связи новых требований с уже сложившейся системой требований , как явные, так и обнаруживаемые в ходе анализа, также требуют соответствующего анализа и других работ , необходимых для реализации. Это, а также то, что для отбора и анализа требований , поступающих в ходе работ над проектом, появляется дополнительный критерий реализационной совместимости с принятыми требованиями , отличает трассировку новых и первоначальных требований .

В результате трансформаций строятся представления требований , вид которых приспособлен для выяснения целесообразности реализации требований . Если на некотором уровне трансформаций установлено, что данное требование отвергается, то его дальнейшие преобразования не производятся. Выделяются следующие представления требований :

1. Исходное представление — текстовое описание пожеланий к системе, заданное в свободной форме. Это описание, в частности, может фактически содержать несколько требований , отражающих разные аспекты проекта, — элементарные составляющие требования .
2. Унифицированные представления — исходное представление требования разбивается на элементарные составляющие, которые описываются в базовом виде, приспособленном для дальнейшего использования на всех проектных уровнях. В частности, здесь могут применяться формализованные описания элементарных составляющих требования . Во всяком случае, на уровне унифицированного представления достигается однозначность понимания требований .
3. Типизированное представление — каждое из элементарных составляющих требования приписывается к некоторому типу. В результате формируется набор атрибутов элементарных требований и их значений. Эта информация допускает почти формальное сопоставление элементарных требований с различными требованиями , уже представленными в проекте. Сопоставление проводится на разных уровнях иерархии типов требований к системе.
4. Модельные представления уровня анализа — образы элементарных требований как элементы аналитических моделей системы. Если следовать RUP (похоже, что сегодня это становится общепринятым), то нужно говорить о моделях ситуаций использования и динамики взаимодействий, которые применяются для оценки требований .

Подчеркнем, что в п. 4 говорится именно об элементах моделей, поскольку сами модели, как правило, отражают, пусть даже фрагментарно, сразу несколько требований . Это же относится и к последующим представлениям требований . Для трассировки важно знать, какие модели и в каких частях затрагивает то или иное требование , что позволяет отслеживать связи, возникающие при трансформации требований . Не менее существенно иметь возможность оперативно получать соответствующую информацию о текстах программ и о документации.

Если требование принимается на уровне анализа, то трассировка продолжается на следующих уровнях и можно говорить о продолжении последовательности трансформаций в реализации требования в компонентах программного изделия:

Схема на рис. 12.1 иллюстрирует приведенную последовательность трансформаций. Первые три представления требований изображены в виде совокупностей стрелок, которые при переходе от одного представления к другому становятся все более упорядоченными.

Иерархия типов требований представлена на рисунке следующим образом. Верхний уровень — это абстрактный тип, свойства которого присущи требованиям всех типов (они сводятся к стандартизованному набору операций объединения, пересечения атрибутов, сравнения значений атрибутов и др.). Можно сказать, что Т_абстр задает регламент, которого следует придерживаться при оперировании требованиями . Следующий уровень содержит четыре обязательных типа: Т_экон, Т_функ, Т_инт и Т_эфф , которые объединяют требования экономического характера (пределы стоимости, рентабельность и пр.), функциональные требования , требования к интерфейсу и эффективности (производительности). Многоточием обозначены типы, которые, добавляются из-за специфики проекта. Т_a(a1. an_a), Т_b(b1. bn_b), Т_c(c1. cn_c), . Т_z(z1. zn_z) — это конкретные типы, которым приписываются элементарные составляющие требований (в скобках указаны их атрибуты).

Модельные представления уровней анализа и конструирования изображены в виде условных схем различных видов. Программные и документные представления — это текстовые файлы , пиктограммы которых показаны на рисунке.

На схеме представлен блок, обозначающий глоссарий проекта . Это очень важный инструмент согласования понятий, используемых в программной разработке. Глоссарий может пополняться на любой стадии трассировки требований , когда появляются новые понятия, смысловую трактовку которых нужно зафиксировать. Тем самым глоссарий отражает текущее понимание проекта в целом. Важно подчеркнуть, что когда разработчики не занимаются ведением глоссария , система понятий проекта все равно складывается, но стихийность этого процесса приводит к дополнительным издержкам коммуникаций сотрудников.

Приведенная схема демонстрирует, что в той или иной форме вынуждены делать разработчики для преодоления трудностей управления требованиями . Она может рассматриваться в качестве проекции жизненного цикла на задачи анализа требований . Каждое требование , поступающее для анализа, проходит вполне традиционные этапы жизненного цикла , правда, в несколько специфичном виде: учитываются только те работы, которые имеют отношение к моделированию требований . Но эта абсолютизация трассировки не является недостатком. Напротив, явное выделение задач управления требованиями уже само по себе способствует более успешному их решению.

источник

Очень часто во время реализации проекта разработки ПО требование не удаётся связать с заинтересованным лицом, отсутствует важная функциональность, или же в конечном продукте появляются ненужные функции — и все это «без трассировки.» То есть отсутствует поддающаяся обнаружению связь между работой, имеющей отношение к этой конкретной функции, и реальной потребности в этой функции. Однако понятие «трассируемость» напрямую связано с качеством производимого продукта. К сожалению, трассируемость часто остается без должного внимания.

На самом деле, мой опыт оказания консалтинговых услуг показывает, что ни один аспект разработки технических требований 1) так часто не упоминается как важнейшая составляющая деятельности разработчика и 2) так часто не игнорируется на практике. 1 Я выскажу свои предположения, почему это происходит. Затем я предложу несколько передовых методов устранения этих причин. Хотя трассируемость применяется для других дисциплин универсального процесса Rational (RUP) — и существует множество других параметров, которые надо отследить, например расхождения, допущения и риски — в этой статье в основном рассматриваются технические требования.

Этот материал рассчитан на тех, кто обладает общим пониманием, что такое разработка технических требований, а в идеале — знаком с вариантами использования.

Давайте начнем с теории, которая лежит в основе трассируемости технических требований.

Что такое трассируемость?

В соответствии со стандартным компьютерным словарем IEEE Standard Computer Dictionary 2 трассируемость определяется как «степень, с которой установлено отношение между двумя или более продуктами в процессе разработки, особенно продуктами, состоящими в таких отношениях как предшествующий-последующий элемент или ведущий-ведомый.»

Rational Unified Process (RUP) определяет понятие трассируемости более общим способом, как «способность соотнести какой-либо элемент проекта с другим, связанным с проектом элементом, особенно с теми, которые имеют отношение к техническим требованиям.»

Как вы можете видеть, «трассируемость» является очень широкой концепцией, которую легко понять. Проблема, однако, состоит в том, что большинство людей тут же представляют себе очень простую иерархическую структуру с четко определенными уровнями и иерархическими отношениями. Но когда реальность оказывается более сложной, невежество (или его современный аналог — слепое доверие программным средствам) заменяет здравый смысл, дисциплину и привычку следовать некоторым основным правилам. Как следствие, информация о трассируемости или вообще не фиксируется, или делается это весьма неохотно. Таким образом, теряется возможность улучшить качество и мгновенно реагировать на изменения. Как это предотвратить? Чтобы ответить на этот вопрос, нам нужно сначала понять, зачем нам требуется трассируемость? Какая от нее польза?

Трассируемость служит двум основным целям:

1. Обеспечению качества продукта через придание ему всех тех возможностей, которые затребовал заказчик, а также обязательное отсутствие тех качеств, которые не были им запрошены («создание правильного продукта»). Другой аспект качества заключается в обеспечении правильного функционирования всех затребованных возможностей («Построение правильного продукта»). Параметр «достоверность» 3 трассирует различные уровни абстракции или детализации во время разработки относительно друг друга. Трассировка «верификации (формальной правильности)» отслеживает требования, анализ и реализацию рабочих продуктов по сравнению с соответствующими тестами. Эти два параметра — «достоверность» и «формальная правильность» трассируемости по отношению к основным дисциплинам RUP проиллюстрированы на рисунке 1.
2. Анализу влияния изменений через определение затронутых требований, проектных решений и артефактов реализации, а также связанных с ними тестов.

Рисунок 1: Аспекты трассируемости

Кроме достижения этих двух целей существует ощутимая побочная польза, в основном связанная с улучшением отчетности и оценки статуса проекта: 4

• Каков процент реализованных требований?
• Каков общий процент удачно реализованных (то есть протестированных) требований?
• Какое количество тестов на приемлемость для пользователя мне необходимо провести, если я изменю некоторые параметры реализации?

Но после того, как мы поймем эти преимущества, как мы будем добиваться внедрения трассируемости? Следующие разделы посвящены трассируемости технических требований в терминах понятия «достоверности» трассируемости, упомянутой выше.

Необходимым предварительным условием для трассировки является четкое определение типов требований. Типы требований — это классификации требований на разных уровнях детализации или абстракции, наиболее часто используемые из них «значимые запросы,» «функции,» «варианты использования,» и «дополнительные требования» (для вводной информации см. примечание 2). Каждый раз, когда вы документируете требование, оно должно принадлежать определенному типу требований.

Кроме типа требований, необходимо определить иерархию, а точнее — набор валидных отношений между типами требований. Это отношение определяет, с каким типом или с какого типа требований трассируется 5 другой тип требований. Нужно знать о некоторых сложностях:

• Один тип требований может трассироваться более чем с одним другим типом требований. Например: функция представляет взгляд на возможности системы. Вариант использования представляет цель с точки зрения конечного пользователя. Варианты использования покрывают главным образом функциональные требования, и поэтому дополнительные требования используются для фиксирования технических требований, которые не лучшим образом записаны в формате конкретного варианта использования. Поэтому функцию можно трассировать с вариантом использования или дополнительным требованием (см. рисунок 2).
• Экземпляр типа требований может трассироваться с многочисленными экземплярами другого типа требований (или наоборот, на него может ссылаться другой тип требований). Например: какая-то функция может трассироваться со многими вариантами использования, но и на вариант использования могут также ссылаться многие функции, что в результате приведет к отношениям «многие с многими», как показано на рисунке 2. 7

В основе иерархии технических требований лежат запросы заинтересованной стороны, которые можно отнести к отдельному пользователю, чьи запросы оцениваются в рамках проекта.

Тип требований и их отношения, вместе взятые, называются стратегией трассируемости. Она должна быть определена заранее и задокументирована в Плане управления техническими требованиями (стандартный рабочий продукт RUP). Чтобы техническое условие было трассируемым, оно должно быть доступно для рассмотрения — то есть оно должно быть определено недвусмысленно на протяжении всего жизненного цикла и в различных рабочих продуктах.

Рисунок 2: Трассируемость отношений

Технические требования трассируются эксплицитно и имплицитно. Эксплицитная трассируемость требует от вас вручную установить отношение между двумя типами требований. Имплицитная трассируемость является результатом внутренне присущих отношений между трассируемыми объектами (то есть вашими типами технических требований) — например, по-настоящему иерархичными требованиями или через автоматически применяемые трансформации к вашим рабочим продуктам 8 .

В большинстве случаев трассируемостью управляют эксплицитно.

Существуют различные подходы к установлению эксплицитной трассируемости. Отношения логической трассируемости между двумя техническими требованиями, представленными их идентификаторами, могут быть физически достигнуты различными способами. Наиболее типичны следующие:

1. В рамках требований к рабочим продуктам, в месте, где определяется требование (например, в перекрестных ссылках).
2. В рамках требований к рабочим продуктам, в специальном разделе (например, в таблицах перекрестных ссылок).
3. Вне требований к рабочим продуктам (например, через электронные таблицы, настроенные базы данных или специальные инструменты управления требованиями).

Вариант 1 часто называется «навязанная трассируемость,» так как требование и трассируемость определяются в одном месте. Варианты 2 и 3 называются также «ненавязанная трассируемость,» так как трассируемость поддерживается отдельно от требования.

Давайте быстро оценим различные варианты: вариант 1 отбрасываем сразу. Такой документ не только очень быстро становится сложно поддерживать, читатель отвлекается на информацию о трассируемости внутри текста, поэтому этот документ трудно читать. Более того, трассируемость — не единственная метаинформация, которую необходимо зафиксировать для технических требований. Необходимо также поддерживать другую информацию, например о приоритетности, статусе или рисках. Вариант 2 представляет компромисс и может, если стратегия обеспечивает трассировку с объекта только внутри документа или к стабильным документам. Это делает вариант 3 наиболее приемлемым подходом к трассируемости. Таблицы, конечно, удлиняют работу, однако специальные инструменты управления требованиями, например IBM Rational RequisitePro, созданы как раз для управления этим типом информации.

Как вы можете видеть, в большинстве случаев внедрение трассируемости предполагает ручную работу. Соответственно анализ по критерию «затраты-выгода» является основным аргументом для реализации правильной стратегии трассировки.

Сначала нужно иметь требование. Требование может возникнуть различными способами, но за написание требования, создание идентификатора и внедрение трассируемости отвечает человек, 9 который документирует требование.

Принимая во внимание то, что основные правила внедрения и поддержки трассируемости просты, кажется трудно понять, почему множество проектов пренебрегают трассируемостью. Этот симптом часто оправдывают такими причинами, как «слишком большие усилия» и «выгоды не очевидны.» Это можно объяснить следующими основными причинами:

1. Для проекта не была определена работающая и согласованная стратегия трассируемости.
2. Трассируемость не рассматривается как неотъемлемая часть разработки технических требований.
3. Усилия затрачены, но выгода не осознается

Ниже представлены некоторые из лучших приемов по устранению одной или нескольких их указанных выше причин.

Установите соответствующий уровень трассировки. Не переоценивайте свои силы. Я видел проекты, в которых пытались осуществлять трассировку до уровня детализации, который не соответствовал ни временным рамкам, ни конкретному варианту использования. В своем первом проекте не пытайтесь выполнить трассировку до уровня конкретного варианта использования. Вы должны иметь хорошо продуманную стратегию трассируемости и оправдание для своих (огромных!) усилий. [1]

Распределяйте ваши усилия равномерно. Включите внедрение трассируемости в документирование технических требований. Не превращайте это в отдельное действие. Зачастую если это действие откладывается, и даже если оно откладывается только для определенного набора требований, трассируемость становится несистематической и поэтому бесполезной. [2, 3]

Применяйте контроль качества по отношению также и к трассируемости.. Когда вы выполняете проверки или обзоры, проверьте трассируемость. Она может быть и неправильной. Прежде всего контроль качества обеспечивает наличие трассируемости, а уж затем подтверждается её правильность до начала её применения, что увеличивает вашу уверенность при её использовании. [2, 3]

Отрегулируйте и заново пересмотрите вашу стратегию трассируемости. Нельзя ожидать, что стратегия трассируемости, которая была удачно использована в прошлом, может оставаться правильной навсегда. Выполнение проектов приводит к организационным изменениям. Типы проектов различны. Разным проектам требуются различные типы требований и/или различные типы отношений, определяемые для трассируемости. Переход от разработки собственными силами для внутренних нужд к проекту интеграции с посторонним поставщиком вероятно приведет к появлению новой документации. Переход от чисто традиционного (декларативного) способа формулирования технических требований к подходу, основанному на конкретном варианте использования, влечет за собой введение новых типов технических требований. Ваша стратегия трассируемости должна отвечать этим изменениям 10 . [1]

Занимайтесь повышением квалификации вашей команды. Трассируемость является результатом коллективных усилий. Команда, ответственная за организацию выполнения проекта, должна быть соответствующим образом подготовлена к определению подхода к трассируемости для проекта. Им нужно понимать и ценить то, что одинаково важно как трассировать требование к его источнику, так и написать хорошее определение требования к качеству. [1, 2]

Приведите контрпример. Если имеется участник проекта со стороны, занимающийся потребностями в трассируемости вашего проекта, позвольте этому сотруднику провести анализ последствий для следующего запроса на изменение. Это может оказаться более понятным. [2, 3]

Если у вас есть сомнения, сделайте меньше, но должным образом. Лучше придерживаться хоть какой-то стратегии трассируемости, чем иметь незавершенную. Последняя требует усилий, но вряд ли принесет пользу. Первая надежна до уровня детализации, определенного в стратегии трассируемости, и если потребуется, может быть расширена при дополнительных затратах и посредством специального, хорошо спланированного процесса. [1]

Продумайте все как следует, но превращайте это в лишнюю проблему. Будьте прилежны и внимательны при определении информации о трассируемости, но не позволяйте трассируемости стать основным предметом обсуждения на собраниях вашей группы (или «жить ей своей жизнью»). Закон Парето применим также и к поддержке трассируемости. Если же вы сомневаетесь, в тех случаях, когда аргументы можно интерпретировать двояко, внедрите цепочку трассируемости. Это будет преимуществом в комплексном анализе последствий, обеспечивающим нахождение всех связанных разработанных требований. [1]

Усильте структуру ваших требований, чтобы она поддерживала трассируемость. Трассируемость не должна определять способ, которым вы документируете требования. Но часто документы с хорошо структурированными требованиями поддерживают трассируемость более естественным образом. Например:

Функция, обеспечивающая, чтобы «общяя сумма всех неоплаченных счетов клиента не превышала предельную сумму кредита», может быть отнесена к некоторому количеству вариантов использования, например «(Клиент) Размещение заказа» или «(Менеджер бюджета) Регулирование лимита кредита», как этап с каком-либо варианте использования. В качестве альтернативы её можно задокументировать в описании базового понятия «Клиент» как ограничение. Это не только делает документирование удобнее, есть возможность улучшить также и трассируемость. Вместо того, чтобы выполнять трассировку с многочисленными этапами вариантов использования, можно выполнять трассировку с одним базовым понятием «Клиент», и этого будет совершенно достаточно; или же, с более точным уровнем детализации, можно выполнять трассировку с атрибутом «общее количество всех неоплаченных счетов» 11 . [1, 3]

Усильте инструментальную поддержку. Инструменты не являются панацеей. Они не устраняют необходимость принимать решения относительно стратегии трассируемости, и не могут подтвердить, правильная ли трассировка и завершена ли она. Тем не менее, инструменты управления требованиями, такие как IBM Rational RequisitePro, позволяют вам:

• Легко внедрять и поддерживать трассируемость по всему набору определенных требований любым ненавязчивым способом
• В некоторой степени усиливать определенную стратегию трассируемости
• Поддерживать распространение изменений по всей иерархии требований посредством определения требований, которые могут быть затронуты изменениями, основываясь на установленной трассируемости
• Выполнять визуализацию и составлять отчёты о трассируемости (см. Рисунок 3).

Следовательно, эти возможности RequisitePro сокращают общее количество ручной работы и увеличивают надежность трассируемости. [1]

Как вы можете видеть, существует некоторое количество контрмер, которые можно предпринять, чтобы сделать трассируемость более доступной, что улучшит соотношение между затратами и пользой, и поэтому сделает трассируемость возможной изначально.

Рисунок 3: Матрица трассируемости, доступная в IBM Rational RequisitePro, позволяет выполнять визуализацию и составлять отчёты о трассируемости.

Итеративный и поэтапный способ осуществления проектов, который предвосхищает и позволяет вносить значительные изменения в проект, значительно увеличивает потребность в трассируемости по сравнению с традиционными методами разработки программного обеспечения. Поэтому любые потенциально высокие, заранее определенные затраты гораздо легче возвращаются в ходе проекта (см. врезку). Способность трассировать свои требования корректно является важнейшим условием управления совместимостью в вашей корпоративной среде. Трассируемость является важнейшим понятием Модели зрелости процессов разработки (Capability Maturity Model).

Чтобы преуспеть в трассируемости, выбирайте соответствующую стратегию трассируемости заранее, четко документируйте и передавайте ее, и при помощи проверок убедитесь, что стратегия трассируемости реализована и работает. Это позволит вам получить выигрыш в качестве продуктов и управлении изменениями.

Проект близится к концу. Менеджер проекта получает запрос на изменение, за которым следует телефонный звонок спонсора с просьбой быстро оценить влияние этого запроса. Соответствующий запрос позволяет быстро установить «частоту цикла очистки.» Менеджер проекта вызывает системного аналитика, ответственного за этот аспект работы системы. Системный аналитик получает соответствующие документы о требованиях и задаёт в поисковой машине некоторые ключевые слова, относящиеся к этому требованию: «‘цикл очистки’, частота.» Менеджер проекта выглядит немного обеспокоенным и спрашивает: «Почему вы не используете матрицу трассируемости», которая существовала в какой-то момент в проекте. Системный аналитик быстро отвечает, что «сегодня никто не ведет эти таблицы, поэтому я им не доверяю!»

Мораль всей этой истории такова: трассируемость не может быть внедрена «наполовину». Если вы не доверяете информации о трассируемости, лучше всего не тратьте на неё свои усилия.

1 Если это не предписывается правилами, установленными, например, такими организациями как Министерство обороны или Управление по контролю за продуктами и лекарствами.

2 Институт инженеров по электротехнике и радиоэлектронике. Стандартный компьютерный словарь IEEE: компиляция стандартных глоссариев IEEE по компьютерной технике. Нью-Йорк, NY: 1990 г.

3 Иногда трассируемость «формальной правильности» также называют трассируемостью «разработки», так как она представляет направление, в котором разрабатываются и совершенствуются типы требований (или рабочие продукты в целом). К сожалению, название совпадает с фазой разработки RUP.

4 Часто эти отчеты содержат также и другую метаинформацию требований, например приоритетность и риски, чтобы поставить в контекст «точное число в процентах».

5 Как можно видеть из использованной терминологии («трассировать с» и «трассировать от»), нам часто нужно использовать трассируемость в обоих направлениях для того, чтобы достигнуть цели трассируемости, то есть нужно иметь ответы на такие вопросы как «Реализована ли функция?», смотря сверху вниз (трассировать с), и вопросы типа «Как это влияет на результат, если мы не можем реализовать этот вариант использования?», смотря снизу вверх (трассировать от). Хорошая новость состоит в том, что вы можете создавать одно направление из другого.

6 То есть «или» в смысле «и/или», а не «или/или.»

7 Относительно рисунка 2: существует более элегантный способ смоделировать ограничивающие условие через обобщение, но эксплицитное ограничивающее условие имеет большое значение.

8 Примером для иерархических отношений была бы трассировка от одних вариантов использования с этапами других вариантов использования, поддержанная соответствующей идентификацией. Трансформация является понятием из подхода архитектуры, управляемой моделями (model-driven architecture — MDA), при котором одна модель транслируется в другую. Это, однако, более применимо на практике в областях проектирования и реализации. См. более детальную информацию о MDA на сайте OMG Website: http://www.omg.org/mda/

9 В больших проектах отдельные роли могут выполняться несколькими людьми, поэтому отношения внутри команды должны быть прозрачными.

10 Прекрасный анализ различных стратегий трассируемости, их преимуществ и недостатков может найден в техническом описании Спенса и Пробаско «Стратегии трассируемости для управления требованиями в конкретных вариантах использования», 1998 г., которая до сих пор доступна в последней версии RUP. Я настоятельно рекомендую эту статью каждому, кто отвечает за определение потребностей в трассировке для проекта, в котором применяется подход к требованиям, основанный на конкретных вариантах использования

11 На самом деле вы можете достигнуть некоторого уровня имплицитной трассируемости (основанной на именах), через определение соответствующих базовых понятий, например «клиент» и «открытый счет» := «общее число неоплаченных счетов.» Вы, таким образом, можете выполнять трассировку с вариантами использования, применяя эти базовые понятия.

12 См. Rational Business Driven Development for Compliance, IBM Redbook, SG24-7244-00, 18 октября 2006 г. (черновик).

• Иен Спенс и Лесли Пробаско, «Стратегии трассируемости для управления требованиями с вариантами использования,» 1998 г., авторитетная статья, которая до сих пор доступна в последней версии RUP
• Дин Леффингвелл, «Функции, варианты использования, требования. О, Боже!,» в The Rational Edge, декабрь 2000 г.
• Леффингвелл и Уидриг, Управление требованиями к программному обеспечению, Addison Wesley, 1999 г.
• Для получения более детальной информации об архитектуре, управляемой моделями см. http://www.omg.org/mda/
• Rational Business Driven Development for Compliance, IBM Redbook, SG24-7244-00, 18 октября 2006 г. (черновик).

Особая благодарность моему коллеге Мартину Эллиффу за ценные комментарии и предложения.

источник

Публикуем доклад Печенкина Григория с предыдущей конференции Analyst Days 2013.

В части обеспечения профессиональными инструментами, аналитики представляют собой наиболее угнетённый класс по сравнению с другими участниками разработки ПО. Аналитики привыкли к этому и часто даже не задумываются о том, как часто в своей работе им приходится использовать неудобные и неэффективные «костыли». Кроме того, аналитику обычно приходится полностью менять свой инструментарий при смене работы, так как построенные на этих «костылях» системы почти всегда оказываются уникальными и не переносимыми.
В докладе будут рассмотрены некоторые типичные костыли и грабли систем управления требованиями, а также высказаны пожелания о том, каким должен быть инструмент мечты аналитика.

Мы рассмотрим затычки, костыли и грабли систем управления требованиями (СУТ) для того, чтобы понять, чего я хочу от систем управления требованиями. В начале сделаю 2 объявления.
В одном из анонсов доклада, который предварительно рассылался, говорилось о том, что будет сделан фундаментальный обзор СУТ. Обзора не будет. На самом деле была такая идея: несколько реальных задач СУТ пропустить через несколько систем, но когда я за это взялся, то понял, что сильно переоценил свои силы (позже я скажу, почему). Хорошая новость в том, что у меня есть, куда вас послать :).

В прошлом году в Киеве проходила конференция REQ Labs, где отлично была реализована идея: аналитические поединки. На конференции присутствовали три эксперта, которые, в отличие от меня, хорошо знают СУТ, потому что они постоянно ими пользуются и проводят тренинги. В процессе работы конференции перед экспертами ставилась реальная задача работы с требованиями, и они демонстрировали, как это делается в разных системах. Было предложена работа с тремя системами: RequisitePro, Enterprise Architect, Sybase PowerDesigner. Если этот вопрос кого-то заинтересовал, видеозапись есть на сайте компании REQ Labs (http://www.req-labs.ru/conf2012/agenda/530/).

Второе объявление (см. скриншот 2 презентации) уже относится к анонсу, который я напечатал в программе.

А именно, я написал, что аналитики самый угнетенный класс среди IT-специалистов, потому что у них нет хороших инструментов. Но в процессе написания доклада я понял, что у аналитиков наоборот, слишком много хороших игрушек, в которые никто больше просто не хочет играть. Проблема в этом, и о ней сейчас будет вестись речь. Я расскажу, почему возникла идея доклада, и какая проблема возникла перед аналитиками.
Я не являюсь профессиональным аналитиком. Я был программистом, потом менеджером, сейчас моя должность называется – аналитик – и, получается, я с чистой совестью могу сказать, что стал аналитиком. Но был период, когда я раз в год менял работу. Работал в трех разных местах. В одной компании я работал техническим директором. Компания была небольшая, всего пять человек. В другой компании – она была больше и состояла из тридцати человек – я руководил направлением. Сейчас я работаю на проекте по разработке банковской системы. И каждый раз заказчик (работодатель) передо мной ставил проблему внедрения системы управления требованиями (СУТ) и требовалось выбирать, какие инструменты использовать. Статья посвящена именно теме, с какими проблемами мне пришлось столкнуться, и выводам, к которым я пришел в процессе данной работы.
В основном на проектах пользуются такими СУТ: Excel Word, Polarion, Enterprise Architect, TFS, Wiki, Caliber, Jira.

Во многих компаниях до сих пор используется пакет MS Office для разработки и управления требованиями. К тому же, сейчас все больше распространяется Sharepoint, т.к. он позволяет внести некоторый порядок в хаос документов Office, плюс есть возможность вести версионный контроль и сравнение. Данная система позволяет на базе существующих наработок компании, которые они вели до этого в Word и Excel, организовать что-то похожее на СУТ. И плюс добавляют к этому веб-интерфейс, в котором можно программировать (сейчас, я знаю, программисты Sharepoint являются самыми востребованными и самыми высокооплачиваемыми, и если вы не знали, то рекомендую изучить эту программу на всякий случай). Рассмотрим и другие системы.

У всех на слуху программа Sparx Enterprise Architect, который позволяет моделировать всё, что угодно. Специализированные средства разработки – IBM Rational RequisitePro, есть и другие. Перечисленные инструменты предназначены именно для разработки требований.
Есть также инструменты командной работы – ALM (Application Lifecycle Management). Сейчас очень активно набирает популярность MS TFS (Team Foundation Server). Я сам его очень люблю и работаю с ним постоянно. Это разработка компании Microsoft — система управления «всем» в команде, другими словами, инструмент командного взаимодействия.
Средства Wiki также набирают популярность. Wiki обычно интегрируют с task-tracker’ами, самой распространенной из которых является система Jira. Я работаю в компании, где используется средство Confluence Wiki в связке с TrackStudio. Есть еще варианты, например MediaWiki с Bugzilla.
На самом деле, что из этого списка предназначено для управления требованиями? Чтобы ответить на этот вопрос, нужно ответить еще на один вопрос: в чем разница между разработкой и управлением требованиями.

Вы, наверное, слышали о модели зрелости CMMI (Capability Maturity Model Integration). В данной модели управление требованиями относится ко второму уровню, а разработка требований – к третьему уровню, т.е. разработка требований – это процесс более высокого уровня, соответствующего более зрелому процессу в компании.
На самом деле, это вообще разные процессы. Разработка – это то, чем занимаются аналитики (или люди, которых обычно называют аналитиками). А управление – это то, чем обычно занимаются менеджеры: взаимосвязь требований с разными рабочими артефактами: тест-кейсы, задачи, код, и др. В конечном итоге, они увязывают всё, что разрабатывает команда, с требованиями. На их основе отслеживаются статусы, трассировки и т.д.
С моей точки зрения, все эти процессы неразделимы (хоть и в CMMI это не совсем так). Проблема в том, что для аналитиков создаются инструменты именно для разработки требований, а для остальной команды – инструменты для управления требованиями. В попытке их состыковать и происходят проблемы. Прежде чем мы перейдем к аналитике, давайте определимся с терминами: грабли, костыли, затычки.

Что такое «грабли»? Граблями я называю какие-то элементы, унаследованные из других отраслей, применение которых создает проблемы. К примеру (этот пример сейчас не очень актуален, но 10 лет назад, когда все разработки велись в Word – это было очень актуально), требованиям присваивается какой-то идентификатор (средствами Word в тексте), на который мы в другом месте ссылаемся, потом изменяем исходный текст, вследствие чего меняется и номер, и дальше вся структура связей ломается. Надеюсь, что у вас нет таких проблем.
На текущий момент базы данных справились с этой проблемой: более или менее. Все мы знаем, что идентификатор присваивается сейчас по-другому. Этот случай я привел в качестве примера граблей. На самом деле, в других отраслях такую идентификацию используют и сейчас: юристы, бухгалтера, когда оформляют договор, потом к нему дополнительное соглашение, которое ссылается на какой-то пункт договора. Или, например, выходит Закон или изменения к Закону, ссылаясь на определенный пункт к Закону. В реальном мире это работает, но попытка применить это в IT – это перенос старого опыта или грабли, на которые кто-то наступил и наступает вновь.
Что такое «костыли»? Это очень распространенный термин в IT – подпорки или временные решения. Как пример, любая интеграция одной системы с другой является костылем: одна система не способна что-то решать, другая система тоже не может делать что-то, и для того чтобы их сынтегрировать, приходится строить костыли.

Что такое «затычки»? Затычки возникают в случаях, когда программа должна выполнять определенные действия сама, но перекладывает эти действия на вас. Очень распространенное явление. Все юзабилити состоит из затычек. Существует даже анекдот про «узбекский вирус».

Анекдот. По электронной почте к вам приходит письмо, в котором написано: «Здравствуйте, я «узбекский вирус». Мой разработчик не успел меня дописать, поэтому, пожалуйста, отправьте меня по всей адресной книге и отформатируйте диск С. Спасибо.»

Многие программы ведут себя именно так, но мы просто к этому привыкли и даже не обращаем на это внимания. Итак, я дал определения терминам, продолжим дальше тему.

Я предлагаю рассмотреть пример проекта, над которым работаю в данный момент, – это проект внутренней разработки. Я разрабатываю требования в Confluence Wiki (после того, как не смог выбрать нормальный инструмент в рамках своего исследования).
Для примера я выбрал достаточно примитивный старый вариант. Для разработчика я даю такую страничку: контекст в составе диаграммы вариантов использования инструмента (для того чтобы они понимали, для чего этот проект создается). Потом текстом описываются какие-то конкретные требования.

В данном проекте разрабатывается визуальная панель, с нее пользователи могут выполнять некоторые операции (я указываю те операции, которые должны реализовать). И далее дается макет интерфейса – представление о том, как это все должно выглядеть.

Опыт показал, что вот такая страничка для разработчиков – это нормально. Они понимают, что они делают панель, которая будет выглядеть примерно так (в примере предложен не реальный интерфейс, а прототип), перечислены фактические требования, что они должны сделать, и некоторые контекстные представления в виде диаграммы.
Конечно, возникает вопрос: «В какой программе, кроме Wiki такое представление можно сделать еще?» Word мало чем отличается. Но позже вам станет понятней, почему я выбрал именно Wiki.

Я обратил ваше внимание на то, что управление требованиями – процесс, который затрагивает интересы всей команды. Вы, как аналитик, разрабатываете требования, потом эти требования используются разными людьми. В зависимости от размера компании, масштаба проекта, технологии, какие-то из этих людей могут быть, какие-то не могут, например, могут появиться юристы. Смысл в том, что в центре процесса управления требованиями находятся требования, которые разрабатывает аналитик.
Ниже я представлю от лица этих людей некоторые пожелания.

Хочу обратить внимание, что не все аналитики хотят разрабатывать требования в виде текста – в данном случае это мое личное предпочтение. Большинство аналитиков с текстом работать не любят и предпочитают работать с визуальными моделями, особенно те, кто работает в Enterprise Architect. Объясняю, почему мне удобней работать в виде текста: в таком виде мне удобней работать с командой – они понимают контекст.

Весь мой опыт работы в IT показывает, что главная проблема программистов в том, что они не понимают контекста того, что они разрабатывают. Они иногда программируют, не приходя в сознание. Например, в проекте разработки банковской системы много программистов. Они совершенно не понимают, какие процессы за этим стоят: при чем тут бухгалтерия, зачем нужны отчеты. Они получают установку, что требуется добавить такой-то код в такую-то папку и в такую-то функцию. И люди годами так работают.
Это, естественно, приводит к проблемам: отсутствие понимания контекста того, что они разрабатывают, приводит к большому количеству проблем, достаточно дорогих. А для того чтобы людей в этот контекст погружать, им необходимо давать требования в понятном для них виде. Нас детского сада и школы учат работать с текстом – для всех это естественный способ представления информации.

Есть противоестественный способ представления информации – это база данных. Нужно отметить, что СУТ появились только тогда, когда появились базы данных, где можно разложить все по полочкам и отслеживать жизнь каждого элемента. Но вот здесь и противоречие: люди работают с текстами, а хранить их нужно в базе, приводит многих к легкой шизофрении.

Поэтому в большей части СУТ склоняются к текстовому представлению СУТ, как это организовано в Wiki и Word, т.к. они работают с текстами, а системы профессиональные чаще склоняются к базам данных.
К чему это приводит? Допустим, мне нужно добавить требование. То, что я сейчас расскажу, многие из слушателей воспринимают, как что-то естественное, потому что других способов не знают. Когда вы создаете новое требование, вас просят ввести его в диалоговое окно. На слайде представлено диалоговое окно из Enterprise Architect, потому что он не ориентирован на работу с текстом и там это может быть оправдано.

Следующий скриншот из TFS, здесь иначе. У меня был знакомый, привыкший работать в Word, который категорически отказывался работать в TFS-системе. Эта система позволяет использовать разные шаблоны проектирования (Scrum, MSF): появляются требования, баги, change request, и др. В каждом случае свой жизненный цикл.
А в чем смысл? Когда ставится шаблон по умолчанию, там каждый вновь созданный артефакт имеет статус proposed. Я не знаю, зачем это было сделано, наверное, с точки зрения CMMI это было нужно. Суть в том, что когда человек добавляет новое требование, ему нужно еще раз зайти в диалоговое окно и еще раз поменять статус. Таким образом, он в диалог заходит два раза (конечно, шаблон настраивается и это можно убрать). Суть в том, что нужно каждый новый элемент вводить в диалоговое окно, а некоторые системы еще заставляют все атрибуты ручками выставлять – это своего рода барьер для внедрения СУТ.

Я не хочу вводить каждый абзац в отдельном окне (а тем более повторять одни и те же действия для каждого из них). Я не хочу вручную выставлять все статусы и постоянно переключаться между мышкой и клавиатурой (всем известен синдром запястного канала). Это всё выбивает аналитика из потока.

Надеюсь, что слушатели понимают, о чем я говорю. Когда ты сидишь и генеришь поток из текста требований, а тут: создал окно, мышкой двинул, потом еще раз и т.д. Это очень мешает работать и очень утомляет. Поэтому я считаю, систему диалоговых окон одним из примеров затычек, когда система на вас перекладывает свое внутреннее устройство: вот у меня есть база данных и изволь каждую запись сохранять отдельно.

Еще один пример. Я считаю мощнейшим средством представления требований – визуальные диаграммы. Без этого просто никак не получается.

В данном случае, пример, который был приведен выше в моих требованиях – это mockup – макет пользовательского интерфейса (разработан в программе Pencil).

Смысл в том, что для того, чтобы картинку с требованиями вставить в Wiki, мне приходится сначала ее экспортировать в какой-то файл jpg-png-bpm и т.п., и только потом вставить его туда. И я всегда еще (вдруг у кого-то возникнет желание поменять что-то без меня) туда вставляю ссылку на использованное средство и ссылку на файл. По-моему опыту, ни у кого и никогда не возникает желание установить программу, чтобы поменять картинку. На самом деле таких программ на удивление много.

Он не хочет запускать руками свои редакторы и хранить модели в отдельных файлах.

И если вы работаете с Wiki, то вам приходится в таком виде вставлять изображения. Это огромная проблема. Я не хочу, как аналитик этого делать. Я не хочу запускать другие редакторы. Я не понимаю, почему это не реализовано в среде разработки требований. Это прекрасно реализовано в MS Office, когда вы рисуете диаграмму в Visio, а потом вставляете ее в MS Office, после чего вы ее тут же можете править, не выходя из Word.
Другими словами — это костыль.

Другой вариант интересен для тех, кто разрабатывает требования в Wiki (Media Wiki, и др.). Для них будет понятен следующий скриншот. Это плагины к Wiki, которые позволяют создавать диаграммы в виде текста или в виде рисунка: PlantUML – более простой плагин и позволяет рисовать обычные диаграммы, а GraphViz – более широкого назначения, там есть возможность рисовать любые диаграммы, но язык программирования более сложный (похожий на ассемблер). На самом деле это очень удобная программа с точки зрения представления информации. Вы можете менять свои диаграммы, не используя какое-то внешнее средство, более того, вы можете отслеживать изменения (это теоретически, потому что практически я ни разу не видел, чтобы это было сделано).

Но я не хочу кодить, хотя программисты любят эту программу. На самом деле, если вдруг пользователю захочется поменять стрелочки или подвинуть фигуры юзкесов и др., то на это уйдет очень много времени на понимание, как это сделать. Если вы в программе Enterprise Architect это делаете – там проще, связал то, что нужно стрелочками и все, разница понятна.

Вообще это можно рассматривать по-разному. Можно рассматривать как затычку, потому что я не вижу никаких проблем, почему нельзя сделать редактор непосредственно на вебе. Его можно рассматривать и как костыль, потому что я хочу в Wiki включать изображения и диаграммы, но у меня нет других средств, и приходится пользоваться этим.

Когда появился Windows 3.0 или Windows 95 и OLE продвигалась компанией Microsoft именно как возможность встраивать один документ в другой: как я уже сказал, создаем диаграмму в Visio, потом вставляем в Word и далее редактируем уже в Word. Я до сих пор не понимаю, почему в WEB нет такого стандарта. Что-то есть в Word, что-то есть во Flash, но единого способа нет. Вы понимаете, о чем я говорю? Вы заходите на веб страничку и прямо на ней редактируете и что-то рисуете. У меня большие надежды на HTML5, потому что там уже появлялось что-то до этого, но опять же не понимаю, по каким причинам это еще не стало мейнстримом.

Существует сервис draw.io, который позволяет это делать очень удобно и красиво, но при этом диаграммы хранятся на их сервере, вы их можете вставить в свои странички, но не у себя. Возможно, это скоро изменится. Именно поэтому сейчас Microsoft Office так популярен – там все эти проблемы интеграции решены давно и удобно, и, кроме того, существует множество наработок.

Сравнивать тексты мы более-менее научились. Программисты уже освоили системы управления исходных кодов, есть множество средств сравнения текстов, однако, сравнение моделей пока стоит на месте, пока труба, хотя мне говорят, что в десятом Enterprise Architect уже есть возможность сравнивать две версии, но я считал, что так было изначально.

Я не хочу запускать сторонние программы, а сравнивать двоичные файлы бессмысленно. Что нам предлагают собственно системы управления требованиями, которые я упоминал вначале? Все, кто презентует СУТ, считают своим преимуществом экспорт в Word. На это есть несколько причин, это очень востребовано, в том числе потому, что Word позволяет сравнивать тексты.

С картинками вообще все плохо. Если необходимо сравнить две картинки, то вам нужно решать задачу «Найди 10 отличий» – т.е. сравнивать визуально. Других способов нет.

Аналитику приходится обсуждать требования. Самые привычные способы — в Word и по почте. Еще можно собрать совещание или распечатать на бумаге и поехать к нему в гости с пачкой бумаг.
Это всё достает. Я не хочу таскать пачки. Я не хочу никуда ехать. И кроме того, я хочу в процессе обсуждения вносить правки.

Такую возможность предоставляет Wiki.

Он хочет вносить изменения в требования прямо в процессе обсуждения.
У нас на летнем аналитическом фестивале (www.lafest.ru), который я все время рекламирую, выступала технический директор фирмы Human Factor Labs Елена Журавлева. Она рассказывала, как они ведут требования в Confluence. У них заказчики очень разные, в том числе и государственные, в том числе и крупные банки. И когда я пытался выпытать у нее, как же они экспортируют все это в Word, чтобы с ними согласовывать. Она сказала, что они ничего не экспортируют, а берут страничку и они (заказчики) сами с ней работают.

Люди к хорошему привыкают очень быстро. Главное, чтобы им кто-то показал это хорошее, но, к сожалению, наша система управления требованиями, кроме Word и Wiki, специально настроенная, этого делать не умеет. Что мы используем? Единственный способ – по почте.

Я взял картинку из Интернета, т.к. свою не смог — там слишком много конфиденциальной информации. Что видим: начинают вносить комментарии к каждому слову, в каждой строчке. Все это быстро вырастает в разноцветную «лапшу». Один абзац и к нему пятьдесят комментариев от разных специалистов. Потом что делает аналитик? Перечитывает все это, выбрасывает и как-то переписывает. Т.е. все эти обсуждения – костыль.
Или второй вариант, который еще хуже. Едет к заказчику, где все обсуждает, зачеркивает на бумаге. А потом с этим возвращается в офис, обрабатывает и выбрасывает, потому что с тем, что было по результатам обсуждения, работать невозможно.

Я не буду говорить о трассировке: требования нужно связывать друг с другом, разные компоненты, требования приходится связывать по уровням (см. доклад Ирины Суровой). Опять же нам приходится использовать для этого костыли.

Я показываю не очень хорошие примеры. В данном случае это модифицированный пример из TrackStudio, где мы попытались вести требования. А для того, чтобы установить связи между ними, попытались придумать иерархию. Иерархия сама по себе — это хороший костыль. Сейчас это не тема для разговора, потому что это очень много особенностей: мы заранее стараемся придумать, какие связи появятся в требованиях, а когда мы влезаем в предметную область и начинаем ее моделировать, то оказывается, что иерархия не работает. В общем, иерархия — это затычка!

Посмотрите на следующий скриншот. С этим кто-нибудь работает? Да, для планирования тестирования, отслеживания изменений.

Как я уже говорил, я не тот человек, который любит работать с таблицами. Есть люди, к сожалению, которые зомбированы таблицами. Например, мой начальник: он открыл для себя «волшебную» матрицу в Excel и потом требовал все документы разрабатывать в Excel, включая протоколы совещаний, требования, и отчеты. Я такой интерфейс называю: кишками наружу, потому что если вы хотите выяснить, какие требования у вас покрыты тест-кейсами, вам проще вывести список тестируемых работ. Но некоторым нравится. Но, тем не менее, это костыль.

11. Разработчик хочет знать, какие требования ему нужно реализовать, а менеджер проекта — какие требования еще не реализованы

Мы говорили об управлении требованиями, а именно о связывании требований друг с другом. Это один момент. Но вся мощь системы управления командной работой заключается в том, что она позволяет связывать разные артефакты. Разработчик видит, какие требования ему нужно реализовать в зависимости от поставленных задач. Менеджер проекта хочет знать, что там осталось в проекте невыполненного и хочет знать (это особенно актуально, когда много клиентов), что уже установлено у заказчика. Сначала вы посылаете ему версии из разных веток, а потом приходят запросы, и вы пытаетесь понять, что у него уже есть. В частности, в банковской сфере я постоянно с этим сталкивался: нужно определить, какие требования в текущей версии у клиента уже реализованы, а какие нет. СУТ позволяет на этот вопрос ответить.

А тестировщику нужно знать тест-кейсы, которые ему осталось выполнить.

В этом и состоит задача СУТ: все процессы построены вокруг управления требованиями, когда требуется отследить те самые связи между артефактами.
Лучше всего это сделано в TFS, который позволяет связать что угодно, с чем угодно, каким угодно способом, но при этом интерфейс выглядит вот так.

Т.е. если вы хотите связать одну сущность с другой, вам нужно ввести ее номер. А 2 цветных блока в нижней части окна они глумливо называют визуализацией. Т.е. TFS как-бы говорит: у нас, знаете ли, реляционная база данных, поэтому все реляции опишите ручками. Это не нормально.
Например, в программе Enterprise Architect это реализовано визуально: у вас есть два квадратика и вы протягиваете между ними стрелочку.
Это затычки, причем та самые, которые ведут себя, как «узбекский вирус». С одной стороны, есть богатая возможность установки производных связей, а с другой стороны, слабый интерфейс создания таких связей.

Он хочет знать, что сделано с его требованиями.

Мы уже говорили о согласовании требований.

Для того чтобы общаться с заказчиком, мы постоянно используем экспорт в MS Office, потому что мы считаем, что заказчик дурак (хотя иногда это действительно так), но в целом, это приводит к проблемам. Это сигнал о том, что хватит использовать затычки.

В общем, я всё вышесказанное представил как диаграмму вариантов использования СУТ, чтобы подытожить тему разговора. На самом деле вариантов может быть гораздо больше.

Есть еще одна проблема, о которой я сказал в самом начале. Я – аналитик. Я прихожу в новую компанию, я хочу внедрить процесс управления требованиями, включаюсь в работу и хочу использовать свой инструмент, а что мне предлагают?

Знаете, что это? Это продукт Rational (инструмент управления требованиями IBM Rational RequisitePro, картинку взял из Интернета), предназначенный для всего: для тестирования, для требований. Проще говоря, как в поговорке: коготок увяз – всей птичке пропасть. Все они интегрированы между собой, кое-что интегрируется и с чем-то другим (но это, в нашем случае, грабли).
Есть еще один вариант – Confluence (программа Atlassian Confluence) – магазин плагинов: возьми кубики и собери то, что тебе нужно.

Команда НЕ хочет использовать игрушки аналитиков

Интересно, удавалось кому-нибудь загнать программистов в Enterprise Architect с моделями работать? Чем все закончилось? Конечно, программисты бывают разные.
Но что я хочу сказать: обучить всю команду инструментам, предназначенным для аналитиков – не правильный подход. С другой стороны, если мы попытаемся загнать аналитика в TFS – как вы помните, он может работать только с текстами. Значит, пропадает вся связь с визуальными диаграммами и возникает проблема связей, о которой я говорил.

Хотя есть опыт лаборатории Касперского – они соединили TFS с Enterprise Architect, но это на самом деле мало, кто может себе позволить, т.к. в данном случае получается очень дорогой проект.
Известно, что интеграция всегда получается уникальной и аналитик не может перенести свой инструментарий в новый проект. У нас в компании, например, на поддержке связки Confluence с Track Studio работает специальная команда, которая называется «Группа поддержки корпоративного портала», где человек пять и это самые квалифицированные специалисты. Т.е. это дорого обходится.

В качестве итога хочется помечтать. Хорошо бы взять все лучшее из всех инструментов и свести все в одном инструменте.

Я попытался создать оптимальную систему требований к документам. Точнее, данные требования к системе родились в клубе системного анализа.
• Генерация документов в разных форматах
• Совместная удалённая работа
• Учёт влияния и трассировка
• Версионный контроль
• Интеграция с инструментами моделирования
• Внешние надстройки

Однако, в процессе работы над своим докладом я эти требования исправил.
Требования к системе документирования разработки и управления требованиями
• Генерация документов в разных форматах Удобное для всех представление требований
• Совместная удалённая работа, в том числе с заказчиками
• Учёт влияния и трассировка Связанность моделей и артефактов
• Версионный контроль Отслеживание изменений
• Интеграция с инструментами моделирования Встроенные инструменты моделирования
• Внешние надстройки Готовность к использованию из коробки

И хочу показать, что получилось.
1. Ввод требований
Вот я ввожу текст в Confluence. Почему я должен вводить данные в какую-то форму? Можно же машину это делать.

Исходя из форматов вводимых требований, машина сама должна раскладывать записи в базу данных. Пусть тут будет возможность коррекции, если я считаю, что она что-то сделала неправильно, я нажму Backspace, и она уберет запись. Похожие системы есть: Rational RequisitePro (в качестве средства ввода текста здесь использует MS Word) – здесь требования набираются в виде текста, которые попадают в базу данных с граблями и косяками, что даже на демонстрации видно. Технических проблем это реализовать я не вижу.

2. Установка иерархии и взаимосвязей
После ввода текста система сама должна строить связи исходя из структуры. Понятно, что потребуется создать макет связей, шаблон. Я по шаблону в Confluence ввожу требования, а в базу данных запись попадает сразу со всеми связями, как показано на диаграмме скриншота. Я не вижу в этом никаких проблем. Конечно, это надо программировать.

3. Построение диаграмм
Я хочу, чтобы установленные связи выглядели вот так. Я хочу изменять диаграмму, сделайте мне ее на вебе.

4. Отображение изменений
Если мы уж храним диаграммы в виде записи в базе данных, как правило, запись хранится в XML. XML – это текст, откуда мы всегда можем вычленить все изменения. Почему это нельзя показать на диаграмме я не понимаю. Пример: на скриншоте показаны две версии диаграммы, где я сразу могу показать, что изменилось в последней модели, по сравнению с предыдущими версиями.

5. Согласование с заказчиком
Спрашивается, а зачем вообще нужен текст? Но идея в том, что мы оставляем текст в качестве основного способа ведения требований. Давайте работать с этим текстом и дайте такую возможность заказчику: пусть он смотрит требования и ставит в пунктах, где согласен: like (пусть «лайкает»).
На самом деле это очень удобно. Вместо того чтобы ехать к нему с распечаткой требований в Word, вы даете ему вот такую страничку в Wiki. У него свой интерфейс для работы с текстом и он отмечает: согласовал – не согласовал. Если нужно обсудить – пожалуйста, отметил, что нужно обсудить и тут же обсуждаем. Как это выглядит в современных средствах управления требованиями в TFS? Длинные и скучные обсуждения.

С текстом можно делать всё, что угодно. Понятно, что можно настроить представление в зависимости от того, кто смотрит. Например, для менеджеров проектов.

Сначала он назначает, в какой релиз это требование пойдет, а потом следит за изменением статусов. Таких примеров можно привести много.

7. Создание связей.

Что такое создание связей? В данном случае я попытался продемонстрировать, как требования создать с тестовыми сценариями. Т.е. тестировщик работает с контекстом требований (в текстовом виде) и тут же может создавать необходимые связи (они сразу же ложатся в базу данных).
Понятно, что для этого нужна хорошо проработанная модель изначально. Иногда нужно связать что-то с чем-то, чтобы в конечном итоге ваш проект не страдал.

8. Визуализация связей

Данную картинку я взял из Интернета. Смысл ее вот в чем: вместо того, чтобы, как в TFS, все реляции забивать руками, связи показывать визуально.

9. Выводы
И, наконец, самое главное. Я всё вышесказанное о граблях, костылях и затычках преподнесено именно с точки зрения аналитиков, но с моей точки зрения, нужно брать инструменты командной работы и к ним прикручивать человеческий интерфейс для аналитиков. Тогда проблема была бы решена.

Т.е. я хочу инструмент для всей команды, но так все, чтобы все, что наработано в других игрушках аналитиков, было удобно и для него. С моей точки зрения, все предпосылки для создания такого инструмента есть. Как только такой инструмент появится, он сразу, по-моему, получит высокую популярность. Может быть, они уже и появились, тогда скажите о них. (Данная избушка на скриншоте символизирует, чтобы веб повернулся к аналитикам лицом).

Встретить Григория можно на следующей конференции Analyst Days в Москве 24 мая.

источник