软件项目开发工作流程

软件项目开发工作流程

软件项目开发工作流程

一、简述

对于一个新项目，从可行性研究到产品交货整个生存阶段将经历如下十大流程：

1、项目可行性研究阶段2、立项阶段

3、需求分析阶段4、开发策划阶段5、设计阶段

6、编码实现阶段7、测试阶段8、验收阶段

9、产品交付使用10、维护阶段

二、项目组基本组成及岗位职责

新项目立项时会成立项目组，不同的项目组成员有不同的职责，一个项目组成员也可以身兼多职，但不可身兼全职。

a项目负责人：负责项目的管理、组织、对技术、进度、质量全面负责。b质量保证人员：负责质量保证工作计划的落实和软件的质量保证。

C配管理人员：负责本项目的配管理工作，对本项目的文档、程序是否符合规程文件的要求进行形式化的检查。

D分析人员：主要负责本项目的需求分析工作。E设计人员：主要负责本项目的设计工作。

F程序员：按设计要求和有关标准进行编程工作。

G测试人员：负责单元测试、组合测试和总装测试工作。H文档人员：负责本项目有关文档的编写工作。

I产品经理：协助进行产品研制计划制定、产品发布与产品推广等,在产品开发中，充分代表用户的利益，提供建议,负责在产品功能与出品日期二者之间的权衡;负责产品市场营销、产品销售和市场推广过程。（通常由营销部门或中试部门人员担任）

三、软件开发流程

3．1可行性研究阶段

如果是公司自主开发项目，可行性研究通常是由公司技术负责人根据公司产品规划和市场需求，在要开展新项目前通过部门负责人指定人员进行的前期调研工作，可行性研究负责人员对产品的市场需求、技术发展、市场定位、功能需求、经济效益、进度需求、风险分析等进行可行性研究，提供产品立项建议，拟制可行性研究报告，由部门负责人指定营销部门配合可行性分析人员，技术负责人协助安排。可行性分析完毕后由总工办组织对可行性研究报告进行评审，评审通过后，总工办组织进行立项工作。

如果是系统集成部外接的系统集成项目，在系统集成部与客户签订合同之前，均应对将签项目进行资源、技术、市场的可行性分析，可行性分析通过后、签订合同前由总工办组织相关人员对合同条款进行评审，评审通过后，总工办组织进行立项工作。

本阶段提交的文档：项目可行性研究任务书（技术负责人或部门负责人下达）项目可行性研究报告（可行性研究人员编写）系统集成项目合同质量记录：可行性分析评审报告3．2立项阶段

可行性分析评审通过后，由开发部门经理下达立项任务，指定相关人员填写立项申请报告报批。报批通过后，由部门经理与技术负责人协商，下达开发任务书，经技术负责人审核确认后，报公司批准。批准立项后项目进度应以立项申请报告中的阶段进度为准，如果进度要调整，需填写进度调整申请报告报批。本阶段提交的文档：项目立项申请报告

开发任务书

3．3需求分析阶段

承办单位根据交办单位提出的技术要求和相应的软件任务书以及其它有关文件，与交办单位协作，确定详细的软件需求，该阶段完成的软件需求规格说明经审定和批准后将作为整个软件开发工作的基础列入配管理的基线，在本阶段可利用快速原型法使比较含糊的具有不确定性的软件需求（主要是功能）明确化。能给本公司开发的软件的“需求基线”确定提供一个讨论、进一步完善的基础。在本阶段，由产品经理负责，其他人员配合，编写产品规格说明书，此说明书面向最终用户和领导，主要描绘产品的形状以及功能、性能、功能特性、性能特性。由项目经理负责编写系统技术方案书，描述公司初次使用的技术的详细解决方案。本阶段完毕后对需求分析进行评审，出具需求分析评审报告。本阶段提交的文档：软件需求规格说明书。原型分析说明书产品规格说明书

系统技术方案书

质量记录：需求分析评审报告

提交的软件：产品的原型（注：如果时间有限，可以只编写原型分析说明书而不作原型）

3．4开发策化阶段根据项目要求和软件需求，由配人员配合项目经理编写本项目的质量保证计划、

配管理计划和项目综合计划。在配管理计划中，应列明本项目需提交的各阶段文档的名称，在项目各阶段完成后，项目组需列表说明要移交的文档，将此表与各文档一并向总工办移交。在制定计划时，应为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。

本阶段涉及的文档：软件质量保证计划

配管理计划项目综合计划

3．5设计阶段3．5．1概要设计

根据软件需求规格说明建立软件总体结构和模块间的关系，确定各模块功能，定义各功能模块的接口，设计全局数据库和数据结构，在概要设计明确后，可以对综合计划进一步细化，填写项目进度预计。概要设计需经过评审。本阶段涉及的文档：产品概要设计说明书数据库设计说明项目进度预计质量记录：评审报告3．5．2详细设计

对概要设计中产生的功能模块进行过程描述设计，设计功能模块的内部细节，包括算法和数据结构，为编写源代码提供必要的说明。详细设计需要经过评审。本阶段涉及的文档：软件详细设计说明书测试计划质量记录：评审报告3．6编码实现阶段

根据软件详细设计说明、对各程序模块进行编码、调试、静态分析和单元测试，验证程序单元与设计说明的一致性。本阶段涉及的文档：项目进度月报

项目周计划和周总结

项目开发人员周计划工作日志

每周例会记录

配项更改申请单3．6测试阶段

3．6．1软件单元测试

按详细设计的结构，根据软件单元测试计划，依照将经过单元测试的底层程序单元逐步组装成子项目直到开发项目的过程，对软件进行测试。本阶段涉及的文档：测试计划

测试设计

测试问题报告单参考文档：北京世纪科怡软件开发操作指导书中的“测试阶段操作指导书”

3．6．2组装测试

根据软件需求规格说明书中定义的全部功能和性能要求及组装测试计划，对软件进行组装测试，以确定整个软件是否满足软件需求，是否可以提交总装测试。

软件组装测试计划（含测试用例设计）的编制工作和软件组装测试环境的研制、组建工作，应从软件需求分析阶段起与软件开发同步展开。本阶段涉及的文档：测试计划测试设计

测试问题报告单

3．7中试阶段

项目组开发的软件产品经中试部验收后提交中试部中试，中试部根据需求分析报告,从用户的角度出发对产品的功能、性能进行中试。本阶段涉及的文档：中试计划

中试问题报告单

3．7验收交付

对完成中试的软件进行检查、审查和评审，确定软件是否达到了软件任务书的要求。验收通过的软件可以向软件交办单位交付。项目经理及项目组人员应在此阶段完成项目总结，项目经理提交项目开发总结报告，项目组成员提交个人工作总结报告。

本阶段涉及的文档：验收报告

项目开发总结报告个人工作总结报告

3．8软件维护

对软件的维护包括针对软件运行过程中发现的问题而进行的改正性维护，针对不同任务对软件提出不需求而进行的改善性维护，以及可能出现的由于软件运行环境的改变而进行的适应性维护。本阶段涉及的文档：软件问题汇总表维护报告四、项目开发文件的审批

可行性研究报告及立项申请、项目开发计划及项目开发总结、确认计划及确

认报告、验收计划及验收报告由技术负责人审批。项目组人员编写的其他文件由项目经理审批。

五、各阶段共同的任务要求5．1编写文档

在软件开发过程的各个阶段，都要求完成相应的文档编写工作。本文档的前面部分已给出了在软件自上而下周期各个阶段中的文档编制情况。软件文档从形式上来看，大致可分为两类：a．开发过程中填写的各种图表，称为工作表格；b．应编制的技术资料或技术管理资料，称为文档或文件。按照文档产生和使用的范围，软件文档大致可分为三类：a．开发文档：这类文档是在软件开发过程中，作为软件开发人员前一阶段工作成果的体现和后一阶段工作依据的文档。包括软件需求说明书、数据库设计说明书、概要设计说明书、详细设计说明书、可行性研究报告、项目开发计划。b．管理文档：这类文档是在软件开发过程中，由软件开发人员制定的需提交人员的一些工作计划或工作报告。使管理人员能够通过这些文档了解软件开发项目安排、进度、资源使用和成果等。包括项目开发计划、测试计划、测试报告、开发进度月报、项目周计划周总结及项目开发总结等。c．用户文档：这类文档是软件开发人员为用户准备的有关该软件使用、操作、维护的资料。包括用户手册、操作手册、维护修改建议、软件需求说明书。

项目各阶段完毕后需把本阶段相关文档列表向总工办移交。

5．2验证与评审

软件评审是保证软件产品质量的重要手段，必须纳入软件开发过程，并把评审通过作为一个软件阶段完成的标志，进而转入下一个开发阶段。软件评审包括有正式评审(即评审)、内部评审两种形式。正式评审是软件项目组上级技术主管主持的评审。内部评审以由项目负责人组织、开发人员相互检查为基本方式。

就整个软件开发过程而言，至少要进行可行性分析、软件需求评审、设计评审、软件验证和确认评审、管理评审等五个方面的评审和检查工作。

扩展阅读：软件项目开发流程

＃＃文档

××软件项目开发流程

修改历史日期201*-03-12201*-5-18201*-12-4201*-1-14

作者修改内容新制作人员职责的变更，内容的变更针对201*年度制作最新工作内容下的工作流程添加项目经理管理被职员填写下周日程表的规则1

＃＃文档

1

概述........................................................................31.11.22

目的......................................................................3内容概述..................................................................3

开发部日常管理流程具体实施方案...............................................32.12.22.3

基本原则..................................................................3内容概述..................................................................3内容详细描述..............................................................3

3开发部管理流程具体实施方案..................................................103.13.23.33.43.53.63.73.83.9

内容概述.................................................................10开发部概要流程图.........................................................12开发部管理人员工作流.....................................................12BUGSURVEY工作流............................................................15项目分析工作流...........................................................15BETA后质量保证工作流......................................................15测试组BETA前工作流.......................................................15项目组基本工作流.........................................................15测试部Β版前流程..........................................................19

4绩效考核实施方案...........................................................214.14.2

总则：...................................................................21流程图...................................................................21

5开发部激励和过失管理流程....................................................245.15.2

激励管理系统.............................................................24过失管理系统.............................................................24

2

＃＃文档

1概述

1.1目的

用标准化的流程来统一管理公司的运作，避免混乱，提高管理的质量。在远程开发上，结果××软件自身的特点，量身定做，解决远程开发上的问题。在实施过程中，所有管理者能够根据此统一的流程，总结经验，提高认识，加强

技术水平和管理水平。

提高公司级的技术分析能力，为公司储备一支分析队伍，侧重在需求理解和需求

分析、框架设计上的能力。保证在201*年能够全盘进行中方市场的顺利运作。对人员负责内容上，明确化各自负责的内容，提高工作效率。

1.2内容概述

开发部日常工作流程开发部管理流程开发部绩效考核流程开发部激励和过失管理流程

2开发部日常管理流程具体实施方案

2.1基本原则

公司开发部力求建立公平公正的评价体系，严谨的工作流程定义和及时的记录与反馈，规范职员活动，形成一个紧张有序的团队。

没有一个明晰的流程和高效的反馈体系，就不可能把工作做好。但是，这需要每个人按照规则把自己应该负责的那一部分高效完成，只有这样才能保证整个系统的顺畅，同时，如果个人没有完成自己的指责和按照规定填写内容，影响的不单单是自己的工作而是整个系统。

2.2内容概述

Esm使用规则

目的注意是为了提高开发部整体的计划能力，反馈能力和管理者的控制能力。同时提高整体职员参与公司管理的渠道，适应东京上市公司对信息管理的要求。日常活动的方法

提供开发部工作流程外的突发事件的解决方法

2.3内容详细描述

2.3.1Esm使用规则（1）schedule的使用

3

＃＃文档

加强全体人员的计划能力，做到我每天要做什么？今天项目经理给我的安排是什么？对应项目经理和部长要知道每个人在做什么？只有这样，才能保证控制人员可以宏观调控，而个人也不会不知所措。

注意事项：

1.必须使用长期类型（哪怕只有一天）保持统一性

2开始时间必须为22：00结束时间为23：00，（为了区分其它人填写的日程安排）

3填写日程安排时，必须选择对应的anken，否则不能于系统内的项目关联，统计软件失去作用。

4日程安排的主题要修改，规则为项目号（中文版项目为北京内部项目编号），暂时没有编号可以写项目名称。内容下周工作安排负责人项目经理技术分析负责人测试组经理开发部全体人员开发部全体人员项目总控助理填写要求必须每周五16：00前填写完毕。同时类型统一用长期进行定义，为每一个人员安排下周工作计划。监督人填写监督：项目总控助理内容监督：部长和项目总控人员无违规处理没有按时提交的，管理者扣除MD0.2日常活动安排待办事项制作下周工作安排表

建议大家把工作安排填写，有利于提高自己的计划能力和规划能力。同时能保证事情不会忘记。建议填写，管理者应该必须使用。主要是把事务管理的井井有条。负责利用工具【导出下周工作表系统】制作开发部下周工作计划表。每周五下班前发送东京。无东京项目负责人4

＃＃文档

（2）Report的使用

作为上市公司的子公司要求公司正规化，第一步公司的日报系统的建立

和审查，所以从本年度起必须建立此系统。同时，在管理上解决口头汇报，不客观而事后而无据可查的弊端，为及时了解问题并解决问题，提供第一手的素材。

同时项目总控助理，也要本着实事求是的原则，根据大家的填写内容向

东京证券市场提交《作业公务表》，所有填写者一定要保证填写日报的消耗工时和最后工资结算时当日工时保持严格一致。

内容项目选择对应esm的名称项目填写要求直接选择自己对应的项目,如果工作对象不是项目本身则需要选择以下项目:(顾客名称为201*年过程管理专用)公司会议公司培训公司管理其它注意:只有部长以上才填写以上项目(公司培训除外),部长以下全部选择对应项目。见附图1监督人××违规处理扣除MD0.15

＃＃文档

当日工作内容和进度工作内容与进度1．填写当日的模块名称（模块名称参考2．中的功能点表）3．细度要求功能点要求与工资计算工时想对应。（esm中数据库的数字和工时统计必须对应，此为东京证券的要求）把当天所遇到的问题按照条目化罗列。必须包含内容和状态两部分例如：1内容：BS详细页面存在老bug，状态：已经解决2内容：文档2.3出现问题，无法继续。状态：等待解决填写监督：××内容监督：项目经理数字核对：××没有填写1次人民币5元工作耗时工作耗时数字不对者，按照一次扣除0.1MD不付责任的乱填或不填，一个日报扣除0.1MD(如果在特殊情况下无问题，也要写无)职员如果不填写则按照输入值进行绩效考核。如果职员输入的MD与分配时不符合项目经理扣除0.5MD问题反馈问题反馈内容监督：项目经理MD输入订货（预定）金额必须在项目总结会议结束之后，同时要经过项目经理的审核。输入值为实际值的10倍（因为数值型目前只能为整数）职员的输入由项目经理负责项目经理的核对由项目总控助理进行附图1：

（3）周报（WeekReport）日报（DailyReport）的使用

主要是使用对象为管理者，主要是适用于向管理者汇报整体问题。在概念上，日

6

＃＃文档

报周报为概括说明，而report则属于细节描述。

内容日报负责人项目经理部长－》部长填写要求项目进展状况：不能解决的问题反馈建议或提议突发问题必须反馈项目进展整体状况：不能解决的问题反馈建议或提议必须填写监督人项目总控人员违规处理如果由于没有汇报造成问题，按一次扣除0.5MD周报不写，按一次扣除0.2MD周报项目经理－》部长部长－》项目总控

项目总控助理（4）目标功能的使用

由于分部内有单独的激励费用，所以建议分部内建立目别考核体系。为每一个程序员根据个人不同的能力和状况设定目标，对于圆满完成目标者进行鼓励。同时，保证公司的开发效果在可控制范围内。

（5）项目信息管理的使用。

本管理系统在201*年开始实行，主要目前是记录公司所有项目的里程碑信息。为以后项目的整理和后期处理提供真实的数据。同时，维护公司的项目信息数据库。注意事项：

其中关于项目中所设计的文档，统一放在fileserver上201*目录中。关于文档名称和路径的书写方法如下,保证能够尽快打开文档：

//fileserver/project/201*/14258/测试用例/14258_testcase.xls201*年1月1号起,东京新项目项目项目名称北京项目编号项目类型要求必填，同时应有对应的项目号必填不能为空，目前类型有ResearchNormalConfirmMerge对应负责人××××××出错处理方法扣除MD0.1扣除MD0.1扣除MD0.1备注添加时一定要注意唯一性，与目前的规则为小于5md的均为RESEARCH项目7

＃＃文档

Others必填项目名称××扣除MD0.1客户方负责人分析负责人项目负责人必填北京分析项目，为必填项目东京设计，为非必填必填项目××部长（但是必须制定具体负责人）扣除MD0.1扣除MD0.1项目的名称应包含项目的ID，关于项目ID的生成方法，参考日方对应文档部长扣除MD0.1本公司负责人分析开始时间不能为空××初始必填的人员为项目负责人项目总控人员及助理、对应部长、测试部经理,公司技术负责人（马俊）必填对应该项目的分析员扣除MD0.1项目负责人应该是直接负责人（不是最先指定的部长）如果没有项目负责人，与××联系扣除MD0.1概要设计完成时间必填详细设计完成时间必填FP文档完成时间分析完毕时间项目接收时间项目最终对应MD必填必填必填原则不为空，在特殊情况下为空，在项目备注重必须说明原因。不是必须，但是只要有变更有内容，此项目必须要有原则不为空，在特殊情况下为空，在项目备注重必须说明原因。必填对应该项目的分析员对应该项目的分析员对应该项目的分析员对应该项目的分析员××××项目经理（Mail通知）××项目经理（Mail通知）××扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1公司技术负责人在分析项目开始时应把对应分析员加到项目列表中本MD伴随着MD的变更需要动态变化Md变更附件名称扣除MD0.1项目最终报价扣除MD0.1Schedule文档名称及路径项目经理扣除MD0.2客户方deadline要求Alfa版时间如果提供必填必填××××项目经理（Mail通知）××项目经理（Mail通扣除MD0.1扣除MD0.1必须与对应MD*11000基本一致。同时必须和MD变更纪录一致可以用excel或者是visio，project后两种要以HTML输出以便查阅。Beta版时间必填扣除MD0.18

＃＃文档

知）××项目经理（Mail通知）××项目经理（Mail通知）项目经理项目经理Alfa变更纪录项目开始时间最后一次记录变更的时间必须和对应的alfa版时间和beta版时间一致必填扣除MD0.1扣除MD0.1CSV分支号功能点文档文件名及文件路径（FileServer服务器）单体测试用例文件名称及文件路径项目总结与MD分配方案文档及文件路径测试负责人必填必填扣除MD0.1扣除MD0.1此分支号为开发分支号此文档为必须文档，各项目经理必须严格控制。此文档为必须文档，各项目经理必须严格控制此文档为必须文档，各项目经理必须严格控制。此文档为必须文档，各项目经理必须严格控制。主要要参考beta后bug的整理表必填项目经理扣除MD0.1必填项目经理扣除MD0.1测试用例对应文件名称及路径必填必填××××扣除MD0.1扣除MD0.1第一阶段测试开必填始时间：第一阶段测试完必填成日期：Alfa版本后的必填BUG：回归测试的开始必填日期：回归测试的结束必填日期：Beta版后的BUG必填数：确认负责人不是必须，主要是与是否进行确认有关，如果确认其他有信息，确认负责人必填测试人员测试人员测试人员测试人员测试人员××××扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1

2.3.2系统的使用（1）电子打卡系统的使用

目的：主要是利用电子打卡，提高效率，能够及时反映请假和迟到，并且所有的数据能够直接被人事利用。要求：

9

＃＃文档

201*年2月开始启用，2月为试用期，但是要求每人必须严格填写，如果不填写并结合打卡，忘记填写扣除过程管理MD0.1计算。

（2）会议室、洽谈室、经理室的使用管理

目的：主要是在人数多而会议室相对紧张的状态下，解决矛盾的一种方法。同时审核各项目组是否及时安排公司规定的两次会议。

201*年2月启动，没有按照规定进行会议，经审核后，扣除项目经理过程管理MD0.2,忘记登录的按照统一标准处理。2.3.3公司内部论坛的使用

主要是要有利于公司内部开辟一块公司可以自由发表言论的地方。同时，在技术讨论上，希望能够把知识点做一个累计，以便新员工能够进行参考和积极发表意见。

3开发部管理流程具体实施方案

3.1内容概述

开发部从流程上主要分为以下几方面：（1）开发部管理人员工作流（2）BUGSurvey工作流（3）项目分析工作流（4）Beta后质量保证工作流（5）测试组beta前工作流（6）项目组运行基本工作流开发部从实施人员角色划分如下：开发部经理：（DM01）

统筹解决公司开发部的全部事宜。进行开发部的整体计划的制定和实施，保证开发部的可持续发展和利润率。

项目总控人员：(DM02)

对公司级的资源进行调配，同时，直接了解日方的战略安排，为北京方的战略安排提供的第一手的资料。同时，在项目分配上保证三个分部间项目的均衡（一个季度内）

开发部部长：(DM10)

在公司统一的规则范围内，负责分部的建设。协调各开发组的问题，处理解决分部内发生的问题。做好所有公司要求的标准流程内的内容。同时，在许可范围内，可以进行单独的管理方法的尝试和分部内激励的分配。

10

＃＃文档

技术设计负责人：(DM11)

统一协调分析组的工作，在对日项目分析组中，进行设计文档的统一确认，在对中方项目中，承担需求的统一把关处理。同时负责分析组的日常工作安排的统筹。

BUGSurvey总负责人(DM12)：

统一管理package和已经提交项目的统筹管理。组织形式上，倾向于单独的组织模式。在目前的情况下，以灵活为主，临时性的进行bugSurvey组的组织和bugSurvey组内teamleader的指定和管理。在间隙阶段，直接进入分析组进行项目分析工作。

项目总控助理：××(DM13)

辅助开发部的项目管理工作，主要负责中日双方的信息的反馈纪录整理，以及esm和taskschedule信息的维护工作。

负责公司级项目文档，过程参数的监督，同时向日本总部汇报各种参数和报表。

常务项目经理：(DM20)目前11名

各分部内程序员的日常管理，整个开发过程中的控制和日方负责人的信息交互，负责组内程序员的绩效考核和问题解决。测试部经理和翻译部经理包含在内。

技术分析员：(DM21)

对日方的需求进行概要分析和设计，并书写设计书，FP。对中方的项目中，负责需求的整理和各种设计文档的实施，同时，负责和项目经理和测试部经理的沟通。

临时项目经理：(DM22)

此角色主要是在接受日方外包项目或整体公司产品设计中，需要临时成立项目组，而从分析组中或者常务项目经理中抽调。临时项目经理需要全权负责此项目的实施，同时需要和公司签订项目负责保证书，以保证项目的进行和最后单独项目激励的兑现。程序员：

主要是负责项目按照分析文档的实施，同时，在实施过程中优化代码结构，提出合理化建议，其中优秀者可以作为TeamLeader负责具体组织工作和分析管理工作。测试员：

负责公司测试流程的具体实施，要求掌握测试的技术，提出合理化建议，并保证整个软件的可靠度。

翻译人员：

11

＃＃文档

负责中日方文档的翻译，要求工作严谨，保证质量。在同日方交流中，负责接待和沟通。同时，在个人的发展意向中可以兼顾其它公司内的常务工作。

3.2开发部概要流程图

软脑软件开发部整体概要流程图出现bug,进行回归处理日方委托开发基本设计书（含DB),Fp表项目总控人员--〉部长--〉常务项目经理项目实施，提交alfa版本测试部进行软件测试，提交beta版本东京项目负责人项目总控助理进行项目信息管理日方委托研发实施东京方或顾客提出需求北京分析人员进行需求整理书写hearingsheet制作demo书写FP表书写基本设计书（含DB),测试用例Tokyo确认中方项目和顾客进行需求获取整理UseCase图分析组实施数据库设计分析组实施项目整体计划demo和设计文档类似委托开发流程

3.3开发部管理人员工作流

3.3.1软件开发管理体系构成参与人员：

项目总控人员（项目总控助理）+部长+（技术设计负责人+BugSurvey负责人）+各级项目经理

管理主线：（1）工具类

taskschedule表：主要目的是增加远程开发的计划和规划性。

管理人员去合适目前我们正在进行的总量有多少，检收而为付款的有多少，

实施完毕而没有检收的有多少。

12

＃＃文档

管理人员去看我们下周能够接受的项目有多少，以便在每周五可以制定下周

的工作计划。

项目经理可以看自己负责项目的基本参数。

Esm系统：通过esm系统详细的记录开发过程中的每个里程碑参数，保证在管理上能够提高管理细度，以便于及时发现并改正问题和错误。

Bug管理系统：作为质量控制过程实际结果的监控。以便总结质量的问题，进行反馈。

Fileserver文档：通过文档管理和整理，保证全部职员能够随时的了解其他项目的信息和相信内容。同时，统一化文档管理，为以后的发展提供素材。所有的文档主要包含如下几种：

HearingSheet：一个简要的需求，重点在于强调这个需求的原因（前因后果）UI文件

设计文档：东京和北京共同进行FP报价书

QuestionSheet：所有的问题一定要集中在一个文档内

功能点文档：一定要融合questionSheet内对应答案的所有内容schedule文档：要包含甘特图

项目总结及MD分配方案：把项目总结作为重点进行。单体测试用例；条数最少为MD*2,按照模板进行测试组测试用例:要保证最后的测试结果确认测试用例：一般为东京发送

beta版后障害书：项目确认者发送，按照同一格式进行书写和填写。beta后障害list表，其中包含bug的简单描述、bug的类型确定和各部门关

于bug的总结。

（2）过程管理类

一个项目两次会议：项目启动会议和项目总结会议

项目启动会议主要是讲述项目的功能点，并据具体问题，进行严格的定义，说明本项目所必须遵守的特殊规则，子功能间的前后顺序，统一的接口定义，和每个人在项目实施中应该注意的问题。

项目总结会议和MD分配方案的确定。主要是根据项目实施的结果，进行集中的讨论

和谐而公平的团队：公司其他方面的管理，就是为了加强管理，提倡量化。做到各司其职，多劳多得，公平评价，提供机会给相应的人。

13

＃＃文档

3.3.2管理示意图

东京客户需求东京项目总控人员1，开发内容的规则及MD确认方案2年度发展计划3月度项目工作量规划4突发事件的处理北京北京项目总控人员基本设计书HearingSheet详细设计书设计文档审核确认项目控制专员1taskSchedule2下周工作安排项目控制专员（付歆玮）实现分支管理与统筹安排1功能点描述文档Merge1。SpecQuestionSheet2.常规信息传递项目质量检测东京担当者北京担当者测试

3.3.3管理人员注意事项

其中反馈机制的建立最关键。其中管理必须遵守以下规则：

对象项目总控人员流程工作内容编号分配项目解决人力矛盾上流方东京项目发包人员（纪秀玲）部长BugSurvey负责人技术设计负责人部长项目经理各级负责人职员项目总控人员下流方部长项目总控助理部长BugSurvey负责人技术设计负责人全体职员备注下流方人员负责把结果反馈给东京担当者开发部经理公司管理问题一定要给问题提出者答复，成为制度后颁布部长分配项目对应分部项目Esm项目负责人加入，修14

＃＃文档

项目总控助理项目经理项目人力调节分部管理问题项目分析和问题确认项目里程碑信息反馈项目开始时间，alfa,beta版本时间和原因，fp变更及原因组织团队进行技术文档的书写和维护无无无无经理项目总控助理项目总控人员开发部经理东京负责人项目总控人员项目总控助理测试部经理改负责人为此项目经理如果出现空闲同时反馈。结果物概要需求文档和问题与回复整理文档无BugSurvey负责人Bugsurvey的调查修改merge项目总控人员项目总控助理监督esm的执行情况测试部经理监督过程管理参数整理所有项目文档对日汇报表绩效考核提供过程情况汇总组织书写测试用例整理汇总beta版后bug分析表控制测试的结果程序员项目经理部长部长项目经理项目经理系统数据系统数据项目经理（功能点文档）项目经理（提供的完整的β后障害书）测试部经理文档列表如下：team所有成员功能点文档questionSheetSchedule单体测试用例各级的bug所有的规则按照surveyleaderbugsurve流程的规定。Bugsurvey实施人员项目总控项目总控项目总控项目总控项目总控东京所有管理者月度过程管理处理表其中的技术分析和管理分析及对东京的建议应由项目负责人进行填写

3.4Bugsurvey工作流

参见《bugSurvey工作规约》。

3.5项目分析工作流

参见《项目分析工作规约》

3.6Beta后质量保证工作流

参见《beta后规作规约》

3.7测试组beta前工作流3.8项目组基本工作流

3.8.1概述

在项目进行过程中，要求能够及时反馈。做好计划安排，并调整这个人力的配比，以达到最好的效果。

15

＃＃文档

3.8.2对程序员的要求

尤其在分析组成立前期，对分析组的设计书，尽可能提出建设性意见和设计

的问题，有利于提高项目分析能力

在功能实现上，主要和项目经理的沟通，把类结构设计和代码向理想情况努

力，同时用公司内的代码规范作为自己的行动准则在日常活动中，加强团体意识，加强责任感。

3.8.3对项目经理的要求主要职责为：

类设计的严格控制。保证整个软件包的可维护性

项目过程管理。能够紧密的控制整个项目的进程，发现项目中的各种风险因

素，尽早地把风险在项目中消除。硬性要求如下：

（1）每个项目（大于10MD正常项目）必须提供的文档为功能点文档，

questionSheet，单体测试用例，项目总结及MD最终分配方案文档

（2）每个项目（大于10MD正常项目）必须召开两次会议：

项目启动会议主要为了统一项目的内容规则和要求，同时把整体逻辑和框架做简要说明。

项目总结会议：主要是评价每个成员的表现和项目完整的状况和质量，总结失败的经验教训。同时根据评论的结果进行最后的MD的分配。

（3）在esm必须登陆必要的过程参数，以便团队成员和公司的管理者能够

及时的把我目前项目状态。

整个团队的建设和公司的管理工作。在项目管理中发现问题，把反映给公司。

以备在公司级别对整个流程和各个环节进行调整。3.8.4流程图

16

＃＃文档

接收到来自项目总控人员的项目通知关注项目的分析进程并作初步计划1功能点文档2uestionSheetEsm系统登录功能点文档名称及服务路径QuestionSheet文档名称及路径Mail通知测试部经理，项目总控助理接收到来自分析组概要设计第一版的通知对概要设计做初步的审核工作确定Alfa/Beta版本邮件通知项目总控助理、测试组负责人必须同时包含：项目开始时间，alfa时间，β版时间esm中登录项目开始时间esm登录Alfa/Beta版时间接收到来自分析组详细设计第一版的通知或者东京发注结合项目组的情况进行计划调整制作项目安排文档（visio或者project）Esm系统登录项目安排文档名称及路径项目启动会议，功能点及MD概要分配项目的类结构设计（项目经理或程序员进行）项目经理审批编码要遵守编码规则和类结构方案，注意讨论，切记盲目编码项目中出现新的问题Mail反馈给文档作者，并通知部长以上人员，按照反馈机制进行项目组内代码检查提交项目经理esm输入代码检查开始日期和代码检查完成日期BUG管理系统中加入代码检查的结果书写单元测试用例制作单元测试文档（参考单元测试模板）esm输入单元测试用例文档的名称和对应地址单员测试提交项目经理项目经理邮件通知测试部经理，项目总控助理把单元测试的结果反映到单元测试用例文档中邮件通知项目总控助理和测试部经理发送测试组DBscript和resource修改文件提交alfa版本项目总结会议，功能点及MD概要分配制作项目总结文档，以及MD分配方案Esm系统登录项目总结文档的名称及路径17

＃＃文档

3.8.5项目组文档管理

原则：

所有文档必须都放在fileserver上，进行统一管理。同时，负责人在本地

应保留一份同样的备份。

201*年开始接收到的项目必须放在201*中，针对每个项目必须按照下图进

行文档管理。

细节描述

项目

Spec

内容

设计说明书QuestionSheet

设计说明书的补充说明设计说明书的各个版本设计说明书一览表

项目组书写的单体测试用例测试组书写的测试用例

东京发送的confirm测试用例针对项目实施的日程安排

对东京进行进度汇报的每个报表

功能点文档

备注

设计说明书一览表要记录所有文档变更的情况，并指明最后项目实施与文档之间的关系

Testcase

Schedule

FunctionPoints

AllBugSpecBeta后障害书

针对此项目的beta后bug类型确定和经验汇总。完毕后，应及时发送测试组项目经理。

UIHtmlDemoHearing联系分析组，如果有应该直接copySheetFPSpecFPsheet不同版本

FPchange表FP说明，记录所有FP变更历史，以备后期确认的方便。

项目spec的中文版需要打印，此工作由项目总控助理执行。同时，对文档

18

＃＃文档

进行归档和密封。

3.9测试部β版前流程

3.9.1相关人员测试部经理：××测试组成员：

3.9.2测试人员的要求

一定要注意配合。因为，在此环节，一种好的描述方式和沟通方式将会直接

影响工作效率和工作质量。所以，首先大家要注意bug管理系统的使用方法和规则，同时，尽量采用统一的属于进行描述，如果需要图形辅助，也可以进行贴图。

加强需求理解能力。能够尽快的理解文档和功能测试用例。在工作中细致、耐心、有条理。

同时对应esm系统需要测试部填写的过程参数必须严格按照规定填写。

3.9.3工作流程图

19

＃＃文档

接收到功能点文档书写测试用例esm登录测试组测试用例文件名称及路径接收到项目经理的Alfa/Beta版通知并参考esm上的项目信息项目测试安排esm登录测试负责人核查以下条件：1是否已经发送测试组DBscript和Resource改动，并验证正确性2单体测试用例是否全部填入单体测试结果接到项目组提交的Afla版通知后按照功能测试用例，开始测试条件不具备，不能进行测试，同时发通知给对应负责人确认连接在测试数据库上确认已经执行DBscritpt和resource修改esm登录第一阶段测试开始时间第一阶段测试测试依据：测试组所整理的测试用例BUG管理系统登录Alfa测试BUG第一阶段测试结束MAIL通知项目负责人，同时确认bug管理系统中alfabug的类型和个数ESM系统中登录第一阶段完成时间esm中登录Alfa版本后的bug数回归测试测试完毕，esm登录回归测试结束时间提交Beta版DBscript和Resource修改放在fileserver对应项目目录下FTP上传DBscript和Resource修改到东京服务器向日方：中山幸子、初宏伟、项目负责人，正式发布Beta通知接收到Beta后bug启动beta版后流程规约

3.9.4注意事项

Bug管理系统中的状态一定要维护，并通过此系统来保证alfabug修改的进

行情况，即在提交beta版前，所有的alfabug的状态都应该在DO上。如果没有在此状态中，应该积极和项目组联系，测试组有权监督其完成。测试组要验证项目组提交的script和resoruce文件，如果有问题，测试组

20

＃＃文档

有权通知项目立即修改，同时可以作为alfabug登录在bug管理系统中。测试组要保证测试用例的质量，尽一切可能减少beta后bug的数量。并严格

的按照beta后bug处理规约进行。

4绩效考核实施方案

4.1总则：

所有职员的所有工作都应该以量化计算，如果不能，则当事者可以提出异议，

而对绩效考核方法进行改进。

例如所有北京项目必须有MD，翻译组翻译工作量可以通过翻译的字数进行调整，测试组同样对工作内容进行分类核算MD。量化管理主要包含几个主题方向：

工作时间：是人事部门公布的每个月的工时统计的结果。实际上，它代表了自己的实际消耗时间。

东京MD：是实际为公司所创造的价值。

北京MD：主要包含正规作的北京内部项目或者实际工作而作的的补充MD。已达到考核的公平合理。

质量扣除MD:是指由于代码的bug而造成的损失，因为实际的贡献是要扣除损失的。对于测试部就是东京对北京确认产生的beta后故障的扣除。

过程管理扣除MD：除了实际的工作量，就是为个建立一个稳固高效的团队而每个人应该承担的过程管理义务，如果没有做好，实际上不仅仅是你自己绩效不高，而是你影响了整个团队的利益。而这部分的值反映了你对团队的影响。

过程管理奖励MD：在项目实施过程中，个人在突发事件上的处理或者对项目整体乃至公司的利益上作出突出贡献，可以作为绩效奖励。

在整个分类上，基本上是划分为管理者，程序员，分析员，翻译人员，测试人

员几个子系统。但是所有系统的价值标准统一。在时间上，每个月的第五个工作日公布绩效考核结果。

绩效考核的结果直接反映在近期和长期的激励系统中。具体内容可以参见

4.2流程图

翻译组MD核算流程

21

＃＃文档

翻译组安排记录算有翻译的字数月度绩效考核年度按照8500字/MD进行核算测试组MD核算流程

测试组接收功能点文档通知书写测试用例按照MD10％Alfa通知验证测试用例测试实施按照MD10％提交beta版接到东京通知后，填写beta后bug归总表月度绩效报表，根据beta后bug进行质量扣除计算项目组MD核算流程

分配原则：1。项目组可以支配的额度为90％（扣除测试部的10％）2剩余90％的分配额如下：项目分析控制：10％机动MD：10％项目实施及单体测试：70％程序员最后确定的MD登陆esm项目经理确认项目经理整理MD分配表存档接收tokyo的order根据FP确认方案，和对方担当者进行协商参看schedule文档和功能点文档进行MD的初期分配项目总结会议上，对初期计划不合理的地方进行调整。项目总结会议上，对10％的机动MD进行分配，鼓励

分析组MD核算流程

22

＃＃文档

分析组项目分析开发规约进行核算MDMD有异议，书面提交说明给马俊马俊和项目总控人员进行协商，确定后回复担当者北京自我研发项目也按照日本发包要求进行事项

测试组绩效

内容

主要根据测试的工作量和工作结果来进行MD的度量

主要是根据beta后bug进行，如果出现beta后bug同时被确认为实施bug，对应测试人员应该承担质量责任，按一个实施bug扣除0.1MD计算

目前是测试工作本身项目MD×10％

测试用例的书写是项目MD×10％

项目分析指拿到文档后，进行的需求详细分析，提出问题，完毕questionSheet文档和功能电文档

注意

强调质量，会加大质量影响的力度。

要注意参看beta后bug汇总表。

负责人

测试部经理

备注

要按项目进行分配，多退少补。

测试组最关键的问题是根据β后的bug情况做分析总结，可向公司申请bug分析内部文档，通过后可按北京项目补充MD

第一月后根据测试用例书写的实际工时和状况重新审核此百分比MD分配时谁分析谁拿走对应的10％的MD

测试组质量考核

测试组工作量百分比

项目分析工作量

项目组质量考核

严格按照alfa版后的bug进行，一个bug扣除0.1MD

目前的测试用例由于是初步书写。所以仅限于第一月

原则上项目经理直接进行，同时也可以委托组内具有分析能力的程序员进行，但是必须是项目经理负责制

Alfa版的bug登录在bug管理系统中，项目经理要维护此系统的Plan栏目，程序员要负责其中的DO栏目。如果不填写直接作为过程管理扣除MD进行，一次0.1MD

此工作包含在实施70％的范围内。

所以项目经理要

项目总控人员

项目经理

测试部经理项目经理

项目组单体测试用例工作量核算项目经理和全体单体测试用例的条数必须大于MD×2，核算项目经理直接指定

全体team（包含自身在

项目经理

Alfa版质量扣除MD的汇总表测试部经理负责。

Alfa版过程管理扣除MD汇总表由测试部经理负责。

项目总控助理负责审核测试部经理的工作，如果出现纰漏，按过程管理扣除MD计算，一次0.1md

项目经理由项目总控助理进行监

23

＃＃文档

管理者自身绩效评定年底绩效评定标准年底绩效加权系数确定内）的平均值直接利用MD进行评价项目经理加权1.25分析组加权1.1翻译组加权8500字/MD进行折算提高整个团队的绩效为目标其中包含东京MD和北京MD控。出现问题按过失进行处理。伴随业务和过程的改变，如果系数有一定的偏差，由项目总控人员对此系数进行调整，反映在文档改版中，并通知全体人员项目总控人员项目总控人员5开发部激励和过失管理流程

5.1激励管理系统

5.1.1定义：

激励指职员对公司作出贡献的对应回报。旨在体现公司公平的原则，客观的对个人的能力和价值进行认可。类别与处理方法：

类别名称描述特别MD奖励在项目中作为突出贡献，对公司的利益产生重大影响。可由部长提出申请，项目总控人员进行批示。特别奖金奖在项目中作为突出贡献，对公司的利益励产生重大影响。可由管理者直接提议，部长会议进行讨论决定。部门内项目部长负责制，按季度抽取项目的激励奖奖金金。内容是骨干人员，突出贡献者和分部内的个别活动。（同时，适用测试部和分析组）金额为：2×[东京MD－质量扣除MD]公司资助培管理者提议，部长会议审议。针对公司训的要求和个人情况，提议确定人选和额度。升职参考绩效表，考察个人能力，并征求个人意见后，进行职位调整。以给有技术或管理能力的人充分的空间。加薪参考绩效表，考察个人能力（技术等级表），于每年8月和1月启动调整薪金调查程序，对应该薪金的人进行处理年终奖金年终奖金额度由东京董事会根据北京利益情况进行直接确定奖金分配采用同一职能部门公开化，计算方法，严格按照个人MD（贡献MD－扣除MD）的百分比进行直接计算。

实施方式特别奖励单特别奖励单财务拨款通知单项目奖金分配明细表培训通知书升职通知书薪金调整单年终奖金分配表适用范围全体员工备注激励的定义和类别

全体员工开发部内全体员工突出贡献者或特别岗位管理者考察通过人员管理者考察通过人员全体员工5.2过失管理系统

5.2.1定义：

24

＃＃文档

过失泛指由于本人的失误和错误，对公司的利益或潜在利益造成比较大的影响和比较大的损失的行为，称作过失。

5.2.2类别：（过失单的类别部分必须从下面列表中取得）

类别名称决策过失描述在公司级的问题上，由于考虑问题不周，或没有广泛讨论或没有上级的同意而匆忙下确定，在结果上造成损失或严重影响。没有贯彻成文或讨论会议上的决议，在运作上自己决定，在结果上造成损失或严重影响。在技术过程管理上，中层领导应全盘负责技术处理的决定和整个开发过程的督导，如果在实现上漏掉其中的过程或没有督导，在结果上造成损失或严重影响。没有遵守公司的规章制度，经规劝后无效果的。同时，在公司范围内造成较大影响的。由于在具体实现上，出现失误，造成损失或严重影响。但是必须经过评审组的详细调查和本人同意。如果此问题是由于工作态度或缺乏责任心引起的，加大处理力度。公司针对管理责任化的原则，制定具体的人承担特定的职责。如果，在指定职责范围内，出现重大失误。适用范围管理者和中层管理层管理者和中层管理层管理者和中层管理层备注运作管理过失技术过程管理过失既是直接责任人为某个人，也要主体负责违反公司规章过失技术实现过失公司全体职员开发部全体职员特别职责过失特别职责负责人其他过失伴随着新的要求和管理的变化而产生的新的类型的过失。公司全体员工如果在特别职责范围内表现突出，可以优先考虑特别奖励制度对应此项，要加强审核制度，避免主观化5.2.3过失处理的种类：

过失处理可以采取并罚制度。类别名称公司通报描述在月度会议（结合绩效总结会议）上，进行通报。Md的补充处理根据影响的程度和过失的程度来确定。MD计入当月的绩效考核，MD的类型为北京MD。适用范围为固定MD的项目和业务过失或项目管理过失。罚金根据影响度和后果，进行度量。考虑到解决问题为本，警示为主的原则。在数额分50/100/150/200，共4个等级。备注重点强调避免办法同时，要客观尊重实际MD,但是此处理要直接影响月度考评和年底考评。此种类型的处罚，不得在季度绩效考核中取得特别奖励。25

＃＃文档

降薪过失影响很巨大，同时，过失人没有改正的倾向。工作态度或工作结果在长时间没有进展，不符合本身的业务标准或薪资标准。

5.2.4制度实施流程

过失管理流程管理者根据客户反馈或工作效益，就具体责任人提出过失处理提议评审组本人解释相关内容和过程提出调查组织评审组，至少3人，确定3个代表通知责任当事人，准备资料和申辩材料接收到评审组通知后准备资料过失评审，表决总结提出提议的时机和方式方法，向当事人道歉解释否通过否总结自己的行为是否有连带责任是填写过失单过失单发送人事部抄送管理者和绩效考核人员绩效管理上处理5.2.5几点补充说明：

26

＃＃文档

首先过失和特别奖励的数目在总体上要把握，原则上不能超过月度3事件（一个

事件可能牵涉多个责任人），同时，要把握时机，基本上要在事件后3-4天处理，保证其情绪化和调查不详细的影响。

评审组的成立。原则为相关事件的相关人员，责任人的直接上司。不能低于三人，

要求评审组在当事人面前，进行所有的活动。凡是有意庇护或回避意见，可以取消评审组资格，同时考虑其过失行为。

与绩效相关部分的处理，解释权归公司，任何当事人有权利询问任何处理影响。

同时，在处理意见上要写清楚。

所有当事人，都要本着把事情处理好，并把以后的工作做得更好的原则去进行。

从大处着眼，以认识问题为主，这也是公司处理的根本，而非处罚某人。所有的处理决定，都要本人书写意见，如果本人不同意，任何人没有权利强行实

施。

“避免过失的方法“，由评审组统一讨论填写，这是整个过失管理的主题。评审

组不能对此项进行简略或应付，同时，需要得到当事人的认可。

27

友情提示：本文中关于《软件项目开发工作流程》给出的范例仅供您参考拓展思维使用，软件项目开发工作流程：该篇文章建议您自主创作。

　　来源：网络整理 免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。

《软件项目开发工作流程》
由互联网用户整理提供,转载分享请保留原作者信息,谢谢!
http://m.bsmz.net/gongwen/722204.html

• 上一篇：个人博客总结系统项目总结

• 下一篇：软件开发心得总结