52
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл информационной системы — период времени,
который начинается с момента принятия решения о необходимости создания
информационной системы и заканчивается в момент ее полного изъятия из
эксплуатации.
Методология проектирования ИС включает в себя описание процесса
создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС,
отождествляя его с некоторой последовательностью стадий и исполняемых на
них процессов. Для каждой стадии выявляется состав и последовательность
производимых работ, итоговые результаты, методы и средства, нужные для
реализации работ, ответственность и роль участников и т.д. Подобное
формальное описание ЖЦ ИС дает возможность спланировать и подготовить
процесс совместной разработки и поддерживать управление этим процессом.
Жизненный цикл (ЖЦ) ИС представляется, как ряд событий,
случающихся с системой с момента ее внедрения и до окончания использования.
Модель ЖЦ отражает различные состояния системы, от момента
возникновения необходимости в данной ИС и до момента ее окончательного
вывода из эксплуатации. Модель жизненного цикла представлена некой
структурой, которая содержит процессы, действия и задачи, реализуемые в ходе
создания, работы и сопровождения ПО в течение всей жизни системы, от
выявления требований до окончания ее использования.
Сегодня известны и применимы следующие модели жизненного цикла:
• Каскадная модель включает в себя последовательную реализацию
всех этапов проекта в заранее определенном порядке. Начало следующего этапа
говорит о полном завершении работ на предыдущем этапе.
• Поэтапная модель с периодичным контролем. Создание ИС
реализовано в виде итераций с циклами обратной связи между этапами.
Межэтапные проверки позволяют учесть реально существующее взаимовлияние
итогов разработки на различных этапах; ЖЦ каждого из этапов продлевается на
весь срок разработки.
53
• Спиральная модель. На любом витке спирали выполняется
генерация очередной версии продукта, корректируются требования проекта,
выражается его качество и планируются работы уже следующего витка. Особое
внимание при этом обращается на начальные этапы разработки - анализ и
проектирование, где возможность создания тех или иных технических решений
обосновывается и проверяется благодаря построению прототипов.
Каскадный подход отлично зарекомендовал себя в процессе создания
относительно простых ИС, когда в самом начале разработки можно с большой
точностью и полнотой составить все требования к системе. Главным
недостатком такого подхода является то, что основной процесс разработки
системы не может полностью уложится в такие жесткие рамки, постоянно есть
потребность в возврате к уже завершенным этапам для уточнения или изменения
ранее принятых решений. В итоге реальный процесс разработки ИС становится
соответствующим поэтапной модели с периодичным контролем.
Все стадии создания системы предусматривают выполнение некоторого
объема работ, представляемых в виде процессов ЖЦ. Процесс выражается как
совокупность объединенных действий, изменяющих входные данные в
выходные. Описание любого процесса состоит из перечня решаемых задач,
исходных данных и итоговых результатов.
Существуют следующие стандарты проектирования информационных
систем:
ГОСТ 34.601-90;
ISO/IEC 12207:1995 (российский аналог — ГОСТ Р ИСО/МЭК 12207-99);
Custom Development Method (методика Oracle);
Rational Unified Process (RUP);
Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ,
проектирование, разработка, стабилизация, предполагает использование
объектно-ориентированного моделирования;
Экстремальное программирование (англ. Extreme Programming, XP). В
основе методологии командная работа, эффективная коммуникация между
заказчиком и исполнителем в течение всего проекта по разработке ИС.
54
Разработка ведется с использованием последовательно дорабатываемых
прототипов.
Стандарт ISO/IEC 12207 задает полный набор процессов (более 40),
охватывающий все возможные виды работ и задач, связанных с построением
программного средства, начиная с анализа предметной области и заканчивая
изготовлением конечного продукта. Данный стандарт содержит основные и
вспомогательные процессы.
В зависимости от проекта процессы, действия и задачи стандарта
выбираются, упорядочиваются и включаются в модель ЖЦ. При применении
они могут перекрывать, прерывать друг друга, выполняться итерационно или
рекурсивно. Это определяет "динамический" характер стандарта и позволяет
реализовать с его помощью произвольную модель ЖЦ .
Из данного стандарта можно выбрать только те процессы, которые более
всего подходят для реализации конкретной ИС. Обязательными являются
основные процессы, которые присутствуют во всех известных моделях ЖЦ. В
зависимости от целей и задач предметной области они могут быть пополнены
дополнительными (документирование, обеспечение качества, верификация и
валидация и т.п.) и организационными (планирование, управление и др.)
процессами этого стандарта. Разработчик принимает решение о включении в
новую создаваемую модель ЖЦ процесса обеспечения качества компонентов и
системы управления проектом или определения набора проверочных
(верификационных) процедур для обеспечения правильности продукта и
соответствия его заданным требованиям.
На предпроектной стадии необходимо провести системный анализ,
включающий анализ функционирования и выявление недостатков
существующей технологии .На основе выявленных недостатков формулируется
потребность в совершенствовании системы, создается технико-экономическое
обоснование проекта (ТЭО), формулируются технические условия и требования
к ИС. Результаты должны быть оформлены в виде ТЗ (технического задания).
Первый этап выполняется бизнес-аналитиком отдела, с привлечением
сотрудников. Входную информацию бизнес-аналитик получает из интервью с
сотрудниками, характеризующих существующие бизнес-процессы.
55
Следующий этап – проектирование ИС – включает в себя разработку в
соответствии со сформулированными требованиями состава автоматизируемых
функций (функциональная архитектура), состава обеспечивающих подсистем
(системная архитектура), оформление технического проекта ИС. Входной
информацией для проектирования является ТЗ. На этом этапе определяется
состав программных подсистем и компонентов оборудования, составляются
спецификации требований к компонентам ПО, определяется состав компонентов
ПО (в том числе повторно используемых компонентов), интерфейсы с БД,
структуры хранения данных, алгоритмы обработки информации, спецификации
интерфейсов с другими системами автоматизации, требования к тестам. Данный
этап является очень ответственным с точки зрения качества всей последующей
разработки.
На этапе реализации выполняется физическое проектирование,
программирование, наполнение баз данных, тестирование, разработка
инструкций для персонала.
Тестирование ИС. На этом этапе оценивается система в целом на
соответствие требованиям ТЗ.
Внедрение системы необходимо проводить в три этапа:
подготовка объекта к внедрению;
опытное внедрение;
сдача проекта в промышленную эксплуатацию.
На этапе подготовки объекта к внедрению планируется провести
следующие работы:
закупить и установить сервер системы и серверное ПО;
развернуть на сервере базу данных;
установить клиентское ПО на все компьютеры АРМ системы;
сконфигурировать взаимодействие АРМ системы с сервером базы
данных;
ввести учетные записи и настроить им права доступа;
заполнить справочники системы реальными данными;
обеспечить пользователей эксплуатационной документацией;
обучить персонал работе с системой.
56
В процессе внедрения системы участвуют: разработчики системы
(проектировщик, программист), системный администратор и будущие
пользователи системы. Системный администратор должен обеспечить место для
установки нового сервера; подключение к локальной сети для сервера и АРМ
пользователей системы; доступ к компьютерам, необходимым для
развертывания системы, с правами администратора. Проектировщик системы
проводит обучение пользователей, конфигурирует систему, заполняет
справочники, проверяет правильность взаимодействия всех подсистем.
Программист оперативно устраняет возникающие при развертывании системы
неполадки.
Опытная эксплуатация системы должна проводиться не менее 3 месяцев.
В случае обнаружения ошибок на этапе опытной эксплуатации, осуществляется
поиск причин и устранение ошибок, внесение коррективов в программу, в
технологию обработки данных. После устранения ошибок подписывается «Акт о
проведении опытной эксплуатации», который служит началом перехода к
третьему этапу – сдаче системы в промышленную эксплуатацию.
На этапе эксплуатации производятся следующие работы:
- периодическая актуализация справочников системы (осуществляется
ответственным за справочник лицом);
- периодическое архивирование информационной базы системы на CD-
носителях (администратор системы);
- локализация проблем и устранение причин их возникновения
(программист);
- модификация ПО (бизнес-анатилик, программист);
- подготовка предложений по совершенствованию системы (пользователи
системы);
- развитие и модернизация системы (бизнес-аналитик, программист).
В связи с небольшим объемом проектных работ, а также характером
проекта выберем каскадную модель для описания жизненного цикла. В
соответствии с этим в него будут входить следующие этапы:
Формирование требований
Проектирование
57
Реализация
Тестирование
Ввод в действие
Эксплуатация и сопровождение
В качестве стратегии внедрения интернет-магазина в ООО «ТС-Авто» был
выбран «Пилотный проект».
Пилотный проект – это первый этап внедрения, позволяющий убедиться
в применимости и эффективности предлагаемой системы до eѐ окончательного
внедрения, обучить сотрудников компании работе с системой, а также
определить и спланировать организационные и технические мероприятия на
этапе промышленного внедрения. Пилотный проект позволяет уменьшить
затраты и ускорить полномасштабное внедрение.
Данная стратегия внедрения информационной системы была выбрана,
потому что это наиболее часто используемая компаниями стратегия. Такой
подход снижает риск и наиболее надежен.
Таким образом, каскадный метод более всего подходит к конкретной
разработке, следовательно, используем стандарт ISO/IEC 12207.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Данный раздел описывает риски, которые могут возникнуть на этапах ЖЦ
разработки интернет-магазина для ООО «ТС-Авто». Риском является
возможность появления обстоятельств, обусловливающих неуверенность или
невозможность получения ожидаемых результатов от реализации поставленной
цели, нанесение материального ущерба, опасность валютных потерь и др.
Существуют следующие типы рисков:
Проектный тип рисков. В него включены риски, которые связаны с
ошибками в бюджете; в графике работ; с проблемами персонала организации;
риски различных изменений в текущем законодательстве.
Технический тип рисков. К нему относят риски, связанные с проблемами
реализации технических решений и человеческим фактором, а именно риски,
связанные с неспособностью специалистов выполнить необходимую задачу.
58
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с
финансовой поддержкой задачи учета, или, другими словами, риски сокращения
бюджета, приводящие не только к сокращению проекта и его задач, но и к его
полному провалу в случае не достижения основной цели; риск потери интереса к
задаче ведения и учета внутренних заказов оборудования со стороны конечных
пользователей, риски при оценке рынка данного вида учета. Данный тип рисков
невозможно исключить, но его можно минимизировать.
Различают две основные категории рисков – прямые и опосредованные.
На прямые риски проектная команда может каким-то образом повлиять, а
опосредованные риски команда контролировать не может в принципе.
Риски можно разделить на отдельные основные виды.
Ресурсные риски:
• Организация (делала ли организация ранее проекты такого
масштаба, есть ли формальный процесс создания ПО и т.п.);
• Инвестиции (достаточно ли денежных средств для развития
проекта, указана ли стоимость проекта или она еще находится в процессе
обсуждения, верно ли проведена оценка затрат и т.п.);
• Коллектив (хватает ли людей для выполнения проекта, имеют ли
они необходимые навыки и опыт, могли ли они участвовать в других проектах
вместе раньше и т.п.);
• Время (адекватен ли план проекта, как важна дата завершения
проекта и т.п.);
• Бизнес (что случится, если конкурент представит на рынке
аналогичный товар первым, прибыль, полученная от реализации проекта будет
выше, чем затраты на него, что случится, если основные поставщики не будут
соблюдать свои обязательства и т.п.).
Технические риски:
• Рамки действия проекта (могут ли быть отражены критерии
успешного окончания проекта, все требования конечны и отлично поняты, рамки
работы жестко фиксированы или поддерживают расширение в будущем и т.п.);
• Технологии (устойчива ли используемая технология или она только
недавно создана и т.п.);
59
• Внешние зависимости (связан ли проект ос другими параллельными
проектами, зависит ли успех проекта от сторонних поставщиков продуктов или
технологий и т.п.).
Чтобы уменьшить величину данных типов рисков необходимо иметь
достаточно компетентных и квалифицированных сотрудников, имеющих
большой опыт работы в соответствующей области и при этом
взаимозаменяемых на сотрудников, не менее соответствующих данным
характеристикам (таблица 2.1).
Таблица 2.1
Характеристики дефектов программного продукта
Этапы возникновения дефектов и ошибок
Типы первичных
дефектов и ошибок
программного средства
и документации
Формирование требований
Разработка требований к
ПО
Дефекты исходных
требований заказчика
Проектирование
Планирование работ
Дефекты,
обусловленные
реальной сложностью
проекта
Проектирование
архитектуры системы
Ошибки планирования
и системного
проектирования
программного средства
Детальное
проектирование ПО
Системные и
алгоритмические
дефекты и ошибки
проекта
Реализация
Кодирование ПО
Программные дефекты
и ошибки компонентов
и документов
программного средства
Тестирование
Тестирование ПО
Программные и
алгоритмические
ошибки программного
средства и
документации
Ввод в действие
Разработка
документации
Дефекты и ошибки
обобщающих
документов
Эксплуатация и
сопровождение
Эксплуатация ПО
Программные дефекты.
60
На этапе эксплуатации возможны риски, возникающие по причинам:
1) Злоумышленных, активных воздействий заинтересованных лиц. Для
защиты от внешних угроз необходимо применять средства обеспечения защиты
программ и данных (аутентификация пользователей, защита локальной сети при
помощи межсетевых экранов, применение антивирусных программ и пр.).
2) Случайных негативных проявлений внешней среды, дефектов системы
или ошибочных действий пользователей. Основными источниками отказовых
ситуаций могут быть некорректные исходные требования, сбои и отказы в
аппаратуре, дефекты или ошибки в программах и данных функциональных
задач, проявляющиеся при их исполнении в соответствии с назначением. При
таких воздействиях внешняя, функциональная работоспособность систем может
разрушаться не полностью, однако невозможно полноценное выполнение
заданных функций и требований к качеству информации для потребителей.
Для снижения рисков, связанных с дефектами системы, необходимо
проводить тщательное тестирование на контрольных примерах, приближенных к
действительности. Для снижения рисков, связанных с ошибочными действиями
пользователей, необходимо предусмотреть защиту от применения ошибочных
действий по удалению и порче данных.
На стадии доработки могут возникнуть следующие риски:
увеличение нагрузки на персонал;- несогласованность действий
персонала исполнителя и сотрудников предметных областей;
трудности с обучением персонала заказчика из-за нежелания
работать с новой системой;
отсутствие поддержки внедрения ИС со стороны отдельных
ключевых участников проекта;
неучастие руководителей в проекте.
Для минимизации указанных рисков необходимо принимать следующие
меры:
проведение обучения персонала работы с системой;
доведение до персонала смысла внедрения автоматизированной
системы;
61
активное вовлечение высшего руководства в проект, активное
взаимодействие с ним в ходе проекта и своевременное принятие решений,
необходимых для нормальной реализации проекта.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой системе
включает в себя следующие аспекты:
защита информации непосредственно в информационной системе
от внутренних угроз;
защита информации от внешних угроз.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 2.2.
Таблица 2.2
Разграничение прав пользователей
Группы
пользователей
Модуль
«Клиенты»
Модуль
«Отчеты»
Модуль
«Справочники»
Модуль
«Заказы»
Клиенты
нет
нет
Чтение
Полный
Администратор
Интернет-
магазина
Полный
Полный
Полный
Полный
Защита от внешних угроз осуществляется путем применения следующих
способов:
- использованием программно-аппаратных комплексов;
- разработкой и соблюдение политик безопасности;
- использованием защищенных каналов связи при передаче информации;
- использованием антивирусных средств;
- физической защитой помещений с наиболее ценной информацией.
В рассматриваемой компании для обеспечения информационной
безопасности лицом, ответственным за информационную безопасность