还剩48页未读,继续阅读
本资源只提供10页预览,全部文档请下载后查看!喜欢就下载吧,查找使用更方便
文本内容:
第一讲项目管理概述
1.1人类有组织的活动逐步分化为两种类型:作业连续不断、周而复始的活动项目暂时性的、一次性的活动项目是未完成某一独特产品或服务所做的一次性努力项目的特性临时性、独特性、逐步完善性项目与作业的区别项目独一无
二、有限时间、革命性改变、状态的不平衡、目标之间不均衡、多变的资源需求、柔性的组织、效果性、风险和不确定性、以达到目标为宗旨;作业重复的、无限时间、渐进性的改变、平衡、均衡、稳定的资源要求、稳定的组织、效率性、经验性、已完成任务为宗旨
1.2项目的重要性—项目的价值,项目是实现价值、成就事业的载体
1.
2.1项目与项目管理的价值国家、企业和个人来说项目是发展基本元素,项目是进步和成长的主要载体项目管理将相关的知识、技术、工具、技能、等应用于项目任务,以满足项目干系人对项目的需求和期望的过程
1.3什么是项目管理?PMI对项目管理的定义为把各种知识、技能、手段和技术应用于项目活动之中,以达到项目的要求通过应用和综合诸如启动、规划、实施、监控和收尾等项目管理过程来进行项目经理是负责实现项目目标的个人PMRC对项目管理的定义为以项目为对象的系统管理方法通过一个临时性的专门的柔性组织,对项目进行高效率的计划、组织、指导和控制,以实现项目全过程的动态管理和项目目标的综合协调与优化
1.
3.1项目管理的特点
(1)管理对象是项目或被当作项目来处理的运作
(2)全过程贯穿着系统工程的思想
(3)组织具有特殊性
(4)体制是一种基于团队管理的个人负责制
(5)项目管理的方式是目标管理
(6)要点是创造和保持一种使项目能顺利进行的环境
(7)项目管理的方法和手段具有先进性、开放性项目的三重制约时间、成本、范围
1.
3.3项目管理的价值许多跨国公司的经验表明,企业的成功在于有效地推行项目管理项目管理是一种有效地知识积累方式,也是进行知识管理的有效途径越来越多的企业引入项目管理,把它作为主要的运作模式和提高企业运作效率的解决方案
1.
3.4项目管理的生命周期项目管理阶段项目启动阶段、项目计划阶段、项目实施阶段、项目监控阶段、项目收尾阶段
1.4项目管理知识体系项目管理已成为一种管理技术和科学,针对各种类型项目的共同之处,建立了项目管理知识体系目前主要存在三大项目管理研究体系
(1)美国项目管理协会—PMI的PMBOK美国项目管理协会(PMI)创建于1969年,PMI在推进项目管理知识和实践的普及中扮演了重要角色PMBOKProjectManagementBodyofKnowledge是PMI开发的项目管理知识体系,国际标准化组织以该文件为框架,制定了ISO10006项目管理标准PMI在1987年公布了第一个PMBOK,并在广泛地讨论和征求意见的基础上,分别于1991年、1996年、2000年和2004年进行了修订2004的PMBOK把项目管理划分为9个知识领域和44个管理过程;9个知识领域包括:4个核心知识领域,其中定义了17个过程4个辅助知识领域,其中定义了20个过程1个项目综合管理,其中定义了7个整体管理过程
(2)国际项目管理协会IPMA的国际项目管理知识体系(ICB)国际项目管理协会IPMA1965年在瑞士注册成立,其成员主要代表各个国家的项目管理研究组织,最初多为欧洲国家,现已扩展到世界各大洲IPMA是一个非盈利性组织,它的职能是成为项目管理国际化的主要促进者到目前为止共有英国、法国、德国、俄罗斯、中国等30多个国家的项目管理专业组织成为其成员组织ICB项目管理与个人能力IPMA99年正式推出了国际项目管理知识体系(IPMACompetencyBaseline,ICB)ICB把个人能力划分为42个要素,其中:28个核心要素,14个附加要素,关于个人素质的8大特征和总体印象的10个方面,
(3)中国的PMRCC-PMBOKPMRC发布的IT信息化项目管理知识体系(iPMBOK)将信息技术与信息化综合起来视为一体,用IT信息化来综合描述信息技术与信息化,与此对应的项目称为IT信息化项目人们还习惯于将以计算机为主体的各种项目称之为IT项目利用有限资源、在一定的时间内,完成满足一系列特定的IT信息化目标的多项相关工作叫做IT项目iPMBOK的IT项目管理定义IT项目管理就是把各种知识、技能、手段和技术应用于IT项目活动之中,以达到IT项目的要求IT项目管理是通过应用和综合诸如启动、规划、实施、监控和收尾等IT项目管理过程来进行的项目经理是负责实现IT项目目标的个人iPMBOK提出的IT项目特征:IT项目除了具有其一般项目所具有的独特性、一次性、整体性、临时性、不确定性、资源多变性、有一个主要发起人等特征外,还具有明显的如下特殊性1)目标的不确定性2)需求的不稳定性3)费用的不可控性4)项目的时限性5)对智力的依赖性6)项目评价的主观性7)项目的创新性iPMBOK2004的IT项目管理知识体系2004年PMRC正式发布了《iPMBOK2004:IT信息化项目管理知识体系与国际项目管理专业资质认证标准》iPMBOK2004采用三维结构模型,包括:面向项目管理职能的职能型iPMBOK面向项目管理过程的流程型iPMBOK面向项目管理对象的离散型iPMBOKiPMBOK2004采用三维结构模型九大知识领域与项目管理阶段综合管理、范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理
1.7软件与软件项目在20世纪中叶,软件伴随着第一台数字电子计算机埃尼亚克的问世而诞生,以编写软件为职业的软件人开始出现软件以计算机为载体,软件的发展以计算机的发展为基础,同时,软件是计算机系统的核心和灵魂,软件的发展又有力的推进了计算机硬件的发展软件项目属于IT项目范畴,软件项目是以软件为产品的项目,其核心是软件软件的开发和应用通过软件项目来实现
1.
7.1软件的定义20世纪60年代,美国的大学开始设立计算机专业,教学生如何编写程序软件对人类来说是一个全新的领域,其发展历史只有短短的几十年,但其发展速度和对人类社会发展的影响都是空前的软件已从个性化的程序变为工程化的产品,人们已经认识到把软件这一术语等同于计算机程序是很狭隘的一个软件系统通常包括在计算机运行中能够提供所希望的功能和性能的程序使程序能够正确运行的数据结构和数据描述系统结构的系统文档和如何使用与维护该系统的用户文档软件(software)是计算机系统中与硬件hardware相互依存的另一部分,它是程序program、数据data和文档document的完整集合
1.
7.3软件的特点:软件产品的抽象性软件生产过程的特殊性软件缺陷检测的困难性软件维护的复杂性软件对环境的依赖性软件开发方式与软件发展的不对称性系统开销的主导性与社会因素的关联性
1.
7.4软件项目的分类与特点利用有限资源、在一定的时间内,完成满足一系列以软件为核心的多项相关工作叫做软件项目软件项目的最终成果是软件产品,软件产品与其他任产品的最大区别是无形和没有物理属性,其特点体现在1)高度复杂性2)智力密集、可见性差3)单件生产、过程不规范4)劳动密集、自动化程度低5)开发工作渗透了人的因素6)开发方法多样性
1.8走进软件项目管理软件项目管理属于IT管理范畴,它是IT项目管理的一个核心部分,其管理的对象是软件项目20世纪70年代中期美国提出的软件项目管理,引起人们的关注
1.
8.2软件项目管理的重点人员的组织与管理软件度量软件项目计划风险管理软件质量保证软件过程能力评估软件配置管理
2.
11.项目启动阶段的知识结构启动阶段的任务:立项、组建项目组、方案设计与项目可行性报告、项目开工会输出:项目可行性报告项目策划需求问题、可选的技术解决方案、方案评价与选择、里程碑、风险分析(项目风险水平定性分析表、子项目风险情况一览表)、项目质量保证说明书项目章程含项目成员表
2.
1.启动阶段的任务立项立项是项目前期工作的一个重要环节,可行性研究是它的重要工作内容可行性研究的内容是对拟实行项目作详细的技术、经济分析,提出若干方案并进行比较,从而对项目的合理性作出结论通过该过程储备一些可供选择的项目,使项目投资的基础工作超前;或取消一些不合理、不可行项目,避免或减少投资决策失误
2.
1.1可行性研究的主要内容旧系统描述(旧系统流程、费用开支、使用人员、主要问题和缺陷)新系统概述(实现的功能、对旧系统的主要改进之处、开发需要的条件)经济可行性(投入初始投资概要、运营费用概要收益预测直接经济收益、间接收益(效率提高、客户满意度、企业/组织形象提升等等)、经济可行性结论行/否)技术可行性(新系统的技术要求、现有技术能否达到要求、技术可行性结论行/否)社会环境可行性(法律、政策、管理环境、文化环境(技术普及程度、用户的工作与生活习惯)、社会环境可行性结论行/否)可行性结论(立即开发、等待某些条件成熟后再开发、不开发)
2.
2.组建项目组为项目建一个团队,配置合理、团结一心的团队是项目成功的保障要求合建一个合理项目组,有明确的分工,清晰的组织分解结构OBSOrganizationalBreakdownStructure寻找合适的人选,了解他们在技术、管理方面的优劣争取领导和职能部分的支持结果一个项目成员表
2.
2.1项目组的一般结构赞助人、项目经理、核心团队、外围团队赞助人的职责项目赞助人通常对项目提供资金和支持职责,包括,挑选和任命项目经理,批准项目核心成员的组成;提供资金和审批重大财务事项;监控项目组执行情况;项目经理的求助对象项目经理的职责项目经理直接对项目赞助人负责,保证项目成功的实施包括,与赞助人协商,就项目目标和所需的资源达成共识;挑选核心成员,并取得他们的支持;在项目的进程中不断了解客户的需求;在项目计划过程中领导及指导小组成员;保证与项目干系人的沟通并汇报项目的进程;监控项目的进程,保证项目按时间计划执行项目成员的责任项目核心成员对项目经理负责,保证项目的完成,包括,参与项目的计划制定;服从项目经理的指挥,执行计划分配的任务;配合其他小组成员工作;保持与项目经理沟通
2.
2.5软件项目组的其它角色产品经理,作为业主的代表,全程参与项目开发,负责确定软件功能需求,回答开发团队对需求的疑问系统分析师架构师用户界面设计师程序员测试工程师培训与实施工程师…
2.
3.项目策划/任务书项目策划/项目任务书的基本要素项目内容描述项目里程碑项目评价标准假定约束条件项目利益干系人结果一个项目成员表
2.
3.1定义里程碑里程碑划分项目阶段一期,二期…一期,第一阶段,第二阶段,…项目进展阶段的标志性成果
2.
3.2确定项目评价标准对项目组承接单位执行能力进行评价对项目阶段性成果进行评价对项目组承接单位执行能力进行评价对项目阶段性成果进行评价
2.
4.1确定项目评价标准假设说明项目的假设条件约束条件说明项目启动和实施过程中的限制性条件项目的风险分析成本因素
2.
4.1确定项目评价标准--项目的风险分析整体各阶段的风险分析分析、设计、实现、测试、运行风险因素费用、工期、质量、组织、技术自然、行为、经济、政治、组织对因素进行加权计算动态地进行项目风险评估和排解
2.5启动阶段TOP3启动阶段关键点
1.与客户、SPONSOR、高层的沟通,明确需求及获得相关支持
2.明确项目目标和定位
3.开工会、统一思想、明确团队运作制度启动阶段常见问题
1.需求不明确及需求沟通不够
2.项目组成员选择不合理
3.为促成项目,过于乐观地分析项目可行性第三讲Scrum重点!Scrum是英语中橄榄球运动的一个专业术语,表示“争球”特指一种敏捷开发的模型敏捷开发是一种从90年代开始逐渐引起广泛关注的一些新型软件开发方法非敏捷开发方式是瀑布式开发,瀑布模型的主要缺陷是程序的维护成本会越来越高(需要很多人)团队氛围压抑(感受不到激情)不方便做需求变更(引起客户不满)Sprint计划会议计划会议要有足够的时间,最好至少8个小时取出部分产品需求做成sprint需求,并写成索引卡确定并细分每一个索引卡的故事(Story)进行工作认领(不是分配)确定每日站立会议的时间和地点确定好演示会议和回顾会议的日期站立会议10-15分钟迟到将接受惩罚自问自答三个问题昨天做了什么今天要做什么遇到了什么问题更新燃尽图Sprint开发周期使用好任务看板需求,设计,开发,测试,维护注意燃尽图不要使用软件取代看板可以选择性的和XP的某些方式结合演示会议演示是跨团队的,会产生不同团队之间的交流不要关注太多的细节,以主要的功能为主让老板和客户看到非常的重要,绝对不可以被忽略回顾会议时间在1-3个小时找最舒适的地方(要有回顾看板)开始的时候轮流发言,而不是主动发言记录问题,总结,并讨论改进的方法,放在回顾看板上每人三个磁铁,将最重要的2-3个改进点,成为下一轮的产品需求Scrum的主要缺陷压力大不方便跨时区,跨语言程序维护成本偏高无法被中断如何改善Scrum结合XP和客户坐在一起结对编程测试驱动开发(TDD)使用编码规范32小时工作制第4讲IT项目计划阶段
1.2项目计划阶段的知识结构计划阶段的任务分解项目工作设定活动排序估算资源、工期、成本作出风险计划、沟通计划项目计划输出WBS网络图/甘特图进度计划风险计划沟通计划计划阶段的工具、方法、模板活动排序网络图工期估算三点估算法、专家判断法成本估算法自下而上法、专家判断法、类别估算法、参数成本法进度计划甘特图、里程碑图、关键路径法模板WBS进度计划表,风险管理表,沟通计划表工作分解结构(WorkBreakdownStructure)一种面向可交付成果的项目元素分组,它自顶向下,定义了全部的项目工作范围每下降一级,都表示一个更详细的项目工作定义分解到可预测、可管理的单个活动,对工作项和工作结构进行验证和评审,工作分解结构是项目范围说明书规定的工作没有包含在WBS里的工作是不应该做的
2.
1.1工作分解的原则百分百分解原则完全穷尽,彼此独立,子层集合等于父层包括的所有工作分解到最底层(工作包)是最小的控制单元,包含所有具体工作活动,一个清晰的任务,一个清晰的责任人,能够估算工作量和工期,通常活动的长度应小于两周80小时,清楚地描述项目的逻辑范围,并得到各方的认可
2.
1.1工作分解的方法纵向分解以交付产品物理/逻辑结构进行划分物理产品,以产品结构为基础进行划分软件产品,以外部功能项、结构组件等为基础进行划分中间输出或可交付的成果横向分解横跨产品所有内容的分解如设计,测试、安装、培训、文档、风险管理等它们通常是技术性,或支持性的识别项目中的其它工作领域,确保覆盖100%的工作
2.
1.1工作分解方法与结构分解方法自上而下法、头脑风暴法表达方式图形式、目录式图形式分解举例按项目的主要姐夫结果分、按职能分、按产品本身结构分、按项目实施顺序分
2.
1.4对工作项和工作结构进行验证和评审需求验证四步骤审查需求文档依据需求文档编写测试用例编写用户手册由用户认可确定产品验收合格的标准由用户认可需求验证九内容有效性检查由用户认可完备性检查是否包含用户需求的所有内容,包括所有状态〈一般状态、特殊状态〉,相关约束条件由用户认可一致性检查需求是否存在冲突、重复现实可行性可检验性可跟踪性可调节性检查对变更的适应性可读性客户和用户是否可读懂
2.2项目计划阶段的任务排序方法按工作的客观规律排序,将项目目标要求排序,按轻重缓急排序根据项目本身的内在依赖关系排序技巧只用工作分解结构WBS的最低层项首先把最相关的项排好建一个子网,再合并所有子网先不要考虑资源、日期或工期工具前导图法PDM用一个方块表示一个工作项,用箭头表示先后关系,连接各个方块,所有工作形成一个有向图
2.3资源、工期和成本估算资源类型人员,物资,技术资源估算要素各个项目成员需要什么资源什么时候需要,需要多少?谁决定资源的分配?估算方法专家判断法什么是工期估算根据项目范围和资源的相关信息,确定估算完成所有活动所需要的工期估算方法三点估算法采用a乐观、c悲观、b最可能的三点工期估算法计算平均值、标准差值确定工期的方法工期=a+4b+c/6专家判断法由项目经理组织1~3名团队成员对任务消耗的工期进行估算,并确定项目日程关键提示任务的工期估算要以“谁来做”和“如何做”为基础
2.
3.3成本估算估算信息来源历史项目、任务执行者、专业评估人员、专业权威估算方法自下而上估算方法估算最详细的计划活动费用,然后汇总到更高层级专家判断法类比估算法利用历史信息和专家判断,只有当满足以下条件时比较可靠(先前的项目与当前项目类似、做估算的个人或小组具有必要的经验)参数成本估算法如确定项目成本与计算机程序代码行数的关系
2.4进度计划进度计划根据WBS、活动排序、工期估算和所需要资源的结果进行分析、制定出项目进度计划进度制定的工具
(1)关键路径法关键路径工期总和最长的一条路径是完成该项目的需要的最短时间,其中的每一项任务都是关键任务,关键任务的延迟会导致项目或阶段延迟
(2)甘特图
2.
5.1风险计划识别风险风险级别
(1)项目级风险环境风险、金融风险、法律风险、项目方案总体规划风险
(2)模块级风险项目管理风险、工程分包风险、配套采购风险评估风险考虑风险发生的可能性高发生可能性大于60%中发生可能性30%~60%低发生可能性小于30%风险对项目的影响高影响项目成败中对项目成本、工期、或质量有较大影响低对项目成本、工期、或质量影响较小制定风险响应计划对风险的基本处理方法规避Avoidance:改变项目计划,以排除风险或改变条件,使项目不受其影响转移Transfer设法将风险的后果连同应对责任转移到第三方减轻Mitigation设法把不利的风险事件的发生概率或后果降低到可以接受的临界值接受Acceptance主动接受、被动接受
2.6沟通管理的要点四个适当适当的时间,将适当的信息,通过适当的渠道,发送给适当的利益干系人,并确保利益干系人正确理解分析利益干系人与项目的兴趣及影响程度,针对每个利益干系人制定沟通计划沟通的三大原则及时、准确、信息量恰到好处计划阶段的关键明确项目范围、全面的风险识别、各关键干系人的识别与沟通计划计划阶段常见问题对工作任务分解不充分、风险防范意识不强,无沟通计划、计划通常由个人制定,没有在项目组达成共识第5讲IT项目实施与监控
1.1IT项目生命周期--实施与监控主要工作内容实施阶段建立与完善项目联络渠道、建立项目信息控制系统、实施项目激励机制、按计划执行WBS的各项工作、解决实施中的问题指导/监督/预测/控制阶段质量、进度、成本、风险、需求的变更等
2.1软件企业的人力资源管理软件企业与传统工业企业不同,与现代企业的其他行业相比,最主要特征是
(1)企业最主要的“资产”是一批掌握技术、熟悉业务、懂得管理的“人”
(2)人力成本是软件企业的主要成本
(3)知识和经验的积累是软件企业主要的财富积累因此
(1)软件企业的人力资源管理,是企业最主要的管理内容
(2)软件项目组的管理过程,几乎全部是围绕“人”来进行的管理
2.2“人件”与“湿件”“人件”“人件”是迪马可(TomdeMarco)和李斯特(TimothyLister)1987年合写的《人件富有成果的项目和团队》一书中的术语,原指的是与计算机互动的人的条件以后大家逐渐理解为与计算机硬件、软件相对应的人在管理学界,该书已是关于“人件”理论的经典之作,它专门讨论了软件开发和维护的团队管理问题“湿件”“湿件”一词源自美国鲁迪·卢克(RudyRucker)1988年出版题为“湿件”的科幻小说该书是卢克三卷本系列科幻小说《软件》、《湿件》和《自由件》的第二卷“湿件“是新经济增长理论中的一种知识类型新经济增长理论认为,经济的投入要素分为两大类”硬件”和”知识”硬件,非知识,非人类要素,如物品、自然资源、能源和物质基础设施等知识又分为“软件”和“湿件”两种类型,“软件”也称“思想”(ideas),是编码化的、储存在人脑之外(如书籍、磁盘、录音录象带等)的知识;“湿件”也称“技能”(skills)或“只可意会的知识”(tacitknowledge),是储存于人脑之中、无法与拥有它的人分离的知识,包括能力、才干、信念(convictions)等等软件与湿件之间的差异,在于编码化程度的不同软件表示的思想可以用言语、符号或其他表达手段来表述,技能则无法形式化,总是处于只可意会不可言传的状态对知识经济时代经济的持续增长来说,资本即硬件的积累固然重要,但知识(包括生产新物件和更有效率地组织物件的新思想;使思想得以落实和物件得以利用的新的更好的技能)是更重要的源泉新经济增长理论揭示了知识的两种类型--思想和技能--的生成、传播和使用的不同特征新思想的产生是很不容易的,但新思想一旦产生,却能很方便、廉价地传播,可以为任何数量的人使用而技能则是由从人的内在素质到个人经验再到训练等种种因素组成,只有拥有它的人才能使用,它的传输复杂、代价高昂和缓慢知识积累和创新,是思想(软件)、技能(湿件)与机器设备、基础设施等物质生产要素(硬件)之间互动的结果,体现为复杂的持续性学习它对经济组织的核心竞争力至关重要
2.3“未来是湿的”“我们可以把湿件理解为是处于生命状态的东西,它和软件可以保存于无生命的代码状态不同,和包括机器、设备在内的硬件更是不同所以说,微软在软件的维度中存在,而开源运动在湿件的维度中存在”从更广泛的意义上说,前现代的组织,是按硬件的方式组织的;现代的组织,是按软件的方式组织的;后现代的组织是按湿件的方式组织的所以,未来是湿的
2.3软件项目中人的特征
(1)高知识更新性软件项目所需要的人的知识,是不断更新的知识三年前熟悉的知识,可能三年后就基本没有什么价值
(2)高主观经验性虽然软件的知识在不断更新,但是,开发经验、行业经验却是长期积累的一个在行业中长期从事应用系统开发的熟练的系统分析师,是各软件企业抢手的热门人才
(3)高自主性正是由于上述特点,高层次的软件人才,还是处于卖方市场这使软件人才在人力资源市场的双向选择中,处于主动地位软件企业如何留住人才,是一个非常重要和困难的工作
(4)主观能动性软件开发的特点,决定了软件人才个人行为,在开发过程中的影响和作用工作绩效的好坏,工作效率的高低,在很大程度上,由项目中的个人所决定
(5)效率波动性作为项目组中的个人,其效率的发挥,也是不稳定的常常受各种因素的影响,呈现波动性
(6)资源消耗性项目中的个人,是项目资源的消耗者进度、成本、质量控制和变化,首先是因为项目中人的因素的变化
(7)不可存储性项目的人力资源,包括人的时间、精力、知识、积极性等
2.4项目经理的职权
(1)高层经理给项目经理的授权任务分配权、预算制定与控制权、提升建议/批准权、资金使用权、处罚权
(2)项目经理的权力不是职务所固有的
(3)项目经理主要通过个人的人格魅力、经验、影响力、协调能力来从事管理
(4)影响力不可能只靠权力
2.4项目经理的9条基本影响因素
1、权利——发布命令的正当的等级权利
2、任务——可感知到的对工作任务分配的影响力
3、预算——可感知到支配资金的能力
4、提升——提拔员工的权力
5、资金——涨工资和增加福利的权利
6、处罚——有实施处罚的权利
7、工作挑战——为特定员工分配所喜好的工作的权力
8、专门技术——拥有其他人很需要的知识、技术和技能
9、友谊——良好的人际关系
3.1两大沟通类型
(1)项目组内沟通四种沟通需求职责分配授权协调状态报告会议,是最常用的沟通方式项目开工会成员进度汇报项目进展会沟通的要点及时、公开、恰到好处
(2)与高层、客户的沟通需要回答以下问题谁,为什么需要信息?他们需要什么类型的信息?何种详尽程度?频度如何?与高层沟通时,目标是什么?采用什么样的方法完成沟通?
3.2沟通的要点项目组全体成员对目标达成共识项目沟通计划、规划互相尊重主动倾听双赢
3.3有效沟通的关键要素会前事先了解为什么开会,以经预期要取得什么结果考虑是否可能取消会议确定需要参加会议的最少人数选择会议地点,会议的布置与会议目标相协调会中做好准备,按时开始,并首先点明会议的目的和议程每位与会者都有发言的机会对会议内容进行口头总结会后会后发布会议纪要给每位与会者必须产生明确的决定所有决定必须立即付诸行动
4.软件项目监控概述项目控制的基本内容衡量当时情况预测未来的情况对比预测情况和当时情况及时制定实现目标、进度或预算的修正方案.软件项目监控的难点软件项目的不确定性项目内容的隐性与分散性计划与变化的关系培养按计划工作的习惯项目经理的权力有限
4.1软件项目监控的要点明确项目控制的目的加强来自各方面的综合、协调和督促.要建立项目管理信息制度项目主管及时向领导汇报工作执行情况定期向客户报告并随时向各职能部门介绍整个项目的进程.
4.3项目进度控制的类型——进度控制项目进度控制是一种循环的例行性活动其活动分为四个阶段编制计划实施计划检查与调整计划分析与总结
4.3项目监控的手段与工具控制手段制定并遵守计划、不断监督、必要时进行调整、沟通、团队工作可视化图表工具重要的关系、里程碑图、甘特图、费用成本曲线、资源负荷图、项目成本记录、工作绩效图、项目报告表
4.
3.3项目进度控制的类型——作业控制作业控制的目的采取一定措施,保证每一项作业本身按计划完成作业控制的内容以工作分解结构WBS的具体目标为基础,针对具体的每个工作环节检查每项作业的质量,监控每项作业的进展情况如果作业存在缺陷,则由项目管理部门下达指令,调整或重新安排存在缺陷的作业,以保证其不致影响整个项目工作的进行进度控制就是采取措施保证项目按计划的时间表来完成工作,防止拖期影响工期的主要因素责任心不强、信息失实或遗漏、协作部门的失误等按照不同管理层次对进度控制的要求分为三类管理层次|进度控制要求高层次管理部门项目经理|项目总进度控制对项目中各里程碑事件的进度控制多级项目的项目部门|项目主进度控制对项目中每一主要事件的进度控制各作业部门|项目详细进度控制对各具体作业进度计划的控制,这是进度控制的基础5项目进展报告—主要内容
1.项目进展简介列出有关重要事项对每一个事项,叙述近期的成绩、完成的里程碑以及其它一些对项目有重大影响的事件(如采购、人事、业主等)
2.项目近期趋势叙述从现在到下次报告期间将要发生的事件对每个将要发生的事件进行简单说明并提供一份下一期的里程碑图表
3.预算情况一般以清晰、直观的图表反映项目近期的预算情况,并对重大的偏差做出解释
4.困难与危机:困难是指你力所不能及的事情,危机是指对项目造成重大险情的事同时可提出高层管理人员支持的要求
5.人、事表扬
5.1项目进展报告的形式
1.日常报告日常报告是为报告有规律的信息,按里程碑时间安排报告时间,有时根据资源利用期限发出日常报告,也有时每周甚至每日提供报告;
2.例外报告此种报告的方式用在为项目管理决策提供信息报告;
3.特别分析报告常用于宣传项目特别研究成果或是对项目实施中发生一些问题进行特别评述
5.
1.1五种项目执行信息的收集方法在整个报告期内,需要收集两种数据或信息
1.实际执行的数据,包括活动开始或结束的实际时间;使用或投入的实际资源和成本等;
2.有关项目范围、进度计划和预算变更的信息五种收集方法
1.发生概率统计法即对某一事件发生的次数进行记录的信息收集方法,主要用于延误报告次数、无事故天数、运行故障次数等
2.原始数据记录法这是对项目中实际资源投入量和项目产出技术指标进行统计
3.经验法这类指标的定量或定级来源于人的主观意志
4.指标法对一些较难或者甚至无法直接获得的对象的有关信息,寻找一种间接的度量或指标
5.口头测定方式这种方式常用于测定队员的合作质量、队员士气高低、项目主和业主间合作程度等第六讲软件配置管理1为什么要进行软件配置管理?复杂的软件系统及开发过程开发的系统越来越大,功能越来越复杂众多软件开发人员多种文件对象和类型(需求、各种文档、设计模型、源代码、目标代码、Web组件、测试脚本、测试用例)多种版本多种平台多个开发地点
1.1以往软件开发过程中的问题版本难以控制资源变化频繁导致失控配置审核问题项目开发中的组织管理问题项目组成员之间沟通不够文档与程序严重脱节无法有效地管理和跟踪变更测试工作不规范对软件版本的发布缺乏有效的管理施工周期过长且开发人员必须亲临现场无法构建企业内部的软件标准构件仓库(即财富库)
1.2造成的后果重要数据丢失开发周期漫长开发成本增加产品可靠性差软件重用率低下无法开展规范化测试工作缺乏软件开发历史数据积累,无法为日后借鉴维护和升级困难施工成本增加用户抱怨使用不便,满意度低项目风险增加
1.6实施软件配置管理的益处加强了开发过程控制,加强了产品质量的可控性节约费用缩短开发周期、减少施工费用有利于知识库的建立代码对象库、业务及经验库规范管理量化工作量考核、规范测试、加强协调与沟通2什么是软件配置管理?配置管理能够系统地处理变更,从而使得软件系统可以随时保持其完整性配置管理又可称为“变更控制”,可以用来评估提出的变更请求,跟踪变更,并保存系统在不同时间的状态另外一个定义对软件开发组所建立的软件的修改进行标识、组织和控制的艺术,其目标是减少错误,提高生产力另外一个定义标识和确定系统中配置项的过程,在系统整个生存周期内控制这些项的发布和变更,记录并报告配置的状态和变更要求,验证配置项的完整性和正确性作用在质量体系的诸多支持活动中配置管理处在支持活动的中心位置它有机地把其它支持活动结合起来形成一个整体相互促进相互影响有力地保证了质量体系的实施目的软件配置管理的目的是建立和维护在项目的整个软件生存周期中软件项目产品的完整性主要内容包括及时地确定软件的配置,系统地控制软件配置的变更保证整个软件生命周期软件配置的完整性和可追溯性总结软件配置管理,贯穿于整个软件生命周期,它为软件研发提供了一套管理办法和活动原则软件配置管理无论是对于软件企业管理人员还是研发人员都着重要的意义软件配置管理可以提炼为三个方面的内容
2.6存储库存储库是一个中央数据库,存放各种版本文件、目录、交付对象、源数据及其关联对象存储库位于网络中的SCM服务器上,并能够通过所有客户端进行访问存储库用于存储全部的控制版本的组件、元素、分支和元数据
2.6软件开发库、软件受控库软件开发库指在软件生命周期的某一个阶段期间,存放与该阶段软件开发工作有关的计算机可读信息和人工可读信息的库软件受控库指在软件生命周期的某一个阶段结束时,存放作为阶段产品而释放的、与软件开发工作有关的计算机可读信息和人工可读信息的库软件配置管理就是对软件受控库中的各软件项进行管理,因此软件受控库也叫配置管理库软件受控库通常用于保存基线
2.7团队开发:版本控制记录软件在生命周期内的所有变更情况记录任何软件变更的历史保存任何生效变更的版本在版本控制下能任意回到历史过程中的任何一个版本3什么是配置项?软件配置管理的对象是软件配置项(SoftwareConfigurationItem缩写SCI)软件配置是指一个软件产品在软件生命周期各个阶段所产生的各种形式(机器可读或人工可读)和各种版本的文档、程序及其数据的集合该集合中的每一个元素称为该软件配置中的一个配置项中国国家标准《计算机软件配置管理计划规范》与合同、过程、计划和产品有关的文档及数据,源代码、目标代码和可执行代码,相关产品,包括软件工具、库内可复用软件、外购软件及顾客提供的软件等4什么是版本?版本-Version亦称配置标识,是指某一特定对象的具体实例的潜在存在这里的某一特定对象是指由版本维护工具管理的软件组成单元,如源代码;具体实例则是指软件开发人员从软件库中恢复出来的某软件组成单元具有一定内容和属性的一个真实拷贝版本记录了配置项的演化过程
4.3版本标识版本标识由版本的命名规则决定
(1)数字顺序形版本标识例如V
1.
0、V
1.
1、V
1.
2、V
1.
1.
0.
2、V
1.
2.
0.4
(2)符号命名版本标识例如X86/WinNT/DBServer
(3)属性版本标识例如J2SDK.v.
1.
2.3:10/31/2000-18:00nativethreads
(4)正交版本标识5什么是基线?基线Baseline一个配置项在其生命周期的某一特定时间被正式标明、固定并经正式批准的一个版本,无论媒体是什么[ISO/IEC12207]基线形成一般是在软件生命周期各阶段末尾的特定点,亦称里程碑时间点作用基线的作用是把各阶段的工作划分得更加明确,使得本来连续的工作在这些点上断开,使之便于检验和确认阶段开发成果,使后续工作在确认后的基准上进行特性具有明确标识、具有明确内容、经正式审批、严格控制变更
5.2如何进行配置?
(1)管理所有目录和全部文件的版本只是其中的一部分
(2)因为软件产品与源代码是一对多的关系,SCM需要好的配置报告或工作空间来进行管理例如一个单一的软件程序有可能是由成百甚至上千个源代码生成的
(3)记录并维护历史是必要的,但还远远不够!
(4)一个SCM系统必须能够再生和重现一个软件产品的全部的完整的配置情况,而不仅仅是单个文件的版本
(5)把配置管理想象成一个软件的时光机器能够定位到最新测试通过的源代码;能够定位到为不同平台或不同客户所做的特殊版本的最新的源代码;能够定位到6个月前或12个月前甚至5年前所发布版本的所有源代码;能够定位到2年前所发布的版本在之后所有BUG修复时任何一版的源代码
6.3工业化时期:并行开发管理
(1)大型软件项目与很多作者合写一本书具有同样的特征开发人员不断地创建新的版本、文件、目录;开发人员不断地修改已经存在的文件版本;开发人员需要从不同地方同时访问相同的代码;开发人员经常需要与其他开发人员的工作成果进行集成
(2)在工业化时期我们称之为“并行开发”
(3)没有并行开发管理将会导致开发过程混乱
(4)并行开发管理能力决定了一个团队的配置管理水平
6.4软件开发是一个团队运动
(1)复杂的开发需要彼此隔绝
(2)由于不同原因需要同时修改相同的工作产品
(3)同一个代码或产品需要支持多种方式支持多种平台、支持多种版本、支持多项目、支持多地点
6.5并行开发管理
(1)允许多个开发人员同时工作在相同的代码,而无需等待他人完成后再开始
(2)允许在相同代码上建立多个开发分支支持多项目、支持多版本、支持多平台、
(3)能够使多个团队并行工作,甚至在远程
(4)当变更完成并被他人认可时,可以很容易地将他们集成到一起7分支管理并行开发的关键方法隔离变更对变更、BUILD、测试以及基线等进行隔离,分别进行管理将工作分解、变更任务、工作分类等有机地组织起来对变更任务的集成进行控制有助于问题的交流、可见性、项目计划和跟踪以及最终的风险管理
7.3检入/检出模型
8.2在集成和测试期间的Build隔离将集成分支上的所有用户锁定稳定由专人进行BUILD,不成功需要修改错误;对BUILD结果进行测试,有问题进行修复共享生成基线、提升老基线第七讲版本控制软件介绍
1.1使用版本控制软件的理由及时了解团队中其他成员的进度轻松比较不同版本间的细微差别;记录每个文件成长的每步细节,利于成果的复用reuse;资料共享,避免以往靠拷贝文件造成的版本混乱;人人为我,我为人人所有成员维护的实际是同一个版本库,无需专人维护所有文件的最新版本;协同工作,大大提高团队工作效率,无论团队成员分布在天涯还是海角;2常用的开源版本软件软件CVS,较早很流行的开源版本系统SVNSubversion,开源,与CVS原理和功能相似,取代CVSGit,开源,分布式版本管理系统,目前发展势头很强3Subversion相关软件是一个客户/服务器系统软件,包含服务器软件部分,Subversion,客户端软件TortoiseSVN的版本控制系统Subversion是一个开源的版本控制系统,拥有CVS的大部分特征,并在CVS的基础上有更强的扩展,用来代替CVS系统TortoiseSVN SVN的客户端工具,和资源管理器完美集成,基于TortoiseCVS的代码开发,使用上与TortioseCVS极其相似;
3.1SVN基本概念配置库(Repository)配置(repository),就是位于服务器端,统一管理和储存数据的地方SVN的核心是配置库,配置库按照文件树形式储存数据-包括文件和目录任意数量的客户端可以连接到配置库,读写这些文件通过写数据,别人可以看到这些信息;通过读数据,可以看到别人的修改最特别的是Subversion会记录配置库中的每一次更改,不仅针对文件也包括目录本身,包括增加、删除和重新组织文件和目录工作副本(WorkSpace工作空间)与位于中央配置库相对应,每个人的工作空间,它是每个程序员工作的地方程序员从配置库拿到源代码,放在本地作为工作副本在工作副本上进行查看、修改、编译、运行、测试等操作,并把新版本的代码从这里提交回配置库库中
3.1SVN的工作模式复制-修改-合并方案Subversion默认的模式在这种模型里,每一个客户读取项目配置库建立一个私有工作副本——版本库中文件和目录的本地映射用户并行工作,修改各自的工作副本,最终,各个私有的复制合并在一起,成为最终的版本,这种系统通常可以辅助合并操作,但是最终要靠人工去确定正误锁定-修改-解锁方案在这样的模型里,在一个时间段里配置库的一个文件只允许被一个人修改此模式不适合软件开发这种工作
3.2SVN服务器SVN服务器支持linux和windows,更多是安装在Linux下SVN服务器有2种运行方式独立服务器、借助apache2种方式各有利弊SVN存储版本数据也有2种方式BDB,在BerkeleyDB数据库中存放数据;和FSFS是使用普通文件,采用自定义的格式来储存因为BDB方式在服务器中断时,有可能锁住数据,所以还是FSFS方式更安全一点
3.2SVN服务器软件Windows环境下常用的两种SubversionVisualSVNServerVisualSVNServer集成了Subversion和Apache;封装SVNServer为windwsservice,并随机器自动启动;图像化配置Apache服务器,指定认证方式、访问端口等简单操作;图像界面配置用户权限等本讲详细介绍VisualSVNServer作为SVN服务器端软件
3.
2.4Trunk、Tranches、Tags之间的区别Trunk、Tranches、Tags只是便于用户区分不同类型版本的三个存放目录,为可选项Trunk为主流版本容器,用于存放该项目的主版本,通常一个项目对应一个主版本Branches为分支版本容器,用于存放该项目的分支版本在项目开发过程中,经常要开发许多新功能,在开发这些新功能时,常会带来编译错误与bug,影响原有程序的正常执行因此,SVN为开发这些新功能专门设有Branches存放目录,在新功能足够稳定的情况下,把这些版本融合到主流版本中Tags为特殊版本容器,每阶段保存一个版本,作为该软件的里程碑,比如发行版,方便你日后对各发行版bug的修改
4.1SVN客户端类型Subversion的客户端有三种第一种是websvn等基于web的,需要web服务器的支持,适宜于跨越防火墙、基于Internet的协作项目开源项目常用它第二种客户端软件,需要用户在本地安装客户端以TortoiseSVN为代表,适宜集团内部的软件开发项目第三种是插件,与NetbeanEclipse等开发工具紧密集成第八讲软件项目风险管理软件项目中的风险不断变换的需求低劣的计划和估算不可信赖的承包人欠缺的管理经验人员问题技术失败政策的变化第一节风险和风险管理风险是不确定的事件,一旦发生,将会造成消极影响风险的三要素一个未来的事件、事件发生的概率、事件的影响风险发生的概率越高,造成的影响越大,就越是高风险,否则就是中等风险或低风险风险分类从风险的范围角度上看,可将软件项目的风险分为三种类型项目风险潜在的项目预算、进度、人员、资源、用户和需求等方面的问题技术风险实现和交付产品过程中所应用的各种技术所包含的风险技术的正确性、不确定性、复杂性、技术陈旧等因素都可带来技术风险商业风险与市场、企业产品策略等因素有关的风险从风险可预测的程度来看,可将风险分为以下三种类型已知风险通过评估项目计划、项目的商业和技术环境以及其它可靠的信息来源之后可以发现的那些风险可预测风险能够从过去的项目经验中推测出的风险不可预测风险事先很难识别出来的风险风险管理风险管理是指在项目进行过程中不断对风险进行识别、评估和监控的过程,其目的是减小风险对项目的不利影响风险管理用来处理项目中的各种不确定性风险管理策略可以分为4个层次危机管理风险已经造成麻烦后才着手处理风险缓解事先制定好风险发生后的补救措施,但不制定任何防范措施着力预防将风险防范作为项目的一部分加以规划和执行消灭根源识别和消灭可能产生风险的根源采取主动的风险管理策略着力预防和消灭根源的管理策略这一策略在项目计划阶段就启动了识别出潜在的风险评估它们出现的概率和潜在的影响按照重要性进行排序然后制定一个计划来管理风险软件项目风险管理包括四个过程风险识别风险评估风险规划风险监控第二节风险识别风险识别方法检查表法风险检查表中列出了项目中常见的风险项目相关人员通过核对风险检查表,判断哪些风险会出现在项目中可根据项目经验对风险检查表进行修订和补充该方法可以使管理者集中识别常见类型的风险有研究表明IT项目常常存在一些共同的风险如人员缺乏、不现实的人员和成本估计、晚期需求变化、外购构件缺陷等风险条目罗列依据项目规模商业影响项目范围客户特性过程定义技术要求开发环境人员数目及其经验其中每一项都可能包含很多风险条目优缺点快速而简单,可以用来对照项目的实际情况,逐项排查,从而帮助识别风险由于每个项目都有其特殊性,检查表法很难做到全面周到德尔菲方法德尔菲方法又称专家调查法,本质上是一种匿名反馈的函询法它起源于20世纪40年代末,最初由美国兰德公司应用于技术预测把需要做风险识别的软件项目的情况分别匿名征求若干专家的意见然后把这些意见进行综合、归纳和统计,再反馈给各位专家,再次征求意见这样反复经过四至五轮,逐步使专家意见趋向一致,作为最后预测和识别风险的依据头脑风暴法头脑风暴(BrainStorm)法简单来说就是团队的全体成员自由地提出自己的主张和想法,它是解决问题时常用的一种方法将项目主要参与人员代表召集到一起,各自根据自己对项目不同部分的认识,识别项目可能出现的问题一个有益的做法是询问不同人员所担心的内容头脑风暴法的优点是可对项目风险进行全面的识别情景分析法情景分析法是根据项目发展趋势的多样性,对系统内外相关问题的系统分析,设计出多种可能的未来前景,然后用类似于撰写电影剧本的手法,对系统发展态势做出自始至终的情景和画面的描述适应场合适用于对可变因素较多的项目进行风险预测和识别的技术特色它在假定关键影响因素有可能发生的基础上,构造多重情景,提出多种未来的可能结果,以便采取适当措施防患于未然第三节风险评估对风险发生概率的估计和评价,项目风险后果严重程度的估计和评价,项目风险影响范围的分析和评价,以及对于项目风险发生时间的估计和评价风险值(风险的严重程度)R=FPIP是风险发生的概率I是风险发生后对项目目标的影响确定风险的优先次序根据风险的严重程度进行排序,确定最需关注的前几个(TOP10)风险风险评估的方法包括定性风险评估和定量风险评估定性风险评估定性评估风险的发生概率及后果风险概率度量高、中、低极高、高、中、低、极低不可能,不一定,可能和极可能等等风险后果度量高、中、低极高、高、中、低、极低灾难,严重,一般,轻微,可忽略等等定量风险评估量化分析每一个风险的概率及其对项目造成的后果,也分析项目总体风险的程度分析方法盈亏平衡分析模拟专家访谈决策树分析量化风险检查表……专家访谈邀请具有类似项目经验或相关领域经验的专家,这些专家运用他们丰富的经验和知识对软件项目的风险进行度量其结果会相当准确和可靠,甚至有时比通过数学计算和模拟仿真得出的结果还要准确和可靠如果风险的影响后果大小不易直接估算出来,可以把后果分解为更小的部分,再对其进行评估,然后把各个部分的结果累加,得到总的评估值例如,如果使用3种新编程工具,可以单独评估每种工具未达到预期效果的损失,然后把损失加到一起,这要比总体评估容易多了决策树分析决策树是一种形象化的图表分析方法,把项目所有可供选择的方案、方案之间的关系、方案的后果及发生的概率用树状的图形表示出来,为决策者提供选择最佳方案的依据决策树中的每一个分支代表一个决策或者一个偶然的事件,从出发点开始不断产生分支以表示所分析问题的各种发展的可能性每一个分支都采用预期损益值(ExpectedMonetaryValueEMV)作为其度量指标决策者可根据各分支的预期损益值中最大者(如求最小,则为最小者)作为选择的依据预期损益值等于损益值与事件发生的概率的乘积,即EMV=损益值×发生概率例如某行动方案成功的概率是50%,收益是10万,则EMV=10*50%=5万第四节风险规划针对风险分析的结果,制定风险应对策略和措施的过程,其目标是应对、减少、以至于消灭风险事件风险规划的主要策略回避风险是对可能发生的风险尽可能地规避,采取主动放弃或者拒绝使用导致风险的方案例如放弃采用新技术消除了风险的起因,将风险发生概率降为零具有简单和彻底的优点注意事项对风险要有足够的认识;当其他风险策略不理想的时候,可以考虑;可能产生另外的风险;不是所有的情况都适用,有些风险无法回避,如用户需求变更;转移风险转移风险是为了避免承担风险损失,有意识地将损失或与损失有关的财务后果转嫁出去的方法例如采购、分包、免责合同、保险缓解风险在风险发生之前采取一些措施降低风险发生的可能性或减少风险可能造成的损失例如,为了防止人员流失,提高人员待遇,改善工作环境;为防止程序或数据丢失而进行备份等接受风险项目团队有意识地选择由自己来承担风险后果当风险很难避免,或采取其它风险应对方案的成本超过风险发生后所造成的损失时,可采取接受风险的策略主动接受在风险识别、分析阶段已对风险有了充分准备当风险发生时马上执行应急计划被动接受风险发生时再去应对在风险事件造成的损失数额不大,不对软件项目的整体目标造成较大影响时,项目团队将风险的损失当做软件项目的一种成本来对待第五节风险监控实施和跟踪风险管理计划确保风险策略正在合理使用监视剩余的风险和识别新的风险收集可用于将来的风险分析信息建立风险监控体系项目风险监控体系的建立,包括制定项目风险的方针、程序、责任制度、报告制度、预警制度、沟通程序等方式,以此来控制项目的风险项目风险审核项目风险审核风险计划是否有效地实施并达到预定目标确定监控活动是否符合项目风险计划确定监控结果是否符合项目风险计划,系统地进行项目风险审核是开展项目风险监控的有效手段,可以作为改进项目风险监控活动的一种有效的机制Top10风险列表控制是最有效的风险控制工具之一定期每周审核Top10风险列表挣值分析通过挣值分析可以显示项目在成本和进度上的偏差如果偏差较大,则需要进一步对项目风险进行识别、分析挣值分析的三个基本参数包括计划值(PV)、实际成本(AC)和挣值(EV)
1、计划值PV,PlanValue,又叫计划工作量的预算费用BCWS,BudgetedCostforWorkScheduled是指项目实施过程中某阶段计划要求完成的工作量所需的预算工时(或费用)计算公式是 PV=BCWS=计划工作量*预算定额 PV主要反映进度计划应当完成的工作量,而不是反映应消耗的工时或费用
2、实际成本(AC,ActualCost),又叫已完成工作量的实际费用(ACWP,ActualCostforWorkPerformed)指项目实施过程中某阶段实际完成的工作量所消耗的工时(或费用)主要反映项目执行的实际消耗指标
3、挣值(EV,EarnedValue),又叫已完成工作量的预算成本(BCWP,BudgetedCostforWorkPerformed)指项目实施过程中某阶段实际完成工作量及按预算定额计算出来的工时(或费用)计算公式是 EV=BCWP=已完成工作量*预算定额风险评价软件项目管理会面临很多已知和未知的问题,尤其是没有管理经验的项目经理更应该及早评价和预防项目风险风险评价分类按照阶段不同可以分为事前评价事中评价事后评价跟踪评价等;按照评价方法不同可以分为定性评价定量评价综合评价等推荐的风险管理措施软件项目计划应包括风险管理计划在必要时任命风险管理负责人使用TOPTEN风险清单作为主要的风险管理工具建立匿名风险汇报渠道第10讲软件质量管理--全面软件质量管理
1.引言软件质量管理是充满争论的话题被人们奉为软件质量管理圣经的CMM和ISO9001似乎并不奏效,现实和理想之间的差距太大经典软件工程教科书以及CMM和ISO9001总是抛开商业目标谈质量管理,本末倒置,纸上谈兵,误导了大量读者,所以质量管理才变得那么艰辛世界上还没有万能的软件质量管理圣经,我们不要迷信CMM和ISO9000要多向有实战经验的同行专家请教,但是不要轻信“纸上谈兵”的专家本文给出了一套实用主义的“全面软件质量管理”方法重要的理念商业目标决定质量目标提高软件质量的最终目的是为了赢利,而不是创造完美无缺的产品因此对于普通商业软件而言,并不是“质量越高越好”,而是恰好让广大用户满意,并且将提高质量所付出的代价控制在预算之内
2.1如何描述质量词典对质量的定义是
①典型的或本质的特征;
②事物固有的或区别于其他事物的特征或本质;
③优良或出色的程度CMM对质量的定义是
①一个系统、组件或过程符合特定需求的程度;
②一个系统、组件或过程符合客户或用户的要求或期望的程度上述定义很抽象,人们看了准会一脸迷惘就让我们用“人的健康”来类比解释软件质量古时候人们以为长得结实、饭量大就是健康,这显然是不科学的现代人总是通过考察多方面的生理因素来判断是否健康,如测量身高、体重、心跳、血压、血液、体温等如果上述因素都合格,那么表明这人是健康的如果某个因素不合格,则表明此人在某个方面不健康,医生会对症下药通过类比,我们这样理解软件质量软件质量是许多质量属性的综合体现,各种质量属性反映了软件质量的方方面面人们通过改善软件的各种质量属性,从而提高软件的整体质量(否则无从下手)软件的质量属性很多,如正确性、精确性,健壮性、可靠性、容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等上述这些质量属性之间“你中有我,我中有他”,非常缠绵如果开发人员每天要面对那么多的质量属性咬文嚼字,不久就会迂腐得像孔乙己,因此我们有必要对质量属性做些分类和整合质量属性可分为两大类“功能性”与“非功能性”,后者有时也称为“能力”(Capability)
2.2十大软件质量因素功能性质量因素正确性,健壮性,可靠性非功能性质量因素性能,易用性,清晰性,安全性,可扩展性,兼容性,可移植性为什么是“十大”质量因素逐一解释“十大”质量因素(参见《高质量程序设计指南——C++/C语言》)
2.3软件质量要素什么是软件质量要素?
(1)从技术角度讲,对软件整体质量影响最大的那些质量属性才是质量要素;
(2)从商业角度讲,客户最关心的、能成为卖点的质量属性才是质量要素对于一个特定的软件而言,我们首先判断什么是质量要素,才能给出提高质量的具体措施,而不是一股脑地想把所有的质量属性都做好,否则不仅做不好,还可能得不偿失如果某些质量属性并不能产生显著的经济效益,我们可以忽略它们,把精力用在对经济效益贡献最大的质量要素上简而言之,只有质量要素才值得开发人员下功夫去改善
2.4正确性正确性是指软件按照需求正确执行任务的能力“正确性”的语义涵盖了“精确性”正确性无疑是第一重要的软件质量属性技术评审和测试的第一关都是检查工作成果的正确性机器不会主动欺骗人,软件运行出错通常都是人造成的,所以不要找借口埋怨机器有毛病
2.5健壮性健壮性是指在异常情况下,软件能够正常运行的能力正确性描述软件在需求范围之内的行为,而健壮性描述软件在需求范围之外的行为开发者往往把异常情况错当成正常情况而不作处理,结果降低了健壮性用户才不管正确性与健壮性的区别,反正软件出了差错都是开发方的错所以提高软件的健壮性也是开发者的义务健壮性有两层含义一是容错能力,二是恢复能力从语义上理解,恢复不及容错那么健壮Unix容错能力很强,可惜不好用Windows容错能力较差,但是恢复能力很好,而且很好用占了90%的操作系统市场
2.6可靠性可靠性是指在一定的环境下,在给定的时间内,系统不发生故障的概率可靠性本来是硬件领域的术语比如某个电子设备在刚开始工作时挺好的,但由于器件在工作中其物理性质会发生变化(如发热),慢慢地系统的功能或性能就会失常所以一个从设计到生产完全正确的硬件系统,在工作中未必就是可靠的软件在运行时不会发生物理性质的变化,人们常以为如果软件的某个功能是正确的,那么它一辈子都是正确的可是我们无法对软件进行彻底地测试,无法根除软件中潜在的错误平时软件运行得好好的,说不准哪一天就不正常了,如有千年等一回的“千年虫”问题,司空见惯的“内存泄露”、“误差累积”问题等等软件可靠性分析通常采用统计方法,遗憾的是目前可供第一线开发人员使用的成果很少见,大多数文章限于理论研究口语中的可靠性含义宽泛,几乎囊括了正确性、健壮性只要人们发现系统有毛病,便归结为可靠性差从专业角度讲,这种说法是确切的时隐时现的错误一般都属于可靠性问题,纠错的代价很高例如当维护人员十万火急地赶到现场时,错误消失了;等维护人员回家后,错误又出现了…软件可靠性问题主要是在编程时候埋下的祸害(很难测试出来),应当提倡规范化程序设计,预防可靠性祸害
2.7性能性能通常是指软件的“时间-空间”效率,而不仅是指软件的运行速度人们总希望软件的运行速度高些,并且占用资源少些既要马儿跑得快,又要马儿吃的少性能优化的关键工作是找出限制性能的“瓶颈”,不要在无关痛痒的地方瞎忙乎例如在大学里当教师,光靠使劲讲课或者埋头做实验,职称是升不快的有些人找到了突破口,一年之内“造”它几十篇文章,争取破格升副教授、教授程序员可以通过优化数据结构、算法和代码来提高软件的性能例如数据库程序的优化算法复杂度分析是很好的方法,可以达到“未卜先知”的功效性能优化就好像从海绵里挤水一样,你不挤,水就不出来,你越挤海绵越干有些程序员认为现在的计算机不仅速度越来越高,而且内存越来越大,因此软件性能优化的必要性下降了这种看法是不对的,殊不知随着机器的升级,软件系统也越来越庞大了和复杂了,性能优化仍然大有必要最具有代表性的是三维游戏软件,例如《DeltaForce》、《古墓丽影》、《反恐精英》等,如果不对软件(关键是游戏引擎)做精益求精的优化,要想在一台普通的PC上顺畅地玩游戏是不太可能的
2.8易用性易用性是指用户使用软件的容易程度现代人的生活节奏快,干啥事都想图个方便所以把易用性作为重要的质量属性对待无可非议导致软件易用性差的根本原因理工科大学教育存在缺陷没有开设人机工程学、美学、心理学这些必修课,大部分开发人员不知道如何设计易用的软件产品开发人员犯了“错位”的毛病他以为只要自己用起来方便,用户也就会满意软件的易用性要让用户来评价当用户真的感到软件很好用时,一股温暖的感觉油然而生,于是就用“界面友好”、“方便易用”等词来评价软件产品
2.9清晰性清晰意味者所有的工作成果易读、易理解,可以提高团队开发效率,降低维护代价开发人员只有在自己思路清晰的时候才可能写出让别人易读、易理解的程序和文档可理解的东西通常是简洁的一个原始问题可能很复杂,但高水平的人就能够把软件系统设计得很简洁如果软件系统臃肿不堪,它迟早会出问题所以简洁是人们对工作“精益求精”的结果,而不是潦草应付的结果与简洁对立的是“罗里罗嗦”千万不要把在学校里“造文章”的手法用于开发产品!如果把文章写得很简洁,让人很容易理解,投稿往往中不了;只有加上一些玄乎的东西,把本来简单的弄成复杂的,才会增加投稿的命中率
2.10安全性这里安全性是指信息安全,英文是Security而不是Safety安全性是指防止系统被非法入侵的能力,既属于技术问题又属于管理问题信息安全是一门比较深奥的学问,其发展是建立在正义与邪恶的斗争之上这世界似乎不存在绝对安全的系统,连美国军方的系统都频频遭黑客入侵如今全球黑客泛滥,真是“道高一尺,魔高一丈”啊!开发商和客户愿意为提高安全性而投入的资金是有限的,他们要考虑值不值得究竟什么样的安全性是令人满意的呢?一般地,如果黑客为非法入侵花费的代价(考虑时间、费用、风险等因素)高于得到的好处,那么这样的系统可以认为是安全的对于普通软件,并不一点要追求很高的安全性,也不能完全忽视安全性,要先分析黑客行为
2.11可扩展性可扩展性反映软件适应“变化”的能力在软件开发过程中,“变化”是司空见惯的事情,如需求、设计的变化,算法的改进,程序的变化等等由于软件是“软”的,是否它天生就容易修改以适应“变化”?关键要看软件的规模和复杂性如果软件规模很小,问题很简单,那么修改起来的确比较容易,这时就无所谓“可扩展性”了要是软件的代码只有100行,那么“软件工程”也就用不着了如果软件规模很大,问题很复杂,倘若软件的可扩展性不好,那么该软件就像用卡片造成的房子,抽出或者塞进去一张卡片都有可能使房子倒塌现代软件产品通常采用“增量开发模式”,不断推出新版本,获取增值利润可扩展性越来越重要可扩展性是系统设计阶段重点考虑的质量属性谈到软件的可扩展性,开发人员首先想到的是怎样提高可扩展性,于是努力去设计很好的体系结构来提高可扩展性,却不考虑该不该做这件事从商业角度考虑,如果某个软件将不断地推出新版本,那么可扩展性很重要但是如果软件永远都不会有下个版本(一次性买卖),那么根本无需提高可扩展性,何必自找苦吃呢!
2.12兼容性兼容性是指不同产品(或者新老产品)相互交换信息的能力例如两个字处理软件的文件格式兼容,那么它们都可以操作对方的文件,这种能力对用户很有好处兼容性的商业规则弱者设法与强者兼容,否则无容身之地;强者应当避免被兼容,否则市场将被瓜分如果你经常看香港拍的“黑帮”影片,你就很容易明白这个道理金山软件公司的WPS与微软的Word之争WPS一定要与Word兼容,否则活不下去但是Word绝对不会与WPS兼容,除非WPS又在中国称老大中国联通和中国移动的手机互联互通问题(互联网的价值与用户数量的平方成正比)
2.13可移植性软件的可移植性指的是软件不经修改或稍加修改就可以运行于不同软硬件环境(CPU、OS和编译器)的能力,主要体现为代码的可移植性编程语言越低级,用它编写的程序越难移植,反之则越容易这是因为,不同的硬件体系结构(例如IntelCPU和SPARCCPU)使用不同的指令集和字长,而OS和编译器可以屏蔽这种差异,所以高级语言的可移植性更好Java程序号称“一次编译,到处运行”,具有100%的可移植性为了提高Java程序的性能,最新的Java标准允许人们使用一些与平台相关的优化技术,这样优化后的Java程序虽然不能“一次编译,到处运行”,仍然能够“一次编程,到处编译”软件设计时应该将“设备相关程序”与“设备无关程序”分开,将“功能模块”与“用户界面”分开
3.1教科书的片面观点大凡软件工程教科书为了强调质量的重要性,总是要举一些历史上发生过的重大软件质量事故,例如航天飞机爆炸、核电站失事、爱国者导弹发生故障等等这些事故的确不是危言耸听,给人们敲响了质量的警钟学术界总是喜欢宣扬质量至上的理念,而忽视企业的商业利益,将质量目标凌驾于商业目标之上我不能评判这种现象是好还是坏,但是的确误导了大量读者许多软件人员都有“质量越高越好”的观念,这是被教科书灌输的,而不是他自己领悟出来的我曾在著作《高质量程序设计指南——C++/C语言》中大肆宣扬了高质量程序设计的理念,力求使C++程序达到“零缺陷”的质量目标尽管此书得到了许多程序员的赞同,但是我经过反思之后改变了质量观念,我要着重指出的是重视软件质量是应该的,但是“质量越高越好”并不是普适的真理只有极少数软件应该追求“零缺陷”,对绝大多数软件而言,商业目标决定了质量目标,而不该把质量目标凌驾于商业目标之上
3.2严格系统对质量的要求航空航天等系统对质量要求极高,任何缺陷都有可能导致机毁人亡,所以人们不惜一切代价去消除缺陷在发射航天器之前,只要发现任何异常,就会立即取消发射指令,直到异常被消除为止前苏联做得最过分,许多重大武器系统的负责人都签了生死状,系统研制成功则获得英雄勋章,失败则被枪毙在这种压力下没有人敢对质量有一丝松懈
3.3普通商业软件商业目标决定质量目标上述严格系统毕竟是少数,绝大多数普通软件的缺陷并不会造成机毁人亡这样的重大损失,否则没有人敢从事软件开发了在日常工作中,我们接触过的软件几乎都是有缺陷的,即便是软件业老大Microsoft,它的软件产品也经常出错甚至导致死机,人们骂几句后还会照样使用有缺陷的软件企业的根本目标是为了获取尽可能多的利润,而不是生产完美无缺的产品如果企业销售出去的软件的质量比较差,轻则挨骂,重则被退货甚至被索赔,因此为了提高用户对产品的满意度,企业必须提高产品的质量但是企业不可能为了追求完美的质量而不惜一切代价,当企业为提高质量所付出的代价超过销售收益时,这个产品已经没有商业价值了,还不如不开发企业必须权衡质量、效率和成本,产品质量太低了或者太高了,都不利于企业获取利润企业理想的质量目标不是“零缺陷”,而是恰好让广大用户满意,并且将提高质量所付出的代价控制在预算之内
4.1美丽的谎言CMM对软件质量保证是这样描述的软件质量保证(QualityAssurance)的目的是为管理者提供有关软件过程和产品的适当的可视性它包括评审和审核软件产品及其活动,以验证其是否遵守既定的规程和标准,并向有关负责人汇报评审和审核的结果质量保证(QualityAssuranceQA)是CMM和ISO9001最为推崇的改善软件质量的方法基于我亲身实践和调查研究,我敢冒天下之大不讳说一句质量保证并不能保证质量,它是个美丽的谎言简而言之,质量保证活动就是检查软件项目的“工作过程和工作成果”是否符合既定的规范如此简单的活动为什么被冠以“质量保证”这等份量的术语呢?没有历史典故,经我考究,猜想是源于一个天真的假设过程质量与产品质量存在某种程度的因果关系,通常“好的过程”产生“好的产品”,而“差的过程”将产生“差的产品”假设企业已经制定了软件过程规范,如果质量保证人员发现某些项目的“工作过程以及工作成果”不符合既定的规范,那么马上可以断定产品存在缺陷反之,如果质量保证人员没有发现不符合既定规范的东西,那么也可以断定产品是合格的符合既定规范的东西并不意味着质量一定合格,仅靠规范无法识别出产品中可能存在的大量缺陷(以高手与新手的设计、编程为例)质量保证的技术含量太低了,只能检查出肤浅的缺陷,不能对付有技术难度的缺陷所以单独的“质量保证”其实并不能“保证质量”
4.2CMM3级企业QA人员的迷惘(email摘录)我很迷茫,很想找一个人聊聊,希望你能给我点主意,化解我心中的谜团昨天我们公司拿到了CMM3的证书,但是我一点都高兴不起来公司宣称,我们的软件质量大大提高了,但是我却没有信心我们的过程执行得很好,但是我觉得并没有在很大程度上改善产品的质量今天还有一个项目经理跟我诉苦前一阶段大家都忙于执行过程,但是他的产品质量令人很不满意,尤其是测试做的很不到位我是这个项目的SQA,所以我很理解他,但是我帮不上他的忙因为他们的过程执行得很好,这个项目可是通过CMM3级正式评估了的当然,执行CMM有不少好处,比如文档全面完整了,项目管理的可视性提高了但是对于我们公司而言,它并没有在根本上提高我们公司的软件能力比如概要设计,开发人员根本就不知道用来干吗的,怎么能指望他们写出高质量的概要设计说明书出来而在做技术评审的时候,他们很少能找出逻辑性的错误,只能发现一些诸如错别字之类的小错误我们几乎每一个配置项都要经过评审,但是大部分评审都只能发现一些无关痛痒的问题公司已经通过CMM3级了,我认为过程执行得很好了,可是软件质量仍然比较差这是怎么回事啊,你觉得原因在哪里?结论公司按照CMM3级的要求执行,而且质量人员也认为执行过程符合既定的规范,但是软件产品的质量仍然低下所以说“质量保证并不能保证质量”,这句话一点都不过分质量保证对于保证质量而言只是必要的手段,而不是充分的手段
5.1郁闷QA人员诉苦我现在觉得很郁闷,CMM评估前还有目标,评估完了冷静下来却觉得效果很差,很没劲项目经理向我诉苦,他们过程执行的很好,但是对产品质量很不满意,我却无能为力,我这个QA还有什么用处啊!所以我现在干活没有动力,因为不能产生效益,做再多的工作也觉得是白干而且我现在手头有5个项目要跟踪,还不包括一些整理培训记录的杂活,我觉得自己连工人也不如我有一些很好的想法却无处发挥,所以我很迷茫,很矛盾地考虑去留问题郁闷的滋味各色各样,只有正在郁闷的人感受最真切我发现在软件职业里,质量人员是最郁闷的一族郁闷的共同特征有
(1)在执行质量保证活动时,经常受别人的气,真是吃力不讨好
(2)如果项目取得成功,主要功劳都被项目主管霸占了,领导们至多会给质量人员一些口头上的感谢领导们嘴上重视产品的质量,但是内心并不重视质量人员
(3)质量人员没有实质性的权力,没有成就感,但是却对质量负有最多的责任
(4)待遇一般,看不到升迁的机会,没有盼头,要么成为打杂的,要么另寻出路声援我也做过伤害质量人员的事情,非常后悔我所认识的公司内外的质量人员都是性格温和、细致耐心的人,他们的优点在于人格而不是技术平心而论,他们比某些技术出色但是情商不高的技术人员更值得交朋友质量检查是他们的工作职责,谁也不会有意干扰项目,所以任何人都不应该向他们发火
5.2路在何方软件行业里的人嘴上都说质量很重要,可是大多数企业并没有给质量人员提供良好的职业发展空间质量人员通常仅给企业起到心里安慰的作用这样下去,有能耐的质量人员会跑光的我所认识的多数质量人员要么改行了(如当老师),要么读工程硕士,MBA等,以图将来发展事业在大多数的软件企业里,男性处于支配地位,女性职位相对比较低而质量人员通常是女性,很多男性主管从未真正地把质量人员当成企业的宝贵人才看待,这种偏见是非常有害的任何素质合格的员工都是宝贵的人才,很多默默无闻的人才其实是被不懂得质量管理的领导给荒废了质量人员之所以没有发挥预期的效果,不是性别缘故,主要过失在于领导者建议
(1)无论是企业领导还是质量人员,都要好好学习全面软件质量管理方法,结合企业的特点给出真正有效的质量管理方案
(2)只有当企业领导采用了正确的质量管理方案,用了合格的质量人员,才可能看得到比较明显的质量改善,才能形成良性循环
(3)如果想让质量人员负起比较重的责任,那么就要给她相应的权力在企业中,责任和权利是成正比的如果质量人员的地位无足轻重,那么必然导致质量管理无足轻重
(4)给质量人员一个适宜的升迁机会和薪资待遇,让她能够快乐地工作,而不是成天无奈地检查质量
5.3赞美诗中国遭受了非典型肺炎(SARS)的肆虐,人们在危难之际想起了医护人员的好处,因此涌现了许多对医护人员的赞美诗我碰巧在网上搜索到一位软件诗人献给质量人员的赞美诗“晚上八九点钟的太阳”,我认为没有必要等到软件质量灾难降临的时候才想起质量人员,于是摘录这首诗公布于此诗中的“狼人”和“银弹”是软件工程的典故,寓意深刻衷心感谢这位不知姓名的浪漫软件诗人
6.1郎中治病的故事质量的死对头是缺陷(defectbug…),缺陷是混在产品中的人们不喜欢、不想要的东西,它对产品没有好处只有坏处缺陷越多质量越低,缺陷越少质量越高,提高软件质量的基本手段是消除软件缺陷中国郎中看病的故事在中国古代,有一家三兄弟全是郎中其中老三是名医,人们问他“你们兄弟三人谁的医术最高?”他回答说“我常用猛药给病危者医治,偶尔有些病危者被我救活,于是我的医术远近闻名并成了名医我二哥通常在人们刚刚生病的时候马上就治愈他们,临近村庄的人说他是好郎中我大哥不外出治病,他深知人们生病的原因,所以能够预防家里人生病,他的医术只有我们家里才知道”郎中三兄弟是三种治病方式的代言人
6.2消除软件缺陷的三种方式老大治病的方式最高明,如果人们能够预防生病的话,那么没病就用不着看医生了提高软件质量最好的办法是在开发过程中有效地防止工作成果产生缺陷,将高质量内建于开发过程之中主要措施是“不断地提高技术水平,不断地提高规范化水平”,其实就是练内功,通称为“软件过程改进”即使一个人严守养生之道,身体状况良好,但总是会意外地得病的,得了病就要去看医生老二治病的方式就是医院的模式,病人越早看病,就越早治好,治病的代价就越低同理,在开发软件的时候,即使人们的技术水平很高,并且严格遵守规范,但是人非机器,总是会犯错误的,因此无法完全避免软件中的缺陷当工作成果刚刚产生时马上进行质量检查,及时找出并消除工作成果中的缺陷这种方式效果比较好,人们一般都能学会最常用的方法是技术评审、软件测试和过程检查,已经被企业广泛采用并取得了成效老三治病的方式代价最高,只能是不得已而为之可在现实之中,大多数软件企业采用老三的方式来对付质量问题典型现象是在软件交付之前,没有及时消除缺陷当软件交付给用户后,用着用着就出错了,赶紧请开发者来补救可笑的是,当软件系统在用户那里出故障了,那些现场补救成功的人倒成了英雄,好心用户甚至还寄来感谢信
6.3模型借鉴老大、老二治病的方法,我们提炼出全面软件质量管理的模型,如下图所示项目中的所有人员几乎都参与了质量活动,只是介入的程度不同而已,后面几节将逐一介绍这些质量活动
6.4角色职责谁对软件质量负责?是全员负责任何与软件开发、管理工作相关的人员都对质量产生影响,都要对质量负责所以人们不要把质量问题全部推出质量人员或测试人员谁对软件质量负最大的责任?谁的权利越大,他所负的质量责任就越大质量人员是成天与质量打交道的人,但他个人并不对产品质量产生最大的影响,所以也不负最大的责任质量人员的主要职责
(1)负责制定质量计划(很重要但是工作量比较少);
(2)负责过程检查(类似于CMM中的质量保证),约占个人工作量的20%;
(3)参与技术评审,约占个人工作量的30%;
(4)参与软件测试,约占个人工作量的30%;
(5)参与软件过程改进(面向整个机构),约占个人工作量的20%;*上述工作量的比例仅供参考,在实际应用时必须根据项目的特征而定
7.全面软件质量管理制定质量管理计划质量管理计划就是为了实现质量目标的计划而质量目标则是由商业目标决定的开发软件产品的最终目的是为了赚钱,所以人们为提高软件质量所付出的代价是有上限的,项目负责人当然希望代价越低越好质量管理计划是全面质量管理的行动纲领谁制定质量管理计划?由项目核心成员和质量人员共同协商制定,主要由质量人员起草,由项目经理审批即可质量管理计划的主要内容(模板见word文件)
1.质量要素分析
2.质量目标
3.人员与职责
4.过程检查计划
5.技术评审计划
6.软件测试计划
7.缺陷跟踪工具
8.审批意见
8.1概念技术评审(TechnicalReviewTR)的目的是尽早地发现工作成果中的缺陷,并帮助开发人员及时消除缺陷,从而有效地提高产品的质量技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的技术评审方法已经被业界广泛采用并收到了很好的效果,它被普遍认为是软件开发的最佳实践之一技术评审的主要好处有通过消除工作成果的缺陷而提高产品的质量;技术评审可以在任何开发阶段执行,不必等到软件可以运行之际,越早消除缺陷就越能降低开发成本;开发人员能够及时地得到同行专家的帮助和指导,无疑会加深对工作成果的理解,更好地预防缺陷,一定程度上提高了开发生产率技术评审有两种基本类型正式技术评审(FTR)FTR比较严格,需要举行评审会议,参加评审会议的人员比较多非正式技术评审(ITR)ITR的形式比较灵活,通常在同伴之间开展,不必举行评审会议,评审人员比较少
9.1观点技术评审和软件测试的目的都是为了消除软件的缺陷,两者的主要区别是前者无需运行软件,评审人员和作者把工作成果摆放在桌面上讨论;而后者一定要运行软件来查找缺陷技术评审在软件测试之前执行,尤其是在需求开发和系统设计阶段相比而言,软件测试的工作量通常比技术评审的大,发现的缺陷也更多在制定质量计划的时候,已经确定了本项目的主要测试活动、时间和负责人,之后再考虑软件测试的详细计划和测试用例如果机构没有专职的软件测试人员的话,那么开发人员可以兼职做测试工作当项目开发到后期,过程检查和技术评审都已经没有多少意义了,开发小组急需有人帮助他们测试软件,如果质量人员参与软件测试,对开发小组而言简直就是“雪中送炭”强调质量人员一定要参与软件测试(大约占其工作量的30%左右),只有这样他才能深入地了解软件的质量问题,而且给予开发小组强有力地帮助请参考软件测试的专题,此处省略
10.全面软件质量管理过程检查
10.1观点CMM和ISO9001所述的软件质量保证,实质就是过程检查,即检查软件项目的“工作过程和工作成果”是否符合既定的规范“过程检查”这个词虽然没有质量保证那么动听,但是其含义直接明了,不会让人误解为了避免人们误以为“质量保证”能够“保证质量”,我提议用“过程检查”取代质量保证这个术语虽然本章批判了“质量保证”的浮夸,但是并没有全盘否定质量保证的好处过程检查对提高软件质量是有帮助的,只是它的好处没有象质量保证鼓吹的那么好而已符合规范的工作成果不见得就是高质量的,但是明显不符合规范的工作成果十有八九是质量不合格的例如版本控制检查再例如,机构制定了重要工作成果的文档模板(例如需求规格说明书、设计报告等),要求开发人员写的文档尽可能符合模板如果质量人员发现开发人员写的文档与机构的模板差异非常大,那么就要搞清楚究竟是模板不合适?还是开发人员偷工减料?过程检查的要点是找出明显不符合规范的工作过程和工作成果,及时指导开发人员纠正问题,切勿吹毛求疵或者在无关痛痒的地方查来查去不少机构的质量人员并没有真正理解过程检查的意义,老是对照规范,查找错别字、标点符号、排版格式等问题,迷失了方向,这样只有疲劳没有功劳,而且让开发人员很厌烦对于中小型项目而言,过程检查工作由质量人员一个人负责就够了,约占其20%的工作量,让质量人员抽出更多的时间从事技术评审和软件测试工作
10.2流程过程检查计划的要点是确定主要检查项和检查时间(或频度)质量人员在执行过程检查的时候,如果发现问题,应该立即记录下来过程问题也是缺陷,因此最好使用缺陷跟踪工具,有助于提高过程检查的效率质量人员首先设法在项目内部解决已经发现的质量问题,与项目成员们协商,给出解决措施在项目内难以解决的质量问题,由上级领导给出解决措施
11.1概念如果没有缺陷跟踪工具的话,人们只好用纸张或文件去记录缺陷,不仅变更缺陷信息很麻烦,而且难以共享信息缺陷跟踪工具就是帮助项目成员记录和跟踪缺陷用的,一般都有数据库支持,可以在局域网内运行Internet上有许多缺陷跟踪工具,大家可以免费下载使用由于缺陷跟踪工具仅仅是一种辅助性的工具,我们没有必要太在乎该软件的功能,只要用起来方便就行缺陷的主要属性缺陷ID缺陷类型缺陷状态缺陷描述相关文件严重性优先级报告者报告日期接受者解决方案(建议)解决日期缺陷跟踪工具的常见功能查询缺陷添加缺陷修改缺陷删除缺陷分类图缺陷趋势图Email演示“集成化项目管理系统Future”的质量管理功能…第13讲软件项目的质量管理现代《软件工程》与传统软件工程比较,现代软件工程的特点是从开发过程(需求、设计、编码、测试、维护)到产品过程、项目过程、再过程;从传统意义的软件开发及管理,到软件合同、运作、管理,包括:三个方面的过程基本过程、支持过程组织过程7大活动的软件过程工程采购、开发、维护、运作、获取、管理、支持质量保证是产品、项目和软件过程的核心内容质量保证已经完全不仅仅是简单测试的概念1软件质量的度量
1.1软件的质量要素
1.2软件质量评价的准则
1.3软件质量的度量
1.4软件质量度量的实施
1.1软件的质量要素ISO9000的质量定义质量的定义反映实体满足明确和隐含需要能力的特性综合定义的说明明确需要指合同中用户明确提出的要求与需要隐含需要指由生产企业通过市场调研进行识别与探明的要求或需要质量与等级的关系等级的含义是对功能用途相同、但技术特性不同的存在事务的一种分类或排序例如高质量——无错误、可读性强的用户手册低等级——有限的功能低质量——错误百出、编排混乱的用户手册高等级——大量功能确定质量和等级标准水平,是项目经理的责任软件项目质量的要素传统的《软件工程》教材中(张海潘)在全书的最后一章《管理技术》中,有一节介绍“质量保证(P290)”定义了软件质量的因素(13项)概括为三个方面产品修改、产品转移、产品运行具体包括正确性、健壮性、效率、完整(安全)性、可用性、风险、可理解性、可维修性、灵活(适应)性、可测试性、可移植性、可再用性、互运行性质量的要素讨论软件的质量定义,一般地从4个角度来看,即用户的角度开发商的角度产品的角度价值的角度美国的B.W.Boehm和R.Brown先后提出了三层次的评价度量模型软件质量要素、准则、度量随后G.Mruine提出了自己的软件质量度量SQM技术,波音公司在软件开发过程中采用了SQM技术,日本的NEC公司也提出了自己的SQM工具,即SQMAT,并且在成本控制和进度安排方面取得了良好的效果IEEE标准1061-1998以表格的形式,定义了有关确认和收集与软件质量需求有关一个模型,或称为一个框架IEEE定义的软件质量度量框架IEEE定义的软件质量度量框架度量框架一种用来组织、选择、沟通、评价软件系统要求的质量属性的辅助决策法它逐层分解为特性、子特性和度量质量特性一个与质量有关的面向管理的软件属性质量子特性质量特性分解出来的技术组件直接度量一种不依赖与任何其他属性测量的度量预计度量一种试用于开发阶段的度量,它用来预计软件质量特性的值软件质量度量一个函数、它的输入是软件数据,输出是一个单一数值它可解释为给定的软件属性对其质量的影响程度过程质量一种用来测量在软件系统开发、实现和维护过程中使用的方法、技术和工具特性的度量产品度量一种用来测量软件开发过程中任何中间或最终产品特性的度量
1.2软件质量评价准则McCall选择的软件质量要素评价准则共21种,它们是
(1)可审查性auditability检查软件需求、规格说明、标准、过程、指令、代码与合同是否一致的难易程度
(2)准确性accuracy计算和控制的精度,是对无误差程序的一种定量估计最好表示成相对误差的函数值越大表示精度越高
(3)通信通用性communicationcommonality使用标准接口、协议、规范的程序
(4)完全性completeness所需功能完全实现的程度
(5)简明性conciseness程序源代码的紧凑与简洁性
(6)一致性consistency设计文档与系统实现的一致性
(7)数据通用性datacommonality在程序中使用标准的数据结构和类型
(8)容错性error-tolerance系统在各种异常条件下提供继续操作的能力
(9)执行效率executionEfficiency程序运行效率
(10)可扩充性expandability能够对结构设计、数据设计和过程设计进行扩充的程度
(11)通用性generality程序部件潜在的应用范围的广泛性,即部件可重用
(12)硬件独立性hardwareindependence软件同支持他运行的硬件系统不相关的程度
(13)检测性instrumentation监视程序的运行,一旦发生错误时,能明确地标识错误的程度
(14)模块化modularity程序部件的功能独立性
(15)可操作性operability操作一个软件的难易程度
(16)安全性security控制或保护程序和数据不受破坏的机制,以防止程序和数据受到意外的或蓄意的存取、使用、修改、毁坏或泄密
(17)自文档化sdlf-documentation源代码提供有意义文档的程度
(18)简单性simplicity理解程序的难易程度
(19)软件系统独立性softwaresystemindependence程序与非标准的程序设计语言特征、操作系统特征以及其他环境约束无关的程度
(20)可追踪性reacebility从设计表示或实际程序构件,追踪到需求的能力
(21)易培训性training软件支持新用户使用该系统的能力1985年,国际标准化组织(ISO)建议,软件质量度量模型由三层组成高层称软件质量需求评价准则(SQRC),中层称软件质量设计评价准则(SQDC),低层称软件质量度量评价准则(SQMC)分别对应McCall等人的要素、评价准则和度量ISO认为应对高层和中层建立国际标准,以便在国际范围内推广应用软件质量管理,而低层可由各使用单位自行制定ISO高层由8个要素组成、中层由23个评价准则组成高层的8个要素为左表的行,中层的23个准则为下表的列它们之间的关系如左表所示
1.3软件质量的度量——四层模型四层模型质量需求层+质量特性+子质量特性+度量在四层模型的第一层,软件产品质量层,是产品必须满足的质量需求它是用用户术语描述的,主要有四点
(1)产品将在用户所在组织当前使用的平台和操作系统上运行
(2)产品将是可靠的并能防止数据丢失的机制
(3)产品将提供完成某些任务所必需的功能
(4)产品将易于使用第二层质量特性在模型的第二层,表示与整个质量需求有关的特殊质量特性,它代表了用户的质量需求它采用从用户角度考虑的立场,把软件质量分解成四类质量特性,这四个质量特性是软件的基本特征质量特性IEEE的四个质量特性是可移植性、可靠性、功能性、可使用性
(1)功能性软件所实现的功能满足用户需求的程度.功能性反映了所开发的软件满足用户指明的或隐含的需求的程度,即用户要求的功能是否全部实现了
(2)可靠性在规定的时间和条件下,软件所能维持其性能水平的程度可靠性对某些软件是重要的质量要求,它除了反映软件满足用户需求正常运行的程度,且反映了在故障发生时能继续运行的程度
(3)易使用性对于一个软件,用户学习、操作、准备输入和理解输出时,所做努力的程度易使用性反映了与用户的友善性,即用户在使用本软件时是否方便
(4)系统效率在指定的条件下,用软件实现某种功能所需的计算机资源(包括时间)的有效程度效率反映了在完成功能要求时,有没有浪费资源,此外“资源”这个术语有比较广泛的含义,它包括了内存、外存的使用,通道能力及处理时间的占用等等
(5)可维护性在一个可运行软件中,为了满足用户需求、环境改变或软件错误发生时,进行相应修改所做的努力程度可维护性反映了在用户需求改变或软件环境发生变更时,对软件系统进行相应修改的容易程度一个易于维护的软件系统也是一个易理解、易测试和易修改的软件,以便纠正或增加新的功能,或允许在不同软件环境之间的易于操作
(6)可移植性从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度
1.4软件质量度量的实施在确定要对一个软件(系统)进行度量之后,一般,采取以下5个步骤,来实施对该软件的度量
(1)确定软件质量需求;在用户需求中,除功能需求外,还有非功能需求,包括质量需求、环境需求、设计约束、开发策略等质量需求是用户比较关心的内容但是,我们已经知道,软件的功能需求的确定,存在一定的难度而非功能需求的确定,则难度更大这些困难包括需求如何获取,需求冲突如何协调、需求的确认和变更的授权等过程需求获取首先,你要理解用户的需求,区分哪些是质量需求,把这些需求记录下来,获得用户的确认需求分析拿到用户确认的需求后,你可以开始把用户的质量需求与我们设定的质量特性联系起来,一直区分到子特性这种联系,就是把用户语言描述的需求,转变为计算机工程师语言的需求建立了这种关联后,可以根据分类,分级,确定直接度量
(2)确定直接度量直接度量就是实际的软件质量测量活动,它的输入是软件或软件过程,输出是一个测量值它通过执行一系列的任务,获得一个质量值例如易理解性度量对一个没有经过培训的用户,让他使用软件系统的某一功能,在界面提示、联机帮助、使用手册的帮助下,他学会掌握该功能所花的时间而用户需求对此项指标的要求(目标)和现实系统所达到的实际值(比如10个人次测量后统计意义上的)的比较,就是将提交质量评审的质量值在进行直接度量前,你应该有以下准备
(1)工具有助于计算度量值的硬件/软件工具,如缺陷跟踪工具;
(2)应用描述度量结果的希望值、度量值的意义、作用和对度量结果数据的使用方法;
(3)数据获得度量结果所需的数据、程序、过程等度量对象;
(4)计算度量程序、步骤和方法
(5)费用测试是要花钱(人力、物力、时间等)的
(3)分析度量结果对度量过程进行跟踪和分析,需要时,可能会对度量程序、度量工具、度量方法,甚至原始数据,做出补充和调整
(4)确认质量度量在度量过程中,进行度量结果的确认非常重要首先,要确认度量过程是否与事实相符,脱离现实真实的度量,与目标再相符的结果也是没有意义的其次,是确认方法的有效性,例如在度量中,我们用到很多统计学方法,在这些方法中,我们有一些概率分布假设(例如某些错误的发生,我们假设符合随机概率分布),当这些假设并不成立时,度量的结果是不真实的其他度量分析模型的度量(对分析模型的度量以测试系统的大小)•设计模型的度量(度量体系结构、数据和系统的复杂度)•源代码的度量(度量程序的长度、层次、开发量、时间等)•对测试的度量(度量测试的宽度、深度、错误的级别)•对维护的度量(度量软件的稳定性)2软件确认
2.1测试阶段
2.2测试方法
2.3测试类型
2.4测试计划软件确认与验证的概念软件的确认(Validation)与验证(Verification)简称为V&V或V2,是软件产品质量度量的具体方法确认(Validation)是这样一个过程它评价“在软件开发过程期间(针对单元)或结束(针对系统)时,单元或系统是否满足用户特定的需求”换句话说,是开发结束期间确认,我们的产品符合用户要求吗?因此,确认的是产品质量确认活动围绕三个基本过程来开展测试度量软件可靠性增长验证(Verification)是这样一个过程它评价“在一个给定的开发阶段中,单元或系统是否满足在此阶段开始时确定的条件”因此,它的意思是,我们正在制作的产品符合用户要求吗?因此,验证的是产品开发过程质量——工作质量验证活动也是围绕三个基本过程来进行审查、度量配置管理
2.1测试阶段根据不同的软件生命周期定义,测试的阶段、方法和类型构成一个层次结构,如下图测试的V模式V模型中的过程从左到右,描述了基本的开发过程和测试行为V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系单元测试单元测试的内容主要是算法逻辑、数据定义的理解和使用、接口、各种CASE路径、边界条件、错误处理等单元测试的目的通常是:在开发环境中,程序设计工程师为了检查单元程序模块内部的逻辑、算法和数据处理结果的正确性等单元测试通常由负责编码的工程师自己在代码完成后测试,也有在项目组内,由工程师相互交叉测试调试与测试的最大的不同点是二者的目的和视角的区别调试包括查找BUG、定位BUG、修改并最终确认BUG已经被修复的软件故障排除过程测试是在一个相对独立的环境下(测试应尽可能地模拟运行环境,调试是在开发环境),运行系统单元,观察和记录运行结果,对结果进行独立评价的过程单元测试(模块测试)实际上,在单元测试级,一般项目组很难做到把调试与测试分开因为二者的工作内容比较接近,担负人常常是一个人,环境区别并不大或者重新搭建环境在时间、成本和人力上,都比较困难这些都是一般项目组并没有独立的单元测试的原因将单元测试与模块调试合并可能带来的问题是
(1)单元测试没有任何记录和文档少有笔头勤快的工程师,会把他每天测了什么、改了什么,记录下来软件工程师要的就是没有BUG的程序,任何中间结果都是垃圾
(2)由于调试的目标是获得没有故障的程序,因此,与功能无关的程序属性往往被忽略,或者要到集成测试、确认测试时才被发现例如命名标准、程序形式规范等不论怎么说,现实情况,单元测试与模块调试经常是混为一谈的,要想改变,也不太容易由于单元测试在项目组中,常常由编码工程师完成,项目经理的管理一般并不深入到单元测试层集成测试(子系统测试)集成测试又称组装测试,它是在单元测试完成后,组装为一个子系统后,对下列只有组装后才能发生和测试到的问题,进行检查
(1)组装后一个模块对一个模块的影响;
(2)合并功能是否是预期的;
(3)独立的误差在合并后的变化,是扩大还是减小,是否在可接受的范围内;
(4)实际的接口测试;包括模块之间对实际衔接的标准、时序(实时性)、应答响应、容错与错误处理等;
(5)模块间的资源竞争等集成测试也很重视集成的阶段性最坏的情况是系统只有一次集成,就是系统全部模块完成后进行集成实际上,这就像一部汽车,直到要出厂时,才来一次总测试而当你每天生产一部完全不同规格、型号的汽车时,这个时候的测试,可能是非常要命的比较好的办法是通常采用的增量组装法,包括自顶向下或自低向上的增量组装分阶段的增量组装测试,可以解决一次集成,问题的隔离和区分不易的困难确认测试(系统测试)确认测试的目的是按照与用户确认的软件需求规格说明书的要求,检查系统的需求实现确认需求的测试依据是需求阶段产生的测试脚本(测试用例)国内项目组的现实情况有以下几种
(1)没有确认测试;
(2)没有独立的确认测试,测试与设计、编码不分离;
(3)有独立的确认测试,但测试用例是设计和编码人员写的,因此,独立测试人员相当于按设计和编码人员的设计思路再测一遍上述这些情况,就丧失了确认测试的大部分意义正确的确认测试是独立的测试组中,具有相应知识的测试设计师,根据需求规格说明书,并依据该软件在用户方面将会是在什么环境下,用户将如何使用该软件,来设计测试方案和测试用例,安排测试人员进行测试很显然,现实离理想的距离还比较遥远确认测试还包括软件经修改后的再测试(回归测试)回归测试是对已测试并发现故障的部分,修改后进行再测试回归测试不应修改测试程序、测试内容或测试标准它与正常测试不同的仅是它可能并不需要再完整地走一遍所有的确认测试,而是小心地选择部分确认测试程序,选择的标准是不减低原标准的整体要求ɑ测试和ß测试为了实际检验软件的功能和性能,有时,常邀请特定的用户帮助试用(测试)系统正式发布前的版本,请用户对系统进行评价这就是通常所说的ɑ测试和ß测试ɑ测试是由一个用户在开发者的场所,在开发者指导下进行的测试开发者记录下问题和错误,是在开发者“控制”下的测试ß测试是用户的环境中,开发者可能并不在现场,由用户“活用”系统情况下的测试用户记录下问题,报告给开发者在商用套装软件中,这种情况比较多见,在行业应用系统中,由于现实环境并不允许不成功的软件直接投入使用,用户也没有参与测试义务、时间和资源的投入和配合的积极性,因此,这种测试很少发生验收测试在行业应用软件环境中,验收测试是项目过程非常重要的一环,也是项目经理非常关注的一项工作验收测试与确认测试非常相似,所不同的是,确认测试是项目组或组织内部的测试,验收测试是用户主导、现场参与、现场环境下的测试验收测试通常由项目组先提出测试大纲,定义测试目的、范围、方法、测试用例、预期结果、验收标准等经用户同意批准,可能包括用户的修改、增加后,确定测试时间,开始进入验收测试用户在完成按测试用例的测试后,在测试记录上逐条确认、签字,最后,在测试报告上签字,完成验收测试一般地、验收测试报告是项目初验、终验的依据和主要验收形式单元测试与验收测试单元测试和验收测试没有什么区别?单元测试可以类比为一个建筑的质检人员对建筑进行的检测,他关注的重点是建筑的内部结构、地基、框架以及墙壁是否垂直等他的检测是要保证建筑的各个部分是正常的、安全的,换句话说,就是要保证施工满足建筑上面的质量标准验收测试可以类比为建筑的使用者来对建筑进行的检测他关心建筑的外观是否美观、各个房间的大小是否合适,窗户的位置是否合适,是否能够满足家庭的需要等这里,建筑的使用者执行的就是验收测试,他是从用户的角度出发的正是这种角度的不同决定了单元测试和验收测试之间的区别它们是对系统的不同的方面进行的测试,二者是互相补充的不管我们在系统的构建中使用了多么聪明的方法,不管我们的系统是多么的灵活,但是首先我们的产品必须是可用的,否则我们所做的就是浪费时间,从这一点上来说验收测试要比单元测试显得更加重要
2.2测试方法测试所处的阶段不同,方法也不同白盒测试在单元测试阶段,由于测试者对被测对象的内部结构、逻辑思路、接口关系等比较熟悉,一般采取白盒测试的方法,它是根据模块的内部逻辑,进行测试设计的方法有些集成测试也采用白盒方法,关键看集成阶段的划分黑盒测试在集成测试以至此后的各阶段,测试设计和测试人员,对被测对象的内部结构不了解也不需要了解,他的目的是按需求功能进行确认因此,黑盒测试是严格按软件需求进行测试设计的方法代码走查
2.3测试类型在不同阶段,测试的类型也不相同,常有的测试类型是
(1)功能测试软件实现的功能是否符合需求规格说明书中定义的功能;
(2)性能测试软件在规定配置下的性能是否符合需求规定;
(3)算法测试确认实现的算法的正确性;
(4)正向测试按照用户正常的理解、操作方式、思维和使用习惯使用软件,得到的结果是否与需求一致
(5)逆向测试如果不按用户正常的理解、操作发生、思维和使用习惯使用软件,软件是否能正确地进行处理如无效操作、错误的数据输入处理、非法进入等
(6)边界测试按软件的限制、假设条件的边界输入,进行测试
(7)配置测试对软件环境进行配置变化,软件需求实现,特别是性能实现是否能符合需求规定要求
(8)负载测试在业务处理量、数据负载量、通讯负载量达到何种情况,系统的性能变化和承载能力情况
2.4测试计划测试估计在拟定测试计划时,首先需要对以下情况,做出估计
(1)完成测试设计所需要的工作量
(2)完成测试设计所需要的工作时间
(3)完成测试所需要的时间根据以上三个部分的结果,我们已经知道了测试的范围、内容、任务分配、时间等,这样,项目经理可以能比较充分地规划资源,制订出一份比较全面和切实的测试工作计划测试分配测试计划确定了测试的范围、内容和估计时间,根据WBS方法,测试计划还应说明具体测试任务的分解和测试工作的分配测试组的成员根据分工,各自完成一部分测试任务测试组与项目开发组还需要保持一定的同步,使测试与开发、修改在协调的步骤下进行,以节约宝贵的项目总时间测试确认测试报告收集齐上述的所有测试用例,构成了测试报告的基本要件测试报告是对所有测试用例测试过程的总结在测试报告中,应反映
(1)测试中出现问题的统计汇总和分析;
(2)未解决问题的汇总和解决方案建议;
(3)回归测试的统计和分析(度量);
(4)对测试计划的总结或修改
2.5测试过程组织以一个独立的测试小组为例,测试过程一般如下
(1)测试准备制定人员、环境、工具、培训和外部支持计划
(2)测试计划确定测试策略、建立测试计划
(3)测试用例建立测试顺序树、确定测试的优先级、详细列出测试程序和测试数据,设计测试用例
(4)测试环境了解需求、搭建环境、安装备份和恢复程序,记录初始环境、测试环境、恢复环境等
(5)测试执行从测试计划复审测试计划进度表、恢复测试执行环境
(6)结果分析执行结果分析、度量
(7)测试报告错误趋势图、测试变动指示、产品检查点建议3软件的验证
3.1审查准备
3.2审查过程
3.3需求审查
3.4设计审查
3.5代码审查
3.6测试审查软件审查的概念回顾我们在上节介绍软件的确认和验证过程时,已经介绍了软件验证的三个过程是审查、测量和配置管理同时,我们也谈到,验证与确认的区别是,确认是在整个软件系统完成交付前或某模块完成交付前的检查,它的检查点是交付前而验证贯穿于整个开发过程,是对过程的确认因此,验证的范围包括了整个开发过程,它是软件质量保证并持续改进的强大工具什么是审查,审查是一个正式的、严格的、具有深度的技术评审过程因此,评审的目的是
(1)在软件开发过程中,尽早可能地发现问题,特别是过程性的问题;
(2)确保对需求保持一致的意见;
(3)验证任何修改和变更满足预先定义的准则;
(4)为组织提供产品在质量和过程方面是否有效的实际数据;
(5)使团队成员之间在技术上建立相互的了解;
(6)增加软件确认测试的有效性;
(7)提高优秀软件工程师的水准
3.1软件审查的准备评审人审查一般由一个审查小组或审查委员会负责进行,审查小组内,应有以下角色构成
(1)主持审查活动的主审员;
(2)被审查产品的负责人,包括产品经理、技术经理、质量经理等;
(3)负责对被审查产品进行讲解和解释的主讲人;
(4)来自各有关部门的审查员;
(5)记录员;
(6)项目经理项目经理应该参与软件的审查过程,关注审查结果,但不一定要参加审查会议这要看审查的级别如果是组织内的项目级审查,项目经理作为被审查产品的负责人,应参加审查会议,否则,应该由具体的产品、技术或质量经理去参加这样的会议被审产品的负责人参加这样的会议,不是为了解释审查中发现的缺陷,及其责任,进行辩解,而只是如实地向审查小组介绍产品为什么要这样做,和做了什么审查的目的不是为了追究什么人的责任,而是为了改进过程如果把评审,引入到人与人之间的斗争中去,则完全丧失了评审,作为过程改进手段的意义评审内容及要求,见下表审查员的职责作为被审查对象的项目组,按照审查组的要求,提交被审查材料,接受审查作为审查员,应该做什么准备?首先,明确作为审查员的定角色位、职责审查员是那些具有相关知识和对被审查产品具有一定熟悉程度的,但不一定就是直接从事相同岗位(有时,还特别需要交叉换位)的人员在参加审查前,他必须花一定的时间和精力,来了解产品,并能通过阅读提交的资料,了解产品与文档、标准和规范之间的差异因此,他在审查中的责任是
(1)必须完全熟悉要审查的产品和产品所依据的文档和标准;
(2)对照产品和文档,鉴别其中的差异;
(3)客观地评价差异,识别是属于实现的程度差别、缺陷,还是错误;
(4)判断差异是实现的个体现象,还是过程问题;
(5)以对产品而不是对人的态度,对差异进行评估和分析;
(6)向主审员报告审查结果和分析意见
3.2软件审查的过程在审查开始之前,审查组与被审查项目的有关人员,产品经理、技术经理、质量经理和项目经理们开一个“审查开工会”,主审员向被审查对象的有关人员介绍本次审查的目的、对象、范围和内容,有必要的话,花一点时间介绍一下审查方法,使得审查员和被审查项目的有关人员,在审查过程中易于沟通和理解当被审查有关人员知道(不是同意)审查的主要内容后,主审员把审查工作,按分工,分配给各审查员,并请项目组指定有关的配合人员会议约定好完成分组审查的时间,即召开审查汇报会的时间获得审查资料的审查员,可以开始从看资料如手,进入审查阶段如果需要实际测试和运行检查,项目组要配合安排机器时间、软件演示等与操作有关的环境审查员经过一段时间的工作,已经对所分工的部分,通过阅读资料、实际查看等,获得了必要的信息,有关的疑问,通过向项目组实际询问,解释了不清楚的地方审查员对差异,已经做好了记录主审员按时间和进度,可以招集审查汇报会在审查汇报会上,审查员汇报分组审查中发现的潜在的(还没有定论)的错误、缺陷和差异审查小组对每一个问题进行讨论,并争取获得一致的意见必要时,可以请项目组再做解释记录员此时应详细记录讨论的过程和各自的意见,并确保这些记录的完整性、正确性和真实性如果一次会议不能解决争论的问题,或者需要再扩大参加人员的范围,或者需要再做测试,那就那样去做或者审查组发现问题已经非常严重,已经超出了软件评审的范围,那么,应立即停止评审,向有关上级报告问题,以便上级做出重大改进的措施审查结果的发布是一个非技术的敏感问题什么性质的结果可以发布,在多大范围内发布审查结果如果比较满意,它的发布将对项目组是一个正向的激励,是相关人员能力的象征负面的审查结果可能引来更大的争议和动荡因此,审查小组和项目经理,要充分沟通,从积极的方面,使用审查结果任何审查结果都不是针对个人的,但是任何工作都是由具体个人来负责和承担相应责任的因此,审查结果的难处,就在这句话的二面性
3.3需求审查需求审查过程我们在上一节,已经一般地讨论过审查的过程需求审查也遵循这样的过程组织审查组;收集项目组提交的被审查资料;确定审查日期;审查员在获得审查任务分配和开始工作,包括对资料的阅读和评审、做实地的检查、调查和询问、记录并报告;参加评审会议并报告自己的发现和分析审查小组首先检查审查活动是否充分和没有偏差、疏漏审查员对问题的认识有没有片面和主观主审员根据自己的经验,可能会对年轻的审查员要求做出补充调查通过讨论,审查小组争取对问题取得一致的意见,并形成审查报告追踪与改正审查的目的是监督项目组对软件的品质,保持良好的状态和不断地改进因此,审查小组有责任跟踪项目组对审查结果的利用情况关注项目组的改进,是项目经理比关注审查结果更重要的事情
3.4设计审查概要设计审查表(问题清单)详细设计审查表(问题清单)设计审查的目标概要设计重点审查以下几个方面(概要设计针对需求)
(1)概要设计对需求的完整实现;
(2)概要设计与需求的一致性;
(3)概要设计向需求的反向可追踪;
(4)概要设计中,对系统结构设计的逻辑性、合理性和可扩展性;由于概要设计是直接衔接需求的,因此,概要设计审查更多地是把设计与需求相衔接在详细设计中,应重点审查以下方面(详细设计针对实现)
(1)设计应符合组织即定的标准;
(2)设计结果对下一阶段的编码是可用的由于详细设计直接提供编码实现,因此,在组织内,应对详细设计的“粒度”做出规定这样,即明确详细设计与代码实现的界面,同时,也是编码标准化的工作基础在这方面,应结合实际,进行研究
3.5代码审查代码的审查与具体实现工具有关,而且与具体实现工具的版本有关,因此,我们在这里就不具体讨论代码审查的内容有不少文章具体讨论代码的标准化和设计技巧,可以作为审查的范本(如果必要的话)代码审查的一个办法是走查就是由审查人员“读”工程师写的代码,然后对照“标准”进行检查,是对软件文档的一种书面检查它通过人工模拟执行源程序的过程,检查软件设计的正确性人工模拟也像计算机执行那样,可以仔细推敲、校验和核实每一步的执行结果,进而确定其执行逻辑、控制模型、算法和使用参数与数据的正确性走查是一件非常艰苦的工作,同时是需要非常大的毅力和记忆力的工作因为一个系统程序量之大,组织的规则和要求之多审查员要做的是N的N次方的核对现在也有一些计算机程序,按一定的规则,帮助审查员“读”程序,并挑出(有的可以做简单的修改)毛病,VB就有这样的程序如果没有计算机程序的帮助,审查员会“疯”掉的
3.6测试审查测试审查是对测试结果进行审查,它审查的内容包括
(1)对测试用例的审查测试用例的哪些要素(用例名、测试日期、预期测试结果等)是否齐备?(宽度)
(2)在概要设计和详细设计中确定的关键点或特殊需求是否都测试到了?(深度)
(3)测试过程(步骤、环境、用户模拟等)的设计是否正确、恰当?
(4)预期值与结果值的差异统计;
(5)测试目的是否达到?4软件质量保证过程
4.1现代质量管理回顾
4.2ISO9000质量管理体系
4.3PMBOK的质量管理
4.4CMM2的质量保证
4.1现代质量管理回顾现代质量管理是对项目管理的补充现代质量管理在以下方面,做出更多的强调
(1)以客户满意为质量目标;
(2)比注重结果更多地注重过程;
(3)管理层对质量负有责任这些观点,是以下这些质量管理大师和前辈,在逐步总结质量管理经验的基础上,建立起来的现代质量管理戴明W.爱德华.戴明,以研究二战后有关质量控制方面的工作而闻名,戴明总结日本改良的经验,提出的管理14点——戴明技术,成为美国企业争先恐后向日本学习的象征戴明奖则象征着高质量组织的最高标志,戴明改进的PDCA循环(计划、执行、检查、处理或改进)为以后ISO体系的持续改进的基本架构朱兰朱兰也是从帮助日本制造企业提高产品质量,为美国企业所知晓朱兰1974年在《质量控制手册》中,特别强调了高层管理行为对连续的产品质量提高的重要性本书在1999年出版了15版,此时,朱兰已经是94岁高龄朱兰发明了“朱兰质量三部曲”,即质量提高、质量规划和质量控制朱兰改变了在质量标准中,是以制造商的关注产品规范还是以用户的更多地关注产品的适用性的争论,在现在大部分的有关质量的定义中,都使用试用性概念,以满足用户明确和隐含的需求为质量的目标朱兰提出了质量改进的10个步骤克鲁斯比克鲁斯比以提出组织向零缺陷努力而闻名他认为,低劣质量成本应包括没有做对这件事的所有成本,而不仅是某个环节例如废料、返工、失去的劳动时间和机器时间、失去的销售额和客户恶劣的印象等等克鲁斯比开发了提高质量的14个步骤石川磬石川磬在972年《质量控制指南》一书中,以首次应用鱼刺图提出质量圈的概念而闻名石川研究了日本企业质量管理和美国企业质量管理的情况,指出,日本企业的管理者和工人对质量都有不同的责任,类似全员的质量责任和全员的质量管理,而在美国,则将质量责任授权给少数人石川发明的鱼刺图,可以将在产品后端发现的有关质量问题,一直追溯到负有责任的生产行为,这样,从生产的源头,可以帮助产品找出质量原因,真正获得质量的改进和提高田口宏一田口宏一对质量管理的贡献是他发明的设计试验过程优化的田口宏一方法田口宏一方法的关键点是,质量在设计阶段,就应该被设计进产品而不是检查进产品,使取得良好质量的最好方法,是产品越接近完成,离质量的目标的偏差就越小这在软件设计中是非常不容易实现的美国施乐、福特、惠普等公司根据田口宏一方法,发明了“坚固设计方法”,通过用科学的查询方法,来取代试验法来消除缺陷菲根堡姆菲根堡姆1983年在他出版的《全面质量管理工程和管理》一书中,第一次提出了全面质量管理的概念他提出,产品的质量责任应该是做这个产品的人,产品质量比生产速度更重要ISO9000与马尔科姆-鲍威治奖ISO9000是一个由总部设在瑞士日内瓦的“国际标准化组织”开发的质量系统标准,该组织有100多个工业化国家参加,ISO9000是一个组织满足质量认证标准的最低要求而马尔科姆-鲍威治国家质量奖创立于1987年,是对在质量管理方面取得世界级竞争水平公司的承认田口宏一田口宏一对质量管理的贡献是他发明的设计试验过程优化的田口宏一方法田口宏一方法的关键点是,质量在设计阶段,就应该被设计进产品而不是检查进产品,使取得良好质量的最好方法,是产品越接近完成,离质量的目标的偏差就越小这在软件设计中是非常不容易实现的美国施乐、福特、惠普等公司根据田口宏一方法,发明了“坚固设计方法”,通过用科学的查询方法,来取代试验法来消除缺陷菲根堡姆菲根堡姆1983年在他出版的《全面质量管理工程和管理》一书中,第一次提出了全面质量管理的概念他提出,产品的质量责任应该是做这个产品的人,产品质量比生产速度更重要ISO9000与马尔科姆-鲍威治奖ISO9000是一个由总部设在瑞士日内瓦的“国际标准化组织”开发的质量系统标准,该组织有100多个工业化国家参加,ISO9000是一个组织满足质量认证标准的最低要求而马尔科姆-鲍威治国家质量奖创立于1987年,是对在质量管理方面取得世界级竞争水平公司的承认1987年发布的ISO9000系列国际化标准组织(ISO)于1979年成立了质量保证技术委员会(TC176),1987年更名为质量管理和质量保证技术委员会,负责制定质量管理和质量保证标准1987年发布了ISO9000系列ISO8402(质量--术语)ISO9000(质量管理和质量保证标准—选择和使用指南)ISO9001(质量体系—设计开发、生产、安装和服务的质量保证模式)ISO9002(质量体系—生产和安装的质量保证模式)ISO9003(质量体系—最终检验和实验的质量保证模式)ISO9004(质量管理和质量体系要素—指南)
4.3PMBOK的质量管理PMBOK是ProjectManagementBodyOfKnowledge的缩写,即项目管理知识体系,是美国项目管理协会(PMI)对项目管理所需的知识、技能和工具进行的概括性描述2004的PMBOK把项目管理划分为9个知识领域和44个管理过程;9个知识领域包括:4个核心知识领域,其中定义了17个过程4个辅助知识领域,其中定义了20个过程1个项目综合管理,其中定义了7个整体管理过程
4.4CMMI的质量保证过程CMMI全称是CapabilityMaturityModelIntegration即软件能力成熟度模型集成,是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的,其目的是帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力,从而能按时地、不超预算地开发出高质量的软件CMMI为改进一个组织的各种过程提供了一个单一的集成化框架,新的集成模型框架消除了各个模型的不一致性,减少了模型间的重复,增加透明度和理解,建立了一个自动的、可扩展的框架因而能够从总体上改进组织的质量和效率CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面CMMI分5个级别CMMILevel1,完成级偶然性企业对项目的目标与要做的努力很清晰,项目的目标得以实现但是由于任务的完成带有很大的偶然性,企业无法保证在实施同类项目的时候仍然能够完成任务企业在一级上的项目实施对实施人员有很大的依赖性CMMILevel2,管理级企业在项目实施上能够遵守既定的计划与流程,有资源准备,权责到人,对相关的项目实施人员有相应的培训,对整个流程有监测与控制,并与上级单位对项目与流程进行审查体现了对项目的一系列的管理程序这一系列的管理手段排除了企业在一级时完成任务的随机性,保证了企业的所有项目实施都会得到成功CMMILevel3,定义级在定义级水平上,企业不仅能够对项目的实施有一整套的管理措施,并保障项目的完成;而且,企业能够根据自身的特殊情况以及自己的标准流程,将这套管理体系与流程予以制度化这样,企业不仅能够在同类的项目上升到成功的实施,在不同类的项目上一样能够得到成功的实施科学的管理成为企业的一种文化,企业的组织财富CMMILevel4,量化管理级企业的项目管理不仅形成了一种制度,而且要实现数字化的管理对管理流程要做到量化与数字化通过量化技术来实现流程的稳定性,实现管理的精度,降低项目实施在质量上的波动CMMILevel5,优化级企业的项目管理达到了最高的境界企业不仅能够通过信息手段与数字化手段来实现对项目的管理,而且能够充分利用信息资料,对企业在项目实施的过程中可能出现的次品予以预防能够主动地改善流程,运用新技术,实现流程的优化第14讲软件能力成熟度模型CMM
1.1什么是软件过程?过程的基本概念过程就是人们使用相应的方法、规程、技术、工具等将原始材料(输入)转化成用户需要的产品过程的3个基本要素是人、方法与规程、技术与工具过程与产品存在因果关系即好的过程才能得到好的产品,而差的过程只会得到差的产品过程被文档化后才能成为规范软件过程研究的是如何将人员、技术和工具等组织起来,通过有效的管理手段,提高软件生产的效率,保证软件产品的质量
1.1软件项目成功的三要素-PPTPeople人Process过程Technology技术
1.2软件工程难题
1.2企业长期面临的软件工程难题产品质量低下、进度延误、费用超支…(软件工程学科发展30年尚未彻底解决)经典软件工程研究需求分析、系统设计、编程、测试、维护等领域的方法、技术和工具问题之源人们逐渐意识到,由于企业管理软件过程的能力比较弱,常常导致项目处于混乱状态过程混乱使得新技术、新工具的优势难以体现经典的软件工程不是不好,而是不够用用于提高软件过程能力的实践通称为软件过程改进
1.
3.软件过程改进概述什么是软件过程改进提高软件过程能力的实践通称为软件过程改进(SoftwareProcessImprovement)软件过程改进的根本目的是提高质量、提高生产率并且降低开发成本软件过程改进必须走规范化之路提高软件过程能力可以比喻为“练内功”,“练内功”没有捷径可走,唯有走“规范化”之路,即“制定适合于本企业的软件过程规范,并按照此规范执行”“规范化”不会抑止人们的创造力,相反地,它使得团队可以大规模地复用前人积累的智慧和财富这种方法非常适合于现代的工业化生产(麦当劳与中餐馆对比)业界实践已经证明,走“规范化”之路是“成本最低、见效最快、能持续发展”的软件过程改进方法,犹如人类的“养生之道”任何IT企业(不论大小),都有办法以其承受得起的代价“走规范化之路”,从而有效地提高软件过程能力2软件过程的三个流派CMU-SEI的CMM/PSP/TSPISO9000质量标准体系ISO/IEC15504(SPICE)
2.1CMU-SEI的CMM/PSP/TSP从20世纪90年代至今,软件过程改进成为软件工程学科的一个主流研究方向,其中CMM和CMMI是该领域举世瞩目的重大成果CMM/PSP/TSP即软件能力成熟度模型/个体软件过程/群组软件过程是1987年美国CarnegieMellon大学软件工程研究所CMU/SEI以W.S.Humphrey为首的研究组发表的研究成果承制方软件工程能力的评估方法“
2.2ISO9000质量标准体系ISO9000质量标准体系是在70年代由欧洲首先采用的,其后在美国和世界其他地区也迅速地发展起来目前ISO9000软件标准系列ISO
9001、ISO9000-
3、ISO9004-
2、ISO9004-
4、ISO
90022.3ISO/IEC15504(SPICE)SO/IEC15504(SPICE)是1991年国际标准化组织采纳了一项动议,开展调查研究,按照CMU-SEI的基本思路,产生的技术报告ISO/IEC15504--信息技术软件过程评估3CMM概述/CMM外部特性
3.
1.CMM发展简史
3.2CMM外部特性五个级别18个关键过程域
3.
1.CMM发展简史CMM是什么CMM(CapabilityMaturityModel)是用于衡量软件过程能力的事实上的标准,同时也是目前软件过程改进最好的参考标准美国卡内基-梅隆大学软件工程研究所(SEI)研制发展简史CMM
1.0于1991年制定CMM
1.1于1993发布,该版本应用最广泛CMM
2.0草案于1997年制定(未广泛应用)到2000年,CMM演化成为CMMI(CapabilityMaturityModelIntegration),CMM
2.0成为CMMI
1.0的主要组成部分CMMI-SE/SW
1.1(CMMIforSystemEngineeringandSoftwareEngineering)于2002年1月正式推出
3.2CMM五个级别初始级(有纪律的过程)可重复级(标准一致的过程)已定义级(可预测的过程)已定量管理级(持续改进的过程)持续优化级
3.4CMM的18个关键过程域软件过程分为三类管理过程|组织过程|工程过程级别优化级|技术更新管理|缺陷防范|过程更新管理已管理级定量过程管理||软件质量管理已定义级集成软件管理、组间协调|组织过程焦点、组织过程定义、培训大纲|软件产品工程、同行评审可重复级需求管理、软件项目计划软件项目跟踪与监督、软件子合同管理、软件质量保证、软件配置管理||初始级无需过程||
3.
5.CMM等级评估过程复杂每一个CMM等级评估周期(从准备到完成)约需12-30个月每一级别的评估由SEI授权的主任评估师领导一个评审小组进行,其成员大部分来自企业内部评估过程包括员工培训(企业的高层领导也要参加)、问卷填写和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等评估结束由主任评估师签字生效(没有盖上公章的证书)取得主任评估师的资格比较困难10年以上的软件开发经验在SEI接受培训,培训费用每人约需数万美元,非美国人加倍经过两次以上CMM评估的全过程实习主任评估师的资格并非终身制评估费用昂贵大约是ISO认证的十倍价格视客户需求的多少而定,可以与咨询公司协商参考价CMM2级50万元RMB,CMM3级80万元RMB4CMM2级的6个KPA2级CMM共有6个KPA,主要涉及建立基本项目管理和控制方面的内容需求管理软件项目计划软件项目跟踪与监督软件子合同管理软件质量保证软件配置管理
4.1KPA
2.1需求管理需求管理RMRequirementsManagement在顾客和顾客要求的软件项目之间建立一种一致的、共同的理解,控制系统对软件的需求,为软件工程和管理建立基线,保持软件计划、产品和活动与分配需求的一致性共同理解是计划和管理软件项目的基础,所以需求管理要求需求文档化,并对需求进行评审在整个软件生命周期中,当用户需求改变时,记录全部改变,并进行评审
4.2KPA
2.2软件项目计划SPPSDPSoftwareProjectPlanningSoftwareDevelopmentPlanning为实施软件工程和管理软件项目制订合理计划SPP包括:估计软件产品的规模和所需资源,制定开发进度计划,确定并评估风险,协商有关约定在SPP执行过程中,记录并维护SPP,严格按照SPP实施软件项目
4.3KPA
2.3软件项目跟踪与监控SPTO(SoftwareProjectTrackingandOversight)对软件项目的执行进行跟踪、监督与控制,以便随时掌握软件项目的实际开发过程当项目的执行活动与软件项目计划SPP偏离时,项目经理能够采取有效的措施进行处理管理活动包括按计划对软件完成情况和结果进行跟踪和评审,必要时进行纠正纠正活动包括修订软件开发计划以反映项目的实际完成情况,重新计划剩余的工作,并采取适当的措施改进
4.4KPA
2.4软件子合同管理SSMSoftwareSubcontractManagement选择高质量的软件子项目承包者,并对子合同的执行进行有效的管理选择合适的子项目承包者,并对其进行过程监督
4.5KPA
2.5软件质量保证SQASoftwareQualityAssurance对软件项目和产品质量进行监督和控制,为管理者监控软件项目的过程和产品质量提供适度的可视性通过评审和审核软件产品和活动,验证是其否与应用的标准和规程一致出现的问题尽可能在软件项目组内部解决内部不能解决的问题,由质量保证组进行适当的解决
4.6KPA
2.6软件配置管理SCMSoftwareConfigurationManagement保证软件项目生产的产品在软件生命周期中的完整性软件配置软件工作产品及技术文档通过在给定时间点上软件的配置,系统地控制配置的更改,维护在整个软件生命周期中配置的完整性和可跟踪性,得到具有完整性的软件工作产品和软件产品5CMM3级的KPA3级CMM在2级的基础上增加了七个KPA,既包括项目管理问题,又包括组织问题和工程问题软件组织建立了一个基础设施,对项目中所有有效的软件工程和管理过程的实施制度化
5.1KPA
3.1组织过程焦点OPFOrganizationProcessFocus软件组织建立负责软件过程活动的责任和机制为改进软件组织的整体软件过程能力提供组织上的保证如设定职位,指定专人或小组负责软件过程能力的监管
5.2KPA
3.2组织过程定义OPDOPD(OrganizationProcessDefinition)由负责软件过程活动的小组开发和维护一组能提高项目软件过程整体效能的软件过程资源的集合,并为在定量过程管理中确定有意义的数据提供基础过程定义产生了企业标准软件过程及相关过程资源例如对软件生命周期的描述企业软件过程数据库软件过程的相关文档库
5.3KPA
3.3培训大纲TPTrainingProgram为提高个人的技能和知识进行培训,使其更有效地完成任
5.4KPA
3.4集成软件管理ISMISM(IntegratedSoftwareManagement)协调软件工程活动和软件管理活动,将二者集成为密切相关、定义完整的软件过程ISM是在2级CMM的软件项目计划SPP和软件项目跟踪与监控SPTO的基础上发展起来的,主要包括软件组织的标准软件过程及与之相关的操作
5.5KPA
3.5软件产品工程SPESPE(SoftwareProductEngineering)协调一致地执行经过定义并综合了所有软件工程活动的工程过程,以便高效地生产出稳定的软件产品SPE的任务分析分配给软件的系统需求、制定软件需求、开发软件体系结构、设计软件、编码、测试、集成等,检验其是否满足分配需求
5.6KPA
3.6组间协调ICIC(IntergroupCoordination)开发软件项目的各小组积极合作,以便使项目更好、更有效地满足用户需求一个软件项目一般要设置若干个小组例如,软件工程组、软件估计组、系统测试组、软件质量保证组、软件配置管理组、合同管理组、文档支持组等)这些小组只有通力协作、互相支持,才能使项目在各方面都能更好地满足客户的需要,因此,各工作组之间必须很好地协作
5.7KPA
3.7同行评审PRPR(PeerReviews)由同一级别的其他人员对该软件项目产品系统地检测,以便能较早地和有效地发现软件产品中存在的错误,并改正它们PR的目的是尽早和高效地除去软件工作产品中的缺陷,增强对软件工作产品和可预防的缺陷的了解PR是一种重要而又有效的工程方法,例如,可通过排查、审查或者其它评审方法来实施6CMM4级的KPACMM4级在3级的基础上增加了两个KPA,关注焦点是建立起对软件过程和产生的软件产品的定量理解
6.1KPA
4.1量化过程管理QPMQPM(QuantitativeProcessManagement)在软件项目过程中的各个阶段进行定量控制QPM的目的是定量地控制软件项目的过程性能在一个可测量的稳定的过程范围内鉴别出变化的特殊原因,并且适时改正促使变化出现的环境QPM为组织过程定义、集成软件管理、组间协调和同行评审的实践增加一个内容丰富的测量计划
6.2KPA
4.2软件质量管理SQMSoftwareQualityManagement定量地评价软件产品的质量,实现具体的质量目标SQM包括确定软件产品的质量目标,制定实现这些目标的计划,监控及调整软件计划、软件工作产品、活动和质量目标,以满足客户和最终用户对高质量产品的需要和期望7CMM5级的KPACMM5级在4级的基础上增加了3个KPA,关注的焦点是为了实施连续不断的和可测量软件过程改进组织和项目所必须解决的问题
7.1KPA
5.1缺陷防范DPDP(DefectPrevention)在软件过程中能识别出产品产生缺陷的原因,并采取防范措施,防止它们再次发生为了能识别缺陷,一方面要分析以前所遇到的问题和隐患,另一方面要对各种可能出现缺陷的情况加以分析和跟踪,从中找出可能出现缺陷和复发缺陷的类型,并对缺陷产生的根本原因进行确认同时对未来的活动预测可能产生的错误趋势
7.2KPA
5.2技术革新管理TCMTCM(TechnologyChangeManagement)确定新技术包括工具、方法和过程,将其有序地引入到组织的各种软件过程中去同时,对由此引起的各种标准变化例如,组织的标准软件过程,项目定义软件过程等进行处理,使之适应新的需要技术改革管理关注的焦点是在不断变化的环境里高效率地进行创新
7.3KPA
5.3过程变更管理PCMPCM(ProcessChangeManagement)不断改进组织的软件过程,提高生产率和软件质量,缩短软件产品开发周期PCM的目的是改进软件质量、提高生产率和缩短产品开发周期只有持续不断地改进组织中所采用的软件过程才能实现这一目标PCM既采用缺陷预防的增量式改进,又采用技术改革管理的创新式改进,并使得整个组织可以共享这些改进的成果PCM活动包括定义过程改进目标不断地改进和完善组织的标准软件过程和项目定义软件过程,制定培训和激励的计划,促使组织中的每个人都能自觉地参与过程改进活动8CMM的内部结构与公共特性
8.1CMM的公共特性每个成熟度级别表明一组过程能力过程能力ProcessCapability遵循某个软件过程后,可能实现的预期结果的程度关键过程域KPA,KeyProcessArea一组相关活动,达到一组目标目标Goal某个KPA中的KP所表示的范围、边界和意图每个KPA有若干个目标公共特性CommonFeatures指出了一个KPA的实现范围、结构要求和实施内容关键实践KPKeyProcess描述对KPA的有效实施和制度化起最重要作用的基础设施和活动
8.1KPA的公共特性CommonFeatures公共特性规定了一些关键实践,实现了这些关键实践后,就实现KPA的目标公共特性是一种属性,它能指示一个KPA的实施和规范化是不是有效的、可重复的和持久的每个KPA都具有的五种公共特性执行约定执行能力执行活动测量和分析验证实施
8.2执行约定CommitmenttoPerform描述软件组织为确保建立并持续执行软件过程,所必须采取的措施,主要包括制定组织策略和构建领导体制等
1.策略陈述项目为实施KPA中的实践必须遵循书面的组织管理策略,以便使组织约定制度在项目实施中能得到落实
2.领导体制有些KPA中的执行约定包括指定领导的职责及组织保证
8.3执行能力AbilitytoPerform描述了项目或组织能成功地执行软件过程所必须满足的前提条件,通常包括组织机构、资源及资金、培训和前提
1.组织机构某些KPA中包括专门为支持该KPA所建立的组织机构例如,软件质量保证组SQA、软件配置管理组SCM、软件工程过程组SEPG等
2.资源和资金资源和资金包括三部分技术KPA可能涉及到的专业技术资金实际可供使用的资金(不是预算资金)工具KPA可以使用的工具,通过实例给出活动可能使用的工具
8.3执行能力AbilitytoPerform(续)
3.培训包括正式培训和非正式培训,其目的是向组织的相关人员传授知识和技能培训方式主要有课堂教学培训、电视教学、CAI教学、师付带徒弟、定向培训(传授一般技能或知识)分级培训别2级CMM强调“接受培训”,指一般培训;3级CMM强调“接受所需的培训”,指高级培训
4.前提前提是指前一个KPA的输出结果,实施本KPA的条件是“前提”应完成,并以此前提的结果作为本KPA的输入
8.4执行活动ActivitiesPerformed软件组织执行一个KPA时所必需执行的活动、任务、职责分配和规程,包括制定计划和规程、实施工作、跟踪,并在必要时采取正确的措施
1.计划制定和修订正式计划:1依据书面规程制定和修订;2必须依照计划执行;3经过高级经理的批准例如软件开发计划、软件质量保证计划、软件配置计划等非正式计划作为正规计划的一部分记入文档,或正规计划的补充例如同行评审计划、风险管理计划、技术管理计划等
8.4执行活动ActivitiesPerformedII
2.计划实施大多数KPA都有一个或若干个关键实践KP描述按照书面规程实施的活动全面实施文档化负责一项任务或活动的人员必须按照书面规程来实施活动,以便使工作能重复,使对该领域有一般知识的人也能以同样的方式学习或完成这些任务和活动,并取得满意的结果
3.跟踪并采取正确的措施与管理对执行的活动进行跟踪,并进行管理和控制CMM2级使用术语“跟踪……并适当采取正确的措施”,没有严格定义,其管理活动仍是“反应式”的CMM3级使用术语“管理……”,有严格的定义,其管理不仅能预计问题的发生,也能阻止问题的发生
8.5测量和分析MeasurementandAnalysis描述测量的基本规则,以便确定、控制和改进软件过程的状态包括培训大纲的质量管理的有效性软件产品的功能和质量
8.6验证执行VerifyingImplementation为保证所实施的活动是否遵循了已制订的软件过程步骤,对实施活动通过管理和软件质量保证进行评审和监督活动
1.高级经理定期审查定期评审的目的是适时地掌握软件过程活动,以便采取适当的措施
2.项目经理定期或不定期评审和监督根据项目的具体情况,在不同阶段进行评审,以便了解项目的工作情况,清楚软件项目中发生的重要事件,比高级经理审查监督更详细更具体
3.软件质量保证活动由软件质量保证小组SQA进行评审或审核活动若SQA不起作用,就无法实现SQA验证活动9CMM的关键实践(KeyPractices)每个KPA有一组目标和一组公共特性每一个公共特性用一组关键实践KP来描述KP描述对关键过程区域的有效实施和规范化的基础设施和活动
10.6CMM通过内部结构特性CMM通过内部结构的规范,使软件组织能够制定方针、政策、标准,并参照自身的特点来建立软件过程,以提高软件过程成熟度这些建设性的活动对软件组织开展业务、进行实践工作、改进过程的基本环境和企业文化起到了极大的支持作用在这样的组织中,一旦组织内的人员发生变化,组织内部开展的各项活动仍然可延续下去第15讲软件过程与能力成熟度模型—CMMI软件工程CMM的成功启发其它学科领域也开发类似的改进模型,从而衍生出多种CMM,如
(1)SW-CMMSoftwareCMM软件CMM
(2)SE-CMMSystemEngineeringCMM系统工程CMM
(3)SA-CMMSoftwareAcquisitionCMM软件采购CMM
(4)IPT-CMMIntegratedProductTeamCMM集成产品群组CMM
(5)IPPD-CMMIntegratedProductandProcessDevelopmentCMM集成产品群组CMM
(6)P-CMMPeopleCMM人力资源能力成熟度模型同一个组织可能采用多种过程改进模型,因而带来一些问题不同改进模型衍生CMM有一些对相同事物说法不一致,或活动不协调,甚至相抵触要进行一些重复的培训、评估和改进活动,因而增加了许多成本;不能集中其不同过程改进的能力以取得更大成绩;美国国防部要求SEI开发CMMI就是要解决上述问题,其具体目标是建立一个自动、可扩展框架,通过它集成已有的及将来待发展的各种能力成熟度模型消除各个模型之间的不一致性、减少重复增加透明性和可理解性从总体上改进组织的效率,提高产品和服务的开发、获取和维护能力CMMI全称为CapabilityMaturityModelIntegration,即能力成熟度模型集成CMMI模型为过程改进提供了一个结构化的描述.CMMI能帮助建立过程改进目标和次序为质量过程提供了指南为评估当前实践提供一个准绳CMMI由三个基本成熟度模型为基础综合形成
(1)SW-CMM软件CMM
(2)SE-CMM系统工程CMM
(3)IPPD-CMM集成产品群组CMM,它主要面向并行工程
(4)经常还会引入外购协作CMM作为CMMI第4个模型源,即SS-CMM具体实践不同组织可根据需要选择CMMI模块,也可同时选择多个模块例如纯软件企业可以选择CMMI中的软件工程模块,设备制造企业可以选择系统工程和外购模块,集成企业可以选择软件工程、系统工程和集成产品和过程开发CMMI与CMM不同,它不但提出了软件能力成熟度模型,还提出了软件过程能力等级CapabilityLevelCL模型它显示一个组织在实施控制其过程,以及改善其过程性能等方面所具备、或设计的能力过程能力等级包含某个过程若干相关的特定实践,共性实践好处是执行这些实践,该组织的过程执行能力就能得到提高;进而增强该组织的总体过程能力着眼点是使软件组织走向成熟,以增强实施和控制软件过程的能力,改善过程本身的性能,这些能力等级有助于软件组织在改进各个相关跟踪、评价和验证中项改进过程一个组织可以从以下两种过程改进的方法中选择其一:组织成熟度,过程域能力CMMI对不同过程改进方法采用不同表示法组织成熟度-分级阶梯式表示法,过程域能力-连续表示法分级表示法规定了一系列已经证明的改进措施每一级都是其上一级的基础服务于上一级,运用成熟度等级使得组织之间的比较成为可能,组织成熟度体现于一组过程域.连续表示法允许选择改进的次序使其最适合组织的商业目标减少组织的风险,以过程域为基础使得组织之间可以在同一过程域内进行比较,提供一个简便的由EIA/IS-731转换至CMMI的方式比较这不同的表示法两种表示法都提供了执行过程改进达到组织目标的方法;两种表示法提供的实质内容是相同的只不过是内容的组织方式不同而已.过程域能力和组织成熟度的关系过程域能力和组织成熟度具有相似的概念二者的区别是过程域能力只与单一的过程域或实践相关;而组织成熟度包含一组既定的过程域一般来说如果一组过程已被评估确认达到某个成熟度等级那么这些被评估的过程会对应相关的过程域能力水平在连续型模型中,每个过程域都被分为6个能力等级,其特征如下表所示CL0不完备级Incomplete,CL1已执行Performed,CL2已管理Managed,CL3已定义Defined,CL4量化管理QuantitativelyManaged,CL5优化OptimizingCL0不完备级过程未执行或执行不完整,特定目标中有不完整的部分CL1已执行级特定目标都能满足,基本活动都得到执行CL2已管理级过程除了得执行,还需要按照计划和组织方针来进行实施;相关的人员得到与执行有关的培训;为了过程的执行分配了相关的资源;生成的工作产品收到控制;利益相关的方面都参与了过程的执行,并且进行了相关的评审以及过程符合度的验证;管理层关心过程的制度化状况和过程的其他目标,例如成本、日程和质量目标CL3已定义级在已管理的过程基础上,还具有如下特征该过程是组织的标准过程裁减得来的,裁减的依据是组织的裁减指南;该过程还向组织的过程资产库贡献关于工作产品、度量数据以及其他的过程改进信息CL4量化管理在已定义基础上,还具有如下特征过程是使用统计的以及其他量化管理的手段来进行管理的;在过程管理中使用了量化管理的质量和过程性能指标作为管理的标准;用统计手段来理解质量和过程性能,并且在整个生命周期内进行管理CL5优化优化的过程除了是一个量化管理的过程之外,还具有如下的特征过程能够及时的变更或采用来满足当前的或预期的业务目标;优化的过程聚焦于使用增量的和创新技术进步手段来达到不断改进过程性能的目的;过程偏差的根本原因得到识别,并且针对这些原因进行采取相应的改进措施;这些措施按照能够度量的方式被识别、评价和实施;这些改进过程的选择是基于对组织量化过程的理解,以及这些改进措施的预期收益、成本以及影响程度;优化过程的性能能够不断提高CMMI与其CMM的异同CMMI有两种表述方式,阶段表述方式与CMM兼容,连续表述方式与ISO/IEC15504相似CMMI的新特性
①CMMI模型中比CMM进一步强化了对需求的重视在CMM中,关于需求只有需求管理这一个关键过程域,也就是说,强调对有质量的需求进行管理,而如何获取需求则没有提出明确的要求;在CMMI的阶段模型中,3级有一个独立的关键过程域叫做需求开发,提出了对如何获取优秀的需求的要求和方法
②CMMI模型对工程活动进行了一定的强化在CMM中,只有3级中的软件产品工程和同行评审两个关键过程域是与工程过程密切相关的;在CMMI中,则将需求开发,验证,确认,技术解决方案,产品集成这些工程过程活动都作为单独的关键过程域进行了要求,从而在实践上提出了对工程的更高要求和更具体的指导
③CMMI中还强调了风险管理在CMM中把风险的管理分散在项目计划和项目跟踪与监控中进行要求;CMMI3级里单独提出了一个独立的关键过程域叫做风险管理
④保留了CMM阶段式模式的基础
⑤增加了连续式模型可以帮助组织其客户更加客观和全面的了解它的过程成熟度;可以给组织在进行过程改进的时候带来更大的自主性;不用再象CMM中一样,受到等级的严格限制;这种改进的好处是灵活性和客观性强,弱点在于若缺乏指导,一个组织可能缺乏对关键过程域之间依赖关系的正确理解而片面的实施过程,造成一些过程成为空中楼阁,缺少其他过程的支撑;两种表现方式(连续的和阶段的)从他们所涵盖的过程区域上来说并没有不同,不同的是过程区域的组织方式以及对成熟度(能力)级别的判断方式CMM有次序的、基于活动的度量方法与管理规范;与瀑布过程的有非常密切的联系,更适合瀑布型的开发过程CMMI相对CMM更一步支持迭代开发过程;支持经济动机推动组织采用基于结果的方法;虽然CMMI保留了基于活动的方法,它集成了软件产业内很多现代的最好的实践,但淡化了与瀑布思想的联系CMMI评估方试自我评估用于本企业领导层评价公司自身的软件能力;主任评估使本企业领导层评价公司自身的软件能力,向外宣布自己企业的软件能力CMMI的评估类型软件组织的关于具体的软件过程能力的评估;软件组织整体软件能力的评估(软件能力成熟度等级评估)CMMI的基本思想
1、解决软件项目过程改进难度增大问题
2、实现软件工程的并行与多学科组合
3、实现过程改进的最佳效益简单改进过程确定目前处于什么现状;确定想改进到什么程度;制定计划;执行计划;汲取经验教训继续做PDCA过程:计划、执行、检查、改进CMMI在IDEAL模型中的运用
①初始阶段CMMI模型能帮助组织了解如何发起并确定改进的基本内容
②诊断阶段用于过程改进的标准CMMI过程改进评估方法SCAMPISM为基于CMMI的过程评估提供了准绳
③建立阶段CMMI过程域注重于建立过程改进组.
④行动阶段CMMI模型为定义和改进过程提供了指南
⑤学习阶段学习CMMI文档是组织进行过程改进的基础.定义过程
①成熟的过程是文档化的
②通常采用两种方式进行过程文档化:描述正式的过程;描述面向用户的过程
③描述正式的过程读者主要是过程专家;详细正规的描述;主要用于开发、剪裁和改进过程
④描述面向用户的过程读者主要是每天使用过程的用户;简单清晰的描述;主要用于执行过程过程必须描述下列事项:在这个过程中将执行什么活动谁来完成为什么要完成它们什么时候完成如何完成哪些输入是必须的能有哪些输出怎样测量其性能不一样的描述格式不一定都能方便地描述:活动的次序;活动的时间;活动中的数据流;分层次的细节;与标准的出入;叙述性的资料描述格式的其它特征:灵活性;简单化;易于理解和培训;实用性一些常用的过程描述格式
①通用的数据流图;流程图;决策树或决策表;检查表;叙述
②特殊的ETVX入口-任务-确认-出口;SADT/IDEF0结构分析和设计技术;信息图InformationMapping
③或是上述的综合活动细节本次活动的目的是什么谁参加了此活动完成这项活动需要有哪些投入通过这次活动能产生什么工作产品怎么知道这次活动应在什么时候开始的怎么知道这次活动到什么时候已经顺利完成的为本次活动的完成做了些什么为完成本次活动列出3-6个子活动怎么确定或测量这次活动的性能在这次活动之前或之后还有什么活动总结作为改进的关键杠杆作用点是过程;有效的过程定义对于过程制度化是至关重要的;基于CMMI的过程改进是可测量的;CMMI对于发现当前组织管理中的问题以及软件工程、产品开发和交付是有用的工具。