60
При объектно-ориентрованном проектировании ИС определяются
абстракции и механизмы, обеспечивающие правильное поведение
информационной модели. Объектная декомпозиция требует большой
интеллектуальной работы и лучший способ ее ведения - последовательный
интерактивный процесс. Перечисленные модели в совокупности дают полное
описание ИС независимо от того, является ли она существующей или вновь
разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от
необходимой полноты описания системы.
Результаты анализа специальной литературы по теоретическим основам
проектирования ИС, показали, что наиболее эффективной моделью жизненного
цикла для создания проекта в рамках данного исследования следует считать
каскадную модель, т.к. многие требования заказчика изначально известны. Это
позволит снизить ошибки в процессах проектирования и разработки системы, и
придать гибкость в управлении процессами жизненного цикла.
Модель жизненного цикла - структура, содержащая процессы, действия и
задачи, которые осуществляются в ходе разработки, функционирования и
сопровождения программного продукта в течение всей жизни системы, от
определения требований до завершения ее использования. Существует несколько
моделей и стандартов, в той или иной степени регламентирующих жизненный
цикл, большинство из них относятся к заказному ПО (автоматизированным
системам АС, и др.) и кроме непосредственно ЖЦ регламентируют также и
процессы разработки:[15]
ГОСТ 34.601-90 распространяется на автоматизированные системы и
устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится
описание содержания работ на каждом этапе. Стадии и этапы работы,
закрепленные в стандарте, в большей степени соответствуют каскадной модели
жизненного цикла[1].
ISO/IEC 12207:1995 стандарт на процессы и организацию жизненного
цикла. Распространяется на все виды заказного ПО. Стандарт не содержит
описания фаз, стадий этапов.[2]
Custom Development Method (и, методика Oracle) по разработке прикладных
информационных систем под заказ - конкретный материал, детализированный до
61
уровня заготовок проектных документов, рассчитанных на использование в
проектах с применением Oracle. Степень адаптивности CDM ограничивается
тремя моделями ЖЦ: «классическая» (предусмотрены все работы/задачи и этапы),
«быстрая разработка» (Fast Track), «облегченный подход», рекомендуемый в
случае малых проектов и возможности быстро прототипировать приложения.
Rational Unified Process (RUP) предлагает итеративную модель разработки,
включающую четыре фазы: начало, исследование, построение и внедрение.
Каждая фаза может быть разбита на этапы (итерации), в результате которых
выпускается версия для внутреннего или внешнего использования. Прохождение
через четыре основные фазы называется циклом разработки, каждый цикл
завершается генерацией версии системы. Если после этого работа над проектом
не прекращается, то полученный продукт продолжает развиваться и снова минует
те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей, а
не бумажных документов, поэтому этот процесс привязан к использованию
конкретных средств моделирования (UML), а также конкретной технологии
проектирования и разработки (объектно-ориентированный анализ, object-oriented
analysis, OOA, объектно-ориентированное программирование, object-oriented
programming, OOP) [2].
Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре
фазы: анализ, проектирование, разработка, стабилизация, является итерационной,
предполагает использование объектно-ориентированного моделирования. MSF в
сравнении с RUP в большей степени ориентирована на разработку бизнес-
приложений [11].
Extreme Programming (XP). Экстремальное программирование является
самым новым среди рассматриваемых методологий, сформировалось в 1996 году.
В основе методологии командная работа, эффективная коммуникация между
заказчиком и исполнителем в течение всего проекта по разработке ИС, а
разработка ведется с использованием последовательно дорабатываемых
прототипов.
Основными критериями для выбора стандарта ЖЦ будут:
актуальность и современность используемых методик контроля
разработки;
62
разработка в итерационном режиме с возможностью контролировать
риски;
выполнение самого проекта на неких контрольных точках,
отсутствие дополнительных требований по моделированию процесса разработки
и внедрения.
Стандарт COBIT нам не подходит, потому что основной целью его
использования является проведения аудита и стратегического планирования ИС и
IT инфраструктуры в целом.
Стандарт XP тоже не подходит, так как он не содержит полноценных
этапов ЖЦ, таких как выработка концепции, планирование, разработка,
стабилизация, внедрение.
Следовательно, перед выбором стоит Rup и MSF. Оба стандарта являются
молодыми и поддерживающими все новые технологии продуктивной разработки
и контроля их выполнения
По ней можно судить, что Rational Unified Process является хорошо
сбалансированным решением для средних по размерам коллективов
разработчиков, работающих с применением продуктов и технологий компании
Rational. Сопровождение разработки системы и самой системы регламентируется
методологией RUP, однако данная технология достаточно сильно ориентирована
на внутрифирменные инструментальные средства.
Extreme Programming хорошо подходит для проектных групп малого
размера и для небольших систем с часто изменяемыми требованиями. Основная
проблема XP - сопровождение. В случае текучки кадров в коллективе
разработчиков значительная часть проектной информации может быть утеряна из-
за практически отсутствующей документации.
Microsoft Solutions Framework является наиболее сбалансированной
технологией, ориентированной на проектные группы малых и средних размеров.
MSF не накладывает никаких ограничений на используемый инструментарий и
содержит рекомендации весьма общего характера. Однако эти рекомендации
могут быть использованы для построения конкретного процесса,
соответствующего потребностям.
Проект является небольшим, кроме того основным преимуществом MSF
63
является итерационная модель одновременно с уточняющими вехами (аналог
каскадной модели). Таким образом, реализация MSF попыталась объединить
каскадную и итерационную модель разработки и внедрения ПО.
По описанным выше преимуществам был выбран стандарт MSF как
наиболее гибкий и удобный для реализации проекта. Одним из преимуществ
этого стандарта является возможность управлять одновременно и проектом
разработкой приложения и внедрением инфраструктуры.
Итак, в идеологии MSF существует 5 стадий жизненного цикла ИС,
которые в понятии MSF называют фазами.
Первый из них это фаза выработки концепции. Цель данной фазы в
создании и сплочении проектной группы на основе выработки единого видения.
Проектная группа должна четко представить себе, что она хочет сделать для
заказчика и сформулировать свою цель. Заказчиком выступает Главное
управление.
В идеологии MSF команда проекта делится на 6 участников, каждый из
которых имеет свою роль в проекте и наделен обязанностями, а также имеет свою
зону ответственности. Эти роли MSF назвала кластерами, за каждым из которых
может быть закреплен не один человек, итак вот они: Управление продуктом,
Управление программой, Разработка, Удовлетворение потребителя, Тестирование,
Управление выпуском. В каждой фазе, для каждого ответственного лица,
закрепленного за кластером, закрепляются определенные задачи.
Управление продуктом регулирует концептуальный и логический дизайн,
функциональная спецификация, сводный план и сводный календарный график
проекта, бюджет.
Кластер Управление программой формирует цели дизайна, концепцию
решения, структуру проекта.
Кластер Разработка отвечает за оценку технологий, логический и
физический дизайн, план и календарный график разработки, смета разработки.
Кластер Удовлетворения потребителя рассматривает сценарии/примеры
использования, пользовательские требования, требования локализации и
общедоступности (accessibility); пользовательская документация/план
обучения/график тестирования удобства эксплуатации; обучение.
64
Кластер Тестирования формирует оценку дизайна; требования
тестирования; план и календарный график тестирования.
Кластер управление выпуском выполняет функции Оценка дизайна;
эксплуатационные требования; план и календарный график пилотного и
окончательного внедрения.
В рамках создания и внедрения проекта, силами сотрудников Главного
управления, было произведено объединение задач кластеров и сформирован из
них список ответственных лиц:
1) программист, на которого возложены следующие кластеры:
• управление программой;
• разработка;
• удовлетворение пользователей.
2) менеджер проекта, на которого возложены следующие кластеры:
• управление продуктом;
• тестирование;
• управление выпуском.
Выходной информацией и результатами данной фазы является подбор
кандидатов и назначение наиболее подходящих из них к требуемым задачам на
исполнение двух ролей, то есть формирование команды, несмотря на то, что она
состоит всего из двух человек. В проекте на данном этапе будут определены
состав и роли участников.
Следующим этапом идет фаза планирования. Основной ее целью является
составление планов проекта. Она включает в себя подготовку проектной группой
функциональной спецификации, разработку дизайнов, подготовку рабочих
планов, оценку проектных затрат и сроков разработки различных составляющих
проекта.
Процесс проектирования - это систематический способ продвижения от
абстрактных концепций к конкретным техническим деталям.
Следующим этапом следует фаза разработки. На фазе разработки проектная
группа фокусируется на создании компонент решения (включая как
документацию, так и программный код). Однако некоторая часть этой работы
может продолжаться также на фазе стабилизации, если такая необходимость
65
выявлена в процессе тестирования. Данная фаза также включает в себя разработку
инфраструктуры.
Результатами фазы разработки являются: исходный и исполнимый код
приложений, скрипты установки и конфигурирования, Окончательное описание
функционала разрабатываемого решения, материалы поддержки решения,
сценарии тестов. В данном случае от программиста на данном этапе требуется
предоставить программу клиент для работы инженеров ИТ и написание полной
документации к ней. От руководителя проекта требуется создать
работоспособную среду, описанную в предыдущем этапе.
Следующим этапом ЖЦ идет фаза стабилизации. Во время фазы
стабилизации производится тестирование разработанного решения. При этом
внимание фокусируется на его эксплуатации в реалистичной модели
производственной среды. Проектная группа занимается устранением ошибок, а
также подготовкой решения к выпуску. Результатами фазы стабилизации является
окончательный продукт.
Следующим этапом будет фаза внедрения. Во время этой фазы проектная
группа внедряет технологии и компоненты решения, стабилизирует внедренное
решение, передает работу персоналу поддержки и сопровождения и получает со
стороны заказчика окончательное одобрение результатов проекта. По завершению
внедрения проектная группа производит анализ выполненной работы и
удовлетворенности заказчика.
Результаты фазы внедрения включают в себя: информационные системы
эксплуатации и поддержки, процедуры и процессы, базы знаний, отчеты, журналы
протоколов, массивы данных и программный код, разработанные во время
проекта.
На этом этапе руководитель окончательно внедряет систему в
эксплуатацию, распечатывает им инструкцию по работе с ней или проводит
обучение.
Внедрение является общим понятием и для него существуют разные
стратегии реализации, которые напрямую зависят от срока исполнения и качества
ИС, получаемой на выходе. Существуют четыре основные стратегии внедрения
системы:
66
1. Параллельная стратегия - когда одновременно работают старая
(ручная) и новая система, и их выходные документы сравниваются. Если они
согласуются длительное время, осуществляется переход на новую систему.
2. «Скачок» - это резкий переход от старой системы к новой без
дополнительных проверок и с полным отказом от старой системы.
3. «Пилотный проект» это наиболее часто используемая стратегия.
«Пилотный проект» - это тактика «скачка», но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок
деятельности. Такой подход снижает риск и наиболее надежен.
4. «Узкое место» - это малая часть производственного процесса. При
использовании подхода «узкое место» план внедрения выполняется только для
«узкого места» и для людей, работающих в нем.
В данном проекте будет применена стратегия «Пилотный проект». Будет
проводиться полный переход к автоматизированной системе обработки заявок.
Областью применения внедрения будет отдел технической поддержки, состоящий
из 5 специалистов. Такой подход не затронет работу всей службы, а лишь
автоматизирует рутинную часть. Надежность данного внедрения обусловлена
четким соответствием порядка регистрации и обработки заявки регламенту
горячей линии.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
Сам стандарт MSF дает некую гарантию минимизации рисков, так как весь
ЖЦ проекта разделен на этапы, на каждом этапе есть роли, за которыми
закреплены цели, которые должны быть достигнуты и все же на каждой фазе есть
некоторые риски:
В фазе выработки концепции могут возникнуть следующие риски:
недальновидный анализ сроков проекта и его бюджета. Для ликвидации такого
рода риска нужно более детально прорабатывать задачи и цели проекта, ставить
больше контрольных точек.
Неправильно подобранный проектный состав исполнителей может повлечь
67
полное отсутствие командной работы. Данный риск уменьшается более
тщательным подбором специалистов в проектную группу тестированием не
только профессиональных навыков, но и личностных качеств.
На фазе планирования могут возникнуть следующие риски: неправильно
или не совсем корректно сформированная архитектура выбираемого решения.
Возможность появления этого риска зависит от компетенции руководителя
проекта, на котором лежит принятие решение о выборе архитектуры
разрабатываемого решения
В фазе разработки возможны следующие риски: неправильная
интерпретация технического задания и как следствие неправильная
программирование архитектуры и сдвиг сроков. Минимизацией данного риска
служит более четкое написание технического задания, понятного программисту
В фазе тестирования могут возникнуть следующие риски: риски
неоконченного тестирования. Может произойти ситуация что программный
продукт будет протестирован не до конца. Решается путем повторного
тестирования на следующей итерации разработки.
В фазе внедрения могут возникнуть следующие риски: риски
неправильного принятия решения о законченности части проекта. Возникновение
данных рисков ведет за собой проблему незаконченности решения и возможность
возникновения нестыковок с другими частями разрабатываемой ИС. Устраняется
путем доработки при следующей итерации.
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Защита от внутренних угроз ИС «Техническая поддержка» реализована
путем определения и разграничения групп пользователей и назначения им
соответствующих права доступа к папкам и модулям системы.
Подробные права пользователей описаны в таблице 5.
68
Таблица 5
Разграничение прав пользователей ИС «Техническая поддержка»
Группы
пользователей
Создание
заявки
Возможность
редактирования
своей заявки
Возможность
переназначит
заявку
Работа с
базой
знаний
Группа
администратор
ов системы
Чтение/соз
дание/удал
ение
Есть
Есть
Чтение/соз
дание/удале
ние
Группа
специалистов
техподдержки
Чтение
Есть
Есть
Чтение/соз
дание
Группа
пользователей
Чтение/соз
дание/удал
ение
Есть
Нет
Чтение
Защита от внешних угроз реализуется следующими положениями. Узлы
сети, доступные из Интернет, помещены в специально выделенный сегмент сети -
демилитаризованную зону (DMZ). DMZ организована с помощью межсетевых
экранов, отделяющих ее от Интернет и от внутренней сети. При этом правила
фильтрации межсетевых экранов выглядят следующим образом:
из внутренней сети можно инициировать соединения в DMZ и в
WAN (Wide Area Network);
из DMZ можно инициировать соединения в WAN;
из WAN можно инициировать соединения в DMZ;
инициация соединений из WAN и DMZ ко внутренней сети
запрещена.
Как следствие повышенная защищенность сети от взломов отдельных
сервисов. Даже если один из серверов будет взломан, нарушитель не сможет
получить доступ к ресурсам, находящимся во внутренней сети.
Все системы в Главном управлении не имеют установленных сторонних
средств удаленного администрирования, доступ организован через гипервизор
WmVare на нужный сервер, в том числе и сервер ИС «Техническая поддержка».
В Главном управлении используются все возможные методы защиты
информации, так как нет уникального одного метода, который смог бы
обеспечить полную информационную безопасность, а сочетание всех методов
69
позволяет реализовать максимальную информационную безопасность.
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и ее описание
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области.
Кроме того, она объясняет, на основе каких входных документов и какой
нормативно-справочной информации происходит выполнение функций по
обработке данных и формирование конкретных выходных документов.
В качестве информационной модели будем использовать схему данных
(ГОСТ 19.701-90). Схемы данных отображают путь данных при решении задач и
определяют этапы обработки, а также различные применяемые носители данных.
Схема данных состоит из следующих элементов:
1) символов данных (символы данных могут также указывать вид
носителя данных);
2) символов процесса, который следует выполнить над данными
(символы процесса могут также указывать функции, выполняемые
вычислительной машиной);
3) символов линий, указывающих потоки данных между процессами и
(или) носителями данных;
4) специальных символов, используемых для облегчения написания и
чтения схемы.
Представим общую информационную модель ИС «Техническая
поддержка» (рис. 16).