普元应用相关文档 - 图文

PRIMETON TECHNOLOGIES, LTD. 上海普元信息技术有限责任公司

EOS应用开发过程参考手册

For EOS 5.x

No part of this document may be reproduced, stored in any electronic retrieval system, or transmitted in any form or by any means, mechanical, photocopying, recording, otherwise, without the written permission of the copyright owner.

COPYRIGHT 2005 by Primeton Technologies, Ltd. ALL RIGHTS RESERVED.

EOS应用开发过程参考手册

欢迎使用

本手册为基于普元EOS产品进行应用的项目组提供了应用开发过程的参照性指导文档，以帮助EOS的用户更加细致了解基于EOS开发企业应用的过程。另外，结合项目实施的现状，本文档着重描述了开发阶段所需要做的各项工作，对于各阶段中角色的分工相对进行了弱化。

本出版物包含Primeton的专利信息，它在许可协议下提供，并受版权法保护，本出版物包含的信息不包括任何产品保证。

通过您当地的Primeton代表或分部可订购出版物，或致电021-50805188订购出版物 当您发送信息给Primeton后，即授予Primeton非专有权，Primeton对于您所提供的任何信息，有权利以任何它认为适当的方式使用或散发，而不必对您负任何责任 ? COPYRIGHT 2005 by Primeton Technologies, Ltd. ALL RIGHTS RESERVED.

本书的相关文档

您可能会发现下列资料对您有用：

格式使用约定

本书对文本格式的使用有如下约定：

粗体： 表示突出显示，或可视化操作中的文字 【***】 可视化操作中的选项

http://www.primeton.com/ 第2页共44页

EOS应用开发过程参考手册

文档修订和审批记录

序号 01 02 03 版本号 0．1 0．2 1．0 修订日期 2005-09-26 2005-09-29 2005-09-30 修订概述 初稿 并行增补 文档集成、整理 修订人 袁义 温昱 袁义 审批人 职位 日期

http://www.primeton.com/ 第3页共44页

EOS应用开发过程参考手册

目 录

1. 引言.............................................................................................................................................. 6

1.1. 目的 ................................................................................................................................... 6 1.2. 目标读者 ........................................................................................................................... 6 1.3. 术语与缩写 ....................................................................................................................... 6 1.4. 配套文档 ........................................................................................................................... 7 1.5. 参考资料 ........................................................................................................................... 7 1.6. 其余部分的结构 ............................................................................................................... 7 2. EOS应用开发过程 ...................................................................................................................... 8 3. EOS应用开发的角色 .................................................................................................................. 9

3.1. 概述 ................................................................................................................................... 9 3.2. 关键角色 ......................................................................................................................... 10

3.2.1. 项目经理 .............................................................................................................. 10 3.2.2. 开发经理 .............................................................................................................. 10 3.2.3. 架构师 .................................................................................................................. 10 3.2.4. 业务专家 .............................................................................................................. 10 3.2.5. 主程序员 .............................................................................................................. 11 3.2.6. 构件包所有者 ...................................................................................................... 11 3.3. 支持角色 ......................................................................................................................... 11

3.3.1. EOS专家 .............................................................................................................. 11 3.3.2. 配置管理人员 ...................................................................................................... 12 3.3.3. 测试人员 .............................................................................................................. 12 3.3.4. 系统管理员 .......................................................................................................... 12 3.3.5. 数据库DBA ........................................................................................................ 12 其他角色 ............................................................................................................................... 12 3.4............................................................................................................................................ 12

3.4.1. 美工 ...................................................................................................................... 12 3.4.2. 文档人员 .............................................................................................................. 12

4. 开发过程阶段描述 .................................................................................................................... 13

4.1. 需求阶段 ......................................................................................................................... 14

4.1.1. 概述 ...................................................................................................................... 14 4.1.2. 进入条件 .............................................................................................................. 15 4.1.3. 工作任务 .............................................................................................................. 15 4.1.4. 输出内容 .............................................................................................................. 17 4.1.5. 阶段控制点 .......................................................................................................... 17 4.1.6. 退出条件 .............................................................................................................. 18 4.1.7. 参考模板 .............................................................................................................. 18 4.2. 设计阶段 ......................................................................................................................... 18

4.2.1. 概述 ...................................................................................................................... 18 4.2.2. 进入条件 .............................................................................................................. 21 4.2.3. 工作任务 .............................................................................................................. 21

http://www.primeton.com/

第4页共44页

EOS应用开发过程参考手册

4.2.4. 输出内容 .............................................................................................................. 27 4.2.5. 阶段控制点 .......................................................................................................... 27 4.2.6. 退出条件 .............................................................................................................. 27 4.2.7. 参考模板 .............................................................................................................. 27 4.3. 开发阶段 ......................................................................................................................... 28

4.3.1. 概述 ...................................................................................................................... 28 4.3.2. 进入条件 .............................................................................................................. 30 4.3.3. 工作任务 .............................................................................................................. 30 4.3.4. 输出内容 .............................................................................................................. 31 4.3.5. 阶段控制点 .......................................................................................................... 32 4.3.6. 退出条件 .............................................................................................................. 32 4.3.7. 参考模板 .............................................................................................................. 33 4.4. 测试阶段 ......................................................................................................................... 33

4.4.1. 概述 ...................................................................................................................... 33 4.4.2. 进入条件 .............................................................................................................. 34 4.4.3. 工作任务 .............................................................................................................. 34 4.4.4. 输出内容 .............................................................................................................. 36 4.4.5. 阶段控制点 .......................................................................................................... 36 4.4.6. 退出条件 .............................................................................................................. 36 4.4.7. 参考模板 .............................................................................................................. 36 4.5. 集成、部署阶段 ............................................................................................................. 36

4.5.1. 概述 ...................................................................................................................... 36 4.5.2. 进入条件 .............................................................................................................. 37 4.5.3. 工作任务 .............................................................................................................. 37 4.5.4. 输出内容 .............................................................................................................. 39 4.5.5. 阶段控制点 .......................................................................................................... 39 4.5.6. 退出条件 .............................................................................................................. 39 4.5.7. 参考模板 .............................................................................................................. 40

5. 其他............................................................................................................................................ 40

5.1. 人员管理 ......................................................................................................................... 40 5.2. 进度管理 ......................................................................................................................... 41 5.3. 并行开发 ......................................................................................................................... 42 6. 小结............................................................................................................................................ 44

http://www.primeton.com/ 第5页共44页

EOS应用开发过程参考手册

1. 引言

1.1. 目的

本手册旨在为基于EOS产品的项目实施提供开发过程的参考。

本手册汇集了普元公司多年卓有成效的项目规划、实施和上线的最佳实践，建议基于EOS的项目采用。当然，这并不意味着本文档所描述的方式是EOS应用开发的唯一方法。

1.2. 目标读者

本手册的目标读者为采用EOS 5.x产品进行应用开发的所有项目组成员，具体角色包括项目经理、开发经理、架构师、业务专家、开发人员、测试人员等。

1.3. 术语与缩写

EOS

EOS Component

普元公司的核心产品名称，是面向构件的应用软件平台。 EOS提供了一个包括页面，展现逻辑，业务流程，业务逻辑，业务方法，数据逻辑等六种构件。

是EOS系统发布、复用的基本单位，它由一组相关的EOS构件组成，能够完成相对独立、完整的业务功能。EOS构件包中可以包含一个或多个的EOS构件在EOS应用中，它相当于一组有关系的构件的容器或命名空间(Namespace)。同一个构件包的构件不能重名。EOS平台对构件的调用也是首先通过包名来定位构件所在的包。

基于EOS产品所开发的应用系统 。

EOS Package

EOS Application

EOS Runtime Environment

EOS运行和管理环境是一个独立的EOS应用程序，可以部署在一个独立的EOS Server上，集中管理（包括部署、监控，察看日志等）位于不同的物理机器上的EOS 应用程序；也可以在每台EOS Server上都部署一个EOS Manager来实现分散式部署与管理，即只管理本 EOS Server上的EOS应用程序。

EOS Development Environment 普元EOS开发环境中包括EOS Studio（集成开发环境）、

EOS Server（运行/调试服务器）、版本控制库三部分组成。

EOS Studio 为用户提供基于向导的应用开发环境，包括数据构件定

义、业务逻辑开发、展现逻辑开发、业务流程开发、JSP页面开发、Bizlet开发、调试、应用部署。

http://www.primeton.com/

第6页共44页

EOS应用开发过程参考手册

EOS Server

XML Data Bus

EOS运行引引擎,负责在调试及运行期间对构件进行执行和管理。

作为EOS平台的一个特性，EOS的各种构件通过XML数据总线进行相关数据的交互，从而以数据流的方式来推动业务的进行。EOS的XML数据总线包含展现数据总线和业务数据总线。

1.4. 配套文档

与本文档配套提供如下项目实施过程参考模板： 《系统需求规格说明书》 《系统设计说明书》

《系统测试方案与测试案例》 《系统测试报告》

《应用系统用户使用手册》 《应用系统维护手册》 《项目开发规范》

与本文档配套提供如下项目管理方面的参考模板 《项目管理方案》 《项目周报》 《会议纪要》

《系统功能分解与跟踪矩阵》 《需求调研会议记录》 《需求变更方案》 《项目需求变更表》

1.5. 参考资料

标题 《普元构件规范》 《特征驱动开发方法》 项目文档模板 版本 0.8 2005-9-15 日期 来源 EOS6定位组 机械工业出版社 普元实际项目的输出文档 1.6. 其余部分的结构

本文档的其余部分，将依次阐述下列内容：

http://www.primeton.com/

第7页共44页

EOS应用开发过程参考手册

? ? ? ? EOS应用开发过程 EOS应用开发的角色 开发过程阶段描述 其他最佳实践

2. EOS应用开发过程

EOS应用是典型的J2EE企业应用，所以EOS应用的开发过程将以J2EE企业应用开发过程为参照并结合EOS的特点进行说明。一般而言，对于J2EE的企业级应用的开发，可以划分为如下内容：

? 需求： 明确软件开发的任务，形成所有相关涉众（如客户、用户、项目组）共同

认可的软件需求规格。需求规格需明确功能需求、质量属性、约束条件等需求的所有方面。

? 设计：针对需求进行分析设计，形成项目组的设计说明书和功能清单。 ? 开发：在设计说明的指导下完成应用的实现。 ? 测试：针对实现的应用进行系统良好性的验证，可能包含的测试工作如：功能测试、

系统测试、集成测试、性能测试等。

? 集成、部署：主要完成系统在用户环境中上线，并通过用户培训，将应用系统交付

用户使用。

应用开发中，针对以上工作，一般都划分为一个独立阶段，然而，各个阶段仅仅表明一个工作的重心和职能以及阶段间的顺序，并不代表着各个阶段的工作是串行的。实际上，各个阶段在不同的应用项目中，不同程度存在一定阶段重合（并行）或者迭代现象。如下图：

项目开发周期0需求设计项目阶段开发测试集成部署

对应用开发过程进行阶段划分的主要目标还是便于界定各个阶段的主要工作内容，而不在乎你是否把属于该阶段的工作放到上一阶段中，或者干脆将某两个阶段合并为一个阶段。需要关注的是相关的工作是否串行和对其他工作是否存在依赖型。

http://www.primeton.com/

第8页共44页

T1T2T3T4T5T6T7 EOS应用开发过程参考手册

本文档旨在为EOS应用项目的开发团队提供一种轻量级的敏捷开发方法，对于开发过程的描述，除了与应用开发和项目实施密切相关的工作内容以外，还将包括保障项目实施的各种项目管理方法和手段。另外，在对各个阶段的工作进行描述之前，先对EOS应用开发过程中可能涉及的各种角色进行简单的说明。

3. EOS应用开发的角色

3.1. 概述

我们可以认为，应用软件项目一般是由人、过程和技术（包含与技术配套的工具）组成的，采用的技术和工具固然重要（能够满足发展需求并最大化团队生产率），过程也是一样（能够保障项目实施有序进行），但从某方面而言，最重要的因素是人，因为系统所有的一切都是关于人的。试图用过程或技术取代人的做法是愚蠢的，因为技术也好，过程也好，没有项目组人员的支持和参与，就不会发挥出相应的作用。在EOS项目中，对于项目成员角色的定义与其他的J2EE项目的角色定义几乎是一致的，只是在某些角色的职责方面有一定的差异。以下将分关键角色、支持角色和额外角色分别进行说明。

另外，需要强调的是，角色代表着项目组的一种职责，并不意味着不同角色都必须由不同的人分别承担，细分角色的目的是为了了解在应用项目实施过程中，存在哪些工作需要由什么样知识结构、经验、技能的人承担。通常情况下，会根据项目的大小，人员的投入情况以及成员的个人能力和经验差异，某个人会承担一个或多个角色。例如，某些小型项目的项目经理可能主要的职责是管理项目开发团队和控制项目的开发进度，而他同时可能是具有较强业务知识的业务专家，同时又具有较深的技术根底，兼任项目的开发经理的职责。

总之，角色就象帽子，具体人与角色可以是一对多的关系。

http://www.primeton.com/

第9页共44页

EOS应用开发过程参考手册

3.2. 关键角色

关键角色是项目实施过程的主体，是实现应用系统从无到有的生产者和管理者，是项目实施成功与否的直接关系人。项目的绝大部分活动都是关键角色完成的。

3.2.1. 项目经理

项目经理是项目的行政领导，负责报告进度情况、管理预算、凑措人员，以及协调设备、场地、资源等。作为项目的操作者和维持者，项目经理的工作是创造和维持一个良好的环境，使项目组运行在最佳状态。

项目经理一般由有良好项目管理知识、具备实际项目管理经验，良好的协调沟通能力，较强的客户服务意识，同时具有超凡人格魅力的人员担任。

3.2.2. 开发经理

开发经理又称为技术经理，他辅助项目经理进行应用开发过程的控制。他在其他角色的配合之下，负责对进入条件、退出条件、项目输出的技术把关。另外，开发经理作为技术能手，还将主要关注技术风险、技术攻关点、技术能力搭配、知识积累及软件过程改过辅助等等

开发经理应当有良好的技术功底，同时具备较多的项目实施经验，对软件过程有较深的理解，尤以通才为佳。

3.2.3. 架构师

他应当为项目的技术方案负责。当有风险较大的技术问题时，架构师应成为技术课题攻关的带头人。

在基于EOS的应用开发中，架构设计师的主要职责：在熟悉EOS所提供的应用框架基础上，结合项目要求、J2EE特性、EOS产品功能，以及现有的构件资源（可能是EOS提供的、或者是以往的EOS项目积累的），设计出系统的最优（工作量最小、实现最简单、应用的结构最合理、系统复用度最高）总体实现方案和适用项目的应用架构。具体而言，他应按照面向构件的思想，将解决方案空间合理地分割成不同的构件、确定构件的粒度、描述构件的接口、确定构件之间的协作关系、并充分考虑构件的并发和构件的分布。

架构师应该由具有较强的J2EE系统设计经验，对EOS体系和功能较为熟悉的人担任。

3.2.4. 业务专家

业务专家是具备业务领域知识的人才，他对项目所涉及的业务知识比较清楚，对用户现有的IT系统的功能等也比较熟悉，他负责辅助其他角色建立业务模型，并对最终业务模型评审把关。

在大多数情况下，担任业务专家的人员还应该具备一定的业务建模知识，懂得如何建模的人才知道如何简化工作。在项目中，具有类似项目经验的技术人员也可以作为业务专家，

http://www.primeton.com/

第10页共44页

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页

EOS应用开发过程参考手册

? 形成一致的需求调研工作思路和需求规格编写方法 ? 形成需求调研的问题清单和与用户进行需求沟通的基础文档 通过该项工作，将使得接下来的需求调研工作有的放矢、事半功倍。 进行需求调研 需求调研人员 必须 需求调研人员在用户确认后进入到调研现场，由项目经理负责组织与用户的需求调研工作。一般配合需求调研工作的用户还有其他的业务工作，需求沟通的时间安排往往比较紧凑，沟通通常以会议的方式进行。每次沟通之前要确定一个主题（不可能一次会议能把所有的需求都讨论完），会议过程要做好记录，会议结束时要进行简单的总结，尤其将一些结论性意见进行归纳并得到用户的口头确认，同时确定某些遗留工作和后续的工作安排。会议结束后按照统一的格式整理会议纪要，发送给与会相关人员，以及得到用户方负责人的确认（最好能够签字认可）。 需求调研的内容包括功能范围、功能的业务规则和实现要求、业务处理流程、交互数据内容的数据类型、与其他系统的接口、接口方式、接口数据项和格式要求，以及系统实现上的技术要求等等…… 编写需求规格 需求调研人员 必须 在进行完一次需求调研的沟通会议后，应该及时进行消化，并以文档的形式沉淀到需求规格说明书中，同时将需求沟通中未涉及或未明确的问题再次整理到问题清单中，通过电话、邮件、或会议方式让用户进行澄清。 编写需求规格的过程实际上就是需求分析的过程，需要针对用户的原始需求进行一定的业务抽象和需求点归类，以便切分和分解形成不同层次的需求点。需求规格包括了应用系统的功能需求、非功能性的需求，以及需求调研形成的数据字典和公共词汇。功能需求一般要描述出系统用户的操作和系统的响应，以及业务规则、业务流程。 以上两个工作在需求调研的过程中是迭代进行的，直到项目组认为需求基本明确，或者主要需求明确，能够进行后续的工作。 进行需求评审 需求调研人员、用户 必须 需求调研组认为应用的需求范围和需求内容基本确定，而且需求规格基本形成后，项目经理应该组织用户对需求进行评审，评审可选择会议评审或者需求走查。 需求评审后对于有误的内容要进行更正或者重新调研的工作，对于目前无法确定的问题要形成遗留问题列示在附件中，并确定大致的处理时间计划。 最终审核通过的需求规格说明书需要获得用户的签字认可（可提供一份需求认可书进行签字）。 建立项目管理方案 项目经理 可选 建立操作性强的项目管理方案是保障项目有序进行的重要工具，也是协调项目相关组织、人员关系的重要依据。也有助于新进入项目的成员尽快进入工作角色。项目管理方案包括但不仅限于以下内容： ? 项目的组织结构和分工界面：有助于明确相关组织、角色、人员的工作职责 ? 项目的内外部协调机制：例如例会机制，沟通机制、工作周报等 ? 项目的争议机制：当项目组与用户方发生争议（例如需求不明确导致的争议、实http://www.primeton.com/

第16页共44页

EOS应用开发过程参考手册

现方式争议等）时的解决机制 ? 需求变更的流程 ? 项目风险方案：列出项目实施可能存在的风险以及规避措施等 ? 项目团队人员名单及联系方式 制定项目实施和管理的模板 项目经理，开发经理 必须 项目文档是项目团队沟通的载体，而良好的模板方便项目成员的编写，也有助于阅读人员的理解。项目模板包括项目实施的过程文档模板和项目管理的模板，包括但不仅限于以下内容： 项目实施过程模板： 《项目需求规格说明书》 《项目系统设计说明书》 《系统测试方案和测试案例》 《系统测试报告》 《应用系统用户使用手册》 《应用系统维护手册》 项目管理模板 《项目工作周报》 《会议纪要》 《项目评审报告》 《项目验收报告》 不一定所有模板都要在本阶段完全确定，也可以考虑本阶段暂时确定当前迫切需要的模板。

4.1.4. 输出内容

? ? ? ? ?

《需求调研的会议纪要》 《项目需求规格说明书》 《项目实施总体计划》 《项目管理方案》 《需求变更控制表》

4.1.5. 阶段控制点

由于该阶段是项目的启动阶段，项目团队刚刚建立尚不完整，对于客户而言，非常关注项目的进度计划，对于项目组所在公司而言，在关注项目进度的同时，也关心项目的需求范围。对于项目经理而言，本阶段的主要控制点在于：

? 需求范围的控制：因为在与用户进行需求调研的基础一般是项目的合同文本，往往

合同对项目的功能范围只是做了粗略的描述，这些内容需要通过调研工作进行细化和明确，功能细化的程度往往对工作量的影响很大，在调研中需要掌握需求的主次，避免对非重要功能的需求过度复杂化（要知道一个功能做到不同程度，付出的工作

http://www.primeton.com/

第17页共44页

EOS应用开发过程参考手册

量的差异是很大的），同时思考某个功能点的需求可能带来的工作量和付出这种工作量对项目整体而言是否值得（这就是让系统架构师和开发经理参与需求调研的重要意义）。要明白，在用户理解付出代价的情况下合理有效的需求控制一定会得到用户的支持。

? 项目资源的协调：在本阶段，将会确定项目实施的总体计划，保证计划能得以正常

执行的前提是有效的资源保障。资源的稀缺性是项目的重要特征，项目经理要和公司充分沟通资源的安排和投入时间，以保证项目按照计划正常实施。

4.1.6. 退出条件

? 《项目需求规格说明书》获得用户签字认可。

? 项目组所明确的用户需求基本完备，能够进入到设计阶段。

4.1.7. 参考模板

? ? ? ? ? ?

《项目需求规格说明书》 《需求调研会议纪要》 《项目工作周报》 《项目管理方案》 《需求变更方案》 《需求变更控制表》

4.2. 设计阶段 4.2.1. 概述

设计阶段是应用项目实施的重要阶段，它是将用户需求转发为应用系统技术实现的重要环节。设计的过程，是将用户需求涉及的功能、数据、流程等业务的信息，运用业务和技术的眼光进行抽象，映射成技术实现内容的过程，一方面，经过抽象后系统横向切分为不同的应用系统功能，从而保证这些功能即能够覆盖用户的业务功能需求，又能体现业务模型的可扩展能力和低耦合度，另一方面，经过抽象后的系统从纵向切分为不同的层次，有利于实现时的分工合作，同时降低技术层次的耦合性，利于技术层面的扩展。下图表现了一个系统经过设计后用户和实现人员的不同视角

http://www.primeton.com/ 第18页共44页

EOS应用开发过程参考手册

这样我们就很容易理解，当我们选择J2EE实现用户的应用系统时，对于设计工作，一方面要从技术层面设计一个应用架构来实现应用软件的层次封装，在开源领域，目前有很多种应用架构的成果，但往往只是解决了应用框架中一部分的问题，需要组合或者自行设计完整的应用框架结构，例如，可能选择Hibernate+Struts+Spring经过整合后的框架作为应用的框架，或者采用项目组自行封装的应用框架实现。另一方面要针对用户的需求进行业务的建模和抽象，形成系统对应与数据库的数据对象模型和java的对象模型。在采用EOS实现J2EE应用时，由于EOS已经提供了一套完整的应用软件框架，使得在设计阶段无需考虑应用架构的问题，同时也不用考虑业务模型与java对象抽象的工作。这也是EOS应用开发与传统J2EE应用开发在设计阶段工作方面最大的差别。 对于EOS应用的设计内容，主要的重心在于业务模型的抽象（可理解为业务架构）、构件包的划分以及功能点的细分，这样让设计人员能够从考虑技术架构和OO模型的稳定、优雅和是否符合力学原理的泥沼中解脱出来，将主要的精力花费在考虑业务模型的抽象和扩展能力上（也有助于设计人员从技术思维转向业务思维，或许我这种说法对于热衷于技术研究的设计师会不以为然，但如果设计师跟用户沟通时如果屡屡提及对象、设计模式等词眼未必能让用户对于系统的设计思路有多清晰的理解）。 所以，对于EOS应用的设计，应多多考虑的具体工作包括：数据库的设计、用户的界面表现和整体风格、功能的切分、功能（页面）的流转方式、应用处理的流程或规则、系统权限的控制、与外部系统的接口等等，分解成本阶段的工作步骤如下图所示：

http://www.primeton.com/ 第19页共44页

EOS应用开发过程参考手册

设计阶段项目实施工作项目管理工作制定项目阶段计划系统总体设计技术课题攻关制定项目开发规范页面框架设计数据库设计（业务建模）制定和实施项目配置管理方案系统功能分解功能设计任务分配页面原型设计评审不通过开发环境准备应用功能设计组织设计评审 在上图中，描述了设计阶段的各项工作以及工作之间的大致关系，在设计阶段，首先需要进行系统的总体设计，形成系统的总体结构和总体要求，通过此工作，可以从系统全局的高度分解出系统设计的各项具体工作内容，例如，存在哪些技术点的风险需要进行技术课题的攻关或预研，项目规范内容的总体要求，数据库设计前的业务对象模型（概念模型），应用的页面框架和美工设计要求等，通过总体设计工作，可以形成几条并行工作线，其中，制定项目开发规范将与数据库设计、页面框架设计、原型设计、功能设计等各个工作相互影响，一方面，项目开发规范的内容形成对这些工作的约束，另一方面，这些工作进行的过程中，某些约定或者要求会补充到项目开发规范中。有关各个步骤的具体内容和要求将在工作任务章节进行详细描述。 在本阶段中，以总体设计、数据库设计、页面框架设计、原型设计、功能设计为主线，其他工作内容作为对主线的辅助，保证设计的质量、或者对设计进行验证等等。需要说明的是，尽管列出了上述的很多工作项，在实际操作中，并不是每个工作项有人专职去做，而是根据项目组人员的具体情况，一人可能同时承担多项工作，并行处理。

http://www.primeton.com/

第20页共44页

EOS应用开发过程参考手册

另外，对于参与EOS应用设计的人员，建议对EOS的结构和开发方式以及相关资源有较好的理解，这样才能知道在设计中哪些工作不需要做了，哪些内容需要结合EOS产品的特点进行考虑。

4.2.2. 进入条件

? 已掌握应用项目的基线性需求，即使存在部分不确定的需求，但该部分飘浮不定的

需求不足以对应用架构产生大的影响； ? 设计人员到位，使得工作的开展有人力的保障。

4.2.3. 工作任务

制定项目阶段计划 项目经理 必须 项目经理通过阶段工作计划确定本阶段的工作目标和内容，以及人力计划，时间计划，里程碑的设置等。 系统总体设计 系统架构师、开发经理 必须 不要将系统总体设计的过程理解为完成系统设计说明书中相应章节文档的过程，总体设计如同高屋建瓴，为整个系统确定大体框架，和系统建设的目标。通过总体设计，将明确采用的技术路线、系统外部接口，以及形成下一步具体设计工作的内容和要求。 该项工作在开发经理带领下与系统架构师和项目组中其他有经验的设计人员共同完成，一般采用讨论会议的形式，形成项目组设计人员对系统一致的设计思路。 数据库设计 系统架构师、主程序员、业务专家 必须 数据库设计最好由参与了需求调研工作的数据库设计人员完成，对于小型项目（数据对象在50以内），可以由一个有较强数据库设计能力的人为主形成系统完整的业务对象模型（包含对象名称、主要数据项和对象关系的数据库概念模型），在此基础上设计组讨论通过后，再进行数据项的补充，以及定义形成物理数据模型。而对于中大型项目，则可以分为业务主题交给不同的设计人员完成概念模型，然后整合形成统一的系统概念模型后进行讨论。 在进行数据库ER设计的同时，要求同时收集整理形成系统的业务字典定义表，本项工作最终将输出数据库设计文件（例如PD工具产生的pdm文件）和《业务字典定义表》。 数据库设计工作推荐选择数据库建模的工具，例如PowerDesigner或者ERWin， 页面框架设计 开发经理、架构师、美工 必须 对于WEB应用，需要考虑系统用户界面的表现方式，例如页面的风格要求、菜单形式、页面布局模式、页面样式定义以及web资源（页面文件、图片文件、js文件、样式文件等等）的命名要求和目录规划等等，如果用户对于系统的界面效果有较强的要求，需要美工在WEB框架设计的指导下，形成应用的页面效果图和一套风格统一的样式。 由于EOS提供了基础的应用框架，包含了缺省的页面布局、菜单风格、页面样式等，http://www.primeton.com/ 第21页共44页

EOS应用开发过程参考手册

在进行应用的页面框架设计时，要充分考虑与EOS应用框架融合的问题。可以采用2种处理方案，方案一：在EOS提供的框架基础上进行补充扩展，例如，沿用EOS提供的样式定义，只是修改样式标记的效果定义（美工完成），这样修改后的样式使得EOS提供的应用功能（如权限管理）和应用本身的功能在风格上一致起来。另外，沿用EOS应用框架中js、图片、样式文件的目录等，方案二：应用完全自主定义页面框架，这样可以不受限于EOS的内容，采用这种方案的项目往往项目组已经有一些原有项目的WEB框架复用方案、或者认为EOS提供的WEB框架不符合应用项目的要求。 以上两种方案都是可行的，前者要求对EOS应用框架的内容有一定了解，采用这种方案将有助于降低项目在WEB框架设计的工作量，所以也是推荐的方式。 页面框架设计的工作成果可以体现在《系统设计说明书》和《项目开发规范》中。 系统功能分解 开发经理、架构师、主程序员、业务专必须 家 系统功能分解的工作包括： ? 针对需求和业务模型（数据库概念模型）完成子系统、一级和二级模块的划分，并完成模块编码，其中一级模块对应系统功能的一个业务主题，二级模块对应系统实现时的一个构件包 ? 针对二级模块对照业务需求分解功能点，并且完成功能点的编号 ? 功能分解的成果整理到《系统功能分解与跟踪矩阵》中。 划分构件包（二级模块）的原则：在考虑构件包功能相对独立的前提下关注构件包的规模，项目中构件包划分粒度太细或者太粗都不利于管理和复用，推荐的适度规模为一个构件包包含对3个以内业务实体和实体之间关系表的管理，当然，这不是严格的限定，而是需要设计人员来把握的。 分解功能点的原则：对于功能点的粒度定义为：在程序实现中基于业务操作的角度不可能再细分的功能单元，例如”课程管理”并不是一个功能点，只有细分到“增加课程“、“删除指定课程”、“删除符合查询条件的课程”这样的粒度才是一个功能点。分解完整后的系统功能点一定包含需求定义中的所有业务功能。 另外，对于某些不是由业务功能需求所带来的工作任务，也可以作为特殊的功能反映在《系统功能分解与跟踪矩阵》中。 在功能分解的过程中，还要考虑分解的功能是否已经由EOS提供的构件库实现或者由以往的EOS应用项目实现（譬如EOS已经提供了权限管理、组织机构管理，是否满足本项目的需求），或者在已有构件库实现的基础上进行扩展。对于此类功能，需要特殊标注，以便在考虑设计和实现的工作量时加以区别对待。 本项工作内容形成的《系统功能分解与跟踪矩阵》是项目实施过程的重要文档，从这个文档形成开始，所有与项目开发相关的工作的评估、分配和跟踪都是基于它完成。有关该文档的使用方法，将在参考模板部分详细说明。 功能设计任务分配 项目经理、开发经理 必须 针对上一步完成的《系统功能分解与跟踪矩阵》，项目经理和开发经理将组织设计组进行功能设计的优先级和工作量的评估，并在此基础上进行设计工作的分配。在进行任务分配的同时，开发经理需要结合前期整理的开发规范和总体设计内容对设计工作提出要http://www.primeton.com/

第22页共44页

EOS应用开发过程参考手册

求。 本项工作的成果将体现在对《系统功能分解与跟踪矩阵》的修改中。 页面原型设计 主程序员，构件包所有者 可选 页面原型设计即通过静态页面（html）方式实现系统的用户界面，页面原型将承载设计的如下信息： ? 系统的界面风格：如菜单形式、页面效果、页面布局形式等 ? 通过菜单和功能链接所体现出的系统的功能 ? 各个功能的界面表现形式、界面信息和信息输入（显示）方式、界面提供的功能链接或者按钮等 ? 功能与功能之间的链转关系 页面原型的详细设计要求可以写入到开发规范中，因为原型的绝大多数规范同样也是功能实现时的规范，所以在考虑原型规范时，要确定是否能够在开发时有很好的延续，这种延续包括：目录命名、界面内容、资源（js/css）等等，最好的做法是：开发时只需将html页面改为jsp页面，同时替换其中的静态数据部分就可以了。 另外，在设计静态原型时要考虑整个原型是一个整体（有统一的入口和链接关系），而不是每个功能单独提供，还要求能够脱离服务器使用，以文件包形式提供，这样可以很方便的向最终用户演示。（在很多项目中，页面原型设计被用户要求在需求阶段完成，作为需求规格的一部分，但这并不能说明该项工作属于需求阶段，而只是需求与设计结合起来了）。 良好的页面原型设计将有助于提升设计的质量，是系统设计说明书最佳的补充。原型设计是比较耗费时间的工作，在权衡进度与质量的要求情况下，对于系统中某些简单的功能或者与已设计的功能原型很类似的其他功能原型，可以不实现原型。 应用功能设计 主程序员，构件包所有者 必须 应用功能设计是这对分解后的功能点进行设计的过程，由于已经完成了数据库设计和界面（原型）设计，所以功能设计将侧重于原型和数据库设计所不能表达的内容，包括： ? 功能的隐含信息：在页面上无法体现的内容，例如在增加操作员功能的原型中，界面并不会体现出“增加时间、操作员ID”等数据项，这些信息是在业务逻辑处理时由系统增加的 ? 功能的处理流程：描述在界面上激活某个操作时系统的处理过程，对于简单的处理，可以通过文字进行描述，对于复杂的情况，则建议以序列图结合文字描述方式 ? 功能的业务规则：譬如业务编码方式、输入数据格式要求，数据验证格式等等 ? 功能对应的数据实体对象：该功能需要操作的数据库表和视图 从以上对功能设计的要求来看，相当于功能的详细设计，但设计过程主要考虑的是业务处理的流程和数据，而没有OO的对象设计概念，这也是EOS体系下进行系统设计的一个重要特点。 可以说，数据库设计、原型设计和功能设计是系统设计的有机整体，彼此之间相辅相成，在三者设计充分的情况下，在EOS上进行开发就显得比较简单了。但是如果没有进行页面原型设计，则要求功能设计时，详细描述功能对应页面的信息内容和输入/显示方式，布局要求等等，所有的功能设计将按照功能分解的层次整理到系统设计说明书中。 http://www.primeton.com/

第23页共44页

EOS应用开发过程参考手册

制定项目开发规范 开发经理、架构师 必须 项目开发规范并不是仅仅指导开发过程的规范，实际上整个项目实施过程中对于技术工作的要求都可以整理进来，包括了设计、原型、开发、测试以及文档编写等等，通过这个文档，形成对各项技术工作的指导，有利于形成项目组统一的工作方式，有利于开发出一个性能卓越，质量优良的系统，同时也便于系统的后期管理和维护。 制定项目开发规范的过程是渐进和迭代的，实际上从需求阶段就可以开始此项工作，将工作过程中的一些统一要求和做法加入到规范中，形成项目团队共同的规范要求，开发规范内容完善的方式有2种：一种是规划性的，在开始某些工作前先考虑对于工作的要求，另一种是改进或者补充，是指在具体的工作过程中，对于规范内容的补充或者改进，两种方式相辅相成，形成最终完整的项目开发规范。 关于项目开发规范的文档内容结构，没有统一的要求，可以在提供的参考模板上结合项目的情况进行补充或者删减。需要注意的是，规范中涉及到的内容必须是统一的，避免出现前后语义矛盾或者冲突的地方。 一般而言，项目开发规范将作为系统测试中对于非功能性要求的重要标准，制定它很重要，制定后的执行则更为重要，否则花费时间做了这个事情而不严格执行，还不如不做。另外，越早制定完整，对项目的帮助越大，如果一个规范性要求在进入到规范之前，已经在项目组形成了不同的做法，再要求统一到这个规范下，无疑要浪费很多的时间，例如，项目开发进行到一定阶段后，意识到要求统一日期时间的显示格式，而这是，每个开发人员都按照自己的方式处理日期的显示格式，这样，无论统一成那种格式，都会引起某些开发人员的改动工作。因此、项目开发规范要求在设计阶段就定义清楚。 开发环境准备 开发经理 必须 开发环境准备的工作包括： ? 准备开发时数据库服务器，并按照数据库设计初始化数据库表和视图，分配数据库用户（建议开发人员共享同一个数据库服务器，而不是每个开发人员各自连接独立的数据库） ? 开发时应用集成环境服务器的准备（应用服务器、EOS Server、以及应用环境的初始化） ? 对于开发环境的使用要求说明（可以放到项目开发规范文档中） ? 在EOS Studio中结合页面框架设计的内容对EOS的构件模板进行修改，并导出形成项目级的模板文件，以下是EOS提供的模板设计和开发结合的流程示意图： http://www.primeton.com/ 第24页共44页

EOS应用开发过程参考手册

分析设计人员开发人员数据实体设计导入模板页面布局模板页面向导模板管理CSS样式模板设计视图控件模板功能模板源代码视图展现构件开发业务构件开发导出模板分发模板页面调试构件调试 ? 通过EOS Studio初始化EOS项目工程，并导入到配置管理服务器中（推荐使用CVS），初始化的工作包括：建立项目（如果分为子系统，则按每个子系统建立一个项目）、建立项目中的构件包、为每个构件包导入对应的数据实体，这样，开发人员开发时，首先在STUDIO中从CVS导出项目，然后就可以在初始化的项目工程基础上进行开发。 【注意】：如果开发没有使用配置管理服务器，则可以在完成项目初始化后，通过EOS Studio导出源码工程，提供给开发人员进行导入。 技术课题攻关 架构师、主程序员 可选 在一个项目实施中，总会或多或少或大或小存在一定技术上的难点或风险，譬如，如果没有采用EOS，可能会考虑应用框架的整合工作。譬如，项目中要提供单点登录，需要对单点登录的技术方案进行技术预研等等。这些都统称为技术课题攻关，一般在系统进行总体设计后，由开发经理和架构师决定是否需要列出某些技术课题进行预研，预研过程可以由主程序员在架构师的指导下进行，通常会形成具体的技术提交物或者技术解决方案。对于技术提交物，还需要提供使用手册，包括实现的说明、使用的接口描述、是否存在技术风险等等。而通过评审的技术提交物，将直接进入到项目初始化工程中。 如果开发经理和架构师认为列出的技术风险是可控的，而且所花费的时间对项目的进度影响比较小，在设计阶段资源紧张的情况下，也可以将这些工作直接放到开发阶段中处理。 制定和实施配置管理方案 开发经理、配置管理人员 可选 从本阶段开始，项目组的人员规模在不断扩大，工作的产物也越来越多，为确保项目组工作成果的管理和共享，建议进行项目的配置管理。配置管理的对象包括项目的文档和源码，以及其他的项目中间产物。考虑到EOS Studio与CVS的良好继承性，推荐使用CVShttp://www.primeton.com/

第25页共44页

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页

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页

EOS应用开发过程参考手册

4.4.4. 输出内容

? ? ? ?

测试阶段计划

测试方案与测试案例 测试报告 BUG列表

4.4.5. 阶段控制点

在测试工作中，对于项目管理需要重点关注的事情包括： ? 测试的进展状况和与开发的工作协调，测试工作往往因开发的进度所影响，在没有

充分考虑好开发进度和测试协调的情况下，会出现比较严重的测试等待开发的状况，例如等待开发人员提交测试功能，等待开发人员对BUG的修正，项目经理要敏感地意识到问题原因，并及时联合开发经理与测试经理沟通工作的进度和开发测试工作的协调问题

? Bug的曲线走势和修正状况：通过对Bug的走势状况了解系统的质量情况和改进

状况。

? 需求变更的控制：变更管理一直是各个阶段的重要控制点，道理参见开发阶段控制

点的描述。

4.4.6. 退出条件

? 按照测试方案完成测试，系统基本达到测试目标

4.4.7. 参考模板

? 《系统测试方案与测试案例》参考模板 ? 《系统测试报告》参考模板

4.5. 集成、部署阶段 4.5.1. 概述

项目的开发工作基本结束，并且已经通过了测试，系统可以进行集成和上线了。集成是将开发出的系统部署到用户的环境中并实现与各个接口系统联通的过程，部署则是在集成、联调完成后确认系统可以使用后，进行系统初始化工作，使其成为生产系统的过程。对于此阶段的工作，针对不同项目的差异性较大，而且与开发过程相关性较小，因此仅做粗略的描述，以下是一般情况下的工作流程：

http://www.primeton.com/

第36页共44页

EOS应用开发过程参考手册

集成、部署阶段项目实施工作项目管理工作制定系统集成上线阶段计划编写用户文档系统部署和集成测试进行用户培训系统上线项目验收项目总结

本阶段是项目的收敛阶段，如果应用功能开发基本完整的情况下，实际上项目组的很多成员可能已经脱离项目组，而部分的开发人员和测试人员将会形成施工队伍，负责本阶段的具体工作。

4.5.2. 进入条件

? 系统经过内部的测试，具备在用户环境进行部署和进行集成测试的条件。 ? 用户集成测试环境具备（场地、硬件、软件等） ? 第三方接口系统具备联调条件

4.5.3. 工作任务

制定系统集成、上线方案 项目经理 必须 项目经理在与用户进行充分沟通后制定系统集成测试、部署上线的方案，主要包括如下内容： ? 系统集成和联调的时间计划和各个接口厂商人员安排（参与的人员包括本项目的施工人员、用户方、接口系统对应的厂商等） http://www.primeton.com/

第37页共44页

EOS应用开发过程参考手册

? 用户培训的时间计划 ? 系统联调环境和上线环境的要求 系统部署和集成测试 项目施工人员 必须 将开发环境部署到用户的集成环境中，并联合各个接口系统进行集成测试的过程。由于联调工作涉及到多个厂商的人员，如果事先没有各方认同一致的周密安排，往往会对进度的影响很大。 系统联调过程，要求每天编写施工日志，详细记录操作过程，系统只有通过了联调测试，才可能具备上线条件， 编写用户文档 文档人员 必须 编写交付给用户的使用文档，包括《用户使用手册》、《系统维护手册》，对于用户使用手册，可以在测试阶段由测试人员完成。系统维护手册则由工程人员结合现场的具体环境编写。以上面文档为基本素材，还需要编写针对用户培训的教程，同样包括系统使用和系统维护的内容。 进行用户培训 培训人员 可选 在完成系统的联调后，根据用户培训计划，组织系统的用户进行培训。 培训的方式可以采用集中现场培训或者远程视频培训，对于系统操作简单、用户文档编写详细的应用，则可以通过发放培训资料的方式，让用户自我进行学习。 系统上线 项目施工人员 必须 系统上线过程是系统割接的过程，对于规模较小相对独立的新系统，上线相对简单，而某些系统上线，可能需要进行大量数据的迁移和系统的初始化工作，而且与其他运行系统存在接口对接的处理，需要要非常详细的上线操作手册，避免酿成上线事故、带来无法挽回的损失（如生产数据丢失等），系统上线割接成功后，还需要结合系统运行环境进行系统配置的调整和优化。系统上线成功，标志系统进入试运行阶段。 系统上线过程中，同样要求编写每日的施工日志，详细记录上线过程的操作步骤和参数配置修改信息，并在上线完成后整理形成上线报告。 项目验收 项目经理、施工人员 必须 在系统进行用户培训和上线的过程中，项目经理应该积极推动项目的验收工作。一方面组织项目组按照合同要求整理项目验收时对用户的提交物，一方面向用户提出验收申请，协调用户进行项目的验收工作。 一般系统能够进入到试运行阶段，表明系统基本具备了验收的条件。在验收过程，在向用户提交各项文档、资源的同时，也需要和用户达成对验收中所提出问题的处理意见（例如，某些问题需要解决才能达到验收条件，某些问题可以在验收后解决）。 系统通过验收需要用户在书面的验收证明上签字认可。项目进入到系统维护阶段，标志项目实施过程的结束。 说明：此处所提到的验收一般指系统的初验。 项目总结 项目经理、开发经理 可选 项目结束后，在项目组所在公司或部门的范围内进行项目总结是一件非常有意义的事http://www.primeton.com/

第38页共44页

EOS应用开发过程参考手册

情。项目总结的内容可以包括： ? 对项目取得的成果以及项目团队中的优秀成员进行表彰和肯定 ? 项目实施过程和项目管理上的经验教训和改进意见 ? 本项目中形成的技术成果（构件）或者解决方案的整理 ? 项目演示环境和项目案例的文档整理 通过项目总结工作，使得项目的知识和经验能够上升到更高的层次，同时也是对项目参与人员一次知识经验的沉淀升华的过程。 4.5.4. 输出内容

? ? ? ?

《系统集成测试报告》 《用户使用手册》 《系统维护手册》 《项目验收报告》

4.5.5. 阶段控制点

本阶段项目管理的重点工作在于组织进行系统的联调和上线验收工作，沟通和协调的事情较多也比较复杂，这是发挥项目经理良好沟通技巧的重要时机。对于具体的控制点描述如下：

? 协调外围系统，进行集成测试

对于存在多个外部接口的系统，需要协调外围系统的厂商配合进行联调。项目组本身是没有力量推动的，项目经理应该推动负责此项目的用户人员去积极协调各个厂商形成联调方案。

? 把握系统需求实现情况，推进系统验收

验收是一项重要的工作，尽早进行验收有助于项目款项的回收。而系统如果进入到试运行阶段后，用户方未必有进行验收的主动性，需要项目经理积极推动。验收过程中，更加需要项目经理讲究技巧和发挥个人魅力，因为任何项目都不可能十分完美的满足客户的需求，或多或少被用户挑出刺来（如项目工期拖延、某些功能缺失、某些功能与用户的期望有差距等等），要清楚如果项目做到挑不出任何问题的时候再申请验收，估计就等不到验收的一天了。本文档只是提到了推进验收是非常重要的工作提请项目经理考虑，至于如何推进，那是一项艺术加技巧的工作了，不在本文档表述之中。

4.5.6. 退出条件

? 系统通过用户的验收（初验）并交付给维护人员。 ? 系统进入试运行阶段。

http://www.primeton.com/

第39页共44页

EOS应用开发过程参考手册

4.5.7. 参考模板

? 《用户使用手册》参考模板 ? 《系统维护手册》参考模板

5. 其他

待项目组已经适应了面向构件的软件开发，可进一步采纳更多体现普元公司多年经验的最佳实践，使项目管理和生产力水平更上一层楼。

5.1. 人员管理

项目经理是开发团队中特殊的角色，他需要掌握的技能和大多数人不同。项目经理的职责之一是“管人”。

面向构件项目的团队组织，建议是动态性的。这样做的重大好处之一是“有利于和外部团队协同”，当项目开发任何涉及外包子系统时非常易于管理；另外，很常见的情况是需求和总体设计由最终客户和中间件厂商共同完成，而后期工作由最终用户的开发人员进行，此时，“动态团队”的灵活性就十分明显。

初始细化构造移交开发组开发组定位组架构组开发组原型开发组开发组开发组

总的来说，资源的投入应该本着风险驱动的原则：在目标为明确之前，仅投入5％的工作量；在架构和主要技术风险明确之前，再投入20％工作量。待所有高风险因素明确之后，全面将工作铺开，投入项目组所有人力资源。

http://www.primeton.com/

第40页共44页

本文来源：https://www.bwwdw.com/article/7qhg.html