- •Типы бизнес-правил.
- •3.5. Документирование бизнес-правил
- •3. Технологический процесс управления требованиями.
- •3.1. Цели управления требованиями.
- •3.2. Цена ошибок, допущенных в требованиях.
- •3.3. Пирамида типов требований
- •3.4. Этап анализа проблемы.
- •3.5. Артефакты процесса управления требованиями.
- •3.6. Функции продукта или системы.
- •3.7. Управление масштабом проекта.
- •3.13. Требования к программному обеспечению.
- •3.14. Спецификация требований к программному обеспечению (Modern Software Requirements Specification)
3.2. Цена ошибок, допущенных в требованиях.
Исследования группы Стендиша (Standish Group) [1] свидетельствуют о следующем. В США ежегодно тратится более 250 миллиардов долларов на разработку приложений информационных технологий в рамках примерно 175 000 проектов. Средняя стоимость проекта составляет:
для крупной компании — $2 322 000;
для средней компании — $1 331 000;
для мелкой компании — $434 000.
При этом 31 % проектов будет прекращен до завершения. Затраты на 52,7% проектов составят 189% от первоначальной оценки.
Исходя из этого, группа Стендиша оценивает, что американские компании и правительственные учреждения потратят 81 миллиард долларов на программные проекты, которые так и не будут завершены. Эти же организации заплатят дополнительно 59 миллиардов долларов за программные проекты, которые хотя и завершатся, но значительно превысят первоначально отведенное на них время.
Первым шагом на пути решения проблемы является осознание основных причин ее возникновения. При проведении исследования респондентам было предложено указать факторы, повлиявшие на проекты, разделенные на следующие категории:
успешные - завершенные срок и в рамках отведенного бюджета;
проблемные – проекты, по которым возникла задержка или проекты, не оправдавшие ожиданий;
потерпевшие неудачу - прекращенные проекты.
В результате были указаны три наиболее часто встречающихся фактора, создающие проблемы в проектах.
Недостаток исходной информации от клиента: 13% всех проектов.
Неполные требования и спецификации: 12% проектов.
Изменение требований и спецификаций: 12% всех проектов.
По остальным факторам (рис. 3.1), влияющим на успех проекта, данные сильно расходятся:
проект потерпел неудачу из-за нереалистического подхода к составлению графика и выделению времени - 4% проектов,
неправильный подбор персонала и выделения ресурсов - 6%,
несоответствия технологических навыков (7%)
по другим причинам.
Если считать, что приведенные группой Стендиша цифры, представляют реальное положение дел в отрасли, то, по крайней мере, третья часть проектов нуждалась в разрешении проблем, непосредственно связанных со сбором, документированием и управлением требований, как показано на рис 3.1.
Рисунок 3.1. Факторы, влияющие на провал проекта.
Хотя большинство проектов действительно превышают отведенное время и бюджет, если их вообще удается закончить, группа Стендиша обнаружила, что около 9% проектов крупных компаний были завершены вовремя и в пределах бюджета; аналогичного успеха удалось достигнуть в 16% проектов мелких компаний. Согласно проведенному исследованию тремя наиболее важными "факторами успеха" были названы следующие.
Подключение к разработке пользователя: 16% всех успешных проектов.
Поддержка со стороны исполнительного руководства: 14% всех успешных проектов.
Ясная постановка требований: 12% всех успешных проектов.
Другие источники приводят даже более впечатляющие результаты. Например, организация ESPITI (European Software Process Improvement Training Initiative — Европейская инициатива по обучению совершенствованию процесса программирования) провела опрос с целью определить относительную важность различных типов существующих в отрасли проблем. Двумя самыми главными проблемами, упоминавшимися почти в половине ответов, оказались следующие.
Спецификации требований.
Управление требованиями клиента.
Если бы ошибки требований можно было быстро, просто и экономно устранять, проблема не была бы столь серьезна. Алан Дэвис (Davis) в своей работе [2] подвел итоги нескольких исследований и показал, что при обнаружении ошибок на стадии формирования требований компания получает экономию средств в соотношении 200:1 по сравнению с их обнаружением на стадии сопровождения программы.
Такая стоимость ошибок обусловлена эффектом умножения. Многие из ошибок в требованиях достаточно долго остаются не обнаруженными, и группа разработчиков тратит время и усилия на создание проекта по этим ошибочным требованиям. В результате проект, вероятно, придется отбросить или пересмотреть. Для уточнения, в чем же состоит ошибка требований, необходимо общение с клиентом, который участвовал в его разработке на самом первом этапе. Однако на практике может оказаться, что в данный момент связаться с этим человеком невозможно, он забыл, в чем состояла суть инструкции, которую он давал команде разработчиков, не помнит, чем руководствовался при этом, или же просто изменил свою точку зрения. Может оказаться, что принимавший участие на этом этапе член команды разработчиков (бизнес-аналитик или системный аналитик) перешел в другое подразделение. В результате определенная часть работы проделывается вхолостую, что приводит к потере времени. Проблемы, связанные с "просачиванием" недостатков из одного этапа в другой, являются вполне очевидными, однако подавляющее большинство организаций ими всерьез не занималось.
Одной из организаций, действительно работавшей над данным вопросом, является компания “Hughes Aircraft”. Исследование Снайдера (Snyder) [3] обнаружило явление "просачивания" дефектов во многих проектах, выполненных компанией на протяжении 15 лет. В данном исследовании говорится о том, что 74% дефектов, связанных с формированием требований, были обнаружены на этапе анализа требований, когда клиенты совместно с системными аналитиками обсуждают, подвергают мозговому штурму, согласовывают и документируют требования к проекту. Этот этап работы над проектом является идеальным с точки зрения обнаружения таких ошибок с наименьшими затратами. Однако исследование также свидетельствует, что 4% дефектов "просачиваются" на этап предварительного (высокоуровневого) проектирования, а 7% — еще дальше, на этап детализированного проектирования. Невыявленные ошибочные требования жизненному циклу системы, и 4% ошибок требований оказываются не найденными вплоть до этапа сопровождения, когда система уже передана клиентам и считается полностью работоспособной.
Таким образом, в зависимости от того, где и когда при работе над проектом разработки программного приложения был обнаружен дефект, стоимость его устранения может разниться в 50-100 раз. Причина состоит в том, что для его исправления придется затратить средства на некоторые (или все) ниже перечисленные действия.
Повторная спецификация.
Повторное проектирование.
Повторное кодирование.
Повторное тестирование.
Создание документации.
Замена дефектной версии исправленной.
Списание части работы, которая оказалась ненужной.
Выплаты по гарантийным обязательствам
Из сказанного выше можно сделать два вывода.
Ошибки в определении требований являются наиболее распространенными.
Стоимость устранения таких ошибок - одна из самых высоких.
Ошибки в определении требований приводят к затратам, составляющим 25-40% бюджета проекта разработки в целом. Учитывая частоту возникновения ошибок в определении требований и эффект умножения стоимости их устранения, легко предсказать, что эти ошибки обусловят до 70% затрат на повторную работу.