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)

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

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

Надежность

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

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

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

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

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

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

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

Интерфейсы

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

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

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

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

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

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

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

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

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

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

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

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

1.2.3 Видение

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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