Экстремальное программирование
Наиболее часто используемой адаптивной моделью является модель экстремального программирования (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])
Достоинтства:
-основаны на объективных данных;
-просты и легко вычислимы;
Недостатки:
-зависят от языка программирования;
-трудновыполнимы на начальной стадии проекта;
-не приспособлены к непроцедурным языкам программирования.
Дата добавления: 2018-05-13; просмотров: 417; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!