论软件过程模型的实际应用

找了一圈尾巴

已于 2024-03-05 00:27:17 修改

阅读量1k

点赞数 26

文章标签：软件工程

于 2024-03-05 00:25:22 首次发布

本文链接：https://blog.csdn.net/weixin_41645817/article/details/133992939

版权

写本篇文章的主要目的是复习软件过程模型的主要知识点。然后以方法论为基础，结合实际工作经验总结软件过程模型的实际应用。最后对现有的开发过程面临的问题做出总结，定义并完善适合自己的软件开发过程。

一. 何为软件过程模型？

60年代中期，随着计算机的飞速发展，计算机软件的使用和普及，软件开发量也随之急剧增长。而软件系统的规模越做越大，复杂程度越来越高，开发者所面临的软件可靠性等问题也越来越突出。1968年，北大西洋公约组织在国际学术会议首次提出了软件危机的概念。软件危机的具体表现为：

1. 软件开发进度难以预测

2.软件开发成本难以控制

3.软件功能难以满足用户期望

4.软件质量难以保证

5.软件难以维护

6.软件缺少适当的文档资料

为了解决软件危机，NATO 连续召开了两次会议，最终提出了软件工程的概念。软件工程简单来说就是为了解决软件危机所面临的问题，以工程学为基础定义了一套流程化、系统化的软件开发过程。而本次要重点介绍的软件过程模型，就是软件工程中定义的方法论中的一部分。

软件过程模型中定义了软件生命周期所经历的各个阶段，以最早定义的最经典的软件过程模型-瀑布模型举例，软件的生命周期过程是从制定软件开发计划开始，然后需要经过需求分析，软件设计，软件编码，软件测试，软件的运行与维护这几个阶段。所以，定义软件过程模型的目的是为了使软件开发过程的各项任务能够有序的按照规程顺利进行，以确保开发软件的正确性、效率和质量，以及后续的软件维护工作、软件迭代更新工作的顺利进行。

二. 软件过程模型包括什么？

面向过程模型介绍

图2.1 瀑布模型

最初定义的软件过程模型是瀑布模型，它包含了一系列活动，而且每一个活动从一个阶段到下一个阶段都需要按顺序执行。一个活动结束后，它输出的内容将是下一个活动的输入内容，所以前一阶段工作的正确性将直接影响后续工作的行进方向。瀑布模型影响深远，直至现在的各大小公司的软件开发工作流程，以及各种Devops工具的设计，都是参照瀑布模型进行规划的。

但是瀑布模型也有其明显的不足。首先它是一个严格串行化的过程模型，用户只有在最后阶段才能看到软件制品。如果出现与用户的期望不一致，或者出现需求变更，将会带来巨大的损失。再者软件的需求是很难一次性就定义完善的，尤其是当今的互联网+ 时代，需求的变更更是频繁的。而瀑布模型它的基本原则是在每个阶段一次性地完全解决该阶段的工作，而这几乎是不可能实现的。

所以为了解决瀑布模型的不足，后续更迭出现了很多新的模型。

图2.2 原型模型

原型化模型建立在在瀑布模型的基础上，在软件开发前期增强了与用户的沟通交流，需求探讨。在需求分析阶段以及设计阶段，原型化模型增加了原型开发阶段，开发者需要快速地开发一个原型。然后使用原型提前给用户展示开发软件的设计和功能，从而减少用户需求的不确定性，并使最终的软件制品更贴近客户的预期。

图2.3 螺旋模型

螺旋模型则是瀑布模型和原型模型的结合，它综合了两者的优点，并增加了风险分析。它以原型为基础，沿着螺线自内向外旋转，每旋转一圈都经过目标设定、风险分析、开发和有效性验证、评审四个步骤，并开发原型的一个新版本。经过若干次螺旋上升的过程，得到最终的系统。

图2.4 增量模型

增量模型则融合了瀑布模型的基本成分和原型实现的迭代特征。第一个增量是用户最关心的核心产品，后续的产品功能则放在后续版本持续迭代增加。它虽然不是完善的，但是是快速交付的；客户对每一个增量的使用和评估，都会影响下一个增量发布的新特性和功能。增量模型将功能细化，分别开发的方法更适用于需求经常改变的软件开发过程。

面向对象模型介绍

上述几个软件过程模型都是面向过程的，即以各阶段的过程为中心来定义的软件过程模型。而随着时代的发展，面向对象思想在软件行业的普及利用，后续人们也定义出了以面向对象思想为核心的软件过程模型。

图2.5 喷泉模型

喷泉模型主要支持面向对象的开发方法。“喷泉”一词就明显体现了这个模型的迭代和无间隙特征。“迭代”是指系统的某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。“无间隙”是指在开发过程中，分析，设计和编码之间不存在明显的边界；

图2.6 基于构件的软件开发模型

构件是一个具有可重用价值的，功能相对独立的软件单元。基于构件的软件开发模型是利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库的一个或多个软件构件，通过组合手段高效率，高质量的构造应用软件系统的过程。

基于构件的开发活动从标识候选构件开始，通过搜索已有构件库，确认所需要的构件是否已经存在，如果已经存在，就从构件库中提取出来复用；如果不存在，就采用面向对象方法开发它。在提取出来的构件通过语法和语义检查后，将这些构件通过胶合代码组装到一起实现系统，这个过程是迭代的。

快速应用开发模型（RAD）是一个增量型的软件开发过程模型，强调极短的开发周期。RAD 模型是瀑布模型的“高速”变种，与瀑布模型相比，RAD 模型不采用传统的第三代程序设计语言来创建软件，而是采用基于构件的开发方法，复用已有的程序结构或使用可复用构件，或创建可复用的构件。在所有情况下，均使用自动化工具辅助软件创造。

重工模型介绍

统一过程模型（RUP）是一个统一的软件开发过程，是一个通用过程框架，可以应付种类广泛的软件系统，不同的应用领域，不同的组织类型，不同的性能水平和不同的项目规模。RUP 描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。RUP类似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。

图2.7 RUP 模型图

如图2.7 RUP模型图所示，纵轴表示RUP模型包含九个核心工作流，横轴表示RUP把软件生命周期划分为四个连续阶段。RUP 是用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。

软件成熟度模型 CMMI 是由美国卡耐基梅隆大学软件工程研究所组织全世界的软件过程改进和软件开发管理方面的专家历时四年而开发出来的，并在全世界推广实施的一种软件能力成熟度评估标准，主要用于知道软件开发过程的改进和进行软件开发能力的评估。CMMI 提供了一个软件能力成熟度的框架，它将软件过程改进的步骤组织成5个成熟度等级，共包括18个关键过程域，52 个过程目标，3168 种关键时间，它为软件过程不断改进奠定了一个循序渐进的基础。

敏捷模型介绍

近些年从事软件行业的人一定不会对“敏捷开发”这个词陌生，而正式提出“敏捷”这个概念是在2001年2月举行的一次敏捷方法发起者和实践者的聚会上。敏捷方法主要强调的核心首先是拥抱变化，软件的开发过程是具有适应性的；其次是定义了敏捷开发是一个迭代增量式的开发过程；最后它将软件过程模型从以过程为本，变成了软件开发这个过程还是要以人为本的。所以后续介绍的敏捷模型都将关于人的概念放入到了模型里面。

在所有敏捷模型中，极限编程（XP）是最引人瞩目的。极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气，即任何一个软件项目都可以从4个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP 是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其他一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

水晶系列方法是由 Alistair Cockburn 提出的敏捷方法系列。它与XP 方法一样，都有以人为中心的理念，但在实践上有所不同。其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。Crystal 家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程，它的发明使得敏捷团队可以根据其项目和环境选择最合适的Crystal 家族成员。

Scrum方法则更侧重于项目管理，它是一个包括了一系列实践和预定义角色的过程骨架。在Scrum 中，使用产品 Backlog 来管理产品的需求，产品 Backlog 是一个按照商业价值排序的需求列表。根据Backlog 的内容，将整个开发过程被分为若干个短的迭代周期。在 Sprint 中，Scrum 团队从产品Backlog 中挑选最高优先级的需求组成 Sprint backlog。在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量。当所有Sprint 结束时，团队提交最终的软件产品。

特征驱动开发方法 FDD 是由 Jeff De Luca 和大师 Peter Code 提出来的。FDD 是一个迭代的开发模型。FDD 认为有效的软件开发需要3个要素：人、过程和技术。FDD 定义了6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员、领域专家。根据项目大小，部分角色可以重复。FDD 有5个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。

对于敏捷模型的理解

虽然现在敏捷开发这个词在互联网行业炒的很火爆，就好像互联网时代人人都要向“敏捷”看齐，否则就是落伍了，掉队了。但是在我看来，敏捷模型的定义更适用于工作了10年以上的程序员大佬。而作为学习者的我们还是首先要先从过程模型的流程化开始，先把基础打扎实，然后再去追求敏捷开发中提到的关于更符合人性的，更深层次的内容。

首先敏捷开发更注重沟通交流，在于将客户，产品，开发等相关参与人员都拉到一起，统一意见的一个过程。但是这个过程是直接开会就可以解决的吗？显然不是。如果我们之前对需求没有一个深入的思考，那再开多少次会都是无意义的。如何对需求有更深入的思考？我认为按照流程化过程模型写各个阶段的文档进行深入思考、总结思路我认为是必要的功课。所以虽然敏捷开发注重交流，但不意味着就可以直接代替流程化中的需求文档、概要设计、详细设计等内容。

第二点敏捷模型更注重开发中的迭代过程，以迭代适应当今需求多变，要求响应更即时的互联网环境。互联网时代必须遵从迭代特征毋庸置疑，跟上时代脚步也是公司生存的保障。但是，我的心之所向是暴雪，它能开发出魔兽世界这样跨时代的经典作品；我的梦中情人是任天堂，它出品的游戏玩法多样性令人叹为观止。事实上，这些经典都是花了3-5年的大制作；在诸如当下很火的电影般的电视剧《繁花》，也是经历了长时间的打磨而产生的作品。所以，迭代方法虽好，但它不是追求，不能圆梦。

第三点敏捷模型更强调以人为本，激发人的主观能动性。我把它理解为它是一个组建优秀开发团队的一个过程。在这个团队中，我们以开发出优秀软件为目的，而不是以完成某个活动的工作职责为目的；我们以更短实现开发目标为目的，所以减去了过程模型中的阶段性里程碑和审查，因为这些对于软件的实现是没有意义的。敏捷团队有角色，但不局限于角色职责，每个人都需要对整个的开发过程负责，而不是对自己的角色职责负责。而这些基于团队中成员的良好沟通和信任。实现敏捷模型本身也是一个不断迭代进化的模型，所以需要团队中的成员有更好的学习力和适应性。所以敏捷模型实际上对团队中的开发人员要求更高，高质量的团队实现高质量的开发，在高质量的基础上再实现快速开发，我认为这是敏捷模型所要表示“以人为本”的内容。

四. 如何利用软件过程模型?

一般情况下，任何一家公司的软件开发流程都会遵从软件开发过程模型中的定义。比如用户需求来了，首先我们要分析这个需求，然后开会讨论这个需求怎么做，接着需要写需求文档，需求概要设计，需求详细设计等，再进行一轮讨论，确认方案无误后开始编写代码；代码写完后进行测试，测试没问题了再进行项目的部署和发布。

图3.1 软件开发流程管理

在一个软件开发过程中，会有多个角色参与其中，并完成各自职责的工作。初入行业的我们一般情况下也会直接被定义为软件开发者、产品经理、产品测试、产品运维等角色，去完成软件开发过程中的具体活动。所以一开始入行我们接触到的软件开发过程往往是被动的，片面的，是受所属公司影响的。

而工作单位作为我们人生中一个重要的平台，它会影响我们，但不能限制我们。当我们进行软件过程模型的学习后，我们可以先观察和思考自己公司目前采用的软件开发过程都包含哪些元素，再大体判断出目前公司的现状。它是一个较为松散的管理模式，还是一个较为严谨的管理模式；它是分工明确的，还是职责模糊的；公司在流程管理上是变化的，还是一直保持不变的。

后续还可以再加入角色的判断，比如目前作为程序员的我都负责哪些活动，产品经理都负责开发过程中的哪些活动，我的领导又负责了哪些活动。通过不断地学习、观察和总结，我们就可以对我们的工作单位进行一个定位，从而可以简单判断出自己在这家公司的晋升空间（个人职业规划与公司预设角色的匹配度）；以及从现有的软件开发制度预估一下公司的发展前景。（我认为一个集体好的制度是导致成功的必然因素。）

如果您是一位公司领导者，有着决定公司软件开发流程的权力。那么学习完软件过程模型后，您就可以对现有公司的软件开发过程做一个总结和更迭。大公司往往流程多而复杂，人员角色职责明确，如果您发现现有的流程已经够全面了，或者改起来影响深远，我觉得也可以尝试一下邓小平提出的“一国两制”的思想。总体团队继续遵从现有的公司规程，而选择一部分人员勇敢尝试敏捷模型，尝试敏捷模型的人员必须是有着多年经验的，而且是热爱改变的。也须有些人抛开了繁琐过程的制约，就会变得更加积极主动，可以发挥其更高的价值。

小公司分两种，一种是大公司会有多个分公司，例如外包公司模式。这种模式的公司团队开发流程往往也是遵从统一规范的，或者是遵从甲方规范的。在我看来作为外包团队如果把自己的开发过程定义的更加严格一点，会更有利于和客户的交流和沟通，后续也不会因为流程上的不严谨而造成双方的矛盾。利用过程化模型定义一个严谨的开发过程，给客户一个严谨办公的印象，我认为也是外包模式一个很好的营销手段。

还有一种就是创业或者发展平稳的小公司，公司的开发团队可能20-50人左右，如果您的团队成员普遍开发工龄不高，我建议还是使用面向过程模型，严格定义公司的开发流程，这样有助于团队朝着更加严谨的方向发展。而如果您的团队成员是由一群热爱编程的大佬组成的，我想您的团队已经不需要软件开发过程的制约了，无论是面向对象模型还是敏捷模型，方法论只是学习参考的一部分，最终我们也会定义更加适合团队，更加适合自己的软件开发过程。