Контрольные вопросы

1. Перечислите основные модели ЖЦ ПО. В чём суть непланируемой модели? Приведите графическое представление этой модели.

2. В чём суть классической каскадной модели? В чём суть модифицированной каскадной модели?

3. В чём суть прототипируемой модели? Объясните название этой модели.

4. В чём суть классической модели прототипирования?

5. В чём суть итеративной инкрементной модели?

6. В чём суть эволюционной модели?

7. В чём суть спиральной модели? Объясните название этой модели.

8. В чём суть классической спиральной модели?

9. Охарактеризуйте особенность классической спиральной модели. Перечислите ключевые практики и контрольные точки для модели.

10. В чём суть модифицированной спиральной модели?

Лекция 7 Тема лекции

Технология разработки ПО (продолжение).

План лекции

1. Классические технологические процессы.

2. Методики анализа и проектирования.

Основное содержание

Процесс 1.Исследование идеи– процесс ЖЦ, который заключается в появлении и превращении возникшей идеи в определённую концепцию и в формировании проекта. Идея может привести либо к развитию уже существующего ПП, либо к созданию нового. Формальным результатом исследования идеи является одностраничное описание проекта.

Процесс 2.Управление– процесс ЖЦ, который заключается в принятии решений по правильной организации имеющихся ресурсов проекта в рамках поставленных ограничений для получения продукта, удовлетворяющего потребности пользователя и требования заказчика.

Данный процесс изучается специальной дисциплиной, называемой управление проектами(букв. проектный менеджмент). Для проекта управление определяет, как, с помощью каких действий, будет достигнута цель проекта и создан необходимый результат.Цель проектаописывает, какие задачи должны быть решены в результате проекта, асодержание проекта– что именно является результатом проекта. Цель проекта разделяется нацелевые установкиили [отдельные] целидля распределения работ по времени и участникам разработки. Для обеспечения адекватности проекта необходимоединое видениепроекта – ясное единообразное представление цели, установок и содержания проекта всеми лицами.

Формальным результатом планирования является план проекта, в том числе календарный план проекта.

Процесс 3.Анализ требований– процесс ЖЦ, который заключается в уточнении, формализации и документировании требований заказчика. Основной вопрос, который решается здесь – «ЧТО должен делать будущий продукт?» В этом процессе наиболее важным является понимание понятия «требование». Существует несколько точек зрения на понятие «требование».

Требование– условие или возможность, необходимая для решения проблемы или достижения определённых целей с помощью разрабатываемого продукта.Требование к продукту– условие или возможность, которую должен удовлетворять или которой должен обладать продукт или его компонент для обеспечения условий разработки, связанных с контрактом, стандартами, спецификациями. Аналогично формулируетсятребование к процессуЖЦ.

Спецификация требований является результатом формализации требований. В общем случае спецификация– достаточно полное и точное формальное описание работы, которую необходимо выполнить.Спецификация требований– это спецификация, включающая однозначно интерпретируемые требования, реализация которых проверяема, а стоимость и ресурсы – предсказуемы.

Существуют две существенно отличающиеся части спецификаций, соответствующие предъявляемым к ПО требованиям. Функциональные спецификациизадают содержание функционирования системы. Они описывают функции ПО на основе требований к системе.Эксплуатационные (нефункциональные) спецификациизадают характеристики системы и ограничения её функционирования. Они описывают особенности ПО на основе правил и стандартов.

Анализ требований также включает концептуальное моделирование. Разработка модели ПрО – ключевой элемент этого процесса. Цель моделирования – понимание проблемы, задачи и методов их решения до того, как начнётся собственно решение.

Формальным результатом анализа является спецификация требований и концептуальная модель ПрО.

Процесс 4.Проектирование– процесс ЖЦ, который заключается в исследовании структуры ПО и взаимосвязи его компонентов. Основной вопрос, который решается здесь – «КАК продукт будет удовлетворять полученным требованиям?». В этом процессе наиболее важным является представление разрабатываемого ПО (как единого целого) в виде системы.

Проектирование обычно разделяется на два взаимосвязанных подпроцесса:

1.Проектирование архитектуры(проектирование структуры, проектирование «в большом», архитектурное или высокоуровневое проектирование).

2.Проектирование компонентов(проектирование модулей, проектирование «в малом», детализированное или низкоуровневое проектирование).

В некоторых случаях выделяют связующий промежуточный подпроцесс:

3.Проектирование взаимодействия(проектирование управления, проектирование «в среднем», механистическое или среднеуровневое проектирование).

Проектирование архитектуры заключается в декомпозиции структуры системы и организации её компонентов. Проектирование компонентов описывает специфическое поведение и характеристики отдельных компонентов системы для их кодирования. Проектирование взаимодействия определяет организацию взаимодействия компонентов системы, выделенных при проектировании архитектуры и детализируемых при проектировании компонентов.

Архитектура ПО– представление ПО как системы из совокупности взаимодействующих частей. Компонент является относительно самостоятельной частью системы, в которой можно выделять только взаимосвязанные элементы. Дизайн представляет собой целостный взгляд на архитектуру ПО и состоит из различных точек зрения.Архитектурное представление– это архитектура ПО с определённой точки зрения.Архитектурная структура– дальнейшая детализация ПО, необходимая для реализации ПО и удовлетворения требований, предъявляемых к ПО.Дизайн ПО– комплекс архитектурных представлений и структур.

Формальным результатом проектирования являются дизайн продукта.

Процесс 5.Кодирование– процесс ЖЦ, который заключается в написании программного кода разрабатываемого ПО. Однако на практике такое определение оказывается слишком узким для этого классического процесса. Поэтому в настоящее время используется понятие «конструирование», определяемое следующим образом:Конструирование– процесс ЖЦ, который заключается в создании программного кода разрабатываемого ПО посредством комбинации дальнейшей детализации дизайна, кодирования и необходимого тестирования. В результате этот процесс оказывается наиболее связанным со смежными процессами – проектированием и тестированием.

К основным концепциям конструирования относят:

– Минимизация сложности: создание простого и легко читаемого кода.

– Ожидание изменений: создание легко адаптируемого кода.

– Конструирование с проверкой: создание легко тестируемого кода.

– Стандарты в конструировании: следование стандартам при создании кода.

Поддержка этих концепций осуществляется заданием стиля программирования, единого для всего создаваемого программного кода проекта, и использованием методов защитного программирования. Большинство вопросов, связанных с выполнением процесса конструирования, относится к инженерии ПО.

Формальным результатом конструирования являются программный код.

Процесс 6.Тестирование– процесс ЖЦ, который заключается в оценке и улучшении качества ПО. В общем случае тестирование состоит в обнаружении проблем нарушения работы ПО.

Этот процесс представляет собой динамическуюверификацию поведения программы наограниченномнаборе тестов,выбранныхсоответствующим образом из обычно выполняемых действий прикладной области и обеспечивающих проверку соответствияожидаемомуповедению системы. При разработке с использованием формальных подходов вместо тестирования выполняют инспектирование – статическую верификацию поведения программы, которое не исключает применения статистического тестирования.

В настоящее время считается, что верификацию любого вида необходимо выполнять во время всего ЖЦ ПО. Большинство вопросов, связанных с выполнением процесса верификации, относится к инженерии ПО.

Формальным результатом тестирования являются «оттестированный» программный код, т.е. код с исключением недостатков, выявленных по сбоям.

Процесс 7.Ввод в действие– процесс ЖЦ, который заключается в передаче разработанного ПО в эксплуатацию. Он включает следующие действия:1. Распространение (доставка заказчику) продукта и2. Инсталляция (установка на конкретные системы) продукта.

Процесс 8.Сопровождение– процесс ЖЦ, который заключается модификации ПО после ввода его в действие для улучшения качества и дальнейшего совершенствования. В общем случае сопровождение состоит в обеспечении эффективной поддержки эксплуатируемого ПО при сохранении его целостности.

Основным принципом этого процесса является закон Биледи: используемый ПП подвергается непрерывным изменениям для поддержания его экономической выгоды. На практике именно недооценка сопровождения приводит к снижению эффективности ПО и отдачи от проекта. В настоящее время считается, что этот процесс по сути являетсяпродолжающейся разработкой.

Выделяют 4 категории сопровождения, рассматриваемых с точки зрения двух подходов и разбиваемых на две группы (табл.7.1).

Табл.7.1. Категории сопровождения

Подход	Коррекция	Расширение
Проактивный	Профилактика	Совершенствование
Реактивный	Корректировка	Адаптация

Таким образом, получаем следующие категории сопровождения. Корректирующее сопровождение – модификация для исправления обнаруженных дефектов: устранение сбоев и т.д. Адаптивное сопровождение – модификация для учёта требуемых изменений: учёт новых требований, изменение окружения ПО и т.д. Совершенствующее сопровождение – модификация для улучшения возможностей ПО: повышение характеристик ПО и т.д. Профилактическое сопровождение – модификация для предупреждения возможных проблем: определение и исправление скрытых дефектов до их реального появления в виде сбоев и т.д.

Эти категории соответствуют разным уровням модификации ПО. Ревизия (пересмотр) – незначительные, часто локальные, изменения кода. Реструктурирование (реструктуризация) – повторная разработка небольшой части кода обычно без изменения интерфейса. Реорганизация (реинжиниринг) – перестройка существующего кода обычно в соответствии с новой моделью или методологией. Реконструирование (реконструкция, повторное конструирование) – перекодирование существенной части кода.

Коррекция предполагает ревизию и реструктурирование, а расширение – реорганизацию и реконструирование. Кроме того, необходимо учитывать класс решаемой задачи и стоимость сопровождения.

Процесс 9.Снятие с эксплуатации– процесс ЖЦ, который заключается в прекращении сопровождения эксплуатируемого ПО. Он выполняется, когда невозможно выполнить ни одну из категорий сопровождения. Он осуществляется предварительным оповещением пользователей о прекращении сопровождения. Но использование ПО возможно вплоть до его морального устаревания.

В настоящее время наиболее употребительными при разработке ПО являются две методологии – структурная и объектно-ориентированная (OO). Принципиальное различие между ними заключается в разных способах декомпозиции систем.Структурная (функциональная) декомпозициярассматривает структуру и поведение системы в терминах иерархии функций и передачи информации.Объектная декомпозициярассматривает структуру системы в виде объектов и связей между ними, а поведение системы – в терминах обмена сообщениями между объектами.

Следует отметить, что в основе многих объектно-ориентированных методов лежит структурный метод, которому придана объектная окраска.

Анализ и проектирование – два достаточно близких и тесно связанных процесса. Они выполняют общую задачу, результатом которой должно стать чёткое представление о системе, на основе которого будет создан программный код.

В основе анализа и проектирования лежат модели и методы для формализации требований. Объединённые в некоторую комбинацию, они образуют методикиилиметодические подходык анализу и проектированию. Подходы имеют названия, причём большинство из них названы по именам своих авторов. Большинство методов и подходов применимы как при анализе, так и при проектировании.

Модели и методы анализа требований.Структурная методология: Диаграммы потоков данных (DFD); Диаграммы потоков управления; Таблицы / деревья решений; Сети Петри; Диаграммы функционального моделирования.ОО методология: КОК-карты (CRC); Диаграммы прецедентов; Диаграммы классов и объектов; Диаграммы состояний; Диаграммы деятельности; Диаграммы последовательности.

Модели и методы проектирования архитектуры.Структурная методология: Нисходящее проектирование; Восходящее проектирование.ОО методология: Проектирование предметных областей; Проектирование наведением мостов.

Модели и методы проектирования компонентов.Структурная методология: Диаграммы «сущность – связь» (ERD); Структурные карты; Скобочные диаграммы Варнье – Орра; Диаграммы деятельности; Диаграммы переходов состояний (STD); Блок-схемы, структурные схемы; Псевдокод; Блок-схемы, потоковые схемы; Диаграммы Несси – Шнейдермана.ОО методология: Диаграммы кооперации; Диаграммы компонентов; Диаграммы развёртывания.

Подходы (методики) к анализу и проектированию.Структурная методология: Подход Йордона / ДеМарко (SAD); Подход Гейна – Сарсона (SSA); Подход Константайна (SSD); Подход Джексона (JSD); Подход Варнье – Орра (DSSD); Подход Мартина (IE); Подход структурированного анализа и проектирования (SADT); Подход промышленной технологииDATARUN; Подход промышленного методаOracle.ОО методология: Подход на основе языкаUML; Подход Гради Буча (Booch); Подход Джеймса Рамбо (OMT); Подход Айвара Якобсона (OOSE); Подход Шлеер – Меллора (RD).