软件工程理论知识.docx
《软件工程理论知识.docx》由会员分享，可在线阅读，更多相关《软件工程理论知识.docx（76页珍藏版）》请在冰点文库上搜索。
软件工程理论知识
软件工程理论知识
软件工程基础知识精解
一．什么是软件？
1.满足用户功能需求和性能的指令或计算机程序集合；
2.处理信息的数据结构；
3.描述程序功能以及程序如何操作和使用所要求的文档；
以上三部分的组合构成了软件
二．软件危机以及产生软件危机的原因？
1.软件开发生产率提高的速度，远远跟不上计算机迅速普及的趋势。
软件产品“供不应求”。
2.软件成本在计算机系统总成本中所占的比例逐年上升。
“开发成本高”
3.软件开发人员和用户之间的信息交流往往很不充分，用户对“已完成的”的软件系统不满足的现象经常发生。
4.软件产品的质量不容易保证。
5.软件产品常常是不可维护的。
6.软件产品的重用性差，同样的软件多次重复开发。
7.软件通常没有适当的文档资料。
产生软件危机的原因可归结为两个重要的方面：
软件生产本身存在的复杂性；
软件开发所使用的方法和技术。
三．有哪些流行的软件工程方法学及其要素？
1.使用最广泛的软件工程方法学是面向结构化方法学和面向对象的方法学（上世纪70-90年代，流行面向结构化方法学，上世纪90年代到现在，流行面向对象方法学）。
2.要素：
方法、工具和过程。
四．什么是软件生存周期？
有哪些活动？
4.1软件生存周期
一个软件从提出开发要求开始到软件废弃不用的整个过程。
4.2开发活动
可行性分析和项目开发计划、需求分析和定义、软件设计（先后细分为：
概要设计和详细设计）、编码、测试和运行维护
可行性分析和项目开发计划：
用户、项目负责人和系统分析师搞清楚系统要解决的问题是什么？
以及从技术、经济、时间等方面论证项目开发可行性。
需求分析和定义：
用户、项目负责人和系统分析师确定系统必须做什么？
但不关心具体怎么做？
要确定系统的功能、性能、数据、界面等要求，从而确定系统的逻辑模型，同时制定后期测试计划。
软件设计-概要设计：
系统分析师和软件设计师在需求定义的基础上，把各功能需求转换成需要的体系结构，即划分模块、模块的层次、模块之间的调用关系以及各模块的功能，同时设计应用系统的总体数据结构和数据库结构。
软件设计-详细设计：
软件设计师和程序员对概要设计阶段得出的各功能模块进行详细描述成精确的、结构化的过程描述，即各个功能模块具体怎么实现，用相应的工具把模块的控制结构表示出来，但还未进行编码。
编码：
由程序员详细设计阶段得出的各模块控制结构（图形）转变成计算机能识别的指令代码。
测试：
由另一部门（单位）的软件设计师或系统分析师花费最少的人力物力找出程序最多、最大的错误（bug）。
维护：
由用户和维护人员进行的软件生存周期中时间最长的阶段。
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评估工具
软件过程的评估，通常采用软件能力成熟度
模型（CapabilityMaturityModel，CMM）。
CMM1.1的5个等级（由低级到高级）：
●初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力，管理是反应式（消防式）的。
●可重复级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。
制定了必要的过程纪律，能重复早先类似应用项目取得的成功。
●已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准化软件过程。
所有项目均使用经标准、裁减的标准软件过程来开发和维护软件。
●已管理级
收集对软件过程和产品质量的详细度量，对软件过程和产品都有定量的理解与控制。
●优化级
加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能持续不断地改进。
巧记：
初级程序员，可重复写程序，现已定义了管理策略来优化程序设计！
2006年下半年：
●软件能力成熟度模型（CMM）是目前国际上最流行、最实用的软件生产过程标准和软件企业成熟度的等级认证标准。
该模型将软件能力成熟度自低到高依次划分为初始级、可重复级、已定义级、已管理级、优化级。
从（17）开始，要求企业建立基本的项目管理过程的政策和管理规程，使项目管理过程有章可循。
（17）A．初始级B.可重复级C.已定义级D.已管理级
七．软件工程项目管理基本知识
软件项目管理开始于任何技术活动之前，并且贯穿于整个的软件生命周期。
软件工程项目管理一般分为时间管理、成本管理、人力资源管理、风险管理。
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成本管理
一种常用的成本估算方法是先估计完成软件项目所需的工作量（人月数），然后根据每个人月的代价（金额）计算机软件的开发费用：
开发费用＝人月数×每个人月的代价
另一种方法是估计软件的规模（通常指源代码行数），然后根据每行源代码的平均开发费用（包括分析、设计、编码、测试所花的费用），计算机软件的开发费用：
开发费用＝源代码行数×每行平均费用
估算源代码行数时，可以请n为有经验的专家，每位专家对软件给出3个估计值：
●ai---最少源代码行数（该软件可能的最小规模）
●bi---最大源代码行数（该软件可能的最大规模）
●mi---最可能的代码行数（该软件最可能的规模）
然后计算出每位专家的估算期
，n位专家的估算期望值的平均值
就是代码行数的估算值。
Putnam模型和COCOMO模型：
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元。
八．模块化基本知识
模块是指执行某一特定任务的数据和可执行语句程序元素的集合，通常是指可通过名字来访问的过程、函数、子程序或宏调用等。
模块化就是将一个待开发的软件划分成若干个可完成某一子功能的模块，每个模块可独立地开发、测试，最后组装成完整的程序。
8.1模块特性
8.1.1可分解性
如果一种设计方法提供了将问题分解成子问题的系统化机制，它就能降低整个系统的复杂性，从而实现一种有效的模块化解决方案。
8.1.2可组装性
如果一种设计方法使现存的（可复用的）设计构件能被组装成新系统，它就能提供一种不需要一切从头开始的模块化解决方案。
8.1.3可理解性
如果一个模块可以作为一个独立的单位（不用参考其他模块）被理解，那么它就易于构造和修改。
8.1.4连续性
如果对系统需求的微小修改只导致对单个模块，而不是整个系统的修改，则修改引起副作用就会被最小化。
8.1.5保护性
如果模块内部出现异常情况，并且它的影响限制在模块内部，不会影响其他模块，则错误引起的副作用就会被最小化。
注意“连续性”和“保护性”的区别！
！
8.2模块与模块的耦合性（7种）
耦合是对一个软件结构内不同模块之间互连程度的度量。
耦合可以分成下列几种，它们之间的耦合度由高到低排列。
8.2.1内容耦合
直接操作或修改另一模块的数据，或不通过正常入口转入另一个模块。
软件设计时应坚决禁止内容耦合，应设计成单入口、单出口的模块，避免病态连接。
8.2.2公共耦合
多个模块引用同一全局数据区。
例如，C语言中的external数据类型、磁盘文件等都是全局数据区。
8.2.3外部耦合
模块与软件以外的环境有关联。
例如，输入输出把一个模块与特定的设备、格式、通信协议耦合在一起。
8.2.4控制耦合
一模块明显把开关量、名字等信息送入另一模块，控制另一模块的功能。
8.2.5标记耦合
两个模块之间通过传递公共指针或地址相互作用的耦合。
8.2.6数据耦合
模块间通过传递数据交换信息。
8.2.7非直接耦合（无耦合）
模块间无任何关系，独立工作
原则上讲，模块化设计总是希望模块之间的耦合表现为非直接耦合方式。
在以上耦合中，耦合度从高到低，内容耦合度最高，非直接耦合度最低。
总结：
内公不好，家外被控了，标志数年心血白非了！
（内功不好，家外被控了，标志数年心血白费了！
）
8.3模块的内聚性
内聚是指一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部的概念的自然扩展。
设计时应该力求高内聚，理想内聚的模块应当恰好做一件事情。
1）偶然内聚：
一个模块的各成分之间毫无关系。
比如：
一组语句在程序的多处出现，为了节省内存空间，这些语句放在一个模块中，该模块的内聚是偶然内聚的。
2）逻辑内聚：
把几种逻辑上相关的功能组放在同一模块中。
3）瞬时内聚（时间内聚）：
一个模块所包含的任务必须在同一时间间隔内执行，例如初始化模块。
4）过程内聚：
一个模块的处理元素是相关的，而且必须按特定的次序执行。
5）通信内聚：
一个模块的所有成分都结合在同一个数据结构上。
6）顺序内聚：
模块的成分同一个功能密切相关，且输出，作为另外一个成分的输入。
7）功能内聚：
模块内的所有成分属于一个整体，完成单一的功能。
在以上的内聚中，内聚度从低到高，偶然内聚度最低，功能内聚度最高。
模块的高内聚、低耦合的原则称为模块独立原则，也称为模块设计的原则。
巧记：
偶然逻辑混乱，瞬间遗忘过程，打电话（通信）询问，顺序清楚，功能也搞定！
8.4模块的深度、宽度、扇出与扇入
●深度：
表示软件结构中控制的层数。
●宽度是软件结构中同一
升级会员 