- •Содержание
- •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.Указатель
Пошаговая модель
Пошаговая (Incremental) модель (Рис. 10) напоминает V-образную, но построена на идее так называемого эволюционного прототипа (evolutionary prototype) и состоит из последовательности шагов от 1 до N. На шаге 1 готовится некоторый зародыш будущего продукта, в котором реализуется очень ограниченное количество функций. В последующих шагах от 2 до N этот прототип наращивается до полного объема спецификаций, какой был задан изначально.
Каждый шаг исполняется по V-образной модели, но с учетом уже имеющихся наработок на предыдущем шаге. В отличие от обобщенной модели, здесь на первой же фазе каждого шага идет разработка "тестов приемки", которые либо разрабатываются, либо берутся уже готовыми от заказчика. Таким образом, в отличие от V-образной модели, в которой приемочное тестирование выполняется на завершении разработки, здесь вопрос: "На чем будут тестироваться последовательные версии продукта и что будет критерием их приемки заказчиком?" изучается и решается первым делом. Изначально эти тесты применяются к продуктам поставщиков и возможных конкурентов, а в конце каждого шага – к очередной версии разрабатываемого продукта, который в этой модели называется демонстрационным прототипом (demo).
После определения и подготовки тестов идет «спуск» по фазам анализа требований, предварительного проектирования (аналог высокоуровневого), детального проектирования и кодирования, а затем «подъем» по фазам модульного тестирования, интеграционного тестирования, и системного, как и в V-образной модели. Завершается шаг приемо-сдаточными испытаниями с учетом тестов, накопленных на предыдущих шагах, и тестов для функциональности, добавленной на данном шаге.
Входным материалом для фазы кодирования является не только детальный проект данного шага, но и результаты работы на предыдущем шаге. При кодировании постоянно наращиваем имеющуюся систему и заканчиваем демонстрационной версией с полным набором требований. Таким образом в данной модели заказчик уже в начале проекта имеет нечто уже работающее и на основании этого работающего варианта может уточнять свои требования к последующим демонстрационным прототипам.
Рис. 10. Пошаговая модель
Известная достаточно давно, пошаговая модель послужила основой для создания технологии SCRUM, получившей широкое распространение в начала 2000-х годов. Она характеризуется частичной реализацией полной системы с пошаговым добавлением функциональности и производительности. Соответственно снижаются затраты на достижение начальной работоспособности программного продукта, правда с ограниченной функциональностью. Работающая система получается быстрее с использованием готовых блоков, что помогает справиться с изменениями требований в процессе разработки.
Спиральная модель Боэма
Спиральная (spiral) модель была предложена Боэмом еще в середине 1980-х годов. Ее главная особенность – выделение анализа рисков в отдельные шаги разработки, которая представляет собой повторяющиеся циклы, раскручиваемые, подобно спирали (Рис. 11). Каждый виток начинается с анализа рисков и построения очередного прототипа системы, эти риски проясняющего. После устранения с помощью рассмотрения этих прототипов всех неясностей, выявленных в анализе рисков, разрабатывается концепция, составляются планы по требованиям к системе и планы по жизненному циклу. На следующем витке спирали в свете полученных новых данных заново проводится анализ рисков в изменившейся ситуации и на основании него, если заказчик соглашается, создается следующий прототип.
После нескольких повторений на основании на основании накопленных данных строится уже проект программного продукта и по нему после очередного анализа рисков создается действующий рабочий прототип, который затем превратится в программный продукт, создаваемый по настоящим фазам проекта. Эти заключительные фазы разработки проходят уже относительно быстро, так как уже сделано много предварительной работы.
В спиральной модели суммарная стоимость разработки очевидным образом растет по мере повторения витков спирали, поэтому она достаточно большая. Но за счет постоянного анализа рисков перед очередным витком спирали заказчик может выявлять ключевые риски в программной разработке и принимать обоснованное решение о ее продолжении или завершении с текущим вариантом рабочего прототипа в качестве результата. Поэтому эта спиральная модель достаточно известна, реально применяется и может рассматриваться как один из «предков» технологии SCRUM.
Рис. 11. Спиральная модель Боэма
В индустрии программного обеспечения спиральная модель является одной из самых распространенных.