DevOps in an ISO 13485 Regulated Environment: A Multivocal Literature Review

Background: Medical device development projects must follow proper directives and regulations to be able to market and sell the end-product in their respective territories. The regulations describe requirements that seem to be opposite to efficient software development and short time-to-market. As agile approaches, like DevOps, are becoming more and more popular in software industry, a discrepancy between these modern methods and traditional regulated development has been reported. Although examples of successful adoption in this context exist, the research is sparse. Aims: The objective of this study is twofold: to review the current state of DevOps adoption in regulated medical device environment; and to propose a checklist based on that review for introducing DevOps in that context. Method: A multivocal literature review is performed and evidence is synthesized from sources published between 2015 to March of 2020 to capture the opinions of experts and community in this field. Results: Our findings reveal that adoption of DevOps in a regulated medical device environment such as ISO 13485 has its challenges, but potential benefits may outweigh those in areas such as regulatory, compliance, security, organizational and technical. Conclusion: DevOps for regulated medical device environments is a highly appealing approach as compared to traditional methods and could be particularly suited for regulated medical development. However, an organization must properly anchor a transition to DevOps in top-level management and be supportive in the initial phase utilizing professional coaching and space for iterative learning; as such an initiative is a complex organizational and technical task.Comment: ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM '20), October 8--9, 2020, Bari, Ital

CHARTING PROGRESS IN THE SOFTWARE ACQUISITION PATHWAY

The Department of the Navy (DON) recently implemented the Department of Defense (DOD) Software Acquisition Pathway (SWP), a software acquisition strategy for custom application and embedded software. The purpose of the SWP is to enable rapid and iterative delivery of high-priority software capability to the intended user. But while the SWP uses an agile software development approach, neither the DOD nor the DON have yet provided comprehensive governance tools and methods for SWP programs to iteratively plan, track, and assess acquisition outcomes in agile environments. To close this gap, the author systematically researched commercial software engineering management and digital product development practices as well as prior DOD software acquisition reform studies. Based on the results, the author showed that Earned Value Management is incompatible with the SWP and recommended alternative techniques to measure cost and schedule performance. Additionally, the author recommended a phased approach to manage DON SWP custom application programs, whereby a minimal, unitless work breakdown structure is used to track progress until demonstrating the minimum viable product to the user in a testing environment; product-based metrics are then tracked until initial release of the custom application software; and then outcome-based goals are iteratively set, tracked, and assessed using the Objectives and Key Results framework for as long as the custom application software is in use.Captain, United States Air ForceApproved for public release. Distribution is unlimited

An Analysis of Multi-domain Command and Control and the Development of Software Solutions through DevOps Toolsets and Practices

Multi-Domain Command and Control (MDC2) is the exercise of command and control over forces in multiple operational domains (namely air, land, sea, space, and cyberspace) in order to produce synergistic effects in the battlespace, and enhancing this capability has become a major focus area for the United States Air Force (USAF). In order to meet demands for MDC2 software, solutions need to be acquired and/or developed in a timely manner, information technology infrastructure needs to be adaptable to new software requirements, and user feedback needs to drive iterative updates to fielded software. In commercial organizations, agile software development methodologies and concepts such as DevOps have been implemented to meet these demands. However, the USAF has been slow to adopt modern agile software development concepts such as DevOps in favor of traditional software development lifecycles and large contracts that can go nearly a decade without any value being released to the users. This work explores MDC2 software use cases and aims to show that MDC2 software can be successfully developed using modern agile software development practices in a timely manner

Continuous delivery

Treballs Finals de Grau d'Enginyeria Informàtica, Facultat de Matemàtiques, Universitat de Barcelona, Any: 2018, Director: Josep Vañó Chic[en] The project consists in researching, analyzing and implementing a deployment pipeline from scratch. During the implementation, a web-application called Funny Stories is created to demonstrate the way this kind of system works. To develop this system, a series of technologies were used. For the implementation of the application the tools used were Java 8 with the framework Spring Boot for the server side; HTML, jQuery, Bootstrap and CSS for the client side, and MySQL for managing the database. The web-site allows users to visualize stories posted by other people which are sorted by categories. They are also able to use a voting system to give their feedback for each post. The web-site is public and these features can be accessed by anyone. When integrating new features into an application and the process is manual, a lot of unforeseen error can happen which can end up delaying the delivery of the software by hours or days. This result in the developer not being able to show his work and delaying the release process which can affect the end users since they cannot use the product. A lot of pressure is put on the responsible for the integration and can end up in a lot of frustration. These problems are very common inside organizations and have inevitable outcome in the development process. These are indications that something is not right because the delivery should be fast and repeatable. This project looks at the delivery from another perspective and will present a series of practices which will improve the code integration. This will allow the developers to release their work several times a day while reducing the risks of the process. The release management of this application is done by using an automated deployment pipeline. This implies that whenever there is a change to the system, the deployment pipeline automatically rebuilds the entire application, tests it for errors and deploys it to the production environment

DevOps and software quality : a systematic mapping

Quality pressure is one of the factors affecting processes for software development in its various stages. DevOps is one of the proposed solutions to such pressure. The primary focus of DevOps is to increase the deployment speed, frequency and quality. DevOps is a mixture of different developments and operations to its multitudinous ramifications in software development industries, DevOps have attracted the interest of many researchers. There are considerable literature surveys on this critical innovation in software development, yet, little attention has been given to DevOps impact on software quality. This research is aimed at analyzing the implications of DevOps features on software quality. DevOps can also be referred to a change in organization cultures aimed at removal of gaps between the development and operations of an organization. The adoption of DevOps in an organization provides many benefits including quality but also brings challenges to an organization. This study presents systematic mapping of the impact of DevOps on software quality. The results of this study provide a better understanding of DevOps on software quality for both professionals and researchers working in this area. The study shows research was mainly focused in automation, culture, continuous delivery, fast feedback of DevOps. There is need of further research in many areas of DevOps (for instance: measurement, development of metrics of different stages to assess its performance, culture, practices toward ensuring quality assurance, and quality factors such as usability, efficiency, software maintainability and portability). Keywords: DevOps, development, operations, software, software quality, automation, measurement, systematic mappingpublishedVersio

DevOps for Digital Leaders

DevOps; continuous delivery; software lifecycle; concurrent parallel testing; service management; ITIL; GRC; PaaS; containerization; API management; lean principles; technical debt; end-to-end automation; automatio

DevOps for Digital Leaders

DevOps; continuous delivery; software lifecycle; concurrent parallel testing; service management; ITIL; GRC; PaaS; containerization; API management; lean principles; technical debt; end-to-end automation; automatio

A mapping study on documentation in Continuous Software Development

Context: With an increase in Agile, Lean, and DevOps software methodologies over the last years (collectively referred to as Continuous Software Development (CSD)), we have observed that documentation is often poor. Objective: This work aims at collecting studies on documentation challenges, documentation practices, and tools that can support documentation in CSD. Method: A systematic mapping study was conducted to identify and analyze research on documentation in CSD, covering publications between 2001 and 2019. Results: A total of 63 studies were selected. We found 40 studies related to documentation practices and challenges, and 23 studies related to tools used in CSD. The challenges include: informal documentation is hard to understand, documentation is considered as waste, productivity is measured by working software only, documentation is out-of-sync with the software and there is a short-term focus. The practices include: non-written and informal communication, the usage of development artifacts for documentation, and the use of architecture frameworks. We also made an inventory of numerous tools that can be used for documentation purposes in CSD. Overall, we recommend the usage of executable documentation, modern tools and technologies to retrieve information and transform it into documentation, and the practice of minimal documentation upfront combined with detailed design for knowledge transfer afterwards. Conclusion: It is of paramount importance to increase the quantity and quality of documentation in CSD. While this remains challenging, practitioners will benefit from applying the identified practices and tools in order to mitigate the stated challenges

Adoption of IT Governance Strategies for Multiproduct DevOps Teams: A Correlational Quantitative Study

Many multiproduct delivery organizations have difficulty adopting Information Technology (IT) governance practices within their Development and Operations (DevOps) teams. IT leaders who are managing DevOps teams, need to understand the factors influencing IT governance (ITG) adoption; otherwise this may impact DevOps maturity, resulting in reduced product delivery capabilities. Grounded in the technology acceptance model, the purpose of this quantitative correlational study was to examine the relationship between performance expectancy (PE), effort expectancy (EE), social influence (SI), and facilitating conditions (FC), as moderated by experience (EXP), gender (GND), age (AGE), and voluntariness of use (VOL) with behavioral intention (BI) to adopt and use (USE) IT governance (ITG), within their organizations. The participants (n=205) were IT leaders in various global professional LinkedIn groups, who specialized in DevOps and ITG-related frameworks. The results of the partial least squares analysis indicated that PE (p1=.234) and SI (p3=.655) have a positive correlation with the DevOps leaders’ BI to adopt ITG (R2=.692). FC (p4=.753) positively correlates with the adoption and USE of ITG (R2=.677). IT leaders who intend to use ITG practices (BI) in order to enhance DevOps capabilities need to engage relevant stakeholders (SI) through specific KPIs related to product delivery (PE) whilst leveraging ITG and DevOps expertise. Furthermore, ITG adoption is facilitated (FC) when implemented early in the DevOps transformation. The implications for positive social change include the potential to improve organizational culture and increase product quality through a sustainable IT environment