Хорошие требования vs Сырые требования(Прочитано 9664 раз)
Как известно, ошибка полученная на стадии разработки требований обходится в 200 раз дороже на стадии тестирования и сдачи. Т.о. естественно нужно прорабатывать требования хорошо и они должны отвечать следующим критериям:
• Correct - описаны верно
• Complete - полные, отражать в себе все требования заказчика
• Clear - понятные всем участникам проекта и непротиворечивые сами по себе
• Consistent - не вступать в конфликт с другими требованиями
• Verifiable - требования можно проверить
• Traceable - уникальные и взаимосвязаны между собой
• Feasible - могут быть выполнены в соответствии с планом и бюджетом
• Modular - могут быть изменены без огромных усилий
• Design-independent - в требования не должны быть включены элементы дизайна

Но с другой стороны, даже если мы честно проработаем требования, то они все равно изменяться от:
• Изменения бизнеса
• Нечеткой формулировки Заказчиком и неумышленного умалчиванием чего-то
• Политических причин
• Квалификации аналитика

Так не лучше работать с требованиями по итерациям? Т.е. описали что-то - реализовали, дальше изменили требования, дописали новые требования - опять реализовали и т.д. Тем самым время разработки получаем немного больше, но зато удовлетворенность заказчика на много выше.

Кто что по этому поводу думает?
« Последнее редактирование: 20 Июля 2008, 14:55:09 от bas »
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Итерационная разработка предполагает циклический подход. Однако во всех таких подходах, требования итерационно не уточняются, а итерационно вовлекаются. Т.е. на первой стадии следует выделить самые самые требования при чем их должно быть не больше 10%. Ларман в своей книге "Применение UML и шаблонов проектирования" рассматирвает итерационный подход на примере вариантов использования. Т.е. вначале очень важно определить список требований (читай ВИ), ранжировать их и отделить самые самые, и уже их детально проработать.

Если же требование разрабатывать итерационно в стиле, который ты описал - то у программистов просто крыша съедит.

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

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

Если же проект инновационный, то мне думается тут следует действительно формировать промежуточнные прототипы, моделировать требования - но это будет скорее уже исследовательская часть, чем промышленное написание кода.



Так не лучше работать с требованиями по итерациям? Т.е. описали что-то - реализовали, дальше изменили требования, дописали новые требования - опять реализовали и т.д. Тем самым время разработки получаем немного больше, но зато удовлетворенность заказчика на много выше.

На сколько я понимаю - это принцип напрямую используется в alige методах разработки (Scrum, XP, UP (упомянутый Galogen) )



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



Итерационная разработка предполагает циклический подход. Однако во всех таких подходах, требования итерационно не уточняются, а итерационно вовлекаются.
Это кто тебе такое сказал?? Т.е. если была ошибка в требованиях, то ее не исправляют, а вовлекают новые требования??

Если же требование разрабатывать итерационно в стиле, который ты описал - то у программистов просто крыша съедит.
Вон у Agile программистов не слетают, а там еще хуже, зачастую требования вообще не прорабатывают, а кодят прям по тому что юзер написал (user story) или сказал

Вообще нужно разделять понятные, точно определяемые требования и требования неясные, нечеткие, знаний по которым по той или иной причине не достаточно. Последние требования наверное нужадются в предварительном осмылсении, моделировании, уточнении по ходу разработки.
А если таких требований много?? Не лучше ли написать, реализовать, показать, уточнить, реализовать. Не будет ли это быстрее, чем долго думать, написать, реализовать, показать, понять что не то, опять уточнить и реализовать. М.б. в итерационном подходе стремиться к неболее 2-3 уточнений?

Если же проект инновационный, то мне думается тут следует действительно формировать промежуточнные прототипы, моделировать требования - но это будет скорее уже исследовательская часть, чем промышленное написание кода.
В какой-то мере все проекты инновационны. А то бы  стояли станки по производству ПО.
« Последнее редактирование: 21 Июля 2008, 00:23:47 от bas »
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



На сколько я понимаю - это принцип напрямую используется в alige методах разработки (Scrum, XP, UP (упомянутый Galogen) )
В принципе да, но там еще хуже, как я писал выше.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



И обычно время выполнения заказчику гораздо дороже, чем какая-то мифическая удовлетворенность
Ну это как обычно, выбирай 2 из 3ех: быстро, качественно, дешево.
Но представим, что Вы выполняете проект сами и Вам выбирать процесс, что бы Вы выбрали??
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.




 

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