微软的软件开发过程

《微软的软件开发过程》由会员分享，可在线阅读，更多相关《微软的软件开发过程（80页珍藏版）》请在装配图网上搜索。

1、,,,,,,,单击此处编辑母版标题样式,,单击此处编辑母版文本样式,,第二级,,第三级,,第四级,,第五级,,,,*,,,,,,,,单击此处编辑母版标题样式,,单击此处编辑母版文本样式,,第二级,,第三级,,第四级,,第五级,,,,*,微软的软件开发过程,重庆大学计算机学院,,曾一,,,-,软件开发过程与案例,,陈宏刚 熊明华 林斌 张高 张益肇 张亚勤,1.,微软解决方案框架,MSF,1.1,观点：技术不是项目成功与否的惟一决定因素。,,一个成功的,IT,项目中，开发人员、开发过程以及风险管理等因素起着至关重要的作用。,,,预见性地、可持续地管理和控制项目风险,,有效地进行协作和沟通,,确保

2、技术方案与商业需求的一致,1.,微软解决方案框架,MSF,1.1,观点：技术不是项目成功与否的惟一决定因素。,,项目失败的五大因素,,不完整的需求描述,,缺少用户参与,,缺乏资源,-,经费、人员、场地、时间等,,不现实的项目目标,,缺少管理层的支持,1.,微软解决方案框架,MSF,1.2,什么是微软解决方案框架,MSF,？,,MSF,（,Microsoft Solution Framework),是微软公司根据自身的实际经验为企业设计的一套有关软件开发的工作模型、开发准则、成功经验和应用指南。,,MSF,的设计目标是为企业,IT,系统的规划（,Planning),、建设,(Building),

3、和管理,(Managing),提供支持和帮助。,1.,微软解决方案框架,MSF,1.2,什么是微软解决方案框架,MSF,？,,MSF,可以帮助企业解决以下问题,,将企业的商业目标同技术目标有机地结合起来,,确立明确的项目目标和完善的项目职责体系,,积极有效地管理项目风险,,实施以里程碑为主导的渐进项目管理过程,,管理和控制项目的需求变化,1.,微软解决方案框架,MSF,1.3,微软解决方案框架,MSF,中的模型,,企业架构模型,Enterprise Architecture Model,,解决方案设计模型,Solution Design Model,,风险管理模型,Risk Managemen

4、t Model,,组队模型,Team Model,,过程模型,Process Model,,应用模型,Application Model,1.,微软解决方案框架,MSF,均衡三角形,,影响项目成败的三个关键因素,,资源（人和费用）,,进度（时间）,,功能（组成一个相互关连、相互依赖的三角形,,求得三者之间的平衡,,三角形任何一边的改动都必须迫使另两边的改变，否则项目可能失败。,1.4,微软解决方案框架,MSF,中的开发准则,功能,进度,组队模型,过程模型,应用模型,资源,Tradeoff Triangle,2.,组队模型,Team Model,2.1,什么是组队模型,,总结了,MS,在成功的项

5、目中组织人力资源、安排工作任务的基本原则和方法,,定义了项目组内的角色分工、任务分配和人员职责,,为项目组成员提供了有关在项目生命周期中如何实现目标的指导性建议,2.,组队模型,Team Model,2.2,组队模型的基本原则,,1,）按层次结构和职能单位划分的小型的、多元化的项目组（,small,，,multidisciplinary team),,Bill Gates,说：,“,在那些有着严格的经费预算和确定的时间期限、其组员在处理问题时享有充分自由的小型项目组中，人们通常拥有最高的生产效率。,”,,多元化的体现即指在一个项目组内，甚至在一个角色内，通常有多种不同的工作方式，需要其成员具有

6、不同的工作技能或经验水平。,,在小型的、多元化的项目组中，交流成本、运营成本、管理成本低，决策和执行速度快，产品发布周期短，产品质量高。,2.,组队模型,Team Model,2.2,组队模型的基本原则,,2,）角色依赖和职责共享（,interdependent roles and shared responsibilities),,,在项目组内，每一个角色都对项目本身以及他们各自的主管部门负责，以实现该角色的工作目标。整个项目的各项工作职责通过对等团队的结构被项目中不同的角色和成员共享，项目目标也通过不同角色的工作目标得以实现。,,在项目组内，不同角色的工作无法完全孤立，这可促使这些角色主动

7、发表意见和贡献力量。,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,组队模型的基本原则

8、,,5,）明确的目标（,clear goals and objectives),,统一的方向,,明确的目标,,目标与需求的一致,2.,组队模型,Team Model,2.2,组队模型的基本原则,,6,）客户的主动参与（,active customer participation),,客户对产品特性的实时反馈,,产品管理角色以客户身份出现,,客户直接担任产品管理角色,2.,组队模型,Team Model,2.2,组队模型的基本原则,,7,）分享产品的前景（,shared project vision),,项目组内所有成员都应该对产品前景有清晰和明确的认同,,每一位成员都应该在产品前景的激励下努力

9、工作,,每一位成员都应该能为产品的美好前景贡献力量而自豪,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,）共同管理、共同决策（,

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,）大项目组也象小项目组

11、一样运转,(large teams working like small teams),,大项目团队的拆分,,结构清晰、目标明确、可灵活管理的小项目组,,小项目组的管理和角色划分,,小项目组之间的并行关系,,对大项目组，每隔,3~6,个月对其小项目组重组,,成功的项目组,,有经验的项目负责人、积极参与项目决策并主动贡献力量和承担责任的组员、以产品发布为共同目标即最高使命、共同分享项目前景。,沟通,沟通,2.,组队模型,Team Model,2.3,组队模型的六种角色,,六种组队角色,程序管理,,角色,发布管理,,角色,测试,,角色,用户体验,,角色,开发,,角色,产品管理,,角色,对等团队结构

12、,程序经理,发布和后勤,,经理,开发经理,产品经理,用户经理,测试经理,2.,组队模型,Team Model,2.3,组队模型的六种角色,,产品管理角色（,product management),,产品管理角色的主要使命是提高客户满意度,,产品经理的主要工作内容,,代表客户的想法和意见,,管理客户的需求定义,-,为其他角色准备一份书面的客户需求说明书,,开发、管理和提供业务用例说明,,管理客户的预期目标,,控制产品特性和开发周期之间的关系,,管理市场宣传和公共关系,2.,组队模型,Team Model,2.3,组队模型的六种角色,,程序管理角色（,program management),,程序

13、管理角色的主要使命是在规定的项目资源、期限等限制条件下，确保产品能够如期发布。,,程序经理,-,项目开发过程的组织者和管理者，而不是项目组的领导者，主要工作内容如下：,,推动产品开发过程,-,一种保证,产品的期限和特性符合需求,,管理产品范围和产品特性说明,-,相当于一份契约,,推动项目组内的交流和讨论,-,组织和协调,,管理产品开发进度、汇报项目状态,-,一种服务,,控制项目开发中关键的取舍和决策,-,拥有最终决定权,2.,组队模型,Team Model,2.3,组队模型的六种角色,,开发角色（,development),,主要任务是使用适当的技术和工具实现项目目标、满足客户需求；进行技术咨

14、询，帮助防范风险；提供解决方案，参与设计过程。,,开发人员的主要工作内容如下：,,产品特性的物理设计,-,即实现程序经理的所有功能规范,,承担技术顾问的职责,,确保每一个产品特性在规定时间内完成,,使产品达到可发布的状态,-,需要编写特定的安装和配置程序，提供给测试人员和最终用户使用,,2.,组队模型,Team Model,2.3,组队模型的六种角色,,测试角色（,testing),,主要任务是在产品最终发布之前找到尽可能多的缺陷或错误,,测试人员的主要工作内容如下：,,制定测试策略和测试计划,,确保产品的所有特性都经过了严格的测试，也同时负责测试所需要的软件工具、脚本程序和技术文档等的编写工

15、作,,向项目组提供翔实、准确的测试报告，确保所有已发现的软件故障都在项目组的有效管理和控制中,2.,组队模型,Team Model,2.3,组队模型的六种角色,,用户体验角色（,user experience),,主要任务是协助用户更好地使用产品，排除用户在使用产品时遇到的问题和障碍。,,主要工作内容包括以下：,,在产品设计阶段确保产品可被最终用户接受,,对产品的国际化功能提供支持（,全球化和本地化,globalization/localization),,,（全球化和本地化,globalization/localization),,全球化,指设计和开发那些可以用最少代价满足世界上不同地区市场

16、需求的产品。,,本地化,指将软件产品的用户界面、帮助文件、印刷或联机文档、市场资料及,WEB,站点等内容转换为符合特定地区市场地区市场中语言、文化习惯的形式。,2.,组队模型,Team Model,2.3,组队模型的六种角色,,发布管理角色（,release management),,主要任务是确保产品的顺利发布，为项目的正常运营提供服务和支持。,,主要工作内容如下：,,代表项目组协调公司内的运营、支持、发布渠道等部门的工作,,项目组的后勤和基础设施管理,-,办公环境、采购、,IT,系统,,管理产品发布事宜,-,制定和执行计划、协调市场和渠道,,参与、管理并支持相关的项目决策过程,,管理产品的

17、认证或许可模式,-,产品序列号、许可协议,2.,组队模型,Team Model,2.3,组队模型的六种角色,,六种角色的授权,/,权利,,自主抉择,self-selecting,,自主管理,self-managing,,自我激励,self-motivating,,自我评估,self-evaluating,,自我改进,self-improving,2.,组队模型,Team Model,2.4,组队模型中的项目组的,六大工作目标,,项目组的六大工作目标与六大角色的关系,,提高客户满意度,--,产品管理角色,,增强产品的可用性,--,用户体验角色,,严格依据用户的业务需求和,,产品功能说明书开发产品

18、,--,开发角色,,在充分测试、定位了所有,,已知问题的前提下发布产品,--,测试角色,,在有限的时间和资源条件下开发产品,--,程序管理角色,,做好产品的发布和后续的管理工作,--,发布管理角色,2.,组队模型,Team Model,2.5,组队模型的灵活应用,,大项目组（多于,10,人）拆分成多个小项目组,,每个小项目组负责产品的一个特性或一个功能模块,,小项目组依据各自的工作目标，并行地完成整个项目组开发工作,,小项目组定期交流和沟通，以保证项目进展同步,,另一种拆分方法是按照职能拆分，当项目组中某个或某几个特定的职能角色需要更多资源配置的时候，这种拆分方法格外有效,,有时不可能要求每一

19、个职能都由专人来负责担任，因此需要角色合并，一人身兼数职,2.,组队模型,Team Model,2.5,组队模型的灵活应用,,小项目组角色合并的基本原则,,项目组内的开发人员不能兼任其他角色,,不要试图合并两个有明显利益冲突或制约关系的职能角色,,,产品管理,程序管理,开发,测试,用户体验,发布管理,产品管理,,N,N,P,P,U,程序管理,N,,N,U,U,P,开发,N,N,,N,N,N,测试,P,U,N,,P,P,用户体验,P,U,N,P,,U,发布管理,U,P,N,P,U,,n,不能合并,p,可以合并,u,可以合并,,,不建议合并,2.,组队模型,Team Model,2.5,组队模型的

20、灵活应用,,例,1,，,一个最小的项目组可以只有,三个成员,即程序经理兼发布管理的角色，产品经理兼测试和用户体验的角色，开发人员即开发角色。,,例,2,，,按职能划分项目组的,产品管理项目组,可以是由如下角色组成,(,分工更加细致）：产品总体管理、产品规划、市场调研、市场工作、宣传、公共关系等。,,例,3,，,按职能划分项目组的,程序管理项目组,可以是由如下角色组成：程序总体管理、版本管理、项目协调、产品架构设计。,2.,组队模型,Team Model,2.5,组队模型的灵活应用,,例,4,，,开发角色也可以拥有内部的项目组结构，开发人员可以按照,用户层、业务逻辑层、数据层,的原则分成不同的团

21、队。例如，开发项目组：开发管理、用户界面、数据库、系统服务,,例,5,，,测试项目组：测试管理、压力、功能、集成、配置测试等,,例,6,，,用户体验项目组：用户体验管理、用户资源管理、媒体管理、文档编撰、本地化,,例,7,，,发布管理项目组：发布管理、系统管理、项目沟通、项目运营、渠道管理、支持平台、内部培训,,2.,组队模型,Team Model,2.6,组队模型中的交流和沟通,Communication,,在,MSF,组队模型中最重要的、最具有决定性的因素是交流和沟通。,,需要特别指出的是在，,MSF,组队模型中，项目组内部测试角色和开发角色之间的沟通直接影响着产品的质量，是项目组内部最为

22、关键的沟通渠道之一。,,,2.,组队模型,Team Model,2.6,组队模型中的交流和沟通,Communication,,两类沟通,——,基于商业视角和基于技术视角的沟通,,开发,测试,发布管理,产品管理,用户体验,程序管理,最,,终,,用,,户,最终用户,客,,户,商业视角,技术视角,业务,,设计,,和规,,划人,,员,技术委员会,运营和支持部门,3.MSF,过程模型,Process Model,MSF,过程模型是一种,基于里程碑的、目标驱动的开发模型,,MSF,过程模型包含,5,个主要阶段和,5,个主要里程碑,,MSF,过程模型中，项目均衡三角形起着至关重要的作用,3.MSF,过程模型

23、,Process Model,3.1,什么是,MSF,的过程模型,,软件开发项目的全过程,——,,（,1,）新项目的启动阶段,：提出项目设想，组建项目组，完成筹备工作,,（,2,）市场调研阶段：,调查相关产品的市场情况，寻找和设计产品未来的市场定位,,（,3,）技术论证阶段：,分析、论证产品在技术上的可行性，评估技术风险,3.MSF,过程模型,Process Model,3.1,什么是,MSF,的过程模型,,（,4,）项目计划和日程制定阶段：,设计和制定项目整体的进度表，为整个项目过程阶段划分工作阶段、界定任务目标。,,（,5,）管理层评审阶段：,寻求管理层对项目的认可。,,（,6,）产品特性

24、描述阶段：,将客户需求转变为产品特性，对其进行技术的精确描述。,,（,7,）资源分配阶段：,在项目组内、外调配项目的可用资源。,,（,8,）产品开发和发布阶段：,通过软件开发过程实现产品的所有特性，满足客户需求，发布到客户手中。,3.MSF,过程模型,Process Model,3.1,什么是,MSF,的过程模型,,MSF,过程模型,——,,是一种,基于阶段的、由里程碑驱动的、递进（螺旋）的软件开发模型。,,它可以用于传统的应用开发环境，也可用于电子商务、,WEB,分布式应用等企业级解决方案的开发和部署。,,,,,,里程碑,3.MSF,过程模型,Process Model,MSF,过程模型的特

25、点,,目标驱动而非任务驱动,,为什么要开发这个产品？,,产品为谁服务？,,最终要发布的产品将具备哪些特性？,,——,任何一项任务都必须围绕最终的项目目标制定，否则必须调整任务。,,外部可见的里程碑,,里程碑与工作阶段对应,应提交项的变更管理,,使用基线对源代码、系统配置、日程表、设计文档、用户手册、预算等应提交项进行变更管理,,——,项目中的所有变更的记录、跟踪、确认、回溯都依据已制定的基线来管理。,,递进的版本发布策略,,先有核心功能的版本,,再向其中添加功能,3.MSF,过程模型,Process Model,MSF,过程模型的特点,,风险驱动的进度管理,,风险最大的产品特性应当首先被安排开

26、发,,项目组集体参与,,项目开发的每一个特定阶段与一种特定的组队角色关联,——,责任与义务,,管理产品质量,,质量管理意识和方法,,质量保证策略,,贯穿项目始终,3.MSF,过程模型,Process Model,微软软件开发过程的基本原则,,制定计划时兼顾未来的不确定因素,,通过有效的风险管理减少不确定因素的影响,,经常生成,（,Daily Build),过渡版本并进行快速测试,（,生成验证测试,-Build Verification Test),来提高产品的稳定性及可预测性,——,确保每次,Check-in,都不会破坏产品的整体结构,快速循环、递进的开发过程,,从产品特性和成本控制出发创造性

27、地工作,,创建确定的进度表,,使用小项目组并发完成工作，并设置多个同步点,——,里程碑,,将大型项目分解成多个可管理的单元，以便更快地发布产品,——,可有效缩短产品发布周期,3.MSF,过程模型,Process Model,用产品的前景目标和概要说明来指导项目的开发工作,-,先基线化，后冻结,,避免产品走形,-,应当检查和审视当前状态是否和客户需要及产品的功能说明书相吻合,,使用概念验证原形进行开发前的测试,-,早期论证,,零缺陷观念,-,所有的,Bug,都在控制范围之内且可在适当时机得到修正,非责难式的里程碑评审会,,以改进工作为主要目的,,会议内容将对此后的项目过程产生影响,,3.MSF,

28、过程模型,Process Model,3.2,MSF,过程模型的阶段划分和里程碑设置,,1,前景,/,范围得到认可,,2,项目计划得到认可,,3,开发完成,,4,可发布版本准备就绪,,5,发布完成,,里程碑的使用可以帮助我们在项目的不同阶段中合理分配（,组队角色,）职责和义务，调动所有团队成员的积极性,3,2,1,4,5,计划阶段,构想阶段,开发阶段,稳定阶段,发布阶段,3.MSF,过程模型,Process Model,,1,构想阶段,,产品管理角色起推动作用,,提交项包括：,,前景范围说明书,,风险评估说明书,,项目组织结构说明书,角色,任务,产品管理,负责全面工作、确认用户需求、编写前景范

29、围说明书,程序管理,负责设计工作、概念设计、项目组织结构,开发,开发系统原型、技术选型、可行性分析,用户体验,收集用户在使用方面的需求和建议,测试,制定测试策略、建立测试标准,发布管理,运营和支持、建立运营标准,3.MSF,过程模型,Process Model,,2,计划阶段,,提交项包括：,,功能说明书,,风险管理计划,,项目总体计划书和总体进度表,角色,任务,产品管理,概念设计、业务需求分析、沟通计划,程序管理,概念设计和逻辑设计、功能说明书、项目总体计划书和进度表、预算,开发,技术验证、逻辑和物理设计、开发计划,/,进度表、开发预算,用户体验,编写使用情景和用例、用户需求、本地化,/,易

30、用性需求、用户文档,/,培训计划,/,进度表,测试,设计论证、测试需求说明书、测试计划,/,进度表,发布管理,设计论证、运营需求、发布计划,/,进度表,3.MSF,过程模型,Process Model,,3,开发阶段阶段,,提交项包括：,,源代码和可执行程序,,安装脚本和用于发布的配置信息,,已冻结的功能说明书,,关于产品使用的支持要素,,测试说明书和测试用例,角色,任务,产品管理,客户期望管理,程序管理,管理功能说明书、项目跟踪、更新项目计划,开发,代码编写、基础架构开发、编写配置文档,用户体验,培训、更新培训计划、可用性测试、图形界面设计,测试,功能测试、问题确认、文档测试、更新测试计划,

31、发布管理,发布清单、更新发布清单和发布计划、现场准备清单,3.MSF,过程模型,Process Model,4,稳定阶段,,应提交项包括：,,黄金版本,,版本注释,,关于产品性能的支持要素,,测试结果和测试工具,,源代码和可执行程序,,项目文档,,里程碑评审记录,建议的临时里程碑,,BUG,收敛,- BUG,数目呈持续减少,,零,BUG,弹跳,-,由于修改,BUG,暂时没有活动的,BUG,,候选版本,-,项目组可能发现不少新的,BUG,；可能不是最终发布的版本,,前生产阶段测试已经完成,-,准备一个先导版本,,可接受度测试完成,-,在非生产环境中用户认可（接受度测试和可用性测试）,,先导版本完

32、成,-,在尽可能真实的测试环境中对整体解决方案进行了足够的测试，该版本可在真实环境中测试了,,角色,任务,产品管理,执行沟通计划、制定执行计划,程序管理,项目跟踪、,BUG,优先级确定,开发,BUG,修正、代码优化,用户体验,稳定与用户使用相关的资源、培训资源,测试,测试、,BUG,报告和,BUG,状态、系统配置测试,发布管理,先导版本的安装和支持、发布计划、运营和支持人员,3.MSF,过程模型,Process Model,5,发布阶段,,应提交项包括：,,运营和支持信息系统,,程序和过程（,PROCEDURES AND PROCESSES,）,,知识库、报告、日志,,文档库：包含项目过程中产

33、生的所有版本的文档、资源和代码,,项目总结报告,,所有项目文档的最终版本,,客户,/,用户满意度调查数据,,下一步的工作计划,角色,任务,产品管理,客户反馈、评估、总结,程序管理,解决方案,/,范围比较、稳定管理,开发,问题解决、技术调整,用户体验,培训、培训进度管理,测试,用户使用测试、问题处理,发布管理,现场发布管理、变更确认,3.MSF,过程模型,Process Model,3.2 MSF,过程模型的交流和沟通,,至关重要,,成功的关键,,例如,产品管理角色：,用户提出需求变更,,程序管理角色：,可能带来什么影响？,,开发角色：,需要开发新的组件,,测试角色：,需要设计新的测试用例,,可

34、能在产品,,用户体验角色：,可能使最终用户产生困惑,3.MSF,过程模型,Process Model,项目管理中的均衡三角形,,产品功能,,通常情况下，产品功能是不能随便调整的,,资源,,进度（发布时间）,,由此，调整三者的指导原则：,在,资源,一定的情况下,,我们可以选择进度，并对产品功能做必要的调整；,,我们可以选择产品功能，并对进度做必要的调整；,,在,产品功能,一定的情况下,,我们可以选择资源，并对进度做必要的调整；,,我们可以选择进度，并对资源做必要的调整；,,在,进度,一定的情况下,,我们可以选择资源，并对产品功能做必要的调整；,,我们可以选择产品功能，并对资源做必要的调整。,4.

35、,程序经理与,IE,浏览器项目,V4.0,4. 1,什么是程序经理,,程序经理没有或很少拥有外部授予的权力，但却需要通过自己的努力工作赢得项目组成员的认可和尊重，赢得项目组内的组织权、协调权及与开发相关的决策权,——,对按时、保质地向客户提交正确的产品负有全部责任,。,项目组是针对项目需求临时组成的工作单元。工作人员主要来自产品部门下面的,三个部门,,一般的,项目组结构,产品部门总经理,测试部经理,开发部经理,程序经理部经理,程序经理组长,开发经理组长,,测试组长,,测试工程师,开发工程师,程序经理,程序经理,开发组长,,开发工程师,,开发工程师,,开发工程师,,开发工程师,测试组长,,测试工

36、程师,,测试工程师,,测试工程师,,测试工程师,产品经理,用户培训工程师,可用性测试工程师,界面设计工程师,三个部门,项目组结构,4.,程序经理与,IE,浏览器项目,V4.0,4. 2,程序经理与项目经理,,程序经理在项目组内享有的权力更多的是主动赢得的；管事；多人任职；编写技术文档等,,项目经理在项目组内享有的权力则是外部授予的（如奖惩权等）；管人；一人任职；一般不参与技术细节（如编写技术文档等）,,项目经理,,,,,,,,,,,,一人负责,管理人,管理项目,不写文档,多人负责,赢得的权力,授予的权力,写文档,4.,程序经理与,IE,浏览器项目,V4.0,4. 3,程序经理应该具备的素质和能

37、力,,程序经理必须具备以下三种核心素质：,,沟通能力（,C,ommunication),,电子邮件、会议（评审、项目组）、项目组网站、直接交流,,领导能力,(,L,eadership),,赢得权力、正确决策、推动产品发布、管理和预防风险,,协调能力,(,R,elationship),,我如何使大家工作得更出色？,,如何使用户认可我的产品？,,程序经理必须具备以下二种核心能力：,,核心能力,——,智商,,核心能力,——,情商,4.,程序经理与,IE,浏览器项目,V4.0,程序经理的核心能力,——,智商,,编码能力,,软件构架设计能力,,用户,-,学习技能,,用户界面设计技术,,API,和接口设计

38、能力,,书面的、口头的、正式和非正式的沟通能力,,演讲和展示能力,,理财能力,,熟悉商法、合同法、专利法和著作权法的基本内容,,市场调研能力,,掌握关于竞争对手的知识,,可以迅速掌握各种软件的使用方法,程序经理的核心能力,——,情商,,一个人成功的背后，智商所起的作用只有,10%,，而情商所起的作用可以占有,90%,。,“,学做事先学会做人,”,。,,聪明才智、,,领导才能、自我意识,,商业谈判能力,,用户移情能力,,对关键信息的敏感,,善于处理人际关系,,进度和项目管理能力,,时间管理能力,,组织心理学、组织技术,,团队行为学,,管理不同类型人员的能力,,招聘、面试和雇用技术,4.,程序经理

39、与,IE,浏览器项目,V4.0,4. 4 IE,V4.0,浏览器项目,,目标是在,1998,将市场占有率扩大到,65%,,人员大致构成（,96.8~97.6,）,,产品部门总经理,1,人,,产品规划员,5,人,,产品经理,20,人,,程序经理,50,人,,软件开发工程师,100,人,,软件测试工程师,100,人,,用户培训工程师,10,人,,IE5.0,大约,500,人,按产品特性形成项目组,,主要组织原则,,化整为零、相对独立、短小精悍、权责分明,,IE4.0,项目组分为,3,个大的项目组,,用户界面部分,,浏览器引擎部分,,服务器端应用部分,,结构同,4.1,中,项目组结构,,可能项目组被

40、分得更小,,子特性项目组,负责,1,个产品组件或几个产品特性的开发,4.,程序经理与,IE,浏览器项目,V4.0,4. 5 IE,V4.0,浏览器项目工作流程,,按照如下阶段管理,,计划阶段,,开发阶段,,稳定阶段,,发布阶段,,总结阶段,,开始下一个版本周期,4.,程序经理与,IE,浏览器项目,V4.0,项目前景和产品目标,,IE,将成为,INTERNET,上的主流浏览器软件,,为客户和最终用户端提供高速、稳定、总体拥有成本最低,,与,MS-OFFICE,有效集成,,在,1998,年市场占有率扩大到,65%,一般工作流程,,确认商业机会，制定宏观的商业计划,,准备项目计划草案,,项目组内的头

41、脑风暴会议，明确产品特性,,编写单页功能说明书（包括产品特性的优先级、资源预算、进度预期和风险预期等）,,汇总产品特性、开发进度和相应的里程碑设置,,计划阶段,,一般工作流程,,项目前景和产品目标,,产品里程碑确定,,产品特性的概要和详细设计,产品里程碑确定,,6,月,25,日，提交前景和目标说明,,7,月,1,日，单页功能说明书,,7,月,15,日，详细功能说明书,,9,月,1,日，引擎代码开发完成,,10,月,8,日，用户界面代码开发完成,,11,月,7,日，发布候选版本,,11,月,9,日，发布,BETA-1,版本（内部员工测试）,,4,月,5,日，发布,BETA-2,版本（外部公开测试

42、）,,7,月,12,日，发布正式版本（,RTM,）,产品特性的概要和详细设计,,一份设计文档的基本章节结构：,,责任人,/,作者,,概述,,指导原则,,情景设计描述,,产品特性设计,,安全设计,,安装和发布,,国际化、本地化,,存在问题,,更新历史,4.,程序经理与,IE,浏览器项目,V4.0,开发阶段,,开发计划工作,,安装、配置开发环境,,代码检入工作（,Check-in),,每日产品生成,(Daily build),,管理,Bug,数据库,1,开发阶段,,开发工程师,：,,审核功能说明书等设计文档,,列出工作任务列表,,估计工作时间,,程序经理：,,主持项目组开会讨论所有的工作任务,,平

43、衡项目组各成员的工作负荷,,测试组长：,,为开发人员指派结伴的,BUDDY,测试员,,BUDDY,测试员编写详细的测试用例,,2,安装、配置开发环境,,开发工程师：,,配置源代码的目录结构，每个产品特性项目组管理一个字目录,,制定检入进度表和检入制度,,测试,/,生成工程师：,,准备编译、生成用的计算机和服务器,,制定生成计划,,安装、配置,BUG,数据库,,程序经理的工作：,,安装、配置项目组网站，定义项目组邮件信箱,,制定项目组会议计划,3,代码检入工作（,Check-in),,同步代码，每人先生成自己的版本以保证新代码与原版本树不发生冲突；,,在检入前做代码审查（提前发现,Bug,并由第

44、二个程序员检验和认可）；,,检入时，代码必须满足检入条件（即 通过了,BVT,（,Build Verification Test),和其他测试，且满足最低测试要求）；,,遵守检入窗口制度，即在大项目组中，不同功能开发人员在不同的规定时间检入他们的代码，这样容易定位,Bug,；,,发送检入邮件通知项目组（包括代码变更目的、代码审查员、修改过的文件和测试条件等）。,4,代码检入工作（,Check-in),,整个生成过程都是自动完成的；,,每天的同一时间，通过同步所有项目组件，创建一个源代码树的拷贝；,,编译生成所有的组件；,,运行,BVT,测试，检验生成版本的可用性；,,向项目组发送状态报告邮件,

45、,发送每日同步日志，在公共服务器上公布生成后的产品版本。,5,管理,Bug,数据库,,每个产品都有一个集中的,Bug,数据库；,,大多数,Bug,记录（包括代码缺陷和不完善的产品特性）都是由测试人员创建的；,,程序经理负责每天审核,Bug,数据库，并为开发人员分配,Bug,修改工作,,开发人员修正,Bug,并将结果发回给测试人员；,,测试人员使用每日生成来检验,Bug,是否已经修正， 并修改,Bug,记录。若确定已经更正，则关闭,Bug,。,4.,程序经理与,IE,浏览器项目,V4.0,稳定阶段,,产品特性冻结,,代码完成,,用户界面冻结,,BETA,版本发布,,1,产品特性冻结,,所有的产品

46、变更必须经过一个特殊的管理过程，项目组开会审查和确定是否允许变更。,,应当有明确的、严格的变更标准,,在产品特性冻结之后，可能引发产品特性变更的一些特殊因素：,,最终用户新提出的反馈意见,,竞争对手的新产品中增加了新的特性,,刚赢得的一个大客户提出了新的需求,,其他部门的需求,,法律问题,2,代码完成,,意味着,,开发人员完成了所有的编码任务，所有产品特性都已被检入到代码库中,,测试人员开始做系统的集成测试,,程序经理每天评审、监控和分配,BUG,修改工作,,开发人员开始修正,BUG,3,用户界面冻结,,意味着：,,用户界面的样式和提示信息不再发生变更,,用户培训工程师开始编写联机帮助手册和用

47、户手册,,开始本地化工作,,任何改动都必须经过项目组和负责用户界面国际化的程序经理审核通过,,对每个变更都必须仔细跟踪和管理,4 BETA,版本发布,,为外部客户提供一个特殊的测试版本,,包含基本特性和功能,,目的是收集客户的反馈信息,,作用是扩展测试队伍和测试平台,,可以稳定产品、提高产品质量,,可以促进项目组之间产品的集成,,可以推动合作伙伴的项目进展,4.,程序经理与,IE,浏览器项目,V4.0,发布阶段,,到达零,BUG,日期,,发布侯选版本,,源代码树分支,,正式发布版本,,签字认可,,1,到达零,BUG,日期,,数据库中所有已知,BUG,都被处理（被更正或被推迟或不予修改）,,测试

48、人员将要开始第二轮全面测试,,项目组会议每天将讨论、评审新的,BUG,,在新条件下重新评定优先级，优先级较高的,BUG,必须在,24,小时内修正,2,发布侯选版本,,数据库中所有已知的优先级较高的,BUG,都已被修正,,新的,BUG,将成为影响产品发布的瑕疵，,,不太重要的新的,BUG,有可能被推迟到下一版本中修正,,开发人员必须在,24,小时内修正新发现的重大,BUG,,新发现的,BUG,被修正之后，项目组将发布一个新的候选版本,,新的候选版本必须通过完整的回归测试,,对于大项目来说，项目组的变更标准更高一些,,例，,IE4.0,发布的候选版本经过,14,个。,3,源代码树分支,,在当前一个

49、版本开始之前，下一个版本的开发工作已经开始,,一些程序经理开始为下一个版本设计产品特性,,源代码树分支的同时，复制当前的源代码树,,开发人员的精力大多投入到新的版本的开发过程中,,只有对影响发布的,BUG,的修正会被合并到当前版本树中来，其他的,BUG,修正和新开发的产品特性都只存在于新的版本的源代码中,4,正式发布版本和签字认可,,发布的两种形式,——,基于盒装产品发布和基于,WEB,发布,,只有修正了所有影响发布的重大,BUG,之后，测试人员才能签字认可最终的可发布版本,,签字认可后，如果发现了影响发布的,BUG,，就需要紧急从生产线上,“,召回,”,正在生产的产品，修正后再次发布。,,“

50、,召回,”,需经过一定级别的人员签字认可。,,测试人员最终为正式发布版本签字，程序经理也需要在包含可发布程序的盘上签字确认,,产品发布后，开庆祝会,4.,程序经理与,IE,浏览器项目,V4.0,总结阶段和开始下一个版本周期,,程序经理负责召集项目组的总结会,,每个项目组成员都需要准备一份总结报告并发言,,会议可能持续几天，包括大型的和小型的,,目的在于改进开发过程和提高开发水平,,会议结束前，每个项目组和每个项目组成员都应该在下一次开发过程中提出行动计划,4.,程序经理与,IE,浏览器项目,V4.0,4. 6,微软过程管理策略,,基于客户需求决定产品的特性集合及优先级关系,,使用前景,/,目标

51、描述文档和概要性的功能说明书指导项目工作,,将项目过程划分为基于里程碑驱动的多个工作阶段,（,1989,年开始严格使用里程碑管理和每日生成制度）,,使用定量的数据来检验里程碑的完成情况,,使用组件化的设计方式，将产品结构和项目结构有机结合,,多个项目组并行开发，在每日生成时完成项目间的同步,,总是拥有理论上的、可发布的产品，包括所有主要的版本,,不断生成和测试产品,5.,软件测试,5. 1,软件测试,,是执行程序或系统以期发现错误的过程。,,是评估程序或系统特性的工作的总称，是衡量软件质量的标尺。,,是一个设计、使用和管理用以度量并改进被测软件质量的测试工具的并行生命周期。,,是用规范的或不规

52、范的方法来对软件进行攻击和破坏，以期寻找软件的缺陷和漏洞。,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.,软件测试,测试组人员的责任,,测试组的软件开发工程师,,具备

53、代码编写的能力和开发工具软件的经验，主要负责自动化测试工具和测试脚本的开发。,,软件测试工程师：主要负责测试软件产品，分为,,BTV,工程师,-,负责保证每日生成的软件版本可顺利执行，确认已开发完成的所有功能模块都已连入产品，且主要功能正确无误。,,功能测试工程师,-,负责对某个特定组件或某组特性测试。,,可用性测试,工程师,-,负责产品中与操作流程、用户界面相关的部分，确保产品在最终使用方式上满足用户的需求。,,测试专家（,AD hoc Tester)-,经验丰富、对产品体系结构和实现方法了如指掌的且能使用各种方法对软件进行测试的人员。,,测试实验室工程师,,负责管理和维护测试环境（硬件平台

54、、网络架构和软件环境）。,5.,软件测试,5. 3,测试角色在不同项目阶段中的工作任务,,构想阶段,,制定测试策略、建立测试标准,,计划阶段,,设计论证、编写测试需求说明书、制定测试计划,/,进度表,,开发阶段,,功能测试、问题确认、文档测试、更新测试计划,,稳定阶段,,功能和性能测试、错误报告和错误状态、系统配置测试,,发布阶段,,用户使用测试、问题处理,5.,软件测试,5. 4,测试中,BUG,的跟踪和管理,,BUG,是指软件在使用中出现的所有存在争议的问题（,ERROR,和,DEFECT,）。,,测试人员的一项重要使命是对所有已知,BUG,进行有效跟踪和管理。,,BUG,的状态,,已修正

55、、重复、可推迟、设计问题、不可再现、无需修正,,BUG,关闭：经过验证确认已正确处理的,BUG,被标记为关闭状态。,BUG,报告,,测试工程师,BUG,处理,,开发工程师,BUG,评估和分配,,程序经理,BUG,关闭,,测试工程师,,,BUG,5.,软件测试,5. 5,测试的分类,,5. 5 .1,覆盖测试,和,使用测试,,覆盖测试,,单元测试（最小代码单元）,,功能或特性测试,,检入（,CHECK-IN,）测试,,BVT,测试,,回归测试,使用测试,,配置测试,,兼容性测试,,压力测试,,性能测试,,文档和帮助文件测试,,Alpha,（内）和,Beta,（外）测试,5.,软件测试,,5. 5

56、 .2,白盒和黑盒测试,,白盒测试,,代码覆盖,,流程覆盖,,系统内部结构,,黑盒测试,,可接受度测试,BVT,,Alpha,和,Beta,测试,,菜单,/,帮助测试,,发布测试,,回归测试,,RMT,准备生产测试（,Ready to Manufacture Testing,刻盘前,),黑盒测试,,功能测试和系统测试,,验证功能说明书的完整和正确,,正确性,,可用性,,边界条件,,性能,,压力,,错误覆盖,（验证是否对错误进行妥善处理）,,安全,,兼容性,,配置,,安装,5.,软件测试,5. 6,测试工具,,自动测试工具,,配置管理工具,,项目管理工具,,缺陷跟踪工具,,调试工具,基本测试工具

57、包括的内容,,测试人员、计算机、,OS,、办公软件,,摄像和录像系统,,秒表,,BUG,跟踪系统,,自动化脚本工具,,软件、硬件诊断工具,,文件比较工具、文件查看工具,,文件格式转换工具,,内存管理工具,,屏幕捕捉工具,5.,软件测试,5. 7,测试文档,,测试计划,,测试说明书,,测试用例,,BUG,报告,,测试结果报告,,工作报告,测试计划,,编写之前应该获得以下文档,,程序经理编写的产品功能说明书,,或产品特性开发计划,,程序经理或开发人员提供的开发进度表,,5.,软件测试,测试计划包括,,测试目标和发布条件,,测试目标描述,,达到何种测试目标的前提才可以发布某个特定版本,,对每个发布条

58、件定义详细的里程碑,,待测产品范围,,主要特性,/,功能说明,,特性,/,功能测试一览,,相应的测试说明书的位置,,测试方法描述,,定义使用的测试方法,,描述每一种特定的测试方法可以覆盖哪些测试范围,测试进度表,,定义里程碑,,当前里程碑的详细测试进度,,描述测试进度与程序经理或开发人员制定的开发进度之间的关系,,测试资源和相关的程序经理,/,开发工程师,,定义参与测试的人员,,描述职责范围,,给出与测试人员有关的的信息,,程序经理或开发人员编写的文档的位置,,配置范围和测试工具,,所用计算机列表,,测试覆盖了哪些硬件设备,,测试时使用的主要测试工具,5.,软件测试,测试说明书,,编写之前应该

59、获得以下文档,,程序经理编写的产品功能说明书,,（与该产品范围相关的部分）,,程序经理或开发人员提供的开发进度表（与该产品范围相关的部分）,背景信息,,产品功能说明书位置（路径）,,参与人员、文档的修改,/,编辑记录,,待测产品特性,,单独的待测产品特性、产品范围的特性组合,,与其他产品范围内的特性有集成关系的产品特性、产品特性的分解,,测试未覆盖到的产品特性说明,,功能描述,,详细的待测功能，包括菜单、热键、对话框、错误信息和帮助文档,,测试描述,,边界条件测试、使用的语言,,系统测试、黑盒测试,,测试情景设计,,描述在何种条件下、使用何种测试方法、通过哪些测试步骤、预期得到何种测试结果,5

60、.,软件测试,测试用例,,设计之前应该获得以下文档,,程序经理编写的产品功能说明书,,详细的测试说明书,测试用例文档一般包括下列环节,,根据测试说明书中的测试情景设计，开发一组测试用例,,根据测试过程中的反馈信息，增加更多的测试用例,,根据测试所发现的,BUG,情况，增加更多的测试用例,,5.,软件测试,BUG,报告,,BUG,主题,/,标题,,测试使用的系统平台,,测试时使用的软件版本,,BUG,优先级和重要程度,,重现该,BUG,的步骤,,实际结果,,预期结果,,其他相关信息,测试结果报告,,当前测试进度和状态,,仍然存在的,BUG,列表,,新发现的,BUG,列表,,已处理或已关闭的,BU

61、G,列表,,测试工作与过去相比的改进之处,,新的工作目标,,测试是否按计划完成？,5.,软件测试,工作报告,,工作概述,,工作详情,,主要完成了什么,,BUG,报告,,未关闭的,BUG,,已关闭的,BUG,,下一周工作计划,,计划完成什么,,测试工程师的来源,,程序员中选拔,,专职培养,,其他行业有经验的职员,,普通用户,,……,5.,应用模型,Application Model,1.,什么是应用模型,,,应用模型针对软件设计和开发工作提供了一种逻辑上的、基于三层结构的、基于服务网络的方法体系,。,,MSF,在逻辑上将应用程序看成是一个相互作用的、由消费者和服务提供者组成的服务网络。,,服务可

62、以跨越物理上或功能上的节点边界，部署在分布式的网络环境中，也可以被不同的应用程序复用，满足用户的需求。包括,三类服务。,5.,应用模型,Application Model,2.,应用模型中的三类服务,,用户服务,,与用户界面、用户体验、用户操作、用户支持相关的功能组件，通常在客户端实现。,,业务服务,,实现系统的业务逻辑，在业务层面上提供可复用组件的服务层次。业务服务对数据服务的系统数据进行加工和计算，并将处理结果传送到用户服务显示或输出。,,数据服务,,管理和维护系统的数据资料，为业务服务或用户服务提供数据支持的服务单元。,5.,应用模型,Application Model,3.,应用模型与其他模型的关系,,模型之间的关系与项目成败的三个关键因素,-,资源、进度、功能特性,-,相关,,组队模型是管理和控制,项目资源,的有效手段,,过程模型与,项目进度,管理密切相关,,应用模型被用于管理,产品的功能特性,,4.MSF,中的各种模型的适用范围,,可以适用于不同规模的组织结构和不同类型的,IT,项目，可以为软件项目提供从项目组织规划到产品发布管理的全方位的指导和帮助。,