软件开发的迭代过程 软件开发中的迭代
开发过程中据说的迭代是什么意思
周期 很多人简单的把迭代理解为开发的分阶段进行。
有些项目经理会这样说：我们打算通过4次迭代完成软件的开发，第一次迭代，完成需求分析和软件设计，第二次迭代，完成多少多少模块的开发，第三次，完成其他多少模块的开发，第四次，配置，部署，上线，测试，修正软件bug。
在这里，虽然他们言必称“迭代”，但是这样的迭代和过去传统的瀑布型开发有多少区别？迭代开发是要分周期分阶段地进行，但是不能认为简单地把开发周期划分为几个不同的阶段就是迭代。
很多人对于迭代周期有一些误解，比如：认为迭代只适用于开发阶段，而需求分析和设计工作则不在此范围内。
认为迭代周期可以拉得很长，比如两个月，三个月，甚至一个季度，半年。
将需求分析，设计，开发，测试，部署，用户反馈，修改当作完整的迭代周期，并要求在前一阶段工作完全（或者大部分）完成以后再进行下一步工作（迭代）。
在一个迭代周期内，我们可以做什么事情呢？可以说：所有的事情。
如果你认为迭代需要在需求分析完成之后才能开始，或者系统集成必须在所有迭代完成之后才可以进行，你会获得一个真正的瀑布流程开发。
一个迭代周期意味着对一些特定功能（用例）的探索。
“探索”一词可能随情况不同而有不同的含义。
对于抽象级别较高，模糊程度比较高的用例，我们需要通过和用户的讨论将它逐渐分解为更加清楚和清晰的用例。
对于目前我们认为已经得到了详细定义的需求，需要选取合适的部分进行设计和实现，通过这些部分的实现，对需求定义和技术可行性进行反馈。
对那些在上次迭代中已经开发完的模块，应该尽可能快速地让用户提出他们的意见，以便了解是否真正解决了用户面临的问题，以及还有没有可以改进的方面，再根据这些意见安排下一阶段的工作。
我们是否可以在开发进行之前把需求或者设计全部弄清楚呢？我认为很难。
因为通常来讲，用户对于自己的需求只有一个模糊的概念。
让我们假设一个饮食业的例子，有一天餐厅经理把你叫入办公室说：马上设计一个新的菜谱，这个菜谱是为某某特定人群定制的，你要让这些人感觉色香味俱全。
不过在你把配料和烹调方法都设计出来之前，我们不打算让大厨来具体做这道菜，我们不允许失败，所以你的设计一定要一次成功，你可以用调查问卷，用户面谈等方法获取最终用户的需求，但是记住：你不能去做这道菜。
这样的事情你可能会觉得很滑稽，但是在软件业，类似的事情人们却认为是天经地义的。
迭代允许我们将开发本身也作为需求探索的一部分，通过用户对已经实现功能的反馈我们和用户都会逐渐明白什么样的软件是我们最终想要开发的。
所以，不要等到所有（或者大部分）的分析完了才开始开发，而是尽早对已经捕获到的需求进行细化，尽早开发，以获得反馈。
在安排迭代计划时，应该指明，这次迭代的目标是什么，在结束时应达到的里程碑是什么。
如果有任务提前达到了这个里程碑，我们可以提前结束迭代，或者顺便在剩下的时间内安排其他的任务，但是要注意这种安排的合理性，不要因为这个而使得迭代周期被延长。
在一次迭代到达所设定的结束日期时，就必须审视各项任务是否达到了里程碑的要求，如果有任务没有达到，原因是什么，我们是否需要对需求和技术方案做出调整。
对于没有达到里程碑要求的任务，我们可以采取的办法有两种：将剩余的工作列入下一次迭代计划中去， 将本次迭代的结束时间向后延迟，等待任务的完成 前一种办法适合于有很大工作量没有完成的情况，这可能也同时说明计划的制定有问题，在制定下次迭代计划时应该考虑对任务完成时间进行调整。
后一种办法适合剩余工作量不是很大的情况。
通常来说，一次迭代完成以后应该有一个产品的新版本可用。
这也就意味着：将集成和发布分散到每次迭代中去。
借助于一些自动化工具（比如ant），我们甚至可以做到每日构建。
一个迭代周期应该有多长呢？这并没有一个统一的说法，而是应该视目标和可用的资源而定。
但是，迭代周期不宜过长，也不宜过短。
迭代周期过长的话，会延缓反馈的时间，可能将许多问题隐藏或是堆积了起来。
迭代周期过短，会让人身心疲劳，事情难有大的成效。
一般来说，迭代周期应该在2-6周之间。
如果安排的迭代周期超过了两个月，你可能就必须审视一下迭代计划的合理性了。
不要认为下一次迭代应该和上次迭代的时间差不多，刻板地把所有迭代规定一个统一的时间是一个很坏的做法。
但是你可以把以前迭代周期中的工作效率作为估算下次迭代时间的一个依据。
目标 一次迭代必须有明确的目标：我们希望通过这次迭代达到什么目的。
在制定目标时，应该同时考虑另外一个问题：如何检查该目标是否已经达成。
这就是所谓的“里程碑”。
迭代计划必须有明确而可行的目标。
明确的意思是它应该是可度量的，不能太模糊，因为你很难检查一个模糊的目标是否达成。
比如，我们可以说，这次迭代的目标是对xxx方面的需求作进一步细化和评审，完成xxx模块的开发以加入到软件的下一版本中去。
这样的目标是明确而且可行的。
反过来，如果我们这样说：我们要通过和用户的讨论...
2.迭代开发的过程是怎么样的
软件开发过程中的迭代模型：1.理解 如果认为这个解释难以理解，可以这样想：我们开发一个产品，如果不太复杂，会采用瀑布模型，简单的说就是先定义需求，然后构建框架，然后写代码，然后测试，最后发布一个产品。
这样，几个月过去了，直到最后一天发布时，大家才能见到一个产品。
这样的方式有明显的缺点，假如我们对用户的需求判断的不是很准确时——这是很常见的问题，一点也不少见——你工作了几个月甚至是几年，当你把产品拿给客户看时，客户往往会大吃一惊，这就是我要的东西吗？2.方法 迭代的方式就有所不同，假如这个产品要求6个月交货，我在第一个月就会拿出一个产品来，当然，这个产品会很不完善，会有很多功能还没有添加进去，bug很多，还不稳定，但客户看了以后，会提出更详细的修改意见，这样，你就知道自己距离客户的需求有多远，我回家以后，再花一个月，在上个月所作的需求分析、框架设计、代码、测试等等的基础上，进一步改进，又拿出一个更完善的产品来，给客户看，让他们提意见。
就这样，我的产品在功能上、质量上都能够逐渐逼近客户的要求，不会出现我花了大量心血后，直到最后发布之时才发现根本不是客户要的东西的情况。
3.优势 这样的方法很不错，但他也有自己的缺陷，那就是周期长、成本很高。
在应付大项目、高风险项目——就比如是航天飞机的控制系统时，迭代的成本比项目失败的风险成本低得多，用这种方式明显有优势。
如果你是给自己的单位开发一个小MIS，自己也比较清楚需求，工期上也不过花上个把月的时间，用迭代就有点杀鸡用了牛刀，那还是瀑布模型更管用，即使是做得不对，顶多再花一个月重来，没什么了不起。
...
软件生命周期迭代式模型什么样的？
软件开发模式有哪些？快速原型模型：（需要迅速造一个可以运行的软件原型，以便理解和澄清问题）快速原型模型允许在需求分析阶段对软件的需求进行初步的非完全的分析和定义，快速设计开发出软件系统的原型（展示待开发软件的全部或部分功能和性能（过程：用户对该原型进行测试评定，给出具体改善的意见以及丰富的细化软件需求，开发人员进行修改完善）优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险缺点：A、 所选用的开发技术和工具不一定符合主流的发展B、 快速建立起来的系统加上连续的修改可能会造成 产品质量底下增量模型：（采用随着日程时间的进展而交错的线性序列，每一个线性徐磊产生软件的一个可发布的“增量”，第一个增量往往就是核心的产品）与其他模型共同之处：它与原型实现模型和其他演化方法一样，本质都是迭代与原型实现模型不同之处：它强调每一个增量均发布一个可操作产品，（它不需要等到所有需求都出来，只要摸个需求的增量包出来即可进行开发）优点：1、 人员分配灵活，一开始不需要投入大量人力资源2、 当配备人员不能在限定的时间内完成产品时，它可以提供一种先推出核心产品的途径，可现发布部分功能给用户（对用户起镇静作用）3、 增量能够有计划的管理技术风险缺点：1、 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析注：这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程原型模型：（样品模型，采用逐步求精的方法完善原型）主要思想：先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。
原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求，采用方法：原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应优点： （1）开发人员和用户在“原型”上达成一致。
这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。
（2）缩短了开发周期，加快了工程进度。
（3）降低成本。
缺点：1、当重新生产该产品时，难以让用户接收，给工程继续开展带来不利因素。
2、不宜利用原型系统作为最终产品。
采用原型模型开发系统，用户和开发者必须达成一致： 喷泉模型：（以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目）它认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性相互迭代：软件的摸个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分无间隙：它在各项活动之间没有明显边界（如分析和设计活动之间）优点：1、 可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程不便之处：1、由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
2、这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况螺旋模型：（适合用于需求经常变化的项目）它主要是风险分析与评估，沿着螺线进行若干次迭代，过程：1、 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件2、 风险分析：分析评估所选方案，考虑如何识别和消除风险3、 实施工程：实施软件开发和验证；4、 客户评估：评价开发工作，提出修正建议，制定下一步计划。
优点：1、 它由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发中缺点：1、 难以让用户确信这种烟花方法的结果是可以控制的2、 建设周期长（而软件技术发展比较快，所以经常会出现软件开发完毕后，和当前的技术水平有很大的差距，无法满足当前用户的需求）3、 除非软件开发人员擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险瀑布模型：（从本质来讲，瀑布模型是一个软件开发架构，重复应用）（核心思想：按工序将问题化简，将功能的实现与设计分开，便于分工协作，采用结构化的分析与设计方法将逻辑实现与物理实现分开，依照软件生命周期自上而下，相互衔接的次序）缺点：1、 在项目各个阶段之间极少有反馈，各个阶段的划分完全固定，阶段之间产生大量的文档，增加了工作量2、 用户只有在项目生命周期的后期才能看到结果，增加了开发的风险3、 需要过多的强制完成日期和里程碑来跟踪各个项目的阶段4、 在每个阶段都会产生循环反馈（如果有信息未被覆盖或是发现问题了，必须返回到上一个阶段并进行适当的修改，只有当上一阶段都被确认后才进行下一阶段）5、 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果优点：1、 为项目提供了按阶段分的检查点2、 当完成一个阶段后，只需要去关...
软件开发模式有哪些？
B、 快速建立起来的系统加上连续的修改可能会造成 产品质量底下增量模型：（采用随着日程时间的进展而交错的线性序列，每一个线性徐磊产生软件的一个可发布的“增量”，第一个增量往往就是核心的产品）与其他模型共同之处：它与原型实现模型和其他演化方法一样，本质都是迭代与原型实现模型不同之处：它强调每一个增量均发布一个可操作产品，（它不需要等到所有需求都出来，只要摸个需求的增量包出来即可进行开发）优点：1、 人员分配灵活，一开始不需要投入大量人力资源2、 当配备人员不能在限定的时间内完成产品时，它可以提供一种先推出核心产品的途径，可现发布部分功能给用户（对用户起镇静作用）3、 增量能够有计划的管理技术风险缺点：1、 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析注：这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程原型模型：（样品模型，采用逐步求精的方法完善原型）主要思想：先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。
原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求，采用方法：原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应优点： （1）开发人员和用户在“原型”上达成一致。
这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。
（2）缩短了开发周期，加快了工程进度。
(3)降低成本。
缺点：1、当重新生产该产品时，难以让用户接收，给工程继续开展带来不利因素。
2、不宜利用原型系统作为最终产品。
采用原型模型开发系统，用户和开发者必须达成一致： 喷泉模型：（以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目）它认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性相互迭代：软件的摸个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分无间隙：它在各项活动之间没有明显边界（如分析和设计活动之间）优点：1、 可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程不便之处：1、由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
2、这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况螺旋模型：（适合用于需求经常变化的项目）它主要是风险分析与评估，沿着螺线进行若干次迭代，过程：1、 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件3、 实施工程：实施软件开发和验证；4、 客户评估：评价开发工作，提出修正建议，制定下一步计划。
优点：1、 它由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发中缺点：1、 难以让用户确信这种烟花方法的结果是可以控制的2、 建设周期长（而软件技术发展比较快，所以经常会出现软件开发完毕后，和当前的技术水平有很大的差距，无法满足当前用户的需求）（核心思想：按工序将问题化简，将功能的实现与设计分开，便于分工协作，采用结构化的分析与设计方法将逻辑实现与物理实现分开，依照软件生命周期自上而下，相互衔接的次序）缺点：1、 在项目各个阶段之间极少有反馈，各个阶段的划分完全固定，阶段之间产生大量的文档，增加了工作量2、 用户只有在项目生命周期的后期才能看到结果，增加了开发的风险3、 需要过多的强制完成日期和里程碑来跟踪各个项目的阶段4、 在每个阶段都会产生循环反馈（如果有信息未被覆盖或是发现问题了，必须返回到上一个阶段并进行适当的修改，只有当上一阶段都被确认后才进行下一阶段）5、 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果优点：1、 为项目提供了按阶段分的检查点2、 当完成一个阶段后，只需要去关注后续阶段3、 可在迭代模型中应用瀑布模型按照瀑布模型的阶段划分，软件测试可以分为单元测试，集成测试，系统测试注：由于每个阶段都会产生循环反馈，对于经常变化的项目而言，瀑布模型毫无价值，这种模型的线性过程太理想化，已不适合现代的软件开发模式
用软件开发流程怎样编写一个完整的程序
1 相关系统分析员和用户初步了解需求，然后用WORD例出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。
2 系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。
这次的文档会清楚例用系统大致的大功能模块，大功能模块有哪些小功能模块，并且还例出相关的界面和界面功能。
3 系统分析员和用户再次确认需求。
4 系统分析员根据确认的需求文档所例用的界面和功能需求，用迭代的方式对每个界面或功能做系统的概要设计。
5 系统分析员把写好的概要设计文档给程序员，程序员根据所例出的功能一个一个的编写。
6 测试编写好的系统。
交给用户使用，用户使用后一个一个的确认每个功能，然后验收。
举个例子来看： 1 某公司想找人订做一套人事管理软件，从某种渠道上得知我们有提供这种服务，所以联系上了我们。
2 我们会派专门的软件工程师到他们那里去了解我们要设计一个什么的东西给他们用，然后回来做个方案给他们，其中方案的内容包括：我们开发出来的软件大概的界面是怎样？方便什么人使用？什么人可以使用什么功能？方便到什么程度？大概的硬件要求是怎样等？ 3 他们看了方案后，确定他们就是要做一套这样的软件，我就开始开发这套软件。
4 我们把开发出来的软件交用他们使用，其中在使用的过程中哪里使用不方便或哪里达不到要求，我们会第第一时间修改这些功能，直到他们要求的所有功能都能很完美的解决掉。
已经很通俗了，不是么 ：）
-