1.4 软件开发模型


  • 瀑布模型
    • 瀑布
      1. 瀑布模型也称生存周期模型或线性顺序模型。这种模型是将软件生存周期各个活动规定为依据,线性顺序连接的若干阶段的模型,包括问题定义可行性研究需求分析概要设计详细设计编码测试维护
      2. 瀑布模型规定了由前至后、相互衔接的固定次序,恰如奔流不息拾级而下的瀑布。是自顶向下结构化开发模型
      3. 通过每个阶段,提交以下产品:软件需求规约、设计文档、实际代码、测试用例、最终产品等。工作产品流经“正向”开发的基本步骤路径。
      4. “反向”步骤流表示对前一个可提交产品的重复变更(又称“返工”)。
        • 由于所有开发活动的非确定性,因此是否需要重复变更,这仅在下一阶段或更加后面的阶段才能认识到。
        • 返工不仅在以前阶段的某一地方需要,而且对当前正在进行的工作也是需要的
      5. 在20世纪80年代之前,瀑布模型一直是唯一被广泛采用的生存周期模型,现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程,基本上可以用瀑布模型来描述。而且是以文档为驱动,适合于需求很明确的软件项目
    • 瀑布模型的特点
      1. 阶段的顺序性和依赖性:首先必须等前一阶段的工作完成之后,才能开始后一阶段的工作;其次前一阶段的输出文档就是后一阶段的输入文档;
      2. 推迟实现的观点:要尽量完善文档,然后才开始编写程序;
      3. 质量保证的观点:每一个阶段都必须完成所规定的相应文档;每一个阶段结束之前都必须对已完成的文档进行评审;
      4. 是一种理想的线性开发模式,缺乏灵活性。特别是无法解决软件需求不明确或不准确的问题;
      5. 适合于系统要求明确的小系统
    • 瀑布模型的优点
      1. 在决定系统怎样做之前,存在一个需求阶段,鼓励对系统“做什么”进行规约(即设计之前的规约)。
        • 设计之前一定要明确需要做什么,在设计之前有一个确定的入口。这样方式为我们后续的开发奠定一个坚实的基础。
      2. 在建造构件之前,存在一个设计阶段,鼓励规划系统结构(即编码之前的设计)。
        • 在编码之前一定要经过设计,软件的开发实际是在创造性的设计,是一个逻辑产品,软件是设计出来而不是制造出来的。所以我们要更加关注设计,也就是到底应怎么做。这是软件架构师和软件工程师智慧的结晶。
      3. 在每一阶段结束时进行复审,允许获取方和用户的参与(可以有效控制产品的质量)。
      4. 前一步工作产品可作为下一步被认可的、文档化的基线。允许基线和配置早期接受控制。
    • 瀑布模型的不足
      1. 客户必须能够完整、正确和清晰地表达他们的需求;开发人员一开始就必须理解需求。这是瀑布模型成功与否的最致命的缺点。
      2. 缺乏灵活性。一旦软件需求存在偏差,就会导致开发出的软件产品不能满足用户的实际要求。
      3. 在一个项目的早期阶段,过分地强调了基线和里程碑初的文档,可能要花费更多的时间,用于建立一些用处不大的文档。
      4. 直到项目项目结束之前,都不能演示系统的功能,增加了项目的风险。用户见面晚纠错慢难于克服系统分析员不懂专业领域的知识用户不懂计算机的困难,成功率低。
  • 增量模型
    • 增量
      1. 也称为渐增模型,是瀑布模型的顺序特征和快速原型法的迭代特征相结合的产物,是一种非整体开发的模型。
      2. 软件在模型中是“逐渐”开发出来的,把软件产品作为一系列的增量构件来设计、编码、组装和测试。每个构件由多个相互作用的模型构成,并且能够完成特定的功能。
      3. 开发出一部分向用户展示一部分,可让用户及早看到部分软件,及早发现问题。
    • 增量模型优点:作为瀑布模型的第一个变体,具有瀑布模型的所有优点。此外,它还有以下优点:
      1. 开发出一部分,向用户展示一部分,可让用户及早看到部分软件,及早发现问题。
      2. 由于用户可以很快看到部分软件功能,因此可以减少用户需求的变更。
      3. 开发由增量表示的小系统所承担的风险不大
        • 将复杂的软件划分成很多部分,分而治之,复杂性降低,风险也相应降低
      4. 允许增量投资,即在项目开始时,可以仅对一个或两个增量投资。
      5. 所以:适用于软件部分需求不明确的软件项目开发。软件可维护性强
    • 增量模型缺点:如果增量模型不适用于某些项目,或使用有误,则有以下缺点:
      1. 如果没有对用户的变更要求进行规划,那么产生的初始增量可能会造成后来增量的不稳定;
      2. 如果需求不像早期思考的那样稳定和完整,那么一些增量就可能需要重新开发,重新发布;
        • 如果要用增量模型,最初有一些需求一定是可确定的,如果什么需求都不能确定,肯定不能用增量模型。所以,增量一定是对一个确定的需求开发的一个产品。而且,每一个增量开发内部都相当于一个瀑布模型。
      3. 管理发生的成本、进度和配置的复杂性,可能会超出一些组织的能力
        • 不断的进行增量,而且每一个增量都要进行需求分析、设计、实现、测试、等过程,无形中增加了管理层的工作量、增加了管理协调的难度。
  • 演化模型
    • 是一种有弹性的过程模型,由一些小的开发步组成,每一步历经需求分析、设计、实现和验证,产生软件产品的一个增量,通过这些迭代,完成最终软件产品的开发。
      1. 针对实现不能完整的定义需求的软件开发
      2. 针对用户的核心需求,开发核心系统
      3. 根据用户的反馈,实施活动的迭代
  • 快速原型模型
    • 快速原型
      1. 主要思想:首先快速建立一个能够反映用户主要需求的原型系统,让用户在计算机上试用它,通过实践让用户了解未来目标系统的概貌,以便判断哪些功能是符合需要的,哪些方面需要改进,用户会提出许多改进意见,开发人员按照用户的意见快速地修改原型系统,然后再次请用户试用,这样反复改进,最终建立完全符合用户需求的新系统。
      2. 根据用户提出的软件定义,快速的开发一个原型,在征求用户对原型意见的过程中,再进一步修改、完善,直至达成一致。
        • 模拟软件的人机界面
        • 开发一个原型,实现已知需要实现的功能
        • 向用户展示正在运行的类似软件
    • 优点
      1. 与用户见面快
      2. 开发成功率高(能渐进地启发客户提出新的要求)
      3. 适合于需求不确定的大系统
    • 缺点
      1. 周期长开发成本高
        • 没有考虑软件的整体质量和长期的可维护性。
        • 由于达不到质量要求产品可能被抛弃,而采用新的模型重新设计
  • 演化模型和快速原型模型的区别
    1. 演化模型是一种原型化开发方法,与快速原型模型略有不同。
    2. 在快速原型模型中,原型的用途是获知用户真正的需求,一旦需求缺点了,原型即被抛弃了。
    3. 演化模型开发的过程则是从初始模型逐步演化为最终软件产品的渐进过程。
    4. 快速原型模型是一种“抛弃式”的原型化方法,而演化模型则是一种“渐进式”的原型化方法。
  • 螺旋模型
    • 螺旋
      1. 螺旋模型加入了瀑布模型与增量模型都忽略了的风险分析,弥补了两种模型的不足。它是一种风险驱动的模型。
      2. 螺旋模型是一种迭代模型(延续了快速原型模型的特点),它把开发过程分为几个螺旋周期,每迭代一次,螺旋线就前进一周。
      3. 特点
        • 瀑布模型+快速原型+风险分析
        • 迭代过程
        • 适合于大规模高风险需求不明确的软件项目开发。
      4. 螺旋模型沿着螺线旋转(一个螺旋式周期 ),每迭代一次,软件开发又前进一个层次。在四个象限上分别表达四个方面的活动:
        • 制定计划——确定软件目标,选定实施方案,弄清项目开发的限制,选定完成目标的策略。
        • 风险分析——分析所选方案,考虑如何识别和消除风险,风险角度分析该策略。
        • 实施工程——实施软件开发,启动一个开发阶段
        • 客户评估——评价前一步开发工作,提出修正建议,计划下一轮的工作。
      5. ![[Pasted image 20230601111636.png]]
    • 优点
      1. 设计上的灵活性,可以在项目的各个阶段进行变更。
      2. 以小的分段来构建大型系统,使成本计算变得简单容易。
      3. 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
      4. 随着项目推进,客户始终掌握项目的最新信息,从而客户能够和管理层有效地交互。
      5. 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
    • 缺点
      1. 很难让用户确信这种演化方法的结果是可以控制的。建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求。
  • 喷泉模型
    • 喷泉
      1. 喷泉模型:以用户需求为动力,以对象作为驱动的模型,适合面向对象的开发方法
      2. 软件开发过程自下而上周期的各阶段是相互迭代无间隙的特性
      3. 迭代是指各阶段需要多次重复。一个循环接着下一个循环,不断的往前推进,每次都进行优化。例如,分析和设计阶段常常需要多次重复进行,以更好的实现需求。
      4. 无间隙性是指在分析、设计和实现之间不存在明显的边界。
      5. ![[Pasted image 20230601113718.png]]
  • 基于构件的开发模型
    • 基于构建的开发
      1. 经过一定的设计和实现的可称为构件,它们可以有不同的计算机软件系统中复用,在某个领域具有一定的通用性。
      2. 基于构件的开发模型是利用预先封装的软件构件来构造应用软件系统,从而提高软件的重用性和可靠性。
  • 统一过程(RUP)模型
    • ![[Pasted image 20230601152107.png]]
    • 统一过程
      1. 软件统一开发过程是基于面向对象统一建模语言UML(Unified Modeling Language)的一种面向对象的软件过程模型。
      2. RUP(Rational Unified Process)是一个通用的过程框架,可以用于各种不同模型的软件系统,各种不同的应用领域和不同规模的项目。
      3. RUP的特点是由用例驱动,以构架为中心,采用迭代和增量的开发策略。RUP软件生存周期是一个二维的软件开发模型
      4. 统一软件开发过程 开发生命周期是一个二维的软件开发模型。
      5. 横轴通过时间组织,是过程展开的生命周期特征,体现开发过程的动态结构,用来描述它的术语主要包括周期、阶段、迭代和里程碑
      6. 纵轴内容来组织为自然的逻辑活动,体现开发过程的静态结构,用来描述它的术语主要包括活动、产物、工作者和工作流。
  • 基于形式化的模型
    • ![[Pasted image 20230601152625.png]]
    • 基于形式化
      1. 典型的适合于形式化开发的模型:
        • 变换模型是结合形式化软件开发方法和程序自动生成技术的一种软件开发模型。它采用严格的、数学的表示体系来表示软件规格说明,从软件需求形式化说明开始,经过一系列变换,最终的得到了系统的目标程序。
        • 是一种增量开发模型。其基本思想是力求在分析和设计阶段就消除缺陷,却保正确,然后在无错误或“净室”的状态下实现软件的开发。
    • 特点
      1. 形式软件开发方式
        • 形式化需求规格说明
        • 变换技术
      2. 程序自动生成技术
      3. 确保正确
    • 基于形式化的模型——净室模型
      1. ![[Pasted image 20230601152846.png]]
      2. 净室思想
        • 在分析和设计阶段消除错误
        • 在“洁净”状态下实现软件制作
      3. 形式化
        • 盒结构表示分析和实际
        • 正确性验证
      4. 增量模型

    • 各种软件开发模型的对比
      1. 瀑布模型:经典,需求确定
      2. 快速原型模型:快速获取用户需求
      3. 增量模型:灵活,允许软件变化
      4. 螺旋模型:加入风险
      5. 喷泉模型:典型面向对象开发模型
      6. 基于构建的开发模型:提高软件重用性和可靠性
      7. 统一过程模型:基于UML和OO过程模型
      8. 基于形式化的模型:确保严格、无措
  • 概括
    ![[Pasted image 20230601155619.png]]

文章作者: Chipfron
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 Chipfron !
  目录