Файл: Разработка регламента выполнения процесса «Учет реализации лекарственных препаратов через аптечную сеть (Основные понятия процессного подхода).pdf

Для проведения анализа и реорганизации бизнес-процессов предназначено CASE-средство верхнего уровня AllFusion Process Modeler (BPwin), поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель TO-BE). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как «внешняя ссылка» и «хранилище данных», что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент «перекресток», что позволяет описать логику взаимодействия компонентов системы.

На основе модели BPwin можно построить модель данных. Для построения модели данных Computer Associates предлагает мощный и удобный инструмент - AIIFusion ERwin Data Modeler (ERwin). Хотя процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому полностью не автоматизирован, Computer Associates предлагает удобный инструмент для облегчения построения модели данных на основе функциональной модели - механизм двунаправленной связи BPwin - ERwin (стрелка 1 на рис. 1.2). ERwin имеет два уровня представления модели - логический и физический, причем модель данных может содержать как оба этих уровня, так и только один из них. Модели, содержащие только один уровень, могут быть синхронизированы, что особенно удобно при создании гетерогенных информационных систем. На логическом уровне данные не связаны с конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных - это, по существу, отображение системного каталога, который зависит от конкретной реализации СУБД. Создание одного логического уровня и нескольких соответствующих ему физических позволяет вести одновременную разработку баз данных для нескольких СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования баз данных (стрелка 2, рисунок 1.2). Это означает, что по модели данных можно сгенерировать схему базы данных или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования.

Для больших, содержащих сотни таблиц моделей данных существенной проблемой становится поиск и исправление ошибок. Решение этой проблемы вручную - слишком трудоемкая задача, которая может недопустимо затянуть выполнение проекта. AllFusion Data Model Validator (ERwin Examiner) - основанный на базе знаний инструмент, который позволяет анализировать структуру баз данных с целью выявления недочетов и ошибок проектирования. ERwin Examiner дополняет функциональность ERwin, автоматизируя трудоемкую задачу поиска и исправления ошибок. ERwin Examiner может использовать в качестве источника метаданных готовую модель ERwin, DDL - скрипт или провести обратное проектирование базы данных (стрелки 3 и 4 на рисунке 1.2).

При проектировании больших ИС ключевой проблемой является создание качественной документации по моделям. BPwin и ERwin позволяют генерировать разнообразные отчеты, которые могут быть использованы для анализа и документирования моделей. Отчеты могут быть экспортированы в распространенные форматы - текстовый, MS Office, HTML и др. Результаты экспорта могут быть использованы для создания отчетов с помощью средств других производителей, например Crystal Reports. BPwin поддерживает также экспорт и импорт модели в текстовый файл формата IDL, который является стандартом для экспорта и импорта моделей IDEF0, позволяет разрабатывать функциональные модели одновременно инструментальными средствами различных производителей.

Создание современных ИС, основанных на широком использовании распределенных вычислений, объединении традиционных и новейших информационных технологий, требует тесного взаимодействия всех участников проекта: менеджеров, бизнес-аналитиков и системных аналитиков, администраторов баз данных, разработчиков. Для этого использующиеся на разных этапах и разными специалистами средства моделирования и разработки должны быть объединены общей системой организации совместной работы. Фирма Computer Associates предлагает систему ModelMart - хранилище моделей, к которому открыт доступ для участников проекта создания ИС (стрелка 5 на рисунке выше).

1.2 Этапы разработки регламента процесса

После выбора Case-средства разработки регламента процесса, необходимо создать техническое задание

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

На основе утвержденного технического задания начинается стадия «Техно-рабочего проектирования», включающая два этапа работ: техническое и рабочее проектирование.

Техническое проектирование содержит:

- разработку общесистемных проектных решений (уточняются цели создания ИС и выполняемые ею функции, устанавливается ее взаимосвязь с другими системами); уточняется и изменяется организационная структура; разрабатывается функциональная архитектура ЭИС;

- разработку локальных проектных решений, к числу которых относятся следующие операции:

-   разработка «Постановки задачи» (рис. 1.3), для задач, входящих в состав функциональных подсистем;

- проектирование форм входных и выходных документов, макетов экранных форм документов, классификаторов экономической информации;

-  проектирование состава и структур файлов информационной базы;

-  проектирование внемашинной и внутримашинной технологии решения каждой задачи;

- уточнение состава технических средств.

Рисунок 1.3 - Содержание «Постановки задачи»

В состав «Характеристика задачи» входят:

- описание цели автоматизации решения задачи (получение эк. эффекта в сфере управления процессами системы, снижение стоимостных и трудовых затрат на обработку информации, повышение качества и достоверности получаемой информации, оперативности её обработки и т.д.;

- описание экономической сущности решаемой задачи, т.е. состава экономических показателей, рассчитываемых при ее решении, документов, куда заносятся эти показатели;

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

- описание алгоритма – формализованное описание входных и результатных показателей, перечень формул расчета, описание математической модели, экономико-математических методов  и т.д.;

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

Наиболее ответственной работой, выполняемой на этапе «Рабочего проектирования» является «Кодирование и составление программной документации», в состав которой входит:

- описание программ;

- спецификация программ;

- тексты программ;

- контрольные примеры;

- инструкции для программиста, оператора и пользователя.

В состав «Рабочего проекта» входит технологическая документация, включающая технологические карты разрабатываемые на процессы обработки информации при решении задач, и инструкционные карты, составляемые на каждую технологическую операцию. Технологическая документация разрабатывается в соответствии с ГОСТ 3.11.09 – 82 «Система технологической документации. Термины и определения основных понятий».

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

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

В качестве примера рассмотрим одну из широко используемых систем такого проектирования – SADT (Structured Analysis and Design Technique – технология структурного анализа и проектирования) – это графические обозначения и подход к описанию систем.

SADT создана для описания системы и её среды до определения требований к программному обеспечению и др. Она облегчает описание и понимание искусственных систем средней сложности. В SADT используется графический язык и набор процедур анализа для понимания системы прежде, чем можно представить себе её воплощение. Она, как правило, применяется на ранних этапах процесса создания системы, который часто называют «жизненным циклом системы».

SADT-модель – иерархически организованная совокупность диаграмм. Диаграммы обычно состоят из трёх-шести блоков, каждый из которых потенциально может быть детализирован на другой диаграмме. Каждая диаграмма представляет некоторую законченную часть всей модели.

Каждый блок может пониматься как отдельный тщательно определённый объект. Разделение такого объекта на его структурные части (блоки и дуги, составляющие диаграмму) называется декомпозицией.

Метод SADT реализован в виде стандарта IDEF0.

На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области; следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации.

Наиболее удобным языком моделирования бизнес-процессов является 1DEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT-Structured Analysis and Design Technique. (Подробно методология SADT излагается в книге Дэвида А. Марка и Клемента Мак-Гоуэна «Методология структурного анализа и проектирования SADT») В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0. Подробные спецификации на стандарты IDEF можно найти на сайте http://www .idef.com.

В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.

Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами; другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие.