计算机系统软件开发基础

计算机系统软件开发基础

主要涉及的知识有系统开发模型软件测试项目管理基础

系统开发模型

在系统开发模型方面主要有:瀑布模型原型化方法演化模型螺旋模型喷泉模型智能模型V模型增量模型

瀑布模型

瀑布模型也称为生命周期法,是生命周期法中最常用的开发模型,它把软件开发的过程分为了软件计划、需求分析、软件设计、程序编码、软件测试和运行维护这 6 个阶段,规定他们自上而下,互相衔接的固定次序,如同瀑布流水,逐级下落。

瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。瀑布模型的本质是“一次通过”,即每个活动只做一次,最后得到软件产品,也称作 “线序顺序模型” 或者 “传统生命周期” ,其过程是从上一项活动接收该活动的工作对象作为输入,利用这一输入实施该项活动应完成的内容,给出该项活动的工作成果,作为输出传给下一项活动;对该项活动实施的工作进行评审,若其工作得到确认,则继续下一项活动,否则返回前项,甚至更前项的活动进行返工。

瀑布模型有利于大型软件开发过程中人员的组织与管理,有利于软件开发方法和工具的研究与使用,从而提供了大型软件项目开发的质量和效率。然而软件开发的实践表明,上述活动之间并非是完全自上而下的,而是呈线性图式,因此,瀑布模型存在严重的缺陷。

原型化方法

软件原型是所提出的新产品的部分实现,建立原型的主要目的是为了解决在产品开发早期阶段需求不确定的问题,其作用是明确并完善需求,探索设计选择方案,发展为最终的产品。

原型有很多种方法来进行分类,主要学习按 “是否实现功能” 和 “最终结果” 这两种分类:

从 “是否实现功能” 来看,软件原型可以分为水平原型和垂直原型两种。

水平原型也称为行为原型,用来探索预期系统的特定行为,并达到细化需求的目的。水平原型通常只是功能的导航,但并未真正实现功能,主要用在界面上。

垂直原型原型也成为结构化原型,实现了一部分功能,垂直原型主要用在复杂的算法上。

从“最终结果”来看,软件原型可以分为抛弃原型和演化原型。

抛弃型原型也成为探索型原型,是指达到预期目标后,原型本身被抛弃。抛弃原型主要用在解决需求不确定性、二义性、不完整性、含糊性等方面。

演化型原型分为开发增量式产品提供基础,式螺旋模型的一部分,也是面向对象软件开发过程的一部分。演化型原型主要用在必须易于升级和优化方面,适用于 Web 项目。

演化模型

演化模型(变换模型)是在快速开发的一个原型的基础上,根据用户在调用原型的过程中提出的反馈意见和建议,对原型进行改进,获得原型的新版本,重复这一过程,直到演化成最终的软件产品。

螺旋模型

螺旋模型将噗波模型和变换模型相结合,他综合了两者的优点,并增加了风险分析。它以原型为基础,沿着螺线自内向外旋转,每旋转一圈都要经过定制计划、风险分析、实施工程、客户评价等活动,并开发原型的一个新版本。经过若干次螺旋上升的过程,得到最终的系统。

喷泉模型

喷泉模型对软件复用和生命周期中多项开发活动的集成提供了支持,主要支持面向对象的开发方法。“喷泉”一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次,相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动中,分析、设计和编码之间不存在明显的边界。

智能模型

智能模型是基于只是的软件开发模型,它综合了上述若干模型,并把专家系统结合在一起。该模型应用基于规则的系统,采用归纳和推理机制,帮助软件人员完成开发工作,并使维护在系统规格说明一级进行。

V 模型

在开发模型中,测试常长作为亡羊补牢的事后行为,但也以测试为中心的开发模型,那就是 V 模型。

V 模型描述了一些不同的测试级别,并说明了这些级别所对应的生命周期中不同的阶段。左边下降的是开发过程的各个阶段,右边上升的是测试过程的各个阶段。

增量模型

增量模型融合了瀑布模型的基本成分(重复的应用)和原型实现的迭代特征。增量模型采用随着时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时,第一个增量往往是核心的产品,也就是说,第一个增量实现了基本的需求,但是有很多补充的特征还没有发布。客户对每一个增量的使用和评估,都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复,直到产生最终的完善产品,增量模型强调每一个增量均发布一个可操作的产品。早期的增量是最终产品的“可拆卸”版本,但他们确实提供了为用户服务的功能,去并且提供了个i用户评估的平台。增量模型的特点时引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。

采用增量模型的优点时人员分配灵活,刚开始不用投入大量人力资源,如果核心产品很受欢迎,则可以增加人力实现下一个增量;当配备的人员不能再设定的期限内完成产品时,它提供了一种先推出核心产品的途径,这样就可以先发布部分功能给客户。

此外,增量模型能够有计划地管理技术风险。增量模型的缺点是如果增量包之间存在相交的情况且不能很好的处理,就必须做全盘的系统分析。增量模型将功能细化,分别开发的方法适用于需求经常改变的软件开发过程中。

软件测试

软件测试的方法一般分为两大类:动态测试静态测试

动态测试

动态测试是指通过运行程序发现错误,分为黑盒测试法白盒测试法灰盒测试法

不管哪一种测试,都不能做到穷尽测试,智能选取少量最有代表性的输入数据,期望用较少的代价暴露出较多的程序错误。这些被选取出来的数据就是有测试用例。(一个完整的测试应该包括输入数据和期望的输出结果)

黑盒测试法

把被测试对象看成一个黑盒子,测试人员完全不考虑程序的内部结构和处理过程,只在软件的接口处进行测试,一句需求规格说明书,检查程序是否满足功能需求,只在软件的接口处进行测试,一句需求规格说明书,检查程序是否满足功能需求。因此黑盒测试法又称为功能测试或者数据驱动测试。常用的黑盒测试用例的设计方法有等价类划分、边值分析、错误猜测、因果图和功能图等。

白盒测试法

把测试对象看做一个打开的盒子,测试人员需要了解程序的内部结构和处理过程,以检查处理过程的细节为基础,对程序中尽可能多的逻辑路径进行测试,检验内部控制结构和数据结构是否有错,实际的运行状态与预期的状态是否一致。由于白盒测试是结构测试,所以被测对象基本上是源程序,以程序的内部逻辑为基础设计测试用例。常用的白盒测试用例设计有基本路径测试、循环覆盖测试、逻辑覆盖测试。

灰盒测试法

灰盒测试是一种介于白盒测试与黑盒测试之间的测试,它关注输出对于输入的正确性。同时也关注内部表现,但这种关注不像白盒测试那样详细且完整,而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。

静态测试

静态测试是指被测试程序不在机器上面运行,而是采用人工检测和计算机辅助静态分析的手段对程序进行检测,静态分析中进行人工检测的主要方法有桌前检查(Desk Checking)、代码审查和代码走查。经验表明,使用这种方法能够有效地发现 30%~70% 的逻辑设计和编码错误。

值得说明的是,使用静态测试的方法也可以实现白盒测试,例如,使用人工检查代码的方法来检查代码的逻辑问题,也属于白盒测试的范畴。

为了保证系统的质量和可靠性,应力求在分析、设计等各个方面开发阶段结束前,对软件进行严格的技术评审。而软件测试是为了发现错误而执行程序的过程。根据测试的目的、阶段的不同,可以把测试分为单元测试集成测试确认测试系统测试等种类。

单元测试

单元测试又称模块测试,是针对软件设计的最小单位(程序模块)进行正确性检验的测试工作。其目的在于检查每个程序单元是否正确实现详细设计说明的模块功能、性能、接口和设计约束等要求,发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例,多个模块可以平行地独立进行单元测试。

单元测试格局详细设计说明书,包括模块接口测试,局部数据结构测试,路径测试、错误处理测试和边界测试,单元测试通常由开发人员自己负责。由于通常测试程序不是独立存在的,因此常常要借助驱动模块(相当于测试模拟的主程序)和桩模块(子模块)完成。单元测试的计划通常是在软件详细设计阶段完成。

集成测试

集成测试也成为组装测试,联合测试(对于子系统而言,则称为部件测试)。它主要是将已通过单元测试的模块集成在一起,主要测试模块之间的协作性。集成测试通常是在软件概要设计阶段完成。

从组装策略而言,可以分为一次性组装和增量式组装,增量式组装又包括自顶向下自底向上混合式三种,其中混合式组装又称为三明治式测试。

自顶向下集成测试

它是一种构造程序结构的增量实现方法。模块集成的顺序式首先集成主模块(主程序),然后按照控制层次结构向下进行集成。隶属于(和间接隶属于)主控模块的模块按照深度优先或者广度优先的方式集成到整个结构中去。

自底向上集成测试

它是从原子模块(比如在程序结构的最底层模块)开始来进行构造和测试的,跟自顶向下集成测试相反。

三明治式测试

它是一种组合的这种测试策略,从“两头”往“中间”测试,其在程序结构的高层使用自定下的策略,在下面的较低层中使用的是自底向上的策略,类似于“两片面夹馅的三明治”。

软件集成的过程是一个持续性的过程,会形成多个临时版本。在不断的集成过程中,功能集成的稳定性是真正的挑战。在每个版本提交时,都需要进行冒烟测试,即对程序主要功能进行验证。冒烟测试也成为版本验证测试或者提交测试。

确认测试

确认测试也称为有效性测试,主要是验证软件的功能、性能及其其他特性是否与用户要求(需求)一致。取人测试计划通常实在需求分析阶段完成的。根基用户的参与程度,通常包括以下四类:

①内部确认测试:主要由软件开发组织内部按软件需求说明书进行测试。

② α 测试( Alpha 测试):由用户在开发环境下进行测试。

③ β 测试( Beta 测试):由用户在实际使用环境下进行测试。

④ 验收测试:针对软件需求说明书,在交付前以用户为主进行的测试。

系统测试

如果项目不只包含软件,还有硬件和网络等,则要将软件与外部支持的硬件、外设、支持软件、数据等其他系统元素结合在一起,在实际运行环境下,对计算机系统的一系列集成与确定测试。一般地,系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等。系统测试计划通常是在系统分析阶段(需求分析阶段)完成的。

不管是在哪一个阶段的测试,一旦测试出问题就需要进行修改。修改完成后,为了检查这种测试是否会引起其他错误,还要对这个问题进行测试,这种测试称为回归测试或者退化测试。

项目管理基础

在项目管理方面的重点主要是项目进度计划于监控软件过程改进

项目进度计划于监控

项目进度的安排于任何一个多重任务工作的进度安排基本差不多。项目的进度计划和工作的实际情况,通常表现为各项任务之间的进度依赖关系,因而通常使用图表的方式来说明。

甘特图

甘特图(Gannt图)使用水平线段表示任务的工作阶段,线段的起点和重点分别对应着任务的开工时间和完成事件,线段的长度表示着完成任务所需的事件。而跟踪甘特图则是在甘特图的基础上,加一个表示现在时间的纵线,可以直观地看出进度是否延误。甘特图的优点在于表明了各任务的计划进度和当前进度,能动态地反映项目进展:其缺点在于难于反映多个任务之间存在的复杂逻辑关系。

.PERT 技术和 CPM 方法

.PERT(计划评审技术)和 CPM(关键路径法)都是采用网络图来描述一个项目的任务网络,通常使用两张图来定义网络图。一张图给出某一特定项目的所有任务,另一张图给出应该按照生么次序来完成这些任务,给出各个任务之间的衔接。PERT 技术和 CPM 方法都是为项目计划人员提供一些定量的工具。

①确定关键路径:即决定项目开发时间的任务链。

②应用统计模型:对每个单独的任务确定最可能的持续时间的估算值。

③计算边界时间:为具体的任务定义时间窗口。

CPM 是借助网络图和各活动所需的时间(估算值),计算每一活动的最早或最迟开始和结束时间。CPM 方法的关键是计算总时差,这样可决定哪一个活动有最小时间弹性。CPM 方法的核心思想是将 WBS 分解的活动按照逻辑关系加以整合,统筹计算出整个项目的工期和关键路径。

在一条路径中,每个工作时间的时间之和等于工程工期,这条路径就称为关键路径。

评估项目进度

最常见的方法是挣值分析,它是把实际进度和计划进度进行比较,发现项目是否拖期或者超前。通过计算实际已花费在项目上的工作量,来预计项目所需的成本和完成时间日期。

软件过程改进

在软件过程改进方面,主要是学习软件过程能力成熟度模型(Capability Maturity Model,CMM)能力成熟模型集成(Capability Maturity Model Integration ,CMMI)

CMM 模型

CMM模型主要描述和分析了软件过程能力的发展程度,确立了一个软件过程成熟程度的分级标准。

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

②可重复级:已经建立了基本的项目管理过程,可用对于成本、进度和功能特性进行跟踪。对于类似的应用项目,有章可循并能重复以往取得成功。焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程,一个可重复的过程则能逐渐演化和成熟,从管路角度可以看到一个按计划且阶段可控的软件开发过程。

③已管理级:软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理时量化的管理。所有过程建立需要相应的度量方式,所有的产品的质量需要有明确的度量指标。这些度量应是详尽的,且可用于理解和控制软件过程和产品,量化控制将使软件开发真正变成一个工业生成活动。

⑤优化级:通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析,能够不断地、持续地进行过程改进。如果一个企业能够根据实际项目性质、技术等因素,不断调整软件产生过程以求达到最佳。

CMMI 模型

与 CMM 模型相比,CMMI 的涉及则更为广泛,专业领域覆盖软件工程、系统工程、集成开发和系统采购。

CMMI 可以看作是把各种 CMM 集成到一个系统的模型中,CMMI 的基础源模型包括软件系统工程,以及集成化产品和过程开发,CMMI 也描述了5个不同成熟度级别。

每一种 CMMI 模型都有两种表示方法:阶段性和连续式。

阶段式表示法强调的是组织的成熟,从过程域集合的角度考察整个组织的过程成熟度阶段,其关键属于是“成熟度”。

连续式表示强调的是单个过程域的能力,从过程域的角度考察基线和度量结构的改善,其关键术语是“能力”。

阶段式模型也把组织分为了5个不同级别:

①初始级

②已管理级

③严格定义级

④定量管理级

⑤优化级

CMMI 的具体目标是:

①改进组织的过程:提高对产品开发和维护的管理能力。

②能给出支持将基础其他科目 CMM 的公共框架。

③确保所开发的全部有关产品符合将要发布的关于软件过程改进的国际标准 ISO/IEC/15504 对软件过程评估的要求。

在使用 CMMI 框架内开发的模型具有下列优点:

①过程改进能扩展到整个企业级。

②先前各模型之间的不一致和矛盾将得到解决。

③既有分级的模型表示,也有连续的模型表示。

④原先单科目过程改进的工作可与其他项目的过程改进工作结合起来。

⑤基于 CMMI 的评估将于组织原先评估得分相协调,从而保护当前的投资,并与 ISO/IEC/15504 评估结构一致。

⑥节省费用。

⑦鼓励组织内各科目之间互相沟通和交流。


回复列表



回复操作

正在加载验证码......

请先拖动验证码到相应位置

发布时间:2020-06-21 12:53:11

修改时间:2020-09-15 10:56:41

查看次数:170

评论次数:0