При каскадной разработке разработчики сначала всё продумывают, а потом начинают делать каждую из продуманных частей отдельно, пока всё не доделают. На выходе получают готовый продукт. Типичный пример каскадной задачи -- это запуск космического аппарата. Его нельзя делать "по частям". Или у вас есть полный готовый продукт, или вы никуда не летите. Но не все задачи -- космические.
При итеративной разработке сначала делают упрощённую версию продукта, которую потом усложняют.
Я не нахожусь активно в "современной" айти-разработке, поэтому не вижу чистых итеративных и каскадных проектов. То, что я вижу -- это всегда смесь.
Если речь идёт не просто о разработке ПО, а о разработке устройств, то элемент каскадности неизбежен. Программист сможет нормально пилить программу только после того, как будет готово железо. Руководство пользователя можно писать только после того, как программист допилил программу.
Тем не менее, желание получить хоть какой-то результат (да побыстрее) смещает разработку в сторону итеративности. Сначала делается упрощённая версия и железки, и программы. Потом они начинают обрастать дополнениями.
Ну и вот, это всё было введение, а теперь тезис. При разработке надо следить за тем, чтобы было побольше каскадности. Почему? Недостаток каскадности приводит к тому, что половина функций не работают, потому что до них не добрались, а вторая не работает, потому что архитектура железа и ПО была плохо продумана, и их теперь просто так не сделаешь.
И мы сидим с нерасширяемым MVP на руках.
Или я чего-то не понимаю? Если вы разбираетесь в методологиях разработки -- подскажите, пожалуйста.
При итеративной разработке сначала делают упрощённую версию продукта, которую потом усложняют.
Я не нахожусь активно в "современной" айти-разработке, поэтому не вижу чистых итеративных и каскадных проектов. То, что я вижу -- это всегда смесь.
Если речь идёт не просто о разработке ПО, а о разработке устройств, то элемент каскадности неизбежен. Программист сможет нормально пилить программу только после того, как будет готово железо. Руководство пользователя можно писать только после того, как программист допилил программу.
Тем не менее, желание получить хоть какой-то результат (да побыстрее) смещает разработку в сторону итеративности. Сначала делается упрощённая версия и железки, и программы. Потом они начинают обрастать дополнениями.
Ну и вот, это всё было введение, а теперь тезис. При разработке надо следить за тем, чтобы было побольше каскадности. Почему? Недостаток каскадности приводит к тому, что половина функций не работают, потому что до них не добрались, а вторая не работает, потому что архитектура железа и ПО была плохо продумана, и их теперь просто так не сделаешь.
И мы сидим с нерасширяемым MVP на руках.
Или я чего-то не понимаю? Если вы разбираетесь в методологиях разработки -- подскажите, пожалуйста.
Пожалуйста, ознакомьтесь с комментариями!