第2章_软件生存周期与软件过程课件_第1页
第2章_软件生存周期与软件过程课件_第2页
第2章_软件生存周期与软件过程课件_第3页
第2章_软件生存周期与软件过程课件_第4页
第2章_软件生存周期与软件过程课件_第5页
已阅读5页,还剩79页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、第2章 软件生存周期与软件过程 Chapter 2 Software Life Cycle & Software Process2.1 2.1 软件生存周期软件生存周期(Software Life Cycle)一个软件从开始计划起一个软件从开始计划起, ,到废弃不用的整个时到废弃不用的整个时期期, ,称为软件生存周期。称为软件生存周期。把软件生存周期划分为较小的阶段的目的:把软件生存周期划分为较小的阶段的目的: 给每个阶段赋予确定而有限的任务,能够简化给每个阶段赋予确定而有限的任务,能够简化每一步的工作内容每一步的工作内容, ,使软件复杂性变得较易控制使软件复杂性变得较易控制和管理。和

2、管理。软件生存周期模型软件生存周期模型( Software Lifecycle Model ) 根据软件生存周期为各项开发活动的根据软件生存周期为各项开发活动的流程确定一个合理的框架,称为软件生流程确定一个合理的框架,称为软件生存周期模型或软件开发模型存周期模型或软件开发模型( (即描述软件即描述软件开发过程中各种活动如何执行的模型。开发过程中各种活动如何执行的模型。) )2.1.1 2.1.1 软件生存周期的主要活动软件生存周期的主要活动软件生存周期包含软件生存周期包含3 3个时期:计划、开个时期:计划、开发和运行时期。发和运行时期。各时期又分为若干阶段,共各时期又分为若干阶段,共6 6个阶

3、段。个阶段。需求分析需求分析软件设计软件设计测试测试编码编码图图2.1 典型的软件生存周期典型的软件生存周期运行维护运行维护可行性研究可行性研究开发开发时期时期运行时期运行时期计划计划时期时期 1. 可行性研究可行性研究( Feasibility Study) (详见第(详见第35页,页,2.6.1) 解决解决“是否能做是否能做? 是否值得做是否值得做?”的问题。的问题。 ( Whether can do ? Whether it is worth to do ? ) 主要文档:主要文档:可行性论证报告(可行性论证报告(Feasibility Report)、项目实施计划(项目实施计划( 简称

4、项目计划,简称项目计划, Project Plan)。)。2. 需求分析需求分析 ( Requirement Analysis ) 解决系统解决系统 “做什么做什么? (What to do?) ” 问题。问题。 弄清用户对弄清用户对系统的需求,系统的需求,包括功能包括功能需求需求、性能、性能需求需求、环境约束和用户界面等(环境约束和用户界面等(其中功能需求是最重要其中功能需求是最重要的的),),建立分析模型。建立分析模型。 主要文档主要文档:需求规格说明书需求规格说明书 (Software Requirement Specification , SRS )。及初步的系统用户手册及初步的系统用

5、户手册提交管理机构评审提交管理机构评审3. 软件设计软件设计(Software Design ): 分为总体设计和详细设计。分为总体设计和详细设计。 总体设计(总体设计( General Design ;又称概要设计,;又称概要设计,Preliminary Design ) 主要确定软件的体系结构。主要确定软件的体系结构。把各项需求转换成软件的体系结构。结构中每一组把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块,每个模块都和某些需成部分都是意义明确的模块,每个模块都和某些需求相对应求相对应软件工程9 详细设计( Detail Design ): 又称过程设计(Proces

6、s Design ), 主要设计每个模块的实现细节。 主要文档:概要设计说明书和详细设计说明书主要文档:概要设计说明书和详细设计说明书( Preliminary Design Specification & Detail Design Specification )。提交管理机构评审提交管理机构评审 4. 编码编码( Coding ):把设计翻译为源程序:把设计翻译为源程序 编写源程序编写源程序(Source Program)。 5. 测试测试( Testing ): 进行单元测试、集成测试、确认测试和进行单元测试、集成测试、确认测试和 系统测试。系统测试。 主要文档:主要文档: 测试

7、计划测试计划 ( Testing Plant ) 、测试报告测试报告( Testing Report )等等 。 3.5. 解决解决 “怎么做怎么做?( How to do? )”的的问题。问题。 6. 运行维护运行维护 (Running / Maintenance ): 做好软件的维护工作。做好软件的维护工作。 主要文档:主要文档:维护申请单维护申请单( Maintenance Request Form )和软件修改报告和软件修改报告( Software Change Report ) 等等2.1.2 生存周期和软件过程的关系生存周期和软件过程的关系1.从软件生存周期到软件过程从软件生存周期

8、到软件过程软件过程(软件过程(Software Process):围绕软件开发):围绕软件开发所进行的一系列活动。(通俗地,也可以把软件所进行的一系列活动。(通俗地,也可以把软件过程称为过程称为“软件开发模型软件开发模型”)2.软件过程的演变软件过程的演变 传统的线性开发模型传统的线性开发模型迭代的过程模型迭代的过程模型2.2 2.2 传统的软件过程传统的软件过程( ( Conventional Software Process ) )2.2.1 2.2.1 瀑布模型(瀑布模型(Waterfall Model)瀑布模型:是一种基于软件生存周期的瀑布模型:是一种基于软件生存周期的线性开发模型。线

9、性开发模型。Waterfall ModelREQUIREMENTSANALYSISSYSTEMDESIGNPROCESSDESIGNCODINGTESTINGOPERATION& MAINTENANCE瀑布模型的特点瀑布模型的特点: :1. 1. 阶段间的阶段间的顺序性和依赖性顺序性和依赖性: 各个阶段按自上而下、相互衔各个阶段按自上而下、相互衔接的固定次序,接的固定次序, 如同瀑布逐如同瀑布逐级下落。级下落。2. 2. 推迟实现推迟实现的观点的观点:瀑布模:瀑布模型在编码以前安排了分析阶段型在编码以前安排了分析阶段和设计阶段,直到设计阶段结和设计阶段,直到设计阶段结束,才实现编码,有

10、利于提高束,才实现编码,有利于提高软件质量。软件质量。3. 3. 质量保证质量保证的观点的观点(文档驱动):(文档驱动): (1)(1)每个阶段都要完成规定的文档。每个阶段都要完成规定的文档。 (2)(2)每个阶段结束前都要对已完成的的文档进每个阶段结束前都要对已完成的的文档进行复审(审查)。行复审(审查)。4. 4. 存在存在的问题:的问题:不适合需求模糊的系统。不适合需求模糊的系统。开发的初始阶段很难彻底弄清软件需求。开发的初始阶段很难彻底弄清软件需求。为了解决这个问题,提出为了解决这个问题,提出“快速原型模型快速原型模型”。软件工程17用户要求用户要求编码编码需求分析需求分析模块说明模块

11、说明详细设计详细设计需求规格说明需求规格说明软件结构图软件结构图总体设计总体设计单元测试单元测试程序清单程序清单确认测试确认测试综合测试综合测试系统测试系统测试瀑瀑布布模模型型的的阶阶段段与与文文档档Waterfall Model features1. Very well distinguished process (easy to understand).2. Every steps in the model completes with a milestone. 3. A milestone is defined as a completion of set of documents.4.

12、 When the documents are approved the next step can be taken.( 瀑布模型的特点:瀑布模型的特点:1. 过程清晰,比较容易理解;过程清晰,比较容易理解;2. 每一阶段结束都有一个里程碑来标志;每一阶段结束都有一个里程碑来标志;3. 里程碑定义了一组文档集合;里程碑定义了一组文档集合;4. 只有文档被大家认可后,下一阶段才能启动。只有文档被大家认可后,下一阶段才能启动。 )软件工程19l间洁性间洁性l提供一个模板,使得分析、设计、编码、测试提供一个模板,使得分析、设计、编码、测试与维护工作可以在该模板的指导下有序展开,与维护工作可以在该模

13、板的指导下有序展开,避免开发过程的随意性。避免开发过程的随意性。l采用此方法划分阶段,可以很容易地为各个阶采用此方法划分阶段,可以很容易地为各个阶段分配相应的资源段分配相应的资源软件工程20l瀑布模型的优点瀑布模型的优点可强迫开发人员采用规范的方法可强迫开发人员采用规范的方法严格地规定了每个阶段必须提交的文档严格地规定了每个阶段必须提交的文档要求每个阶段交出的所有产品都必须经过质量保证小组的要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证仔细验证l瀑布模型的缺点瀑布模型的缺点周期长:顺序推进,环环审查周期长:顺序推进,环环审查需求难以准确把握需求难以准确把握( (不能准确提出和沟通、

14、不能快速适应变不能准确提出和沟通、不能快速适应变化的需求化的需求) ),导致返工甚至推倒重来,导致返工甚至推倒重来无法预测新引入模块的影响无法预测新引入模块的影响最终的形式难以预料最终的形式难以预料不适合需求模糊的系统不适合需求模糊的系统 2.2.2 2.2.2 快速原型模型快速原型模型( Rapid Prototype Model ) 1.1.原型开发的优越性原型开发的优越性 快速原型模型的中心思想是:首先建立一个快速原型模型的中心思想是:首先建立一个能够反映用户主要需求的原型,让用户看一看能够反映用户主要需求的原型,让用户看一看未来系统的概貌,以便判断哪些功能是符合需未来系统的概貌,以便判

15、断哪些功能是符合需要的,哪些方面还需要改进;然后将原型反复要的,哪些方面还需要改进;然后将原型反复改进,最终建立符合用户要求的新系统。改进,最终建立符合用户要求的新系统。快速原型模型示意图快速分析快速分析运行原型运行原型快速设计快速设计建造原型建造原型客户评价客户评价修改修改开始开始2.2.原型开发的方法原型开发的方法 (1)(1)原型系统仅包括未来系统的主要功能以及系统的重原型系统仅包括未来系统的主要功能以及系统的重要接口要接口, ,不包括系统的细节。不包括系统的细节。 (2)(2)开发原型系统时尽量使用能缩短开发周期的先进的开发原型系统时尽量使用能缩短开发周期的先进的语言和工具语言和工具(

16、 (如如4GL)4GL)。 (3)(3)把原型系统作为基础,通过补充和修改获得最终的把原型系统作为基础,通过补充和修改获得最终的实际系统。实际系统。 (快速原型模型也常常被当作帮助定义软件需求的一快速原型模型也常常被当作帮助定义软件需求的一种手段种手段, ,大多数原型都废弃不用。)大多数原型都废弃不用。)3. 原型模型的启示原型模型的启示“逼真逼真”的原型可以使用户迅速作出反馈。的原型可以使用户迅速作出反馈。循环回溯和迭代:非线性模型。循环回溯和迭代:非线性模型。4. 应该防止的偏向应该防止的偏向舍不得抛弃,从而影响软件质量。舍不得抛弃,从而影响软件质量。5.原型模型的种类原型模型的种类渐进型

17、:对原型补充和修改获得最终系统。渐进型:对原型补充和修改获得最终系统。抛弃型:原型废弃不用。抛弃型:原型废弃不用。 Advantages and Disadvantages of Prototype1.AdvantagesRequirements better specified and validatedStrong involvement of the customer in the prototyping phase2.DisadvantageHigher development effortl原型模型的优缺点:原型模型的优缺点:1、优点:需求说明可以被更好的描述和验证;在原型阶、优点:

18、需求说明可以被更好的描述和验证;在原型阶段用户可以更深地加入到开发中来。段用户可以更深地加入到开发中来。2、缺点:需要更高的开发技术要求。、缺点:需要更高的开发技术要求。 Prototype is a partially developed product that enables customers and developer to examine some aspect of the proposed system and decide if it is suitable or appropriates for the finished product. (原型是一个被开发的部分产品,用来

19、使用户(原型是一个被开发的部分产品,用来使用户和开发者对想象产品的某些方面进行测试,判断和开发者对想象产品的某些方面进行测试,判断它是否适合于最终的产品。)它是否适合于最终的产品。)软件工程27l用户界面的开发:用得最多的地方。l工作流的模拟:如可演示出系统中的一个具体的购物过程(包括在什么地方产生此类购买活动,针对不同活动所产生的各种用户界面与对话框等)。采用这种方法可以对整个工作流加以模拟,并且可以让用户与软件开发人员亲眼看到相应的过程,考虑到所有可能的场景,从而在最终产品中不漏掉任何一种逻辑情况。软件工程28l存在多个客户的情况:在此情况下,针对变化所作出的原型可能不能令所有的客户满意,

20、因此很可能花大代价制作多个原型。即使每个原型均能各自满足相应客户的要求,也可能存在相互矛盾的需求。l最终客户并不明确的情况:产品有关的功能很可能对于真正的客户来说是无意义的。无法将外部的客户请到开发现场为开发人员提供帮助。软件工程292.3软件演化模型软件演化模型l基本思想:分期完成,分步提交,先提交一个基本思想:分期完成,分步提交,先提交一个有限功能的版本,再逐步地使其完善。有限功能的版本,再逐步地使其完善。l主要特点:利用主要特点:利用“迭代迭代”方法,使渐进开发生方法,使渐进开发生产出逐步完善的软件版本兼有线性顺序模型和产出逐步完善的软件版本兼有线性顺序模型和原型模型的特点。原型模型的特

21、点。l据策略不同分为:增量模型和螺旋模型据策略不同分为:增量模型和螺旋模型2.3 软件演化模型软件演化模型( Software Evolutionary Model ) 2.3.1 增量模型(增量模型(Incremental Model ) 增量模型是瀑布模型的顺序特征与快速原型增量模型是瀑布模型的顺序特征与快速原型模型的迭代特征相结合的产物。它把软件看做一模型的迭代特征相结合的产物。它把软件看做一系列相互联系的增量,在开发过程的各次迭代中,系列相互联系的增量,在开发过程的各次迭代中,每次完成其中的一个增量。每次完成其中的一个增量。时间时间分析分析 增量增量1 增量增量1交付客户交付客户设计设

22、计 编码编码 测试测试 分析分析 增量增量2 增量增量2交付客户交付客户设计设计 编码编码 测试测试 分析分析 增量增量3 增量增量3交付客户交付客户设计设计 编码编码 测试测试 分析分析 增量增量4 增量增量4交付客户交付客户设计设计 编码编码 测试测试 系统和信息工程系统和信息工程软件工程32l优点优点能在较短的时间内向用户提交部分功能的构件;能在较短的时间内向用户提交部分功能的构件;逐步增加产品功能可以使用户有较充裕的时间学习和适应新逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品,减少一个全新软件可能给用户带来的冲击。产品,减少一个全新软件可能给用户带来的冲击。l缺点缺点增量构

23、件的划分依赖于系统功能的构成和软件开发人员的经增量构件的划分依赖于系统功能的构成和软件开发人员的经验;验;要求软件系统的体系结构具有高度的可扩充性和开放性。要求软件系统的体系结构具有高度的可扩充性和开放性。2.3.2 螺旋模型(Spiral Model )螺旋模型是在结合瀑布模型与快速原型模型的基础上螺旋模型是在结合瀑布模型与快速原型模型的基础上 增加了风险分析增加了风险分析 而形成的。而形成的。 1.1.典型的迭代模型典型的迭代模型螺旋模型是一种迭代模型,每迭代一次,螺线线就前进螺旋模型是一种迭代模型,每迭代一次,螺线线就前进一周,每轮螺旋均包含以下一周,每轮螺旋均包含以下4 4个活动:个活

24、动: (1)(1)计划:确定目标,选择方案。计划:确定目标,选择方案。(2)(2)风险分析:分析所选方案,考虑如何识别和消除风险。风险分析:分析所选方案,考虑如何识别和消除风险。(3)(3)建立原型:实施本周期的开发任务。建立原型:实施本周期的开发任务。(4)(4)用户评审:用户评价前一步结果,提出修正建议。用户评审:用户评价前一步结果,提出修正建议。决定目标、决定目标、方案和限制方案和限制评价方案、评价方案、识别风险、识别风险、弱化风险弱化风险 开发、验证、开发、验证、下一级产品下一级产品 计划下一阶段计划下一阶段集成集成测试测试Spiral ModellSuggested by Boehm

25、 (1988);lCombines development activities with risk management to minimize and control risks.l螺旋模型,螺旋模型,1988年由勃姆提出。综合了风险年由勃姆提出。综合了风险管理到开发活动中,以控制风险使其最小化。管理到开发活动中,以控制风险使其最小化。螺旋模型主要适用于内部开发的大规模软件项目。当螺旋模型主要适用于内部开发的大规模软件项目。当风险过大时,可方便的终止项目。风险过大时,可方便的终止项目。 2. 2.风险分析:软件开发存在风险,风险分析的风险分析:软件开发存在风险,风险分析的目的就是要了解、分

26、析并设法降低和排除风险。目的就是要了解、分析并设法降低和排除风险。 对高风险的大型软件,螺旋模型是一个理想的对高风险的大型软件,螺旋模型是一个理想的开发过程。开发过程。 3.3.螺旋模型的特点螺旋模型的特点 在项目开发的所有阶段都考虑各类风险。在项目开发的所有阶段都考虑各类风险。2.3.3 构件集成模型构件集成模型(Component Integrated Model ) 1. 面向对象的基本概念面向对象的基本概念 (1)对象(对象(Object):数据和操作的封装体。):数据和操作的封装体。 (2)类(类(Class):类是对象的抽象,对象是类的实例。类是对象的抽象,对象是类的实例。 (3)

27、继承(继承(Inheritance):子类可以共享父类的数据和操作。):子类可以共享父类的数据和操作。 (4)消息(消息(Message):对象通过消息进行通信。):对象通过消息进行通信。面向对象面向对象 = 对象对象+ 分类分类+ 继承继承+ 通过消息的通信通过消息的通信 Object Oriented = Object + Classfication + Inheritance + Communication with Message软件工程38软件工程39对象是面向对象开发模式的基本成份。对象是面向对象开发模式的基本成份。每个对象可用它本身的一组每个对象可用它本身的一组属性属性和它可以执

28、和它可以执行的一组行的一组操作操作来定义。来定义。电子信箱收件人主题优先级收邮件发邮件手机短消息属性操作对象软件工程40对象:电视机对象:电视机封装封装软件工程41Internal State对象的例子对象的例子: TV开请求开请求变更频道变更频道调节声音调节声音Turn OnTurn OffChange ChannelAdjust VolumeOthers.被封装的行为和状态被封装的行为和状态关请求关请求软件工程42类类l类是一组具有相同数据结构和相同操作的对象的集合。l类的定义包括一组数据属性和在数据上的一组合法操作。l类定义可以视为一个具有类似特性与共同行为的对象的模板,可用来产生对象。

29、l在一个类中,每个对象都是类的实例,它们都可使用类中提供的函数。软件工程43软件工程44例子:四边形类例子:四边形类&两个四边形对象两个四边形对象四四边边形形类类对象对象1对象对象2软件工程45软件工程46继承继承l继承是使用已存在的定义做为基础建立新定义的技术。l新类的定义可以是既存类所声明的数据和新类所增加的声明的组合。新类复用既存的定义,而不要求修改既存类。l既存类可当做基类来引用,则新类相应地可当做派生类来引用。软件工程47继承的例子继承的例子多边形类多边形类四边形类四边形类软件工程48l消息是一个对象与另一个对象的通信单消息是一个对象与另一个对象的通信单元,是要求某个对象执行

30、类中定义的某元,是要求某个对象执行类中定义的某个操作的规格说明。发送给一个对象的个操作的规格说明。发送给一个对象的消息定义了一个方法名和一个参数表消息定义了一个方法名和一个参数表(可能是空的),并指定某一个对象。(可能是空的),并指定某一个对象。l一个对象接收的消息则调用消息中指定一个对象接收的消息则调用消息中指定的方法,并将形式参数与参数表中相应的方法,并将形式参数与参数表中相应的值结合起来。的值结合起来。消息消息软件工程49软件工程50Question:考虑电视机的例子怎样发送消息?软件工程51l假定系统的各个组建已经存在,系统开发 过程的焦点在于集成这些组件,而不是从头开始重新开发。l构

31、件:一个或多个相关类的组合称为一个构件。l特点:有通用性,可在不同软件中复用。软件工程52 2. 什么是构件什么是构件 构件构件(Component)是一种通用的是一种通用的(可复用的可复用的)、可、可支持不同应用系统的软件组件。支持不同应用系统的软件组件。 3. 构件集成模型的特征构件集成模型的特征融合螺旋模型特征。融合螺旋模型特征。支持软件开发的迭代方法支持软件开发的迭代方法 。基于构件库;基于构件库; 构件集成模型利用预先封装好的构件来构造构件集成模型利用预先封装好的构件来构造应用软件系统。应用软件系统。软件工程54 融合螺旋模型的特征,但它是利用融合螺旋模型的特征,但它是利用预先包装好

32、的软件构件来构造软件,预先包装好的软件构件来构造软件,若有完善构件标准可实现软件生产若有完善构件标准可实现软件生产规模化、工程化的一个最有前途的规模化、工程化的一个最有前途的模型据模型据QSM报告称:报告称: 缩短缩短70% 开发周期开发周期 降低降低84%的的项目成本项目成本优点优点2.4 形式化方法模型形式化方法模型 (Model of Formal Method)2.4.1 转换模型(转换模型( Transformational Model ,又称变换模型)又称变换模型)软件工程中涉及的语言有软件工程中涉及的语言有3种种: (1)自然语言自然语言 (2)半形式语言半形式语言: 图表、图形

33、图表、图形; (3)形式语言形式语言: 计算机可运行的语言。计算机可运行的语言。软件工程56l结合形式化软件开发方法和程序自动生成技结合形式化软件开发方法和程序自动生成技术的一种软件开发模型。术的一种软件开发模型。l对系统进行形式化的数学描述,然后把这种对系统进行形式化的数学描述,然后把这种描述用数学方法转换成程序,这种转换是描述用数学方法转换成程序,这种转换是“正确性保持的正确性保持的”可保证开发的程序满足其可保证开发的程序满足其描述。描述。l理论:一个正确的,满足客户需要的形式化理论:一个正确的,满足客户需要的形式化规格说明,经过一系列正确的程序变换后,规格说明,经过一系列正确的程序变换后

34、,可以确保得到一个正确的软件系统。可以确保得到一个正确的软件系统。l特点:试图通过减少某些主要的开发步骤来特点:试图通过减少某些主要的开发步骤来减少出错的机会。减少出错的机会。 图2.2 转换模型形式化形式化规格说明规格说明与需求比较后与需求比较后修正修正变换变换2变换变换1变换变换n测试测试形式化开发记录形式化开发记录系统需求系统需求目标系统目标系统2.4.2 2.4.2 净室模型(净室模型(CleanroomCleanroom Model) Model) 净室模型是一种净室模型是一种形式化的形式化的增量开发模型。增量开发模型。 该模型只适合于软件的形式化开发方法;需要严格的数该模型只适合于

35、软件的形式化开发方法;需要严格的数学理论和形式化技术支持;需要一整套开发环境(如程序学理论和形式化技术支持;需要一整套开发环境(如程序变换工具、定理证明工具等)的支持。变换工具、定理证明工具等)的支持。 软件工程59l净室思想净室思想在分析和设计阶段消除错误在分析和设计阶段消除错误在在“洁净洁净”状态下实现软件制作状态下实现软件制作l形式化形式化盒结构表示分析和设计盒结构表示分析和设计正确性验证正确性验证l增量模型增量模型把软件看成一系列的增量把软件看成一系列的增量表2.1 7种软件开发模型的主要特点开发模型开发模型特特 点点适用场合适用场合瀑布模型瀑布模型 线性模型,每一阶段必须完成规定线性

36、模型,每一阶段必须完成规定的文档的文档需求明确的中、小型需求明确的中、小型软件开发软件开发快速原型模快速原型模型型用户介入早,通过迭代完善用户需用户介入早,通过迭代完善用户需求,原型废弃不用求,原型废弃不用需求模糊的小型软件需求模糊的小型软件开发开发增量模型增量模型 每次迭代完成一个增量,可用于每次迭代完成一个增量,可用于OO开发开发容易分块的大型软件容易分块的大型软件开发开发螺旋模型螺旋模型 典型迭代模型,重视风险分析,可典型迭代模型,重视风险分析,可用于用于OO开发开发具有不确定性大型软具有不确定性大型软件开发件开发构件集成模构件集成模型型软件开发与构件开发平行进行软件开发与构件开发平行进

37、行领域工程、行业的中领域工程、行业的中型软件开发型软件开发转换模型转换模型 形式化的规格说明,自动的程序变形式化的规格说明,自动的程序变换系统换系统理想化模型,尚无成理想化模型,尚无成熟工具支持熟工具支持净室模型净室模型 形式化的增量开发模型,在洁净状形式化的增量开发模型,在洁净状态下实现软件制作态下实现软件制作开发团队熟悉形式化开发团队熟悉形式化方法方法2.5 统一过程和敏捷过程统一过程和敏捷过程2.5.1 统一过程统一过程(Rational Unified Process, RUP)RUP 是美国是美国 Rational 公司(现被公司(现被IBM 公司兼并,称公司兼并,称 IBM- Ra

38、tional 公司)开发的一种支持公司)开发的一种支持UML建模过程的建模过程的软件工具。软件工具。 RUP是以用例为驱动、以系统架构为中心的迭代与增是以用例为驱动、以系统架构为中心的迭代与增量过程。量过程。 RUP在一个二维空间中描述软件开发活动,水平轴代在一个二维空间中描述软件开发活动,水平轴代表时间,显示了过程动态的一面,它将一个软件生存周期表时间,显示了过程动态的一面,它将一个软件生存周期分为分为4个阶段,个阶段,包括初始、细化、构造和移交阶段包括初始、细化、构造和移交阶段,每个阶每个阶段又可以分为多个迭代。段又可以分为多个迭代。图图2.9 2.9 统一过程图示统一过程图示1初始阶段初

39、始阶段:初始阶段的目标是为系统建立业务用例和初始阶段的目标是为系统建立业务用例和确定项目的边界。本阶段的具体目标如下:确定项目的边界。本阶段的具体目标如下:明确软件系统的范围和边界条件,包括从功能角度的前明确软件系统的范围和边界条件,包括从功能角度的前景分析、产品验收标准和哪些做与哪些不做的相关决定;景分析、产品验收标准和哪些做与哪些不做的相关决定;明确区分系统的关键用例和主要的功能场景;明确区分系统的关键用例和主要的功能场景;展现或者演示至少一种符合主要场景要求的候选软件体展现或者演示至少一种符合主要场景要求的候选软件体系结构;系结构;对整个项目做最初的项目成本和日程估计;对整个项目做最初的

40、项目成本和日程估计;估计出潜在的风险估计出潜在的风险(主要指各种不确定因素造成的潜在主要指各种不确定因素造成的潜在风险风险);准备好项目的支持环境。准备好项目的支持环境。 2 2细化阶段细化阶段 细化阶段的目标是分析问题域,建立健全的体系结构细化阶段的目标是分析问题域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。本基础,编制项目计划,淘汰项目中最高风险的元素。本阶段的具体目标如下:阶段的具体目标如下:确保软件结构、需求、计划足够稳定;确保项目风险已确保软件结构、需求、计划足够稳定;确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度;经降低到能够预计完成整个项目的成

41、本和日程的程度;针对项目的软件结构上的主要风险已经解决或处理完成;针对项目的软件结构上的主要风险已经解决或处理完成;通过完成软件结构上的主要场景建立软件体系结构的基通过完成软件结构上的主要场景建立软件体系结构的基线;线;建立一个包含高质量构件的可演化的产品原型;建立一个包含高质量构件的可演化的产品原型;说明基线化的软件体系结构可保障需求可控制在合理的说明基线化的软件体系结构可保障需求可控制在合理的成本和时间范围内;成本和时间范围内;建立好产品的支持环境。建立好产品的支持环境。 3 3构造阶段构造阶段 在构造阶段,所有剩余的构件和应用程序功能被开发并在构造阶段,所有剩余的构件和应用程序功能被开发

42、并集成为产品,所有的功能被详尽地测试。本阶段的主要目集成为产品,所有的功能被详尽地测试。本阶段的主要目标如下:标如下:通过优化资源和避免不必要的返工达到开发成本的最小通过优化资源和避免不必要的返工达到开发成本的最小化;化;根据实际需要达到适当的质量目标;根据实际需要达到适当的质量目标;据实际需要形成各个版本;据实际需要形成各个版本;对所有必须的功能完成分析、设计、开发和测试工作;对所有必须的功能完成分析、设计、开发和测试工作;采用循环渐进的方式开发出一个可以提交给最终用户的采用循环渐进的方式开发出一个可以提交给最终用户的完整产品;完整产品;确定软件、站点和用户都为产品的最终部署做好了相关确定软

43、件、站点和用户都为产品的最终部署做好了相关准备;准备;达成一定程度上的并行开发机制。达成一定程度上的并行开发机制。4 4迁移阶段迁移阶段 完成最后的软件产品和产品验收测试,并编制用户文完成最后的软件产品和产品验收测试,并编制用户文档,进行用户培训等,将软件产品交付给用户群体。本档,进行用户培训等,将软件产品交付给用户群体。本阶段的具体目标如下。阶段的具体目标如下。进行进行BetaBeta测试以期达到最终用户的需要;测试以期达到最终用户的需要;进行进行BetaBeta测试和旧系统的并轨;测试和旧系统的并轨;转换功能数据库;转换功能数据库;对最终用户和产品支持人员的培训;对最终用户和产品支持人员的

44、培训;具体部署相关的工程活动;具体部署相关的工程活动;协调协调BugBug修订、改进性能和可用性等工作;修订、改进性能和可用性等工作;基于完整的版本和产品验收标准对最终部署做出评估;基于完整的版本和产品验收标准对最终部署做出评估;达到用户要求的满意度;达到用户要求的满意度;2.5.2 2.5.2 敏捷过程敏捷过程 ( Agile Process )( Agile Process ) 敏捷开发敏捷开发( (Agile Development)Agile Development)是以人为核心、是以人为核心、以迭代方式顺序渐进开发的方法,其开发过程称以迭代方式顺序渐进开发的方法,其开发过程称为为“敏

45、捷过程敏捷过程”。1.1.敏捷开发的价值观敏捷开发的价值观 个人和交互胜过过程和工具。个人和交互胜过过程和工具。 可以工作的软件胜过面面俱到的文档。可以工作的软件胜过面面俱到的文档。 客户合作胜过合同谈判。客户合作胜过合同谈判。 响应变化胜过遵循计划。响应变化胜过遵循计划。2.2.敏捷过程应遵循的敏捷过程应遵循的1212条原则条原则 通过尽早的、持续的交付有价值的软件来使客户满意。通过尽早的、持续的交付有价值的软件来使客户满意。 即使到了开发的后期,也欢迎改变需求。敏捷过程利即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。用变化来为客户创造竞争优势。 交付可以工作的软

46、件,交付的间隔可以从几个星期到交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。几个月,交付的时间间隔越短越好。 在整个项目开发期间,业务人员和开发人员必须天天在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。都在一起工作。 以积极向上的员工为中心,建立项目组,给他们提供以积极向上的员工为中心,建立项目组,给他们提供所需的环境和支持,并且信任他们能够完成工作。所需的环境和支持,并且信任他们能够完成工作。 在团队内部,最具有效果并富有效率的传递信息的方在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。法,就是面对面的交谈。可运行的软件是首要

47、的进度度量标准。可运行的软件是首要的进度度量标准。敏捷过程提倡可持续的开发速度。责任人、开发者和敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。用户应该能够保持一个长期的、恒定的开发速度。时刻关注优秀的技能和好的设计,以增强敏捷能力。时刻关注优秀的技能和好的设计,以增强敏捷能力。简单是最根本的。简单是最根本的。最好的构架、需求和设计出于自组织团队。最好的构架、需求和设计出于自组织团队。每隔一定时间,团队要反省如何才能更有效地工作方每隔一定时间,团队要反省如何才能更有效地工作方面,然后相应地调整自己的行为。面,然后相应地调整自己的行为。2.5.3 极限编

48、程极限编程 (Extreme Programming,XP) 极限编程是敏捷方法中最著名的、轻量级一个。极限编程是敏捷方法中最著名的、轻量级一个。它由一系列简单却互相依赖的实践组成。它由一系列简单却互相依赖的实践组成。4个价值观个价值观加强交流、从简单做起、寻求反馈、勇于实事就加强交流、从简单做起、寻求反馈、勇于实事就是。是。12个核心实践个核心实践完整团队、计划对策、测试、简单设计、结对编完整团队、计划对策、测试、简单设计、结对编程、小软件版本、设计改进、持续集成、代码共程、小软件版本、设计改进、持续集成、代码共有、编码标准、系统比喻、可持续的速度。有、编码标准、系统比喻、可持续的速度。下面

49、是极限编程的实践内容:下面是极限编程的实践内容: 1.完整团队:完整团队: XP项目的所有参与者(开发人员、客户、项目的所有参与者(开发人员、客户、测试人员等)一起工作在一个场所中。测试人员等)一起工作在一个场所中。 2.计划对策:计划是持续的、循序渐进的。计划对策:计划是持续的、循序渐进的。3.测试:作为选择每个所期望的特性的一部分,客户可以测试:作为选择每个所期望的特性的一部分,客户可以根据脚本语言来定义出自动验收测试来表明该特性可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。工作。 4.简单设计:团队保持设计恰好和当前的系统功能相匹配,简单设计:团队保持设计恰好和当前的系统功能

50、相匹配,不包含任何重复,包含尽可能少的代码。不包含任何重复,包含尽可能少的代码。 5.结对编程:所有的产品软件都是由两个程序员、并排坐结对编程:所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。在一起在同一台机器上构建的。 6.小软件版本:测试驱动开发编写单元测试是一个验证行小软件版本:测试驱动开发编写单元测试是一个验证行为,更是一个设计行为。编写单元测试避免了相当数量为,更是一个设计行为。编写单元测试避免了相当数量的反馈循环,程序员以非常短的循环周期工作,然后使的反馈循环,程序员以非常短的循环周期工作,然后使之通过。之通过。 7. 设计改进:随时利用重构方法改进已经腐化的代码

51、,设计改进:随时利用重构方法改进已经腐化的代码,保持代码尽可能的干净、具有表达力。保持代码尽可能的干净、具有表达力。 8. 持续集成:团队总是使系统完整地被集成。一个人拆持续集成:团队总是使系统完整地被集成。一个人拆入(入(Check in)后,其它所有人责任代码集成。)后,其它所有人责任代码集成。 9. 代码集体共有:任何结对的程序员都可以在任何时候代码集体共有:任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技改进任何代码。没有程序员对任何一个特定的模块或技术单独负责,每个人都可以参与任何其它方面的开发。术单独负责,每个人都可以参与任何其它方面的开发。 10.

52、编码标准:系统中所有的代码看起来就好像是被单独编码标准:系统中所有的代码看起来就好像是被单独一人编写的。一人编写的。 11.系统比喻:系统比喻: 将整个系统联系在一起的全局视图;它是将整个系统联系在一起的全局视图;它是系统的未来影像,是它使得所有单独模块的位置和外观变系统的未来影像,是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符,那么你就得明显直观。如果模块的外观与整个隐喻不符,那么你就知道该模块是错误的。知道该模块是错误的。 12.可持续的速度:团队只有持久才有获胜的希望。他们以可持续的速度:团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精

53、力,他们把项能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑。目看作是马拉松长跑,而不是全速短跑。 极限编程是一组简单、具体的实践,这些实践结合在极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法,项目团队可以拿来直接采用,也可以增的软件开发方法,项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。加一些实践,或者对其中的一些实践进行修改后再采用。 2.6 可行性研究可行性研究( Feasibility Study )

54、 可行性研究的目的是弄清所定义可行性研究的目的是弄清所定义的项目是否可能实现、是否值得进行。的项目是否可能实现、是否值得进行。2.6.1 可行性研究的内容与步骤可行性研究的内容与步骤 1.研究的内容研究的内容 (1)经济可行性经济可行性(Economic Feasibility): 有没有经济效益有没有经济效益? 多长时间可以收回成本多长时间可以收回成本? (进行成本进行成本-效益分析效益分析) (2)技术可行性技术可行性(Technical Feasibility): 现有的技术能否实现该系统?有哪些技术难现有的技术能否实现该系统?有哪些技术难点点? 建议采用的技术的先进程度怎样建议采用的技

55、术的先进程度怎样? (3)运行可行性运行可行性(Operational Feasibility): 系统的运行方式是否可行?系统的运行方式是否可行? (4)法律可行性法律可行性(Legal Feasibility): 系统的开发会不会在社会上或政治上引起侵系统的开发会不会在社会上或政治上引起侵权、破坏或其他责任问题?权、破坏或其他责任问题? 2. 2.研究的步骤研究的步骤 (1)(1)对当前系统进行调查和研究。对当前系统进行调查和研究。 (2)(2)导出新系统的解决方案。提出几种可能导出新系统的解决方案。提出几种可能的解决方案,以便用户选择。的解决方案,以便用户选择。 (3)(3)提出推荐的方案。提出推荐的方案。 本项目的开发价值。本项目的开发价值。 推荐这个方案的理由。推荐这个方案的理由。 (4)(4)编写可

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论