26、软件架构决策与质量平衡：方法与实践

软件架构决策与质量平衡：方法与实践

在软件项目的开发过程中，架构投资决策和产品的时间 - 市场与质量平衡是两个关键的问题。本文将深入探讨这两个方面，介绍相关的方法和实践经验。

1. 战略聚焦的架构决策方法（StArch）

1.1 决策步骤

在架构投资决策过程中，有一种名为 StArch 的方法，它整合了战略地图、平衡计分卡、场景分析和商业案例分析等工具和方法，指导架构师和管理者进行决策。其决策步骤如下：
1. 制定战略地图和计分卡 ：明确战略目标和衡量指标。
2. 提出场景 ：构思不同的架构场景。
3. 估算计分卡 ：对每个场景的计分卡进行估算。
4. 决策 ：根据评估标准和计分卡结果做出决策。

1.2 实际案例分析

以一个实际项目为例，在进行 ISR 投资决策时，主要评估标准为净现值（NPV）大于 0 以及优化对现有客户的销售。从数据来看，Sneezy 和 Dopey 场景的 NPV 均大于 0，且 ISR 不会影响未来软件升级销售，只会促进传感器销售。然而，尽管有积极的商业案例和优化的销售情况，团队最终建议不投资 ISR，原因是组织中有另一个更有利的项目可以部分解决 ISR 的问题。这表明，在实际架构投资中，NPV 大于 0 只是必要条件，而非充分条件，需要考虑整个潜在投资组合。

1.3 StArch 评估

为了评估 StArch 的有效性，邀请了参与项目的从业者进行评价，主要聚焦于两个方面：
1. StArch 特性评估 ：通过问卷让从业者评价对 StArch 的满意度，包括整体满意度、信息完整性以及每个步骤的满意度。结果显示，从业者总体对 StArch 满意，但不同角色的满意度有所差异。系统架构师和成像产品经理更满意，而传感器经理评价为中立，原因是该过程忽略了降低成本的目标，这直接关系到传感器经理的利益。信息完整性的评价也因从业者的角色和获取信息的途径而异，架构师从 StArch 提供的信息完整性中获得的满意度最高。战略地图和平衡计分卡步骤得分最高，因为它提供了结构化方法，避免过早做出假设，用客观的计分卡和标准取代了个人偏好。提出场景步骤也得到了满意的反馈，这是因为组织中已有使用场景进行路线图和架构评估的实践。估算计分卡步骤的评价存在争议，架构师对计分卡的量化不满意，而成像产品经理则认为这是一个很好的估算方法。决策步骤得到了所有从业者的满意评价，他们认可 StArch 的决策规则和优化销售的评估标准。
|角色|非常满意|满意|中立|不满意|非常不满意|
| ---- | ---- | ---- | ---- | ---- | ---- |
|总体 - 架构师|X| | | | |
|总体 - 成像经理|X| | | | |
|总体 - 传感器经理| | |x| | |
|信息完整性 - 架构师| |x| | | |
|信息完整性 - 成像经理| |x| | | |
|信息完整性 - 传感器经理| |x| | | |
|步骤 1 - 架构师|x| | | | |
|步骤 1 - 成像经理|x| | | | |
|步骤 1 - 传感器经理|x| | | | |
|步骤 2 - 架构师|x| | | | |
|步骤 2 - 成像经理|x| | | | |
|步骤 2 - 传感器经理|x| | | | |
|步骤 3 - 架构师|x| | | | |
|步骤 3 - 成像经理|x| | | | |
|步骤 3 - 传感器经理|x| | | | |
|步骤 4 - 架构师|x| | | | |
|步骤 4 - 成像经理|x| | | | |
|步骤 4 - 传感器经理|x| | | | |

2. 决策改进评估 ：通过开放性问题询问从业者对 StArch 改进架构决策的看法。讨论表明，StArch 有效改善了组织现有的架构决策，因为它解决了一直悬而未决的 ISR 决策问题。其主要优势在于提供了结构化方法，能够应对架构变更的多重影响和不明确的价值。从业者表示会在新项目中再次应用战略地图和计分卡，并推荐给同事。此外，从业者认为使用 StArch 在 ISR 决策过程中花费的时间比未采用系统方法时少，且该方法可在一周内应用于任何架构项目，前提是从业者在会议前收集好所需信息。

1.4 结论与建议

综上所述，StArch 方法在架构投资决策中具有一定的优势，但也存在一些问题。不同从业者对估算计分卡和信息完整性的看法不同，这与他们在组织中的角色有关。为了提高满意度，建议提前更好地管理从业者的期望，并使用其他领域的技术，如心理测量学或谈判技巧，以更好地理解架构师和管理者的思维方式。同时，在实际架构投资中，应将 StArch 应用于整个项目组合，以考虑资源的稀缺性和项目的重叠范围。

2. 嵌入式系统中时间 - 市场与质量的平衡

2.1 软件挑战

在医疗设备行业，软件面临着诸多挑战，主要包括以下几个方面：
1. 法规要求 ：医疗设备市场是受监管的市场，例如美国的食品药品监督管理局（FDA）制定并执行相关规则。制造商必须遵守文档管理、风险控制等要求，否则可能面临严重后果，如产品召回。
2. 软件规模和召回问题 ：随着软件和产品变体数量的增加，质量面临风险，召回成本和后果也随之增加。例如，丰田汽车的召回事件和飞利浦 HeartStart FR2C 设备的召回事件。不过，飞利浦的主动召回在一定程度上有助于维护公司声誉。
3. 市场增长 ：医疗保健市场的增长带来了机遇和挑战，公司需要应对不断增加的市场需求和竞争，同时协调全球范围内的开发活动。

2.2 应对挑战的措施

为了应对这些挑战，医疗设备制造商采取了一系列措施。现在的医疗设备需要遵循严格的要求，公司需要建立风险管理系统（如 ISO 14791）和设计制造管理系统（如 ISO 13485）。虽然目前没有针对医疗设备的严格质量标准，但公司会关注相关标准以控制质量和可靠性。历史数据在这些分析中起着重要作用，可以帮助量化安全关键软件密集型系统的故障率。

2.3 基本数据

数据来源于飞利浦医疗保健的缺陷管理系统 IBM Rational ClearQuest，该系统用于记录开发过程中的缺陷和医院使用系统时报告的问题。典型的缺陷报告包含以下元素：
1. 标题 ：缺陷的单行描述。
2. 项目 ：所属项目。
3. 问题类型 ：问题报告或变更请求。
4. 负责团队 ：负责解决问题的开发团队。
5. 子段 ：软件问题发生的功能集群，其他组为“NA”。
6. 版本 ：缺陷发生的软件版本。
7. 严重程度 ：分为关键、主要、一般、次要和增强五个级别。
8. 优先级 ：描述缺陷对项目的重要性。

每个缺陷会经历多个状态转换，如提交、接受、调查、解决等。

2.4 数据可用性问题

在使用历史数据时，存在一些问题：
1. 组织变更 ：如 2004 年底至 2005 年初用户名的更改，对历史数据的可靠性和分析类型产生了深远影响，限制了数据的使用。
2. 工具集变更 ：2004 - 2005 年从 ClearDDTS 迁移到 ClearQuest，虽然缺陷报告被导入，但历史记录无法直接导入，需要通过导出附件并解析内容来获取之前的缺陷趋势信息。
3. 数据完整性 ：“负责团队”、“优先级”、“子段”和“版本”等字段在实际使用中存在问题，这些字段可能未填写或信息过时，因此在分析中主要关注受组织变更影响较小的严重程度信息、时间戳和项目字段。

2.5 数据特征

分析的数据来自八个项目，涵盖了近 10 年（1995 年 12 月至 2009 年 11 月）的数据，共收集了 28000 多个缺陷。在此期间，软件系统从约 350 万行代码增长到近 900 万行，涉及多种编程语言。平均每个项目有 300 人参与，其中约 100 人积极参与软件开发和维护。

对于单个项目的数据，呈现出以下特点：
1. 参与人数 ：项目高峰期近 200 人参与。
2. 签入次数 ：签入模式不稳定，与参与人数和缺陷数量无明显规律，因此在当前分析中暂不使用该数据。
3. 缺陷提交数量 ：每月提交的缺陷数量分布较为规律，12 月因人员休假导致提交数量下降，该信息可用于辅助系统质量和上市时间的决策。
4. 工时 ：通过时间跟踪软件记录项目工时，但由于是独立系统，难以与缺陷跟踪系统的数据进行详细关联，目前仅进行高层次的汇总分析。

2.6 瑞利模型

在软件开发生命周期中，开发人员容易犯错，虽然大部分错误在交付前会被发现和修复，但不可能解决所有问题，因此需要在软件质量和上市时间之间进行权衡。瑞利模型被用于描述项目生命周期内缺陷数量的变化趋势。在项目早期，参与人数少，缺陷数量低；随着项目推进，参与人数增加，错误率上升；接近项目结束时，参与人数减少，错误率下降，且重点转向修复缺陷。该模型可用于预测项目生命周期内的缺陷数量，从而确定达到特定质量水平（如 95%的缺陷已解决）的时间。

2.7 上市时间估算

为了使用瑞利模型预测缺陷趋势和达到所需质量水平的时间，需要对项目中发现的总缺陷数量进行粗略估计。通过收集多个已完成和正在进行的项目的规模（以工时衡量）和缺陷数量数据，发现缺陷数量与工时之间可能存在指数关系或逻辑分布关系。
- 指数关系 ：公式为 (d = h^x)，其中 (d) 是项目生命周期内发现的总缺陷数，(h) 是项目的总工时估算，(x) 是常数。通过对数据的分析，发现该关系更为一致，(x) 的平均值在 0.6 至 0.7 之间，即使对于正在进行的项目也是如此。
- 逻辑分布关系 ：公式为 (d = \frac{c}{1 + a e^{-b h}})，其中 (c) 是输出的极限值，(a) 是初始人口增长到 (c) 的倍数，(b) 决定函数的增减性。然而，该模型依赖于预期峰值 (c)，而这个值通常未知，且不同项目的逻辑曲线和参数差异较大，因此对单个项目的预测价值不准确。

2.8 质量估算

虽然理论上可以使用瑞利模型预测缺陷趋势，但在实际应用中存在一些限制：
1. 项目独特性 ：每个项目都是独特的，不同项目的瑞利曲线表现不同，因此基于其他项目数据的瑞利曲线无法准确预测新项目的缺陷趋势。
2. 缺陷提交时间 ：在飞利浦医疗保健的项目中，缺陷直到测试阶段才开始提交，因此瑞利模型仅适用于预测项目的测试阶段。此外，随着越来越多的项目采用敏捷开发模式，其缺陷提交模式与传统瀑布模型不同，目前尚无足够数据确定这些变化对瑞利模型可用性的影响。

尽管瑞利模型不能作为预测工具，但它在监控项目进度和确定达到最低质量水平的时间方面非常有用。通过估算总缺陷数量，可以计算出 95%的缺陷已解决的时间点。在测试阶段早期，估计可能不准确，但随着项目进展，瑞利曲线会逐渐收敛到一个点，通常在测试阶段中期，可以确定产品的发布时间。

综上所述，在软件项目中，架构投资决策和时间 - 市场与质量的平衡是复杂而关键的问题。通过 StArch 方法可以更科学地进行架构投资决策，同时利用历史数据和瑞利模型可以更好地平衡产品的上市时间和质量。

3. 综合分析与实践建议

3.1 架构决策与质量平衡的关联

架构投资决策和时间 - 市场与质量的平衡并非孤立的问题，而是相互关联的。在进行架构投资决策时，需要考虑到项目的质量要求和上市时间限制。例如，在使用 StArch 方法进行决策时，评估标准中的净现值和销售优化等因素，都与产品的质量和市场竞争力相关。而在平衡时间 - 市场与质量时，架构的合理性也会影响到开发效率和缺陷数量。一个好的架构可以减少开发过程中的错误，提高软件的质量和可靠性，从而缩短上市时间。

3.2 实践中的操作建议

为了更好地实现架构决策和质量平衡，以下是一些实践中的操作建议：
1. 加强团队协作 ：架构师、管理者和开发人员等不同角色之间需要加强沟通和协作。在 StArch 方法的应用中，不同角色对决策过程和信息的需求不同，因此需要通过有效的沟通来确保各方的意见得到充分考虑。例如，可以定期组织跨部门的会议，讨论项目的进展和问题。
2. 充分利用历史数据 ：无论是架构决策还是质量平衡，历史数据都起着重要的作用。在 StArch 方法中，历史数据可以用于制定战略地图和计分卡；在瑞利模型中，历史数据可以用于预测缺陷数量和确定质量水平。因此，需要建立完善的数据管理系统，收集、整理和分析历史数据，为决策提供支持。
3. 灵活调整方法 ：不同的项目具有不同的特点和需求，因此在实践中需要根据项目的实际情况灵活调整方法。例如，在使用瑞利模型时，如果项目采用了敏捷开发模式，就需要考虑到敏捷开发的特点，对模型进行适当的调整。同时，在 StArch 方法中，也可以根据项目的战略目标和评估标准，对决策步骤和计分卡进行优化。

3.3 案例对比分析

为了更直观地说明架构决策和质量平衡的重要性，下面进行一个案例对比分析。假设有两个项目 A 和 B，项目 A 在架构决策时没有充分考虑到质量和市场因素，采用了一种简单但不太可靠的架构；而项目 B 则使用了 StArch 方法，综合考虑了各种因素，选择了一种更合理的架构。在开发过程中，项目 A 由于架构的问题，出现了大量的缺陷，导致开发进度延迟，上市时间推迟；而项目 B 由于架构合理，缺陷数量较少，开发进度顺利，按时上市。从市场反馈来看，项目 B 的产品质量得到了用户的认可，市场份额逐渐扩大；而项目 A 的产品则因为质量问题，受到了用户的批评，市场份额逐渐缩小。

通过这个案例可以看出，合理的架构决策和有效的质量平衡对于项目的成功至关重要。在实际项目中，需要重视架构决策和质量平衡，采用科学的方法和工具，确保项目的顺利进行和产品的市场竞争力。

4. 总结与展望

4.1 总结

本文主要探讨了软件项目中的两个关键问题：架构投资决策和时间 - 市场与质量的平衡。在架构投资决策方面，介绍了 StArch 方法，该方法整合了多种管理工具和分析方法，通过四个步骤指导架构师和管理者进行决策。通过实际案例分析和评估，发现 StArch 方法在明确架构对业务战略的贡献、避免个人偏好等方面具有优势，但不同从业者对估算计分卡和信息完整性的看法存在差异。在时间 - 市场与质量的平衡方面，介绍了医疗设备行业软件面临的挑战，以及如何利用历史数据和瑞利模型来监控项目进度和确定质量水平。虽然瑞利模型在预测新项目的缺陷趋势方面存在一定的局限性，但在监控项目进度和确定产品发布时间方面具有重要作用。

4.2 展望

未来，随着软件行业的不断发展，架构决策和质量平衡的问题将变得更加复杂和重要。为了更好地应对这些挑战，可以从以下几个方面进行改进和完善：
1. 方法的进一步优化 ：对 StArch 方法和瑞利模型进行进一步的研究和优化，提高其准确性和适用性。例如，可以结合机器学习等技术，对历史数据进行更深入的分析，为决策提供更精准的支持。
2. 跨领域的融合 ：将架构决策和质量平衡与其他领域的知识和方法进行融合，如项目管理、风险管理等。通过跨领域的融合，可以更全面地考虑项目的各种因素，提高决策的科学性和有效性。
3. 人才培养 ：培养更多具有架构决策和质量平衡能力的专业人才。这些人才需要具备丰富的软件技术知识、管理经验和数据分析能力，能够在复杂的项目环境中做出合理的决策。

总之，架构决策和质量平衡是软件项目成功的关键因素。通过不断地探索和实践，采用科学的方法和工具，加强团队协作和人才培养，我们可以更好地应对软件项目中的挑战，提高软件产品的质量和市场竞争力。

5. 可视化呈现

5.1 流程图：StArch 决策流程

graph LR
    A[制定战略地图和计分卡] --> B[提出场景]
    B --> C[估算计分卡]
    C --> D[决策]

5.2 表格：缺陷报告元素

元素	描述
标题	缺陷的单行描述
项目	所属项目
问题类型	问题报告或变更请求
负责团队	负责解决问题的开发团队
子段	软件问题发生的功能集群，其他组为“NA”
版本	缺陷发生的软件版本
严重程度	分为关键、主要、一般、次要和增强五个级别
优先级	描述缺陷对项目的重要性

5.3 流程图：缺陷状态转换

graph LR
    A[提交] --> B[接受]
    B --> C[调查]
    C --> D[解决]
    D --> E[验证]
    E --> F[关闭]

通过以上的流程图和表格，我们可以更直观地了解 StArch 决策流程、缺陷报告元素和缺陷状态转换过程，有助于更好地理解和应用相关的方法和工具。