Экстремальное программирование

Наиболее часто используемой адаптивной моделью является модель экстремального программирования (eXtreme Programming, XP-процесс).

XP-процесс ориентирован на группы малого и среднего размера, разрабатывающих ПС в условиях неопределенных или быстро меняющихся требований.

Основная идея XP-процесса – устранить высокую стоимость внесения изменений. Это достигается путем резкого (до двух недель) сокращения длительности отдельных итераций.

Базовыми действиями являются:

-кодирование,

-тестирование,

-выслушивание заказчика,

-проектирование.

Принципы XP

Высокий динамизм разработки обеспечивается следующими принципами:

-непрерывная связь с заказчиком,

-простота выбираемых решений,

-быстрая обратная связь на основе оперативного тестирования,

-профилактика рисков.

Практики XP

Реализация этих принципов достигается за счет использования следующих методов:

-Метафора – вся разработка ведется на основе простой, общедоступной истории о том, как работает система.

-Простое проектирование – принимаются наиболее простые.

-Непрерывное тестирование как отдельных модулей, так и системы в целом; входным критерием для написания кода является отказавший тестовый вариант

-Реорганизация ( Refactoring ) – улучшение структуры системы при сохранении ее поведения

-Парное программирование – код пишется двумя программистами на одном компьютере

-Коллективное владение кодом – любой разработчик может улучшить код любого модуля системы

-Непрерывная интеграция – система интегрируется как можно чаще; непрерывное регрессионное тестирование гарантирует сохранение функциональности при изменении требований

-Локальный заказчик – в группе все время должен находиться компетентный представитель заказчика

-Стандарты кодирования – должны выдерживаться правила, обеспечивающие одинаковое представление кода во всех частях системы

Прогнозирующие процессы

Все рассмотренные выше модели соответствуют так называемым прогнозирующим ( тяжеловесным ) процессам разработки ПС.

Они предполагают планирование всего объема работ и, соответственно, достаточно большой объем документации.

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

Многочисленные вспомогательные действия выполнить успешную разработку с помощью имеющихся работников, не обязательно являющихся суперпрофессионалами.

Адаптивные процессы

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

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

Адаптивные процессы делают упор на использовании хороших разработчиков, а не хорошо отлаженных процессов разработки.

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

Scrum-модель

Является еще одним примером адаптивного процесса разработки.

Основные идеи модели сформулировали Хиротака Такеути и Икудзиро Нонака в 1986 году.

Основная идея

Экспериментальный факт: проекты, над которыми работают небольшие, кросс-функциональные команды, обычно систематически производят лучшие результаты.

Такеуки и Ноната объяснили это как «подход регби» и ввели и сам термин «scrum» - «толкотня; схватка вокруг мяча (в регби)» .

Впервые метод Scrum был представлен в документированном виде в 1996 году совместно Сазерлендом и Швабером.

Роли

Главные действующие роли:

-ScrumMaster, тот кто занимается процессами и работает в качестве руководителя проекта,

-Владелец Продукта, человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон,

-Команда, которая включает разработчиков.

Этапы разработки:

-Процесс разработки разбивается на отдельные этапы определенной длительности – спринты (обычно,15-30 дней).

-Каждому спринту предшествует этап, который называется product backlog –документирование запросов на выполнение работ.

Планирование спринта:

-Запросы на выполнение работ определяются на этапе совета по планированию спринта – sprint planning meeting.

-На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены.

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

Выполнение спринта:

Во время спринта команда выполняет определенный фиксированный список заданий - backlog items, наращивая функциональность программного продукта.

На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать, как заморозку требований (requirements) во время спринта.

Руководство проектом

Руководство проектом определяет сущность процесса разработки от его начала до конца. Оно обеспечивает :

Основная задача планирования – определение структуры распределения работ.

Типовая структура распределения работ включает:

-системный анализ

-анализ требований

-предварительное проектирование

-детальное проектирование

-разработку модулей

-тестирование интеграции

-аттестацию продукта

Границы времени выполнения

Распараллеливание задач требует согласования процессов их выполнения во времени. Для каждой из них должно быть запланировано приемлемое время решения Tproc, а также раннее Tmin и позднее Tmax время начала решения.

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

Рекомендуемое распределение времени выполнения проекта:

-на анализ и проектирование 40% временных затрат (из них 5% на анализ и планирование)

-на кодирование – 20%

-на тестирование и отладку – 40%

Оценки, меры и метрики

Для оценки различных свойств процесса создания программного продукта, а также и самого продукта, применяются количественные характеристики, называемые мерами.

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

Основаны на LOC-оценках, т.е. на количестве строк в текстах программ (Lines Of Code).

К числу размерно-ориентированных метрик относятся:

-производительность(Производительность = Длина [тыс. LOC]/Затраты [чел.-мес.])

-качество(Качество = Ошибки [Единиц]/Длина [тыс. LOC])

-удельная стоимость(Удельная Стоимость = Стоимость [Тыс. руб.]/Длина [LOC])

-документированность(Документированность = Страниц Документа/Длина [тыс. LOC])

Достоинтства:

-основаны на объективных данных;

-просты и легко вычислимы;

Недостатки:

-зависят от языка программирования;

-трудновыполнимы на начальной стадии проекта;

-не приспособлены к непроцедурным языкам программирования.