eos应用开发过程参考手册_v2

eos应用开发过程参考手册_v2内容摘要：

8 页共 36 页 . 其余部分的结构 本文档的其余部分，将依次阐述下列内容：  EOS 应用开发过程  EOS 应用开发的角色  开发过程阶段描述  其他最佳实践 EOS 应用开发过程参考手册 第 9 页共 36 页 2. EOS 应用开发过程 EOS 应用是典型的 J2EE 企业应用，所以 EOS 应用的开发过程将以 J2EE 企业应用开发过程为参照并结合 EOS 的特点进行说明。 一般而言，对于 J2EE 的企业级应用的开发，可以划分为如下内容：  需求： 明确软件开发的任务，形成所有相关 涉众（如客户、用户、项目组）共同认可的软件需求规格。 需求规格需明确功能需求、质量属性、约束条件等需求的所有方面。  设计：针对需求进行分析设计，形成项目组的设计说明书和功能清单。  开发：在设计说明的指导下完成应用的实现。  测试：针对实现的应用进行系统良好性的验证，可能包含的测试工作如：功能测试、系统测试、集成测试、性能测试等。  集成、部署：主要完成系统在用户环境中上线，并通过用户培训，将应用系统交付用户使用。 应用开发中， 针对以上工作，一般都划分为一个独立阶段，然而，各个阶段仅仅表明一个工作的重心和职 能以及阶段间的顺序，并不代表着各个阶段的工作是串行的。 实际上，各个阶段在不同的应用项目中，不同程度存在一定阶段重合（并行）或者迭代现象。 如下图： 需 求设 计开 发测 试集 成 部 署0 T 1 T 2T 3 T 4 T 5 T 6 T 7项目阶段项 目 开 发 周 期 对应用开发过程进行阶段划分的主要目标还是便于界定各个阶段的主要工作内容，而不在乎你是否把属于该阶段的工作放到上一阶段中，或者干脆将某两个阶段合并为一个阶段。 需要关注的是相关的工作是否串行和对其他工作是否存在依赖型。 对于 开发过程的 描述 ， 除了与应用开发和项目实施密切相关的 工作内容 以外，还将包括保障 项目实施的各种项目管理方法和手段。 另外，在对各个阶段的工作进行描述之前，先对 EOS 应用开发过程参考手册 第 10 页共 36 页 EOS 应用开发过程中涉及的各种角色进行简单的说明。 EOS 应用开发过程参考手册 第 11 页共 36 页 3. EOS 应用开发的角色 . 理解角色 项目是由人、过程和技术组成的，但是迄今为止，最重要的因素是人。 试图用过程或技术取代人的做法是愚蠢的，因为技术也好，过程也好，没有项目组人员的支持和参与，就不会发挥出相应的作用。 在 EOS 项目中，对于项目成员角色的定义与其他的 J2EE 项目的角色定义几乎是一致的，只是在某些角色的职责方面有一定的差异。 以下将分关键角色、支持角色和额外角色分别进行说明。 另外，需要强调的是，角色代表着项目组的一种职责，并不意味着不同角色都必须由不同的人分别承担，细分角色的目的是为了了解在应用项目实施过程中，存在哪些工作需要由什么样知识结构、经验、技能的人承担。 通常情况下，会根据项目的大小，人员的投入情况以及成员的个人能力和经验差异，某个人会承担一个或多个角色。 例如，某些小型项目的项目经理可能主要的职责是管理项目开发团队和控制项目的开发进度，而他同时可能是具有较强业务知识的业务专家，同时又具有较深的技术根底，兼任项目的开发经理的职责。 总之，角色就象帽子，具体人与角色可以是一 对多的关系。 EOS 应用开发过程参考手册 第 12 页共 36 页 . 关键角色 . 项目经理 项目经理是项目的行政领导，负责报告进度情况、管理预算、 筹措 人员，以及协调设备、场地、资源等。 作为项目的操作者和维持者，项目经理的工作是创造和维持 一个良好的环境，使项目组运行在最佳状态。 项目经理一般由有良好项目管理知识、具备实际项目管理经验，良好的协调沟通能力，较强的客户服务意识，同时具有超凡人格魅力的人员担任。 . 开发经理 开发经理又称为技术经理，他是应用开发过程的主要控制者。 他在其他角色的配合之下，负责对进入条件、退出条件、项目控制点的把关。 开发经理应当有良好的技术 功底，尤以通才为佳。 . 架构师 他应当为项目的技术方案负责。 当有风险较大的技术问题时，架构师应成为技术课题攻关的带头人。 在面向构件方法论中，架构设计师的主要职责如下：从活动方面讲，他一是需要了解现有构件资产，二是需要设计出满足需求（含功能需求和非功能需求）的面向构件的应用架构；具体而言，他应按照面向构件的思想，将解决方案空间合理地分割成不同的构件、确定构件的粒度、描述构件的接口、确定构件之间的协作关系、并充分考虑构件的并发和构件的分布；从工作产品方法讲，他必须提交架构文档或模型。 . 业务专家 业务专家是具备业务领域知识的人才，他负责辅助其他角色建立业务模型，并对最终业务模型评审把关。 在大多数情况下，担任业务专家的人员还应该具备一定的业务建模知识，懂得如何建模的人才知道如何简化工作。 他还应具有良好的沟通技巧。 . 主程序员 主程序员负责带领程序员（构件包所有者）进行特定子系统的开发，他是子系统的应用功能设计的负责人。 另外，他还辅助架构师进行功能分解、页面原型设计等工作。 主程序员应当是在特定子系统方面有丰富经验的高级工程师，应能够给他的下属以指导。 EOS 应用开发过程参考手册 第 13 页共 36 页 . 构件包所有者 构件包所有者 负责按照项目所采用的标准 来进行构件开发与测试，他是 构建构件包的程序员（我们不采用 XP 的代码集体所有），并有义务对自己的工作成果进行单元测试。 随着产品生命周期的延续，构件包所有者应当担负其维护的责任。 EOS 应用开发过程参考手册 第 14 页共 36 页 . 支持角色 . EOS 专家 EOS 专家是指精通 EOS 产品的技术专家，能够为项目组提供 如下服务：  提供基于 EOS 的应用开发过程和项目管理方面的指导  结合应用要求和 EOS 特点的 提供 应用设计 方面的咨询和 指导  帮助项目组建立结合 EOS 特点和应用要求的开发规范  为应用开发中的技术课题攻关提供解决方案 或指导  为开发人员提供产品使用的培训和指导  开发 中故障的快速定位 和处理 对于初次采用 EOS 进行项目开发的项目组， EOS 专家往往是由普元公司的服务工程师担任，对于 已经有 EOS 应用项目开发经验的项目组，由具有相关经验的人员担任。 . 配置管理人员 配置管理人员负责为产品开发团队提供全面的配置管理环境。 他应确保配置管理环境有利于进行评审、更改和缺陷跟踪等活动。 . 系统管理员 系统管理员负责系统级通知 的 发布 、 反馈意见 的收集、 系统性能 的及时改进 ， 还 对各类数据库进行操作、备份恢复、导入导出，以保证系统正常运行，同时对其它登录 角色 分配系统使用权限。 系统管理员具有功能：信息管 理、数据管理、权限管理。 . 数据库 DBA 数据库管理员 (DBA)负责设计、 建立 和维护 项目 的数据库，并保证数据库的准确性和安全性。 EOS 应用开发过程参考手册 第 15 页共 36 页 . 其他角色 . 美工 美工的职责包括： 进行网页美术设计；应用程序的用户界面 美术 设计。 对于产品型公司，还应负责 产品包装设计及其其他相关工作。 . 测试人员 在 EOS 应用的开发中，测试人员主要进行功能测试、集成测试、系统测试、验收测试、其他非功能性专项测试等，测试主要从需求规格和功能设计出发，以黑盒测试为主。 测试人员可以由独立于项目组的测试部门工程师担任，也可以由项目组的人员兼任，某些测试内 容可能有用户的人员参与。 . 文档人员 文档人员主要进行用户手册等用户文档的编写和编排。 对于一般中小型的应用项目，一般不需要配备专职的文档人员，可以由测试的人员兼任。 EOS 应用开发过程参考手册 第 16 页共 36 页 4. 开发过程阶段描述 为保证对各个阶段的描述有一个完整统一的描述方法，将采用 “ ETOCXM”的方法 进行，具体方式如下：  Entry（进入条件）：为每个阶段定义清晰良好的入口条件；  Task（工作任务）：列出所有要实现的任务列表，名称，是否需要实现，任务描述；  Output（输出内容） ： 阶段工作的输出产物以及评审内容 ；  Control Point（ 阶段 控制点） ：本阶段中为保证项目成功的关键控制点 ；  eXit（退出条件） ：阶段结束时所要达到的结果 ，注意，阶段退出条件并不意味下一阶段进入条件，因为下一阶段可能在上一阶段并未结束的情况下就已经启动了；  Template（参考模板）： 本阶段可供参考的文档模板或参考案例 . 需求阶段 . 概述 本阶段是应用项目的启动阶段 ， 它主要完成应用系统需求的采集整理工作，形成系统设 EOS 应用开发过程参考手册 第 17 页共 36 页 计和实现所需要的需求基线库。 对于签订客户合同的应用项目，需求调研 工作的地点一般在客户的现场，这种情况下 ，项目组往往只确定了项目经理和需求调研的人员 ，项目团队还不完整。 而对于开发应用产品性的项目，则 应用开发过程 的 地点比较固定。 对于这两种情况，项目团队的管理和工作方法均有一定的差异性，而在本参考中，只提供本阶段通用的工作说明，对于上面提到的差异性不做说明，需要项目组结合本参考内容的基础上充分考虑。 对于本阶段的工作，如图所示，详细的说明，参见“工作任务”章节。 需 求 阶 段项 目 管 理 工 作项 目 实 施 工 作制 定 项 目 实 施 和 管 理的 相 关 模 板评审不通过制 定 项 目 实 施 计 划进 行 需 求 调 研编 写 需 求 规 格迭代建 立 项 目 管 理 方 案进 行 需 求 评 审组 建 项 目 团 队资 料 研 究 和 需 求 初 步整 理 在上图所示的工作中，项目实施工作和项目的管理工作可以是并行的。 另外， 由以上的工作内容可以看出，实际上本阶段的工作，与是否采用 EOS 是无关 的。 需求阶段的主要目标是明确应用的所有功能需求和其他非功能性需求，然而这往往是一种理想的目标，实际上在进行需求调研时，配合 参与需求调研工作的用户对于系统的需求并不是十分清晰，也是在讨论和碰撞中不断清晰明确的， 由此导致的需求 不稳定性特点比较明显，表现为某些需求现阶段无法进一步细化，某些需求可能出现反复，某些需求现阶段无法确定是否需要实现等等。 这种状况导致无法在 人为确定的需求阶段中固化所有的需求内容，因此，对于项目组而言，在本阶段所掌握的需求内容基本充分，能够进行后续的设计工作，或者说，所不明确的需求，不足以 影响 系统的结构和目前工作的进展，那么，需求阶段的目标就算是基本达到了。 另外，在需求阶段，有时用户会要求提供一个应用的原型，希望在需求讨论的基础上，看到系统实现的基本效果。 关于原型的实现，我认为属于设计的工作，将在设计。