软件开发管理流程简介.ppt

软件开发中的常见问题 微软开发管理流程综述 案例分析：开发流程精髓 工具在管理流程中的应用 软件开发管理平台产品介绍及应用场景 个性化的企业应用级平台及咨询服务 成功案例及分析,内容提要,软件开发中的常见问题,软件开发中的常见问题,开发团队协同问题 缺乏沟通平台，信息交流滞后 开发模式落后，团队协作不力 责任机制不明，事务无法跟踪 工作无法量化，奖惩机制无效,开发团队协同问题 缺乏沟通平台，信息交流滞后 建立实时的信息沟通和管理平台 开发模式落后，团队协作不力 建立科学的流程和高效的管理机制 责任机制不明，事务无法跟踪 构建科学的团队模型和明确角色分工 工作无法量化，奖惩机制无效 利用工具辅助绩效考核及工作评估,解决方案,软件开发中的常见问题,开发周期难以控制 项目风险无法评估和预测 对频繁出现的变更和缺陷无法跟踪 缺乏数据采集平台和分析引擎以辅助决策 工具灵活性差，不能进行企业级的量身定制 计划、设计、编码和测试脱节，无法做到无缝连接,开发周期难以控制 项目风险无法评估和预测 对频繁出现的变更和缺陷无法跟踪 缺乏数据采集平台和分析引擎以辅助决策 工具灵活性差，不能进行企业级的量身定制 计划、设计、编码和测试脱节，无法做到无缝连接,解决方案,使用企业级的开发管理平台进行无缝管理、跟踪和评估。,通过咨询服务裁剪定制具有企业特色的、特有的流程和管理系统。,微软开发管理流程综述,MSF团队模型,团队组织结构一例,MSF过程模型,1. 多里程碑式管理-平衡范围、时间和资源的最佳实践,MSF过程模型,2. MSF模型-集瀑布模型和螺旋模型的优点于一身,瀑布模型,螺旋模型,MSF模型,协作贯穿于产品开发周期始终,全程协作,远景阶段 PM: 做什么，为什么？ Dev: 技术可行否？ Test: 风险在哪？ 计划阶段 PM: 具体做什么？ Dev: 具体怎么做？ Test: 细化的衡量标准,开发阶段（多里程碑） PM: 掌舵，进度控制 Dev: 开发 Test: 无微不至的关怀 Beta与发布阶段 PM: 根据反馈调整功能 Dev: 开发，解决缺陷 Test: 多种手段稳定产品,协作三板斧 每日构造（daily build） 版本控制 缺陷管理,协作的保障,案例分析：开发流程精髓,每日构造,整个Office团队使用统一的每日构造 痛 Office Common的Bug马上会影响Excel的开发 Build一次需要几个钟头 开发人员的疏忽造成Blocking Bug，成为万恶不赦的公敌 并快乐着 各产品组自始至终在集成环境下工作，保证总体质量 开发人员绝对重视单元测试 让无微不至的关怀变得可能,版本控制,版本控制是否形同虚设？ 版本控制是每日构造的基础 版本控制是建立在版本工具之上的一系列严格的质量保障制度 单元测试 代码审阅 (code review) 通知机制 每个程序员都有完整的Build环境，在集成的基础上进行单元测试,缺陷管理,协同工作的主要手段 缺陷 变更请求 建议 各色问题 量化管理 量化质量 跟踪进度 预测发布时间,工具在管理流程中的应用,开发流程概览,流程分解,项目范围定义,需求跟踪管理,概念-逻辑设计,风险管理,逻辑-物理设计,规范和审核,代码集成,构造/基线,概念-逻辑设计,需求管理,测试管理,开发管理,流程分解,项目范围定义,需求跟踪管理,概念-逻辑设计,风险管理,逻辑-物理设计,代码集成,代码规范,构造/基线,概念-逻辑设计,需求管理,测试管理,开发管理,上图对CMM部分KPA的映射,1-初始级,2-可重复级,3-定义级,4-管理级,5-优化级, , ,工具在领域中的应用,需求管理,测试管理,开发管理,微创软件开发管理平台 产品介绍及应用场景,测试人员,BMS,项目经理,其他人员,构造员,开发人员,代码管理,Daily Build,Exchange,RMS,TCM,Project,设计思想,VSS,用户,项目管理,BMS,缺陷管理,缺乏缺陷管理会怎么样？ 以前解决过的缺陷发布时又出现了，拉长开发周期 测试发现的问题被忽略或是不了了之 很难衡量测试员和开发员的工作 缺陷管理的意义 提高项目质量，缩短周期 为项目管理提供依据 预测项目进度与里程碑 加强沟通与协作,“缺陷”的定义,通常大家认为缺陷是： 软件设计、编程、制作中出现的错误 BMS中对缺陷的定义： 任何有助于改善产品质量的提议、任何需要引起注意、值得跟踪的问题、任何可能潜在的错误，由BMS来记录、跟踪、管理缺陷的后继变化和处理方案。其中包括： 代码错误 工作项 变更 文档问题 测试问题 建议及其他,BMS界面,缺陷的生命周期,BMS应用场景,测试人员 登记一个缺陷，描述缺陷的详细信息 按优先级验证缺陷，检查其是否可以重现 若缺陷被解决，关闭缺陷 回归测试 测试主管 指派缺陷 比较谁登记的缺陷最多，而且个人是否完成指标 组织“软件大扫除”,缺陷的生命周期,BMS应用场景,开发人员 找到所有由自己负责的缺陷 按优先级解决这些缺陷 把那些设计、重现环境或步骤不明确的缺陷指派回给项目经理或登记该缺陷的测试人员 找到所有由自己解决的缺陷，并写代码Check-in Report 开发主管 指派缺陷 比较谁解决的缺陷最多，而且个人是否完成指标 调研指派给自己的那些较难解决的缺陷 通过比较check-in前后的文件版本，为开发人员解决的缺陷做Code Review 评估修复某个缺陷的复杂度,缺陷的生命周期,BMS应用场景,项目经理 指派待定的缺陷，并指定优先级和负责人 及时了解缺陷分布以更好地协调团队之间的工作，消除瓶颈 组织专家会诊 通过缺陷趋势预测关键检查点及发布日期 给开发人员布置工作任务（可以从Microsoft Project 2002导入），并给出详细设计 变更跟踪,缺陷的生命周期,自动监控,非细化无以监控 细化的开发进度表 检查点多多益善 Spec freeze CC 50 bug goal ZBB Beta RC RTM 赋予测试团队神圣的权利 测试计划紧密尾随开发计划 测试员和开发员捉对厮杀 群众的眼睛是雪亮的 每日构造和自动测试让问题自动曝光,TCM,测试管理,测试目的 验证软件对规格说明的实现 发现程序中的缺陷 确定系统可以正常工作 了解性能的限制 了解系统不能做什么 评估系统的能力和质量 验证文档 测试关键 测试应尽早开始 应该在测试工作真正开始前较长时间内就进行测试计划 建立良好的测试用例管理机制 严格执行测试计划，避免测试的随意性 对每个测试结果做全面调查 妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便 建立良好的Daily Build机制,“测试用例”的定义,为一个测试项创建一个文档，这个文档包含了一系列的执行条件和环境，并定义描述输入数据和期望的输出和结果 为一个测试项的输入和期望输出做定量测试 必须包括有效的和期望的输入条件以及无效的和不期望的输入条件,一个定义明确 的缺陷报告 也是一个测试用例。,TCM界面,TCM应用场景,测试人员 新建测试用例 在一个可执行版本上检验测试用例并记录结果 碰到非期望的结果时，登记一个缺陷 选择一组测试用例来做不同场景的测试（如BVT） 测试主管/项目经理 分配测试用例 检验有多少用例已经走过，有多少用例还未被运行，测试人员是否完成指标 审核测试用例是否和设计文档一致 开发人员 单元测试时运行一批用例并