Пенсионный портал России
Виды конфигураций при управлении проектом. Управление конфигурацией. Введение в управление конфигурацией программных средств

Виды конфигураций при управлении проектом. Управление конфигурацией. Введение в управление конфигурацией программных средств

24.06.2019 Пенсионный фонд РФ

Зачем нам нужен план управления конфигурациями? Основные понятия и концепции документа

Всегда не хватает времени, чтобы выполнить работу как надо, но на то, чтобы ее переделать, время находится…

Что такое план УК?

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

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

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

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

Кто пишет план УК?

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

Если говорить применительно к терминологии УК, то есть роль, которая отвечает за физическое написание плана – Менеджер УК.

Менеджер Управления Конфигурациями - ключевая роль. Этот человек знает процесс разработки. Понимает цели и задачи УК. Все свои знания он излагает в плане УК. Сам управляет процессом УК.

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

Техническое применение плана (реализация плана в средствах поддержки УК)

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

  • Установить средства;
  • Разработать экранные формы запросов на изменение;
  • Установить политику доступа;
  • Определить жизненный цикл запросов на изменение;
  • Поставить данные под УК в соответствии с планом;
  • И т.д.

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

Когда готовят план УК?

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

Что хорошо в плане УК, так это то, что он долго пишется всего один раз. Далее для каждого проекта пишется новый план, на основе существующего, так как способы и методы в новом проекте могут отличаться, то и план описывает все особенности данного проекта. Иногда применяется практика выделения общих частей плана УК и утверждение их как составная часть стандарта на разработку в компании. После чего каждый проект использует общий план + выпускает к нему набор дополнений для конкретного проекта. Впрочем набор дополнений не может противоречить основному плану.

Поддержка плана в актуальном состоянии

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

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

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

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

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

План УК в стандартах

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

Таблица 1 – Определение структуры плана УК в стандартах
Стандарт Определяет содержимое плана? Комментарии
ГОСТ Р ИСО/МЭК 12207 НЕТ Оговаривается только наличие плана.
CMM/CMMI НЕТ Требований к содержимому плана и его структуре нет, но по большому счету вся модель один в один представляет собой «скелет» плана УК.
ISO 10007-95 Частично «Приложение “А”» (нормативное) определяет рекомендуемую структуру и содержание программы управления конфигурацией.
IEEE Std 828-1990 и Std 1042-1987 ДА Совместно определяют как процесс, так и структуру плана УК. Даются примеры нескольких планов УК для проектов разного типа.
Microsoft Solution Frameworks ДА
Rational Unified Process ДА Естественно, RUP не совсем стандарт в полном смысле этого слова, но по сути стандарт «де факто». Требования к плану, шаблоны планов и примеры планов отражены в нем в полной мере и представляют агрегированный опыт по отраслям экономики.

Стандартизация и классификация

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

Рассмотрим факторы, влияющие на структуру плана УК:

  • Тип проекта;
  • Относительный размер проекта;
  • Количество конфигурационных элементов;
  • Число компонентов и подсистем;
  • Наличие нескольких офисов (регионально распределенная разработка);
  • Фаза жизненного цикла;
  • Модель разработки;
  • Доступность (наличие) средств УК и иных смежных средств;
  • Уровень формализации (как процессов организации, так и тип контроля плана).

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

Таблица 2 - факторы, влияющие на структуру плана УК и его детализацию
Фактор Возможные значения Воздействие, описание
Тип проекта Разработка модели (прототипа)
Проект сопровождения ПС
Коммерческий (с сопровождением)
Коммерческий без сопровождения
Субподрядный
Наличие нескольких офисов (регионально распределенная разработка) Один офис
Более одного 		Наличие нескольких офисов усложняет план, дополняя его регламентами взаимодействия между офисами.
Также дополнительные офисы влияют на общую архитектуру проекта. На такие ключевые факторы как количество ответвлений на проектном дереве (как правило, добавление нового региона, приводит к добавлению минимум одной ветви для каждого региона). Увеличение числа регионов воздействует на уровень формализма плана. Уровень – высокий.
Относительный размер проекта Малый
Средний
Большой 		Воздействует на количество регламентов и их проработанность и детальность. Фазы, взаимодействие между группами, прохождение запросов на изменения описываются более детально. Чем больше проект, тем более формализованным должен быть план.
Количество конфигурационных элементов Число конфигурационных элементов влияет только на более глубокую проработку идентификации элементов. В некоторых случаях полезно определить в плане все типы конфигурационных элементов на основании шаблонов (например, по расширениям файлов)
Количество компонентов и подсистем Число компонентов и подсистем могут влиять на выборку элементов из репозитория (способ выборки и обращения). Также влияет на глубину изложения раздела, описывающего структуру проектного каталога
Фаза жизненного цикла План УК обычно описывает все фазы жизненного цикла ПС. Иногда при работе с субподрядчиками бывает необходимо более четко выделить фазу, на которой подключается субподрядная организация. Также к плану УК может выпускаться дополнение, отражающее фазу жизненного цикла ПС.
Модель разработки В зависимости от того какая модель разработки принята за основу (каскад, итерации, спираль), необходимо откорректировать план УК в части состава фаз ЖЦ ПС, глубины их описания, способа идентификации базовых версий, выпуска релизов.
Доступность (наличие) средств УК и иных смежных средств Базовые
Основные системы УК (как правило, только отслеживание версий)
Генераторы отчетов (обычно встроенные)
Средства управления библиотеками 		Проект может строиться вообще без средств автоматизации (например, управление конфигурацией сборки макета печатной платы).
На ход проекта и на план оказывают существенное воздействие такие факторы как используемые средства разработки, платформа разработки (возможно разработка на нескольких платформах и для нескольких платформ одновременно).
Также большое значение имеют тип и количество средств реализации (автоматизации УК), их принадлежность одному или нескольким вендорам.
Например, в проекте можно использовать средство управления версиями от одного производителя, а средство управления изменениями от другого. Можно иметь интеграцию средства управления со средствами управления проектами а можно и не иметь.
Тип интеграции между средствами, архитектура интеграции должны быть детально рассмотрены в плане.
Продвинутые, интегрированные
Тоже что и выше. Плюс средства управления изменениями
Встроенные средства сборки и аудита
Разрозненные
Уровень формализации (как процессов организации, так и тип контроля плана) Высокий
Средний
Низкий 		Уровень формализации можно варьировать в зависимости от многих факторов, в том числе отраженных в данной таблице.
Выбирая уровень формальности и глубины изложения необходимо руководствоваться исходящими задачами и целями. Такие факторы, как сложность проекта, региональная разбросанность, тип проекта, наличие субподрядчиков должны автоматически подвигнуть к написанию высоко формализованного плана УК.
Средний и низкий уровень может применяться в относительно краткосрочных проектах, проектах, в которых задействовано небольшое количество разработчиков. С ростом команды, разделением ролей план УК должен быть пересмотрен, уровень формализации поднят.

Структура типового плана УК с комментариями к разделам

Существует бесконечное множество вариаций на тему плана УК. Ниже представлены основные разделы плана и объясняется, почему они необходимы. Отметим, что данная структура – усредненная и представляет собой выборку из планов УК, составленных нами в реальных проектах.

Таблица 4 – Структура плана УК
Раздел плана Раздел плана Требования к содержанию Дополнительные комментарии
1. Введение Introduction Введение в план УК представляет собой обзор содержания документа. Включает цели, область действия, определения, акронимы, сокращения, ссылки и обзор плана конфигурационного управления Введение позволяет сделать документ более читаемым – объяснить основные моменты и расставить правильные акценты.
1.1 Назначение Purpose Содержит назначение документа «План конфигурационного управления» Как правило, в назначение можно включить описание целей, которые решает данный план. Ведь план, в зависимости от размеров проекта, от географической распределенности также может различаться.
1.2 Область применения Scope Краткое описание области применения плана; с какой моделью он связан, другие особенности, влияющие на документ. Зачастую, можно описать подразделения, участвующие в процессе УК. Описать условия применения. При определении области полезно ответить для себя на ряд вопросов:
  • Какова характеристика подконтрольных конфигурационных элементов?
  • Чем должны управлять интерфейсы высокого уровня?
  • Каковы временные рамки проекта?
  • Каковы доступные ресурсы?
  • Каковы подконтрольные сущности?
Definitions, Acronyms, and Abbreviations Представляет собой определения всех терминов, акронимов и сокращений, требующихся для точной интерпретации документа «План конфигурационного управления». Для предоставления этой информации можно воспользоваться ссылками на словарь проекта Нам часто приходится сталкиваться с тем, что данный раздел либо игнорируют совсем, либо не придают ему особого значения. Те не менее глоссарий – это составная и неотъемлемая часть ЛЮБОГО документа, плана УК в том числе.
Здесь необходимо отразить и объяснить все термины УК и разрабатываемого продукта. Необходимо помнить, что хороший глоссарий позволит всем находиться в одном терминологическом пространстве.
Вопросы :
  • Определения легки и понятны всем участникам проекта?
  • Есть ли список, на который можно легко сослаться?
  • Необходимо ли определять данный термин?
1.4 Ссылки References Этот подраздел представляет полный список всех документов, на которые имеется ссылка где-либо в «Плане конфигурационного управления». Идентифицируется каждый документ по названию, номеру отчета (если есть), дате и организации, его опубликовавшей. Указывается источник, из которого могут быть получены указанные документы. Для предоставления этой информации можно воспользоваться ссылками на приложения или другие документы. План УК редко разрабатывается сам по себе. Он является частью нормативно-методического обеспечения проекта. Нет смысла в плане повторять дословно разделы из других документов. Проще сформировать ссылку на документ, а в данном разделе указать все используемые источники (в том числе, документы RUP, стандарты, международные и отраслевые стандарты).
Вопросы :
  • Используются ли в плане положения, методики политики, уже используемые в организации?
  • Действительно ли ссылка необходима в плане?
1.5 Обзор Overview Обзор документа по разделам Необходимо понимать, что не все участники проекта будут читать документ «от корки до корки». Обзор необходим для того, чтобы впоследствии можно было читать те разделы, которые нужны в данный момент данной роли.
Software Configuration Management Один из основных разделов. Описывает все технические и технологические аспекты применения УК в проекте или организации.
Количество подразделов и их вложенность могут отличаться от приведенных ниже
Organization, Responsibilities, and Interfaces Указывается, кто будет ответственным за выполнение различных задач конфигурационного управления, описанных в ходе процессов конфигурационного управления Данный пункт оговаривает не только список ответственных за выполняемые действия, но может описывать состав и взаимодействие между проектными группами. Данный аспект особенно важен, если речь идет о распределенной разработке в нескольких географических точках.
Эффективное дополнение данного раздела – подраздел, описывающий политику доступа. Это может быть простая таблица, в которой описывается в терминах применяемых средств автоматизации процесса что можно выполнять отдельному участнику проекту. А что для него запрещено.
Обычно для этого выбирают способ описания либо только доступных операций либо только запрещенных.
В дальнейшем данная политика перекладывается в средства реализации, где выставляются соответствующие разрешения и запрещения.
В зависимости от выбранной проектной структуры (матричной или иерархической) адаптируется политика.
Вопросы :
  • Каковы возможности организации по штату для выполнения операций УК?
  • Какова структура управления?
  • Каков стиль управления?
  • Кто будет ответственен за выполнение операций?
  • Какие организационные изменения могут быть в течении жизни плана УК?
  • Каковы планы по поддержке текущей организационной структуры?
  • Какой уровень поддержки необходим для осуществления плана УК?
  • Это единственный проект для руководства, или руководство управляет несколькими проектами одновременно?
  • Как распределяется ответственность при возникновении нештатных ситуаций?
  • Имеются ли особенности для этого проекта, которые могут повлиять на бизнес?
  • Какие действия выполняет группа CCB в проектном управлении при планировании?
  • Прозрачно ли описаны роли участников?
Tools, Environment, and Infrastructure Рассматривается рабочая среда и программное обеспечение, которое будет использовано при выполнении функций конфигурационного управления в ходе жизненного цикла проекта или программного продукта.
Описываются инструменты и процедуры, которые нужно использовать для версионного контроля объектов конфигурационного управления, создаваемых в ходе жизненного цикла проекта или программного продукта.
Вопросы, рассматриваемые при настройке рабочей среды конфигурационного управления:
ожидаемый размер данных по программному продукту;
распределение рабочей команды;
расположение серверов и рабочих станций. 		Детальное описание данного пункта позволит, во-первых, понять самим какие средства разработки используются в компании (зачастую до начала внедрения в большой компании никто кроме начальника отдела разработки не представляет полного списка средств). Полный учет средств необходим еще и для того, чтобы определить методы интеграции средств разработки со средствами УК, ведь известно, что любое средство УК имеет ограниченные возможности по интеграции со средствами разработки. Задача менеджера УК и администратора в этом случае заключается в том, чтобы выбрать сторонние разработки, которые делают интеграцию либо более полной, либо просто добавляют саму интеграцию в используемое средство разработки + в средство УК.
Не менее важно описать среду исполнения. Не все средства УК одинаково ставятся на всех платформах. Здесь могут быть особенности.
Как вариант: сервер Linux, клиенты Windows.
Не все средства УК умеют работать в подобной среде, что надо учитывать при выборе средства.
Вопросы :
  • Каковы организационные интерфейсы?
  • Как взаимодействую процессы?
  • Каков перечень процессов для взаимодействия?
  • Каковы интерфейсы между применяемыми средствами автоматизации?
  • Каковы зависимости между ними?
  • Есть ли аппаратные зависимости?
  • Где определены документы, регламентирующие процесс?
  • Они утверждены?
  • Каковы процедуры внесения изменений в эти документы?
  • Каковы задействованные ресурсы (человечески, оборудование)?
The Configuration Management Program
Configuration Identification Вопросы :
  • Доступны ли стандартные методы идентификации?
  • В чем состоит используемая схема идентификации объектов УК?
  • Связаны ли программные и аппаратные идентификации (для встроенных систем)?
  • Какие спецификации и планы управления должны быть идентифицированы?
  • Необходима ли специальная схема идентификации чтобы отслеживать ПС третьей стороны?
  • Есть ли разница в идентификации элементов в зависимости от типа приложений?
  • Есть ли подтипы (например, компилятор С++ может работать с файлами c, cpp, h, hpp и др)?
  • Идентифицируются ли и хранятся скрипты автоматизированного тестирования?
3.1.1 Методы идентификации Identification Methods Описывается, как именуются, маркируются и нумеруются артефакты проекта или программного продукта. Схема идентификации должна покрывать оборудование, системное программное обеспечение, продукты внешних разработчиков и все артефакты разрабатываемого приложения, указанные в структуре директорий программного продукта; например, модели, планы, компоненты, тестовое ПО, результаты и данные, исполняемые файлы и т.д Очень важный пункт, в котором нужно описать все правила именования объектов УК. Также здесь должно быть детально расписана структура каталогов проекта. Обычно к моменту внедрения УК структура каталогов проекта складывается исторически, зачастую - спонтанно. Цель описания - выработать новую более эффективную структуру. Практика показывает, что человек на этапе восстановления структуры может увидеть уязвимые или неэффективные места.
3.1.2 Базовые версии проекта Project Baselines Базовые версии предоставляют официальный стандарт, на котором основывается последующая работа и для которого проводятся только авторизованные изменения.
Описывается, в какой точке жизненного цикла проекта или продукта должны создаваться базовые версии. Наиболее общие базовые версии должны быть в конце каждой из фаз обследования, проработки проекта, построения системы и передачи в эксплуатацию. Базовые версии также могут создаваться в конце итераций внутри различных фаз или даже чаще.
Определяется, кто может создавать базовые версии и что входит в их состав (обычно это интегратор, но может быть и по-другому) 		Здесь описывается то, каким образом будет происходить сама работа в средстве УК. Как будут ставиться метки, как выпускаться релизы. Сколько ветвей для реализации проекта будет использовано, и по какому принципу ветви будут именоваться.
Обратите особое внимание на данный пункт – без него невозможна эффективная работа.
При проработке пункта учитывается региональная раздробленность команды (влияет состав команд, количество регионов), интенсивность внесения изменений, количество выпускаемых релизов за единицу времени. Соответственно, в зависимости от данных показателей выбирается наиболее эффективный способ управления конфигурациями, что и отражается в данном разделе.
Вопросы :
  • Какой способ выбора базовых версий используется?
  • Для всех ли элементов базовые версии строятся по одинаковы правилам?
  • Кто разрешает создание базовых версий?
  • Кто физически создает базовую версию?
  • Как и по какому шаблону создаются базовые версии?
  • Как осуществляется продвижение базовых версий?
  • Как и кем осуществляется проверка базовых версий?
  • Какова периодичность проверок?
  • Используется ли существующий (устоявшийся) стандарт именования меток и ответвлений?
  • Есть ли иерархия между объектами? Какая?
Configuration and Change Control Как известно процесс УК состоит из двух частей – управление изменениями и управления версиями.
Управление изменениями – неотъемлемая и важная часть процесса. Управлять необходимо любыми изменениями: от заявок пользователей до исправляемых дефектов.
Данный раздел содержит полно описание всех запросов на изменения, включая атрибуты и жизненный цикл. Подробное описание – залог успешно построенного процесса УК.
Очень часто для отслеживания существенных событий в проекте, применяют уведомления различного вида. Как правило, это уведомления по электронной почте (например при исправлении ошибки тестер получает уведомление и может приступить к тестированию). Укажите все типы уведомлений, которые применяются в проекте.
Вопросы :
  • Какие типы запросов планируется использовать в процессе УК?
  • Каков полный цикл запросов на изменения?
  • Будет ли храниться в системе УК справочная информация, или необходимо подключаться к имеющейся справочной информации?
  • В какой информации, возможно, будут нуждаться члены CCB?
  • Каковы основные ожидания от автоматизации управления изменениями?
  • При иерархической проектной структуре как будут приниматься решения по запросу?
  • Необходимо ли управлять всеми запросами на изменения?
  • Каков уровень детальности управления будет выбран (сколько шагов/этапов)?
  • Обеспечивается ли отслеживание изменений в исходных текстах (есть ли связь между изменениями на верхнем уровнем и описание изменений на уровне файлов)?
  • Как исходный текст ассоциируется с запросом?
  • Будет ли применена система оповещений?
Change Request Processing and Approval Рассматриваются процессы, которые обеспечивают внесение, рассмотрение и упорядочение проблем и изменений. Определяются типы запросов. Как правило это: Дефект, Запрос на расширение, Задача и Заявка. Состав типов может существенно меняться, главное не сводить все управление изменениями к одному типу запросов (очень часто кроме как Дефектами компании ничем не управляют)
Change Control Board (CCB) Описывается, кто входит в состав группы управления изменениями и процедуры, которым она следует, для отработки и утверждения запросов на изменение. В некоторых случаях указывается регламент сбора группы. Решение о принятии запроса от пользователя, решение о реализации новой технической идеи практически никогда не решаются одним человеком. В любой компании это группа людей. В терминах стандартов данная группа называется CCB.
В данном разделе необходимо описать состав участников (как правило, это аналитик или постановщик, лидер группы разработчиков, лидер группы тестировщик и представитель отдела маркетинга) и периодичность заседаний. Например группа CCB может собираться каждую неделю (по регламенту) либо по возникшей потребности (не рекомендуется).
Вопросы :
  • Каковы пределы полномочий группы?
  • Одна группа на все проекты или несколько групп - каждая на свой проект?
  • Если несколько, то, каким образом они сотрудничают друг с другом?
  • Есть ли иерархия CCB?
  • Кто отвечает за коммуникации между CCB?
  • Будет ли поддерживать система УК специальные запросы для организации встреч и выпуска протоколов по результатам?
  • Есть ли потребность в выработки регламента для ограничения действий группы (жесткий регламент встреч с высокой степенью формализма)?
  • Как различаются уровни привилегий в группе?
  • Меняет ли введение группы CCB установленный порядок принятия решений в организации?
  • Введены ли в состав CCB все ключевые участники, включая менеджера УК, менеджера проекта, лидера тестировщиков, лидера разработчиков и архитекторов?
  • Каковы процедуры устранения разногласий (выпуск протокола разногласий или нечто иное)?
  • Автоматизирована ли данная процедура?
Configuration Status Accounting
Project Media Storage and Release Process Описываются правила хранения и регламенты резервирования, действия на случай непредвиденных обстоятельств.
Описание процесса выпуска релизов включает их содержание, для кого они предназначены и имеются ли какие-либо известные проблемы и инструкции по инсталляции (можно вынести в отдельное приложение)
3.3.2 Отчеты и проверки Reports and Audits Reports and Audits Рассматривается содержание, формат и цель запрашиваемых отчетов и проверок состояния конфигурации.
Отчеты используются для получения данных о «качестве программного продукта» в любой заданный момент времени жизненного цикла программного продукта или проекта. Отчетность по дефектам, основанная на запросах на изменения, может обеспечить некоторые удобные индикаторы качества и, следовательно, предостеречь менеджеров и разработчиков об определенных критических областях процесса разработки. 		Отчетам следует уделить особое внимание. Только по отчетам можно проследить ход выполнения работ.
Здесь необходимо определить отчеты по ролям участников проекта и описать их формат.
Также рекомендуется сформировать регламент сбора отчета, то есть с какой периодичностью собираются метрики (в реальном времени, раз в день… итд). Желательно выделить различные типы отчетов и периодичность сбора их метрик.
Вопросы :
  • Есть ли необходимость в более чем одной ревизии для каждой базовой версии?
  • Вовлечены ли субподрядчики в ревизию?
Отчеты :
Вопросы:
  • Какие метрики собираются в ходе проекта?
  • Какие типы отчетов необходимо иметь?
  • Способы представления отчетной информации?
  • Есть ли внешние отчетные документы для клиентов?
  • Дифференцируются ли отчеты в зависимости от типа выполняемой участником роли в проекте?
  • Доступны ли отчеты?
  • Какие будут предусмотрены формальные шаги для получения отчетов?
  • Какие типы нотификационных сообщений будут применяться?
  • Отслеживаются ли тенденции в проекте? По каким отчетам?
  • Как ведется учет (статически, динамически)?
  • Какие средства используются для получения отчетов (допускается использование любого числа систем для получения достоверной Ии понятной информации о ходе проекта)?
3.3.3 Документирование Documents Раздел определяет способы и типы документов
3.3.3.1 Описание версии Version Description Данный документ описывает диски, CD или другие носители, используемые для поставки ПО.
Также данный раздел также определяет состав документов поставляемых с версией ПО и доступных для конечных пользователей. 		Примерный состав документов:
  • Архив релизов с описанием (Release Media);
  • Описание релиза (Release Notes);
  • Описание функций;
  • Перечень решенных проблем в релизе;
  • Перечень новых возможностей;
  • Инструкция по установке ПО;
  • Инвентаризация, опись.
Данный пункт может содержать основные правила формирования документов, отражать способ выпуска документов (ручной, автоматический). Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК. Перечень приведенных документов относится к выпуску ПС для каждой версии, релиза, патча. В зависимости от выбранной модели выпуска состав документов. А также их детальность могут различаться.
CM Documents Общие документы, требуются в случаях, когда продукт разрабатывается для крупных организаций, а также в тех случаях, когда продукт представляет собой программно-аппаратный комплекс. Типовые документы для данного раздела:
  • Описание системы, в которой используется ПС;
  • Описание административного управления программными средствами системы;
  • Руководство системного администратора;
  • Руководство пользователя;
  • Паспорт на ПС (общие сведения о ПС. основные характеристики, комплектность, акты о приемке и снятии с эксплуатации… итд).
Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК.
4. Этапы Milestones Детально рассматриваются этапы работ для заказчика и внутренние, относящиеся к работам по УК для программного продукта или проекта. Эта секция обычно включает детальное описание того, когда может быть модифицирован сам план конфигурационного управления В зависимости от выбранной модели может измениться содержание этапов. Рекомендуется описать, что выполняется в УК в зависимости от этапа проекта.
5. Обучение и ресурсы Training and Resources Рассматриваются инструментальные средства, персонал и обучение, требуемые для реализации описанных в плане задач
Subcontractor and Vendor Software Control Описывается, как будет интегрировано программное обеспечение, разработанное вне среды УК проекта К работе над проектом могут привлекаться субподрядчики. Данный раздел описывает каким образом будет происходить работа с субподрядчиком.
Вопросы :
  • Разработка ведется только в одно организации или в обеих?
  • Каковы процедуры корректировки дефектов в разрабатываемом продукте?
  • Автоматизированы ли они (полностью или частично)?
  • Какие изменения допустимо вносить Заказчику в исходные тексты после получения продукта?
  • Ставится ли в известность об этом субподрядчик, и в какой мере?
  • Когда и как выполняются ревизии?
  • Какой набор инструментальных средств используется Заказчиком и Субподрядчиком?
  • Необходимы ли дополнительные модули синхронизаций (для тех случаев когда Заказчик и Подрядчик используют разные системы УК от разных производителей)?
  • Как контролируется Субподрядная организация?
  • Кто отвечает за работу с Субподрядчиком?
  • Работает ли субподрядчик по своим процессам или Заказчик обязывает его работать по собственным?
  • Как решаются конфликты?
  • Разрешено ли Субподрядчику осуществлять полную сборку продукта у себя, или Заказчик выделяет стенд для сборки на своей территории?
  • Допускается ли Субподрядчик к справочной информации Заказчика (доступ к реальным базам данных, справочникам)?
Приложения Состав приложений не определяется стандартами. Обычно включает в себя такие документы как:
  • Регламенты;
  • Инструкции по использованию средств УК (как пользовательские так и административные);
  • Различные методические пособия;
  • Планы обучения;
  • Инструкции по установке и администрированию средств УК.
И т.д. 		Руководствуйтесь целесообразностью внесения тех или иных изменений. Оцените, все ли попало в основные разделы плана. Если основные раздел слишком «разрослись», то, возможно нужно вынести из них часть информации в приложение.

Полнота плана УК в зависимости от объема проекта и его типа

Японская мудрость гласит: «Чем завтра сто, лучше сегодня пятьдесят». Применительно к плану УК ее можно перефразировать как: «Лучше полплана сегодня, чем полный завтра».

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

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

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

Применяется следующая градация:

  • Малый - в этом проекте участвуют 2-7 разработчиков, тестировщиков почти нет, либо разработчики сами выполняют тестирование. Также в данную категорию могут попасть проекты, в которых нет параллельной разработки – то есть у каждого разработчика есть свой круг решаемых задач. Роли определены не четко. Команда находится в одной комнате;
  • Средний – это проект, в котором участвуют более 6 разработчиков. Ведется разработка коробочных продуктов на продажу. В команде есть выделенные роли: разработчики, тестировщики, аналитики, системные аналитики. Разделение достаточно четкое, но есть совмещение ролей. Все участники находятся в одном офисе, но в разных рабочих комнатах.
  • Крупный – тоже, что и средний, но возможно, работа над проектом ведется с несколькими субподрядчиками. Сама компания разбросана по нескольким регионам. В компании много параллельно идущих проектов.

Применена следующая градация:

  • Обязательность пункта – нужен ли данный пункт плана в проекте данного типа, можно ли отказаться от пункта без ущерба целостности логической стройности плана УК.
  • Детальность изложения – насколько глубоко необходимо проработать раздел. Какова его детальность? Нужно ли вносить дополнительные подпункты, раскрывающие значения основных пунктов?
  • Формальность изложения – этот пункт больше относится к стилю и коррелируется с детальностью и обязательностью. Для желательного раздела в маленьком проекте допускается нестрогий стиль изложения.
Таблица 3 – обязательность, формальность и глубина изложения пунктов плана УК.
Раздел плана Тип проекта
Малый Средний Крупный
1. Введение
1.1 Назначение О НД НФ О СД Ф О СД Ф
1.2 Область применения О НД НФ О СД Ф О СД Ф
1.3 Определения, акронимы и сокращения Ж НД НФ О СД Ф О СД Ф
1.4 Ссылки П О СД О СД Ф
1.5 Обзор Ж СД НФ О СД Ф О ВД Ф
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 Документирование процесса П П О ВД Ф
4. Этапы Ж НД НФ О СД Ф О ВД Ф
5. Обучение и ресурсы Ж НД НФ О СД Ф О ВД Ф
6. Субподрядчики и контроль программного обеспечения со стороны поставщиков П П О ВД Ф
Приложения П Ж НД НФ О ВД Ф

Сокращения к таблице:

О – обязательно; Ж – желательно, П – можно пропустить.

ВД – высокая детальность, СД – средняя детальность, НД – низкая детальность.

Ф – формально, НФ – неформально.

Ресурсы для скачивания

static.content.url=http://www.сайт/developerworks/js/artrating/

ArticleID=208482

ArticleTitle=Разработка плана управления конфигурацией

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

Потом все чуть-чуть повзрослели. Появились и начали как-то использоваться redmine/jira/etc, git/svn, jenkins, spinx-docs/rubydoc/doxygen/etc, wiki, unit тесты. Появились подпроекты, стенд подрос. Production сервачков стало несколько. Админ поднял salt/puppet/etc, мониторинг, сидит в своем логове как паук, правит конфиги на salt-master и дергает оттуда state.highstate.

Жизнь

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

Стадий жизненного цикла всего семь.

  1. Conceptual design. На этом этапе надо понять, что вообще надо делать.
  2. Architectural design. На этом этапе надо понять как это нужно делать.
  3. Implementation. Это непостредсвтенно кодинг и unit тестирование.
  4. Verification. Проверка того, что все задуманные функции программа выполняет.
  5. Validation. Проверка того, что программой таки можно пользоваться. Из предыдущего пункта это внезапно не следует.
  6. Ввод в эксплуатацию. В нее обычно входят выкатка релиза, миграция данных, обучение пользователей.
  7. Собственно сама эксплуатация.
  8. Вывод из эксплуатации
Восемь. Про последий пункт все забывают. А он таки тоже очень важен (и не только для атомной станции). Для программного проекта надо позаботиться о данных. На этапах до ввода в эксплуатацию надо убедиться, что все нужные данные из него можно будет извлечь, а на этапе вывода из эксплуатации, что данные реально были извлечены.

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

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

Что может сломаться?

Версии библиотек. Собрались, набросали диаграмку классов, договорились использовать libcrutch. Одна команда давно и долго сидела на libcrutch-1.0, вторая о ней только узнала и скачала из Интернета libcrutch-2.0. А выясниться это только на интеграционном тестировании. Словить bug можно даже на отличиях libcrutch-1.2.14 и libcrutch-1.2.15. А всякие LD_PRELOAD или docker только подливают масла в огонь. Даже если проект весь из себя на микросервисах, в интерфейсы может быть венесен обмен данными, полученными из libcrutch и имеющими в разных версиях разный формат.

Несоответствие версий компонент. Одни пилят libbase, другие libManagementFacade. В процессе выяснилось, что в libbase-1.14.3 есть мелкий но коварный bug. Поговорили, поправили, забыли. Тестировались на libbase-1.14.4, а в релиз ушло libbase-1.14.3.

Изменение конфигурации окружения. Один POST запрос внезапно начал работать долго. Посмотрели, он не такой уж и важный, пусть себе поработает.Увеличили в nginx таймаут ожидания ответа backend"а. Админ на стенде поправил и забыл. Выкатились и опять старые баги ловить, но теперь уже в боевых условиях.

Изменение проектных решений. Начинали делать под Windows, потом прониклись идеями RMS"а, решили перейти на Ubuntu, но до всех решение не довели. Начали собирать, все принесли deb пакеты, а кто-то, кто был в танке, exe"шник.

Потеря значимого для пользователя функционала. Принесли новую версию, долго рассказывали про смену дизайна, про новые фреймворки, про передовые алгоритмы. Пользователи послушали, головой покивали, и сказали: «Это все хорошо, но вы для нас по нашей просьбе формочку делали. Раньше она была пятым подпунктом в третьем пункте меню, где она теперь?» Потеряли на каком-то merge request"е.

Что делать

Программистам очень повезло, что есть git. Основной удар он берет на себя и от них самих требуется совсем чуть-чуть.
  1. Определить все компоненты, которые нужны для функционирования проекта, убедиться, что они корректно версионируются. Конфигурация в первом приближении это список компонент и их версий.
  2. Понять как обеспечивается перенос конфигурации со стенда в production.
  3. Начать управление требованиями. Вообще говоря, управление требованиями это отдельный процесс. В рамках управления конфигурацией нужно убедиться, что для каждого компонента, попавшего в релизный набор, прилагается документация, в которой точно описаны требования, предъявленные к этому компоненту, и их cтатуcы: выполнено, не выполнено, выполнено частично, с оговорками.
  4. Да и вообще у каждого компонента должна быть документация, которая описывает что как и зачем он делает.
На этапе завершения conceptual design"а , когда специалисты предметники говорят: «Такая система нам нужна!», - технари в один голос заявляют «Сделаем!», - менеджеры дают отмашку: «Ресурсы выделим - делайте!», - нужно убедиться, что согласованное описание системы из головы экспертов вынуто, на требования порезано и в документацию положено. В процессе разработки это описание будет меняться. Надо убедиться, что описание версионируется. Неплохой вариант, если это текст, забрать его в git

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

На этапе разработки нужно убедиться, что код документируется. Неплохо на модули заводить отдельные документы (в git), которые описывают требования к ним и их особенности поведения. Оставлять много информации в redmine/jira не стоит. После допила большой фичи, перед merge"ом в master, нужно убедиться, что ее описание из task tracker"а корректно перенесено в документацию. Просто потому, что через некоторое время в рамках другой задачи поведение может поменяться и собирать документацию по нескольким задачам будет сложно. Task tracker целостную картину не обеспечивает.

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

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

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

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

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

На этапе вывода из эксплуатации надо убедиться, что все нужные данные вынуты.

Про сборку и salt/puppet. Это вторая линия обороны (сразу после git"а) Рабочая схема применения примерно такая:

  1. Убедиться, что ситуация с каждым сторонним пакетом ясна: откуда взято, какая версия, какие патчи накладывались. Если какая-то редиска (нехороший человек) приклеивает одинаковые версии на физически разные файлики, его надо убедить, что он не прав, или на всю его продукцию наклеивать дополнительную версию.
  2. Если все rpm"ки скидываются в один репозиторий, нужно убедиться, что понятно, какая именно версия будет накатана. Неплохой вариант - иметь скрипт пересборки всего репозитория и наклеивать версию на весь репозиторий целиком. Другой - версию указывать явно в манифесте/sls-файле. Кстати, у puppet"а есть bug, ресурс package не умеет версию понижать. Почему им не стыдно, я не знаю.
  3. Все манифесты/sls файлы храняться в git. В pillar для salt или параметры классов для puppet выносится только то, что отличает стенд от продакшена. Такими вещами, например, являются ulr"ы web сервисов, параметры наподобии shared_buffers для postgres, флаги, включающие debug режим. Все остальное безжаластно hard"кодится. Параметры задаются один раз при развертывании стенда и в дальнейшем меняются редко. sls файлы воспринимаются как код, он накатывается на стенд, тестируется и в неизменном виде переносится в production.
На этом все. Управляйте конфигурацией правильно, и не забывайте, что хороший тех процесс, это тот, который обходит все грабли и дает отличный результат с первого раза.

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

08.08.2013 Никита Налютин

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

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

Объект конфигурации (Configuration Item, CI): исходные тексты, скомпилированные программы, исходные коды программ, документация, элементы аппаратуры, процедуры и материалы обучения и т.п. - базовое понятие процесса управления конфигурациями Однако обычно под управление конфигурациями попадают только результаты проектной деятельности: программное обеспечение и сопутствующая документация, требования к интерфейсам и документация, выходные файлы, полученные при использовании инструментов проекта, технико-экономические документы и записи пользовательских требований, планы управления проектом, инструменты и руководства пользователя, записи об истории проекта, тест-планы, процедуры и отдельные тестовые примеры.

При объединении объектов конфигурации образуется их конфигурация - любая структурированная совокупность объектов разработки программной системы, представленных в виде CI, или совокупность процессов и технологических цепочек проекта по разработке программной системы, описания которых также могут быть представлены в виде CI. Процесс управления конфигурациями в различных отраслях регламентируется международными и национальными стандартами: ГОСТ Р 51904, DO-178, AS9100, AS9006, ISO10007, ISO/IEC TR 15846, ISO/IEC 15408, IEEE 1042 и пр. При разработке высококритичных систем применение процесса управления конфигурациями строго обязательно - цена исправления дефектов в таких системах может быть очень высока.

Стандарт ГОСТ Р 51904 был принят Госстандартом России в 2002 году и регламентирует требования к разработке и документированию встроенных систем. В нем процесс управления конфигурациями отнесен к группе интегральных процессов, необходимых для обеспечения качества выполнения процессов разработки и их выходных данных. Интегральные процессы выполняются одновременно с процессами разработки и обеспечивают непрерывную поддержку разработки. Основные цели процесса управления конфигурациями согласно ГОСТ 51904 состоят в том, чтобы обеспечить:

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

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

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

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

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

Кроме этого, имеются еще подпроцессы ведения отчетности о состоянии конфигурации, необходимые

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

Практически все процессы управления конфигурациями, определенные стандартом ГОСТ Р 51904, требуют отслеживания состояний жизненного цикла объектов, помещенных в конфигурацию. Так, контроль конфигурации подразумевает, что режим доступа к CI может изменяться в зависимости от их состояния. Создание базовых линий происходит только по достижении всех входящих в нее CI определенного состояния. Управление отчетностью о дефектах производится на основании информации о том, в каком состоянии находится отчет о дефекте и сам дефект, устранен ли он. Отчет о состоянии конфигурации в обязательном порядке включает в себя информацию о состояниях CI. Архивирование конфигураций также может изменять их состояние. Процесс контроля загрузки ПО автоматизируется при помощи создания базовой линии из CI, достигших определенного состояния. Контроль среды жизненного цикла производится на основании информации о том, в каком состоянии находятся инструменты проекта, не требуется ли их обновление.

По своей сути ГОСТ Р 51904, область применения которого - любые встроенные системы, базируется на международном стандарте DO-178, используемом при разработке авиационных систем. Системы, разработанные в соответствии с этим стандартом, могут быть сертифицированы согласно требованиям летной годности.

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

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

С точки зрения стандарта ISO 10007 управление конфигурациями - это управленческая дисциплина, применяемая на протяжении всего жизненного цикла изделия для обеспечения наглядности функциональных и физических характеристик и управления ими. Данная деятельность является способом удовлетворения определенных требований, содержащихся в других международных стандартах серии ИСО 9000. Согласно данному стандарту, процесс управления конфигурациями включает в себя следующие виды деятельности: идентификацию конфигураций, контроль конфигураций, представление отчетности о статусе конфигураций, проверку конфигураций. Охват данного стандарта шире, чем у предыдущих двух, - это не только разработка программного обеспечения, но и все результаты деятельности компании, управление которыми может вестись в соответствии с принципами управления конфигурациями.

Существуют также стандарты AS 9100/AS9006, специально адаптирующие требования системы менеджмента качества ISO к авиационной отрасли.

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

Никита Налютин ([email protected]) - менеджер по обеспечению качества, компания Experian (Москва).



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

Разработка плана управления конфигурацией

Что такое план УК?

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

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

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

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

Кто пишет план УК?

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

Если говорить применительно к терминологии УК, то есть роль, которая отвечает за физическое написание плана - Менеджер УК.

Менеджер Управления Конфигурациями - ключевая роль. Этот человек знает процесс разработки. Понимает цели и задачи УК. Все свои знания он излагает в плане УК. Сам управляет процессом УК.

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

Техническое применение плана (реализация плана в средствах поддержки УК)

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

  • Установить средства;
  • Разработать экранные формы запросов на изменение;
  • Установить политику доступа;
  • Определить жизненный цикл запросов на изменение;
  • Поставить данные под УК в соответствии с планом;
  • И т.д.

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

Когда готовят план УК?

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

Что хорошо в плане УК, так это то, что он долго пишется всего один раз. Далее для каждого проекта пишется новый план, на основе существующего, так как способы и методы в новом проекте могут отличаться, то и план описывает все особенности данного проекта. Иногда применяется практика выделения общих частей плана УК и утверждение их как составная часть стандарта на разработку в компании. После чего каждый проект использует общий план + выпускает к нему набор дополнений для конкретного проекта. Впрочем набор дополнений не может противоречить основному плану.

Поддержка плана в актуальном состоянии

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

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

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

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

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

План УК в стандартах

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

Таблица 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

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

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

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

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

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

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

Вопросы:

  • Каковы возможности организации по штату для выполнения операций УК?
  • Какова структура управления?
  • Каков стиль управления?
  • Кто будет ответственен за выполнение операций?
  • Какие организационные изменения могут быть в течении жизни плана УК?
  • Каковы планы по поддержке текущей организационной структуры?
  • Какой уровень поддержки необходим для осуществления плана УК?
  • Это единственный проект для руководства, или руководство управляет несколькими проектами одновременно?
  • Как распределяется ответственность при возникновении нештатных ситуаций?
  • Имеются ли особенности для этого проекта, которые могут повлиять на бизнес?
  • Какие действия выполняет группа CCB в проектном управлении при планировании?
  • Прозрачно ли описаны роли участников?

Tools, Environment, and Infrastructure

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

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

ожидаемый размер данных по программному продукту;

распределение рабочей команды;

расположение серверов и рабочих станций.

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

Не менее важно описать среду исполнения. Не все средства УК одинаково ставятся на всех платформах. Здесь могут быть особенности.

Как вариант: сервер Linux, клиенты Windows.

Не все средства УК умеют работать в подобной среде, что надо учитывать при выборе средства.

Вопросы:

  • Каковы организационные интерфейсы?
  • Как взаимодействую процессы?
  • Каков перечень процессов для взаимодействия?
  • Каковы интерфейсы между применяемыми средствами автоматизации?
  • Каковы зависимости между ними?
  • Есть ли аппаратные зависимости?
  • Где определены документы, регламентирующие процесс?
  • Они утверждены?
  • Каковы процедуры внесения изменений в эти документы?
  • Каковы задействованные ресурсы (человечески, оборудование)?

The Configuration Management Program

Configuration Identification

Вопросы:

  • Доступны ли стандартные методы идентификации?
  • В чем состоит используемая схема идентификации объектов УК?
  • Связаны ли программные и аппаратные идентификации (для встроенных систем)?
  • Какие спецификации и планы управления должны быть идентифицированы?
  • Необходима ли специальная схема идентификации чтобы отслеживать ПС третьей стороны?
  • Есть ли разница в идентификации элементов в зависимости от типа приложений?
  • Есть ли подтипы (например, компилятор С++ может работать с файлами c, cpp, h, hpp и др)?
  • Идентифицируются ли и хранятся скрипты автоматизированного тестирования?

3.1.1 Методы идентификации

Identification Methods

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

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

3.1.2 Базовые версии проекта

Project Baselines

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

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

Обратите особое внимание на данный пункт - без него невозможна эффективная работа.

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

  • Какой способ выбора базовых версий используется?
  • Для всех ли элементов базовые версии строятся по одинаковы правилам?
  • Кто разрешает создание базовых версий?
  • Кто физически создает базовую версию?
  • Как и по какому шаблону создаются базовые версии?
  • Как осуществляется продвижение базовых версий?
  • Как и кем осуществляется проверка базовых версий?
  • Какова периодичность проверок?
  • Используется ли существующий (устоявшийся) стандарт именования меток и ответвлений?
  • Есть ли иерархия между объектами? Какая?

Configuration and Change Control

Как известно процесс УК состоит из двух частей - управление изменениями и управления версиями.

Управление изменениями - неотъемлемая и важная часть процесса. Управлять необходимо любыми изменениями: от заявок пользователей до исправляемых дефектов.

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

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

Вопросы:

  • Какие типы запросов планируется использовать в процессе УК?
  • Каков полный цикл запросов на изменения?
  • Будет ли храниться в системе УК справочная информация, или необходимо подключаться к имеющейся справочной информации?
  • В какой информации, возможно, будут нуждаться члены CCB?
  • Каковы основные ожидания от автоматизации управления изменениями?
  • При иерархической проектной структуре как будут приниматься решения по запросу?
  • Необходимо ли управлять всеми запросами на изменения?
  • Каков уровень детальности управления будет выбран (сколько шагов/этапов)?
  • Обеспечивается ли отслеживание изменений в исходных текстах (есть ли связь между изменениями на верхнем уровнем и описание изменений на уровне файлов)?
  • Как исходный текст ассоциируется с запросом?
  • Будет ли применена система оповещений?

Change Request Processing and Approval

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

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

Change Control Board (CCB)

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

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

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

Вопросы:

  • Каковы пределы полномочий группы?
  • Одна группа на все проекты или несколько групп - каждая на свой проект?
  • Если несколько, то, каким образом они сотрудничают друг с другом?
  • Есть ли иерархия CCB?
  • Кто отвечает за коммуникации между 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 или другие носители, используемые для поставки ПО.

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

Примерный состав документов:

  • Архив релизов с описанием (Release Media);
  • Описание релиза (Release Notes);
  • Описание функций;
  • Перечень решенных проблем в релизе;
  • Перечень новых возможностей;
  • Инструкция по установке ПО;
  • Инвентаризация, опись.

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

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

Типовые документы для данного раздела:

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

Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК.

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

В зависимости от выбранной модели может измениться содержание этапов. Рекомендуется описать, что выполняется в УК в зависимости от этапа проекта.

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. Субподрядчики и контроль программного обеспечения со стороны поставщиков

Приложения

Сокращения к таблице:

О - обязательно; Ж - желательно, П - можно пропустить.

ВД - высокая детальность, СД - средняя детальность, НД - низкая детальность.

Ф - формально, НФ - неформально.

Мониторинг проекта

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

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

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

Для осуществления мониторинга необходимо сформировать команду в соответствии со следующими правилами.

  • 1. Это должна быть небольшая команда, состоящая из экспертов, имеющих опыт осуществления проектов и знания особенностей данного проекта.
  • 2. Команда изучает проект на месте его проведения.
  • 3. Команда составляет краткие отчеты и передает их менеджменту проекта.
  • 4. Предложения и рекомендации, сделанные командой, должны учитываться, а их реализация – проверяться при осуществлении дальнейших мониторингов.

Процедура мониторинга представлена на рис. 11.2.

Рис. 11.2.

Управление изменениями

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

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

Характеристики контекста организационных изменений показаны в табл. 11.1.

Таблица 11.1

Основные характеристики контекста организационных изменений

Характеристика

Основные аспекты

Власть и влияние

Кому принадлежит власть в организации?

Чьей поддержкой внутри и вовне организации необходимо заручиться?

Какими возможностями по проведению изменений обладают руководители отдельных подразделений?

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

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

Масштаб изменений

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

Изменения должны в основном затронуть какое-то конкретное подразделение или всю организацию в целом?

Степень сохранения активов

Идентификация осязаемых и неосязаемых активов. Что целесообразно сохранить и что можно ликвидировать?

Степень разнообразия персонала

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

Способность к изменениям, потенциал

Есть ли у организации способность, опыт и потенциал для преобразований?

Как широко этот потенциал распространен внутри организации?

Насколько глубоко организация и ее персонал изменялись в прошлом?

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

Платежеспособность

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

Готовность к изменениям

Персонал сознательно идет на перемены или людей надо убеждать?

Какова степень сопротивления изменениям?

Какова степень поддержки изменений?

Путь изменений

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

Реконструкция – быстрые преобразования в части организации.

Трансформация – полное изменение организации быстро, в сжатые сроки

Стиль изменений

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

Цель изменений

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

Роли в изменениях

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

Механизмы и рычаги для проведения изменений

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

Процесс управления изменениями состоит из двух стадий. Это показано на рис. 11.3.

Рис. 11.3.

В самом общем виде логика внедрения изменений может быть представлена на рис. 11.4.

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

Рис. 11.4.

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

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

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

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

Эти стадии отражены на рис. 11.5.

Рис. 11.5.

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

  • 1) содержания продукта (состав и спецификация элементов продукта);
  • 2) содержания проекта (состав и содержание работ проекта) – например, внесение незначительных, но, как правило, многочисленных и зачастую неконтролируемых улучшений по просьбе заказчика. Последнее особенно характерно для инновационных проектов, где заказчики занимают активные позиции в ходе их реализации;
  • 3) сроков и стоимости проекта;
  • 4) процедур управления проектом;
  • 5) вследствие реакции на наступление рисковых событий.

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

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

Внесение изменений в проект предполагает:

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

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

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

  • 1. Отчет о проблеме (Problem report ) – описание проблемы, возникающей в ходе реализации проекта. Формируется на начальной стадии.
  • 2. Запрос на осуществление изменения (Change request) – формируется на начальной стадии.
  • 3. Описание предполагаемого изменения (Change proposal form) – информация об изменении, его текущем статусе, инициаторах и ответственных за выполнение и контроль. Формируется на начальной и корректируется на последующих стадиях.
  • 4. Заявка на изменение (Change order ) – оформляется в виде письменного приказа и подписывается должностным лицом подрядчика; разрешает и указывает, какие производить изменения по проекту. Формируется на стадии принятия решения.

Управление конфигурацией

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

Управление конфигурацией охватывает процессы:

  • – подачи предложенных изменений;
  • – отслеживания системы рассмотрения и утверждения предложенных изменений;
  • – определения уровней утверждения для авторизации изменений;
  • – обеспечения методов реализации одобренных изменений.

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

Этапы организации управления конфигурацией проекта представлены на рис. 11.6.

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



Читайте также...

Что такое творчество презентация

Что такое творчество презентация

Крымские устрицы, кубанский хамон и ладожская моцарелла Что мешает российскому производителю

Крымские устрицы, кубанский хамон и ладожская моцарелла Что мешает российскому производителю

История изобретения стекла

История изобретения стекла

Лучшее на сайте
1

Чем опасен уран и его соединения?

2

Шесть самых мощных флотов в мире

3

Полный обзор: метод оценки персонала «360 градусов

4

Исследование AdIndex: рынок Event&MICE по опросу заказчиков

5

Успешный и компетентностный человек

Новое
Инструкция по инсталляции клиентской части АИС госзакупок

Инструкция по инсталляции клиентской части АИС госзакупок "АЦК-Госзаказ" v

Крабовые страдания франка

Крабовые страдания франка

Картонные коробки и коробочки

Картонные коробки и коробочки

Техник (архитектура и строительство)Должностная инструкция

Техник (архитектура и строительство)Должностная инструкция

Описание закупки по 44 фз года

Описание закупки по 44 фз года

Должностные обязанности: главный механик

Должностные обязанности: главный механик

Неполное рабочее время устанавливается Укороченная рабочая неделя по инициативе работника

Неполное рабочее время устанавливается Укороченная рабочая неделя по инициативе работника

Регламентация деятельности персонала: анализ должностных инструкций (на примере Мэрии г

Регламентация деятельности персонала: анализ должностных инструкций (на примере Мэрии г

Рекомендуем почитать