软件项目的需求变更管理 .docxVIP

PAGE 1 PAGE 1 软件项目的需求变更管理  软件项目的范围掌握应当是在需求分析阶段就开头的，然而许多项目经理针对需求分析存在不少熟悉误区。  方法/步骤  误区1：开发商和用户仅就软件需求的基本轮廓达成全都即可，详细细节预备日后协商。  从项目管理角度分析，这是特别危急的，很多软件项目失败的最主要原因就是需求分析阶段对问题、流程、细节的描述不够精确，导致后期预算超支或者工期延误。  正确的方法是：在需求分析阶段，双方必需对项目的应用背景、功能需求、性能需求、牢靠性需求、可用性需求、操作界面需求、外部接口需求，以及项目评审的方法、标准、过程进行全面、细致地研究争论，逐一进行明确。  误区2：软件需求是软件必需向用户供应的功能和界面，功能上满意需求就足够了。  从软件需求工程角度分析，这只是熟悉到了软件系统的功能需求，忽视了软件的非功能需求和设计约束，需求捕获不够全面。软件需求工程理论认为，软件需求包括功能需求、非功能需求和设计约束三方面内容。  正确的方法是：除了要明确软件的功能需求，还需要进一步明确非功能需求(即软件产品所必备的属性和品质，包括牢靠性、可用性、安全性、可扩展性、可移植性等)和设计约束(即软件研发必需遵守的特定规约、限制条件、政策标准,如软件必需采用国内自主学问产权的数据库产品)。  误区3：需求调研的对象是用户，用户就是软件产品的最终使用人员。  从项目管理角度分析，该观点缺乏对项目相关人全面、系统的熟悉，对用户的概念理解不到位。“用户”是一种泛称，它可细分为客户、最终用户和间接用户三种类型。例如，许多企业的一把手并不直接参与软件的选购和操作，但是其对于软件项目实际上起到了关键意义的打算作用，属于最重要的间接用户。  正确的方法是：要充分熟悉用户的多重性、层次性、复杂性，在进行需求调研时应首先对用户进行分析、分类，依据重要性、优先级、特别性对各类用户进行排序;其次，是针对不同类别的用户分别制订不同的需求调研计划，全面开展需求调研。需要重点指出的是，对于由多个业务部门共同参与的软件项目，在确认软件需求时一定要得到全部参与部门的共同认可。  误区4：根据“需求、设计、编程、测试”步骤研发出的软件不必考虑需求跟踪问题。  从软件工程角度分析，这是对于需求变更过程缺乏系统的熟悉的表现，严格线性顺序的开发模型并不能保证各个开发阶段的工作成果与需求保持全都。实际上，由于需求变更的不可预见性和必定性，各个阶段往往以螺旋的方式渐进。  正确的方法是：需求跟踪应当贯穿于整个软件需求管理阶段，需求跟踪的目标是实现《产品需求规格说明书》和软件产品之间的双向可追溯。  留意事项  有必要强调的是，在项目实施过程中，变更处理越早，难度越小，损失越小;变更处理越迟，难度越大，损失也越大。而且，任何变更都必需经过项目建设全部相关方(建设单位、承建单位和监理单位)多方确认后才能计划实施，严禁任何一方擅自变更。对项目变更的范围要有明确的界定，而且项目建设全部相关方对变更范围的理解上都没有任何异议。  最终，变更对项目质量、成本、进度都会产生影响,需要对变更过程加强监控，实施变更风险管理，不能因为变更而引发新的风险。项目管理人员在做出变更决策时，应准时将变更信息、变更计划方案公布于众，这样才能准时调整项目团队的工作，朝着新的方向努力。