软件项目管理的理论与实践.docxVIP

PAGE 1 PAGE 1 软件项目管理的理论与实践  软件工程是针对软件这一具有其特别性质的产品的工程化方法。它关注的是软件产品的生命周期，包括从需求、设计、编程、测试、到运行和升级维护共六个主要阶段，而且随着软件产品的不断升级维护，还会使同一软件产品经历多次这样的生命周期，由于软件产品的性质、用途、规模等方面的差异，软件生命周期和项目生命周期可能会重合，一个软件的生命周期在一个项目周期结束时也随之结束。而在更多状况下，一个软件的生命周期会通过多个项目来完成，例如在软件的计划阶段，可以以一个项目的方式来实现，在软件开发阶段，包括软件的需求、设计、编程、测试阶段，也可以通过一个项目的方式来管理。项目可大可小。  项目管理涉及范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、选购管理、项目综合管理九大学问领域的内容，而其中范围、时间、成本被称为项目管理的三约束，又称为“项目管理三角形”，项目三角形中的成本，主要来自于所需资源的成本，自然也包括人力资源的成本。为了缩短项目时间，就需要增加项目成本(资源)或削减项目范围；为了节省项目成本(资源)，可以削减项目范围或延长项目时间；假如客户需求变化导致增加项目范围，就需要增加项目成本(资源)或延长项目时间。项目范围管理是指对项目包括什么与不包括什么的定义与掌握过程。这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及这些产品用到的过程有一个共同的理解。作为衡量一个项目或项目阶段是否已经顺当完成的标准是项目的范围说明书，项目范围要由项目客户和项目发起人共同地正式认定，范围变更要进行变更掌握。对于软件开发过程来说，范围说明书就是软件的需求分析报告，项目范围的管理也就是软件需求的管理，电力自动化公司在软件需求管理过程中存在以下几个问题：  1．需求描述不清楚  该公司已经通过了IS09001：2000国际质量管理体系认证，现在软件开发项目负责人已经能够做到将用户的需求整理成需求分析报告，交用户签字确认，但他们这样做好像只是为了达到IS09001质量体系的要求，只是走形式，并没有熟悉到这样做的重要性。因而存在需求描述不够清楚、不够详细的问题，给用户留下发挥的空间，也给我们公司造成不良影响。例如公司与某农电项目签署的需求说明书中写到‘实现电力营业相关的功能’，我们开发人员认为按签署的合同金额，我们只要完成其主要业务功能，多余的工作会使我们成本过高，也不在需求之内，而用户认为管理、考核功能、综合查询功能都是营业相关功能，都属于需求范围之内，需求未满意，用户不付款。因此我们只能损失利润以便换取用户的满足，造成项目成本超支。  2．用户口头需求不能准时记录，交用户确认的需求经常不能一次提全，随时增加需求.  而由于项目负责人缺少项目管理学问，不能准时记录用户口头需求，为了赶进度，为了按期完成任务，也不与用户进一步沟通确认，结果是开发完成的产品用户不认可，用户也很恼火，我明明告知你这个功能要做成那个样子，你为什么做成这个样子。这就是项目范围未经客户正式认定，沟通也不准时，因理解的不全都造成劳而无功，而且还需要重新返工。  3．用户需求变动缺少有效掌握。  用户需求变动也就是项目范围变更，项目变更需要有项目变更委员会评审变更的影响，而用户提出的需求变动经常被开发人员自行消化处理了，而且依旧是没有文字记载，没有用户确认，有的只是为了赶工期，为了不超成本，在程序中打补丁。在软件测试检查文档时解释说需求没来得及修改，等有时间再重新整理需求。而且这样完成的程序结构不够优化，不利于他人阅读理解，甚至留有隐患。  4．需求未能考虑全部的用户  项目管理学问体系要求项目范围由项目客户和项目发起人共同地正式认定，这里强调，共同认定，软件开发这个项目也不例外。项目发起人和一两个客户的认定不能代表全部的用户，其他用户不认可，不得不在现场修改程序，这样做不仅程序的质量得不到保证，而且造成工期延误、成本超支。最主要的是用户对我们公司的满足度下降。  5．开发过程中缺少与用户的沟通  软件开发的结果要满意或超越用户的需求和期望，但纸面上的需求分析报告描述得再清楚也不能涵盖用户的全部需求，比如用户对使用敏捷性的要求、对软件运行界面的要求，所以在开发过程中应当多与用户沟通，或者请用户参与到项目组中，不能一味地赶进度，埋头苦干，随时沟通才能保证不偏离轨道，才能提高成功率。  由此可见，只强调时间和成本，忽视范围管理，往往会适得其反，不仅时间和成本不能保证，还会引起用户的不满。需求分析又是软件设计、实现、测试直至维护的主要基础。良好的需求分析活动有助于避免或尽早剔除早期错误，从而提高软件生产