1、GIS软件工程化管理,第六讲,2,软件工程化管理内容提要,概述 软件计划管理 人员管理 软件配置管理 软件质量保证 软件审查 软件测试,3,软件工程化管理课程目标,了解软件工程化管理的概念和内容 学习软件项目计划管理和规模评估方法 了解软件开发团队的典型模式和管理方法 了解软件配置管理的概念、内容和实施 了解软件质量保证的概念和工作内容 了解软件审查方法 了解软件测试的方法、级别和组织,4,概述管理是关键,美国: 软件产业相对发达; 过去人们一直期望运用新的软件方法和技术，来提高软件的生产率和质量，但经过了20多年的努力仍未实现; 政府和工业界终于认识到：他们的根本问题在于对软件过程缺乏管理。
2、在一种无纪律、混乱的软件的开发状态下，即使有较好的方法和工具也难以获益。 国内: 软件产业相对落后; 外正、反二方面的经验告诉我们：软件工程化的技术是基础，而软件工程化的管理是关键。,5,概述软件管理过程的内容,组织管理; 计划管理; 过程管理; 资源管理; 文档管理;,质量管理; 软件配置管理; 风险管理; 对外包的管理。,6,概述组织管理,应将项目组置于机构领导下； 当项目规模较大、比较复杂时，可以设立管理组和技术组，负责日常的管理工作和技术工作； 每个项目可成立一个或多个开发组，并任命开发组组长； 明确项目参与人的职责和任务。,7,概述计划管理,在项目立项后、全面启动前，制定项目开发计划
3、，包括：总计划、详细分解计划、配置管理计划等，以作为项目管理的依据。 开发计划应规定开发全过程的各项工作内容、参加人员、完成的产品、工作进度、经费预算、软件和硬件资源的支持、子项目专题计划的要点以及可能存在的关键问题等。,8,概述过程管理,过程管理是指项目开发过程中的动态管理，即按照软件开发模型，对项目开发各阶段的工作进行及时、有效的管理。 围绕各阶段过程管理任务及应生成的文档开展。,9,概述资源管理,人员 确定完成该项目所需人员的专业类型、技术水平和数量要求，并指明对人员必须进行的培训和完成培训的最终日期。 设施 确定完成项目所需的硬件设施和支持软件，到货日期和备份的要求，并考虑设备的性能价
4、格比，以及用户连续使用设备的可能性。 经费 编制本项目的财务概算，逐项列出项目开发所需的经费预算，包括人员费、机时费、资料费、办公费、差旅费、软硬件购置费、通讯设备和专用设备的租金等，并应估算软件的成本。,10,概述文档管理,规定需要编制哪几种文档； 按时完成开发各阶段的文档，并经编写者及有关负责人签署归档。软件开发各阶段的评审，包括文档评审的内容； 在开发期间，规定文档维护和管理的人员以及修改文档的审批手续； 必须保证交付的文档和运行的软件完全一致，软件如有修改，文档必须反映修改后的实际状态。,11,概述质量管理,评审: 软件需求规格说明评审 接口需求规格说明评审 设计评审 测试计划与集成测
5、试评审 质量监督的若干措施: 双岗制 自检 内部评审 正式评审 内部测试 正式测试,12,概述软件配置管理,制定并执行软件配置管理规程。 对各种软件开发阶段所产生的各种形式和各种版本的文档、程序以及数据进行统一的配置和管理。,13,概述风险管理,预测项目的风险范围和构成因素； 估算风险出现的概率和潜在的损失； 估算降低风险因素所需的资源； 确定降低风险的措施； 制定降低风险的实施计划； 及时取得反馈信息以确保降低风险的措施获得成效。,14,概述对外包的管理,与外包方正式签定必要的合同； 指派专人负责和关心外包方的工作，保持联系，及时沟通信息； 对外包方的工作进行定期或分阶段的检查，发现问题，及
6、时解决。,15,概述风险意识,建立最基本的软件过程，并有效运行; 根据风险排定优先次序; 确定核心工作，逐步扩展; 实现最终目标，并持续改进。,16,概述回顾,管理是关键 工程化管理的主要内容: 组织管理、计划管理、过程管理、资源管理、文档管理、质量管理、软件配置管理、风险管理、对外包的管理,17,计划管理软件项目计划,定义软件项目计划是指为软件工程的运作和软件项目活动的管理提供一个合理的基础和可行的工作计划的过程。 目标提供一个框架，使得管理者能够对资源、成本及进度进行合理的估算。,18,计划管理软件项目计划,目的: 使软件项目的开发建立在可靠的基础上，并将计划文档化，由开发人员遵循，并据此
7、跟踪检查计划的执行; 确定软件项目开发的活动和承诺，使软件开发工作有续而协调的开展，以便根据软件计划的资源、约束和能力逐步向客户履行承诺; 明确与软件项目相关的组织和个人的承诺，将任务责任落实到组和人，从组织管理上保证项目开发的成功。,19,计划管理实现过程,计划过程初始,制定SDP,对SDP审查和批准,实施软件开发计划 SDP,过程度量和评价,修改SDP,软件规模、成本、进度估计,需求管理,软件配置管理,软件质量保证,软件项目跟踪和监控,20,计划管理编制计划目的,在软件管理者、技术人员和客户之间传达项目范围和资源信息； 定义风险并提出有关风险管理技术的建议； 定义管理复审的成本和进度； 为
8、与项目相关的所有人员提供软件开发的整体方法； 概述如何保证质量及进行变更管理。,21,计划管理计划一般格式,1 引言1.1 计划的目的1.2 项目的范围和目标1.2.1 范围说明1.2.2主要功能1.2.3性能问题1.2.4管理和技术约束 2 项目估算2.1 用于估算的历史数据2.2 估算技术2.3 工作量、成本和持续时间的估算 3 风险管理策略3.1 风险表3.2 对需要管理的风险的讨论3.3 每个风险的RMMM计划3.3.1 风险缓解3.3.2风险监控3.3.3风险管理(意外事件计划),4 进度4.1 项目工作细分结构4.2 任务网络4.3 时间表(甘特图)4.4 资源表 5 项目资源5.
9、1 人员5.2 硬件和软件资5.3特殊资源 6 人员组织6.1 项目组组织结构6.2 管理报告 7 跟踪及控制机制7.1 质量保证和控制7.2 变更管理和控制 8 附录,22,计划管理项目估算作用,对项目工作量和最终完成日期提出相当准确的评估 建立适当的期望，并且提高项目组(最终用户)对潜在风险和预期成果的认识水平 帮助评估中间里程碑，使得问题可尽早纠正 确定额外需求的影响 评定可能的风险对项目进度表的影响,23,计划管理项目估算过程,24,计划管理项目估算方法,基于问题进行估算 代码行 功能点 特征点 基于过程进行估算 基于经验进行估算,25,计划管理代码行估算,确定软件范围 分解 为每个功
10、能确定乐观值(Sopt)、可能值(Sm)和悲观值(Spess) 计算期望值EV = (Sopt+4Sm+Spess)/6,26,计划管理功能点估算,使用软件所提供的功能的测量作为规范化值。 软件功能点是基于软件信息领域的可计算的测量及其软件复杂性的评估而导出的。 功能点FP = 信息域值0.65+0.01Fi Fi : 复杂度调整值,27,计划管理信息域值的计算,测量参数,计数,简单,平均,复杂,用户输入数,用户输出数,用户查询数,文件数,外部接口数,信息域值,?,?,?,?,?,?,?,?,?,?,?,3,4,3,7,5,4,5,4,10,7,6,7,6,15,10,=,=,=,=,=,加权
11、因子,28,计划管理Fi考虑的项目,需要数据通信吗? 有分布处理功能吗? 性能很关键吗? 系统需要联机数据项吗? 需要联机更新主文件吗? 内部处理复杂吗? 代码需要被设计成可重用的吗? 设计中需要包括转换及安装吗?,系统需要可靠的备份和恢复吗? 系统是否在一个已有的、很实用的操作环境中运行? 联机数据项是否需要在多屏幕或多操作之间切换以完成输入? 输入、输出、文件或查询很复杂吗? 系统需要支持不同组织的多次安装吗? 应用的设计方便用户修改和使用吗?,29,计划管理Fi的取值,30,计划管理功能点估算举例,测量参数,简单,平均,复杂,用户输入数,用户输出数,用户查询数,文件数,外部接口数,信息域
12、值,63=18,74=28,03=0,57=35,95=45,24=8,75=35,24=8,210=20,07=0,36=18,07=0,46=24,315=45,210=20,功能点,304,影响系数,1.15,功能点总数,350,31,计划管理基于过程估算,获得软件功能描述 每个软件功能需要通过一系列的软件过程活动实现，用二维表格表示 估算每个软件功能的软件过程活动的工作量 估算项目的工作量(人月数),32,计划管理基于过程估算实例,任务,33,计划管理基于经验估算,E = A + B (EV)C E: 以人月为单位的工作量 EV: 估算变量(FP) A、B、C: 经验导出的常数,34,
13、计划管理估算技巧,避免无准备的估算 留出估算的时间，并做好计划 使用以前项目的数据 使用由开发人员为基础的估算 走查估算 分类法估算 详细的较低层次上的估算 不要忽略普通任务 使用软件估算工具 使用几种不同的估算技术，并比较它们的结果 项目进行中改变评估算准则,35,计划管理回顾,软件项目计划的概念 计划管理的实现过程 项目规模的估算,36,人员管理,人员及其管理是软件项目成功的最重要因素之一 PM-CMM,37,人员管理因素,待解决问题的困难程度 要产生的程序规模 小组生命周期 问题能够被模块化的程度 待开发系统所要求的质量和可靠性 交付日期的严格程度 项目所需的交流(通信)程度 问题解决
14、创新 战术执行,38,人员管理挑战,规模 地理分布 技术能力 应用的复杂性 变更的比例,项目经理 在公司本部,市场经理 在上海,程序员 在开发基地,QA工程师 在广州,系统分析 在北京,美工设计 在深圳,dll,C+,Java applet,CAD,Execl,IDE,IDE,Word,Quark Xpress,Frontpage,Photoshop,.doc,HTML,XML,.gif,.jpg,Web tools,Web tools,仿真,39,人员管理角色,项目经理 需求经理 开发经理 测试经理 质量保证经理 配置管理经理 其他经理,系统分析员 开发人员 测试人员 质量保证人员 配置管理
15、人员 其他人员,40,人员管理技能,技术领域 张三 李四 王二 刘一 需求调查 H H M M 需求分析 M L L L 使用用例分析 H L L M 创建原型 M L H M 处理建模 H H L L 数据建模 H M M M 结构化设计 H M M M 面向对象技术 M L L L 可行性评估 L L L H 风险分析 M M M M 测试技术 M L L L等等.,H = 专家 M = 熟练 L = 新手,41,人员管理业务项目组,一个技术领导带领 其他成员来自不同专业领域,地位相同,42,人员管理首席程序员项目组,由首席程序员、后备程序员、管理员、工具员、语言顾问组成 首席程序员具有超
16、强能力 适合创新项目,43,人员管理特征项目组,开发、SQA、文档管理、配置管理和市场人员都采用传统的等级报告结构 有授权、责任平衡优势 适合问题解决,44,人员管理专业运动员项目组,项目组的管理者负责挑选组员 组员都是某个领域的专家,45,人员管理其他项目组,搜索救援项目组 特种武器和战术(SWAT)项目组 戏剧团队,46,人员管理大型项目组,大型项目增加了人员交流的负担 为了简化通信，可以将大型项目组划分成小的项目组,47,人员管理项目参与者,高级管理者 项目管理者 开发人员 客户 最终用户,48,人员管理沟通,正式的、非个人的方法(培训、研讨会、评审) 正式的、个人间的规程 非正式的、个
17、人间的规程 电子通信 个人间网络,49,人员管理其它内容,人员招聘 人员激励 人员培训 人员职业生涯设计 人员能力评估 等等,50,人员管理回顾,人员是软件开发的关键要素 人员管理是资源管理的重要部分 各种开发项目组队方式 人员管理的内容广泛,51,软件配置管理解决的问题,同时更新 共享代码 公共代码 版本,进行 软件配置管理,52,软件配置管理概念,配置配置由部件表和部件分解图组成。部件分解图定义了基线中包含的所有要素以及如何将它们安装在一起。 软件配置项为了配置管理的目的而作为一个单位来看待的软件要素的集合。 软件配置软件产品在生存期各个阶段的不同形式（记录特定信息的不同媒体）和不同版本的
18、程序、文档及相关数据的集合，或者说是配置项的集合。,53,软件配置管理范围,54,软件配置管理过程,55,软件配置管理计划格式,1 概述1.1 SCM目标1.2 系统概述 2 SCM组织2.1 SCM职责2.2 配置管理委员会成员2.3 配置管理委员会章程2.4 产品保证关联 3 SCM方法3.1 基线和内容3.2 标识系统3.3 控制系统,3.4 审核3.5 状态记录3.6 配置管理支持工具 4 SCM规程4.1 规程手册4.2 表格和记录 5 SCM实施5.1 人事计划5.2 系统支持计划5.3 预算5.4 关键检查点,56,软件配置管理配置标识要求,唯一性 可追溯性 反映产品的结构 支持
19、工具,57,软件配置管理配置标识对象,58,软件配置管理标识例子,例1、CODE是根结点为PCL_TOOLS树结构的第六层结点，对其命名为：PCL_TOOLS/EDIT/FORMS/DISPLAY/AST_INTERFACE/CODE,59,软件配置管理标识例子,例2: 文档的标识 标识规则:VVV-WWW-BBB-XXX.NN.MM 含义: VVV 系统识别符 WWW 分系统识别符 BBB 文档类别 XXX 版本标识 NN 发布号 MM 修订标识,60,软件配置管理变更管理,软件变更的不可避免性 软件变更的复杂性 软件配置项数量大 版本多 变更的迁延性 人员沟通协调 变更管理的任务 分析变更
20、 记录和追踪变更 采取措施保证变更在受控状态下进行,61,软件配置管理基线定义,基线基线是软件开发过程中的里程碑。它以一个或多个软件配置项的交付为标志。基线又通过了正规评审的软件配置项组成。从此以后，基线作为进一步开发的基础。基线只能通过正式的变更过程才能改变。,62,软件配置管理基线的概念,63,软件配置管理三种常见基线,64,软件配置管理变更控制,对基线提出的变更必须经过一定层次的评审 建立更改控制层 必须确定和理解提出的变更对经费、进度、软件开发和生产造成的影响 必要时，必须获得配置控制委员会的批准、并配置主要管理人员和项目组成员 必须正确实施被批准的变更 一旦变更被批准，必须通知所有受
21、影响的部门,65,软件配置管理配置库,作用 记录与配置相关的所有信息 利用库中的信息可评价变更的后果 可利用库中的信息查询 三类库 开发库 受控库 产品库,66,软件配置管理人员组织,变更控制委员会(Change Control Board)也称为配置控制委员会(Configuration Control Board) 变更授权人(Chang control authority,CCA) 配置经理 模块主管,67,软件配置管理变更控制,68,软件配置管理变更请求表,69,软件配置管理版本控制,版本一个基线或一个软件配置项特殊的事例。 版本控制通过分支和合并为并行开发提供支持 并行开发允许不同的
22、项目在同一时间使用相同的原文件 并行开发隔离了那些永远不被共享的工作。 并行开发允许工程师即使某一条开发线被冻结了，仍可以沿着一个分支继续开发。,70,软件配置管理版本控制,分支是软件配置项同时沿着两个或多个分支展开，新版本独立地添加到各自的分支中。 合并有选择地将分支或其它基线中对源文件所做的修改与主分支中相应的源文件对应起来的过程。 文件比较用来比较两个或多个分支或基线中具有相同名字的文件，并识别这些不同的文件。,71,软件配置管理版本管理,软件版本 为满足不同用户的不同使用要求，如适用于不同运行环境或不同平台的系列产品。 软件产品投入使用以后，经过一段时间运行提出了变更的要求，需要做较大
23、的修正或纠错，增强功能或提高性能。 版本标识版本管理也称版本控制。 号码版本标识 符号版本标识把重要的版本属性有选择地给出。如：V1/VMS/DB Server 版本管理工具,72,软件配置管理版本管理,73,软件配置管理配置审核,配置审核是指对于存储配置项及相关记录的软件基线库的结构、内容和设施进行检验，其目的在于验证基线是否符合描述基线的文档。 验证包括： 配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象； 配置标识的准则是否得到了遵循； 变更控制规程是否以遵循，变更记录是否可供使用 是否保持了可追溯性。,74,配置审核主要工作,功能配置审核验证配置项的实际功效是与其软件需求一
24、致的。 物理配置审核确定配置项符合预期的物理特性，即特定的媒体形式。,75,配置审核主要作用,确保软件配置管理的有效性，不允许出现任何混乱现象。例如： 防止出现向用户提交了不适合的产品，如交付了用户手册不 适当的版本； 发现不完善的实现，如开发出不符合初始规格说明或未按变 更请求实施变更； 找出各配置项间不匹配或不相容的现象； 确认配置项已在所要求质量控制审查之后作为基线入库保存； 确认记录和文档保持着可追溯性。,76,配置审核工作步骤,由项目经理决定何时进行配置审核工作 质量保证组或软件组的配置管理组指定该项目的配置审核 人员 项目经理和配置审核员决定审核范围。 配置审核员准备配置审核检查单
25、 配置审核员安排时间审核文档和记录，审核活动可能涉及到： 项目范围 配置项的检入（check-in）及检出（check_out）评审记录 配置项的变更历史测试记录 文件的命名变更请求 版本的编号 配置审核远在审核中发现不符合现象，并作记录。 由项目经理负责消除不符合现象。 配置审核员验证所有发现的不符合现象确已得到解决。,77,软件配置管理配置状态报告,任务有效的记录和报告管理配置所需要的信息。 目的及时、准确的给出软件配置项的当前状况，供相关人员了解，以加强配置管理工作。 信息 配置项的当前标识 已交付软件的配置 变更请求或问题报告的状态 已获准变更的状态,78,软件配置管理实现,手工方法的
26、局限性 规程过于繁琐 可能出现人为的失误 个别人可能持逆反心理 必须作充分培训 对人员的依赖性较大 工具的可能好处 减少了人为因素 节省人工实施配置管理所花费的时间 发生配置问题的机会较少 程序人员可集中精力在自己的工作中，不必担心配置问题 两条建议 首先采用手工方法，积累经验，提高认识 选择配置管理工具时，应慎重，结合实际需要,79,软件配置管理工具,Visual Source Safe Perforce CVS PVCS JBCM ClearCase CCC/Harvest,80,软件配置管理回顾,软件配置管理的概念和作用 软件配置管理的内容 如何建立基线并进行管理 如何进行版本控制 如何
27、进行变更管理 如何监控配置管理过程 常用配置管理工具,81,软件质量保证质量,定义:明确声明的功能和性能需求、明确文档化过的开发标准、以及专业开发人员开发的软件所应具有的所有隐含特征都得到满足。 问题:假定你得到了一个按进度、在预算内提交的软件产品，它能够正确和有效的完成指定的功能。它是高质量的软件吗?,82,软件质量保证软件质量模型(McCall),83,软件质量保证软件质量模型(ISO/IEC),ISO/IEC 9126:1991(GB/T 16260-1996),84,软件质量保证,定义:保证软件过程和产品符合需求、标准和程序的一套有计划和系统化的活动。“过程”包括与设计、编码、测试和维
28、护相关的所有活动。“产品”包括软件、相关数据、文档和所有支援与报告的文书工作。 挑战:普通人评审专家的工作。,85,软件质量保证SQA目标,通过适当的监控软件及其开发过程来改进软件质量 确保软件及其开发过程与已定义的标准和规程要求完全一致 确保能及时发现产品、过程和标准的不足，报告给管理者,86,软件质量保证SQA职责,复查所有开发计划和质量计划的完整性; 作为检查调解人参与设计检查和代码检查; 复审所有测试计划，使其遵循采用的标准; 复审所有测试结果样本，以便确定测试遵循了制定计划; 定期审计SCM实施情况，以确定其遵循采用的标准; 参与所有项目阶段评审并记下不符合项。,87,软件质量保证S
29、QA必需条件,软件质量保证计划 (SQAP) 由优秀SQA人员组成的SQA的小组 高级管理人员的支持 为执行SQA活动提供足够的资源和资金 培训SQA组的成员以便执行其SQA活动 软件项目的成员认同SQA组的任务、责任、权力和价值,88,软件质量保证SQA人员,希望 经验丰富 知识渊博 关心产品质量 解决方案 轮岗 宣传促进SQA,89,软件质量保证高级管理者支持,SQA报告不在软件开发项目管理者控制下; 高级管理者必须首先同意SQA目标,并统一解决在SQA和项目管理者之间的主要SQA问题; 建立SQA管理者直接向高级管理者报告的机制。,90,质量过程与每个人相关,质量方针 标准 程序,自检
30、提议修改 承诺质量,客户 开发者 管理者,确定期望 理解期望 培育期望,91,软件质量保证 SQA活动,为项目准备SQA计划 参与开发项目的软件过程描述 复审各项软件工程活动 审计制定的软件工作产品 确保软件工作及工作产品的偏差已被记录在案，并根据与定规程进行处理 记录所有不符合的部分，并报告给高级管理者,92,软件质量保证计划(ANSI/IEEE),1 计划的目的 2 参考文献 3 管理 3.1 组织 3.2 任务 3.3 责任 4 文档 4.1 目的 4.2 所需的软件工程文档 4.3 其它文档 5 标准、实践和约定 5.1 目的 5.2 约定 6 复审和审计 6.1 目的 6.2 需求复
31、审,6.3 软件需求复审 6.4 设计复审 6.5 软件验证和确认复审 6.6 功能审计 6.7 物理审计 6.8 过程内部审计 6.9 管理复审7 测试8 问题报告和改正行动9 工具、技术和方法学 10 代码控制 11 介质管理 12 供应商控制 13 记录收集、维护和保留 14 培训 15 风险管理,93,计划编制关于文档,软件需求规格说明, 足够精确的详细说明每个软件功能、性能参数、接口或者其他属性，以便进行验证。 软件设计描述, 描述主要的组件, 数据库, 内部接口。 软件验证与确认计划, 描述用于检验设计实现了需求、编码实现了设计以及代码满足需求的方法。 软件验证与确认报告, 用于报
32、告SQA的验证与确认活动。 用户文档, 安装、操作和维护软件所需的文档。 其它, 包括软件开发计划,软件配置管理计划,标准和程序手册, 计划好的评审方法。,94,计划编制关于标准、实践和约定,最少需要包括的标准: 文档标准 设计标准 编码标准,95,计划编制关于复审和审计,标识软件工程小组、SQA小组和客户进行的审计和复审活动。 给出各种审计和复审方法的总览。,96,计划编制关于测试,软件测试计划和过程 测试记录的保存,97,计划编制关于问题报告和改正行动,定义错误和缺陷的报告、跟踪和解决规程 标识相关活动的组织责任,98,SQA任务系统分析与软件定义,协助确定配置管理方针 参与需求评审 对可
33、用的工具、技术和方法进行评审 定义软件和文档的纠正措施规程 定义SQA的职责、人员需求和工具 评审软件开发计划 评审转承包商的质量保证体系，编制对转承包商的SQA要求,99,SQA任务软件需求分析,评审SCM计划，并开发审核规程 评审软件需求规格说明书和客户要求的一致性 评审工具、技术和方法的适应性 实施SQA计划 参加项目状态会议，评审状态报告,100,SQA任务软件设计,审核SCM计划的一致性 参与软件设计评审 评审软件设计规范 审核开发进展情况 验证需求追溯矩阵和需求的可测试性 评审设计中工具的使用情况 评审初步测试计划、规程和工具 审核转承包商的活动，监控其SQA计划的实施 评审/更新
34、SQA计划，监控其一致性 审核有关评审、资源、进度方面的记录,101,SQA任务软件实现,审核SCM计划的一致性 参与代码审查，审查代码和标准的一致性 监控工具的使用和维护 评审最终测试计划和说明，见证单元测试 审核代码问题以便纠正 审核转承包商的活动，监控其SQA计划的实施 评审/更新SQA计划，监控其一致性 参与状态会议、评审状态报告、审核开发记录,102,SQA任务软件集成,审核SCM计划的一致性、审核配置管理库、审核基线 监控工具的使用和维护 见证集成测试、验收测试，确认测试报告 审核测试不足，以便纠正 审核转承包商的活动，监控其SQA计划的实施 评审/更新SQA计划，监控其一致性 参
35、与状态会议、评审状态报告、审核开发记录,103,SQA任务软件验收交付,审核SCM计划的一致性、审核配置管理库、参与CCB 评审更新的文档，审核更新的开发记录 审核客户提出的问题，以便更正 评审/审批转承包商的变更 更新SQA计划,104,软件质量保证回顾,软件质量模型 软件质量保证的概念和作用 软件质量保证计划 软件开发各阶段的质量保证工作,105,软件审查概念,软件工程过程的“过滤器” 可以用于软件开发过程的多个点 作用是发现错误 可以采用多种方法,106,软件审查好处,开发过程每前进一步，发现和修复缺陷的平均代价要增长10倍 缺陷放大模型：,107,软件审查正式技术复审,正式技术复审由软
36、件工程师完成。 目标： 在软件的任何一种表示形式中发现功能、逻辑或者实现的错误； 证实经过复审的软件的确满足需求； 保证软件的表示符合预定义的标准； 得到以一种一致的方式开发的软件； 使项目更易于管理。,108,软件审查复审会议,复审会议应该35人参加 应该提前准备，但准备时间应少于2小时 复审会议时间应该在2小时之内 复审会议决定：不修改接受否决暂时接受 复审报告和记录被保存，并对纠正活动进行跟踪,109,软件审查复审指南,复审产品，而不是复审生产者 制定日程，并且遵守日程 限制争论和辩驳 对各种问题都发表见解，但是不要试图解决所有记录的问题 作书面笔记 限制参与人数，并坚持事先作准备 为每
37、个要复查的工作产品建立一个检查表 为正式技术复审分配资源和时间 对所有复审者进行有意义的培训 复审以前所作的复审,110,软件审查回顾,软件审查的概念和意义 软件正式技术复审 技术复审会议的组织,111,软件测试定义,由人工或自动方法来执行或评价系统或系统部件的过程，以验证它是否满足规定的需求；或识别出期望的结果和实际结果之间有无差别。(国家标准GB/T 114571995软件工程术语) 使用为发现错误所选择的输入和状态的组合而执行代码的过程。(IEEE/ANSI),112,软件测试测试与调试,测试不是调试，调试也不是测试。 主要区别： 测试是一种检验，调试是推理过程。 测试从已知条件开始，使
38、用预先定义的规程并且有可预知的结果；调试的开始条件可能是不可知的，结果不可预见。 测试经常由非程序设计人员完成，调试必须由程序设计者完成。,113,软件测试测试无止境,除了最简单的程序，任何程序的完全测试都是不可能的。 测试可以表明缺陷的存在，但绝不能证明没有缺陷。 测试只能使好的设计变得更好,114,软件测试能做什么?,发现软件中隐藏的缺陷 为软件质量的评价提供数据支持 为软件开发过程的改进提供帮助 对软件工程项目进行验证与确认 验证(Verification):”Are we building the product right?” 确认(Validation):”Are we build
39、ing the right product?”,115,软件测试正确理解,有效的测试对于开发可靠、安全和成功的软件是必须的。 不是“银弹(silver bullet)” 测试具有有效范围，它不是其他软件工程方法的替代品。 测试活动是否与软件过程协调一致，对测试的有效性有重要影响。 软件测试应系统的、针对性的和自动的进行。,116,软件测试基本原则,所有的测试都应追溯到客户需求 在测试开始前的较长时间就进行计划 Pareto原则可应用于软件测试 测试应从小规模开始，逐步转向大规模 穷举测试是不可能的 为达到最有效，应该由独立的第三方来构造测试,117,软件测试方法,静态测试技术 动态测试技术 白
40、盒测试(White-Box Testing) 黑盒测试(Black-Box Testing),118,软件测试静态测试的特征,静态测试是不动态执行程序代码而寻找程序代码中可能存在的缺陷或评估程序代码的过程。 可以由人工进行，充分发挥人的逻辑思维优势。 可以借助软件工具自动进行。,119,软件测试常用静态测试方法,代码复查 代码检查(Code Inspection) 代码走查(Walkthrough) 桌面检查(Desk Checking) 代码审查(Code Review) 静态分析(主要由软件工具自动进行),120,软件测试白盒测试,已知产品内部工作流程，通过测试来检测产品的内部动作是否按照
41、详细设计规格说明的规定正常进行，而不管它的功能； 全面了解程序内部逻辑结构，对所有逻辑路径进行测试； 穷举路径测试； 依据详细设计规范； 检查程序如何工作，是一种验证技术； 也称为结构测试或逻辑驱动测试。,121,软件测试逻辑路径的数量,程序的执行序列(逻辑路径)的数目是庞大的，简单的重复就有可能使执行序列的数目增大到天文数字。,例子： For (int i =0;in;+i)if (a.get(i)=b.get(i)xi=xi+100;elsexi=xi/2; ,解： 可能的执行序列/路径数是2n1 当n=20时，执行序列/路径数是1,048,577,122,软件测试基本覆盖,基于控制流的测
42、试 语句覆盖 分支覆盖 条件覆盖 条件组合覆盖 基本路径覆盖 循环覆盖 数据流覆盖 变元覆盖(mutation coverage),123,软件测试覆盖率与缺陷查找,覆盖与发现缺陷之间没有必然联系 获得任何覆盖目标都不意味着没有缺陷 需求相关的缺陷 丢失的代码 中断相关的缺陷 兼容性/配置相关的缺陷,124,软件测试黑盒测试,已知软件产品应该具有的功能，通过测试来检测每个功能是否都能正常使用； 黑盒法着眼于程序外部结构，不考虑内部逻辑结构； 穷举输入/状态测试，测试情况有无穷多个； 依据需求规范； 检查程序实现的功能，是一种确认技术； 也称为功能测试或数据驱动测试。,125,软件测试输入/状态
43、空间,一些很普通的程序所包含的输入输出组合的数目都是非常惊人的，有些更是天文数字。例：读入三个数值，表示三角形的三条边，程序输出一条信息，说明该三角形是等边三角形、等腰三角形、不等边三角形。解：在限制坐标点取值为110的整数的情况下，3条直线有1041041041012种可能的输入，每秒测试1000条直线，需要1012/103109s，每年按3.1536107s计算，需要109/(3.1536107)=31.7年。注：考虑输入域之外/实数/更大范围,126,软件测试黑盒测试的不彻底性,不可能测试所有的输入 有效的输入 无效的输入 输入的编辑特性 输入时间的考虑 不可能测试多个输入的所有组合,1
44、27,软件测试黑盒测试常用方法,功能分解(function disassemble) 等价类划分(equivalence class partitioning) 边界值分析(boundary analysis) 组合逻辑测试(combinational logic testing) 基于状态转换的测试(state-based testing) 随机测试(random testing),128,软件测试方法使用,从原理上讲，功能(黑盒)测试能检测出所有错误，但要花费无限的时间。结构(白盒)测试基本上是有限的，但即使是全部执行也不能测试出全部的错误。某种程度上讲，测试的技巧就是在结构(白盒)测试与
45、功能(黑盒)测试之间如何进行选择。- Beizer,129,软件测试级别,单元测试 集成测试 确认测试 系统测试 验收测试,130,软件测试单元测试,特点: 关注程序的基本组成部分 若干个模块可以并行测试 发现错误后容易隔离和定位 规模和复杂性较低，可利用多种测试技术进行比较充分细致的测试 内容: 模块接口 局部数据结构 重要的执行路径 错误处理的路径 影响上述几点的边界条件,131,软件测试集成测试内容,单元间的接口测试 全局数据结构测试 性能测试 边界和人为条件下的性能 软件功能模块的功能测试,132,软件测试集成策略,非渐增式集成(大爆炸集成) 渐增式集成 自顶向下集成 深度优先方法 广
46、度优先方法 自底向上集成 高频集成(High-frequency Integration),133,软件测试系统级测试,软件确认测试 软件系统测试 验收测试 基准测试 小规模试验 用户测试 独立测试 Alpha和Beta测试 比较测试 符合性测试,134,软件测试系统级测试项目,功能测试 性能测试 强度测试 恢复测试 人机交互测试 本地化测试,配置和兼容性测试 可安装性测试 安全性测试 软件可靠性测试 用户文档测试,135,软件测试回归测试,原因： 超过60%的对软件系统的修改会无意中引入新的错误 每修改6行代码就会引入一个新的错误 内容： 检验修改是否达到了预期的目的； 检验是否损害了原有的正常功能，从而造成系统的回归。,136,软件测试实现过程,137,软件测试视觉隧道,138,软件测试测试组织,单元测试,集成测试,确认测试,系统测试,验收测试,开发人员 对等测试人员,独立测试小组,独立测试机构,SQA,139,软件测试缺陷跟踪,审阅,打开,分配,测试,关闭,拒绝,重新打开,暂缓,发现 缺陷,140,软件测试缺陷统计,141,软件测试回顾,软件测试的概念 软件测试方法 软件测试的级别 软件测试的实现过程和组织 缺陷管理的概念,142,课程小结,概述 软件计划管理 人员管理 软件配置管理 软件质量保证 软件审查 软件测试,
