软件设计师——软件工程的基本知识(你想要的都有)

软件开发生命周期模型

软件开发生命周期模型的基本知识点如下:

瀑布模型

是一种将系统按软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等6个基本活动,并且规定了它们自上而下、相互衔接的固定次序的系统开发方法。瀑布模型强调文档的作用,并要求每个阶段都要仔细验证,它适用于需求明确或很少变更的项目。

V模型

是瀑布模型的一种演变模型,将测试和分析与设计关联进行,加强分析与设计的验证。

演化模型

主要针对需求不明确的软件开发项目。根据用户的需求,首先开发核心系统。当该核心系统投入运行后,用户试用并有效地提出反馈。开发人员根据用户的反馈,实施开发的迭代过程。每一次迭代过程由需求、设计、编码、测试和集成等阶段组成,为整个系统增加一个可定义的、可管理的子集。也可将该模型看做是重复执行的多个“瀑布模型”。

螺旋模型

是指将瀑布模型和演化原型模型结合起来,强调风险分析的一种开发模型。

喷泉模型

基于对象驱动,主要用于描述面向对象的开发过程。其开发过程具有迭代性和无间隙性,“迭代”意味着模型中的开发活动常常需要多次重复,每次重复都会增加或明确一些目标系统的性质,但却不是对先前工作结果的本质性改动。“无间隙”是指在开发活动(如分析、设计、编程)之间不存在明显的边界,而是允许各开发活动交叉、迭代地进行。

增量开发

增量开发是把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成,并且能够完成特定的功能。其优点包括:能在较短的时间内向用户提交可完成一些有用工作产品;逐步增加产品的功能可以使用户有较充分的时间学习和适应新产品;项目失败的风险较低;优先级高的服务首先交付,使得最重要的系统服务接受最多的测试。

软件开发过程

需求分析确定软件要完成的功能及非功能要求;概要设计将需求转化为软件的模块划分,确定模块之间的调用关系;详细设计将模块进行细化,得到详细的数据结构和算法;编码根据详细设计进行代码的编写,得到可以运行的软件,并进行单元测试。

软件设计原则

结构化分析与设计

软件设计必须依据软件的需求来进行,结构化分析的结果为结构化设计提供了最基本的输入信息,其关系为:
(1)根据加工规格说明书和控制规格说明进行过程设计;
(2)根据数据字典和实体关系图进行数据设计;
(3)根据数据流图进行接口设;
(4)根据数据流图进行体系结构设计。

高内聚,低耦合

内聚是指模块内部各元素之间联系的紧密程度,也就是代码功能的集中程度。耦合是指模块之间相互联系的紧密程度。
模块内聚通常可以分为7种,根据内聚度从高到底排序表如下:

内聚类型 描述
功能内聚 完成一个单一功能,各个部分协同工作,缺一不可
顺序内聚 处理元素相关,而且必须顺序执行
通信内聚 所有处理元素集中在一个数据结构的区域上
过程内聚 处理元素相关,而且必须按特定的次序执行
瞬时内聚 所包含的任务必须包含在同一时间隔内执行(如初始化模块)
逻辑内聚 完成逻辑上相关的一组任务
偶然内聚 完成一组没有关系或松散关系的任务

模块的耦合性类型通常分为如下7种,根据耦合度从低到高排序如下:

耦合类型 描述
非直接耦合 没有直接联系,互相不依赖对方
数据耦合 借助参数表传递简单数据
标记耦合 一个数据结构的一部分借助于模块接口被传递
控制耦合 模块间传递的信息中包含用于控制模块内部逻辑的信息
外部耦合 与软件以外的环境有关
公共耦合 多个模块引用同一个全局数据区
内容耦合 一个模块访问另一个模块的内部数据
一个模块不通过正常入口转到另一个模块的内部
两个模块有一部分程序代码重叠
一个模块有多个入口

ISO/IEC9126的软件质量模型

(1)功能性。

功能性是指与软件所具有的各项功能及其规定性质有关的一组属性, 包括:
●适合性:与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性。适合程度的例子是面向任务系统中由子功能构成的功能是否合适、表容量是否合适等。
●准确性:与能否得到正确或相符的结果或效果有关的软件属性。此属性包括计算
值所需的准确程度。
●互操作性(互用性):与同其他指定系统进行交互的能力有关的软件属性。为避免可能与易替换性的含义相混淆,此处用互操作性(互用性)而不用兼容性。●依从性:使软件遵循有关的标准、约定、法规及类似规定的软件属性。
●安全性:与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性。
eg:将每个用户的数据和其他的用户的数据隔离开,是考虑了软件的安全性质量子特性。隶属于功能特性。

(2)可靠性。

可靠性是指在规定运行条件下和规定时间周期内,与软件维护其性能级别的能力有关的一组属性。 可靠性反映的是软件中存在的需求错误、设计错误和实现错误而造成的失效情况,包括:
●成熟性:与由软件故障引起失效的频度有关的软件属性。
容错性:与在软件故障或违反指定接口的情况下,维持规定的性能水平的能力有关的软件属性。指定的性能水平包括失效防护能力。
●可恢复性:与在失效发生后,重建其性能水平并恢复直接受影响数据的能力以及为达此目的所需的时间和努力有关的软件属性。

(3)可用性。

可用性是指根据规定用户或隐含用户的评估所作出的与使用软件所衢要的努力程度有关的一一组属性,包括:
●可理解性:与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性。
●易学性)与用户为学习软件应用,(如运行控制、输入、输出)的努力有关的软件属性。
●可操作性:与用户为操作和运行控制的努力有关的软件属性。

(4)效率。

效率是指在规定条件下,与软件性能级别和所用资源总量之间的关系有关的-组属性。包括:
●时间特性:与软件执行其功能时响应和处理时间以及吞吐量有关的软件属性。
●资源特性:与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性。

(5)可维护性。

可维护性是指与对软件进行修改的难易程度有关的一组属性,包括:
●可分析性:与为诊断缺陷或失效原因及为判定待修改的部分所需努力有关的软件属性。
●可改变性:与进行修改、排除错误或适应环境变化所需努力有关的软件属性。.稳定性:与修改所造成的未预料结果的风险有关的软件属性。
●可测试性:与确认已修改软件所需的努力有关的软件属性。此子特性的含义可能
会被研究中的修改加以改变。

(6)可移植性。

可移植性是指与一个软件从一个环境转移到另一个环境运行的能力有关的一组属性。包括:
●适应性:与软件无须采用为该软件准备的活动或手段就可能适应不同的规定环境
有关的软件属性。
●可安装性:与在指定环境下安装软件所需努力有关的软件属性。
●遵循性(-致性):使软件遵循与可移植性有关的标准或约定的软件属性。
●可替换性:与软件在该软件环境中用来替代指定的其他软件的机会和努力有关的软件属性。为避免可能与互操作性(互用性)的含义相混滑,此处用可替换性而不用兼容性。特定软件的可替换性并不隐含此软件可由所考虑的软件所替代。可替换性可能包含可安装性和适应性这两个属性。由于此概念的重要性,它以被采用作为一个独立的子特性。

软件测试

软件测试的目的就是在软件投入生产性运行之前,尽可能名地发现软件产品(主要是指程序)中的错误和缺陷。而根据理论推测,是不可能发现软件中所以错误的。而一个高效的测试是指用少量的测试用例,发现被测软件尽可能多的错误。软件测试所追求的目标是以尽可能少的时间和人力发现软件产品中尽可能多的错误。

测试过程

单元测试

单元测试也称模块测试,通常可以放在编程阶段,由程序员对自己编写的模块进行测试,检查模块是否实现了详细设计说明书中规定的功能和算法。单元测试主要发现编程和详细设计中产生的错误,单元测试计划应该在详细设计阶段之前。单元测试期间着重从以下几个方面对模块进行测试:模块接口、局部数据结构、重要的执行通路、出错处理通路、边界条件等。

集成测试

集成测试也称组装测试,它是对由各模块组装而成的程序进行测试,主要目标是发现模块间的接口和通信问题,验证模块间是否按照规定的方式正确工作。例如,数据字过接口可能丢失:一个模块对另一个模块可能由于疏忽而造成有害影响:把子功能组合起来可能不产生预期的主功能:个别看来是可以接受的误差可能积累到不能接受的程度:全程数据结构可能有问题等。集成测试主要发现设计阶段产生的错误,集成测试计划应该在概要设计阶段制定。

确认测试

确认测试主要依据软件需求说明书检查软件的功能、性能及其他特征是否与用户的需求致。确认测试计划应该在需求分析阶段制定。一般情况下,通过确认测试后的软件就可以交付使用了。

系统测试

系统测试的对象是完整的、集成的计算机系统,系统测试的目的是在真实系统工作环境下,验证完整的软件配置项能否和系统正确连接,并满足系统子系统设计文档和软件开发合同规定的要求。系统测试的技术依据是用户需求或开发合同,除应满足一股测试的准入条件外,在进行系统测试前,还应确认被测系统的所有配置项已通过测试,对需要固化运行的软件还应提供固件。

软件测试方法

白盒测试

又称结构测试,主要用於单元测试阶段。它把程序看成装在”个透明的白盒子里,测试者完全知道程序的结构和处理算法。

逻辑覆盖

辑的覆盖程度。主要的覆盖标准有六种:语句覆盖(SC)、判定覆盖(DC)、条件覆道(CC)、判定/条件覆盖(CDC)、组合条件覆盖(MCC)和路径覆盖。

(1)语句覆盖是指选择足够多的测试用例,使得运行这些测试用例时,被测程序的每个语句至少执行一一次。 显然,语句覆盖是一种很弱的覆盖标准。

(2)判定覆盖又称分支覆盖,它的含义是不仅每个语句至少执行-次, 而且每个判定的每种可能的结果(分支)都至少执行一次。 判定覆盖比语句覆盖强。

(3)条件覆盖的含义是不仅每个语句至少执行一次,而且使判定表达式中的每个条件都取到各种可能的结果。(因此条件覆盖不一定包含判定覆盖,判定覆盖也不-定包含条件覆盖。

(4)判定/条件覆盖就是同时满足判定覆盖和条件覆盖的逻辑覆盖。它的含义是,选取足够的测试用例,使得判定表达式中每个条件的所有可能结果至少出现-次,而且每个判定本身的所有可能结果也至少出现-次。

(5)条件组合覆盖的含义是,选取足够的测试用例,使得每个判定表达式中条件结果的所有可能组合至少出现一次。 (因此,满足条件组合覆盖的测试用例,也-定满足判定/条件覆盖。

(6)路径覆盖的含义是,选取足够的测试用例,使得程序的每条可能执行到的路径都至少经过一次(如果程序中有环路,则要求每条环路至少经过一次)。
路径覆盖实际上考虑了程序中各种判定结果的所有可能组合,因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组合,并不能代替条件覆盖和条件组合覆盖。

黑盒测试

黑盒测试又称功能测试,主要用于集成测试和确认测试阶段。它把软件看作一个不透明的黑盒子,完全不了解软件的内部结构和处理算法,它只检查软件功能是否能按照软件需求说明书的要求正常使用,软件是否能适当地接收输入数据并产生正确的输出信息,软件运行过程中能否保持外部信息的完整性等,常见的黑盒测试方法包括等价类量分、边值分析、错误推测和因果图等。

等价类划分

所谓等价类划分就是某个输入域的集合,对于一个等价类中的输入值来说,他们揭示程序中错误的作用是等效的。也就是说,如果等价类中的一个输入输入数据能检测出一个错误,那么 等价类中的其他输入数据也能检测出同一个错误。 等价类可以分为有效等价类和无效等价类,其中如果个等 价类内的数据是符合(软件需求说明书)要求的、合理的数据,则称这个等价类为有效等价类:否则,则称这个等价类为无效等价类,无效等价类主要用来检验软件的容错性。
采用等价类划分方法来设计测试用例的步骤如下:

(1)根据软件的功能说明,对每一一个输入条件确定若干个有效等价类和若千个无效等价类,并为每个有效等价类和无效等价类编号。

(2)设计一个测试用例,使其覆盖尽可能多的尚未被覆盖的有效等价类。重复这一步,直至所有的有效等价类均被覆盖。

(3)设计一个测试用例,使其覆盖一一个尚未被覆盖的无效等价类。 重复这一步,直至所有的无效等价类均被覆盖。

a测试

a测试是用户在开发者的场所由开发者指导完成的测试。开发者负责记录发现的错误和使用中遇到的问题,换句话说,al 测试是在“受控的"环境中进行的。

β测试

β测试是在一一个或多 个用户的现场由该软件的最终用户实施的,开发者通常不在现场,用户负责记录发现的错误和使用中遇到的问题并把这些问题报告给开发者。也就是说,β测试是在“非受控的"环境中进行的。

回归测试

回归测试是测试软件变更之后,变更部分的正确性和对变更需求的符合性,以及软件原有的、正确的功能、性能和其他规定的要求的不损害性,因此,只要软件发生了变更,都应该进行相应的回归测试。

软件测试准则

另外,在做软件测试时,要注意以下准则:

(1)应该尽早地、不断地进行软件测试,把软件测试贯穿于开发过程的始终。

(2)所有测试都应该能追溯到用户需求。从用户的角度看,最严重的错误是导致软件不能满足用户需求的那些错误。

(3)应该从“小规模”测试开始,并逐步进行“大规模”测试。

(4)应该远在测试之前就制定出测试计划。

(5)根据Pareto原理,80%的错误可能出现在20%的程序模块中,测试成功的关键是怎样找出这20%的模块,因此,对发现错误较多的程序段,应进行更深入的测试。

(6)应该由独立的第三方从事测试工作。

(7)对非法和非预期的输入数据也要像合法的和预期的输入数据一样编写测试用例。

(8)检查软件是否做了应该做的事仅是成功的半,另半是看软件是否做了不该做的事。

(9)在规划测试时不要设想程序中不会查出错误。

(10)测试只能证明软件中有错误,不能证明软件中没有错误。

能力成熟度模型CMM

CMM模型将软件过程的成熟度分为5个等级。

(1)初始级:

软件过程的特点是无秩序的,有时甚至是混乱的。软件过程定义几处于无章法和步骤可循的状态,软件产品所取得的成功往往依赖极个别人的努力和机初始级的软件过程是未加定义的随意过程,项目的执行是随意甚至是混乱的。也许,些企业制订了- -些软件工程规范,但若这些规范未能覆盖基本的关键过程要求,且执没有政策、资源等方面的保证,那么仍然被视为初始级。(特点是混乱和不可预测

(2) 可重复级:

已经建立了基本的项目管理过程,可用于对成本、进度和功能特进行眼踪。对类似的应用项目,有章可循并能重复以往所取得的成功。焦点集中在软管理过程上。一个可管理的过程则是- - 个可重复的过程,一一个可重复的过程则能逐渐化和成熟。从管理角度可以看到一个按计划执行的、阶段可控的软件开发过程。(项目得到管理监控和跟踪,有稳定的策划和产品基线)

(3)定义级:

用于管理和工程的软件过程均已文档化、标准化,并形成整个软件织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过来进行操作。要求制定企业范围的工程化标准,而且无论是管理还是工程开发都需要套文档化的标准,并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程,剪裁出与项目适宜的过程,并执行这些过程。过程的剪裁不是随意的,在使用前需经过企业有关人员的批准。(通过软件过程的定义和制度化确保对产品质量的控制)

(4)管理级:

软件过程和产品质量有详细的发量标准,软件过程和产品质量得到了定量的认识和技制。(特点是产品质量得到策划,软件过程基于度量的跟踪)

(5)优化级:

通过对来自过程、新概念和新技术等方面的各种有用信息的定最分析,能够不断地)将续地进行过程改进。(持续的过程能力改进)

系统转换

本题主要考查系统转换的概念。
新老系统之间的转换有三种方式:直接转换、并行转换和分段转换。
下面详细1这三种转换各自的特点。

  • 直接转换就是在确定新系统运行无误时,立刻启用新系统, 终止老系统运行。)方式对人员、设备费用很节省,一般适用于处理过程不太复杂、 数据不很重要的场台
  • 并行转换是让新老系统并行段时间,经过一段时间的考验以后, 新系统正式智老系统。对于较复杂的大型系统,它提供了一个与老系统运行结果进行比较的机会,以对新老两个系统并行工作,消除了尚未认识新系统时的紧张和不安。在银行、财务一些企业的核心系统中,这是一种经常 使用的转换方式。它的主要特点是安全、可靠但费用和工作量都很大,因为在相当的长时间内系统要两套班子并行工作。
  • 分段转换又称逐步转换、向导转换、试点过渡法等。这种转换方式实际上是以上种转换方式的结合。在新系统全部正式运行前,一部分 部分地代替 老系统。那些在换过程中还没有正式运行的部分,可以在一个模拟环境中继续试运行。这种方式既保了可靠性,又不至于费用太大。但是这种分段转换要求子系统之间有一定的独立性,又系统的设计和实现都有一定 的要求,否则就无法实现分段转换的设想。

统一过程UP

统-过程(UP)的基本特征是“用例驱动、以架构为中心的和受控的迭代式增量开发”一个UP可分为若千个周期,每个周期的开发过程被分为4个阶段,每个阶段可进行若干次迭代。
UP将一个周期的开发过程划分为如下的4个阶段。

(1)初始阶段:该阶段的主要任务包括确定项目范围和边界,识别系统的关键用例,展示系统的侯选架构,估计项目费用和时间,评估项目风险。其意图是建立项目的范围和版本,确定业务实现的可能性和项目目标的稳定性。提交结果包括原始的项目需求和业务用例。

(2)精化阶段:该阶段的主要任务包括分析系统问题领域,建立软件架构基础,淘汰最高风险元素。其意图是对问题域进行分析,建立系统的需求和架构,确定技术实现的可行性和系统架构的稳定性。提交结果包括系统架构及其相关文档、领域模型、修改后的业务用例和整个项目的开发计划。

(3)构建阶段:该阶段相对简单一一些, 其主要任务包括资源管理、控制和流程优化,开发剩余的构件,然后进行构件组装和测试等。其主要意图是增量式地开发一个可以交付用户的软件产品。

(4)提交阶段:该阶段的主要任务包括进行β测试,制作发布版本,用户文档定稿,确认新系统,获取用户反馈,培训、调整产品使最终用户可以使用产品。其主要意图是将软件产品提交用户。

软件开发过程管理

敏捷开发方法之XP

四大价值观
5大原则
13个最佳实践

软件项目管理

软件项目管理的基础知识点如下:

软件项目计划安排进度的方法

  • Gantt图

在这里插入图片描述
  甘特图也就做进度管理图。他是一种简单的水平条形图,它以日历为基准描述项目任务,水平轴表示日历时间线,每一个线条表示一个任务,任务名称垂直的列在左边列中,图中的线条的起点和终点对应水平轴上的时间,分别表示任务的开始时间和结束时间,线条的水平长度表示该任务的持续时间。同一时间短内有多个线条,表示这些任务是并发进行的。
甘特图特点:能清晰的描述每个任务从何时开始,到何时结束,以及任务之间的并行关系。但是他不能清晰的反应出各任务的依赖关系。

  • PERT图

在这里插入图片描述
   PERT图是一个有向图,图中剪头表示任务,它可以标上完成该任务的时间,途中的节点表示流入节点的任务的结束,并开始流出结点任务,这里把结点称为事件。只有当流入该结点的所有任务都结束时,结点所表示的 事件才出现。在PERT图中,最早时刻表示在此时刻之前从该事件出发的任务不可能开始,最迟时刻表示从该事件出发的任务必须在此时刻之前开始。松弛时间,表示在不影响整个工期的前提下,完成任务有多少机动余地。如图:
   PERT图特点:不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间,还给出了任务之间的关系。
  在PERT图中,关键路径是图中最长的一条路径。而松弛时间则反映了完成某些任务时可以推迟其开始时间或延长其所需完成的事件。但是PERT图不能反应任务之间的并行关系。
备注:

  • 1. 结点(事件):图中的圆,表示流入结点任务的结束,并开始流出节点的任务。只有当流入该结点所有任务均结束,结点事件才出现,流出结点任务才开始。
  • 2. 关键路径:图中花费时间最长的事件和活动的序列。
  • 3. 最早时刻:此刻之前从该事件出发的任务不可能开始。
  • 4. 最迟时刻:从该事件出发的任务必须在此时刻之前开始,否则整个工程不能如期完成。
  • 5. 松弛时间:表示不影响整个工期前提下完成该任务的机动余地。

例如我们求如上PERT图的的关键路劲和松弛时间
该题要求求出工程的最少时间,即关键路径。

首先计算出各个路径长度:
  1ABEGJ:3+15+2+7=27
  2.ACFGJ:6+4+3+7=20
  3.ACFHJ:6+4+20+10=40
  4.ADFGJ:10+8+3+7=28
  5.ADFHJ:10+8+20+10=48
  6.ADFIHJ:10+8+4+10=32
  7.ADFIJ:10+8+4+12=34
  综上最长为48,故最少时间为48
求活动FG松弛时间
   首先应弄清楚四个概念的计算:
    ①最早开始时间(某段工程开始点之前最长的输入流之和),
    ②最晚开试(关键路径-开始点到最后整个工程最后结束点的距离),
    ③最早结束(某段工程结束点之前最长的输入流之和),
    ④最晚结束(关键路径-该结束点到整个工程最后结束点的距离)   
根据上述概念可求得
    ①10+8=18
    ②48-3-7=38
    ③10+8+3=21
    ④48-7=41
松弛时间=最晚开始-最早开始②-①=38-18=20
松弛时间=最晚结束-最早结束④-③=41-21=20
另一种较为简单的方法:用关键路径-所求活动在的最长路径即48-10-8-3-7=20求得松弛时间。

软件工程文档

软件文档也称文件,通常指的是一些记录的数据和数据媒体,它具有固定不变的形式,可被人和计算机阅读。它和计算机程序共同构成了能完成特定功能的计算机软件(有人把源程序也当作文档的一部分)。 我们知道,硬件产品和产品资料在整个生产过程中都是有形可见的,软件生产则有很大不同,文档本身就是软件产品。没有文档的软件,不成其为软件,更谈不到软件产品。软件文档的编制在软件开发工作中占有突出的地位和相当的工作量。高效率、高质量地开发、分发、管理和维护文档对于转让、变更、修正、扩充和使用文档,对于充分发挥软件产品的效益有着重要意义。
软件文档可以分开发文档、管理文档和用户文档三大类。

开发文档

开发文档包括《功能要求》、《投标方案》、 《需求分析)、《技术分析》、《系统分析》、《数据库文档》、《功能函数文档》、《界面文档》、 《编译手册》、(QA文档》、(项目总结》等。

管理文档

管理文档包括(产品简介》、《产品演示》、《疑问解答》、(功能介绍》、《技术白皮书》、《评测报告》等。

用户文档

用户文档包括《安装手册》:《使用手册》、《维护手册》、《用户报告》、《销售培调》等。

软件开发风险分析

风险分析:

风险分析实际上是4个不同的活动:风险识别、风险预测、风险评估和风险控制。在对风险进行优先级排序时,需要根据风险概率和后果来进行排序。

风险识别

风险识别是试图系统化地确定对项目计划(估算、进度、资源分配)的威胁。

风险预测

风险预测又称为风险估算,它从两个方面评估一个风险:风险发生的可能性或概率;以及如果风险发生时所产生的后果。
风险预测一共有四个预测活动
(1)建立一个尺度,以反映风险发生的可能性。
(2)描述风险的后果。
(3)估算风险对项目及产品的影响。
(4)标注风险预测的整体精确度,以免产生误解。

风险评估

风险评估根据风险及其发生的概率和产生的影响预测是否影响 参考水平值。

风险控制

风险控制的目的是辅助项目组建立处理风险的策略,有效的策略应考虑风 险避免、风险监控、风险管理及意外事件计划。而其中风险避免是最好的风险控制策略。

软件维护

根据引起软件维护的原因不同,软件维护通常可分为以下四种类型:

改正性维护:

在软件交付使用后,必然会有一部分隐藏的错误被带到运行阶段来。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了纠正这些错误而对软件进行的维护工作就是改正性维护。该类维护一般占总维护 工作量的25%。

适应性维护:

随着计算机的飞速发展,外部环境(新的硬、软件配置)或数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质)或应用环境可能发生变化,为了使软件适应这种变化,而去修改软件的过程就叫做适应性维护。该类维护-般占总维护工作量的20%。

完善性维护:

在软件的使用过程中,用户往往会对软件提出新的功能与性能要求。为了满足这些要求,需要修改或再开发软件,以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。该类维护一般占总维护工作量的50%。

eg:针对应用在运行期的数据特点,修改器排序算法使其更高效,属于完善性维护。

预防性维护:

为了提高软件的可维护性、可靠性等而提出的一种维护类型, 它为以后进步改进软件打下良好基础。通常,预防性维护定义为:“把今天的方法学用于昨天的系统以满足明天的需要”。也就是说,采用先进的软件工程方法对需要维护的软件或软件中的某一部分 (重新)进行设计、编制和测试。该类维护般占总维护工作量的 50%

软件危机

软件危机是指在计算机软件开发和维护过程中所遇到的一系列严重问题。软件危机主要表现在:软件需求的增长得不到满足,软件生产成本高、价格昂贵,软件生产进度无法控制,软件需求定义不够明确,软件质量不易保证,软件可维护性差。归纳起来,产生软件危机的内在原因归结为两个重要方面:一方面是由于软件生产成本存在着复杂性;另一个方面是与软件开发所使用的方法和技术有关。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章