В чем преимущество итеративног процесса разработки ПО?(Прочитано 12546 раз)
Добрый день коллеги.
Читаю всякие красивые статьи, что каскадная модель это прошлый век, сейчас надо использовать итерационные модели (RUP, Agile, etc.)
Как мне представляется процесс разработки ПО:
1.Заказчик что-то хочет
2.Пишется ТЗ.
3.Заказчик согласовывает и утверждает ТЗ.
.
.
n.По истечению определенного времени получает требуемый продукт с характеристиками указанными в ТЗ.

Срыв сроков/ досрочная сдача указываются в договоре (пени, бонусы)
Внесение изменений после утверждения ТЗ оформляются дополнительным соглашением с указанием изменения стоимости/сроков.

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

p.s.Я работал в ВПК. У нас чуть ли не каждая версия ПО как НИР шла. Соответственно новое полноценное ТЗ на каждую новую версию, хотя 90% может повторятся с предыдущей.



Trigger, вообще довольно странно от Вас с Вашим то опытом слышать подобные рассуждения и вопросы. Хотя может все дело именно в ВПК?

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

Итеративный процесс предполагает эволюционную модель Боэма.
Преимущества:
- вовлечение заказчика в процесс разработки
- эволюционное протипирование и эволюция поставки работающего кода
- принцип ограничения работ

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

Водопадная модель как показывает практика плохо работает в производстве ПО (по крайней мере коммерческого ПО)



Galogen Спасибо за ответ.
Вы меня с кем то путаете. У меня нет опыта в разработке ПО (я работал инженером-системотехником, программированием у нас другой отдел занимался) эта тема очень интересует, однако большое количество методологий вносят путаницу.

Цитировать
RUP - типичная каскадная модель
Что-то новенькое. RUP изначально предполагает процессы и итерации, в отличии от каскадной, где фазы идут в стогом порядке.
Цитата из википедии:
Цитировать
RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта.
Цитировать
Водопадная модель жизненного цикла предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.

Цитировать
Преимущества:
- вовлечение заказчика в процесс разработки
- эволюционное протипирование и эволюция поставки работающего кода
- принцип ограничения работ
Предположим я заказчик и утвердил ТЗ по ГОСТу (из гос сектора заказчик) со сроками и необходимой функциональностью.
Далее предположим что я очень занятой заказчик и на весь срок исполнения уехал в командировку и про данный проект и не вспоминаю, ожидая, что к приезду (окончания срока работ указанных в ТЗ) все будет готово.
Преимуществ не вижу  :(

Другое дело, если заказчик заинтересован полностью участвовать в разработке. Тогда наиболее подходит ХР.

p.s.Если заказчик хочет по ГОСТу странно будет говорить, что мы используем ХР как самый передовой метод и ваше постоянное присутствие нам жизненно необходимо, раз в 2-4 недели будем высылать очередную версию (ну что успели к этому моменту, независимо от количества багов). Такому заказчику альфа, бетта версии не нужны, только полностью законченный продукт! Если в срок не укладываются или реализована не вся функциональность, то проблемы разработчиков. Если появились новые требования не указанные в ТЗ, то это проблемы заказчика.



Galogen Спасибо за ответ.
Вы меня с кем то путаете. У меня нет опыта в разработке ПО (я работал инженером-системотехником, программированием у нас другой отдел занимался) эта тема очень интересует, однако большое количество методологий вносят путаницу.
p.s.Я работал в ВПК. У нас чуть ли не каждая версия ПО как НИР шла. Соответственно новое полноценное ТЗ на каждую новую версию, хотя 90% может повторятся с предыдущей.
Я о Вас ничего не знаю кроме того, что Вы пишите о себе сами.

Что ж примем как аксиому. У Вас нет никакого опыта разработки ПО. Я предлагаю Вам его приобрести. Начните создавать ПО для кого-нибудь, желательно в команде из нескольких человек.

Все методологии возникают как результат обобщения опыта. Каскадная модель - вполне естественная в материальном производстве (строительстве и т.п.), где конечный результат в достаточной степени детерминирован.

С другой стороны возьмем инновационный проект, с большой неопределенностью в конечном продукте. Так вот разработка ПО - это инновационный проект. Очень схоже с математикой. Есть уравнение и есть его решение аналитическое. Все просто. Есть уравнение транцедентные, которые не имеют аналитического решения и могут быть решены только численно, итерационно. Однако и обычные уравнения часто дешевле решить численно. Любое численное решение предполагает задание некоторого нулевого приближения, а потом по определенным правилам производится локализация решения и постепенное приближение к нему с заданной точностью. С ПО то же самое. Если экономически обосновано сначала построить полную математическую модель системы, а потом ее построить, не взирая на затраты , но обеспечивая заданное качество - имеем одну модель разработки (по ГОСТ, каскадная: примеры систем критические системы управления процессами крекинга нефти, управления ядерными реакциями, полетом космического корабля, автопилот лайнера, и т.п.). Однако чаще всего это не так, даже для критических систем. Потому как практически невозможно сформировать полное и непротиворечивое ТЗ, потому как передача информации от заказчика к разработчику нетривиальный сложный процесс, потому как заказчик ВСЕГДА не знает чего он хочет точно, потому что большая НЕОПРЕДЕЛЕННОСТЬ, потому что это в природе ПО и т.п.

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




Что-то новенькое. RUP изначально предполагает процессы и итерации, в отличии от каскадной, где фазы идут в стогом порядке.
Небольшое замечание. Каскадная модель Ройса изначально была итерационной.
Первоисточник: статья "Управление разработкой широкомасштабных систем ПО", Уинстон Ройс 1970.
То, что вы называете каскадную модель неитерационной просто ошибка.

На текущий момент мне неизвестны методологии предполагающие реализацию исключительно в один проход.

PS. ГОСТ-ы 34.х не методология, а стандарт. Но тем не менее они также предполагают итерации.
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



Небольшое замечание.
Сергей, спасибо за уточнение.



совершенно верно, даже видел где-то недавно отличную презентацию на эту тему....
Лью воду...



О "водопадной" модели я как-то писал в блоге:
http://greesha-ru.livejournal.com/6988.html

Я склоняюсь к мысли, что водопадная модель была самым логичным подходом в условиях недостаточно эффективных (по сравнению с сегодняшними) коммуникаций.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19