软件工程-第2章 1

第2章生命周期及开发模型,2.1软件生命周期的基本任务,软件生命周期又称为软件生存周期，生命周期的每一个阶段都有确定的任务，并产生相应的文档资料，提交给下一个阶段作为继续工作的依据。按照软件生命周期的定义，软件的开发不仅仅是强调“编码”，而是概括了软件开发的全过程。,概括地说，软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)3个时期组成，每个时期又进一步划分成若干个阶段。,软件生命周期模型,典型文档,尽管在实际的软件项目开发过程中会有很多不同，但都会产生一些典型文档。这些文档包括：（1）软件需求规格说明书，即描述将要开发的软件是做什么的；（2）项目计划，即描述将要完成的任务及其顺序，并估计所需要的时间、工作量和成本等；,（3）软件测试计划，即描述如何测试软件，使之确保软件应实现规定的功能，并达到预期的性能；（4）软件设计说明书，即描述软件的结构，包括概要设计及详细设计；（5）用户手册，即描述如何使用软件。,典型文档,软件生命周期各个阶段的基本任务,1问题定义2可行性分析3需求分析4概要设计5详细设计6编码7测试8软件维护,问题定义阶段必须回答的关键问题是：“要解决的问题是什么?”在进行软件开发前，确切地定义问题是十分必要性，是不容忽视一个步骤。,1问题定义,2可行性研究,这个阶段要回答的关键问题是：“对于上一个阶段所确定的问题有行得通的解决办法吗?”可行性研究的目的就是用最小的代价在最短的时间内确定问题是否能够解决。从技术可行性、经济可行性、社会因素可行性等方面进行分析。,3需求分析,这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”。需求分析就是对目标系统提出完整、清晰、具体的要求，即确定目标系统必须具备哪些功能。而可行性研究没有考虑细节的问题，并没有准确地回答“系统必须做什么”的问题，所有不能代替需求分析。,3需求分析,这个阶段还有一项重要的任务，就是用正式文档准确地记录对目标系统的需求，我们把该文档称为规格说明书(specification)。,4概要设计,概要设计又称为总体设计。这个阶段的基本任务是，概括地回答“如何实现目标系统?”这个问题。概要设计的任务还包括设计程序的体系结构，也就是对程序进行模块化，确定程序由哪些模块组成以及模块间的关系。这一阶段确定了解决问题的策略、目标系统中应包含的程序以及数据库的设计。,5详细设计,概要设计阶段只是比较概括的方式提出了解决问题的办法。详细设计阶段的任务则是要把解法具体化，即具体解决如何实现软件系统。同时，在这个阶段还要设计出程序的详细规格说明。,5详细设计,详细设计也称为模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。,6编码,这个阶段的任务是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。,7测试,这个阶段的任务就是发现并改正软件中的错误，以保证软件的可靠性。整个测试过程分单元测试、集成测试和确认测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中，这两类方法通常联合使用，测试过程的前期阶段主要使用白盒测试技术，而后期阶段主要使用黑盒测试技术。,7测试,应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，作为软件配置的一个组成部分。,8软件维护,这个阶段的任务是通过各种必要的维护活动使系统持久地满足用户的需要。通常有4类维护活动：改正性维护、适应性维护、完善性维护、预防性维护。软件维护实际上就是一次压缩和简化了的软件定义和开发的全过程。同时，每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。,以上根据应该完成的任务，把软件生命周期划分成8个阶段。但在实际从事软件开发工作时，软件规模、种类、开发环境及开发时使用的技术方法等因素都会影响阶段的划分。没有一个适用于所有软件项目的任务集合，因此，应根据所承担项目的特点来划分阶段。,2.2开发模型,软件生命周期又称为软件生存周期，生命周期的每一个阶段都有确定的任务，并产生相应的文档资料，提交给下一个阶段作为继续工作的依据。按照软件生命周期的定义，软件的开发不仅仅是强调“编码”，而是概括了软件开发的全过程。,2.2开发模型,软件生命周期模型又称为软件开发模型(SoftwareDevelopmentModel)，即软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。,2.2开发模型,对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。,2.2开发模型,下面介绍几种比较经典的软件开发模型有瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型，以及Rational统一过程开发模型和敏捷过程模型之极限编程。,2.2.1瀑布模型,最早出现的软件开发模型是1970年温斯顿罗伊斯提出的“瀑布模型”，直到上世纪80年代之前，瀑布模型一直是惟一被广泛采用的软件开发模型，现在它仍然是软件工程中应用得最广泛的开发模型。,传统的瀑布模型：,2.2.1瀑布模型,传统的瀑布模型又称为线性顺序模型，按照这种模型开发的软件产品具有以下特点：1.阶段间由于顺序性和依赖性2.延迟实现观点3.保证质量的观点,瀑布模型的优缺点：,2.2.1瀑布模型,传统的瀑布模型过于理想化了，实际的瀑布模型是带“反馈环”的。,改进的瀑布模型：,2.2.2快速原型模型,快速原型模型的优点：（1）有助于满足用户的真实需求。（2）原型系统已经通过与用户的交互而得到验证，据此产生的规格说明文档能够正确地描述用户需求。（3）软件产品的开发基本上是按线性顺序进行。（4）因为规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工。,2.2.2快速原型模型,快速原型模型的优点：（5）开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。（6）快速原型的突出特点是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型可以抛弃，当然也可以在原型的基础上进行开发。,2.2.3增量模型,增量模型也称为渐增模型，是Mills等于1980年提出来的。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。,2.2.3增量模型,增量模型：,2.2.3增量模型,增量模型的优点：（1）有利于增加客户对系统的信心（2）降低系统失败风险（3）提高系统可靠性（4）提高了系统的稳定性和可维护性增量模型的缺点：（1）增量粒度难以选择（2）确定所有的基本业务服务比较困难,2.2.4螺旋模型,螺旋模型最初是Boehm于1988年提出来的。该模型将瀑布模型与快速原型模型结合起来，并且加入两种模型均忽略了的风险分析。螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。,2.2.4螺旋模型,四个象限：制定计划风险分析实施工程客户评价,2.2.4螺旋模型,螺旋模型的优点：对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。减少了过多测试或测试不足所带来的风险。在螺旋模型中维护只是模型的另一个周期，因而在维护和开发之间并没有本质区别。,2.2.4螺旋模型,螺旋模型的缺点：螺旋模型是风险驱动的，因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还以为一切正常。,2.2.5喷泉模型,喷泉模型是典型的面向对象生命周期模型。“喷泉”一词体现了迭代和无间隙特性。图中代表不同阶段的圆圈相互重叠，这明确表示两个活动之间存在重叠。,2.2.6Rational统一过程,Rational统一过程（即RationalUnifiedProcess，简称RUP），是一个软件的开发过程，它将用户需求转化为软件系统所需的活动的集合。RUP是一种“用例驱动，以体系结构为核心，采用迭代及增量开发”的软件过程框架，由UML方法和工具支持。它适用于各种类型的软件系统、以及各种不同的应用领域、功能级别以及项目规模。,2.2.6Rational统一过程,RUP可以是用一个二维坐标来描述的。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期、阶段、迭代和里程碑；纵轴以内容来组织自然地逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动、产物、角色和工作流。,RUP软件开发生命周期：,2.2.6Rational统一过程,RUP由四个阶段组成，分别是初始阶段、细化阶段、构造阶段和移交阶段。每个阶段开始时都有目标，结束时都有里程碑。在每个阶段中存在一个或多个迭代。在每个迭代中，可以有多个工作流。,2.2.6Rational统一过程,初始阶段主要任务是项目计划和风险评估，其目的是确定是否值得开发目标系统。初始阶段的里程碑是生命周期目标。精化阶段又称为细化阶段，主要任务是定义系统的总体框架，其目标是细化初始需求、细化体系结构、监控风险并细化它们的优先级、细化业务案例以及制订项目管理计划。细化阶段的里程碑是生命期架构。构造阶段是建立系统，构造系统的第一个具有操作的版本，以能够交付给客户进行测试的版本结束，有时称为测试版本。构造阶段的里程碑是初始运作功能。移交阶段是测试时期，以发布完整的系统而终止，其目标是确保信息系统真正满足客户的需求。交付阶段的里程碑是产品发布。,2.2.6Rational统一过程,其中，简单介绍5个核心工作流，（1）需求工作流。其目标是确保开发人员构建正确的系统。（2）分析工作流。其目标是分析和细化需求。（3）设计工作流。设计工作流是对分析工作流的细化，直到设计模型可以被程序员实现为止。（4）实现工作流。实现工作流的目标是用选择的实现语言实现目标系统。（5）测试工作流。测试工作流是质量保证组的职责。,2.2.7敏捷过程与极限编程,2001年，KentBeck等17名编程大师成立了敏捷软件开发联盟，简称敏捷联盟，并发表了“敏捷软件开发”宣言。该宣言中提到“个体和交互胜过过程和工具；可工作软件胜过宽泛的文档；客户合作胜过合同谈判；响应变化胜过遵循计划”。敏捷软件开发是一个新型的开发软件模式，用来替代以文件驱动开发的瀑布开发模式。,2.2.7敏捷过程与极限编程,任何一个敏捷过程都可以由所强调的3个关键假设识别出来，这3个假设可适用于大多数软件项目。（1）提前预测哪些需求是稳定的、哪些需求会变化非常困难。同样的，预测项目进行中客户优先级的变化也很困难。（2）对很多软件，设计和构建是交错进行的。事实上，两种活动应当顺序开展以保证通过构建实施来验证设计模型，而在通过构建验证之前很难估计应该设计到什么程度。（3）从制订计划的角度来看，分析、设计、构建和测试并不像我们所设想的那么容易预测。,2.2.7敏捷过程与极限编程,典型的敏捷过程开发模型有极限编程、特性驱动开发（FDD）、Scrum以及敏捷的统一过程（AUP）等。,2.2.7敏捷过程与极限编程,极限编程（eXtremeProgramming，简称XP）是一个轻量级、灵巧的软件开发方法，是一种软件工程方法学。XP包含了策划、设计、编码和测试4个框架活动的规则和实践。,2.2.7敏捷过程与极限编程,（1）策划。策划活动开始于建立健全描述待开发软件特征与功能需求的“故事”（也称为用户故事）。（2）设计。XP设计严格遵循KIS（keepitsimple，保持简洁）原则，通常更愿意使用简单设计而不是更为复杂的表述。（3）编码。XP推荐在故事开发和基本设计完成之后，团队不应直接开始编码，而是开发一系列用于检测本次（软件增量）发行包括所有故事的单元测试，一旦建立起单元测试，开发者就可以更集中精力于必须实现的内容以通过单元测试。（4）测试。,2.2.7敏捷过程与极限编程,XP在4个价值观之上，又定义了12个的必须遵循的实践：1.完整团队：XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。2.计划游戏：计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。3.客户测试：作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。,2.2.7敏捷过程与极限编程,4.简单设计：团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。5.结对编程：所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。6.测试驱动开发：编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。,2.2.7敏捷过程与极限编程,7.改进设计：随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。8.持续集成：团队总是使系统完整地被集成。一个人拆入（Checkin）后，其它所有人责任代码集成。9.集体代码所有权：任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。,2.2.7敏捷过程与极限编程,10.编码标准：系统中所有的代码看起来就好像是一人单独编写的。11.隐喻：将整个系统联系在一起的全局视图的概念。它是系统的未来影像，是它使得所有单独模块的位置和外观变得明