数据的三重奏:业务实体、数据对象与属性
发布于 2026-04-07
1474
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
文章主旨:通过构建“业务实体-数据对象-属性”三层概念框架,打通COSMIC与NESMA/IFPUG在数据层面术语差异的鸿沟,揭示两者在本质上是对业务与系统不同视角的反映。
关键要点:
- NESMA的逻辑文件 ≈ 业务实体,是业务视角的最小有意义数据单元;记录类型(RET)≈ 数据对象,是系统视角的存储单元。
- COSMIC的兴趣对象 ≈ 数据对象,即系统能够独立存储和管理的数据结构。
- 属性是数据对象内部的原子内容,外键是连接多个数据对象以还原业务实体的桥梁。
- 当一个业务实体对应多个数据对象时,NESMA用一个逻辑文件包含多个记录类型描述,COSMIC用多个兴趣对象描述,两者在数据对象层面概念对齐。
- 统一框架有助于理解两种估算方法的本质,并促进业务分析与技术实现的协同。
内容结构:
- 引言:指出COSMIC与NESMA/IFPUG对数据概念的术语差异(如逻辑文件、记录类型、兴趣对象),提出以“业务实体-数据对象-属性”三层框架统一概念。
- 一、业务之眼:聚焦“业务实体”
- 定义:业务实体是业务层面可识别、可处理的整体对象,是业务能力的最小原子交付物。
- 举例:订单、保险合同。复合业务实体(如合同)可分解为原子业务实体(合同主信息、合同标的物清单、合同受益人清单)。
- 结论:NESMA的逻辑文件 ≈ 业务实体。
- 二、系统之眼:雕琢“数据对象”
- 定义:数据对象是系统的最小有意义存储单元。
- 业务实体与数据对象的关系:1对1(简单订单)或1对多(订单头+订单明细)。
- COSMIC的兴趣对象即数据对象,NESMA的记录类型(RET)也对应数据对象。
- 结论:NESMA的RET ≈ COSMIC的兴趣对象 ≈ 数据对象。
- 三、属性:构成数据的原子内容
- 属性是数据对象的内部细节,外键是连接不同数据对象以还原业务实体的关键属性。
- 结论:属性是原子颗粒,外键是粘合剂。
- 四、三个层次的统一框架
- 表格展示宏观层(业务实体)、中观层(数据对象)、微观层(属性)在三者中的对应关系(NESMA:逻辑文件/记录类型/字段;COSMIC:广义兴趣对象/兴趣对象/兴趣对象属性;责任主体:业务方/开发方/开发方)。
- 关键纽带:外键。
- 五、殊途同归:统一视角下的双模型
- 业务实体 = NESMA逻辑文件 = COSMIC广义兴趣对象;数据对象 = NESMA记录类型 = COSMIC狭义兴趣对象。
- 二者观察角度不同但概念对齐。
- 六、示例印证
- 保险合同案例:合同(复合业务实体)在NESMA中为一个逻辑文件包含三个记录类型,在COSMIC中为三个兴趣对象,在数据对象层面统一。
- 七、结语
- 术语差异的本质是业务视角与系统视角的自然分野。三层框架是理解估算模型和业务-技术协同的钥匙,强调数据始终是软件核心。
文章总结:本文通过构建层级概念模型,清晰解释了COSMIC与NESMA在数据概念上的内在一致性,为实践者提供了跨方法理解与应用的实用桥梁。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1169.3K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
案例:需求问题的解决方案
讨论时间:2012-09-14下午13:00至14:45参与人员:EPG3人,需求开发部门负责人一名,项目经理一名 1现象与问题:(1)开发人员反映需求没有说清楚, 写的人认为需求很清楚了。(2)是写清楚,还是说清楚?以谁的意见为主?如果说清楚呢,语言没有证据,不如文字规范。将来发生了需求变更时有争议。(3)需求人员没有讲解约定俗成的,默认的东西,开发人员没有概念。(4)需求人员抱怨开发人员写的软
穷举、分类、分层、抽象的要义
穷举、分类、分层、抽象是我推荐的4种分析问题的方法,即可以用于需求的分析,也可以用于其它的方面。
穷举就是罗列出所有可能的情况。当知道某一种可能的时候,要举一反三,列出所有的可能,针对问题的全集考虑解决方案。假如你考虑开发一个库存管理系统,有入库单、出库单、损溢单等3种类型的单据,有2种帐本:库存流水帐、库存成本帐。当考虑记帐的算法时就要考虑3*2=6种情况,也就是说要考虑6种算法,这就是穷举。在做软件需求分析时,尤其需要穷举的方法,确保需求的完备性。采用穷举
项目管理的三架马车
决定项目成功的核心角色是什么?我认为是三个角色:项目经理、技术经理与需求经理。
项目经理:解决管理上如何做的问题,对项目的进度与质量负责。具体职责包括了:过程定义、估算、计划制定、计划跟踪与控制、风险管理、质量管理等。
技术经理:解决技术上如何做的问题,对项目的技术方案负责。具体职责包括了:技术可行性的评估、技术方案的确定、设计、设计验证、技术难题的解决、实现等。
需求经理:解决做什么的问题,对项目的需求与范围负责。具体职责包括了:需求获取、需求分析、
过程改进不能这样啊
过程改进是长期行为: 公司的高层对软件规范管理的认识有一个过程. 公司负责过程改进的人员对规范管理的理论的理解也需要一个过程. 公司的规范体系的推广需要一个实用化的过程. 公司的开发人员认识规范管理也需要一个过程. 公司的管理问题的解决从认识到制定措施,落实措施,优化措施也需要一个过程. 公司的管理体系真正制度化也不是短期内能做到的. 任何事情都有其发展的必然规律.违反了客观规律是要摔跟头的,
如何保证测试的完备性?
经验法则如下:1 测试人员参与需求评审,需求人员参与测试用例的评审不懂需求,不了解需求的测试人员是不可能设计出完备的测试用例的。测试人员参与需求评审一是可以评审需求的可测试性,二是了解需求。 需求人员评审测试用例可以检验用例的完备性,判断测试人员是否理解了需求。2 系统测试用例覆盖每一个场景场景是在需求中描述的用户使用系统的一条操作路径。覆盖每个场景是系统测试用例设计的基本要求。3 集成测试用例
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线