软件开发过程模型及内聚耦合

1. 软件开发过程模型温故

软件开发过程是什么？

软件开发的开发生命周期，各个阶段实现软件的需求定义与分析、设 计、实现、测试、交付和维护

常用模型有哪些？

总体预览

0.jpg

• 瀑布模型
  

定义

给出了软件生存周期活动的固定顺序。

特征

接受上一阶段的结果作为本阶段的输入；对本阶段的工作进行评审；本阶段的结果作为输出，传递给下一阶段；

优点

需求阶段进行规约；
设计阶段规划系统结构；
每个阶段进行评审；
前一步作为下一步被认可的基线，并允许基线和配置早期接受控制；

缺点

要求用户能完整、正确和清晰的表达需求；由于需求的不稳定性，使设计、编码和测试阶段都可能发生延期；在开始的阶段，很难评估真正的进度状态，直到项目结束之前，都不能演示系统的能力；项目早期，过分强调基线和里程碑文档，建立一些用处不大的文档。

适用场景

需求明确的项目

示意图

1.png

• 演化模型

定义

有弹性的过程模型，由一些小的开发步组成，每一步经理需求分析、设计、实现和验证，产生软件产品的一个增量。通过迭代，完成最后软件产品的开发。针对用户的核心需求，开发核心系统，根据用户的反馈，实施活动的迭代。

特征

显式的将需求获取扩展到需求阶段。

优点

在需求不能予以规划时，可以使用这一演化模型；用户可以通过运行系统的实践，对需求进行改进； 同瀑布模型相比，需要更多用户/获取方的参与

缺点

不断探索，有较大的风险，需要有力的管理

适用场景

事先不能完整的定义需求的软件

示意图

2.png

• 增量模型

定义

需求可以分组，形成一个个的增量，并可形成一个结构，在此条件下，对每一个增量实施瀑布式开发。

特征

第一个增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。
迅速确定系统的基本需求，发现问题、消除误解、开发者与用户充分协调的一个步骤。

优点

瀑布模型的变体 ，第一个可交付版本的成本和时间较少，开发风险不大，减少用户需求的变更；
允许增量投资（非all in）

缺点

不控制需求变更，初始增量可能会造成后来增量的不稳定；若需求不稳定、不完整，那么一些增量可能需要重新开发，重新发布；管理发生的成本、进度和配置的复杂性，可能会超出组织的能力

适用场景

需求明确，且产品还可被适当分解为一些独立的、可交付的软件

示意图

3.jpg

• 喷泉模型

定义

面向对象技术开发

特征

迭代、无缝

优点

模糊了生命周期各阶段的区分，分析阶段得到的对象模型适用设计阶段和实现阶段；提高软件项目开发项目，节省开发时间

缺点

开发过程过分无序；面向对象范型本身要求经常对开发活动进行迭代或求精；开发过程需要大量的开发人员，不利于项目的管理。

适用场景

面向对象技术开发

示意图

4.png

• 螺旋模型

定义

瀑布模型跟演化模型的基础上，加入风险分析。将软件生命周期的活动分为四个可重复的阶段：规划、风险分析、开发和评估。比瀑布增建了管理活动和支持活动。

特征

引入风险分析阶段。迭代过程中实际只有一个迭代过程真正开发了可交付的软件。

优点

以小的分段来构建大型系统，使成本计算变得简单容易，客户始终参与每个阶段的开发，保证项目不偏离正确方向以及项目的可控性

缺点

建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距

适用场景

项目开发风险大。风险驱动，风险分析人员需要有经验且经过充分训练

示意图

5.png

• 敏捷开发模型
  

 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，强调程团队之间的紧密协作、面对面的沟通频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，更注重软件开发中人的作用。

 瀑布模型是预见性，严格遵循计划，并按照步骤顺序进行，步骤成果作为衡量进度的方法。敏捷开发过程中，软件一直处于可使用状态，项目细分为各个相关联子项目，故，每个阶段软件都是可见的，客户可以直观的体验并提出意见。瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。在瀑布式开发中，需求修改的时间越靠后，成本越大，所以需求分析人员的压力很大。敏捷开发迭代周期较短，容易应对需求变动。瀑布式开发重文档，敏捷开发轻文档，有助于整理思路，加快沟通和讨论，文档在每个产品版本开始之前会有产生，在每个迭代的过程中根据业务人员和市场的反馈也会有一些变更。

 相比迭代式的增量开发，均强调在较短的开发周期提交软件。基于Scrum的迭代增量开发一般会在一个比较长的一个迭代周期频率下不断交付，同时迭代中不允许有变化的需求，另项目的估算非常难，导致不容易承诺。敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。敏捷开发的原则之一是拥抱变化，敏捷开发方法属于适应性的开发方法，而非预设性。敏捷开发更适用于小型团队，并重视交互，有利于团队中知识的迅速传播。即使有人离开团队，另外的人也能完成相应的工作。

2. 内聚

是什么？

模块内部各成分之间相互关联程度的度量。

有哪些？

内聚度由弱到强

1. 逻辑内聚
   

只要机能在逻辑上分为同一类，不论各机能的本质是否有很大差异，就将这些机能放在同一个模块中。

eg: 私有库的功能模块

2. 时间内聚

如果一个模块完成的功能必须在同一时间执行，并无功能逻辑的成分合在一起.

eg: 异常捕捉上传：捕获异常，容错处理，日志上传，通知用户

3. 过程内聚

如果一个模块内部的处理成分相关，且这些处理成分必须以特定的次序执行

eg: 订单打印，数据存放、格式转换、顺次打印

4. 通信内聚

模块的所有成分都操作同一个数据集

eg: 典型的数据库

5. 顺序内聚

如果一个模块的各个处理成分和同一功能相关，且一个成分的输出作为下一个成分的输入

eg: NSOperationQueue顺次依赖

6. 功能内聚

模块的所有成分对于完成单一功能都是基本的

eg: 身份证号判断：字符串处理、省份判断、日期判断、尾号规则

3. 耦合

是什么？

对不同模块之间相互依赖程度的度量

有哪些？

耦合度从高到低

1. 内容耦合

一个模块直接修改另一个模块的数据

eg: 指针传值

2. 公共耦合

两个以上的模块共同引用一个全局数据项

eg: 数据中心：接受写入的数据，输出各端所需的数据；单例维护的变量更新

3. 外部耦合

一组模块都访问同一全局简单变量，而且不通过参数表传递该全局变量的信息，则称之为外部耦合

eg: 宏定义

4. 控制耦合

一个模块在界面上传递一个信息控制另一个模块，接收信号的模块的动作根据信号值进行调整

eg: 观察者模式有没有？

5. 标记耦合

两个模块至少有一个通过界面传递的公共参数

eg: 模块之间传值Object

6. 数据耦合

模块间通过参数传递基本类型的数据

eg: 模块A做一部分数据处理，模块B做一部分数据处理。比如A做读取，B做加工

7. 非直接耦合

模块之间没有信息传递

eg: 模块A实现输出字符串，模块B实现接收int数据，两者之间没有信息传递。这种情况下模块A和模块B就是非直接耦合

高内聚低耦合建议

耦合是影响软件复杂程度和设计质量的一个重要因素，为提高模块的独立性，应建立模块间尽可能松散的系统，在设计上我们应采用以下原则：若模块间必须存在耦合，应尽量使用数据耦合，少用控制耦合，慎用或有控制地使用公共耦合，并限制公共耦合的范围，尽量避免内容耦合。

内聚的话：简单化，模块化，接口化，标准化，不关注模块内部实现。呈现给使用者的就那么一丢丢。