Разработка экономической информационной системы для автоматизации обработки информации по договорам с покупателями

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

Менеджер отправляет счет на утверждение руководителю фирмы.

Прецедент Контроль за исполнением договора: Система управления  сбытом при создании спецификации анализирует состояние договора, если состояние активно, т.е. есть неоплаченная спецификация, система выводит сообщение.

По истечении определенно срока (5 лет) система удаляет карточки договоров с пустой историей, перед этим выведя сообщение об истечении срока хранения неактивного договора в архиве.

Начальник МТС и С контролирует правильность результативной информации, следит за загруженностью каждого менеджера, имеет доступ ко всем базам контрагентов и ко всем базам договоров.

Прецедент Управление безопасностью: Доступ к договорам и контрагентам может быть разграничен не только по подразделениям компании, но и по менеджерам. Администратор может наложить любые ограничения для каждого сотрудника - договоры будут отображены или скрыты в зависимости от потребностей и логики бизнес-процессов предприятия.

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

 

Рисунок 2 - Диаграмма прецедентов

 

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

Развернутое описание прецедента Создание спецификации

Основной исполнитель. Менеджер.

Заинтересованные лица и их требования

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

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

- Начальник ОМТС и С - Заинтересован в качественных сделках, т.е. чтобы они были оформлены в максимально короткий срок в правильном содержании.

- Фирма - Удовлетворить свои снабженческие и сбытовые потребности. Удовлетворить все требования покупателя.

Предусловия. Идентификация менеджера, а именно аутентификация и авторизация менеджера.

Примечание-

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

 Результаты (Постусловия). Складские данные обновлены. Спецификация сгенерирована и сохранена. Автоматизация обработки информации по договору выполнена.

 

Основной успешный сценарий

1. Идентификация менеджера.
2. Менеджер открывает новую спецификацию.
3. Система присваивает номер и дату спецификации.
4. Менеджер выбирает номер договора. Система выдает номер и дату договора, реквизиты и наименование контрагента, с которым был заключен договор.
5. Менеджер выбирает товар в нужном количестве. Система записывает наименование товара и выдает его описание: цену, стоимость, налоговую ставку, сумму налога, общую стоимость.

Стоимость, сумма налога, общая стоимость вычисляются на основе набора правил.

Менеджер повторяет действия, описанные в пунктах. 4 - 7, для каждого товара.

6. Система выводит общую сумму к оплате. Менеджер вводит срок доставки товара, форму и срок оплаты.

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

 

Расширения (или альтернативные потоки)

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

1) Менеджер перезапускает систему, идентифицируется и предлагает восстановить предыдущее состояние.

2)  Система восстанавливает предыдущее состояние.

    2.а) Система определяет аномалию, повлекшую сбой.

       1.Система уведомляет и регистрирует ошибку и переходит в начальное состояние.

       2.Менеджер  открывает новую спецификацию.

3.б) Редактирование старой спецификации.

   1. Менеджер выбирает номер  спецификации (она уже имеется  в базе).

   2. Система предлагает изменить номер или исправить данный документ.

4.а) Выбранный договор в состоянии активен.

   1. Система сообщает, что по данному договору уже есть неоплаченная спецификация.

   2. Менеджер  соглашается с продолжением создания  документа.

5.а) Требуемого количества товара нет на складе.

   1. Система уведомляет о том, что данного товара нет в требуемом количестве.

   2. Менеджер  соглашается, изменяет (добавляет) в спецификации количество товара.

5.б) Менеджера не устраивает цена товара (от стоимости сделки зависит процент, выплачиваемый менеджеру).

   1. Менеджер  может вручную изменить цену товара.

   2. Система  пересчитывает стоимость, сумму  налога и общую стоимость.

6.а) Менеджера не устраивает общая сумма к оплате.

   1. Менеджер  может вручную изменить цену  товара.

   2. Система  пересчитывает стоимость, сумму  налога, общую стоимость, общую сумму.

7.а) Система уведомляет о незаполненных полях в спецификации.

  1. Менеджер устраняет ошибку.

   2. Система сохраняет и выводит на печать документ.

 

Специальные требования

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

- Отклик службы авторизации в 90% случаев приходит в течение 30 секунд.

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

Частота использования: почти постоянно.

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

Пример, приведенный на рисунке 3, соответствует основному успешному сценарию прецедента Создание спецификации.

Рисунок 3 – Диаграмма последовательностей для успешного сценария

Описания Системных операций (system operation contract) описывают детальное поведение системы в терминах изменения состояния объектов модели предметной области после выполнения системных операций.

Системные операции для контрольного прецедента представлены в таблицах 4 – 8.

Таблица 4 – Описание операции enterID (Passport, Login)

Операция	enterID (Passport, Login)
Ссылки	Прецедент: Создание спецификации
Предусловия	Отсутствует
Постусловия	Идентификация менеджера

 

Таблица 5 – Описание операции makeNewDoc()

Операция	makeNewDoc()
Ссылки	Прецедент: Создание спецификации
Предусловия	Менеджер идентифицирован
Постусловия	Создан экземпляр класса Спецификация

 

Таблица 6 – Описание операции enterNomerContract ()

Операция	enterNomerContract ()
Ссылки	Прецедент: Создание спецификации
Предусловия	Создан экземпляр класса Спецификация
Постусловия	Создана новая строка в экземпляре класса Спецификация

 

Таблица 7– Описание операции enterProduct ()

Операция	enterProduct ()
Ссылки	Прецедент: Создание спецификации
Предусловия	Создан экземпляр класса Спецификация
Постусловия	Создана новая строка в экземпляре класса Спецификация

 

Таблица 8 – Описание операции enterDateProduct()

Операция	enterDateProduct()
Ссылки	Прецедент: Создание спецификации
Предусловия	Создан экземпляр класса Спецификация
Постусловия	Создана новая строка в экземпляре класса Спецификация

 

Остальные операции описываются аналогично.

 

 1.2.2 Дополнительная спецификация

 

Версия	Дата	Описание	Автор
Окончательный вариант	25 мая 2007 г.	Окончательный оригинальный вариант	………

 

Введение

В этом документе описаны все требования к системе «AWM», не вошедшие в описание прецедентов.

Регистрация событий и обработка ошибок

Все ошибки регистрируются на постоянном носителе.

Безопасность

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

Удобство использования

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

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

Надежность

Возможность восстановления информации

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

Производительность

Выполнение авторизации должно быть не более чем за 3 минуту в 80% случаев.

Возможности поддержки

Конфигурирование

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

Интерфейсы

- Сенсорный монитор (воспринимаемый операционной системой как обычный монитор; прикосновения обрабатываются как события мыши);

- Устройство для печати счетов и спецификаций;

- Факс для выведения спецификаций.

Бизнес-правила

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

Таблица 9 - Перечень бизнес-правил

Имя	Правило	Вероятность возможного изменения	Источник
Прав1	Правило вычисления стоимости товара. Стоимость равна произведению количества и цены товара.	Низкая вероятность	Политика торговых организаций
Прав2	Правило вычисления суммы налога. Сумма налога равна 18% от стоимости товара.	Высокая вероятность изменения.	Закон
Прав3	Правило вычисления общей стоимости товара. Общая стоимость товара равна сумме стоимости и налога.	Низкая вероятность	Политика торговых организаций
Прав4	Правило вычисления общей суммы. Общая сумма сделки равна общей стоимости всех товаров.	Низкая вероятность	Политика торговых организаций