Проектирование и реализация ИС «Нотариальная контора»

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

Бизнес-процессы в компании совершенно не формализованы. Для начального описания текущего состояния бизнес-процессов приводятся диаграммы вариантов использования (use-case) в нотации UML. В случае, если деятельность является хотя бы отчасти формализованной, приводятся также диаграммы деятельности в нотации UML, отражающие входную и выходную информацию для процессов, деятельность и роли исполнителей, участвующих в процессе [9].

Рассмотрим контекстную диаграмму, целью построения которой является смоделировать текущие бизнес-процессы нотариальной конторы (Модель AsIs). Она показывает, что основной функцией является обслуживание клиентов (рис. 6).

Основные информационные потоки:

• 1. Входящие потоки:
  • — Данные о клиентах (паспортные данные клиентов);
  • — Данные о заказах.
• 2. Управляющие потоки:
  • — Законодательство РФ (законы, ГОСТ, правила);
  • — Методика формирования статистики посещения нотариальной конторы;
• 3. Механизмы:
  • — База данных нотариальной конторы (БД «Нотариат»);
  • — Нотариус.
• 4. Выходящие потоки:
  • — Статистика посещения клиентами нотариальной конторы (график);

Созданная модель описывает деятельность нотариата.

Объектом моделирования является нотариальная контора.

Система рассматривается с точки зрения нотариуса.

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

Рассмотрим диаграммы декомпозиции (рис. 7).

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

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

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

Рис. 7 Диаграммы декомпозиции

Рассмотрим диаграмму потоков данных DD (рис. 8).

Представлена диаграмма потоков данных, которая демонстрирует «расщепление» функции «Прием/оформление заказов». Основными компонентами диаграммы являются:

• — Внешние объекты: Нотариус, Гражданин.
• — Процессы: Принять заявку от клиента; Занести инф-ю о клиенте в БД.
• — Хранилища данных: Нотариус, Гражданин.
• — Различные потоки данных.

При получении заявки от клиента нотариус заносит данные о клиенте в базу, затем предлагает свои услуги. Если услуга устраивает, то нотариус оформляет заказ.

Рис. 8 Диаграмма потоков данных

Документирование процессов, происходящих в системе, стандарт IDE3 представлено на рис. 9.

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

• — Единицы работы: Принять заявку, Предложить услугу, Оказать услугу, Оформить заказ.
• — Объекты: Заявка, Услуга, Договор.

Также на диаграмме имеются соединения J1(разветвляющее) и J2(соединяющее) с типом «эксклюзивное или», т. е. только одно конечное действие инициируется, и только одно исходное действие должно завершиться.

Рис. 9 Диаграмма IDE3

Проектирование базы данных, используемых ИС (ER-модель) (рис. 10).

Рис. 10 ERD-диаграмма

На рисунке 10 изображена ERD-диаграмма, с помощью которой можно выделить ключевые сущности и обозначить связи между этими сущностями. Основной сущностью является сущность Обращение гражданина к нотариусу (Order) со следующими атрибутами: идентификатор (o_id); дата поступления заказа (o_date); состояние обращения (o_status), услуга, которую выбрал гражданин (s_id); гражданин, от которого поступило обращение (c_id); нотариус, который принял обращение (n_id). Три последние атрибута используются для создания связей с другими сущностями. Атрибутами сущности Услуга (service) являются: идентификатор (service _id); название услуги (s_name); стоимость (s_ price);. Сущности Гражданина (citizen) и Нотариус (Notary) схожи по таким атрибутам, как имя, фамилия, отчество, адрес, телефон. Сущность Оказанная услуга (services rendered) — это оформляемые с гражданином документы.

ERD-диаграмма поможет в разработке базы данных (сущности на диаграмме — основные таблицы для БД).

Диаграмма классов представлена на рис. 11.

Рис. 11 Описание деятельности Нотариальной конторы

На рисунке 11 изображена диаграмма классов, позволяющих описать деятельность Нотариальной конторы в статическом состоянии, т. е. определить типы объектов и различного рода статические связи между ними. Она содержит классы: Актор, Гражданин, Нотариус.

Класс Актор является родительским по отношению к классам Гражданин и Нотариус.

Расчёт трудоёмкости разработки осуществляется на основе вариантов использования и содерит в себе следующие блоки работ (рис. 12):

Рис. 12. Схема определения трудоёмкости проекта

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

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

Таблица 1.

Весовые коэффициенты действующих лиц.

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

A = 1*3 = 3.

Второй блок — «Определение весовых показателей вариантов использования». Все варианты использования делятся на три типа: простые, средние и сложные в зависимости от количества транзакций в потоках событий (основных и альтернативных). В данном случае под транзакцией понимается атомарная последовательность действий, которая выполняется полностью или отменяется. Описание типов вариантов использования и их весовые показатели представлены в таблице 2.

Таблица 2.

Весовые коэффициенты вариантов использования.

Все варианты использования, представленные в системе по типу определены как «средние», в соответствии с этим им были присвоены следующие весовые коэффициенты (табл. 3):

Таблица 3.

Сложность вариантов использования.

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

ИС = 3*10=30.

В результате показатель ИИСР = А + ИС = 3 + 30 = 33.

Далее необходимо определить техническую сложность проекта TC (TC — Technical Complexity actor).

Техническая сложность проекта (TC) вычисляется с учетом показателей технической сложности. Таблица 4 с показателями технической сложности проекта представлена ниже.

Каждому показателю присваивается значение Тi в диапазоне от 0 до 5 (0 означает отсутствие значимости показателя для данного проекта, 5 — высокую значимость).

Значение TC вычисляется по формуле:

TC = 0,6 + (0,01 * (?Ti * Весi)).

где где Тi-показатель сложности компонента; Весiвсё этого компонента В нашем случае TC будет равен:

TC=0.6+(0.01*(?Ti*Весi))=0.6+(0.01*40)=1,0.

Таблица 4.

Характеристика проекта.

Таблица 5.

Определение уровня квалификации разработчика.

Четвёртый блок предполагает определение уровня квалификации разработчика (E-Environmental actor). Оценка уровня квалификации проводится по восьми различным показателям (табл. 6).

Уровень квалификации разработчиков (E) вычисляется по формуле:

E = 1,4 + (-0,03 * (?i * Весi)).

В нашем случае E = 1.4 + (-0.03 * (?i*Весi)) = 1.4 + (-0.03 * 21) = 1.4−0.63=0.77.

В результате получаем окончательное значение ИСР:

ИСР = ИИСР*TC*E = 33*1*0,77 = 25,41.

Таким образом, оценив все выше перечисленные показатели, можно перейти к «Оценке трудоёмкости проекта». В качестве начального значения предлагается использовать 20 чел.-часов на 1 ИСР. Таким образом общее время разработки составляет 25,41 * 20 = 508,2 чел.-час. = 12,705 недель при 40 часовой рабочей неделе = 3,17 625 месяца.