54
Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненным циклом проекта является непрерывный процесс, начинающий с
момента зарождения решения о важности его создания и заканчивающимся тогда,
когда продукт изымается из эксплуатации[24].
Традиционно для управления проектом разработки программных продуктов
в течение последних десятилетий использовался каскадный подход, который
описывает последовательность этапов от описания требований к системе до
эксплуатации и сопровождения. Поскольку такой подход не обладает достаточной
гибкостью при разработке систем, требования к которым меняются в течение ЖЦ,
необходимо обратиться к итеративным подходам, которые объединены
собирательным названием Agile, что с английского переводится как «гибкий».
Наиболее распространенными Agile-методами на сегодняшний день являются
Scrum, Kanban и экстремальное программирование.
Agile (Agile software development) – это серия подходов к разработке
программных продуктов путем непрерывной и быстрой поставки ценного рабочего
функционала самоорганизованной командой профессионалов в сотрудничестве с
заказчиком.
В 2001 году группой из 17 единомышленников был сформулирован так
называемый Agile-манифест, который ставит в основу разработки ПО четыре
ценности:
люди и взаимодействие важнее процессов и инструментов;
работающий продукт важнее исчерпывающей документации;
сотрудничество с заказчиком важнее согласования условий контракта;
готовность к изменениям важнее следования первоначальному плану.
Кроме ценностей, манифест содержит 12 принципов, которые позволяют
избежать различных проблем при разработке ПО[25].
В конце ноября 2017 года компания ScrumTrek опубликовала отчет о первом
масштабном исследовании востребованности и особенностей внедрения гибких
методологий управления в России, которое проводилось с 1 сентября по 15 октября
2017 года, данное исследование является актуальным и по сей день. Опрос показал
55
рост эффективности многих российских компаний при использовании Agile
методов. 73% опрошенных заявили, что стали «прозрачнее», и столько же лучше
справляются с меняющимися приоритетами. 63% опрошенных убеждены, что
благодаря гибким методологиям ускорили поставку продуктов на рынок.
Также в отчете были отражены основные проблемы, с которыми
столкнулись команды и организации при внедрении Agile. Главными проблемами
при внедрении Agile, как показывает статистика, являются несоответствие
ценностей гибких методологий и корпоративной культуры, а так же недостаточная
вовлеченность руководства и нехватка опыта использования методик.
На рисунке 12 приведено процентное соотношение использования Agile
методологий и практик.
Среди Agile-подходов лидирует Scrum — самый простой для понимания
подход: конкретный набор правил, по которым должна жить самоорганизующаяся
команда. В мире по состоянию на 2017 год Scrum занимает долю 58%, в России
доля Scrum в среднем составляет 48%, причем с ростом зрелости компаний в Agile
растет доля использования Scrum[26].
Scrum – фреймворк гибкой разработки ПО. Основан на эмпирическом
методе и предназначен для разработки продуктов высокой ценности в запутанной
среде. Прежде всего, Scrum – это командная работа, наиболее оптимальное число
людей в команде – 5-9 человек. При увеличении числа участников команды
возникают затруднения в коммуникациях. По закону Брукса влияние размера
группы на коммуникации можно отобразить формулой 1.
???? ????
(1)
где N
к
– число каналов коммуникации, n – количество человек в команде.
Таким образом, если в команде 5 человек, тогда количество каналов
коммуникаций будет 10, если 6 человек – 15 каналов, если 10 – уже 45, и так далее.
Судя по тенденции сложность взаимодействия ощутимо растет при добавлении
каждого нового участника, из-за этого участники группы не владеют всей
информацией о проекте в целом, что нарушает одну из важных идей Scrum – любая
деталь рабочего процесса должна быть прозрачна для всей группы.
56
Рисунок 12. Распространенность Agile методологий
В команде Scrum приняты 3 роли:
Владелец продукта (Product owner) – участник, сфокусированный на
требованиях бизнеса и рынка, занимается отбором задач и их приоритезацией.
Скрам-мастер (Scrum-master) – участник, сфокусированный на
обучении и контролировании следования методологии всех участников команды, в
том числе владельца продукта.
Скрам-команда (Scrum team) – автономная и многофункциональная
команда.
Вся деятельность в Scrum поделена на короткие, повторяющиеся итерации –
спринты. Как правило спринт длится от 1 до 4 недель и состоит из следующих
этапов:
Планирование – начало спринта, команда выбирает из списка невыполненных
задач продукта (Product backlog) те, которые собирается выполнить в этом спринте,
оценивает их, записывает на стикеры и переносит на скрам-доску (Sprint backlog),
которая разделена на несколько колонок: Новая, В работе, Тестируется, Сделано.
Ежедневные собрания – каждый участник команды за 3-5 минут
рассказывает что было сделано вчера, что нужно сделать сегодня, какие есть
57
проблемы. Таким образом, собрание проходит в среднем 20-30 минут.
Обзор спринта (Sprint review) – встреча с участием заказчика и руководства,
на которой команда рассказывает, что было выполнено за спринт и демонстрирует
готовые части продукта.
Ретроспективное собрание (Sprint retrospective) – заключительный этап
спринта, на котором команда подводит итоги и выдвигает предложения по
усовершенствованию работы.
Существует несколько методик, которые позволяют наиболее точно
спланировать задачи в следующем спринте. Наиболее распространенные из них –
это использование последовательности Фибоначчи и покера планирования. Данные
методики позволяют оценить ресурсоемкость задач не в часах, а в числах
Фибоначчи и комбинациях карт, что как показывает практика получается точнее,
чем при оценке в часах[27].
Хотя у Scrum есть много привлекательных достоинств, тем не менее следует
выделить несколько главных недостатков, с которыми может столкнуться любая
команда:
невозможность скорректировать спринт в процессе работы;
в Scrum не описан план работы с рисками;
сложность формирования самоорганизующейся команды;
ежедневные собрания на ходу рекомендуется проводить при личном
участии всей команды, что неудобно при удаленной работе;
руководителю проекта сложно контролировать процесс разработки;
сложность перехода на Scrum;
Scrum подразумевает маленькие команды по 5-9 человек, что
проблематично при больших проектах.
Kanban – это механизм, лежащий в основе производственной системы Tayota
и ее метода постоянного улучшения – Кайдзен. Слово «канбан» переводится с
японского как «рекламный щит, вывеска».
Канбан-метод предлагает комплексную адаптивную систему, которая
направлена на ускорение перехода организации к бережливому производству, для
создания которого Канбан использует 5 ключевых свойств:
визуализация рабочего потока;
58
ограничение количества незавершенных задач;
измерения и управление потоком;
формальные политики процессов;
использование моделей для оценки возможностей совершенствования.
Так же как и Scrum, Канбан хорошо работает в командах по 5-9 человек,
однако он лучше себя показывает, когда команды однородны, то есть отдельно
команда разработчиков, отдельно тестировщики, аналитики и так далее. К тому же,
как и любая гибкая методология, Канбан хорошо справляется с краткосрочным
планированием, поэтому сложно придерживаться долгосрочного плана[28].
Одной из важнейших практик в Канбан является WIP-лимитирование (WIP -
work-in-progress), которое, впрочем, используется в Scrum и других методах и
методологиях. В Канбан в отличие от Scrum делается акцент на выполнение задач,
а не спринтов.
Канбан реализуется с помощью большой доски с расчерченными столбцами,
в которых размещаются стикеры-карточки. Столбцы отображают этапы процесса
разработки программного продукта, а стикеры — рабочие задачи. WIP-лимит – это
цифры вверху каждого столбика, показывающие разрешенное количество задач
(стикеров) на данном этапе.
Надо отметить, что WIP-лимиты не являются стабильными и должны время
от времени быть рассчитаны снова с учетом изменения количества и квалификации
сотрудников, технологичности производства и формата задач. К тому же, не
обязательно полагаться на чистый математический расчет, необходимо
корректировать лимиты в зависимости от простоя, эффективности и стресса
команды[29,30].
Экстремальное программирование (XP) – методология разработки ПО,
которая во многом похожа на Scrum и объединяет в себе 12 практик, которые
делятся на 4 группы.
Практики программирования – практики, которые помогают разработчикам писать
более качественный код.
Практики интеграции – практики, которые позволяют улучшить процесс
интеграции, уменьшив время сборки и количество ошибок при слиянии изменений.
Практики планирования – практики, предназначенные для выбора, упорядочивания
59
и приоритезации задач в рамках очередной итерации, а так же выбора направления
вектора разработки и решения организационных проблем.
Командные практики – практики, помогающие командам сплотиться.
Применяя перечисленные практики команда будет легче реагировать на
изменения, таким образом становясь гибкой, а приложение при этом, вместо того
чтобы обрастать проблемным кодом, станет более качественным и
масштабируемым.
Учитывая достоинства и недостатки перечисленных методологий для
разработки текущего проекта командой было принято решение применить
методологию Scrum, с размером команды 4 человека и длительностью спринта 1
неделя. Владельцем продукта выбрали руководителя команды, отдельно был нанят
скрам-мастер. Было принято решение бэклог продукта вести в системе Первая
форма и следовать стандартной схеме спринтов. То есть, в начале недели
происходит планирование спринта и формируется бэклог спринта, ежедневно
проводится митинг команды, а в конце недели проводится ревью спринта и
ретроспектива, в качестве результата спринта представляются результаты в виде
инкремента продукта, результат может быть представлен либо на словах с
демонстрацией функционала, либо в презентации.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
На каждом этапе жизненного цикла ИС есть различные риски. Они приводят
как к серьезным неустойкам во в процессе разработки системы, так и в ее
функциональных возможностях.
Далее будут представлены риски в зависимости от процессов ЖЦ, а также
возможные методы их предотвращения.
Процесс подготовки проекта.
1) Риск персонала
Риски:
набор необученного персонала к выполнению проекта;
набор в группу разработчиков «случайных» сотрудников;
неимение выработанной стратегии автоматизации;
несогласованность в общих целях и задачах проекта;
отсутствие мотивационных поощрений сотрудникам;
60
нежелание персонала участвовать в проекте;
хаотичный план ведения работ.
Методики предотвращения:
постоянное взаимодействие с руководством в процессе всего проекта;
привлечение к проекту ведущих специалистов и консультантов;
четкая формулировка целей и задач;
выработка определённой стратегии автоматизации компании;
неизменный состав рабочей группы во время подготовки проекта.
2) Риск ведения проекта.
Риски:
ошибочная установка границ и масштаба проекта;
выделение ошибочных функций системы;
подбор неверных технологий и методологий решений задач;
несоблюдение приведенных заказчиком требований.
Методики предотвращения:
поддержка стабильности границ проекта;
точное планирование выполняемых работ;
включение в проект необходимых ресурсов;
согласованное и утвержденное проектное решение;
высокий порог принятия изменений.
3) Риск неверного планирования.
Риски:
малоэффективный план организации разработки системы;
несоблюдение сроков реализации работ по этапам.
Методики предотвращения:
в начальных стадиях проекта проведение учета, организация
командной работы, выделение ролей и стимулирование;
описание и сохранение всех проведенных работ и открытый доступ к
ним.
Процесс разработки.
1) Риск персонала.
61
Риски:
увольнение сотрудников, которые отвечают за проведение разработки;
плохой система коммуникации;
ошибочное представление задачи проектирования;
набор разработчиком без опыта работы с подобными системами.
Методики предотвращения:
грамотный набор сотрудников, участвующих в проекте;
реализация четкой системы взаимодействия между сотрудниками.
2) Технические риски.
Риски:
остановка разработки из-за ошибок в применяемом ПО;
бедность документации ИС.
Методики предотвращения:
регулярное резервное копирование данных;
отслеживание полноты сведений во всех документах.
Процесс внедрения.
1) Риск персонала
Риски:
разрозненность деятельности разработчиков и экспертов;
отсутствие желания у сотрудников использовать новую систему;
безучастность руководства.
Методики предотвращения:
обучение пользователей со стороны заказчика работе с системой;
подготовка плана внедрения системы;
обоснование важности и нужности автоматизации персоналу;
активное участие руководства проекта.
2) Технические риски
Риски:
утрата информации при внедрении системы.
Методики предотвращения:
наем квалифицированных сотрудников с соответствующим опытом.
62
При грамотном подходе к предотвращению рисков, а также благодаря
использованию гибкой методологии разработки ущерб проекту будет
минимальный.
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
При эксплуатации разработанной ИС для обеспечения её безопасности от
внешних и внутренних угроз используется комплекс мер по защите информации. В
этот комплекс прежде всего входят средства, позволяющие ограничить доступ
пользователей к различным модулям системы.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа на каждый программный модуль. Характеристика
политики для компании ООО «Агентство сейлконтент» приведена в таблице 8.
Таблица 8
Разграничение прав пользователей
Программный
модуль
Менеджеры
Клиенты
Администраторы
Авторизация
Чтение
Чтение
Полный
Управление
задачами
Чтение / Запись
Чтение
Полный
Ведение
трудозатрат
Чтение / Запись
Чтение / Запись
Полный
Электронная
подпись
Чтение / Запись
Чтение / Запись
Полный
Список
контактов
Чтение
Чтение
Полный
Чат
Чтение / Запись
Чтение / Запись
Полный
Лента новостей
Чтение / Запись
Чтение
Полный
Диагностика
приложения
Без доступа
Без доступа
Полный
Кроме указанных групп пользователей, система позволяет создавать и
редактировать права на любой программный модуль
В целях защиты информационной системы проводятся следующие
63
мероприятия:
обеспечение сетевой безопасности;
обеспечение локальной безопасности;
обеспечение физической безопасности.
Для обеспечения сетевой безопасности используются следующие средства:
фильтрация трафика;
ограничение доступа в интернет и во внутреннюю сеть;
антивирусная фильтрация;
система обнаружения атак;
контроль содержания трафика;
протоколирование и регулярный мониторинг доступа.
Локальная безопасность обеспечивается осуществлением следующих
мероприятий:
антивирусный контроль;
аппаратная защита от несанкционированного доступа;
криптографическая защита данных;
защита персональным файрволом;
резервирование данных;
протоколирование доступа.
Для обеспечения физической информации файрвол, веб-сервер, сервера IDS
и контроля за трафиком и все сервера данных находится в отдельном помещении,
доступ в которое разрешен только администраторам, у которых есть ключ или
магнитная карта к этой комнате (комната закрыта). Помещение оборудовано
принудительной вентиляцией и пожарной защитой (полуавтоматической). Вход в
офис компании должен осуществляться только по магнитным картам.
2.2 Управление проектом автоматизации
2.2.1 Описание системы принятия управленческих решений
Принятая в команде методология Scrum – фреймворк гибкой разработки ПО.
Основан на эмпирическом методе и предназначен для разработки продуктов
высокой ценности в запутанной среде. Прежде всего, Scrum – это командная
работа, где наиболее оптимальное число людей в команде – 5-9 человек.