哪位大侠给我讲讲采用迭代式进行开发，以及要进行的注意点

[qiujoe]

我刚开始学RUP，对于迭代式开发不理解，特别是迭代开始时，如何确定首次目标，按当前的目标开发会不会对以后的集成产生不利的影响？
请大虾给讲讲，分不够，我会继续加的

[longaway]

迭代迭代，就是要不断的循环的嘛。
首次目标，至少是能运行的，能把系统主要功能体现出来。
确实较难准确定义。不然用迭代干嘛。
第一次出错并不太要紧，关键是在早期，发现问题。

[qiujoe]

谢谢
你的意思就是出错了不要紧，因为第一次做的工作量不算大，可以重来？

[FireKylin]

迭代的每个周期多长、每个周期要完成什么都是挺重要的。通常要靠经验，也和开发

团队的素质有关（包括项目组的每个成员的素质）。

过多的迭代会损失效率，过少的迭代会增加开发风险。

最好是在开发中不断总结，相类似的项目开发一到两个就会有比较清晰的过程了。

[AutoAsm]

要使用这种增量的方法，必须需求基本明确，也就是说大方向是正确的，否则，很危险。
不过我喜欢这中方法，是演进与瀑布的综合，扬长避短。

[青润]

迭代：是要根据你的目标进行时间和资源配置的。
一般来说，在第一次迭代的时候，往往是不太稳定的，所以，不好控制；
但在第二次迭代开始前，就可以做好第二次迭代的计划，此后的迭代都是有具体的目标和资源配置的，这以后的迭代过程都是根据需要进行管理和控制的，而不是随心所欲。
第一次的安排，往往是依靠经验而不是计划性。

[qiujoe]

谢谢参与，加分
另外如果我想试一试这种开发方式，有什么方法可以让我比较好的控制第一次迭代
是不是做一个小的系统可以少一点风险

[qiujoe]

对了，我现在做的系统也有一定的想法，即1.0版做什么 2.0版做什么......
但都是后续版本都是一个模模糊糊的想法，想做哪方面的内容，没有仔细考虑过，在现在的分析也没有考虑到以后的版本，在后续版本的开发中有可能会推掉现在版本的想法，迭代式开发会不会也有这样情况？

[bland]

一般来说，如果没有多少经验，比较好的控制第一次迭代的方法那只有耐心的做好需求分析，
做一个小的系统当然可以少一点风险，小系统都没多少把握做好，大系统那就会尽出篓子的
还有一点，也许具体的软件工程过程与软件管理过程的混乱与失误常常使人忙于因之而生的麻烦
和日常事物

[FireKylin]

1.是原型（因为这这时候还不具有完整的功能），原型经过多次迭代不就是产品了吗？
2.对要做的系统不了解是绝对不行的，宁愿花较多的时间去了解系统需求，不然到最后再来改
框架会大量增加开发成本的。我觉得第一次迭代最好是完成系统框架性的东东，这样后续
的开发能有较高的并行性，不会因为某些问题产生瓶颈。当然这样对系统架构人员的素质
也要求非常高了。
3.系统架构是非常重要的，不管采用什么开发模型对系统分析人员的要求都是特别高的。

[青润]

实际上，在RUP中，需求也是经过一个个迭代然后完成的，所以，不要涉求第一次就将需求做得很完善，你只能尽可能的是自己找到的需求更完全，但不会一次就能做好。
在做第一次迭代的时候，要限定一个比较可行的时间范围（完全依靠经验），提供一定的资源，然后就可以开始了！不要害怕什么都不知道，不知道要做什么，当你按照RUP中的方式完成了作了需求收集工作后，你就可以基本上清楚自己的方向了。^&^还是做一下会对你有好处！
关于后续版本的问题，你不需要考虑得那么清楚，如果都很清楚了，你的需求也就不需要迭代了，所以，没必要想得太远。

[qiujoe]

我理了一理各位的想法,请大虾指正
1、根据对系统的了解程度确定好具体的目标和资源,第一次迭代只需要完成基本功能,好运行就就可以了:-)
2、当第一次需求测试完成后,进行第二次迭代,此时根据第一次的测试报告、用户的需求变更和新了解到的需求,做第二次需求分析
3、重复2的工作,直至项目完成

这中间我有几个地方不懂
1、迭代中交给用户的是产品还是原型,还是说没有严格的区分?
2、这样做,当对要做系统本身没有太多了解、没有经验时,是不是第一次迭代所涉及的范围、目标越小越好,准备重来:-(
3、迭代是不是对分析人员要求特别高,因为不能每次都重来啊.我觉得用户的需求是五花八门,你想也想不到,万一一个没做好架构,就要重来,假如在最后一次迭代不就惨了

[shgciom]

受益非浅

[qiujoe]

没人发表意见,我就结账了

[fita]

我谈谈自己对于迭代式开发的看法：
1、迭代式开发的目的在于能够尽早实现一个可用的产品，并在每一次迭代提交一个更加完善的产品。虽然这一版本产品的功能不是很完整，但它是可用的，有足够的质量，前面有位朋友说第一个版本可以有很多错误，我认为这是不对的，每一次迭代提交的产品，应该都是错误很少，可以使用的产品，但产品的功能可以少一些。其余的功能在后面的版本中逐步实现。

2、基于上面的观点，迭代的第一个版本，应该是确定这个产品可用最小的功能集合，以及客户最想要的功能，只需要实现这些功能产品就可以提交给客户使用了。然后再确定下一个版本的功能，在前期的版本开发中，可以先不管以后要做的功能，因为各种因素都在变化当中，以后版本的功能到时候再根据客户当时需求确定比较好，就是说每个版本的功能是客户驱动的。

3、迭代式开发中，应该把每一次迭代的时间控制得短一些，快速提交新的版本，使客户受益。在系统的设计上，应通过面向对象设计保持设计的灵活性，使得设计修改更加方便快速，因为后期的需求可能会导致系统某些部分重新设计，对于这些地方的重新设计应不会对整个系统架构造成太大的影响。

4、对于迭代式开发，我觉得做得最好的应该是XP方法，大家可以去看看相关的资料。

[qiujoe]

to lyf_lyf(陀螺)　
我对rose现在是看得懂,但不会画,没有看过实际项目的rose 图,请问你有没有不涉及商业秘密的实际工作ROSE图发给我看看
to fita(天外飞仙)　
同意你的看法,但对于
迭代式开发，我觉得做得最好的应该是XP方法，大家可以去看看相关的资料,
我不懂
XP是什么?网上有资料吗?

[得码刘永锋]

我现在用rose的经验：
1。系统初期关注全局的问题，尽量把需求和功能分到不同的包中去；
2。在包的划分完成后，迭代第二步开始：进行系统用例图的划分。如果在进行用例图的划分的时候发现包的划分不合理，可以退回包的划分。包的划分修正后可以再来看用例图的划分。这就完成了一个迭代的过程。
3。用例图的划分完成可以进行类图或活动图，状态图的划分，再划分中找出问题，再退回来处理用例图的划分，或者还可以回溯到包的划分。这样就可以实现逐步加细的迭代思想。

我认为这就是迭代的概念。不知道你是否认同。：）