【软考数据库】第十章 系统开发与运行

目录

10.1 系统实施

10.1.1 信息系统生命周期

10.1.2 能力成熟度模型

10.1.3 软件过程开发模型

10.1.4 信息系统开发方法

10.1.5 系统分析与设计

10.1.6 结构化开发 

10.2 系统测试

10.2.1 测试原则和方法

10.2.2 测试阶段

10.2.3 测试用例设计

10.2.4 调试

10.2.5 软件度量

10.3 系统维护

10.3.1 系统转换

10.3.2 系统维护

10.3.3 系统评价

10.4 面向对象开发


前言:

笔记来自《文老师软考数据库》教材精讲,精讲视频在b站,某宝都可以找到,个人感觉通俗易懂。

10.1 系统实施

10.1.1 信息系统生命周期

  • 软件工程基本原理:用分阶段的生命周期计划严格管理、坚持进行阶段评审、实现严格的产品控制采用现代程序设计技术、结果应能清楚的审查、开发小组的人员应少而精、承认不断改进软件工程实践的必要性。
  • 软件工程的基本要素:方法、工具、过程。
  • 软件生存周期:可行性分析与项目开发计划、需求分析、概要设计(选择系统解决方案,规划子系统)、详细设计(设计子系统内部具体实现)、编码、测试、维护。

  1. 系统规划阶段:任务是对组织的环境、目标及现行系统的状况进行初步调查,根据组织目标和发展战略确定信息系统的发展战略,对建设新系统的需求做出分析和预测,同时考虑建设新系统所受的各种约束,研究建设新系统的必要性和可能性。根据需要与可能,给出制建系统的备选方案输出:可行性研究报告、系统设计任务书。
  2. 系统分析阶段:任务是根据系统设计任务书所确定的范围,对现行系统进行详细调查,描述现行系统的业务流程,指出现行系统的局限性和不足之处,确定新系统的基本目标和逻辑功能要求,即提出新系统的逻辑模型。系统分析阶段又称为逻辑设计阶段。这个阶段是整个系统建设的关键阶段,也是信息系统建设与一般工程项目的重要区别所在。输出:系统说明书
  3. 系统设计阶段:系统分析阶段的任务是回答系统“做什么”的问题,而系统设计阶段要回答的问题是“怎么做”。该阶段的任务是根据系统说明书中规定的功能要求,具体设计实现逻辑模型的技术方案,也就是设计新系统的物理模型。这个阶段又称为物理设计阶段,可分为总体设计(概要设计)和详细设计两个子阶段。输出:系统设计说明书 (概要设计、详细设计说明书)
  4. 系统实施阶段:是将设计的系统付诸实施的阶段。这一阶段的任务包括计算机等设备的购置、安装和调试程序的编写和调试、人员培训、数据文件转换、系统调试与转换等。这个阶段的特点是几个互相联系、互相制约的任务同时展开,!必须精心安排、合理组织。系统实施是按实施计划分阶段完成的,每个阶段应写出实施进展报告。系统测试之后写出系统测试分析报告输出:实施进展报告、系统测试分析报告。
  5. 系统运行和维护阶段:系统投入运行后,需要经常进行维护和评价,记录系统运行的情况,根据一定的规则对系统进行必要的修改,评价系统的工作质量和经济效益。

10.1.2 能力成熟度模型

【能力成熟度模型集成CMMI】
是若干过程模型的综合和改进不仅仅软件,而是支持多个工程学科和领域的系统的、致的过程改进框架能适应现代工程的特点和需要,能提高过程的质量和工作效率。
CMMI两种表示方法:
(1)阶段式模型:类似于CMM,它关注组织的成熟度,五个成熟度模型如下:

10.1.3 软件过程开发模型

【瀑布模型】
瀑布模型(SDLC)
:瀑布模型是一个经典的软件生命周期模型一般将软件开发分为:可行性分析 (计划)、需求分析、软件设计 (概要设计、详细设计)、编码 (含单元测试)、测试、运行维护等几个阶段。
瀑布模型特点:
(1)从上一项开发活动接受该项活动的工作对象作为输入;
(2)利用这一输入,实施该项活动应完成的工作内容;
(3)给出该项活动的工作成果,作为输出传给下一项开发活动。
(4)对该项活动的实施工作成果进行评审。若其工作成果得到确认,则继续进行下一项开发活动;否则返回前一项,甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件。

【螺旋模型】

  • 螺旋模型是一个演化软件过程模型,将原型实现的迭代特征与线性顺序(瀑布)模型中控制的和系统化的方面结合起来。在螺旋模型中,软件开发是一系列的增量发布。
  • 开发过程具有周期性重复的螺旋线状。四个象限分别标志每个周期所划分的四阶段:制订计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析,特别适用于庞大而复杂的、高风险的系统。

【V模型】

  • V模型从整体上看起来,就是一个V字型的结构,由左右两边组成。左边的下画线分别代表了需求分析、概要设计、详编码。右边的上画线代表了单元测试、集成测试细设计、系统测试与验收测试。v模型的特点如下:
    (1)单元测试的主要目的是针对编码过程中可能存在的各种错误;
    (2)集成测试的主要目的是针对详细设计中可能存在的问题;
    (3)系统测试主要针对概要设计,检查系统作为一个整体是否有效地得到运行;
    (4)验收测试通常由业务专家或者用户进行,以确认产品能真正符合用户业务上的需要;
    (5)V模型用于需求明确和需求变更不频繁的情形。

【原型化模型】

  • 原型化模型第一步就是创建一个快速原型能够满足项目千系人与未来的用户可以与原型进行交互,再通过与相关干系人进行充分的讨论和分析,最终弄清楚当前系统的需求,进行了充分的了解之后,在原型的基础上开发出用户满意的产品。原型法认为在很难一下子全面准确地提出用户需求的情况下,原型应当具备的特点如下:
    (1)实际可行;
    (2)具有最终系统的基本特征;
    (3)构造方便、快速,造价低。原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的。

【增量模型】

  • 增量模型:首先开发核心模块功能,而后与用户确认,之后再开发次核心模块的功能,即每次开发一部分功能并与用户需求确认,最终完成项目开发优先级最高的服务最先交付。
  • 特点:但由于并不是从系统整体角度规划各个模块,因此不利于模块划分难点在于如何将客户需求划分为多个增量。与原型不用的是增量模型的每一次增量版本都可作为独立可操作的作品,而原型的构造一般是为了演示。

【其他模型】

  • 喷泉模型:是一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性。
  • 基于构件的开发模型CBSD:利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件,也可以是商品化成品软件构件。特点是增强了复用性,在系统开发过程中,会构建一个构件库,供其他系统复用,因此可以提高可靠性,节省时间和成本
  • 形式化方法模型:建立在严格数学基础上的一种软件开发方法,主要活动是生成计算机软件形式化的数学规格说明。

10.1.4 信息系统开发方法

【结构化方法】

  • 结构是指系统内各个组成要素之间的相互联系、相互作用的框架。
  • 结构化方法也称为生命周期法,是一种传统的信息系统开发方法,由结构化分析 (Structured Analysis,SA) 、结构化设计 (Structured Design, SD) 和结构化程序设计 (Structured Programming,SP)三部分有机组合而成,其精髓是自顶向下、逐步求精和模块化设计。
  • 结构化方法的主要特点:
    (1)开发目标清晰化。结构化方法的系统开发遵循“用户第一”的原则;
    (2)开发工作阶段化。每个阶段工作完成后,要根据阶段工作目标和要求进行审查,这使各阶段工作有条不紊地进行,便于项目管理与控制;
    (3)开发文档规范化。结构化方法每个阶段工作完成后,要按照要求完成相应的文档,以保证各个工作阶段的衔接与系统维护工作的遍历;
    (4) 设计方法结构化。在系统分析与设计时,从整体和全局考虑,自顶向下地分解,在系统实现时,根据设计的要求,先编写各个具体的功能模块,然后自底向上逐步实现整个系统。
  • 结构化方法的不足和局限:
    (1)开发周期长:按顺序经历各个阶段,直到实施阶段结束后,用户才能使用系统;
    (2) 难以适应需求变化:不适用于需求不明确或经常变更的项目;
    (3)很少考虑数据结构:结构化方法是一种面向过程,面向数据流的开发方法,很少考虑数据结构。
  • 结构化方法常用工具:结构化方法一般利用图形表达用户需求,常用工具有数据流图、数据字典、结构化语言、判定表以及判定树等.。

【面向对象方法】

  • 面向对象 (Object-Oriented,OO)方法认为,客观世界是由各种对象组成的,任何事物都是对象,每一个对象都有自己的运动规律和内部状态,都属于某个对象类,是该对象类的一个元素。复杂的对象可由相对简单的各种对象以某种方式而构成,不同对象的组合及相互作用就构成了系统。
  • 面向对象方法的特点:
    (1)使用OO方法构造的系统具有更好的复用性,其关键在于建立一个全面合理、统一的模型(用例模型和分析模型)。
    (2)OO方法也划分阶段,但其中的系统分析、系统设计和系统实现三个阶段之间已经没有“缝隙”。也就是说,这三个阶段的界限变得不明确,某项工作既可以在前一个阶段完成,也可以在后一个阶段完成;前一个阶段工作做得不够细,在后一个阶段可以补充。
    (3)面向对象方法可以普遍适用于各类信息系统的开发。
  • 面向对象方法的不足之处必须依靠一定的面向对象技术支持在大型项目的开发上具有一定的局限性不能涉足系统分析以前的开发环节。
  • 当前,一些大型信息系统的开发,通常是将结构化方法和OO方法结合起来首先,使用结构化方法进行自顶向下的整体划分;然后,自底向上地采用OO方法进行开发。因此,结构化方法和OO方法仍是两种在系统开发领域中相互依存的、不可替代的方法。

【原型化方法】

  • 原型化方法也称为快速原型法,或者简称为原型法。它是一种根据用户初步需求,利用系统开发工具,快速地建立一个系统模型展示给用户,在此基础上与用户交流,最终实现用户需求的信息系统快速开发的方法。
  • 按是否实现功能分类:分为水平原型(行为原型,功能的导航)、垂直原型(结构化原型,实现了部分功能)。
  • 按最终结果分类:分为抛弃式原型、演化式原型 。

  • 原型法的特点:
    原型法可以使系统开发的周期缩短成本和风险降低、速度加快,获得较高的综合开发效益。
    原型法是以用户为中心来开发系统的,用户参与的程度大大提高,开发的系统符合用户的需求,因而增加了用户的满意度,提高了系统开发的成功率。由于用户参与了系统开发的全过程,对系统的功能和结构容易理解和接受,有利于系统的移交,有利于系统的运行与维护。
  • 原型法的不足之处:开发的环境要求高。管理水平要求高。
  • 由以上的分析可以看出,原型法的优点主要在于能更有效地确认用户需求。从直观上来看,原型法适用于那些需求不明确的系统开发。事实上,对于分析层面难度大、技术层面难度不大的系统,适合于原型法开发。
  • 从严格意义上来说,目前的原型法不是一种独立的系统开发方法,而只是一种开发思想,它只支持在系统开发早期阶段快速生成系统的原型,没有规定在原型构建过程中必须使用哪种方法。因此,它不是完整意义上的方法论体系。这就注定了原型法必须与其他信息系统开发方法结合使用。

【敏捷开发】

  • 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法,相对于传统软件开发方法的“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通 (认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用
  • 敏捷软件开发宣言:
    (1)个体和交互胜过过程和工具;
    (2)可以工作的软件胜过面面俱到的文档;
    (3)客户合作胜过合同谈判;
    (4)响应变化胜过遵循计划 。

  • 结对编程:个程序员开发,另一个程序在一旁观察审查代码,能够有效的提高代码质量在开发同时对代码进行初步审查,共同对代码负责。
  • 自适应开发:强调开发方法的适应性 (Adaptive)。不象其他方法那样有很多具体的实践做法,它更侧重为软件的重要性提供最根本的基础,并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
  • 水晶方法:每一个不同的项目都需要一套不同的策略、约定和方法论。
  • 特性驱动开发:是一套针对中小型软件开发项目的开发模式。是一个模型驱动的快速迭代开发过程,它强调的是简化、实用、易于被开发团队接受,适用于需求经常变动的项目。
  • 极限编程XP:核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化,XP无需开发人员在软件开始初期做出很多的文档。XP提倡测试先行,为了将以后出现bug的几率降到最低。
  • 并列争球法SCRUM:是一种迭代的增量化过程,把每段时间 (30天) 一次的,并按需求的优先级别来实现产品,多个自组织和自治迭代称为一个“冲刺”的小组并行地递增实现产品。
  • 统一过程(RUP)提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下,确保满足最终用户需求的高质量产品。
    • 3个显著特点:用例驱动、以架构为中心、迭代和增量。
    • 4个流程:初始阶段、细化阶段、构建阶段和交付阶段。每个阶段结束时都要安排一次技术评审,以确定这个阶段的目标是否已经达到。
    • 适用:一个通用过程框架,可以用于种类广泛的软件系统、不同的应用领域不同的组织类型、不同性能水平和不同的项目规模。

10.1.5 系统分析与设计

  • 系统分析过程一般按如图所示的逻辑进行:
    (1)认识、理解当前的现实环境,获得当前系统的“物理模型”;
    (2)从当前系统的“物理模型”抽象出当前系统的“逻辑模型”;
    (3)对当前系统的“逻辑模型”进行分析和优化,建立目标系统的“逻辑模型”;
    (4)对目标系统的逻辑模型具体化(物理化),建立目标系统的物理模型。
  • 系统开发的目的是把现有系统的物理模型转化为目标系统的物理模型,即图中所描述的路径,而系统分析阶段的结果是得到目标系统的逻辑模型。逻辑模型反映了系统的功能和性质,而物理模型反映的是系统的某一种具体实现方案。

  • 系统设计基本原理:抽象(模块化信息隐蔽、模块独立。衡量模块独立程度的标准有两个:耦合性和内聚性。内聚程度从低到高如下表:

  • 耦合程度从低到高如下表所示:

  • 系统总体结构设计是要根据系统分析的要求和组织的实际情况对新系统的总体结构形式和可利用的资源进行大致设计,这是一种宏观、总体上的设计和规划。
  • 系统结构设计原则
    (1)分解-协调原则。
    (2)自顶向下的原则。
    (3)信息隐蔽、抽象的原则。
    (4)一致性原则。
    (5)明确性原则。
    (6)模块之间的耦合尽可能小,模块的内聚度尽可能高。
    (7)模块的扇入系数和扇出系数要合理。
    (8)模块的规模适当 
  • 子系统划分的原则:
    (1)子系统要具有相对独立性。
    (2)子系统之间数据的依赖性尽量小。
    (3)子系统划分的结果应使数据冗余较小。
    (4)子系统的设置应考虑今后管理发展的需要。
    (5)子系统的划分应便于系统分阶段实现。
    (6)子系统的划分应考虑到各类资源的充分利用。
  • 子系统结构设计的任务是确定划分后的子系统模块结构,并画出模块结构图王这个过程中必须考虑以下几个问题。
    (1)每个子系统如何划分成多个模块。
    (2)如何确定子系统之间、模块之间传送的数据及其调用关系。
    (3)如何评价并改进模块结构的质量。
    (4)如何从数据流图导出模块结构图。

【系统模块结构设计】

  • 模块是组成系统的基本单位,它的特点是可以组合、分解和更换。系统中的任何一个处理根据功能都可以看成是一个模块,具体化程度的不同,模块可以分为逻辑模块和物理功能。模块。个模块应具备以下4 个要素:
    (1)输入和输出。
    (2)处理功能。指模块把输入转换成输出所做的工作
    (3)内部数据。指仅供该模块本身引用的数据。
    (4)程序代码。指用来实现模块功能的程序。
    前两个要素是模块外部特性,反映了模块的外貌。后两个要素是模块的内部特性
  • 模块结构图为了保证系统设计工作的顺利进行,结构设计应遵循以下原则。
    (1)所划分的模块其内部的凝聚性要强,模块之间的联系要少,即模块具有较强的独立性。
    (2)模块之间的连接只能存在上下级之间的调用关系,不能有同级之间的横向联系。
    (3)整个系统呈树状结构,不允许网状结构或交叉调用关系出现。
    (4)所有模块(包括后继IPO图)都必须严格地分类编码并建立归档文件模块结构图主要关心的是模块的外部属性,即上下级模块、同级模块之间的数据传递和调并不关心模块的内部。

10.1.6 结构化开发 

  • 结构化分析与设计方法是一种面向数据流的传统软件开发方法,它以数据流为中心构建软件的分析模型和设计模型。结构化分析(Structured Analysis,SA)结构化设计 (Structured Design,SD)和结构化程序设计 (StructuredProgramming Design,SPD)构成了完整的结构化方法。
    结构化方法的分析结果由以下几部分组成:一套分层的数据流图、一本数据词典、一组小说明 (也称加工逻辑说明) 、补充材料。

  1. 数据流:由一组固定成分的数据组成,表示数据的流向。在DFD 中,数据流的流向必须经过加工
  2. 加工:描述了输入数据流到输出数据流之间的变换,数据流图中常见的三种错误如图所示:
    加工3.1.2有输入但是没有输出,称之为“黑洞”;
    加工3.1.3有输出但没有输入。称之为“奇迹“;
    加工3.1.1中输入不足以产生输出,我们称之为“灰洞“。
  3. 数据存储:用来存储数据。
  4. 外部实体(外部主体)是指存在于软件系统之外的人员或组织,它指出系统所需数据的发源地(源)和系统所产生的数据的归宿地(宿)。

 【分层数据流图】

【数据字典DD】
数据流图描述了系统的分解,但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工,以及组成数据流或文件的数据项做出说明。
数据字典有以下4 类条目:数据流、数据项、数据存储和基本加工。

加工逻辑也称为“小说明”。常用的加工逻辑描述方法有结构化语言、判定表和判定树3 种。 

  • 结构化设计(Structured Design,SD)方法是一种面向数据流的设计方法,它可以与SA方法衔接。结构化设计方法的基本思想是将系统设计成由相对独立功能单一的模块组成的结构。
  • 结构化设计方法中用结构图 (structure chart)来描述软件系统的体系结构指出一个软件系统由哪些模块组成,以及模块之间的调用关系。模块结构图是结构化设计的工具,由模块、调用、数据、控制和转接五种基本符号组成。
  • 结构化设计主要包括:
    (1)体系结构设计:定义软件的主要结构元素及其关系;
    (2)数据设计:基于实体联系图确定软件涉及的文件系统的结构及数据库的表结构描述用户界面,软件和其他硬件设备、其他软件系统及使用人员;
    (3)接口设计:的外部接口,以及各种构件之间的内部接口;
    (4)过程设计:确定软件各个组成部分内的算法及内部数据结构,并选定某种过程的表达形式来描述各种算法。 

10.2 系统测试

10.2.1 测试原则和方法

  • 系统测试是为了发现错误而执行程序的过程,成功的测试是发现了至今尚未发现的错误的测试。
  • 测试原则:
    • 应尽早并不断的进行测试;
    • 测试工作应该避免由原:软件的人或小组承担;
    • 在设计测试方案时,不仅要确定输入数据,而且要根据系统功能确定预期的输出结果;
    • 既包含有效、合理的测试用例,也包含不合理、失效的用例;检验程序是否做了该做的事,且是否做了不该做的事;
    • 严格按照测试计划进行;
    • 妥善保存测试计划和测试用例:
    • 测试用例可以重复使用或追加测试。
  • 软件测试方法可分为静态测试和动态测试。
    • 静态测试:指被测试程序不在机器上运行,而采用人工检测和计算机辅助静态分析的手段对程序进行检测,包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行,而对代码的静态测试,包括桌前检查、代码审查、代码走查大方式。使用这种方法能够有效地发现30%-70%的逻辑设计和编码错误
    • 动态测试:指在计算机上实际运行程序进行软件测试,一般采用白盒测试和黑盒测试方法。
      黑盒测试法:功能性测试,不了解软件代码结构,根据功能设计用例,测试软件功能。
      白盒测试法:结构性测试,明确代码流程,根据代码逻辑设计用例,进行用例覆盖。 

10.2.2 测试阶段

(1)单元测试:也称为模块测试,测试的对象是可独立编译或汇编的程序模块软件构件或OO软件中的类(统称为模块),测试依据是软件详细设计说明书
(2)集成测试:目的是检查模块之间,以及模块和已集成的软件之间的接口关系,并验证已集成的软件是否符合设计要求。测试依据是软件概要设计文档。
(3)系统测试:测试对象是完整的、集成的计算机系统;测试的目的是在真实系统工作环境下验证完成的软件配置项能否和系统正确连接,并满足系统/子系统设计文档和软件开发合同规定的要求。测试依据是用户需求或开发合同。主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试安装与反安装测试等,其中,最重要的工作是进行功能测试与性能测试。功能测试主要采用黑盒测试方法;性能测试主要指标有响应时间、吞吐量、并发用户数和资源利用率等。
(4)确认测试:主要用于驰证软件的功能、性能和其他特性是否与用户需求-致。根据用户的参与程度,通常包括以下类型:
● 内部确认测试:主要由软件开发组织内部按照SRS进行测试;
● Alpha测试:用户在开发环境下进行测试。用户在实际使用环境下进行测试,通过改测试后,产品才能交付用户;
● Beta测试:验收测试:针对SRS,在交付前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。验收测试的目的是,在真实的用户工作环境下,检验软件系统是否满足开发技术合同或SRS。
● 验收测试的结论是用户确定是否接收该软件的主要依据。除应满足一般测试的准入条件外,在进行验收测试之前,应确认被测软件系统已通过系统测试。
(5)配置项测试:测试对象是软件配置项,测试目的是检验软件配置项与SRS的一致性。测试的依据是SRS。在此之间,应确认被测软件配置项已通过单元测试和集成测试。
(6)回归测试:测试目的是测试软件变更之后,变更部分的正确性和对变更需求的符合性,以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。

  • 测试策略
    ● 自底向上:从最底层模块开始测试需要编写驱动程序,而后开始逐一合并模块,最终完成整个系统的测试。优点是较早的验证了底层模块。
    ● 自顶向下:先测试整个系统,需要编写桩程序,而后逐步向下直至最后测试最底层模块。优点是较早的验证了系统的主要控制和判断点
    ● 三明治:既有自底向上也有自顶向下的测试方法,二者都包括。兼有二者的优点,缺点是测试工作量大。

10.2.3 测试用例设计

【黑盒测试用例】

  • 黑盒测试用例:将程序看做一个黑盒子,只知道输入输出,不知道内部代码由此设计出测试用例,分为下面几类:等价类划分:把所有的数据按照某种特性进行归类,而后在每类的数据里选取一个即可。
  • 等价类测试用例的设计原则::设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。
  • 边界值划分:将每类的边界值作为测试用例,边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值,如年龄范围为0-150,边界值为0,150,-1,151四个。
  • 错误推测:没有固定的方法,凭经验而言,来推测有可能产生问题的地方作为测试用例进行测试。
  • 因果图:由一个结果来反推原因的方法,具体结果具体分析,没有固定方法

【白盒测试用例】

  • 白盒测试用例:知道程序的代码逻辑,按照程序的代码语句,来设计覆盖代码分支的测试用例,覆盖级别从低至高分为下面几种:
    (1)语句覆盖SC:逻辑代码中的所有语句都要被执行一遍,覆盖层级最低,因为执行了所有的语句,不代表执行了所有的条件判断。
    (2)判定覆盖DC: 逻辑代码中的所有判断语句的条件的真假分支都要覆盖一。

(3)条件覆盖CC:针对每一个判断条件内的每一个独立条件都要执行一遍真和假。
(4)条件判定组合覆盖CDC::同时满足判定覆盖和条件覆盖。

(5)路径覆盖:逻辑代码中的所有可行路径都覆盖了,覆盖层级最高。

10.2.4 调试

  • 测试是发现错误,调试是找出错误的代码和原因。
  • 调试需要确定错误的准确位置;确定问题的原因并设法改正;改正后要进行回归测试。
  • 调试的方法有:蛮力法、回溯法 (从出错的地方开始,向回找)、原因排除法(找出所有可能的原因,逐一进行排除,具体包括演绎法、归纳法、二分法)。

10.2.5 软件度量

  • 软件的两种属性:外部属性指面向管理者和用户的属性,可直接测量一般为性能指标。内部属性指软件产品本身的的属性,如可靠性等,只能间接测量。
  • McCabe度量法:又称为环路复杂度,假设有向图中有向边数为m,节点数为n,则此有向图的环路复杂度为m-n+2。
  • 注意m和n代表的含义不能混淆,可以用一个最简单的环路来做特殊值记忆此公式,另外,针对一个程序流程图,每一个分支边(连线)就是一条有向边,每一条语句(语句框)就是一个顶点。

10.3 系统维护

10.3.1 系统转换

  • 遗留系统是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统,它通常具有以下特点:
    (1)系统虽然完成企业中许多重要的业务管理工作,但仍然不能完全满足要求。一般实现业务处理电子化及部分企业管理功能,很少涉及经营决策。
    (2)系统在性能上已经落后,采用的技术已经过时。例如多采用主机/终端形式或小型机系统,软件使用汇编语言或第三代程序设计语言的早期版本开发,使用文件系统而不是数据库。
    (3)通常是大型的软件系统,已经融入企业的业务运作和决策管理机制之中,维护工作十分困难。
    (4)没有使用现代信息系统建设方法进行管理和开发,现在基本上已经没有文档,很难理解。

  • 系统转换是指新系统开发完毕,投入运行,取代现有系统的过程,,需要考虑多方面的问题,以实现与老系统的交接,有以下三种转换计划:
    (1)直接转换:现有系统被新系统直接取代了,风险很大,适用于新系统不复杂或者现有系统已经不能使用的情况。优点是节省成本。
    (2)并行转换:新系统和老系统并行工作一段时间,新系统经过试运行后再取代若新系统在试运行过程中有问题,也不影响现有系统的运行,风险极小,在试运行过程中还可以比较新老系统的性能,适用于大型系统。缺点是耗费人力和时间资源,难以控制两个系统间的数据转换。
    (3)分段转换:分期分批逐步转换,是直接和并行转换的集合,将大型系统分为多个子系统,依次试运行每个子系统,成熟一个子系统,就转换一个子系统。同样适用于大型项目,只是更耗时,而且现有系统和新系统间混合使用,需要协调好接口等问题。
  • 数据转换与迁移:将数据从旧数据库迁移到新数据库中。有三种方法:系统切换前通过工具迁移、系统切换前采用手工录入、系统切换后通过新系统生成。

10.3.2 系统维护

  • 系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度,其评价指标如下:
    (1)易分析性。软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。
    (2)易改变性。软件产品使指定的修改可以被实现的能力,实现包括编码、设计和文档的更改。
    (3)稳定性。软件产品避免由于软件修改而造成意外结果的能力。
    (4)易测试性。软件产品使已修改软件能被确认的能力。
    (5)维护性的依从性。软件产品遵循与维护性相关的标准或约的能力。
  • 系统维护包括硬件维护、软件维护和数据维护,其中软件维护类型如下正确性维护:
    发现了bug而进行的修改;
    ● 正确性维护:发现了bug而进行的修改。
    ● 适应性维护:由于外部环境发生了改变,被动进行的对软件的修改和升级。
    ● 完善性维护:基于用户主动对软件提出更多的需求,修改软件,增加更多的功能,使其比之前的软件功能、性能更高,更加完善。
    ● 预防性维护:对未来可能发生的bug进行预防性的修改。

10.3.3 系统评价

【系统评价分类】
立项评价:系统开发前的预评价,分析是否立项开发,做可行性评价。
中期评价:项目开发中期每个阶段的阶段评审。或者项目在开发中途遇到重大变故,评价是否还要继续。

  • 结项评价:系统投入正式运行后,了解系统是否达到预期的目的和要求而对系统进行的综合评价。系统评价的指标
    (1)从信息系统的组成部分出发,信息系统是一个由人机共同组成的系统,所以可以按照运行效果和用户需求(人)、系统质量和技术条件(机)这两条线索构造指标。
    (2)从信息系统的评价对象出发,对于开发方来说,他们所关心的是系统质量和技术水平:对于用户方而言,关心的是用户需求和运行质量:系统外部环境则主要通过社会效益指标来反映。
    (3)从经济学角度出发,分别按系统成本、系统效益和财务指标3 条线索建立指标。

10.4 面向对象开发

  • (1)对象:由数据及其操作所构成的封装体,是系统中用来描述客观事务的-个实体,是构成系统的一个基本单位。一个对象通常可以由对象名、属性和方法3个部分组成。
  • (2)类:现实世界中实体的形式化描述类将该实体的属性(数据) 和操作(函数)封装在一起。对象是类的实例,类是对象的模板类可以分为三种:实体类、接口类《边界类) 和控制类实体类的对象表示现实世界中真实的实体,如人、物等。接口类(边界类) 的对象为用户提供一种与系统合作交互的方式,分为人和系统两大类,其中人的接口可以是显示屏窗口、Web 窗体、对话框、菜单、列表框、其他显示控制、条形码、二维码或者用户与系统交互的其他方法。系统接口涉及到把数据发送到其他系统,或者从其他系统接收数据。控制类的对象用来控制活动流,充当协调者。
  • (3) 抽象:通过特定的实例抽取共同特征以后形成概念的过程。它强调主要特征,忽略次要特征。一个对象是现实世界中一个实体的抽象,一个类是一组对象的抽象,抽象是一种单一化的描述,它强调给出与应用相关的特性,抛弃不相关的特性。
  • (4)封装:是一种信息隐蔽技术,将相关的概念组成一个单元模块,并通过-个名称来引用。面向对象封装是将数据和基于数据的操作封装成一个整体对象对数据的访问或修改只能通过对象对外提供的接口进行
  • (5)继承:表示类之间的层次关系 (父类与子类)这种关系使得某类对象可以继承另外一类对象的特征,又可分为单继承和多继承。
  • (6)多态:不同的对象收到同一个消息时产生完全不同的结果。包括参数多态(不同类型参数多种结构类型)包含多态 (父子类型关系) 、过载多态 (类强制多态(强制类型转换) 四种类型。多态以于重载,一个名字不同含义)由继承机制支持,将通用消息放在抽象层,具体不同的功能实现放在低层。
  • (7)接口: 描述对操作规范的说明,其只说明操作应该做什么,并没有定义操作如何做。
  • (8)消息:体现对象间的交互,通过它向目标对象发送操作请求
  • (9)覆盖:子类在原有父类接口的基础上,用适合于自己要求的实现去置换父类中的相应实现。即在子类中重定义一个与父类同名同参的方法
  • (10)函数重载:与覆盖要区分开,函数重载与子类父类无关,且函数是同名不同参数。
  • (11)绑定是一个把过程调用和响应调用所需要执行的代码加以结合的过程在一般的程序设计语言中,绑定是在编译时进行的,叫作静态绑定。动态绑定则是在运行时进行的,因此,一个给定的过程调用和代码的结合直到调用发生时才进行。 

【软考数据库】第一章 计算机系统基础知识
【软考数据库】第二章 程序语言基础知识
【软考数据库】第三章 数据结构与算法
【软考数据库】第四章 操作系统知识
【软考数据库】第五章 计算机网络
【软考数据库】第六章 数据库技术基础
【软考数据库】第七章 关系数据库
【软考数据库】第八章 数据库SQL语言
【软考数据库】第九章 非关系型数据库NOSQL

猜你喜欢

转载自blog.csdn.net/weixin_43313333/article/details/130583624