软件开发项目管理制度

软件开发项目管理制度（共8篇）

篇1：软件开发项目管理制度

1.负责项目管理软件的全部开发管理工作。

2.负责开发工作计划的制订、任务安排、工作检查和考核。

3.负责项目管理软件相关的开发代码、配套文档的管理工作。

4.负责开发队伍的建设和培养。

篇2：软件开发项目管理制度

项目管理是第二次世界大战后期发展起来的重大新管理技术之一。虽然在此之前项目管理已广泛应用于许多事业领域，如工程建设项目和新产品开发，但直到第二次世界大战期间以及战后，它作为管理技术复杂的活动，或需要多学科协作的活动的一种特殊工具的价值，才完全被认识，其结果使项目管理成为一种相对来说较新的管理方法，得到迅速发展和不断完善，现在，项目管理已经被公认为是一种有生命力并能实现复杂的企业目标的良好方法。

随着信息技术的飞速发展，软件产品的规模也越来越庞大，个人单打独斗的作坊式开发方式已经越来越不适应发展的需要。各软件企业都在积极将软件项目管理引入开发活动中，对开发实行有效的管理。从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展（即减小开发风险）。

本文将根据自己在软件开发项目中的实际经验来浅述在软件项目开发过程中项目经理如何使用项目管理的理论来进行软件项目的管理。

一、需求的确定

需求的确定也就是项目范围的确定，这是项目管理中首先要注意的，是软件开发项目管理的重中之重，只有分析设计的时间越长，需求设计做的越详细，测试的时间就越短，返工率越低，风险也越小，成本越容易得到控制。而需求分析没有做好就急忙上马进行开发的项目在项目初期进展顺利的时候问题不大，到了项目后期和测试阶段，一些潜伏期比较长但破坏作用比较大的问题就会显现出来，造成返工，延长测试时间。

本人原来负责过一个企业的B2B电子商务系统的项目，客户方对项目进度要求特别快，我们公司领导因为和客户方的领导关系比较好，所以就要求我们必须满足他们的时间要求。所以在做需求分析是，客户方就要求我们做需求的时间不要太长，还说具体细节可以在以后填充。就这样，经过简单的需求分析后，该项目就正式开始启动了，我们项目团队也就抓紧时间开始进行项目的开发了。

但结果证明我们是错误的，等我们按照项目开发计划的时间把DEMO版交给客户方的时候，客户方却对结果不满意，他们认为他们想实现的一些功能我们没有替他们实现，而实际上他们说的功能我们在做需求分析的时候他们并没有提供给我们；另外，客户方对系统的界面、操作方法还有一些其他功能也不满意，认为界面不符合他们企业的风格、操作过程也和他们现有的一些操作流程不太吻合等。所有的这些客户不满意产生的原因就是我们需求没有做够。

后来，我们只能又根据客户提出的新的需求对系统进行调整，就这样反复过多次，最终系统才能满足用户的需求。但就这个项目本身而言已经是失败了，因为项目的进度拖后、项目的成本也超支了。

所以与其把问题堆积到紧张的项目后期，不如把时间多花点到需求分析和总体设计上。经验告诉我，需求分析本身也存在着时间分配的问题。第一遍需求分析花的时间会最长，分析员们在客户的各个部门之间几乎把腿都跑断，把口水说干，就是为了确立一个初期的需求模型。所有的文档将会提交给项目经理进行复审并签字，不合格的打回重做。反馈表随之将提交给客户，第二遍第三遍等等接踵而来，与客户反复讨论和磋商，反复提交文档和表格，目的只有一个，明确需求。当项目经理最终合并了所有文档并确立需求之后，最终生成的需求文档将提交给客户的各部门负责人签字。这些文档将作为合同的附件添加，以便在将来项目变更或者碰到重大问题时和客户扯皮的重要依据。

二、需求变更的管理

需求变更的管理属于项目管理中的过程控制内容，对任何项目，变更无可避免，无从逃避，只能去积极应对，这个应对应该是从需求分析就开始了。对一个需求分析做的很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理扯皮的幌子就越少。而需求没做好，基准文件里的范围含糊不清，被客户抓住空子搞你一下是非常头疼的事情，往往要付出无谓的牺牲。

一般的，需求做好了，文档清晰又有客户签字，那么后期客户提出的变更就超出了合同的范围，需要另外收费。这个时候千万不能手软，并非要刻意赚取客户的钱财，而是不能养成客户经常变更的习惯，否则后患无穷，维护的成本会让项目经理吃不消。在客户提出变更请求时，要建立变更申请登记表和变更申请表，并让客户签字。当然，有时候一些不是非常关键的模块项目经理也不至于一点不讲情面，该卖面子的时候还是要卖，尤其是当着对方领导的面，千万要卖面子，但是也别卖的太干脆，不要让他们得到的太容易。

三、项目团队的管理

项目团队管理属于项目管理中人力资源管理和沟通管理部分的内容，它是项目能否取得成功的重要因素。挑选合适的项目成员是项目经理头疼的一个大问题，有时候一个在别的项目里很优秀的项目成员，过来本项目未必能适应。所以，项目经理还是要拓展知识面，培养自己的敏锐度，因人置宜，才能挑选对自己项目有帮助的项目成员，才能真正对项目起作用。

任何项目都有核心的项目成员，核心项目成员背负着很重的责任，项目经理要特别注意爱护核心程序员，尤其是他们的生活困难和精神状况，有时候，他们耍性子或者不合作项目经理要妥协，要从自己身上找原因。

对项目程序的奖惩也是项目成员管理的一个重要工作，如果项目成员的工作做的十分好、工作效率很高，项目经理就可以对项目成员进行奖励，一般主要是进行精神上的奖励，如在项目讨论会等场合进行表扬，当然适当的时候可以进行物质上的奖励，如加奖金等；至于惩罚，要注意方法和技巧还是时间场合，骂，扣工资，开除都不顶用，在项目没完成之前不是追究责任的时候。一个优秀的项目经理应该给他一个机会，有时可以当作没事一样让他去做别的事情，把他做砸的事情交给别人去做，但其实这就是对他最大的惩罚。这样既能激励他上进又不会让他尴尬。

项目团队成员的冲突再所难免。在发生冲突的时候项目经理要牢记以公开，公正的方式

处理冲突，不能偏袒任何一方；处理事情的时候必须对事不对人。有时候，成员与项目经理之间也会有冲突，一般情况下都可以几乎肯定是项目经理的责任，因为很少有成员敢吃豹子胆来反抗自己的顶头上司。这时候项目经理除了要及时的做自我检讨之外，要有宽广的心胸。绝对不可以利用职权打击与自己有矛盾的成员，否则团队里所有成员都会心寒，项目的质量将会大打折扣。如果他确实不对，也要忍住，等项目完了在处理。项目经理的心胸还表现在不能嫉贤妒能上。当公司高层越级表扬团队某成员时，你应该高兴和光荣，而不是阴险的想着下次如何把这份光环戴到自己的头上。

项目是有风险的，肯定会有失败的部分甚至整个项目失败。虽然说每个人都在项目里定下了责任，在项目里程碑里都有任务。但是当整个项目危机来临的时候，项目经理要勇于站出来，承担起全部的责任。这是做人的方式，也能让你赢得团队所有成员的尊敬和爱戴。往往在这个时候我们才能体会到什么叫团队合作精神，就是大家齐心合力，共渡难关。

四、项目的沟通管理

在项目开发过程中，要多与项目干系人进行沟通，项目的干系人主要包括客户、公司领导等。

客户是项目开发过程中最要进行沟通的，我们可以尽早对用户进行培训，进行多层面的沟通，让用户深入理解在项目过程中的难点以及可能产生的组织结构与职务、岗位、职责的变化，经常鼓励他们积极参与项目的整个过程，有效排除各种干扰和抵触情绪以确保项目的成功。

除了客户外，项目经理也要多与公司的领导进行沟通，在项目开发过程中不要报喜不报忧，实施过程中出现的问题都要及时反映给公司领导，尽早让领导知道问题的详细情况，领导也就可以针对一些问题做出新的决策。如果把一些错误对公司领导隐瞒，让问题继续发展扩大直至积累到难以纠正才报告给高层领导，到那时，公司领导就根本不可能有什么解决问题的办法了。最后，项目经理就要承担所有的后果。

五、项目管理软件

在软件项目开发过程中项目经理要多利用一些项目管理软件来辅助项目的管理，这样可以提高项目的管理水平，增强计划的可执行性，提高资源的有效配置，加强成本管理，提高企业的竞争能力。在实际工作中，我们主要利用项目管理软件来实现如下功能：

1．成本预算和控制

输入任务、工期，并把资源的使用成本、所用材料的造价、人员工资等一次性分配到各任务包，即可得到该项目的完整成本预算。在项目实施过程中，可随时对单个资源或整个项目的实际成本及预算成本进行分析、比较。

2．制定计划、资源管理及排定任务日程

用户对每项任务排定起始日期、预计工期、明确各任务的先后顺序以及可使用的资源。软件根据任务信息和资源信息排定项目日程，并随任务和资源的修改而调整日程。

3．监督和跟踪项目

大多数软件都可以跟踪多种活动，如任务的完成情况、费用、消耗的资源、工作分配等。通常的做法是用户定义一个基准计划，在实际执行过程中，根据输入当前资源的使用状况或工程的完成情况，自动产生多种报表和图表，如“资源使用状况”表、“任务分配状况”表、进度图表等。还可以对自定义时间段进行跟踪。

4．报表生成与人工相比，项目管理软件的一个突出功能是能在许多数据资料的基础上，快速、简便地生成多种报表和图表，如甘特图、网络图、资源图表、日历等。

5．方便的资料交换手段

项目管理软件还可以通过电子邮件发送项目信息，项目人员通过电子邮件获取信息，如最新的项目计划、当前任务完成情况以及各种工作报表。

篇3：软件开发项目管理浅析

一、软件项目计划

软件项目计划是一个软件项目进入系统实施的启动阶段, 主要进行的工作包括:确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。

软件项目管理过程从项目计划活动开始, 而第一项计划活动就是估算:需要多长时间、需要多少工作量以及需要多少人员。此外, 还必须估算所需要的资源 (硬件及软件) 和可能涉及到的风险。根据项目的规模可以估算出完成项目所需的工作量, 可以使用一种或多种技术进行估算, 这些技术主要分为两大类:功能分解技术和经验技术。分解技术需要划分出主要的软件功能, 接着估算实现每一个功能所需的程序规模或人、月数。经验技术的使用是根据经验导出的公式来预测工作量和时间。

二、软件项目管理的组织模式

软件项目可以是一个单独的开发项目, 也可以与产品项目组成一个完整的软件产品项目。实行项目管理时, 首先要成立项目领导小组, 项目领导小组下设项目管理小组、项目评审小组和软件开发项目组。

(一) 项目领导小组

项目领导小组是公司项目管理的最高决策机构, 一般由公司总经理、副总经理组成。主要职责如下:

1. 审核批准项目的总体方案, 工程实施计划。

2. 负责项目实施过程中的重大事件的决策。

3. 根据项目过程中的进度、质量、技术、资源、风险等实行宏观监控。

4. 负责组建验收小组, 主持验收工作。

5. 协调涉及与系统建设中有关的各方工作关系。

(二) 项目管理小组

项目管理小组对项目领导小组负责, 一般由项目负责人 (项目经理) 及相关人员组成。主要职责如下:

1. 根据项目进展及工作要求制定工作计划, 并监督实施, 控制进度。

2. 协调项目组内人员的分工合作, 资源分配。

3. 确保项目的质量和过程符合软件开发的规范。

4. 召集并主持各阶段的评审工作。

5. 负责制定阶段工作完成验收标准和最终验收标准, 报领导小组审批。

(三) 软件开发项目组

软件开发项目组对项目领导小组负责, 成员一般由公司技术人员和专业开发商开发人员构成。主要职责是:

1. 系统需求调研。

2. 系统设计。

3. 程序编码。

4. 系统测试。

5. 建立开发及测试环境 (系统硬件, 软件, 网络配置等) 。

6. 准备测试数据。

7. 安装生产系统。

(四) 项目评审小组

项目评审小组对项目领导小组负责, 一般由公司技术专家和市场专家组成。主要职责如下:

1. 对项目可行性报告进行评审。

2. 对开发计划和阶段报告进行评审。

3. 项目结束时, 对项目总结报告进行评审。

三、软件项目管理的内容

从软件工程的角度讲, 软件开发主要分为六个阶段:需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、系统上线及维护阶段。

(一) 需求分析阶段。

需求分析阶段是整个项目开发的起点, 其任务是通过详细调查用户的实际要求, 在此基础上确定项目开发的功能点。本阶段需要形成文档:《项目需求规格说明书》。

(二) 概要设计阶段。

概要设计的内容包括:开发目标及环境、系统框架设计、接口设计、数据结构设计、功能模块设计。阶段文档:《概要设计说明书》

(三) 详细设计阶段。

详细设计是在概要设计的基础上, 为每个功能模块进行详细的算法设计, 对数据结构进行物理设计, 即确定数据库的物理结构, 以此作为软件开发人员进行编码开发的基础。阶段文档:《详细设计说明书》

(四) 编码阶段。

编码阶段是软件开发的实质性阶段, 是将详细设计中的算法转化为代码的过程。因为每个开发人员的编码习惯和风格都有所不同, 因此在开发之前确定一套编码规范是非常有必要的。

(五) 测试阶段。

所谓测试就是用已知的输入在已知环境中动态地执行系统 (或系统的部件) 。测试阶段一般包括单元测试、模块测试、集成测试和系统测试。测试过程中将产生下述基本文档:

1.《项目测试计划》:确定测试范围、方法、和需要的资源等。

2.《项目测试报告》:详细描述和每个测试方案有关的测试步骤和数据 (包括测试数据及预期的结果)

(六) 系统上线及维护阶段。

系统上线前要编写《系统上线计划书》, 对上线时间、上线步骤、环境准备、风险评估、应急方案制定等方面做详细说明, 尽量估计可能出现的情况并作出处理预案, 才能保证系统成功上线投入生产运行。

维护阶段包含两项内容, 一是系统运行中出现问题的处理, 这也是常见的维护内容;另一项内容是对原有功能模块进行修改或功能扩展。

四、项目评审

项目评审并不是在项目开发完毕后进行评审, 而是在项目开发的各个阶段都要进行评审。因为在项目开发的各个阶段都可能产生错误, 如果这些错误不及时发现并纠正, 会不断地扩大, 最后可能导致整个项目的失败。

项目评审各项标准:

正确性:在预定环境下能正确地完成预期功能的程度。

健壮性:在硬件发生故障、输入的数据无效或操作错误等意外环境下, 系统能做出适当响应的程度。

效率:为了完成预定的功能, 系统消耗资源的多少。

安全性:对未经授权的人使用系统或操作数据的企图, 系统能过控制 (禁止) 的程度。

可用性:系统在完成预定应该完成的功能时令人满意的程度。

风险:按预定的成本和进度把系统开发出来, 并且为用户所满意的概率。

可理解性:理解和使用该系统的容易程度。

可维护性:诊断和改正在运行现场发现的错误所需要的工作量的大小。

灵活性:修改或改进正在运行的系统需要的工作量的多少。

可测试性:系统容易测试的程度。

可移植性:把程序从一种硬件配置和 (或) 软件系统环境转移到另一种配置和环境时, 需要的工作量多少。

可再用性:在其他应用中该程序可以被再次使用的程度 (或范围) 。

互运行性:把该系统和另一个系统结合起来需要的工作量的多少。

五、结语

篇4：软件开发项目质量管理措施探讨

关键词：软件开发;质量管理;措施

一、软件开发项目质量管理的原则及必要性

（一）软件开发项目质量管理的原则。在我国企业发展的过程中，对软件的依赖程度越来越高，由此也促使企业对软件质量的要求逐渐提升。软件企业在开发软件的过程中，已经充分的认识到了软件质量的重要性，因此，在进行软件开发时，会严格的按照相关的原则来进行，进而有效的保证质量要求。一般来说，软件开发时应该遵循的原则主要包含三点：第一，尊重客户需求原则，软件开发的目的就是为了满足客户的需求，因此，这是最基本的原则，同时，在与客户合作的过程中，要以互利为基础，将质量管理贯彻到软件开发过程的始终;第二，建立完善的质量管理体系原则，质量管理并不单单针对某一个软件开发项目，而是包含所有，因此，通过质量管理体系的构建，保证软件开发项目均具备较高的质量，实现良性循环;第三，重视软件开发团队精神原则，软件开发团队是软件开发项目顺利实施的保障，当团队精神比较好时，软件开发项目的质量就会比较高，因此，在进行质量管理时，必须要重视团队精神。

（二）软件开发项目质量管理的必要性。现如今，我国的软件开发行业已经发展的比较繁荣，软件开发技术也已经发展的比较成熟，软件开发行业属于知识密集型的行业，软件开发人员所具备的智力水平、知识水平都比较高，在进行软件开发的过程中，影响因素比较多，这都会在不同程度上影响软件的质量，由此，质量的保证就是一个比较困难的问题。如果前期开发的软件质量比较差，那么在投入使用之后，后期的维护、运营等成本都会增加，同时，还存在着安全隐患，甚至会带来不可预估的影响，基于此，软件开发项目的质量管理工作十分的重要。

二、软件开发项目质量管理措施

（一）对项目的过程进行合适的定义。软件开发项目的过程并不单单指软件产品的开发，还包含软件产品的维护。随着企业现代化的发展，企业管理中特别重视过程管理工作，通过过程管理，有效的提升了管理的效果和水平。企业在实行过程管理时，会受到外部环境或者组织模式变化的影响。基于此，软件开发项目过程的顺利实施，就需要利用过程管理的思想来保证，根据项目的实际情况，结合企业的发展，优化软件开发流程，同时保证软件开发的功能能够满足客户的需求。对于每一个设计阶段，都需要对其计入和退出条件进行明确的定义，进而有效的开展质量管理，提升软件开发的质量。

（二） 明确项目需求。所谓项目需求，就是指客户的需求，当客户需求非常明确时，软件开发项目所具备的成功率就会比较高，相反，成功难度就比较大。在实际的软件开发过程中，经常会发生用户需求改变的情况，从而对软件项目开发产生比较严重的影响。鉴于此项问题的存在，项目需求的明确是在软件开发之前所必须要进行的管理工作，首先，在与客户进行沟通时，应将客户的需求明确、详尽的填写在说明书中，避免开发人员误解行为的出现;其次，当客户的需求发生变化时，开发人员要与客户及时的进行沟通，并保证沟通的有效性，从而保证软件开发的顺利进行;最后，当用户的需求存在不明确的地方时，采取暂缓开发的政策，同时尽早的对这部分的需求进行明确。

（三）代码走查。软件开发周期比较长，在开发的过程中，会由多个开发人员同时进行，对于自身所负责的开发部分，开发人员要在每周固定的时间讲解代码，这样一来，开发人员可以对自己代码的质量有所了解，并根据他人的意见和建议优化自己的代码，提升软件开发的质量。

（四）对软件产品进行检测。在对软件产品进行检测时，主要包含两种检测，一种是集成检测，一种是系统检测，检测的主要内容有功能、安全性、用户界面、安装等，一般来说，在进行测试时，需要软件产品在模拟环境中运行，通过检测，保证软件产品无任何的缺陷。

结论：对于软件产品来说，质量是非常重要的，因此，在进行软件开发时，就需要进行质量管理。在对软件开发项目进行质量管理时，应该保证整个过程的管理，同时，质量管理工作还需要在充分满足客户需求的基础上来进行，通过检测、代码走查等手段，保证软件开发项目的质量，从而有效地开发出高质量的软件产品。

参考文献：

[1] 张成功.基于CMMI的软件开发质量管理问题研究[J].信息通信，2015，10（03）：154.

篇5：软件项目开发管理流程

1，新项目开发管理流程

按照项目管理规范，项目管理分为：项目启动—》项目计划—》项目执行—》项目控制—》项目结尾。5个阶段。根据该管理流程和我公司实际情况，将新项目开发的管理流程制定如下图：

1.1 项目立项

项目立项阶段，首先由的项目经理编写《项目立项报告》。

研发项目立项报告模板.doc

1.2 立项评审

《项目立项报告》编写完成后，交由项目管理委员会进行立项评审，评审通过后由副总经理签字确认立项。确定需求分析和项目设计阶段的时间和人员安排。

1.3 需求分析

需求分析阶段，需要与用户交流，双方对软件需求取得共同理解基础上达成的协议。编写并完成软件需求说明书：也称软件规格说明书。

软件需求说明书模板.doc

1.4 系统设计阶段

常规的系统设计需要依次完成《概要设计说明书》，《详细设计说明书》。以下是文档的简要说明：

概要设计说明书：该说 明书是概要设计阶段的工作 成果，它应说明功能分配、模 块划分、程序的总体结构、输 入输出以及接口设计、运行设 计、数据结构设计和出错处理 设计等，为详细设计奠定基础。

概要设计说明书.doc

详细设计说明书：着重 描述每一模块是怎样实现的，包括实现算法、逻辑流程等。详细设计说明书.doc

详细设计说明书编写完成后，项目经理应该依次编写安排项目开发工作计划。工作计划安排可以根据项目经理的习惯进行工作计划编写。建议采用project。附件为综合考务平台的工作计划安排，可以供参考：

考试考务综合管理平台工作计划.mpp。并且确定里程碑，以便在后期项目执行过程中，对其进行确认。对于大项目，建议按照项目设计流程，先进行概要设计，再到详细设计。但是对于特殊项目（项目周期较短，小项目），可以讲概要设计和详细设计阶段合二为一，编写功能，接口方案。但是值得注意的是，该方案中，仍然需要涵盖项目模块功能，用户权限和各模块实现逻辑，接口等。

项目设计开发方案.docx。

1.5 项目设计评审

设计阶段完成后，项目经理填写《项目设计评审表》，将相关文档交由项目管理委员会进行项目设计评审。通过评审后，方可进行编码工作。

项目设计评审表.docx

1.6 编码和测试用例编写阶段

项目编码阶段，项目经理需要对项目执行情况进行控制和监督，其中包括（项目输入，项目输出，里程碑）。如果由于特殊情况，如：需求变化，人员临时调配，或者其他原因导致的项目范围和时间，计划等变更，项目经理应该及时填写变更申请。并提交给项目管理委员会。作为之后项目输出验证的重要依据项目变更申请书.doc。

在此阶段，测试人员应该根据《需求说明书》，《概要设计》和《详细设计说明书》的内容，编写相应的《测试用例》。1.7 测试阶段

编码完成后，应该移交测试组进行相关测试工作。按照测试流程，需要提交《测试申请表》。测试人员在接收到《测试申请》后，应该与研发人员讨论《测试用例》的相关内容，确定测试时间，开始程序测试。并在测试工作完成后，编写对应的《测试报告》。

1.8 结项评审与验证

项目负责人和测试负责人分别填写《项目结项评审表》，交由项目管理委员会进行评审。评审通过后，由研发中心副总经理进行发布确认。

项目结项评审验证表.doc

1.9 新产品发布

编写《用户手册》。方可进行新产品发布。

2，旧项目升级开发管理流程

旧项目的升级，依照如下流程：

2.1项目升级需求分析

项目需求分析，需要收集用户在产品使用过程中，已经技术人员在调试过程中的反馈作为需求分析的输入。并填写对应的项目升级需求报告表。项目升级需求报告表.doc

2.2 升级评审

将《升级需求报告》交由项目管理委员会，评审通过后，进行升级设计。2.2项目升级设计

项目负责人，根据需求报告和升级具体情况，编写升级开发方案。项目升级开发方案.docx。并安排整改工作计划。

2.3 项目升级设计评审

升级开发方案完成后，填写《项目设计评审表》，交由项目管理委员会评审。

2.4 编码

按照项目升级开发方案进行编码设计，如果编码工作中，发生特殊情况需要变更计划，或者项目范围等，同样需要提交《变更申请》，作为项目验证的基础。同样，此阶段，测试人员应该编写或者修改相关测试用例。

2.5 测试

编码完成后，应该移交测试组进行相关测试工作。按照测试流程，需要提交《测试申请表》。测试人员在接收到测试申请后，应该与研发人员讨论《测试用例》的相关内容，确定测试时间，开始程序测试。并在测试工作完成后，编写对应的《测试报告》。

2.6 升级输出评审

篇6：软件开发项目进度管理研究论文

软件开发项目具有需求不确定性、时间期限严格等特点，由此决定了软件开发项目进度管理非常必要，但同时也存在着一定的难度。重点对软件开发项目进度管理进行分析研究，明确软件开发项目进度管理的4个主要步骤：根据项目目标和现有资源，进行项目工作分解;在项目工作分解结构图的基础上，确认项目活动，用科学的方法估算活动时间并排序;编制项目进度计划和进度管理计划;在项目实施过程中，对项目进度进行跟踪和监控并定期评估，必要时需根据实际情况按一定规则，变更项目进度计划。

0引言

软件开发项目进度，是指完成整个软件开发项目所需活动的过程和时间周期。软件开发项目进度管理是为了确保项目按时完成而对其各项活动及阶段进行的管理。软件开发项目进度管理包括4个步骤，其中软件开发项目进度计划编制和进度控制是实际工作重点，但编制项目进度计划前，应先分解项目，明确该项目包含的活动，并对项目活动进行排序[1]。下文中“软件开发项目”简称为“项目”。

1项目工作分解

一个项目提出后，根据项目目标确定项目的研究范围后，应对项目进行分解，将可交付成果和复杂的项目逐步分解成较小的、便于管理的组成部分，并创建工作分解结构图，为项目进度计划打下基础[2]。

1.1项目工作分解的作用

项目分解的作用主要体现在两个方面：

(1)便于进行综合性方案设计。工作分解就是在项目目标的指导下，在任务范围中从粗到细、从简到繁，逐步分析，直到可执行的最小独立单元，这样能够较好地保持项目的系统性和完整性，策划者据此可以通盘考虑实现项目目标应完成的工作，能够清晰地分辨任务实现的重点和步骤、完成周期、成本费用，并评估风险，同时，也有利于发现潜在的不明确内容，为项目总体设计提供可靠依据。

(2)便于分配任务和明确责任。项目工作分解把项目划分成多个独立性较强的任务单元，明确区分各任务的目标、范围和界限，对每个工作任务提出具体要求，便于在执行项目时，落实责任者或完成单位。既可以作为委托工作或下达任务的依据，也便于观察、了解和控制整个项目过程。

1.2项目工作分解结构的依据、原则和方法

项目工作分解结构的主要依据是前期取得的项目主要资料和其它相关项目的借鉴性文件，包括项目需求文件、任务(合同)范围说明、本项目的其它资料、其它项目的相关资料等。

工作分解结构的原则是：在各层次上保持项目内容的完整性，不能遗漏任务必要的组成部分;每个项目单元只能从属于某一个上层单元，不能同时交叉从属于两个上层单元;相同层次的项目单元应有相同的性质，各项目单元应有明确的任务界限，保持各项目单元的独立性;项目分解的原则应事先确定，同一层次上分解出的项目单元，其分解的原则应该是一致的。

工作分解的方法有自上而下和自下而上等方法。自上而下法是先明确项目最终产品，然后确定中间可交付成果，再对主要可交付成果细分，直至每一个工作只包含一个可交付成果;自下而上法是首先明确项目的所有可交付成果，然后将可交付成果进行逻辑分组，接着将每组汇总成一个母元素，成为上一层次的元素，再将高一层次的元素进行分组、汇总，以此类推，最终汇成一个母元素。

1.3项目工作分解结构一般步骤

工作分解首先应识别项目的主要要素，项目的主要要素就是项目的主要交付物，然后对识别出的主要要素作进一步细化，分解出更详细的有形的、可检验的产品或服务，在此基础上，选择自上而下或自下而上的方法编制工作分解结构图(也可以使用单位标准模板或以前项目的模板)，编制完工作分解结构图后，应编制详细的结构图说明，说明的内容包括各要素的界定、说明、估算经费、时间、预安排的责任部门、人员等。

1.4项目工作分解结构输出

项目工作分解的输出结果包括项目结构图和相关说明。项目分解结构图(WBS)是通过分解技术，将项目任务按照其内在性质和结构逐层细化而形成的示意图。它涵盖为完成项目交付物需进行的所有项目工作，为项目责任分配和任务协调提供依据。项目结构说明包括各层要素的详细描述、工作说明、负责组织、进度日期、成本预算等。

2项目活动确认及排序

完成项目工作分解后，应对所确定的可交付成果的具体活动进行分析确认和排序，为编制项目计划打基础。

2.1项目活动确认

依据项目工作分解结构的成果、其它关于项目范围的说明性文件、项目约束条件、项目的假设前提、管理计划和单位的历史信息等[3]确认项目活动。对于一些小项目，可通过大家集体研究讨论，集思广益的方法，形成可行的活动清单并估算所需时间，对于较大、较复杂的项目，则需要由相应领域专家研讨或使用一定的工具和方法来确认项目活动，这些方法包括：进一步使用活动分解技术、采用已有模板法、领域专家判断法等。项目活动确认后，形成的结果包括：涵盖项目所有必要活动的项目活动清单、描述项目过程中基本关键点的项目里程碑图等，此外，还应适时更新项目工作分解结构图和项目总体管理计划。

2.2项目活动排序

确认了项目活动，要识别各项活动的相互关系，项目活动之间的关系也称为项目活动之间的先后信赖关系，包括人们无法改变的硬逻辑关系和需由各种因素综合确定的软逻辑关系，在项目活动排序时，要根据项目活动清单、项目里程碑和一些约束条件，先识别并安排硬逻辑关系，再安排软逻辑关系，同时要考虑项目假设条件和外部条件的影响。项目排序图的编制方法可以采用节点图法或箭线图法。项目排序的最终结果，是描述项目各项活动相互关系的项目网络图及其活动说明，项目网络图应包括项目的主要活动和情况，并明确各活动之间的逻辑关系或依赖关系，在网络图的说明中，应描述活动排序的基本方法，对于特殊的排序应进行说明。

2.3项目时间估算

项目时间估算是指根据项目范围、资源及相关信息，对项目已标识的各活动持续时间所进行的估计。大多数项目活动时间的长短，取决于人力、物力、财力及资源的多少，同时还受人的能力、物资质量和设备效率的影响。对项目活动时间进行估算时，即要考虑各活动所消耗的实际工作时间，也要考虑活动的延迟时间。因此，一般由熟悉项目活动或有经验的人员或团队，采用专家判断法、类比估算法或模拟估算法完成。

3项目进度计划编制

编制项目进度计划，是综合分析项目活动排序、持续时间、资源需求和进度约束，确定每一个项目活动及整个项目起始和完成日期，建立一个相对科学可行的项目进度计划的过程。编制项目进度计划是一个迭代过程，需要运用科学的计划方法，将时间、经费、人员、设备及各种资源作统筹安排，还要与其它相关项目协调一致。

3.1编制依据

编制项目进度计划的依据包括：项目活动排序后得到的项目网络图、项目活动估算得到的时间值、现有的和能取得的资源、项目时限和重要里程碑、项目约束条件以及其它风险和假设前提。

3.2编制方法

根据不同项目的具体情况采用不同的方法，本文重点介绍编制项目进度计划的3种方法。

(1)甘特图法。甘特图又称横道图或条形图，它是通过赋予时间以含义的横道图形式，列出项目活动工期及其相应的开始和结束时间，以反映项目进度信息的一种可视化计划方法。甘特图左侧列出项目活动和工期，顶部列出时间，横道长短代表活动持续时间长短。甘特图的`优点是简单、明了、直观、易于绘制，缺点是不能系统地将项目各项活动之间的逻辑关系表示出来，也不能进行定量分析和计算，更不能指出影响项目的关键所在。

(2)关键路线法。关键路线法也是通过横道图以日历形式列出项目活动、工期、相应的开始结束时间来进行规划。它与甘特图的不同之处在于，它运用特定的、有顺序的网络逻辑方法来预测总体项目历时，是一种数字分析技术。关键路线法的重要功能是确定项目的关键工作和关键路线，关键路线的确定是将项目网络图中每一条路径上的所有项目活动的历时分别相加，最长的那条路径就是关键路线。

(3)计划评审技术。计划评审技术是指当项目或项目某些活动历时估算存在不确定性时，运用加权平均历时估算法，来估算项目历时的网络分析技术。这种技术适用于不可预知因素较多，或从未做过的新项目或复杂项目。计划评审技术网络图的画法与一般网络图画法相同，不同之处在于对项目活动时间的估计和分析[4]。

3.3编制结果

编制项目进度计划的主要成果用表格或图表形式呈现，项目各项活动都标明了各种日期参数的项目进度计划文档。此外，还应包括进度管理计划，用以明确项目进度计划发生变化时的处理原则。

4项目进度控制

项目进度控制是进度管理的重要内容和过程，是前期一系列进度计划工作的延伸，是进度管理中与实施并行的实践性关键阶段。

4.1进度控制依据

项目进度计划是经过论证和批准的，在技术和资源上具有可行性，所以是项目进度控制的主要依据。通过项目跟踪监测和沟通形成的有关项目进度的绩效报告、根据项目进展情况提出的变更请求、编制进度计划时形成的进度管理计划，也都是进行项目进度控制的依据。

4.2进度控制主要工作

控制项目进度的主要工作是：依据作为项目进度基准的项目进度计划，通过跟踪监测和沟通，采用一定的工具和方法进行分析比较，确定项目进度是否发生了变化，如果发生了变化，找出变化的原因，对影响变化的因素进行控制或制定项目进度的补充计划，从而确保进度变化朝着有利于项目目标实现的方向发展[5]。控制项目进度还可以借助项目管理软件来实现。

4.3进度控制结果

篇7：软件开发项目管理实施方案.

作为一个项目管理者,如何要成功的做好项目管理;首先必须先要明白的是在特定的领域中赋予这个角色所要实现的目标、承担的职责、以及项目管理者的具体工作内容是什么? 从我个人的浅见和角度以及我们所从事的IT领域来分析回答以上三个问题。第一:目标

作为一个项目的管理者,必须要明确的知道自己的工作目标;我个人认为项目管理者的目标无非就是以下两点:

1、就是清晰明确地了解项目利害关系者的需求和期望,努力做到满足项目利害关系者的不同需求;项目利害关系者包括:项目团队成员和项目团队外成员(比如各部门的部门负责人和市场人员,客户等。

2、就是保证开发项目按需按时保质的完成。第二:职责

作为项目的管理者,首先要端正态度,要明确知道自己的工作职责,认识到这份工作职责的本质。项目管理者不是来管人的,而是来支持人的,是来协调资源的,是来营造一个适合团队成员比较认同的工作环境和氛围的,是来为一个共同的目标和大家一起战斗共同成长的。可以大概概括成以下几点:

1、建立有效的工作流程保证项目的顺利进行。

2、制定详细周密的项目计划。

3、跟踪,推动项目按计划进行。

4、积极解决项目过程中出现的问题和冲突。

5、调动开发团队的积极性,创造力,推动团队成员在项目过程中不断成长。

6、项目风险识别、风险评估、风险解决和风险管理策略以及做好突发风险的应急预案。

7、实现目标

第三:项目管理者的具体工作内容

最后一个是项目管理者的具体工作内容,作为项目管理者必须清晰的知道自己的工作范围和所要做的工作内容以及工作重心,分为以下六点:

1、项目前期阶段

对项目进行技术可行性分析、技术评估、成本评估以及风险评估。与需求提出方的代表进行需求讨论,明确项目的目标、价值;确定项目范围、功能及优先级。组建项目团队,特别要搞清楚项目的key person(对产品有决定权的人。项目启动会议,相关的

利害关系人员都必须参加。

该阶段完成后的成果:确认后的最终软件需求规格说明书文档。

2、分析设计阶段

根据确认后的软件需求规格说明书,制定项目进度计划,工作任务分解(WBS;资源申请,项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源;数据库设计;系统设计;文档(包括Use Case、Demo系统原型、Test Case等;评审会议。

该阶段完成后的成果: A、User Case(系统用例;B、DEMO(系统原型;

C、系统设计文档(概要设计和详细设计;D、数据库设计文档。

最后对完成的成果,包括User Case和设计文档等进行评审。

3、执行阶段(开发和测试

准备开发环境、测试环境;跟踪,推动项目按计划进行;以周报的形式通报项目的进展情况。对项目的阶段成果进行评估,以确保该阶段完成的质量,包括代码审核、SQL 审核等。对需求变更进行控制管理;对项目风险进行管理;测试阶段BUG FIXED及改进、收集反馈意见。

4、发布阶段

包括制定项目发布计划,用户培训,发布上线。

5、上线后监控

数据监控(日志、服务器状态,根据监控出现的问题,及时进行BUG FIXED及改进或做补丁升级。

6、结束阶段

产品交付,项目总结会。

第四:基于以上三个问题所做的应对细则

要做好项目管理,并能确实解决好以上三个问题,实现目标、履行职责、完成工作中的具体内容,从我个人这几年的工作经验和面临的一些问题,还有所积累的一些项目管理中的

一些知识以及自己的观察和思考的角度看,应该要努力做好以下这几个方面的具体工作:

1、项目开发时间的估算

制定项目进度时间表的时候,需要估算每个任务所需的时间,其中开发任务中模块的分配和时间估算是其中最主要的部分;在分配模块和估算开发时间时需要遵循的原则和目标:

1、保证项目整体的进度。

2、有助于确保开发编码的质量。

3、有助于提高开发编码的速度。

在公司现有的技术框架下,开发人员主要的工作是投入在具体的商业逻辑上。通常每个模块所需的开发时间取决于以下三个因素:

1、所负责模块的商业逻辑的复杂程度。

2、开发人员的技术水平和对项目所在应用的熟悉程度(包括对框架和应用的熟悉程度。

3、该模块技术实现上是否有技术难点;这里所谓的技术难点定义是:在现有系统中还未实现的、开发人员自身也未没接触过的技术。对于这样的难点,开发者没有相关的代码可以参考,自己也没有经验,所以需要投入一些时间研究解决。

模块分配和开发时间估算的步骤:

1、在划分好模块后,首先自己先估算一下每个模块所需要的开发时间。

2、然后召集所有开发人员,讨论模块的分配和开发时间估算。将划分好的模块,让开发人员从中挑选他们感兴趣的模块。这样做可以提高开发人员的主动性和参与性。在分配模块的时候还需从以下几方面考虑,以确保开发的速度和质量: A、相同类似的模块由同一人负责开发,比如用户管理的增删改由同一开发者负责。

这样做的好处就是开发者对相关逻辑会更加熟悉,同时接口的定义也会比较明确,沟通的成本比较低,同时功能实现的缺陷也相应的会降低。

B、技术难度比较大的模块由技术水平比较高的人负责。C、业务逻辑比较复杂的由对这块逻辑比较了解的人负责。

3、模块分配完后,开发人员评估自己负责开发的模块所需要的时间。在此过程中最好做到要和开发者比较详细的讨论每个模块的技术实现,以便使时间的估算更加准确。

4、对开发人员估算的时间进行确认。在确认过程中作为项目管理者应参考以上提到的三个因素,同时将自己估算的时间和开发人员估算的时间进行比较。这其中的差异当然会存在的。对于那些差异比较大的,将与技术人员探讨其中的缘由。对于时间周期比较长的任务,尽量将任务通过再细分的手段细化任务,争取每个任务的最长时间不超过3天;时间周期越长的任务,不确定性越高,风险也越高,越有可能成为项目的瓶颈,影响项目的进度。

2、Code Review Code Review是保证项目中代码质量非常重要的一个环节,在这一环中我们公司做的非常欠缺,把关不严格;这是导致每次测试后出现大量bug的主要原因,这一环需要纳入绩效考核中,实行责任追究制,实施重点监控。出现这样的薄弱环节,造成这样的原因,我想也是有很多因素造成的;比如开发人员对需求不是很明确,以自己比较主观的因素去完成任务的;还有对整个系统业务逻辑没有正确的清晰的认识的原因,以及对项目组成员培训不到位的原因等众多因素纠集在一起才产生的。

如何做好这方面的工作?首先编码要有“编码规范”文档,Code Review要有“代码审

核规范”文档:记录代码实现应该遵循的标准。通过这两个文档来规范开发人员的代码实现,代码编写者必须要严格按照规范来进行;代码审核者根据这些标准来Code Review代码,同时在Code Review过程中不断完善该文档。

在做好这些前期工作的前提下,分以下几个步骤来实施:

1、检查开发者的代码实现是否遵循了编码规范。

2、从代码的易维护性、可扩展性角度考察代码的质量,提出修改建议。

3、代码编写者和代码审核者坐在一起,由代码编写者按照Use Case依次讲解自己负责 的代码和相关逻辑,从Web层-到Manage层再到Dao层;

4、代码审核者在此过程中可以随时提出自己的疑问,同时积极发现隐藏的bug;对这

些bug记录在案。

5、代码讲解完毕后,代码审核者给自己安排几个小时再对代码审核一遍。代码需要一

行一行静下心来看。同时代码又要全面的看,以确保代码整体上设计优良。

6、代码审核者根据审核的结果编写“代码审核报告”,“审核报告”中记录发现的问题

及修改建议,然后把“审核报告”发送给相关人员。

7、代码编写者根据“代码审核报告”给出的修改意见,修改好代码,有不清楚的地方

可积极向代码审核者提出。

8、代码编写者bug fixed完毕之后给出反馈。

9、代码审核者把Code Review中发现的有价值的问题更新到“代码审核规范”的文档中, 对于特别值得提醒的问题可群发email给所有技术人员。如果通过以上步骤,还因为是代码编写者的原因而出现严重的缺陷问题,将通过绩效考核来加深代码编写者的印象,并在周报会议上做通报批评。

3、需求变更管理

需求变更管理也是项目管理中最重要的一个环节,对需求变更管理的有效性将直接影响项目的成功与否。

对待需求变更的态度:

1、需求变更是不可避免的。

2、需求变更要必须被管理。

3、积极发现引起变更的因素,促使变更尽可能早的出现,减低变更带来的风险。需求变更管理的目标:

1、相关的干系人必须清楚地了解发生的变更。

2、变更处于有效的管理中。

3、尽量降低变更带来的风险。

通过制定需求变更的流程,确保项目中的需求变更有效地进行,实现上述的目标。需求变更流程:

1、确定需求的基准线。将以User Case作为需求基准线,在User Case确认之后的任何需求改变,都需要走需求变更流程,这一环节我们基本没有,期间有时候使的工

作很混乱,也就是因为没有一个规范的变更流程而造成的;如果建立了这么一个流程规范和机制,需求变更没有走这个流程的将不被认可。

2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。

3、项目管理者评估该需求变更。针对接收到的需求变更的要求,召集相关人员讨论该需求变更的合理性、可行性,实施的代价以及对项目的影响。包括可能影响的项目范围,进

度,费用,质量等计划。项目管理者作为项目的负责人,对项目的成功与否负有主要的责任。所以需求变更的决策者应该由项目管理者承担。

4、需求变更确认后由专人将需求变更记录下来,通知给项目中所有成员。其中以下人员对需求的变更是紧密相关的,他们必须知晓并认可此需求变更。包括(客户方,需求分析人员,测试人员,相关开发人员。需求变更记录格式如下: 序号变更提出时间变更描述变更类型(是 对原有需求 的修改还是 新增需求 原因变更提出 者

开发人员对进度的 影响(工 作量 2

5、确定变更的负责人。承担需求变更的具体工作,比如基线控制,对需求变更的记录,并通知相关人员。

6、相关人员接收到确认的需求变更后,做以下事情。需求分析人员修改需求说明书和User Case的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部分。

7、按照变更后的计划实施项目,并进行检查,跟踪,对变更后的实施反馈和可能出现的问题及时沟通和处理。

8、需求冻结。项目越到后期,需求变更对项目的影响就越大,所以在一定时候要进入需求冻结阶段,不再接收新需求或需求的变更。

4、风险管理

风险管理是项目管理者最重要的工作之一。风险管理是一个持续的过程,贯穿于整个项目过程中,风险管理包括风险识别、风险评估、风险解决以及风险管理策略。

在项目的实施过程中需要不断地识别和应对风险,并加以有效的控制,风险管理的好与坏直接影响项目的实施效果,从某种意义上讲,项目实施对于项目管理者就是识别、分析、应对、控制风险的过程,使项目的约束性目标和质量目标朝有利的方向发展。

项目不同于日常任务,它有明确的起止时间和目标,要在明确的范围、时间和成本约束下,达到相应的质量标准,并取得用户的满意。影响项目成败的因素涉及方方面面,并且风险伴随着项目的始终,是客观存在的,作为一个项目管理者,应该具备良好的风险控制意识,善于识别风险并分析风险的影响,从中发现影响目标的风险点,并施

加影响或采取应对措施,把风险的负面影响降到最低,并且风险控制应该贯穿项目始终。

风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面,导致这些问题的因素主要包括目标以及需求不明确、范围蔓延以及需求变更、代码质量或返工风险、人员技能和资源的不足、缺乏良好的团队协作等。下面将详细描述一下这些问题以及出现这些问题时的应对方案:

1、目标以及需求不明确

为了市场竞争或内部管理决策的需要,业务部门提出的需求往往要求的时间比较紧迫,需求的提出大多停留在几张纸或口头的传达上,没有形成正式的业务需求文档,在没有明确的需求范围的情况下,有时为了迎合业务部门的口味匆匆开工,过程中用户不断地提出新的想法,技术人员开始疲于奔命和应付,很难保证项目的进度和质量,也难以取得业务部门的认可。所以,在项目的前期一定要采取相应的手段或措施,与业务部门共同明确项目目标、需求范围,充分考虑现有的时间和资源约束,将需求排定优先级, 对于关键的需求优先实现，其他辅助性的根据过程中的具体情况进行滚动式计划，并取 得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统 原型等手段让用户在前期充分暴露自己的想法和需求。

2、范围蔓延以及需求变更 在有了明确的目标和需求范围的情况下，需求的变更还是不可避免的，业务部门在 看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控 制，新的需求的加入通常会影响已实现的需求，并且对项目进度和成本产生很大的影响。项目管理者针对这种情况一定要采取严格的变更控制流程，不能碍于面子，否则最终的 结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相 关团队成员进行分析及评估，作为是否实施的依据，变更控制负责人根据分析结果判断 是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求，当然实际 情况下可以采取一些软措施缓解矛盾。需求变更风险：需求已经打上了基线，但此后仍然有变更

发生，对项目造成影响。如何减少此类风险的发生？ 前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户，所有的需求要经 过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确 认、User Case 确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变 更时，严格按照需求变更流程执行。在分析设计阶段的中的确认和评审也是降低此类风 险的重要手段。

3、代码质量或返工风险 质量风险主要指开发代码的质量。如何提高开发人员开发的质量？在制定项目计划 时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响也很大。有 时开发人员为了赶进度在比较紧张的时间需要完成指定的任务，可能就存在很大的开发 质量问题。开发要有一套严格可行的代码规范，编码时严格遵守，到现在为止，我们这 个方面做的不是很规范，做的也很不足，大家编写的代码随意性比较大，代码编写者的 主观意识性比较强。要建立一套大家认可并且规范可行的编码规范和考核规范，code review 时严格考核。在编码前，开发人员要对框架熟练掌握；一份好的系统设计文档对 指导开发非常重要。返工是项目组最不愿意看到的，既浪费人力、物力和财力，又影响团队积极性。需 求不明确或范围没有有效控制都可能造成返工，另外造成返工的原因是质量没有达到用 户要求。往往有这样一种情况，每个团队成员按照项目计划报告进度都是 100%完成，但一到最后系统交互测试或集成的时候就会发现一大堆问题，不得不花费很大精力回头 排查、修改程序，造成这种情况的主要原因是过程中质量保证没有做到位，把大部分问 题留在了后面。这就需要在项目实施过程中采取有效的措施来规避返工的风险，通常的 做法有同行评审，比如概要设计完成之后，邀请其他项目组的技术专家进行技术评审以 发现架构设计问题； 管理评审，通过组织级的质量审计看产品以及实施过程是否满足质 量要求；代码走查，在编码过程中加入至少一次的代码走查，排查不符合规范或性能要 求的代码，走查通常能够发现 50%-70%的错误；每日构建，这是一种非常有效的方法，可以避免把各部分的集成问题拖到最后，并且能够及时发现相应的错误，日构建一般在 项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。

4、人员技能和资源的不足 项目实施过程中由于人员技能欠缺造成的进

度延后和软件质量问题并不少见，一个 熟练的技术人员完成同样一个任务需要 3 天，但一个生手可能就需要 7-10 天。项目管

理者应该在前期就分析清楚项目所要采用的技术以及相应的人员技能要求，针对不同的 角色，及时采取相应的技能培训，以保证项目的顺利实施。如果对于项目中某些部分专 业性特别强或新技术，短期内又不能快速建立技能的情况，可以考虑将该块任务外包，借鉴合作商的力量降低实施风险，当然要进行外购人力成本与自建人力成本的效益分 析。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。如何减少 此类风险的发生？在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻 克。如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找 可替代方案。这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风 险在后期或中期出现。项目所需人力资源无法按时到位，导致资源风险。如何减少此类风险的发生？这个 就需要在项目计划制定的时候提前申请确认资源，并在项目过程中不断沟通协调。

5、缺乏良好的团队协作 软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各 模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清 楚工作界面及接口关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融为一体。这是一个团队的软实力，团队之间的协作好坏也将是个潜在 的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。项目风险管理的要点：

1、上述我们所说的风险管理都是指可以预期将要发生的风险，那些不可预期将要发生 的风险不属于风险管理的范畴。这也将是考验一个项目管理者的经验和知识对能否 管理好风险至关重要的内容。

2、对不可预期的风险，项目管理者要有潜在的风险意识评估，做好一些可操作性的预 案准备。

3、详细明确的项目计划、以及项目执行过程中每个要点的质量保证是降低项目风险的 必要条件。

4、风险报告是项目团队以及领导了解项目风险的一个有效手段。风险报告的格式： 序号 风险简介 对项目的影响 解决方案或对策

5、团队管理 团队就是一组个体为实现共同的目标而相互依赖、一起工作的共同体。团队工作顾名思 义就是团队成员为实现这个共同的目标而付出的共同努力，项目团队的工作是否有效直接关 系到

项目的成败。团队管理是个渐进的过程。世界上只有完美的团队，没有完美的个人。好的高效的团队 不是管理出来的，而是营造出来的。团队成员需要有大家可认同的团队文化，这需要大家共 同的努力。

1、营造良好的工作环境和氛围。

2、建设优秀或鲜明的团队文化。

3、保持高效的沟通。

6、项目会议 组织会议是项目管理者日常工作中一项非常重要的工作任务，项目过程中很多重要的决 定都是在会议中做出的，也有很多由于不成功的会议而对项目本身造成了不好的影响。首先看看不成功的会议常常表现为哪些形式：

1、会议氛围不好，参与者发言不踊跃；

2、会议讨论常常偏离主题；

3、会议没有取得预期的结果；

4、会议时间常常一拖再拖。这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的目的，很多人都对这样的会议都有抵触情绪，对此也是深恶痛绝。以下是组织会议时应该注意的问 题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必须要清楚：

1、会议是否会取得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有 可能取得成功，这是会议成功的充分条件。

2、会议的组织者和参与者的想法通常是不一致的，有时候甚至会大相径庭。所以不要 希望会议的参与者和你一样，对会议有着如此的期待，对大多数参与者而言，在会议中他只 是一个发表想法的人，他不用对会议的成功承担责任。

3、以下十一条最佳实践是形式上的约定，具体的实施可以根据实际情况来做。组织会议的十一条最佳实践：

1、只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。

2、提前发出会议议程，以便会议参与者知道他们来做什么。

3、请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确 保必要人物都在的情况下一次会议参与者越少效果越好。

4、提前预约参与者的时间，以确保他们能按时到场。

5、会议的开场很重要。会议组织者要在开始前做好几件事情。通常我建议有几点要在 开场时说： A、再一次强调会议的目标，我们来做什么。B、强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求讨论会，主要是讨论做还是不做以及告知大家我们要做什么，而不要把太多的精力放在讨论 如何做上面。C、说明一下会议的规则。如要发言，请举手；不要有小圈子讨论；不要打断别人 的讲 话，等别人说完你再说等等。

6、会议过程中时刻注意引导和控制会议，以确保会议按照目

标进行。一次会议的氛围 是否良好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。

7、会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成 果之一。

8、会议要有结论。我们常在会议上听到有人说：“大家讨论了这么半天，结论呢？”。没有结论的会议是没有意义的。

9、会议后别忘发会议纪要，以及一些 Action，什么人什么时候做什么。

10、会议后的 action 执行情况的反馈很重要。反馈是对会议参与者的尊重，同时也告知 了会议的效果。否则会让大家感觉到这是一个可无可无的会议，大家以后参与的积极性 也会降低。很多会议往往都不注意这一点。

11、按时结束的会议会受到所有人的欢迎。

7、版本控制 版本控制也是项目管理者的一个重要工作内容之一，一个项目或产品的完成不可能是一 步到位的，在项目完成的后期可能会有多个不同的版本的发布（开发版本，测试版本，发布 版本等）。需要做好版本的管理和控制。

篇8：浅析软件开发项目的管理

一、软件开发项目管理的必要性

项目管理是指:在一定的资源条件约束下, 如:资金、人力、时间、设备等, 对于一个有既定目标的任务进行计划与控制。项目管理是现代管理学中的重要理论, 其涉及到的范围较广, 在各行业、各领域中均发挥了重要的作用。由于软件开发项目具有特殊性, 在应用项目管理时也有其独特的一面。与其他的项目相比, 软件开发项目具有劳动密集型与知识密集型的特点, 其开发成果也多是以非物质的形式表现出来, 可见性并不明显。所以, 在软件开发过程中, 加强项目管理是十分必要的, 而且需要注意以下几方面的问题: (1) 了解用户的实际需求, 科学确定项目管理的框架与具体内容; (2) 严格控制软件开发的成本、质量、进度与风险, 以保障项目管理的实际效果; (3) 在软件开发过程中, 团队成员对于具体事物的描述与思维方式不同, 应尽量加强成员之间的协同性。大量软件开发实例表明, 如果不能在软件开发中加强项目管理, 随着国内软件行业的不断发展与壮大, 国内的软件开发企业将面临严峻的挑战性与风险性。因此, 为了确保软件开发的效率与质量, 必须认识到强化项目管理的必要性, 并且坚持多管齐下的方针, 积极采取有效的管理策略。

二、软件开发项目的管理策略

(一) 团队的组建

在软件开项目的管理中, 团队的组建是十分重要的, 只有保证团队的高效性、专业性与协调性, 才能保证软件开发项目的顺利开展与进行。从项目管理理论的角度出发, 在软件开发团队的组建中, 一定要尽量选拔具有较强专业技能和良好工作态度的人员, 从而保障团队成员有效的计划、协调与管理各自负责的工作项目。在团队的组建过程中, 必须首先提出明确、清晰的团队目标, 而只有在所有成员认同这一目标的基础上, 才能更好的激发团队成员的工作热情与积极性, 这是保障软件开发项目管理效果的先决条件。

(二) 成本管理

在软件开发项目的管理中, 成本管理的根本目标将项目的开发费用控制在预算内, 这是实现软件开发企业经济效益的关键管理项目。从国内外软件行业的发展现状而言, 在软件开发项目的管理中, 成本管理是一个较为薄弱的环节, 特别是对于一些中小软件开发企业, 由于成本管理措施不完善, 而导致软件产品的造价提高, 市场竞争力则明显削弱。成本管理计划是软件开发项目中成本管理的基本标准, 其是否合理将直接关系到项目的实际开发费用。软件开发项目的成本最主要的是人力资源的成本, 而人力资源的成本体现为各个项目成员薪资水平乘以他所花费工作日的总合, 因此人力资源的成本其重点在于合理地安排使用合适的人力资源。软件开发项目的成本还包括购买必需的软硬件设备的成本;需求调研所花费的交通、协作、通信成本;购买必要的办公用品、参考资料的费用;给用户培训所需要花费的培训资料编写费、资料印刷费、产地费、设备费;如果需要第三方的鉴定或检测, 还需要一定的鉴定检测费用, 包括准备的费用;如果部分组件需要外包, 则应当控制软件外包的成本, 包括交付给外包承担方的费用, 和进行质量、进度控制的管理成本。

(三) 质量管理

软件开发项目的质量管理要素一般包括以下特性: (1) 功能性, 即所开发的各类软件必须满足用户的实际需求, 对于用户发展相关业务具有一定的推动作用; (2) 可靠性, 即在一定的软件开发条件与规定时间内, 软件自身的维持性能水平必须保持在相应的程度, 不但要满足用户的正常使用需求, 而且要尽量提升软件在发生故障情况下的持续运行程度; (3) 易用性, 即软件的操作要求应尽量符合用户的个性需求和使用习惯, 保证界面友好和操作简单; (4) 维护性, 即在软件发生运行故障或用户需要进行某些功能的更改时, 其维护难度应适中。

在软件开发项目的质量管理中, 应从以下几方面做起: (1) 对软件功能性需求做详细的调研; (2) 制定严格的软件开发质量管理计划; (3) 在软件开发过程中, 定期对于软件项目的开发质量进行绩效评价, 并且完善相关的质量管理标准信息; (4) 对软件开发项目质量管理的执行结果进行全过程、动态的监控, 确保每一开发环节都符合相应的质量标准; (5) 建立高效的质量小组或者测试小组。

(四) 进度管理

在软件开发项目的管理中, 由于开发过程中经常需要进行修改与调试, 进度管理的难度相对较大。为了进一步加强软件开发项目的进度管理, 必须从以下几方面做起: (1) 根据软件开发项目的规模与性质, 合理计算出所需的人员数目、资金和时间等, 逐步完善项目的进度管理计划, 并且坚持弹性原则, 将软件开发中所必需的调试、缓冲时间等计入其中, 以防止出现开发时间不足的现象; (2) 在完成软件系统分析与初步设计完, 应根据进度管理计划确定每个程序在开发与测试过程所需要的具体时间, 并确定进度管理的基本方针, 要突出研发项目的主次; (3) 在软件开发项目的进度管理中, 进度计划应随着软件的具体开发过程, 实行“由粗到细”的科学调整, 每隔一段时间应组织管理人员比对项目的实际进度和进度计划的差距, 对于明显落后于进度计划规定时间的项目, 应及时补充开发人员或适当调整项目的开发时间。

三、结束语

综上所述, 软件开发是一项技术性、专业性要求较高的项目, 也是一个国家科技发展水平的重要展现。在我国现代科技的不断发展中, 软件行业已经成为部分地区的重要支柱产业, 为了有效提升国内软件行业的实力与竞争力, 必须认识到加强项目管理的重要性, 必须对于细节问题进行深入的研究与探讨, 从而构建一套完善的软件开发项目管理体系。

摘要：随着我国软件行业的快速发展, 软件开发企业之间的竞争也日趋激烈, 为了提高软件开发的效率与质量, 必须采取行之有效的项目管理策略。本文就如何提高软件开发质量及管理进行探讨。

关键词：软件开发,项目管理

参考文献

[1]刘畅.项目管理在软件开发企业中的应用[J].黑龙江科技信息, 2010, (04)

[2]李英才.项目管理在软件开发过程中的体现[J].黑龙江科技信息, 2009, (06)