Модели жизненного цикла MSF, RUP, XP

Программная инженерия. Лекция 3 Модели жизненного цикла MSF, RUP, XP В настоящее время широкое применение получают так называемые промышленные технологии создания программного продукта. Эти технологии были разработаны фирмами, накопившими большой опыт создания ПО. Технологии представлены описаниями принципов, методов, применяемых процессов и операций. Такие технологии, как правило, поддерживаются набором CASE-средств, охватывают все этапы жизненного цикла продукта и успешно применяются для решения практических задач. Рассмотрим особенности моделей жизненного цикла трех наиболее известных промышленных технологий: • Microsoft Solution Framework (MSF) – разработка фирмы Microsoft, предназначенная для решения широкого круга задач. Технология масштабируема, т.е. настраиваема на решение задач любой сложности коллективом любой численности. • Rational Unified Process (RUP) – разработка фирмы Rational, долгое время успешно занимавшейся созданием CASE-средств, применяемых на различных этапах жизненного цикла продукта от анализа до тестирования и документирования. Аналогично MSF, RUP универсальна, масштабируема и настраиваема на применение в конкретных условиях. • Extreme Programming (XP) – активно развивающаяся в последнее время технология, предназначенная для решения относительно небольших задач, относительно небольшими коллективами профессиональных разработчиков в условиях жестко ограниченного времени. Каждая из этих технологий имеет свои особенности организации модели жизненного цикла создания продукта. Модель Microsoft Solution Framework Одна из особенностей технологии MSF состоит в том, что она ориентирована не просто на создание программного продукта, удовлетворяющего перечисленным требованиям, а на поиск решения проблем, стоящих перед заказчиком. Различие состоит в том, что перечисляемые заказчиком требования являются проявлениями некоторых более глубоких проблем и неточность, неполнота, изменение требований в процессе разработки – следствие недопонимания проблем. Поэтому, в технологии MSF большое внимание уделяется анализу проблем заказчика и разработке вариантов системы для поиска решения этих проблем. Модель жизненного цикла MSF является некоторым гибридом каскадной и спиральной моделей, сочетая простоту управления каскадной модели с гибкостью спиральной. Схема модели жизненного цикла MSF (модели процессов) представлена на слайде. Модель жизненного цикла MSF ориентирована на “вехи” (milestones) – ключевые точки проекта, характеризующие достижение какого-либо существенного результата. Этот результат может быть оценен и проанализирован, что подразумевает ответ на вопрос: “А достигли ли мы целей, поставленных на этом шаге?». В модели предусматривается наличие основных вех (завершение главных фаз модели) и промежуточных, отражающих внутренние этапы главных фаз. Основными фазами модели MSF являются: • Создание общей картины приложения (Envisioning).На этом этапе решаются следующие основные задачи: оценка существующей ситуации; определение состава команды, структуры проекта, бизнесцелей, требований и профилей пользователей; разработка концепции решения и оценка риска. Устанавливаются две промежуточные вехи: "Организован костяк команды" и "Создана общая картина решения". • Планирование (Panning). Включает планирование и проектирование продукта. На основе анализа требований разрабатывается проект и основные архитектурные решения, функциональные спецификации системы, планы и календарные графики, среды разработки, тестирования и пилотной эксплуатации. Этап состоит из трех стадий: концептуальное, логическое и физическое проектирование. На стадии концептуального проектирования задача рассматривается с точки зрения пользовательских и бизнес-требований и заканчивается определением набора сценариев использования системы. При логическом проектировании задача рассматривается с точки зрения проектной команды, решение представляется в виде набора сервисов. И уже на стадии физического проектирования задача рассматривается с точки зрения программистов, уточняются используемые технологии и интерфейсы. • Разработка (Developing). Создается вариант решения проблемы, в виде кода и документации очередного прототипа, включая спецификации и сценарии тестирования. Основная веха этапа - "Окончательное утверждение области действия проекта". Продукт готов к внешнему тестированию и стабилизации. Кроме того, заказчики, пользователи, сотрудники службы поддержки и сопровождения, а также ключевые участники проекта могут предварительно оценить продукт и указать все недостатки, которые нужно устранить до его поставки. • Стабилизация (Stabilizing). Подготовка к выпуску окончательной версии продукта, доводка его до заданного уровня качества. Здесь выполняется комплекс работ по тестированию (обнаружение и устранение дефектов), проверяется сценарий развертывания продукта. Когда решение становится достаточно устойчивым, проводится его пилотная эксплуатация в тестовой среде с привлечением пользователей и применением реальных сценариев работы. • Развертывание (Deploying). Выполняется установка решения и необходимых компонентов окружения, проводится его стабилизация в промышленных условиях и передача проекта в руки группы сопровождения. Кроме того, анализируется проект в целом на предмет уровня удовлетворенности заказчика. Модель Rational Unified Process Модель жизненного цикла RUP является довольно сложной, детально проработанной итеративно-инкрементной моделью с элементами каскадной модели. В модели RUP выделяются 4 основные фазы, 9 видов деятельности (процессов). Кроме того, в модели описывается ряд практик, которые следует применять или руководствоваться для успешного выполнения проекта. RUP ориентирован на поэтапное моделирование создаваемого продукта с помощью языка UML. Основными фазами RUP являются: • Фаза начала проекта (Inception). Определяются основные цели проекта, бюджет проекта, основные средства его выполнения — технологии, инструменты, ключевой персонал, составляются предварительные планы проекта. Основная цель этой фазы — достичь компромисса между всеми заинтересованными лицами относительно задач проекта. • Фаза проработки (Elaboration). Основная цель этой фазы — на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы. • Фаза построения (Construction). Основная цель этой фазы — детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры. • Фаза передачи (Transition). Цель фазы — сделать систему полностью доступной конечным пользователям. Здесь происходит окончательное развертывание системы в ее рабочей среде, подгонка мелких деталей под нужды пользователей. В рамках каждой фазы возможно проведение нескольких итераций, количество которых определяется сложностью выполняемого проекта. Деятельности (основные процессы) RUP делятся на пять рабочих и четыре поддерживающие. К рабочим деятельностям относятся: • Моделирование предметной области (бизнес-моделирование, Business Modeling). Цели этой деятельности — понять бизнес-контекст, в котором должна будет работать система (и убедиться, что все заинтересованные лица понимают его одинаково), понять возможные проблемы, оценить возможные их решения и их последствия для бизнеса организации, в которой будет работать система. • Определение требований (Requirements). Цели — понять, что должна делать система, определить границы системы и основу для планирования проекта и оценок ресурсозатрат в нем. • Анализ и проектирование (Analysis and Design). Выработка архитектуры системы на основе ключевых требований, создание проектной модели, представленной в виде диаграмм UML, описывающих продукт с различных точек зрения. • Реализация (Implementation). Разработка исходного кода, компонент системы, тестирование и интегрирование компонент. • Тестирование (Test). Общая оценка дефектов продукта, его качество в целом; оценка степени соответствия исходным требованиям. Поддерживающими деятельностями являются: • Развертывание (Deployment). Цели — развернуть систему в ее рабочем окружении и оценить ее работоспособность. • Управление конфигурациями и изменениями (Configuration and Change Management). Определение элементов, подлежащих хранению и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений. • Управление проектом (Project Management). Включает планирование, управление персоналом, обеспечения связей с другими заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта. • Управление средой проекта (Environment). Настройка процесса под конкретный проект, выбор и смена технологий и инструментов, используемых в проекте. Модель Extreme Programming Экстремальное программирование является примером так называемого метода «живой» разработки (Agile Development Method). В группу «живых» входят, помимо экстремального программирования, входит еще ряд методов, о чем подробнее можно прочитать: Мартин Фаулер. Новые методологии программирования. http://www.maxkir.com/sd/newmethRUS.html. Схема модели XP Модель жизненного цикла XP является итерационно-инкрементной моделью быстрого создания (и модификации) протопопов продукта, удовлетворяющих очередному требованию (user story). Особенности этой модели представлены на слайде. Основными фазами модели можно считать: • «Вброс» архитектуры – начальный этап проекта, на котором создается видение продукта, принимаются основные решения по архитектуре и применяемым технологиям. Результатом начального этапа является метафора (metaphor) системы, которая в достаточно простом и понятном команде виде должна описывать основной механизм работы системы. • Истории использования (User Story) – этап сбора требований, записываемых на специальных карточках в виде сценариев выполнения отдельных функций. Истории использования являются требованиями для планирования очередной версии и одновременной разработки приемочных тестов (Acceptance tests) для ее проверки. • Планирование версии (релиза). Проводится на собрании с участием заказчика путем выбора User Stories, которые войдут в следующую версию. Одновременно принимаются решения, связанные с реализацией версии. Цель планирования - получение оценок того, что и как можно сделать за 1-3 недели создания следующей версии продукта. • Разработка проводится в соответствии с планом и включает только те функции, которые были отобраны на этапе планирования. • Тестирование проводится с участием заказчика, который участвует в составлении тестов. • Выпуск релиза – разработанная версия передается заказчику для использования или бета-тестирования. По завершению цикла делается переход на следующую итерацию разработки Extreme Programming. Принципы Особенности модели жизненного цикла XP проясняют следующие принципы этого метода. Прежде всего, это принципы «живой» разработки ПО, зафиксированные в манифесте «живой» разработки: • Люди их общение более важны, чем процессы и инструменты • Работающая программа более важна, чем исчерпывающая документация • Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта • Отработка изменений более важна, чем следование планам Кроме того, в XP есть несколько правил (техник), характеризующих особенности модели его жизненного цикла: • Живое планирование (planning game) - как можно быстрее определить объем работ, который нужно сделать до следующей версии ПО. Решение принимается на основе, в первую очередь, бизнесприоритетов заказчика и, во-вторую, технических оценок. Планы изменяются, как только они начинают расходится с действительностью или пожеланиями заказчика. • Частая смена версий (small releases) - первая работающая версия должна появиться как можно быстрее, и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени. • Простые проектные решения (simple design) - в каждый момент времени система должна быть сконструирована так просто, насколько это возможно. Новые функции добавляются только после ясной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается. • Разработка на основе тестирования (test-driven development) - сначала пишутся тесты, потом реализуются модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала. • Постоянная переработка (refactoring) - системы для устранения излишней сложности, увеличения понятности кода, повышения его гибкости. При этом предпочтение отдается более элегантным и гибким решениям, по сравнению с просто дающими нужный результат. • Программирование парами (pair programming) - весь код пишется двумя программистами на одном компьютере, что повышает его качество (отсутствие ошибок, понятность, читаемость,…). • Постоянная интеграция (continuous integration) - система собирается и проходит интеграционное тестирование как можно чаще, по несколько раз в день, каждый раз, когда пара программистов оканчивает реализацию очередной функции. • 40-часовая рабочая неделя - сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд — это истощает программистов и делает их работу значительно менее продуктивной. Более подробно об экстремальном программировании можно почитать здесь: Agile-технологии В области SE специалисты Кент Бек (Kent Beck), Мартин Фаулер (Martin Folwer), Кен Шваубер (Ken Schwaber), Джефф Сазерленд (Jeff Sutherland) и другие образовали некоммерческую организацию Agile Alliance, пропагандирующую Agile Software Development, методологию extreme Programming, SCRUM, DSDM, ASD, Crystal, FDD, Pragmatic Programming и др.[1] Методологии Agile ориентированы на тесное взаимодействие команды разработчиков с пользователями, итеративную модель ЖЦ с приращениями и быструю реакцию на изменяющиеся требования и продукто-ориентированный подход к разработке ПО. Такой подход к разработке ПС обеспечивает уменьшение зависимости не только от постоянных изменений функциональных требований заказчика, но и от проблем неритмичности общего финансирования и плана-графика разработки, а также быстрой смены технологической среды разработки. Самой широко известной Agile- методологией является extreme Programming (ХР) (экстремальное программирование). В ХР реализуется принцип «коллективного владения кодом». В нем любой член группы может изменить не только свой код, но и код другого программиста и каждый модуль снабжается автономным тестом (unit test), обеспечивая возможность регрессионного тестирования модулей. Тесты пишут сами программисты, и они имеют право написать тесты для любого модуля. Таким образом, большинство ошибок исправляются на стадии кодирования, либо при просмотре кода, либо при динамическом тестировании. DSDM (Dynamic Systems Development Method) является методом разработки информационных систем консорциума DSDM. Он использует модель быстрой разработки RAD (Rapid Application Development) с прототипированием для достижения целей построения систем в условиях ограниченных ресурсов проекта. ASD (Adaptive Software Development) — методология разработана Д. Хайсмитом (президентом Information Architects, Inc.) специально для экстремальных проектов и базируется на теории сложных адаптивных систем. В ней статический цикл разработки ПС включает планирование — проектирование — программирование, а динамический цикл: размышление — взаимодействие — обучение. FDD (Feature Driven Development) — методология разработки ПС ориентирована на функциональные возможности, предложена Д. ДеЛуком для крупного банка (http://www.nebulon.com). FDD характеризуется модельноориентированным (model-driven) процессом разработки, включающим три последовательные фазы, в ходе которых формируется общая модель системы, и две итеративные фазы, выполняемые для каждой выделенной функции системы. SCRUM — гибкая методика управления проектом фирмы Advanced Development Methods, Inc., широко используется в сотнях организаций (FujiXerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox and Hewlett- Packard и др.). Эта методика задает итеративную модель ЖЦ с четко определенным процессом разработки, включающим анализ требований, проектирование, программирование, тестирование (http://agile.csc.ncsu.edu). Управление продуктом в Scrum складывается из нескольких универсальных для каждого контекста шагов. Выбирается «Владелец продукта» – человек, который становится связующим звеном между рынком (заказчиком продукта или конечным потребителем) и командой исполнителей. Этот человек отвечает за увеличение ценности продукта и со старта видит общий замысел. Собирается команда исполнителей, компетентность которой должна сочетаться с умением согласованно работать. Определяется Scrum-мастер. Здесь мастер – это администратор, следящий за ходом работы в команде, но не командующий, а помогающий в обучении, обеспечивающий плановое проведение собраний и т. д. Создаётся список требований к цели и продукту с расстановкой пунктов по приоритету. Этот список меняется по ходу развития проекта. Участники команды оценивают каждый пункт списка, решая сколько временных и материальных ресурсов потребуется для реализации задачи. Владелец продукта, мастер и участники команды проводят собрание, где в совместном обсуждении планируется спринт – короткий (не больше месяца в практике разработчиков ПО) этап, на который планируется решение определённой части задач. В некоторых контекстах такой этап называют итерацией. Предполагается, что в течение каждого спринта-итерации команда нарабатывает определённое количество баллов, которое в следующем спринте желательно увеличить, чтобы продемонстрировать рост производительности. Для информирования всех участников процесса создаётся информационная доска, заполняемая стикерами, с разделением на то, что нужно сделать, что находится в работе, и что сделано. По мере выполнения задач, стикера перемещаются из одной колонки в другую. Короткие общие собрания проводятся ежедневно. На них озвучиваются препятствия на пути, определяется уже сделанное для пользы проекта и запланированное. Каждый спринт заканчивается детальным обзором результатов работы и, что не менее важно, обсуждением характеристик процесса в прошедшем спринте. Если можно что-то улучшить, то обговариваются направленные на оптимизацию нововведения, которые будут внедрены в следующем спринте. Для того чтобы такая схема была жизнеспособной, методология управления Scrum должна складываться из ряда составляющих: философии Scrum, которая со временем включила в себя ценности и принципы манифеста Agile (авторы методологии были в числе 17 авторов, подписавших знаменитый манифест), требований в заданном формате, определённого алгоритма действий с распределением ролей в команде, особого типа рабочих отношений, специфического понимания отдельного рабочего этапа, инструментария, подходящего для этой методологии. В зависимости от сферы, в которой внедряется методология управления Scrum, характеристики некоторых составляющих могут отличаться. Например, варьируется число исполнителей в команде, некоторые инструменты учёта или система начисления баллов. Но ключевые моменты и рамки структуры Scrum должны оставаться неизменными. Философская основа Scrum Управление продуктом в Scrum на идеологическом уровне – это следование определённому образу жизни и образу деятельности. Автор книги о методе Scrum увлекался японскими боевыми искусствами и это увлечение отразилось на отношении к своей работе, которая перестала быть просто зарабатыванием денег. Работа в стиле Scrum (как и айкидо) – это способ постоянного совершенствования через практику стремящихся к единству тела и разума. Идеологические основы Scrum позднее были более чётко выражены в манифесте Agile. В нём были перечислены 4 ценности и 12 принципов, которым призывали следовать авторы манифеста. На первое место в системе ценностей ставились: люди и их взаимодействие, работающий продукт, живое сотрудничество с заказчиком, готовность менять и меняться. Эти ценности были не противопоставлены, но определены как более важные по отношению к формальному соблюдению процессуального шаблона и выбору инструментов, соблюдению бюрократической процедуры, следованию первоначальному плану. Предполагалось, что если практика на каждом этапе вносит свои коррективы, и это делает продукт лучше и ценнее, а потребителей – счастливее, то эта практика лучше жёсткого планирования. Подход Agile объединил в одно семейство модели, в основе которых лежали сформулированные ценности. Частью такого семейства моделей был и остаётся Scrum. Роли в Scrum Scrum подход предполагает распределение трёх ролей между участниками проекта. Product owner. Этого человека называют «владельцем продукта» поскольку он становится единственным, кто принимает окончательное решение (поэтому эта роль, как правило, не перепоручается группе лиц). Он же ведёт проект в целом и занимается увеличением ценности продукта для рынка (заказчика), которого представляет. Исполнитель этой роли должен поставить задачи команде на спринт, но не ставит задачи конкретному исполнителю. То есть, Product owner – руководит продуктом, а не командой. Scrum Master. Роль мастера тоже не предполагает возможность постановки задач конкретному исполнителю, поскольку команда, следуя принципам подхода, должна проявлять себя как самоорганизующийся и самоуправляемый организм. Его роль в работе ближе к роли администратора: Team. Scrum команда в такой модели кроссфункциональна и самоуправляема. Нет специального человека, который бы организовывал её работу. Применительно к сфере разработки ПО, команды, как правило, складываются из 5-9 человек (в среднем – семи) специалистов разного профиля (аналитиков, разработчиков, тестировщиков). Несмотря на разнообразие специалистов внутри команды, Team действует как единой целое, и результаты её деятельности тоже оцениваются как результат общей работы. В случае масштабирования при решении очень трудоёмких многоплановых задач, число людей в команде Скрам всё равно стараются не увеличивать, а для работы организовывают систему из нескольких команд. Помимо прочего, это объясняется и «законом Брукса», согласно которому, если коллектив не успевает вовремя закончить проект, то добавление числа исполнителей задерживает проект ещё больше. Характеристика этапов работы Работа над проектом и распределение времени предполагает фазы планирования, спринтов и подведения итогов спринта. В модели Скрам процессы и действия предполагают прозрачность. Чтобы все всё видели в режиме реального времени внедряется специфический инструментарий – доска с колонками, на которой перестановкой стикеров иллюстрируется процесс. В продвинутой версии список информационных панелей расширяется. Список скрам-артефактов включает 4 инструмента: Все этапы, процессы (ритуалы) и технология применения инструментов важны для жизнеспособности модели. Управление проектами Scrum даёт максимальный эффект при комплексном и системном внедрении всех составляющих. мастер работает над созданием атмосферы доверия в коллективе, пока остальные решают свои задачи, устраняет препятствия, поднимает, формулирует и выносит на обсуждение скрытые противоречия, становится связующим звеном между менеджером проекта и командой. Планирование. Пункты списка задач, от которых зависит достижение цели, расставляются по приоритетности. Каждый пункт участниками команды оценивается для определения объёма временных, интеллектуальных, материальных и др. ресурсов. Оценка объёма энергозатрат. Для введения оценочной шкалы предлагают различные условные единицы с неравномерным распределением «веса». Например, сравнивать энергообъём задач можно в «собаках», где «задача-бульдог» больше «задачи-таксы» и меньше «задачи-мастиффа». На практике удобнее каждой такой величине присвоить ещё и числовое значение. Требования в классической модели представляются в виде пользовательских историй. Они должны быть завершёнными, независящими от обстоятельств, практически реализуемыми. Например, работа интернетмагазина в одной истории может описываться с точки зрения потребителя, который рассказывает, как ему удобно сортировать товар, и как хотелось бы, чтобы в корзине было не очень много полей для заполнения. В другой истории этот же проект описывается с точки зрения маркетолога, сообщающего, что ему нужно видеть, как покупатель вёл себя на сайте, сколько целевых действий сделал, прежде чем совершить покупку. Третья история рассказывается с точки зрения менеджера, обрабатывающего заказ, и т.д.. Спринты тоже планируются. Весь коллектив собирается вместе и рассматривают пользовательские истории, оценивая свои возможности с тем условием, что к концу спринта будет закончен запланированный объём задач, который можно будет в виде готового функционала представить заказчику. Команда ставит себя на место потребителя и «проживает» в своём исполнении работы его пользовательскую историю вместе с ним. Собрания, которые проводятся ежедневно, длятся не дольше четверти часа и проходят по одной схеме, определяющей настрой рабочего дня. По сути, собрание состоит из ответов на три ежедневно повторяющиеся вопроса: Что ты сделал накануне, чтобы команда успешно завершила спринт? Что для этого будешь делать сегодня? Что мешает команде? Product backlog. Представляет собой список требований по проекту в виде пользовательских историй, расставленных по приоритету. Отсутствие в этом списке требований означает, что проект завершён. Sprint backlog. Список разделённых на задачи и оценённых требований для ближайшего спринта. Этот список в течение спринта не может пополняться. Sprint Goal. Описание целей, ради которых выполняется спринт. Sprint Burndown Chart. Исполняется в виде диаграммы, отражающей продвижение команды вперёд, и иллюстрирует, как ежедневно, по мере продвижения, «сгорают» человеко-часы.