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

Требования на ранних стадиях проекта

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

Таким образом, на ранних стадиях проекта инженер по требованиям сталкивается со следующими проблемами:

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

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

Понимание бизнес-сценариев использования

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

Вот несколько простых шагов, которые, по нашему мнению, можно предпринять вне зависимости от плотности графика:

• Документировать предварительные бизнес-сценарии
• Устроить сессию, на которой собрать лиц со стороны бизнеса и технический персонал
• По каждому сценарию использования грубо обозначить детали внедрения, задав следующие вопросы:
• Какие стороны будут взаимодействовать с системой?
• Сколько других задействованных систем?
• Какие интерфейсы необходимо определить?
• Сколько шагов необходимо предпринять, чтобы обработать входящие данные?
• Сколько шагов необходимо предпринять, чтобы показать выходные данные?
• Сколько существует альтернативных сценариев и из скольких шагов они состоят?
• Сколько существует сценариев ошибок?

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

Измерение функционального размера

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

Шаг включает в себя следующие возможности:

• Взаимодействие действующего лица и рассматриваемой системы.
• Валидация данных.
• Внутренняя смена состояния.

Это определение важно, поскольку превращение информации, собранной во время сессий и опросов, в метрики сценариев использования на основе количества шагов лежит в зоне ответственности инженера по требованиям. Идея приравнять функциональный размер сценария использования к количеству шагов изначально была предложена Густавом Карнером в 1993. Единицы метрик сценариев использования присваивают весовую оценку каждому сценарию, основываясь на количестве шагов.

Метрики определяют их таким образом:

• 1-3 шага: «простой сценарий» (вес: 5)
• 4-7 шагов: «сценарий средней сложности» (вес: 10)
• 7 шагов и более: «сложный сценарий» (вес: 15).

В дополнение к сценариям использования оцениваются и участники взаимодействия с системой:

• через API: простое взаимодействие (вес: 1)
• через протоколы или командную строку: взаимодействие средней сложности (вес: 2)
• через GUI: сложное взаимодействие (вес: 3).

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

Если каждый сценарий использования документирован таким образом, легко вычислить метрику функционального размера (Functional Size Measurement - FSM) как сумму весов по всем метрикам сценариев использования. FSM считается в так называемых «некорректированных единицах сценариев использования» (Unadjusted Use Case Points - UUCP). В данном примере мы можем насчитать 15 UUCP (1 сложное взаимодействие, 1 взаимодействие средней сложности и 1 сценарий средней сложности).

Оценка стоимости

Используя метрики функционального размера приложения, можно оценить общие трудозатраты по проекту и, таким образом, его стоимость. Мы опишем два метода, которыми может воспользоваться руководитель проекта. Первый метод можно использовать в компаниях, которые уже делали ранее оценку по методу функциональных единиц на более поздних стадиях проекта, но с оценкой на ранних стадиях у них возникают проблемы. Как правило, проблемы появляются из-за того, что оценка в функциональных единицах на ранних стадиях невозможна из-за технической природы самих метрик функциональных единиц. Однако, используя описанные выше единицы UUCP, можно легко конвертировать их в функциональные единицы. Конвертация в функциональные единицы (FP) требует использования нормализующего коэффициента, который трансформирует UUCP в FP. Этот коэффициент может быть предоставлен компанией-оценщиком или вычислен самой организацией на основе нескольких проектов. Как отправную точку мы возьмем коэффициент 2.27, предложенный Джо Скофилдом в статье об использовании функциональных единиц (2013). После этого преобразования компания сможет использовать результат в качестве ориентира для оценки трудозатрат и стоимости. Предположим, к примеру, что функциональный размер приложения составляет 300 UUCP, а производительность компании - 34 человеко-часа на функциональную единицу. Оценку следует рассчитать таким образом:

300 UUCP ∗ 2.27 FP/UUCP ∗ 34 чч X 34 чч/FP = 23154 чч

Однако данный метод берет за основу лишь функциональный размер приложения, упуская нефункциональные требования. Поэтому хорошо он работает лишь тогда, когда, во-первых, имеется достаточно исторических данных для расчета производительности (например, человеко-месяцев на функциональную единицу), а во-вторых, нефункциональные требования нового проекта не слишком отличаются от таковых по предыдущим. Второй метод решает эти проблемы. Он основан на комбинации модели издержек разработки (COnstructive COst MOdel - II/COCOMO II) и функциональных единиц, описанных Барри Боемом (2002). Одно из преимуществ метода COCOMO II в том, что его можно использовать для оценки проектов в незнакомой среде с множеством нефункциональных требований. Однако и калькуляций это потребует несколько больше: сама идея COCOMO заключается в том, чтобы предоставить достаточное количество параметров с поправкой на конкретную ситуацию любого проекта. Используемую формулу, параметры и как их рассчитать, можно найти в статье Barry Boehm: Software Cost Estimation with COCOMO II. Перед использованием COCOMO необходимо преобразовать функциональные единицы в единицу «тысяча строк исходного кода» (kSLOC). Это значит, что в зависимости от того, какой язык программирования используется, продуктивность проекта корректируется по таблице поправочных коэффициентов Боема. Поправочные коэффициенты описывают, сколько строк кода необходимо, чтобы реализовать одну функциональную единицу. Значение, переведенное в kSLOC, можно использовать как входящее для формулы COCOMO. Суммируя изложенное выше, предположим, что приложение с функциональным размером в 300 UUCP будет написано на языке Java (поправочный коэффициент которого 53). Мы можем вычислить kSLOC таким образом:

300 UUCP ∗ 2.27 чч/ UUCP ∗ 53 SLOC / FP ≈ 36000 SLOC = 36 kSLOC

Это значение теперь можно использовать для оценки стоимости при помощи COCOMO II.

Уточнение оценки

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

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

Об авторе: Д-р Карл Фридрих Кресс работает старшим консультантом и инновационным менеджером в Германии. Он написал много статей о научном подходе к методам и метрикам оценки ПО. Его работа помогает руководителям IT-проектов надежно оценивать и планировать проекты по разработке ПО. Кроме того, он имеет опыт создания точных требований для agile-разработчиков.

Источник: http://re-magazine.ireb.org/issues/2015-1-ruling-complexity/catching-the-worm/

Перевод: Александра Родсет

Еще интересные статьи на эту тему:

• Wiki для управления требованиями
• Лучше не писать техническое задание в Google Docs
• Нефункциональные пользовательские истории
• Критерии приёмки для требований в Agile
• Проектная документация в Agile