Взаимозависимости подсистем
Лист утверждения
УТВЕРЖДЕН План конфигурационного управления
Листов 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. Если целесообразно, приводятся условия для начала этапов, формы внутренней отчетности и т.д.>. Порядок сборки <Данный раздел включается, если в проекте планируется специальный порядок сборки готового продукта. >
Популярное: Почему люди поддаются рекламе?: Только не надо искать ответы в качестве или количестве рекламы... Почему стероиды повышают давление?: Основных причин три... ©2015-2020 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (595)
|
Почему 1285321 студент выбрали МегаОбучалку... Система поиска информации Мобильная версия сайта Удобная навигация Нет шокирующей рекламы |