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

□ 软件开发中的常见问题 □ 微软开发管理流程综述 □ 案例分析：开发流程精髓 □ 工具在管理流程中的应用 □ 软件开发管理平台产品介绍及应用场景 □ 个性化的企业应用级平台及咨询服务 □ 成功案例及分析开发团队协同问题 ◦ 缺乏沟通平台，信息交流滞后 ◦ 开发模式落后，团队协作不力 ◦ 责任机制不明，事务无法跟踪 ◦ 工作无法量化，奖惩机制无效开发团队协同问题 ◦ 缺乏沟通平台，信息交流滞后 建立实时的信息沟通和管理平台◦ 开发模式落后，团队协作不力 建立科学的流程和高效的管理机制◦ 责任机制不明，事务无法跟踪 构建科学的团队模型和明确角色分工◦ 工作无法量化，奖惩机制无效 利用工具辅助绩效考核及工作评估开发周期难以控制 ◦ 项目风险无法评估和预测 ◦ 对频繁出现的变更和缺陷无法跟踪 ◦ 缺乏数据采集平台和分析引擎以辅助决策 ◦ 工具灵活性差，不能进行企业级的量身定制 ◦ 计划、设计、编码和测试脱节，无法做到无缝连接开发周期难以控制 ◦ 项目风险无法评估和预测 ◦ 对频繁出现的变更和缺陷无法跟踪 ◦ 缺乏数据采集平台和分析引擎以辅助决策 ◦ 工具灵活性差，不能进行企业级的量身定制 ◦ 计划、设计、编码和测试脱节，无法做到无缝连接使用企业级的开发管 理平台进行无缝管理 、跟踪和评估。

通过咨询服务裁剪定制 具有企业特色的、特有 的流程和管理系统产品部门经理产品部门经理测试人员组长测试人员组长开发人员组长开发人员组长项目经理组长项目经理组长项目经理项目经理开发人员开发人员测试人员测试人员产品经理产品经理可用性可用性用户培训用户培训其他其他1. 多里程碑式管理-平衡范围、时间和资源的最佳实践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环境，在集成的基础上进 行单元测试协同工作的主要手段 ◦ 缺陷 ◦ 变更请求 ◦ 建议 ◦ 各色问题量化管理 ◦ 量化质量 ◦ 跟踪进度 ◦ 预测发布时间项目范围定义需求跟踪管理概念-逻辑设计风 险 管 理逻辑-物理设计规范和审核代码集成构 造 / 基 线测试用例设计测试用例运行测 试 计 划测试结果报告概念-逻辑设计需求管理测试管理缺 陷 管 理文 档 管 理版 本 控 制项 目 管 理开发管理项目范围定义需求跟踪管理概念-逻辑设计风 险 管 理逻辑-物理设计代码集成代码规范构 造 / 基 线测试用例设计测试用例运行测 试 计 划测试结果报告概念-逻辑设计需求管理测试管理开发管理缺 陷 管 理文 档 管 理版 本 控 制项 目 管 理风险管理Daily BuildCheck-outCheck-in基线管理风险管理范围管理变更控制项目跟踪项目计划质量评估质量管理变更管理任务跟踪缺陷跟踪用户文档测试文档开发文档计划/设计范围/需求1-初始级2-可重复级3-定义级4-管理级5-优化级需求管理软件项目计划.. .. .. .. .. ..软件配置管理集成式软件管理组织过程定义同行评审.. .. .. .. .. .. .. .. ..定量过程管理软件质量管理缺陷管理技术改革管理过程变更管理需求管理测试管理开发管理缺 陷 管 理文 档 管 理版 本 控 制项 目 管 理测试人员BMS项目经理其他人员构造员开发人员代码管理Daily BuildExchang eRMSTCMProjec tVSS用户项目管理缺乏缺陷管理会怎么样？ ◦ 以前解决过的缺陷发布时又出现了，拉长开发周期 ◦ 测试发现的问题被忽略或是不了了之 ◦ 很难衡量测试员和开发员的工作缺陷管理的意义 ◦ 提高项目质量，缩短周期 ◦ 为项目管理提供依据 ◦ 预测项目进度与里程碑 ◦ 加强沟通与协作通常大家认为缺陷是： ◦ 软件设计、编程、制作中出现的错误 BMS中对缺陷的定义： 任何有助于改善产品质量的提议、任何需要引起注意、值得跟 踪的问题、任何可能潜在的错误，由BMS来记录、跟踪、管理 缺陷的后继变化和处理方案。

其中包括： ◦ 代码错误 ◦ 工作项 ◦ 变更 ◦ 文档问题 ◦ 测试问题 ◦ 建议及其他缺陷的生命周期测试人员 ◦ 登记一个缺陷，描述缺陷的 详细信息 ◦ 按优先级验证缺陷，检查其 是否可以重现 ◦ 若缺陷被解决，关闭缺陷 ◦ 回归测试测试主管 ◦ 指派缺陷 ◦ 比较谁登记的缺陷最多，而 且个人是否完成指标 ◦ 组织“软件大扫除”缺陷的生命周期开发人员 ◦ 找到所有由自己负责的缺陷 ◦ 按优先级解决这些缺陷 ◦ 把那些设计、重现环境或步骤不明 确的缺陷指派回给项目经理或登记 该缺陷的测试人员 ◦ 找到所有由自己解决的缺陷，并写代码Check-in Report开发主管 ◦ 指派缺陷 ◦ 比较谁解决的缺陷最多，而且个人 是否完成指标 ◦ 调研指派给自己的那些较难解决的 缺陷 ◦ 通过比较check-in前后的文件版本 ，为开发人员解决的缺陷做Code Review ◦ 评估修复某个缺陷的复杂度缺陷的生命周期项目经理 ◦ 指派待定的缺陷，并指定优先级和负责人 ◦ 及时了解缺陷分布以更好地协调团队之间的工作，消除瓶颈 ◦ 组织专家会诊 ◦ 通过缺陷趋势预测关键检查点及发布日期 ◦ 给开发人员布置工作任务（可以从Microsoft Project 2002导入），并 给出详细设计 ◦ 变更跟踪缺陷的生命周期非细化无以监控 ◦ 细化的开发进度表检查点多多益善 ◦Spec freeze ◦CC ◦50 bug goal ◦ZBB ◦Beta ◦RC ◦RTM赋予测试团队神圣的权利 ◦ 测试计划紧密尾随开发计划 ◦ 测试员和开发员捉对厮杀 ◦ 群众的眼睛是雪亮的每日构造和自动测试让问题自动曝光测试目的 ◦验证软件对规格说明的实现 ◦发现程序中的缺陷 ◦确定系统可以正常工作 ◦了解性能的限制 ◦了解系统不能做什么 ◦评估系统的能力和质量 ◦验证文档测试关键 ◦测试应尽早开始 ◦应该在测试工作真正开始前较长时间内就进行测试计划 ◦建立良好的测试用例管理机制 ◦严格执行测试计划，避免测试的随意性 ◦对每个测试结果做全面调查 ◦妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便 ◦建立良好的Daily Build机制为一个测试项创建一个文档，这个文档包含 了一系列的执行条件和环境，并定义描述输 入数据和期望的输出和结果为一个测试项的输入和期望输出做定量测试必须包括有效的和期望的输入条件以及无效 的和不期望的输入条件一个定义明确 的缺陷报告 也是一个测试用例。

测试人员 ◦ 新建测试用例 ◦ 在一个可执行版本上检验测试用例并记录 结果 ◦ 碰到非期望的结果时，登记一个缺陷 ◦ 选择一组测试用例来做不同场景的测试（如BVT）测试主管/项目经理 ◦ 分配测试用例 ◦ 检验有多少用例已经走过，有多少用例还 未被运行，测试人员是否完成指标 ◦ 审核测试用例是否和设计文档一致开发人员 ◦ 单元测试时运行一批用例并验证是否成功单元测试 ◦ 让每日构造和测试员来监督覆盖性测试 ◦ 依赖清晰的功能规范，着眼于用户情景Monkey Testing ◦ 找出边缘问题回归测试 ◦ 以前出现过的缺陷是财富自动测试 ◦ 成熟软件的必备白盒测试 ◦ 对后台和技术性强的模块有效更重要的是测试计划，软件质量标准和测试流程。