No abstract

No abstract

Agile software development principles enable companies to successfully and quickly deliver software by meeting their customers' expectations while focusing on high quality. Many companies working with pure software systems have adopted these principles, but implementing them in companies dealing with non-pure software products is challenging.We identified a set of goals and practices to support large-scale agile development in companies that develop software-intense mechatronic systems.We used an inductive approach based on empirical data collected during a longitudinal study with six companies in the Nordic region. The data collection took place over two years through focus group workshops, individual on-site interviews, and complementary surveys.The primary benefit of large-scale agile development is improved quality, enabled by practices that support regular or continuous integration between teams delivering software, hardware, and mechanics. In this regard, the most beneficial integration cycle for deliveries is every four weeks; while continuous integration on a daily basis would favor software teams, other disciplines does not seem to benefit from faster integration cycles.We identified 108 goals and development practices supporting agile principles among the companies, most of them concerned with integration; therefrom, 26 agile practices are unique to the mechatronics domain to support adopting agile beyond pure software development teams. 16 of these practices are considered as key enablers, confirmed by our control cases.

When individual teams in mechatronic organizations attempt to adopt agile software practices, these practices tend to only affect modules or sub-systems. The short iterations on team level do not lead to short lead-times in launching new or updated products since the overall R&D approach on an organization level is still governed by an overall stage gate or single cycle V-model. This paper identifies challenges for future research on how to combine the predictability and planning desired of mechanical manufacturing with the dynamic capabilities of modern agile software development. Scaling agile in this context requires an expansion in two dimensions: First, scaling the number of involved teams. Second, traversing necessary systems engineering activities in each sprint due to the co-dependency of software and hardware development.

ResuméDen här uppsatsen behandlar skapandet och designen av en arkitektur over ett system för behandling av depression och andra psykiska sjukdomar via internet, kallat Melencolia. Ett av kraven för detta projekẗ ar att skapa ett system som kan utökas i framtiden. Vi har härlett detta krav till begreppet modularitet och för att skapa en modulär arkitektur för Melencolia har vi undersökt vad begreppet innebär och härlett det till att vara ett kvalitetsdrag hos flera kvalitetsattribut däribland "maintainability" och "reusability". AbstractThis thesis considers the problem of creating and designing an architecture for a software project that will result in a system for treatment of depression on the Internet. One of the requirements for this project, named by Melencolia, is to create a system which can be extended in the future. From this requirement we have derived the concept of modularity. In order to create a modular architecture we have concluded that modularity is a quality characteristic of multiple quality attributes such as "maintainability" and "reusability".We deploy Attribute-Driven Design (ADD) in this Melencolia project.By doing this, an architecture that is focused around modularity can be created. Since modularity is not a quality attribute, but rather a quality characteristic, we had to change the input to ADD from a quality attribute to a quality characteristic.Furthermore, we derive and propose a new method for quality characteristic evaluation of software architectures.Finally we apply our aforementioned method on the architecture of Melencolia and by doing this we get an indication on how well our proposed architecture satisfies modularity.ii