44
Технология Java Server Pages (JSP) является составной частью единой
технологии создания бизнес-приложений J2EE. JSP – это методика разработки
приложений, в ходе применения которых происходит автоматическая генерация
ответа на запросы клиента.
Перед использованием JSP документа его необходимо преобразовать в
соответствующий Servlet. Servlet, как правило, пишется на языке Java и в ходе
применения реализует определенный интерфейс. После того, как сформирован
Servlet, его необходимо поместить в соответствующий ему web-контейнер. Web-
контейнер призван обеспечивать информационное взаимодействие между Servlet’ом
и клиентами. На стороне веб-контейнера происходит выполнение таких функций, как
создание программной среды, идентификация и авторизация клиентов, организация
сессии для клиентов.[18]
Обычно данная технология применяется как основная технология при
разработке веб-интерфейсов. Облегченные всплывающие окна намного ускоряют
работу приложения, давая возможность использовать освободившиеся ресурсы для
реализации других функций приложений.
На настоящий момент реализована трансляция JSP страницы в Servlet,
программный код которого пишется на языке Java.
Основная схема реализации технологии Java Server Pages приведена на
рисунке 1.24.
Рисунок 1.24 Технология Java Server Pages приведена на рисунке
Таким образом, при разработке приложения будут использованы следующие
средства проектирования: HTML, CSS, PHP, JavaScript.
45
1.4.3.Обоснование проектных решений по техническому
обеспечению
Техническое обеспечение - совокупность технических средств, компьютерной
техники, средств передачи информации, используемых в автоматизированных
системах управления и в информационных системах.
В обеспечение работы сервера уведомлений важно наличие следующего
технического обеспечения:
ПК-сервера – основной ЭВМ, являющейся сервером БД. На нем
расместят и сервис (службу) производяющую регистрацию и обработку почтовых
рассылок в режиме втомата. ПК-пользователя (рабочей станции) пользовательского
ПК, с установленным веб-клиентом (браузером), который будет генерировать
рассылки и ответы на них;
Средствами организации ЛВС сюда включают ряд активных
(маршрутизатора, коммутатора, шлюза и т.д.) и пассивных (сегментов ЛВС,
коммутационных розеток и т.д.) компонентов локальной вычислительной сети.
Вслучае применения элемента важно указать ряд критериев, наиболее
важных для реализации выбора:
Серверами можно назвать одну из незаметных систем в целой сети
компьютеров. И подход к выбору сервера должен являться жестким и прагматичным,
чем к любой другой системе. При этом специфика сервера заключается в
преднамеренной избыточности основных компонентов.
Главные критерии выбора серверной платформы заключаются в специфике
решаемых сервером задач и количестве автоматизированных рабочих мест, которые
будут объединены в сеть. После этого происходит выбор производителя.
Для Сервера СУБД сервера в рамках одного ПК основным критерием выбора
будет отказоустойчивость и пропускная способность сетевого интерфейса.
Представленные ниже требования к конфигурации технических средств и
общесистемных программных средств, обеспечивающих функционирование системы,
предъявляются к системе в целом:
46
- свободное дисковое пространство 100 Мб и выше;
- оперативная память 1Гб и выше;
- сетевая карта Ethernet 100 Мбит и выше.
Требования к серверу:
- операционная система Microsoft Windows Server 2003;
- производительность двух ядерного процессора не менее 1,86 ГГц;
- свободное дисковое пространство 40 Гб и выше;
- оперативная память 4 Гб и выше;
- сетевая карта Ethernet 1 Гбит.
- СУБД PostgreSQL 10 или MS SQL Server не ниже версии 2005.
47
II.Практическая часть
2.1. Разработка проекта автоматизации
2.1.1.Этапы жизненного цикла проекта автоматизации
Моделью жизненного цикла называют структуру, содержащую процессы,
действия и задачи, реализуемые в ходе разработки, функционирования и
сопровождения программного продукта в период всей жизни системы, от постановки
требований до завершения ее применения. Есть перечень моделей и стандартов, в той
или иной степени регламентирующих процесс жизненного цикла, большинство из
которых может быть отнесено к заказному ПО (автоматизированные системы АС, и
др.) и кроме непосредственно ЖЦ реализуют регламент процессов разработки:
- ГОСТ 34.601-90 имет распространение на автоматизированные системы и
определяет стадии и этапы их создания. Кроме того, стандарт содержит описание
содержания работ на каждом промежутке работы. Стадии и этапы работы,
прописанные стандартом, по большей мере имеют сопряжение с каскадной моделью
жизненного цикла.
- Custom Development Method (методика Oracle) по разработке прикладных
информационных систем под заказ является конкретным материалом,
детализированным до уровня заготовок проектных документов, которые должны
быть использованы в проектах с применением Oracle. Степень адаптивности CDM
ограничена тремя моделями ЖЦ: "классической" (предусматривает все работы/задачи
и этапы), "быстрой разработки" (Fast Track), "облегченного подхода",
рекомендуемого в случае малых проектов и возможности создать быстрое
прототипирование приложений.
- Rational Unified Process (RUP) предлагается итеративная модель разработки,
включающая четыре фазы: начала, исследования, построения и внедрения. Каждая
48
фаза подразделяетя на ряд этапов (итераций), в результате которых происходит
выпуск версии для внутреннего или внешнего использования. Прохождение через
четыре основные фазы называют циклом разработки, каждый цикл имет завершение в
генерации версии системы. Если после этого работа над проектом не будет
прекращена, то полученный продукт имеет дальнейшее развитие и снова циклически
проходит те же фазы [3]. Суть работы в рамках RUP заключается в создании и
сопровождении моделей, а не бумажных документов, поэтому этот процесс
обусловлен использованием конкретных средств моделирования (UML), а так же
конкретной технологии проектирования и разработки (объектно-ориентированный
анализ, object-oriented analysis, OOA, объектно-ориентированное программирование,
object-oriented programming, OOP).
Основные критерии для выбора стандарта жизненного цикла заключаются в:
актуальности и современности используемых методик контроля
разработки;
разработке в итерационном режиме с возможностью контролировать
риски и выполнения самого проекта на неких контрольных точках;
отсутствии дополнительных требований по моделированию процесса
разработки и внедрения.
Таким образом, для разрабатываемого проекта автоматизации нами выбран
стандарт ГОСТ 34.601-90
От имеющейся сложности объекта автоматизации и набора задач, требующих
решения при создании конкретной ИС, стадии и этапы работ имеют различный
уровнеь трудоемкости. Допускается объединение последовательных этапов и даже
исключение некоторых из них на любой стадии проекта. Допускается также
начинание выполнения работ следующей стадии в период до окончания предыдущей.
Стадии и этапы создания ИС прописываются в рамках договоров и
технических заданий на исполнение работ. Перечень стадий и этапов ЖЦ по ГОСТ
34.601-90.
Начальная стадия проектирования включает следующие этапы работ,
заключающиеся в:
обследовании объекта и обоснование необходимости создания ИС;
формированиие требований пользователей к ИС;
49
оформлении отчета о выполненной работе и тактико-технического
задания на разработку.
Oбследованием назвают изучение и диагностический анализ организационной
структуры предприятия, его деятельности и существующей системы инфрмационной
обработки. Материалы, полученные в результате обследования, используются в:
обосновании разработки и поэтапного внедрения систем;
составлении технического задания на разработку систем;
разработке технического и рабочего проектов систем;
изучении объекта автоматизации;
разработка вариантов концепции ИС, удовлетворяющих требованиям
пользователей;
оформлении отчета и утверждение концепции.
Согласно с ГОСТ 34.601-90 порядок разработки, состав, структура и
оформление технического задания описан в ГОСТ 34.602-89.
Цель, достигаемая подготовкой правильно организованного технического
задания является простой. Это однозначное распределение сфер ответственности
между Заказчиком и Исполнителем. ТЗ является документом, который является
основой при принятии решения о закрытии проекта и о размере и порядке расчета
Заказчика и Исполнителя. Если ТЗ имеет правильный состав, то стороны могут
формально подходить к вопросу сдачи-приемки работ. В противном случае имеет
место наличие ситуации, когда одна из сторон, как правило, этой стороной является
Исполнитель, бывает не в состоянии отстаивания своих интересов. Для того чтобы
заявленная цель была реализована и до начала работ по реализации были однозначно
определены критерии, по которым будет осуществляться приемка ИС, в случае
разработки технического задания важно решение следующих задач:
установления общей целисоздания ИС, определения состава подсистем
и функциональных задач;
разработки и обоснования требований, предъявляемых к подсистемам;
разработки и обоснования требований, предъявляемых к
информационной базе, математическому и программному обеспечению, комплексу
технических средств (включая средства связи и передачи данных);
установки общих требований к проектируемой системе;
50
определения перечня задач создания системы и исполнителей;
определения этапов создания системы и сроков их выполнения;
проведения предварительного расчета затрат на создание системы и
определить уровень экономической эффективности ее внедрения.
Эскизный проект предусматривает разработку предварительных проектных
решений по системе и ее частям. Содержание эскизного проекта задается в ТЗ на
систему. Как правило, на этапе эскизного проектирования определяются:
функции ИС;
функции подсистем, их цели и ожидаемый эффект от внедрения;
состав комплексов задач и отдельных задач;
концепция информационной базы и ее укрупненная структура;
функции системы управления базой данных;
состав вычислительной системы и других технических средств;
функции и параметры основных программных средств.
Для визуализации проекта автоматизации применяются CASE-средства. В
данном проекта применяется Enterprise Architect.
2.1.2.Ожидаемые риски на этапах жизненного цикла и их описание
Сам стандарт ГОСТ 34 предполагает наличие некой гарантии минимизации
рисков, так как весь ЖЦ проекта в данном случае разделется на ряд этапов, на
каждом этапе отмечены роли, за которыми закреплены цели, достигаемые в процессе
реализации. Но при этом каждая фаза имеет свои некоторые риски:
В фазе выработки концепции могут возникнуть следующие риски в виде:
- Недальновидного анализа сроков проекта и его бюджета. Для ликвидации
такого рода риска важна более детальная прорабатка задач и целей проекта,
постановка большего числа контрольных точек.
- Неправильно подобранного проектного состава исполнителей. Приводит к
отсуствию командной работы. Данный риск может быть уменьшен при помощи более
тщательного подбора специалистов в проектную группу тестированием не только
профессиональных навыков, но и личностных особенностей.
51
На фазе планирования происходит возникновение следующих рисков:
неправильной или не совсем корректно сформированной архитектуры выбираемого
решения. Возможность появления этого риска обусловлена компетенциией
руководителя проекта, на котором лежит принятие решение о выборе архитектуры
разрабатываемого решения.
Фаза разработки имеет следующий перечень рисков: неправильную
интерпретацию технического задания и, как следствие, неправильное
программирование архитектуры и сдвиг сроков. Минимизация данного риска
достигается более чѐтким написанием технического задания, понятного
программисту.
Еще один немаловажный риск в данном проекте заключается в отсутствии
должной квалификации у программиста в том языке, на котором решено
реализовывать программу клиент, распределяющую заявки между инженерами.
В случае, если программистом отмечено неуложение в заданные временные
рамки календарного плана проекта, приглашается внешний разработчик, так
называемый ―аутсорсинг‖ или ―фриланс‖.
В фазе тестирования возникают следующие риски: неоконченного
тестирования.
Вероятность возникновения ситуации, что программный продукт не будет
полностью протестирован. Решается путем повторного тестирования на следующей
итерации разработки.
В фазе внедрения могут возникнуть риски неправильного принятия решения о
законченности части проекта.
Возникновение данных рисков приводит к возникновению проблемы
незаконченности решения и возможности появления нестыковок с другими частями
разрабатываемой ИС. Устранение проводят путем доработки при следующей
итерации.
2.1.3.Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Основные особенности распределенных ИС заключаются в:
52
территориальной разнесенности компонентов системы и наличии
интенсивного обмена информацией между ними;
широкого спектра используемых способов представления, хранения и
протоколов передачи информации;
интеграции данных различного назначения, принадлежащих различным
субъектам, в рамках единых баз данных и, наоборот, размещении необходимых
некоторым субъектам данных в различных удаленных узлах сети;
абстрагировании владельцев данных от физических структур и места
размещения данных;
использовании режимов распределенной обработки данных;
участии в процессе автоматизированной обработки информации
большого количества пользователей и персонала различных категорий;
непосредственном и одновременном доступе к ресурсам (в том числе и
информационным) большого числа пользователей (субъектов) различных категорий;
высокой степени разнородности используемых средств вычислительной
техники и связи, а также их программного обеспечения;
Все это привносит риски потери и неправомерного использования
информации.
Угрозы для безопасности информационной системы можно разделить на два
класса: внутренние и внешние.
Внутренние угрозы являются итогами воздействий непосредственных
участников процесса, пользователей:
- Неумышленных действий, приводящих к частичному или полному отказу
системы или разрушению аппаратных, программных, информационных ресурсов
системы (неумышленная порча оборудования, удаление, искажении файлов с важной
информацией или программ, в том числе системных и т.п.).
- Неправомерном отключении оборудования или изменении режимов работы
устройств и программ.
- Неумышленной порче носителей информации.
- Запуске технологических программ, способных при некомпетентном
использовании вызывать потерю работоспособности системы (зависания или
зацикливания) или осуществляющих необратимые изменения в системе
53
(форматирование или реструктуризацию носителей информации, удаление данных и
т.п.).
Защита от угроз регулируется организационно-правовыми мерами и
программно-аппаратными. На предприятии необходимо разработать комплект
документов, такие как инструкции пользователей при работе с информационной
системой, внутренние правовые документы, регламентирующие действия
пользователей. Также необходимо установить аппаратную защиту: для
пользователей, не использующих в своей работе внешние накопители, отключить их
использование в системе. Возможно использование программных средств защиты
информации, запрещающих пользователям скачивать и устанавливать программы на
компьютер, посещать запрещенные интернет-ресурсы. Таким программным
средством может быть Kaspersky Lab Internet Security. Эта программа успешно
зарекомендавала себя и используется на предприятии ООО «Безам».
Также для устранения внутренних угроз применяется система разраничения
прав доступа. Для этого все участники процесса делятся на группы. Каждой группе
соответсвует свой набор прав и полномочий. Примерные права пользователей
описаны в таблице 2.1.
Таблица 2.1
Разграничение прав доступа
Группы
пользователей
Права
Создание
рассылки
Администрирование
Только Просмотр
Администраторы
Нет
Есть
Нет
Пользователи
Есть
Нет
Есть
Руководители
Есть
Нет
Есть
Внешние угрозы информационной безопасности могут возникать во внешней
среде. Так как разрабатываемое приложение использует возможности Интенет-среды,
то такая система имеет большой риск попасть под активные внешние угрозы.
Для защиты от внешних угроз на предприятии установлен универсальнй
шлюз безопасности UserGate/ UserGate осуществляет защиту от атак, управление
трафиком, аутентификацию интернет-пользователей, а также обеспечивает
безопасность посещения сотрудниками интернет-ресурсов, ограждает их от загрузки