2021年软件项目开发工作流程_第1页
2021年软件项目开发工作流程_第2页
2021年软件项目开发工作流程_第3页
已阅读5页,还剩23页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、精选word文档 下载可编辑软件项目开发工作流程软件项目开发工作流程一、简述对于一个新项目,从可行性研究到产品交货整个生存阶段将经历如下十大流程1、项目可行性研究阶段2、立项阶段3、需求分析阶段4、开发策划阶段5、设计阶段6、编码实现阶段7、测试阶段8、验收阶段9、产品交付使用10、维护阶段二、项目组基本组成及岗位职责新项目立项时会成立项目组,不同的项目组成员有不同的职责,一个项目组成员也可以身兼多职,但不可身兼全职。a项目负责人负责项目的管理、组织、对技术、进度、质量全面负责。b质量保证人员负责质量保证工作计划的落实和软件的质量保证。c配管理人员负责本项目的配管理工作,对本项目的文档、程序是

2、否符合规程文件的要求进行形式化的检查。d分析人员主要负责本项目的需求分析工作。e设计人员主要负责本项目的设计工作。f程序员按设计要求和有关标准进行编程工作。g测试人员负责单元测试、组合测试和总装测试工作。h文档人员负责本项目有关文档的编写工作。i产品经理协助进行产品研制计划制定、产品发布与产品推广等,在产品开发中,充分代表用户的利益,提供建议,负责在产品功能与出品日期二者之间的权衡;负责产品市场营销、产品销售和市场推广过程。(通常由营销部门或中试部门人员担任)三、软件开发流程31可行性研究阶段如果是公司自主开发项目,可行性研究通常是由公司技术负责人根据公司产品规划和市场需求,在要开展新项目前通

3、过部门负责人指定人员进行的前期调研工作,可行性研究负责人员对产品的市场需求、技术发展、市场定位、功能需求、经济效益、进度需求、风险分析等进行可行性研究,提供产品立项建议,拟制可行性研究报告,由部门负责人指定营销部门配合可行性分析人员,技术负责人协助安排。可行性分析完毕后由总工办组织对可行性研究报告进行评审,评审通过后,总工办组织进行立项工作。如果是系统集成部外接的系统集成项目,在系统集成部与客户签订合同之前,均应对将签项目进行资源、技术、市场的可行性分析,可行性分析通过后、签订合同前由总工办组织相关人员对合同条款进行评审,评审通过后,总工办组织进行立项工作。本阶段提交的文档项目可行性研究任务书

4、(技术负责人或部门负责人下达)项目可行性研究报告(可行性研究人员编写)系统集成项目合同质量记录可行性分析评审报告32立项阶段可行性分析评审通过后,由开发部门经理下达立项任务,指定相关人员填写立项申请报告报批。报批通过后,由部门经理与技术负责人协商,下达开发任务书,经技术负责人审核确认后,报公司批准。批准立项后项目进度应以立项申请报告中的阶段进度为准,如果进度要调整,需填写进度调整申请报告报批。本阶段提交的文档项目立项申请报告开发任务书33需求分析阶段承办单位根据交办单位提出的技术要求和相应的软件任务书以及其它有关文件,与交办单位协作,确定详细的软件需求,该阶段完成的软件需求规格说明经审定和批准

5、后将作为整个软件开发工作的基础列入配管理的基线,在本阶段可利用快速原型法使比较含糊的具有不确定性的软件需求(主要是功能)明确化。能给本公司开发的软件的“需求基线”确定提供一个讨论、进一步完善的基础。在本阶段,由产品经理负责,其他人员配合,编写产品规格说明书,此说明书面向最终用户和领导,主要描绘产品的形状以及功能、性能、功能特性、性能特性。由项目经理负责编写系统技术方案书,描述公司初次使用的技术的详细解决方案。本阶段完毕后对需求分析进行评审,出具需求分析评审报告。本阶段提交的文档软件需求规格说明书。原型分析说明书产品规格说明书系统技术方案书质量记录需求分析评审报告提交的软件产品的原型(注如果时间

6、有限,可以只编写原型分析说明书而不作原型)34开发策化阶段根据项目要求和软件需求,由配人员配合项目经理编写本项目的质量保证计划、配管理计划和项目综合计划。在配管理计划中,应列明本项目需提交的各阶段文档的名称,在项目各阶段完成后,项目组需列表说明要移交的文档,将此表与各文档一并向总工办移交。在制定计划时,应为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。本阶段涉及的文档软件质量保证计划配管理计划项目综合计划35设计阶段351概要设计根据软件需求规格说明建立软件总体结构和模块间的关系,确定各模块功能,定义各功能模块的接口,设计全局数据库和数据结构,

7、在概要设计明确后,可以对综合计划进一步细化,填写项目进度预计。概要设计需经过评审。本阶段涉及的文档产品概要设计说明书数据库设计说明项目进度预计质量记录评审报告352详细设计对概要设计中产生的功能模块进行过程描述设计,设计功能模块的内部细节,包括算法和数据结构,为编写源代码提供必要的说明。详细设计需要经过评审。本阶段涉及的文档软件详细设计说明书测试计划质量记录评审报告36编码实现阶段根据软件详细设计说明、对各程序模块进行编码、调试、静态分析和单元测试,验证程序单元与设计说明的一致性。本阶段涉及的文档项目进度月报项目周计划和周总结项目开发人员周计划工作日志每周例会记录配项更改申请单36测试阶段36

8、1软件单元测试按详细设计的结构,根据软件单元测试计划,依照将经过单元测试的底层程序单元逐步组装成子项目直到开发项目的过程,对软件进行测试。本阶段涉及的文档测试计划测试设计测试问题报告单参考文档北京世纪科怡软件开发操作指导书中的“测试阶段操作指导书”362组装测试根据软件需求规格说明书中定义的全部功能和性能要求及组装测试计划,对软件进行组装测试,以确定整个软件是否满足软件需求,是否可以提交总装测试。软件组装测试计划(含测试用例设计)的编制工作和软件组装测试环境的研制、组建工作,应从软件需求分析阶段起与软件开发同步展开。本阶段涉及的文档测试计划测试设计测试问题报告单37中试阶段项目组开发的软件产品

9、经中试部验收后提交中试部中试,中试部根据需求分析报告,从用户的角度出发对产品的功能、性能进行中试。本阶段涉及的文档中试计划中试问题报告单37验收交付对完成中试的软件进行检查、审查和评审,确定软件是否达到了软件任务书的要求。验收通过的软件可以向软件交办单位交付。项目经理及项目组人员应在此阶段完成项目总结,项目经理提交项目开发总结报告,项目组成员提交个人工作总结报告。本阶段涉及的文档验收报告项目开发总结报告个人工作总结报告38软件维护对软件的维护包括针对软件运行过程中发现的问题而进行的改正性维护,针对不同任务对软件提出不需求而进行的改善性维护,以及可能出现的由于软件运行环境的改变而进行的适应性维护

10、。本阶段涉及的文档软件问题汇总表维护报告四、项目开发文件的审批可行性研究报告及立项申请、项目开发计划及项目开发总结、确认计划及确认报告、验收计划及验收报告由技术负责人审批。项目组人员编写的其他文件由项目经理审批。五、各阶段共同的任务要求51编写文档在软件开发过程的各个阶段,都要求完成相应的文档编写工作。本文档的前面部分已给出了在软件自上而下周期各个阶段中的文档编制情况。软件文档从形式上来看,大致可分为两类a开发过程中填写的各种图表,称为工作表格;b应编制的技术资料或技术管理资料,称为文档或文件。按照文档产生和使用的范围,软件文档大致可分为三类a开发文档这类文档是在软件开发过程中,作为软件开发人

11、员前一阶段工作成果的体现和后一阶段工作依据的文档。包括软件需求说明书、数据库设计说明书、概要设计说明书、详细设计说明书、可行性研究报告、项目开发计划。b管理文档这类文档是在软件开发过程中,由软件开发人员制定的需提交人员的一些工作计划或工作报告。使管理人员能够通过这些文档了解软件开发项目安排、进度、资源使用和成果等。包括项目开发计划、测试计划、测试报告、开发进度月报、项目周计划周总结及项目开发总结等。c用户文档这类文档是软件开发人员为用户准备的有关该软件使用、操作、维护的资料。包括用户手册、操作手册、维护修改建议、软件需求说明书。项目各阶段完毕后需把本阶段相关文档列表向总工办移交。52验证与评审

12、软件评审是保证软件产品质量的重要手段,必须纳入软件开发过程,并把评审通过作为一个软件阶段完成的标志,进而转入下一个开发阶段。软件评审包括有正式评审(即评审)、内部评审两种形式。正式评审是软件项目组上级技术主管主持的评审。内部评审以由项目负责人组织、开发人员相互检查为基本方式。就整个软件开发过程而言,至少要进行可行性分析、软件需求评审、设计评审、软件验证和确认评审、管理评审等五个方面的评审和检查工作。扩展阅读软件项目开发流程文档软件项目开发流程修改历史日期201*-03-12201*-5-18201*-12-4201*-1-14作者修改内容新制作人员职责的变更,内容的变更针对201*年度制作最新

13、工作内容下的工作流程添加项目经理管理被职员填写下周日程表的规则1文档1概述.3122目的.3内容概述.3开发部日常管理流程具体实施方案.3123基本原则.3内容概述.3内容详细描述.33开发部管理流程具体实施方案.10123456789内容概述.10开发部概要流程图.12开发部管理人员工作流.12bugsurvey工作流.15项目分析工作流.15beta后质量保证工作流.15测试组beta前工作流.15项目组基本工作流.15测试部版前流程.194绩效考核实施方案.2112总则.21流程图.215开发部激励和过失管理流程.2412激励管理系统.24过失管理系统.242文档1概述1目的用标准化的流

14、程来统一管理公司的运作,避免混乱,提高管理的质量。在远程开发上,结果软件自身的特点,量身定做,解决远程开发上的问题。在实施过程中,所有管理者能够根据此统一的流程,总结经验,提高认识,加强技术水平和管理水平。提高公司级的技术分析能力,为公司储备一支分析队伍,侧重在需求理解和需求分析、框架设计上的能力。保证在201*年能够全盘进行中方市场的顺利运作。对人员负责内容上,明确化各自负责的内容,提高工作效率。2内容概述开发部日常工作流程开发部管理流程开发部绩效考核流程开发部激励和过失管理流程2开发部日常管理流程具体实施方案1基本原则公司开发部力求建立公平公正的评价体系,严谨的工作流程定义和及时的记录与反

15、馈,规范职员活动,形成一个紧张有序的团队。没有一个明晰的流程和高效的反馈体系,就不可能把工作做好。但是,这需要每个人按照规则把自己应该负责的那一部分高效完成,只有这样才能保证整个系统的顺畅,同时,如果个人没有完成自己的指责和按照规定填写内容,影响的不单单是自己的工作而是整个系统。2内容概述esm使用规则目的注意是为了提高开发部整体的计划能力,反馈能力和管理者的控制能力。同时提高整体职员参与公司管理的渠道,适应东京上市公司对信息管理的要求。日常活动的方法提供开发部工作流程外的突发事件的解决方法3内容详细描述1esm使用规则(1)schedule的使用3文档加强全体人员的计划能力,做到我每天要做什

16、么?今天项目经理给我的安排是什么?对应项目经理和部长要知道每个人在做什么?只有这样,才能保证控制人员可以宏观调控,而个人也不会不知所措。注意事项必须使用长期类型(哪怕只有一天)保持统一性2开始时间必须为2200结束时间为2300,(为了区分其它人填写的日程安排)3填写日程安排时,必须选择对应的anken,否则不能于系统内的项目关联,统计软件失去作用。4日程安排的主题要修改,规则为项目号(中文版项目为北京内部项目编号),暂时没有编号可以写项目名称。内容下周工作安排负责人项目经理技术分析负责人测试组经理开发部全体人员开发部全体人员项目总控助理填写要求必须每周五1600前填写完毕。同时类型统一用长期

17、进行定义,为每一个人员安排下周工作计划。监督人填写监督项目总控助理内容监督部长和项目总控人员无违规处理没有按时提交的,管理者扣除md0.2日常活动安排待办事项制作下周工作安排表建议大家把工作安排填写,有利于提高自己的计划能力和规划能力。同时能保证事情不会忘记。建议填写,管理者应该必须使用。主要是把事务管理的井井有条。负责利用工具【导出下周工作表系统】制作开发部下周工作计划表。每周五下班前发送东京。无东京项目负责人4文档(2)report的使用作为上市公司的子公司要求公司正规化,第一步公司的日报系统的建立和审查,所以从本年度起必须建立此系统。同时,在管理上解决口头汇报,不客观而事后而无据可查的弊

18、端,为及时了解问题并解决问题,提供第一手的素材。同时项目总控助理,也要本着实事求是的原则,根据大家的填写内容向东京证券市场提交作业公务表,所有填写者一定要保证填写日报的消耗工时和最后工资结算时当日工时保持严格一致。内容项目选择对应esm的名称项目填写要求直接选择自己对应的项目,如果工作对象不是项目本身则需要选择以下项目:(顾客名称为201*年过程管理专用)公司会议公司培训公司管理其它注意:只有部长以上才填写以上项目(公司培训除外),部长以下全部选择对应项目。见附图1监督人违规处理扣除md0.15文档当日工作内容和进度工作内容与进度1填写当日的模块名称(模块名称参考2中的功能点表)3细度要求功能

19、点要求与工资计算工时想对应。(esm中数据库的数字和工时统计必须对应,此为东京证券的要求)把当天所遇到的问题按照条目化罗列。必须包含内容和状态两部分例如1内容bs详细页面存在老bug,状态已经解决2内容文档3出现问题,无法继续。状态等待解决填写监督内容监督项目经理数字核对没有填写1次人民币5元工作耗时工作耗时数字不对者,按照一次扣除0.1md不付责任的乱填或不填,一个日报扣除0.1md(如果在特殊情况下无问题,也要写无)职员如果不填写则按照输入值进行绩效考核。如果职员输入的md与分配时不符合项目经理扣除0.5md问题反馈问题反馈内容监督项目经理md输入订货(预定)金额必须在项目总结会议结束之后

20、,同时要经过项目经理的审核。输入值为实际值的10倍(因为数值型目前只能为整数)职员的输入由项目经理负责项目经理的核对由项目总控助理进行附图1(3)周报(weekreport)日报(dailyreport)的使用主要是使用对象为管理者,主要是适用于向管理者汇报整体问题。在概念上,日6文档报周报为概括说明,而report则属于细节描述。内容日报负责人项目经理部长部长填写要求项目进展状况不能解决的问题反馈建议或提议突发问题必须反馈项目进展整体状况不能解决的问题反馈建议或提议必须填写监督人项目总控人员违规处理如果由于没有汇报造成问题,按一次扣除0.5md周报不写,按一次扣除0.2md周报项目经理部长部

21、长项目总控项目总控助理(4)目标功能的使用由于分部内有单独的激励费用,所以建议分部内建立目别考核体系。为每一个程序员根据个人不同的能力和状况设定目标,对于圆满完成目标者进行鼓励。同时,保证公司的开发效果在可控制范围内。(5)项目信息管理的使用。本管理系统在201*年开始实行,主要目前是记录公司所有项目的里程碑信息。为以后项目的整理和后期处理提供真实的数据。同时,维护公司的项目信息数据库。注意事项其中关于项目中所设计的文档,统一放在fileserver上201*目录中。关于文档名称和路径的书写方法如下,保证能够尽快打开文档/fileserver/project/201*/14258/测试用例/1

22、4258_testcase.xls201*年1月1号起,东京新项目项目项目名称北京项目编号项目类型要求必填,同时应有对应的项目号必填不能为空,目前类型有researchnormalconfirmmerge对应负责人出错处理方法扣除md0.1扣除md0.1扣除md0.1备注添加时一定要注意唯一性,与目前的规则为小于5md的均为research项目7文档others必填项目名称扣除md0.1客户方负责人分析负责人项目负责人必填北京分析项目,为必填项目东京设计,为非必填必填项目部长(但是必须制定具体负责人)扣除md0.1扣除md0.1项目的名称应包含项目的id,关于项目id的生成方法,参考日方对应文

23、档部长扣除md0.1本公司负责人分析开始时间不能为空初始必填的人员为项目负责人项目总控人员及助理、对应部长、测试部经理,公司技术负责人(马俊)必填对应该项目的分析员扣除md0.1项目负责人应该是直接负责人(不是最先指定的部长)如果没有项目负责人,与联系扣除md0.1概要设计完成时间必填详细设计完成时间必填fp文档完成时间分析完毕时间项目接收时间项目最终对应md必填必填必填原则不为空,在特殊情况下为空,在项目备注重必须说明原因。不是必须,但是只要有变更有内容,此项目必须要有原则不为空,在特殊情况下为空,在项目备注重必须说明原因。必填对应该项目的分析员对应该项目的分析员对应该项目的分析员对应该项目

24、的分析员项目经理(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输出

25、以便查阅。beta版时间必填扣除md0.18文档知)项目经理(mail通知)项目经理(mail通知)项目经理项目经理alfa变更纪录项目开始时间最后一次记录变更的时间必须和对应的alfa版时间和beta版时间一致必填扣除md0.1扣除md0.1csv分支号功能点文档文件名及文件路径(fileserver服务器)单体测试用例文件名称及文件路径项目总结与md分配方案文档及文件路径测试负责人必填必填扣除md0.1扣除md0.1此分支号为开发分支号此文档为必须文档,各项目经理必须严格控制。此文档为必须文档,各项目经理必须严格控制此文档为必须文档,各项目经理必须严格控制。此文档为必须文档,各项目经理必须

26、严格控制。主要要参考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.12系统的使用(1)电子打卡系统的使用目的主要是利用电子打卡,提高效率,能够及时反

27、映请假和迟到,并且所有的数据能够直接被人事利用。要求9文档201*年2月开始启用,2月为试用期,但是要求每人必须严格填写,如果不填写并结合打卡,忘记填写扣除过程管理md0.1计算。(2)会议室、洽谈室、经理室的使用管理目的主要是在人数多而会议室相对紧张的状态下,解决矛盾的一种方法。同时审核各项目组是否及时安排公司规定的两次会议。201*年2月启动,没有按照规定进行会议,经审核后,扣除项目经理过程管理md0.2,忘记登录的按照统一标准处理。3公司内部论坛的使用主要是要有利于公司内部开辟一块公司可以自由发表言论的地方。同时,在技术讨论上,希望能够把知识点做一个累计,以便新员工能够进行参考和积极发表

28、意见。3开发部管理流程具体实施方案1内容概述开发部从流程上主要分为以下几方面(1)开发部管理人员工作流(2)bugsurvey工作流(3)项目分析工作流(4)beta后质量保证工作流(5)测试组beta前工作流(6)项目组运行基本工作流开发部从实施人员角色划分如下开发部经理(dm01)统筹解决公司开发部的全部事宜。进行开发部的整体计划的制定和实施,保证开发部的可持续发展和利润率。项目总控人员(dm02)对公司级的资源进行调配,同时,直接了解日方的战略安排,为北京方的战略安排提供的第一手的资料。同时,在项目分配上保证三个分部间项目的均衡(一个季度内)开发部部长(dm10)在公司统一的规则范围内,

29、负责分部的建设。协调各开发组的问题,处理解决分部内发生的问题。做好所有公司要求的标准流程内的内容。同时,在许可范围内,可以进行单独的管理方法的尝试和分部内激励的分配。10文档技术设计负责人(dm11)统一协调分析组的工作,在对日项目分析组中,进行设计文档的统一确认,在对中方项目中,承担需求的统一把关处理。同时负责分析组的日常工作安排的统筹。bugsurvey总负责人(dm12)统一管理package和已经提交项目的统筹管理。组织形式上,倾向于单独的组织模式。在目前的情况下,以灵活为主,临时性的进行bugsurvey组的组织和bugsurvey组内teamleader的指定和管理。在间隙阶段,直

30、接进入分析组进行项目分析工作。项目总控助理(dm13)辅助开发部的项目管理工作,主要负责中日双方的信息的反馈纪录整理,以及esm和taskschedule信息的维护工作。负责公司级项目文档,过程参数的监督,同时向日本总部汇报各种参数和报表。常务项目经理(dm20)目前11名各分部内程序员的日常管理,整个开发过程中的控制和日方负责人的信息交互,负责组内程序员的绩效考核和问题解决。测试部经理和翻译部经理包含在内。技术分析员(dm21)对日方的需求进行概要分析和设计,并书写设计书,fp。对中方的项目中,负责需求的整理和各种设计文档的实施,同时,负责和项目经理和测试部经理的沟通。临时项目经理(dm22

31、)此角色主要是在接受日方外包项目或整体公司产品设计中,需要临时成立项目组,而从分析组中或者常务项目经理中抽调。临时项目经理需要全权负责此项目的实施,同时需要和公司签订项目负责保证书,以保证项目的进行和最后单独项目激励的兑现。程序员主要是负责项目按照分析文档的实施,同时,在实施过程中优化代码结构,提出合理化建议,其中优秀者可以作为teamleader负责具体组织工作和分析管理工作。测试员负责公司测试流程的具体实施,要求掌握测试的技术,提出合理化建议,并保证整个软件的可靠度。翻译人员11文档负责中日方文档的翻译,要求工作严谨,保证质量。在同日方交流中,负责接待和沟通。同时,在个人的发展意向中可以兼

32、顾其它公司内的常务工作。2开发部概要流程图软脑软件开发部整体概要流程图出现bug,进行回归处理日方委托开发基本设计书(含db),fp表项目总控人员-部长-常务项目经理项目实施,提交alfa版本测试部进行软件测试,提交beta版本东京项目负责人项目总控助理进行项目信息管理日方委托研发实施东京方或顾客提出需求北京分析人员进行需求整理书写hearingsheet制作demo书写fp表书写基本设计书(含db),测试用例tokyo确认中方项目和顾客进行需求获取整理usecase图分析组实施数据库设计分析组实施项目整体计划demo和设计文档类似委托开发流程3开发部管理人员工作流1软件开发管理体系构成参与人

33、员项目总控人员(项目总控助理)+部长+(技术设计负责人+bugsurvey负责人)+各级项目经理管理主线(1)工具类taskschedule表主要目的是增加远程开发的计划和规划性。管理人员去合适目前我们正在进行的总量有多少,检收而为付款的有多少,实施完毕而没有检收的有多少。12文档管理人员去看我们下周能够接受的项目有多少,以便在每周五可以制定下周的工作计划。项目经理可以看自己负责项目的基本参数。esm系统通过esm系统详细的记录开发过程中的每个里程碑参数,保证在管理上能够提高管理细度,以便于及时发现并改正问题和错误。bug管理系统作为质量控制过程实际结果的监控。以便总结质量的问题,进行反馈。f

34、ileserver文档通过文档管理和整理,保证全部职员能够随时的了解其他项目的信息和相信内容。同时,统一化文档管理,为以后的发展提供素材。所有的文档主要包含如下几种hearingsheet一个简要的需求,重点在于强调这个需求的原因(前因后果)ui文件设计文档东京和北京共同进行fp报价书questionsheet所有的问题一定要集中在一个文档内功能点文档一定要融合questionsheet内对应答案的所有内容schedule文档要包含甘特图项目总结及md分配方案把项目总结作为重点进行。单体测试用例;条数最少为md*2,按照模板进行测试组测试用例:要保证最后的测试结果确认测试用例一般为东京发送be

35、ta版后障害书项目确认者发送,按照同一格式进行书写和填写。beta后障害list表,其中包含bug的简单描述、bug的类型确定和各部门关于bug的总结。(2)过程管理类一个项目两次会议项目启动会议和项目总结会议项目启动会议主要是讲述项目的功能点,并据具体问题,进行严格的定义,说明本项目所必须遵守的特殊规则,子功能间的前后顺序,统一的接口定义,和每个人在项目实施中应该注意的问题。项目总结会议和md分配方案的确定。主要是根据项目实施的结果,进行集中的讨论和谐而公平的团队公司其他方面的管理,就是为了加强管理,提倡量化。做到各司其职,多劳多得,公平评价,提供机会给相应的人。13文档2管理示意图东京客户

36、需求东京项目总控人员1,开发内容的规则及md确认方案2年度发展计划3月度项目工作量规划4突发事件的处理北京北京项目总控人员基本设计书hearingsheet详细设计书设计文档审核确认项目控制专员1taskschedule2下周工作安排项目控制专员(付歆玮)实现分支管理与统筹安排1功能点描述文档merge1。specquestionsheet常规信息传递项目质量检测东京担当者北京担当者测试3管理人员注意事项其中反馈机制的建立最关键。其中管理必须遵守以下规则对象项目总控人员流程工作内容编号分配项目解决人力矛盾上流方东京项目发包人员(纪秀玲)部长bugsurvey负责人技术设计负责人部长项目经理各级

37、负责人职员项目总控人员下流方部长项目总控助理部长bugsurvey负责人技术设计负责人全体职员备注下流方人员负责把结果反馈给东京担当者开发部经理公司管理问题一定要给问题提出者答复,成为制度后颁布部长分配项目对应分部项目esm项目负责人加入,修14文档项目总控助理项目经理项目人力调节分部管理问题项目分析和问题确认项目里程碑信息反馈项目开始时间,alfa,beta版本时间和原因,fp变更及原因组织团队进行技术文档的书写和维护无无无无经理项目总控助理项目总控人员开发部经理东京负责人项目总控人员项目总控助理测试部经理改负责人为此项目经理如果出现空闲同时反馈。结果物概要需求文档和问题与回复整理文档无bu

38、gsurvey负责人bugsurvey的调查修改merge项目总控人员项目总控助理监督esm的执行情况测试部经理监督过程管理参数整理所有项目文档对日汇报表绩效考核提供过程情况汇总组织书写测试用例整理汇总beta版后bug分析表控制测试的结果程序员项目经理部长部长项目经理项目经理系统数据系统数据项目经理(功能点文档)项目经理(提供的完整的后障害书)测试部经理文档列表如下team所有成员功能点文档questionsheetschedule单体测试用例各级的bug所有的规则按照surveyleaderbugsurve流程的规定。bugsurvey实施人员项目总控项目总控项目总控项目总控项目总控东京所

39、有管理者月度过程管理处理表其中的技术分析和管理分析及对东京的建议应由项目负责人进行填写4bugsurvey工作流参见bugsurvey工作规约。5项目分析工作流参见项目分析工作规约6beta后质量保证工作流参见beta后规作规约7测试组beta前工作流8项目组基本工作流1概述在项目进行过程中,要求能够及时反馈。做好计划安排,并调整这个人力的配比,以达到最好的效果。15文档2对程序员的要求尤其在分析组成立前期,对分析组的设计书,尽可能提出建设性意见和设计的问题,有利于提高项目分析能力在功能实现上,主要和项目经理的沟通,把类结构设计和代码向理想情况努力,同时用公司内的代码规范作为自己的行动准则在日

40、常活动中,加强团体意识,加强责任感。3对项目经理的要求主要职责为类设计的严格控制。保证整个软件包的可维护性项目过程管理。能够紧密的控制整个项目的进程,发现项目中的各种风险因素,尽早地把风险在项目中消除。硬性要求如下(1)每个项目(大于10md正常项目)必须提供的文档为功能点文档,questionsheet,单体测试用例,项目总结及md最终分配方案文档(2)每个项目(大于10md正常项目)必须召开两次会议项目启动会议主要为了统一项目的内容规则和要求,同时把整体逻辑和框架做简要说明。项目总结会议主要是评价每个成员的表现和项目完整的状况和质量,总结失败的经验教训。同时根据评论的结果进行最后的md的分

41、配。(3)在esm必须登陆必要的过程参数,以便团队成员和公司的管理者能够及时的把我目前项目状态。整个团队的建设和公司的管理工作。在项目管理中发现问题,把反映给公司。以备在公司级别对整个流程和各个环节进行调整。4流程图16文档接收到来自项目总控人员的项目通知关注项目的分析进程并作初步计划1功能点文档2uestionsheetesm系统登录功能点文档名称及服务路径questionsheet文档名称及路径mail通知测试部经理,项目总控助理接收到来自分析组概要设计第一版的通知对概要设计做初步的审核工作确定alfa/beta版本邮件通知项目总控助理、测试组负责人必须同时包含项目开始时间,alfa时间,

42、版时间esm中登录项目开始时间esm登录alfa/beta版时间接收到来自分析组详细设计第一版的通知或者东京发注结合项目组的情况进行计划调整制作项目安排文档(visio或者project)esm系统登录项目安排文档名称及路径项目启动会议,功能点及md概要分配项目的类结构设计(项目经理或程序员进行)项目经理审批编码要遵守编码规则和类结构方案,注意讨论,切记盲目编码项目中出现新的问题mail反馈给文档作者,并通知部长以上人员,按照反馈机制进行项目组内代码检查提交项目经理esm输入代码检查开始日期和代码检查完成日期bug管理系统中加入代码检查的结果书写单元测试用例制作单元测试文档(参考单元测试模板)

43、esm输入单元测试用例文档的名称和对应地址单员测试提交项目经理项目经理邮件通知测试部经理,项目总控助理把单元测试的结果反映到单元测试用例文档中邮件通知项目总控助理和测试部经理发送测试组dbscript和resource修改文件提交alfa版本项目总结会议,功能点及md概要分配制作项目总结文档,以及md分配方案esm系统登录项目总结文档的名称及路径17文档5项目组文档管理原则所有文档必须都放在fileserver上,进行统一管理。同时,负责人在本地应保留一份同样的备份。201*年开始接收到的项目必须放在201*中,针对每个项目必须按照下图进行文档管理。细节描述项目spec内容设计说明书quest

44、ionsheet设计说明书的补充说明设计说明书的各个版本设计说明书一览表项目组书写的单体测试用例测试组书写的测试用例东京发送的confirm测试用例针对项目实施的日程安排对东京进行进度汇报的每个报表功能点文档备注设计说明书一览表要记录所有文档变更的情况,并指明最后项目实施与文档之间的关系testcaseschedulefunctionpointsallbugspecbeta后障害书针对此项目的beta后bug类型确定和经验汇总。完毕后,应及时发送测试组项目经理。uihtmldemohearing联系分析组,如果有应该直接copysheetfpspecfpsheet不同版本fpchange表fp

45、说明,记录所有fp变更历史,以备后期确认的方便。项目spec的中文版需要打印,此工作由项目总控助理执行。同时,对文档18文档进行归档和密封。9测试部版前流程1相关人员测试部经理测试组成员2测试人员的要求一定要注意配合。因为,在此环节,一种好的描述方式和沟通方式将会直接影响工作效率和工作质量。所以,首先大家要注意bug管理系统的使用方法和规则,同时,尽量采用统一的属于进行描述,如果需要图形辅助,也可以进行贴图。加强需求理解能力。能够尽快的理解文档和功能测试用例。在工作中细致、耐心、有条理。同时对应esm系统需要测试部填写的过程参数必须严格按照规定填写。3工作流程图19文档接收到功能点文档书写测试

46、用例esm登录测试组测试用例文件名称及路径接收到项目经理的alfa/beta版通知并参考esm上的项目信息项目测试安排esm登录测试负责人核查以下条件1是否已经发送测试组dbscript和resource改动,并验证正确性2单体测试用例是否全部填入单体测试结果接到项目组提交的afla版通知后按照功能测试用例,开始测试条件不具备,不能进行测试,同时发通知给对应负责人确认连接在测试数据库上确认已经执行dbscritpt和resource修改esm登录第一阶段测试开始时间第一阶段测试测试依据测试组所整理的测试用例bug管理系统登录alfa测试bug第一阶段测试结束mail通知项目负责人,同时确认bu

47、g管理系统中alfabug的类型和个数esm系统中登录第一阶段完成时间esm中登录alfa版本后的bug数回归测试测试完毕,esm登录回归测试结束时间提交beta版dbscript和resource修改放在fileserver对应项目目录下ftp上传dbscript和resource修改到东京服务器向日方中山幸子、初宏伟、项目负责人,正式发布beta通知接收到beta后bug启动beta版后流程规约4注意事项bug管理系统中的状态一定要维护,并通过此系统来保证alfabug修改的进行情况,即在提交beta版前,所有的alfabug的状态都应该在do上。如果没有在此状态中,应该积极和项目组联系,

48、测试组有权监督其完成。测试组要验证项目组提交的script和resoruce文件,如果有问题,测试组20文档有权通知项目立即修改,同时可以作为alfabug登录在bug管理系统中。测试组要保证测试用例的质量,尽一切可能减少beta后bug的数量。并严格的按照beta后bug处理规约进行。4绩效考核实施方案1总则所有职员的所有工作都应该以量化计算,如果不能,则当事者可以提出异议,而对绩效考核方法进行改进。例如所有北京项目必须有md,翻译组翻译工作量可以通过翻译的字数进行调整,测试组同样对工作内容进行分类核算md。量化管理主要包含几个主题方向工作时间是人事部门公布的每个月的工时统计的结果。实际上,它代表了自己的实际消耗时间。东京md是实际为公司所创造的价值。北京md主要包含正规作的北京内部项目或者实际工作而作的的补充md。已达到考核的公平合理。质量扣除md:是指由于代码的bug而造成的损失,因为实际的贡献是要扣除损失的。对于测试部就是东京对北京确认产生的beta后故障的扣除。过程管理扣除md除了实际的工作量,就是为个建立一个稳固高效的团队而每个人应该承担的过程管理义务,如果没有做好,实际上不仅仅是你自己绩效不高,而是你影响了整个团队的利益。而这部分的值反映了你对团队的影响。过程管理奖励md在项目实施过程中,个人在突发事件上的处理或者对项目整体乃至

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论