- •Содержание
- •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.Указатель
Задания для самопроверки
Сформулируйте название и аннотацию какого-либо хорошо известного Вам программного проекта и создайте одностраничный экран для него.
Сформулируйте основные характеристики и критерии успешности для этого проекта.
Используя матрицу выбора ЖЦ, примите решение, какой ЖЦ или комбинация ЖЦ наиболее подходит для Вашего проекта, и обоснуйте Ваш выбор.
Определите набор метрик, которые должны собираться в Вашем проекте и дайте его обоснование.
2.Типовой каркас для разработки по
В разработке программного продукта можно выделить некоторый «общепроектный» набор деятельностей, которые в той или иной мере встречаются в каждом проекте и характеризуют саму технологию программирования как инженерную дисциплину и образуют каркас данного производственного технологического процесса.
Рис. 13. Пример каркаса для процесса разработки ПО
Классический каркас по разработке программного обеспечения представлен на Рис. 13. Он является определенной структуризацией рассмотренной ранее обобщенной схемы процесса разработки (Рис. 6) и состоит из вложенных друг в друга групп взаимосвязанных деятельностей, каждая из которых в той или иной степени необходима для успешного создания программного продукта.
Программная разработка
Самой внутренней частью этой «матрешки» является собственно программная разработка (Software Development), состоящая из трех взаимосвязанных крупных групп деятельностей: Определять (Define), Разрабатывать (Develop), Сопровождать (Maintain).
Деятельности в группе «Определять» отвечают на вопрос «Что?» и состоят в основном в планировании проекта и сборе и анализе требований к нему. Результатом этих деятельностей является задокументированное четкое понимание исполнителем и заказчиком того, что именно предстоит создать в качестве результата данного программного проекта. Это понимание фиксируется в документах «Положение о работе», «Техническое задание», «План разработки» и «Спецификация требований», обязательно утверждаемых заказчиком.
Деятельности в группе «Разрабатывать» отвечают на вопрос «Как?» и включают в себя проектирование, кодирование, тестирование, документирование и выпуск продукта (сдачу его заказчику). Программный продукт создается в соответствии с полученными ранее ответами на вопрос «Что?» и принятыми решениями «Как?». Рабочими продуктами, создаваемыми в этой группе, помимо собственно программного продукта, являются его внутренняя и пользовательская документация в виде документов «Высокоуровневый проект», «Тестовые примеры и процедуры тестирования», «Руководство пользователя», «Руководство по установке» и других.
Наконец, деятельности в группе «Сопровождать» отвечают на вопрос: «Какие изменения?» и включают в себя действия по внесению изменений в уже работающий продукт и в конце его жизненного цикла вывод этого продукта из эксплуатации.
Обычно разработка «Положения о работе» (Statement of Work – SOW) или «Технического задания» (ТЗ) ведется до начала собственно разработки силами лиц, заинтересованных в запуске проекта, которыми могут быть как представители заказчика, так и будущие ключевые исполнители проекта. Контракт (договор) на исполнение разработки заключается уже после того, как готово SOW или ТЗ, которое включается в него как приложение. Типичная структура этих документов приведена в Приложении 1.51. Главное отличие SOW от ТЗ в том, что SOW описывает работу на более высоком уровне абстракции, чем ТЗ, и поэтому оно более компактно и менее трудоемко в своей разработке.
Важным шагом в определении работы является выявление структуры разбиения работ (Work Breakdown Structure – WBS), которая дает логическое разделение работ, исходя их структуры программного будущего продукта. Типичный верхний уровень WBS для разработки полной системы, состоящей из N подсистем, приведен на Рис. 14.
Рис. 14. Типичный верхний уровень структуры разбиения работ
Каждый компонент может быть разбит далее на следующие уровни, для более частных работ, которые должны быть выполнены для получения данного компонента. Например, разработка рабочего плана может включать в себя разработку ряда подпланов: по исполнению работ, по персоналу, по управлению качеством, по оборудованию и материалам, по утверждениям и согласованиям работ, по управлению себестоимостью, по управлению временным графиком, по отчетности, по рискам, в каждом из которых прорабатываются соответствующие аспекты общего плана.
Обычно структура разбиения работ появляется уже в положении о работе и в дальнейшем только уточняется, при этом желательно, чтобы, по крайней мере, хотя бы самый верхний уровень этой иерархии не менялся, обеспечивая устойчивость разработки.