• Sustainability is defined as a trustworthiness attribute in SW architecture design. • Design of 4 SW architectures for an indoor environmental IoT system in the Edge. • Response time and energy consumption experimental evaluation report of 30 experiments. • 11 findings for the green and performance trustworthy design of IoT SW architectures. • The 30 experiments’ dataset with response and computing times and energy consumption. Identifying and implementing sustainable solutions to address the high energy consumption of ICT solutions has become a necessity in Industry 4.0. Therefore, the construction of Green software products is a priority for its customers, who need to trust that their software products are sustainable to fulfil the sustainability policies of their companies. We present sustainability as a key attribute in addressing the trustworthiness of software architectures. This work is focused on IoT monitoring software architectures in the Edge, since IoT energy consumption is a critical issue for sustainability due to the huge amount of power connections required by IoT devices and the high energy consumption needed for processing and transmitting their data. We present an exploratory research study conducted to determine how to design trustworthy IoT monitoring software architectures in the Edge considering two critical attributes, performance and sustainability. Specifically, this study evaluates how the configuration of the components that comprise Edge IoT monitoring architectures may influence their energy consumption and response time. This work presents the experimental results of the exploratory study and its findings, in which the energy consumption and response time of four different software architecture configurations of an indoor environmental monitoring IoT system are measured. From the execution of thirty experiments, this study reveals the importance of balancing the monitoring activities between the Edge nodes and servers, and it indicates that it is possible to construct trustworthy IoT monitoring software architectures in the Edge with software components that reduce both energy consumption and response time.

Background: A novel framework in management science introduces collaboration-style focused personas (bee, ant, and leech) built on human values and their relationship to team performance. Studies on human values in software engineering until now have only focused on adapting human values to the engineering process. The persona framework leverages how values may affect performance in software engineering. Aims: We investigate the relationship of individual and team performance with computationally detected personas based on the content of different communication channels. Method: We conducted an empirical study with 61 students studying software quality management and correlated personas with their exam-based individual and project-based team performance. Bee, ant and leech personas were detected by an AI tool using intra-team WhatsApp and MSTeams textual communication. Results: We found a significant positive correlation of ant persona and a significant negative correlation of leech persona with team performance. In addition, the detection of computational personas differed significantly between communication channels. Conclusions: Informal meetups among team members and team-building training can promote antness among team members by improving a sense of security and belonging for a healthy competitive environment. Additionally, multiple distinct communication data channels are essential for forming reliable results when employing AI and other computational tools.

Context The COVID‐19 pandemic has had a disruptive impact on how people work and collaborate across all global economic sectors, including software business. While remote working is not new for software engineers, forced WFH situations come with both limitations and opportunities. As the ‘new normal’ for working might be based on the current state of Work‐from‐home (WFH), it is useful to understand what has happened and learn from that. Objective This study aims to gain insights into how their WFH arrangement impacts project management and software engineering. We are also interested in exploring these impacts in different contexts, such as startups and established companies. Method We conducted a global‐scale, cross‐sectional survey during the spring and summer 2021. Our results are based on quantitative and qualitative analysis of 297 valid responses. Results We characterize the profile of WFH in both spatial and temporal aspects, together with a set of common collaborative tools and coordination and control mechanisms. We revealed some areas of project management that are relatively more challenging during WFH situations, such as coordination, communication and project planning. We also revealed a mixed picture of the perceived impact of WFH on different software engineering activities. Conclusion WFH is a situational phenomenon which can have both negative and positive impact on software teams. For practitioners, we suggest a unified approach to consider the context of WFH, collaborative tools, associated coordination and control approaches and a process that resolve those aspects that are sensitive to physical interaction.

Our world’s needs have evolved dramatically since the origins of software engineering in the 1960s. The future software engineer must be able to anticipate our needs and desires in an era where complex challenges continually emerge, and adaptive solutions must be delivered on the fly. This paper addresses the evolution of the IEEE Computer Society’s Guide to the Software Engineering Body of Knowledge (SWEBOK Guide) and its impact on software engineering higher education and professional training that should prepare engineers to fulfill their mission in this dynamic digital future.

Business Model Canvas (BMC) is a tool widely used to describe startup business models. Despite the various business aspects described, BMC pays a little emphasis on team- related factors. The importance of team-related factors in software development has been acknowledged widely in literature. While not as extensively studied, the importance of teams in software startups is also known in both literature and among practitioners. In this paper, we propose potential changes to BMC to have the tool better reflect the importance of the team, especially in a software startup environment. Based on a literature review, we identify various components related to the team, which we then further support with empirical data. We do so by means of a qualitative case study of five startups.

Technical debt monitoring is one of the activities that have to be performed in technical debt management. To do that, there are different techniques that can be used to estimate technical debt and different tools that implement those different techniques. This paper presents TEDMA Tool, a tool for monitoring technical debt over the software evolution and that it is open to integrate third party tools. TEDMA is based on the analysis of source code repositories and is useful for researching using empirical data extracted from software projects. Currently, it is been used to analyze big projects in the execution of several case studies. The expected evolution of TEDMA will make the tool useful for software development industry.

Editorial article Since the publication of Agile Manifesto in 2001, agile methods have transited from a grass- root initiative among enthusiastic advocates and developers to a mainstream software development approach adopted by both small and large companies worldwide. Meanwhile research on agile methods has grown rapidly and steadily into an established research area, evidenced by dedicated conferences (e.g., XP conference series, research track of previous Agile Conference series), special issues and sections in top Information Systems and Software Engineering journals. However, practitioners and consultants have largely driven the advancement in agile field, and agile research has lagged behind practice in the past. Has this situation changed as both agile methods and research community become increasingly mature? To be able to answer such questions, there is a constant need to check what interest agile practitioners and what agile researchers are investigating, to make sure that the states of the art and practice are aligned properly.

A Body of Knowledge (BOK) is a term used to represent the complete set of concepts, terms, and activities that make up a professional domain. It encompasses the core teaching skills and research in a field or industry [13]. One of the main concerns of the software industry is to develop the talent of its human resources since the quality and innovation of its products and services depend of a great extent on the Knowledge, the ability, and the talent of technical engineers. In the educational area the used of BOK and Cloud Computing Tools are becoming the best way to provide solutions that meet the current need for greater collaboration between business, industry, education, and society; for this reason, the development of software products based in innovation is important for the professional life of a software engineering, since it leads to transform routine tasks into automated tasks; in the same way, it allows to manage processes focused on aligning services of Information Technology (IT) to the needs of companies with an emphasis on the benefits that the final customer added may perceive to the factor of I+D+I in order to create an innovative product. The current study focuses on the use of computer tools in the cloud in its phases: definition, planning, and control of software project based on the innovation as a tool for development and knowledge generation based in BOK. The tools of Computing in the Cloud analyzed were: Alfresco, Redbooth, DotProject, Dealines, and Redmine. The use of these tools permitted to obtain information to formulate a BOK in the context of projects.

The potential shown by Lean in different domains has aroused interest in the software industry. However, it remains unclear how Lean can be effectively applied in a domain such as software development that is fundamentally different from manufacturing. This study explores how Lean principles are implemented in software development companies and the challenges that arise when applying Lean Software Development. For that, a case study was conducted at Ericsson R&D Finland, which successfully adopted Scrum in 2009 and subsequently started a comprehensible transition to Lean in 2010. Focus groups were conducted with company representatives to help devise a questionnaire supporting the creation of a Lean mindset in the company (Team Amplifier). Afterwards, the questionnaire was used in 16 teams based in Finland, Hungary and China to evaluate the status of the transformation. By using Lean thinking, Ericsson R&D Finland has made important improvements to the quality of its products, customer satisfaction and transparency within the organization. Moreover, build times have been reduced over ten times and the number of commits per day has increased roughly five times.The study makes two main contributions to research. First, the main factors that have enabled Ericsson R&D’s achievements are analysed. Elements such as ‘network of product owners’, ‘continuous integration’, ‘work in progress limits’ and ‘communities of practice’ have been identified as being of fundamental importance. Second, three categories of challenges in using Lean Software Development were identified: ‘achieving flow’, ‘transparency’ and ‘creating a learning culture’.

Abstract Software Product Line Engineering (SPLE) demands upfront long‐term investment in (i) designing a common set of core‐assets and (ii) managing variability across the products from the same family. When anticipated changes in these core‐assets have been predicted with certain accuracy, SPLE has proved significant improvements. However, when large/complex software product line projects have to deal with changing market conditions, alternatives to supplement SPLE are required. Agile Software Development (ASD) may be an alternative, as agile processes harness change for the customer's competitive advantage. However, when the aim is to scale Agile projects up to effectively manage reusability and variability across the products from the same family, alternatives to supplement agility are also required. As a result, a new approach called Agile Product Line Engineering (APLE) advocates integrating SPLE and ASD with the aim of addressing these gaps. APLE is an emerging approach, which implies that organizations have to face several barriers to achieve its adoption. This paper presents a systematic literature review of experiences and practices on APLE, in which the key findings uncover important challenges about how to integrate the SPLE model with an agile iterative approach to fully put APLE into practice. Copyright © 2011 John Wiley & Sons, Ltd.

One widely accepted approach to implement traceability practices is the use of methodologies. But the information related to organization, stakeholders, product size, and quality requirements may change from one project to another. As a consequence, traceability information differs as well, which arises specific traceability requirements to each project.One common way to cope with this fact is the use of metamodels to underpin methodologies. However most of the traceability metamodeling approaches simply provide a predefined set of concepts, with no extension mechanism.Therefore, customizing a methodology for a specific project is often unsatisfactory. This paper justifies that this problem can be approached if traceability metamodels include a basic set of items, including concepts and traceability structures, designed to be extended according to project features. For this, the right modeling tools are required:that is, some metamodeling principles that support typing and extensibility, together with a general and extensible description of the software process. This second issue is obtained from ISO/IEC 24744 with some additional inputs.This paper explains how to use these tools in practice to define the so called TmM metamodel. Within this paper TmMis applied to a case study in which non-conventional work products have to be considered as part of the trace ability information.

Functional requirements must be tested to check if the system executes as the end user expects. Validation environments must be able to test multiple kinds of applications that belong to different domains and technologies. Since this wide validation spectrum is very difficult to cope with, validation environments are usually specialized in domains, programming languages, technologies, etc. However, it is possible to identify that the validation processes for different systems share a set of commonalities and variability points. This is a perfect framework to apply the software product line approach to develop domain specific validation environments for testing specific products. In this paper we present our experience of applying software product lines to support the variability of validation environments. We illustrate our product-line experience of developing two domain-specific validation environments for two different case studies: digital TV and slots machines.

The aim of this work is to produce a traceability model to enhance processes and tasks, which make extensive use of traceability information such as, V&V, change management and impact analysis, under the roundtrip engineering approach. This paper analyzes several current traceability approaches, in order to obtain their relevant features, to identify overlaps and inconsistencies between them, and to select the best traceability practices. It was identified that, several issues still make difficult the adoption of a wide-scale traceability activity, in the software/system engineering practice, such as, there is a lack of a commonly accepted traceability definition, a standard way of specifying traceability between artifacts, and a traceability type classification. Basing on these findings, an approach for a "traceability schema specification" and a first implementation on a software/system engineering environment are provided. The schema attempts to systematize the definition, deployment and maintenance of a traceability implementation