Диплом: Исследование и разработка ИС контроля обслуживания дорожно-строительной техники на примере ОАО "Брянскдорстрой"

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
40
Продолжение таблицы 1.4
Наименование
Характеристика
Оперативная память
1 гигабайт (ГБ) ОЗУ (32-разрядный
выпуск); 2 гигабайта (ГБ) ОЗУ (64-
разрядный выпуск)
Жесткий диск (HDD)
не менее 40Гб
Сетевая плата
100Мбит/с
Монитор
не менее17 дюймов,
разрешение 1024х768
Клавиатура
стандартная
Манипулятор «Мышь»
стандартная
Устройство бесперебойного питания
любое
МФУ (принтер, сканер, копир)
любое
41
II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
ГОСТ 34.60190 определяет следующие стадии и этапы создания АИС:
1. Формирование требований к АИС:
обследование организации и обоснование необходимости разработки
ИС;
требования конечных пользователей к системе;
оформление отчёта о проделанной работе (тактико-техническое
задание).
2. Разработка концепции АИС:
изучение объекта автоматизации;
проведение исследовательских научных работ, необходимых для
работы;
разработка вариантов АИС, выбор окончательного варианта, который
будет удовлетворять всем требованиям пользователя;
оформление отчёта о проделанной работе.
3. Разработка технического задания (далее ТЗ). ТЗ – это документ, в
котором сформулированы основные цели разработки, требование к
программному продукту, определены сроки и этапы разработки, и
регламентирован процесс приёмно-сдаточных испытаний.
4. Эскизный проект (макет):
планирование предварительных проектных решений по будущей
системе, по отдельным её частям;
разработка документаций как на АИС.
5. Технический проект:
принятие решений по создаваемой системе;
разработка документаций на систему;
разработка и оформление документации на поставку изделий на
комплектование АИС;
42
оформление технических требований на разработку изделий для
комплектования АИС;
задания на проектирование в смежных модулях ИС.
6. Рабочая документация:
создание рабочей документации;
разработка программ и её адаптация.
7. Ввод в действие:
подготовка предприятия-заказчика к началу установки ИС;
обучение персонала;
комплектование АИС;
строительно-монтажные работы;
пуско-наладочные действия;
предварительные испытания ИС;
опытная эксплуатация установленной и проверенной системы;
приёмочные испытания.
8. Сопровождение АИС:
выполнение обязательств по гарантийному обслуживанию;
послегарантийное обслуживание.
Модель жизненного цикла отражает различные состояния системы в
процессе всего жизненного цикла ИС. Модель ЖЦ – это такая структура,
которая содержит все процессы, действия и задачи по разработке программного
продукта, по его сопровождению и функционированию в течении всей жизни
созданной системы, вплоть до её исчезновения.
В настоящее время известны несколько моделей жизненного цикла, но все
они сводятся к выполнению следующих стадий:
1. Планирование и анализ требований.
2. Проектирование (техническое и логическое.).
3. Реализация (рабочее проектирование, физическое проектирование,
программирование. Разработка и настройка программ, наполнение баз данных,
создание инструкций).
4. Внедрение (Тестирование, опытная эксплуатация. Обучение персонала).
43
5. Эксплуатация (Сопровождение и модернизация. Исправление ошибок и
недоработок. Повторение стадий 2-5 при необходимости).
Для информационной системы, реализуемой в рамках данной работы
будет использована RAD- модель жизненного цикла.
RAD-модель – это модель быстрой разработки приложений. (Рисунок 5)
Решающую роль в такой модели играет конечный пользователь. В тесном
взаимодействии с разработчиками он участвует в формировании требований и
апробации их на работающих прототипах в RAD модели большую часть отводят
планированию и проектированию [3].
Рисунок 2.1 RAD-модель
Модель проходит четыре фазы:
1. Составление требований и планирование (метод совместного
планирования требований: структурный анализ и осуждение задач).
2. Описание пользователя: проектирование ПП, выполняемого при
участии заказчика.
3. Создание – детальное проектирование, кодирование, тестирование
ПП, поставка его заказчику.
4. Сопровождение – приёмочные испытания, установка ПП, обучение
пользователя.
RAD-модель при разработке ИС выбирают, если все требования к
будущей системе определены. Но для её использования требуются
высококвалифицированные кадры. Если заказчики не могут постоянно
участвовать, разработка по этой модели будет невозможна. Так же существует
риск, что работа над ПП никогда не будет завершена.
44
Несмотря на эти недостатки у RAD-модели имеются и преимущества:
сокращение время цикла разработки за счёт современных
инструментальных средств;
привлечение к работе заказчика;
повторно используются компоненты уже существующих программ.
Внедрение информационной системы будет происходит собственными
силами.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Рассмотрим основные риски, которые могут ожидать разработчиков
информационной системы контроля проведения обслуживания дорожно-
строительной техники.
На этапе планирования и анализа требований к информационной системе
возможно неточно определить требований к информационной системе. Еще
одним риском является неправильное определения объема задач
проектирования. Риск предотвращается использованием современных case-
средств при моделировании бизнес-процессов. Составление подробной и
наглядной модели позволит более детально продумать требования и
спланировать работы по проектированию информационной системы.
На этапах технического и логического проектирования информационной
системы основным риском является разработка неправильной информационной
модели и неудобных для пользователя прототипов экранных форм. Для
предотвращения такого риска необходимо на ранних этапах проектирования
согласовывать модели и прототипы экранных форм с представителем заказчика.
На этапе реализации информационной системы основным риском
является ошибки программного кода и нарушение логики работы программы.
Для избегания этого риска необходимо использовать современные средства
разработки, такие как MS Visual Studio 2013, которая позволяет проверять
написанный код.
На этапе внедрения основной риск заключается в недостаточном
тестировании информационной системы, при котором будут выявлены не все
45
ошибки и недочеты. Для снижения этого риска необходимо более тщательно
подходить к тестированию продукта.
На этапе эксплуатации основным риском является моральное устаревание
информационной системы и снижение скорости обработки данных из-за
разрастания базы данных. Для снижения этих рисков необходимо своевременно
дорабатывать информационную систему и следить за оборудование серверов по
обслуживанию базы данных. Еще одним риском на этом этапе является потеря
данных, возникающая из-за выхода из строя оборудования или других факторов.
Для избегания этого риска необходимо своевременно создавать резервные копии
данных.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Доступ к информации в разрабатываемой информационной системе
подчиняется политики разделения прав пользователей. В информационной
системе предусмотрены 2 типа пользователей:
начальник отдела;
сотрудник.
Каждый из пользователей обладает определенными правами для работы в
системе. В таблице 2.1 представлена информация о правах доступа для разных
групп пользователей.
Таблица 2.1
Распределения прав доступа
Функции
Начальник отдела
Сотрудник
Справочник «Сотрудники»
Полный доступ
Доступ запрещен
Справочник «Пользователи»
Полный доступ
Доступ запрещен
Справочник «Техника»
Полный доступ
Полный доступ
Справочник «Типы техники»
Полный доступ
Полный доступ
График техосмотра
Полный доступ
Чтение, запись
Отчеты
Полный доступ
Чтение, запись
46
Для защиты от внешних угроз компьютеры с установленной
информационной системой должны быть защищены антивирусными
программами.
2.2 Управление проектом автоматизации
2.2.1 Описание системы принятия управленческих решений
Решение – это выбор определённого сочетания цели, действий,
направленных на достижение этой цели, и способов использования имеющихся
ресурсов.
В рамках социально-экономических систем решение – это результат
анализа, прогнозирования, оптимизации и выбора альтернативы из множества
вариантов достижения конкретной цели.
Процесс принятия решений может быть подразделен на 2 операции:
выработка рекомендаций специалистами по выбору лучшего варианта и
принятие окончательного варианта непосредственно лицом, принимающим
решение (ЛПР).
Содержание задачи принятия решений в социально-экономических
системах позволяет сформулировать ее особенности:
1. Неизвестные элементы задачи (ситуация, цели, ограничения, варианты
решения, предпочтения) имеют содержательный характер и только частично
определяются количественными характеристиками. Число неизвестных
элементов задачи много больше числа известных.
2. Определение неизвестных элементов задачи и нахождение наилучшего
решения не всегда может быть формализовано, т.к. нет готовых алгоритмов.
3. Часть характеристик может быть измерена субъективно (приоритеты
целей, критериев, вариантов решения).
4. Часто решать задачи принятия решений приходится в условиях
неопределенности, и в таких условиях большое значение имеет интуиция ЛПР.
47
5. Принимаемые решения могут непосредственно затрагивать интересы
ЛПР и специалистов-аналитиков, поэтому их личные предпочтения и мотивы
могут повлиять на выбор решения.
Стадии работ и сроки начала и окончания каждой стадии представлены в
таблице 2.2.
Таблица 2.2
Общий календарный план создания ИС
Название
Даты работ
начало
окончание
Формирование требований к ИС
01.08
08.08
Разработка концепции создания системы
09.08
11.08
Техническое задание (ТЗ)
12.08
16.08
Техническое проектирование (ТП)
17.08
01.09
Разработка рабочей документации (РД)
02.09
12.09
Ввод в действие
13.09
19.09
Согласно календарного плана для разработки информационной системы
контроля обслуживания дорожно-строительной техники понадобиться 49 дней.
2.2.2 Формирование команды проекта автоматизации
Для реализации проекта в рамках диссертации необходимо привлечение
следующих специалистов:
со стороны заказчика:
руководитель проекта;
начальник диспетчерской службы;
начальник отдела АСУ.
со стороны исполнителя:
руководитель проекта;
разработчик.
Руководитель проекта со стороны заказчика должен выполнять
следующие функции:
48
управление планированием и решением оперативных вопросов на всех
этапах проекта;
организация работы проектной группы компании заказчика во всех
стадиях проекта: анализе, дизайне, настройке системы, обучении и
тестировании;
принятие административных решений по организационным вопросам и
вопросам привлечения ресурсов со стороны компании заказчика;
обеспечение своевременной готовности всех данных для заполнения
справочников информационной системы;
обеспечение своевременной готовности инфраструктуры;
согласование и утверждение результатов проекта.
Начальник диспетчерской службы в данном проекте будет выступать в
роли представителей пользователей информационной системы и будет
выполнять следующие функции:
изложение экспертной информации и участие на стадии дизайна
системы;
утверждение и проверка документов по функциональным требованиям
и дизайну системы;
выполнение настройки системы, ввод и перенос данных;
утверждение и проверка учебных материалов;
помощь в обучении конечных пользователей при вводе системы в
эксплуатацию.
Начальник отдела АСУ выполняет роль системного аналитика и
выполняет следующие функции в проектной группе:
определение способа ведения разработки; функционала версий и т.п.;
определение критериев приемки системы;
согласование технологических решений;
согласование технических средств, выделяемых под информационную
систему.
49
Руководитель проекта со стороны исполнителя – обеспечивает полного
выполнение всех обязательств перед компанией заказчик. Его основные
функции:
разработка плана и плана-графика проекта;
контроль и обеспечение прогресса и результатов проекта;
проведение совещаний и регулярных встреч по текущему статусу
проекта;
периодическая отчетность по состоянию проекта перед заказчиком;
планирование и распределение ресурсов, используемых на проекте;
обеспечение своевременного решения вопросов и проблем,
возникающих в ходе проекта;
управление запросами на изменение;
управление процессом контроля качества (тестирования);
координация и планирование создания документации и обучения
пользователей.
Разработчик компании исполнителя – осуществляет все настройки,
конфигурирование и доработку системы, внедрение приложения и его
подготовку к запуску в промышленную эксплуатацию, начальное
сопровождение:
настройка системы;
доработка системы согласно ТЗ;
помощь и обучение специалистов заказчика для выполнения
самостоятельной настройки системы;
обучение специалистов заказчика для выполнения тестирования
системы;
доработка по результатам тестирования;
миграция и преобразование данных;
утверждение документации для пользователей и процедурной
документации.

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

«Психологическое сопровождение персонала в организации на примере ООО «Крокус»
Cовершенствование деловой оценки персонала в организации (на примере ООО "Даймонд кейтеринг развитие")
PR как средство продвижения организации (на примере ПАО "Тамбовский завод "Комсомолец им. Н.С. Артемова")
PR-коммуникации в сфере общественного питания (на примере кафе-кондитерской «Cream Cheese»)
SMM как средство повышения эффективности работы учреждений социокультурной сферы (на примере Малого театра)
Value-based education: ценности в системе образования и способы их реализации на уроке английского языка. Опыт Европейских стран
Work-life balance подход в управлении рабочим временем молодых сотрудников (на примере ООО «МГТ-сервис»)
Автоматизация бизнес-процессов вывода банковского продукта на рынок
Автоматизация бизнес-процессов малого предприятия на примере ООО "Лагонаки"
Автоматизация документооборота организации на примере Дирекции информационных систем АО «Казахтелеком»