update for haodan
This commit is contained in:
parent
54a3dcf47c
commit
0d43291997
|
|
@ -1,15 +1,14 @@
|
|||
% !TEX root = main.tex
|
||||
|
||||
\section{软件工程的诞生}
|
||||
\section{概述}
|
||||
1968年，在德国的一个叫做Garmisch的小镇上，由北大西洋公约组织（NATO）科学委员会主导召开了一个小型研讨会，有来自11个国家的50位代表参加。会议的议题是如何应对当时面临的所谓“软件危机”\index{软件危机}。在这个研讨会上诞生了“软件工程”这个学科领域~\cite{naur1968software}。这里，软件危机是指，在所需时间内编写出有用且高效的计算机程序存在很大困难，导致软件开发出现许多问题。Dijkstra在其会议报告中提到~\cite{Dijkstra:1972}：软件危机的主要原因是因为机器变得越来越强大，强大了好几个数量级！如果没有计算机，就没有编程问题; 如果只有一些比较弱的计算机，编程就是解决简单的问题，当有了能力巨大的计算机，编程就需要解决同样巨大的问题。软件危机正是因为计算机能支持的计算能力和人对软件的预期，远远超出了程序员开发的软件能够有效利用的能力，以及程序员利用编程手段来驾驭现实问题的能力。
|
||||
|
||||
这个研讨会上提到的软件危机有很多种形式，比如软件开发效率低（如，项目超预算，项目时间过长，软件滞后交付），软件质量差（如，很多方面不符合要求），项目难以管理（如，代码难以维护），等等。所讨论的问题，涉及软件开发的方方面面，包括，软件与硬件的关系、软件的设计、软件的生产、软件的分发、以及软件的服务等。这次会议成为软件工程\index{软件工程}学科的奠基性会议，所讨论的核心议题也成为软件工程学科经久不衰的开放性挑战问题，比如：（1）获取正确的软件需求；（2）设计合适的系统架构；（3）正确和有效地实现软件；（4）验证软件的质量；（5）长期维护具有目标功能和高代码质量的软件系统。
|
||||
这个研讨会上提到的软件危机有很多种形式，比如软件开发效率低（如，项目超预算、项目时间过长、软件滞后交付）、软件质量差（如，很多方面不符合要求）、项目难以管理（如，代码难以维护）等等。所讨论的问题，涉及软件开发的方方面面，包括，软件与硬件的关系、软件的设计、软件的生产、软件的分发、以及软件的服务等。这次会议成为软件工程\index{软件工程}学科的奠基性会议，所讨论的核心议题也成为软件工程学科经久不衰的开放性挑战问题，比如：（1）获取正确的软件需求；（2）设计合适的系统架构；（3）正确和有效地实现软件；（4）验证软件的质量；（5）长期维护具有目标功能和高代码质量的软件系统。
|
||||
|
||||
1986 年，布鲁克斯(Brooks) 给出了“软件开发没有银弹”的预言~\cite{Brooks:1987}，即由于软件本质上的复杂性，在未来10 年内，不存在任何技术或方法能够使软件生产力提升10 倍以上。1995 年，布鲁克斯在重新发行的《人月神话》纪念版中再次重申，“软件开发没有银弹”的预言在下一个10 年仍然成立~\cite{brooks1995the}。布鲁克斯的观点得到了软件开发实践者和研究者的广泛关注和讨论。虽然有学者曾经宣称某项技术或方法有可能成为“银弹”，但实践表明这些技术或方法后来都没有能成为“银弹”。
|
||||
|
||||
随着信息技术的发展，软件技术的应用范围不断扩大，应用领域不断深入，50年前的软件和现代软件已经不可同日而语，在最初出现软件的时候，没有人能预计到现在人们对软件的期望，也没有人能想象出通过互联网\index{互联网}和物联网\index{物联网}，未来人机物融合\index{人机物融合}系统将会在各类场合服务于广大民众。50年前的核心挑战仍然还是软件工程当前的核心挑战，问题的表述几乎没有变化，只是被赋予了不同的内涵。“软件开发没有银弹” 的预言仍是软件工程研究者和实践者不可逾越之“墙”。
|
||||
随着信息技术的发展，软件技术的应用范围不断扩大，应用领域不断深入，50年前的软件和现代软件已经不可同日而语，在最初出现软件的时候，没有人能预计到现在人们对软件的期望和依赖，也没有人能想象出通过互联网\index{互联网}和物联网\index{物联网}，未来人机物融合\index{人机物融合}系统将会在各类场合服务于广大民众。50年前的核心挑战仍然还是软件工程当前的核心挑战，问题的表述几乎没有变化，只是被赋予了新的不同的内涵。“软件开发没有银弹” 的预言仍是软件工程研究者和实践者不可逾越之“墙”。
|
||||
|
||||
\section{软件工程内涵和知识结构}
|
||||
软件工程（Software Engineering） 是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科~\cite{张效祥2005计算机科学技术百科全书}。其主要强调的是，是用\textbf{工程化}和\textbf{系统化}的方法进行\textbf{软件开发}~\cite{Laplante:2007}。
|
||||
|
||||
软件工程关注软件生产各个方面~\cite{IanSommerville:1982}，以下广泛流行的说法从不同的角度表述了软件工程的主要关注点，比如：
|
||||
|
|
@ -42,12 +41,6 @@
|
|||
|
||||
综上所述，软件工程要解决的问题是\textbf{如何高效高质地开发出符合要求的产品}。其中包含三个方面的含义。第一，软件工程的产出是一类产品，其产品形态是\textbf{软件}，这决定了软件工程学科的研究对象。第二，软件工程需要高效高质地开发出这类产品，工程化是使产品开发得以高效高质的手段，一般依赖于管理有序的\textbf{生产过程}，其中要依据合适的\textbf{方法}，以及可操作的\textbf{质量保障手段}。这构成了窄义软件工程学科的研究范畴。第三，软件产品要用于解决现实世界的\textbf{领域相关问题}，它的使用要能为相关领域带来\textbf{价值}，进一步地，对领域价值的评判超出狭义软件工程的范畴，其范畴扩展到了应用领域中，因此，\textbf{领域工程}进入广义软件工程学科范畴，同时，\textbf{需求工程}成为领域工程和狭义软件工程之间的桥梁。
|
||||
|
||||
软件工程的内涵可以用图\ref{fig:se1}展示。其核心内容包括领域工程、需求工程和软件系统设计与实现三部分，它们形成广义上的软件工程的学科内涵。软件系统设计与实现是其中的主体内容，也是软件工程50年来发展最快的部分。所针对的问题是：如何高效高质地开发出能胜任的软件系统，其知识和技术体系体现在软件工程的方法、过程、质量保障\index{质量保障}及其相应的支撑工具上。这部分内容将在第3节予以描述。
|
||||
|
||||
2014年，《IEEE SWEBOK Guide》 V3.0提出一个软件工程学科的知识体系~\cite{Pierre2014SWEBOK}，其中包括15个知识领域，即：软件需求\index{软件需求}、软件设计\index{软件设计}、软件构造\index{软件构造}、软件测试\index{软件测试}、软件维护\index{软件维护}、软件配置管理\index{软件配置管理}、软件工程管理\index{软件工程管理}、软件工程过程\index{软件工程过程}、软件工程模型和方法、软件质量\index{软件质量}、软件工程职业实践、软件工程经济学\index{软件工程经济学}、计算基础、数学基础和工程基础。这个知识分类体系，除了基础性知识领域外，其它的大部分知识领域可以归属为上述软件系统设计和实现的内容。
|
||||
|
||||
值得一提的是，相比于传统的工程学科，软件工程最大的不同在于它的跨行业性，领域工程和需求工程就是解决软件的跨行业性问题，包括：如何理解所面对的问题领域（领域工程），和如何理解需要用软件技术来解决的领域问题（需求工程）。在目前即将进入的人机物融合时代，软件工程的跨行业性显得尤为突出，这是软件能够渗透进各行各业并通过行业应用体现其价值性的关键。这两部分内容将在第4节中描述。
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[scale=0.3]{fig1-4/fig1.png}
|
||||
|
|
@ -55,13 +48,19 @@
|
|||
\label{fig:se1}
|
||||
\end{figure}
|
||||
|
||||
软件工程的内涵可以用图\ref{fig:se1}展示。其核心内容包括领域工程、需求工程和软件系统设计与实现三部分，它们形成广义上的软件工程的学科内涵。软件系统设计与实现是其中的主体内容，也是软件工程50年来发展最快的部分。所针对的问题是：如何高效高质地开发出能胜任的软件系统，其知识和技术体系体现在软件工程的方法、过程、质量保障\index{质量保障}及其相应的支撑工具上。这部分内容将在第3节予以描述。
|
||||
|
||||
2014年，《IEEE SWEBOK Guide》 V3.0提出一个软件工程学科的知识体系~\cite{Pierre2014SWEBOK}，其中包括15个知识领域，即：软件需求\index{软件需求}、软件设计\index{软件设计}、软件构造\index{软件构造}、软件测试\index{软件测试}、软件维护\index{软件维护}、软件配置管理\index{软件配置管理}、软件工程管理\index{软件工程管理}、软件工程过程\index{软件工程过程}、软件工程模型和方法、软件质量\index{软件质量}、软件工程职业实践、软件工程经济学\index{软件工程经济学}、计算基础、数学基础和工程基础。这个知识分类体系，除了基础性知识领域外，其它的大部分知识领域可以归属为上述软件系统设计和实现的内容。
|
||||
|
||||
值得一提的是，相比于传统的工程学科，软件工程最大的不同在于它的跨行业性，领域工程和需求工程就是解决软件的跨行业性问题，包括：如何理解所面对的问题领域（领域工程），和如何理解需要用软件技术来解决的领域问题（需求工程）。在当前正在开启的人机物融合时代，软件工程的跨行业性显得尤为突出，这是软件能够渗透进各行各业并通过行业应用体现其价值性的关键。这两部分内容将在第4节中描述。
|
||||
|
||||
图\ref{fig:se1}还列举了与软件工程有适度交叉的学科领域，包括：计算机科学与技术是软件工程的技术支撑。数学提供了软件工程研究，特别是定量研究中所需的数学工具和理论支撑。管理科学和生态学为复杂软件系统的系统化和工程化管理，以及软件开发和应用生态的建立和可持续发展提供指导。系统科学\index{系统科学}是软件工程应对复杂领域问题的系统方法学。在成为信息社会的基础设施后，软件系统还需要遵循或受到各项法律法规的约束。
|
||||
|
||||
\section{软件工程设计和实现}
|
||||
\section{软件系统设计和实现}
|
||||
从研究布局角度看，软件系统设计和实现可以分为软件工程方法、软件工程过程、软件质量保障、以及软件工程工具等四个维度。本节分别从这几个维度进行介绍。
|
||||
\subsection{软件工程方法}
|
||||
\subsubsection{概述}
|
||||
软件开发在早期基本上没有可遵循的方法，程序员只是根据需要解决的问题按经验直接写代码。M. H. Hamilton是负责早期飞行控制软件（Apollo软件）的项目开发的，根据她的回忆~\cite{hamilton2018errors}，当时程序员主要关心的是硬件和软件的关系，以及如何利用这类关系来提升软件的性能。由于没有辅助工具，程序员最担心的是代码出错，需要不断地花时间进行手工调试。
|
||||
软件开发在早期基本上没有可遵循的方法，程序员只是根据需要解决的问题按经验直接写代码。M. H. Hamilton是早期飞行控制软件（Apollo软件）的项目开发负责人，根据她的回忆~\cite{hamilton2018errors}，当时程序员主要关心的是硬件和软件的关系，以及如何利用这类关系来提升软件的性能。由于没有辅助工具，程序员最担心的是代码出错，需要不断地花时间进行手工调试。
|
||||
|
||||
总结早期飞行控制软件开发经验，M. H. Hamilton设计了通用系统语言（Universal System Language, USL）~\cite{hamilton2008universal}，其灵感来自她对Apollo软件开发过程中出现的错误模式/类别的认识。当时，子系统间的接口错误占了软件错误的绝大部分，而且这些错误通常是最难找到和调试正确的。USL给出了不同接口错误类别的定义，通过这些系统定义来识别错误并在系统设计的时候预防它们。 USL定义的六个公理形成了控制逻辑的数学构造性理论的基础。
|
||||
|
||||
|
|
@ -69,7 +68,8 @@
|
|||
|
||||
如同本书第一章中阐述，软件发展的核心是管理复杂性，软件工程的目标则是控制复杂性。这在系统实现层表现为“模块化封装”，在系统设计层表现为“结构化抽象”，在问题分析层表现为“关注点分离”。这在早期的一些代表性工作中就有所体现，比如，1970年代末兴起的模块互联语言\index{模块互联语言}（Module Interconnection Language，简称MIL）就是一种结构化系统设计语言~\cite{prieto1986module}，它提倡软件系统由相互联结的模块组成，提供形式化手段刻画模块间的各种联接关系，形成系统规格说明，以支持系统完整性和模块间兼容性等的验证。还有各种体系结构描述语言\index{体系结构描述语言}（Architecture Description Language，简称ADL）就是在接近系统设计者直观认识的抽象层次上描述软件系统的结构，是软件系统高层结构的概念模型~\cite{Taylor2009SoftwareArchitecture}。
|
||||
|
||||
软件开发的效率和质量一直是软件工程追求的目标，基于构件的方法尝试采用大规模复用\index{复用}的手段，提高软件的开发效率，以及提升所开发的软件的质量。面向服务的方法则将其它软件提供的服务作为可复用的构件，软件系统通过复用并无缝集成来自不同提供方的服务来获得。除此之外，还有其它软件开发和软件工程模式，比如开源软件\index{开源软件}开发以及敏捷开发\index{敏捷开发}等，它们都从不同的角度来应对软件开发问题，解决软件危机，尝试找到软件开发的“银弹”。
|
||||
软件开发的效率和质量一直是软件工程追求的目标，基于构件的方法尝试采用大规模复用\index{复用}的手段，提高软件的开发效率，以及提升所开发的软件的质量。面向服务的方法则将其它软件提供的服务作为可复用的构件，软件系统通过复用并无缝集成来自不同提供方的服务来获得。除此之外，还有其它软件开发和软件工程模式，%比如开源软件\index{开源软件}开发以及敏捷开发\index{敏捷开发}等，它们
|
||||
都从不同的角度来应对软件开发问题，解决软件危机，尝试找到软件开发的“银弹”。
|
||||
|
||||
\subsubsection{结构化系统分析和设计方法}
|
||||
结构化系统分析和设计方法\index{结构化系统分析和设计方法}，起源于20世纪70-80年代，是一种用于分析和设计信息系统的瀑布方法，结构化分析以分层数据流图\index{数据流图}和控制流图\index{控制流图}为工具来开发系统的功能模型和数据模型。结构化设计包括软件体系结构设计、过程（功能）设计和数据设计。早期比较有代表性的包括P. Checkland和J. Scholes的软系统方法~\cite{peter1990soft}，E. Yourdon和L. Constantine的结构化设计~\cite{yourdon1979structured}，E. Yourdon的Yourdon结构化方法~\cite{yourdon1989modern}，M. Jackson的Jackson结构化编程~\cite{jackson1975principle}和结构化设计~\cite{jackson1983system}，以及Tom DeMarco的 结构化分析~\cite{demarco1979structure}等，结构化系统分析和设计方法由这些不同流派的方法综合而成。其中倡导的多种建模技术目前仍然是软件系统数据建模和分析的重要技术：
|
||||
|
|
@ -136,11 +136,11 @@
|
|||
\end{figure}
|
||||
|
||||
\subsubsection{软件过程管理}
|
||||
软件过程是为实现事先定义的目标而建立起来的一组事件的集合。软件过程也有广义和狭义之分，狭义的软件过程只单纯涉及流程，就是一组有先后顺序的活动，即流程。广义的软件过程中，其事件涉及三个维度，技术、人员和流程，流程是其中最重要的一维，它是连接技术和人员的粘合剂。只有技术、人员及流程三者融为一体，软件过程才能在软件开发中真正起到指导作用。
|
||||
软件过程是为实现事先定义的目标而建立起来的一组事件的集合。软件过程也有广义和狭义之分，狭义的软件过程只单纯涉及流程，即一组有先后顺序的活动。广义的软件过程中，其事件涉及三个维度，技术、人员和流程，流程是其中最重要的一维，它是连接技术和人员的粘合剂。只有技术、人员及流程三者融为一体，软件过程才能在软件开发中真正起到指导作用。
|
||||
|
||||
软件过程与软件生命周期\index{软件生命周期}紧密相关，一个软件过程既可以覆盖从需求到交付的完整的软件生命周期，也可以仅包括其中某些特定开发阶段。例如，一个实现过程就只包括详细设计、编码、代码评审、编译以及单元测试\index{单元测试}等更为细小的开发步骤。为了确保代码评审工作的质量，也可以进一步定义、管理和改进代码评审过程。
|
||||
|
||||
软件过程管理就是对软件过程的管理，包括软件过程的建立、执行、监控、评估以及改进等活动。其管理的依据，是从众多软件开发活动的经验教训中，总结而成的可供参考的模型。最著名的软件过程管理参考模型是能力成熟度模型CMM\index{能力成熟度模型CMM}，以及其后续的能力成熟度集成模型CMMI\index{能力成熟度集成模型CMMI}~\cite{chrissis2003cmmi}。
|
||||
软件过程管理就是对软件过程的管理，包括软件过程的建立、执行、监控、评估以及改进等活动。其管理的依据，是从众多软件开发活动的经验教训中，总结而成的可供参考的模型。最著名的软件过程管理参考模型是能力成熟度模型CMM\index{能力成熟度模型CMM}，其后续的能力成熟度集成模型CMMI\index{能力成熟度集成模型CMMI}~\cite{chrissis2003cmmi}，以及质量管理体系ISO 9000~\cite{DBLP:conf/quatic/Rienstra95}。
|
||||
|
||||
\subsubsection{敏捷软件开发}
|
||||
1990年代，有很多批评是针对一些僵化的对软件工程的过度监管、计划和微观管理等重量级方法，许多轻量级方法得以发展，其中包括快速应用开发（RAD）以及其它一些技术，包括统一过程（UP）和动态系统开发方法（DSDM），Scrum、Crystal Clear和极限编程（XP），特征驱动开发等。
|
||||
|
|
@ -176,7 +176,7 @@
|
|||
还有一系列标准用于监控和评估软件生产过程过程，以支持软件质量的提升，如，ISO/IEC 15504\footnote{https://www.iso.org/standard/38932.html}，其第一个版本专注于软件开发过程，后来扩展到涵盖软件业务中的所有相关流程，例如项目管理，配置管理，质量保障等，是成熟度模型的参考模型，评估者可以根据模型在评估期间收集证据，全面确定所开发产品（软件，系统和IT服务）的能力。其更新版本是ISO/IEC 33000\footnote{https://www.iso.org/standard/54175.html}。其它质量标准还包括ISO/IEC 25000\footnote{https://www.iso.org/standard/64764.html}、ISO/IEC/IEEE 29119\footnote{https://www.iso.org/standard/45142.html}等。
|
||||
|
||||
\subsubsection{形式规约和验证}
|
||||
除了采用工程方法来组织、管理软件的开发过程，并根据标准检验过程的正确性外。还有一类工作就是深入探讨程序和程序开发过程的规律，建立严密的理论，以其用来指导软件开发实践，这类工作推动了形式化方法的深入研究，其目标是以严格的数学推演为基础，通过对系统的形式规约、验证和逐步精化来构造并实现软件，从而提高软件设计的可靠性和鲁棒性。其中，形式规约是使用形式语言构建所开发的软件系统的规约，对应软件生命周期不同阶段的制品，刻画系统不同抽象层次的模型和性质。形式化开发就是构造并证明形式规约和形式模型之间的等价转换和精化关系，以系统的形式模型为指导，通过逐步精化，最后开发出满足需要的系统，也称为保证正确性的构造(Correctness by Construction)。
|
||||
除了采用工程方法来组织、管理软件的开发过程，并根据标准检验过程的正确性外。还有一类工作就是深入探讨程序和程序开发过程的规律，建立严密的理论，以期用来指导软件开发实践，这类工作推动了形式化方法的深入研究，其目标是以严格的数学推演为基础，通过对系统的形式规约、验证和逐步精化来构造并实现软件，从而提高软件设计的可靠性和鲁棒性。其中，形式规约是使用形式语言构建所开发的软件系统的规约，对应软件生命周期不同阶段的制品，刻画系统不同抽象层次的模型和性质。形式化开发就是构造并证明形式规约和形式模型之间的等价转换和精化关系，以系统的形式模型为指导，通过逐步精化，最后开发出满足需要的系统，也称为保证正确性的构造(Correctness by Construction)。
|
||||
|
||||
\subsubsection{软件分析和软件测试}
|
||||
软件分析和软件测试是软件开发实践中常用的质量保障手段，被广泛用于发现软件需求、设计、实现代码等制品中的缺陷或验证相关性质。
|
||||
|
|
@ -186,7 +186,7 @@
|
|||
\subsection{软件工程工具}
|
||||
软件工程工具，或软件工具，是用来辅助计算机软件的开发、运行、维护、管理、支持等过程中活动或任务的一类软件。早期的软件开发所用到的引导程序、装入程序、编辑程序等都可以看作是最早的软件工具。在汇编语言和高级程序设计语言出现以后，汇编程序、解释程序、编译程序、连接程序和排错程序构成了早期的软件工具集。在软件工程出现后，支持软件需求分析、设计、编码、测试、维护和管理等活动的软件工具逐渐发展起来，从各个阶段支持着软件开发过程，并且自然而然出现了工具集成的需要，使得各个工具能够协同操作。
|
||||
|
||||
软件开发环境由软件工具和环境集成机制构成，是支持软件产品开发的软件系统~\cite{张效祥2005计算机科学技术百科全书}。软件开发环境在工具集成的需求中开始萌芽，上世纪70年代中后期出现了软件工具箱（Toolkit）的思想，在软件开发过程中使用成套的多个软件工具。80年代起，软件开发环境的研究成为热点，出现了支持图形设计方式的第二代软件工具和集成这些工具为一体的软件开发环境。这些环境的特点是采用环境信息库，支持软件开发模型和开发方法，并且集成机制有了较大发展，出现了集成型软件开发环境。80年代后期，美国国家标准与技术研究院（National Institute of Standards and Technology, NIST）/欧洲计算机制造商协会(European Computer Manufacturers Association, ECMA)提出的集成化环境参考模型，被欧洲信息技术研究战略计划的PCTE采用，并于1990年成为ECMA的标准。90年代开始出现支持面向对象方法和技术的软件开发环境。我国“七五”“八五”“九五”科技攻关中研制的青鸟软件开发环境\index{青鸟软件开发环境}，是当时先进的软件开发环境，具有较为完善的集成化软件开发支撑能力。
|
||||
软件开发环境由软件工具和环境集成机制构成，是支持软件产品开发的软件系统~\cite{张效祥2005计算机科学技术百科全书}。软件开发环境在工具集成的需求中开始萌芽，上世纪70年代中后期出现了软件工具箱（Toolkit）的思想，在软件开发过程中使用成套的多个软件工具。80年代起，软件生产技术的研究和实践得到更多关注，计算机辅助软件工程（CASE）的研究和实践得到开展，并出现了可用的CASE工具和环境，以及支持图形设计方式的第二代软件工具和集成这些工具为一体的软件开发环境。这些环境的特点是采用环境信息库，支持软件开发模型和开发方法，并且集成机制有了较大发展，出现了集成型软件开发环境。80年代后期，美国国家标准与技术研究院（National Institute of Standards and Technology, NIST）/欧洲计算机制造商协会(European Computer Manufacturers Association, ECMA)提出的集成化环境参考模型，被欧洲信息技术研究战略计划的PCTE采用，并于1990年成为ECMA的标准。90年代开始出现支持面向对象方法和技术的软件开发环境。我国“七五”“八五”“九五”科技攻关中研制的青鸟软件开发环境\index{青鸟软件开发环境}，是当时先进的软件开发环境，具有较为完善的集成化软件开发支撑能力。
|
||||
|
||||
21世纪以来，随着互联网和移动通信的普及，软件工具和软件开发环境的用途和种类进一步拓展，出现了支持软件国际化、软件开发协同工作、开源软件库和开源社区环境以及支持互联网、物联网和云计算的基础软件和应用测试支撑工具。软件开发环境不仅支持时间上的松耦合开发，还支持空间上的分布开发，并且开始以协同开发思想为基础，更强调多相关方、多工具、多活动的协同开发支撑，使得软件产品相关的所有利益相关方能在互动的软件开发协作过程中，实现包括需求管理、项目管理、软件部署和运行监控等活动在内的完整的软件生存周期过程支撑。
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@
|
|||
|
||||
人机物融合计算场景下，软件系统分析和建模的困难还来自于当前的需求相关者（即领域专家，最终用户和客户）无法提供完整和正确的能力要求。许多创新应用，如微信、在线购物等一些受欢迎的应用程序，都是由技术的发展和产品设计师的创新思维驱动的，而不是最初的需求相关者所要求的。信息技术飞速发展的时代，领域专家和最终用户无法提出超出想象的技术发展，不能预测技术的发展趋势，如何在软件系统分析和建模方法中，支持创新需求的引入，或提供对创新需求的包容手段是一个重要的挑战。
|
||||
|
||||
\subsubsection{系统内生安全性}
|
||||
\subsubsection{系统内生安全性（Safety和Security）}
|
||||
对人机物融合系统而言，安全和隐私保护是第一要务，首先不容置疑的是系统安全性，系统在和人和物理环境直接交互的过程，需要保护人身安全，需要保护其交互环境，不施加具有破坏性的操作，避免交互环境受到损失；其次，由于其直接和人打交道，采集和分享人的信息，使得系统的隐私保护成为计算系统需要强制执行的法律，欧盟、美国等都出台了个人隐私数据或网络隐私保护法，中国也出台了个人信息保护法。与开发功能性需求是申明系统要做什么不同，使人机物融合系统具有内生的安全性和遵循隐私保护法，其系统需求开发的难点和挑战是回答以下几个问题：如何避免在系统操作回路中/上的人的安全隐患？如何避免系统可能对交互环境造成的伤害/破坏？如何避免不在系统操作回路上的人的安全隐患？如何避免泄露不在系统操作回路上的人的隐私？等。
|
||||
\subsubsection{计算与控制的交互与融合}
|
||||
人机物融合场景下，大量系统不再是单纯等待外界输入后做简单响应。在以轨道交通、航空航天、医疗卫生、工业控制等为代表的核心系统软件中，相关系统行为都包含了连续实时计算与离散决策控制之间的交互与融合。以列控系统为例，列车运行中相关运行参数物理量，如车速、位置、外界风速、轨道坡度等取值在连续变化。基于这些运行参数取值的实时监控与预测计算，列控系统会在各运行模式间切换，比如加速，减速等。然而列车不同的运行模式也会导致这些物理量变化规律发生改变。在这类情况下，系统的连续计算和离散控制两种行为相互依赖、相互影响、彼此互为依存、息息相关。因此，如何在开放环境下准确构建系统离散与连续交织行为模型成为重要挑战。
|
||||
|
|
@ -90,48 +90,62 @@ DevOps 持续高效高质量的交付有赖于高度自动化支持工具的支
|
|||
DevOps整合了开发团队与运维团队，使其成为一个整体，这使得团队的组织、文化和软件过程都与单纯的开发团队和运维团队有所不同。同时，团队的规模也不可避免的有所增加，降低了团队面对面沟通的效率。DevOps是受到敏捷软件开发的影响而产生的，天然带有敏捷基因并植根于精益思想。然而，敏捷方法的很多理念和实践并不能天然应用于DevOps。例如，常规敏捷方式鼓励着眼当前问题同时通过承担一定程度的技术负债来应对未来的多种可能变化。这种寻求局部最优解的思维方式并不利于打破各个部门之间的壁垒。又如，在敏捷宣言鼓励之下的“重代码轻文档”工作方式对于持续性的维持还是弊大于利，毕竟我们不会轻易终止一款软件系统。另一方面，随着开发和维护的软件系统越来越复杂，其规模也越来越大，在开发运维团队合并后，必然要求团队规模也相应扩大，团队之间的协作和交流也会更加复杂。敏捷社区提出了SAFe（Scaled Agile Framework）来支持更大规模的团队，目前已经列入DevOps相关内容。然而，也有很多人批评SAFe过于复杂，违背了敏捷的基本价值观。从这个意义上说，如何在大规模团队中实施DevOps仍将成为未来一段时间研究者和实践者需要解决的问题。
|
||||
|
||||
\section{主要研究内容}
|
||||
面向高效、高质量、低成本开发和演化软件系统的总体目标，软件开发方法和技术的研究范围涵盖新型程序设计与软件方法学\index{软件方法学}、软件自动化技术、软件复用\index{软件复用}技术、软件自适应与生长\index{软件自适应与生长}技术、复杂软件分析与建模、智能软件开发方法、嵌入式软件\index{嵌入式软件}开发方法与技术、复杂系统需求分析方法与技术、\index{软件服务化方法与技术}等各个方面。结合应对以上重大挑战问题，主要研究内容将集中在人机物融合场景建模、系统自适应需求分析、系统内生安全规约获取、群智软件生态、群智开发方法、群智协同演化、群智软件支撑环境、面向机器编程的代码生成、面向人机协同的智能开发环境、开发过程建模与优化、软件系统运行数据管理、安全可信的开发运维一体化、开发运维一体化的组织与管理、微服务软件体系结构等。
|
||||
面向高效、高质量、低成本开发和演化软件系统的总体目标，软件开发方法和技术的研究范围涵盖新型程序设计与软件方法学\index{软件方法学}、软件自动化技术、软件复用\index{软件复用}技术、软件自适应与生长\index{软件自适应与生长}技术、复杂软件分析与建模、智能软件开发方法、嵌入式软件\index{嵌入式软件}开发方法与技术、复杂系统需求分析方法与技术、\index{软件服务化方法与技术}等各个方面。结合应对以上重大挑战问题，主要研究内容将集中在人机物融合场景建模(§\ref{sec:ch2-4:model})、系统自适应需求分析(§\ref{sec:ch2-4:analysis})、系统内生安全规约获取(§\ref{sec:ch2-4:safety})、群智软件生态(§\ref{sec:ch2-4:eco})、群智开发方法(§\ref{sec:ch2-4:develop})、群智协同演化(§\ref{sec:ch2-4:evo})、群智软件支撑环境(§\ref{sec:ch2-4:environment})、面向机器编程的代码生成(§\ref{sec:ch2-4:generation})、面向人机协同的智能开发环境(§\ref{sec:ch2-4:intel})、开发过程建模与优化(§\ref{sec:ch2-4:opt})、软件系统运行数据管理(§\ref{sec:ch2-4:run})、安全可信的开发运维一体化(§\ref{sec:ch2-4:trust})、开发运维一体化的组织与管理(§\ref{sec:ch2-4:org})、微服务软件体系结构(§\ref{sec:ch2-4:micro})等。
|
||||
|
||||
\subsection{人机物融合场景建模}
|
||||
\label{sec:ch2-4:model}
|
||||
人机物融合的新型泛在系统，以实现人类社会、信息空间和物理世界的互联互通为目标。在这种应用场景中，计算资源高度泛化，系统能力拓展到包括连接、计算、控制、认知、协同和重构等在内的网络化、协同式和适应性的认知、计算和控制一体的综合能力范畴。需要研究人机物融合的计算环境的认知和建模，特别是对各种实现感知、计算、通信、执行、服务等能力的异构资源的认知的建模；系统研究交互环境的建模理论，包括交互环境静态属性特征和动态行为特征，以及行为约束等多个方面；针对系统离散、连续行为交织，系统外部运行环境、内部协作关系随时间、任务变化进行实时演变的特性，研究相关复杂行为建模与刻画方法，从而对系统行为进行描述，为后续分析、测试、验证提供基础；需要对典型人机物融合场景下泛在应用的本质特征，分别予以有效的场景抽象，研究相应的软件定义方法，以凝练人机物融合应用场景的共性，更有效地管理资源，并适应动态多变的应用场景。
|
||||
|
||||
\subsection{系统自适应需求分析}
|
||||
\label{sec:ch2-4:analysis}
|
||||
人机物融合应用场景下，需求以及交互环境的动态变化性和不确定性，使得系统的自适应性成为关键，软件系统的自适应性需求建模和管理成为热点研究课题，其中包括自适应需求的获取，自适应系统的建模，需求、系统模型和交互环境的在线检测和分析，系统能力在线规划和管理等。针对系统环境的开放性、动态变化性和不确定性等，需要对系统及其交互环境在建模和模型管理方面进行综合型研究，在系统环境建模方法，环境现象感知方法，环境事件推理技术，模型的追踪关系和基于追踪关系的协同演化策略，运行时目标驱动的在线优化和系统功能重配置方法，以及系统自适应性机制的度量和评估方法等方面进行深入研究。
|
||||
|
||||
\subsection{系统内生安全规约获取}
|
||||
\label{sec:ch2-4:safety}
|
||||
人机物融合应用场景下，安全作为第一要务是不容置疑的，一方面需要保护人身安全，另一方面需要避免损失，避免破坏环境，安全防护，这些已成为系统强制执行的法律。系统内生安全的实现存在两个阶段，第一阶段是安全特征的构造，安全特性不同与系统的其它功能，需要研究：基于显式环境建模安全关注点分析，支持对安全隐患/环境风险/不合规问题等的识别；研究对系统运行时的时空间协同建模，支持混合的行为建模和认知建模以及人类行为模拟，支持从环境行为模型中发现隐含的风险隐患；研究离散模型和连续模型的融合方法，支持一体化系统验证，以及人在环路中/上系统，以及支持协作和共享的控制器综合。第二阶段是建立内置的安全规约，研究对系统级内置隐私保护和安全控制能力抽象，支持安全能力成为系统可管理的资源，研究面向应用场景的可定义的安全能力配置，系统功能和隐私/安全约束的协调，个性化、可动态配置的隐私/安全约束，以及可追溯可审计的隐私保护/安全控制。
|
||||
|
||||
\subsection{群智软件生态}
|
||||
\label{sec:ch2-4:eco}
|
||||
在群智开发中，参与者群体、开发环境、软件任务、软件制品等多种要素相互作用，是持久驱动软件生产力发展的重要引擎。然而，由于软件的复杂性持续增长、开发过程的开放性持续加大，软件生态的形成与演变具有很强的随机性，未能形成有效的生态构建机理与方法。为此需要重点研究：1）基于博弈论和社会经济学等理论研究开源生态形成与演化的动力学模型，形成“贡献激发、群智汇聚、人才涌现”的良性循环；2）研究面向软件生态的多模态持续激励机制，突破基于区块链等新型技术的知识产权共享与群智激励方法；3）研究软件生态的大规模混源代码溯源技术和演化分析方法，突破软件开发供应链的分析识别技术，建立全谱系的群智软件生态供应链模型。通过上述研究，为软件生态构建和演化提供理论指导。
|
||||
|
||||
\subsection{群智开发方法}
|
||||
\label{sec:ch2-4:develop}
|
||||
在动态开放环境下，参与群体的高自主性、任务目标的高变化性等，带来群智涌现的不确定性，严重制约了基于群智的软件开发效能。基于“人在回路中”的群智软件生态观，群智软件开发方法需重点关注：（1）研究大规模群体的高效协作机理和模型，突破面向复杂开放环境的群体协同增强方法；（2）研究碎片化贡献的高效共享与汇聚融合技术，建立群智贡献的高效可信传播体系；（3）突破群智贡献的多维量化评估与度量技术，形成多源群智贡献的高效汇聚与精化收敛方法。
|
||||
|
||||
\subsection{群智协同演化}
|
||||
\label{sec:ch2-4:evo}
|
||||
群智开发是一种人类智能和机器智能协同融合推动软件系统持续迭代的新方法，如何充分激发人机群智的效能，实现软件系统的快速演化，需要重点关注：（1）研究群体行为量化分析与建模方法，建立群智激发汇聚、行为轨迹演进等基本模型；（2）研究涵盖代码、开发者、开发社区、软件生态的群智软件开发多维度分析评估方法，突破面向软件开发演化的大数据分析和智能释放技术；（3）研究开发者群体智能与开发大数据机器智能的互补融合、协同演进机制，构建面向软件生态演化的人-机反馈回路。通过上述研究，为群智软件生态演化提供技术支撑。
|
||||
|
||||
\subsection{群智软件支撑环境}
|
||||
\label{sec:ch2-4:environment}
|
||||
以群智软件开发方法和技术为依托，以群智开发生态为理论指导，构建面向群智软件开发与演化的支撑环境，需要重点关注：（1）研究构建面向群智制品和大规模群体的管理、协作、共享与评估等群智开发支撑工具集，有效支持开放群体的高效协同和群智任务的有效管理；（2）研究动态开放环境的群体组织规则与环境协作流程，构建相应的支撑机制和工具，充分释放大规模人-机混合群体效能；（3）突破面向新型软件的智能化开发运维一体化技术，构建基于人机混合群体智能的软件开发与演化支撑平台，建立针对群智软件开发生态中核心技术和关键节点的全面支撑和自主可控机制，形成覆盖人-机-物的全新软件开发与技术创新生态网络。
|
||||
|
||||
\subsection{面向机器编程的代码生成}
|
||||
\label{sec:ch2-4:generation}
|
||||
机器编程是人机协作编程的基础，而代码生成又是机器编程的核心。从软件的生命周期过程看，机器编程主要在以下场景中起作用：（1）以软件规约为出发点，自动生成满足规约的软件代码；（2）针对软件中存在的错误，自动生成修复代码。从软件规约生成代码本质上是一个搜索过程，即在在程序空间里搜索满足软件规约的程序，然而待搜索的程序空间规模巨大，搜索难以有效进行；同时，程序本身固有的复杂性使得验证代码是否满足规约也存在巨大的效率问题。与从软件规约生成代码相比，自动生成修复代码有明显的特殊性：修复时通常缺乏可以准确刻画正确程序性质的规约，但存在可运行的出错程序，此时代码生成更多地是在已有代码上的修改，而验证更多地通过对比运行修改前后的程序进行。这方面的主要研究内容包括：（1）如何利用海量代码数据加速程序合成中的代码搜索；（2）如何利用海量代码数据加速程序合成中的代码验证；（3）如何利用人类程序员的修复数据完成软件错误的自动修复。
|
||||
|
||||
\subsection{面向人机协作的智能开发环境}
|
||||
\label{sec:ch2-4:intel}
|
||||
人机协作编程的另一个重要基础是高效的智能开发环境，智能开发环境是机器编程技术的集中承载者，也为开发人员提供各种智能服务，同时智能开发环境也是开发人员间交流的通道。在一个智能开发环境中，开发人员应该能够方便地获取各种所需的信息，从而减少对自身大脑信息记忆的依赖；同时，智能开发环境应该能够主动识别开发人员的需求，为开发人员推荐相关的信息或开发动作，比如推荐完成特定开发任务的代码；进一步，作为开发人员间交流的中介，智能开发环境应该保证开发人员间高效顺畅的交互，如果存在可以独立承担开发任务的机器程序员，智能开发环境也应保证人类程序员与机器程序员间的交互；传统的键盘和屏幕并不是人类最习惯的交互机制，更好的交互机制应该是一种综合运用多种感官的多通道交互，智能开发环境应该提供开发人员更习惯的交互机制。因此，这方面的主要研究内容包括：（1）如何帮助开发人员快速查找开发所需的信息；（2）如何针对具体的开发任务推荐可能的开发动作；（3）如何实现开发人员间以及与开发环境间的多通道交互。
|
||||
|
||||
\subsection{开发过程建模与优化}
|
||||
\label{sec:ch2-4:opt}
|
||||
丰富的工具是软件过程实现DevOps化的助推器与基石，工具在有效地优化过程的同时，会产生海量的过程数据。挖掘这些数据并构建模型，以实现过程改进和优化是目前热门的研究领域。早在DevOps出现之前，软件过程建模和优化就是一个研究热点，但数据的缺乏一直是过去相关研究的痛点。DevOps的盛行，尤其是随着各类工具的普及，问题已经转变为了如何有效挖掘并利用资源库中蕴含的海量数据。这方面，有两大类研究值得关注：一类是使用传统过程建模技术为理解、分析以及管控过程提供支持，更进一步的可以实现过程的改进与优化。另一类研究采用机器学习技术，着眼于过程中更具体的点，例如缺陷预测、持续集成结果预测、评审人员推荐等，能够为提高过程质量、减少资源消耗和缩短交付周期等提供支持。
|
||||
|
||||
\subsection{软件系统运行数据管理}
|
||||
\label{sec:ch2-4:run}
|
||||
从指标信息、调用链信息以及日志信息入手，通过深入整合与挖掘这三种运维相关的数据信息，来提供更丰富以及更高质量的信息，进而提升AIOps的质量与效率，这应该是需要实现的目标。为了达成这个目标，需要开展如下研究。首先，需要研究提升运维数据的质量的方法。在这三类信息中，由于日志信息是非结构化的，受到开发人员主观因素影响较大，因此大部分数据的质量并不理想。因此，在日志的生命周期中，需要将日志决策和日志开发的阶段左移，在需求开发和系统设计中充分考虑日志的需求，并形成日志本身的开发-运维反馈闭环。在此基础上，辅以自动化日志工具，以此来提高日志的质量以及日志记录的效率。其次，应该探索相应的方法和技术来提升调用链信息的捕获和存储效率。最后，需要提出一种深度整合三类运维数据的方法。日志信息、调用链信息以及指标信息应该通过特定的算法关联起来，从而提供多维度的运维信息。例如，调用链信息可以与指标信息结合，将各个时间节点的指标信息以调用关系的形式组织起来，进而促进根因分析等AIOps任务。
|
||||
|
||||
\subsection{安全和可信的开发运维一体化}
|
||||
\label{sec:ch2-4:trust}
|
||||
为实现安全且可信的运维，我们需要开展的主要研究内容包括：（1）通过自动化运维以及智能化运维减少运维工作中的一些人工操作，在提升效率的同时避免手工作业本身可能导致的错误；（2）对运维过程的监控数据进行分析，及时检测异常的发生，并对问题进行追踪和溯源工作，快速解决问题、避免损失；（3）DevSecOps下的安全运维在持续监控和分析的同时需要建立持续的问题反馈循环，为产品安全性和可行度提供持续的保障。
|
||||
|
||||
\subsection{开发运维一体化的组织与管理}
|
||||
\label{sec:ch2-4:org}
|
||||
为了缩短软件从产品设计到呈现给最终用户的时间，DevOps整合了软件开发和运维团队，这使得DevOps团队的组织、文化和过程都与单纯开发、运维团队不同。从组织与管理角度，DevOps需要解决以下问题：（1）使用经验软件工程的方法，探寻适合DevOps的组织结构和过程实践，并进行验证；（2）如何既能通过团队自组织工作方式提升效率，同时又能够避免由于具体人员技能缺失或管理人员与DevOps团队缺乏信任关系造成的失败，在敏捷与规范之间取得平衡；（3）在大型项目中，使用怎样的组织方式和软件过程，能够使得DevOps项目具有敏捷应对变更的优势以及工作效率。
|
||||
|
||||
\subsection{微服务软件体系结构}
|
||||
\label{sec:ch2-4:micro}
|
||||
围绕微服务架构有如下几类研究值得关注：（1）实现合适粒度的微服务划分方法，主要研究内容包括：基于领域驱动设计方法识别限界上下文以实现高内聚、低耦合的服务；利用遗留系统的现有构件信息识别候选微服务；综合利用多种划分策略实现复杂系统的服务划分等。（2）基于微服务架构的快速故障定位和消除，主要研究内容包括：构建更加完善的监控系统，除了基础指标监控功能，实现分布式服务链路追踪和日志聚合分析等高级功能来帮助故障排查和定位；基于AIOps实现智能告警运维，通过已经构建的监控系统平台对多种类型数据进行不同形式的采集（有代理和无代理）、处理、存储，使用并改进机器学习算法对运维数据进行分析预测，实现多种场景的智能告警运维；微服务架构评估，即提出面向微服务系统的一般化架构质量评价方法，为微服务系统架构质量的评估过程提供指南，总结供架构评估使用的核查表（Checklist）以支持开发和运维中的微服务架构实践。
|
||||
|
||||
\section{本章小结}
|
||||
|
|
|
|||
|
|
@ -10,11 +10,11 @@
|
|||
|
||||
\section{重大挑战问题}
|
||||
|
||||
在人机物融合的计算场景下，软件质量与安全保障面临的重大挑战问题主要集中以下几个方面：一是在人工智能时代，数据驱动的智能软件系统高度复杂的数据依赖、软件行为不确定性、计算结果鲁棒性方面，对软件质量提出了新的挑战；二是针对人机物融合场景下的大规模软件系统，拓展传统静态、封闭环境下的正确性、可靠性质量保障技术，支持动态、开放、演化环境下的可信质量保障；三是针对基础设施化软件系统，有效检测漏洞或恶意软件等安全缺陷，并通过构建准确、高效的缺陷修复技术及漏洞防御机制保障安全。
|
||||
在人机物融合的计算场景下，软件质量与安全保障面临的重大挑战问题主要集中以下几个方面：一是数据驱动的智能软件系统高度复杂的数据依赖、软件行为不确定性、计算结果鲁棒性方面，对软件质量提出了新的挑战；二是针对人机物融合场景下的大规模软件系统，拓展传统静态、封闭环境下的正确性、可靠性质量保障技术，支持动态、开放、演化环境下的可信质量保障；三是针对基础设施化软件系统，有效检测漏洞或恶意软件等安全缺陷，并通过构建准确、高效的缺陷修复技术及漏洞防御机制保障安全。
|
||||
|
||||
\subsection{数据驱动的智能软件系统质量保障}
|
||||
\subsection{数据驱动的智能系统质量保障}
|
||||
|
||||
越来越多的软件系统采用人工智能技术，基于大规模数据分析进行计算、推理及决策，即综合利用统计分析算法、数据处理、并行计算等技术，从海量、多态的数据中，挖掘知识、实现数据价值的最大化。与传统软件相比，智能算法模型通常构建一些复杂变换（往往是高维非线性）实现智能处理，这种复杂运算给模型内部变换边界带来特定方向的不稳定性。智能软件系统最终得依赖外部物理设备运行，系统运行过程还受环境的精度等方面的资源约束。因此，数据驱动的智能软件系统在高度复杂的数据依赖、软件行为不确定性、计算结果鲁棒性方面，对质量保证研究提出了新的挑战\cite{sculley2015hidden}。随着数据驱动的智能软件系统越来越广泛地应用在工业生产、社会生活、金融经济、行政管理的方方面面，其可靠性、鲁棒性、安全性等方面问题如不能有效地加以防范，将造成重大损失甚至灾难性后果。
|
||||
越来越多的软件系统采用深度学习技术，基于大规模数据分析进行计算、推理及决策，即综合利用统计分析算法、数据处理、并行计算等技术，从海量、多态的数据中，挖掘知识、实现数据价值的最大化。与传统软件相比，智能算法模型通常构建一些复杂变换（往往是高维非线性）实现智能处理，这种复杂运算给模型内部变换边界带来特定方向的不稳定性。智能软件系统最终得依赖外部物理设备运行，系统运行过程还受环境的精度等方面的资源约束。因此，数据驱动的智能软件系统在高度复杂的数据依赖、软件行为不确定性、计算结果鲁棒性方面，对质量保证研究提出了新的挑战\cite{sculley2015hidden}。随着数据驱动的智能软件系统越来越广泛地应用在工业生产、社会生活、金融经济、行政管理的方方面面，其可靠性、鲁棒性、安全性等方面问题如不能有效地加以防范，将造成重大损失甚至灾难性后果。
|
||||
|
||||
(1) 数据质量\index{数据质量}和模型质量\index{模型质量}成为瓶颈。数据驱动的智能软件系统中，往往以数据为核心，围绕数据的处理、分析、挖掘、学习等各种任务设计算法，被称为“面向数据编程”的模式。因此，与传统软件侧重“逻辑正确”不同，数据和模型的质量是数据驱动的智能软件系统可信性的基础和关键。一方面，数据的质量难以保证，与传统关系型数据相比，大数据具有数据量大、实时分析要求高、存在多种异构数据格式、噪音高、关键数据元素持续演变等特点，数据质量是大数据分析正确和决策有效的根本保证，数据质量管理更加具有挑战性和迫切性；另一方面，鉴于认知系统和认知过程的复杂性，模型有可能不完整、不精确、模型假设存在偏差，噪音会严重干扰模型的有效性。算法需具备一定的鲁棒性，不受模型中噪音的干扰，给出可信的决策结果，在数据分布特征等方面，训练数据集与实际应用或是预期的数据集可能存在不一致性，即数据集偏差、歧视、或是样本迁移问题，直接影响模型的可靠性。数据和模型的错误和失效，将造成智能算法判断和决策错误、软件失效。
|
||||
|
||||
|
|
@ -22,7 +22,7 @@
|
|||
|
||||
(3) 智能系统需具备运行时故障诊断、预测及自愈的能力。智能系统常常需要融合多种硬件设施、软件构件，实时完成大规模数据的采集、综合、分析等处理，实现智能感知和智能决策。系统应用场景多样，功能组合繁多，输入空间难以穷尽，条件组合数量巨大；在实际运行中，软硬件环境等因素复杂多变，各种情况叠加在一起综合作用。离线测试阶段难以覆盖各种可能的场景。另一方面，系统常需要集成大量第三方的数据和软件，如深度学习与机器学习框架。在实际应用中，第三方服务的稳定性、可靠性、安全性以及不同来源的服务之间的兼容性、互操作性等问题，都给系统集成带来了巨大的挑战。因此，运行过程中及时发现和诊断乃至预测系统故障、及时修复故障或通过容错等机制保持系统正常运行，对于保证业务安全和系统高可用性至关重要。
|
||||
|
||||
\subsection{人机物融合场景下的软件系统可信增强}
|
||||
\subsection{人机物融合场景下的系统可信增强}
|
||||
与传统系统不同，人机物融合场景下的软件系统将计算部件与物理环境进行一体化整合，将大量独立的异构设备（及其数据）进行智能化的连接，并针对当前系统、场景等的实时变化根据任务需求对计算逻辑，乃至软件体系结构进行自动调整与配置。这样，计算设备可以更精确地获取外界信息并做出针对性、智能化的实时反映，从而提高计算的性能与质量，给出及时、精确并且安全可靠的服务，实现物理世界与信息系统的整合统一\cite{lee2006cyber}。显然，列车、电网、航天等典型安全攸关系统均具有鲜明的人机物融合特质。如何对相关系统的可信性进行保障对相关系统的正确运行具有重要意义。然而，在人机物融合的场景下，相关异构、组合、动态等特性也给系统行为可信保障带来了新的挑战与需求。
|
||||
|
||||
(1) 人机物融合场景下构件间将进行频繁的通信、合作与协同，去完成复杂的任务。因此，相关系统是一个典型的组合系统。长期以来，对大规模组合系统进行分析、测试、验证一直是相关领域难点所在。此外，由于在人机物融合场景下不确定性、概率性行为、实时连续行为越来越常见。如何在建模阶段对随机、不确定、连续行为进行描述，并在分析中对相关行为进行研究，也是对相关复杂不确定系统进行可信增强的一个重要挑战。
|
||||
|
|
@ -36,14 +36,14 @@
|
|||
|
||||
(1) 安全缺陷统一建模。安全缺陷中，漏洞属于实现中存在遗漏，而恶意代码属于非预期的实现，安全缺陷一旦被攻击或利用，都能对软件系统带来危害。经过几十年的发展，已经公开了大量的安全缺陷，软件安全缺陷具有程序设计语言依赖、系统依赖等特征，有时还依赖于特定的硬件平台与体系结构，安全缺陷形态、机理各异。针对特定的安全缺陷，研究相应的检测方法进行精准制约化检测，虽在特定场景下可行，但已不能满足实际的安全需求。面临的挑战主要在于如何统一表达安全缺陷的语法、语义特征、触发规则、行为特征等问题，使得能够通过相关检测算法高效、精准识别安全缺陷；在此基础上，提升安全缺陷检测方法的可扩展能力，以便检测已有的重要安全缺陷，还能检测新的安全缺陷。
|
||||
|
||||
(2) 大规模复杂系统安全缺陷检测方法的效率和资源有效协同。根据已公开的安全缺陷特征，通过静态分析、测试和验证等方法检测潜在安全缺陷，是目前被普遍采用的技术。但随着软件系统规模越来越大、系统功能日趋复杂，公开安全缺陷的数量也急剧上升，安全缺陷检测方法的精准性和规模化能力是难点问题。面临的挑战主要包括：1）需要在处理大规模程序时平衡精度和可扩展性。高精度的检测方法需要更多的资源开销，并且受到程序规模的制约，而为了适应大规模程序的安全缺陷检测，采用保守的策略，会导致大量的误报，且需要人工进一步确认，从而降低了检测方法的可用性； 2）需要平衡协同计算资源的消耗与检测效率。安全缺陷检测方法可以提升精度但增加复杂度且需要更高的计算资源，可以利用大数据处理、硬件加速、并行化等技术优化检测算法，依据特定的规则将大规模代码进行切分，将检测任务并行化处理、并将其分配到不同的计算资源上完成检测工作。
|
||||
(2) 大规模复杂系统安全缺陷检测方法的效率和资源有效协同。根据已公开的安全缺陷特征，通过静态分析、测试和验证等方法检测潜在安全缺陷，是目前被普遍采用的技术。但随着软件系统规模越来越大、系统功能日趋复杂，公开安全缺陷的数量也急剧上升，安全缺陷检测方法的精准性和规模化能力是难点问题。面临的挑战主要包括：1）需要在处理大规模程序时平衡精度和可扩展性。高精度的检测方法需要更多的资源开销，并且受到程序规模的制约，而为了适应大规模程序的安全缺陷检测，采用保守的策略，会导致大量的误报，且需要人工进一步确认，从而降低了检测方法的可用性； 2）需要平衡协同计算资源的消耗与检测效率。安全缺陷检测方法可以提升精度但增加复杂度需要更高的计算资源，可以利用大数据处理、硬件加速、并行化等技术优化检测算法，依据特定的规则将大规模代码进行切分，将检测任务并行化处理、并将其分配到不同的计算资源上完成检测工作。
|
||||
|
||||
(3) 安全缺陷检测过程中大规模状态空间的充分探索。在安全缺陷检测过程，需要尽快探索到目标程序的状态空间，以检测潜在的安全缺陷，由于复杂软件系统的程序状态空间十分庞大，如何有效地探索程序的状态空间是需要解决的关键问题，具体包括以下几个方面：1）程序分支和循环结构的深度覆盖：通过探索程序状态空间过程中历史覆盖、缺陷检测、冗余等信息，有效地制导探索过程，尽早覆盖关键的程序状态空间；2）多维信息制导的模糊测试输入生成：利用程序结构、安全缺陷特征、执行结果反馈等信息，有效地制导模糊测试，使其能够产生覆盖多样性目标的输入空间，从而快速覆盖程序状态空间，到达能够触发安全缺陷的程序行为路径。
|
||||
(4) 历史漏洞机理和安全专家经验难以复用。在现有安全缺陷检测的分析和测试过程中，多个环节存在不确定性，仍需要安全专家人工进行决策。这些安全专家经验以及历史漏洞的机理信息对后续漏洞分析、检测、利用和修复工作能够起到很大作用。但遗憾的是，这些经验在现阶段难以实现高准确度的复用。然而，人工智能技术现已在文本翻译、图像处理、语音识别等方面得到广泛应用，使其具备人的智能而实现自主决策。因此，如何在安全缺陷检测和预警的各个环节中引入智能化技术，是现阶段所面临的重要挑战，具体包括以下两个方面：1）安全缺陷检测历史信息的智能化：将安全缺陷检测历史信息及其统计特征知识化，以便在安全缺陷检测过程中进行智能化预测；将深度学习技术应用到安全缺陷检测样本代码相似度映射中以便实现同源安全缺陷检测和挖掘的智能化，应用到输入域、程序结构的映射中实现模糊测试中输入生成的智能化；2）安全专家经验的知识化和智能化利用：分析安全缺陷检测过程中的专家经验，进而抽象其为安全缺陷检测的启发式规则，以便在安全缺陷检测过程中根据自动搜索经验知识空间实现安全缺陷检测的智能化。
|
||||
(4) 历史漏洞机理和安全专家经验难以复用。在现有安全缺陷检测的分析和测试过程中，多个环节存在不确定性，仍需要安全专家人工进行决策。这些安全专家经验以及历史漏洞的机理信息对后续漏洞分析、检测、利用和修复工作能够起到很大作用。但遗憾的是，这些经验在现阶段难以实现高准确度的复用。人工智能技术现已在文本翻译、图像处理、语音识别等方面得到广泛应用，使其具备人的智能而实现自主决策。因此，如何在安全缺陷检测和预警的各个环节中引入智能化技术，是现阶段所面临的重要挑战，具体包括以下两个方面：1）安全缺陷检测历史信息的智能化：将安全缺陷检测历史信息及其统计特征知识化，以便在安全缺陷检测过程中进行智能化预测；将深度学习技术应用到安全缺陷检测样本代码相似度映射中以便实现同源安全缺陷检测和挖掘的智能化，应用到输入域、程序结构的映射中实现模糊测试中输入生成的智能化；2）安全专家经验的知识化和智能化利用：分析安全缺陷检测过程中的专家经验，进而抽象其为安全缺陷检测的启发式规则，以便在安全缺陷检测过程中根据自动搜索经验知识空间实现安全缺陷检测的智能化。
|
||||
|
||||
(5) 面向安全保障的缺陷自动修复与验证。及时修复软件中存在的安全缺陷，是保障软件安全的主要手段，现阶段主要依靠人工修复软件安全缺陷需要花费大量的时间精力阅读理解程序代码、定位安全缺陷并修复，非常耗时耗力。面临的挑战主要在于：1）如何针对安全缺陷实现自动修复。基于遗传算法、程序搜索、程序合成等手段的软件缺陷的自动修复方法面临在实际系统中应用的可扩展性、可用性等方面的挑战。2）如何自动验证修复。目前存在一些修复方法在某些实验途径上可以证实有效性，但缺少理论基础，无法保障其完备性，需要有手段保证安全缺陷修复措施符合预期。
|
||||
|
||||
\subsection{物联网环境下基础设施类软件安全保障}
|
||||
\subsection{物联网环境下的系统安全保障}
|
||||
|
||||
物联网作为新一代信息技术，通过软件定义、人机物融合实现计算、信息、通讯、控制等任务的一体化，软件是其核心使能、基础设施类组成部分。物联网高速发展的同时，也带来新的问题，特别是物理设备实现移动互联后，导致所有物联网终端设备直接暴露在互联网上、处于不安全状态，使得设备自身安全、其拥有和传输的数据的机密性、完整性和可获得性，都面临安全挑战。任一物联网终端软件一旦遭受攻击，将会导致软件崩溃、设备失效、威胁用户隐私、冲击关键信息基础设施等安全事故，对整个物联网系统造成严重的破坏性\cite{ammar2018internet, brumley2008automatic}。但现阶段，全面保障物联网软件与系统安全，需要检测物联网软件的所有潜在安全薄弱环节，实施有针对性的保障措施。但由于物联网软件的复杂性、异构性、人机物融合等特性，仍然需要重点解决如下重大挑战问题：
|
||||
(1) 面向复杂异构物联网终端控制软件的安全缺陷检测。物联网系统的使能部件是软件，而这类驱动物联网系统工作的核心软件，如果存在安全缺陷，包括漏洞、恶意软件，容易被攻击利用，在安全关键场景下会带来严重的后果，如何能够及时检测这类安全漏洞是关注的焦点。在复杂物联网系统中，计算、通信和控制设备由于其各自所执行的任务不同，往往由完全不同的软硬件构成，同时不同设备间的相互协作关系也由于系统的庞大而变得十分复杂，有时还可能存在动态变化，这导致对复杂物联网系统中异构的终端设备控制软件进行安全性检测变得异常困难。如何改进现有的静态分析与动态测试技术以适应物联网软件依赖的芯片、硬件外设、操作系统、指令集、外部库、交互接口、外部输入等异构性，是面向复杂异构物联网终端软件进行安全缺陷检测亟需解决的关键问题。
|
||||
|
|
@ -99,7 +99,8 @@
|
|||
在DevOps、持续集成（Continuous Integration）、持续测试（Continuous Testing）、持续交付（Continuous Delivery）、智能运维（AIOps）等软件开发、集成和动态运行维护框架下，研究开发、集成、部署、运维流程中持续迭代的故障检测和质量评价等环节质量历史数据的分析方法，确定质量问题、追溯问题来源并评估质量风险，从管理角度在软件开发构建、运行维护过程中约束、规范人的行为，从改进软件过程、预防不符合预期制品的构建角度保障软件的质量和安全。
|
||||
|
||||
\section{本章小结}
|
||||
本章基于软件的复杂加剧化、形态服务化、质量价值化、协作生态化的视角，从具有数据驱动、智能化、大规模、高复杂度、人机物融合等特征的角度分析了软件面临的质量和安全保障的重大挑战问题，在此基础上，从尚未充分探索解决的经典问题和新的重大挑战问题等角度展望软件质量和安全保障方面未来仍需研究的方向和内容。
|
||||
长期以来，软件质量一直是软件学科不可或缺的核心研究主题之一。在“软件定义一切”的时代，软件日益成为实现应用价值的核心载体，软件质量的核心价值观由强调“绝对正确”转变为强调“相对可信”；在人机物融合应用场景需求的牵引下，软件系统的规模和复杂性进一步增大，动态开放的运行环境使得安全性成为十分重要的质量属性，从而使得软件质量与安全保障面临一系列重大挑战，主要包括数据驱动的智能系统质量保障、 人机物融合场景下的系统可信增强、大规模复杂系统安全缺陷检测、物联网环境下的系统安全保障等。围绕这些挑战所开展的研究将主要集中在软件预期的外延扩展和符合性评估、开放空间下的缺陷分析与漏洞挖掘、系统动态行为监控与容错、智能系统测试、物联网环境下的安全测试技术、过程改进与预防式软件质量保障等方面，在此基础上建立人机物融合环境下的软件质量与安全可信保障方法与技术体系。
|
||||
|
||||
%
|
||||
%%\section{参考文献}
|
||||
%\begin{thebibliography}{7}
|
||||
|
|
|
|||
|
|
@ -3813,4 +3813,26 @@ keywords = {hypervisor, functional programming, microkernel}
|
|||
booktitle={Proceedings of the twenty-eighth annual ACM symposium on Theory of computing},
|
||||
pages={212--219},
|
||||
year={1996}
|
||||
}
|
||||
}
|
||||
%%added
|
||||
|
||||
@inproceedings{DBLP:conf/quatic/Rienstra95,
|
||||
author = {Folkert Rienstra},
|
||||
editor = {Carlos Campos Morais and
|
||||
Laxmiprasad Varajid{\'{a}}s and
|
||||
Fernando Brito e Abreu and
|
||||
Lu{\'{\i}}s Amaral},
|
||||
title = {{ISO} 9000 for Software Quality Systems},
|
||||
booktitle = {Proceedings of the 2nd International Conference on the Quality of
|
||||
Information and Communications Technology, {QUATIC} 1995, Lisboa,
|
||||
Portugal, December 4-6, 1995},
|
||||
series = {{CEUR} Workshop Proceedings},
|
||||
volume = {1471},
|
||||
pages = {1--9},
|
||||
publisher = {CEUR-WS.org},
|
||||
year = {1995},
|
||||
url = {http://ceur-ws.org/Vol-1471/paper1.pdf},
|
||||
timestamp = {Wed, 12 Feb 2020 16:44:31 +0100},
|
||||
biburl = {https://dblp.org/rec/conf/quatic/Rienstra95.bib},
|
||||
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue