EOS应用开发过程参考手册
同时，在项目实施中，能够随时针对业务问题提供咨询和解答的用户方人员也可视为业务专家。或者项目组成员通过需求调研培养形成业务专家。业务专家从某种程度上代表用户视角，对于项目组交付一个让用户满意的系统能起到关键的作用。
3.2.5. 主程序员
主程序员负责带领程序员（构件包所有者）进行特定子系统中构件包的设计和开发，他是子系统的应用功能设计的负责人。另外，他还辅助架构师进行功能分解、页面原型设计等工作。
主程序员应当是在特定子系统方面有丰富经验的高级工程师，可以作为开发小组其他成员的技术导师。主程序员要求熟悉J2EE、WEB技术，对应用服务器、数据库编程有较深经验。或者具有EOS应用开发经验。
3.2.6. 构件包所有者
在EOS应用开发中，开发人员以一个构件包作为开发任务的接受单元，所以被称为构件包所有者，构件包所有者负责按照项目所采用的标准来进行构件开发（我们不采用XP的代码集体所有），并有义务对自己的工作成果进行单元测试。
主程序员在进行具体的开发工作时，同样也作为构件包的所有者，而其他的构件包所有者，一般要求有一定WEB编程经验，对需求和设计有良好的理解能力，善于学习，勤于钻研。
3.3. 支持角色
支持角色对项目实施起辅助作用，但并不表明此类角色在项目中可以缺失，在某种程度上，支持角色能够成为项目有效实施的强大后盾。
3.3.1. EOS专家
EOS专家是指精通EOS产品的技术专家，能够为项目组提供如下服务：
? 提供基于EOS的应用开发过程和项目管理方面的指导
? 结合应用要求和EOS特点的提供应用设计方面的咨询和指导 ? 帮助项目组建立结合EOS特点和应用要求的开发规范 ? 为应用开发中的技术课题攻关提供解决方案或指导 ? 为开发人员提供产品使用的培训和指导 ? 开发中故障的快速定位和处理
对于初次采用EOS进行项目开发的项目组，EOS专家往往是由普元公司的服务工程师担任，对于已经有EOS应用项目开发经验的项目组，由具有相关经验的人员担任。
http://www.primeton.com/ 第11页共44页
EOS应用开发过程参考手册
3.3.2. 配置管理人员
配置管理人员负责为产品开发团队提供全面的配置管理环境，如版本控制服务器等。他应确保配置管理环境有利于进行评审、更改和缺陷跟踪等活动。
配置管理人员可以由公司类似QA这样部门的人员担任。
3.3.3. 测试人员
在EOS应用的开发中，测试人员主要进行功能测试、集成测试、系统测试、验收测试、其他非功能性专项测试等，测试主要从需求规格和功能设计出发，以黑盒测试为主。
测试人员可以由独立于项目组的测试部门工程师担任，也可以由项目组的人员兼任，某些测试内容可能有用户的人员参与。
3.3.4. 系统管理员
系统管理员负责配置、管理和检修项目组专用的任何服务器（如应用服务器、数据库服务器）和网络，包括开发环境和任何指定的测试环境。另外，系统管理员具有系统级的配置调优能力。
系统管理员应该对各种操作系统、数据库、应用服务器的安装、配置、调优比较熟悉。
3.3.5. 数据库DBA
数据库管理员(DBA)负责将设计出的数据库模型部署到物理数据库中，并且在后续开发测试中，建立数据库的维护机制，负责将接受的数据库变更实施到数据库中并进行记录和及时通知相关人员。DBA还负责保证数据库的准确性和安全性。
3.4. 其他角色 3.4.1. 美工
美工的职责包括：进行网页美术设计和图片设计；应用程序的用户界面美术设计。对于产品型项目，还应负责产品包装设计及其他相关工作。
3.4.2. 文档人员
文档人员主要进行用户手册等用户文档的编写和编排。对于一般中小型的应用项目，一般不需要配备专职的文档人员，可以由测试的人员兼任。
http://www.primeton.com/ 第12页共44页
EOS应用开发过程参考手册
4. 开发过程阶段描述
为保证对各个阶段的描述有一个完整统一的描述方法，将采用“ETOCXT”的方法进行，具体方式如下：
? ? ? ? ?
Entry（进入条件）：为每个阶段定义清晰良好的入口条件；
Task（工作任务）：列出所有要实现的任务列表，名称，是否需要实现，任务描述； Output（输出内容）：阶段工作的输出产物以及评审内容；
Control Point（阶段控制点）：本阶段中为保证项目成功的关键控制点；
eXit（退出条件）：阶段结束时所要达到的结果，注意，阶段退出条件并不意味下一阶段进入条件，因为下一阶段可能在上一阶段并未结束的情况下就已经启动了； ? Template（参考模板）：本阶段可供参考的文档模板或参考案例 以下是相互关系图：
http://www.primeton.com/ 第13页共44页
EOS应用开发过程参考手册
4.1. 需求阶段 4.1.1. 概述
本阶段是应用项目的启动阶段，它主要完成应用系统需求的采集整理工作，形成系统设计和实现所需要的需求基线库。
对于签订客户合同的应用项目，需求调研工作的地点一般在客户的现场，这种情况下，项目组往往只确定了项目经理和需求调研的人员，项目团队还不完整。而对于开发应用产品性的项目，则应用开发过程的地点比较固定。对于这两种情况，项目团队的管理和工作方法均有一定的差异性，而在本参考中，只提供本阶段通用的工作说明，对于上面提到的差异性不做说明，需要项目组结合本参考内容的基础上充分考虑。
对于本阶段的工作，如图所示，详细的说明，参见“工作任务”章节。
需求阶段项目实施工作项目管理工作资料研究和需求初步整理组建项目团队制定项目实施计划进行需求调研评审不通过迭代编写需求规格建立项目管理方案制定项目实施和管理的相关模板进行需求评审
在上图所示的工作中，项目实施工作和项目的管理工作可以是并行的。另外，由以上的工作内容可以看出，实际上本阶段的工作，与是否采用EOS是无关的。
需求阶段的主要目标是明确应用的所有功能需求、非功能性需求和确定业务边界、整理出业务模型，然而这往往是一种理想的目标，实际上在进行需求调研时，配合参与需求调研工作的用户对于系统的需求并不是十分清晰，也是在讨论和碰撞中不断清晰明确的，由此导
http://www.primeton.com/
第14页共44页
EOS应用开发过程参考手册
致的需求不稳定性特点比较明显，表现为某些需求现阶段无法进一步细化，某些需求可能出现反复，某些需求现阶段无法确定是否需要实现等等。这种状况导致无法在人为确定的需求阶段中固化所有的需求内容，因此，对于项目组而言，在本阶段所掌握的需求内容基本充分，能够进行后续的设计工作，或者说，所不明确的需求，不足以影响系统的结构和目前工作的进展，那么，需求阶段的目标就算是基本达到了。
另外，在需求阶段，有时用户会要求提供一个应用的原型，希望在需求讨论的基础上，看到系统实现的基本效果。关于原型的实现，我认为属于设计的工作，将在设计阶段进行描述，但并不妨碍将这部分的工作在需求过程中完成。
4.1.2. 进入条件
? 确定项目经理和需求调研人员
? 需求工作的条件成熟：有初始的需求材料（如合同等），与用户确定了具体的需求
调研安排
4.1.3. 工作任务
组建项目团队 项目经理 必须 组建项目团队是项目启动的标志，一般公司会为项目任命（或指定）项目经理，然后由项目经理来申请其他的团队成员，在项目团队组建初期，并不能明确这个项目中的所有资源，只会确定重要的角色（如开发经理、架构师等）以及即将开始的需求工作的参与人员。 需求调研人员建议由项目经理，开发经理，业务专家、架构师等人员组成。 另外，需要强调的是，项目团队不仅仅包括项目经理所管辖的人员，有时还需要包括对项目起支持作用的组织或成员。有时甚至会有一个对等的用户项目组参与项目（主要承担配合、监控、质保等职能），项目团队同样包括这些人。 制定项目实施计划 项目经理 必须 应用项目往往有时间进度的要求，一般都明确了系统的上线时间，在项目合同签订后，用户要求提供针对上线时间安排倒推的项目总体实施计划，所以制定项目总体实施计划是项目经理开始介入项目工作后的重要事情。 总体计划将包括项目阶段的划分，以及项目各个阶段的时间计划、大致的资源需求、工作地点等等。 制定的总体计划需要获得用户和本公司项目主管领导的认可，这样才能便于用于的工作协调和配合，以及公司的资源调配。 另外，由于当前阶段处于需求阶段，在确定总体计划的同时也需要制定需求阶段的详细工作计划。 研究资料和需求初步整理 需求调研人员 可选 在与用户开始正式的需求调研工作之前，利用一定时间针对已掌握的资料（如项目合同的功能需求和系统建设要求等）进行学习，同时，需求调研组还可以在需求规格书模板基础上针对已有资料进行初步的需求整理，整理工作可以达到以下目标： http://www.primeton.com/
第15页共44页