降低与软件相关的商务风险需要系统的视角

本篇文章7148字，读完约18分钟

目前，与软件相关的业务风险是一个非常严重的问题。由于停机，美国公司每年损失265亿美元的收入。这些风险也严重威胁着软件系统的安全性、可靠性、性能效率和可维护性。

对于一般的软件公司来说，管理软件风险需要多个业务部门的合作，其中产品经理或产品负责人应该承担主要责任。

目前，it软件质量联盟(cisq)已经发布了软件质量评估的行业框架。ciso是一个致力于软件开发规模和源代码结构质量测试的国际标准化的it行业领导小组。ciso是由卡内基梅隆大学的对象管理集团(omg)和软件工程研究所(sei)联合建立的。

风险评估可以分为两个层次，组件层次和系统层次，通过这两个层次可以有效地降低风险。市场上有针对这两个级别的强大静态代码分析工具，选择哪一个级别取决于系统在其生命周期中的位置。

软件风险的系统化管理可以将软件架构师和工程师从一些机械化的工作中解救出来，为他们节省宝贵的时间来专注于其他工作和创新，并帮助公司获得更多的商业利益。此外，管理软件风险可以加快公司的发展，降低系统中断或安全漏洞的概率，使公司能够更有效地参与当前和未来的业务竞争。

最近，Cutter Consortium的Peter Kaminski和tomlin coggeshall在Cutter Consortium的“通过软件上下文分析降低业务风险和释放软件潜力”报告中指出，降低单个业务风险很容易，软件相关的业务风险在所有业务风险中所占的比重越来越大。因此，降低软件风险的解决方案已经成为当今业务发展的一部分。目前，用户可以在结合软件资产和开发项目的过程中应用一套工具和方法来管理软件风险。对于数字时代的企业和组织来说，以产业化的方式管理软件风险是非常重要的。它可以帮助解放开发人员的独创性，使他们能够专注于更困难的部分，如构建和交付应用程序，同时确保应用程序在任何时候都不会有风险，并充分利用人类智能和软件智能。

软件风险等于业务风险

软件系统为企业提供了许多好处，但就像任何系统一样，它们很容易受到一些问题的影响，包括明显的软件故障，如中断或入侵，以及难以发现的故障。软件系统的问题直接影响客户满意度、收入、股票价格和员工保留率。事实上，这已经成为美国公司面临的一个主要问题，由于停机，美国公司每年损失265亿美元。

为自己或他人开发软件的公司有责任将与软件系统的交付、操作和维护相关的商业风险降至最低。因为软件系统包含日益膨胀的业务流程模块，并且变得更加复杂，所以降低软件系统中的风险不仅具有挑战性，而且至关重要。

软件组织结构与软件风险

目前，许多it组织的组织结构不利于软件风险的有效管理，那么从组织的角度来看，谁应该负责管理软件风险呢？

首席信息安全官(ciso)负责系统的整体安全，但此人可能不直接参与日常应用程序开发。此外，ciso不需要对三种类型的软件风险负责:可靠性、性能效率和可维护性。

架构师负责建立架构标准，以确定开发人员如何在开发应用程序的过程中降低风险，但是在构建应用程序时，架构师通常不参与开发过程。

因此，开发工作可能会在架构团队不知情的情况下无意中偏离目标架构。

Qa工程师名义上负责产品质量和降低软件风险，但他们缺乏对软件设计方法的洞察力，这使得他们无法测试边界条件和其他盲点。通常，他们甚至没有时间测试所有的功能，测试是他们主要关心的。因此，默认情况下，降低软件风险的责任由开发人员承担。

这对于开发人员控制范围内的风险是有意义的；然而，随着应用程序、新架构和交付速度的不断增长和复杂性，开发人员可能会对整个现代软件系统失去深刻的理解，这已成为大多数公司和组织无法克服的盲点，而这一盲点在一些对业务至关重要的核心应用程序的安全性和可靠性方面尤为突出。

我们的建议是，产品经理或产品负责人应该主要负责管理和降低产品风险，他们可以使用软件上下文分析工具并指派相应的工程团队来解决这个问题。

风险:质量的另一面

在这份报告中，我们旨在提供软件风险的概述——如何理解它以及如何管理它。

首先，我们必须承认，对构建灵活、快速、敏感、安全和可靠的系统感兴趣的it领导者通常从软件质量而不是软件风险的角度谈论这个话题。换句话说，他们倾向于描述积极的结果，而不是避免消极的结果。

对于那些负责软件系统部署的人来说，为了尽可能完美地分析业务风险，更合适的做法是平等对待正面(软件质量)结果和负面(软件风险)结果。

软件风险和软件质量只是同一枚硬币的两面。我们可以使用软件质量分类和改进框架来构建我们的软件风险评审标准。

从最广泛接受的软件质量框架——由cisq发布的自动质量特性测量标准开始，该标准规定软件质量测量应该从两个方面组织，或者对于本报告，应该测量软件风险(见图1)。

图1:测试的两个维度

风险来源:单位级和系统级

软件风险相关知识的一个非常重要的部分是软件风险的声音。单元级风险仅限于一个组件和一种编程语言，这通常是单个程序员的工作问题，而系统级风险分布广泛，涉及系统的大多数组件、多种编程语言和体系结构层(参见图2)。

图2:单元级问题和系统级问题

在单元级别，随着软件组件的开发及其功能需求的变化，开发人员可以引入或修复问题。然而，这种修复是在不考虑系统其余部分的情况下进行的，开发人员不想忽略其他部分，但是他们缺乏对整个系统的理解，所以他们只能更改他们负责的组件。

系统级问题通常是在体系结构级别生成或修复的，并且通常源于整个系统组件，这些组件与外部组件交互，例如软件架构师的设计、产品经理的非功能性需求以及用户和数据库。由于当今系统的规模和复杂性不断增加，开发人员、测试人员或架构师需要软件分析工具的帮助来发现系统问题。

软件风险的类型

标准的第二个维度是类型，我们将软件风险分为四个主要类别。

1.安全问题，如隐私、数据和特权的泄露。显然，这些可能会带来灾难性的后果。常见漏洞枚举是众所周知的安全问题的标准化列表，其中已经包含了1005种安全错误。

2.可靠性问题，如系统停机时间、数据损坏以及系统从中断中恢复的能力。

3.性能问题，当用户有大量的计算需求时，软件系统可能无法及时响应，系统响应时间长，应用的可扩展性变差，影响员工的工作效率和用户满意度。

4.最后，当软件体系结构不完整时，会有可维护性的风险，并且需要很长时间来解决每个问题，导致软件系统无法应对不断变化的市场条件，或者在修改过程中维护成本过高。

运行、构建、转换

在这一部分，让我们用一个镜头来检查软件风险。

大多数公司和企业都有完整的软件系统，公司领导也制定了开发计划以赶上竞争对手。然而，在每个项目生命周期中，软件风险和风险降低工作有很大的不同，因此如何分析各种类型的风险及其发生概率是值得我们研究的。

跑步:建造什么

对于一般系统，大多数软件风险分布在系统级。在这个假设的场景中，项目已经作为一个整体进行了集成和部署，并且几乎所有单元级别的风险都已消除。

此时，仍然需要在测试项目的部署和使用阶段进行安全检查，其中包括常规渗透测试和对已知体系结构的系统安全问题的审查，因为可能已经为旧体系结构开发了一种新类型的攻击。旧系统更安全、不太可能存在安全漏洞的观点已经被证明是错误的。例如，美国联邦机构最近对该系统的研究表明，拥有更多先前遗留系统的联邦机构可能比拥有新系统的联邦机构具有更多的安全漏洞。

必须始终监控可靠性和性能效率；然而，如果他们长期保持稳定的趋势，没有必要不断加强或现代化，他们不需要太多的关注。在上述生命周期模式下，由于法规变化或规范性原因，某些系统仍需要偶尔升级。尽管由于系统时代的变化、对代码库的理解和相应的专业知识的缺乏，升级很困难，但就像构建新系统的工作一样，升级仍然是必要的。

系统的可维护性在系统的整个生命周期中非常重要，甚至包括之前的部署。安全补丁、库和操作系统的升级以及开发人员对系统内容的编译、修改和维护都非常重要。最后，有必要提供一份说明项目一般内容和规模的文件，这有助于用户了解系统内容，以便日后维护。

文档覆盖范围应包括系统的组成、涉及的其他系统和过程、相应测量系统的规模、大小和复杂性、系统中包含的语言、组件的数量、代码行的数量、操作系统和库的使用以及一些文档信息。

如果用户已经为应用程序设计了一个合理的蓝图，那么它可能包含用户在编写文档时所需的所有信息。如果没有，用户可能需要使用工具来扫描他们的应用程序，并生成详细的架构蓝图来准确描述系统。这个蓝图可以帮助用户充分理解描述系统。

构建:理解你正在构建的系统

如果一个公司正在开发一个项目，对于软件风险管理来说，这将是一个极好的机会和挑战。此时，公司领导对如何组合项目有很大影响，他们还需要平衡许多因素，如预算、进度和范围。

当设计、部署和构建项目时，软件风险管理的所有方面都发挥作用:产品管理提供系统需求和客户建议；体系结构和安全性为系统构建一个框架和保护系统，并描述支持项目的通用工程框架；系统开发遵循最佳的开发模式，进行连续的单元和集成测试，而集成和部署使用软件上下文分析来检查整个系统；项目管理和项目发起人与整个团队合作，帮助他们跟进开发过程。

系统级分析通常出现在前台，这使得项目经理、架构师和安全专家能够方便地持续监控系统的当前和未来健康状态。将系统级分析集成到devops管道中，使用软件智能帮助团队提高开发速度和减少返工时间，同时确保他们能够降低最终系统中的软件风险。

为了管理系统的安全风险，开发人员通常需要跟进一些理解体系结构和开发软件工程的实践。应用程序所有者、架构师和安全专家需要一种方法来验证系统符合这些约定和标准，并且系统级分析满足这一要求，并且还可以向开发人员和操作团队提供实时反馈。集成工程师、qa、操作、架构和安全专家可以使用系统级分析来识别安全热点或缺陷，以便在产品发布前进行深入审查。

开发团队需要在单元级别遵循良好的代码规范，以确保系统可靠性和性能效率。然而，这两个指标只有在系统开始集成时才会有实际结果，并且可以由质量工程师通过系统级分析进行压力测试和扫描。这些测试的输出需要及时反馈给团队领导和架构师，以便在最终集成之前改进设计。

如果代码刚刚写完，开发团队还在修改代码，那么系统维护成本将大大降低，系统维护将更加有效。在实际应用中，最好同时使用单元级和系统级分析来提高代码的可读性，记录软件系统采用的方法和体系结构，并减少代码重复。

转型:未来建设的目标

目前，业务形势、市场和技术都在迅速变化，仅仅管理以前或现在遇到的软件风险是远远不够的。为了在未来的挑战中生存并继续发展，所有的公司和组织都需要时刻向前发展。

箭在弦上，必须送出。新技术和增长领域，如物联网、区块链和认知计算，正在不断涌现。这些技术组件将在几年内成为市场的主流，企业用户也将面临来自新市场的激烈竞争压力和时间压力。有必要在这些领域中安顿下来，管理好企业风险。

除了建立软件风险管理框架之外，企业和组织还需要部署重要的人力资源来了解新技术以优化公司的发展战略，并系统地阐明旧技术和新技术是如何协同工作的。It领导者现在正抓住机会实现软件开发和部署的产业化，从而扩展和自动化现有软件资产的测试和部署，并在即将到来的技术领域推广创新资源。

软件风险管理工具概述

现在我们知道了什么是软件风险以及如何识别它们，让我们回顾一下可以降低风险发生率和严重性的工具和方法。这些工具和方法可能特别适用于开发你最有影响力的项目。我们将在下面的简短总结中介绍每个工具，并在每个主题下进行更详细的解释。

产品管理

产品经理通常会列出功能性和非功能性需求并对其进行优先级排序，这样开发团队就可以专注于他们的工作并提供更多的业务价值。事实上，一些与公司生存相关的商业风险可以通过仔细规划公司的发展方向来避免，而规划中最重要的是什么方向不能发展。产品管理层进行的详细需求分析消除了用户在使用软件时遇到的一些问题，严格规定了软件系统的一些非功能性需求(包括安全性、隐私性、可靠性、性能效率和可维护性)，为软件系统发布后的短期甚至长期成功奠定了基础。

显色法

敏捷或瀑布等开发方法提供了一种降低软件风险因素发生率的方法，也可以将问题信息反馈给开发人员。当系统能够长期正常运行时，开发人员可以构建一个更好的系统，从而不断降低软件风险，因为这些较小的稳定模块可以形成一个更大、更稳定的系统。

如今，软件技术日新月异的变化更加引人注目。企业和组织工程团队需要为持续创新开发适当的流程，并让开发人员了解最新的工具和技术。继续教育和抽出一些时间让开发团队做一些创新性的实验将变得越来越重要，以保持公司在技术、招聘和保留方面的竞争力。

开发工具

诸如源代码管理(scm)和集成开发环境(ide)之类的开发工具有着悠久的历史，但是这些工具的最新版本在功能和速度上都有所改进，从而提高了开发人员的工作效率并降低了引入错误的风险。它们还与devops工具链集成在一起，以确保在交付和部署之后仍然可以向开发人员提供反馈，并且应用程序在部署之后可以正常工作，而不仅仅是在开发人员的机器上。

Scm跟踪数百或数千个文件中的每个修订，允许开发人员进行更改，确保他们可以回滚更改，比较更改，并在出现问题时与其他开发人员一起更改冲突的文件。

Ide捆绑了文件管理、编辑、编译和测试工具。它们提供了一种类似仪表板的方式来组合开发人员需要完成的所有任务，包括集成软件平台，如findbugs或sonarqube。这些开发工具可以提供连续的代码质量检查。当开发人员实例化软件系统时，单元级别的软件风险是显而易见的，并且开发人员可以在那时修改它。

本地代码分析

软件语法分析旨在发现重复、过于复杂、可读性差、测试覆盖率不足或违反编码标准的代码，通常在本地或组件级别执行静态代码分析(执行但不执行代码)。大多数编程软件和编译器现在都集成了这些类型的工具。软件解析器可以在许多环境中使用:当ide开发嵌入式软件时，当有一种或多种语言时，以及在不同的系统环境中。

目前，有许多免费的开源工具可用于本地静态代码分析。详细列表请参考维基百科的静态代码分析工具列表。我们将特别提到两种最常用的工具。

Findbugs是一个开源的本地代码分析器。它通过扫描java代码来分析可能的缺陷，并将潜在的错误分为四类:可怕的、可怕的、恼人的和不相关的，从而帮助开发人员理解它们可能的严重性。

Sonarqube是一个用于解析的商业开源工具套件。像ide中的工具和插件一样，sonarqube基本上依赖于一个由商业插件组成的大型库。此外，它还支持多种语言:C、c++、javascript、c #、java、cobol、pl/sql、php、abap，这意味着开发人员可以使用它来保护各种项目中的软件系统。由于sonar cube的广泛使用，使用包含sonar cube的软件系统的人不必学习sonar cube。

然而，当一个项目在ide中或跨项目运行时，代码解析一次只能部分分析一个组件。它可以检测组件本身包含的问题，但是它没有查看系统级问题的权限，并且它不知道在检查组件时添加的上下文信息。

在某些情况下，额外的上下文会使解析器误报。此时，如果开发人员在没有考虑上下文的情况下仔细彻底地检查错误，将会浪费时间和精力。

正如ayewah等人总结的那样，静态分析有时会报告真实但无关紧要的问题，这可能是因为静态分析工具通常不知道代码应该做什么，所以它无法检查代码是否正确地意识到它应该做什么。

您可以将语法代码分析视为一个仪表板，它使开发人员能够实时检查他们正在开发的组件中是否生成或累积了软件风险。

全球系统分析

语法软件分析的局限性迫使业界将组件依赖和数据流添加到传统的软件分析中，然后开发能够将软件系统作为一个整体来识别的软件上下文分析工具。

上述一些工具具有复杂的功能。他们使用语言分析器根据组件分解软件，然后使用分解结果建立整个系统及其所有组件(代码和数据库)和依赖关系的模型。Coverity体系结构分析和cast应用智能平台(cast AIP)是这类工具的两个突出例子。Coverity专注于单一技术，无论是java还是c ++，而cast可以识别同一系统中不同语言和不同级别的多种技术。

一旦软件上下文分析工具建立了系统模型，它就可以在单元和系统级别检查整个系统，而语法分析只能在单元级别检查整个系统。zudeli等人的研究结果表明，涉及多个组件之间交互的缺陷约占所有软件缺陷的30%，但其中80%以上需要修复。此外，由于组件之间的交互作用，系统的上下文不断变化，软件上下文分析也可以避免高频率的误报，因为它知道这些误报仅通过分析组件而不是考虑上下文来触发。

系统级分析的潜在缺点是软件上下文分析不能立即完成，因为有更多的文件和路径需要检查，所以这种分析通常在软件开发生命周期的系统集成阶段运行。即便如此，更深入的分析使得软件上下文分析在降低软件风险方面非常有价值。

管理软件风险的好处

在本文中，我们了解了系统管理软件风险的方法，研究了需要研究的问题类型，并了解了一系列可以度量和降低软件风险的强大工具。这些工具可以帮助企业实现软件风险管理的产业化，并为工程师们做一些自动化的工作，这样他们就可以专注于完成一些你们公司将来会用到的工作。有了这些工具，企业可以提高开发速度，降低中断或安全漏洞的概率，进而更有效地参与当前和未来的业务竞争。

软件风险是非常重要的商业风险。降低软件风险可以直接降低业务风险，包括减少收入损失、改善公司的公众形象、客户满意度和员工满意度。