软件开发部规章制度与软件项目管理方法.docx
《软件开发部规章制度与软件项目管理方法.docx》由会员分享，可在线阅读，更多相关《软件开发部规章制度与软件项目管理方法.docx（38页珍藏版）》请在冰点文库上搜索。
软件开发部规章制度与软件项目管理方法
软件开发部规章制度及软件项目管理方法
第一部分：
软件开发部规章制度
一、平时工作制度：
1、对于休假、加班：
严格恪守企业的考勤制度，若有事，提早书面形式填写告假申请，同意后方可休假，如状况紧迫不可以提早填写告假申请，要电话请示上司领导，并在休假后补办告假手续。
开发部人员在项目紧张时尽量不提出告假申请。
研发人员原则上不安排加班，研发进度依据企业要求联合项目实质由项目组长负责拟定，项目组长协调安排工作。
项目组长依据进度需要安排的加班，加班花费由项目奖金中支出。
企业工作需要硬性安排的加班，加班费有企业支出。
有关标准依照国家有关制度履行。
2、开发部职工守则：
遵纪守纪，忠于职责，克己奉公。
保护企业名誉，保护企业利益。
听从领导，关怀部下，团结相助。
爱惜公物，节俭开销，根绝浪费。
努力学习，提升水平，精晓业务。
踊跃进步，勇于开辟，创新贡献。
3、职工工作日志：
工作日志制度的目的是形成严格的工作追踪和累积习惯，要求部门中项目负责人以下人员按要求每天记录。
工作日志是部门职工的工作记录载体，起到部分绩效查核和浮动薪资确实定依照的作用。
工作日志包含每天计划和达成状况，每天工作一直时间，每天工作饱和度（5为最高，
1为最低，如为告假，请注明“事假”或“病假”），次周计划，以及问题、建议和
建议。
工作日志严格要求每天填写，绝不一样意在上交前一致填写。
如发现某些栏目多周相同的状况，将进行警示。
填写时注意清空原有内容。
每天工作内容如无特别状况，起码需要写3条以上。
表达工作内容要求尽可能说明清
楚。
不一样意简单的如“改正错误”的描绘。
工作日志严格要求在次周上午10:
00前提交。
不提交工作周报将适合予以处罚。
对于未提交日志的人员，部门经理保证当周内口头通知。
工作日志以Email形式提交给项目负责人和部门经理。
部门经理收到后保证第一时间
进行答复，并依此进行查核。
文件名格式：
《***工作日志（200*年*月*日）.doc》。
此中***为职工姓名，日期为提交日期。
4、项目月报制度：
项目月报制度是保证项目顺利推动的一种阶段性总结和计划载体的体制。
项目月报由项目负责人负责制定。
项目月报应依据实质状况包含本月计划、达成状况（含计划的偏离状况）、成就和不足、突发事务及其解决状况、项目构成职工作状况、客户反应状况、下月计划，以及问题、建讲和建议等内容。
项目月报由项目负责人于每个月第五个工作日从前，经过
Email
提交给部门经理，经部
门经理审订后公布到项目月报文件夹中。
部门所有成员能够查阅已公布的项目月报。
项目月报的文件名格式为《***项目月报（$$$，200*年*月*日）.doc》。
此中***为项目名称，$$$为项目负责人姓名，日期为提交日期
5、项目例会制度：
每个月第一个周一上午10:
30在企业会议室召开，部门所有人员（含参加部门人员为主导的项目并起中心作用的其余部门人员）参加。
会议由部门经理招集，并由部门经理主持。
会议议程：
a）各项目负责人回首上月工作状况、成就和不足，以及当月的大概工作计划。
b）部门经理总结上月工作，对不足的问题提出解决方法。
c）部门经理宣告企业近期动向和有关事项。
d）部门经理做出工作方面的安排。
e）部门人员各抒己见，提出问题、想法、建议与建议。
大家议论。
f）部门经理解答部门人员的问题，并做出总结。
部门人员轮番做会议记录，并在会议结束后次日内整理并在Vss中公布。
文件名格
式：
《软件二部200*年*月*日例会（***整理）.doc》。
此中日期为例会召开日期，***
为会议记录整理人的姓名。
6、部门例会制度：
每周五下午在部门会议室召开，详细项目的所有参加人员参加。
会议由项目负责人招集并主持，部门经理依据实质状况出席。
会议指定固定人员做会议记录，
并在第二周周一上午
9:
30前整理并经过邮件发送给项
目负责人。
项目负责人改正并认同会议记录后，在第二周周一上午
11:
00前在Vss中公布。
文件
名格式：
《***项目组例会（200*年*月*日）.doc》。
此中***为项目名称，日期为例会召开日期。
二、软件开发部组织构造：
开发部经理
项目组长A
项目组长N
项目组长B
系统剖析员
系统剖析员
系统剖析员
系统设计
系统设计
系统设计
程序员A
程序员A
程序员A
程序员N
程序员N
程序员N
软件测试
软件测试
软件测试
项目小组
项目小组
项目小组
三、开发部人员岗位制度：
1、开发部经理岗位职责：
职责：
1）拟定产品的目标。
2）拟定各个工作的详尽任务表，追踪这些任务的履行状况，进行控制。
3）组织会议对程序进行评审。
4）综合详细状况，对各样不一样方案进行弃取并做出决定。
5）协调各项目参加人员之间的关系。
2、项目组长岗位职责：
1）对项目经理负责，负责软件项目的详尽设计、编码和内部测试的组织实行，对小型软件项目兼任系统剖析工作。
2）参加需求调研、项目可行性剖析、技术可行性剖析和需求剖析。
3）熟习并娴熟掌握交托软件部开发的软件项目的有关软件技术。
4）负责向项目经理及时反应软件开发中的状况，并依据实质状况提出改良建议。
5）参加软件开发和保护过程中重要技术问题的解决，参加软件初次安装调试、数据割接、用户培训和项目推行。
6）负责有关技术文档的拟定。
7）负责对业务领域内的技术发展动向进行剖析研究。
8）负责向项目经理、部门经理/副经理及时反应实质工作中碰到的问题，并提出改良建议。
9）肩负相应的保密职责。
10）达成部门经理/副经理或项目经理交办的其余工作。
3、一般开发人员岗位职责：
1）依据项目详细要求，肩负开发任务，按计划达成任务目标。
2）配合系统剖析人员达成软件系统及模块的需求调研与需求剖析
3）配合系统剖析人员达成软件系统及模块的设计
4）独立达成软件系统及模块的编码
5）辅助测试一试人员达成软件系统及模块的测试
6）负责编制与项目有关的技术文档
四、软件研发人员绩效查核：
1、目的：
对软件开发的过程所产生的软件项的质量和过程进行定量的评论，用评论的结果指导软件的开发过程，不停地提升软件开发质量水平，并依照胸怀记录来查核软件开发人员的工作绩效。
2、软件项包含：
1）技术文档：
主要包含：
可行性剖析报告、需求剖析报告、软件功能规格说明、开发计划、质量计划、系统设计报告、测试文档、技术报告、用户手册、总结报告等；
2）计算机程序。
3、胸怀数据根源：
1）项目计划；
2）评审报告；
3）测试报告；
4）问题报告；
5）软件保护记录；
4、质量胸怀：
胸怀指标，主要依据各种软件项检查表的检查指标来确立，比如，软件需求规格说明书检查表（见附录1），有10个检查指标，则依据详细项目检查重视点不一样，可从中选择相应的检查指标作为胸怀指标。
质量等级：
1）软件项的质量等级确实定依据胸怀综合指标进行。
2）胸怀综合指标计算公式为：
Total=∑QiMi
5、过程胸怀：
1）及时度：
以软件项目计划规定的的达成时间为基准
2）成熟度：
以软件项检查、评审、测试的结果为评论基准
3）改良效率：
在检查、评审、测试的结果的基础上改良软件项结果，以改良的时间能否影响后续阶段的达成和计划的整体达成时间为评分依照
6、人员绩效查核：
1）开发人员：
软件部门依据软件项综合评论表每个月或季度统计各开发人员所负责的软件项的均匀得分值，比较开发人员软件项的均匀得分值与绩效查核标准范围，确立开发人员绩效查核评论。
依据相应的绩效查核成绩决定每个开发人员的奖赏等级。
2）项目经理：
软件部门每个月或季度确立了项目构成员绩效查核评论后，计算项目组的均匀得分值，比较项目组的均匀得分值与绩效查核标准范围，确立项目经理、开发经理绩效查核评论。
3）测试人员查核：
测试人员的缺点查找质量胸怀表作为月度查核或季度查核依照，软件部门依据软件项综合评论表每个月或季度统计各检查人员或测试人员缺点查找的均匀得分值，比较检查人员或测试人员缺点查找的均匀得分值与绩效查核标准范围，确立检查人员或测试人员绩效查核评论，绩效查核为"优异"以上人员奖赏相应金额。
五、软件资料控制管理：
软件测试由开发组和测试组人员共同进行，提早编写测试计划、侧使用例，最后
达成测试报告。
软件开发任务达成后，要提交一份详尽资料给企业IT人员。
开发过程亦和企业IT特意人员配合。
IT工作也可由研发部经理安排特意人员负责。
六、
软件研发部门项目奖金：
依据企业有关项目性质，拟定项目奖的比率，企业计划类项目和工程盈余性项目可依照不一样比率拟定，盈余性项目可依照收益的百分比拟定项目奖，非盈余性项目由企业在项目达成后研究给与适合项目奖。
项目奖由研发部经理、项目组长依据项目构成员实质工作状况，合理安排比率，报请企业同意后由企业一致发放。
七、对于部门协作的规定：
市场部，不建立特意的平面设计人员及技术文档、宣传文档人员，有关工作需部门之间合作达成，部门之间的合作，由部门经理协调，详细适合由当事人磋商解决，本着对企业工作负责的原则，部门经理依据实质工作安排决定有哪些人配合。
第二部分：
软件项目管理方法
软件项目管理是为了使软件项目能够依照预约的成本、进度、质量顺利达成，而对
人员（People）、产品（Product）、过程（Process）和项目（Project）进行剖析和管理的活
动。
软件项目管理的根本目的是为了让软件项目特别是大型项目的整个软件生命周期（从分
析、设计、编码到测试、保护全过程）都能在管理者的控制之下，以预约成本如期，按质的达成软件交托用户使用。
一、软件项目的计划：
软件项目计划是一个软件项目进入系统实行的启动阶段,主要进行的工作包含:
确立
详尽的项目实行范围、定义递交的工作成就、评估实行过程中主要的风险、拟定项目实行的时间计划、成本和估量计划、人力资源计划等。
软件项目管理过程从项目计划活动开始，而第一项计划活动就是估量：
需要多长时间、需要多少工作量、以及需要多少人员。
别的，我们还一定估量所需要的资源（硬件及软件）和可能波及到的风险。
为了估量软件项目的工作量和达成限期，第一需要展望软件规模。
胸怀软件规模的
常用方法有直接的方法——LOC（代码行），间接的方法——FP（功能点）。
这两种方法各有优弊端，应当依据软件项目的特色选择合用的软件规模胸怀方法。
二、
软件项目的控制：
对于软件开发项目而言，控制是十分重要的管理活动。
软件质量保证（SQA，SoftwareQualityInsurance）是在软件过程中的每一步都进行的“保护性活动”。
SQA主要有鉴于非履行的测试（也称为评审）、鉴于履行的测试（即
往常所说的测试）和程序正确性证明。
（1）用分阶段的生命周期计划严格管理；
（2）坚持进行阶段评审；
（3）推行严格的产品控制；
（4）采纳现代程序设计技术；
（5）结果应能够清楚地审察；
（6）开发小组地人员应当少而精；
（7）认可精益求精软件工程实践地必需性。
软件配置管理（SCM，Softwareconfigurationmanagement）是应用于整个软件过程中的保护性活动，它是在软件整个生命周期内管理变化的一组活动。
1、当前软件开发中面对的问题
。
在有限的时间、资本内，要知足不停增添的软件产质量量要求；
。
开发的环境日趋复杂，代码共享日趋困难，需超越的平台增加；
。
程序的规模愈来愈大；
。
软件的重用性需要提升；
。
软件的保护愈来愈困难。
2、软件配置管理应供给的功能，在ISO9000.3中，对配置管理系统的功能作了以下描绘：
。
独一地表记每个软件项的版本；
。
表记共同构成一完好产品的特定版本的每一软件项的版本；
。
控制由两个或多个独立工作的人员同时对一给定软件项的更新；。
控制由两个或多个独立工作的人员同时对一给定软件项的更新；。
按要求在一个或多个地点对复杂产品的更新进行协调；
。
表记并追踪所有的举措和改正；这些举措和改正是在从开始直到放行时期，因为改正恳求或问题惹起的。
3、版本管理
软件配置管理分为版本管理、问题追踪和成立管理三个部分，此中版本管理是基
础。
版本管理应达成以下主要任务：
。
成立项目；
。
重构任何订正版的某一项或某一文件；
。
利用加锁技术防备覆盖；
。
当增添一个订正版时要求输入改正描绘；
。
供给比较随意两个订正版的使用工具；
。
采纳增量储存方式；
。
供给对订正版历史和锁定状态的报告功能；
。
供给合并功能；
。
同意在任何时候重构任何版本；
。
权限的设置；
。
荣膺模型的成立；
。
供给各样报告。
三、软件项目管理的组织形式：
软件项目能够是一个独自的开发项目，也能够与产品项目构成一个完好的软件产品项目。
假如是订单开发，则成立软件项目组即可；假如是产品开发，需成立软件项目组和产品项目（负责市场调研和销售），构成软件产品项目组。
企业推行项目管理时，第一要成立项目管理委员会，项目管理委员会下设项目管理
小组、项目评审小组和软件产品项目组。
1、项目管理委员会
项目管理委员会是企业项目管理的最高决议机构，一般由企业总经理、副总经理构成。
主要职责以下：
（1）依照项目管理有关制度，管理项目；
（2）监察项目管理有关制度的履行；
（3）对项目立项、项目取消进行决议；
（4）委任项目管理小组组长、项目评审委员会主任、项目组组长.
2、项目管理小组
项目管理小组对项目管理委员会负责，一般由企业管理人员构成。
主要职责以下：
（1）起草项目管理的各项制度；
（2）组织项目阶段评审；
（3）保留项目过程中的有关文件和数据；
（4）为优化项目管理提出建议。
3、项目评审小组
项目评审小组对项目管理委员会负责，可下设开发评审小组和产点评审小组，一般由企业技术专家和市场专家构成。
主要职责以下：
（1）对项目可行性报告进行评审；
（2）对市场计划和阶段报告进行评审；
（3）对开发计划和阶段报告进行评审；
（4）项目结束时，对项目总结报告进行评审。
4、软件产品项目组
软件产品项目组对项目管理委员会负责，可下设软件项目组和产品项目组。
软件项目组和产品项目组分别设开发经理和产品经理。
成员一般由企业技术人员和市场人员构成。
主要职责是：
依据项目管理委员会的安排详细负责项目的软件开发和市场调研及销售工作。
四、人员的组织与管理：
软件开发中的开发人员是最大的资源。
对人员的配置、调动安排贯串整个软件过程，人员的组织管理能否适合，是影响对软件项目质量的决定性要素。
第一在软件开发的一开始，要合理的配置人员，依据项目的工作量、所需要的专业技术，再参照各个人员的能力、性格、经验，组织一个高效、和睦的开发小组。
一
般来说，一个开发小组人数在5到10人之间最为适合，假如项目规模很大，能够采纳层级式构造，配置若干个这样的开发小组。
在选择人员的问题上，要联合实质状况来决定能否选入一个开发组员。
其实不是
一群高水平的程序员在一同就必定能够构成一个成功的小组。
作为观察标准，技术水平、
与本项目有关的技术和开发经验、以及团队工作能力都是很重要的要素。
一个一天能写
一万行代码但却不可以与同事交流和睦的程序员，未必适合一个对组员之间通信要求很高
的项目。
还应当考虑分工的需要，合理配置各个专项的人员比率。
比如一个网站开发项
目，小组中有页面美工、后台服务程序、数据库几个部分，应当合理的组织各项工作的
人员配比。
在决定一个开发组的开发人员数目时，除了考虑候选人素质之外，还要综合考虑项
目规模、工期、估量、开发环境等要素的影响.
在组建开发组时，还应充足预计到开发过程中的人员风险。
因为工作环境、待遇、工作强度、企业的整体工作安排和其余没法预知的要素，一个项目特别是开发周期较长
的项目几乎无可防止的要面对人员的流入流出。
假如不在项目早期对可能出现的人员风险进行充足的预计，作必需的准备，一旦风险转变为现实，将有可能给整个项目开发造
成巨大的损失。
以较低的代价进行提早的预防是降低这类人员风险的基本策略。
详细来说能够从以下几个方面对人员风险进行控制：
a．保证开发组中全职人员的比率，且项目中心部分的工作应当尽量由全职人员来担当，以减少兼职人员对项目组人员不稳固性的影响。
b．成立优异的文档管理体制，包扩项目组进度文档、个人进度文档、版本控制文
档、整体技术文档、个人技术文档、源代码管理等。
一旦出现人员的改动，比方某个组员因病退出，替补的组员能够依据完好的文档尽早接手工作。
c．增强处目组内技术交流，比方按期开技术交流会，或依据组内分工成立项目组
内部的开发小组，是开发小组内的成员能够互相熟习对方的工作和进度，能够在必需的时候替对方工作。
d．对于项目经理，能够从一开始就指派一个副经理在项目中共同项目经理管理项
目开发工作，假如项目经理退出开发组，副经理能够很快接手。
可是只建议在项目经理
这样的高度重要的岗位采纳这类冗余复制的策略来预防人员风险，不然将大大增添项目成本。
e．为项目开发供给尽可能好的开发环境，包含工作环境、待遇、工作进度安排等等，同时一个优异的项目经理应当能够在项目组内创造一种优异的人际关系和工作氛围。
优异的开发环境对于稳固项目组人员以及提升生产效率都有不行忽略的作用。
五、软件项目管理的的原则：
1均衡原则
2高效原则
3分解原则
4及时控制原则
5分类管理原则
6简单有效原则
7规模控制原则
六、软件开发不一样阶段一定具备的文档资料：
项目阶段所需文档
开始编码前需求剖析
整体设计
详尽设计（整体设计和详尽设计能够合并在同一个文中间）
提交查收javadoc
测试计划（对于用户前台，需要手工测试的模块）
产品公布操作手册
企业项目开发周期分为以下几个步骤：
步骤
说明
参加角色
生成文档或程序
（打*号为可选）
可
行
对项目的技术，功能需乞降市场进行
部门主管
可行性剖析报告*
性
分
调研和初步剖析，确立能否需要立项
中心技术员
技术调研报告*
析
开发。
立项
正式立项，由部门主管指定项目经理，
部门主管
项目初步计划
项目经理拟定初步计划。
初步计划包
中心技术员
括设计和开发时间的初步估量。
需
求
对项目进行详尽的需求剖析，编写需
项目经理
需求剖析文档
剖析
求剖析文档。
对于B/S构造软件系统
项目中心小
静态演示页面
需要制作静态演示页面。
需求剖析文
组
档和静态演示页面需要经过部门主管
项目计划订正版本
审批才能够进行到下一个步骤
详
细
依据需求剖析对项目进行详尽设计。
项目经理
详尽设计文档
设计
详尽设计此后，项目经理同部门主管
项目中心小
项目计划确立版本
一同指定项目小组开发成员。
组
开发
依据设计开发项目，由美工对操作界
项目经理
项目计划订正版本*
面进行美化。
项目开发员
美工
测试
项目经理提交测试申请，由测试部门
项目经理
测试申请
对项目进行测试。
项目小组配合测试
项目开发员
测试计划
部门改正软件中的错误。
测试部
测试报告
项
目
项目查收归档
部门主管
项目所有文档和程序
查收
项目经理
七、软件评审：
软件评审其实不是在软件开发完成后进行评审，而是在软件开发的各个阶段都要进行评审。
因为在软件开发的各个阶段都可能产生错误，假如这些错误不及时发现并纠正，会不停地扩大，最后可能致使开发的失败。
软件评审是相当重要的工作，也是当前国内开发最不重视的工作。
（1）评审目标
。
发现任何形式表现的软件功能、逻辑或实现方面的错误；。
经过评审考证软件的需求；
。
保证软件按早先定义的标准表示；
。
已获取的软件是以一致的方式开发的；。
使项目更简单管理。
（2）评审过程
A、召开评审会议：
一般应有3至5人参加，会前每个参加者做好准备，评审会每次一般不超出2小时。
B、会议结束使一定做出以下决议之一：
接受该产品，不需做改正；因为错误严重，拒绝接受；临时接受该产品。
C、评审报告与记录；所提出的问题都要进行记录，在评审会结束前产生一个评审讯题表，此外一定达成评审简要报告。
（3）评审准则
。
评审产品，而不是评审设计者（不可以使设计者有任何压力）；。
会场要有优异的氛围；
。
成立议事日程并保持它（会议不可以离开主题）；
。
限制争辩与辩驳（评审会不是为认识决问题，而是为了发现问题；。
指明问题范围，而不是解决提到的问题；
。
展现记录（最好有黑板，将问题随时写在黑板上）；
。
限制会议人数和坚持会前准备工作；
。
对每个被评审的产品要全力评审清单（帮助评审人员思虑）；
。
对每个正式技术评审分派资源和时间进度表；
。
对所有评审人员进行必需的培训；
。
提早地对自己地评审做评审（对评审准则的评审）
您好，欢迎您阅读我的文章，本WORD文档可编写改正，也能够直接打印。
阅读事后，希望您提出保贵的建议或建议。
阅读和学习是一种特别好的习惯，坚持下去，让我们共同进步。
升级会员 