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

1. Жизненный цикл и модели разработки ПО

2. Жизненный цикл программного обеспечения

Стратегия проектирования ИС определяется использованием
соответствующей модели жизненного цикла, определяющей
последовательность стадий проектирования и выполняемых в них
процессов.
Жизненный цикл ИС - ряд событий, происходящих с системой в процессе
ее создания и использования.
Модель жизненного цикла - структура, содержащая стадии, процессы
(действия и задачи), которые осуществляются в ходе разработки,
функционирования и сопровождения программного продукта в течение всей
жизни системы, от определения требований до завершения ее использования.
2

3.

Стадии ЖЦ – отражают состояния ИС и их изменения;
Этапы ЖЦ – входят в состав стадий; предполагают выполнение
определенного объема работ в течение ограниченного времени;
Процессы ЖЦ - отражают те действия, которые должны обязательно
выполняться для эффективного проектирования ИС; определяются как
совокупность взаимосвязанных действий, преобразующих входные данные в
выходные; одни и те же процессы могут выполняться на различных стадиях
(этапах) ЖЦ.
3

4.

Жизненный̆ цикл тестирования
4

5.

Стадия 1 (общее планирование и анализ требований) объективно необходима, как минимум, для того,
чтобы иметь ответ на такие вопросы, как: что нам предстоит тестировать; как много будет работы; какие
есть сложности; всё ли необходимое у нас есть и т.п. Как правило, получить ответы на эти вопросы
невозможно без анализа требований, т.к. именно требования являются первичным источником ответов.
Стадия 2 (уточнение критериев приёмки) позволяет сформулировать или уточнить метрики и
признаки возможности или необходимости начала тестирования, приостановки и возобновления
тестирования, завершения или прекращения тестирования.
Стадия 3 (уточнение стратегии тестирования) представляет собой̆ ещё одно обращение к
планированию, но уже на локальном уровне: рассматриваются и уточняются те части стратегии
тестирования, которые актуальны для текущей итерации.
5

6.

Стадия 4 (разработка тест-кейсов) посвящена разработке, пересмотру, уточнению, доработке,
переработке и прочим действиям с тест-кейсами, наборами тест-кейсов, тестовыми сценариями и иными
артефактами, которые будут использоваться при непосредственном выполнении тестирования.
Стадия 5 (выполнение тест-кейсов) и стадия 6 (фиксация найденных дефектов) тесно связаны между
собой и фактически выполняются параллельно: дефекты фиксируются сразу по факту их обнаружения в
процессе выполнения тест-кейсов. Однако зачастую после выполнения всех тест-кейсов и написания всех
отчётов о найденных дефектах проводится явно выделенная стадия уточнения, на которой все отчёты о
дефектах рассматриваются повторно с целью формирования единого понимания проблемы и уточнения
таких характеристик дефекта, как важность и срочность.
Стадия 7 (анализ результатов тестирования) и стадия 8 (отчётность) также тесно связаны между
собой и выполняются практически параллельно. Формулируемые на стадии анализа результатов выводы
напрямую зависят от плана тестирования, критериев приёмки и уточнённой стратегии, полученных на
стадиях 1, 2 и 3. Полученные выводы оформляются на стадии 8 и служат основой для стадий 1, 2 и 3
следующей итерации тестирования. Таким образом, цикл замыкается.
6

7. Процессы ЖЦ

1. Основные процессы, реализующиеся под управлением основных сторон,
участвующих в жизненном цикле программных средств.
Основные стороны: заказчик, поставщик, разработчик.
1) Заказ - определение потребностей заказчика, выбор поставщика и
управление процессов заказов.
2) Поставка - определение работ и задач поставщика.
3) Разработка
❖ Подготовка процессов разработки
❖ Анализ требований к системе
❖ Проектирование системной архитектуры
❖ Анализ требований к ПО
❖…
7

8.

❖…
❖ Проектирование программной архитектуры.
❖ Техническое проектирование ПО.
❖ Программирование и тестирование ПО.
❖ Сборка ПО.
❖ Квалификационные испытания.
❖ Ввод в действие.
❖ Обеспечение приемки.
4) Эксплуатация - использование ПО и поддержка пользователей.
+Сопровождение (модификация ПО)
8

9.

2. Вспомогательные процессы жизненного цикла. Предназначены для
обеспечения успешной реализации и качества выполнения проекта.
1) Документирование.
2) Процесс управления конфигурацией.
3) Процесс обеспечения качества.
4) Аудит.
5) Процесс решения проблем.
3. Организационные- процессы, направленные на персонал.
1) Управление.
2) Усовершенствование.
3) Обучение.
9

10. Виды деятельности

Обобщенный базис процессов для программной инженерии включает пять
видов основной деятельности:
1.
Подготовка.
2. Планирование.
3. Моделирование.
4. Конструирование.
5. Развертывание.
10

11. Стадии ЖЦ в некоторых стандартах

ISO/IEC 12207
ISO/IEC 15288
Методика Oracle CDM
ГОСТ 34
Формирование
требований к ПО
Формирование
концепции
Определение
требований
ФТ - Формирование
требований к АС
Проектирование
Разработка
Анализ
РК - Разработка
концепции АС
Реализация
Реализация
Проектирование
ТЗ - Техническое
задание на АС
Тестирование
Эксплуатация
Реализация
ЭП - Эскизный проект
Ввод в действие
Поддержка
Внедрение
ТП - Технический
проект
Эксплуатация и
сопровождение
Снятие с эксплуатации
Эксплуатация
РД - Рабочая
документация
Снятие с эксплуатации
ВД - Ввод в действие
Сп - Сопровождение АС
11

12. Методика Oracle CDM

❖ RD - Определение
производственных
требований,
❖ CV - Конвертирование
данных,
❖ ES - Исследование
существующих систем,
❖ TE - Тестирование,
❖ TA - Определение
технической архитектуры,
❖ DB - Проектирование и
построение БД,
❖ DO - Документирование,
❖ TR - Обучение,
❖ TS - Переход к новой системе,
❖ PS - Поддержка и
сопровождение.
❖ MD - Проектирование и
реализация модулей,
12

13. Модель и методология создания ПО

Модель разработки программного обеспечения описывает, какие стадии
жизненного цикла оно проходит и что происходит на каждой из них.
Методология включает в себя набор методов по управлению разработкой:
это правила, техники и принципы, которые делают её более эффективной.
13

14. Модели разработки

В настоящее время наиболее часто используются:
1.
Code and fix — модель кодирования и устранения ошибок;
2. Waterfall Model — каскадная модель, или «водопад»;
3. V-model — V-образная модель, разработка через тестирование;
4. Incremental Model — инкрементная модель;
5. Iterative Model — итеративная (или итерационная) модель;
6. Spiral Model — спиральная модель;
7.
Chaos model — модель хаоса;
8. Prototype Model — прототипная модель.
Из этих моделей наиболее популярны пять основных: каскадная, Vобразная, инкрементная, итерационная и спиральная.
14

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

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

16. Преимущества каскадной модели

❖ Разработку просто контролировать. Заказчик всегда знает,
чем сейчас заняты программисты, может управлять сроками
и стоимостью.
❖ Стоимость проекта определяется на начальном этапе. Все
шаги запланированы уже на этапе согласования договора, ПО
пишется непрерывно «от и до».
❖ Не нужно нанимать тестировщиков с серьёзной технической
подготовкой. Тестировщики смогут опираться на подробную
техническую документацию.
16

17. Недостатки каскадной модели

❖ Тестирование начинается на последних этапах разработки.
Если в требованиях к продукту была допущена ошибка, то
исправить её будет стоить дорого. Тестировщики обнаружат её,
когда разработчик уже написал код, а технические писатели —
документацию.
❖ Заказчик видит готовый продукт в конце разработки и только
тогда может дать обратную связь. Велика вероятность, что
результат его не устроит.
❖ Разработчики пишут много технической документации, что
задерживает работы. Чем обширнее документация у проекта,
тем больше изменений нужно вносить и дольше их
согласовывать.
17

18. Когда использовать каскадную методологию?

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

19. V-образная модель (разработка через тестирование)

V-модель – вариация каскадной модели,
в которой задачи разработки идут сверху
вниз по левой стороне буквы V, а задачи
тестирования – вверх по правой стороне
буквы V. Внутри V проводятся
горизонтальные линии, показывающие,
как результаты каждой из стадий
разработки влияют на развитие системы
тестирования на каждой из стадий
тестирования.
Модель базируется на том, что приемосдаточные испытания основываются,
прежде всего, на требованиях, системное
тестирование – на требованиях и
архитектуре, комплексное тестирование –
на требованиях, архитектуре и
интерфейсах, а компонентное
тестирование – на требованиях,
архитектуре, интерфейсах и алгоритмах.
19

20. Преимущества и недостатки V-образной модели

Преимущества
Недостатки
Количество ошибок в
архитектуре ПО сводится к
минимуму.
Если при разработке
архитектуры была допущена
ошибка, то вернуться и
исправить её будет стоить
дорого, как и в «водопаде»
20

21. Когда использовать V-модель?

❖ Если требуется тщательное тестирование продукта, то Vмодель оправдает заложенную в себя идею: validation and
verification.
❖ Для малых и средних проектов, где требования четко
определены и фиксированы.
❖ В условиях доступности инженеров необходимой
квалификации, особенно тестировщиков.
21

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

Итеративная (итерационная) модель предполагает разбиение жизненного
цикла проекта на последовательность итераций, каждая из которых напоминает
«мини-проект», включая все фазы жизненного цикла в применении к созданию
меньших фрагментов функциональности, по сравнению с проектом, в целом.
Цель каждой итерации – получение работающей версии программной системы,
включающей функциональность, определенную интегрированным содержанием
всех предыдущих и текущей итерации. Результата финальной итерации содержит
всю требуемую функциональность продукта.
22

23. Преимущества итеративной модели

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

24. Недостатки итеративной модели

❖ Использование на начальном этапе баз данных или серверов
— первые сложно масштабировать, а вторые не выдерживают
нагрузку. Возможно, придётся переписывать большую часть
приложения.
❖ Отсутствие фиксированного бюджета и сроков. Заказчик не
знает, как выглядит конечная цель и когда закончится
разработка.
24

25. Когда использовать итеративную модель?

❖ Требования к конечной системе заранее четко определены и
понятны.
❖ Проект большой или очень большой.
❖ Основная задача должна быть определена, но детали
реализации могут эволюционировать с течением времени.
25

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

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

27. Преимущества инкрементной модели

❖ Не нужно вкладывать много денег на начальном этапе. Заказчик
оплачивает создание основных функций, получает продукт, «выкатывает»
его на рынок — и по итогам обратной связи решает, продолжать ли
разработку.
❖ Можно быстро получить фидбэк от пользователей и оперативно обновить
техническое задание. Так снижается риск создать продукт, который никому
не нужен.
❖ Ошибка обходится дешевле. Если при разработке архитектуры была
допущена ошибка, то исправить её будет стоить не так дорого, как в
«водопаде» или V-образной модели.
27

28. Недостатки инкрементной модели

❖ Каждая команда программистов разрабатывает свою функциональность и
может реализовать интерфейс продукта по-своему. Чтобы этого не
произошло, важно на этапе обсуждения техзадания объяснить, каким он
будет, чтобы у всех участников проекта сложилось единое понимание.
❖ Разработчики могут оттягивать доработку основной функциональности и
заниматься второстепенными задачами. Чтобы этого не случилось,
менеджер проекта должен контролировать, чем занимается каждая
команда.
28

29. Когда использовать инкрементную модель?

❖ Когда основные требования к системе четко определены и
понятны. В то же время некоторые детали могут
дорабатываться с течением времени.
❖ Требуется ранний вывод продукта на рынок.
❖ Есть несколько рисковых фич или целей.
29

30. Разница между итерационной и инкрементной моделями

30

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

Спиральная модель – на каждом
витке спирали:
1.
выполняется создание очередной
версии продукта,
2.
уточняются требования проекта,
3.
определяется его качество,
4.
планируются работы следующего
витка.
Особое внимание уделяется
начальным этапам разработки –
анализу и проектированию, где
реализуемость тех или иных
технических решений проверяется и
обосновывается посредством
создания прототипов
(макетирования).
31

32. Преимущества и недостатки спиральной модели

Преимущества
Недостатки
Большое внимание уделяется
проработке рисков.
❖ Есть риск застрять на
начальном этапе —
бесконечно
совершенствовать первую
версию продукта и не
продвинуться к
следующим.
❖ Разработка длится долго и
стоит дорого.
32

33. Когда использовать спиральную модель?

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