Таблица 14.7.
Распределение временных затрат по стадиям для маленьких и больших проектов_
Разработка | Производство | |||
Предметная область | Начальная. стадия | Уточнение | Конструирование | Ввод. в действие |
Маленький коммерческий проект | 10% | 20% | 50% | 20% |
Большой, сложный проект | 15% | 30% | 40% | 15% |
Самым значительным отличием является относительное время, за которое достигается контрольная точка жизненного цикла, связанная с созданием архитектуры. Это соответствует тому количеству времени, которое тратится на стадию разработки, по сравнению с количеством времени, затрачиваемым на стадию производства. Для малых проектов это отношение составляет 30/70; для большого проекта оно ближе к 45/55.
Одним из ключевых аспектов, касающихся различий между двумя такими проектами, является влияние, которое оказывают разные компоненты процесса на успех или неудачу проекта. В этом находит свое отражение важность найма сотрудников или уровень соответствующего управления рисками. Таблица 14.8 содержит перечень рабочих процессов в порядке их важности.
Таблица 14.8.
Различия в приоритетах рабочих процессов для малого и большого проектов
Приоритет | Маленький коммерческий проект | Большой сложный проект |
1 | Проектирование | Управление |
2 | Реализация | Проектирование |
3 | Внедрение | Требования |
4 | Требования | Оценка |
5 | Оценка | Среда |
6 | Управление | Реализация |
7 | Среда | Внедрение |
Следующий список показывает некоторые из ключевых особенностей, являющихся определяющими для успеха. Ни один из этих компонентов процесса нельзя считать незначительным, хотя некоторые из них более важны, чем другие.
■ Проектирование — ключевой аспект для обеих областей. Хорошие проектные решения являются для коммерческого проекта ключевым фактором в определении места, занимаемого на рынке, и основой для создания эффективных новых версий продукта. Хорошие проектные решения для большого проекта формируют основу для предсказуемого, эффективного по затратам процесса создания.
■ Управление является первостепенным для больших проектов, где ошибки, допущенные при планировании и распределении ресурсов, противоречивые ожидания заинтересованных сторон и другие выводящие из равновесия факторы могут иметь катастрофические последствия для общей динамики работы команд. Для маленькой команды управление не так важно, поскольку вероятность неправильного взаимодействия намного ниже, а его последствия менее значимы.
■ Внедрение играет значимую роль для маленького коммерческого продукта, поскольку у него существует широкая пользовательская база и большое разнообразие сред. Единственный в своем роде, сложный проект обычно внедряется только в одном месте. Унаследованные системы и непрерывная эксплуатация могут представлять некоторый риск, однако в общем эти проблемы хорошо понятны и у них постоянный набор целей.
Другой ключевой набор различий присущ реализации рабочих продуктов процесса. В таблице 14.9 приводится концептуальный пример этих различий.
Таблица 14.9.
‘.
Различия в рабочих продуктах малого и большого проектов
Рабочий продукт | Маленький коммерческий проект | Большой сложный проект |
Декомпозиция работ | Развернутый план, занимающий одну страницу и имеющий 2 уровня элементов WBS | Система финансового управления с 5 или 6 уровнями элементов WBS |
Бизнес-план | Подробный план и краткий меморандум | Трехтомные предложения, в том числе технический том, том по затратам и описание соответствующего опыта |
Общая концепция | 10-страничное общее представление | 2200-страничные спецификации подсистем |
План разработки | 10-страничный план | 200-страничный план разработки |
Спецификации версий и количество версий | Спецификации трех промежуточных версий | Спецификации 8—10 промежуточных версий |
Описание архитектуры | 5 критичных вариантов использования, 50 диаграмм UML,. 20 страниц текста, другие графические материалы | 25 критичных вариантов использования, 200 диаграмм UML,. 100 страниц текста, другие графические материалы |
ПО | 50 ООО строк кода на Visual Basic | 300 ООО строк кода на C++ |
Описание версии | 10-страничные замечания по версии | 100-страничное обобщение результатов |
Внедрение | Курсы обучения пользователей Стандартный набор для продаж | План ввода в действие План инсталляции |
Руководство. пользователя | Онлайновая помощь и 100-страничное руководство пользователя | 200-страничное руководство пользователя |
Оценка состояния | Ежеквартальное рассмотрение проекта | Ежемесячное рассмотрение управления проектом |
Ключевые моменты.
А Особенностью современных проектов является то, что позитивные и негативные тенденции становятся более ощутимыми уже на ранних стадиях жизненного цикла.
А Интеграция начинается рано и выполняет функцию верификации рабочих продуктов.
А Многие критичные риски оказываются разрешенными к моменту завершения стадии уточнения. Стадии конструирования и ввода в действие, которым присущ основной финансовый риск, лишены всяких сюрпризов.
А Внимание по достижению основных контрольных точек сосредоточивается на демонстрируемых результатах.
1.
Затянувшаяся интеграция и позднее обнаружение ошибок, допущенных при разработке, разрешаются посредством переноса интеграции на стадию разработки. Это достигается за счет постоянной интеграции базовой архитектуры, поддерживаемой демонстрациями выполнения основных сценариев.
2.
Позднего разрешения рисков удается избегать за счет подхода с упреждающей разработкой архитектуры, при котором наиболее значимые элементы системы тщательно прорабатываются на ранних стадиях жизненного цикла.
3.
«Паралича анализа» функциональной декомпозиции, определяемой требованиями, удается избежать, организуя спецификации низкого уровня в соответствии с содержанием версий, а не в соответствии с декомпозицией продукта (на подсистемы, компоненты и т.д.).
4.
Противоречий между заинтересованными сторонами удается избежать за счет предоставления более осязаемых и объективных результатов на протяжении всего жизненного цикла.
5.
Традиционно повышенное внимание к документации и встречам для обмена мнениями заменяется повышенным вниманием к результатам, которые можно продемонстрировать, и к четко определенным комплектам рабочих продуктов, выполненных с помощью более строгих нотаций и автоматической поддержки «безбумажной» среды.
Средства для решения этих пяти проблем, используемые современными благополучными проектами, подробно обсуждаются ниже. Способы решения четвертой и пятой проблем тесно связаны между собой и описываются в разделе 15.4. Разделы 15.5 и 15.6 посвящены анализу современных проектов в контексте моих 10 принципов управления созданием ПО и рассмотрению лучших примеров альтернативной практики.