кандидат технических наук, доцент Грекул Владимир Иванович Учебный курс Проектирование информационных систем Лекция 2

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

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

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

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

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

7 Соответствие процессов ГОСТ ; "э.X.Y" - этап Y стадии X ISO/IEC12207: Oracle CDM;Примечание э.5.3 ТП, э.7.3 ВД.1) Процесс приобретения разработчиком нетв ГОСТ это приобретение планируется нет2) Процесс поставкинетCDM содержит процесс CV, Все этапы ГОСТ кроме 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.

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

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

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

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

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 – тестирование принятых решений

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 – запуск новой системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

28 Evolutionary model (эволюционная модель) Разработка осуществляется при постоянном уточнении требований

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

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

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

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

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

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

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

36 Потоковая процессная модель Определяет требования к ИС в части обеспечения деятельности предприятия

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

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

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

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

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

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

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

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

45 Задачи моделирования бизнес-процессов функций Описание выполняемых системой функций данными Описание отношений между данными поведения Описание динамического поведения системы

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

47 Принять заявку Карты Харрингтона (BFD – Block Flow Diagrams) Начало Принять заявку Проверить заявку Рассчитать платеж Оформить договор Получить платеж Конец Формализуют следующие знания о бизнес- процессе : Состоит из Является частью Следует за Предшествует

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

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

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

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

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

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

54 Перенос контекста на декомпозицию Продажа, маркетинг Сборка, тестирование

55 декомпозиция

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

57 Декомпозиция родительской диаграммы А2 Подфункция 2 А2 А21 А22 А23 А24

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

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