《软件工程——面向对象和传统的方法》复习笔记

 

第一章 软件工程的范畴

引言

可以结合 软件工程导论第六版 –张海藩

1.软件工程概念：

软件工程是一门学科，目的是生产出没有错误的软件，按时并且在预算内交付，满足用户的需求。更进一步，当用户的需求改变时，软件必须易于修改。

2.软件工程范畴：

软件工程的范畴非常广。软件工程的某些方面可以归入数学或计算机科学；其他方面可以落入经济学、管理学或者心理学的范畴。我们可以从历史方面、经济方面、维护性方面、需求分析设计方面、小组编程方面等五个方面进行考察。

3.软件制品：

软件制品是软件产品的组成部分，如规格说明文档、代码模块或手册，它结合了属性和对属性的操作。

4.回归错误：

指对软件某处进行修改时，不小心在与该处明显没有关联的另一处造成新的错误。

1.1历史方面

软件危机：

顾名思义，软件危机指软件产品的质量低的通常不能接受，并且不能满足交付日期和预算限制。

1.2经济方面

2014年真题：

使用旧编码技术CTold的软件组织发现使用新的编码技术CTnew之后，编写代码的时间比旧编码技术少花1/10，因此花费也少1/10.通常大家都认为使用新技术CTnew比较恰当，对此你怎么看/p>

答案：实际上，虽然大家普遍认为速度快的技术应当成为技术的首选，但是从软件工程的经济观点却认为选择旧编码技术比较合适。原因如下：（1）新技术引入一个组织的花费十分高昂。使用CTnew技术后编码速度提高了10%，这与将新技术引入开发组织中的花费相比没有那么重要。（2）软件工程经济学建议保留旧编码技术的第二个重要原因是维护问题。从满足用户需求的角度来看，新旧技术的代码质量相当，但是信技术的使用导致代码很难维护，从整个产品的周期来看，使用新技术的耗费要大一些。

1.3维护性方面

传统范型的生命周期模型：

（1）需求阶段。在需求分析阶段，对概念进行研究和细化，提取客户的需求。

（2）分析（规格说明）阶段。分析客户需求并以规格说明文档的形式给出，同时阶段结束时，制定出计划，称为软件项目管理计划，详细描述期望的软件开发。

（3）设计阶段。第一步是结构设计、将作为整体的产品分解成各个模块，然后通过详细设计

对各个模块进行设计，最终得到两个设计文档。

（4）实现阶段。对各个部分独立地进行代码编写和测试（单元测试、集成测试），最后由客户对产品进行验收测试

（5）交付后维护。交付后维护包括在产品交付并安装到客户计算机中并通过验收测试后对产品所做的全部改动。它可以分为纠错性维护、增强性维护。纠错性维护主要是去掉残存错误，它不对规格说明文档做修改；增强性维护则是在对规格说明文档进行修改的同时，实现这些修改。有两种类型的增强性维护：完善性维护、适应性维护。

（6）退役。退役，发生在当产品推出服务的时候。当产品功能不再对客户组织有用的时候，就不再使用该产品。

1.4需求、分析和设计方面

无重点

1.5小组编程方面

无重点

其他：

 

为什么没有计划阶段/p>

为什么没有测试阶段/p>

答案：一个软件产品准备好交付给客户时才检查它实在是太晚了。在软件开发过程中，对产品进行测试伴随着整个产品的开发和维护之中。如果测试看作一个独立的阶段，那么会有不将测试连续贯穿于产品开发和维护的每个阶段的实际危险。开发人员需要不断进行测试保证软件产品尽可能在所有时候都没有差错。因此，不能将软件测试划分为一个独立的阶段。

2013年为什么没有文档阶段/p>

答案：（1）确保文档最新很重要的一个原因是软件行业中人员的流动性比较大

（2）如果前一阶段的文档不是完整、正确和最新的，几乎不可能执行下一阶段的步骤

（3）除非提供文档来说明对一个软件产品的期望，否则不可能测试该软件产品是否正确工作 （4）如果没有一套完整、正确的文档精确的描述产品的当前版本做些什么，维护几乎是不可能的。

因此，计划、测试和文档活动应当伴随着建造软件产品的所有其他活动进行。

 

第二章 软件生命周期模型

１.移动目标问题:　在软件正在开发的时候，需求改变了。

２.测试驱动开发（TDD）：一个程序员首先制定出任务的测试用例

３.结对编程：两个程序员在一台计算机前一起工作

４.重组：在建造产品的过程中设计在不断地调整

５.光盒：使用了多年的时间管理技术。为一项任务设定一段时间，小组成员在这段时间里尽可能好的做工作。

５.极限编程：

它是一些新的统称为敏捷过程地范型中的一个，是在迭代——递增模型的基础上发展起来的一种颇有争议的新的软件开发方法，能够快速响应需求变化。

特性：XP小组的计算机设在一个大房间的中心，大房间中有许多彼此连接的小隔间；一个客户代表一直与XP小组工作；没有一个人能够连续两周超时工作；没有规格说明，而是XP小组的所有成员一同完成需求、分析、设计、编码和测试；在建造出各种构件之前没有概要设计步骤。

6.软件的生命周期模型比较:—–2016

 

第三章 统一过程

1.软件过程

软件过程是生产软件的方式,包括方法学,生命周期模型,技术和工具,以及所有这些因素中最重要的部分:建造这些软件的人.

2.软件过程的改进:

软件过程的改进包括改进能力成熟度模型CMM,国际化组织指定的ISO9000系列标准以及ISO/IEC15504(后者是涉及40多个国家的一个国际软件改进的创见性建议).还有,要考虑的是,软件过程改进的代价和效益.

软件改进运动非常有意思的影响是:软件过程改进的尝试和软件工程的标准之间发生相互作用,这种软件工程标准化组织和软件改进之间的相互影响,真正促进了软件过程的改进.

3.统一过程和统一建模语言—-2015

统一过程,是一种自适应的方法学,是目前最主要的面向对象开发方法;统一建模语言,是用来模拟目标软件产品的模型工具,目前最常用的统一建模语言是UML.

4.统一过程核心工作流:—-2016

(1)需求流:目标是让开发组织确定客户的需求

(2)分析流:目标是分析和提取需求

(3)设计流:细化分析流的制品,直至材料处于程序员可实现的形式

(4)实现流:目标是用选择的实现语言实现目标软件产品

(5)测试流:始终与其他工作流并发执行,确保各阶段软件制品的正确性

 

5.统一过程的四个阶段

(1)开始阶段: 明确提出的软件产品经济上是否可行

(2)细化阶段: 细化最初的需求

(3)构建阶段: 产生软件产品的第一个可工作版本

(4)转换阶段: 确保客户的需求切实得到满足

6.可追踪性

需求制品所具有的属性,能够对分析制品,设计制品,实现制品中的每一项追踪到需求制品,确保它们是客户需求的真实反映.当SQA(软件质量保证)小组检查需求小组成员工作时也可以简化工作.

7.能力成熟度模型CMM —–2012

CMM,是一组用于改进软件过程的相关策略,它不考虑实际使用的软件生命周期模型.CMMI,能力成熟度模型集成,将5个现存的能力成熟度模型集成进一个模型,将来还可以加入另外的约束.

SW-CMM	用于软件的
P-CMM	用于人力资源管理的;
SE-CMM	用于系统工程的；
IPD－CMM	用于集成产品开发的；
SA-CMM	用于软件获取的

级别	关键过程区	措施
5.最优级	错误预防技术变更管理过程变更管理	持续改进软件过程
4.管理级	量化过程管理软件质量管理	为每个项目设计了质量目标和生产目标
3.定义级	集成软件管理软件项目工程组间协调对等检查	有充分的软件生产文档
2.可重复级	需求管理软件项目计划软件项目追踪和遗漏软件质量保证软件配置管理	使用了基本的软件项目管理措施
1.初始级	不可应用

 

第四章 软件小组

2012–2013–2014–2016–2017

1.民主小组

一个民主小组,是为了一个共同的事业而工作的团体,没有单独的领导,没有程序员视图提升到更高的职位,最重要的是小组的群体特征和相互尊重.

优点:对查找错误的积极态度,错误能够更快被发现,代码质量更高.

2.主程序员小组

编程秘书—-主程序员—–备程序员

程序员 程序员 程序员

 

主程序员: 既是一个成功的管理者,也是一个训练有素的程序员,完成结构化设计以及代码中的关键和复杂部分.其他的小组成员在主程序员的指导下进行具体的细节设计和编写代码.在程序员之间没有沟通的渠道,所有的接口问题都有主程序员解决,最后,主程序员审查其他小组成员的工作,因为主程序员个人要对每行代码负责.

备程序员: 应该在各方面和主程序员一样有能力,并且需要和主程序员一样深入了解这个项目.另外,为让主程序员集中精力进行结构化设计,备程序员应该进行黑盒测试的用例规化,并承担其他与设计过程独立的任务.

编程秘书: 不是一个兼职的办公助手,而是主程序员小组中一个精通专业,收入颇丰的核心人物.负责维护项目产品库,及项目的文档.程序员将他们的源程序交给编程秘书,有编程秘书负责将它们转换为及其可识别的形式,编译,链接,装载,运行,执行并测试用例.

程序员:只进行编程,其他的工作都交给编程秘书来做.

 

缺点:不仅高水平的程序员缺乏,成功的管理者同样缺乏,找到一个主程序员的几率不大.备程序员和编程秘书也很难找到.

3.现代编程小组

小组经理 小组领导

程序员 程序员 程序员

小组领导,负责小组活动中技术方面的事务;小组经理,负责所有非技术性的管理事务.

优点:进行分散决策,但同时拥有民主小组的优点,能够适用于大型项目的开发.

4.同步–稳定小组

微软公司使用的同步—稳定小组,但是使用同步—稳定生命周期模型和相关的小组组织极难像微软公司这样的成功,不具有普世作用.

5.敏捷过程小组

核心是结对编程.

6.开源编程小组

例如:linux,apache这种成功的开源项目,核心:一个出色的有号召力的关键人物.

一个开源项目的成功是因为目标产品的特性,组织者的个性以及核心小组成员的天资.一个公开源码的小组的成功与其小组组织方式基本上没有关系.

 

小组组织	优点	缺点
民主小组	由于积极地寻找错误,因而代码质量高,特别适用于解决难的问题	有经验的人反感新手的评价不能从外部强加
传统的主程序员小组	<<纽约时报>>项目的成功之处	不实用
修改的主程序员小组	有许多成功的范例	没有与<<纽约时报>>项目可比拟的成功范例
现代程序员小组	小组经理/小组领导结构避免对主程序员需求,可扩展,必要时支持分散决策	除非明确小组领导和小组经理之间的负责范围,否则容易产生问题
同步–稳定小组	鼓励创造性,确保大量开发者为共同目标工作	在微软公司之外还没有该方案的应用的实例
敏捷过程小组	程序员不测试自己的代码,如果一个程序员离开不会有损失,经验欠缺的程序员可以向其他人学习,代码具有小组所有权	还没有更多的实例证实它的成功
开源小组	少数项目非常成功	应用面窄,需由许多出色的有号召力的人领导,需要顶尖高手参与

 

注:实践中,目前多数小组都采用主程序员小组形式的某种变种.

第五章 软件过程工具

注:逐步求精成本效益分析法:两种贯穿于软件生命周期的基础理论性的软件工程技术

1.逐步求精法

逐步求精,是一个解决问题的技术,是许多软件工程技术的基础,可定义为”尽可能将细节的定义推研到最后,以便于集中精力在重要的事项上”的一种方法.逐步求精法潜在地支撑着许多规格说明技术,设计和实现技术,甚至测试和集成技术.

优点:帮助软件工程师集中精力于当前开发任务地相关方面,并忽略一些细节,尽管这些细节在总体方案中是必要的,但是也不能考虑.

2.成本—效益分析法

成本效益分析法,对比—估计的未来收益和预测的未来成本—-的一种方法.是确定客户是否应该进行业务计算机化的 基本技术,如果确定使用计算机处理业务,应用何种方式来比较各种可选方案的成本和收益.

优点:(1)通过假设的办法给无形的收益确定金钱数量的一个实际办法,假设与得到的收益估算值结合起来.

(2)在对数据进行审核时,可以根据数据中潜在的假设提出更好的假设,能产生更好的数据,无形收益可以计算的更加准确.

3.分治技术

分治技术:把整个问题分解为重要程度相同的子问题.

4.关注分离

5.软件度量

1.产品度量:测量产品本身的某个特性,例如:规模和可靠性.

2.过程度量:开发者使用这种度量推断软件开发过程的信息,典型例子:开发过程中检测错误的有效性.

6.CASE

CASE的最简形式是软件工具，只在软件生产的某一方面其帮助作用的软件产品．

分类：数据字典;一致性检查器;报表生成器;屏幕生成器;

7.软件版本

１.修订版：如果在一个制品中发现了错误之后，修复了该制品．经过适当的修改之后，该制品会有两个版本，老版本和将要替代老版本的新版本，那么新版本就称作修订版．

２.变种版：与专门为了替代前面版本的修订版不同，变种版是为共存而设计的．需要变种版的一个情况是产品要和多种不同操作系统或硬件接口，可能需要为每一种操作系统或者硬件接口组合生产多个制品的不同变种版．

8.配置控制

制品的三种形式：源代码－－－＞目标代码－－－＞可执行载入映像

１.配置：

某个完成的产品的给定版本所赖以建造的每个制品的特定版本称为该产品那个版本的配置．

注：配置控制工具可以自动管理多个变种版，但配置控制的作用不局限于多个变种版．配置控制工具还能处理小组开发和维护时出现的问题．

２.基准：

它是产品中所有制品的配置（版本集）．当要寻找错误时，维护程序员把所需的制品复制到自己的个人工作台中．在这个个人工作台中，程序员可以做任何修改，对其他程序员没有任何影响，因为修改的只是该程序员的个人副本，基准版还保持未动．

 

 

第六章 测试

1．故障:是观察到的软件产品的不正确的行为,它是差错的结果;

　错误:是不正确的结果的累积;

缺陷:是一个通用词汇,泛指差错.故障或者错误.

2．软件质量:产品满足规格说明的程度

3．软件质量保证(SQA)：原则是确保软件过程的质量，从而确保软件产品的质量．

４.走查：评审软件的方式,进行非执行测试:(测试软件但不运行测试用例),比审查的步骤少且不那么正式.

走查步骤: (1)准备 ;(2)小组对文档进行分析

5.审查的步骤:

(1)概要: 由负责文档的人提供被审查的的文档概要.

(2)准备: 处在准备中,参加者设法详细理解文档

(3)审查: 开始审查

(4)修订: 处于修订中,负责该文档的个人改正审查报告中列出的所有错误和问题.

(5)跟踪: 处于跟踪状态,主持者必须确认提出的每个事项都得到满意的解决,或者修改文档,或者澄清被误当成错误的事项.

6.测试的特性:

(1)正确性:产品在允许的条件下运行,能够满足输出规格说明,并与使用的计算资源无关

(2)实用性:在规格说明允许的条件下使用正确的产品时,满足用户需求的程度.

(3)可靠性:对产品故障的出现频率和严重性进行的测试.

—->平均故障时间:隔多久出现故障;

—->平均修复时间:修复故障的时间用了多久

(4)健壮性:运行条件的范围,有效输入带来不可接受的结果的可能性以及产品的输入无效时结果的可接受性.

(5)性能:根据时间或者空间要求,产品所受限制的程度.

第七章 从模块到对象

1.模块:

模块是词汇上邻接的程序语句序列,由边界元素限制范围,有一个聚合标识符.

2.模块内聚:

模块内部的交互程度;

3.模块耦合:

模块之间的交互程度;

4.内聚:

坏——————————————————–>好

(1)偶然内聚:一个模块执行完全不相关的操作;

(2)逻辑内聚:当一个模块进行一系列相关的操作,每个操作由调用模块来选择;

(3)时间内聚:一个模块执行一系列与时间有关的操作;

(4)过程内聚:一个模块执行一系列与产品要遵循的步骤顺序有关的操作;

(5)通信内聚:一个模块执行一系列与产品要遵循的步骤顺序有关的操作,并且所有操作对相同数据进行;

(6)功能内聚:只执行一个操作或只达到单一目标的模块;

(7)信息内聚:模块进行许多操作,每个都有各自的入口点,每个操作的代码相对独立,而且所有操作都对相同的数据结构完成;

第八章 可重用性和可移植性

第九章 计划和估算

来源：sunliee