Адаптивный подход как альтернатива традиционным методологиям разработки ПО

Содержание

Слайд 2

Причины использования методологий разработка программного обеспечения представляет собой хаотическую деятельность; единого

Причины использования методологий

разработка программного обеспечения представляет собой хаотическую деятельность;
единого плана не

существует;
общий проект - смесь краткосрочных решений;
неконтролируемый рост числа ошибок при увеличении размеров проекта;
увеличение тестового периода;
как следствие вышеперечисленных проблем - нарушение плана выпуска программы.
Слайд 3

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

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

создание программного продукта - упорядоченный процесс;
работа

программистов - прогнозируема и эффективна;
детальное описание процесса создания системы – подробное планирование.

Преимущества:

Недостатки:

следование методологии в процессе разработки приводит к затягиванию и загромождению всего процесса;
выполнение всех предписаний не всегда бывает возможным;
большой объем документации может «отвлечь» от основной цели - рабочий код.

Слайд 4

Особенности, учитываемые альтернативным подходом ИЗМЕНЯЮЩИЕСЯ ТРЕБОВАНИЯ К СОЗДАВАЕМОМУ ПО НЕПРЕДСКАЗУЕМОСТЬ ТРЕБОВАНИЙ

Особенности, учитываемые альтернативным подходом

ИЗМЕНЯЮЩИЕСЯ ТРЕБОВАНИЯ К СОЗДАВАЕМОМУ ПО

НЕПРЕДСКАЗУЕМОСТЬ ТРЕБОВАНИЙ

УПРАВЛЕНИЕ НЕПРЕДСКАЗУЕМЫМИ ПРОЦЕССАМИ

итеративность

адаптивность

ЛЮДИ

ориентированность

процессов на человека

роль бизнес-консультантов

АДАПТАЦИЯ АДАПТИВНОГО ПРОЦЕССА

Слайд 5

Сравнение традиционного и адаптивного подходов к разработке ПО

Сравнение традиционного и адаптивного подходов к разработке ПО

Слайд 6

Методологии (1)

Методологии (1)

Слайд 7

Методологии (1)

Методологии (1)

Слайд 8

Когда следует использовать адаптивный подход? а) команда разработчиков невелика (до 50

Когда следует использовать адаптивный подход?

а) команда разработчиков невелика (до 50 человек);
б)

требования к системе не определены или подвержены частым изменениям;
в) разработчики обладают высокой квалификацией и ответственностью;
г) заказчик готов «плотно» участвовать в процессе разработки;
Предсказуемый подход используется, когда:
а) команда разработчиков более 50 человек;
б) контракт с фиксированным объёмом работ (или с фиксированной стоимостью).
Слайд 9

Принципиальные концепции создания ИС в рамках RUP Итерационная разработка Управление требованиями

Принципиальные концепции создания ИС в рамках RUP

Итерационная разработка

Управление требованиями

Использование компонентной архитектуры

Визуальное

моделирование

Тестирование качества

Контроль за изменениями

Слайд 10

Средства поддержки основных практик RUP Управление требованиями - Requisite Pro Визуальное

Средства поддержки основных практик RUP

Управление требованиями - Requisite Pro

Визуальное моделирование -

Rational Rose

Тестирование качества продукта - Rational Purify, Rational PureCoverage, Rational Quantify, Rational Robot

Отслеживание изменений - Rational ClearCase, Rational ClearQuest