增量模型的软件过程
采用增量模型的软件过程如图1-8所示。
增量模型(incremental model)与原型实现模型和其他演化方法一样,本质上是迭代的,但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。
早期的增量是最终产品的“可拆卸”版本,但提供了为用户服务的功能,并且为用户提供了评估的平台。
增量模型的优点和缺点
优点采用增量模型的优点是人员分配灵活,刚开始不用投入大量人力资源。
如果核心产品很受欢迎,则可增加人力实现下一个增量。
当配备的人员不能在设定的期限内完成产品时,它提供了一种先推出核心产品的途径。
这样即可先发布部分功能给客户,对客户起到镇静剂的作用。
此外,增量能够有计划地管理技术风险。
缺点增量模型存在以下缺陷: 1) 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。
2) 在开发过程中,需求的变化是不可避免的。
增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而使软件过程的控制失去整体性。
3)如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析,这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
增量模型的优缺点
1) 由于能够在较短的时间内向用户提交一些有用的工作产品,因此能够解决用户的一些急用功能。
2)由于每次只提交用户部分功能,用户有较充分的时间学习和适应新的产品。
3)对系统的可维护性是一个极大的提高,因为整个系统是由一个个构件集成在一起的,当需求变更时只变更部分部件,而不必影响整个系统。
增量模型存在以下缺陷:1) 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。
2) 在开发过程中,需求的变化是不可避免的。
增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而使软件过程的控制失去整体性。
3)如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析,这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
总结归纳主要的软件工程模型,并任意选定其中的一种过程模式,介绍...
主要的软件过程模型有:瀑布模型,演化模型(如增量模型、原型模型、螺旋模型)、喷泉模型、基于构件的开发模型和形式方法模型等。
瀑布模型(waterfall model)是1970年有W.Royce提出的,它给出了软件生存周期活动的固定顺序,上一阶段的活动完成后向下一阶段过渡,最终得到所开发的软件产品。
瀑布模型如下图所示,有时也称为软件生存周期模型。
瀑布模型中,上一阶段的活动完成并经过评审后才能开始下一阶段的活动,其特征是:(1)接受上一阶段的结果作为本阶段活动的输入。
(2)依据上一阶段活动的结果实施本阶段应完成的活动。
(3)对本阶段的活动进行评审。
(4)将本阶段活动的结果作为输出,传递给下一阶段。
瀑布模型是最早出现的也是应用最广泛的过程模型,对确保软件开发的顺利进行、提高软件项目的质量和开发效率起到重要作用。
在大量的实践过程中,瀑布模型也逐渐暴露出它的不足。
首先,客户常常难以清楚地描述所有的要求,而且在开发过程中,用户的需求也常常会有所变化,使得不少软件的需求存在着不确定性;在某个活动中发现的错误常常是由前一阶段活动的错误引起的,为了改正这一错误必须回到前一阶段,这就导致了瀑布的倒流,也就是说,实际的软件开发很少能按瀑布模型的顺序没有回流地顺流而下。
其次,瀑布模型使得客户在测试完成以后才能看到真正可运行的软件,此时,如果发现不满足客户需求的问题(由于需求不确定性),那么修改软件的代价是巨大的。
不是任何软件都可采用瀑布模型的,瀑布模型适合于结构化方法,也就是面向过程的软件开发方法。
软件项目或产品选择瀑布模型必须满足下列条件:在开发时间内需求没有或很少变化;分析设计人员应对应用领域很熟悉;低风险项目(对目标、环境很熟悉);用户使用环境很稳定;用户除提出需求以外,很少参与开发工作。
用瀑布模型开发的软件项目过程管理
一、有助于按照现实或者实际情况进行直观的描述。
二、能够规定软件或者模型的结构,行为,属性。
三、能够指导软件构造的模板。
四、对决策进行文档化当然建模并不只适用于大的系统,甚至像非常小的一个应用,我们都可以建模,在建模中受益,然而越大的软件,功能越杂,业务越不清晰,从而阻挠软件开发者的思路和效率。
在这种情况下,我们使用建模的重要性就越大,一个很简单的原因是:因为不能理解一个很复杂而庞大的软件工程,所以要对他建模 。
而且人们对复杂的事物或者问题的理解是有局限的,人们总是习惯去理解 简单易懂的东西。
所以通过建模可以 缩小研究范围,只着重研究其很小的一部分功能,这就要求了一个复杂的软件系统“分而治之”,从而通过建模简单化。
从而你会发现其实很复杂的系统软件或者工程总是变得很简单,解决了这小部分的简单问题,就形成了复杂而庞大的软件或者工程。
建模能帮助开发组更好地进行系统规划,并帮助他们进行架构软件,使用开发效率提高。
如果不建模,项目越复杂,就越会失败或者出现错误的东西。
软件的生命周期
软件生命周期是指从软件定义、开发、使用、维护到报废为止的整个过程,一般包括问题定义、可行性分析、需求分析、总体设计、详细设计、编码、测试和维护。
问题定义就是确定开发任务到底“要解决的问题是什么”,系统分析员通过对用户的访问调查,最后得出一份双方都满意的关于问题性质、工程目标和规模的书面报告。
可行性分析就是分析上一个阶段所确定的问题到底“可行吗”,系统分析员对系统要进行更进一步的分析,更准确、更具体地确定工程规模与目标,论证在经济上和技术上是否可行,从而在理解工作范围和代价的基础上,做出软件计划。
需求分析即使对用户要求进行具体分析,明确“目标系统要做什么”,把用户对软件系统的全部要求以需求说明书的形式表达出来。
总体设计就是把软件的功能转化为所需要的体系结构,也就是决定系统的模块结构,并给出模块的相互调用关系、模块间传达的数据及每个模块的功能说明。
详细设计就是决定模块内部的算法与数据结构,也是明确“怎么样具体实现这个系统”。
编码就是选取适合的程序设计语言对每个模板进行编码,并进行模块调试。
测试就是通过各种类型的测试使软件达到预定的要求。
维护就是软件交付给用户使用后,对软件不断查错、纠错和修改,使系统持久地满足用户的需求。
软件的生命周期也可以分为3个大的阶段,分别是计划阶段、开发阶段和维护阶段。
瀑布模型有时也称为V模型,它是一种线型顺序模型,是项目自始至终按照一定顺序的步骤从需求分析进展到系统测试直到提交用户使用,它提供了一种结构化的、自顶向下的软件开发方法,每阶段主要工作成果从一个阶段传递到下一个阶段,必须经过严格的评审或测试,以判定是否可以开始下一阶段工作,各阶段相互独立、不重叠。
瀑布模型是所有软件生命周期模型的基础。
原型+瀑布模型原型模型本身是一个迭代的模型,是为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题,通过建立原型使开发者进一步确定其应开发的产品,使开发者的想象更具体化,也更易于被客户所理解。
原型只是真实系统的一部分或一个模型,完全可能不完成任何有用的事情,通常包括抛弃型和进化型两种,抛弃型指原型建立、分析之后要扔掉,整个系统重新分析和设计;进化型则是对需求的定义较清楚的情形,原型建立之后要保留,作为系逐渐增加的基础,采用进化型一定要重视软件设计的系统性和完整性,并且在质量要求方面没有捷径,因此,对于描述相同的功能,建立进化型原型比建立抛弃型原型所花的时间要多。
原型建立确认需求之后采用瀑布模型的方式完成项目开发。
增量模型与建造大厦相同,软件也是一步一步建造起来的。
在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。
整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。
一些大型系统往往需要很多年才能完成或者客户急于实现系统,各子系统往往采用增量开发的模式,先实现核心的产品,即实现基本的需求,但很多补充的特性(其中一些是已知的,另外一些是未知的)在下一期发布。
增量模型强调每一个增量均发布一个可操作产品,每个增量构建仍然遵循设计-编码-测试的瀑布模型。
迭代模型早在20世纪50年代末期,软件领域中就出现了迭代模型。
最早的迭代过程可能被描述为“分段模型”。
迭代,包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。
所以,在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。
实质上,它类似小型的瀑布式项目。
所有的阶段(需求及其它)都可以细分为迭代。
每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。
转载请注明出处51数据库 » 适合采用增量模型的软件项目