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

Вопросы законодательства

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

Информация из предметной области

Возникновение обязательств

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

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

 

1.2.3 Видение

 

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

 

Введение

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

Позиционирование

Экономические предпосылки

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

Формулировка проблемы

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

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

Место системы

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

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

Система «AWM» разработана для менеджера компании. Кроме обработки договоров, менеджер работает с клиентами, занимается вопросами поиска новых покупателей, проводит экономические расчеты о целесообразности проведения коммерческих сделок, изучает спрос и готовит предложения по улучшению работы предприятия, принимает меры по обеспечению оплаты выставленных спецификаций (счетов), способствует учету продукции на складе. Поэтому возникла необходимость снизить рабочую нагрузку менеджера, предложив тем самым решение «AWM». Кроме снижения объема работ у менеджера больше нет необходимости в хранении огромного количества бумажных документов.

Задачи уровня пользователя

Пользователи (и внешние системы) используют данную систему в следующих целях:

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

- Системный администратор  управляет безопасностью системы;

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

- Начальник следит  за исполнением каждого договора.

Таблица 10 - Основные задачи высокого уровня и проблемы заинтересованных лиц

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

 

Обзор

Перспективы продукта

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

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

Преимущества системы

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

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

Таблица 11 – Основное значение и отличительные свойства «AWM»

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

 

 

 

 

 

 

 

 

 

Рисунок 4 - Контекстная диаграмма «AWM»

 

Основные свойства системы

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

Другие требования и ограничения

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

Словарь терминов

Таблица 12 – Словарь терминов

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

2 Модель предметной области

 

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

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

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

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

 

Рисунок 5 – Кандидаты на роль концептуальных классов

 

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рисунок 6 – Модель предметной области

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3 Модель проектирования

3.1 Диаграмма взаимодействия

 

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

Создадим реализацию прецедента Создание спецификации - построим диаграмму взаимодействия (рисунок 7).

Рисунок 7 – Диаграмма взаимодействия

 

3.2 Диаграмма последовательностей и кооперации

 

Термин "диаграмма взаимодействия" используется в качестве общего названия для следующих конкретных типов диаграмм, которые могут использоваться для иллюстрации обмена сообщениями: Диаграммы кооперации (рисунок 8), Диаграммы последовательностей (рисунок 9)

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

Рисунок 8 – Диаграмма кооперации

 

 

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

 

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

 

                 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рисунок 10 – Взаимодействие уровней пользовательского интерфейса и предметной области для события makeNewDoc()

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рисунок 11 – Взаимодействие уровней пользовательского интерфейса и предметной области для событий enterNomerContract () и enterProduct ()

 

 

 

 

 

 

 

 

 

 

 

 

3.3 Диаграмма программных классов

 

Рисунок 12 – Диаграмма программных классов

 

 

 

 

 

 

 

 

 

 

 

 

4 Модель данных

 

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

Реляционная БД состоит из двумерных таблиц. В таблицах хранятся различные данные.

Реализованная БД состоит из 5 таблиц (таблицы 13 - 17), которые связаны между собой и включают атрибуты связанной таблицы.

 

Таблица 13 – Контрагент

Контрагент	Контрагент	ФИО Руководителя	Реквизиты
ООО «Геоникс»	14.12.06	Колоткина Н.В.	610256, г.Нытва, ул.Пол23 т. 1265489
ОО «Век»	01.08.06	Самарин А.К.	614056, ул. Левина 124, т. 156-2369

 

Таблица 14 – Договор

Дата	Номер	Срок	Контрагент	ФИО Руководителя
01.08.06	52	31.07.2007	ОО «Век»	Самарин А.К.
14.12.06	100	30.09.2007	ООО «Геоникс»	Колоткина Н.В.