Logo GenDocs.ru

Поиск по сайту:  


Загрузка...

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


Курсовой проект - Разработка экономической информационной системы для автоматизации обработки информации по договорам с покупателями
скачать (522.5 kb.)

Доступные файлы (1):

1.doc523kb.14.12.2011 08:02скачать

содержание
Загрузка...

1.doc

  1   2   3
Реклама MarketGid:
Загрузка...
Кафедра: Информационных технологий и

автоматизированного проектирования

КУРСОВОЙ ПРОЕКТ



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

для автоматизации обработки информации по договорам

с покупателями »

Проект выполнил:
Руководитель:


Оценка ………………………………



…………………………………………

(дата защиты)
…………………………………………

(подпись преподавателя)


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

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 С0 до 25 С0;

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. Заключение. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Приложение А . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Приложение Б. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Приложение В . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



2

8

11

25

27

31

33

34

35

36

38

39



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

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

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

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

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

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

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

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

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

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

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

^ 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. Анализ требований

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

ООО «С»


УО



Руководитель

Цель: Получение отчетной документации

ОУБ



Системный

администратор
Цель: Управление безопасностью системы

ОМТС и С



Система

управления

сбытом
Цель: Анализ данных о продажах, контроль за исполнением договоров



Менеджер
Цель: Оформление сделки с контрагентом

Начальник ОМТС и С

AWM

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

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

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

Исполнитель

Задача

Менеджер

Создает карточки договоров, ведет спецификации к каждому договору, продлевает срок действия договора

Система управления снабжением и сбытом

Контроль за исполнением договоров

Системный администратор

Управляет безопасностью системы

Руководитель

Контролирует работу менеджеров

Начальник МТС и С

Контролирует исполнение договора


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

^ Внешнее событие


Инициатор


Задача


Ввод информации о контрагенте

Менеджер

Создать электронную карточку договора

Ввод информации о товаре

Менеджер

Создать спецификацию, счет

Ввод срока действия договора

Менеджер

Продлить срок действия договора

Добавление пользователей

Системный администратор

Управление безопасностью системы

Удаление пользователей

Системный администратор

Управление безопасностью системы

Запрос на просмотр истории договора

Начальник МТС и С

Контролировать исполнение договора


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

^ Элементарный бизнес- процесс

Прецедент

Заключение договора

Сбор первичной информации, Ведение карточки договора, Пролонгация договора

Обработка договора

Создание спецификации, счета

Контроль за исполнением договора

Контроль за исполнением договора

Управление безопасностью ситемы

Управление безопасностью системы



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание-

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


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

  1. Идентификация менеджера.

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

  3. Система присваивает номер и дату спецификации.

  4. Менеджер выбирает номер договора. Система выдает номер и дату договора, реквизиты и наименование контрагента, с которым был заключен договор.

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

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

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

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

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

П
Простой сценарий прецедента

Создание спецификации


  1. Идентификация менеджера.


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

  2. Система присваивает номер и дату спецификации.




  1. Менеджер выбирает номер договора.

Система выдает номер и дату договора, реквизиты контрагента.


  1. Менеджер выбирает товар.

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


Менеджер повторяет действия, описанные в п.п. 5-6, для каждого товара.


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



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


:System

: Менеджер

enterID (Passport, Login)

Доступ к системе

makeNewDoc()

Номер, дата документа

enterNomerContract ()

Номер, дата, контрагент

enterProduct ()

Товар, цена, стоимость, НДС, сумма НДС, общая стоимость
ример, приведенный на рисунке 3, соответствует основному успешному сце­нарию прецедента Создание спецификации.


Общая сумма

enterDateProduct()

makeSave()

P

Спецификация

makePrint()

enterFormaPay()

enterDatePay()


Рисунок 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



Скачать файл (522.5 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru