| |
Статьи | |
Как собирают требования в большой команде (практический опыт)
Автор: Волков Юрий Ольгердович, yvolk@yurivolkov.com
Ошибки в управлении требованиями являются основной причиной неудач очень многих ИТ-проектов, и именно поэтому данная тема остается весьма и весьма популярной. В этой статье делается попытка найти наиболее приемлемый путь развития управления требованиями для описываемого проекта, а также выработать общие рекомендации, применимые и для других проектов разработки сложных информационных систем. Мы расскажем, как наша команда организовала процесс сбора требований и управления ими, используя, среди прочего, средства автоматизации, и как эти требования используются в разработке информационной системы.
В настоящий момент проект разработки системы, о которой пойдет речь, ещё не завершен, соответственно и полный цикл управления требованиями не пройден до конца. Однако фаза формирования технического задания окончена, и началась фаза разработки ПО на его основе, поэтому многое понятно уже сейчас. Полученный нами опыт не является полностью положительным, но он, без сомнения, ценен и интересен тем, кто ищет свой путь в многообразии методологий и программных инструментов, автоматизирующих процессы управления требованиями. Для начала, приведем краткое описание проекта.
В соответствии с конкурсными требованиями создаваемая система должна решать два рода задач:
Требования к системе, существовавшие на момент начала работы, были очень общими, а рамки проекта — в значительной мере неопределёнными.
Работе добавило сложность отсутствие единого представителя заказчика, уполномоченного принимать решения по вопросам, возникающим в ходе сбора требований.
Сбором требований параллельно занималось несколько коллективов — соисполнителей проекта. Между соисполнителями были распределены зоны ответственности, в основном совпадающие с границами подсистем. Предполагалось, что эти же коллективы могут стать и разработчиками соответствующих подсистем. Мы, участники проекта со стороны IBS как компании, управляющей проектом, также распределили между собой ответственность по управлению подсистемами.
Управление требованиями начинается со сбора требований, их организации и документирования. Первым результатом нашей работы, представляемым заказчику, должно было стать техническое задание (ТЗ). В связи с этим мы приняли решение сразу помещать выявленные требования в репозиторий, структурировать их в соответствии со структурой ТЗ, а также сформулировать в виде, пригодном для помещения в ТЗ.
В качестве программного средства автоматизации управления требованиями был выбран продукт IBM Rational RequisitePro. Он позволяет вести коллективную работу над репозиторием требований как с использованием “толстого” клиента (в локальной сети), так и через Web-интерфейс. С самого начала была сделана ставка на то, что RequisitePro позволит нам автоматически “собрать” готовое ТЗ на основе информации репозитория. Мы не знали, каков будет объём собранной информации, и боялись, что вручную перенос требований в ТЗ займёт слишком много времени, поэтому параллельно со сбором требований дорабатывался соответствующий шаблон ТЗ (в формате MS Word), содержащий скрипт для автоматической генерации ТЗ.
Почему именно RequisitePro? Выбор был сделан практически без анализа альтернатив: на такой анализ просто не было времени, рисковать не хотелось, а фирма Rational себя уже давно зарекомендовала, в том числе и в области методологии. Поэтому мы просто установили RequisitePro и начали с ним работать, надеясь, что сможем по ходу дела решить возникающие проблемы. Сразу скажу, что этот продукт вполне оправдал наши ожидания.
Для того чтобы все участники команды единообразно понимали процесс сбора и управления требованиями, мы разработали документ “Концепция управления требованиями”. Сам процесс стал композицией процесса сбора требований с помощью «вариантов использования» (use cases), предложенного А. Кобёрном [1], а также упрощённого унифицированного процесса фирмы Rational [3]. Наибольший интерес, естественно, представляет не то, что мы декларировали в этом документе, а то, как мы на самом деле работали. Именно на этой реальной работе я и остановлюсь подробнее. Данная статья не ставит своей целью заменить указанные книги, поэтому, в случае возникновения вопросов по терминологии и по самой методологии сбора требований, обращайтесь к первоисточникам.
Нашей команде пришлось самостоятельно дорабатывать методологию сбора требований для проекта: его сложность не позволяет использовать готовые методологии, имеющие существенные ограничения. В частности, в книге Д. Леффингуелла [2], проповедующей унифицированный подход (Unified process), за описанием методов анализа систем и управления требованиями следует конкретный пример методологии, предваряемый описанием ограничений его применения. Так вот, практически каждый пункт этого списка [2, с. 364] относится к нашему проекту, т. е. приведённая методология в буквальном смысле не подходит нам “по всем пунктам”.
Центральным местом взаимодействия команды, занимающейся сбором требований, стал репозиторий требований RequisitePro. А основным способом доступа к этому репозиторию — Web-интерфейс.
Для собственно требований мы создали в репозитории два типа требований: “вариант использования” и “требование”, — имеющие различные наборы атрибутов. Мысль была такая: “варианты использования” содержат описания сценариев и другие атрибуты (“основное действующее лицо”, “цель” и т. п., см. [1]), а “требование” — это нечто более простое, например фраза, описывающая это требование. Связь требований, в том числе и различных типов, мы указывали с помощью трассировки (трассировка и есть установление связи, зависимости). Помещать в репозиторий отформатированные варианты использования (файлы MS Word) было неудобно (RequisitePro не даёт возможности “прикрепить” файл к “требованию»), поэтому хотя варианты использования и создавались в удобном для восприятия человеком формате, их применение было затруднено тем, что они пересылались обычной почтой и выпадали за пределы автоматизированной части процесса сбора требований. В результате, поля (body parts) вариантов использования помещались в репозиторий в виде неформатированного текста. Структурированные сценарии после такого копирования, к сожалению, уже не читаются. Мы это заметили сразу, но отступать было уже поздно.
Проиллюстрировать взаимосвязи собранных вариантов использования можно с помощью UML-диаграммы вариантов использования. Логичным шагом могла бы стать интеграция репозитория требований с соответствующими UML-моделями, и RequisitePro поддерживает интеграцию со средствами моделирования (IBM Rational XDE и Rose)… но не через Web-интерфейс, что в нашем случае было критически важно. И вообще, мы заметили, что для корректной работы репозитория через Web нужно избегать работы не через Web (по локальной сети с помощью “толстого клиента” RequisitePro), иначе могут появиться документы, доступ к которым возможен только из локальной сети.
Для удобства разделения труда между рабочими группами соисполнителей проекта при одновременной работе с репозиторием, все требования имели атрибут “владелец”, идентифицирующий рабочую группу (организацию-соисполнителя), которая может изменять данное требование. Этот атрибут имел для нас только справочное значение: RequisitePro, к сожалению, не позволяет задать права доступа пользователей к отдельным требованиям. Работу с репозиторием требований параллельно вели около десяти человек.
Список терминов (глоссарий) проекта, список действующих лиц (участников вариантов использования), а также реестр регламентирующих документов (документов, на которых базируется работа системы) мы также стали вести в репозитории требований, создав для этого отдельные пакеты (для структурного выделения этих списков) и специальные “типы требований” для элементов этих списков (других вариантов и не было: ничего, кроме требований и документов в RequisitePro не “живёт”).
Реестр регламентирующих документов, практически, так и не был заполнен. Вероятно, это было следствием того, что RequisitePro не поддерживает гиперссылки в тексте требований (могут быть созданы только отдельные атрибуты типа “URL Link”), а основной целью введения реестра регламентирующих документов была унификация ссылок на эти документы. Аналогичная судьба постигла и документ “Действующее лицо/цель”: мы создали первоначальную его версию, которая, однако, не прижилась в репозитории требований.
Сбор требований проходил итерационно: раз в неделю мы подводили итог проделанной работы и намечали направления проработки требований на следующую неделю. После того, как был подготовлен шаблон MS Word для генерации ТЗ на основе информации из репозитория требований, мы начали периодически генерировать это ТЗ и публиковать его для участников проекта. Таким образом, все видели, как движется работа, и что делают остальные участники.
Ниже перечислены результаты, достигнутые на декабрь 2004 г., а также предварительные выводы, касающиеся управления требованиями в проекте.
Успешно прошёл этап согласования ТЗ с большим количеством представителей заказчика. Для учёта поступивших замечаний мы создали ещё один тип требований: “замечания”. Каждое такое замечание, снабжённое именем его автора, мы связали трассировкой с соответствующим требованием, по поводу которого оно было высказано, (т.е. с предложением об изменении ТЗ). После этого работа по учёту замечаний в ТЗ велась параллельно несколькими членами команды: каждый мог внести изменение в требования, а потом соответственно изменить статус “замечания” (принято/учтено/отклонено…). В результате, в репозитории на 400 своих требований мы получили 200 замечаний.
В то же время, периодическая генерация ТЗ на основе репозитория требований позволяла нам визуализировать то, что “пряталось” в куче папок (“пакетов”) самого репозитория. Таким образом, сами собранные требования стали трудно воспринимаемы в отрыве от созданного на их основе ТЗ.
Причина неполноты требований к системе в целом, по моему мнению, такова: эксперты в предметной области распределили между собой задачи сбора требований к подсистемам и тем самым сразу “провалились” на уровень своих подсистем. Сначала мы никак не могли понять, почему у нас не возникает прогнозируемого (на основе опыта, описанного А. Кобёрном [1]), дерева вариантов использования, имеющего для всей системы в целом от двух до пяти вариантов использования верхнего уровня.
К моменту завершения этапа сбора требований для ТЗ у нас был, по сути, всего один вариант использования, описывающий сценарий одного из бизнес-процессов, в котором участвовало несколько подсистем. Не удивительно, что именно этот сценарий привлёк наибольшее внимание участников проекта, в том числе и заказчика, и чаще всего подвергался доработке: в нем говорилось о том, что конкретно делает система.
Вот один из примеров таких требований слишком низкого уровня: “Управление учётными записями пользователей должно осуществляться посредством их модификации, удаления либо блокирования”.
Излишняя детализация требований плоха как минимум по двум причинам: с одной стороны, эти детальные требования засоряют общую картину, мешают добраться до сути, а с другой — они очень непостоянны. Малейший ветерок изменений сверху, — и они изменяются или просто исчезают. В результате, такими детальными требованиями просто невозможно управлять. Ведь идея состоит в том, чтобы отслеживать изменения требований, анализировать причины и следствия этих изменений и т. д. А если меняются требования на верхних уровнях, включая те уровни, которые раньше просто не были описаны, то уже некому заниматься анализом того, “какие же из детальных требований выжили”. Гораздо проще, при необходимости, сформулировать детальные требования с чистого листа, т. е. на основе более общих требований, а не возиться с мусором старых требований.
Я уже упомянул о том, что RequisitePro вполне оправдал наши ожидания. Это, однако, не означает, что он устраивает нас: просто сначала мы и не пытались требовать от этой системы всего, что нам было нужно, хотя и надеялись решить часть проблем. А потом сами наши ожидания стали расти по мере развития работы по проекту: к ней подключались новые члены команды, увеличивалось количество собранных требований, начались активные обсуждения того, что получается, и какие за ними должны следовать изменения, порой весьма кардинальные.
Удобным для работы в RequisitePro является только один вариант структурирования требований, при котором требования группируются в оглавления (пакеты) и детализируются требованиями следующего уровня (связь родитель — ребёнок (parent — child)). Однако отношение родитель — ребёнок возможно только для артефактов одного типа: например, требованию типа “вариант использования” нельзя назначить в качестве ребёнка ни текстовый документ, содержащий подробное описание этого требования в удобном формате, ни требование другого типа (у нас были и такие типы требований: “требование”, “замечание”).
Другой вариант структурирования требований — с помощью трассировки (traceability). Трассировка возможна между артефактами (в том числе требованиями) любых типов, однако сама она должна быть только одного типа! Наш же набор трассировок, созданных с разными целями, постепенно превратился в кучу, в которой уже нет наглядности. Особенно печально стал выглядеть репозиторий после появления более сотни замечаний и их трассировки на требования.
В использовавшейся нами версии RequisitePro 2003 не было удобной возможности организовать связь репозитория требований с внешними ресурсами, расположенными в глобальной Сети (с помощью URL). Это ограничение по сути похоронило наши идеи о размещении дополнительных документов, относящихся к требованиям, на Web-серверах. (Здесь нужно заметить, что в выпуске RequisitePro 2003.06.13 рядом с атрибутом, содержимое которого имеет тип “URL Link”, появилась кнопка, по которой указанный URL открывается в окне Интернет-браузера.)
Кроме того, мы предполагали связать требования с базой (или базами) регламентирующих (нормативных) ресурсов, размещённых в Интернете. Для этого нами была разработана унифицированная система ссылок на регламентирующие ресурсы, но воплощения эта система не нашла, потому что атрибуты требований RequisitePro представляют собой неформатированный текст и гиперссылки в нём не поддерживаются. А ведь гиперссылки, как известно, наиболее удобны непосредственно в тексте…
Да, RequisitePro помог нам “собрать” документ “Техническое задание”. Это немало, но:
Несомненное преимущество от использования RequisitePro в том, что теперь стало гораздо понятнее, чем хороша система автоматизации управления требованиями, и что нам может понадобиться от неё.
1. Кобёрн А. Современные методы описания функциональных требований к системам. М.: “Лори”, 2002. Домашняя страница А. Кобёрна в Интернете: http://alistair.cockburn.us/.
2. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. М.: ИД “Вильямс”, 2002.
3. Крачтен Ф. Введение в Rational Unified Process. — Изд. 2-е. М.: ИД “Вильямс”, 2002.
Последнее изменение: 19 января 2005 г.
Cтатья опубликована 25 января 2005 г. в "PC Week/Russian Edition", №2 (464) 2005г., стр.27, http://kis.pcweek.ru/Year2005/N2/CP1251/DevApp/chapt1.htm