软件项目需求管理论文（共12篇）
软件项目需求管理论文 篇1
摘要：随着我国经济社会的发展, 信息系统的应用无处不在, 软件研发成为了当今社会的一个热点。一个软件项目的成败取决于多个方面, 但需求管理是软件工程管理的重中之重。本文从软件项目需求管理的概念出发, 结合笔者在工作中的体会, 针对需求开发、需求管理两个方面的内容进行了系统论述, 希望读过此篇文章的同行, 能从中受到启迪, 更有效地进行需求沟通并加强协作与验证, 少走弯路, 降低失败的风险。
关键词：软件项目,需求工程,需求开发,需求管理
1. 软件项目需求管理的概念
软件项目需求管理是指软件项目的开发团队了解、挖掘用户的“需要”, 对这些“需要”进行系统有效的跟踪、管理, 最终通过软件将这些“需要”实现, 满足用户期望的过程。软件需求来源于用户的需要和期望, 这些“需要”被清洗、梳理、分析、抽象、整理后形成文档, 详细地说明了软件产品“必须做什么”或“应当做什么”, 是用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
2. 软件项目需求工程与管理
2.1 软件需求的层次与组成
软件项目需求工程是一个系统工程, 在实际开发过程中, 需求可分为4个层次:
原始问题:用户口头、书面提出的要解决的问题, 它是软件需求的基础;
用户需求:开发团队用自然语言、图表给出的, 软件系统将要提供的服务及操作的约束;
系统需求:是用户需求的映射, 可通过软件原型给用户一个直观印象, 并在此基础上开展下一步的工作;一般算法较简单的软件采用水平原型, 需要体现复杂算法的则用垂直原型;
软件设计描述:以上三个层次说明了“做什么”, 这个层次则说明“如何做”, 是软件详细设计和实现的基础。
在了解以上4个层次的基础上, 我们就可以进一步理解软件需求工程的组成:需求开发和需求管理。
2.2 需求开发
(1) 需求捕获
需求捕获是需求工程的主体, 它描述了用户通过软件系统需要完成的任务。改过程归纳、整理了用户提出的各种问题和要求, 厘清用户希望通过软件达到的目的, 并使用工具和方法描述用户提出的实际需求, 以界定软件的作用范围, 最终弄明白要“做什么”。
实施需求捕获首先要确定用户类型, 寻找每一类型用户的涉众代表及需求的决策者。需求捕获的方法有:理解用户单位的组织架构;调查各部门的业务活动;与用户交谈;向用户群体发放调查问卷;分析用户工作流转的表单、文件;参观用户的工作流程, 观察用户的操作;召集用户代表会议;场景实例分析;跟班作业等。建议在捕获前需求管理人员应事先建立一份基本词汇表, 其中主要描述用户行业的专业术语, 包含了一些用户日常工作的基本流程及其解释。这样做的好处, 一是给用户一个良好的第一印象, 让用户认为你很专业, 对你很放心, 双方有更多的共同语言;二是能帮助项目开发团队正确领会用户相关干系人的意图。
(2) 需求分析
需求分析是指在需求开发过程中, 对所获取的需求信息进行分析, 及时排除错误和弥补不足, 弄清楚问题的要求。确保需求文档正确地反映用户的真实意图。需求分析方法大体有两类:一类是常识性的方法, 简单易用, 另一类技术性很强, 在此不做讲解。
(3) 需求规格说明书
需求规格说明书 (SRS) 用以描述用户需求和系统需求。SRS不仅要正确地反映用户的真实意图, 而且用词应该简单明了, 清楚易懂, 尽量使用前文提及的基本词汇表中的语言, 另外还应该力求全面具体, 具有可操作性与可验证性, 只有这样的需求规格说明书才能最终帮助我们进行科学的需求管理。
(4) 需求验证
需求验证目的是为了确保SRS准确、完整地表达了必要的质量特点。此时, 应会同用户方的决策、业务、技术人员一起验证, 其目的有二:一是让用户了解、明白SRS是否正确地描述了他们的需求;二是通过此文档, 确保需求提出者与需求分析人员、开发人员、测试人员及其也干系人对需求达成共识, 并把需求固化, 作为基线, 控制用户在需求方面的变更。验证的内容有:审查SRS、测试用例、测试覆盖、产品验收标准等是否与用户需求一致、完备。
2.3 需求管理
(1) 变更管理
用户需求变更在项目实施过程中是永远存在的, 但客户并不永远是对的, 也就是说需求变更要加以正确的管理和控制。如何对需求变更进行管理呢?
首先, 要对需求变更进行分类, 区别对待。一类是关键性变更, 它影响到项目的正常交付使用, 这种需求是必须满足的;二是改良型变更, 它不影响系统的交付, 但如果不被满足会令整体项目工作的价值下降。
其次, 所有的变更必须通过变更控制流程实现, 绝对不能因为变更范围小、容易实现, 或碍于面子, 就随口答应, 或不通过配置管理就进行随意改动, 有时一个小小的变更就会导致项目的失败。
(2) 版本控制
版本控制用于跟踪记录整个软件的开发过程, 包括软件本身和相关文档。通过版本控制在空间上可以保证配置项的集中管理, 解决一致性和冗余问题, 让版本具有可回溯性, 它不仅是开发团队并行开发、提高开发效率的基础, 也是管理需求变更的手段。
(3) 需求跟踪
需求跟踪建立和维护了从用户需求 (包括变更的需求) 到测试的一致性与完整性, 即建立“需求-设计-编码-测试”之间的一致性, 确保所有的工作成果符合用户需求。
3. 几种需求管理工具
一个好的工具可以让需求管理工作事半功倍。这里我推荐几种管理系统:Rational Requisite Pro:集成易用的需求管理工具;IBM Rational DOORS:老牌的需求管理套件;Cloudtopo Topo:国产需求管理平台;Visual Source Safe:一个常用的、易上手的配置管理 (版本控制) 软件;
需求管理是软件项目开发工作的一个重要领域, 关系到整个项目的成败与质量, 尽可能准确的获取客户需求, 尽量一次做对, 编写出高质量的SRS, 加强需求管理, 有效防范和减少不必要的需求变更, 跟踪、控制需求在整个软件开发生命周期中的作用, 努力降低因需求变更对项目的范围、成本、质量和进度造成的影响。
参考文献
[1]万文杰, 李振中, 任伟, 高瑞年, 卢旭.探析软件开发中的项目需求管理[J].电脑编程技巧与维护, 2010, 10.
[2]毛伟辉, 陈旭翔, 赵少娟, 裴金栋, 张金华, 杨萍.软件项目中的需求管理模型[J].电信快报, 2010, 1.
软件项目需求管理论文 篇2
软件项目需求分析总结
需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键 总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况： 客户本身说不清楚 文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。需求自身经常变动 随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。分析人员或客户理解有误 毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。由此出现的问题： a)需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。b)需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。c)需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。d)对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。e)项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。f)此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。结论 a)需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。b)需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。c)需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。d)需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生 e)需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。f)需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题 g)帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解 h)最后，需求分析报告一定要双方共同签字确认。
软件项目需求管理论文 篇3
关键词：职场需求；校企合作；软件项目工作室
中图分类号：G712 文献标识码：A 文章编号：1674-7712 (2012) 14-0135-02
党的十六大明确指出：要坚持以信息化带动工业化，工业化促进信息化，走新型工业化道路。软件技术作为信息化的核心，国家需要大量的计算机软件人才。
一、软件专业教学存在的问题
为了培养软件行业所需人才，几乎各个院校都开设了计算机软件相关专业。尽管每年都有这么多的学生进入计算机软件专业学习，但我国的软件人才需求缺口依然巨大，最终能在软件专业岗位留下来的人才不到软件专业招生学生的30%。
从目前软件专业教育来看，大学的软件专业教学存在着两个重要的问题。
（一）所学与所用脱节
这个问题体现在两个方面，第一方面，大学的软件专业教学普遍还停留在理论讲授的阶段，讲的内容多，但做的东西少。这就导致了学生所学不能所用，不能充分的理解并转为应用；第二个方面是指软件专业的一些专业课程讲授内容滞后造成软件专业毕业生技能水平与社会实际要求相差较大，一旦走入岗位，发现无所适从，一切又得从头学。
（二）专业技能不熟练
有些学生在校学习不错，基础也挺好，但对软件专业的各个岗位技能需求不明确，对自己将来要从事的岗位和未来职业定位也不是很清楚，在校学习的技能与社会所需的熟练技能存在着一定的差距，这就是我们最常听见学生反馈的——很多东西都朦朦胧胧的，做不到对应职业岗位的要求水平。
二、软件行业职场需求的特点
软件专业的教学所出现的问题其实是与软件行业职场的特点息息相关的。目前，我国软件产业继续呈现快速增长态势，增幅始终高于电子信息产业平均水平，产业规模继续扩大，软件出口平稳增长，产业结构与布局不断调整。软件行业职场呈现出以下主要特点。
（一）软件岗位分工越趋精细化
随着软件规模的不断膨胀和软件开发技术的发展，软件开发的分工和组织也变得越来越复杂，对一个软件产品或者一项软件工程来说，参与角色通常包括如下几种：高级经理、产品经理或项目经理、开发经理、设计师、测试经理、开发人员、测试人员、项目实施人员。我们现在都提倡模块化编程，模块划分遵循高内聚、低耦合的原则。模块化可以使软件结构清晰，容易设计、容易阅读和理解、容易测试和调试；提高软件可靠性；有助于软件开发工程的组织管理。同样，我们的项目管理也在学习软件的模块化思想。项目成员之间有明确的分工，分工遵循高内聚、低耦合的原则，减少工作重复内容。
（二）软件岗位要求知识面偏广
虽然软件行业岗位分工明确，但每个岗位间有着很多千丝万缕的联系，在平常的工作中，我们会经常沟通和交流；又由于计算机学科本身是一门综合性学科，所以势必造成各个岗位普遍要求任职人员对软件技术知识面要偏广，知识面越广，在IT领域的发展空间也越大。
（三）软件岗位与日俱变、岗位需求变化较快
目前，基于框架的开发使得程序员从繁重的后台数据访问中解脱出来，越来越多的应用开发更多的关注于前端的开发，即“富”客户端开发，富客户端开发技术正在越来越受到重视。这个岗位上的人才需求明显增多，但市场供应明显不足。同时，通过深入市场，发现前几年需求较旺的软件测试人员受到了冷落，人员也偏多，而新生的3G开发，Android应用开发等新型领域的开发岗位和开发人员受到青睐。据调查，软件开发岗位一般2-3年就会有一次新的需求产生和技术变革引来的替换。
三、基于职场需求的校企合作软件项目工作室的建设
为了解决目前软件专业教学所出现的问题，我们认为通过相关教学改革最终要达到以下三个目标：一是学生的学习过程要与软件公司项目开发过程接轨；二是教师授课模式要与软件公司项目经理带团队模式接轨；三是学生的实际能力要与软件企业对员工的要求接轨。其中前两个是过程控制，最后一个是实现目标。
而通过在大学里建设基于职场需求的校企合作软件项目工作室可以帮助以上目标的达成，针对企业具体就业岗位，锤炼学生的技能熟练度和技术的深度，做到有的放矢，有效地弥补大学教育知识广而非精的弊端，更好地与企业实现接轨。下面来介绍一下项目工作室的重要建设内容。
（一）专业导师担任项目团队经理
项目工作室的项目团队经理职位在整个项目工作室建设中起着非常关键的作用，他是软件项目工作室的领头人和开拓者。一般由专业导师担任，专业导师必须是“双师型”，要有多年的企业一线工作经历，有着丰富的软件技术技能和经验，教学期间能常参与企业的顶岗学习或为企业做技术顾问等相关工作。
学校也要鼓励教师面向企业，面向生产，直接参与技术开发、技术转化与技术改造。采取激励措施，促进“双师型”教师队伍的建设，学校可结合本身实际情况，从制度上、政策导向上向积极开展校企合作的“双师型”教师倾斜。
（三）建立岗位考核与奖励机制
参考软件企业，以“虚拟公司”建立项目工作室岗位考核制度，考核以量化指标为主并辅以非量化指标结合进行，体现多劳多得的原则，同时鼓励技术创新和技术复用，将团队合作也纳入到项目小组的绩效考核之中，整体项目的考核可以从项目完成质量、项目完成时间、项目成本三个维度进行考核。此外，可以按月、学期进行时间梯度上的考核，注重考核的时效性和激励作用。
（四）校企基于项目互赢合作
项目工作室以外包的方式承接企业软件项目，企业对完成的项目进行验收和评估，并支付一定的软件开发费用用于奖励导师和项目工作室学生。项目工作室可定期邀请企业技术骨干指导项目开发。学生也可以经常深入企业进行学习。表现好的学生毕业后可以直接进入到企业就职。
四、结束语
我们认为，大学教育结合技能岗位教育才是解决“企业招不到人，学生就不了业”两难困境的钥匙。而基于职场需求的校企软件项目工作室的建设是实现这一途径的有效方法。通过与市场接轨的职场岗位锻炼，学生必能学以致用，振翅高飞。
参考文献：
[1]李德有,解晨光,刘明刚.高职高专计算机软件专业教学改革的探讨[J].哈尔滨金融高等专科学校学报,2009,99.
[2]钟石根.基于“导师制、项目化”建设校内生产性软件项目开发实训工作室[J].出国与就业,2011,14.
[3]赵学义.论高等教育的职业导向[J].教育发展研究,2008,11.
[4]胡艳曦,曹立生,刘永红.我国高等职业教育校企合作的瓶颈及对策研究[J].高教探索,2009,1.
软件项目管理中的需求管理 篇4
关键词：软件项目,需求管理
计算机包括了硬件、软件, 而计算机的顺利运作离不开软件这个重要因素, 由此可以看出相关的软件工作人员对软件展开设计、开发以及管理的工作, 是非常重要的。然而, 在软件的整个项目中, 软件需求更是重中之重, 既是广大用户与软件工作人员的直接桥梁, 又是展开软件设计、开发以及管理的基础前提。只有根据广大用户的需求、思想来实现软件项目的设计、开发以及管理, 才能够获得成功, 也才能够保持持续的发展。
一、软件需求管理
(一) 软件需求管理的目标、原则
对软件需求实施管理, 能够直接地从本质上确保软件开发的实用价值, 进而增强软件开发完成后的成功率。然而, 软件需求的管理, 并不仅仅只是采纳广大用户的意见、建议, 而是一项比较系统的工作, 在运作的过程中有着其自身的目标以及原则。软件需求管理的原则:第一, 软件需求必须划分优先级;第二, 软件需求必须展开分类的管理;第三, 对软件需求的管理工作必须与所有的软件需求活动紧密的结合在一起;第四, 在运作的过程中如果软件需求发生了改变, 应该及时的根据改变所造成的影响展开评估活动;第五, 软件需求的所有信息, 都应该实施文档化。软件需求管理的目标:尽可能良好地控制软件需求, 在此过程中积极地、主动地建立、完善整个工程所需要的基线, 并且使后续的软件设计、开发以及管理工作符合最初的软件需求。
(二) 软件需求管理的涵义
在展开软件设计、开发以及管理工作之前, 必须先做好相关的软件需求工作, 而对软件需求管理工作的实施, 则应该积极地、主动地去提取、组织并且将这些系统性的软件需求进行文档化, 由此可以看出, 软件需求的管理是一个系统性的项目。具体的运作步骤如下:第一, 提出问题或者列出示范类型, 并且尽可能的找到相关的依据, 进而得出切实可行的需求探讨;第二, 将所有的信息做好记录以及整理, 并且输入到数据库当中, 从而使软件企业、软件工作人员能够在系统的具体操作上与广大的用户达成共识;第三, 用更为准确、更为清晰的方式描述对软件的需求, 为后续软件设计、开发以及管理工作人员的工作奠定好基础, 使其能够顺利的、成功的将需要转换为真实的系统设计。
二、软件需求管理的实施特点
从某种程度上来看, 软件企业与传统的生产企业有着很多的相似点, 而对于软件需求的管理则类似于传统生产企业所展开的问卷调查活动, 其性质都是为了能够更好地掌握消费者的需要以及了解市场的最新动向等等。但是软件企业毕竟与传统生成企业有所不同, 传统的生产企业所展开的需要管理, 是具体的、有形的, 也就是说可以直接进行描述的, 然而软件是一个比较抽象的商品, 其最初的需求管理工作具有主观性, 是模糊的、难以确定的。不仅如此, 软件企业的需求管理工作, 也比传统的生产企业重要得多, 可以说是整个软件设计、开发以及管理项目的关键所在, 直接的影响到软件能否获得成功, 进而影响到软件企业的生存、发展。正是因为这样, 软件需求的管理有着其自身的实施特点, 包括了:第一, 软件需求的变化。社会在不断地发展, 科技在不断地进步, 而计算机作为一种高端科技, 可以说是瞬息万变的。更何况一个新软件的推出, 并不是在短时间之内就能够完成的, 从最初对软件需求的管理, 到软件的具体设计、开发以及后续的管理, 是需要一定时间段的, 而在这个时间段中可能会发生很多的事, 比如说其他的软件企业抢先推出了同一类型的软件或者人们的思想、需要在这个时间段中发生了改变等等。第二, 软件需求的完整程度。软件的需求系统, 是一个非常庞大的工程项目, 小到广大客户所提出的意见、建议, 大到专业的推断、决策等等, 要想做到全面几乎是不可能实现的。更何况对于软件需求系统的划分还是一个非常客观的重要问题, 只有准确的实施硬性划分, 才能够区别出特点的范围, 也才能够建立起指定的基线, 并在其过程中尽可能地去完善软件需求的完整程度。第三, 软件需求的描述。尽可能地完善软件信息的完整程度, 会消耗软件企业大量的人力、财力以及物力, 而当软件信息的完整程度获得成功, 就会延续地引发另一个问题, 那就是对软件需求的描述。软件是一个比较抽象的商品, 如果通过文档来展开记录, 则会出现成百上千的页面文档, 而广大的用户是不可能完全地理解这些文档记录的, 更何况不同层次的用户所需要的、关心的问题又都是具有差异的, 所以造成了软件需求的描述难点。第四, 软件需求的细致程度。软件需求的细致程度, 可以说是见仁见智的, 不同的人都会有不同的想法以及观点, 如果一味地强调细致, 就会拖延时间, 而时间的延长又会引发需求的变化。正是因为这样, 对于软件需求的细致程度, 也是一个非常值得重视、深思的问题。第五, 软件需求的工期。软件的推出, 不仅仅在质量上要抓好, 在时间上也同样要抓紧, 因为时间的延长会引发一系列的变化问题, 而这些变化问题的出现将会直接的影响到软件企业的生存、发展。但是软件需求管理, 又是软件设计、开发以及管理工作的必要前提, 要想确保软件需求管理的准确性、完整性, 就不得不在这个阶段投入大量的时间, 从而引发极端的矛盾。
三、如何做好软件项目管理中的需求管理工作
(一) 正确认识需求变化
软件需求管理的变化包括了建立基线、确定软件需要追踪的重要依赖关系、建立相关项目之间的可追踪性以及对变化控制等等。软件需求的变化可以说贯穿了整个软件项目的生命周期, 只有通过建立规范的变化控制流程, 改进软件分析以及设计, 将不能够确定的变化纳入已经确定的计划当中, 才能够在应对软件需求变化的过程中更加的从容以及更加的具有信心。在软件开发的过程中有这样一条客观真理, 那就是需求的变化是永恒的, 而需求又是不可能完备的。软件开发的过程实际上是一个变化的过程, 然而需求的变化不一定是坏事, 也有可能是好事。软件需求的变更之所以难以进行管理, 不仅仅只是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性, 而且也因为对某个需求的变更很可能影响到其他需求。正是因为这样, 应该确保赋予需求一个有弹性的结构, 从而使软件需求能够适应变化, 并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系。
(二) 与用户充分沟通
在软件需求的管理过程中, 与广大用户保持积极的、有效的沟通、交流是非常重要的, 因为这个过程直接地决定着最终的软件商品是不是能够满足用户的要求, 换句话来说, 这个过程在很大程度上决定着软件项目的成功与否。然而, 在与广大用户保持沟通、交流的过程中, 双方对于软件需求的认识应该要确定一致, 不能够模棱两可。而在讨论软件需求以及软件需求变化的时侯, 软件工作人员必须以协作的态度来对待这些用户, 从而通过良好的工作氛围、交流分为来提高工作的效率, 激发广大用户的思维, 从而获得软件需求信息。除此之外, 确定软件需求基线的过程也是软件企业与广大用户交流的过程, 而频繁的、大量的软件需求变化在很大程度上也是交流不充分的后果。正是因为这样, 有效的充分的交流尤为重要, 需求人员认真听取客户用户的要求, 进行分析以及整理, 并且最终取得用户的确认。
(三) 建立需求管理模型
软件需求建模的目的是为了能够消除人际沟通随意性很强的弱点, 所以需要致力于将沟通标准化、自动化以及准确化, 而且责任到人负责的具体阶段, 具有可测试性以及可验证性的特点。软件需求建模是表达软件需求的其中一种形式, 是对软件需求的一种描述以及诠释, 它使用标准的语言, 利用类似积木的概念来建模, 最大的优势就是每个人都能够直接的根据自身的要求, 轻易的、反复地修改这个软件需求模型, 而在这个过程中还不会产生任何的歧义, 从而可以使大多数人快速地掌握、理解。建模的过程就是通过软件需求的特点以及要求来展开相关的分析、探讨, 以建模标准为基础进行准确的、完备的以及有效的阐述, 以确保广大用户以及软件企业都能够准确无误的、通用的理解。
(四) 控制好需求文档版本
客户签收的所有过程文档都要作为基线确定下来, 做好相关文档的管理工作。软件需求的基线指的是容许需求变更的分界线, 需求分析人员在充分与客户用户进行沟通的基础上形成第一个版本的需求文档, 这个需求文档在通过需求评审后即可以建立第一个需求基线。在此之后, 每次软件需求的变化并且经过需求评审之后, 都要重新的确定新的软件需求基线, 以免将来用户需求发生变更的时侯, 原来的需求无法查找。为了能够有效地进行软件需求变更的控制, 必然要做的工作就是保存好各个版本的需求基线, 维护需求基线的文档, 这样才能够以备不时之需。
四、总结
总而言之, 软件的需求管理是软件设计、开发以及管理的必要前提, 只有认真地、充分地、完整地做好软件需求管理, 才能够确保软件的顺利推出。正是因为这样, 软件企业必须重视软件需求管理, 并且尽可能的完善这个项目, 用科学的、严谨的态度对待软件的需求管理, 这样才能够从本质上促进自身企业的成功发展。
参考文献
[1]姬晓鹏, 吴朝晖.需求管理的一个系统解决方案[J].计算机工程, 2003.
[2]江小丁, 王朝晖.软件项目需求管理的研究[J].计算机与现代化, 2006.
[3]陈丽杰.浅析软件项目管理中的需求管理[J].科技资讯, 2007.
《××项目软件需求变更说明书》 篇5
项目名称： 长益高速收费数据分析系统一、概述
因湖南省高速公路联网拆分系统软件升级，导致长益下属收费站入口和出
口交易数据、拆分数据、代收拆分数据无法获取。而现阶段省高管局监控中心无法在上报报表日期内提供拆分数据，从而导致长益高速收费数据分析系统无法输出相关报表。经过深入了解和分析，在与业主方多次探讨后，提出以下变更说明。
二、变更内容
MTC实收和流量
原始情况：
人工收费系统出口站收费数据和出口流量的导入，是由收费站工作
人员从站级拆帐网下载的“收费数据统计报表”并再录入部分细分数据，导入长益收费数据分析系统。
变更后：
收费站工作人员在分析系统中MTC实收功能模块中只录入出口各车
型实收收入、各车型流量、免费车流量、绿通车流量、系统外收入、绿通车减免金额、免费车减免金额、手工票金额。
运营部工作人员在分析系统中MTC实收功能模块中导入本路段各站
进，其他路段出的代收流量的各车型估算流量。其中包括各车型流量、绿通车流量、免费车流量。
MTC实得
原始情况：
人工收费系统实得数据的导入，是由收费站工作人员从站级拆帐网
下载的“拆帐统计报表”，导入长益收费数据分析系统。
代收实得的导入，是由运营部工作人员从拆帐网下载的“长张高速
公司名称，版本号
2公路联网收费实际分配收入统计表”，导入长益数据分析系统。
变更后：
运营部工作人员在分析系统中MTC实得功能模块中导入估算MTC各
车型拆分收入。其中包括本路段各车型收入、系统外收入及代收业主各车型收入、系统外收入。
报表输出
由于原始基础数据的变更，所导致从数据模型上的建立发生了变化，从而将导致原长益数据分析系统输出报表无法根据原来基础数据的数据输出，需要转换为估算的数据输出，需要对所有的报表进行修改。
需要修改的报表有以下：
公司－绿色通道车辆 公司－收费站拆帐情况表 公司－单车收费标准计算表 公司－流量对比表 公司－各类车流量收入比重对比图 公司－各类车流量收入比重表 公司－实征率 公司－高速免费车 公司－收费车流量统计 公司－ETC收费车与免费车 公司－月流量分析 公司－ETC征费情况 公司－月收入图 公司－月收费情况总表 公司-收费车流量与收入统计 路劲-收入影响因素对比表 路劲-项目每月输入及车流汇总表 路劲-各站每月收入及车流汇总表 路劲-历年路费收入图 路劲-历年次票车流量图 路劲-日报 省局-交通流量统计月报表 省局-绿色通道和免费车公司名称，版本号
省局-其他收入分项统计
三年同天对比-1月
三年同期对比-2月
三年同天对比-3月
三年同期对比-4月
三年同期对比-5月
三年同期对比-6月
三年同期对比-7月
三年同期对比-8月
三年同期对比-9月
三年同期对比-10月
三年同期对比-11月
三年同期对比-12月
周报-高速公路
周报-总表
周报-流量图
周报-收入图
周报-老路
月报-月收费
月报-财务系统内金额拆帐
月报-月度收费情况
论软件项目的进度管理 篇6
关键词医保通系统项目进度管理
2013年6月，笔者作为项目经理参加了某保险公司医保通系统建设，主要职责是项目管理。“医保通系统”是指保险公司通过信息化手段和医院之间搭建的信息平台。医保通系统在省级公司建立医保通中心端，搭建数据库和应用服务平台，医保通前端设在医院。系统的主要功能包括：客户入院申报；探访核实的信息录入；处方信息采集和上传；处方审核；理赔金结算；统计分析功能。医保通项目历时6个月，于2013年12月成功上线。
该系统开发中，我主要担任项目管理工作。软件开发进度管理是一项软件开发项目管理的一个重要内容，有效的进度管理是保证软件开发项目如期完成的重要环节，在医保通系统开发过程中，我采用合理估算项目工期、工作量和技术难度，制定出项目的进度计划表；制作项目周报，及时了解项目进度，适时进行调整和动态控制；采用CPM法，识别关键任务，允许一些任务并行以及组件的复用等方法来保证项目如期完成。
一、合理估算项目工期、工作量和技术难度，制定出项目的进度计划表
首先制定项目日程主计划，内容包括项目在定义阶段、实现阶段、验证阶段、确认阶段的里程计划及主要成果物。
其次制定详细的进度表，先进行项目的工期的精确估算。在工期估算方面，我们主要采用基于公司项目估算参考表，如模块复杂度划分参考表、功能点代码行转换参数表、功能点生产率参数表、缺陷参考基准表、工作量分布参数表，对项目所需要实现的每一个功能模块在项目生命周期的每个阶段的基准规模、需求定义/设计/测试占阶段人天比例、评审占阶段人天比例、bug修复占阶段人天比例、模块规模（FP）、模块规模（LOC）进行详细的估算，同时估算出项目组每一位成员在项目生命周期的每个阶段以人天为单位的工作量，形成项目估算明细表。依据项目估算明细表，汇总统计出每一阶段/任务工作量、缺陷、详细的进度安排（包含每一阶段的开始时间、结束时间）、人员投入安排，制定出项目进度计划表。
最后在project中参照项目进度计划表相关数据填写各阶段工时值时形成项目甘特图。
二、制作项目周报，及时了解项目进度，适时进行调整和动态控制
在project中项目的计划开始、完成时间就是比较基准时间，它在项目计划做好后即可保存起来。项目开始、完成时间随项目成员反馈的任务进度进行更新，两者比较形成项目进度偏差。因此利用project的任务视图和资源视图可以随时看出目前项目进度、资源、成本与计划是否存在偏差。
每周利用project采集项目进度数据填写入度量计划表所列项目进度、里程碑进度差异等内容，按照《标准度量指标定义》中制定的度量方法和度量公式，计算度量结果，并对度量结果进行分析形成度量分析表，寻找偏差，采取行动调整偏差。综合project中反映出的项目的风险和问题形成项目周报，项目周报的主要内容有：项目进展概况、本周任务工作完成情况、下周任务计划、项目目前存在的问题和风险、度量分析表。每周举行项目例会，分析项目周报列出的进度风险和问题。
三、采用CPM法，识别关键任务
允许一些任务并行以及组件的复用采用CPM法，识别出项目的关键任务，允许关键任务以外的其他任务在机动期内收缩。而关键任务的收缩不得超过一周。当遇到关键任务延期时，就会召集大家开会，讨论找出项目延期的原因，并由主要责任人签字，把这种责任作为业绩考核的依据与工资挂钩。
四、结束语
解析企业软件开发项目的需求管理 篇7
随着信息时代的发展, 计算机软件的需求愈来愈复杂, 规模愈来愈大, 而且随着企业的发展和工作过程重组, 需求变更已愈来愈成为必然。在企业软件项目的开发过程中, 需求变更贯穿了软件项目的整个生命周期, 在软件的项目立项、研发及维护各阶段, 用户经验的增加、对软件使用感受的变化以及整个行业的新动态, 都为软件带来不断完善功能、优化性能、提高用户友好性的要求。在软件项目管理过程中, 项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更, 项目计划会一再调整, 软件交付日期一再拖延, 项目研发人员的士气将越来越低落, 将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。
需求管理是软件开发生命周期的初始阶段, 它对最终提交的软件产品的质量起着至关重要的作用。有资料统计, 软件项目40%—60%的问题都源于需求分析。所以, 重视需求、谨慎对待、严密分析, 是每一个开发者应该持有的正确态度。建立软件需求管理过程的目的在于用户和软件项目组之间形成共同的理解, 这种共同理解应体现在用户需求的文档化确认和对用户需求的控制中, 并保证项目的计划、工作产品和活动都与需求一致。
1 需求管理复杂性分析
软件需求是整个软件开发项目的最关键的一个输入, 和传统的生产企业相比较, 软件的需求具有模糊性、不确定性、变化性和主观性的特点, 不同于生产汽车、电脑等硬件的需求, 是有形的、客观的、可描述的、可检测的, 软件需求是企业软件项目最难把握的问题, 其复杂性体现在以下方面:
1.1 需求的描述问题。
缺少正式的、完整的需求文档浪费了大量的人力物力, 但是有了需求文档又出现了新的问题。在用户方进行的需求评审会完全是走形式, 因为用户根本不去听那上百页的需求文档。不同层次的客户 (用户) 关心的问题是不一样的, 想要每个客户都成为需求专家是不现实的。
1.2 需求的完备程度问题。
需求如何做到没有遗漏?如何准确划定系统的范围?这确实是一个两难问题, 稍微大一点的系统要想穷举需求几乎是不可能的, 每次开需求评审会时, 总会冒出新的需求, 以至于系统没有一个准确的范围界定。即使是这样, 系统还是要开发, 系统的范围还要硬性的划定一个, 从而建立一个基线。
1.3 需求开发的工期问题。
在需求上花费了大量的时间, 客户、企业是否能够忍受?为了确保需求的正确性, 完备性, 项目经理往往坚持要在需求阶段花费大量的时间, 但是客户与企业的高层领导却会为项目迟迟看不到实际可运行的软件担心不已, 他们往往会催促项目组尽快往前推进, 而项目组的成员往往也会被系统复杂、善变的需求折腾的筋疲力尽, 希望尽快结束需求分析的相关工作。
1.4 需求的细致程度问题。
需求到底描述到多细, 才算可以结束了?仁者见仁, 智者见智, 并没有定论, 如果时间允许, 要想细总可以细下去的。但是, 需求的周期越长, 可能的变化越多, 对设计的限制越严格, 对需求的共性提取要求越高, 所以只要客户 (用户) 、需求分析人员、设计人员、测试人员认为描述清楚了, 就可以进入设计阶段了。
1.5 需求的变化问题。
在软件开发过程中如果只有一条真理的话, 那一定是:需求的变化是永恒的, 需求不可能是完备的。软件开发的过程实际上是同变化做斗争的过程, 需求的变更不一定是坏事, 也有可能是好事, 是商业机会, 对市场敏感的人可以从需求的变化中发现市场机会。
2 需求变化的原因:
需求变化的原因很多, 比如: (1) 一开始没有识别全, 需要增加需求; (2) 业务发生了变化, 需求必须变化; (3) 需求错误; (4) 需求不清楚。
需求的变化问题是每个开发人员、每个项目经理都遇到的问题, 也是最头痛的问题, 一旦发生了需求变化, 项目组不得不修改设计、重写代码、修改测试用例、调整项目计划等等。需求的变化好像为项目的正常的进展带来不尽的麻烦, 怎么办?只有通过需求管理使需求在受控的状态下发生变化, 而不是随意变化, 需求管理就是要按照标准的流程来控制需求的变化。难题随之而来, 需求中的变化一般不是突发的革命性的变化, 最常见的是项目需求的渐变 (Proje ct Scope Cre e p) 问题, 这种渐变很可能是客户与开发方都没有意识到的, 当达到一定程度时, 双方才蓦然回首, 发现已经物是人非, 换了一番天地。
3 需求管理策略
需求管理需要遵守以下策略:
3.1 需求一定要与投入有必然的联系
需求一定要与投入有必然的联系, 否则如果需求变更的成本由开发方来承担, 则项目需求的变更就成为必然了。人们常说世上没有免费的午餐, 同样也不应该有免费的需求变更。但是, 接受需求变更目前却是软件企业不得不咽下的苦果。所以, 在项目的开始无论是开发方还是出资方都要明确这一条:需求变, 软件开发的投入也要变。
3.2 要充分理解客户提出来的需求
开发者应该理解客户的需求, 如果这点做不到, 后面的工作是没有意义的, 所以, 那种在没有理解需求的情况下, 就仓促开发的做法是不合适的。
3.3 需求的变更要经过出资者的认可
需求的变更引起投入的变化, 所以要通过出资者的认可, 这样才会对需求的变更有成本的概念, 能够慎重地对待需求的变更。
3.4 做好需求文档的版本管理
记录用户需求、系统需求、软件分配需求的文档都要作为基线确定下来, 做好相关文档的管理工作。需求的基线是指是否容许需求变更的分界线, 需求分析人员在充分与客户用户进行沟通的基础上形成第一个版本的需求文档, 这个需求文档在通过需求评审后即可以建立第一个需求基线。此后每次需求变更并经过需求评审后, 都要重新确定新的需求基线, 以免将来用户需求发生变更时, 原来的需求无法查找。为有效进行需求变更控制, 必然要做的工作就是保存好各个版本的需求基线, 维护需求基线文档, 以备不时之需。
3.5 小的需求变更也要经过正规的需求管理流程
小的需求变更也要经过正规的需求管理流程, 否则会积少成多。在实践中, 人们往往不愿意为小的需求变更去执行正规的需求管理过程, 认为降低了开发效率, 浪费了时间。正是由于这种观念才使需求的渐变不可控, 最终导致项目的失败。
3.6 精确的需求与范围定义并不会阻止需求的变更
并非对需求定义的越细, 越能避免需求的渐变, 这是两个层面的问题。太细的需求定义对需求渐变没有任何效果, 因为需求的变化是永恒的, 并非需求写细了就不会变化了。
3.7 注意沟通的技巧
由于需求的变更可能来自投资方、也可能来自用户方和开发方, 作为投资方可能不愿意为需求的变更付出更多的成本, 而开发方有可能主动的变更了需求目的是使软件做的更精致。于是作为需求管理者, 项目经理需要采用各种沟通技巧来使项目的各方各得其所。
4 结束语
需求管理是软件项目中一项十分重要的工作, 据调查显示在众多失败的软件项目中, 由于需求原因导致的约占到45%, 因此有效的需求管理是企业软件开发项目顺利达成目标的重要支撑条件。理解项目开发的目的和用途, 梳理用户需求, 设计系统的各项功能需求, 监控需求变化, 进行需求确认, 对需求风险进行防范, 以一系列的方法和措施实施需求管理工作, 才能推进软件项目良性发展, 达到用户与软件开发企业的双赢。
摘要：需求管理是整个软件工程的管理的基础, 也是项目成功的关键所在。本文论述了企业软件开发项目中需求管理的重要性, 详细描述了软件需求的复杂性, 分析了需求变化的原因, 并针对这些问题提出相应的管理策略。
关键词：需求管理,软件需求,需求变化
参考文献
[1]吴艳艳.软件项目管理中的需求管理[J].信息技术与信息化, 2008 (2) .
[2]唐薇娜.正确应对需求变更[J].软件工程, 2007 (6) .
试论软件项目管理中的需求管理 篇8
1.1 需求管理的基本定义
国际上关于需求管理的定义很多,当前最为广大研究人员及用户认可的是Rational所定义的在尚未完成的系统必须具备或符合的条件及功能。
正是因为需求是尚未完成的系统必须绝对符合的条件,同时这些界定的条件将最终决定该类系统的构建是否成功,所以将需求的条件找出,并经过综合的分析和组织,当某一环节发生变化时积极及时精确的予以调整,则会取得积极有益的效能,从而使整个系统的构建变得更有价值。简而言之,需求管理就是研判、调整及综合分析与组织的一种系统优化方案,同时它还是项目组织与所属客户之间通过不间断的沟通变更而实现系统最优化配置的一种有益过程。
1.2 需求管理的现实意义
需求管理的存在意义取决于该项目研发团队对于系统构建的终极目标,即没有一个软件项目组织希望自己的研究对象或是构建目标最终趋向失败,否则研究将变得没有任何意义。需求管理的存在正是由于它对于项目研发团队来说是取得成功的基本条件和前提。业界最具影响Standish Group的CHAOS Reports通过近8年(1994年-2001年)的跟踪研究证实,项目研究失败的最本质原因是与需求管理有关的。Standish Group在对多个软件项目的跟踪调查和综合分析显示,由于缺乏对于需求管理的严格界定,导致在系统构建和项目研发中74%的项目最终以失败告终。
较之其他的客观条件,需求管理的生命周期更长,它在软件项目的整个研发过程当中,一直存在,并且起着关键性的作用。正如万事开头难,在软件研发的初始阶段,需求管理的界定也是最为关键和最难把握的问题。失去了严格界定的需求管理条件,那么该软件项目就会根基不牢,研发也将半途而废。当然,通过对每一次软件项目的研发经验积累,用户在软件项目的立项、研究、构建和后期维护方面的掌控都会越趋于成熟,同时也会积极地进行反馈、调整、完善,促进软件构建的更加合理化、人性化,从而推动整个软件项目管理业发生积极有益的变化。在软件项目的整个管理过程中,项目负责人将会经常面临客户对于软件的各种需求和变更,一方面这些需求和变更对于软件项目的优化是积极的,而另一方面如果项目负责人处理不当,那么这种需求和变更对于软件项目的优化又是消极被动的。正是需求管理的双面性造成软件项目研发过程中是一个动态变化的过程,如果以不变应万变的态度来应对客户需求,那么最终将导致该软件项目的交付时限被延迟、成本被追加、客户需求被弱化。正是趋于这些因素考虑,研发团队必须高度重视需求管理的重要性,具备较高的需求管理的战略眼光。
2 需求管理的发展
步入21世纪以来,信息时代的飞速发展,导致计算机的普及率越来越高,而与之配套的计算机软件却未能跟上发展的步伐,缺乏超前性、智能性和人性化是当前所有软件的通病,并且随着信息时代的发展,与之对应的软件需求也将越来越大,而差距亦将越拉越大,这种软件需求危机自上世纪八十年代就已开始,持续了30多年之久,截止到目前也没有得到较好地缓解和解决。虽然软件研发本身存在着滞后性的现实问题,但是软件开发的手段、软件研发过程当中质量监管、软件后期的维护都是造成软件效能发挥不明显的最关键原因。通过具体的研究和调查分析,软件项目的开发和后期维护的不合理性主要体现在:一是对于软件的客户需求分析的不够透彻;二是在整个研发过程中没有规范的需求管理方法;三是对于软件应用的指导性文件表述不够规范细致;四是独立与客户群体进行自行研发,缺乏实用性和认同性;五是在研发后期受资金和交付时限的限制,对软件的测试过于简单化;六是在交付给客户后,缺乏相应的后期维护和跟踪调查,工程报告反馈性不强。
正是由于这些因素的存在,往往在软件交付以后,客户对软件系统的难于操控和掌握,以及更新维护和问题处理方面带来的不够便捷方面,抱怨不断。综合这些不利的因素,业内形成了一种共识,就是在软件项目研发过程中要坚持工程化的指导原则和逻辑化的结构体系来实现整个项目的推进,从而使得多年来持续软件危机得到了较大的缓解。
软件的需求分析是整个软件研发过程当中的初始阶段,也是关键性的阶段,并且贯穿在软件生命周期的全过程。正是其特殊的地位作用,从上世纪80年代中期开始,软件的需求分析就逐渐成为软件项目工程中的一项独立的子项目,而进入90年代中后期,关于需求管理的研究已成为软件业研究的一个重要学科。从1993年起,每隔2年举办一次的需求工程国际研讨会(ISRE),到1994年起,每两年举办一次需求工程国际会议(ICRE),都足以证明软件需求分析的重要作用所在,同时一些关于软件需求分析的研究团队和项目小组陆续成立。
3 需求管理面临的问题
3.1 需求表述的精细性
正如文前反复强调的需求分析对于整个软件项目的研发和实现的极其重要作用,如何将对软件需求表述的更加精细化,是摆在每一项目团队和研发人员面前的一个现实问题,简单的讲,表述的越趋于细致,那么问题变现的就越突出,便于最终的解决。在项目团队与客户就软件项目的研发问题上,其立项的方案是明确和基本一致的,但是如何研发、如何确保软件的按期交付、如何实现软件的便捷性和人性化,那将是一个不断沟通和理解支持的过程。若是这些过程都是在初步达成意向的前提下展开的,这就造成在软件研发过程中始终存在计划修改、方法变更和交付推迟等种种问题,并最终影响双方的效益取得。同时在软件的需求分析阶段,研发人员往往把较大的精力集中于软件的基础架构上,希望将自己的合理化架构雏形较早地呈现在客户面前,并进行后期的改进,而客户则认为只有每一步的及时掌握才能有效避免返工现象的发生,所以双方很难就这一问题达成共识,造成信任危机。类似这样的现象在这个研发过程中还有很多。正是由于这些问题的存在,如何针对软件需求做出较为精细化的工程报告,对于软件工程的顺利实现有着积极的意义。
3.2 需求表述的严谨性
软件项目的研发是一种严谨的专业行为,普通的客户无法了解软件研发人员的专业性思维和理念。因此,当研发人员与客户沟通交流时,针对客户主观上认为可以通过软件实现个人任何需求的想法时,研发人员必须克服急躁心理,既不能用专业的理论去敷衍客户,也不能刻意指责客户想法的不合理性,而应从最大限度的满足客户需求的角度去通俗化解释软件的最终效果。同时,由于客户缺乏相应的软件专业知识,造成自己的想法与最终的表述存在偏差,并且这种偏差是绝对存在的,还有一些客户在表述上本身就存在矛盾性,并且坚持不改这种决定,那么在软件的研发过程中必然会造成客户的需求和愿望很难实现或是即便实现了也是与客户需求存在差距。为了尽可能地缩短这种差距,这就需要软件研发人员在需求表述方面具备一定的严谨性,因为只有规范的表述,才能在与客户的沟通中尽量消除理解上的偏差。不要忽视这种表述上的严谨性,如果由于研发人员在与客户之间因为表述不够规范而造成理解上的偏差,并且这种偏差在软件交付使用时才被发现,那么这种损失将会是极其可怕的,甚至会出现超出软件项目本身的研发费用。因此养成严谨的规范表述,将会减少对客户需求方面理解的偏差,这对于项目团队本身是积极必要的。
3.3 需求表述的完整性
正如软件本身的缺陷,往往无法对客户所有意愿进行体现,并且客户的需求随着软件的使用会不断地增多,从而导致软件本身的缺陷也越来越趋于明显。同时,还应看到的是,并不是客户的所有需求都能得到满足,一味的追究软件的完整性,必将导致整个软件项目的庞大和入不敷出,并且最终的结果往往还是无法实现万能。因此在软件项目的立项之初,建立完整的需求是必要的。因为它能促进软件项目的架构合理和交付应用的高效便捷。忽视需求表述的完整性是绝对不可的,但是盲目的追求需求表述的完整性也绝对是不够理性的。
3.4 需求表述的动态性
需求管理是一个动态变化的过程,较之其它问题,该类问题更让所有的项目研发人员和项目经理感到头疼,因为需求是随着客户的意愿随时存在的,并且随时都可能发生,而作为软件的研发人员往往只能被动的接受这一现实,选择修改软件设计方案、重新编译代码、调整测试实例、甚至是项目计划本身都会出现大的变动等等。每一次需求的变更,都会造成整个软件项目的改变,给整个研发过程带来无尽工作负担,直接影响软件的交付使用。当然这种动态性是不可避免的,但却是可控的,因为需求管理本身就是对软件研发流程的一种严格规范,而需求变化本身也不是一种质的变化,而是较为常见的渐变过程(Project Scope Creep)。虽然在真正的实践过程中,这种渐变往往不为研发人员和客户所察觉,但是它确实存在,并影响着软件项目本身。
4 解决问题的策略
4.1 正确认识需求变更
变更的需求之所以变得难以管理,不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性,而且也因为对某个需求的变更很可能影响到其他需求。应确保赋予需求一个有弹性的结构,使它能适应变更,并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系。管理变更包括建立基线,确定需要追踪的重要依赖关系,建立相关项之间的可追踪性,以及变更控制等活动。
4.2 管理需求变更
变更控制不应该只是软件开发过程应该考虑的事情,随着软件产品的开发和时间的推进,用户会提出越来越多的新需求,甚至在交付软件产品的最后阶段用户还会有不同的需求,因此需求变更的管理应贯穿于整个项目生命周期的全过程。
为了使变更对项目的影响降到最小,就应当采取合适有效的变更控制策略,确定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此流程。对需求的变更的处理应该分以下几个步骤:提出变更、变更评估、实施变更、监督变更过程。
4.3 与用户充分沟通
在需求管理过程中与用户的沟通很重要,因为它直接决定着最终软件产品是否满足客户的要求,即很大程度上决定着项目的成败。在沟通时,双方对需求的认识要一致,不能模棱两可。讨论需求及变更需求时,需求人员与客户及用户应该尽量采取协作的态度,创设良好的工作氛围。有效的充分的交流很重要,需求人员应该认真听取客户用户的要求,进行分析和整理,并最终取得用户的确认。
5 结束语
需求管理是需求分析过程中的一个步骤,提供的是一个持续的不断完善的过程,软件项目开发过程中需求管理的问题有很多,随时都有用户需求变更,需求分析的错误也时常发生,需求质量难以保证,针对这些问题,采取有效的措施尽可能减少这些问题可能给项目造成的影响也显得尤其重要。
摘要：需求管理对于整个软件项目工程起着基础性的影响作用,同时也是项目实现和软件交付的关键所在。该文通过对软件项目中需求管理的基本定义进行阐述,并从其自身发展和面临问题两个方面进行论述,针对性地提出了解决软件项目管理中难题的方法,对软件项目团队和研究人员具有积极的借鉴和参考意义。
关键词：软件,项目管理,需求管理
参考文献
[1]吴艳艳,周长伦,姜家轩,等.软件项目管理中的需求管理[J].信息技术与信息化,2008(4).
[2]孙莉.软件项目管理中的需求管理[J].信息系统工程,2011(4).
[3]刘苗.管理需求变更问题的软件设计与实现[D].成都:电子科技大学,2010.
[4]姚海峰.多方合作软件项目的需求管理[D].上海:上海交通大学,2008.
[5]窦勇.通信企业IT项目需求变更管理研究[D].北京:北京邮电大学,2009.
软件项目需求管理论文 篇9
关键词：项目管理,软件需求开发,进度,成本,质量,管理模型
一、引言
软件需求开发是软件工程的一个重要环节, 在软件生命周期中的需求、设计、编码、测试和维护等各个阶段中, 需求开发处于软件工程的开始部分, 它提供构建软件项目的根基, 决定软件开发成果满足客户需求的匹配程度。软件需求开发环节的失误会随着开发进度的扩大而蔓延, 资料表明, 软件项目中由于需求开发管理混乱而造成的返工开销几乎占了总开发的50%。本文应用项目管理理论分析软件需求开发阶段的系统构成, 并设计管理模型来提高软件需求开发的管理效率。
二、软件需求开发管理过程
由于计算机技术的迅速发展, 使得软件需求具有模糊性、不确定性、变化性、主观性等特点, 并带来软件需求开发管理的复杂性。软件需求开发是一定的组织利用有限的资源在规定的时间内完成, 可以作为项目来进行管理, 其管理过程由需求获取、需求分析、编写软件需求规格和需求验证四个阶段构成。
1. 需求获取
需求获取是在问题和最终解决方案之间架设桥梁, 其主要任务是和用户方的领导层、业务层人员进行沟通, 获取用户的具体需求, 并了解用户的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等具体情况, 同用户建立起良好的沟通渠道和方式。软件需求获取的方法有:与用户交谈, 向用户提问题;参观用户的工作流程, 观察用户的操作;用户工作的情景分析;现有系统的问题报告和改进要求, 事件和响应;市场调查和向用户群体发调查问卷;与同行、专家交谈, 听取他们的意见;分析已经存在的同类软件产品, 提取需求;从现有产品或竞争产品的文档中提取需求;从行业标准、规则中提取需求;从Internet上搜查相关资料等。
2. 需求分析
需求分析主要通过建立业务模型的方式来描述用户的功能需求, 为客户、用户、开发方等不同参与者提供一个交流的渠道。业务模型可以映射出软件产品的核心需求, 即功能需求。功能需求应描述软件提供的功能和服务、对输入的响应, 并描述特定条件下的系统构成等。软件产品本身可能还存在与业务无直接关系的非功能需求, 具体与系统的总体特性有关, 如可靠性、响应时间、存储空间等。非功能需求定义系统提供服务或功能的约束, 包括时间约束、空间约束、开发过程约束及应遵循的标准等。通常这两类需求构成软件需求的总集。
3. 编制软件需求规格
软件需求规格的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解, 使之成为整个开发工作的基础, 需求分析完成的标志就是提交一份完整的软件需求规格说明书。软件需求规格说明书以一种开发人员可用的技术形式阐述软件必须提供的功能和具备的性能, 以及必须考虑的限制条件。软件项目客户通过软件需求规格了解软件项目能够提供的软件产品, 检查软件需求是否满足需要;项目管理人员根据软件需求规格制定项目的开发计划和管理过程;软件开发人员通过软件需求规格理解要开发的产品及具体要开发的内容;软件测试人员通过软件需求规格验证软件。
4. 需求评审
编写的软件需求规格说明书还应当进行需求评审, 确保需求确定的科学性。可采用下列指标进行评审: (1) 正确性:每条需求都正确代表构建软件系统所要完成的事情。 (2) 无歧义:每条需求只有一种解释。 (3) 完备性:需求不能发生遗漏, 应全面考虑相关问题。 (4) 一致性:用户需求必须和业务需求一致, 功能需求必须和用户需求一致。 (5) 重要性和稳定性分级:现有资源不足以实现所有需求时, 可以根据级别的高低决定实现的先后, 舍弃一些级别低的需求以保证项目的按期交付。 (6) 可验证性:需求分析是可测试的, 只有系统的所有需求都是可以被测试的, 才能够保证软件始终围绕着用户的需要, 保证软件系统是成功的。 (7) 可修改性:每一条需求都易于完整一致的进行变更, 且不改变需求集的结构和风格。 (8) 可跟踪性:每条需求都是可溯源的, 且存在一种机制使得在以后的工作中引用需求是可行的。 (9) 可理解性:用户和开发人员都完全理解需求集的整体行为、所提供的功能及其中的每条需求的含义。
三、软件需求开发管理模型
1. 软件需求开发管理模型构建原则
软件需求开发是一项复杂的系统工程, 管理模型的构建应遵循下列原则: (1) 程序性原则:软件需求开发管理应遵循固定的业务流程, 可将其划分为需求获取、需求分析、编写软件需求规格和需求验证四个阶段, 前一阶段的工作完成后才能进入下一阶段。 (2) 系统性原则:软件需求开发要在限定的时间、成本条件约束下达到一定的质量, 实现软件系统的最优, 要求管理遵循系统管理原则, 实现目标最优。 (3) 简化性原则:化繁为简, 将模糊的、潜在的复杂问题明确化, 以图表的形式表示出, 并以简化的解决方案解决问题, 便于项目管理。 (4) 平衡性原则:管理软件需求开发的具体事务要有一定的侧重。对于需求开发过程事项, 应根据影响大小分清主次, 关键的事项或者事项里的某个多发问题点, 着重管理, 达到在管理上的主次平衡。 (5) 高效性原则:模型的设计必须以促进需求开发目标的实现为前提, 提供给相关人员一个展示需求开发管理和有效解决方案的平台。 (6) 时时控制性原则:及时控制需求开发过程中影响进度、成本、质量等问题, 及时发现解决冲突事件, 做到事前、事中、事后控制, 保证项目按时保质保量完成。 (7) 动态性原则:开发中应关注信息技术的发展, 将先进的技术应用到软件需求开发中, 并学习借鉴相关软件需求开发的成果。
2. 软件需求开发管理模型
基于以上分析, 本文构建了软件需求开发管理模型, 见下图:
该模型遵循了软件需求开发的管理流程。启动阶段, 软件开发进行了可行性研究, 软件项目已立项, 项目正式启动。软件需求开发管理阶段是模型的主要部分, 按照项目流程, 依次划分为需求获取、需求分析、编写软件需求规格和需求验证四个阶段。总结阶段, 对软件需求开发管理进行总结, 并进入到软件程序设计阶段。模型的核心部分是应用项目管理的进度管理、成本管理、质量管理, 对软件需求开发进行动态管理。进度管理就是制定出经济合理的进度计划, 然后在计划执行过程中, 检查实际进度与计划进度之间的差异, 并及时找出出现差异的原因, 采取有效的补救措施, 以确保项目按时按质完成。进度管理应加强沟通, 掌握可能延误进度的环节, 并严格控制进度变更。成本管理就是对项目所需的成本情况进行详细地分析和估算, 编制资源需求计划, 并编制项目所需的成本估算和预算, 在执行过程中, 采取相应的措施对项目成本进行控制。成本管理应严格控制加班、浪费等额外支出。质量管理是为了保证项目的可交付成果能够满足客户的需求, 围绕项目质量而进行的计划、协调和控制等活动, 其具体内容涉及质量规划、实施质量保证和质量控制。通过进度管理、成本管理和质量管理, 使软件需求开发成为进度快、成本低和质量合格的有机统一体。
该模型规范了软件需求开发的业务流程, 并在整个软件需求开发的不同环节之间建立联系, 明确需求开发过程与自身各任务项之间以及项目其余环节所存在的各种联系。模型各环节间的相关性、可追溯性保证了软件项目需求开发过程, 可以遵循统一的管理模式。该模型具备可配置性。每个软件项目, 都具有个性化管理需求, 在进度管理、成本管理、质量管理等方面有不同的要求, 可以针对具体的开发团队, 项目要求, 管理侧重点, 扩增相应的管理模块, 将此模型推广到任何一个软件需求开发项目。
3. 模型应用
由于软件需求开发具有复杂性, 其主要表现为需求描述问题, 明确表达需求较难确定, 并且难以统一;需求完备问题, 需求没有遗漏, 难以准确划定系统范围;需求的变更问题, 需求变化是永恒, 需求不可能是完备。模型应用需做好以下工作: (1) 文档化管理。需求必须有文档来记录, 该文档必须是正确的, 是经过验证的, 是在受控的状态下变更的。开发或管理人员常常会在含糊的情况下把认为是相对简单的需求忽视而省略文档记录, 其实未必简单, 只有想清楚、写清楚、说清楚才说明已经真正把需求整理清楚了, 同时方便日后维护工作的展开。需求含糊的情况下要进行会议形式处理, 并邀请相关人员参加进行需求澄清及确定, 需求在进行多方确定后进行归档。同时软件需求的复用率也是相当高的, 可以避免升级时重新将需求再次获取, 只需要在原来的基础上作为文挡需求复用升级处理。 (2) 审核评估需求变更, 减少变更的影响。在管理软件开发过程中, 需求渐变是必然的, 无论需求变化的程度如何, 只要需求变更就必须进行评估。在需求变更之前必须由项目管理人员审核, 再传给开发人员进行评估等工作。管理人员必需依据对整套系统的了解程度分析需求变更过程中可能受影响的系统及受关联的功能模块, 并制定积极应对措施。 (3) 整体管理。应识别、确定、结合、统一与协调软件需求开发管理过程中所需要进行的各种过程和活动, 保证进度、成本、质量等各要素的相互协调。
四、结语
软件需求开发在软件项目管理中具有重要地位。本文应用项目管理理论, 设计了软件需求开发管理模型。该模型遵循项目管理流程, 将软件需求开发划分启动、需求开发过程、总结三个阶段, 并将软件需求开发过程划分为需求获取、需求分析、编写软件需求规格和需求验证四个阶段, 模型应用项目管理的进度管理、成本管理、质量管理, 对软件需求开发进行动态管理, 实现软件需求开发项目目标最优。该模型能够提高软件需求开发管理效率, 确保软件开发能够按进度, 低成本, 高质量地完成。
参考文献
[1]景慎艳:软件项目需求管理的探索与实践[J].电脑知识与技术, 2008 (27)
[2]左怀远:软件项目中的风险管理研究[J].世界科技研究与发展, 2008 (3)
[3]孙琦龙:加强软件项目管理的实践模式[J].科技信息, 2008 (7)
[4]潘加宇:软件工程与项目管理[J].程序员, 2007 (12)
计算机软件项目管理中的需求分析 篇10
一、软件项目需求分析的重要性
软件系统的开发主要分为五个阶段,分别是系统的需求分析阶段、系统设计阶段、系统实施阶段、系统测试阶段和系统维护阶段。而需求分析阶段是整个五阶段中的重中之重,在该阶段所占的工作量大概是整个软件开发项目的50%,逻辑方案是该阶段的最终成果。逻辑方案不仅是进行系统设计的依据,而且,还是系统最终验收的说明性文件。从以往的经验来看,需求分析做的不彻底,没有深层次的挖掘用户需求,往往可能导致整个项目无法达到预期的效果,或者说设计开发出来的产品不能满足用户的需求。
需求分析首先要对现有系统有充分的认识和了解,在此基础上,通过识别关键问题、分析项目的可行性、详细调查研究、系统化分析,最终设计完成该项目的新系统逻辑方案。只有系统分析员明白了用户的真正需求,才能开发出满足用户的软件产品。在这里,要强调一点的是,在做需求分析的时候,开发方一定要指派有实际工作经验的系统分析员来与用户沟通,而不是指派具体的开发人员,这将避免一些沟通不畅的问题发生。系统分析员在了解用户的基本需求之后,要以书面的形式,准确地制定出软件需求报告。该报告主要说明系统的行为属性,是项目开发过程中对系统的制约。要实现这一目标,就需要系统分析员与用户之间做到紧密协作,甚至系统分析员要深入到用户方的实际业务当中,把自己当做是用户,从用户的角度思考问题,只有这样,开发方才可以真正了解用户需要什么,系统应该做什么。
二、规范执行需求分析的流程
需求分析的过程,要严格执行规范化操作,囫囵吞枣式的需求调研是不可取的。开发方在做需求分析过程中,一定要严格把关,从对用户负责的角度出发,并且也为了降低自己的开发成本,对无法与用户实现很好沟通的项目经理要及时叫停,避免后续工作无法正常进行。
按照需求分析的过程,同样也可将其分为五个阶段:首先要获取用户需求,其次是分析用户的需求,第三是编写需求文档,第四是评审需求文档,最后是管理需求。规范执行需求分析的流程,是需求分析能否成功的关键。图1是根据实际工作经验总结出的需求分析工作流程:
在需求分析过程中,开发方要深入用户方的各个部门,最简单的项目也要做到用户确认需求和需求评审两个过程,复杂的项目甚至要做到多次。
三、尽快熟悉项目用户方干系人全貌
项目干系人又称为项目相关利益者,是指积极参与项目、或其利益会受到项目执行或完成情况影响的个人或组织,项目干系人对项目的目的和结果施加影响。项目管理团队,即开发方,必须识别项目干系人,确定他们的需求和期望,尽最大可能地管理与需求相关的因素,以获得项目的成功。因此,应当从项目的启动开始,系统分析员用户方相关人员的配合下,逐步分清项目用户方干系人具体包含哪些人和部门,通过开方法与其沟通加之用户方领导的协调以驱动他们对项目的支持,从而减小其对项目的阻力。
有些项目在做需求调研时,因受用户方提出的进度要求等因素影响,有些系统分析员不愿与用户过多地交流,只是发一些调研表做一些大概的了解。往往是因为开发方已有与该建设单位相似的原型,会亟不可待地去推广,这样会导致某些差异需求得不到深入了解,用户方只能被动地去适应原型系统,这样的做法是不可取的。另一种情况则是开发方与用户方的技术部门交流比较多,而向业务部门和实际使用人员调查的力度不够,往往容易造成原型试用后,与用户的需求不一致,不得不再对需求做较大调整,造成开发周期不断延期,开发成本大大增加。因此,熟悉项目用户方干系人全貌是进行需求调研的第一步,也是需求调研的基础。在定制的开发项目中,最重要的是要弄清楚用户方中的组织结构关系、业务流程关系、数据流程关系。制定该项目的牵头单位,在此基础上,使用图表的形式将这三种关系表现出来。
四、采取正确的方法获取用户需求
软件开发项目的首要目标就是要发现用户的需求。在对用户进行需求调研过程中,使用的方式很多,初期调研可以采用会议的形式,后续的详细调研以及需求确认,可以采用电话、邮件、小组讨论等方式,模拟演示也是一种很有效的形式,用户比较直观,容易发现、提出问题,但每一次调研过程当中,都要做好笔录,当与用户交流完毕以后,要对交流的结果进行整理、分类,便于后续的分析活动。系统分析人员要对收集到需求做进一步的梳理和分析工作,在这个过程中,首先要对用户提出的具体需求,包括可能该项目目前不涉及的需求,都要知道“为什么”,并且判断用户提出的需求是否合理,对于不合理的需求,开发方要给出不合理的理由和原因。其次,要集中精力,把关注点放在需求分析阶段关注的目标上,即“做什么”,而不是“如何做”,第三就是要分析用户提出的需求当中所衍生出的隐含需求,这一点往往容易忽略掉,这就需要系统分析员在与用户交流当中,关注用户的表情、眼神、用语,因为对隐含需求不加以考虑或考虑不充分,往往会引起永无止境的需求变更。
在需求调研中,还要把握要求相关业务人员与领导同时出席,这将避免用户所提需求的不负责任性和随意性,以及对需求的确认不够积极等问题。项目开发方应掌握用户干系人需求,用户干系人也应具有一定的技术基础,两者缺一不可,只有这样双方沟通起来才比较容易达成一致。对某些需求,用户可能无法想到,系统分析员要做到引导用户的作用,并且要有足够的耐心聆听用户的讲述。
五、分析用户需求并编写需求调研报告
调研结束后,开发方要根据用户的需求编写需求调研报告,即提出新系统的逻辑方案。获取用户需求与分析用户需求二者之间并不冲突,完全可以同时进行,关键问题是如何详细地描述用户的需求,常用的方式是通过建立相关的模型来操作。通过建立模型,抽象出用户的需求,以一种可视化的方式与用户进一步沟通。获取用户需求与分析需求二者之间有着类似的步骤,不同之处仅在于分析用户需求时采用模型来描述。分析用户需求所执行的活动如下:
1.用业务流程图描述系统的整体业务活动,包括系统之间的接口和边界。
2.用数据流程图模型来描述系统的数据流关系。可以采用多层次的数据流程图加以描述,对于复杂的数据流关系或功能处理模块要配以数据字典。
3.通过原型向用户展示系统界面以及各项功能模块,用户可以拿自己的需求与其相比较,存优去劣。
4.采用实体关系图描述实体、属性、关系三者之间的联系。
在编写需求说明书时,可以采用自然语言或结构化语言来加以描述,当然,可以将需求分析阶段的各类图表列入到需求调研报告中,需求文档应该包括用户的所有需求(包括功能性需求和非功能性需求),这便于在需求确认和需求评审阶段,使用户一目了然,容易理解。
六、项目的需求确认和需求评审
开发方要从两个角度出发来描述系统,一是全面详细地描述现行系统的缺陷和不足,以及业务流程存在的不合理之处。二是在业务流程重组的基础上,提出新系统所优化的各项业务流程和系统所具有的优点。并将二者业务流程文档化后与客户进行探讨,对于描述不准确不精确的地方要加以细化,对于错误的地方要进行修改,最终让客户进行确认。需求评审的目的就是对需求分析阶段的成果做出评价,提出不足,进一步优化流程,纠偏、完善需求调研报告。需求确认与评审是不可逾越的两个阶段,有研究表明:由客户发现的一个错误,然后更正错误,约需要多花90倍的时间,可以看出,需求确认和评审阶段的重要性。
需求评审的关键在于邀请这方面的专家、用户、领导对新系统进行评价。当然,在确认评审阶段,开发使用双方都要在场,开发方在讲解需求报告时,要做到细致入微,不能放过任何一个功能模块,使得双方共同找出需求调研中不合理的、不完善的、有歧义的、遗漏的问题。需求评审的目的是要获得用户的认可,如果用户用户以种种理由不以确认,那么系统分析员要尽快拿出原型系统来给用户确认,否则后续的工作将无法顺利开展,并伴随着无穷无尽的需求变更。
参考文献
[1]黄梯云.管理信息系统(第四版)[M].北京:高等教育出版社,2008.
[2]吴洁明.软件工程应用实践教程[M].北京:清华大学出版社,2003,(8).
[3]赵池龙.实用软件工程[M].北京:电子工业出版社,2006.
软件项目管理课程教改革探索 篇11
关键词 软件项目管理；理论教学；实践教学
中图分类号：G642.0 文献标识码：B
文章编号：1671-489X（2015）15-0121-02
随着软件产业的不断发展，社会对软件项目管理人员的需求数量以及能力的要求也再不断提高。一个软件企业的发展离不开高能力的项目管理人员，成为一名成功的软件项目管理人员学习理论知识是基础，而实践经验是重点。软件项目管理课程是一门项目管理的原理和方法在软件工程领域中应用的课程。教育的目的是满足社会的需求，通过软件项目管理课程的学习能提高学生软件开发水平，培养学生的项目沟通能力，对社会培养软件项目管理人员具有重要意义。在该课程的教学中将理论教学作为基础，理论知识融入虚拟环境中，以开发模拟项目为重点，达到最终的教学目的。
软件项目管理作为一门理论联系实践比较强的课程，分为理论教学和实践教学两部分，课程总课时数为52学时，其中理论教学40学时，实践教学12学时。下面将理论教学和实践教学中涉及的内容以及应用的教学方法分别进行探讨。
1 理论教学
教学内容 软件项目管理重点内容是项目管理的九大知識体系，课程内容庞大、复杂、抽象、概念多。为了考虑课程的适用性，在课程内容的安排上以软件项目管理过程为主线，引出项目管理的知识点，主要介绍软件项目需求管理、成本管理、进度管理、风险管理、配置管理、资源管理、质量管理等七个方面，其中需求管理、进度管理、成本管理、风险管理、质量管理作为重点内容详细讲解。考虑课程内容的连贯性及教学时间的局限性，课程的教学内容和课时分配如表1所示。
教学方法 在教学中使用案例驱动式和分组讨论的教学方法。软件项目管理是项目管理的原理和方法在软件工程领域中应用的课程，属于管理类课，其中抽象概念较多，而任课学生都是缺乏实际项目开发经验的本科三年级学生。因此，为了让学生易于理解与掌握教学内容，笔者在理论教学中使用案例驱动式教学方法。考虑到课程内容的前后连贯性，在备课的时候就先选择好能贯穿该课程所有教学内容且能够体现软件项目管理全过程的大案例，教学中师生共同分析案例，分析时力求能全面，从案例中找出隐含的教学知识点，将抽象的概念通过案例具体化，使学生生动地理解教学重点，掌握教学难点。通过课堂作业与历年计算机等级考试中软件项目管理题作为训练内容，让学生更进一步理解和掌握教学重点、难点，必要时布置课堂作业，甚至让学生上讲台，在黑板上演算作业，师生共同探讨演算过程中的问题，并对其进行点评加深和巩固对知识点的理解，同时也督促学生集中精力听课。
2 实践教学
教学内容 软件项目管理理论教学使学生了解软件项目管理的概念、原理与方法，通过实验教学使学生将在理论教学中学到的知识应用到实践中。Microsoft Project是项目管理软件。软件设计目的在于协助项目经理发展计划、为任务分配资源、跟踪进度、管理预算和分析工作量。在实践教学中让学生熟练掌握Project软件的各项操作，并且通过上机实验练习，使学生将软件项目管理与Project软件有机地结合起来，最后达到通过Project软件实际进行项目管理的目的。实践教学中的教学内容及课时分配如表2所示。
教学方法 为了贯穿软件项目管理的理论教学内容以及完成实验项目，课程一开始将班级学生六人为一组进行分组，每一组分配项目经理，小组中每名成员都有自己的职位（如需求分析师、数据库设计师、软件工程师、测试经理等），小组所有成员讨论并确定项目题目，以小组为单位将所选的题目进行分析讨论，小组内部通过讨论形成统一观点和见解。
如讲解第二章内容“软件项目需求管理”，师生共同学习需求管理中的理论知识，下一步教师布置任务，将应用所学理论知识编写小组项目的《需求规格说明书》；接着每一组项目经理分派需求分析师与用户沟通了解用户需求，确定用户需求，小组讨论并编写该组项目的《需求规格说明书》。利用这种分组讨论的方式提高学生的积极性和参与度，锻炼和培养学生运用知识点进行实践的能力。
为了学生能够对于实际项目的体验更加深刻，教师利用一学时简单介绍Microsoft Project工具的作用及主要功能。完成实验内容时按照项目管理的思想，项目经理再具体明确小组成员的角色和任务，小组成员针对不同的角色完成实验内容。按照软件项目管理的流程，第一步为计划阶段，该阶段每一组需要对项目进行可行性分析，编写需求规格说明书（完成实验一），利用项目进度管理的理论知识和项目WBS（Work Breakdown Structure，工作分解结构），画出项目的网络图，做项目进度计划，最后将项目进度、成本、人力资源计划录入Microsoft Project工具中（完成实验二、三、四），以便后续管理和计算。第二步实施控制阶段，将涉及的相关表格做好以便管理和控制。第三步是收尾阶段，填写设备验收及产品验收单、项目的经验总结报告，填写完了演示汇报项目的整个管理过程。
通过这样的实践，学生掌握了软件项目管理过程中所用的工具、方法，也掌握了软件项目管理从启动到收尾所涉及的流程。加深学生有关软件项目开发与管理的知识，同时通过实际项目案例分析获得实践经验，最后提高学生的学习热情，调动学习兴趣。
3 课程考核
有效的课程考核能促进学生的学习兴趣，也是对学生辛苦一学期所付出劳动的肯定。根据课程的培养目标，课程考核主要由平时考核、阶段考核和结课考核三部分组成，分别占总成绩的20%、40%和40%。平时成绩主要考核出勤和课堂作业等；阶段考核取决于期中测试成绩和实践教学中完成的实验报告成绩；结课考核是在网络教学平台中进行，通过闭卷考试考核学生对软件项目管理基本思想、理论和方法的掌握。
4 结束语
软件项目管理课程对提高学生的职业技能非常重要，它是从理论知识到实践过度的课程之一。本文对其教学方法和内容进行探讨，期望在今后的教学中注重该课程的实践教学，不断增强教学效果。
参考文献
[1]覃征，徐文华，等.软件项目管理[M].2版.北京：清华大学出版社，2009.
[2]杨莉.“软件项目管理”课程教学探讨[J].江苏技术师范学院学报，2011（2）.
[3]欧毓毅.“软件项目管理”的课程教学探索[J].广东工业大学学报，2008（8）.
课题项目：此项研究获得呼伦贝尔学院教学研究课题“软件项目管理课程教学体系研究”（YBKT-014）的支持。
软件项目的需求变更及对策 篇12
什么是需求分析?
要知道需求变更是什么, 首先要知道什么是需求分析。
需求分析是指理解客户需求, 就软件功能与客户达成一致, 估计软件风险和评估项目成本代价, 最终形成开发计划的一个复杂过程。需求分析的成果形成需求说明书。
什么是需求变更?
根据软件工程思想定义, 需求说明书一般要经过论证, 如果在需求说明书经过论证以后, 需要在原有需求基础上追加和补充新的需求, 或对原有需求进行修改和削减, 均属于需求变更。
二、需求变更的原因及影响
1. 需求变更原因
一方面是用户:他们是项目需求的提出者。一个十分常见的现象是用户提出需求以后, 在软件开发过程中用户改变了需求, 这只能迫使开发工作返工, 丢弃一些无法修正的部分。无疑这会造成一定的损失, 但又无法完全避免。要求用户一次性把需求讲清楚, 并且不允许此后需求有任何变更, 这是不现实的。只能尽量减少需求变更, 降低它所造成的影响。
二是系统因素:在系统内部, 如计算机硬件、系统软件或数据的变更要求与其相适应。
三是外部环境因素:与软件运行相关的工作制度或法规、政策的变更, 或是业务要求变更导致的需求变更。
四是需求分析阶段工作缺陷:需求调研、分析、定义和评审工作不够充分, 致使需求规格说明中隐含着问题, 在开发过程中才有所发现。或者需求开发中开发人员与用户沟通不够充分, 如未能如实获得用户的潜在需求等。
软件需求一旦出现变更, 它可能要涉及到一些相关的代码和文档的修改, 为此要把这一变更通知到所有相关人员。提出需求变更有可能在开发的任何阶段, 并且随着项目的进展, 越晚的需求变更引起的损失越大。
2. 需求变更给软件的开发工作带来的影响
需求变更对软件开发的影响是多方面的, 概括的看, 包括以下三个方面:
(1) 增加项目的人员、费用开支, 影响开发进度。需求变意味着原先的需求调研、分析的结果与预期的软件实现存在偏差, 需要进行需求变更。这无疑要增加项目的人员、费用的开支, 并对开发进度造成影响。更有甚者, 如果变更频繁, 可能对项目造成较大影响, 严重时可能直接导致项目的失败。
(2) 影响软件质量。在一个复杂的软件系统中, 需求之间具有一定的联系, 相关需求可构成需求链。如果由于需求变更导致需求链的某些环节脱节, 就可能引起一些难以察觉的错误。当需求变更没能及时修改项目的设计、开发文档时, 这些错误一般难以被测试人员发现, 将直接影响系统质量, 严重时可导致系统崩溃。
(3) 影响开发者与用户之间的合作关系。需求变更的实施是用户和开发者相互协作的过程。开发者和用户在是否采用变更问题上常常产生分歧, 如果没有恰当处理, 影响双方的互信, 从而影响项目开发进程。同时需求变更也会在项目开发人员之间产生分歧, 影响合作关系。
三、采取的对策
1. 首先是预防
尽量做好需求分析工作, 以期减少需求变更的频次, 为此在需求分析阶段着重处理好以下问题, 力图使需求分析的结果更接近目标。
(1) 培养正确的需求意识。优秀软件产品建立在优秀的需求基础之上, 而高质量的需求又来源于客户与开发人员之间有效的交流与合作。因此, 双方的参与者都需要认识到:要想获得成功, 自己需要什么, 合作方又需要什么。只有这样, 才能建立融洽的合作关系。因此, 培养正确的需求意识是双方都需要努力的, 而开发人员在这个阶段应该发挥更加积极主动的作用。
首先, 需求分析人员应该接受一定的正规培训, 以提高与人沟通的能力、缓解矛盾的能力、善于倾听和询问的技巧, 以及收集整理资料的能力等。在参与具体项目时, 分析人员也应主动学习一些项目所涉及的具体应用领域的基本知识, 以更好地理解用户的需求。
其次, 开发单位应该对那些不想花时间在需求分析上的用户明确指出:如果用户不能充分地支持并参与, 项目很可能会失败;开发单位还可以通过学习一些前车之鉴的真实案例警告用户:低质量的需求分析可能导致严重的后果。通过对用户代表和管理人员的培训, 使他们真正理解需求分析的重要性和忽略需求带来的风险, 并对计算机系统有一个大体的了解, 这样用户才能够主动地参与需求分析。
同时, 正因为不可能一次就完全了解用户的需求, 而且在系统开发过程中还需要不断地请用户参与, 因此与用户的沟通是需要贯穿始终的。需求分析中所采取的一些策略可能会让用户觉得意外和难以接受。因此, 需求分析人员需要对用户解释一些做法的必要性和合理性, 以得到用户最大的支持与合作。
(2) 从业务需求入手。用户认识到了需求分析的重要性, 但可能仍然不知道从何处入手表达自己的需求。这时可以从业务需求入手, 任何企业对自己的经营运作目标应该是比较清楚的, 这样的经营背景让用户不仅有话说, 也让开发者有章可循。需求分析不可以完全与它所处的背景相脱离, 只有当系统真正置身于它的社会和组织环境中, 它的需求才能清晰地反映出来。
(3) 充分利用需求来源。有了以上需求背景, 就比较容易做到有的放矢了。需求分析人员可以直接与系统未来的操作者探讨他们希望有什么样的软件;观察系统的潜在用户当前的日常工作以获取有价值的信息;系统的使用者可能有很多, 可以将他们分类以简化需求;最后一定要与真正的决定者达成协议:对于有冲突的需求如何权衡, 对于直接用户的众多需求如何取舍等。
同时, 用户往往对计算机期望过高, 认为计算机可以解决当前存在的所有问题, 因此会提出很多的功能需求, 并且希望在很短的时间内看到成效。但是, 由于技术、人力等资源的限制, 并不一定能够在设定的时间期限内满足用户所有的期望, 这时就应该尽早确定出交付的产品应具备的最重要功能, 即设定需求的优先级。
在这个阶段, 可以采用UML中的用例图帮助用户和需求分析人员之间的交流。一个用例图描述用户可以用软件产品执行的一个任务。它不是从软件的性能和系统的行为方面出发, 而是从用户到底能够用这个软件产品干什么入手。这样的方式用户比较熟悉, 容易沟通;而且不会在需求分析的一开始就陷入过于细节化的设计, 也有助于避免分析人员添加一些与所需任务无关的自认为很好的功能。
(4) 提供选择方案。由于用户对软件系统缺乏经验, 或者由于用户的运作机制还未完善, 或者由于其他种种原因, 用户可能仍然不能对一些需求做出明确的说明, 收集整理的需求中可能仍然存在一些不确定因素。这时可提出几份比较详细的方案。附带不同做法的优点, 供用户选择或者启发用户确定需求。
如果需求分析做得好, 文档清晰且又有客户签字, 那么后期客户提出的变更就超出了合同范围, 需要另外收费。这个时候, 开发方一定要据理力争, 此时这并非要刻意赚取客户的钱财, 而是不能让客户养成经常变更的习惯, 否则后患无穷。
2. 分级管理客户需求
软件开发项目中, “客户永远是对的”和“客户是上帝”并不完全的正确, 因为在已经签定的项目合同中, 任何新需求的变更和增加除了影响项目的正常进行以外, 还影响到了客户的投入收益, 所以有的时候项目经理反倒应该为客户着想。
对于项目中的需求变更, 可以实行分级管理, 以达到对需求变更的控制。
一级需求变更是关键性的需求, 这种需求如果不满足, 意味着整个项目不能正常交付使用, 前期工作也会被全部否定。这个级别的需求是必须满足的, 否则就意味着否定自已的项目成员和成员的所有努力, 所以定为“Urgent”。
二级需求变更是后续关键性需求, 它不影响前面工作内容的交付, 但不加以满足, 新的项目内容无法提交或继续, 所以是“Necessary”。一般新模块关键性的基础组件, 属于这个级别。
三级需求是后续重要的需求, 如果不被满足会令整体项目工作的价值下降, 为了体现项目价值, 也是开发人员自已的技术价值的证明, 所以定为“Needed”。一般性的重大的有价值的全新模块开发, 属于这个级别。
以上三个等级是应该实施的, 但时间性上可以作优先级的排列。
四级需求是改良性需求, 没有满足这类需求并不影响已有功能的使用, 但如果实现了则会更好, 定级为“Better”。界面和使用方式的需求, 一般在这个档次。
五级需求是可选性需求, 更多的是一种设想, 以及一种可能, 通常只是客户的的一种个人喜好而已, 定级为“Maybe”。
对于四级需求, 如果时间和资源条件都允许的话, 不妨做下去。对于五级需求, 正如对它的描述一样做与不做是“Maybe”。
3. 加强需求变更的控制
在需求分析阶段工作完成后, 需求变更仍可以会发生, 因此就要加强对需求变更的控制, 主要有以下原则:
(1) 建立需求基线。需求基线是需求变更的依据。在开发过程中, 需求确定并经过评审后 (用户参与评审) , 可以建立第一个需求基线。此后每次变更并经过评审后, 都要重新确定新的需求基线。
(2) 制订简单、有效的变更控制流程, 并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时, 这个流程具有一定的普遍性, 对以后的项目开发和其他项目都有借鉴作用。
(3) 成立项目变更控制委员会 (CCB) 或相关职能的类似组织, 负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成, 应该包括用户方和开发方的决策人员在内。
(4) 需求变更一定要先申请然后再评估, 最后经过与变更大小相当级别的评审确认。
(5) 需求变更后, 受影响的软件计划、产品、活动都要进行相应的变更, 以保持和更新的需求一致。
(6) 妥善保存变更产生的相关文档。
这六大原则看起来简单, 但真正实施起来有难度, 还需要依据理论知识配合开发项目组的实际工作情况, 在实践中不断摸索总结。
四、总结
软件项目的需求变更是对软件产品的质量、成本、工期带来巨大的影响。通过预防性措施和加强需求变更的控制与管理, 将需求变更的频次大幅度降低, 从而为软件项目的顺利实施打下坚实基础。
参考文献
[1]王莉吴洁明:软件项目中的需求变更管理的研究[J].计算机技术与发展, 2007, 17 (1) :120～121
[2]王强:软件开发项目中的需求变更管理[J].电脑知识与技术 (学术交流) , 2007, (11)
[3]李师贤张珞玲:需求分析的常见问题及其对策分析[J].计算机工程, 2002, 28 (1) :7～8