51
Все ролевые кластеры имеют равные права. Допускается объединение
ролей, что довольно часто встречается в проектах, но не рекомендуется
объединять ролевой кластер разработки с другими.
Дифференцирующим фактором подхода MSF к управлению проектами
является то, что управленческие функции и деятельность работы проекта не
образуют иерархическую структуру в процессе принятия решений. MSF
выступает против жесткого, диктаторского стиля управления проектами. Этот
жесткий стиль препятствует развитию эффективной команды сверстников, что
является ключевым фактором успеха MSF.
В MSF все командные роли выполняют конкретную цель, все из которых
считаются одинаково важными. Основные решения принимаются на основе
консенсуса основной команды.
При использовании MSF, команда разрабатывает решения путем создания,
тестирования и развертывания ядра функциональности, а затем добавление
наборов функций для решения в каждом выпуске. Это известно как стратегия
версии.
На рисунке 17 показано, как функциональность развивается в процессе
создания многих версий решения. Время между версиями зависит от размера и
масштаба проекта.
52
Рисунок 17 - Функциональность развивается в процессе создания многих
версий решения
Ряд рекомендаций, способствующих принятию версионированных
релизов:
Создание несколько плана выпуска версии. Думать за пределами
текущей версии увеличивает способность команды принимать правильные
решения о том, чтобы создать сейчас и что отложить. Это позволяет команде,
чтобы наилучшим образом использовать имеющиеся ресурсы и график.
Работа через итерацию быстро. Существенное преимущество версий
является то, что она поставляет используемые решения для клиента быстро и
улучшает их постепенно с течением времени. Поддерживать управляемые рамки
так, что итерации могут быть достигнуты в пределах допустимых рамок
времени.
Обеспечение базового решения, которое является твердым и полезным,
является более эффективным, чем разработка решения, которое невозможно
использовать в течение нескольких недель или месяцев. Обеспечивая базовую
функциональность первым, позволяет разработчикам включать обратную связь,
которая будут мотивировать развивать функции в последующих итерациях.
Создание функций высокого риска в первую очередь. В ходе оценки
риска, команда идентифицирует рискованные функции. При составлении
графика написания функций для доказательства правильности концепции эти
функции в порядке тестирования находится в числе первых.
Ниже приведено описание фаз MSF.
Фаза выработки концепции. Процесс MSF начинается с фазы выработки
концепции. Предвидение может быть определено, как создание широкого
описания целей и ограничений проекта. На этом этапе команда определена и
определено то, что команда должна выполнить для клиента. Цель фазы
выработки концепции заключается в создании общей концепции проекта среди
всех ключевых заинтересованных сторон проекта. Во время фазы выработки
концепции команда управления программой определяет задачи и ожидаемые
результаты, которые учитывают потребности и цели проекта. Эта фаза
53
завершается утверждениям концепции. Этот этап означает, что клиент и команда
договариваются о цели и направлении проекта.
Фаза планирования. На этапе планирования команда определяет, что
нужно для разработки и планов, как создать решение. Команда готовит
функциональную спецификацию, создает дизайн решения, и готовит планы
работы, сметы расходов и графики для различных результатов. Этап
планирования включает анализ требований. Эти требования могут быть
классифицированы как бизнес-требования, требования пользователей,
эксплуатационные требования и требования к системе. Эти требования
используются для разработки решения, его особенностей и проверки
правильности конструкции. После сбора и анализа требований, команда создает
дизайн решения. Команда создает профили пользователей, которые определяют
различные пользователей решения и их роли и обязанности. Затем команда
создает ряд сценариев использования. Сценарий использования определяет
деятельность, выполняемую определенным типом пользователя. Таким образом,
команда должна создать сценарии использования для всех профилей
пользователей. После создания сценариев использования, команда создает
случаи использования для сценариев использования. Прецедент определяет
последовательность шагов, которые пользователь будет выполнять в сценарии
использования.
Фаза разработки. Во время фазы разработки, команда проекта создает
решение. Этот процесс включает в себя создание кода, который реализует
решения и документирование кода. В дополнение к разработке кода, команда
также развивает инфраструктуру для решения.
Процесс разработки. Команда выполняет следующие основные задачи на
этапе разработки:
Начинается цикл разработки. Проверка того, что все задачи,
выявленные в ходе выработки концепции и планировании этапов, были
завершены так, что команда может приступить к разработке решения;
Создание приложения прототипа. Проверка концепций проекта
решения в среде, которая напоминает среду, в которой решение будет в
54
конечном счете развернуто. Эта среда является как можно более близкой к
производственной среде. Эта задача будет завершена до начала разработки;
Разработка компонентов решения. Разработка основных компонентов, и
расширение этих компонентов к конкретным потребностям решения.
Построение решения. Серия ежедневных или частых сборок, которые
означают точки, когда команда разработчиков поставляет ключевые
особенности решения;
Закрытие фазы разработки. Завершение всех функций, а также поставка
кода и документации. Решение считается завершенным, и команда входит в
процесс утверждения веха.
Фаза стабилизации. Во время фазы стабилизации, команда выполняет
интеграцию, нагрузку, и бета-тестирование решения. Кроме того, команда
тестирует сценарии развертывания для решения. Команда сосредоточена на
выявлении, приоритизации вопросов с тем, чтобы решение могло быть готово к
выпуску. На этом этапе проект переходит до полностью функционирующего
проекта, как это определено в функциональной спецификации для этой версии в
состоянии удовлетворения определенных уровней качества. Кроме того,
решение готово к развертыванию в бизнесе. Результатами стабилизирующей
фазы заключаются в следующем:
Окончательный релиз;
Поддержка производительности элементов;
Результаты испытаний и инструменты тестирования;
Исходный код и исполняемые файлы;
Проектные документы.
Фаза внедрения. На этом этапе команда внедряет технологию решения и
компоненты, стабилизирует внедрения, передает проект на операцию и
поддержку, и получает окончательное одобрение проекта. После развертывания
команда проводит обзор проекта и исследование удовлетворенности
использования. Фаза внедрения достигает кульминации в развертывании полной
вехи.
Как выше было сказано, MSF основан на принципах спиральной модели
жизненного цикла, изображена на рисунке 18. Спиральная модель представляет
55
собой комбинацию модели водопада и итерационной модели. Каждый этап
спиральной модели начинается с цели проектирования и заканчивается тем, что
клиент анализирует ход выполнения. Спиральная модель была впервые
упомянута Барри Бемом в его статье 1986 года. Команда разработчиков в модели
Spiral-SDLC начинает с небольшого набора требований и проходит каждый этап
разработки для этого набора требований. Команда разработчиков программного
обеспечения добавляет функциональные возможности для дополнительных
требований в каждой возрастающей спирали, пока приложение не будет готово к
этапу производства.
Рисунок 18 – Спиральная модель жизненного цикла
Спиральные фазы:
Планирование, включает оценку стоимости, графика и ресурсов для
итерации. Это также подразумевает понимание системных требований для
непрерывной связи между системным аналитиком и клиентом;
Анализ рисков, идентификация потенциального риска производится в
то время, когда стратегия снижения риска запланирована и доработана
инженерия;
Реализация и тестирование, включает тестирование, кодирование и
внедрения программного обеспечения;
Оценка, оценка программного обеспечения заказчиком. Также
включает в себя выявление и мониторинг рисков, таких как проскальзывание
графика и перерасход средств.
56
Используют спиральную модель когда:
когда проект большой;
когда релизы должны быть частыми;
когда создание прототипа применимо;
когда важна оценка риска и затрат;
для проектов среднего и высокого риска;
когда требования неясны и сложны;
когда изменения могут потребоваться в любое время;
когда долгосрочные обязательства по проекту невозможны из-за
изменений в экономических приоритетах.
Преимущества спиральной модели:
дополнительные функции или изменения могут быть сделаны на более
позднем этапе;
оценка стоимости становится легкой, поскольку создание прототипа
выполняется небольшими фрагментами;
постоянное или повторное развитие помогает в управлении рисками;
разработка происходит быстро, а функции добавляются
систематически.
Недостатки спиральной модели:
для бесперебойной работы необходимо строго соблюдать протокол
спиральной модели;
документация больше, поскольку она имеет промежуточные фазы;
лучше всего подходит для крупных проектов и требует экспертизы по
оценке рисков;
риск несоблюдения графика или бюджета.
В качестве стратегии внедрения данного проекта будет использоваться
параллельная стратегия, изображено на рисунке 19.
57
Рисунок 19 - Параллельная стратегия внедрения
Параллельная стратегия — это стратегия для реализации системы,
когда новая система медленно берет на себя роль более старой системы, в то
время как обе системы работают одновременно. Это преобразование
происходит, поскольку технология старой системы устарела, поэтому для ее
замены требуется установить новую систему. Через некоторое время, когда
будет доказано, что система работает правильно, старая система будет
полностью удалена, и пользователи будут зависеть исключительно от новой
системы [6].
Новая система должна быть внедрена после того, как она будет
построена и протестирована, чтобы она выполняла работы в соответствии с
целями. Это включает в себя несколько начальных шагов, которые:
обеспечение правильного оборудования и программного обеспечения
были подготовлены; любое дополнительное оборудование и программное
обеспечение подготавливаются и хранятся до их внедрения. Перед настройкой
аппаратного и программного обеспечения их необходимо проверить на наличие
ошибок.
организация обучения персонала использованию новой системы; это
включает тех, кто будет управлять новой системой, и тех, кто будет
поддерживать других на начальных этапах внедрения, таких как администратор
сети и менеджеры.
58
ввод данных; данные необходимо вводить в файлы данных в новой
системе либо вручную, либо загружая их из старой системы.
Во время переключения новая система и существующая система работают
одновременно в течение согласованного периода времени. Это должно быть
достаточно долго, чтобы гарантировать, что все аспекты новой системы
подтверждены, чтобы она могла работать должным образом. Оба вводят одни и
те же данные и выполняют одинаковые процессы. Это позволит сравнить их
результаты и доказать надежность новой системы. Если новая система будет
принята, существующая система перестанет работать и будет заменена новой.
Если и старая, и новая системы компьютеризированы, входные данные могут
храниться на диске или ленте и одновременно выполняться в обеих системах.
При переходе с ручной системы на компьютеризированную систему основной
проблемой является ввод данных. Данные необходимо вводить вручную, и это
может занять много времени.
Параллельный запуск позволяет сравнивать результаты, чтобы
гарантировать, что новая система работает без каких-либо ошибок. Если ошибки
обнаружены, пользователь может обратиться к старой системе, чтобы решить
проблему и внести изменения в новую систему, таким образом, работа может
продолжаться в старой системе, пока проблемы устранены. Это также позволяет
обучать персонал и помогает им обрести уверенность в новой системе.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Стандарт MSF даёт некую гарантию минимизации рисков, так как весь
ЖЦ проекта разделён на фазы (этапы), на каждом этапе есть роли, за которыми
закреплены задачи и цели, которые должны быть достигнуты и всё же на каждом
этапе есть некоторые риски.
В фазе выработки концепции могут возникнуть следующие риски:
Недальновидное анализирование сроков проекта и его бюджета. Чтобы
ликвидировать такого рода риск нужно более глубоко прорабатывать задачи и
цели проекта, а также ставить больше контрольных точек.
Полное отсутствие командной работы может повлечь неправильно
подобранный проектный состав исполнителей. Чтобы уменьшить данный риск
59
нужно более тщательным образом подбирать специалистов в проектную группу,
тестируя не только профессиональные навыки, но и личностные качества.
На фазе планирования могут возникнуть следующие риски: не совсем
корректно или вовсе неправильно сформированная архитектура выбираемого
решения. От компетенции руководителя проекта, на котором лежит принятие
решение о выборе архитектуры разрабатываемого решения, зависит
возможность появления этого риска.
В фазе разработки возможны следующие риски:
Неправильное программирование архитектуры и сдвиг сроков в
следствие неправильной интерпретации технического задания. Ликвидация
данного риска заключается в более чётком написании технического задания,
понятного программисту.
Отсутствие должной квалификации у программиста в том языке, на
котором решено реализовывать программу. В случае, если программист не будет
укладываться в заданные временные рамки календарного плана проекта,
продеться использовать внешнего разработчика, так называемый “аутсорсинг”
или “фриланс”.
В фазе тестирования могут возникнуть следующие риски: неоконченность
тестирования. Может произойти ситуация что программный продукт будет
протестирован не до конца. Решения данного риска заключается в повторном
тестировании на следующей итерации разработки.
В фазе внедрения могут возникнуть следующие риски: неправильность
принятия решения о законченности части проекта. Это ведет за собой проблему
незаконченности решения и возможность возникновения нестыковок с другими
частями разрабатываемой ИС. Ликвидируется путем доработки при следующей
итерации.
Дисциплина управления рисками MSF выступает за превентивное
управление рисками, непрерывную оценку рисков и принятие решений на
протяжении всего жизненного цикла проекта. Команда постоянно оценивает,
контролирует и активно управляет рисками, пока они не будут либо решены или
преобразованы в проблемы, которые будут обработаны.
60
Процесс управления рисками MSF определяет шесть логических шагов,
через которые команда управляет текущими рисками, планами и выполняет
стратегией управления рисками, а также документы знаний для предприятия:
Идентификация риска позволяет людям идентифицировать риски, так
что команде становится известно о возможных проблемах;
Анализ рисков трансформирует оценку или данные о конкретных
рисках проекта, который возникает в процессе идентификации рисков, команда
может использовать это для принятия решений о приоритетности;
Планирование рисков использует информацию, полученную на основе
анализа рисков для разработки стратегий, планов и действий;
Отслеживание рисков отслеживает состояние конкретных рисков и
документы прогресса в их соответствующих планах действий;
Управление рисками является процессом выполнения планов действий
риски и связанными с ними отчеты о состоянии;
Обучение рискам формализует накопленный опыт и соответствующие
проектные документы, и инструменты, а также записывает эти знания в
многоразовой форме для использования в команде и на предприятии.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для данного комплекса задач существует несколько реализации
информационной безопасности[10].
Защита от внутренних угроз. Подразумевает разграничение прав
пользователей ИС. Подробные права пользователей описаны в таблице 16.
Таблица 16
Разграничение прав пользователей.
Группы
пользователе
й
Создание
заявки
Возможность
редактирования
своей заявки
Возможность переназначит
заявку
Группа
клиентов
Чтение/создан
ие/удаление
Нет
Нет
Группа
Чтение/удален
Есть
Есть