Каскадный жизненный цикл разработки ПО

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

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

Открыть схему в полном размере ↗

Каскадный жизненный цикл разработки ПО

Этапы идут в следующем порядке:

1. Сбор требований. Зафиксируйте требования клиента и подготовьте необходимую документацию.
2. Проектирование системы. На основе требований определите архитектуру, а также потребности системы в оборудовании и программном обеспечении.
3. Реализация. Начните писать код по проекту. Разделите программу на небольшие независимые модули, проверьте каждый на соответствие его спецификации, а затем соберите из них систему целиком.
4. Интеграционное тестирование. Объедините проверенные модули и протестируйте всю систему на наличие дефектов.
5. Развёртывание. Исправьте дефекты, обнаруженные при интеграционном тестировании, а затем повторите тесты и убедитесь, что дефекты устранены. После этого система готова к выпуску на рынок и развёртыванию в среде клиента.
6. Сопровождение. Выпускайте исправления или новые версии для устранения дефектов и проблем, обнаруженных после поставки.

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

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

Спецификация и анализ требований

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

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

Открыть схему в полном размере ↗

Спецификация требований пользователей

Используйте принятый в компании формат, например документы Word, блок-схемы или чертежи. В результате команда получает подробное описание того, чего хочет клиент, и может правильно понять его потребности. Дефектом считается любое несоответствие требованиям клиента. Ошибки при сборе требований направляют проект по неверному пути с самого начала.

Спецификация требований пользователей

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

Спецификация требований к ПО

Спецификация требований к программному обеспечению (SRS) описывает, как оно должно работать с точки зрения пользователя. Она служит следующим целям:

• Зафиксировать договорённость между клиентом и поставщиком о конкретных функциях программного обеспечения.
• Дать основу для проектирования программного обеспечения.
• Упростить разработку и тестирование за счёт чётких требований.
• Помочь спланировать работы и оценить затраты.
• Дать основу для верификации и валидации.

Открыть схему в полном размере ↗

Спецификация требований к ПО

Проектирование ПО

У проектирования программного обеспечения есть два уровня:

• Высокоуровневое проектирование ПО
• Детальное проектирование ПО

Открыть схему в полном размере ↗

Проектирование ПО

Высокоуровневое проектирование ПО

Высокоуровневый проект (HLD) описывает структуру базы данных и функциональную архитектуру. Он помогает разработчикам ориентироваться в проекте и отвечает на вопросы о том, как устроено проектное решение. Для подготовки HLD нужна ясная спецификация SRS.

Детальное проектирование ПО

Детальный, или низкоуровневый, проект (LLD) разделяет HLD на более мелкие части и фиксирует логику, которая составляет спецификацию программы. Он даёт подробную информацию о системе и опирается на готовый HLD.

Подходы к проектированию ПО

При проектировании можно выбрать один из двух подходов:

• Нисходящее проектирование
• Восходящее проектирование

Подход к нисходящему проектированию

Нисходящее проектирование начинается с общей схемы системы. Детали подсистем определяются позже. Последовательно уточняйте устройство каждой подсистемы, пока не дойдёте до базовых элементов.

Подход к восходящему проектированию

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