提示5-3:始终描述构建块视图的 Level 1(Level 1是你的朋友)!
提示5-3:始终描述构建块视图的 Level 1(Level 1是你的朋友)! #building-block #hierarchy #essential #lean 即使您文档非常节俭,可用的文档时间或资源也有限……您也应该遵循架构文档的最基本规则之一: 始终描述构建块视图的 Level 1 __Level 1__: 使构建块的顶级结构变得明确! 随着时间的推移,通常保持相当稳定——因为顶级系统分解通常波动性很小或没有波动性。 因此,只会引起很少的维护或改变努力…… ...
提示5-4:确保外部接口与 level 1 的一致性
提示5-4:确保外部接口与 level 1 的一致性 #building-block #external-interface #whitebox 确保 level 1 始终(在外部接口方面)与系统的范围和上下文(arc42第3节)保持一致。 下图显示了从上下文到构建块 level 1 的这种一致细化示例。 图中的“refinement”可以理解为“细化” ...
提示5-9:使用运行时视图来解释或指定白盒!
提示5-9:使用运行时视图来解释或指定白盒! #building-block #whitebox #runtime-view 如果您想影响白盒的内部结构,但不想指定所有细节,您可以从运行时视图中应用技术: 描述白盒所需的(运行时)行为,例如: 伪代码 活动图或流程图 状态图或状态机 此类信息为架构师或开发人员提供了一些如何构建或构建此白盒的信息,但没有指定所有包含的细节。 ...
提示6-10:在场景中使用小型和大型构建块!
提示6-10:在场景中使用小型和大型构建块! #runtime-view #scenario #building-block #lean 为了节省精力,您可以在单个场景中混合各种抽象级别(或大小)的构建块,而不是显示所有低级交互。 请参阅以下示例(左侧是构建块层次结构,右侧是一个场景) 混合抽象水平可以节省精力当您显示一些大型或更抽象的构建块时,您将在场景中隐藏它们的内部工作或内部流程。在上面的示例中,您完全隐藏了构建块B的内部工作……您只是没有描述或指定B执行任务的 ...
提示8-11:构建块和概念之间的(超)链接!
提示8-11:构建块和概念之间的(超)链接! #concept #building-block #lean 您应该指出哪些概念应用于某些构建块。见提示5-10。 为重要概念分配一个独特的名称给你的重要概念起个名字(下面的例子使用相当奇怪的名称“X-service”,我们真诚地希望你的命名比我们的更好)。 意图公布的名字将是完美的: «fyne-ui»-如果您使用Fyne框架在Go中创建多平台图形用户界面…«template-method-pattern» - 以防您的系统 ...
提示3-17:将业务背景与技术信息相结合!
提示3-17:将业务背景与技术信息相结合! #context #technical-context #business-context #基础设施 #lean 即使在典型的业务环境中(如下图所示),包括某些技术细节,如传输信箱、VPN(虚拟专用网络)甚至服务器/硬件信息,也可能有所帮助。 通常,我们建议将业务与此类技术信息分开,但组合可能会节省一些文档工作 ...
提示1-14:使用清单来满足质量要求!
提示1-14:使用清单来满足质量要求! #requirement #quality #quality-tree #iso-25010 #thorough 凭借其分层表示(见下图),ISO标准25010为顶级质量“主题”提供了一个很好的清单。 作为一个更实用的替代方案,考虑arc42子项目“质量要求示例”(见提示1-15),以了解60多个现实世界的质量要求示例。 一些常见的“质量主题”是: 可用性 可修改性 可维护性 可靠性/稳健性 性能(运行时效率) 安 ...
提示1-16:在介绍中只描述前3-5个质量目标!
提示1-16:在介绍中只描述前3-5个质量目标! #requirement #quality #scenario #lean #quality-goal 虽然您必须满足利益相关者要求的所有质量目标,但您应该保持文档的这一部分简短。在这里,在第1.2节中,您只描述了这些要求中的一小部分(前3-5名)。 使用带有场景的简要解释(见提示IV-12),而不仅仅是关键字。 所有其他质量目标和要求都可以在需求规范或 arc42 第10节的质量树中找到。 ...
提示1-22:如果您的管理层已经维护了,请跳过利益相关者表!
提示1-22:如果您的管理层已经维护了,请跳过利益相关者表! #requirement #stakeholder #lean 如果您的管理层已经保持了一致的利益相关者概述(包括他们各自对架构工作的期望),则不要记录利益相关者表。 如果您的管理层(例如项目管理或产品所有者)认真对待利益相关者的概述,因此维护一个利益相关者表,您只应该在架构文档中横切引用它。 但要小心:根据我们的经验,项目经理专注于有关利益相关者(例如,联系方式和联系人)的组织信息。在arc42中,我们需要 ...
提示1-23:按兴趣和影响力对您的利益相关者进行分类!
提示1-23:按兴趣和影响力对您的利益相关者进行分类! #stakeholder #lean 特别是在时间紧迫的情况下工作时,你只能照顾一些利益相关者。在这种情况下,您可以使用按兴趣和影响力进行视觉分类,而不是利益相关者表。这种分类可以非常非正式地完成,方法是将团队聚集在挂纸白板周围,并根据需要将结果放入文档中。 影响力大,兴趣大:你应该让这些人集中参与进来和/或照顾他们。尽一切全力在各方面满足这类利益相关者。主动与他们沟通。 影响大,兴趣低:投入尽可能多的努 ...