Спиральная модель процесса разработки, ее характеристика.

· Предложена в 1988 г. Барри Боэмом (Barry W. Boehm) и является классическим примером реализации эволюционной стратегии.

· Модель определяет четыре действия:

- -планирование(заключается в определении целей очередной итерации процесса разработки, выборе вариантов решения и оценки ограничений)

- -анализ рисков(анализ вариантов решения и оценка связанных с ними рисков, т.е. возможностей получения неудовлетворительных результатов)

- -конструирование(это основное действие, заключающееся в создании следующей версии ПО)

- -оценивание(оценка заказчиком качества очередной версии ПО, внесение им предложений по модификации продукта, корректировка требований)

Характеристика модели

· Достоинства модели:

- -данная модель отображает процесс разработки ПО в наиболее реальном виде;

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

· Недостатки модели:

- -повышенные требования к заказчику;

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

16. Прогностические и адаптивные процессы разработки программных средств. Методология экстремального программирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

XP-процесс

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

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

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

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

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

Принципы XP

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

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

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

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

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

Практики XP

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

Прогностические и адаптивные процессы разработки программных средств. Scrum-модель процесса разработки.

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

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

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

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

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

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

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

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

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

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

Scrum-модель

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

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

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

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

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

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

Роли

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планирование процесса разработки

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

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

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

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

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

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

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

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