您好、欢迎来到现金彩票网!
当前位置:ag视讯 > 构件存储库 >

软件工程知识点总结

发布时间:2019-07-30 00:45 来源:未知 编辑:admin

  5. 常见的软件体系结构(B/S 、C/S 、软件总线. SOA 的定义、特点、和工作模型(松耦合、明确定义的接口)

  的工程学科,它以计算机理论及其他相关学科的理论为指导,采用工程化的概念、原理、技术和方法进行软件的开发和维护,把经实践证明的科学的管理措施与最先进的技术方法结合起来。软件工程研究的目标是“以较少的投资获取高质量的软件”。2.

  (P5)软件生命周期(SDLD)是指一个从用户需求开始,经过开发、交付使用,在使用中不断地增补修订,直至软件报废的全过程,亦称软件生存期(Life  Cycle)。

  。该阶段的任务不是具体地解决问题,而是准确地确定“软件系统必须做什么”,确定软件系统必须具备哪些功能。③

  。概要设计就是设计软件的结构,该结构由哪些模块组成,这些模块的层次结构是怎样的,这些模块的调用关系是怎样的,每个模块的功能是什么。同时还要设计该项目的应用系统的总体数据结构和数据库结构,即应用系统要存储什么数据,这些数据是什么样的结构,它们之间有什么关系等。④

  。即对每个模块完成的功能进行具体描述,要把功能描述变为精确的、结构化的过程描述。⑤

  。该阶段把每个模块的控制结构转换成计算机可接受的程序代码,即写成以某特定程序设计语言表示的“源程序”。⑥

  。它是保证软件质量的重要手段,其主要方式是在设计测试用例的基础上检验软件的各个组成部分。测试分为,模块测试、组装测试、确认测试等。⑦

  。软件维护是软件生存期中时间最长的阶段。已交付的软件投入正式使用后,便进入软件维护阶段,它可以持续几年甚至几十年。在大部分文献中将生存期划分为5个阶段,即 要求定义、设计、编码、测试及维护。其中 要求定义阶段包括可行性研究和项目开发计划及需求分析,设计阶段包括概要设计和详细设计。

  为了描述软件生存期的活动,提出了多种生存期模型,如瀑布模型、循坏模型、螺旋模型、喷泉模型、智能模型等。

  3. 目前常见的软件过程模型如下:瀑布模型、增量模型、螺旋模型、喷泉模型、智能模型等。

  优点:在软件工程的第一阶段,瀑布模型得到了广泛的应用,它简单易用,在消除非结构化软件,降低软件的复杂性,促进软件开发工程化方面起了很大的作用。

  缺点:由于瀑布模型是一种理想的线性开发模式,它将一个充满回溯的软件开发过程硬性分割为几个阶段,无法解决软件需求不明确或者变动的问题。这些缺点对软件开发带来了严重影响,由于需求不明确,会导致开发的软件不符合用户的需求而夭折。

  该模型具有较大的灵活性,适合于软件需求不明确、设计方案有一定风险的软件项目。

  增量模型和瀑布模型之间的本质区别是:瀑布模型属于整体开发模型,它规定在开始下一个阶段的工作之前,必须完成前一阶段的所有细节。而增量模型属于非整体开发模型,它推迟某些阶段或所有阶段中的细节,从而较早地产生工作软件。

  对大型软件,需要多个原型描述系统的生存期,螺旋模型将瀑布模型与原型化模型结合起来,并

  :计划下一周期工作。一般的螺旋模型如下图:沿着螺旋线每转一圈,表示开发出一个更完善的新的软件版本。如果开发风险过大,开发机构和客户无法接受,项目有可能就此中止;多数情况下,会沿着螺旋线继续下去,自内向外逐步延伸,最终得到满意的软件产品。

  喷泉模型以面向对象的软件开发方法为基础,以用户需求作为喷泉模型的源泉。如下图:

  6. 喷泉模型是对象驱动的过程,对象是所有活动作用的实体,也是项目管理的基本内容。

  7. 喷泉模型在实现时,由于活动不同,可分为系统实现和对象实现,这既反映了全系统的开发过程,也反映了对象族的开发和重用过程

  智能模型也称为基于知识的软件开发模型,是知识工程与软件工程在开发模型上结合的产物,以瀑布模型与专家系统的综合应用为基础建立的模型,该模型通过应用系统的知识和规则帮组设计者认识一个特定的软件的需求和设计,这些专家系统已成为开发过程的伙伴,并指导开发过程。

  从图中可以清楚地看到,智能模型与其他模型不同,它的维护并不在程序一级上进行,这样就把问题的复杂性大大降低了。

  ② 通过软件工程的专家系统,提供一个设计库支持,在开发过程中成为设计的助手。

  但是,要建立合适于软件设计的专家系统,或建立一个既适合软件工程由适合应用领域的知识库都是非常困难的。目前,在软件开发中正在使用AI技术,并已取得局部进展;例如在CASE工具系统中使用专家系统,又如使用专家系统实现测试自动化。

  需求工程是一个包括创新和维护系统需求文档所必须的一切活动,是对系统应该提供的服务和所受到的约束进行理解、分析、检验和建立文档的过程。

  需求的获取和分析是需求工程的关键和核心步骤,直接影响到后期的开发工作和系统的成败。

  在深入实际调查研究,充分理解用户需求的基础上,获取系统需求。获取过程为:

  ,工程技术人员需要依靠领域专家,学习和理解相关的专业知识,才能正确抽取用户需求。②

  ,与项目相关人员进行沟通,在进一步了解专业领域的基础上,发现系统需求的过程。·需求分析

  需求分析的过程是对收集到的需求进行提炼、分析和审查的过程,最终确定需求,并确保所有项目相关人员对需求取得一致性认识。分析阶段的主要工作包括:

  。对所收集的需求进行重新组织、整理、分类和筛选,并对每类需求进行排序,确定哪些是最重要的需求。③

  。这是分析阶段的核心工作。需求分析模型是对需求的主要描述手段,是根据不同的分析方法建立的各种视图,例如数据流图(DFD)、实体关系图(E-R)、用例图(Use Case)、类图、状态图、各种交互图等。还可建立辅助的说明,如数据词典。④

  。软件需求规格说明(Software Requirement Specification,SRS)是将需求的结果按照不同开发方法规定的格式用图形和文档形式描述出来。需求规格说明在整个开发过程中具有很重要的作用,是用户和开发人员之间进行交流和理解系统的手段。用户通过需求规格说明检查是否符合和满足所提出的全部需求。开发者则通过需求规格文档,了解和理解所开发系统的内容,并以此作为软件设计和软件测试的依据。项目管理人员以它为依据,规划软件开发过程、计划,估算软件成本和控制需求的变更过程。

  也称“容器模型 ”,是一种集中式的模型。在这种结构模型当中,应用系统用一个中央数据仓库来存储各个子系统共享的数据,其它的子系统可以直接访问这些共享数据。当然,每个子系统可能会有自己的数据库。为了共享数据,所有的子系统之间紧密耦合的,并且围绕中央数据仓库,如下图:

  ②共享数据能得到有效的管理,各子系统之间不需要通过复杂的机制来传递共享数据。

  ④所有的子系统都拥有一致的基于中央数据仓库的数据视图。如果新子系统也采用相同的规范,则将它集成与系统中是容易的。

  ①为了共享数据 ,各子系统必须有一致的数据视图 ,不可避免地会影响了整个系统的性能。

  ②一个子系统发生了改变,它产生的数据结构也可能发生改变。为了其他共享的目的,数据翻译系统会被用到。但这种翻译的代价是很高的,并且有时是不可能完成的。

  ③中央数据仓库和各子系统拥有的数据库必须有相同的关于备份、安全、访问控制和恢复的策略,这可能会影响子系统的效率。

  ④集中式的控制使数据和子系统的分布变得非常困难甚至成为不可能。这里分布指的是将数据或子系统分散到不同的机器上。

  :系统中的结点一般只需知道服务的位置而不必清楚系统的结构。分布式结构有如下一些不足:

  :分布式系统比集中式系统要复杂的多。集中式系统的性能主要依赖于主机的处理能力,而分布式系统的性能则还要依赖于网络的带宽,这让情况变得更加复杂。

  :网络环境随时面临着各种威胁,如病毒、恶意代码、非法访问等,如何保证安全性是一个让人头痛的问题。

  :分布式系统的开放性造成了系统的异构性,显而易见,管理异构的系统比管理主机系统要困难得多。

  :这主要指系统的响应时间。网络环境本身的特点决定了网络负载会明显地影响整个系统的响应时间。下面主要讨论几种不同的分布式结构.

  客户-服务器结构(Client/ServerArchitecture)是一种典型的分布式结构。典型的客户-服务器C/S 结构的系统包括三个组成部分:

  ①服务器(Server):多个独立的服务器为系统提供诸如Web、文件共享、打印等服务。

  ②客户(Client):多个并发客户应用访问多个服务器提供的服务,每个客户应用都是独立的同样的客户应用可以同时有多个实例。

  ③网络(Network):客户和服务器通过网络连接在一起。这是C/S结构的常用模式。有时客户应用和服务器应用会在同一台机器上运行,但两个应用还是要通过本机的网络协议进行通信,其效果就像在不同的机器上运行一样。

  根据应用逻辑层所处的位置,C/S 结构的应用系统常可以分为两层结构、三层/多层应用结构。

  在两层C/S 结构中,应用系统有两个典型的应用组成,其中一个是主要负责用户界面部分的客户端,另一个是主要负责数据访问的服务器,两者通过网络进行数据交换。其结构如下图:

  客户应用工具需求向数据库服务器发出数据访问请求,数据库服务器会响应这个请求,查询、更新数据,然后将结果返回给客户端。这是典型的“请求-响应-得结果”模式。当然,不是所有的请求都需要返回结果。实际上,C/S 的工作模式是一种远程过程调用(Remote Procedure Call, RPC)模式。允许客户端和服务器端有不同的软硬平台。

  ·完整的应用包含三个相对独立的逻辑部分,而两层的C/S结构只有两个端应用。应用逻辑应该映射到哪一端上呢? 三种情况:

  C/S 应用1的结构中,客户端应用负责用户界面和应用逻辑部分,因此他的工作比较繁重。这种结构往往被称为

  ,一般的数据库应用都是属于这种结构的。以此相反,C/S 应用3的结构中,服务器负责了更多的工作,而客户端的工作就变得非常单纯。这种结构成为

  。浏览器/Web 服务器结构就属于瘦客户结构,而且常被称为Browser/Server(B/S)结构。不过,越来越多的B/S应用包含了一些可以迁移的代码,例如包含客户端脚本的网页,这些代码从服务器端下载到客户端并在客户端执行,这样一来,客户端也或多或少地要处理一部分的应用逻辑。这种B/S结构实际上介于胖客户和瘦客户结构之间,就如上图中的C/S 应用2的结构。

  由于两层C/S 架构将数据表示和处理逻辑分开,这样,客户端和服务器的功能相对来说就比较单一,两端的维护和升级也比集中式结构简单。

  由于应用逻辑和两端之一是紧耦合的,因此当它发生改变时,不是客户端就是服务器也要跟着做出相应的改变,同时这种改变极有可能会影响到另一端。因此,C/S 架构不适合用在多用户、多数据库、非安全的网络环境中。另外,客户端应用程序越来越大,对使用者的要求也越来越高。

  第二级或中间级是“商业逻辑结点” (business logic node),是指具体应用中实施的 程序逻辑和法则。

  在下图所示的多层应用模型中,为了有效地管理那些完成业务逻辑的组件,中间层会用到应用服务,包括事务服务、消息服务等。常见的事务服务器有Microsoft Transaction Server,消息服务器有Microsoft Message Queue。

  常见的三层结构应用有浏览器-Web服务-数据服务结构。这是一种典型的B/S结构。在这种结构中,

  ⑤业务逻辑集中放在服务器上有所有用户共享,使得系统的维护和更新变得简单,也更安全。

  分布式对象结构的另一个重要特点是,对象可能分布在网络的各个结点上而不是集中在一台硬件服务器上。为了将分散的对象提供的服务“串”起来,一种被形象地称为“软件总线(Software Bus)”的中间件起了关键的作用。

  由于分布式对象结构具有相当好的开放性和透明性,用户可以非常方便地在总线上添加或者删除组件对象,从而完成增加、更新或删除功能。

  公共对象请求代理体系结构。由对象管理组织OMG (Object Management Group)提出的应用软件体系结构和对象技术规范。

  组件对象模型。为组件之间、组件与应用程序之间的通信和互操作提供了统一的标准和技术规范,使不同语言开发的组件可进行基于组件的软件开发。

  由Sun公司定义的规范,EJB构件是实现EJB规范的Java构件,完成企业级应用中的业务逻辑。EJB构件驻留在EJB容器中。

  。整个任务不只是在单机上运行,而是由网络中多台计算机上的相关应用共同协作完成,这需要考虑网络传输、数据安全、数据一致性、同步等诸多问题。②

  。支撑应用的计算机硬件、操作系统、网络协议、数据库系统,以及开发工具种类繁多,需要考虑数据表示、调用接口、处理方式等诸多问题。③

  。参与协作的应用允许位置透明性、迁移透明性、负载平衡性等需求。④应用程序各部分之间松散耦合,从而使应用程序各部分的更新相互独立。

  ⑤业务逻辑集中放在服务器上有所有用户共享,使得系统的维护和更新变得简单,也更安全。

  应用中间件系统可以满足现代系统的需要。中间件是一种处于系统软件(操作系统和网络软件)与应用软件之间的软件,它能使应用软件之间进行跨网络的协同工作(也就是互操作),并允许个应用软件所涉及的“系统结构、操作系统、通信协议、数据库和其他应用服务”各不相同。

  面向服务的体系结构(service-orientedarchitecture,SOA)是一个构件模型,它将应用程序的不同功能单元(称为服务)通过定义良好的接口和契约联系起来。

  ·接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

  2. 服务(service)是封装成用于业务流程的可复用构件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。

  ①在该体系架构中,客户端不和任何服务器相关联,它只和服务相联系,所以客户端和服务器的集成不影响客户端应用程序。

  ④在复杂的应用程序里,业务过程的控制可以被隔离:引入一个业务规则引擎用来控制已经定义好的业务过程流。引擎根据工作流的状态调用各种不同的服务。

  · Web 服务描述语言(Webservices Description Language,WSDL)是受到广泛支持的方法,用于描述服务请求者所要求的绑定到服务提供者的细节

  · 服务应该是独立的、自包含的请求,在实现时它不需要从一个请求到另一个请求的信息或状态

  · 服务不应该依赖于其他服务的上下文和状态。当需要依赖时,它们最好定义成通用业务流程、函数和数据模型

  。在极大规模上可扩展的信息技术能力向外部客户作为服务来提供的一种计算方式。

  当你想运行成批的程序组,但是没有合适的软硬件环境,可使用Amazon的EC2。

  当你想在网络上发布一个短期(几天到几个月)的网站,可使用Flexiscale。

  当你想把一个大容量的文件上传到网络上,允许35000个用户使用2个月的时间,可使用Amazon的Cloud Front即时升级。

  当你想在网络上存储大量的文档,但是你没有足够的存储空间,可使用Amazon的S3。可靠。

  来进行。②应该在测试工作真正开始前的较长时间内就进行测试计划(测试规划)的编写。一般而言,测试计划可以在需求分析完成后开始,详细的测试用例定义可以在设计模型被确定后立即开始,因此,所有测试可以在任何代码被编写前进行计划和设计。

  ③Pareto 原则应用于软件测试。Pareto 原则意味着测试发现的80%的错误很可能集中在20%的程序模块中。

  ④测试应从“小规模”开始,逐步转向“大规模”。即从模块测试开始,再进行系统测试。

  ⑤穷举测试是不可能的,因此,在测试中不可能覆盖路径的每一个组合。然而,充分覆盖程序逻辑,确保覆盖程序设计中使用的所有条件是有可能的。

  ⑤检查程序是否做了应做的事仅是成功的一半,另一半是检查程序是否做了不该做的事。

  把测试对象看作一个透明的盒子,根据程序内部的逻辑结构及有关信息设计测试用例

  把测试对象看作一个透明的盒子,测试人员根据程序内部的逻辑结构及有关信息设计测试用例,检查程序中所有逻辑路径是否都按预定的要求正确地工作。

  根据程序或设计图画出控制流图,并计算其区域数,然后确定一组独立的程序执行路径,最后为每一条基本路径设计一个测试用例

  :每个判定的所有可能结果都至少执行一次,并且,每个判定中的每个条件的所有可能结果都至少出现一次

  :每条可能执行到的路径都至少经过一次(如果程序中包含环路,则要求每条环路至少经过一次)

  ⑤检查程序是否做了应做的事仅是成功的一半,另一半是检查程序是否做了不该做的事。

  黑盒法是把测试对象看做一个黑盒,测试时完全不考虑程序内部的逻辑结构与内部特性,只需根据

  ,测试程序的功能或程序的外部特性,因此黑盒发又称为功能测试或数据驱动测试。黑盒测试法注重于测试软件的功能需求,主要试图发现下列几类错误:功能不对或遗漏;性能错误;初始化和终止错误;界面错误;数据结构或外部数据库访问错误。

  ·将所有可能的输入数据划分成若干个等价类,然后在每个等价类中选取一个代表性的数据作为测试用例

  ·凭以往的经验和直觉推测程序中某些可能存在的各种错误,从而针对性地设计测试用例

  分别开发二个软件版本,用相同的测试用例对二个版本的软件分别进行测试,比较其测试结果

  由于被测试的模块往往不是独立的程序,它处于整个软件结构的某一层位置上,被其他模块调用或调用其他模块,其本身不能单独运行,因此在单元测试时,需要为被测试模块设计若干辅助测试模块。辅助模块有两种

  ,用以模拟主程序或者调用模块的功能,用于向被测模块传递数据,接收、打印从被测模块返回的数据。一般只设计一个驱动模块。另一种是

  ),用于模拟那些由被测模块所调用的下属模块的功能,可以设计一个或者多个桩模块,才能更好地对下属模块进行模拟。

  集成测试(IntegratedTesting)是指在单元测试的基础上,将所有模块按照设计要求组装成一个完整的系统而进行的测试,也称为联合测试或组装测试。重点测试模块的接口部分,需设计测试过程所使用的驱动模块或桩模块。测试方法以黑盒法为主

  的方法来集成系统。首先对每个模块分别进行单元测试,然后再把所有的模块按设计要求组装在一起进行测试。非渐增式是将所有的模块一次连接起来,简单、易行,节省机时,但测试过程中难于查错,发现错误也很难定位,测试效率低。

  它的集成式逐步实现的,组装测试也是逐步完成的,也可以说它把单元测试与组装测试结合起来进行的。该测试是逐个把未经过测试的模块组装到已经测试过得模块上去,进行组装测试,每加入一个新模块进行一次集成的测试。重复此过程直至程序组装完毕。

  α测试是邀请某些有信誉的软件用户与软件开发人员一道在开发场地对软件系统进行测试,其测试环境要尽量

  。在测试过程中,软件系统出现的错误或使用过程中遇到的问题,以及用户提出的修改要求,均要由开发人员完整、如实地记录下来,作为对软件系统进行修改的依据。α测试的整个过程是在受控环境下,由开发人员和用户共同参与完成的。α测试的目的是评价软件的FLURPS,其中FLURPS 表示对一下项目的测试:①Function Testing(功能测试)

  下进行的测试。整个测试活动是在用户的独立操作下完成的,没有软件开发人员的参与。β测试是投入市场前由支持软件预发行的客户对FLURPS 进行测试,主要目的是测试系统的可支持性。β测试的涉及面最广,最能反映用户的真实愿望,但花费的时间最长,不好控制。一般地,软件公司与β测试人员之间有一种互利的协议。即β测试人员无偿地为软件公司做测试,定期递交测试报告,提出批评与建议。而软件公司将向β测试人员免费赠送或以很大的优惠价格提供软件的正式版本。

  通常应该先进行“人工走查”,再以白盒法为主,辅以黑盒法进行动态测试。使用白盒法时,只需要选择一种覆盖标准,而使用黑盒法时,应该采用多种方法。

  关键是要按照一定的原则,选择组装模块的方案(次序),然后再使用黑盒法进行测试。在测试过程中,如果发现了问题较多的模块,需要进行回归测试时,再采用白盒法。

  软件维护是指软件系统交付使用以后,为了改正错误或满足新的需求而修改软件的过程。按照不同的维护目的,维护工作可分成4类。

  这种扩充软件功能、增强软件性能、提高软件运行效率和可维护性而进行的维护活动称为完善性维护。

  此项维护的策略是,可以使用功能强、使用方便的工具,或采用原型化方法开发的等。

  适应性维护是为了适应计算机的飞速发展,使软件适应外部新的硬件和软件环境或者数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质)发生的变化,而进行修改软件的过程。

  它主要的维护策略是,对可能变化的因素进行配置管理,将因环境变化而必须修改的部分局部化,即局限于某些程序模块等。

  对在测试阶段未能发现的,在软件投入使用后才逐渐暴露出来的错误的测试、诊断、定位、纠错,以及验证、修改的回归测试过程称为纠错性维护。

  它主要的维护策略是,开发过程中采用新技术,利用应用软件包,提高系统结构化程度,进行周期性维护审查等。

  预防性维护是为了提高软件的可靠性和易维护性,采用先进的软件工程方法对需要维护的软件或软件中的某一部分重新进行设计、编制和测试,为以后进一步维护和运行打好基础。也就是软件开发组织选择在最近的将来可能变更的程序,做好变更它们的准备。

  项目管理的9个知识领域、5个过程组、和44个过程之间的相互关系可以通过下表来表示:

  是为了有效地控制和管理软件开发过程中的变化,进行标识、组织和控制修改的技术。

  ①源代码行(LOC)估算。源代码行是指机器指令行/非机器语言的执行步,使用它们可以作为度量生产率的基本数据。

  ②开发工作量估算。它是估算任何项目开发成本最常用的技术方法。根据项目开发过程,通常使用的度量单位是人月(PM)、人年(PY)或人日(PD)。

  ③软件生产率估算。它是指单位劳动量所能完成的软件数量,度量单位常用LOC/PM,¥/LOC或¥/PM。

  ·有代表性的软件开发成本估算模型:专家估算模型、IBM估算模型、Putnam 估算模型。

  其中:ai — 估计的最小行数     bi —估计的最大行数     mi — 最可能的行数

  最后,通过与历史资料进行类比,推算出该软件每行源代码所需成本,将估算的源代码行数,乘以推算出的每行源代码所需成本,就得到该软件的成本估算值。

  IBM估算模型是一种静态单变量模型,它利用已估算的结果,如源代码行,来估算各种资源的需求量.

  但IBM 估算模型不是一种通用模型,因此应用中应根据具体实际情况调整模型中的参数.

  ²  COCOMO模型是一种层次模型,按照其祥细程度分为三级:即基本的COCOMO模型、中间的COCOMO模型和详细的COCOMO模型。

  ²  该模型主要对工作量MM(单位:PM)和进度TDEP(单位:月)进行估算。模型中考虑到估算量与开发环境有关,将开发项目分为三类:

  ①组织型(Organic):相对较小、较简单的软件项目。程序规模不是很大(小于5万行),开发人员对产品目标理解充分,经验丰富,熟悉开发环境。大多数应用软件及老的操作系统、编译系统属于此种类型。

  ②嵌入型(Embadded):此种软件要求在紧密联系的硬件、软件和操作的限制条件下运行,通常与某些硬件设备紧密结合在一起,因此,对接口、数据结构,算法要求较高。如大型复杂的事务处理系统,大型、超大型的操作系统,军事指挥系统,航天控制系统等

  ③半独立型(Semidetached):对项目要求界于上述两者之间,规模复杂度中等。最大可达30万行。如大多数事务处理系统、新操作系统,大型数据库,生产控制等软件属此种类型。

  模型系数,a —模型指数 . Cl、a 取决于开发项目的模式为组织型、半独立型或嵌入型。

  ·描述计划进度的主要工具:一般的表格工具、甘特图、PERT技术与CPM方法。

  风险(risk)是一种潜在的危险。软件项目由于其自身的特点而存在风险,甚至是灾难性的风险。

  1)  项目风险(project)。与项目有关的预算、进度、人力、资源、用户需求、项目规模、复杂性等方面的问题。

  2)  技术风险(technical)。是指影响开发质量和交付时间的设计、实现、验证、维护、接口等方面的问题。

  3)  商业风险(business )。包括与产品的商业运作有关的市场风险、预算风险、决策风险、销售风险等。

  ⑵  风险发生所带来的损失的严重程度,即评价若风险一旦发生所产生的后果。

  ·为了反映风险产生的可能程度和风险产生后果的严重程度,建立风险度量的指标体系,如一种简单的风险评估技术是建立风险评估表。

  风险评价是指在风险估算的基础上,对所确定的风险做进一步的确认。定义项目的风险参考水准,进一步验证风险评估结果的准确性,并按照风险发生概率高低和后果严重的程度进行排序。一般可定义成本、性能和进度是三个典型的参考量。

  一个有效的策略必须考虑风险避免、风险监控和风险管理及意外事件计划这样三个问题。风险的策略管理可以包含在软件项目计划中,或者风险管理步骤也可以组成一个独立的风险缓解、监控和管理计划。

  这一种主动避免风险的活动。是在风险发生前分析引起风险的原因,采取措施,避免风险发生。

  贯穿在软件开发的全过程,是一种项目跟踪活动。主要监控对项目风险产生主要影响的因素。

  我们把影响软件质量的因素分成三组,分别反映用户在使用软件产品时的是三种不同倾向或观点。这三种倾向是:产品运行、产品修改和产品转移。如下图:

  ①精确度量:使用质量度量评价准则进行详细度量,工作量大,但度量精确度也高;

  ②全面度量:可以与简易度量并用对各个质量设计评价准则进行度量,工作量可以控制在一定的范围内。

  ①精确度量:使用质量度量评价准则进行详细度量,工作量大,但度量精确度也高;

  ②全面度量:可以与简易度量并用对各个质量设计评价准则进行度量,工作量可以控制在一定的范围内。

  u  软件能力成熟度模型CMM(Capability Maturity Model)是由美国卡内基-梅隆大学软件工程研究所(CMU/SEI)推出的评估软件能力与成熟度的一套标准,该标准基于众多软件专家的实践经验。

  软件过程成熟度是指某个具体软件过程被明确定义、管理、度量和控制的有效程度。成熟意味着软件过程能力持续改善的过程,成熟度代表软件过程能力改善的潜力。

  CMM将软件过程的成熟度分为5个级别(MaturityLevels),如图所示,5个等级分别是:

  软件过程的特点是无秩序的,甚至是混乱的。企业一般不具备稳定的软件开发与维护环境。项目成功与否在很大程度上取决于是否有杰出的项目经理和经验丰富的开发团队。此时,项目经常超出预算和不能按期完成,组织的软件过程能力不可预测。

  建立基本的项目管理过程来跟踪成本、进度和功能特性。组织建立了管理软件项目的方针以及为贯彻执行这些方针的措施。组织基于在类似项目上的经验对新项目进行策划和管理。组织的软件过程能力可描述为有纪律的,并且项目过程处于项目管理系统的有效控制之下。因为软件项目的计划和跟踪是稳定的,并能重复以前的成功。

  已将管理和工程活动两方面的软件过程文档化、标准化,并综合成该机构的标准软件过程。组织形成了管理软件开发和维护活动的组织标准软件过程,包括软件工程过程和软件管理过程。项目依据标准定义自己的软件过程进行管理和控制。

  组织的软件过程能力可描述为标准的和一致的,因为无论是软件工程活动还是管理活动,过程是稳定的和可重复的。对软件质量也进行了跟踪。项目的这种过程能力是建立在整个机构对项目定义的软件过程中的活动、任务和职责具有共同的理解的基础上的。

  组织对软件产品和过程都设置定量的质量目标。项目通过把过程性能的变化限制在可接受的范围内,实现对产品和过程的控制。组织的软件过程能力可描述为可预测的,软件产品具有可预测的高质量。

  在优化级,组织通过预防缺陷、技术创新和更改过程等多种方式,不断提高项目的过程性能以持续改善组织软件过程能力。组织的软件过程能力可描述为持续改善的。

  Ø  要达到一个成熟度等级,必须实现该等级上的全部关键过程区域。要实现一个关键过程区域,就必须达到该关键过程区域的所有目标。

  Ø  此外,只有实现了下一成熟度等级的所有关键过程域的目标,才能实施高一级成熟度等级的关键过程域的活动。

  ①可重复级关键过程域集中关注从非软件工程化向软件工程化转变初期必须做好的事情。其中包括它的6个关键过程域。

  ②已定义级中的关键过程域既涉及项目,又涉及组织,这是因为组织建立了对所有项目都有效的软件工程过程和管理过程的规范化基础设施。该等级包括7个关键过程域。

  ③已管理级中的关键过程域的主要任务是,为软件过程和软件产品建立一种可以理解的定量的方式。该等级中有两个关键过程域,即定量过程管理和软件质量管理。

  ④优化级有3个关键过程域,主要涉及的内容是软件组织和项目中如何实现持续不断的过程改进。

  不同成熟度级别中的关键过程域执行的具体实践不同。这些实践分别组成关键过程域的5个属性,即5个共同特性。

http://nzrimfire.com/goujiancunchuku/493.html
锟斤拷锟斤拷锟斤拷QQ微锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷微锟斤拷
关于我们|联系我们|版权声明|网站地图|
Copyright © 2002-2019 现金彩票 版权所有