added 12 project references
As an important type of architectural knowledge, architectural assumptions should be well managed in projects. However, little empirical research has been conducted regarding architectural assumptions and their management in software development. In this paper, we conducted an exploratory case study with twenty-four architects to analyze architectural assumptions and their management in industry. In this study, we confirmed certain findings from our previous survey on architectural assumptions (e.g., neither the term nor the concept of architectural assumption is commonly used in industry, and stakeholders may have different understandings of the architectural assumption concept). We also got five new findings: (1) architects frequently make architectural assumptions in their work; (2) the architectural assumption concept is subjective; (3) architectural assumptions are context-dependent and have a dynamic nature (e.g., turning out to be invalid or vice versa during their lifecycle); (4) there is a connection between architectural assumptions and certain types of software artifacts (e.g., requirements and design decisions); (5) twelve architectural assumptions management activities and four benefits of managing architectural assumptions were identified.
The automotive domain is living an extremely challenging historical moment shocked by many emerging business and technological needs. Electrification, autonomous driving, and connected cars are some of the driving needs in this changing world. Increasingly, vehicles are Becoming software-intensive complex systems and most of the innovation within the automotive industry is based on electronics and software. Modern vehicles can have over 100 Electronic Control Units (ECUs), Which are small computers, together executing gigabytes of software. ECUs are connected to each other through Several networks within the car, and the car is increasingly connected with the outside world. These novelties ask for a change on how the software is engineered and produced and for a disruptive renovation of the electrical and software architecture of the car. In this paper, we describe the current investigation of Volvo Cars to create an architecture framework able to cope with the complexity and needs of present and future vehicles. Specifically, we presented scenarios that describe demands for the architectural framework and introduce three new viewpoints that need to be taken into account for future architectural decisions: Continuous Integration and Deployment, Ecosystem and Transparency, and car as a constituent of a System of Systems. Our results are based on a series of focus groups with experts in automotive engineering and architecture from different companies and universities.
The practice of Continuous Integration (CI) has a big impact on how software is developed today. Shortening integration and feedback cycles promises to increase software quality, feature throughput, and customer satisfaction. Thus, it is not a surprise that companies try to embrace CI in domains where it is rather difficult to implement. In this paper we present our findings from two rounds of interviews with a car manufacturer on the use of tools in system engineering and how these tools would support wider adoption of CL Our findings suggest a complex tool landscape with immense requirements that are not easily fulfilled by existing tools; this holds also for tools that well support CI in other domains. From this notion, we further explore what makes the automotive domain challenging when it comes to CI (namely complexity of system and value chain). We hope that our findings will help address such challenges.
To investigate the new requirements and challenges of architecting often safety critical software in the automotive domain, we have performed two case studies on Volvo Car Group and Volvo Group Truck Technology. Our findings suggest that automotive software architects produce two different architectures (or views) of the same system. The first one is a high-level descriptive architecture, mainly documenting system design decisions and describing principles and guidelines that should govern the overall system. The second architecture is the working architecture, defining the actual blueprint for the implementation teams and being used in their daily work. The working architecture is characterized by high complexity and considerably lower readability than the high-level architecture. Unfortunately, the team responsible for the high-level architecture tends to get isolated from the rest of the development organization, with few communications except regarding the working architecture. This creates tensions within the organizations, sub-optimal design of the communication matrix and limited usage of the high-level architecture in the development teams. To adapt to the current pace of software development and rapidly growing software systems new ways of working are required, both on technical and on an organizational level.
Software engineering practice has shifted from the development of products in closed environments toward more open and collaborative efforts. Software development has become significantly interdependent with other systems (e.g. services, apps) and typically takes place within large ecosystems of networked communities of stakeholder organizations. Such software ecosystems promise increased innovation power and support for consumer-oriented software services at scale and are characterized by a certain openness of their information flows. While such openness supports project and reputation management, it also brings requirements engineering-related challenges within the ecosystem, such as managing dynamic, emergent contributions from the ecosystem stakeholders, as well as collecting their input while protecting their IP. In this paper, we report from a study of requirements communication and management practices within IBM®’s Collaborative Lifecycle Management® product development ecosystem. Our research used multiple methods for data collection, including interviews within several ecosystem actors, on-site participatory observation, and analysis of online project repositories. We chart and describe the flow of product requirements information through the ecosystem, how the open communication paradigm in software ecosystems provides opportunities for “just-in-time” RE—and which relies on emergent contributions from the ecosystem stakeholders—, as well as some of the challenges faced when traditional requirements engineering approaches are applied within such an ecosystem. More importantly, we discuss two tradeoffs brought about by the openness in software ecosystems: (1) allowing open, transparent communication while keeping intellectual property confidential within the ecosystem and (2) having the ability to act globally on a long-term strategy while empowering product teams to act locally to answer end users’ context-specific needs in a timely manner. A sufficient level of openness facilitates contributions of emergent stakeholders. The ability to include important emergent contributors early in requirements elicitation appears to be a crucial asset in software ecosystems.