47
осуществляют определение и распределение рисков. На данном этапе происходит
организация и проведение торгов, заключение контрактов с основными
исполнителями, организуется выполнение основных проектных и опытно-
конструкторских работ по проекту и осуществляется представление проектной
разработки заказчику.
В выпускном квалификационном проекте по автоматизации учёта заявок на
этом этапе определяют основные критерии будущей системы, и формируют
требования к ней. Осуществляется проектирование и разработка основных модулей
информационной системы, создается интерфейс системы и происходит пробное
заполнение данными.
Фаза реализации – это фаза, в процессе которой происходит введение в
работу информационной системы. На этом этапе производиться введение в
действие средств коммуникации и связи между участниками проекта, введение в
действие системы стимулирования участников проекта, осуществление детального
проектирования, и определение технических спецификаций, осуществление
оперативного планирования работ.
Применительно к задаче ВКР на этом этапе проводится обучение персонала,
внедрение в технологию работы разработанной информационной системы.
Заполнение системы реальными данными и проверка ее соответствия
поставленным задачам.
Завершающая фаза или окончание проекта – это фаза, в процессе которой
достигаются поставленные цели проекта и подводятся итоги. К основным работам
этой фазы относятся - эксплуатационные испытания готового продукта, подготовка
кадров для эксплуатации системы, подготовка документации, сдача объекта
заказчику и ввод в эксплуатацию.
В данном выпускном квалификационном проекте на этой фазе происходит
обучение специалиста работе с информационной системой, составление
инструкции пользователя по основным критериям работы, пробная печать отчетов.
Жизненный цикл программного обеспечения.
Важным понятием в методологии по проектированию ИС является понятие
жизненных циклов ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это
48
непрерывный процесс, который начинаются с момента принятия решений о
создании информационных систем и заканчивающийся в момент их полного
изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, служит
международный стандарт ISO/TEC 12207 (ISO -International Organization of
Standardization Международная организация по стандартизации, EEC - International
Electrotechnical Commission - Международная комиссия по электротехнике). По
нему определяется структура ЖЦ, содержащая процессы, действия и задачи,
выполняемые во время разработки ПО.
Структура ЖЦ ПО по стандарту ISO/TEC 12207 состоит из трех групп
процессов:
основные процессы ЖЦ ПО (приобретение, поставка, разработка,
эксплуатация, сопровождение);
вспомогательные процессы, обеспечивающие выполнение основных
процессов (документирование, управление конфигурацией, обеспечение
качества, верификация, аттестация, оценка, аудит, решение проблем);
организационные процессы (управление проектами, создание
инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ,
обучение).
Разработка содержит все работы для создания ПО и его компонентов
(анализ, проектирование и программирование) по заданным требованиям, включая
оформление проектной и эксплуатационной документации, подготовку
материалов, необходимых для проверки работоспособности и качества
программных продуктов, материалов, необходимых для организации обучения
персонала, и т.д.
Эксплуатация содержит работы для внедрения компонентов ПО, а также для
конфигурирования базы данных и рабочих мест пользователей, обеспечения
эксплуатационной документацией, проведения обучения персонала и т.д., ну и
непосредственно эксплуатация, в том числе локализация проблем и устранение
причин их возникновения, модификация ПО в рамках созданного регламента,
49
подготовка предложений для совершенствования, развития и модернизации
системы.
Модели жизненного цикла ПО.
Стандарт ISO/TEC 12207 не предлагает определенную модель ЖЦ и методы
для разработки ПО. Его регламенты база для всех моделей ЖЦ, для методологии и
технологии разработки. Стандарт ISO/TEC 12207 представляет структуру
процессов ЖЦ ПО, но не рассматривает в деталях, их реализацию или выполнение
действий и задач.
Модель ЖЦ – это структура, определяющая последовательность выполнения
и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ
зависит от назначения ИС и требований условий, в которых система будет
разрабатываться и функционировать. Наибольшее распространение имеют две
основные модели ЖЦ: каскадная модель (1970 - 1985 гг.) и спиральная модель
(1986 - 1990 гг.).
В однородных ИС приложения были единым целым. Для разработки такого
приложения применялся каскадный способ. Каскадный способ - это деление всей
разработки на этапы, при этом переход с одного этапа на другой происходит
только после завершения всех работ на предыдущем этапе.
Каждый этап заканчивается созданием комплекта документации, с которой
разработка может быть продолжена другой командой разработчиков.
Преимущества такого метода:
на всех этапах создается набор проектной документации, отвечающий
критериям полноты и согласованности;
выполняемые в логичной последовательности этапы дают возможность
планирования сроков завершения всех работ и соответствующих затрат.
Каскадный метод подходит для построения ИС, в которых с начала
разработки можно точно и полно сформировать все требования, и предоставить
разработчикам свободу реализовать их технически как можно грамотней. Сюда
входят сложные расчетные системы, системы реального времени и др.
Для избегания этих проблем была предложена спиральная модель ЖЦ, в
которой упор делается на начальные этапы ЖЦ: анализ и проектирование. На этих
50
этапах реализация всех технических решений проверяется путем создания
прототипов. Все витки спирали соответствует разработке своего фрагмента или
версии ПО, происходит уточнение целей и характеристик проекта, определяется
качество и планируется работа следующего витка спирали. Так, происходит
углубление и последовательная конкретизация деталей проекта, в результате
выбирается наилучший вариант, который доводится до реализации.
Главная задача разработки - как можно быстрее представить заказчикам
системы работоспособный продукт, таким образом, активизируя процесс
уточнения и дополнения требований.
Для создаваемой ИС подходит спиральная модель жизненного цикла. Эта
модель ЖЦ является более эффективной по сравнению с каскадной, что позволяет
получить в итоге более качественный продукт при небольшом количестве
задействованного персонала и довольно коротком графике проектирования.
Спиральная модель позволяет совершенствовать информационную систему путем
создания новых версий.
На стадии внедрения проводятся подготовка и постепенное освоение
разработанной проектной документации ИС заказчиком. В процессе выполнения
работ на этой стадии осуществляется выявление частных и системных недоработок
в предлагаемом для внедрения проектном решении.
Существует четыре способа внедрения новой системы:
1. Параллельная стратегия.
2. «Скачок».
3. Пилотный проект.
4. «Узкое место».
Специфика работы АНО «АВТОМОТОПРО» предполагает невозможность
приостановки работы предприятия из-за внедрения новой ИС, поскольку это может
повлечь за собой потерю клиентской аудитории, ошибки в выполнении
документооборота и, как следствие, упущенную прибыль. Также риск влияния
неудачного внедрения на эффективность работы предприятия должен быть
минимальным или отсутствовать.
51
Метод «скачка» предусматривает полный отказ от работающей системы и
моментальный и безусловный переход на новую ИС. Это может стимулировать
пользователей системы к быстрому ее освоению, однако возникает большая
вероятность остановки технологического процесса получения и обработки
информации при условии, если в новой системе возникнет сбой.
Метод «узкого места» является принципиально неприемлемым для
разрабатываемого проекта, так как предполагает внедрение ИС в наиболее
критический участок работы предприятия, с тем, чтобы в дальнейшем перейти к
полномасштабному внедрению на всем предприятии. Решаемая задача изначально
решается на одном участке, переход на уровень всего предприятия в целом не
запланирован.
Таким образом, наиболее приемлемыми представляются два варианта
технологии внедрения ИС – параллельная стратегия и стратегия пилотного
проекта. Их сравнительная характеристика приведена в таблице 6.
Таблица № 6
Сравнительная характеристика стратегий внедрения ИС
Позиция
Параллельная стратегия
Пилотный проект
Случай
применения
Старую работающую систему
необходимо заменить новой
Тактика «скачка», но применяемая
к ограниченному числу функций.
Область
применения
Не имеет значения
Малый участок деятельности
Риск срыва
работы
предприятия
Риск минимальный
Стратегия нацелена на снижение
риска при внедрении
Дублирование
операций
Есть
Нет
При использовании параллельной стратегии внедрения проекта
одновременно работают старая и новая системы,
их результаты и выходные документы сравниваются. Если они согласуются
длительное время, можно переходить на новую систему. При замене одной
части программного обеспечения другой дублирование операций при внедрении
системы не будет иметь принципиального значения для выбора способа внедрения.
52
Гораздо более значимым критерием при этом необходимо считать снижение
риска, сведение его практически к нулю. В этой связи наиболее приемлемой
представляется стратегия параллельного внедрения.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
При создании любого проекта постоянно появляются ситуации, связанные с
неопределенностью, неполнотой или неточностью информации об условиях
проектирования проекта и связанные с ними затраты и результаты. Участники
проекта заинтересованы в уменьшении возможности срыва проекта из-за таких
неопределенных ситуаций. Для снижения потери от возможных просчетов и
избегания срыва проекта, методологии управления проектами содержат
специальные процедуры, которые помогают учесть факторы неопределенности и
риска на этапах проекта.
Предугадывая виды и значения рисков, возможно на них влиять, тем самым
уменьшая их плохое влияние на эффективность проекта. Так, появляются реальные
возможности управлять ими. Факторы риска и неопределенности которые
подвергаются учету в расчетах эффективности, когда при разных возможных
условиях реализации затраты и результаты по проекту различны.
Этап подготовки проекта.
1. Риск сотрудников.
Риски:
Привлечение неопытных сотрудников к выполнению проекта;
Вхождение в состав разработчиков «случайных» сотрудников, а не основных
участников автоматизируемых бизнес процессов;
Отсутствие общей стратегии автоматизации;
Отсутствие общей цели и задачи проекта;
Отсутствие мотивирования сотрудников;
Негативное отношение сотрудников к проекту;
Непродуманный план ведения работ.
Способы устранения рисков:
Полное взаимодействие с руководством в ходе проекта и своевременное
принятие решений;
53
Участие в проекте лучших специалистов и профессиональных
консультантов;
Грамотно сформулированные цели проекта;
Проработка основной стратегии автоматизации организации;
Постоянный состав рабочей группы в течение всего проекта.
2. Риски ведения проекта.
Риски:
Неверное определение границ и масштаба проекта;
Проектирование функций системы с ошибками;
Выбор неверных технологий и методов решений задач;
Не соблюдение требований заказчика.
Способы предотвращения:
Обеспечение четких границ проекта, которые определяются на начальном
этапе и остаются неизменными вплоть до окончания проекта;
Качественное планирование выполнения работ;
Обеспечение проекта нужными ресурсами;
Утверждение и согласование проектных решений;
Установка высокого порога принятия изменений.
3. Риски неверного планирования.
Риски:
Непродуманный организационный план внедрения системы;
Срывы сроков выполнения работ на каждом этапе.
Способы предотвращения:
На ранних стадиях проекта проведение проверок, организация командной
работы, распределение ролей и стимулирование сотрудников;
Документирование всех работ и обеспечение доступа к данным по работам
всем участникам проекта.
Этап разработки.
4. Риски персонала.
Риски:
54
Увольнение основных сотрудников, ответственных за проведение
разработки;
Недопонимание между разработчиками проекта из-за отсутствия
налаженной системы коммуникации;
Неверное представление задачи проектирования;
Выбор программистов без опыта работы с подобными системами.
Способы предотвращения:
Грамотный подбор сотрудников, участвующих в проекте;
Налаженная система взаимосвязи между сотрудниками, постоянное
документирование изменений системы.
5. Технические риски.
Риски:
Задержка разработки из-за ошибок в использованном программном
обеспечении;
Пользовательская документация описывает не все функции системы.
Способы предотвращения:
Применение только проверенного лицензионного ПО, проведение
регулярного резервного копирования данных;
Проверка документации на состав сведений.
Этап внедрения.
6. Риски персонала.
Риски:
Несогласованность в действиях разработчика и специалистов предметной
области;
Нежелание сотрудников учится работать с новой системой и связанные с
этим трудности их обучения;
Неучастие руководства организации в проекте.
Способы предотвращения:
Грамотное обучения сотрудников заказчика работе с системой;
Составление четкого плана внедрения системы;
Обоснование необходимости автоматизации всему персоналу организации;
55
Привлечение руководства к проекту и активное взаимодействие с ним в ходе
всего проекта.
7. Технические риски.
Риски:
Потеря важных данных при внедрение системы.
Способы предотвращения:
Привлечение квалифицированных сотрудников, имеющих большой опыт в
подобных проектах.
Этап эксплуатации и сопровождения.
8.Технические риски.
Риски:
Ошибки в системе, приводящие к невозможности ее использования;
Неграмотная эксплуатация оборудования;
Несоответствие функционального набора системы из-за внутренних
изменениях в организации.
Способы предотвращения:
Поэтапное тестирование и модификации во время разработки системы;
Документирование всех технических условий и их согласование.
Применительно к внедряемой системе учета документации и отчетности
следует отметить такие риски: нарушение конфиденциальности информации;
нарушение целостности информации; нарушение доступности информации.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
В соответствии общим тенденциям, основными источниками по угрозе
безопасности данных в компании являются[5]:
угроза по каналам утечки вещественных данных (незаконного доступа к
физическим объектам защиты);
угроза по утечке данных по техническим каналам;
угроза НСД к информации, обрабатываемой в локальной сети.
Угрозы по утечке данных по техническим каналам могут включать в себя:
56
угроза по утечке акустических (речевых) данных;
угроза по утечке видимых данных;
угроза по утечке данных по каналу ПЭМИН.
Наиболее значительными угрозами безопасности данных для организации
(способы причинения ущерба субъектам информационных отношений) есть:
нарушения конфиденциальности (разглашения, утечки) сведений,
включающих служебные или коммерческие тайны, а также персональных
данных;
нарушения функционирования компонентов информационной системы,
блокировка данных, не соблюдение технологического процесса, срывы по
своевременному решению задач;
нарушения целостности (искажения, подмены, уничтожения)
информационных, программных и других ресурсов, а также фальсификации
(подделки) документов.
Наиболее распространены следующие аппаратные средства защиты данных:
специализированные регистры с целью хранения реквизитов защиты:
пароля, идентифицирующего кода, грифа или уровня секретности;
устройств по измерению индивидуальных характеристик человека (голоса,
отпечатков) для его дальнейшей идентификации;
схем по прерыванию передачи данных в линии связи с целью периодической
проверки адреса выдачи информации;
устройств для шифрования данных (криптографические методы).
Первоначально криптография применяла методы шифрования данных -
обратимого преобразования открытого (исходного) текста на основании
секретного алгоритма и/или ключа в шифрованный текст (шифротекст).
В целях защиты периметров информационных систем создаются[6]:
система охранной и пожарной сигнализации;
система цифрового видео наблюдения;
система контроля и управления доступом (СКУД).
Защита данных от утечки по техническим каналам — это комплекс
организационных, организационно-технических и технических мероприятий,