第二章软件生存期与与软件过程.ppt

单击此处编辑母版文本样式,*,软件生存周期,与软件过程,一、实用软件工程方法：,1、结构化方法(SA、SD、SP)，,2、面向数据结构（Jacson、warrier）方法，,3、问题分析法PAM，,4、面向对象方法（OOA、OOD、OOP），,面向方面编程(AspectOriented Process，AOP),5、可视化开发（针对图形用户界面的开发方法），,6、ICASE,（Integrated Computer-Aided Software Engineering）,，,7、软件重用,和,组件连接,等,二、形式化开发方法：,采用严格的数学语言，具有精确的数学语义的方法，都称为形式化方法。,有限状态机、Petri 网、进程代数、一阶逻辑、,时态逻辑、Z方法、VDM、Larch,软件开发方法：,Parnas方法,1972,原型化方法Prototyping,为获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。,工作任务,里程碑、交付物,SQA,点,A process defines,Who,is doing,What,When,and,How,in order to reach a certain goal.,公共过程框架,辅助活动,框架活动,任务集合,软件过程,过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。,过程：,我们可以把一系列有序的任务集合看作过程：过程是涉及活动、约束和资源，并产生某种输出的一系列步骤。,过程的特点：,过程需要使用一系列工具和技术。,过程规定所有主要的过程活动。,过程使用资源，受制于约束（如进度），产生中间产品和最终产品。,过程可能由在某种方式上相互关联的子过程组成，过程可定义过程的层次结构，以便每一子过程均有自己的过程模型。,每一过程活动均有入口和出口标准，以便我们知晓活动何时开始，何时结束。,软件生命周期与过程,软件开发模型,软件开发模型,:,软件开发,全部过程,、,活动,和,任务,的,结构框架,。,它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。,软件开发模型,也常称为：,软件过程模型,软件生存期模型,软件工程范型,活动,按顺序组织在一起，以便我们清晰地知道当一项活动执行时，与何活动相关。,为解释每一活动的目标，每一过程都有一系列的指导原则。,对活动、资源或产品须施于约束或控制。例如预算或进度会限制活动花费的时间，工具会限制使用资源的方式。,软件生命周期也是一个过程！,同其它事物一样，软件也有一个孕育、诞生、成长、成熟、衰亡的生存过程。我们称其为计算机软件的生存周期。即：,软件产品或软件系统从,设计、投入使用到被淘汰,的全过程。,根据这一思想，把上述基本的过程活动进一步展开，可以得到软件生存周期的六个步骤。,软件生存周期,(,Software Life Cycle,),1）制定计划：,确定要开发软件系统的总目标，给出它的功能、性能、可靠性以及接口等方面的要求;,研究完成该项软件任务的可行性，探讨解决问题的可能方案;,制定完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查。,2）需求分析：,对待开发软件提出的需求进行分析并给出详细的定义。,编写出软件需求说明书及初步的用户手册，提交管理机构评审。,3）软件设计,：,把已确定了的各项需求转换成一个相应的体系结构。进而对每个模块要完成的工作进行具体的描述。,编写设计说明书，提交评审。,只考虑,编写程序,涉及整个,软件生存,周期,扩展到,软件工作的范围,软件生命周期各阶段的不同定义,1问题定义,“,要解决的问题什麽？,”在问题定义阶段应提出：,问题性质报告,工程目标和规模报告,对系统的实际用户和使用部门进行访问调查，,澄清含糊不清的地方后得到双方满意的文档。,2可行性研究,关键问题“,对于上一个阶段所确定的问题有行得通的解决办法,”,可行性研究阶段应该导出系统的高层逻辑模型（通常用数据流图）并且在此基础上更准确，更具体的确定工程规模和目标，然后分析员更准确的估计系统成本和效益，对建议的系统进行仔细的成本/效益分析。,生命周期各阶段的基本任务,3.需求分析,解决的问题“,为解决问题，目标系统必须做什麽？,”,系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流程图，数据字典和简要的算法表示系统的逻辑模型。,需求分析阶段必须交出完整准确的系统逻辑模型经用户确认后，再进入下一个阶段,应防止和克服急于着手进行具体设计。,系统分析员通常都是软件技术专家。,4.总体设计,关键问题：“,应该如何解决这个问题？,”,首先应考虑几种可能的解决方案：,（1）低成本的解决方案,系统只能完成最少必要的工作，不做额外工作。,（2）中等成本的解决方案,除很好完成预定的任务，使用方便，而且还有附加的额外功能。,（3）高成本的“十全十美”的系统,该系统具有用户可能希望有的所有功能和特点。,系统分析员用系统流程图或其他工具描述每种可能的系统，估计每种方法的成本和效益。充分权衡各种方案利弊，推荐一个较好的系统方案。,另一项工作是程序实现模块化，一个大程序应由许多规模适中，模块合理的层次结构。准确的设计软件结构，即确定某些模块和模块间的关系，通常用层次图或结构图描绘软件的结构。,5.详细设计,总体设计以比较抽象概括的方式提出了解决问题的办法，详细设计的任务是把解法具体化。具体的任务是设计出程序的详细规格说明，通常用HIPO图（层次图加输入/处理/输出图）或PDL语言（过程设计语言）描述详细设计结果。,6.编码和单元测试,程序员根据系统要求，选定开发平台把详细设计的结果翻译成选定的语言书写程序，并仔细测试编写的每个模块。,7.综合测试,通过各种类型的测试是软件达到预定的要求。,集成测试:,根据软件结构，把模块按某种选定的策略,装配起来,装配过程中对程序进行必要的测试,基本测试,验收测试:,按照规格说明书的规定，由用户（或在用户,积极参加下）对目标系统进行验收,8软件维护,通常有四类的维护：,改正性维护 适应性维护,完善性维护 预防性维护：修改软件为将来的维护活动预先作准备,软件生存期模型（描述软件过程）,瀑布模型(waterfall model),瀑布模型是将软件生存周期各活动规定为依线性顺序联接的若干阶段的模型。它包括：可行性分析、项目开发计划、需求分析、概要设计、详细设计、编码、测试和维护。,它规定了由前至后、相互衔接的固定次序，如同瀑布流水，逐级下落。,可行性研究与计划,需求分析,设计,编码,运行维护,测试,定义,阶段,开,发,阶,段,维护阶段,有人把软件维护看成为软件的二次开发，把开发活动和维护活动区别开来，便有了,“b”,型软件生存期模型。,瀑布模型的特点,1970年，W.Royce提出瀑布模型。,特征：,活动的输入来自上一活动的输出；完成该项活动的内容；活动的输出传给下一活动；对活动的实施工作进行评审。,阶段间具有顺序性和依赖性。,适合：,需求明确的任务。,优点：,以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证了软件产品及时交付，并达到预期的质量要求。,缺点：,成品时间长；缺乏灵活性。,*演化模型(Evolutional Model),克服瀑布模型缺点，减少由于软件需求不明确而给开发工作带来风险方面有明显效果。,原型模型,（快速原型模型）,原型范型,用户测试,运行原型,建造/修改,原型,听取用,户意见,采用原型模型的软件生存周期,分析定义,系统需求,生成,原型,系统,设计,程序,设计,编码,测试,运 行,和维护,原型化,含原型化的,软件,生存期,需求分析,系统设计,程序设计,编 码,运行与维护,可接受性测试,系统测试,单元与集成测试,需求验证,设计确认,V模型,V,模型是瀑布模型的变型,，表现了验证测试活动与分析和设计间关系。,模型左侧与右侧的联系表明若在确认和验证过程中发现了问题，,V,模型的左侧需要重新被执行。,换句话说，,V,模型隐含在瀑布模型中迭代和再工作的明确化。,瀑布模型关注,:,过程和产品，,V,模型关注,:,活动和正确性。,阶段式开发：增量和迭代模型,系统设计时分片交付，可使用户在使用某些基本功能的同时，开发剩余的功能。,这样通常会并行地存在两个系统：,生产系统,和,开发系统,。,运行或生产系统是当前被客户或用户所使用的系统。,开发系统是准备用于替代当前生产系统的下一个版本。,创建版本1,创建版本2,创建版本3,使用版本1,使用版本2,使用版本3,开发者,使用者,阶段式开发：增量和迭代模型,阶段式开发：增量和迭代模型,增量开发,迭代开发,螺旋模型,螺旋模型,将瀑布模型,与,增量模型,结合起来，加入了两种模型均忽略了的风险分析，弥补了这两种模型的不足。,螺旋模型是一种,风险驱动的模型,。,螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。,螺旋模型适合于,大型软件的开发,。,螺旋模型(Spiral model ),加入风险分析,1，制定计划,2，风险分析,3，实施工程,4，客户评估,面向对象的开发模型,对象技术,为软件工程基于构件的过程模型提供了技术框架。,面向对象范型,强调了类的创建，类封装了数据和用于操纵该数据的算法。如果经过合适的设计和实现，面向对象的类可以在不同的应用及基于计算机的系统结构中复用,。,面向对象模型,融合了螺旋模型的许多特征。,它本质上是演化的，支持软件开发的迭代方法。,软件开发的固有特征：,1、迭代,多次重复、演进。,2、无间隙,各阶段间无明显的界限。支持分析和设计结果的自然复用。,适用,：面向对象的软件开发过程。,喷泉模型,（Water fountain model）,喷泉模型,界面叠代划分不严格清楚,变换模型,变换模型是一种适合于形式化开发方法的模型。,从软件需求形式化说明开始，经过一系列变换，最终得到系统的目标程序。,模型检查,软件需求形式化说明（M,0,）,软件需求形式化说明（M,1,）,（M,2,）,程序,（M,n,）,变换,变换,变换,变换模型,(1)该模型只适合于软件的形式化开发方法。,(2)必须有严格的数学理论和形式化技术支持。,(3)缺乏相应的支持工具，处于手工处理方式。,(4)尚处于研究和实验阶段，离使用尚有一定距离。,(5)对软件开发人员要求较高。,变换模型的特点,也称为基于知识的软件开发模型：,1、是知识工程与软件工程在开发模型上结合的产物,2、要建立知识库/专家系统,将模型本身、软件工程知识和特定领域的知识分别存入知识库，由此构成某一领域的软件开发系统。,智能模型,软件过程,可定义为人们用来开发和维护软件以及相关产品（如：工程计划、设计文档、规章、检测事例及用户手册）的一组活动、方法、实践及转换。,软件过程重要性的提高已经引起了对软件过程改进的要求，这就需要过程分析和评估的方法。,(1)软件工程过程(Software Engineering Process),软件工程过程是为获得软件产品，在软件工具支持下由软件工程师完成的一系列软件工程活动。软件工程过程通常包含四种基本的过程活动：,P(Plan)：软件规格说明。规定软件的功能及其运行的限制；,D(Do)：软件开发。产生满足规格说明的软件；,C(Check)：软件确认。确认软件能够完成客户提出的要求；,A(Action)：软件演进。为满足客户的变更要求，软件必须在使用的过程中演进。,事实上，软件工程过程是一个软件开发机构针对某一类软件产品为自己规定的工作步骤，它应当是科学的、合理的，否则必将影响到软件产品的质量。,Rational 统一过程（RUP）,由Rational推出的一种完整的软件过程。,六条最有效的开发经验,（迭代式开发、管理需求、使用基于构件的体系结构、,可视化建模、验证软件质量、控制软件变更）,RUP软件开发生命周期,二维的生命周期模型，纵轴：核心工作流（9个），,横轴：时间；,RUP软件生命周期：分四个连续阶段 初始、精化、构建、移交；,RUP（Rational Unified Process，统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。,纵轴以内容组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。,通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；,敏捷过程,（01年17位软件专家起草宣言）,与极限（XP）编程,极限编程是敏捷过程中最有名的一个,含义：把好的开发时间运用到极致。,XP（Extreme Programming），是由Kent Beck大师提出的。大师在经历传统软件开发的痛苦之后，希望能够找到一种优秀的软件开发方法。他总结了大量软件的成功和失败因素之后，提出了改进软件开发方法的四个要素：,沟通（communication）、简单化（simplicity）、,反馈（feedback）、勇气（courage）。,形成了XP的核心价值观。在经历了数年的发展，XP在软件开发的各方面都发展出了众多的方法来支持软件开发。,微软过程,微软过程准则、微软生命周期（5个阶段）、微软过程模型,相对于传统过程，敏捷更强调快速灵活反应，主动迎接适应变化，主张客户和开发商的紧密合作，以人为本的企业可持续发展。典型敏捷包括：XP、FDD（特性驱动开发）、Scrum、AUP（敏捷的统一过程）,软件生存期过程,国际标准定义的软件生存过程（,1995 ISO/IEC 12207,）,软件生存期过程,支持过程,组织过程,主要过程,获,取,过,程,供,应,过,程,开,发,过,程,运,行,过,程,维,护,过,程,文,档,编,制,过,程,配,置,管,理,过,程,质,量,保,证,过,程,验,证,过,程,确,认,过,程,联,合,评,审,过,程,审,核,过,程,问,题,解,决,过,程,管,理,过,程,基,础,设,施,过,程,改,进,过,程,培,训,过,程,过程名,执行者,活动内容,获取,过程,项目委托方,确定需求；招标；签订合同；对供应方的监督；验收完成。,供应,过程,项目承包方,理解需求；投标；签订合同；计划；实施；控制；评审评价；交付。,开发,过程,软件开发人员,过程实施准备；系统需求分析；系统结构设计；软件需求分析；软件体系结构设计；软件详细设计；软件编码和测试；软件集成；软件合格测试；系统集成；系统合格测试；软件安装；验收支持。,运行,过程,用户,运行准备；运行测试；产品转移；运行；运行支持；运行评价。,维护,过程,维护人员,过程实施准备；问题分析和修改设计；修改实施；对维护的评审和验收；软件移植；软件退役。,过程名,执行者,活动内容,文档过程,1.由软件开发组织自己实施。,2.由独立的第三方机构实施。,3.作为一种服务由客户实施。,制订文档编制计划；设计和开发文档；制作和发行文档；文档维护。,配置管理过程,确定软件配置项和基线；控制配置项的修改和交付；记录配置项的完成和修改情况；保证配置项的完整、相容和正确性；控制配置项的存储和提交。,质量保证过程,软件产品质量保证；软件过程质量保证。,验证过程,合同验证；过程验证；需求验证；设计验证；代码验证；集成验证；文档验证。,确认过程,类似于验证的活动，区别是：确认针对软件是否正确地满足客户的要求，验证针对软件是否按照规范要求开发。,评审过程,项目管理评审；技术评审,审计过程,问题解决过程,课时数少的班级到本页结束！,1,进行审查和复审的必要性,由于人的认识不可能百分之百的符合客观实际，因此，在每个阶段的工作中都,会发生错误，然而前一阶段的成果是后一阶段的工作基础。前一阶段的错误自然导致,后一阶段的工作结果中有相应的错误。造成错误积累，软件错误的积累与放大效应。,2,技术审查的标准和方法,通常由技术专家组组成审查小组。,审查小组：组长，作者，两名评审员。,组 长,：组织和领导技术审查的全过程，安排会议日程，分发文档,主持会议，,确保全面公正。,作 者,：是课题组长，责任是回答技术上的问题。,评审员,：也是由技术专家担任。,审查过程,准备简要介绍情况，阅读被审查的文档，开审查会，返工复查,（审查会一般不超过,90,分钟）。,补充一：技术审查和管理审查,1 软件风险的定义,软件风险的严格的定义还存在许多争议，但在风险中包含了两个特性：,1.不确定性-刻化风险的事件可能发生，也可能不发生；,2.损失-如果风险变成了现实，就会产生恶性后果和损；,2 软件风险的种类,软件风险的种类有两种：一般性风险和特定产品的风险,一般性风险,对每一个软件项目而言都是一个潜在的威胁；,特定产品的风险,只有那些对当前项目的技术、人员、及环境非常了解的人才能识别出来；,3 软件风险的识别,识别风险的一个方法是建立风险条目检查表，该表可以用于识别风险,“如果你不主动攻击风险，风险就会主动攻击你”,补充二,：,软件风险,4 软件风险的识别表内容,1）.产品规模风险,对于估算出的产品规模的信任度如何？,是否以程序、文件或事务处理的数目来估算产品规模？,产品的规模与以前的产品规模平均值的偏差百分比是多少？,产品创新或使用的数据库大小如何？,产品的用户数是多少？,产品需求改变了多少？,复用的软件有多少？,2）、商业影响风险,本产品对公司的收入有何影响？,本产品是否得到公司高级管理层的重视？,交付期限是否合理？,将会使用本产品的用户数及本产品是否与用户的需要相符合？,本产品必须能与之互操作的其他产品/系统的数目？,最终用户水平如何？,必须产生并交付给用户的产品文档的量与质如何？,政府对本产品开发的约束？,延迟交付所造成的成本消耗是多少？,产品缺陷所造成的成本消耗是多少？,3）,、客户相关的风险,你以前是否曾与该客户合作过,该客户是否很清楚需要什么，他是否花时间把需求写出来,该客户是否同意花时间召开正式的需求收集会议，以确定项目范围,该客户是否愿意建立与开发者之间的快速通信渠道,该客户是否愿意参加复审工作,该客户是否具有该产品领域的技术素养,该客户是否愿意让你的人来做他们的工作，即，当你的人在做具体的技术工作时，该客户是否会坚持在旁边监视,该客户是否了解软件过程,4）、技术风险,该技术对于你的组织而言是新的吗？,客户的需求是否需要创建新的算法或输入、输出技术？,软件是否需要是否使用新的或未经证实的硬件接口？,待开发软件是否需要与开发商提供的未经证实的软件产品接口？,待开发软件是否需要与其功能及性能均未在本领域中得到证实的数据库系统接口？,产品的需求中是否要求采用特定的用户界面？,产品的需求中是否要求开发某些程序构件，这些构件与你的组织以前所开发过的构件完全不同？,需求中是否要求使用新的分析、设计、或测试方法？,需求中是否要求使用非传统的软件开发方法，如形式化方法、基于AI的方法、以及人工神经网络？,需求中是否有过分的对产品的性能约束？,客户能否确定所要求的功能是“可行的”吗？,5）、开发环境风险,是否有可用的软件项目管理工具,是否有可用的软件过程管理工具,是否有可用的分析及设计工具,分析及设计工具是否支持适用于待建造产品的方法,是否有可用的编译器或代码生成器，且适用于待建造产品,是否有可用的测试工具、且适用于待建造产品,是否有可用的软件配置管理工具,环境是否利用了数据库或数据仓库,是否所有软件工具都是彼此集成的,项目组的成员是否已经接受过关于工具的培训,是否有相关的专家能够回答关于每个工具的培训,工具的联机帮助及文档是否适当,6）、与人员数目及经验相关的风险,是否有最优秀的人员可用,人员在技术上是否配套,是否有足够的人员可用,开发人员是否能够自始自终的参加整个项目的工作,项目中是否有一些人员只能部分时间工作,开发人员对自己的工作是否有正确的期望,开发人员是否接受过必要的培训,开发人员的流动是否仍能保证工作的连续性,