Слайд 2Оглавление
Программное обеспечение (ПО);
Жизненный цикл ПО;
Модель жизненного цикла ПО;
Каскадная модель (водопад);
V-образная модель;
Инкрементная модель;
Спиральная
![Оглавление Программное обеспечение (ПО); Жизненный цикл ПО; Модель жизненного цикла ПО; Каскадная](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-1.jpg)
модель;
Гибкая модель;
Скрам;
Итерационная модель;
Модель хаоса;
Модель быстрой разработки RAD;
Заключение.
Слайд 3Программное обеспечение
Программное обеспечение (ПО) — программа или множество программ, используемых для управления
![Программное обеспечение Программное обеспечение (ПО) — программа или множество программ, используемых для управления компьютером.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-2.jpg)
компьютером.
Слайд 4Жизненный цикл ПО
Жизненный цикл программного обеспечения — это период времени, который начинается с
![Жизненный цикл ПО Жизненный цикл программного обеспечения — это период времени, который](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-3.jpg)
момента принятия решения о создании программного продукта и заканчивается в момент его полного изъятия из эксплуатации.
Слайд 5Модель жизненного цикла ПО
Модель жизненного цикла ПО — структура, содержащая процессы действия и
![Модель жизненного цикла ПО Модель жизненного цикла ПО — структура, содержащая процессы](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-4.jpg)
задачи, которые осуществляются в ходе разработки, использования и сопровождения программного продукта.
Слайд 7Каскадная модель (водопад)
Характерные черты каскадной модели:
завершение каждого этапа проверкой полученных результатов с
![Каскадная модель (водопад) Характерные черты каскадной модели: завершение каждого этапа проверкой полученных](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-6.jpg)
целью устранить как можно большее число проблем, связанных с разработкой изделия;
циклическое повторение пройденных этапов (как в классической модели).
Слайд 8Каскадная модель (водопад)
Плюсы
все стадии проекта выполняются в строгой последовательности;
строгость этапов позволяет планировать
![Каскадная модель (водопад) Плюсы все стадии проекта выполняются в строгой последовательности; строгость](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-7.jpg)
сроки завершения всех работ и соответствующие ресурсы (денежные и человеческие);
требования остаются неизменными в течение всего цикла.
Слайд 9Каскадная модель (водопад)
Минусы
сложности при формулировке четких требований и невозможность их изменения;
тестирование начинается
![Каскадная модель (водопад) Минусы сложности при формулировке четких требований и невозможность их](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-8.jpg)
только с середины развития проекта;
до завершения процесса разработки пользователи не могут убедиться, качествен ли разрабатываемый продукт.
Слайд 11V-образная модель
В этой модели особое значение придается действиям, направленным на верификацию и
![V-образная модель В этой модели особое значение придается действиям, направленным на верификацию](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-10.jpg)
аттестацию продукта. Она демонстрирует, что тестирование продукта обсуждается, проектируется и планируется на ранних этапах жизненного цикла разработки. Данная модель стала последователем каскадной модели, так как с ее помощью можно устранить недостатки, которые были ранее.
Слайд 12V-образная модель
Плюсы
строгая этапизация;
минимизация рисков и устранение потенциальных проблем за счет того, что
![V-образная модель Плюсы строгая этапизация; минимизация рисков и устранение потенциальных проблем за](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-11.jpg)
тестирование появляется на самых ранних стадиях;
усовершенствованный тайм-менеджмент.
Слайд 13V-образная модель
Минусы
невозможность адаптироваться к измененным требованиям заказчика;
длительное время разработки (иногда длится до
![V-образная модель Минусы невозможность адаптироваться к измененным требованиям заказчика; длительное время разработки](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-12.jpg)
нескольких лет) приводит к тому, что продукт может быть уже не нужен заказчику, поскольку его потребности меняются;
нет действий, направленных на анализ рисков.
Слайд 15Инкрементная модель
ПО разрабатывается с линейной последовательностью стадий, но в несколько инкрементов (версий).
![Инкрементная модель ПО разрабатывается с линейной последовательностью стадий, но в несколько инкрементов](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-14.jpg)
Таким образом улучшение продукта проходит запланированно все время, пока жизненный цикл разработки ПО не завершится.
Требования к системе определяются в самом начале работы, после чего процесс разработки проводится в виде последовательности версий, каждая из которых является законченным и работоспособным продуктом.
Слайд 16Инкрементная модель
Плюсы
заказчик может дать свой отзыв касательно каждой версии продукта;
есть возможность пересмотреть
![Инкрементная модель Плюсы заказчик может дать свой отзыв касательно каждой версии продукта;](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-15.jpg)
риски, которые связаны с затратами и соблюдением графика;
привыкание заказчика к новой технологии происходит постепенно.
Слайд 17Инкрементная модель
Минусы
функциональная система должна быть полностью определена в начале жизненного цикла для
![Инкрементная модель Минусы функциональная система должна быть полностью определена в начале жизненного](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-16.jpg)
выделения итераций;
при постоянных изменениях структура системы может быть нарушена;
сроки сдачи системы могут быть затянуты из-за ограниченности ресурсов (исполнители, финансы).
Слайд 19Спиральная модель
весь процесс создания конечного продукта представлен в виде условной плоскости, разбитой
![Спиральная модель весь процесс создания конечного продукта представлен в виде условной плоскости,](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-18.jpg)
на 4 сектора, каждый из которых представляет отдельные этапы его разработки;
на выходе из очередного витка мы должны получить готовый протестированный прототип;
прототип, удовлетворяющий всем требованиям – готов к релизу;
концентрация на возможных рисках.
Слайд 20Спиральная модель
Плюсы
управлению рисками уделяется особое внимание;
дополнительные функции могут быть добавлены на поздних
![Спиральная модель Плюсы управлению рисками уделяется особое внимание; дополнительные функции могут быть](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-19.jpg)
этапах;
есть возможность гибкого проектирования.
Слайд 21Спиральная модель
Минусы
оценка рисков на каждом этапе является довольно затратной;
постоянные отзывы и реакция
![Спиральная модель Минусы оценка рисков на каждом этапе является довольно затратной; постоянные](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-20.jpg)
заказчика может провоцировать все новые и новые итерации, которые могут приводить к временному затягиванию разработки продукта;
более применима для больших проектов.
Слайд 23Гибкая модель
Представляет собой совокупность различных подходов к разработке ПО.
Включает серии подходов
![Гибкая модель Представляет собой совокупность различных подходов к разработке ПО. Включает серии](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-22.jpg)
к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри рабочих групп.
Отдельная итерация представляет собой миниатюрный программный проект.
Слайд 24Гибкая модель
Плюсы
быстрое принятие решений за счет постоянных коммуникаций;
минимизация рисков;
облегченная работа с документацией.
![Гибкая модель Плюсы быстрое принятие решений за счет постоянных коммуникаций; минимизация рисков; облегченная работа с документацией.](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-23.jpg)
Слайд 25Гибкая модель
Минусы
большое количество митингов и бесед, что может увеличить время разработки продукта;
сложно
![Гибкая модель Минусы большое количество митингов и бесед, что может увеличить время](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-24.jpg)
планировать процессы, так как требования постоянно меняются;
редко используется для реализации больших проектов.
Слайд 27Скрам
Скрам – это гибкая модель разработки ПО, в которой делается акцент на
![Скрам Скрам – это гибкая модель разработки ПО, в которой делается акцент](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-26.jpg)
качественном контроле процесса разработки.
Роли в методологии позволяют четко распределить обязанности в процессе разработки.
Команда – это единое целое, в ней результаты оцениваются не по каждому отдельному участнику, а по тому, что получается в итоге у всех.
Спринты в данной методологии длятся от 1 до 4 недель. После каждого спринта команда предоставляет вариант законченного продукта.
Слайд 28Скрам
Плюсы
быстрая обратная связь от специалистов в разных сферах (дизайнеров, архитекторов, тестировщиков и
![Скрам Плюсы быстрая обратная связь от специалистов в разных сферах (дизайнеров, архитекторов,](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-27.jpg)
пр.);
благодаря вовлеченности тестировщика в работу происходит быстрое добавление нового функционала и быстрый запуск продукта с минимальными функциями;
самостоятельная и самоорганизованная команда.
Слайд 29Скрам
Минусы
некоторые люди, знающие продукт, становятся незаменимыми, так как документация не предоставляется в
![Скрам Минусы некоторые люди, знающие продукт, становятся незаменимыми, так как документация не](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-28.jpg)
процессе разработки;
невозможно спланировать точную дату завершения, так как всё уточняется по результатам предыдущего спринта;
заказчики не всегда могут понять суть данной методологии и необходимо потратить время на “ликбез”.
Слайд 31Итерационная модель
Итерационная модель предполагает разбиение проекта на части и прохождение этапов жизненного цикла
![Итерационная модель Итерационная модель предполагает разбиение проекта на части и прохождение этапов](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-30.jpg)
на каждом их них. Каждый этап является законченным сам по себе, совокупность этапов формирует конечный результат.
На каждой итерации мы работали с одним и тем же продуктом и в конце каждой итерации получали результат, которым можно пользоваться.
С каждым этапом разработка приближается к конечному желаемому результату или уточняются требования к результату по ходу разработки, и соответственно в любой момент текущая итерация может оказаться последней или очередной на пути к завершению.
Слайд 32Итерационная модель
Плюсы
позволяет бороться с неопределенностью, снимая ее этап за этапом, и проверять
![Итерационная модель Плюсы позволяет бороться с неопределенностью, снимая ее этап за этапом,](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-31.jpg)
правильность технического, маркетингового или любого другого решения на ранних стадиях;
снижает риски глобального провала и растраты всего бюджета, получение несинхронизированных ожиданий и ошибочного понимания процессов;
дает возможность завершения разработки в конце любой итерации.
Слайд 33Итерационная модель
Минусы
целостное понимание возможностей и ограничений проекта очень долгое время отсутствует;
при итерациях
![Итерационная модель Минусы целостное понимание возможностей и ограничений проекта очень долгое время](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-32.jpg)
приходится отбрасывать часть сделанной ранее работы;
добросовестность специалистов при выполнении работ снижается, над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже».
Слайд 35Модель хаоса
Основная идея этой модели заключается в том, что программный код представляет
![Модель хаоса Основная идея этой модели заключается в том, что программный код](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-34.jpg)
собой сложную интеграцию тысяч модулей, функций и строк кода. Этот хаос интеграции требует метода, который определяет интеграцию между всей программой и кодом, который определяет эту программу.
Слайд 36Модель хаоса
Плюсы
учитывает взаимодействие между членами команды при внесении изменений в код;
ограничивает риск
![Модель хаоса Плюсы учитывает взаимодействие между членами команды при внесении изменений в](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-35.jpg)
чрезмерного проектирования решения.
прозрачность между желаниями руководства высокого уровня и пониманием командой разработчиков проблем и приоритетов.
Слайд 37Модель хаоса
Минусы
критическая необходимость включить единый дизайн на уровне кода, который необходимо выполнить
![Модель хаоса Минусы критическая необходимость включить единый дизайн на уровне кода, который](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-36.jpg)
для удовлетворения требований на уровне программы.
Слайд 39Модель быстрой разработки RAD
Модель RAD, как правило, представляет собой инкрементную модель, в
![Модель быстрой разработки RAD Модель RAD, как правило, представляет собой инкрементную модель,](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-38.jpg)
которой множество разработок маленьких кусков выбираются и развиваются одновременно для достижения большей картины. Кроме того, обрабатывается инкрементная модель, в которой основные характеристики, подлежащие разработке, делятся на более мелкие, выполнимые куски. Эти куски затем разрабатываются индивидуально.
Слайд 40Модель быстрой разработки RAD
Плюсы
быстрое развитие продукта;
разработка многоразовых мелких компонентов;
повторный обзор в процессе
![Модель быстрой разработки RAD Плюсы быстрое развитие продукта; разработка многоразовых мелких компонентов;](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-39.jpg)
разработки;
интеграция повторно используемых компонентов на начальном уровне, следовательно, экономит усилия, несмотря на то, что не добавляются более крупные модули;
конструктивная реакция.
Слайд 41Модель быстрой разработки RAD
Минусы
требуется много усилий для сбора всех требований на начальном
![Модель быстрой разработки RAD Минусы требуется много усилий для сбора всех требований](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-40.jpg)
этапе.
навыки моделирования имеют много зависимостей.
не подходит для малобюджетного проекта.
Слайд 42Заключение
Существует множество вариантов моделей разработки ПО. Выбор того или иного варианта зависит
![Заключение Существует множество вариантов моделей разработки ПО. Выбор того или иного варианта](/_ipx/f_webp&q_80&fit_contain&s_1440x1080/imagesDir/jpg/884449/slide-41.jpg)
от особенностей и требований проекта, моделей оплаты. Частично методологии пересекаются и похожи друг на друга, но тем не менее, каждая находит своих почитателей.