4. В конце присутствует «миникаскад», завершающийся выпуском финальной версии ПО.

6. Преимущества и недостатки использования каскадной модели ЖЦ

Каскадная модель (Waterfall):

Рекомендации: Подходит для проектов с четкими, стабильными требованиями (например, государственные или инженерные системы). Неэффективна при высоких рисках изменений.

Основной принцип каскадной модели:

1.​ Работа над проектом ведётся как над единым целым; 2.​ фиксируются требования к системе в начале проекта;

3.​ переход со стадии на стадию осуществляется только после полного завершения работ на текущей стадии;

4.​ процессы ЖЦ жестко привязываются к стадиям; 5.​ в конце каждой стадии должен быть готов исчерпывающий

комплект документации.

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

Преимущества:

●​ Простота и структурированность: Четкая последовательность этапов упрощает планирование и контроль.

●​ Четкая документация: Каждый этап сопровождается подробной документацией, что удобно для крупных проектов.

●​ Предсказуемость: Легко прогнозировать сроки и бюджет.

●​ Подходит для стабильных требований: Идеальна для проектов с заранее определенными задачами (например, встраиваемые системы).

Недостатки:

●​ Низкая гибкость: Трудно вносить изменения в требования на поздних этапах.

●​ Поздняя обратная связь: Результаты видны только на этапе тестирования или внедрения.

●​ Высокие риски: Ошибки, допущенные на ранних этапах, обнаруживаются поздно и дорого исправляются.

●​ Не подходит для сложных проектов: Неэффективна при неопределенности требований.

7. Преимущества и недостатки использования эволюционной модели ЖЦ

Особенности эволюционной модели:

1.​ Работа над проектом ведется как над единым целым, требования к ПО поэтапно уточняются.

2.​ В рабочем цикле параллельно протекают процессы анализа требований, разработки и тестирования;

3.​ Промежуточные версии оцениваются совместно с заказчиком; 4.​ Количество промежуточных версий заранее не определяется.

Недостатки:

1.​ Сложность управления: Требует постоянного взаимодействия с заказчиком и контроля версий прототипов.

2.​ Риск бесконечных доработок: Без четких границ проект может затягиваться.

3.​ Высокие затраты: Создание и доработка прототипов может быть дорогостоящим.

4.​ Снижение качества документации: Фокус на прототипах может привести к недостаточной документации.

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

8. Сравнение эволюционной и итерационной моделей ЖЦ

Общие черты:

1.​ Обе модели предполагают многократное прохождение этапов разработки.

2.​ Ориентированы на постепенное улучшение продукта.

3.​ Подходят для проектов с изменяющимися или нечеткими требованиями.

Различия:

Количество итераций в итерационных моделях определяется заранее, в этом заключается важное отличие итерационных моделей от эволюционной.

1.​ Подход к разработке:

Эволюционная модель: Создает прототипы, которые постепенно превращаются в финальный продукт. Каждый прототип — это промежуточная версия системы.

Итерационная модель: Делит проект на итерации, каждая из которых создает рабочий инкремент с частью функциональности.

2.​ Гибкость:

Эволюционная: Более гибкая, так как прототипы могут радикально меняться в зависимости от обратной связи.

Итерационная: Менее гибкая, так как каждая итерация обычно следует заранее определенному плану.

3.​ Риск управления:

Эволюционная: Высокий риск "застревания" в доработках прототипов.

Итерационная: Более предсказуема, так как итерации имеют четкие цели и сроки.

4.​ Применение:

Эволюционная: Лучше для проектов с высокой неопределенностью, где заказчик активно участвует (например, стартапы).

Итерационная: Подходит для сложных проектов с частично определенными требованиями (например, корпоративное ПО).

Вывод: Эволюционная модель лучше для экспериментальных проектов с нечеткими требованиями, а итерационная — для

структурированных проектов, где функциональность можно разбить на независимые части.

9.Понятие архитектуры программного обеспечения

ипричины возникновения такого понятия в рамках процесса создания информационных систем

Архитектура ПО – набор ключевых правил, определяющих организацию системы:

1.​ Совокупность структурных элементов системы и связей между ними;

2.​ Поведение элементов системы в процессе их взаимодействия; 3.​ Иерархия подсистем, объединяющих структурные элементы; 4.​ Архитектурный стиль (типовой способ организации системы).

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

Существуют два основных принципа декомпозиции:

1.​ Количество связей между подсистемами должно быть минимальным («низкая связанность» или «слабое зацепление» – Low Coupling);

2.​ Степень взаимодействия внутри каждой подсистемы должна быть максимальной («сильная связность» или «высокая прочность» –

High Cohesion).

Существуют два основных подхода к декомпозиции систем:

1.​ Функционально-модульный подход, основывается на функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и иерархии структур данных;