
为什么要使用软件开发模型
一、有助于按照现实或者实际情况进行直观的描述。
二、能够规定软件或者模型的结构,行为,属性。
三、能够指导软件构造的模板。
四、对决策进行文档化当然建模并不只适用于大的系统,甚至像非常小的一个应用,我们都可以建模,在建模中受益,然而越大的软件,功能越杂,业务越不清晰,从而阻挠软件开发者的思路和效率。
在这种情况下,我们使用建模的重要性就越大,一个很简单的原因是:因为不能理解一个很复杂而庞大的软件工程,所以要对他建模 。
而且人们对复杂的事物或者问题的理解是有局限的,人们总是习惯去理解 简单易懂的东西。
所以通过建模可以 缩小研究范围,只着重研究其很小的一部分功能,这就要求了一个复杂的软件系统“分而治之”,从而通过建模简单化。
从而你会发现其实很复杂的系统软件或者工程总是变得很简单,解决了这小部分的简单问题,就形成了复杂而庞大的软件或者工程。
建模能帮助开发组更好地进行系统规划,并帮助他们进行架构软件,使用开发效率提高。
如果不建模,项目越复杂,就越会失败或者出现错误的东西。
总结归纳主要的软件工程模型,并任意选定其中的一种过程模式,介绍...
主要的软件过程模型有:瀑布模型,演化模型(如增量模型、原型模型、螺旋模型)、喷泉模型、基于构件的开发模型和形式方法模型等。
瀑布模型(waterfall model)是1970年有W.Royce提出的,它给出了软件生存周期活动的固定顺序,上一阶段的活动完成后向下一阶段过渡,最终得到所开发的软件产品。
瀑布模型如下图所示,有时也称为软件生存周期模型。
瀑布模型中,上一阶段的活动完成并经过评审后才能开始下一阶段的活动,其特征是:(1)接受上一阶段的结果作为本阶段活动的输入。
(2)依据上一阶段活动的结果实施本阶段应完成的活动。
(3)对本阶段的活动进行评审。
(4)将本阶段活动的结果作为输出,传递给下一阶段。
瀑布模型是最早出现的也是应用最广泛的过程模型,对确保软件开发的顺利进行、提高软件项目的质量和开发效率起到重要作用。
在大量的实践过程中,瀑布模型也逐渐暴露出它的不足。
首先,客户常常难以清楚地描述所有的要求,而且在开发过程中,用户的需求也常常会有所变化,使得不少软件的需求存在着不确定性;在某个活动中发现的错误常常是由前一阶段活动的错误引起的,为了改正这一错误必须回到前一阶段,这就导致了瀑布的倒流,也就是说,实际的软件开发很少能按瀑布模型的顺序没有回流地顺流而下。
其次,瀑布模型使得客户在测试完成以后才能看到真正可运行的软件,此时,如果发现不满足客户需求的问题(由于需求不确定性),那么修改软件的代价是巨大的。
不是任何软件都可采用瀑布模型的,瀑布模型适合于结构化方法,也就是面向过程的软件开发方法。
软件项目或产品选择瀑布模型必须满足下列条件:在开发时间内需求没有或很少变化;分析设计人员应对应用领域很熟悉;低风险项目(对目标、环境很熟悉);用户使用环境很稳定;用户除提出需求以外,很少参与开发工作。
瀑布模型 软件 过程
1 引言软件生命周期是软件由产生直到报废的生命周期,周期内可有可行性分析、需求分析、概要设计、详细设计、编码、测试和维护等阶段。
软件生命周期解释如何演绎软件过程的思想,是软件生命周期模型化技术的基础,也是建立软件开发环境的核心。
生命周期模型会为软件开发提供支持,为软件开发过程中所有活动提供政策保证,为参与软件开发的所有成员提供帮助和指导。
软件生命周期模型的适用与否,对于软件开发的成功、用户的满意影响巨大。
瀑布模型是软件工程中应用的非常广泛的一种软件生命周期模型,传统的软件工程方法学的软件过程基本上都可以用该模型进行描述。
2 瀑布模型瀑布模型是W.Royce 于1970 年首先提出的,由可行性研究、需求分析、系统设计、编码、测试、运行和维护各阶段组成。
该模型把软件生命过程比喻成瀑布的流水,每个阶段看作瀑布中的一个台阶,软件生命过程在台阶上由上向下流动。
瀑布模型规定上一阶段的变换结果是下一阶段变换的输入,相邻两个阶段具有因果关系,紧密相联。
为保障软件开发的正确性,每一阶段任务完成后,都必须对它的阶段性产品进行评审,确认之后再转入下一阶段的工作。
评审过程发现错误和疏漏后,应该反馈到前面的有关阶段修正错误、弥补疏漏,然后再重复前面的工作,直至某一阶段通过评审后再进入下一阶段。
瀑布模型的特点非常鲜明。
首先,它以文档形式驱动的,为管理者进行项目开发管理提供基础,对开发过程中的活动进行约束。
其次,它是一种整体开发模型,在开发过程中,用户看不见系统是什么样,只有开发完成向用户提交整个系统时,用户才能看到一个完整的系统。
最后,该模型过程逆转性很差或者说不可逆转,因为根据前面阶段的错误会在后面的阶段进行发散性传播的原理,所以逆转将会延误工期,增加成本,造成重大损失。
瀑布模型的优点如下:通过设置里程碑,能够明确每阶段的任务与目标;可为每阶段制定开发计划,进行成本预算,组织开发力量;通过阶段评审,将开发过程纳入正确轨道;严格的计划性保证软件产品的按时交付。
任何事物都不是完美的,瀑布模型也一样,该模型的缺点包括:缺乏灵活性,不能适应用户需求的改变;开始阶段的小错误被逐级放大,可能导致软件产品报废;返回上一级的开发需要十分高昂的代价;随着软件规模和复杂性的增加,软件产品成功的机率大幅下降。
3 V模型V模型是瀑布模型的变形,着重于测试活动如何与分析和设计相联系。
V 模型认为:单元测试和集成测试用于验证程序设计,即在单元测试和集成测中,编码人员和测试人员应确保程序设计的所有方面都已经在代码中正确实现;系统测试应验证系统设计,保证系统设计的所有方面都已正确实现;验收测试由用户来进行,把测试步骤与需求规格说明中的每一个要素联系起来对需求进行确认。
该模型中V 形左右两边连线说明各阶段的对应关系。
如果在验证和确认期间发现问题,应重新执行左边的步骤进行修正和改进相应的需求、设计和编码,然后去再次执行右边的测试,这样做使得迭代和重做的过程由隐藏变明确。
与瀑布模型关注对象是文档和制品相比,V 模型更加关注活动和正确性。
4 结束语不是任何软件都可采用瀑布模型的,瀑布模型适合于结构化方法,也就是面向过程的软件开发方法。
软件项目或产品选择瀑布模型必须满足下列条件:在开发时间内需求没有或很少变化;分析设计人员对应用领域很熟悉;低风险项目(对目标、环境很熟悉);用户使用环境很稳定;用户除提出需求以外,很少参与开发工作。
尽管上述条件比较苛刻,但是软件企业在开发新产品或新项目时往往还是采用瀑布模型,系统软件和工具软件也常常采用瀑布模型。
用软件开发流程怎样编写一个完整的程序
1 相关系统分析员和用户初步了解需求,然后用WORD例出要开发的系统的大功能模块,每个大功能模块有哪些小功能模块,对于有些需求比较明确相关的界面时,在这一步里面可以初步定义好少量的界面。
2 系统分析员深入了解和分析需求,根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。
这次的文档会清楚例用系统大致的大功能模块,大功能模块有哪些小功能模块,并且还例出相关的界面和界面功能。
3 系统分析员和用户再次确认需求。
4 系统分析员根据确认的需求文档所例用的界面和功能需求,用迭代的方式对每个界面或功能做系统的概要设计。
5 系统分析员把写好的概要设计文档给程序员,程序员根据所例出的功能一个一个的编写。
6 测试编写好的系统。
交给用户使用,用户使用后一个一个的确认每个功能,然后验收。
举个例子来看: 1 某公司想找人订做一套人事管理软件,从某种渠道上得知我们有提供这种服务,所以联系上了我们。
2 我们会派专门的软件工程师到他们那里去了解我们要设计一个什么的东西给他们用,然后回来做个方案给他们,其中方案的内容包括:我们开发出来的软件大概的界面是怎样?方便什么人使用?什么人可以使用什么功能?方便到什么程度?大概的硬件要求是怎样等? 3 他们看了方案后,确定他们就是要做一套这样的软件,我就开始开发这套软件。
4 我们把开发出来的软件交用他们使用,其中在使用的过程中哪里使用不方便或哪里达不到要求,我们会第第一时间修改这些功能,直到他们要求的所有功能都能很完美的解决掉。
已经很通俗了,不是么 :)
2. 比较各个软件开放过程模型与现在讲的rup(统一软件开发过程)有...
不知道你提到的是哪些方面的的模型。
rup是一个比较理想的软件软件工程方法,现在比较流行的敏捷开发理念中包含有极限编程,水晶方法等等或多或少都有些rup的影子,敏捷是一种理念,rup是一个完整的解决方案,在采用哪种过程方法来开发软件取决于项目的类型,规模等等。
rup属于偏重型,使用时可以适当裁剪已符合项目要求。
转载请注明出处51数据库 » 如何选择软件开发过程模型
亖呉?盀