34
реляционных СУБД, в сравнении с ними имеет более высокую
производительность, масштабированность и позволяет работать с разнородными
структурами данных. Это очень важно при разработке системы автоматизации
учета рабочего времени, в которой планируется также внесение перечня задач,
комментариев и иной информации. Поэтому именно этот подход планируется
для разработки информационной системы.
1.4.2. Обоснование проектных решений по программному
обеспечению
В качестве проектных решений по программному обеспечению
рассматривается три основных типа:
- системное программное обеспечение, которое будет установлено на
компьютеры конечных пользователей;
- система управления базой данных (СУБД), необходимая для
создания и дальнейшего управления и взаимодействия с базой данных (БД);
- инструментальная среда для разработки прикладного программного
обеспечения.
В качестве операционной системы была выбрана уже установленная в
организации Windows 10. Такое решение было принято по нескольким
причинам:
- данная операционная система является наиболее современной и
функциональной из существующих систем, поддерживается разработчиками;
- Windows 10 хорошо совместима с различными программными
средствами и разрабатываемым приложением;
- не требуются дополнительные затраты на внедрение и установку
приложений;
- не требуется обучение работников.
Для разработки БД рассматривалось несколько вариантов современных
СУБД, таких как:
- InterBase;
- Microsoft SQL Server;
- MongoDB.
Microsoft SQL Server это современная СУБД, которая предназначена для
анализа и управления реляционными базами данных, оснащена современным
движком, позволяющим выполнять различные сложные задачи. Имеет широкие
возможности для формирования статистической и отчетной информации,
проведения анализа данных. Однако, данная СУБД требует четкую
структуризацию данных [9].
InterBase - это реляционная система управления базами данных от
компании Borland с открытым кодом. Имеет широкие возможности для
разработки БД, обладает высокой производительностью и простотой
администрирования. Недостатком является сложность масштабирования и
необходимость хранения типизированных данных. В случае с поставленной
задачей, требуется хранить документы различной структуры, для чего неудобно
использовать реляционные БД.
MongoDB - это документоориентированная СУБД, которая хранит JSON-
данные, сгруппированные в коллекции. В этом формате возможно хранить
любые JSON-документы, которые удобно разделять на категории и коллекции.
Содержащийся в MongoDB JSON-документ называется двоичным JSON или
BSON и, как любой другой документ этого формата, является
неструктурированным. Поэтому, в отличии от традиционных СУБД, в
коллекциях можно сохранять любые виды данных, и эта гибкость сочетается с
горизонтальной масштабируемостью базы данных.
При создании приложения, концепция которого подразумевает работу с
документами, MongoDB будет хорошим выбором. База данных для
обслуживания такого приложения должна быть легко расширяемой, и здесь
MongoDB подойдет как нельзя лучше.
MongoDB подойдет там, где база растет, документы не требуют связности
и их структура варьируется достаточно сильно.
Для разработки приложения рассматривались следующие
инструментальные варианты:
- Delphi;
- Microsoft Visual C++;
- JavaScript.
35
Delphi имеет мощный набор компонентов для работы с базами данных.
Позволяет разрабатывать программы, которые включают в себя
многофункциональный интерфейс. Упорядоченный набор данных хорошо
взаимодействует с разными базами данных, как с локальными, так и с
промышленными. Например, с такими, как, Oracle или MS SQL Server. Delphi
позволяет управлять базами данных на логическом уровне, не применяя
низкоуровневые запросы к драйверам. Однако данная среда используется для
разработки реляционных баз данных.
Microsoft Visual C++ имеет широкие возможности для создания
графических приложений, однако, требует большой длительности разработки и
громоздкий код. В сравнении с двумя другими рассматриваемыми вариантами
хуже подходит для разработки web-приложения для работы с базой данных.
JavaScript прекрасно подходит для быстрой разработки web-приложений.
Быстрый для конечного пользователя: сценарий Java написан для клиентской
стороны, для поддержки веб-сервера не требуется поддержка. Он также не
нуждается в компиляции на стороне клиента, что дает ему определенные
преимущества скорости. Поскольку сценарий выполняется на компьютере
пользователя, в зависимости от задачи, результаты выполняются почти
мгновенно. Например, вы можете проверить любой пользовательский ввод перед
отправкой запроса на сервер. Это снижает нагрузку на сервер.
JavaScript относительно прост в освоении и реализации. Он использует
модель DOM, которая обеспечивает множество предустановленных функций для
различных объектов на страницах, что делает его легким для разработки
сценария для решения пользовательской цели. Кроме того, JavaScript отлично
работает с другими языками и может использоваться в самых разных
приложениях.
JavaScript удобно использовать через серверы Node.js с помощью Express,
для взаимодействия с базой данных документов MongoDB, а также в интерфейсе
для клиентов. JavaScript позволяет создавать приложение полностью из одного
окна вперед, используя только JavaScript.
Как видно из предыдущих пунктов, в разрабатываемой системе будут
храниться документы, имеющие различную структуру. Например, к каждой
36
37
задаче планируется добавление описания, комментариев. В некоторых случаях,
возможно, их опустить, в других потребуются числовые данные или же
подробные описания планируемых действий.
Такие документы, как оформление сделки могут не иметь четкой
структуры, по этой причине хранение информации в виде таблиц реляционных
БД становится невозможным. Кроме того, в поставленной задаче документы не
требуют связности. Также, для разрабатываемой системы необходима
масштабируемость базы данных в связи с ежедневным увеличением базы на
сотни записей. Поэтому, для решения поставленной в работе задачи как нельзя
лучше подойдет СУБД MongoDB [15].
В качестве языка для написания приложения был выбран JavaScript
благодаря своей универсальности, простоте реализации, а также идеальной
сочетаемости с СУБД MongoDB.
1.4.3. Обоснование проектных решений по техническому
обеспечению
Технические средства, функционирующие в составе проектируемой
информационной системы, подразделяются на следующие категории:
1. Компьютерное оборудование клиентских мест.
2. Каналы связи.
Требования к компьютерному оборудованию рабочих мест:
1. Персональный компьютер:
- процессор на базе архитектуры x64, с частотой не менее 2000MHz;
- объем оперативной памяти не менее 2 Гб;
- дисковая подсистема не менее 100Гб;
- цветной монитор, размер не менее 15 дюймов, разрешение не менее
1024х768 точек;
- клавиатура, мышь;
- операционная система Windows 10;
- антивирусное ПО.
2. Сетевой адаптер.
38
Требования к каналам связи:
- способ установки соединения, виды коммуникационного
оборудования должны соответствовать критериям обеспечения
помехоустойчивости при передаче или получении данных ИС;
- должны быть использованы каналы связи с пропускной
способностью не менее 128Кбит/с.
39
II ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненным циклом программного средства называется период времени,
который начинается с момента принятия решения о необходимости создания
программного средства и заканчивается в момент его полного изъятия из
эксплуатации [2]. Жизненный цикл охватывает весь процесс построения и
развития программного обеспечения. Этот процесс может быть организован по-
разному для различных классов программных продуктов и в зависимости от
особенностей коллектива разработчиков.
Важным этапом в проектировании программного средства является выбор
модели его жизненного цикла.
Моделью жизненного цикла программного обеспечения называется
структура, которая определяет взаимосвязь процессов, действий и задач на
протяжении жизненного цикла, а также последовательность их выполнения.
Модель жизненного цикла зависит от специфики, масштаба и сложности проекта
и специфики условий, в которых система создается и функционирует [7].
Модель жизненного цикла содержит:
- стадии;
- результаты выполнения работ на каждой стадии;
- ключевые события.
Стадией называется этап процесса создания программы, который
ограничен определенными временными рамками и заканчивается выпуском
конкретного продукта, которым может быть модель, программный компонент
или документация, и определяемый заданными требованиями.
Под ключевым событием понимается точка завершения работы и
принятия решений
На каждой стадии может выполняться несколько процессов, которые
определены в стандарте ГОСТ Р ИСО/МЭК 12207-2010[1]. Также, один и тот же
процесс может выполняться на различных стадиях. Это соотношение между
процессами и стадиями также определяет вид используемой модели жизненного
цикла программного средства.
Существует ряд стандартов, которые регламентируют разработку и
жизненный цикл программного обеспечения, как международных, так и
российских: ГОСТ 34, ISO 12207, ISO 15288, MSF, RUP, COBIT, Oracle CDM,
XP. Рассмотрим кратко каждый из стандартов:
- Стандарт ISO/IEC 12207:2008 «System and software engineering —
Software life cycle processes» (Системная и программная инженерия - жизненный
цикл программного продукта)[9];
- Стандарт ГОСТ 34.601-90 «Информационная технология. Комплекс
стандартов на автоматизированные системы. Автоматизированные системы.
Стадии создания»;
- Стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная
технология. Системная и программная инженерия. Процессы жизненного цикла
программных средств». Этот стандарт регламентирует общую структуру
процессов жизненного цикла программных средств с применением устоявшейся
терминологии. Данный стандарт описывает все процессы, задачи и виды
деятельности, применение которых необходимо как при приобретении
программного обеспечения и его обслуживания, так и при дальнейших этапах,
таких как: поставка, разработка, использование, сопровождение и вывод
программных средств из эксплуатации.
- Стандарт ISO/IEC 12207:1995 - базовый международный стандарт,
описывающий процессы и организацию жизненного цикла программного
обеспечения. Распространяется на все виды программного обеспечения, но не
содержит описания фаз, стадий и этапов.
Помимо базовых стандартов, существуют следующие методологии
разработки программных средств:
- Стандарт Custom Development Method (CDM) - это
технологический материал, который детализирован до уровня заготовок
проектных документов, и рассчитанных на применение в проектах, основанных
на методике Oracle. Этот стандарт используется для классической модели ЖЦ
(предусмотрены все работы/задачи и этапы), а также для технологий быстрой
разработки применяемых для проектов малых масштабов [12].
40
41
- Методология Rational Unified Process (RUP) ориентирована на
модель разработки итерациями, состоящей из четырех фаз: начало,
исследование, построение и внедрение. При этом каждая фаза разбивается на
итерации, в результате которых выпускается версия, которая может применяться
как для внутреннего, так и для внешнего использования. Прохождение через
четыре основные фазы называется циклом разработки, каждый цикл завершается
генерацией версии системы. Основные принципы методологии RUP это:
итерационный и инкрементный подход к созданию программных средств,
планирование и управление проектом на основе функциональных требований к
системе, построение системы на базе архитектуры программных средств. RUP в
большей степени соответствует стандартам и нормативным документам,
связанным с процессами жизненного цикла ПО и оценкой технологической
зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и других).
- Методология Microsoft Solution Framework (MSF) имеет сходные с
RUP характеристики, включает следующие фазы: идея, планирование, сборка,
стабилизация и развертывание. Она также предполагает разработку итерациями
и использование объектно-ориентированного моделирования. Данная
методология ориентирована на разработку бизнес-приложений [17].
- Методология Extreme Programming (XP) или экстремальное
программирование сформировалось в 1996 году. В основе методологии
командная работа, эффективная коммуникация между заказчиком и
исполнителем в течение всего проекта по разработке ИС, а разработка ведется с
использованием последовательно дорабатываемых прототипов [16].
Для описания этапов жизненного цикла применяются модели жизненного
цикла ПО. В настоящее время широко известны и применяются следующие
модели [1]:
- Каскадная модель подразумевает последовательное выполнение
каждого из этапов проекта в строго определенном порядке. Переход на
следующий этап возможен только после полного завершения работ на
предыдущем этапе.
- Поэтапная модель с промежуточным контролем предусматривает
разработку программного средства итерациями с циклами обратной связи между
42
этапами. Межэтапные корректировки позволяют учитывать реально
существующее взаимовлияние результатов разработки на различных этапах;
время жизни каждого из этапов растягивается на весь период разработки.
- Спиральная модель предусматривает создание следующей версии
продукта на каждом новом витке спирали, при этом следует уточнить
требования проекта, определить его качество и план работ для следующего
витка. Наиболее важными этапами являются анализ и проектирование, где
проверяется возможность реализации различных технических решений,
посредством создания прототипов.
- Инкрементная стратегия подразумевает разработку программного
средства с линейной последовательностью стадий, но при этом планируется
создание нескольких инкрементов (версий), то есть с запланированным
улучшением продукта.
Необходимо заметить, что рассмотренные модели являются
классическими и сейчас редко применяются на практике, из-за сложности
реализации. В настоящее время большее распространение получили
комбинированные модели [8].
Поэтапная модель с промежуточным контролем предназначена для
реализации малых и средних проектов, срок выполнения которых занимает не
более года. В данной модели необходимо производить определение основных
требований в начале проектирования программного средства на этапе написания
технического задания, а внесение изменений в процессе проектирования
возможно только после завершения каждого из этапов работ, и данная модель
позволяет разрабатывать программные средства итерациями. Что подходит для
решения поставленных в работе задач.
В данной выпускной квалификационной работе был выбран стандарт
ISO/IEC 15288, который включает в себя следующие этапы:
- формирование концепции;
- разработка;
- реализация;
- эксплуатация;
поддержка;
43
- снятие с эксплуатации.
Опишем каждый этап.
На этапе формирования концепции производится детальный анализ
деятельности ООО «ВЕЛЕС», выявляются существующие проблемы
организации и пути их решения при помощи информационных технологий.
Выбирается решение - автоматизация учета рабочего времени сотрудников ООО
«ВЕЛЕС». Производится анализ существующих программных средств на
основании, которого было принято решение о разработке собственного
программного продукта. Были выявлены требования к информационной
системе, программному, техническому и информационному обеспечению.
На основании сформированной концепции происходит разработка проекта
автоматизации. На данном этапе проектируется структура БД, выполняется
конфигурирование вычислительной сети ИС. Для приложений определяются
требования к информационным технологиям, разрабатываются алгоритмы
обработки данных, формализованные постановки задач, осуществляется выбор
программных средств базового и прикладного назначения ИС.
Этап реализации обеспечивает программную и техническую реализацию
проектных решений по ИС. В первую очередь, это — создание БД,
проектирование форм документов, заполнение классификаторов и
кодификаторов технико-экономической информации, программная реализация
информационных технологий приложений, создание проектной документации
по ИС. По мере разработки отдельных программных компонентов
осуществляется их тестирование и интеграция. Для пользователей ИС
разрабатывается эксплуатационная документация.
На этапе внедрения выбирается стратегия внедрении, к которой относятся
следующие типы:
- параллельная стратегия, применяемая в случае замены старой
работающей системы на новую систему;
- стратегия скачок, означающая, резкую смену прежней системы на
новую систему, без предварительной подготовки и обучения персонала. При
неточных данных и необученных сотрудниках есть риск, сорвать поставки,
финансовые расчеты и получить убытки;