software-strategy-1/Ch2-4-DevelopmentMethodolog...


软件开发方法与技术是软件学科的核心关注点之一，从宏观上看，其目标一方面是在计算平台上给出满足用户需求的解决方案，另一方面是达到开发效率、质量、成本的最佳平衡。在通常的软件及信息技术体系中，软件开发包括了技术、管理、工具等多个方面：技术上包括软件分析、设计、构造、维护和质量保证，关注于如何完成具体的软件开发活动并产出相应的软件制品；管理上包括软件过程模型、开发团队组织和最佳实践，关注于软件开发活动的流程和协作管理以及包括人在内的各类资源的组织和运筹等；不论是技术还是管理方面，在解决大规模复杂软件开发问题时都离不开工具的支持和帮助。高效、高质量、低成本地开发和演化软件系统是软件开发方法和技术研究追求的总体目标，在这个总体目标指引下，在不断出现的、新的应用需求的牵引下，软件开发方法和技术研究不断面临新的挑战。


在“软件定义一切”的时代背景下，尽管软件开发方法与技术的目标宏观上依然不变，但是软件的需求空间被进一步大幅度扩展，人机物融合的需求场景和运行环境更进一步增大了软件系统的规模和复杂性，导致软件开发和演化的成本随之急剧上升，从而产生了对软件自动化方法与技术的迫切需求；另一方面，软件开发和演化的外在条件随着需求和技术发展不断发生变化，新的问题不断涌现，不断扩展了软件自动化方法和技术的研究空间。


人是软件开发成败的决定因素，认知空间中人们长期的积累与计算平台的发展，使得软件开发的社会化和智能化成为必然方向，也为软件开发中人与计算/机器平台的新型关系的建立提出了挑战。网络化、数据化、可视化、虚拟化将改变人在软件开发中的工作方式、合作方式和组织方式，催生出软件开发的各种新方式，包括软件开发终端化和普及化、群智化开发与生态化平台等等。建立新的开发方式以有效适应人机融合的软件生态发展，将是软件开发和平台的未来机遇。


软件作为智力和人工制品，软件开发属于认知空间范畴，介于应用空间（问题空间）与平台空间（解空间）之间。应用空间和平台空间的泛在化和持续变化决定了未来软件形态的泛在性、适应性、演化性。复杂多样的不确定性成为软件的固有本质特征，控制而不是消除不确定性使得软件的持续演化和成长成为必然挑战。与传统软件开发相比较，软件的不确定性控制和处理难以在设计时完成，除了面向应用空间，软件开发的设计时与运行时融合要求认知空间与平台空间的协作乃至一体化成为一个趋势。近来的开发运维一体化已经有了一个良好的开端。


面向动态变化场景的人机物融合复杂系统，软件开发面临的首要挑战是融合人机物三元资源、以建模为核心的软件定义方法和技术。我们需要构建人机物三元资源及其行为的抽象、观察和度量的新模型和方法，研究基于软件定义方法的元级控制和数据赋能机理，使得软件开发方式（包括设计、构造和保证）从实体建模为主走向实体加链接，从分而治之走向群智聚合，从而有效驾驭各类软件复杂性。

\section{重大挑战问题}
在人机物融合应用场景需求牵引下，软件开发方法和技术研究面临的重大挑战问题主要包括复杂场景分析与建模（§4.1.1）、群智开发（§4.1.2）、人机协作编程（§4.1.3）和开发运维一体化（§4.1.4）。

\subsection{复杂场景分析与建模}
人机物融合计算场景的需求在我们的日常生活中已经存在，大到智慧国家、智慧城市，小到网络家电、汽车引擎智能网络控制系统，对这类计算场景的分析和建模存在许多挑战，其中最重要的挑战包括如下四个方面。


（1）与日俱增的规模与复杂度


从已经出现的支撑人机物融合计算场景的系统来看，其系统的大小和复杂性显著增加。例如，现代汽车中基于软件的功能在不断地持续增加[1]，比如，2007年经典高端轿车包含大约270个与驾驶员互动的软件实现的功能，而最新的高端轿车包含超过500个这样的功能。轿车软件的规模也在大幅增长。2007年高端轿车的二进制代码量约为66兆字节，而现在这类轿车则含超过1千兆字节的二进制代码。随着软件支持的功能的数量和规模的增加，复杂性也随之增加。这些基于软件的功能要求各个组件子系统，例如刹车系统、发动机管理系统、驾驶辅助系统等，具备更细粒度的功能，以及子系统之间密集的交互，因而整个系统的复杂性大大增加，对系统的分析和建模需要从方法和技术上得到全面提升。


除了功能数量和规模的提升，对软件分析和建模方法的挑战还来自于软件与硬件、软件与人的交互的紧密性和持续性。首先，软硬件协同分析和建模成为必须，这类系统的发展大部分是由先进硬件技术的改进而驱动的，集成电路的成本、尺寸和能耗的显著降低以及基于新原理的计算元件的可用都是技术改进的例子。这种改进使得软件有可能控制设备，而且在经济上也成为可行。另一方面，软件在硬件设备中的广泛集成又为许多设备提供了更加新颖的功能，例如家用电器的网络连接，集成了数万到数千个内核的多核处理器的单个芯片的开发，意味着即使是单芯片系统也必须被视为由大量单个节点组成。这种趋势和挑战要求采用系统的方法来设计具有大量计算节点的大型网络化系统。通过网络将数亿或者数十亿个物理设备、智能设备连接起来，这些数量庞大的智能设备进行实时数据采集和彼此之间信息交互，形成了复杂的网络，产生了大量的数据，这些数据呈指数级增长。这些数据的处理促进了新软件的诞生，系统规模日益增大。这描绘了一个物理世界被广泛嵌入各种感知与控制智能设备后的场景，在这个场景下能够全面地感知环境信息，智能地为人类提供各种便捷的服务。


其次，将人的行为分析和建模纳入到系统分析和建模的范畴中也成为必须。在这些人机物融合计算场景中，人的日常生活和这些大型网络化系统将紧密地联系在一起，比如，目前，全球已经大约30亿人连入互联网，每个人都在智能终端、个人电脑上使用各种各样的软件，发微博、发微信、全球每天会有2.88万小时的视频上传到Youtube，会有5000万条信息上传到Twitter，会在亚马逊产生630万笔订单，…。这些数据都是由人和系统的持续交互产生的结果，人的行为和意图将成为系统分析和建模的重要关注点。


（2）开放和不确定环境


在传统软件分析和建模方法中，通常假设软件的工作环境就是当前设计的环境。与其不同，在人机物融合计算场景中，软件系统将运行在开放和不确定环境中。例如，在未来的大规模无处不在的城市计算系统中，系统将能获取到大量的异构数据，这些异构数据由城市空间中的各种数据源和数据采集器（如传感器、设备、车辆、建筑物和人类等）产生，需要集成到软件系统中进行统一分析，并在收集的数据上构建许多有趣的应用。例如，通过气象传感器收集温度、湿度和风向等信息后，软件系统可以预测热岛效应并给出应对措施。软件系统还可以帮助维护旧的高速公路或道路，并通过部署在旧建筑中的传感器检测旧建筑的安全参数，预测危险。软件系统还可以通过感知人类的生命体征，帮助提供紧急医疗服务和监测慢性病。在所有这些人机物融合计算场景下，软件的交互环境都是动态的，并且可以观察到其不确定性。


有很多证据表明，在人机物融合计算场景中，软件的交互环境也是开放的。例如，许多移动电话、掌上电脑、个人电脑甚至是配备RFID的商品都通过不同规模的网络联网，它们可以自主的动态加入或者移除。可用设备的不断更新，又促使服务提供商提供新服务或删除不再有校或已被取代的服务，更换不再提供类似功能的其他服务，利用网络环境提供新的服务，而这些更新后的服务是软件系统设计时不可能预见到的。因此，建立在不断变化的服务空间上的人机物融合系统的环境永远不会是封闭的，而是开放的，所以需要从方法学和技术层面支撑分析和建模能容忍环境的开放性、变化性和不确定性。


（3）情境感知和适应性


除了复杂度和不确定性带来的挑战之外，人机物融合计算场景中，对软件系统的分析和建模还受到来自由于新算法新技术引入的系统能力的挑战。例如，目前可以看到的，手机与全球定位系统位置设备耦合的电子导航系统，以及执行从交通冲突检测到自动间隔和车道跟踪任务的自动装置，正在被辅助驾驶软件系统采用，这些新的能力使软件系统更加深入地嵌入到可变和开放的环境中，也使系统能够了解系统周围的整体情况，从而做出更好的在线决策。新技术和新能力的引入使得软件系统常常要在与其设计时明显不同的条件下运行。


在执行时，软件系统它们不仅应该能够适应各种交互和运行环境（比如，网络环境）的变化，还应该能够在遇到变化时继续可靠地执行。未来的人机物融合计算场景中，软件系统将更普遍、更分散，并且在其运行期间将需要更广泛的适应性。交互和运行情境的动态变化（事物在环境中变化的程度和速度）是一个重要特征。软件系统的分析和建模需要考虑在线决策的能力。在人机物融合复杂计算场景下进行动态决策，所要求的绝不仅仅是简单地认识环境状态，具备良好的情境意识，整合对情境的理解，它高度依赖于情境感知能力，支持对环境状态的不断演变的认识。


（4）创新使能的需求模糊性


人机物融合计算场景下，软件系统分析和建模的困难还来自于当前的需求相关者（即领域专家，最终用户和客户）无法提供完整和正确的能力要求。可以看到，许多创新应用，一些最受欢迎的应用程序，如微信、在线购物等，都是由技术的发展和产品设计师的创新思维驱动的，而不是最初的需求相关者所要求的。信息技术飞速发展的时代，领域专家和最终用户无法提出超出想象范围的技术发展，他们不了解现有技术的发展趋势，在软件系统分析和建模方法中支持未来创新需求的引入或提供对创新需求的包容手段是一个重要的挑战。

\subsection{群智开发}
互联网技术的发展，使得人类群体打破物理时空限制开展大规模协作成为可能，新型编程技术包括新型高级编程语言、智能化编程工具和技术的出现则降低了编程开发的参与门槛，软件开发活动从一个纯粹的生产性活动转变为一个涉及到多种要素紧密关联的社会性活动，软件也从相对独立的产品转变为多种元素相互依赖持续演化的生态。在软件生态系统中，作为软件开发活动中的关键要素，人在其中的角色发生了显著变化：参与者规模的变化，软件开发活动的参与者规模由过去的公司/组织内部封闭环境下的数百数千人转变为软件生态系统中通过互联网联接的开放环境的数万数十万人；参与者类型的变化，软件开发活动的参与者由过去的主要是开发者转变为软件生态系统中开发者、用户、管理者、投资人等多种不同类型的个体深度参与，共同驱动软件生态系统的发展演化；参与者角色的变化，每个软件开发活动的参与个体的角色从单纯的软件开发者或使用者等单一角色演变为软件生态系统的参与者和推动者等多重角色，每个参与个体都成为软件生态中的组成部分同软件生态共同成长演化。


群智开发是一种通过互联网联接和汇聚大规模群体智能实现高效率高质量的群体化软件开发方法，主要包括微观个体的激发、宏观群体的协作、全局群智的汇聚以及持续的成长演化等不同的维度。在生态观下，软件开发的关注点从“人在系统外”的软件系统构建发展为“人在回路”的软件生态构建。开源软件、软件众包以及应用市场等快速发展，显示出超越传统软件开发的生产力，展现了群智开发所蕴含的巨大潜力。但是，如何高效激发和稳态汇聚大规模群体智能，确保群智智能在软件开发活动中可控形成和重复出现，构建持续健康演化的软件生态，是群智开发面临的核心挑战。


（1）自主个体的持续激发和大规模群体的高效协作


互联网技术的快速发展，打破了传统软件开发面临的时间和空间的局限，为大规模群体的联接和协作提供了坚实基础。在开源、众包和应用市场中，采用社区声誉、物质回报等多种机制来激励群体参与，并采用合作、竞争和对抗等模式开展群体协作，取得了一定的进展。但是，在互联网环境下的群智开发中，参与的每个个体都具有高度的行为自主性和不可预测性，基于人类群体智能的软件开发不仅仅是一种技术问题，而是一个涵盖心理、社会、经济等多种属性交织作用的复杂问题，如何有效激发每一个参与个体持续高质量贡献？另一方面，大规模多样化群体的开放参与带来巨大的沟通交互开销，如何有效组织大规模参与群体开展高效协作共同完成复杂软件开发任务，是群智开发面临的一大挑战。


（2） 群智任务的度量分解与群智贡献的汇聚融合


软件开发本身是一项创作与生产深度融合的活动，具有很强的开放性和灵活性。在面对一个具有更强不确定性和差异性的大规模群体时，如何将一个复杂的软件开发任务分解成一组简单任务，并建立起开发任务与参与个体的最优适配，实现个体智能的最大释放？此外，开放参与下的软件开发具有群体贡献碎片化、群智结果不可预期性等特点，如何量化度量群智贡献的质量和价值、构建有效的群智贡献迭代精化闭环、实现多源碎片化群智贡献的可信传播与汇聚收敛，形成高效群智涌现？


（3）群智开发生态的认知度量和成长演化


在群智开发中，参与者群体、代码与社区等多样要素共同形成一个持续发展的生态，在个体激发和群智融合基础上，通过评估和反馈推动生态持续成长演化。在此环境下，软件开发关注点不再仅仅是孤立的、静止的参与者个体或者代码，更需要从“联系”的、“发展”的视角去分析和认识整个群智生态。面临以下两个方面的挑战：一是如何认知和计算软件开发中的群智。群智激发和汇聚是形成群智开发生态的关键，如何深入理解和认识群智激发汇聚和本质，并从激发和汇聚的角度建立群体智能的效能评估方法和评测指标，从而为群智开发的成长演化提供评价准则和度量体系？二是如何推动群智生态的持续成长演化。群智生态中各个要素相互依赖紧密交互，如何建立多元高效的主动反馈机制，在基于群智度量体系对群智过程开展量化度量的基础上对参与群体进行实时反馈和持续引导，驱动群智生态的正向演化？

\subsection{人机协作编程}
在现有的软件开发活动中，几乎每一行程序（高级语言编写的代码）都需要人类程序员手工编写，随着对软件的需求进一步地增长，以及软件复杂度进一步地提升，这种几乎全手工的编程方式将成为制约计算机行业发展的瓶颈。只有大幅度提升机器编程的占比，并将程序员的主要工作更多地放在少数对创造性具有极高要求的活动上，才能够突破这一瓶颈。因此，需要将程序员统领开发环境完成编程任务的模式转变为程序员与机器各司其职又相互协作完成编程任务的模式。实现人机协作编程的挑战主要来自两个方面：1、如何提升机器编程的能力；2、如何实现人机无障碍协作。


提升机器编程的能力是实现人机协作编程的基础，软件自动化是提升机器编程能力的主要技术手段。人们对软件自动化的探索几乎是伴随着软件的出现而开始的，由于早期的软件开发（编程）是异常繁琐易错的工作，人们很早就开始考虑将编程中机械性的工作交给机器完成。然而，软件自动化也一直没有完全达到人们的期望，导致软件开发长期属于严重依赖开发人员个人能力的活动。传统的软件自动化技术以严格的规约作为输入，通过机器将规约翻译成程序代码或者通过搜索技术找到符合规约的程序代码：前者的典型代表是编译器，也是软件自动化方面到目前为止最为成功的尝试，但随着抽象层次的提高，人们发现很难通过固定的规则完成所有可能的翻译；后者的典型代表是程序合成，但由于程序空间过于庞大，目前能够通过搜索获得程序通常仅限于规模很小的程序。近年来，随着数据的广泛积累，数据驱动的方式在很多领域取得了前所未有的成功，类似地，长期累积的海量代码数据为软件自动化带来了新的可能性，为提升机器编程能力带来了新的希望。数据驱动的软件自动化可以利用已有代码数据中总结出来的规律指导搜索，从而提升程序合成的效率，同时这种不依赖严格推理的模式又易于处理半形式化甚至非形式化的规约，从而扩大软件自动化技术的适用范围。由于程序空间是无限空间，已有程序代码在整个空间里仍然很稀疏，而程序代码又受到问题领域、技术进步、开发者习惯的影响展现出很强的异质性，如何从已有程序代码总结规律存在巨大的挑战。


与人工编程相比，机器编程的优势在于机器编程可以利用计算机的强大计算能力，劣势在于机器编程主要从已有代码中学习，缺乏有效处理边角信息的能力，因此高效的人机协作将能更好地发挥两者的优势。支持高效人机互动的开发环境一直是软件工程关注的重点之一，最早的开发环境只是一系列工具的简单堆叠，真正意义上的开发环境是在上世纪八十年代以后发展起来的，这类开发环境的主要特点在于，开发者是整个开发环境的主导，开发环境是开发者的操控台和延伸，进入到新世纪开发环境有两个新的发展趋势：1、开发环境中开始出现一些智能服务（如代码推荐等），虽然能够进入主流开发环境的智能服务仍十分有限，但学术界研究的智能工具多以开发环境的插件形式展现；2、开发环境开始支持开发者间的交互，虽然这与开发者间远程协作需求的增长有关（短程协作中开发者可以进行面对面的交流），但却为探索多开发者协同提供了有益尝试。为了满足人机协作编程的需要，开发环境需要应对以下两方面的挑战：1、建立开发者对机器编程的信任关系：在开发者主导的环境中开发者更多依赖自己的主观判断，但在人机协作环境中开发者完全可控的范围缩小将更依赖机器编程，如果开发者不能确信机器编程能否完成特定任务，就会严重影响开发效率；2、实现人机多渠道交互：现有开发环境中的人机交互以及开发者间的交互方式主要以文本方式进行，而人类通常习惯同时以多种方式进行交流，这样才能更好激发开发者的创造力。

\subsection{开发运维一体化}
软件开发是人类的一项高复杂度的集体智力活动，其现实问题的复杂度反映到开发中主要表现为架构、过程、技术和组织四个维度上的复杂度，它们往往紧密地交织纠缠在一起并相互转化。软件工程在这四个维度上发展趋势，即架构逐渐去中心化，技术趋于平台化、自动化和虚拟化，过程趋于增量和迭代，组织趋于小而自治，开发运维一体化（DevOps）集中体现了这些发展趋势的高阶形态。随着互联网化和服务化的高度发展和走向成熟使得未来的软件更加需要具备持续（continuous）的特征。这种持续性将覆盖从商业策划、开发到运维以及演化的所有环节，使得未来软件系统像具有生命一般：在持续稳定提供服务的同时，软件系统的边界、发展走向等不再固化，而是始终处在不断变化和适应之中。持续性与上述的架构、过程、技术与组织四个维度的复杂性交织在一起，再叠加性能、安全等质量要求和实效性要求等，使得未来的软件系统的开发和运维面临诸多的挑战，这就需要我们在原则、方法、实践以及工具层面都做要充分的应对。


（1）	构建按需（On-Demand）的基础设施


作为DevOps产生的技术和平台基础，基础设施(Infrastructure)可能是未来DevOps能够发挥更大作用的关键环节。然而，如何匹配软件系统运行需求（或者企业需求）来构建适用的基础设施一直是需要重点关注的话题。值得关注的几个挑战包括：1）混合云，即为了更好的适应各种业务场景，混合云是一种合理的选择，但是由此带来的异构、安全、可扩展等方面的挑战不容忽视；2）边缘计算，即为了尽可能减少数据传输代价，就近提供计算服务是一种选择，但是，这会大大增加基础设施的复杂程度，带来软件系统部署和维护方面的巨大挑战。此外，支持Serverless架构的基础设施、内建安全的基础设施、RPA（Robotic Process Automation，机器人流程自动化）等等也都是未来支撑DevOps发展的IT基础设施相关的研究和实践热点。


（2）	搭建智能化流水线


DevOps 持续高效高质量的交付有赖于高度自动化支持工具的支持，自动化也是获得快速反馈的关键。鉴于DevOps自动化支持工具涉及多个阶段，种类繁多，数量上已达数千种，从诸多关系复杂的工具中理解和选择合适的工具集合来搭建流水线对 DevOps 实践者来讲至关重要，但也非常具有挑战性。未来，部分重要的基础性工具将向少数较成熟的工具收敛（如在持续构建、自动化部署、服务治理等方面），但是，更多的DevOps的自动化支持工具将向更加专业化发展。即构建的流水线往往面向特定应用领域（例如金融行业对安全性和合规性有着极高要求）或包含其他专业组建（例如，人工智能、大数据等），因而，如果提供开箱即用的工具链方案，帮助企业选择并定制适合其业务的DevOps工具链是一个巨大的挑战。此外，随着软件项目的持续进展，DevOps流水线会产生大量的数据，例如，工具链自身产生的数据，在研软件系统在验证过程中产生的数据以及DevOps项目执行产生的数据等等。如何从流程与数据两个维度打通，提供以DevOps流水线为基础的开发运维一体化协作平台，进而提升其智能化水平，再次基础上提升DevOps实践的效率和质量，同样也是为了支持前文所述的持续性，从工具链和生产环境角度需要需要解决的重大挑战之一。


（3）	探索可用的微服务化架构演化策略和评估手段


微服务化是支持前文提及的软件系统持续性要求的必备条件。软件系统的微服务化要求软件系统的各个模块或服务间耦合进一步降低，从而在新版本发布和出现问题时不会影响到系统其它部分。企业系统架构向微服务架构演化以更好地支持DevOps已成为行业共识和趋势，然而在演化过程中却面临诸多挑战。首先，合理的服务划分，即将软件系统拆分成多个独立自治且协同合作的服务，是微服务应用实现敏捷、灵活和高可扩展的先决条件，也是微服务领域的一项严峻挑战。其次，虽然服务拆分为测试带来诸多便利，但在另一方面，服务数量的增加也带来了测试复杂度的指数增长。当采用微服务架构之后，系统对远程依赖项的依赖较多，而对进程内组件的依赖较少，因此测试策略和测试环境需要适应这种变化。微服务系统不仅需要保证组件内部的正确性，还需要通过契约测试等保证组件间通信和交互的正确性，使得众多微服务能够真正实现协同工作。相应地，微服务联调、日志分析与故障定位、自动化监控告警与治理策略等是当前以及未来较长时间内的研究中需要探索的迫切问题。此外，微服务架构并不一定适合所有的企业情况，因此，建立微服务架构行之有效的评估和决策支持方法，如在演化过程中，应该通过哪些角度去判断架构拆分的效果？这些角度与业务需求之间的对应关系？如何度量微服务拆分效果并及时给出建议（包括补充替代的架构形式）等都存在若干亟需解决的问题。


（4）	DevOps高频交付带来的质量和安全问题


质量和安全一直都不是新问题，但是在当前以及未来，都是DevOps用以支撑未来软件系统开发和运维应当重点关注的点。在DevOps语境下，在高水平自动化支持下的快速高频交付是维系持续性的基础，但同时也使得传统的质量和安全问题都有了新的内容。例如，通过各类工具来实现自动化V\&V是DevOps实践中的不二选择。然而，现有工具在发现并且消除缺陷和隐患的效率和效能方便并不能如意。大量研究和实践表明，DevOps和Security合规往往在实践中具体天然的对立，这种对立不是通过“构造”DevSecOps一个词汇能解决的。如何协调上述的对立是一个棘手问题。其次，现代软件系统的缺陷（vulnerability）往往有多种来源和根本原因，例如来自上述基础设施的安全威胁、DevOps的快节奏所导致的各种妥协、质量缺陷、大量第三方组件的安全威胁、自动化运维中的安全隐患、企业文化（流程、人员技能和意识等）导致的安全疏漏等等。所谓百密一疏，尽管有一些工具、方法以及实践可以一定程度上缓解上述各种威胁带来的压力，但显然在效果和效率方面还有一些不足。从这个意义上述，退而求其次的方式是采取事后方式——通过监控系统运行过程尤其是通过分析系统异常来辅助发现安全风险。但是，这种方式还是有两大急需解决的难题，即如何产生可靠的高质量运行相关的数据（例如日志信息）以及如何应用先进的技术（例如大数据、AI技术等）提升对数据的利用效率和分析数据发现质量和安全性风险的能力。


（5）	智能化运维


作为DevOps中的Ops一端，运维的重要性越来越突显。工业界目前已经开始实践智能化运维（AIOps）技术以有效降低运维成本、提高运维效率和质量。随着各类AI技术和方法的迅速发展，智能化运维尽管已经有了较为坚实的基础，但是其有效实施却直接依赖于软件系统或者服务的运行时产生的各类信息的质量。目前智能化运维主要是提供一些相对简单的标准化日志信息的捕获、分析和决策，主要只关注在运维侧，在现阶段尚未有效形成运维-开发的反馈闭环，以支持开发高效应对运维变化。此外，智能化运维依赖的各类数据都有缺点：日志数据的产生主要依赖程序员的个人经验，实践中往往日志质量很差，难以支持对软件行为的有效捕获；指标数据则是一种隔靴搔痒的环境数据；跟踪路径数据会在瞬间产生巨量数据，导致完全无法分析。因此，如何充分使用这三类数据，在更加精细的力度上捕获软件应用或者服务的行为，进而提供更加准确的信息供分析，这是智能化运维需要解决的关键问题。


（6）	支撑DevOps规模化的组织与管理


DevOps整合了开发团队与运维团队，使其成为一个整体，这使得团队的组织、文化和软件过程都与单纯的开发团队和运维团队有所不同。同时，团队的规模也不可避免的有所增加，降低了团队面对面沟通的效率。DevOps是受到敏捷软件开发的影响而产生的，天然带有敏捷基因并植根于精益思想。然而，敏捷方法的很多理念和实践并不能天然应用于DevOps。例如，常规敏捷方式鼓励着眼当前问题同时通过承担一定程度的技术负债来应对未来的多种可能变化。这种寻求局部最优解的思维方式并不利于打破各个部门之间的壁垒。又如，在敏捷宣言鼓励之下的“重代码轻文档”方式在高频交付中也会面临挑战，等等。另一方面，随着开发和维护的软件系统越来越复杂，规模也越来越大，开发运维团队合并后，必然要求团队规模也相应扩大。一个DevOps团队由于包含了运维人员，安全团队等，整体人员规模会更大，工作和交流更加复杂。敏捷社区提出了SAFe（Scaled Agile Framework来支持更大规模的团队，目前已经列入DevOps相关内容。然而，也有很多人批评SAFe过于复杂，违背了敏捷的基本价值观。从这个意义上说，如何在大规模团队中实施DevOps仍将成为未来一段时间研究者和实践者需要解决的问题。

\section{主要研究内容}
面向高效、高质量、低成本开发和演化软件系统的总体目标，软件开发方法和技术的研究范围涵盖新型程序设计与软件方法学、软件自动化技术、软件复用技术、软件自适应与生长技术、复杂软件分析与建模、智能软件开发方法、嵌入式软件开发方法与技术、复杂系统需求分析方法与技术、软件服务化方法与技术等各个方面。结合应对以上重大挑战问题，主要研究内容将集中在人机物融合场景建模（§4.2.1）、系统自适应需求分析（§4.2.2）、系统内生安全规约获取（§4.2.3）、群智软件生态（§4.2.4）、群智开发方法（§4.2.5）、群智协同演化（§4.2.6）、群智软件支撑环境（§4.2.7）、面向机器编程的代码生成（§4.2.8）、面向人机协同的智能开发环境（§4.2.9）、开发过程建模与优化（§4.2.10）、软件系统运行数据管理（§4.2.11）、安全可信的开发运维一体化（§4.2.12）、开发运维一体化的组织与管理（§4.2.13）、微服务软件架构（§4.2.14）等。

\subsection{人机物融合场景建模}
人机物融合的新型泛在系统，以实现人类社会、信息空间和物理世界的互联互通为目标。在这种应用场景中，计算资源高度泛化，系统能力拓展到包括连接、计算、控制、认知、协同和重构等在内的网络化、协同式和适应性的认知、计算和控制一体的综合能力范畴。需要研究人机物融合的计算环境的认知和建模，特别是对各种实现感知、计算、通信、执行、服务等能力的异构资源的认知的建模；系统研究交互环境的建模理论，包括交互环境静态属性特征和动态行为特征，以及行为约束等多个方面；需要对典型人机物融合场景下泛在应用的本质特征，分别予以有效的场景抽象，研究相应的软件定义方法，以凝练人机物融合应用场景的共性，更有效地管理资源，并适应动态多变的应用场景。

\subsection{系统自适应需求分析}
人机物融合应用场景下，需求以及交互环境的动态变化性和不确定性，使得系统的自适应性成为关键，软件系统的自适应性需求建模和管理成为热点研究课题，其中包括自适应需求的获取，自适应系统的建模，需求、系统模型和交互环境的在线检测和分析，系统能力在线规划和管理等。针对系统环境的开放性、动态变化性和不确定性等，需要对系统及其交互环境在建模和模型管理方面进行综合型研究，在系统环境建模方法，环境现象感知方法，环境事件推理技术，模型的追踪关系和基于追踪关系的协同演化策略，运行时目标驱动的在线优化和系统功能重配置方法，以及系统自适应性机制的度量和评估方法等方面进行深入研究。

\subsection{系统内生安全规约获取}
人机物融合应用场景下，安全作为第一要务是不容置疑的，一方面需要保护人生安全，另一方面需要避免损失，避免破坏环境，安全防护，这些已成为系统强制执行的法律。系统内生安全的实现存在两个阶段，第一阶段是安全特征的构造，安全特性不同与系统的其它功能，需要研究：基于显式环境建模安全关注点分析，支持对安全隐患/环境风险/不合规问题等的识别；研究对系统运行时的时空间协同建模，支持混合的行为建模和认知建模以及人类行为模拟，支持从环境行为模型中发现隐含的风险隐患；研究离散模型和连续模型的融合方法，支持一体化系统验证，以及人在环路中/上系统，以及支持协作和共享的控制器综合。第二阶段是建立内置的安全规约，研究对系统级内置隐私保护和安全控制能力抽象，支持安全能力成为系统可管理的资源，研究面向应用场景的可定义的安全能力配置，系统功能和隐私/安全约束的协调，个性化、可动态配置的隐私/安全约束，以及可追溯可审计的隐私保护/安全控制。

\subsection{群智软件生态}
在群智开发中，参与者群体、开发环境、软件任务、软件制品等多种要素相互作用，是持久驱动软件生产力发展的重要引擎。然而，由于软件的复杂性持续增长、开发过程的开放性持续加大，软件生态的形成与演变具有很强的随机性，未能形成有效的生态构建机理与方法。为此需要重点研究：1）基于博弈论和社会经济学等理论研究开源生态形成与演化的动力学模型，形成“贡献激发、群智汇聚、人才涌现”的良性循环；2）研究面向软件生态的多模态持续激励机制，突破基于区块链等新型技术的群智激励方法；3）研究软件生态的大规模混源代码溯源技术和演化分析方法，突破软件开发供应链的分析识别技术，建立全谱系的群智软件生态供应链模型。通过上述研究，为软件生态构建和演化提供理论指导。

\subsection{群智开发方法}
在动态开放环境下，参与群体的高自主性、任务目标的高变化性，带来群智涌现的不确定性，严重制约了基于群智的软件开发效能。基于“人在回路中”的群智软件生态观，群智软件开发方法需重点关注：（1）研究大规模群体的高效协作机理和模型，突破面向复杂环境的群体协同增强方法；（2）研究碎片化贡献的高效共享与汇聚融合技术，建立群体贡献的高效可信传播体系；（3）突破群智贡献的多维量化评估与度量技术，形成多源群智贡献的高效汇聚与精化收敛方法

\subsection{群智协同演化}
群智软件开发是一种人类智能和机器智能协同融合推动软件系统持续迭代的新方法，如何充分激发人机群智的效能实现软件系统的快速演化，需要重点关注：（1）研究群体行为量化分析与建模方法，建立群智激发汇聚行为轨迹演进模型；（2）研究涵盖代码、开发者、开发社区、软件生态的群智软件开发多维度分析评估方法，突破面向软件开发演化的大数据分析和智能释放技术；（3）研究开发者群体智能与开发大数据机器智能的互补融合、协同演进机制，构建面向软件生态演化的人-机反馈回路。通过上述研究，为群智软件生态演化提供技术支撑。

\subsection{群智软件支撑环境}
以群智软件开发方法和技术为依托，以群智开发生态为理论指导，构建面向群智软件开发与演化的支撑环境，需要重点关注：（1）研究构建面向群智制品和大规模群体的管理、协作、共享与评估等群智开发支撑工具集，有效支持开放群体的高效协同和群智任务的有效管理；（2）研究动态开放环境的群体组织规则与环境协作流程，构建相应的支撑机制和工具，充分释放大规模人-机群体的效能；（3）突破面向新型软件的智能化开发运维一体化技术，构建人机混合智能软件开发与演化的支撑平台，建立针对群智软件开发生态中核心技术和关键节点的支撑和掌控机制，形成覆盖人-机-物的全新软件开发与技术创新生态网络。

\subsection{面向机器编程的代码生成}
机器编程是人机协作编程的基础，而代码生成又是机器编程的核心。从软件的生命周期过程看，机器编程主要在以下场景中起作用：（1）以软件规约为出发点，自动生成满足规约的软件代码；（2）针对软件中存在的错误，自动生成修复代码。从软件规约生成代码本质上是一个搜索过程，即在在程序空间里搜索满足软件规约的程序，然而待搜索的程序空间规模巨大，搜索难以有效进行；同时，程序本身固有的复杂性使得验证代码是否满足规约也存在巨大的效率问题。与从软件规约生成代码相比，自动生成修复代码有明显的特殊性：修复时通常缺乏可以准确刻画正确程序性质的规约，但存在可运行的出错程序，此时代码生成更多地是在已有代码上的修改，而验证更多地通过对比运行修改前后的程序进行。这方面的主要研究内容包括：（1）如何利用海量代码数据加速程序合成中的代码搜索；（2）如何利用海量代码数据加速程序合成中的代码验证；（3）如何利用人类程序员的修复数据完成软件错误的自动修复。

\subsection{面向人机协作的智能开发环境}
人机协作编程的另一个重要基础是高效的智能开发环境，智能开发环境是机器编程技术的集中承载者，也为开发人员提供各种智能服务，同时智能开发环境也是开发人员间交流的通道。在一个智能开发环境中，开发人员应该能够方便地获取各种所需的信息，从而减少对自身大脑信息记忆的依赖；同时，智能开发环境应该能够主动识别开发人员的需求，为开发人员推荐相关的信息或开发动作，比如推荐完成特定开发任务的代码；进一步，作为开发人员间交流的中介，智能开发环境应该保证开发人员间高效顺畅的交互，如果存在可以独立承担开发任务的机器程序员，智能开发环境也应保证人类程序员与机器程序员间的交互；传统的键盘和屏幕并不是人类最习惯的交互机制，更好的交互机制应该是一种综合运用多种感官的多通道交互，智能开发环境应该提供开发人员更习惯的交互机制。因此，这方面的主要研究内容包括：（1）如何帮助开发人员快速查找开发所需的信息；（2）如何针对具体的开发任务推荐可能的开发动作；（3）如何实现开发人员间以及与开发环境间的多通道交互。

\subsection{开发过程建模与优化}
丰富的工具是软件过程实现DevOps化的助推器与基石，工具在有效的优化过程的同时，会产生海量的过程数据。挖掘这些数据并构建模型，以实现过程改进和优化是目前热门的研究领域。早在DevOps出现之前，软件过程建模和优化就是一个研究热点，但数据的缺乏一直是过去相关研究面临的主要挑战。DevOps的盛行，尤其是随着各类工具的普及，问题已经转变为了如何有效挖掘并利用资源库中蕴含的海量数据。有两大类研究值得关注：一类是使用传统过程建模技术为理解、分析以及管控过程提供支持，更进一步的可以实现过程的改进与优化。另一类研究采用机器学习技术，着眼于过程中更具体的点，例如缺陷预测，持续集成结果预测，评审人员推荐等等，能够为提高过程质量、减少资源消耗和缩短交付周期等提供支持。

\subsection{软件系统运行数据管理}
从指标信息、调用链信息以及日志信息入手，通过深入整合与挖掘这三种运维数据信息，来提供更丰富以及高质量的信息，进而提升AIOps的质量与效率，这应该是需要实现的目标。为了达成这个目标，需要开展如下研究。首先，需要研究提升运维数据的质量的方法。在这三类信息中，由于日志信息是非结构化的以及主观的，因此数据的质量并不理想。在日志的生命周期中，需要将日志决策和开发的阶段提前，融入需求开发阶段，并形成日志的开发-运维反馈闭环。辅以自动化日志工具，以此来提高日志的质量以及日志记录的效率。其次，应该提升调用链信息的捕获和存储效率。最后，需要提出一种深度整合三类运维数据的方法。指标信息、调用链信息以及指标信息应该通过特定的算法关联起来，从而提供多维度的运维信息。例如，调用链信息可以与指标信息结合，将各个时间节点的指标信息以调用关系的形式组织起来，进而促进根因分析等AIOps任务。

\subsection{安全和可信的开发运维一体化}
DevOps打破了软件开发与运维团队之间的隔阂，提高了软件部署的频率，但是当运维团队在维护过程中遇到安全问题时仍然需要通过求助安全团队，使用专业的安全工具检测问题来源，分析数据形成解决方案并提交给开发团队最终解决问题，这一过程通常需要较长的时间且伴随有问题扩散的风险。为实现安全且可信的运维，主要的研究内容包括：（1）通过自动化运维以及智能化运维减少运维工作中的一些人工操作，在提升效率的同时避免手工作业所可能产生的错误；（2）对运维过程的监控数据进行分析，及时检测异常的发生，并对问题进行追踪和溯源工作，快速解决问题、避免损失；（3）DevSecOps下的安全运维在持续监控和分析的同时需要建立持续的问题反馈循环，为产品安全性和可行度提供持续的保障。

\subsection{开发运维一体化的组织与管理}
为了缩短软件从产品设计到呈现给最终用户的时间，DevOps整合了软件开发和运维团队，这使得DevOps团队的组织、文化和过程都与单纯开发、运维团队不同。基于DevOps的目标、基础设施变化、质量和安全的挑战、工具链发展现状，DevOps需要解决以下问题：（1）使用经验软件工程的方法，探寻适合DevOps的组织结构和过程实践，并进行验证；（2）如何既能通过团队自组织工作方式提升效率，同时又能够避免由于具体人员技能缺失或管理人员与DevOps团队缺乏信任关系造成的失败，在敏捷与规范之间取得平衡；（3）在大型项目中，使用怎样的组织方式和软件过程，能够使得DevOps项目具有敏捷应对变更的优势以及工作效率。

\subsection{微服务软件架构}
围绕微服务架构有如下几类研究：第一，实现合适粒度的微服务划分方法，主要研究内容包括：（1）基于领域驱动设计方法识别限界上下文以实现高内聚、低耦合的服务；（2）利用遗留系统的现有构件信息识别候选微服务；以及（3）综合利用多种划分策略实现复杂系统的服务划分等。第二，基于微服务架构的快速故障定位和消除，主要研究内容包括：（1）构建更加完善的监控系统，除了基础指标监控功能，实现分布式服务链路追踪和日志聚合分析等高级功能来帮助故障排查和定位；（2）基于AIOps实现智能告警运维，具体来讲通过已经构建的监控系统平台对多种类型数据进行不同形式的采集（有代理和无代理）、处理、存储， 使用并改进机器学习算法对运维数据进行分析预测，实现多种场景的智能告警运维。第三，微服务架构评估，主要研究内容包括：（1）提出面向微服务系统的架构质量评价方法，为微服务系统架构质量的评估过程提供指南，总结供架构评估使用的核查表（checklist）以支持开发、运维微服务系统的实践；（2）初步实现一个微服务系统的验证平台，为软件开发、运维人员和软件组织提供有效的架构决策和实现支持。