42
Рисунок 2.2 – Итерационная модель
Спиральная модель
На каждом витке спирали выполняется создание очередной версии продукта,
уточняются требования проекта, определяется его качество и планируются работы
следующего витка. Особое внимание уделяется начальным процессам разработки –
анализу и проектированию, где реализуемость тех или иных технических решений
проверяется и обосновывается посредством создания прототипов (макетирования)
(рисунок 2.3).
Рисунок 2.3 – Спиральная модель
В качестве модели ЖЦ для проекта автоматизации выбрана каскадная
модель, так как она простая в понимании и реализации при учете самостоятельной
разработки системы и сравнительно несложного объема работы.
43
Теперь следует выбрать один из способов внедрения автоматизированной
системы. Различают такие способы:
● «параллельная стратегия», когда устаревшую систему заменяют на
новую;
● «скачок», когда переход к новой системе происходи одномоментно,
скачком;
● «пилотный проект», который позволяет внедрить систему для
ограниченного числа изделий или процессов;
● «узкое место», который означает выполнение внедрения только для
ограниченного числа людей, работающих в рамках автоматизируемого бизнес
процесса.
В качестве стратегии внедрения системы выбрана «узкое место», который
позволит внедрить и протестирования систему учета и обработки заявок на ТО и
ремонт оргтехники на ограниченном (4 человека) числе сотрудников отдела ТО и
ремонта.
2.1.2. Ожидаемые риски в процессах жизненного цикла и их описание
Представим сформированные риски для выбранной каскадной модели ЖЦ
проекта автоматизации.
Рисками для процесса «Разработка требований» являются:
● определение заведомо невыполнимых или избыточных требований;
● определение недостаточного набора требований даже для
минимальных характеристик системы;
● не учет требований заказчика;
● отсутствие документирования требований;
● не привлечение квалифицированного персонала для составления
требований в случаях, когда это необходимо;
● привлечение неквалифицированного персонала.
Рисками для процесса «Проектирование» являются:
● неверное определение рамок и масштаба проекта;
● оценка ошибочных функций системы;
● выбор неправильных технологий и методов решений задач;
● отсутствие различных альтернативных решений;
44
● разработка и утверждение технического задания на проект;
● не привлечение заказчика к утверждению концепции системы;
● отсутствие четко задокументированных результатов данного
процесса.
● недостаточно детализированное ТЗ;
● определение ошибочных функций системы;
● не учет всех требований заказчика в ТЗ;
● отсутствия согласования ТЗ с заказчиком.
Рисками для процесса «Реализация» являются:
● Ошибочное определение функций ИС в целом и ее подсистем, их
целей и эффекта.
● Отсутствие документации на части АС.
● Разработка технического проекта.
● Отсутствие документации на части АС.
● Ошибки в описании функциональной и обеспечивающей частей
системы.
● Ошибочное проектирование информационной базы ИС.
● Ошибочные алгоритмы для решения определенного комплекса задач.
Рисками для процесса «Тестирование» являются:
● Неспособность разработчиков реализовать требуемые функции.
● Ошибки в разработанном программном обеспечении.
● Уход ключевых разработчиков из команды.
● Недопонимание между участниками проекта из-за отсутствия
налаженной системы коммуникации.
● Неверное понимание задачи проектирования.
● Пользовательская документация охватывает не все функции системы.
Рисками для процесса «Ввод в действие» являются:
● Неудовлетворительная производительность системы.
● Несогласованность действий разработчика и специалистов
предметной области.
● Нежелание сотрудников работать с новой системой и связанные с
этим трудности их обучения.
45
● Неучастие руководства в проекте.
● Ошибки в программе, приводящие к невозможности ее
использования.
● Некорректная эксплуатация разработанного ПО.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
В рамках проекта автоматизации следует защитить проектируемую систему
механизмом авторизации.
В рамках приложения предлагается использовать такие типы пользователей:
● Неавторизованный пользователь;
● Авторизованный пользователь:
o
Руководитель отдела ремонта и обслуживания;
o
Заместитель руководителя отдела;
o
Техник по ремонту и обслуживанию.
В рамках работы были сформированы учетные записи пользователей, однако
для обеспечения безопасности они не могут быть представлены в открытом
доступе [1].
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Информационная модель проектируемой системы учета и обработки заявок
на ТО и ремонт оргтехники представлена на рисунке 2.4.
46
Рисунок 2.4 – Информационная модель
Как видно из рисунка, в системе выделены такие таблицы:
● История заявок
● Заявки
● Пользователи ИС
● Файлы, прикрепленные к заявкам
● Статусы заявок
● Типы проблемных ситуаций с оргтехникой
● Приоритеты заявок
В рамках работы с системой оператор выполняет:
● создание заявки
● управление пользователями
● управление заявками
При этом изменяются таблицы:
● История заявок
● Пользователи ИС
● Заявки
● Файлы, прикрепленные к заявкам
47
Остальные таблицы условно постоянны, так как формируются при
инициализации БД и в дальнейшем без веских причин не изменяются.
В результате выполнения операций и изменения таблиц формируются такие
выходные формы:
● История по заявке
● Редактор пользователей
● Список заявок
● Редактор заявок
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
Проектируемая автоматизированная система предназначена для учета и
обработки заявок сотрудников корпорации на техническое обслуживание и ремонт
оргтехники. Система предназначена для ускорения процесса выполнение данных
операций.
В процессе работы информационная система использует различные
справочники.
Нормативно-справочной информацией являются:
● статусы заявок
● приоритеты заявок
● типы проблемных ситуаций с оргтехникой
Данные справочники формируются изначально при инициализации базы
данных. Ответственным за формирование данных справочников является
руководитель отдела технической поддержки предприятия.
Формат справочника статусов заявок представлен в таблице 2.1.
Таблица 2.1
Формат справочника статусов заявок
Имя атрибута
Тип
Код статуса
Целочисленный
Наименование статуса
Строковый
Значения в справочнике статусов заявок представлены в таблице 2.2.
48
Таблица 2.2
Значения в справочнике статусов заявок
001
Заявка создана
002
Подтверждение заявки
003
Заявка подтверждена
004
Установлена дата и стоимость работ
005
Производятся работы
006
Согласование качества работ
007
Работа завершена
Формат справочника приоритетов заявок представлен в таблице 2.3.
Таблица 2.3
Формат справочника статусов заявок
Имя атрибута
Тип
Код приоритета
Целочисленный
Наименование приоритета
Строковый
Значения в справочнике приоритетов заявок представлены в таблице 2.4.
Таблица 2.4
Значения в справочнике приоритетов заявок
001
Высокий
002
Средний
003
Низкий
Формат справочника типов проблемных ситуаций с оргтехникой
представлен в таблице 2.5.
Таблица 2.5
Формат справочника типов проблемных ситуаций с оргтехникой
49
Имя атрибута
Тип
Код типа ситуации
Целочисленный
Наименование типа ситуации
Строковый
Информация
Строковый
Значения в справочнике типов проблемных ситуаций с оргтехникой
представлены в таблице 2.6.
Таблица 2.6
Значения в справочнике типов проблемных ситуаций с оргтехникой
001
Поломка оргтехники
002
Настройка оргтехники
003
Гарантийное обслуживание
004
Постгарантийное обслуживание
Также к нормативно-справочной информации можно отнести и данные о
пользователях системы. Хотя эти данные можно редактировать, но это делается
крайне редко, поэтому эту информацию можно назвать условно-постоянной.
Формат справочника пользователей представлен в таблице 2.7.
Таблица 2.7
Формат справочника пользователей
Имя атрибута
Тип
Код пользователя
Целочисленный
ФИО
Строковый
Внутренний телефон
Строковый
Компания/подразделение
Строковый
Должность
Строковый
Email
Строковый
Пароль для доступа в личный кабинет
Строковый
Тип пользователя
Целочисленный
50
Входной информацией для системы являются адрес/местоположение
объекта/цеха/участка, на котором возникла проблемная ситуация с оргтехникой, а
также описание проблемной ситуации.
Для ввода входной информации в систему применяется специальная веб-
форма, которая представлена на рисунке 2.5.
Рисунок 2.5 – Формат веб-формы для ввода информации в систему
Также входной информацией являются данные о файлах, которые должны
храниться в таблице 2.8.
Таблица 2.8
Формат данных и прикрепленных к заявке файлах
Имя атрибута
Тип
Код файла
Целочисленный
Код заявки
Целочисленный
Имя файла
Строковый
Оперативной информацией является записи о заявках в системе и
изменяющиеся атрибуты у этих записей. Формат записи заявок представлен в
таблице 2.9.
Таблица 2.9
51
Формат записи заявок
Имя атрибута
Тип
Код записи
Целочисленный
Текущий статус
Целочисленный
Тип проблемной ситуации
Целочисленный
Приоритет заявки
Целочисленный
Описание проблемной ситуации
Строковый
Адрес/местоположение объекта/цеха
Строковый
Сотрудник, обнаруживший проблему
Строковый
Стоимость ТО или ремонта
Денежный
Ответственный сотрудник отдела ТО и ремонта
Целочисленный
Оперативной информацией являются и записи в истории работы с заявкой,
формат которых может быть представлен в таблице 2.10.
Таблица 2.10
Формат записи об истории работы с заявками
Имя атрибута
Тип
Код записи в истории
Целочисленный
Код заявки
Целочисленный
Дата изменения статуса
Дата/Время
Код нового статуса
Целочисленный
2.2.3. Характеристика результатной информации
Результатной информацией является список зарегистрированных в системе
заявок (рисунок 2.6), а также временная сводка по работе с той или иной заявкой
(рисунок 2.7).