
- •Содержание
- •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.Указатель
Взаимодействие функциональностей
Важной и трудной проблемой в обеспечении правильного функционирования программной системы является так называемое взаимодействие функций (feature interaction), когда несколько правильно работающих функций системы перестают работать правильно при их интеграции в единый продукт. Эта проблема часто возникает при развитии программного продукта, функциональность которого наращивается поэтапно. Поиски причин нарушения целостности такой системы при добавлении новой функциональности (корректно реализованной и работающей правильно в изоляции) могут привести к серьезным переделкам кода и оказаться чреватыми к внесению в него новых ошибок. Возможной мерой предотвращения таких «сюрпризов» может быть исследование поведения системы на ее формальной модели.
Рассмотрим простую систему телефонной связи (Plain Old Telephone System – POTS), в которой реализованы три независимые функциональности: переадресация звонка (Forward), трехсторонняя связь (3WayCall) и ожидание (CallWaiting) – Рис. 42.
Рис. 42. Простая телефонная система с дополнительными функциями
Телефоны взаимодействуют между собой через установленные каналы связи телефонной сети и могут быть в состоянии «свободен» или «занят». В системе реализована переадресация звонка (Forward) и добавляются 2 независимые функции 3WayPhone и CallWaiting, которые, как выясняется, могут взаимно влиять друг на друга. Очевидная формализация отдельных шагов этих функций приведена на Рис. 43.
Телефоны m, n, и k все на связи; Телефон k кладет трубку и переходит в состояние idle; Телефоны m и n получают dialtone. req 3WAY teardown 2: Forall(m,n,k) ( rel(m,n,3wayconnected k) -> after(onhook k)( state(k,idle) & state(m,(idle;offhook m)) & state(n,(idle;offhook n)) & 3WAY k ) ); |
|
Трехсторонняя связь – 3WayPhone |
|
Телефон n ожидает соединения с k; Телефоны k и m соединены; Телефон m отсоединяется и переходит в состояние idle; k получает сигнал “busy” от m; Телефоны n и k становятся соединенными. req CW teardown 1: Forall(m,n,k) ( rel(k,n,cw hold connect m) -> after(onhook m) (state(m,idle) & rel(k,n,(cw hold connect m;onhook m)) ) );
req CW teardown 11: Forall(m,n,k) ( rel(k,n,(cw hold connect m;onhook m)) -> after(busy k.flash k) (rel(k,n,connected) & CW(k)) ) |
|
Ожидание – CallWaiting |
Рис. 43. Формализация отдельных шагов 3WayPhone и CallWaiting
Пусть теперь имеется 4 телефона С1, С2, С3 и Р1, причем Р1 с функцией трехсторонней связи. Рассмотрим, сценарий, представленный на Рис. 44.
1.
|
2.
|
3.
|
4.
|
Рис. 44. Пример незапланированного взаимодействия функциональностей
1. Пары телефонов (С1, С2) и (Р1, С3) соединены и ведут независимые разговоры.
2. Телефон Р1 переводит С3 в состояние ожидания трехсторонней связи и вызывает С2.
3. Телефон С2 переводит С1 в режим ожидания, после чего устанавливается трехсторонняя связь между телефонами Р1, С2 и С3.
4. Телефон Р1 кладет трубку и переходит в состояние «свободен». В какое состояние в этом случае переходит телефон С2? С одной стороны, по правилу 3WAY teardown 2 для трехсторонней связи оба телефона С2 и С3 должны получить сигнал dialtone; с другой стороны, по правилу CW teardown 1 телефон С2 должно получить сигнал «занято».
Исправить ситуацию; т.е., убрать возникшую неоднозначность, можно лишь при дальнейшем уточнении поведения телефонов, когда присутствуют эти новые функциональности.