Вы находитесь на странице: 1из 31

Технологии конструирования

программного обеспечения
(программная инженерия)
Software Engineering
Цель: обучение основным принципам и методам,
используемым на различных этапах разработки
программного обеспечения сложных компьютерных систем,
а также обучение организации процессов программной
разработки.
Дисциплина формирует знания по следующим вопросам:
• принципы и методы анализа исходных задач на разработку
и формирование требований к программным продуктам;
• принципы и методы анализа, проектирования, тестирования
и сопровождения программных продуктов;
• способы и средства руководства программным проектом,
количественной оценки программного продукта;
• современные инструментальные средства поддержки
процесса конструирования ПО;
• перспективы и возможности систем автоматизированного
проектирования программных изделий, тенденции
промышленного производства программного обеспечения.

2
Лекция 1

Организация процессов
разработки ПО
Определение технологии конструирования
программного обеспечения (программной инженерии)
Основным результатом рассматриваемой в дисциплине деятельности
является программное обеспечение (ПО).
Создается ПО промышленным способом, коллективом
профессионалов-инженеров, и продается пользователям в виде
программных продуктов. Разрабатываются программные продукты в
рамках программных проектов.
Программный проект — это временное предприятие, предназна-ченное
для создания уникальных продуктов. Временный характер проекта
подчеркивает, что у любого проекта есть определенное начало и
завершение. Завершение наступает, когда достигнуты цели проекта.
Характеристика «временный» не относится к создаваемому в ходе
проекта продукту, услуге или результату. Большинство проектов
предпринимается для достижения устойчивого, длительного
результата — время жизни конечного программного продукта может
существенно превышать время жизни программного проекта. В
состав программного проекта входят как люди (разработчики), так и
необходимые материальные ресурсы.
6
Программная инженерия (технология разработки программного
обеспечения) — система инженерных принципов для создания
экономичного ПО, которое надежно и эффективно работает в
реальных компьютерах.
Программная инженерия
Методы Средства
 Планирование и автоматизированная
оценка проекта поддержка методов
 Анализ требований (CASE система)
 Проектирование
алгоритмов и структур Процеcсы
 Кодирование "склеивают"методы и
 Тестирование средства,
определяют порядок
 .Сопровождение их применения

Процессом здесь называют набор взаимосвязанных работ, которые


преобразуют исходные данные в выходные результаты.

7
Средства (утилиты) ТКПО обеспечивают автоматизированную или
автоматическую поддержку методов. В целях совместного
применения утилиты могут объединяться в системы
автоматизированного конструирования ПО. Такие системы
принято называть CASE-системами. Аббревиатура CASE
расшифровывается как Computer Aided Software Engineering
(программная инженерия с компьютерной поддержкой).
Процеccы являются «клеем», который соединяет методы и утилиты
так, что они обеспечивают непрерывную технологическую
цепочку разработки. Процеccы определяют:
• порядок применения методов и утилит;
• формирование отчетов, форм по соответствующим требованиям;
• контроль, который помогает обеспечивать качество и
координировать изменения;
• формирование «вех», по которым руководители оценивают
прогресс.

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

9
Базис процессов разработки ПО
• Подготовка. К любой технической работе нужно правильно
подготовиться. Подготовка заключается в тесном
сотрудничестве с заказчиком и другими заинтересованными
лицами. Главное — понять цели заинтересованных лиц в
отношении продукта и проекта, собрать их требования к
характеристикам и функциям ПО.
• Планирование. По понятным причинам опытный
путешественник всегда берет в дорогу карту. Программный
проект подобен сложному путешествию, и деятельность
планирования создает карту, упрощающую «путешествие»
команды. Карта называется планом программного проекта.
План определяет порядок инженерной работы. Он
описывает технические задачи, которые надо выполнять,
наиболее вероятные факторы риска, подстерегающие
команду, требуемые ресурсы, рабочие продукты (модели,
документы, данные, отчеты, формы и т. д.), которые будут
созданы, и расписание работы.
10
Базис процессов разработки ПО (продолжение)
• Моделирование. В любой человеческой деятельности каждый день
работают с моделями. Модель — упрощенное представление
реальности. Модели «с высоты птичьего полета» наглядно
демонстрируют желаемую структуру и поведение системы (обычно
визуально). Модели позволяют лучше понять общую картину —
эскиз будущего решения. При необходимости эскиз дополняется
деталями. Так формируется окончательный способ решения
проблемы. Обычно моделирование включает в себя два действия:
анализ и проектирование. Модель анализа улучшает понимание
требований к ПО, а модель проектирования показывает эскиз
структуры и поведения ПО, выполняющего эти требования.
• Конструирование. Эта деятельность объединяет два действия:
генерацию программного кода ПО (ручную или автоматическую) и
тестирование, которое требуется для обнаружения ошибок в коде.
• Развертывание. ПО (окончательный вариант, или частично
завершенная версия) поставляется заказчику, который оценивает
полученный продукт и обеспечивает обратную связь, дающую
возможность улучшения продукта.
11
Классический жизненный цикл
П о д гото в ка
сб о р тр е бо ва н и й

П ланирование
оце нка
расписание

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

Конструиро ва ни е
кодиро ва ние
те с ти р о ва н и е

Разверты вание
п оста вка
сопровождение

12
• Подготовка обеспечивает активное взаимодействие с
потенциальным заказчиком. Помимо оформления контракта,
здесь собираются и формируются требования,
определяющие характеристики и функции будущей
программной системы. Этот сбор требует интенсивного
диалога с заказчиком и другими заинтересованными в
создании системы лицами. Фактически, эти требования
определяют полное задание на разработку.
• Планирование. На этом этапе решаются задачи
планирования программного проекта. В ходе планирования
проекта определяются объем будущих работ и их риск,
необходимые трудозатраты, формируются рабочие задачи и
расписание (план-график работ).
• Моделирование посвящено выполнению двух действий —
анализу требований и проектированию. Результаты этих
действий — модели — обычно записываются на
графическом языке моделирования, языке картинок.

13
Анализ требований обрабатывает набор требований к ПО,
сформированный на этапе подготовки. Уточняются и
детализируются функции, характеристики и интерфейс ПО.
Все текстовые определения и модели документируются в
спецификации анализа.
Проектирование состоит в создании представлений:
• архитектуры ПО;
• структурной и поведенческой организации частей
архитектуры ПО;
• входного и выходного интерфейса частей архитектуры
(входных и выходных форм данных).

14
Архитектура ПО определяет организационную структуру
программной системы, задает ее разбиение на части, связи
между этими частями, механизмы взаимодействия и
основные руководящие принципы для детализации
дальнейшего проектирования системы.
Архитектура — это множество значимых решений относительно
принципов построения программной системы. При
проектировании архитектуры выбирают структурные
элементы и интерфейсы, с помощью которых они связаны
между собой. Архитектура фиксирует:
• крупномасштабную организацию структурных элементов и
топологию их связей;
• поведение, описываемое кооперацией этих элементов;
• важные механизмы, доступные во всей системе;
• архитектурный стиль, который управляет организацией
элементов системы.

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

16
• Конструирование. Этот этап включает в себя действия
кодирования и тестирования.
Кодирование, иначе называемое программированием или
реализацией, состоит в переводе результатов
проектирования в текст на языке программирования.
Тестирование — выполнение программы для выявления
ошибок в функциях, логике и форме реализации
программного продукта. Если ошибки выявлены, запускается
отладка, цель которой — устранить ошибки.
• Развертывание. Последний этап классического жизненного
цикла нацелен на два действия: поставку разработанного
продукта заказчику и сопровождение процесса эксплуатации
этого продукта.

17
Сопровождение — это внесение изменений в эксплуатируемое ПО.
Цели изменений:
• исправление ошибок;
• адаптация к изменениям внешней для ПО среды;
• усовершенствование ПО по требованиям заказчика.
Адаптация обычно требуется, если заказчик хочет использовать
продукт с другой операционной системой, а усовершенствование
состоит или в расширении функциональности полюбившегося
продукта, или в изменении каких-то характеристик (например,
ускорения реакции на запросы пользователя).
Согласно статистическим данным, 65% сопровождения связано с
усовершенствованием ПО, 18% отводится на адаптацию и 17%
связано с исправлением ошибок. Из этого можно заключить, что
исправление ошибок не является самой распространенной работой
сопровождения. Львиная толика сопровождения ориентирована на
модернизацию ПО. Поэтому сопровождение само по себе является
естественным продолжением разработки системы со своими
этапами подготовки, планирования, моделирования и
конструирования.

18
Достоинства классического жизненного цикла:
 дает план и временной график по всем этапам проекта,
 упорядочивает ход разработки.

Недостатки классического жизненного цикла:


 реальные проекты часто требуют отклонения от
стандартной последовательности шагов;
 цикл основан на точной формулировке исходных
требований к ПО (реально в начале проекта требования
заказчика определены лишь частично);
 результаты проекта доступны заказчику только в конце
работы.

19
Макетирование

Основная цель макетирования: снять неопределенности в


требованиях заказчика.
Макетирование (прототипирование) — это процесс создания
модели требуемого программного продукта.

Ожидание Построение /
заказчика уточнение
макета

Оценка
макета
заказчиком

20
Алгоритм применения макетирования
Макетирование

Сбор и уточнение требований

Быстрое проектирование

Построение макета

Оценка макета заказчиком

Уточнение макета

Продолжать
Да
Нет
Разработка продукта

Конец

21
Достоинство макетирования:
обеспечивает определение полных требований к ПО.

Недостатки макетирования:
 заказчик может принять макет за продукт;
 разработчик может принять макет за продукт.

22
Стратегии разработки ПО
 однократный проход (водопадная стратегия) — линейная
последовательность этапов разработки;
 инкрементная стратегия. В начале процесса
определяются все пользовательские и системные
требования, оставшаяся часть разработки выполняется в
виде последовательности версий. Первая версия реализует
часть запланированных возможностей, следующая версия
реализует дополнительные возможности и т. д., пока не
будет получена полная система;
 эволюционная стратегия. Система также строится в виде
последовательности версий, но в начале процесса
определены не все требования. Требования уточняются в
результате разработки версий.

23
Характеристики стратегий разработки

Стратегия В начале процесса Множество циклов Промежуточное ПО


разработки определены все разработки? распространяется?
требования?
Однократный да нет нет
проход
Инкрементная да да может быть
(запланированное
улучшение
продукта)
Эволюционная нет да да

24
Инкрементная модель
Классический пример инкрементной стратегии разработки.
1-й Поставка 1-го
инкремент инкремента
Подготовка
Планирование Моделирование Конструирование Развертывание

2-й Поставка 2-го


инкремент инкремента
Подготовка
Моделирование Конструирование Развертывание
Планирование

3-й Поставка 3-го


инкремент инкремента

Подготовка
Планирование Моделирование Конструирование Развертывание

25
Спиральная модель
Классический пример применения эволюционной стратегии
конструирования. Спиральная модель (Барри Боэм, 1988)
базируется на лучших свойствах классического жизненного
цикла и макетирования, к которым добавляется новый
элемент — анализ риска.
Подготовка Планирование
сбор 3 оценка
требований расписание
2 анализ риска
4

Линия принятия решения


(продолжать или нет)
5

8
9
7

6
Развертывание Моделирование
поставка Конструирование
сопровождение
26
Четыре действия, представляемые четырьмя квадрантами
спирали:
1. Подготовка — сбор требований и ограничений.
2. Планирование — формирование плана проекта и анализ
риска.
3. Моделирование и конструирование — подготовка
моделей и реализация продукта следующего уровня.
4. Развертывание — оценка заказчиком текущей версии
продукта.
С каждой итерацией по спирали (продвижением от центра к
периферии) строятся все более полные версии ПО. В
каждом цикле по спирали требуется создание версии
продукта (нижний правый квадрант), которое может быть
реализовано моделированием-конструированием или
макетированием.

27
Достоинства спиральной модели:
1. наиболее реально (в виде эволюции) отображает
разработку программного обеспечения;
2. позволяет явно учитывать риск на каждом витке
эволюции разработки;
3. включает возможность оценки системы в итерационную
структуру разработки;
4. использует моделирование для уменьшения риска и
совершенствования программного изделия.
Недостатки спиральной модели:
1. повышенные требования к заказчику;
2. трудности контроля и управлением временем разработки.

28
Компонентно-ориентированная модель
Эта модель — развитие спиральной модели. В ней модифицируется содержание
квадранта моделирования-конструирования  — новая разработка основывается
на повторном использовании существующих программных компонентов.

Подготовка Планирование
сбор оценка
требований расписание
анализ риска

Развертывание Моделирование
поставка Конструирование
сопровождение

Содержание этапа Идентификация


кандидатов
в компоненты
Создание Поиск
n-й версии компонентов
системы в библиотеке

Включение новых Извлечение


компонентов компонентов
в библиотеку (если найдены)

Построение
компонентов
(если не найдены) 29
Модель зрелости процесса разработки ПО
CMM (Capability Maturity Model)

Уровень 5. Оптимизирующий
Планомерное улучшение и повышение
качества процесса

Уровень 4. Управляемый
Количественное управление процессом,
его качеством

Уровень 3. Определенный
Процесс полностью определен
и организован на основе единого
стандарта компании

Уровень 2. Повторяемый
Процесс планируется и отслеживается

Уровень 1. Начальный
Самоорганизующийся хаос. Процесс
осуществляется случайным образом

30
Спасибо за внимание
Кодовое слово: fwrwerwer

31