软件工程建设监理课件

软件工程建设监理软件工程建设监理1主要内容软件工程概述软件质量与质量保证软件工程项目的实施与监理主要内容软件工程概述2一、软件工程概述

一、软件工程概述

3软件工程的定义Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料IEEE：软件工程是开发、运行、维护和修复软件的系统方法FritzBauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法软件工程的定义Boehm：运用现代科学技术知识来设计并构造计4软件工程的定义软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件和有关技术及管理方法。三个组成要素：方法、工具和过程。中心思想：是把软件当作一种工业产品，要求“采用工程化的原理与方法对软件进行计划、开发和维护”。 目的：不仅是为了实现按预期的进度和经费完成软件生产计划，也是为了提高软件的生产率与可靠性。软件工程的定义软件工程是用工程、科学和数学的原则与方法研制、5软件工程的目标付出较低的开发成本达到要求的软件功能取得较好的软件性能开发的软件易于移植需要较低的维护费用能按时完成开发工作，及时交付使用软件工程的目标付出较低的开发成本6软件工程目标之间的相互关系图低开发成本易于维护按时交付高可靠性高性能互斥关系互补关系软件工程目标之间的相互关系图低开发成本易于维护按时交付高可靠7软件工程的原则抽象(abstraction)信息的隐藏(informationhiding)模块化(modularity)局部化(localization)一致性(consistency)完全性(completeness)可验证性(verifiability)软件工程的原则抽象(abstraction)8软件工程的七条原理用分阶段的生命周期计划严格管理应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。Boehm认为，在整个软件生命周期中应指定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。软件工程的七条原理用分阶段的生命周期计划严格管理9软件工程的七条原理坚持进行阶段评审错误发现的越晚，改正它要付出的代价就越大软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误软件工程的七条原理坚持进行阶段评审10软件工程的七条原理实行严格的产品控制用户需求经常变更采用基准配置管理等科学的产品控制技术顺应用户的功能要求。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。采纳现代程序设计技术提高软件开发的效率，又可以减少软件维护的成本软件工程的七条原理实行严格的产品控制11软件工程的七条原理结果应能清楚地审查软件是一种富有逻辑性的知识产品软件开发小组的工作进展情况可见性差，难于评价和管理为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。软件工程的七条原理结果应能清楚地审查12软件工程的七条原理开发小组的人员应少而精当开发小组为N人时，可能的通讯信道为N(N-1)/2,可见随着人数N的增大，通讯开销将急剧增大。承认不断改进软件工程实践的必要性不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计，以评估新的软件技术的效果，指明须重视的问题。软件工程的七条原理开发小组的人员应少而精13软件的生存期开发软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存期软件生存期的六个步骤：计划、需求分析、设计、程序编码、测试及运行维护软件生存期划分的原则：各阶段任务尽可能独立软件的生存期开发软件有一个孕育、诞生、成长、成熟、衰亡的生存14软件的生存期软件的生存期15制定计划确定要开发软件系统的总目标给出功能、性能、可靠性以及接口等方面的要求完成该软件任务的可行性研究估计可利用的资源(计算机硬件、软件、人力等)、成本、效益、开发进度制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查制定计划确定要开发软件系统的总目标16需求分析和定义确定对待开发软件提出的需求进行分析并给出详细的定义编写软件需求说明书或系统功能说明书及初步的系统用户手册提交管理机构评审需求分析和定义确定对待开发软件提出的需求进行分析并给出详细的17软件设计概要设计—把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应详细设计—对每个模块要完成的工作进行具体的描述，为源程序编写打下基础编写设计说明书，提交评审软件设计概要设计—把各项需求转换成软件的体系18程序编写、软件测试程序编写

根据软件设计方案，编写程序代码结构。结构中每一组成部分都是意义明确的

软件测试单元测试，查找各模块在功能和结构上存在的问题并加以纠正组装测试，将已测试过的模块按一定顺序组装起来按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用程序编写、软件测试程序编写19运行、维护改正性维护运行中发现了软件中的错误需要修正适应性维护为了适应变化了的软件工作环境，需做适当变更完善性维护为了增强软件的功能需做变更运行、维护改正性维护运行中发现了软件中的错误需要修正20软件生存期模型软件生存期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架瀑布模型演化模型螺旋模型喷泉模型增量模型软件生存期模型软件生存期模型是跨越整个生存期的系统开发、运作21瀑布模型瀑布模型22演化模型由于在项目开发的初始阶段人们对软件的需求认识常常不够清晰，因而使得开发项目难于做到一次开发成功，出现返工再开发在所难免。做两次第一次只是试验开发，其目标只是在于探索可行性，弄清软件需求第二次则在此基础上获得较为满意的软件产品演化模型由于在项目开发的初始阶段人们对软件的需求认识常常不够23演化模型需求分析快速设计建立原型评价原型修改原型开发产品丢弃型—原型开发之后，已获取了更为清晰的需求信息演式型—原型作为软件最终产品的一部分，可满足用户的部分需求，进一步在此基础上开发，则可增加需求，实现后再交付使用。演化模型需求分析快速设计建立原型评价原型修改原型开发产品丢弃24螺旋模型螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件风险分析──分析所选方案，考虑如何识别和消除风险实施工程──实施软件开发客户评估──评价开发工作，提出修正建议螺旋模型螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面25螺旋模型

螺旋模型26喷泉模型迭代重复演进无间隙各阶段间无明显界限喷泉模型迭代27喷泉模型需求获取与分析系统测试程序生成构件设计类层次结构喷泉模型需求获取与分析系统测试程序生成构件设计类层次结构28增量模型适合于知识型的软件系统的开发不要求一开始就有完整的软件系统需求，先完成基本子集的开发，然后不断增加功能，反复进行，直到满足用户需求始终在软件人员和用户的参与下完成， 特别适用于研究性质的实验室软件（用户需求不明确）增量模型适合于知识型的软件系统的开发29总结阶段阶段成果计划问题定义关于规模和目标的报告书

可行性研究系统的高层逻辑模型：数据流图成本/效益分析

需求分析系统的逻辑模型：数据流图（MSC图）数据字典（类清单、对象间关系）算法描述

设计概要设计系统流程图、

层次图

、结构图(SDL)详细设计编码规格说明(SDL)软件测试综合测试方案和结果完整性一致的软件配置

运行维护完整准确的维护记录

总结阶段阶段成果计划问题定义关于规模和目标的报告书系统的高30二、软件质量与质量保证

二、软件质量与质量保证

31软件质量因素可直接度量的因素只能间接度量的因素度量和量度度量(Measurement)度量是对开发过程进行检测，以提高开发过程的质量和劳动生产率量度(Metrics)量度是度量的结果或度量中一个项的抽象表示，做为评价质量和劳动生产率的基础软件质量因素可直接度量的因素32量度模型－Boehm模型Boehm模型量度模型－Boehm模型Boehm模型33量度模型－McCall模型McCall模型量度模型－McCall模型McCall模型34量度模型－ISO模型ISO模型（软件质量需求评价准则）（软件质量度量评价准则）（软件质量设计评价准则）量度模型－ISO模型ISO模型（软件质量需求评价准则）（软件35各因素间的影响各因素间的影响36软件质量保证质量保证策略以检测为重点以过程管理为重点以新产品开发为重点

软件质量保证质量保证策略37软件质量保证活动技术方法和开发过程的选用正式技术评审的实施多层次软件测试标准的执行文档及其修改的控制度量和报告制度记录和记录保存SQA小组活动

软件质量保证活动技术方法和开发过程的选用38开发过程的选用瀑布模型演化模型螺旋模型喷泉模型增量模型开发过程的选用瀑布模型39开发方法、语言的选用开发方法结构化开发方法面向对象（OO）的开发方法形式化开发方法语言规格说明语言设计语言原型开发语言编程语言开发方法、语言的选用开发方法40正式技术评审的实施软件评审是一个“过滤器”正式技术评审(FTR，FormalTechnicalReviews)有时称为“走查(walkthrough)”正式技术评审的实施软件评审是一个“过滤器”41正式技术评审FTR的目标发现软件在功能、逻辑和实现上的错误验证评审的软件符合需求保证软件按照已确定的标准表述使软件以统一方式开发使项目更易于管理FTR可以作为一个训练基地，使初级工程人员观察到软件分析、设计和实现不同的处理方法。也能促进人们变得更加熟悉正式技术评审FTR的目标42正式技术评审(续)(一)评审会议3~5人参加会前准备，每个人工作量不超过2小时会议时间2小时评审结束时，必须作出决定接受该产品，不再作进一步修改该产品错误严重，拒绝接受(改正后也必须进行另一次评审)暂时接受该产品(小错误已经发现，必须改正，但没有必要进行另外的评审)正式技术评审(续)(一)评审会议43正式技术评审(续)(二)评审报告和记录保存报告评审了什么产品？谁评审的？发现了什么？结论是什么？记录确定该产品中问题的大小成为生产者修改错误时的行动项的校对表还要建立一个跟踪过程，以保证问题列表中的项都被正确的改正了正式技术评审(续)(二)评审报告和记录保存44正式技术评审(续)(三)评审指南评审产品，不评审生产者建立一个议事日程，并遵循它限制争论和辯驳说明问题大小，不要企图解决所有提出的问题作记录限制参与人数和坚持充分准备为可能评审的产品开发一张检查表为FTR安排资源和时间表对所有的评审人员进行有意义的培训评审你早期的评审正式技术评审(续)(三)评审指南45标准的执行产品质量是企业的生命，标准是产品的基础，没有标准，就无产品质量可言软件工程国际标准体系ISO/IEC的软件工程标准体系结构框架ISO/IEC12207和ISO/IECTR15504ISO9000-3(1993)/GB/T19000.3(1994)CMM-57-标准的执行产品质量是企业的生命，标准是产品的基础，没有标准，46标准的类别Standard(标准)Specification(规范)Criterion(准则)Guidance(指南)Convention(约定)标准的类别Standard(标准)47标准的范围国际：ISO(国际标准化组织)区域：NATO(北大西洋组织)CJK(中、日、韩)国家：GB(中国)ANSI(美国国家标准协会)FIPS(美国商务部国家标准局联邦信息处理标准)BS(英国国家标准)DIN(德国国家标准)JIS(日本工业标准)

卜标准的范围国际：ISO(国际标准化组织)卜48标准的范围行业：IEEE(美国电气和电子工程师协会)ACM(美国计算机协会)DOD(美国国防部)MIL-standard(美国军用标准)HB(中国航空标准)GJB(中国军用标准)厂标：IBM(国际商业机器公司)

小标准的范围行业：IEEE(美国电气和电子工程师协会)小49中国与SE有关的国家标准基础：GB/T11457-89(SE术语)开发：GB8566-88(计算机软件开发规范)文档：GB8567-88(计算机软件产品开发文件编制指南)GB9385-88(计算机软件需求说明文件编制规范)GB9386-88(计算机软件测试文件编制规范)质量：GB/T12504-90(计算机软件质量保证计划规范)管理：GB/T12605-90(计算机软件配置计划规范)90年以后，国家标准与国际标准从等效原则改为等同原则，均采用双编码。如GB/T19000.3(1994)-ISO9000-3(1993)中国与SE有关的国家标准基础：GB/T11457-89(S50相关标准说明PDAM12207/AMD112207的过程结果CD15388系统生存期过程IS12207软件生存期过程FDIS14764软件维护TR15846软件生存期过程软件配置管理DTR16326软件工程项目管理CD15939软件度量过程FD14598-3软件产品评价第三部分：开发者过程FD14598-4软件产品评价第四部分：获取者过程IS14598-5软件产品评价第五部分：评价者过程FDIS15910软件用户文档过程TR15271ISO/IEC12207使用指南ISO9000-3在软件开发、供应和维护中的使用指南TR9294软件文档管理指南ISO/IEC15288计划指南相关标准说明PDAM12207/AMD112207的过程51ISO9000-3-GB/T19000.3

质量管理和质量保证标准-在软件开发、供应和维护中的使用指南ISO9000系列标准原为硬件制造业制定的标准，不能直接用于软件业的生产曾试图用改编的9001用于软件业的生产由于软件与硬件的性质截然不同，软件为人工智能产品，实践结果说明不行，于是以ISO9000系列标准的追加形式，专门制定了ISO9000-3。ISO9000-3-GB/T19000.352标准的目的和范围本标准作为ISO9000/GB/T19000系列标准之一，旨在生产满足需求的软件而建议采用的控制手段和方法，即为从事软件开发、供应和维护的组织建立质量管理体系提供指南本标准适用于软件产品的整个生存期阶段和任何生存期模型，也适用于合同提出特殊要求的产品标准的目的和范围本标准作为ISO9000/GB/T19053标准的主要内容本标准在给出软件质量管理体系要素时，没有按照ISO9001/GB/T19991的形式给出，而是按下列三部分给出：质量体系-框架质量体系-生存期话动质量体系-支持活动标准的主要内容本标准在给出软件质量管理体系要素时，没有按照I54质量体系－框架这部分主要从管理上描述了构成了质量体系的组织机构、管理职责、质量体系的基本要求及构成质量体系的框架领导的职责、作用和采用的手段质量体系GB/T6583-ISO8402给质量体系定义为：为实施质量管理所具有的组织机构、职责、程序、过程和资源。这一定义给出了质量体系的五个要素，同时明确了质量管理的核心是建立适合企业实际的质量体系。质量体系应以深入细致的质量体系文件为基础，应用系统的有序的方法将质量体系要素、需求和预防措施清楚地写入文件质量体系是贯穿产品整个生存期的一个综合过程，它强调的是在开发过程中的质量保证，以预防为主，而不是在问题发生后依靠纠正措施来解决问题。因此，应按质量体系要求制定并执行质量活动计划

质量体系－框架这部分主要从管理上描述了构成了质量体系的组织机55质量体系－生存期话动合同评审需方需求规格说明开发策划质量计划设计与实现测试与验证验收复制、交付和安装维护质量体系－生存期话动合同评审56质量体系-支持活动配置管理文档控制质量记录度量规则和惯例工具和方法采购配套的软件产品培训

质量体系-支持活动配置管理57CMMCMM(TheCapabilityMaturityModel)不是国际标准，是CMU/SEI于1986年在Mitre公司的协助下，用于帮助机构改进其软件过程和联邦政府要求能提供一种用来评价软件承制方软件能力的方法，开始工作经过五年的努力，于1991/1992公开发布了基线版1.0之后，1992/19931.1版、1997/19982.0版，2000推出了CMMI1.0版，它除了沿用CMM分级的形式外，还吸收了ISO/IECTR15504的一些特点CMMCMM(TheCapability58CMM（续）CMM是一个概念模型，它给出了一个软件机构如何开发和维护高质量软件产品的思路CMM也是一个描述模型，它描述了一个具有某个级别的软件机构所具有的主要特征CMM又是一个系统框架，它为一个软件机构改进其软件过程能提供一种改进的途径CMM（续）CMM是一个概念模型，它给出了一个软件机构如何开59CMM结构CMM结构60CMM结构－成熟度级别CMM的顶层为成熟度级别(五级)1级：初始级(TheInitialLevel)2级：可重复级(TheRepeatableLevel)3级：已定义级(TheDefinedLevel)4级：已管理级(TheManaged)5级：优化级(TheOptimizingLevel)CMM结构－成熟度级别CMM的顶层为成熟度级别(五级)61CMM结构－关键过程域关键过程域除1级外，每个成熟度级都包含几个关键过程域(KeyProcessAreas)它们确定了要实现一个成熟度级别所必须解决的问题和目标处于级别3的软件机构一定要解决级别2和级别3中所有关键域中的问题；4、5级类推共有十八个关键过程域CMM结构－关键过程域关键过程域62CMM结构－关键过程域2级：

需求管理软件项目计划软件项目跟踪和监督软件分包合同管理软件质量保证软件配置管理3级：

机构过程焦点机构过程定义培训大纲

综合软件管理软件产品工程组间协调同行评审4级：定量过程管理软件质量管理5级：缺陷预防技术更新管理过程变更管理CMM结构－关键过程域2级：63CMM结构－共同特性每个关键过程由五部分组成，称为共同特性(CommonFeatures)执行约定(如建立机构策略和领导关系等)执行能力(如资源、机构结构和培训等)执行活动(如制定计划和规程、执行和跟踪及必要时采取的纠正措施等)度量和分析(如可采用的度量实例等)验证实现(如管理部门和质量保证小组实施的评审和审核等)

CMM结构－共同特性每个关键过程由五部分组成，称为共同特性64CMM结构－关键实践在共同特性中的实践，描述了要建立一个过程能力所必须完成的活动，即每一个关键过程都要用关键实践的概念进行描述CMM有316个关键实践(KeyPractices)关键实践只描述“做什么？”不规定“怎么做？”如不指定生存期模型、不规定产品实现所采用的开发方法和工具，从而可以让各个机构可以选择自己的方法。但必须合理地说明关键实践，以判断是否有效地实现了关键过程域的目标CMM结构－关键实践在共同特性中的实践，描述了要建立一个过程65CMM应用软件过程评价与软件能力估价软件过程评价(processassessment)和软件能力估价(capabilityevaluation)的方法基本相同。但由于评价和估价的动机、目的、输出和结果归属不同，使得在会谈或采访目的、访问范围所采集的信息和结果的表示方式，可能存在重要差别。所以，所采用的的详细规程不同，培训要求也不同评价是在开放、合作环境中进行的，目的在于暴露问题和帮助管理人员和技术人员改进他们所在机构的过程。所以，评价能否成功取决于他们对机构改进的支持。但更重要的是要通过各种座谈会了解机杓构的软件过程。评价的结果除了能确定机构所面临的软件过程问题外，最有价值的是明确机构改进软件过程的途径，促进制定进一步的行动计划，使整个机构关注软件过程的改进，提高整个机构改进行动计划的动力和热情

CMM应用软件过程评价与软件能力估价66软件过程评价与软件能力估价软件能力估价是在更为面向审计的环境中进行。估价的目的与金钱有关，因为估价组的推荐意见将影响挑选承制方或投放资金的多少。估价过程的重点在评审巳文档化的审计记录上，这些记录能揭示机构实际执行的软件过程必须指出的是：评价和估价的结果不是不可比的。因为它们都是基于CMM的，其不同之处也是可以解释的软件过程评价与软件能力估价软件能力估价是在更为面向审计的环境67CMM应用－评价方法评价方法选择评价小组填写成熟度问卷进行响应分析现场访问、会议和文档评审提供基于CMM的调查结果清单制作关键过程域的剖面图，以显示该机构哪些区域巳满足，哪些区域尚未满足关键过程域的目标等CMM应用－评价方法评价方法68CMM与ISO标准比较CMM与ISO9000-3的设计思路不同，虽然都是着眼于软件质量管理和软件过程管理，它们最大的不同是：CMM强调的是持续的过程改进；ISO9000-3涉及的是可接受的质量体系最低标准还要指出的是：CMM中关于能力等级是针对每个软件机构的；而ISO/IECTR15504中的能力等级是针对每个过程的CMM与ISO标准比较CMM与ISO9000-3的设计思路69文档及其修改的控制在生产软件时，修改(Change)是不可避免的，而不修改则是不正常的如果修改中有任何疏忽或处理不当，就非常容易把一个开发得很好的软件带入混乱！所以，只有当每个软件修改可以被说明、分析、跟踪和控制，而且所有需要知道的人都被通知到时，这样才能保证软件修改的质量软件配置管理(SCM,SoftwareConfigurationManagement)就是用来对软件文档及其修改控制的

文档及其修改的控制在生产软件时，修改(Change)是不可避70软件配置管理软件生存期各个阶段的交付项（包括描述程序的文档、和程序(源代码或可执行代码)，以及包含在程序内部或外部的数据）组成整体软件配置软件配置管理就是对这些交付项修改的管理，因此，不难看出：一个开发组可以生产出几百或上千种独立的交付项，所有这些交付项形成一个相互依赖的层次网在开发和维护的各个步骤中需要不断地再加工、修改和提高，因此任何交付项都可能有很多不同的版本，而且某一项的任何一种版本都与其它交付项的特定版本有关要防止相关交付项上下左右不一致引起的错误，是配置管理要具体解决的问题当然，解决这个问题的机制非常多，以至于需要一个独立的配置管理计划作为质量管理计划的补充，而且应让全体人员都知道，应该怎样完成和控制他们它们的工作质量软件配置管理软件生存期各个阶段的交付项（包括描述程序的文档、71修改控制无控制的修改必将导致混乱。修改控制过程：修改控制无控制的修改必将导致混乱。修改控制过程：72修改过程修改过程73配置审计如何保证修改控制的正确实现，除了进行正式的技术评审(FTR)以外，还要进行软件配置审计。通常检查下列问题：(1)被批准的修改报告中修改巳经完成了吗？(2)是否巳经进行了正式的技术评审？并表明技术的正确吗？(3)软件过程是否遵循了软件工程标准？(4)修改是否在交付项中被完全实现？配置对象的属性是否反映了该修改？(5)是否给出了修改者的姓名和修改的日期？(6)是否遵照了标识修改、记录修改和报告修改的软件配置管理规程？(7)所有的相关交付项都被更新了吗？在有些情况下，配置审计作为正式技术评审的一部分。审计一般都由质量保证小组进行配置审计如何保证修改控制的正确实现，除了进行正式的技术评审(74软件配置状态报告软件配置状态报告是软件配置管理的一项任务。它必须回答以下问题：(1)发生了什么事？(2)谁做了此事？(3)此事是什么时候发生的？(4)将影响到什么？配置状态报告可存储在一个联机的数据库中，使得软件开发者和维护者可以通过关键词分类访问修改信息，管理者也可获得与管理相关的信息软件配置状态报告软件配置状态报告是软件配置管理的一项任务。它75度量度量的主要目的：(1)更好的理解产品的质量(2)评价过程的效率(3)改进项目层完成工作的质量讨论的重点放在产品质量的量度上。(1)传统(结构化)软件的量度(2)面向对象软件的量度度量度量的主要目的：76传统软件的量度软件复杂性软件可靠性软件可用性软件安全性

传统软件的量度软件复杂性77面向对象软件的量度OO软件量度的使用和发展要比传统软件晚得多，其量度的主要目的与传统软件一样任何产品的量度都取决于产品的特性。OO软件与使用传统方法开发的软件根本不同。Berard定义了OO软件五个特殊量度的特性：1.局域性(localization)2.封装性(encapsulation)3.信息隐藏(informationhiding)4.继承性(inheritance)5.抽象(abstraction)面向对象软件的量度OO软件量度的使用和发展要比传统软件晚得多78SQA小组的活动软件质量保证由各种活动中的多个任务完成这些任务由做技术工作的人员和负责质量保证计划、监督、记录、分析及报告工作的SQA小组共同完成CMU/SEI推荐了一组有关质量保证中SQA小组的活动SQA小组的活动软件质量保证由各种活动中的多个任务完成79SQA小组活动（续）为项目准备SQA计划本计划与开发项目计划同时制定，由所有感兴趣的相关部门进行评审。本计划将控制由软件工程小组和SQA小组执行的质量保证活动；在计划中要确定以下各点：(1)需要执行的评价(2)需要执行的评审和审计(3)项目可采用的各种标准(4)错误报告和跟踪过程(5)由SQA小组给出的各种文档(6)为软件项目组提供反馈信息的数量SQA小组活动（续）为项目准备SQA计划80SQA小组活动（续）参与开发该顶目的软件过程描述软件工程小组要为进行的工作选择一个过程。SQA小组要按照机构政策、内部软件标准、外部确定的标准，以及软件项目计划其它部分的规定对过程描述进行评审评审软件工程各项活动，以验证其与巳定义的软件过程的符合程度SQA小组要发现、记录和跟踪与过程的偏差，并对其是否巳经改正进行验证审计指定的软件工作产品，并对其是否符合巳定义的软件过程相关部分进行验证SQA小组对选出的工作产品进行评审；发现、记录和跟踪出现的偏差；对其是否巳经改正进行验证；并定期向项目管理者报告工作结果SQA小组活动（续）参与开发该顶目的软件过程描述81SQA小组活动（续）确保软件工作和工作产品中的偏差巳被记录在案，并按照已文档化的过程进行处理偏差可以发生在项目计划、过程描述、可采用的标准或技术工作产品中记录任何不符合的部分，并报告给上级管理部门所有不符合的部分，必须受到跟踪，直至它们得到解决SQA小组除上述活动外，还需要协调软件修改的控制和管理，并帮助收集和分析软件量度活动的信息SQA小组活动（续）确保软件工作和工作产品中的偏差巳被记录82三、软件工程项目的实施与监理三、软件工程项目的实施与监理83定义阶段问题定义可行性研究需求分析定义阶段问题定义84问题定义问题定义：要解决的问题是什麽?方法：对系统的实际用户和使用部门负责人进行调研分析员扼要地写出对问题的理解在用户和使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不清或者错误理解阶段成果：关于问题性质、工程目标和规模的书面报告（一份承建双方都满意的文档）时间：不超过一天问题定义问题定义：要解决的问题是什麽?85问题定义的内容问题的范围需要什么应用上下文假设性能要求外部接口协议 软件工程标准，如模块化，可测试性，可扩充性哪些要求是必须的，那些是任选的问题定义的内容问题的范围86可行性分析的目标识别用户要求评价系统的可行性进行经济分析和技术分析把功能分配给硬件、软件、人、数据库和其它系统元素建立成本和进度限制生成系统规格说明，形成所有后续工程的基础可行性分析的目标识别用户要求87可行性分析的任务识别希望的功能和性能范围确定系统的功能、性能、约束和接口将功能赋予一个或多个系统元素（即软件、硬件、人等）提出一些候选方案并做评价对同一功能，可以分配不同的系统元素为选取最有效的分配方案，使用一组权衡准则进行评价可行性分析的任务识别希望的功能和性能范围88可行性分析的类型经济可行性（成本---效益分析）成本效益分析：长期利益、短期利益公司经营策略：市场前提技术可行性开发的风险：在给出的限制范围内，能否设计出系统，并实现必须的功能和性能资源：开发人员的水平，硬件、软件技术：相关技术的发展能否支持系统操作可行性用户单位的行政管理，工作制度；使用人员的素质法律可行性合同，侵权，违法，责任，版权可行性分析的类型经济可行性（成本---效益分析）89可行性分析报告阶段性成果——可行性分析报告一般只有投资能取得较大效益的工程项目才继续开发否则应及时中止工程项目，避免更大的浪费可行性研究的工作量大约占开发总工作量的5%可行性分析报告阶段性成果——可行性分析报告90需求分析需求分析的目标

借助于当前系统的逻辑模型导出目标系统的逻辑模型。当前系统目标系统物理模型物理模型逻辑模型逻辑模型模型化具体化抽象化实例化怎么做做什么导出理解需求表达需求参考当前系统建立目标系统模型需求分析需求分析的目标当前系统目标系统物理模型物理模型逻辑模91需求分析的过程需求获取需求表示需求验证需求规格说明书总体设计通过不通过可行性分析报告需求分析的过程需求获取需求表示需求验证需求规格说明书总体设计92需求分析获取的内容识别物理环境界面用户或者人的因素功能文档数据资源安全性质量保证需求分析获取的内容识别物理环境93需求分析的表示模型化表示将需求定义用工具（例如数据流图和数据字典）严格地描述出来分析方法结构化方法（自顶向下，逐步求精）面向数据流的结构化分析方法（SA）面向数据结构的Jackson方法(JSD)面向对象方法（OO）面向数据内容的面向对象分析方法(OOA)等需求分析的表示模型化表示94定义阶段的监理定义阶段监理的目标对软件功能、性能和其它需求描述的正确性、完整性和清晰性给予评价定义阶段监理的依据软件需求说明书（GB856T——88）国标《计算机软件开发规范》定义阶段承建单位提交的文档可行性研究报告项目开发计划数据要求说明书需求规格说明书用户手册概要定义阶段的监理定义阶段监理的目标95定义阶段的监理定义阶段监理的控制内容系统定义的目标是否与用户的要求一致系统需求分析阶段提供的文档资料是否齐全文档中的所有描述是否完整清晰准确反映用户要求与所有其它系统成分的重要接口是否都已经描述确定所开发项目的数据流与数据结构是否足够所有图表是否清楚，在不补充说明时能否理解定义阶段的监理定义阶段监理的控制内容96定义阶段的监理定义阶段监理的控制内容主要功能是否已包括在规定的软件范围之内，是否都已充分说明设计的约束条件或限制条件是否符合实际开发的技术风险是什么是否考虑过软件需求的其它方案是否考虑过将来可能会提出的软件需求是否详细制定了检验标准，它们能否对系统定义是否成功进行确认有没有遗漏，重复或不一致的地方软件开发计划中的估算是否受到了影响定义阶段的监理定义阶段监理的控制内容97设计阶段概要设计将软件需求转化为数据结构和软件的系统结构详细设计通过对结构表示进行细化，得到软件详细的数据结构和算法。设计阶段概要设计98设计阶段设计阶段的流程设计阶段设计阶段的流程99概要设计概要设计——将软件需求转化为数据结构和软件的系统结构；概要设计只是描绘出软件的总体框架，根据功能、性能需求和数据需求导出软件的数据结构和系统结构。概括地说：概要设计进行数据设计和系统结构设计。概要设计概要设计——将软件需求转化为数据结构和软件的系统结构100概要设计的任务概要设计制定规范。包括：阅读和理解软件需求说明书，确定软件设计的目标，及实现的顺序根据目标确定最合适的设计方法规定设计文档的编制标准规定编码的代码体系，与硬件、操作系统的接口规约，命名规则等

概要设计的任务概要设计制定规范。包括：101概要设计的任务软件系统结构的总体设计将复杂的系统功能划分成模块的层次结构确定每个模块的功能、模块间的调用关系、模块间的接口等评估模块划分的质量及导出模块结构的规则

处理方式设计确定为实现软件系统功能需求所必需的算法，并评估算法性能确定为满足软件系统的性能需求所必需的算法和模块间的控制方式确定外部信号的接收发送方式

概要设计的任务软件系统结构的总体设计102概要设计的任务数据结构设计

确定软件涉及的文件系统的结构、数据库的模式及子模式，并进行数据完整性和安全性设计。确定输入、输出文件的详细的数据结构结合算法设计，确定算法所必须的逻辑数据结构及其操作确定对逻辑数据结构所必需的那些操作的程序模块；若需要与操作系统或调度程序接口所必须的控制表等数据时，确定其详细的数据结构和使用规则；数据的保护性设计概要设计的任务数据结构设计103概要设计的任务编写概要设计文档数据库设计说明书用户手册制定初步的测试计划概要设计的任务编写概要设计文档104详细设计详细设计——通过对结构表示进行细化，得到软件详细的数据结构和算法详细设计的任务确定软件各个组成部分内的算法以及各部分的内部数据组织确定模块内算法，用某种工具来表达确定模块内的数据结构确定模块间的接口细节为每个模块设计测试选定某种过程的表达形式来描述各种算法；编写详细设计文档详细设计详细设计——通过对结构表示进行细化，得到软件详细的数105设计阶段的监理定义阶段监理的依据详细设计说明书（GB8567——88）概要设计说明书（GB8567——88）数据库设计说明书（GB8567——88）国标《计算机软件开发规范》设计阶段的监理定义阶段监理的依据106设计阶段的监理定义阶段监理的控制内容：分析软件各结构成分与软件需求之间的对应关系分析软件各结构成分之间的联系确认软件设计在现有技术条件下和预算范围内是否能按时完成确认软件设计对于需求的解决方案是否实用确认软件设计是否以一种易于翻译成程序代码的形式进行表达的确认软件设计是否考虑了易维护性评估对该软件的限制是否现实，是否与需求一致对于文档、可测试性、设计过程...等等进行评估设计阶段的监理定义阶段监理的控制内容：107设计阶段的监理设计阶段监理单位提交的文档设计阶段监理细则设计阶段监理周记概要设计监理报告详细设计说明书的确认报告设计阶段的监理设计阶段监理单位提交的文档108实施阶段

系统实施目的：是把审核过的系统设计说明书转化为可以实际运行的系统，交付用户一个可以实际运行的信息系统。编码软件测试实施阶段系统实施目的：是把审核过的系统设计说明书转109软件实现与测试的流程

准备编程代码审查单元测试集成测试软件系统缺陷管理与改错软件实现与测试的流程编程代码审查单元测试集软件系统缺陷管110编码监理编码监理的几个方面：编程语言的选择编程风格编码方法相关文档的编写参考指标：可靠性规范性可读性可维护性编码监理编码监理的几个方面：111编程语言的选择目标——编程困难低，测试程序量少，易于维护和阅读。参考因素：系统用户的要求可以使用的编译程序可以得到的软件工具工程规模程序员的知识软件可移植性要求软件的应用领域编程语言的选择目标——编程困难低，测试程序量少，易于维护和阅112编程风格目标——源程序代码的逻辑简明清晰参考因素：程序内部文档名字含义鲜明正确的注解程序清单数据说明数据说明的次序标准化多变量名字在一个语句中说明，按字母顺序排列编程风格目标——源程序代码的逻辑简明清晰113参考因素：语句构造语句简单直接避免复杂的条件测试，减少对“非”条件的测试避免大量使用循环嵌套和条件嵌套多使用括号使逻辑表达式和算数表达式清晰直观输入输出校验所有的输入输出检查输入项重要组合的合法性保持输入格式简单使用数据结束标志明确提交交互式输入的请求设计良好的输出表格给所有输出数据加标志编程风格参考因素：编程风格114参考因素：效率——时间和容量效率是性能要求，在需求分析阶段确定效率方面的要求效率是依靠设计来提高的程序的效率和程序的简单程度是一致的。编程风格参考因素：编程风格115编码方法模块和模块集成

常用的模块策略：自顶向下自底向上线性监理人员应考虑：开发人员在选择模块应用和集成方案时，考虑问题的完善于成熟程度。可以通过面谈和检查文档编码方法模块和模块集成116编码程序编码应保证按照结构化的编程方法进行。程序中的每个模块都只有一个入口和出口，模块的长度限制在50~100个语句的范围，使用自顶向下的流控制。监理人员应考虑：开发人员是否采用了结构化编程方法。可以通过编程者的工作，检查程序文档和察看代码。编码方法编码编码方法117高质量的文档是减少编码错误和提高可维护性的有利途径。监理人员应通过采样，通过样本判定文档质量高低。文档编写高质量的文档是减少编码错误和提高可维护性的有利途径。文档编118编码监理要点：程序说明书，是否得到开发负责人认可是否按照系统设计报告进行程序设计编码时发现与系统设计有矛盾，是否对系统设计进行了再讨论检查编码是否按程序说明书进行是否对程序测试结果进行登录与保管重要的程序是否由程序作者以外的人员进行了测试编码监理的要点编码监理要点：编码监理的要点119通过分析和执行程序发现软件不满足质量要求的缺陷的过程测试是程序的一个分析和执行过程，其目的在于发现错误软件测试通过分析和执行程序发现软件不满足质量要求的缺陷的过程软件测试120软件测试意义在一般软件开发的总成本中，用在测试上的开销要占30%到50%极端情况下，例如在关系到人的生命安全的软件中（如飞机控制或核反应监控等软件），测试费用可能相当软件生存周期所有其它阶段费用总和的3~5倍据美国工业界的统计，对商品化的顺序程序来说，测试在时间和费用两方面的花费都要占整个软件开发周期总开销的50%左右可以预料，分布式程序因为要增加死锁检测等内容，其测试花费势必还要大些。如果能将测试效率提高，其经济效益是显而易见的软件测试意义在一般软件开发的总成本中，用在测试上的开销要占3121软件测试的原则软件开发人员和管理人员首先应该尽早地和不断地进行各种软件质量保证活动软件开发人员应避免检查自已的程序,软件质量保证活动应由独立于软件开发单位的机构来承担在设计测试用例时，测试用例应包括输入数据和与之对应的期望输出结果两部分，在输入数据中，应当包括合理的输入条件和不合理的输入条件严格执行测试计划，排除测试的随意性充分注意测试的群集现象在进行各种分析和修复工作后，要做回归测试软件测试的原则软件开发人员和管理人员首先应该尽早地和不断地进122软件测试的基本策略验证、确认和测试静态分析与动态测试黑盒测试与白盒测试软件测试的基本策略验证、确认和测试123软件测试步骤单元测试单元测试系统测试确认测试集成测试单元测试被测模块被测模块被测模块已经过测试的模块已集成的软件已确认的软件可交付的软件概要设计信息系统其它元素软件需求详细设计信息软件测试步骤单元单元系统确认集成单元被测模块被测模块被测模块124测试分类——基本类型单元测试集成测试系统测试文档测试验收测试测试分类——基本类型单元测试125单元测试合格的代码正确、清晰、规范、一致、高效人工静态检查，发现30％－70％的逻辑设计和编码错误（review）算法的逻辑正确模块接口的正确性输入参数有无正确性检查调用其他方法接口的正确性出错处理表达式、SQL语句的正确性单元测试合格的代码126单元测试人工静态检查（review）常量、全局变量使用的正确性程序风格的一致性、规范性代码是否可以优化注释是否完整设计测试用例，执行待测程序尽可能覆盖所有路径至少检查每个判断语句的所有条件，确保所有的变量和参数都经过正常值和异常值的测试单元测试人工静态检查（review）127单元测试主要任务模块接口测试模块局部数据结构测试模块边界条件测试模块中所有独立执行路径测试模块的各条错误处理路径测试边界测试监理人员应检查相关文档《单元集成测试计划》《单元测试用例》《单元测试错误报告》相关《评审记录》、《变更记录》等。单元测试主要任务128集成测试集成测试任务：穿越模块接口的数据是否会丢失一个模块的功能是否会对另一个模块造成不利的影响各个子功能组合起来，是否达到预期要求的父功能全局数据结构是否有问题单个模块的误差累积起来是否会放大单个模块的错误是否会导致数据库错误集成测试集成测试任务：129集成测试分类非增量式集成测试把所有模块按设计要求一次全部组装起来，然后进行整体测试容易出现混乱。可能发现一大堆错误，为每个错误定位和纠正非常困难，且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。增量式集成测试程序一段一段地扩展，测试的范围一步一步地增大错误易于定位和纠正，界面的测试亦可做到完全彻底关键模块应尽早测试，并反复进行回归测试。集成测试分类130集成测试相关文档《单元集成测试计划》《集成测试用例》《集成测试错误报告》相关《评审记录》、《变更记录》等集成测试相关文档131系统测试系统测试——基于系统整体需求规格说明书，覆盖系统所有组成部分分类：功能测试（可用性）用于测试应用系统的功能需求功能点的全覆盖恢复测试主要检查系统的容错能力当系统出错时，能否在指定时间间隔内修正错误并重新启动系统压力测试检查程序对异常情况的抵抗能力迫使系统在异常的资源配置下运行系统测试系统测试——基于系统整体需求规格说明书，覆盖系统所有132系统测试监理人员应检查相关文档：《系统测试计划》《系统测试用例》《系统测试版本提交记录》《系统测试错误报告》《系统测试报告》相关《评审记录》、《变更记录》等系统测试监理人员应检查相关文档：133文档测试正式的review，检查文档的逻辑错误Livetesting，结合时间程序的使用而使用文档文档测试正式的review，检查文档的逻辑错误134验收测试完成所有开发和测试后进行。基于客户或最终用户的需求规格说明书的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。时机初验终验一般在用户现场，真实用户环境实施，也可在内部应用环境实施一般，验收测试用例为系统测试用例的子集，可从系统测试用例中根据实际需要选取验收测试完成所有开发和测试后进行。135测试监理要点测试监理要点:测试数据的选取及系统测试是否按测试计划进行系统测试是否站在公正、客观立场上进行的；系统测试是否由用户参与，是否按照用户手册进行系统测试结果是否得到开发、运行、维护及用户的负责人认可测试监理要点测试监理要点:136系统验收阶段系统验收的条件系统验收的组织结构系统验收的流程系统验收阶段监理工作的内容系统验收阶段监理工作的控制要点系统验收阶段系统验收的条件137系统验收的条件承建单位、监理单位已准备好总结报告材料监理工程师已完成工程质量测试、检验并编写完成工程项目质量鉴定书经预验收各分项工程均达到合格以上的工程；对未完成工或预验收时提出的修复、补救工程已处理完毕，并经监理工程师以及有关部门检查合格按国家相关法规法律、技术标准和竣工文件的有关要求已编制完成竣工文件按规定已编制好工程项目竣工决算系统验收的条件承建单位、监理单位已准备好总结报告材料138系统验收的组织联合验收工组组项目监理小组综合技术小组监理行政小组测试监理小组承建单位监理工程师业主单位软件工程验收阶段组织机构图系统验收的组织联合验收工组组项目监理小组综合技术小组监理行政139软件工程项目验收程序

项目收尾工作准备项目验收文档项目自检提交验收申请组成联合验收工作组项目初步验收项目正式验收签发终验报告颁发移交证书合格合格合格项目材料验收合格是是是否否否承建单位监理单位软件工程项目验收程序

项目收尾工作准备项目验收文档项目自检提140系统验收阶段监理的工作内容组成联合验收工作组项目材料验收初步验收正式验收签发终验报告颁发移交证书、办理固定资产移交

系统验收阶段监理的工作内容组成联合验收工作组141系统验收阶段监理的控制要点及时处理承建单位提交的初验申请，审核初验的必备条件审核承建单位初验、终验和工程整改计划的可行性审核承建单位提交的验收计划及其方案，明确验收目标、各方责任、验收内容、验收标准、验收方式和验收结果等内容对初验中发现的质量问题进行评估，根据质量问题的性质和影响范围，确定整改要求和整改后的验收方式

审核承建单位提交的阶段性付款申请协调业主单位和承建单位在验收计划、验收目标、验收范围、验收内容、验收方法和验收标准等方面达成一致，填报工程备忘录监理机构应协助业主单位和承建单位完成工程移交工作

系统验收阶段监理的控制要点及时处理承建单位提交的初验申请，审142结束语

软件工程的监理机制刚刚起步，但已有的工程实践证明，监理机制必将显现出它在市场经济环境下强大的生命力。通过强化软件开发的标准化、规范化工程思想，软件工程监理必将逐步规范化、专业化，形成成熟的市场运作模式。谢谢！结束语软件工程的监理机制刚刚起步，但已有的工程实践143软件工程建设监理软件工程建设监理144主要内容软件工程概述软件质量与质量保证软件工程项目的实施与监理主要内容软件工程概述145一、软件工程概述

一、软件工程概述

146软件工程的定义Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料IEEE：软件工程是开发、运行、维护和修复软件的系统方法FritzBauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法软件工程的定义Boehm：运用现代科学技术知识来设计并构造计147软件工程的定义软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件和有关技术及管理方法。三个组成要素：方法、工具和过程。中心思想：是把软件当作一种工业产品，要求“采用工程化的原理与方法对软件进行计划、开发和维护”。 目的：不仅是为了实现按预期的进度和经费完成软件生产计划，也是为了提高软件的生产率与可靠性。软件工程的定义软件工程是用工程、科学和数学的原则与方法研制、148软件工程的目标付出较低的开发成本达到要求的软件功能取得较好的软件性能开发的软件易于移植需要较低的维护费用能按时完成开发工作，及时交付使用软件工程的目标付出较低的开发成本149软件工程目标之间的相互关系图低开发成本易于维护按时交付高可靠性高性能互斥关系互补关系软件工程目标之间的相互关系图低开发成本易于维护按时交付高可靠150软件工程的原则抽象(abstraction)信息的隐藏(informationhiding)模块化(modularity)局部化(localization)一致性(consistency)完全性(completeness)可验证性(verifiability)软件工程的原则抽象(abstraction)151软件工程的七条原理用分阶段的生命周期计划严格管理应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。Boehm认为，在整个软件生命周期中应指定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。软件工程的七条原理用分阶段的生命周期计划严格管理152软件工程的七条原理坚持进行阶段评审错误发现的越晚，改正它要付出的代价就越大软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误软件工程的七条原理坚持进行阶段评审153软件工程的七条原理实行严格的产品控制用户需求经常变更采用基准配置管理等科学的产品控制技术顺应用户的功能要求。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。采纳现代程序设计技术提高软件开发的效率，又可以减少软件维护的成本软件工程的七条原理实行严格的产品控制154软件工程的七条原理结果应能清楚地审查软件是一种富有逻辑性的知识产品软件开发小组的工作进展情况可见性差，难于评价和管理为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。软件工程的七条原理结果应能清楚地审查155软件工程的七条原理开发小组的人员应少而精当开发小组为N人时，可能的通讯信道为N(N-1)/2,可见随着人数N的增大，通讯开销将急剧增大。承认不断改进软件工程实践的必要性不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计，以评估新的软件技术的效果，指明须重视的问题。软件工程的七条原理开发小组的人员应少而精156软件的生存期开发软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存期软件生存期的六个步骤：计划、需求分析、设计、程序编码、测试及运行维护软件生存期划分的原则：各阶段任务尽可能独立软件的生存期开发软件有一个孕育、诞生、成长、成熟、衰亡的生存157软件的生存期软件的生存期158制定计划确定要开发软件系统的总目标给出功能、性能、可靠性以及接口等方面的要求完成该软件任务的可行性研究估计可利用的资源(计算机硬件、软件、人力等)、成本、效益、开发进度制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查制定计划确定要开发软件系统的总目标159需求分析和定义确定对待开发软件提出的需求进行分析并给出详细的定义编写软件需求说明书或系统功能说明书及初步的系统用户手册提交管理机构评审需求分析和定义确定对待开发软件提出的需求进行分析并给出详细的160软件设计概要设计—把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应详细设计—对每个模块要完成的工作进行具体的描述，为源程序编写打下基础编写设计说明书，提交评审软件设计概要设计—把各项需求转换成软件的体系161程序编写、软件测试程序编写

根据软件设计方案，编写程序代码结构。结构中每一组成部分都是意义明确的

软件测试单元测试，查找各模块在功能和结构上存在的问题并加以纠正组装测试，将已测试过的模块按一定顺序组装起来按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用程序编写、软件测试程序编写162运行、维护改正性维护运行中发现了软件中的错误需要修正适应性维护为了适应变化了的软件工作环境，需做适当变更完善性维护为了增强软件的功能需做变更运行、维护改正性维护运行中发现了软件中的错误需要修正163软件生存期模型软件生存期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架瀑布模型演化模型螺旋模型喷泉模型增量模型软件生存期模型软件生存期模型是跨越整个生存期的系统开发、运作164瀑布模型瀑布模型165演化模型由于在项目开发的初始阶段人们对软件的需求认识常常不够清晰，因而使得开发项目难于做到一次开发成功，出现返工再开发在所难免。做两次第一次只是试验开发，其目标只是在于探索可行性，弄清软件需求第二次则在此基础上获得较为满意的软件产品演化模型由于在项目开发的初始阶段人们对软件的需求认识常常不够166演化模型需求分析快速设计建立原型评价原型修改原型开发产品丢弃型—原型开发之后，已获取了更为清晰的需求信息演式型—原型作为软件最终产品的一部分，可满足用户的部分需求，进一步在此基础上开发，则可增加需求，实现后再交付使用。演化模型需求分析快速设计建立原型评价原型修改原型开发产品丢弃167螺旋模型螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件风险分析──分析所选方案，考虑如何识别和消除风险实施工程──实施软件开发客户评估──评价开发工作，提出修正建议螺旋模型螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面168螺旋模型

螺旋模型169喷泉模型迭代重复演进无间隙各阶段间无明显界限喷泉模型迭代170喷泉模型需求获取与分析系统测试程序生成构件设计类层次结构喷泉模型需求获取与分析系统测试程序生成构件设计类层次结构171增量模型适合于知识型的软件系统的开发不要求一开始就有完整的软件系统需求，先完成基本子集的开发，然后不断增加功能，反复进行，直到满足用户需求始终在软件人员和用户的参与下完成， 特别适用于研究性质的实验室软件（用户需求不明确）增量模型适合于知识型的软件系统的开发172总结阶段阶段成果计划问题定义关于规模和目标的报告书

可行性研究系统的高层逻辑模型：数据流图成本/效益分析

需求分析系统的逻辑模型：数据流图（MSC图）数据字典（类清单、对象间关系）算法描述

设计概要设计系统流程图、

层次图

、结构图(SDL)详细设计编码规格说明(SDL)软件测试综合测试方案和结果完整性一致的软件配置

运行维护完整准确的维护记录

总结阶段阶段成果计划问题定义关于规模和目标的报告书系统的高173二、软件质量与质量保证

二、软件质量与质量保证

174软件质量因素可直接度量的因素只能间接度量的因素度量和量度度量(Measurement)度量是对开发过程进行检测，以提高开发过程的质量和劳动生产率量度(Metrics)量度是度量的结果或度量中一个项的抽象表示，做为评价质量和劳动生产率的基础软件质量因素可直接度量的因素175量度模型－Boehm模型Boehm模型量度模型－Boehm模型Boehm模型176量度模型－McCall模型McCall模型量度模型－McCall模型McCall模型177量度模型－ISO模型ISO模型（软件质量需求评价准则）（软件质量度量评价准则）（软件质量设计评价准则）量度模型－ISO模型ISO模型（软件质量需求评价准则）（软件178各因素间的影响各因素间的影响179软件质量保证质量保证策略以检测为重点以过程管理为重点以新产品开发为重点

软件质量保证质量保证策略180软件质量保证活动技术方法和开发过程的选用正式技术评审的实施多层次软件测试标准的执行文档及其修改的控制度量和报告制度记录和记录保存SQA小组活动

软件质量保证活动技术方法和开发过程的选用181开发过程的选用瀑布模型演化模型螺旋模型喷泉模型增量模型开发过程的选用瀑布模型182开发方法、语言的选用开发方法结构化开发方法面向对象（OO）的开发方法形式化开发方法语言规格说明语言设计语言原型开发语言编程语言开发方法、语言的选用开发方法183正式技术评审的实施软件评审是一个“过滤器”正式技术评审(FTR，FormalTechnicalReviews)有时称为“走查(walkthrough)”正式技术评审的实施软件评审是一个“过滤器”184正式技术评审FTR的目标发现软件在功能、逻辑和实现上的错误验证评审的软件符合需求保证软件按照已确定的标准表述使软件以统一方式开发使项目更易于管理FTR可以作为一个训练基地，使初级工程人员观察到软件分析、设计和实现不同的处理方法。也能促进人们变得更加熟悉正式技术评审FTR的目标185正式技术评审(续)(一)评审会议3~5人参加会前准备，每个人工作量不超过2小时会议时间2小时评审结束时，必须作出决定接受该产品，不再作进一步修改该产品错误严重，拒绝接受(改正后也必须进行另一次评审)暂时接受该产品(小错误已经发现，必须改正，但没有必要进行另外的评审)正式技术评审(续)(一)评审会议186正式技术评审(续)(二)评审报告和记录保存报告评审了什么产品？谁评审的？发现了什么？结论是什么？记录确定该产品中问题的大小成为生产者修改错误时的行动项的校对表还要建立一个跟踪过程，以保证问题列表中的项都被正确的改正了正式技术评审(续)(二)评审报告和记录保存187正式技术评审(续)(三)评审指南评审产品，不评审生产者建立一个议事日程，并遵循它限制争论和辯驳说明问题大小，不要企图解决所有提出的问题作记录限制参与人数和坚持充分准备为可能评审的产品开发一张检查表为FTR安排资源和时间表对所有的评审人员进行有意义的培训评审你早期的评审正式技术评审(续)(三)评审指南188标准的执行产品质量是企业的生命，标准是产品的基础，没有标准，就无产品质量可言软件工程国际标准体系ISO/IEC的软件工程标准体系结构框架ISO/IEC12207和ISO/IECTR15504ISO9000-3(1993)/GB/T19000.3(1994)CMM-57-标准的执行产品质量是企业的生命，标准是产品的基础，没有标准，189标准的类别Standard(标准)Specification(规范)Criterion(准则)Guidance(指南)Convention(约定)标准的类别Standard(标准)190标准的范围国际：ISO(国际标准化组织)区域：NATO(北大西洋组织)CJK(中、日、韩)国家：GB(中国)ANSI(美国国家标准协会)FIPS(美国商务部国家标准局联邦信息处理标准)BS(英国国家标准)DIN(德国国家标准)JIS(日本工业标准)

卜标准的范围国际：ISO(国际标准化组织)卜191标准的范围行业：IEEE(美国电气和电子工程师协会)ACM(美国计算机协会)DOD(美国国防部)MIL-standard(美国军用标准)HB(中国航空标准)GJB(中国军用标准)厂标：IBM(国际商业机器公司)

小标准的范围行业：IEEE(美国电气和电子工程师协会)小192中国与SE有关的国家标准基础：GB/T11457-89(SE术语)开发：GB8566-88