2020年中国制冷空调行业竞争格局及投资风险分析报告.docx

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