BCG-华为软件质量业界对标技术咨询合作项目-20160328.pptx

1、软件质量业界对标技术咨询合作项目软件质量业界对标技术咨询合作项目（对标分析）（对标分析）项目终期汇报 工作过程稿工作过程稿 仅供讨论仅供讨论 Huawei Confidential Page 2 HW SW SQM strategy-final readout-28Mar16-v5.pptx 工作过程稿工作过程稿 仅供讨论仅供讨论 今天会议目标今天会议目标 介绍新增的软件架构质量管理对标内容介绍新增的软件架构质量管理对标内容 介绍新增的关键举措对标内容介绍新增的关键举措对标内容 回复上次研讨的主要问题回复上次研讨的主要问题 Huawei Confidential Page 3 HW SW SQ

2、M strategy-final readout-28Mar16-v5.pptx 工作过程稿工作过程稿 仅供讨论仅供讨论 Agenda 新增内容：软件架构质量管理对标新增内容：软件架构质量管理对标 主要发现节选：软件质量管理举措主要发现节选：软件质量管理举措 上一阶段主要问题回复上一阶段主要问题回复 附录附录 3大类型软件质量要求及管控方式对标大类型软件质量要求及管控方式对标 5大质量管理举措大质量管理举措对标对标 Huawei Confidential Page 4 HW SW SQM strategy-final readout-28Mar16-v5.pptx 工作过程稿工作过程稿 仅供讨

3、论仅供讨论 业界领先公司对于架构采取两种不同的管控机制：模块化修改和快速迭代业界领先公司对于架构采取两种不同的管控机制：模块化修改和快速迭代 机制描述机制描述 主要考量主要考量 适用场景适用场景 使用公司使用公司 软件架构的质量需要实战检验，根据需求和使用情况不断进行修改软件架构的质量需要实战检验，根据需求和使用情况不断进行修改 资料来源：文献检索；专家访谈；BCG分析 快速迭代快速迭代 降低降低架构架构设计时间设计时间和和成本成本，快，快速推出产品试水市场速推出产品试水市场 前期简单场景和低业务量，无需探讨复杂架构问题 根据根据用户实际使用情况用户实际使用情况进行架进行架构的检验，有的放矢构

4、的检验，有的放矢 消费者产品消费者产品，需，需快速验证用户习快速验证用户习惯和喜好惯和喜好 架构较为简单架构较为简单的的产品，重写架构产品，重写架构成本较低成本较低 快速设计 开发上线 重新设计 依据小业务量和简单场景快速设计 通过tech lead和架构架构师师的简单设简单设计计review 快速开发快速开发上线上线，吸引用户 在软件使在软件使用过程中，用过程中，检验架构检验架构是否存在是否存在问题问题 随着用户规模增多，业务场景复杂，重新设计架重新设计架构构 1 1 企业级产品企业级产品，用，用户习惯和喜好较户习惯和喜好较为确定为确定 架构较为复杂架构较为复杂的的产品，重写架构产品，重写架

5、构成本较高成本较高 模块化模块化 修改修改 降低代码重写降低代码重写的的风险风险和和频率频率，避免大规模更新的负担避免大规模更新的负担 发现问题后，分步更新架构，发现问题后，分步更新架构，逐步验证，逐步验证，降低试错风险降低试错风险 系统性设计 依据未来可预计的业务量和复杂场景设计 通过tech lead、工程、工程师团队师团队和架构师架构师的详细详细设计设计review 重视模块化设计，模块化设计，保证模块间可以独立修改可以独立修改 逐渐修改 根据用户使用情况，按模块，按模块修改修改 在多模块修改成熟后成熟后，推出新架构，取代取代老架构老架构 2 2 Huawei Confidential

6、Page 5 HW SW SQM strategy-final readout-28Mar16-v5.pptx 工作过程稿工作过程稿 仅供讨论仅供讨论 微软控制软件架构主要依靠前期架构设计和微软控制软件架构主要依靠前期架构设计和审阅审阅，由产品经理、开发经理、，由产品经理、开发经理、架构设计人员和测试人员共同参与，主要衡量用户需求指标和可开发性架构设计人员和测试人员共同参与，主要衡量用户需求指标和可开发性 资料来源：文献检索；专家访谈；BCG分析 用户需求分析用户需求分析 架构设计架构设计 架构设计审阅架构设计审阅 开发开发/测试测试 +关注维度 用户关注的质量维度用户关注的质量维度 功能性、

7、兼容性、一致性、容错性、可拓展性、Crash consistence、性能、资源消耗（仅消费者产品）1 1.1 判断判断架构设计是否满足满足未来开发和维护开发和维护的要求要求 参与人员和主要工作 Technical Fellow 测试人员测试人员 产品产品 经理经理 产品产品 经理经理 开发开发 经理经理 开发开发 经理经理 通过通过审阅审阅 未通过未通过审阅审阅 依据测试大纲来计算用户关注维度计算用户关注维度的的理理论值论值，或者检查检查相关checklist，判断判断是否满足满足客户需求需求 进入开发进入开发/测试阶段测试阶段 依照需求，设计设计高阶软件架构高阶软件架构 依照需求和规范，设

8、计设计相应产品测试大纲测试大纲 分析用户需分析用户需求，完成需求，完成需求文档求文档 根据需求，根据需求，搜寻相应行搜寻相应行业开发标准业开发标准和规范和规范 2 资深开发资深开发工程师工程师 依照高阶设计，设计各个子模块设计各个子模块 划分模块划分模块 提出反馈提出反馈 可开发性可开发性/可维护性可维护性 模块化设计，逻辑清晰 模块间松耦合，彼此开发和维护不互相影响 增加新功能和模块较为方便灵活 1.2 设计、审阅阶段都需要考虑两个维度 Huawei Confidential Page 6 HW SW SQM strategy-final readout-28Mar16-v5.pptx 工作

9、过程稿工作过程稿 仅供讨论仅供讨论 以以windows OS为例，对于用户关注维度，微软在设计架构时要根据用户需为例，对于用户关注维度，微软在设计架构时要根据用户需求设计测试，并计算理论值，来衡量架构是否满足用户需求求设计测试，并计算理论值，来衡量架构是否满足用户需求 资料来源：文献检索；专家访谈；BCG分析 1.1 质量维度用户关注维度 描述描述 衡量指标类型衡量指标类型 衡量指标来源衡量指标来源 架构是否支撑用户需要用户需要的功能功能 用户需求 竞品情况 兼容性兼容性 功能性功能性 一致性一致性 容错性容错性 可拓展性可拓展性 Crash consistence 性能性能 安全性安全性 重

10、要性 强 弱 衡量方法衡量方法 设计用户场景，按优先级优先级分成三级，前两级的功能必须通过 checklist 理论值 理论值 架构是否兼容各类硬件硬件和常用上上层软件层软件 扫描常用硬件和软件，将所需兼容性要求做理论验证理论验证 架构是否满足数据安全、网络安全等安全性要求安全性要求 扫描主要安全性场景安全性场景，进行理论验证，并借鉴安全性规范标准规范标准 即compliance，架构是否满足规规范标准范标准，如ISO和内部规范等 扫描主要行业标准行业标准和内部规范内部规范，进行理论验证 在系统从外界输入输入有错误错误时，系统是否能够正常运行正常运行 设计外界错误输入，计算系统能够正常工作的错

11、误临界值错误临界值 在系统崩溃并恢复崩溃并恢复后，数据数据能否仍然能够保证正确正确 在多种场景下，计算数据保持正正确确的比例比例 主要对云服务而言，从少量用户扩展到大量用户性能下降大量用户性能下降较小 在用户量增长场景下，计算性能性能的理论值理论值，与低用户量进行比较 各功能的延时延时、是否是否crash等 无竞品，因此要求较低 根据应用场景和功能，计算性能理论值 用户需求 竞品情况 行业规范 checklist checklist checklist 行业规范 内部规范 竞品情况 理论值 理论值 用户需求 竞品情况 用户需求 竞品情况 用户需求 1 1 2 2 3 3 4 4 5 5 6 6

12、 7 7 8 8 Huawei Confidential Page 7 HW SW SQM strategy-final readout-28Mar16-v5.pptx 工作过程稿工作过程稿 仅供讨论仅供讨论 对于可开发性对于可开发性/可维护性，主要考虑模块化设计逻辑、模块间耦合和增加新功可维护性，主要考虑模块化设计逻辑、模块间耦合和增加新功能的灵活度，由开发经理评估，并交予架构设计人员修改能的灵活度，由开发经理评估，并交予架构设计人员修改 资料来源：文献检索；专家访谈；BCG分析 1.2 质量维度可开发性/可维护性 开发经理开发经理 资深开发资深开发工程师工程师 模块化设计逻辑清晰模块化设计

13、逻辑清晰 模块间松耦合模块间松耦合 增加新功能的灵活度高增加新功能的灵活度高 模块间的逻辑清晰易懂，得到模块间的逻辑清晰易懂，得到开发经理认可开发经理认可 用简单语言清晰描述逻辑，可降低出现bug的风险 由开发经理决定逻辑是否清晰易懂 每个模块仅实现一个关键功能每个模块仅实现一个关键功能 减少不同功能修改时影响其他功能 由开发经理确认模块功能性是否合理 各个模块间耦合度较低，互相各个模块间耦合度较低，互相不影响，可以独立修改不影响，可以独立修改 耦合度由开发经理和设计人员根据设计文档主观判断 在资源受限的情况下，可以选择将某些模块耦合在一起，提高开发效率（减少接口定义、开发工作）模块内部逻辑清

14、晰，增加功能模块内部逻辑清晰，增加功能较为容易较为容易 模块尽可能将功能分解到颗粒模块尽可能将功能分解到颗粒度小的状态度小的状态 增加新功能可以由增加新模块完成，不影响其他模块的功能 模块接口定义清晰，可方便与模块接口定义清晰，可方便与新增加模块交互新增加模块交互 Technical Fellow 评估并给评估并给与反馈与反馈 设计并根据设计并根据意见修改意见修改 将子模块将子模块分配分配 按照子模块按照子模块设计，并反设计，并反馈问题馈问题 可开发性可开发性/可维护性多由开发经理和设计人员主观判断，并根据团队的资源、开可维护性多由开发经理和设计人员主观判断，并根据团队的资源、开发的进度和团队

15、的能力综合考虑，进行调整发的进度和团队的能力综合考虑，进行调整 可开发性可开发性/可维护性的评估维度可维护性的评估维度 Huawei Confidential Page 8 HW SW SQM strategy-final readout-28Mar16-v5.pptx 工作过程稿工作过程稿 仅供讨论仅供讨论 架构设计人员往往由架构设计人员往往由technical fellow和资深开发工程师担任，有时开发经理和资深开发工程师担任，有时开发经理也会参与架构设计工作也会参与架构设计工作 资料来源：文献检索；专家访谈；BCG分析 2 架构设计和审阅人才 客户需求维度客户需求维度 可开发可开发/维护

16、性维护性 开发经理开发经理 Technical Fellow 资深开发资深开发工程师工程师 架架构构设设计计人人员员 主要架构设计工作职责主要架构设计工作职责 主要能力要求主要能力要求 基本不承担设计工作不承担设计工作，更多承担开发过程中的管理工作 负责审阅架构设计审阅架构设计 较强的沟通能力和领导力领导力 对架构架构较深的理解 深入理解客户需求客户需求 开发产品满足客户需求 既包括架构架构方面也包括开发开发方面 主要负责产品从业务模块到高阶高阶开发模块的设计设计 一般不涉及开发不涉及开发工作 一般与开发经理平级，或向开发经理汇报 资深开发资历资深开发资历，技术能力较强 有行业行业和客户知识客户知识 全面全面考虑测试指标，做出取舍判断取舍判断能力 架构审阅阶段审阅阶段，测试大纲计算的理论值理论值和达成的checklist可以满足客户需求 负责根据technical fellow的模块继续进行底层设计底层设计 负责与其他开发人员合作，开发和实现开发和实现设计的模块 向开发经理汇报 对架构有较深理解 能够承担设计设计和开开发发的工作 测试阶段，开发产品达测试要求测试要求 既包括架构架构方面