项目一个迭代周期内的开发流程 zhuan

软件项目开发，一般都会采用增量、迭代、（或者叫进化、演化、演进）的软件开发模型，众多的软件开发模型大多是以经典的瀑布模型为基础进行改进、变形，改进原则是：增加客户在整个项目周期中的参与度，降低软件开发过程中的风险，增强软件项目的后期可维护性。
不 同的软件开发模型，迭代周期长短也不相同，有的是一个月，有的是两周，我们一般都是根据实际情况确定，一个周期完成，将项目成果（可运行的软件）提交给用 户（或进行内部评审），通过后就进入下一个迭代开发周期，我画了一个迭代周期的活动草图（适用于中、小型项目的开发），每一个活动，将在下面详细说明。

一、明确客户（用户）。客户和用户一般指的是最终使用软件系统的人或为系统付费的人，搞不清楚目标客户（用户）会造成需求上的偏差。比如一个网站项目，或是一个外包项目，你首先得搞明白软件项目的目标客户（用户）。
二、市场调研，可行性分析。 针对目标客户，对软件项目或产品的目前市场状况、目标客户的情况以及公司的开发资源等各个方面因素进行综合分析考虑，确定项目市场与技术上的可行性，如果 发现风险过大，或可行性太低，项目就必须得终止。本阶段一般会产生市场调研报告或市场分析报告等文档。如果项目可行，就算是立项了。
准备自己创业的同学一定要注意市场调研哦，千万不能想当然，还一腔热血，不要迷恋网上的成功创业传奇。
三、需求采集。对目标客户进行需求的采集，方法很多，这列几个：部门访谈、中上层领导访谈、问卷调配、同类型软件分析、电话会议等等，收集回来的资料包括客户工作中的报表、表格，访谈记录，会记录、问卷调查表等。
四、需求分析、整理。对收集、采集回来的资料，进行整理、分析、讨论，梳理出业务流程，形成文档。有些纸质的东西收集回来后，要形成电子表格或word文件。
五、形成需求（规约）分析说明书。需求分析说明书的完成标志着软件生命周期中的第一个重要里程碑完成，需求分析说明书可以用两种形式来描述用户的需求：
A、 按功能模块来划分。具体思路是把整个大的系统按逻辑分成子模块功能，子功能再具体细分，直到确信某子功能可以实现为止。这种方式来描述需求有一些缺点，主 要表现在隔离了模块的角色与操作环境，不好把握需求与设计的界线，优点是非常容易映射到实现上（一般一个子功能就是一个菜单项）。这种方法很多大公司至今 都还在用，也许是老程序员已经习惯了这种需求描述的方式吧。
B、按用例来划分。用例是现在很多公司采用的需求描述方式。用例文件是需求主要描述的地方，用例文件描述的是一个会话环境，更加的形象、生动，推荐大家按这种方式来做，我也是习惯于用例来描述需求。
在前面五个环节中，还有两个活动流程是贯穿在其中的，它们是界面原型和领域模型。我认为这两个软件活动，在软件开发早期就开始了，并且在后续软件开发流程中，都可以找到它们的身影，下在就来谈谈这两个重要的活动。
原型法是 我认为在软件开发过程中必不可少的过程，而且非常的重要。我在这里指的原型法，主要是界面原型（架构原型或技术探索原型先不在这讨论），界面原型分两个阶 段来做，分别是原型设计与原型实现，在web项目中，会有不同的工具，并且侧重点也是不同的，具体请参阅我的别一篇文章。总的来说，没有界面原型，后面的 开发流程都免谈。打个比方：你要创作一幅油画，应该先有一个构思，先要有素描稿、色彩稿，要做到心中有数，否则，后期的创作将无从谈起。我现在的任何一个 项目，都是由原型设计开始，原型设计通过评审后，再进行原型实现。
领域模型的重要性大家应该非常清楚，在DDD一书中已有详细的论 述。领域模型是我们软件开发活动中的一种重要沟通工具，在需求采集、整理阶段就已经可以采用，我们可以用它来和客户沟通，可以固化我们对需求的理解，随着 对需求的不断深入，领域模型将不断完善。领域模型是一个项目的精髓，就像一幅肖像画中的神，它是更本质、更核、更深层的东西，不容易随着需求的变化而变 化。
有一些人和我纠缠界面原型、领域在软件活动中的顺序，比如：先写用例文本，再寻找领域；先写界面原型，再写需求文档等等，如果 你也存在这样的困惑，那就说明你犯了教条主义的错误，读书读死了。软件开发的各个响动，都是以降低软件开发风险，保证功能开发为目的的，无论什么活动，什 么工具，只要你认为对当前所处的开发阶段有用，就可以大胆采用，无要再在顺序上过于纠结。
领域模型做完后，有的公司会用一些方法对域模型的可行性 进行验证，常用工具是DB4O，一种面向对象的数据库，具体做法是：结合界面原型实现，直接在Controller层中通过DB4O完成主要域对象与页面 的交互，如果发现领域问题就可以及时修正，减少后期存在的一引起风险因素。
六、概要设计。这一过程架构师参与得多一些，主要是根据需求分析阶段的成果（重点要考虑非功能性需求），进行架构的确定，包括业务架构（如果一个公司初入某一行业领域，可能无法确定业务架构），系统架构，技术实现架构等，这一阶段可能还会对领域模型进一步的细化。
七、详细设计。该阶段应该完成编码前的所有准备工作，主要完成以下的任务：
A、 ER模型。可参照领域模型，完成ER模型的设计，最终结果基本和域模型一致。有的UML工具可以由领域模型直接导出ER模型，经常有人问题有了领域模型， 为什么要创建ER模型呢？因为我们要由ER转物理模型，在PD中由ER转物理模型非常方便，并且可以选择不同的底层数据库，建了ER后数据库移植将非常的 方便。
B、物理模型。由er直接转面物理模型，再由物理模型导出数据字典，建表sql，在PD中还可以自动生成测试数据，因此，物理模型这一步是 必须要做的。我见过有人是先写好领域对象，再写好hbm，然后动态生成表，这种做法不是太好，因为在实际的生产环境中，数据库和领域对象是不匹配的，存在 阻抗，所以，数据字典对于开发、维护，都绝对是一份非常重要的文档，也就是说一定要有物理模型。
C、详细设计包层次结构，包中的类，类中的方法及属性，总之，编码前的一切准备工作都要做好。
D、本次迭代的周期的人员分工，计划等。人员分工可按用例（或功能）来分配，也可以按层来分配（比如：dao,service,action等），任务分配要考虑到任务是否存在时间上和逻辑上的先、后依赖关系。
E、如果持久层是hibnerate、ibatis等orm框架，要事先安排一到两人来完成整个系统的关系映射文件（如果用 hibernate，这点很重要，不要让每个实现者去写自己的hbm）。
F、项目的第一个版本，上传版本控制服务器，每位开发人员检出项目。
八、编码实现，单元测试。 程序员在这个阶段按照分工及业务需求，进行代码实现。如果是按用例（或功能）来分工的，必须要求程序员从底层向上层写，最好按测试驱动开发（TDD）方式 来做，写一层，测一层，保证底层的实现正确性后再向上写。编码阶段管理者还要注意时间上的控制，业务代码实现大约占比20%，页面交互、实现约占80%的 编码实现周期，做计划时要做到心中有数。如果是程序新手，还得分阶段对代码进行评审，对不规范的代码进行及时指正，以保证代码的质量。
九、测试。本阶段专业的测试人员参与多一些，一般的公司可采用下面的流程。
A、首先是一个集成测试，必须保证每个程序员写的东西可以做为一个项目整体正确运行；
B、功能性测试，可以用工具来简化（比如：Selenium），但对前期设计要求很高，如果你的前期设计没有达到这个程度，最好是用人进行手工测试了。比如一些web game，还只能用人来进行测试功能。
C、 压力测试。压力测试是针对于非功能性需求的，选择一些重要的功能进行压力测试，得到测试报告（得到系统的性能参数后有针对性的优化），可选择工具有 ab，loadruner，jmeter等等，要注意的是压力测试是要有针对性的，一般不会整个项目的全部功能都进行压力测试。根据测试结果，还要进行性 能调优，至少得满足非功能性需求吧。
十、用户验收。把阶段性果（可运行软件）交付用户使用，收集用户反馈，准备下一阶段的迭代准备。如果本次的软件迭代成品是不可运行的，或不需要向客户交付，只需进行一个内部验收或评审即可。
十一、项目部署，维护，二次开发等。 软件开发流程是一环扣一环的，前一阶段的没有做好，一定会对后一阶段造成影响。如果前面的工作做得不扎实，存在一些问题，那么在项目的运行维护期，就等着 前期把挣到的钱一点一点还回去吧。什么开闭原则，高耦合低内聚，代码质量，文档完整性等等这些，我相信在这个阶段你一定会感受到它们的重要性，这些东西绝 对不是空洞的理论。
上面是对软件开发流程中各个活动进行了一个简单的介绍，下面来谈谈活动的时候及项目管理者如何来管理（主要针对一个已经有需求文的项目，如何带领程序员来实现，假设程序员都是些新手，初级程序员）。

一个月的时候分为四周，共20个工作日，每周的具体安排如下：
第一周：
A、下发需求文档，必须要明确如何去阅读需求文档。
B、 在阅读的过程中，认真思考业务流程，并进行界面原型的设计（这是让程序员尽快熟悉需求的最好办法）。本过程的原则是：快速，每张界面原型中要合理布局主要 的界面元素以及要标明页面间的跳转流程，所用工具：Balsamiq Mockups。做好后的原型全部整合到一起，进行总体评审，在评审的过程中，需求将会得到了进一步的明确和理解。（2天）
审核不合格的，要求进行再次修改，修改完后再次评审。评审以小组为单位，结合业务流程，在PC上进行逐页进行检查，也可以使用投影仪，由页面实现者根据原型设计自己讲解业务。
（注：本过程之前一定要下发页面原型规范，明确审核标准）
C、原型实现。以前期的原型设计为基础，进行可重用原型的实现，工具为DW。原则是：按最终的实现去做，尽量细化，详细确定界面上的原素细节。css、js、目录划分、页面命名、页面元素命名这些事项都要进行明确。
（注：本过程前期要讲清楚原型实现的要求、细节，下发页面框架，在框架的基础上实现，以达到效果的统一）
普通web项目原型实现要用到js框架，我们一般选择jQuery ui。（3天）
时间安排上，原型设计约2天时间，原型实现3天时间。第一周完成后的项目成果有：原型设计存盘文件，原型实现存盘文件。
第二周：
A、 领域模型设计。以OOA理论为基础，结合界面原型、需求文件以及自身对业务的理解，小组讨论通过形成第一个版本的领域模型，确保大的结构符合业务需求。第 一个版本的领域模型只包括对象的重要属性及对象间的组合聚合、泛化关系，已经搞清楚的关联数量关系一定要标出，领域对象一定要取合理的名字。这个过程完成 后，要求小组的每个程序员能够根据领域对象图描述自己的业务流程（1天）
（注：这个过程也可以在第一周讨论业务的时候就开始进行，我一般都会向前提）
B、 在第一个版本的领域模型图的基础上，结合界面原型，进一步完善领域对象的属性及关系，这个时候必须要做细致，类名及属性名全部用翻译成英文（描述要用中文 写好，导出的代码中就会有中文注释）；对象间的关联关系线全部用具体属性表示；根据业务确定是单向还是双向关联；添加数据库主键；实现序列化接口；实例化 所有集合。
C、进行数据库ER设计，导出建表sql，生成数据库测试数据，生成数据字典。（B、C两步共用2天时间）
D、进行详细设计，根据规范建立包名，从uml工具中导出领域对象；根据界面原型及需求（用例）确定业务对象粒度，完成业务层业务方法的设计（业务层业务方法设计这一步也可以省略，按敏捷方法在实现时自行灵活添加）。
E、 创建一个动态web工程，在公司现有架构基础上（这时要对架构进行讲解），按规范建立初始版本，主要做三件事：生成orm映射文件，确保基本正确无误；所 有html页面转换为jsp页面，注意转换的一些注意事项，要确保新建立起来的项目能够正确启动运行，所有页面均可访问，外观不变形；初始版本项目提交至 版本控制服务器，每位组员根据账号密码检出一份项目代码（1天）。
F、第二周要建立起编码前的所有准备工作，小组后面两周的计划要制定出来，有横向的人员模块分工，有纵向的哪一天写到哪一个层次。项目管理人员要对编码前所完成的工作进行审核，确保无误。
第二周的阶段性成果有：领域模型，数据字典，设计模型，项目后期开发计划，ORM映射文档等。
第三周：
进 行编码期，这个时期要求程序员从业务层实现写起，junit测试代码与实现代码交替进行（基本按照TDD来做），测试过程中会发现ORM映射文件可能有问 题，表结构或许也有问题，这个时候要进行小的调整（所有的表结构、类、orm调整均由项目负责人进行）。项目管理人员在这个时间主要是对代码进行审核，确 保符合编码规范。
业务层代码的编写与测试时间大约为2~3天，后面的时间进行页面的交互实现。
页面的交互花费的时候非常多，工作量也很大，这项工作会持续到第四周。
第四周：
页面的交互实现，项目集成整合，集成测试，功能性测试，压力测试等。
本 周花在页面交互实现的时间约2~3天，集成测试1~2天，压力测试及最后的整合1天，根据程序员的整体水平的不同，本周的时间可能会非常仓促。如果前面几 周的工作没有做扎实，这周受到的影响会非常大。如果项目最终结果没有达到，时间可能会顺延几天，这样也致使项目在一个迭代周期中无法完成，如果一定要以固 定周期迭代，只有在项目前期减少本次迭代的任务。
附一个迭代周期主要活动进度图，供参考：


最后说一点，每个公司都会根据项目特点和自身习惯，找到一条符合公司实际情况的开发流程，但总的原则只有一个，那就是尽量降低软件开发过程中的风险，确保项目成功开发。

 

出处http://hi.baidu.com/ien_leo/blog/item/ed55409dc4a3f2186f068c4d.html