31
частей проекта. Чем сильнее взаимосвязаны отдельные части проекта, тем чаще
и тщательнее должна выполняться синхронизация, тем сильнее зависимы друг
от друга команды разработчиков. Поэтому преимущества параллельного
ведения работ просто теряются;
• Сложность управления проектом при использовании каскадной
модели обусловлена в основном строгой последовательностью этапов
разработки и присутствием сложных зависимостей между различными
элементами проекта. Поэтапность разработки проекта ведет к тому, что одним
группам разработчиков приходится ожидать результатов работы других.
Поэтому для согласования условий работы и состава документов, подлежащих
передаче, требуется административное вмешательство.
Спиральная разработка
Для решения вышеуказанных проблем была предложена спиральная
модель ЖЦ приведенная на рисунке 4, в которой основное внимание уделяется
начальным этапам ЖЦ: анализ и проектирование. На этих этапах
осуществимость технических решений проверяется путем создания прототипов.
Каждый виток спирали соответствует созданию фрагмента или версии ПО, на
нем уточняются цели и характеристики проекта, определяется его качество и
планируются работы следующего витка спирали. Таким образом, углубляются
и последовательно конкретизируются детали проекта и в результате выбирается
разумный вариант, который доводится до реализации.
Рисунок 4. Спиральная модель жизненного цикла программного
обеспечения
32
Достоинства спиральной модели:
Развитие итераций отражает объективно существующий спиральный
цикл создания системы. Главная задача -как можно быстрее показать
пользователям системы работоспособный продукт, тем самым активизируя
процесс уточнения и дополнения требований.
Такая разработка значительно облегчает процесс внесение изменений в
проект при изменении требований заказчика;
Отдельные элементы информационной системы постепенно
интегрируются в единое целое. Интеграция производится практически
непрерывно, она начинается с меньшего количества элементов, тогда в ее
реализации возникает гораздо меньше проблем;
Уменьшение уровня рисков. Риски обнаруживаются в процессе
интеграции;
Спиральная модель обеспечивает достаточную гибкость в управлении
проектом, дает возможность внесения различных изменений в разработку;
Позволяет получить более надежную и стабильную систему.
Недостаток спиральной модели - это определение момента перехода к
следующему этапу. Чтобы решить эту проблему необходимо ограничить время
на каждом из этапов жизненного цикла информационной системы. Завершение
итерации происходит строго в соответствии с планом, несмотря на то, что
запланированные работы могут быть не выполнены
Развитее каскадной и спиральной моделей привело к появлению
современного итерационного подхода, который представляет собой их
рациональное сочетание.
Итеративная разработка представлена на рисунке 5.
33
Рисунок 5. Итеративная разработка программного обеспечения
Создание информационной системы предполагает увязку проектных
решений, получаемых при выполнении отдельных задач. Данный подход
обуславливает необходимость итерационных возвратов, когда проектные
решения по отдельным задачам формируются в общие системные решения, и
необходимо пересмотреть ранее сформулированные требования. Как правило,
из-за большого числа итераций появляются рассогласования в уже сделанных
проектных решениях и документации. Запутанность функциональной и
системной архитектуры созданной информационной системы, трудность в
использовании проектной документации вызывают на стадиях внедрения и
эксплуатации сразу необходимость перепроектирования всей системы.
Длительный жизненный цикл представлен на рисунке 5, разработки
информационной системы заканчивается этапом внедрения, за которым
начинается жизненный цикл создания новой информационной системы.
Различные варианты итерационного подхода реализованы в
большинстве современных технологий и методов проектирования.
RUP включает в себя четыре фазы: начало, исследование,
конструирование и внедрение, которые представлены на рисунке 6. Каждая
фаза может быть разбита на этапы (итерации), в результате которых
выпускается готовая для использования версия. Прохождение через четыре
34
фазы завершается генерацией версии системы. Если после этого работа над
проектом не прекращается, то полученный продукт продолжает развиваться
5
.
Рисунок 6. Графическое представление процесса разработки по
RUP
RUP основан на следующих основных принципах:
• Ранняя идентификация и непрерывное (до окончания проекта)
устранение основных рисков.
• Концентрация на выполнении требований клиентов.
• Ожидание изменений в требованиях, проектных решениях и
реализации в процессе разработки.
• Компонентная архитектура, реализуемая и тестируемая на ранних
стадиях проекта.
• Непрерывный контроль качества.
• Работа над проектом в сплоченной команде.
RUP использует итеративную модель разработки. В конце каждой
5
Богданов, В. В. Управление проектами. Корпоративная система — шаг за шагом / В.В. Богданов. — М. :
Манн, Иванов и Фербер, 2013. - 248 с.
35
итерации (в идеале продолжающейся от 2 до 6 недель) проектная группа
должна достичь запланированных на данную итерацию целей, создать или
совершенствовать проектные артефакты и получить промежуточную, но
функциональную версию конечного продукта. Итеративная разработка
позволяет быстро реагировать на изменяющиеся требования, обнаруживать и
устранять риски на ранних стадиях проекта, и эффективно контролировать
качество создаваемого продукта.
Гибкая разработка
В феврале 2001 г. в штате Юта, США был выпущен «Agile Manifesto»,
как альтернатива управляемым документацией, «тяжеловесным» практикам
разработки ПО.
Основные принципы:
• Наивысший приоритет - удовлетворенность клиентов за счет
регулярной и ранней поставки ценного ПО. Изменение требований
приветствуется, даже на более поздних стадиях разработки.
• Agile-процессы позволяют использовать изменения чтобы
предоставить клиенту конкурентное преимущество. Работающий продукт
следует выпускать как можно чаще, с периодичностью от 2х недель до 2х
месяцев.
• На протяжении всего проекта разработчики и представители
бизнеса должны ежедневно работать вместе. Над проектом должны работать
мотивированные профессионалы. Для того чтобы работа была сделана,
создаются условия, обеспечиваются поддержка и полное доверие к ним.
• Прямое общение - это наиболее практичный и эффективный способ
обмена информацией, как с самой командой, так и внутри команды. Основным
показателем прогресса является рабочий продукт.
• Инвесторы, разработчики и пользователи должны быть в состоянии
поддерживать заданный темп бесконечно. Постоянное внимание к
техническому совершенству и качеству проектирования повышает гибкость
проекта.
36
• Простота - искусство минимизации ненужной работы. Лучшие
требования, архитектурные и технические решения рождаются у
самоорганизующихся команд.
• Команда должна систематически анализировать возможные
способы повышения эффективности и соответственно корректировать стиль
своей работы.
Методика Scrum
Слово Scrum («схватка») взято из регби и обозначает метод командной
игры, позволяющий завладеть мячом и вести его дальше по полю, а для этого
нужны слаженность, единство намерений и четкое понимание цели.
В основе методологии Scrum лежит простая идея. Когда бы ни был
запущен проект, ничто не мешает регулярно проверять ход работ и
последовательно выяснять: справляется ли команда с заданием; в правильном
ли направлении движется команда; создается ли именно то, что на самом деле
хочет получить заказчик. И так же постоянно поднимать вопросы: есть ли
способы усовершенствовать методы разработки и выполнять работу наиболее
качественно и быстро; существуют ли факторы, препятствующие
поставленным задачам.
Scrum - это методология управления разработкой информационных
систем, в которой уделяется большое внимание контролю качества процесса
разработки. В дополнении к управлению проектами по разработке
программного обеспечения, методология используется командами поддержки
программного обеспечения, а также как подход управления разработкой и
сопровождением программ.
Следуя методологии Scrum, весь процесс разработки представлен на
рисунке 7, он разбит на небольшие временные интервалы, которые называются
спринтами. Во время спринта происходит функциональный рост
разрабатываемого программного обеспечения. Разделение задач на спринты,
37
позволяет сделать процесс разработки более предсказуемым и гибким
6
.
Рисунок 7. Scrum-процессы
Еще два термина, которые важны в методике Scrum - это резерв проекта
и резерв спринта. Резервом проекта является упорядоченный список
требований к функциональности, в соответствии с уровнем важности. Резерв
спринта содержит функции, выбранные владельцем проекта из резерва проекта.
Соответственно, Scrum-команда участвует в процессе разработки проекта,
участникам которой назначаются четко обозначенные «роли».
Важнейшие фигуры Serum-процесса: Scrum Master (проводит совещания
(Scrum meetings), следит за соблюдением принципов процесса и устраняет
противоречия), Product Owner (представляет интересы конечных
пользователей), и собственно Scrum-команда (состоящая из специалистов
различных профилей проектной команды).
В ходе работ над проектом в соответствии с методологией Scrum
происходят регулярные встречи команды, жесткая проверка выполняемых
задач, постановка новых целей, корректировка. Существует ряд инструментов
управления проектами, которые поддерживают ведение Scrum-процесса.
Использование методологии Scrum клиенту дает ряд преимуществ.
Прежде всего, это увеличение скорости запуска проекта с наиболее
6
Баронов, А.В. Информационные технологии и управление предприятием / В.В. Баронов, Г.Н. Калянов, Ю.И.
Попов, И.Н. Титовский. - М.: Компания АйТи, 2016. — 328 с
38
приоритетными функциями и значительная экономия бюджета клиента. Кроме
того, методология Scrum позволяет осуществлять непрерывный контроль за
ходом работ и более гибко контролировать траты из бюджета проекта.
Экстремальное программирование
Упрощенная методология организации разработки программ для малых
и средних по размеру групп разработчиков, занимающихся созданием
программного продукта в условиях неточных или быстро меняющихся
требований.
Основные принципы:
Основными принципами являются:
1. Тестирование. Экстремальное программирование включает в себя
запись автоматических тестов (программный код, написанный специально для
проверки логики другого кода). Тесты модулей (юнит-тесты) дают возможность
разработчикам убедиться, что каждый из них по отдельности работает
правильно. Они также помогают другим разработчикам понять, почему
требуется определенный фрагмент кода, и как он работает — в ходе изучения
кода тестов логика тестируемого кода становится понятной, поскольку она
показывает, как его следует использовать. Тесты модулей также позволяют
разработчику выполнять рефакторинг без какого-либо опасения.
Рефакторинг (refactoring) — это метод улучшения кода без изменения
его функциональности.
Функциональные тесты предназначены для проверки функционирования
логики, образованной взаимодействием нескольких (часто - весьма
внушительных размеров) частей. Они менее подробны, чем юнит-тесты, но
охватывают гораздо больше - то есть тесты, которые при выполнении влияют
на больший объем кода, вероятность обнаружения какого-либо некорректного
поведение, явно, больше.
Для экстремального программирования приоритетным является подход,
называемый TDD (test-driven development—разработка через тестирование). В
соответствии с этим подходом сначала пишется тест, затем реализуется логика,
39
необходимая для прохождения теста. TDD, в некотором смысле, позволяет
писать код, который более удобен в использовании - потому что при написании
теста, когда логики еще нет, проще всего позаботиться об удобстве будущей
системы.
2. Игра в планирование: главная цель игры в планирование - быстро
составить приблизительный план работы и постоянно обновлять его, когда
условия задачи становятся более ясными. Артефактами игры в планирование
является набор бумажных карточек, на которых записаны пожелания клиентов
(customer stories), и приблизительный план работы по выпуску следующих
небольших версий продукта. Критическим фактором, который делает этот
стиль планирования эффективным, является то, что в этом случае заказчик
несет ответственность за принятие бизнес-решений, а команда разработчиков
отвечает за принятие технических решений. Если это правило не выполняется,
весь процесс разбивается на части.
3. Парное программирование: Данное программирование
подразумевает, что весь код пишется парами программистов, работающих на
одном компьютере. Один из них напрямую работает с текстом программы,
другой просматривает его работу и следит за общей картиной происходящего.
При необходимости клавиатура свободно передается от одного к другому. Во
время работы над проектом пары не фиксированы: рекомендуется их
смешивать, чтобы каждый программист в команде имел представление о всей
системе. Таким образом, парное программирование усиливает взаимодействие
внутри команды.
4. Постоянная интеграция: При частом выполнении интеграции
разрабатываемой системы, можно уйти от большого количества проблем
связанных с этим. Если применять обычные методы, то интеграция будет
проводиться на завершающем этапе работы над продуктом, когда полностью
готовы все элементы системы. Полная интеграция системного кода в
экстремальном программировании производится несколько раз в день, лишь
после, того как разработчики проверили, что абсолютно все тесты модулей
40
работают исправно.
5. Частые небольшие релизы: Версии (releases) продукта должны
вводиться в эксплуатацию как можно чаще. Работа над каждой версией должна
занимать как можно меньше времени. В то же время каждая версия должна
быть достаточно осмысленной с точки зрения полезности для бизнеса. Чем
раньше будет выпущена первая рабочая версия продукта, тем раньше клиент
начинает получать от неё дополнительную прибыль. Чем раньше клиент
начинает использовать продукт, тем раньше разработчики получат от него
обратную информацию о продукте. Эта информация может быть чрезвычайно
полезной при планировании следующей версии.
6. Простота проектирования: Проектирование должно выполняться
небольшими шагами, с учетом постоянно меняющихся требований. В любой
момент времени следует пытаться использовать простейший дизайн,
подходящий для решения текущей задачи, и менять его по мере того, как
условия задачи этого требуют.
7. Метафора системы: Архитектура - это представление о
компонентах системы и их взаимосвязях друг с другом. Разработчикам
необходимо проанализировать архитектуры программного обеспечения, чтобы
понять, в каком месте системы необходимо добавлять новые функции, и с чем
будет взаимодействовать новый компонент.
Выбор хорошей метафоры облегчает команде разработчиков понимание
того, как устроена система.
8. Стандарты кодирования: Все члены команды должны выполнять
требования общих стандартов кодирования. Благодаря этому обеспечивается
эффективное выполнение поставленных задач.
9. Коллективное владение: Коллективное владение означает, что
каждый член команды несет ответственность за весь исходный код. Важным
преимуществом коллективного владения кодом является то, что оно ускоряет
процесс разработки, поскольку при появлении ошибки её может устранить
любой программист.