Как управлять требованиями

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

  1. требования к продукту зафиксированы в базе знаний (корпоративная wiki, система управления задачами, документация разработчика, система контроля версий и т.п.) до начала работы над продуктом, что позволяет следить за историей изменений и непротиворечивостью требований;
  2. любой член команды имеет доступ к полным требованиям. Это решит проблему коммуникации и обеспечит целостное видение проекта.
  3. требования оформлены единообразным способом понятным для каждого участника команды. Это условие в сочетании со вторым позволяет определить форму и вместе с тем необходимый минимум информации для описания требований.

Ниже мы рассмотрим какими способами можно обеспечить такой процесс.

Устное общение

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

Пользовательские истории

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

  • Роль пользователя в системе. Например, администратор;
  • Действие, которое пользователь может совершить;
  • Цель, которую достигает пользователь.

Дополнительными могут быть такие параметры, как:

  • Приоритет;
  • Сложность;
  • Ограничения, накладываемые системой;
  • Нефункциональные требования. Например, работа веб-приложения оффлайн.
  • и другие…

Примером пользовательской истории может служить следующее высказывание:

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

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

Администратор рекламного агентства может создать медиаплан для управления расходами на рекламную кампанию.

Администратор рекламного агентства может редактировать медиаплан для изменения параметров расходов на текущую рекламную кампанию.

Администратор рекламного агентства может удалить медиаплан рекламной кампании для прекращения рекламной кампании.

Администратор рекламного агентства может просмотреть список медиапланов для выбора медиаплана на редактирование или удаление.

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

Проектирование. UML диаграммы

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, согласно wikipedia. Исходя из названия, очевидно, что эта нотация, разработанная консорциумом OMG, предназначена для описания моделей, по большей части програмного обеспечения. Для разных типов моделей в UML предусмотрены разные графические представления (диаграммы). Рассмотрим диаграммы, которые помогут нам описать информационную систему на этапе постановки задач.

Диаграмма прецедентов (Use case diagram)

Начнём с уже известных нам пользовательских историй. Для их изображения в нотации UML используется диаграмма прецедентов. Ниже изображена диаграмма прецедентов для последнего примера из раздела Пользовательские истории. На этой диаграмме мы видим два элемента: актёр (actor, действующее лицо) — пользователь системы; и прецедент (use case, вариант использования) — действие, которое пользователь может выполнить в системе. На самом деле, на ней есть ещё и третий элемент, который позволяет ассоциировать действующее лицо с доступными ему вариантами использования. Реальные диаграммы вариантов использования могут выглядеть сложнее, так как позволяют:

  • показать несколько ролей;
  • объединять прецеденты в подсистемы
  • показывать взаимодействия между прецедентами (обобщение, включение, расширение)
Ниже приведен пример диаграммы прецедентов, спроектированной для системы учёта платежей:

Диаграмма классов (Class diagram)

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

Диаграмма деятельности (Activity diagram)

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

Выводы

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

  • Диаграмма состояний (State machine diagram). Она используется для описания переходов состояний объекта (например, статус платежа)
  • Диаграмма последовательности (Sequence diagram). Используется для описания последовательных взаимодействий в реальном времени.
  • Диаграмма коммуникации (Communication Diagram). Используется для описания взаимодействия между разными системами, частями системы или действующими лицами посредством сообщений.
Также я хочу отметить, что графическое представление требований и моделей значительно легче для восприятия, чем текстовое. А значит использования диаграм сократит время коммуникаций, которое тратится на уточнения задач. Однако, и этот подход не гарантирует однозначную трактовку поставленных условий, хотя и сужает область возможных отклонений.

Test driven development

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

Модульное тестирование

Модульное тестирование призвано помочь разработчикам в поиске ошибок в логике выполнения программы. Выполнение модульных тестов означает, что каждая часть системы ведёт себя ожидаемым образом и, как следствие, что система не сможет прийти в противоречивое состояние. Значит для написания модульных тестов необходимо выделить части системы, взаимодействие которых вызывает опасения, и определить «ожидаемое поведение».  Обычно в качестве «частей системы» выступают публичные методы классов. Их тестируют как «чёрный ящик» на определённом наборе данных, который и описывает «ожидаемое поведение». Как правило набор данных состоит из пограничных значений; значений, которые приводят к исключениям; и несколькими значениям из области допустимых.

Приёмочное тестирование

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

Выводы

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

P.S. Как говорил Фейнман в своих лекциях по физике, «мы понимаем явление, если находим ему несколько различных объяснений».

Поделиться
This entry was posted in Management, Programming and tagged , , , , . Bookmark the permalink.

One Response to Как управлять требованиями

  1. Pingback: Пять качеств хорошего менеджера » Max Rykin Blog

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>