Для сравнения, модификацию CRM и ERP назвали лишь 22%. Еще 19% испытывают проблемы с доработкой ПО промежуточного слоя (middleware). Говоря о качестве доработок, производимых внутри компании и вне ее, явных тенденций не выявилось. 45% полагают, что больше ошибок содержат внутренние доработки, а 41% - что внешние. Оставшиеся 14% склонны связывать ошибки с недоработками базового продукта. В целом же ИТ-руководители отмечают достаточно большое число ошибок. Это является одной из причин роста спроса на приложения, поддерживающие процессы разработки.

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

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

По оценкам Giga Information Group более 60% неудачных проектов по разработке ПО в США потерпели неудачу по причинам, среди которых плохая работа с требованиями была в списке пяти основных причин. "В целом, под качеством понимается не только отсутствие аномального поведения ПО, но и его соответствие потребностям заказчика", - подчеркивает Новичков. Качественные требования, выраженные в ТЗ, сами по себе являются определенной гарантией качества программного продукта.

Ошибочно определенные или неполные требования вызывают в конечном итоге большое количество переделок, в том числе и архитектурных. Переделка баз данных и других логических частей программного обеспечения, как правило, вызвана именно изменением требований со стороны заказчика.