Contrasting the idea of a team with all-round testers, the Testing Hopscotch model includes six complementary profiles, tailored for different types of testing. The model is based on 60 interviews and three focus groups with 22 participants. The validation of the Testing Hopscotch model included ten validation workshops with 58 participants from six companies developing large-scale and complex software systems. The validation showed how the model provided valuable insights and promoted good discussions, helping companies identify what they need to do in order to improve testing in each individual case. The results from the validation workshops were confirmed at a cross-company workshop with 33 participants from seven companies and six universities. Based on the diverse nature of the seven companies involved in the study, it is reasonable to expect that the Testing Hopscotch model is relevant to a large segment of the software industry at large. The validation of the Testing Hopscotch model showed that the model is novel, actionable and useful in practice, helping companies identify what they need to do to improve testing in their organization.

Software products are increasingly used in critical infrastructures, and verifying the security of these products has become a necessary part of every software development project. Effective and practical methods and processes are needed by software vendors and infrastructure operators to meet the existing extensive demand for security. This article describes a lightweight security risk assessment method that flags security issues as early as possible in the software project, namely during requirements analysis. The method requires minimal training effort, adds low overhead, and makes it possible to show immediate results to affected stakeholders. We present a longitudinal case study of how a large enterprise developing complex telecom products adopted this method all the way from pilot studies to full-scale regular use. Lessons learned from the case study provide knowledge about the impact that upskilling and training of requirements engineers have on reducing the risk of malfunctions or security vulnerabilities in situations where it is not possible to have security experts go through all requirements. The case study highlights the challenges of process changes in large organizations as well as the pros and cons of having centralized, distributed, or semi-distributed workforce for security assurance in requirements engineering.

Testing of a large-scale and complex software system requires many types of knowledge, skills and personality traits. Contrasting the idea of a perfect all-round tester, this paper presents the Testing Hopscotch model with six complementary profiles, and the key characteristics considered as most relevant for each profile. The model is based on 60 interviews with engineers from three large-scale companies in different industry segments. The Testing Hopscotch model was well received by three focus groups including 22 participants, which further strengthens the validity of the model.

Contribution: This article identifies the participation of external stakeholders as a key contributing factor for positive outcomes in project-based software engineering courses. A model for overlapping virtuous circles of lasting positive impact on both stakeholders and students from such courses is proposed. Background: Project-based courses are widespread in software engineering education, and there are numerous designs for such courses presented in literature. It is found that the needs and motivations of external stakeholders, from industry and government sectors, in these courses has received limited attention in related work. Intended Outcomes: A course design that prepares students for graduate level studies and professional life, through close proximity to external stakeholders in a highly realistic setting, working on "live" projects. Application Design: Building on a long tradition of university-industry collaboration dating back to 1977, as well as findings in related work, students are assigned to live projects proposed by external stakeholders from industry and government, working in close proximity with their respective stakeholders throughout the project. The course places great emphasis on coaching over instruction, treating the many unforeseen challenges of such projects as a valuable part of the learning experience. Findings: Based on interviews with stakeholders and students, it is found that stakeholder and student outcomes are interdependent and build upon one another, and that positive outcomes for both groups are necessary for the sustainability of the course over multiple iterations.

Continuous integration and delivery consolidate several activities, ranging from frequent code changes to compiling, building, testing, and deployment to customers. During these activities, software professionals seek additional information to perform the task at hand. Developers that spend a considerable amount of time and effort to identify such information can be distracted from doing productive work. By identifying the types of information that software professionals seek, we can better understand the processes, practices, and tools that are required to develop a quality product on time. A better understanding of the information needs of software practitioners has several benefits, such as staying competitive, increasing awareness of the issues that can hinder a timely release, and building a visualization tool that can help practitioners to address their information needs. We conducted a multiple-case holistic study with 5 different companies (34 unique participants) to identify information needs in continuous integration and delivery. This study attempts to capture the importance, frequency, required effort (e.g., sequence of actions required to collect information), current approach to handling, and associated stakeholders with respect to identified needs. We identified 27 information needs associated with different stakeholders (i.e., developers, testers, project managers, release team, and compliance authority). The identified needs were categorized as testing, code & commit, confidence, bug, and artifacts. We discussed whether the information needs were aligned with the tools used to address them.

Technical abilities (also known as hard skills) are just as crucial as soft skills (such as communication, cooperation, teamwork, etc.) in attaining professional success. Therefore it is important to pay much attention to soft skills when developing the curriculum of engineering educations. Many elements can have a direct or indirect impact on students’ soft skills, including course topic, course module (i.e., laboratories, seminars, etc.), the medium of instruction, and learning activities. Many academics have investigated the development of soft skills in a variety of disciplines, including engineering, science, and business. The purpose of this study is to assess the perceived impact of coaching on the development of soft skills in MS and BS engineering students. During four planned sessions over a six-month period, MS students acted as coachers, while BS students received coaching from MS students. After each coaching session, all students were asked to complete a survey to evaluate their perception for how their soft skills had developed. The results of the perceived effects of introducing coaching activities are presented in this article. This article is a first step, in the series of our investigation, in identifying the students’ perceptions about the development of soft skills. According to the survey, the MS engineering students who were the coachers had perceived to improve most of their soft skills. However, in the perception of BS students, their soft skills did not improve as compared to MS students, prompting us to conduct additional research in the future to discover what hampered the growth of BS students’ soft skills as well as how MS students’ soft skills were enhanced.

Shortened time-to-market cycles and increasingly complex systems are just some of the challenges faced by industry. The requirement engineering process needs to adapt to these challenges in order to guarantee that the end product fulfils the customer expectations as well as the necessary safety norms. The goal of this paper is to investigate the way engineers work in practice with the requirement engeneering processes at different stages of the development, with a particular focus on the use of requirements in cross domain development and to compare this to the existing theory in the domain.

Today it is very common for software systems to be built by teams located in more than one country. For example, a project team may be located in the US while the team lead resides in Sweden. How then should students be trained for this kind of work? Senior design or capstone projects offer students real-world hands-on experience but rarely while working internationally. One reason is that most instructors do not have international business contacts that allow them to find project sponsors in other countries. Another reason is the fear of having to invest a huge amount of time managing an international project. In this paper we present the general concepts related to "International Capstone Project Exchanges", the basic model behind the exchanges (student teams are led by an industry sponsor residing in a different country) and several alternate models that have been used in practice. We will give examples from projects in the US, Germany, Sweden, Australia, and Colombia. We have extended the model beyond software projects to include engineering projects as well as marketing, and journalism. We conclude with a description of an International Capstone Project Exchange website that we have developed to aid any university in establishing their own international project exchange.