软件工程理论知识.docx
《软件工程理论知识.docx》由会员分享，可在线阅读，更多相关《软件工程理论知识.docx（63页珍藏版）》请在冰点文库上搜索。
软件工程理论知识
软件工程理论知识
适用班级：
软件设计师、网络工程师
一．什么是软件？
1.满足用户功能需求和性能的指令或计算机程序集合；
2.处理信息的数据结构；
3.描述程序功能以及程序如何操作和使用所要求的文档；
以上三部分的组合构成了软件
二．软件危机及软件工程？
软件危机是指在计算机软件的开发和维护过程中所遇到的一序列严重问题，在20世纪60年代末全面爆发，1968年，北大西洋公约组织提出使用工程的概念、原理、技术和方法来开发与维护软件，即以工程化的方式组织软件的开发。
产生软件危机的原因可归结为两个重要的方面：
软件生产本身存在的复杂性；软件开发所使用的方法和技术。
注意：
我们只能尽力减少软件危机的危害，不可能彻底消除软件危机，犹如人类的感冒，永远不可能彻底消除！
三．有哪些流行的软件工程方法学及其要素？
1.使用最广泛的软件工程方法学是面向结构化方法学和面向对象的方法学（上世纪70-90年代，流行面向结构化方法学，上世纪90年代到现在，流行面向对象方法学）。
2.要素：
方法、工具和过程。
四．什么是软件生存周期？
有哪些活动？
4.1软件生存周期
一个软件从提出开发要求开始到软件废弃不用的整个过程。
4.2开发活动
问题定义、可行性分析和项目开发计划、需求分析和定义、软件设计（先后细分为：
概要设计和详细设计）、编码、测试和运行维护
4.2.1问题定义—--“要解决的问题是什么？
”
通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。
参与人：
用户、系统分析员、项目负责人
4.2.2可行性分析和项目开发计划—--“有行得通的解决方案吗？
”
用户、项目负责人和系统分析师搞清楚系统要解决的问题是什么？
以及从技术、经济、时间等方面论证项目开发可行性。
4.2.3需求分析和定义—--“系统必须做什么？
”
用户、项目负责人和系统分析师确定系统必须做什么？
但不关心具体怎么做？
要确定系统的功能、性能、数据、界面等要求，从而确定系统的逻辑模型，同时制定后期测试计划。
1.需求分析的任务
（1）确定软件系统的综合要求
●界面要求
●功能要求
●性能要求
●安全性、保密性、可靠性要求
●系统运行要求
●异常处理要求
●将来可能提出的要求
（2）分析系统的数据要求：
数据元素、数据元素之间的逻辑关系、数据量和峰值等。
常用的数据描述手段是实体-关系模型。
（3）导出系统的逻辑模型：
结构化分析方法中使用数据流图；面向对象分析方法中使用类模型（类图）
（4）修正项目开发计划：
在明确了用户的真正需求后，可以更准确地估算软件的成本和进度，从而修正项目开发计划
（5）如果必要，可开发一个原型系统来获取用户真正的需求。
2．需求的分类
（1）功能需求：
所开发的软件必须具备什么样的功能。
（2）非功能需求：
指产品必须具备的属性或品质，如可靠性、性能、相应时间、容错性和扩展性等。
（3）设计约束：
也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。
3．需求分析方法
需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成，定义了表示系统逻辑视图和物理视图的方式。
很多需求分析方法都是数据驱动的，即这些方法提供了一种表示数据域的机制，开发人员根据这种表示，确定软件功能及其他特性，最终建立一个待开发软件系统的抽象模型，即目标系统的逻辑模型。
数据域具有三种属性：
数据流、数据内容和数据结构。
目前所有的需求分析方法都具有如下共性：
（1）支持数据域分析的机制
（2）功能表示的方法
（3）接口的定义
（4）问题分解的机制以及对抽象的支持
（5）逻辑视图和物理视图
（6）系统抽象模型
4．需求工程
（1）需求开发：
包括需求捕获、需求分析、编写规格说明书和需求验证四个阶段。
（2）需求管理：
包括定义需求基线、处理需求变更和需求跟踪等方面的工作。
4.2.4概要设计—---“概括地说，应该怎样做？
”
系统分析师和软件设计师在需求定义的基础上，把各功能需求转换成需要的体系结构，即划分模块、模块的层次、模块之间的调用关系以及各模块的功能，同时设计应用系统的总体数据结构和数据库结构。
特例：
进销存管理系统可分为进、销、存三个模块。
4.2.5详细设计—---“具体怎么样做？
”
软件设计师和程序员对概要设计阶段得出的各功能模块进行详细描述成精确的、结构化的过程描述，即各个功能模块具体怎么实现，用相应的工具把模块的控制结构表示出来，但还未进行编码。
4.2.6编码—--代码实现
由程序员把详细设计阶段得出的各模块控制结构（图形）转变成计算机能识别的指令代码。
4.2.7测试
由另一部门（单位）的软件设计师或系统分析师花费最少的人力物力找出程序最多、最大的错误（bug）。
“高产测试”
4.2.8运行维护
由用户和维护人员进行的软件生存周期中时间最长的阶段。
4.3各活动阶段主要文档
4.3.1可行性分析和项目开发计划
●可性行研究报告
●项目开发计划
4.3.2需求分析中的文档
●需求规格说明书
●初步用户使用手册
●确认测试的测试计划
●修改完善的软件开发计划
●系统测试计划文档
4.3.3概要设计阶段文档
●概要设计说明书
●数据库说明书
●用户手册
●修订的测试计划（测试的策略、方法、步骤）
4.4.4详细设计阶段
●详细设计说明书
4.4.5编码
●程序清单
4.4.5测试
●完善的测试计划书
●软件测试报告
4.4.6系统测试阶段
●系统测试报告
2005年下半年
●应该在 （7）阶段制定系统测试计划。
（7）A.需求分析B.概要设计C.详细设计D.系统测试
●（29）详细描述软件的功能、性能和用户界面，以使用户了解如何使用软件。
（29）A.概要设计说明书B.详细设计说明书C.用户手册D.用户需求说明书
五．有哪些主要生存期模型？
瀑布模型、原型开发模型（快速原型模型、演化模型、增量模型）、螺旋模型、喷泉模型、基于知识的模型和变化模型。
5.1瀑布模型（传统的软件周期模型）
瀑布模型严格遵循软件生命周期各阶段的固定顺序：
计划、分析、设计、编程、测试和维护，上一阶段完成后才能进入到下一阶段，整个模型就像一个飞流直下的瀑布，如下图所示。
优点：
以文档作为驱动，强迫开发人员采用规范的方法，严格规定了各阶段必须提交的文档；要求每一阶段结束后，都要进行严格的评审。
与它最相适应的开发方法是结构化方法。
缺点：
不适应用户需求的改动。
2004年下半年：
●软件开发中的瀑布模型典型的刻画了软件生存周期的阶段划分，与其最相适应的软件开发方法是（9）。
（9）A.构件化方法 B.结构化方法 C.面向对象方法 D.快速原型法
5.2原型模型
5.2.1快速原型模型
快速原型的用途是获知用户的真正需求，一旦需求确定了，原型即被抛弃。
主要用于需求分析阶段。
不追求也不可能要求对需求的严格定义，而是采用了动态定义需求的方法，所以不能定义完善的文档。
特征：
简化项目管理、尽快建立初步需求、加强用户参与和决策。
具有广泛技能水平的原型化人员是原型实施的重要保证。
原型化人员应该是具有经验与才干、训练有素的专业人员。
衡量原型化人员能力的重要标准是他是否能够从用户的模糊描述中快速获取需求。
5.2.2演化模型
在快速原型模型中，原型的用途是获知用户的真正需求，一旦需求确定了，原型即被抛弃。
而演化模型应用于整个软件开发过程，是从初始模型逐步演化为最终软件产品的渐进过程。
也就是说，快速原型模型是一种“抛弃式”的原型化方法，而演化模型则是一种“渐进式”的原型化方法。
5.2.3增量模型（渐增式）
增量模型主要用于设计阶段，把软件产品划分为一系列的增量构件，分别进行设计、编程、集成和测试。
新的增量构件不得破坏已经开发出来的产品。
其示意图如图4-2所示。
5.2.4原型模型小结
从下面的有关原型化方法的叙述中，选择出正确的叙述：
（1）快速原型方法是一种企图克服传统软件周期模型缺点的开发方法。
（2）在用户的数据资源没有得到很好地组织和管理的时候，应该使用原型化方法。
（3）在用户没有明确地肯定其需求的时候，应该使用原型化方法。
（4）在用户不希望把自己的时间花在软件开发过程中的时候，应该使用原型化方法。
（5）使用原型化方法时应该使用第三代编程语言。
（6）原型化加强了开发过程中用户的参与和决策。
（7）原型化方法大致可分为三类：
抛弃式、演化式和递增式。
（8）原型化方法大致可分为演化式和递增式。
（9）采用原型化方法时，软件的开发成本较高。
（10）采用原型化方法时，关键的因素是建立原形的速度，而不是原形运行的效率。
5.3螺旋模型
螺旋模型综合了瀑布模型和原型模型中的演化模型的优点，还增加了风险分析。
螺旋线第一圈的开始点可能是一个概念项目。
从第二圈开始，一个新产品开发项目开始了，新产品的演化沿着螺旋线进行若干次迭代，一直转到软件生命期结束。
5.4喷泉模型
喷泉模型主要用于描述面向对象的开发过程。
喷泉一词体现了面向对象开发过程的迭代和无间隙特征。
迭代指的是开发活动常常需要重复多次，在不断的迭代中逐渐完善软件系统，无间歇性指在开发活动之间不存在明显的边界，允许各开发活动交叉、迭代地进行。
5.5迭代软件开发技术
Rational统一开发流程RUP（RationalUnifiedProcess）是一个通用的软件流程框架，它是一个以架构为中心、用例驱动的迭代化软件开发流程。
RUP是从几千个软件项目的实践经验中总结出来的，对于实际的项目具有很强的指导意义，是软件开发行业事实上的行业标准。
在RUP中，我们把软件开发生命周期划分为四个阶段，每个阶段的结束标志就是一个主要的里程碑（如下图所示）。
这四个阶段主要是为了达到以下阶段性的目标里程碑：
先启（Inception）：
确定项目开发的目标和范围
精化（Elaboration）：
确定系统架构和明确需求
构建（Construction）：
实现剩余的系统功能
产品化（Transition）：
完成软件的产品化工作，将系统移交给客户
2005年下半年：
●在开发一个系统时，如果用户对系统的目标是不很清楚，难以定义需求，这时最好使用 （6） 。
（6）A.原型法B.瀑布模型C.V-模型D.螺旋模型
2006年上半年：
●渐增式开发方法有利于（4）。
（4）A.获取软件需求 B.快速开发软件 C.大型团队开发 D.商业软件开
2006年下半年：
●常见的软件开发模型有瀑布模型、演化模型、螺旋模型、喷泉模型等。
其中（5）模型适用于需求明确或很少变更的项目，（6）主要用来描述面向对象的软件开发过程。
（5）A．瀑布模型B.演化模型C.螺旋模型D.喷泉模型
（6）A．瀑布模型B.演化模型C.螺旋模型D.喷泉模型
●统一过程（UP）的基本特征是“用例驱动，以架构为中心的和受控的迭代式增量开发”。
UP将一个周期的开发过程化分为4个阶段，其中（26）提交结果包含了系统架构。
（26）A.先启阶段B.精化阶段C.构建阶段D.提交阶段
5.6极限编程（XP）
一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方法。
与其他方法对比，最大的不同在于：
1.在更短的周期内，更早地提供具体、持续的反馈信息
2.迭代地进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断地发展
3.依赖于自动测试程序来监控开发进度，并及早地捕获缺陷
4.依赖于口头交流，测试和源程序进行沟通
5.倡导持续的演化式的设计
6.依赖于开发团队内部的紧密协作
7.尽可能达到程序员短期利益和项目长期利益的平衡
如上图所示，xp由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联，并通过行为贯穿于整个生命周期。
xp的核心是其总结的四大价值观：
沟通、简单、反馈和勇气、它们是xp的基础，也是xp的灵魂。
5个原则：
快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
在xp方法中，贯彻的是“小步快走”的开发原则，因此工作质量绝不可打折扣，通常采用测试先行的编码方式来提供支持。
在xp中，继承了12个最佳实践：
计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续继承、每周工作40小时，现场客户，编码标准。
六．软件过程基础知识
6.1软件过程
软件过程是指人们用于开发和维护软件及相关产品的一系列活动，包括软件工程过程和软件管理过程。
6.2评估工具
6.2.1软件能力成熟度模型（CapabilityMaturityModel，CMM）
CMM1.1的5个等级（由低级到高级）：
●初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力，管理是反应式（消防式）的。
●可重复级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。
制定了必要的过程纪律，能重复早先类似应用项目取得的成功。
●已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准化软件过程。
所有项目均使用经标准、裁减的标准软件过程来开发和维护软件。
●已管理级
收集对软件过程和产品质量的详细度量，对软件过程和产品都有定量的理解与控制。
●优化级
加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能持续不断地改进。
巧记：
初级程序员，可重复写程序，现已定义了管理策略来优化程序设计！
2006年下半年：
●软件能力成熟度模型（CMM）是目前国际上最流行、最实用的软件生产过程标准和软件企业成熟度的等级认证标准。
该模型将软件能力成熟度自低到高依次划分为初始级、可重复级、已定义级、已管理级、优化级。
从（17）开始，要求企业建立基本的项目管理过程的政策和管理规程，使项目管理过程有章可循。
（17）A．初始级B.可重复级C.已定义级D.已管理级
6.2.2成立成熟度集成模型
CMMI的一种表述方式为连续表述，主要关注某特定域的过程改进和能力评估；另一种表述方式为阶段式，主要是衡量一个企业的成熟度，而不把单个过程是否完成作为重点。
1.阶段表述方式
初始级、已管理级、量化管理级和优化级，这些等级要一级一级逐级进行，每个等级是下一个等级的基础，当前一个级别没有达到时，不能进入下一个等级。
2.连续表述方式
分为0-5能力等级：
未完成级，已执行级，已管理级，已定义级，量化管理级和优化级。
2011年上半年：
●关于过程改进，以下叙述中不正确的是（30）。
（30）A.软件质量依赖于软件开发过程的质量，其中个人因素占主导作用
B.要使过程改进有效，需要制定过程改进目标
C.要使过程改进有效，需要进行培训
D.CMMI成熟度模型是一种过程改进模型，仅支持阶段性过程改进而不支持连续性过程改进
七．软件工程项目管理基本知识
软件项目管理开始于任何技术活动之前，并且贯穿于整个的软件生命周期。
软件工程项目管理一般分为时间管理、成本管理、人力资源管理、风险管理。
7.1时间管理
7.1.1Gantt图
是一种简单的水平条形图，它以水平线段表示子任务的工作阶段，线段的起点和终点分别对应着子任务的起始时间，线段长度指示完成该任务所需要的时间。
甘特图的优点：
直观简明、易学易绘、可从图上清楚地标出子任务间的时间对比，但它也有
缺点：
（a）不能显示地描绘各项彼此间的依赖关系；
（b）进度计划的关键部分不明显，难以判断哪些部分应当是主攻和主控的对象；
（c）计划中有潜力的部分以及潜力的大小不明确，往往造成潜力的浪费。
2006年5月：
●在软件项目管理中可以使用各种图形工具来辅助决策，下面对Gantt图的描述中，不正确的是（5）。
A.Gantt图表现了各个活动的持续时间B.Gantt图表现了各个活动的起始时间
C.Gantt图反映了各个活动之间的依赖关系 D.Gantt图表现了完成各个活动的进度
7.1.2PERT网图与关键路径
PERT网图是一个由箭头（标识任务）和结点（标识事件）组成的有向图。
将网络方法用于工作计划安排的评审和检查。
开发模块A、B、C模块的任务网络图
PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的依赖关系，即哪些任务完成后才能开始另一些任务，以及如期完成整个工程的“关键路径”。
关键路径（CriticalPath）是由一连串的任务所组成的链，距离最大的一条路径。
软件项目的管理人员应该密切注视关键任务的进展情况。
如果希望缩短工期，只有往关键任务中增加资源才会有效果。
7.2成本管理
7.2.1成本估算方法
一种常用的成本估算方法是先估计完成软件项目所需的工作量（人月数），然后根据每个人月的代价（金额）计算机软件的开发费用：
开发费用＝人月数×每个人月的代价
另一种方法是估计软件的规模（通常指源代码行数），然后根据每行源代码的平均开发费用（包括分析、设计、编码、测试所花的费用），计算机软件的开发费用：
开发费用＝源代码行数×每行平均费用
估算源代码行数时，可以请n为有经验的专家，每位专家对软件给出3个估计值：
●ai---最少源代码行数（该软件可能的最小规模）
●bi---最大源代码行数（该软件可能的最大规模）
●mi---最可能的代码行数（该软件最可能的规模）
然后计算出每位专家的估算期
，n位专家的估算期望值的平均值
就是代码行数的估算值。
7.2.2成本估算模型
Putnam模型和COCOMO模型是常用的成本估算模型。
●Putnam模型：
是一种动态多变量模型，它是假设在软件开发的整个生存期中工作量的分布。
●COCOMO模型：
是结构性成本模型，是最精确、最易于使用的成本估算模型之一。
该模型可以分为：
（1）基本COCOMO模型，是一个静态单变量模型，它是对整个软件系统进行估算。
（2）中级COCOMO模型，是一个静态多变量模型。
它将软件系统模型分为系统和部件两个层次，系统由部件构成，它把软件开发所需人力（成本）看作是程序大小和一系列“成本驱动属性”的函数。
（3）详细COCOMO模型，它将软件系统模型分为系统、子系统和模块3个层次，它除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响。
2006年上半年：
●使用LOC（linesofcode）度量软件规模的优点是（9）。
（9）A.容易计算 B.与使用的编程语言相关C.与使用的开发模型有关D.在设计之前就可以计算出LOC
●软件项目开发成本的估算依据，通常是开发成本估算模型，常用的模型有：
①IBM模型②Putnam模型③基本COCOMO模型④中级COCOMO模型⑤高级OCOMO模型其中（18）都是静态单变量模型。
（18）A．①②B.②④⑤C.①③D.③④⑤
7.3风险管理
7.3.1风险的定义
1.关心未来：
风险是否会导致软件项目失败？
2.关心变化：
在用户需求、开发技术、目标机器，以及所有其他与项目及时工作和全面完成有关的实体中会发生什么样的变化？
3.关心选择：
应采用什么方法和工具，应配置多少人力，在质量上强调到什么程度才能满足要求？
7.3.2风险的类型
1.项目风险：
指潜在的预算、进度、人力（工作人员及组织）、资源、客户和需求等方面的问题以及它们对软件项目的影响。
例如：
项目复杂性、规模和结构不确定性等都是项目风险、项目风险威胁到项目计划，即如果项目风险变成现实，有可能会拖延项目的进度，增加项目的成本。
2.技术风险：
指潜在的设计、实现、接口、验证和维护等方面的问题。
此外，规约的二义性、技术的不正确性，陈旧的技术和“先进的”技术也是技术风险因素。
技术风险威胁到开发软件的质量及软件交付时间，如果技术风险比恩成现实，则开发工作可能变得很困难或根本不可能。
3.商业风险：
在信息系统项目中，商业风险威胁到要开发系统的生存能力。
一般主要有5类商业风险：
●市场风险：
开发了一个没有人真正需要的优秀产品或系统
●策略风险：
开发的产品不再符合公司的整体商业策略
●销售风险：
开发了一个销售部门不知道如何去卖的产品
●管理风险：
由于重点的转移或人员的变动而失去了高级管理层的支持
●预算风险：
没有得到预算或人力上的保证
7.3.3风险管理活动
1.风险识别：
找的哦啊潜风险并将其文档化，它包括项目风险、技术风险和商业风险三种
2.风险评估：
可分为定量评估和定性评估。
通过对各种风险发生的可能性和破坏性这两个方面进行评估，并将它们按优先级别进行排列。
在进行软件工程分析时，项目管理人员要进行四种风险评估活动，包括建立表示风险概率的尺度，面熟风险引起的后果，估计风险影响的大小，确定风险估计的正确性
3.风险驾驭：
利用某种技术，如原型化、软件自动化、软件心理学、可靠性工程学等方法设法避开风险。
统称可以把风险应对策略分为两种类型：
防范策略和相应策略
（1）风险防范策略
●规避策略：
想方设法阻止风险的发生或消除风险发生的危害。
避免策略如果成功则可以消除风险对项目的影响。
例如：
针对技术风险可以采取聘请技术专家、针对项目进度风险可以采取延长项目时间或缩减项目范围的办法。
●减轻策略：
当风险很难避免或转移时，可以考虑采取减轻策略来降低风险发生的概率或减轻风险带来的损失。
风险是一种不确定因素，可以通过前期的一些工作来降低风险发生的可能性；或者也可以通过一些准备来降低风险发生的损失。
例如对于需求风险，如果认为需求变化可能很剧烈，那么可以考虑采用柔性设计的方法降低需求变更的代价。
尤其对于IT项目而言，越早发现问题越容易解决，例如对于需求风险带来的问题，在设计阶段发现要好过编码阶段发现。
针对这些特点，也可以采用尽早暴露风险的方法降低发生风险的损失。
（2）制定风险相应策略
注意，虽然我们采用了很多方法防范风险的发生，但风险本身就是一种不确定因素，不可能在项目中完全消除。
我们还需要制定一些风险发生后的应急措施来解决风险带来的问题。
例如：
对于系统性能的风险，由于不清楚目前的系统是否能够满足用户的需求，可能在系统发布后出现系统性能不足的问题。
对于这个风险，我们可以定义其风险响应策略为增加硬件资源以提高系统性能。
风险响应策略与风险防范策略不同，无论风险是否发生，风险防范策略都需要体现在项目技术中，在项目过程中需求有人来执行对应的方法策略；而风险响应策略是在事件触发的，直到当风险发生后才会被执行，如果始终没有发生风险，则始终不会被安排到项目活动中。
7.3.3风险曝光度
风险曝光度（riskexposure）=风险损失*风险概率
例如：
正在开发的软件项目可能存在一个未将发现的错误，这个错误出现的概率是0.5%，给公司造成的损失将是100万元，那么这个错误的风险曝光度是5000元。
7.4软件配置管理
软件配置管理（SoftwareConfigureManagement,SCM）用于整个软件工程过程。
主要目标是标识变更；控制变更；确保变更正确地实现；报告有关变更。
SCM是一组管理整个软件生存期各阶段中变更的活动。
1.基线
基线是软件生存期中各开发阶段的一个特定点，把
升级会员 