37
остаются независимыми от любых изменений в прикладной программе. При этом в
реляционных базах данных наблюдется низкая скорость обращения к данных по
сравнению с другими моделями, и они требуют больших объемов памяти.
Проанализировав достоинства и недостатки баз данных был сделан выбор в пользу
реляционных баз данных.
Для управления реляционной базой данных используется реляционная СУБД.
На рынке широко представлены как коммерческие, так и бесплатные СУБД.
Рассмотрим решения, представленные на рынке. Лидерами на рынке СУБД
являются продукты IBM DB2, Oracle, MySQL и Microsoft SQL Server.
СУБД IBM DB2 является кросс-платформенной, обеспечивает стабильную
работу базы данных. Недостатками системы являются высокая стоимость и низкая
производительность. СУБД Microsoft SQL Server обладает большим пакетом
инструментов, стабильностью работы и низкими затратами на администрирование.
Недостаток системы заключается в том, что она работает только на платформе
Windows. СУБД Oracle обладает высокой производительностью, легкостью
интегрирования приложений и устойчивостью к большим потокам данных.
Недостатком является высокая стоимость, необходимость приобретения мощного
оборудования и персонала для поддержки СУБД. СУБД MySQL – это свободная
СУБД, разработанная компанией «Oracle». Эта СУБД используется в малых и
средних приложениях. MySQL обладает интерфейсом для языков
программирования Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, Python и др.
Поскольку масштабы проектируемого приложения можно описать как
средние, а также ввиду поддержки языков программирования, была выбрана
реляционная СУБД MySQL.
Для разработки информационной системы будет использован объектно-
ориентированный подход, поскольку он позволяет осуществлять конструирование
из компонентов, обладающих простыми инструментами, что дает возможность
абстрагироваться от деталей реализации. При этом данные и операции вместе
образуют определенную сущность и они не «размазываются» по всей программе,
как это нередко бывает в случае процедурного программирования. Использование
локализации программного кода и данных улучшает наглядность и удобство
сопровождения программного обеспечения.
38
В качестве языка программирования был выбран язык программирования c++,
который обладает:
большей безопасностью по сравнению с другими языками;
возможностью писать обобщенный код с помощью шаблонов;
возможностью использования объектно-ориентированного подхода;
управления ресурсами с помощью RAII;
упрощение программного кода за счет перегрузки функций и
операторов;
более простой обработки ошибок за счет исключений.
Рассмотрим существующие среды программирования, которые
поддерживают язык программирования c++. Среда программирования «Visual
Studio 2017» является одной из старейших продуктов для создания программных
продуктов с графическим интерфейсом. Возможность добавления сторонних
плагинов способствует расширению функциональности среды программирования
до кроссплатформенного состояния. К недостаткfм этой среды можно отнести то,
что разработчик должен обладать опытом создания приложений, для работы с этой
средой.
Среда программирования «IntelliJ IDEA» позволяет осуществить разработку
программных продуктов на множестве популярных языков программирования. Но у
системы существует существенный недостаток производительности в процессе
компиляции, перекомпиляции и тестирования.
Платформа для разработки графических приложений «Appcelerator Titanium»
предоставляет возможность быстрого создания приложений для всех устройств. Но
в среде существует недостаток в виде генерации ошибок в коде, искусственных
ограничений и низкого качества пользовательской документации.
Мощной платформой для разработки приложений, которая позволяет
создавать приложения на языке программирования с++, является платформа
«Netbeans». Однако, платформа обладает низким показателем быстродействия и
ограничением функциональности некоторых плагинов.
На основании рассмотренных сред программирования, поддерживающих
язык с++, был сделан вывод о том, что наиболее надежной средой
программирования будет являться среда «MS Visual Studio».
39
Для создания отчетных форм будет использован программный продукт
«DesignFR», которое позволяет просматривать и редактировать файлы отчетов.
Проектируемая система должна функционировать в среде операционной
системы Windows 10, поскольку эта операционная система используется для работы
сотрудников организации.
2.1.3. Обоснование проектных решений по техническому обеспечению
Программное обеспечение процесса приема регистрируемых отправлений
разрабатывается для терминалов, которые будут осуществлять следующие
операции:
1. Вычисление веса отправления.
2. Вычисление расстояния отправления.
3. Расчет стоимости отправления.
4. Печать квитанции.
5. Печать адресного ярлыка на посылку.
Поэтому терминал должен быть оборудован следующими элементами:
1. Сенсорным монитором.
2. Весами.
3. Принтером.
4. Карт-ридер (для возможности оплаты услуг картой).
5. Купюроприемником.
6. Источник бесперебойного питания.
7. Системным блоком с комплектующими.
Как правило терминалы продают уже укомплектованными сенсорным
монитором, системным блоком, принтером и купюроприемником. Рассмотрим
решения, которые предлагают поставщики почтоматов. В таблице 5 представлен
обзор решений с указанием технических характеристик и стоимости.
Почтомат «МВК-Маш 1» обладает высокой стоимостью по сравнению с
другими моделями, но не укомплектован весами, поэтому такое оборудование не
подходит для поставленной задачи. Почтомат «ПТЧ-3» также не укомплектован
весами и его купюроприемник обладает малым объемом. Этот вариант также
43
Таблица 5
Характеристика оборудования
Наименование
Технические характеристики
Стоимость,
руб.
Системный блок
Карт-ридер
Купюроприемник
Весы
Почтомат «МВК-
Маш 1»
Celeron E2-7110/J3060,
1.6/1.8 ГГц DDR3 4 ГБ HD
Graphics 400/Radeon R2
Накопитель:500 ГБ
ICT3K5
Cash Code BNL-
3008 (3000 купюр)
-
392 923
Терминал
самообслуживания
СК-ПГ.П1
Core i3-8100 DDR4 8ГБ Intel HD
Graphics 530 Накопитель 1Тб
CREATOR
CRT-288K
CashCode (1000
купюр)
Взвешивание
до 300кг
127 656
Почтомат ПТЧ-3
MSI H61M-P31/W8/intelCeleron
G1610/DDR3 2ГБ 1333МГц/ SSD
Phison 32 ГБ/БП 400W ATX
CREATOR
CRT–310N
CashCode SLF2002
(35 купюр)
-
98 587
Терминал
самообслуживания
ПР.1052
Core i5-6500 3,6 ГГц 3,6 ГГц
H370 DDR4 8Гб 2400 МГц HDD
SATA 1Тб
CRT-350
ICT3K5 (2000
купюр)
Взвешивание
до 50 кг
111 580
Почтомат GNX-1.4
MSI H61M-P31/W8/intelCeleron
G1610/DDR3 8ГБ 1333МГц/ SSD
Phison 128 ГБ/БП 400W ATX
ViVOpay Kiosk
II
DDM-855 (1000
купюр)
Взвешивание
до 30 кг
268 741
44
не является подходящим. Из оставшихся вариантов терминал «Почтомат GNX-1.4»
имеет только модуль бесконтактной оплаты, что негативно сказывается на его
универсальности. Между терминалами «СК-ПГ.П1» и «ПР.1052» большей
мощностью стоимостью обладает второй вариант. Мощность терминала «ПР.1052»
позволяет использовать его при масштабировании программного обеспечения,
поэтому для рассматриваемой задачи был выбран этот вариант. Также он более
выгодный с точки зрения финансовых вложений.
2.2. Разработка проекта автоматизации
2.2.1. Этапы жизненного цикла проекта автоматизации
За долгую практику разработки программного обеспечения разработчики
стремились упростить процесс и наладить коммуникации между заказчиком и
проектной командой. С развитием вычислительной техники и информационных
технологий структура программного обеспечения усложнялась, поэтому возникла
острая необходимость в разработке стандартов [13].
В 1990 году был разработан отечественный стандарт разработки
программного обеспечения ГОСТ 34.601-90 «Автоматизированные системы. Стадии
создания» [1]. Согласно этому стандарту разработка информационных систем
делится на следующие стадии:
1. Формирование требований к АС
2. Разработка концепции АС
3. Техническое задание
4. Эскизный проект
5. Технический проект
6. Рабочая документация
7. Ввод в действие
8. Сопровождение АС
У этого стандарта есть один недостаток: на сегодняшний день он является
неактуальным, потому что содержит устаревшие представления об архитектуре
информационных систем. Примерами этого являются следующие утверждения:
Программные продукты двухуровневые, включающие клиентскую
программу и сервер СУБД.
45
Описание структуры таблиц базы данных дает представление о
логической модели данных.
Используется однооконный пользовательский интерфейс.
Система содержит небольшое количество отчетов, они являются
бумажными и печатаются принтере матричного типа.
АИС разрабатывается для решения задач обработки данных, которые
имеют четкий вход и выход и являются узкоспециализированными. Основу
обработки информации составляет алгоритм.
Более современный стандарт ГОСТ Р ИСО/МЭК 12207 «Информационная
технология. Системная и программная инженерия. Процессы жизненного цикла
программных средств» определяет общую структуру жизненного цикла ПО в виде
трехуровневой модели, элементами которой являются процессы, виды деятельности,
задачи [2]. Процессы объединены в четыре группы: основные процессы,
поддерживающие процессы, организационные процессы, адаптация. Процессы
состоят из отдельных видов деятельности. Каждый процесс, действие или задача
инициируется и выполняется другим процессом по мере необходимости, причем не
существует заранее определенных последовательностей выполнения. Структура
этого стандарта представлена на рисунке 10.
Стандарт ГОСТ Р ИСО/МЭК 15288 «Информационная технология. Системная
инженерия. Процессы жизненного цикла систем» расширил рамки стандарта ГОСТ
Р ИСО/МЭК 12207 и имеет схожую структуру [3]. Однако, в отличие от стандарта
ГОСТ Р ИСО/МЭК 12207, ГОСТ Р ИСО/МЭК 15288 обладает точностью и
продуманностью формулировок, структурированностью изложения. Также, как и в
стандарте ГОСТ Р ИСО/МЭК 12207, процессы создания информационной системы
сгруппированы, но по другому принципу разбиения [20]:
процессы соглашения включают приобретение и поставку компонентов
информационной системы;
процессы предприятия включают управление средой предприятия,
инвестициями, процессом жизненного цикла системы, ресурсами и качеством;
процессы проекта включают планирование, оценку, контроль, принятие
решений, управление рисками, управление конфигурацией и информацией;
46
технические процессы включают выявление требований, разработку
архитектуры приложения, реализацию его элементов, верификацию, передачу,
валидацию, функционирование, техническое обслуживание системы, ее изъятие и
списание.
Рисунок 10. Структура создания информационной системы
согласно стандарту ГОСТ Р ИСО/МЭК 12207
Этот стандарт разрабатывался для организаций, которые приобретают,
разрабатывают или внедряют информационные системы. Применение этих систем
может осуществляться как в самой организации, так и для заказчиков. Структура
стандарта ГОСТ Р ИСО/МЭК 15288 представлена на рисунке 11.
Современные стандарты в области разработки программного обеспечения не
предписывают четких и однозначных схем построения структуры жизненного цикла
ПО. Международные стандарты регламентируют перечень видов деятельности, из
которых должен состоять процесс разработки, и вводят ту или иную структуру
жизненного цикла разработки ПО.
47
Рисунок 11. Схема стандарта ГОСТ Р ИСО/МЭК 15288
Существуют стандарты, определяющие различные элементы в структуре
жизненных циклов ПО. Основу таких элементов составляют технологические
процессы – структурированные наборы деятельностей, решающие некоторую
общую задачу или совокупность задач, такие, как процесс определения требований,
процесс разработки, процесс сопровождения ПО, процесс обеспечения качества,
процесс разработки документации, процесс тестирования и пр.
Стандарт «Custom Development Method» (CDM) был разработан компанией
«Oracle» для разработки прикладных информационных систем [19]. Этот метод
является технологическим материалом, детализированным до уровня шаблонов
проектной документации, рассчитанной на применение в проектах компании.
Согласно этому стандарту при разработке программного обеспечения применяется
классическая модель жизненного цикла программного продукта.
Стандарт «Rational Unified Process» (RUP) представляет разработку
программного обеспечения в виде итеративной модели жизненного цикла, который
включает следующие фазы: начало, исследование, построение и внедрение [18].
Каждая фаза жизненного цикла АИС может разбиваться на этапы, называемые
итерациями. В результате осуществления этих этапов происходит выпуск версий
программного продукта для внутреннего или внешнего использования.
Прохождение процесса разработки через четыре этапа называют циклом разработки.
Каждый цикл разработки завершается генерацией версии системы. Если после
48
версия системы не удовлетворяет требованиям пользователя, то разработанный
продукт продолжает свое развитие и проходит те же этапы разработки.
Стандарт «Microsoft Solution Framework» (MSF) похож на стандарт «RUP»
тем, что делит разработку программного обеспечения на четыре фазы: анализ,
проектирование, разработка, стабилизация [18]. Эта модель является итерационной,
что предполагает использование объектно-ориентированного подхода при
моделировании системы. Стандарт«MSF» в сравнении со стандартом «RUP» больше
ориентирован для разработки бизнес- приложений.
Стандарт «Extreme Programming» (XP) был создан в 1996 году и является
самым новым среди рассмотренных стандартов [19]. Основу этого стандарта
составляет командная работа, с организацией эффективной коммуникацией между
заказчиком и разработчиков во время всей разработки АИС. При этом разработка
АИС проводится с использованием последовательно разрабатываемых прототипов
АИС.
У каждой информационной системы есть свой жизненный цикл, который
включает все этапы системы от формирования требований до снятия в эксплуатации.
Рассмотрим модели жизненного цикла программного продукта. Когда программные
продукты только начали разрабатываться, они имели однородную структуру и
каждое приложение являлось единым целым. Поэтому для разработки программных
продуктов такого типа применялась каскадная модель жизненного цикла
программного обеспечения.
Основной характеристикой этой модели является деление всего процесса
разработки программного обеспечения на ряд этапов. При этом переходы между
этапами осуществлялись только после полного завершения работ на текущем этапе.
Каждый этап каскадной модели завершался выпуском полного пакета проектной
документации, которой достаточно для продолжения процесса разработки другой
командой разработчиков.
Каскадная модель была разработана в 1970 году, и она являлась первой
моделью, которая формализовала структуру этапов разработки ПО, что придавало
особое значение исходным требованиям к программному обеспечению и этапу
проектирования системы, а также созданию документации на ранних этапах
процесса разработки. Структура каскадной модели представлена на рисунке 12.
49
Рисунок 12. Каскадная модель жизненного цикла
На схеме этапов каскадной модели жизненного цикла программного
обеспечения видно, что процесс разработки осуществляется при помощи
упорядоченной последовательности шагов. Каскадная модель предусматривает
начало каждой фазы только тогда, когда полностью завершается выполнение
предыдущей фазы. При этом у каждой фазы есть определенные критерии входа и
выхода: входные и выходные данные.
Требования к проектируемой АИС определяются на стадии анализа и затем
документируются в техническом задании, которое является опорным документом
при создании АИС. Каждая стадия каскадной модели должна завершаться выпуском
полного комплекта проектной документации, которая включает в себя:
1. Техническое задание.
2. Эскизный проект.
3. Технический проект.
4. Рабочую программу.
Перечисленный пакет документов является достаточным для продолжения
процесса разработки другой командой разработчиков. Критерий качества при
использовании каскадной модели жизненного цикла программного обеспечения –
точное соответствие спецификациям технического задания на разработку АИС. При
этом особое внимание разработчики уделяют достижению оптимального значения