Лекция 7 Цели, корректность и направления анализа программных пр. Цели, корректность и направления анализа программных продуктов. Выбор критериев сравнения. Представление результатов сравнения

• Название: Цели, корректность и направления анализа программных продуктов. Выбор критериев сравнения. Представление результатов сравнения
• Дата: 03.04.2023
• Размер: 0.54 Mb.
• Имя файла: Лекция 7 Цели, корректность и направления анализа программных пр.pptx
• Тип: Документы; #1033405

Цели, корректность и направления анализа программных продуктов. Выбор критериев сравнения. Представление результатов сравнения

Шаги процесса

Процесс разработки состоит из множества подпроцессов, или дисциплин, некоторые из которых показаны ниже. В модели водопада они идут одна за другой, в других аналогичных процессах их порядок или состав изменяется.
Анализ требований → Спецификация программного обеспечения
Проектирование программного обеспечения
Программирование
Тестирование программного обеспечения
Системная интеграция (System integration)
Внедрение программного обеспечения (или Установка программного обеспечения)
Сопровождение программного обеспечения


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

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

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

Этапы проекта в соответствии с каскадной моделью:

Формирование требований;
Проектирование;
Реализация;
Тестирование;
Внедрение;
Эксплуатация и сопровождение.

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

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

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

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

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

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

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

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

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

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

На каждой итерации оцениваются:

риск превышения сроков и стоимости проекта;
необходимость выполнения ещё одной итерации;
степень полноты и точности понимания требований к системе;
целесообразность прекращения проекта.

Задача

Дополнить данную презентацию другими моделями разработки ПО в таком же стиле. Желательно указать основные принципы, преимущества, недостатки, когда модель стоит использовать и добавить наглядный демонстрационный ресурс.