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

– поддерживает методы расчета себестоимости хозяйственной деятельности;

– интегрирован с такими продуктами, как ERwin, Paradigm Plus и прочие;

– интегрирован с инструментарием имитационного моделирования Arena.

Набор современных инструментальных средств с названием Oracle Designer использует решение для разработки разного рода систем корпоративного уровня.

Oracle Designer может брать участие практически во всех фазах ЖЦ разработки любого ПО – от моделирования до внедрения программы.

Окно Oracle Designer изображено на рисунке 5:

Рисунок 5. Внешний вид ПО Oracle Designer

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

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

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

Одним с таких средств является ARIS, разработанный компанией IDS Scheer.

ARIS (рисунок 6) поддерживает 4 класса моделей, отражающие самые различные аспекты системы:

Рисунок 6. Окно системы ARIS

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

1.3. Моделирование бизнес-процессов «как есть»

Рассмотрим описание моделирования БП учета предоставления услуг салона красоты в формате «как есть» (рисунок 7).

Рисунок 7. Контекстная диаграмма

Выполним анализ контекстной диаграммы.

Выполнение БП «Предоставление услуг салона красоты» выполняется на основании таких нормативных документов:

– Законодательство РФ;

– Договор по предоставлении услуг.

Входами для данного процесса являются:

– Потребности клиента;

– Возможности сотрудника.

В зависимости от этих параметром далее и будет определяться объем и мероприятия по предоставлению услуг в рамках утвержденного прейскуранта.

---

Механизмами для реализации бизнес-процесса являются такие лица:

– Клиент;

– Исполнитель;

– Менеджер по работе с клиентами.

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

Выходами в данном случае будут?

– полученные услуги;

– финансовая отчетность;

– отчет по статистике.

Выполним декомпозицию данного процесса на следующие составляющие подпроцессы (рисунок 8) и опишем их.

БД «Предоставление услуг салона красоты» 3 подпроцесса:

– Выбор услуги;

– Выбор сотрудника;

– Получение услуг.

Опишем входы, выходы, управление и механизмы для каждого их процессов.

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

Выходом является услуга.

Механизм процесса – клиент, который пишет данное заявление, управление выполняется на основании законодательства РФ.

Подпроцесс «Получение услуг» характеризуется такими показателями:

– вход – договор о предоставлении услуг;

– выходы:

Рисунок 8. Декомпозиция контекстной диаграммы

• Предоставленные услуги;
• Отчет по статистике;
• Финансовая отчетность.

– механизмы – менеджер по работе с клиентами, клиент;

– управление – законодательство РФ.

Подпроцесс «Выбор сотрудника» характеризуется такими показателями:

– входы:

• Возможности сотрудника;
• Заявление.

– выход – Сотрудник;

– механизм – менеджер по работе с клиентами, клиент;

– управление – законодательство РФ.

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

Рисунок 9. Декомпозиция БП «Получение услуг»

Рассмотрим основные особенности протекания описываемого бизнес-процесса:

– на этапе постановки задачи выполняется уточнение требований для услуг;

– услуга салона красоты предоставляется клиенту уже после ее определения и подбора.

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

---

Глава 2. Усовершенствование выполнения процесса «Учет предоставляемых услуг салоном красоты»

2.1. Предлагаемые мероприятия по улучшению БП

Рассмотрим меры по усовершенствованию бизнес-процесса по предоставлению услуг.

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

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

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

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

Стоит заметить тот факт, что прототипы используют и по причине того, что их проектирование стоит дешевле, чем непосредственное создание оригинального программного продукта.

Рассмотрим самые основные характеристики и классификацию прототипов программных продуктов.

С точки зрения масштаба разработки все прототипы подразделяются на такие категории (рисунок 10):

Рисунок 10. Категории прототипов по масштабу проектирования

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

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

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

Стоит также заметить, что практически все локальные прототипы разделяются на такие виды (рисунок 11):

Рисунок 11. Типы локальных прототипов

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

---

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

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

Рисунок 12. Схема горизонтального прототипирования

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

Рисунок 13. Описание вертикального прототипирования

Все рассмотренные классы прототипов по уровню их достоверности можно разделить на такие категории (рисунок 14):

Рисунок 14. Классификация прототипов по уровню достоверности

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

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

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

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

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

При этом, для них используется больше времени на непосредственную разработку или создание.

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

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

Рассмотрим далее основные подходы к реализации прототипа.

Традиционный подход для создания макетов программной продукции или ПО в целом основан на выполнении переходов с прототипа малого уровня достоверности к прототипам более высокого уровня (рисунок 15).

---

Рисунок 15. Классическая схема создания прототипа

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

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

Рисунок 16. Принцип выполнения эволюционного прототипирования

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

Но, несмотря на всю полезность эволюционного прототипирования при выявлении разных тонкостей и аспектов, к примеру, макета, усовершенствования его многими методами.

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

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

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

2.2. Моделирование бизнес-процессов «как должно быть»

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

В контекстной диаграмме стоит добавить механизм «ИС», который будет выполнять усовершенствование учета услуг.

В результате получим такую контекстную диаграмму (рисунок 17):

Рисунок 17. Контекстная диаграмма после добавления механизма «ИС»

Аналогично при предоставлении услуги в ИС будут вводится данные для учета услуг (рисунок 18):

---