【赛迪网讯】当下，与软件相关的商务风险是一个很严峻的问题。这些风险还严重威胁到软件系统的安全性，可靠性，性能效率和可维护性。
        目前IT软件质量联盟（CISQ）已经发布了软件质量评估的产业框架，CISO是致力于将开发软件规模和源代码结构质量测试国际标准化的IT行业领导小组，CISO由对象管理组（OMG）和软件工程研究所（SEI）在卡内基梅隆大学联合成立。
        风险的评估可以分为两个层级，组件和系统级，利用这两个层级的评估，风险可以被有效降低。市面上对应这两个层级已有可用的功能强大的静态代码分析工具，而选择哪个层级则取决于系统在其生命周期中的位置。
        系统化地管理软件风险可以让软件架构师和工程师免于一些机械化的工作，为他们专注于其他工作和创新节约了宝贵的时间，从而帮助公司获得更多的商务效益。不仅如此，管理软件风险还能加快公司发展速度，降低系统中断或安全漏洞的出现几率，让公司更有力地参与到当前和未来的商业竞争中。
        日前，卡特财团(Cutter Consortium)?Peter Kaminski与Tomlin Coggeshall，在卡特财团的《通过软件语境分析降低业务风险和解锁软件潜力》报告中，指出：“降低单个商务风险十分容易，与软件相关的商务风险在所有的商务风险中占比越来越大，因此，降低软件风险的解决方案已成为当今商业发展的一部分。目前，用户可以在软件资产和开发项目的组合过程中应用一组工具和方法来管理软件风险。对于数字化时代的企业及组织来说，工业化地管理软件风险是至关重要的，它能解放了开发人员的“聪明才智”，使他们能专研于构建和交付应用程序等更加困难的部分，同时也能确保应用程序在任何时刻都不会有风险，大化地利用好人类智能和软件智能。”
        软件的组织结构和软件风险
        目前，许多IT机构的组织架构都不利于有效地管理软件风险，那么从组织上来看，谁应该负责管理软件风险呢？
首席信息安全官(CISO)负责系统的整体安全，但是这个人可能不会直接参与到日常的应用程序开发中，此外，CISO并不需要对可靠性、性能效率和可维护性三种类型的软件风险负责。
        架构师负责建立架构标准，以确定开发人员在开发应用程序过程中如何降低风险，但是在构建应用程序时，架构师常常不会参与开发环节。
        因此，开发工作可能会无意中在架构团队不知情的情况下偏离了目标体系结构。
        QA工程师名义上负责产品质量和降低软件风险，但是他们缺乏对软件设计方法的洞察力，导致他们无法测试边界情况和其他盲点。通常，他们甚至没有时间来测试所有的功能，而测试才是他们的主要关注点。因此，降低软件风险的责任在默认情况下留给了开发人员。
        这对于在开发人员掌控范围内的风险是有意义的;但是，随着应用程序、新架构框架和交付速度的不断增长和日渐复杂，开发人员可能对整个现代软件系统失去了深刻的了解，这种现状成了大多数公司和组织都无法克服的盲点，而这种盲点在那些对业务至关重要的部分——核心应用程序的安全性和可靠性方面显得尤为突出。
        我们的建议是，产品管理或产品负责人应该对管理和降低产品风险负主要责任，他们可以使用软件语境分析工具并分配相应的工程团队来解决这个问题。
        风险：质量的另一面
        我们首先必须承认，有兴趣构建弹性，快速，灵敏，安全和有保障的系统的IT领导者通常会以“软件质量”而不是“软件风险”来谈论这个话题。也就是说，他们倾向于描述一个积极的结果，而不是避免消极的结果。
对于负责软件系统部署的人员来说，为了尽可能完美地分析商务风险，比较合适的做法应该是平等地看待积极（软件质量）结果和负面（软件风险）结果。
        在单元层面上，随着软件组件的工作进展及其功能需求变化，开发人员可以引入或修复问题。但是，这种修复是没有考虑系统其余部分的情况下进行的，开发人员也不想忽略其他部分，只是他们缺少对整个系统的了解，所以他们只能改动自己负责的组件。
        系统级问题一般在架构级别产生或修复，常源于整个系统组件之间，这些组件和软件架构师的设计、产品经理的非功能需求这两种语境以及与用户、数据库这些外部组件的交互。由于当今系统的规模和复杂程度不断增加，开发人员、测试人员或架构师需要在软件分析工具的帮助下才能看到系统问题。
        软件风险的种类
        标准的第二个维度是类型，我们将软件风险问题分为四个主要的类别。
        1.安全性问题，如泄露隐私，数据和特权等的漏洞。显然这些可能会有灾难性的后果。常见弱点枚举是一个比较知名的安全问题的标准化列表，表中已经包括了1,005种安全错误。
        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，这意味着开发者可以在在各种各种的项目中使用它来保护软件系统，因为SonarQube的广泛使用，使用包含SonarQube的软件系统的人也不必再去学习SonarQube。
        尽管如此，当项目在IDE中运行或是跨项目运行时，代码语法分析仅能一次一次局部地分析组件。它能够侦测组件自身包含的问题，但它不具备查看系统级问题的权限，也不知道它检查一个组件时所增加的语境信息。
在某些情况下，额外的语境会让语法分析器误报，此时，若开发人员不考虑语境直接对错误进行仔细彻底的检查语法分析，必将会浪费时间和精力。
        您可以将语法代码分析视为一个仪表板，它能让开发人员能够实时查看其正在开发的组件中软件风险是否产生或是积累。
        全局系统分析
        语法软件分析的局限性迫使行业向常规的软件分析中添加了组件依赖关系和数据流这些信息，进而开发出能从整体上认知某个软件系统的“软件语境分析”工具。
        上述工具中有一些功能较为复杂，它们使用了语言分析器按组件分解软件，然后用分解结果来搭建整个系统及其所有组件（代码和数据库）和依赖关系的模型。Coverity Architecture Analysis和CAST Application Intelligence Platform（CAST AIP）就是这类工具中两个突出的例子。 Coverity专注于单一技术，无论是Java的还是C ++的，而CAST可以识别同一系统中不同语言，不同层次中的多种技术。
        一旦软件语境分析工具构建了系统的模型，它就可以在单元和系统两个层面上检查整个系统，而语法分析就只能在单元层面检查。李祖德（Zude?Li）等人的研究结果表明涉及多个组件间交互的缺陷占所有软件缺陷的约30％，但却需要超过80％的修复工作。此外，随着组件之间相互作用而导致系统的语境不断变化，软件语境分析还能避免高频率的误报，因为它知道这些误报是没有考虑语境，仅对组件进行分析才触发的。
        系统级分析的潜在缺点是，由于有更大数量级的文件和路径要检查，软件语境分析的运行不能立即完成，所以这种分析通常放在软件开发生命周期中的系统集成阶段运行。即使这样，更深层次的的分析仍使软件语境分析在降低软件风险方面非常有价值。
        管理软件风险的好处
        在本文中，我们了解了系统地管理软件风险的方法，研究了将需要调查的问题的种类，知晓了一系列能测量和降低软件风险的强大工具。这些工具可以帮助企业实现管理软件风险的产业化，替工程师中做一些可自动化的工作，来让他们更专注地完成在未来您的公司未来将会用到的一些工作。有了所有这些工具，企业机构便可以提高开发速度，降低出现中断或安全漏洞的几率，进而更有力地参与到当下和未来的商业竞争中。
        软件风险是一种很重要的商务风险。降低软件风险能直接降低商务风险，包括减少收入损失，提升公司的公众形象，客户满意度和员工满意度。
                                                                                                    来源：赛迪网