微软软件开发流程实施

《微软软件开发流程实施》由会员分享，可在线阅读，更多相关《微软软件开发流程实施（36页珍藏版）》请在金锄头文库上搜索。

1、微软软件开发流程实施,Wendy Fan 范文峰 微软全球技术中心 项目专员 2002/5/20,现存问题,测试团队没有权威,没有明确的质量标准和员工度量标准 团队成员之间缺乏有效沟通 实现的功能不是最初的设计目标,既产品规格和产品开发的一致性 产品规格更改维护 产品进度无法控制 测试计划 文档管理,解决方法,软件开发过程管理 资源管理,包括管理时间,管理成本,管理人员 产品管理,管理功能,实现,质量 实施步骤 团队建立-一个高效的团队具有如下特征 目标一致,信念明确 积极有效沟通,不要假设别人已经知道 主动做事,主动促进流程改进,主动回复别人EMAIL等,主动共享信息 通过Process使成

2、员各司其职,每件事情必须有负责人 数字化管理 实现方式:流程+工具+文档+数字,实施考虑,软件流程改进实施前提条件-作为软件企业的ERP系统,改变必然涉及每一个人的日常工作和思维方式,必须有强有力的领导支持和自适应的能力. 企业已经建立了有效的邮件管理机制和信息共享机制(通过内部站点共享知识库,资源等). 潜意识的有效沟通-使每一次需求更改都被所有的团队成员知道 高效率协作,没有权利而是依靠权威和知识领先性的管理方法,结果是高创造性 积极工作,发表意见,改进流程 实施误区 不考虑企业自身的情况,盲目实施流程 过度强调工具的重要性:如过度强调自动化测试工具而忽略了测试,流程改进本质-注重沟通,强

3、调沟通,更注重实用性 团队成员之间的相互牵制,三权分立; 程序经理 开发组 测试组 沟通不会自动发生 日常会议 TRD 里程碑总结(PostMotem) 每日,每周汇报 Bug Triage Meeting One one review,流程改进本质-使软件开发可控制,使软件过程开发成为一个可控制的过程 数字化管理: 基于数字的软件开发度量 树立时间计划的权威性,有效控制时间 软件产品有清晰的标准:功能规格书(Functional Specification)作为全组的标准,必须具有权威性 基于功能的进度计划和多个检查点保证所有的功能实现符合功能规格书,流程改进本质-持续主动调整,必须专门的人

4、员监测整个软件开发流程,并加以调整.将尽可能多的流程书面化. 制定六大服务器的OWNER. 流程的不断变化和不同时期角色的工作重点调整,项目初始化(一),软件企业需要一个能够满足缺陷跟踪和管理的工具,同时能够为决策提供支持. 市场调查(市场人员),并给出产品需求书 产品前景 目标用户 产品包和构件 平台支持,硬件和软件环境 语言支持 功能要求 管理层决定实施该项目,并决定PM, Test Lead, Dev Lead人选 管理层决定Review Meeting的时间 完成Vision Statement(前景陈述),项目初始化(二),项目动员大会 Audience 听众:所有可得到的人力资源

5、主题 宣布项目开始 项目前景陈述 团队组织 人力资源获得: 招聘+培训 项目发布时间,工作准则-明确准则,积极工作,PM的工作 进度监控,树立Spec和Schedule的权威性 沟通中心,对内确保每一个理解产品的前景,功能和对外确保管理层的支持和满足顾客需求 PM一般是整个TEAM的凝聚力所在 PM的主要工作以写Spec,开会和查看EmailL,进度监控,查看BUG数据库和沟通为主 Dev Lead 的工作 通过Code Review代码审核提供高质量代码 制定合理的时间计划 技术选型,代码重利用从而达到按时完成代码 总体构架设计和通用程序设计 团队成员沟通 Test Lead的工作 测试环境

6、的建立 测试策略制订 测试方法和工具的选用 测试案例的维护 发布测试报告,M0,其它工作,人员培训,熟练掌握各种工具. 建立源代码服务器,培训TEAM MEMBER使用版本控制工具.确定各团队工作目录 确定常规会议,如周项目状态会议 新员工工作手册,使新的员工能够非常清楚的知道各个Server和环境安装,及工作流程 建立Build服务器和Release服务器 测试团队建立BUG数据库服务器 建立团队工作信息发布站点,发布团队新闻,共享文档资源,Team Member联系方式,任务列表等.,文档模板-Function Specification,人力资源+Feature Team(功能团队) 前

7、景描述 平台要求 语言支持(本地化和全球化) 出错处理(日志,警告,信息)和最终返回错误信息 用户场景(User Scenarios) 功能细分和说明 安装程序 快捷键要求 性能目标 用户教育文档和进度计划 进度计划 (Microsoft Project) UI 设计文档,文档模板-Implementation spec,实现文档是一个文档集,包括数据字典 资源管理,指定Builder, BVT 所有者,Peer Review 开发环境,技术选型,程序构架和设计模式 代码重用 模块划分 出错处理 多语言支持 性能考虑 数据库设计 公用接口设计,文档模板-测试计划(一),测试环境描述,包括服务器

8、,安装程序描述 人力资源划分 测试流程及不同阶段的测试重点 功能完备性测试 测试目标,范围和质量标准 测试区域划分 易用性测试 性能测试 可靠性测试 平台测试(使用矩阵) 恢复测试 回归测试 缺陷跟踪工具,文档模板-测试计划(二),测试策略描述,频率和所有者 测试案例开发和维护,制订测试案例覆盖标准 自动化工具开发,决定何时进行自动化工具开发 存在大量的API和大量的测试案例 测试案例只需要结果”通过”或”不通过”,不需要用户的干预 有大量的回归测试案例 雇开发人员写自动化工具比雇多个TESTER便宜 测试脚本开发 测试工具 源代码分析工具 测试进度,如何实现成功的进度计划,进度计划 由整个开

9、发团队来制定进度计划而不是PM单独制定 事情无论大小,全部列入计划或算进缓冲 保证进度计划的权威性. 可以将进度计划贴在作战会议或工作房间的墙壁上 PM必须非常清楚最重要的事情并推动执行.尤其是在不同的里程碑切换时.并将这一信息传达给全组. 在制订计划时,必须考虑到会议,假期,汇报工作,单元测试,病假,解决缺陷和不可预料的事件.缓冲一般为30%50%.在固定发布日期条件下,尤其应该增长缓冲.,如何实现成功的进度控制,监控和度量 每天队员发Daily Report, 它的格式: Highlight Shortcoming To Do List 每周PM发Weekly Report, Dev Le

10、ad和Test Lead分别发Weekly Report对当前项目状态进行总结,这些REPORT的听众必须是所有团队成员,包括管理人员. 周报的格式和日报格式相同 在周报中安排除了日常工作以外的其它必须检查的事宜.这可以补充进度计划的不足. 每周召开团队会议, 总结项目当前状态.,M1,工作流程(一),DEVELOPER检查BUG数据库和电子邮件.如果发现自己的BUG数量高于给定值,则停止开发,更改BUG. PM和LEAD检查BUG数据库和电子邮件.指定BUG给某一个TEAM MEMBER.如果可争议BUG太多,召开BUG TRIAGE会议,讨论BUG的优先级. 每天的RELEASE中需要包含

11、说明文件(本版本更正BUG,实现功能,改变的文件),如果是API测试应包含类库文档,工作流程(二),DEVELOPER每天早上从源代码服务器下载代码,更新其它程序员的改变. (SD SYNC) DEV编辑自己的文件 (SD EDIT),完成某个FEATURE. DEV编译自己的本地源代码拷贝并进行单元测试,如无错误,交给BUDDY TESTER或CODE REVIEW测试. 如果没有错误,提交到源代码服务器.通过这种方法保证源代码服务器中的程序始终是可运行的. 如果本次CHECK IN完成了某一个功能,发送TRD到TEST TEAM,证明此功能已完成并可测试 DEV发送日报. DEV LEAD

12、指定专门的BUILDER和BVT人员.并写成BUILD SCRIPT.每天在固定的时间运行该BUILD SCRIPT.如,每天2:00AM. 每天早上9:00-9:30对当天的BUILD进行BVT和冒烟测试,通过后提交到RELEASE服务器.,工作流程(三),TEST TEAM指定专门的可接受测试人员,并给出可接受的标准.9:30-10:00,指定的测试人员每天早上运行可接受测试,如果成功发EMAIL给全组. 其它测试人员开始进行功能测试.功能测试仅测试那些已经发出TRD的功能. TEST TEAM发现BUG,并登记在BUG数据库中. TEST TEAM进行其它测试,如性能测试,本地测试和平台

13、测试.测试频率和目标在TEST计划中制定.如果是MILESTONE结束时,运行所有测试案例. TEST TEAM根据TEST计划开发TEST CASE,编写自动化工具和测试脚本. TEST TEAM发送日报表,使用源代码控制工具,放入源文件,文档资料和所有频繁改动的资料 不要放入二进制代码,包括动态库和可执行文件 只编辑需要改动的编码(SD EDIT) 每次Check In时,填写变化列表. 每次Check In 之前,保证本地编译通过,并通过代码审核 建立每日Release的源代码标签,便于回滚到某一个特定的Build时的源代码.,管理你的BUG数据库,建立并备份你的BUG数据库 定义BUG

14、管理流程 清楚地定义BUG类别和属性 建立起BUG的权威性,如果一个BUG可以方便地被重现,该BUG必须被修复. 设定BUG数上限 DEV不能选择”不修复”和”设计”作为一个BUG的解决方案 遇到争论时,BUG被指定给COMMITTEE,由COMMITTEE作出决定.COMMITTEE一般由PM,DEV LEAD和TEST LEAD组成. 监测BUG数据库,利用数字标准作为衡量标准,并使全组人员知道这些数字.,软件开发度量(一),前提条件,在实施的过程中和过程后收集大量数据 项目开发过程中的数据收集 每日,每周登记的缺陷和解决的缺陷(按照严重性统计) 跟踪每日已激活缺陷和已解决缺陷数目 Fix

15、ed 缺陷数目;已解决的缺陷数目(除去重复和不可重复缺陷) 跟踪缺陷重新激活次数 缺陷的发现途径:随即测试,测试案例开发,可接受性测试 解决缺陷的平均时间 关闭缺陷的平均时间 最老的缺陷,软件开发度量(二),总结过程中的数据收集 不同等级的缺陷百分比 计划的测试工作量 实际的测试工作量 “SHOW STOPPER”缺陷的产生原因: 缺乏测试案例 由于修改其它缺陷引起的新缺陷, 测试区域划分导致没有进行测试, 回归测试 配置测试,不是所有的机器上都可以重现错误 规范不完整 最后加的功能,如何作Code Review(代码审核),标志代码错误,如通过编译检查的代码拼写错误,违反编码规范,硬编码(h

16、ard code)字符串和配置; 标明算法错误,如选择错误的算法或没考虑边界情况. 标志潜在的回归式错误 标志可改进的地方 教育开发人员 Code Review的步骤 代码应该在多个平台上编译成功 代码首先必须被开发人员测试过.使用DEBUGGER单步执行,或添加跟踪语句. 代码必须被提交给代码审核者, 使用Windiff工具比较不同 代码审核的结果应该是接受,有条件的接受和拒绝 代码审核的结果必须在下次审核之前更正,并提交.,代码审核Check List,是否符合编码规范 是否有HARD CODE字符串 是否使用数字来定义数组大小,而不是使用常量或宏 是否自己写代码而不使用类库 开发人员是否误解了类库的参数 开发者是否假定某一平台来开发程序,从而在其它平台上不能运行 是否去除了代码,而忘了另外一个地方 是否考虑了边界条件 是否在DEBUG版本中使用ASSERT 代码是否具有可读性? 开发者对代码的变化是否会引起其它的BUG 是否能够通过去除代码来提高性能 变化是否在文档中更新以便维护? 代码变化是否和其它人有关?,Code Complete & System Testing,测试最佳经验,