Merge branch 'master' of http://git.trustie.net/Dan_Hao/software-strategy-book

Ch2-4-DevelopmentMethodology.tex

@@ -10,11 +10,11 @@
 
 面向动态变化场景的人机物融合复杂系统\index{人机物融合复杂系统}，软件开发面临的首要挑战是融合人机物三元资源、以建模为核心的软件定义\index{软件定义}方法和技术。我们需要构建人机物三元资源及其行为的抽象、观察和度量的新模型和方法，研究基于软件定义方法的元级控制和数据赋能机理，使得软件开发方式（包括设计、构造和保障）从实体建模为主走向实体加链接，从分而治之走向群智聚合，从而有效驾驭各类软件复杂性。
 
-\section{重大挑战问题\xxm{建议本节补充若干主要参考文献引用}}
+\section{重大挑战问题}
 在人机物融合应用场景需求牵引下，软件开发方法和技术研究面临的重大挑战问题主要包括复杂场景分析与建模、群智开发、人机协作编程\index{人机协作编程}和开发运维一体化。
 
 \subsection{复杂场景分析与建模}
-人机物融合计算场景的需求在我们的日常生活中已经存在，大到智慧国家、智慧城市，小到网络家电、汽车引擎智能网络控制系统，对这类计算场景的分析和建模存在许多挑战，其中主要的挑战包括如下几个方面。
+人机物融合计算场景的需求在我们的日常生活中已经存在，大到智慧国家、智慧城市，小到网络家电、汽车引擎智能网络控制系统，对这类计算场景的分析和建模存在许多挑战~\cite{jin2018environment, 10.5555/2208018, 10.1109/MC.2014.30}，其中主要的挑战包括如下几个方面。
 \subsubsection{与日俱增的规模与复杂度}
 
 首先，从已经出现的支撑人机物融合计算场景的系统来看，其系统的大小和复杂性显著增加。例如，现代汽车中基于软件的功能在不断地持续增加\cite{zhang2017software}。2007年经典高端轿车包含大约270个与驾驶员互动的软件实现的功能，而最新的高端轿车包含超过500个这样的功能。轿车软件的规模也在大幅增长。2007年高端轿车的二进制代码量约为66兆字节，而现在这类轿车则含超过1千兆字节的二进制代码。随着软件支持的功能的数量和规模的增加，复杂性也随之增加。这些基于软件的功能要求各个子系统，例如刹车系统、发动机管理系统、驾驶辅助系统等，具备更细粒度的功能，以及子系统之间密集的交互，因而整个系统的复杂性大大增加，对系统的分析和建模需要从方法和技术上得到全面提升。
@@ -31,7 +31,7 @@
 \subsubsection{情境感知和适应性}
 
 除了复杂度和不确定性带来的挑战外，新算法新技术引入的系统能力，也是人机物融合计算场景对软件系统的分析和建模的挑战。例如，与手机与全球定位系统位置设备耦合的电子导航系统，以及执行从交通冲突检测到自动间隔和车道跟踪任务的自动装置，正逐步被辅助驾驶软件系统所采用，这些新的能力使软件系统与物理环境能更加融合，使软件系统能够了解周围的整体情况，从而做出更好的在线决策。新技术和新能力的引入使得软件系统常常要在与其设计时明显不同的条件下运行。 
-执行时，交互和运行情境的动态变化是一个重要特征，软件系统不仅要能够适应各种交互和运行环境的变化，还应能够在遇到变化时继续可靠地执行，需要广泛的适应性。软件系统的分析和建模需要考虑在线决策的能力，这种能力所要求的不仅是简单地认识环境状态，还高度依赖于情境感知能力，支持对环境状态的不断演变的认识。
+执行时，交互和运行情境的动态变化是一个重要特征，软件系统不仅要能够适应各种交互和运行环境的变化，还应能够在遇到变化时继续可靠地执行，需要广泛的适应性~\cite{Sifakis2019Auton}。软件系统的分析和建模需要考虑在线决策的能力，这种能力所要求的不仅是简单地认识环境状态，还高度依赖于情境感知能力，支持对环境状态的不断演变的认识。
 
 \subsubsection{创新使能的需求演化性}
 
@@ -64,12 +64,12 @@
 \subsection{人机协作编程}
 在现有的软件开发活动中，几乎每一行程序（高级语言编写的代码）都需要人类程序员手工编写，随着对软件的需求进一步地增长，以及软件复杂度进一步地提升，这种几乎全手工的编程方式将成为制约计算机行业发展的瓶颈。只有大幅度提升机器编程的占比，并将程序员的主要工作更多地放在少数对创造性具有极高要求的活动上，才能够突破这一瓶颈。因此，需要将程序员统领开发环境完成编程任务的模式转变为程序员与机器各司其职又相互协作完成编程任务的模式。实现人机协作编程的挑战主要来自两个方面：1、如何提升机器编程的能力；2、如何实现人机无障碍协作。
 
-提升机器编程的能力是实现人机协作编程的基础，软件自动化是提升机器编程能力的主要技术手段。人们对软件自动化的探索几乎是伴随着软件的出现而开始的，由于早期的软件开发（编程）是异常繁琐易错的工作，人们很早就开始考虑将编程中机械性的工作交给机器完成。然而，软件自动化也一直没有完全达到人们的期望，导致软件开发长期属于严重依赖开发人员个人能力的活动。传统的软件自动化技术以严格的规约作为输入，通过机器将规约翻译成程序代码或者通过搜索技术找到符合规约的程序代码：前者的典型代表是编译器，也是软件自动化方面到目前为止最为成功的尝试，但随着抽象层次的提高，人们发现很难通过固定的规则完成所有可能的翻译；后者的典型代表是程序合成，但由于程序空间过于庞大，目前能够通过搜索获得程序通常仅限于规模很小的程序。近年来，随着数据的广泛积累，数据驱动的方式在很多领域取得了前所未有的成功，类似地，长期累积的海量代码数据为软件自动化带来了新的可能性，为提升机器编程能力带来了新的希望。数据驱动的软件自动化可以利用已有代码数据中总结出来的规律指导搜索，从而提升程序合成的效率，同时这种不依赖严格推理的模式又易于处理半形式化甚至非形式化的规约，从而扩大软件自动化技术的适用范围。由于程序空间是无限空间，已有程序代码在整个空间里仍然很稀疏，而程序代码又受到问题领域、技术进步、开发者习惯的影响展现出很强的异质性，如何从已有程序代码总结规律存在巨大的挑战。
+提升机器编程的能力是实现人机协作编程的基础，软件自动化是提升机器编程能力的主要技术手段。人们对软件自动化的探索几乎是伴随着软件的出现而开始的，由于早期的软件开发（编程）是异常繁琐易错的工作，人们很早就开始考虑将编程中机械性的工作交给机器完成。然而，软件自动化也一直没有完全达到人们的期望，导致软件开发长期属于严重依赖开发人员个人能力的活动。传统的软件自动化技术以严格的规约作为输入，通过机器将规约翻译成程序代码或者通过搜索技术找到符合规约的程序代码：前者的典型代表是编译器，也是软件自动化方面到目前为止最为成功的尝试，但随着抽象层次的提高，人们发现很难通过固定的规则完成所有可能的翻译；后者的典型代表是程序合成，但由于程序空间过于庞大，目前能够通过搜索获得程序通常仅限于规模很小的程序。近年来，随着数据的广泛积累，数据驱动的方式在很多领域取得了前所未有的成功，类似地，长期累积的海量代码数据为软件自动化带来了新的可能性，为提升机器编程能力带来了新的希望~\cite{mei2018can}。数据驱动的软件自动化可以利用已有代码数据中总结出来的规律指导搜索，从而提升程序合成的效率，同时这种不依赖严格推理的模式又易于处理半形式化甚至非形式化的规约，从而扩大软件自动化技术的适用范围。由于程序空间是无限空间，已有程序代码在整个空间里仍然很稀疏，而程序代码又受到问题领域、技术进步、开发者习惯的影响展现出很强的异质性，如何从已有程序代码总结规律存在巨大的挑战。
 
 与人工编程相比，机器编程的优势在于机器编程可以利用计算机的强大计算能力，劣势在于机器编程主要从已有代码中学习，缺乏有效处理边角信息的能力，因此高效的人机协作将能更好地发挥两者的优势。支持高效人机互动的开发环境\index{开发环境}一直是软件工程关注的重点之一，最早的开发环境只是一系列工具的简单堆叠，真正意义上的开发环境是在上世纪八十年代以后发展起来的，这类开发环境的主要特点在于，开发者是整个开发环境的主导，开发环境是开发者的操控台和延伸，进入到新世纪开发环境有两个新的发展趋势：1、开发环境中开始出现一些智能服务（如代码推荐等），虽然能够进入主流开发环境的智能服务仍十分有限，但学术界研究的智能工具多以开发环境的插件形式展现；2、开发环境开始支持开发者间的交互，虽然这与开发者间远程协作需求的增长有关（本地协作中开发者可以进行面对面的交流），但却为探索多开发者协同提供了有益尝试。为了满足人机协作编程的需要，开发环境需要应对以下两方面的挑战：1、建立开发者对机器编程的信任关系：在开发者主导的环境中开发者更多依赖自己的主观判断，但在人机协作环境中开发者完全可控的范围缩小将更依赖机器编程，如果开发者不能确信机器编程能否完成特定任务，就会严重影响开发效率；2、实现人机多渠道交互：现有开发环境中的人机交互以及开发者间的交互方式主要以文本方式进行，而人类通常习惯同时以多种方式进行交流，这样才能更好激发开发者的创造力。
 
 \subsection{开发运维一体化}
-软件开发是人类的一项高复杂度的集体智力活动，其现实问题的复杂度反映到开发中主要表现为架构、过程、技术和组织四个维度上的复杂度，它们往往紧密地交织纠缠在一起并相互转化。软件工程在这四个维度上发展趋势，即架构逐渐去中心化，技术趋于平台化、自动化和虚拟化，过程趋于增量和迭代，组织趋于小而自治，开发运维一体化（DevOps）集中体现了这些发展趋势的高阶形态。随着互联网化和服务化的高度发展和走向成熟使得未来的软件更加需要具备持续（Continuous）的特征。这种持续性将覆盖从商业策划、开发到运维以及演化的所有环节，使得未来软件系统像具有生命一般：在持续稳定提供服务的同时，软件系统的边界、发展走向等不再固化，而是始终处在不断变化和适应之中。持续性与上述的架构、过程、技术与组织四个维度的复杂性交织在一起，再叠加性能、安全等质量要求和实效性要求等，使得未来的软件系统的开发和运维面临诸多的挑战，这就需要我们在原则、方法、实践以及工具层面都做要充分的应对。
+软件开发是人类的一项高复杂度的集体智力活动，其现实问题的复杂度反映到开发中主要表现为架构、过程、技术和组织四个维度上的复杂度，它们往往紧密地交织纠缠在一起并相互转化。软件工程在这四个维度上发展趋势，即架构逐渐去中心化，技术趋于平台化、自动化和虚拟化，过程趋于增量和迭代，组织趋于小而自治，开发运维一体化（DevOps）集中体现了这些发展趋势的高阶形态。随着互联网化和服务化的高度发展和走向成熟使得未来的软件更加需要具备持续（Continuous）的特征~\cite{FITZGERALD2017176}。这种持续性将覆盖从商业策划、开发到运维以及演化的所有环节，使得未来软件系统像具有生命一般：在持续稳定提供服务的同时，软件系统的边界、发展走向等不再固化，而是始终处在不断变化和适应之中。持续性与上述的架构、过程、技术与组织四个维度的复杂性交织在一起，再叠加性能、安全等质量要求和实效性要求等，使得未来的软件系统的开发和运维面临诸多的挑战，这就需要我们在原则、方法、实践以及工具层面都做要充分的应对。
 
 \subsubsection{构建按需（On-Demand）的基础设施}
 作为DevOps产生的技术和平台基础，基础设施(Infrastructure)可能是未来DevOps能够发挥更大作用的关键环节。然而，如何匹配软件系统运行需求（或者企业需求）来构建适用的基础设施一直是需要重点关注的话题。值得关注的几个挑战包括：1）混合云\index{混合云}，即为了更好的适应各种业务场景，混合云是一种合理的选择，但是由此带来的异构、安全、可扩展等方面的挑战不容忽视；2）边缘计算，即为了尽可能减少数据传输代价，就近提供计算服务是一种选择，但是，这会大大增加基础设施的复杂程度，带来软件系统部署和维护方面的巨大挑战。3）基础设施自动化和智能化，即提供自动化和智能化类的处理流程来进行基础设施的管理和维护。现有IT基础设施和环境往往已经足够复杂，同时也缺乏跨系统、平台以及流程的可见性，叠加基础设施、运行其上的软件系统和业务往往都是紧耦合的，这些因素都给自动化和智能化带来了巨大挑战。此外，为基础设施注入内建安全机制等也都是未来支撑DevOps发展的IT基础设施亟待解决的挑战。
@@ -78,13 +78,14 @@
 DevOps 持续高效高质量的交付有赖于高度自动化支持工具的支持，自动化也是获得快速反馈的关键。鉴于DevOps自动化支持工具涉及多个阶段，种类繁多，数量上已达数千种，从诸多关系复杂的工具中理解和选择合适的工具集合来搭建流水线对 DevOps 实践者来讲至关重要，但也非常具有挑战性。未来，部分重要的基础性工具将向少数较成熟的工具收敛（如在持续构建、自动化部署、服务治理等方面），但是，更多的DevOps的自动化支持工具将向更加专业化发展。即构建的流水线往往面向特定应用领域（例如金融行业对安全性和合规性有着极高要求）或包含其他专业组建（例如，人工智能、大数据等），因而，如果提供开箱即用的工具链方案，帮助企业选择并定制适合其业务的DevOps工具链是一个巨大的挑战。此外，随着软件项目的持续进展，DevOps流水线会产生大量的数据，例如，工具链自身产生的数据，在研软件系统在验证过程中产生的数据以及DevOps项目执行产生的数据等等。如何将流程与数据两个维度打通，提供以DevOps流水线为基础的开发运维一体化协作平台，进而提升其智能化水平，在此基础上提升DevOps实践的效率和质量，同样也是为了支持前文所述的持续性，从工具链和生产环境角度需要需要解决的重大挑战之一。
 
 \subsubsection{微服务化架构演化策略和评估手段}
-微服务\index{微服务}化是支持前文提及的持续性要求的必备条件。软件系统的微服务化要求软件系统的各个模块或服务间的耦合进一步降低，从而在新版本发布或者部分服务出现问题时不会影响到系统其它部分。企业系统架构的微服务化以更好地支持DevOps已成为行业共识和趋势，然而在演化过程中却面临诸多挑战。首先，如何进行合理的服务划分，即将软件系统拆分成多个独立自治且协同合作的服务，是微服务应用实现敏捷、灵活和高可扩展的先决条件，也是微服务领域的一项严峻挑战。其次，虽然服务拆分为开发和维护提供诸多便利，但在另一方面，服务数量的增加也带来了系统整体测试复杂度的增长。例如，当采用微服务架构之后，系统对远程依赖项的依赖较多，而对进程内组件的依赖较少，因此测试策略和测试环境需要适应这种变化。微服务化的系统不仅需要保证组件内部的正确性，还需要通过契约测试等保证组件间通信和交互的正确性，使得众多微服务能够真正实现协同工作。相应地，微服务联调、日志分析与故障定位、自动化监控告警与治理策略等是当前以及未来较长时间内的研究中需要探索的迫切问题。此外，缺乏普遍适用的架构演化评估手段也是当前面临的挑战。微服务架构并不一定适合所有的企业情况，因此，在演化过程中，应该通过哪些角度去判断架构拆分的效果？如何建立这些角度与业务需求之间的对应关系？如何度量微服务拆分效果并及时给出建议（包括补充替代的架构形式）等方面都存在若干亟需解决的问题。
+微服务\index{微服务}化是支持前文提及的持续性要求的必备条件。软件系统的微服务化要求软件系统的各个模块或服务间的耦合进一步降低，从而在新版本发布或者部分服务出现问题时不会影响到系统其它部分。企业系统架构的微服务化以更好地支持DevOps已成为行业共识和趋势，然而在演化过程中却面临诸多挑战~\cite{Microservices2017ICSA}。首先，如何进行合理的服务划分，即将软件系统拆分成多个独立自治且协同合作的服务，是微服务应用实现敏捷、灵活和高可扩展的先决条件，也是微服务领域的一项严峻挑战。其次，虽然服务拆分为开发和维护提供诸多便利，但在另一方面，服务数量的增加也带来了系统整体测试复杂度的增长。例如，当采用微服务架构之后，系统对远程依赖项的依赖较多，而对进程内组件的依赖较少，因此测试策略和测试环境需要适应这种变化。微服务化的系统不仅需要保证组件内部的正确性，还需要通过契约测试等保证组件间通信和交互的正确性，使得众多微服务能够真正实现协同工作。相应地，微服务联调、日志分析与故障定位、自动化监控告警与治理策略等是当前以及未来较长时间内的研究中需要探索的迫切问题。此外，缺乏普遍适用的架构演化评估手段也是当前面临的挑战。微服务架构并不一定适合所有的企业情况，因此，在演化过程中，应该通过哪些角度去判断架构拆分的效果？如何建立这些角度与业务需求之间的对应关系？如何度量微服务拆分效果并及时给出建议（包括补充替代的架构形式）等方面都存在若干亟需解决的问题。
 
 \subsubsection{DevOps高频交付带来的质量和安全问题}
-质量和安全一直都不是新问题。然而，在DevOps语境下，在高水平自动化支持下的快速高频交付是维系持续性的基础，但同时也使得传统的质量和安全问题都有了新的含义和内容。例如，通过各类工具来实现自动化验证和确认是DevOps实践中的不二选择。然而，现有工具在发现并且消除缺陷和隐患的效率和效能方便并不完全令人满意，在快节奏和高度自动化的交付过程中，以往的交叉检验和人工分析等质量手段往往也被略去，不可避免地增加了很多质量风险。大量研究和实践表明，DevOps和Security合规往往在实践中处于天然对立关系，这种对立不是通过“构造”DevSecOps一个词汇能解决的。如何协调上述的对立是一个棘手问题。其次，现代软件系统的弱点（Vulnerability）往往有多种来源和根本原因，例如来自上述基础设施的安全威胁、DevOps的快节奏所导致的各种妥协、质量缺陷、大量第三方组件的安全威胁、自动化运维中的安全隐患、企业文化（流程、人员技能和意识等）导致的安全疏漏等等。所谓百密一疏，尽管有一些工具、方法以及实践可以一定程度上缓解上述各种威胁带来的压力，但显然在效果和效率方面还有一些不足。从这个意义上说，退而求其次的方式是采取事后方式——通过监控系统运行过程尤其是通过分析系统异常来辅助发现安全风险。但是，这种方式还是有两大急需解决的难题，即1）如何产生可靠的高质量运行相关的数据（例如日志信息）以及2）如何应用先进的技术（例如大数据、AI技术等）提升对数据的利用效率和分析数据发现质量和安全性风险的能力。
+质量和安全一直都不是新问题。然而，在DevOps语境下，在高水平自动化支持下的快速高频交付是维系持续性的基础，但同时也使得传统的质量和安全问题都有了新的含义和内容~\cite{DevSecOps2017Review}。例如，通过各类工具来实现自动化验证和确认是DevOps实践中的不二选择。然而，现有工具在发现并且消除缺陷和隐患的效率和效能方便并不完全令人满意，在快节奏和高度自动化的交付过程中，以往的交叉检验和人工分析等质量手段往往也被略去，不可避免地增加了很多质量风险。大量研究和实践表明，DevOps和Security合规往往在实践中处于天然对立关系，这种对立不是通过“构造”DevSecOps一个词汇能解决的。如何协调上述的对立是一个棘手问题。其次，现代软件系统的弱点（Vulnerability）往往有多种来源和根本原因，例如来自上述基础设施的安全威胁、DevOps的快节奏所导致的各种妥协、质量缺陷、大量第三方组件的安全威胁、自动化运维中的安全隐患、企业文化（流程、人员技能和意识等）导致的安全疏漏等等。所谓百密一疏，尽管有一些工具、方法以及实践可以一定程度上缓解上述各种威胁带来的压力，但显然在效果和效率方面还有一些不足。从这个意义上说，退而求其次的方式是采取事后方式——通过监控系统运行过程尤其是通过分析系统异常来辅助发现安全风险。但是，这种方式还是有两大急需解决的难题，即1）如何产生可靠的高质量运行相关的数据（例如日志信息）以及2）如何应用先进的技术（例如大数据、AI技术等）提升对数据的利用效率和分析数据发现质量和安全性风险的能力。
 
 \subsubsection{智能化运维}
 作为DevOps中的Ops一端，运维的重要性越来越突显。工业界目前已经开始实践智能化运维（AIOps）技术以有效降低运维成本、提高运维效率和质量。我们注意到，随着各类AI技术和方法的迅速发展，智能化运维尽管已经有了较为坚实的基础，但是其有效实施却直接依赖于软件系统或者服务的运行时产生的各类数据和信息的质量。目前智能化运维主要提供一些相对简单的标准化日志信息的捕获、分析和决策；同时，当前的AIOps主要关注在运维一侧，尚未有效形成运维-开发的反馈闭环，以支持开发团队高效应对运维变化的新需求。此外，智能化运维依赖的各类数据和信息也都有各自缺点：日志数据的产生主要依赖程序员的个人经验，实践中往往日志实践开展的质量很差，导致大部分日志文件中充斥着毫无价值的垃圾信息，难以支持对软件行为的有效捕获；指标数据则是一种隔靴搔痒的环境数据，对错误定位的支持非常有限；跟踪路径数据会在瞬间产生巨量数据，导致完全无法分析。因此，如何充分使用这三类数据，在更加精细的力度上捕获软件应用或者服务的行为，进而提供更加准确的信息供分析，这是智能化运维需要解决的关键问题。
+
 \subsubsection{支撑DevOps规模化的组织与管理}
 DevOps整合了开发团队与运维团队，使其成为一个整体，这使得团队的组织、文化和软件过程都与单纯的开发团队和运维团队有所不同。同时，团队的规模也不可避免的有所增加，降低了团队面对面沟通的效率。DevOps是受到敏捷软件开发的影响而产生的，天然带有敏捷基因并植根于精益思想。然而，敏捷方法的很多理念和实践并不能天然应用于DevOps。例如，常规敏捷方式鼓励着眼当前问题同时通过承担一定程度的技术负债来应对未来的多种可能变化。这种寻求局部最优解的思维方式并不利于打破各个部门之间的壁垒。又如，在敏捷宣言鼓励之下的“重代码轻文档”工作方式对于持续性的维持还是弊大于利，毕竟我们不会轻易终止一款软件系统。另一方面，随着开发和维护的软件系统越来越复杂，其规模也越来越大，在开发运维团队合并后，必然要求团队规模也相应扩大，团队之间的协作和交流也会更加复杂。敏捷社区提出了SAFe（Scaled Agile Framework）来支持更大规模的团队，目前已经列入DevOps相关内容。然而，也有很多人批评SAFe过于复杂，违背了敏捷的基本价值观。从这个意义上说，如何在大规模团队中实施DevOps仍将成为未来一段时间研究者和实践者需要解决的问题。
 

references.bib

@@ -1,3 +1,118 @@
+@article{mei2018can,
+  title={Can big data bring a breakthrough for software automation?},
+  author={Mei, Hong and Zhang, Lu},
+  journal={Science China Information Sciences},
+  volume={61},
+  number={5},
+  pages={056101},
+  year={2018},
+  publisher={Science China Press}
+}
+
+@article{10.1109/MC.2014.30,
+author = {Broy, Manfred and Schmidt, Albrecht},
+title = {Challenges in Engineering Cyber-Physical Systems},
+year = {2014},
+issue_date = {February 2014},
+publisher = {IEEE Computer Society Press},
+address = {Washington, DC, USA},
+volume = {47},
+number = {2},
+issn = {0018-9162},
+url = {https://doi.org/10.1109/MC.2014.30},
+doi = {10.1109/MC.2014.30},
+journal = {Computer},
+month = feb,
+pages = {70–72},
+numpages = {3},
+keywords = {systems engineering, Software testing, ubiquitous computing, Technological innovation, Navigation, cyber-physical systems, Computer science, invisible computing, Educational institutions, Physical layer}
+}
+
+
+
+@book{10.5555/2208018,
+author = {Endsley, Mica R.},
+title = {Designing for Situation Awareness: An Approach to User-Centered Design, Second Edition},
+year = {2011},
+isbn = {1420063553},
+publisher = {CRC Press, Inc.},
+address = {USA},
+edition = {2nd}
+}
+
+
+
+
+@book{jin2018environment,
+  title={Environment Modeling-Based Requirements Engineering for Software Intensive Systems},
+  author={Jin, Zhi},
+  isbn={9780128019573},
+  url={https://books.google.com.sg/books?id=wLV7BgAAQBAJ},
+  year={2018},
+  publisher={Elsevier Science}
+}
+
+
+@Inbook{Sifakis2019Auton,
+author="Sifakis, Joseph",
+editor="Boreale, Michele
+and Corradini, Flavio
+and Loreti, Michele
+and Pugliese, Rosario",
+title="Autonomous Systems -- An Architectural Characterization",
+bookTitle="Models, Languages, and Tools for Concurrent and Distributed Programming: Essays Dedicated to Rocco De Nicola on the Occasion of His 65th Birthday",
+year="2019",
+publisher="Springer International Publishing",
+address="Cham",
+pages="388--410",
+}
+
+@article{FITZGERALD2017176,
+title = "Continuous software engineering: A roadmap and agenda",
+journal = "Journal of Systems and Software",
+volume = "123",
+pages = "176 - 189",
+year = "2017",
+issn = "0164-1212",
+doi = "https://doi.org/10.1016/j.jss.2015.06.063",
+url = "http://www.sciencedirect.com/science/article/pii/S0164121215001430",
+author = "Brian Fitzgerald and Klaas-Jan Stol",
+keywords = "Continuous software engineering, Lean software development, DevOps",
+}
+
+@INPROCEEDINGS{Microservices2017ICSA,
+author={P. D. {Francesco} and I. {Malavolta} and P. {Lago}},
+booktitle={2017 IEEE International Conference on Software Architecture (ICSA)},
+title={Research on Architecting Microservices: Trends, Focus, and Potential for Industrial Adoption},
+year={2017},
+volume={},
+number={},
+pages={21-30},
+keywords={software architecture;microservices;industrial adoption;enterprise world;systematic mapping;Data mining;Systematics;Market research;Service-oriented architecture;Computer architecture;Architecture;Microservices;Software Architecture;Systematic Mapping Study},
+doi={10.1109/ICSA.2017.24},
+ISSN={null},
+month={April},}
+
+
+
+@InProceedings{DevSecOps2017Review,
+author="Myrbakken, H{\aa}vard
+and Colomo-Palacios, Ricardo",
+editor="Mas, Antonia
+and Mesquida, Antoni
+and O'Connor, Rory V.
+and Rout, Terry
+and Dorling, Alec",
+title="DevSecOps: A Multivocal Literature Review",
+booktitle="Software Process Improvement and Capability Determination",
+year="2017",
+publisher="Springer International Publishing",
+address="Cham",
+pages="17--29",
+}
+
+
+
 
 @Book{brooks1995the,
  author = {Brooks, Frederick},