1. Моделирование БП, методология SADT – как
основа моделирования процессов
Под визуальной моделью БП понимается некоторое графическое
описание в виде совокупности схем или диаграмм, отвечающие требованиям нотации
выбранного графического языка.
Наиболее распространенными методологиями и стандартами являются:
1.
SADT (Structured Analysis and Design Technique) – методология структурного анализа и проектирования.
2.
IDEF – серия стандартов,
основанная на методологии SADT.
3. ARIS (Architecture of Integrated Information Systems).
4. UML (United Modeling Language).
Методы построения моделей БП делятся на структурные (SADT, IDEF,
ARIS) и объектно-ориентированные (UML).
Методология SADT
Это структурный метод исследования системы или процесса, который
начинается с общего обзора объекта исследования и затем предполагает его
последовательную детализацию. Структурные методы имеют 3 основные особенности:
-
Расчленение сложной
системы на части, представляемые как черные ящики, где каждый ящик реализует
определенную функцию.
-
Иерархическое упорядочение выделенных элементов системы с определением
взаимосвязей между ними.
-
Использование графического представления взаимосвязей элементов
системы.
2. Стандарт IDEF0
Методология
функционального моделирования IDEF0 основана на технологии структурного анализа SADT. IDEF0 – технология описания системы в целом, как множества взаимосвязанных
действий или функций. Основная идея стандарта: построение древовидной
функциональной модели деятельности, предусматривающей переход от общего к частному.
В стандарте
реализуются 3 базовых принципа моделирования БП:
-
принцип
функциональной декомпозиции, представляющий собой способ моделирования типовой
ситуации, когда любые функции могут быть разбиты на более простые действия
-
принцип
ограничения сложности – количество блоков на диаграмме должно быть не менее 2 и
не более 6 (8)
-
принцип
контекстной диаграммы – моделирование делового процесса начинается с построения
контекстной диаграммы, в которой отображается только один блок – главная
функция моделируемой системы.
Имена функций в IDEF0 подбираются с использованием глаголов
или отглаголенных существительных.
Для типизации
категорий информации на IDEF0 диаграммах используются ICOM коды, обозначающие:
3. Стандарт IDEF3
Позволяет
фиксировать и структурировать описание работы системы, т.е. описывать сценарий и последовательность операций
каждого процесса. Эта технология хорошо приспособлена для сбора данных
требующихся для проведения структурного анализа системы.
Стандарт IDEF3 позволяет решать следующие задачи:
-
документировать
имеющиеся данные о технологии процесса;
-
определять и анализировать точки влияния
потоков сопутствующего документооборота на сценарий процессов;
-
определять
ситуации, в которых требуется принятие решения, влияющего на ЖЦ процесса;
-
содействовать
принятию оптимальных решений при реорганизации процессов;
-
разрабатывать
имитационные модели процессов по принципу “как будет, если …”
Для системного
аналитика необходимо понимать цели моделирования – набор вопросов, ответами на
которые будет служить модель, граница моделирования и целевая аудитория (для
кого разрабатывается модель).
Единица работы (действие):
Соединения: Соединяют или разбивают внутренние потоки,
используются для описания ветвления процесса.
Обозначение |
Наименование |
Смысл в случае слияния стрелок (Fan-in Junction) |
Смысл в случае разветвления стрелок
(Fan-out Junction) |
|
|
Asynchronous AND |
Все предшествующие процессы должны быть
завершены |
Все следующие процессы должны быть запущены |
|
|
Synchronous AND |
Все предшествующие процессы завершены
одновременно |
Все следующие процессы запускаются одновременно |
|
|
Asynchronous OR |
Один или несколько предшествующих процессов
должны быть завершены |
Один или несколько следующих процессов
должны быть запущены |
|
|
Synchronous OR |
Один или несколько предшествующих процессов
завершаются одновременно |
Один или несколько следующих процессов
запускаются одновременно |
См выше /*Здесь один возможен вариант,
не готов к аудиту, можно сдать кредит (Если здесь поставить простое «ИЛИ»
(О), то право выбора за студентом).*/ |
|
XOR (Exclusive OR) |
Только один предшествующий процесс завершен |
Только один следующий процесс запускается |
|
4.
Стандарт DFD
(Data Flow Diagrams)
Диаграммы потоков данных являются основным
средством моделирования функциональных требований проектируемой системы. С их
помощью требования разбиваются на функциональные компоненты и представляются в
виде сети, связанной потоками данных.
Представление
потока данных обеспечивает отражение таких физических характеристик системы,
как движение объектов, хранение объектов, источники и потребители объектов.
В стандарте
используются 2 нотации: по методу Гейна-Сарсона и по методу Йордана (наиболее
употребим а).
В названии объектов используются имена
существительные.
Контекстная DFD диаграмма состоит из одного функционального блока и
нескольких внешних сущностей.
Элементы нотации:
1. Функциональные
блоки – моделируют функцию, которая преобразует сырье в какую-либо продукцию.
2. Внешняя сущность – материальный предмет или физическое
лицо, представляющее собой источник или приемник информации (заказчики,
персонал, поставщики, клиенты).
3. Потоки данных – показывают как объекты реально перемещаются
от одного действия к другому и определяют информацию, передаваемую через
некоторое соединение от источника к приемнику. В этой нотации допускаются
двойные стрелки.
Допускается ветвление и объединение
стрелок. Стрелки могут быть разбиты на части, при этом каждый получившийся
сегмент может быть переименован таким образом, чтобы показать декомпозицию
данных переносимых конкретным потоком.
4.
Хранилища
данных (накопители) –
определяют данные, которые буду сохраняться между процессами на определенных
участках. Накопитель физически может
быть реализован в виде ящика картотеки. Файла и т.д.
Если потоки
данных представляют объекты в процессе их передвижения, то хранилища данных моделируют
их во всех остальных состояниях.
Диаграммы DFD стоятся с использованием подхода
аналогичного структурному методу анализа и проектирования SADT, вначале
стоится модель физической реализации существующей системы, которая
используется в настоящее время.
Затем создаются
логическая модель для моделирования основных требований реальной системы. После этого формируется новая логическая
модель для отражения основных параметров
разрабатываемой системы. Затем создается новая физическая модель, реализующая логическую
модель новой системы. Пример: DFD-диаграмма процесса:
5. Организация планирования ИС
Стратегическое
планирования ИС определяется стратегией бизнеса предприятия.
Причины
необходимости планирования ИС:
-
динамика
рынка ИС требует постоянного анализа возможностей и рисков новых ИТ
-
рост
объема инвестиций в ИС требуют
обоснование бюджета финансирования ИС
-
длительность
подготовки квалифицированных кадров для новых ИТ.
Для процесса
стратегического планирования ИС (СПИС) характерны следующие этапы:
1.
Постановка задача: для какой части предприятия должна планироваться
система, в каком виде и кем, что от этого предприятия должно получить и когда.
2.
Анализ условий:
2.1. Анализ окружения предприятия
(клиентура, рынки продукции, конкуренция) и вытекающие из этого рынка риски,
шансы и требования.
Документация анализа может включать:
1.
спецификацию имеющихся и ожидаемых требований законодателей,
партеров по рынку, партнеров-смежников
2.
общий обзор предложений на рынке ИТ
3.
описание шансов и риска на основе анализа состояния ИТ и прогноза
ИТ развития
4.
диагноз риска и его “терапия”
2.2. Анализ внутренней ситуации:
изучаются внутренние условия предприятия (структура и процессы производства,
финансы, ресурсы) и устанавливаются сильные и слабые стороны / сферы ИС.
2.2.1. Анализ начинается со спецификации
всех ИС, т.е. изучается степень проникновения ИТ.
2.2.2. Распределение ресурсов: включаются
работники сферы обработки информации, технические и программные средства,
бюджет сферы обработки информации.
3.
Разработка стратегии:
3.1. Стратегия в области архитектуры
приложений: разрабатывается концептуальная модель данных для всей организации в
целом.
3.1.1. Разработка
единого для всего предприятия базиса данных.
1.1.2.
Формирование спектра приложений.
3.2. Стратегия в области ресурсов:
планируются по направлениям:
5.
персонал сферы обработки информации: определяется число,
квалификация и затраты на работников сферы обработки информации и организации
труда,
6.
ИТ – планируются такие позиции как использование собственных
разработок или покупных программных средств; разработка технологической
архитектуры и средств автоматизации.
7.
Бюджет сферы – внутренне распределение средств, детальный обзор
затрат для области развития, обслуживания, эксплуатации и использования ИС и
персонала сферы ИС.
6. Методы оценки эффективности ИТ
Позволяют установить причинно-следственные связи между ИТ и
финансовыми показателями предприятия:
1) Методика использования выгод информации: ATE (Хаббард Д.) – Applied Information Economics.
Устанавливает шкалы измерения традиционным нематериальным активам (уровень
удовлетворенности пользователей, их стратегическая ориентация) в сфере развития
ИТ и затем применяет для определения ценности данных, информации, знаний,
различные инструментальные средства.
2) Сбалансированная оценочная ведомость (Balanced Scorecard, BSC).
Предназначена для выявления прямых связей между бизнес стратегией
и финансовыми показателями ИТ за счет контроля 4-х различных аспектов
деятельности.
Для финансовой оценки эффективности автоматизации предприятия необходимо выделить
доходные статьи:
·
Прямое
снижение расходов
·
Прямое
увеличение дохода
·
Увеличение
оборачиваемости средств
·
Увеличение
объема продаж
·
Повышение
удовлетворенности клиентов
·
Снижение
складских запасов.
Для оценки
эффективности ИТ проектов в соответствии
с методологией BSC развитие предприятия рассматривается в
следующих аспектах:
Критерии оценки в методологии BSC взаимосвязаны и представляют собой
причинно-следственную цепочку стратегий. Для оценки выполнения факторов успеха
предлагается набор ключевых показателей эффективности, которые одновременно
являются элементами сбалансированной системы показателей.
Для того чтобы качественно оценить эффективность
проекта в соответствии с методологией рекомендуется разрабатывать SCORE-модель.
7. Риски автоматизации
Проектные риски включают следующие группы в зависимости от источника
возникновения:
·
Природно-климатические
(в т.ч. стихийные и экологические)
·
Технические:
отказы машин и оборудования, снижение качества продукции
·
Производственные:
нарушение технологии, остановки и
перерывы производства, задержки поставок сырья.
·
Экономические:
рост издержек, увеличение цен на сырье, инфляция, …
·
Рыночные:
падение цен на продукцию, уменьшение объема сбыта, рост конкуренции.
·
Финансовые:
кредитные, валютные, процентные риски, связанные с финансовыми и кредитными операциями.
·
Социальные:
забастовки, увеличение социальных расходов.
·
Политические:
изменение законодательства, административные ограничения, смена приоритетов.
·
Инновационные:
риски недостижения ожидаемых результатов научных и инженерных разработок.
Методы
анализа и прогнозирования риска:
Подразделяются на
2 вида: качественные и количественные.
Главная задача качественного
анализа – определение факторов, этапов и работ, при выполнении которых
возникает риск. Т.е. установление потенциальных зон риска, после чего зоны идентифицируются.
Количественный анализ применяется для определения
численных размеров риска. Наиболее распространенными методами является анализ
чувствительности, анализ моделей (метод Монте-Карло), метод PERT (project evaluation and review technique).
Методы
снижения рисков (минимизация, защита).
·
Избежание
– простое уклонение от деятельности или обстоятельств содержащих риск;
·
Передача
– перевод ответственности за риск другой стороне, прежде всего страховой компании;
·
Сокращение
– проведение собственных специальных мер по ограничению размеров риска.
Для снижения
степени риска применяются следующие способы защиты: