软件工程1-软件过程模型

Posted on 2025-05-01

软件过程模型

软件生命周期

定义：软件产品或软件系统从设计、投入使用到被淘汰的全过程。

软件过程

定义：软件过程定义了软件生产的一些列活动，这些活动贯穿于软件开发的全过程

沟通：包括软件设计者和客户，客户提出需求，软件设计者收集材料或其他活动
计划：讨论使用什么方法实现需求
建模：设计模型满足需求
构造：编码和测试
部署：软件交付给客户

三个流派：

能力成熟度模型CMM：
- CMU-SEI的CMM是公认的有关软件工程和管理实践的最好的软件过程。
- 为评估软件组织的生产能力提供了标准，为提高软件组织的生产过程指明了方向。
- CMM1初始级：有能力的核心成员发挥；
  
  CMM2可重复级：基本的项目管理；
  
  CMM3已定义级：过程标准化，开发过程实现标准化和文档化；
  
  CMM4量化管理级：产品和过程已建立了定量的质量目标；
  
  CMM5优化级：持续的过程改进，可集中精力改进过程，采用新技术、新方法；
ISO 9000质量标准
软件计数软件过程评估：SPICE

CMM的关键过程域：

CMM	过程
CMM2:可重复阶段	1. 需求管理： requirement management 2. 软件项目计划： software project planning 3. 软件项目跟踪和监督： software project tracking oversight 4. 软件子合同管理： software subcontract management 5. 软件质量保证： software quality assurance 6. 软件配置管理： software configuratione management
CMM3:已定义阶段	1. 组织过程焦点： organization process focus 2. 组织过程定义： organization process definition 3. 培训大纲： training program 4. 集成软件管理： intergrated software management 5. 软件产品工程： software product engineering 6. 组间协调： intergroup coordination 7.同行评审： peer review
CMM4:已管理阶段	1. 定量管理过程： quantitative process management 2. 软件质量管理： software quality management
CMM5:优化阶段	1. 缺陷预防： defect prevention 2. 技术改革管理： technology change management 3. 过程更改管理： process change management

软件过程模型

软件过程模型是软件开发全部过程、活动和任务的结构框架；
它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。软件过程模型也常称为：软件开发模型，软件生存周期模型，软件工程范型；

常见过程模型：

瀑布模型
增量模型
演化过程模型
喷泉模型
…

瀑布模型

软件开发过程与软件生命周期一致，也是经典的生命周期模型[Winston, 1970];

经典的瀑布模型

特点：

阶段间具有顺序性和依赖性；
推迟实现的观点；
每个阶段必须完成规定的文档；每个阶段结束前完成文档审查，及早改正错误。

带反馈的瀑布模型

主要问题：线性过程太理想化

各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

瀑布模型适用于系统需求明确，技术成熟，工程管理较为严格的场合；

增量过程模型

增量过程模型是一种非整体开发的模型，是一种进化式的开发过程。
它允许从部分需求定义出发，先建立一个不完整的系统，通过测试运行这个系统取得经验和反馈，进一步使系统扩充和完善。如此反复进行，直至软件人员和用户对所设计的软件系统满意为止。

特点：

增量适用于小而可用的软件，在前面增量的基础上开发后面的增量
每个增量的开发可用瀑布或快速原型模型
快速迭代

优点：

增量包概念的引入，以及它不需要提供完整的需求。只要有一个增量包出现，开发就可以进行。
在项目的初始阶段不需要投入太多的人力资源。
增量可以有效地管理技术风险。

缺点：每个增量必须提供一些系统功能，这使得开发者很难根据客户需求给出大小适合的增量。

快速应用开发模型（RAD）

作为增量过程模型的一种，是一个增量过程模型，强调短暂的开发周期。
RAD 模型是瀑布模型的“高速”变体，通过基于组件的构建方法实现快速开发。如果需求以及项目范围得到明确界定， RAD 能使开发团队在很短的时间内（如 60 到 90 天）建立一个“全功能系统”。

缺点：

对大型项目而言 RAD 需要足够的人力资源。
开发者和客户都要实现承诺，否则将导致失败。
并非所有系统都适合（不能合理模块化的系统、高性能需求并且要调整构件接口的、技术风险很高的系统均不适合）。

演化模型

演化模型包括原型模型和螺旋模型，思想是首先实现软件最核心的最重要的功能；

原型模型：客户定义一个总体目标集，但是他们并不清楚系统的具体输入输出；或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式。
- 缺点：设计者在质量和原型间有所折衷，客户意识不到一些质量问题；
螺旋模型：结合了瀑布模型和原型模型的特点，强调风险管理，适用于大型系统的开发；
- 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件。
  风险分析：分析所选方案，考虑如何识别和消除风险。
  实施工程：实施软件开发。
  客户评估：评价开发工作，提出修正建议。
- 优点：
  - 支持用户需求的动态变化。
  - 原型可看作形式的可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便。
  - 螺旋模型特别强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力。
  - 螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险。
- 缺点：
  - 如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间；
  - 使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高。
- 适用场合：支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。

喷泉模型

喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述 面向对象 的软件开发过程。

优点：该模型的各个阶段没有明显的界限，开发人员可以同步进行开发，可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
缺点：由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

基于构件的模型

四阶段：

需求
组件分析：根据需求规格搜索可满足该需求的组件。通常情况下，没有完全匹配的情况，因而组件通常需要加以修改。
系统设计：与其它模型的系统设计有所不同，因为该模型是基于重用的。设计者必须考虑到重用的概念，但遗憾的是，如果没有可重用的组件，还要设计新的软件。
开发和集成：在这个阶段，组件集成到系统中。

优点：

组件的重用，降低了成本和风险，节约了时间；

缺点：

模型复杂
导致需求的折衷，进而导致系统不能完全符合需求
无法完全控制所开发系统的演化
项目划分的好坏直接影响项目结果的好坏

敏捷开发模型

是一种从 90 年代开始逐渐引起广泛关注的一些新型软件开发方法。

迭代与增量开发：敏捷开发将整个软件项目分成多个小的迭代（通常是2到4周），每个迭代都是一个完整的开发周期，包括需求分析、设计、编码、测试和交付。在每个迭代结束时，都会交付一个可以运行的产品版本，这个版本可能是部分功能的实现，但能够为用户或利益相关者提供价值。
重视客户和用户的反馈：敏捷开发模型注重与客户和用户的频繁沟通和合作。在每个迭代结束时，团队会向客户展示当前的成果，并根据他们的反馈调整下一步的开发方向。这种方式使得项目可以快速适应需求的变化，确保最终交付的产品更符合用户期望。
跨职能团队：敏捷团队通常是小型的、跨职能的团队，包含开发人员、测试人员、产品经理和用户代表等。这种团队结构使得每个人都能为产品的不同方面贡献力量，并能快速响应问题和需求。
自组织和自管理：敏捷强调团队的自组织能力，团队成员可以根据需求自行安排工作，决定如何实现目标。管理者不会详细指挥每个步骤，而是让团队在一定框架下自行运作，这有助于提升团队的灵活性和响应速度。
持续改进：敏捷开发鼓励持续的反思和改进。团队在每次迭代结束后通常会进行一个回顾会议（Retrospective），讨论在过去的迭代中哪些方面做得好，哪些方面可以改进，以便在下一次迭代中做得更好。
早期和持续的交付：敏捷模型的目标是尽可能早地向用户提供有价值的软件。团队会在项目的早期阶段就交付一个可工作的系统，并在后续的迭代中不断增加新功能。
适应性：敏捷方法强调对变化的接受，认为变化是不可避免的。无论是需求变化还是市场变化，敏捷团队都能快速调整计划和优先级，以适应新的形势。
常见框架：敏捷开发模型下有多种实施框架，其中最常见的包括Scrum、Kanban和Extreme Programming（XP）。这些框架提供了具体的流程和实践，帮助团队有效地进行敏捷开发。
工作方式透明：敏捷团队通过每日站会（Daily Stand-up Meeting）等方式，让所有团队成员了解彼此的工作进展，暴露潜在的问题，并快速做出调整，确保项目的顺利进行。
文档减少，但非无文档：与传统的瀑布模型相比，敏捷开发减少了过多的文档要求，更注重可交付的软件。然而，敏捷并不排斥文档，而是提倡根据项目实际需求编写足够的文档。

优点：

快速响应变化，适应市场需求
早期交付可用的产品，增加市场竞争力
增强团队协作，减少沟通障碍
持续改进，确保产品质量不断提升

缺点：

需求变化频繁时，可能导致开发团队的工作压力增大
需要高效的沟通和跨职能合作，否则可能影响效率
项目初期规划不够详细，可能增加项目后期的复杂性

如何选择过程模型？

软件开发模型是不断发展的，各种软件开发模型各有优缺点
选用时不必拘泥于某种模型，可组合多种模型，也可根据实际创建新的模型

参考原则

在前期需求明确的情况下，尽量采用瀑布模型或改进的瀑布模型。
在用户无系统使用经验，需求分析人员技能不足情况下一定要借助原型。
在不确定因素很多，很多东西前面无法计划的情况下尽量采用增量迭代和螺旋模型。
在需求不稳定的情况下尽量采用增量迭代模型。
在资金和成本无法一次到位的情况下可采用增量模型，软件产品多个版本进行发布。
对于完成多个独立功能开发可以在需求分析阶段就进行功能并行，但每个功能内部都应该遵循瀑布模型。
对于全新系统的开发必须在总体设计完成后再开始增量或并行。
对于编码人员经验较少的情况下建议不要采用敏捷或迭代等生命周期模型。
增量、迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口原则。

参考原则：