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

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

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

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

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

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

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

Соответствие процессов ГОСТ 34. 601 -90; "э. X. Y" - этап Y стадии X ISO/IEC 12207: 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 и изделия и процессах ISO 12207. программный продукт (в контексте создания системы). 7

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

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

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

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

Последовательности задач 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

Последовательности задач 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандарты IDEF (Integrated Computer Aided Manufacturing DEFinition) (1981 г) ØIDEF 0 - методология функционального моделирования. Система отображается в виде набора взаимосвязанных функциональных блоков. ØIDEF 1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи; ØIDEF 1 X (IDEF 1 е. Хtended) – методология построения реляционных структур. IDEF 1 X относится к типу методологий “Сущностьвзаимосвязь” (ER – Entity-Relationship) и используется для моделирования реляционных баз данных в системе; ØIDEF 3 – методология документирования процессов. С помощью IDEF 3 описываются сценарий и последовательность операций для каждого процесса. ØIDEF 4 – методология построения объектно-ориентированных систем. 48

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

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

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

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

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

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

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

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

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

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

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