第二篇 软件开发方法章的几个微小文字修改。主要意见是应该加几个主要参考文献。
另外,去除了ch3-1的不必要的latex文档头尾,以便放在整书里编译。
This commit is contained in:
parent
41b2ed5ef7
commit
fc06469bfd
|
@ -6,18 +6,18 @@
|
|||
|
||||
人是软件开发成败的决定因素,认知空间中人们长期的积累与计算平台的发展,使得软件开发的社会化和智能化成为必然方向,也为软件开发中人与计算/机器平台的新型关系的建立提出了挑战。网络化、数据化、可视化、虚拟化将改变人在软件开发中的工作方式、合作方式和组织方式,催生出软件开发的各种新方式,包括软件开发终端化和普及化、群智化开发\index{群智化开发}与生态化平台等等。建立新的开发方式以有效适应人机融合的软件生态发展,将是软件开发和平台的未来机遇。
|
||||
|
||||
软件作为智力和人工制品,软件开发属于认知空间范畴,本质上是问题空间、解空间和平台空间之间的转换和映射。随着问题空间和平台空间的泛在化和持续变化,未来软件形态也呈现出泛在性、适应性、演化性、不确定性。特别是复杂多样的不确定性成为软件的固有本质特征,控制而不是消除不确定性使得软件的持续演化和成长成为必然挑战。与传统软件开发相比较,软件的不确定性控制和处理难以在设计时完成,除了面向应用空间,软件开发的设计时与运行时融合要求认知空间与平台空间的协作乃至一体化成为一个趋势。近来的开发运维一体化\index{开发运维一体化}已经有了一个良好的开端。
|
||||
软件作为人工逻辑制品,其开发属于认知空间范畴,本质上是问题空间、解空间和平台空间之间的转换和映射。随着问题空间和平台空间的泛在化和持续变化,未来软件形态也呈现出泛在性、适应性、演化性、不确定性。特别是复杂多样的不确定性成为软件的固有本质特征,控制而不是消除不确定性使得软件的持续演化和成长成为必然挑战。与传统软件开发相比较,软件的不确定性控制和处理难以在设计时完成,除了面向应用空间,软件开发的设计时与运行时融合要求认知空间与平台空间的协作乃至一体化成为一个趋势。近来的开发运维一体化\index{开发运维一体化}已经有了一个良好的开端。
|
||||
|
||||
面向动态变化场景的人机物融合复杂系统\index{人机物融合复杂系统},软件开发面临的首要挑战是融合人机物三元资源、以建模为核心的软件定义\index{软件定义}方法和技术。我们需要构建人机物三元资源及其行为的抽象、观察和度量的新模型和方法,研究基于软件定义方法的元级控制和数据赋能机理,使得软件开发方式(包括设计、构造和保障)从实体建模为主走向实体加链接,从分而治之走向群智聚合,从而有效驾驭各类软件复杂性。
|
||||
|
||||
\section{重大挑战问题}
|
||||
\section{重大挑战问题\xxm{建议本节补充若干主要参考文献引用}}
|
||||
在人机物融合应用场景需求牵引下,软件开发方法和技术研究面临的重大挑战问题主要包括复杂场景分析与建模、群智开发、人机协作编程\index{人机协作编程}和开发运维一体化。
|
||||
|
||||
\subsection{复杂场景分析与建模}
|
||||
人机物融合计算场景的需求在我们的日常生活中已经存在,大到智慧国家、智慧城市,小到网络家电、汽车引擎智能网络控制系统,对这类计算场景的分析和建模存在许多挑战,其中主要的挑战包括如下几个方面。
|
||||
\subsubsection{与日俱增的规模与复杂度}
|
||||
|
||||
首先,从已经出现的支撑人机物融合计算场景的系统来看,其系统的大小和复杂性显著增加。例如,现代汽车中基于软件的功能在不断地持续增加\cite{zhang2017software},比如,2007年经典高端轿车包含大约270个与驾驶员互动的软件实现的功能,而最新的高端轿车包含超过500个这样的功能。轿车软件的规模也在大幅增长。2007年高端轿车的二进制代码量约为66兆字节,而现在这类轿车则含超过1千兆字节的二进制代码。随着软件支持的功能的数量和规模的增加,复杂性也随之增加。这些基于软件的功能要求各个子系统,例如刹车系统、发动机管理系统、驾驶辅助系统等,具备更细粒度的功能,以及子系统之间密集的交互,因而整个系统的复杂性大大增加,对系统的分析和建模需要从方法和技术上得到全面提升。
|
||||
首先,从已经出现的支撑人机物融合计算场景的系统来看,其系统的大小和复杂性显著增加。例如,现代汽车中基于软件的功能在不断地持续增加\cite{zhang2017software}。2007年经典高端轿车包含大约270个与驾驶员互动的软件实现的功能,而最新的高端轿车包含超过500个这样的功能。轿车软件的规模也在大幅增长。2007年高端轿车的二进制代码量约为66兆字节,而现在这类轿车则含超过1千兆字节的二进制代码。随着软件支持的功能的数量和规模的增加,复杂性也随之增加。这些基于软件的功能要求各个子系统,例如刹车系统、发动机管理系统、驾驶辅助系统等,具备更细粒度的功能,以及子系统之间密集的交互,因而整个系统的复杂性大大增加,对系统的分析和建模需要从方法和技术上得到全面提升。
|
||||
|
||||
其次,除了功能数量和规模的提升,对软件分析和建模方法的挑战还来自于软件与硬件、软件与人的交互的紧密性和持续性。首先,软硬件协同\index{软硬件协同}分析和建模成为必须,这类系统的发展大部分是由先进硬件技术驱动的,集成电路的成本、尺寸和能耗的显著降低,和各类嵌入集成电路的、带计算能力的设备的不断增加,使得能通过像调用软件一样灵活地调用设备。另一方面,在硬件设备中嵌入的软件能力,又为许多设备提供了新颖的功能,例如家用电器的网络连接等。这种趋势和挑战要求采用系统的方法来设计具有大量计算节点的大型网络化系统。通过网络将大量物理设备连接起来,这些数量庞大的设备进行实时数据采集,产生了大量的数据,这些数据呈指数级增长,并进行彼此间的信息交互,形成了复杂的网络。这些数据的处理促进了新软件的诞生,系统规模日益增大。在这样一个广泛嵌入各种感知与控制智能设备后的物理世界场景下,系统能够全面地感知环境信息,并智能地为人类提供各种便捷的服务。
|
||||
|
||||
|
@ -37,15 +37,15 @@
|
|||
|
||||
人机物融合计算场景下,软件系统分析和建模的困难还来自于当前的需求相关者(即领域专家,最终用户和客户)无法提供完整和正确的能力要求。许多创新应用,如微信、在线购物等一些受欢迎的应用程序,都是由技术的发展和产品设计师的创新思维驱动的,而不是最初的需求相关者所要求的。信息技术飞速发展的时代,领域专家和最终用户无法提出超出想象的技术发展,不能预测技术的发展趋势,如何在软件系统分析和建模方法中,支持创新需求的引入,或提供对创新需求的包容手段是一个重要的挑战。
|
||||
|
||||
\subsubsection{系统内生安全性}
|
||||
对人机物融合系统而言,安全和隐私保护是第一要务,首先不容置疑的是系统安全性,系统在和人和物理环境直接交互的过程,需要保护人生安全,需要保护其交互环境,不施加具有破坏性的操作,避免交互环境受到损失;其次,由于其直接和人打交道,采集和分享人的信息,使得系统的隐私保护成为计算系统需要强制执行的法律,欧盟、美国等都出台了个人隐私数据或网络隐私保护法,中国也出台了个人信息保护法。与开发功能性需求是申明系统要做什么不同,使人机物融合系统具有内生的安全性和遵循隐私保护法,其系统需求开发的难点和挑战是回答以下几个问题:如何避免在系统操作回路中/上的人的安全隐患?如何避免系统可能对交互环境造成的伤害/破坏?如何避免不在系统操作回路上的人的安全隐患?如何避免泄露不在系统操作回路上的人的隐私。
|
||||
\subsubsection{计算与控制的交互与融合}
|
||||
人机物融合场景下,大量系统不再是单纯等待外界输入后做简单响应。在以轨道交通、航空航天、医疗卫生、工业控制等为代表的核心系统软件中,相关系统行为都包含了连续实时计算与离散决策控制之间的交互与融合。以列控系统为例,列车运行中相关运行参数物理量,如车速、位置、外界风速、轨道坡度等取值在连续变化。基于这些运行参数取值的实时监控与预测计算,列控系统会在各运行模式间切换,比如加速,减速等。然而列车不同的运行模式也会导致这些物理量变化规律发生改变。在这类情况下,系统的连续计算和离散控制两种行为相互依赖、相互影响、彼此互为依存、息息相关。因此,如何在开放环境下准确构建系统离散与连续交织行为模型成为重要挑战。
|
||||
\subsubsection{系统内生安全性}
|
||||
对人机物融合系统而言,安全和隐私保护是第一要务,首先不容置疑的是系统安全性,系统在和人和物理环境直接交互的过程,需要保护人身安全,需要保护其交互环境,不施加具有破坏性的操作,避免交互环境受到损失;其次,由于其直接和人打交道,采集和分享人的信息,使得系统的隐私保护成为计算系统需要强制执行的法律,欧盟、美国等都出台了个人隐私数据或网络隐私保护法,中国也出台了个人信息保护法。与开发功能性需求是申明系统要做什么不同,使人机物融合系统具有内生的安全性和遵循隐私保护法,其系统需求开发的难点和挑战是回答以下几个问题:如何避免在系统操作回路中/上的人的安全隐患?如何避免系统可能对交互环境造成的伤害/破坏?如何避免不在系统操作回路上的人的安全隐患?如何避免泄露不在系统操作回路上的人的隐私?等。
|
||||
\subsubsection{计算与控制的交互与融合}
|
||||
人机物融合场景下,大量系统不再是单纯等待外界输入后做简单响应。在以轨道交通、航空航天、医疗卫生、工业控制等为代表的核心系统软件中,相关系统行为都包含了连续实时计算与离散决策控制之间的交互与融合。以列控系统为例,列车运行中相关运行参数物理量,如车速、位置、外界风速、轨道坡度等取值在连续变化。基于这些运行参数取值的实时监控与预测计算,列控系统会在各运行模式间切换,比如加速,减速等。然而列车不同的运行模式也会导致这些物理量变化规律发生改变。在这类情况下,系统的连续计算和离散控制两种行为相互依赖、相互影响、彼此互为依存、息息相关。因此,如何在开放环境下准确构建系统离散与连续交织行为模型成为重要挑战。
|
||||
|
||||
|
||||
|
||||
\subsection{群智开发}
|
||||
互联网\index{互联网}技术的发展,使得人类群体打破物理时空限制开展大规模协作成为可能。新型编程技术(包括新型高级编程语言、智能化编程工具和技术等)的出现则降低了编程开发的参与门槛。软件开发从一个纯粹的生产性活动演变为一个涉及到多种要素紧密关联的社会性活动;软件也从相对独立的产品演变为多种元素相互依赖、持续演化的生态。在软件生态系统中,作为软件开发活动的关键要素,“人”在其中发生了显著变化:参与者规模的变化-软件开发活动的参与者规模由过去的公司/组织内部封闭环境下的数百至数万人,演变为软件生态系统\index{软件生态系统}中开放环境下通过互联网联接的数万数十万人;参与者群体多样类型的变化-软件开发活动的参与者由过去的主要是开发者,演变为软件生态系统中开发者、用户、管理者、投资人等多种不同类型的群体深度参与,共同驱动软件生态系统的发展演化;参与者个体多重角色的变化-软件开发活动中参与个体的角色从单纯的软件开发者或使用者等单一角色,演变为软件生态系统的参与者和推动者等多重角色,每个参与个体都成为软件生态中的组成部分,与软件生态共同成长演化\cite{zhang2017software}。
|
||||
互联网\index{互联网}技术的发展,使得人类群体打破物理时空限制开展大规模协作成为可能。新型编程技术(包括新型高级编程语言、智能化编程工具和技术等)的出现则降低了编程开发的参与门槛。软件开发从一个纯粹的生产性活动演变为一个涉及到多种要素紧密关联的社会性活动;软件也从相对独立的产品演变为多种元素相互依赖、持续演化的生态。在软件生态系统中,作为软件开发活动的关键要素,“人”在其中发生了显著变化:参与者规模的变化---软件开发活动的参与者规模由过去的公司/组织内部封闭环境下的数百至数万人,演变为软件生态系统\index{软件生态系统}中开放环境下通过互联网联接的数万数十万人;参与者群体多样类型的变化---软件开发活动的参与者由过去的主要是开发者,演变为软件生态系统中开发者、用户、管理者、投资人等多种不同类型的群体深度参与,共同驱动软件生态系统的发展演化;参与者个体多重角色的变化---软件开发活动中参与个体的角色从单纯的软件开发者或使用者等单一角色,演变为软件生态系统的参与者和推动者等多重角色,每个参与个体都成为软件生态中的组成部分,与软件生态共同成长演化\cite{zhang2017software}。
|
||||
|
||||
群智开发是一种通过互联网联接和汇聚大规模群体智能\index{群体智能}、实现高效率高质量软件开发的群体化方法,主要包括:微观个体的激发、宏观群体的协作、全局群智的汇聚以及持续的成长演化等不同维度。在生态观下,软件开发的关注点从“人在系统外”的软件系统构建发展为“人在回路中”的软件生态构建。开源软件\index{开源软件}、软件众包\index{软件众包}以及应用市场等作为群智开发的原始形态快速发展,释放出不同于传统软件开发模式的强大生产力,展现了群智开发所蕴含的巨大潜力\cite{wang2018harnessing}。但是,如何高效激发和稳态汇聚大规模群体智能,确保群体智能在软件开发活动中可控形成和重复出现,构建持续健康演化的软件生态,是群智开发面临的核心挑战。
|
||||
|
||||
|
@ -55,18 +55,18 @@
|
|||
|
||||
\subsubsection{群智任务的度量分解与群智贡献的汇聚融合}
|
||||
|
||||
软件开发本身是一项创作与生产深度融合的活动,具有很强的开放性和灵活性。在面对一个具有更强不确定性和差异性的大规模群体时,如何将一个复杂的软件开发任务分解成一组简单任务,并建立起开发任务与参与个体的最优适配,实现个体智能的最大释放?此外,开放参与下的软件开发具有群体贡献碎片化、群智结果不可预期性等特点,如何量化度量群智贡献的质量和价值、构建有效的群智贡献迭代精化闭环、实现多源碎片化群智贡献的可信传播与汇聚收敛,形成高效群智涌现?
|
||||
软件开发本身是一项创作与生产深度融合的活动,具有很强的开放性和灵活性。在面对一个具有更强不确定性和差异性的大规模群体时,如何将一个复杂的软件开发任务分解成一组简单任务,并建立起开发任务与参与个体的最优适配,实现个体智能的最大释放?此外,开放参与下的软件开发具有群体贡献碎片化、群智结果不可预期性等特点,如何量化度量群智贡献的质量和价值、构建有效的群智贡献迭代精化闭环、实现多源碎片化群智贡献的可信传播与汇聚收敛,形成高效群智涌现?这些都是有待深入研究的问题。
|
||||
|
||||
\subsubsection{群智开发生态的认知度量和成长演化}
|
||||
|
||||
在群智开发中,参与者群体、代码与社区等多种要素共同形成一个持续发展的生态,并在个体激发和群智融合基础上,通过评估和反馈推动生态持续成长演化。在此环境下,软件开发关注点不再仅仅是孤立的、静止的参与者个体或者代码,更需要从“联系”的、“发展”的视角去分析和认识整个群智生态。面临以下两个方面的挑战:一是如何认知和计算软件开发中的群智。群智激发和汇聚是形成群智开发生态的关键,如何深入理解和认识群智激发汇聚和本质,并从激发和汇聚的角度建立群体智能的效能评估方法和评测指标,从而为群智开发的成长演化提供评价准则和度量体系?二是如何推动群智生态的持续成长演化。群智生态中各个要素相互依赖、紧密交互,如何建立多元高效的主动反馈机制,在基于群智度量体系对群智过程开展量化度量的基础上对参与群体进行实时反馈和持续引导,驱动群智生态的正向演化?
|
||||
在群智开发中,参与者群体、代码与社区等多种要素共同形成一个持续发展的生态,并在个体激发和群智融合基础上,通过评估和反馈推动生态持续成长演化。在此环境下,软件开发关注点不再仅仅是孤立的、静止的参与者个体或者代码,更需要从“联系”的、“发展”的视角去分析和认识整个群智生态。这里面临以下两个方面的挑战:一是如何认知和计量软件开发中的群智。群智激发和汇聚是形成群智开发生态的关键,如何深入理解和认识群智激发汇聚和本质,并从激发和汇聚的角度建立群体智能的效能评估方法和评测指标,从而为群智开发的成长演化提供评价准则和度量体系?二是如何推动群智生态的持续成长演化。群智生态中各个要素相互依赖、紧密交互,如何建立多元高效的主动反馈机制,在基于群智度量体系对群智过程开展量化度量的基础上对参与群体进行实时反馈和持续引导,驱动群智生态的正向演化?
|
||||
|
||||
\subsection{人机协作编程}
|
||||
在现有的软件开发活动中,几乎每一行程序(高级语言编写的代码)都需要人类程序员手工编写,随着对软件的需求进一步地增长,以及软件复杂度进一步地提升,这种几乎全手工的编程方式将成为制约计算机行业发展的瓶颈。只有大幅度提升机器编程的占比,并将程序员的主要工作更多地放在少数对创造性具有极高要求的活动上,才能够突破这一瓶颈。因此,需要将程序员统领开发环境完成编程任务的模式转变为程序员与机器各司其职又相互协作完成编程任务的模式。实现人机协作编程的挑战主要来自两个方面:1、如何提升机器编程的能力;2、如何实现人机无障碍协作。
|
||||
|
||||
提升机器编程的能力是实现人机协作编程的基础,软件自动化是提升机器编程能力的主要技术手段。人们对软件自动化的探索几乎是伴随着软件的出现而开始的,由于早期的软件开发(编程)是异常繁琐易错的工作,人们很早就开始考虑将编程中机械性的工作交给机器完成。然而,软件自动化也一直没有完全达到人们的期望,导致软件开发长期属于严重依赖开发人员个人能力的活动。传统的软件自动化技术以严格的规约作为输入,通过机器将规约翻译成程序代码或者通过搜索技术找到符合规约的程序代码:前者的典型代表是编译器,也是软件自动化方面到目前为止最为成功的尝试,但随着抽象层次的提高,人们发现很难通过固定的规则完成所有可能的翻译;后者的典型代表是程序合成,但由于程序空间过于庞大,目前能够通过搜索获得程序通常仅限于规模很小的程序。近年来,随着数据的广泛积累,数据驱动的方式在很多领域取得了前所未有的成功,类似地,长期累积的海量代码数据为软件自动化带来了新的可能性,为提升机器编程能力带来了新的希望。数据驱动的软件自动化可以利用已有代码数据中总结出来的规律指导搜索,从而提升程序合成的效率,同时这种不依赖严格推理的模式又易于处理半形式化甚至非形式化的规约,从而扩大软件自动化技术的适用范围。由于程序空间是无限空间,已有程序代码在整个空间里仍然很稀疏,而程序代码又受到问题领域、技术进步、开发者习惯的影响展现出很强的异质性,如何从已有程序代码总结规律存在巨大的挑战。
|
||||
|
||||
与人工编程相比,机器编程的优势在于机器编程可以利用计算机的强大计算能力,劣势在于机器编程主要从已有代码中学习,缺乏有效处理边角信息的能力,因此高效的人机协作将能更好地发挥两者的优势。支持高效人机互动的开发环境\index{开发环境}一直是软件工程关注的重点之一,最早的开发环境只是一系列工具的简单堆叠,真正意义上的开发环境是在上世纪八十年代以后发展起来的,这类开发环境的主要特点在于,开发者是整个开发环境的主导,开发环境是开发者的操控台和延伸,进入到新世纪开发环境有两个新的发展趋势:1、开发环境中开始出现一些智能服务(如代码推荐等),虽然能够进入主流开发环境的智能服务仍十分有限,但学术界研究的智能工具多以开发环境的插件形式展现;2、开发环境开始支持开发者间的交互,虽然这与开发者间远程协作需求的增长有关(短程协作中开发者可以进行面对面的交流),但却为探索多开发者协同提供了有益尝试。为了满足人机协作编程的需要,开发环境需要应对以下两方面的挑战:1、建立开发者对机器编程的信任关系:在开发者主导的环境中开发者更多依赖自己的主观判断,但在人机协作环境中开发者完全可控的范围缩小将更依赖机器编程,如果开发者不能确信机器编程能否完成特定任务,就会严重影响开发效率;2、实现人机多渠道交互:现有开发环境中的人机交互以及开发者间的交互方式主要以文本方式进行,而人类通常习惯同时以多种方式进行交流,这样才能更好激发开发者的创造力。
|
||||
与人工编程相比,机器编程的优势在于机器编程可以利用计算机的强大计算能力,劣势在于机器编程主要从已有代码中学习,缺乏有效处理边角信息的能力,因此高效的人机协作将能更好地发挥两者的优势。支持高效人机互动的开发环境\index{开发环境}一直是软件工程关注的重点之一,最早的开发环境只是一系列工具的简单堆叠,真正意义上的开发环境是在上世纪八十年代以后发展起来的,这类开发环境的主要特点在于,开发者是整个开发环境的主导,开发环境是开发者的操控台和延伸,进入到新世纪开发环境有两个新的发展趋势:1、开发环境中开始出现一些智能服务(如代码推荐等),虽然能够进入主流开发环境的智能服务仍十分有限,但学术界研究的智能工具多以开发环境的插件形式展现;2、开发环境开始支持开发者间的交互,虽然这与开发者间远程协作需求的增长有关(本地协作中开发者可以进行面对面的交流),但却为探索多开发者协同提供了有益尝试。为了满足人机协作编程的需要,开发环境需要应对以下两方面的挑战:1、建立开发者对机器编程的信任关系:在开发者主导的环境中开发者更多依赖自己的主观判断,但在人机协作环境中开发者完全可控的范围缩小将更依赖机器编程,如果开发者不能确信机器编程能否完成特定任务,就会严重影响开发效率;2、实现人机多渠道交互:现有开发环境中的人机交互以及开发者间的交互方式主要以文本方式进行,而人类通常习惯同时以多种方式进行交流,这样才能更好激发开发者的创造力。
|
||||
|
||||
\subsection{开发运维一体化}
|
||||
软件开发是人类的一项高复杂度的集体智力活动,其现实问题的复杂度反映到开发中主要表现为架构、过程、技术和组织四个维度上的复杂度,它们往往紧密地交织纠缠在一起并相互转化。软件工程在这四个维度上发展趋势,即架构逐渐去中心化,技术趋于平台化、自动化和虚拟化,过程趋于增量和迭代,组织趋于小而自治,开发运维一体化(DevOps)集中体现了这些发展趋势的高阶形态。随着互联网化和服务化的高度发展和走向成熟使得未来的软件更加需要具备持续(Continuous)的特征。这种持续性将覆盖从商业策划、开发到运维以及演化的所有环节,使得未来软件系统像具有生命一般:在持续稳定提供服务的同时,软件系统的边界、发展走向等不再固化,而是始终处在不断变化和适应之中。持续性与上述的架构、过程、技术与组织四个维度的复杂性交织在一起,再叠加性能、安全等质量要求和实效性要求等,使得未来的软件系统的开发和运维面临诸多的挑战,这就需要我们在原则、方法、实践以及工具层面都做要充分的应对。
|
||||
|
@ -75,10 +75,10 @@
|
|||
作为DevOps产生的技术和平台基础,基础设施(Infrastructure)可能是未来DevOps能够发挥更大作用的关键环节。然而,如何匹配软件系统运行需求(或者企业需求)来构建适用的基础设施一直是需要重点关注的话题。值得关注的几个挑战包括:1)混合云\index{混合云},即为了更好的适应各种业务场景,混合云是一种合理的选择,但是由此带来的异构、安全、可扩展等方面的挑战不容忽视;2)边缘计算,即为了尽可能减少数据传输代价,就近提供计算服务是一种选择,但是,这会大大增加基础设施的复杂程度,带来软件系统部署和维护方面的巨大挑战。3)基础设施自动化和智能化,即提供自动化和智能化类的处理流程来进行基础设施的管理和维护。现有IT基础设施和环境往往已经足够复杂,同时也缺乏跨系统、平台以及流程的可见性,叠加基础设施、运行其上的软件系统和业务往往都是紧耦合的,这些因素都给自动化和智能化带来了巨大挑战。此外,为基础设施注入内建安全机制等也都是未来支撑DevOps发展的IT基础设施亟待解决的挑战。
|
||||
|
||||
\subsubsection{搭建智能化流水线}
|
||||
DevOps 持续高效高质量的交付有赖于高度自动化支持工具的支持,自动化也是获得快速反馈的关键。鉴于DevOps自动化支持工具涉及多个阶段,种类繁多,数量上已达数千种,从诸多关系复杂的工具中理解和选择合适的工具集合来搭建流水线对 DevOps 实践者来讲至关重要,但也非常具有挑战性。未来,部分重要的基础性工具将向少数较成熟的工具收敛(如在持续构建、自动化部署、服务治理等方面),但是,更多的DevOps的自动化支持工具将向更加专业化发展。即构建的流水线往往面向特定应用领域(例如金融行业对安全性和合规性有着极高要求)或包含其他专业组建(例如,人工智能、大数据等),因而,如果提供开箱即用的工具链方案,帮助企业选择并定制适合其业务的DevOps工具链是一个巨大的挑战。此外,随着软件项目的持续进展,DevOps流水线会产生大量的数据,例如,工具链自身产生的数据,在研软件系统在验证过程中产生的数据以及DevOps项目执行产生的数据等等。如何从流程与数据两个维度打通,提供以DevOps流水线为基础的开发运维一体化协作平台,进而提升其智能化水平,在此基础上提升DevOps实践的效率和质量,同样也是为了支持前文所述的持续性,从工具链和生产环境角度需要需要解决的重大挑战之一。
|
||||
DevOps 持续高效高质量的交付有赖于高度自动化支持工具的支持,自动化也是获得快速反馈的关键。鉴于DevOps自动化支持工具涉及多个阶段,种类繁多,数量上已达数千种,从诸多关系复杂的工具中理解和选择合适的工具集合来搭建流水线对 DevOps 实践者来讲至关重要,但也非常具有挑战性。未来,部分重要的基础性工具将向少数较成熟的工具收敛(如在持续构建、自动化部署、服务治理等方面),但是,更多的DevOps的自动化支持工具将向更加专业化发展。即构建的流水线往往面向特定应用领域(例如金融行业对安全性和合规性有着极高要求)或包含其他专业组建(例如,人工智能、大数据等),因而,如果提供开箱即用的工具链方案,帮助企业选择并定制适合其业务的DevOps工具链是一个巨大的挑战。此外,随着软件项目的持续进展,DevOps流水线会产生大量的数据,例如,工具链自身产生的数据,在研软件系统在验证过程中产生的数据以及DevOps项目执行产生的数据等等。如何将流程与数据两个维度打通,提供以DevOps流水线为基础的开发运维一体化协作平台,进而提升其智能化水平,在此基础上提升DevOps实践的效率和质量,同样也是为了支持前文所述的持续性,从工具链和生产环境角度需要需要解决的重大挑战之一。
|
||||
|
||||
\subsubsection{微服务化架构演化策略和评估手段}
|
||||
微服务\index{微服务}化是支持前文提及的持续性要求的必备条件。软件系统的微服务化要求软件系统的各个模块或服务间的耦合进一步降低,从而在新版本发布或者部分服务出现问题时不会影响到系统其它部分。企业系统架构的微服务化以更好地支持DevOps已成为行业共识和趋势,然而在演化过程中却面临诸多挑战。首先,如何进行合理的服务划分,即将软件系统拆分成多个独立自治且协同合作的服务,是微服务应用实现敏捷、灵活和高可扩展的先决条件,也是微服务领域的一项严峻挑战。其次,虽然服务拆分为开发和维护提供诸多便利,但在另一方面,服务数量的增加也带来了系统整体测试复杂度的增长。例如,当采用微服务架构之后,系统对远程依赖项的依赖较多,而对进程内组件的依赖较少,因此测试策略和测试环境需要适应这种变化。微服务化的系统不仅需要保证组件内部的正确性,还需要通过契约测试等保证组件间通信和交互的正确性,使得众多微服务能够真正实现协同工作。相应地,微服务联调、日志分析与故障定位、自动化监控告警与治理策略等是当前以及未来较长时间内的研究中需要探索的迫切问题。此外,缺乏普遍适用的架构演化评估手段也是当前面临的挑战。微服务架构并不一定适合所有的企业情况,因此,在演化过程中,应该通过哪些角度去判断架构拆分的效果?如何建立这些角度与业务需求之间的对应关系?如何度量微服务拆分效果并及时给出建议(包括补充替代的架构形式)等都存在若干亟需解决的问题。
|
||||
微服务\index{微服务}化是支持前文提及的持续性要求的必备条件。软件系统的微服务化要求软件系统的各个模块或服务间的耦合进一步降低,从而在新版本发布或者部分服务出现问题时不会影响到系统其它部分。企业系统架构的微服务化以更好地支持DevOps已成为行业共识和趋势,然而在演化过程中却面临诸多挑战。首先,如何进行合理的服务划分,即将软件系统拆分成多个独立自治且协同合作的服务,是微服务应用实现敏捷、灵活和高可扩展的先决条件,也是微服务领域的一项严峻挑战。其次,虽然服务拆分为开发和维护提供诸多便利,但在另一方面,服务数量的增加也带来了系统整体测试复杂度的增长。例如,当采用微服务架构之后,系统对远程依赖项的依赖较多,而对进程内组件的依赖较少,因此测试策略和测试环境需要适应这种变化。微服务化的系统不仅需要保证组件内部的正确性,还需要通过契约测试等保证组件间通信和交互的正确性,使得众多微服务能够真正实现协同工作。相应地,微服务联调、日志分析与故障定位、自动化监控告警与治理策略等是当前以及未来较长时间内的研究中需要探索的迫切问题。此外,缺乏普遍适用的架构演化评估手段也是当前面临的挑战。微服务架构并不一定适合所有的企业情况,因此,在演化过程中,应该通过哪些角度去判断架构拆分的效果?如何建立这些角度与业务需求之间的对应关系?如何度量微服务拆分效果并及时给出建议(包括补充替代的架构形式)等方面都存在若干亟需解决的问题。
|
||||
|
||||
\subsubsection{DevOps高频交付带来的质量和安全问题}
|
||||
质量和安全一直都不是新问题。然而,在DevOps语境下,在高水平自动化支持下的快速高频交付是维系持续性的基础,但同时也使得传统的质量和安全问题都有了新的含义和内容。例如,通过各类工具来实现自动化验证和确认是DevOps实践中的不二选择。然而,现有工具在发现并且消除缺陷和隐患的效率和效能方便并不完全令人满意,在快节奏和高度自动化的交付过程中,以往的交叉检验和人工分析等质量手段往往也被略去,不可避免地增加了很多质量风险。大量研究和实践表明,DevOps和Security合规往往在实践中处于天然对立关系,这种对立不是通过“构造”DevSecOps一个词汇能解决的。如何协调上述的对立是一个棘手问题。其次,现代软件系统的弱点(Vulnerability)往往有多种来源和根本原因,例如来自上述基础设施的安全威胁、DevOps的快节奏所导致的各种妥协、质量缺陷、大量第三方组件的安全威胁、自动化运维中的安全隐患、企业文化(流程、人员技能和意识等)导致的安全疏漏等等。所谓百密一疏,尽管有一些工具、方法以及实践可以一定程度上缓解上述各种威胁带来的压力,但显然在效果和效率方面还有一些不足。从这个意义上说,退而求其次的方式是采取事后方式——通过监控系统运行过程尤其是通过分析系统异常来辅助发现安全风险。但是,这种方式还是有两大急需解决的难题,即1)如何产生可靠的高质量运行相关的数据(例如日志信息)以及2)如何应用先进的技术(例如大数据、AI技术等)提升对数据的利用效率和分析数据发现质量和安全性风险的能力。
|
||||
|
@ -98,7 +98,7 @@ DevOps整合了开发团队与运维团队,使其成为一个整体,这使
|
|||
人机物融合应用场景下,需求以及交互环境的动态变化性和不确定性,使得系统的自适应性成为关键,软件系统的自适应性需求建模和管理成为热点研究课题,其中包括自适应需求的获取,自适应系统的建模,需求、系统模型和交互环境的在线检测和分析,系统能力在线规划和管理等。针对系统环境的开放性、动态变化性和不确定性等,需要对系统及其交互环境在建模和模型管理方面进行综合型研究,在系统环境建模方法,环境现象感知方法,环境事件推理技术,模型的追踪关系和基于追踪关系的协同演化策略,运行时目标驱动的在线优化和系统功能重配置方法,以及系统自适应性机制的度量和评估方法等方面进行深入研究。
|
||||
|
||||
\subsection{系统内生安全规约获取}
|
||||
人机物融合应用场景下,安全作为第一要务是不容置疑的,一方面需要保护人生安全,另一方面需要避免损失,避免破坏环境,安全防护,这些已成为系统强制执行的法律。系统内生安全的实现存在两个阶段,第一阶段是安全特征的构造,安全特性不同与系统的其它功能,需要研究:基于显式环境建模安全关注点分析,支持对安全隐患/环境风险/不合规问题等的识别;研究对系统运行时的时空间协同建模,支持混合的行为建模和认知建模以及人类行为模拟,支持从环境行为模型中发现隐含的风险隐患;研究离散模型和连续模型的融合方法,支持一体化系统验证,以及人在环路中/上系统,以及支持协作和共享的控制器综合。第二阶段是建立内置的安全规约,研究对系统级内置隐私保护和安全控制能力抽象,支持安全能力成为系统可管理的资源,研究面向应用场景的可定义的安全能力配置,系统功能和隐私/安全约束的协调,个性化、可动态配置的隐私/安全约束,以及可追溯可审计的隐私保护/安全控制。
|
||||
人机物融合应用场景下,安全作为第一要务是不容置疑的,一方面需要保护人身安全,另一方面需要避免损失,避免破坏环境,安全防护,这些已成为系统强制执行的法律。系统内生安全的实现存在两个阶段,第一阶段是安全特征的构造,安全特性不同与系统的其它功能,需要研究:基于显式环境建模安全关注点分析,支持对安全隐患/环境风险/不合规问题等的识别;研究对系统运行时的时空间协同建模,支持混合的行为建模和认知建模以及人类行为模拟,支持从环境行为模型中发现隐含的风险隐患;研究离散模型和连续模型的融合方法,支持一体化系统验证,以及人在环路中/上系统,以及支持协作和共享的控制器综合。第二阶段是建立内置的安全规约,研究对系统级内置隐私保护和安全控制能力抽象,支持安全能力成为系统可管理的资源,研究面向应用场景的可定义的安全能力配置,系统功能和隐私/安全约束的协调,个性化、可动态配置的隐私/安全约束,以及可追溯可审计的隐私保护/安全控制。
|
||||
|
||||
\subsection{群智软件生态}
|
||||
在群智开发中,参与者群体、开发环境、软件任务、软件制品等多种要素相互作用,是持久驱动软件生产力发展的重要引擎。然而,由于软件的复杂性持续增长、开发过程的开放性持续加大,软件生态的形成与演变具有很强的随机性,未能形成有效的生态构建机理与方法。为此需要重点研究:1)基于博弈论和社会经济学等理论研究开源生态形成与演化的动力学模型,形成“贡献激发、群智汇聚、人才涌现”的良性循环;2)研究面向软件生态的多模态持续激励机制,突破基于区块链等新型技术的知识产权共享与群智激励方法;3)研究软件生态的大规模混源代码溯源技术和演化分析方法,突破软件开发供应链的分析识别技术,建立全谱系的群智软件生态供应链模型。通过上述研究,为软件生态构建和演化提供理论指导。
|
||||
|
|
12
Ch3-1.tex
12
Ch3-1.tex
|
@ -1,10 +1,5 @@
|
|||
\documentclass[10pt]{article}
|
||||
\usepackage[usenames]{color} %pour la couleur
|
||||
\usepackage{amssymb} %maths
|
||||
\usepackage{amsmath} %maths
|
||||
\usepackage[utf8]{inputenc} %utile pour taper directement les caractères accentués
|
||||
\begin{document}
|
||||
\[% !TEX root = main.tex
|
||||
% !TEX root = main.tex
|
||||
|
||||
%\chapter{政策建议}
|
||||
|
||||
|
||||
|
@ -81,6 +76,3 @@
|
|||
\item 培育开源生态:培育基于开源模式的公益性生态环境建设,采取“参与融入、蓄势引领”的开源策略(“参与融入”针对国际成熟开源社区,“蓄势引领”则从中文开源社区建设切入),发展开源软件生态,并以其为抓手提升我国在信息技术领域的核心竞争力和国际影响力。
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
\]
|
||||
\end{document}
|
Loading…
Reference in New Issue