проектирование 1

1. Системная инженерия

Лекция 1

2. Системная инженерия

По INCOSE (International Council on Systems Engineering):
Системная инженерия — это «междисциплинарный подход и
средство создания успешных систем. Она фокусируется на
определении потребностей заказчиков, документировании
требований и обеспечении того, чтобы конечная система
удовлетворяла ожидания в течение всего жизненного цикла».
По ISO/IEC 15288:
Системная инженерия — это совокупность процессов, которые
охватывают весь жизненный цикл системы: от концепции и
разработки до эксплуатации и вывода из эксплуатации

3. Системная инженерия

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

4. Основные задачи системной инженерии:

Определение требований и ограничений
Разработка архитектуры
Управление рисками
Координация взаимодействия участников
Контроль качества и соответствие стандартам

5.

5

6. Продукт

Артефакт – любой вид информации, создаваемый,
изменяемый и используемый сотрудниками при
создании системы
Артефакты:
Само приложение
Спецификация требований
Проектная модель
Исходный и объектный код
Тестовые процедуры
…
6

7. Проект

Совокупность действий, необходимых для создания
артефакта:
контакт с заказчиком
написание документации
проектирование
программирование
тестирование
…
7

8. Процесс

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

9. Семейства процессов разработки ПО

тяжеловесные (heavyweight)
применяются при фиксированных требованиях и
многочисленной группе разработчиков разной
квалификации
облегченные (lightweight, agile)
применяются при малочисленной группе
квалифицированных разработчиков и грамотном
заказчике, который имеет возможность
участвовать в процессе
9

10. Жизненный цикл программного обеспечения

период от момента появления идеи создания
некоторого программного обеспечения до момента
завершения его поддержки фирмойразработчиком или фирмой, выполнявшей
сопровождение.
Состав процессов жизненного цикла
регламентируется международным стандартом
ISO/1EC12207: 1995 «Information Technologe Software Life Cycle Processes»

11.

12. Стратегии конструирования ПО

однократный проход (водопадная стратегия) ;
эволюционная стратегия.

13. Водопадная модель ЖЦПО

14. V-образная модель (V-model)

15. Эволюционные модели

16. Инкрементная модель

17. Итеративная модель

18. Спиральная модель БОЭМА

19. Макетирование (прототипирование)

20.

Виды прототипирования
Выбрасываемое
Эволюционное
Инкрементальное
Экстремальной
Модель ЖЦПО
Прототипирование
Каскадная (водопадная)
Дополнительный инструмент
V-модель
Дополнительный инструмент
Итерационная/Инкрементная
Неотъемлемая часть процесса
Спиральная
Центральный элемент для
управления рисками

21. Стратегии создания ПО

Водопадная
В начале определены
все требования?
Циклов
конструирования
Промежуточное ПО
распространяется?
Эволюционная
Инкрементная
Итеративная
+
+
-
1
>1
>1
-
+
21

22. Процессы и их описание

Хорошее моделирование – это искусство
представления конкретного на
абстрактном уровне
Разработка качественного бизнес-процесса
возможна лишь в случае его подробного
описания.
Изображение бизнес-процесса в графическом
виде позволяет детализировать и затем
проанализировать каждый элемент цепочки
процессов, рассчитать необходимый ресурс.
22

23. Процессы и их описание

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

24. Модели и нотации

24

25. Модели и нотации

Разные виды моделей
описываются разными
нотациями.
Любая нотация должна обладать:
простотой,
индивидуальностью,
наглядностью,
единообразием,
определенностью.
25

26. Модели и нотации

26

27. SADT – Structured Analysis and Deign Technique

является методологией, основанной на концепциях системного
моделирования – представление системы, как совокупности подсистем,
компонентов и способов их соединений, с заданными ограничениями
функционирования.
27

28. SADT – Structured Analysis and Deign Technique

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

29. Основная идея SADT:

Мир рассматривается как система взаимодействующих подсистем
У системы есть:
○ сущность
○ граница
○ поведение
SADT-модель имеет единственную цель и точку зрения
○ Цель формируется из набора вопросов, на которые должна ответить модель
○ Точка зрения -- позиция, с которой описывается система
В основе SADT лежит последовательное выявление структуры системы
Два основных принципа:
○ Структурный блок – функция
○ Декомпозиция
Область моделирования описывает круг функции, которые будет и которые не
будет выполнят система.
29

30. SIPOC

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

31. SIPOC

На какие вопросы необходимо ответить.
Какие этапы верхнего уровня составляют процесс?
Что является выходами процесса?
Кто такие клиенты? Кто выиграет от этого процесса? Кто будет расстроен, если
этот процесс не будет работать должным образом?
Каковы требования Заказчиков в разрезе каждого результата?
Каковы внешние входы?
Кто поставляет входные данные?
31

32. SIPOC

На какие вопросы необходимо ответить.
Какие этапы верхнего уровня составляют процесс?
Что является выходами процесса?
Кто такие клиенты? Кто выиграет от этого процесса? Кто будет расстроен, если
этот процесс не будет работать должным образом?
Каковы требования Заказчиков в разрезе каждого результата?
Каковы внешние входы?
Кто поставляет входные данные?
32

33. SIPOC

ПОКУПАЕМ АВТОМОБИЛЬ
33

34. Методология IDEF0

описывает бизнес-процессов с помощью функциональных диаграмм
Особенности нотации:
Функциональные блоки (работы) – поименованные процессы, функции или задачи, которые
происходят в течение определенного времени и имеют распознаваемые результаты.
Имя работы должно быть выражено отглагольным существительным, обозначающим
действие.
Декомпозиция процесса на подпроцессы позволяет строить иерархические модели бизнеспроцессов.
На диаграмме рассматривается логические отношений между функциями, а не временная
последовательность (поток работ)
Используется для создания верхнего уровня модели бизнес-процессов и обеспечивает общее
или абстрактное описание объекта моделирования.
34

35. Методология IDEF0

описывает бизнес-процессов с помощью функциональных диаграмм
Выделяют четыре типа диаграмм:
контекстная;
диаграмма декомпозиции;
диаграмма дерева узлов;
диаграмма экспозиции.
35

36. Методология IDEF0

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

37. Методология IDEF0

описывает бизнес-процессов с помощью функциональных диаграмм
Выделяют четыре типа диаграмм:
контекстная;
диаграмма декомпозиции – второстепенные или дочерние. Описывают
составные части основной функции
37

38. Методология IDEF0

описывает бизнес-процессов с помощью функциональных диаграмм
Выделяют четыре типа диаграмм:
контекстная;
диаграмма декомпозиции;
диаграмма дерева узлов – определяет зависимость функций между собой
38

39. Методология IDEF0

описывает бизнес-процессов с помощью функциональных диаграмм
Выделяют четыре типа диаграмм:
контекстная;
диаграмма декомпозиции;
диаграмма дерева узлов;
диаграмма экспозиции – позволяют изобразить отдельные части системы,
для определения оптимальной точки зрения на бизнес-процесс
39

40. Методология IDEF0

Управляющее
воздействие
(информация)
Материальные
ресурсы
Вход
Материальные
продукты
Бизнеспроцесс
Выход
A0
Информационные
ресурсы
Информация
Персонал Инфраструктура
Механизм
Вход – это ресурсы, которые переносят свою стоимость на выход
полностью, то есть расходуются на создание результата, а механизмы
переносят свою стоимость только частично (например, оборудование
– через амортизацию, а люди – через заработную плату).
40

41. Типы межблочных связей

A0
A0
A1
Связь по выходу
A1
Связь по управлению
41

42. Типы межблочных связей

A0
A0
A1
A1
А2
Обратная связь по выходу
Обратная
управлению
связь
по
42

43. Типы межблочных связей

A1
A0
Связи «выход-механизм»
43

44.

Типы межблочных связей
Связи параллельные

45. Стратегии декомпозиции

Функциональная
P3 (PeoplePaperProcedures)
В соответчики с известными стабильными
подсистемами
Отслеживания ЖЦ
По физическому процессу

46. Ограничения стандарта IDEF0

количество функциональных блоков на диаграмме - от 3 до 6;
количество интерфейсных дуг на один функциональный блок не
более 5;
любой функциональный блок должен иметь, по крайней мере, одну
управляющую стрелка и одну исходящую;
компоновка блоков и интерфейсных дуг с подписями должна
обеспечивать максимальную читабельность диаграммы
наиболее важная функция располагается в верхнем левом углу.
46

47. Методология IDEF0

ОПИШЕМ бизнес-процесс малого предприятия по изготовлению и доставке пиццы.
Клиент оставляет заявку на изготовление пиццы по заданному рецепту, нужного размера,
на предприятии должны быть продукты для изготовления пиццы, и клиент должен иметь
возможность расплатиться за заказ.
Все процессы предприятия управляются внутренним регламентов и правилами совершения
торговли.
В бизнес-процессе задействован персонал и оборудование пекарни
47

48. Методология IDEF0

Клиент оставляет заявку на изготовление пиццы по заданному рецепту, нужного размера, на предприятии
должны быть продукты для изготовления пиццы, и клиент должен иметь возможность расплатиться за заказ.
Все процессы предприятия управляются внутренним регламентов и правилами совершения торговли.
В бизнес-процессе задействован персонал и оборудование пекарни
48

49. Методология IDEF0

49

50. Усложним бизнес-процесс

Усложним бизнеспроцесс
Информация об
остатках
50

51. Усложним бизнес-процесс

Усложним бизнеспроцесс
Информация
об
остатках
51

52.

Информация
об
остатках
52

53. Диаграмма дерево узлов

Дерево узлов
Доставка пиццы
Цель
Задачи
Работа с клиентом
Принять заявку
Работа с поставщиком
Выбрать доставу
Выбрать пиццу
Оформить заказ
Работа склада
Приготовление пиццы
Доставка товара
Методы
Оформить счет
Подготовить договор
53

54.

55.

56.

57. IDEF3

относится к классу Work Flow Modeling.
Предназначена для описаний отдельных элементов бизнес-процессов как
последовательности действий с детальным описанием происходящих
событий, для описания рабочих процессов как потоков работ выполняемых
последовательно по времени.
IDEF3 показывает причинно-следственные связи между ситуациями и
событиями в ходе функционирования системы, процесса или предприятия
57

58. IDEF3 элементы для моделирования

Единицы работ UOW (unit of work)
Объекты ссылки
58

59. IDEF3 элементы для моделирования

Единицы работ UOW (unit of work)
Объекты ссылки
Связи
«Временное предшествование» (Precedence)
«Поток объектов» (Object Flow)
«Нечеткое отношение» (Relational)
59

60. IDEF3 элементы для моделирования

Единицы работ UOW (unit of work)
Объекты ссылки
Связи
«Временное предшествование» (Precedence)
«Поток объектов» (Object Flow)
«Нечеткое отношение» (Relational)
Перекресток (JUNCTION)
Асинхронное И
Синхронное И
Асинхронное ИЛИ
Синхронное ИЛИ
Исключающее ИЛИ
60

61.

62. Давайте попробуем

Перед созданием бизнес-процесса с помощью нотации IDEF3 необходимо:
1. определить сценарий (описание действий необходимых для
достижения результата);
2. границы моделирования (область, за которую не стоит выходить для
достижения удобства восприятия модели);
3. определит точку зрения (с чьей стороны будет производится процесс).
ДЕТАЛИЗИРОВАТЬ ПРОЦЕСС
ПРИГОТОВЛЕНИЯ ПИЦЦЫ
62

63. Давайте попробуем

ДЕТАЛИЗИРОВАТЬ ПРОЦЕСС ПРИГОТОВЛЕНИЯ ПИЦЦЫ
Продукты
для заказа
Получить
продукты со
склада
Приготовить
питту
A4.1.1
Добавить доп.
соус
Рецепт по
артиклу
A4.1.6
A4.1.2
&
J1
Приготовить
начинку
J2
&
В заказе
допы
A4.1.3
Нагреть печь
A4.1.4
Сформировать
пиццу
O
Добавить доп.
сыр
O
J6
A4.1.7
Х
J3
A4.1.5
Заказ без
допов
Контроль
температуры
J4
Добавить доп.
ингредиенты
A4.1.8
O
J5
Испечь пиццу
Пицца
A4.1.9
63

64. Давайте попробуем

Клиент заполняет заказ на производство некоторого изделия. Заказ должен
быть учтен во внутренней CRM и проверен на соответствие номенклатуре
выпускаемых товаров. Если заказ выполнить возможно, то заявку необходимо
согласовать с планово-финансовым отделом и включить ее в план выпуска
продукции, предварительно согласовав сроки и стоимость с заказчиком. Если
заказ выполнить невозможно, необходимо уведомить об этом заказчика и
зарегистрировать заявку-отказ, аналогичная регистрация производится если
клиент н согласен с условиями производства продукта.
64

65. Давайте попробуем

Производство
возможно
Х
Заказ клиента
Рассчитать
себестоимость,
цену и сроки
заказа
Согласовать
условия поставки
с клиентом
J3
Выполнить учет
заказа в системе
Заказ соответствует
номенклатуре
Выполнить
анализ
соответствия
номенклатуре
Х
J1
Согласовать
заявку с ПФО
Производство
невозможно
План выпуска
Плановофинансовый
отдел
Заказ не
согласован с клиентом
Заказ
согласован
с клиентом
J5
Х
Заказ не соответствует
номенклатуре
O
J2
Уведомить
клиента о
невозможности
выполнить заказ
O
Заявка
на производство
Внести данные
об отказе в
заказе
J4
65

66. Нотация DFD (Data Flow Diagramming)

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

67. Нотация DFD поддерживает 3 уровня абстракции

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

68. Алфавит DFD

68

69. Основные правила построения DFD

Все потоки данных перемещаются между хранилищами через
процессы.
DFD не содержит логических операторов (XOR, AND OR)
Потоки данных на диаграмме должны быть названы и описаны в
словаре данных.
Проектирование начинается с контекстной диаграммы (описывает
назначение и границы системы, отражает только внешние
свойства, а не содержание системы.
69

70. Выдача кредита

Заявка на
кредит
70

71. Кофейный автомат

Выделим процессы:
Зададим хранилища:
«Рассчитать стоимость заказа» (на основании данных о выбранном напитке, наличии сахара,
молока)
«Оплатить заказ»
«Приготовить кофе»
«Налить кофе»
«Рецепт кофе» (информация)
«База ингредиентов» (информация)
«Счет на оплату» (информация)
«Емкость с водой» (материальное хранилище)
«Емкость с сахаром» (материальное хранилище)
«Емкость с зерном» (материальное хранилище)
«Склад стаканов» (материальное хранилище)
Определим внешние сущности:
«Клиент» (Покупатель)
«Банковская система» (при расчете картой)
71

72. Кофейный автомат

72

73. Предоставление контента по интересам пользователя

73

74. Предоставление контента по интересам пользователя

74

75. Основные ошибки при разработке DFD-диаграмм

1.
Отсутствие контекстной диаграммы -> отображает, что
находится вне системы и даёт ответ на главный
вопрос, какой внутренний процесс мы будем
детализировать на диаграммах нижних уровней.
2.
Неименованные потоки данных
3.
Отсутствие внешних сущностей - источников входящих в
процесс данных
4.
Каждый отдельный процесс должен иметь как минимум
один вход и один выход.
5.
В каждом хранилище данных должен быть как минимум
один входящий и один выходной поток данных.
6.
Каждый процесс на диаграмме потоков данных должен
быть связан с другим процессом или хранилищем данных.
75

76. EPC-Event-Driven Process Chain – поведенческая модель

Используется для моделирования поведения отдельных частей
системы при реализации функций

77.

78.

79.

80. Диаграмма «сущность-связь»

81. Диаграммы переходов состояний

Состояние
завершения
Исходное
состояние
Ввод
Всегда
инициализация
Вывод
Всегда
вычисления
Всегда
завершение

82.

83. Псевдокод

Структура
Псевдокод
Структура
Псевдокод
Следование
<Действие1>
Выбор
Выбор <код>
<Действие2>
<код1>:<Действие1>
<код2>: <Действие2>
…
Все-выбор
Ветвление
Если <Условие>
Цикл с
Для <индекс> =
то <Действие1>
заданным
<n>,<k>,<h>
иначе <Действие2> количеством
Цикл-пока
<Действие>
Все-если
повторений
Все-цикл
Цикл-пока
Цикл-до
Выполнять
<Условие>
<Действие>
Все-цикл
<Действие>
До <Условие>
Цикл-пока не конец
файла
Прочитать запись
Сравнить заданные поля
с критерием поиска
Если совпали
то Сохранить в
выходной список
Все-если
Все-цикл
Вывод результирующего
списка

84. Flow-формы

85. Диаграммы Насси-Шнейдермана

Действие1
Действие2

86. Структурные карты Константайна

Подсисте
ма
Модуль
Имя
а
б
в
г
а
Область
данных
Библиотека
б
в
г
типы модулей
элементы
XY
Z
A
а
B
б
связи
Последовательный
вызов
Параллельный
вызов
A
A
A
A вызывает B как сопрограмму
1
типы вызовов модулей
B
а
B
C
б
C
в
условные и циклические вызовы модулей

87. Пример Разработать структурную карту Константайна для задачи сортировки одномерного массива с помощью алгоритмов Пузырька,

для задачи сортировки одномерного массива с помощью
алгоритмов Пузырька, прямого выбора и Шелла
Программа сортировки
одномерных массивов
разными методами
Выбор метода
Массив
Массив
Массив
метод
Массив
Массив
Меню
Метод
пузырька
Массив
Метод
прямого
выбора
Массив
Метод
Шелла
метод
Массив
Вывод
текстового
описания
метода
Массив
Сортировка
Массив
Массив
Сортировка
Массив
Массив
Сортировка
Вывод
отсортированно
го массива

88. Схема Джексона

A
Операция
Программа
поиска нужного
принтера
1
B
C
D
1
а
б
A
Считывание
записи из
файла
A
1
B
O
C
O
в
элементы
D
O
B
г
*
Сравнение
содержимого с
заданным
критерием
пример
Вывод записей
о принтерах