Моделирование системы работы с договорами покупателей

12

Техническое задание на проектирование

1 Общие сведения

В рамках данного курсового проекта будет рассмотрена подсистема АСУ «Управление договорами» - автоматизированная система, представляющая собой совокупность программно-аппаратных средств, обеспечивающих взаимодействие человека с ЭВМ в интерактивном режиме.

Полное наименование системы - «Автоматизированное система по обработке информации по договорам с контрагентами».

Условное обозначение системы- «AWM».

Система создается на основе документов, используемых в организации:

· Должностная инструкция специалиста отдела МТС и С

· Положение о порядке осуществления договорной работы в ООО «» утверждено руководителем_______.

· Форма № С «Дополнительная спецификация» (Приложение Б).

Курсовой проект разрабатывается согласно учебному плану по дисциплине «Проектирование информационных систем» в соответствии с государственным стандартом специальности «Прикладная информатика (в экономике)» ГОСТ 080801. При разработке так же были использованы:

· Методическое пособие по курсовому проектированию по дисциплине «Проектирование информационных систем»;

· Комплекс стандартов на автоматизированные системы ГОСТ 34.602-89.

Плановые сроки начала и окончания работы по созданию системы: с 16.03.2007 по 30.05.2007.

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

2 Назначение и цели создания (развития) системы

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

Цель создания «AWM»: организация электронного документооборота по обработке информации по договорам, повышение производительности труда при выполнении рутинных каждодневных операций и сокращение времени обработки одного документа. Что позволит процессу обработки договора и связанных с ним документов стать более управляемыми и контролируемыми.

3 Характеристика объекта автоматизации

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

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

4 Требования к системе

4.1 Требования к системе в целом

4.1.1Требования к структуре и функционированию системы

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

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

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

4.1.2 Требования к численности и квалификации персонала и режиму его работы

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

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

Режим работы менеджера с системой с 9.00 до 18.00 часов, с перерывом с 13.00 до 14.00 часов.

4.1.3 Требования к надежности

Аппаратура «AWM» должна эксплуатироваться круглосуточно. Средний срок службы системы должен быть не менее 8 лет. «AWM» должно обеспечивать автоматическое восстановление работоспособности без вмешательства оператора в случае отключения электропитания с последующим его включением. Кратковременные отключения электропитания (до 15 минут) и броски напряжения в электросети не должны перезапускать систему при использовании источника бесперебойного питания.

4.1.4 Требования по безопасности

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

Подключение АРМ менеджера к электросети должно производиться через розетки с заземляющим контактом. Заземляющий контакт в розетках должен быть соединен с земляным контуром помещения.

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

4.1.5 Требования к эргономике и технической эстетике

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

Рабочее место менеджера состоит из монитора, системного блока, клавиатуры, мыши, принтера, факса. Клавиатура должна быть расположена непосредственно перед пользователем. Расстояние от глаз пользователя до монитора должно составлять 0.5 - 0.7 м. На столе, на котором расположена ПЭВМ, должно оставаться место для наглядного, графического материала, для возможности работать с литературой.

К размерам рабочего места предъявляются требования:

- высота рабочей поверхности 655 мм;

- высота сидения 420 мм (желательно регулируемого);

- расстояние от сидения до нижнего края рабочей поверхности 150мм;

- размеры пространства для ног 650x500x600.

4.1.6 Конструктивные требования

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

Конструктивное соединение интерфейсных кабелей с АРМ должно обеспечивать надёжный электрический и механический контакт, удобство стыковки-расстыковки.

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

АРМ менеджера должен быть IBM PC совместимым компьютером

4.1.7 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению

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

1) температура окружающего воздуха от 0 С⁰ до 25 С⁰;

2) относительная влажность окружающего воздуха от 10% до 95%;

3) атмосферное давление (мм. рт. ст.) от 630 до 800.

4) массовая концентрация пыли в воздухе до 1 мг/м3.

5) амплитуда вибрации пола не превышает 1мм в диапазоне частот от 5 до 17 Гц и в диапазоне от 17 до 500Гц с нагрузкой до 1,5G.

Система должна подключаться к однофазной электросети переменного тока с номинальным напряжением 220 В, при предельных отклонениях напряжения от плюс 10 до минус 15%, и частотой 50 Гц, при предельных отклонениях частоты от плюс 1 до минус 1 Гц, с нормами качества электрической энергии - по ГОСТ 13109-87.

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

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

4.1.8 Требования к защите информации от несанкционированного доступа

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

Быстрая, простая и корректная обработка информации -- вот главные принципы системы автоматизации «AWM».

4.2 Требования к функциям (задачам), выполняемым системой

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

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

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

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

5) Архивирование документов - после обработки, подписанные документы должны помещаться в архив. Документы из архива редактировать нельзя, их можно читать или удалять. Системный администратор может настраивать режимы архивирования и восстановления документов, устанавливать права доступа к архивам.

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

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

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

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

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

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

4.3 Требования к видам обеспечения

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

Для данной системы необходимо следующее программное обеспечение: операционная система Windows 98SE, Windows ME, Windows 2000, Windows XP, аппаратное обеспечение: Intel Pentium III 800 МГц или AMD Athlon 800 МГц, оперативная память 512 Мб. Все процессы осуществляются по средствам GUI.

5 Состав и содержание работ по созданию системы

Задание на курсовое проектирование посвящено проектированию экономической информационной системы (ЭИС). При этом предусматривается закрепление знаний и навыков системного проектирования с применением объектно-ориентированной технологии (ООТ) в рамках RUP (Rational Unified Process).

При выполнении курсового проекта необходимо:

- разработать техническое задание (ТЗ) на разработку ЭИС по ГОСТ 34.602-89;

- выполнить системный анализ и анализ требований к создаваемой ЭИС, разработать модель предметной области, модель проектирования, модель данных и модель реализации;

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

Содержание

Техническое задание на проектирование

Введение

1. Системный анализ и анализ требований

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

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

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

5. Модель реализации

6. Заключение

Список использованных источников

Приложение А

Приложение Б

Приложение В

Введение

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

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

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

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

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

Применение современных информационных технологий обеспечивает:

· полные возможности взаимодействия с существующим кодом;

· полное и абсолютное межъязыковое взаимодействие;

· упрощение процесса развертывания приложения;

· использование общей среды выполнения для любых приложений.

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

1 Системный анализ и анализ требований

1.1 Системный анализ

Заказчику необходима система по обработке информации по договорам с контрагентами, позволяющая:

- Автоматизировать процесс выполнения операций с заключенным договором с контрагентом (автоматическое создание документов по заданному договору), минимизировать количество ошибок;

- Контролировать работу нижестоящих сотрудников с договорами (возможность просмотра информации о состоянии любого договора);

- Ограничивать доступ к информации, хранящейся в системе.

В рамках данного курсового проекта будет рассмотрена подсистема АСУ «Управление договорами» - автоматизированное рабочее место, представляющее собой совокупность программно-аппаратных средств, обеспечивающих взаимодействие человека с ЭВМ в интерактивном режиме.

МИНИМАЛЬНЫЕ СИСТЕМНЫЕ ТРЕБОВАНИЯ:

- Процессор: Intel Pentium III 800 МГц или AMD Athlon 800 МГц;

- Оперативная память: 512 Mb;

- HDD (Свободное место на жестком диске): 6 Мб;

- Монитор: VGA разрешение 800*600;

- Операционная система: Windows 98SE, Windows ME, Windows 2000, Windows XP;

- PCI слот;

- Видеокарта с поддержкой DirectX 9 и выше;

- Звуковая карта для записи дополнительных комментариев с поддержкой DirectX 9 и выше;

- Привод CDROM;

- Клавиатура и мышь;

Входной информацией системы является: информация о контрагенте; информация о договоре; информация о товаре; Соглашение о пролонгации договора.

Выходной информацией системы является: информация о состоянии сделки по договору; спецификация, счет, Соглашение о пролонгации договора.

1.2 Анализ требований

1.2.1 Определение рамок системы, элементарных бизнес-процессов и соответствующих им прецедентов

Для выделения внешних, вспомогательных и основных пользователей необходимо определить рамки разрабатываемой системы. В соответствии с рисунком 1 видно, что работой в системе заинтересованы четыре отдела фирмы ООО «С». К этим отделам относятся: управленческий отдел, отдел материально-технического снабжения и сбыта, отдел управления безопасностью.



12

Рисунок 1- Схема определения рамок системы

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

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

Таблица 1 - Перечень исполнителей и их задач

Исполнитель	Задача
Менеджер	Создает карточки договоров, ведет спецификации к каждому договору, продлевает срок действия договора
Система управления снабжением и сбытом	Контроль за исполнением договоров
Системный администратор	Управляет безопасностью системы
Руководитель	Контролирует работу менеджеров
Начальник МТС и С	Контролирует исполнение договора

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

Таблица 2 - Перечень исполнителей и их задач на основе анализа внешних событий

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

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

Таблица 3 - Перечень элементарных бизнес-процессов и соответствующих им прецедентов

Элементарный бизнес- процесс	Прецедент
Заключение договора	Сбор первичной информации, Ведение карточки договора, Пролонгация договора
Обработка договора	Создание спецификации, счета
Контроль за исполнением договора	Контроль за исполнением договора
Управление безопасностью ситемы	Управление безопасностью системы

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

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

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

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

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

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

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

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

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

По истечении определенно срока (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). С их помощью можно проиллюстрировать взаимодействие исполнителя с системой и операции, выполнение которых при этом инициируется.

12

Пример, приведенный на рисунке 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	Правило вычисления общей суммы. Общая сумма сделки равна общей стоимости всех товаров.	Низкая вероятность	Политика торговых организаций

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

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

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

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

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

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

1.2.3 Видение

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

После добавления ассоциаций и атрибутов предметная область будет выглядеть, как показано на рисунке 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	ООО «Геоникс»	Колоткина Н.В.

Таблица «Договор» содержит данные о договорах, с которыми работает менеджер. Таблица «Договор» связана с таблицей «Контрагент» по наименованию контрагента и по ФИО руководителя контрагента.

Таблица 15 -Товар

Код	Наименование	Цена
1	вентилятор ВЦ 32	1500
2	элдвигатель ВА 12	1400
3	компрессор винтовой К4	5600

Таблица 16 -Спецификация

Дата	Номер	Номер Договора	Дата Договора	Контрагент	ФИО Руководителя	Сумма
01.05.07	1	52	01.08.2006	ОО «Век»	Самарин А.К.	21594
10.04.07	2	100	14.12.2006	ООО «Геоникс»	Колоткина Н.В.	1652

Таблица 17 - Элемент Спецификации

Номер	КодТовара	Товар	Цена	Кол-во	Стоимость	%	НДС	Общая Сумма
1	1	вентилятор ВЦ 32	1500	1	1500	18	270	1770
1	3	компрессор винтовой К4	5600	3	16800	18	3024	19824

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

Таблица «Элемент спецификации» существует как промежуточная между таблицами «Товар» и «Спецификация». Эта таблица служит для отображения товара в спецификации.

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

Рисунок 13 - Структура БД «AWM»

5 Модель реализации

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

Анализ рынка CASE-средств и их возможностей позволил выбрать CASE-средство - CASEBERRY.

CASEBERRY базируется на технологии .NET Framework фирмы Microsoft, которая предоставляет принципиально новый подход к разработке пользовательских приложений. Основным принципом разработки распределенных приложений с помощью .NET Framework является логическое разбиение приложения на три слоя - представления, бизнес-логики, доступа к данным и их хранения.

Один из основных языков программирования платформы .NET - С#, который имеет доступ к общеязыковой исполняющей среде (CLR), предоставляемой библиотекой программ .NET Framework.

Именно С# был использован для преобразования разработанной модели в исходный код (Приложение В).

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

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

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

Заключение

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

Предлагаемое решение - автоматизированная система «AWM», предназначенная для АРМ менеджера по сбыту.

Преимуществами данной системы является следующее:

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

- информация по договорам и контрагентам хранится централизованно;

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

«ARM» разработано с использованием CASE- средства Caseberry.

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

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

Список использованных источников

1. Вендров А.М. Проектирование ПО экономических информационных систем: Учебник. - М.: Финансы и статистика, 2007. - 352 с.: ил.

2. ГОСТ 7.32-2001 СИБИД. Отчет о научно-исследовательской работе. Структура и правила оформления.

3. ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы.

4. Должностная инструкция инженера по сбыту

5. Калянов Г.Н. CASE - технологии. Консалтинг в автоматизации бизнес-процессов. 3-е изд. - М.: Горячая линия - Телеком, 2009. - 320 с.: ил.

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

7. Технологии разработки программного обеспечения,С.Орлов.СПб.:Питер,2010.- 464 с.: ил.

Приложение А

ДОГОВОР № 52

г. Пермь «14 декабря 2006 г.

ООО ИТФ «С», именуемое в дальнейшем «ПОСТАВЩИК», в лице директора Сенкевича Андрея Викторовича, действующего на основании Устава, с одной стороны и ООО «Геоникс», именуемое в дальнейшем «ПОКУПАТЕЛЬ», в лице Колоткиной Н.В., действующего на основании устава, с другой стороны, заключили настоящий Договор о нижеследующем: