ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 16.03.2024
Просмотров: 12
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Модели разработки ПО
Лекция №3
Виды моделей
Модель разработки ПО
(Software Development Model, SDM)
— структура, систематизирующая различные виды проектной деятельности, их взаимо- действие и последовательность в процессе разработки ПО. Выбор той или иной модели зависит от масштаба и сложности проекта, предметной области, доступных ресурсов и множества других факторов.
Моделей разработки ПО много, но, в общем случае, классическими можно считать каскадную, v-образную, итерационную, инкрементальную, спиральную и гибкую.
Водопадная модель (waterfall model)
Общее планирование
Пользовательские требования
Системные требования
Техническая архитектура
Детализированный дизайн
Разработка и отладка
Интеграция и модульные тесты
Инсталляционное тестирование
Системное тестирование
Приёмочное тестирование
Итоговая отчетность
Тестирование в явном виде появляется лишь с середины развития проекта, достигая своего максимума в самом конце.
https://vimeo.com/18951935?embedded=true&source=vimeo_logo&owner=5781173
Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
Нет проблем с доступностью программистов нужной квалификации.
В относительно небольших проектах.
Когда использовать каскадную методологию?
Таблица
Модель
+
-
Тестирование
Водопадная
У каждой стадии есть чёткий проверяемый результат.
В каждый момент времени команда выполняет один вид работы.
Хорошо работает для небольших задач.
-
Полная неспособность адаптировать проект к изменениям в требованиях.
-
Крайне позднее со здание работающего продукта.
С середины проекта.
V-образная модель (V-model)
Общее планирование
Пользовательские требования
Системные требования
Техническая архитектура
Детализированный дизайн
Разработка и отладка
Интеграция и модульные тесты
Инсталляционное тестирование
Системное тестирование
Приёмочное тестирование
Итоговая отчетность
Тестирование
появляется с
самого начала
проекта
Когда использовать?
Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
Для малых и средних проектов, где требования четко определены и фиксированы.
В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.
Таблица
Модель
+
-
Тестирование
V- образная
У каждой стадии есть чёткий проверяемый результат.
Внимание тестированию уделяется с первой же стадии.
Хорошо работает для проектов со стабильными требованиями.
-
Недостаточная гибкость и адаптируемость
-
Отсутствует раннее прототипирован ие.
-
Сложность устранения проблем, пропущенных на ранних стадиях развития проекта.
На переходах между стадиями.
Итерационная инкрементальная модель (iterative model, incremental model)
Общее планирование
Тестирование
Оценка результатов
Отчётность
Установка билда
Разработка и отладка
Интеграция и модульные тесты
Итоговая отчетность
Планирование
+ требования
Архитектура и дизайн
Итерационная инкрементальная модель (iterative model, incremental model)
Когда использовать?
Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
Требуется ранний вывод продукта на рынок.
Есть несколько рисковых фич или целей.
Таблица
Модель
+
-
Тестирование
Итерационная инкрементальная
Достаточно раннее прототипирование.
Простота управления итерациями.
Декомпозиция проекта на управляемые итерации.
-
Недостаточная гибкость внутри итераций.
-
Сложность устранения проблем, пропущенных на ранних стадиях развития проекта.
В определённые моменты итераций.
Повторное тестирование (после доработки) уже проверенного ранее.
Спиральная модель (spiral model)
Проработка целей,
альтернатив и
ограничений
Анализ рисков и
прототипирование
Планирование
следующего цикла
Разработка
(промежуточной
версии) продукта
Оценка промежуточных результатов
На
ра
ст
ан
и
е
общ
ей
ц
ен
нос
ти
п
ро
д
укт
а
Проекта и
продукта
Продуктных
Жизненного
цикла
проекта
Процесса
разработки
проекта
Эксплуатации
продукта
Жизненного
цикла
Разработки,
интеграции и
тестирования
Внедрения и
сопровождения
Общей
концепции
Уточненных
требований
Архитектуры
Дизайна
Детализация
Кодирование
Интеграция
Тестирование
Тестирование
Интеграция
Кодирование
Детализация
Когда использовать?
Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование.
Таблица
Модель
+
-
Тестирование
Спиральная
Глубокий анализ рисков.
Подходит для крупных проектов.
Достаточно раннее прототипирование.
-
Высокие накладные расходы.
-
Сложность применения для небольших проектов.
-
Высокая зависимость успеха от качества анализа рисков.
В определённые моменты итераций.
Повторное тестирование (после доработки) уже проверенного ранее.
Гибкая модель(Agile model)
Гибкая модель(Agile model)
1.Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения.
2.Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3.Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
Гибкая модель(Agile model)
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5.Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6.Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
Гибкая модель(Agile model)
7. Работающий продукт — основной показатель прогресса.
8.Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
Agile помогает наладить такой устойчивый процесс разработки.
9.Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
Гибкая модель(Agile model)
10.Простота — искусство минимизации лишней работы —
крайне необходима.
11.Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12.Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Гибкая модель(Agile model)
Ценности
TDD
Прозрачность
Простота
Единство
Наглядность
Осталось сделать
Производительность
Сделано
тесты
НЕПРЕРЫВНО
Билд
Рефакторинг
Интеграция
ЕЖЕДНЕВНО
Адаптивность
ИТЕРАЦИЯ
Билд
Тестирование
"Стендап"
собрание
Планирование
Ретроспектива
Оценка
ВЫПУСК
Оценка
План выпуска
Бэклог
Сотрудничество
СТРАТЕГИЯ
Бюджет
Соглашения
Цели
Видение
Гибкая модель
SCRUM
Гибкая модель
Когда использовать?
Когда потребности пользователей постоянно меняются в динамическом бизнесе.
Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.
Таблица
Модель
+
-
Тестирование
Гибкая
Максимальное вовлечение заказчика.
Много работы с требованиями.
Тесная интеграция тестирования и разработки.
Минимизация документации.
-
Сложность реализации для больших проектов.
-
Сложность построения стабильных процессов
В определённые моменты итераций и
в любой
необходимый
момент.
Пример
Компания-клиент X
Агенство Z
Таблица
Жизненный цикл тестирования
Жизненный цикл тестирования
Жизненный цикл тестирования
Стадия 1
(общее планирование и анализ требований) объективно необходима для того, чтобы иметь ответ на такие вопросы, как:
что нам предстоит тестировать;
как много будет работы;
какие есть сложности;
всё ли необходимое у нас есть и т.п.
Как правило, получить ответы на эти вопросы невозможно без анализа требований, т.к. именно требования являются первичным источником ответов.
Жизненный цикл тестирования
Стадия 2
(уточнение критериев приёмки) позволяет сформулировать или уточнить метрики и признаки возможности или необходимости начала тестирования (entry criteria), приостановки
(suspension criteria) и возобновления (resumption criteria) тестирования, завершения или прекращения тестирования (exit criteria).
Стадия 3
(уточнение стратегии тестирования) представляет собой ещё одно обращение к планированию, но уже на локальном уровне: рассматриваются и уточняются те части стратегии тестирования
(test strategy), которые актуальны для текущей итерации.
Жизненный цикл тестирования
Стадия 4
(разработка тест-кейсов) посвящена разработке, пересмотру, уточнению, доработке, переработке и прочим действиям с тест-кейсами, наборами тест-кейсов, тестовыми сценариями и иными артефактами, которые будут использоваться при непосредственном выполнении тестирования.
Жизненный цикл тестирования
Стадия 5
(выполнение тест-кейсов) и
стадия 6
(фиксация найденных дефектов) тесно связаны между собой и фактически выполняются параллельно: дефекты фиксируются сразу по факту их обнаружения в процессе выполнения тест-кейсов.
Жизненный цикл тестирования
Стадия 7 (анализ результатов тестирования) и стадия 8
(отчётность) также тесно связаны между собой и выполняются практически параллельно. Формулируемые на стадии анализа результатов выводы напрямую зависят от плана тестирования, критериев приёмки и уточнённой стратегии, полученных на стадиях
1, 2 и 3. Полученные выводы оформляются на стадии 8 и служат основной для стадий 1, 2 и 3 следующей итерации тестирования.
Таким образом, цикл замыкается.
Тест по Лекции №3
За тест можно набрать
максимум 30 баллов
Критерии оценки:
24-30 баллов - 5(отлично)
18-23 баллов - 4(хорошо)
12-17 баллов -
3(удовлетворительно)
0-10 баллов -
2(неудовлетворительно)
Время на тест 30 минут
Виды ошибок и методы отладки
Лекция №4