1、软件工程建设监理软件工程建设监理主要内容主要内容软件工程概述软件工程概述软件质量与质量保证软件质量与质量保证软件工程项目的实施与监理软件工程项目的实施与监理一、软件工程概述一、软件工程概述软件工程的定义软件工程的定义Boehm：运用现代科学技术知识来设计并：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料程序所必需的相关文件资料IEEE：软件工程是开发、运行、维护和修：软件工程是开发、运行、维护和修复软件的系统方法复软件的系统方法Fritz Bauer：建立并使用完善的工程化原则，：建立并使用完善的工程化原则，以较
2、经济的手段获得能在实际机器上有效运以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法行的可靠软件的一系列方法软件工程的定义软件工程的定义软件工程是用工程、科学和数学的原则与软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件和有关技术及管方法研制、维护计算机软件和有关技术及管理方法。理方法。三个组成要素：方法、工具和过程。三个组成要素：方法、工具和过程。中心思想：是把软件当作一种工业产品，中心思想：是把软件当作一种工业产品，要求要求“采用工程化的原理与方法对软件进行采用工程化的原理与方法对软件进行计划、开发和维护计划、开发和维护”。目的：不仅是为了实现按预期的进度和经目的：
3、不仅是为了实现按预期的进度和经费完成软件生产计划，也是为了提高软件的费完成软件生产计划，也是为了提高软件的生产率与可靠性。生产率与可靠性。软件工程的目标软件工程的目标付出较低的开发成本达到要求的软件功能取得较好的软件性能开发的软件易于移植需要较低的维护费用能按时完成开发工作，及时交付使用软件工程目标之间的相互关系图软件工程目标之间的相互关系图低开发成本低开发成本易于维护易于维护按时交付按时交付高可靠性高可靠性高性能高性能互斥关系互斥关系互补关系互补关系软件工程的原则软件工程的原则抽象(abstraction)信息的隐藏(information hiding)模块化(modularity)局部化
4、(localization)一致性(consistency)完全性(completeness)可验证性(verifiability)软件工程的七条原理软件工程的七条原理用分阶段的生命周期计划严格管理用分阶段的生命周期计划严格管理 应该把软件生命周期分成若干阶段，并相应制定应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。和维护进行管理。Boehm 认为，在整个软件生命周期中应指定并严认为，在整个软件生命周期中应指定并严格执行格执行6类计划：项目概要计划、里程碑计划、项目类计划：项目概要计划、里程
5、碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。控制计划、产品控制计划、验证计划、运行维护计划。软件工程的七条原理软件工程的七条原理坚持进行阶段评审坚持进行阶段评审 错误发现的越晚，改正它要付出的代价就错误发现的越晚，改正它要付出的代价就越大越大 软件的质量保证工作不能等到编码结束之软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，后再进行，应坚持进行严格的阶段评审，以便尽早发现错误以便尽早发现错误 软件工程的七条原理软件工程的七条原理实行严格的产品控制实行严格的产品控制 用户需求经常变更用户需求经常变更采用基准配置管理等科学的产品控制技术采用基准配置管理等科
6、学的产品控制技术顺应用户的功能要求。当需求变动时，其顺应用户的功能要求。当需求变动时，其它各个阶段的文档或代码随之相应变动，它各个阶段的文档或代码随之相应变动，以保证软件的一致性。以保证软件的一致性。采纳现代程序设计技术采纳现代程序设计技术 提高软件开发的效率，又可以减少软件维提高软件开发的效率，又可以减少软件维护的成本护的成本 软件工程的七条原理软件工程的七条原理结果应能清楚地审查结果应能清楚地审查 软件是一种富有逻辑性的知识产品软件是一种富有逻辑性的知识产品软件开发小组的工作进展情况可见性差，软件开发小组的工作进展情况可见性差，难于评价和管理难于评价和管理 为更好地进行管理，应根据软件开发
7、的总为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚责任和产品标准，从而使所得到的标准能清楚地审查。地审查。软件工程的七条原理软件工程的七条原理开发小组的人员应少而精开发小组的人员应少而精 当开发小组为当开发小组为N人时，可能的通讯信道为人时，可能的通讯信道为N(N-1)/2,可见随着人数可见随着人数N的增大，通讯开销将急剧增大。的增大，通讯开销将急剧增大。承认不断承认不断改进软件工程实践的必要性改进软件工程实践的必要性 不断总结经验，收集进度和消耗等数据，进行出错不断总结经验，收集进度
8、和消耗等数据，进行出错类型和问题报告统计，以评估新的软件技术的效果，类型和问题报告统计，以评估新的软件技术的效果，指明须重视的问题。指明须重视的问题。软件的生存期软件的生存期开发软件有一个孕育、诞生、成长、成熟、开发软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的衰亡的生存过程。这个过程即为计算机软件的生存期生存期软件生存期的六个步骤：计划、需求分析、软件生存期的六个步骤：计划、需求分析、设计、程序编码、测试及运行维护设计、程序编码、测试及运行维护软件生存期划分的原则：软件生存期划分的原则：各阶段任务尽可能独各阶段任务尽可能独立立软件的生存期软件的生存期制定计划制定计
9、划确定要开发软件系统的总目标确定要开发软件系统的总目标给出功能、性能、可靠性以及接口等方面的给出功能、性能、可靠性以及接口等方面的要求要求完成该软件任务的可行性研究完成该软件任务的可行性研究估计可利用的资源估计可利用的资源(计算机硬件、软件、人力计算机硬件、软件、人力等等)、成本、效益、开发进度、成本、效益、开发进度制定出完成开发任务的实施计划，连同可行制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查性研究报告，提交管理部门审查需求分析和定义需求分析和定义确定对待开发软件提出的需求进行分析并给确定对待开发软件提出的需求进行分析并给出详细的定义出详细的定义编写软件需求说明书或系
10、统功能说明书及初编写软件需求说明书或系统功能说明书及初步的系统用户手册步的系统用户手册提交管理机构评审提交管理机构评审软件设计软件设计概要设计概要设计 把各项需求转换成软件的体系把各项需求转换成软件的体系 结构。结构中每一组成部分都是意义明确的结构。结构中每一组成部分都是意义明确的 模块，每个模块都和某些需求相对应模块，每个模块都和某些需求相对应详细设计详细设计 对每个模块要完成的工作进行对每个模块要完成的工作进行 具体的描述，为源程序编写打下基础具体的描述，为源程序编写打下基础编写设计说明书，提交评审编写设计说明书，提交评审程序编写、软件测试程序编写、软件测试程序编写程序编写 根据软件设计方
11、案，编写程序代码根据软件设计方案，编写程序代码 结构。结构中每结构。结构中每一组成部分都是意义明确的一组成部分都是意义明确的 软件测试软件测试 单元测试，查找各模块在功能和结构上存在的问单元测试，查找各模块在功能和结构上存在的问题并加以纠正题并加以纠正组装测试，将已测试过的模块按一定顺序组装起组装测试，将已测试过的模块按一定顺序组装起来来按规定的各项需求，逐项进行有效性测试，决定按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用已开发的软件是否合格，能否交付用户使用运行、维护运行、维护改正性维护改正性维护 运行中发现了软件中的错误需运行中发现了软件中的错误需要修正
12、要修正适应性维护适应性维护 为了适应变化了的软件工作环为了适应变化了的软件工作环境，需做适当变更境，需做适当变更完善性维护完善性维护 为了增强软件的功能需做变更为了增强软件的功能需做变更软件生存期模型软件生存期模型软件生存期模型是跨越整个生存期的系统开软件生存期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任发、运作和维护所实施的全部过程、活动和任务的结构框架务的结构框架瀑布模型瀑布模型演化模型演化模型螺旋模型螺旋模型喷泉模型喷泉模型增量模型增量模型瀑布模型瀑布模型演化模型演化模型由于在项目开发的初始阶段人们对软件的需求认识常常不够清晰，因而使得开发项目难于做到一次开发成功
13、，出现返工再开发在所难免。做两次第一次只是试验开发，其目标只是在于探索可行性，弄清软件需求第二次则在此基础上获得较为满意的软件产品演化模型演化模型需求分析需求分析快速设计快速设计建立原型建立原型评价原型评价原型修改原型修改原型开发产品开发产品丢弃型原型开发之后，已获取了更为清晰的需求信息 演式型原型作为软件最终产品的一部分，可满足用户的部分需求，进一步在此基础上开发，则可增加需求，实现后再交付使用。螺螺旋模型旋模型螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：制定计划确定软件目标，选定实施方案，弄清项目开发的限制条件风险分析分析所选方案，考虑如何识别和消除风险实施工程实施软件
14、开发客户评估评价开发工作，提出修正建议螺螺旋模型旋模型 喷泉模型喷泉模型迭代重复演进无间隙各阶段间无明显界限喷泉模型喷泉模型需求获取与分析需求获取与分析系统测试系统测试程序生成程序生成构件设计构件设计类层次结构类层次结构增量模型增量模型适合于知识型的软件系统的开发适合于知识型的软件系统的开发不要求一开始就有完整的软件系统需求，先完成不要求一开始就有完整的软件系统需求，先完成基本子集的开发，然后不断增加功能，反复进行，基本子集的开发，然后不断增加功能，反复进行，直到满足用户需求直到满足用户需求始终在软件人员和用户的参与下完成，始终在软件人员和用户的参与下完成，特别适用特别适用于研究性质的实验室软
15、件（用户需求不明确）于研究性质的实验室软件（用户需求不明确）总结总结阶段阶段成果计划问题定义关于规模和目标的报告书 可行性研究系统的高层逻辑模型：数据流图成本/效益分析 需求分析系统的逻辑模型：数据流图（MSC图）数据字典（类清单、对象间关系）算法描述 设计概要设计系统流程图、层次图、结构图(SDL)详细设计编码规格说明(SDL)软件测试综合测试方案和结果完整性一致的软件配置 运行维护完整准确的维护记录 二、软件质量与质量保证二、软件质量与质量保证软件质量因素可直接度量的因素只能间接度量的因素度量和量度度量(Measurement)度量是对开发过程进行检测，以提高开发过程的质量和劳动生产率量度
16、(Metrics)量度是度量的结果或度量中一个项的抽象表示，做为评价质量和劳动生产率的基础量度模型Boehm模型Boehm模型量度模型McCall模型McCall模型量度模型ISO模型ISO模型（软件质量需求评价准则）（软件质量度量评价准则）（软件质量设计评价准则）各因素间的影响软件质量保证质量保证策略以检测为重点以过程管理为重点以新产品开发为重点 软件质量保证活动技术方法和开发过程的选用正式技术评审的实施多层次软件测试标准的执行文档及其修改的控制度量和报告制度记录和记录保存SQA小组活动 开发过程的选用瀑布模型演化模型螺旋模型喷泉模型增量模型开发方法、语言的选用开发方法结构化开发方法面向对象
17、（OO）的开发方法形式化开发方法语言规格说明语言设计语言原型开发语言编程语言正式技术评审的实施软件评审是一个“过滤器”正式技术评审(FTR，Formal Technical Reviews)有时称为“走查(walkthrough)”正式技术评审FTR的目标发现软件在功能、逻辑和实现上的错误 验证评审的软件符合需求保证软件按照已确定的标准表述使软件以统一方式开发 使项目更易于管理FTR可以作为一个训练基地，使初级工程人员观察到软件分析、设计和实现不同的处理方法。也能促进人们变得更加熟悉正式技术评审(续)(一)评审会议35人参加会前准备，每个人工作量不超过2小时会议时间2小时评审结束时，必须作出决
18、定接受该产品，不再作进一步修改该产品错误严重，拒绝接受(改正后也必须进行另一次评审)暂时接受该产品(小错误已经发现，必须改正，但没有必要进行另外的评审)正式技术评审(续)(二)评审报告和记录保存报告评审了什么产品？谁评审的？发现了什么？结论是什么？记录确定该产品中问题的大小成为生产者修改错误时的行动项的校对表 还要建立一个跟踪过程，以保证问题列表中的项都被正确的改正了正式技术评审(续)(三)评审指南评审产品，不评审生产者建立一个议事日程，并遵循它限制争论和辯驳说明问题大小，不要企图解决所有提出的问题作记录限制参与人数和坚持充分准备为可能评审的产品开发一张检查表为FTR安排资源和时间表对所有的评
19、审人员进行有意义的培训评审你早期的评审标准的执行产品质量是企业的生命，标准是产品的基础，没有标准，就无产品质量可言软件工程国际标准体系ISO/IEC的软件工程标准体系结构框架ISO/IEC 12207和ISO/IEC TR15504ISO 9000-3(1993)/GB/T 19000.3(1994)CMM -57-标准的类别Standard(标准)Specification(规范)Criterion(准则)Guidance(指南)Convention(约定)标准的范围国际：ISO(国际标准化组织)区域：NATO(北大西洋组织)CJK(中、日、韩)国家：GB(中国)ANSI(美国国家标准协会)
20、FIPS(美国商务部国家标准局联邦信息处理标准)BS(英国国家标准)DIN(德国国家标准)JIS(日本工业标准)卜标准的范围行业：IEEE(美国电气和电子工程师协会)ACM(美国计算机协会)DOD(美国国防部)MIL-standard(美国军用标准)HB(中国航空标准)GJB(中国军用标准)厂标：IBM(国际商业机器公司)小中国与SE有关的国家标准基础：GB/T 11457-89(SE术语)开发：GB 8566-88(计算机软件开发规范)文档：GB 8567-88(计算机软件产品开发文件编制指南)GB 9385-88(计算机软件需求说明文件编制规范)GB 9386-88(计算机软件测试文件编制
21、规范)质量：GB/T 12504-90(计算机软件质量保证计划规范)管理：GB/T 12605-90(计算机软件配置计划规范)90年以后，国家标准与国际标准从等效原则改为等同原则，均采用双编码。如GB/T 19000.3(1994)-ISO 9000-3(1993)相关标准说明PDAM 12207/AMD1 12207的过程结果CD 15388 系统生存期过程IS 12207 软件生存期过程FDIS 14764 软件维护TR 15846 软件生存期过程软件配置管理DTR 16326 软件工程项目管理CD 15939 软件度量过程FD 14598-3 软件产品评价第三部分：开发者过程FD 145
22、98-4 软件产品评价第四部分：获取者过程IS 14598-5 软件产品评价第五部分：评价者过程FDIS 15910 软件用户文档过程TR 15271 ISO/IEC 12207使用指南ISO 9000-3 在软件开发、供应和维护中的使用指南TR 9294 软件文档管理指南ISO/IEC 15288 计划指南ISO 9000-3-GB/T 19000.3 质量管理和质量保证标准-在软件开发、供应和维护中的使用指南ISO 9000系列标准原为硬件制造业制定的标准，不能直接用于软件业的生产曾试图用改编的9001用于软件业的生产由于软件与硬件的性质截然不同，软件为人工智能产品，实践结果说明不行，于是
23、以ISO 9000系列标准的追加形式，专门制定了ISO 9000-3。标准的目的和范围本标准作为ISO 9000/GB/T 19000系列标准之一，旨在生产满足需求的软件而建议采用的控制手段和方法，即为从事软件开发、供应和维护的组织建立质量管理体系提供指南本标准适用于软件产品的整个生存期阶段和任何生存期模型，也适用于合同提出特殊要求的产品标准的主要内容本标准在给出软件质量管理体系要素时，没有按照ISO 9001/GB/T 19991的形式给出，而是按下列三部分给出：质量体系-框架质量体系-生存期话动质量体系-支持活动质量体系框架这部分主要从管理上描述了构成了质量体系的组织机构、管理职责、质量体
24、系的基本要求及构成质量体系的框架领导的职责、作用和采用的手段质量体系 GB/T 6583-ISO 8402给质量体系定义为：为实施质量管理所具有的组织机构、职责、程序、过程和资源。这一定义给出了质量体系的五个要素，同时明确了质量管理的核心是建立适合企业实际的质量体系。质量体系应以深入细致的质量体系文件为基础，应用系统的有序的方法将质量体系要素、需求和预防措施清楚地写入文件质量体系是贯穿产品整个生存期的一个综合过程，它强调的是在开发过程中的质量保证，以预防为主，而不是在问题发生后依靠纠正措施来解决问题。因此，应按质量体系要求制定并执行质量活动计划 质量体系生存期话动合同评审需方需求规格说明开发策
25、划质量计划设计与实现测试与验证验收复制、交付和安装维护质量体系-支持活动配置管理文档控制质量记录度量规则和惯例工具和方法 采购配套的软件产品培训 CMM CMM(The Capability Maturity Model)不是国际标准，是CMU/SEI 于1986年在Mitre公司的协助下，用于帮助机构改进其软件过程和联邦政府要求能提供一种用来评价软件承制方软件能力的方法，开始工作经过五年的努力，于1991/1992公开发布了基线版1.0之后，1992/1993 1.1版、1997/1998 2.0版，2000推出了CMMI 1.0版，它除了沿用CMM分级的形式外，还吸收了ISO/IEC TR
26、 15504的一些特点CMM（续）CMM是一个概念模型，它给出了一个软件机构如何开发和维护高质量软件产品的思路CMM也是一个描述模型，它描述了一个具有某个级别的软件机构所具有的主要特征CMM又是一个系统框架，它为一个软件机构改进其软件过程能提供一种改进的途径CMM结构CMM结构成熟度级别CMM的顶层为成熟度级别(五级)1级：初始级(The Initial Level)2级：可重复级(The Repeatable Level)3级：已定义级(The Defined Level)4级：已管理级(The Managed)5级：优化级(The Optimizing Level)CMM结构关键过程域关键
27、过程域除1级外，每个成熟度级都包含几个关键过程域(Key Process Areas)它们确定了要实现一个成熟度级别所必须解决的问题和目标处于级别3的软件机构一定要解决级别2和级别3中所有关键域中的问题；4、5级类推共有十八个关键过程域CMM结构关键过程域2级：需求管理软件项目计划软件项目跟踪和监督软件分包合同管理软件质量保证软件配置管理3级：机构过程焦点机构过程定义培训大纲 综合软件管理软件产品工程组间协调同行评审4级：定量过程管理软件质量管理5级：缺陷预防技术更新管理过程变更管理CMM结构共同特性 每个关键过程由五部分组成，称为共同特性(Common Features)执行约定(如建立机构
28、策略和领导关系等)执行能力(如资源、机构结构和培训等)执行活动(如制定计划和规程、执行和跟踪及必要时采取的纠正措施等)度量和分析(如可采用的度量实例等)验证实现(如管理部门和质量保证小组实施的评审和审核等)CMM结构关键实践在共同特性中的实践，描述了要建立一个过程能力所必须完成的活动，即每一个关键过程都要用关键实践的概念进行描述CMM有316个关键实践(Key Practices)关键实践只描述“做什么？”不规定“怎么做？”如不指定生存期模型、不规定产品实现所采用的开发方法和工具，从而可以让各个机构可以选择自己的方法。但必须合理地说明关键实践，以判断是否有效地实现了关键过程域的目标CMM应用软
29、件过程评价与软件能力估价软件过程评价(process assessment)和软件能力估价(capability evaluation)的方法基本相同。但由于评价和估价的动机、目的、输出和结果归属不同，使得在会谈或采访目的、访问范围所采集的信息和结果的表示方式，可能存在重要差别。所以，所采用的的详细规程不同，培训要求也不同评价是在开放、合作环境中进行的，目的在于暴露问题和帮助管理人员和技术人员改进他们所在机构的过程。所以，评价能否成功取决于他们对机构改进的支持。但更重要的是要通过各种座谈会了解机杓构的软件过程。评价的结果除了能确定机构所面临的软件过程问题外，最有价值的是明确机构改进软件过程的途
30、径，促进制定进一步的行动计划，使整个机构关注软件过程的改进，提高整个机构改进行动计划的动力和热情 软件过程评价与软件能力估价软件能力估价是在更为面向审计的环境中进行。估价的目的与金钱有关，因为估价组的推荐意见将影响挑选承制方或投放资金的多少。估价过程的重点在评审巳文档化的审计记录上，这些记录能揭示机构实际执行的软件过程必须指出的是：评价和估价的结果不是不可比的。因为它们都是基于CMM的，其不同之处也是可以解释的CMM应用评价方法评价方法选择评价小组填写成熟度问卷进行响应分析现场访问、会议和文档评审提供基于CMM的调查结果清单制作关键过程域的剖面图，以显示该机构哪些区域巳满足，哪些区域尚未满足关
31、键过程域的目标等CMM与ISO标准比较CMM与ISO 9000-3的设计思路不同，虽然都是着眼于软件质量管理和软件过程管理，它们最大的不同是：CMM强调的是持续的过程改进；ISO 9000-3涉及的是可接受的质量体系最低标准还要指出的是：CMM中关于能力等级是针对每个软件机构的；而ISO/IEC TR 15504中的能力等级是针对每个过程的文档及其修改的控制在生产软件时，修改(Change)是不可避免的，而不修改则是不正常的如果修改中有任何疏忽或处理不当，就非常容易把一个开发得很好的软件带入混乱！所以，只有当每个软件修改可以被说明、分析、跟踪和控制，而且所有需要知道的人都被通知到时，这样才能保
32、证软件修改的质量软件配置管理(SCM,Software Configuration Management)就是用来对软件文档及其修改控制的 软件配置管理软件生存期各个阶段的交付项（包括描述程序的文档、和程序(源代码或可执行代码)，以及包含在程序内部或外部的数据）组成整体软件配置软件配置管理就是对这些交付项修改的管理，因此，不难看出：一个开发组可以生产出几百或上千种独立的交付项，所有这些交付项形成一个相互依赖的层次网在开发和维护的各个步骤中需要不断地再加工、修改和提高，因此任何交付项都可能有很多不同的版本，而且某一项的任何一种版本都与其它交付项的特定版本有关要防止相关交付项上下左右不一致引起的错
33、误，是配置管理要具体解决的问题当然，解决这个问题的机制非常多，以至于需要一个独立的配置管理计划作为质量管理计划的补充，而且应让全体人员都知道，应该怎样完成和控制他们它们的工作质量修改控制无控制的修改必将导致混乱。修改控制过程：修改过程配置审计如何保证修改控制的正确实现，除了进行正式的技术评审(FTR)以外，还要进行软件配置审计。通常检查下列问题：(1)被批准的修改报告中修改巳经完成了吗？(2)是否巳经进行了正式的技术评审？并表明技术的正确吗？(3)软件过程是否遵循了软件工程标准？(4)修改是否在交付项中被完全实现？配置对象的属性是否反映了该修改？(5)是否给出了修改者的姓名和修改的日期？(6)
34、是否遵照了标识修改、记录修改和报告修改的软件配置管理规程？(7)所有的相关交付项都被更新了吗？在有些情况下，配置审计作为正式技术评审的一部分。审计一般都由质量保证小组进行软件配置状态报告软件配置状态报告是软件配置管理的一项任务。它必须回答以下问题：(1)发生了什么事？(2)谁做了此事？(3)此事是什么时候发生的？(4)将影响到什么？配置状态报告可存储在一个联机的数据库中，使得软件开发者和维护者可以通过关键词分类访问修改信息，管理者也可获得与管理相关的信息度量度量的主要目的：(1)更好的理解产品的质量(2)评价过程的效率(3)改进项目层完成工作的质量讨论的重点放在产品质量的量度上。(1)传统(结
35、构化)软件的量度(2)面向对象软件的量度传统软件的量度软件复杂性软件可靠性软件可用性软件安全性 面向对象软件的量度OO软件量度的使用和发展要比传统软件晚得多，其量度的主要目的与传统软件一样任何产品的量度都取决于产品的特性。OO软件与使用传统方法开发的软件根本不同。Berard定义了OO软件五个特殊量度的特性：1.局域性(localization)2.封装性(encapsulation)3.信息隐藏(information hiding)4.继承性(inheritance)5.抽象(abstraction)SQA小组的活动软件质量保证由各种活动中的多个任务完成这些任务由做技术工作的人员和负责质量
36、保证计划、监督、记录、分析及报告工作的SQA小组共同完成CMU/SEI推荐了一组有关质量保证中SQA小组的活动SQA小组活动（续）为项目准备SQA计划本计划与开发项目计划同时制定，由所有感兴趣的相关部门进行评审。本计划将控制由软件工程小组和SQA小组执行的质量保证活动；在计划中要确定以下各点：(1)需要执行的评价(2)需要执行的评审和审计(3)项目可采用的各种标准(4)错误报告和跟踪过程(5)由SQA小组给出的各种文档(6)为软件项目组提供反馈信息的数量SQA小组活动（续）参与开发该顶目的软件过程描述软件工程小组要为进行的工作选择一个过程。SQA小组要按照机构政策、内部软件标准、外部确定的标准
37、，以及软件项目计划其它部分的规定对过程描述进行评审 评审软件工程各项活动，以验证其与巳定义的软件过程的符合程度SQA小组要发现、记录和跟踪与过程的偏差，并对其是否巳经改正进行验证审计指定的软件工作产品，并对其是否符合巳定义的软件过程相关部分进行验证SQA小组对选出的工作产品进行评审；发现、记录和跟踪出现的偏差；对其是否巳经改正进行验证；并定期向项目管理者报告工作结果SQA小组活动（续）确保软件工作和工作产品中的偏差巳被记录在案，并按照已文档化的过程进行处理偏差可以发生在项目计划、过程描述、可采用的标准或技术工作产品中记录任何不符合的部分，并报告给上级管理部门所有不符合的部分，必须受到跟踪，直至
38、它们得到解决SQA小组除上述活动外，还需要协调软件修改的控制和管理，并帮助收集和分析软件量度活动的信息三、软件工程项目的实施与监理三、软件工程项目的实施与监理定义阶段定义阶段问题定义问题定义可行性研究可行性研究需求分析需求分析问题定义问题定义问题定义：要解决的问题是什麽问题定义：要解决的问题是什麽?方法：方法：对系统的实际用户和使用部门负责人进行调研对系统的实际用户和使用部门负责人进行调研分析员扼要地写出对问题的理解分析员扼要地写出对问题的理解在用户和使用部门负责人的会议上认真讨论这在用户和使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不清或者错误理解份书面报告，澄清含糊不清或者错误理解
39、阶段成果：关于问题性质、工程目标和阶段成果：关于问题性质、工程目标和 规模的书面报告（一份承建双方都满意的文档）规模的书面报告（一份承建双方都满意的文档）时间：不超过一天时间：不超过一天问题定义的内容问题定义的内容问题的范围问题的范围需要什么需要什么应用上下文应用上下文假设假设性能要求性能要求外部接口协议外部接口协议软件工程标准，如模块化，可测试性，可扩软件工程标准，如模块化，可测试性，可扩充性充性哪些要求是必须的，那些是任选的哪些要求是必须的，那些是任选的可行性分析的目标可行性分析的目标识别用户要求识别用户要求评价系统的可行性评价系统的可行性进行经济分析和技术分析进行经济分析和技术分析把功能
40、分配给硬件、软件、人、数据库和其把功能分配给硬件、软件、人、数据库和其它系统元素它系统元素建立成本和进度限制建立成本和进度限制生成系统规格说明，形成所有后续工程的基生成系统规格说明，形成所有后续工程的基础础可行性分析的任务可行性分析的任务识别希望的功能和性能范围识别希望的功能和性能范围确定系统的功能、性能、约束和接口确定系统的功能、性能、约束和接口将功能赋予一个或多个系统元素（即软件、将功能赋予一个或多个系统元素（即软件、硬件、人等）硬件、人等）提出一些候选方案并做评价提出一些候选方案并做评价对同一功能，可以分配不同的系统元素对同一功能，可以分配不同的系统元素为选取最有效的分配方案，使用一组权
41、衡准为选取最有效的分配方案，使用一组权衡准则进行评价则进行评价可行性分析的类型可行性分析的类型经济可行性（成本经济可行性（成本-效益分析）效益分析）成本效益分析：长期利益、短期利益成本效益分析：长期利益、短期利益公司经营策略：市场前提公司经营策略：市场前提技术可行性技术可行性开发的风险：在给出的限制范围内，能否设计出系统，开发的风险：在给出的限制范围内，能否设计出系统，并实现必须的功能和性能并实现必须的功能和性能资源：资源：开发人员的水平，硬件、软件开发人员的水平，硬件、软件技术：相关技术的发展能否支持系统技术：相关技术的发展能否支持系统操作可行性操作可行性用户单位的行政管理，工作制度；使用人
42、员的素质用户单位的行政管理，工作制度；使用人员的素质法律可行性法律可行性合同，侵权，违法，责任，版权合同，侵权，违法，责任，版权可行性分析报告可行性分析报告阶段性成果阶段性成果可行性分析报告可行性分析报告 一般只有投资能取得较大效益的工程项目才继续一般只有投资能取得较大效益的工程项目才继续开发开发否则应及时中止工程项目，避免更大的浪费否则应及时中止工程项目，避免更大的浪费可行性研究的工作量大约占开发总工作量的可行性研究的工作量大约占开发总工作量的5%需求分析需求分析需求分析的目标需求分析的目标 借助于当前系统的逻辑模型导出目标系统的逻辑模型。借助于当前系统的逻辑模型导出目标系统的逻辑模型。当前
43、系统当前系统目标系统目标系统物理模型物理模型物理模型物理模型逻辑模型逻辑模型逻辑模型逻辑模型模型化模型化具体化具体化抽象化抽象化实例化实例化怎么做怎么做做什么做什么导导出出理理解解需需求求表表达达需需求求 参考当前系统建立目标系统模型参考当前系统建立目标系统模型需求分析的过程需求分析的过程需求获取需求获取需求表示需求表示需求验证需求验证需求规格说明书需求规格说明书总体设计总体设计通过不通过可行性分析报告可行性分析报告需求分析获取的内容需求分析获取的内容识别识别物理环境物理环境界面界面用户或者人的因素用户或者人的因素功能功能文档文档数据数据资源资源安全性安全性质量保证质量保证需求分析的表示需求分
44、析的表示模型化表示模型化表示将需求定义用工具（例如数据流图和数据字典）将需求定义用工具（例如数据流图和数据字典）严格地描述出来严格地描述出来分析方法分析方法结构化方法（自顶向下，逐步求精）结构化方法（自顶向下，逐步求精）面向数据流的结构化分析方法（面向数据流的结构化分析方法（SASA）面向数据结构的面向数据结构的JacksonJackson方法方法(JSD)(JSD)面向对象方法（面向对象方法（OOOO）面向数据内容的面向对象分析方法面向数据内容的面向对象分析方法(OOA)(OOA)等等定义阶段的监理定义阶段的监理定义阶段监理的目标定义阶段监理的目标 对软件功能、性能和其它需求描述的正确性、完
45、整对软件功能、性能和其它需求描述的正确性、完整性和清晰性给予评价性和清晰性给予评价定义阶段监理的依据定义阶段监理的依据软件需求说明书（软件需求说明书（GB856TGB856T8888）国标国标计算机软件开发规范计算机软件开发规范定义阶段承建单位提交的文档定义阶段承建单位提交的文档可行性研究报告可行性研究报告项目开发计划项目开发计划数据要求说明书数据要求说明书需求规格说明书需求规格说明书用户手册概要用户手册概要定义阶段的监理定义阶段的监理定义阶段监理的控制内容定义阶段监理的控制内容系统定义的目标是否与用户的要求一致系统定义的目标是否与用户的要求一致系统需求分析阶段提供的文档资料是否齐全系统需求分
46、析阶段提供的文档资料是否齐全文档中的所有描述是否完整清晰准确反映用户要文档中的所有描述是否完整清晰准确反映用户要求求与所有其它系统成分的重要接口是否都已经描述与所有其它系统成分的重要接口是否都已经描述确定所开发项目的数据流与数据结构是否足够确定所开发项目的数据流与数据结构是否足够所有图表是否清楚，在不补充说明时能否理解所有图表是否清楚，在不补充说明时能否理解定义阶段的监理定义阶段的监理定义阶段监理的控制内容定义阶段监理的控制内容主要功能是否已包括在规定的软件范围之内，是否都主要功能是否已包括在规定的软件范围之内，是否都已充分说明已充分说明设计的约束条件或限制条件是否符合实际设计的约束条件或限制
47、条件是否符合实际开发的技术风险是什么开发的技术风险是什么是否考虑过软件需求的其它方案是否考虑过软件需求的其它方案是否考虑过将来可能会提出的软件需求是否考虑过将来可能会提出的软件需求是否详细制定了检验标准，它们能否对系统定义是否是否详细制定了检验标准，它们能否对系统定义是否成功进行确认有没有遗漏，重复或不一致的地方成功进行确认有没有遗漏，重复或不一致的地方软件开发计划中的估算是否受到了影响软件开发计划中的估算是否受到了影响设计阶段设计阶段概要设计概要设计将软件需求转化为数据结构和软件的系统结构将软件需求转化为数据结构和软件的系统结构详细设计详细设计通过对结构表示进行细化，得到软件详细的数通过对结
48、构表示进行细化，得到软件详细的数据结构和算法。据结构和算法。设计阶段设计阶段设计阶段的流程概要设计概要设计概要设计概要设计将软件需求转化为数据结构和将软件需求转化为数据结构和软件的系统结构；软件的系统结构；概要设计只是描绘出软件的总体框架，根据概要设计只是描绘出软件的总体框架，根据功能、性能需求和数据需求导出软件的数据功能、性能需求和数据需求导出软件的数据结构和系统结构。概括地说：概要设计进行结构和系统结构。概括地说：概要设计进行数据设计和系统结构设计。数据设计和系统结构设计。概要设计的任务概要设计的任务概要设计制定规范。包括：概要设计制定规范。包括：阅读和理解软件需求说明书，确定软件设计的阅
49、读和理解软件需求说明书，确定软件设计的目标，及实现的顺序目标，及实现的顺序根据目标确定最合适的设计方法根据目标确定最合适的设计方法规定设计文档的编制标准规定设计文档的编制标准规定编码的代码体系，与硬件、操作系统的接规定编码的代码体系，与硬件、操作系统的接口规约，命名规则等口规约，命名规则等 概要设计的任务概要设计的任务软件系统结构的总体设计软件系统结构的总体设计将复杂的系统功能划分成模块的层次结构将复杂的系统功能划分成模块的层次结构确定每个模块的功能、模块间的调用关系、模确定每个模块的功能、模块间的调用关系、模块间的接口等块间的接口等评估模块划分的质量及导出模块结构的规则评估模块划分的质量及导
50、出模块结构的规则 处理方式设计处理方式设计确定为实现软件系统功能需求所必需的算法，确定为实现软件系统功能需求所必需的算法，并评估算法性能并评估算法性能确定为满足软件系统的性能需求所必需的算法确定为满足软件系统的性能需求所必需的算法和模块间的控制方式和模块间的控制方式确定外部信号的接收发送方式确定外部信号的接收发送方式 概要设计的任务概要设计的任务数据结构设计数据结构设计 确定软件涉及的文件系统的结构、数据库的模式及子模式，确定软件涉及的文件系统的结构、数据库的模式及子模式，并进行数据完整性和安全性设计。并进行数据完整性和安全性设计。确定输入、输出文件的详细的数据结构确定输入、输出文件的详细的数
