ГОСУДАРСТВЕННОЕ УЧРЕЖДЕНИЕ ОБРАЗОВАНИЯ
ИНСТИТУТ БИЗНЕСА
БЕЛОРУССКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА
Факультет бизнес-технологий
Кафедра цифровых систем и технологий
Курсовая работа на тему:
РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ УЧЕТА ДЕТАЛЕЙ НА
СКЛАДЕ ЦЕХА
Студентки 5 курса, группа з1551
специальность
«Управление
информационными ресурсами»
Мастыкина Анна Андреевна
Научный
руководитель:
технических наук, доцент
Стацук Ирина Петровна
Минск, 2019
кандидат
ГОСУДАРСТВЕННОЕ УЧРЕЖДЕНИЕ ОБРАЗОВАНИЯ
ИНСТИТУТ БИЗНЕСА
БЕЛОРУССКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА
Факультет бизнес-технологий
Кафедра цифровых систем и технологий
Специальность Управление информационными ресурсами
ЗАДАНИЕ
для выполнения курсовой работы по дисциплине
«Проектирование информационных систем»
студенту Мастыкиной А.А.
1. Тема проекта Разработка информационной системы учета деталей на
складе цеха
2.
Сроки сдачи проекта 24.11.2019
3.
Исходные данные к проекту
1. Назначение системы
2. Масштаб системы
3. Организация информационного обмена
4. Требуемые отчетные данные и их формы
5. Используемые технологии проектирования
6. Другие данные о системе и организации проектирования
4.
Содержание расчетно-пояснительной записки (перечень вопросов,
подлежащих разработке)
Введение.
1. Анализ объекта автоматизации
2. Разработка технического задания.
3 Проектирование информационной системы.
4. Организация тестирования и приемки системы.
Заключение.
Список использованных источников. Приложения.
Задание получил
Задание выдал
Студентка группы з1551 УИР
Мастыкина Анна Андреевна
Дата 20.11.2019
Кандидат технических наук, доцент
Стацук Ирина Петровна
Дата 20.11.2019
2
Оглавление
ВВЕДЕНИЕ ........................................................................................................... 4
1 АНАЛИЗ ОБЪЕКТА АВТОМАТИЗАЦИИ .................................................... 5
2 ПОСТРОЕНИЕ МОДЕЛИ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ .................. 5
2.1 Требования к системе ................................................................................ 6
2.2 Глоссарий проекта ...................................................................................... 6
2.3 Диаграмма вариантов использования ...................................................... 7
3 СТРУКТУРА СИСТЕМЫ ................................................................................ 8
4 ПРОЕКТИРОВАНИЕ КЛАССОВ ................................................................. 10
4.1 Диаграмма концептуальных классов ..................................................... 10
4.2 Диаграмма взаимодействий .................................................................... 12
4.3 Диаграмма состояний .............................................................................. 13
4.4 Диаграмма проектных классов ............................................................... 14
5 ПРОЕКТИРОВАНИЕ СХЕМЫ ДАННЫХ................................................... 17
6 РАЗРАБОТКА ШАБЛОНА КОДА................................................................ 21
7
ОРГАНИЗАЦИЯ
ТЕСТИРОВАНИЯ
И
ПРИЕМКИ
ИНФОРМАЦИОННОЙ СИСТЕМЫ ........................................................................ 24
ЗАКЛЮЧЕНИЕ .................................................................................................. 26
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ .............................................. 27
ПРИЛОЖЕНИЕ А ......................................................................................... 28
ПРИЛОЖЕНИЕ Б ......................................................................................... 45
3
ВВЕДЕНИЕ
Курсовая работа выполняется по дисциплине «Проектирование
информационных систем» по специальности «Управление информационными
ресурсами».
Цель курсовой работы заключается в расширении, углублении и
систематизации теоретических знаний и практических навыков, приобретенных
в процессе изучения дисциплины «Проектирование информационных систем», в
овладении методами принятия технических решений, в приобретении
практических навыков проектирования информационных систем с
использованием CASE средств. Также целью курсовой работы является развитие
навыков разработки и чтения технической документации и приобретение
навыков использования типовых решений, шаблонов и стандартов при
разработке информационных систем.
Программа должна обеспечивать:
- Работу с входными данными (информация о деталях)
- Ведение базы данных (хранение информации о деталях)
- Выгрузка отчетов (анализ использования деталей)
- Все перечисленные операции требуют четкого и правильного
документирования, ведения учета и отчетности. В тоже время, использование
бумажных носителей, ведение рукописного учета продаж и выполненных работ,
предполагает затраты большого количества времени и сил. А также создает
определенные трудности при поиске необходимых данных и их анализе.
Поэтому необходима информационная система автоматизации деятельности
сервиса оцифровки, создание базы данных, где будет храниться вся информация
о деталях, а также иная необходимая информация, связанная с деятельностью
организации. Разработать удобные для работы формы, приятный интерфейс. Всё
это поможет сократить время составления накладных, отчетов и прочих
документов. Позволит хранить информацию об услугах, клиентах, принятых
заказах, структурировать её в более удобный вид, что значительно повысит
эффективность работы.
Данная информационная система может применяться на различный
заводах. Она легка в обращении, позволяет хранить большое количество
сведений в одной базе данных, экономит рабочее время за счет автоматизации
некоторых рутинных операций. Таким образом, система позволит повысить
производительность труда, помогая выполнить работу лучше, быстрее и
дешевле.
4
1 АНАЛИЗ ОБЪЕКТА АВТОМАТИЗАЦИИ
Анализ объекта автоматизации начинается с описания бизнес-процесса, который
необходимо автоматизировать. В данной главе будет подробно описан
автоматизированный бизнес-процесс, который в дальнейшем будет
реализоваться с использованием спроектированной в рамках данной работы
автоматизированной системы управления.
Автоматизируемый бизнес процесс выглядит следующим образом. При
поступлении детали на склад, работник склада вносит данные детали. Далее
когда деталь забирается со склада, рабочий находит в системе по номеру эту
деталь и указывает количество изъятых штук. Также, по запросу, программа
выдаёт отчёт о количестве использованных и оставшихся деталей.
Модель автоматизируемого бизнес-процесса представлена на рисунке 1.1.
Моделирование бизнес-процесса реализовано с помощью нотации BPMN, так как
она максимально подходит для описания сложных семантических конструкций,
использует базовый набор интуитивно понятных элементов.
Рисунок 1.1 – Автоматизированный процесс учёта деталей на складе
Для разработки данной системы разрабатывается техническое задания с
использованием ГОСТ 34.602-89 «Техническое задание на создание
автоматизированной системы». Техническое задание «Автоматизация процесса
учета деталей на складе цеха» представлено в приложении А.
Разработанные в рамках данной главы модель бизнес процесса и техническое
задание в последующем будут использованы для создания диаграммы вариантов
использования и логического проектирования в целом.
2 ПОСТРОЕНИЕ МОДЕЛИ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
5
В данной главе описываются требования к системе, ее функции и варианты
использования на основе разработанного ранее технического задания, а также
разрабатываются глоссарий для проекта, документация основных вариантов
использования.
2.1 Требования к системе
Выявление функциональных и нефункциональных требований к системе
необходимо для того, чтобы правильно сформировать концептуальное описание
системы.
Основные функциональные требования к системе:
•
Ввод данных деталей
•
Учет складских остатков
•
Выгрузка данных по деталям
•
Просмотр данных деталей
Нефункциональные требования к системе
Удобство (Usability) — интерфейс веб-приложения должен быть user
friendly и хорошо работать во всех браузерах.
Надежность (Reliability) — Система должна быть в работоспособном
состоянии 24 часа в день 7 дней в неделю. Раз в 12 часов должны производиться
автоматические бэкапы.
Производительность (Performance) — Реактивное обновление
компонентов веб-приложения (получение новых данных без перезагрузки
страницы).
Возможность поддержки (Supportability) — Реализация ролей
пользователей, позволяющая организовать различные уровни доступа в
приложении.
2.2 Глоссарий проекта
Для проекта был разработан специализированный глоссарий, представленный в
таблице 2.1, термины которого будут использоваться в дальнейшем.
Таблица 2.1 – Глоссарий проекта
Карта детали
Деталь
Рабочий
Акт приёма деталей
Карта,
в
которой
отражена
информация о клиенте
Поставляемая и отслеживаемая в
программе вещь
Сотрудник,
заполняет
карту
деталей, ведет отчетность
Договор по доставке деталей
6
2.3 Диаграмма вариантов использования
Действующими лицами в информационной системе являются рабочий и деталь.
Исходя из информации, представленной в техническом задании, были выявлены
следующие варианты использования информационной системы:
•
Вход в систему
•
Ввод данных детали
•
Учет складских остатков
•
Посмотреть наличие детали на складе
•
Выгрузка данных по деталям
•
Ввести логин/пароль
Учет выручки В таблице 2.2 представлено описание вариантов использования и
как действующие лица их реализуют.
Таблица 2.2 – Описание вариантов использования
№
выход
вход
вид связи
назначение
1
Пользователь Вход в систему Communication
Аутентификация
2
Ввести
Вход в систему
Include
Ввод реквизитов
Логин/Пароль
3
Пользователь
Рабочий
Generalization Ведёт учёт деталей
4
Рабочий
Просмотреть Communication
Анализ данных
карты деталей
5
Рабочий
Внос
Communication Ввод информации
информации в
по поступлению
систему при
поступлении
деталей
6
Рабочий
Внос
Communication Ввод информации
информации в
по изъятию
систему при
изъятии
деталей
7
Рабочий
Выгрузка
Communication
Выгрузка отчета
отчета
Для детального описания был выбран наиболее трудоемкий вариант
использования: «получение отчёта». Для их описания использован шаблон,
предложенный в регламенте Rational Unified Process (RUP).
Наименование варианта использования: Выгрузить отчет
1.
Краткое описание: Сформированная специальным образом выгрузка
данных осуществляемая системой.
2.
Предусловия: в базе данных должны храниться необходимая информация
по выбранным параметрам.
7
3.
Потоки событий: с помощью нажатия определенной кнопки перейти в
форму выгрузки отчет. Выбрать область отчета. Выбрать параметры отчета. По
нажатию кнопки “получить отчет” система выгружает сформированный отчет.
4.
Основной поток: По нажатию кнопки “получить отчет” система формирует
отчет.
5.
Подчинённый поток: Проверка отправленных параметров обработчиком
данных.
6.
Альтернативные потоки: Если параметры не прошли проверку, то
отправляется просьба о повторном введении параметров.
7.
Специальные требования: Должна быть разработана необходимая проверка
обработчиком данных.
8.
Постусловия: Система выгружает сформированный отчет.
9.
Дополнительные замечания: Отсутствуют.
На рисунке 2.1 представлена диаграмма вариантов использования данной
информационной системы.
Рисунок 2.1 – Диаграмма вариантов использования
Теперь, когда выявлены функциональные и нефункциональные требования к
системе и описаны варианты ее использования, можно переходить к разработке
структуры
информационной
системы,
описываемой
диаграммами
использования.
3 СТРУКТУРА СИСТЕМЫ
В данной главе разрабатывается структура информационной системы, а
также требования к составным ее частям. Разрабатываются диаграммы
последовательностей для описания некоторых вариантов-использования.
8
Структуру информационной системы составляет совокупность отдельных
ее частей – подсистем. Подсистема – это часть системы, выделенная по
определенному признаку, поэтому структура любой информационной системы
может быть представлена как совокупность подсистем, обеспечивающих
информационное, техническое, математическое, программное, организационное
и правовое обеспечение
Таблица 3 - Требования к составным частям системы, информационные
связи и связи по управлению.
№
Требования к
Способ реализации
Информационные связи
Необходима
При нажатии на
Через форму
авторизация
кнопку “вход”
открывается доступ к
пользователя через
открывается
ИС согласно
ввод логина и пароля
форма для ввода
назначенным уровням
логина и пароля.
доступа пользователей.
Пользователь,
Если пользователь
Данные изменяются
имеющий право на
является сотрудником,
непосредственно при
это, должен иметь
то на форме,
взаимодействии с
возможность
появляющейся после
главным окном ИС
отредактировать
авторизации
записи в БД
присутствует кнопка,
составной части
1.
2.
для редактирования
новых записей.
Для варианта использования выгрузка отчета, описанного в прошлой главе,
была
построена
диаграмма
последовательностей.
Диаграмма
последовательности при варианте использования «зарегистрироваться в
приложении» представлена на рисунке 3.1.
9
Рисунок 3.1 – Диаграмма последовательности при варианте использования
«получение отчёта»
В данной диаграмме представляется следующая последовательность
действий. Рабочий выбирает область отчета и параметры отчета. Форма
параметров отчета передает параметры Контролеру БД. Контролер БД
обрабатывает входящие параметры и выгружает отчет.
4 ПРОЕКТИРОВАНИЕ КЛАССОВ
В данной главе выделяются объекты системы, на основе которых
описываются модельные классы и связи между ними, а также разрабатываются
диаграмма взаимодействий, с помощью которой описывается динамика
поведения системы, а разрабатываются также диаграммы состояния для сложных
классов системы. Итогом этой главы является разработка диаграммы проектных
классов.
4.1 Диаграмма концептуальных классов
Диаграмма модельных, или как еще называют, концептуальных классов,
разрабатывается для того, чтобы графически представить концепцию работы
всей системы.
В ходе описания системы были выявлены следующие концептуальные
классы, которые представлены в таблице 4.1
Таблица 4.1 – Описание выделенных концептуальных классов
№
класс
Категория или
существительное,
использованное для
идентификации
10
1
2
3
4
6
5
Руководитель
Выбор параметров отчета
Контролер БД
Область отчета
Рабочий
Отчет
Руководитель
Выбор параметров отчета
Контролер базы данных
Область отчета
Рабочий
Отчет
Также, используя информацию описания информационной системы,
выявлены связи, которые также именуются ассоциациями, между
концептуальными классами, которые представлены в таблице 4.2
Таблица 4.2 – Ассоциации между концептуальными классами
№
1
Название
связи
выбирает
выход
вход
Работник
Область
отчета
2
уточняется
Область
отчета
3
передает
4
передает
Выбор
параметров
отчета
Клиент
5
выгружает
Контролер
БД
категория
назначение
взаимодействует Выбор
области
отчета
Выбор
взаимодействует Уточнение
параметров
параметров
отчета
Клиент
взаимодействует Передает
параметры
для выгрузки
Контролер взаимодействует Передает
БД
данные
Отчет
взаимодействует Выгрузка
данных
Теперь, когда есть необходимая информация, можно разработать
графически модель концептуальных классов, которая представлена на рисунке
4.1
11
Рисунок 4.1 – Диаграмма концептуальных классов
4.2 Диаграмма взаимодействий
Диаграмма взаимодействий используется для моделирования процесса
выполнения операций. На ней отображается логика или последовательность
перехода от одной деятельности к другой, при этом внимание фиксируется на
результате деятельности. Сам же результат может привести к изменению
состояния системы или возвращению некоторого значения.
В ходе проектирования была выявлена необходимость разработки
диаграммы взаимодействий для варианта использования “Выгрузить отчет”.
12
Рисунок 4.2 – Диаграмма взаимодействий для варианта использования
«Выгрузить отчет»
4.3 Диаграмма состояний
Диаграммы состояний позволяют описывать поведение отдельных
объектов, а в данном случае, классов информационной системы. Она
представляет собой связный ориентированный граф, вершинами которого
являются состояния, а дуги служат для обозначения переходов из состояния в
состояние.
В ходе проектирования было выявлено, что класс «Каталог» имеет сложную
структуру и несколько состояний, поэтому, он нуждается в описании его
поведения с помощью диаграммы состояний.
Разработанная диаграмма состояний представлена на рисунке 4.3.
13
Рисунок 4.3 – Диаграмма состояний класса «детали»
4.4 Диаграмма проектных классов
Диаграмма проектных классов – это основная диаграмма для создания кода
приложения. При помощи диаграммы классов создается внутренняя структура
системы, описывается наследование и взаимное положение классов друг
относительно друга.
Разработанная диаграмма классов представлена на рисунке 4.4.
14
Рисунок 4.4 – Диаграмма классов
Необходимо отметить, что разработанная диаграмма классов аналогична с
диаграммой концептуальных классов, однако в ней названия классов
представлены в их английских наименованиях, как это требует синтаксис кода.
Был добавлен интерфейс, который реализует представления форм программы.
Связи между классами представлены связями ассоциации, а между классами и
интерфейсом – связями реализации. Классы-представления объединены
названием Boundaries (ограничения), управленческие классы, соответственно,
выделяются названием Control (контроль), а классы-сущности – Entities
(сущности).
Каждый класс имеет свои атрибуты, которые описаны в таблице 4.3. В
рамках данной программы атрибуты имеют следующие типы: строковый (char),
натуральный (int).
Таблица 4.3 – Описание атрибутов классов
Название
№
Класс
Назначение
атрибута
1
registrationForm
Name
Название детали
2
registrationForm
Amount
Количество деталей
3
registrationForm
Arrived
Дата завоза
4
registrationForm
withdrawal date
5
registrationForm
Количество изъятый штук
6
registrationForm
Withdrawal
amount
Worker name
7
registrationForm
login
Логин рабочего
8
registrationForm
password
Пароль рабочего
9
authorizationForm
login
Логин рабочего
10
authorizationForm
password
Пароль рабочего
11
questionnaire
question
Вопрос анкеты
12
questionnaire
answer
Ответ рабочего
13
answers
detailID
Идентификационный номер
детали
14
answers
answerData
Данные ответов
15
sources
sourceID
Идентификационный номер
ресурса
16
sources
sourceName
Название ресурса
17
sources
sourceData
Данные ресурса
Дата изъятия
ФИО рабочего
15
18
result
clientID
Идентификационный номер
рабочего
19
result
resultData
Данные результата
20
resultForm
result
Результат
21
resultForm
resultDate
Дата результата
Идентификационный номер
рабочего
Некоторые классы обладают своими методами, которые в основном имеют
типо данных void (неопределенный), кроме метода processData(), который имеет
булевский тип данных. Методы классов представлены в таблице 4.4
Таблица 4.4 – Описание методов классов
№
Класс
Название метода
Назначение
22
client
clientID
1
mainForm
openRegistration()
Открыть форму
регистрации
2
mainForm
openAutorization()
Открыть форму
авторизации
3
mainForm
openTimetable()
4
mainForm
openConsult()
Открыть форму изъятия
детали
5
mainForm
showForm
Показать форму
6
registrationForm
sendRegistration()
Отправить данные
регистрации
7
registrationForm
showForm()
Показать форму
8
autorizationForm
sendAutorization()
Отправить данные
авторизации
9
autorizationForm
showForm()
Показать форму
10
dataHandler
processData()
Обработать данные
11
questionnaireForm showForm()
Показать форму
12
questionnaire
getQuestion()
Получить вопрос
13
questionnaire
setQuestion()
Ответить на вопрос
14
questionnaire
sendQuestion()
Отправить данные вопроса
15
questionnaire
showForm()
Показать форму
16
questionHandler
processQuestion()
17
questionHandler
sendQuestion()
Открыть карту детали
Обработать данные вопроса
Отправить запрос
16
18
questionHandler
generateResult()
Сгенерировать результат
19
resultForm
showForm()
Показать форму
20
timetableForm
selectAppointment()
Выбрать деталь
21
timetableForm
showForm()
Показать форму
22
consultForm
makeAppointment()
Зарегистрировать запись
23 consultForm
showForm()
Показать форму
Разработанные в данной главе диаграммы концептуальных классов,
диаграмма взаимодействий, диаграмма состояний, диаграмма проектных классов
графически представляют собой всю программную часть информационной
системы. Подобные диаграммы расширяются и изменяются при выявлении
новых требований к системе или же во время программирования системы при
выявлении потребности создания дополнительных классов, их атрибутов и
методов. Следующим действием необходимо разработать структуру данных
информационной системы, которые программа должна обрабатывать.
5 ПРОЕКТИРОВАНИЕ СХЕМЫ ДАННЫХ
В данной главе описывается проектирование схемы данных, а именно,
разработка структуры основной базы данных информационной системы –
клиентская база данных. Именно с ней взаимодействуют большинство классов
программы.
Клиентская база данных хранит в себе информацию о данных деталей
(detailTable), его данных для авторизации (autorizationData), результаты анкеты
(resultData), данные о консультации (consultationData), данные консультанта
(Consulter). Соответственно, разрабатывается пять таблиц. Каждая из таблиц
включает в себя определенные атрибуты, описанные в таблице 5.1.
Таблица 5.1 – Атрибуты таблиц базы данных
Наименование
Атрибут
Значение атрибута Тип атрибута
таблицы
detailTable
detailID (ПК)
Идентификационный
int
номер детали
detailName
Название детали
varchar(50)
dealArrival
Дата привоза
date
detailAmount
Количество деталей
int
detailWithdrawal
Дата изъятия
date
detailWAmount
Количество деталей
int
FL
ФИО рабочего
varchar(50)
17
Наименование
таблицы
Атрибут
Идентификационный
int
номер работника
worker_firstName
Имя работника
varchar(50)
e-mail работника
varchar(25)
worker_mobilePhone
Мобильный телефон
работника
varchar(20)
worker_autorizeID
(ПК)
autorizationData worker_login
WithdrawalData
Фамилия работника
varchar(50)
worker_e-mail
worker_position
resultData
Тип атрибута
WorkerID (ПК)
worker_lastName
Worker
Значение атрибута
Уровень работника
varchar(50)
Идентификационный
номер данных
int
авторизации
работника
Логин работника
varchar(25)
worker_password
Пароль работника
workerID (ВК)
Идентификационный
int
номер работника
resultDataID (ПК)
Идентификационный
varchar(50)
номер результата
resultData
Данные результата
varchar(1000)
result_Date
Дата результата
date
workerID (ВК)
Идентификационный
int
номер работника
Withdrawal ID (ПК)
Идентификационный
int
номер изъятия
Withdrawal _date
Дата изъятия
date
Withdrawal _time
Время изъятия
time(7)
resultData
Данные результата
varchar(1000)
worker_firstName
Имя работника
varchar(50)
worker _lastName
detailID (ВК)
Фамилия работника
vachar(25)
varchar(50)
Идентификационный
int
номер детали
18
worker ID (ВК)
Идентификационный
int
номер работника
Атрибуты таблиц имеют следующие типы данных: натуральный (int),
строковый (varchar), тип даты (date) тип времени (time).
В скобках типов данных атрибутов указывается их длина. Также, необходимо
отметить, что сокращение ПК означает «первичный ключ», иначе говоря, это
уникальное значение в строке таблицы, а сокращение ВК означает «внешний
ключ», то есть, уникальное значение таблицы, с которой связана данная таблица.
Значение первичного ключа необходимо, чтобы взаимодействовать с
определенными строками, а значение внешнего ключа определяет одно из
главных условий связи таблиц.
В представленной структуре базы данных все таблицы связаны связью
«один ко многим» с помощью внешних ключей, кроме таблицы рабочего и
таблицы его авторизационных данных: каждый рабочий может иметь только
один экземпляр авторизационных данных. Также в таблицах указаны функции
создания первичных и внешних ключей, а также индексы для внешних ключей,
необходимые в последующем для создания других элементов базы данных,
основанных на данных таблиц. Также был создан триггер tr_NoModifyResult,
который не позволяет редактировать ячейки данных о результате таблицы
внутри базы данных. Также была создана хранимая процедура, которая включает
полную информацию о изъятии: идентификационный номер изъятия,
идентификационный номер детали, идентификационный номер работника,
название детали, ID детали, имя работника, фамилия работника. В хранимой
процедуре String означает строковый тип данных, а Real означает десятичное
число.
Программа Enterprise Architect, в которой разрабатываются все диаграммы,
необходимые для проектирования данного проекта, позволяет сгенерировать
файл, который хранит в себе код SQL создания всех таблиц, ключей и других
элементов, созданных в рамках диаграммы структуры базы данных.
Сгенерированный код таблиц представлен ниже на примере таблицы
работника. Код остальных таблиц выглядит аналогично.
CREATE TABLE [workerTable]
(
[workerID] int NOT NULL,
[worker_firstName] varchar(50) NULL,
[worker_lastName] varchar(50) NULL,
[worker_e-mail] varchar(25) NULL,
19
[worker_mobilePhone] varchar(20) NULL,
[worker_position] varchar(50) NULL
) GO
Создание всех таблиц начинается с вызова CREATE TABLE, а
заканчивается вызовом GO. Параметр NOT NULL означает, что значение не
может быть пустым, соответственно NULL допускает пустое значение ячеек
столбца.
Сгенерированный код первичных ключей представлен ниже на примере
первичного ключа данных изъятия. Код остальных первичных ключей выглядит
аналогично.
ALTER TABLE [withdrawalData]
ADD CONSTRAINT [PK_withdrawalData]
PRIMARY KEY CLUSTERED ([withdrawalID] ASC)
GO
Создание всех первичных ключей начинается с вызова ALTER TABLE
[(название таблицы] ADD CONSTRAINT [(название первичного ключа]
PRIMARY KEY CLUSTERED ([(столбец первичного ключа)]), а заканчивается
вызовом GO. Параметр ASC означает сортировку по алфавиту.
Сгенерированный код внешних ключей представлен ниже на примере
внешнего ключа таблицы авторизационных данных. Код остальных внешних
ключей выглядит аналогично.
ALTER TABLE [autorizationData] ADD CONSTRAINT
[FK_autorizationData_workerTable]
FOREIGN KEY ([workerID]) REFERENCES [workerTable]
([workerID]) ON DELETE No Action ON UPDATE No Action
GO
Создание всех внешних ключей начинается с вызова ALTER TABLE
[(название таблицы] ADD CONSTRAINT [(название первичного ключа]
FOREIGN KEY ([(первичный ключ таблицы, с которой необходимо связать
данную таблицу)]), REFERENCES [(название таблицы, с которой необходимо
связать данную таблицу)] ON DELETE No Action ON UPDATE No Action и
заканчивается вызовом GO.
Также код генерирует создание индексов внешних ключей таблиц,
соответствующее синтаксису языка SQL, а также выполняется проверка на
существование данной таблицы в базе данных: программа создаст таблицу
только тогда, когда проверит, что такой таблицы на данный момент точно нет в
базе данных.
Разработанную схему данных можно использовать, если необходимо
изменить или расширить структуру базы данных, а сгенерированный код
20
позволяет практически полностью воссоздать базу данных и все ее элементы,
описанные в схеме данных. Это является достаточно полезным инструментом,
так как сокращает время при разработке структуры данных.
6 РАЗРАБОТКА ШАБЛОНА КОДА
В данной главе разрабатывается диаграмма компонентов, из которой в
последующем будет сгенерирован программный код классов информационной
системы на языке C++.
Для проектирования приложения для учёта деталей была разработана ранее
диаграмма классов. Теперь с помощью ее данных необходимо создать
компоненты: Boundaries (границы), Entities (сущности) и Control (контроль). Они
нужны для того, чтобы потом отображать классы на соответствующие
компоненты.
Классы-представления форм, а именно autorizationForm, withdrowalForm,
mainForm, questionnaireForm, registrationForm, resultForm, а также userInterface,
попадают в компонент Boundaries. Классы, контролирующие потоки данных, а
именно dataWorker и questionWorker, попадают в компонент Control. Классысущности, а именно answers, detail, worker, questionnaire, result, sourses, timetable,
попадают в компонент Entities. В результате формируется диаграмма
компонентов, представленная на рисунке 6.1, элементы которых нужно
сгенерировать в код C++.
Рисунок 6.1 – Диаграмма компонентов информационной системы
Как говорилось ранее, код генерируется автоматически с помощью
программы Enterprise Architect, в которой разрабатываются все диаграммы,
необходимые для проектирования информационной системы. В рамках данной
курсовой работы будут рассмотрены примеры создания классов каждого из
21
компонентов. Остальные классы генерируется аналогичным образом. Вариант
генерации кода одного из компонентов Boundaries – registrationForm.h
#include "userInterface.h" class
registrationForm : public userInterface
{ public:
registrationForm();
virtual
~registrationForm();
void
sendRegistration(); void
showForm(); private:
char company;
char e-mail;
char
firstName;
char
lastName;
char
login; char
password;
char
phoneNumber;
char
position;
};
Класс registrationForm состоит из закрытых свойств: company, e-mail,
firstName, lastName, login, password, phoneNumber, position, имеющих тип данных
char. Также он имеет публичные методы sendRegistration и showForm, имеющие
тип данных void. Этот класс имеет подключение к публичному интерфейсу
userInterface.
Также был сгенерирован
файл registrationForm.cpp, содержащий
информацию о включенных в класс методах, который выглядит следующим
образом.
#include "registrationForm.h"
registrationForm::registrationForm(){
} registrationForm::~registrationForm(){
} void
registrationForm::sendRegistration(){
}
void registrationForm::showForm(){
}
Вариант генерации кода одного из компонентов Control – dataWorker.h
#include "authorizationForm.h"
#include "registrationForm.h" class
dataWorker
{ public:
22
dataWorker();
virtual ~dataWorker();
authorizationForm *m_authorizationForm;
registrationForm *m_registrationForm;
void processData();
};
Класс dataWorker включает в себя следующие свойство processData,
имеющего тип данных void. Это свойство обрабатывает данные, которые он
получает из подключенных к нему классов registrationForm и autorizationForm.
Также был сгенерирован файл dataWorker.cpp, содержащий информацию о
включенных в класс методах, который выглядит следующим образом.
#include "dataWorker.h"
dataWorker::dataWorker (){
}
dataWorker::~dataWorker (){
} boolean
dataWorker::processData(){
}
Вариант генерации кода одного из компонентов Entities – result.h
#include "resultForm.h" class
result
{ public:
result();
virtual
~result();
resultForm
*m_resultForm; private:
int detailID;
char resultData;
};
Класс result состоит из закрытых свойств:detailID, имеющий тип данных int,
и resultData, имеющий тип данных char. Он не имеет методов, но его данные
используются мтодами других классов. Этот класс имеет подключение к
классупредставлению resultForm.
Также был сгенерирован файл result.cpp, содержащий информацию о
включенных в класс методах, который выглядит следующим образом.
#include "result.h" result::result(){
} result::~result(){
}
Сгенерированный в рамках данной главы шаблон кода можно использовать
для программирования и последующего расширения информационной системы.
23
7 ОРГАНИЗАЦИЯ ТЕСТИРОВАНИЯ И ПРИЕМКИ
ИНФОРМАЦИОННОЙ СИСТЕМЫ
Заключительная глава данной курсовой работы описывает тестовую часть
информационной системы. В ней также представлены сценарии Smoke-test для
основных модулей информационной системы.
Тестирование – это процесс анализа ПО, направленный на выявление
отличий между его реально существующими и требуемыми свойствами и на
оценку свойств ПО. Тестирование необходимо для того, чтобы поддерживать
полную функциональность информационной системы и определить ее защиту от
внезапных ошибок.
Элементарным тестированием для мобильного приложения является
проверка форм, в которые вводится информация, обрабатываемая в
последующем. Также, необходимы тестовые сценарии для проверки
подключений к серверу и к базам данных. Это то тестирование, которое можно
является очевидным перед разработкой информационной системы, и которое
можно спроектировать еще до разработки программного кода. Остальные
тестовые сценарии можно спроектировать и реализовать при выявлении
необходимости в ходе разработки кода информационной системы.
Приёмочный тест (smoke test) – самый первый и быстрый уровень
тестирования. Если тесты этого уровня не проходят, тестирование прекращается.
Приемочные тесты основных модулей информационной системы представлены
в таблице 7.1.
Таблица 7.1 – Приемочные тесты основных модулей информационной системы
№
Тест-кейс
Алгоритм
выполнения
Ожидаемый
результат
Результат в
случае
неудачи
Регистрация
1
работника
1. Открыть
страницу
регистрации. 2.
Ввести данные. 3.
Нажать кнопку
«подтвердить».
Регистрация
успешно
завершена
Регистрация
работника с
2 неправильно
введенными
данными
1. Открыть
страницу
регистрации. 2.
Ввести данные. 3.
Нажать кнопку
«подтвердить».
Поле до
Сообщение:
стадии
«Неправильно
выполнения
введены данные» остается
пустым
Поле до
стадии
выполнения
остается
пустым
24
№
Тест-кейс
Алгоритм
выполнения
Ожидаемый
результат
Результат в
случае
неудачи
Авторизация
работника
1. Открыть
страницу
авторизации. 2.
Ввести данные. 3.
Нажать кнопку
«подтвердить».
Сообщение:
«Добро
пожаловать в
систему!»
Авторизация
работника с
4 неправильно
введенными
данными
1. Открыть
страницу
авторизации. 2.
Ввести данные. 3.
Нажать кнопку
«подтвердить».
Поле до
Сообщение:
стадии
«Неправильно
выполнения
введен логин или
остается
пароль»
пустым
1. Открыть форму
анкеты.
Сообщение:
«Анкета
временно не
Закрытие
работает в связи с
программы
нарушением
подключения к
БД»
3
Подключение к
БД ссылок на
5
формальные
источники
6 Загрузка деталей
1. Открыть форму
выбора детали
7 Выбор детали
1. Нажать на
интересующую
деталь
Сообщение:
«Происходит
обновление
списка деталей.
Попробуйте
позже»
Поле до
стадии
выполнения
остается
пустым
Закрытие
программы
Перенаправление
Закрытие
на форму изъятия
программы
детали
25
Выбор изъятого
8 (подсвеченного
серым)
№
Тест-кейс
9 Изъятие детали
1. Нажать на
законченные детали
Алгоритм
выполнения
1.
Открыть
форму изъятия.
2.
Ввести
данные. 3. Нажать
подтвердить.
Сообщение:
детали
закончились,
Сообщение
пожалуйста,
выберите другую не появляется
деталь»
Ожидаемый
результат
Сообщение:
«Изъятие
успешно
подтверждено»
Результат в
случае
неудачи
Сообщение
не появляется
Разработанная программа приемки информационной системы в
соответствии с ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»
приведена в приложении Б. Она включает в себя объем программы испытаний
информационной системы, требования к ним, а также саму методику испытаний
в приложении.
Разработанная программа испытаний будет использоваться при реализации
информационной системы. Программа испытаний будет дополняться и
расширяться, а методик испытаний будет становится больше в ходе разработки
информационной системы и появления потребности в новых испытаниях.
ЗАКЛЮЧЕНИЕ
В рамках данной курсовой работы было выполнено проектирование
информационной системы мобильного приложения для учёта деталей на складе.
В ходе проектирования были выполнены следующие задачи:
• проанализирована предметная область информационной системы;
• разработана и обоснована диаграмма вариантов использования
информационной системы;
• выполнено шаблонное описание основных вариантов использования
информационной системы;
• разработано техническое задание информационной системы;
• разработаны диаграммы действий для основных вариантов использования
информационной системы;
26
• разработана диаграмма концептуальных классов, также был обоснован
выбор классов, включенных в диаграмму и выбор связей между ними;
• разработана
диаграмма взаимодействий выбранного
варианта
использования;
• разработана диаграмма состояний выбранного концептуального класса;
• разработана диаграмма проектных классов;
• разработана схема основной базы данных информационной системы и
была выполнена генерация ее кода;
• была выполнена генерация кода классов информационной системы;
• были разработаны основные приемочные тесты информационной
системы;
• были разработаны программа приемки информационной системы и
методика ее испытаний.
Всю проектную информацию, разработанную в рамках данной курсовой
работы необходимо использовать при последующей реализации, тестировании и
эксплуатации информационной системы.
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ
1. Грекул В. Проектирование информационных систем / В. Грекул, Г.
Денищенко, Н. Коровкина – Москва: Издательство «Бином. Лаборатория
знаний» 2008. – 304 с.
2. Хританков А. Проектирование на UML / А. Хританков, В. Полежаев, А.
Андрианов – Екатеринбург.: Издательские решения, 2017. – 240 с.
3. Ньютон, Р. Управление проектами от А до Я / Р. Ньютон – Москва:
Альпина Паблишер, 2017. – 182 с.
4. Назаров С. Архитектура и проектирование программных систем /
Станислав Назаров – Москва: Инфра-М, 2016. – 376 с.
5. Гвоздева Т. Проектирование информационных систем /Т. Гвоздева, Б.
Баллод – Москва: Феникс, 2016. – 512 с.
6. Исаев Г. Проектирование информационных систем /Георгий Исаев –
Москва: Омега-Л, 2013. – 424 с.
7. Семакин И. Основы программирования и баз данных. Учебник для
студентов среднего профессионального образования – Москва: Академия,
2014. – 224 с.
27
ПРИЛОЖЕНИЕ А
РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ УЧЕТА ДЕТАЛЕЙ НА
СКЛАДЕ ЦЕХА
Техническое задание
УТВЕРЖДАЮ
СОГЛАСОВАНО
ГЕНЕРАЛЬНЫЙ ДИРЕКТОР
МЕНЕДЖЕР ПРОЕКТА
ОТ КОМПАНИИ
____________________________
_______
_____________________/______ ______/
«_____»
______________________ 20__г.
______________________/_____
_______/
«_____»
______________________ 20__г.
Лист согласования
СОГЛАСОВАНО:
28
(должность)
(подпись)
(Ф.И.О.)
(дата)
(должность)
(подпись)
(Ф.И.О.)
(дата)
(должность)
(подпись)
(Ф.И.О.)
(дата)
(должность)
(подпись)
(Ф.И.О.)
(дата)
ПРЕДСТАВИТЕЛИ ПРЕДПРИЯТИЯ-РАЗРАБОТЧИКА:
(должность)
(подпись)
(Ф.И.О.)
(дата)
(должность)
(подпись)
(Ф.И.О.)
(дата)
(должность)
(подпись)
(Ф.И.О.)
(дата)
(должность)
(подпись)
(Ф.И.О.)
(дата)
Термины и сокращения
{Граница}
–
{Туннель}
–
внешний поставщик или потребитель стрелки. Находится за рамками
моделируемой системы. Название не детализируется в случаях
однозначного понимания читателями диаграммы или в случаях
неоднозначности.
поставщик или потребитель стрелки. Название не детализируется в
случаях однозначного понимания читателями диаграммы.
29
Бизнес-процесс
–
последовательность действий (подпроцессов), направленная на
получение заданного результата, ценного для организации (далее
Процесс).
Владелец процесса
–
должностное лицо, несущее ответственность за получение результата
процесса и обладающее полномочиями для распоряжения ресурсами,
необходимыми для выполнения процесса.
Входы бизнес-процесса
–
ресурсы (материальные, информационные), необходимые для
выполнения и получения результата процесса, которые потребляются
или преобразовываются при выполнении процесса.
Выходы бизнес-процесса
–
объекты (материальные или информационные), являющиеся результатом
выполнения бизнес-процесса, потребляемые другими бизнес-процессами
или внешними по отношению к организации клиентами.
Исполнитель процесса
–
подразделение или должность сотрудника, выполняющего процесс.
Организационная структура
управления
–
совокупность специализированных функциональных подразделений,
взаимосвязанных в процессе обоснования, выработки, принятия и
реализации управленческих решений (далее Организационная
структура).
Подпроцесс
–
бизнес-процесс, являющийся составной частью вышестоящего процесса.
Процедура
–
бизнес-процесс нижнего уровня, содержащий последовательность
конечных (не требующих дополнительной детализации) операций
(функций).
Управление бизнеспроцесса
–
управляющие воздействия, регламентирующие выполнение процесса.
ИС
–
Информационная система
1.
ВВЕДЕНИЕ
1.1.
Наименование Информационной системы
Полное наименование Информационной системы – разработка информационной
системы учета деталей на складе цеха.
1.2.
Краткая характеристика области применения
Используется для дальнейшего составления стратегии предприятия.
Содержанием стратегии служит набор правил принятия решений, используемый
для определения основных направлений деятельности.
Разработанное мобильное приложение автоматизирует процесс учёта деталей.
Для уменьшения временных затрат, а, соответственно, увеличения
эффективности работ, необходимо создать мобильное приложение.
При
поступлении детали на склад, работник склада вносит данные детали. Далее
когда деталь забирается со склада, рабочий находит в системе по номеру эту
деталь и указывает количество изъятых штук. Также, по запросу, программа
выдаёт отчёт о количестве использованных и оставшихся деталей.
30
2.
ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ
2.1.
Основание для проведения разработки
Основанием для проведения разработки является появление потребности у
завода в автоматизации процесса учёта деталей.
2.2.
Наименование и условное обозначение темы разработки
Наименование – «Автоматизация процесса учёта деталей».
31
3.
НАЗНАЧЕНИЕ РАЗРАБОТКИ
3.1.
Функциональное назначение
Функциональным назначением Информационной
автоматизация бизнес-процессов завода.
3.2.
системы
является
Эксплуатационное назначение
Информационная система должна эксплуатироваться сотрудниками завода, чьи
процессы являются объектом автоматизации.
32
4.
ТРЕБОВАНИЯ К ИНФОРМАЦИОННОЙ СИСТЕМЕ
4.1.
Автоматизируемые процессы
А1.1 Процесс учёта
Владелец процесса
Владельцем процесса является:
№
1
Должность
Рабочий
Подразделение
цех
Предмет деятельности
Учёт деталей
Результат процесса
Основным результатом процесса является ведение учёта деталей в цеху.
33
Диаграмма процесса
Автоматизируемые действия
Используемые документы
№
Действие
Требования к
срокам
Исполнители
Входы
Функция ИС
Инструкции
Выходы
1.
А1.1.1 Запуск приложения
Работник
Автоматизация процесса
учёта деталей
2.
А1.1.2 Вход в систему
Работник
Автоматизация процесса
учёта деталей
1. Ввести необходимые данные.
Автоматизация процесса
учёта деталей
1. Получение данных.
3.
А1.1.3 Обработка данных
Программа
2. Нажать кнопку отправить.
2. Обработка данных скриптом.
3. Отправка ответа.
4.
А1.1.4 Заполнение анкеты
Работник
Автоматизация процесса
учёта деталей
5.
А1.1.5 Получение деталей
Работник
Автоматизация процесса
учёта деталей
51
4.2.
Структура Информационной системы
Информационная система должна иметь следующую структуру: Перечень
модулей и функций Информационной системы
4.4.
№
Модуль ИС
Функция ИС
1.
Предоставление деталей
Автоматизация процесса учёта деталей
2.
Форма регистрации
Автоматизация процесса учёта деталей
3.
Анкета на выдачу деталей
Автоматизация процесса учёта деталей
Требования к функциональным характеристикам
4.4.1. Перечень формируемых отчетов
Система должна обеспечить автоматическое формирование следующих
отчетов:
№
1.
Отчет
Отчет о предоставлении услуги консультации
4.4.2. Требования к системе учёта в целом
Информационная система должна обеспечить автоматизацию процесса
учёта.
Требования к функциональности ИС:
1. Управление процессом учёта на начальном этапе
Предоставление возможности работнику проверки наличия
деталей;
Предоставление работнику возможности добавления новых
деталей в базу;
Предоставление
деталей;
работнику
возможности
изъятия
4.5.
Требования к надежности
4.5.1. Требования к обеспечению надежного (устойчивого)
функционирования Информационной системы
Надежное (устойчивое) функционирование Информационной системы
должно быть обеспечено выполнением Заказчиком совокупности
организационно-технических мероприятий, перечень которых приведен
ниже:
1. Поддержка работоспособности сервера;
2. Использование лицензионного программного обеспечения;
3. Регулярное резервирование баз данных Информационной
системы средствами самой Информационной системы или
средствами используемой системы управления базами данных.
4.5.2. Время восстановления после отказа
Время восстановления после отказа, вызванного сбоем электропитания
технических средств (иными внешними факторами), не фатальным сбоем
(не крахом) операционной системы, не должно превышать времени на
перезагрузку задействованных технических и программных средств при
условии соблюдения условий эксплуатации самих технических и
программных средств.
Время восстановления после отказа, вызванного неисправностью
технических средств, фатальным сбоем (крахом) операционной системы, не
должно превышать времени, требуемого на устранение неисправностей
технических средств и переустановку программных средств.
4.5.3. Отказы из-за некорректных действий оператора
Отказы Информационной системы возможны вследствие некорректных
действий оператора (пользователя) при взаимодействии с операционной
системой. Во избежание возникновения отказов программы по указанной
выше причине следует обеспечить работу конечного пользователя без
предоставления ему административных привилегий. Контроль блокировка
4.6.
Условия эксплуатации
4.6.1. Требования к видам обслуживания
Серверная часть Информационной системы должна обслуживаться и
администрироваться квалифицированным персоналом.
4.6.2. Требования к численности и квалификации персонала
Численность персонала должна быть достаточной для выполнения
автоматизированных процессов в Информационной системе в полном
объеме.
Для работы Информационной системы требуется персонал следующих
категорий – системный администратор и конечный пользователь
Информационной системы – оператор.
Системный администратор должен иметь высшее профильное образование
и сертификаты компании-производителя Информационной системы. В
перечень задач, выполняемых системным администратором, должны
входить:
1. Задача поддержания работоспособности технических средств;
2. Задачи
установки
(инсталляции)
и
поддержания
работоспособности системных программных средств;
3. Задача установки (инсталляции) Информационной системы;
4. Задачи по сопровождению и модификации Информационной
системы.
Клиент (оператор) должен обладать практическими навыками работы с
графическим пользовательским интерфейсом операционной системы.
Персонал должен быть аттестован на II квалификационную группу по
электробезопасности. Поддержка сервера должна осуществляться
беспрерывно, максимально исключая случаи некотролируемых сбоев.
Необходимое количество пользователей будет определено на этапе
внедрения Информационной системы.
4.7.
Требования к маркировке и упаковке
Требования к маркировке и упаковке не предъявляются.
4.8.
Требования к транспортированию и
хранению
Требования к транспортированию и хранению не предъявляются.
4.9.
Специальные требования
Информационная система должна обеспечивать взаимодействие с
пользователем (оператором) посредством графического пользовательского
интерфейса, разработанного согласно рекомендациям компаниипроизводителя операционной системы. Программа должна обеспечивать
высокую защиту данных и удобный и быстрый просмотр необходимой
информации посредством отчетов. Информационная система должна
обеспечивать устойчивую связь клиент-сервер.
5.
ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ
5.1.
Предварительный состав программной документации
Состав разрабатываемых программных документов должен включать в
себя:
1. Техническое задание – назначение и область применения
Информационной
системы,
технические,
техникоэкономические и специальные требования, предъявляемые к
Информационной системе, необходимые стадии и сроки
разработки, виды испытаний;
2. Пояснительная записка – схема алгоритма, общее описание
алгоритма и (или) функционирования программы, а также
обоснование принятых технических и технико-экономических
решений;
3. Руководство оператора – сведения для обеспечения процедуры
общения оператора с Информационной системой в процессе
работы.
6.
СТАДИИ И ЭТАПЫ РАЗРАБОТКИ
Разработка Информационной системы осуществляется поблочно.
Содержание, объемы, сроки разработки и стоимость определяется для
каждого блока и оформляется отдельными дополнениями к договору.
Каждый блок разрабатывается по нижеперечисленным стадиям и этапам.
6.1.
Стадии разработки
Разработка Информационной системы должна содержать стадии:
1. Техническое задание; 2.
Рабочий проект;
3. Внедрение.
6.2.
Этапы разработки
На стадии разработки технического задания должны быть выполнены
следующие этапы:
1. Разработка (доработка существующего) технического задания; 2.
Согласование технического задания;
3. Утверждение технического задания.
На стадии рабочего проектирования должны быть выполнены следующие
этапы работ:
1. Разработка Информационной системы;
2. Разработка программной документации;
3. Испытание Информационной системы.
На стадии внедрения должны быть выполнены следующие этапы
разработки:
1. Тестовая эксплуатация Информационной системы;
2. Доработка Информационной
системы и
документации по возникшим замечаниям;
3. Промышленная эксплуатация Информационной системы.
4. Сдача системы в эксплуатацию
6.3.
Содержание работ по этапам
На этапе разработки требований должны быть выполнены следующие
этапы работ:
1. Постановка (уточнение) задачи;
2. Определение и уточнение требований к техническим
средствам;
3. Определение дополнительных требований к Информационной
системе;
4. Определение стадий, этапов и сроков разработки
Информационной системы и документации на нее;
5. Определение ключевых исполнителей со стороны Заказчика и
закрепление их ответственности за отдельными задачами;
6. Определение потребности во внешних модулях и языков
программирования для них;
7. Согласование и утверждение технического задания.
На этапе рабочего проектирования должна быть выполнена работа по
программированию и отладке программы.
На этапе разработки программной документации должна быть выполнена
разработка программных документов в соответствии с требованиями п. 5.1
«Предварительный состав программной документации» и требованиями
ГОСТ 19.101-77 Единая система программной документации. Виды
программ и программных документов.
На этапе испытаний Информационная система проходит два вида
испытаний:
1. Внутренние испытания при сдаче блока Информационной
системы в опытную эксплуатацию силами Разработчика. При
этом должны быть выполнены перечисленные ниже виды
работ:
разработка, согласование
методики испытаний;
и
утверждение
порядка
и
проведение испытаний;
фиксация результатов испытаний;
корректировка Информационной системы и программной
документации по результатам испытаний.
2. Испытания Информационной системы в ходе тестовой и
промышленной эксплуатации силами Заказчика. При этом
должны быть выполнены перечисленные ниже виды работ:
определение и локализация дефекта в Информационной
системе;
внесение дефекта в реестр дефектов с его подробным
описанием;
устранение дефекта, корректировка Информационной
системы и программной документации по результатам
тестовой и промышленной эксплуатации.
На этапе тестовой и промышленной эксплуатации Информационной
системы должны быть выполнены следующие работы:
1. Выделение типов мобильных устройств, поддержвивающих
информационную систему;
2. Разработка и выполнение тестов Smoke Test и Critical Path Test.
3. Проверка работоспособности форм представления.
4. Проверка алгоритма обработки данных.
5. Работы по подготовке и передаче Информационной системы и
документации в эксплуатацию в подразделениях Заказчика;
6. Обучение пользователей правилам работы с Информационной
системой с фиксацией результатов обучения;
7. Консультирование пользователей по возникающим вопросам,
связанным с работой Информационной системы;
8. Методическая помощь при решении вопросов учета в
Информационной системе.
7.
ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ
После того как каждый блок прошел этап промышленной эксплуатации
Информационной системы, оформляется «Акт сдачи-приемки системы»,
который утверждается должностными лицами сторон, подписавшими
Договор на разработку Информационной системы, или лицами, ими
уполномоченными.
8. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
Вся необходимая документация, разрабатываемая для проектирования,
разработки и эксплуатации информационной системы, должна
соответствовать требованиям ГОСТ 34.201-89, а также согласована
Разработчиком и Заказчиком.
Разрабатываемая общая документация должна включать в себя общее
описание
системы,
технологическую
инструкцию,
руководство
пользователя, описание технологического процесса обработки данных,
файл инсталяции информационной системы и методика испытаний, код
программы и его описание, акт выполненных работ.
ПРИЛОЖЕНИЕ Б
Программа испытаний информационной
системы
Объект испытаний
Полное наименование – Мобильное приложение для автоматизации учёта
деталей
Обозначение – Система.
Испытаний проводятся для всех подсистем и функций Системы. Так же испытания
включают проверку необходимого сетевого оборудования и каналов связи.
Цель испытаний
Целью проведения испытаний является:
- проверка взаимодействия подсистем Системы;
- проверка работоспособности Системы;
- проверка соответствия Системы требованиям приведенным в документе
«Техническое задание»;
- проверка готовности Системы к проведению опытной эксплуатации или приемочных
испытаний на территории Заказчика.
Общие положения
Перечень руководящих документов
Настоящая Программа и Методика Испытаний разработана в соответствии со
следующими документами:
- ГОСТ 34.603-92 Виды испытаний автоматизированных систем.
- РД 50-34.698-90 Автоматизированные системы требования к содержанию
документов. - ГОСТ 19.301-79 Программа и методика испытаний. Требования к
содержанию и оформлению.
- РД 50-34.698-90 Методические указания информационная технология комплекс
стандартов и руководящих документов на автоматизированные системы
автоматизированные системы требования к содержанию документов. Техническое задание.
Место и продолжительность испытаний
Испытательный стенд находится на территории Исполнителя по адресу: г. Минск ул.
Московская, 5
Испытания проводятся в течении 5 дней.
Участники испытаний
В испытаниях принимают участие Заказчик и Исполнитель.
Допускается привлечение экспертов из сторонних организаций.
Перечень ранее проведенных испытаний
До начала данных испытаний тестирования или испытания Системы не проводились
(или были проведены автономные, или комплексные, или опытная эксплуатация).
Перечень предъявляемых на испытания документов
Ниже приведен перечень программной документации, предъявляемой для
использования:
- Паспорт.
- Общее описание системы.
- Технологическая инструкция.
- Руководство пользователя.
- Описание технологического процесса обработки данных (включая телеобработку).
- Инструкция по формированию и ведению базы данных (набора данных).
- Описание программ.
- Текст программ.
Объем испытаний
Перечень этапов испытаний и проверок
Ниже представлен перечень проверок требований изложенных в техническом задании
на создание Системы.
№
Объект
испытаний/
Компонент
объекта
испытаний
1
Система в
целом
№ пункта ТЗ,
требование
4.2. Система должна
протоколировать все
события, связанные с
изменением своего
информационного
наполнения
иметь возможность в
случае сбоя в работе
Система в
целом
Вид
испытания
Оцениваемые
характеристики
4.2. Система должна
2
Наименование
испытания
восстанавливать свое
Проверка
реализации
протоколирования
изменения
информационного
наполнения
Системы
Количество
групп
журнальных
файлов
Предварительные
состояние, используя
ранее
запротоколированные
изменения данных
Последовательность проведения испытаний
Испытания проводятся в следующей последовательности:
Этап 1. Проведение испытаний, описание результатов испытаний, и выявленных
неполадок. Этап 2. Оценка неполадок и определение доработок.
Этап 3. Устранение неполадок.
Этап 4. Передача Системы для проведения дальнейших испытаний.
Этап 1. Проведение испытаний, описание результатов испытаний, и
выявленных неполадок
Члены комиссии по проведению испытаний проводят испытания Системы в
последовательности, указанной в таблице ниже настоящего раздела. При
проведении испытаний Члены комиссии руководствуются методикой проведения
испытаний Перед проведением испытаний должен быть заведен Протокол
испытаний, который подлежит заполнению в процессе проведения испытаний в
соответствии с правилами заполнения. Так же должен быть заведен рабочий
Журнал испытаний.
В ходе проведения испытаний, результаты испытаний фиксируются в колонке
«Результат испытания» Журнала испытаний.
По мере завершения каждого отдельного испытания, результаты испытания
подлежат занесению в раздел «Сведения о результатах наблюдений за правильностью
функционирования АИС» Протокола испытаний.
В случае если все характеристики подлежащие оценке находятся в допустимых
пределах, то в колонке «Оценка результата испытания» таблицы раздела «Сведения о
результатах наблюдений за правильностью функционирования АИС» Протокола
испытаний записывается «Успешно», иначе «Не успешно».
В случае если результата испытания был признан не успешным (колонка «Оценка
результата испытания») или во время проведения испытаний возникла ошибка или
иные неисправности, то результат фиксируется в таблице раздела «Сведения об
отказах, сбоях и аварийных ситуациях, возникающих при испытаниях» Протокола
испытаний, в которой указывается: описание шага который не удалось выполнить.
Также прописывается степень тяжести возникшей неисправности (степень тяжести
определяется на основе раздела "Метрологическое обеспечение испытаний"
Программы испытаний.
Этап 2. Оценка неполадок и определение доработок
В ходе выполнения испытаний производится, оформления результатов испытаний и
выявленных неполадок в Протоколе испытаний, Комиссия по проведению испытаний
определяет очередность и сроки их устранения, руководствуясь критериями
определения степени тяжести обнаруженных неполадок, изложенными в разделе
"Метрологическое обеспечение испытаний", настоящей Программы испытаний.
Протокол испытаний, с отраженными в нем результатами испытаний, выявленными
неполадками, сгруппированными по степени тяжести, очередности, и
рекомендуемыми сроками их устранения должны быть переданы Комиссией по
проведению испытаний Руководителям проекта со стороны Заказчика и Исполнителя.
Руководители проекта со стороны Заказчика и Исполнителя рассматривают
полученные материалы, и совместно принимают решение о перечне необходимых
доработок, и сроках их выполнения, и назначают ответственных за выполнение
доработок со стороны Исполнителя и Заказчика.
Разработанный перечень необходимых доработок, и запланированные сроки их
выполнения подлежат занесению Комиссией по проведению испытаний в раздел
«Сведения о корректировках параметров объекта испытания и технической
документации» Протокола испытаний.
Этап 3. Устранение неполадок
Руководствуясь запланированными сроками доработок, Комиссия по проведению
испытаний назначает ответственных и сроки проведения повторных испытаний по
которым предусмотрены доработки.
Ответственные за выполнение доработок со стороны Исполнителя и Заказчика
производят необходимые доработки в объеме и сроках, указанных в Протоколе
испытаний.
Выполненные доработки передаются для испытаний Комиссии по проведению
испытаний по мере их выполнения.
Комиссия по проведению испытаний выполняет повторные испытания в
соответствии с порядком, и методикой испытаний.
Этап 4. Передача Системы для проведения дальнейших испытаний
После устранения выявленных недостатков, Комиссия по проведению испытаний
оформляет Акт приемки Системы в опытную эксплуатацию или Акт передачи системы
для проведения приемочных испытаний (в зависимости от вида проводимых
испытаний).
Ниже представлена последовательность проведения испытаний.
№ Наименование испытания
День проведения
испытания относительно
даты начала испытаний
1
Проверка
реализации
протоколирования
изменения
информационного наполнения Системы
1
2
Проверка
реализации
резервного копирования
1
4
Тестирование назначения и изменения
прав доступа на уровне записей таблиц БД
логического
2
Проверка использования протокола TCP/IP
5
при взаимодействии подсистем
2
Системы на транспортно-сетевом уровне
Требования по испытаниям программных средств
Каждое программное средства и его отдельные модули должны быть испытаны. Эти
испытания должны показать, что каждый модуль выполняет предназначенную ему
функцию и не выполняет не предназначенных функций.
Программные средства должны пройти испытания на отсутствие компьютерных
вирусов. Испытания программных средств проводятся в соответствии с методикой
испытаний.
Перечень работ, проводимых после завершения
испытаний
По результатам испытаний необходимо оформить отчетную документацию, а также
сделать заключение о возможности приёмки Системы в опытную эксплуатацию или
возможности поведения приемочных испытаний (в зависимости от вида проводимых
испытаний).
Условия и порядок проведения испытаний
Условия проведения испытаний
Испытания Системы проводят в объеме, необходимом для проверки взаимодействия
подсистем Системы и её работоспособности в целом.
Проведению испытаний должно предшествовать:
- Окончание этапа «Разработка рабочей документации. Адаптация программ». Подготовка (обучение) персонала.
- Пуско-наладочные работы.
- Организация и подготовка рабочих мест пользователей и администраторов Системы
для проведения тестирования.
- Формирование приемочной комиссии.
Имеющиеся ограничения
Испытания должны проводится на тестовом стенде Системы.
Срок проведения: начало – 00.00.0000 г., окончание – 00.00.0000г. Данный срок
является базовым и возможно его изменение.
Требования к техническому обслуживанию
Технические средства Системы и персонал должны размещаться в существующих
помещениях Заказчика, которые по климатическим условиям должны соответствовать
ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для
различных климатических районов. Категории, условия эксплуатации, хранения и
транспортирования в части воздействия климатических факторов внешней среды»
(температура окружающего воздуха от 5 до 40 °С, относительная влажность от 40 до 80
% при Т=25 °С, атмосферное давление от 630 до 800 мм ртутного столба). Размещение
технических средств и организация автоматизированных рабочих мест должны быть
выполнены в соответствии с требованиями ГОСТ 21958-76 «Система "Человекмашина". Зал и кабины операторов. Взаимное расположение рабочих мест. Общие
эргономические требования».
Меры, обеспечивающие безопасность
При проведении испытаний Заказчик должен обеспечить соблюдение требований
безопасности, установленных ГОСТ 12.2.007.0–75 «Система стандартов безопасности
труда. Изделия электротехнические. Общие требования безопасности», «Правилами
техники безопасности при эксплуатации электроустановок потребителей» и
«Правилами технической эксплуатации электроустановок потребителей».
Порядок взаимодействия организаций
При проведении испытаний устанавливается следующий прядок взаимодействия
между Заказчиком и Исполнителем.
1. Исполнитель письменно извещает Заказчика о готовности к проведению испытаний
не позднее чем за N дней до срока проведения испытаний указанного в Договоре.
2. Заказчик Приказом назначает срок проведения испытаний и приемочную комиссии,
которая должна включать в свой состав представителей Заказчика и Исполнителя.
3. Заказчик письменно извещает Исполнителя и сторонние организации, которые
должны принять участие в испытаниях.
4. Заказчик совместно с Исполнителем проводят все подготовительные мероприятия
для проведения испытаний на объекте Заказчика, а так же проводят испытания.
5. Заказчик осуществляет контроль проведения испытаний, а также документирует ход
проведения проверок в Протоколе проведения испытаний.
6. Заказчик передает Протокол проведения испытаний Исполнителю.
7. Исполнитель исправляет ошибки в Системе указанные в Протоколе проведения
испытаний.
8. Заказчик осуществляет контроль проведения исправлений.
9. По завершению испытаний Заказчик и Исполнитель подписывают Акт приемки
Системы в опытную эксплуатацию или Акт передачи системы для проведения
приемочных испытаний (в зависимости от вида проводимых испытаний).
Порядок привлечения экспертов
В случае расхождений в оценках результатов испытаний, для разрешения споров,
получения однозначных оценок, допускается привлечение экспертов как со стороны
Заказчики и Исполнителя, так и со стороны сторонних организаций.
Заказчик и Исполнитель совместно инициируют привлечение экспертов. По
результатам проведения экспертизы формируется протокол проведения экспертизы, в
котором излагаются заключения экспертов и рекомендации.
Требования к персоналу, проводящему испытания
Со стороны Заказчика в испытаниях должны принимать участие:
- руководитель проекта, сотрудник Департамента управления проектами;
- системный архитектор, сотрудник Департамента информационных технологий; системный администратор, сотрудник Департамента сопровождения ИС; - конечный
пользователь, сотрудник Отдела анализа.
Со стороны Исполнителя в испытаниях принимать участие:
- системный архитектор;
- разработчик ETL;
- администратор БД; - разработчик BI.
Требования к наличию специальных допусков у персонала проводящего испытания не
предъявляются.
Материально-техническое обеспечение испытаний
Для проведения испытаний необходимо провести следующие работы:
- Силами Заказчика обеспечить доступ к Системе с рабочих мест пользователей. Силами Исполнителя провести установку необходимого программного обеспечения
на рабочие места пользователей и администраторов Системы.
- Силами Исполнителя создать в проектной зоне рабочую папку (\\DWH\) и
предоставить к ней полный доступ участникам испытаний.
Испытания проводятся на компьютерах Заказчика. К конфигурации компьютеров
предъявляются следующие минимальной требования:
CPU: 1 Intel;
RAM: 512 Mb;
HDD: 80Gb;
Network Card: 1 Mb/s;
ОС: MS Windows 2000/XP;
ПО: MS Internet Explorer
ver. 6.0; MS Office ver.
2003.
Метрологическое обеспечение испытаний
Для проведения испытаний Системы не требуется специальных метрологических
приборов, систем и мероприятий.
Для обеспечения единства оценки степени тяжести возможных неполадок
возникающих при проведении испытаний, вводятся следующие оценки степени
тяжести неполадок.
Степень
тяжести
неполадки
Критическая
Условный
вес тяжести
неполадки
2
Определение
Неполадка повлияла на фактическую
эффективность работоспособности таким
образом, что все зафиксированные
фактические значения количественных и
качественных характеристик находятся за
определенными допустимыми пределами.
Серьезная
Незначительная
1
1
Неполадка повлияла на фактическую
эффективность работоспособности таким
образом, что часть зафиксированных
фактических значений количественных и
качественных характеристик находятся за
определенными допустимыми пределами.
Неполадка повлияла на фактическую
эффективность работоспособности таким
образом, что некоторые зафиксированные
фактические значения количественных и
качественных характеристик имеют близкие и
незначительные отклонения определенных
допустимыми пределами.
Отчетность
К отчетным документам относят акт и отчет о результатах испытаний, акт
технического состояния системы после испытаний.
Приложение
Испытание №1. «Проверка реализации
протоколирования изменения информационного
наполнения Системы»
Требование технического задания
4.2. Система должна протоколировать все события, связанные с изменением своего
информационного наполнения.
4.2. Система должна иметь возможность в случае сбоя в работе восстанавливать свое
состояние, используя ранее запротоколированные изменения данных.
Объект испытаний / Компонент объекта испытаний
Контроль, хранение, обновление и восстановление данных.
Требования к испытанию
Перед проведением испытаний должно быть организовано:
- рабочее место Администратора
- подготовлен документ «Журнал проведения испытаний» подготовлен документ «Протокол испытаний»
Порядок проведения испытания
1. Запустить ярлык Database Control на рабочем столе.
2. Ввести с клавиатуры имя пользователя system и пароль пользователя system и
нажать кнопку Login.
3. Перейти на закладку Administration.
4. В разделе Storage выбрать Redo Log Groups.
5. Зафиксировать в колонке «Результат испытания» в «Журнале испытаний»
количество групп журнальных файлов, определяемое количеством строк в таблице
раздела Redo Log Groups.
Характеристики, подлежащие оценке
Количество групп журнальных файлов
Допустимые пределы расхождений
Количество групп журнальных файлов: 5
Порядок обработки результатов испытания
Результат проверки фиксируется в колонке «Результат испытания» в таблице раздела
«Сведения о результатах наблюдений за правильностью функционирования АИС»
Протокола испытаний - для характеристик подлежащих оценке (Количество групп
журнальных файлов) прописывается «Находятся в допустимых пределах» в случае
если зафиксированные значения находятся в допустимых пределах или «Не находятся
в допустимых пределах» в обратном случае.
