Данное приложение обобщает результаты этих анализов.

Примеры успешных и неудачных программных систем.

Книга «Patterns of Software Sysems Failure and Success» [Jones, 1996]) является подробным анализом состояния индустрии ПО. Джонс проанализировал тысячи проектов, сгруппировав их по шести направлениям: системное ПО, информационные системы, коммерческое ПО, ПО для управления ресурсами, ПО для военных нужд и ПО для конечных пользователей. Общие оценки коренных причин удач и неудач проектов по созданию ПО, выполненные автором, сведены в таблицу А. 1.

Таблица А.1.

Технологии, используемые при осуществлении проектов по созданию ПО

Джонс приводит интересное наблюдение, касающееся этой таблицы:.

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

Джонс определяет также культурные и человеческие факторы, которые отличают успешные проекты от неудачных. Они представлены в таблице А. 2.

Таблица А.2.

Социальные факторы, наблюдаемые в проектах по созданию ПО

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

Я могу согласиться с большинством общих посылок, обобщенных в этих двух таблицах, но у меня несколько иное мнение по вопросу об относительной важности различных факторов и деталей реализации, связанных с успешным применением некоторых технологий. Например, три самых первых фактора в таблице А.1, может быть, и являются наиболее распространенными характеристиками, но я не думаю, чтобы именно они были наиболее важными определяющими факторами успехов и неудач. Мои взгляды на этот вопрос изложены в главе 4.

«Хаос».

В отчете «Chaos» [Standish Group, 1995] основное внимание уделяется индустрии коммерческого ПО и даются три основных вывода:.

■ В 1995 г. американские компании потратят на закрытые из-за неудач проекты $81 млрд.

■ 31% проектов от общего числа изученных оказались закрыты до своего завершения.

■ 55% проекта по созданию ПО превысили свой первоначальный бюджет более чем на 50%.

■ В больших компаниях только 9% проектов по созданию ПО были выполнены в срок и уложились в рамки бюджета. Для средних и малых компаний аналогичные значения возрастают до 16% и 28% соответственно.

Отчет определяет десять главных причин, обеспечивающих проектам удачу, и десять главных причин, по которым они оказываются рискованными. (Рискованные проекты называются в нем «проблемными».) Эти факторы сведены в таблицу А.З. Большая часть отчета «Хаос» касается проблем и препятствий в том виде, как они воспринимаются менеджерами корпоративных информационных систем. Рассмотрению возможных решений в отчете уделяется минимальное внимание. Тем не менее в нем содержится описание лекарства, необходимого для лечения болезни; этот подход в большей степени ориентирован на процесс, а не на борьбу с отдельными симптомами.

Таблица А.З.

Факторы, влияющие на успех проектов по созданию ПО

В отчете утверждается следующее:.

Исследование, выполненное Standish Group, также показало, что более жесткие временные рамки с предоставлением пользователю программных компонентов как можно раньше и чаще способствуют увеличению вероятности успеха. Более жесткие временные рамки приводят к итерационному процессу разработки, созданию прототипов, реализации, тестированию и внедрению небольших элементов. Такой процесс известен под названием «растущее ПО» в отличие от старой концепции «разрабатываемого ПО». Растущее ПО позволяет привлекать пользователя на более ранних стадиях, у каждого компонента есть автор или небольшая группа авторов, а ожидания реалистичны. Кроме того, каждый программный компонент имеет ясное и точное описание и набор целей. Компоненты ПО и небольшие проекты обычно оказываются менее сложными. Упрощение проекта - предприятие, имеющее смысл, поскольку сложность приводит только к путанице и возрастанию стоимости.

В отчете «Хаос» отражены убеждения, распространенные среди менеджеров ПО, в частности то, что причины успеха или неудачи кроются прежде всего в процессе определения требований. Из приведенных данных следует: если организация осознает, что именно она создает (требования), то вопрос о том, как это должно строиться (процесс), не представляет большой проблемы. На самом деле это далеко не так: на определение требований обычно уходит около 10% ресурсов жизненного цикла; остальные 90% тоже должны быть задействованы надлежащим образом. Поскольку работа по определению требований преобладает на ранних стадиях жизненного цикла, удобно использовать требования в качестве козла отпущения. В отличие от того, что вытекает из приведенных данных, рекомендации, выдаваемые в отчете о разбиении проблемы на небольшие части, являются проницательными и не противоречат духу современного итерационного процесса.

Доклад рабочей группы Научного совета по обороне о приобретении ПО для оборонных целей на коммерческой основе.

Отчет Научного совета по обороне «Report of the Defense Science Board Task Force on Acquiring Defense Software Commercially» [Defence Science Board, 1994] содержит следующие заключения:.

■ Современная практика Министерства обороны несовместима с коммерческой практикой.

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

■ Наблюдается дефицит подготовленного соответствующим образом персонала, связанного с ПО, на всех уровнях Министерства обороны.

■ Министерство обороны не полностью определило «за» и «против», касающиеся использования коммерческих компонентов.

■ Министерство обороны не уделяет достаточного внимания архитектуре.

■ Министерство обороны не способствует адекватному технологическому взаимодействию с коммерческим сектором.

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

Принципиальные причины, по которым проекты Министерства обороны по созданию ПО сталкиваются с проблемами, определены следующим образом:.

■ Плохое определение требований.

■ Неадекватное управление процессом создания ПО.

■ Отсутствие сплоченных производственных коллективов.

■ Неэффективное управление субподрядчиками.

■ Отсутствие должного внимания к процессу.

■ Совершенно недостаточное внимание, уделяемое архитектуре.

■ Плохо описанные, неадекватно контролируемые интерфейсы.

■ Обновление ПО для решения проблемы дефицита аппаратуры.

■ Основное внимание уделяется нововведениям, а не стоимости и риску.

■ Ограниченные возможности по адаптации оборонных стандартов или полное их отсутствие.

Даются следующие основные рекомендации:.

■ Использовать коммерческую практику (например, итерационную разработку и процессы с упреждающим развитием архитектуры).

■ Использовать коммерческие компоненты и технологии.

■ Инвестировать больше средств в обучение сотрудников Министерства обороны.

В отчете обсуждаются способы разрешения выявленных рисков. Он не переоценивает необходимость лучшего выполнения работы по определению требований и контролю над ними, как это делалось во многих предыдущих исследованиях, проводимых Министерством обороны. Эта тема упоминается и ей уделяется должное внимание при обсуждении наряду с другими не менее важными факторами. В отчете «Хаос» основная вина за неудачу проекта возлагается на недостаточную работу с требованиями. Министерство обороны соглашалось с этим в конце 1980-х гг., но, кажется, доросло до более взвешенной самооценки и одновременного понимания симптомов и самой болезни.