| 作者 |
内容 |
| achang_hu |
关于迭代式开发的讨论
迭代是现在软件开发工程中常用的软件工程方法，如RUP和XP中都是以此为基础来设计软件过程，以适应用户需求的变更。
RUP中提到：在以用户为中心的设计中，迭代式设计是在一个集成化的框架内部进行的。我们有意回避在一个统一的框架之外进行递增式开发，因为那将产生一个“拼拼凑凑”的解决方案。
那么，是不是说，第一次迭代就必须要分析用户所有的需求，设计好整个系统的框架？以后的迭代是在此框架中进行，但是变更需求可不会总是这样的。
如果，当用户需求变更时，你在下一次迭代中加入该需求，而该需求却是在原来设计框架之外，请问，如何避免产生“拼拼凑凑”的解决方案。 |
| 02/01/09 11:19 |
酷帖！ 臭帖！ 回复 |
酷帖评价： 臭帖评价： |
| 返回页首 |
|
| zhuxian |
 回复:
关于迭代式开发的讨论
我现在也在尝试迭代式开发。如果做得不成功，确实好像变成了每一个步骤都不规范。不过我认为OO过程必须是迭代式的，关健是每次迭代都要有一个目标，这确实难以做好。而且迭代不佳，可能导致开发周期过长；各个文档不匹配。因此迭代式开发是否一定要有好的软件工程工具支持才可能做好？ |
| 02/01/09 12:44 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| charles_chen |
 回复:
关于迭代式开发的讨论
你对框架的概念理解的小了一些。比如说，MVC就是一种通用的框架。你所有的设计都纳入MVC框架内，那这个框架就不会因为需求的变化而变化。再比如，我们前期为Web应用程序做了一个框架，只是为了制作JSP页面时风格的统一。它也不会因为制作不同需求的JSP而发生变化。所以，你在理解框架时要站在一个高的视角上看。 |
| 02/01/09 13:20 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| achang_hu |
你所说的框架是是指设计模式方面的framework，但
你所说的framework，编码当然不会超出此范围。而针对用户业务需求，我们不能用这样看待，为满足用户需求的设计虽然是在此框架中，但是你如何处理因为需求变化而造成的对象之间关系的变化？
所以，我认为，初期迭代所谓框架只是一个更为抽象的结构，就算如此，具体业务流程对象间关系，在此时也是需要考虑的，在当前迭代设计时，就要计划下一次迭代的设计，也许这就是迭代管理吧。 |
| 02/01/09 14:29 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| britain |
 回复:
关于迭代式开发的讨论
我认为迭代式开发的本身就包含两个方面过程：一是不断更新需求的过程，二是使设计不断完全反映和解决需求的过程。这时存在的问题可能是文档的数量过大，不能很好地管理。 |
| 02/01/09 14:45 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| lzhihua |
 回复:
关于迭代式开发的讨论
关于以架构为中心的迭代式开发,john_zhu及品雪大虾有过极为精彩的讨论。
我的理解有几点：1。架构由领域知识，需求（更多的是非功能性的，或者称为约束），借鉴相似系统得来，再由需求（包括功能性，非功能性）来验证。2。架构是有基线的，一开始需求可能不稳定，但有一个2/8原则即20%的需求占用系统80%的时间，意思是这是最核心的需求，由核心的需求导出架构基线，如果一开始核心需求就不确定，那架构的反复就难免了。（需求也是有基线的，否则我们可以创建一个放之四海而皆准的系统，因此不难理解架构是有基线的，否则我们可以创建一个放之四海而皆准的架构）。这里面有一个度的把握，这个把握需要知识和经验。3。架构也需要迭代。每次迭代都得用新需求验证架构，看是否要修改。（需求是有优先级的，优先级高的需求越先处理），好的情况是头几次需要对架构进行修改，后来就逐步稳定只需验证了至于再出现要大改架构的需求，那么只能说这需求是非分的了。4。借鉴很重要。
ibm developwork网站上《需求的实践（2）》中提到“煮鸡蛋的启示”
的故事，对于开发一个新领域，新系统得有英国人煮鸡蛋的精神，对于一个相似系统，借鉴可以事半功倍，注意是借鉴而不是照搬。
欢迎批评指正！ |
| 02/01/09 15:10 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| achang_hu |
回复:
关于迭代式开发的讨论
多谢！
我能理解你的描述，最重要的是一个“度”，基线确定是必须的。是不是可以这样说，一次完成最终的设计是没有的，只能逐步完善。 |
| 02/01/09 15:36 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| lzhihua |
 回复:
关于迭代式开发的讨论
RUP的目标是降低风险，其手段是尽早尽快发现风险并着手解决。至于解决风险的能力就要看团队的了，说到底是人的能力。我没有太多的实践经验，希望能和各位高手多多交流。 |
| 02/01/09 16:10 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| roshui |
构架的要求就是足够的稳定，（当然，如有必要，还要建立备选构架）
在初期对需求建立了基线以后，需要找出需求中的基本用例（essential
use cases）以建立系统的构架，如果你做过需求管理或了解需求管理的话，那你就知道在需求管理中对用例的管理中有一项属性就是“对构架的影响”，sccb在评估需求变更时也要考虑需求变更对架构的影响。 |
| 02/01/10 16:21 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| achang_hu |
那么，可不可以这样说，在一定程度上，迭代只是增量开发，需求也是有限定的。
|
| 02/01/10 17:00 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| roshui |
回复:
那么，可不可以这样说，在一定程度上，迭代只是增量开发，需求也是有限定的。
对,就是前面说的2/8和8/2 |
| 02/01/11 09:19 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
