Согласование, установление взаимосвязей. Проектный практикум. Учебный курс. Лекция 2

1.

Учебный курс
Проектный практикум
Лекция 2

2.

Согласование, установление
взаимосвязей
2

3. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

Процесс
(исполни
тель
процесса)
Действия
Вход
Результат
Приобрете
ние
(заказчик)
Инициирование
Подготовка
заявочных
предложений
Подготовка
договора
Контроль
деятельности
поставщика
Приемка ИС
Решение о начале
работ по внедрению
ИС
Результаты
обследования
деятельности
заказчика
Результаты анализа
рынка ИС/тендера
План
поставки/разработки
Комплексный тест
ИС
Техникоэкономическое
обоснование внедрения
ИС
Техническое задание
на ИС
Договор на
поставку/разработку
Акты приемки этапов
работы
Акт приемо-сдаточных
испытаний
3

4. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

Процесс
(исполни
тель
процесса)
Действия
Вход
Результат
Поставка
(разработч
ик ИС)
Инициирование
Ответ на
заявочные
предложения
Подготовка
договора
Планирование
исполнения
Контроль
исполнения
Поставка
Техническое
задание на ИС
Решение
руководства об
участии в разработке
Результаты тендера
Техническое
задание на ИС
План управления
проектом
Разработанная ИС
и документация
Решение об участии в
разработке
Коммерческие
предложения/конкурсна
я заявка
Договор на
поставку/разработку
План управления
проектом
Реализация/корректир
овка
Акт приемосдаточных испытаний
4

5. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

Содержание основных
процессов ЖЦ ПО ИС (ISO/IEC
12207)Вход
Процесс
Действия
Результат
(исполни
тель
процесса)
Разработка
(разработчи
к ИС)
Подготовка
Анализ требований
к ИС
Проектирование
архитектуры ИС
Разработка
требований к ПО
Проектирование
архитектуры ПО
Детальное
проектирование ПО
Техническое задание
на ИС
Техническое задание
на ИС, модель ЖЦ
Техническое задание
на ИС
Подсистемы ИС
Спецификации
требования к
компонентам ПО
Архитектура ПО
Используемая модель
ЖЦ, стандарты разработки
План работ
Состав подсистем,
компоненты оборудования
Спецификации
требования к компонентам
ПО
Состав компонентов ПО,
интерфейсы с БД, план
интеграции ПО
Проект БД,
спецификации
интерфейсов между
компонентами ПО,
требования к тестам
5

6. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

Содержание основных
процессов ЖЦ ПО ИС (ISO/IEC
12207)Вход
Процесс
Действия
Результат
(исполните
ль
процесса)
Разработка
(разработч
ик ИС)
Кодирование и
тестирование ПО
Интеграция ПО и
квалификацион
ное тестирование
ПО
Интеграция ИС и
квалификацион
ное тестирование
ИС
Материалы
детального
проектирования ПО
План интеграции
ПО, тесты
Архитектура ИС,
ПО, документация на
ИС, тесты
Тексты модулей ПО,
акты автономного
тестирования
Оценка соответствия
комплекса ПО
требованиям ТЗ
Оценка соответствия
ПО, БД, технического
комплекса и
комплекта
документации
требованиям ТЗ
6

7. Соответствие процессов

ГОСТ 34.601-90;
"э.X.Y" - этап Y
стадии X
ISO/IEC12207:
1995-08-01
Oracle CDM;
Примечание
э.5.3 ТП, э.7.3 ВД.
1) Процесс
приобретения
разработчиком
нет
в ГОСТ это
приобретение
планируется
нет
2) Процесс поставки
нет
CDM содержит
процесс CV,
Все этапы
ГОСТ34.601 кроме 8.
Сп, а именно: 1. ФТ,
2. РК, 3. ТЗ, 4. ЭП, 5.
ТП,6. РД, 7. ВД.
3) Процесс
разработки.
Определяет действия
предприятияразработчика,
которое
разрабатывает
принцип построения
программного
изделия и
программный
продукт (в контексте
создания системы).
RD, ES, TA, DB, MD,
(DO), TE, (TR), TS.
аналог есть в ГОСТ
(э.7.5 ВД и ранее), в
ISO аналога нет в
явном виде.
Процессы DO TR из
CDM указаны в
скобках, так как они
отражены и в других
стандартах ГОСТ34 и
процессах ISO12207.
7

8. Соответствие процессов

ГОСТ 34.601-90;
"э.X.Y" - этап Y
стадии X
ISO/IEC12207:
1995-08-01
Oracle CDM;
Примечание
нет
4) Процесс
эксплуатации
нет
По ISO организацияоператор
разрабатывает план и
гарантирует
соответствие плану
8. Сп., развитие АС по пункту.1.3 ГОСТ
34.601.
5) Процесс
сопровождения
PS
ISO предполагает
развитие как элемент
сопровождения,
вызывающий новый
процесс разработки, в
CDM в этом смысле
полномасштабное
развитие не
предусмотрено
8

9. Распределение процессов по стадиям ЖЦ (ISO/IEC 12207)

Формирование
требований
Проектиро
вание
Реализация
Тестирова
ние
Ввод в
действие
Сопровожде
ние
Снятие
Процесс «ПРИОБРЕТЕНИЕ»
Инициирование
Заявочные предл.
Договор
Надзор за деятельностью поставщика
Приемка и завершение
Процесс «ПОСТАВКА»
Инициирование
Ответ на ЗП
Договор
Планирование
Выполнение и контроль
Проверка и оценка
9
Поставка и завершение

10. Распределение процессов по стадиям ЖЦ

Формирование
требований
Проектиро
вание
Реализация
Тестирова
ние
Ввод в
действие
Сопровожде
ние
Снятие
Процесс «РАЗРАБОТКА»
Подгот. работа
Анализ требований к системе
Проектиров.
архитектуры
Детальное
проектиров.
Кодирование
и тестир. ПО
Интеграция
Квалификационное
тестирование ПО
Интеграция
ИС
Квалификационное
тестирование ИС
Установка
Приемка
10

11. Процессы CDM

•RD - Определение производственных требований,
•ES - Исследование существующих систем,
•TA - Определение технической архитектуры,
•DB - Проектирование и построение БД,
•MD - Проектирование и реализация модулей,
•CV - Конвертирование данных,
•DO - Документирование,
•TE - Тестирование,
•TR - Обучение,
•TS - Переход к новой системе,
•PS - Поддержка и сопровождение.
11

12. Последовательности задач

RD.020 – RD.030 – RD.070 – BR.020 – BR.080 – MD.020 –
MD.060 – DO.070 – TE.110 – PM.050 – CV.140 – PM.080, где
•RD.020 – изучение существующих бизнес-процессов
•RD.030 – моделирование будущих бизнес-процессов
•RD.070 – выявление детальных требований к будущим
бизнес-процессам
•BR.020 – отображение бизнес-процессов в
функциональность приложения
•BR.080 – тестирование принятых решений
12

13. Последовательности задач

RD.020 – RD.030 – RD.070 – BR.020 – BR.080 – MD.020 –
MD.060 – DO.070 – TE.110 – PM.050 – CV.140 – PM.080, где
•MD.020 – оценка решений по доработке
функциональности приложения
•MD.060 – дизайн расширений функциональности
приложения
•DO.070 – разработка инструкций пользователя
•TE.110
– тестирование приложения
•PM.050 – установка приложения на систему периода
эксплуатации
•CV.140 – ввод начальных данных
•PM.080 – запуск новой системы
13

14. Доработка

AIM разделяет доработку:
•при «нехватке» возможностей приложения, касающихся
функциональности
•при «нехватке» возможностей приложения, касающихся
отчетов
•при «нехватке» возможностей приложения по
предоставлению/ограничению доступа к функциям и
данным,
•при разработке программ автоматической конвертации
(программ переноса бизнес-данных в новое приложение).
14

15. Доработка

Доработка основного функционала
BR.020 – BR.080 – MD.020
•BR.020 – выявление «дыр» функциональности
приложения, предварительное формулирование решения,
как можно устранить «дыры»
•BR.080 – первоначальная оценка предложенного
предварительного решения
•MD.020 – окончательное формулирование решения, как
можно устранить «дыры», оценка трудозатрат
15

16. Характеристики стандартов

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

17. Методика Oracle CDM

Стандарт, детализированный до уровня заготовок
проектных документов, рассчитанных на прямое
использование в проектах ИС с реализацией на
инструментальных средствах Oracle.
Ориентирован на поддержку деятельности разработчика.
17

18. Степень адаптивности

- ограничивается тремя разновидностями каскадной модели
ЖЦ: "классическая" (предусмотрены все работы/задачи и
этапы), "быстрая разработка" (Fast Track) (еще более сильно
ориентированная на использование инструментов моделирования и
программирования Oracle), "облегченный подход"
(рекомендуемый в случае малых проектов и возможности быстро
прототипировать приложения).
Методика не предусматривает:
включение дополнительной задачи, которой нет в CDM,
и ее привязку к остальным;
удаление задачи (и порождаемых ею документов);
изменение последовательности выполнения задач по
сравнению с предложенной (тем более - по ходу процесса
проектирования).
18

19. Степень обязательности

методика необязательна, но может считаться фирменным
стандартом; при формальном применении степень обязательности
полностью соответствует ограничениям возможностей адаптации
Прикладная система рассматривается в основном как
программно-техническая система - моменты организации
выполнения возможных оргструктурных преобразований, реально
всегда происходящих при переходе к новой ИС, и
соответствующее обеспечение отсутствуют в этой методике.
Другой фактической ориентацией методики является ее (исторически
понятная) направленность на создание Информационной Системы с
Базами Данных в достаточно традиционном понимании.
19

20. ISO 12207

На первый взгляд неконкретный, но вполне новый и отчасти
"модный" стандарт.
Определяет процессы ЖЦ. Состоит из крупных обобщенных
процессов: "приобретение", "поставка", "разработка" и т. п.
Каждый процесс разделен на набор действий, каждое действие - на
набор задач.
Каждый процесс, действие или задача инициируется и выполняется
другим процессом по мере необходимости.
Заранее определенных последовательностей нет.
Равносильно ориентирован на организацию действий
каждой из двух сторон: поставщик (разработчик) и
покупатель (пользователь).
!
20

21. Степень адаптивности

Степень адаптивности: максимальная. Множество процессов и
задач сконструировано так, что возможна их адаптация в
соответствии с проектами ПО. Процесс адаптации является
процессом исключения процессов, видов деятельности и задач,
не применимых в конкретном проекте.
Добавление уникальных или специфических процессов,
действий и задач должно быть оговорено в контракте между
сторонами.
Позволяет реализовывать любую модель ЖЦ - один
процесс при необходимости вызывает другой или его часть
21

22. Степень обязательности

После решения организации о применении ISO12207 в качестве
условия торговых отношений возникает ее ответственность за
указание минимального набора требуемых процессов и задач,
которые составляют согласованность с этим стандартом.
Стандарт не предписывает конкретную модель ЖЦ или метод
разработки, но определяет, что стороны-участники использования
стандарта ответственны за выбор модели ЖЦ для проекта, за
адаптацию процессов и задач стандарта к этой модели, за выбор и
применение методов разработки, за выполнение действий и задач,
подходящих для проекта.
Стандарт ориентирован на различные виды ПО и типы
проектов АС, куда ПО входит как часть;содержит предельно
мало описаний, направленных на проектирование БД.
22

23. Стандарты комплекса ГОСТ 34

- обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и
проектной документации. Многими считаются бюрократическими до
вредности и консервативными до устарелости.
Содержат описание стадий и этапов ЖЦ, и содержания
документов, разрабатываемых на каждом этапе. Это определяет
потенциальные возможности выделения на содержательном
уровне сквозных работ, выполняемых параллельно или
последовательно (то есть по сути - процессов), и составляющих
их задач.
Комплекс стандартов рассчитан на взаимодействие заказчика и
разработчика.
Наиболее распространены: ГОСТ 34.601-90 (Стадии создания АС),
ГОСТ 34.602-89 (ТЗ на создание АС), методические указания РД 5034.698-90 (Требования к содержанию документов).
23

24. Степень адаптивности

определяется возможностями:
1. опускать стадию эскизного проектирования и объединять
стадии "Технический проект" и "Рабочая документация";
2. опускать этапы, объединять и опускать большинство
документов и их разделов;
3. вводить дополнительные документы, разделы документов и
работы;
4. гибко формировать ЖЦ динамически создавая т. н. ЧТЗ; как
правило, этот прием используется на уровне крупных
единиц (подсистем, комплексов), ради которых считается
оправданным создавать ЧТЗ, однако нет никаких
существенных оснований сильно ограничивать этот способ
управления ЖЦ.
24

25. Степень обязательности

Прежняя полная обязательность отсутствует, материалы ГОСТ34
по сути стали методической поддержкой, причем чаще для
заказчиков, имеющих в стандарте набор требований к содержанию
ТЗ и проведению испытаний АС.
Стадии и этапы, выполняемые организациями - участниками
работ по созданию системы, устанавливаются в договорах и
техническом задании
Объектами стандартизации являются автоматизированные
системы различных (любых!) видов и все виды их
компонентов (а не только ПО и БД):
"организационно-техническая система, обеспечивающая выработку решений
на основе автоматизации информационных процессов в различных
сферах деятельности (управление, проектирование, производство и т. д.)
или их сочетаниях" (по РД 50-680-88), что особенно актуально в аспектах
25
бизнес-реинжиниринга;

26. Waterfall model (модель водопада)

Разработка основана на на выполнении одной цепочки
проектирования в соответствии с заранее определенными
требованиями
26

27. Incremental model (модель расширения системы)

Разработка основана на последовательном\параллельном
выполнении нескольких цепочек проектирования в соответствии
27
с заранее определенными требованиями

28. Evolutionary model (эволюционная модель)

Разработка осуществляется при постоянном
уточнении требований
28

29. Моделирование функциональной области внедрения ИС

1. Моделирование – основа проектирования
ИС
2. Основные подходы к разработке моделей
3. Задачи моделирования бизнес-процессов
4. Структурное моделирование БП
29

30. Цели создания моделей деятельности предприятия

Подготовка к внедрению корпоративной
информационной системы
Проведение реорганизации деятельности
предприятия (реинжиниринг)
Подготовка предприятия к сертификации по
стандартам ISO 9000
30

31. 1. Моделирование – основа проектирования ИС

31

32.

Процесс разработки ИС - процесс пост роения и
последоват ельного преобразования ряда
согласованных моделей на всех этапах жизненного
цикла ИС.
Модели:
организации,
деятельности организации,
требований к ИС,
проекта ИС,
требований к приложениям и т.д.
32

33. Виды моделей

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

34. Организационно-функциональная модель

Функция – это обособленный вид деятельности
компании. Функции выполняются постоянно.
34

35. Шаблон распределения функций по организационным звеньям

35

36. Потоковая процессная модель

36

37. 2. Основные подходы к разработке моделей

37

38. Цикл реструктуризации

Продуктовая
модель
+
+
+
+
+
+
Организацион
ная модель
Функциональ
ная модель
Функциональ
ная модель
+
Проверка на
соответствие
+
+
+
+
+ +
+
+
+
+
38

39. Фрагменты организационно-функциональной модели – основные функции

39

40. Фрагменты организационно-функциональной модели – организационная структура

40

41. Анализ организационно-функциональной модели средствами матричных проекций

41

42.

Функции
Агрегированные функции
Детализированные функции
+
+
+
+
+
+
+
+
+
+
+
+
Сотрудники
Подразделения
Организация
+
+
+
+
+
42

43. 3. Задачи моделирования бизнес-процессов

43

44. Определение бизнес-процесса

Под бизнес-процессом понимается деятельность предприятия
или его подразделения, имеющая ценность для клиента (клиент
– внешний заказчик или другое подразделение предприятия).
Получение товара по заказу
Прием заявки
Проверка
наличия
Выписка
счета
Контроль
платежа
Доставка
товара
Отдел
продаж
Склад
Бухгалтерия
Бухгалтерия
Транспортный
отдел
Бизнес-процесс - одна или несколько связанных работ или процедур, в совокупности
реализующих некоторую цель производственной и непроизводственной деятельности в
рамках определенной организационной структуры.
44

45. Обобщенная модель бизнес-процесса

Организация
Подразделение
Работник
Ресурсы:
Вход
Бизнеспроцессы
• Сырье
• Промежуточная
продукция
• Информация
• Деньги
Преобразование
ресурсов,
добавляющее
стоимость
Выход
Продукты:
• Топливо
• Прибор
•Счет-фактура
• Промежуточная
продукция
• Информация
Бизнес-процесс – модель преобразования сущностей типа
«вход-выход», рассматриваемая как работа по реализации
предписываемой функции
45

46. Задачи моделирования бизнес-процессов

Описание выполняемых системой функций
Описание отношений между данными
Описание динамического поведения
системы
46

47. Технологии и инструментальные средства моделирования бизнес-процессов.

Ст рукт урный анализ – метод исследования системы,
которое начинается с общего обзора и затем детализируется, ,
приобретая иерархическую структуру со все большим числом
уровней.
Объект но-ориент ированное моделирование подразумевает описание статической структуры системы в
терминах объектов и связей между ними, а поведение системы
описывается в терминах обмена сообщениями между
объектами. Каждый объект обладает своим собственным
поведением, моделирующим поведение объекта реального
мира.
Технология Aris – управляемые событиями модели
Программные средства: IDEF Designer, ERwin\BPwin, Oracl Designer, BPM
Workbench, Aris, Rational Rose
47

48. Карты Харрингтона (BFD – Block Flow Diagrams)

Начало
Принять
Начало
заявку
Формализуют следующие
знания о бизнеспроцессе:
Конец
Состоит из
Является частью
Следует за
Принять
Проверить
заявку
заявку
Получить
платеж
Рассчитать
платеж
Оформить
договор
Предшествует
48

49. Стандарты IDEF (Integrated Computer Aided Manufacturing DEFinition) (1981г)

IDEF0 - методология функционального моделирования. Система
отображается в виде набора взаимосвязанных функциональных
блоков.
IDEF1 – методология моделирования информационных потоков
внутри системы, позволяющая отображать и анализировать их
структуру и взаимосвязи;
IDEF1X (IDEF1 еХtended) – методология построения реляционных
структур. IDEF1X относится к типу методологий “Сущностьвзаимосвязь” (ER – Entity-Relationship) и используется для
моделирования реляционных баз данных в системе;
IDEF3 – методология документирования процессов. С помощью
IDEF3 описываются сценарий и последовательность операций для
каждого процесса.
IDEF4 – методология построения объектно-ориентированных
систем.
49

50. 4. Структурное моделирование БП

50

51. Основные принципы структурного моделирования

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

52. Функциональная модель SADT(Structured Analysis and Design Teqnique) (IDEF0)

(Нотация Росса)
отображает действия объекта и связи между этими действиями
Управление
Вход
Функция
Выход
Механизм
Модель обеспечивает отделение функций от организационной
структуры.
52

53. Декомпозиция функциональных диаграмм

функция
Контекстная диаграмма определяет все
функции, входы и выходы, которые могут
появиться на диаграммах нижних уровней
А0
Каждая подфункция может содержать
только те элементы, которые входят в
исходную функцию.
Подфункция
Подфункция1 Выход
А1
Подфункция 2
Подфункция 1
А2
Управление
Выход
Подфункция 3
Вход А3
53

54. Контекстная диаграмма

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

55. Перенос контекста на декомпозицию

Продажа,
маркетинг
Сборка,
тестирование
55

56. декомпозиция

56

57. Преобразование типов стрелок

Выход
Управле
ние
Выход
Вход
Появление новых стрелок, отсутствующих на родительской диаграмме, отображается 57
«туннелем»

58. Декомпозиция родительской диаграммы А2

Подфункция 2
А2
А21
А22
А23
А24
58

59. Ограничения сложности IDEF0-диаграмм

Ограничение количества функциональных блоков на
диаграмме: три-семь. Верхний предел (семь)
обусловлен физиологическими возможностями
восприятия информации человеком и заставляет
разработчика использовать иерархии при описании
сложных предметов. Нижний предел (три) гарантирует,
что на соответствующей диаграмме достаточно деталей,
чтобы оправдать ее создание.
Ограничение количества подходящих к одному
функциональному блоку (выходящих из одного
функционального блока) интерфейсных дуг четырьмя.
Для моделирования бизнес-функции обычно достаточно 2-3 уровней
детализации.
Общее число уровней в модели обычно не превышает 6-7.
59

60. Оценка бизнес-процессов

Функционально-стоимостной анализ АВС (Activity Based
Costing) – методика определения характеристик товаров и
услуг на базе действий и ресурсов, задействованных во всех
бизнес-процессах предприятия
Этапы АВС-анализа:
Формирование перечня ресурсов и стоимостных объектов
(«центров затрат»)
Определение затрат на выполнение бизнес-задач (расходы
ресурсов – прямые затраты материалов и труда, косвенные
затраты труда и накладные расходы)
Определение затрат на стоимостные объекты (товары,
услуги, обслуживание и пр.) на основе составляющих бизнес60
задач