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

Август 12, 2022

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

Содержание

2. Цели: Представить: Концепцию инфраструктуры процессов Структуру унифицированного процесса Жизненный цикл унифицированного процесса Модели унифицированного процесса Фазы
3. Принятые сокращения: SS – Software System(s) – Программные система (ы) SEP – Software Engineering Process –
4. 1.1. Инфраструктура процесса
5. Инфраструктура SEP – процесса программной инженерии Что включает инфраструктура процесса? Ресурсы (компетентный штат, инструментарий, методы и
6. Процесс Процесс программной инженерии – это определён(конеч)ная последовательность задач, необходимая для того, чтобы программный продукт удовлетворял
7. Процесс1= технология + средства + люди + модель Технология – в разработке программных систем используются всевозможные
8. Люди – участники процесса и пользователи ПС (необходимо определить спрос на разработчиков ПС, состав квалифицированной команды,
9. Организационная модель Кто – люди (внештатники или сотрудники), требования к навыкам и квалификации, зарплата, … Что
10. Я почти понял. Давайте продолжим.
11. 1.1.1. Унифицированный процесс
12. Ситуация Процесс разработки ПС становится технологичным, но всё ещё не удовлетворяет инженерным требованиям Необходима реализация более
13. Процесс разработки ПС Он основан на вариантах использования (Use Cases) ПС, архитектурно ориентирован, итеративен, развивающийся Процесс
14. Процесс ... Унифицированный процесс – термин, который имеет много значений. Он включает разработку и сопровождение (в
15. Факторы, определяющие различие процессов Организационные (организационная структура, культура, опыт реализации и управления проектами, компетентность и опыт
16. Преимущества процесса Члены команды понимают, что они и другие должны делать Руководители понимают, что разработчики делают
17. Процесс базируется на вариантах использования ПС1 Перед созданием ПС необходимо знать что хочет пользователь, как и
18. Процесс базируется на вариантах использования ПС1 Варианты использования (UC) описывают функциональность – что ПС должна предоставлять
19. Процесс ориентирован на архитектуру1 Архитектурная модель ПС – это как архитектурный проект дома. Это взгляд на
20. Процесс ориентирован на архитектуру2 Архитектурная модель разрабатывается исходя из оценки будущих целей Она должна быть простой,
21. Процесс итеративен и развивается1 Разработка ПС разделяется на отдельно воплощаемые подсистемы, которые позже интегрируются в единую
22. Процесс итеративен и развивается2 Каждая итерация основывается на результатах предыдущей итерации и на требованиях проекта в
23. Сам ЖЦ ПС итеративен (вспомним) Анализ рынка Анализ требований Проект разработки ПС Разработка подсистем Интеграция подсистем,
24. ЖЦ унифицированного процесса (1) Философия жизни: Стадии жизни (циклы) Рождение Смерть
25. ЖЦ унифицированного процесса2 Каждый цикл состоит из четырёх фаз (НАЧАЛО, РАЗВИТИЕ (Детализация), КОНСТРУИРОВАНИЕ и ПЕРЕХОД к
26. ЖЦ унифицированного процесса3 Результат каждого цикла – новая реализация системы : код, который реализует все варианты
27. Модели унифицированного процесса1 Модель вариантов использования Аналитическая модель Проектная модель Модель размещения Модель реализации Тестовая модель
28. Модели унифицированного процесса2 Модель вариантов использования описывает, как ПС используется Аналитическая модель разъясняет, уточняет и детализирует
29. Модели унифицированного процесса3 Модель размещения определяет физическое размещение компонентов в компьютерах Модель реализации определяет физические компоненты
30. Фазы в цикле Работы Фазы Требования Анализ Разработка Реализация Тестирование Начало Развитие Конструирование Переход Итер.1 Итер.2
31. Фазы Каждая фаза итеративна. Фаза заканчивается представлением рабочих продуктов и средств. Развитие продукта гарантирует прогресс проекта.
32. Фаза НАЧАЛО1 Устанавливается начальное видение конечного продукта, составляется план действий Вопросы, на которые должны быть даны
33. Фаза НАЧАЛО2 На первый вопрос даёт ответ модель вариантов использования Структура (архитектура) системы на этой фазе
34. Фаза РАЗВИТИЕ (Детализация) Варианты использования детализируются и специфицируются, разрабатывается архитектура системы. Архитектура представляется моделями вариантов использования,
35. Фаза Конструирование Продукт разрабатывается (скелет обрастает мышцами). Верифицируется, качественно ли ПС выполняет (воспроизводит) все варианты использования,
36. Фаза Переход Точка – подготовка к переходу на следующую фазу Тестеры и добровольцы-пользователи бета-версии испытывают систему,
37. Интегрированный процесс Унифицированный процесс имеет много аспектов Необходимо согласовать (гармонизировать) циклы, фазы, работы, персонал, контроль качества,
38. Опять не ясно, что такое унифицированный процесс?
40. Скачать презентацию

Слайд 2

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

Слайд 3

Принятые сокращения:
SS – Software System(s) – Программные система (ы)
SEP – Software

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

Слайд 4

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

Слайд 5

Инфраструктура SEP – процесса программной инженерии
Что включает инфраструктура процесса?
Ресурсы (компетентный

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

Слайд 6

Процесс
Процесс программной инженерии – это определён(конеч)ная последовательность задач, необходимая для того,

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

Слайд 7

Процесс1= технология + средства + люди + модель
Технология – в разработке

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

Слайд 8

Люди – участники процесса и пользователи ПС
(необходимо определить спрос

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

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

Слайд 9

Организационная модель
Кто – люди (внештатники или сотрудники), требования к навыкам и

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

Слайд 10

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

Слайд 11

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

Слайд 12

Ситуация
Процесс разработки ПС становится технологичным, но всё ещё не удовлетворяет инженерным

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

Слайд 13

Процесс разработки ПС
Он основан на вариантах использования (Use Cases) ПС, архитектурно

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

Слайд 14

Процесс ...
Унифицированный процесс – термин, который имеет много значений. Он включает

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

Слайд 15

Факторы, определяющие различие процессов
Организационные (организационная структура, культура, опыт реализации и управления

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

Слайд 16

Преимущества процесса
Члены команды понимают, что они и другие должны делать
Руководители понимают,

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

Слайд 17

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

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

Слайд 18

Процесс базируется на вариантах использования ПС1
Варианты использования (UC) описывают функциональность –

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

Слайд 19

Процесс ориентирован на архитектуру1
Архитектурная модель ПС – это как архитектурный проект

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

Слайд 20

Процесс ориентирован на архитектуру2
Архитектурная модель разрабатывается исходя из оценки будущих целей
Она

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

Слайд 21

Процесс итеративен и развивается1
Разработка ПС разделяется на отдельно воплощаемые подсистемы, которые

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

Слайд 22

Процесс итеративен и развивается2
Каждая итерация основывается на результатах предыдущей итерации и

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

Слайд 23

Сам ЖЦ ПС итеративен (вспомним)
Анализ рынка
Анализ
требований
Проект
разработки
ПС
Разработка
подсистем
Интеграция
подсистем, тестирование ПС
Внедрение ПС,
её

оценка

Эксплуатация ПС, её сопровождение

Анализ опыта

Слайд 24

ЖЦ унифицированного процесса (1)
Философия жизни:
Стадии жизни (циклы)
Рождение
Смерть

Слайд 25

ЖЦ унифицированного процесса2
Каждый цикл состоит из четырёх фаз (НАЧАЛО, РАЗВИТИЕ (Детализация),

КОНСТРУИРОВАНИЕ и ПЕРЕХОД к следующему циклу), каждая из которых итеративна:

Слайд 26

ЖЦ унифицированного процесса3
Результат каждого цикла – новая реализация системы : код,

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

Слайд 27

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

Слайд 28

Модели унифицированного процесса2
Модель вариантов использования описывает, как ПС используется
Аналитическая модель разъясняет,

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

Слайд 29

Модели унифицированного процесса3
Модель размещения определяет физическое размещение компонентов в компьютерах
Модель реализации

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

Слайд 30

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

Слайд 31

Фазы
Каждая фаза итеративна. Фаза заканчивается представлением рабочих продуктов и средств. Развитие

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

Слайд 32

Фаза НАЧАЛО1
Устанавливается начальное видение конечного продукта, составляется план действий
Вопросы, на которые

должны быть даны ответы:
Что даст пользователю ПС?
Какая структура системы нужна для этого?
Каковы планы, даты, стоимость разработки продукта?

Слайд 33

Фаза НАЧАЛО2
На первый вопрос даёт ответ модель вариантов использования
Структура (архитектура) системы

на этой фазе существует только в начальной версии. Критические подсистемы идентифицируются.
Главная цель этой фазы – идентифицировать ключевые риски и приоритеты фазы

Слайд 34

Фаза РАЗВИТИЕ (Детализация)
Варианты использования детализируются и специфицируются, разрабатывается архитектура системы.
Архитектура

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

Слайд 35

Фаза Конструирование
Продукт разрабатывается (скелет обрастает мышцами). Верифицируется, качественно ли ПС выполняет

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

Слайд 36

Фаза Переход
Точка – подготовка к переходу на следующую фазу
Тестеры и добровольцы-пользователи

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

Слайд 37

Интегрированный процесс
Унифицированный процесс имеет много аспектов
Необходимо согласовать (гармонизировать) циклы, фазы, работы,

персонал, контроль качества, управление проектом, ...
Курс рассматривает только инженерные вопросы. Он не включает управление качеством, планирование управления проектом, реализацию проекта и распределение ресурсов, бизнес планирование и др. вопросы.

Слайд 38

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

Содержание

Принятые сокращения:SS – Software System(s) – Программные система (ы)SEP – Software

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

Инфраструктура SEP – процесса программной инженерииЧто включает инфраструктура процесса? Ресурсы (компетентный

ПроцессПроцесс программной инженерии – это определён(конеч)ная последовательность задач, необходимая для того,

Процесс1= технология + средства + люди + модель Технология – в разработке

Люди – участники процесса и пользователи ПС (необходимо определить спрос

Организационная модельКто – люди (внештатники или сотрудники), требования к навыкам и

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

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

СитуацияПроцесс разработки ПС становится технологичным, но всё ещё не удовлетворяет инженерным

Процесс разработки ПСОн основан на вариантах использования (Use Cases) ПС, архитектурно

Процесс ...Унифицированный процесс – термин, который имеет много значений. Он включает

Факторы, определяющие различие процессовОрганизационные (организационная структура, культура, опыт реализации и управления

Преимущества процессаЧлены команды понимают, что они и другие должны делатьРуководители понимают,

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

Процесс базируется на вариантах использования ПС1Варианты использования (UC) описывают функциональность –

Процесс ориентирован на архитектуру1Архитектурная модель ПС – это как архитектурный проект

Процесс ориентирован на архитектуру2Архитектурная модель разрабатывается исходя из оценки будущих целейОна

Процесс итеративен и развивается1Разработка ПС разделяется на отдельно воплощаемые подсистемы, которые

Процесс итеративен и развивается2Каждая итерация основывается на результатах предыдущей итерации и

Сам ЖЦ ПС итеративен (вспомним)Анализ рынкаАнализ требованийПроектразработкиПСРазработка подсистемИнтеграция подсистем, тестирование ПСВнедрение ПС,её

ЖЦ унифицированного процесса (1)Философия жизни:Стадии жизни (циклы)РождениеСмерть

ЖЦ унифицированного процесса2Каждый цикл состоит из четырёх фаз (НАЧАЛО, РАЗВИТИЕ (Детализация),

ЖЦ унифицированного процесса3Результат каждого цикла – новая реализация системы : код,

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

Модели унифицированного процесса2Модель вариантов использования описывает, как ПС используетсяАналитическая модель разъясняет,

Модели унифицированного процесса3Модель размещения определяет физическое размещение компонентов в компьютерахМодель реализации

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

ФазыКаждая фаза итеративна. Фаза заканчивается представлением рабочих продуктов и средств. Развитие

Фаза НАЧАЛО1Устанавливается начальное видение конечного продукта, составляется план действийВопросы, на которые

Фаза НАЧАЛО2На первый вопрос даёт ответ модель вариантов использованияСтруктура (архитектура) системы

Фаза РАЗВИТИЕ (Детализация)Варианты использования детализируются и специфицируются, разрабатывается архитектура системы. Архитектура

Фаза КонструированиеПродукт разрабатывается (скелет обрастает мышцами). Верифицируется, качественно ли ПС выполняет

Фаза ПереходТочка – подготовка к переходу на следующую фазуТестеры и добровольцы-пользователи

Интегрированный процессУнифицированный процесс имеет много аспектовНеобходимо согласовать (гармонизировать) циклы, фазы, работы,

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

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