- •Содержание
- •1.13. Задания для самопроверки 59
- •1.17. Задания для самопроверки 88
- •1.19. Задания для самопроверки 108
- •1.23. Задания для самопроверки 116
- •1.27. Задания для самопроверки 125
- •1.37. Задания для самопроверки 144
- •1.48. Задания для самопроверки 159
- •Перечень рисунков
- •Перечень таблиц
- •Введение
- •Принятые сокращения
- •1.Жизненный цикл разработки по
- •Программные проект и его атрибуты
- •Ролевые модели в программном проекте
- •Размер и сложность программного проекта
- •Характеристики программного проекта
- •Качество программного продукта
- •Экран проекта и сводка о подходе
- •Критерий smart для формулирования целей
- •Критерии успешности программного проекта
- •Модели жизненного цикла
- •Водопадная модель
- •Модель быстрой разработки приложения
- •Пошаговая модель
- •Спиральная модель Боэма
- •Прототипная модель
- •Выбор модели жизненного цикла
- •Задания для самопроверки
- •2.Типовой каркас для разработки по
- •Программная разработка
- •Планирование проекта
- •Модель cocomo для оценки трудозатрат в проекте
- •Модель slim для оценки трудозатрат в проекте
- •Разработка спецификации требований
- •Отслеживание и контроль
- •Верификация и валидация
- •Обеспечение качества
- •Конфигурационное управление
- •Метрики
- •Повышение квалификации
- •Задания для самопроверки
- •3. Модели зрелости способностей cmm/cmmi
- •Ключевые области процесса в модели cmm
- •Характеристика уровней зрелости в модели cmm
- •Интегрированная модель зрелости способностей cmmi
- •История возникновения
- •Уровни зрелости и области процесса
- •Уровни способностей процесса в модели cmmi
- •Специальные и общие цели и практики процессных областей
- •Характеристики уровней зрелости в модели cmmi
- •Задания для самопроверки
- •4.Управление рисками в программном проекте
- •Модели esi и pmi управления рисками
- •Выявление рисков
- •Анализ рисков
- •Расстановка приоритетов для рисков
- •Планирование рисков
- •Исполнение ответных стратегий
- •Оценивание результатов исполнение ответных стратегий
- •Документирование действий по рискам
- •Заключительное оценивание рисков
- •Задания для самопроверки
- •5.Стандарты качества iso в применении к по
- •Структура и принципы семейства стандартов iso 9000
- •Модели iso 9000 на базе процессов
- •Самооценивание по ключевым элементам iso 9000
- •Задания для самопроверки
- •6.Формальные методы в разработке по
- •Инструменты формализации и верификации
- •Взаимодействие функциональностей
- •Интегрированная технология анализа и верификации
- •Задания для самопроверки
- •7.Некоторые общие технологические приемы
- •Инспекции по Фейгану
- •Диаграммы Исикавы («рыбий скелет»)
- •Инструменты
- •Swot-анализ
- •Сбалансированный экран результативности
- •Технологическая дорожная карта
- •Метод Дельфи
- •Деревья решений
- •Сравнительное ранжирование
- •Методология подвижного программирования
- •Принципы подвижного программирования
- •Рабочий цикл и роли участников
- •Рабочие документы и обстановка
- •Задания для самопроверки
- •8.Сертификация программного обеспечения в авиации
- •История создания серии документов do-178 и ed-12
- •Уровни программного обеспечения
- •Процессы жизненного цикла по авиационных систем
- •Цели процессных деятельностей
- •Рабочие документы и категории их контроля
- •Процесс планирования по
- •Процессы разработки по
- •Определение требований
- •Проектирование
- •Кодирование
- •Верификация
- •Конфигурационное управление
- •Обеспечение качества
- •Контакт с органом сертификации
- •Выводы и рекомендации
- •Задания для самопроверки
- •9.Задания для самостоятельной работы
- •Темы, связанные с единым каркасом для разработки по
- •Перечень тем
- •Краткое описание каждой темы
- •Тема 2. Программная архитектура базового инструмента для распределенного управления программными проектами
- •Тема 3. Профили типовых рабочих компонентов для разработки приложений
- •Тема 1. Прототип метрической базы данных для управления разработкой приложений
- •Тема 5. Репозиторий повторно используемых компонентов
- •Тема 6. Сквозной пример для единого каркаса разработки приложений
- •Темы, связанные применением формальных методов перечень тем
- •Тема 1. Сравнительный анализ систем верификации
- •Тема 2. Формализация протоколов связи краткое описание каждой темы
- •Тема 1. Сравнительный анализ систем верификации
- •Тема 2. Формализация протоколов связи
- •10.Литература
- •11.Приложения
- •Шаблон для одностраничного экрана проекта
- •Примерная структура положения о работе и тз
- •Примерная форма еженедельного отчета
- •Примерная форма презентации на ежемесячном операционном обзоре
- •12.Указатель
Конфигурационное управление
Конфигурационное управление или управление конфигурацией (Configuration Management) призвано обеспечивать целостность программного продукта и его воспроизводимость на протяжении всего его жизненного цикла вплоть до вывода из эксплуатации.
Конфигурационное управление, как правило, состоит в установлении правил именования составляющих компонентов программного проекта с поддержанием их версионного контроля (version control), и в обеспечении их быстрого восстановления в случае утраты путем регулярного резервного копирования. В проекте определяется перечень его рабочих продуктов и компонентов, подпадающих под управление конфигурацией, который включает не только программные модули создаваемого продукта, но и все инструментальные средства и платформы, на которых эти компоненты создаются, а также все тесты и тестовые процедуры для их верификации и валидации.
Рис. 19. Укрупненная структура системы конфигурационного управления
Для каждого компонента, подпадающего под управление конфигурацией, создается его базовая версия (baseline), которая по мере развития проекта может заменяться какой либо очередной версией этого компонента. При этом поддерживается согласованность в замене базовых версий взаимосвязанных компонентов.
Укрупненная структура системы конфигурационного управления показана на Рис. 19. Она состоит из двух взаимно согласованных составляющих. Первая из них представляет собой комплекс процедур и соглашений по правилам создания базовых версий, именования файлов, именования версий и сборок версий. Эти процедуры и соглашения касаются также структуры каталогов, идентификации компонентов и элементов конфигурации, идентификационному контролю. Кроме того, они регламентируют порядок рассмотрения запросов на изменения и контроль над изменениями компонентов программного продукта и продукта в целом, ведение архива резервных копий (периодического копирования всех данных по проекту и их регулярного сохранения в архиве), защиту от повреждений и несанкционированного доступа и т.п.
Второй составляющей системы конфигурационного управления является какое-либо инструментальное средство автоматизации управления версионным контролем и базой данных компонентов программного продукта, например CVS (Control Version System) или ClearCase.
Одной из важных составляющих системы конфигурационного управления является совет по управлению конфигурацией (Configuration Management Board), который обычно состоит из представителя администрации и по одному представителю всех проектов. В обязанности совета входит оценивание подготовленных предложений по изменению конфигурации и принятие решения об их утверждении или отклонении. Совет также определяет и утверждает базовые версии программного продукта для каждого проекта. В обоих случаях по результатам заседания составляется отчет о состоянии конфигурации продукта на дату заседания совета.
При проведении анализа целесообразности изменений совет прежде всего исходит из соотношения стоимости получаемых выгод и стоимости понесенных затрат на изменение. Трудно представить себе ситуацию, когда можно принять решение о целесообразности внесения изменений при получении меньших выгод, чем понесенные затраты на их получение.
Регулярной деятельностью в рамках системы конфигурационного управления является проведение аудитов, при которых проверяется состояние компонентов и соблюдение всех требований системы управления конфигурацией в каждой проектной группе. Аудиты проводятся представителем группы процесса, причем в группе процесса все аудиты обязательно планируются, а планы группы процесса согласовываться с проектными планами каждой проектной группы и после согласования планов аудиты включаются в планы проектных групп.
Конфигурационное управление, приспособленное к конкретным условиям проекта, дает положительные результаты, не будучи ни избыточным, ни чересчур узким. Именно благодаря хорошо поставленному конфигурационному управлению в проекте не раз удается восстанавливать казалось бы потерянные навсегда материалы и продукты.
Важным аспектом конфигурационного управления является сопровождение только одной официальной копии базовой версии каждого документа, поскольку невозможно поддерживать полную тождественность никаких двух отдельных экземпляров одного и того же документа. Каждое предложение по изменениям должно пройти утверждение до своей реализации, причем все предложения и все разрешенные и отклоненные изменения обязательно регистрируются в БД конфигурационного управления проектом.