Search

With the rise of cloud computing platforms, the speed of developing software has drastically increased. This increased speed requires new models of operating hardware, as the separation of development and operations departments often leads to bottlenecks in the deployment process. DevOps techniques aim at improving the collaboration between development and operation teams, promising to reduce the time until new products reach the customer and improving software quality. GitOps is a new concept claiming to be the evolution of DevOps. This paper analyzes if GitOps is really an evolution of DevOps, as in making DevOps obsolete. As neither DevOps nor GitOps have a standard definition, this paper synthesizes a definition of both concepts and compares them by their key elements. We find that GitOps is not the evolution of DevOps although they share common concepts. However, both concepts are defined by their use in industry, so additional research is required.

Many software engineering tools build and evaluate their models based on historical data to support development and process decisions. These models help us answer numerous interesting questions, but have their own caveats. In a real-life setting, the objective function of human decision-makers for a given task might be influenced by a whole host of factors that stem from their cognitive biases, subverting the ideal objective function required for an optimally functioning system. Relying on this data as ground truth may give rise to systems that end up automating software engineering decisions by mimicking past sub-optimal behaviour. We illustrate this phenomenon and suggest mitigation strategies to raise awareness.

Self-adaptation gives software systems the ability to adjust their behavior or structure in changing environments such as the health software domain However, adaptability significantly complicates software implementation and brings great challenges to software engineering This paper proposes an Adaptive Healthcare Software Architecture (AHSA), which is based on international health standards and offers at-runtime adaptation Three components (Dynamic Linker, Runtime Locator, and Autonomous Component) have been specified to compose AHSA A tool called AdaptiveHIS has also been developed to dynamically generate AHSA components, and this generation is exemplified through an algorithm Within two real-world COVID-19 pandemic healthcare scenarios, an assessment compared the adaptability of AHSA and other software architectures built using state-of-art tools Results based on the level of system adaptability metric respectively showed that AHSA offered 20% and 72% more adaptability in the two real-world scenarios IEEE

There are three technologies a modern AI-aware software engineer needs to know: data mining, theorem proving, and nonlinear optimization (also called search-based SE). While much of the current industrial AI activity is focused on data mining, these other technologies are starting to achieve prominence. Optimization technology is discussed in the editorial “A Watershed Moment for Search-Based Software Engineering” (see IEEE Software, July-August 2021). Here, we offer a tutorial on theorem proving (what it is, how to use it, how it can sometimes go wrong, and how to fix that).

Many data-driven software systems present dependability challenges caused by the distribution and dynamicity of their application environments. We investigate machine learning-driven construction techniques combined with pattern-based architecture, showing that system dependability is linked to data and function quality.

This article presents approaches for performance improvements into two large and well-known open source projects, Git and GNU Compiler Collection, using parallel programming. We share the difficulties faced and the strategies used, concluding with a set of lessons learned that are useful to similar parallelization processes.

To learn about novel software engineering (SE) trends, where do you refer to? In order to document and disseminate their experience / knowledge, many SE practitioners prepare technical materials and share them online as blog posts, white papers and videos. Such materials are often called “grey literature” because they are not formally peer reviewed. By contrast, SE researchers write technical papers that are peer-reviewed and published as academic literature. We observe that, in general, these two communities mostly read literature that is only written by and published within their respective communities. This situation has led to a form of “knowledge divide” between the two communities that, we believe, hurts both communities. By characterizing and contrasting the two types of literature, grey and academic, we discuss how each literature can complement the other and can lead to a richer and more integrated knowledge exchange and dissemination in SE.

Time Pressure means that time experienced by an individual is scarce in relation to the task demands at hand. In this article, we summarize findings and provide practitioner takeaways based on a systematic review of existing literature. We find that most empirical evidence supports reduced quality, increased productivity, and negative effects on individuals under time pressure. Time pressure is caused by company culture, poor effort estimates, and project management. The effects of time pressure can be explained by Challenge and Hindrance time pressure, the Yerkes-Dodson Law and The Job Demands-Resources model. Finally we conclude the article by giving practitioner takeaways related to minimizing the negative effects of time pressure.

We currently find ourselves in a surprising situation: we understand software architecture fairly well, but we find it difficult to put it into practice. This is because most software developers work within iterative processes that focus attention on what’s new, and because factory-inspired metaphors encourage ever-quicker movement from feature requests to deployed code. How did that happen? Explores changes in software development management and reports on where it is headed in the near future.

Software engineering is about understanding and making the right tradeoffs. Many software engineering tasks-such as test case generation, design, sprint planning, and refactoring-boil down to understanding tradeoffs including concretely expressing the attributes to optimize and elements and decisions that will maximize their intended outcomes. Consequently, many software engineering problems can be formulated as search problems. Driven by these observations, Harman and Jones in 2001 emphasized the importance of concentrated research on the application of search-based techniques in software engineering and coined the subfield of search-based software engineering (SBSE) in software engineering research.1 During the two decades that followed, SBSE has seen a significant amount of increased research where metaheuristic algorithms are used to create recommendations for software engineering tasks.

How can artificial intelligence help software engineers better do their jobs and advance the state of the practice? We describe three productivity tools that learn patterns from software artifacts: code search using natural language, code recommendation, and automatic bug fixing.

Software and systems engineering practitioners have the option to work with a very wide range of requirements specification methods. I view these as requirements languages. A subset of practitioners additionally has a compelling interest in using requirements methods that are suitable for very large-scale enterprise projects.1-4

Programming mistakes of all kinds-in source code, configurations, tests, or other artifacts-are a wide-ranging and expensive problem. Developers dedicate a significant proportion of engineering time and effort to finding and fixing bugs in their code, businesses lose market share when vulnerabilities in the software they sell impact customers, and overall productivity is impacted by software that does not work as intended or is prone to vulnerabilities.1 Rapidly finding and fixing bugs and vulnerabilities only grows in importance as software is continuously evolving and deployed and as society becomes increasingly dependent on software systems in all aspects of modern life. Speaking to this general problem, this special issue of IEEE Software addresses recent advances in research and practice in automatic software repair.

Writing reliable software is hard. No matter how determined we all are to avoid it, we do make mistakes and at a fairly predictable rate. What makes a software system reliable is not determined just by the care we take in planning and structuring a design but also by the methods we use in catching those pesky bugs that come along for the ride. For safety-critical code, the use of strong static source code analyzers has become an essential part of the development process. The best analyzers are based on solid theory and maintained by large teams of highly skilled developers. The tools can patiently trace through complex execution paths to reveal a range of subtle bugs, although, of course, only the types of bugs the tools have been trained on. The tools can be slow and costly, though, and the warnings they generate are sometimes difficult for humans to evaluate accurately.

High dependability software systems must be developed and maintained using rigorous safety-assurance practices. By leveraging traceability, we can visualize and analyze changes as they occur, mitigate potential hazards, and support greater agility.

Your software projects never quite go as smoothly as the textbooks promise, do they? The article explains where the fog of design comes from and tells you how to handle it.

Presents papers from the 2020 IEEE Conference on Requirements Engineering and the ACM/ IEEE 23rd International Conference on Model Driven Engineering Languages and Systems (MODELS 2020).

RESTful APIs are very popular in industry, especially when developing enterprise systems using a microservice architecture. Testing such APIs is challenging, as tests will be composed of not only HTTP calls, but also settings of the environment, like databases. Different blackbox testing techniques have been shown to easily find real faults in many RESTful APIs, with very little human effort from software engineers. However, whitebox techniques could lead to much better results, although having an up-front cost for the engineers. In this paper, we report on the use of the open-source tool EvoMaster, on eight RESTful APIs. We show how EvoMaster can be used to automatically generate test cases that can find several bugs, even when using a naive blackbox approach. When enhancing the search with whitebox information, significantly better results are achieved. However, there are several challenges that need to be taken into account when an engineer wants to use a tool such as EvoMaster to test their projects. This work is funded by the Research Council of Norway (project on Evolutionary Enterprise Testing, grant agreement No 274385).

In recent years, automated software verification has progressed significantly. We can now effectively explore complex software structures through automated testing or to prove properties of complex programs, such as compilers using formal methods. But, for the most part, software testing and formal software verification techniques have advanced independently with relatively few insights on how their research thrusts compare or can be combined.

Affirmative action in college admissions has been touted as a way to close the gender gap in science, technology, engineering, and mathematics programs. We report a study of one such program, where we discovered a positive effect on female enrollment and a smaller effect on a combined computer science and software engineering degree.

International audience; Modelling languages and frameworks have been the key technology for advancing Model-Driven Engineering (MDE) methods and tools. Many industrial and research tools have been realised and are used across many domains. Hence, we think it is the right time to define what should be the future of modelling technologies, especially the requirements for the next generation of modelling frameworks and languages. In January 2020, the Second Winter Modelling Meeting (WMM2020) was held in San Vigilio di Marebbe (Italy), focusing on the analysis of the state of research, state of practice, and state of the art in MDE. The event brought together experts from industry, academia, and the open-source community to assess (i) what had changed in research on modelling in the last ten years, (ii) which problems are still unsolved, and (iii) which new challenges have arisen. This article presents a set of success stories and driving success factors of modelling and MDE, as well as a set of challenges and corresponding research directions that emerged from the synthesis of the results of our analysis.

A half-century ago, Winston Royce warned us that, in practice, a waterfall process “is risky and invites failure.” In a twist, Michael Keeling warns us that, in practice, teams using an iterative process will drag their feet on necessary redesign work, which sabotages iterative’s main advantage over waterfall processes.

Peer review is the evaluation of scientific, academic, and professional work by other experts in the same field. The main purpose of the peerreview process is to maintain the integrity of the scientific process and increase the quality of the work product by providing timely, professional, and unbiased feedback. The most substantive scientific activity that relies on the success and integrity of the peer-review process is, by all means, scientific publications. All software engineering conferences and workshops as well as all journals and magazines, including IEEE Software's focus and feature articles, select which articles to publish after a peer-review process.

​© 2020 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works., Serverless computing aims at reducing processing and operational units to single event-driven functions for service orchestration and choreography. With its micro-granular architectural characteristics, serverless computing is bound to face considerable architectural issues and challenges in the medium- and long-term; are these bound to become Technical Debt? As known to many, technical debt is a metaphor that reflects the additional long-run project costs connected to immediately-expedient but unsavvy technical decisions. However, what does technical debt mean and how is it expressed in serverless computing and other hybrid compute models? This article represents the first attempt to conceptualize Technical Debt in such a context; we base our arguments over a technical overview of serverless computing concepts and practices and elaborate on them via empirical inquiry. Our results suggest that higher serviceability of serverless technologies is also characterized by the absence of mechanisms to support an adequate maintainability, testability, and monitoring of serverless systems. Indeed, in case of unexpected behaviours, testing and maintenance activities are more complex and more expensive, as mainly based on non-automated, manual tasks.

Testing serverless applications plays an important role in software quality assurance. The current status of testing and debugging in serverless-based applications depicted by the experts helped us highlight issues and challenges that need to be deeply investigated. Post-print / Final draft

The ‘Practitioners’ Digest’ department in this issue of IEEE Software includes papers from the 2021 International Conference on Software Engineering (ICSE). A paper entitled, ‘Siri, Write the Next Method’ by Fengcai Wen and colleagues, expands upon the long-standing concept of code completion to include the automation of function signatures and function bodies. Code completion, an important support mechanism used by professional developers, helps complete method names, suggests the signature of an application programming interface function, or simply formats code. FeaRS, the authors’ new tool, takes that concept one step further by writing entire function signatures and function bodies based on the analysis of 2.5 million commits of existing functions in various open source projects. Another paper entitled ‘A Case Study of Onboarding in Software Teams: Tasks and Strategies’, by An Ju and colleagues, reports on the results of a study with 32 developers and 15 managers involved in the onboarding process.

This article presents a novel method for determining the factual adoption of new processes in software R&D organizations. We use a DNA-inspired analysis (motifs) to categorize parts and find similarities between projects using defect-inflow profiles.

The best way to design good products (human-centered design) assumes a "waterfall" process, which is incompatible with agile methods.

Capturing developers' behavior at scale can be challenging. In this article, we describe our experience creating a system that integrates log data from dozens of development tools at Google.

Designing and sustaining sociotechnical systems where relationships among humans, machines, and environmental aspects are intertwined is not new to software engineering. Emery and Trist1 coined the term sociotechnical systems in 1960 to draw attention to the need for people, machines, and context to all be considered when developing and sustaining these systems. Interactions and dependencies in sociotechnical systems get complex quickly as the interdisciplinary nature of such systems drive different design priorities and information flow mechanisms: sociologists see social systems, psychologists observe them as cognitive systems, computer scientists approach them as information systems, and engineers see the hardware systems.2 All of these perspectives are not only valid but also are essential elements of sociotechnical systems.

The cloud has several security and trust issues with the third-party provider. The blockchain-based cloud (BBC) system is an emerging technology that promises safe storage of big data on a cloud. The development of such a system needs requirements engineering (RE) in determining the requirements based on service-level agreements (SLAs). RE can provide a functional process to model and specify a SLA-based smart contract. The RE process for BBC ensures that the resulting SLA specifications are consistent, accurate, complete, verified, and validated. The RE process responds to the many challenges of the BBC and determines a novel direction to provide efficient and quality development of blockchainbased applications.

Due to the conceptual discrepancy between legal contract terms and code, understanding and creating smart contracts without errors can be difficult. This article proposes smart contract design patterns and their automated application through (the use of) a domain-specific language and code generation.

These days, everyone uses the term technical debt. It's so prevalent that we shorten it to tech debt tech debt or even just TD. Tech debt is also hacky code, code written by novices, code written without consideration of software architecture (so-called big balls of mud), and code with antipatterns flagged by static analysis tools.

The scientific software community's lack of computer science background and software engineering training takes a toll on scientists who need to develop software. We built a taxonomy of 2,110 reported problems and grouped them into three major axes: technical-related, socialrelated, and scientific-related problems.

IEEE Software: With the rapid changes occurring in the fields of artificial intelligence (AI) and machine learning (ML), what areas do you think are the most important to focus on right now, especially in relation to software engineering?

Advances in machine learning (ML) algorithms and increasing availability of computational power have resulted in huge investments in systems that aspire to exploit artificial intelligence (AI), in particular ML. AIenabled systems, software-reliant systems that include data and components that implement algorithms mimicking learning and problem solving, have inherently different characteristics than software systems alone.1 However, the development and sustainment of such systems also have many parallels with building, deploying, and sustaining software systems. A common observation is that although software systems are deterministic and you can build and test to a specification, AI-enabled systems, in particular those that include ML components, are generally probabilistic. Systems with ML components can have a high margin of error due to the uncertainty that often follows predictive algorithms. The margin of error can be related to the inability to predict the result in advance or the same result cannot be reproduced. This characteristic makes AI-enabled systems hard to test and verify.2 Consequently, it is easy to assume that what we know about designing and reasoning about software systems does not immediately apply in AI engineering. AI-enabled systems are software systems. The sneaky part about engineering AI systems is they are "just like" conventional software systems we can design and reason about until they?re not.

We are at an inflection point where software engineering meets the data-centric world of big data, machine learning, and artificial intelligence. In this article, I summarize findings from studies of professional data scientists and discuss my perspectives on open research problems to improve data-centric software development.

The authors describe a case study of the migration of an interactive diagramming tool written in Java from the Swing Graphical User Interface framework to the more recent JavaFX framework. The study distills the authors' experience identifying what information was needed to support the migration effort, and how the information was ultimately discovered. The outcome is presented in a set of five lessons about the discrepancies between expectations and reality in the search for information when migrating software between major frameworks.

Software specialists increasingly find themselves in situations where their application programming interface (API)-related decisions have implications on software business. We present a strategic API framework to aid in consideration of business concerns when designing, updating, or maintaining APIs.

In this position paper, we elaborate on the possibilities and needs to integrate Design Thinking into Requirements Engineering. We draw from our research and project experiences to compare what is understood as Design Thinking and Requirements Engineering considering their involved artifacts. We suggest three approaches for tailoring and integrating Design Thinking and Requirements Engineering with complementary synergies and point at open challenges for research and practice., Manuscript accepted for publication at a IEEE Software special issue on Design Thinking

This article provides a taxonomy for risk-based testing that serves as a tool to define, tailor, or assess risk-based testing approaches in general and to instantiate risk-based testing approaches for the current testing standards ISO/IEC/IEEE 29119, ETSI EG and OWASP Security Testing Guide in particular. We demonstrate the usefulness of the taxonomy by applying it to the aforementioned standards as well as to the risk-based testing approaches SmartTesting, RACOMAT, PRISMA and risk-based test case prioritization using fuzzy expert systems. In this setting, the taxonomy is used to systematically identify deviations between the standards' requirements and the individual testing approaches so that we are able to position and compare the testing approaches and discuss their potential for practical application.

Design by contract (DBC) is a technique that improves the quality of your team's code. It yields code with both a logical and a procedural nature, where the contracts state declaratively what will happen, and the implementations procedurally cause the desired effect. The team can reason either logically, by using the contracts, or procedurally, by following the code line by line, but the former allows them to reason about far larger programs. It also creates conditions for deliberate practice so developers using DBC grow their design skills faster.

In large and complex systems, identifying developers capable of maintaining a piece of code is an essential task. Repository-mining techniques can help by providing some level of automation; however, whether such techniques effectively identify skilled software maintainers is still unclear.

Formal methods are mathematically based approaches for specifying, building, and reasoning about software. Despite 50 years of research and development, formal methods have had only limited impact in industry. While we have seen success in such domains as microprocessor design and aerospace (e.g., proofs of security properties for helicopter control systems1), we have not seen wide adoption of formal methods for large and complex systems, such as web services, industrial automation, or enterprise support software.

In this article, object-relational mapping (ORM) engines in object-oriented programming are introduced. The tradeoffs that must be considered when using ORM are discussed and four lessons that will help software developers take advantage of ORM in transaction processing scenarios are provided.

Our function-as-a-service (FaaS) framework transformed end users' questions into automated tests for scientific software. Our case study illustrates the FaaSification of scientific software testing and the importance of value-driven evaluations by focusing on real-world defect detection.

Software design involves the process of understanding the requirements and creating the artifacts that specify these requirements as the product to be built. The specification of the requirements ultimately happens in code. Intermediate abstraction mechanisms, such as domain modeling languages, software design and architecture patterns, programming paradigms, and design fragments, assist software engineers to specify requirements further into the final designs as implementations. However, in the absence of commonly agreed-upon building blocks that assist software engineers in tracing the design specification across software elements, these abstraction mechanisms become sources of unintended errors. Consequently, despite the availability of many software development lifecycle processes and implementation tool support, designs erode and drift from their intent quicker than anticipated.

We are glad to present the "Sentiment and Emotion in Software Engineering" special issue of IEEE Software. In recent years, this topic has gained attention from both the research community and industry. Indeed, academic researchers have organized a number of highly successful workshops, such as the International Workshop on Emotional Awareness in Software Engineering (SEmotion) in 2016-2019. The topic was also explored in a special issue of The Journal of Systems and Software. 1 Both small and large companies have considered emotions in some aspects of their work. For example, Microsoft considers emotions in the context of inclusive hiring and support of neurodiverse developers. 2 Meanwhile, SkyTV aims at enhancing productivity of teams 3 by increasing their emotional awareness. Yet another company, source{d}, designs techniques for detection of sentiment in source-code repositories. 4.