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