软件开发生命周期（SDLC）是用于定义在软件开发过程的每个步骤中执行的任务的概念模型。虽然SDLC有各种型号，但一般来说SDLC包括以下步骤 -

初步分析

系统分析和需求定义

系统设计

发展

集成和系统测试

安装，操作和验收测试

保养

处置

我们将简要讨论这些步骤，以及如何将风险评估和管理纳入这些步骤，以确保开发软件的风险降低。

1.初步分析：

在这一步中你需要找出：

3.系统设计：

这是SDLC的第二阶段，其中必须建立系统架构，并且需要解决所有需要记录的需求。

在此阶段，使用屏幕布局，伪代码，业务规则，流程图等详细描述系统（操作和功能）。

风险管理活动的支持 -

准确分类资产的重要性

准确识别计划控制

它涉及一系列七项活动：

检查需求文档 -开发人员必须成为检查需求文档的一部分，以确保需求文档中列出的需求的可理解性。

风险因素 -

开发人员不清楚RD：开发人员必须参与需求定义和分析阶段，否则他们将无法很好地理解要开发的系统。他们将无法开始设计对系统要求的充分理解。因此，除了预期的系统之外，还将为系统创建设计。

选择体系结构设计方法活动 -将系统分解为组件的方法。因此，它是一种定义软件系统组件的方法。存在许多用于架构设计的方法，如结构化面向对象，Jackson系统开发和形式化方法。但是没有标准的架构设计方法。

风险因素 -

不正确的建筑设计方法：如上所述，没有标准的建筑设计方法，可以根据项目的需要选择最合适的方法。但重要的是要谨慎选择方法。如果选择不正确，可能会导致系统实施和集成出现问题。即使实现和集成成功，架构设计也许可能无法在当前机器上成功运行。编程语言的选择取决于所选择的架构模型。

选择编程语言活动 -选择编程语言应该与架构方法并行完成。编程语言应该与所选择的架构方法兼容。

风险因素 -

编程语言选择不当：编程语言选择不正确可能不支持所选的架构方法。因此可能降低系统的可维护性和可移植性。

构建物理模型活动 -由符号组成的物理模型是分层有组织系统的简化描述。

风险因素 -

复杂系统：如果要开发的系统非常庞大和复杂，那么它将给开发人员带来问题。因为开发人员会感到困惑，无法从哪里开始，以及如何将这样庞大而复杂的系统分解为组件。

复杂的设计：对于大型复杂系统而言，由于混乱和缺乏足够的技能，开发人员可能会创建一个难以实现的复杂设计。

大尺寸组件：如果大尺寸组件可进一步分解为子组件，则可能难以实现，并且还难以将功能分配给这些组件。

缺乏可重用性专业知识：缺乏适当的专业知识来确定可重复使用的组件会给项目带来严重风险。从重新开发组件开始，与重新使用组件相比，需要花费大量时间。从而延迟投影完成。

较少可重复使用的组件：在分析阶段对可重用组件的错误估计会导致项目的两个严重风险 - 项目完成的第一次延迟，其次是预算超过运行。开发人员会惊讶地发现，被认为已准备好的代码百分比需要从头开始重写，最终会使项目预算过度运行。

验证设计活动 -验证设计意味着确保设计是正在构建的系统的正确解决方案，并且满足所有用户要求。

风险因素 -

验证设计符合要求的困难：有时开发人员很难检查所提议的设计是否满足所有用户要求。为了确保设计是系统的正确解决方案，设计必须满足所有要求。

许多可行的解决方案：在验证设计时，开发人员可能会针对同一问题遇到许多替代解决方案因此，选择满足所有要求的最佳设计是困难的。选择取决于系统及其性质。

设计不正确：在验证设计时，建议的设计可能符合很少的要求或根本没有要求。它可能是完全不同的设计。

指定设计活动 -此活动涉及以下主要任务：

识别组件并定义它们之间的数据流

对于每个识别的组件状态，其功能，数据输入，数据输出和资源利用率。

风险因素 -

向组件分配功能的难度：在两种情况下，开发人员可能在向组件分配功能时遇到困难 - 首先是系统没有正确分解，其次如果需求文档没有正确完成，那么在这种情况下，开发人员会发现很难识别功能对于组件，功能要求构成组件的功能。

广泛的规范：应避免广泛的模块处理规范，以使设计文档尽可能小。

省略数据处理功能：创建，读取等数据处理功能是组件对数据执行的操作。应避免意外遗漏这些功能。

记录设计活动 -在此阶段设计文档（DD）。这将有助于在实施和其他阶段控制和协调项目。

风险因素 -

不完整的DD：设计文档应该足够详细，详细解释每个组件，子组件，子子组件的详细信息，以便开发人员可以在不同的模块上独立工作。如果DD缺乏此功能，那么程序员就无法独立工作。

DD不一致：如果多个组件执行相同的功能。那么在这种情况下，它将导致设计文档中的冗余，并最终导致文档不一致。

不清楚DD：如果设计文档没有明确定义组件并且是用非常见的自然语言编写的，那么在这种情况下，开发人员可能很难理解所提出的设计。

大DD：设计文档应该足够详细，列出所有组件将详细说明功能，输入，输出，所需资源等。它不应包含不必要的信息。大型设计文档将难以让程序员理解。

4.开发：

此阶段涉及根据开发人员和客户之间商定的要求对软件进行实际编码。

风险管理活动的支持 -

所有设计的控制都在此阶段实施。

这个阶段包括两个步骤：编码和单元测试。

编码活动 -此步骤涉及编写要开发的系统的源代码。用户界面在此步骤中开发。然后在单元测试步骤中测试每个开发的模块。

风险因素 -

不清楚的设计文档：如果设计文档很大且不清楚，程序员很难理解文档并找出从哪里开始编码。

缺乏独立的工作环境：由于设计文档不清晰和不完整，开发人员团队很难分配独立的工作模块。

开发了错误的用户界面和用户功能：不完整，不一致和不清晰的设计文档导致错误实现的用户界面和功能。糟糕的用户界面降低了客户之间在真实环境中系统的可接受性。

与架构设计不兼容的编程语言：架构方法的选择仅驱动编程语言的选择。必须按顺序选择它们，否则如果不兼容，编程语言可能无法与所选方法一起使用。

重复代码：在大型项目中，需要一次又一次地重写相同的代码。这会消耗大量时间并且还会增加代码行数。

由不同程序员开发的模块：在大型项目中，模块在程序员之间划分。但不同的程序员有不同的风格和思维方式。这导致了不一致，复杂和模糊的代码。

单元测试活动 - 对每个模块进行单独测试，以检查其是否符合指定的要求，并执行其预期的功能。

风险因素 -

缺乏完全自动化的测试工具：直到今天，单元测试还没有完全自动化。这使得测试过程枯燥乏味。测试人员不打算生成所有可能的测试用例。

审阅者无法理解代码：在单元测试期间，开发人员需要检查并更改代码。如果代码不可理解，则更新代码将非常困难。

编码驱动程序和存根：在单元测试期间，模块需要来自其他模块的数据或需要将数据传递给其他模块。因为没有模块本身是完全独立的。Stub是替换接受来自被测模块的数据的模块的pf代码。驱动程序是替换将数据传递给被测模块的模块的代码段。编码驱动程序和存根会消耗大量的时间和精力。由于这些不会与最终系统一起交付，因此这些被认为是额外的。

测试用例的文档记录不好：需要正确记录测试用例，以便将来可以使用这些测试用例。

测试团队没有经验：测试团队没有足够的经验来处理自动化工具并为驱动程序和存根编写简短的代码。

回归测试不佳：回归测试意味着在进行更改时重新运行所有成功的测试用例。这样可以节省时间和精力，但如果选择重新运行所有测试用例，则可能会非常耗时。