Процессы программной инженерии. Реализация и изменение процессов (Часть 1)

1. Процессы программной инженерии Реализация и изменение процессов (Часть 1)

2. Цели:

Представить:
•Концепцию инфраструктуры процессов
•Структуру унифицированного процесса
•Жизненный цикл унифицированного процесса
•Модели унифицированного процесса
•Фазы циклов
2

3. Принятые сокращения:

• SS – Software System(s) – Программные
система (ы)
• SEP – Software Engineering Process –
Процессы программной инженерии
• UC – Use Case(s) – Вариант(ы)
использования
3

4.

1.1. Инфраструктура процесса
4

5. Инфраструктура SEP – процесса программной инженерии

1.
Что включает инфраструктура процесса?
Ресурсы (компетентный штат, инструментарий, методы и
технологии, спонсирование, ...) а также ответственности по
выполнению процесса
2. Кто нуждается в инфраструктуре процесса?
Это нужно, чтобы поддержать процесс ресурсами в течение
всего жизненного цикла проекта включая его изменения
3. Почему
процессы изменяются?
Инсталлируются новые средства, выявляются новые ситуации,
делаются попытки оптимизации процессов, разрабатываются
новые инструменты и технологии, …
5

6. Процесс

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

7. Процесс1= технология + средства + люди + модель

•Технология – в разработке программных систем
используются всевозможные среды, знания, правила,
...
(языки программирования, ОС, компьютерные системы, сети,
CASE средства, ...)
•Средства (инструменты) – вспомогательные средства
разработки ПС, которые сопровождаются и
совершенствуются в ходе процесса вместе с
разработкой основного продукта
(чем лучше мастер, тем больше специальных инструментов у
него есть, например, NoMagic)
7

8.

Процесс2= технология + средства +
люди + модель
• Люди – участники процесса и пользователи ПС
(необходимо определить спрос на разработчиков ПС, состав
квалифицированной команды, для управления их навыками и
навыками пользователей ПС, это зависит от требований к
ПС, квалификации разработчиков и общей грамотности
компьютер люди, наиболее ограниченный параметр)
• Организационная модель – определение: кто, что,
когда и как делает + программная поддержка
(средства)
(Разработчик ПС – это не импровизирующий музыкант, он
“играет по нотам” – организационной модели проекта,
устанавливающей кто, что, когда и как должен делать«играть»)
8

9. Организационная модель

• Кто – люди (внештатники или сотрудники),
требования к навыкам и квалификации,
зарплата, …
• Что – работы (задачи), рабочие продукты
(программа, модели, документы …),...
• Когда – этапы, сетевой график,
устанавливающий взаимозависимость задач
и рабочих продуктов, ...
• Как – требования к качеству, ...
• Программная поддержка – групповой работы,
организации виртуальной работы,
дистанционной работы, управления рабочим
временем, субподряд, ...
9

10.

Я почти
понял.
Давайте
продолжим.
10

11.

1.1.1. Унифицированный
процесс
11

12. Ситуация

1. Процесс разработки ПС становится
технологичным, но всё ещё не
удовлетворяет инженерным требованиям
2. Необходима реализация
более общего (обобщённого)процесса
разработки ПС, который бы мог:
- направлять деятельность команды
- согласовать цели как индивидуальных разработчиков, так и
команд
- определить, какие типы средств (инструментов) необходимы
вначале для создания и совершенствования ПС
- определить критерии мониторинга процесса и измерения
параметров продукта
12

13. Процесс разработки ПС

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

14. Процесс ...

• Унифицированный процесс – термин, который имеет
много значений. Он включает разработку и
сопровождение (в том числе маркетинг),
разработчиков ПС, заказчиков, финансистов,
трейдеров (продавцов), менеджеров, …
• В нашем случае анализируются только технические
аспекты (унифицированный процесс – это
последовательность действий, которая преобразует
(трансформирует) пользовательские требования в
ПС)
Однако, унифицированный процесс не возможен без
анализа рынка, маркетинга, управления проектом,
управления качеством, управления рисками,
кадрового менеджмента, финансового планирования
и управления, ...
14

15. Факторы, определяющие различие процессов

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

16. Преимущества процесса

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

17. Процесс базируется на вариантах использования ПС1

• Перед созданием ПС необходимо знать что
хочет пользователь, как и с какой целью он будет
использовать ПС, а также выполнения каких
функций он ожидает от ПС
• Пользователь – человек, группа людей или
другая система
• Например, банкомат (ATM- Automated Teller
Machine) взаимодействует с человеком и
банковской системой; описываются цели,
варианты текущего диалога, коммуникационный
протокол и условия выдачи денег
17

18. Процесс базируется на вариантах использования ПС1

• Варианты использования (UC) описывают
функциональность – что ПС должна предоставлять
каждому пользователю
• Т.е. модель процесса включает и пользователя. В этом
состоит главная особенность унифицированного
процесса
• Спецификации детализируют и формализуют описания
• Варианты использования (UC), вытекающие из
моделей, регулируют процесс разработки ПС
18

19. Процесс ориентирован на архитектуру1

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

20. Процесс ориентирован на архитектуру2

• Архитектурная модель разрабатывается исходя из
оценки будущих целей
• Она должна быть простой, понятной, по возможности
легко изменяемой и пригодной к многократному
использованию (многоразовой). Она должна служить
как можно большим поколениям ПС.
• Варианты использования – функциональный взгляд
на ПС, архитектура – структурный взгляд. Что из них
приоритетнее – проблема «яйца и курицы».
20

21. Процесс итеративен и развивается1

• Разработка ПС разделяется на отдельно воплощаемые
подсистемы, которые позже интегрируются в единую
систему
• Разработка подсистем – минипроцесс со своими
собственными этапами: анализ, дизайн, реализация
(кодирование) и тестирование
• Уже это определяет, что разработка ПС является
итеративным процессом
• Интегрированные подсистемы могут нуждаться в
изменениях, что приводит к новым итерациям
• В ходе работы могут появляться ошибки, и их
исправление приводит к новой итерации
• ...
21

22. Процесс итеративен и развивается2

• Каждая итерация основывается на результатах
предыдущей итерации и на требованиях проекта
в целом
• Необходимо облегчить выполнение итераций и
сократить их число, так как от этого зависит
продолжительность и стоимость проекта
• Сделать это помогает более глубокий анализ
проекта и пользовательских требований
• В ходе итераций проект или его часть могут
детализироваться, требования или решения
могут пересматриваться, что приводит к новым
итерациям
22

23. Сам ЖЦ ПС итеративен (вспомним)

Анализ опыта
Анализ рынка
Анализ
требований
Эксплуатация ПС,
её сопровождение
Проект
разработки
ПС
Разработка
подсистем
Внедрение ПС,
её оценка
Интеграция
подсистем,
тестирование ПС
23

24. ЖЦ унифицированного процесса (1)

Философия жизни:
Стадии жизни (циклы)
Рождение
Смерть
24

25. ЖЦ унифицированного процесса2

• Каждый цикл состоит из четырёх фаз
(НАЧАЛО, РАЗВИТИЕ (Детализация),
КОНСТРУИРОВАНИЕ и ПЕРЕХОД к
следующему циклу), каждая из которых
итеративна:
НАЧАЛО
Итер.1Итер.2 ...
РАЗВИТИЕ
(Детализация)
КОНСТРУИРО
ВАНИЕ
ПЕРЕХОД
Выпуск продукта
25

26. ЖЦ унифицированного процесса3

• Результат каждого цикла – новая реализация
системы : код, который реализует все
варианты использования и
нефункциональные требования, варианты
тестов, модели, спецификации, ...
• Новые циклы вызываются необходимостью
добавления новых возможностей для
системы, изменением окружающей среды
(OС, СУБД, сети, ...), ...
• В новом цикле все шаги повторяются
26

27. Модели унифицированного процесса1

Модель
вариантов
использования
Аналитическ
ая модель
Проектная
модель
Модель
размещения
Модель
реализации
Тестовая
модель
27

28. Модели унифицированного процесса2

• Модель вариантов использования описывает,
как ПС используется
• Аналитическая модель разъясняет, уточняет и
детализирует варианты использования,
распределяет функции между объектами,
которые реализуют функции системы
• Структурная модель определяет статическую
структуру системы, состоящую из подсистем,
классов и интерфейсов, и распределяет
реализацию вариантов использования между
этими элементами
28

29. Модели унифицированного процесса3

• Модель размещения определяет
физическое размещение компонентов в
компьютерах
• Модель реализации определяет физические
компоненты системы и размещение классов
в этих компонентах, порядок и метод
реализации системы
• Тестовая модель описывает тесты для
тестирования вариантов использования
• Дополнительно может существовать бизнес
модель, которая описывает бизнес аспекты
ПС, а также и др. модели
29

30. Фазы в цикле

Работы
Фазы
Начало
Развитие
Конструирование
Переход
Требования
Анализ
Разработка
Реализация
Тестирование
Итер.1 Итер.2
...
...
...
...
...
...
Итерация – это мини проект
30

31. Фазы

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

32. Фаза НАЧАЛО1

• Устанавливается начальное видение конечного
продукта, составляется план действий
• Вопросы, на которые должны быть даны ответы:
1. Что даст пользователю ПС?
2. Какая структура системы нужна для этого?
3. Каковы планы, даты, стоимость разработки
продукта?
32

33. Фаза НАЧАЛО2

• На первый вопрос даёт ответ модель вариантов
использования
• Структура (архитектура) системы на этой фазе
существует только в начальной версии.
Критические подсистемы идентифицируются.
• Главная цель этой фазы – идентифицировать
ключевые риски и приоритеты фазы
33

34. Фаза РАЗВИТИЕ (Детализация)

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

35. Фаза Конструирование

• Продукт разрабатывается (скелет обрастает
мышцами). Верифицируется, качественно ли ПС
выполняет (воспроизводит) все варианты
использования, согласованные с пользователем.
• Здесь могут быть ошибки, приводящие к новым
итерациям. Основной вопрос – удовлетворяет ли
система пользовательским требованиям?
35

36. Фаза Переход

• Точка – подготовка к переходу на следующую
фазу
• Тестеры и добровольцы-пользователи бетаверсии испытывают систему, информируют о
недостатках и вносят предложения по её
совершенствованию
• Включает тиражирование ПС, обучение
пользователей, реализацию сервисов и справки
(Help)
• Дефекты группируются на устраняемые в этой
версии и устраняемые в другой версии
36

37. Интегрированный процесс

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

38.

Опять не ясно,
что такое
унифицирован
ный процесс?
38

39. Спасибо за внимание!