软件开发生命周期 (SDLC) 是一个概念模型，用于定义在软件开发过程的每个步骤中执行的任务。虽然 SDLC 有多种模型，但一般 SDLC 包括以下步骤 –
- 初步分析
- 系统分析和需求定义
- 系统设计
- 发展
- 集成和系统测试
- 安装、操作和验收测试
- 维护
- 处理
我们将简要讨论这些步骤，以及如何将风险评估和管理纳入这些步骤，以确保正在开发的软件中的风险更低。
一、初步分析：
在这一步中，您需要了解：
- 组织的目标
- 所研究问题的性质和范围
- 在深入了解问题和竞争对手正在做什么后提出替代解决方案和建议
- 描述成本和收益。
风险管理活动的支持 –
- 建立风险管理流程和职责
- 记录初始已知风险
- 项目经理应优先考虑风险
2、系统分析和需求定义：
这一步对于清楚了解客户的期望和要求非常重要。因此，非常小心地进行此阶段并给予适当的时间是非常重要的，因为任何可能的错误都会导致整个过程的失败。以下是在此阶段执行的一系列步骤：
- 通过文档、客户访谈、观察和问卷获得最终用户要求
- 识别当前系统的优缺点，以避免缺点并在新系统中发扬优点。
- 任何特定的用户建议都用于准备规范，并针对第二步中发现的缺点找到解决方案。
通常，此步骤涉及以下风险管理活动。
风险管理活动的支持 –
- 确定需要保护的资产并在机密性、完整性和可用性方面分配其重要性
- 识别对这些资产的威胁和由此产生的风险
- 确定现有的安全控制措施以降低风险
简而言之，我们可以将这个阶段分为五个子阶段：可行性研究、需求获取、需求分析、需求验证、需求文档。
我们将详细讨论这些阶段以及这些子阶段涉及哪些风险因素。
- 可行性研究——这是第一个也是最重要的阶段。通常，此阶段在大型项目中作为独立阶段进行，而不是作为需求定义阶段下的子阶段进行。此阶段允许团队估计给定项目的主要风险因素成本和时间。您可能想知道为什么这如此重要？可行性研究有助于我们了解是否值得构建该系统。它有助于确定主要风险因素。
风险因素 –
以下是可行性研究阶段的风险因素列表：- 项目经理在估算项目的成本、时间、资源和范围时经常出错。不切实际的预算、时间、资源不足和范围不明确往往会导致项目失败。
- 不切实际的预算：如上所述，不准确的预算估计可能会导致项目在 SDLC 早期耗尽资金。准确的预算预算与对时间、精力和资源的正确认识直接相关。
- 不切实际的时间表：不正确的时间估计导致项目经理为开发人员按时交付项目造成负担。从而影响项目的整体质量，从而使系统更不安全和更容易受到攻击。
- 资源不足：在某些情况下，可用的技术、工具不是最新的，无法满足项目要求，或者可用的资源（人员、工具、技术）不足以完成项目。在任何情况下，项目都会延迟，或者在最坏的情况下可能导致项目失败。
- 项目范围不明确：清楚了解项目应该做什么，哪些功能是重要的，哪些功能是强制性的，哪些功能可以被认为是额外的，这对项目经理来说非常重要。对系统的了解不足可能会导致项目失败。
- 需求获取——从应用领域的分析开始。此阶段需要不同利益相关者的参与，以确保高效、正确和完整地收集系统服务、其性能和约束。然后对该数据集进行审查和阐明，以使其为下一阶段做好准备。
风险因素 –
- 不完整的需求：在 60% 的情况下，用户无法在开始时说明所有需求。因此，需求在整个 SDLC 流程中具有最动态的性质。如果没有涵盖任何用户需求、约束或其他功能/非功能需求，则称该需求集不完整。
- 不准确的需求：如果需求集不能反映真实的用户需求，那么在这种情况下，需求被认为是不准确的。
- 需求不明确：在SDLC的过程中，往往存在用户和开发者之间的沟通鸿沟。这最终会影响需求集。如果分析人员和开发人员无法理解用户陈述的需求，那么这些需求就被认为是不明确的。
- 忽略非功能性需求：有时开发人员和分析师会忽略非功能性需求与功能性需求同等重要的事实。在这种混乱中，他们专注于提供系统应该做什么，而不是系统应该如何像可扩展性、可维护性、可测试性等。
- 冲突的用户需求：系统中的多个用户可能有不同的需求。如果不仔细列出和分析，这可能会导致需求不一致。
- 镀金：在开始时列出所有要求非常重要。在开发过程中后期添加需求可能会导致系统中的威胁。镀金只不过是为系统添加了之前没有考虑过的额外功能。从而招来威胁并使系统易受攻击。
- 对真实操作环境的描述不明确：对真实操作环境的了解不足会导致某些漏洞被遗漏，因此威胁在软件开发生命周期的后期才会被发现。
- 需求分析活动——在这一步中，通过采访用户、头脑风暴或其他方式收集的需求将：首先分析，然后分类和组织，例如功能性和非功能性需求组，然后对这些进行优先级排序，以更好地了解哪些要求是高优先级的，需要明确存在于系统中。在协商所有这些步骤要求之后。
风险因素 –
这一步的风险管理有以下任务要做：- 不可验证的需求：如果一个有限成本有效的过程（如测试、检查等）不可用于检查软件是否满足需求，则该需求被称为不可验证的。
- 不可行的要求：如果没有足够的资源来成功实现该要求，则称其为不可行的要求。
- 不一致的要求：如果一项要求与任何其他要求相矛盾，则称该要求不一致。
- 不可追溯的需求：每个需求都有一个源头是非常重要的。在文档编制过程中，有必要写下每个需求的原始来源，以便将来需要时可以追溯。
- 不切实际的需求：如果一个需求满足上述所有标准，比如它是完整的、准确的、一致的、可追溯的、可验证的等，那么该需求就足够现实，可以记录和实施。
- 需求验证活动——这涉及验证迄今为止收集和分析的需求，以检查它们是否真正定义了用户对系统的需求。
风险因素 –
- 被误解的领域特定术语：开发人员和应用程序专家经常使用领域特定术语，或者我们可以说大多数最终用户无法理解的技术术语。从而在最终用户和开发人员之间造成误解。
- 使用自然语言表达需求：自然语言并不总是表达需求的最佳方式，因为不同的用户可能有不同的符号和约定。因此，建议使用正式语言进行表达和记录。
- 需求文档活动——此步骤涉及通过使用正式语言写下所有商定的需求来创建需求文档（RD）。 RD 作为不同利益相关者之间的沟通手段。
风险因素 –
- 需求数据和RD不一致：有时可能会发生，由于收集和记录过程中的故障，实际需求可能与记录的需求不同。
- 不可修改的RD：如果在RD的准备过程中，不考虑RD的可维护性结构化，那么在修改过程中修改文档就很难不重写。
参考 SDLC 的其他阶段 – 在 SDLC 中集成风险管理 | 2套