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

Основное содержание Процесс 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).

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

• 1. Охарактеризуйте классический процесс «Исследование идеи».
• 2. Охарактеризуйте классический процесс «Управление».
• 3. Охарактеризуйте классический процесс «Анализ».
• 4. Охарактеризуйте классический процесс «Проектирование».
• 5. Охарактеризуйте классический процесс «Кодирование».
• 6. Охарактеризуйте классический процесс «Тестирование».
• 7. Охарактеризуйте классический процесс «Ввод в действие».
• 8. Охарактеризуйте классический процесс «Сопровождение».
• 9. Охарактеризуйте классический процесс «Снятие с эксплуатации».
• 10. Дайте определения понятиям, связанным с моделями и методами анализа и проектирования.
• 11. Перечислите основные модели и методы анализа требований для структурной и объектно-ориентированной методологии.
• 12. Перечислите основные модели и методы проектирования архитектуры для структурной и объектно-ориентированной методологии.
• 13. Перечислите основные модели и методы проектирования компонентов для структурной и объектно-ориентированной методологии.
• 14. Перечислите основные подходы (методики) к анализу и проектированию для структурной и объектно-ориентированной методологии.

Лекция 8