Файл: Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы.pdf

• принцип «разделяй и властвуй» - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
• принцип «иерархического упорядочивания» - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

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

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

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

• SADT (Structured Analysis and Design Technique) - модели и соответствующие функциональные диаграммы;
• DFD (Data Flow Diagrams) - диаграммы потоков данных;
• ERD (Entity-Relationship Diagrams) - диаграммы «сущность-связь».

Глава 2. Анализ методологий структурного проектирования

2.1 Метод функционального моделирования SADT (IDEF0)

Методология SADT (Structured Analisys and Design Technique - технология структурного анализа и проектирования) разработана Дугласом Т. Россом в 1969-1973 годах. Технология изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения. SADT - одна из самых известных и широко используемых методик проектирования. Новое название методики, принятое в качестве стандарта - IDEF0 (Icam DEFinition) - часть программы ICAM (Integrated Computer-Aided Manufacturing - интегрированная компьютеризация производства), проводимой по инициативе ВВС США.

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (поток работ).

Стандарт IDEF0 был разработан в 1981 году в США департаментом Военно-воздушных сил для автоматизации промышленных предприятий. В процессе разработки программного обеспечения разработчики столкнулись с необходимостью разработки новых методов анализа бизнес-процессов. В результате появилась методология функционального моделирования IDEF0, в которой для анализа применяются специальные нотации IDEF0.

Функциональная модель IDEF0 представляет собой набор блоков, каждый из которых представляет собой «черный ящик» со входами и выходами, управлением и механизмами, которые детализируются (декомпозируются) до необходимого уровня. Наиболее важная функция расположена в верхнем левом углу. А соединяются функции между собой при помощи стрелок и описаний функциональных блоков. При этом каждый вид стрелки или активности имеет собственное значение. Данная модель позволяет описать все основные виды процессов, как административные, так и организационные.

Стрелки могут быть:

• Входящие – вводные, которые ставят определенную задачу.
• Исходящие – выводящие результат деятельности.
• Управляющие (сверху вниз) – механизмы управления (положения, инструкции и пр).
• Механизмы (снизу вверх) – что используется для того, чтобы произвести необходимую работу.

Входящие и исходящие стрелки точнее было бы называть вводящими и выводящими, так как по-английски они называются Input и Output соответственно. Но особенности перевода и привычные названия выглядят уже так, как сложилось. И все же для правильного понимания терминов важно помнить их значение в данном случае. Это подтверждается еще и тем, что данная нотация создана прежде всего для разработки ПО, и термины переводить правильнее в этой точки зрения.

Стрелки подписываются при помощи имен существительных (опыт, план, правила), а блоки – при помощи глаголов, т.е. в них описываются действия, которые производятся (создать товар, заключить договор, произвести отгрузку).

IDEF0 – это очень простой и одновременно наглядный язык описания бизнес-процессов. С помощью этого стандарта возможна передача информации между разработчиками, консультантами и пользователями. Стандарт очень тщательно разрабатывался, он удобен для проектирования, универсален. Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д.

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

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

Базовые требования стандарта IDEF0:

1. В левом верхнем углу всегда – главный элемент.
2. Все элементы должны иметь входящие и исходящие стрелки, так как для выполнения необходимо что-то получить на входе (заказ, поставленную задачу), а после обработки на выходе необходимо передать готовый продукт. Входящие стрелки всегда слева, исходящие – справа.
3. Сверху – управляющие элементы, снизу – механизмы, необходимые для выполнения процесса.
4. Если на одном листе (экране) располагается несколько блоков, каждый последующий располагается справа и ниже предыдущего.
5. Необходимо стремиться создавать схемы таким образом, чтобы пересечение стрелок было сведено к необходимому минимуму.

Стандарт IDEF0 включает в себя также общепринятые обозначения, правила, требования к блокам диаграмм, имеет собственную семантику.

Выгоды использования IDEF0

• Самая первая выгода очевидна – это наглядность. Проектировщик сам начинает понимать, как работает та или иная система, и может также наглядно пояснить, где в этой системе «тонкие места» и какие решения помогут избавиться от них.
• Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины.
• Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема — это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате аналитик получает инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
• Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.

2.2 Метод моделирования процессов IDЕF3

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

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

В общем случае, процесс – это упорядоченная последовательность действий. Следовательно, процессная модель IDEF3 позволяет:

• Отразить последовательность процессов;
• Показать логику взаимодействия элементов системы.

Цель IDEF3 - дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также объекты, участвующие совместно в одном процессе.

Основными элементами IDEF3-модели являются:

1) единицы работ;

2) связи;

3) перекрестки;

4) объекты ссылок.

Единица работ (UOW, Unit of Work) является центральным компонентом модели. Связи показывают взаимоотношения работ. Связи однонаправлены и могут быть направлены куда угодно. Обычно диаграммы рисуют таким образом, чтобы связи были направлены слева направо Различают 3 типа связей:

• Старшая стрелка;
• Стрелка отношений;
• Поток объектов.

Связь типа «временное предшествование» - Precedence. Соединяет единицы работ Показывает, что работа-источник должна быть закончена прежде, чем начнется работа-цель

Связь типа нечеткое отношение – Relational. Изображается в виде пунктирной линии, используется для изображения связи между единицами работ, а также между единицами работ и объектами ссылок

Стрелка, изображающая поток объектов - Object Flow. Применяется для описания того факта, что объект используется в двух и более единицах работ, например, когда объект порождается в одной работе и используется в другой

Перекрестки (соединения) используются для отображения логики взаимодействия стрелок при их слиянии или разветвлении, для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния и разветвления стрелок. Перекрестки не могут быть одновременно использованы для слияния и разветвления стрелок. Все перекрестки на диаграммах нумеруются, каждый номер имеет префикс J. В отличие от других методологий (IDEF0, DFD) стрелки могут сливаться или разветвляться только через перекрестки.

Декомпозиция работ в IDEF3 В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на текущей диаграмме.

2.3 Моделирование потоков данных DFD

DFD – общепринятое сокращение от англ. data flow diagrams – диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) – один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Непосредственно DFD нотация состоит из следующих элементов:

1. Процесс (англ. Process), т.е. функция или последовательность действий, которые нужно предпринять. чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жестко определенный синтаксис, так как они могут быть исполняемыми. Но все же определенных правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми.

2. Внешние сущности (англ. External Entity). Это любые объекты, которые не входят в саму систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Это может быть человек, внешняя система, какие-либо носители информации и хранилища данных.