Декомпозиция работ.

Декомпозиция работ (work breakdown structure, WBS) является средством для определения и получения бюджета. Для того чтобы наблюдать и контролировать финансовое выполнение проекта, менеджер проекта

должен вникать в определение стоимости различных элементов проекта и в то, как эти суммы расходуются. Структура ответственности за расходование средств является серьезным ограничением при планировании проекта. Уроки, извлеченные из всех проектов, которые не были успешными, показали, что если WBS построена неправильно, она может увести процесс разработки и структуру продукта в неправильном направлении. Менеджеру проекта не следует расписывать более низкие уровни WBS (тем самым задавая определенные границы ответственности) до тех пор, пока не будет достигнут соответствующий уровень стабильности структуры продукта. Функциональное разбиение в WBS приведет к функциональной декомпозиции ПО. Концепция постоянно развивающейся WBS рассматривается в главе 10.

Бизнес-план.

Рабочие продукты бизнес-планирования содержат всю информацию, необходимую для выяснения того, стоит ли инвестировать данный проект. Бизнес-план позволяет детализировать ожидаемый доход, ожидаемые затраты, технический и управленческий планы и дополнительные данные, необходимые для демонстрации рискованности и реализма планов. При обсуждении больших контрактов бизнес-план может быть реализован в виде полномасштабного предложения, содержащего большие объемы информации. В случае небольшого соглашения о коммерческом продукте он может быть реализован в виде краткого плана, к которому прилагается развернутый план. Основной задачей является превращение общей концепции системы в экономические термины с тем, чтобы организация могла произвести точную оценку ROI. Финансовые прогнозы постоянно эволюционируют, они заменяются более точными прогнозами по мере развития жизненного цикла. На рис. 6.4 приведена стандартная схема бизнес-плана.

I.

Контекст (предметная область, рынок, область действия).

II.

Технический подход.

A.

План достижения набора функциональных возможностей.

B.

План достижения требуемого качества.

C.

Рабочие соглашения и технические риски.

III.

Подход к управлению.

A.

График работ и оценка его рискованности.

B.

Объективная мера успешного завершения проекта.

IV.

Дополнительные материалы.

А. Финансовый прогноз.

1.

Оценка стоимости.

2.

Оценка прибыли.

3.

Основания для оценок.

Рис. 6.4. Типичная схема бизнес-плана.

Спецификации версии.

Область действия, план и объективные критерии оценки для каждой базовой версии вытекают из концепции системы и из многих других источников (решение о приобретении/разработке, подходы к управлению рисками, архитектурные решения, смутные догадки, ограничения реализации, пороговые значения качества). Эти рабочие продукты развиваются вместе с процессом, становясь все более точными по мере развития жизненного цикла и более глубокого понимания требований. На рис. 6.5 приведена стандартная схема спецификаций версии.

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

Второй формой требований, содержащихся в спецификациях версии, являются критерии оценки. Это временные цели для данной промежуточной контрольной точки жизненного цикла. Критерии оценки в спецификациях версии определяются как рабочие продукты управления, а не как часть комплекта требований. Они вытекают из общей концепции и многих других источников (решение о приобретении/разработке, подходы к управлению рисками, архитектурные решения, смутные догадки, ограничения реализации, пороговые значения качества). Требования, связанные с управлением, могут быть представлены в виде вариантов использования, реализаций вариантов использования, аннотаций к вариантам использования или в виде структурированного текста.

задаваемых в виде вариантов использования и других текстуально представленных целей). Это означает, что требования более низкого уровня могут изменяться. Приведем пример:.

1.

Итерации начальной стадии. Обычно от 10 до 20 критериев определяют основные моменты, связанные с критичными вариантами использования, которые оказывают влияние на выбор альтернатив, касающихся архитектуры, и на общий бизнес-план.

2.

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

3.

Итерации стадии конструирования. Эти критерии оценки (возможно, сотни) связаны с наиболее значимыми вариантами использования. То, что прошло оценку по этим критериям, образует полезные части продукта, которые можно превратить в формальный тест, в альфа- или бета-версии.

4.

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

Такой процесс естественно является эволюционным и легко соотносится с современной разработкой и изменяемой архитектурой. В конце концов, становится важной 100%-ная трассируемость требований, но промежуточные действия и этапы требуют непротиворечивости и завершенности в гораздо меньшей степени, чем в случае применения традиционного подхода. Критерии оценки каждой итерации отбрасываются, когда контрольная точка пройдена; это временные рабочие продукты. На каждом этапе создается более совершенная версия, поэтому содержание и извлеченные уроки сохраняются в каждом оказавшемся удачном наборе критериев оценки. Спецификации версий и соответствующие критерии оценки более важны на ранних этапах, так как позволяют убедиться в том, что разрешены проблемы с наиболее высокой степенью риска.

План разработки ПО.

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

Рис. б.б. Типичная схема плана разработки ПО.

непротиворечивым образом всеми нижестоящими организациями, занятыми созданием ПО. Существуют два признака полезного плана: периодические изменения (он не является чем-то закоснелым), а также понимание и принятие его в равной степени как менеджерами, так и практиками. На рис. 6.6 приведена стандартная схема плана разработки ПО.

Описания версии.

В документах, описывающих версию, приводятся результаты по каждой версии, включая оценку работоспособности по каждому из критериев оценки, содержащихся в соответствующих спецификациях версии. Версия должна сопровождаться документом, в котором описываются критерии оценки для данной конфигурации и который позволяет получить свидетельство (посредством демонстрации, тестирования, просмотра или анализа) того, что проверка по каждому критерию проводилась допустимым способом. Этот документ должен содержать также общую сводку значений параметров, которая бы давала количественную характеристику качеству данной версии в абсолютных и относительных терминах (по сравнению с предыдущими версиями, если таковые существуют). Здесь должны храниться документированные результаты «посмертного» рассмотрения любой версии, в том числе неразрешенные проблемы, рекомендации по улучшению процесса и продукта, соглашения об использовании критериев оценки, последующие действия и тому подобная информация. На рис. 6.7 приведена стандартная схема спецификаций версии.

I.

Контекст.

A.

Основное содержание версии.

B.

Параметры версии.

II.

Замечания по версии.

А. Специфические для данной версии ограничения.

III.

Результаты выполнения оценок.

A.

Обоснование выполненных оценок.

B.

План последующих действий по неудовлетворенным критериям.

C.

Рекомендации по следующей версии.

IV.

Неразрешенные проблемы.

A.

Необходимые действия.

B.

«Посмертное» заключение об извлеченных уроках Рис. 6.7. Типичная схема описания версии.

Оценки состояния.

Оценки состояния предполагают периодическое создание «моментальных снимков» состояния проекта, которые включают в себя оценку риска менеджером проекта, показатели качества и показатели управления. Период между этими оценками может изменяться, но их необходимость сохраняется. Первостепенная задача хорошего процесса управления — убедиться в том, что ожидания всех заинтересованных сторон (подрядчика, заказчика, пользователя, субподрядчика) соответствуют друг другу и непротиворечивы. Документация по периодической оценке состояния является важным механизмом для управления потребностями всех заинтересованных сторон на протяжении всего жизненного цикла; для выявления проблем управления, технических проблем и рисков проекта, для работы с ними и их разрешения; для ведения истории проекта. Они позволяют менеджеру держать руку на пульсе (см. главу 9).

Типичные оценки состояния должны включать в себя анализ ресурсов, укомплектованность кадрами, финансовые данные (затраты и прибыли), 10 самых серьезных рисков, технический прогресс («моментальные снимки» параметров), планы и результаты по основным контрольным точкам, общее состояние проекта или продукта, список действий и их последовательность. Постоянная открытая работа с объективными данными, полученными непосредственно из текущей деятельности щ конфигурации изменяющегося продукта, обязательна для любого проекта.

База данных запросов на изменение ПО.

Управление изменениями является одной из основных составляющих итерационного процесса разработки. Чем больше свобода внесения изменений, тем продуктивнее итерации проекта. Такая гибкость позволяет увеличивать объем выполненной работы, качество и число итераций, которые достижимы в рамках данного графика. На практике свобода внесения изменений достигается за счет автоматизации, а все бремя по управлению изменениями ложится на современную среду итерационного процесса разработки. Организационно процессы, зависящие от ручных методов управления изменениями, неэффективны. Следовательйо, данные, необходимые для управления изменениями, преобразуются в важнейшие рабочие продукты управления, которые описываются как база данных для того, чтобы исподволь внушить понятие о необходимости автоматизации. Поскольку ПО создается на управляемой основе, все изменения должны формально отслеживаться и контролироваться. За счет автоматизации ввода данных и поддержки записей об изменениях в онлайновом режиме может быть автоматизирована большая часть бюрократической деятельности по управлению изменениями, сбору метрик и составлению отчетов. Запросы на внесение изменений подробно обсуждаются в главе 12.

Внедрение.

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

Среда.

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

Рис. 6.8. Последовательности рабочих продуктов на протяжении типичного жизненного цикла.

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

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

.

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

каждой второстепенной. На рис. 6.8 показаны типичные последовательности рабочих продуктов на разных стадиях жизненного цикла.

6.3 РАБОЧИЕ ПРОДУКТЫ РАЗРАБОТКИ.

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

Общая концепция.

Данный документ содержит полное общее представление относительно разрабатываемой программной системы и обеспечивает основу для заключения контракта между ответственным за финансирование и организацией-разработчиком. Независимо от того, является ли проект огромной разработкой, проводимой по военным стандартам (общая концепция которого может представлять собой 300-страничные системные спецификации), или маленьким, финансируемым внутри организации коммерческим продуктом (чья концепция может занимать две странички), у каждого проекта должен быть источник, в котором бы содержались ожидания всех заинтересованных сторон. Подразумевается, что общая концепция проекта будет изменяться по мере изменения понимания требований, архитектуры, планов и технологии. Хороший документ с общей концепцией должен меняться медленно. На рис. 6.9 приводится стандартная общая схема концепции.

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

I.

Описание набора функциональных возможностей.

А. Старшинство и приоритет.

II.

Показатели и диапазоны качества.

III.

Необходимые ограничения.

А. Внешние интерфейсы.

IV.

Дополнения.

A.

Варианты использования.

1.

Основные сценарии.

2.

Критерии приемки и допустимые отклонения .

B.

Желаемая гибкость (возможные сценарии внесения изменений).

6.9. Типичная схема документа концепции.

возникнуть при внесении изменений, чтобы можно было предпринять защитные меры в процессе проектирования.

Концепция должна содержать в себе как описание того, что будет включено в проект, так и описание тех возможностей, которые рассматривались, но не были включены. Должны указываться также эксплуатационные характеристики (объемные показатели, время реакции, точность), профили пользователей и интерфейсы взаимодействия с объектами, находящимися за границами системы (в тех случаях, когда это может понадобиться). Не следует определять концепцию только для начального эксплуатационного уровня; его наиболее вероятный путь развития должен быть отражен таким образом, чтобы в этом контексте могла быть оценена применимость разработки. Аспект функционирования включает в себя определение вариантов использования и сценариев для нормальных ситуаций и различных отклонений. Представление вариантов использования обеспечивает динамический контекст для понимания и уточнения области действия, для оценки целостности проектной модели и для разработки процедур приемочного тестирования. Документ с общей концепцией обеспечивает основу договоренностей о требованиях, понятных всем заинтересованным сторонам.

Описание архитектуры.

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

I.

Общее представление архитектуры.

A.

Цели.

B.

Ограничения.

C.

Степени свободы.

II.

Различные представления архитектуры.

A.

Проектное представление.

B.

Представление процессов.

C.

Представление компонентов.

D.

Представление внедрения.

III.

Архитектурные взаимодействия.

A.

Аспект функционирования для основных сценариев.

B.

Аспект функционирования для дополнительных сценариев.

C.

Аспект функционирования для аномальных условий.

IV.

Производительность.

V.

Обоснования и соглашения.

Типичная схема описания архитектуры.

Для формы описания в виде подмножества вполне достаточно оглавления. Такое описание архитектуры книги получается непосредственно из самой книги.

■ Для абстрактной формы достаточно трактовки «Cliffs Notes». (Cliffs Notes (увлекательные заметки) — это сжатые версии классических книг, используемые в качестве учебников некоторыми учащимися колледжей.) Данный формат является абстракцией, которая создается независимо и включает в себя дополнительный материал, который не может быть получен непосредственно из изменяющегося продукта.

Подход, рассматриваемый в разделе 7.2, позволяет подогнать описание архитектуры под специфические требования конкретного проекта. На рис. 6.10 приведена стандартная схема описания архитектуры.

Руководство пользователя.

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

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