微软的软件开发过程.ppt

微软的软件开发过程,重庆大学计算机学院曾一,-软件开发过程与案例 陈宏刚 熊明华 林斌 张高 张益肇 张亚勤,1.微软解决方案框架MSF,1.1 观点：技术不是项目成功与否的惟一决定因素。一个成功的IT项目中，开发人员、开发过程以及风险管理等因素起着至关重要的作用。预见性地、可持续地管理和控制项目风险有效地进行协作和沟通确保技术方案与商业需求的一致,1.微软解决方案框架MSF,1.1 观点：技术不是项目成功与否的惟一决定因素。项目失败的五大因素不完整的需求描述缺少用户参与缺乏资源-经费、人员、场地、时间等不现实的项目目标缺少管理层的支持,1.微软解决方案框架MSF,1.2 什么是微软解决方案框架MSF？MSF（Microsoft Solution Framework)是微软公司根据自身的实际经验为企业设计的一套有关软件开发的工作模型、开发准则、成功经验和应用指南。MSF的设计目标是为企业IT系统的规划（Planning)、建设(Building)和管理(Managing)提供支持和帮助。,1.微软解决方案框架MSF,1.2 什么是微软解决方案框架MSF？MSF可以帮助企业解决以下问题将企业的商业目标同技术目标有机地结合起来确立明确的项目目标和完善的项目职责体系积极有效地管理项目风险实施以里程碑为主导的渐进项目管理过程管理和控制项目的需求变化,1.微软解决方案框架MSF,1.3 微软解决方案框架MSF中的模型企业架构模型 Enterprise Architecture Model解决方案设计模型 Solution Design Model风险管理模型 Risk Management Model组队模型 Team Model过程模型 Process Model应用模型 Application Model,1.微软解决方案框架MSF,均衡三角形影响项目成败的三个关键因素资源（人和费用）进度（时间）功能（组成一个相互关连、相互依赖的三角形求得三者之间的平衡三角形任何一边的改动都必须迫使另两边的改变，否则项目可能失败。,1.4 微软解决方案框架MSF中的开发准则,2.组队模型 Team Model,2.1 什么是组队模型总结了MS在成功的项目中组织人力资源、安排工作任务的基本原则和方法定义了项目组内的角色分工、任务分配和人员职责为项目组成员提供了有关在项目生命周期中如何实现目标的指导性建议,2.组队模型 Team Model,2.2 组队模型的基本原则1）按层次结构和职能单位划分的小型的、多元化的项目组（small，multidisciplinary team)Bill Gates说：“在那些有着严格的经费预算和确定的时间期限、其组员在处理问题时享有充分自由的小型项目组中，人们通常拥有最高的生产效率。”多元化的体现即指在一个项目组内，甚至在一个角色内，通常有多种不同的工作方式，需要其成员具有不同的工作技能或经验水平。在小型的、多元化的项目组中，交流成本、运营成本、管理成本低，决策和执行速度快，产品发布周期短，产品质量高。,2.组队模型 Team Model,2.2 组队模型的基本原则2）角色依赖和职责共享（interdependent roles and shared responsibilities)在项目组内，每一个角色都对项目本身以及他们各自的主管部门负责，以实现该角色的工作目标。整个项目的各项工作职责通过对等团队的结构被项目中不同的角色和成员共享，项目目标也通过不同角色的工作目标得以实现。在项目组内，不同角色的工作无法完全孤立，这可促使这些角色主动发表意见和贡献力量。,2.组队模型 Team Model,2.2 组队模型的基本原则3）专深的技术水平和业务技能（deep technical and business acumen)透彻理解用户需求熟悉客户的业务流程和业务模式熟练掌握相关技术把握产品目标,2.组队模型 Team Model,2.2 组队模型的基本原则4）以产品发布为中心（focus on competency and shipping products)强烈的产品意识按时发布产品的显著标识产品单元的内部代码,2.组队模型 Team Model,2.2 组队模型的基本原则5）明确的目标（clear goals and objectives)统一的方向明确的目标目标与需求的一致,2.组队模型 Team Model,2.2 组队模型的基本原则6）客户的主动参与（active customer participation)客户对产品特性的实时反馈产品管理角色以客户身份出现客户直接担任产品管理角色,2.组队模型 Team Model,2.2 组队模型的基本原则7）分享产品的前景（shared project vision)项目组内所有成员都应该对产品前景有清晰和明确的认同每一位成员都应该在产品前景的激励下努力工作每一位成员都应该能为产品的美好前景贡献力量而自豪,2.组队模型 Team Model,2.2 组队模型的基本原则8)所有人都参与设计（everyone participating in design)有意义的建议有价值的信息使产品趋于完善和合理,2.组队模型 Team Model,2.2 组队模型的基本原则9）认真从过去的项目中吸取经验（deliberate efforts to learn from past projects)总结反省分析,2.组队模型 Team Model,2.2 组队模型的基本原则10）共同管理、共同决策（shared project management and shared decision-making)每一个成员都对项目管理和项目组中的重要决策负有一定的职责，应当参与每一个决策每个角色的负责人应该集思广益才能做出最终决定,2.组队模型 Team Model,2.2 组队模型的基本原则11）项目组成员在同一地点办公(team members working together at one site)更高的沟通效率更好的工作业绩非正式的交流增多：电梯间、餐桌边等,2.组队模型 Team Model,2.2 组队模型的基本原则12）大项目组也象小项目组一样运转(large teams working like small teams)大项目团队的拆分结构清晰、目标明确、可灵活管理的小项目组小项目组的管理和角色划分小项目组之间的并行关系对大项目组，每隔36个月对其小项目组重组成功的项目组有经验的项目负责人、积极参与项目决策并主动贡献力量和承担责任的组员、以产品发布为共同目标即最高使命、共同分享项目前景。,沟通,沟通,2.组队模型 Team Model,2.3 组队模型的六种角色,六种组队角色,程序管理角色,发布管理角色,测试角色,用户体验角色,开发角色,产品管理角色,对等团队结构,程序经理,发布和后勤经理,开发经理,产品经理,用户经理,测试经理,2.组队模型 Team Model,2.3 组队模型的六种角色产品管理角色（product management)产品管理角色的主要使命是提高客户满意度产品经理的主要工作内容代表客户的想法和意见管理客户的需求定义-为其他角色准备一份书面的客户需求说明书开发、管理和提供业务用例说明管理客户的预期目标控制产品特性和开发周期之间的关系管理市场宣传和公共关系,2.组队模型 Team Model,2.3 组队模型的六种角色程序管理角色（program management)程序管理角色的主要使命是在规定的项目资源、期限等限制条件下，确保产品能够如期发布。程序经理-项目开发过程的组织者和管理者，而不是项目组的领导者，主要工作内容如下：推动产品开发过程-一种保证产品的期限和特性符合需求管理产品范围和产品特性说明-相当于一份契约推动项目组内的交流和讨论-组织和协调管理产品开发进度、汇报项目状态-一种服务控制项目开发中关键的取舍和决策-拥有最终决定权,2.组队模型 Team Model,2.3 组队模型的六种角色开发角色（development)主要任务是使用适当的技术和工具实现项目目标、满足客户需求；进行技术咨询，帮助防范风险；提供解决方案，参与设计过程。开发人员的主要工作内容如下：产品特性的物理设计-即实现程序经理的所有功能规范承担技术顾问的职责确保每一个产品特性在规定时间内完成使产品达到可发布的状态-需要编写特定的安装和配置程序，提供给测试人员和最终用户使用,2.组队模型 Team Model,2.3 组队模型的六种角色测试角色（testing)主要任务是在产品最终发布之前找到尽可能多的缺陷或错误测试人员的主要工作内容如下：制定测试策略和测试计划确保产品的所有特性都经过了严格的测试，也同时负责测试所需要的软件工具、脚本程序和技术文档等的编写工作向项目组提供翔实、准确的测试报告，确保所有已发现的软件故障都在项目组的有效管理和控制中,2.组队模型 Team Model,2.3 组队模型的六种角色用户体验角色（user experience)主要任务是协助用户更好地使用产品，排除用户在使用产品时遇到的问题和障碍。主要工作内容包括以下：在产品设计阶段确保产品可被最终用户接受对产品的国际化功能提供支持（全球化和本地化globalization/localization),（全球化和本地化globalization/localization)全球化指设计和开发那些可以用最少代价满足世界上不同地区市场需求的产品。本地化指将软件产品的用户界面、帮助文件、印刷或联机文档、市场资料及WEB站点等内容转换为符合特定地区市场地区市场中语言、文化习惯的形式。,2.组队模型 Team Model,2.3 组队模型的六种角色发布管理角色（release management)主要任务是确保产品的顺利发布，为项目的正常运营提供服务和支持。主要工作内容如下：代表项目组协调公司内的运营、支持、发布渠道等部门的工作项目组的后勤和基础设施管理-办公环境、采购、IT系统管理产品发布事宜-制定和执行计划、协调市场和渠道参与、管理并支持相关的项目决策过程管理产品的认证或许可模式-产品序列号、许可协议,2.组队模型 Team Model,2.3 组队模型的六种角色六种角色的授权/权利自主抉择self-selecting 自主管理self-managing自我激励self-motivating自我评估self-evaluating自我改进self-improving,2.组队模型 Team Model,2.4 组队模型中的项目组的六大工作目标项目组的六大工作目标与六大角色的关系提高客户满意度-产品管理角色增强产品的可用性-用户体验角色严格依据用户的业务需求和 产品功能说明书开发产品-开发角色在充分测试、定位了所有 已知问题的前提下发布产品-测试角色在有限的时间和资源条件下开发产品-程序管理角色做好产品的发布和后续的管理工作-发布管理角色,2.组队模型 Team Model,2.5 组队模型的灵活应用大项目组（多于10人）拆分成多个小项目组每个小项目组负责产品的一个特性或一个功能模块小项目组依据各自的工作目标，并行地完成整个项目组开发工作小项目组定期交流和沟通，以保证项目进展同步另一种拆分方法是按照职能拆分，当项目组中某个或某几个特定的职能角色需要更多资源配置的时候，这种拆分方法格外有效有时不可能要求每一个职能都由专人来负责担任，因此需要角色合并，一人身兼数职,2.组队模型 Team Model,2.5 组队模型的灵活应用小项目组角色合并的基本原则项目组内的开发人员不能兼任其他角色不要试图合并两个有明显利益冲突或制约关系的职能角色,n不能合并,p可以合并,u可以合并,不建议合并,2.组队模型 Team Model,2.5 组队模型的灵活应用例1，一个最小的项目组可以只有三个成员即程序经理兼发布管理的角色，产品经理兼测试和用户体验的角色，开发人员即开发角色。例2，按职能划分项目组的产品管理项目组可以是由如下角色组成(分工更加细致）：产品总体管理、产品规划、市场调研、市场工作、宣传、公共关系等。例3，按职能划分项目组的程序管理项目组可以是由如下角色组成：程序总体管理、版本管理、项目协调、产品架构设计。,2.组队模型 Team Model,2.5 组队模型的灵活应用例4，开发角色也可以拥有内部的项目组结构，开发人员可以按照用户层、业务逻辑层、数据层的原则分成不同的团队。例如，开发项目组：开发管理、用户界面、数据库、系统服务例5，测试项目组：测试管理、压力、功能、集成、配置测试等例6，用户体验项目组：用户体验管理、用户资源管理、媒体管理、文档编撰、本地化例7，发布管理项目组：发布管理、系统管理、项目沟通、项目运营、渠道管理、支持平台、内部培训,2.组队模型 Team Model,2.6 组队模型中的交流和沟通Communication在MSF组队模型中最重要的、最具有决定性的因素是交流和沟通。需要特别指出的是在，MSF组队模型中，项目组内部测试角色和开发角色之间的沟通直接影响着产品的质量，是项目组内部最为关键的沟通渠道之一。,2.组队模型 Team Model,2.6 组队模型中的交流和沟通Communication两类沟通基于商业视角和基于技术视角的沟通,开发,测试,发布管理,产品管理,用户体验,程序管理,最终用户,最终用户,客户,商业视角,技术视角,业务设计和规划人员,技术委员会,运营和支持部门,3.MSF过程模型Process Model,MSF过程模型是一种基于里程碑的、目标驱动的开发模型MSF过程模型包含5个主要阶段和5个主要里程碑MSF过程模型中，项目均衡三角形起着至关重要的作用,3.MSF过程模型Process Model,3.1 什么是MSF的过程模型软件开发项目的全过程（1）新项目的启动阶段：提出项目设想，组建项目组，完成筹备工作（2）市场调研阶段：调查相关产品的市场情况，寻找和设计产品未来的市场定位（3）技术论证阶段：分析、论证产品在技术上的可行性，评估技术风险,3.MSF过程模型Process Model,3.1 什么是MSF的过程模型（4）项目计划和日程制定阶段：设计和制定项目整体的进度表，为整个项目过程阶段划分工作阶段、界定任务目标。（5）管理层评审阶段：寻求管理层对项目的认可。（6）产品特性描述阶段：将客户需求转变为产品特性，对其进行技术的精确描述。（7）资源分配阶段：在项目组内、外调配项目的可用资源。（8）产品开发和发布阶段：通过软件开发过程实现产品的所有特性，满足客户需求，发布到客户手中。,3.MSF过程模型Process Model,3.1 什么是MSF的过程模型MSF过程模型是一种基于阶段的、由里程碑驱动的、递进（螺旋）的软件开发模型。它可以用于传统的应用开发环境，也可用于电子商务、WEB分布式应用等企业级解决方案的开发和部署。,里程碑,3.MSF过程模型Process Model,MSF过程模型的特点目标驱动而非任务驱动为什么要开发这个产品？产品为谁服务？最终要发布的产品将具备哪些特性？任何一项任务都必须围绕最终的项目目标制定，否则必须调整任务。外部可见的里程碑里程碑与工作阶段对应,应提交项的变更管理使用基线对源代码、系统配置、日程表、设计文档、用户手册、预算等应提交项进行变更管理项目中的所有变更的记录、跟踪、确认、回溯都依据已制定的基线来管理。递进的版本发布策略先有核心功能的版本再向其中添加功能,3.MSF过程模型Process Model,MSF过程模型的特点风险驱动的进度管理风险最大的产品特性应当首先被安排开发项目组集体参与项目开发的每一个特定阶段与一种特定的组队角色关联责任与义务管理产品质量质量管理意识和方法质量保证策略贯穿项目始终,3.MSF过程模型Process Model,微软软件开发过程的基本原则制定计划时兼顾未来的不确定因素通过有效的风险管理减少不确定因素的影响经常生成（Daily Build)过渡版本并进行快速测试（生成验证测试-Build Verification Test)来提高产品的稳定性及可预测性确保每次Check-in都不会破坏产品的整体结构,快速循环、递进的开发过程从产品特性和成本控制出发创造性地工作创建确定的进度表使用小项目组并发完成工作，并设置多个同步点里程碑将大型项目分解成多个可管理的单元，以便更快地发布产品可有效缩短产品发布周期,3.MSF过程模型Process Model,用产品的前景目标和概要说明来指导项目的开发工作-先基线化，后冻结避免产品走形-应当检查和审视当前状态是否和客户需要及产品的功能说明书相吻合使用概念验证原形进行开发前的测试-早期论证零缺陷观念-所有的Bug都在控制范围之内且可在适当时机得到修正,非责难式的里程碑评审会以改进工作为主要目的会议内容将对此后的项目过程产生影响,3.MSF过程模型Process Model,3.2 MSF过程模型的阶段划分和里程碑设置1前景/范围得到认可2项目计划得到认可3开发完成4可发布版本准备就绪5发布完成里程碑的使用可以帮助我们在项目的不同阶段中合理分配（组队角色）职责和义务，调动所有团队成员的积极性,3,2,1,4,5,计划阶段,构想阶段,开发阶段,稳定阶段,发布阶段,3.MSF过程模型Process Model,1构想阶段产品管理角色起推动作用提交项包括：前景范围说明书风险评估说明书项目组织结构说明书,3.MSF过程模型Process Model,2计划阶段提交项包括：功能说明书风险管理计划项目总体计划书和总体进度表,3.MSF过程模型Process Model,3开发阶段阶段提交项包括：源代码和可执行程序安装脚本和用于发布的配置信息已冻结的功能说明书关于产品使用的支持要素测试说明书和测试用例,3.MSF过程模型Process Model,4稳定阶段应提交项包括：黄金版本版本注释关于产品性能的支持要素测试结果和测试工具源代码和可执行程序项目文档里程碑评审记录,建议的临时里程碑BUG收敛-BUG数目呈持续减少零BUG弹跳-由于修改BUG暂时没有活动的BUG候选版本-项目组可能发现不少新的BUG；可能不是最终发布的版本前生产阶段测试已经完成-准备一个先导版本可接受度测试完成-在非生产环境中用户认可（接受度测试和可用性测试）先导版本完成-在尽可能真实的测试环境中对整体解决方案进行了足够的测试，该版本可在真实环境中测试了,3.MSF过程模型Process Model,5发布阶段应提交项包括：运营和支持信息系统程序和过程（PROCEDURES AND PROCESSES）知识库、报告、日志文档库：包含项目过程中产生的所有版本的文档、资源和代码项目总结报告所有项目文档的最终版本客户/用户满意度调查数据下一步的工作计划,3.MSF过程模型Process Model,3.2 MSF过程模型的交流和沟通至关重要成功的关键例如,产品管理角色：用户提出需求变更程序管理角色：可能带来什么影响？开发角色：需要开发新的组件测试角色：需要设计新的测试用例可能在产品用户体验角色：可能使最终用户产生困惑,3.MSF过程模型Process Model,项目管理中的均衡三角形产品功能通常情况下，产品功能是不能随便调整的资源进度（发布时间）由此，调整三者的指导原则：,在资源一定的情况下我们可以选择进度，并对产品功能做必要的调整；我们可以选择产品功能，并对进度做必要的调整；在产品功能一定的情况下我们可以选择资源，并对进度做必要的调整；我们可以选择进度，并对资源做必要的调整；在进度一定的情况下我们可以选择资源，并对产品功能做必要的调整；我们可以选择产品功能，并对资源做必要的调整。,4.程序经理与IE浏览器项目V4.0,4.1 什么是程序经理程序经理没有或很少拥有外部授予的权力，但却需要通过自己的努力工作赢得项目组成员的认可和尊重，赢得项目组内的组织权、协调权及与开发相关的决策权对按时、保质地向客户提交正确的产品负有全部责任。,项目组是针对项目需求临时组成的工作单元。工作人员主要来自产品部门下面的三个部门,一般的项目组结构,产品部门总经理,测试部经理,开发部经理,程序经理部经理,程序经理组长,开发经理组长,测试组长,测试工程师,开发工程师,程序经理,程序经理,开发组长开发工程师开发工程师开发工程师开发工程师,测试组长测试工程师测试工程师测试工程师测试工程师,产品经理,用户培训工程师,可用性测试工程师,界面设计工程师,三个部门,项目组结构,4.程序经理与IE浏览器项目V4.0,4.2 程序经理与项目经理程序经理在项目组内享有的权力更多的是主动赢得的；管事；多人任职；编写技术文档等项目经理在项目组内享有的权力则是外部授予的（如奖惩权等）；管人；一人任职；一般不参与技术细节（如编写技术文档等）,项目经理,一人负责,管理人,管理项目,不写文档,多人负责,赢得的权力,授予的权力,写文档,4.程序经理与IE浏览器项目V4.0,4.3 程序经理应该具备的素质和能力程序经理必须具备以下三种核心素质：沟通能力（Communication)电子邮件、会议（评审、项目组）、项目组网站、直接交流领导能力(Leadership)赢得权力、正确决策、推动产品发布、管理和预防风险协调能力(Relationship)我如何使大家工作得更出色？如何使用户认可我的产品？程序经理必须具备以下二种核心能力：核心能力智商核心能力情商,4.程序经理与IE浏览器项目V4.0,程序经理的核心能力智商编码能力软件构架设计能力用户-学习技能用户界面设计技术API和接口设计能力书面的、口头的、正式和非正式的沟通能力演讲和展示能力理财能力熟悉商法、合同法、专利法和著作权法的基本内容市场调研能力掌握关于竞争对手的知识可以迅速掌握各种软件的使用方法,程序经理的核心能力情商一个人成功的背后，智商所起的作用只有10%，而情商所起的作用可以占有90%。“学做事先学会做人”。聪明才智、领导才能、自我意识商业谈判能力用户移情能力对关键信息的敏感善于处理人际关系进度和项目管理能力时间管理能力组织心理学、组织技术团队行为学管理不同类型人员的能力招聘、面试和雇用技术,4.程序经理与IE浏览器项目V4.0,4.4 IE V4.0浏览器项目目标是在1998将市场占有率扩大到65%人员大致构成（96.897.6）产品部门总经理 1人产品规划员 5人产品经理 20人程序经理 50人软件开发工程师100人软件测试工程师100人用户培训工程师 10人IE5.0大约500人,按产品特性形成项目组主要组织原则化整为零、相对独立、短小精悍、权责分明IE4.0项目组分为3个大的项目组用户界面部分浏览器引擎部分服务器端应用部分结构同4.1中项目组结构可能项目组被分得更小子特性项目组负责1个产品组件或几个产品特性的开发,4.程序经理与IE浏览器项目V4.0,4.5 IE V4.0浏览器项目工作流程按照如下阶段管理计划阶段开发阶段稳定阶段发布阶段总结阶段开始下一个版本周期,4.程序经理与IE浏览器项目V4.0,项目前景和产品目标IE将成为INTERNET上的主流浏览器软件为客户和最终用户端提供高速、稳定、总体拥有成本最低与MS-OFFICE有效集成在1998年市场占有率扩大到65%,一般工作流程确认商业机会，制定宏观的商业计划准备项目计划草案项目组内的头脑风暴会议，明确产品特性编写单页功能说明书（包括产品特性的优先级、资源预算、进度预期和风险预期等）汇总产品特性、开发进度和相应的里程碑设置,计划阶段一般工作流程项目前景和产品目标产品里程碑确定产品特性的概要和详细设计,产品里程碑确定6月25日，提交前景和目标说明7月1日，单页功能说明书7月15日，详细功能说明书9月1日，引擎代码开发完成10月8日，用户界面代码开发完成11月7日，发布候选版本11月9日，发布BETA-1版本（内部员工测试）4月5日，发布BETA-2版本（外部公开测试）7月12日，发布正式版本（RTM）,产品特性的概要和详细设计一份设计文档的基本章节结构：责任人/作者概述指导原则情景设计描述产品特性设计安全设计安装和发布国际化、本地化存在问题更新历史,4.程序经理与IE浏览器项目V4.0,开发阶段开发计划工作安装、配置开发环境代码检入工作（Check-in)每日产品生成(Daily build)管理Bug数据库,1开发阶段开发工程师：审核功能说明书等设计文档列出工作任务列表估计工作时间程序经理：主持项目组开会讨论所有的工作任务平衡项目组各成员的工作负荷测试组长：为开发人员指派结伴的BUDDY测试员BUDDY测试员编写详细的测试用例,2安装、配置开发环境开发工程师：配置源代码的目录结构，每个产品特性项目组管理一个字目录制定检入进度表和检入制度测试/生成工程师：准备编译、生成用的计算机和服务器制定生成计划安装、配置BUG数据库程序经理的工作：安装、配置项目组网站，定义项目组邮件信箱制定项目组会议计划,3代码检入工作（Check-in)同步代码，每人先生成自己的版本以保证新代码与原版本树不发生冲突；在检入前做代码审查（提前发现Bug并由第二个程序员检验和认可）；检入时，代码必须满足检入条件（即 通过了BVT（Build Verification Test)和其他测试，且满足最低测试要求）；遵守检入窗口制度，即在大项目组中，不同功能开发人员在不同的规定时间检入他们的代码，这样容易定位Bug；发送检入邮件通知项目组（包括代码变更目的、代码审查员、修改过的文件和测试条件等）。,4代码检入工作（Check-in)整个生成过程都是自动完成的；每天的同一时间，通过同步所有项目组件，创建一个源代码树的拷贝；编译生成所有的组件；运行BVT测试，检验生成版本的可用性；向项目组发送状态报告邮件发送每日同步日志，在公共服务器上公布生成后的产品版本。,5管理Bug数据库每个产品都有一个集中的Bug数据库；大多数Bug记录（包括代码缺陷和不完善的产品特性）都是由测试人员创建的；程序经理负责每天审核Bug数据库，并为开发人员分配Bug修改工作开发人员修正Bug并将结果发回给测试人员；测试人员使用每日生成来检验Bug是否已经修正，并修改Bug记录。若确定已经更正，则关闭Bug。,4.程序经理与IE浏览器项目V4.0,稳定阶段产品特性冻结代码完成用户界面冻结BETA版本发布,1产品特性冻结所有的产品变更必须经过一个特殊的管理过程，项目组开会审查和确定是否允许变更。应当有明确的、严格的变更标准在产品特性冻结之后，可能引发产品特性变更的一些特殊因素：最终用户新提出的反馈意见竞争对手的新产品中增加了新的特性刚赢得的一个大客户提出了新的需求其他部门的需求法律问题,2代码完成意味着开发人员完成了所有的编码任务，所有产品特性都已被检入到代码库中测试人员开始做系统的集成测试程序经理每天评审、监控和分配BUG修改工作开发人员开始修正BUG,3用户界面冻结意味着：用户界面的样式和提示信息不再发生变更用户培训工程师开始编写联机帮助手册和用户手册开始本地化工作任何改动都必须经过项目组和负责用户界面国际化的程序经理审核通过对每个变更都必须仔细跟踪和管理,4 BETA版本发布为外部客户提供一个特殊的测试版本包含基本特性和功能目的是收集客户的反馈信息作用是扩展测试队伍和测试平台可以稳定产品、提高产品质量可以促进项目组之间产品的集成可以推动合作伙伴的项目进展,4.程序经理与IE浏览器项目V4.0,发布阶段到达零BUG日期发布侯选版本源代码树分支正式发布版本签字认可,1 到达零BUG日期数据库中所有已知BUG都被处理（被更正或被推迟或不予修改）测试人员将要开始第二轮全面测试项目组会议每天将讨论、评审新的BUG在新条件下重新评定优先级，优先级较高的BUG必须在24小时内修正,2 发布侯选版本数据库中所有已知的优先级较高的BUG都已被修正新的BUG将成为影响产品发布的瑕疵，不太重要的新的BUG有可能被推迟到下一版本中修正开发人员必须在24小时内修正新发现的重大BUG新发现的BUG被修正之后，项目组将发布一个新的候选版本新的候选版本必须通过完整的回归测试对于大项目来说，项目组的变更标准更高一些例，IE4.0发布的候选版本经过14个。,3 源代码树分支在当前一个版本开始之前，下一个版本的开发工作已经开始一些程序经理开始为下一个版本设计产品特性源代码树分支的同时，复制当前的源代码树开发人员的精力大多投入到新的版本的开发过程中只有对影响发布的BUG的修正会被合并到当前版本树中来，其他的BUG修正和新开发的产品特性都只存在于新的版本的源代码中,4正式发布版本和签字认可发布的两种形式基于盒装产品发布和基于WEB发布只有修正了所有影响发布的重大BUG之后，测试人员才能签字认可最终的可发布版本签字认可后，如果发现了影响发布的BUG，就需要紧急从生产线上“召回”正在生产的产品，修正后再次发布。“召回”需经过一定级别的人员签字认可。测试人员最终为正式发布版本签字，程序经理也需要在包含可发布程序的盘上签字确认产品发布后，开庆祝会,4.程序经理与IE浏览器项目V4.0,总结阶段和开始下一个版本周期程序经理负责召集项目组的总结会每个项目组成员都需要准备一份总结报告并发言会议可能持续几天，包括大型的和小型的目的在于改进开发过程和提高开发水平会议结束前，每个项目组和每个项目组成员都应该在下一次开发过程中提出行动计划,4.程序经理与IE浏览器项目V4.0,4.6微软过程管理策略基于客户需求决定产品的特性集合及优先级关系使用前景/目标描述文档和概要性的功能说明书指导项目工作将项目过程划分为基于里程碑驱动的多个工作阶段（1989年开始严格使用里程碑管理和每日生成制度）使用定量的数据来检验里程碑的完成情况使用组件化的设计方式，将产品结构和项目结构有机结合多个项目组并行开发，在每日生成时完成项目间的同步总是拥有理论上的、可发布的产品，包括所有主要的版本不断生成和测试产品,5.软件测试,5.1软件测试是执行程序或系统以期发现错误的过程。是评估程序或系统特性的工作的总称，是衡量软件质量的标尺。是一个设计、使用和管理用以度量并改进被测软件质量的测试工具的并行生命周期。是用规范的或不规范的方法来对软件进行攻击和破坏，以期寻找软件的缺陷和漏洞。,5.软件测试,5.2测试角色测试人员通常比开发人员多EXCHANGE SERVER 2000测试/开发人员：350/（25+140）=2.5:1WINDOWS 2000测试/开发人员：3200/（250+1700）=1.9:1测试团队测试部（经理）由下列小组人员组成测试实验室（组长）+功能测试（组长）+BVT测试（组长）BVT=Build Verification Test 生成验证测试,5.软件测试,测试组人员的责任测试组的软件开发工程师具备代码编写的能力和开发工具软件的经验，主要负责自动化测试工具和测试脚本的开发。软件测试工程师：主要负责测试软件产品，分为BTV工程师-负责保证每日生成的软件版本可顺利执行，确认已开发完成的所有功能模块都已连入产品，且主要功能正确无误。功能测试工程师-负责对某个特定组件或某组特性测试。可用性测试工程师-负责产品中与操作流程、用户界面相关的部分，确保产品在最终使用方式上满足用户的需求。测试专家（AD hoc Tester)-经验丰富、对产品体系结构和实现方法了如指掌的且能使用各种方法对软件进行测试的人员。测试实验室工程师负责管理和维护测试环境（硬件平台、网络架构和软件环境）。,5.软件测试,5.3测试角色在不同项目阶段中的工作任务构想阶段制定测试策略、建立测试标准计划阶段设计论证、编写测试需求说明书、制定测试计划/进度表开发阶段功能测试、问题确认、文档测试、更新测试计划稳定阶段功能和性能测试、错误报告和错误状态、系统配置测试发布阶段用户使用测试、问题处理,5.软件测试,5.4测试中BUG的跟踪和管理BUG是指软件在使用中出现的所有存在争议的问题（ERROR和DEFECT）。测试人员的一项重要使命是对所有已知BUG进行有效跟踪和管理。BUG的状态已修正、重复、可推迟、设计问题、不可再现、无需修正BUG关闭：经过验证确认已正确处理的BUG被标记为关闭状态。,BUG报告测试工程师,BUG处理开发工程师,BUG评估和分配程序经理,BUG关闭测试工程师,BUG,5.软件测试,5.5测试的分类5.5.1覆盖测试和使用测试覆盖测试单元测试（最小代码单元）功能或特性测试检入（CHECK-IN）测试BVT测试回归测试,使用测试配置测试兼容性测试压力测试性能测试文档和帮助文件测试Alpha（内）和Beta（外）测试,5.软件测试,5.5.2白盒和黑盒测试白盒测试代码覆盖流程覆盖系统内部结构黑盒测试可接受度测试BVTAlpha 和Beta 测试菜单/帮助测试发布测试回归测试RMT准备生产测试（Ready to Manufacture Testing刻盘前),黑盒测试功能测试和系统测试验证功能说明书的完整和正确正确性可用性边界条件性能压力错误覆盖（验证是否对错误进行妥善处理）安全兼容性配置安装,5.软件测试,5.6 测试工具自动测试工具配置管理工具项目管理工具缺陷跟踪工具调试工具,基本测试工具包括的内容测试人员、计算机、OS、办公软件摄像和录像系统秒表BUG跟踪系统自动化脚本工具软件、硬件诊断工具文件比较工具、文件查看工具文件格式转换工具内存管理工具屏幕捕捉工具,5.软件测试,5.7 测试文档测试计划测试说明书测试用例BUG报告测试结果报告工作报告,测试计划编写之前应该获得以下文档程序经理编写的产品功能说明书或产品特性开发计划程序经理或开发人员提供的开发进度表,5.软件测试,测试计划包括测试目标和发布条件测试目标描述达到何种测试目标的前提才可以发布某个特定版本对每个发布条件定义详细的里程碑待测产品范围主要特性/功能说明特性/功能测试一览相应的测试说明书的位置测试方法描述定义使用的测试方法描述每一种特定的测试方法可以覆盖哪些测试范围,测试进度表定义里程碑当前里程碑的详细测试进度描述测试进度与程序经理或开发人员制定的开发进度之间的关系测试资源和相关的程序经理/开发工程师定义参与测试的人员描述职责范围给出与测试人员有关的的信息程序经理或开发人员编写的文档的位置配置范围和测试工具所用计算机列表测试覆盖了哪些硬件设备测试时使用的主要测试工具,5.软件测试,测试说明书编写之前应该获得以下文档程序经理编写的产品功能说明书（与该产品范围相关的部分）程序经理或开发人员提供的开发进度表（与该产品范围相关的部分）,背景信息产品功能说明书位置（路径）参与人员、文档的修改/编辑记录待测产品特性单独的待测产品特性、产品范围的特性组合与其他产品范围内的特性有集成关系的产品特性、产品特性的分解测试未覆盖到的产品特性说明功能描述详细的待测功能，包括菜单、热键、对话框、错误信息和帮助文档测试描述边界条件测试、使用的语言系统测试、黑盒测试测试情景设计描述在何种条件下、使用何种测试方法、通过哪些测试步骤、预期得到何种测试结果,5.软件测试,测试用例设计之前应该获得以下文档程序经理编写的产品功能说明书详细的测试说明书,测试用例文档一般包括下列环节根据测试说明书中的测试情景设计，开发一组测试用例根据测试过程中的反馈信息，增加更多的测试用例根据测试所发现的BUG情况，增加更多的测试用例,5.软件测试,BUG报告BUG主题/标题测试使用的系统平台测试时使用的软件版本BUG优先级和重要程度重现该BUG的步骤实际结果预期结果其他相关信息,测试结果报告当前测试进度和状态仍然存在的BUG列表新发现的BUG列表已处理或已关闭的BUG列表测试工作与过去相比的改进之处新的工作目标测试是否按计划完成？,5.软件测试,工作报告工作概述工作详情主要完成了什么BUG报告未关闭的BUG已关闭的BUG下一周工作计划计划完成什么,测试工程师的来源程序员中选拔专职培养其他行业有经验的职员普通用户,5.应用模型 Application Model,1.什么是应用模型 应用模型针对软件设计和开发工作提供了一种逻辑上的