56
функциональных моделей. По итогам этапа составляется подписываемый всеми
участниками проекта внедрения документ, описывающий все установленные
недостатки и намечает пути их решения.
2. Реализация информационно—функциональной модели работы
предприятия, оптимизация и описание процессов, которые подлежат
автоматизации. Моделирование должно осуществляться хорошо обученными
сотрудниками исследуемой компании с привлечением опытных консультантов и
с привязкой построенной модели к стандартам бизнеса и к только что
спроектированной системе.
3. Адаптация ИС внутри компании. В ходе этапа реализуется настройка
системы тестирование ключевых модулей и функций группой внедрения. Этот
этап также требует наличия корпоративных стандартов, поскольку именно они
составляют основу настроек системы [41].
4. Опытная эксплуатация ИС. Реализуется для тестирования четкого
соответствия функциональности, полученной в процессе отладки системы,
требованиям компании. На этом этапе присутствует двойной ввод данных в
новую и старую системы. В процессе опытной эксплуатации: создаются
стандартные отчеты (при помощи ИС и стандартными способами) и реализуется
проверка данных; система шаг за шагом вводится в эксплуатацию по каждому
участку учета; документируются инструкции по обслуживанию рабочих мест и
дополняются должностные инструкции всех членов учетного процесса.
В отдельных подразделениях компании в систему добавляются
фактические данные (в минимальном объеме) и последовательно проверяются
бизнес—функции при помощи моделирования реальных ситуаций работы
компании (в максимально приближенных к действительности условиях).
Оттачивается слаженная работа подразделений на базе тестовых пилотных
примеров. Конечные пользователи (сотрудники IT-отдела) проходят обучение с
настроенной системой только на своих рабочих местах.
По завершению обучения конечных пользователей реализуется
встроенный пилотный пример и полностью моделируется работа компании.
57
Основываясь на результатах реализации пилотного примера руководство
компании принимает решение о переводе ИС в повседневную эксплуатацию.
Этап эксплуатации подразумевает под собой непосредственное использование
информационной системы для выполнения ею тех функций, для которых она
предназначена [20].
Для внедрения системы выбираем стратегию Пилотный проект. Работы,
ожидаемые на этапе эксплуатации, можно разделить на две группы: плановые и
неплановые. К плановым работам будут относятся такие работы, как:
инсталляция программного обеспечения;
базовая настройка и проверка работоспособности компонентов
устанавливаемой системы;
устранение недостатков в конфигурации системы;
проверка надежности работы системы;
окончательная донастройка.
Данные работы будут выполнять специалисты отдела ИТ. Модель
жизненного цикла ПО отражает структуру, определяющую последовательность
реализации и взаимосвязь процессов, действий и задач в рамках всего ЖЦ.
Модель ЖЦ зависит от специфики, масштаба и трудности проекта и конкретных
условий, в которых система развивается и работает. Сегодня наибольшее
распространение получили три базовые модели ЖЦ:
Задачная модель; 64
Каскадная модель (70-85 г.г.);
Спиральная модель (сегодняшние дни).
ЖЦ программных средств (ПС) обычно представляет собой набор этапов,
работ и операций в порядке их реализации и взаимосвязях, определяющих
ведение работ от составления технического задания до финальных испытаний
ряда версий и завершения эксплуатации ПС или ИС. Подобные стандарты
состоят из правил описания начальной информации, методики выполнения
операций, осуществляют контроль технологических процессов и правил
58
представления их результатов. Еще они определяют содержание
технологических и эксплуатационных документов на комплексы ПО [19].
Они выражают организационную структуру коллектива, поддерживают
распределение и планирование заданий, реализуют контроль над этапами
разработки комплекса ПС. Для составления жизненных циклов (ЖЦ) ИС был
выбран стандарт ISO 12207, как стандарт, включающий в себя большинство
автоматизированных систем (АС) и ПС, где ПС – малая часть всего плана работ.
Международный стандарт ISO/IEC 12207 показывает стратегию и общий
порядок в разработке и использовании ПО, он охватывает ЖЦ ПО от зарождения
идей до окончания цикла.
Определение стандарта: система — это совокупность одного или более
процессов, аппаратных средств, ПО, оборудования и людей для реализации
возможности удовлетворения конкретных потребностей или целей. В отличие от
Oracle CDM стандарт ISO 12207 одинаково нацелен на организацию действий
каждой из двух сторон: поставщик (создатель) и покупатель (клиент).
Применяется в разных случаях, даже когда обе стороны внутри одной компании.
В отличии от CDM, стандарт ISO состоит из более крупных обобщенных
процессов: «покупка», «доставка», «создание» и т.п. Любой процесс разделен на
набор действий, а каждое действие — на совокупность задач. Важно одно
отличие ISO: любой процесс, действие или задача определяется и реализуется
другим процессом по мере необходимости, причем нет ранее заданных
последовательностей (конечно, в рамках сохранения логики связей по
начальным сведениям задач и т.п.) [29].
Развивающийся характер стандарта зависит от способа выражения
последовательности выполнения процессов и задач, когда один процесс в случае
необходимости вызывает другой или его часть. Стандарт отражает архитектуру,
процессы, разделы и подразделы ЖЦ ПС, а также указывает список
необходимых работ и подробно описывает содержание каждой из них.
Архитектура ЖЦ ПС в стандарте основывается на 3 основных компонентах:
Покупка или поставка,
59
Создание,
Использование.
Стандарт не включает конкретные методы действий, а также заготовки
решений или документации. Он отражает архитектуру процессов ЖЦ ПО, но не
углубляется в детали реализации или выполнения услуги и задачи, включенных
в процессы. Стандарт не указывает конкретную модель ЖЦ или метод создания
ПО, но показывает, что стороны участники использования стандарта несут
ответственность за выбор модели ЖЦ для проекта ПО, за подгонку процессов и
задач стандарта к этой модели, за обоснованный выбор и использование методов
создания ПО, за реализацию действий и задач, уместных для проекта ПО.
Покупка или поставка.
Цель этапа – предложение разработчику от заказчика, на выполнение
автоматизированной системы. На этом этапе заключается договор,
корректируются его условия и требования. Участники этапа – ответственный от
лица заказчика, который контролирует и уточняет направления для
разработчиков. А также менеджер проекта от лица разработчиков. Он принимает
от заказчика 66 требования, подписывает договор, и согласует начальные
установки и задачи для работы. На этом этапе заказчик должен предоставить
развернутое техническое задание (ТЗ), менеджер утверждает его, уточняются
некоторые детали задания и согласовываются средние сроки выполнения
разработки [31].
Создание ПО разбито на множество небольших этапов, призванных
обеспечить создание ИС, отвечающей требованиям заказчика, и в договоренные
сроки:
Исследование требований к системе;
Построение системной архитектуры;
Исследование требований к ПС;
Построение архитектуры ПС;
Детальное проектирование ПС;
60
Реализация и тестирование ПС;
Внедрение ПС;
Квалификационная проверка системы;
Начало эксплуатации ПС;
Финальная приемка ПС.
Основные участники на этом этапе – это менеджер проектов и
непосредственные разработчики. Сам менеджер разбивает задачу разработки ПС
на вышеперечисленные этапы, следит за их выполнением, контролирует ход
выполнения за каждым разработчиком. При необходимости сам участвует в
разработке или координации действий между отдельными разработчиками.
Определяет участки работы для каждого отдельного разработчика в зависимости
от квалификации и опыта, определяет степень универсальности взаимодействия
отдельных частей ПС, разрешает коллизии и спорные моменты. Разработчики
принимают план работ, поле деятельности и конкретные задачи для выполнения.
Определяют для себя методы решения своих задач, согласовывают пути
взаимодействия с программными частями других разработчиков, спецификации
функций, протоколов передачи данных, и др. Использование. На этом этапе
проводятся тестовые испытания ПС, определяются сильные и слабые моменты,
недоработки, и слаженность работы всех компонентов. При выявлении
недоработок определяются перечень указаний для исправлений разработчиками
[27].
Таким образом, уточнив критерии проекта автоматизации, можно сделать
следующие выводы.
1. Разработать локальную систему защиты информации ООО «Волга».
2. Система автоматизации должна быть разработана в виде отдельного
независимого приложения, которое должно обеспечить возможность
оперативной и эффективной работы с любой информацией в соответствующих
объемах.
3. Вся информация должна храниться в соответствующих базах
данных.
61
4. Система защита информации должна осуществлять автоматизацию
работы менеджера по работе с персональными данными с различной
информацией.
5. Процесс работы с информацией должен быть доведен до такой
степени автоматизации, при которой от пользователя требовался бы минимум
усилий и действий.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Стандарт дает некоторую гарантию минимальных рисков, поскольку весь
процесс создания проекта делится на этапы. На каждом из этапов есть свои роли
и цели, которые должны быть достигнуты с учетом некоторых рисков. При этом
на фазе концепции могут возникать такие риски:
Неправильный анализ сроков и бюджета проекта.
Чтобы убрать этот риск, необходимо более детально прорабатывать разные
задачи и цели проекта, а также ставить больше точек контроля.
Неверно подобранный проектный состав исполнителей.
Чтобы избавиться от такого риска, необходимо тщательно подбирать
специалистов в проектную группу и тестировать их профессиональные навыки и
личностные качества.
На фазе планирования также может появиться риск некорректно
сформированной архитектуры выбранного решения. В данном случае многое
зависит от знаний и компетенции руководителя проекта, отвечающего за
принятие решений о выборе архитектуры разрабатываемого решения.
На фазе разработки также возможны следующие риски:
Неправильная интерпретация технического задания и неверное
программирование архитектуры со сдвигом сроков.
Чтобы минимизировать этот риск, необходимо четко писать техническое
задание, которое будет понятно программисту.
Отсутствие необходимой квалификации у программиста в том языке, на
основании которого он должен составить программу для клиента.
62
Несоблюдение установленных временных рамок на разработку
календарного плана проекта.
Такое часто происходит при привлечении внешнего разработчика
(фрилансера).
На фазе тестирования также может возникнуть риск незавершенного
процесса. В этом случае необходимо заново тестировать программный продукт
после корректировки.
На фазе внедрения существует риск неправильного принятия решения о
завершенности проекта. Как следствие, в последующей работе могут появиться
нестыковки с другими частями ранее разработанной информационной системы.
Их необходимо устранить для повторной интеграции.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Совершенствование деятельности субъектов хозяйствования связано с
внедрением новых методов и механизмов управления в разрезе отдельных
функциональных направлений. Одним из наиболее перспективных способов
решения этой задачи является автоматизация управленческого процесса, что
непосредственно реализуется во внедрении автоматизированных
информационных систем. Однако серьезным сдерживающим фактором на этом
пути выступает низкая их надежность [13].
Проблемы с надежностью программного обеспечения обусловливают
необходимость авансирования значительных финансовых ресурсов в
организацию:
- тестирования;
- адаптации под нужды конкретного заказчика;
- сопровождения в процессе эксплуатации.
Понятие надежности программного обеспечения является многогранным и
комплексным, отражающим его эффективность для пользователей и затратность
63
в процессе эксплуатации. По мнению Г. Майерса, представленному в его
работах, можно рассматривать такие особенности параметра надежности систем:
- наличие ошибки в программном обеспечении проявляется в факте
невыполнения тех задач, которые были поставлены пользователем, и решение
которых ожидается в связи с использованием ПО;
- любой отказ программного обеспечения – это конкретный случай
проявления ошибки;
- надежность рассматривается как вероятность безотказной работы
программного обеспечения в рамках заданного отрезка времени, который
определяется исходя из понесенных расходов по причине возникновения
конкретного отказа.
В связи с этим можно утверждать, что надежность программного
обеспечения не может ограничиваться исключительно внутренними
характеристиками и программными особенностями. Надежность должна
анализироваться как комплексное понятие, поставленное в зависимость от самой
программы и от конкретных задач, определенных пользователем, а также его
ожиданий от работы программного обеспечения.
Все многообразие ошибок можно свести к двум основным типам
(группам):
1) Сравнительно более высокий уровень сложности программного
обеспечения, например, относительно используемой в работе аппаратуры ЭВМ;
2) Некорректное преобразование массивов информации, вследствие чего
возникают искажения при переводе данных из одного представления в другое
как на микроуровне, так и на макроуровне. Преобразования на макроуровне
связаны с процессами передачи и обработки информации в рамках проекта. Они
проявляются в отношениях между организациями, подразделениями и
специалистами на всех этапах ЖЦ рассматриваемого программного обеспечения
[11]. Микроуровень охватывает проблемы преобразования данных по отдельным
исполнителям. Здесь все манипуляции с информацией происходят в такой
последовательности:
64
- получение информации;
- запоминание;
- извлечение из памяти;
- воспроизведение данных, или передача.
Оценка надежности программного обеспечения должна производиться с
учетом не только типов ошибок, но и причин их происхождения. Все угрозы
надежности подразделяются на:
1) Внутренние, природа которых лежит в особенностях самого ПО, –
ошибки проектирования, разработки и постановки алгоритмов,
программирования. Также внутренние угрозы надежности могут быть связаны с
невысоким уровнем инструментов обеспечения защиты, а также недостатками
документации.
2) Внешние ошибки, которые являются результатом внедрения и
эксплуатации ПО. К ним относят ошибочные действия пользователей, сбои в
работе ЭВМ, нарушения в функционировании каналов связи, внесение
конфигурационных преобразований в систему.
В связи с этим особую актуальность приобретает обеспечение процедуры
создания надежных программ. Все методы проектирования такого ПО сводятся
к трем основным группам:
- методы предупреждения ошибок, благодаря которым вероятность их
возникновения минимизируется, а конкретные проявления могут быть
устранены;
- методы обнаружения ошибок сводятся к разработке и реализации
отдельных функций, которые направлены на выявление нарушений в работе ПО;
- функции обеспечения устойчивости программ, позволяющие
своевременно исправлять ошибки и устранять негативные проявления их
последствий, а также предусматривающие возможность адекватной работы
системы в условиях проявления ошибки.
В процессе проектирования программного обеспечения необходим
постоянный мониторинг за процедурой реализации методов предупреждения
65
ошибок. Требуется исключить вероятность появления потенциальных
источников сбоя программы уже на данном этапе. К основным методам
противодействия причинам ошибок являются:
- методы, оптимизирующие программное обеспечение по параметрам
сложности системы;
- методы, повышающие точность и достоверность преобразования
информации в процессе работы с ней;
- методы, повышающие эффективность обмена данными;
- методы оперативного поиска и идентификации ошибок в процессе
проектирования, что позволяет устранить ошибку до окончания этой процедуры.
Наиболее часто реализующейся причиной возникновения ошибок является
сложность системы. Она определяется числом связей между
взаимодействующими компонентами. Основными концепциями
противодействия сложности ПО являются:
1) Иерархическая структура, благодаря которой система распределяется на
отдельные уровни по степени понимания. Система может анализироваться в
разрезе наиболее критических для ее функционирования факторов.
Незначительные для данного уровня параметры, относящиеся к другим
ступенькам иерархии, игнорируются. В результате появляется возможность
изучить систему, спроектировать ее и описать.
2) Независимость – чтобы минимизировать сложность всей системы,
требуется увеличить независимость отдельных элементов. Причем, чем выше
самостоятельность этих индивидуальных компонентов, тем эффективней можно
бороться со сложностью системы.
В связи с этим возникает потребность в проведении оптимальной
декомпозиции. Высокочастотная динамика системы фиксируется в разрезе
отдельных элементов. Связи между отдельными компонентами должны давать
характеристику только низкочастотным параметрам динамики системы [6].
Чтобы произвести эффективное обнаружение ошибок, необходимо
включать в ПО разнообразные типы избыточности: