第二讲 软件工程方法学和软件过程.docx

第二讲 软件工程方法学和软件过程.docx

《第二讲 软件工程方法学和软件过程.docx》由会员分享，可在线阅读，更多相关《第二讲 软件工程方法学和软件过程.docx（19页珍藏版）》请在冰点文库上搜索。

第二讲软件工程方法学和软件过程

第二讲软件工程方法学和软件过程

一、软件的生命周期

1、软件的生命周期

软件同世界上其它所有事物一样，也有产生、发展、成熟到消亡的过程，称为软件的“生命周期”（lifecycle）。

“生命周期”把软件不仅仅看作一个静态的事物，而看成是一个过程，需要动态地进行控制和管理，这对纠正软件开发中的各种错误观念，实现对经济上合理有效的软件开发是至关重要的。

“生命周期”的概念是软件工程的基石，一切软件工程的研究和实践都是在此概念基础上进行的。

2、软件生命周期的阶段划分

根据软件自身的特点，生命周期可以划分为以下四个主要阶段：

（1）软件定义：

确定软件开发的目标和具体要求。

（2）软件开发：

实现软件实体，测试，并交付用户

（3）使用和维护：

用户使用软件，开发者进行维护

（4）软件废弃：

软件不再适应新的需求，维护代价太高，停止使用

二、软件工程方法学

1、软件工程方法学

软件工程方法学是指一套完整的、相关的软件开发技术，包括原则、方法、过程和工具，也称为软件开发范型。

目前主要的软件工程方法学包括：

生命周期方法学

面向对象方法学

敏捷方法学

2、生命周期方法学：

（1）定义：

生命周期方法学是指严格按照软件的生命周期，采用分阶段计划和控制，以及顺序实施的步骤，和各种结构化分析（SA，StructuredAnalysis）和结构化设计（SD，StructuredDesign）技术的软件开发方式。

生命周期方法学首先是一种软件开发的方式，它的特点，一是分阶段计划、控制、顺序实施，另外就是在各个阶段采用结构化（包括结构化分析和结构化设计）技术。

要注意：

软件的生命周期概念和软件工程的生命周期方法学概念是两个不同的概念，不能混淆。

软件的生命周期方法学，只是软件开发的一种方法学，同其他软件开发方法学一样，都是以软件生命周期的概念为基础而研究建立的。

生命周期方法学是软件工程最传统的方法学，虽然它并未完全解决软件危机的问题，但是对软件工程的发展起到了极其重要的促进作用，至今仍旧是最成熟和应用最为广泛的方法学。

我们上面给出了软件工程生命周期方法学的定义，下面我们就根据这个定义，来详细讨论一下生命周期方法学的主要特点，分析一下怎么样的软件开发方式就可以被称做是“生命周期方法学”。

（2）特点：

严格的分阶段计划

就是将软件开发过程从时间上分解，降低软件开发的复杂度。

软件危机的主要表现之一，就在于软件的开发过程难以管理和控制，软件的质量没有保证。

随着软件规模越来越大，开发周期越来越长，整个软件开发过程也变得越来越复杂，越来越混乱。

人类解决复杂问题的一个惯常方式就是分解，把复杂的事物分解为小的部分，再逐一解决。

生命周期方法学依照软件的生命周期，将完整的软件开发过程从时间上划分为许多相对独立的阶段。

在每一个阶段，都有它确定的任务和方法，以及完成的结果的标准。

瀑布式开发模式

“瀑布式开发模式”，也就是定义里的“顺序实施”。

瀑布的特点是水流从上到下，一落到底，不会反复。

生命周期方法学采用了从上到下，各个阶段逐一进行的软件开发方式，前一个阶段结束后形成的结果作为下一个阶段工作开始的依据。

在每一个阶段的任务没有按质量要求完成时，不进行下一个阶段的工作，每个阶段完成后也不再反复。

严格的技术审查和管理复审

技术审查和管理复审是技术和经济两个方面管理软件开发过程，保证软件的质量，控制开发成本和进度。

技术审查包括文档齐备性的形式审查和阶段结果的实质审查。

技术审查的要点就是不能把错误带入下一个阶段，以满足瀑布式开发模式的需要。

技术审查通过后要进行管理复审。

它由组织开发工作的项目管理人员进行，是从进度和成本的角度审查本阶段的工作，并对后续阶段的成本和进度计划进行调整，并对后续的开发目标进行决策。

各个阶段采用结构化技术

结构化技术的基本思想是自上而下，逐步求精。

结构化技术最先起源于编程领域，后来随着生命周期方法学的发展被全面应用到软件开发过程的各个阶段。

在后续生命周期方法学各个阶段的详细介绍中会说明各种结构化技术的具体方法。

3、面向对象方法学：

（1）定义：

面向对象方法学是以面向对象技术为核心，利用类的继承等复用方式，通过逐步细化地建立对象模型，以及迭代和演化的步骤完成软件开发的模式。

面向对象方法学起源于面向对象程序设计，是目前最符合人类解决现实问题的思维模式和物理系统运行方式的软件开发方法学。

（2）特点：

以对象作为基本的软件构件

在问题的解域模拟问题域的模型，数据和对数据的操作紧密结合。

对象是一种包含了数据和操作，并且良好封装的逻辑实体。

整个软件由无数独立活动的对象构成，对象之间通过消息机制相互通信和相互作用。

面向对象的软件结构和面向流程的软件结构之间有巨大的区别，与现实世界中的实际系统更加吻合，是软件构建思想上的一次革命。

软件定义和实现的统一

无论在定义、设计还是在实现阶段，面向对象方法学都是通过对系统模型的逐步细化和精化来完成的，因此整个软件的开发过程就是一次由粗到细构建对象模型的过程，定义和实现不再截然划分。

重视软件复用

面向对象方法学使用类来完成对象的定义，类还可以通过继承派生出新的类，因此面向对象方法学本质上就具备了良好的软件复用的基础，可以在不同软件中使用已有的类来派生出新的类，既利用了前人的软件开发成果，又可以根据每个软件的实际情况产生新的对象，结合对象完善的封装机制，实现对象模型的多层次、普遍的复用。

通过逐步演化来完成软件开发

面向对象方法学使用循环迭代的方式来开发软件，整个软件系统是逐步精华的，这既符合人类对事物的认识模式，又可以尽早获得软件开发的概貌性结果，便于对软件需求进行验证。

4、敏捷方法学：

（1）定义：

敏捷方法学是针对用户需求迅速变化的现实情况，采用短周期交付形式和协作开发的轻量级软件开发方式。

敏捷方法学是程序员对过多强调严格规范和文档的软件工程方法的一次更高水平上的反动，强调以人为本、追求目标和“轻但适用”。

（2）特点：

追求软件交付使用这一终极目标

敏捷方法学把一切软件开发的规范、标准、技术都置于“软件按期交付”这一目标之下，强调任何使软件能够高质量地按期交付的方法、工具和过程都应得到应用，把软件能够满足用户的实际需求看做是软件开发工作的根本目标。

强调全面合作和交流

敏捷方法学把软件开发定性为一种创造和交流的合作活动，强调用户和开发方不仅仅是合同的甲方和乙方，而是必须全面合作来完成软件开发工作；用户和开发人员，开发人员之间的有效交流是最重要的成功因素，致力于寻找快捷、方便和低成本的交流方式。

重视软件开发中人的个性

敏捷方法学不把软件开发人员看做完成任务的机器，强调发挥个人的潜能和主动性，保障开发人员得到足够的尊重和照顾，维持开发人员的工作积极性，以使开发工作能够有效地持续。

强调团队的力量

敏捷方法学不认为个人的能力决定了软件的成败，它强调开发人员之间的交流和配合，强调团队的合力，以保障团队在人员调整的情况下依然能够按期完成软件开发。

灵活采用各种开发和管理方式

正因为敏捷方法学强调终极目标，因此在具体开发方式和管理方式上，各种具体的开发方法也有许多区别，只要能够有效地促进软件开发，各种方式方法都可以使用。

三、软件过程

软件过程是开发软件所需的一系列任务的框架，它规定了完成各项任务的步骤和顺序。

1、瀑布模型

瀑布模型是最传统的软件开发过程，也是经典的生命周期方法学的组成部分，在软件开发过程首次以“工程化”的思想为指导实现可控制、可管理的过程发挥了非常重要的作用。

瀑布模型把软件开发过程从时间上划分成相对独立的阶段，并具备以下特点：

顺序实施，不能反复

每个阶段完成后才能开始下一个阶段的工作，每个阶段的工作结果都是下一个阶段工作的出发点，一旦完成了一个阶段的工作，就不能再返回重新进行该阶段的任务。

推迟编程实现

具体编制程序的工作放在需求分析和软件设计之后，不急于编程，以保证在软件实现之前进行了充分细致的分析和设计，极端的情况下甚至推崇在编程阶段之前不提供编程开发环境，完全脱离编程思维来完成软件分析和设计工作。

通过阶段评审保证开发质量

因为瀑布模型在每一个阶段完成后不允许反复，因此如何保证每个阶段的工作结果能够全面、正确，不把错误带入下一个阶段就变得非常重要。

瀑布模型采用阶段评审来保证软件开发的质量。

要求文档齐备

瀑布模型在编程阶段完成之前是看不到软件实体的，因此为了保证各个阶段的工作能够顺利开始和结束，保证阶段评审能够有据可依，对各个阶段产生的文档要求非常严格，种类必须满足规范，内容必须完整充实，表述必须清晰可读。

由于以上特点，瀑布模型也存在明显得缺陷：

难以验证需求

用户在软件开发过程的后期才能见到软件实体，因此即使文档再齐备，用户也难以确定软件开发的目标和自己的真实需求完全一致，开发人员也难以直观有效地摸清用户的需求细节，容易对软件需求产生误判。

不能适应需求的变化

瀑布模型完全不允许在开发流程上出现反复，因此在开发周期比较长的大型项目中，即使需求分析的结果是非常准确有效的，也会由于用户需求随环境和时间的变化在最终的软件实体中不能得到完美地满足。

瀑布模型对需求变化的适应能力弱严重制约了面向网络时代的新型软件开发项目的有效实施。

软件重用性差

提高软件开发成果的重用性是提高软件生产率的关键因素。

瀑布模型的开发基点是对某个具体用户需求的分析，采用的是由总到分、逐步细化的结构化分析和设计技术，每个软件部件都是软件整体的有机组成部分，这直接影响了软件部件在不同软件项目中的通用性和重用性。

2、快速原型法

快速原型法是直接针对瀑布模型不能及时验证用户需求的缺陷而改进产生的，它基于第4代编程语言（4GL）可以直观便捷地建立软件界面和软件结构的特性，在获得软件开发需求后，开发出软件的快速原型供用户试用，通过用户的反溃来调整需求分析结果，得到用户对需求的完全认可后再进行后续的软件设计和实现工作。

快速原型法的特点是：

基于瀑布模型基础

快速原型法只是对瀑布模型进行了改进，整体流程和基本原则没有发生变化。

使用快速原型完成需求验证

快速原型法使用快速原型来完成需求验证，使得用户需求的表述和交流更加直观有效。

原型可以被抛弃，也可以演化成最终的软件

快速原型法产生的原型可以在需求确认后被放弃，也可以作为界面基础来进行后续的软件设计的实现。

但在面向对象技术出现以前，由于软件的界面结构与内部模块结构并不完全一致，快速原型演化成最终端软件存在很多困难，多数情况下还是会重新进行软件的设计和实现。

使用快速原型来完成需求验证，使得用户需求的表述和交流更加直观有效。

快速原型法的主要缺点有：

增加成本和开发时间

如果快速原型仅用来完成需求验证，就增加了整个软件开发过程的成本和时间。

不能适应需求的变化

快速原型法仍旧没有解决瀑布模型不能适应软件需求变化的问题。

3、增量模型

增量模型是在软件总体设计中，将软件整体划分为相对独立的构件（通常是按照功能子系统），对每个构件分别进行详细设计、编码实行和综合测试，再分别交付用户试用。

整个软件的开发和交付是逐构件递增的，因此称为“增量模型”。

增量模型的特点是：

构件分解，逐步开发交付

将大型的软件进行构件分解，一个构件一个构件地开发交付，也是化解软件开发复杂性的一种思路。

如果快速原型仅用来完成需求验证，就增加了整个软件开发过程的成本和时间。

根据用户反馈修改分析果和设计

在每个构件先后交付用户使用的过程中，可以尽早得到用户的反馈信息，便于对需求分析结果和软件设计进行修改，避免到最后一步才发现问题。

逐步进行用户培训

用户是逐步得到软件实体的，在这个过程中，用户可以逐步熟悉系统工作方式和操作方式，降低了用户培训的难度。

增量模型的缺点有：

构件划分难以准确

构件划分在增量模型中非常重要，但是要准确地划分构件却十分困难。

构件划分不仅要保证软件功能的相对完整，还要准确定义不同构件之间的相互联系和影响，避免构件逐步交付却由于配合问题用户不能使用。

容易引入组装错误

在各个构件分别交付用户使用的过程中，容易引入组装错误（由于构件间的相互作用带来的软件运行错误）。

组装错误常常不仅影响软件的整体功能，而且对每个构件内部的可靠性和正确性都会产生影响。

4、螺旋模型

螺旋模型是一种倍受重视的软件开发过程。

在螺旋模型中，软件开发按照螺旋状的路径反复进行，每个周期都会在不同的层次上完成软件原型的构建，通过对原型的不断改进和细化得到最终的软件。

同时，在螺旋模型的每个开发循环中，都会经历阶段目标的确定和风险分析的步骤，以不断发现和排除软件开发进程中的各种风险因素，全面掌控软件开发的进度和成本。

螺旋模型的特点是：

逐步提高开发目标

开发目标是逐步提高的，这有助于开发过程的控制和管理。

软件周期性迭代演化

软件在整个开发过程中，以原型的方式逐步演化，不断迭代，最终得到可以交付使用的软件系统。

利用风险分析避免投资损失

在每个开发周期中，都要进行风险分析，及时做出后续开发的正确决策，以避免投资的更大损失。

螺旋模型的缺点有：

适用于大型项目

螺旋模型投入的开发控制和管理成本比较高，适用于周期长、规模大的软件项目。

风险分析要求较高

风险分析师螺旋模型得以顺利实施的关键，但是如何发现、预测和控制风险是一项难度很大的工作，往往只能根据长期的经验来进行判断。

5、喷泉模型

喷泉模型是一种在面向对象方法学中应用很广泛的软件开发过程。

在喷泉模型软件开发的各个阶段中，系统表达都采用统一的对象模型，这样每个阶段的工作都是对上一个阶段产生的对象模型进行细化求精的过程，反复迭代促进软件系统的演化。

在相邻的两个开发阶段之间，并没有明确清晰的工作边界，总是存在局部的反复。

喷泉模型的特点是：

各个阶段采用统一的系统模型

这样有助于相邻阶段之间的衔接和配合。

逐步细化和精化

软件开发的整体过程和每个阶段内部的开发方式都是对系统模型的逐步细化和精化过程，系统的演进既有继承性又有扩展性。

喷泉模型的缺点有：

仅适用于面向对象方法学

面向对象技术是喷泉模型可以得以实现的基础。

不易实现过程中的评审和质量控制

喷泉模型各个开发阶段之间边界模糊，阶段成果不清晰独立，过程中的质量监控比较困难。

6、变换模型

变换模型是一种非常理想的软件开发过程。

它使用形式化技术将软件的需求分析和设计结果表达为数学上严格和无歧义的形式，再使用自动化软件工具将其逐步变换编译为最终的可执行代码。

变换模型的特点是：

自动产生程序代码

只要需求分析的结果可以良好地形式化表达，程序代码的生成就可以自动完成。

可使用快速原型进行需求验证

变换模型中最终软件的质量仅取决于需求分析的结果，因此可使用快速原型法在需求分析结束后进行需求验证，快速原型可以由变换工具自动生成，也可以人工设计。

变换模型完全依赖于形式化理论的完善和自动化工具的支持，因此在实际应用中很难满足所需条件，目前只是软件自动化研究的一个方向，还没有在实践中变成有效的现实。

变换模型还有另一个缺点是过程中没有人工参与，缺乏开发人员可以理解的软件文档，给软件的维护和重用都带来了困难。

7、极限编程

极限编程是符合敏捷方法的基本原则实施的软件开发方式，它强调任何开发工作最终都要向用户交付合格的软件，并且将许多实践证明有效的开发实践运用到极限来达到这一目标。

极限编程有完整明确的开发规程，它的主要特点包括：

符合敏捷方法学原则

客户参加开发小组

短交付周期（1～3周），持续迭代

代码的集体所有

极限运用好的开发实践

有许多极限编程的狂热者声称极限编程没有缺陷，但在另外一些人看来，极限编程的缺陷也很明显：

：

对大型项目适应性不强

依赖于高素质的开发队伍

8、微软过程

微软过程是微软公司根据长期的软件开发经验而总结确立的独特的软件开发过程，它的核心思想是“同步”和“稳定”，强调既要符合软件开发中演进和迭代的规律，也要在不同的阶段实现软件配置的“固定化”，以减少变动对各个不同开发小组的影响。

微软过程本质上更适合微软公司大型产品化软件的开发任务，同时也存在对于需要对市场和用户需求进行快速反应的网络时代的软件开发不太适应的问题，微软公司目前已经在进行调整。

微软过程的主要特点包括：

做好早期规划和评估

微软过程强调在一个产品开发的早期要对市场和用户需求有详尽的分析，做好全面的规划和开发风险评估。

多个小组并行开发，经常同步

在开发任务确定后，微软通常建立多个开发小组并行的开发软件的不同部分，各个小组间通过频繁地进行产品同步来确保都使用了其它小组开发成果的最新版本。

过程强调在一个产品开发的早期要对市场和用户需求有详尽的分析，做好全面的规划和开发风险评估。

使用“里程碑”实现阶段性性的产品稳定

当产品开发进行到某个相对独立的时间节点（称为里程碑），可以完整地完成软件的一部分功能时，此时的各部分开发结果要进行冻结，不能再随意修改，以确保后续的开发工作有相对稳定的开发基础。

当所有里程碑都实现的时候，整个软件开发的工作也就完整结束了。

其主要缺点有：

缺乏一般性理论指导

微软过程是微软公司自己的软件开发经验的总结，缺乏一般性的软件工程理论指导，也缺乏通用性。

强调在一个产品开发的早期要对市场和用户需求有详尽的分析，做好全面的规划和开发风险评估。

仅适合产品化软件开发

微软过程更适合面向市场的产品化软件开发，对于大型的任务型软件开发不太适合。

对用户需求反应迟缓

微软过程在前期进行软件开发需求的调研，在后期很难再对软件开发目标进行大的调整。

课后作业

阅读下面两本书籍中的一本，写一篇论文来说明在软件开发思想方面得到的启发和自己对于软件工程学科的认识：

《微软的秘密》，北京大学出版社，1997

《人月神话》，清华大学出版社 ，2007