分类目录归档:文档

软件项目的需求变更及对策


转自:http://www.uml.org.cn/RequirementProject/201405153.asp

[摘 要] 需求分析是软件生命周期中的重要阶段,决定软件项目的成败;需求变更会严重影响软件项目的质量、成本和工期。本文分析了需求变更的原因和影响,并给出了对需求变更进行有效控制的对策。

[关键词] 需求分析;需求变更;需求控制

一、问题的提出

什么是需求分析?

要知道需求变更是什么,首先要知道什么是需求分析。

需求分析是指理解客户需求,就软件功能与客户达成一致,估计软件风险和评估项目成本代价,最终形成开发计划的一个复杂过程。需求分析的成果形成需求说明书。

什么是需求变更?

根据软件工程思想定义,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求,或对原有需求进行修改和削减,均属于需求变更。

二、需求变更的原因及影响

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)妥善保存变更产生的相关文档。

这六大原则看起来简单,但真正实施起来有难度,还需要依据理论知识配合开发项目组的实际工作情况,在实践中不断摸索总结。

四、总结

软件项目的需求变更是对软件产品的质量、成本、工期带来巨大的影响。通过预防性措施和加强需求变更的控制与管理,将需求变更的频次大幅度降低,从而为软件项目的顺利实施打下坚实基础。


   

流程图


转自:http://yangxiufeng.bokee.com/6227964.html

介绍常见的流程图符号及流程图的例子。

    本章例1 – 1的算法的流程图如图1 – 2所示。本章例1 – 2的算法的流程图如图1 – 3所示。


在流程图中,判断框左边的流程线表示判断条件为真时的流程,右边的流程线表示条件为假时的流程,有时就在其左、右流程线的上方分别标注“真”、“假”或“T”、“F”或“Y”、“N”

图2

另外还规定,流程线是从下往上或从右向左时,必须带箭头,除此以外,都不画箭头,流程线的走向总是从上向下或从左向右。


2. 算法的结构化描述

    早期的非结构化语言中都有go to语句,它允许程序从一个地方直接跳转到另一个地方去。

执行这样做的好处是程序设计十分方便灵活,减少了人工复杂度,但其缺点也是十分突出的,一大堆跳转语句使得程序的流程十分复杂紊乱,难以看懂也难以验证程序的正确性,如果有错,排起错来更是十分困难。这种转来转去的流程图所表达的混乱与复杂,正是软件危机中程序人员处境的一个生动写照。而结构化程序设计,就是要把这团乱麻理清。

经过研究,人们发现,任何复杂的算法,都可以由顺序结构、选择(分支)结构和循环结构这三种基本结构组成,因此,我们构造一个算法的时候,也仅以这三种基本结构作为“建筑单元”,遵守三种基本结构的规范,基本结构之间可以并列、可以相互包含,但不允许交叉,不允许从一个结构直接转到另一个结构的内部去。正因为整个算法都是由三种基本结构组成的,就像用模块构建的一样,所以结构清晰,易于正确性验证,易于纠错,这种方法,就是结构化方法。遵循这种方法的程序设计,就是结构化程序设计。

    相应地,只要规定好三种基本结构的流程图的画法,就可以画出任何算法的流程图。

(1) 顺序结构

顺序结构是简单的线性结构,各框按顺序执行。其流程图的基本形态如图1 – 4所示,语句

的执行顺序为:A→B→C。

(2) 选择(分支)结构

这种结构是对某个给定条件进行判断,条件为真或假时分别执行不同的框的内容。其基本形状有两种,如图1-5 a)、b)所示。图1-5 a)的执行序列为:当条件为真时执行A,否则执行B;图1 – 5 b)的执行序列为:当条件为真时执行A,否则什么也不做。

图3

(3) 循环结构

循环结构有两种基本形态: while型循环和do – while型循环。

a. while 型循环

如图1 – 6所示。

其执行序列为:当条件为真时,反复执行A,一旦条件为假,跳出循环,执行循环紧后的语句。

b. do-while型循环

如图1 – 7所示。

图4

执行序列为:首先执行A,再判断条件,条件为真时,一直循环执行A,一旦条件为假,结束循环,执行循环紧后的下一条语句。

    在图1 – 6、图1 – 7中,A被称为循环体,条件被称为循环控制条件。要注意的是:

1) 在循环体中,必然对条件要判断的值进行修改,使得经过有限次循环后,循环一定能

结束,如图1 – 3中的i = i – 1。

2) 当型循环中循环体可能一次都不执行,而直到型循环则至少执行一次循环体。

3) 直到型循环可以很方便地转化为当型循环,而当型循环不一定能转化为直到型循环。

例如,图1 – 7可以转化为图1 – 8。


七,用N-S图描述算法

N – S图是另一种算法表示法,是由美国人I . Nassi和B.Shneiderman共同提出的,其根据是:

既然任何算法都是由前面介绍的三种结构组成,所以各基本结构之间的流程线就是多余的,因此,N – S图也是算法的一种结构化描述方法。

N – S图中,一个算法就是一个大矩形框,框内又包含若干基本的框,三种基本结构的N – S图描述如下所示:

1. 顺序结构

如图1 – 9所示,执行顺序先A后B。

2. 选择结构

对应于图1 – 5的N – S图为图1 – 1 0。图1-10 a)条件为真时执行A,条件为假时执行B。图1 – 1 0

条件为真时执行A,为假时什么都不做

图5

3. 循环结构

1) while型循环的N – S图如图1 – 11所示,条件为真时一直循环执行循环体A,直到条件为假时才跳出循环。

2) do-while型循环的N – S图如图1 – 1 2,一直循环执行循环体A,直到条件为假时才跳出循环。

本章例1 – 1的N – S图如图1 – 1 3,例1 – 2的N – S图如图1 – 1 4。应该说,N – S图比流程图更直观易懂,而且相对简练一些。

图6

八,用PAD图描述算法    

    PAD(Problem Analysis Diagram),是近年来在软件开发中被广泛使用的一种算法的图形表示法,与前述的流程图、N – S图相比,流程图、N – S图都是自上而下的顺序描述,而PAD图除了自上而下以外,还有自左向右的展开,所以,如果说流程图、N – S图是一维的算法描述的话,则PAD图就是二维的,它能展现算法的层次结构,更直观易懂。

下面是PAD图的几种基本形态:

1. 顺序结构:

如图1 – 1 5所示。

2. 选择结构

(1) 单分支选择,条件为真执行A,如图1-16 a)。

(2) 两分支选择,如图1-16 b),条件为真执行A,为假执行B。

(3) 多分支选择,如图1-16 c),当I = I1时执行A,I= I2时执行B,I = I3时执行C,I = I4时执行D。

图7

3. 循环结构

如图1 – 1 7所示。图1-17 a)为while型循环,图1-17 b)为do – while型循环。

图8

本章例1 . 1的PA D图如图1 – 1 8,例1 – 2的PA D图如图1 – 1 9

图9