软件过程管理论文Word文档格式.docx
- 文档编号:21043072
- 上传时间:2023-01-27
- 格式:DOCX
- 页数:11
- 大小:59.71KB
软件过程管理论文Word文档格式.docx
《软件过程管理论文Word文档格式.docx》由会员分享,可在线阅读,更多相关《软件过程管理论文Word文档格式.docx(11页珍藏版)》请在冰豆网上搜索。
4.7需求管理策略-10-
5目前需求管理的现状及存在问题-12-
6结束语-13-
参考文献-14-
1引言
1.1概述
在软件开发.维护过程中,许多错误都是潜伏的。
一项对TRM公司所做过的软件项目的分析结果表明:
所有被检测出来的错误中,54%是在编码和单元铡试阶段以后才被发现的;
更糟糕的是此类错误中的绝大部分(占45%)是在需求和设计阶段发生的,而编码阶段的错误只占9/0。
另一项对GTE.TRW和IBM三家公司的研究结果表明,在需求阶段检查和修复一个错误所需的费用只有编码阶段的1/5到I/1O,而在维护阶段做同样的工作所付出的代价却是编码阶段的20倍这就意味着在需求阶段和维护
阶段修复一个错误的比值可高达I:
200。
由此可以看出:
需求变更贯穿了软件项目的整个生命周期,从软件的项目立项,研发,维护,用户的经验在增加,对使用软件的感受有变化,以及整个行业的新动态,都为软件带来不断完善功能,优化性能,提高用户友好性的要求。
在软件项目管理过程中,项目经理经常面对用户的需求变更。
如果不能有效处理这些需求变更,项目计划会一再调整,软件交付日期一再拖延,项目研发人员的士气将越来越低落,将直接导致项目成本增加、质量下降及项目交付日期推后。
这决定了项目组必须拥有需求管理策略。
对大多数软件和系统开发团队来说,由于评测和验证有效的软件开发流程的标准得到推广和普及,加上全球经济对软件的依赖程度加深,推动了开发流程的发展,提高了系统质量。
既然如此,那么今天频频发生的软件项目失败的事件又如何解释呢?
为什么仍有那么多的项目受到延期、预算超支和质量问题的困扰呢?
简单地说,系统开发团队之所以管理需求,是因为他们想让项目获得成功。
满足项目需求即为成功打下了基础。
若无法管理需求,达到目标的几率就会降低。
也就是说:
好的需求管理是项目成功的第一位因素。
采用需求管理可以给项目组带来很多的好处,直至项目取得成功。
2需求管理的基本概念
一般来说,当接手一个项目时,需要将系统需求分配到软件、硬件和其他系统组成部分,这项工作一般由系统工程组桌负责完成。
我们称分配给软件的系统需求为分配的需求,它是系统需求的子集,是要在系统中实现的软件成份。
分配的需求包括影响和决定软件项目活动的非技术性需求及软件技术性需求,此外还有使软件产品满足分配需求的接收标准。
分配的需求构成了整个软件生命周期中估算、计划、执行和跟踪软件项目活动的基础。
需求管理的目的是:
在客户和实现客户需求的软件项目之间达成共识,以便更好地控制分配的需求,为软件工程和管理建立基准线,同时保证软件计划,产品和管理活动能与分配的需求保持一致。
在需求管理中,软件工程组的工作是:
采取适当的措施来保证分配的需求具体地说,就是要将分配的需求文档化,控制需求的变化,负责项日实施过程中需求的实现情况。
通常需求可分成三类:
用户需求CR、技术需求TR和项目需求PR。
用户需求陈述了用户的要求。
技术需求陈述的是满足用户需求的技术功能和质量属性。
表明必须提供什么而不是如何提供。
项目需求用于项目计划和跟踪行为,项目需求通过项目计划和项目跟踪进行管理。
项目开发过程可概括为:
首先将用户的价值取向转化成用户需求而用户需求又进一步转化为技术需求。
根据技术需求进行设计,从而进行编码。
通过这种方式需求就是内嵌的,而不是测试来的,测试行为就成了简单的核实行为。
满足需求的产品才能为用户提供价值。
由于需求是正在构建的系统必须符合的事务,而且符合某些需求决定了项目的成功或失败,因此找出需求是什么,将它们记下来,进行组织,并在发生变化时对它们进行追踪,这些活动都是有意义的。
换句话说,需求管理就是:
一种获取、组织并记录系统需求的系统化方案,以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。
3需求管理的基础
需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解。
需求管理的目标有两个:
第一,使软件需求受控,并建立供软件工程和管理使用的需求基线;
第二,使软件计划、产品和活动与软件需求保持一致。
在CMM中,每一个KPA都要求:
1.有一个书面的组织政策以供项目实施过程中遵循。
这个政策一般应该包含以下要求:
为分配的需求建立文档,应该由软件经理和其他相关组来审查分配的需求。
这里所说的相关组大致有:
系统测试组、软件工程组、系统工程组、软件质量保证组、软件配置管理组及文档支持组。
要求软件计划工作产品及项目活动都要随着分配需求的变更而做相应的变化
2.要求已经对承接的项目进行明确的系统需求分析.并将这些需求分析给硬件,软件和其他系统组成部分。
3.为管理分配的需求提供足够的资源和资金保证由在应用领域里和软件工程方面具有经验和专业知识的人员来管理分配的需求。
此外还要提供支持管理需求活动的工具,包括配置管理工具跟踪工具、文奉管理工具等。
4.为软件工程组成员和其他软件相关组提供管理需求的相关培训。
这些培训主要有:
项目使用方法标准和工作程序及应用领域等。
在需求管理过程,为实现第一个目标,必须控制需求基线的变动,按照变更控制的标准和规范的过程进行需求变更控制和版本控制;
为实现第二个目标,必须就变更和软件项目各小组达成共识,对软件项目计划做出调整,其中包括人员的安排、用户的沟通、成本的调整、进度的调整等。
为进行有效的需求管理,一般要遵循如下五条原则:
第一,需求一定要分类管理。
进行软件项目管理的时候,一定要将软件需求分出层次。
不同层次需求的侧重点、描述方式、管理方式是不同的。
第二,需求必须分优先级。
在软件项目中,如果出现过多的需求,通常会导致项目超出预算和预定进度,最终导致软件项目的失败,因而需求的优先级可能比需求本身更加重要。
第三,需求必须文档化。
需求必须有文档记录。
该文档必须是正确的、最新的、可管理的、可理解的,是经过验证的,是在受控的状态下变更的。
第四,需求一旦变化,就必须对需求变更的影响进行评估。
无论需求变化的程度如何,只要需求变化了就必须进行评估,这是基本的原则。
第五,需求管理必须与需求工程的其他活动紧密整合。
进行需求管理一定不能脱离需求工程,需求工程包括了需求获取、需求分析、需求描述、需求验证、需求管理,因而需求管理必须与前面的几个需求阶段保持密切相关。
4需求管理的具体活动
需求管理在需求开发的基础上进行,贯穿于整个软件项目过程,是软件项目管理的一部分。
在软件项目进行的过程中,无论正处于哪个阶段,一旦有需求错误出现或任何有关需求的变更出现,都需要需求管理活动来解决。
需求管理是一个对系统需求变更了解和控制的过程。
初始需求导出的同时就启动了需求管理规划,一旦形成了需求文档的草稿版本,需求活动就开始了。
需求活动的具体内容如表一所示:
需求管理活动
活动的任务
变更控制
建议需求变更并分析其影响,做出是否变更的决策
版本控制
确定单个需求(即功能规格说明)的版本
需求跟踪
定义对于其他需求及系统元素的联系链
需求状态
定义并跟踪需求的状态
4.1说明
应该说需求管理过程和软件开发过程是并行的。
奉文描述的需求管理过程出现在软件开发过程整个周期之中所以将软件开发过程作为背景信息提供出来。
软件开发过程可分为需求阶段、建议阶段、设计阶段、编码阶段和核实阶段。
需求阶段包括程序初始化和程序定义。
交付的是程序陈述和需求说明书;
需求说明书包括了用户需求和技术需求。
建议阶段定的组织制度或政策之类的基础,在这样一个基础之上才能够开展各个KPA的实践活动。
需求管理也不例外,其基础是:
覆盖了为确定需求说明书而进行工程建议的活动,建议文档是后续设计阶段的基础。
设计阶段包括功能描述和设计交付的是一个或多个为了确定具有更多细节的功能和设计说明书而编写的功能说明书。
编码阶段包括实施源代码对目标代码进行单元测试,交付的是实际的软件和文档或产品信息。
核实阶段包括各种各样的测试行为,交付的是基于设计和技术或用户需求的测试说明.测试计划和测试运行结果。
4.2需求管理过程
本文所建议的需求管理过程采用了一个数据库来标志需求在各个阶段的状态,在CMM中称为度量目的是为了明确分配的需求管理活动的状态。
下面给出了需求管理过程的数据流图。
4.3需求确定的管理
需求确定阶殷可映射到软件开发过程中的需求阶段。
具体到需求管理过程可以进一步细分为定义阶段分析阶段。
实施办法建议如下:
在定义阶段所做的工作是:
(1)收集需求,并制定需求说明书的草案。
(2)与需求者一起定义验证所收集的需求。
(3)跟踪需求的需求者或需求源及时向他们发送批准的需求或需求的变更。
在这一阶段,需求说明书草案中的每一个需求的状态是“定义的”。
在分析阶段所做的工作是:
①分析需求,以保证所列需求是清晰的、明确的、有意义的、可测量的,并且可用于开发和测试。
②建立用户和技术需求之的联系。
保证技术需求能充分覆盖和分解用户需求。
③划分需求,找出其中的不足和不完善的地方。
④区分需求的优先级、更新需求说明书。
⑤得到批准的需求说明书,这是软件开发和项目管理行为的基础。
到目前为止,批准的需求说明书的每一个需求的状态已被更新为“批准的”。
4.4需求实现的管理
需求实现阶段涉及到软件开发过程的建议阶段、设计阶段、编码阶段和核实阶段。
在建议阶段所做的工作是:
根据适当的过程开发建议和项目计划。
建议也许不能针对每一个批准的需求,而且有些需求可能在其他项目建议中或今后的交付中才会出现,要审核、批准、提交建议和项目计划到目前为止,需求说明书中被建议的每一个需求的状态已被更新为“建议的”。
在设计阶段所做的工作是:
在一个或多个设计说明书中提出技术需求:
必须根据需求来进行设计,检查设计,以判断是否对所有的需求都进行了设计。
到目前为止,在设计中提出的每一个需求的状态已被更新为“设计的”。
项目经理要保证在一个或多个设计中包括所有提交的需求。
在编码阶段所做的工作是:
实施设计。
实施设计的结果就是软件和文档必须对这些工作产品进行检查。
如果设计没有被充分的实施,就会有需求不能满足,这就意味着要重复工作。
到目前为止,在软件和文档中被实施的每一个需求的状态已被更新为“实施的”。
项目经理要保证产品中包括所有提交的需求。
在核实阶段所做的工作是:
通过测试软件来检验需求的满足情况。
CMM要求在项目实施过程中,项目组定期与上级管理部门一起审查对分配的需求的管理括动而在项目组内,项目经理也要定期或有审查触发时审查对分配的需求的管理话动。
这是对需求管理活动的审查此外。
CMM还要求由软件质量保证组审查管理活动的工作产品并报告结果。
由需求者来审核、批准需求说明。
审查软件工程组提交的分配需求。
解决有关问题软件计划。
工作产品和项目活动是否随分配需求的变更而相应的变化。
在测试阶段,跟踪测试结果。
判断哪些需求被满足了。
在这一阶段,产品中被核实的每一个需求的状态已被更新为“完备的”。
项目经理要保证产品中包括所有的提交的需求。
4.5需求变更的管理
变更管理主要涉及到分配的需求的更改活动,分配的需求的更改次数等。
接手过项目的人都知道,需求确定之后并不是一成不变的。
需求变更可以从需求说明书或建议开始生效。
变更必须在相关的计划、交付和行为中反映出来。
本文针对几种常见的需求变更情况,对变更的管理工作提出了一些建议,列表如下:
放弃一个不再需要的需求
更新需求说明书删除该需求并重新批准需求说明书。
在建议、项目计划和产品交付中反映这一变更
从当前打算的实施中删除需求,而该需求还是希望在子交付中被满足
更新建议,反映这一变更。
该需求的状态还原成“批准的”。
变更在项目计划和产品交付中要有所反映
在批准需求说明书中加入新的需求
新的需求应是有效的,经过分析的并且划分了优先级的。
更新并批准需求说明书。
要求在建议、项目计划和产品交付中反映需求变更,该需求状态是“批准的”。
在当前打算的实施中加入需求,并且需求已经在需求说明书中被批准
该需求状态变成“提交的”。
变更在项目计划和产品中交付
可以看出,采用需求状态数据库能够很方便的管理需求变更所引起的某一需求所处的阶段及最后是否实施的情况。
4.6需求管理复杂性分析
软件需求是整个软件开发项目的最关键的一个输入,和传统的生产企业相比较,软件的需求具有模糊性、不确定性、变化性和主观性的特点,他不像生产汽车、电脑等硬件的需求,是有形的、客观的、可描述的、可检测的,软件需求是软件项目最难把握的问题,他的复杂性体现在以下方面:
1、需求的描述问题。
缺少正式的完整的需求文档浪费了大量的人力物力,但是有了需求文档又出现了新的问题。
在用户方进行的需求评审会完全是走形式,因为用户根本不去听他读那上百页的需求文档。
不同层次的客户(用户)关心的问题是不一样的,想要每个客户都成为需求专家是不现实的。
2、需求的完备程度问题。
需求如何做到没有遗漏?
如何准确划定系统的范围?
这确实是一个两难问题,稍微大一点的系统要想穷举需求几乎是不可能的,每次开需求评审会时,总会冒出新的需求,以至于系统没有一个准确的范围界定。
即使是这样,系统还是要开发,没办法,系统的范围还要硬性的划定一个,从而建立一个基线。
3、需求开发的工期问题。
在需求上花费了大量的时间,客户、软件公司是否能够忍受?
为了确保需求的正确性,完备性,项目经理往往坚持要在需求阶段花费大量的时间,但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已!
他们往往会逼迫项目组尽快往前推进,而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽,他们也希望尽快结束此阶段。
4、需求的细致程度问题。
需求到底描述到多细,才算可以结束了?
仁者见仁,智者见智,并没有定论,如果时间允许,要想细总可以细下去的。
但是,需求的周期越长,可能的变化越多,对设计的限制越严格,对需求的共性提取要求越高,所以只要大家(客户、用户、需求分析人员、设计人员、测试人员)认为描述清楚了,就可以进入设计阶段了。
5、需求的变化问题。
在软件开发过程中如果只有一条真理的话,那一定是:
需求的变化是永恒的,需求不可能是完备的。
软件开发的过程实际上是同变化做斗争的过程,需求的变更不一定是坏事,也有可能是好事,是商业机会,对市场敏感的人可以从需求的变化中发现市场机会。
需求变化的原因很多,如:
·
一开始没有识别全,需要增加需求;
·
业务发生了变化,需求必须变化;
需求错误;
需求不清楚。
需求的变化问题是每个开发人员、每个项目经理都遇到的问题,也是最头痛的问题,一旦发生了需求变化,你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等,需求的变化好比是万恶之源,为项目的正常的进展带来不尽的麻烦,怎么办?
管理它!
使需求在受控的状态下发生变化,而不是随意变化,需求管理就是要按照标准的流程来控制需求的变化。
难题随之而来,需求中的变化一般不是突发的革命性的变化,最常见的是项目需求的渐变(ProjectScopeCreep)问题,这种渐变很可能是客户与开发方都没有意识到的,当达到一定层度时,双方才蓦然回首,发现已经物是人非,换了一番天地。
4.7需求管理策略
需求管理需要遵守以下策略:
1、需求一定要与投入有必然的联系。
需求一定要与投入有必然的联系,否则如果需求变更的成本由开发方来承担,则项目需求的变更就成为必然了。
人们常说世上没有免费的午餐,同样也不应该有免费的需求变更。
但是,接受需求变更目前却是软件开发商不得不咽下的苦果。
所以,在项目的开始无论是开发方还是出资方都要明确这一条:
需求变,软件开发的投入也要变。
2、需求的变更要经过出资者的认可。
需求的变更引起投入的变化,所以要通过出资者的认可,这样才会对需求的变更有成本的概念,能够慎重地对待需求的变更。
笔者曾经经历过一个项目,为了避免项目的风险,我们请了用户代表全程参与了开发过程,结果此用户代表在开发过程提出了大量“小的需求变更,当开发人员按此需求变更修改了软件时,在项目进入现场实施阶段时,却有大量的这些变更需要改回去,问题就是出在我们的项目组成员视该用户代表的需求为圣旨,却忽略了需求是否经过了客户方真正有决策权的人员的认可。
3、小的需求变更也要经过正规的需求管理流程。
小的需求变更也要经过正规的需求管理流程,否则会积少成多。
在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。
正式由于这种观念才使需求的渐变不可控,最终导致项目的失败。
4、精确的需求与范围定义并不会阻止需求的变更。
并非对需求定义的越细,越能避免需求的渐变,这是2个层面的问题。
太细的需求定义对需求渐变没有任何效果。
因为需求的变化是永恒的,并非由于需求写细了,它就不会变化了。
注意沟通的技巧。
实际情况是用户、开发者都认识了到了上面的几点问题,但是由于需求的变更可能来自客户方、也可能来自开发方,作为客户他们可能不愿意为需求的变更付出更多的投资,开发方有可能是主动的变更了需求,他们的目的了上面的几点问题,但是由于需求的变更可能来自客户方、也可能来自开发方,作为客户他们可能不愿意为需求的变更付出更多的投资,开发方有可能是主动的变更了需求,他们的目的可能是使软件做的更精致,于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。
基于上述的问题,必须对需求进行管理,使需求能够真正成为软件工程和管理的基线,使软件计划、活动和工作产品同软件需求保持一致,使需求可以复用。
5目前需求管理的现状及存在问题
一个目的在于确保系统符合人们对其期望的流程面临着哪些困难呢?
当它真正在实际项目实施时,困难就暴露出来了。
对开发人员、经理和质量保证人员所做的一次调查结果。
显示了经历过最常提到的需求相关难题的受访者比例。
常见的需求问题:
无法跟踪变更7176,难以编写70%,特性偏移67%,组织欠佳54%。
下面列出了更多与需求有关的问题需求不总是显而易见的,而且它可来自各个方面;
需求并不总是容易用文字明白无误地表达;
存在不同种类的需求,其详细程度各不相同;
如果不加以控制,需求的数量将难以管理;
需求相互之间以及与流程的其他可交付工件之间以多种方式相关联;
需求既非同等重要,处理的难度也不同;
需求涉及众多相关利益责任方,这意味着需求要由跨职能的各组人员来管理;
需求发生变更;
需求可能对时间敏感。
当这些问题与需求管理和处理技能不足以及缺乏易用工具等情况一同出现时,许多团队都对管理好需求不抱希望了。
6结束语
软件工程管理的核心思想是:
有效地对软件开发整个过程进行合理地规划和控制,到在用户可接受的软件功能、可靠性、性能等前提下尽可能的低成本、低风险和较高的效率完成软件开发。
从多年开发软件的实践来看,凡是重视软件管理并按规范进行的开发,软件开发周期短,软件可用性强,软件可靠性高,用户界面好。
反之,不是拖延进度,不了了之,就是可用性和可靠性差,不受用户欢迎。
实践表明,提高软件可靠性和可维护性,促进软件工程化管理,需要广大软件开发人员和管理人员转变观念,以现有的起点为基础,脚踏实地、真抓实干。
参考文献
[1]BobHughes,MikeCotterel1.SoftwareProJectManagement[M].北京:
机械工业出版社,2004.
[2]赵晓亮.浅议软件工程管理[J].科技情报开发与经济,2002第12卷第5期.
[3]黄卓.软件工程管理方法的探讨[J].辽宁师专学报,2003年第5卷第3期.
[4]软件工程管理——sEM推进中国信息化发展[J].软件世界,2004年第2期.
[5]郝滨滨.软件工程管理方法与实践[J].舰船电子工程,2004年第4期.
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 过程 管理 论文