- 博客(37)
- 收藏
- 关注
RSS订阅
原创 ASPICE对追踪性和一致性要求
微信公众号 SystemEngineeringLabAutomotive SPICE PAM V3.1中对双向追踪性和一致性要求主要在系统系统工程过程组、软件工程过程组、变更管理过程以及相关管理过程中。双向追踪性和一致性整体要求如下：系统工程和软件工程过程中，双向追踪性主要体现在：V模型左侧的需求、架构、设计和实现之间V模型左侧的需求、架构、设计和实现与V模型右侧对应的测试规范...
2019-02-20 21:11:31
5900
1
原创 ASPICE:能力等级评定
微信公众号 SystemEngineeringLabAutomotive SPICE 标准中为了便于评估师进行过程能力等级评估提供了不同的indicator, 具体包括Process Performance indicator和Process Capability Indicator。Process Performance Indicator为标志了过程结果（Process Outcome...
2019-01-29 18:06:13
10996
原创 Automotive SPICE Introduction
Automotive SPICE于2005年由AutoSIG发布，是SPICE(ISO\IEC15504国际标准)在汽车行业的衍生标准，其关注汽车行业的软件过程改进和能力测定。ASPICE兴起于欧洲，广泛用于主机厂以及供应商企业自身的的过程能力改进，以及对供应商的风险评估。从更务实的角度，主机厂基于供应商的ASPICE等级评定其是否具有供应商资质。ASPICE中的过程ASPICE中的过程被...
2019-01-29 18:04:12
1962
原创 敏捷开发-Scrum
更多请关注微信公众号 SystemEngineeringLabScrum Guide: https://www.scrumguides.org/scrum-guide.htmlScrum是一种敏捷过程框架，不同于其他敏捷开发方法，Scrum不仅仅适用于软件开发领域。1. Srum 的目标Deliver the highest business value in the shortt...
2019-01-07 22:16:56
1310
2
原创 敏捷的本质
更多请关注微信公众号 SystemEngineeringLab我们一直在谈论敏捷、学习并实践敏捷，在敏捷大爆发的今天，许多组织或团队都声称是“敏捷的”，那么到底什么是 “敏捷” 呢 ？要回答这个问题，我们必须要要回归到敏捷诞生的标志–敏捷宣言。1. 敏捷的诞生在2001年，17位具有反叛精神的软件开发方法的代表性人物相聚在犹他州的雪鸟城，并进行为期三天的小型会议。这些人都是来自当时“轻量...
2019-01-02 16:25:08
800
原创 设计模式之外观模式
系统的通用设计目标是最小化子系统间的通信和依赖。实现该设计目标的一种方式是引入外观对象，为子系统中的通用设施提供一个单一并且简单的接口。与适配器模式区别本质上二者的模式意图不同：适配器是将接口转换为不同接口，外观模式是提供一个统一的接口来简化子系统的访问。基于外观模式，客户端请求首先到达外观类，并由外观类负责路由并委托到具体的子系统类处理逻辑。为子系统的接口集合提供一个统一接口，Facade定义高层接口使得子系统更容易使用。将客户单请求委派给合适的子系统对象。外观对象：Facade。
2025-03-24 10:28:44
460
原创 系统架构书单推荐（一）领域驱动设计与面向对象
想寻找 “到底什么是软件架构” 这一问题的答案，Mark Richards, Neal Ford 两位大师在该书中从自身视角对软件架构进行了定义说明，并详细描述的不同的应用架构风格及其多维度的指标分析。推荐理由：黑天鹅事件、《三体》中的射手和农场主假说......在混乱的表象之上，我们应该如何追本溯源、直达问题的本质，相信这本书能带给你一些醍醐灌顶的收获。：该书技术思想领域的开创性作品，归纳总结了技术的定义，详细解释了技术的进化机制，并且构建了一个完整的关于技术的理论体系。
2025-03-22 11:55:27
846
原创 业务概念模型，你必须知道的建模分析工具
对于概念模型我们并不陌生，其本质是模型，是对某个域信息的建模，例如常见的E-R图是对数据模型的建模。多数情况下，作为技术我们更多的接触的是技术域的分析与建模。业务概念模型（Business Conceptual Model）是一种用于描述业务领域核心概念及其关系的工具，业务概念模型的本质在于语言对齐（或统一语言）。它通过定义业务术语及其关系，建立业务团队与技术团队之间的共同语言，确保双方对业务需求的理解一致。业务概念模型是技术无关的，其不涉及技术实现细节，而是专注于业务域逻辑的抽象与表达。
2025-03-21 17:45:21
822
原创 软件架构图评审检查单
设计意图的传达是架构可视化关注的重要维度，在技术方案评审过程中不可避免的会出现各种各样的架构图或设计图，这些图形化表述在设计设计意图传达效果层面表现不一。不论架构设计者，还是参与设计评审的开发人员，对于形式各异的 “架构图” 是提供通用的参考关注点，以便干系人。是否能够理解架构图中每个元素的类型？是否能够理解架构图中的每个关联关系（适合标明技术选型的场景）的。是否能够理解架构图中的每个元素是做什么的？是否能够理解架构图中的关联关系的简称或缩写？(比如，进程间的交互的协议)是否能够理解架构图中元素使用的。
2025-03-21 17:43:06
314
原创 代码评审的参考规范
不要惧怕提出问题，这更容易提高你对问题的认知，如果最终发现你提出的问题是错误的，这对你也是一项难得的提高。不要为了提高评审速度而牺牲代码评审的标准，团队内的代码评审应该是一个持续改进的过程，发现问题、解决问题、避免问题，这种正向循环会为研发流程的每一步都带来收益。代码评审的目的就是为了保证公司整体代码的健康状况随着不断迭代，始终保持一个较高的水平，所有在评审中使用的工具和流程都应是为此目的而设计的。如果评审尺度严格导致研发人员抱怨，那么礼貌的坚持非常有必要，严格的代码评审有助于产出优秀的代码。
2025-03-21 17:39:55
596
原创 分层单体应用架构的本质
良好的模块化是单体走向微服务的重要基石，如果模块化设计较差的系统，不仅会增加微服务拆分的成本，更为重要的是，会增加拆分后形成分布式单体的概率和风险。技术视角是研发友好的，作为开发人员，天然的可以理解和接受这种技术维度的统一语言：DAO层只负责处理数据相关逻辑，Controller层之服务处理Restful API相关，RPC层只处理与外部系统的跨进程调用等等。首先会想到的例子，比如，如果底层的数据库发生了变更，又或者ORM框架发生了变更，那么，我们只需要修改DAO层的实现，而不需要更改上层的业务层代码。
2025-03-21 17:28:38
487
原创 探寻软件架构的本质，到底什么是架构？
不论是开发人员还是架构师，我们都一直在跟软件系统打交道，架构是在工作中出现最频繁的术语之一。那么，到底什么是架构？你可能有自己的答案，也有可能没有答案。对“架构”的理解需要我们不断在实践中思考、归纳、演绎，形成自己的认知。
2025-03-21 17:26:51
948
原创 相比微服务，模块化单体应用架构可能是更好的选择?
虽然微服务架构风格有其独特优势，但前提是合理架构、划分业务单元。完全无脑的进行微服务化、拆分成庞大的子系统有时并不是一个好的选择，特别是针对初期项目，基于模块化单体应用架构可能是更好的选择。通过系统的不断迭代，随着上下文变化逐渐演进，是一个建议的方式。
2025-03-19 19:58:49
807
原创 浅谈业务系统代码与应用架构-回归代码本身
对于应用系统本身而言，除了满足功能性需求之外，还要满足特定的架构属性（不同的文章对架构属性有不同的称呼，有些称之为“非功能性需求”，有些称为“质量属性”）。
2025-03-19 19:57:19
1086
原创 状态机模型，你真的搞懂并用对了吗？
状态机时一种非常有效的抽象的系统行为的分析建模工具，在工程实践中具有较高价值。通过对实体状态建模，有利于业务与技术对领域有一致性理解，并能够有效指导后续的工程实现。值得注意的是，技术人员要对业务状态机和系统状态机有清晰认识，不要混为一谈。由于二者出发视角的不同，技术视角的系统状态机更加偏重于实现，业务状态机更加面向客户。
2025-03-19 19:55:41
1501
原创 规避系统用例建模的常见 “陷阱” ！
在业务分析过程中，用例建模是分析需求的重要方式，其本质上是对问题域范围的一种抽象，建模过程也是抽象过程。C4模型中的上下文或边界图也是一种高层的分析建模方式，其表述的目标系统如何融入到当前IT环境，是技术无关的概念。系统用例则表征的是目标系统与参与者的交互，表述目标系统对外提供的功能。见多有四层包含关系的用例图，也见过一张用例图中用例个数超过20个的情况，虽然，“更多的用例可能能够更全面的表达需求”，但，往往会提高干系人的认知成本，严重降低可视化建模带来的有效信息传递效率，使得建模分析的结果大打折扣。
2025-03-19 19:53:36
650
原创 聊聊技术方案设计的普遍问题与参考实践
技术方案的设计没有完全统一的标准，也不应该有强制标准。团队内可以根据自身情况制定可裁剪的技术方案设计模板，作为团队方案设计的参考。“好”的技术方案可能不是面面俱到、事无巨细的表述，应该结合迭代需求/产品建设的上下文灵活的决定技术方案要体现的内容、详细程度等。“好”的技术方案应该是有清晰的背景说明、关键的技术实现方案表述、能够在干系人间达成一致，并能指导团队实施落地。
2025-03-18 15:00:02
896
原创 状态机模型，你真的搞懂并用对了吗？
状态机时一种非常有效的抽象的系统行为的分析建模工具，在工程实践中具有较高价值。通过对实体状态建模，有利于业务与技术对领域有一致性理解，并能够有效指导后续的工程实现。值得注意的是，技术人员要对业务状态机和系统状态机有清晰认识，不要混为一谈。由于二者出发视角的不同，技术视角的系统状态机更加偏重于实现，业务状态机更加面向客户。
2025-03-18 11:06:41
321
原创 如何管控与外部系统的对接集成？
研发部团队在系统建设过程中，多有与公司内外部系统能力对接的场景。对接的质量不尽相同，有些团队对对接的各个环节把控严格，则质量会偏高，有些团队把控较弱，则质量偏低。对接质量直接影响团队的研发成本、开发效率及线上系统稳定。外部集成对接的场景较多，比如对接公司内部成熟能力、对接公司内部团队同步迭代支持的能力、外部供应商能力等等，本文聚焦的场景是公司外部供应商能力对接、公司内部同步迭代支持等需要我方与外部团队紧密协作的场景。
2025-03-18 10:57:57
711
原创 简单高效的草图辅助可视化建模
系统设计过程中基于UML进行可视化建模是普遍的方式，但是，在某些场景下，使用轻量级的草图表述方式比UML图更加简单和高效。其是轻量级的白板工具，支持在线和离线使用方式，可以快速进行草图绘制及团队间的远程沟通协作。建议团队基于自身的建模可视化风格，尽量统一草图的常见图标并形成模板，例如常见的数据库、中间件等，有助于提升图形信息传递效率，降低沟通成本。虽然ExcaliDraw社区的图标库有限（技术领域），但线框图能支持绝大多数草图场景。方式二：打开在线网址，在导航栏右侧点击安装按钮本地安装使用。
2025-03-18 10:55:12
302
原创 如何做好团队的技术方案评审？
团队技术方案评审的效果总是差强人意，低质量的方案评审导致人力成本的浪费以及后期落地成本的增加，本篇文章探讨一下 “如何做好团队技术方案评审？技术方案评审是研发生命周期中最为常见的活动，技术方案评审会是最常见的活动形式。一般由研发人员基于产品需求完成技术方案设计之后，在干系人间发起技术方案的评审。作为架构师几乎每周都会参加1-2次团队的技术方案评审会，每个业务线团队的评审会质量层次不齐。在如此多的干系人参会情况下，如果评审会不能够有效的达成一致性认知，那么其造成的人员成本浪费可想而知。
2025-03-18 10:49:48
955
原创 从哲学到工程，聊聊构建高可用分布式系统
高可用是系统提供无故障服务的能力。有太多资料探讨如何构建高可用系统，但多是一些工程实践知识点的堆叠。这篇文章我们从更朴素的视角去透视分布式系统的高可用建设
2025-03-18 10:46:15
1141
原创 软件架构可视化及C4模型
软件架构设计的终极目标不在于设计本身，而在于架构设计意图的传达。图形化有助于在团队间进行高效的信息同步，但不同的图形化方式在语义一致性和效率间存在平衡。C4模型通过不同的抽象层级来表达系统的静态结构，并提供了最小及的抽象建模元素，为设计人员提供了一种低认知负载、易于学习和使用的高效的建模方式。在实际项目落地过程中，结合C4模型以及UML、线框图等组合方式对架构设计进行可视化表达，一定程度上能够提升团队对架构设计认知的一致性以及建模效率。
2023-02-12 22:17:44
83
原创 DDD 参考工程架构
应用架构模式的选择是系统架构设计的重要维度之一，结构不仅仅是简单的包结构和命名，其传达的是一种顶层抽象，背后包含了大量的实践和知识。制定符合团队情况的工程参考架构，并在团队成员间达成共识非常重要。领域驱动设计并没有统一的、通用的架构，试图定义标准架构是不切实际的。本文描述的工程架构只是一个参考，实践过程中应该基于团队特定情况而有所差异，但原则上都应该遵循业务域与技术域分离的核心理念。
2023-02-12 22:09:57
1899
原创 【ALM】Polarion RM 与 IBM Rational DOORS
Polarion RM 与 DOORS 对比更多请关注微信公众号 SystemEngineeringLab 相关背景Polarion RM 和DOORS 是目前需求管理领域内的两款典型的商业工具。 Polarion RM 是西门子ALM解决方案Polarion ALM 中组成部分，是一款基于Web的需求管理系统。Polarion ALM 目前已广泛服务于汽车、航空航天、医疗等领域。...
2018-07-23 08:03:35
4005
原创 【MBSE】系统工程的本质
引言本篇博文是基于模型的系统工程（MBSE）的开篇，主要对系统工程进行简要的介绍，并随着后续文章的深入，逐步揭开MBSE的神秘面纱。 文中的部分内容其实也是作者的一些读书笔记。2. 系统的本质我们基于这样一个论点： 系统思想是系统理论的基石在认识系统理论之前我们有必要先了解 “系统思想” 的含义。基于辩证唯物主义的哲学观点，系统是客观存在的，系统思想也是客观存在...
2018-07-01 23:57:34
4232
原创 【OSLC】OSLC Overview
1. 引言相信大家凡是查看到这篇博文，大多的可能是从事系统集成工作，又或者是从事软件工程相关的咨询工作，想要了解OSLC的基本概念以及原理。作者将以一系列的博文对OSLC的方方面面进行介绍。2. 相关背景2.1 信息孤岛与跨生命周期协作的冲突我们说, OSLC解决的是系统集成问题，那么，我们需要先从系统集成的源头说起。企业信息化的过程向来不是“一蹴而就”，而是通过迭代、渐进的方...
2018-06-29 23:28:36
3465
1
原创 【HLA】初识HLA/RTI
本文主要对近期所翻阅的一些论文及资料进行的概要性整理，后续会有更多的关于HLA的研究细节发布，基于博客园的知识共享平台，以期共同进步！一、引言仿真的历史由来已久，在系统研制过程中，基于建模及仿真技术能够有效的降低系统研制周期、提高研发效率以及提高系统的可靠性和稳定性。随着系统规模和复杂度的不断提高，如何提高仿真效率是重要的研究课题之一。分布式仿真能够充分利用分布式并行计算的特点，大幅度提高
2017-04-13 10:50:54
6843
1
原创 【DOORS】需求管理实施过程中的需求属性
一、引言 企业在项目中实施需求管理过程中，其中关键的一点是对需求内容进行存储和管理。而针对于需求管理而言，单纯的需求内容的管理是重要的，但是不完备的。需求的表述除了 需求主体 之外，往往还需要额外的属性信息进行补充描述。这些属性的类型随着企业特点、项目特点或是业务流程的不同而有所差异。需求属性的选择不依赖于具体的需求管理工具，而是基于实际的也无需求驱动。本文主要对需求管理实践中一些常用的、典型
2017-04-13 10:50:51
1257
原创 【SysML】模块定义图(BDD, Block Definition Diagram)
一、引言SysML中的模块定义图，英文为 “Block Definition Diagram”，简称BDD，是系统建模过程中最为常见的图之一，BDD是一种结构图，它主要对系统的结构组成以及组成元素间的关系进行描述。SysML中的图类似于UML中的类图，在学习的过程中可以以类比的方式进行学习。二、模块定义图介绍 如下图所示，BDD中可以包含 包、模型、模型库、视图、模块和约束模块。其中最
2017-04-13 10:50:46
3376
原创 【DOORS】如何基于DOORS实施需求管理
引言IBM Rational DOORS，简称DOORS，是被业界广泛认可的需求管理工具，在国内外需求管理领域具有较高的市场占有率。需求管理作为传统的工程领域，理论发展相对成熟和健全。随着越来越多的企业开始注重在需求管理工程层面的投入，企业的需求管理成熟度也在逐步提高。在需求管理实施过程中，不可避免的会依托相关的需求管理工具支撑。而实施过程中所存在的关键困难之一就是：工具与业务如何紧密结合。很多
2017-04-13 10:50:40
3665
原创 【DOORS】产品功能介绍
引言据权威组织调查结果显示，项目的成功与失败与项目的需求息息相关。高效的需求管理有助于降低由于需求原因导致的项目失败风险，提高项目成功的几率。随着人们对需求管理认识水平的不断提高，越来越多的企业开始重视需求管理领域。同样，由于商业价值的驱动，也推动了商业化需求管理支撑工具的诞生。其中，本次文章的主角-DOORS就是这样一款出色的商业化的需求管理工具。背景DOORS，全称 “Dynamic O
2017-04-13 10:50:35
5316
原创 【需求工程】KANO模型
引言 1979年10月东京理工大学教授狩野纪昭（Noriaki Kano）和其同事 Fumio Takahashi发表的论文 《Motivator and Hygiene Factor in Quality》，该论文第一次将满意与不满意引入质量管理领域。狩野教授于1982年完成了 《Attractive Quality and Must-be Quality》研究报告，并与1984年正式表
2017-04-13 10:50:31
1519
原创 【Harmony】概述
原文来自本人的微信公众号文章 系统工程实验室 引言基于模型的系统工程（简称MBSE，英文全称Model based System Engineering ）的实践至少需要三个维度的支撑：建模语言、建模方法论和建模工具。建模语言为模型的表述提供了统一的支撑，建模方法论为建模的行为提供了更为一致的准则，建模工具为建模的实现提供了更为自动化的支撑。今天要讨论的主题 “IBM Rati
2017-04-13 10:50:25
3740
原创 【SysML】用例图
用例图是一种黑盒视图，表征系统对外部参与者的可见行为或服务。用例间具有泛化、扩展、包含三种关系。通过包含和扩展关系可以对系统通用行为进行重构。
2017-03-21 10:50:25
1288
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人