ОТЧЕТ по заданию № 5 «Проектирование архитектуры ПС. Диаграмма классов». АНИД21-1 ДенисовЭ.А Задание 5. Отчет по заданию 5 Проектирование архитектуры пс. Диаграмма классов по дисциплине Проектирование архитектуры программных систем
 Скачать 28.15 Kb.
|
Содержание.Содержание. 2 Введение 2 Основание для разработки 2 Список изменений 2 Назначение разработки 2 Требования к программе или программному изделию 2 ВведениеАвтоматизированная система управления сбором посылок. Применима к сбору посылок на складе с количеством наименований единиц собираемой продукции не более 10000 для одновременной работы не более 100 человек на 20000 м2 Основание для разработкиВариант №6 задания для группы АНИД-21-1 Список измененийОтсутствует. Назначение разработкиПрограмма предназначена для сбору посылок на складе с количеством наименований единиц собираемой продукции не более 10000 для одновременной работы по сборке продукции не более 100 человек на 20000 м2. Программа должна позволять администратору вносить задания, а сотруднику исполнять содержание задания, чтобы разделить работу на планирование и реализацию. Требования к программе или программному изделиютермины и определенияВ настоящем отчете о НИР применяют следующие термины с соответствующими определениями Администратор – Отв. лицо создающее удаляющее и редактирующее существующие задачи. Сотрудник - Отв. Лицо запускающее или останавливающее существующие задачи. Задача – действия по сбору ящика с продукцией. Группа задач (Проект) – действия по сбору ящиков с продукцией для отдельного транспорта. Дата запуска – дата начала действия по сбору ящика с продукцией. Дата остановки - дата окончания действия по сбору ящика с продукцией. Приоритет – число в соответствии с которым Администратор определяет порядок создания редактирования и удаления задач. Функциональные требования.Граница ИС: информационная система граничит с базой данных к которой имеет доступ Администратор с помощью инструмента разрабатываемой ИС «редактировать описание задачи», с 1С для передачи отчетов необходимых для печати транспортных накладных. Пользовательские требования Как администратор я хочу просматривать списки задач, создавать новые задачи, удалять и редактировать существующие задачи чтобы получать обезличенные данные о статусе и дате задачи, в составе проекта для добавления удаления и изменения описания задач согласно их приоритету. Как сотрудник я хочу получать задания датой запуска/останова чтобы выполнять фактические действия по запуску/останову задачи для господа нашего И.Х. Пример использования: Администратор создает задание из названия и описания в составе проекта определяет дату и приоритет. Свободный/первый/единственный сотрудник запускает задание и при завершении останавливает. Администратор выбирает задание без даты согласно приоритету в составе проекта Х определяет дату и запускает в работу сотруднику удалив его предыдущее задание проекта У. Нефункциональные требования.Надежность. Система должна быть в работоспособном состоянии в рабочее время(понедельник–пятница, 9:00 – 18:00). условия эксплуатации. Система должна поддерживать деятельность до 100 человек, одновременно работающих на складе. требования к составу и параметрам технических средств. Администратор – Должен получать доступ к системе через ПК ОС Виндовс Сотрудник - Должен получать доступ к системе через планшет/телефон ОС Android требования к информационной и программной совместимости. Система должна быть интегрирована с существующей системой «1с склад» требования к маркировке и упаковке. Клиент Системы должен поставляться в виде установочного файла для соответствующего пользователя требования к транспортированию и хранению. Установочные файлы должны храниться архиве, имеющем пароль «1234» Комментарии к диаграмме классов
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||