Форум Сообщества Аналитиков
Общий раздел => Методологии => Тема начата: Trigger от 21 Января 2012, 22:03:23
-
Добрый день коллеги.
Читаю всякие красивые статьи, что каскадная модель это прошлый век, сейчас надо использовать итерационные модели (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://greesha-ru.livejournal.com/6988.html (http://greesha-ru.livejournal.com/6988.html)
Я склоняюсь к мысли, что водопадная модель была самым логичным подходом в условиях недостаточно эффективных (по сравнению с сегодняшними) коммуникаций.