47
II. Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла - структура, содержащая процессы, действия
и задачи, которые осуществляются в ходе разработки, функционирования и
сопровождения программного продукта в течение всей жизни системы, от
определения требований до завершения ее использования. Существует
несколько моделей и стандартов, в той или иной степени регламентирующих
жизненный цикл, большинство из них относятся к заказному ПО
(автоматизированным системам АС, и др.) и кроме непосредственно ЖЦ
регламентируют также и процессы разработки:
ГОСТ 34.601-90 распространяется на автоматизированные системы и
устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится
описание содержания работ на каждом этапе. Стадии и этапы работы,
закрепленные в стандарте, в большей степени соответствуют каскадной модели
жизненного цикла.
ISO/IEC 12207:1995 стандарт на процессы и организацию жизненного
цикла. Распространяется на все виды заказного ПО. Стандарт не содержит
описания фаз, стадий этапов.
Custom Development Method (и, методика Oracle) по разработке
прикладных информационных систем под заказ - конкретный материал,
детализированный до уровня заготовок проектных документов, рассчитанных
на использование в проектах с применением Oracle. Степень адаптивности
CDM ограничивается тремя моделями ЖЦ: "классическая" (предусмотрены все
работы/задачи и этапы), "быстрая разработка" (Fast Track), "облегченный
48
подход", рекомендуемый в случае малых проектов и возможности быстро
прототипировать приложения.
Rational Unified Process (RUP) предлагает модель разработки,
включающую четыре фазы: начало, исследование, построение и внедрение.
Каждая фаза может быть разбита на этапы (итерации), в результате которых
выпускается версия для внутреннего или внешнего использования.
Прохождение через четыре основные фазы называется циклом разработки,
каждый цикл завершается генерацией версии системы. Если после этого работа
над проектом не прекращается, то полученный продукт продолжает
развиваться и снова минует те же фазы. Суть работы в рамках RUP - это
создание и сопровождение моделей, а не бумажных документов, поэтому этот
процесс привязан к использованию конкретных средств моделирования (UML),
а так же конкретной технологии проектирования и разработки (объектно-
ориентированный анализ, object-oriented analysis, OOA, объектно-
ориентированное программирование, object-oriented programming, OOP).
Microsoft Solution Framework (MSF) сходна с RUP, так же включает
четыре фазы: анализ, проектирование, разработка, стабилизация, является
итерационной, предполагает использование объектно-ориентированного
моделирования. MSF в сравнении с RUP в большей степени ориентирована на
разработку бизнес-приложений.
Extreme Programming (XP). Экстремальное программирование является
самым новым среди рассматриваемых методологий, сформировалось в 1996
году. В основе методологии командная работа, эффективная коммуникация
между заказчиком и исполнителем в течение всего проекта по разработке ИС, а
разработка ведется с использованием последовательно дорабатываемых
прототипов.
49
В таблице 17 приведено краткое сравнение:
Таблица 17
Технология
Команда
(чел.)
Стандарты
Удобство
модификации
Допустимые
технологии
Microsoft Solutions
Framework
3 – 20
Адаптируемые
Удобно (MSF и
MOF)
Любые
Rational Unified
Process
10 – 40
Rational
Удобно (RUP)
UML и Rational
Extreme
Programming (XP)
2 – 10
Отсутствуют
Зависимость от
участников
коллектива
Любые
Наш проект является большим. Он включает в себя более 100 человек, а
этапы разработки и тестирования проводятся в среде разработки HTML. Исходя
из приведенной выше информации, для нас подойдет MSF.
По описанным выше преимуществам, мною был выбран стандарт MSF
как наиболее гибкий и удобный для реализации проекта. Одним из
преимуществ этого стандарта является возможность управлять одновременно и
проектом разработкой приложения и внедрением инфраструктуры. В идеологии
MSF существует 5 стадий жизненного цикла ИС, которые в понятии MSF
называют фазами. Первый из них это Фаза выработки концепции. Кроме того
основным преимуществом MSF является итерационная модель одновременно с
уточняющими вехами (аналог каскадной модели). Таким образом, реализация
MSF попыталась объединить каскадную и итерационную модель разработки и
внедрения ПО.
Команда создания проекта будет поделена на 4 участников, каждый из
которых имеет свою роль в проекте, наделён обязанностями и имеет свою зону
ответственности. Эти роли MSF назвала кластерами, за каждым из которых
может быть закреплён не один человек, итак вот они: разработка ПО,
управление программой, тестирование, диспетчер. В каждой фазе для каждого
ответственного лица, закреплённого за кластером, закрепляются определённые
задачи:
50
Разработка ПО – непосредственно сам разработчик проекта М3. В его
обязанности входит написание кода, прорисовка графического интерфейса,
установка и поддержка основного агента на выделенный сервер банка.
Управление программой – арбитр и технический администратор. В его
обязанности входит работа с создаваемыми заявками.
Тестирование – контролер. В его обязанности входит контроль за
работоспособностью ПО M3 ATM Monitoring System.
Диспетчеризация – диспетчер/координатор. В его обязанности входит
первичный анализ неисправности, регистрация ремонтной заявки, мониторинг
состояния устройства.
51
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Сам стандарт Microsoft Solutions Framework, даёт небольшую гарантию
минимизации рисков, так как весь жизненный цикл проекта разделён на этапы.
На каждом этапе жизненного цикла есть роли, за которыми закреплены цели,
которые должны быть достигнуты. Но всё же на каждой фазе есть некоторые
риски. В фазе выработки концепции могут возникнуть риски:
Недальновидный анализ сроков проекта и его бюджета. Для
минимизации такого рода риска, нужно более точно и детально
прорабатывать задачи и цели проекта. Необходимо ставить больше
контрольных точек.
Неправильно подобранный проектный состав исполнителей может
повлечь частичное или полное отсутствие командной работы. Данный
риск уменьшается с более тщательным подбором специалистов в
проектную группу, а также тестированием не только профессиональных
навыков, но и личностных качеств.
На фазе планирования могут возникнуть следующие риски:
Неправильно или не совсем корректно сформированная архитектура
выбираемого решения. Возможность появления данного риска зависит от
компетенции руководителя проекта, на котором лежит принятие решения
о выборе архитектуры разрабатываемого решения.
В фазе разработки возможны следующие риски:
Неправильная интерпретация технического задания, и как следствие,
неправильное программирование архитектуры и сдвиг сроков.
52
Минимизацией данного риска служит более чёткое написание
технического задания для программиста.
Риск отсутствия должной квалификации у программиста на том языке, на
котором решено реализовывать программу-клиент, которая будет
распределять заявки между инженерами. В случае, если программист не
будет укладываться в заданные временные рамки, придеться
использовать внешнего разработчика.
В фазе тестирования могут возникнуть следующие риски:
Неоконченное тестирование. Может произойти ситуация что
программный продукт будет протестирован не до конца. Данный риск
решается путем повторного тестирования на следующей итерации
разработки.
В фазе внедрения могут возникнуть следующие риски:
Риски неправильного принятия решения о законченности части проекта.
Возникновение данного риска ведет за собой проблему незаконченности
решения и возможность возникновения нестыковок с другими частями
разрабатываемой ИС. Устраняется путем доработки при следующей
итерации.
53
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для данного комплекса задач существует несколько реализаций
информационной безопасности.
1. Защита от внутренних угроз. Подразумевает разграничение прав ИС
HP OpenView Service Desk
2. Защита от внешних угроз. Все серверные системы в компании ООО
"ЛАН АТМсервис" не имеют предустановленное стороннее средство
для удаленного администрирования. Доступ организован через
Remote Desktop Protocol. На нужный сервер вход осуществляется
только по доменной авторизации в соответствии с уровнем доступа.
3. В компании ООО «ЛАН АТМсервис» используются все возможные
современные методы и средства защиты информации.
54
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
На рисунке 4 приведена информационная модель дипломного проекта в
виде схемы. Данная информационная модель может включать в себя несколько
источников. Основной базой является система Octopus. В ней находятся все
ремонтные заявки, которые поступили на ремонт УС, информация об
устройствах, подрядчиках, контрагентах и договоры с банками. Доступ к
системе Octopus есть и у регионов.
Процесс создания заявки реализуется через:
Электронное письмо (по почте)
Ручное создание заявки через систему Octopus
Телефонное обращение (по телефону)
Рисунок 4
55
Разработанная в данном дипломном проекте система М3 является
дополнением для системы Octopus. Система М3 разрабатывается для банка
РСХБ (Россельхозбанк) по всей России. Первичная программа-мониторинг
будет установлена на каждом банкомате и терминале банка РСХБ для
мониторинга состояния подключенных устройств. Программа-мониторинг
будет подключена к удаленному серверу М3, который будет автоматически
создавать заявки в системе М3 исходя из статуса устройств. Например, если у
клиента была изъята карта, М3 автоматически создаст в системе M3 с
неисправностью: «картридер». На самом устройстве самообслуживания
появится ошибка картридер, но она не будет мешать полноценной работе
устройства, так как изъятая карта сбрасывается в специальное хранилище для
карт.
После автоматического создания заявки в системе М3, Диспетчер обязан
принять решение согласно регламенту:
Уточнить, необходима ли разгрузка/загрузка перед началом
ремонтных работ.
Запросить информацию у подрядчика и решить вопрос без выезда
инженера (решить вопрос силами ТА).
Зарегистрировать заявку на ремонт в Octopus для выезда
инженера.
Услуга по управлению уровнем доступности Сети оказывается
специалистами ООО «ЛАН АТМсервис». Технологическая платформа оказания
Услуги – продукт М3.
Для управления уровнем доступности Сети Поставщик Услуги
развертывает на ИТ-площадке Заказчика Услуги платформу. М3 и размещает
консоли мониторинга и инцидент-менеджмента в своих структурных
подразделениях и Филиалах. Оперативный контроль за деятельностью
Поставщика Услуги осуществляют сотрудники Заказчика Услуги, у которых
также установлены консоли мониторинга и инцидент-менеджмента. Платформа
56
М3 принимает информацию о техническом состоянии УС Сети, на основании
которой регистрируются инциденты. Данные о возникших инцидентах
обрабатываются Диспетчерами Поставщика Услуги. При возникновении
инцидента Диспетчер Поставщика Услуги проводит анализ данных об
инциденте. При необходимости проводит консультации со специалистами 2-й
линии поддержки Поставщика Услуги и принимает решение о выборе Плана
восстановления УС после инцидента. На основании Плана Диспетчер
формирует запросы на выполнение шагов по восстановлению
работоспособности УС. Запросы передаются между участниками процесса
средствами платформы М3, среди которых:
внутренние каналы М3;
электронная почта.
Получив запрос, участник процесса инициирует необходимые для его
выполнения действия: связывается с непосредственным подрядчиком и
предоставляет данные о ходе выполнения действия стороне, инициировавшей
запрос.