Добавлен: 25.10.2018
Просмотров: 4933
Скачиваний: 12
56
ПРИЛОЖЕНИЕ Е
(справочное)
IEEE 828-1990 ПЛАН УПРАВЛЕНИЯ КОНФИГУРАЦИЯМИ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
(SOFTWARE CONFIGURATION MANAGEMENT PLAN – SCMP)
Утверждаю
Дата
01.06.09 А. Мелихов: Создание первой версии
10.06.09 А. Мелихов: Рецензирование
18.06.09 А. Мелихов: Расширен раздел 5.2
18.07.09 А. Мелихов: Проверка для выпуска
30.07.09 А. Мелихов: Окончательное форматирование
02.08.09 А. Мелихов: Выпуск
1. Введение
Данный план управления конфигурациями ПО (SCMP) описывает, как ведется работа с артефактами
информационно-справочной системы (ИСС).
1.1. Сокращения
CI (Configuration Item) – элемент конфигурации – любой элемент, отслеживаемый системой управле-
ния конфигурациями.
СМ (Configuration Management) – управление конфигурациями – процесс поддержки релевантных
версий артефактов проекта.
SCMP (Software Configuration Management Plan) – данный документ.
SRS (Software Requirements Specification) – спецификация требований к программному обеспечению.
SDD (Software Design Document) – проектная документация программного обеспечения.
STD (Software Test Documentation по ANSI/IEEE 829-1983) – документация по тестированию про-
граммного обеспечения.
SPMP (Software Project Management Plan) – план управления программным проектом.
СММ (Capability Maturity Model) – модель технологической зрелости организаций.
1.2. Термины
Утвержденный CI — CI, подписанный руководством проекта.
Артефакт — окончательный или промежуточный материал проекта (например, документ, исходный
код, объектный код, результат теста).
Главный файл — специальным образом построенный файл для данного проекта, определяется в раз-
деле 3.1.2.
2. Управление конфигурациями
2.1. Организация
[Определите, как должно быть организовано управление конфигурациями. Укажите роли, но не
имена конкретных исполнителей — для этого служат другие разделы.]
Специальный инженер, выделяемый отделом контроля качества, будет назначен ведущим конфигу-
рацию на все время проведения данного проекта.
2.2. Ответственность за управление конфигурациями
[Определите ответственность каждой роли]
2.2.1. Ведущий конфигурацию
[Ведущий конфигурацию организовывает работу и контролирует ход ее выполнения]
Ведущий конфигурацию:
• отвечает за организацию и управление конфигурациями;
• обсуждает планы управления конфигурациями с командой разработчиков до того, как эти
планы вводятся в действие;
• поддерживает данный документ;
• отвечает за установку и сопровождение инструментов управления конфигурациями, опреде-
ленных в разделе 2.3.
• отвечает за настройку, сопровождение и резервное копирование используемых инструментов
управления конфигурациями, а также разрабатывает план действий на случай, если исполь-
зуемые инструменты окажутся неподдерживаемыми (например, по вине поставщика).
57
Дополнительные обязанности ведущего конфигурацию описаны в разделах 3.3, 3.4, 3.5 и 3.6.
2.2.2. Лидер проекта
Лидер проекта и руководитель проекта могут выполнять функции ведущего конфигурацию
только в исключительных обстоятельствах. Они обязаны знать все соответствующие средства досту-
па к документам во время проведения проекта. Лидер проекта обязан проверить, что архивирование
данных ведется в соответствии с инструкций, упомянутой в разделе 2.3.
Дополнительные обязанности лидера проекта описаны в разделах 3.3 и 3.4.
2.2.3. Разработчики
Каждый разработчик обязан выполнять правила управления конфигурациями, опубликован-
ные ведущим конфигурацию. Разработчики также обязаны следовать документу 56789 «Должност-
ные обязанности инженеров». Дополнительные обязанности разработчика описаны в разделе 3.
2.3. Применяемые политики, директивы и процедуры
[Такая деятельность, как управление конфигурациями, обычно осуществляется в соответствии с
общей политикой организации. Студенты должны идентифицировать и перечислить в этом разде-
ле соответствующие правила и инструкции. В частности, необходимо упомянуть систему управле-
ния конфигурациями (название SuperCMTool дано для примера), выбор которой был сделан на стра-
ницах пояснительной записки.]
1. Управление конфигурациями для данного проекта должно осуществляться в соответствии с указа-
ниями по управлению конфигурациями, изложенными в корпоративном документе 7890 версии 6 от
15.08.2008.
2. В соответствии с политикой улучшения процесса разработки требуется проводить обзорные сове-
щания по ходу и в конце проекта. Результаты самооценки должны быть отправлены управляющему,
ответственному за улучшение процесса, не позднее трех недель после того, как состоялось совеща-
ние. Все разделы, в которых указаны возможные улучшения, должны содержать соответствующий
материал и конкретные примеры.
3. Все текущие и предшествующие версии CI должны сохраняться.
4. К главному файлу (определен в разделе 3.1.2) имеет доступ только ведущий конфигурацию, а в его
отсутствие — начальник отдела.
5. Пароли управления конфигурациями должны меняться в соответствии с принятыми корпоратив-
ными правилами безопасности со следующим добавлением: никакой пароль не должен изменяться,
пока лидер проекта, руководитель проекта и ответственный за качество не оповещены об изменении
и не подтвердили получение оповещения.
6. Лидер проекта и начальник отдела должны всегда иметь полный доступ ко всем документам, кото-
рые затрагивает управление конфигурациями. Каждые две недели лидер проекта должен предостав-
лять форму http://localhost/division3.accessVerification своему начальнику для верификации прав дос-
тупа.
7. В настоящем проекте будет использоваться средство SuperCMTool версии 3.4, поставляемое ком-
панией SuperCMTool.
8. Архивация должна производиться в соответствии с корпоративной инструкцией №12345
3. Виды деятельности
3.1. Определение конфигурации
[В этом разделе определяется, как создаются элементы конфигурации (CI) и как им назначаются
имена.]
3.1.1. Определение элементов конфигурации
Лидер проекта несет ответственность за определение всех элементов конфигурации. Разра-
ботчики, желающие определить новый CI, должны получить согласие лидера проекта по электронной
почте или иным способом. Если лидер проекта недоступен в течение более чем одного рабочего дня,
ведущий конфигурацию имеет право включить в конфигурацию предлагаемый элемент.
3.1.2. Именование элементов конфигурации
Ведущий конфигурацию несет ответственность за маркировку всех CI. Соглашение об именах сле-
дующее.
Корневой каталог: IRS (Informational Reference System).
Вложенные каталоги: SRS или SDD или...
Файл с именем N_N_N.xxx соответствует версии N.N.N документа.
Например, версия SRS 2.4.8 имеет имя IRS/SRS/2_4_8.txt.
Главный файл с именем Master находится в корневом каталоге и содержит информацию о текущем
состоянии и предыдущих состояниях проекта. Например, файл Master может включать такую инфор-
58
мацию: текущая версия проекта 3.7.1. - включает версию 2.4.8 SRS и версию 1.4 SDD; предыдущая
версия проекта 3.6.11. - включает версию 2.4.8 SRS и версию 1.3 SDD.
3.1.3. Получение элементов конфигурации
[Составляя данный раздел, примите во внимание наиболее стрессовую часть проекта, то есть фазу
реализации, когда несколько человек будут работать параллельно.]
Для модификации CI разработчик должен получить CI с помощью процедуры checkout инст-
румента SuperCMTool. Эта информация запоминается и предоставляется другим пользователям, же-
лающим взять данный CI на модификацию. Любой желающий получить данный CI должен догово-
риться с текущим владельцем CI о передаче средствами SuperCMTool. Ни при каких обстоятельствах
разработчики не должны передавать друг другу CI прямо, в обход SuperCMTool. Для любого разра-
ботчика любой CI должен быть доступен на чтение в любое время.
3.2. Контроль конфигурации
[Данный раздел устанавливает процесс внесения изменений в элементы конфигурации.]
3.2.1. Запрос на изменения
Назначается инспектор для каждого участника команды. Прежде чем сделать запрос на изме-
нение, разработчик обязан получить одобрение данного предложения по изменению от инспекти-
рующей команды или, если последнее невозможно, от своего инспектора. Чтобы сделать запрос на
изменение, необходимо предоставить форму http://localhost/ultracorp.division3.Encounter.submitCI ве-
дущему конфигурацию и лидеру проекта вместе с исходным CI и измененным CI.
3.2.2. Оценка изменений
Лидер проекта или его заместитель оценивают все запросы на изменения. Лидер проекта дол-
жен также указать стандарты качества, которые необходимо учесть при внесении изменения.
3.2.3. Одобрение или отклонение изменений
Запрос на изменение должен быть одобрен лидером проекта. Если лидер проекта не имеет
возможности это сделать в течение трех рабочих дней, то право одобрения запроса на изменение пе-
реходит к ведущему конфигурацию.
3.2.4. Реализация изменений
Как только CI включается в конфигурацию, на ведущего конфигурацию возлагается ответст-
венность за тестирование и интеграцию изменений. Это должно выполняться в соответствии с прави-
лами регрессионного тестирования, описанного в документации по тестированию программного
обеспечения (STD). В частности, ведущий конфигурацию должен координировать сборку версии для
тестирования.
Выпуск версий должен утверждаться лидером проекта или руководителем проекта, если ли-
дер отсутствует.
3.3. Определение статуса конфигурации
Ведущий конфигурацию обязан обновлять информацию о конфигурации на странице
http://localhost/uLtracorp.division3/Encounter/Configuration не реже раза в неделю. Для этого достаточ-
но опубликовать итоговый отчет инструмента SuperCMTool.
3.4. Аудиты и обзоры конфигурации
Руководитель проекта должен запланировать выполнение обзоров конфигурации ведущим
конфигурацию не реже, чем раз в две недели, обычно в качестве одного из пунктов повестки дня
еженедельных собраний команды. Ведущий конфигурацию должен сделать обзор состояния конфи-
гурации и предложить детальные процедуры управления конфигурациями на фазах кодирования и
интеграции.
3.5. Управление интерфейсом
Система управления конфигурациями должна иметь интерфейс с веб-сайтом проекта. Этим
интерфейсом управляет ведущий конфигурацию.
3.6. Контроль поставщиков и субподрядчиков
Ведущий конфигурацию должен отслеживать обновления и сообщения об ошибках в инстру-
менте SuperCMTool. У него должен быть план действий на случай, если поддержка SuperCMTool бу-
дет прекращена. Этот план должен быть представлен лидеру проекта в течение месяца после начала
проекта.
4. Расписание
[План мероприятий по управлению конфигурациями можно определить в данном разделе или в об-
щем плане в SPMP. В последнем случае данный раздел должен не дублировать SPMP, а содержать
только ссылку.]
5. Ресурсы
59
Ведущему конфигурацию для выполнения своих обязанностей требуется в среднем приблизи-
тельно 6 часов в неделю в первой половине проекта и 12 часов в неделю во второй половине проекта.
Время, затрачиваемое другими разработчиками на управление конфигурациями, принято отдельно не
учитывать.
6. Сопровождение
Ввиду важности наличия стабильного плана управления конфигурациями изменения в данном
документе должны быть одобрены всей командой проекта.
Поскольку целью организации является достижение уровня 5 по СММ, ведущий конфигура-
цию при подготовке совещаний по улучшению процесса управления конфигурациями обязан сделать
следующее:
• Оценить эффективность данного плана.
• Количественно оценить потери, вызванные дефектами данного плана.
• Оценить эффективность использования инструмента SuperCMTool.
• Изучить литературу по новым методам управления конфигурациями; количественно оценить
выгоды и затраты на проведение улучшений.
• Изучить новые инструменты управления конфигурациями.
• Предложить конкретные улучшения текущего процесса управления конфигурациями.
• Перечислить выгоды от улучшений.
• Предоставить оценки стоимости эффекта введения улучшений.
Упорядочить предлагаемые улучшения по значению отношения выгоды-затраты.
60
ПРИЛОЖЕНИЕ Ж
(справочное)
IEEE 730-1989 ПЛАН КОНТРОЛЯ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
(SOFTWARE QUALITY ASSURANCE PLAN – SQAP)
Утверждаю
Дата
17.01.09 А. Мелихов: Создание первой версии.
30.05.09 А. Мелихов: Рецензирование и добавление разделов от 7 до конца.
31.05.09 А. Мелихов: Интеграция и пересмотр содержания.
1. Цель
В этом документе описан план получения качественного продукта при выполнении проекти-
рования информационно-справочной системы (ИСС).
2. Задействованные документы
См. раздел 4.2.
3. Управление
3.1. Организация
[Этот раздел устанавливает, какие роли задействованы в процессе обеспечения качества. Факти-
ческое распределение обязанностей дано в разделе 3.3.]
Каждый участник команды отвечает за качество своей работы. Кроме того, на первые три
итерации проекта назначается отдельный ответственный за качество. Ответственный за качество ру-
ководит всеми вопросами, связанными с обеспечением качества в проекте. Начиная с итерации 4
должна быть назначена команда инженеров по контролю качества, в которую должен войти ответст-
венный за качество.
3.2. Задачи
Задачи по контролю качества в данном проекте включают в себя:
• документирование;
• обзорные собрания;
• верификацию (включая инспектирование);
• валидацию (прежде всего тестирование);
• виды деятельности, направленные на улучшение самого процесса обеспечения качества.
Эти задачи детализированы в данном документе.
3.3. Ответственность
[Здесь не упоминаются имена сотрудников, поскольку они должны быть указаны в SPMP.]
Ответственный за качество следит за тем, чтобы требования данного документа были выпол-
нены, в том числе, чтобы были организованы обзорные собрания.
Лидер проекта отвечает за то, чтобы управление качеством действительно производилось.
Обязанности ответственного за требования и ответственного за проектирование описаны в
разделе 6 данного документа.
4. Документация
4.1. Цель
В данном разделе определяется документация, используемая для обеспечения качества.
4.2. Минимальные требования к документации
[В этом разделе перечисляются все документы проекта, поскольку именно проектная документация
обеспечивает качество продукта.]
Должны быть созданы следующие документы.
• SQAP – План контроля качества (данный документ).
• SCMP – План управления конфигурациями.
• SPMP – План управления программным проектом.
• SRS – Спецификация требований к программному обеспечению.
• SDD – проектная документация программного обеспечения.
• STD – документация по тестированию программного обеспечения