Технология разработки ПО

Сентябрь 3, 2022

Главная
Алгебра
Технология разработки ПО

Содержание

2. Существует два основных набора технологических процессов. Классический набор – совокупность основных процессов, сложившихся исторически в результате
3. Классические технологические процессы. Процесс 1. Исследование идеи – процесс ЖЦ, который заключается в появлении и превращении
4. Классические технологические процессы. Процесс 2. Управление – процесс ЖЦ, который заключается в принятии решений по правильной
5. Процесс 2. Управление – процесс ЖЦ Данный процесс изучается специальной дисциплиной, называемой управление проектами (букв. проектный
6. Процесс 3. Анализ требований Процесс 3. Анализ требований – процесс ЖЦ, который заключается в уточнении, формализации
7. Требование Требование – условие или возможность, необходимая для решения проблемы или достижения определённых целей с помощью
8. Спецификация требований Спецификация требований является результатом формализации требований. В общем случае спецификация – достаточно полное и
9. Концептуальное моделирование Анализ требований также включает концептуальное моделирование. Разработка модели ПрО – ключевой элемент этого процесса.
10. Процесс 4. Проектирование Процесс 4. Проектирование – процесс ЖЦ, который заключается в исследовании структуры ПО и
11. Проектирование Проектирование обычно разделяется на два взаимосвязанных подпроцесса: 1. Проектирование архитектуры (проектирование структуры, проектирование «в большом»,
12. Проектирование архитектуры Проектирование архитектуры заключается в декомпозиции структуры системы и организации её компонентов. Архитектура ПО –
13. Процесс 5. Кодирование Процесс 5. Кодирование – процесс ЖЦ, который заключается в написании программного кода разрабатываемого
14. К основным концепциям конструирования относят: – Минимизация сложности: создание простого и легко читаемого кода. – Ожидание
15. Процесс 6. Тестирование Процесс 6. Тестирование – процесс ЖЦ, который заключается в оценке и улучшении качества
16. Процесс 6. Тестирование В настоящее время считается, что верификацию любого вида необходимо выполнять во время всего
17. Процесс 7. Ввод в действие Процесс 7. Ввод в действие – процесс ЖЦ, который заключается в
18. Процесс 8. Сопровождение Процесс 8. Сопровождение – процесс ЖЦ, который заключается модификации ПО после ввода его
19. Категории сопровождения Корректирующее сопровождение – модификация для исправления обнаруженных дефектов: устранение сбоев и т.д. Адаптивное сопровождение
20. Процесс 9. Снятие с эксплуатации Процесс 9. Снятие с эксплуатации – процесс ЖЦ, который заключается в
21. Методологии разработки ПО В настоящее время наиболее употребительными при разработке ПО являются две методологии – структурная
22. Анализ и проектирование Анализ и проектирование – два достаточно близких и тесно связанных процесса. Они выполняют
23. Модели и методы анализа требований Структурная методология: Диаграммы потоков данных (DFD); Диаграммы потоков управления; Таблицы /
24. Модели и методы проектирования архитектуры Структурная методология: Нисходящее проектирование; Восходящее проектирование. ОО методология: Проектирование предметных областей;
25. Модели и методы проектирования компонентов Структурная методология: Диаграммы «сущность – связь» (ERD); Структурные карты; Скобочные диаграммы
27. Скачать презентацию

Слайд 2

Существует два основных набора технологических процессов.
Классический набор – совокупность основных

процессов, сложившихся исторически в результате практического опыта разработки ПО.
Классический набор включает 9 процессов:
1. Исследование;
2. Управление;
3. Анализ;
4. Проектирование;
5. Кодирование;
6. Тестирование;
7. Ввод в действие;
8. Сопровождение;
9. Снятие с эксплуатации.
Процессы классического набора фактически являются подмножеством стандартного, выступая там как процессы или действия процессов.
Стандартный набор – совокупность процессов из ISO/IEC 12207:1999 «Информационная технология – Процессы жизненного цикла ПО».
Стандартный набор включает 3 группы процессов:
основные,
вспомогательные,
организационные процессы.

Слайд 3

Классические технологические процессы.
Процесс 1. Исследование идеи – процесс ЖЦ, который заключается

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

Слайд 4

Классические технологические процессы.
Процесс 2. Управление – процесс ЖЦ, который заключается в

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

Слайд 5

Процесс 2. Управление – процесс ЖЦ
Данный процесс изучается специальной дисциплиной, называемой

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

Слайд 6

Процесс 3. Анализ требований
Процесс 3. Анализ требований – процесс ЖЦ,

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

Слайд 7

Требование
Требование – условие или возможность, необходимая для решения проблемы или достижения

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

Слайд 8

Спецификация требований
Спецификация требований является результатом формализации требований. В общем случае

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

Слайд 9

Концептуальное моделирование
Анализ требований также включает концептуальное моделирование. Разработка модели ПрО

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

Слайд 10

Процесс 4. Проектирование
Процесс 4. Проектирование – процесс ЖЦ, который заключается

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

Слайд 11

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

проектирование «в большом», архитектурное или высокоуровневое проектирование).
2. Проектирование компонентов (проектирование модулей, проектирование «в малом», детализированное или низкоуровневое проектирование).
В некоторых случаях выделяют связующий промежуточный подпроцесс:
3. Проектирование взаимодействия (проектирование управления, проектирование «в среднем», механистическое или среднеуровневое проектирование).

Слайд 12

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

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

Слайд 13

Процесс 5. Кодирование
Процесс 5. Кодирование – процесс ЖЦ, который заключается

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

Слайд 14

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

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

Слайд 15

Процесс 6. Тестирование
Процесс 6. Тестирование – процесс ЖЦ, который заключается

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

Слайд 16

Процесс 6. Тестирование
В настоящее время считается, что верификацию любого вида

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

Слайд 17

Процесс 7. Ввод в действие
Процесс 7. Ввод в действие –

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

Слайд 18

Процесс 8. Сопровождение
Процесс 8. Сопровождение – процесс ЖЦ, который заключается

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

Слайд 19

Категории сопровождения
Корректирующее сопровождение – модификация для исправления обнаруженных дефектов: устранение

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

Слайд 20

Процесс 9. Снятие с эксплуатации
Процесс 9. Снятие с эксплуатации –

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

Слайд 21

Методологии разработки ПО
В настоящее время наиболее употребительными при разработке ПО

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

Слайд 22

Анализ и проектирование
Анализ и проектирование – два достаточно близких и

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

Слайд 23

Модели и методы анализа требований
Структурная методология: Диаграммы потоков данных (DFD); Диаграммы

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

Слайд 24

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

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

Слайд 25

Модели и методы проектирования компонентов
Структурная методология: Диаграммы «сущность – связь»

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

Технология разработки ПО

Содержание

Существует два основных набора технологических процессов. Классический набор – совокупность основных

Классические технологические процессы. Процесс 1. Исследование идеи – процесс ЖЦ, который заключается

Классические технологические процессы. Процесс 2. Управление – процесс ЖЦ, который заключается в

Процесс 2. Управление – процесс ЖЦДанный процесс изучается специальной дисциплиной, называемой

Процесс 3. Анализ требований Процесс 3. Анализ требований – процесс ЖЦ,

ТребованиеТребование – условие или возможность, необходимая для решения проблемы или достижения

Спецификация требований Спецификация требований является результатом формализации требований. В общем случае

Концептуальное моделирование Анализ требований также включает концептуальное моделирование. Разработка модели ПрО

Процесс 4. Проектирование Процесс 4. Проектирование – процесс ЖЦ, который заключается

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

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

Процесс 5. Кодирование Процесс 5. Кодирование – процесс ЖЦ, который заключается

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

Процесс 6. Тестирование Процесс 6. Тестирование – процесс ЖЦ, который заключается

Процесс 6. Тестирование В настоящее время считается, что верификацию любого вида

Процесс 7. Ввод в действие Процесс 7. Ввод в действие –

Процесс 8. Сопровождение Процесс 8. Сопровождение – процесс ЖЦ, который заключается

Категории сопровождения Корректирующее сопровождение – модификация для исправления обнаруженных дефектов: устранение

Процесс 9. Снятие с эксплуатации Процесс 9. Снятие с эксплуатации –

Методологии разработки ПО В настоящее время наиболее употребительными при разработке ПО

Анализ и проектирование Анализ и проектирование – два достаточно близких и

Модели и методы анализа требований Структурная методология: Диаграммы потоков данных (DFD); Диаграммы

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

Модели и методы проектирования компонентов Структурная методология: Диаграммы «сущность – связь»

Похожие презентации