Введение в программную инженерию. Технологии программирования

1. Введение в программную инженерию

Технологии программирования

2. Технологии программирования

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

3. Программная инженерия/ Инженерия ПО – это…

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

4. Программная инженерия/ Инженерия ПО – это…

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

5. Практическая деятельность + область знания

Положительный опыт подвергается осмыслению,
обобщению и надлежащему оформлению →
появляются различные методы и практики (best
practices), также стандарты и методологии,
касающиеся всего процесса в целом.
5

6. Программное обеспечение

Программное обеспечение (ПО) – множество
развивающихся во времени логических
предписаний, с помощью которых некоторый
коллектив людей управляет и использует
многопроцессорную и распределенную систему
вычислительных устройств.
Харальд Милс, специалист в области ПИ из компании IBM
6

7. Программное обеспечение

1. Логические предписания – это не только сами
программы, но и различная документация (например,
по эксплуатации программ).
2. Современное ПО предназначено, как правило, для
одновременной работы со многими пользователями,
которые могут быть удалены друг от друга в
физическом пространстве. Таким образом,
вычислительная среда оказывается распределенной.
3. Задачи, решаемые современным ПО, часто требуют
различных вычислительных ресурсов. Таким образом,
вычислительная среда оказывается
многопроцессорной.
4. ПО развивается во времени – исправляются ошибки,
добавляются новые функции, выпускаются новые
версии, меняется его аппаратная база.
7

8. Свойства ПО

1. Сложность программных объектов, которая
существенно зависит от их размеров. Большее ПО с
аналогичной функциональностью – это другое ПО.
2. Согласованность. ПО основывается не на объективных
посылках, а должно быть согласовано с большим
количеством интерфейсов, с которыми впоследствии
оно должно взаимодействовать.
3. Изменяемость. ПО легко изменить и, как следствие,
требования к нему постоянно меняются в процессе
разработки.
4. Нематериальность. ПО невозможно увидеть, оно
виртуально.
8

9. Архитектура ПО

Определение и
управление
требованиями

10. Определение и управление требованиями

Причина множественности точек
зрения при разработке ПО
1. Из-за разных видов деятельности процесса
разработки ПО.
Этап
Функциональные
требования к ПО
Важность
Какая функциональность
должна быть реализована
Проектирование
Принципы и детали
реализации
Тестирование
Развертка
Система – черный ящик
Система – набор файлов,
хранилищ данных и т. д.
11

11. Причина множественности точек зрения при разработке ПО

2. В разработку/использование ПО вовлечено
большое количество очень разных
специалистов.
Продавец
Менеджер
Создаваемая
система
Заказчик
Разработчик
3. Уникальность каждой конкретной ситуации
при разработке.
12

12. Причина множественности точек зрения при разработке ПО

Точка зрения
Точка зрения – это определенный взгляд на
систему, который осуществляется для выполнения
какой-то определенной задачи кем-либо из
участников проекта. Точку зрения нужно ясно
осознавать при создании визуальных моделей.
Важнейшими характеристиками точки зрения
моделирования является цель (зачем создается
модель) и целевая аудитория (то есть, для кого
она предназначается).
13

13. Точка зрения

Управление требованиями проблема
1. Специализированность и специфика.
2. Индивидуальность заказчика.
3. Трудности понимания между заказчиком и
программистами.
4. Изменчивость ПО.
14

14. Управление требованиями - проблема

Трудности взаимопонимания
заказчика и разработчиков
1. Увидеть проблемы предметной области
изнутри.
2. Специфичность программирования как сферы
деятельности.
15

15. Трудности взаимопонимания заказчика и разработчиков

Изменчивость ПО и ее причины
• Меняется ситуация на рынке.
• Проблемы и трудности в ходе разработки.
• Заказчик меняет свое собственное видение
системы.
Изменчивость требований по ходу разработки
очень болезненно сказывается на продукте.
16

16. Изменчивость ПО и ее причины

Виды требований
• Функциональные требования являются
детальным описанием поведения и сервисов
системы, ее функционала.
• Нефункциональные требования описывают
такие характеристики системы, как надежность,
особенности поставки (наличие инсталлятора,
документации), определенный уровень качества,
требования на средства и процесс разработки
системы, требования к переносимости,
соответствию стандартам и т.д.
17

17. Виды требований

Свойств требований
• Ясность, недвусмысленность – однозначность
понимания требований заказчиком и разработчиками.
• Полнота и непротиворечивость.
• Необходимый уровень детализации. Требования
должны обладать ясно осознаваемым уровнем
детализации, стилем описания, способом формализации.
• Прослеживаемость – важно видеть то или иное
требование в различных моделях, документах, в коде
системы.
• Тестируемость и проверяемость – необходимо , чтобы
существовали способы оттестировать и проверить
данное требование.
• Модифицируемость. Определяет процедуры внесения
изменений в требования.
18

18. Свойств требований

Варианты формализации
требований
Неформальная постановка требований в переписке по
электронной почте. Работает в небольших проектах, при
вовлеченности заказчика в разработку, когда есть
взаимопонимание между заказчиком и командой.
Требования в виде документа – описание предметной
области и ее свойств, техническое задание как приложение
к контракту, функциональная спецификация для
разработчиков и т.д.
Требования в виде графа с зависимостями в одном из
средств поддержки требований. Такое представление
удобно при частом изменении требований, при
отслеживании выполнения требований, при организации
"привязки" к требованиям задач, людей, тестов, кода.
19

19. Варианты формализации требований

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

20. Ошибки при документировании требований

Цикл работы с требованиями
• Выделение требований (requirements elicitation), нацеленное на
выявление всех возможных источников требований и ограничений
на работу системы и извлечение требований из этих источников.
• Анализ требований (requirements analysis), целью которого является
обнаружение и устранение противоречий и неоднозначностей в
требованиях, их уточнение и систематизация.
• Описание требований (requirements specification). В результате этой
деятельности требования должны быть оформлены в виде
структурированного набора документов и моделей, который может
систематически анализироваться, оцениваться с разных позиций и в
итоге должен быть утвержден как официальная формулировка
требований к системе.
• Валидация требований (requirements validation), которая решает
задачу оценки понятности сформулированных требований и их
характеристик, необходимых, чтобы разрабатывать ПО на их
основе.
SWEBOK
21