Формирование базовой линии конфигурации проекта
Пример процедуры создания инфраструктуры проекта
Для создания инфраструктуры необходимо:
· обеспечить поставки материальных ресурсов - требуется заказать или запросить необходимые ресурсы;
· организовать установку оборудования - обеспечить доставку, провести установку и тестирование оборудования;
· обеспечить сервисное обслуживание оборудования - разработать график сервисного обслуживания;
· протестировать рабочую среду на предмет ее совместимости с требованиями к функциональности, совместимости и доступности.
Базовая линия или фиксированный срез конфигурации - набор элементов конфигурации, формально определенный и зафиксированный по времени в процессе жизненного цикла ИС. В определенных случаях базовая линия может изменяться только через формальную процедуру контроля изменений. Фиксированный срез в сочетании со всеми утвержденными изменениями в отношении его представляет собой текущую утвержденную конфигурацию .
Различные элементы конфигурации передаются под управление конфигурацией в различные моменты времени и включаются в базовые линии в определенных точках жизненного цикла . Инициирующим событием является завершение определенных форм формального утверждения задач, таких как формальная оценка. Примерами элементов конфигурации могут служить настроенные модули ИС, руководство пользователя, планы тестирования, базы данных тестов и прочее.
Для организации выполнения вышеперечисленных задач на стадии планирования ЖЦ ИС разрабатывается план управления конфигурацией, где излагается концепция и определяются средства для автоматизации процесса, а также расписываются все роли и деятельности в зависимости от стадии жизненного цикла ИС.
План управления конфигурацией (УК) разрабатывается на ранних стадиях этапа планирования и является частью плана управления проектом . Структура плана УК зависит от таких факторов, как тип проекта и его длительность, уровень формализации процессов, размер команды и прочее. Это означает, что структура плана в зависимости от проекта может существенно изменяться. В работе выполнен анализ факторов, влияющих на структуру плана.
Так, наличие нескольких офисов усложняет план, дополняя его регламентами взаимодействия между офисами, влияет на общую архитектуру проекта. Увеличение числа регионов воздействует на уровень формализма плана.
Относительный размер проекта воздействует на количество регламентов и их проработанность и детальность. Фазы, взаимодействие между группами, прохождение запросов на изменения описываются более детально. Чем крупнее проект, тем более формализованным должен быть план.
Количество конфигурационных элементов влияет только на более глубокую проработку идентификации элементов. В некоторых случаях полезно определить в плане все типы конфигурационных элементов на основании шаблонов.
Количество компонентов и подсистем влияют на выборку элементов из репозитория (способ выборки и обращения) и глубину изложения раздела, описывающего структуру проектного каталога План УК обычно описывает все фазы жизненного цикла ИС. Иногда при работе с субподрядчиками бывает необходимо более четко выделить фазу, на которой подключается субподрядная организация.
На ход проекта и на план оказывают существенное воздействие такие факторы, как используемые средства разработки , платформа разработки (возможна разработка на нескольких платформах и для нескольких платформ одновременно). Большое значение имеют тип и количество средств реализации (автоматизации УК), их принадлежность одному или нескольким вендорам. Например, в проекте можно использовать средство управления версиями от одного производителя, а средство управления изменениями - от другого. Тип интеграции между средствами, архитектура интеграции должны быть детально рассмотрены в плане УК.
Уровень формализации зависит от многих факторов. Выбирая уровень формальности и глубины изложения, необходимо руководствоваться исходящими задачами и целями. Такие факторы, как сложность проекта, региональная разбросанность, тип проекта, наличие субподрядчиков, должны автоматически подвигнуть к написанию высоко формализованного плана УК. Средний и низкий уровень могут применяться в относительно краткосрочных проектах, проектах, в которых задействовано небольшое количество разработчиков. С ростом команды, разделением ролей план УК должен быть пересмотрен, уровень формализации поднят. В таблице 42 представлен пример структуры плана УК.
В зависимости от размера проекта некоторые пункты плана могут быть пропущены.
На стадии планирования управления конфигурацией необходимо также определить, какие программное обеспечение и аппаратные средства обеспечат достижение целей проекта, разработать планы по контролю и созданию документов проекта, а также определить стратегии, стандарты и процедуры проекта, обеспечивающие управление конфигурацией , документировать, каким образом будут идентифицироваться, организовываться и контролироваться элементы конфигурации.
8.4. Организация документирования статуса элементов конфигурации
Пример процедуры обеспечения хранения документов.
Вся документация по проекту хранится в библиотеке проекта. Библиотека организована для обеспечения гарантии доступности документов команде проекта; регистрации и хранения копий измененных документов; хранения справочных материалов, включая документацию по стандартам; поддержки административной информации по проекту; хранения текущей (рабочей) информации.
Пример процедуры подготовки документов
Все документы проекта должны иметь титульный лист, историю изменений, список рецензентов, таблицу рассылки.
Титульный лист обязательно содержит тему документа, автора, дату создания, дату последней модификации документа, идентификатор, по которому можно делать ссылки на документ, номер версии документа, кем утверждается документ.
История изменений включает дату изменения, автора вносимого изменения.
Пример процедуры отчетности о деятельности
Процедура отчетности о деятельности заключается в налаживании и поддержании процесса предоставления отчетности по реализации проекта. Управление временными рамками проекта осуществляется посредством отслеживания результатов проделанной работы, сообщения о которых являются частью предоставляемой отчетности.
Проектные документы будут готовиться проектными группами в ходе всего проекта, в соответствии с планом работ по проекту.
Все проектные документы будут передаваться на согласование и утверждение заказчику. Открытые вопросы по документу фиксируются в последнем разделе каждого документа "Открытые вопросы для настоящего документа" с вариантами решения вопроса. Открытые вопросы, которые не могут быть решены на уровне проектных групп и руководителя проекта, дублируются в журнале проблем и открытых вопросов, в соответствии с процедурой управления проблемами и открытыми вопросами.
Утвержденные проектные документы будут являться основой для последующих проектных работ.
Для выполнения документов будут использованы следующие программные средства:
· Microsoft Word 2010 - для подготовки текстовой части проектных документов;
· Microsoft Project 2010 - для подготовки планов проекта;
· Visio 2010 - для графического описания бизнес процессов.
Вся проектная документация будет храниться в электронном виде в библиотеке проекта.
Таблица 7.3. Структура плана управления конфигурацией (адаптировано из )
| Раздел плана | Требования к содержанию | Дополнительные комментарии |
| 1. Введение | Введение в план УК представляет собой обзор содержания документа. Включает цели, область действия, определения, акронимы, сокращения, ссылки и обзор планаконфигурационного управления | Введение позволяет сделать документ более читаемым - объяснить основные моменты и расставить правильные акценты |
| 1.1 Назначение | Содержит назначение документа "План конфигурационного управления " | Как правило, в назначение можно включить описание целей, которые решает данный план. Ведь план, в зависимости от размеров проекта, от географического распределения, также может различаться |
| 1.2 Область применения | Краткое описание области применения плана; с какой моделью он связан, другие особенности, влияющие на документ | Зачастую можно описать подразделения, участвующие в процессе УК. Описать условия применения. При определении области полезно ответить для себя на ряд вопросов: · Какова характеристика подконтрольных конфигурационных элементов? · Чем должны управлять интерфейсы высокого уровня? · Каковы временные рамки проекта? · Каковы доступные ресурсы? · Каковы подконтрольные сущности? |
| 1.3 Определения, акронимы и сокращения | Представляет собой определения всех терминов, акронимов и сокращений, требующихся для точной интерпретации документа "План конфигурационного управления ". Для предоставления этой информации можно воспользоваться ссылками на словарь проекта | Нам часто приходится сталкиваться с тем, что данный раздел либо игнорируют совсем, либо не придают ему особого значения. Те не менее, глоссарий - это составная и неотъемлемая часть ЛЮБОГО документа, плана УК в том числе.Здесь необходимо отразить и объяснить все термины УК и разрабатываемого продукта. Необходимо помнить, что хороший глоссарий позволит всем находиться в одном терминологическом пространстве. Вопросы: · Определения легки и понятны всем участникам проекта? · Есть ли список, на который можно легко сослаться? · Необходимо ли определять данный термин? |
| 1.4Ссылки | Этот подраздел представляет полный список всех документов, на которые имеется ссылка где-либо в "Плане конфигурационного управления ". Идентифицируется каждый документ по названию, номеру отчета (если есть), дате и организации, его опубликовавшей. Указывается источник, из которого могут быть получены указанные документы. Для предоставления этой информации можно воспользоваться ссылками на приложения или другие документы | План УК редко разрабатывается сам по себе. Он является частью нормативно-методического обеспечения проекта. Нет смысла в плане повторять дословно разделы из других документов. Проще сформировать ссылку на документ, а в данном разделе указать все используемые источники (в том числе документы RUP, стандарты, международные и отраслевые стандарты). Вопросы: · Применяются ли в плане положения, методики политики, уже используемые в организации? · Действительно ли ссылка необходима в плане? |
| 1.5 Обзор | Обзор документа по разделам | Необходимо понимать, что не все участники проекта будут читать документ от корки до корки. Обзор необходим для того, чтобы впоследствии можно было читать те разделы, которые нужны в данный момент данной роли |
| 2. Конфигурационное управление программным продуктом | Один из основных разделов. Описывает все технические и технологические аспекты применения УК в проекте или организации.Количество подразделов и их вложенность могут отличаться от приведенных ниже | |
| 2.1 Организация, распределение ответственности и взаимодействия | Указывается, кто будет ответственным за выполнение различных задачконфигурационного управления , описанных в ходе процессовконфигурационного управления | Данный пункт оговаривает не только список ответственных за выполняемые действия, но может описывать состав и взаимодействие между проектными группами. Данный аспект особенно важен, если речь идет о разработке, распределенной по нескольким географическим точкам. Эффективное дополнение данного раздела - подраздел, описывающий политику доступа. Это может быть простая таблица, в которой описывается в терминах применяемых средств автоматизации процесса, что можно выполнять отдельному участнику проекту, а что для него запрещено. Обычно для этого выбирают способ описания либо только доступных операций, либо только запрещен-ных.В дальнейшем данная политика перекладывается в средства реализации, где выставляются соответствующие разрешения и запрещения. В зависимости от выбранной проектной структуры (матричной или иерархической) адаптируется политика. Вопросы: · Каковы возможности организации по штату для выполнения операций УК? · Какова структура управления? · Каков стиль управления? · Кто будет ответственным за выполнение операций? · Какие организационные изменения могут быть в течение жизни плана УК? · Каковы планы по поддержке текущей организационной структуры? · Какой уровень поддержки необходим для осуществления плана УК? · Это единственный проект для руководства, или руководство управляет несколькими проектами одновременно? · Как распределяется ответственность при возникновении нештатных ситуаций? · Имеются ли особенности для этого проекта, которые могут повлиять на бизнес? · Какие действия выполняет группа ССВ в проектном управлении при планировании? · Прозрачно ли описаны роли участников? |
| 2.2 Инструментарий, рабочая среда и инфраструктура | Рассматриваются рабочая среда и программное обеспечение, которое будет использовано при выполнении функций конфигурационного управления в ходе жизненного цикла проекта или программного продукта. Описываются инструменты и процедуры, которые нужно использовать для версионного контроля объектовконфигурационного управления , создаваемых в ходе жизненного цикла проекта или программного продукта.Вопросы, рассматриваемые при настройке рабочей среды конфигурационного управленияюжидаемый размер данных по программному про-дукту;распределение рабочей команды;расположение серверов и рабочих станций | Детальное описание данного пункта позволит, для начала, понять самим, какие средства разработки используются в компании (зачастую до начала внедрения в большой компании никто, кроме начальника отдела разработки, не представляет полного списка средств). Полный учет средств необходим еще и для того, чтобы определить методы интеграции средств разработки со средствами УК, ведь известно, что любое средство УК имеет ограниченные возможности по интеграции со средствами разработки. Задача менеджера УК и администратора в этом случае заключается в том, чтобы выбрать сторонние разработки, которые либо делают интеграцию более полной, либо просто добавляют саму интеграцию в используемое средство разработки + в средство УК. Не менее важно описать среду исполнения. Не все средства УК одинаково ставятся на всех платформах. Здесь могут быть особенности. Как вариант: сервер Linux, клиенты Windows. Не все средства УК умеют работать в подобной среде, что надо учитывать при выборе средства. Вопросы: · Каковы организационные интерфейсы? · Как взаимодействуют процессы? · Каков перечень процессов для взаимодействия? · Каковы интерфейсы между применяемыми средствами автоматизации? · Какова зависимость между ними? · Есть ли аппаратная зависимость? · Где определены документы, регламентирующие процесс? · Они утверждены? · Каковы процедуры внесения изменений в эти документы? · Каковы задействованные ресурсы (человеческие, оборудование)? |
| 3. Программа конфигурационног о управления | ||
| 3.1 Конфигурационная идентификация | Вопросы: · Доступны ли стандартные методы идентификации? · В чем состоит используемая схема идентификации объектов УК? · Связаны ли программная и аппаратная идентификация (для встроенных систем)? · Какие спецификации и планы управления должны быть идентифицированы? · Необходима ли специальная схема идентификации, чтобы отслеживать ПС третьей стороны? · Есть ли разница в идентификации элементов в зависимости от типа приложений? · Есть ли подтипы (например, компилятор C++ может работать с файлами с, срр, h, hpp и др)? · Идентифицируются ли и хранятся скрипты автоматизированного тестирования? | |
| 3.1.1 Методы идентификации | Описывается, как именуются, маркируются и нумеруются артефакты проекта или программного продукта. Схема идентификации должна покрывать оборудование, системное программное обеспечение, продукты внешних разработчиков и все артефакты разрабатываемого приложения, указанные в структуре директорий программного продукта; например, модели, планы, компоненты, тестовое ПО, результаты и данные, исполняемые файлы и т.д. | Очень важный пункт, в котором нужно описать все правила именования объектов УК. Также здесь должна быть детально расписана структура каталогов проекта. Обычно к моменту внедрения УК структура каталогов проекта складывается исторически, зачастую - спонтанно. Цель описания - выработать новую, более эффективную структуру. Практика показывает, что человек на этапе восстановления структуры может увидеть уязвимые или неэффективные места |
| 3.1.2 Базовые версии проекта | Базовые версии предоставляют официальный стандарт, на котором основывается последующая работа и для которого проводятся только авторизованные изменения. Описывается, в какой точке жизненного цикла проекта или продукта должны создаваться базовые версии. Наиболее общие базовые версии должны быть в конце каждой из фаз обследования, проработки проекта, построения системы и передачи в эксплуатацию. Базовые версии также могут создаваться в конце итераций внутри различных фаз или даже чаще. Определяется, кто может создавать базовые версии и что входит в их состав (обычно это интегратор, но может быть и по-другому) | Здесь описывается то, каким образом будет происходить сама работа в средстве УК: как будут ставиться метки, как выпускаться релизы, сколько ветвей для реализации проекта будет использовано и по какому принципу ветви будут именоваться. Обратите особое внимание на данный пункт - без него невозможна эффективная работа. При проработке пункта учитывается региональная раздробленность команды (влияет состав команд, количество регионов), интенсивность внесения изменений, количество выпускаемых релизов за единицу времени. Соответственно, в зависимости от данных показателей выбирается наиболее эффективный способ управления конфигурациями, что и отражается в данном разделе.Вопросы: · Какой способ выбора базовых версий используется? · Для всех ли элементов базовые версии строятся по одинаковым правилам? · Кто разрешает создание базовых версий? · Кто физически создает базовую версию? · Как и по какому шаблону создаются базовые версии? · Как осуществляется продвижение базовых версий? · Как и кем осуществляется проверка базовых версий? · Какова периодичность проверок? · Используется ли существующий (устоявшийся) стандарт именования меток и ответвлений? - Есть ли иерархия между объектами? Какая? |
| 3.2 Контроль конфигураций и изменении | Как известно, процесс УК состоит из двух частей -управление изменениями и управления версиями. Управление изменениями - неотъемлемая и важная часть процесса. Управлять необходимо любыми изменениями: от заявок пользователей до исправляемых дефектов. Данный раздел содержит полное описание всех запросов на изменения, включая атрибуты и жизненный цикл. Подробное описание - залог успешно построенного процесса УК.Очень часто для отслеживания существенных событий в проекте применяют уведомления различного вида. Как правило, это уведомления по электронной почте (например, при исправлении ошибки тестер получает уведомление и может приступить к тестированию). Укажите все типы уведомлений, которые применяются в проекте. Вопросы: · Какие типы запросов планируется использовать в процессе УК? · Каков полный цикл запросов на изменения? · Будет ли храниться в системе УК справочная информация, или необходимо подключаться к имеющейся справочной информации? · В какой информации, возможно, будут нуждаться члены ССВ? · Каковы основные ожидания от автоматизации управления изменениями? · При иерархической проектной структуре как будут приниматься решения по запросу? · Необходимо ли управлять всеми запросами на изменения? · Какой уровень детальности управления будет выбран (сколько шагов/этапов)? · Обеспечивается ли отслеживание изменений в исходных текстах (есть ли связь между изменениями на верхнем уровнем и описанием изменений на уровне файлов)? · Как исходный текст ассоциируется с запросом? · Будет ли применена система оповещений ? | |
| 3.2.1 Отработка и утверждение запросов на изменение | Рассматриваются процессы, которые обеспечивают внесение, рассмотрение и упорядочение проблем и изменений | Определяются типы запросов. Как правило, это дефект, запрос на расширение, задача и заявка. Состав типов может существенно меняться, главное - не сводить все управление изменениями к одному типу запросов (очень часто, кроме как дефектами компании, ничем не управляют) |
| 3.2.2 Группа управления изменениями | Описывается, кто входит в состав группы управления изменениями, и процедуры, которым она следует, для отработки и утверждения запросов на изменение. В некоторых случаях указывается регламент сбора группы | Решение о принятии запроса от пользователя, решение о реализации новой технической идеи практически никогда не принимаются одним человеком. В любой компании это группа людей. В терминах стандартов данная группа называется ССВ. В данном разделе необходимо описать состав участников (как правило, это аналитик или постановщик, лидер группы разработчиков, лидер группы тести-ровщиков и представитель отдела маркетинга) и периодичность заседаний. Например, группа ССВ может собираться каждую неделю (по регламенту) либо по возникшей потребности (не рекомендуется). Вопросы: · Каковы пределы полномочий группы? · Одна группа на все проекты или несколько групп, каждая на свой проект? · Если несколько, то каким образом они сотрудничают друг с другом? · Есть ли иерархия ССВ? · Кто отвечает за коммуникации между ССВ? · Будет ли поддерживать система УК специальные запросы для организации встреч и выпуска протоколов по результатам? · Есть ли потребность в выработке регламента для ограничения действий группы (жесткий регламент встреч с высокой степенью формализма)? · Как различаются уровни привилегий в группе? · Меняет ли введение группы ССВ установленный порядок принятия решений в организации? · Введены ли в состав ССВ все ключевые участники, включая менеджера УК, менеджера проекта, лидера тестировщиков, лидера разработчиков и архитекторов? · Каковы процедуры устранения разногласий (выпуск протокола разногласий или нечто иное)? · Автоматизирована ли данная процедура? |
| 3.3 Учет состояния конфигурации | ||
| 3.3.1 Хранение материалов проекта и выпуск релизов | Описываются правила хранения и регламенты резервирования, действия на случай непредвиденных обстоятельств.Опи-сание процесса выпуска релизов включает их содержание, для кого они предназначены и имеются ли какие-либо известные проблемы и инструкции по инсталляции (можно вынести в отдельное приложение) | |
| 3.3.2 Отчеты и проверки | Рассматривается содержание, формат и цель запрашиваемых отчетов и проверок состояния конфигурации. Отчеты используются для получения данных о качестве программного продукта в любой заданный момент времени жизненного цикла программного продукта или проекта. Отчетность по дефектам, основанная на запросах на изменения, может обеспечить некоторые удобные индикаторы качества и, следовательно, предостеречь предупредить? Потому что предостеречь ОТ чего-либо менеджеров и разработчиков об определенных критических областях процесса разработки | Отчетам следует уделить особое внимание. Только по отчетам можно проследить ход выполнения работ. Здесь необходимо определить отчеты по ролям участников проекта и описать их формат. Также рекомендуется сформировать регламент сбора отчета, то есть, с какой периодичностью собираются метрики (в реальном времени, раз в день... и т. д.). Желательно выделить различные типы отчетов и периодичность сбора их метрик. Вопросы: · Есть ли необходимость в более чем одной ревизии для каждой базовой версии? · Вовлечены ли субподрядчики в ревизию? Отчеты Вопросы: · Какие метрики собираются в ходе проекта? · Какие типы отчетов необходимо иметь? · Каковы способы представления отчетной информации? · Есть ли внешние отчетные документы для клиентов? · Дифференцируются ли отчеты в зависимости от типа выполняемой участником роли в проекте ? · Доступны ли отчеты? · Какие будут предусмотрены формальные шаги для получения отчетов? · Какие типы нотификационных сообщений будут применяться? · Отслеживаются ли тенденции в проекте? По каким отчетам? · Как ведется учет (статически, динамически)? · Какие средства используются для получения отчетов (допускается использование любого числа систем для получения достоверной и понятной информации о ходе проекта)? |
| 3.3.3 Документирование | Раздел определяет способы и типы документов | |
| 3.3.3.1 Описание версии | Данный документ описывает диски, CD или другие носители, используемые для поставки ПО.Также данный раздел также определяет состав документов, поставляемых с версией ПО и доступных для конечных пользователей | Примерный состав документов: · архив релизов с описанием (Release Media); · описание релиза (Release Notes); · описание функций; · перечень решенных проблем в релизе; · перечень новых возможностей; · инструкция по установке ПО; · инвентаризация, опись. Данный пункт может содержать основные правила формирования документов, отражать способ выпуска документов (ручной, автоматический). Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК. Перечень приведенных документов относится к выпуску ПС для каждой версии, релиза, патча. В зависимости от выбранной модели выпуска состав документов, а также их детальность могут различаться |
| 3.3.3.2 Документирование процесса | Общие документы требуются в случаях, когда продукт разрабатывается для крупных организаций, а также в тех случаях, когда продукт представляет собой программно-аппаратный комплекс | Типовые документы для данного раздела: · описание системы, в которой используется ПС; · описание административного управления программными средствами системы; · руководство системного администратора; · руководство пользователя; · паспорт на ПС (общие сведения о ПС, основные характеристики, комплектность, акты о приемке и снятии с эксплуатации... и т. д.). Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК |
| 4. Этапы | Детально рассматриваются этапы работ для заказчика и внутренние, относящиеся к работам по УК для программного продукта или проекта. Эта секция обычно включает детальное описание того, когда может быть модифицирован сам план конфигурационного управления | В зависимости от выбранной модели может измениться содержание этапов. Рекомендуется описать, что выполняется в УК в зависимости от этапа проекта |
| 5. Обучение и ресурсы | Рассматриваются инструментальные средства, персонал и обучение, требуемые для реализации описанных в плане задач | |
| 6. Субподрядчики и контроль программного обеспечения со стороны поставщиков | Описывается, как будет интегрировано программное обеспечение, разработанное вне среды УК проекта | К работе над проектом могут привлекаться субподрядчики. Данный раздел описывает, каким образом будет происходить работа с субподрядчиком. Вопросы: · Разработка ведется только в одно организации или в обеих? · Каковы процедуры корректировки дефектов в разрабатываемом продукте? · Автоматизированы ли они (полностью или частично)? · Какие изменения допустимо вносить заказчику в исходные тексты после получения продукта? · Ставится ли в известность об этом субподрядчик и в какой мере? · Когда и как выполняются ревизии? · Какой набор инструментальных средств используется заказчиком и субподрядчиком? · Необходимы ли дополнительные модули синхронизации (для тех случаев, когда заказчик и подрядчик используют разные системы УК от разных производителей)? · Как контролируется субподрядная организация? · Кто отвечает за работу с субподрядчиком? · Работает ли субподрядчик по своим процессам или заказчик обязывает его работать по собственным? · Как решаются конфликты? · Разрешено ли субподрядчику осуществлять полную сборку продукта у себя, или заказчик выделяет стенд для сборки на своей территории? · Допускается ли субподрядчик к справочной информации заказчика (доступ к реальным базам данных, справочникам)? |
| Приложения | Состав приложений не определяется стандартами. Обычно включает в себя такие документы, как: · регламенты; · инструкции по использованию средств УК (как пользовательские, так и административные); · различные методические пособия; · планы обучения; · инструкции по установке и администрированию средств УКит.д. | Руководствуйтесь целесообразностью внесения тех или иных изменений. Оцените, все ли попало в основные разделы плана. Если основные разделы слишком разрослись, то, возможно, нужно вынести из них часть информации в приложение |
При планировании разработки АС необходимо выполнить работы в следующей последовательности:
составить перечень работ по разработке АС;
определить состав и количество исполнителей каждой работы;
установить последовательность и взаимосвязи работ;
определить трудоемкость и продолжительность каждой работы;
составить план-график выполнения работ.
Исходные данные для составления перечня работ по созданию АС и определения состава и количества исполнителей дипломник должен получать, как правило, во время преддипломной практики, либо в период проектирования в организации, где выполняется данный проект. При этом необходимо охватить весь перечень видов работ по созданию АС, не ограничивая его только работами, выполняемыми дипломником лично. При этом нужно исходить из того, что дипломник выступает в качестве основного разработчика системы, занятого выполнением работ на протяжении всего периода разработки. Для выполнения отдельных видов работ могут привлекаться другие исполнители. По каждому виду работ определяется квалификационный уровень исполнителей (должности), количество исполнителей. Трудоемкость выполнения каждой работы оценивается экспертным путем в человеко-днях, и носит вероятностный характер, так как зависит от множества трудно учитываемых факторов, поэтому применяются оценки минимально возможной трудоемкости выполнения отдельных видов работ - a j , максимально-возможной - b j и наиболее вероятной - m j . По этим величинам оценивается ожидаемое значение трудоемкостей , по следующей формуле:
;
Продолжительность каждой работы D j определяется по формуле, дн.:
где n j - численность исполнителей, чел.
Экспертные оценки и расчетные величины трудоемкости и продолжительности сводятся в табл. 2.
Таблица 2 - Оценка трудоемкости отдельных видов работ.
Наименования работ по проектированию автоматизированной системы, входящих в нее задач, взаимосвязи работ, исполнители, трудоемкость и длительность заносятся в сводную таблицу для планирования работ, пример которой приведен в табл. 3.
Таблица 3 - Сводная таблица для планирования работ
|
Исполнители | ||||||
|
Наименование работы |
работы нужно вы-полнить перед данной |
должность |
кость работы, чел.-дн. |
житель-ность работы, дн. |
||
|
Разработка технического задания на разработку АС |
начальник | |||||
|
старший инженер | ||||||
|
Разработка алгоритма модуля 1… |
программ. | |||||
|
Кодирование модуля 1 | ||||||
|
Отладка модуля 1 | ||||||
|
Тестирование модуля 1 | ||||||
|
Разработка алгоритма модуля 2… | ||||||
|
Кодирование модуля 2 | ||||||
|
Отладка модуля 2 | ||||||
|
Тестирование модуля 2 | ||||||
|
Разработка алгоритма | ||||||
|
Кодирование модуля 3 | ||||||
|
Отладка модуля 3 | ||||||
|
Тестирование модуля 3 | ||||||
|
Отладка и тестирование интеграции системы | ||||||
|
Оформление документации | ||||||
Если перечень включает не более 10 работ, то планирование процесса создания АС осуществляется на основе ленточных графиков. При планировании более сложных автоматизированных систем составляется сетевой график и используется аппарат систем сетевого планирования.
Сетевой график составляется с учетом последовательности и взаимосвязей работ (табл. 3) по правилам составления сетевых моделей. Пример сетевого графика приведен на рисунке 1. Стрелкой обозначены работы, события - кружочком. Каждое событие имеет номер, который проставляется после построения сети.
Рис. 1 - Сетевой график процесса разработки системы
Длительность разработки АС определяется продолжительностью критического пути сетевого графика.
К р и т и ч е с к и м п у т е м называется последовательность работ между начальным и конечным событием сети, имеющая наибольшую продолжительность.
Длительность разработки автоматизированной системы устанавливается после формирования сетевого плана.
С этой целью рассчитываются временные параметры событий и работ построенной сети.
Р а н н и й с р о к с в е р ш е н и я i - г о с о б ы т и я T рi - время, необходимое для выполнения всех работ, предшествующих данному событию.
T р i = t[ L(Ii)макс ],
где L(Ii) - пути, ведущие от исходного события I до данного события i.
t[ L(Ii)макс ] - продолжительность максимального из путей от исходного события I до данного события i.
Продолжительность критического пути t(L кр) находится по фомуле:
t(L кр) = t[ L(IС)макс ],
где L кр - критический путь;
L(IС) - пути, ведущие от исходного события I до конечного события С.
П о з д н и й с р о к с в е р ш е н и я i - г о с о б ы т и я T пi - время свершения события, превышение которого вызовет аналогичную задержку наступления завершающего события.
T п i = t(L кр) - t[ L(iC)макс ],
t[ L(iC)макс ] - продолжительность максимального из путей от данного события i до завершающего C.
Р е з е р в в р е м е н и i - г о с о б ы т и я R i определяется как разность между поздним и ранним сроком свершения события i, т.е.
R i = T пi - T рi .
В р е м е н н ы е п а р а м е т р ы р а б о т ы между i и j событием сетевой модели находятся следующим образом:
ранний срок начала T рнij = T рi ;
поздний срок окончания T поij = T пj ;
ранний срок окончания T роij = T рнij + t ij ;
поздний срок начала T пнij = T поij - t ij ;
полный резерв времени R пij = T поij - T роij ;
свободный резерв времени R сij = T рj - T роij ,
где t ij - продолжительность работы ij.
Временные параметры событий и работ представляются в форме табл. 4.
Таблица 4 - Временные параметры сетевого плана
|
Временные пара- метры событий |
Временные параметры работ |
||||||||||
План-график по разработке АС формируется на основе рассчитанных временных параметров сети и директивного срока начала разработки . Если этот директивный срок не задан, то принимается равным 0.
Примерный вид план-графика выполнения работ представлен в табл. 5.
Таблица 5 - Линейный график работ
|
Наименование |
Календарь, мес. |
||||||||
|
ность, дн. | |||||||||
|
Разработка ТЗ на АС | |||||||||
|
Выбор комплекса технических средств | |||||||||
|
Оформление документации | |||||||||
Если в дипломном проекте разрабатывается программные средства, то следует более подробно рассмотреть вопросы организации, создания и применения программных продуктов.
Управление конфигурацией является основополагающей дисциплиной в определении того, каким образом управляются и контролируются рабочие материалы проекта, вносимые в них изменения и информация о состоянии отдельных задач и всего проекта в целом. Успех проекта в большой степени зависит от того, насколько хорошо построен процесс управления конфигурацией, который может как спасти проект, так и похоронить его, если сам процесс УК работает плохо.
История развития дисциплины управления конфигурацией
Первым заметным шагом в развитии управления конфигурациями (сокращенно – УК) было изобретение микрометра в 1636 году (William Gascoigne). Это устройство сыграло важную роль в индустриальной революции и переходе к массовому производству. Этот инструмент позволил использовать взаимозаменяемые части в различных устройствах, что являлось существенной причиной для того, чтобы использовать процедуры управления конфигурацией.
Первые инженерные концепции, которые привели к становлению дисциплины управления конфигурацией, начали формироваться в начале 20-го века и обрели реальную форму в 60-х годах прошлого века.
Изначально создатели концепции управления конфигурацией преследовали цель улучшения способов разработки и сопровождения программных средств (ПС). «Отцы-основатели» управления конфигурацией хотели создать дисциплину, которая обеспечивала бы соответствие разработанного ПС потребностям пользователей, для которых это ПС разрабатывалось. Они изучили успешные проекты и обобщили опыт применения тех технологий, которые хорошо себя проявили. Другой важной целью было обеспечить простоту модификации и сопровождения ПС и (так как «отцы-основатели» в основном работали на правительственные учреждения) возможность для заказчика ПС сменить разработчика без того, чтобы заново проходить весь цикл разработки ПС с нуля.
Кроме того, в качестве дополнительной цели рассматривалось обеспечение оценки состояния проекта на основе отчетности по ключевым показателям. Они сосредоточились на достижении долгосрочных целей и не рассчитывали получить сразу очевидные преимущества от использования разрабатываемых ими технологий. Следует заметить, что преимущества такого сорта трудно выразить количественно, так как при успешном использовании управления конфигурацией в организации просто перестают растрачивать ресурсы на лишнюю работу. Например, на повторное исправление ошибки, которая уже была исправлена ранее, но появилась вновь из-за того, что при сборке ПС правильный код случайно заменили на неправильный.
«Отцы-основатели» осознали, что в первую очередь им требуется контролировать то, какие части входят в готовый продукт (под продуктом может пониматься как ПС, так и оборудование и, в широком смысле, любое изделие, состоящее из различных частей) и каким образом они взаимосвязаны, а также отслеживать изменения в отдельных частях продукта и в их взаимосвязях друг с другом. Они выбрали слово «конфигурация» для обозначения «относительного взаиморасположения частей». Слово «управление» вполне подходило по смыслу, и в итоге получилось «управление конфигурацией».
(!) Всегда не хватает времени, чтобы выполнить работу как надо, но на то, чтобы ее переделать, время находится..
Разработка плана управления конфигурацией
Что такое план УК?
Многие компании при попытке поставить любой процесс (не важно какой, но в данном случае - Управления Конфигурациями) ограничиваются только инсталляцией программных средств с минимальными затратами в дальнейшей работе. Так был загублен не один проект. Во-первых, всегда должна быть планомерная работа. А во-вторых, сначала внедряется процесс, а потом инсталлируются средства автоматизации (уж никак не наоборот). Соответственно, если есть процесс, то должен быть документ, описывающий его. Таким документом для процесса УК является «План управления конфигурациями», где излагается концепция процесса и имплементация средств автоматизации. В нем же расписываются все роли, и, что особенно важно, деятельности в зависимости от стадии жизненного цикла разработки ПО.
Данный план является основным документом, регламентирующим все дальнейшие проектные действия, связанные с конфигурационным управлением. В плане необходимо отмечать то, каким образом будет достигаться та или иная цель: ведь одну и ту же задачу можно решать различными способами, но, однажды выбрав определенное решение, не рекомендуется изменять его в процессе работы.
План должен быть документально оформлен и выполнен (план может быть частью плана управления конфигурацией системы).
План на высоком уровне определяет процесс разработки ПО. План также содержит в себе много административных моментов, которые необходимо реализовать в настройках инструментальных средств УК, чтобы они соответствовали плану.
Кто пишет план УК?
По большому счету написание плана - коллективная работа. Здесь задействованы все участники проекта, так как на основе их информации и рождается план УК.
Если говорить применительно к терминологии УК, то есть роль, которая отвечает за физическое написание плана - Менеджер УК.
Менеджер Управления Конфигурациями - ключевая роль. Этот человек знает процесс разработки. Понимает цели и задачи УК. Все свои знания он излагает в плане УК. Сам управляет процессом УК.
Очень часто пытаются либо вообще обойтись без такой роли, либо «спихивают» ее на разработчиков. Естественно, это неправильно, так как разработчик не видит всей картины процесса разработки, может не понимать структурных взаимодействий между отделами… и т.д. Перечень непониманий можно продолжать далее. На первых порах, на порах становления роль менеджера берет на себя человек, который имеет представление о процессе разработки. Такой человек всегда есть в коллективе, как правило, это лидер разработчиков или руководитель отдела разработки.
Техническое применение плана (реализация плана в средствах поддержки УК)
Как мы уже говорили выше - план содержит высокоуровневое описание процесса, но чтобы инструментальные средства поддержки УК начали следовать плану, необходимо выполнить их физическую настройку:
- Установить средства;
- Разработать экранные формы запросов на изменение;
- Установить политику доступа;
- Определить жизненный цикл запросов на изменение;
- Поставить данные под УК в соответствии с планом;
- И т.д.
Физическую настройку обычно проводит администратор, который на основании имеющегося плана проводит физические настройки инструментальных средств УК.
Когда готовят план УК?
План разрабатывается на ранних стадиях общего планирования проекта. План должен быть подготовлен на самых ранних стадиях, еще до того, как разработчики включили компьютеры - момент проработки технического задания уже нужно писать план УК. Это в идеале. На практике, как правило, процесс уже сложился и его требуется сначала описать, а потом, по потребностям модифицировать, улучшить.
Что хорошо в плане УК, так это то, что он долго пишется всего один раз. Далее для каждого проекта пишется новый план, на основе существующего, так как способы и методы в новом проекте могут отличаться, то и план описывает все особенности данного проекта. Иногда применяется практика выделения общих частей плана УК и утверждение их как составная часть стандарта на разработку в компании. После чего каждый проект использует общий план + выпускает к нему набор дополнений для конкретного проекта. Впрочем набор дополнений не может противоречить основному плану.
Поддержка плана в актуальном состоянии
План рассматривается всеми участниками процесса и рецензируется ими.
План - живой документ. План пишут живые люди, которые могут ошибиться. План - не секретный документ - он должен храниться на видном месте, его должны все читать, так как план описывает процесс разработки, то его особенно должны читать вновь пришедшие разработчики, тестировщики, менеджеры. Чтобы план был живым его необходимо читать и корректировать - избавлять от косноязычия и от неправильных формулировок. Такая ошибка, как неправильное понимание процесса, ведет к простоям и частым доработкам продукта. План должен быть доступен и управляем в части его изменений.
Каждый приходящий сотрудник в организацию должен быть ознакомлен с планом, чтобы понять процесс разработки как можно в более короткие сроки. Хороший план с приложениями в виде подробных инструкций позволит это сделать в кратчайшее время.
Очень часто при обследовании компаний, нам приходится сталкиваться с тем, что имеющийся план не соответствует тому процессу, который существует в организации. Самое любопытное заключено в том, что если специалисты на ранних этапах внедрения отслеживали актуальность плана, то со временем план УК (а вместе с ним и большинство документов по другим процессам) постепенно «задвигается» и работа по нему прекращается. И получается очень занятная ситуация: с одной стороны, если идти по формальным признакам, в организации есть процесс и есть НМО, описывающее его. С другой стороны, по факту, НМО описывает нечто, чего уже нет в организации. В итоге можно считать, что в организации нет плана УК, так как он не отражает реалии.
С подобным ходом вещей необходимо нещадно бороться. Мы все прекрасно понимаем, что нормальное состояние человека и организации это совершенствование (совершение процесса, самосовершенствование… и т.д.) имеющегося. Просто насущно необходимо совершенствовать документацию по процессу вместе с самим процессом. Их эволюционирование должно осуществляться параллельно. Только тогда можно будет говорить о зрелости процессов в организации.
План УК в стандартах
План УК является важнейшим документом процесса. По большому счету он является единственным документом процесса УК. Состав и содержимое плана УК определяется в некоторых стандартах, но в большинстве случаев существенно дорабатывается под нужды конкретной организации или проекта при внедрении процессов ЖЦ ПС. Все рассмотренные в данные книге стандарты определяют процесс, роли, но не все определяют и классифицируют планы УК. Рассмотрим подробнее требования стандартов на содержимое планов УК:
Таблица 1 - Определение структуры плана УК в стандартах
|
Стандарт |
Определяет содержимое плана? |
Комментарии |
|---|---|---|
|
ГОСТ Р ИСО/МЭК 12207 |
Оговаривается только наличие плана. |
|
|
Требований к содержимому плана и его структуре нет, но по большому счету вся модель один в один представляет собой «скелет» плана УК. |
||
|
Частично |
«Приложение "А"» (нормативное) определяет рекомендуемую структуру и содержание программы управления конфигурацией. |
|
|
IEEE Std 828-1990 и Std 1042-1987 |
Совместно определяют как процесс, так и структуру плана УК. Даются примеры нескольких планов УК для проектов разного типа. |
|
|
Microsoft Solution Frameworks |
||
|
Rational Unified Process |
Естественно, RUP не совсем стандарт в полном смысле этого слова, но по сути стандарт «де факто». Требования к плану, шаблоны планов и примеры планов отражены в нем в полной мере и представляют агрегированный опыт по отраслям экономики. |
Стандартизация и классификация
На сам план при его разработке влияют множество факторов. Структура плана УК, и его содержание, зависит от таких факторов, как тип проекта и его длительность, уровень формализации процессов, размер команды (наличие регионально распределенных групп), количество субподрядчиков, и многих других. Это означает, что структура плана, состав приложений могут в достаточно больших пределах варьироваться, сохраняя при этом единый «дух».
Рассмотрим факторы, влияющие на структуру плана УК:
- Тип проекта;
- Относительный размер проекта;
- Количество конфигурационных элементов;
- Число компонентов и подсистем;
- Наличие нескольких офисов (регионально распределенная разработка);
- Фаза жизненного цикла;
- Модель разработки;
- Доступность (наличие) средств УК и иных смежных средств;
- Уровень формализации (как процессов организации, так и тип контроля плана).
Проведем детализацию, выделив возможные значения по факторам, так как показано в таблице ниже.
Таблица 2 - факторы, влияющие на структуру плана УК и его детализацию
|
Фактор |
Возможные значения |
Воздействие, описание |
|---|---|---|
|
Тип проекта |
Разработка модели (прототипа) Проект сопровождения ПС Коммерческий (с сопровождением) Коммерческий без сопровождения Субподрядный |
|
|
Наличие нескольких офисов (регионально распределенная разработка) |
Один офис Более одного |
Наличие нескольких офисов усложняет план, дополняя его регламентами взаимодействия между офисами. Также дополнительные офисы влияют на общую архитектуру проекта. На такие ключевые факторы как количество ответвлений на проектном дереве (как правило, добавление нового региона, приводит к добавлению минимум одной ветви для каждого региона). Увеличение числа регионов воздействует на уровень формализма плана. Уровень - высокий. |
|
Относительный размер проекта |
Воздействует на количество регламентов и их проработанность и детальность. Фазы, взаимодействие между группами, прохождение запросов на изменения описываются более детально. Чем больше проект, тем более формализованным должен быть план. |
|
|
Количество конфигурационных элементов |
Число конфигурационных элементов влияет только на более глубокую проработку идентификации элементов. В некоторых случаях полезно определить в плане все типы конфигурационных элементов на основании шаблонов (например, по расширениям файлов) |
|
|
Количество компонентов и подсистем |
Число компонентов и подсистем могут влиять на выборку элементов из репозитория (способ выборки и обращения). Также влияет на глубину изложения раздела, описывающего структуру проектного каталога |
|
|
Фаза жизненного цикла |
План УК обычно описывает все фазы жизненного цикла ПС. Иногда при работе с субподрядчиками бывает необходимо более четко выделить фазу, на которой подключается субподрядная организация. Также к плану УК может выпускаться дополнение, отражающее фазу жизненного цикла ПС. |
|
|
Модель разработки |
В зависимости от того какая модель разработки принята за основу (каскад, итерации, спираль), необходимо откорректировать план УК в части состава фаз ЖЦ ПС, глубины их описания, способа идентификации базовых версий, выпуска релизов. |
|
|
Доступность (наличие) средств УК и иных смежных средств |
Базовые Основные системы УК (как правило, только отслеживание версий) Генераторы отчетов (обычно встроенные) Средства управления библиотеками |
Проект может строиться вообще без средств автоматизации (например, управление конфигурацией сборки макета печатной платы). На ход проекта и на план оказывают существенное воздействие такие факторы как используемые средства разработки, платформа разработки (возможно разработка на нескольких платформах и для нескольких платформ одновременно). Также большое значение имеют тип и количество средств реализации (автоматизации УК), их принадлежность одному или нескольким вендорам. Например, в проекте можно использовать средство управления версиями от одного производителя, а средство управления изменениями от другого. Можно иметь интеграцию средства управления со средствами управления проектами а можно и не иметь. Тип интеграции между средствами, архитектура интеграции должны быть детально рассмотрены в плане. |
|
Продвинутые, интегрированные Тоже что и выше. Плюс средства управления изменениями Встроенные средства сборки и аудита |
||
|
Разрозненные |
||
|
Уровень формализации (как процессов организации, так и тип контроля плана) |
Уровень формализации можно варьировать в зависимости от многих факторов, в том числе отраженных в данной таблице. Выбирая уровень формальности и глубины изложения необходимо руководствоваться исходящими задачами и целями. Такие факторы, как сложность проекта, региональная разбросанность, тип проекта, наличие субподрядчиков должны автоматически подвигнуть к написанию высоко формализованного плана УК. Средний и низкий уровень может применяться в относительно краткосрочных проектах, проектах, в которых задействовано небольшое количество разработчиков. С ростом команды, разделением ролей план УК должен быть пересмотрен, уровень формализации поднят. |
Структура типового плана УК с комментариями к разделам
Существует бесконечное множество вариаций на тему плана УК. Ниже представлены основные разделы плана и объясняется, почему они необходимы. Отметим, что данная структура - усредненная и представляет собой выборку из планов УК, составленных нами в реальных проектах.
Таблица 4 - Структура плана УК
|
Раздел плана |
Раздел плана |
Требования к содержанию |
Дополнительные комментарии |
|---|---|---|---|
|
1. Введение |
Введение в план УК представляет собой обзор содержания документа. Включает цели, область действия, определения, акронимы, сокращения, ссылки и обзор плана конфигурационного управления |
Введение позволяет сделать документ более читаемым - объяснить основные моменты и расставить правильные акценты. |
|
|
1.1 Назначение |
Содержит назначение документа «План конфигурационного управления» |
Как правило, в назначение можно включить описание целей, которые решает данный план. Ведь план, в зависимости от размеров проекта, от географической распределенности также может различаться. |
|
|
1.2 Область применения |
Краткое описание области применения плана; с какой моделью он связан, другие особенности, влияющие на документ. |
Зачастую, можно описать подразделения, участвующие в процессе УК. Описать условия применения. При определении области полезно ответить для себя на ряд вопросов:
|
|
|
Definitions, Acronyms, and Abbreviations |
Представляет собой определения всех терминов, акронимов и сокращений, требующихся для точной интерпретации документа «План конфигурационного управления». Для предоставления этой информации можно воспользоваться ссылками на словарь проекта |
Нам часто приходится сталкиваться с тем, что данный раздел либо игнорируют совсем, либо не придают ему особого значения. Те не менее глоссарий - это составная и неотъемлемая часть ЛЮБОГО документа, плана УК в том числе. Здесь необходимо отразить и объяснить все термины УК и разрабатываемого продукта. Необходимо помнить, что хороший глоссарий позволит всем находиться в одном терминологическом пространстве. Вопросы:
|
|
|
Этот подраздел представляет полный список всех документов, на которые имеется ссылка где-либо в «Плане конфигурационного управления». Идентифицируется каждый документ по названию, номеру отчета (если есть), дате и организации, его опубликовавшей. Указывается источник, из которого могут быть получены указанные документы. Для предоставления этой информации можно воспользоваться ссылками на приложения или другие документы. |
План УК редко разрабатывается сам по себе. Он является частью нормативно-методического обеспечения проекта. Нет смысла в плане повторять дословно разделы из других документов. Проще сформировать ссылку на документ, а в данном разделе указать все используемые источники (в том числе, документы RUP, стандарты, международные и отраслевые стандарты). Вопросы:
|
||
|
Обзор документа по разделам |
Необходимо понимать, что не все участники проекта будут читать документ «от корки до корки». Обзор необходим для того, чтобы впоследствии можно было читать те разделы, которые нужны в данный момент данной роли. |
||
|
Software Configuration Management |
Один из основных разделов. Описывает все технические и технологические аспекты применения УК в проекте или организации. Количество подразделов и их вложенность могут отличаться от приведенных ниже |
||
|
Organization, Responsibilities, and Interfaces |
Указывается, кто будет ответственным за выполнение различных задач конфигурационного управления, описанных в ходе процессов конфигурационного управления |
Данный пункт оговаривает не только список ответственных за выполняемые действия, но может описывать состав и взаимодействие между проектными группами. Данный аспект особенно важен, если речь идет о распределенной разработке в нескольких географических точках. Эффективное дополнение данного раздела - подраздел, описывающий политику доступа. Это может быть простая таблица, в которой описывается в терминах применяемых средств автоматизации процесса что можно выполнять отдельному участнику проекту. А что для него запрещено. Обычно для этого выбирают способ описания либо только доступных операций либо только запрещенных. В дальнейшем данная политика перекладывается в средства реализации, где выставляются соответствующие разрешения и запрещения. В зависимости от выбранной проектной структуры (матричной или иерархической) адаптируется политика. Вопросы:
|
|
|
Tools, Environment, and Infrastructure |
Рассматривается рабочая среда и программное обеспечение, которое будет использовано при выполнении функций конфигурационного управления в ходе жизненного цикла проекта или программного продукта. Вопросы, рассматриваемые при настройке рабочей среды конфигурационного управления: ожидаемый размер данных по программному продукту; распределение рабочей команды; расположение серверов и рабочих станций. |
Детальное описание данного пункта позволит, во-первых, понять самим какие средства разработки используются в компании (зачастую до начала внедрения в большой компании никто кроме начальника отдела разработки не представляет полного списка средств). Полный учет средств необходим еще и для того, чтобы определить методы интеграции средств разработки со средствами УК, ведь известно, что любое средство УК имеет ограниченные возможности по интеграции со средствами разработки. Задача менеджера УК и администратора в этом случае заключается в том, чтобы выбрать сторонние разработки, которые делают интеграцию либо более полной, либо просто добавляют саму интеграцию в используемое средство разработки + в средство УК. Не менее важно описать среду исполнения. Не все средства УК одинаково ставятся на всех платформах. Здесь могут быть особенности. Как вариант: сервер Linux, клиенты Windows. Не все средства УК умеют работать в подобной среде, что надо учитывать при выборе средства. Вопросы:
|
|
|
The Configuration Management Program |
|||
|
Configuration Identification |
Вопросы:
|
||
|
3.1.1 Методы идентификации |
Identification Methods |
Описывается, как именуются, маркируются и нумеруются артефакты проекта или программного продукта. Схема идентификации должна покрывать оборудование, системное программное обеспечение, продукты внешних разработчиков и все артефакты разрабатываемого приложения, указанные в структуре директорий программного продукта; например, модели, планы, компоненты, тестовое ПО, результаты и данные, исполняемые файлы и т.д |
Очень важный пункт, в котором нужно описать все правила именования объектов УК. Также здесь должно быть детально расписана структура каталогов проекта. Обычно к моменту внедрения УК структура каталогов проекта складывается исторически, зачастую - спонтанно. Цель описания - выработать новую более эффективную структуру. Практика показывает, что человек на этапе восстановления структуры может увидеть уязвимые или неэффективные места. |
|
3.1.2 Базовые версии проекта |
Project Baselines |
Базовые версии предоставляют официальный стандарт, на котором основывается последующая работа и для которого проводятся только авторизованные изменения. |
Здесь описывается то, каким образом будет происходить сама работа в средстве УК. Как будут ставиться метки, как выпускаться релизы. Сколько ветвей для реализации проекта будет использовано, и по какому принципу ветви будут именоваться. Обратите особое внимание на данный пункт - без него невозможна эффективная работа. При проработке пункта учитывается региональная раздробленность команды (влияет состав команд, количество регионов), интенсивность внесения изменений, количество выпускаемых релизов за единицу времени. Соответственно, в зависимости от данных показателей выбирается наиболее эффективный способ управления конфигурациями, что и отражается в данном разделе.
|
|
Configuration and Change Control |
Как известно процесс УК состоит из двух частей - управление изменениями и управления версиями. Управление изменениями - неотъемлемая и важная часть процесса. Управлять необходимо любыми изменениями: от заявок пользователей до исправляемых дефектов. Данный раздел содержит полно описание всех запросов на изменения, включая атрибуты и жизненный цикл. Подробное описание - залог успешно построенного процесса УК. Очень часто для отслеживания существенных событий в проекте, применяют уведомления различного вида. Как правило, это уведомления по электронной почте (например при исправлении ошибки тестер получает уведомление и может приступить к тестированию). Укажите все типы уведомлений, которые применяются в проекте. Вопросы:
|
||
|
Change Request Processing and Approval |
Рассматриваются процессы, которые обеспечивают внесение, рассмотрение и упорядочение проблем и изменений. |
Определяются типы запросов. Как правило это: Дефект, Запрос на расширение, Задача и Заявка. Состав типов может существенно меняться, главное не сводить все управление изменениями к одному типу запросов (очень часто кроме как Дефектами компании ничем не управляют) |
|
|
Change Control Board (CCB) |
Описывается, кто входит в состав группы управления изменениями и процедуры, которым она следует, для отработки и утверждения запросов на изменение. В некоторых случаях указывается регламент сбора группы. |
Решение о принятии запроса от пользователя, решение о реализации новой технической идеи практически никогда не решаются одним человеком. В любой компании это группа людей. В терминах стандартов данная группа называется CCB. В данном разделе необходимо описать состав участников (как правило, это аналитик или постановщик, лидер группы разработчиков, лидер группы тестировщик и представитель отдела маркетинга) и периодичность заседаний. Например группа CCB может собираться каждую неделю (по регламенту) либо по возникшей потребности (не рекомендуется). Вопросы:
|
|
|
Configuration Status Accounting |
|||
|
Project Media Storage and Release Process |
Описываются правила хранения и регламенты резервирования, действия на случай непредвиденных обстоятельств. Описание процесса выпуска релизов включает их содержание, для кого они предназначены и имеются ли какие-либо известные проблемы и инструкции по инсталляции (можно вынести в отдельное приложение) |
||
|
3.3.2 Отчеты и проверки |
Reports and Audits |
Рассматривается содержание, формат и цель запрашиваемых отчетов и проверок состояния конфигурации. Отчеты используются для получения данных о «качестве программного продукта» в любой заданный момент времени жизненного цикла программного продукта или проекта. Отчетность по дефектам, основанная на запросах на изменения, может обеспечить некоторые удобные индикаторы качества и, следовательно, предостеречь менеджеров и разработчиков об определенных критических областях процесса разработки. |
Отчетам следует уделить особое внимание. Только по отчетам можно проследить ход выполнения работ. Здесь необходимо определить отчеты по ролям участников проекта и описать их формат. Также рекомендуется сформировать регламент сбора отчета, то есть с какой периодичностью собираются метрики (в реальном времени, раз в день… итд). Желательно выделить различные типы отчетов и периодичность сбора их метрик. Вопросы:
Отчеты:
|
|
3.3.3 Документирование |
Раздел определяет способы и типы документов |
||
|
3.3.3.1 Описание версии |
Version Description |
Данный документ описывает диски, CD или другие носители, используемые для поставки ПО. Также данный раздел также определяет состав документов поставляемых с версией ПО и доступных для конечных пользователей. |
Примерный состав документов:
Данный пункт может содержать основные правила формирования документов, отражать способ выпуска документов (ручной, автоматический). Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК. Перечень приведенных документов относится к выпуску ПС для каждой версии, релиза, патча. В зависимости от выбранной модели выпуска состав документов. А также их детальность могут различаться. |
|
Общие документы, требуются в случаях, когда продукт разрабатывается для крупных организаций, а также в тех случаях, когда продукт представляет собой программно-аппаратный комплекс. |
Типовые документы для данного раздела:
Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК. |
||
|
Детально рассматриваются этапы работ для заказчика и внутренние, относящиеся к работам по УК для программного продукта или проекта. Эта секция обычно включает детальное описание того, когда может быть модифицирован сам план конфигурационного управления |
В зависимости от выбранной модели может измениться содержание этапов. Рекомендуется описать, что выполняется в УК в зависимости от этапа проекта. |
||
|
5. Обучение и ресурсы |
Training and Resources |
Рассматриваются инструментальные средства, персонал и обучение, требуемые для реализации описанных в плане задач |
|
|
Subcontractor and Vendor Software Control |
Описывается, как будет интегрировано программное обеспечение, разработанное вне среды УК проекта |
К работе над проектом могут привлекаться субподрядчики. Данный раздел описывает каким образом будет происходить работа с субподрядчиком. Вопросы:
|
|
|
Приложения |
Состав приложений не определяется стандартами. Обычно включает в себя такие документы как:
|
Руководствуйтесь целесообразностью внесения тех или иных изменений. Оцените, все ли попало в основные разделы плана. Если основные раздел слишком «разрослись», то, возможно нужно вынести из них часть информации в приложение. |
Полнота плана УК в зависимости от объема проекта и его типа
Японская мудрость гласит: «Чем завтра сто, лучше сегодня пятьдесят». Применительно к плану УК ее можно перефразировать как: «Лучше полплана сегодня, чем полный завтра».
Просмотрев структуру и содержание плана, у читателя может сложиться ощущение, что написание плана это отдельная непосильная наука, и вообще, план нужен только в очень больших проектах. К сожалению такое мнение бытует во многих софтверных компаниях (в отраслевых компаниях ситуация несколько лучше). Как правило, в подобных организациях присутствует некий недокументированный процесс разработки, либо есть фрагменты документов по процессу, но в силу низкой культуры коллективной работы отсутствует планирование как класс.
План УК должен быть разработан. Вопрос в том насколько он должен быть детальным и формальным. Нам очень часто приходится слышать от клиентов фразы, смысл которых в том, что нам для нашего маленького проекта планирование нужно. Это мнение неправильно в корне. Планирование должно быть всегда, вопрос только в глубине изложения.
Мы попытались облегчить задачу выбора степени детальности изложения, привязав пункты плана УК к относительному размеру проекта.
Применяется следующая градация:
- Малый - в этом проекте участвуют 2-7 разработчиков, тестировщиков почти нет, либо разработчики сами выполняют тестирование. Также в данную категорию могут попасть проекты, в которых нет параллельной разработки - то есть у каждого разработчика есть свой круг решаемых задач. Роли определены не четко. Команда находится в одной комнате;
- Средний - это проект, в котором участвуют более 6 разработчиков. Ведется разработка коробочных продуктов на продажу. В команде есть выделенные роли: разработчики, тестировщики, аналитики, системные аналитики. Разделение достаточно четкое, но есть совмещение ролей. Все участники находятся в одном офисе, но в разных рабочих комнатах.
- Крупный - тоже, что и средний, но возможно, работа над проектом ведется с несколькими субподрядчиками. Сама компания разбросана по нескольким регионам. В компании много параллельно идущих проектов.
Применена следующая градация:
- Обязательность пункта - нужен ли данный пункт плана в проекте данного типа, можно ли отказаться от пункта без ущерба целостности логической стройности плана УК.
- Детальность изложения - насколько глубоко необходимо проработать раздел. Какова его детальность? Нужно ли вносить дополнительные подпункты, раскрывающие значения основных пунктов?
- Формальность изложения - этот пункт больше относится к стилю и коррелируется с детальностью и обязательностью. Для желательного раздела в маленьком проекте допускается нестрогий стиль изложения.
Таблица 3 - обязательность, формальность и глубина изложения пунктов плана УК.
|
Раздел плана |
Тип проекта |
||||||||
|---|---|---|---|---|---|---|---|---|---|
|
1. Введение |
|||||||||
|
1.1 Назначение |
|||||||||
|
1.2 Область применения |
|||||||||
|
1.3 Определения, акронимы и сокращения |
|||||||||
|
2. Конфигурационное управление программным продуктом |
|||||||||
|
2.1 Организация, распределение ответственностей и взаимодействия |
|||||||||
|
2.2 Инструментарий, рабочая среда и инфраструктура |
|||||||||
|
3. Программа конфигурационного управления |
|||||||||
|
3.1 Конфигурационная идентификация |
|||||||||
|
3.1.1 Методы идентификации |
|||||||||
|
3.1.2 Базовые версии проекта |
|||||||||
|
3.2 Контроль конфигураций и изменений |
|||||||||
|
3.2.1 Отработка и утверждение запросов на изменение |
|||||||||
|
3.2.2 Группа управления изменениями |
|||||||||
|
3.3 Учет состояния конфигурации |
|||||||||
|
3.3.1 Хранение материалов проекта и выпуск релизов |
|||||||||
|
3.3.2 Отчеты и проверки |
|||||||||
|
3.3.3 Документирование |
|||||||||
|
3.3.3.1 Описание версии |
|||||||||
|
3.3.3.2 Документирование процесса |
|||||||||
|
5. Обучение и ресурсы |
|||||||||
|
6. Субподрядчики и контроль программного обеспечения со стороны поставщиков |
|||||||||
|
Приложения |
|||||||||
Сокращения к таблице:
О - обязательно; Ж - желательно, П - можно пропустить.
ВД - высокая детальность, СД - средняя детальность, НД - низкая детальность.
Ф - формально, НФ - неформально.
В должностные обязанности менеджера по управлению конфигурацией обязательно входит :
- разработка планов и процедур процесса управления конфигурацией;
- обеспечение реализации планов и документирование результатов;
- определение базовых положений проекта и содержание релизов;
- организация и контроль выполнения процедур процесса управления конфигурацией;
- контроль инструментальных средств хранения информации о процессе управления конфигурацией.
Различные элементы конфигурации передаются под управление конфигурацией в различные моменты времени и включаются в базовые линии в определенных точках жизненного цикла . Инициирующим событием является завершение определенных форм формального утверждения задач, таких как формальная оценка. Примерами элементов конфигурации могут служить настроенные модули ИС, руководство пользователя, планы тестирования, базы данных тестов и прочее.
Организация управления конфигурацией проекта
Для организации выполнения вышеперечисленных задач на стадии планирования ЖЦ ИС разрабатывается план управления конфигурацией, где излагается концепция и определяются средства для автоматизации процесса, а также расписываются все роли и деятельности в зависимости от стадии жизненного проекта воздействует на количество регламентов и их проработанность и детальность. Фазы, взаимодействие между группами, прохождение запросов на изменения описываются более детально. Чем крупнее проект, тем более формализованным должен быть план.
Количество конфигурационных элементов влияет только на более глубокую проработку идентификации элементов. В некоторых случаях полезно определить в плане все типы конфигурационных элементов на основании шаблонов.
Количество компонентов и подсистем влияют на выборку элементов из репозитория (способ выборки и обращения) и глубину изложения раздела, описывающего структуру проектного каталога План УК обычно описывает все фазы жизненного цикла ИС. Иногда при работе с субподрядчиками бывает необходимо более четко выделить фазу, на которой подключается субподрядная организация.
На ход проекта и на план оказывают существенное воздействие такие факторы, как используемые средства разработки , платформа разработки (возможна разработка на нескольких платформах и для нескольких платформ одновременно). Большое значение имеют тип и количество средств реализации (автоматизации УК), их принадлежность одному или нескольким вендорам. Например, в проекте можно использовать средство управления версиями от одного производителя, а средство управления изменениями - от другого. Тип интеграции между средствами, архитектура интеграции должны быть детально рассмотрены в плане УК.
Уровень формализации зависит от многих факторов. Выбирая уровень формальности и глубины изложения, необходимо руководствоваться исходящими задачами и целями. Такие факторы, как сложность проекта, региональная разбросанность, тип проекта, наличие субподрядчиков, должны автоматически подвигнуть к написанию высоко формализованного плана УК. Средний и низкий уровень могут применяться в относительно краткосрочных проектах, проектах, в которых задействовано небольшое количество разработчиков. С ростом команды, разделением ролей план УК должен быть пересмотрен, уровень формализации поднят. В таблице 42 представлен пример структуры плана УК.
В зависимости от размера проекта некоторые пункты плана могут быть пропущены.
На стадии планирования управления конфигурацией необходимо также определить, какие программное обеспечение и аппаратные средства обеспечат достижение целей проекта, разработать планы по контролю и созданию документов проекта, а также определить стратегии, стандарты и процедуры проекта, обеспечивающие управление конфигурацией , документировать, каким образом будут идентифицироваться, организовываться и контролироваться элементы конфигурации.