用友实施方法论V3.ppt

项目实施中的工作确认 阶段工作确认 里程碑任务 步骤 准备要确认的报告 发出通知并提交 双方确认 复印保存 顾问工作确认 每天/周确认 统计顾问利用率 个人绩效考核的依据之一 实施方法论总结 项目环境千变万化，不可能依据一个标准的工作流程就能顺利实现项目目标。 掌握标准的实施流程，但不要标准地使用流程 实施方法论＋项目经理的判断、应变能力＝可行的项目实施方法 问题与交流 Q A Question: 你所理解的实施方法论是什么？ (用一两句话表达) 系统建设－静态数据准备 数据准备人员和校验人员分开负责 校验工具的制作 数据出错后的纠正措施 确认合格的静态数据 数据的校验和确认 严格按照标准的表单准备 保证数据准备人员理解字段含义 没有双方确认的静态数据不允许导入到客户系统 静态数 据准备 导入工具的应用范围 导入工具的开发、测试 导入的风险分析 数据转换 工具的开发 制定《静态数据准备方案》 编写《静态数据准备计划》 静态数据的准备表单 方案、计划的确认 静态数据准备方案 《静态数据准备方案》 《静态数据准备计划》 《静态数据准备表单》 数据的导入 工具 风险分析 举例： 某项目在静态数据方案讨论时，客户提出他们的静态数据太多了，如果按照我们的要求准备至少需要6个月的时间，但是我们整个项目规划才4个月，同时大家工作很忙，没有时间去做，结果开始数据准备没有专人负责，数据整理非常不到位，最终花费2个月的时间整理好了，但没有进行严格的校验，系统上线之处，错误百出，严重的影响业务的处理。 问题： 1、工作量的估计偏差较大 2、缺少明确的分工、校验人员不负责等 3、暴露我们顾问在行业和项目管理经验不足的缺陷 4、系统急于上线工急于收钱结果事与愿违 修改配置,ITS,业务流程 模型 确定业务情 形和测试案 例清单 编写集成测试文档(测试案例和数据) 测试 测试完成 确定问题(差距、集成测试文档、设计) 处理问题 编制详细 测试计划 (如 只需要 修改 文档 ) 业务流程模型 集成测试文档 测试数据 业务流程模型 业务流程模型 集成测试系统 已完成和 修改后的 测试案例 Open 等待计划 等待测试 等待 解决 正在 测试 等待计划 完成 * 测试案例状态 系统测试流程 系统建设－系统测试I 测试准备_测试案例和测试数据 (测试用样例) 测试准备_ 《系统测试方案》纲要 测试准备_建立测试 环境 业务流程 测试用例编码 测试过程描述 角色 预期结果 实际结果 结果是否正确 BS1 T1 步骤 1 (SD-C1) A xxxx xxxx 步骤 2 (PP-C1 B 步骤 3 (FI-C1) C ….. …… 准备测试场地、系统、参加人员等 a)?测试目标 b)?编写详细的测试计划 c)?测试问题的提交和解决流程 d)?明确测试参加人员的角色和职责 系统测试过程I 主数据测试（物料、客户） 模块内业务流程的串联测试，检查集成点 简单、无特例跨流程测试 导入生产系统权限参数 复杂及包括特例测试 必须取自实际数据 测试事务应该基于实际业务数据 使用少量、易于管理，便于验证结果的正确 使用生产系统转换数据版本 使用数据转换的完整流程 测试案例编写 测试数据 测试 详细测试计划 所有处于“等待计划”状态的测试案例，都要由集成测试控制员计划、调度 计划完毕，将“计划测试日期”输入测试案例表，并将其状态改为“等待测试” 记录非预期的结果并通知测试组负责人 如果问题不可以立即解决，转作其他案例 测试组之间的有效沟通 在测试文档、流程、功能和主数据上标准存在问题 《测试案例清单》 《测试用例模板》 《详细测试计划》 《测试问题记录》 系统测试过程II 确定客户化开发的 范围和内容 解决问题 当测试得到非预期的结果，或出现问题、测试停止。 每个问题都应用问题表格记录，并提交给测试控制员用于跟踪。 设置测试案例状态为“等待解决”。 将问题通知测试组负责人，转入下个测试案例。 问题的解决应遵循以下原则：为业务流程提供最佳支持。 问题安排给流程拥有者解决 首先解决最高优先级的问题 根据需要，利用测试组负责人、顾问、扩大项目小组成员，尽快解决问题 -- 当日事当日毕。 在开发环境中完成配置修改，利用相关工具将修改请求拷贝到测试环境。不允许在测试环境中直接修改配置。 及时修改配置文档、BAS、测试文档和业务流程图等相关文档。