dddd - 西安交通大学精品课程 :: 软件开发

Download Report

Transcript dddd - 西安交通大学精品课程 :: 软件开发

第1章 软件开发方
法
(二)软件工程
计算机教学实验中心
问题的提出






什么是软件工程?
为什么提出软件工程?
主要研究哪些问题?
软件工程的目标、原理
软件开发活动
……
上一页
下一页
停止放映
第2|83页
1.了解软件工程的基本概念、基本原则
2.理解软件工程的主要定义
3.理解软件过程及模型
4.了解软件工程方法学
上一页
下一页
停止放映
第3|83页
一、软件工程概述
什么是软件工程?
为什么要学习软件工程?
软件工程包括哪些内容?
……
上一页
下一页
停止放映
第4|83页
软件工程?
“软件工程是一种描述规范。”
Michael Jackson
上一页
下一页
停止放映
软件工程的定义

软件工程专家Boehm定义

IEEE给出的定义

教科书给出的定义
上一页
下一页
停止放映
第6|83页
软件工程专家Boehm定义

著名软件工程专家B.W.Boehm为软件工
程的定义是:
• 运用现代科学技术知识来设计并构造
计算机程序及为开发、运行和维护这
些程序所必需的相关文件资料。
上一页
下一页
停止放映
第7|83页
IEEE给出的定义

1983年IEEE给出的定义为:
• 以优质、高效、低成本为目标,研究
开发、运行和维护软件以及使之退役
的系统方法。

其中,“软件”的定义为:计算机程序、方法、
规则、相关的文档资料以及在计算机上运行时
所必需的数据。
上一页
下一页
停止放映
第8|83页
教科书给出的定义

教科书中定义为:
• 运用系统的、规范的和可定量
的方法来开发、运行和维护软
件。
上一页
下一页
停止放映
第9|83页
关于软件工程学

上一页
软件工程是一门交叉学科,涉及到计算机
科学、管理科学、工程学和数学。
• 软件工程的理论、方法、技术都是建立
在计算机科学的基础上;
• 它是用管理学的原理、方法进行软件生
产管理;
• 用工程学的观点进行费用估算、制定进
度和实施方案;
• 用数学方法建立软件可靠性模型以及分
析各种算法。
下一页
停止放映
第10|83页
为什么学习软件工程?
了解并掌握软件的开发步骤、
方法、准则。为了:
• 克服、解决“软件危机”
• 改进“软件生产”方法、工
具
• 提高软件的生产率
上一页
下一页
停止放映
软件工程的目标





开发生产尽可能多的软件产品;
提高软件的生产效率;
满足应用的功能需要和具有较好的软件性能;
能按时、按质完成软件开发任务;
降低软件开发成本。
上一页
下一页
停止放映
第12|83页
目标的实现是矛盾的



上一页
在实际开发过程中,企图让以上几个目标都
达到理想的程度是非常困难的。
例如,如果过于追求提高软件的性能,可能
造成开发出的软件对硬件有较大的依赖,从
而直接影响到软件的通用性和可移植性。
实际上软件工程就是要解决如何在用户要求
的功能、质量、成本、进度之间取得平衡,
才能真正满足应用的实际需要。
下一页
停止放映
第13|83页
软件工程具体目标
–
–
–
–
–
–
–
–
–
上一页
保护公众安全、健康和幸福
建立、健全开发软件产品的学科
识别新软件或修改现行软件的需求风险
避免开发失败的软件
鼓励寻求开发和采购软件产品的替代方法
促进软件生存期所有方面生产率的改进
通过不断更新软件,发现新的用途
便于开发具有“鲁棒性”的软件
通过对引起故障或有影响的元素的不断检测
以促进软件过程和产品的改进。
下一页
停止放映
第14|83页
软件工程的本质特征
1.
2.
3.
4.
5.
6.
7.
上一页
软件工程关注于大型程序的构造
软件工程的中心课题是控制复杂度
软件经常变化
开发软件的效率非常重要
和谐地合作是开发软件的关键
软件必须有效地支持它的用户
在软件工程领域中是由具有一种文化背
景的人替具有另一种文化背景的人创造
产品
下一页
停止放映
第15|83页
软件工程原理


自1968年提出“软件工程”的概念以来,
专家学者又陆续提出了100多条关于软件工
程的准则。
著名软件工程专家B.W.Boehm于1983年发表
的一篇论文中提出了软件工程的七条基本
原理。他认为这七条原理是确保软件产品
质量和开发效率的最小准则集合。
上一页
下一页
停止放映
第16|83页
软件工程七条基本原理







用分阶段的生命周期计划严格管理
坚持进行阶段评审
实行严格的产品控制
采用现代程序设计技术
结果应能清楚地审查
开发小组人员少而精
承认不断改进软件工程实践的必要性
上一页
下一页
停止放映
第17|83页
①用分阶段生命周期计划严格管理



上一页
下一页
据统计发现:不成功软件项目中半数是因计划
不周造成的。
在软件的整个生命周期中应该制定并严格执
行六类计划:项目概要、项目进度表、项目
控制、产品控制、验证及运行维护计划。
不同层次的管理人员必须严格按照计划各尽
其职地去管理软件开发与维护工作,绝不能
受客户或上级的影响而擅自背离预定计划。
停止放映
第18|83页
②坚持进行阶段评审


上一页
软件的质量保证工作不能等到编码阶段结束
之后再进行。这是因为:
• 大部分错误是在编码之前造成的(根据
Boehm统计,设计错误占软件错误的63%,
编码错误占37%)。
• 错误发现与改正得越晚,所付出的代价也
越高。
因此,在每个阶段进行严格的评审,尽早发
现并修正各个阶段中所犯的错误是一条必须
遵循的重要原则。
下一页
停止放映
第19|83页
示意图关于阶段评审作用
上一页
下一页
停止放映
第20|83页
③实行严格的产品控制


上一页

在软件开发过程中不应随意改变需求,但不能
禁止更改需求。当必须修改时,为了保持软件
各配置成分的一致性,必须实行严格的产品控
制。
一切有关修改软件的建议都必须按照严格的规
程进行评审,获准后才能实施修改。
绝对不能谁想修改就随意进行修改的行为。
下一页
停止放映
第21|83页
④采用现代程序设计技术


以前的结构化程序设计技术,如今的面向
对象程序设计技术都被实践证明是各个不
同历史阶段的优秀程序设计技术和方法。
采用先进的技术既可以提高软件开发的效
率,又可以提高软件维护的效率。
上一页
下一页
停止放映
第22|83页
⑤结果应能清楚地审查


软件产品是看不见、摸不着的逻辑产品,
软件开发人员的工作进展情况可见性差。
为了提高开发过程的可见性,应根据软件
开发项目中的目标完成期限,规定开发组
织的责任和产品标准,使得到的结果能够
清楚的审查。
上一页
下一页
停止放映
第23|83页
⑥开发小组人员少而精



开发小组成员的素质应该高,人员不宜过
多。人员素质和数量是影响产品质量和开
发效率的重要因素。
素质高的人开发效率比低的人高几倍甚至
几十倍,而错误则明显得少;
人数增加,管理难度也增加。
上一页
下一页
停止放映
第24|83页
⑦承认不断改进软件工程实践的必要性


要积极主动地采纳新的软件技术,要不断
总结经验;不能自以为是,固步自封,唯
我独好。
大千世界,错综复杂,只有不断学习,才
能不断进取,不断进步。
上一页
下一页
停止放映
第25|83页
软件开发活动




软件工程过程是由一系列软件工程的阶段任
务和活动组成。
1995年ISO将软件生存周期的活动和任务划分
为3个过程:
主要过程(需求、设计、构造、测试和维护)
支持过程(软件配置、软件工程管理、软件过程和
软件质量)

组织过程(基础设施建设、工具和方法、改进、培
训)
上一页
下一页
停止放映
第26|83页
主要过程

主要过程包括的软件开发活
动和任务是:
• 软件需求
• 软件设计
• 软件构造
• 软件测试
• 软件维护
上一页
下一页
停止放映
第27|83页
1、软件需求





上一页
下一页
任务:收集、分析、理解、确定用户的要求;
然后把用户的要求精确、完整地描述表达出来。
目的:要回答“要解决什么问题?”,
既系统”做什么?“。
分两步骤:
可行性研究、制定软件开发计划
结果:
可行性报告、软件计划、需求说明书
需求说明书是让用户理解:
“什么是他们真正需要的”。
停止放映
第28|83页
了解用户需求有关的问题

什么是需求?希望,功能,限制,必需品,任何必要的东西;

什么时候?

为什么?

来自哪里?

如何实现?使所有相关的人参与需求分析活动,通过有效的交
从确定方案开始;
用户的需求是开发需要的依据;
来自用户,工业标准,和实践经验;
流实现;

谁来做?
用户,工程管理人员,开发人员,维护人员。
上一页
下一页
停止放映
第29|83页
用户参与需求分析的重要性

根据Standish Group 1994年发表的一份研
究报告统计,延迟的、超出预算的、未完
成的工程的最普遍的原因是:
⑴ 缺少用户参与;
⑵ 不完备的需求规范;
⑶ 改变需求规范。
上一页
下一页
停止放映
第30|83页
需求分析的难点
⑴ 问题的复杂性。
涉及因素多而;如运行环境和系统功能等。
⑵ 交流障碍。
涉及不同类型人员较多,知识背景、角度、角色的不同;
⑶ 不完备性和不一致性。
用户对问题的陈述有矛盾、片面性等造成。
⑷ 需求易变性。
需求是变化的。
上一页
下一页
停止放映
第31|83页
需求工作的重要性





IBM公司有关研究的结果表明:
有效的需求管理可以降低开发成本。
通常改正需求错误需要付出改正其他错误
10倍以上的代价。
需求错误通常导致软件工程中全部错误的
25-40%。
改正很少的需求错误可以避免大量耗费在
返工上的成本和时间。
上一页
下一页
停止放映
第32|83页
需求活动
上一页
下一页
⑴ 识别问题
通过调研和收集资料,了解用户的确切需求,并将用
户提出的功能行为和特殊要求等用双方都能理解的表达
方式逐条列出。在整个分析期间要和用户充分协商。
⑵ 可行性研究
对于大型复杂问题,要对用户的要求及实现环境从技
术、经济和社会因素三个方面进行可行性研究,以确定
问题是否可解。
⑶ 分析建模
建立软件求解模型;信息、行为和表示。
⑷ 需求规格化及编写文档
需求规格说明书、初步用户使用手册等。
停止放映
第33|83页
2、软件设计






上一页
任务:给出实现系统的实施蓝图。
目的:要回答“如何解决该问题?”,
既系统“怎样做?”。
步骤:
概要设计:解决系统的模块划分、模块的层次
结构及数据库设计。
详细设计:解决每个摸块内部算法和数据结构。
结果:
系统设计说明书和模块功能说明书
下一页
停止放映
第34|83页
软件设计工作


软件设计要做的工作总的可以归结为:软件
系统结构(软件结构) 设计、数据设计、界
面设计和过程设计。
设计办法是功能分解,包括:
⑴ 采用某种设计方法,将一个复杂的系统
按功能划分成模块;
⑵ 确定每个模块的功能;
⑶ 确定模块之间的接口,即模块之间传递
的信息;
⑸ 评价模块结构的质量。
上一页
下一页
停止放映
第35|83页
软件设计准则
(1)软件结构准则;分层结构、便于控制;软件
结构的深度和宽度要适中;具有合理的扇出和扇
入数。
(2)模块化准则;分解复杂问题;
(3)模块独立性准则;应使模块之间和与外部环
境之间接口的复杂性尽量地减小;模块应具有低
耦合、高内聚;
(4)数据和过程描述清晰、可区分(表达式);
(5)成果可重复。
上一页
下一页
停止放映
第36|83页
软件设计方法
⑴ 面向数据流的设计方法;又进一步细分为
变换流和事务流方法;
⑵ 结构化设计方法;
⑶ 面向数据结构的设计方法;Jackson方法;
⑷ Warnier方法
⑸ 面向对象方法
上一页
下一页
停止放映
第37|83页
使用的开发工具
⑴ 层次图、HIPO图、结构图
⑵ 程序流程图、N-S图、问题分析图PAD
(Program Analysis Diagram)
⑶ 类语言、过程设计语言PDL(Procedural
Design Language)等
⑷ 统一建模语言UML(Unified Modeling
Language)
上一页
下一页
停止放映
第38|83页
3、软件构造





任务:根据设计说明书中每个模块的控制
流程编写出相应的源程序。
目的:写出高质量的代码和相应饿文档。
构造要注意使系统更易于使用和系统的可
重用性。
选择合适的开发工具及系统软件、数据库
软件、中间件等。制定编程规范。
结果:
源程序和文档
上一页
下一页
停止放映
第39|83页
编程风格
编程风格主要体现在如何描述源程序文件、
数据说明、输入输出等。
(1)源程序文件;变量名的命名、源程序中
的注解以及源程序的书写格式;
(2)数据说明;按不同类型数据的顺序以及
字典顺序说明、对数据结构加注释说明;
(3)语句构造;语句构造一般规则;
(4)输入输出语句;输入输出语句的规则。

上一页
下一页
停止放映
第40|83页
语句构造规则





不要为节省空间而把多个语句写在同一行;
尽量避免复杂的条件测试;
尽量减少对“非”条件的测试;
避免使用多层嵌套的循环和重复;
利用括号使表达式的运算顺序清晰直观。
上一页
下一页
停止放映
第41|83页
I/O语句规则








上一页
保持输入格式简单;
对所有输入数据都进行校验;
使用数据结束标记,不要要求用户指定数据的数目;
当程序设计语言对格式有严格要求时,应保持输入
格式的一致性;
检查输入项中重要组合的合法性;
给所有的输出数据加标记,并设计良好的输出报表;
用标记标明交互的输入请求,应规定可以使用的选
择值或边界值;
要根据用户的不同类型、特点和要求设计输入方案,
输入数据的格式要简单,应具有完备的出错检查和
出错恢复措施。
下一页
停止放映
第42|83页
程序设计语言
选用程序设计语言时要考虑它的三种特性:
(1)心理特性
对人-机通信质量有重要影响。例如,人们习惯使用
已熟悉的程序设计语言,由此产生的惰性影响人们学
习新语言。
(2)工程特性
它涉及到软件的可移植性、开发工具的可利用性等。
(3)技术特性
它对设计质量、人和整个软件工程有影响。例如,对
数据结构复杂性要求很高的系统,考虑选用C及C++等
语言;若对高性能和实时功能要求高,可考虑选用Ada
语言。

上一页
下一页
停止放映
第43|83页
4、软件测试





上一页
下一页
任务:检查、发现程序中的错误,提高系
统可靠性。
目的:保证系统的正确性、可靠性和可用
性。
回答:“该系统是否能实现规定的操
作?”。
方式:模块测试、组装测试 、确认测试和
系统测试
结果:
测试报告和软件修改报告等。
停止放映
第44|83页
测试包括
⑴ 单元测试。 对一个模块的测试,一般以白盒法
测试为主,多个模块可以并行进行。
⑵ 集成测试。最终将本项目所有模块集成在一起
测试,交出完整程序产品。
⑶ 确认测试。以用户为主的测试。证实系统能否
正确地实现其功能。
⑷ 系统测试。软件只是整个应用系统的一部分。
最后要集成为一个整体,包括硬件、软件以及相
关的其它设备。此时的测试称系统测试。
上一页
下一页
停止放映
第45|83页
α测试与β测试


阿尔法测试:
对于商品软件在研制方有客户(订货方)参与
的确认测试叫阿尔法测试。
贝塔测试:
指在若干客户场地由客户组织,最终用户参
与的测试,此时所有文档均予冻结,作为本
软件版本的基线。对于新软件,改版则为里
程碑。
上一页
下一页
停止放映
第46|83页
设计测试用例应考虑的问题
上一页
下一页
停止放映
① 界面:内界面主要检查参数个数及类型匹配。
外界面主要检查I/O文件、数据格式、类型匹配。
② 模块的数据结构:类型是否不正确或不一致?
初始化、缺省值使用情况;变量名拼错;上、
下界溢出等数据异常,测试能否正确处理等。
③ 边界条件:保证在边界值的情况下模块依然可
以正确操作,值出界时要有正确反应。
④ 独立路径:保证至少所有语句都要执行一次,
每个条件或子条件都执行一次更好。
⑤ 错误处理路径:不管程序有无异常处理都要察
看出错处理路径。特别要考察是否死机。
第47|83页
程序调试


调试是在测试发现错误之后排除错误的过
程。调试过程会发生两种结果:
• 找到原因并把问题排除;
• 没找到问题的原因。
调试是软件开发过程中最艰苦的脑力劳动。
在调试过程中遇到的错误有所不同,错误
的后果越严重,查找错误原因的压力也越
大。通常,压力会导致软件开发人员在改
正一个错误的同时可能引入更多的错误。
上一页
下一页
停止放映
第48|83页
调试技术
① 输出存储器内容;特点是效率低、难定位、
输出的是静止状态的程序内容。
② 加打印语句;特点是显示的是程序的动态
信息,但大量的输出,时间慢,可能引出
新的问题。
③ 用调试工具;特点是动态调试,可自动执
行,是目前广泛采用的一种调试技术。
上一页
下一页
停止放映
第49|83页
调试策略
上一页
① 试探法。大概分析、估计错误的位置。
② 回溯法。确定最先出现“症状”的地方,
然后沿程序的控制流程往回追踪源程序,直
到找出错误源为止。
③ 对分查找法。若已知程序中若干个关键点
的正确值,然后用调试工具在关键点附近处
输入正确值;若输出正确,则故障在前半部
分;否则,再查后半部分。
④ 归纳法。从线索出发,通过分析线索之间
的关系而找出故障。主要步骤为:收集有关
数据,组织数据,导出假设,证明假设。
下一页
停止放映
第50|83页
调试的启发性原则

这部分内容大多是心理学的问题:
• 要思考,不要盲目地修改程序,至使错
误越改越多;
• 如陷入困境,放到第2天去解决;
• 陷入绝境后,要与别人交谈你的问题,
或许对你有所启发;
• 避免用试验法。不要在问题没有搞清楚
之前,就改动程序,这样对找出错误不
利,程序越改越乱,以致于面目全非。
上一页
下一页
停止放映
第51|83页
5、软件维护




任务:改正软件系统在使用过程中发现
的隐含错误,扩充在使用过程中新的功
能要求。
目的:维护软件系统的正常运行。
回答:系统是否满足用户的应用要求。
阶段结果:
软件系统的问题报告和软件修改报告。
上一页
下一页
停止放映
第52|83页
软件维护的原因
⑴ 软件的原有功能和性能可能不再适应用户
的要求;
⑵ 软件的工作环境改变了(例如,增加了新
的外部设备),软件也要做相应的变更;
⑶ 软件运行中发现错误,需要修改。
上一页
下一页
停止放映
第53|83页
维护活动分类
⑴ 校正性维护:指为了识别和纠正错误,修改软件性
能上的缺陷,进行确定和修改错误的过程。占整个维护
工作的15%。
⑵ 适应性维护:为了使本软件适应硬件和软件的变化
而修改软件的过程称为适应性维护。占整个维护活动的
25%。
⑶ 完善性维护:增加软件功能、增强软件性能、提高
运行效率而进行的维护活动称为完善性维护。占整个维
护工作的55%。
⑷ 预防性维护:为了提高软件的可维护性和可靠性而
上一页
下一页
对软件进行的修改称为预防性维护。只占整个维护活动
的5%。
停止放映
第54|83页
维护活动的特点
⑴ 非结构化维护和结构化维护。主要区别是开
发过程是否用软件工程方法,若各阶段均有相
应的文档记录,系统则容易维护。采用结构化
维护可以大大提高软件维护效率。
⑵ 软件维护的困难性。是由于软件需求分析和
开发方法的缺陷。
上一页
⑶ 软件维护的费用在总费用中的比重不断增加,
已经上升到了70%~80%或更多,我们看到的软
件不断升级就是维护的具体体现。
下一页
停止放映
第55|83页
维护活动流程
建立维护机构,组织维护活动:
⑴ 制定维护申请报告;
⑵ 审查维护申请报告并批准;
⑶ 进行维护并做详细记录;
⑷ 复审。

上一页
下一页
停止放映
第56|83页
软件的可维护性
软件可维护性是指维护人员理解、修改软件的难
易程度。
⑴ 可维护性因素
软件的可维护性因素主要包括:可理解性、可测试
性、可修改性、可靠性和可使用性。
⑵ 提高可维护性的方法
提高软件的可维护性必须从软件生存周期各个阶段
的工作入手,每个阶段都把可维护性贯彻到阶段
的开发活动过程中,并按规范对阶段工作进行评
估,以保证个阶段的工作按质按量完成。
⑶ 文档
文档是影响软件可维护性的决定性因素。文档分为
用户文档和系统文档两类。
第57|83页

上一页
下一页
停止放映
支持过程

支持过程包括的软件开发活
动和任务是:
• 软件配置管理
• 软件工程管理
• 软件过程
• 软件质量
上一页
下一页
停止放映
第58|83页
软件配置管理


上一页
下一页
软件修改后会发生什么呢?
• 同步更新——当两个或两个以上的角色各自
工作在同一产物上时,最后一个修改者会破
坏前者的工作。
• 通知不达——当被若干开发者共享的产品中
的问题被解决时,修改未被通知到一些开发
者。
• 多个版本——软件修改与文档不一致。
• 新版本公布的管理和监控。
配置和变更管理提供了准则管理演化系统中的
多个变体,跟踪给定软件创建过程中的版本。
停止放映
第59|83页
软件工程管理
软件工程管理是一门艺术。其主要活动有:管理
项目的框架、计划配备执行监控项目的实践准则、
管理风险的框架。
 项目管理是过程管理的主要体现:
(1)建立与客户的通信;
(2)作计划,定义资源、时限、落实到开发组;
(3)风险分析,评估所采用的技术和管理带来的风
险;
(4)工程,即软件分析与设计;
(5)构造和发布,即编码、测试、交付、安装、文
档、培训;
(6)客户评审,获得客户的反馈。

上一页
下一页
停止放映
第60|83页
软件过程



上一页
软件过程是生产软件的一系列可预测、可控制活动的步骤,
即把用户要求转化为软件产品的一系列有序开发活动的集
合。
软件过程给出了软件开发所要遵循的基本路线,它的重要
性在于它使一组开发活动具有了一致性和结构,从而使在
软件开发过程中人们能够使用自己熟悉的技术和工具设计
和开发软件,并能保持软件产品和服务在一定程度上的一
致性和质量。过程的重要性还在于它能够获取经验并将这
些经验传授给别人。
但是,Wasserman在1996年提出:“应用类型和组织文化
之间的巨大差别使得过程本身规范化是不可能的”。相反,
他建议不同类型的软件,使用不同的过程。
下一页
停止放映
第61|83页
软件质量





上一页
下一页
停止放映

软件质量保证SQA活动,贯穿于软件过程始终。
开发单位成立SQA小组负责全面质量管理。在开
发项目计划时就要做出SQA计划。其工作:
各种测试 测试软件是否满足规格说明要求。
各种评审 为多种人员参与的讨论会,以规格说
明或各种标准,规范为准评价各项软件工作。
各种审计 以职能人员为主审,审查软件过程产
物是否符合标准或规格说明书。
报告和记录 所有测试、评审、审计都要详细
记录并写出报告,报告和记录均要整理、归档。
以上活动均应在软件质量保证计划中列出。
第62|83页
组织过程

组织过程包括的软件开发
活动和任务是:
• 基础设施建设
• 软件工程工具和方法
• 改进
• 培训
上一页
下一页
停止放映
第63|83页
基础设施建设




上一页
建立、维护和管理用于软件开发过程中其他活
动的硬件和软件的基础设施;
建立、维护和管理用于软件开发过程中其他活
动的软件开发工具和方法;
建立、维护和管理用于软件开发过程中其他活
动的开发技术 、技术规范和标准;
建立、维护和管理用于软件开发过程中其他活
动的其他基础设施。
下一页
停止放映
第64|83页
软件工程工具和方法




上一页
下一页
停止放映
程序的开发、运行都是在支持软件的基础上作出
的。支持软件的总和称之为软件开发环境 。
早期的环境只有最必要的软件工具;例如语言的
编译器、连接器、加载和运行工具、排错、信息
显示及编辑工具。称为最小环境工具集。
70年代中期, 软件工程师迫于软件危机的压力,
提出了计算机辅助软件工程(CASE)的设想, 开发
出一系列工具尽量使软件过程的各项活动自动化、
半自动化。
相应问题:工具日益增多, 给使用者带来不便,例
如,各工具的使用方法、格式、参数等差异的问
题。这就在客观上产生了对于集成的CASE工具的
需求。
第65|83页
计算机辅助软件工程CASE






上一页
下一页

人们期望,借助CASE工具,有朝一日软件开发
人员可以像在自动流水线上生产计算机那样生
产软件。
CASE 工具具有如下特征:
支持专用的个人计算环境;
使用图形功能对软件系统进行说明并建立文档;
将生命周期各阶段的工作连接在一起;
收集和连接软件系统从最初的软件需求到软件
维护各个环节的所有信息;
用人工智能实现软件开发和维护工作的自动化。
停止放映
第66|83页
软件工程工具









上一页
下一页
停止放映


信息工程工具
过程模型和管理工具
项目计划工具
风险分析工具
项目管理工具
需求追踪工具
度量和管理工具
文档工具
系统软件工具
质量保证工具
数据库管理工具
第67|83页
改进

软件开发技术会随着软件开发工程实践活动
的不断开展而发展。改进活动就负有总结经
验、不断改进开发技术和开发方法的职能。
改进活动的基本内容有:
• 对整个软件生存过程进行评估;
• 对现行过程进行度量;
• 对现行过程进行改进。
上一页
下一页
停止放映
第68|83页
培训


为了使用户能够尽快掌握使用软件系
统,要对用户进行培训。
活动包括:
• 制定培训计划。
• 编写培训教材。
• 实施培训计划。
上一页
下一页
停止放映
第69|83页
软件工程方法学



上一页
通常把在软件生命周期全过程中使用的一整套技
术方法的集合称为方法学,也称为范型。
软件工程方法学包括3个要素:方法、工具和过
程。
这三者之间是相互联系的。方法是完成软件开发
过程中各项任务的技术方法,回答“怎样做”的
问题;工具是为运用方法而提供的自动或半自动
的软件支撑环境;过程是为了获得高质量的软件
所需完成的一系列任务的框架,它规定了完成各
项任务的工作步骤。
下一页
停止放映
第70|83页
软件工程的基本问题

软件工程开发技术的角度
软件工程开发技术
软件工程的三目标
工具
质量
过程
解决
成本
方法
思想与原则
进度
上一页
下一页
停止放映
第71|83页
传统方法学


传统方法学是建立在软件生存周期方法学
和结构化方法学的基础上。因此,具有明
显的那个时代的特点。70年代,计算机技
术水平不高,开发工具少而且性能差。
对于大型复杂问题的求解,人们不得不采
用“将大化小“、“将难化简”,最后
“分而治之”的开发策略。
上一页
下一页
停止放映
第72|83页
结构化方法概述

结构化方法是由结构化分析方法
SA、结构化设计方法SD和结构化
程序设计方法SP组成的,该方法
的核心是基于功能分解的模块化
层次结构方法。
上一页
下一页
停止放映
第73|83页
结构化分析SA
• 自顶向下
• 逐步求精
• 模块化设计

结构化分析的要点是:将大问题化为小问
题,找出关键点、难点,定量描述;核心
是:分解;手段是:模块化。
上一页
下一页
停止放映
第74|83页
结构化设计SD
• 模块化结构
• 模块独立性

结构化设计方法的要点是:将系统设计成
由相对独立、单一功能的模块组成的软件
结构。模块独立性用模块内的内聚性和模
块间的耦合性来衡量。
上一页
下一页
停止放映
第75|83页
结构化程序设计SP

• 自顶向下逐步加细;
• 模块只有一个入口,一个出口;
• 三种基本结构;
• 开发支持库;
• 主程序员组
结构化程序设计方法SP的要点是用三种基
本结构的语句编写只有一个入口和一个出
口的模块程序,尽可能地采用重用程序,
开发组织形式为主程序员组。
上一页
下一页
停止放映
第76|83页
传统方法学的缺点







过分强调了分阶段实施,使得开发过程各个
阶段之间存在严重的顺序性和依赖性;
很难将一个复杂的问题化简、分解;
设计方法存在很大的主观随意性;
基于功能分解的系统结构难于修改和扩充;
思维成果的可重用性很差;
数据和对数据的处理是分离的;
忽视了人在软件开发过程中的地位和作用。
上一页
下一页
停止放映
第77|83页
现代方法学





现代方法学是在传统方法学的基础上,为了强调人在软
件开发中的作用,同时为了适应软件新技术的发展趋势
而提出的。其基本要点是:
⑴ 软件开发过程是以人为主,充分利用软件开发方法及
软件开发工具;
⑵ 开发人员的组织管理对软件开发成功与否至关重要;
⑶ 基于软件组件的软件开发技术。
⑷ 由于软件组件是标准化设计、成品化生产的,极易构
造使用,从而大大简化了设计、编程、测试各个环节的
工作量,提高了生产效率和产品质量。
上一页
下一页
停止放映
第78|83页
现代方法学中生命周期





在现代方法学中软件生命周
期的阶段划分:
系统分析
系统构造
系统测试
软件组件
上一页
下一页
停止放映
第79|83页
系统开发人员的组织管理
一个复杂的系统开发过程,涉及到众多的以
人为主的各种开发活动,通过这些活动的有
机配合与协调才能保证系统开发的成功。因
此,系统开发人员的组织管理是现代软件工
程中的重要方面。组织管理方法有以下几个
要点:
① 明确系统开发人员与用户之间的责任与义
务;
② 明确各类开发人员的主要工作及责任;
③ 制定或选择工程开发规范。

上一页
下一页
停止放映
第80|83页
面向对象方法学


上一页
下一页
停止放映
由于传统方法学无法从根本上克服“软件危机”
带来的灾难性影响,业界人士不得不研究、探索
新的方法。而当面向对象(OO)思想和方法一经
出现,就引起计算机业界的极大关注,使得对这
种新方法的研究和应用得到迅速发展。
OO方法是人类借助计算机认识和模拟客观世界的
一种方法。它将客观世界看成是由许多不同种类
的对象构成。通过分析、研究客观世界中的实体、
实体的属性及其相互关系,从中抽象出求解问题
的对象,最后求解这些对象,得到问题的解。这
一过程更接近人类认识问题、解决问题的思维方
式,使得计算机求解的对象与客观事物具有一一
对应的关系。
第81|83页
什么是OO方法
现在比较一致的看法是:OO方法是基于“对象、类、继承
性、消息机制、多态性等技术特征”的构造软件系统的开
发方法。OO方法具有以下几个要点:
⑴ 把对象作为一种统一的软件构件,它将数据及在数据上的
操作行为融合为一体。OO方法处理的基本元素是对象;程
序是由对象组成的,复杂的对象是由简单的对象组合而形
成的。OO方法学用对象分解代替了传统方法的功能分解。
⑵ 把所有对象都用类来表示;每个类都有自己的属性和方法,
具体的对象只是类中的一个实例。
⑶ 类具有层次结构,子类可以继承父类的特性和方法(继承
性);
⑷ 对象之间只能通过传递消息构成相互之间的联系(消息机
制)。

上一页
下一页
停止放映
第82|83页
面向对象分析(OOA)








上一页
下一页

OOA强调根据问题域中客观存在的实体创建OOA模型中的对
象。具体表现在:
用对象的属性和服务分别描述事物的静态特征和行为;
问题域中有哪些值得考虑的事物,就在OOA模型中创建哪
些对象;
对象及其服务的命名尽量与客观实体一致。
OOA模型应尽量保留问题域中实体之间关系的原貌。包括:
把具有相同属性和相同服务的对象归结为类;
用一般-特殊结构(分类结构)描述一般类与特殊类之间
的关系(继承关系);
用整体-部分结构(组装结构)描述实体间的组成关系;
用实例连接和消息连接表示实体之间的静态联系和动态联
系。
停止放映
第83|83页
面向对象设计(OOD)
OOD包括两方面的工作:
① 把OOA模型直接搬到OOD中来,作为OOD的一个部分;
②针对具体实现中的人机界面、数据存储、任务管理等因
素补充一些与实现有关的内容,这些内容与OOA采用相
同的表示法和模型结构。
 在分析和设计阶段采用一致的表示法是OO方法与传统方
法重要的区别之一。这使得从OOA到OOD不存在转换,只
需进行局部的修改或调整,并增加几个与实现有关的独
立部分即可。因此OOA与OOD之间不存在传统方法中分析
与设计之间的鸿沟,可以自然地实现无缝衔接,从而大
大降低了从OOA过渡到OOD的难度、工作量和出错率。

上一页
下一页
停止放映
第84|83页
面向对象编程(OOP)


上一页
OOP也称为面向对象的实现。在OOA和OOD理论
出现之前,程序员要写一个好的OO程序,首
先要学会运用OO方法来认识问题域,因此把
OOP看作比较高深的技术。
现在,在“OOA→OOD→OOP”的设计模式中,
OOP的分工相对简单多了;认识问题域与设计
系统元素的工作在OOA和OOD阶段已经完成,
OOP的工作就是用一种OO程序设计语言把OOD
模型中的每个元素描述出来而已。
下一页
停止放映
第85|83页
面向对象测试(OOT)




OOT的主要特点是:
利用对象的封装性。测试以类为基本单位进行。测
试只需针对类定义范围内的属性和服务、以及有限
的对外接口所涉及到的部分即可。
利用对象的继承性。若父类已被测试或父类是可重
用构件,则对子类的测试重点只是那些新定义的属
性和服务。
对于用OOA、OOD和OOP实现的软件,OOT通过捕捉
OOA、OOD模型信息,检查程序与模型不匹配的错误,
可以极大地提高测试效率。这一点是传统程序设计
方法是无法达到的。
上一页
下一页
停止放映
第86|83页
面向对象的软件维护



上一页
OO方法为改进软件维护提供了有效的途径。主
要表现在:
因为OO方法在各个阶段表示的一致性,使得实
现的程序与问题域是一致的,便于理解和阅读,
也为纠错和功能扩充提供了便利。
系统维护过程中的老大难问题是系统功能的变
化并由此产生的影响。在OO方法中,由于对象
的封装性,使一个对象的修改对其它对象的影
响很小,从而可以减少错误传播所产生的“波
动效应”,使得用OO方法开发的软件易维护。
下一页
停止放映
第87|83页
OO方法的主要优点
上一页
下一页
⑴ 与人类习惯的思维方式一致
OO方法顺应人认识过程的这个规律,从寻找要求解的
对象“是什么?”开始,认识事物及其本质规律,主
观随意性受到限制。
⑵ 稳定性好
传统方法以“过程为中心”,以功能分解为基本方法。
当功能需求发生变化时,将引起对软件整体结构的修
改,导致系统不稳定。OO方法以“对象为中心”,采
用对象技术。不管需求如何变化,其内在规律不变,
不会引起软件结构的整体变化,所以系统的稳定性影
响不大。
⑶ 可重用性好
⑷ 可维护性好
停止放映
第88|83页
软件工程模型
1
2
3
4
5
6
瀑布模型
增量模型
螺旋模型
喷泉模型
基于知识的模型
面向对象模型
上一页
下一页
停止放映
第89|83页
①瀑布模型

瀑布模型是上个世纪80年代广泛应
用的一种模型,至今仍然是最广泛
使用的过程模型之一。在应用程的
应用模式也称为软件生存周期模式
(B.W.Boehm提出的该模型)。
上一页
下一页
停止放映
第90|83页
瀑布模型示意图
用户要求
分析报告
U
A 需求分析7%
M
系统设计报告
A
T 系统设计6%
M
M 软件编程7%
P
U
T
P
A 系统分析员
M 项目管理员
P 程序员
T 高级程序员
U 用户
源程序
软件测试13%
测试报告
U
更改要求
A 软件维护67%
M
P
上一页
下一页
停止放映
第91|83页
瀑布模型的特点
1.
2.
3.
4.
上一页
下一页
停止放映
瀑布模型具有顺序性和依赖性,即后一阶段
工作必须在前一阶段工作完成后才能开始。
推迟实现的观点;把逻辑设计与物理设计清
楚地划分开,尽可能推迟物理模型的实现,
这是瀑布模型的重要指导思想。
质量保证的观点。瀑布模型强调的是优质,
即每一步都循序渐进,及早消除隐患,从
而保证软件质量。
致命缺点是只有做出精确的需求分析,才
能取得预期的结果。由于各种客观、主观
的原因,需求分析往往不很精确,常常给
日后的开发带来隐患。
第92|83页
②原型模型—样品模型



上一页
下一页
停止放映
原型模型的主要思想:
先借用已有系统作为原型模型,通过“样品”不断改
进,使得最后的产品就是用户所需要的。
原形模型的特点:
⑴开发人员和用户在“原型”上达成一致。这样可以
减少设计中的错误和开发中的风险,以及对用户培训
的时间,而提高了系统的实用、正确性以及用户的满
意程度。
⑵缩短开发周期,加快工程进度。
⑶降低成本。
原型模型的缺点:
当告诉用户,还必须重新生产该产品时,用户是很难
接受的。这往往给工程继续开展带来不利因素。
第93|83页
快速原型模型
原型
样品
模型
分析
设计
修改
与
改进
编程
在系统分析与
设计中,采用
交互式,反复
修改与不断改
进的方式进行。
测试
使用
上一页
下一页
停止放映
还有的把原型模式嵌套在瀑布模型中运用。
第94|83页
③增量模型




上一页
下一页

也称渐增模型。它把软件产品作为一系列的增
量构件来设计、编码、集成和测试。
增量模型是一种非整体开发的模型。软件在该
模型中是“逐渐”开发出来的,开发出一部分,
向用户展示一部分,让用户及早看到部分软件,
及早发现问题。
或者先开发一个“原型”软件,完成部分主要
功能,展示给用户征求意见,然后逐步完善,
最终后的满意的软件产品。
该模型具有较大的灵活性,适合于软件需求不
明确、设计方案有一定风险的软件项目。
缺点:要求软件具有开放的结构是这种模型固
有的困难。
停止放映
第95|83页
④螺旋模型

将工程划分为4个主要活动:制定计划、风险分
析、实现工程和用户评价。4个活动螺旋式地重
复执行,直到最终得到用户认可的产品。
• 制定计划 :确定软件目标,选定实施方案,
弄清项目开发限制条件。
• 风险分析:分析可选方案,分析识别风险,研
究解决化解风险的办法。
• 实现工程:实施软件产品的开发。
• 用户评价:对当前工作结果进行评价,提出
上一页
下一页
停止放映

改进产品的建议。
螺旋模型的缺点:很难让用户确信这种演化方法
的结果是可以控制的。
第96|83页
螺旋模型的缺陷
建立在风险分析的基础上


需要有一个非常有经验的小组来准确地分析
和检测风险
绝对依赖人的素质 (本身就是冒险!)
不适合新手


上一页
开发中的每一层都很有弹性,并不是很明确
的界限
每一层的目标和计划都是由小组本身来制定。
要求有经验的人来组成。
下一页
停止放映
第97|83页
⑤智能模型


上一页
下一页
也称基于知识的软件开发模型,它与
专家系统结合在一起。
该模型在实施过程中要建立知识库,
将模型本身、软件工程知识与特定领
域的知识分别存入数据库。以软件工
程知识为基础的生成规则构成的专家
系统与含应用领域知识规则的其他专
家系统相结合,构成这一应用领域的
软件开发系统。
停止放映
第98|83页
⑥面向对象的开发模型
上一页
下一页
其主导思想是:在整个软件开发过程中将面
向对象技术贯穿于整个生存周期。当然,还
要结合传统开发模式中好的、已被无数成功
开发活动证明是可行的经验和技术。
具备3个主要的阶段:
 分析: 模拟 “关键系统”来表示用户要求,
并设计独立实现的“关键类”。
 设计: 限制并优化关键类,在特定的环境
中实现,得到另外的类。
 实现: 定义类的接口和实现方法,然后编
写并统一测试所有的类。
停止放映
第99|83页
面向对象开发的缺陷
• 还不成熟
几个有影响的面向对象开发的过程对不同的
步骤意见不一。
在大的项目上经验不多,在小项目上尚可。
在每个过程步上细节少,新手难于理解。
• 晚期的测试
开发过程没有中间的版本,几乎所有的测试
都留在最后的实现阶段。
• 结构上的死板
上一页
下一页
停止放映
假设所有的结构设计都定义好在要求阶段,
对于设计和实现阶段基本上没有结构上变化
第100|83页
的余地。.
开发流程模型的比较
上一页
下一页
停止放映
线性有序模型(瀑布模型)
结构性好
基于原型模型
需要在短时间内建立原型系统
在系统要求模糊或者未知时较有效
重复使用模型
假如条件适合,是开发速度最快的模型
积累模型
容许早期测试和用户反馈
螺旋模型
适于大规模系统
第101|83页
软件工程前景
软件学科的核心问题是“如何提高软件的生产效
率和运行效率” 。
 在对提高运行效率问题的研究上,人们已经探索
出一条有效的途径并取得重大成果。表现在:
⑴ 集成电路技术、计算机体系结构技术和计算机网
络技术的发展,为软件系统的运行提供了日益强
大的硬件基础设施,极大地提高了软件运行的效
率。在此方面目前的研究热点是高性能计算和高
性能网络。
⑵ 软件学科的并行计算和分布计算理论的新进展也
在很大程度上解决了提高运行效率的问题。近十
年来研究的热点是系统软件技术和中间件技术。

上一页
下一页
停止放映
第102|83页
提高软件生产效率的方法





上一页
下一页
停止放映
研究途径分分理论方法和技术方法:
技术方法主要是以美国软件产业为代表。它以“软件工厂”
为目标来提高软件的生产效率。主要办法是提高软件的可
重用性。
面向对象方法是解决软件危机,提高软件开发效率和质量
的有效途径,是一种社会化的方法,有助于软件工程化、
工厂化生产的实现。这种方法在近二十年来处于主导地位,
也使美国的软件业在全球领先。
理论方法是以西欧的学术界为首的形式化方法,即纯自动
化方法。它以精确的语义描述软件系统,在此基础上进行
自动生成、转化及验证。此方法提出来很早,但难度很大,
大部分处于原型讨论,离实用还有很大差距。
这两种方法的优、缺点很明显。技术的方法实用性很强,
得到了产业界的大力拥护。但是随着软件的规模越来越大,
复杂度越来越高,很难保证软件的可靠性和软件的开发效
率。理论的方法则实用性差,很难投入实际应用。 第103|83页
软件工程主要技术发展趋势
1.基于软件复用库的软件重用
2 .面向对象技术
3 .针对几种中间件平台开发组件交互的标
准和基于组件的软件开发
上一页
下一页
停止放映
第104|83页
欢迎参加计教中心网站的学习讨论。
中心网址:
http://ctec.xjtu.edu.cn
课件下载地址:
ftp: //ctec.xjtu.edu.cn
我的E-mail地址:
[email protected]
上一页
谢谢,再见!
下一页
停止放映
第105|83页