EOS应用开发过程参考手册
构件实现走查 主程序员，构件包所有者 可选 构件实现走查是提高开发质量和提升项目复用度的重要手段，一般由开发小组的主程序员牵头，对本小组选取具有典型代表意义的功能进行构件实现的走查，走查的内容包括： ? 实现是否满足设计的要求：包括是否满足业务需求、功能操作过程是否合理 ? 构件实现的逻辑是否合理：包括是否是最合理的算法，是否可以复用已存在的构件，是否可以将几个逻辑合为一个公共的构件、逻辑的切分是否优雅 ? 构件实现是否遵循了项目开发规范：包括命名规范、开发规范等 另外，主程序员也可以邀请横向小组的主程序员进行这种走查工作。 提交开发结果 主程序员，构件包所有者 必须 提交开发结果是指将开发源码提交到版本管理服务器的过程，如果采用CVS，则可以通过EOS Studio直接进行提交或者迁出。 在向版本管理服务器提交源码时，需要注意避免将一些中间文件或临时文件也提交的版本管理服务器中。譬如，在EOS项目中，目录debug、out都不需要提交，另外，对于有java文件的目录下的class文件也不需要提交到版本管理服务器中。 提交开发成果时，需要保证所提交的功能通过了开发人员自身的单元测试，提交完成后，更新《系统功能分解与跟踪矩阵》的开发状态。 应用部署包导出 开发经理 可选 通过EOS Studio产生并导出应用项目的部署包，便于部署到开发团队功能的集成服务器上。 说明：应用部署包的导出可能是周期性进行的，导出后可以按日期放到版本控制服务器中，再由测试人员提取部署到测试（开发集成）的服务器上。 项目文档生成 开发经理 可选 通过EOS Stduio提供的功能生成项目的文档，该文档可以作为系统的详细设计文档，同时通过对该文档的审查，可以看到是否存在不符合开发规范的地方。 开发进度跟踪 项目经理、开发经理 必须 项目经理将通过《系统功能分解与跟踪矩阵》了解项目开发的进度状况，开发经理则需要提醒主程序员更新进度，并根据进度状况阶段性（例如每周）调整开发计划或者任务分配。
4.3.4. 输出内容
? 开发阶段计划 ? 项目源码
? 项目实现的文档（EOS Studio产生）
http://www.primeton.com/ 第31页共44页
EOS应用开发过程参考手册
4.3.5. 阶段控制点
项目组进入到开发阶段，项目团队基本形成了统一的工作风格，整个项目组似乎形成了一个团队文化，大家的交流和沟通比较畅通和充分，在工作协调较好的情况下，项目团队表现出较高的工作效率。但是，在这个阶段，往往能意识到项目的进度是否能达到预期的目标，在进度延迟的情况下（实际情况往往如此），项目组开发人员通常被要求加班加点，尽管本阶段项目经理的具体工作不太多，激发和保持开发团队的工作激情是一项重要的工作（这是一项艺术性的工作，在此不作深入阐述）。除此以外，本阶段还有以下控制点：
? 开发进度的控制和开发团队的协调
对于初次使用EOS的项目组，一般开发过程分为三个阶段：入门期、磨合期、高效率期，含义如下：
1） 入门期：刚刚使用EOS，在对产品的理解和产品使用的熟悉程度上都处于
初级阶段，开发时有些不知从哪着手的感觉，很简单的功能或者处理做起来都感觉很艰难，因为认识不深，所以有时不知变通，在此阶段，有时项目组的成员甚至感觉效率还不如直接编码，加上这个阶段开发人员还需要去理解设计和需求，所以工作效率比较低下。
2） 磨合期：开始有了感觉，对EOS理解加深，也具备了某些使用经验，但
有时遇到一些复杂的情况还是不知如何处理，开发效率稳步上升
3） 高效率期：这是对产品有了深入了解，使用经验也比较丰富，能够做到融
会贯通，一般的问题都能找到解决方案，开发效率达到最佳状态。
对于以上各个阶段在时间上的划分，各个项目组根据人员的开发经验和基础技能有所差别，需要开发经理综合开发团队的情况进行评估，在划分开发阶段的里程碑和进行工作量评估分配时，可以充分考虑以上的一些情况。 另外，在开发过程中，还要充分考虑各项工作的协调问题，某些优先级高而且对其他工作任务有影响的工作交给有经验的主程序员实现，同时，密切跟踪项目的开发进度，适当的时候进行工作任务的调整。
? 开发规范的执行状况
在开发过程中，对于开发规范执行状况的监控也是项目管理工作中的重要内容，在本参考中，一直比较强调《项目开发规范》对项目质量的作用。只用真正通过开发时将规范执行下去了，这种作用才能真正体现出来。对于监控工作，可以推荐使用2层机制：开发经理监控整个开发团队的规范执行情况，主程序员监控本开发小组的执行情况。
? 需求变更的严格控制
在本阶段中，不可避免仍然存在一些需求变更的情况，对此，需要进行更为严格的控制，尤其对于引起设计变化的变更，当然，严格控制的意思不是说不接受，而是要严格评估造成的工作量，在如果接受这种变更的状况下，增加的工作量如何消化（增加资源？进度顺延？…）。
4.3.6. 退出条件
? 代码开发全部完成，并且提交
? 更新完《系统功能分解与跟踪矩阵》的开发状态
http://www.primeton.com/
第32页共44页
EOS应用开发过程参考手册
4.3.7. 参考模板
? 《数据库变更管理》参考模板
4.4. 测试阶段 4.4.1. 概述
测试阶段并不一定在所有开发结束后才开始，而是在开发进行到一定阶段后就启动测试工作，测试工作可以由项目组以外的测试部门进行，或者项目组包含测试人员。测试过程中，对于功能性测试，主要采用编写testCase后手工执行的方式，而性能测试可以采用一些性能测试功能，接口测试可以编写模拟的测试程序进行。
EOS应用的测试主要偏向系统功能和非功能性的测试，主要以黑盒测试为主（单元测试在开发阶段由开发者完成），以下是本阶段的主要工作：
http://www.primeton.com/ 第33页共44页
EOS应用开发过程参考手册
测试阶段项目实施工作项目管理工作编写测试方案制定测试计划测试环境准备应用功能测试任务分配编写测试用例迭代系统测试测试进度跟踪编写测试报告
测试中，对于BUG的管理，建议使用BUG管理工具，例如Bugzilla。
4.4.2. 进入条件
? 开发工作有序进行，并且已经有成果提交 ? 测试人员到位
4.4.3. 工作任务
制定测试计划 项目经理、测试经理 必须 项目经理或者测试经理通过阶段工作计划确定本阶段的工作目标和内容，以及人力计划，时间计划，里程碑的设置等。 http://www.primeton.com/
第34页共44页
EOS应用开发过程参考手册
编写测试方案 测试经理 必须 测试方案应明确测试类型、测试的工作方法与要求、测试原则、测试环境的说明，BUG的管理方法等。 测试方案还应明确列出系统最终通过测试的各项标准或前提。 测试方案还应明确测试组的构成和人员职责。 对于开发和测试并行的情况，测试方案还应明确测试与开发的工作同步机制或应用发布策略（譬如：确定多长周期提取最新的开发功能部署到测试服务器上进行测试、测试人员测试的BUG与开发人员BUG修改和BUG验证的处理流程等） 测试方案应明确测试采用的具体工作和工具的使用说明（如果有独立的使用文档，则可以提示参见）。 测试环境准备 开发经理、测试人员 必须 根据测试方案搭建测试环境，建议测试环境的数据库与开发的数据库分离，以免测试对开发造成影响。数据库分离时，需要注意开发环境中数据库的变更要同步反映到测试环境中（由DBA实施）。而应用部署的测试环境，则可以直接在开发的集成服务器上进行。 测试任务分配 项目经理、测试经理、测试人员 必须 结合《系统功能分解与跟踪矩阵》以及测试方案的测试要求，项目经理和测试经理将组织测试组进行测试工作的分配。 本项工作的输出将体现在对《系统功能分解与跟踪矩阵》的修改中。 编写测试用例 测试人员 必须 测试人员针对分配的任务，结合设计说明书、需求规格、开发规范编写测试用例。每个功能点可从多个角度编写多个案例。另外，针对开发规范的要求，也需要形成测试案例。 系统测试 测试人员 必须 测试人员在完成测试案例编写后，根据开发团队的开发进度进行测试工作。测试过程中，注意BUG的记录。测试通过的功能点，及时更新《系统功能分解与跟踪矩阵》的进度。 编写测试报告 测试人员 必须 在测试工作基本结束时，测试组要编写测试报告，测试报告包括但不限于如下内容： ? 测试工作的过程总结 ? 测试的方法和测试内容说明 ? 测试的标准 ? 测试的质量报告 ? 测试的结论 测试进度跟踪 项目经理、测试经理 必须 项目经理将通过《系统功能分解与跟踪矩阵》了解测试的进度状况，测试经理应该适时提醒测试人员更新进度，同时根据测试的BUG状况了解系统的质量状况，对于测试中发现的某些共性问题，及时反馈到开发团队。 http://www.primeton.com/
第35页共44页