- •Содержание
- •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.Указатель
Исполнение ответных стратегий
Исполнить – это немедленно реализовать те ответные стратегии на риски, которые снижают вероятность наступления рискового события, и реализовывать ответные стратегии при наступлении рисковых событий, в соответствии с выработанными планами. Входными данными для этого шага являются данные, поступающие с ходом проекта в соответствии с его планом, и ответные стратегии, выработанные на предыдущем шаге. Необходимые стратегии отрабатываются и по результатам их исполнения вносятся необходимые коррективы в план управления рисками, возможно, влияющие на дальнейший ход проекта. Результатом является возможно пересмотренный план действий от текущего момента до конца проекта.
Входными данными для этого шага служат проектный план и план управления рисками, проектные ресурсы, информация о рисковых событиях, стоимость, график и технические данные, связанные с проектом, инструментом – сами рисковые стратегии, которые отрабатываются как часть исполнения проекта. При возможности выбора очередности в исполнении первыми реализуются стратегии, нацеленные на снижение вероятности риска или его воздействия, или на уклонение от риска, затем отрабатываются и другие стратегии по мере актуализации рисковых событий. При этом надо обязательно информировать членов группы и других заинтересованных лиц о состоянии плана по рискам и документировать все рисковые события и предпринятые по ним ответные действия. В историческом разрезе очень полезно создать и регулярно обновлять файл «усвоенных уроков» (lessons learnt).
На управление рисками нужно время и адекватные ресурсы, которые должны быть заложены в проектном плане. Руководители программных проектов, как правило, всегда перегружены, поэтому для того, чтобы управление рисками работало действенно и экономно (effectively and efficiently), руководители проектов должны на регулярной основе:
оценивать состояние проекта и связанных с ним рисков;
отслеживать рисковые события;
в соответствии с планом управления рисками запускать ответные стратегии при наступлении таких событий;
проверять результаты исполнения ответных стратегий;
и осуществлять все это как часть общего процесса управления проектом. Важными вопросами, требующими постоянного внимания руководителя проекта, являются:
Определен ли способ отчетности по рискам?
Определены ли данные, подлежащие сбору для определения рисков?
Определено ли, как использовать эти данные?
Как эти данные должны собираться?
Кто отвечает за сбор этих данных?
Как часто должны эти данные собираться?
Какие требуются отчеты?
Кому требуются отчеты о состоянии проекта и рисков в нем?
До какого уровня WBS должны собираться эти данные?
Опыт преодоления рисковых ситуаций является ценным процессным активом, который стоит накапливать и стараться использовать в новых проектах.
Оценивание результатов исполнение ответных стратегий
Оценивать результаты – это наблюдать за отработкой ответных стратегий на риски чтобы понять, являются ли последствия стратегии теми, какие ожидались, и выявить возможности для уточнения плана управления рискам. Все это необходимо для переноса полезного опыта на другие проекты. Входными данными для этого шага служат проектный план и план управления рисками, данные по затратам и графику, технические проблемы в проекте и любые значимые данные по рисковому событию. Применяемые инструменты – различные методики, например, стандарты IEEE 982.1-1988 и другие. Для каждой рисковой стратегии необходимо определить критерии успеха и анализировать результаты ее исполнения в свете этих критериев. В процессе оценивания результатов исполнения могут измениться ранее сделанные оценки вероятности и воздействия этого и других рисков, а также появиться новые риски, что возвращает процесс к шагу 1. В свете полученных данных могут быть также пересмотрены сами ответные стратегии, что возвращает процесс к шагу 4. Все это вызывает необходимость пересмотра плана управления рисками, который необходимо утвердить и сообщить всем участникам разработки. Таким образом, выходными данными этого шага является пересмотренный план управления рисками.
Цель постоянного наблюдения за рисковыми событиями – предотвратить их наступление и предпринять действия быстрого реагирования, если рисковое событие все же наступит. Причинами, вызывающими необходимость такого постоянного наблюдения являются постоянные изменения в проекте, затрагивающие его кадры, среду, организацию, требования заказчика, технический прогресс и использование ресурсов.
Методики, ориентированные на продукт, используют метрики продукта, нацеленные на причинно-следственный анализ его надежности до исполнения в дополнение к надежности во время исполнения. Этими метриками являются:
Ошибки, дефекты и сбои: число дефектов, вызванных человеческим фактором, ошибками в программе, наблюдаемым неправильным функционированием.
Среднее время между сбоями и частота сбоев: производные метрики по дефектам и времени их наступления.
Рост и проекция надежности: оценка изменений в отсутствии сбоев при тестировании и эксплуатации.
Остаточные дефекты в продукте: оценка отсутствия сбоев при разработке, тестировании и сопровождении.
Полнота и согласованность: оценка присутствия и согласованности всех необходимых программных частей.
Сложность: оценка усложняющих факторов в системе.
Например, уже такая простая метрика для отслеживания: TM=R1/R2×100%, где R1 – число требований, которым архитектура удовлетворяет, а R2 – число исходных требований, позволяет выявить требования, либо пропущенные в исходных требованиях, либо дополнительные к ним.
Процессно-ориентированные методики используют процессные метрики, нацеленные на практики и процедуры управления для совершения работ по разработке продукта, такие как:
Контроль руководства: оценка управляемости процессов разработки и сопровождения.
Покрытие: оценка присутствия всех необходимых деятельностей для разработки и сопровождения программного продукта.
Оценивание рисков, выигрыша и затрат: оценивание процессных «за и против» по цене, графику и производительности.
Например, контроль руководства в распределении ошибок может учитывать специфику разрабатываемого приложения через поиск причин дефектов и сбоев в ПО, включая анализ данных по дефектам, собираемых на каждой фазе разработки, а сами эти данные могут включать связанные дефекты, их типы, серьезность, фазу внесения дефекта, меры предупреждения и механизм обнаружения.
К другим методикам относятся обзоры, структурные просмотры и инспекции.
Обзоры (reviews) помогают выяснить внутреннюю полноту и согласованность самого процесса по разработке продукта. Их цель – найти неточности, пропуски и избыточность в данных, они рассчитаны на широкий круг участников и проводятся в заранее определенное время жизненного цикла в соответствии с проектным планом.
Структурные просмотры (structured walkthroughs) – это обзоры «на лету», в процессе самой разработки. Их цель – дать отзыв разработчику по качеству продукта на данный момент. Участниками таких просмотров обычно являются разработчик, системный проектировщик, аналитик и инженеры, но не руководство, и они проводятся на протяжении всего жизненного цикла разработки по мере необходимости. Как показала практика, структурные просмотры весьма результативны для выявления и последующего устранения ошибок.
Инспекции (inspections) имеют целью найти ошибки в их источнике – как можно ранее в процессе разработки. Они более формальны и жестки, чем обзоры и просмотры и проводятся подготовленными техническими специалистами. Как правило, инспекции требуют больше времени и ресурсов, но находят больше ошибок, чем тестирование. Более подробно инспекции рассмотрены в разделе 1.28.
Стандарт IEEE Standard Dictionary of Measures to Produce Reliable Software (IEEE Std 982.1-1988) перечисляет 39 методик для наблюдения за рисками, из которых можно выбирать наиболее подходящие для каждого данного случая.
Известный подход Боэма «Первые 10» суммирует все вышесказанное в следующих действиях:
Выявить 10 самых серьезных рисков в проекте.
Разработать план по разрешению каждого риска.
Ежемесячно обновлять список этих рисков, планов и результатов.
На ежемесячных обзорах проекта сообщать о состоянии самых серьезных рисков – сравнивать их состояние и ранги с аналогичными данными за предыдущий месяц.
Запускать соответствующие поправочные действия при необходимости.