软件项目开发流程书(共11页).doc

《软件项目开发流程书(共11页).doc》由会员分享，可在线阅读，更多相关《软件项目开发流程书(共11页).doc（11页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、精选优质文档-倾情为你奉上软件项目开发流程修改历史日期作者修改内容2003-03-12新規制作2003-5-18人员职责的变更，内容的变更2003-12-4针对2004年度制作最新工作内容下的工作流程2004-1-14添加项目经理管理被职员填写下周日程表的规则1 概述1.1 目的l 用标准化的流程来统一管理公司的运作，避免混乱，提高管理的质量。l 在实施过程中，所有管理者能够根据此统一的流程，总结经验，提高认识，加强技术水平和管理水平。l 提高公司级的技术分析能力，为公司储备一支分析队伍，侧重在需求理解和需求分析、框架设计上的能力。l 对人员负责内容上，明确化各自负责的内容，提高工作效率。1.

2、2 内容概述l 开发部日常工作流程l 开发部管理流程l 开发部绩效考核流程l 开发部激励和过失管理流程2 开发部日常管理流程具体实施方案2.1 基本原则公司开发部力求建立公平公正的评价体系，严谨的工作流程定义和及时的记录与反馈，规范职员活动，形成一个紧张有序的团队。没有一个明晰的流程和高效的反馈体系，就不可能把工作做好。但是，这需要每个人按照规则把自己应该负责的那一部分高效完成，只有这样才能保证整个系统的顺畅，同时，如果个人没有完成自己的指责和按照规定填写内容，影响的不单单是自己的工作而是整个系统。2.2 内容概述l 日报周报使用规则目的注意是为了提高开发部整体的计划能力，反馈能力和管理者的控

3、制能力。同时提高整体职员参与公司管理的渠道。l 日常活动的方法提供开发部工作流程外的突发事件的解决方法2.3 内容详细描述2.3.1 日报/周报使用规则（1） 日报/周报的使用加强全体人员的计划能力，做到我每天要做什么？今天项目经理给我的安排是什么？对应项目经理和部长要知道每个人在做什么？只有这样，才能保证控制人员可以宏观调控，而个人也不会不知所措。注意事项：1. 周报哪怕只有一天也需填写；保持统一性2 开始时间必须为22：00 结束时间为23：00，内容负责人填写要求监督人违规处理周报项目组长技术分析负责人测试组组长项目进展整体状况：本周已完成工作量及不能解决的问题反馈，建议或提议；为每一个

4、人员安排下周工作计划，下周项目风险的预估。必须填写必须每周五16：00前填写完毕。项目经理没有按时提交的，负责人扣除相应的绩效日报开发部全体人员项目进展状况：不能解决的问题反馈建议或提议；突发问题必须反馈；当天已完成工作量，明天工作量安排建议大家把工作安排填写，有利于提高自己的计划能力和规划能力。同时能保证事情不会忘记。项目组长（2） 目标功能的使用为每一个程序员根据个人不同的能力和状况设定目标，对于圆满完成目标者进行鼓励。同时，保证公司的开发效果在可控制范围内。3 开发部管理流程具体实施方案3.1 内容概述开发部从流程上主要分为以下几方面：（1） 开发部管理人员工作流（2） BUG Surv

5、ey 工作流（3） 项目分析工作流（4） Beta后质量保证工作流（5） 测试组beta前工作流（6） 项目组运行基本工作流开发部从实施人员角色划分如下：项目组长： 统筹解决项目的全部事宜。进行项目的整体计划的制定和实施，保证项目的可持续发展和利润率。项目经理： 对公司级的资源进行调配，同时进行开发部的整体计划的制定和实施，保证开发部的可持续发展和利润率。技术设计负责人：统一协调分析组的工作，在对日项目分析组中，进行设计文档的统一确认，在对中方项目中，承担需求的统一把关处理。同时负责分析组的日常工作安排的统筹。QA： 统一管理项目质量保证，监督项目组各项活动有序开展程序员：主要是负责项目按照分

6、析文档的实施，同时，在实施过程中优化代码结构，提出合理化建议，其中优秀者可以作为TeamLeader负责具体组织工作和分析管理工作。测试员：负责公司测试流程的具体实施，要求掌握测试的技术，提出合理化建议，并保证整个软件的可靠度。翻译人员：负责中外文文档的翻译，要求工作严谨，保证质量。在同客户交流中，负责接待和沟通。同时，在个人的发展意向中可以兼顾其它公司内的常务工作。3.2 开发部概要流程图3.3 开发部管理人员工作流3.3.1 软件开发管理体系构成参与人员：（技术设计负责人+测试负责人）+项目组长管理主线：l 管理人员去合适目前我们正在进行的总量有多少，检收而为付款的有多少，实施完毕而没有检

7、收的有多少。l 管理人员去看我们下周能够接受的项目有多少，以便在每周五可以制定下周的工作计划。l 项目经理可以看自己负责项目的基本参数。Bug管理系统：作为质量控制过程实际结果的监控。以便总结质量的问题，进行反馈。Fileserver 文档：通过文档管理和整理，保证全部职员能够随时的了解其他项目的信息和相信内容。同时，统一化文档管理，为以后的发展提供素材。所有的文档主要包含如下几种：l HearingSheet：一个简要的需求，重点在于强调这个需求的原因（前因后果）l UI文件l 设计文档： 东京和北京共同进行l 估算报价书l 问题收集表：所有的问题一定要集中在一个文档内l 功能点文档：一定要

8、融合问题收集表内对应答案的所有内容l 计划文档：要包含甘特图l 项目总结及绩效分配方案：把项目总结作为重点进行。l 单体测试用例；按照模板进行l 测试组测试用例: 要保证最后的测试结果l 确认测试用例： 客户确认l beta版后障害书：项目确认者发送，按照同一格式进行书写和填写。l beta后障害list表，其中包含bug的简单描述、bug的类型确定和各部门关于bug的总结。（2）过程管理类一个项目两次会议：项目启动会议和项目总结会议项目启动会议主要是讲述项目的功能点，并据具体问题，进行严格的定义，说明本项目所必须遵守的特殊规则，子功能间的前后顺序，统一的接口定义，和每个人在项目实施中应该注意

9、的问题。项目总结会议和MD分配方案的确定。主要是根据项目实施的结果，进行集中的讨论和谐而公平的团队：公司其他方面的管理，就是为了加强管理，提倡量化。做到各司其职，多劳多得，公平评价，提供机会给相应的人。3.3.2 管理人员注意事项其中反馈机制的建立最关键。其中管理必须遵守以下规则：对象流程编号工作内容上流方下流方备注项目经理分配项目客户负责人项目组长解决人力矛盾项目组长测试负责人技术设计负责人项目组长测试负责人技术设计负责人下流方人员负责把结果反馈给东京担当者开发部经理公司管理问题项目经理各级负责人职员全体职员一定要给问题提出者答复，成为制度后颁布组长分配项目项目经理各个成员项目人力调节无项目

10、经理如果出现空闲同时反馈。分部管理问题无开发部经理项目经理项目分析和问题确认无客户结果物概要需求文档和问题与回复整理文档项目里程碑信息反馈项目开始时间，alfa,beta版本时间和原因，估算变更及原因无项目经理组织团队进行技术文档的书写和维护无测试部经理team所有成员文档列表如下：功能点文档问题收集计划书单体测试用例QA监督svn的执行情况程序员项目经理组长监督过程管理参数组长项目经理整理所有项目文档组长项目经理对日汇报表组长项目经理绩效考核提供过程情况汇总组长项目经理月度过程管理处理表测试部经理组织书写测试用例项目经理（功能点文档）东京整理汇总beta版后bug分析表项目经理（提供的完整的

11、后障害书）所有管理者其中的技术分析和管理分析及对东京的建议应由项目负责人进行填写控制测试的结果3.4 Bugsurvey工作流参见bugSurvey工作规约。3.5 项目分析工作流 参见项目分析工作规约3.6 Beta后质量保证工作流 参见beta后规作规约3.7 测试组beta前工作流3.8 项目组基本工作流3.8.1 概述在项目进行过程中，要求能够及时反馈。做好计划安排，并调整这个人力的配比，以达到最好的效果。3.8.2 对程序员的要求l 尤其在分析组成立前期，对分析组的设计书，尽可能提出建设性意见和设计的问题，有利于提高项目分析能力l 在功能实现上，主要和项目经理的沟通，把类结构设计和代

12、码向理想情况努力，同时用公司内的代码规范作为自己的行动准则l 在日常活动中，加强团体意识，加强责任感。3.8.3 对项目经理的要求主要职责为：l 类设计的严格控制。保证整个软件包的可维护性l 项目过程管理。能够紧密的控制整个项目的进程，发现项目中的各种风险因素，尽早地把风险在项目中消除。硬性要求如下：（1） 每个项目（大于10MD正常项目）必须提供的文档为功能点文档，需求收集，单体测试用例，项目总结及MD最终分配方案文档（2） 每个项目（大于10MD正常项目）必须召开两次会议：项目启动会议主要为了统一项目的内容规则和要求，同时把整体逻辑和框架做简要说明。项目总结会议：主要是评价每个成员的表现和

13、项目完整的状况和质量，总结失败的经验教训。同时根据评论的结果进行最后的MD的分配。l 整个团队的建设和公司的管理工作。在项目管理中发现问题，把反映给公司。以备在公司级别对整个流程和各个环节进行调整。3.8.4 流程图3.8.5 项目组文档管理原则：l 所有文档必须都放在SVN上，进行统一管理。同时，负责人在本地应保留一份同样的备份。l 细节描述(各路径存放什么文件)注意修正项目内容备注Spec设计说明书QuestionSheet设计说明书的补充说明设计说明书的各个版本设计说明书一览表设计说明书一览表要记录所有文档变更的情况，并指明最后项目实施与文档之间的关系Test case项目组书写的单体测

14、试用例测试组书写的测试用例东京发送的confirm测试用例Schedule针对项目实施的日程安排对东京进行进度汇报的每个报表Function Points功能点文档All Bug SpecBeta后障害书针对此项目的beta后bug类型确定和经验汇总。完毕后，应及时发送测试组项目经理。UIHtml DemoHearing Sheet联系分析组，如果有应该直接copyFP SpecFP sheet 不同版本FP change 表FP 说明，记录所有FP变更历史，以备后期确认的方便。3.9 测试部版前流程3.9.1 相关人员测试部经理：测试组成员： 3.9.2 测试人员的要求l 一定要注意配合。因

15、为，在此环节，一种好的描述方式和沟通方式将会直接影响工作效率和工作质量。所以，首先大家要注意bug 管理系统的使用方法和规则，同时，尽量采用统一的属于进行描述，如果需要图形辅助，也可以进行贴图。l 加强需求理解能力。能够尽快的理解文档和功能测试用例。l 在工作中细致、耐心、有条理。l 同时对应esm系统需要测试部填写的过程参数必须严格按照规定填写。3.9.3 工作流程图3.9.4 注意事项l Bug管理系统中的状态一定要维护，并通过此系统来保证alfa bug修改的进行情况，即在提交beta版前，所有的alfa bug的状态都应该在jira上。如果没有在此状态中，应该积极和项目组联系，测试组有权监督其完成。l 测试组要验证项目组提交的script 和resoruce文件，如果有问题，测试组有权通知项目立即修改，同时可以作为alfa bug登录在jira管理系统中。l 测试组要保证测试用例的质量，尽一切可能减少beta 后bug的数量。并严格的按照beta后bug处理规约进行。专心-专注-专业