«Учебно-методическое пособие по дисциплине Технологические подходы к разработке программного обеспечения Новиков Ф.А., канд. физ.-мат. наук, доцент кафедры Технологии программирования Санкт-Петербург 2007 УМП ...»

На практике программирующие организации редко применяют приведенные абстрактные модели процессов в «чистом виде». Как правило, используя известные модели и учитывая конкретные особенности и условия, организация создает специфические модели «под себя», которые наилучшим образом учитывают особенности организации.

Откуда и происходит название модели.

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

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

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

Замечание по конструированию Замечания, которые присутствуют далее в тексте описания сконструированного процесса, не являются частью сконструированного процесса, т.е. не являются частью примера. Эти замечания содержат объяснения и мотивацию того, почему было принято то или иное решение при конструировании.

Рассмотрим гипотетическую организацию, разрабатывающую программное обеспечение на заказ. Допустим, организация выявила у себя следующие особенности.

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

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

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

• Гарантированный конечный успех. Для расширения и стабилизации круга заказчиков требуется гарантированный конечный успех каждого отдельного проекта, даже если это требует дополнительных внутренних расходов на проведение проекта.

Для такой организации целесообразно построить комбинированную модель процесса, и дифференцировать ее по типам проектов.

Сформулируем требования к конструируемой модели процесса.

• Учет особенностей организации. Процесс должен учитывать выявленные особенности организации и не должен им противоречить.

Выражаясь терминами, принятыми в унифицированном языке моделирования UML, можно сказать, что процесс конструирования описания процесса разработки является мета процессом по отношению к процессу разработки.

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

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

• Область применения. Конструируемое описание должно описывать только процесс разработки программного обеспечения. Другие процессы, например, договорные отношения с заказчиком, описывать нежелательно.

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

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

В разрабатываемом процессе используются фазы, которые называются • Анализ • Проектирование • Реализация • Стабилизация • Внедрение Замечание по конструированию Названия первых четырех фаз совпадают с фазами процесса MSF (см. рис. 10) В модели процесса MSF имеются только четыре первых фазы по следующей причине. Фаза внедрения (deployment) не включается в процесс разработки и рассматривается в MSF как отдельный процесс. В случае рассматриваемой организации мы предположили, что разработка и внедрение регулируются, как правило, одним и тем же договором, поэтому внедрение считается частью процесса разработки.

Последовательность пяти фаз называется «виток». Фазы одного витка всегда выполняются в указанном порядке.

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

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

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

Замечание по конструированию Видимость извне означает, что отчуждаемые материалы вехи согласуются с заказчиком. Таким образом, все главные вехи и видимые извне внутренние вехи являются контрольными точками, привязанными ко времени планом-графиком, прилагаемым к Техническому заданию на проект. Далее в качестве синонима оборота "согласуемый с заказчиком…" используется термин "внешний".

Фаза анализа является первой в каждом витке. Главная веха фазы анализа называется «утверждение концепции проекта» (или просто «концепция») и состоит в фиксации документа (серии документов) с общим названием "Концепция…". Концепция включает в себя следующие обязательные разделы:

1. Введение. Основание для разработки и статус проекта.

2. Постановка задачи. Общее описание предметной области проекта; формулировка проблемы, на решение которой направлен проект; краткий обзор альтернативных решений, если они есть; основные отличительные особенности проекта.

3. Цели проекта. Явное, лаконичное и эффективно проверяемое утверждение о целях проекта. Обычно проект имеет одну главную цель и несколько вспомогательных или промежуточных подцелей.

4. Категории пользователей. Классификация пользователей результатов проекта; перечисление их ожиданий по отношению к результатам проекта.

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

7. Типовые примеры. Несколько (1–3) неформальных примеров, иллюстрирующих использование ожидаемого решения.

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

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

Промежуточными вехами на фазе анализа могут быть:

• Обследование. Отчет о проведенном обследовании бизнес-процессов, на которые направлен проект.

• Техническое задание. Формализованный документ, отражающий в стандартизованной форме содержание Концепции.

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

3.4.2.2. Фаза «Проектирование»

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

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

Замечание по конструированию Различаются внешние и внутренние спецификации проекта. Внешние спецификации согласуются с заказчиком, внутренние спецификации являются внутренними документами проекУМП Технологические подходы к разработке ПО та. Все внешние спецификации обязательно создаются на фазе проектирования, некоторые внутренние спецификации могут быть перенесены на последующие фазы.

• Календарный план-график. Список фаз и частей фаз с указанием главных и промежуточных вех, привязанных к конкретным датам, исполнителей и отчуждаемых материалов каждой вехи. Настоятельно рекомендуется использовать для этой цели инструментальное средство Microsoft Project. Другие средства календарного планирования используются только в том случае, если заказчик возражает против использования Microsoft Project.

Замечание Документ с аналогичным названием подготавливается также на первом этапе подготовки к проекту, прилагается к Договору и согласуется с заказчиком. План-график фазы проектирования может совпадать с календарным планом, который видит заказчик, если все вехи являются внешними и совпадают с этапами ТЗ. Но гораздо чаще календарный план-график является внутренним документом, содержащим детальную расшифровку фаз и вех с персоналиями. В этом случае внешний (менее детальный) план-график оформляется в соответствии с пожеланиями заказчика, а внутренний план-график ведется с помощью Microsoft Project.

Кроме указанных основных компонентов, в спецификации проекта могут входить:

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

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

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

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

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

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

3.4.2.3. Фаза «Реализация»

Фаза реализации (кодирования) имеет основную веху, которая называется «код готов».

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

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

Замечание по конструированию Многочисленные исследования показывают, что чем крупнее проект, тем меньшую долю в нем занимает собственно кодирование. Указанная величина 20% является ориентировочным показателем для типичного проекта.

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

• Логический проект. Модель объектов (служб) приложения. Спецификация интерфейсов услуг (методов и свойств), предоставляемых службами (объектами).

• Схема базы данных. Фиксация представления данных проекта. В случае использования стандартной реляционной СУБД — определение структуры таблиц и связей между ними.

• Дизайн интерфейса. Фиксация внешнего вида статической части графического интерфейса (форм и диалоговых окон). Фиксация состава команд меню и языка пользователя, если он предусматривается проектом.

• Физический проект. Упаковка служб в компоненты, описание протоколов взаимодействия компонент для распределенных приложений.

Если какие-то промежуточные вехи фазы реализации являются внешними (например, логический проект), то они относятся к внешним спецификациям и выполняются на стадии планирования.

Рекомендуется использование средств CASE, ориентированных на визуальное проектирование и автоматическую генерацию кода. Наиболее перспективным является использование средств, поддерживающих UML. В этом случае результатом для целого ряда вех (Функциональные спецификации, Логический проект, Схема базы данных, Физический проект и даже Код готов) является модель приложения (отдельные части этой модели), построенная с помощью используемого средства CASE.

3.4.2.4. Фаза «Стабилизация»

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

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

• Тестирование устойчивости (reliability). Целью этого вида тестирование является выявление не перехватываемых ошибок времени выполнения, т.е. тесты устойчивости нацелены на то, чтобы "сломать" приложение. Типичными приемами, применяемыми при тестировании устойчивости, являются ввод данных, выходящих за пределы области допустимых значений, нарушение порядка действий, предусмотренных сценарием, создание ситуаций, нарушающих количественные ограничения.

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

• Тестирование применимости (usability). Целью этого вида тестирования является проверка того, что предусмотренные способы использования приложения являются удовлетворительными для пользователя при выполнении типичных сценариев работы. При тестировании применимости проверяются, например, следующие параУМП Технологические подходы к разработке ПО метры: реактивность, защищенность данных, способность к восстановлению после ошибки, понятность интерфейса и др.

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

• Нет известных ошибок. Все тесты, предусмотренные планом тестирования, не выявляют ошибок. Все найденные и зафиксированные в базе данных ошибки помечены как исправленные.

• Исходные тексты готовы. Все исходные тексты программ проверены на соответствие принятой дисциплине программирования (комментарии, имена объектов, структура текста). Некоторые советы, касающиеся хорошего стиля программирования, приведены ниже в разделе Дисциплина программирования.

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

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

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

3.4.2.5. Фаза «Внедрение»

Фаза внедрения является заключительной, ее главная веха называется «проект закончен».

Эта веха характеризуется следующими основными признаками: разработанное решение используется заказчиком (пользователями) на практике; взаимоотношения с заказчиком урегулированы, результаты проекта документированы, измерены, архивированы и подготовлены для повторного использования.

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

На фазе внедрения промежуточные вехи могут устанавливаться заказчиком. Типичными вехами фазы внедрения являются следующие:

• Приложение (решение) развернуто. Разработанное приложение (решение) установлено у заказчика и проверена его работоспособность согласно программе и методике испытаний.

• База данных загружена. Эксплуатация решения ведется на реальных данных заказчика.

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

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

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

Витки выполняются не последовательно, а частично накладываются друг на друга.

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

Конкретный способ наложения витков в модели называется «спиральной структурой».

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

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

Замечание по конструированию Используя объектно-ориентированную терминологию, можно сказать, что предлагаемая модель процесса в целом описывает класс процессов разработки. Описание этого класса на мета уровне представляется затруднительным для формулирования и понимания. Поэтому описание устроено следующим образом. Приводятся примеры объектов – экземпляров этого класса (конкретные схемы проектов, которые называются типами и подтипами проектов).

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

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

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

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

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

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

• критерий новизны;

• критерий сложности;

• критерий времени.

Критерий новизны подразумевает проверку следующих условий:

• инструментальное программное обеспечение является новым (первый раз используемым) для всех разработчиков;

• предметная область проекта является новой (не имеет прямых аналогов среди выполненных проектов);

• тип и/или масштаб приложения являются новыми (не имеют прямых аналогов среди выполненных проектов).

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

Критерий сложности основан на подсчете количества принципиально различных специальных (инструментальных) средств, которые предполагается использовать в проекте. Что именно следует считать специальным средством, зависит от специфики проекта. Например, подготовку ТЗ в Word не следует считать случаем использования специального средства, а написание сотни хранимых процедур для SQL сервера – следует.

Если проект требует не более одного специального средства, то это сверх легкий проект, если 2–3, то легкий, если в проект вовлечено больше трех различных средств, то это тяжелый или сверх тяжелый проект.

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

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

Сверх легкий проект имеет продолжительность до двух месяцев, легкий проект – до 6 месяцев, тяжелый проект – до 9 месяцев и сверх тяжелый проект продолжается год или более.

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

3.4.3.2. Модель процесса сверх легкого проекта Модель процесса сверх легкого проекта имеет вырожденную спиральную структуру, состоящую из одного неполного витка, как показано на рис. 13.

Модель процесса сверх легкого проекта Рис. 13. Модель процесса сверх легкого проекта В модели процесса сверх легкого проекта предполагается, что фазы анализа и проектирования, а также реализации и стабилизации выполняются параллельно. Это обусловлено тем, что • ТЗ совпадает с Концепцией и фаза анализа не имеет главной вехи (что не отменяет необходимости самого анализа задачи), • используется ровно одно инструментальное средство и автономная отладка эквивалентна комплексной отладке.

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

Для сверх легкого проекта фазы анализа / проектирования и внедрения требуют примерно вполовину меньше ресурсов, чем для проектов других типов, поэтому общая продолжительность сверх легкого проекта составляет 0,5+1+0,5=2 месяца.

3.4.3.3. Модель процесса легкого проекта В спиральной структуре легкого проекта второй виток максимально наложен на первый (рис. 14), поскольку на фазе реализации первого витка не ожидается возникновения информации, которая может повлиять на фазу анализа второго витка. Таким образом, для легкого проекта расчет общей продолжительности проводится по формуле 6+1. В типичном случае, считая продолжительность одной фазы равной месяцу, заказчик получает результат через 6 месяцев.

проектирование Рис. 14. Модель процесса легкого проекта Замечание по конструированию В легком проекте заказчик получает результат через 6 месяцев (а не 7) в худшем случае, так как на фазе внедрения приложение (решение) не подвергается радикальным переделкам, а только косметическим улучшениям.

Схематический план-график модели процесса легкого проекта:

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

Модифицированная модель процесса легкого проекта проектирование Рис. 15. Модифицированная модель процесса легкого проекта 3.4.3.4. Модель процесса тяжелого проекта В спиральной структуре тяжелого проекта (рис. 16) второй виток начинается в тот момент, когда достигнута главная веха фазы реализации первого витка и, тем самым, доказана принципиальная возможность реализации при выбранной концепции. Для тяжелого проекта расчет общей продолжительности проводится по формуле 7,5+1,5. В типичном случае, считая продолжительность фаз проектирования и внедрения равной полутора месяцам, а продолжительность остальных фаз равной месяцу, заказчик получает результат через 9 месяцев.

Замечание по конструированию В тяжелом проекте фазы проектирования (и повторного анализа), а также внедрения следует немного удлинить.

Модель процесса тяжелого проекта Рис. 16. Модель процесса тяжелого проекта Замечание по конструированию На схемах спиральной структуры первый выпуск заканчивается выпуском прототипа19, который является законченным приложением (решением), но не является тем экземпляром приложения, который будет реально эксплуатироваться заказчиком после окончания проекта. Это не означает, что результаты пилотного проекта полностью выбрасываются. Напротив, они в максимальной степени используются при построении второго "боевого" варианта приложения (решения).

Схематический план-график модели процесса тяжелого проекта:

Иногда употребляется термин "пилотный проект". Не следует путать "прототип" на этих схемах с "прототипом", о котором речь шла при перечислении вех фазы планирования.

5 Планирование Спецификация Аналитик Переработка предыдущей спецификации 8 Внедрение Проект закончен Эксплуатационник 3.4.3.5. Модель процесса сверх тяжелого проекта Если фаза реализации тяжелого проекта заканчивается неудачей, т.е. вехи "код готов" на первом витке не удается достичь, то проект переходит из категории тяжелых в категорию сверх тяжелых. Такая ситуация означает необходимость увеличить срок выполнения проекта на время, затраченное до момента получения видимой неудачи первоначальной концепции. Если увеличить сроки выполнения проекта невозможно, то проект следует прекратить, чтобы уменьшить неизбежные убытки. В противном случае, т.е. при попытке выполнить проект в намеченные сроки за счет вложения дополнительных ресурсов, возникает очень большой финансовый риск. Если же проект можно удлинить, то он возвращается в категорию тяжелых и проходит согласно модели процесса тяжелого проекта. Таким образом, в типичном случае, считая продолжительность одной фазы равной месяцу, заказчик получает результат сверх тяжелого проекта через 12 месяцев (рис. 17).

Замечание по конструированию Согласно авторитетным зарубежным источникам, сокращение сроков требует не менее чем квадратичного увеличения ресурсов. Например, чтобы сократить сроки вдвое, потребуется вложить вчетверо больше ресурсов.

Модель процесса сверх тяжелого проекта Рис. 17. Модель процесса сверх тяжелого проекта Замечание по конструированию Формально в процессе сверх тяжелого проекта имеется 11 периодов, но продолжительность фаз анализа, повторного анализа и окончательного внедрения следует положить равной 1, месяца.

3.4.3.6. Занятость исполнителей Модель процесса предполагает параллельное выполнение нескольких проектов. Для динамического формирования команд исполнителей и составления индивидуальных плановУМП Технологические подходы к разработке ПО графиков необходимо учитывать схему занятости исполнителей, которая определяется моделью процесса.

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

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

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

Аналитики : Программисты : Эксплуатационники = 2 : 2 : На рис. 18 показана плотная укладка четырех проектов. Фазы первого проекта обведены сплошной линией, фазы второго проекта заштрихованы горизонтально, фазы третьего проекта заштрихованы вертикально, фазы четвертого проекта обведены волнистой линией. Буква А обозначает фазу анализа, П – планирование, Р – реализация, С – стабилизация, О – опытная эксплуатация, В – внедрение. Цифры обозначают номер витка.

сты онники сты Рис. 18 Схема укладки фаз легких проектов на временной шкале Замечание по конструированию Схему укладки реализовать значительно проще, если исполнители владеют смежными специализациями и могут играть различные роли.

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

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

Абсолютные величины трудозатрат по ролям для проектов разных типов (в условных человеко-месяцах):

ник На рис. 20 показано относительное соотношение между трудозатратами для проектов разных типов.

Замечание по конструированию Следует обратить внимание на то, что чем тяжелее проект, тем большую долю составляет работа аналитиков и тем меньшую долю составляет работа программистов.

Рис. 19. Относительное соотношение между трудозатратами для проектов разных типов Замечание по конструированию Сконструированная в соответствии с потребностями программирующей организации абстрактная модель процесса должна быть переведена в конкретную форму, допускающую ее практическое применение. Такой формой в настоящее время чаще всего является документированная процедура. Документированные процедуры описывают различными средствами, в соответствии с корпоративной культурой и иными особенностями организации. В качестве примера приведем описание документированной процедуры «порядок проведения типового проекта» с использованием унифицированного языка моделирования UML и естественного В качестве типового проекта, на примере которого описывается порядок проведения, выбран легкий проект, содержащий разработку вертикального приложения по внешнему заказу.

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

Выполнение проекта другого типа может отличаться в деталях выполняемых действий и в составе документов проекта, но основная процедура является неизменной и состоит в последовательном выполнении трех этапов:

1. подготовка к проекту;

2. работа над проектом;

3. завершение проекта.

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

Рис. 20. Основная процедура проведения проекта 3.4.4.1. Этап 1. Подготовка к проекту На первом этапе подготовки к проекту решаются три основные задачи:

• сбор и анализ предварительной информации;

• формирование бригады проекта;

• подготовка исходных документов.

Сбор информации, формирование бригады и подготовка исходных документов выполняются параллельно, как показано на рис. 22.

Подготовка информации Рис. 21. Процедура «Подготовка к проекту»

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

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

Главной задачей сбора информации на этапе подготовки к проекту является получение оценки экономической целесообразности проекта.

3.4.4.3. Формирование бригады проекта Формирование бригады проекта осуществляется по следующему алгоритму:

1. предварительный анализ;

2. назначение руководителя проекта;

3. подготовка проекта исходных документов;

4. утверждение бригады и запуск проекта.

На рис. 23 приведена процедура формирования бригады проекта и подготовки исходных документов.

Формирование Рис. 22. Процедура «Формирование бригады проекта и подготовка проектов исходных документов»

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

Шаг 1. Предварительный анализ Руководитель подразделения разработки проектов самостоятельно или посредством консультаций производит первичный анализ задачи:

• на соответствие ресурсам;

• на квалификацию исполнителей;

• на экономическую целесообразность;

• на предмет развития структуры подразделения и предприятия в целом.

Замечание по конструированию В описании процедур используются названия подразделений и должностей. Таким образом, считается, что в организации определены организационная структура и штатное расписание.

Итогом первого шага является оценка экономической целесообразности проекта или технико-экономическое обоснование (ТЭО) проекта и кандидатура руководителя проекта.

Замечание по конструированию Технико-экономическое обоснование является более широким документом, чем оценка экономической целесообразности. Как правило, ТЭО предусматривает рассмотрение нескольких вариантов решения и обоснование выбора варианта с точки зрения заказчика. Оценка же экономической целесообразности содержит просто предварительный расчет рентабельности проекта с точки зрения организации-разработчика.

Шаг 2. Назначение руководителя проекта Руководитель подразделения разработки проектов на производственном совещании выносит на обсуждение ТЭО проекта (или оценку экономической целесообразности) и кандидатуру руководителя проекта.

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

Итогом второго шага является решение руководителя предприятия о целесообразности продолжения подготовки к проекту и утверждение кандидатуры руководителя проекта.

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

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

Шаг 3. Подготовка проекта исходных документов Руководитель подразделения разработки проектов знакомит утвержденного руководителя проекта с принятым решением и со всей собранной информацией о проекте. Предлагает детализировать задачу (путем контактов с техническими специалистами заказчика, анализа документов заказчика и т. д.), а также подготовить предложения по составу бригады проекта, распределение ролей в бригаде и оценить необходимые ресурсы на каждом из предполагаемых этапов проекта.

Итогом третьего шага является проект (предварительный вариант для обсуждения) исходных документов, в состав которых могут входить: техническое задание, технические (коммерческие) предложения или «одностраничное» описание проекта; предложения по формированию бригады проекта; предварительная оценка требуемых ресурсов, и, в случае необходимости, предложения по привлечению ресурсов извне.

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

Шаг 4. Утверждение бригады и запуск проекта Руководитель проекта на производственно-техническом совещании выносит на обсуждение свои предложения.

В состав производственно-технического совещания кроме перечисленных выше руководителя предприятия и руководителя подразделения разработки проектов включаются: руководитель проекта, руководители групп (все или только имеющие административное отношение к составу бригады) и ведущие специалисты по усмотрению руководителя предприятия.

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

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

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

3.4.4.4. Подготовка исходных документов К исходным документам относятся:

• Технические (коммерческие) предложения;

• Техническое задание;

• договорные документы;

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

На рис. 24 показана общая процедура подготовки исходных материалов. Предполагается, что заказчик участвует в процедуре согласования и не прекращает подготовку к проекту на данном этапе. Детали подготовки конкретных документов описаны в последующих разделах.

[заказчик Техническое задание, Календарный план, Договорные материалы материалы не утверждены Рис. 23. Процедура "Подготовка исходных документов" Технические (Коммерческие) предложения В случае если руководитель проекта более детально представляет предмет разработки, чем представитель заказчика, он инициирует создание Технических (Коммерческих) предложений, которые служат основой для разработки последующих технических документов, в частности, Технического задания.

Замечание по конструированию В MSF роль "представитель заказчика" называется "менеджер продукта".

Технические (Коммерческие) предложения должны содержать по крайней мере следующие основные части: описание целей проекта, укрупненное содержание работы, (в Коммерческих предложениях – экономический эффект от внедрения), краткие сведения о предприятии-исполнителе.

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

Техническое задание Как правило, Техническое задание (ТЗ) создается руководителем проекта совместно с представителем заказчика. В проекте, регулируемом договорными документами, ТЗ является обязательным документом, поскольку является приложением к договору.

ТЗ является исходным техническим документом, определяющим назначение, конкретные цели и задачи разработки, технические требования, конечные результаты, и сроки выполнения работ на всех этапах проекта.

ТЗ является основанием для расчета трудоемкости работ и стоимости проекта.

Коррекция ТЗ производится путем оформления Дополнения, которое после согласования становится неотъемлемой частью ТЗ.

Замечание по конструированию Согласованное ТЗ обычно включает в себя перечень этапов и является основой для подготовки договорных материалов.

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

• договор;

• техническое задание;

• календарный план со стоимостью каждого этапа и работы в целом;

• протокол согласования договорной цены;

• структура цены.

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

Алгоритм процесса согласования договорных материалов (см. рис. 24):

1. проект договорных материалов (включая ТЗ) в одном экземпляре (или в электронном виде) передается заказчику на предварительное согласование;

2. заказчик возвращает проект с замечаниями технического подразделения, планового и юридического отделов;

3. производится коррекция и оформление договорных материалов;

4. заказчику передаются оригиналы договорных материалов в двух экземплярах в виде твердых копий на окончательное согласование;

5. если согласование не получено, то переход на шаг 3.

3.4.4.5. Этап 2. Работа над проектом При работе над проектом используется управляемая вехами, ориентированная на заказчика, итеративная, параллельная, модель процесса, описанная в разделе 3.4.3.

Для типичного случая работы над легким проектом разработки вертикального приложения процедура работы над проектом представлена на рис. 24. На этой диаграмме состояния – это фазы работы над проектом, а переходы – это главные вехи проекта.

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

Замечание по конструированию Диаграмма на рис. 24 отражает логическую взаимосвязь фаз и главных вех. Фактически, фазы даже одного витка могут перекрываться во времени. Например, фаза стабилизации может быть начата до того, как код полностью готов. Это зависит от типа проекта, используемых инструментальных средств и принятой дисциплины программирования.

проектирование Рис. 24. Процедура "Работа над проектом" 3.4.4.6. Процедура выполнения фазы проекта Состав промежуточных вех (получаемых результатов) для каждой фазы проекта не является фиксированным и зависит от многих субъективных и объективных факторов:

типа проекта;

индивидуальных пожеланий заказчика;

используемых инструментальных средств;

личных предпочтений руководителя проекта.

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

Назначение ролей для выполнения функций, связанных с достижением промежуточных вех на данной фазе проекта, называется командой фазы проекта. Состав команды также не является фиксированным и зависит от различных факторов:

утвержденного состава бригады проекта;

индивидуальных возможностей и способностей членов бригады;

общего состояния хода работы над проектом;

состояния других проектов, в которых задействованы сотрудники, входящие в бригаду проекта;

внешних обстоятельств (например, возникновения незапланированных работ вне проекта).

Таким образом, процедура выполнения конкретной фазы проекта является предметом динамического (оперативного) планирования, которое выполняется руководителем проекта.

Диаграмма процедуры выполнения фазы приведена на рис. 25.

Выполнение фазы проекта Формирование команды фазы и плана фазы Достижение внутренних вех Рис. 25. Процедура "Выполнение фазы проекта" На этой диаграмме подразумевается, что "Достижение внутренних вех" – это множество однотипных составных активностей, которые могут выполняться параллельно для всех вех фазы (в том числе для главной вехи).

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

Замечание по конструированию Руководитель проекта может играть или не играть определенные роли на различных фазах в зависимости от типа и других особенностей проекта. Загрузка всех ролей может быть полной или частичной. Например, для сверх легкого проекта Руководитель проекта играет все роли и загружен на 100%. Для сверх тяжелого проекта с большой бригадой Руководитель проекта играет, в основном, роль администратора ("освобожденный руководитель") и только эпизодически выполняет иные функции, при этом его загрузка может быть менее 100%.

План выполнения фазы План выполнения фазы должен содержать следующую информацию:

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

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

оценка (переоценка, если риск был оценен для проекта в целом) рисков фазы;

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

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

На рис. 26 приведен пример: фрагмент плана фазы проектирования для некоторого условного проекта. На рис. 28 тот же пример плана представлен в форме таблицы.

Диаграммы прецендентов Функциональные спецификации Пользовательские формы Рис. 26. План фазы проектирования, построенный с помощью Microsoft Project Функциональ- Диаграммы 01.01-15.01 1 неделя Аналитик А.А.Аналитиков 100% ные специфи- прецедентов Прототип Пользователь- 15.01-30.01 2 недели Програм- П.П.Програм- 100% Рис. 27. Календарный план фазы проектирования в форме таблицы Замечание по конструированию Использование Project позволяет не только представить план в наглядной форме, но и анализировать план, например, определять критические задачи, выявлять перегруженные ресурсы и т.п. Поэтому в проектах, выполняемых по стандарту, рекомендуется использование Project и не рекомендуется использование упрощенных форм планирования типа таблиц.

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

3.4.4.7. Подготовка результирующих материалов вех Состав материалов, которые готовятся на втором этапе в ходе работы над проектом и составляют отчуждаемый результат проекта, существенно зависит от типа и объема проекта.

Для типичного проекта разработки вертикального приложения на заказ возможный состав материалов кратко описан в разд. 3.4.3. Различаются внешние материалы проекта, которые согласуются с заказчиком и/или входят в состав результатов проекта, предусмотренных Техническим заданием, и внутренние материалы, которые заказчику не предоставляются.

Замечание по конструированию Из сказанного не следует, что внешние материалы готовятся только для заказчика, а внутренние материалы исчезают при завершении проекта. Напротив, внешние материалы интенсивно используются бригадой проекта, а внутренние материалы архивируются после завершения проекта для повторного использования в последующих проектах. В связи с этим к качеству оформления внешних и внутренних материалов предъявляются одинаковые требования.

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

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

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

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

Замечание по конструированию В ЕСПД Концепции соответствует Эскизный проект. Если организация склонна к использованию терминологии ЕСПД, то документ "Концепция" можно называть "Эскизный проект", от этого суть и назначение документа не меняются.

Оценка риска На этапе подготовки к проекту производится начальная оценка риска.

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

Замечание Оценка риска является внутренней информацией, которая используется Руководителем проекта и руководством при планирования процесса, выделении и перераспределении ресурсов.

Как правило, оценка риска не предоставляется заказчику. Однако, в некоторых специальных случаях особых отношений с заказчиком оценка риска может включаться в ТЗ. Методика оценки риска является отдельной достаточно сложной процедурой, не включенной в данной описание процесса.

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

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

календарный риск, который ставит под угрозу срок выполнения этапа или проекта в целом;

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

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

Оценка риска может быть самостоятельным документом, а может входить в качестве раздела в ТЭО.

Замечание по конструированию Переоценка риска производится на каждой фазе для всех типов проектов, кроме сверх легкого.

Спецификации Спецификации проекта являются основным результатом фазы анализа. Как правило, спецификации проекта состоят из нескольких материалов различного типа.

Функциональные спецификации. Исчерпывающее и подробное описание функций решения. Для описания функциональных спецификаций могут использоваться разнообразные средства: естественный язык; специальные таблицы; формальные языки; компьютерные средства моделирования и др. Наиболее перспективным является применение средств моделирования, поддерживающих Unified Modeling Language (UML).

Замечание по конструированию Следует различать внутренние и внешние спецификации. Во внешних спецификациях не должно быть деталей реализации, которые не интересны заказчику. Если они появляются – это путает и пугает заказчика. В то же время только описания сценариев и пользовательских форм не достаточно для программистов, пишущих код. Унифицированный язык моделирования UML является тем средством специфицирования, которое позволяет перейти от внешних спецификаций к внутренним путем последовательного уточнения, и поэтому должно использоваться как основное средство.

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

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

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

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

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

Замечание по конструированию В некоторых случаях План тестирования не включается в Спецификации, а является первой промежуточной вехой фазы стабилизации.

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

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

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

Именно поэтому диаграммы UML могут служить в качестве результатов таких вех, как Спецификации, Логический проект, Физический проект и даже Код готов (если средства автоматической генерации кода это позволяют).

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

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

Пользовательская документация В большинстве проектов на фазе внедрения составляется документ (или несколько документов) с названием «Руководство пользователя».

3.4.4.8. Этап 3. Завершение проекта Назначение третьего завершающего этапа состоит в том, чтобы подготовить результаты проекта к повторному использованию. Таким образом, завершающий этап выполняется в интересах программирующей организации, а не заказчика. Признаком перехода на завершающий этап является подписание акта сдачи-приемки работы. На рис. 28 приведена диаграмма, иллюстрирующая порядок завершения проекта.

В ЕСПД План внедрения и План тестирования оформляются как один документ с названием Программа и методика испытаний. Если организация склонна к использованию ЕСПД, то "План внедрения" можно называть "Программа и методика испытаний". План тестирования лучше иметь в виде отдельного документа.

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

Отзыв заказчика Отзыв заказчика – это обобщенное название документально зафиксированного факта удовлетворенности заказчика результатами проекта. Отзыв может иметь различные формы, например:

формальный отзыв в виде письма на бланке заказчика;

письменное разрешение заказчика на публикацию результатов проекта в открытой печати;

письменное разрешение заказчика на использования названия фирмы заказчика и других данных в маркетинговых материалах.

Целесообразность получения и предпочтительная форма отзыва заказчика определяются с помощью отдела маркетинга.

3.4.4.9. Архивирование результатов работы Исходные, промежуточные и отчетные документы проекта существуют в виде файлов, а также в виде твердых копий; копии либо передаются заказчику, либо являются рабочими документами для организации технических семинаров проектной группы. Для архивирования результатов работы:

Технические материалы проекта помещаются в папку коллективного доступа, которую определяет администратор сети. Доступ к этой папке ограничен (для технических специалистов). По мере накопления материалов проектов, по усмотрению администратора сети, материалы проектов целиком переносятся на компакт-диски для постоянного хранения.

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

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

3.4.4.10. Подведение итогов проекта После архивации результатов проекта Руководитель проекта составляет отчет о результатах проекта, в котором содержится следующая информация:

общие сведения о выполненном проекте: название, шифр, календарные сроки выполнения, краткие сведения о заказчике, состав бригады проекта, краткие сведения о назначении проекта, тип проекта, перечень использованных технологий и инструментов;

точные ссылки на все архивированные результаты проекта;

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

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

Кроме отчета, Руководитель проекта составляет три приложения к отчету:

Анализ экономической эффективности проекта. Анализ производится путем сравнения плановых показателей экономической эффективности в ТЭО и фактических показателей, измеренных в ходе проекта.

Предложения по премированию бригады проекта. Предложения по премированию по результатам успешного проекта подготавливаются Руководителем проекта в соответствии с нормативными документами организации.

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

На производственном совещании, посвященном подведению итогов проекта,21 рассматриваются подготовленные Руководителем проекта отчетные документы и принимаются соответствующие административные и организационные решения. Проект завершается изданием приказа (рис. 28).

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

На бюрократическом жаргоне такое совещание называют "разбор полетов".

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

• учет рабочего времени (трудозатрат и производительности);

• ведение регулярной отчетности (в проекте и вне проекта);

• проверка качества материалов (нормоконтроль);

• управление документами.

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

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

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

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

внутренняя отчетность в рамках проекта;

внешняя отчетность в рамках проекта (перед заказчиком);

внутренняя отчетность в рамках организации.

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

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

В типичном случае для проведения проектов достаточно еженедельного22 отчета руководителя проекта,23 адресованного руководителю подразделения, и включающего:

1. список вех, достигнутых за прошедшую неделю;

2. персональный состав команды фазы с указанием процента занятости за прошедшую неделю;

3. список вех, планируемых на следующую неделю;

4. персональный состав команды фазы с указанием процента занятости на следующую неделю;

5. список особых обстоятельств, например, факт невыполнения плана, проблемы с материально-техническим обеспечением, переоценка факторов риска и т.п.

Замечание по конструированию ISO 9000 рекомендует коэффициент 3 для периодичности отчетности разных уровней, т.е. на каждые три периода получения отчетов от подчиненных должен приходиться один период представления отчета начальнику.

3.4.5.3. Проверка качества материалов Для обеспечения повышения качества процесса проведения проектов определенные виды отчуждаемых материалов (документов) проверяются и визируются Комитетом Качества.

Порядок проверки и визирования определяется Комитетом Качества. Например, Комитет Качества может назначить своего представителя для проверки конкретного документа или всех документов определенного типа. Проверке и визированию подлежат все внешние (т.е. предоставляемые заказчику) материалы и планы фаз. По усмотрению Комитета Качества для некоторых или всех проектов могут проверяться все или некоторые внутренние материалы. Проверка имеет целью установить степень соответствия материала принятым стандартам.

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

Проверка соответствия материала требованиям и рекомендациям и указание на несоответствие.

Указание на очевидные (например, орфографические) ошибки.

Указание на несоответствие хорошему тону, здравому смыслу и деловому стилю.

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

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

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

Периодическая отчетность руководителей подразделений здесь не рассматривается.

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

1. Общая процедура проведения проекта состоит из трех этапов: подготовка к проекту, работа над проектом, завершение проекта. Этапы не могут быть опущены.

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

3. Схема проекта имеет нелинейный (итеративный и параллельный) характер и не противоречит модели процесса. Отклонения схемы проведения проекта от типовых схем документированы и обоснованы.

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

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

6. Назначение сотрудников на выполнение роли происходит динамически на каждой фазе проекта.

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

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

9. Результаты проектов архивируются и подготавливаются для анализа и повторного использования.

Замечание по конструированию Принятые модель жизненного цикла и модель процесса разработки взаимно определяют друг друга и являются согласованными. Некоторая разница в терминологии объясняется разными точками зрения на предмет: с точки зрения программиста и с точки зрения программы. Однако фазы и вехи строго соответствуют другу, хотя и по-разному названы. В таблице 4 указано это соответствие для фаз.

Таблица 4. Соответствие терминов жизненного цикла и модели процесса Проектирование (логическое)24 Проектирование Модель, схемы, диаграммы В дисциплине программирования проектирование подразделяется на концептуальное, логическое и детальное. Логическое проектирование выполняется на фазе проектирования, концептуальное – на фазе анализа, а детальное – на фазе реализации (см. раздел Проектирование).

Тема 4. Модели команды разработчиков Если программа разрабатывается индивидуально, одним человеком, то проблем взаимодействия с самим собой обычно не возникает. В современных условиях программное обеспечение разрабатывается коллективами, иногда очень большими коллективами. В таких коллективах проблемы взаимодействия являются постоянными и иногда очень сложными. Сами проблемы, несомненно, относятся к процессу разработки программного обеспечения, а способы решения этих проблем относятся к технологии программирования.

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

В этой теме рассматриваются различные абстрактные модели команды, и приводится пример конструирования конкретной модели для гипотетической организации.

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

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

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

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

Замечание Регулярное общение означает разговор с кем-либо в течение примерно двух часов в неделю.

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

В современных условиях используются три основных вида организации подчиненности (субординации):

• Линейно-функциональная;

• Проектно-ориентированная;

А если возникают, то такие проблемы относятся к области психологии или психиатрии, но не к технологии программирования.

• Матричная.

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

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

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

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

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

4.1.3. Развитие команды и развитие персонала Каждый проект, кроме достижения основной своей цели, должен использоваться руководителем проекта для развития команды. А именно, в процессе выполнения проекта:

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

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

4.1.4. Специализация, кооперация и взаимодействие Программирование отнюдь не однородно. В модели процесса мы выделили несколько фаз. Успешное выполнение каждая из фаз требует наличия определенных навыков у работников. Частично эти навыки для разных фаз совпадают, но есть и специальные навыки, которые специфичны для некоторой фазы. Например, если в проекте применяются формальные методы, то на фазах анализа и проектирования может потребоваться владение математическим аппаратом в таких объемах, которые не предусматриваются программами учебных заведений, готовящих программистов.26 Другой пример: на фазе внедрения требуется написать пользовательскую документацию. К сожалению, практика показывает, что большинство программистов просто не в состоянии написать хорошее руководство для пользователя – нет навыка, нет опыта. Поэтому специализация «технический писатель» является сейчас даже более дефицитной, чем «системный архитектор».

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

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

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

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

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

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

Иерархическая модель команды Рис. 29. Иерархическая модель команды В то же время иерархической модели присущи некоторые принципиальные недостатки.

Иерархическая модель экстенсивна. Наращивание функциональности обеспечивается увеличением состава.

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

Чтобы подчеркнуть это обстоятельство, на рис. 29 использована "армейская" терминология.

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

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

Иерархическая модель не устойчива по отношению к личным качествам руководителей.

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

Модель главного программиста появилась во время первой технологической революции в программировании на рубеже 60–70-х годов. Долгое время модель главного программиста (или метод хирургической бригады, или модель звезды, рис. 30) являлась доминирующей моделью при разработке программного обеспечения.

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

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

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

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

Бригада главного программиста наследует все достоинства принципа единоначалия (поскольку главный программист единолично принимает все принципиальные решения по проекту).

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

Модель бригады главного программиста (звезда) Рис. 30. Модель бригады главного программиста Метод бригады главного программиста допускает различные модификации при сохранении своей сути.

Первая модификация: изменение количества и качества лучей в звезде. В классической модели, описанной в книге Брукса [3], в звезде еще присутствовали второй Секретарь и Языковед. В практических случаях количество лучей сокращают, например, объединяя Секретаря, Редактора и Архивариуса. Характеристическими ролями в бригаде являются Главный программист, Второй пилот и Администратор, остальные роли меняются по мере развития технологий программирования.

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

Третья модификация: "сдвоенный центр" (рис. 31). Эта модификация позволяет хотя бы в некоторых пределах масштабировать бригаду. Имеются два Главных программиста, которые делят проект пополам, все решения принимают консенсусом и являются вторыми пилотами друг для друга.

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

Модификация модели бригады главного программиста Рис. 31. Модификация модели бригады главного программиста Модель бригады главного программиста имеет определенные недостатки.

Бригада главного программиста не является масштабируемым решением. Она отлично работает на проектах объема 6-8 человек 1-2 года. Если проект требует более коротких сроков или существенно больших объемов, то использование бригады главного программиста затруднено.

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

Бригада главного программиста не является распараллеливаемой структурой. Она действует по принципу: один проект – одна команда. Практически невозможно выполнять бригадой одновременно разные фазы разных проектов.

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

Замечание Второй пилот в бригаде главного программиста должен тщательно отслеживать все действия главного программиста. Это несколько снижает риск аннигиляции.