软件项目范围界定中的画布分析与注解应用
1. 引言
在软件项目的范围界定过程中,为了确保项目的顺利实施,需要对项目中的各个方面进行深入的分析和理解。尤其是那些特别复杂或者尚未被充分理解的方面,更需要我们集中讨论。本文将围绕对象画布和集成画布展开,介绍如何通过注解和分析来揭示项目中的潜在问题和需求。
2. 对象画布的注解与分析
2.1 对象模型中的隐藏信息
看似简单的对象模型往往隐藏着大量的领域知识、约束条件、不确定性以及利益相关者的直觉感受,这些信息无法用正式的建模语言(如UML)明确表达。然而,这些非正式的额外信息对于数据结构的正确实现至少与对象模型中指定的细节同样重要。
2.2 对象画布的注解
为了明确表达这些有价值的背景知识,利益相关者可以在对象画布上添加注解。对象画布的注解通常从业务价值、用户价值、政策约束和复杂性注解开始,同时还会添加一两个与应用领域相关的其他工作量注解(如准确性、安全性、灵活性和外部资源注解)。后续可以根据需要在后续轮次中为模型分配额外的注解。
| 符号 | 名称 | 解释 |
|---|---|---|
| 业务价值 | 数据对软件系统的提供者具有特殊价值,例如在线商店中的客户用户资料。 | |
| 用户价值 | 数据对软件系统的用户具有特殊价值,例如在线商店中的客户评级。 | |
| 准确性 | 数据在及时性、精度或一致性方面有特别高的要求,如证券价格的及时性、传感器数据的精度或缓存数据的一致性。 | |
| 安全性 | 数据特别敏感,需要保护以防未经授权的访问或丢失,保护形式包括加密传输、创建备份或电子签名。 | |
| 灵活性 | 数据会因技术或法律演变而发生可预见的结构变化,对于提供纯数字产品的公司尤为重要,如保险公司需要并行维护多个产品世代的众多合同变体。 | |
| 移动性 | 数据要在移动设备上获取或提供,当移动设备的数据量高、有严格的及时性要求,或者将移动设备上捕获的数据传输到中央后端很关键时,此注解尤为相关。 | |
| 自动化 | 数据捕获或处理要实现自动化,对于数字化项目,当需要使遗留数据可用于数字处理时,此注解特别相关。 | |
| 手动任务 | 数据的格式不适合自动处理,如文本文档或其他非结构化数据源,由于语义复杂性无法为自动处理做准备,或者相关流程将继续手动处理。 | |
| 政策约束 | 获取、处理或存储数据受到特定的业务或技术基本条件限制,如保留期限和执行流程所需的数据类型要求(如簿记和会计法规)。 | |
| 复杂性 | 数据的结构或处理比乍一看更复杂,此注解有助于利益相关者避免在交互室中详细建模复杂的数据结构,而是关注整体情况,它可以指出哪些乍一看简单的模型元素隐藏着特别高的复杂性。 | |
| 不变性 | 数据结构不能更改(例如来自不可更改的遗留系统),在迁移或适应项目中,由于现有软件环境的限制无法进行“绿地”软件开发时,了解哪些地方有设计自由,哪些地方需要尊重现有结构很重要。 | |
| 弃用 | 数据在未来将不再可用(例如数据源将停止存在),此注解主要用于迁移和适应项目,以指示哪些数据结构将来需要用新结构替换,以及哪些数据将不再可供新系统使用。 | |
| 需要改进 | 数据需要进行结构或质量上的修订(例如为了实现新的分析类型),更改现有数据结构是一个重大变化,可以用此注解提前突出显示,这需要仔细考虑旧结构中数据的迁移以及使用该数据的所有组件的适应。 | |
| 外部资源 | 数据来自外部源,需要考虑该源(如外部货币转换器)可能并不总是可用,或者对其质量和业务模式的影响可能有限。 | |
| 不确定性 | 数据结构或内容的核心方面存在不确定性,这种不确定性可能是特定性质的(例如某些数据类型的值范围或验证规则),也可能影响设计的较大部分,如物流系统中不清楚描述国际货运交通需要哪些数据。 |
2.3 对象画布注解的分析
在对对象画布进行注解后,IR领域教练会要求利益相关者解释和讨论他们为模型元素分配的注解,并记录详细的评论,以便在项目后期使用。对各个注解及其在各种数据结构上的组合进行分析,也为确定实施工作量的优先级和估算提供了见解。
以下是一些需要特别关注的注解组合情况:
-
灵活性和自动化注解的组合
:一方面要自动捕获和/或处理数据,另一方面又能预见数据的结构变化。这要么需要提前设计足够灵活的数据结构,要么需要在后期再次调整它们,同时还存在在灵活设计或后续更改过程中出现不兼容性或错误的风险。
-
注解之间的冲突
:例如,一个数据结构同时标记了不变性或弃用注解以及灵活性、移动性或业务价值等价值或工作量注解。这意味着一方面要实现一个(新的?)功能需求或业务价值,但另一方面该数据结构显然被归类为遗留组件,进一步开发似乎不合理。这就需要为受影响的数据结构实现复杂的适应或替换机制,或者重新评估遗留系统的战略价值。
-
画布整体的检查
:较大的无注解区域值得怀疑,与其假设该区域的所有利益相关者都清楚一切,更有可能的是没有利益相关者认真思考过这些区域,其中可能隐藏着尚未发现的挑战。这在不确定性注解轮次中有时会变得明显,此时会突然在之前没有注解的模型区域放置问号。
-
注解分配过于普遍的情况
:在注解轮次开始时,IR方法教练会指出正确性要求自然适用于所有数据,但准确性注解应仅应用于需要特别关注的结构。然而,一些利益相关者在分配注解时往往比较慷慨。如果超过三分之一的模型元素都被分配了注解,IR教练应该质疑哪些元素实际上是需要特别关注的特殊价值或工作量驱动因素。
3. 集成画布的介绍
3.1 集成画布的结构与作用
集成画布展示了正在开发的系统与其相邻系统的上下文关系,这有助于明确与系统景观中其他组件的通信和依赖关系。通常,画布呈星形结构,正在开发的软件系统位于中间,通过箭头与相关系统相连。与其他画布一样,集成画布必须保持可管理性,而不是变得过于复杂成为一个完整的基础设施模型。因此,它最多展示正在开发的软件与20个重要相关系统的上下文关系。
3.2 集成画布的方法和符号
在利益相关者绘制过程和对象画布的同时,通常会并行填写集成画布。在过程步骤中发挥作用的外部组件或组织会被安排在集成画布上围绕正在开发的软件。在过程步骤中产生或消耗并与外部参与者交换的数据,会以数据对象的形式记录在对象画布上,并以箭头系统的形式记录在集成画布上。
集成画布的符号使用最少的语法:
- 矩形表示系统景观的组件或正在开发的系统(显示在中心)需要与之通信的其他组件。
- 箭头表示组件之间的数据流动方向,传输的数据实体作为箭头标签注明。
集成画布与经典的数据流程图有几个不同之处:
- 其目的只是展示与哪些组件交换了哪些数据,而不是对系统景观中的所有数据流动进行建模。因此,相关系统之间的数据流动被省略,重点放在与正在开发的软件系统交换的数据上。
- 不区分通信组件是组织内部还是外部的,也不区分它们是技术、机构还是人类通信伙伴。集成画布的目的只是让利益相关者意识到这些关系,以便他们形成对组件之间依赖关系和责任的整体理解。
集成画布中可以交换的数据源类型相当广泛,箭头标签可以描述任何类型的结构化或非结构化数据。然而,利益相关者应确保此处记录的任何数据也反映在对象画布上,以全面了解系统的数据结构。在务实建模的精神下,集成画布中的数据流动箭头不描绘确切的通信协议,而只关注数据交付的主要方向。
以下是集成画布的建模流程:
graph LR
A[利益相关者绘制过程和对象画布] --> B[并行填写集成画布]
B --> C[安排外部组件或组织]
C --> D[记录数据交换]
D --> E[使用最少语法符号表示]
3.3 集成画布的注解与分析
利益相关者可以使用表中列出的注解来标记在集成各种系统组件时需要特别关注的关键方面。集成画布最初会用政策约束、复杂性、外部资源、不变性和需要改进等注解进行标注。如有必要,IR领域教练可以让利益相关者在后续注解轮次中为其他挑战添加更多注解。
| 符号 | 名称 | 解释 |
|---|---|---|
| 高使用 | 组件或接口持续或偶尔承受重负载,例如社会保险公司之间定期交换报告时。 | |
| 安全性 | 组件或接口必须满足特殊要求,以保护其功能或数据免受攻击或丢失,可能需要加密通信以防止未经授权的访问,或设计外部组件的冗余。 | |
| 可靠性 | 组件有特别高的可用性要求,根据正在开发的软件的具体要求,这可能意味着故障的持续时间和频率不得超过一定阈值,或者组件必须设计有冗余,以便在发生故障时切换到备份组件,这可能会导致确保冗余组件之间数据一致性的额外要求。 | |
| 移动性 | 组件需要在移动设备上可用,此注解有助于使用集成画布表示系统组件在移动设备和后端之间的分布,有移动可用性要求的组件通常会导致更高的开发和测试工作量,以确保与各种移动平台的兼容性。 | |
| 政策约束 | 组件或接口受到特殊的业务或技术约束,例如云应用托管位置的法律限制。 | |
| 复杂性 | 处理组件或接口比乍一看更复杂,该注解表明集成该组件需要特别的努力,例如需要转换数据格式,或者使用的交换格式或通信协议特别复杂。 | |
| 不变性 | 组件或接口不能更改(例如因为它是遗留系统),在企业IT环境中,由于适应和质量保证需要过多的努力(前提是公司内仍有必要的专业知识),遗留系统通常保持不变。 | |
| 弃用 | 组件在未来将不再可用,在迁移和适应项目中,此注解可用于标记在项目过程中需要替换或将来会淘汰的组件。 | |
| 需要改进 | 组件或接口的某些方面需要进行调整或优化,这种改进需求可能是实现主要项目目标所需的工作,也可能是在计划的转换工作中可以实现的优化。 | |
| 外部资源 | 组件是外部资源,对其可用性和质量的影响有限,组件是否被视为外部资源取决于计划项目范围内的影响可能性,即使是公司内部管理但不属于计划项目的组件也可能需要指定为外部资源,在组件由独立组织实际运营的情况下,此注解也适用,如果由于组件的外部性导致控制损失和可靠性风险,则建议使用此注解。 | |
| 不确定性 | 组件或接口的核心方面存在不确定性,例如通信协议的具体细节或集成外部服务的方式和方法等更一般性的问题。 |
对注解的解释和讨论提供了背景知识,揭示了在经典的系统景观展示中常常隐藏的需求和约束条件。通过集成画布,这些信息可以在负责集成或运营的利益相关者的脑海中变得明确。分析各个注解及其在各种组件上的组合,也提供了有关集成它们的工作量和风险的见解。
以下是一些需要特别关注的注解组合:
-
高使用和外部资源注解的组合
:意味着特别高的风险,不仅开发的系统承受高负载,而且该负载实际上转移到了运营方无法控制的外部组件上。如果外部资源出现故障,大量用户将受到影响,可能会产生严重后果。
-
移动性和复杂性注解的组合
:如果某个组件的移动连接本身就是一个重大的技术和流程挑战,那么对已经被确定为复杂的组件进行移动化则显得尤为关键。此时,在IR:mobile中仔细研究与该移动化项目相关的挑战可能是值得的。
4. 跨画布分析的重要性
在软件项目范围界定中,仅对单个画布进行分析是不够的,还需要进行跨画布分析,以全面了解项目中的潜在问题和需求。通过整体审视所有画布,可以发现不同画布上语义相关或相互依赖的模型元素之间的注解组合和冲突,这些情况可能在单独查看某个画布时并不明显。
4.1 跨画布的注解组合与冲突
不同画布上的注解组合和冲突可能会给项目带来挑战,以下是一些需要特别关注的情况:
-
安全与灵活的组合
:在系统的生命周期中,为了使安全预防措施适应不断变化的流程、架构和技术等,预计会出现反复的困难或至少需要额外的努力。因此,应制定策略,尽可能将安全基础设施与系统的可变元素隔离开来。
-
安全与外部资源的组合
:所有利益相关者都需要意识到,通常只能在自己组件的边界内保证安全,但系统的用户期望整个系统都具备安全性。因此,需要制定措施,尽可能减少系统边界处的控制损失。
-
弃用与业务/用户价值的组合
:利益相关者需要确保在组件被替换后,仍能提供已识别的价值。然而,存在这样的风险,即被标注的价值方面可能至少在一段时间内受到限制。
-
外部资源与业务/用户价值的组合
:利益相关者需要意识到,注解所强调的价值是由组织影响力有限的组件提供的。存在这样的风险,即相应的功能后来可能无法以满足创造价值要求的方式提供。因此,利益相关者需要考虑是否可以由内部运营的组件以更大的控制权来提供相应的功能。
-
复杂性与业务/用户价值的组合
:强调的价值将由比普通组件更难实现的组件提供,这会导致更高的风险,因此应提供足够的资源来降低风险。
-
灵活性与业务/用户价值的组合
:强调的价值将由一个预计其需求和实现会发生重大变化的组件来创造。这存在这样的风险,即在未来的变化之后,无法以足够的质量提供该价值。
4.2 跨画布分析的流程
跨画布分析可以按照以下流程进行:
graph LR
A[收集各画布的注解信息] --> B[识别语义相关或相互依赖的模型元素]
B --> C[检查注解组合和冲突]
C --> D[分析潜在问题和风险]
D --> E[制定应对策略]
5. 总结
在软件项目范围界定过程中,对象画布、集成画布以及跨画布分析都起着至关重要的作用。通过对这些画布进行注解和分析,可以揭示项目中隐藏的领域知识、约束条件、不确定性以及利益相关者的直觉感受,为项目的顺利实施提供有力支持。
5.1 对象画布的价值
对象画布能够帮助我们挖掘看似简单的对象模型中隐藏的大量信息,通过添加各种注解,如业务价值、安全性、灵活性等,可以明确表达有价值的背景知识。对注解及其组合的分析,有助于确定实施工作量的优先级和估算,提前发现潜在的问题和风险,如注解之间的冲突、画布整体的无注解区域等。
5.2 集成画布的作用
集成画布展示了正在开发的系统与相邻系统的上下文关系,明确了与其他组件的通信和依赖关系。其简单的符号表示和对数据交换的重点关注,使利益相关者能够形成对组件之间依赖关系和责任的整体理解。通过对集成画布进行注解和分析,可以揭示在集成各种系统组件时需要特别关注的关键方面,以及不同注解组合带来的高风险情况。
5.3 跨画布分析的必要性
跨画布分析能够全面审视项目中的潜在问题和需求,发现不同画布上注解的组合和冲突。这些组合和冲突可能会给项目带来各种挑战,如安全与灵活的组合可能导致安全适应困难,外部资源与业务/用户价值的组合可能带来价值实现的风险等。通过跨画布分析,可以提前制定应对策略,降低项目风险。
综上所述,在软件项目范围界定中,充分利用画布分析和注解应用,能够提高项目的可控性和成功率,确保项目能够满足业务需求并顺利实施。在实际项目中,应严格按照上述方法和流程进行操作,及时发现和解决问题,为项目的成功奠定坚实的基础。
42

被折叠的 条评论
为什么被折叠?



