EOS应用开发过程参考手册
作为项目配置管理服务器。（注意：由于CVSNT不够稳定，建议不要使用CVSNT） 配置管理的目录规划要求清晰方便，以下是供参考的目录结构（以CVS为例）： CVSROOT. ——CVS根目录 └─cson ——项目根目录，以项目简称为目录明 ├─doc ——文档根目录 │ ├─1-需求管理 │ │ └─会议记录 │ ├─2-系统设计 │ │ ├─database │ │ ├─demo │ │ ├─会议记录 │ │ └─接口设计 │ ├─3-系统开发 │ ├─4-系统测试 │ ├─5-实施验收 │ ├─参考资料 ——存放与本项目内容无关的技术资料或者参考资料 │ └─项目管理 │ ├─项目周报 │ ├─项目模板 │ └─项目计划 └─src ——源码根目录 ├─csw ——子系统csw项目工程目录 ├─csm ——子系统csm项目工程目录 └─csi ——子系统 csi 项目工程目录 通常，项目配置管理的方案由项目组制定，具体的实施（如配置初始化、用户权限分配等）则由公司的配置管理部门完成。 组织设计评审 项目经理、设计组、业务专家 必须 当设计的工作完成时，项目经理需要组织设计组进行评审工作，评审一般采取正式的评审会议和走查相结合的方式，评审可以： ? 了解设计中存在的缺陷或者模糊，并进行修正 ? 确定设计工作是否存在遗漏，并进行补充 ? 通过评审，让参与人员完整了解设计的各个部分的内容，对于不属于自己设计的部分，是一次学习的过程 ? 设计在评审中基本通过，是系统全面进入开发阶段的里程碑 另外，对于评审有如下建议： ? 建议让用户方的技术人员参与评审工作，并取得对方的认可 ? 评审会议中，要记录下评审意见，并确定处理方案和计划 ? 评审工作不要流于形式，评审工作并不是指一次评审的会议，而是包括会议以及对设计评审意见处理的过程
http://www.primeton.com/
第26页共44页
EOS应用开发过程参考手册
4.2.4. 输出内容
? ? ? ? ? ? ? ? ? ?
数据库设计（ER关系）、业务字典定义 系统静态原型 系统设计说明书 系统功能分解矩阵
经过项目客户化后的EOS模板文件 项目配置管理方案
技术课题预研的结论或者使用指南 EOS初始项目源码 项目开发规范 设计阶段计划
4.2.5. 阶段控制点
设计阶段是系统实施的重要阶段，设计的完整性和合理性直接决定了系统的扩展能力、易用性、和系统运行效率。对于项目组而言，本阶段的主要控制点包括：
? 确保系统设计的质量：
对于良好的系统设计，应该满足如下要求： 1） 应用总体设计思路清晰，应用结构简洁合理
2） 功能设计可实现性强：通过查看原型、对应的数据库设计和功能设计文档，功
能实现者（开发人员）比较清楚用户界面的信息、对应操作的数据实体、应用处理的流程、相关的隐含规则、界面流转关系等等
3） 完整统一、操作性强的项目开发规范：这是保证项目满足非功能性需求和系统
质量的重要工具，需要确保开发规范的内容尽可能覆盖项目实施的各个环节，同时所提供的规范内容具有较强的操作性，而不至于流于形式。
? 有效合理的需求变更控制：
在本阶段，需求阶段所遗留的不稳定需求对本阶段会有较大的影响，一方面需要花费时间来讨论这部分需求导致设计阶段进度延误，另一方面需求的变更可能会导致系统设计的变化，因此，项目经理和有经验的设计人员要充分评估这些变更对项目的影响，对于可能影响项目进展而需求重要程度较低的变更，项目经理要懂得让用户放弃这种变更或者采用双方可接受的变更方式。
4.2.6. 退出条件
? 系统设计工作内容通过评审
4.2.7. 参考模板
? 《系统设计说明书》参考模板
http://www.primeton.com/ 第27页共44页
EOS应用开发过程参考手册
? 《项目开发规范》参考模板 ? 系统静态原型
? 《功能分解与跟踪矩阵》参考模板
4.3. 开发阶段 4.3.1. 概述
本阶段是应用的实现阶段，主要的工作就是针对设计进行实现，开发过程可以采用结对编程的方式，由一个富有经验的主程序员带领1、2名构件包所有者形成一个开发小组，负责开发某个主题所包含的构件包。同时，主程序员也有能力在开发过程中及时发现设计阶段的失误。
开发阶段可能在设计进入到一定程度就启动了，本阶段的工作内容比较单一，主要以构件包开发为主（实际上往往由于设计阶段工作的不充分或者设计失误，会在一定程度上影响本阶段的工作，形成设计的反复），以下是工作步骤图：
http://www.primeton.com/ 第28页共44页
EOS应用开发过程参考手册
开发阶段项目实施工作项目管理工作制定项目阶段计划应用功能开发任务分配功能实现（构件包开发）构件实现走查迭代项目进度跟踪构件单元测试提交开发结果应用部署包导出构件文档生成 在以上的开发过程中，开发小组内部和开发小组之间需要定期和不定期的进行交流沟通，以确定开发中一些共同的开发约定（或称为实现模式）、或者商议形成公共的构件，以及交流开发的心得体会，这样无论是对于开发新手或者是有经验的程序员，都是一个学习和提升的机会，也有利于形成团队互相学习和互相帮助的氛围。
另外，在上阶段数据库设计完成并部署到数据库服务器后，建议项目组确定专门的DBA，在开发期间对数据库的变更都需要通过DBA来实施，实施的流程如下：
a) 开发人员或设计人员向DBA提出变更要求（最好提供变更的脚本） b) DBA更改数据库设计（PDM文件） c) DBA进行数据库变更，并做好变更记录 d) DBA通知所有相关人员（邮件方式）
http://www.primeton.com/ 第29页共44页
EOS应用开发过程参考手册
4.3.2. 进入条件
? 设计所提供的内容已经明确，可以进行实现 ? 开发环境已经确定 ? 开发人员到位
4.3.3. 工作任务
制定项目阶段计划 项目经理 必须 项目经理通过阶段工作计划确定本阶段的工作目标和内容，以及人力计划，时间计划，里程碑的设置等。 应用功能开发任务分配 项目经理、开发经理、主程序员 必须 针对设计阶段完成的《系统功能分解与跟踪矩阵》，项目经理和开发经理将组织开发组进行开发的优先级和工作量的评估，并在此基础上进行开发工作的分配。分配时将开发团队分成几个由主程序员担任组长的开发小组，每个开发小组人数为2-4人（含主程序员） 开发任务的分配原则： ? 工作量基于功能点进行评估 ? 工作分配基于构件包进行，而且对于业务类似、实现方式相近的构件包也尽可能分配个同一个构件包所有者或者主程序员所带领的开发小组的其他成员。 本项工作的成果将体现在对《系统功能分解与跟踪矩阵》的修改中。 构件包开发 主程序员，构件包所有者 必须 使用EOS进行功能开发的过程，包括了页面开发、展现逻辑开发、运算逻辑开发，视功能的需要，还可能包括了运算逻辑、handle以及TAG的开发工作。如果进行了原型设计，则功能的页面则根据原型页面转入到项目中变为对应的jsp页面。 如果设计阶段针对EOS提供的模板进行了改写，形成了项目级的模板，则开发前通过EOS Studio将模板导入到自己的工作空间。开发过程中如果使用EOS提供的向导生成功能，一方面要考虑通过向导生成的逻辑是否与其他功能的逻辑可以开发成为一个公共的构件，以提高系统中构件的复用度，另一方面，如果向导生成的功能中，有某些功能并不是应用系统需要的，则要清除这些无用功能，以免为项目留下冗余代码。另外，开发过程中，对于命名、注释、开发中的原则等要求，需要严格遵循项目开发规范中的约定。 开发中，主程序员除了本身承担一定量的开发工作外，还须对本组的构件包所有者进行适当的指导，并且时刻关注本组的工作进度和开发成果的提交、以及是否遵循了开发规范等情况。 构件单元测试 主程序员，构件包所有者 必须 根据敏捷开发的思路，一般功能的单元测试由开发人员自身完成，EOS应用的单元测试，同样建议由构件开发者完成，以缩短反馈周期。 单元测试的目标为实现满足系统设计对功能实现的要求，同时能够通过边界值测试、异常操作测试。 http://www.primeton.com/
第30页共44页