📜  在 SDLC 中集成风险管理 |设置 3

📅  最后修改于: 2021-10-21 05:50:59             🧑  作者: Mango

先决条件 – 在 SDLC 中集成风险管理 |第 1 组和第 2 组
在本文中,我们将讨论剩余的四个步骤:集成和系统测试、安装、操作和验收测试、维护和处置。

5. 集成和系统测试:
在这个阶段,首先独立检查所有模块是否有错误、错误。然后将它们与其依赖项相关联,并检查依赖项是否有错误,最后将所有模块集成到一个完整的软件中,并作为一个整体检查错误。

风险管理活动的支持 –
在此阶段测试设计的控件以查看它们是否在集成环境中准确工作。

这个阶段包括三个活动:集成活动、集成测试活动、系统测试活动。我们将详细讨论这些活动以及每项活动中的风险因素。

  1. 整合活动——在这个阶段,各个单元被组合成一个工作系统。
    风险因素 –

    • 组合组件的困难:集成应该逐步完成,否则将很难定位错误和错误。错误的集成顺序最终会妨碍系统设计的功能。
    • 集成错误版本的组件:开发系统涉及编写同一组件的多个版本。如果为集成选择了不正确的组件版本,则可能无法生成所需的功能。
    • 遗漏:组件的集成应谨慎进行。单个遗漏的组件可能会导致错误和错误,这将很难定位。
  2. 集成测试活动 –集成组件后,下一步是测试组件是否正确连接并评估它们的集成。此过程称为集成测试。
    风险因素 –
    • 集成过程中的错误:如果集成了错误版本的组件或不小心遗漏了组件,则会导致最终系统出现错误和错误。
    • 接口数据丢失:错误的集成会导致组件之间的数据丢失,其中调用组件中的参数数量与被调用组件中的参数数量不匹配。
    • 未实现所需的功能:集成过程中引入的错误和错误会导致系统无法生成所需的功能。
    • 定位和修复错误的困难:如果集成不是增量完成,则会导致难以定位的错误和错误。即使找到了错误,也需要修复它们。在一个组件中修复错误可能会在其他组件中引入错误。因此,定位和修复错误变得相当麻烦。
  3. 系统测试活动——在这一步中,对集成系统进行测试,以确保它满足从用户那里收集到的所有系统要求。
    风险因素 –
    • 不合格的测试团队:缺乏优秀的测试团队是一个好的软件的主要挫折,因为测试人员可能会滥用可用的资源和测试工具。
    • 有限的测试资源:时间、预算、工具如果使用不当或不可用可能会延迟项目交付。
    • 无法在真实环境中测试:有时由于缺乏预算、时间限制等原因无法在真实环境中测试系统。
    • 测试无法应对需求变化:在整个软件开发生命周期中,用户需求经常发生变化,因此应设计测试用例来处理此类变化。如果设计不当,他们将无法应对变化。
    • 被测试的系统不够可测试:如果需求是不可验证的,那么在这种情况下,测试这样的系统就变得非常困难。

6. 安装、运行和验收测试:
这是 SDLC 中最后也是最长的阶段。在此系统中交付、安装、部署和测试以供用户接受。

风险管理活动的支持 –
系统所有者将希望确保规定的控制措施,包括任何物理或程序控制措施,在系统上线之前就位。必须在系统运行之前就已识别的风险做出决定。

此阶段涉及三项活动:安装、操作、验收测试。

  1. 安装活动——软件系统在客户现场交付和安装。
    风险因素 –
    • 安装问题:如果部署者经验不足,或者系统复杂且分布式,那么在这种情况下,安装软件系统变得困难。
    • 环境变化:有时安装的软件系统在真实环境中不能正常工作,在某些情况下是由于硬件的进步。
  2. 操作活动:在此对终端用户进行软件系统及其服务的使用培训。
    风险因素

    • 新需求出现:在使用系统时,有时用户会觉得需要添加新需求。
    • 使用系统的困难:作为一个人,一开始总是很难接受一个变化,或者我们可以说接受一个新的系统。但这不应该持续很长时间,否则这将对系统的可接受性构成严重威胁。
  3. 验收测试活动——对交付的系统进行验收测试,以检查其是否满足所有用户要求。
    风险因素 –
    • 用户对变化的抵制:抵制周围环境的任何新变化是人类的行为。但是对于新交付系统的成功,最终用户接受该系统并开始使用它是非常重要的。
    • 太多的软件故障:软件故障应该在系统运行阶段之前发现,因为后期发现导致处理这些故障的成本很高。
    • 数据处理不足:开发新系统时应牢记在实际环境中必须处理的用户数据负载。
    • 缺少要求:在使用系统时,最终用户可能会发现缺少某些要求和功能。

7.维护:
在此阶段,对系统进行评估以确保其不会过时。此阶段还涉及在性能方面对系统进行持续评估,并且不时对初始软件进行更改以使其保持最新状态。

在此阶段修复验收测试期间发现的错误和故障。此步骤涉及改进系统、修复错误、增强服务和升级软件。

风险管理活动的支持 –
对系统的任何更改都有可能降低现有控制的有效性,或者对系统的机密性、可用性或完整性产生一些影响。解决方案是确保在评估系统更改时包含风险评估步骤。

风险因素 –

  • 预算超支:查找错误并修复它们需要再次在 SDLC 中重复几个步骤。从而超出预算。
  • 升级中的问题:来自最终用户的限制或系统架构不够灵活,使其不易维护。

8. 处置:
在此阶段,制定计划以丢弃系统信息、硬件和软件以过渡到新系统。目的是防止因信息处理不当而导致未经授权披露敏感数据的任何可能性。所有这些都应该按照组织的安全要求来完成。

风险管理活动的支持 –
制定的风险管理计划还必须包括对残留数据保密性的威胁、适当的程序和控制措施,以减少因处置不当而导致数据被盗的风险。但是,通过在项目早期识别风险,可以提前记录控制措施以确保正确处置。

风险因素 –

  • 缺乏正确处理的知识:正确处理信息需要有经验的团队,对如何处理剩余数据制定计划。
  • 缺乏适当的程序:有时急于推出新系统,组织将处置任务搁置一旁。用于处理残留数据的程序应适当记录,以便将来使用。