Организация работы офисной сети под управлением конкретной ОС в ООО ПК «ВентКомплекс». Часть 2

1 2 3

---

II Проектная часть

2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации

Далее в рамках проектирования информационной системы учета заявок на доступ к серверным ресурсам необходимо провести планирование процесса разработки, выбрать модель жизненного цикла [2].
Стадии разработки и внедрения программных решений включают: планирование, разработку (программную реализацию), тестирование, использование, поддержку эксплуатации, связанную с выпуском обновлений, стадию вывода из эксплуатации [11].
Планирование этапов проекта должно соответствовать специфике решаемых задач, на начальном этапе необходимо провести планирование каждой из стадий, их продолжительность, заинтересованные стороны и ответственных специалистов.
Модель жизненного цикла выбирается из вариантов [15]:
 Каскадной модели, в рамках которой обеспечивается поочередное выполнение всех работ в рамках проекта в заданном порядке. Переход к последующей стадии производится только после окончания предыдущего этапа.
 Итерационная модель, в рамках которой этапы проекта разделяются на заданную последовательность итераций, каждая из которых представляет собой «мини-проект», в котором также выделяются этапы реализации. Цель каждой итерации — получение работающей версии программного продукта, включающей функциональность, определённую интегрированным содержанием всех предыдущих, и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта.
 Спиральная модель — складывается из нескольких итераций (витков спирали) путем создания прототипов (черновых версий программы). Каждая итерация соответствует созданию фрагмента или версии программного обеспечения, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
Схема каскадной модели представлена на рисунке 13.

Рисунок 13 – Схема каскадной модели жизненного цикла

Недостатками каскадной модели является вероятное затягивание сроков проекта, так как переход к последующей стадии производится только при полном завершении предыдущего этапа.
На рисунке 14 приведена схема итерационной модели жизненного цикла.

Рисунок 14 – Схема итерационной модели жизненного цикла

Недостатком итерационной модели является затягивание сроков проекта, так как в рамках него предполагаются возможности постоянного возврата к предыдущим этапам при обнаружении ошибок.
Для разработки требуемого приложения автоматизации управления взаимоотношениями с клиентами выбрана спиральная модель, представленная на рисунке 15. Структура модели жизненного цикла программного обеспечения приведена в соответствии со стандартом ГОСТ Р МЭК 62304 —2013. Информационная технология. Процессы жизненного цикла программных средств.

Рисунок 15 — Спиральная модель

К возможным стратегиям внедрения программного обеспечения относятся [30]:
— Параллельная стратегия, в рамках реализации которой производится постепенное внедрение новой технологии, одновременное использование существующей и внедряемой систем с постепенным существующего замещением функционала. Достоинство подобной стратегии: отсутствие перерывов в работе, связанных с издержками на внедрение новой технологии, возможности выявления недостатков внедряемой системы и постепенное их устранение. Недостатки данной стратегии: длительность проекта, необходимость дублирования ввода данных в существующую и внедряемую систему, некоторые ошибки не могут быть своевременно выявлены. Также в данном случае необходимо использовать инструменты мотивации пользователей к обновлению системы. Также отсутствие ситуации форс-мажора не мотивирует разработчиков быстро реагировать на выявленные ошибки и устранять их (т.к. работа компании не остановлена и функционирует существующая система);
— Скачок, в рамках которой одномоментно проводится внедрение новой системы. Достоинство данной стратегии: сокращаются сроки внедрения, недостатки в функционале внедряемого решения обнаруживаются значительно быстрее, что стимулирует разработчиков к быстрому их устранению. Недостатки: значительное время требуется на перевод компании в штатный режим функционирования, т.к. сбои в работе ПО приводят к невозможности выполнения функций. Также первоначально требуются затраты времени на проверку корректности формируемых документов и проводимых расчетов;
— Опытная эксплуатация. Внедряемая система устанавливается на выбранное количество рабочих мест, где проводится проверка всего функционала системы с постепенным ее доведением до работоспособного состояния. Достоинства данной стратегии: работа компании не приостанавливается на период внедрения ПО. Ввод системы в промышленную эксплуатацию осуществляется при полной проверке всех функций. недостатки стратегии: часть специалистов из профильных отделов на время не могут выполнять свои функции, что предполагает дополнительную нагрузку на работников, не вовлеченных в процесс внедрения.
— Узкое место. Данная стратегия используется при необходимости автоматизации направления деятельности, функции которого выполняет небольшое количество специалистов. Внедрение в данном случае вносит минимальное воздействие на работу компании.
В качестве стратегии внедрения выбрана опытная эксплуатация, так как предполагается автоматизация направления деятельности, в котором участвует значительное количество специалистов и при этом необходимо обеспечить бесперебойное функционирование компании.
При разработке проекта автоматизации технологии учета заявок на доступ к серверным ресурсам был составлен календарный план внедрения автоматизированной информационной системы, представленный в таблице 10.
Таблица 10
Хронологический порядок внедрения программного продукта в технологию работы

 

Таким образом, реализация системы предполагает выполнение работ, связанных с привлечением к проекту как разработчиков ПО, так и представителей профильных отделов, в которых предполагается использование системы автоматизации.
Разработка и управление ИТ-решениями связаны со сложностями организационного характера, связанными с обеспечением эффективности взаимодействия специалистов, привлеченных к созданию информационных систем, администраторов, осуществляющих управление базой данных и файловыми ресурсами.
Основные проблемы, связанные с проектированием информационных систем, определяются факторами [9]:
— Разграничением ответственности между разработчиками;
— Определение календарных планов разработки ИТ-продуктов;
— Определением этапов разработки и критериев приемки.
При ошибках в организации проектирования информационных систем возможны задержки, связанные с:
— необходимостью дублирования функций (назначением основного и дублирующего специалиста);
— ошибками в разделении полномочий, что может привести к нерациональному расходу ресурсов времени специалистов.
Ошибки при реализации ИТ-продуктов возможно минимизировать путем использования стандартов программирования, к которым относятся технологии Agile, технологии восходящего и нисходящего программирования.
Нисходящее программирование представляет собой набор систематических методов по проек¬тированию, кодированию и тестированию программ в форме последо¬вательности шагов. Метод основывается на идее проведения пошаговой детализации и позволяет проводить создание иерархически организованных модульных про¬грамм, модули верхнего уровня которых соответствуют общему функционалу программы, а модули следующего уровня являются их подфункциями.

Рисунок 21 — Схема обмена данными с использованием XML

Традиционно разработка программы проводится в виде последовательности этапов: первоначально проводится создание программы, далее ее кодирование и, наконец, тестирование. В случае использования приемов нисходящего программиро-вания первоначально идет проектирование, кодирование и тестирование одного мо-дуля, затем другого и т.д., пока все будет проведено завершение всех модулей. Функционал программы возрастает постепенно по мере подключения к ней новых модулей [2].
Процесс нисходящей разработки программы стартует после разработки общей логической структуры программы. Первоначально проводится проектирование модуля самого верхнего уровня. Следующие модули считаются фиктивными и заменяются на так называемые «заглушки» — пустые модули, содержащие только точки входа и выхода. Данные модули при вызове проводят возвращение уп¬равления вызывающим модулям. Далее проводится их замена на ре¬альные модули, разработанные на последующих этапах детали¬зации.
Методология восходящего программирования связана с использованием противопо¬ложной стратегии. Программа разрабатывается через объединение про¬стых программных составляющих для создания компонент высшего уровня [3].
Однако первый разработки, связан с созданием общей структурной схемы программы, вклю¬чая функциональные подсистемы и структуры данных. Далее производится поэтапный процесс по разработке и объединению компо¬нент, начиная с компонент низшего уровня. При объедине¬нии и совместном тестировании модулей нижнего уровня возникает необходимость в вызывающем модуле более высокого уровня, ко¬торый в данный момент еще не существует. Для имитации его функций создается тестовый драйвер — скелетная модель модуля, который будет создан на следующем шаге. Драйвер является управляющей программой, вызывающей другие модули и передающей им управления.
Оба метода проводят упорядочение процесса разработки. При этом более эффективным является использование комбинированного подхода. Так, общие модули, которые будут вызываться более чем одной компонентой более высокого уровня, целесообразно разраба¬тывать, используя восходящее программирование, а для остальной части программы использовать нисходящий принцип. Восходящий подход позволяет работать параллельно над разными модулями программы, а нисходящий упрощает интегрирование модулей в единую программу.
Усложнение современного программного обеспечения делает актуальным задачи специализации в программировании. Существующее программное обеспечение предполагает необходимость реализации помимо прикладных задач множества смежных, обеспечивающих возможность использования программы пользователями. Так, например, для программ учета продаж необходимы модули взаимодействия с фискальными регистраторами, модули экспорта в унифицированные форматы для обмена информацией. Также необходимо обеспечение разграничения доступа на уровне приложений, сетевая защиты и др. Специализация разработчиков позволяет разделить работу программистов на определенные участки, предоставляет возможности подключения к программам модулей, созданных сторонними разработчиками.
Зачастую при разработке программных продуктов приходится многократно производить набор одних и тех же действий. Например, выводить предупреждения о невозможности выполнения определенного действия. При программной реализации стандартных используются библиотеки, содержащие подпрограммы (процедуры), используемые для исполнения стандартных действий. Данные «заготовки» могут использоваться в качестве готовых модулей при разработке программы.
Программистами могут использоваться стандартные процедурные библиотеки процедур, а также создаваться модули собственной разработки.
При использовании готовых внешних модулей всегда возникают проблемы их совместимости с разрабатываемой программой, решаемые с помощью стандартов, позволяющих проводить запись библиотечных подпрограмм в формате, обеспечивающем максимальный уровень совместимости.
При использовании разработки по модели «сверху вниз» алгоритмы и данные разделяются на автономные части, называемые модулями, некоторые из которых являются стандартными и входят в комплект поставки сред разработки. Примеры стандартных внешних модулей: математические библиотеки, библиотеки печати, конструкторы отчетов и т. д. Но большую часть модулей приходится разрабатывать программистам.
Таким образом, готовые программные продукты представляют собой дерево модулей: из одних модулей осуществляется вызов других модулей, начиная с высшего модуля, являющегося корневым, или головной программой.
Принцип модульности в языках программирования предполагает разделение программы на отдельные компоненты, называемые модулями.
Характеристики модулей [3]:
 наличие одного входа и одного выхода – на входе программные модули получают заданный набор информации, выполняют содержательную обработку и возвращают заданные результатные данные, таким образом реализуется стандартный принцип IPO (Input — Process — Output) – вход-процесс-выход;
 наличие функциональной завершенности, что предполагает выполнение перечня регламентированных операций, используемых для реализации определенной функции в полном составе, достаточных для окончания запущенной обработки;
 логическая независимость, предполагающая, что результаты работы программного модуля определяются только исходными данными, но не зависят от работы других модулей;
 наличие слабых информационных связей со смежными программными модулями (минимизация обмена данными между модулями);
 модуль представляет собой обозримый по размеру и сложности программный элемент.
Таким образом, в модулях содержатся определения доступной для обработки информации, описание перечня операции обработки данных, описание схем взаимосвязанности со смежными модулями.
В каждый модуль входит спецификация и тело. В спецификации определяются правила работы с модулем, а в теле – методы обработки данных.
Модульный принцип разработки программ является самым старым по возрасту принципом программирования. Разработка программ в соответствии с данным принципом проводится исключительно по частям – написание частей поочередно с проведением тестирования с последующей сборкой. Таким образом, готовый программный продукт представляет собой сборку различных по функциональному назначению систем. Большое преимущество указанного подхода связано с возможностью работы над программой не одним программистом, а несколькими группами. Модульный принцип используется в языках Рascal, C, Phyton, Perl.
Модульный принцип программирования – это организация программного обеспечения как совокупности отдельных независимых блоков (модулей), структура и функционал которых определяется в соответствии с заданными заранее правилами.
Модульный принцип программирования используется при разработке больших программ.
Разработка сложных программных продуктов проводится, как правило, коллективом программистов, каждый из которых проводит разработку определенной самостоятельной части программы. И он в таком случае отвечает за конструирование всех необходимых процедур и данных для этих процедур. Сокрытие данных (запрет доступа к данным из-за пределов модуля) защищает их от случайного изменения и соответственно нарушения функциональности программы. Для взаимодействия отдельных частей (модулей) программы коллективу программистов необходимо провести разработку интерфейса, в котором проводится взаимодействие сконструированных модулей в основной программе.
Принципы модульного программирования программного обеспечения продуктов имеют сходство с нисходящим проектированием. Первоначально определяется состав и подчиненность функционала, далее – список программных модулей, в которых реализуются данные функции.
Реализация однотипного функционала проводится с использованием одних и тех же модулей. Функции верхнего уровня обеспечиваются в главном модуле, который управляет работой функций на подчиненных уровнях, которым соответствуют автономные модули.
При определении набора модулей, в которых реализуются функции конкретных алгоритмов, необходимо учитывать специфику модульного принципа, включающую [7]:
 вызов каждого модуля вызывается на исполнение производится с вышестоящего модуля и, при окончании работы, производит возврат на вызвавший его модуль;
 принятие основных решений при реализации алгоритмов алгоритме осуществляется на максимально «высоком» по иерархии уровне;
 для использования одних и тех же функций в разных блоках алгоритма используется один модуль, вызываемый на выполнение при необходимости. В результате дальнейшей детализации алгоритмов проводится реализация функционально-модульной схемы алгоритма, являющейся базовой для проведения разработки.
Методологии структурного программирования базируются на работе с подпрограммами и независимыми структурами данных.
Подпрограммы представляют собой поименованные или иным образом идентифицированные части компьютерных программ, в которых содержится описание определённого набора действий. Подпрограммы могут многократно вызываться из разных частей программы.
Назначение подпрограмм. Подпрограммы первоначально использовались как средство оптимизации программ по критерию объёма используемой памяти, что позволяло не повторять в основной программе одинаковые блоки кода, а проводить их описание однократно и вызывать при необходимости. На сегодняшний день указанная функция подпрограмм является вспомогательной, главным их назначением является структуризация программы для удобства работы с программным кодом и возможностью сопровождения
Выделение набора действий в подпрограмму и вызов её по мере необходимости позволяет логически выделить целостную подзадачу, имеющую типовое решение. Данное действие обладает ещё одним (кроме экономии памяти) преимуществом перед повторением одинаковых действий: при любом изменении (исправлении ошибок, оптимизации, расширении функционала), сделанном в подпрограмме, проводится автоматическое отражение на всех её вызовах, в то время как при дублировании каждое изменять необходимо блоки во всех областях программного кода.
Экстремальное программирование или XP, eXtreme Programming — гибкая методология разработки программного обеспечения. Как и у других agile методологий, у нее есть особенные инструменты, процессы и роли. Хотя автор XP не придумал ничего нового, а взял лучшие практики гибкой разработки и усилил до максимума. Поэтому программирование и зовется экстремальным [1].
Цель методики XP — адаптация с постоянно изменяющимся требованиям к программным продуктам и повышение качественных характеристик процесса разработки. В силу этого, методология XP оптимально подходит для сложных продуктов с большой степенью неопределенности.
Методология XP построена вокруг следующих процессов: кодирование, тестирование, дизайн и слушание. Также, ценностями экстремального программирования являются: простота, коммуникация, обратная связь (рисунок 22).

Рисунок 22 — Схема практики экстремального программирования

Преимущества экстремального программирования проявляются в случаях, когда командой полноценно используется хотя бы одна из практик XP, к которым относятся [2]:
 заказчик получает только необходимый ему продукт, даже если первоначально не имеет точных представлений о его конечном виде
 команда быстро проводит внесение изменений в код и добавление новой функциональности за счет простоты дизайна кода, частого планирования и релизов
 работа кода обеспечивается постоянным проведением тестирования и непрерывности процесса интеграции
 командой проводится поддержка код, т.к. он разработан в соответствии с единым стандартом и постоянно рефакторится
 скорость процесса разработки обеспечивается парным программированием, отсутствием переработок, присутствием представителей заказчика в команде
 высокое качество кодирования
 снижение рисков, связанных с разработкой, т.к. ответственность за продукт распределена равномерно и кадровые перестановки в команде не нарушают процесс
 затраты на разработку ниже, т.к. команда ориентирована на кодирование, а не на документацию и собрания.
Первой ценностью ХР являются коммуникации. Проблемы, возникающие в процессе работы над продуктом, почти всегда обусловлены тем, что не была передана необходимая информация. Иногда программист не сообщает кому-то о важном изменении в дизайне. Иногда программист не задает заказчику важного вопроса, и в результате важное принятое им решение оказывается неправильным. Иногда менеджер не задает программисту важного вопроса, в результате у него складывается неполное, а иногда и неправильное представление о состоянии продукта.
Сложности в коммуникации между разработчиками ИТ-продуктов усиливаются с ростом объемов проекта. Существует огромное количество предпосылок, которые ведут к нарушению коммуникации. Например, программист сообщает менеджеру плохие новости и менеджер наказывает программиста. Заказчик сообщает программисту нечто важное, а программист делает вид, что не понял или просто проигнорирует эту информацию.
Дисциплина ХР нацелена на обеспечение непрерывных, постоянно осуществляемых коммуникаций между участниками процесса проектирования. В рамках ХР применяется ряд методик, которые невозможно реализовать без коммуникации. Данные методики направлены на достижение краткосрочных целей, например, тестирование модулей, программирование парами, а также оценка сложности задачи. В процессе тестирования, программирования парами и формирования предварительных оценок программисты, заказчики и менеджеры вынуждены тесно взаимодействовать.
Это не означает, что излишние разговоры мешают работе. Люди часто попадают в ситуацию, когда они сомневаются, делают ошибки, отвлекаются. В рамках ХР существует специальное ответственное лицо – инструктор (coach), в чьи обязанности входит следить за тем, чтобы люди общались тогда, когда это надо. Если инструктор замечает, что люди перестают общаться, он стимулирует коммуникацию.
Для создания стратегии максимизации экономической выгоды при реализации методологии экстремального программирования, связанной с продуктом, необходимо провести анализ следующих трёх факторов:
 анализ структуры финансовых потоков, втекающих в продукт и вытекающих из него;
 оценку коэффициентов прибыли (процентная ставка);
 вероятность выживания продукта.
Максимизировать экономическую выгоду можно следующим образом:
 минимизация затрат, однако это достаточно сложно, так как изначально каждый обладает примерно одним и тем же набором знаний и инструментов;
 максимизация заработка, однако это возможно только при наличии оптимальной маркетинговой стратегии;
 откладывание затрат на последующие периоды при опережающем получении прибыли, благодаря этому с учетом коэффициентов прибыли придется нести меньшие затраты за счет процентной ставки на затраченных средствах, и получать больше за счет процентной ставки на отчислениях с продаж;
 увеличения времени эксплуатации ИТ-решения.
Управление крупными ИТ-продуктами предполагает необходимость использования программных решений, обеспечивающих возможности анализа хода их реализации. Класс ИТ-решений для автоматизации указанных задач – системы управления ИТ-продукт.

2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание

Для каждого из этапов создания информационной системы характерно наличие рисков, которые создают вероятность срыва сроков и увеличения бюджета проекта.
Далее проведем оценку степени влияния каждого из видов рисков, характерных для каждой из стадий жизненного цикла информационной системы (таблица 11).

Таблица 11
Оценка влияния рисков реализации проекта автоматизации

Таким образом, на всех этапах жизненного цикла системы необходимо минимизировать негативное влияние рисков указанного типа.

2.1.1. Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации

При внедрении информационной системы учета заявок на доступ к серверным ресурсам необходимо определить пользовательские роли и комплекс их полномочий, что позволит организовать эффективную систему разграничения доступа к системе.
В таблице 12 приведено описание пользовательских ролей в ИС учета заявок на доступ к серверным ресурсам в условиях ООО ПК «ВентКомплекс».
Таблица 12
Описание пользовательских ролей в ИС в условиях ООО ПК «ВентКомплекс»
Мерами защиты от угроз халатности сотрудников могут быть [34]:
 максимальное понижение уровня доступа пользователя на рабочей станции;
 регламентация временных параметров работы неактивных сеансов;
 принятие нормативных документов и определение ответственности пользователей за нарушение регламентов информационной безопасности.
Низкая квалификация
Зачастую вследствие низкой квалификации пользователю затруднительно понять, с чем он имеет дело; из-за этого даже программные продукты с достаточной степенью защищённости предполагают необходимость тонкой настройки со стороны администраторов безопасности.
Таким образом, защитой от угроз, обусловленных недостаточностью квалификации персонала, могут быть:
— проведение технических учеб со специалистами по вопросам информационной безопасности;
— включение вопросов по информационной безопасности при аттестации сотрудников;
— оценка квалификации сотрудника при принятии на работу или кадровом перемещении.
Архитектура защиты информации определяется структурой телекоммуникационной сети предприятия, типом обрабатываемой информации, моделью нарушителя. таким образом, средства защиты информации необходимо выбирать в соответствии с актуальными угрозами. Выбор оптимальных решений в области защиты информации необходимо производить на основании результатов моделирования угроз с использованием соответствующего математического аппарата.
В компании организована система обучения сотрудников в части выполнения регламентов защиты информации. Допуск к работе с информационными ресурсами пользователи сдают в форме тестирования. В ходе анализа организации работы с защищаемыми ресурсами были выявлены следы инцидентов, связанные с отсутствием защиты от несанкционированного копирования данных. В информационной системе отсутствует инструмент, позволяющий выявлять признаки утечек конфиденциальной информации, отсутствует реестр информационных ресурсов, содержащих конфиденциальные данные.
Для технологического обеспечения требований защиты информации в условиях ООО ПК «ВЕНТКОМПЛЕКС» используются программные и аппаратные решения, перечень которых приведен в таблице 13. По каждому из инструментов по защите информации приняты соответствующие регламентирующие документы.

Таблица 13
Описание технологических средств защиты информации

В таблице 14 показано распределение функций в области защиты информации в ООО ПК «ВентКомплекс».
Таблица 14
Распределение функций в области защиты информации в ООО ПК «ВентКомплекс»

Таким образом, в условиях ООО ПК «ВентКомплекс» создана организационная структура, обеспечивающая выполнение требований информационной безопасности, включающая как специалистов по защите информации, так и ответственных в подразделениях предприятия, что обеспечивает распределение уровней ответственности и эффективность выполнения работ по защите информации.
Предоставление доступа к информационным ресурсам, содержащим конфиденциальную информацию, оформляется начальником отдела через служебную записку на имя администратора защиты информации, который в случае нахождения ресурса на уровне подразделения предоставляет доступ, в случае нахождения на уровне сторонней организации оформляет заявку в соответствующий профильный отдел. Для каждого из информационных ресурсов разработаны формализованные заявки. При необходимости закрытия доступа аналогично на основании служебной записки начальника отдела составляется заявка на закрытие доступа к информационному ресурсу.
Все проведенные мероприятия по защите информации необходимо протоколировать в журналах [10]:
 Журнал мероприятий по защите информации, где протоколируются все действия, связанные с проведением работ по защите информации с датой и росписью специалиста, их проводившего;
 Журнал регистрации нештатных ситуаций, связанных с защитой информации, куда заносится информация о происшествиях, связанных с нарушениями требований защиты информации и принятых мерах к специалистам, допустившим нарушения.
Контроль за организацией обеспечения защиты информации в подразделениях компании осуществляется в формах:
 комплексные проверки системы информационной безопасности (периодичность – 4 года);
 выборочные запросы документов в электронном виде администраторов защиты информации;
 запросы отчетности по проведенным мероприятиям.
При проведении выбора стратегии проектирования системы информационной безопасности различаются следующие стратегии [9]:
— оборонительная;
— наступательная;
— упреждающая.
Предпочтение в сторону оборонительной стратегии предполагает, что при исключении вмешательства в технологию функционирования информационной системы, можно проводить лишь нейтрализацию наиболее опасных угроз. Как правило, это можно достичь путем построения «защитных оболочек», включающих возможность разработки дополнительных организационных мер, создания программных технологий по разграничению доступа информационным ресурсам, использования технических средств для осуществления контроля помещений, где располагается терминальное и серверное оборудование.
Использование наступательной стратегии предполагает возможность активного противодействия наиболее известным угрозам, которые могут оказать влияние на состояние информационной безопасности системы. Наступательная стратегия предполагает необходимость установки дополнительных средств пользовательской аутентификации на программном и аппаратом уровнях, внедрения более современных технологий по резервированию и восстановлению информации, рост уровня доступности системы с применением систем по горячему и холодному резервированию [8].
Использование упреждающей стратегии предполагает возможность тщательного исследования возможных угроз для систем обработки данных и разработку мероприятий по их нейтрализации еще на этапе проектирования и тестирования системы. Важная часть упреждающей стратегии предполагает необходимость проведения оперативного анализа информации из центров изучения проблем защиты информации, анализ отечественного и мирового передового опыта, проведение независимого аудита уровня обеспечения защиты информации на предприятиях.
Изучение структуры информационной системы показало, что оптимальной стратегией разработки системы информационной безопасности будет являться наступательная стратегия, что предполагает наличие следующих этапов проектирования [7]:
— внедрение дополнительных средств антивирусной защиты (проверка внешних носителей информации на выделенной рабочей станции с установленным альтернативным антивирусным ПО);
— управление использованием внешних носителей информации (допуск к использованию USB-подключений носителей информации на рабочих станциях, где это технологически необходимо);
— внедрение корпоративной версии антивирусного ПО (что позволит автоматизировать процессы централизованного управления системой антивирусной защиты);
— внедрение почтового антивируса, позволяющего блокировать вложения, содержащие вредоносные файлы.
Организационные меры защиты информации включают в себя [5]:
— изменение положений инструкции по антивирусной защите в соответствии с внесенными изменениями;
— ознакомление сотрудников под роспись с требованиями антивирусной защиты;
— определение ответственности специалистов в рамках нормативных документов в области защиты информации;
— определение групп пользователей по уровню доступа к рискованным операциям (подключению внешних USB-накопителей, работе с внешней электронной почтой, наличию прав локального администратора на рабочих станциях).

2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание

На рисунке 16 приведена информационная модель системы. Как показано на рисунке 16, информационная модель системы включает области:
1– Область администратора, связанная с заполнением базы данных, куда вводится информация о сотрудниках компании, настройки ролей доступа;
2 – Область работы пользователя, в которой проводится ввод данных по заявкам пользователей.
3 – Область формирования отчетности.

Рисунок 16 – Информационная модель системы

2.2.2. Характеристика нормативно-справочной, входной и оперативной информации

Сущностями разрабатываемой информационной системы являются:
— Базы данных;
— Пользователи;
— Роли;
— Заявки.
На рисунке 17 приведена ER-диаграмма разрабатываемой системы.

Рисунок 17 — ER-диаграмма разрабатываемой системы

Для выбранных сущностей информационной системы установлены связи:
 Для одной базы данных существует множество ролей. Связь 1:N.
 Каждый пользователь входит в систему разграничения доступа множество раз. Связь 1:N.
 Каждая роль входит в заявки множество раз. Связь 1:N.
Далее приведем описание структуры таблиц информационной системы.
Таблица 15
Структура таблицы «Базы данных»

На рисунке 18 показана логическая модель разрабатываемого сервиса. На рисунке 19 показана диаграмма вариантов использования. На рисунке 20 приведена диаграмма кооперации. На рисунке 21 показана диаграмма деятельности. Как показано на рисунке 19, сценарий руководителя отдела включает работу по вводу заявок на предоставление (изменение) доступа к сетевым ресурсам, сценарий администратора связан с ведением классификаторов, учетом заявок на предоставление доступа к информационным ресурсам.

Рисунок 18 — Физическая модель данных сервиса формирования заявок на доступ к ресурсам сервера БД

Рисунок 19 — Диаграмма вариантов использования

Рисунок 20 — Диаграмма кооперации

Рисунок 21 — Диаграмма деятельности

Рисунок 22 — Диаграмма компонентов

2.2.3. Характеристика результатной информации

Шаблон выходного документа «Доступ сотрудника» приведён в таблице 19.
Таблица 19
Шаблон выходного документа «Доступ сотрудника»
Параметры: Сотрудник: ФИО
Шаблон выходного документа «Матрица доступа» приведён в таблице 20.
Таблица 20
Шаблон выходного документа «Матрица доступа»
Шаблон выходного документа «Отчет по информационному ресурсу» приведён в таблице 21.

Таблица 21
Шаблон выходного документа «Отчет по информационному ресурсу»
Параметры: Наименование БД

 

2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)

Схема «Дерево функций» позволяет наглядно показать иерархию функций управления и обработки данных, которые автоматизированы в разработанном программном продукте.
В системе определены следующие типы функциональных возможностей системы (рисунок 23) [9]:
 служебные функции, связанные с авторизацией пользователей, настройкой интерфейса и др.;
 функционал, связанный с обработкой информации, включающий ведение справочной, оперативной информацией по учету заявок на доступ к серверным ресурсам.

Рисунок 23 — Дерево функций

На рисунке 24 приведен сценарий диалога системы.

Рисунок 24 — Сценарий диалога системы

Таким образом, интерфейс разрабатываемого программного продукта должен соответствовать показанной структуре и включать перечень указанных основных и служебных функций.

2.3.2. Характеристика базы данных

Создание информационной системы проведено в формате «1С: Предприятие». Далее приведено описание структуры данных в формате данной системы.
Таблица 22
Структура таблицы «Базы данных»
Таблица 23
Структура таблицы «Сотрудники»
Таблица 24
Структура таблицы «Роли»
Таблица 25
Структура таблицы «Заявки на доступ»

2.3.3. Структурная схема пакета (дерево вызова программных модулей)

На рисунке 25 показано дерево вызова программных модулей.

Рисунок 25 — Дерево вызова программных модулей

В таблице 26 приведено описание программных модулей системы.
Таблица 26
Описание программных модулей

2.3.4. Описание программных модулей

Рассмотрен программный модуль М6 «Отчет по заявкам».
При вызове модуля производится формирование и вывод на экран отчета, содержащего отчет по рейтингу сотрудников по данным опросов клиентов. Специалист по поставкам, ознакомившись с документом, может его распечатать или сохранить на жесткий диск в формате Microsoft Word (Текст RTF). Развернутая блок-схема работы модуля М6 представлена на рисунке 26.
Структура представления (VIEW) SVOD_3, предназначенного для получения отчета, представлена в таблице 27.
Таблица 27
Структура записи представления SVOD_3

Рисунок 26 — Блок-схема модуля М6

Как показано на блок-схеме алгоритма, приведенной на рисунке 26, работа с системой по формированию отчета по заявкам на доступ к серверным ресурсам включает этапы:
— открытие главной формы;
— выбор режима формирования отчета;
— просмотр результатов выборки;
— сохранение результатов.
Таким образом, интерфейс разрабатываемого программного продукта должен соответствовать показанной структуре и включать перечень указанных основных и служебных функций.

2.4. Контрольный пример реализации проекта и его описание

Прототип системы автоматизации учета заявок на доступ к серверным ресурсам включает компоненты:
 Перечисления: Статусы заявок, Уровни доступа;
 Справочники: Пользователи, Базы данных, Роли, Должности;
 Документы: Заявка на доступ;
 Система отчетности;
 Регистр накопления: Доступ.
Разработка системы была проведена с использованием среды «1С: Предприятие 8.3». На рисунке 27 приведена главная форма системы.

Рисунок 27 – Главная форма

На рисунках 28-29 показан режим работы со справочником должностей.

Рисунок 28 — Справочник должностей (создание)

Рисунок 29 -Справочник должностей

На рисунках 30-31 показан режим работы со справочником информационных ресурсов сервера баз данных.

Рисунок 30 – Справочник информационных ресурсов сервера (создание)

Рисунок 31 – информационных ресурсов сервера (список)
На рисунке 32 приведен справочник информационных подсистем.

Рисунок 32 – Справочник информационных подсистем

На рисунках 33-37 показаны режимы работы со справочником сотрудников.

Рисунок 33 – Справочник сотрудников (создание)

Рисунок 34 – Справочник сотрудников

Режим работы с заявками на доступ к подсистемам показан на рисунках 35-36.

Рисунок 35 – Заявка на доступ к информационному ресурсу

Рисунок 36 – Журнал заявок на доступ к подсистемам
Отчет «Матрица доступа» показан на рисунке 37

Рисунок 37 – Матрица доступа (печатная форма)

Матрица доступа содержит информацию о пользователях информационной системы и уровнях предоставленного для них доступа к прикладным подсистемам.
Отчет по доступу сотрудника показан на рисунке 38.
Параметры: Сотрудник: Таранова Нина Андреевна

Рисунок 38 – Отчет по работе с информационным ресурсом

Далее приведем краткой обзор процесса создания конфигурации в системе «1С: Предприятие» для автоматизации поставленных задач.
На рисунке 39 приведена настройка работы со справочной подсистемой.

Рисунок 39 – Настройка работы со справочной подсистемой

На рисунке 40 приведен режим настройки перечисления «Уровни доступа к информационным ресурсам». На рисунке 41 приведен режим настройки справочника пользователей. На рисунке 42 приведен режим настройки документа «Заявка на доступ», в котором указан формат реквизитов, входящих в заявку на предоставление доступа к информационным ресурсам. На рисунке 43 приведена настройка макета печатной формы данного документа, в котором проводится настройка выходной формы бланка заявки, предназначенной для ведения документооборота.

Рисунок 40 – Структура перечисления «Уровни доступа к информационным ресурсам»

Рисунок 41 – Настройка справочника пользователей

Рисунок 42 – Настройка документа «Заявка на доступ»

Рисунок 43 – Настройка макета печатной формы документа «Доступ к подсистемам»

На рисунке 44 приведена настройка отчета «Таблица управления доступом».

Рисунок 44 – Настройка отчета по структуре клиентской базы

На рисунке 45 приведена обработка проведения документа «Заявка на доступ», в которой приведены правила записи данных в регистр накопления, в котором осуществляется хранение данных архива заявок.
На рисунке 46 приведен режим настройки ролей пользователей. На рисунке 47 – настройка учётной записи.

Рисунок 46 – Настройка прав администратора

Рисунок 47 – Настройка учётной записи

Тестирование программного обеспечения проводится на уровнях выполняемых функций, системной архитектуры, а также при выпуске новых версий.
При проведении функционального тестирования выполняются работы:
— проверка функций, реализованных в системе, на предмет соответствия техническому заданию;
— проверка разграничения доступа по ролям пользователей, функционирование систем безопасности;
— проверка функционирования системы в инфраструктуре компании-заказчика на предмет обнаружения проблем совместимости.
При проведении нефункционального тестирования проводится анализ качества реализованного интерфейса, проводится расчет машинного времени на выполнение технологических операций. Тестируются нагрузки системы в различных операционных системах, производительность при различных нагрузках.
При проведении тестирований после изменения версий ПО проверяется не только работа измененных режимов, но и также выборочно анализируется работа системы в различных режимах.
Проверка работы информационных систем проводится посредством проведения тестирования следующих типов [7]:
— дымового тестирования (в рамках которого проверяется функциональность по основным направлениям использования ПО, на основании которой делается вывод о возможности использования ПО на рабочих местах пользователей);
— регрессивного тестирования (в рамках которого наряду с функционалом системы проверяется ее поведение в различных операционных системах, взаимодействие с различными форматами серверов баз данных и приложений);
— тестирования сборки, при котором анализируется поведение программы только по функциям, которые были подвергнуты корректировке;
— санитарного тестирования, в рамках которого в ручном режиме тестируется работоспособность системы на соответствие функционалу, заявленному в спецификации.
Проведение тестирования программного обеспечения осуществляется на различных уровнях в рамках поставленных задач. Тестирование может проводиться на каждом из этапов реализации системы, что позволяет обнаруживать ошибки на ранних стадиях и сократить время работ по созданию системы. В качестве объектов тестирования могут выступать как система в целом, так и отдельные ее модули. В зависимости от типа выбранного объекта тестирования определяются различные подходы к его проведению.
В таблице 28 приведено описание уровней тестирования
Таблица 28
Описание уровней тестирования
В таблице 29 приведено описание методов тестирования.
Таблица 29
Описание методов тестирования

Проведение функционального тестирование предполагает использование следующих методов [9]:
 эквивалентного разбиения;
 анализа пограничных значений;
 работы с причинно-следственными связями;
 предположения об ошибке.
В рамках данной работы для проектирования системы учета заявок на доступ к серверным ресурсам проведено определение выбора стратегии тестирования, включающей [14]:
 Функциональное тестирование в части проверки реализации задач, определенных в рамках деятельности службы маркетингового отдела;
 Уровень тестирования: компонентный (модульный), так как предполагается проверка функционала приложения в разбиении на модули: учет объектов ИТ-инфраструктуры, учета поступающих заявок и их отработки, формирования отчетности. Проведение системного тестирования не представляется возможным, так как отсутствуют возможности развертывания системы на различных платформах с различным аппаратным обеспечением;
 Метод тестирования: эквивалентное разбиение, в рамках которого каждая из функций разбивается на группы, в которых проводится поиск ошибок функционирования.
Созданный программный продукт обеспечивает возможности работы со справочной, оперативной информацией и формирование отчетности в соответствии с поставленными задачами.
В рамках тестирования разработанного ПО методом черного ящика была проверена корректность работы системы.
1.Позитивный тест-кейс, в котором проведена проверка функциональности системы работы с пользовательскими учётными записями.

Таблица 30
Позитивный тест-кейс
1. В таблице 31 приведено описание тестового сценария, в котором проводится проверка функциональности по вводу информации по заявкам на предоставление доступа к информационным ресурсам.
Таблица 31
Простой тест
2. В таблице 32 приведено описание тестового сценария, в котором проводится проверка функциональности формирования отчета по уровням доступа пользователей к информационным ресурсам (таблицы управления доступом).

Таблица 32
Сложный тест

Таким образом, успешно проведено тестирование основных режимов разработанной системы, ошибок не выявлено.
Выводы по разделу
В практической части работы проведено построение структуры данных информационной системы учета заявок на доступ к серверным ресурсам. Проведено планирование процесса разработки информационной системе, выбрана стратегия внедрения, модель жизненного цикла, оценено влияние возможных рисков, связанных с процессом разработки информационной системы. Определен перечень сущностей информационной системы, установлены межтабличные связи. Первоначально проведено построение информационной модели, в рамках которого определен набор используемых в системе таблиц, интерфейсов и пользовательских сценариев. Проведено построение логической, физической моделей, в которых описан реквизитный состав каждого из информационных объектов, определен тип данных. Далее проведено моделирование в UML, в котором построена диаграмма вариантов использования, активностей, последовательностей, определены требования к архитектуре системы. Далее проведено обоснование выбора средства разработки, описан прототип созданного программного обеспечения, в котором реализованы возможности работы со справочной, оперативной и отчетной информацией, проведено тестирование разработанной системы, в котором проведен анализ соответствия реализованного функционала поставленным задачам. в ходе проведенного тестирования ошибок не выявлено.
Таким образом, все поставленные задачи автоматизации выполнены.

---

1 2 3