软件项目开发流程书.docx
- 文档编号:14086971
- 上传时间:2023-06-20
- 格式:DOCX
- 页数:16
- 大小:85.67KB
软件项目开发流程书.docx
《软件项目开发流程书.docx》由会员分享,可在线阅读,更多相关《软件项目开发流程书.docx(16页珍藏版)》请在冰点文库上搜索。
软件项目开发流程书
××软件工程开发流程
修改历史
日期
作者
修改容
2003-03-12
新規制作
2003-5-18
人员职责的变更,容的变更
2003-12-4
针对2004年度制作最新工作容下的工作流程
2004-1-14
添加工程经理管理被职员填写下周日程表的规那么
1概述
1.1目的
●用标准化的流程来统一管理公司的运作,防止混乱,提高管理的质量。
●在实施过程中,所有管理者能够根据此统一的流程,总结经历,提高认识,加强技术水平和管理水平。
●提高公司级的技术分析能力,为公司储藏一支分析队伍,侧重在需求理解和需求分析、框架设计上的能力。
●对人员负责容上,明确化各自负责的容,提高工作效率。
1.2容概述
●开发部日常工作流程
●开发部管理流程
●开发部绩效考核流程
●开发部鼓励和过失管理流程
2开发部日常管理流程具体实施方案
2.1根本原那么
公司开发部力求建立公平公正的评价体系,严谨的工作流程定义和及时的记录与反应,规职员活动,形成一个紧有序的团队。
没有一个明晰的流程和高效的反应体系,就不可能把工作做好。
但是,这需要每个人按照规那么把自己应该负责的那一局部高效完成,只有这样才能保证整个系统的顺畅,同时,如果个人没有完成自己的指责和按照规定填写容,影响的不单单是自己的工作而是整个系统。
2.2容概述
●日报周报使用规那么目的注意是为了提高开发部整体的方案能力,反应能力和管理者的控制能力。
同时提高整体职员参与公司管理的渠道。
●日常活动的方法
提供开发部工作流程外的突发事件的解决方法
2.3容详细描述
2.3.1日报/周报使用规那么
(1)日报/周报的使用
加强全体人员的方案能力,做到我每天要做什么?
今天工程经理给我的安排是什么?
对应工程经理和部长要知道每个人在做什么?
只有这样,才能保证控制人员可以宏观调控,而个人也不会不知所措。
考前须知:
1.周报哪怕只有一天也需填写;保持统一性
2开场时间必须为22:
00完毕时间为23:
00,
容
负责人
填写要求
监视人
违规处理
周报
工程组长
技术分析负责人
测试组组长
工程进展整体状况:
本周已完成工作量及不能解决的问题反应,建议或提议;
为每一个人员安排下周工作方案,下周工程风险的预估。
必须填写必须每周五16:
00前填写完毕。
工程经理
没有按时提交的,负责人扣除相应的绩效
日报
开发部全体人员
工程进展状况:
不能解决的问题反应建议或提议;突发问题必须反应;
当天已完成工作量,明天工作量安排
建议大家把工作安排填写,有利于提高自己的方案能力和规划能力。
同时能保证事情不会忘记。
工程组长
(2)目标功能的使用
为每一个程序员根据个人不同的能力和状况设定目标,对于圆满完成目标者进展鼓励。
同时,保证公司的开发效果在可控制围。
3开发部管理流程具体实施方案
3.1容概述
开发部从流程上主要分为以下几方面:
(1)开发部管理人员工作流
(2)BUGSurvey工作流
(3)工程分析工作流
(4)Beta后质量保证工作流
(5)测试组beta前工作流
(6)工程组运行根本工作流
开发部从实施人员角色划分如下:
工程组长:
统筹解决工程的全部事宜。
进展工程的整体方案的制定和实施,保证工程的可持续开展和利润率。
工程经理:
对公司级的资源进展调配,同时进展开发部的整体方案的制定和实施,保证开发部的可持续开展和利润率。
技术设计负责人:
统一协调分析组的工作,在对日工程分析组中,进展设计文档的统一确认,在对中方工程中,承当需求的统一把关处理。
同时负责分析组的日常工作安排的统筹。
QA:
统一管理工程质量保证,监视工程组各项活动有序开展
程序员:
主要是负责工程按照分析文档的实施,同时,在实施过程中优化代码构造,提出合理化建议,其中优秀者可以作为TeamLeader负责具体组织工作和分析管理工作。
测试员:
负责公司测试流程的具体实施,要求掌握测试的技术,提出合理化建议,并保证整个软件的可靠度。
翻译人员:
负责中外文文档的翻译,要求工作严谨,保证质量。
在同客户交流中,负责接待和沟通。
同时,在个人的开展意向中可以兼顾其它公司的常务工作。
3.2开发部概要流程图
3.3开发部管理人员工作流
3.3.1软件开发管理体系构成
参与人员:
〔技术设计负责人+测试负责人〕+工程组长
管理主线:
●管理人员去适宜目前我们正在进展的总量有多少,检收而为付款的有多少,实施完毕而没有检收的有多少。
●管理人员去看我们下周能够承受的工程有多少,以便在每周五可以制定下周的工作方案。
●工程经理可以看自己负责工程的根本参数。
Bug管理系统:
作为质量控制过程实际结果的监控。
以便总结质量的问题,进展反应。
Fileserver文档:
通过文档管理和整理,保证全部职员能够随时的了解其他工程的信息和相信容。
同时,统一化文档管理,为以后的开展提供素材。
所有的文档主要包含如下几种:
●HearingSheet:
一个简要的需求,重点在于强调这个需求的原因〔前因后果〕
●UI文件
●设计文档:
东京和共同进展
●估算报价书
●问题收集表:
所有的问题一定要集中在一个文档
●功能点文档:
一定要融合问题收集表对应答案的所有容
●方案文档:
要包含甘特图
●工程总结及绩效分配方案:
把工程总结作为重点进展。
●单体测试用例;按照模板进展
●测试组测试用例:
要保证最后的测试结果
●确认测试用例:
客户确认
●beta版后障害书:
工程确认者发送,按照同一格式进展书写和填写。
●beta后障害list表,其中包含bug的简单描述、bug的类型确定和各部门关于bug的总结。
〔2〕过程管理类
一个工程两次会议:
工程启动会议和工程总结会议
工程启动会议主要是讲述工程的功能点,并据具体问题,进展严格的定义,说明本工程所必须遵守的特殊规那么,子功能间的前后顺序,统一的接口定义,和每个人在工程实施中应该注意的问题。
工程总结会议和MD分配方案确实定。
主要是根据工程实施的结果,进展集中的讨论
和谐而公平的团队:
公司其他方面的管理,就是为了加强管理,提倡量化。
做到各司其职,多劳多得,公平评价,提供时机给相应的人。
3.3.2管理人员考前须知
其中反应机制的建立最关键。
其中管理必须遵守以下规那么:
对象
流程编号
工作容
上流方
下流方
备注
工程经理
分配工程
客户负责人
工程组长
解决人力矛盾
工程组长
测试负责人技术设计负责人
工程组长
测试负责人技术设计负责人
下流方人员负责把结果反应给东京担当者
开发部经理
公司管理问题
工程经理
各级负责人
职员
全体职员
一定要给问题提出者答复,成为制度后公布
组长
分配工程
工程经理
各个成员
工程人力调节
无
工程经理
如果出现空闲同时反应。
分部管理问题
无
开发部经理
工程经理
工程分析和问题确认
无
客户
结果物概要需求文档和问题与回复整理文档
工程里程碑信息反应
工程开场时间,alfa,beta版本时间和原因,估算变更及原因
无
工程经理
组织团队进展技术文档的书写和维护
无
测试部经理
team所有成员
文档列表如下:
功能点文档
问题收集
方案书
单体测试用例
QA
监视svn的执行情况
程序员
工程经理
组长
监视过程管理参数
组长
工程经理
整理所有工程文档
组长
工程经理
对日汇报表
组长
工程经理
绩效考核提供过程情况汇总
组长
工程经理
月度过程管理处理表
测试部经理
组织书写测试用例
工程经理〔功能点文档〕
东京
整理汇总beta版后bug分析表
工程经理〔提供的完整的β后障害书〕
所有管理者
其中的技术分析和管理分析及对东京的建议应由工程负责人进展填写
控制测试的结果
3.4Bugsurvey工作流
参见?
bugSurvey工作规约?
。
3.5工程分析工作流
参见?
工程分析工作规约?
3.6Beta后质量保证工作流
参见?
beta后规作规约?
3.7测试组beta前工作流
3.8工程组根本工作流
3.8.1概述
在工程进展过程中,要求能够及时反应。
做好方案安排,并调整这个人力的配比,以到达最好的效果。
3.8.2对程序员的要求
●尤其在分析组成立前期,对分析组的设计书,尽可能提出建立性意见和设计的问题,有利于提高工程分析能力
●在功能实现上,主要和工程经理的沟通,把类构造设计和代码向理想情况努力,同时用公司的代码规作为自己的行动准那么
●在日常活动中,加强团体意识,加强责任感。
3.8.3对工程经理的要求
主要职责为:
●类设计的严格控制。
保证整个软件包的可维护性
●工程过程管理。
能够严密的控制整个工程的进程,发现工程中的各种风险因素,尽早地把风险在工程中消除。
硬性要求如下:
(1)每个工程〔大于10MD正常工程〕必须提供的文档为功能点文档,需求收集,单体测试用例,工程总结及MD最终分配方案文档
(2)每个工程〔大于10MD正常工程〕必须召开两次会议:
工程启动会议主要为了统一工程的容规那么和要求,同时把整体逻辑和框架做简要说明。
工程总结会议:
主要是评价每个成员的表现和工程完整的状况和质量,总结失败的经历教训。
同时根据评论的结果进展最后的MD的分配。
●整个团队的建立和公司的管理工作。
在工程管理中发现问题,把反映给公司。
以备在公司级别对整个流程和各个环节进展调整。
3.8.4流程图
3.8.5工程组文档管理
原那么:
●所有文档必须都放在SVN上,进展统一管理。
同时,负责人在本地应保存一份同样的备份。
●细节描述(各路径存放什么文件)
工程
容
备注
Spec
设计说明书
QuestionSheet
设计说明书的补充说明
设计说明书的各个版本
设计说明书一览表
设计说明书一览表要记录所有文档变更的情况,并指明最后工程实施与文档之间的关系
Testcase
工程组书写的单体测试用例
测试组书写的测试用例
东京发送的confirm测试用例
Schedule
针对工程实施的日程安排
对东京进展进度汇报的每个报表
FunctionPoints
功能点文档
AllBugSpec
Beta后障害书
针对此工程的beta后bug类型确定和经历汇总。
完毕后,应及时发送测试组工程经理。
UI
HtmlDemo
HearingSheet
联系分析组,如果有应该直接copy
FPSpec
FPsheet不同版本
FPchange表
FP说明,记录所有FP变更历史,以备后期确认的方便。
3.9测试部β版前流程
3.9.1相关人员
测试部经理:
××
测试组成员:
3.9.2测试人员的要求
●一定要注意配合。
因为,在此环节,一种好的描述方式和沟通方式将会直接影响工作效率和工作质量。
所以,首先大家要注意bug管理系统的使用方法和规那么,同时,尽量采用统一的属于进展描述,如果需要图形辅助,也可以进展贴图。
●加强需求理解能力。
能够尽快的理解文档和功能测试用例。
●在工作中细致、耐心、有条理。
●同时对应esm系统需要测试部填写的过程参数必须严格按照规定填写。
3.9.3工作流程图
3.9.4考前须知
●Bug管理系统中的状态一定要维护,并通过此系统来保证alfabug修改的进展情况,即在提交beta版前,所有的alfabug的状态都应该在jira上。
如果没有在此状态中,应该积极和工程组联系,测试组有权监视其完成。
●测试组要验证工程组提交的script和resoruce文件,如果有问题,测试组有权通知工程立即修改,同时可以作为alfabug登录在jira管理系统中。
●测试组要保证测试用例的质量,尽一切可能减少beta后bug的数量。
并严格的按照beta后bug处理规约进展。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目 开发 流程