В практике разработки программного обеспечения нередко бывают такие ситуации, когда разработчики становятся заложниками своего успеха. Вот, к примеру, небольшая группа бодро разработала и сдала проект. Заказчик доволен, счастлив и говорит: давайте развивать систему, вот вам еще договор, набирайте людей. Разработчики расширяют систему, заказчику пока все нравится. В команде проекта занято уже человек 20–30, но работают они по-старому, как будто их 5–10 человек; есть лидеры, которые ведут разработку в целом и держат все в голове. И все было бы хорошо, если б в один прекрасный момент проект не начинает пробуксовывать. Появляются факторы часто незаметные при выполнении небольших проектов.

Первый из них — сложность. Подкрадывается она неожиданно. Например, система ни с того ни с сего начинает работать неустойчиво, то есть она вроде работает, но в некоторые моменты вдруг непонятно почему «падает». Попытки исправить ошибки приводят к тому, что возникают новые ошибки в самых неожиданных местах. Это свидетельствует о том, что проект сделан не по правилам, или, можно сказать, сделан вовсе без проекта, поскольку каждый программист как считал нужным написать свой модуль, так и сделал.
Статистика показывает, что в плохо структурированных программах, где архитектуре уделялось мало внимания, после исправлении одной ошибки в 50 процентах случаев появляется новая ошибка. В подобных ситуациях в какой-то момент приходится принимать решение: систему больше не модернизировать, потому что нет ни времени ни сил исправлять целый веер ошибок, возникающий при внесении в нее даже незначительных изменений.
Второй случай проявления фактора сложности: система вроде бы нормально работает, но с какого-то момента начинает сильно отставать в производительности. Например, сделали файл-серверную систему на Access-е. Все замечательно, данные вносятся легко и быстро, все «летает». Но что значит файл-серверная система? При возрастании размеров таблиц, числа одновременно подключенных пользователей резко возрастает трафик, по сети гоняются одни и те же таблицы… Система начинает падать сначала раз в неделю, потом несколько раз в день, что, в конце концов, требует принятия кардинальных решений по пересмотру архитектуры системы.
Другая сторона возможных неудач развивающихся ИТ-проектов заключается в том, что при управлении командами программистов возникают специфические риски, которым, как правило, не учат менеджеров по управлению «обычными» проектами. Хрестоматийный пример — закон Брукса, не вполне очевидный для тех, кто никогда не участвовал в разработке софта: добавление людей в «горящий» ИТ-проект только замедляет его выполнение. Среди классических рисков при управлении разработкой программных проектов: неправильный выбор архитектуры на ранних этапах; постоянное изменение и детализация требований, необходимость управлять всеми видами изменений.
Надо также учитывать и статистику успешности выполнения программных проектов. Так, например, по данным компании Standish Group, в США в 1998 году только 26% проектов были успешными, 46% — завершились с превышением лимита бюджета или времени, а 28% потерпели полный крах и были прекращены (проценты даны в общей стоимости проекта¹). Среди факторов неуспеха в порядке убывания приоритета можно привести: отсутствие вовлечения пользователей в проект, нечеткие цели, неполные требования и спецификации, постоянное изменение требований и спецификаций, ошибки планирования.
В результате мы приходим к выводу, что при создании сложного программного обеспечения необходимо четко и грамотно организовать весь процесс разработки или заказа ПО — от написания технического задания до внедрения и дальнейшего развития. Без использования специальных технологий автоматизирующих процесс разработки, мы неизбежно будем наступать на одни и те же «грабли». Вот лишь основные из них:
 1.  разработчики и пользователи разговаривают на «разных языках», что не позволяет точно перевести неформальные требования в формальную спецификацию системы. В результате трудно создать систему, отвечающую требованиям пользователей. Требуются постоянные переделки и доработки;
 2. отсутствие проектных спецификаций («чертежей») на систему приводит к отсутствию структуры и единой концепции системы. Развитие такой системы трудоемко и ведет к дальнейшему росту «хаотичности»;
 3. трудоемкость документирования в ходе разработки выливается либо в неприемлемые сроки создания точной проектной документации, либо в неприемлемое качество документации, что

влечет за собой проблематичность модификации программного обеспечения;
 4. ошибки на этапах анализа и проектирования часто обнаруживаются только в начале внедрения, когда стоимость их исправления становится на порядок выше;
 5.  подсистемы, разрабатываемые разными группами разработчиков, трудно интегрировать из-за отсутствия или недостаточной проработки общей концепции проекта;
 6.  информационные системы не переносятся с одной платформы на другую, имеют сложное взаимодействие с другими системами и являются тяжелыми для развития.
В результате разработка нового или изменение существующего ПО поглощает слишком много ресурсов. Мировой опыт показывает, что для успешного создания такого ПО необходимы современные методологии, опирающиеся на мощные и удобные инструментальные средства. Осуществление подобных проектов в приемлемые сроки с высоким качеством невозможно без применения инженерных методов — CASE-технологий.
Для грамотной постановки процесса разработки необходимо решить в первую очередь следующие задачи:

•  Как преодолеть разрыв между постановкой и реализацией задачи?
•  Как обеспечить прозрачность проекта и его хода для заказчика и подрядчиков?
•  Как автоматизировать достоверный учет и отчетность о ходе работ?
•  Как сформировать и оценивать метрики проекта для постепенного роста качества планирования и точности оценки проектов?
•  Как оценить качество результата?

Главная проблема работы с проектом это организация коммуникации как внутри команды разработчиков, так и их коммуникации с внешним миром. Поэтому кроме индивидуальных средств работы с проектом (компиляторы, отладчики…) у программистов должны быть средства, поддерживающие основные процессы при разработке. Сами процессы определены в ГОСТе 12207 «Информационная технология. Процессы Жизненного Цикла Программных Средств»². А средства включают инструментарий, методологию и нормативную базу.