56
состояние; координирование работы над проектом. С помощью
интеграции можно находить компромиссы между пересекающимися
целями и альтернативными вариантами.
Управление содержанием. Сюда относятся такие процессы как
создание иерархической структуры работ по проекту, определение,
планирование, подтверждение и управление содержанием.
Управление сроками. Здесь определяется состав операций и
взаимосвязи между ними, оцениваются ресурсы и длительность
операций, разрабатывается расписание и производится управлением
им.
Управление стоимостью. Имеется в виду разработка бюджета и
контроль затрат. Для успешной реализации проекта осуществляется
стоимостная оценка, разрабатывается бюджет расходов и производится
управление стоимостью.
Управление качеством. Эта область включает все процессы, связанные
с выполнением целей. К ним относятся планирование, обеспечение и
контроль качества.
Управление человеческими ресурсами. Направление действий –
организация проектной команды и управление ей. Планируются
человеческие ресурсы, набирается и развивается коллектив,
предпринимаются меры по управлению командой.
Управление коммуникациями. Планируются коммуникации,
распространяется информация, создается отчетность по исполнению,
происходит управление участниками проекта.
Управление рисками. Процессы, относящиеся к данной области, – это
планирование управления рисками, идентификация, качественный и
количественный анализ рисков, планирование реагирования,
мониторинг и управление рисками.
Управление поставками. К этой области относится планирование
покупок и контрактов, запрос информации у поставщиков, подбор
поставщиков, администрирование и закрытие контрактов.
57
Методы PMBoK: управление освоенным объемом (EVM-метод),
выравнивание ресурсов, оценка «снизу вверх», быстрый подход, дерево
решений, анализ допущений, метод набегающей волны, анализ сети, мозговой
штурм, оценка и анализ программ (PERT-метод), метод Монте-Карло, метод
Дельфи, анализ отклонений, метод «операции в узлах» (PDM-метод), SWOT-
анализ, метод критической цепи, метод критического пути (CPM-метод),
декомпозиция, анализ ожидаемого денежного значения (EMV-метод), анализ
чувствительности, метод освоенного объема, анализ характера и последствий
отказов (FMEA-метод).
Инструменты PMBoK: система управления конфигурацией, система
управления изменениями, сетевая модель, матрица вероятности и воздействия,
диаграмма Парето, расписание контрольных событий, система
санкционирования выполненных работ, расписание контрольных событий,
диаграмма Ганта, матрица ответственности, информационная система
управления проектами, иерархическая структура рисков.
Унифицированный процесс Rational – это универсальная методология
распределения задач и сфер ответственности при разработке программного
обеспечения. Её цель – создание высококачественного программного
обеспечения, отвечающего потребностям и запросам пользователей.
Методология RUP была разработана в компании Rational Software Corporation,
которую в 2003 году купила IBM [19].
Невероятный успех предложенного в рамках RUP подхода помог многим
компаниям понять, насколько важно иметь чётко прописанный и за
документированный процесс разработки.
Методология RUP предназначена для крупных проектов разработки,
поэтому многие менеджеры уверены, что она не подойдёт для небольших задач,
не требующих большого объёма ресурсов. Но есть множество примеров, когда
небольшие проекты значительно выигрывали от внедрения RUP.
Работа над процессом– команда разработчиков RUP тесно работает с
покупателями, партнёрами и группами компаний, постоянно обновляя
методологию.
58
RUP оптимизирует командную работу– обеспечивает команде
разработчиков свободный доступ к базе знаний с инструкциями для
использования программных средств. Это помогает быстрее справиться с
критическими проблемами. Благодаря этому команда легко находит общий язык
в процессе работы над проектом.
RUP ориентирован на создание и поддержание моделей– вместо
написания большого количества бумажной документации при использовании
RUP методологии создаются модели – семантические представления
разрабатываемого командой программного обеспечения.
RUP– это инструкция использования Unified Modelling Language (UML)–
UML позволяет команде легко донести свои требования к проекту, его
архитектуру и план реализации.
RUP – это конфигурируемый процесс, он подходит как небольшим
группам разработчиков, так и крупным организациям.
Шесть основополагающих принципов RUP
В основе RUP лежит шесть главных принципов:
итеративная модель разработки– устранение рисков на каждой стадии
проекта позволяет лучше понять проблему и вносить необходимые
изменения, пока не будет найдено приемлемое решение;
управление требованиями–RUP описывает процесс организации и
отслеживания функциональных требований, документации и выбора
оптимальных решений (как в процессе разработки, так и при ведении
бизнеса);
компонентная архитектура– архитектура системы разбивается на
компоненты, которые можно использовать как в текущем, так и в
будущих проектах;
визуальное моделирование ПО – RUP методология разработки
показывает, как создать визуальную модель программного
обеспечения, чтобы понять структуру и поведение архитектуры и его
компонентов;
59
проверка качества ПО– в процессе разработки программного
обеспечения контролируется качество всех действий команды;
контроль внесённых изменений– отслеживание изменений позволяет
выстроить непрерывный процесс разработки. Создаётся благоприятная
обстановка, в рамках которой команда будет защищена от изменений в
рабочем процессе.
Жизненный цикл RUP разбит на четыре основных фазы, в каждой из
которых ведётся работа над новым поколением продукта: фазу начала проекта,
уточнение, построение и внедрение.
Фаза начала проекта. В этой фазе команда определяет структуру и
основную идею проекта. Команда решает, стоит ли вообще заниматься этим
проектом, исходя из его предполагаемой стоимости, необходимых ресурсов и
цели, которую нужно достичь.
Уточнение. Цель этой фазы – анализ требований к системе и её
архитектуры, разработка плана проекта и устранение элементов наивысшего
риска. Это самая важная фаза из всех, поскольку она знаменует переход от
низкого уровня риска к высокому. В рамках этой фазы команда решает,
переходить ли к фазе построения (разработке и написанию кода) или нет.
Построение. В этой фазе RUP методологии команда начинает разработку
всех компонентов и функций программного обеспечения, интегрирует их в
конечный продукт. Это производственный процесс, в рамках которого команда
сосредоточена на управлении ресурсами, чтобы оптимизировать расходы, время
и качество продукта.
Внедрение. Фаза, когда продукт готов и доставлен покупателям. Но после
того как пользователи получают продукт, могут возникнуть новые трудности.
Команде нужно будет исправить ошибки, отловить баги и доделать функции,
которые не были реализованы в первично установленный срок.
В конце каждой фазы существует отметка завершения этапа (Project
Milestone) – момент, когда ваша команда оценивает, достигнуты ли
поставленные цели. При этом команда принимает важные решения, влияющие
на ход следующей фазы.
60
Основой Scrum-методологии является итеративная разработка, а сама она
определяет несколько характеристик при работе с проектами [20]:
правила планирования и управления списком требований к
разрабатываемому продукту;
правила планирования итераций;
правила взаимодействия между членами проектной команды;
правила анализа и корректировки процесса разработки.
Каждая итерация проекта может быть представлена в виде цепочки:
планирование – фиксирование – реализация – анализ. Благодаря фиксированным
требованиям к одной итерации, как к фазе выполнения проекта, а также
возможности менять длину итераций, можно эффективно управлять балансом
гибкости и планируемости разработок.
В системе Agile Scrum-управление проектами состоит из трех
основополагающих частей:
роли;
практики;
документы (артефакты).
Всего в Скрам есть три роли:
владелец продукта (Product Owner);
скрам-мастер (Scrum Master);
команда разработчиков (Delivery Team);
Владельцем продукта является человек, который отвечает за его
разработку. Как правило, это либо официальный представитель, либо
доверенное лицо заказчика. Также он может представлять рынок, на котором
продукт будет реализовываться.
Владелец продукта в обязательном порядке составляет бизнес-план, где
отражается ожидаемая доходность, и план развития, включающий требования,
отсортированные по коэффициенту окупаемости вложений.
Руководствуясь имеющейся информацией, владелец продукта
разрабатывает список требований, который также рассортирован по значимости.
По сути, владельца продукта можно назвать центром принятия окончательных
61
решений для проектной команды. По данной причине это всегда только один
человек, но никак не группа людей.
Скрам-мастер – это самый важный человек во всем процессе. От него
зависит инициативность и самостоятельность всех остальных членов команды,
удовлетворенность получаемыми результатами, атмосфера в коллективе и итоги
работы вообще. Скрам-мастером должен быть один из участников команды;
необходимо, чтобы он тоже был задействован в процессе разработки.
Командой разработчиков называется группа из 5-9 инициативных и
самостоятельных человек – членов команды. Ее первостепенная задача состоит в
постановке реально достижимой, прогнозируемой, интересной и значимой цели
для каждой итерации.
Adaptive Software Development (ASD) – одна из новых методологий,
которые появились как альтернатива традиционным, ориентированным на
процесс, методам управления разработкой ПО. Во главу угла в ней ставится
человеческий фактор, результаты работы и минимизация самого процесса при
максимальном увеличении взаимодействия между людьми.
Методология была разработана исходя из объективных реалий
современного высокотехнологичного бизнеса, который отличается огромной
скоростью развития и высокой изменчивостью.
Практики ASD базируются на принципе непрерывной адаптации,
благодаря которой возникает другая философия и другой жизненный цикл
проекта, когда постоянные изменения становятся нормой.
Extreme Programming очень хорошо применима для small-medium команд
(от 2 до 10 человек), в процессе разработки которых присутствует
неопределенность или потребность в решении быстро меняющихся требований.
Длина цикла разработки составляет от 1 до 3 недель.
Методология содержит в название слово “Extreme” в силу того, что
определенные принципы и практики превозносятся до экстремального уровня,
вот одни из них:
Review кода проводится на протяжении всей жизнедеятельность
продукта.
62
Написание тестов проводится на протяжении всей жизнедеятельность
продукта; тесты пишут все, как разработчики, так и заказчики.
Redesign, refining the architecture, refactoring проводится на протяжении
всей жизнедеятельности продукта.
Разработка ведется с принятием самых простых решений, постоянное
упрощение дизайна при сохранение функциональности.
CI/CD практики, запуск тестов по несколько раз за день.
Планирование происходит с использованием очень маленьких шагов
(не более 1 дня).
Основные проблемы, которые могут быть решены с помощью XP:
Увеличение сроков разработки, приводящее к невыполнению
обязательств перед заказчиков в срок. XP использует короткие циклы
разработки, поэтому в конце каждого цикла есть возможность
корректировки задач и решений. В XP используется подход client
driven development, согласно которому самые важные для клиента
задачи выполняются в первую очередь.
Отмена проекта на поздних стадиях. Из-за коротких release циклов,
самые значимые для buiseness’а решения попадают в production раньше
всего. Если buiseness понимает, что определенный функционал им не
нужен или вообще пропала необходимость в продукте, то такой вывод
делается уже на ранних стадиях реализации.
Увеличение сложности системы. Увеличение стоимости изменений,
приводящее к отказу от продукта.
Основные неопределенности разработки, которые необходимо
контролировать:
Цена – деньги, безусловно, являются катализатором разработки, но
только в разумном количестве. Мало денег – плохо и много денег –
плохо.
Время – больше времени может увеличить качество и объем работы.
Много времени – плохо, его по сути не бывает, мало времени – тоже
плохо, получим просадку по качеству.
63
Качество – уровень качества определяется непосредственно самими
разработчиками, но только если есть все благоприятные условия.
Объем работы – меньший объем работы позволяет поставлять продукт
более высокого качества.
Основные принципы XP:
Коммуникация – чем выше коммуникация между сотрудниками, тем
четче понимание что нужно делать;
Упрощение – чем проще ваша система, тем меньше надо тратить время
на коммуникацию;
Обратная связь – чем чаще происходит обратная связь, тем более
эффективней развивается проект;
Мужество и взаимное уважение – без первых трех принципов не имеет
значения, является связующим звеном между всеми принципами,
способствует успешной работе команды в целом.
В качестве метода разработки ПО выбрана RUP, которая описана в
стандарте ISO/IEC 12207.
В качестве стратегии автоматизации предлагается использовать «узкое
место», так как под автоматизацию попадет деятельность некоторых работников
отдела МТО.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Ожидаемые риски на этапах жизненного цикла и их описание
представлены в таблице 2.1.
Выделены такие стадии по методологии RUP:
начальная стадия (Inception);
уточнение (Elaboration);
построение (Construction);
внедрение (Transition).
Следует отметить, что указанные риски не являются единственно
возможными, но, на взгляд автора, представляют наибольшую опасность для
проекта автоматизации.
64
Таблица 2.1
Ожидаемые риски на этапах жизненного цикла
Этап
Риски
Способы снижения
рисков
Начальная стадия
(Inception)
Неправильное видение и
границы проекта
Привлечение к
составлению видения и
определению границ
проекта всех
заинтересованных сторон
Ошибочное
экономическое
обоснование
Консультация со
специалистов в области
обоснования проектов
Ошибочные или
неполные требования
Привлечение к
составлению требований
всех заинтересованных
сторон
Уточнение (Elaboration)
Ошибки при
проектировании системы
Перепроверка
соответствия системы
требованиям на этапе
проектирования
Построение
(Construction)
Задержка сроков
реализации
Установка четких сроков
реализации проекта и их
контроль со стороны
руководства
Ошибка в ПО
Тестирование при
реализации ПО,
привлечение QA-
специалистов
Внедрение (Transition)
Не соответствие качества
разработанного ПО
заявленным требованиям
Возврат на стадию
«Начало»
Не охват всех функций
системы при
тестировании
Тестирование всех
функций по заранее
составленному чек-листу
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
В качестве средств обеспечения ИБ предложено ввести разграничение
прав доступа пользователей в АИС. Выделены такие группы пользователей:
администратор;
пользователь (оператор АИС).
Администратору доступны все справочники системы, в то время как
оператору системы не доступен справочник управления пользователями.
65
Также для повышения уровня безопасности при информационном обмене
между филиалами предложено настроить VPN-каналы между подразделениями
по технологии IPSec.
IPsec (IP security) – набор протоколов для безопасной передачи трафика
через IP сеть. Включает в себя три основных протокола:
AH (Authentication Header) – управление целостностью передаваемых
данных и аутентификацию
ESP (Encapsulating Security Payload) – шифрование данных
ISAKMP (Internet Security Association and Key Management Protocol) –
управление установкой соединения, взаимную аутентификации
конечным и узлами друг друга и обмен секретными ключами
Основные используемые порты и номера протоколов
Протокол UDP, port 500 (IKE, управление ключами)
Протокол UDP, port 4500 (IPSEC NAT-Traversal mode)
Протокол ESP, значение 50 (for IPSEC)
Протокол AH, значение 51 (for IPSEC)
Базовой особенностью всего взаимодействия по этому протоколу является
понятие SA (Security Association) – это набор параметров о том как стороны
будут в дальнейшем использовать те или иные свойства протоколов из состава
IPsec (рисунок 2.2).
Рис. 2.2 Шифрованный туннель по технологии IPSec