软考复习之软件工程篇

软件生命周期

问题定义：要示系统分析员与用户进行交流，弄清”用户需要计算机解决什么问题”然后提出关于“系统目标与范围的说明”，提交用户审查和确认

可行性研究：一方面在于把待开发的系统的目标以明确的语言描述出来，另一方面从经济、技术、法律等多方面进行可行性研究

需求分析：确定软件系统的功能需求和非功能需求；分析软件系统的数据要求；导出系统的逻辑模型；修正项目开发计划；如有必要可以开发一个原型系统

开发阶段：设计->实现->测试

维护：

改正性维护：在软件交付使用后，由于开发测试时的不彻底、不完全、必然会有一部分隐藏的错误被带到运行阶段，这些隐藏的错误在某些特定的使用环境下就会暴露。
适应性维护：是为适应环境的变化而修改软件的活动。
完善性维护：是根据用户在使用过程中提出的一些建设性意见而进行的维护活动。
预防性维护：是为了进一步改善软件系统的可维护性和可靠性，并为以后的改进奠定基础。

统一过程（UP）

初启阶段：生命周期目标

精华阶段：生命周期架构

构建阶段：初始动作功能

移交阶段：产品发布

CMM（软件能力成熟度模型）

初始级：软件工程管理制度缺乏，过程缺乏定义、混乱无序

可重复级：建立了基本的项目管理过程和实践来追踪项目费用、进度和功能特性

已定义级：所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件

已管理级：收集对软件过程和产品质量的详细度量，对软件过程和产品都有度量的理解与控制

优化级：过程的量化反馈和先进的新思想，新技术促使过程不断改进

CMMI（软件能力成熟度集成模型）

未完成级：表明过程域的一个或多个特定目标没有被满足

已执行级：过程通过转化可识别输入工作产品，产生可识别的输出工作产品，关注于过程域的特定目标的完成

已管理级：过程作为已管理的过程制度化，针对单个过程的实例的能力

已定义级：过程作为已定义的过程制度化，关注过程的组织级标准化和部署

量化管理级：过程作为定量管理的过程制度化

优化级：过程作为优化的过程制度化，表明过程得到很好的执行且持续得到改进

COCOMO

基本COCOMO模型：静态单变量模型，用于对整个软件系统进行估算

中级COCOMO模型：静态多变量模型，将软件系统模型分为系统和部件两个层次

详细COMO模型：将软件系统分为系统、子系统、模块三个层次，除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响

COCOMOII

应用组装模型：在软件工程的前期阶段使用，这时用户界面的原型开发、对软件和系统交互的考虑、性能的评估以及技术成熟度的评价是最重要的

早期设计阶段模型：在需求已经稳定并且基本的软件体系结构已经建立时使用

体系结构阶段模型：在软件的构造过程中使用

Putnam估算模型：动态多变量，它是假设在软件开发的整个生存周期中工作量有特定的分布

ISO/IEC 9126(软件质量模型)：

由3个层次组成：第一层是质量特性，第二层是质量子特性

特性含义：

其中各六个质量特性与二十七个质量子特性的关系如下表：

质量特性	功能性	可靠性	易使用性	效率	可维护性	可移植性
质量子特性	适合性	成熟性	易理解性	时间特性	易分析性	适应性
	准确性	容错性	易学性	资源特性	易改变性	易安装性
	互用性	易恢复性	易操作性		稳定性	一致性
	依从性				易测试性	易替换性

耦合

无直接耦合（最低耦合）：两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，它们之间不传递任何信息。因此，模块间的耦合性最弱，模块独立性最高

数据耦合：两个模块之间有调用关系，传递的是简单的数据值

标记耦合：两个模块之间传递的是数据结构，如果高级语言的数组名，记录名，文件名等这些名字即为标记，其实传递的是这个数据结构的地址

内容耦合（最高耦合）：当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部

控制耦合：模块间传递的信息不但有数据，还包括控制信息

外部耦合：模块间通过软件之外的环境联结(如I/O将模块耦合到特定的设备、格式、通信协议上)

公共耦合：通过一个公共数据环境相互作用的那些模块间的耦合

内聚

功能内聚：完成一个单一功能，各个部分协同工作，缺一不可(最高)

顺序内聚：处理元素相关，而且必须顺序执行

通信内聚：所有处理元素集中在一个数据结构的区域上

过程内聚：处理元素相关，而且必须按特定的次序执行

瞬时内聚：所包含的任务必须在同一时间间隔执行

逻辑内聚：完成逻辑上相关的一组任务

偶然内聚：完成一组没有关系或松散关系的任务（最低）

软件开发模型

瀑布模型

给出了软件生存周期中制定开发计划、需求分析、软件设计、编码、测试和维护等阶段以及各阶段的固定顺序，上一阶段完成后才能进入到下一阶段，整个过程如同瀑布流水。该模型为软件的开发和维护提供了一种有效的管理模式，但在大量的实践中暴露出其缺点，其中最为突出的是缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。这些问题有可能造成开发出的软件并不是用户真正需要的，并且这一点只有在开发过程完成后才能发现。所以瀑布模型适用于需求明确，且很少发生较大变化的项目。