ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 11.01.2024
Просмотров: 270
Скачиваний: 8
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
.
Рисунок 2 – Схема базы данных
База данных является основным источником получения необходимой информации, а также средством для хранения и изменения необходимых данных. Вся информации в БД разделена на таблицы, которые являются сущностями того или иного бизнес-объекта или процесса. Краткое описание таблиц БД приведено в таблице 1 ниже.
Таблица 1 – Описание таблиц в БД
Города (city) – список городов, в которых данное приложение используется, города связываются с пользователями, и учитывается при авторизации.
Страны (land) – таблица хранит в себе страны происхождения груза
Группы грузов (group) – таблица хранит в себе группы грузов, пример (мясо и мясопродукты принадлежат к группе грузов, мясо птицы к наименованию груза)
Единицы измерения (units) – таблица хранит в себе единицы измерения (пример: голов, млн. шт., тонн, тыс. шт., шт.)
Операции (operation) – таблица хранит в себе тип операций т.е. импортные перевозки, экспортные перевозки, перевозки между странами СНГ и.т.д
Перевозки (traffic) – таблица хранит перевозки и их типы. Как и в случае со справочниками, из-за сходной структуры для перевозок, было принято решение использовать одну таблицу из-за единой структуры и для большего удобства при формировании отчетов.
Пользователи (sys_user) – список пользователей и их привилегии в системе, а также состояние пользователя на данный момент.
Права пользователей (user_rules) – таблица хранит в себе права пользователей, а также указывает какие страницы можно редактировать, поля права пользователей, а также указывают какие страницы можно редактировать, поля generate_report и generate_xml_report, указывают на какой создать отчет, и выгрузить его в формате excel.
Выделено 3 основные части системы:
Административная, для управления настройками ИС, данные привилегии, выделены в отдельную форму, чтобы повысить безопасность и сделать интерфейс более удобным и понятным.
Система ввода данных, основные функции данной ИС, пользователи, используя данные справочников, вводят информацию о движении грузов через ПКВП
Система формирования отчетов в различных форматах. Система отчетов должна быть доступна и пользователям, и администраторам, поэтому выделена в отдельный раздел, отчеты могут быть представлены как визуально, так и с выгрузкой в файл, отчетным периодом может задаваться любой интервал дат.
Для ввода и вывода данных используются стандартные компоненты визуализации, такие как Frame и Swing. Данные введённые пользователем сначала попадают в PKVPController, проводится проверка корректности ввода, соответствие типов данных и диапазонам значений, в случае ошибки в визуальный интерфейс выводятся замечания пользователю.
Для разработки информационной системы были выделены следующие требования: ИС должна состоять из следующих разделов:
1. Раздел авторизации пользователей, по результату авторизации определяется права пользователя в ИС.
2. Раздел администрирования, позволяет пользователю ИС с привилегиями администратора:
a) Добавлять пользователей системы.
b) Редактировать пользователей.
c) Отключать пользователей.
d) Добавлять и удалять данные из следующих справочников:
Группы грузов.
Грузы.
Страны.
Единицы измерения.
3. Раздел ввода данных, позволяет пользователю ИС с обычными привилегиями вводить и обновлять данные в разделы:
a) Импортные перевозки.
b) Экспортные перевозки.
c) Перевозки между странами СНГ.
d) Внутрироссийские перевозки.
e) Перевозки в Таможенном союзе.
4. Раздел отчетности, формирование отчета с возможностью задания диапазона даты начала и даты окончания отчетного периода, по умолчанию даты должны заполнятся. Начальной датой берется, первое число текущего месяца, датой окончания отчетного периода устанавливается дата на текущий день.
5. Раздел журнала регистрации ПКВП, для рядовых пользователей. В этой форме пользователь может ознакомиться с историей перемещения грузов:
a) просмотреть и сделать различные виды сортировок, проанализировать увиденную информацию;
b) просмотреть на каком транспорте перевозился груз.
Рисунок 3 – Структура разрабатываемой системы.
Запросы пользователя с корректными данными попадают в основной класс PKVP, этот класс выполняет необходимую обработку данных, формирует запросы в БД, если запрос в БД занимает продолжительное время, выводит пользователю информацию об этом, чтобы избавить пользователя от эффекта зависания программы.
Обмен данными с базой осуществляется при помощи универсального драйвера ODBC. После обработки данных они попадают в класс PKVPReport класс отвечает за подготовку данных к выводу, вывод возможет как на экран пользователю, так и в файл в формате MS Excel.
Рисунок 4 – Схема архитектуры проекта
-
Мероприятия по разработке эксплуатационной документации.
Ввод системы в эксплуатацию включает:
-
комплексные испытания; -
подготовку кадров для эксплуатации создаваемой системы; -
подготовку рабочей документации, сдачу системы -
заказчику и ввод ее в эксплуатацию; -
сопровождение, поддержку, сервисное обслуживание
План установки ПО содержит описание работ для установки ПО на пользовательских местах, включая подготовку, обучение пользователей и адаптацию существующих систем. Данный план необходим, когда разработчик должен выполнить установку ПО на пользовательских местах и когда процесс установки ПО настолько сложен, что без оформленного в виде документа плана обойтись невозможно. План установки ПО включает в себя:
-
Перечень пользовательских мест, на которых должно быть установлено ПО. -
Запланированные сроки установки ПО. -
Методы установки ПО. -
Организационные сведения: номер телефона, факс, официальное наименование организации, осуществляющей установку, и т. д. -
Технические средства поддержки: перечень всех типов, характеристик и источников средств, необходимых для установки ПО (диски, бумага для принтера и т. д.). -
Организация процесса обучения персонала: классные комнаты, расписание теоретических и практических занятий и т. д.
План передачи ПО определяет аппаратное и программное обеспечение, а также другие ресурсы, необходимые для поддержки жизненного цикла передаваемого ПО, и описывает планы разработчиков для поставки передаваемых элементов через организации, осуществляющие поддержку. Данный план разрабатывают в том случае, если используют концепцию передачи ПО отдельной организации, осуществляющей поддержку. План должен содержать:
-
Краткий обзор системы и документов, относящихся к передаваемому ПО, общий обзор разработки системы и сопровождения. -
Детальное описание ресурсов, необходимых для поддержки передаваемого ПО. -
Перечень рекомендуемых мероприятий, в том числе консультации и лекции, которые должен проводить разработчик в целях поддержки передаваемого ПО и соответствующей среды поддержки.
В плане должны быть указаны предполагаемые области изменений передаваемого ПО. Кроме рассмотренных планов, документация, согласно ГОСТ Р 51904-2002, должна включать ряд описаний.
Опытную эксплуатацию проводят в соответствии с программой, в которой указывают:
1) условия и порядок функционирования частей ИС и ИС в целом;
2) продолжительность опытной эксплуатации, достаточную для проверки правильности функционирования ИС при выполнении каждой функции системы и готовности персонала к работе в условиях функционирования ИС;
3) порядок устранения недостатков, выявленных в процессе опытной эксплуатации.
Во время опытной эксплуатации ИС ведут рабочий журнал, в который заносят сведения о продолжительности функционирования ИС, отказах, сбоях, аварийных ситуациях, изменениях параметров объекта автоматизации, проводимых корректировках документации и программных средств, наладке, технических средств. Сведения фиксируют в журнале с указанием даты и ответственного лица. В журнал могут быть занесены замечания персонала по удобству эксплуатации ИС.
По результатам опытной эксплуатации принимают решение о возможности (или невозможности) предъявления частей АС и системы в целом на приемочные испытания.
Работа завершается оформлением акта о завершении опытной эксплуатации и допуске системы к приемочным испытаниям.
Приемочные испытания проводят в соответствии с программой, в которой указывают:
1) перечень объектов, выделенных в системе для испытаний и перечень требований, которым должны соответствовать объекты (со ссылкой на пункты ТЗ);
2) критерии приемки системы и ее частей;
3) условия и сроки проведения испытаний;
4) средства для проведения испытаний;
5) фамилии лиц, ответственных за проведение испытаний;
6) методику испытаний и обработки их результатов;
7) перечень оформляемой документации.
-
Мероприятия по разработке тестовой документации.
Рассмотрим жизненный цикл проекта:
-
Планирование и анализ требований. -
Проектирование. Создание моделей и представлений проекта: дизайн интерфейса, архитектура, структуры данных, алгоритмов и т. д. -
Кодирование и написание документации. -
Тестирование и исправление недостатков. -
Сопровождение (после выпуска) и усовершенствование.
На каждом этапе жизненного цикла должны выполняться верификация и валидация проекта. Верификация (Verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа.
Валидация (Validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. Тестирование как инструмент верификации и валидации является постоянным процессом и проводится на всех этапах жизненного цикла проекта.
В ходе тестирования на текущем этапе необходимо достичь следующих целей:
-
• Повысить вероятность того, что разрабатываемое ПО будет работать правильно при любых обстоятельствах. -
• Повысить вероятность того, что разрабатываемое ПО будет соответствовать всем описанным требованиям. -
• Предоставить актуальную информацию о состоянии продукта на данный момент.
Рисунок 5 - Структура документации тестирования
План тестирования (Test plan) — это основной документ этапа тестирования, который описывает работы по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
План верификации ПО включает в себя описание процедур верификации, удовлетворяющих целям процесса верификации. Данный план должен включать следующие разделы:
-
Организация: организационная ответственность внутри процесса верификации ПО интерфейсы с другими процессами ЖЦ ПО. -
Независимость: описание методов для обеспечения независимости верификации, когда это требуется. -
Методы верификации: описание методов верификации, которые будут использованы на каждом этапе процесса верификации ПО. -
Среда верификации: описание оборудования для тестирования, инструментальных средств тестирования и анализа, а также руководств по применению этих средств и аппаратного тестового оборудования. -
Критерии перехода: критерии перехода к процессу верификации ПО, определяемому в этом плане. -
Проверка разбиения: если используется разбиение на части, то описывают метод верификации целостности. -
Руководство по повторной верификации: повторная верификация должна гарантировать, что ранее зарегистрированные ошибки или классы ошибок были устранены. -
Ранее разработанное ПО: если для базовой линии ранее разработанного ПО требования к процессу верификации не согласуются с требованиями данного документа, приводят описание методов верификации, удовлетворяющих этим требованиям. -
Многоверсионное ПО: при использовании многоверсионного ПО необходимо описание работ процесса верификации для него.