REQUIREMENTS ENGINEERING (RE) is a critical area in software development, as figuring out what to develop and include in a product is a cornerstone activity which all others depend upon. Countless studies of unsuccessful development projects report that lack in RE is often a core-contributing failure factor. 13 Central in RE is the role that coordinates all its related activities, usually named requirements engineer.

Still, empirical evidence on the way companies implement this role is scarce. In this article, we present the results of an interview-based descriptive study involving 24 IT professionals from 12 companies. As a main outcome, we can affirm that all companies assign IT professionals to the requirements engineer role in their projects, but in many different ways, which might impact efficiency of the function. Furthermore, we uncover that requirements engineers often perform other tasks ranging from project’s go vs. no-go decisions to test suite design in addition to handling requirements. Last, the study highlights their need to communicate with many other roles inside the company, from domain experts to system architects.

SOFTWARE IS A cornerstone of the economy, historically led by companies like Apple, Google, and Microsoft. However, the past decade has seen software become increasingly pervasive, while traditionally hardware-intensive products are increasingly dependent on software, meaning that major global companies like ABB, Ericsson, Scania, and Volvo are likewise becoming soft(er).(10) Where software was bundled with hardware it is now increasingly the main product differentiator.(10) This shift has radical implications, as software delivers notable advantages, including a faster pace of release and improved cost effectiveness in terms of development, ease of update, customization, and distribution. These characteristics of software open a range of possibilities, though software's inherent properties also pose several significant challenges in relation to a company's ability to create value.(10) To investigate them, we conducted in-depth interviews from 2012 to 2016 with 13 senior product managers in 12 global companies.

Multi-agent systems applied to energy/smart houses applications

REFACTORING(6) IS SOMETHING software developers like to do. They refactor a lot. But do they refactor as much as they would like? Are there barriers that prevent them from doing so? Refactoring is an important tool for improving quality. Many development methodologies rely on refactoring, especially for agile methodologies but also in more plan-driven organizations. If barriers exist, they would undermine the effectiveness of many product-development organizations. We conducted a large-scale survey in 2009 of 3,785 practitioners' use of object-oriented concepts, 7 including questions as to whether they would refactor to deal with certain design problems. We expected either that practitioners would tell us our choice of design principles was inappropriate for basing a refactoring decision or that refactoring is the right decision to take when designs were believed to have quality problems. However, we were told the decision of whether or not to refactor was due to non-design considerations. It is now eight years since the survey, but little has changed in integrated development environment (IDE) support for refactoring, and what has changed has done little to address the barriers we identified.

Quality attributes of software systems, also known as system qualities, such as performance, security, and scalability, continue to grow in importance in industrial practice. The evaluation of quality attributes is critical to software development since optimizing a software system’s core attributes can provide marketing advantage and set a product apart from its competitors. Many existing studies of unsuccessful development projects report that lack of quality attribute evaluation is often a contributing factor of project failure. Therefore, continuous quality attribute evaluation, throughout the development process, is needed to ensure customers’ expectations and demands are met.

Manual evaluation of software attributes is common in many software development companies, but it has proven to be insufficient in meeting the demands of rapid releases and high-quality expectations from customers. Automated practices have therefore gained widespread popularity as a solution to enhance efficiency, reduce costs, and increase accuracy compared to manual evaluation.

One way to automate the evaluation is using continuous integration (CI) environments. The CI environment provides several benefits, such as fast feedback on code quality, early detection of quality defects, and visualization of system quality trends. As such, these environments inherently offer organizations the opportunity to continuously monitor the quality of their software systems. However, an immature automation process can result in negative outcomes, such as cost and schedule overruns, slow feedback loops, and delayed releases.

To improve the evaluation process, prior studies have investigated different key areas, including knowledge, processes, tools, and metrics. While leveraging these areas can have a positive impact on quality evaluation, to the best of our knowledge, there is a lack of frameworks that link CI environment knowledge, metrics, and evolution together.

In this article, we aim to fill this gap by presenting the state-of-practice of using CI environments for the evaluation of quality attributes. This is achieved through an industrial study at four partner companies. Study results show that metrics acquired from CI components have a positive effect on evaluating quality requirements. Through analyzing these results, we propose a model by providing guidelines to mature existing CI environments that organizations can use for quality improvements.

As such, we claim the following contributions of this study:

A generic model of how CI environments contribute to quality attribute evaluation.

Empirical evidence that demonstrates how CI components can be used to produce data supporting the evaluation of quality attributes with metrics.

A model, derived from the study results, which provides decision support to evolve software quality evaluation through CI environments over time. © 2024 Owner/Author.

With the increasing popularity of agile development and team-oriented practices, bottom-up coordination structures have found their ways into software companies, first changing the small companies and now revolutionizing large-scale development projects and programs. One of the ways to enable bottom-up coordination is cultivation of communities of practice. Existing research has demonstrated that successful implementation of communities of practice depends on organizational support, mutual engagement and regular interaction. Engagement is said to increase, when a community creates value for the organization and individual community members, while increased engagement is further associated with the ability to create more value. However, little is known about how to ensure member engagement in large-scale environments covering many sites and thousands of developers. In this article, we report our findings from studying member engagement in large-scale distributed communities of practice at Spotify called guilds. We report the perceived value guilds provide on individual and organizational level, and discuss what hinders and what stimulates mutual engagement and value creation across time and space.