大学软件工程总结
大学软件工程总结
2013年7月9日软件工程复习总结
前言
软件工程在我整个大学的课程里是选修课，学的是电子工业出版社的《软件工厂--方法与实践 第2版》
软件工程呢，我觉得是一门很需要实践的学科，光靠这样简单地靠老师讲或者看看书是学不到什么东西的。软件工程涉及到很多内容，其中软件项目管理也包括了。概念性东西很多，一些专业术语和名词在整个软件工程中也频繁地出现了。其中近些年比较火的技术领域，面向服务的软件架构和云计算。云计算这个名词，我想IT界的从业人员并不陌生，已经不是什么新鲜东西，不过近些年确实是被捧得水深火热了，我都想尽快涉足这个领域当中去。因为这就是趋势，云服务、云存储等改变了软件行业的格局，对传统的软件开发商是一个很大的冲击，我想会有越来越多的软件开发商会提供这样的服务。原因很简单，它是一个双赢的模式。不过这也是我浅薄的看法，关于云计算并不是简单就能说清楚的东西，我觉得它是技术上的创新，它能给人类带来很多的好处。
当然，这个世界上没有完全完美的东西，双面性在云计算也有体现，云计算为我们节省了成本，节约了劳动力，那么也会丧失一些就业机会，我也不清楚中国现在的格局是怎样。还有就是，云计算是一个绝对安全的东西么，我们把所有的数据都放在云中，集中在一起真的没问题么。关于隐私问题，现在的我们随时随地都可以被一些云计算公司搜集到信息，在网上可以很轻易找到一个人各种信息，包括很多我们不希望被别人知道的信息。这又如何解决呢。总之，好东西都是需要经过锤炼的，不过我相信云计算肯定是利大于弊的东西，我很期待未来的信息化世界。
软件工程知识点总结
有以下知识点（考试内容，当然不止这些）
1. 软件工程的定义
2. 软件生存周期
3. 软件过程模型
4. 需求分析的定义、获取
5. 常见的软件体系结构（B/S 、C/S 、软件总线中间件）
6. SOA 的定义、特点、和工作模型（松耦合、明确定义的接口）
7. 云计算的定义、优势和应用模型
8. 软件测试的概念、原则、方法和测试策略
9. 软件维护的类型
10.软件项目管理的管理过程和领域
11.成本估算模型、进度计划的方法
12. 风险管理、质量管理的概念
13.CMM（软件能力成熟度模型）
第一章
1. 软件工程的定义：（P3）
软件工程是一门指导软件开发的工程学科，它以计算机理论及其他相关学科的理论为指导，采用工程化的概念、原理、技术和方法进行软件的开发和维护，把经实践证明的科学的管理措施与最先进的技术方法结合起来。软件工程研究的目标是“以较少的投资获取高质量的软件”。
2. 软件生存期（P5）
软件生命周期（SDLD）是指一个从用户需求开始，经过开发、交付使用，在使用中不断地增补修订，直至软件报废的全过程，亦称软件生存期（Life Cycle）。
软件生命周期分为以下阶段：
①可行性研究和项目开发计划。该阶段必须要回答的问题是“要解决的问题是什么”。
②需求分析。该阶段的任务不是具体地解决问题，而是准确地确定“软件系统必须做什么”，确定软件系统必须具备哪些功能。
③概要设计。概要设计就是设计软件的结构，该结构由哪些模块组成，这些模块的层次结构是怎样的，这些模块的调用关系是怎样的，每个模块的功能是什么。同时还要设计该项目的应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系等。
④详细设计。即对每个模块完成的功能进行具体描述，要把功能描述变为精确的、结构化的过程描述。
⑤编码。该阶段把每个模块的控制结构转换成计算机可接受的程序代码，即写成以某特定程序设计语言表示的“源程序”。
⑥测试。它是保证软件质量的重要手段，其主要方式是在设计测试用例的基础上检验软件的各个组成部分。测试分为，模块测试、组装测试、确认测试等。
⑦维护。软件维护是软件生存期中时间最长的阶段。已交付的软件投入正式使用后，便进入软件维护阶段，它可以持续几年甚至几十年。
在大部分文献中将生存期划分为5个阶段，即 要求定义、设计、编码、测试及维护。其中 要求定义阶段包括可行性研究和项目开发计划及需求分析，设计阶段包括概要设计和详细设计。
为了描述软件生存期的活动，提出了多种生存期模型，如瀑布模型、循坏模型、螺旋模型、喷泉模型、智能模型等。
3. 目前常见的软件过程模型如下：瀑布模型、增量模型、螺旋模型、喷泉模型、智能模型等。
1) 瀑布模型
优点：在软件工程的第一阶段，瀑布模型得到了广泛的应用，它简单易用，在消除非结构化软件，降低软件的复杂性，促进软件开发工程化方面起了很大的作用。
缺点：由于瀑布模型是一种理想的线性开发模式，它将一个充满回溯的软件开发过程硬性分割为几个阶段，无法解决软件需求不明确或者变动的问题。这些缺点对软件开发带来了严重影响，由于需求不明确，会导致开发的软件不符合用户的需求而夭折。
2) 增量模型(incremental model)
- 增量模型是一种非整体开发的模型。是一种进化式的开发过程。
-
根据增量的方式和形式的不同，分为：
- 基于瀑布模型的渐增模型
- 基于原型的快速原型模型
该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。
增量模型和瀑布模型之间的本质区别是什么？
增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。而增量模型属于非整体开发模型，它推迟某些阶段或所有阶段中的细节，从而较早地产生工作软件。
一般的增量模型如下：
3)螺旋模型
对大型软件,需要多个原型描述系统的生存期，螺旋模型将瀑布模型与原型化模型结合起来,并加入了风险分析。
该模型将开发过程分为几个螺旋周期，每个螺旋周期可分为4个工作步骤：
①制定计划：确定目标、方案和限制条件；
②风险分析：评估方案、标识风险和解决风险；
③实施工程：开发确认产品；
④客户评估：计划下一周期工作。
一般的螺旋模型如下图：沿着螺旋线每转一圈，表示开发出一个更完善的新的软件版本。如果开发风险过大，开发机构和客户无法接受，项目有可能就此中止；多数情况下，会沿着螺旋线继续下去，自内向外逐步延伸，最终得到满意的软件产品。
4) 喷泉模型
喷泉模型以面向对象的软件开发方法为基础，以用户需求作为喷泉模型的源泉。如下图：
6. 喷泉模型是对象驱动的过程，对象是所有活动作用的实体，也是项目管理的基本内容。
7. 喷泉模型在实现时，由于活动不同，可分为系统实现和对象实现，这既反映了全系统的开发过程，也反映了对象族的开发和重用过程5）智能模型
智能模型也称为基于知识的软件开发模型，是知识工程与软件工程在开发模型上结合的产物，以瀑布模型与专家系统的综合应用为基础建立的模型，该模型通过应用系统的知识和规则帮组设计者认识一个特定的软件的需求和设计，这些专家系统已成为开发过程的伙伴，并指导开发过程。
从图中可以清楚地看到，智能模型与其他模型不同，它的维护并不在程序一级上进行，这样就把问题的复杂性大大降低了。
智能模型的主要优点有：
① 通过领域的专家系统，可使需求说明更加完整、准确和无二义性。
② 通过软件工程的专家系统，提供一个设计库支持，在开发过程中成为设计的助手。
③ 通过软件工程知识和特定应用领域的知识和规则的应用来提供开发的帮助。
但是，要建立合适于软件设计的专家系统，或建立一个既适合软件工程由适合应用领域的知识库都是非常困难的。目前，在软件开发中正在使用AI技术，并已取得局部进展；例如在CASE工具系统中使用专家系统，又如使用专家系统实现测试自动化。
第二章
1.需求分析的定义
在传统软件工程生命周期中，涉及软件需求的阶段称做需求分析。
2.需求工程的定义
需求工程是一个包括创新和维护系统需求文档所必须的一切活动，是对系统应该提供的服务和所受到的约束进行理解、分析、检验和建立文档的过程。
3. 需求的获取和分析
需求的获取和分析是需求工程的关键和核心步骤，直接影响到后期的开发工作和系统的成败。
·需求获取
在深入实际调查研究，充分理解用户需求的基础上，获取系统需求。获取过程为：
①了解领域知识，工程技术人员需要依靠领域专家，学习和理解相关的专业知识，才能正确抽取用户需求。
②需求收集，与项目相关人员进行沟通，在进一步了解专业领域的基础上，发现系统需求的过程。
·需求分析
需求分析的过程是对收集到的需求进行提炼、分析和审查的过程，最终确定需求，并确保所有项目相关人员对需求取得一致性认识。分析阶段的主要工作包括：
①确定系统范围。确定系统与其他外部实体或其他系统的边界和接口。
②分类排序。对所收集的需求进行重新组织、整理、分类和筛选，并对每类需求进行排序，确定哪些是最重要的需求。
③建立需求分析模型。这是分析阶段的核心工作。需求分析模型是对需求的主要描述手段，是根据不同的分析方法建立的各种视图，例如数据流图（DFD）、实体关系图（E-R）、用例图（Use Case）、类图、状态图、各种交互图等。还可建立辅助的说明，如数据词典。
④建立需求规格说明。软件需求规格说明（Software Requirement Specification,SRS）是将需求的结果按照不同开发方法规定的格式用图形和文档形式描述出来。需求规格说明在整个开发过程中具有很重要的作用，是用户和开发人员之间进行交流和理解系统的手段。用户通过需求规格说明检查是否符合和满足所提出的全部需求。开发者则通过需求规格文档，了解和理解所开发系统的内容，并以此作为软件设计和软件测试的依据。项目管理人员以它为依据，规划软件开发过程、计划，估算软件成本和控制需求的变更过程。
第三章
·软件体系结构设计
仓库模型（The repository model）
也称“容器模型 ”，是一种集中式的模型。在这种结构模型当中，应用系统用一个*数据仓库来存储各个子系统共享的数据，其它的子系统可以直接访问这些共享数据。当然，每个子系统可能会有自己的数据库。为了共享数据，所有的子系统之间紧密耦合的，并且围绕*数据仓库，如下图：
仓库模型的主要优点：
①数据由一个子系统产生，并且被另外一些子系统共享；
②共享数据能得到有效的管理，各子系统之间不需要通过复杂的机制来传递共享数据。
③一个子系统不必关心其他的子系统是如何使用它产生的数据的。
④所有的子系统都拥有一致的基于*数据仓库的数据视图。如果新子系统也采用相同的规范，则将它集成与系统中是容易的。
仓库模型的主要缺点：
①为了共享数据 ,各子系统必须有一致的数据视图 ，不可避免地会影响了整个系统的性能。
②一个子系统发生了改变，它产生的数据结构也可能发生改变。为了其他共享的目的，数据翻译系统会被用到。但这种翻译的代价是很高的，并且有时是不可能完成的。
③*数据仓库和各子系统拥有的数据库必须有相同的关于备份、安全、访问控制和恢复的策略，这可能会影响子系统的效率。
④集中式的控制使数据和子系统的分布变得非常困难甚至成为不可能。这里分布指的是将数据或子系统分散到不同的机器上。
一般来说，命令控制系统、CAD系统等常采用这种结构。
分布式结构
分布式结构有如下一些优势：
①资源共享：系统中每个服务结点上的资源都可以被系统中的其他结点访问。
②开放性高：系统可以方便地增删不同软、硬件结构的结点。
③可伸缩性好：系统可以方便的增删新的服务资源以满足需要。
④容错能力强：分布式系统中的信息冗余可以容忍一定程度的软、硬件故障。
⑤透明性高：系统中的结点一般只需知道服务的位置而不必清楚系统的结构。
分布式结构有如下一些不足：
①复杂性：分布式系统比集中式系统要复杂的多。集中式系统的性能主要依赖于主机的处理能力，而分布式系统的性能则还要依赖于网络的带宽，这让情况变得更加复杂。
②安全性：网络环境随时面临着各种威胁，如病毒、恶意代码、非法访问等，如何保证安全性是一个让人头痛的问题。
③可管理性：分布式系统的开放性造成了系统的异构性，显而易见，管理异构的系统比管理主机系统要困难得多。
④不可预知性：这主要指系统的响应时间。网络环境本身的特点决定了网络负载会明显地影响整个系统的响应时间。
下面主要讨论几种不同的分布式结构.
1)客户-服务器模型（Client/Server Architectural Model）
客户-服务器结构（Client/ServerArchitecture）是一种典型的分布式结构。典型的客户-服务器C/S 结构的系统包括三个组成部分：
①服务器（Server）:多个独立的服务器为系统提供诸如Web、文件共享、打印等服务。
②客户（Client）:多个并发客户应用访问多个服务器提供的服务，每个客户应用都是独立的同样的客户应用可以同时有多个实例。
③网络（Network）:客户和服务器通过网络连接在一起。这是C/S结构的常用模式。有时客户应用和服务器应用会在同一台机器上运行，但两个应用还是要通过本机的网络协议进行通信，其效果就像在不同的机器上运行一样。
C/S 结构的应用都由三个相对独立的逻辑部分组成：
①用户界面部分：数据表示层，实现与用户交互。
②应用逻辑部分：业务逻辑层，进行具体运算和数据处理；
③数据访问部分：数据访问层，完成数据查询、修改、更新等任务。
以上三种逻辑之间的关系如下图：
根据应用逻辑层所处的位置，C/S 结构的应用系统常可以分为两层结构、三层/多层应用结构。
1)两层客户-服务器模型（Two Tier Client/ServerArchitectural Model）
在两层C/S 结构中，应用系统有两个典型的应用组成，其中一个是主要负责用户界面部分的客户端，另一个是主要负责数据访问的服务器，两者通过网络进行数据交换。其结构如下图：
现在举数据库应用的例子来说明两层C/S结构的工作方式。
客户应用工具需求向数据库服务器发出数据访问请求，数据库服务器会响应这个请求，查询、更新数据，然后将结果返回给客户端。这是典型的“请求-响应-得结果”模式。当然，不是所有的请求都需要返回结果。实际上，C/S 的工作模式是一种远程过程调用（Remote Procedure Call, RPC）模式。允许客户端和服务器端有不同的软硬平台。
·完整的应用包含三个相对独立的逻辑部分，而两层的C/S结构只有两个端应用。应用逻辑应该映射到哪一端上呢？三种情况：
在上图中：
C/S 应用1的结构中，客户端应用负责用户界面和应用逻辑部分，因此他的工作比较繁重。这种结构往往被称为胖客户端（Fat-Client）结构，一般的数据库应用都是属于这种结构的。以此相反，
C/S 应用3的结构中，服务器负责了更多的工作，而客户端的工作就变得非常单纯。这种结构成为瘦客户（Thin-Client）结构。浏览器/Web 服务器结构就属于瘦客户结构，而且常被称为Browser/Server(B/S)结构。
不过，越来越多的B/S应用包含了一些可以迁移的代码，例如包含客户端脚本的网页，这些代码从服务器端下载到客户端并在客户端执行，这样一来，客户端也或多或少地要处理一部分的应用逻辑。这种B/S结构实际上介于胖客户和瘦客户结构之间，就如上图中的C/S 应用2的结构。
由于两层C/S 架构将数据表示和处理逻辑分开，这样，客户端和服务器的功能相对来说就比较单一，两端的维护和升级也比集中式结构简单。
但C/S 架构也存在着明显的缺陷：
由于应用逻辑和两端之一是紧耦合的，因此当它发生改变时，不是客户端就是服务器也要跟着做出相应的改变，同时这种改变极有可能会影响到另一端。因此，C/S 架构不适合用在多用户、多数据库、非安全的网络环境中。另外，客户端应用程序越来越大，对使用者的要求也越来越高。
3）三层/多层应用模型(Three/Multi Tier Model)
第一级是数据库管理结点(databasemanagement node)。
第二级或中间级是“商业逻辑结点” (business logic node),是指具体应用中实施的 程序逻辑和法则。
第三级是用户界面级，强调高效、方便易用的用户界面。
在下图所示的多层应用模型中，为了有效地管理那些完成业务逻辑的组件，中间层会用到应用服务，包括事务服务、消息服务等。常见的事务服务器有Microsoft Transaction Server，消息服务器有Microsoft Message Queue。
常见的三层结构应用有浏览器-Web服务-数据服务结构。这是一种典型的B/S结构。在这种结构中，
客户应用是一个通用的浏览器，如 Microsoft Internet Explorer(IE),它完成网页的显示和客户端脚本的远行；
Web服务器，如Microsoft Internet Information Server,它响应客户的网页访问请求，运行服务端脚本，并通过Microsoft ADO组件对象向数据库服务器发出数据请求；
数据库服务器，如Microsoft SQL Server ,响应数据请求并返回结果。
·多层应用模型的优点相当的明显：
①客户端的功能单一，变得更“瘦”。
②每一层可以被单独改变，而无须其他层的改变。
③降低了部署与维护的开销，提高了灵活性、可伸缩性。
④应用程序各部分之间松散耦合，从而使应用程序各部分的更新相互独立。
⑤业务逻辑集中放在服务器上有所有用户共享，使得系统的维护和更新变得简单，也更安全。
4) 分布式对象结构(Distributed Objects Architecture)
采用分布式对象结构 ：
·服务的提供者是被称为“对象(Object)”的系统组件(System Component)。
·每个对象在逻辑上是平等的，它们可以互相为对方提供所需的服务。
·提供服务的对象就是服务器，而提出服务请求的对象就是客户。
·为了能够提供服务，每个对象都有一个服务接口。
下图是分布式对象结构：
分布式对象结构的另一个重要特点是，对象可能分布在网络的各个结点上而不是集中在一台硬件服务器上。为了将分散的对象提供的服务“串”起来，一种被形象地称为“软件总线（Software Bus)”的中间件起了关键的作用。
由于分布式对象结构具有相当好的开放性和透明性，用户可以非常方便地在总线上添加或者删除组件对象，从而完成增加、更新或删除功能。
“软件总线(Software Bus)”的中间件(Middleware) ，即对象请求代理(Object Request Broker，简称ORB) 。
1 、CORBA(Common Object Request BrokerArchitecture)
公共对象请求代理体系结构。由对象管理组织OMG （Object Management Group）提出的应用软件体系结构和对象技术规范。
2、DCOM(Distributed Component ObjectModel)
组件对象模型。为组件之间、组件与应用程序之间的通信和互操作提供了统一的标准和技术规范，使不同语言开发的组件可进行基于组件的软件开发。
3、 EJB（Enterprise Java Bean）
由Sun公司定义的规范，EJB构件是实现EJB规范的Java构件，完成企业级应用中的业务逻辑。EJB构件驻留在EJB容器中。
5) 中间件（Middleware）
现代应用系统具有如下的一些特点：
①分布性。整个任务不只是在单机上运行，而是由网络中多台计算机上的相关应用共同协作完成，这需要考虑网络传输、数据安全、数据一致性、同步等诸多问题。
②异构性。支撑应用的计算机硬件、操作系统、网络协议、数据库系统，以及开发工具种类繁多，需要考虑数据表示、调用接口、处理方式等诸多问题。
③动态协作性。参与协作的应用允许位置透明性、迁移透明性、负载平衡性等需求。
④应用程序各部分之间松散耦合，从而使应用程序各部分的更新相互独立。
⑤业务逻辑集中放在服务器上有所有用户共享，使得系统的维护和更新变得简单，也更安全。
应用中间件系统可以满足现代系统的需要。中间件是一种处于系统软件（操作系统和网络软件）与应用软件之间的软件，它能使应用软件之间进行跨网络的协同工作（也就是互操作），并允许个应用软件所涉及的“系统结构、操作系统、通信协议、数据库和其他应用服务”各不相同。
·中间件按其应用领域分为以下6种：
①远程过程调用中间件
②分布式对象中间件
③数据库访问中间件
④事务处理中间件
⑤消息中间件
⑥其他中间件
补充内容:面向服务的软件架构（PPT）
1. 面向服务的体系结构（service-oriented architecture，SOA）的定义
面向服务的体系结构（service-orientedarchitecture，SOA）是一个构件模型，它将应用程序的不同功能单元（称为服务）通过定义良好的接口和契约联系起来。
·接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
2. 服务（service）是封装成用于业务流程的可复用构件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。
3. SOA的特点
·松耦合
①在该体系架构中，客户端不和任何服务器相关联，它只和服务相联系，所以客户端和服务器的集成不影响客户端应用程序。
②无论老的或者新的功能模块都可以被封装成服务构件被发布。
③功能构件和它们的接口分离，所以新的接口可以非常方便地插入。
④在复杂的应用程序里，业务过程的控制可以被隔离：引入一个业务规则引擎用来控制已经定义好的业务过程流。引擎根据工作流的状态调用各种不同的服务。
⑤服务可以在运行时动态地合成进来。
⑥通过配置文件进行绑定，所以可以非常容易地适应各种新的需要。
·明确定义的接口
·服务交互必须是明确定义的
·Web 服务描述语言（Webservices Description Language，WSDL）是受到广泛支持的方法，用于描述服务请求者所要求的绑定到服务提供者的细节
· 服务
·调用操作的消息
·构造这种消息的细节
· 关于向何处发送用于构造这种消息的处理细节的消息的信息
· 无状态的服务设计
· 服务应该是独立的、自包含的请求，在实现时它不需要从一个请求到另一个请求的信息或状态
·服务不应该依赖于其他服务的上下文和状态。当需要依赖时，它们最好定义成通用业务流程、函数和数据模型
补充内容:云计算（PPT）
1. 云计算的定义
云计算（Cloud Computing ）：是分布式处理(Distributed Computing)、并行处理(ParallelComputing)和网格计算(Grid Computing)的发展，或者说是这些计算机科学概念的商业实现。是指基于互联网的超级计算模式--即把存储于个人电脑、移动电话和其他设备上的大量信息和处理器资源集中在一起，协同工作。在极大规模上可扩展的信息技术能力向外部客户作为服务来提供的一种计算方式。
2. 云计算的优势：
①开发容易快速
②无多余的开支
③每月花费低
④IT人员减少，费用降低
⑤提供最新的技术和功能
⑥支持、推行IT标准
⑦系统和信息共享更容易
3. 云计算的应用模型
·云计算三种服务方式
·SAAS（ Software as a Service ）
·PAAS（Platform as a Service ）
·IAAS（Infrastructure as a Service ）
云计算的应用—IAAS（Infrastructure as a Service）
实现模式
·完全操作系统（软硬件）接入
·防火墙
·路由器
·负载平衡
优势
·节省费用/所付及所用
·即时升级
·安全
·可靠
·APIs
实例
当你想运行成批的程序组，但是没有合适的软硬件环境，可使用Amazon的EC2。
当你想在网络上发布一个短期（几天到几个月）的网站，可使用Flexiscale。
云计算的应用—PAAS（ Platform as a Service ）
实现模式
·平台价格昂贵
·需求估算不科学
·平台管理复杂麻烦
流行的服务
·存储
·数据库
·扩展性
优势
·节省费用/所付及所用
·即时升级
·安全
·可靠
·APIs
实例
当你想把一个大容量的文件上传到网络上，允许35000个用户使用2个月的时间，可使用Amazon的Cloud Front即时升级。
当你想在网络上存储大量的文档，但是你没有足够的存储空间，可使用Amazon的S3。可靠。
云计算的应用—SAAS（ Software as a Service ）
实现模式
·在中小企业盛行
·无需管理软硬件
·服务通过浏览器实现
优势
·无浪费费用
·即时扩展
·安全
·可靠
·APIs
实例
·CRM
·财务计划
·HR
·文字处理
云计算的应用
IaaS、PaaS & SaaS共性
·无浪费费用
·即时扩展
·安全
·可靠
·APIs
优势
·用户花费低
·减少底层管理职责
·允许意想不到的资源装载
·业务应用实现迅速
风险
·安全性
·宕机问题
·接入问题
·独立性
·协同互动问题
第七章 软件测试
1. 软件测试的概念
2. 软件测试的原则
· Davis 提出了一组指导软件测试的基本原则：
①所有的测试都应根据用户的需求来进行。
②应该在测试工作真正开始前的较长时间内就进行测试计划（测试规划）的编写。一般而言，测试计划可以在需求分析完成后开始，详细的测试用例定义可以在设计模型被确定后立即开始，因此，所有测试可以在任何代码被编写前进行计划和设计。
③Pareto 原则应用于软件测试。Pareto 原则意味着测试发现的80%的错误很可能集中在20%的程序模块中。
④测试应从“小规模”开始，逐步转向“大规模”。即从模块测试开始，再进行系统测试。
⑤穷举测试是不可能的，因此，在测试中不可能覆盖路径的每一个组合。然而，充分覆盖程序逻辑，确保覆盖程序设计中使用的所有条件是有可能的。
⑥为达到最佳的测试效果，提倡由第三方来进行测试。
·其他的测试原则：
①在设计测试用例时，应包括合理的输入条件和不合理的输入条件
②严格执行测试计划，排除测试的随意性
③应当对每一个测试结果做全面检查
④妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便
⑤检查程序是否做了应做的事仅是成功的一半，另一半是检查程序是否做了不该做的事。
⑥在规划测试时不要设想程序中不会出错误
3. 测试用例的设计方法大体可分为两类
白盒测试/白箱测试
把测试对象看作一个透明的盒子，根据程序内部的逻辑结构及有关信息设计测试用例
黑盒测试/黑箱测试
把测试对象看做一个黑盒子，完全不考虑程序内部的逻辑结构和内部特性
4. 白盒测试
又称结构测试、逻辑驱动测试或基于程序的测试
把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作。
主要用于对模块的测试
白盒法常用的测试方法
①基本路径覆盖测试
根据程序或设计图画出控制流图，并计算其区域数，然后确定一组独立的程序执行路径，最后为每一条基本路径设计一个测试用例
②逻辑覆盖测试
考察使用测试数据运行被测程序时对程序逻辑的覆盖程度
通常希望选择最少的测试用例来满足所需的覆盖标准
语句覆盖：每个可执行语句都至少执行一次
判定覆盖：每个判定的每个分支至少经过一次
条件覆盖：每个判定中的每个条件的所有可能结果都至少出现一次
判定－条件覆盖：每个判定的所有可能结果都至少执行一次，并且，每个判定中的每个条件的所有可能结果都至少出现一次
条件组合覆盖：每个判定中条件结果的所有可能组合都至少出现一次
路径覆盖：每条可能执行到的路径都至少经过一次（如果程序中包含环路，则要求每条环路至少经过一次）
③数据流测试
·根据程序中变量的定义（赋值）和引用位置来选择测试用例
④循环测试
·简单循环、嵌套循环、串接循环和非结构循环
⑤检查程序是否做了应做的事仅是成功的一半，另一半是检查程序是否做了不该做的事。
⑥在规划测试时不要设想程序中不会出错误
5. 黑盒测试
黑盒法是把测试对象看做一个黑盒，测试时完全不考虑程序内部的逻辑结构与内部特性，只需根据需求规格说明书，测试程序的功能或程序的外部特性，因此黑盒发又称为功能测试或数据驱动测试。
黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误：功能不对或遗漏；性能错误；初始化和终止错误；界面错误；数据结构或外部数据库访问错误。
黑盒法的主要测试方法：
①等价分类法
·将所有可能的输入数据划分成若干个等价类，然后在每个等价类中选取一个代表性的数据作为测试用例
②边界值分析法
·挑选那些位于边界附近的值作为测试用例
③错误推测法
·凭以往的经验和直觉推测程序中某些可能存在的各种错误，从而针对性地设计测试用例
④因果图法
·既考虑输入条件的组合关系，又考虑输出条件对输入条件的依赖关系
⑤比较测试法
分别开发二个软件版本，用相同的测试用例对二个版本的软件分别进行测试，比较其测试结果
6.软件测试的策略
·单元测试
单元测试（UnitTesting）,也称模块测试（Module Testing）。测试的主要目的是检查模块内部的错误。因此，测试方法应以白盒法为主。
单元测试的内容
①模块接口
②局部数据结构
③重要的执行路径
④边界条件
⑤错误处理
·单元测试步骤：
由于被测试的模块往往不是独立的程序，它处于整个软件结构的某一层位置上，被其他模块调用或调用其他模块，其本身不能单独运行，因此在单元测试时，需要为被测试模块设计若干辅助测试模块。辅助模块有两种
一种是驱动模块(driver),用以模拟主程序或者调用模块的功能，用于向被测模块传递数据，接收、打印从被测模块返回的数据。一般只设计一个驱动模块。
另一种是桩模块（stub）,用于模拟那些由被测模块所调用的下属模块的功能，可以设计一个或者多个桩模块，才能更好地对下属模块进行模拟。
·集成测试（Integrated Testing）
集成测试（IntegratedTesting）是指在单元测试的基础上，将所有模块按照设计要求组装成一个完整的系统而进行的测试，也称为联合测试或组装测试。重点测试模块的接口部分，需设计测试过程所使用的驱动模块或桩模块。测试方法以黑盒法为主
集成的方式
·非渐增式测试
非渐增式测试方法采用一步到位的方法来集成系统。首先对每个模块分别进行单元测试，然后再把所有的模块按设计要求组装在一起进行测试。
非渐增式是将所有的模块一次连接起来，简单、易行，节省机时，但测试过程中难于查错，发现错误也很难定位，测试效率低。
·渐增式测试
它的集成式逐步实现的，组装测试也是逐步完成的，也可以说它把单元测试与组装测试结合起来进行的。该测试是逐个把未经过测试的模块组装到已经测试过得模块上去，进行组装测试，每加入一个新模块进行一次集成的测试。重复此过程直至程序组装完毕。
在增量集成测试过程中发现的错误，往往与新加入的模块有关。
增量式集成又可分为自顶向下结合和自底向上结合
α测试和β测试
α测试是邀请某些有信誉的软件用户与软件开发人员一道在开发场地对软件系统进行测试，其测试环境要尽量模拟软件系统投入使用后的实际运行环境。在测试过程中，软件系统出现的错误或使用过程中遇到的问题，以及用户提出的修改要求，均要由开发人员完整、如实地记录下来，作为对软件系统进行修改的依据。α测试的整个过程是在受控环境下，由开发人员和用户共同参与完成的。α测试的目的是评价软件的FLURPS，其中FLURPS 表示对一下项目的测试:
①Function Testing(功能测试)
②Local Area Testing(局部化测试)
③Usability Testing(可使用性测试)
④Reliability Testing (可靠性测试)
⑤Performance Testing (性能测试)
⑥Supportability Testing(可支持性测试)
β测试是由软件产品的全部或部分用户在实际使用环境下进行的测试。整个测试活动是在用户的独立操作下完成的，没有软件开发人员的参与。β测试是投入市场前由支持软件预发行的客户对FLURPS 进行测试，主要目的是测试系统的可支持性。β测试的涉及面最广，最能反映用户的真实愿望，但花费的时间最长，不好控制。一般地，软件公司与β测试人员之间有一种互利的协议。即β测试人员无偿地为软件公司做测试，定期递交测试报告，提出批评与建议。而软件公司将向β测试人员免费赠送或以很大的优惠价格提供软件的正式版本。
综合测试策略
一般都应该先进行静态分析，再考虑动态测试。
1) 单元测试
通常应该先进行“人工走查”，再以白盒法为主，辅以黑盒法进行动态测试。使用白盒法时，只需要选择一种覆盖标准，而使用黑盒法时，应该采用多种方法。
2) 组装测试
关键是要按照一定的原则，选择组装模块的方案（次序），然后再使用黑盒法进行测试。在测试过程中，如果发现了问题较多的模块，需要进行回归测试时，再采用白盒法。
3) 确认测试、系统测试
应该以黑盒法为主。确定测试中进行软件配置复查，主要是静态测试。
第九章 软件维护
1.软件维护的类型
软件维护是指软件系统交付使用以后，为了改正错误或满足新的需求而修改软件的过程。按照不同的维护目的，维护工作可分成4类。
完善性维护（Perfective Maintenance）
这种扩充软件功能、增强软件性能、提高软件运行效率和可维护性而进行的维护活动称为完善性维护。
此项维护的策略是，可以使用功能强、使用方便的工具，或采用原型化方法开发的等。
适应性维护（Adaptive Maintenance）
适应性维护是为了适应计算机的飞速发展，使软件适应外部新的硬件和软件环境或者数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）发生的变化，而进行修改软件的过程。
它主要的维护策略是，对可能变化的因素进行配置管理，将因环境变化而必须修改的部*部化，即局限于某些程序模块等。
纠错性维护（Corrective Maintenance）
对在测试阶段未能发现的，在软件投入使用后才逐渐暴露出来的错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程称为纠错性维护。
它主要的维护策略是，开发过程中采用新技术，利用应用软件包，提高系统结构化程度，进行周期性维护审查等。
预防性维护（Preventive Maintenance）
预防性维护是为了提高软件的可靠性和易维护性，采用先进的软件工程方法对需要维护的软件或软件中的某一部分重新进行设计、编制和测试，为以后进一步维护和运行打好基础。也就是软件开发组织选择在最近的将来可能变更的程序，做好变更它们的准备。
它主要的维护策略主要是采用提前实现、软件重用等技术。
第十章 软件项目管理
1.软件项目管理的管理过程和领域
项目管理的9个知识领域、5个过程组、和44个过程之间的相互关系可以通过下表来表示：
·软件项目管理过程
软件项目管理，是对整个软件生存期的所有活动进行管理。主要过程包括：
①项目启动
确定系统范围、组建项目团队、建立项目环境。
②项目规划
确定项目活动、项目成本估算、制定进度计划
③项目实施
监控项目执行、管理项目风险、控制项目变更
④项目收尾
项目验收、软件安装培训、项目总结
项目管理的主要活动
1、软件项目的规划
·可行性分析
·软件成本估算
·软件计划
2、人员的组织管理
·人员配备原则
·人员配备模式
·软件团队建设
·软件项目沟通活动
3、软件风险管理
·风险识别
·风险分析
·风险规划
·风险监控
4、 软件配置管理
是为了有效地控制和管理软件开发过程中的变化，进行标识、组织和控制修改的技术。
配置管理活动：
·配置项的标识
·版本管理
·系统构建
·变更控制
2.成本估算模型
·软件成本估算通常是估算软件的下列特性。
①源代码行（LOC）估算。源代码行是指机器指令行/非机器语言的执行步，使用它们可以作为度量生产率的基本数据。
②开发工作量估算。它是估算任何项目开发成本最常用的技术方法。根据项目开发过程，通常使用的度量单位是人月（PM）、人年（PY）或人日（PD）。
③软件生产率估算。它是指单位劳动量所能完成的软件数量，度量单位常用LOC/PM,￥/LOC或￥/PM。
④软件开发时间估算。在软件项目开发前必须进行估算。
·软件成本估算模型可分为两大类：理论模型和统计模型
·有代表性的软件开发成本估算模型：专家估算模型、IBM估算模型、Putnam 估算模型。
Ø 专家估算模型
其中:ai — 估计的最小行数 bi —估计的最大行数 mi — 最可能的行数
最后，通过与历史资料进行类比，推算出该软件每行源代码所需成本，将估算的源代码行数，乘以推算出的每行源代码所需成本，就得到该软件的成本估算值。
Ø IBM估算模型
估算公式：（其中：源代码行数L，以千行计）
工 作量： E=5.2*L （PM）
项目持续时间：D=4.1*L（月）
人员需要量： S=0.54*E （人）
文 档数： DOC=49*L （页）
IBM估算模型是一种静态单变量模型，它利用已估算的结果，如源代码行，来估算各种资源的需求量．
但IBM 估算模型不是一种通用模型，因此应用中应根据具体实际情况调整模型中的参数．
Ø Putnam估算模型
其中： L—源代码行数，K — 所需人力（PY） td— 开发时间,
CK —技术水平常数其值与开发环境有关。（差：2500-2000，正常：10000-8000，好：12500-11000）
由上述公式可以得到所需开发工作量的公式：
Ø COCOMO模型
² COCOMO模型是一种层次模型，按照其祥细程度分为三级：即基本的COCOMO模型、中间的COCOMO模型和详细的COCOMO模型。
² 该模型主要对工作量ＭＭ（单位：PM）和进度TDEP（单位：月）进行估算。模型中考虑到估算量与开发环境有关，将开发项目分为三类：
①组织型（Organic）：相对较小、较简单的软件项目。程序规模不是很大（小于5万行），开发人员对产品目标理解充分，经验丰富，熟悉开发环境。大多数应用软件及老的操作系统、编译系统属于此种类型。
②嵌入型（Embadded)：此种软件要求在紧密联系的硬件、软件和操作的限制条件下运行，通常与某些硬件设备紧密结合在一起，因此，对接口、数据结构,算法要求较高。如大型复杂的事务处理系统，大型、超大型的操作系统,军事指挥系统,航天控制系统等
③半独立型（Semidetached)：对项目要求界于上述两者之间,规模复杂度中等。最大可达30万行。如大多数事务处理系统、新操作系统,大型数据库,生产控制等软件属此种类型。
² 下面分别讨论三级COCOMO模型：
① 基本的COCOMO模型（静态单变量模型）
其中： MM — 工作量（PM），Kloc— 估计的源代码行
Cl—模型系数，a —模型指数 . Cl、a 取决于开发项目的模式为组织型、半独立型或嵌入型。
②中间的COCOMO模型
③详细的COCOMO模型
3.进度计划的方法
·描述计划进度的主要工具：一般的表格工具、甘特图、PERT技术与CPM方法。
4.项目风险管理
·风险的定义
风险（risk）是一种潜在的危险。软件项目由于其自身的特点而存在风险，甚至是灾难性的风险。
·软件项目风险管理过程：
项目风险管理主要包括：风险标识、风险估算、风险评价、风险监控和管理。
· 风险标识
1)项目风险(project)。与项目有关的预算、进度、人力、资源、用户需求、项目规模、复杂性等方面的问题。
2)技术风险（technical)。是指影响开发质量和交付时间的设计、实现、验证、维护、接口等方面的问题。
3)商业风险(business )。包括与产品的商业运作有关的市场风险、预算风险、决策风险、销售风险等。
·风险估算
也称为风险评估，一般是从两方面进行估算：
⑴从影响风险的因素考虑风险发生的可能性，即风险发生的概率。
⑵风险发生所带来的损失的严重程度，即评价若风险一旦发生所产生的后果。
·为了反映风险产生的可能程度和风险产生后果的严重程度，建立风险度量的指标体系，如一种简单的风险评估技术是建立风险评估表。
· 风险评价
风险评价是指在风险估算的基础上，对所确定的风险做进一步的确认。定义项目的风险参考水准，进一步验证风险评估结果的准确性，并按照风险发生概率高低和后果严重的程度进行排序。一般可定义成本、性能和进度是三个典型的参考量。
·风险监控和管理
一个有效的策略必须考虑风险避免、风险监控和风险管理及意外事件计划这样三个问题。风险的策略管理可以包含在软件项目计划中，或者风险管理步骤也可以组成一个独立的风险缓解、监控和管理计划。
⑴ 避免风险（avoidance）
这一种主动避免风险的活动。是在风险发生前分析引起风险的原因，采取措施，避免风险发生。
(2)风险监控
贯穿在软件开发的全过程，是一种项目跟踪活动。主要监控对项目风险产生主要影响的因素。
（3）风险管理监控计划
风险监控计划RMMP（Risk Management and Monitoring Plan）, 保证文档的正确性，按监控计划记录、管理风险分析的全过程。
5.软件质量保证
我们把影响软件质量的因素分成三组，分别反映用户在使用软件产品时的是三种不同倾向或观点。这三种倾向是：产品运行、产品修改和产品转移。如下图：
软件质量度量方法有以下三种：
①精确度量：使用质量度量评价准则进行详细度量，工作量大，但度量精确度也高；
②全面度量：可以与简易度量并用对各个质量设计评价准则进行度量，工作量可以控制在一定的范围内。
③简易度量：简易度量顾名思义就是对各个质量评价进行简单的工作量度量。
· 软件质量度量方法有以下三种：
①精确度量：使用质量度量评价准则进行详细度量，工作量大，但度量精确度也高；
②全面度量：可以与简易度量并用对各个质量设计评价准则进行度量，工作量可以控制在一定的范围内。
③简易度量：简易度量顾名思义就是对各个质量评价进行简单的工作量度量。
第11章 软件能力成熟度模型
1.CMM概述
u 软件能力成熟度模型CMM(Capability Maturity Model）是由美国卡内基-梅隆大学软件工程研究所(CMU/SEI)推出的评估软件能力与成熟度的一套标准，该标准基于众多软件专家的实践经验。
u CMM的主要用于：
①软件过程评估SPA（Software Process Assessment）
②软件过程改进SPI（Software Process Improvement）
③软件能力评价SCE（Software Capability Evaluation）
2.CMM的基本概念
·什么是软件过程
软件过程是指软件开发人员开发和维护软件及其相关产品所采取的一系列活动。
·什么是软件能力成熟度？
软件过程成熟度是指某个具体软件过程被明确定义、管理、度量和控制的有效程度。成熟意味着软件过程能力持续改善的过程，成熟度代表软件过程能力改善的潜力。
·软件过程的成熟度等级
CMM将软件过程的成熟度分为5个级别(MaturityLevels),如图所示，5个等级分别是：
Ø 初始级（Initial）
软件过程的特点是无秩序的，甚至是混乱的。企业一般不具备稳定的软件开发与维护环境。项目成功与否在很大程度上取决于是否有杰出的项目经理和经验丰富的开发团队。此时，项目经常超出预算和不能按期完成，组织的软件过程能力不可预测。
Ø 可重复级（Repeatable）
建立基本的项目管理过程来跟踪成本、进度和功能特性。组织建立了管理软件项目的方针以及为贯彻执行这些方针的措施。组织基于在类似项目上的经验对新项目进行策划和管理。组织的软件过程能力可描述为有纪律的，并且项目过程处于项目管理系统的有效控制之下。因为软件项目的计划和跟踪是稳定的，并能重复以前的成功。
Ø 已定义级（Defined）
已将管理和工程活动两方面的软件过程文档化、标准化，并综合成该机构的标准软件过程。组织形成了管理软件开发和维护活动的组织标准软件过程，包括软件工程过程和软件管理过程。项目依据标准定义自己的软件过程进行管理和控制。
组织的软件过程能力可描述为标准的和一致的，因为无论是软件工程活动还是管理活动，过程是稳定的和可重复的。对软件质量也进行了跟踪。项目的这种过程能力是建立在整个机构对项目定义的软件过程中的活动、任务和职责具有共同的理解的基础上的。
Ø 已管理级（Managed）
组织对软件产品和过程都设置定量的质量目标。项目通过把过程性能的变化限制在可接受的范围内，实现对产品和过程的控制。组织的软件过程能力可描述为可预测的，软件产品具有可预测的高质量。
Ø 优化级（Optimizing）
在优化级，组织通过预防缺陷、技术创新和更改过程等多种方式，不断提高项目的过程性能以持续改善组织软件过程能力。组织的软件过程能力可描述为持续改善的。
u 表描述了SW-CMM不同成熟度等级过程的可视性和过程能力。
3.CMM的内部结构
· 关键过程域
Ø 在CMM中一共有18个关键过程域，分布在2~ 5个级别中 。
Ø 要达到一个成熟度等级，必须实现该等级上的全部关键过程区域。要实现一个关键过程区域，就必须达到该关键过程区域的所有目标。
Ø 此外，只有实现了下一成熟度等级的所有关键过程域的目标，才能实施高一级成熟度等级的关键过程域的活动。
如上图所示，对关键过程域简单说明如下：
①可重复级关键过程域集中关注从非软件工程化向软件工程化转变初期必须做好的事情。其中包括它的6个关键过程域。
②已定义级中的关键过程域既涉及项目，又涉及组织，这是因为组织建立了对所有项目都有效的软件工程过程和管理过程的规范化基础设施。该等级包括7个关键过程域。
③已管理级中的关键过程域的主要任务是，为软件过程和软件产品建立一种可以理解的定量的方式。该等级中有两个关键过程域，即定量过程管理和软件质量管理。
④优化级有3个关键过程域，主要涉及的内容是软件组织和项目中如何实现持续不断的过程改进。
共同特性
不同成熟度级别中的关键过程域执行的具体实践不同。这些实践分别组成关键过程域的5个属性，即5个共同特性。
共同特性用来指明一个关键过程域的执行和制度化是否有效、可重复和可持续。
①执行约定（Commitmentto Perform）
②执行能力（Ability to Perform）
③实施活动（Actives Performed）
④度量和分析（Measurementand Analysis）
⑤验证实施（Verifying Implementation）