49
Рисунок 1.10 – Диаграмма вариантов использования ИСУРКТ
Из диаграммы вариантов использования видны основные
пользовательские роли ИСУРКТ: сотрудник (обычный пользователь),
администратор, мастер, руководство.
Требования к ИСУРКТ
Формальные требования формулируются исходя из
функционального описания системы и диаграммы вариантов
использования. Все требования к программным системам обычно
соотносятся с тремя уровнями.
Верхний уровень – бизнес требования.
Средний уровень – требования пользователя.
50
Нижний уровень – функциональные требования.
Применительно к ИСУРКТ, выделяются следующие требования.
1. Бизнес-требования:
1.1. Система должна обеспечить достоверные сводные данные для
анализа.
1.2. Система должна повысить эффективность процессов контроля и
управления техническими ресурсами магазина за счет сокращения
времени проведения тривиальных операций и минимизации числа
ошибок при вводе данных и составлении документов.
1.3. Система должна разграничить права доступа к данным и операциям.
2. Требования пользователя:
2.1. Для каждой роли должно быть предусмотрено собственное меню
подсистем.
2.2. Ввод данных в систему посредством диалогов.
2.3. Наличие главного меню действий программы на панели
инструментов, которая всегда должна быть доступна.
2.4. Обеспечить табличное представление данных справочников и
основных операций.
2.5. Вывод документов по операциям в отдельном окне в HTML-
формате.
2.6. Вывод сводных данных в виде диаграмм.
3. Функциональные требования:
3.1. Операции, доступные обычному пользователю:
3.1.1. Обзор подчиненных единиц компьютерной техники.
3.1.2. Обзор созданных заявок на ремонт и результатов их выполнения.
3.1.3. Создание заявок на ремонт техники с указанием характера
неисправности.
3.2. Операции, доступные для мастера:
51
3.2.1. Регистрация и комментирование выполненных заявок.
3.2.2. Учет закупленных по заявкам запчастей и комплектующих.
3.2.3. Возможность «закрывать» заявку в нормальном режиме
«выполнена» и режиме отмены ремонта «списание техники».
3.3. Администратору должно быть доступно ведение таблиц (списков)
категорий технических средств, сотрудников, технических средств.
При этом администратор должен иметь возможность выполнять
любые манипуляции над данными: добавление, редактирование,
удаление.
3.4. Для руководителя должны быть доступны функции формирования
сводных отчетов: по списку и состоянию технических ресурсов
Предприятия, по выполненным ремонтам.
1.4.3. Обоснование проектных решений по техническому обеспечению
Технический комплекс системы представляет собой:
Набор рабочих станций (персональных компьютеров) стандартной
конфигурации, на которой возможен запуск операционной системы
Windows 10 – каждая рабочая станция соотносится с местом менеджера.
Выделенный сервер для доступа к глобальной сети (для организации
обмена данными и коммуникациями с клиентами).
Сервера базы данных (рекомендуется использовать конфигурацию,
указанную в спецификации требований операционной системы
WindowsServer 2008).
В составе комплекса технических средств (КТС) системы
применяются:
системный блок персонального компьютера, включающий набор
основных и периферийных комплектующих;
монитор;
клавиатура, устройство позиционирования «мышь»;
принтер;
52
блок бесперебойного питания (UPS).
Технические средства системы должны соответствовать основным
требованиям:
ГОСТ 12999-84 - по устойчивости к внешним воздействиям;
ГОСТ 21128-83 – по параметрам электроснабжения.
Все технические средства должны быть рассчитаны на длительную
работу. Рекомендуется также регулярно производить профилактические работы
для предотвращения возможных сбоев технических средств.
Минимальные требования к вычислительному комплексу:
ПЭВМ типа IBM PC на базе процессора Pentium, Celeron 3 ГГц и
выше фирмы Intel или аналогичных;
ОЗУ объемом 8 ГБ и выше с учетом требований операционной
системы;
свободное место на HDD – от 20Гб и более;
объем видеопамяти: 1024 Мб и больше;
набор контроллеров USB для подключения внешних периферийных
устройств.
Ручной ввод данных в системе осуществляется при помощи
комбинированного использования следующих устройств:
клавиатура (стандартная, 101 / 102 клавиши);
манипулятор типа “мышь”.
Вывод данных осуществляется:
на монитор персонального компьютера;
на принтер (печать документов);
в каталог документов на диске.
Расположение рабочего места пользователя должно соответствовать
всем правилам безопасности, эргономики и технической эстетики.
53
2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Процессы жизненного цикла проекта автоматизации
Разработка программного обеспечения является итерационным
процессом, поскольку связана с постоянным внесением правок и
дополнений на разных этапах жизненного цикла проекта. Правки могут
возникать по различным причинам – от ошибок проектирования,
допущенных разработчиками, до изменения условий и исходных данных
заказчика.
Поддержку модели итеративного процесса разработки предоставляет
методология RationalUnifiedProcess (RUP). Данная методология
подразумевает последовательное выполнение 4-ёх основных этапов:
начало, проектирование, построение (разработка), внедрение. Все эти
этапы могут осуществляться в несколько проходов (итераций), каждый из
которых подразумевает выпуск очередной новой версии продукта или
спецификации.
В завершении прохождения всех этапов после внедрения
программного продукта начинается срок опытной эксплуатации, в
пределах которого может быть принято решение о внесении изменений в
проект. Так определяется итеративный процесс разработки.
На этапе проектирования для программного продукта строятся
различные статические и поведенческие модели, определяющие
направления работы на этапе разработки. На этапе проектирование
большую роль имеет правильно построить концептуальную модель
продукта (объектную и компонентную структуру, алгоритмы поведения,
схему коопераций основных объектов, и т.д.). При этом важную роль
выполняет унифицированный язык моделирования UML. Суть работы в
рамках RUP — это создание и сопровождение моделей на базе нотаций
UML.
54
В таблице 2.1 приведена характеристика основных этапов
жизненного цикла создания ИСУРКТ в соответствии с выбранной
методологией RUP. В таблице по каждому этапу указаны исполнители,
цели, данные и результаты.
Таблица 2.1
Характеристика этапов жизненного цикла ИСУРКТ
Цель
Ключевые
участники
Входная
информация
Результаты
Начало
Планирование
работ. Составление
целей, бюджета.
Выбор
инструментов
проектирования и
реализации.
Разработчик,
Заказчик
Исходные
данные на
проектирование
Модель
прецедентов,
подобранная
инструментальная
база.
Проектирование
Разработка
эскизного проекта
ИСУРКТ,
определяющего
архитектуру и
поведение
системы.
Разработчик
Исходные
данные,
требования
Эскизный проект
ИСУРКТ и его
спецификация
Построение
Разработка
системы, создание
комплекта
документации на
ИСУРКТ.
Разработчик
Эскизный
проект ИСУРКТ
Технический проект
ИСУРКТ, версия
программного
обеспечения файлы
файл дампа БД,
документация на
ИСУРКТ
Внедрение
Развертывание
ИСУРКТ в среде
заказчика и ее
передача,
испытания
системы,
исправления и
доработки
продукта, обучение
персонала.
Разработчик,
Представители
заказчика
(пользователи)
Реализованный
продукт (файлы
проекта
ИСУРКТ, БД),
документация
Подписанный акт
приемки системы,
результаты оценки
качества
разработанного
продукта.
55
Автоматизация с деятельности технического отдела предполагает
применение новой информационной системы (ИСУРКТ), которая должна
обеспечить решение поставленных задач и повысить эффективность всего
отдела в целом. Таким образом стратегия внедрения ИСУРКТ будет
представлять собой опытную эксплуатацию пилотного проекта. В рамках
такой стратегии должны быть выполнены следующие работы:
Развертывание системы в среде заказчика. Результатами данной
работы должны стать подготовленные рабочие места пользователей
для проведения тестирование ИСУРКТ. При этом производится
инсталляция ПО ИСУРКТ на рабочие места пользователей,
разворачивается БД на сервере БД (из подготовленного файла дампа
БД или скрипта его формирования на языке описания данных),
наполнение базы необходимой информацией справочников. Работа
этого этапа выполняется сотрудниками технического отдела при
участии разработчика (в режиме консультанта).
Проведение тестовых испытаний системы. Данная работа определяет
процесс тестирования ИСУРКТ с целью определения и проверки
соответствия предъявленным требованиям количественных и
качественных характеристик системы, выявления и устранения
недостатков в работе системы и в содержании документации на ее
части. В результате тестовых испытаний должно быть установлено
полное соответствие результатов работы системы предъявляемым
требованиям. Результаты тестирования ИСУРКТ заносятся в
соответствующий протокол.
Выполнение доработки ИСУРКТ осуществляется разработчиком в
соответствии с протоколом проведенного тестирования, если были
выявлены недостатки или замечания. Результатом данного этапа
56
являются новые версии программного /информационного/
организационного обеспечения (либо отдельные их модули).
Подготовка пользователей к работе с ИСУРКТ. Данная работа
необходима для ознакомления пользователей с навыками работы в
ИСУРКТ. Ознакомление производится в соответствии
сруководством пользователя. Окончание работы сопровождается
началом срока опытной эксплуатации ИСУРКТ.
Опытная эксплуатация системы проводится в течение гарантийного
срока эксплуатации, в рамках которого должны быть тщательно
оттестированы все функции системы. При этом составляется
перечень замечаний для будущего устранения. После окончания
периода гарантийной эксплуатации ИСУРКТ разработчик передает
заказчику комплект финальных материалов проекта «AsBuilt»,
содержащих последнюю версию программного и информационного
обеспечения, файлы технического проекта (модели системы,
исходные коды программ), документацию. Исходные коды проекта
могут не передаваться заказчику – данное требование
устанавливается на начальном этапе заключения соглашения.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Проекты, связанные с разработкой программных систем, на каждом
из этапов жизненного цикла имеют свои риски. К таким относятся,
например, недостатки планирования сроков, нарушение требований, отход
от спецификаций.
При разработке ИСУРКТ выделены следующие типы рисков и меры
по их снижению:
1. Неоднозначность требований – предотвращается за счет
разработки формальной модели требований с однозначными
формулировками.
57
2. Недостатки календарного планирования – предотвращаются за
счет планирования работ с возможностью параллельного их
выполнения, а также применения средств автоматизированного
проектирования.
3. Повреждение информации – предотвращается посредством
защиты БД паролем квалифицированного уполномоченного
пользователя, а также четкого разграничения прав доступа для
различных типов пользователей.
4. Аварийное завершение работы программы из-за внутренних
ошибок – разрешается интенсивным использованием
обработчиков исключений в коде программы, а также проверкой
введенных пользователем данных.
5. Неоптимальная организация хранения данных – предотвращается
посредством автоматизированного проектирования
информационного обеспечения, нормализации базы данных.
6. Трудность в эксплуатации – может быть снижена за счет
разработки подробного руководства пользователя.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты
информации
Защита информации от внутренних угроз обеспечивается наличием
системы прав доступа различных типов пользователей к функциям и
данным ИСУРКТ. При этом выделяются следующие основные роли:
Пользователь – может просматривать списки технических средств,
входящих в область его ответственности, создавать заявки на
ремонт.
Мастер – может просматривать созданные пользователями заявки на
ремонт и управлять ими.
58
Руководитель – может просматривать сводные данные по
техническому отделы: затраты на ремонты, состояние технических
ресурсов.
Администратор – может управлять основными справочниками
(сотрудники, технические средства, категории, и т.д.).
Защита данных от внешних угроз осуществляется следующими
методами:
Применения антивирусного ПО.
Использование пароля для СУБД.
Блокировка свободных портов в сетевой инфраструктуре.
Проверка введенных пользователем данных.
Резервное копирование содержимого БД.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Информационная модель ИСУРКТ приведена на рисунке 2.1.
Модель приведена для демонстрации влияния всех типов ролей
пользователей на информационные потоки с использованием средств ИС.
Так, сотрудники (пользователи) создают заявки на ремонт технических
средств. Эти заявки получает мастер технического отдела, реагируя на них
и регистрируя выполненные ремонты и действия. По завершению ремонта
пользователь, создавший заявку, получает соответствующее уведомление
от ИС, инициированное мастером.
Роль администратора состоит в управлении данными основных
справочников информационной системы.
Роль руководителя заключается в формировании и анализе итоговых
сводных данных по состоянию технических ресурсов Предприятия и по
результатам деятельности мастеров технического отдела.