Модели разработки ПО

1. Модели разработки ПО

Программная инженерия
Lecture 2

2. План

Жизненный цикл ПО
Каскадный подход
Поэтапный подход
Компонентно-ориентированный подход

3. Жизненный цикл ПО

ЖЗ ПО – это набор действий и
связанных с ними результатов,
направленных на разработку и/или
развитие программного продукта:
Спецификация требований
Разработка
Валидация (тестирование конформности)
Развитие
Для любого проекта подбирается свой
процесс разработки, нет универсального

4. Модель процесса разработки ПО

Модель процесса разработки ПО – это
абстрактная репрезентация процесса
разработки ПО, представляющая
данный процесс в определенной
перспективе
Модель не является всеобъемлющее им
описанием процесса разработки ПО

5. Типы моделей разработки ПО

Каскадный подход
Водопадная
V-модель
Поэтапный подход
Итерационная
Инкрементная
Спиральная
Гибкие
Часто эти модели
объединяются в
рамках одного
проекта
(подсистемы могут
создаваться
посредством
различных
подходов)
Компонентно-ориентированный подход

6. Водопадная модель

7. Водопадная модель: фазы

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

8. V-модель

9. V-модель

Применима к системам, которым
особенно важно бесперебойное
функционирование
Направлена на тщательную проверку
и тестирование продукта, находящегося
уже на первоначальных стадиях
проектирования
Стадия тестирования проводится
одновременно с соответствующей
стадией разработки

10. Каскадный подход

Достоинства:
Очень формализованная, в результате каждой
фазы формируется утвержденный документ
Соответствует стандартным моделям
инженерной разработки
Недостатки:
Отсутствие гибкости
Все договоренности – на ранней стадии, нет
возможности подстроиться под изменяющиеся
требования пользователя

11. Инкрементная модель

12. Инкрементная модель

«Мульти-водопад»
Цикл разделен на более мелкие легко
создаваемые модули. Каждый модуль
проходит через фазы определения
требований, проектирования, кодирования,
внедрения и тестирования.
Выпуск на первом большом этапе продукта
в базовой функциональности, а затем уже
последовательное добавление новых
функций (инкрементов)

13. Итерационная модель

14. Итерационная модель

Не требует для начала полной
спецификации требований
Создание начинается с реализации
части функционала, становящейся
базой для определения дальнейших
требований
Каждая версия – работоспособна

15. Спиральная модель

16. Спиральная модель

Основное отличие спиральной
разработки от других методов – явная
оценка рисков
Риск – это вероятность того, что что-то
может пойти не так как хотелось бы
Применяется для критически важных
бизнес-задач, когда неудача
недопустима

17. Гибкие модели (Agile)

18. Гибкие модели

В основе – непродолжительные
ежедневные встречи (scrum) и регулярно
повторяющиеся собрания (meet-up)
После каждой итерации заказчик может
наблюдать результат и понимать,
удовлетворяет он его или нет
Из-за отсутствия конкретных
формулировок результатов сложно
оценить трудозатраты и стоимость
разработки

19. Компонентно-ориентированный подход

Компонентноориентированный подход
Основывается на повторном
использовании кода
Программный компонент – это
автономный элемент программного
обеспечения, предназначенный для
многократного использования, который
может распространяться для
использования в других программах в
виде скомпилированного кода

20. Компонентно-ориентированный подход

Компонентноориентированный подход
Развитие объектно-ориентированного
подхода, для проектирования и реализации
крупных и распределенных программных
систем
Программная система – это набор
компонентов с четко определенным
интерфейсом
Изменения в систему вносятся путем создания
новых компонентов или изменения старых
Наследование реализации запрещено.
Наследуется только интерфейс

21. Компонентно-ориентированный подход

Компонентноориентированный подход
Достоинства
Уменьшается уменьшаются цена и риски
Уменьшается время разработки
Недостатки
Реальные требования пользователей не будут
учтены
Контроль над системой может быть потерян при
появлении новых версий используемых
компонентов

22. Что выбрать?

23. Формализм vs Общение

24. Формализм vs Общение

25. Формализм vs Общение

26. Формализм vs Общение

27. Формализм vs Общение

28. Формализм vs Общение

Масштаб проекта: чем крупнее проект, тем более формальный
подход необходим
Критичность проекта: если цена ошибки высока, необходимо
применять более формальные модели разработки
Распределение участников: чем компактнее расположены
участники разработки, тем менее формально можно подходить к
разработке системы
Новизна проекта: чем более новые технологии и задачи стоят
перед командой, тем больше нужно формализма
Требования заказчика: если заказчик – гос. учреждение, то он,
скорее всего, будет требовать более формальный подход
Ожидаемая долговечность проекта: чем дольше
предполагается срок жизни системы, тем более формальный
подход к разработке необходимо применить

29. Итоги

Каскадная разработка:
самая первая
самая формальная
Поэтапная разработка:
самая гибкая
результат – после первой итерации
Компонентно-ориентированная разработка:
повторное использование кода
ускоренная разработка

30. Вопросы для самостоятельного изучения

Scrum
XP
Kanban
Crystal Clear
TDD
FDD