【软件工程】游戏开发者应该理解的SDLC（中）

ainatipen · 发表于 2023-3-1 08:51

螺旋模型（Spiral Model）

螺旋模型的介绍

螺旋模型将迭代模型的思想与瀑布模型的系统性，可控性相结合，这种螺旋强调迭代模型的过程阶段与瀑布模型的线性流程相结合，使其能够兼具瀑布模型强大的风险分析能力，与迭代模型的增量式开发能力和快速修改能力。
为什么是一个螺旋呢？我们在上一篇的迭代模型中讲过，迭代模型有一个缺点就是给系统开发人员造成了架构压力。在设计的前期，往往不可知未来的需求。即便是最有经验的开发者，也不得不面临这样的窘境：越到了项目的后期，这种压力越发明显。螺旋模型考虑了这种影响，因此，螺旋越远离原点，这个螺旋就越长，在实际开发中，往往就意味着开发更缓慢。
迭代模型的阶段

螺旋模型可以分为四个阶段，一个软件开发生命中不断重复的进行这几个阶段直到软件完成。在螺旋模型中，一个这样的迭代被称为一个螺旋（Spiral）。

分析与信息收集：在这个阶段，主要工作是收集，创造需求，到了后面的成熟螺旋中，系统需求，子系统需求等也在本阶段提出。
设计：设计阶段包含了对系统架构的思考，模块的实现与编码以及测试，本阶段即为技术人员介入实现的过程。
构建：在本阶段会发布一个带有版本号的测试版本提供给客户，客户进行试用并给出反馈。
评估与风险分析：对构建结果得到的用户反馈进行进一步评估，重新分析风险，反馈于下一阶段的第一阶段。

你应该在何时使用螺旋模型？

螺旋模型在传统的软件行业使用非常广泛，因为产品在发展中成熟，客户和开发都对其中的每一个阶段都很了解，对于双方而言风险都很小。

你的预算很有限，几乎不能承担任何风险，降低风险在你的软件开发中非常重要。
尽管你承担不起风险，然而项目的风险却不小。
长期项目，随着时间推移，项目的经济价值可能发生变化。
客户也不太清楚他们到底想要一个什么样子的软件，他们也需要根据开发反馈修改自己的需求。
需求很复杂，需要反馈来让事情变得明确。
产品需要快速的发行新版本来听取用户反馈。
在产品发展的过程中可能会发生重大需求改变。

螺旋模型与游戏

事实上，游戏开发并不适用螺旋模型，但可能存在局部的螺旋模型。在游戏开发中，我们很少会向用户推行大量的试玩版本，当玩家看到EA测试之后，往往已经是开发的末期了。这样做的原因是，游戏玩家并不像传统软件开发者面向的目标一样经验丰富，很多时候，他们对于开发过程并不熟悉，经常提出不切实际的需求。“玩家群体”并不是一个自然人，过于庞大的群体数量导致玩家群体内部本身都存在有争议的内容等。但是，对于在游戏的后期进行紧锣密鼓的测试阶段是，往往接连不断的alpha测试，beta测试等，却能够让项目短暂的符合螺旋模型的特点。
但并不是所有的游戏都不适用于螺旋模型。例如一些核心粉丝向游戏，这些游戏玩家对于自己想要的非常明确。听取他们在开发中的反馈非常重要。这些粉丝向游戏受众非常狭小，风险较大，因此满足核心粉丝的诉求是这些游戏最基本的目标。
另一方面，一些有技术能力却缺乏资金的独立游戏也适用螺旋模型。因为这些团队缺乏资金，需要支持，并且承受风险能力几乎不存在，因此他们往往会发行大量的版本来维持游戏的热度，代替宣发，或者获取资金。在这种情况下，玩家的反馈必然在整个开发过程中如影随形，开发者也很可能根据玩家的反馈来快速变动需求以规避他们几乎无法承担的商业风险。在这种情况下，盲目使用迭代模型或敏捷模型很可能导致团队失败。同时，独立游戏往往仅有研发团队构成，缺乏立项的市场调研，因此模糊的用户需求可能对他们的开发造成影响，而螺旋模型对需求含糊不清的包容度可以很好的适应这种环境。因此，独立游戏的主程未尝不可把螺旋模型纳入SDLC模型选取的考量范围。
螺旋模型的优点

总体来言，螺旋模型的优点来源于他的核心观念：让客户的反馈与开发过程如影随形。因此，螺旋模型对于客户的需求变化极其灵敏，对市场的嗅觉也是最灵敏的，对于风险的控制能力极强。

对需求的变动容忍度很高。
允许原型的大量使用。
往往需求非常精确。
用户在早期即可介入，可以更快的描述自己的需求。
研发可以分块，高风险高难度的模块可以提前以规避项目后期框架压力造成高难模块开发缓慢。

螺旋模型的缺点

首先，螺旋模型的缺点在于对项目管理开销的进一步上升。但更重要的是，螺旋模型存在一个不能碰的红线，而这个红线却很难定义。简单来说就是，并不是所有的用户反馈都是可以更改的，否则螺旋会陷入无限螺旋，开发团队对于这个红线的把握如果差点儿意思，很容易随波逐流，丧失对项目核心竞争力的把控。最终迷失在冲突的反馈中。

复杂的管理，高昂的管理成本。
很难确定项目到底要花多长时间来完成。
对于那些短期小项目，低风险项目，螺旋模型可能得不偿失。
过程太复杂了。
存在无限螺旋的风险。
大量的中间文件导致对大量文档的需求。

V-模型（V-Model）

V模型的介绍

V模型是一种线性流程模型，它可以被认为是一种证明与验证模型（Verification and Validation model，太难翻译了，有更好翻译的可以留言一下）
V模型是基于将每个阶段的测试联系到一起的一种瀑布模型的拓展，这意味着对于开发中的每一个阶段，都有一个与之对应的测试阶段。与瀑布模型一样，这也是一种高度原则化的模型，只有当前一个阶段结束才会开启下一个阶段。但是，与瀑布模型不同的是，V模型存在局部并行。
V模型的阶段

V模型下存在线性的需求分析与研发设计，测试，但存在与研发并行的测试设计。毕竟测试设计并不需要真的拿到代码。
V模型可以简略的分为三部分：Verification Phases，Coding Phases，Verification Phases。其中的每个小部分都是我们在瀑布模型的老熟人，不再详细介绍。
整个过程图是V型的，再加上他Verification and Validation model的名字，故称V模型。

这张图看起来很复杂，我们可以忽略中间部分，只看V型的左侧（Verification Phases），这是一个线性的过程，需求分析->系统设计->架构设计->模块设计->编码。这一个标准的开发流程，同时，也存在并行的设计，QA人员可以在其他人工作的时候并行的设计概念测试，系统测试，整合测试，单元测试。这样，一旦Coding完成，马上就可以进行单元测试，整合测试（Verification Phases）等。
测试的顺序是栈式的，即后完成的先测试。这是自然原理，整合前自然进行单元测试，自然就呈栈式。并不是一种什么特殊的设计。
你应该在什么时候使用V模型？

V模型的选取与瀑布模型一致——需求在开始前就已经非常明确，因为回退阶段通常是非常昂贵的。这个模型通常在医学领域被选取使用。

有清晰的需求与良好的文档
产品方向稳定
技术非常的固定，不存在有风险的技术
比起瀑布模型，你的QA人员应该更经验丰富，从而在缺乏实际代码的情况下设计抽象测试。
没有模棱两可的，含糊不清的需求。
短期项目

V模型不适合游戏的原因与瀑布模型如出一辙。
V模型的优点

V模型的优点其实与瀑布模型基本一致，看起来很复杂其实因为还是线性的导致管理与实施成本很低，存在局部并行导致速度比瀑布模型更快。

高度原则化，阶段一次完成。
对于小项目和需求简单的项目表现良好。
简单，容易施行。
管理成本低。

V模型的缺点

高风险与不确定性。
对于复杂的项目和OOP项目不合适。
对于长期项目或长期维护项目不合适。
不适合那些需求常常会发生变动的项目。
项目的后期QA阶段设计人员和程序人员参与感低。
一旦项目阶段推进了，很难再回到上一个阶段。

		自动登录	找回密码
密码			立即注册

【软件工程】游戏开发者应该理解的SDLC（中）

本帖子中包含更多资源