如何做casestudy.doc

ecom Case Study规范 项目名称 【项目名称】 项目时间 【项目的起止时间】 项目负责人 【项目负责人】 会议时间 【举行Case Study的时间】 与会人员 【参与或预计参与Case Study的人员】 一、详细过程 【描述要求】 请使用自然语言描述完整的事例过程； 请说明每个问题点的具体时间； 请说明每次处理问题花费的时间的多少； 请说明分析查找问题的具体方法； 若进行了紧急处理，请详细描述其具体方法； 二、重点分析 问题点1： 描述：【关于问题点1的具体描述】 原因：【造成该问题的具体原因】 处理：【处理该问题的具体方法】 总结：【从对该问题的原因分析及处理中值得总结的经验教训】 问题点2： 描述：【关于问题点2的具体描述】 原因：【造成该问题的具体原因】 处理：【处理该问题的具体方法】 总结：【从对该问题的原因分析及处理中值得总结的经验教训】 问题点3： 描述：【关于问题点2的具体描述】 原因：【造成该问题的具体原因】 处理：【处理该问题的具体方法】 总结：【从对该问题的原因分析及处理中值得总结的经验教训】 问题点4： 描述： 。。。 原因： 。。。 处理： 。。。 总结： 。。。 三、改进措施 总体原则：【填写项目将来的改进措施的总体原则】 实施计划： 实施项目 实施方案 【项目名称】 针对问题 【此项目针对的问题】 改进方案 【此项目的具体改进方案】 预期效果 【此项目上线后预期达到的效果】 项目启动时间 【启动日期】 预计上线时间 【上线日期】 【项目名称】 针对问题 【此项目针对的问题】 改进方案 【此项目的具体改进方案】 预期效果 【此项目上线后预期达到的效果】 项目启动时间 【启动日期】 项目启动时间 【启动日期】 。。。 针对问题 。。。 改进方案 。。。 预期效果 。。。 项目启动时间 。。。 项目启动时间 。。。 【Case Study规定】 某产品线的在线服务升级，若遇到意外情况，导致升级完全失败或部分失败，或对预期的升级进度产生严重影响的情况，需进行Case Study； 某产品线的新功能上线后，根据各方面反馈，若发现与升级的预期效果严重不符，需进行Case Study； 其他技术总监/部门经理/项目经理认为需要进行Case Study的情况； 【Case Study会议流程】 开场白：由项目经理简单介绍Case Study的原因； 背景介绍：若多数与会人员对进行Case Study的项目不了解，则请项目负责人首先对项目本身做一下简单的介绍；目的是使与会人员对项目的背景环境有一个大致的了解； 详细描述：由项目负责人描述该Case发生的完整过程；目的是使与会人员了解Case事例的起因、过程、进展、结果及各个着眼点的相互关系； 重点分析：由项目负责人分析需要进行Study的各个Case的原因、结果、处理方法，并进行总结；该部分应作为Case Study的会议重点； 讨论交流：由项目经理组织与会人员对需要进行Study的各个Case原因、结果、处理方法及其总结进行讨论与交流，由项目负责人进行书面记录； 改进计划：由项目经理或项目负责人描述改进计划； 结束语：由项目经理或部门经理/技术总监做总结陈词。 【Case Study附加说明】 关于文档提交时间： Case Study的文档，应在其所描述的具体事例发生后的3天之内提交； 关于文档审核流程： Case Study文档，应有项目负责人负责根据本文文档规范撰写，完成后提交项目经理或部门经理审阅；需要修改的，由项目经理或部门经理提出修改意见，由项目负责人根据意见进行修改，并再次提交审阅，直至最终定稿；定稿后由项目经理或部门经理提交技术总监审阅。 关于会议举行时间与与会人员； Case Study会议，应在其所描述的具体事例发生后的一周之内进行；与会人员应是相应项目组内的所有成员，及测试组的测试经理及相关人员，必要时由部门经理或技术总监发起组织其他项目组的成员参与； 关于改进计划 本Case Study中列出的改进计划为初步计划，若Case Study中与会人员的讨论结果涉及到改进计划的修订，则由项目经理或部门经理负责进行评估，并根据最终方案监督执行。 ecom Case Study 实例 项目名称 Sfrd 1.2.1 EcomBS 3.5.0 项目时间 2005-3-23 ~ 2005-4-5 项目负责人 会议时间 2005-4-8 与会人员 Ecom组全体人员 一、详细过程 ? 4月5日下午五点SFRD开始准备上线，在各服务器上建立相应的各路径，在apptest机器上为SFRD的client、server_ec、server_pp、