先决条件 – 在 SDLC 中集成风险管理 |设置 1
在本文中，我们将讨论 SDLC 的系统设计和开发阶段。
3. 系统设计：
这是 SDLC 的第二阶段，其中必须建立系统架构，并需要解决所有记录的要求。
在这个阶段，使用屏幕布局、伪代码、业务规则、流程图等详细描述系统（操作和功能）。
风险管理活动的支持 –
- 资产危急程度精准分类
- 准确识别计划控制
它涉及一系列七项活动：
- 检查需求文档——对于开发人员来说，参与检查需求文档以确保需求文档中列出的需求的可理解性非常重要。
风险因素 –
RD 对开发人员来说不清楚：开发人员必须参与需求定义和分析阶段，否则他们将无法很好地理解要开发的系统。他们将无法在充分了解系统需求的情况下开始设计。因此，将为系统创建一个设计而不是预期的设计。 - 选择架构设计方法活动——将系统分解为组件的方法。因此，它是一种定义软件系统组件的方法。有许多架构设计方法，如结构化面向对象、Jackson 系统开发和形式化方法。但是没有标准的建筑设计方法。
风险因素 –
不当的建筑设计方法：如上所述，没有标准的建筑设计方法，可以根据项目的需要选择最合适的方法。但重要的是要极其谨慎地选择方法。如果选择不当，可能会导致系统实施和集成出现问题。即使实施和集成成功，架构设计也可能无法在当前机器上成功运行。编程语言的选择取决于所选的架构模型。 - 选择编程语言活动——选择编程语言应该与架构方法并行。因为编程语言应该与所选择的架构方法兼容。
风险因素 –
不正确的编程语言选择：不正确的编程语言选择可能不支持所选的架构方法。从而可能降低系统的可维护性和可移植性。 - 构建物理模型活动——由符号组成的物理模型是对分层组织系统的简化描述。
风险因素 –
- 复杂系统：如果要开发的系统非常庞大和复杂，那么会给开发人员带来问题。因为开发人员会感到困惑，无法弄清楚从哪里开始以及如何将如此庞大而复杂的系统分解为组件。
- 复杂的设计：对于一个大型复杂系统，可能由于混乱和缺乏足够的技能，开发人员可能会创建一个复杂的设计，这将很难实现。
- 大尺寸组件：如果大尺寸组件可进一步分解为子组件，则可能难以实现，也难以为这些组件分配功能。
- 缺乏可重用性专业知识：缺乏确定可重用组件的适当专业知识对项目构成严重风险。与重用组件相比，从头开始开发组件需要花费大量时间。从而延迟了投影完成。
- 可重用组件较少：分析阶段对可重用组件的错误估计会导致项目面临两个严重风险——一是项目完成延迟，二是预算超支。开发人员会惊讶地发现，被认为已准备就绪的代码所占的百分比需要从头开始重写，最终会导致项目预算超支。
- 验证设计活动——验证设计意味着确保设计是正在建设的系统的正确解决方案，并且满足所有用户要求。
风险因素 –- 验证设计满足需求的困难：有时开发人员很难检查提议的设计是否满足所有用户要求。为了确保设计是系统的正确解决方案，设计必须满足所有要求。
- 许多可行的解决方案：在验证设计时，开发人员可能会针对同一问题遇到许多替代解决方案，因此，选择满足所有要求的最佳设计是困难的。选择取决于系统及其性质。
- 不正确的设计：在验证设计时，提议的设计可能匹配很少的要求或根本不符合要求。它可能是一种完全不同的设计。
- 指定设计活动 –此活动涉及以下主要任务：
- 识别组件并定义它们之间的数据流
- 对于每个已识别的组件，说明其函数、数据输入、数据输出和资源利用率。
风险因素 –
- 组件功能分配困难：在两种情况下，开发人员可能会面临为组件分配功能的困难 – 一是系统没有正确分解，二是需求文档没有做好，在这种情况下，开发人员会发现功能难以识别对于组件作为功能需求构成组件的功能。
- 大量规范：应避免对模块处理进行大量规范，以保持设计文档尽可能小。
- 省略数据处理函数：创建、读取等数据处理函数是组件对数据执行的操作。应避免意外遗漏这些功能。
- 记录设计活动——在此阶段准备设计文件（DD）。这将有助于在实施和其他阶段控制和协调项目。
风险因素 –- 不完整的 DD：设计文档应该足够详细，详细地解释每个组件、子组件、子子组件，以便开发人员可以在不同的模块上独立工作。如果 DD 缺少这个特性，那么程序员就不能独立工作。
- 不一致的 DD：如果相同的函数由多个组件执行。那么在这种情况下，它会导致设计文档中的冗余，并最终导致文档不一致。
- 不明确的 DD：如果设计文档没有明确定义组件并且是用不常见的自然语言编写的，那么在这种情况下，开发人员可能难以理解提议的设计。
- 大型 DD：设计文档应该足够详细，以列出所有组件以及有关功能、输入、输出、所需资源等的完整详细信息。它不应包含不必要的信息。大的设计文档让程序员难以理解。
4. 发展：
此阶段涉及根据开发人员和客户之间商定的要求对软件进行实际编码。
风险管理活动的支持 –
所有设计的控制都在此阶段实施。
这个阶段包括两个步骤：编码和单元测试。
- 编码活动 –此步骤涉及为要开发的系统编写源代码。在此步骤中开发用户界面。然后在单元测试步骤中测试每个开发的模块。
风险因素 –- 不清晰的设计文档：如果设计文档很大且不清晰，程序员将很难理解文档并找出从哪里开始编码。
- 缺乏独立的工作环境：由于设计文档不清晰、不完整，开发团队难以分配独立的模块进行工作。
- 开发了错误的用户界面和用户功能：不完整、不一致和不明确的设计文档导致错误实现的用户界面和功能。糟糕的用户界面降低了客户对系统在真实环境中的接受度。
- 与架构设计不兼容的编程语言：架构方法的选择仅驱动编程语言的选择。它们必须按顺序选择，否则如果不兼容，编程语言可能无法使用所选方法。
- 重复代码：在大型项目中，需要一次又一次地重写同一段代码。这会消耗大量时间并增加代码行数。
- 不同程序员开发的模块：在大型项目中，模块在程序员之间划分。但是不同的程序员有不同的风格和思维方式。这会导致不一致、复杂和模棱两可的代码。
- 单元测试活动——每个模块都被单独测试，以检查它是否满足指定的要求并执行它打算执行的功能。
风险因素 –
- 缺乏完全自动化的测试工具：直到今天，单元测试还没有完全自动化。这使得测试过程枯燥乏味。测试人员不必费心生成所有可能的测试用例。
- 审查者无法理解的代码：在单元测试期间，开发人员需要审查并更改代码。如果代码无法理解，更新代码将非常困难。
- 编码驱动程序和存根：在单元测试期间，模块需要来自其他模块的数据或需要将数据传递给其他模块。因为没有一个模块本身是完全独立的。 Stub 是一段 pf 代码，用于替换接受来自被测试模块的数据的模块。驱动程序是一段代码，用于替换将数据传递给被测试模块的模块。编码驱动程序和存根会消耗大量时间和精力。由于这些将不会与最终系统一起交付，因此这些被视为额外的。
- 测试用例的文档记录不佳：需要正确记录测试用例，以便将来使用。
- 测试团队经验不足：测试团队经验不足，无法处理自动化工具以及为驱动程序和存根编写简短的代码。
- 糟糕的回归测试：回归测试意味着在进行更改时重新运行所有成功的测试用例。这可以节省时间和精力，但如果选择所有测试用例进行重新运行，则可能会很耗时。
其他四个阶段参考——在SDLC中集成风险管理|设置 3