A software architecture framework for quality-aware DevOps

Nitto, Elisabetta Di; Jamshidi, Pooyan; Guerriero, Michele; Spais, Ilias; Tamburri, Damian A.

doi:10.1145/2945408.2945411

Cited by 17 publications

(12 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…And more importantly, if safety and security coding (software) standards do not guarantee that the final robotic system will be secure, will it be safe given the safety and security connection? Some preliminary work [37,38] tackles the first question and indicates that Model-Driven Engineering (MDE) frameworks might allow a mix of DevSecOps with the functional safety process. Further research on these questions remains open for future efforts.…”

Section: Discussion and Future Workmentioning

confidence: 99%

DevSecOps in Robotics

Mayoral-Vilches¹,

García-Maestro²,

Towers³

et al. 2020

Preprint

View full text Add to dashboard Cite

Quality in software is often understood as "execution according to design purpose" whereas security means that "software will not put data or computing systems at risk of unauthorized access." There seems to be a connection between these two aspects but, how do we integrate both of them in the robotics development cycle? In this article we introduce DevSecOps in Robotics, a set of best practices designed to help roboticists implant security deep in the heart of their development and operations processes. First, we briefly describe DevOps, introduce the value added with DevSecOps and describe and illustrate how these practices may be implemented in the robotics field. We finalize with a discussion on the relationship between security, quality and safety, open problems and future research questions.

show abstract

Section: Discussion and Future Workmentioning

confidence: 99%

DevSecOps in Robotics

Mayoral-Vilches¹,

García-Maestro²,

Towers³

et al. 2020

Preprint

View full text Add to dashboard Cite

show abstract

“…Many studies contributed to the theory of NFRs in DevOps (26%, e.g., requirements prioritization criteria [35], share experiences and lessons learned in practice (17%) such as the capabilities and challenges of DevOps faced in industrial settings [9], or describe general advices for handling NFRs in DevOps (10%), such as the organizational change associated with DevOps adoption [36]. On the other side, 40% of the studies contribute concrete approaches, comprised of methods (17%) (e.g., for evaluating the fulfillment of NFRs towards value streams [37], frameworks (11%), (e.g., for guiding the evaluation of NFRs specially in DevOps [38]), models (9%) e.g., for feature ideation from user interactions [39], and tools (3%) for instance to support customer value estimation during feature ideation [40]. Processes for handling NFRs in DevOps are contributed by only 1% of the studies.…”

Section: Contribution Facets (Rq12)mentioning

confidence: 99%

“…• Continuous delivery: Reducing the failure rate after software changes through deploying the software in short cycles. Also, the aim is on gaining understanding of the impacts of the software change on operational characteristics and improve architectural decisions thereof [38]. • Development tool versatility: Assuring the suitability and flexibility of the development environments (e.g., IDEs, source code repositories, issue trackers) to support engineers in their development activities and the tracking between source code and compiled software on different systems.…”

Section: Themes and Objectives Behind Nfrs Of The Development Focus Areamentioning

confidence: 99%

Focus Areas, Themes, and Objectives of Non-Functional Requirements in DevOps: A Systematic Mapping Study

Haindl

Plösch

2020

2020 46th Euromicro Conference on Software Engineering and Advanced Applications (SEAA)

View full text Add to dashboard Cite

Context: Software non-functional requirements address a multitude of objectives, expectations, and even liabilities that must be considered during development and operation. Typically, these non-functional requirements originate from different domains and their concrete scope, notion, and demarcation to functional requirements is often ambiguous. Objective: In this study we seek to categorize and analyze relevant work related to software engineering in a DevOps context in order to clarify the different focus areas, themes, and objectives underlying non-functional requirements and also to identify future research directions in this field. Method: We conducted a systematic mapping study, including 142 selected primary studies, extracted the focus areas, and synthesized the themes and objectives of the described NFRs. In order to examine non-engineering-focused studies related to non-functional requirements in DevOps, we conducted a backward snowballing step and additionally included 17 primary studies. Results: Our analysis revealed 7 recurrent focus areas and 41 themes that characterize NFRs in DevOps, along with typical objectives for these themes. Overall, the focus areas and themes of NFRs in DevOps are very diverse and reflect the different perspectives required to align software engineering with technical quality, business, compliance, and organizational considerations. Conclusion: The lack of methodological support for specifying, measuring, and evaluating fulfillment of these NFRs in DevOps-driven projects offers ample opportunities for future research in this field. Particularly, there is a need for empirically validated approaches for operationalizing non-engineering-focused objectives of software.

show abstract

“…The focus-group sessions were structured as follows: (a) the practitioners were presented with a data-intensive architectural design using standard UML structure and behavior representations (a component view and an activity view [19]); (b) the practitioners were asked to identify and discuss any bottlenecks or structural limitations in the outlined designs; (c) finally, the practitioners were asked to illustrate any other antipattern the showcased topologies did not contain.…”

Section: Extracting Anti-patterns For Big Data Applicationsmentioning

confidence: 99%

Verifying big data topologies by-design: a semi-automated approach

et al. 2019

Self Cite

View full text Add to dashboard Cite

IntroductionBig data or data-intensive applications (DIAs) process large amounts of data for the purpose of gaining key business intelligence through complex analytics using machinelearning techniques [20,35]. These applications are receiving increased attention in the last years given their ability to yield competitive advantage by direct investigation of user needs and trends hidden in the enormous quantities of data produced daily by the average Internet user. According to Gartner [1] business intelligence and analytics applications will remain a top focus for Chief-Information Officers (CIOs) of most Fortune 500 companies until at least 2019-2021. However, the cost of ownership of the systems that process big data analytics are high due to infrastructure costs, steep learning curves for the different frameworks (such as Apache Storm [21], Apache Spark [2] or Apache Hadoop [3]) typically involved in design and development of big data applications and complexities in large-scale architectures.A key complexity of the above design and development activity lies in quickly and continuously refining the configuration parameters of the middleware and service platforms on top of which the DIA is running [12]. The process in question is especially complex as the number of middleware involved in DIAs design increases; the more middleware are involved the more parameters need co-evaluation (e.g., latency or beaconing times, caching policies, queue retention and more)-fine-tuning these "knobs" on so many Abstract Big data architectures have been gaining momentum in recent years. For instance, Twitter uses stream processing frameworks like Apache Storm to analyse billions of tweets per minute and learn the trending topics. However, architectures that process big data involve many different components interconnected via semantically different connectors. Such complex architectures make possible refactoring of the applications a difficult task for software architects, as applications might be very different with respect to the initial designs. As an aid to designers and developers, we developed OSTIA (Ordinary Static Topology Inference Analysis) that allows detecting the occurrence of common anti-patterns across big data architectures and exploiting software verification techniques on the elicited architectural models. This paper illustrates OSTIA and evaluates its uses and benefits on three industrial-scale case-studies. which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

show abstract

A software architecture framework for quality-aware DevOps

Cited by 17 publications

References 7 publications

DevSecOps in Robotics

DevSecOps in Robotics

Focus Areas, Themes, and Objectives of Non-Functional Requirements in DevOps: A Systematic Mapping Study

Verifying big data topologies by-design: a semi-automated approach

Contact Info

Product

Resources

About