57
гибкие процессы способствуют устойчивому развитию благодаря их
постоянному ритму и техническому совершенству, что повышает
производительность;
ретроспективные моменты внутри команды имеют важное значение,
позволяя ей вносить необходимые коррективы и повышать
эффективность.
По сути, гибкая разработка следует за инкрементной моделью, которая
развивает сотрудничество внутри команды и непрерывное планирование, а
также постоянное развитие и обучение. Гибкие методологии должны учитывать
цикл разработки программного обеспечения − планирование, выполнение и
окончательную поставку, следовательно, позволяя разрабатывать программное
обеспечение поэтапно − это облегчает выявление и устранение ошибок.
Основным преимуществом использования методологий Agile является не
только быстрая доставка программного обеспечения клиенту, но и постоянная
поставка новых характеристик ИС для клиента, поскольку разработка ИС носит
постепенный характер.
Существует множество методологий, которые следуют этому гибкому
подходу. Основные Agile методологии: Scrum, Kanban, Extreme Programming,
Lean Development, Crystal.
Рассмотрим более детально каждую из них.
Методология Scrum
Scrum, несомненно, является наиболее используемой из многих структур
методологии Agile. Scrum характеризуется циклами или этапами разработки,
известными как спринты, и увеличением времени разработки программного
продукта. Обычно он используется в управлении проектами разработки
программных продуктов, но также может использоваться в контексте бизнеса.
Каждый день проводятся небольшие 15-минутные собрания, ежедневные
разборки, которые играют роль синхронизации действий и поиска наилучшего
способа планирования рабочего дня.
Преимущества и недостатки методологии «Scrum» представлены в
таблице 2.1.
58
Таблица 2.1
Преимущества и недостатки методологии «Scrum»
Преимущества:
Недостатки:
В командах много мотивации, потому что
программисты хотят уложиться в сроки
каждого спринта;
Прозрачность позволяет проекту следовать
всем членам команды или даже организации;
Акцент на качестве является постоянным в
методе схватки, что приводит к меньшему
количеству ошибок.
Динамика этого метода позволяет
разработчикам реорганизовать приоритеты,
гарантируя, что спринты, которые еще не
были завершены, получают больше внимания
Сегментация проекта и поиск гибкости
разработки иногда могут привести к
тому, что команда потеряет контроль
над проектом в целом,
сосредоточившись только на одной
части;
Роль каждого разработчика может быть
нечетко определена, что приводит к
некоторой путанице среди членов
команды.
Методология Kanban
Слово Kanban имеет японское происхождение, и его значение связано с
понятием времени «точно в срок». На практике метод Kanban существует в виде
платы или таблицы (доска Kanban), разделенных на столбцы, которые
показывают каждый поток производства программного обеспечения. По мере
развития разработки информация, содержащаяся в таблице, меняется, и когда в
игру вступает новое задание, создается новая «карта».
Метод Kanban требует коммуникации и прозрачности, чтобы члены
команды могли точно знать, на каком этапе находится разработка, и в любой
момент увидеть состояние проекта. Преимущества и недостатки методологии
«Kanban» представлены в таблице 2.2.
Таблица 2.2
Преимущества и недостатки методологии «Kanban»
Преимущества:
Недостатки:
Возможность просмотра всех задач одного
проекта (например, «Завершено», «В процессе»
или «В процессе тестирования»);
Можно ограничить количество запущенных
задач (то есть объем работы, принимая во
внимание ее разрешение или выполнимость);
Сосредоточьтесь на продолжительности цикла −
сколько времени занимает задача, чтобы
перейти от отставания к финальной стадии;
Позволяет непрерывные поставки.
Члены команды могут неверно
истолковать информацию,
отображаемую на доске Kanban,
особенно когда она считается
устаревшей;
Поскольку в Kanban нет временных
рамок, вы можете столкнуться с
проблемами, связанными со
временем, такими как задержки,
связанные с каждым этапом.
59
Экстремальное программирование (Extreme Programming − XP)
Это типичная среда Agile Development, разработанная Кентом Беком,
которая может быть адаптирована для компаний-разработчиков различных
размеров. Это методология, которая подчеркивает такие ценности, как общение,
простота, обратная связь, смелость и уважение, и ставит во главу угла
удовлетворенность клиентов. Эта методология предлагает разработчикам
доверие, мотивируя их принимать изменения требований заказчика, даже если
они поступают на более поздней стадии цикла разработки.
Работа в команде чрезвычайно важна в XP, так как, когда есть проблема,
она решается всей командой менеджеров, разработчиков или клиентов. Все они
являются важными частями одной и той же головоломки, что создает
благоприятную среду для высокой производительности и эффективности в
команде. В экстремальном программировании программное обеспечение
тестируется с первого дня, собирая отзывы для улучшения разработки.
Преимущества и недостатки методологии «XP» представлены в таблице
2.3.
Таблица 2.3
Преимущества и недостатки методологии «XP»
Преимущества:
Недостатки:
Простота написанного кода работает как
преимущество, так как позволяет улучшить
его в любой момент времени;
Весь процесс и весь цикл разработки XP
видны, поэтому они создают цели для
разработчиков и показывают результаты
относительно быстрым способом;
Разработка программного обеспечения
оказывается более гибкой, чем в других
методологиях, именно из-за постоянного
тестирования;
ХР также способствует повышению таланта
команд и их удержанию.
Чрезвычайное внимание к коду может
привести к тому, что дизайну будет уделено
меньше внимания, что потребует
дополнительного внимания;
Эта структура может работать не лучшим
образом, если все члены команды не
работают в одной географической зоне;
В проектах XP реестр возможных ошибок
не всегда поддерживается, и отсутствие
контроля может привести к аналогичным
ошибкам в будущем.
Бережливая разработка (Lean Development − LD)
Lean Development − это методология, которая исходит непосредственно от
Lean Manufacturing, созданной Toyota и применяемой для разработки
программного обеспечения. Этот метод предлагает концептуальную основу и
60
следует ценностям, принципам и передовым методам разработки, которые могут
быть применены к подходу гибкой разработки.
Существует семь основных принципов: удаление вещей, которые не
имеют значения (все, что не приносит эффективной пользы проекту клиента,
удаляется); Развитие качества (создание качества в разработке требует
дисциплины и контроля количества созданных остатков); Создание знаний
(команда мотивирована задокументировать всю инфраструктуру, чтобы
впоследствии сохранить это значение); Различные обязательства (этот пункт
побуждает команду не уделять слишком много внимания планированию и
предвидению идей, не имея предварительного и полного понимания требований
бизнеса); Быстрая доставка (доставить стоимость клиенту как можно скорее);
Уважение к команде (общение и управление конфликтами − это два важных
момента); Оптимизация в целом (последовательность разработки должна быть
достаточно усовершенствована, чтобы иметь возможность удалять ошибки в
коде, чтобы создать поток истинного значения).
Преимущества и недостатки методологии «LD» представлены в таблице
2.4.
Таблица 2.4
Преимущества и недостатки методологии «LD»
Преимущества:
Недостатки:
Позволяет команде удалять лишнюю
активность, тем самым экономя время и
деньги;
Уменьшает время, необходимое для
предоставления функциональных
возможностей, поскольку оно
подготавливает команду разработчиков к
процессу принятия решений, что повышает
общую мотивацию;
Легко масштабируемая методология и легко
адаптируемая к проектам любого масштаба.
Это очень зависит от способностей команды
разработчиков и от следующих принципов
Lean, что означает, что будет необходимо
иметь преданных своему делу и талантливых
разработчиков;
Проще потерять фокус, поскольку различные
задачи делятся на несколько элементов;
Требуются некоторые документы, в
частности о характеристиках бизнеса,
который является предметом работы. В
противном случае существует риск того, что
разработка может быть выполнена
неправильно и может привести к ошибкам.
Методология Crystal
Это семейство гибких методологий, включающее такие варианты, как
Crystal Clear (до 8 человек), Crystal Yellow (до 10-20 человек), Crystal Orange (до
61
20-50 человек) ) и Crystal Red (для больших команд от 50 до 1000 человек).
Crystal фокусируется на таких принципах, как люди, взаимодействие,
сообщество, навыки, талант и общение, стремясь обеспечить наилучший процесс
разработки программного обеспечения. Ядром этого процесса разработки
является взаимодействие и симбиоз, которые должны существовать между
людьми, распределенными по проектам и процессам, чтобы повысить
эффективность разработки.
По словам его основателя Алистера Кокберна, «Crystal − это семейство
методологий разработки программного обеспечения, которое работает с силой,
вложенной людьми, и является чрезвычайно легким и эластичным». По сути,
Кокберн считает, что талант и способ взаимодействия членов команды приносят
пользу всему проекту.
Преимущества и недостатки методологии «Crystal» представлены в
таблице 2.5.
Таблица 2.5
Преимущества и недостатки методологии «Crystal»
Преимущества:
Недостатки:
Это обеспечивает частые поставки, чтобы
определить возможные проблемы на
каждом этапе;
Всегда есть место для улучшения
характеристик, что занимает некоторое
время от разработки программного
обеспечения и позволяет обсудить, как
усовершенствовать процессы;
Позволяет для более тесного общения и
способствует взаимодействию и обмену
знаниями между членами команды;
Требуется техническая среда с
автоматизированными тестами,
управлением конфигурацией и частой
интеграцией.
Тот факт, что в семействе методологий есть
варианты, означает, что принципы могут
варьироваться в зависимости от размера
команды и размера проекта, что приводит к
тому, что проекты могут быть не такими
простыми;
Это может не работать в командах,
разбросанных по разным областям, из-за
постоянной необходимости общаться и
размышлять;
Планирование и разработка не зависит от
требований.
В Xpand IT разработка программного обеспечения персонализирована,
поэтапно ориентируясь на результаты и удовлетворенность клиентов. Все
развитие регулируется Agile принципами. Поэтому, чтобы соблюдать цикл
разработки, достигать желаемых результатов, прогнозировать возможные
ошибки, максимизировать производительность и безопасно развиваться,
62
сохраняя при этом мотивацию членов команды, мы создали нашу собственную
методологию: XPAgile (сочетание сред Agile − Scrum и Extreme Programming −
что обеспечивает наилучшие результаты в установленные сроки).
Стандартом жизненного цикла ИС выбран ISO/IEC 12207:2008, в качестве
модели ЖЦ ИС выбрана SCRUM, которая обеспечивакт высокий уровень
соответствия процессу управления проектами по представленному выше
стандарту ЖЦ.
Стратегией внедрения выбрана «узкое место», поскольку во внедрении
участвуют сотрудники одного отдела.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Этапами и мероприятиями Scrum являются:
спринт − результатом спринта является инкремент готового продукта
(build), который можно передать заказчику для установки на
продуктивный информационный ландшафт.
ежедневные встречи (daily) − это ежедневные встречи для
синхронизации работ членов команды в единую согласованную
командную работу.
груминг − продолжительная встреча, на которой Scrum-команда вместе
с владельцем продукта рассматривает существующий бэклог продукта,
а также требования, которые планируется включить в ближайший
спринт, добавляет необходимые технические и бизнес-задачи, чтобы
зафиксировать направления проектирования или решить необходимые
архитектурные вопросы развития продукта и его инкремента.
демо – встреча, когда все члены команды должны продемонстрировать
то, что было ими выполнено.
ретроспектива − мероприятие, направленное на систематическое
инспектирование и адаптацию Scrum к условиям функционирования
конкретной команды.
Обозначим риски, которые могут возникать.
63
Риски, связанные с требованиями к продукту
Если требования не определены должным образом с самого начала, то при
создании функций есть большая вероятность, что новые дополнения, которые не
были изначально согласованы, попадут в ПО.
Как это предотвратить:
подготовить четко детализированный объем проекта;
определить спецификации требований и критерии приемки;
попросить заинтересованные стороны подписать это соглашение;
определить, какие требования должны быть задействованы на этапе,
над которым идет работа, в сравнении с будущими этапами или
версиями;
разработка и внедрение процесса контроля изменений, о котором
заинтересованные стороны знают и с которым согласны;
мониторинг прогресса проекта с учетом объема.
Примеры проблем и пути их решения:
Отсутствие деталей в описании задач. Нужно убедиться, что все детали
присутствуют и понятны для группы, чтобы они точно знали, что они
создают. Лучший способ записать их в виде пользовательских
комментариев или технических требований.
Изменения требований владельцем продукта. Владелец продукта
меняет свое мнение или добавляет новые функции по мере
продвижения команды − пока владелец продукта отвечает за
обеспечение выполнения требований проекта, его также необходимо
информировать, когда он запрашивает работу, отличающуюся от
оригинала.
Меняются приоритеты или направления. Меняются приоритеты или
направления − иногда приоритеты заинтересованных сторон или
направление проекта изменяются, и поэтому функции, которые
изначально не планировались, имеют приоритет над остальными.
Когда это происходит, важно убедиться, что заинтересованные
стороны понимают, какое влияние это окажет на масштаб проекта и
даже на сроки и бюджет.
64
Риски, связанные с графиком разработки
Другим важным аспектом проекта является график, который установлен
для него. Эта временная шкала может быть определена на основе количества
доступных ресурсов для выполнения работы и количества усилий, которые
потребуются для выполнения требований проекта.
Как и при планировании любого графика, все может пойти не так, как
планировалось, что может привести к задержке выполнения проекта, в
результате чего он будет завершен с опозданием или раньше, чем
планировалось.
Планируя график, следует учитывать такие моменты:
фактор возможности праздников − персонал или клиент могут взять
дополнительные выходные дни;
нужно планировать неожиданные больничные дни − убедиться, что на
каждом ресурсе есть резервный исполнитель;
в случае если член команды уходит или его увольняют, то надо
поставить в очередь другой ресурс, чтобы заполнить его место;
нужно разрабатывать планы для членов команды, которые могут изо
всех сил пытаться выполнить работу из-за сложности, отсутствия
мотивации или других факторов;
фактор других возможных задержек, таких как чрезвычайные
ситуации, которые могут помешать производству даже на один день;
надо принять во внимание тот факт, что в утверждениях будут
задержки – надо добавить запасы по срокам для клиентов;
есть очень редкие случаи, когда свойства ПО утверждаются на первой
итерации, поэтому надо дать запас времени, чтобы пройти несколько
раундов правок;
надо выделить время для тестирования и QA;
надо оставить запас времени для неизвестных и форс-мажорных
обстоятельств.
Примеры конкретных проблем в Agile, которые влияют на график
проекта:
65
agile-команда может переоценить или недооценить свои задачи − со
временем команда должна быть более уверенной в том, чтобы
поставить свои оценки на место;
цель спринта не достигнута или изменяется в середине спринта −
команда должна четко понимать цель спринта и выполнять задачи,
которые они будут выполнять в спринте.
Влияние данных рисков можно снизить, если:
всегда иметь планы предотвращения, смягчения последствий и
действий;
нужно всегда общаться с клиентом в тот момент, когда идет
запаздывание с результатами;
очень сжатые сроки почти не дают права на ошибку, поэтому надо
ответственно подходить к планированию таких проектов.
Риски, связанные с бюджетом проекта
Если временные и/или финансовые затраты на проект поддаются оценке,
то можно составить бюджет проекта на основе трудозатрат и финансовых
ресурсах. Качество и стоимость также являются другими факторами, которые
могут учитываться при оценке бюджета. Создание бюджета и отслеживание
затрат на протяжении всего проекта очень важно.
В тех случаях, когда проект может превышать бюджет, это может
указывать на то, что произошла ошибка планирования масштабов проекта, или
плохое планирование этапов, плохое развитие или другие факторы, которые
привели к увеличению стоимости по сравнению с первоначальной оценкой.
Чрезмерное ограничение бюджета может также указывать на то, что в
проекте не хватает этапов и работ, которые должны были быть выполнены, или
клиент был перегружен.
Существует баланс, который необходимо соблюдать при работе с
бюджетом проекта. В то же время нужен резерв для непредвиденных проблем,
которые могут возникнуть уже на этапе работы над проектом.
При планировании бюджета следует учитывать следующие риски и
способы их предотвращения:
66
недостаточная оценка или чрезмерная оценка − если нет уверенности
на 100% в своих цифрах, нужно попросить мнение экспертов по
конкретным вопросам, которые знают более подробную информацию о
позициях, в которых планировщик проекта не уверен.
отсутствие резерва ресурсов − если указать точную стоимость всех
этапов разработки, то, скорее всего, то можно столкнуться с их
нехваткой, что, в свою очередь, приведет к дополнительной потере
денег.
контроль объемов и сроков − должны быть планы действий, например,
как обрабатывать дополнительные расходы на контроль изменений,
задержки и другие обстоятельства, когда что-то меняется в ходе
выполнения проекта, и это влияет на бюджет.
Как только разработчики смогут определить риски в своем проекте и
составить планы для них, то они смогут лучше справляться с этими рисками,
чтобы обеспечить более высокую вероятность успеха проекта.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Ранее было сказано, что на предприятии информационная безопасность
обеспечивается встроенными средствами ОС (брандмауэрами), а также
функциями межсетевого экрана.
В качестве дополнительной меры, повышающей уровень ИБ, предлагается
использовать сканер сетевой безопасности XSpider версии 7.8.25.
Сетевой сканер безопасности XSpider версии 7.8.25, разработанный
компанией Positive Technologies, успешно прошел очередной инспекционный
контроль в системе сертификации средств защиты информации ФСТЭК России
и получил соответствующий сертификат, действительный до 24 октября 2020
года.
В ходе инспекционного контроля подтверждены возможности сканера по
выявлению включенных в банк данных угроз безопасности ФСТЭК России
уязвимостей ПО для поддерживаемых платформ и объектов и его соответствие
требованиям по 4 уровню контроля отсутствия недекларированных