软件工程第二章 软件生存周期及模型ppt课件

1、1软件生存周期及模型第二章第二章2一、软件工程研讨内容序序号号研讨方面研讨方面详细内容详细内容1软件开发软件开发模型模型如：瀑布模型、增量模型、迭如：瀑布模型、增量模型、迭代模型代模型2软件开发软件开发方法方法如：面向过程方法、面向数据如：面向过程方法、面向数据方法、面向对象方法方法、面向对象方法3软件支持软件支持过程过程如：如：CASE工具工具Rose、北大青、北大青鸟系统、鸟系统、PowerDesigner4软件管理软件管理过程过程如：如：ISO9000、CMM、软件企、软件企业文化业文化31、软件生存周期(Life cycle) 软件有一个孕育、诞生、生长、成熟、软件有一个孕育、诞生、生

2、长、成熟、衰亡的生存过程。衰亡的生存过程。 软件生存周期通常包括可行性研讨和工软件生存周期通常包括可行性研讨和工程开发方案、需求分析、概要设计、详细程开发方案、需求分析、概要设计、详细设计、编码、测试、维护等活动设计、编码、测试、维护等活动GB8567中规定。中规定。4定义定义分析分析蓝图、图表、库蓝图、图表、库存、采购单等存、采购单等设计设计实现实现产品产品52、软件生存周期模型概念l模型是为了了解事物而对事物作出的一种笼模型是为了了解事物而对事物作出的一种笼统，它忽略了不用要的细节，是事物的一种统，它忽略了不用要的细节，是事物的一种笼统方式笼统方式 。n软件生存周期模型是描画软件开发过程中

3、各种软件生存周期模型是描画软件开发过程中各种活动如何执行的模型。它确立了软件开发和演活动如何执行的模型。它确立了软件开发和演绎中各阶段的次序以及各阶段活动的准那么，绎中各阶段的次序以及各阶段活动的准那么，确立开发过程所必需遵守的规定和限制等。确立开发过程所必需遵守的规定和限制等。n目前有瀑布模型、增量模型、螺旋模型、目前有瀑布模型、增量模型、螺旋模型、喷泉模型、变换模型和基于知识的模型等。喷泉模型、变换模型和基于知识的模型等。2022-4-2963、软件工程的传统途径维维 护护开开发发定定义义DefinitionDefinitionFeasibility StudyFeasibility St

4、udyRequirements AnalysisRequirements AnalysisProgram DesignProgram DesignCoding & Module TestingCoding & Module TestingIntegration & System TestingIntegration & System TestingDelivery & MaintenanceDelivery & MaintenanceSystem DesignSystem Design7二、瀑布模型瀑布模型瀑布模型1970年由W.Royce提出n

5、瀑布模型是传统软件瀑布模型是传统软件工程的根底。工程的根底。n瀑布模型的根本思想瀑布模型的根本思想是将软件生命周期划是将软件生命周期划分为假设干明确定义分为假设干明确定义的阶段。每一阶段活的阶段。每一阶段活动具有严厉性，要实动具有严厉性，要实施评审任务，以便及施评审任务，以便及早发现错误，矫正错早发现错误，矫正错误误 ；n以文档方式驱动的，以文档方式驱动的，上一阶段的结果作为上一阶段的结果作为本阶段的输入本阶段的输入 ；软件维护报告软件维护报告要求定义要求定义确认确认设计设计确认确认编码编码确认确认测试测试确认确认维护维护确认确认测试报告测试报告源程序清单源程序清单设计阐明书设计阐明书需求阐明

6、书需求阐明书81、软件定义时期根本义务：回答根本义务：回答 要处理的问题是什么？该问题有要处理的问题是什么？该问题有行的通的处理方法吗？假设有处理问题的方法，行的通的处理方法吗？假设有处理问题的方法，那么需求多少费用、资源、时间？那么需求多少费用、资源、时间？终了规范：提出关于问题性质、工程目的和规模终了规范：提出关于问题性质、工程目的和规模的问题定义书面报告；提出可行性研讨报告；假的问题定义书面报告；提出可行性研讨报告；假设问题值得去处理，制定工程开发方案。设问题值得去处理，制定工程开发方案。可行性研讨和工程开发方案可行性研讨和工程开发方案需求分析需求分析根本义务：回答根本义务：回答“为理处

7、理这个问题，目的系统必为理处理这个问题，目的系统必需做什么，确定目的系统的功能。需做什么，确定目的系统的功能。终了规范：给出软件需求阐明书终了规范：给出软件需求阐明书92、软件开发时期系统设计概要设计概要设计根本义务：回答根本义务：回答 “概括地说，应如何处理这个问概括地说，应如何处理这个问题。把确定的各项功能需求转换成需求的体系题。把确定的各项功能需求转换成需求的体系构造。设计软件的构造，确定程序由哪些模块组构造。设计软件的构造，确定程序由哪些模块组成及模块间的关系，同时设计该工程的运用系统成及模块间的关系，同时设计该工程的运用系统的总体数据构造和数据库构造。的总体数据构造和数据库构造。终了

8、规范：给出概要设计文档。终了规范：给出概要设计文档。详细设计详细设计根本义务：回答根本义务：回答 “应怎样详细地实现这个系统。应怎样详细地实现这个系统。为每个模块完成的功能进展详细描画，把功能描为每个模块完成的功能进展详细描画，把功能描画转变为准确的、构造化的过程描画。画转变为准确的、构造化的过程描画。终了规范：设计出程序的详细规格阐明。终了规范：设计出程序的详细规格阐明。102、软件开发时期系统实现编码编码根本义务：把每个模块的控制构造转换成计算机根本义务：把每个模块的控制构造转换成计算机可接受的程序代码。写出的程序应是构造好，明可接受的程序代码。写出的程序应是构造好，明晰易读，并且与设计一

9、致。晰易读，并且与设计一致。终了规范：以某种程序设计言语表示的源程序清终了规范：以某种程序设计言语表示的源程序清单。单。测试测试根本义务：经过各种类型的测试使软件到达预定根本义务：经过各种类型的测试使软件到达预定的要求。的要求。终了规范：软件合格，能交付用户运用。终了规范：软件合格，能交付用户运用。113、软件维护时期根本义务：经过各种必要的维护活动使系根本义务：经过各种必要的维护活动使系统耐久地满足用户需求。统耐久地满足用户需求。124、技术审查和管理复审 v技术审查是从技术角度进展的审查，是保证软件质量和降低软件本钱的重要措施。在每一阶段终了前进展，对于继续时间很长的开发阶段，在阶段中间还

10、要根据需求进展多次正式的或非正式的技术审查。技术审查通常由技术专家组成的审查小组来承当审查任务。审查过程包括：预备和阅读被审文档、开审查会、返工、复查。 v管理复审的主要义务是在软件生存周期的每个重要的里程碑，对工程工程的本钱、实践破费的经费、投资回收的前景、工程的进度等经济要素从管理角度进展审查。从管理角度对软件开发工程进展复审，是对工程进展管理和控制的主要手段，对发现的问题可以及时采取措施加以处理，必要时甚至可以取消开发工程以防止更大的损失。13名词名词解释解释软件任软件任务产品务产品在在CMMCMM中，它是软件开发活动中的人工制品，如需求阐明书、概要设计中，它是软件开发活动中的人工制品，

11、如需求阐明书、概要设计阐明书、详细设计阐明书、源程序、测试报告、用户手册，也包括软件阐明书、详细设计阐明书、源程序、测试报告、用户手册，也包括软件管理文档，如软件开发方案、软件质量保证方案、各种评审报告、里程管理文档，如软件开发方案、软件质量保证方案、各种评审报告、里程碑报告、变卦恳求表、不符合项跟踪报告等。碑报告、变卦恳求表、不符合项跟踪报告等。软件产品软件产品在在CMMCMM中软件产品是最终用户运用的软件。它是软件任务产品的一部分。中软件产品是最终用户运用的软件。它是软件任务产品的一部分。基线基线它是软件任务产品。它是要经内部和外部评审过的，并且是下一阶段任它是软件任务产品。它是要经内部和

12、外部评审过的，并且是下一阶段任务的根底，一根基线是一个里程碑或一个检查点。务的根底，一根基线是一个里程碑或一个检查点。检查点检查点它是由时间、方案、事件驱动的检查任务进度和质量的一个记号，一个它是由时间、方案、事件驱动的检查任务进度和质量的一个记号，一个检查点不一定是基线或里程碑。检查点不一定是基线或里程碑。里程碑里程碑它是一个记号，只需经过内部评审。它是一个检查点，但不一定是基线。它是一个记号，只需经过内部评审。它是一个检查点，但不一定是基线。评审评审是对软件任务产质量量的一次开会或汇签活动。是对软件任务产质量量的一次开会或汇签活动。审计审计是复查评审活动程序的合法性，能否按程序与规范进展。

13、是复查评审活动程序的合法性，能否按程序与规范进展。顾客顾客 客客户户 用户用户客户是顾客的一部分，顾客包括潜在的客户。用户是软件产品的最终运客户是顾客的一部分，顾客包括潜在的客户。用户是软件产品的最终运用者，用户是客户的一部分。用者，用户是客户的一部分。现有系统现有系统目的系统目的系统现有系统是用户当前正在运用的系统能够是手工系统；目的系统是现有系统是用户当前正在运用的系统能够是手工系统；目的系统是将要实现的系统。将要实现的系统。Capability Maturity Model forsoftware145、瀑布模型特点l是一个理想化过程。会粉饰工程中真正的风险，是一个理想化过程。会粉饰工程

14、中真正的风险，当他太晚发现它们时已无济于事。当他太晚发现它们时已无济于事。l 过程逆转性很差，由于上游的错误解在下游进过程逆转性很差，由于上游的错误解在下游进展发散性传播。所以逆转会呵斥很大损失。展发散性传播。所以逆转会呵斥很大损失。l缺乏灵敏性缺乏灵敏性; ;特别是无法处理软件需求不明确或特别是无法处理软件需求不明确或不准确的问题后期错误，修正代价高不准确的问题后期错误，修正代价高 。l纯瀑布模型的缺陷是在工程开场的时候，在设纯瀑布模型的缺陷是在工程开场的时候，在设计任务完成前和代码写出来前，很难充分描画计任务完成前和代码写出来前，很难充分描画需求。需求。l瀑布模型最主要的问题是缺乏灵敏性。

15、必需在瀑布模型最主要的问题是缺乏灵敏性。必需在工程开场前阐明全部需求。但这恰恰是非常困工程开场前阐明全部需求。但这恰恰是非常困难的。难的。6、瀑布模型适用场所l当有一个稳定的产品定义和很容易被了解的技术处理方案时，纯瀑布模型特别适宜l当他对一个定义得很好的版本进展维护或将一个产品移植到一个新的平台上，瀑布模型也特别适宜。l纯瀑布模型可以降低管理费用，由于他可以预先完成一切方案。l对于那些容易了解但很复杂的工程，采用纯瀑布模型比较适宜，由于可以用顺序方法处置问题。l在质量需求高于本钱需求和进度需求的时候，它尤为出色。l当开发队伍的技术力量比较弱或者缺乏阅历时，瀑布模型更为适宜。15167、瀑布模

16、型变种：V型模型178、瀑布模型变种：生鱼片模型软件概念需求分析架构设计详细设计编码和调试系统测试188、瀑布模型变种：生鱼片模型l传统的瀑布模型强调阶段之间最小的重叠，而生鱼片模型强调大幅度的重叠，即在需求分析完成之前就可以进展架构设计和部分详细设计l纯瀑布模型强调在恣意两个阶段交接时，文档从一个团队交给另一个完全隔离的团队，但是假设一个团队完成各个阶段义务时，可以没有那么多文档。l问题：缺陷是什么？l生鱼片模型由于阶段重叠，因此里程碑不明确，很难有效地进展过程跟踪和控制。199、瀑布模型变种：具有子工程的瀑布模型l纯瀑布模型的一个问题是必需完成全部的架构设计后才干进展详细设计，但是，整个系

17、统中有些部分能够有些特殊性，可以有本人的步骤，即将这些部分划分为为子工程。l问题：该模型有何问题？l这种方法的主要风险是相关性无法预料。2010、瀑布模型变种：可以降低风险的瀑布模型l纯瀑布模型要求在开场架构设计前，必需将用户的一切需求都搞清楚，但是实践中是很困难的。l可降低风险的瀑布模型是在顶端，即需求分析和架构设计阶段引入螺旋以便降低风险。l在该螺旋中，先开发一个用户界面原型，采用系统情节串联图版system storyboarding引导用户提出需求，记录用户与系统的交互操作方式，或者采用其它需求获取方法。21客户评价原型客户评价原型快速设计快速设计停顿停顿开场开场2223三、螺旋模型螺

18、旋模型是一种风险驱动的模型。螺旋模型需求有相当丰富的风险评价阅历和专门知识。2022-4-2924ReviewReviewCommitmentCommitmentPartitionPartitionRisk Risk analy-analy-sissisPrototype 1Prototype 1Simulations, models, benchmarksSimulations, models, benchmarksRequirements Requirements plan, life-cycle plan, life-cycle planplanConcept of Concept of

19、 operationoperationPrototype 2Prototype 2Risk Risk analysisanalysisSoftware Software requirementsrequirementsRequirements Requirements validationvalidationDevelop-Develop-ment planment planRisk Risk analysisanalysisPrototype 3Prototype 3Software Software product product designdesignDesign validation

20、 and Design validation and verificationverificationIntegration Integration and test planand test planRisk Risk analysisanalysisOperational Operational prototypeprototypeDetailed Detailed designdesignUnit Unit testtestCodeCodeIntegration and Integration and testtestAcceptance testAcceptance testImple

21、mentationImplementationPlan next phasesDevelop, verify next-level productDetermine objectives, alternatives, constrainsEvaluate alternatives, identify, resolve risksCumulative costCumulative costProgress through stepsProgress through stepsThe spiral The spiral modelmodel25螺螺旋旋模模型型决议目的、决议目的、方案和限制方案和限

22、制评价方案、评价方案、识别风险、识别风险、弱化风险弱化风险 开发、验证、下一级产品 方案下一阶段集成测试26四、增量模型123491011125678需求分析需求分析设计设计编码编码测试测试第第1 1块块第第1 1次集成次集成第第2 2次集成次集成第第3 3次集成次集成第第N N次集成次集成第第4 4次集成次集成第第1 1块块第第1 1块块第第1 1块块第第1 1块块第第N N块块第第4 4块块第第3 3块块第第2 2块块第第2 2块块第第2 2块块第第2 2块块第第3 3块块第第3 3块块第第4 4块块27四、增量模型遵照递增方式进展软件开发。开发一部分，向用户展现一部分。增量模型是一种非整

23、体开发的模型。适用条件：1运用面向对象言语或第四代言语；2需求能够发生变化，客户接受分阶段交付；3分析设计人员对运用领域不熟习，难以一步到位；4工程风险高；28五、原型模型-概念快速原型模型：先开发一个快速原型模型：先开发一个“原型软件，完原型软件，完成主要功能，展现给用户并征求意见，然后逐成主要功能，展现给用户并征求意见，然后逐渐完善。渐完善。探求型原型：用于需求分析阶段；探求型原型：用于需求分析阶段；实验型原型：用于设计阶段；实验型原型：用于设计阶段；演化型原型：软件开发全过程，及早向用演化型原型：软件开发全过程，及早向用户提交一个原型系统。户提交一个原型系统。原型运用方式：丢弃战略和附加

24、战略。原型运用方式：丢弃战略和附加战略。29五、原型开发过程-开发步骤原型开发步骤原型开发步骤:快速分析：分析人员与用户配合，迅速快速分析：分析人员与用户配合，迅速确定系统的根本要求。要根据原型所要表确定系统的根本要求。要根据原型所要表达的特征，描画根本需求。关键是要留意达的特征，描画根本需求。关键是要留意分析描画内容的选取。分析描画内容的选取。构造原型：在软件工具支持下尽快实现构造原型：在软件工具支持下尽快实现一个可运转的系统。一个可运转的系统。运转原型：是发现问题、消除误解、开运转原型：是发现问题、消除误解、开发者与用户充分协调的一个步骤。发者与用户充分协调的一个步骤。评价原型：评价原型的

25、特性，纠正误解评价原型：评价原型的特性，纠正误解与错误，增添新要求或提出要求变动，提与错误，增添新要求或提出要求变动，提出全面的修正意见。出全面的修正意见。修正：原型开发的循环。修正：原型开发的循环。30五、原型模型的评价原型的优点：原型的优点：可及早为用户提供有用的产品。可及早为用户提供有用的产品。可及早发现问题，随时纠正错误。可及早发现问题，随时纠正错误。减少技术、运用风险，缩短开发时间，减少技术、运用风险，缩短开发时间，减少费用。减少费用。促运用户自动参与开发活动，促进各促运用户自动参与开发活动，促进各类人员的协调，减少误解，顺应需求的类人员的协调，减少误解，顺应需求的变化，能有效提高系

26、统质量。变化，能有效提高系统质量。原型存在的问题：原型存在的问题：缺乏丰富而强有力的软件工具和开发缺乏丰富而强有力的软件工具和开发环境。环境。缺乏有效的管理机制，还未建立起本缺乏有效的管理机制，还未建立起本人的开发规范。人的开发规范。对设计人员程度和开发环境要求较高。对设计人员程度和开发环境要求较高。在多次反复改动原型的过程中，程序在多次反复改动原型的过程中，程序员会感到腻烦。员会感到腻烦。系统的易变性对测试有一定影响，难系统的易变性对测试有一定影响，难于做到彻底测试，更新文档较为困难。于做到彻底测试，更新文档较为困难。2022-4-2931五、原型模型五、原型模型-快速原型法快速原型法Pro

27、totypePrototypeFeedbackFeedbackModificationModification32快速原型模型需求分析需求分析需求阐明需求阐明设计阐明设计阐明源程序源程序软件产品软件产品设计设计编码编码测试测试维护维护快速分析快速分析需求阐明需求阐明原型原型修正意见修正意见修正类型修正类型构造原型构造原型运转原型运转原型评价原型评价原型停顿修正停顿修正修正阐明修正阐明修正原型修正原型33六、喷泉模型n主要用于采用面向对象技术的工程n喷泉表达迭代和无间隙的特征n软件的某些部分经常被反复任务多次，相关对象在每次迭代中随之参与渐进的软件成分n在分析、设计、实现等各项活动之间无明显边境

28、34六、喷泉模型六、喷泉模型35需求阶段需求阶段分析阶段分析阶段设计阶段设计阶段编程阶段编程阶段集成与测试阶段集成与测试阶段维护与演进阶段维护与演进阶段36七、迭代模型RUP模型Rational Unified Rational Unified ProcessProcess初始初始精化精化构建构建移交移交9 9个核个核心流程心流程对初学者来说，运用比较困难对初学者来说，运用比较困难37八、智能模型八、智能模型38用户要求用户要求需求分析需求分析概要设计概要设计详细设计详细设计程序编码程序编码测试测试维护维护支持需求支持需求 分析的分析的专家系统专家系统支持软件支持软件 设计的设计的专家系统专家

29、系统 支持测试的专家系统 支持维护的专家系统3940九、软件生存周期模型的剪裁在一个成熟的在一个成熟的ITIT企业或软件组织内部，通常要根据各企业或软件组织内部，通常要根据各种软件开发模型的特点，结合本单位的开发阅历和行种软件开发模型的特点，结合本单位的开发阅历和行业特点的详细实践，还需求定制适宜本单位的业特点的详细实践，还需求定制适宜本单位的“生存周生存周期模型裁剪指南，有针对性地对选定的软件开发模期模型裁剪指南，有针对性地对选定的软件开发模型中定义的生存周期，进展适当剪裁，使它完全适宜型中定义的生存周期，进展适当剪裁，使它完全适宜于本单位的需求。于本单位的需求。所谓裁剪，就是对原模型中定义的内容进展增、改、所谓裁剪，就是对原模型中定义的内容进展增、改、删，去掉对本单位不适用的内容，同时进一步细化，删，去掉对本单位不适用的内容，同时进一步细化，从而构成了完全适宜本单位的从而构成了完全适宜本单位的“软件生存周期模型裁剪软件生存周期模型裁剪指南。该指南在软件组织内部，专供高层经理和工指南。该指南在软件组织内部，专供高层经理和工程经理在软件谋划中选取软件开发模型时运用。程经理在软件谋划中选取软件开发模型时运用。 41l在软件开发过程中必需遵照的软件工在软件开发过程