资源描述
Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,第2章 软件生存周期,2.1,软件工程过程,2.2,软件生存周期,2.3,软件生存周期瀑布模型,2.4,软件生存周期原型模型,2.5,软件生存周期其他模型,2.1 软件工程过程,2.1.1,什么是软件工程过程,软件工程是一种层次化的技术。如图,2.1,所示,图,2.1,软件工程层次,软件过程定义了一组关键过程域,它们构成软件项目管理的基础,并规定了技术方法的采用、工程产品(模型、文档、数据、报告以及表格等)的产生、里程碑的建立、质量的管理以及适当的变更控制。,2.1 软件工程过程,软件过程是软件生存期中的一系列相关软件工程活动的集合。每一个软件过程又是由一组工作任务、项目里程碑、软件工程产品和交付物以及质量保证(,SQA,)点等组成。一个软件过程可以用图,2.2,的形式来表示。,图,2.2,软件过程,2.1 软件工程过程,2.1.2,软件过程模型,软件工程过程模型的选择基于项目和应用的特点、采用的方法和工具、要求的控制和需交付的产品,.,所有的软件开发都可以看成是一个问题循环解决过程,如图,2.3,所示。,其中包括四个截然不同的阶段:状态捕获、问题定义、技术开发和方案综合。状态捕获表示了事物的当前状态;问题定义标识了需要解决的特定问题;技术开发利用某些技术来解决问题;方案综合导出最终的结果(如文档、程序、数据、新的事务功能、新的产品)。,2.1 软件工程过程,以上的问题循环解决过程可以用于软件工程的不同开发级别上。它可用于考虑整个应用系统的宏观级,也可用于建造程序构件的中间级,甚至还可用于源代码行级。因此,可以用分级几何表示来给出过程的理想化的视图。首先定义一个分级几何表示的模式,然后相继地在更小的规模上递归地应用分级几何表示:模式中嵌套模式。在图,2.4,中,问题循环解决过程的每一个阶段又包含一个同样的问题循环解决过程,该循环中每一个步骤中还可以再包含另一个问题循环解决过程。这样一直继续下去,直到某个合理的边界为止。对于软件来说,就是源代码行。,2.1 软件工程过程,图,2.4,问题循环解决过程中阶段嵌套阶段,2.1 软件工程过程,2.1.3,过程建造技术,为了使得软件过程模型适合于软件项目组的使用,需要开发一些过程技术工具,以帮助软件开发组织分析它们当前的过程,组织工作任务,控制和监控进度,管理技术质量。,使用过程技术工具,可以建造一个自动模型,模型包含前面提到的公共过程框架、任务集合及保护伞活动。该模型一般表示成一个网络,对其加以分析,就能够确定典型的工作流程,考察可能导致减少开发时间、降低开发成本的可选的过程结构。,一旦创建了一个可接受的过程,就可以使用其他过程技术工具来分配、监视、甚至控制在软件过程模型中定义的所有软件工程任务。软件项目组的每一个成员都可以使用这样的工具来开发检查表,列出所有将要执行的工作任务、将要产生的工作产品和将要实施的软件质量保证活动。,2.2 软件生存周期,如同任何事物一样,软件也有一个孕育、诞生、成长、成熟、衰亡的生存过程。软件产品从形成概念开始,经过开发、使用和维护,直到最后退役的全过程称为软件生存周期。根据这一思想我们可以得到软件生存周期的三个时期:软件定义、软件开发、软件使用与维护,如图,2.5,所示。,图,2.5,软件生存周期,2.2 软件生存周期,2.2.1,软件定义,软件定义可分为软件系统的可行性研究和需求分析两个阶段,:,软件系统的可行性研究,可行性研究的任务是了解用户要求和现实环境,从技术、经济、市场等方面研究并论证开发该软件系统的可行性。即这个软件系统是否值得开发,是否有可行的技术去开发。,系统分析员一般需通过以下途径完成此阶段的任务,:,调查和了解用户要求和现实环境。,撰写调查报告。,可行性论证和分析(技术可行性、操作可行性和经济可行性)如可行,制定初步项目开发计划(成本估算、人员组织、进度安排等)。,2.2 软件生存周期,需求分析,这个阶段的任务主要是确定待开发软件的功能需求、性能需求和运行环境约束、编制软件需求规格说明、软件系统的确认测试准则和用户手册概要。软件的功能需求应该指明软件必须完成的功能。软件的性能需求包括:软件的安全性、可靠性、可维护性、精度、错误处理、适应性及用户培训等。软件系统的运行环境约束指软件系统必须满足的运行环境方面(硬件环境、系统平台)的要求。,2.2 软件生存周期,软件需求分析不仅是软件开发依据,而且也是软件验收的标准。,系统需求一般由用户提出。由于用户往往缺乏软件开发的知识和经验,系统分析员和软件开发人员不得不与用户反复讨论、协商、使用户需求逐步精确化、一致化、完全化。,需求分析的一项重要任务是建立面向开发者的软件需求规格说明(,Software Requirements Specification,,简称,SRS,)。多数场合面向开发者的软件需求用需求规格说明语言描述。,SRS,应该指明软件系统的功能需求、性能需求、接口需求、设计需求、基本结构,以及开发标准和验收原则,等等。,SRS,是软件开发的基础,建立,SRS,是软件开发成败的关键。,2.2 软件生存周期,2.2.2,软件开发,在软件生存周期模型中,软件开发由概要设计、详细设计、实现、集成测试和确认测试五个阶段组成。,概要设计,概要设计的任务是根据软件需求规格说明(,SRS,)建立软件系统的总体结构和模块间的关系,定义各功能模块的接口,设计全局数据库或数据结构,规定设计约束,制定组装测试计划。对于大型软件系统,应对软件需求进行分解,将其划分为若干个子系统,对每个子系统定义功能模块和各功能模块之间的关系,并给出各子系统接口界面的定义;对于一般的软件系统可以直接定义各功能模块以及它们之间的关系,概要设计应提供概要设计说明书、数据库或数据结构设计说明书、组装测试计划等文件。,2.2 软件生存周期,详细设计,详细设计的任务是对概要设计产生的功能模块逐步细化,形成若干个可编程的程序模块,用某种过程设计语言(,Procedure Design Language,)设计程序模块的内部细节,包括算法、数据结构和各程序模块之间的详细接口信息,为编写源代码提供必要的说明,建立“模块开发卷宗”,拟定模块测试方案。,详细设计需根据软件需求规格说明(,SRS,)和概要设计的结果进行,可以选用的方法和工具是比较多的,如结构化的设计方法、面向对象的设计等方法和,Rationa Rose,、,VisualModel,及,Microsoft Visio,等工具。软件开发人员可以根据实际情况选用适当的方法和工具。详细设计应该遵循的原则是:设计应与软件需求保持一致,设计的软件结构应支持模块化、信息隐藏等。,详细设计应该提供详细设计规格说明书和单元测试计划。,2.2 软件生存周期,实现,实现的主要任务是,根据详细设计文档将详细设计转化为所要求的编程语言或数据库语言的程序,并对这些程序进行调试和程序单元测试,验证程序模块接口与详细设计文档的一致性。,集成测试,集成测试的任务是根据概要设计各功能模块的说明及制定的集成测试计划,将经过单元测试的模块逐步进行集成和测试。集成测试应对系统各模块间的连接正确性进行测试;测试软件系统或子系统的输入输出处理是否达到设计要求;测试软件系统或子系统正确处理能力和承受错误的能力等。,通过集成测试的软件应生成满足概要设计要求、可运行的系统源程序清单和集成测试报告,。,2.2 软件生存周期,确认测试,确认测试的任务是根据软件需求规格说明定义的全部功能和性能要求及软件确认测试计划对软件系统进行测试,测试系统是否达到了系统需求或是否满足用户的需求。,确认测试应有客户参加,以软件需求规格说明书为依据,使用专用的测试工具进行确认测试。为验证软件产品是否满足软件需求规格说明的要求,必须按照测试计划的要求编制大量的测试用例、采用多种方法和工具、组织专门的测试队伍并严格组织实施。,确认测试阶段应向用户提交最终的用户手册、操作手册、源程序清单及其他软件文档。确认测试结束时应生成确认测试报告、项目开发总结报告。,2.2 软件生存周期,2.2.3,软件使用、维护和退役,软件的使用,将软件安装在用户确定的运行环境中,测试通过后移交用户使用。软件的使用是软件发挥社会和经济效益的重要阶段。由于软件是逻辑产品,软件发行的份数越多,软件的社会和经济效益越显著。因此应大力推广软件的使用。软件在使用过程中客户或维护人员必须认真收集被发现的软件错误,定期或阶段性地撰写“软件问题报告”和“软件修改报告”。,软件的维护,当发现软件产品中的潜伏错误,或用户提出要对软件需求进行修改,或软件运行环境发生变化时,都需要对软件进行维护。软件维护不仅针对程序代码,而且还针对软件定义、开发的各个阶段生成的文档软件在设计阶段很难预料到这个软件交给谁,在什么时候进行什么样的维护工作。,2.2 软件生存周期,软件维护的依据只能靠软件文档和有关的设计信息。这样,软件维护人员不得不花费大量的劳动,用于软件系统的再分析和对软件信息的理解。软件的维护直接影响软件的应用和软件的生存期,而软件的可维护性又与软件的设计密切相关,因此软件在开发过程中应该重视对软件可维护性的支持。,软件的退役,软件的退役是软件生存周期中的最后一个阶段,即终止对软件产品的支持,停止使用该软件。,2.3 软件生存周期瀑布模型,瀑布(,waterfall model,)模型也称软件生存周期模型(如图,2.6,所示),由,W,Royce,于,1970,年首先提出。根据软件生存周期各个阶段的任务,瀑布模型从可行性研究(或称系统分析)开始,逐步进行阶段性变换,直至通过确认测试并得到用户确认的软件产品为止。瀑布模型上一阶段的变换结果是下一阶段变换的输入,相邻两个阶段具有因果关系,紧密相联。一个阶段工作的失误将蔓延到以后的各个阶段。为了保障软件开发的正确性,每一阶段任务完成后,都必须对它的阶段性产品进行评审,确认之后再转入下一阶段的工作。评审过程发现错误和疏漏后,应该反馈到前面的有关阶段修正错误、弥补疏漏,然后再重复前面的工作,直至某一阶段通过评审后再进入下一阶段。,瀑布模型在软件工程中占有重要的地位,它提供了软件开发的基本框架,它有利于大型软件开发过程中人员的组织、管理,有利于软件开发方法和工具的研究与使用,从而提高了大型软件项目开发的质量和效率。,2.3 软件生存周期瀑布模型,图,2.6,软件生存周期的瀑布模型,2.3 软件生存周期瀑布模型,瀑布模型的主要缺点如下,:,在软件开发的初始阶段指明软件系统的全部需求是困难的,有时甚至是不现实的。而瀑布模型在需求分析阶段要求客户和系统分析员必须做到这一点才能开展后续阶段的工作。,需求确定后,用户和软件项目负责人要等相当长的时间(经过设计、实现、测试、运行)才能得到一份软件的最初版本。如果用户对这个软件提出比较大的修改意见,那么整个软件项目将会蒙受巨大的人力、财力和时间方面的损失。瀑布模型的应用有一定的局限性。,2.4,软件生存周期原型模型,由于在软件开发的初始阶段人们对软件的需求认识常常不够清晰,因而使得所开发的软件项目难于做到一次性开发成功,出现返工再开发在所难免,这样会造成软件开发进度的延长、开发成本的上升。因此,我们可以先做试验开发,其目标只是在于探索可行性,弄清软件需求,然后在此基础上获得较为满意的软件产品。通常我们把第一次得到的试验性产品称为“原型”。,软件开发人员根据客户提出的软件定义,快速地开发一个原型,它向客户展示了待开发软件系统的全部或部分功能和性能,在征求客户对原型意见的过程中,进一步修改、完善、确认软件系统的需求并达到一致的理解。,2.4,软件生存周期原型模型,快速开发原型的途径有三种:,利用个人计
展开阅读全文