- •Содержание
- •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.Указатель
Верификация и валидация
Деятельности по собственно разработке, отслеживанию и контролю объемлются постоянно идущими деятельностями по верификации и валидации (Verification and Validation – V&V) как создаваемых в них рабочих продуктов, так и самих процессов и технологических приемов их создания.
Верификация – это проверка корректности реализации; т.е., соответствия выполненных деятельностей известным стандартам и процедурам. Отвечает на вопрос: “Правильно ли это сделано? – Did we do the thing right?”
Валидация – это проверка пригодности созданной реализации к предполагаемому использованию; т.е., того, что она действительно заключает в себе заявленную для заказчика ценность. Отвечает на вопрос: “Сделано ли действительно то, что нужно? – Did we do the right thing?”
Очевидно, что корректно построенный программный продукт (т.е., успешно прошедший верификацию), может оказаться непригодным к использованию и тем самым привести проект к неудаче. Типичными деятельностями по верификации и валидации являются регулярные внутренние аудиты (internal audits), отчеты по качеству (quality reports) создаваемых рабочих продуктов и оценивания (assessments) в форме самооценивания (self-assessment) или официального оценивания (formal assessment), проводимого уполномоченными на то организациями или лицами. Результаты всех деятельностей доводятся до сведения всех исполнителей и заказчика для выработки и принятия к исполнению при необходимости соответствующих поправочных действий.
Обеспечение качества
Обеспечение качества (Software Quality Assurance – SQA) представляет собой ряд деятельностей, обеспечивающих заданное качество будущего программного продукта. В своем самом простом виде оно состоит в регулярной проверке того, что разработчики выполняют свои обязанности в соответствии со стандартами и требованиями организации, данной проектной группы и заказчика. Обычно в проекте выделяется отдельная роль инженера по качеству (как правило, часть полной ставки) из специальной группы качества, которая обслуживает все проекты в данной организации и подчиняется непосредственно ее руководителю. Этот специалист совместно с разработчиками и руководством обеспечивает корректную реализацию процесса разработки и непрерывное улучшение всего производственного процесса в данной организации и росту качества выпускаемых программных продуктов.
В плане разработки предусматривается отдельный план по обеспечению качества, в котором прописываются соответствующие действия: разработки и уточнение стандартов, процедур и шаблонов для соответствующих рабочих продуктов проекта, обзоры, инспекции кода и документации, повышение квалификации, процедуры документирования и отслеживания разрешения разногласий и другие действия, запланированные для достижения поставленных целей по качеству. При этом должно быть предусмотрено и выделение адекватных этим задачам ресурсов. Этот план готовится, начиная с ранних этапов проекта и параллельно с разработкой общего проектного плана, и все относящиеся к проекту лица и группы должны ознакомиться с ним в обязательном порядке.
Планом обеспечения качества определяется документация, которую должна создавать группа качества, методика и частота предоставления сведений проектным и всем заинтересованным группам (так реализуется обратная связь). Процедуры, относящиеся к обеспечению качества, могут описываться в плане или представляться в виде ссылок на другие документы, в которых содержится их описание.
Группа качества через своего выделенного представителя принимает участие в подготовке и проверке соблюдения проектного плана, стандартов и процедур. Она проверяет стандарты и процедуры, используемые в проектах, на предмет соответствия принятым в организации стандартам, требованиям применимости стандартов к конкретному проекту. Проверяет наличие в проектных планах необходимых разделов, связанных с обеспечением качества, наличие в каждом проекте и доступность всем относящимся к проекту лицам планов, стандартов и процедур, установленных процессом. При необходимости инженер по качеству консультируется по спорным вопросам данного проекта с другими членами группы качества и ее руководителем.
Группа качества проверяет работы по проектированию программного продукта с точки зрения их соответствия проектному плану. Она сопоставляет деятельность по разработке с планом, процедурами и стандартами с целью обнаружения отклонений. Выявленные отклонения в обязательном порядке документируются, составляется план устранения выявленных недостатков. В последующем проверяется устранение выявленных недостатков, сопоставляются сроки их устранения с плановыми данными.
Группа качества также проверяет качество создаваемых рабочих продуктов и устанавливает их соответствие или несоответствие условиям контракта на разработку. Все рабочие продукты, предназначенные для поставки, обязательно проверяются до передачи заказчику на предмет их соответствия стандартам, процедурам и требованиям заказчика. Выявленные отклонения документируются, составляется план их устранения, который в дальнейшем проверяется.
Обнаруженные отклонения документируются и обрабатываются в соответствии с формальной процедурой. При обнаружении отклонений вопрос о возможности продолжения работ по разработке сначала обсуждается с соответствующими руководителями групп или руководителем проекта. Вопросы, которые разрешить с руководителями групп или руководителем проекта не удается, сообщаются старшему руководителю, ответственному за разрешение разногласий, и регулярно проверяются на предмет разрешения. Группа SQA регулярно обсуждает результаты своих проверок с персоналом аналогичного подразделения заказчика.
Обычно все метрики по программным проектам собираются и накапливаются в группе качества для их анализа и учета в планировании и проверке соответствующих деятельностей. Группа SQA ведет эту метрическую БД и регулярно дополняет ее данными из внешних источников.