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

摘要

当下，与软件相关的商务风险是一个很严峻的问题。全美的公司每年因为停机而损失265亿美元的收入，这些风险还严重威胁到软件系统的安全性、可靠性、性能效率和可维护性。

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

目前IT软件质量联盟（CISQ）已经发布了软件质量评估的产业框架，CISO是致力于将开发软件规模和源代码结构质量测试国际标准化的IT行业领导小组，CISO由对象管理组（OMG）和卡内基梅隆大学软件工程研究所（SEI）联合成立。

风险的评估可以分为两个层级：组件和系统级，利用这两个层级的评估，风险可以被有效降低。市面上对应这两个层级已有可用的功能强大的静态代码分析工具，而选择哪个层级则取决于系统在其生命周期中的位置。

    系统化地管理软件风险可以让软件架构师和工程师免于一些机械化的工作，为他们专注于其他工作和创新节约了宝贵的时间，从而帮助公司获得更多的商务效益。不仅如此，管理软件风险还能加快公司发展速度，降低系统中断或安全漏洞的出现几率，让公司更有力地参与到当前和未来的商业竞争中。

引言

   降低单个商务风险十分容易，与软件相关的商务风险在所有的商务风险中占比越来越大，因此，降低软件风险的解决方案已成为当今商业发展的一部分。目前，用户可以在软件资产和开发项目的组合过程中应用一组工具和方法来管理软件风险。对于数字化时代的企业及组织来说，工业化地管理软件风险是至关重要的，它能解放开发人员的“聪明才智”，使他们能专研于构建和交付应用程序等更加困难的部分，同时也能确保应用程序在任何时刻都不会有风险，最大化地利用好人类智能和软件智能。

软件风险等于商业风险

    

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

    为自己或他人开发软件的公司有责任尽量减少与其所交付的软件系统运行和维护相关的商业风险。由于软件系统包含日益臃肿的业务流程模块，并且越来越复杂，因此，降低软件系统中的风险不仅有挑战性，而且至关重要。

组织结构和软件风险

 

  目前，许多IT机构的组织架构并不利于有效地管理软件风险，那么从组织上来看，谁应该负责管理软件风险呢？

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

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

，

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

QA工程师名义上负责产品质量和降低软件风险，但是他们缺乏对软件设计方法的洞察力，导致他们无法测试边界情况和其他盲点。通常，他们甚至没有时间来测试所有的功能。但是恰恰全面测试软件风险应当是他们的主要关注点。

因此，降低软件风险的责任在默认情况下留给了开发人员。这对于在开发人员掌控范围内的风险是有意义的;但是，随着应用程序、新架构框架和交付速度的不断增长和日渐复杂，开发人员可能对整个软件系统失去了深刻的了解，这种现状成了大多数公司和组织都无法克服的盲点，而这种盲点在那些对业务至关重要的部分——核心应用程序的安全性和可靠性方面显得尤为突出。

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

Risk: The Flip Side of Quality 

风险：质量的另一面

在本报告中，我们旨在提供软件风险的概述--如何理解它和如何管理它。

我们首先必须承认，有兴趣构建弹性、快速、灵敏、安全和有保障的系统的IT领导者通常会以“软件质量”而不是“软件风险”来谈论这个话题。也就是说，他们倾向于描述一个积极的结果，而不是避免消极的结果。

对于负责软件系统部署的人员来说，为了尽可能完美地分析商务风险，比较合适的做法应该是平等地看待积极（软件质量）结果和负面（软件风险）结果。

软件风险和软件质量恰如一枚硬币的两面，我们可以利用用于分类和提升软件质量的框架来构建我们对软件风险的审查标准。

我们从最广泛接受的软件质量框架--CISQ发布的自动质量特征量度标准出发，该标准规定从两个方面来进行软件质量测量，或对于本报告而言，测量软件风险（见图1）。

单元级别                       系统级别

     安全性

      可靠性

    性能

        可维护性

图1：测试的两种维度  

Origin of Risk: Unit-Level vs. System-Level 

风险起源：单位级与系统级

软件风险的相关知识中很重要的一块就是软件风险的起因。单元级风险仅限于一个组件，单一编程语言，通常是单个程序员的工作问题，而系统级风险则分布广泛，涉及系统的多个组件、多种编程语言以及架构层（见图2）。

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

At the unit level, problems can be introduced or fixed by developers as work progresses on a software component and its functional requirements (i.e., what that component is supposed to do). However, this remediation is performed without concerns for the rest of the system. This is not intentional, but since developers tend to lack visibility or an understanding of the entire system, their decisions can only be scoped to the individual component. 

在单元层面上，随着软件组件的工作进展及其功能需求变化，开发人员可以引入或修复问题。但是，这种修复是在没有考虑系统其余部分的情况下进行的，开发人员也不想忽略其他部分，只是他们缺少对整个系统的了解，所以他们只能改动自己负责的组件。

系统级问题一般在架构级别产生或修复，通常源于整个系统组件之间，这些组件和软件架构师的设计、产品经理的非功能需求这两种语境以及与用户、数据库这些外部组件的交互。由于当今系统的规模和复杂程度不断增加，开发人员、测试人员或架构师需要在软件分析工具的帮助下才能看到系统级的问题。

Types of Software Risk 

软件风险的种类

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

1.安全性问题：如泄露隐私、数据和授权等的漏洞，显然问题这些可能会造成灾难性的后果。常见缺陷枚举（CWE）是一个比较知名的安全问题的标准化列表，表中目前已经包括了1,005种安全缺陷。

2.可靠性问题：如造成系统停机、数据损坏以及影响系统从中断恢复的能力等的缺陷。

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

4.最后，当软件架构不完整时，会出现可维护性的风险，即每个问题修复所需要的时间特别长，导致软件系统无法应对不断变化的市场要求，或在修复过程中的维护成本过高等。

Run, Build, Transform 

运行、构建、转换

在本节中，让我们使用不一样的透镜来检视软件风险。

大部分公司及企业已有成套的软件系统，公司领导已做好赶超竞争对手的发展规划。而软件风险和降低风险的工作在每个项目生命周期中大不相同，因此如何分析各种类型的风险及其出现的可能性值得我们研究。

运行：你所运行的是什么

对于一般的系统来说，软件风险的大部分都分布在系统级别。在这个假定的场景中，这个项目已经通过系统集成测试并且部署完成，单元级的风险几乎都被消除了。

此时，安全性检查在测试项目的部署使用阶段仍要进行，这包括对已知架构的系统安全问题的定期渗透测试和审查，这是因为针对旧的架构，新型的攻击可能已经被开发出来了。“旧的更安全”，旧的系统可能不太容易有安全漏洞的想法已被证明是错误的，例如，美国联邦机构最近对系统的研究表明，具有更多旧系统的联邦机构可能会有比采用新系统的机构有更多的安全漏洞。

可靠性和性能效率必须被时刻监测；但如果他们长期保持一个稳定的的趋势，则不必予以过多关注，除非系统还在不断加强或改变中。有些系统，在上述的生命周期模式下，由于监管要求变更或合规性的原因，依然需要偶尔升级，并且由于系统的变化，缺少对代码细节的了解，缺乏相应的专业知识而让这种升级变得很困难，就像新建一个系统一样。

系统的可维护性在系统的整个生命周期中，甚至包括以前的部署，都是非常重要的。安全补丁、对库和操作系统的升级，以及开发人员对系统内容的编写修改及维护都非常重要。最后，一个说明项目大致内容和项目规模的文档是必要的，用户清楚系统内容有助于后期维护。

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

若用户已为应用程序设计一个合理的蓝图，它可能包含书写文档时用户需要的所有信息。如果没有，用户可能需要使用一个工具来扫描其应用程序，并生成详细的体系结构蓝图，以准确地描述系统。该蓝图可帮助用户更加全面地了解系统。

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

一个公司若正在开发项目，这将是软件风险管理的一个绝佳的机会，当然也是一个挑战。在这个时候，公司领导对项目如何组合在一起有很大的影响力，其也需要平衡很多因素，例如预算、进度、范围。

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

    

系统级分析的出现，使得项目经理、架构师和安全专家能够持续监控系统的当前和未来的健康状况。将系统级分析集成到DevOps流程中，用软件智能帮助团队提高开发速度并减少返工，同时还能确保他们能够降低最终交付系统中的软件风险。

    

为了管理系统的安全风险，开发人员一般需要时刻跟进了解体系结构和软件工程的一些惯例。应用程序的所有者、架构师和安全专家需要一种方法来验证系统遵循了这些惯例和标准，而系统级分析就满足了这种要求，还能为开发人员和操作团队提供实时的反馈，集成工程师、QA、操作、架构和安全专家可以使用系统级的分析来确定安全热点或缺陷，以便在产品发布之前进行深入的审查。

   

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

   

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

转换:未来的构建目标

    

当前，商业现状，市场和技术变化飞快，管理之前或是当下遇到的软件风险远远不够，为了在未来的挑战中能够存活下来并继续发展，所有公司及组织需要时刻前进。

箭在弦上，不得不发。新的技术和增长领域，例如物联网，区块链和认知计算等新技术源源不断地涌现，这些技术组件将在几年内成为市场主流，企业组织用户还将面对来自新兴市场的激烈竞争压力和时间上的压力。需要进入这些领域，并管理好企业风险。

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

The Software Risk Management Tool Landscape 

软件风险管理工具总览

现在我们已经清楚了软件风险是什么以及如何识别它，让我们了解一下可以降低风险的发生几率率和严重性的工具和方法，这些工具和方法在您最有影响力的项目的开发中可能特别适用。我们将在下面的简短摘要中介绍每个工具，而每个主题下都附有更详细的解释。

Product Management 

产品管理

产品管理者们一般会罗列并优先处理功能和非功能性要求，这样开发团队可以专注于其工作并提供更多的商业价值。一些关乎公司存亡的商业风险其实可以通过仔细规划公司发展方向来避免，而且在规划中至关重要的就是什么方向不能发展。产品管理所做的细致的需求分析消除了用户在使用软件时遇到的一些问题，并且严格规定了软件系统的一些非功能性要求（包括安全性，隐私性，可靠性，性能效率和可维护性），为软件系统发布后短期甚至是长期的成功奠定了基础。

Development Processes 

开发过程

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

当下，软件技术日新月异的变化更加值得注意。企业和组织工程团队需要制定适当的流程来不断创新，并使开发人员了解最新的工具和技术。继续教育和抽出一些时间来让开发团队做些创新实验将越来越重要，这样才能保持公司在技术和招聘以及留住关键人才方面的竞争力。

Development Tools 

开发工具

    

诸如源代码管理（SCM）和集成开发环境（IDE）的开发工具具有悠久的历史，但这些工具最近的版本已经在功能和速度上做了改进，从而提高了开发人员的工作效率，并降低了引入错误的风险。它们还与DevOps工具链集成，确保交付和部署后依然能向开发人员提供反馈，确保应用程序在部署后能正常工作，而不仅仅是在开发人员的机器上正常运行。

   SCM在数百或数千个文件中跟踪每个修订版本，允许开发人员进行更改，确定他们可以回滚更改、比较变化，如果有问题，可以与其他开发人员一起更改有冲突的文件。

IDE将文件管理、编辑、编译和测试工具捆绑在一起。它们提供了一种类似仪表板的方式，可以将开发人员需要做的所有任务组合在一起，包括诸如FindBugs或SonarQube之类的软件平台的集成，这些开发工具能够提供连续的代码质量检测。单元层面的软件风险在开发人员实例化软件系统时显而易见，开发人员可以及时进行修改。

Local Code Analysis 

本地代码分析

    

软件语法分析本着查找重复的、过于复杂的、可读性差的、测试覆盖不足或违反编码标准的代码为目的，一般在本地或组件级进行静态代码分析（而不需要执行代码）。现在大多数编程软件和编译器都集成了这些类型的工具。软件语法分析器可以在许多上环境下使用：在IDE进行嵌入式软件开发时，有一种或多种语言时，以及不同的系统环境下。

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

FindBugs是一种开源的本地代码分析器。它通过扫描Java代码来分析其中的可能缺陷，并将潜在错误分类为很可怕的、可怕的、令人烦恼的和无关痛痒的四类，从而帮助开发人员了解其严重性。

SonarQube是一款商业化的句法分析开源工具套件，和IDE中的工具和插件一样， SonarQube的功能基本上都依赖于一个由商业化的插件组成的大型库。此外，它还支持多种语言：C、C++、JavaScript、C #，java，COBOL，PL / SQL，PHP，ABAP，这意味着开发者可以在在各种各样的项目中使用它来检测软件系统。 

尽管如此，当项目在IDE中运行或是跨项目运行时，代码语法分析仅能一次一次局部地分析组件。它能够侦测组件自身包含的问题，但它不具备查看系统级问题的能力，也不知道它检查一个组件时所关联的语境信息。

在某些情况下，额外的语境会让语法分析误报，此时，若开发人员不考虑语境直接对错误进行仔细彻底的检查和语法分析，必将会浪费时间和精力。

正如Ayewah等人总结道：“静态分析有时候会报告确实存在但是微不足道的问题，可能是因为静态分析工具一般不知道代码应该做什么，因此，它不能检查代码是否正确地实现了应该做的事情。”

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

Global System Analysis 

全局系统分析

语法软件分析的局限性迫使行业向常规的软件分析中添加了组件依赖关系和数据流这些信息，进而开发出能从整体上认知某个软件系统的“软件语境分析”工具。

上述工具中有一些功能较为复杂，它们使用了语言分析器按组件分解软件，然后用分解结果来搭建整个系统及其所有组件（代码和数据库）和依赖关系的模型。Coverity Architecture Analysis和CAST Application Intelligence Platform（CAST AIP）就是这类工具中两个突出的例子。 Coverity专注于单一技术，无论是Java的还是C ++的，而CAST可以识别同一系统中不同语言，不同层次中的多种技术。 

一旦软件语境分析工具构建了系统的模型，它就可以在单元和系统两个层面上检查整个系统，而语法分析就只能在单元层面检查。李祖德（Zude Li）等人的研究结果表明涉及多个组件间交互的缺陷占所有软件缺陷的约30％，但却需要超过80％的修复工作。此外，随着组件之间相互作用而导致系统的语境不断变化，软件语境分析还能避免高频率的误报，因为它知道这些误报是没有考虑语境，仅对组件进行分析才触发的。 

系统级分析的潜在缺点是，由于有更大数量级的文件和路径要检查，软件语境分析的运行不能立即完成，所以这种分析通常放在软件开发生命周期中的系统集成阶段运行。即使这样，更深层次的的分析仍使软件语境分析在降低软件风险方面非常有价值。

Business Benefits of Managing Software Risk 

管理软件风险的好处

在本报告中，我们了解了系统地管理软件风险的方法，研究了将需要调查的问题的种类，知晓了一系列能测量和降低软件风险的强大工具。这些工具可以帮助您实现管理软件风险的流程化，替您的工程师中做一些可自动化的工作，来让他们更专注地完成在未来您的公司未来将会用到的一些工作。有了所有这些工具，您的机构便可以提高开发速度，降低出现中断或安全漏洞的几率，进而更有力地参与到当下和未来的商业竞争中。

软件风险是一种很重要的商业风险。降低软件风险能直接降低商业风险，包括减少收入损失、提升公司的公众形象、客户满意度和员工满意度。此外，它还能：

•提高组织敏捷性和工作效率 ，这样就能更有效地跟踪用户需求，更快更有效地完成项目。

•舍弃废弃不用的资源，不能正常运行的项目和可利用性较差的应用程序。

•提高您作为领导者的声誉。

•资深团队和行政人员能更有效地讨论如何降低系统风险，如何提高系统质量。