软件项目开发工作流程.docx

上传人:wj151****6093 文档编号:25561016 上传时间:2022-07-12 格式:DOCX 页数:42 大小:53.39KB
返回 下载 相关 举报
软件项目开发工作流程.docx_第1页
第1页 / 共42页
软件项目开发工作流程.docx_第2页
第2页 / 共42页
点击查看更多>>
资源描述

《软件项目开发工作流程.docx》由会员分享,可在线阅读,更多相关《软件项目开发工作流程.docx(42页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、软件项目开发工作流程 软件项目开发工作流程软件项目开发工作流程一、简述对于一个新项目,从可行性探讨到产品交货整个生存阶段将经验如下十大流程: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编码实现阶段依据软件具体设计说明、对各程序模块进行编码、调试、静态分析和单元测试,验证程序单元与设计说明的一样性。本阶段涉及的文档:项目进度月报项目周安排和周总结项目开发人员周安排工作日

8、志每周例会记录配项更改申请单36测试阶段361软件单元测试按具体设计的结构,依据软件单元测试安排,依照将经过单元测试的底层程序单元逐步组装成子项目直到开发项目的过程,对软件进行测试。本阶段涉及的文档:测试安排测试设计测试问题报告单参考文档:北京世纪科怡软件开发操作指导书中的“测试阶段操作指导书”362组装测试依据软件需求规格说明书中定义的全部功能和性能要求及组装测试安排,对软件进行组装测试,以确定整个软件是否满意软件需求,是否可以提交总装测试。软件组装测试安排(含测试用例设计)的编制工作和软件组装测试环境的研制、组建工作,应从软件需求分析阶段起与软件开发同步绽开。本阶段涉及的文档:测试安排测试

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

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

11、为三类:a开发文档:这类文档是在软件开发过程中,作为软件开发人员前一阶段工作成果的体现和后一阶段工作依据的文档。包括软件需求说明书、数据库设计说明书、概要设计说明书、具体设计说明书、可行性探讨报告、项目开发安排。b管理文档:这类文档是在软件开发过程中,由软件开发人员制定的需提交人员的一些工作安排或工作报告。使管理人员能够通过这些文档了解软件开发项目支配、进度、资源运用和成果等。包括项目开发安排、测试安排、测试报告、开发进度月报、项目周安排周总结及项目开发总结等。c用户文档:这类文档是软件开发人员为用户打算的有关该软件运用、操作、维护的资料。包括用户手册、操作手册、维护修改建议、软件需求说明书。

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

13、作者修改内容新制作人员职责的变更,内容的变更针对201*年度制作最新工作内容下的工作流程添加项目经理管理被职员填写下周日程表的规则1文档1概述.31.11.22目的.3内容概述.3开发部日常管理流程详细实施方案.32.12.22.3基本原则.3内容概述.3内容具体描述.33开发部管理流程详细实施方案.103.13.23.33.43.53.63.73.83.9内容概述.10开发部概要流程图.12开发部管理人员工作流.12BUGSURVEY工作流.15项目分析工作流.15BETA后质量保证工作流.15测试组BETA前工作流.15项目组基本工作流.15测试部版前流程.194绩效考核实施方案.214.

14、14.2总则:.21流程图.215开发部激励和过失管理流程.245.15.2激励管理系统.24过失管理系统.242文档1概述1.1目的用标准化的流程来统一管理公司的运作,避开混乱,提高管理的质量。在远程开发上,结果软件自身的特点,量身定做,解决远程开发上的问题。在实施过程中,全部管理者能够依据此统一的流程,总结阅历,提高相识,加强技术水平和管理水平。提高公司级的技术分析实力,为公司储备一支分析队伍,侧重在需求理解和需求分析、框架设计上的实力。保证在201*年能够全盘进行中方市场的顺当运作。对人员负责内容上,明确化各自负责的内容,提高工作效率。1.2内容概述开发部日常工作流程开发部管理流程开发部

15、绩效考核流程开发部激励和过失管理流程2开发部日常管理流程详细实施方案2.1基本原则公司开发部力求建立公允公正的评价体系,严谨的工作流程定义和刚好的记录与反馈,规范职员活动,形成一个惊慌有序的团队。没有一个明晰的流程和高效的反馈体系,就不行能把工作做好。但是,这须要每个人根据规则把自己应当负责的那一部分高效完成,只有这样才能保证整个系统的顺畅,同时,假如个人没有完成自己的指责和根据规定填写内容,影响的不单单是自己的工作而是整个系统。2.2内容概述Esm运用规则目的留意是为了提高开发部整体的安排实力,反馈实力和管理者的限制实力。同时提高整体职员参加公司管理的渠道,适应东京上市公司对信息管理的要求。

16、日常活动的方法供应开发部工作流程外的突发事务的解决方法2.3内容具体描述2.3.1Esm运用规则(1)schedule的运用3文档加强全体人员的安排实力,做到我每天要做什么?今日项目经理给我的支配是什么?对应项目经理和部长要知道每个人在做什么?只有这样,才能保证限制人员可以宏观调控,而个人也不会不知所措。留意事项:1.必需运用长期类型(哪怕只有一天)保持统一性2起先时间必需为22:00结束时间为23:00,(为了区分其它人填写的日程支配)3填写日程支配时,必需选择对应的anken,否则不能于系统内的项目关联,统计软件失去作用。4日程支配的主题要修改,规则为项目号(中文版项目为北京内部项目编号)

17、,短暂没有编号可以写项目名称。内容下周工作支配负责人项目经理技术分析负责人测试组经理开发部全体人员开发部全体人员项目总控助理填写要求必需每周五16:00前填写完毕。同时类型统一用长期进行定义,为每一个人员支配下周工作安排。监督人填写监督:项目总控助理内容监督:部长和项目总控人员无违规处理没有按时提交的,管理者扣除MD0.2日常活动支配待办事项制作下周工作支配表建议大家把工作支配填写,有利于提高自己的安排实力和规划实力。同时能保证事情不会遗忘。建议填写,管理者应当必需运用。主要是把事务管理的井井有条。负责利用工具制作开发部下周工作安排表。每周五下班前发送东京。无东京项目负责人4文档(2)Repo

18、rt的运用作为上市公司的子公司要求公司正规化,第一步公司的日报系统的建立和审查,所以从本年度起必需建立此系统。同时,在管理上解决口头汇报,不客观而事后而无据可查的弊端,为刚好了解问题并解决问题,供应第一手的素材。同时项目总控助理,也要本着实事求是的原则,依据大家的填写内容向东京证券市场提交作业公务表,全部填写者肯定要保证填写日报的消耗工时和最终工资结算时当日工时保持严格一样。内容项目选择对应esm的名称项目填写要求干脆选择自己对应的项目,假如工作对象不是项目本身则须要选择以下项目:(顾客名称为201*年过程管理专用)公司会议公司培训公司管理其它留意:只有部长以上才填写以上项目(公司培训除外),

19、部长以下全部选择对应项目。见附图1监督人违规处理扣除MD0.15文档当日工作内容和进度工作内容与进度1填写当日的模块名称(模块名称参考2中的功能点表)3细度要求功能点要求与工资计算工时想对应。(esm中数据库的数字和工时统计必需对应,此为东京证券的要求)把当天所遇到的问题根据条目化排列。必需包含内容和状态两部分例如:1内容:BS具体页面存在老bug,状态:已经解决2内容:文档2.3出现问题,无法接着。状态:等待解决填写监督:内容监督:项目经理数字核对:没有填写1次人民币5元工作耗时工作耗时数字不对者,根据一次扣除0.1MD不付责任的乱填或不填,一个日报扣除0.1MD(假如在特别状况下无问题,也

20、要写无)职员假如不填写则根据输入值进行绩效考核。假如职员输入的MD与安排时不符合项目经理扣除0.5MD问题反馈问题反馈内容监督:项目经理MD输入订货(预定)金额必需在项目总结会议结束之后,同时要经过项目经理的审核。输入值为实际值的10倍(因为数值型目前只能为整数)职员的输入由项目经理负责项目经理的核对由项目总控助理进行附图1:(3)周报(WeekReport)日报(DailyReport)的运用主要是运用对象为管理者,主要是适用于向管理者汇报整体问题。在概念上,日6文档报周报为概括说明,而report则属于细微环节描述。内容日报负责人项目经理部长部长填写要求项目进展状况:不能解决的问题反馈建议

21、或提议突发问题必需反馈项目进展整体状况:不能解决的问题反馈建议或提议必需填写监督人项目总控人员违规处理假如由于没有汇报造成问题,按一次扣除0.5MD周报不写,按一次扣除0.2MD周报项目经理部长部长项目总控项目总控助理(4)目标功能的运用由于分部内有单独的激励费用,所以建议分部内建立目别考核体系。为每一个程序员依据个人不同的实力和状况设定目标,对于圆满完成目标者进行激励。同时,保证公司的开发效果在可限制范围内。(5)项目信息管理的运用。本管理系统在201*年起先实行,主要目前是记录公司全部项目的里程碑信息。为以后项目的整理和后期处理供应真实的数据。同时,维护公司的项目信息数据库。留意事项:其中

22、关于项目中所设计的文档,统一放在fileserver上201*书目中。关于文档名称和路径的书写方法如下,保证能够尽快打开文档:/fileserver/project/201*/14258/测试用例/14258_testcase.xls201*年1月1号起,东京新项目项目项目名称北京项目编号项目类型要求必填,同时应有对应的项目号必填不能为空,目前类型有ResearchNormalConfirmMerge对应负责人出错处理方法扣除MD0.1扣除MD0.1扣除MD0.1备注添加时肯定要留意唯一性,与目前的规则为小于5md的均为RESEARCH项目7文档Others必填项目名称扣除MD0.1客户方负责

23、人分析负责人项目负责人必填北京分析项目,为必填项目东京设计,为非必填必填项目部长(但是必需制定详细负责人)扣除MD0.1扣除MD0.1项目的名称应包含项目的ID,关于项目ID的生成方法,参考日方对应文档部长扣除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版时间假如供应必填必填项目

25、经理(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安排方案文档及文件路径测试负责人必填必填扣除

26、MD0.1扣除MD0.1此分支号为开发分支号此文档为必需文档,各项目经理必需严格限制。此文档为必需文档,各项目经理必需严格限制此文档为必需文档,各项目经理必需严格限制。此文档为必需文档,各项目经理必需严格限制。主要要参考beta后bug的整理表必填项目经理扣除MD0.1必填项目经理扣除MD0.1测试用例对应文件名称及路径必填必填扣除MD0.1扣除MD0.1第一阶段测试开必填始时间:第一阶段测试完必填成日期:Alfa版本后的必填BUG:回来测试的起先必填日期:回来测试的结束必填日期:Beta版后的BUG必填数:确认负责人不是必需,主要是与是否进行确认有关,假如确认其他有信息,确认负责人必填测试人

27、员测试人员测试人员测试人员测试人员扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.12.3.2系统的运用(1)电子打卡系统的运用目的:主要是利用电子打卡,提高效率,能够刚好反映请假和迟到,并且全部的数据能够干脆被人事利用。要求:9文档201*年2月起先启用,2月为试用期,但是要求每人必需严格填写,假如不填写并结合打卡,遗忘填写扣除过程管理MD0.1计算。(2)会议室、洽谈室、经理室的运用管理目的:主要是在人数多而会议室相对惊慌的状态下,解决冲突的一种方法。同时审核各项目组是否刚好支配公司规定的两次会议。201*年2月启动,没有根据规定进行会议,经

28、审核后,扣除项目经理过程管理MD0.2,遗忘登录的根据统一标准处理。2.3.3公司内部论坛的运用主要是要有利于公司内部开拓一块公司可以自由发表言论的地方。同时,在技术探讨上,希望能够把学问点做一个累计,以便新员工能够进行参考和主动发表看法。3开发部管理流程详细实施方案3.1内容概述开发部从流程上主要分为以下几方面:(1)开发部管理人员工作流(2)BUGSurvey工作流(3)项目分析工作流(4)Beta后质量保证工作流(5)测试组beta前工作流(6)项目组运行基本工作流开发部从实施人员角色划分如下:开发部经理:(DM01)统筹解决公司开发部的全部事宜。进行开发部的整体安排的制定和实施,保证开

29、发部的可持续发展和利润率。项目总控人员:(DM02)对公司级的资源进行调配,同时,干脆了解日方的战略支配,为北京方的战略支配供应的第一手的资料。同时,在项目安排上保证三个分部间项目的均衡(一个季度内)开发部部长:(DM10)在公司统一的规则范围内,负责分部的建设。协调各开发组的问题,处理解决分部内发生的问题。做好全部公司要求的标准流程内的内容。同时,在许可范围内,可以进行单独的管理方法的尝试和分部内激励的安排。10文档技术设计负责人:(DM11)统一协调分析组的工作,在对日项目分析组中,进行设计文档的统一确认,在对中方项目中,担当需求的统一把关处理。同时负责分析组的日常工作支配的统筹。BUGS

30、urvey总负责人(DM12):统一管理package和已经提交项目的统筹管理。组织形式上,倾向于单独的组织模式。在目前的状况下,以敏捷为主,临时性的进行bugSurvey组的组织和bugSurvey组内teamleader的指定和管理。在间隙阶段,干脆进入分析组进行项目分析工作。项目总控助理:(DM13)协助开发部的项目管理工作,主要负责中日双方的信息的反馈纪录整理,以及esm和taskschedule信息的维护工作。负责公司级项目文档,过程参数的监督,同时向日本总部汇报各种参数和报表。常务项目经理:(DM20)目前11名各分部内程序员的日常管理,整个开发过程中的限制和日方负责人的信息交互,

31、负责组内程序员的绩效考核和问题解决。测试部经理和翻译部经理包含在内。技术分析员:(DM21)对日方的需求进行概要分析和设计,并书写设计书,FP。对中方的项目中,负责需求的整理和各种设计文档的实施,同时,负责和项目经理和测试部经理的沟通。临时项目经理:(DM22)此角色主要是在接受日方外包项目或整体公司产品设计中,须要临时成立项目组,而从分析组中或者常务项目经理中抽调。临时项目经理须要全权负责此项目的实施,同时须要和公司签订项目负责保证书,以保证项目的进行和最终单独项目激励的兑现。程序员:主要是负责项目根据分析文档的实施,同时,在实施过程中优化代码结构,提出合理化建议,其中优秀者可以作为Team

32、Leader负责详细组织工作和分析管理工作。测试员:负责公司测试流程的详细实施,要求驾驭测试的技术,提出合理化建议,并保证整个软件的牢靠度。翻译人员:11文档负责中日方文档的翻译,要求工作严谨,保证质量。在同日方沟通中,负责接待和沟通。同时,在个人的发展意向中可以兼顾其它公司内的常务工作。3.2开发部概要流程图软脑软件开发部整体概要流程图出现bug,进行回来处理日方托付开发基本设计书(含DB),Fp表项目总控人员-部长-常务项目经理项目实施,提交alfa版本测试部进行软件测试,提交beta版本东京项目负责人项目总控助理进行项目信息管理日方托付研发实施东京方或顾客提出需求北京分析人员进行需求整理

33、书写hearingsheet制作demo书写FP表书写基本设计书(含DB),测试用例Tokyo确认中方项目和顾客进行需求获得整理UseCase图分析组实施数据库设计分析组实施项目整体安排demo和设计文档类似托付开发流程3.3开发部管理人员工作流3.3.1软件开发管理体系构成参加人员:项目总控人员(项目总控助理)+部长+(技术设计负责人+BugSurvey负责人)+各级项目经理管理主线:(1)工具类taskschedule表:主要目的是增加远程开发的安排和规划性。管理人员去合适目前我们正在进行的总量有多少,检收而为付款的有多少,实施完毕而没有检收的有多少。12文档管理人员去看我们下周能够接受的

34、项目有多少,以便在每周五可以制定下周的工作安排。项目经理可以看自己负责项目的基本参数。Esm系统:通过esm系统具体的记录开发过程中的每个里程碑参数,保证在管理上能够提高管理细度,以便于刚好发觉并改正问题和错误。Bug管理系统:作为质量限制过程实际结果的监控。以便总结质量的问题,进行反馈。Fileserver文档:通过文档管理和整理,保证全部职员能够随时的了解其他项目的信息和信任内容。同时,统一化文档管理,为以后的发展供应素材。全部的文档主要包含如下几种:HearingSheet:一个简要的需求,重点在于强调这个需求的缘由(前因后果)UI文件设计文档:东京和北京共同进行FP报价书Questio

35、nSheet:全部的问题肯定要集中在一个文档内功能点文档:肯定要融合questionSheet内对应答案的全部内容schedule文档:要包含甘特图项目总结及MD安排方案:把项目总结作为重点进行。单体测试用例;条数最少为MD*2,根据模板进行测试组测试用例:要保证最终的测试结果确认测试用例:一般为东京发送beta版后障害书:项目确认者发送,根据同一格式进行书写和填写。beta后障害list表,其中包含bug的简洁描述、bug的类型确定和各部门关于bug的总结。(2)过程管理类一个项目两次会议:项目启动会议和项目总结会议项目启动会议主要是讲解并描述项目的功能点,并据详细问题,进行严格的定义,说明

36、本项目所必需遵守的特别规则,子功能间的前后依次,统一的接口定义,和每个人在项目实施中应当留意的问题。项目总结会议和MD安排方案的确定。主要是依据项目实施的结果,进行集中的探讨和谐而公允的团队:公司其他方面的管理,就是为了加强管理,提倡量化。做到各司其职,多劳多得,公允评价,供应机会给相应的人。13文档3.3.2管理示意图东京客户需求东京项目总控人员1,开发内容的规则及MD确认方案2年度发展安排3月度项目工作量规划4突发事务的处理北京北京项目总控人员基本设计书HearingSheet具体设计书设计文档审核确认项目限制专员1taskSchedule2下周工作支配项目限制专员(付歆玮)实现分支管理与

37、统筹支配1功能点描述文档Merge1。SpecQuestionSheet2.常规信息传递项目质量检测东京担当者北京担当者测试3.3.3管理人员留意事项其中反馈机制的建立最关键。其中管理必需遵守以下规则:对象项目总控人员流程工作内容编号安排项目解决人力冲突上流方东京项目发包人员(纪秀玲)部长BugSurvey负责人技术设计负责人部长项目经理各级负责人职员项目总控人员下流方部长项目总控助理部长BugSurvey负责人技术设计负责人全体职员备注下流方人员负责把结果反馈给东京担当者开发部经理公司管理问题肯定要给问题提出者答复,成为制度后颁布部长安排项目对应分部项目Esm项目负责人加入,修14文档项目总

38、控助理项目经理项目人力调整分部管理问题项目分析和问题确认项目里程碑信息反馈项目起先时间,alfa,beta版本时间和缘由,fp变更及缘由组织团队进行技术文档的书写和维护无无无无经理项目总控助理项目总控人员开发部经理东京负责人项目总控人员项目总控助理测试部经理改负责人为此项目经理假如出现空闲同时反馈。结果物概要需求文档和问题与回复整理文档无BugSurvey负责人Bugsurvey的调查修改merge项目总控人员项目总控助理监督esm的执行状况测试部经理监督过程管理参数整理全部项目文档对日汇报表绩效考核供应过程状况汇总组织书写测试用例整理汇总beta版后bug分析表限制测试的结果程序员项目经理部

39、长部长项目经理项目经理系统数据系统数据项目经理(功能点文档)项目经理(供应的完整的后障害书)测试部经理文档列表如下:team全部成员功能点文档questionSheetSchedule单体测试用例各级的bug全部的规则根据surveyleaderbugsurve流程的规定。Bugsurvey实施人员项目总控项目总控项目总控项目总控项目总控东京全部管理者月度过程管理处理表其中的技术分析和管理分析及对东京的建议应由项目负责人进行填写3.4Bugsurvey工作流参见bugSurvey工作规约。3.5项目分析工作流参见项目分析工作规约3.6Beta后质量保证工作流参见beta后规作规约3.7测试组b

40、eta前工作流3.8项目组基本工作流3.8.1概述在项目进行过程中,要求能够刚好反馈。做好安排支配,并调整这个人力的配比,以达到最好的效果。15文档3.8.2对程序员的要求尤其在分析组成立前期,对分析组的设计书,尽可能提出建设性看法和设计的问题,有利于提高项目分析实力在功能实现上,主要和项目经理的沟通,把类结构设计和代码向志向状况努力,同时用公司内的代码规范作为自己的行动准则在日常活动中,加强团体意识,加强责任感。3.8.3对项目经理的要求主要职责为:类设计的严格限制。保证整个软件包的可维护性项目过程管理。能够紧密的限制整个项目的进程,发觉项目中的各种风险因素,尽早地把风险在项目中消退。硬性要

41、求如下:(1)每个项目(大于10MD正常项目)必需供应的文档为功能点文档,questionSheet,单体测试用例,项目总结及MD最终安排方案文档(2)每个项目(大于10MD正常项目)必需召开两次会议:项目启动会议主要为了统一项目的内容规则和要求,同时把整体逻辑和框架做简要说明。项目总结会议:主要是评价每个成员的表现和项目完整的状况和质量,总结失败的阅历教训。同时依据评论的结果进行最终的MD的安排。(3)在esm必需登陆必要的过程参数,以便团队成员和公司的管理者能够刚好的把我目前项目状态。整个团队的建设和公司的管理工作。在项目管理中发觉问题,把反映给公司。以备在公司级别对整个流程和各个环节进行

42、调整。3.8.4流程图16文档接收到来自项目总控人员的项目通知关注项目的分析进程并作初步安排1功能点文档2uestionSheetEsm系统登录功能点文档名称及服务路径QuestionSheet文档名称及路径Mail通知测试部经理,项目总控助理接收到来自分析组概要设计第一版的通知对概要设计做初步的审核工作确定Alfa/Beta版本邮件通知项目总控助理、测试组负责人必需同时包含:项目起先时间,alfa时间,版时间esm中登录项目起先时间esm登录Alfa/Beta版时间接收到来自分析组具体设计第一版的通知或者东京发注结合项目组的状况进行安排调整制作项目支配文档(visio或者project)Es

43、m系统登录项目支配文档名称及路径项目启动会议,功能点及MD概要安排项目的类结构设计(项目经理或程序员进行)项目经理审批编码要遵守编码规则和类结构方案,留意探讨,切记盲目编码项目中出现新的问题Mail反馈给文档作者,并通知部长以上人员,根据反馈机制进行项目组内代码检查提交项目经理esm输入代码检查起先日期和代码检查完成日期BUG管理系统中加入代码检查的结果书写单元测试用例制作单元测试文档(参考单元测试模板)esm输入单元测试用例文档的名称和对应地址单员测试提交项目经理项目经理邮件通知测试部经理,项目总控助理把单元测试的结果反映到单元测试用例文档中邮件通知项目总控助理和测试部经理发送测试组DBscript和resource修改文件提交alfa版本项目总结会议,功能点及MD概要安排制作项目总结文档,以及MD安排方案Esm系统登录项目总结文档的名称及路径17文档3.8.5项目组文档管理原则:全部文档必需

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 应用文书 > 工作报告

本站为文档C TO C交易模式,本站只提供存储空间、用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。本站仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知淘文阁网,我们立即给予删除!客服QQ:136780468 微信:18945177775 电话:18904686070

工信部备案号:黑ICP备15003705号© 2020-2023 www.taowenge.com 淘文阁