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

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