软件工程教案.docx
《软件工程教案.docx》由会员分享，可在线阅读，更多相关《软件工程教案.docx（43页珍藏版）》请在冰豆网上搜索。
软件工程教案
第l部分软件工程基础
第1章软件工程概论
1．1软件
1．1．1软件的定义
软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。
程序是按事先设计的功能和性能要求执行的指令序列。
数据是使程序能正常操纵信息的数据结构。
文档是与程序开发，维护和使用有关的图文材料。
1．1．2软件的特征
软件是一种逻辑实体，而不是具体的物理实体。
因而它具有抽象性。
软件的生产与硬件不同，在它的开发过程中没有明显的制造过程。
在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。
1．1．3软件的应用
按软件应用的不同领域进行划分：
1）系统软件（操作系统、数据库管理系统、设备驱动程序）
2）支撑软件（文件格式化程序、程序库系统、文本编辑程序）
3）应用软件（工程与科学计算软件、系统仿真软件、智能产品嵌入软件）
4）实时处理软件
5）分时软件
6）交互式软件
7）批处理软件
1．2软件工程
1．2．1软件的发展历史
程序设计阶段—50至60年代
程序系统阶段—60至70年代
软件工程阶段—70年代以后
软件危机
⑴项目没有被很好地理解；计划不周，最终导致进度拖延。
⑵没有充分的文档资料（documentation）。
⑶软件可靠性（reliability）缺少度量的标准，质量无法保证。
⑷软件难以维护（maintainability）、不易升级（evolvability）。
1．3．2软件过程的概念
软件规格说明：
规定软件的功能及其运行的限制
软件开发：
产生满足规格说明的软件
软件确认：
确认软件能够完成客户提出的要求
软件演进：
为满足客户的变更要求，软件必须在使用的过程中演进
软件工程过程的特性：
易理解性、可见性、可支持性、可接受性、可靠性、健壮性、可维护性、速度
1．2．3软件工程的概念
Boehm：
运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。
IEEE：
软件工程是开发、运行、维护和修复软件的系统方法。
FritzBauer：
建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。
1．3．4软件工程的要素
软件工程三要素：
方法、工具和过程。
软件工程方法为软件开发提供了“如何做”的技术。
软件工具为软件工程方法提供了自动的或半自动的软件支撑环境。
软件工程过程定义了:
方法使用的顺序
要求交付的文档资料
为保证质量和适应变化所需要的管理
软件开发各个阶段完成的里程碑
1．2．5软件工程的目标
1）付出较低的开发成本
2）达到要求的软件功能
3）取得较好的软件性能
4）开发的软件易于移植
5）需要较低的维护费用
6）能按时完成开发工作及时交付使用。
1．3软件工程的活动
1．3．1建模
1．3．2问题求解
1．3．3知识获取
1．3．4决策知识
作业：
课后自测练习P11
第2章软件过程
2．1软件过程框架
2．2软件的生存周期和瀑布模型
生存周期：
软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。
这个过程即为计算机软件的生存期。
软件生存期的六个步骤，即制定计划、需求分析、设计、程序编码、测试及运行维护。
瀑布模型：
2．3原型实现模型
2．4演化软件过程模型
由于在项目开发的初始阶段人们对软件的需求认识常常不够清晰，因而使得开发项目难于做到一次开发成功，出现返工再开发在所难免。
做两次：
第一次只是试验开发，其目标只是在于探索可行性，弄清软件需求。
第二次则在此基础上获得较为满意的软件产品。
2．4．1增量模型
2．4．2螺旋模型
2．5微软解决框架过程模型
2．5．1过程定义
2．5．2目标驱动
2．5．3基于风险管理的开发调度
2．5．4按产品版本发布
2．5．5支持项目管理
2．5．6靠改进特性与固定资源来激发创造力的战略
2．5．7同步——稳定开发法
2．6基于构件的开发模型
2．7极限编程
2．7．1目标与活动
2．7．2实践方法
2．7．3XP——演化模型
2．7．4XP应用的限制
2．8软件过程能力成熟度模型
2．8．1CMM简介
1）CMM的由来
2）CMM的定义
3）软件能力成熟度模型与能力成熟度模型的过程目标
4）关键过程等级
5）关键过程域
2．8．2关键过程域
2．8．3CMM与ISO
2．8．4CMM的应用
作业：
课后自测练习
第3章软件工程建模语言
3．1建模的概念
建模的原因：
1）在建模过程中了解系统
2）通过抽象降低复杂性
3）有助于回忆所有的细节
4）有助于开发小组间的交流
5）有助于与用户的交流
6）为系统的维护提供文档
模型化或模型方法是通过抽象、概括和一般化，把研究的对象或问题转化为本质（关系或结构）相同的另一对象或问题，从而加以解决的方法。
模型化方法要求所建立的模型能真实反映所研究对象的整体结构、关系或某一过程、某一局部、某一侧面的本质特征和变化规律。
3．1．1系统及模型和视图
3．1．2概念和现象
3．2统一建模语言
3．2．1为什么需要UML
问题提出的背景：
ERP（EnterpriseResourcePlanning）在企业的应用越来越普遍。
但多数ERP系统都未达到预定目标。
对于这类高度复杂、需求持续变化的应用软件，需要采取新的软件开发方式。
Rational公司提出了统一建模语言UML（UnifiedModelingLanguage）和统一开发过程RUP（RationalUnifiedProcess），这种面向对象软件的开发方法为解决上述问题提供了有价值的参考。
但RUP存在不足：
对领域分析方法提供的具体指导不多，也不太强调业务模型的建立和维护。
3．2．2UML简介
UML是通用的可视化建模语言，Rational公司的Booch,Rumbaugh，Jacobson在他们的方法Booch，OMT－2，OOSE的基础上，总结了以往建模技术经验并吸收当今优秀成果得出了统一建模语言。
1997年11月，UML1.1被OMG（ObjectManagementGroup）采纳为标准建模语言，2003年6月OMG通过了UML2.0规约。
UML的语义定义在一个四层建模概念框架中，语言自身被定义在元模型层。
UML的词汇表包含3种构造块：
事物、关系和图。
3．3UML图形符号
3．3．1用例图
系统作用者：
系统作用者代表位于系统之外并和系统进行交互的一类对象，用它可以对软件系统与外界发生的交互进行分析和描述。
软件系统在和外界发生交互时涉及的具体的对象，在UML里，用系统作用者来建模。
用例代表系统为响应系统作用者引发的一个事件而执行的一系列的处理，而且这处理应该为系统作用者产生一种可见的价值。
在UML里，软件系统的功能和其代表的动态行为是用用例来建模的。
用例描述了当系统作用者和软件系统进行交互时，软件系统所执行的一系列的动作序列，这些动作序列不但应包含正常使用的各种动作序列，而且应包含对非正常使用时软件系统的动作序列的描述。
用例用来为软件系统所提供的功能及其动态特征建模，在考虑软件系统的功能划分时，要考虑功能设置的合理性和使用的方便性。
一个用例代表系统作用者和系统的一次交互，用例视图中用例的设置，就代表了软件系统的功能的划分，为了得到合理而方便的软件系统的功能设置，必须仔细考虑每个用例代表的动态行为的内容，使得每个用例都能产生一个有价值的结果。
在通过用例考虑软件系统的功能划分时，应使得功能的分布较为均衡、易于理解、易于使用，这也是用例的定义中所谓“产生可见的价值”的含义。
3．3．2类图及对象图和包
类的定义：
一个类描述了一组对象的公共的结构和行为。
属性：
它是类的一个组成部分，描述了类在软件系统中代表的事物所具备的特征。
属性的定义，在UML里，属性是类的一个具名的构成（namedproperty），它描述了此构成在类的实例中能具备的取值范围。
操作：
操作是一个类所能提供的服务的实现，此服务能被请求，以改变提供服务的类的对象的状态或为服务的请求者返回一个值。
一个类的操作被定义后，它的任何一个对象都能提供此操作所定义的服务。
操作必须有一个名字，可以有参数表，可以有返回值。
类的图形表示：
它是分为三个分隔区（compartment）的长方形。
其中：
1顶端的分隔区为类的名字
2下面两个分隔区为可省略的
3分别可以列出类的属性和操作
在类之间的关系中，最常用的是：
1）依赖关系
2）泛化关系
3）关联关系
依赖关系
两个类之间的依赖关系，表明其中的一个类（客户类）依赖于另一个类（供应类）所提供的某些服务。
图形表示：
依赖关系被图形化地表示为一个带虚线的箭头，箭头所指的类是供应类（被依赖的类），箭头的出发点是客户类。
泛化关系
在UML中，泛化关系表示子类共享定义在一个或多个超类（parent）里的结构或行为。
泛化关系表示类之间的一般和特殊的关系。
图形表示：
在UML中，泛化关系被图形化地表示为一个带有空心三角形的箭头的线段，箭头所指的方向是超类，箭头起始端是子类。
关联关系
聚合：
表示组成和整体的所有关系
组合：
表示整体对组成的包容关系
重复度：
在UML里，角色重复度被定义为关联关系的实例的两端所连接的对象的数目。
重复度1：
代表对象作为角色必须出现且只出现1次。
重复度0..1：
表示对象作为角色可以出现0次或1次。
星号（*）：
代表任意多次，例如：
重复度0..*表示对象作为角色可以出现0次任意多次；
重复度1..*表示对象作为角色必须至少出现1次且可以出现多至任意多次。
3．3．3构件图和配置图
3．3．4消息
消息是一个对象向另一个对象发送的请求其提供服务的指令。
3．3．5状态图
3．3．6／顷序图
3．3．7协作图
3．3．8活动图
3．3．9四种图的运用
作业：
课后自测练习
第2部分软件项目管理
第4章软件项目
4．1项目管理的历史及发展
4．1．1项目管理的历史
4．1．2项目管理的发展
4．1．3项目管理的应用
4．1．4软件项目管理的特点
4．2软件项目的基本概念
4．2．1基本概念
4．2．2项目管理框架
4．2．3人员
1）了解程序员
一、诚实
程序员在学习与工作期间几乎天天与机器打交道，压根就没有受欺骗或欺骗人的机会。
勤奋的程序员在调试无穷多的程序Bug时，已经深深地接受了“诚实”的教育。
不诚实的人，他肯定不想做、也做不好程序员。
有一名市场营销员和一名程序员都在新闻发布会上发言，将一项新技术的消息公布于众。
市场营销员说：
“这项技术比电话、晶体管和原子弹三项发明加起来对世界文明的影响都要大。
”
程序员说：
“这项技术在有限的领域内，在有限的程度上，解决了一些技术性的问题。
”
二、简单——实用主义
有人问一个数学家，一个物理学家和一名程序员：
“一个盒子有几个面？
”
数学家回答说：
“有六个面，因为盒子是长方体。
”
物理学家回答说：
“有12个面，分为6个外表面和6个内表面。
”
程序员回答说：
“只有两个面，里面放电路板和硬盘，外面放显示器和键盘。
”
目前即使最先进的计算机也不具备智能，程序员的基本工作就是把复杂的问题转化为计算机能处理的简单的程序。
如果一个问题复杂到连程序员自己都不能理解，他就无法编出程序让更笨的计算机来处理。
所以程序员信奉“简单——实用”主义。
也有不少做计算机“学问”的人颠倒行事。
本来几句话、几行程序就能说明白的事，非得要抬高到理论创新的程度，写成玄乎的文章去评教授或者弄个博士学位。
所幸在第一线工作的程序员大多是实干的。
三、爱憎分明
程序员大都喜欢技术挑战，不喜欢搞测试与维护。
高水平的程序员喜欢与高水平的程序员一起工作，因为他们怕“与臭棋佬下棋，棋越下越臭”。
程序员大都厌恶拉帮结派、耍政治手腕。
不信，数一数你认识的程序员，有几个是党派人士？
四、工作单调但不乏味
有人问编程大师：
“程序设计的真正含义是什么？
”
大师回答说：
“饿了的时候就吃，困的时候就睡，只要时机恰当就进行程序设计。
”
其实程序员的生活和工作已融为一体，尽管单调却不乏味，还能独享孤独。
有诗为证：
我编程三日
两耳不闻人声
只有硬盘在歌唱
2）了解程序经理
好的程序经理应该具备以下几个条件：
一、技术水平是程序员队伍中的最高级别
每个程序员骨子里头都有一股傲气，如果你不能技压群雄，他们就不会听你指挥。
一个技术水平较差的人被任命为程序经理真是个悲剧，就象一个略有权势的太监，表面上有人对他点头哈腰，背后却被人鄙视。
二、能做最多且最难的工作
程序经理编程要快且好。
别人要干一天的活，他半天就能做完，这样才会有精力去搞管理。
程序经理应负责系统分析、系统设计这类最难的开发工作，并指导不同水平的程序员把各自的工作做好。
如果人手不够，程序经理要能同时干几个人的活。
三、有人格魅力
软件开发是智力创作过程，你不能指望仅通过执行规章制度来产生好的作品。
很多软件公司的程序经理都不是管理专业出身的，他们也不可能为了搞好管理而成天玩弄心机。
技术出色的程序经理一般少有心术不正的，所以管理的重点应是“以身作则”、“公正待人”。
如果程序经理在上班时趴在桌上睡觉，其他程序员也会这样干。
如果程序经理发现有两个程序员趴在机器旁睡觉，不能只对其中一个大声吼叫：
“你一编程就想睡觉，看看人家，在睡觉时都想着编程。
”
4．2．4产品
4．2．5过程
4．2．6项目计划
做项目计划，如同给一个待出生的婴儿写传记那样困难。
如果允许项目结束后再写计划，那就轻松多了，并且可以100%地准确。
历史教训让我们明白一个道理：
如果一万年以后才会有一条阳光大道通向共产主义，那么现在就不要忙着砸锅炼钢赶英超美，免得在跑步奔向共产主义时把自己累死饿死。
在做软件的项目计划时，应屏弃一切浮夸作风。
只有“知已知彼”才能做出合理的项目计划。
这里“知彼”是指要了解项目的规模、难度与时间限制。
“知已”是指要了解有多少可用资源，如可调用的程序员有几个？
他们的水平如何？
软硬件设施如何？
1）知己知彼
首先要了解项目的规模、难度与时间限制，才可以确定应该投入多少人力、物力去做这个项目。
在可行性分析阶段就要考虑这个问题。
但不幸的是，人们在陷入项目不能自拨之前总难以准确地估计项目的规模与难度。
这里经验起到了最重要的作用。
项目的时间限制有两类。
第一类，项目应该完成的日期写在合同中，如果延期了，则开发方要作出相应的赔偿。
第二类是开发自己的软件产品，虽然只确定了该产品大致的发行日期并允许有延误，但如果拖延太久则会失去商机造成损失。
项目的资源分为三类：
“人”、“可复用的软构件”和“软硬件环境”，如图所示。
（１）人是最有价值的资源。
项目计划的制定者要确定开发人员的名单，要根据他们的专长进行分工。
（1）可复用的软构件是次有价值的资源。
构件可提高软件的质量与生产率。
软构件并非一定要用自己的，可以向专业的软件供应商购买。
（2）软硬件环境虽然不是最重要的资源，却是必需的资源。
原则上软硬件环境只要符合项目的开发要求即可。
有些项目可能要用到特殊的设备，则要事先作好准备，以免用时找不到而担搁了进程。
2）进度安排
有一位程序员忙着编写程序，经理问他还需要多久才能完成。
“明天就可以完成。
”程序员立即回答。
“我想这是不切实际的，实话实说，到底还要多少时间？
”经理说。
“我还想加进一些新的功能，这需要花两个星期。
”程序员想了一会儿说。
“即使这样也期望过高了，只要你编完程序时告诉我一声，我也就满足了。
”经理说。
几年以后，经理要退休了。
在他去退休午餐会时，发现那位程序员正趴在机器旁睡觉：
可怜的家伙整个晚上都在忙于编写那个程序。
[James1999]
程序员也期望每天早晨能在7:
00准时起床，可老是一觉醒来就到中午了。
项目落后于进度表乃是家常便饭，不必大惊小怪。
以下一些事件经常会导致项目被延误：
（1）上级领导主管臆断，制定了不现实的期限。
项目经理与程序员们被迫按照不合理的进度表开展工作。
（2）客户的需求发生了变化，但没有对进度表作出相应的修改。
（3）低估了项目的规模与难度，导致投入的人力和物力不足。
（4）并未预见到存在难以克服的技术障碍。
（5）并未预见到开发人员会发生问题，如生病，辞职等等。
（6）开发人员之间不能很好的交流、协作，导致各阶段任务难以如期完成。
所以写进程表不能象小学生写决心书那样充满幻想。
以下是一些有益的建议：
（1）制定进度表的人最好就是项目负责人，他最了解项目和开发人员。
进度表要经过开发小组的讨论，在得到大部数人的支持后才能实施。
避免出现一厢情愿的局面。
（2）进度安排并不见得一定要符合逻辑顺序。
应尽可能地先做技术难度高的事，后做难度低的事。
也就是辛苦在前，轻松在后。
（3）开发一个大的软件项目，应该将进度表分为若干个里程碑。
一个里程碑之内的多个任务可以同步进行。
程序员极容易沉迷于技术，要么乐不思蜀，要么焦头烂额。
里程碑就象心灵的灯塔，使忙碌的人群不混乱，不迷失方向。
（4）进度表中必须留有缓冲时间，并将缓冲时间用到不确定的事情上。
因为人们对即将要做的事情知之甚少，所以要留一些时间以防不测。
Microsoft公司的一些开发小组甚至制定了“50%缓冲规则”[Cusumano1996]。
对许多项目经理而言，容忍进度表中存在缓冲时间，不啻为观念上的一个飞跃。
（5）如果发现项目应交付的期限非常不合理，就要跟领导或跟客户据理力争，请求放宽期限、调整进度。
当客户的需求发生变化时，就要对进度表作出相应的修正。
不要觉得修改进度表很困难很麻烦，不修改才会产生真真的麻烦。
很多人认为戒烟很困难，但马克·吐温曾说：
“戒烟很容易，我一年就戒几十次。
”
4．3项目生存周期
4．4项目拥有者
4．5关键管理技能
4．5．1明白领导和管理的区别
4．5．2交流技巧
4．5．3谈判能力
4．5．4解决问题的能力
4．5．5影响组织
4．6项目管理的基本思想和技术
4．6．1成本／进度综合控制
4．6．2蒙托卡罗模拟技术
4．6．3项目进展评价技术
4．6．4网络计划技术
4．6．5项目管理的可视化技术
作业：
课后自测练习
第5章团队管理
5．1团队模型
5．1．1组织原则
项目的组织机构
1）广义的软件项目组织图
系统工程：
包括需求分析、产品设计和手册活动
验证和确认：
包括测试计划及其本身
工程管理办公室：
包括管理者,计划和管理,职员.
2）组织图的制作准则
（1）合并人员少于2FSP的相邻功能，除非
ⅰ）下属功能的领导者
ⅱ）至少配备0.5FSP以上，且下一阶段发展成完整功能
（2）如果一个功能有7FSP以上,分解成一个管理者和几个附属功能
（3）把任何管理者控制面保持在7以下
（4）如果上述准则与经验常识冲突，使用经验常识.
5．1．2微软解决方案框架团队模型
作业：
课后自测练习
第6章项目计划
6．1项目计划简介
项目计划的目标是提供一个框架，使得管理者能够对资源、成本及进度进行合理的估算，并随着项目的进展不断更新。
项目计划的目标是通过一个信息发现的过程实现的。
软件工程过程中的每一步骤都应该产生可以被复审，并能作为后续步骤的基础工作产品。
软件项目计划是一种面向广大读者的简短文档，在软件管理者、技术人员和客户间传达项目范围和资源信息，定义风险并提出有关风险管理技术的建议，定义管理复审的成本和进度，为与项目相关的所有人员提供软件开发的整体方法概述如何保证质量及变化的管理。
软件项目计划大纲。
6．1．1影响项目估算的因素
软件项目估算的准确性取决于以下因素：
1）计划者是否适当地估算待建造产品规模的程度。
2）把规模估算转换成人的工作量、时间及成本的能力
3）项目计划反映软件项目组能力的程度
4）产品需求的稳定性及支持软件工程工作的环境
6．1．2软件范围的确定
6．1．3项目所需资源
软件计划的第二个任务是估算完成软件开发工作所需的资源：
1）开发环境：
硬件及软件工具
2）可复用构件
3）人员
6．2项目估算
软件成本及工作量的估算永远不会是一门精确的科学。
人员、技术、环境、策略等是影响软件最终成本及开发所需工作量的主要因素。
为了可靠地估算成本及工作量：
1）将估算拖延到项目的最后阶段。
2）基于已经完成的类似的项目进行估算。
3）使用简单的“分解技术”来进行项目成本及工作量的估算。
4）使用一个或多个经验模型进行软件成本及工作量的估算。
6．2．1项目估算的方法
6．2．2软件规模估算
四种估算问题规模的方法（由PutnamtMyers92年提出）：
1）“模糊逻辑”法
要点：
计划者必须说明应用软件的类型
建立其定性的规模估算
在最初的范围内精化该估算
利用个人的经验和项目历史数据库
2）功能点法
3）标准构件法
要点：
软件由若干不同的“标准构件”组成
估算出每个标准构件的出现次数
使用历史数据来确定每个标准构件交付时的大小
4）修改法
要点：
项目中包含对已有软件的使用，但该软件必须做某种程度的修改。
估算必须完成的修改数目及类型。
6．2．3经验估算模型
计算机软件的估算模型使用由经验导出的公式来预测工作量，工作量是LOC或FP的函数。
支持大多数估算模型的经验数据是来源于一个有限的项目样品集。
没有任何估算模型能够适用于所有类型的软件及所有的开发环境。
这种模型得出的结果必须谨慎使用。
典型的估算模型是通过对以前的软件项目中收集到的数据进行回归分析而导出的。
这种模型的总体结构具有如下形式：
E=A+B*（ev）C
文献中提出了许多面向LOC的估算模型：
E=5.2*（KLOC）0.91Walston-Felix模型
E=5.5+0.73*（KLOC）1.16Bailey-Basili模型
E=3.2*（KLOC）1.05Boehm的简单模型
E=5.288*（KLOC）1.047Doty模型，在KLOC>9
E=-13.39+0.0545FPAlbrecht&Gaffney模型
E=60.62*7.728*10-8FPKemerer模型
E=585.7+5.12FPMaston、Barnett&Mellichamp
6．3项目计划的制定与提交
作业：
课后自测练习
第7章风险分析和管理
7．1软件风险
7．1．1风险的概念
7．1．2风险策略
风险:
没有办法消除的缺陷。
被动的风险策略：
最多是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们。
主动的风险策略：
早在技术工作开始之前就已经启动风险管理。
标识出潜在的风险，评估它们出现的概率及产生的影响，且按重要性加以排序，然后软件项目组建立一个计划来管理风险。
风险的特征：
不确定性、损失。
7．1．3软件风险的类别
项目风险：
指潜在的预算
升级会员 