2. Идентификация объектов конфигурационного управления

План конфигурационного управления
УТВЕРЖДАЮ
Менеджер проекта
__________________ <И.O. Фамилия>
"___"_______________ 200_ г.
ПЛАН КОНФИГУРАЦИОННОГО УПРАВЛЕНИЯ
ДЛЯ ПРОЕКТА
<НАЗВАНИЕ ПРОЕКТА>
Лист утверждения
СОГЛАСОВАНО:
Менеджер по качеству
Интегратор проекта
____________<Фамилия И.О.>
____________<Фамилия И.О.>
"___"______________200_ г.
"___"______________200_ г.
План конфигурационного управления
УТВЕРЖДЕН
ПЛАН КОНФИГУРАЦИОННОГО УПРАВЛЕНИЯ
ДЛЯ ПРОЕКТА
<НАЗВАНИЕ ПРОЕКТА>
Листов 9
План конфигурационного управления
АННОТАЦИЯ
Настоящий документ является планом конфигурационного управления для
проекта <название проекта>. Утвержденный план обязателен для выполнения
всеми участниками данного проекта.
План конфигурационного управления
СОДЕРЖАНИЕ
1.
ВВЕДЕНИЕ..........................................................................................................6
1.1.
ЦЕЛЬ ДОКУМЕНТА............................................................................................6
1.2.
НОРМАТИВНАЯ ОСНОВА ..................................................................................6
1.3.
СВЕДЕНИЯ О ДОКУМЕНТЕ ................................................................................6
1.4.
ТЕРМИНЫ, СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ ......................................................6
2. ИДЕНТИФИКАЦИЯ
ОБЪЕКТОВ
КОНФИГУРАЦИОННОГО
УПРАВЛЕНИЯ ....................................................................................................................6
3.
4.
2.1.
РАЗРАБАТЫВАЕМЫЕ КОНФИГУРАЦИИ ПРОДУКТА ...........................................6
2.2.
ОПИСАНИЕ ПЛАТФОРМ РАЗРАБОТКИ ...............................................................7
2.3.
ФИЗИЧЕСКАЯ АРХИТЕКТУРА СИСТЕМЫ ...........................................................7
2.4.
ИДЕНТИФИКАЦИЯ
2.5.
ОПИСАНИЕ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ ....................................................7
2.6.
ОПИСАНИЕ ОБЪЕКТОВ КОНФИГУРАЦИОННОГО УПРАВЛЕНИЯ .........................7
2.7.
СТРУКТУРА БАЗЫ ДАННЫХ КОНФИГУРАЦИОННОГО УПРАВЛЕНИЯ ..................8
2.8.
СТАНДАРТ ИМЕНОВАНИЯ ................................................................................8
ПОДСИСТЕМ ......................................................................7
ПОРЯДОК СБОРКИ И ФОРМИРОВАНИЯ ВЕРСИЙ ..............................8
3.1.
ВЗАИМОЗАВИСИМОСТИ ПОДСИСТЕМ ..............................................................8
3.2.
ПОРЯДОК РАЗРАБОТКИ .....................................................................................9
3.3.
ПОРЯДОК СБОРКИ ............................................................................................9
3.4.
ПОРЯДОК ФОРМИРОВАНИЯ ВЕРСИЙ .................................................................9
РАСПРЕДЕЛЕНИЕ РОЛЕЙ В ПРОЕКТЕ ....................................................9
4.1.
МЕНЕДЖЕР ПРОЕКТА .......................................................................................9
4.2.
ИНТЕГРАТОР (ОТВЕТСТВЕННЫЙ
10
ПРОЕКТА)
ЗА
КОНФИГУРАЦИОННОЕ
УПРАВЛЕНИЕ
4.3.
РУКОВОДИТЕЛИ ПОДПРОЕКТОВ .....................................................................10
4.4.
ПРАВА ДОСТУПА ............................................................................................10
© АПЛАНА Софтвер
5
План конфигурационного управления
1. ВВЕДЕНИЕ
1.1. Цель документа
Целью настоящего документа является планирование конфигурационного
управления в данном проекте.
1.2. Нормативная основа
Настоящий план основан на «Положении о конфигурационном управлении при
выполнении проектов разработки прикладного программного обеспечения и документации. Версия 1.0»
1.3. Сведения о документе
Номер версии:
<1.0>.
Дата утверждения:
<00.00.200_> г.
<В процессе выполнения проекта настоящий план должен уточняться. Новые
редакции плана сохраняют номер версии документа.
Если же возникает необходимость пересмотра ранее принятых пунктов, выпускается новая версия плана. Причины и краткое содержание произведенных изменений в новой версии отражаются в настоящем введении. Новой версии плана присваивается следующий порядковый номер.>
1.4. Термины, сокращения и определения
Сокращение, термин
Расшифровка сокращения или термина
2. ИДЕНТИФИКАЦИЯ ОБЪЕКТОВ КОНФИГУРАЦИОННОГО
УПРАВЛЕНИЯ
2.1. Разрабатываемые конфигурации продукта
<Приводятся все конфигурации продукта, которые запланировано разработать
(демо-версии, версии для различных платформ и т.п.) Дается описание конфигураций
и их наименование в проекте: >
Наименование
конфигурации
© АПЛАНА Софтвер
Идентификатор
Описание
6
План конфигурационного управления
2.2. Описание платформ разработки
<Приводится описание платформ разработки создаваемого программного продукта>.
2.3. Физическая архитектура системы
<Приводится описание физической архитектуры системы или дается ссылка на
документ с описанием физической архитектуры (Технический проект)>
2.4. Идентификация подсистем
Полное
название
подсистемы
Идентификатор
Подсистемы
Идентификатор
головной
подсистемы
Мнемоническое
сокращение
(суффикс)
для
стандарта именования
2.5. Описание инструментальных средств
<Приводится перечень инструментальных средств разработки, библиотек и т.д.
с указанием версий. При необходимости перечень приводится отдельно для каждой
разрабатываемой подсистемы: >
Идентификатор
подсистемы
Инструментальное средство
Номер
версии
инструментального средства
2.6. Описание объектов конфигурационного управления
<Приводится полное описание объектов конфигурационного управления,
например, путем перечисления расширений файлов. Если возможно, ориентировочно
указывается ожидаемый объем разработок в доступной метрике на основе предыдущих проектов. При необходимости перечень приводится с разбивкой по подсистемам
и инструментальным средствам: >
Идентификатор Планируемый
Объекты конфигураци- Инструменобъем
онного управления
тальное сред- подсистемы
ство
© АПЛАНА Софтвер
7
План конфигурационного управления
2.7. Структура базы данных конфигурационного управления
<Приводится структура верхнего уровня базы данных конфигурационного
управления: >
Идентификатор
Идентификатор
Описание подпроекта
головного
подподпроекта
проекта
2.8. Стандарт именования
<Приводится стандарт именования объектов конфигурационного управления.
Стандарт должен обеспечивать уникальность имен. Рекомендуется в стандарте отражать структуру разрабатываемой системы, например:
<имя_файла> ::= <суффикс_подсистемы><суффикс под подсистемы><имя>
>
3. ПОРЯДОК СБОРКИ И ФОРМИРОВАНИЯ ВЕРСИЙ
3.1. Взаимозависимости подсистем
<Данный раздел включается в случае наличия перекрестных связей между подсистемами, которые влияют на порядок разработки, сборки, внесения изменений и
тестирования. Иерархические связи описываются в разделе 2.4 и здесь не приводятся.
Рекомендуемые значения параметров (в зависимости от типа разработки значения параметров могут быть другие):
Характеристика подсистемы:
-
Функциональная – подсистема является самостоятельной функциональной подсистемой (верхний уровень архитектуры);
-
Содержание Web – подсистема является содержанием разрабатываемого Web –
узла;
-
Сервисы пользователей – подсистема является набором компонент обеспечивающих интерфейс пользователя в функциональной подсистеме;
-
Бизнес сервисы – подсистема является набором компонент обеспечивающих бизнес логику функциональной подсистемы;
-
Сервисы данных – подсистема является набором компонент, обеспечивающих
связь функциональной подсистемы с базой данных;
-
База данных – подсистема является базой данных для функциональной подсистемы.
Характер зависимости:
© АПЛАНА Софтвер
8
План конфигурационного управления
-
Разработка – разработка зависимой подсистемы может быть полностью завершена только после завершения данной подсистемы;
-
Сборка – сборка зависимой подсистемы может быть осуществлена только после
сборки данной подсистемы;
-
Изменение – при необходимости внести изменения в зависимую подсистему
необходимо также внести изменения в данную подсистему;
-
Тестирование – для проведения тестирования зависимой подсистемы необходимо
провести тестирование данной подсистемы.
Примечание:
Качество архитектуры может быть оценено, в частности, по матрице взаимозависимостей между подсистемами: матрица должна быть слабо заполненной, треугольной и
практически одинаковой для разных характеров зависимостей.
Идентификатор
подсистемы
Характеристика подсистемы
Идентификатор
Характер зависимости
подсистемы, от которой зависит данная подсистема
>
3.2. Порядок разработки
<Описывается порядок разработки программного продукта или дается ссылка
на календарный план работ. Указывается регулярность и условия актуализации информации в базе данных CM. Если целесообразно, приводятся условия для начала
этапов, формы внутренней отчетности и т.д.>.
3.3. Порядок сборки
<Данный раздел включается, если в проекте планируется специальный порядок
сборки готового продукта. >
3.4. Порядок формирования версий
<Данный раздел включается, если в проекте планируется свой стандарт формирования версий системы, отличный от порядка, предусмотренного в Положении о
конфигурационном управлении. >
4. РАСПРЕДЕЛЕНИЕ РОЛЕЙ В ПРОЕКТЕ
4.1. Менеджер проекта
<Должность> <Фамилия Имя Отчество>.
© АПЛАНА Софтвер
9
План конфигурационного управления
4.2. Интегратор (ответственный за конфигурационное управление проекта)
<Должность> <Фамилия Имя Отчество>.
4.3. Руководители подпроектов
<Приводится список членов рабочей группы, ответственных за разработку подсистем >
Должность
Фамилия И.О.
Идентификатор подсистемы
4.4. Права доступа
<Приводится список членов рабочей группы, с указанием подпроектов в базе
CM, в которых они участвуют, и прав доступа к подпроектам.>
Роль
Фамилия И.О.
© АПЛАНА Софтвер
Идентификатор подпроекта
Право доступа
10