关于rup中的迭代有关问题
关于rup中的迭代问题
在先启阶段、精化阶段皆有迭代。我比较迷惑，这时候每次迭代主要干什么？上次的迭代和下次的迭代之间如何区分其工作内容？比如在先启阶段要完成远景的确定，那么还需要多次迭代来完成吗？
我理解，迭代应该至少把软件的用例大部分都确定下来才有依据，至少应该明确出所有的高层用例，然后在第一次迭代中细化一部分高层用例，然后再在下一次迭代中细化另外的用例。在先启阶段的第一次迭代中，应该尽可能的把所有的用例都描述出来。
不知以上理解对否？
------解决方案--------------------
RUP中得迭代就是完成一个工作目标，不同于XP中的迭代
------解决方案--------------------
你可能是刚刚接触迭代，迭代没有任何必须明确必须应该至少把软件的用例大部分都确定下来，也不是至少应该明确出所有的高层用例……
迭代是需要明确一个目标，也就是每一个迭代周期内需要完成的主要任务，这个主要任务并不需要某一个特定的阶段点，或者某一些必须完成的全部功能或者什么，你所说的都确定，或者至少明确所有的，这应该是阶段任务，而在阶段以内是需要划分多个迭代的，这样才是正确的对迭代的考虑。而不要把迭代当作阶段来考虑。
对于阶段来说，必须完成的就必须完成，而对于迭代来说，一旦有任务完不成，可以考虑放入下一个迭代中继续进行，而没必要为了一个任务来*推迟迭代的结束时间点。
这样说，是否就明白了？
------解决方案--------------------
简答说，迭代就是先做你清楚的，通过迭代搞定你不清楚的，最后达到非常清楚
------解决方案--------------------
不知道目标是什么，就知道现状不满意，现在满意了迭代就可以停止了。
------解决方案--------------------
RUP的迭代的目标不是给出一个可执行的程序，XP的是。
------解决方案--------------------
RUP的迭代的目标也是要有可执行的版本，迭代得思想的成熟时在rup中，IBM有专门的迭代开发的划分和管理的课程，有需要可以在网上相关的材料
------解决方案--------------------
我觉得。迭代是有必要时才迭代，如果一个很小的项目，没有必要一定要迭代。也就是说，本来一次迭代可以完成的工作，不必做第二次迭代。
迭代产出可执行的产品，我的理解并不一定是可运行的程序，他可以是一系列可行的文档或者一个能够验证系统框架的原型。
另外迭代的目的是把一个阶段的工作不断得深化下去直到可以进入下一个阶段。
一个项目是否可行应该在最初的一个或几个（通常一个足够）迭代中确定下来。确定下来就是说已经签定了合同了。在判断项目是否可行的时候，确实可以对其中最最主要的用例进行分析设计甚至于实现一个原形来验证系统是否真的可行。这些成本是判断项目是否可行必须的。所以这么做只会降低风险而不是增加风险。
至于接下来如何做计划和估计,RUP讲究的是啥都不必太急着决定下来，有多少信息就做多少事情。计划和估计都可以一开始就做起来，但不必太详细，只详细计划下一个迭代的工作。当然到了迭代结束，到了里程碑，那么该决定的事情一定要决定，如果决定不了，就进不了下一关了.
所以，不必拘泥。迭代的目的是帮助我们聚焦于近期最重要的事情。
建议楼主能够仔细体会每个阶段该达到的目标是什么，分这些阶段的目的是什么。然后根据项目需要，安排每个迭代的目标是什么。
------解决方案--------------------
同上，迭代只有有必要时才要用。
几个人，目标明确的小项目绝对不可能用这个模型。
那种目标不清楚，方法不明确，意见众多的大项目才需要。（有时候需求也需要迭代，用户的需求也会一下子说不清楚地）
基本意思就是，做一点，研究一下，再做一点，再研究一下，直到觉得很满意为止。
别被名词晃眼了
在先启阶段、精化阶段皆有迭代。我比较迷惑，这时候每次迭代主要干什么？上次的迭代和下次的迭代之间如何区分其工作内容？比如在先启阶段要完成远景的确定，那么还需要多次迭代来完成吗？
我理解，迭代应该至少把软件的用例大部分都确定下来才有依据，至少应该明确出所有的高层用例，然后在第一次迭代中细化一部分高层用例，然后再在下一次迭代中细化另外的用例。在先启阶段的第一次迭代中，应该尽可能的把所有的用例都描述出来。
不知以上理解对否？
------解决方案--------------------
RUP中得迭代就是完成一个工作目标，不同于XP中的迭代
------解决方案--------------------
你可能是刚刚接触迭代，迭代没有任何必须明确必须应该至少把软件的用例大部分都确定下来，也不是至少应该明确出所有的高层用例……
迭代是需要明确一个目标，也就是每一个迭代周期内需要完成的主要任务，这个主要任务并不需要某一个特定的阶段点，或者某一些必须完成的全部功能或者什么，你所说的都确定，或者至少明确所有的，这应该是阶段任务，而在阶段以内是需要划分多个迭代的，这样才是正确的对迭代的考虑。而不要把迭代当作阶段来考虑。
对于阶段来说，必须完成的就必须完成，而对于迭代来说，一旦有任务完不成，可以考虑放入下一个迭代中继续进行，而没必要为了一个任务来*推迟迭代的结束时间点。
这样说，是否就明白了？
------解决方案--------------------
简答说，迭代就是先做你清楚的，通过迭代搞定你不清楚的，最后达到非常清楚
------解决方案--------------------
不知道目标是什么，就知道现状不满意，现在满意了迭代就可以停止了。
------解决方案--------------------
RUP的迭代的目标不是给出一个可执行的程序，XP的是。
------解决方案--------------------
RUP的迭代的目标也是要有可执行的版本，迭代得思想的成熟时在rup中，IBM有专门的迭代开发的划分和管理的课程，有需要可以在网上相关的材料
------解决方案--------------------
我觉得。迭代是有必要时才迭代，如果一个很小的项目，没有必要一定要迭代。也就是说，本来一次迭代可以完成的工作，不必做第二次迭代。
迭代产出可执行的产品，我的理解并不一定是可运行的程序，他可以是一系列可行的文档或者一个能够验证系统框架的原型。
另外迭代的目的是把一个阶段的工作不断得深化下去直到可以进入下一个阶段。
一个项目是否可行应该在最初的一个或几个（通常一个足够）迭代中确定下来。确定下来就是说已经签定了合同了。在判断项目是否可行的时候，确实可以对其中最最主要的用例进行分析设计甚至于实现一个原形来验证系统是否真的可行。这些成本是判断项目是否可行必须的。所以这么做只会降低风险而不是增加风险。
至于接下来如何做计划和估计,RUP讲究的是啥都不必太急着决定下来，有多少信息就做多少事情。计划和估计都可以一开始就做起来，但不必太详细，只详细计划下一个迭代的工作。当然到了迭代结束，到了里程碑，那么该决定的事情一定要决定，如果决定不了，就进不了下一关了.
所以，不必拘泥。迭代的目的是帮助我们聚焦于近期最重要的事情。
建议楼主能够仔细体会每个阶段该达到的目标是什么，分这些阶段的目的是什么。然后根据项目需要，安排每个迭代的目标是什么。
------解决方案--------------------
同上，迭代只有有必要时才要用。
几个人，目标明确的小项目绝对不可能用这个模型。
那种目标不清楚，方法不明确，意见众多的大项目才需要。（有时候需求也需要迭代，用户的需求也会一下子说不清楚地）
基本意思就是，做一点，研究一下，再做一点，再研究一下，直到觉得很满意为止。
别被名词晃眼了