10.2：系统开发生命周期 (SDLC) 模型
- Page ID
- 172355
系统开发生命周期 (SDLC) 模型
SDLC 最初开发于 20 世纪 60 年代，用于管理与在大型机上运行的公司系统相关的大型项目。 这是一个非常结构化的流程，旨在管理需要许多人的努力才能管理大型项目，包括技术、业务和支持专业人员。 这些项目的建设成本通常很高，而且对组织有很大的影响。 对于组织而言，失败的项目或错误的业务决策选择错误的项目可能是一场商业或财务灾难。
SDLC 是一个模型，定义了规划、分析、设计、实施、维护等一系列阶段的流程。 第 1 章讨论信息系统 (IS) 包括硬件、软件、数据库、网络、流程和人员。 SDLC 经常用于管理 IS 项目，该项目可能包含 IS 的一个、部分或全部元素。 让我们逐一看看 SDLC 的五个阶段中的每一个阶段，如图 10.1 所示：
- 规划。 在这个阶段，请求是由作为这个想法的赞助者发起的。 组建了一个小组，对请求的实质和可行性进行初步评估。 这个阶段的目标是：
- 确定请求如何符合公司的战略或业务目标。
- 进行可行性分析，包括对技术可行性的分析（有可能创建这个吗？） ，经济可行性（我们能负担得起吗？） ，以及法律上的可行性（我们可以这样做吗？）。
- 要推荐可行/不行，请接受该请求。 如果可以的话，还会制定一份概念提案供管理层批准。
- 分析。 概念提案获得批准后，将由新的项目团队（包括前一个阶段）正式确定项目。 项目成员以概念提案为起点，与不同的利益相关者团体合作，确定新系统的具体要求。 此步骤未完成任何编程或开发。 这个阶段的目标是：
- 确定并访谈关键利益相关者。
- 记录关键程序
- 制定数据要求
- 作为此阶段的结果，生成系统需求文档。 这包含了开始系统设计的细节。
- 设计。 系统要求获得批准后，可以对团队进行重新配置以引入更多成员。 此阶段旨在让项目团队获取在前一阶段创建的系统需求文档，并制定系统所需的具体技术细节。 目标是：
- 将业务需求转化为特定的技术需求
- 设计用户界面、数据库、数据输入和输出以及报告
- 在此阶段结束后，生成系统设计文档。 本文档将包含程序员创建系统所需的一切。
- 实施。 一旦系统设计获得批准，软件代码终于可以在编程阶段编写，其他元素（例如硬件）的开发工作也随之发生。 目的是创建一个初始工作系统。 目标是：
- 开发软件代码和其他 IS 组件。 使用系统设计文档作为指南，开发人员开始编写或开发所有 IS 项目组件。
- 通过一系列结构化测试测试工作系统，例如：
- 第一个是单元测试，它测试代码的各个部分是否存在错误或错误。
- 接下来是系统测试，在此测试中，对系统的不同组件进行测试，以确保它们可以正常协同工作。
- 最后，用户接受度测试允许将要使用该软件的用户测试系统，以确保系统符合他们的标准。
- 再次反复测试所有修复程序，以解决测试期间发现的任何错误、错误或问题。
- 对用户进行培训
- 提供文档
- 执行从任何先前系统到新系统的必要转换。
- 因此，生成符合分析阶段提出的要求的初始工作系统和设计阶段制定的设计。
- 维护。 此阶段将在实施阶段完成后开始。 在此阶段，系统必须建立结构化支持流程，以便：
- 报告错误
- 部署错误修复
- 接受对新功能的请求
- 评估已报告的错误或要求实现的功能的优先级
- 确定可预测的定期时间表，以发布系统更新和执行备份。
- 处置数据和其他不再需要的东西
组织可以合并或细分这些阶段以满足其需求。 例如，组织可以选择两个阶段，而不是一个阶段（规划）：启动、概念；或者将实施分为两个阶段：实施和测试。
瀑布模型
一个基于 SDLC 的特定模型是 Waterfall 模型，人们通常认为该名称与 SDLC 相同。 它用于管理软件项目，如图 10.2 所示，分为五个阶段：需求、设计、实施、验证和维护。 该模型强调，必须先完成每个阶段，然后才能开始下一个阶段（因此被命名为瀑布）。 例如，一旦实施阶段开始，就不允许对要求进行更改，或者必须寻求变更流程的变更并获得批准。 他们可能要求项目从需求阶段重新开始，因为新的要求需要获得批准，这可能会导致在实施阶段开始之前对设计进行修改。
瀑布模型的刚性结构因相当僵化而受到批评，导致团队规避风险，避免回到以前的阶段。 但是，这种结构也有好处。 SDLC 和 Waterfall 的一些优缺点是：
SDLC 和瀑布的优缺点
|
优点 |
缺点 |
|
控制和跟踪变更以最大限度地减少风险数量的强大流程可能会在不知不觉中使项目脱轨。 |
花时间记录所有内容，这会导致额外的成本和时间表的时间。 |
|
标准和透明的流程有助于管理大型团队。 |
花在出席会议、寻求批准等上的时间过多，这会增加日程安排的成本和时间。 |
|
文档减少了人员流失的风险，更容易为项目添加人员。 |
有些成员不喜欢花时间写作，这会导致完成项目需要额外的时间。 |
|
每当发现错误时，即使在项目完成之后，也可以更轻松地将系统中的问题追溯到其根源。 |
很难纳入变更或客户的反馈，因为项目必须回到之前的一个或多个阶段，这会导致团队规避风险。 |
随着时间的推移，还开发了其他模型来解决这些批评。 我们将讨论另外两种模型：快速应用程序开发和敏捷，它们是 SDLC 的不同方法。
快速应用程序开发 (RAD)
快速应用程序开发 (RAD) 是一种软件开发（或系统开发）方法，它较少关注持续规划和纳入变更。 RAD 专注于快速构建软件或系统的工作模型，获取用户的反馈以及更新工作模型。 经过几次迭代的开发，最终版本得以开发和实现。 让我们来看看 RAD 模型中的四个阶段，如图 10.3 所示。
- 需求规划。 此阶段与 SDLC 的规划、分析和设计阶段类似。
- 用户设计。 在此阶段，用户代表与系统分析师、设计人员和程序员合作，以交互方式创建系统设计。 与所有这些不同的利益相关者合作的一种技巧是联合应用程序开发 (JAD) 会议。 JAD 会议让所有从不同角度与系统交互的相关用户、包括开发人员在内的其他主要利益相关者就系统的设计进行结构化讨论。 目标是让用户理解和采用工作模式，让开发人员从用户的角度理解系统需要如何运作，以提供积极的用户体验。
- 施工。 在施工阶段，任务与 SDLC 的实施阶段类似。 开发人员继续与用户互动合作，在他们与正在开发的工作模型进行互动时采纳他们的反馈。 这是一个交互式过程，可以在开发人员开发程序时进行更改。 此步骤将以迭代方式与 “用户设计” 步骤并行执行，直到开发出可接受的产品版本。
- 切换。 此步骤与某些 SDLC 实施阶段的任务类似。 系统上线或已完全部署。 从以前的状态转变为使用新系统所需的所有步骤都在此处完成。
与 SDLC 或 Waterfall 模型相比，RAD 方法的压缩程度要高得多。 许多 SDLC 步骤是组合在一起的，重点是用户参与和迭代。 这种方法更适合小型项目，还具有使用户能够在整个过程中提供反馈的额外优势。 SDLC 需要更多的文档和对细节的关注，非常适合大型资源密集型项目。 RAD 更适合资源密集度较低且需要快速开发的项目。 以下是 RAD 的一些优缺点：
RAD 的优缺点
|
优点 |
缺点 |
|
通过与用户互动的频率提高质量 |
用户看不到的功能（例如安全性）实施不力的风险 |
|
降低用户拒绝接受成品的风险 |
由于工作版本可以快速解决用户的问题，因此无法控制系统更改。 |
|
在用户实时更新时，提高按时、按预算完成的机会，避免在开发过程中出现意外。 |
由于对系统进行了更改，因此缺乏设计可能会在不知不觉中影响系统的其他部分。 |
|
增加开发者/专家和用户之间的互动时间 |
由于开发人员被束缚，资源稀缺，这可能会减慢其他项目的速度。 |
|
最适合中小型项目团队 |
很难扩大到大型团队 |
敏捷开发方法
敏捷方法是一组利用渐进式变化的方法，这些方法侧重于质量和对细节的关注。 每个增量都会在指定的时间段（称为时间框）内发布，从而创建具有特定目标的常规发布时间表。 尽管它们被认为是与 RAD 分开的方法，但它们具有一些相同的原则：迭代开发、用户交互和可变性。 敏捷方法基于 2001 年首次发布的 “敏捷宣言”。
敏捷方法的特点包括：
- 小型跨职能团队，包括开发团队成员和用户；
- 每日状态会议，讨论项目的当前状态；
- 每次完成的变更都要在短时间内递增（从几天增加到一周或两周）；以及
- 在每次迭代结束时，将完成一个工作项目，向利益相关者演示。
从本质上讲，敏捷方法更重视促进互动、建立频繁工作版本、客户/用户协作、快速响应变化、减少对流程和文档的重视的任务。 敏捷方法论的目标是提供迭代方法的灵活性，同时确保高质量的产品。
有各种各样的模型是使用敏捷方法构建的。 其中一个例子是 Scrum 开发模型。
Scrum 开发模型
此模型适用于在固定时间交互（例如两到四周）内努力制作一系列功能的小型团队，称为 sprint。 让我们来看看 Scrum 模型的四个关键元素，如图 10.4 所示。
图 10.4。 Scrum 项目管理方法。 Lakeworks 的图片已获得 CC BY-SA 4.0
- 产品待办事项。 这是要完成的工作的详细细分清单。 根据风险、依赖关系、关键任务等标准对所有工作进行优先排序。开发人员选择自己的任务并自行组织以完成工作。
- 冲刺待办事项。 这是下一个 Sprint 中要完成的工作的清单。
- Sprint 。 这是一个固定的时间，例如 1 天、2 周或 4 周，由团队商定。 每日进度会议被称为每日 Scrum，通常是 10-15 分钟的简短会议，由 Scrum 大师主持，其职责是为团队消除障碍。
- 软件的工作增量 e. 这是一个工作版本，以递增方式构建，在冲刺结束时会有细分列表。
精益方法论
我们将讨论的最后一种方法是从埃里克·里斯（Eric Reis）的商业畅销书《精益创业》中摘录的一个相对较新的概念。
该方法侧重于采纳初步想法并开发最低可行产品（MVP）。 MVP 是一个运行中的软件应用程序，其功能刚好足以演示项目背后的想法。 MVP 开发完成后，将交给潜在用户审核。 有关 MVP 的反馈以两种形式生成：（1）直接观察和与用户讨论，以及（2）从软件本身收集的使用统计数据。 使用这两种形式的反馈，团队决定他们是应该继续朝着相同的方向前进，还是重新考虑项目的核心思想，改变职能或创建一个新的 MVP。 这种策略的变化被称为支点。 开发了 MVP 的多次迭代，每次都会根据反馈添加新功能，直到最终产品完成。
精益方法与其他方法之间的最大区别在于，当项目启动时，系统的全套要求是未知的。 在项目每次迭代发布时，收集的统计数据和反馈将用于确定需求。 精益方法在企业环境中效果最好，在这种环境中，公司有兴趣确定自己的软件应用程序想法是否值得开发。
参考文献：
敏捷软件开发宣言（2001）。 检索于 2020 年 12 月 10 日，来自 http://agilemanifesto.org/
精益创业公司。 检索于 2020 年 12 月 9 日，来自 http://theleanstartup.com/