1、约指导委员会 (毕马威和客户)交付成果项目详细说明范围 /目的该交付成果的目的是说明EAI解决方案范围变化管理过程。大纲 范围变化控制程序将包括流程图、范围影响分析程序和范围变化优先顺序排序程序概要 范围变化控制程序将以下列形式展开：1. 简介2. 关键术语的定义3. 流程4. 影响评估5. 优先排序6. 扩展q 时间/费用报告程序交付成果项目描述交付成果名称:时间/费用报告程序所有者：PMO经理接受对象：项目小组全体成员输入：工作说明书（SOW）时间安排：计划&分析。SOW结束之后交付成果认可认可人：EAI项目指导委员会（毕马威和客户）交付成果项目细节描述范围/目的：本交付成果的目的是介绍本
2、项目中我们收集实际花费时间和向客户收取费用的流程，以便项目小组可以按预算来跟踪实际数额。大纲： 时间/费用报告程序将介绍如何填写模板、何时及向谁提交模板、数据的校对，以及数据报告结构等一系列流程。概要：时间/费用报告程序将按如下方式进行概要介绍1. 简介2. 流程3. 关键领域4. 后勤5. 报告q 沟通计划交付成果项目描述交付成果名称:沟通计划所有者：PMO经理接受对象：项目小组全体成员输入：工作说明书（SOW）时间安排：计划&分析。SOW结束之后交付成果认可认可人：EAI项目指导委员会（毕马威和客户）交付成果项目细节描述范围/目的：本交付成果的目的是描述团队沟通的方案，以便有效地管理客户期
3、望和团队期望大纲： 本沟通计划描述了客户期望、团队成员期望和管理层期望。同时，还描述了沟通事项的方法以及团队的状况概要：本沟通计划将按如下方式进行概要介绍：1. 简介2. 客户期望3. 管理层期望4. 团队成员期望5. 状态沟通协议6. 问题沟通协议7. 沟通会议q 降低风险计划交付成果项目描述交付成果名称:降低风险计划所有者：PMO经理接受对象：客户高层管理者、项目出资人、客户日常管理者和职员、及此方面专家输入：工作一览表（SOW)时间安排：计划&分析。SOW结束之后交付成果认可认可人：EAI项目指导委员会（毕马威和客户）交付成果项目细节描述范围/目的：本交付成果的目的是描述可预见的风险和降
4、低这些风险的方法大纲： 本降低风险计划将包括风险描述、降低方法、风险记录日期、风险降低日期概要：本降低风险计划将按如下方式进行概要介绍：1. 简介2. 风险描述3. 降低方法q 项目概要培训交付成果项目描述交付成果名称:项目概要培训所有者：PMO经理接受对象：全体成员输入：工作说明书（SOW)时间安排：计划&分析。SOW结束之后交付成果认可认可人：EAI项目指导委员会（毕马威和客户）交付成果项目细节描述范围/目的：本项目概要培训文档的目的是向新团队成员介绍项目情况，以使其能迅速熟悉项目大纲： 本项目概要培训文档将包括项目背景、目标、范围、大体日程、解决方案结构、组织结构图和管理细节概要：本项目
5、概要培训文档将按如下方式进行概要介绍：1. 简介2. 背景3. 项目目标4. 项目范围5. 大体日程6. 解决方案结构7. 实施方法论8. 项目组织结构9. 管理q 文档管理程序 交付成果项目描述交付成果名称:文档管理程序所有者：PMO经理接受对象：项目小组全体成员输入：工作说明书（SOW)时间安排：计划&分析。SOW结束之后交付成果认可认可人：EAI项目指导委员会（毕马威和客户）交付成果项目细节描述范围/目的：本交付成果的目的是就项目文档的维护程序进行沟通大纲：本文档将描述目录结构和访问文档的方式概要：本文档管理程序将按如下方式进行概要介绍：1. 简介2. 目录结构3. 访问4. 更新文档及
6、通知2.2 EAI中间件及其它商用组件选型2.2.1 工具选择流程一个完善确立的产品选择流程能帮助我们选择最适合的工具，来满足的企业战略业务驱动的需要，并消除当前状态架构和未来状态架构的技术差距。一个成功的工具选择流程包括：q 考虑企业的业务挑战来进行决策，而不是强制满足样板文件的需求。q 在评价时鼓励创新，但同时要注意那些可能很快不兼容或被淘汰的所谓“流行技术”。q 在评价时减少利益相关者/客户的参与。q 在允许创新的同时，综合采用标准的流程和技术。q 遵循一个一致的、建立在控制和流程上的结构化方法，以提供在各个层次上的检查点。q 帮助项目组明确对每一个选择动作进行监控的重要性，保证花费的时
7、间和精力有所回报。2.2.2 评估方法评估的方法是使用尽量多的相关信息来完成产品评估。这个过程的目标是利用毕马威管理咨询公司的实施经验、供应商提供的文档和行业研究，为中国电信提供足够的信息，以便根据中国电信业务需求做出决策。组成评估过程的步骤是：图2-5：EAI产品选择评估步骤1) 基于初步业务需求，确定必需的功能；2) 检查符合初始功能需求的产品；3) 进行初步筛选，排除不符合基本选择需求的供应商；4) 建立当前需求的详细评价准则，和中国电信进行讨论；5) 提交供应商/产品调查表、评估准则，发给供应商，获取所有仍在考虑的产品；6) 在KPMG咨询实践经验和供应商产品研究基础上，给出初步评价；
8、7) 回顾分析供应商/产品反馈；8) 在候选产品中完成一个供应商对比分析；9) 合并中国电信的回顾和反馈；10) 给出结论和推荐的产品。2.2.3 选型准则下面的选型准则将用来对EAI候选供应商产品进行比较。这些评估准则，根据行业分析、毕马威管理咨询公司项目经验和知识，被分成以下几类，具体选型准则详见D5。战略符合哪个供应商的战略对你的业务战略提供了最佳支持？风险供应商的风险是什么？（资历、服务、实施的支持） 成本完整的生命周期解决方案的成本是什么？（硬件、软件、维护、实施）功能哪些需求影响软件选择，并且是业务成功的关键？技术哪些技术可以被使用，怎样最佳地使用？业务关系哪个供应商愿意成为合作伙
9、伴，并提供投资？2.3 概念验证设计及实施2.3.1 概念性验证（PoC）简介为减轻一步到位在线实施的的风险，开发一个概念证明性的系统整合（EAI）框架是非常重要的。概念性验证项目(PoC) 不影响生产署但能构建EAI的基础模块，以此作为目标状态下IT架构的基石之一。q 验证设计时的假设qq 实现直接短期效益qq 作为向生产环境过渡的基础qq 新技术和实施方法论的练习qq 检验中国电信的技术能力qq 减少对生产环境的影响qqqq图2-6：概念性验证2.3.2 应用系统初步设计图2-7：应用系统初步设计2.3.2.1 实施内容以下交付成果是该阶段的主要内容: q 使用案例仓库实施项目介绍实施名称
10、:使用案例仓库所有者:应用体系经理接受对象:客户行政管理人员和项目负责人, 客户管理人员, 应用系统小组成员.输入:业务需求文件(BRD)时帧:初步设计，在BRD的结束信号之后。项目正式批准许可人:CTF 筹划指导委员会 （毕马威管理咨询与客户）实施项目具体描述范围/目的:案例仓库汇集了所有确定了的案例。它将对每个案例的详细设计要求提供跟踪和生产的依据。提要: 案例仓库是一个电子数据表。它列出了案例的名称、跟踪代码以及简要的介绍。提纲: 案例仓库有以下几方面构成： 1. 案例记录代码2. 案例名称3. 案例介绍q 应用系统地位级图实施项目描述实施名称:应用系统地位级图所有者:应用体系经理对象:
11、客户行政管理人员和项目负责人, 客户管理人员, 应用系统小组成员.信息:业务需求文件 (BRD)时帧:初步设计。在BRD的结束信号之后。实施正式批准许可人:CTF 筹划指导委员会 （毕马威管理咨询与客户）实施项目具体描述范围/目的：应用地位级图是一经详细设计的实施内容。它以绘图形式提供了从用户界面到应用系统内部的用户界面的概览。只有面向应用系统的用户需要该项实施设计。提要: 应用系统地位级图由描绘所用图形用户界面和应用系统的矢量图表和不同用户界面的链结构成。这一阶段同时提出了每一用户界面的命名协定。提纲: 应用系统地位级图由以下几方面构成：1. 用户界面命名协定2. 屏幕到屏幕流程演示2.3.
12、2.2 参与人员以下的参与人员将在该阶段工作中发挥积极作用：q 应用体系经理 -业务体系经理最终对该项交付工作负责。此人将指导应用系统方面的领导/设计者以确保他们符合标准，完成预定的交付工作，参与跨团队设计圆桌会议。此人还将促进该交付作业的回顾和总结。q 应用系统域领导/设计者 负责向业务体系小组提供第二阶段流程图的应用关键点的输入信息。他们负责制作案例仓库的使用以及应用系统地位级图。2.3.2.3 附件以下附件将会影响本阶段工作完成的时效性：q 业务需求文档 该阶段的实施完全依赖于内部第一阶段流程图和业务需求文档所指明的各项要求。 内部第一阶段流程图和业务需求文档所明确的要求的变化将影响该项
13、工作完工的时效性。q COTS应用文档 很多时候应用系统 COTS软件在初步设计中不被安装。为了做出合理的设计决定，应用系统小组至少必须有COTS 应用系统文档以便完成第二阶段应用系统功能性流程图的绘制过程。2.3.3 系统架构初步设计2.3.3.1 实施内容以下为初步设计阶段的主要实施内容: q 应用软件架构示意图实施项目实施名称：应用软件架构示意图拥有者：技术架构经理对象：所以项目成员信息:业务需求文件 (BRD) 时间顺序:初步设计，在确认BRD之后实施正式批准批准者:CTF主管委员会(毕马威咨询与客户)实施条目细节范围/ 目的:应用软件架构示意图是一个初步设计的可交付成果， 采用图表来
14、描绘所有为业务决策提供支持应用软件包。对于每个应用软件，该示意图列出架构的构成组件并对之进行详细描述。本交付成果可对适用范围的所有应用软件和适配器组件进行识别。纲要: 应用软件架构示意图包括该架构的核心组件，应用软件包的架构组件，数据架构组件以及所有相关的适配器。要点: 列出应用软件架构示意图需要包括以下内容： 1. 核心架构组件2. 应用软件包的架构组件3. 数据架构组件4. 适配器q 技术架构示意图可交付成果条目实施名称:技术架构示意图拥有者:技术架构经理对象:所有项目成员信息:应用软件架构示意图时间顺序:初步设计，在确认BRD之后实施的正式批准批准方:CTF主管委员会 (毕马威咨询与客户
15、)实施条目 具体描述范围/目的：技术架构示意图 是初步设计的一项可交付成果，采用图表来描绘应用软件架构的物理构成。它详细说明了应用软件包的硬件配置，它为软件的定义、发展、测试、生产提供了基础环境。纲要: 技术架构示意图提供了硬件, 存储器，和操作系统等应用软件包所必须的支持工具的详细信息。它明确列出了应用软件包的版本信息,其中包括应用软件的所有组件。这张示意图还会详细展示相关的数据库示例，这是每个应用软件与核心架构都需要的支持。要点: 技术架构示意图应包括以下内容：1. 硬件/操作系统/存储器2. 软件组件与版本3. 数据库与数据库示例q 事件示意图实施项目实施名称:事件示意图拥有者:技术架构
16、经理对象:所有项目成员信息:应用软件架构示意图、二级流程图、工作流过程示意图时间顺序:初步设计，在确认BRD之后实施正式批准批准方:CTF主管委员会（毕马威咨询与客户）实施项目具体描述范围/目的：事件示意图是设计的一项可交付成果，它对所有已在事件总线上发布与和订阅的信息都作了详细描述。通过适配器，该示意图对事件总线之间的交互作用作了一个全面的观察。q 持续的架构途径实施项目实施名称:持续的架构途径拥有者:技术架构经理对象：应用软件架构, 技术架构信息：业务需求文件(BRD)时间顺序：初步设计，在确认BRD之后实施正式批准批准方：CTF主管委员会（毕马威咨询与客户）实施项目细节描述范围/目的：持
17、续架构途径的文件能提供处理数据需求的策略，该数据是通过顾客的详细参与得到的。纲要: 持续架构途径文件提供数据需求，必须的（COTS 与CTF）数据库，以及处理产品信息、顾客信息、销售定单信息的方法。另外，它还包含了处理历史遗留数据。要点: 持续架构途径应包含以下内容： 1. 目的2. 对数据的需求3. 数据库4. 产品信息5. 顾客信息6. 销售定单信息7. 历史遗留信息8. 事务处理模型9. 安全性10. 备份与恢复q 出错处理策略实施项目实施名称:出错处理策略拥有者：技术架构经理对象：所有项目成员信息：应用软件架构表, 二级流程图, 工作流流程图, 业务需求文件 (BRD)时间顺序：初步设
18、计，在确认BRD之后实施批准批准方：CTF主管委员会（毕马威咨询与客户）实施项目具体描述范围/目的：出错处理策略文件是处理错误的方法（包括处理日志错误、合并的错误日志）以及在用CTF架构修复缺陷。在设计和实施过程中，该方法是保障设计稳定性、标准化与实施稳定性的必须的途径。纲要: 出错处理策略是一种初步设计文件。它提供了一种前向方法，它包括了在架构中能遇到的不同类型的缺陷。这表示，它将合并这些缺陷，并从缺陷中恢复。这种策略将证明如何使用一个联合概念（Hawk,工作流，经鉴定的消息）来完成处理缺陷的工作。要点: 出错处理策略应包含以下内容：1. 目的2. 出错分类 （非致命、致命）3. 错误编码标
19、准4. 错误日志标准 (调试, 成果; 数据库, 文件)5. 错误日志合并 (来自于多个系统)6. 错误告戒/通知（警告 ）7. 缺陷修复(手动/自动)2.3.3.2 参与人员以下的参与人员将在这一阶段活动中发挥重要作用：q 技术架构经理- 技术架构经理是本阶段交付成果的最终责任人。他将引导EAI设计师和数据架构设计师，确保他们按时得到标准的、完备的交付成果，并准时出席交叉设计小组的圆桌会议。他还将为评价这次活动的交付成果提供便利。q 企业应用集成(EAI)设计师 EAI设计师负责开发应用软件架构示意图, 技术架构图, 以及事件示意图等可交付成果。他将会与其他项目组紧密合作，把EAI专家带到设
20、计会议上来。q 数据架构设计师 数据架构设计师将与应用软件架构小组紧密合作，以便理解即将在CTF解决方案中实施的COTS应用软件。他还将出席设计会议，以便了解在COTS 应用软件中的数据使用方式。 2.3.3.3 附件以下的从属因素将对这次活动的按时完成产生影响：q 业务需求文件 这一阶段的可交付成果在很大程度上取决于一级业务流程图的范畴以及业务需求文件中识别的需求。无论业务流程图范畴内部还是BRD中的需求的变化都可能影响到这次活动中所有可交付成果的按时完成。q 已存在的系统文件 如果CTF架构需要和已经存在的系统和历史数据进行结合的话, 那些系统/数据库的文件将对初步设计产生很大的影响。为了
21、有效地评估这一影响，完成技术架构的初步设计可交付成果，必须在设计会议召开之前，获取已经存在的系统文件。2.4 测试2.4.1 测试步骤定义测试将分为单元测试、集成测试和系统测试三步，以下将分别说明。q 单元测试单元测试是针对程序的函数、过程或完成某一定功能的程序块。可采用的测试方法有等价类划分法、因果图法、边值分析法、逻辑覆盖法、路径分析法及程序插装法等。用于单元级测试进行的测试分析（提出相应的测试要求）和测试用例（选择适当的输入，达到测试要求），规模和难度等均远小于后面将进行的对整个系统的测试分析和测试用例，而且强调对语句应该有100%的执行代码覆盖率。q 集成测试集成测试能够检测出相对独立
22、的单元测试无法检测出的那些模块间相互作用时才会产生的错误。基于单元测试对成员函数行为正确性的保证，集成测试只关注于系统的结构和内部的相互作用。集成测试可以分成两步进行：先进行静态测试，再进行动态测试。- 静态测试静态测试主要针对程序的结构进行，检测程序结构是否符合设计要求。当前流行的一些测试软件都能提供一种称为可逆性工程的功能，即通过原程序得到函数功能调用关系图，然后将可逆性工程得到的结果与设计的结果相比较，检测程序结构和实现上是否有缺陷，即通过这种方法检测编程是否达到了设计要求。- 动态测试动态测试设计测试用例时，通常需要上述的功能调用结构图或者实体关系图为参考，确定不需要被重复测试的部分，从而优化测试用例，减少测试工作量，使得进行的测试能够达到一定的覆盖标准。测试所要达到的覆盖标准可以是：达到所有的服务要求或服务提供的一定覆盖率；依据模块间传递的消息，达到对所有执行线程的一定覆盖率；达到所有状态的一定覆盖率等。同时也可以考虑使用现有
