- •Содержание
- •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.Указатель
Модели жизненного цикла
Профессиональная разработка программного продукта ведется по какой-либо определенной модели ее жизненного цикла. Выбор модели определяется характеристиками, как самого продукта, так и программного проекта для его разработки, включая специфику и опыт (экспертизу) команды разработчиков.
Рис. 6. Обобщенная схема повторяемого процесса разработки
Общая схема модель жизненного цикла представлена на Рис. 6. Модель структурирует процесс разработки, выделяя в нем отдельные фазы (phases) или этапы (milestones), исполнение которых может совмещаться во времени и состоять из нескольких более мелких этапов. На каждом этапе исполняются определенные для этапа деятельности (activities), результатом которых являются рабочие продукты (work products) в виде некоторых документов (documents), создаваемых в ходе их исполнения. Примером таких документов являются исходный код, отчет о тестировании, отчет об исправлении дефектов. Рабочие продукты, поставляемые заказчику в ходе проекта, называются поставками (deliverables), и для них определяются сроки, формы и способы поставок (в электронном виде, на магнитном или ином носителе или еще как-нибудь), причем датой поставки считается не дата отправки исполнителем данного рабочего продукта заказчику, а подтвержденная дата получения этой поставки заказчиком.
Таким образом, модель жизненного цикла обеспечивает каркас для определения повторяемого процесса, в явном виде задающего деятельности по созданию высококачественного ПО. Она дает разработчику возможность включать лучшие практики из опыта других и делиться своими лучшими практиками с другими, причем понятие модели ЖЦ применимо к программным проектам любого размера, как большим, так и малым.
Типичными деятельностями в этой обобщенной схеме являются:
на фазе анализа –
планирование проекта (project planning)
сбор и анализ требований (requirements gathering and analysis);
на фазе проектирования –
предварительное или высокоуровневое проектирование (preliminary / high-level design)
подробное или низкоуровневое проектирование (detailed / low-level design);
на фазе реализации –
кодирование модульное тестирование (coding and unit testing);
на фазе обозрения –
интеграционное тестирование (integration testing);
системное тестирование (system testing).
Для малых проектов данная схема сводится к следующим основным фазам:
Спланировать (plan) – определить функциональные требования, привязав их к ПО и к аппаратуре, и по ним создать план разработки, включающий перечень поставляемых рабочих продуктов, оценку ресурсов и определение процессов поддержки;
Специфицировать (specify) – точно определить внешние характеристики будущей программы с точки зрения пользователя (например, через прототипирование и предъявление пользователям); провести обзор спецификаций как минимум с участием инженера-проектировщика, основных пользователей и заказчика;
Разработать (develop) – выполнить детальный проект с точки зрения его реализации; провести обзор детального проекта с участием разработчиков и тестировщиков; выполнить кодирование этого проекта; провести обзор кода с участием тех же лиц, что и в обзоре проекта; скомпилировать программу, выявив синтаксические ошибки, не вскрытые на обзоре кода; протестировать программу, выявив логические ошибки, не вскрытые обзором кода;
После завершения (post-mortem) – проанализировать проделанную работу, проверив, что все плановые поставки завершены; сравнить результаты работ с требованиями пользователя по качеству; сравнить фактические результаты с первоначальными оценками, объяснив все расхождения.
Наличие проговоренной и понятной модели ЖЦ и следование ей в процессе разработки имеет следующие положительные следствия для хода проекта:
Модель способствует определению требований до проектирования системы – надо определить, что система должна делать ДО ее создания;
Модель способствует проектированию программного обеспечения ДО построения его компонентов – надо спланировать, как именно компоненты будут взаимодействовать между собой и по каким интерфейсам ДО их создания;
Модель определяет, какие именно рабочие продукты должен поставить данный процесс разработки – надо сгенерировать стандартный набор поставок, которые должны быть тестируемы и смогут помочь в дальнейшем сопровождении данного программного продукта;
Модель дает возможность руководству проектом тщательно отслеживать его продвижение – руководство должно располагать базовыми стандартами для измерения качества продукта и производительности, как самого процесса разработки, так и разработчиков;
Модель снижает затраты на разработку и сопровождение – все предыдущее этому способствует;
Модель дает возможность организации-разработчику быть более структурированной и управляемой.
Благодаря следованию какой-либо известной модели ЖЦ, организация-разработчик получает следующие преимущества:
Улучшается качество продукта через согласованность в его разработке – продукт определяется как состоящий из всех поставляемых рабочих продуктов его жизненного цикла;
Облегчается управление проектами – сравнение с известными стандартами выявляет проблемы, требующие решения;
Облегчается отслеживание состояния проекта – определение деятельностей и заданий в процессе является средством знать, что именно было сделано, за какое время и какими ресурсами;
Накапливается база фактических данных для последующих улучшений и измерений – успех проекта измеряется сравнением завершенных компонентов со стандартами и фактической производительности с ожидаемой по оценкам; производительность ниже базовой указывает на необходимость улучшений в процессе, а качество продукта ниже базового указывает на необходимость исправлений в продукте;
По мере исправления организационных слабостей растет уровень зрелости организации-разработчика – когда недостатки процесса исправляются, организация переходит на более высокий уровень зрелости, как это определяется моделями зрелости CMM/CMMI.
Далее будут рассмотрены 6 моделей жизненного цикла, отличающихся своими фазами, вариантами деятельностей и создаваемыми рабочими документами. Все они, однако, в той или иной степени укладываются в приведенную обобщенную схему.