Модели ЖЦ

1.

Модели ЖЦ

2.

Каскадная модель

3.

Характерные особенности
каскадной модели ЖЦ ПО
Особенность:
• переход на следующий этап осуществляется только после полного
завершения предыдущего.
Достоинства:
• На каждом этапе формируется законченный комплект документации
• Модель позволяет планировать сроки разработки.
Недостатки:
• Запаздывание с получением результатов
• Невозможность изменения требований в ходе разработки
Рекомендации по использованию:
модель эффективна, если все требования можно определить в начале
разработки.

4.

V модель

5.

6.

Характерные особенности
спиральной модели ЖЦ ПО
Особенность : каждый виток соответствует поэтапной модели создания версии
программного продукта (ПП). Версии отличаются друг от друга качеством.
Достоинства:
• Последовательно корректируются детали проекта, и выбирается обоснованная
версия.
• Происходит накапливание версий (создается задел разработчика)
• Совершенствование программного продукта происходит в процессе его создания.
Недостаток:
• Сложно определить момент перехода на следующий этап.
• Необходимость введения временных ограничений на каждый этап разработки.

7.

• Модель ЖЦ ПО выбирается в
зависимости от типа разрабатываемой
системы, ресурсов разработчика и
ограничений по стоимости и времени
разработки

8.

«Agile Model» (гибкая методология
разработки)

9.

Основные ценности
• Люди и взаимодействие важнее процессов и
инструментов
• Работающий продукт важнее исчерпывающей
документации
• Сотрудничество с заказчиком важнее
согласования условий контракта
• Готовность к изменениям важнее следования
первоначальному плану
То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.

10.

Основополагающие принципы
Agile-манифеста
1. Наивысшим приоритетом для нас является
удовлетворение потребностей заказчика,
благодаря регулярной и ранней поставке ценного
программного обеспечения.
2. Изменение требований приветствуется, даже на
поздних стадиях разработки.
Agile-процессы позволяют использовать
изменения для обеспечения заказчику
конкурентного преимущества.
3. Работающий продукт следует выпускать как
можно чаще, с периодичностью от пары недель
до пары месяцев.

11.

4. На протяжении всего проекта разработчики и
представители бизнеса должны
ежедневно работать вместе.
5. Над проектом должны работать
мотивированные профессионалы. Чтобы
работа была сделана, создайте условия,
обеспечьте поддержку и полностью
доверьтесь им.

12.

6. Непосредственное общение является наиболее
практичным и эффективным
способом обмена информацией как с самой
командой, так и внутри команды.
7. Работающий продукт — основной показатель
прогресса.
8. Инвесторы, разработчики и пользователи должны
иметь возможность
поддерживать постоянный ритм бесконечно. Agile
помогает наладить такой
устойчивый процесс разработки.

13.

9. Постоянное внимание к техническому
совершенству и качеству
проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней
работы — крайне необходима.
11. Самые лучшие требования, архитектурные и
технические решения рождаются
у самоорганизующихся команд.
12. Команда должна систематически
анализировать возможные способы
улучшения эффективности и соответственно
корректировать
стиль своей работы.

14.

15.

• ХР
• SCRUM
• Kunban