36
испытательного проекта на основании нескольких систем управления базами
данных и дальнейший выбор самого подходящего из кандидатов. Однако и в
таком случае нужно ограничивать спектр возможных систем, основываясь на
некие показатели отбора. В таком случае можно отметить особенно несколько
групп критериев, среди которых:
моделирование информации;
функциональные возможности и особенности архитектуры;
контроль работы системы;
специфика разработки приложений;
надежность;
производительность;
требования к рабочей среде;
смешанные показатели.
Главным принципом выбора системы управления базами данных
считается определение программного продукта, в наибольшей степени
соответствующего предъявляемым требованиям. Такую задачу решить довольно
сложно. В первую очередь, к системам управления базами данных
предъявляется довольно много требований, которые со временем претерпевают
различные изменения, кроме того, системы управления базами данных имеют
много параметров, что усложняет их сравнение. Помимо этого, информация о
системах управления базами данных часто имеет рекламный характер, из за
которого сложно сделать правильное суждение.
Процедуру выбора системы управления базами данных необходимо
производить в 3 следующих этапа:
на качественном уровне проводить оценку предлагаемых
программных продуктов на пригодность;
оценка технических характеристик выбранных информационных
систем;
оценка производительности программных систем.
Характ
a
ерист
a
ики ПО MySQL снискали ему славу наиболее
предпочит
a
аемого web-программист
a
ами программного продукт
a
а. Прежде всего,
37
т
a
акая репут
a
ация обязана скорост
a
и, надежност
a
и и прост
a
от
a
е MySQL в
использовании. Т
A
е, кт
a
о ценит
a
перечисленные качест
a
ва превыше всего, делают
a
выбор в пользу данного сервера. От
a
крыт
a
ый код и т
a
есный конт
a
акт
a
с
пользоват
a
елями позволили расширит
a
ь исходный ряд функций программы,
сделав её еще более практ
a
ичной. При эт
a
ом совершенст
a
вование MySQL не
ост
a
анавливает
a
ся на дост
a
игнут
a
ом уровне [13]. Разработ
a
ки ведут
a
ся в непрерывном
режиме. Уже сейчас она в полной мере соот
a
вет
a
ст
a
вует
a
высоким т
a
ребованиям
эксплуат
a
ации в промышленных условиях, предост
a
авляет
a
безопасный и
высокоскорост
a
ной дост
a
уп к базам данных во всемирной сет
a
и.
Сист
a
ема MySQL организована по принципу клиент
a
-сервер. Благодаря
вст
a
роенному многопот
a
очному SQL-серверу MySQL обеспечивает
a
поддержку
разнообразных вычислит
a
ельных машин БД, позволяет
a
работ
a
ат
a
ь с различными
библиот
a
еками и программами на ст
a
ороне клиент
a
а, от
a
крывает
a
широкий круг
возможност
a
ей по админист
a
рированию, поддерживает
a
обширный спект
a
р
A
PI.
MySQL может
a
в виде многопот
a
очной библиот
a
еки быт
a
ь подключена к
пользоват
a
ельскому приложению, чт
a
о даст
a
в результ
a
ат
a
е быст
a
рый, легкий и
компакт
a
ный программный продукт
a
.
Для среды проектирования главное требование – удобство работы.
В и процессе в создания на или но модификации как прикладного за решения под
разработчик и1С:Предприятие избавлен в от на необходимости но каких-либо как действий за
по под непосредственному и изменению в структуры на полей но базы как данных за прикладного под
решения.
Разработчику и достаточно в путем на визуального но конструирования как описать за
структуру под используемых и объектов в прикладного на решения, но состав как их за реквизитов, под
табличных и частей, в форм на и но пр.
Все и действия в по на созданию но или как изменению за структуры под таблиц и базы в
данных на платформа но выполнит как самостоятельно, за на под основании и состава в объектов на
прикладного но решения как и за их под характеристик.
Этим система 1С:Предприятие выгодно отличается от универсальных
инструментальных средств. Обычно, при создании бизнес-приложений с
использованием универсальных сред разработки, используются отдельно
поставляемые системы управления базами данных. А это значит, что
38
разработчику приходится постоянно заботиться о преобразованиях между
типами данных, поддерживаемыми той или иной системы управления базами
данных, и типами, поддерживаемыми языком программирования.
Хранение ссылок на объекты
При манипулировании данными, хранящимися в базе данных
1С:Предприятия, зачастую используется объектный подход. Это значит, что
обращение (чтение и запись) к некоторой совокупности данных, хранящихся в
базе, происходит как к единому целому [10]. Например, используя объектную
технику, можно манипулировать данными справочников, документов, планов
видов характеристик, планов счетов и т.д.
Характерной особенностью объектного манипулирования данными
является то, что на каждый объект, как совокупность данных, существует
уникальная ссылка, позволяющая однозначно идентифицировать этот объект в
базе данных.
Таким образом, можно говорить о том, что для проекта,
рассматриваемого в данном исследовании наиболее более приемлема 1 С
Предприятие.
1С: Предприятие – программный продукт для автоматизации
деятельности предприятий, первоначально предназначался для автоматизаций
управленческого и бухгалтерского учета, в настоящее время охватывает и
другие сферы деятельности [19].
1С: Предприятие состоит из пользовательского режим работы и
технологической платформы. Технологическая платформа своего рода оболочка
над базой данных, которая предоставляет объекты данных и механизмы
управления объектами.
Совокупность взаимосвязанных объектов описываются в виде
конфигураций. При автоматизации каких-либо учетных задач создается своя
конфигурация, которая представляет собой уже законченное прикладное
решение [2].
Также выпускаются учебные версии 1С, это «1С: Предприятие 8.3
Версия для обучения программированию» и «1С: Бухгалтерия 8. Учебная
39
версия». Учебные версии предназначены для обучения программированию и
использованию программы [20].
В новой редакции платформы 1С 8.3.14 появилась возможность
устанавливать связь с внешними источниками данных, в том числе и с файлами
MySQL.
Для решения задачи использовалась база данных MySQL Для выгрузки
данных использовался драйвер ODBC. Для разработки отдельных модулей
использовался встроенный язык 1 С.
1.4.3. Обоснование проектных решений по техническому
обеспечению
Техническое обеспечение представляет собой набор технических
средств, которые предназначены для работы ИС, а также соответствующая
документация на данные средства и технологические процессы.
В набор технических средств входят:
компьютеры;
устройства сбора, обработки, накопления, передачи и вывода
информации – жесткие диски, специальные устройства хранения данных,
принтеры, сканеры, факсимильные аппараты;
устройства передачи данных и линий связи – модемы.
Для решения данной задачи нужно применять персональный компьютер
с уровнем вычислительной мощности AMD 2000 Мгц, или Intel 2000 Мгц, с
объемом оперативной памяти от 2 Гб. Система оптимизирована для работы в
экранном разрешении 1024х768 на мониторе с диагональю 17 дюймов.
Перечисленные технические средства обладают конфигурацией, достаточной
для решения задачи.
При выборе персонального компьютера следует руководствоваться
несколькими характеристиками. К ним относятся надежность, финансовые
расходы, производительность, простота использования и так далее. От значения
выше названных параметров напрямую зависит возможность работы с
необходимыми программными средствами, а значит, и успех разработки
системы.
40
Для каждого из компонентов данной система выделяется список
показателей, самых важных при проведении выбора технического обеспечения.
На сегодняшний день во многом разрозненный парк персональных
компьютеров формирует сложности с их ремонтом и обслуживанием, в связи с
чем нужно его унифицировать и закупить одинаковые рабочие станции.
Технические характеристики подходящей рабочей станции представлены
в таблице 4.
Таблица 4
Характеристики рабочей станции
Производитель Hugel
Модель процессора
Intel Core
i5 2500 3,3
ГГц
LGA 1155
Оперативная память
8 Г
b
Жесткий диск
500
Gb
Оптический привод
DVD
-
RW
Видеоадаптер
Интегрирован в чипсет
Разъемы на материнской плате
7 USB,
выход
S/PDIF, 2xCOM, D
-
Sub,
DVI, Ethernet, PS/2 (клавиатура), LPT
Корпус
mATX 250W
Операционная система
Не установлена
Размеры (ШхГхВ)
283 х 282 х 95 (мм)
Для решения данной задачи нужно применять персональный компьютер
с уровнем вычислительной мощности AMD, или Intel, с размером оперативной
памяти от 2 гигабайт.. Данные технические средства имеют достаточную для
решения задачи конфигурацией.
Выбираем компьютер на базе процессора AMD, т. к. он больше подходит
по цене.
41
II. Проектная часть
212. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл информационной системы можно представить в виде
последовательных событий, которые происходят с системой в процессе ее
создания и эксплуатации [1]. Сегодня известны и широко применяются такие
модели жизненного цикла:
каскадная модель предполагает последовательное исполнение всех
этапов проекта в установленном порядке. Переход на второй этап должен
происходить только после полного завершения работ на прошлом этапе;
поэтапная модель с промежуточным контролем. Межэтапные
корректировки обеспечивают возможность учитывать существующее
взаимовлияние результатов разработки на разных этапах; срок жизни каждого
из этапов занимает весь период разработки;
цикличная модель. На каждом цикле производится создание новой
версии продукта, проводятся уточнения требованийпроекта, устанавливается
его качество и планируются работы последующего цикла [16].
Среди наиболее известных стандартов можно выделить следующие:
ISO/IEC 12207 - стандарт на процессы и организацию жизненного цикла.
Распространяется на все виды заказного ПО. Стандарт не содержит описания
фаз, стадий и этапов;
ISO/IEC 15288 - стандарт применим для широкого класса систем, но его
основное предназначение - поддержка создания компьютеризированных систем;
ГОСТ 34.601-90 - распространяется на автоматизированные системы и
устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится
описание содержания работ на каждом этапе. Стадии и этапы работы,
закрепленные в стандарте, в большей степени соответствуют каскадной
модели жизненного цикла.
Rational Unified Process (RUP) предлагает итеративную
модель разработки, включающую четыре фазы: начало, исследование,
построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в
42
результате которых выпускается версия для внутреннего или внешнего
использования.
Microsoft Solution Framework (MSF) сходна с RUP, так же включает
четыре фазы: анализ, проектирование, разработка, стабилизация,
является итеративная, предполагает использование объектно-ориентированного
моделирования. Rapid Application Development (RAD) – стандарт (методология)
быстрой разработки приложений на основе спиральной модели ЖЦ ИС.
Основным нормативным документом, регламентирующим ЖЦ ПО,
является международный стандарт ISO/IEC 12207
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы
разработки ПО. Его регламенты являются общими для любых моделей ЖЦ,
методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает
структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать
или выполнить действия и задачи, включенные в эти процессы.
В этом проекте следует использовать стандарт ISO/IEC серии 15288 и
каскадную модель.
Перечень стадий и основные результаты, которые должны быть
достигнуты к моменту их завершения, приведены в таблице 5.
Таблица 5
Стадии создания систем (ISO/IEC 15288)
№
п/п
Стадия Цель
Формирование
концепции
Описание предметной области, принятие
решений по программному, техническому и
информационному обеспечению
Разработка
Проектирование системы
Реализация
Изготовление системы
Эксплуатация
Ввод в эксплуатацию и использование системы
Поддержка
Обеспечение функционирования системы
Снятие с
эксплуатации
Прекращение использования, демонтаж,
архивирование системы
Данной методологии будет достаточно.
Выбор стратегии внедрения
1) Параллельная стратегия — для случая, когда старую работающую
систему необходимо заменить новой.
43
2) Скачок означает, что прежняя система работала еще в пятницу а в
понедельник начала работать по новой системе.
Если данные не столь точные, как хотелось бы, если люди не обучены,
тогда есть риск ввергнуться в хаос, сорвать поставки и финансовые расчеты.
3) Опытная эксплуатация пилотного проекта — это тактика скачка, но
применяемая к ограниченному числу изделий. Область применения стратегии —
малый участок деятельности. Такой подход наиболее надежен, он снижает риск,
и сегодня практически все фирмы применяют эту тактику.
4) Узкое место — это наиболее критичная малая часть
производственного процесса. При внедрении узкого места план внедрения
выполняется только для узкого места и для людей, работающих в нем [7].
При стратегии узкого места объем работ уменьшается значительно, и
при заданных ресурсах узкое место может быть завершено в более короткие
сроки, чем внедрение во всей фирме.
Свойство этой стратегии — сосредоточение на узком месте в
производственном процессе — упрощает внедрение.
Узкое место служит испытательным полигоном для дальнейших работ.
Оно может явиться успешным примером, помогающим внедрению во всей
компании.
В результате анализа было принято решение о выборе стратегии
внедрения узкое место.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
В ходе жизненного цикла информационной системы всегда могут
возникнуть риски, могущие сорвать разработку. Для их избежания проводится
оценка вероятных рисков и разрабатываются способы, позволяющие избегнуть
эти риски или минимизировать их влияние.
Существуют различные типы моделей ЖЦ ИС, и разные компании могут
использовать наиболее удобные для себя подходы.
Каждая из приведенных стадий несет в себе определенный набор угроз,
которые должны быть своевременно учтены и обработаны. Наиболее
распространенные угрозы:
неверная формулировка требований к ИС;
44
неадекватный выбор процессов ЖЦ и вовлеченных в них участников;
принятие неверных проектных решений;
внесение разработчиком дефектов на уровне архитектурных решений;
внесение разработчиком недокументированных возможностей в ИС в
целом или в ее отдельные компоненты;
неадекватная (неполная, противоречивая и пр.) реализация
предъявленных к ИС требований;
сборка ИС с нарушением предъявляемых требований, приводящая к
появлению недокументированных возможностей в ИС либо к неадекватной
реализации требований;
разработка некачественной документации;
неверное конфигурирование ИС;
приемка ИС, не отвечающей требованиям, установленным в компании;
внесение недокументированных возможностей в ИС в процессе
проведения приемочных испытаний посредством использования
недокументированных возможностей функциональных тестов и тестов ИБ [16].
Безопасность при разработке ИС может быть обеспечена следующими
мерами:
1. Определение процедур разработки ИС. С целью снижения вероятности
возникновения проблем с безопасностью заранее должны быть определены
методы и средства разработки. Они должны охватывать все используемые языки
программирования (C++, JavaScript, SQL и пр.).
2. Организация среды разработки. Для организации безопасного
процесса разработки рекомендуется выделить рабочие места ответственных лиц
в отдельный защищенный сетевой сегмент, обеспечить рабочие места
средствами антивирусной безопасности и защиты от НСД, использовать
"чистую" лицензионную политику. Эти простые меры позволят значительно
снизить риски несанкционированного доступа и изменения кода посторонними
лицами.
3. Обучение персонала методам безопасной разработки. Понимание
проблем безопасности современных приложений и новых способов атак крайне
необходимо для создания защищенной ИС, поэтому проведение тренингов по
45
ИБ для разработчиков может существенно повысить качество и безопасность
ИС.
4. Анализ и тестирование исходных кодов на наличие уязвимостей и не
декларированных возможностей. Исходные коды должны периодически
анализироваться с помощью автоматизированных средств или в ручном режиме
на наличие распространенных ошибок, в том числе: межсайтовый скриптинг,
переполнение буфера, ошибки при проверке входных данных для обработки,
ошибки в процессе обработки данных, пароли в открытом виде и т.д.
Альтернативным решением может стать использование услуг третьих сторон по
анализу кода на уязвимость.
5. Разработка (получение) документации на ИС. Документация на ИС
должна включать описание применяемых защитных мер и функций, описанных
в техническом задании. С точки зрения ИБ документация как минимум должна
содержать:
• описание ролевой системы;
• описание механизмов доступа, регистрации событий, целостности,
резервирования;
• параметры настроек безопасности.
При приобретении ИС необходимо уделить особое внимание
оформлению договорных обязательств. Помимо указанных выше требований по
обеспечению безопасной разработки и поставки ИС, на поставщика должна быть
возложена ответственность на случай возникновения каких-либо инцидентов
ИБ, связанных с некачественной разработкой, нарушением правил поставки и
пр. Также следует учитывать наличие у разработчика необходимых лицензий на
разработку и эксплуатацию средств и систем защиты.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Система мероприятий, направленных на защиту данных в
разрабатываемой системе включает ряд аспектов, а именно:
защита данных непосредственно в ИС от различных внутренних
угроз;