需求评估培训解说.ppt

POS：项目目标 一个项目只有一个目标，目标决定项目的目的和方向，也决定了项目的最终交付成果和产出。 目标说明应当用商业语言书写。 目标说明不应该包括任何具体的完成时间。 目标说明的要求：S.M.A.R.T Specific：明确性，明确针对一个目的 Measurable：度量性，建立进展的度量尺度 Assignable：授权性，每个目的都可授权给具体人 Realistic：现实性，利用可用资源能完成什么 Time-related：时间相关，何果可以达到该目的 POS：项目目的 项目目的是对项目目标的详细说明，是为了明确目标说明的准确界限和定义项目的范围。 目的说明的是一种未来状态，而不是基于活动的。 目的陈述应包括以下部分： 产出：项目将要完成什么 时间框架：预计完成时间 度量：评价成功的尺度 行动：如何达到这一目的 POS：成功标准 为什么要做这个项目—即这个项目产生的可度量的商业价值 采用的表述方法类似于：增加的利润、增加的纯收入、减少的处理时间、提高的生产力、降低的生产或销售费用 例如：项目将把定单的处理时间降低6% POS：假设、风险和障碍列表 想引起管理层关注的可能影响项目结果的各种因素，常见的因素主要有以下几种： 技术：缺乏对新技术的经验… 环境：诸如一个不稳定的或变化频繁的管理机构可能会在一夜之间将一个高优先的项目变成低优先级的 人际关系：项目团队成员之间的关系很重要 文化：项目是否适合企业？… 因果关系：对某些因素的假设如果不 成立，将影响最终结果 POS：附件 风险分析 财务分析 费用/收益分析 收支平衡分析 投资回报（ROI） 合同 内部开发：为自己的需要，在内部进行。通常客户与IT部门合作编写并签署规格说明。它也应指定交付时间，以及任务、费用的分担 产品开发：开发公司将在市场上销售的商业产品 成品购买：供应商交付一个现成的产品 招标：发出投标要求（RFP），同时提供由客户或顾问编写的需求规格说明 资格预审 合同签署 合同开发：供应商为客户开发并交付系统 比较建议书 普通需求：对需求的平均或总体评价 最弱需求：某些重要需求无法得到充分的支持 产品类总分：上述两项之和 理解具体问题：只是简单说明能够满足需求，但未提供证据表明如何满足 历史记录：在相关行为的经验 可靠性：供应商财务状态 总分数：以上总和 基本价格：基本版本的价格 选项1~n：各可选项的价格 比较建议书 需求的评价 为每项需求指定优先级 说明可选的需求，供应商可以单独的价格实现或忽略 采用“开放尺度”或“开放标准方法 采用”任务及支持“技术说明需求 编写建议书 供应商完成 必须提供客户所要求的所有信息 应该说明如何解决其问题 设计与编程 直接实现：逐项实现需求，同时完成由需求至设计或代码的追踪 验证：逐一考虑每项需求，检查是否已实现 嵌入式的追踪信息：为每段代码或设计的每个部分，说明所处理的需求编号 验收测试与交付 安装测试：保证硬件、软件已为下一步测试做好了准确 系统测试：检查产品是否完成了所有能够在开始日常运作之前就验证的需求 部署测试：检查产品能否使用生产数据进行日常支作 验收测试：检查产品能否处理所有任务的变体，以及是否已安装好，可以投入日常运作，内容包括系统测试+部署测试 运作测试：检查另一部分需求，即只有经过一段时间运行才能测试的 需求管理 建立变更控制部门（CCB） 报告：记录日期、来源、说明 分析：新要求？修改请求？误解？真实需要是？客户可能结果是？完成该请求的成本？是否进一步调查？ 决定：是否应该拒绝？优先级如何？ 回复：将决策反馈给报告人及相关人员 执行：修订规格说明 需求评审：方法 非正式评审： 同级桌面检查：请一位同事检查 轮查：同时请若干同事分别检查 走查：作者向评审人员描述，并要求做出评论 正式评审 同级评审(审查)：最有效的软件质量技术 需求审查过程 参与者 需求规格说明书的作者、同级伙伴 提供规格说明信息的人：分析员、客户 要根据规格书开展工作的人：开发人员… 负责相关接口工作的人 总人数：=6人 角色 作者 主持人  读者 记录员 需求审查：开始标准 文档遵循标准模板 文档已经进行过拼写检查 作者已经检查了文档在版面上的错误 已经获得了审查前需要阅读的文档或参考文档 在文档中标上了行号，便于查阅 所有未解决问题已标上了TBD 主持人检查10分钟后，找不出3个以上重大错误 需求审查：主要阶段 规划：谁参加？准备什么材料？ 总体会议：确定审查的背景、假设及目标 准备：审查员阅读材料 审查会议：主持人引