软件的开发部规章规章制度及软件的项目管理方法.docx
《软件的开发部规章规章制度及软件的项目管理方法.docx》由会员分享，可在线阅读，更多相关《软件的开发部规章规章制度及软件的项目管理方法.docx（16页珍藏版）》请在冰点文库上搜索。
软件的开发部规章规章制度及软件的项目管理方法
软件开发部规章制度与软件项目管理方法
第一局部：
软件开发部规章制度
一、日常工作制度：
1、关于休假、加班：
严格遵守公司的考勤制度，如有事，提前书面形式填写请假申请，批准后方可休假，如情况紧急不能提前填写请假申请，要请示上级领导，并在休假后补办请假手续。
开发部人员在项目紧X时尽量不提出请假申请。
研发人员原如此上不安排加班，研发进度根据公司要求结合项目实际由项目组长负责制定，项目组长协调安排工作。
项目组长根据进度需要安排的加班，加班费用由项目奖金中支出。
公司工作需要硬性安排的加班，加班费有公司支出。
相关标准按照国家相关制度执行。
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》。
其中***为项目名称，日期为例会召开日期。
二、软件开发部组织结构：
三、开发部人员岗位制度：
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）开发人员：
软件部门根据软件项综合评价表每个月或季度统计各开发人员所负责的软件项的平均得分值，比拟开发人员软件项的平均得分值与绩效考核标准X围，确定开发人员绩效考核评价。
根据相应的绩效考核成绩决定每个开发人员的奖励等级。
2）项目经理：
软件部门每个月或季度确定了项目组成员绩效考核评价后，计算项目组的平均得分值，比拟项目组的平均得分值与绩效考核标准X围，确定项目经理、开发经理绩效考核评价。
3）测试人员考核：
测试人员的缺陷查找质量度量表作为月度考核或季度考核依据，软件部门根据软件项综合评价表每个月或季度统计各检查人员或测试人员缺陷查找的平均得分值，比拟检查人员或测试人员缺陷查找的平均得分值与绩效考核标准X围，确定检查人员或测试人员绩效考核评价，绩效考核为"良好"以上人员奖励相应金额。
五、软件资料控制管理：
软件测试由开发组和测试组人员共同进展，提前编写测试计划、侧使用例，最后完成测试报告。
软件开发任务完成后，要提交一份详细资料给公司IT人员。
开发过程亦和公司IT专门人员配合。
IT工作也可由研发部经理安排专门人员负责。
六、软件研发部门项目奖金：
根据公司相关项目性质，制定项目奖的比例，公司计划类项目和工程盈利性项目可按照不同比例制定，盈利性项目可按照利润的百分比制定项目奖，非盈利性项目由公司在项目完成后研究给与适当项目奖。
项目奖由研发部经理、项目组长根据项目组成员实际工作情况，合理安排比例，报请公司批准后由公司统一发放。
七、关于部门协作的规定：
市场部，不设立专门的平面设计人员与技术文档、宣传文档人员，相关工作需部门之间合作完成，部门之间的合作，由部门经理协调，具体适宜由当事人协商解决，本着对公司工作负责的原如此，部门经理根据实际工作安排决定有哪些人配合。
第二局部：
软件项目管理方法
软件项目管理是为了使软件项目能够按照预定的本钱、进度、质量顺利完成，而对人员〔People〕、产品〔Product〕、过程〔Process〕和项目（Project）进展分析和管理的活动。
软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期〔从分析、设计、编码到测试、维护全过程〕都能在管理者的控制之下，以预定本钱按期，按质的完成软件交付用户使用。
一、软件项目的计划：
软件项目计划是一个软件项目进入系统实施的启动阶段,主要进展的工作包括:
确定详细的项目实施X围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、本钱和预算计划、人力资源计划等。
软件项目管理过程从项目计划活动开始，而第一项计划活动就是估算：
需要多长时间、需要多少工作量、以与需要多少人员。
此外，我们还必须估算所需要的资源〔硬件与软件〕和可能涉与到的风险。
为了估算软件项目的工作量和完成期限，首先需要软件规模。
度量软件规模的常用方法有直接的方法——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〕评审准如此
。
评审产品，而不是评审设计者〔不能使设计者有任何压力〕；
。
会场要有良好的气氛；
。
建立议事日程并维持它〔会议不能脱离主题〕；
。
限制争论与反驳〔评审会不是为了解决问题，而是为了发现问题；
。
指明问题X围，而不是解决提到的问题；
。
展示记录〔最好有黑板，将问题随时写在黑板上〕；
。
限制会议人数和坚持会前准备工作；
。
对每个被评审的产品要尽力评审清单〔帮助评审人员思考〕；
。
对每个正式技术评审分配资源和时间进度表；
。
对全部评审人员进展必要的培训；
。
与早地对自己地评审做评审〔对评审准如此的评审〕
升级会员 