test

# 1. 实际工作中的痛点

作为XX，应用系统开发过程中的质量管控是非常重要的工作。得益于CMMI体系，我们开发中已经有很多规范可循，比如每个阶段的产出物，对各阶段产出物的评审。这些规范可以让过程合规，从形式上保证应用系统的开发质量。

但是

许多软件组织在实施CMMI模型方法中,形式主义的现象很严重（刘晓龙，2013），在一些软件组织中,虽然建立了规范的软件过程,但软件产品的质量仍旧与预定目标存在偏差,致使组织中的相关规范体系流于形式,反而加重了软件组织的负担（李婷，2007）。作为当然应用不错，但不是没有改善的余地

但是依旧时不时听到有不理解的外包人员认为是形式，埋怨编写需求分析、详设，参加评审等工作浪费了编码的时间。虽然随着软件工程的，抱怨的人，但是从其评审材料中可见不是很好，应付的态度。

在参加评审时，在评审员那里，也会听到抱怨：没有讲清楚，怎么能帮你把关、怎么帮你设计？说实话，我自己作为评审员，也会不时有疑虑：你写的听上去都没问题，但是在你没，有没有问题呢？

# 2. 应用系统开发需要遵循的3C原则

有很多原则，需要设计模式、数据库设计范式、面向对象设计中组合（composition）继承和（inheritance）的选择。

但这些原则不能解释回答我们上面的提到的问题。这是因为都是为了解决正确性或者适用性（未来的正确性）。

而从逻辑上来说，正确性不足以。就像下图，每一块拼图都拼对了位置。但是仍然没有得到最终正确的结果，为什么，因为缺少了一块拼图，即未能达成完备性。

## 完备性

很多研究人员也对软件开发相关工作的完备性。比如巴里·保汉教授（南加利福尼亚大学特聘教授，专攻软件工程方向），就提出在应用软件的需求与设计文档中要考虑完备性（completeness），一致性（consistency），可行性（feasibility）与可测试性（testability）（Boehm, 1984）。而前国际软件架构师协会副主席斯科特·惠特迈尔在其《面向对象的软件设计度量》一书中也指出软件设计时要考虑到充分性（Sufficiency），完备性（Completeness）与内聚性（Cohesion）（Whitmire, 1997）。

软件需求分析是不是把需求的方方面面都分析到了？是否有情景遗漏？

## 一致性

## 3C原则

上面提到的“”是软件开发需要更宏观的指导原则Correctness, Completeness, and Consistency

# 3C原则的具体实践

## 通过交付物进行落实，通过可视化的方式协助思考

### 需求分析

如何将纷乱的需求梳理清楚呢？要知道，很多非常复杂，比如统一额度项目的一个最高额担保需求，需要考虑不同业务场景、不同担保方式、不同产品类型。。。而在我们常见的需求分析文本中，一般都是对各种不同层次子需求场景（a，b，c，d，e）的罗列。一个负责任的评审员，如果要审阅需求分析文档的完备性，则需要自己在头脑中或纸笔上进行一种类似反编译的逆向工程：子场景a是整体需求中的一个场景，b和c构成了一个场景组合，而这个组合和d又是一个。听上去非常麻烦吧？这里为了简单，我让评审员直接发现了最深层场景是b和c，然后未经任何反复犹豫，直接推导出。试想一下评审时的真实情景，需求分析员按照投影讲解，子需求场景a在第1页，子需求场景b在第3页，c和d都在第4页，而子场景e则在第6页予以阐述。不借助纸笔的辅助，任何评审员都难以在头脑中储存、分析、归纳这些子需求场景，然后还能做出准确地判断（缺少场景）。

为此，我在此推可视化的逻辑拆分，即在具体的需求分析前，先加上一张需求逻辑拆分图。综合考虑多种图示。我发现使用类似结构化流程图（NS Diagram）的方式进行需求分析的拆分是非常清晰。

这里是结构化流程图示例：


下面是按照此流程图方式表示的需求场景：

![需求分析图]()

从图中，所有场景可以一眼所见。因此可以很容易。

### 详细设计

### 测试案例/测试报告

## 变更的管理

通过什么时机来实现

## 应用的效果

针对这些痛点，业界也有很多先驱大牛提出了很多应用系统开发所应遵循的若干原则。

软件开发相关评审需要做到这几性

应用程序开发中的完备性、准确性与一致性

参考文献

1. 刘晓龙. (2013). *基于CMMI的软件敏捷开发研究* (长春理工大学)

2. 李婷. (2007). 基于知识的软件质量改进技术研究与应用 (上海交通大学).

3. Boehm, B. W. (1984). Verifying and validating software requirements and design specifications. *IEEE software, 1*(1), 75.

4. Whitmire, S. A. (1997). *Object oriented design measurement.* John Wiley & Sons, Inc..