1、文档1软件项目开发流程文档21 概述 .31.1 目的 .31.2 内容概述 .32 开发部日常管理流程具体实施方案 .32.1 基本原则 .32.2 内容概述 .32.3 内容详细描述 .33 开发部管理流程具体实施方案 103.1 内容概述 103.2 开发部概要流程图 123.3 开发部管理人员工作流 123.4 BUGSURVEY工作流 153.5 项目分析工作流 153.6 BETA后质量保证工作流 153.7 测试组 BETA前工作流 153.8 项目组基本工作流 153.9 测试部 版前流程 194 绩效考核实施方案 214.1 总则： 214.2 流程图 215 开发部激励和过
2、失管理流程 245.1 激励管理系统 245.2 过失管理系统 24文档31 概述1.1 目的 用标准化的流程来统一管理公司的运作，避免混乱，提高管理的质量。 在远程开发上，结果软件自身的特点，量身定做，解决远程开发上的问题。 在实施过程中，所有管理者能够根据此统一的流程，总结经验，提高认识，加强技术水平和管理水平。 提高公司级的技术分析能力，为公司储备一支分析队伍，侧重在需求理解和需求分析、框架设计上的能力。保证在 2004 年能够全盘进行中方市场的顺利运作。 对人员负责内容上，明确化各自负责的内容，提高工作效率。1.2 内容概述 开发部日常工作流程 开发部管理流程 开发部绩效考核流程 开发
3、部激励和过失管理流程2 开发部日常管理流程具体实施方案2.1 基本原则公司开发部力求建立公平公正的评价体系，严谨的工作流程定义和及时的记录与反馈，规范职员活动，形成一个紧张有序的团队。没有一个明晰的流程和高效的反馈体系，就不可能把工作做好。但是，这需要每个人按照规则把自己应该负责的那一部分高效完成，只有这样才能保证整个系统的顺畅，同时，如果个人没有完成自己的指责和按照规定填写内容，影响的不单单是自己的工作而是整个系统。2.2 内容概述 Esm 使用规则目的注意是为了提高开发部整体的计划能力，反馈能力和管理者的控制能力。同时提高整体职员参与公司管理的渠道，适应东京上市公司对信息管理的要求。 日常
4、活动的方法提供开发部工作流程外的突发事件的解决方法2.3 内容详细描述2.3.1Esm 使用规则（1） schedule 的使用文档4加强全体人员的计划能力，做到我每天要做什么？今天项目经理给我的安排是什么？对应项目经理和部长要知道每个人在做什么？只有这样，才能保证控制人员可以宏观调控，而个人也不会不知所措。注意事项：1. 必须使用长期类型（哪怕只有一天）保持统一性2 开始时间必须为 22：00 结束时间为 23：00， （为了区分其它人填写的日程安排）3 填写日程安排时，必须选择对应的 anken，否则不能于系统内的项目关联，统计软件失去作用。4 日程安排的主题要修改，规则为项目号（中文版项
5、目为北京内部项目编号） ，暂时没有编号可以写项目名称。内容 负责人 填写要求 监督人 违规处理下周工作安排项目经理技术分析负责人测试组经理必须每周五 16：00 前填写完毕。同时类型统一用长期进行定义，为每一个人员安排下周工作计划。填写监督：项目总控助理内容监督：部长和项目总控人员没有按时提交的，管理者扣除 MD 0.2日常活动安排开发部全体人员建议大家把工作安排填写，有利于提高自己的计划能力和规划能力。同时能保证事情不会忘记。无待办事项开发部全体人员建议填写，管理者应该必须使用。主要是把事务管理的井井有条。无制作下周工作安排表项目总控助理负责利用工具【导出下周工作表系统】制作开发部下周工作计
6、划表。每周五下班前发送东京。东京项目负责人文档5（2） Report 的使用作为上市公司的子公司要求公司正规化，第一步公司的日报系统的建立和审查，所以从本年度起必须建立此系统。同时，在管理上解决口头汇报，不客观而事后而无据可查的弊端，为及时了解问题并解决问题，提供第一手的素材。同时项目总控助理，也要本着实事求是的原则，根据大家的填写内容向东京证券市场提交作业公务表 ，所有填写者一定要保证填写日报的消耗工时和最后工资结算时当日工时保持严格一致。内容 对应 esm的名称填写要求 监督人 违规处理项目选择项目 直接选择自己对应的项目,如果工作对象不是项目本身则需要选择以下项目:(顾客名称为 2004
7、年过程管理专用)公司会议公司培训公司管理其它注意:只有部长以上才填写以上项目(公司培训除外),部长以下全部选择对应项目。见附图 1 扣除 MD 0.1文档6当日工作内容和进度工作内容与进度1 填写当日的模块名称（模块名称参考2 中的功能点表）3 细度要求功能点填写监督：内容监督：项目经理没有填写 1 次人民币 5 元工作耗时工作耗时 要求与工资计算工时想对应。（esm 中数据库的数字和工时统计必须对应，此为东京证券的要求）数字核对：数字不对者，按照一次扣除0.1MD问题反馈问题反馈 把当天所遇到的问题按照条目化罗列。必须包含内容和状态两部分例如：1 内容： BS 详细页面存在老bug，状态：已
8、经解决2 内容：文档 2.3 出现问题，无法继续。状态：等待解决内容监督：项目经理不付责任的乱填或不填，一个日报扣除 0.1MD(如果在特殊情况下无问题，也要写无)MD 输入 订货（预定）金额必须在项目总结会议结束之后，同时要经过项目经理的审核。输入值为实际值的 10 倍（因为数值型目前只能为整数）职员的输入由项目经理负责项目经理的核对由项目总控助理进行职员如果不填写则按照输入值进行绩效考核。如果职员输入的MD 与分配时不符合项目经理扣除0.5MD附图 1：（3） 周报（Week Report）日报（Daily Report）的使用主要是使用对象为管理者，主要是适用于向管理者汇报整体问题。在概
9、念上，日文档7报周报为概括说明，而 report 则属于细节描述。内容 负责人 填写要求 监督人 违规处理日报 项目经理部长部长项目进展状况：不能解决的问题反馈建议或提议突发问题必须反馈项目总控人员 如果由于没有汇报造成问题，按一次扣除0.5MD周报 项目经理部长部长项目总控项目进展整体状况：不能解决的问题反馈建议或提议必须填写项目总控助理 周报不写，按一次扣除0.2MD（4） 目标功能的使用由于分部内有单独的激励费用，所以建议分部内建立目别考核体系。为每一个程序员根据个人不同的能力和状况设定目标，对于圆满完成目标者进行鼓励。同时，保证公司的开发效果在可控制范围内。（5） 项目信息管理的使用。
10、本管理系统在 2003 年开始实行，主要目前是记录公司所有项目的里程碑信息。为以后项目的整理和后期处理提供真实的数据。同时，维护公司的项目信息数据库。注意事项： 其中关于项目中所设计的文档，统一放在 fileserver 上 2004 目录中。 关于文档名称和路径的书写方法如下,保证能够尽快打开文档：/fileserver/project/2004/14258/测试用例/14258_testcase.xls 2004 年 1 月 1 号起,东京新项目项目 要求 对应负责人 出错处理方法 备注项目名称 必填，同时应有对应的项目号 扣除 MD 0.1北京项目编号 必填 扣除 MD 0.1 添加时一
11、定要注意唯一性，与项目类型 不能为空，目前类型有ResearchNormal 扣除 MD 0.1 目前的规则为小于5md 的均为RESEARCH 项目文档8ConfirmMergeOthers项目名称 必填 扣除 MD 0.1 项目的名称应包含项目的 ID，关于项目 ID 的生成方法，参考日方对应文档客户方负责人 必填 扣除 MD 0.1分析负责人 北京分析项目，为必填项目东京设计，为非必填部长（但是必须制定具体负责人）扣除 MD 0.1项目负责人 必填项目 部长 扣除 MD 0.1 项目负责人应该是直接负责人（不是最先指定的部长）本公司负责人 不能为空初始必填的人员为项目总控人员及助理、对应
12、部长、测试部经理,公司技术负责人（马俊）项目负责人扣除 MD 0.1 如果没有项目负责人，与联系分析开始时间 必填 对应该项目的分析员扣除 MD 0.1 公司技术负责人在分析项目开始时应把对应分析员加到项目列表中概要设计完成时间 必填 对应该项目的分析员扣除 MD 0.1详细设计完成时间 必填 对应该项目的分析员扣除 MD 0.1FP 文档完成时间 必填 对应该项目的分析员扣除 MD 0.1分析完毕时间 必填 对应该项目的分析员扣除 MD 0.1项目接收时间 必填 扣除 MD 0.1项目最终对应 MD 原则不为空，在特殊情况下为空，在项目备注重必须说明原因。项目经理（Mail通知）扣除 MD
13、0.1 本 MD 伴随着 MD 的变更需要动态变化Md 变更附件名称 不是必须，但是只要有变更有内容，此项目必须要有项目经理（Mail通知）扣除 MD 0.1项目最终报价 原则不为空，在特殊情况下为空，在项目备注重必须说明原因。 扣除 MD 0.1 必须与对应MD*11000 基本一致。同时必须和 MD 变更纪录一致Schedule 文档名称及路径必填 项目经理 扣除 MD 0.2 可以用 excel 或者是 visio，project后两种要以 HTML输出以便查阅。客户方 deadline要求如果提供必填 扣除 MD 0.1Alfa 版时间 必填 项目经理（Mail通知）扣除 MD 0.1
14、文档9Beta 版时间 必填 项目经理（Mail通知）扣除 MD 0.1Alfa 变更纪录 最后一次记录变更的时间必须和对应的 alfa 版时间和beta 版时间一致项目经理（Mail通知）扣除 MD 0.1项目开始时间 必填 项目经理（Mail通知）扣除 MD 0.1CSV 分支号 必填 项目经理 扣除 MD 0.1 此分支号为开发分支号功能点文档文件名及文件路径（FileServer 服务器）必填 项目经理 扣除 MD 0.1 此文档为必须文档，各项目经理必须严格控制。单体测试用例文件名称及文件路径必填 项目经理 扣除 MD 0.1 此文档为必须文档，各项目经理必须严格控制项目总结与 MD
15、 分配方案文档及文件路径必填 项目经理 扣除 MD 0.1 此文档为必须文档，各项目经理必须严格控制。测试负责人 必填 扣除 MD 0.1测试用例对应文件名称及路径必填 扣除 MD 0.1 此文档为必须文档，各项目经理必须严格控制。第一阶段测试开始时间： 必填 测试人员 扣除 MD 0.1第一阶段测试完成日期： 必填 测试人员 扣除 MD 0.1Alfa 版本后的BUG： 必填 测试人员 扣除 MD 0.1回归测试的开始日期： 必填 测试人员 扣除 MD 0.1回归测试的结束日期： 必填 测试人员 扣除 MD 0.1Beta 版后的 BUG数：必填 扣除 MD 0.1 主要要参考 beta后
16、bug 的整理表确认负责人 不是必须，主要是与是否进行确认有关，如果确认其他有信息，确认负责人必填 扣除 MD 0.12.3.2系统的使用（1） 电子打卡系统的使用目的：主要是利用电子打卡，提高效率，能够及时反映请假和迟到，并且所有的数据能够直接被人事利用。文档10要求：2004 年 2 月开始启用，2 月为试用期，但是要求每人必须严格填写，如果不填写并结合打卡，忘记填写扣除过程管理 MD 0.1 计算。（2） 会议室、洽谈室、经理室的使用管理目的：主要是在人数多而会议室相对紧张的状态下，解决矛盾的一种方法。同时审核各项目组是否及时安排公司规定的两次会议。2004 年 2 月启动，没有按照规定
17、进行会议，经审核后，扣除项目经理过程管理 MD0.2,忘记登录的按照统一标准处理。2.3.3公司内部论坛的使用主要是要有利于公司内部开辟一块公司可以自由发表言论的地方。同时，在技术讨论上，希望能够把知识点做一个累计，以便新员工能够进行参考和积极发表意见。3 开发部管理流程具体实施方案3.1 内容概述开发部从流程上主要分为以下几方面：（1） 开发部管理人员工作流（2） BUG Survey 工作流（3） 项目分析工作流（4） Beta 后质量保证工作流（5） 测试组 beta 前工作流（6） 项目组运行基本工作流开发部从实施人员角色划分如下：开发部经理：（DM01）统筹解决公司开发部的全部事宜。
18、进行开发部的整体计划的制定和实施，保证开发部的可持续发展和利润率。项目总控人员：(DM02) 对公司级的资源进行调配，同时，直接了解日方的战略安排，为北京方的战略安排提供的第一手的资料。同时，在项目分配上保证三个分部间项目的均衡（一个季度内）开发部部长：(DM10) 在公司统一的规则范围内，负责分部的建设。协调各开发组的问题，处理解决分部内发生的问题。做好所有公司要求的标准流程内的内容。同时，在许可范围内，可以进行单独的管理方法的尝试和分部内激励的分配。文档11技术设计负责人：(DM11) 统一协调分析组的工作，在对日项目分析组中，进行设计文档的统一确认，在对中方项目中，承担需求的统一把关处理
19、。同时负责分析组的日常工作安排的统筹。BUG Survey 总负责人(DM12)： 统一管理 package 和已经提交项目的统筹管理。组织形式上，倾向于单独的组织模式。在目前的情况下，以灵活为主，临时性的进行 bugSurvey 组的组织和 bugSurvey 组内team leader 的指定和管理。在间隙阶段，直接进入分析组进行项目分析工作。项目总控助理：(DM13)辅助开发部的项目管理工作，主要负责中日双方的信息的反馈纪录整理，以及 esm和 taskschedule 信息的维护工作。负责公司级项目文档，过程参数的监督，同时向日本总部汇报各种参数和报表。常务项目经理：(DM20) 目前
20、 11 名各分部内程序员的日常管理，整个开发过程中的控制和日方负责人的信息交互，负责组内程序员的绩效考核和问题解决。测试部经理和翻译部经理包含在内。技术分析员：(DM21)对日方的需求进行概要分析和设计，并书写设计书，FP。对中方的项目中，负责需求的整理和各种设计文档的实施，同时，负责和项目经理和测试部经理的沟通。临时项目经理：(DM22)此角色主要是在接受日方外包项目或整体公司产品设计中，需要临时成立项目组，而从分析组中或者常务项目经理中抽调。临时项目经理需要全权负责此项目的实施，同时需要和公司签订项目负责保证书，以保证项目的进行和最后单独项目激励的兑现。程序员：主要是负责项目按照分析文档的
21、实施，同时，在实施过程中优化代码结构，提出合理化建议，其中优秀者可以作为 TeamLeader 负责具体组织工作和分析管理工作。测试员：负责公司测试流程的具体实施，要求掌握测试的技术，提出合理化建议，并保证整个软件的可靠度。文档12翻译人员：负责中日方文档的翻译，要求工作严谨，保证质量。在同日方交流中，负责接待和沟通。同时，在个人的发展意向中可以兼顾其它公司内的常务工作。3.2 开发部概要流程图软 脑 软 件 开 发 部 整 体 概 要 流 程 图日方委托研发实施中方项目日方委托开发 基 本 设 计 书（ 含DB),Fp表 项 目 总 控 人 员 - 部 长 - 常 务项 目 经 理 ，项 目
22、 实 施 提交 alf版 本项 目 总 控 助 理 进 行项 目 信 息 管 理 测 试 部 进 行 软，件 测 试 提 交beta版 本 东 京 项 目 负责 人出 现 bug,进 行 回 归 处 理东 京 方 或顾 客 提 出需 求 北 京 分 析 人 员进 行 需 求 整 理 书 写 hearingstToky 确 认制 作 demo书 写 FP表 书 写 基 本 设 计（书 含 DB),测试 用 例和 顾 客进 行 需求 获 取 整 理UseCa 图分 析 组 实 施 数 据 库 设 计分 析 组 实 施 项 目 整 体 计 划 demo和 设 计 文档 类 似 委 托 开 发流 程3
23、.3 开发部管理人员工作流3.3.1软件开发管理体系构成参与人员：项目总控人员（项目总控助理）+部长+（技术设计负责人+BugSurvey 负责人）+各级项目经理管理主线：（1）工具类taskschedule 表：主要目的是增加远程开发的计划和规划性。 管理人员去合适目前我们正在进行的总量有多少，检收而为付款的有多少，文档13实施完毕而没有检收的有多少。 管理人员去看我们下周能够接受的项目有多少，以便在每周五可以制定下周的工作计划。 项目经理可以看自己负责项目的基本参数。Esm 系统： 通过 esm 系统详细的记录开发过程中的每个里程碑参数，保证在管理上能够提高管理细度，以便于及时发现并改正问
24、题和错误。Bug 管理系统：作为质量控制过程实际结果的监控。以便总结质量的问题，进行反馈。Fileserver 文档：通过文档管理和整理，保证全部职员能够随时的了解其他项目的信息和相信内容。同时，统一化文档管理，为以后的发展提供素材。所有的文档主要包含如下几种： HearingSheet：一个简要的需求，重点在于强调这个需求的原因（前因后果） UI 文件 设计文档： 东京和北京共同进行 FP 报价书 QuestionSheet：所有的问题一定要集中在一个文档内 功能点文档：一定要融合 questionSheet 内对应答案的所有内容 schedule 文档：要包含甘特图 项目总结及 MD 分配
25、方案：把项目总结作为重点进行。 单体测试用例；条数最少为 MD*2,按照模板进行 测试组测试用例: 要保证最后的测试结果 确认测试用例： 一般为东京发送 beta 版后障害书：项目确认者发送，按照同一格式进行书写和填写。 beta 后障害 list 表，其中包含 bug 的简单描述、bug 的类型确定和各部门关于 bug 的总结。（2）过程管理类一个项目两次会议：项目启动会议和项目总结会议项目启动会议主要是讲述项目的功能点，并据具体问题，进行严格的定义，说明本项目所必须遵守的特殊规则，子功能间的前后顺序，统一的接口定义，和每个人在项目实施中应该注意的问题。项目总结会议和 MD 分配方案的确定。
26、主要是根据项目实施的结果，进行集中的讨论文档14和谐而公平的团队：公司其他方面的管理，就是为了加强管理，提倡量化。做到各司其职，多劳多得，公平评价，提供机会给相应的人。3.3.2管理示意图客户需求分支管理与统筹安排东京项目总控人员东京担当者项目控制专员 （ 付歆玮 ）北京项目总控人员北京担当者设计文档审核确认项目质量检测1 t a s k S c h e d u l e2 下周工作安排项目控制专员1 ， 开发内容的规则及 M D 确认方案2 年度发展计划3 月度项目工作量规划4 突发事件的处理1 。 S p e c Q u e s t i o n S h e e t2 . 常规 信息传递基本设
27、计书H e a r i n g S h e e t详细设计书实现M e r g e测试北京东京1 功能点描述文档3.3.3管理人员注意事项其中反馈机制的建立最关键。其中管理必须遵守以下规则：对象 流程编号工作内容 上流方 下流方 备注项目总控人员 分配项目 东京项目发包人员（纪秀玲）部长项目总控助理解决人力矛盾 部长BugSurvey 负责人技术设计负责人部长BugSurvey 负责人技术设计负责人下流方人员负责把结果反馈给东京担当者开发部经理 公司管理问题 部长项目经理全体职员 一定要给问题提出者答复，成为制度后颁布文档15各级负责人职员部长 分配项目 项目总控人员项目总控助理对应分部项目经
28、理项目总控助理Esm 项目负责人加入，修改负责人为此项目经理项目人力调节 无 项目总控人员 如果出现空闲同时反馈。分部管理问题 无 开发部经理项目经理 项目分析和问题确认 无 东京负责人 结果物概要需求文档和问题与回复整理文档项目里程碑信息反馈项目开始时间，alfa,beta 版本时间和原因，fp 变更及原因无 项目总控人员项目总控助理测试部经理组织团队进行技术文档的书写和维护无 测试部经理team 所有成员文档列表如下：功能点文档questionSheetSchedule单体测试用例BugSurvey 负责人Bugsurvey 的调查修改merge项目总控人员 各级的 bug survey
29、leaderBug survey 实施人员 所有的规则按照bugsurve 流程的规定。项目总控助理 监督 esm 的执行情况 程序员项目经理部长项目总控监督过程管理参数 部长项目经理项目总控整理所有项目文档 项目经理 项目总控对日汇报表 系统数据 项目总控绩效考核提供过程情况汇总系统数据 项目总控 月度过程管理处理表测试部经理 组织书写测试用例 项目经理（功能点文档）东京整理汇总 beta 版后 bug分析表项目经理（提供的完整的 后障害书）所有管理者 其中的技术分析和管理分析及对东京的建议应由项目负责人进行填写控制测试的结果3.4 Bugsurvey 工作流参见bugSurvey 工作规约
30、 。3.5 项目分析工作流参见项目分析工作规约3.6 Beta 后质量保证工作流参见beta 后规作规约3.7 测试组 beta 前工作流3.8 项目组基本工作流文档163.8.1概述在项目进行过程中，要求能够及时反馈。做好计划安排，并调整这个人力的配比，以达到最好的效果。3.8.2对程序员的要求 尤其在分析组成立前期，对分析组的设计书，尽可能提出建设性意见和设计的问题，有利于提高项目分析能力 在功能实现上，主要和项目经理的沟通，把类结构设计和代码向理想情况努力，同时用公司内的代码规范作为自己的行动准则 在日常活动中，加强团体意识，加强责任感。3.8.3对项目经理的要求主要职责为： 类设计的严
31、格控制。保证整个软件包的可维护性 项目过程管理。能够紧密的控制整个项目的进程，发现项目中的各种风险因素，尽早地把风险在项目中消除。硬性要求如下：（1） 每个项目（大于 10MD 正常项目）必须提供的文档为功能点文档，questionSheet，单体测试用例，项目总结及 MD 最终分配方案文档（2） 每个项目（大于 10MD 正常项目）必须召开两次会议：项目启动会议主要为了统一项目的内容规则和要求，同时把整体逻辑和框架做简要说明。项目总结会议：主要是评价每个成员的表现和项目完整的状况和质量，总结失败的经验教训。同时根据评论的结果进行最后的 MD 的分配。（3） 在 esm 必须登陆必要的过程参数
32、，以便团队成员和公司的管理者能够及时的把我目前项目状态。 整个团队的建设和公司的管理工作。在项目管理中发现问题，把反映给公司。以备在公司级别对整个流程和各个环节进行调整。3.8.4流程图接收到来自项目总控人员的项目通知关注项目的分析进程并作初步计划接收到来自分析组概要设计第一版的通知对概要设计做初步的审核工作接收到来自分析组详细设计第一版的通知或者东京发注结合项目组的情况进行计划调整项目的类结构设计 （ 项目经理或程序员进行 ）项目经理审批编码项目组内代码检查单员测试提交项目经理e s m 输入代码检查开始日期和代码检查完成日期B U G 管理系统中加入代码检查的结果提交项目经理提交 a l
33、f a 版本确定 A l f a / B e t a版本e s m 中登录项目开始时间e s m 登录 A l f a / B e t a 版时间项目中出现新的问题项目启动会议 ，功能点及 M D 概要分配发送测试组 D B s c r i p t 和 r e s o u r c e 修改文件E s m 系统登录功能点文档名称及服务路径Q u e s t i o n S h e e t 文档名称及路径E s m 系统登录项目安排文档名称及路径书写单元测试用例e s m 输入单元测试用例文档的名称和对应地址把单元测试的结果反映到单元测试用例文档中1 功能点文档2 u e s t i o n S
34、h e e t制作项目安排文档（ v i s i o 或者 p r o j e c t ）要遵守编码规则和类结构方案 ，注意讨论 ， 切记盲目编码制作单元测试文档 （ 参考单元测试模板 ）M a i l 通知 测 试 部 经理 ， 项 目 总 控 助 理邮件通知 项 目 总 控 助 理 、 测 试 组 负 责 人必须同时包含 ： 项目开始时间 ， a l f a 时间 ， 版时间M a i l 反馈给 文 档 作 者 ， 并通知部长以上人员 ， 按照反馈机制进行项目经理邮件通知测 试 部 经 理 ， 项 目总 控 助 理邮件通知 项 目 总 控 助 理和 测 试 部 经 理项目总结会议 ，功能
35、点及 M D 概要分配制作项目总结文档 ，以及 M D 分配方案E s m 系统登录项目总结文档的名称及路径3.8.5项目组文档管理原则： 所有文档必须都放在 fileserver 上，进行统一管理。同时，负责人在本地应保留一份同样的备份。 2004 年开始接收到的项目必须放在 2004 中，针对每个项目必须按照下图进行文档管理。文档17 细节描述项目 内容 备注Spec 设计说明书QuestionSheet设计说明书的补充说明设计说明书的各个版本设计说明书一览表设计说明书一览表要记录所有文档变更的情况，并指明最后项目实施与文档之间的关系Test case 项目组书写的单体测试用例测试组书写的
36、测试用例东京发送的 confirm 测试用例Schedule 针对项目实施的日程安排对东京进行进度汇报的每个报表Function Points功能点文档All Bug Spec Beta 后障害书针对此项目的 beta 后 bug 类型确定和经验汇总。完毕后，应及时发送测试组项目经理。UI Html DemoHearing Sheet联系分析组，如果有应该直接 copyFP Spec FP sheet 不同版本FP change 表FP 说明，记录所有 FP 变更历史，以备后期确认的方便。 项目 spec 的中文版需要打印，此工作由项目总控助理执行。同时，对文档进行归档和密封。3.9 测试部
37、版前流程3.9.1相关人员测试部经理：测试组成员： 文档183.9.2测试人员的要求 一定要注意配合。因为，在此环节，一种好的描述方式和沟通方式将会直接影响工作效率和工作质量。所以，首先大家要注意 bug 管理系统的使用方法和规则，同时，尽量采用统一的属于进行描述，如果需要图形辅助，也可以进行贴图。 加强需求理解能力。能够尽快的理解文档和功能测试用例。 在工作中细致、耐心、有条理。 同时对应 esm 系统需要测试部填写的过程参数必须严格按照规定填写。3.9.3工作流程图文档19接收到项目经理的A l f a / B e t a 版通知并参考 e s m 上的项目信息项目测试安排e s m 登录
38、测试负责人接到项目组提交的A f l a 版通知后按照功能测试用例 ， 开始测试确认连接在测试数据库上确认已经执行 D B s c r i t p t 和r e s o u r c e 修改e s m 登录第一阶段测试开始时间第一阶段测试结束第一阶段测试 B U G 管理系统登录 A l f a 测试 B U GE S M 系统中登录第一阶段完成时间e s m 中登录 A l f a 版本后的 b u g 数测试依据 ： 测试组所整理的测试用例回归测试测试完毕 ， e s m 登录回归测试结束时间提交 B e t a 版F T P 上传 D B s c r i p t 和 R e s o u
39、r c e 修改到东京服务器向日方 ： 中山幸子 、 初宏伟 、 项目负责人 ， 正式发布 B e t a 通知接收到 B e t a 后b u g启动 b e t a 版后流程规约接收到功能点文档书写测试用例e s m 登录测试组测试用例文件名称及路径核查以下条件 ：1 是否已经发送测试组 D B s c r i p t 和 R e s o u r c e 改动 ， 并验证正确性2 单体测试用例是否全部填入单体测试结果M A I L 通知项目负责人 ， 同时确认 b u g 管理系统中 a l f a b u g 的类型和个数D B s c r i p t 和 R e s o u r c e
40、 修改放在 f i l e s e r v e r 对应项目目录下条件不具备 ， 不能进行测试 ， 同时发通知给对应负责人3.9.4注意事项 Bug 管理系统中的状态一定要维护，并通过此系统来保证 alfa bug 修改的进行情况，即在提交 beta 版前，所有的 alfa bug 的状态都应该在 DO 上。如果没有在此状态中，应该积极和项目组联系，测试组有权监督其完成。 测试组要验证项目组提交的 script 和 resoruce 文件，如果有问题，测试文档20组有权通知项目立即修改，同时可以作为 alfa bug 登录在 bug 管理系统中。 测试组要保证测试用例的质量，尽一切可能减少 b
41、eta 后 bug 的数量。并严格的按照 beta 后 bug 处理规约进行。4 绩效考核实施方案4.1 总则： 所有职员的所有工作都应该以量化计算，如果不能，则当事者可以提出异议，而对绩效考核方法进行改进。例如所有北京项目必须有 MD，翻译组翻译工作量可以通过翻译的字数进行调整，测试组同样对工作内容进行分类核算 MD。 量化管理主要包含几个主题方向：工作时间：是人事部门公布的每个月的工时统计的结果。实际上，它代表了自己的实际消耗时间。东京 MD：是实际为公司所创造的价值。北京 MD：主要包含正规作的北京内部项目或者实际工作而作的的补充 MD。已达到考核的公平合理。质量扣除 MD:是指由于代码
42、的 bug 而造成的损失，因为实际的贡献是要扣除损失的。对于测试部就是东京对北京确认产生的 beta 后故障的扣除。过程管理扣除 MD：除了实际的工作量，就是为个建立一个稳固高效的团队而每个人应该承担的过程管理义务，如果没有做好，实际上不仅仅是你自己绩效不高，而是你影响了整个团队的利益。而这部分的值反映了你对团队的影响。过程管理奖励 MD：在项目实施过程中，个人在突发事件上的处理或者对项目整体乃至公司的利益上作出突出贡献，可以作为绩效奖励。 在整个分类上，基本上是划分为管理者，程序员，分析员，翻译人员，测试人员几个子系统。但是所有系统的价值标准统一。 在时间上，每个月的第五个工作日公布绩效考核
43、结果。 绩效考核的结果直接反映在近期和长期的激励系统中。具体内容可以参见4.2 流程图文档21翻译组 MD 核算流程翻译组安排记录算有翻译的字数月度绩效考核年度按照 8 5 0 0字 / M D 进行核算测试组 MD 核算流程测试组接收功能点文档通知书写测试用例按照 M D 1 0 测试实施按照 M D 1 0 A l f a 通知 验证测试用例 提交 b e t a 版接到东京通知后 ， 填写 b e t a 后b u g 归总表月度绩效报表 ， 根据 b e t a 后 b u g 进行质量扣除计算项目组 MD 核算流程接收 t o k y o 的o r d e r根据 F P 确认方案
44、， 和对方担当者进行协商参看 s c h e d u l e 文档和功能点文档进行 M D 的初期分配分配原则 ：1 。 项目组可以支配的额度为 9 0（ 扣除测试部的 1 0 ）2 剩余 9 0 的分配额如下 ：项目分析控制 ： 1 0 机动 M D ： 1 0 项目实施及单体测试 ： 7 0 项目总结会议上 ， 对初期计划不合理的地方进行调整 。程序员最后确定的M D 登陆 e s m项目经理整理M D 分配表存档项目总结会议上 ， 对 1 0 的机动 M D 进行分配 ，鼓励项目经理确认分析组 MD 核算流程文档22分析组项目分析开发规约进行核算M DM D 有异议 ， 书面提交说明给马
45、俊马俊和项目总控人员进行协商 ， 确定后回复担当者北京自我研发项目也按照日本发包要求进行事项 内容 注意 负责人 备注测试组绩效 主要根据测试的工作量和工作结果来进行 MD的度量强调质量，会加大质量影响的力度。测试部经理 要按项目进行分配，多退少补。测试组质量考核 主要是根据 beta 后 bug进行，如果出现 beta后 bug 同时被确认为实施 bug，对应测试人员应该承担质量责任，按一个实施 bug 扣除0.1MD 计算要注意参看beta 后 bug 汇总表。测试组最关键的问题是根据 后的 bug 情况做分析总结，可向公司申请 bug 分析内部文档，通过后可按北京项目补充 MD测试组工作
46、量百分比目前是测试工作本身项目 MD10测试用例的书写是项目MD10目前的测试用例由于是初步书写。所以仅限于第一月项目总控人员 第一月后根据测试用例书写的实际工时和状况重新审核此百分比项目分析工作量 项目分析指拿到文档后，进行的需求详细分析，提出问题，完毕questionSheet 文档和功能电文档原则上项目经理直接进行，同时也可以委托组内具有分析能力的程序员进行，但是必须是项目经理负责制项目经理 MD 分配时谁分析谁拿走对应的 10的 MD项目组质量考核 严格按照 alfa 版后的bug 进行，一个 bug 扣除 0.1MDAlfa 版的 bug登录在 bug 管理系统中，项目经理要维护此系
47、统的 Plan 栏目，程序员要负责其中的 DO 栏目。如果不填写直接作为过程管理扣除 MD 进行，一次 0.1MD测试部经理项目经理Alfa 版质量扣除 MD 的汇总表测试部经理负责。Alfa 版过程管理扣除MD 汇总表由测试部经理负责。项目总控助理负责审核测试部经理的工作，如果出现纰漏，按过程管理扣除 MD 计算，一次0.1md项目组单体测试用例工作量核算单体测试用例的条数必须大于 MD2，核算项目经理直接指定此工作包含在实施 70的范围内。项目经理文档23项目经理和全体管理者自身绩效评定全体 team（包含自身在内）的平均值所以项目经理要提高整个团队的绩效为目标项目经理 由项目总控助理进行
48、监控。出现问题按过失进行处理。年底绩效评定标准直接利用 MD 进行评价 其中包含东京MD 和北京 MD项目总控人员年底绩效加权系数确定项目经理加权 1.25分析组加权 1.1翻译组加权 8500 字/MD进行折算项目总控人员 伴随业务和过程的改变，如果系数有一定的偏差，由项目总控人员对此系数进行调整，反映在文档改版中，并通知全体人员5 开发部激励和过失管理流程5.1 激励管理系统5.1.1 激励的定义和类别定义：激励指职员对公司作出贡献的对应回报。旨在体现公司公平的原则，客观的对个人的能力和价值进行认可。类别与处理方法：类别名称 描述 实施方式 适用范围 备注特别 MD 奖励 在项目中作为突出
49、贡献，对公司的利益产生重大影响。可由部长提出申请，项目总控人员进行批示。特别奖励单全体员工特别奖金奖励在项目中作为突出贡献，对公司的利益产生重大影响。可由管理者直接提议，部长会议进行讨论决定。特别奖励单全体员工部门内项目奖金部长负责制，按季度抽取项目的激励奖金。内容是骨干人员，突出贡献者和分部内的个别活动。 （同时，适用测试部和分析组）金额为：2东京 MD质量扣除 MD财务拨款通知单项目奖金分配明细表开发部内全体员工公司资助培训管理者提议，部长会议审议。针对公司的要求和个人情况，提议确定人选和额度。培训通知书突出贡献者或特别岗位升职 参考绩效表，考察个人能力，并征求个人意见后，进行职位调整。以给有技术或管理能力的人充分的空间。升职通知书管理者考察通过人员加薪 参考绩效表，考察个人能力（技术等级表） ，于每年 8 月和 1 月 启动调整薪金调查程序，对应该薪金的人
