软件工程第二章软件过程

第二章：软件过程目标：软件工程和软件过程模型的概念；了解3个一般的软件过程模型及何时使用它们；了解软件需求工程，软件开发，测试和进化中所涉及的基本过程活动；理解为什么软件过程要有效地组织以应对软件需求和设计上的变更；了解Rational统一过程是如何集成好的软件过程实践来产生一个可适应的软件过程。

所有的软件过程都必须具有4种对软件工程来说是基本的活动。

它们是：1.软件描述：必须定义软件的功能以及软件操作上的约束。

2.软件设计和实现：必须生产符合描述的软件。

3.软件有效性验证：软件必须得到有效性验证，即确保软件是客户所想要的。

4.软件进化：软件必须进化以满足不断变化的客户需要。

2.1软件过程模型一软件过程模型一般有1.瀑布模型：该模型将基本的过程活动，描述，开发，有效性验证和进化，看成是一些界限分明的独立的过程阶段，例如，需求描述阶段，软件设计阶段，实现阶段，测试阶段，等等。

2.增量式开发：该方法使得描述活动，开发活动和有效性验证活动交织在一起。

系统的开发是建立一系列的版本（增量），每个版本添加部分功能到先前的版本中。

3.面向复用的软件工程：该方法使得描述活动，开发活动和有效性验证活动交织在一起。

系统开发过程着重于集成这些组件到新系统中，而非从头开发。

2.1.1瀑布模型一瀑布模型中的主要阶段直接映射基本的开发活动：1.需求分析和定义2.系统和软件设计3.实现和单元测试4.集成和系统测试5.运行和维护二适合采用瀑布模型的时候瀑布模型是与其他工程过程模型相一致的，在它的每个阶段都要生成文档。

这使得过程是可见的，项目经理能够根据项目计划监控项目的过程。

它的主要问题在于它将项目生硬地分解成这些清晰的阶段。

关于需求的责任和义务一定要在过程的早期阶段清晰界定，而这又意味它对用户需求变更的响应较困难。

所以只有在对需求了解的好，而且在系统开发过程中不太可能发生重大改变的时候，适合采用瀑布模型。

瀑布模型的一个重要变形是形式化系统开发。

针对系统描述创建其数学模型。

然后采用能保持一致性的数学变换对该数学模型进行加工，知道产生可执行代码。

形式化的开发过程，如基于B方法特别适用于有严格安全性，可靠性或信息安全性需求的系统的开发。

形式化方法简化了安全用例和信息安全性的需求。

基于形式变换的过程通常只用于开发安全性或信息安全性要求极高的一类系统。

这需要非常专业的知识和技能。

对于大多数系统，在系统开发中应用这一过程不会比其他方法带来明显的成本优势。

2.1.2增量式开发一增量式开发的定义增量式开发的思想是先开发出一个初始的实现，给用户使用并听取用户的使用意见和建议，通过对多个版本的不断修改直到产生一个充分的系统。

描述，开发和有效性验证等活动不是分离的而是交织在一起。

同时让这些活动之间都能得到快速地反馈信息传递。

增量式软件开发，是敏捷开发的一个基本部分，对于商务，电子商务和个人系统来说更加适合。

增量式开发反映了我们解决问题的方法。

我们很少提前制定出完整的问题解决方案，而是逐步地逼近解决方案，当我们意识到错误的时候进行回溯。

通过增量式地开发软件，在开发过程中可以更经济，更容易对软件变更做出响应。

二增量式开发较之瀑布模型有3个重要优点：1.降低了适应用户需求变更的成本。

重新分析和修改文档的工作量较之瀑布模型要少很多。

2.在开发过程中更容易得到用户对于已做的开发工作的反馈意见。

用户可以评价软件的现实版本，并可以看到已经实现了多少。

这比让用户从软件设计文档中判断工程进度要好很多。

3.使更快地交付和部署有用的软件到客户方变成了可能，虽然不是所有的功能都已经包括在内。

相比于瀑布模型，用户可以更早地使用软件并创造商业价值。

三从管理的角度来看，增量式方法存在两个问题：1.过程不可见。

管理者需要通过经常性的可交付文档来把握进度，如果系统开发速度太快，要产生反映系统每个版本的文档就很不划算。

2.伴随着新的增量的添加，系统结构在逐渐退化。

除非投入时间和金钱用在重构系统结构上以改善软件，否则定期的变更会损坏系统的结构。

随着时间的推移，越往后变更系统越困难，而且成本也将逐渐上升。

2.1.3面向复用的软件工程一面向复用的中间阶段是：1.组件分析：给出需求描述，然后搜寻能满足需求的组件。

2.需求修改：根据的得到的组件信息分析需求，然后修改需求以反映可得到的组件。

3.使用复用的系统设计：设计系统的框架或者重复使用一个已存在的框架。

4.开发和集成：当组件不能买到时就需要自己开发，然后集成这些自己开发的组件和现货组件，使之成为一个整体。

二3种类型的软件组件可能用于面向复用的过程：1.通过标准服务开发的Web服务，可用于远程调用。

2.对象的集合，作为一个包和组件框架，如.NET或者J2EE等集成在一起。

3.独立的软件系统，通过配置在特定的环境下使用。

三面向复用模型的优势与劣势面向复用的模型的明显优势是它减少了需要开发的软件数量，从而降低了软件开发成本，同时也降低了开发中的风险。

通常也可使软件快速地交付。

然而，需求妥协是不可避免的，而且这可能又导致一个不符合用户真正需要的系统。

此外，对系统进化的控制也将失效，因为可复用的组件新版本可能是不受机构控制的。

2.2过程活动真正的软件过程是交织着技术，协作，管理等内容的一个活动序列，围绕着一个总的目标，即实现系统的描述，设计，实现和测试。

2.2.1软件描述一软件描述或需求工程是理解和定义系统需要提供哪些服务，以及找出开发和运行中受到哪些约束。

需求工程是软件过程中一个特别关键的阶段，这个阶段的错误将不可避免地带来系统设计和实现阶段过程的后续问题。

二需求工程过程有4个主要的阶段：1.可行性研究：指明现有的软件，硬件技术能否实现用户对新系统的要求。

从业务角度来决定系统开发是否划算以及在预算范围内能否开发出来。

可行性研究应该是相对来讲花钱少且快速完成的。

结果应该得到结论，该系统是否值得进行更细致的分析。

2.需求导出和分析：这是一个通过对现有系统分析，与潜在用户和购买者讨论，进行任务分析等导出系统需求的过程。

也可能需要开发一个或多个不同的系统模型和原型。

这些都会帮助分析员了解所要描述的系统。

3.需求描述：就是把在分析活动中收集的信息以文档的形式确定下来。

在这个文档中有两类需求。

用户需求是从客户和最终用户角度对系统需求的抽象描述；系统需求是对系统要提供的功能的详尽描述。

4.需求有效性验证：该活动检查需求的现实性，一致性和完备性。

在这个过程中，肯定会发现需求文档中的错误，必须加以改正以解决问题。

2.2.2软件设计和实现一软件开发的实现阶段是把系统描述转换成一个可运行的系统的过程。

它总是包含设计和编程，但是，如果用增量式开发方法，可能还包含对软件描述的精炼过程。

软件设计是对实现软件的结构，系统的数据，系统组件间的接口以及所用的算法的描述。

绝大多数软件有面向其他软件系统的接口。

二信息系统设计过程中4个活动：1.体系结构设计：识别系统总体结构，基本组件（有时候也叫子系统或模块），它们之间的关系以及它们是怎样分布的。

2.接口设计：定义系统组件间的接口。

接口的描述必须是无二义的。

在有精确接口定义的前提下，组件不必知道其他组件的具体实现即可使用它们。

一旦接口描述达成一致意见，组件就可以并行设计和开发了。

3.组件设计：针对每个系统组件设计它的运行方式。

这可能是对预期功能的一个简单声明，留给程序员去做具体的设计。

也可能是对复用组件或是某个细化的设计模型所做的一系列的变更。

设计模型可用于自动生成一个实现。

4.数据库设计：设计系统数据结构，以及如何在数据库中表示这些数据结构。

此处的工作又一次取决于是否复用现有数据库或创建一个新的数据库。

2.2.3软件有效性验证一软件有效性验证，通常也称为检验和有效性验证（V&V），是要看系统是否符合它的描述以及系统是否符合客户的预期。

程序测试，即用模拟测试数据运行系统，是最基本的有效性验证技术。

有效性验证技术也包括在从用户需求定义到程序开发的每个软件过程阶段进行检查过程（比如，查阅和复查）。

由于测试的主导地位，绝大多数的有效性验证成本发生在系统完成过程中和完成之后。

二测试过程中的阶段包括：1.组件（或单元）测试：由开发系统的人员对组成系统的组件进行测试。

每个组件都单独测试，而不受其他系统组件的影响。

组件可能是简单的实体，如一个函数或对象类，或者是这些实体的一个相关集合。

通常用自动化测试工具，如JUnit （Massol 和Husted ，2003），它能在新版本的组件创建的时候对其重新测试。

2.系统测试：集成组件形成完整的系统。

这个过程主要是关注无法预测的组件间交互和组件界面问题所引发的错误。

也关注系统是否满足了功能上和非功能上的需求，并测试系统的总体特性。

对于大型系统来说，这可能是一个多阶段的过程，需要对组件所构成的子系统进行测试，然后测试由这些子系统所构成的最终系统。

3.接收测试：这是系统在接受并运行之前进行的最后阶段测试。

这个阶段不再是用模拟数据来测试系统，而是用客户提供的真实数据测试系统。

真实数据能以不同的方式测试系统，所以能暴露出系统需求定义中的错误和遗漏。

接受测试还能发现系统需求中的类问题，即系统的设施不能满足用户的需要或者系统性能是无法接受的。

2.2.4软件进化一 自有软件开发以来，就有软件开发过程和软件进化（软件维护）过程之分。

而现在完全从头开发的系统很少，将软件系统的开发维护看成是一个连续体显得更有意义。

因此，不再将软件工程看成是开发和维护两个完全独立的过程，而是将其堪称是一个进化过程，即软件在其生命周期内不断地随着需求的变更而变更的进化式过程。

这个进化式过程如下图所示。

2.3应对变更一 对于所有大型项目来说，变更是无法避免的。

系统需求是在变化的，因为采购系统的工作要屈从于外部压力和管理权力的更替。

当有新技术可用的时候，新的设计和实现方法就会出现。

因此不管用什么样的软件过程模型，能在软件开发过程中及时处理变更是很必要的。

二 有两个相关的方法会用于降低返工成本：1.变更避免：软件过程包括一些能够在重大返工发生之前预测变更的活动。

例如，原型系统的开发，要先给客户看系统的一些重要特征。

客户可以试用原型，并在花费高额的软件生产成本之前重新定义需求。

2.变更容忍：所设计的过程使得变更以相对较低的成本得到处理。

这通常需要增量开发。

提出的变更可能是在还没有开发的增量上实现。

假如不是这样的，只需要更改单个增量（系统的一小部分）来适应变更。

三 两种应对变更系统需求的方法，它们是：1.系统原型：快速开发一个系统版本或者是系统的一个部分，以检验客户需求和某些设计决定的可行性。

它支持变更避免，因为它允许客户试用正式交付之前的系统，并重新审视和定义需求。

因此在交付正式系统之后，客户提出的需求变更的数目将会降低。