Слайд 2
МОДЕЛЬ ЖЦ ПП -
Общая структура, определяющая последовательность
выполнения и взаимосвязи процессов, действий и задач, выполняемых в
течение ЖЦ.
Другими словами, модель ЖЦ ПП – это последовательность действий, выполнение которых является необходимым условием для создания ПП, соответствующего заданным требованиям.
Слайд 3
СТРАТЕГИИ РАЗРАБОТКИ
Линейная
Итерационная
Этапы разработки реализуются последовательно друг за другом
Система
строится в виде последовательности версий, каждая из которых дополняет
предыдущую
Слайд 4
ОБЗОР СОВРЕМЕННЫХ МОДЕЛЕЙ:
Линейная стртегия
Каскадная модель
Прямолинейная и простая в
использовании. Разрабатываемое программное обеспечение не доступно для изменений
V-образная модель
Простая
в использовании. Особое значение придается тестированию и сравнению результатов фаз тестирования и проектирования
Итерационная стратегия
Спиральная модель
Требования определяются не полностью, дополняются и реализуются на каждом витке спирали
Модель прототипирования
Создается «быстрая» частичная реализация системы до составления окончательных требований.
Модель быстрой разработки приложений
Проектные группы небольшие и составлены из высококвалифицированных специалистов. Уменьшенное время цикла разработки (до 3 мес) и улучшенная производительность.
Слайд 5
КАСКАДНАЯ МОДЕЛЬ ИЛИ МОДЕЛЬ ВОДОПАДА
(Waterfall model)
Слайд 6
Структура каскадной модели имеет вид:
Слайд 7
ОСОБЕННОСТИ КАСКАДНОЙ МОДЕЛИ:
Переход на следующий этап осуществляется только
после завершения всех работ на предыдущем этапе, и возвратов
на пройденные этапы не предусматривается.
Каждый этап завершается получением некоторых результатов, которые являются исходными для следующего этапа.
Требования к ПП, определённые на этапе формирования требований, документируются в виде Технического задания (ТЗ) и фиксируются на всё время разработки.
Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка была продолжена другой командой разработчиков.
Критерием качества разработки является точность выполнения спецификаций (требований) ТЗ.
Слайд 8
ПРЕИМУЩЕСТВА КАСКАДНОЙ МОДЕЛИ:
На каждой стадии формируется законченный набор
проектной документации;
Выполненные в логичной последовательности стадии работ позволяют планировать
сроки завершения всех работ и соответствующие затраты.
Слайд 9
Недостатки каскадной модели обусловлены, прежде всего, тем, что
реальный процесс разработки ПП никогда не укладывается в такую
жёсткую схему.
В результате реальный
процесс разработки
имеет вид:
Слайд 10
Недостатки каскадной модели:
Позднее тестирование, приводящее к существенным затратам
на отладку ПП.
Позднее согласование результатов работы с заказчиком, вследствие
чего повышается риск его неудовлетворённости ПП.
Слайд 11
V – ОБРАЗНАЯ МОДЕЛЬ
V – shaped model
Слайд 12
V – ОБРАЗНАЯ МОДЕЛЬ -
разновидность каскадной модели,
в которой особое внимание уделяется верификации и аттестации ПП.
Модель
показывает, что тестирование продукта обсуждается, проектируется и планируется, начиная с ранних этапов ЖЦ разработки.
Слайд 13
Структура V – образной модели имеет вид:
Слайд 14
ПРЕИМУЩЕСТВА V – ОБРАЗНОЙ МОДЕЛИ:
1. Большая роль уделяется
верификации и аттестации ПП, начиная с ранних стадий его
разработки, все действия планируются;
2. Предполагается верификация не только самого ПП, но и всех полученных внутренних и внешних данных;
3. Ход выполнения работ легко отслеживается, т.к. переход на следующий этап осуществляется только после завершения всех работ на предыдущем.
Слайд 15
НЕДОСТАТКИ V – ОБРАЗНОЙ МОДЕЛИ:
Не учитываются итерации между
фазами;
Нельзя вносить изменения на разных этапах ЖЦ;
Тестирование требований происходит
слишком поздно, поэтому внесение изменений влияет на выполнение графика работ.
Слайд 16
V – образную модель используют при разработке ПП,
главным требованиям для которых является высокая надёжность.
Слайд 17
СПИРАЛЬНАЯ МОДЕЛЬ.
Spiral model
Автор – Барри Боэм
Слайд 18
Спиральная модель — классический пример применения итерационной стратегии
конструирования, когда система строится в виде последовательности версий.
Требования к
ПП в начале процесса определяются не полностью и уточняются в результате работы над продуктом.
Слайд 19
СТРУКТУРА СПИРАЛЬНОЙ МОДЕЛИ:
Спиральная модель: 1 — начальный сбор
требований и планирование проекта; 2 — та же работа,
но на основе рекомендаций заказчика; 3 — анализ риска на основе начальных требований; 4 — анализ риска на основе реакции заказчика; 5 — переход к комплексной системе; 6 — начальный макет системы; 7 — следующий уровень макета; 8 — сконструированная система; 9 — оценивание заказчиком.
Слайд 20
ПРИНЦИПИАЛЬНЫЕ ОСОБЕННОСТИ СПИРАЛЬНОЙ МОДЕЛИ:
Отказ от фиксации требований и
назначение приоритетов пользовательским требованиям;
Разработка последовательности прототипов, начиная с требований
наивысшего приоритета;
Идентификация и анализ риска на каждой итерации;
Использование каскадной модели для реализации окончательного прототипа;
Оценка результатов по завершении каждой итерации и планирование следующей итерации.
Слайд 21
Таким образом, спиральная модель определяет 4 основных действия
(записаны в 4-х квадрантах спирали):
Планирование – определение целей и
требований;
Анализ риска – анализ вариантов на целесообразность продолжения работы над проектом.
Конструирование – разработка ПП следующего уровня;
Оценивание – оценка заказчиком текущих результатов конструирования.
Слайд 22
ПРИНЦИП РАБОТЫ СПИРАЛЬНОЙ МОДЕЛИ:
С каждой итерацией по спирали
(продвижением от центра к периферии) строятся всё более полные
версии ПП.
В первом витке определяются начальные цели и требования. Выполняется анализ риска, на основе которого принимается решение о разработке ПП (если риск велик, проект может быть остановлен). Заказчик оценивает промежуточную работу и вносит предложения по модификации.
Следующая фаза планирования и анализа риска базируется на предложениях заказчика.
Движение по спирали продолжается до тех пор, пока следующая версия ПП полностью не удовлетворит потребности заказчика.
Слайд 23
ДОСТОИНСТВА СПИРАЛЬНОЙ МОДЕЛИ:
Наиболее реально (в виде эволюции) отражает
разработку ПП;
Ускорение разработки (раннее получение результатов за счёт прототипирования)
Постоянное
участие заказчика в процессе разработки
Разбиение большого объёма работы на небольшие части
Учёт риска на каждом витке спирали;
Слайд 24
НЕДОСТАТКИ СПИРАЛЬНОЙ МОДЕЛИ:
Трудность приведения проекта к конечному результату
Сложность
планирования (определения количества и длительности итераций, оценки затрат и
рисков)
Сложность применения модели с точки зрения менеджера и заказчиков (из – за привычки к строгому и детальному планированию)
Напряжённый режим работы для разработчиков (при краткосрочных итерациях)
Повышенные требования к заказчику;
Слайд 25
МОДЕЛЬ БЫСТРОЙ РАЗРАБОТКИ ПРИЛОЖЕНИЙ.
RAD – модель
(RAD –
Rapid Application Development);
Слайд 26
RAD – МОДЕЛЬ -
второй пример применения
итерационной стратегии конструирования, основанный на 3-х составляющих:
Небольшая группа разработчиков
(7+-2 человека)
Короткий, но тщательно разработанный производственный график (до трёх месяцев)
Повторяющийся цикл, при котором разработчики по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные в результате взаимодействия с заказчиком.
Слайд 28
БАЗОВЫЕ ПРИНЦИПЫ RAD:
Разработка приложений итерациями
Необязательность полного завершения работ
на каждой стадии ЖЦ
Обязательность вовлечения пользователей в процесс разработки
Применения
средств управления конфигурациями и средств автоматизированной разработки, проектирования и документирования приложений (CASE - средств)
Тестирование и развитие проекта, осуществляемой одновременно с разработкой
Ведение разработки небольшой, хорошо управляемой командой профессионалов
Грамотное руководство разработкой системы, чёткое планирование и контроль выполняемых работ.
Слайд 29
УСЛОВИЯ ПРИМЕНЕНИЯ МЕТОДОЛОГИИ RAD:
применима для относительно небольших проектов,
разрабатываемых под конкретного заказчика;
неприменима для построения сложных расчетных программ,
требующих написания большого объема (сотни тысяч строк) уникального кода (например, операционных систем или программ управления космическими кораблями);
неприменима для разработки приложений, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий, скорее всего не будут полностью работоспособны, что в данном случае исключается.