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

Выбор средств / методологии проектирования. Выбор СУБД

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

В качестве системы управления базами данных применим реляционную базу данных (РБД). Хотя существуют СУБД, построенные по другим принципам, наибольшее распространение в настоящее время получили именно реляционные базы. Реляционная модель данных основана на строгих закономерностях и хорошо разработанном аппарате реляционной алгебры.

В качестве языка программирования выбран РНР – легкий в освоении язык для быстрой разработки малых и средних Web-приложений. Он позволяет быстро разработать многомодульную программу, в которой каждый модуль отвечает за свою конечную функциональность.

Для хранения данных как нельзя лучше подойдёт СУБД MySQL – лёгкая, быстрая СУБД, в которой можно создать таблицы, хранящие все необходимые данные, и отношения между ними.

В качестве Web-сервера для связки PHP+MySQL традиционно используется Apache – проверенный и надёжный продукт.

Опишем указанные технологии более подробно.

РНР — это серверный язык создания сценариев (или стороны сервера), разработанный специально для Web. В HTML-страницу можно внедрить код РНР, который будет выполняться при каждом ее посещении. Код РНР интерпретируется Web-сервером и генерирует HTML или иной вывод, наблюдаемый посетителем страницы.

РНР — это продукт с открытым исходным кодом (Open Source). У пользователя имеется доступ к исходному коду. Его можно использовать, изменять и свободно распространять другим пользователям или организациям.

К числу конкурентов РНР относятся Perl, Active Server Pages (ASP) от Microsoft, Java Server Pages (JSP) и Allaire Cold Fusion.

PHP обладает множеством преимуществ по сравнению с этими продуктами, в числе которых:

• высокая производительность;
• наличие интерфейсов ко многим различным системам баз данных;
• встроенные библиотеки для выполнения многих общих задач, связанных с Web;
• бесплатность;
• простота изучения и использования;
• переносимость;
• доступность исходного кода.

MySQL — очень быстрая, надежная система управления реляционными базами данных (СУРБД). База данных позволяет эффективно хранить, искать, сортировать и получать данные. Сервер MySQL управляет доступом к данным, позволяя работать с ними одновременно нескольким пользователям, обеспечивает быстрый доступ к данным и гарантирует предоставление доступа только имеющим на это право пользователям. Следовательно, MySQL является многопользовательским, многопотоковым сервером. Он применяет SQL (Structured Query Language —язык структурированных запросов), используемый по всему миру стандартный язык запросов в базы данных. MySQL появился на рынке в 1996 г., но его разработка началась еще в 1979 г.

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

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

Web-сервер Apache называют самым главным сокровищем движения «Открытые программные системы». Его можно получить совершенно бес­платно. Он имеет отличные рабочие характеристики и поэтому используется более широко, чем все остальные Web-серверы вместе взятые. В настоящий момент более 65 процентов всех Web-узлов в мире созданы с использова­нием сервера Apache.

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

Достоинства Web-сервера Apache:

• модульность структуры, которая позволяет: подключать только необходимые модули, гибко регулируя со­отноше­ние между функциональностью и размером программы сервера; создавать дополнительные модули (яркий пример – модуль mod_charset, обеспечивающий обслуживание кириллических кодиро­вок);
• открытая архитектура (можно скачать как исходный код, так и от­компи­лированнный вариант);
• работоспособность под несколькими платформами: (Unix, Linux, Windows, Netware);
• бесплатное распространение;
• возможность использовать СУБД для аутентификации пользовате-лей, модифицировать сообщения об ошибках и так далее;
• поддержка IPv6.
• надёжность и гибкость конфигурации.

2.1 Моделирование бизнес-процессов

BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать деятельность предприятия с трех ключевых точек зрения:

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

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

2.1 Выбор средства для моделирования предметной области решаемой задачи

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

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

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

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

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

Проектирование физической структуры базы данных

Выходные документы и сообщения:

1. Отчет Агенты
2. Отчет Клиенты
3. Отчет Объекты страховки
4. Отчет Отчет по продажам страхования.

В программном приложении MS Access разработана структура и схема данных БД.

В режиме Конструктора созданы следующие таблицы (рис. 7):

Рисунок 7.1 Таблицы в режиме Конструктора

В программном приложении MS Access разработаны формы как объекты баз данных для каждой из таблиц БД ( рис.8).

Рисунок 8. Формы

Далее в схеме данных созданы связи между таблицами (рис. 9):

Рисунок 9. Схема данных со связями между таблицами

В программном приложении MS Access разработан запрос с параметрами диалога как объект БД., Запрос выполнен в режиме конструктора (рис.10) и в режиме таблицы (рис.11Рисунок 10. Запрос с параметром (введите объект страховки)).

Рисунок 10. Запрос с параметром (введите объект страховки)

Рисунок 11. Результат запроса с параметром

В программном приложении MS Access разработан перекрестный запрос как объект БД. Запрос выполнен в режиме конструктора (Рисунок 12 – Запрос перекрёстный в режиме Конструктора12) и в режиме таблицы (Рисунок 13 – Перекрестный запрос Агент_Объект_Количество13).

Рисунок 12 – Запрос перекрёстный в режиме Конструктора

Рисунок 13 – Перекрестный запрос Агент_Объект_Количество

В программном приложении MS Access разработался запрос с вычислением как объект БД. Запрос выполнен в режиме конструктора (Рисунок 14 – Запрос с вычисляемым полем в режиме Конструктора14) и в режиме таблицы (Рисунок 15 – Запрос Срок страховки15). Вычислен срок страховки по формуле: Срок страховки: CInt((!-!)/365*12+0,5).

Рисунок 14 – Запрос с вычисляемым полем в режиме Конструктора

Рисунок 15 – Запрос Срок страховки

В программном приложении MS Access разработан запрос на удаление записей как объект БД. Запрос выполнен в режиме конструктора (Рисунок 16 – Запрос на удаление Вида страховки16).

Рисунок 16 – Запрос на удаление Вида страховки

В программном приложении MS Access разработан запрос на создание новой таблицы с вычисляемыми полями как объект БД. Запрос выполнен в режиме конструктора (Рисунок 17 – Запрос на создание новой таблицы17). Вычислена новая цена страхования (увеличение цены на 10%) по формуле Новая цена: !*1,1

Рисунок 17 – Запрос на создание новой таблицы

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

Список литературы

Основная

1. Диго С.М. Проектирование и использование баз данных. – М.: Финансы и статистика, 1995. – 208 с.: ил.

2. Диго С.М. Создание баз данных в среде СУБД Access. М.: МЭСИ, 2000. – 105 с.: ил.

3. Верховцев А. В. Заработная плата./А. В. Верховцев — 3-е изд., перераб. и доп -М.: ИНФРА — М, 2000. — 148 с.]

4. Федеральный закон РФ № 22-ФЗ от 04.02.1999 «Об оплате труда работников федеральных государственных учреждений»

5. Трудовой кодекс Российской Федерации» от 30.12.2001 N 197-ФЗ (ред. от 03.07.2016) (с изм. и доп., вступ. в силу с 03.10.2016)

6. Политика доходов и заработной платы: Учебник/ Под ред. П.В. Савченко и Ю. П. Кокина. – М.:Юристъ, 2000

Дополнительная

1. 7. Вендров А.М. Case-технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика, 1998.
2. 8. Гейн К., Сарсон Т. Структурный системный анализ: средства и методы. Пер. с англ. М.: 3 Эй-текс, 1993.
3. 9. Горев А., Ахаян Р, Макашарипов С. Эффективная работа с СУБД. СПб.; Питер, 1997., – 700 с.
4. 10. Грачев А.Ю. Введение в СУБД Informix. – М.: ДИАЛОГ-МИФИ, 2000 – 272 с.
5. 11. Грабер М. Введение в SQL. Пер. с англ. – М.: «ЛОРИ», 1996.

12. Джексон Г. Проектирование реляционных баз данных для использования с микроэвм: Пер. с англ. – М.: Мир, 1991. – 252 с., ил.

• Разработка конфигурации «Продажи» в среде 1С:Предприятие 8.3 (Контрольный пример реализации проекта в среде 1С:Предприятие и его описание)
• ОТЛАДКА И ТЕСТИРОВАНИЕ ПРОГРАММ:ОСНОВНЫЕ ПОДХОДЫ И ОГРАНИЧЕНИЯ ( Сущность тестирования и отладки )
• Понятие науки теории государства и права
• Понятие пенсии по инвалидности (Понятие и правовое регулирование пенсии по инвалидности).
• Методы выбора проектов на примере инновационных проектов
• Совершенствование функционирования службы питания на примере гостиницы «Marriott»
• Прикладные аспекты социальной психологии
• Социально-психологический портрет современного руководителя (Лидерские качества, формируемые внутренней генной предрасположенностью)
• Социально-психологический портрет современного руководителя(Лидерские качества, формируемые внутренней генной предрасположенностью)
• Тенденции и анализ развития сетевой розничной торговли в России ( Стратегии развития торговых сетей в зарубежных странах )
• Анализ коммерческой деятельности спортивной организации на примере компании “ADIDAS”
• Коммерческая информация и ее защита (на примере ООО «Стокман»)

Разработка интерфейса и реализация проекта

Главная страница предоставляет доступ к системе «Электронная регистратура». Главная страница интерфейса пользователя представлена на рис. 7.

Рис.7. Главная страница интерфейса пользователя

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

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

Рис.8. Основное пошаговое меню

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

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

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

Рис. 9. Второй этап – выбор врача

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

Рис.10. Третий этап – просмотр расписания приема

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

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

Рис. 11. Пятый этап – печать талона

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

Рис. 12. Вид талона на печатном носителе

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

Описание предметной области. Постановка задачи

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

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

В течение года клуб организует различные походы. Каждый поход имеет свой маршрут, на который отводится определенное количество дней. По маршруту и количеству дней определяется категория сложности данного похода. Поход возглавляет инструктор, которым может быть какой-либо тpенеp или спортсмен. Он набирает группу в количестве 5-15 человек для своего похода, исходя из типа похода (пеший, конный, водный, горный) и физических данных туристов (по их занятиям в секциях: водники, спелеологи, альпинисты и другие).

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

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

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

Перечень таблиц:

1. Таблица «Туристы» (сведения о туристах): код туриста, фамилия, имя, отчество, пол, дата рождения, категория.

2. Таблица «Тренеры» (сведения о тренерах): код тренера, код секции, фамилия, имя, отчество, пол, дата рождения, возраст, категория, инструктор.

3. Таблица «Группы» (сведения о сформированных группах): код группы, код туриста, номер группы, код тренера, код секции.

4. Таблица «Секции» (сведения об имеющихся секциях): код секции, название, место проведения, дата начала, дата окончания, ФИО руководителя, дата рождения, возраст, год устройства на работу, зарплата.

5. Таблица «Тренировки» (сведения о проводимых тренировках): код тренировки, код группы, код тренера, дата начала, дата окончания, дни, длительность/час, общее количество часов.

6. Таблица «Походы» (сведения о запланированных походах): код похода, название похода, категория сложности, тип похода, дата, протяженность (км), количество дней, код тренера, категория похода, код маршрута.

7. Таблица «Маршруты» (сведения о маршрутах для походов): код маршрута, дата начала, дата окончания, привал, время привала (час), стоянка, время стоянки (час).

8. Таблица «Туристы в походе» (сведения о туристах, которые ходили в указанный поход): код туриста в походе, код туриста, код похода.

9. Таблица «Соревнования» (сведения о проводимых соревнованиях): код соревнования, код секции, название, дата проведения.

10. Таблица «Туристы в соревнованиях» (сведения о туристах, которые принимали участия в соревнованиях): код туриста в соревновании, код туриста, код соревнования, место.

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

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

Например, представление отчета по выполненному запросу «Поиск туриста», который выводит данные о туристе (рисунок 1).

Рисунок 1 Отчет о туристе

2.1.2 Нотация DFD

Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.

Диаграммы потоков данных используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. Главная цель DFD — показать, как каждая работа преобразует свои входные данные в выходные, а также выявить отношения между этими работами.

Любая DFD-диаграмма может содержать работы, внешние сущности, стрелки (потоки данных) и хранилища данных.

Далее моделировать систему будем, используя диаграммы потоков данных (DFD).

Декомпозируем функциональный блок «Приемка товара на склад» еще на четыре действия (Рис.3):

• Проверка товарно-транспортной накладной;
• Проверка поставленной продукции;
• Занесение данных о продукции в БД;
• Передача продукции на хранение.

Рис.3. Диаграмма DFD «Приемка товара на склад»

Далее декомпозируем функциональный блок «Хранение и переучет продукции» на два действия (Рис.4):

• Размещение товара на складе;
• Анализ наличия необходимого количества на складе (на этом этапе лицу, принимающему решение, передается оперативная информация).

Рис.4. Диаграмма DFD «Хранение и переучет продукции»

Декомпозируем функциональный блок «Отгрузка» на три действия (Рис.5):

• Проверка наличия товара на складе;
• Занесение информации об отгружаемой продукции в БД;
• Отгрузка продукции по требованию.

Рис.5. Диаграмма DFD «Отгрузка»

1.2 Предлагаемые мероприятия по улучшению бизнес-процессов

Проблемный анализ ключевых процессов (анализ «узких мест») бизнес-процесса «Управление персоналом» компании выявил следующие проблемы:

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

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

Сначала в отделе персонала кандидат заполняет документы: анкету кандидата и заявление о приеме на работу, правильность заполнения которых проверяет менеджер по персоналу (время обработки составляет 15 мин., время подготовки документов — 40 мин., время ожидания — 55 мин.).

Далее документы направляются начальнику отдела персонала для согласования (время передачи – 5 мин.). Здесь время обработки составляет 10 мин., время подготовки 5 мин., время ожидания 20 мин.

Затем документы направляются руководителю компании на утверждение кандидатуры (время передачи – 15 мин.). Здесь время обработки составляет 25 мин., время подготовки 15 мин., время ожидания 55 мин.

После чего результат возвращается к менеджеру по персоналу, который оформляет кандидата на должность (время передачи 10 мин., время обработки составляет 15 мин., время подготовки документов — 40 мин., время ожидания — 65 мин.).

Фактические временные затраты по данному процессу представлены в табл. 1.

Таблица 1.

Фактические временные затраты (мин.)

Операции	Время обработки	Время подготовки	Время ожидания	Время передачи	Общее время
Оформление документов	15	40	55	110
Согласование начальником отдела	10	5	20	5	40
Утверждение руководителем	25	15	55	15	110
Оформление на должность	15	40	65	10	130
Итого	65	100	195	30	390

Анализ процесса показал, что при его выполнении имеют место:

• передача ответственности за прохождение документа от одних отделов другим;
• разрывы в информационных носителях и др.

Это приводит к завышению длительности цикла выполнения процесса и увеличению его стоимости.

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

В отделе персонала менеджер в ИС заполняет анкету и заявление кандидата, попутно проверяя их достоверность (время обработки составляет 0 мин., время подготовки документов — 30 мин., время ожидания — 30 мин.).

Начальник отдела персонала проверяет заполненные данные в электронном виде и согласовывает кандидатуру (время передачи – 0 мин.). Здесь время обработки составляет 10 мин., время подготовки 1 мин., время ожидания 11 мин.

Руководитель компании знакомится с заполненными данными кандидата и принимает решение (время передачи – 0 мин.). Здесь время обработки составляет 5 мин., время подготовки 5 мин., время ожидания 10 мин.

Увидев результат решения руководителя в ИС, менеджер по персоналу оформляет кандидата на должность (время передачи – 0 мин., время обработки составляет 5 мин., время подготовки документов — 15 мин., время ожидания — 20 мин.).

Фактические временные затраты по оптимизированному процессу представлены в табл. 2.

Таблица 2.

Фактические временные затраты (мин.)

Операции	Время обработки	Время подготовки	Время ожидания	Время передачи	Общее время
Оформление документов	30	30	60
Согласование начальником отдела	10	1	11	22
Утверждение руководителем	5	5	10	20
Оформление на должность	5	15	20	40
Итого	20	51	71	142

Таким образом, после оптимизации данного процесса найма сотрудника на работу, время на его выполнение сократилось на 248 мин.

ЗАКЛЮЧЕНИЕ

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

Далее был осуществлен выбор CASE-средства для моделирования бизнес-процесса. Для моделирования бизнес-процессов предметной области был выбран системный подход, который включает следующие нотации: IDEF0, DFD, IDEF3. Для моделирования бизнес-процессов выбрана нотация IDEF0, поскольку она позволяет рассмотреть процесс комплексно, обладает неизбыточной детализацией и включает все необходимые инструменты.

Выбранная нотация реализована в ряде средств моделирования бизнес-процессов. К таким средствам относятся: Ramus Education, Dia, MS Visio и BPwin process modeler. Для выбора инструментального средства был выделен ряд критериев, согласно которым была проведена экспертная оценка перечисленных средств моделирования бизнес-процессов предметной области. В результате анализа было выбрано средство BPwin process modeler.

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

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

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

В результате были разработаны модели бизнес-процесса «как должно быть». На основании построенных моделей можно сделать вывод о том, что бизнес-процесс стал более простым, участие персонала в нем сократилось, следовательно были снижены временные затраты на осуществление процесса.