Выбор методологии проектирования ПО
Анализ и планирование т.е. то, что у заказчика сформулировано не формально после этого этапа должно превратиться в спецификацию требований. Сбор происходит совместно с анализом требований, т.е. во время формирования функциональной спецификации анализируются, чтобы требования были непротиворечивыми, чтобы они были полными и т.д. После формирования требований приступают к планированию проекта, т.е. планирование этапов, сколько времени они займут, каких усилий они потребуют, какое кол-во разработчиков нужно привлечь и т.д.
Проектирование. Определяем как будет организована наша система, определяем какими данными и с какой структурой данных она будет оперировать и какие алгоритмы эти данные будут обрабатывать. Понятно если проект небольшой то отдельно алгоритм не разрабатывают, а это уже делают на этапе кодирования. Но если система большая то алгоритмы должны быть разработаны заранее.
Реализация или разработка. Здесь выполняют кодирование, т.е. проецирование алгоритма на какой-либо язык программирования. Отладка, т.е. то, что делает разработчик еще до отдельного тестирования, т.е. те ошибки которые он обнаружил в процессе разработки локализуются и отлаживаются на этом этапе.
Тестирование/верификация. На котором проводят разные процедуры обеспечения качества. Это могут быть динамические методы, типа тестирования, это могут быть различные статические методы типа верификации. Это зависит от конкретного проекта.
Завершается все это стадией сопровождения. Сначала программа внедряется, а в процессе эксплуатации обнаруживаются какие-либо ошибки, которые исправляются в процессе сопровождения. Это могут быть именно ошибки реализации, т.к. на этапе сопровождения не исправляются ошибки проектирования или ошибки сбора требования.
Существуют помимо общепринятой линейной модели еще три модификации классической модели, которые так или иначе используются и которые более адекватно соответствуют разработки ПО.
Классическая итерационная модель, предложенная Ройсом. Особенности модели, что подразумевается обратная связь между предыдущими этапами, т.е. на самом деле водопад в чистом виде уже здесь не присутствует и обратные связи появляются.
Каскадная модель. Основное отличие, что каждый этап сопровождается специальной проверкой, корректности выполнения этого этапа.
Усовершенствованная строгая каскадная модель. При этом минимизируются количество возвратов к пройденным этапам.
После проектирования возможно вернуться на стадию анализа и планирования и изменить требования или до собрать требования.
После разработки можно вернуться как к проектированию, так и к анализу.
После тестирования и после эксплуатации и сопровождения можно вернуться на любой этап.
Т.е. модификация заключается в том, что после проведения этапа можно вернуться на любое количество этапов назад.
В каскадной модели появляется этап проверки каждого этапа. Т.е. на этапе анализа и сбора требований у нас есть этап подтверждение, что требование не противоречиво, т.е. происходит верификация требований. Т.е. собрали требования, специфицировали, подтвердили.
Строгая каскадная модель отличается от каскадной модели тем, что возвраты разрешаются сделать только на один шаг назад. Это позволяет с одной стороны сократить или по крайней мере легче прогнозировать время проектирования, но с другой стороны обеспечивает меньшую гибкость, хотя такой гибкости как в предыдущей возможно и не требуется.
