微软的软件开发过程.ppt

微软的软件开发过程,重庆大学计算机学院 曾一ZYJCKXXCQU.EDU.CN,-软件开发过程与案例 陈宏刚 熊明华 林斌 张高 张益肇 张亚勤,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:1 WINDOWS 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白盒和黑盒测试 白盒测试 代码覆盖 流程覆盖 系统内部结构 黑盒测试 可接受度测试BVT Alpha 和Beta 测试 菜单/帮助测试 发布测试 回归测试 RMT准备生产测试（Ready to Manufacture Testing刻盘前),黑盒测试 功能测试和系统测试 验证功能说明书的完整和正确 正确性 可用性 边界条件 性能 压力 错误覆盖（验证是否对错误进行妥善处理） 安全 兼容性 配置 安装,5.软件测试,5. 6 测试工具 自动测试工具 配置管理工具 项目管理工具 缺陷跟踪工具 调试工具,基本测试工具包括的内容 测试人员、计算机、OS、办公软件 摄像和录像系统 秒表 BUG跟踪系统 自动化脚本工具 软件、硬件诊断工具 文件比较工具、文件查看工具 文件格式转换工具 内存管理工具 屏幕捕捉工具,5.软件测试,5. 7 测试文档 测试计划 测试说明书 测试用例 BUG报告 测试结果报告 工作报告,测试计划 编写之前应该获得以下文档 程序经理编写的产品功能说明书 或产品特性开发