第7章-软件维护与项目管理.ppt

第7章 软件维护与项目管理普通人轻视软件维护工作，会失掉极其宝贵的机会；维护人员轻视软件维护工作，会失掉本应精彩的人生；老板轻视软件维护工作，会丢掉大片本来属于自己的市场第7章 软件维护与项目管理7.1 软件维护7.2 软件再工程7.3 项目管理7.4 项目度量7.5 风险分析7.6 小结7.1 软件维护J7.1.1 软件维护概述J7.1.2 软件的可维护性J7.1.3 软件维护的实施37.1.1 软件维护概述J 软件维护-在软件交付使用后，根据需求变化或硬件环境变化对应用程序进行部分或全部修改。修改时要充分利用源程序，修改后要填写程序登记表，并在程序变更通知书上写明新旧程序的不同之处。J 维护的类型有四种：正确性维护 适应性维护 完善性维护 预防性维护4正确性维护（改正性维护）J 改正软件中存在的错误。占整个维护工作量的17%21%。J 在软件交付使用后，由于开发时测试得不彻底或不完全，在运行阶段会暴露一些开发时未能测试出来的错误。为了识别和纠正软件错误，改正软件性能上的缺陷，避免实施中的错误使用，应当进行的诊断和改正错误的过程，这就是改正性维护。5适应性维护（18%25%）J 在使用过程中，有以下变化：外部环境（新的硬、软件配置）数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）企业的外部市场环境、管理需求J 为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。J 要有计划、有步骤的进行。6完善性维护（50%60%）J 在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。J 为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。J 这种情况下进行的维护活动叫做扩充与完善性维护。7 预防性维护（4%左右）J 预防性维护是：为了改进软件可维护性、可靠性；为了适应未来软硬件环境变化；主动增加预防性的新功能，使得软件不因各种变化而被淘汰。8各种维护所占比例:其它维护 4%适应性维护18%25%改正性维护 17%21%扩充与完善性维护 50%60%9107.1.2 软件的可维护性J软件的维护十分困难，原因在于这些软件的文档不全、质量差、开发过程不注意采用好的方法，忽视程序设计风格等。J许多维护要求并不是因为程序中出错而提出，而是为适应环境变化或需求变化而提出的。J为了使得软件能够易于维护，必须考虑使软件具有可维护性可维护性。11一、软件可维护性的定义J 软件可维护性定义：软件能够被理解、校正、适应及增强功能的难易程度。J 软件可维护性可以用7个质量特性来衡量：可理解性，可测试性，可修改性，可靠性，可移植性，可使用性，效率127个特性在各类维护中的侧重点13二、可维护性的度量J 度量一个可维护性软件的七种特性常用方法：质量检查表：是用于测试程序中某些质量特性是否存在的一个问题清单。质量测试和质量标准：用于定量分析和评价程序的质量。由于许多质量特性是相互抵触的，要考虑几种不同的度量标准。14三、提高可维护性的方法（1）建立明确的软件质量目标和优先级J 相互捉进的特性：可理解性和可测试性；可理解性和可修改性。J 相互抵触的特性：效率和可移植性；效率和可修改性。J 各特性的相对重要性应随着程序的用途不同、计算环境的不同而不同。15提高可维护性的方法（续）（2）利用先进的软件开发技术和工具 面向对象软件开发方法软件系统稳定性好、易修改、易理解、易测试，可维护性好。（3）建立明确的质量保证 质量保证为提高软件质量所做的各种检查工作。非常有用的四类检查：在检查点进行检查、验收检查、周期性地维护检查、对软件包的检查。16提高可维护性的方法（续）（4）选择可维护的程序设计语言 低级语言：难掌握、难理解、难维护。高级语言：易理解、易掌握。第四代语言：更易理解、易编程、易修改、易维护。（5）改进程序的文档 程序文档对提高程序的可阅读性有重要意义。（6）开发软件时考虑到维护177.1.3 软件维护的实施一、软件维护的主要任务二、软件维护的阶段三、软件维护的主要问题18一、软件维护的主要任务：软件维护主要任务包括两点：1.维护组织机构J 对大型软件系统：建立专门的维护组织机构。J 对较小软件系统：委派专人负责软件维护工作。J 维护活动开始之前，必须明确维护活动的审批制度。审批制度如下页表：1.维护组织机构2.软件维护报告19维护审批制度系统管理员维护管理员维护申请主管部门202.软件维护报告J 用户填写维护申请单交给维护组织，经有关人员认真分析后，根据分析结果制定软件维护报告，主要包括以下内容：维护要求的性质 维护活动的优先顺序 计算满足维护申请表中提出的软件变更所需要的工作量 预计软件变更后的情况212.软件维护报告J 用标准化的格式表达所有软件维护申请（要求）。J 维护申请报告/软件问题报告，由申请维护的用户填写。J 用户必须完整地说明产生错误的情况，包括输入数据、错误清单以及其它有关材料。J 如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明书，列出所有希望的修改。222.软件维护报告J 维护申请报告将由维护管理员和系统管理员研究处理后，做出软件修改报告，指明：所需修改变动的性质；申请修改的优先级；为满足维护申请报告所需的工作量；预计修改后的状况。J 软件修改报告应提交给变化授权人/修改负责人），经批准后批准后才能开始进一步安排维护工作。23维护的技术工作J 不同类型的维护申请，都要进行同样的技术工作：修改软件需求说明 修改软件设计 设计评审 对源程序做必要的修改 单元测试 集成测试(回归测试)确认测试 软件配置评审等24维护完成后的总结J 每次软件维护任务完成后进行情况评审，对以下问题做总结：(1)在目前情况下，设计、编码、测试中的哪一方面可以改进?(2)哪些维护资源应该有但没有?(3)工作中主要的或次要的障碍是什么?(4)从维护申请的类型来看是否应当有预防性维护?J 情况评审对将来的维护工作如何进行会产生重要的影响。2526维护档案记录程序标识；源语句数；机器指令条数；使用的程序设计语言；程序安装的日期；自从安装以来程序运行的次数；自从安装以来程序失效的次数；程序变动的层次和标识；因程序变动而增加的源语句数；因程序变动而删除的源语句数；每个改动耗费的人时数；程序改动的日期；软件工程师的名字；维护要求表的标识；维护类型；维护开始和完成的日期；累计用于维护的人时数；与完成的维护相联系的纯效益。26二、软件维护6个阶段软件维护的准备和过度活动：维护计划的构思与创建，后续的产品配置管理。问题与修改分析阶段：维护人员分析每个请求，确认并验证其有效性，调查、提出、记录解决方案，获得软件修改的授权。实施修改阶段。接受修改阶段：由用户检查所做的修改是否解决了相应的问题。迁移阶段：软件被迁移到另一个平台。对软件某一部分的弃用。27 软件维护过程J 为了有效地进行软件维护，应事先就开始做组织工作：首先建立一个维护组织；申明提出维护申请报告的过程及评价的过程；为每一个维护申请规定标准的处理步骤；建立一个适用于维护活动的记录保管过程；规定复审标准。28三、结构化维护与非结构化维护差别巨大J 非结构化维护：只有程序代码，没有设计文档及测试文档，维护活动从艰苦地评价程序代码开始。需要付出很大代价，是没有使用良好的软件工程方法学开发出来的软件的必然结果。29三、结构化维护与非结构化维护差别巨大J 结构化维护：有一个完整的软件配置，维护工作从评价设计文档开始；估计改动将带来的影响，计划实施途径；修改设计文档，并且复审；编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试；把修改后的软件再次交付使用。30四、维护的代价高昂 J软件维护活动所花费的工作占整个生存期工作软件维护活动所花费的工作占整个生存期工作量的量的70%70%以上以上。J 软件维护代价极高，既破财，又伤神；有形代价：投入的人力物力。无形代价：影响更大。31维护的无形影响：J 可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机。J 改错或修改的不及时，引起的用户不满；J 由于维护时的改动，在软件中引入了潜伏的错误，从而降低了软件的质量；J 把软件开发人员抽调到维护工作中，干扰了软件开发工作。J 生产率的大幅度下降，尤其在维护旧程序时常常遇到。32五、影响维护工作量的因素J系统大小J程序设计语言：强功能，模块化，结构化J系统年龄：维护人员常换，文档缺少，文档与程序不一致J数据库技术的应用：J先进的软件开发技术：面向对象、复用技术J其它：应用类型，数学模型，任务难度，开关与标记、IF嵌套深度、索引或下标数等J许多软件在开发时并未考虑将来的修改，为软件的维护带来许多问题。33六、维护中的典型问题(1)难以跟踪软件版本的进化过程，软件的变化未在文档中反映出来。(2)难以读懂他人程序。(3)无文档或不全。(4)软件人员流动性大。(5)设计时未考虑修改需要,修改困难(6)维护工作无吸引力,缺乏成就感 采用软件工程方法至少可部分解决与维护有关的每一个问题。34七、文 档J文档文档是影响软件可维护性的决定因素。往往文档比程序代码更重要。J软件系统的文档可以分为两大类如下：用户文档：主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档：描述系统设计、实现和测试等各方面的内容。35用户文档J 用户文档主要包括：用户手册 操作手册 维护修改意见 软件需求规格说明书J 上述内容可以分别作为独立的文档，也可以作为一个文档的不同分册，具体做法应该由系统规模决定。36用户文档J 用户文档至少应该包括下述5方面的内容：(1)功能描述系统能做什么；(2)安装文档如何安装系统，配置硬件；(3)使用手册如何使用系统（例子），出错时如何恢复、重启系统；(4)参考手册详尽详尽描述所有系统设施的使用方法，解释可能产生的错误信息的含义；(5)操作员指南说明操作员如何处理系统使用中出现的各种问题。37开发文档J 开发文档 软件需求规格说明书 数据要求说明书 概要设计说明书 详细设计说明书 可行性研究报告 项目开发计划38管理文档J 管理文档 测试计划 测试报告 开发进度月报 开发总结报告39 系统文档J 系统文档：指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。J 描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。J 和用户文档类似，系统文档的结构也应该能把读者从对系统概貌的了解，引导到对系统每个方面每个特点的更形式化更具体的认识。40417.2 软件再工程再工程是一个重构活动（类比 重建一所房子）l 开始重建前，首先检查一下房子。确定它是否确实需要重建？l 在拆掉并重建房子前，确定其结构是否牢固。若结构良好，则可能是“改造”。l 开始重建前，确保已经了解房子最初是如何建造的。（墙内部，了解布线、管道以及内部结构。）l 如果开始重建，应该使用最现代的，耐久的材料。l 如果决定重建，一定要采用严格的方式，使用现在及将来都将获得高质量的做法。42软件再工程过程模型软件再工程是一类软件工程活动，是一个工程过程，它将逆向工程、重构和正向工程组合起来，将现存系统重新构造为新的形式。4344 软件再工程过程示意图 需求新需求设计 设计代码 代码正向工程逆向工程（重构）（重构）（重构）4445软件再工程过程模型的6类活动1.库存目录分析2.文档重构3.逆向工程4.代码重构5.数据重构6.正向工程451.库存目录分析 每个软件组织要保存所有应用系统的库存目录。它包含关于每个应用系统的基本信息：应用系统名字；最初构建日期；已做过的实质性修改次数和花费的总劳动；最好的一次实质性修改的日期和花费的劳动；它驻留的系统；和它有接口的应用；它访问的数据库；过去18个月报告的错误；用户数量；安装它的机器数量；程序结构、代码和文档的复杂性；文档的质量；整体可维护性等级；预期寿命；预期在未来36个月内修改次数；年度维护成本；年度运作成本；年度业务值；业务重要程度。461.库存目录分析（续）J 库存目录分析：分析哪些软件系统需要进行再工程过程。有3类程序：（1）预定将使用多年的程序；（2）当前正在成功地使用着的程序；（3）在最近的将来可能要做重大修改或增强的程序。472.文档重构老程序固有的特点是缺乏文档。处理方法：（1）如果一个程序是相对稳定的，正在走向终点，保持现状，不建文档。（2）只针对系统中当前正在修改的那些部分建立完整文档。随着时间流逝，将得到一组有用的和相关的文档。（3）如果某应用系统是完成业务工作的关键，而且必须重构全部文档，也设法把文档工作减少到必需的最小量。483.逆向工程J 软件的逆向工程：是分析程序以便在比源代码更高的抽象层次上创建出程序的某种表示的过程；J 逆向工程是一个恢复设计结果的过程；J 逆向工程工具从现存的程序代码中抽取有关数据、体系结构和处理过程的设计信息。494.代码重构J 某些老程序具有比较完整、合理的体系结构，但是，个体模块的编码方式却是难于理解、测试和维护的，可进行代码重构。J 重构过程：分析源代码 标注需重构部分 重构 复审、测试 更新文档。J 重构并不修改不修改整体的程序体系结构程序体系结构，它仅关注个体模块的设计细节以及在模块中定义的局部数据结构。J 如果重构扩展到模块边界之外，并涉及软件体系结构，则重构变成了正向工程。505.数据重构J 对数据体系结构差的程序很难进行适应性修改和增强；J 数据体系结构比源代码本身对程序的长期生存力有更大影响；J 由于数据体系结构对程序体系结构程序体系结构及算法算法有很大影响，对数据的修改必然会导致体系结构或代码层的改变。J 当数据结构较差时，应该对数据进行再工程。516.正向工程J 正向工程也称为革新或改造；J 不仅从现有程序中恢复设计信息，而且使用该信息去改变改变或重构现有系统重构现有系统，以提高其整体质量。J 被再工程的软件不仅重新实现现有系统的功能，而且加入加入了新功能新功能和提高了整体性能提高了整体性能。527.2.2 逆向工程J 逆向工程：是对产品设计过程的一种描述。J 逆向工程产品设计：根据已经存在的产品，反向推出产品设计数据的过程。53将要再工程的系统自动分析手工加注释系统信息库文档生成数据结构图程序结构图可追溯矩阵 逆向工程过程54逆向工程的工具源程序目标代码 源程序概要设计详细设计概要设计需求分析J 反汇编、反编译J 程序分析技术：程序结构分析工具，程序功能分析工具55(1)实现级:程序的抽象语法树、符号表等信息；(2)结构级:反映程序分量之间相互依赖关系的信息，如调用图、结构图等；(3)功能级:反映程序段功能和段间关系的信息；(4)领域级:反映程序分量与应用领域概念间对应关系的信息；抽象级别低高信息的抽象级别越高,它与代码距离越远,通过逆向工程恢复的难度越大,自动工具支持的可能性变小逆向工程恢复信息的级别:56数据的逆向工程J 数据逆向工程的层次：程序层：某一程序内部数据结构必须被逆向工程。系统层：全局数据结构经常被再工程。57用户界面的逆向工程J 用户界面的重新开发J 要注意问题：系统界面的主要功能 用户的使用方式587.2.3 重构J 在不改变软件现有功能的基础上，通过调整程序代码改善软件质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。J 重构：并不修改整体的程序体系结构，更关注个体模块的设计细节以及定义模块中的局部数据结构。59J 代码重构：对程序代码做一些更改，目的是增加可读性，或者简化代码结构，从而使得代码容易维护。不修正错误，不增加新的功能。J 数据重构：分析所有包含数据定义、文件描述、I/O 以及接口描述的程序语句，目的是抽取数据项和数据对象，获取关于数据流的信息，理解现存的已经实现的数据结构。607.3 项目管理J 项目管理定义：是指为了实现项目目标，利用各种有效手段，对执行中的项目周期的各阶段工作进行计划、组织、协调、指挥、控制，以取得良好经济效益的各项活动的综合。J 项目管理要求在项目活动中运用知识、技能、工具和技术，以便达到项目目标的活动。是为了确保项目能够达到期望的结果的一系列管理行为。61软件项目管理的定义J 软件项目管理：为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。J 软件项目管理的特点：软件是纯知识产品，开发进度和质量很难估计、度量，生产效率难以预测和保证。开发周期长，复杂度高，变数多。软件需求要满足一群人的期望。627.3.2 项目管理的对象J 项目管理的5个要素：技术Technology；方法Methodology；团队建设Team Building；信息Information；沟通Communication：技术沟通，管理沟通，质量沟通。63有效项目管理的三个因素：J 有效项目管理集中于三个因素：人员People：人员管理能力成熟度模型PM-CMM通过吸引、培养、鼓励和留住改善其软件开发能力所需的人才增强软件组织承担日益复杂的应用程序开发的能力。问题Problem：明确项目目的和范围，考虑可选的解决方案，定义技术和管理的约束。过程Process：软件过程提供一个框架，用于建立一个软件开发的综合计划。647.3 项目管理1.你开发中按软件工程做了吗？J 一些程序员抱怨说：我加班加点写了10万行代码，所以老板把我给开除了。“J 关键代码有多少？10万行代码的维护问题？J 假设你到一个公司，老板首先要求你看完10万行代码。你会怎么办？J 对于一个没有按软件工程来开发的程序，读起来也是很难受的事。所以得好好按规定软件工程办事。65你是先写文档再写程序的吗？J 一个好的程序是先写好设计文档再进行编程，在设计文档指导下，才能写出安全的代码。J 对于小程序，文档可以很不正规。J 对于大程序，必须正规写文档，详细记下你的设计思想。如果要对一些功能进行修改时，记住别删除原来的，而是在下面进行变更说明。J 可是在一些小公司，先写文档后写程序的开发员又有多少。要成为一个好的程序员大家想想自己该怎么做的吧！66软件项目管理问题J1.现代的软件开发，技术不是关键 J 目前开发软件系统要求团队合作才能完成。J 管理才是开发出好的软件的前提，没有管理一定出不来好软件，当然有管理也不一定出软件。67要注重整体，而非个体J 用户要求去在三个月内完成软件开发，在系统分析时你也认为3个月可以完成。在详细设计时遇到建立一个不太大的路由表问题。J 大多数国内设计人员就会想用什么算法，花很多时间去设计研究新的算法和技术。把个体放在首位J 印度程序员首先考虑系统运行环境，假设这个软件是在(CPU：1.1G，内存：512M)中运行，用户也没特意提出运行效率要求。所以人家就在内存中开一个大数组来对这个路由表进行操作。注重的是软件的整体。68要注重整体，而非个体（续）J 如果花太多时间在技术上去，将对系统的按时完成带来影响。J 不是说不该研究技术，只是说开发中应当以全局为重。J 如果要加入新的技术，必须在分析时就预算其所需要的时间，并设置技术风险管理。如果风险太大就应当取消用这项技术，改用其它的已成功的技术代替。J 风险管理这是近来才提出的软件管理方法。它对我们的软件项目有着很好的控制作用。69错误管理 J 典型的软件开发项目可能会给我们提供很多的机会去从错误中吸取经验教训。J 一般软件项目也会提供少量的错误给我们学习。J 汽车教练经常对学员说：“我希望你们从我身上学习我和前人的经验，这些经验你们就不要再去试了。如果要试你也许会赔上钱甚至于生命”。J 虽然软件项目开发不会赔上生命，但是失败的软件项目是一定会赔钱的。J 所以在软件开发中少不了要对错误进行管理。70错误管理A.列出典型错误J 人员方面的典型错误：对有问题的员工失控、挫伤积极性、人员素质低、英雄主义、项目后期加入人员、开发人员与客户之间发生摩擦、不现实的预期、缺乏有效的项目支持、缺乏各种角色的齐心协力、政治高于物质、充满想像等J 过程方面的典型错误：过于乐观的计划、缺乏足够的风险管理、缺乏计划、在压力下放弃计划、在模糊的项目前期浪费时间、前期活动不合要求、缺少管理控制、缺少质量保证措施、鲁莽编码等J 技术方面的典型错误：过高估计新技术或方法带来的节省量、项目中间切换工具、缺乏自动的源代码控制手段等71错误管理B.列出自己的最差实践J 注意典型错误，建立自己的最差实践列表，可以避免在以后的项目中犯同样错误。72错误管理C.列出项目中的最差实践J 组织机构和其他项目组总结经验，学习他们的错误中得到的经验。和其他组同事交流项目开发中的磨难，学习他们的经验。列出潜在的错误，看到它我们就会尽量避免今后犯同样的错误。73J 典型错误好比学车时教练讲的经验；J 自己的最差实践好比我们在实际开车当中出的问题J 项目中的最差实践好比我们学车前的笔试的书。J 对公司来讲，系统分析中的经验提供给系统分析员；设计人员中的经验提供给管理人员；技术中的经验提供给开发员。74风险管理J 软件项目所面临的不断变换的用户需求、糟糕的计划与估算、不可信赖的承包人、欠缺的管理经验、人员问题、伤筋动骨的技术失败、性能欠佳.等等不胜枚举的风险，使大型项目按时完成的概率几乎为0。J 所以项目开发中对风险进行控制管理就大大提高了软件开发的成功性。J 软件风险管理工作就是在风险成为影响软件项目成功的威胁之前，识别、着手处理并消除风险的源头。75管理风险的层次1.危机管理-救火模式，就是在风险已经造成麻烦后才着手处理它们。2.失败处理-察觉到了风险并迅速做出反应，但只是在风险发生之后。3.风险缓解-事先制定好风险发生后的补救措施，但不做任何防范措施。4.着力预防-将风险识别与风险防范作为软件项目的一部分加以规划和执行。5.消灭根源-识别和消除可能产生风险的根源。J 前三项被动进行，亡羊补牢为时已晚。应当着力于预防风险，更好的是消除风险根源。76风险管理由风险评估和风险控制J 风险评估：由风险识别、风险分析和风险优先级组成。1.风险识别：就是提出一个潜在破坏项目进度的风险列表，就像生成错误列表一样。2.风险分析：评估每一个风险出现的可能性及其影响，判定风险的级别。3.风险优先级：按风险影响大小排出一个风险优先级，这个风险列表将作为风险控制的基础。77风险管理由风险评估和风险控制J 风险控制由风险管理计划，风险化解和风险监控组成。1.风险管理计划：制定一个应对每个重要风险的方案，同时确保每一个单独的风险管理计划之间以及与整体项目计划之间相一致。2.风险化解：每个重要风险所对应计划的执行。3.风险监控：就是对解决风险的过程进行监控，风险监控还可以包括识别新的风险并将其反馈到正在进行的风险管理进程中等方面的工作。78人员管理 J 人力因素极大地影响着生产效率，同时任何关注提高生产效率的组织首先必须有一套良好的人员绩效、薪酬、培训等的机制。J 团队建设、企业文化建设等。J 管理模式没有绝对的好与坏，适合组织本身并能产生最高效的模式就是最好的。J 如果把软件工程比做音乐家，那项目管理就是音乐指挥家。J 有好的程序员只是前提条件，要开发出好的软件，还要有一个好的管理。79807.4 项目度量J7.4.1 软件度量J7.4.2 质量度量J7.4.3 集成度量817.4.1 软件度量J 软件度量：针对软件开发项目、过程及产品进行数据定义、收集、分析的持续性定量化的过程。J 软件度量包括两大部分：度量：基于一定目的，采用一定方法或标准，对目标事物进行观察，得到客观评价结果，以量化管理定义项目过程，完成项目已建立的质量和过程性能目标。分析：采用一系列数学函数，对数据进行处理，发现问题并确定过程的发展趋势。82软件度量的目的J理解通过搜集软件过程和项目数据，以了解软件开发过程及状态。J评价评定软件产品或开发活动是否符合规定的准则和条件。J控制根据获得的数据，控制软件开发过程中的关键活动。J预测根据数据分析结果，预测软件开发效率或趋势，并给出建议措施。J改进根据度量信息，确定改进软件的机会。83软件度量要遵循的方针J 根据信息需要和目标，建立预测目标并维护。J 软件度量方法只是手段，不是目的。J 不能单纯收集数据，要应用度量结果去解决问题。J 规定度量元去处理度量目标。但度量数据本身也存在瑕疵，不精确，不稳定。J 说明如何获得并存储数据，让软件开发者参与软件度量活动。J 规定如何对度量数据进行分析、报告，安排优先顺序。J 提供度量结果，以便处理信息需要和目标。J 将某些特殊知识存储到经验数据库中。84度量元J 度量元软件度量的内容描述。分为：基本度量元：数据可以直接度量获得。派生度量元：数据不能直接获得，通常有两个或多个基本度量组合而成。85建议使用的基本度量元：J 进度性能度量元（里程碑进展、工作包完成情况等）。J 成本性能度量元（实际与计划的对照，用于衡量成本的不一致情况）。J 工作量性能度量元（人时数，人月数实际与计划的对照，用来衡量工作量的不一致情况）。J 需求管理度量元（需求追踪矩阵中增加的、删除的、修改的需求数量，衡量需求易变性）。J 程序规模度量元（源码行数、页数，实际与计划的对照）。86建议使用的基本度量元：J 测试性能度量元（需要执行的测试用例数、已经执行通过的测试用例数）。J 度量度量元（未解决的问题、解决完成的问题、缺陷数、严重缺陷数、缺陷密度、缺陷来源）。J 过程性能度量元（完成的任务，行动项数）。J 计算机资源利用情况度量元（内存占有量、CPU 占有量）。J 管理计划项目过程的性能度量元（对照实际进展做估计、重计划、项目总结数据）。87可能使用的派生度量元：J 挣值（Earned Value，EV）。J 进度性能指标（SPI）。J 缺陷密度，发现的缺陷数目与规模的比值。J 同行评审覆盖率。J 测试或验证覆盖率。J 可靠性度量，如平均故障间隔时间。J 质量度量，如严重缺陷数/总缺陷数等。88三、度量模型J 度量模型：是指关于要度量哪些度量元的需求规格说明。通过生命周期、直接度量元或间接度量元3个方面来描述。（1）在生命周期各阶段，要用到和度量哪些度量元？他们与企业的商业目标有什么联系？（2）其中哪些是直接度量元？有谁度量？是否可以采用工具来度量？（3）其中哪些是间接度量元？如何由直接度量导出？897.4.2 质量度量J 软件产品质量度量的对象软件产品。J 软件产品质量度量包括软件复杂度，客户满意度的度量。主要集中于软件缺陷的度量，和软件测试有直接关系。J 软件质量测量的主要属性有：正确性 可维护性 完整性 可用性90正确性J 一个程序必须能够正确运行并完成相应功能。J 正确性是指：软件完成所需功能的程度。J 正确性的测量：常用每千行的缺陷数表示。J 此处的缺陷是指：验证出的与需求不符的地方。91正确性度量J 基于缺陷分析的产品质量的评估方法：缺陷密度软件缺陷在规模上的分布。缺陷率缺陷在时间上的分布。整体缺陷清除率。阶段性缺陷清除率。缺陷趋势、预期缺陷发现率。软件产品性能评估技术。借助工具的其他方法。92可维护性J 可维护性是指：遇到错误时程序能被修改的容易程度；环境发生变化时程序能够适应的容易程度；用户希望改变需求时程序能被增强的容易程度。J 可维护性必须间接测量。常用测量方法是：平均修改时间即设计合适的修改方案、实现修改，并将修改结果发布给用户所花的时间。93完整性J 完整性测量软件系统在安全方面的抗攻击（包括偶然的和蓄意的攻击）能力。J 攻击可能针对程序、数据、文档三个方面。完整性=1-威胁*（1-安全性）J 威胁：某个特定类型的攻击在给定时间内发生的可能性。J 安全性：某个特定类型的攻击将被击退的可能性。94可用性J 可用性是对一个软件系统是否满足“用户友好性”的量化。根据4个特性来测量：学会一个系统需要的体力和智力投入。使用软件系统达到中等效率所需要的时间。当系统由某个具有中等效率的人使用时，测量到的生产率的净增长（与被该系统替代的老系统相比）。用户对系统的态度的一个主观评估（有时可以通过调查表获得）。957.5 风险分析J 风险分析是贯穿于软件工程过程的一系列风险管理步骤，包括：风险识别，风险估计，风险管理策略，风险解决和风险监督等。967.5 风险分析J 风险分析是：找出行动方案的不确定性（主观上无法控制）因素，分析其环境状况和对方案的敏感程度；估计有关数据，包括行动方案的费用，在不同情况下得到的收益以及不确定因素等各种机遇的概率，计算各种风险情况下的经济效果；做出正确判断。97进行风险分析要考虑的因素：J 产品大小：项目风险和产品大小成正比。J 技术相关：使用新技术存在风险。技术过时也是风险。技术风险一般难以改正。J 开发环境：使用的开发工具不完善、不可靠、使用不方便等，都会降低开发效率。J 组织规模和人员经验。J 客观因素：例如：客户需求自相矛盾；不了解客户的特殊需求；客户不了解项目采用的新技术；双方难于沟通等。98风险管理J 风险管理：是在危机还没有发生前就对它进行处理，提高项目成功的机会，减少必可避免的风险产生的后果。J 主动的风险管理策略：在没有出现危机前，识别风险，评估风险出现的概率，以及它们的影响程度，事先预防风险，尽量消灭出现危机的根源。J 被动的风险管理策略：对风险没有规划，直到发生了错误才采取补救措施，也称救火模式。补救失败后，项目就处于真正的危机中了。99风险识别J 风险识别：试图系统化的确定对项目计划的威胁，识别已知和可预测的风险，在必要时控制这些风险。贯穿于整个项目过程中。J 风险识别包括：识别风险的来源，确定风险产生的条件，描述风险特征，确定哪些风险可能影响本项目。J 一般性风险：对每个软件项目都是一个潜在威胁。J 特定性风险：需要掌握特定技术的人员才能识别出来。100风险识别的常用方法JDelphi 方法专家调查法J 头脑风暴法J 情景分析法J 风险条目检查表101风险评估J 风险评估：对识别出来的风险事件做进一步分析，对风险发生的概率进行估计和评价，对风险的严重程度进行估计和评价，对风险影响范围进行分析评价，对风险发生事件进行估计和评价。102风险评估的方法J 定性风险评估：针对风险概率及后果进行定性评估。可以采取小中取大原则、大中取消原则、遗憾原则、最大数序期望原则、最大可能原则等。J 定量风险分析：在定性分析的逻辑基础上，给出各个风险源的风险量化指标及其发生概率，再通过一定的方法合成，得到系统风险的量化值。103