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% затрат на повторную работу.