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

ВВЕДЕНИЕ

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

Разнообразные интерьеры аптек поражают даже воображение самых требовательных клиентов. Постоянно растущая конкуренция заставляет владельцев аптек искать новые способы для завоевания признания избалованной публики. Часто такие эксперименты приводят к очень интересным результатам. В последнее время все большее распространение получают так называемые аптечные супермаркеты, в которых можно рассмотреть товар со всех сторон, ознакомиться с инструкцией по применению и, в результате, сделать наиболее осознанный выбор.

Объектом и предметом исследования является процесс реализации лекарственных препаратов в аптечной сети.

Цель работы - разработка информационной системы процесса реализации лекарственных препаратов в аптечной сети.

Методы исследования: анализ предметной области и полученных результатов и их систематизация, анализ данных.

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

- Провести анализ и описание предметной области;

- Создать хранилище данных;

- Обеспечить систему функцией контроля правильности оформления документов;

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

- Обеспечить максимальную безопасность данных в системе;

- Разработать интерфейс пользователя, учитывающий особенности специфики работы пользователя;

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

---

1. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ РАЗРАБОТКИ РЕГЛАМЕНТА БИЗНЕС-ПРОЦЕССОВ

1.1Основные понятия процессного подхода

Для того чтобы приступить к реализации курсового проекта «Разработка регламента выполнения процесса «Учет реализации лекарственных препаратов через аптечную сеть», необходимо разобраться в теоретических аспектах. Перечислим основные понятия процессного подхода.

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

Процесс проектирования - представляет собой преобразование входной информации об объекте и методах проектирования в проект ИС в соответствии с ГОСТом.

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

Субъектами проектирования являются проектная организация и организация заказчик.

Одной из основных проблем, которые приходится решать при создании больших и сложных систем любой природы, в том числе и ПО, является проблема сложности. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера, и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй» {divide et impera), иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделить (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня иметь дело только с ней, а не со всеми остальными частями системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем ПО. Понятие «правильная» по отношению к декомпозиции означает следующее:

---

- количество связей между отдельными подсистемами должно быть минимальным (принцип «слабой связанности» — Low Coupling);

- связность отдельных частей внутри каждой подсистемы должна быть максимальной (принцип «сильного сцепления» - High Cohesion).

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

- каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);

- каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

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

Термин CASE-средства (Computer Aided Software Engineering) означает программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы.

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

- подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

- широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

Наибольшая потребность в CASE-средствах – начальные этапы анализа и спецификации требований. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки.

---

Преимущества CASE-технологии по сравнению с традиционной технологией оригинального (ручного) проектирования сводятся к следующему:

- улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации;

- возможность повторного использования компонентов разработки;

- поддержание адаптивности и сопровождения ЭИС;

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

- освобождение разработчиков от рутинной работы по документированию проекта, за счет использования встроенного документатора;

- возможность коллективной разработки ЭИС в режиме реального времени.

CASE-системы классифицируются по следующим признакам:

1. по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);

2. по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными;

3. по степени интегрированности: tools (отдельные локальные средства), toolkit (набор интегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных – репозиторием);

4. по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ЛВС, ГВС и смешанного типа;

5. по режиму коллективной разработки проекта: на поддерживающие коллективную разработку, ориентированные на режим реального времени и на режим объединения подпроектов;

6. по типу операционной системы (ОС): Windows, UNIX, OS/2 и др.

Архитектура CASE-средства представлена на рисунке 1.1

Рисунок 1.1- Архитектура CASE-средства

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

Репозиторий содержит информацию об объектах проектируемой ЭИС и взаимосвязях между ними, все подсистемы обмениваются данными. В репозитории хранятся описания следующих объектов:

- проектировщиков и их права доступа к различным компонентам системы;

- организационных структур;

- диаграмм, и связей между ними;

- компонентов диаграмм;

---

- структур данных;

- программных модулей;

- процедур;

- библиотеки модулей и т.д.

Графический редактор позволяет выполнять следующие операции:

- создавать элементы диаграмм, их взаимосвязи и описания;

- задавать описания элементов диаграмм  и связей между ними;

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

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

Верификатор – служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС.

Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов, которые строятся по нескольким признакам (по времени, автору, элементам диаграмм, диаграмме или проекту в целом).

Администратор проекта – это инструменты, необходимые для выполнения таких функций, как:

- инициализация проекта:

- задания начальных параметров проекта;

- назначения и изменения прав доступа к элементам проекта;

- мониторинга выполнения проекта.

Сервис – набор системных утилит по обслуживанию репозитория (архивация данных, восстановления данных и создания нового репозитория).

Большинство существующих CASE – систем ориентировано на автоматизацию проектирования ПО и основано на методологиях структурного или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, и т.д.

Одним из наиболее популярных CASE-средств, поддерживающих методологию структурного (функционального проектирования) является пакет AllFusion Modeling Suite, выпущенный компанией Computer Associates.

В этот пакет входит 5 продуктов:

1.  AllFusion Process Modeler .AllFusion Process Modeler является новым именем хорошо известного BPwin.

2.  AllFusion ERwin Data Modeler - инструмент создания моделей данных и генерации схем баз данных.

3.  AllFusion Data Model Validator - система поиска и исправления ошибок модели данных.

4.  AllFusion Model Manager  Система организации коллективной работы, хранилище моделей BPwin и ERwin.

5.  AIIFusion Component Modeler -инструмент создания объектных моделей.

Рисунок 1.2 - Общая схема взаимодействия инструментальных средств AllFusion Modeling Suite

---