50
одновременно выполняющих разнообразные приложения, которые оперируют
одними и теми же данными. Он минимизирует соперничество за данные и
гарантирует согласованность данных.
3. поддерживает все описанные выше возможности, при этом
сохраняя высокую степень суммарной производительности системы.
4. пользователи базы данных не страдают от низкой
производительности обработки. Во многих случаях ПО Oracle должно работать
24 часа в сутки, не имея периодов разгрузки, ограничивающих пропускную
способность базы данных. Нормальные системные операции — такие, как откат
базы данных, а также частичные сбои компьютерной системы, — не прерывают
работу с базой данных. Oracle может выборочно управлять доступностью
данных, как на уровне базы данных, так и на более низких уровнях.
Для реализации модуля была выбрана библиотека Electron которая
позволяет разрабатывать нативные графические приложения для
компьютерных операционных систем с помощью веб-технологий: HTML,
CSS, и JavaScript.
Основными плюсами Electron являются:
1. кроссплатформенность (Windows, Linux, MacOS);
2. богатый набор как встроенных, так и сторонних компонентов;
3. настройка компонентов под собственные задачи;
4. наличие языка разметки для описания интерфейса;
5. хорошая поддержка.
2.1.3 Обоснование проектных решений по техническому обеспечению
К техническому обеспечению относится комплекс различных
технических устройств, необходимых для выполнения информационных
процедур: сбора, регистрации, передачи, хранения, обработки и использования
информации. Например, персональный компьютер, периферийные устройства,
устройства ввода/вывода.
51
Требования к техническому обеспечению формировались исходя из
аппаратных требований используемого программного обеспечения, и
представлены в таблице 5.
Таблица 5
Требования к техническому обеспечению
Сервер
Клиент
Процессор
Минимум 2,6 ГГц, 4 ядра
2,6 ГГц
ОЗУ
1 ГБ
1 ГБ
Видеокарта и монитор
VGA монитор (с минимальным разрешением 1280 x
800 точек)
Жѐсткий диск
3 ГБ
3 ГБ
Оптический привод
-
-
Устройство ввода
Клавиатура и мышь
Интернет соединение
10 Мбит/с
256 Кбит/с
Исходя из анализа требований, можно утверждать, что существующих
технических средств на предприятии достаточно и они соответствуют
необходимым требования программного обеспечения, отсутствует
необходимость в замене или покупке новых комплектующих.
2.2 Разработка проекта автоматизации
2.2.1 Этапы жизненного цикла проекта автоматизации
Под моделью жизненного цикла понимается структура, определяющая
последовательность выполнения и взаимосвязи процессов, действий и задач,
выполняемых на протяжении жизненного цикла. Модель жизненного цикла
зависит от специфики информационной системы и специфики условий, в
которых последняя создается и функционирует. [15]
Среди наиболее известных стандартов выделяют следующие:
ГОСТ 34.601 - 90 – описывает стадии и этапы создания
автоматизированных систем.
52
ISO/IEC 12207 - стандарт который распространяется на процессы и
организацию жизненного цикла. Распространяется на все виды заказного
программного обеспечения и не содержит описания фаз, стадий и этапов.
ISO 15288 - устанавливает общую структуру описания процессов
жизненного цикла систем. Он определяет набор процессов и связанную с ними
терминологию с инженерной точки зрения. Эти процессы могут применяться на
любом уровне иерархии структуры системы.
COBIT - является структурой для управления ИТ проектами, созданный
некоммерческой организацией ISACA. Он сочетает в себе методы
корпоративного управления, предоставляя принципы, практики, модели
жизненного цикла и аналитические инструменты.
CustomDevelopmentMethod (методика Oracle) – описывает разработку
прикладных информационных систем - технологический материал,
детализированный до уровня заготовок проектных документов, рассчитанных
на использование в проектах с применением Oracle.
RationalUnifiedProcess (RUP) - описывает итеративную модель
разработки, которая включает в себя следующие фазы: начало, исследование,
построение и внедрение. Каждая фаза может быть разбита на этапы (итерации),
в результате которых выпускается версия для внутреннего или внешнего
использования. Прохождение через четыре основные фазы называется циклом
разработки, каждый цикл завершается генерацией версии системы. Если после
этого работа над проектом не прекращается, то полученный продукт
продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP
- это создание и сопровождение моделей на базе UML.
MicrosoftSolutionFramework (MSF) - включает четыре фазы: анализ,
проектирование, разработка, стабилизация, является итерационной,
предполагает использование объектно-ориентированного моделирования. MSF
в сравнении с RUP в большей степени ориентирована на разработку бизнес-
приложений.
53
ExtremeProgramming (XP) - экстремальное программирование, в основе
этой методологии лежит командная работа, эффективная коммуникация между
заказчиком и исполнителем в течение всего проекта по разработке
информационной системы.
Для задачи разрабатываемой информационной системы подходит
методология ГОСТ 34.601 - 90, которая отличается гибкостью и описывает
процессы жизненного цикла программного обеспечения, имеет четкое
определение терминологии.
По данной методологии, процесс жизни системы или программного
продукта может быть описан посредством каскадной модели жизненного
цикла, состоящей из стадий. Модель может использоваться для представления
всего жизненного цикла от замысла до прекращения применения или для
представления части жизненного цикла, соответствующей текущему проекту.
Каскадная модель жизненного цикла (водопад) - является самой
старой и самой простой из структурированных методологий жизненного цикла
- после завершения одной фазы происходит переход к следующей. Отсутствуют
обратные связи между этапами. Каждый этап основан на информации
предыдущего и имеет собственного плана проекта. Данной методологией легко
управлять, но данная модель не работает, если от проекта требуется гибкий
график или если проект является долгосрочным и продолжающимся.
На каждом этапе каскадной модели формируется законченный набор
проектной документации, отвечающий критериям полноты и согласованности,
что позволяет разработать продукт согласно критериям, также она проста и
удобна в применении, так как процесс разработки выполняется поэтапно, при
правильном использовании модели дефекты можно обнаружить на более
ранних этапах, когда их устранение еще не требует относительно больших
затрат.
Таким образом можно выделить этапы жизненного цикла проекта:
54
1. Сбор требований – на этом этапе первичные требования
анализируются и записываются в документ спецификации, который служит
основой для всей будущей разработки.
Содержит следующие задачи:
сбор исходной информации, требований;
постановка задачи;
выбор и обоснование критериев эффективности и качества
разрабатываемой программы.
2. Анализ - на этом втором этапе разрабатывается проектное решение,
удовлетворяющее всем требованиям, бизнес-логике, которые будут
использоваться в приложении.
Содержит следующие задачи:
определение структуры входных и выходных данных;
предварительный выбор методов решения задач;
обоснование целесообразности применения ранее разработанных
программ;
определение требований к техническим средствам.
3. Проектирование - этот этап в значительной степени охватывает
требования к техническому проектированию, такие как язык
программирования, сервисы. Как правило, создается спецификация проекта, в
которой описывается, как именно будет реализована техническая составляющая
проекта.
Содержит следующие задачи:
уточнение структуры входных и выходных данных;
разработка алгоритма решения задачи;
определение формы представления входных и выходных данных.
определение семантики и синтаксиса языка.
55
4. Кодирование – на данном этапе происходит написание исходного
кода, реализуются все модели, бизнес-логика и интеграция служб, которые
были определены на предыдущих этапах.
Содержит следующие задачи:
программирование;
отладка программы;
разработка программных документов.
5. Тестирование - проводится проверка полученного программного
обеспечения на предмет соответствия требованиям, заявленным в техническом
задании.
Содержит следующие задачи:
проверка требований;
разработка, согласование и утверждение порядка и методики
испытаний.
6. Опытная эксплуатация позволяет обнаружить проблемы в
приложении, которые необходимо решить. Не редко на этой фазе необходимо
снова начать итерацию и исправить выявленные ошибки.
Содержит следующие задачи:
опытная эксплуатация;
модульное тестирование.
7. Сдача готового продукта – завершающим является момент, когда
приложение готово к развертыванию в реальной среде.
Содержит следующие задачи:
подготовка и передача программы и программной;
оформление и утверждение акта о передаче продукта.
Для выполнения этих стадий будут использованы силы штатных
сотрудников компании. На эту задачу были поставлены:
системный администратор (занимается разработкой технического
задания, требований к ИС);
56
программист (занимается разработкой модуля, внедрением,
тестированием, составлением рабочей документации);
начальник производственного отдела (занимается формированием
требований и проверкой).
На первом этапе участниками процесса являются системный
администратор и начальник производственного отдела.
На втором этапе участниками процесса являются системный
администратор и программист.
На третьем этапе участником процесса является программист.
На четвертом этапе участниками процесса является программист.
На пятом этапе участниками процесса являются системный
администратор и программист.
На шестом этапе участниками процесса являются системный
администратор и программист.
На седьмом, завершающем этапе участниками процесса являются
системный администратор, программист, а также начальник производственного
отдела.
Согласно ГОСТу 34.601 - 90 можно выделить типовые стадии создания
информационной системы, представленные в таблице 6.
Таблица 6
Стратегия автоматизации
Стадии разработки
Цель и задачи этапа
1. Формирование
требований к ИС
Научно-исследовательские работы, сбор информации о
подразделении, сбор требований.
2. Разработка
концепции ИС
Определение структуры входных и выходных данных,
сбор исходной информации.
3. Техническое
задание
Постановка задачи, создание технического задания и
приложений к нему, определение стадий, этапов и
сроков разработки программы и документации на нее.
4. Эскизный проект
Общее описание функциональной и технической
архитектур, предварительный выбор методов решения
задач.
5. Технический
Описание функциональной архитектуры (включая
описание каждой функции, задачи, методов
57
Стадии разработки
Цель и задачи этапа
проект
реализации).
6. Рабочая
документация
Разработка программных документов в соответствии с
требованиями ГОСТ 19.101-77.
7. Ввод в действие
Подготовка и передача программы и программной
документации для сопровождения, тестирование,
обучение сотрудников.
Интеграция компонентов модуля в существующую
систему.
8. Сопровождение
Дальнейшее обслуживание системы.
На этапе «Ввод в действие» для поставленной цели была выбрана
стратегия внедрения “Пилотный проект”, которая применяется к
ограниченному числу процессов, то есть будет использоваться на небольшом
участке деятельности. Такой подход снижает риски и наиболее надежен и
менее затратный, однако сложен в реализации.
Процесс внедрения будет состоять из следующих этапов:
Тестирование системы
Отладка и исправление ошибок
Обучение персонала
Опытная эксплуатация
Этап эксплуатации представляет собой сбор информации о
функционировании информационной системы, исправление ошибок и
оформление требований на доработку.
Целью этапа является обеспечение полной функциональности
информационной системы и ее оптимальной работы до конца срока службы
системы.
На этом этапе в работе участвуют следующие сотрудники:
начальник производственного отдела
сотрудники
заинтересованные стороны проекта
Успешное завершение этапа эксплуатации и технического обслуживания
должно включать:
58
мониторинг производительности системы;
выполнение необходимых действий по обеспечению безопасности,
таких как резервное копирование, планирование на случай непредвиденных
обстоятельств и аудит;
продолжение поддержки конечных пользователей посредством
обучения и документации.
Во время разработки документации команда разработчиков системы
должна:
написать исчерпывающие, понятные документы без лишней
информации.
разработать организованное хранилище документов для критически
важной информации о проекте.
использовать или ссылаться на информацию из более ранних
документов, где это возможно и выгодно.
2.2.2 Характеристика нормативно-справочной, входной и оперативной
информации
Входные данные – информация, которая необходима для начала работы
алгоритма. Входные данные берутся из следующих наборов объектов:
Таблица «Проект».
Таблица «Задачи».
Таблица «Сотрудники».
Информация о задаче заполняется начальником производственного
отдела и менеджером отдела ведения проектов.
Для контроля прав доступа к данным справочникам используется
система администрирования и отображено в виде процесса авторизации и
графы «Права доступа». Так внутри системы пользователь с правами
администратора может самостоятельно выдавать права доступа к задачам в
списке. Входная информация данного процесса представляет собой Значение
имени пользователя и пароль.
Данный процесс включает в себя:
59
создание идентификатора субъекта (создание учѐтной записи
пользователя) в системе;
управление данными субъекта, используемыми для его
аутентификации (смена пароля, издание сертификата и т. п.);
управление правами доступа субъекта к ресурсам системы.
Описание справочников, в которых хранится входная информация
показаны в таблице 7.
Таблица 7
Описание используемых справочников и таблиц
Название
справочника
Ответственный за
ведение справочника
Средний объем
справочника
В записях
Средняя
частота
актуализации
Сотрудники
Начальник
производственного
отдела
100
2 раз в месяц
Проект
Начальник
производственного
отдела, менеджер
отдела ведения
проектов
20
10 раз в месяц
Задачи
Начальник
производственного
отдела, менеджер
отдела ведения
проектов
20
10 раз в месяц
Далее следует рассмотреть реквизитный состав справочников. В
таблице 8 указана подробная информация.
Таблица 8
Реквизитный состав справочников
Название справочника
Перечень реквизитов
Сотрудники
Код сотрудника
ФИО
Контактная информация
Паспортные данные
Лицевой счет
Договор номер
Проект
Project_ID
Имя проекта