软件工程:理论、方法与实践 软件过程读后感

在软件过程里面,从前言里面我们知道绝大多数软件企业长期面临许多质量,进度,成本的问题,所以产生了人物思维与过程思维两种方式,现在我们对其有了一个定义:软件过程为一个为建造高质量软件所需完成的任务的框架,即形成软件产品的一系列步骤,包括中间产品、资源、角色及过程中采取的方法、工具等范畴。它的基本活动是:问题提出,软件需求规格说明,软件设计,软件实现,软件确认与软件演化等活动。

第二节里我们学习了软件过程模型,其主要如下所示:

1.瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。瀑布模型本质是一次通过,即每个活动只执行一次,最后得到软件产品,也称为“线性顺序模型”或者“传统生命周期”。其过程是从上一项活动接收该项活动的工作对象作为输入,利用这一输入实施该项活动应完成的内容给出该项活动的工作成果,并作为输出传给下一项活动。同时评审该项活动的实施,若确认,则继续下一项活动;否则返回前面,甚至更前面的活动。

瀑布模型有利于大型软件开发过程中人员的组织及管理,有利于软件开发方法和工具的研究与使用,从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明,上述各项活动之间并非完全是自上而下且呈线性图式的,因此瀑布模型存在严重的缺陷。

① 由于开发模型呈线性,所以当开发成果尚未经过测试时,用户无法看到软件的效果。这样软件与用户见面的时间间隔较长,也增加了一定的风险。

② 在软件开发前期末发现的错误传到后面的开发活动中时,可能会扩散,进而可能会造成整个软件项目开发失败。

③ 在软件需求分析阶段,完全确定用户的所有需求是比较困难的,甚至可以说是不太可能的。

2. 快速原型模型需要迅速建造一个可以运行的软件原型 ,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。 快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义,快速设计开发出软件系统的原型,该原型向用户展示待开发软件的全部或部分功能和性能;用户对该原型进行测试评定,给出具体改进意见以丰富细化软件需求;开发人员据此对软件进行修改完善,直至用户满意认可之后,进行软件的完整实现及测试、维护。它是增量模型的另一种形式;它是在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。这也是最常见的模型之一,但是其优缺点也有,其主要为:优点:克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险。

这种模型适合预先不能确切定义需求的软件系统的开发。

缺点:所选用的开发技术和工具不一定符合主流的发展;快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。

使用这个模型的前提是要有一个展示性的产品原型,因此在一定程度上可能会限制开发人员的创新。

3. 增量模型融合了瀑布模型的基本成分(重复应用)和原型实现的迭代特征,该模型采用随着日程时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时,第1个增量往往是核心的产品,即第1个增量实现了基本的需求,但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能,这个过程在每一个增量发布后不断重复,直到产生了最终的完善产品。

它的特点是:增量模型的特点是引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改,但只要这个增量包足够小,其影响对整个项目来说是可以承受的。

优点为:1) 由于能够在较短的时间内向用户提交一些有用的工作产品,因此能够解决用户的一些急用功能。

2)由于每次只提交用户部分功能,用户有较充分的时间学习和适应新的产品。

3)对系统的可维护性是一个极大的提高,因为整个系统是由一个个构件集成在一起的,当需求变更时只变更部分部件,而不必影响整个系统。

缺点为:1) 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。

2) 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型快速原型模型,但也很容易退化为边做边改模型,从而使软件过程的控制失去整体性。

3)如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析,这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。

4. 螺旋模型是一种演化软件开发过程模型,它兼顾了快速原型迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。同时,在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。螺旋模型强调风险分析,使得开发人员和用户对每个演化层出现的风险有所了解,继而做出应有的反应,因此特别适用于庞大、复杂并具有高风险的系统。螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:

四种象限

(1)制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;

(2)风险分析:分析评估所选方案,考虑如何识别和消除风险;

(3)实施工程:实施软件开发和验证;

(4)客户评估:评价开发工作,提出修正建议,制定下一步计划。

螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。

常见问题为:


经常遇到的问题


螺旋模型的解决方案


用户需求不够充分


允许并鼓励用户反馈信息


沟通不明


在项目早期就消除严重的曲解


刚性的体系(Overwhelming architectures)


开发首先关注重要的业务和问题


主观臆断


通过测试和质量保证,作出客观的评估


潜在的不一致


在项目早期就发现不一致问题


糟糕的测试和质量保证


从第一次迭代就开始测试


采用瀑布法开发


在早期就找出并关注风险

限制条件为:(1)螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的,因此,这种模型往往适应于内部的大规模软件开发。

(2)如果执行风险分析将大大影响项目的利润,那么进行风险分析毫无意义,因此,螺旋模型只适合于大规模软件项目。

(3)软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险

一个阶段首先是确定该阶段的目标,完成这些目标的选择方案及其约束条件,然后从风险角度分析方案的开发策略,努力排除各种潜在的风险,有时需要通过建造原型来完成。如果某些风险不能排除,该方案立即终止,否则启动下一个开发步骤。最后,评价该阶段的结果,并设计下一个阶段。

优点为:1)设计上的灵活性,可以在项目的各个阶段进行变更

2)以小的分段来构建大型系统,使成本计算变得简单容易。

3)客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。

4)随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。

5)客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

缺点为:很难让用户确信这种演化方法的结果是可以控制的。建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求。

螺旋模型的项目适用:

对于新近开发,需求不明确的情况下,适合用螺旋模型进行开发,便于风险控制和需求变更。

其最核心的组成部分为:“螺旋模型”刚开始规模很小,当项目被定义得更好、更稳定时,逐渐展开。

螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵,定义最重要的功能,实现它,然后听取客户的意见,之后再进入到下一个阶段。如此不断轮回重复,直到得到您满意的最终产品。

每轮循环包含如下六个步骤:

1. 确定目标,可选项,以及强制条件。

2. 识别并化解风险。

3. 评估可选项。

4. 开发并测试当前阶段。

5. 规划下一阶段。

6. 确定进入下一阶段的方法步骤。

这是一个比较好的模型。

第三节里则介绍了微软公司的开发过程,通过这我们知道技术不是项目成功与否的唯一决定因素,其开发过程模型由规划,设计,开发,稳定与发布5个过程,但是每个过程又是由里程碑驱动的。它有着许多显著地特点:1.解决问题的及时性。2.不确定与变更因素的可控性。3.缩短产品的上市周期。

时间: 2024-12-21 20:11:59

软件工程:理论、方法与实践 软件过程读后感的相关文章

软件工程理论方法与实践第二章读后感

第二章读后感 为解决软件开发的问题,首先是将整个软件开发任务看做是一个可比较的刻度量的可改造,而软件过程是软件工程人员为了获得软件产品而在软件工具的支持下实施的一系列软件工程活动,主要包括问题提出,软件需求规格说明,软件设计等等.软件过程模型主要分为瀑布模型,快速原型模型,增量模型,螺旋模型,形式化方法模型,基于组件的开发模型.而微软公司的软件过程模型由规划,设计,开发,稳定和发布五个主要阶段组成,采取低近视的软件开发策略,具体表现在解决问题的及时行.不确定和变更因素的可控性,缩短按产品的上市周

软件工程理论方法与实践第五章读后感

形式化方法是指将离散数学的方法用于解决软件工程领域的问题,主要包括建立精确的数学模型以及对模型的分析活动,从根本上讲,软件设计过程就是一个建立形式化规约,软件设计的最终产物--程序在进行形式化的过程中涉及到三中系统模型:现实世界,模型表示和计算机系统.软件规格说明是对软件系统对象,对象的操作系统以及对象行为的描述,形式化的规格说明可用自然语言图表等形式来描述,模型检测主要用于有穷状态系统,优点是完全自动化并且验证速度快

软件工程理论方法与实践第一章读后感

软件是计算机程序,规程以及运行计算机系统可能需要的相关文档和数据,根据软件服务UI想的范围不同,一般可以将软件划分为通用软件和定制软件两种类型.软件的特性主要有,软件是复杂的,不可见的,不断变化的,大多数软件是定制的而不是通过已有的构建组装而成的,然而在软件开发过程中软件开发的成本和进度难以准确估计,延迟交付甚至取消项目的现象屡见不鲜,软件存在这错误多性能低不可靠不安全等质量问题,软件成本在计算机系统的整个成本中所占比例越来越大,且维护困难等等,而软件工程中则是将工程化应用到软件上,由过程方法和

软件工程理论方法与实践第六章读后感

面向对象技术比较自然的模拟了人类认识客观世界的方式,成为当前计算机软件工程学中的主流方式,具有相同数据和相同操作对象可以归为一个类,对象是对象类的一个实例,类可以派生出子类,子类继承父类的全部特性,面向对象=对象+类+挤成+通信.面向对象的软件工程方法:面向对象分析,面向对象设计,面向对象编程,面向对象设计,面向对象维护, 属相和对象是构成对象的两个基本要素,其定义是,属性是用来面熟对象静态特征的一个数据项,服务是用来描述对象动态特征的一个操作序列,类是具有相同属性和服务的一组对象的集合,封装是

软件工程理论方法与实践第八章读后感

设计是一个建模的活动他在分析模型的基础上完成在实现环境的类建模,状态图建模,协作建模,组件建模,部署建模,持久建模和用户界面原型,实现从需求分析到软件实现之间的跨越.设计活动,系统设计两个主要阶段,详细设计是细化原有的分析对象,确定一些新的对象,对每一个子系统接口和类,进行准确详细的说明.模块性降低复杂性的有效方法是将系统模块化,将一个复杂的大系统分解成若干个相对的较小部分,成为子系统(Subsystem).如果一个子系统依然是复杂的,那么继续分解直到易于开发和管理为止.子系统是一个定义明确的软

软件工程理论方法与实践第四章读后感

软件需求从用户角度来说是用户解决问题和达到目标所需的条件或能力,从开发人员角度来说系统或系统部件要满足合同标准规范或其他正式规定文档所需具有的条件或能力.软件功能需求必须根据用户需求来考虑,而且应该与业务需求定义的目标一致,业务需求是组织或客户对于系统地高层次目标要求,定义了项目的远景和范围,项目软件产品的发展方向,功能能够范围,目标客户,和价值来源.用户需求是从用户角度描述的系统功能需求和非功能需求.功能需求描述的是系统应该提供的功能或服务,通常涉及用户或外部系统与该系统之间的交互一般不考虑系

软件工程理论方法与实践第三章读后感

第三章读后感 软件项目管理是为了是软件项目能够按照预定的成本,进度,质量顺,而对成本人员,进度,风险进行扥系和管理的活动.有效的软件管理集中于人员,产品,过程,项目.软件项目的生命周期包括项目启动,项目规划,项目实施和项目收尾四个阶段.接下来是人员组织与管理,主要有三种典型的开发组织模式民主是组织结构,主程序员式组织结构,技术管理是组织结构,以微软公司的软件开发为例,它的软件开发团队的特色是采用小型的多元化的项目组织进行软件开发,具有交流和管理成本低决策和执行速度低,产品质量易于控制的特点.对于

软件工程理论方法与实践第七章读后感

面向对象分析模型有三个独立的模型组成:功能模型,分析对象分析,动态模型.分析类是概念层次上的内容,用于描述系统中较高层次的对象.边界类用于描述外部参与者与系统之间的交互,控制类用于描述一个用例所具有的事件流控制行为,实体类用于描述必须存储的信息及其相关行为,分析活动的主要活动首先开发人员进一步理解最初的用例模型和词汇表,识别出系统的分析类:其次,通多建立系统的顺序图发现可能一楼的对象丙丁一分析类的重要属性和行为,确定分析类之间的关系,从而得到进一步细化的分析模型:最后开发人员和用户一起检查模型,

软件工程理论方法与实践第九章读后感

第九章主要讲了代码的规范性,首先要有适当的空行,注意分行对齐与缩进,命名规则:标识符的命名应当直观,可以望文知义,最好采用英文单词或其组合,标识符的长度应当符合最小长度下的最大信息原则, 过长的英文单词应该采用一些通用而合理的缩写或者应用领域专业术语的缩写等等,声明,尽量在变量生命是进行初始化,只有当变量的处置依赖于某些计算得到的值时可以不对其进行初始化等等.对于软件程序编码程序注释问题要注意注释的目的是有助于对程序的阅读理解,不宜太多也不能太少,注释语言必须准确易懂简洁避免使用缩写,内存异常可