所有的软件开发，不管是 Python 还是其他，在一定的复杂度之上，都遵循可重复的模式，或者有一个生命周期。一个软件（或系统****开发生命周期（SDLC）可以用作其自己独特的开发方法，提供一组适用于开发过程的任务和活动。也就是说，即使没有围绕 SDLC 的正式流程，通过 SDLC 进行的任何或所有活动仍然可能发生，并且从 SDLC 中产生的任何或所有工件可能在项目开发期间可用。
从实际开发的角度来看，并非所有由 SDLC 产生的工件，无论是正式的还是其他的，都可能非常有用，尤其是那些来自生命周期过程的前几个阶段的工件。即便如此，在开发过程中获得的知识越多，开发工作越不可能朝着与系统长期意图相反的方向发展。
为了充分探索 SDLC 可能提供的功能，我们将使用互联网上可以找到的更详细的功能之一。它将生命周期分为十个阶段，将按以下顺序执行，禁止开发方法中的流程变更：
-
初步概念/构想
-
概念发展
-
项目管理规划
-
需求分析和定义
-
系统架构与设计
-
开发（编写代码）和质量保证
-
系统集成、测试和验收
-
实施/安装/分发
-
操作/使用和维护
-
退役
Many of these individual phases can be merged together, or might be broken out into smaller sub-phases, but this breakdown—these ten phases—is a useful grouping of similar activities with similar scopes.
前三个阶段可能都发生在编写任何代码之前，定义高级概念和目标，并规划如何实现这些目标。后三种情况通常发生在代码完成之后，尽管随着新特性的出现或 bug 的出现，代码开发可能会重新启动以解决这些问题。第 4 阶段到第 7 阶段的余额在开发过程中大致可分为d****，不过，除了第 6 阶段中实际编写的代码外，该分类可能取决于正在使用的开发过程或方法，如果外部政策或力量尚未决定，则可能在第 3 阶段决定的事项。
**Different software development methodologies (Agile ones in particular) may well address these in more of an on-demand manner, grouping phase activities iteration by iteration, story by story, or out of the sequence they are listed in here. A deeper exploration of these variations can be found in Chapter 4, Methodologies, Paradigms, and Practices.
在编写第一行代码之前，可能会有相当多的想法和工作投入到项目中。在开发开始时，并非所有的工作都是可见的，而且，现实地说，在许多情况下，并非所有在开发前可以产生的工作都是可见的。即使是创建的那些工件也可能没有任何正式的结构或文档，或者可能没有期望的那么完整或详细。尽管如此，了解在开发过程中有用或感兴趣的可用内容至少有助于回答在实际编写系统/项目的代码部分时可能出现的问题。
项目或系统生命周期中发生的第一件事就是它的概念。在幕后，这通常涉及到对一些未满足的需求的认识，或是对一些没有按应有方式工作的需求的认识，尽管也可能发生其他变化。作为实现的一部分，通常会有一组构思系统将提供的功能、将推动系统开发的好处或功能，并确定开发何时完成。在这个初始的、非常高层次的概述中，可能没有太多的细节，我们需要一种更好的方法来管理库存，例如，对于整个愿景，但也可能会有更多细节进入画面。
这一概念和好处可能来自于任何与系统有利害关系的人：寻找更好的做事方式的业务人员，可能认识到现有系统不如它可能有效的开发人员，或者可能认识到它很难维护的开发人员。系统管理员可能担心就地系统的管理有多容易，并希望采用更新、更好的方法，或者最初的设想可能是全新的，至少在业务环境中，我们需要一种跟踪整个运货卡车车队燃油效率的方法。如果我们的客户可以在线订购我们的产品呢？
希望，如果有现成的解决方案或产品可以满足这些需求的一部分，那么这些选项将被详细研究，甚至可以让 vision 所有者能够指出这些产品的某些功能集并说：“我们想要这样的东西。”在开发前的设计和开发过程中，拥有接近实际需要的功能示例可以大大节省时间，而且几乎总是值得询问，在设计和开发过程中是否有需要的示例。如果进行了这类调查，但没有发现任何接近的选项，那么，其中也包含有用的信息，缺少了什么？产品 X 做了哪些不符合概念需求的工作？如果没有进行调查，或者调查没有结果，那么最初的概念很可能只不过是一两句话。不过，这没关系，因为随着概念开发的进行，更多细节将在稍后提取。
The "no investigation was undertaken" scenario, in the author's experience, happens more frequently than might be expected, particularly in businesses that are heavily invested in the development of their own products, or where there is a desire to own all the code.
在更正式的流程中，也可能会进行其他分析，查找以下内容：
- 特定用户需求：用户在系统中必须能够做什么，可能他们应该能够做什么。也可能有一系列用户希望能够实现的功能，但这不是功能上的需要。
- 特定功能需求：系统需要解决或至少以显著方式缓解的问题。
- 风险：通常与业务流程相关的风险，但这些风险也可能用于指导后期的设计和开发。
- 成本：资金和资源两方面。从开发过程的角度来看，这些信息可能不会产生太多的用途，但偶尔也会产生大量的信息。
- 操作可行性：检查概念系统在多大程度上满足了其所考虑的需求。与成本分析一样，很可能不会有太多直接用于开发目的的结果，但它可能会确定对可行性存在疑问的操作或设计领域，而这些疑问反过来可能会在系统开发时影响设计和/或实施。
在最好的情况下，如果有正式的流程，或者在非正式流程中对细节给予足够的关注，那么最初的概念可能会产生关于以下方面的信息或文档：
-
系统预期的好处或功能（通常是高水平的，至少从一开始）：
- 特定的高级功能需求集合
- 特定用户需求的集合
-
现成系统未提供的特定特性或功能（从而证明定制开发工作的合理性）
-
要缓解的特定风险
-
需要解决的具体功能或可行性问题
一旦开发正在进行，所有这些都至少有一些价值，并有望进入设计或需求，然后进入开发。
概念开发主要涉及充实最初概念中的一些高级细节，为生命周期后期的工作提供细节和方向。这一步骤的一个更重要的方面是生成各种系统建模工件，这些工作涉及的内容足够多，将在单独的一章中介绍。这个阶段产生的开发相关信息的平衡可能更多地集中在结合业务流程和系统功能上，并围绕系统目标提供一些细节。这里还可以定义至少一个基本的用户体验和/或用户界面，特别是当它们连接到流程/功能时。
定义嵌入到系统中的业务流程至少包括识别系统跟踪的业务对象、可以针对这些对象采取的操作以及这些操作的结果。应用第 1 章编程与软件工程中所述的提问，如果需要更多细节，可以获得相当多的信息。
This same system concept will be revisited in Chapter 3, System Modeling, to illustrate how fleshing out the high-level technical design aspects of a system might progress.
举个例子，考虑一个系统，其概念始于知识，他们需要一种方法来跟踪他们的送货卡车车队的燃料效率。从中确定业务对象和活动可以回答一些非常基本的问题，例如：
-
系统跟踪的是什么？：车队中的单个卡车，这些卡车不定期里程计上的里程，以及这些卡车的加油，至少。
-
加油是什么样子的？：加油时的燃油量和里程表读数。这两个数据点将允许计算燃油效率，这是以每种使用的任何单位（燃油为加仑或升，里程表为英里或公里）计算的。燃油效率成为对任何给定卡车的任何给定加油的计算，并且任何给定卡车的当前里程表读数可以从其上次加油时的里程表读数中检索。
-
对于给定的卡车，应保留多少次加油？：如果系统的目标之一是检测卡车的燃油效率何时下降，以便标记其进行维护，或者触发对与其相关的交付计划的审查，那么显然需要跟踪多个此类加油，可能所有加油。
-
谁将使用该系统，如何使用，在哪里使用？：至少需要两种类型的物理接入点：一种来自移动设备（为卡车加油时），另一种来自办公室计算机（如果没有其他用途，则用于报告）。这组用例告诉我们，我们正在研究一个 web 应用程序，或者某种专用的电话和计算机应用程序集，可以通过服务层访问一些公共数据存储。
可能还有其他问题可以问，但仅这四个问题就可能提供足够的信息来充分利用主要的概念设计决策，尽管后者可能需要更多的探索才能最终确定。类似的提问，询问（特定类型的用户）在没有更多用户和活动之前可以对系统做什么，也可以产生更具体的系统目标：
-
各用户可以记录加油情况，提供当前里程表读数和涉及的燃油量：
- 送货司机（在当地加油站）
- 车队维护人员（在总办公室，有公司加油站）
-
当卡车的计算燃油效率下降到低于其平均值的 90%时，车队维护人员将收到警报，以便安排卡车进行检查
-
当卡车计算出的燃油效率下降到低于其平均值的 90%时，办公室工作人员也会收到警报，以便检查卡车的送货轮
用户将如何以及在何处与系统交互的问题可能会引发一些关于用户体验和界面设计的讨论和设计决策。在这种情况下，可能在讨论系统是 web 应用程序还是专用电话和桌面应用程序后，决定将其作为 web 应用程序，并将Clarity Design system用于 UI，因为系统愿景中的主要利益相关者喜欢它处理屏幕卡的方式：
生命周期的这一阶段是所有概念性项目汇集在一起的阶段，希望以一种形式或方式，为开始实际的代码创建做好准备。因此，如果有正式的 PMP 文件，其大纲可能如下所示：
-
商业目的
-
目标
-
目标
-
包括什么
-
什么被排除在外
-
关键假设
-
项目组织：
- 角色和责任
- 利益相关者
- 表达
-
风险、问题和依赖性
-
交付物的初步时间表
-
变革管理
-
风险和问题管理
开发人员不需要所有这些项目，但知道在哪里查找他们需要的各种信息（或者，在某些情况下，联系谁获取信息）是有利的，因此：
理想情况下，业务目的、目标和目标部分应收集所有原始视觉信息（从最初的概念/视觉阶段开始），以及在概念设计完成后添加或更改的任何细节。这些很可能包括在生命周期的特定开发阶段进行的需求分析和定义工作的起点。此外，中包含的、中排除的和关键假设部分，在它们之间，应该揭示实际的开发范围，以及提供高级设计决策和任何相关的高级系统建模信息。风险、问题、和依赖关系可能会提供有助于形成开发工作的特定关注事项或其他利益。最后，变更管理将在系统发生变更时，为预期或计划的流程设定期望（至少是高水平的期望）。
在角色和责任和/或利益相关者部分中，可能会列出能够回答纯开发范围之外的有关系统实施的问题或做出决策的人员，尽管在沟通部分中可能有提出这些问题的特定既定流程。
即使没有关于项目管理期望的正式文档，前面提到的许多信息仍然应该让开发人员知道。毕竟，花在追踪谁能回答问题上的时间越少，花在实际编写代码上的时间就越多。
由于敏捷方法的出现，以及其中许多方法的广泛采用，SDLC 的特定开发阶段的具体形式可能会有很大的不同。不同的方法论会对优先顺序或重点做出不同的决定，而这些差异反过来会产生显著不同的过程和工件，以实现直接关注开发人员需求和活动的正式 SDLC 阶段的目标。整本书都是关于几个敏捷过程的，因此对它们的完整讨论远远超出了本书的范围，但所有这些都涉及以下活动。
需求分析和定义涉及发现和详细说明系统的特定需求，系统需要什么来允许用户使用它。用户显然包括最终用户，从使用该系统进行日常业务的办公室工作人员到外部最终用户（如客户）。不太明显的是，用户还应该包括系统管理员、通过某些报告流程从系统接收数据的工作人员，以及可能以任何方式与系统交互的任何数量的其他人，或者由系统执行操作的其他人，包括开发人员自己。
Requirements are, first and foremost, about those interactions, and developers have to know what is expected of the system in order to write code to provide those capabilities.
如果需求分析和定义是关于系统提供什么，那么系统架构和设计主要是关于这些功能如何工作。不同的开发方法如何处理体系结构和设计的差异与其说是如何处理的，不如说是何时定义的。本质上，给定一组需求（系统背后的意图或原因），实现细节（如何）几乎肯定更多地取决于这些需求以及如何以编程语言最好地实现它们的细节，而不是取决于它们何时被识别、合并或形式化。
Developers need to know how best to implement the required functionality, and that is what this phase is concerned with.
这个阶段的开发部分可能需要最少的解释：当实际代码被编写时，使用定义的需求来确定代码的目标是什么，架构/设计来确定如何编写代码。可能会有人提出这样一种观点，即该阶段的质量保证部分应该划分为自己的分组，如果只是因为所涉及的许多活动本质上是不同的，那么在执行手动测试计划的过程中，代码编写（如果有的话）会更少。这就是说，自动化测试的概念可能会取代许多旧式的手动测试计划执行活动，至少在一开始，它确实需要大量的代码。一旦建立了这些测试套件，回归测试就变得更简单、更省时。开发方法学对该阶段 QA 方面的关注通常集中在 QA 活动发生时，而这些活动的实际期望通常是开发标准和最佳实践的组合。
Developers need to know what quality assurance efforts are expected of them, and plan (and perhaps write code) accordingly during development. Automated testing is also a critical foundation for increasingly popular Continuous Integration (CI) and Continuous Delivery/Deployment (CD) practices.
如果一个系统超过了一定的规模或复杂程度，那么开发工作中产生的新代码必须被整合到更大的系统环境中只是时间问题。可能还需要注意与其他系统的交互，以及在这些场景中提出的任何影响。在较小、不太复杂的系统中，这种集成可能在开发过程中实现。
在任何一种情况下，都需要测试新（或修改）功能的集成，以确保它没有破坏本地系统和与之交互的任何其他系统中的任何东西。
Developers need to know how and where their code fits into the larger system, and thus how to integrate it. As with the Quality Assurance portion of the previous phase, developers also need to know what testing efforts are expected of them, for much the same reasons.
在编写系统核心代码之后发生的 SDLC 部分仍然会对开发周期产生重大影响。从历史上看，它们可能不涉及大量的实际开发工作。例如，有些代码可能是一次性编写的，用于各种特定目的，如打包系统代码，或促进在目标环境上的安装。如果系统的代码库结构或系统编写语言（很少）没有以某种方式阻止它，那么为支持后期开发活动而编写的大多数代码可能会在开发过程的早期创建，以满足其他一些需要。
作为一个例子，打包代码库和/或创建一些安装机制很可能是在第一次需要将代码库安装到用户验收测试环境中时进行的。如果这一期望提前知道并且应该知道，那么在某种程度上，编写打包过程以编写安装程序的工作很可能在创建任何真正的代码之前就开始了。在这一点之后，进一步的工作通常很少发生，因为需要将新组件添加到包结构中，或者需要对安装过程进行更改。该级别的更改通常很小，并且随着流程的成熟和代码库的安装，通常需要的更改频率越来越低。这种流程演进至少是 DevOps 和一些连续交付实践的起点。
Developers will need to know how the system is supposed to be distributed and installed so that they can plan around those needs, writing code to facilitate them as required.
SDLC 的最后两个阶段涉及系统的日常使用及其最终退役，总体而言与核心开发过程的相关性较小。最可能的例外情况是重新进入开发周期阶段，以处理 bug 或添加新的特性或功能（在操作/使用和维护阶段的使用和维护部分）。
从系统管理员（负责执行这些阶段的活动的人员）的角度来看，开发人员是他们所需要的知识和过程的贡献者，其方式与系统开发的所有开发前贡献者都是关于开发人员知识和过程的。系统管理和维护人员将寻找并使用开发过程中产生的各种工件，以便能够执行与系统相关的日常工作。这些工件很有可能主要是知识，以文档的形式出现，也许是偶尔的系统管理工具。
Developers will need to know what kind of information is needed for post-development activities in order to be able to provide the relevant documentation or to write code to facilitate common or expected tasks.
最后，关于系统退役的过程，使其离线，可能永远不会被再次使用：可能处于业务决策级别的人必须围绕需要发生的事情提供指导，甚至正式的业务政策和程序。至少，这些可能包括以下内容
- 保存和归档系统数据的要求（如果是敏感数据，则应如何处置）
- 通知用户系统退役的要求
可能会有更多，甚至更多，它在结构和功能上都非常依赖于系统本身，以及可能应用的任何业务策略。
Developers will need to know what should happen when the system is finally shut down for good so that they can plan and document accordingly. Knowing how things will be handled during a complete and permanent shutdown may give significant insight into how system processes and data can or should be handled when normal data deletion is executed during normal system operation.
即使并没有正式的 SDLC，从一个 SDLC 中产生的大量信息仍然有利于开发人员访问。如果有足够的信息可用，并且信息足够详细、易于访问，而且最重要的是准确，那么它肯定可以帮助区分一个正在编程的项目和一个设计良好的软件。
造成这种差异的另一个重要因素是，在几个系统模型工件中的任何一个或所有工件中，都可以获得关于系统本身的类似信息。这些提供了更多面向实现的细节，这些细节至少应该与来自各种 SDLC 工件的策略和过程级信息一样有用。下面我们来看看。**