微软软件开发流程实施.ppt

微软软件开发流程实施 WendyFan范文峰微软全球技术中心项目专员2002 5 20 现存问题 测试团队没有权威 没有明确的质量标准和员工度量标准团队成员之间缺乏有效沟通实现的功能不是最初的设计目标 既产品规格和产品开发的一致性产品规格更改维护产品进度无法控制测试计划文档管理 解决方法 软件开发过程管理资源管理 包括管理时间 管理成本 管理人员产品管理 管理功能 实现 质量实施步骤团队建立 一个高效的团队具有如下特征目标一致 信念明确积极有效沟通 不要假设别人已经知道主动做事 主动促进流程改进 主动回复别人EMAIL等 主动共享信息通过Process使成员各司其职 每件事情必须有负责人数字化管理实现方式 流程 工具 文档 数字 实施考虑 软件流程改进实施前提条件 作为软件企业的ERP系统 改变必然涉及每一个人的日常工作和思维方式 必须有强有力的领导支持和自适应的能力 企业已经建立了有效的邮件管理机制和信息共享机制 通过内部站点共享知识库 资源等 潜意识的有效沟通 使每一次需求更改都被所有的团队成员知道高效率协作 没有权利而是依靠权威和知识领先性的管理方法 结果是高创造性积极工作 发表意见 改进流程实施误区不考虑企业自身的情况 盲目实施流程过度强调工具的重要性 如过度强调自动化测试工具而忽略了测试 流程改进本质 注重沟通 强调沟通 更注重实用性团队成员之间的相互牵制 三权分立 程序经理开发组测试组沟通不会自动发生日常会议TRD里程碑总结 PostMotem 每日 每周汇报BugTriageMeetingOneonereview 流程改进本质 使软件开发可控制 使软件过程开发成为一个可控制的过程数字化管理 基于数字的软件开发度量树立时间计划的权威性 有效控制时间软件产品有清晰的标准 功能规格书 FunctionalSpecification 作为全组的标准 必须具有权威性基于功能的进度计划和多个检查点保证所有的功能实现符合功能规格书 流程改进本质 持续主动调整 必须专门的人员监测整个软件开发流程 并加以调整 将尽可能多的流程书面化 制定六大服务器的OWNER 流程的不断变化和不同时期角色的工作重点调整 项目初始化 一 软件企业需要一个能够满足缺陷跟踪和管理的工具 同时能够为决策提供支持 市场调查 市场人员 并给出产品需求书产品前景目标用户产品包和构件平台支持 硬件和软件环境语言支持功能要求管理层决定实施该项目 并决定PM TestLead DevLead人选管理层决定ReviewMeeting的时间完成VisionStatement 前景陈述 项目初始化 二 项目动员大会Audience听众 所有可得到的人力资源主题宣布项目开始项目前景陈述团队组织人力资源获得 招聘 培训项目发布时间 工作准则 明确准则 积极工作 PM的工作进度监控 树立Spec和Schedule的权威性沟通中心 对内确保每一个理解产品的前景 功能和对外确保管理层的支持和满足顾客需求PM一般是整个TEAM的凝聚力所在PM的主要工作以写Spec 开会和查看EmailL 进度监控 查看BUG数据库和沟通为主DevLead的工作通过CodeReview代码审核提供高质量代码制定合理的时间计划技术选型 代码重利用从而达到按时完成代码总体构架设计和通用程序设计团队成员沟通TestLead的工作测试环境的建立测试策略制订测试方法和工具的选用测试案例的维护发布测试报告 M0 其它工作 人员培训 熟练掌握各种工具 建立源代码服务器 培训TEAMMEMBER使用版本控制工具 确定各团队工作目录确定常规会议 如周项目状态会议新员工工作手册 使新的员工能够非常清楚的知道各个Server和环境安装 及工作流程建立Build服务器和Release服务器测试团队建立BUG数据库服务器建立团队工作信息发布站点 发布团队新闻 共享文档资源 TeamMember联系方式 任务列表等 文档模板 FunctionSpecification 人力资源 FeatureTeam 功能团队 前景描述平台要求语言支持 本地化和全球化 出错处理 日志 警告 信息 和最终返回错误信息用户场景 UserScenarios 功能细分和说明安装程序快捷键要求性能目标用户教育文档和进度计划进度计划 MicrosoftProject UI设计文档 文档模板 Implementationspec 实现文档是一个文档集 包括数据字典资源管理 指定Builder BVT所有者 PeerReview开发环境 技术选型 程序构架和设计模式代码重用模块划分出错处理多语言支持性能考虑数据库设计公用接口设计 文档模板 测试计划 一 测试环境描述 包括服务器 安装程序描述人力资源划分测试流程及不同阶段的测试重点功能完备性测试测试目标 范围和质量标准测试区域划分易用性测试性能测试可靠性测试平台测试 使用矩阵 恢复测试回归测试缺陷跟踪工具 文档模板 测试计划 二 测试策略描述 频率和所有者测试案例开发和维护 制订测试案例覆盖标准自动化工具开发 决定何时进行自动化工具开发存在大量的API和大量的测试案例测试案例只需要结果 通过 或 不通过 不需要用户的干预有大量的回归测试案例雇开发人员写自动化工具比雇多个TESTER便宜测试脚本开发测试工具源代码分析工具测试进度 如何实现成功的进度计划 进度计划由整个开发团队来制定进度计划而不是PM单独制定事情无论大小 全部列入计划或算进缓冲保证进度计划的权威性 可以将进度计划贴在作战会议或工作房间的墙壁上PM必须非常清楚最重要的事情并推动执行 尤其是在不同的里程碑切换时 并将这一信息传达给全组 在制订计划时 必须考虑到会议 假期 汇报工作 单元测试 病假 解决缺陷和不可预料的事件 缓冲一般为30 50 在固定发布日期条件下 尤其应该增长缓冲 如何实现成功的进度控制 监控和度量每天队员发DailyReport 它的格式 HighlightShortcomingToDoList每周PM发WeeklyReport DevLead和TestLead分别发WeeklyReport对当前项目状态进行总结 这些REPORT的听众必须是所有团队成员 包括管理人员 周报的格式和日报格式相同在周报中安排除了日常工作以外的其它必须检查的事宜 这可以补充进度计划的不足 每周召开团队会议 总结项目当前状态 M1 工作流程 一 DEVELOPER检查BUG数据库和电子邮件 如果发现自己的BUG数量高于给定值 则停止开发 更改BUG PM和LEAD检查BUG数据库和电子邮件 指定BUG给某一个TEAMMEMBER 如果可争议BUG太多 召开BUGTRIAGE会议 讨论BUG的优先级 每天的RELEASE中需要包含说明文件 本版本更正BUG 实现功能 改变的文件 如果是API测试应包含类库文档 工作流程 二 DEVELOPER每天早上从源代码服务器下载代码 更新其它程序员的改变 SDSYNC DEV编辑自己的文件 SDEDIT 完成某个FEATURE DEV编译自己的本地源代码拷贝并进行单元测试 如无错误 交给BUDDYTESTER或CODEREVIEW测试 如果没有错误 提交到源代码服务器 通过这种方法保证源代码服务器中的程序始终是可运行的 如果本次CHECKIN完成了某一个功能 发送TRD到TESTTEAM 证明此功能已完成并可测试DEV发送日报 DEVLEAD指定专门的BUILDER和BVT人员 并写成BUILDSCRIPT 每天在固定的时间运行该BUILDSCRIPT 如 每天2 00AM 每天早上9 00 9 30对当天的BUILD进行BVT和冒烟测试 通过后提交到RELEASE服务器 工作流程 三 TESTTEAM指定专门的可接受测试人员 并给出可接受的标准 9 30 10 00 指定的测试人员每天早上运行可接受测试 如果成功发EMAIL给全组 其它测试人员开始进行功能测试 功能测试仅测试那些已经发出TRD的功能 TESTTEAM发现BUG 并登记在BUG数据库中 TESTTEAM进行其它测试 如性能测试 本地测试和平台测试 测试频率和目标在TEST计划中制定 如果是MILESTONE结束时 运行所有测试案例 TESTTEAM根据TEST计划开发TESTCASE 编写自动化工具和测试脚本 TESTTEAM发送日报表 使用源代码控制工具 放入源文件 文档资料和所有频繁改动的资料不要放入二进制代码 包括动态库和可执行文件只编辑需要改动的编码 SDEDIT 每次CheckIn时 填写变化列表 每次CheckIn之前 保证本地编译通过 并通过代码审核建立每日Release的源代码标签 便于回滚到某一个特定的Build时的源代码 管理你的BUG数据库 建立并备份你的BUG数据库定义BUG管理流程清楚地定义BUG类别和属性建立起BUG的权威性 如果一个BUG可以方便地被重现 该BUG必须被修复 设定BUG数上限DEV不能选择 不修复 和 设计 作为一个BUG的解决方案遇到争论时 BUG被指定给COMMITTEE 由COMMITTEE作出决定 COMMITTEE一般由PM DEVLEAD和TESTLEAD组成 监测BUG数据库 利用数字标准作为衡量标准 并使全组人员知道这些数字 软件开发度量 一 前提条件 在实施的过程中和过程后收集大量数据项目开发过程中的数据收集每日 每周登记的缺陷和解决的缺陷 按照严重性统计 跟踪每日已激活缺陷和已解决缺陷数目Fixed缺陷数目 已解决的缺陷数目 除去重复和不可重复缺陷 跟踪缺陷重新激活次数缺陷的发现途径 随即测试 测试案例开发 可接受性测试解决缺陷的平均时间关闭缺陷的平均时间最老的缺陷 软件开发度量 二 总结过程中的数据收集不同等级的缺陷百分比计划的测试工作量实际的测试工作量 SHOWSTOPPER 缺陷的产生原因 缺乏测试案例由于修改其它缺陷引起的新缺陷 测试区域划分导致没有进行测试 回归测试配置测试 不是所有的机器上都可以重现错误规范不完整最后加的功能 如何作CodeReview 代码审核 标志代码错误 如通过编译检查的代码拼写错误 违反编码规范 硬编码 hardcode 字符串和配置 标明算法错误 如选择错误的算法或没考虑边界情况 标志潜在的回归式错误标志可改进的地方教育开发人员CodeReview的步骤代码应该在多个平台上编译成功代码首先必须被开发人员测试过 使用DEBUGGER单步执行 或添加跟踪语句 代码必须被提交给代码审核者 使用Windiff工具比较不同代码审核的结果应该是接受 有条件的接受和拒绝代码审核的结果必须在下次审核之前更正 并提交 代码审核CheckList 是否符合编码规范是否有HARDCODE字符串是否使用数字来定义数组大小 而不是使用常量或宏是否自己写代码而不使用类库开发人员是否误解了类库的参数开发者是否假定某一平台来开发程序 从而在其它平台上不能运行是否去除了代码 而忘了另外一个地方是否考虑了边界条件是否在DEBUG版本中使用ASSERT代码是否具有可读性 开发者对代码的变化是否会引起其它的BUG是否能够通过去除代码来提高性能变化是否在文档中更新以便维护 代码变化是否和其它人有关 CodeComplete SystemTesting 测试最佳经验 为各种水平的测试准备详细的测试计划和测试案例 和数据及日志相关联设计测试案例来测试系统限制 如文件大小和数据库大小为特例设计测试案例系统的每个部件都要使用回归测试 安装并文档化测试环境在测试计划中规定测试范围 测试和管理工具 测试范围功能测试边界值测试性能测试和分析平台测试压力测试软件测试工具性能测试工具 WEBSTRESSTOOL PERFORMANCECOUNTER SQLConnection Memory CPU压力测试StressTestingDataAccessComponentsinWindowsDNAApplications TestCaseSample TestCase50 ManualKeyPressTestTestCase51 KeySequenceTestTestCase52 KeyChordingTestTestCase53 TextEditingTestTestCase54 RepeatRateandKeyDelayTestTestCase55 AsynchronousStateTest 压力测试 为什么需要压力测试 高性能不是一天就能实现的开发环境和生产环境的不同对用户和维护人员有意义压力测试的工具WEBAPPLICATIONSTRESSTOOLPERFORMANCEMONITORWEBLOG需要收集的数据ActiveServerPages requestspersecond requestsrejected totalqueuelength andnumberofcurrentsessionsDatabaseCounterLockrequestsDeadlockspersecondTablelockescalationspersecondUserconnectionsActivetransactionsIISCPUutilization userandkernelshouldbe8 2Memoryus