Диплом: Автоматизация приема заявок на ремонт и модернизацию ПК в Отделении по Астраханской области Южного главного управления Центрального Банка РФ

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
58
Для осуществления данного проекта была нами предложена спиральная
модель жизненного цикла (рис. 2.1), которая делает упор на начальные этапы
жизненного цикла: анализ и проектирование.
На данных этапах течение технических решений подвергается проверке
путем создания прототипов. Каждый виток спирали сопоставим созданию
фрагмента или версии базы данных «Прием заявок на ремонт и модернизацию
ПК» в От АО ЮГУ ЦБ РФ, на нем уточняются цели и характеристики данного
проекта, определяется также его качество и планируются работы последующего
витка спирали. Таким образом, углубляются и постепенно конкретизируются
детали данного проекта и в результате выбирается в конце обоснованный вариант,
который доводится в дальнейшем до реализации в От АО ЮГУ ЦБ РФ.
Рисунок 2.1. Спиральная модель жизненного цикла ИС [17, c.
113]
Отметим основную проблему спирального цикла – это определение
момента времени перехода на последующий этап. Для ее решения нужно ввести
временные ограничения на фактически каждый из этапов жизненного цикла.
Данный переход осуществляется в соответствии с планом, даже если не вся
запланированная работа по программному продукту закончена.
Наиболее оптимальной считаю спиральную модель, потому, что в ней
учитываются все недостатки, которые имеются в каскадной и задачной модели. В
рамках последующей доработки уже существующей ИС часто появляются новые
59
замечания от пользователей фирмы, которые можно реализовать на проходе
нового витка в спиральной модели.
Для проектируемой системы была выбрана стратегия «пилотный проект»
поскольку система будет автоматизировать только процесс приема заявок на
проведение ремонта и модернизации ПК. В качестве модели жизненного цикла
была выбрана спиральная модель. Стандартом разработки программного
обеспечения будет ГОСТ Р ИСО/МЭК 12207-2010.
2.1.2.Ожидаемые риски на этапах жизненного цикла и их описание
Риски на подэтапе «Анализ требований к ИС». Основной риск на этом
подэтапе - неполное определение всех свойств и параметров ИС, требуемых для
решения задачи, и неверный выбор задач проектирования (очень большой или
недостаточный объем задач автоматизации).
Это может потребовать, на этапе эксплуатации, дополнительной
доработки ИС, что приведет к финансовому риску. Риск предотвращается с
помощью использования современных case-средств при моделировании бизнес-
процессов. При возникновении данного риска проводится дополнительное
моделирование при использовании современных case-средств. На подэтапе
«Выбор и разработка концепции системы» главный риск - это некорректное
определение функций ИС и стратегии автоматизации. На данном подэтапе
существует риск неправильного выбора способа приобретения ИС.
Риск предотвращается с помощью проведения анализом всех вариантов
приобретения ИС. В случае возникновения, риск устраняется проведением
повторного анализа вариантов выбора ИС. Риск взаимосвязан с риском
неправильного определения функций ИС и стратегии автоматизации. Данный
риск предотвращается и устраняется использование современных CASE-средств
в процессе анализа. Риски на подэтапе «Составление и согласование плана по
проведению разработки».
Основной риск - это разработка неэффективного плана-графика
автоматизации: использование избыточных ресурсов или их недостаточность.
Этот риск является финансовым, предотвращается использованием современных
автоматизированных средств проектирования. В случае возникновения, риск
устраняется повторной корректировкой плана-графика автоматизации.
60
На подэтапе «Составление технического задания» основные риски – это
разработка неверной информационной модели и неудобных для пользователя
прототипов экранных форм. Риск предотвращается по согласованию прототипов
экранных форм с будущими пользователями, а устраняется дополнительной
доработкой экранных форм. На подэтапе «Подготовка к разработке ПО» основной
риск - это неправильная формализация расчетов показателей. Риск устраняется
тестированием программных модулей на этапе внедрения.
На подэтапе «Разработка программного обеспечения» основной риск
заключается в некорректной разработке программы. Риск устраняется
посредством использования пилотных проектов при частичном внедрении.
Необходимо учитывать также то, что программные модули будут тестироваться
на этапе внедрения. Риск на этапе «Интеграция и тестирование программного
обеспечения» - это некорректное тестирование технического обеспечения
программных модулей. Риск предотвращается использованием лицензионного
стендового оборудования, а устраняется двойным тестированием.
На этапе «Сопровождение» основные риски - это поломка оборудования,
моральное устаревание ПО и ПС. Первый риск предотвращается регулярным
мониторингом состояния оборудования.
Второй риск предотвращается посредством гибкости разработанной ИС и
своевременной доработкой программной архитектуры. В Таблица (см.
приложение 2) приведена вероятность наступления рисков и степень влияния их
на проект.
Главные риски и методы по их минимизации рассмотрены в таблице 2.1..
Таблица 2.1.
Риски проекта и способы по их минимизации
Виды
рисков/варианты
менеджмента
рисков
Операции
необходимые для
снижения видов
риска
Производимые операции
для снижения вероятности
появления риска
Риски,
которые
связанны с
масштабом
разрабатываемого
проекта
Подробный анализ в
каждом этапе работ,
при взаимодействии
участников,
организации
необходимых работ
Детально
отработаннаяпрограмма
качества, проработанное
управление конфигурацией
проекта,
особые процедуры по
взаимодействию участников
61
Риски, которые
связанны с
недостаточным
опытом в
сфере
информационных
технологий
Проводить обучение
сотрудников, включая
руководство компании,
следование
технологиям работ
Разработка и утверждение
концепции проекта на как
можно более ранней его
стадии проектирования
Технические риски
разрабатываемого
проекта
Правильный отбор
проектной команды по
квалификационным
критериям участников.
Обучение участников
проекта технологии в
проектировании работ,
используя
инструментальные
средства
Применение стандартов
компании в проектных
работах, разработка
стандартов проекта
Организационные
риски
разрабатываемого
проекта системы
Учеба
участников
проекта (курс
"управление
проектом"),
тренировки команды,
как нельзя более
совершенная
формализация
деятельности
Подключение к команде
администратора проекта,
подробное разделение ролей в
проекте
Операционные
риски
разрабатываем
ого
проекта
системы
Неоднократное
тестирование
построенных
продуктов,
скрупулезнаяэ
кспертиза
документов
Правильное выполнение всех
процедур программы качества
2.1.3.Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Рассмотрим аспекты реализации информационной безопасности для
поставленной задачи. Защита системы от внутренних угроз предполагает
добавление в существующую Политику безопасности организации раздела о
разграничении прав доступа к разрабатываемой системе.
Пользователями системы приема заявок на ремонт и модернизацию ПК
будут сотрудники отдела безопасности, а именно подразделение
«Программисты». Программисты должны иметь права на создание и
редактирование заявок и формирование отчетов. Все изменения в системе должны
протоколироваться для возможности выявления лица, нарушившего Политику
безопасности. Определим правила разграничения доступа к разрабатываемой
62
системе. Для того, чтобы определить правила разграничения доступа, выделим
группы пользователей, которые будут работать с разрабатываемой системой:
1. Администратор.
2. Специалист.
3. Руководитель отдела. Затем составим список разделов системы и
опишем права доступа для каждой категории пользователей. Права доступа
представлены в таблице 2.2
Таблица 2.2
Разграничение прав доступа
Раздел
Руководитель
отдела
Администратор
Специалист
Справочники
Редактирование
Создание,
редактирование,
удаление
Просмотр
Заявки
Создание,
редактирование,
удаление
Создание,
редактирование
Отчеты
Просмотр
Просмотр
Защита системы от внешних угроз будет реализована с помощью текущей
Политики безопасности организации: на серверное оборудование компании не
установлены сторонние средства удаленного администрирования. Доступ к
серверу осуществляется с помощью «Remote desktop protocol», в том числе и
сервер приложений и СУБД, где будет установлена серверная версия
разрабатываемой информационной системы. Доступ к серверу осуществляется
только авторизованный.
Для каждого пользователя системы необходима процедура авторизации
для защиты от внутренних угроз информационной безопасности. Ежеквартально
система должно запрашивать изменение пароля при авторизации для каждого
пользователя, при этом необходимо осуществлять проверку того, не ввел ли
пользователь пароль, который уже им использовался для доступа к системе.
Для защиты от внешних угроз необходимо хранение паролей в
зашифрованном виде и обеспечить надежность каналов связи для того, чтобы
избежать перехвата информации. Для обеспечения информационной
безопасности в организации используется программное обеспечение «Kaspersky
Internet Security», который обеспечивает защиту от вредоносного программного
обеспечения, и фильтрует сетевой трафик, благодаря встроенному брандмауэру.
63
Также необходимо обеспечить следующие механизмы обеспечения
информационной безопасности:
защиту базы данных;
систему резервного копирования.
Защита базы данных обеспечивается использованием алгоритмов
шифрования данных. Резервное копирование осуществляется созданием
резервных копий системы лицом, ответственным за обеспечение
информационной безопасности. Защиту от хищения данных злоумышленниками
обеспечивает пропускная система контроля доступа в служебные помещения
организации. Защита от порчи данных регламентируется Политикой
информационной безопасности, которая принята в организации.
На основании вышеперечисленного можно заключить, что в компании
использованы все возможные методы защиты информации, так как нет
уникального одного метода, который смог бы обеспечить полную
информационную безопасность, а сочетание всех методов позволяет реализовать
максимальную информационную безопасность.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Информационная модель представляет собой новый вариант организации
информационной системы, автоматизирующей процесс приема заявок на
проведение ремонта и модернизации ПК. Информационная модель представлена
на рисунке 2.2
Ввод данных в систему будет осуществляться администратором системы,
руководителем сервисного отдела и сотрудником сервисного отдела. В
разрабатываемой информационной системе будут созданы следующие
справочники: сотрудник, отдел, вид комплектующего, вид ремонтных работ,
статус заявки. А также будут таблицы, предназначенные для администрирования
системы: пользователь и право доступа. Для того чтобы осуществлять работу в
системе будут созданы таблицы заявка и стадия заявки. Информационная система
будет содержать формы заявки, формы справочников и отчетную форму. В
результате работы системы будет формироваться отчет по заявкам, который будет
использоваться для контроля принятых заявок.
64
Рисунок 2.2 – Информационная модель
2.2.2Характеристика нормативно-справочной, входной и оперативной
информации
В системе будут доступны следующие справочники:
1. Отдел, содержащий информацию об отделах организации.
2. Сотрудник, содержащий список всех сотрудников организации.
3. Вид комплектующего, содержащий наименования комплектующих для
ПК.
4. Вид ремонтных работ, содержащий перечень ремонтных работ,
осуществляемых с ПК.
5. Статус заявки, содержащий информацию об этапе обработки заявки.
65
Характеристика справочников представлена в таблице 2.3.
Таблица 2.3.
Характеристика справочников
Характеристика
Отдел
Вид
комплектующего
Статус
Заявки
Сотрудник
Вид
ремонтных
работ
Ответственный
за ведение
Администратор
Объем
справочника в
записях
10
15
4
100
100
Частота
актуализации
По мере необходимости
Объем
актуализации
1-10 записей
Реквизитный
состав
Наименование
Наименование
Наименование
Фамилия
Наименование
Имя
Отчество
Телефон
Выходным документом проектируемой системы является отчет по
заявкам, который содержит следующие поля:
1. Номер заявки.
2. Статус заявки.
3. Дата выставленного статуса.
4. ФИО ответственного сотрудника.
5. Дата начала формирования отчета.
6. Дата окончания формирования отчета.
2.2.3Характеристика результатной информации
Результатной информацией задачи будет являться отчет по заявкам, в
котором будет отражена информация о всех заявках за заданный пользователем
период, их статусах и ответственных сотрудников за каждую заявку. Этот
документ используется для контроля работы сотрудников отдела.
В результате пользователю будет выдана отчетная форма, в которой будут
следующие поля:
1. Номер заявки.
2. Статус заявки.
66
3. Дата выставленного статуса.
4. ФИО ответственного сотрудника.
5. Дата начала формирования отчета.
6. Дата окончания формирования отчета.
Результатная информация содержит данные следующих таблиц базы
данных:
Статус.
Заявка.
Стадия заявки.
Сотрудник.
Характеристика таблиц с результатной информацией представлена в
таблице 2.4.
Таблица 2.4.
Характеристика таблиц с результатной информацией
Наименование таблицы
Наименование поля
Статус
Наименование
Заявка
Номер
Дата
Сотрудник
Фамилия
Имя
Отчество
Стадия заявки
Дата
2.3.Программное обеспечение задачи
2.3.1.Общие положения (дерево функций и сценарий диалога)
Функции, которые автоматизирует информационная система делятся на
два типа [16]:
1. Служебные функции.
2. Основные функции.
К служебным функциям проектируемой системы будут относиться:
1. Настройка информационной системы.
2. Управление окнами.
3. Помощь по работе программы.
К основным функциям будут относиться:
1. Редактирование справочников.
67
2. Создание заявки.
3. Просмотр заявок.
4. Редактирование заявки.
5. Формирование отчетов.
На основании перечисленных функций составим дерево функций системы
(рисунок 2.3).
Рисунок 2.3. – Дерево функций системы
Затем, на основании дерева функций системы создадим сценарий диалога.
Для взаимодействия информационной системы с пользователем был выбран язык
типа «Меню» [22].
Разрабатываемый сценарий диалога должен обладать возможностью
определения состава кадров диалога, содержания каждого кадра и их
соподчиненность. В сценарии диалога должно учитываться:
работа с формами входных документов;
формирование результатных документов;
ввод и редактирование и просмотр данных;
протоколирование действий пользователей;

Смотрите также:

"Автоматизация обработки заявок ООО "Проектно-Строительная Компания"
"Автоматизация процесса аттестации персонала для ООО "Нэт Бай Нэт Холдинг"
"Анализ интернет-активности конкурентов ( на примере конкурентов "Газпром нефть")
"Бухгалтерский учёт и аудит расчётов с подотчётними лицами в организации на примере ООО "ЛОЦ 10""
«Психологическое сопровождение персонала в организации на примере ООО «Крокус»
Cовершенствование деловой оценки персонала в организации (на примере ООО "Даймонд кейтеринг развитие")
IPO - инструмент финансирования деятельности организации. На примере ПАО «Нефтяная компания «Лукойл»
PR как средство продвижения организации (на примере ПАО "Тамбовский завод "Комсомолец им. Н.С. Артемова")
PR-коммуникации в сфере общественного питания (на примере кафе-кондитерской «Cream Cheese»)
SMM как средство повышения эффективности работы учреждений социокультурной сферы (на примере Малого театра)