Методология разработки программного обеспечения ХР

 

Министерство  образования и науки Украины

Севастопольский национальный технический университет

Кафедра

информационных систем

Реферат

по дисциплине «Технология создания программных продуктов»

на тему «Методология разработки программного обеспечения ХР»

Выполнил: ст. гр. И-21д

Михайлов А. А.

Проверил:

Строганов В. А.

Севастополь

2013

 

СОДЕРЖАНИЕ

 

ВВЕДЕНИЕ..............................................................................................................3

1. ИСТОРИЯ ВОЗНИКНОВЕНИЯ МЕТОДОЛОГИИ.......................................4
2. СОДЕРЖАНИЕ МЕТОДОЛОГИИ..................................................................5

2.1 Основные принципы методологии..............................................................5

2.2 Жизненный цикл...........................................................................................6

2.3 Практики........................................................................................................7

2.4 Существующие риски применения методологии......................................9

3. ИЗВЕСТНЫЕ ПРИМЕНЕНИЯ........................................................................13

ЗАКЛЮЧЕНИЕ.....................................................................................................14

СПИСОК  ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ.............................................15

 

ввеДение

Методология разработки программного обеспечения — это система принципов, а также совокупность идей, понятий, методов, способов и средств, определяющих стиль разработки программного обеспечения. Из существующих методологий можно выделить два основных типа: прогнозируемые и адаптивные методологии.

Прогнозируемые фокусируются на детальном планировании будущего. Известны запланированные задачи и ресурсы на весь срок проекта. Команда с трудом реагирует на возможные изменения. План оптимизирован исходя из состава работ и существующих требований. Изменение требований может привести к существенному изменению плана, а также дизайна проекта. Часто создается специальный комитет по «управлению изменениями», чтобы в проекте учитывались только самые важные требования.

Адаптивные методологии  нацелены на преодоление ожидаемой  неполноты требований и их постоянного  изменения. Когда меняются требования, команда разработчиков тоже меняется. Команда, участвующая в адаптивной разработке, с трудом может предсказать  будущее проекта. Существует точный план лишь на ближайшее время. Более  удаленные во времени планы существуют лишь как декларации о целях проекта, ожидаемых затратах и результатах.

Методология разработки XP (extreme programming) является адаптивной методологией разработки. Это сравнительно новая методология, но хорошо зарекомендовавшая себя среди профессиональных разработчиков.

 

1. История возникновения методологии

Наверное, каждый проектировщик или аналитик хотя бы раз в жизни сталкивался с заказчиком, стремящимся получить свой проект как можно дешевле и вдобавок в максимально сжатые сроки. Но если стоимость проекта — вполне реальный предмет торга, то вести переговоры о корректировке сроков сдачи проекта куда сложнее. Нетерпеливых клиентов сегодня становится все больше и больше, что объясняется и состоянием современного динамичного рынка, и падающим уровнем доверия между исполнителями и заказчиками, и поведением инвесторов, у которых аппетит приходит во время еды (при наличии более или менее работающей версии продукта деньги на дальнейшую разработку дают намного охотнее), и т.д. В связи с этим классические методологии разработки (при которых долгий цикл собственно проектирования и сбора информации, когда клиент вкладывает значительные средства, а реального результата довольно долго не получает) вступают в весьма жесткое противоречие с интересами нетерпеливого заказчика. Все это и дало толчок развитию альтернативных методологий проектирования в двух основных направлениях: повышение доверия заказчика путем предоставления реальных доказательств успешно развивающегося процесса разработки и резкое сокращение сроков разработки продукта. Одной из таких методологий и является ХР.

Методология XP была создана Кентом Беком (Kent Beck) в 1996 году в ходе попытки спасти провальный проект по разработке системы расчета зарплаты для компании Крайслер. В 2000 году проект был закрыт, но XP к тому времени уже получила известность и начала распространяться среди разработчиков ПО.

 

2. Содержание  методологии
1. Основные принципы методологии

Основными принципами рассматриваемой методологии являются:

- Простота решений (simplicity).

- Интенсивная разработка малыми группами (не больше 10 человек), активное общение в группе и между группами (communication).

- Обратная связь с клиентом (feedback), который фактически вовлечен в процесс разработки.

- Достаточная степень смелости (courage) и желание идти на риск.

Первый фактор ускорения  разработки — итеративность: разработка ведется короткими итерациями при  наличии активной взаимосвязи с  заказчиком. XP — это итеративный процесс разработки, который сам по себе не является революционным. Итерации как таковые предлагается делать короткими, рекомендуемая длительность — 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории (user story). Пользовательские истории в данном случае являются начальной информацией, на основании которой создается модуль. Пользовательские истории отличаются от прецедентов (use case): пользовательская история коротка — 1-2 абзаца, тогда как прецеденты обычно пишут достаточно подробными, с основным и альтернативными потоками — таким образом, получается примерно страница плюс схема (наиболее распространенная формализация в настоящее время предложена в UML); истории пользователей пишутся самими пользователями (которые в XP являются частью команды) в отличие от прецедентов, которые обычно пишет системный аналитик. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать посредством активного включения в процесс разработки заказчика как полноправного члена команды и за счет наличия постоянного контакта с заказчиком (активное общение и непрерывная поддержка обратной связи). В данном случае extreme — это степень привлечения заказчика к программистской кухне, что обусловлено стремлением сжать сроки разработки за счет коммуникации и обратной связи.

Второй фактор ускорения  разработки продукта — наличие малых  групп и парное программирование (когда два программиста вместе создают  код на одном общем рабочем  месте). Все это нацелено на достижение высокого уровня общения в группе, а также на как можно более  раннее обнаружение проблем (как  ошибок, так и срыва сроков). Парное программирование преследует цель стабилизации проекта, так как при данной методологии  высок риск потери кода по причине  ухода программиста, не выдержавшего интенсивного графика работы. В этом случае второй программист из пары играет роль «наследника» кода (что  в классических методиках реализуется  в технической документации). Немаловажно  и то, как именно распределены группы в рабочем пространстве — в XP используется открытое рабочее пространство, которое предполагает быстрый и свободный доступ всех ко всем; как правило, рабочее пространство строится на основе круга.

Третий фактор ускорения  разработки процесса — принятие первого  наипростейшего рабочего решения. В  данном случае экстремальность метода связана с высокой степенью риска  решения, обусловленного поверхностностью анализа и жестким временным  графиком. Реализуется минимальный  набор главных функций системы  на первой и каждой последующей итерации; функциональность расширяется на каждой итерации.

 

2. Жизненный цикл

Жизненный цикл проекта в  XP состоит из последовательности релизов. Каждый релиз – это полноценная версия продукта, которую может использовать заказчик, и содержащая дополнительную функциональность по сравнению с предыдущим релизом. Релиз появляется в результате одной или нескольких итераций, длящихся от одной до четырех недель.

В XP не рекомендуется тратить много времени на планирование; сам процесс планирования называется игрой (planning game). Подробный план составляется только на очередную итерацию и ближайшие один-два релиза.

Планирование релиза состоит  из следующих шагов:

Заказчик формулирует  свои требования в виде историй, которые  оцениваются по трудоемкости разработчиками. Оценки трудоемкости делаются в так  называемых идеальных днях – времени, которое некий воображаемый разработчик  потратит на реализацию истории при  полном отсутствии отвлекающих факторов, параллельных задач, перерывов и  т.п.

Истории сортируются по приоритету, рискам, сложности реализации.

Определяется фактическая  производительность команды (какое  число реальных дней соответствует  идеальному дню).

На основании фактической  производительности определяется, какие  истории войдут в очередной релиз  и за какое время он будет завершен.

Итерация планируется  аналогичным образом.

 

Предварительно определяется набор историй для итерации.

Истории разбиваются на задачи (tasks), которые распределяются между разработчиками. В отличие от историй, которые описывают поведение системы с точки зрения пользователя, задачи составляются на техническом уровне, например «модифицировать схему базы данных» или «провести рефакторинг».

Разработчики оценивают  свои задачи. Казалось бы, это ненужное повторение операции оценки историй, однако на этом этапе уточненные оценки должны быть более реалистичными. Поскольку  задачи теперь оценивают их непосредственные исполнители, в оценках учитывается индивидуальная производительность, зависящая от опыта, знакомства с используемыми технологиями и т.п.

На основе уточненных оценок задач подсчитывается общая загрузка команды. В зависимости от загрузки некоторые истории могут быть перенесены на следующую итерацию или, наоборот, добавлены в текущую.

Периодически в ходе проекта  измеряется фактическая производительность команды. Если она начинает сильно отличаться от значения, которое было использовано при планировании, график выхода релизов  должен быть пересмотрен.

 

3. Практики

Обычно XP характеризуют набором из 12 действий (практик), которые необходимо выполнять для достижения хорошего результата. Практики XP не определяют сам процесс XP, но XP определяет эти практики — то есть выполнение практик не гарантирует результата. Ни одна из практик не является принципиально новой, но в XP они собраны вместе.

- Планирование процесса (planning game). Вся команда собирается вместе, принимается коллективное решение о том, какие свойства системы будут реализованы в ближайшей итерации. Набор свойств определяется пользовательскими историями. XP-трудоемкость каждого свойства определяется самими программистами.

- Тесное взаимодействие с заказчиком (feed-back, on-site customer). Заказчик должен быть членом XP-команды (on-site customer). Он пишет пользовательские истории, выбирает истории, которые будут реализованы в конкретной итерации, и отвечает на вопросы, касающиеся бизнеса. Заказчик должен быть экспертом в автоматизируемой предметной области. Необходимо постоянное наличие обратной связи с заказчиком (feed-back).

- Метафора системы (system metaphor). Хорошая метафора системы означает простоту именования классов и переменных. В реальной жизни поиск метафоры — крайне сложное занятие; найти хорошую метафору непросто. В любом случае команда должна иметь единые правила именования.

- Простая архитектура (simple design). Любое свойство системы должно быть реализовано как можно проще. Программисты в XP-команде работают под девизом: «Ничего лишнего!». Принимается первое наипростейшее работающее решение, реализуется необходимый уровень функциональности на данный момент. Тем самым экономится время программиста.

- Стандарты кодирования (coding conventions). Стандарты кодирования нужны для обеспечения других практик: коллективного владения кодом, парного программирования и рефакторинга. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно: группа будет работать в режиме постоянной нехватки времени. Детальные стандарты не требуются, необходимо стандартизировать только важные вещи. Определение наиболее важных объектов стандартизации в XP субъективно.

- Рефакторинг (refactoring). Рефакторинг — это оптимизация существующего кода в сторону упрощения, что предусматривает постоянную работу по упрощению кода. Сохраняя код прозрачным и определяя его элементы всего один раз, программисты сокращают число ошибок, которые впоследствии придется устранять. При реализации каждого нового свойства системы программист должен подумать над тем, можно ли упростить существующий код и как это поможет реализовать новое свойство. Кроме того, нельзя совмещать рефакторинг с дизайном: если создается новый код, рефакторинг надо отложить.

- Парное программирование (pair programming) — одна из самых известных XP-практик. Все программисты должны работать в парах: один пишет код, другой смотрит. Таким образом, необходимо размещать группу программистов в одном месте, что легче всего сделать на территории заказчика (все необходимые члены команды географически находятся в одном месте); XP наиболее успешно работает в нераспределенных коллективах программистов и пользователей.

- 40-часовая рабочая неделя. Программист не должен работать более 8 часов в день. Необходимость сверхурочной работы (overtime) — это четкий индикатор проблемы на данном конкретном направлении разработки; к тому же заказчик не платит за сверхурочную работу в XP. Поиск причин сверхурочной работы и их скорейшее устранение  — одно из основных правил.

- Коллективное владение кодом (collective code ownership). Каждый программист в коллективе XP должен иметь доступ к коду любой части системы и вносить изменения в любой код. Обязательное правило: если программист внес изменения и система после этого работает некорректно, то именно этот программист должен исправить ошибки. В противном случае работа системы уподобится тотальному хаосу.

- Частая смена версий (small releases). Минимальная итерация — один день, максимальная  — месяц; чем чаще осуществляются релизы, тем больше недостатков системы будет выявлено. Первые релизы помогают выявить недостатки на самых ранних стадиях, далее функциональность системы расширяется (на основании тех же пользовательских историй). Поскольку пользователь включается в процесс разработки начиная с первого релиза, то он оценивает систему и выдает пользовательскую историю плюс feedback. На основании этого определяется следующая итерация: каким будет новый релиз. В XP все направлено на обеспечение непрерывной обратной связи с пользователями.