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