Chapter 1 gives a general introduction to mass-produced embedded systems and what characterises them.
Chapter 2 gives some examples of problems in current R&D approaches, defines goals for an R&D organisation, and defines the research questions investigated further in the thesis.
Chapter 3 outlines the research process, used epistemology, lists the cases studied and discusses issues with doing research as native in the organisation studied.
Chapter 4 outlines all chapters in the thesis and describes my individual contribution in chapters 5 to 11.
Chapters 5 and 6 describe three detailed cases of how architectures are developed and maintained for automotive embedded systems. The rich description provides a background of current practice of software development of mass-produced embedded systems.
Chapter 7 identifies and models various approaches to develop embedded software, and relates them to two different businesses. The model was based on a mapping study to identify what broad approaches to embedded software development are used in industry. The study aimed to better understand, and potentially point at an answer to RQ1. Of special interest was how these approaches relate to used architectural styles, which supports further investigation of RQ1.2.
Chapter 8 aims to facilitate agile development for individual teams in the context of large MPES projects. This would allow the length of iterations from idea to implementation to be determined by the potential speed of the individual development teams and not the overall product development project. This provides an answer to RQ1.1.
Chapter 9 designs a compositional architecture for embedded software as precursor for open software ecosystems. The study aimed to answer RQ1.2 and detail the architecture-related issues of RQ1.3.
Chapter 10 explores open software ecosystems as possible approach to development of embedded software as an asnwer to RQ1.3. This would extend the base of innovators beyond what is presently hierarchically directed by the OEM to support delivery of innovative features with value for the customer.
Chapter 11 describes innovation experiment systems for embedded products and defines a reference architecture supporting such an R&D approach. The study aimed to an answer RQ1.2 and RQ1.4.
Chapter 12 summarises the answers to the research questions and design goals in terms of developed artefacts. It also lists the key contributions of the thesis.
31 December 2012
30 December 2012
Thesis chapter 3.3: Insider issues
I was a PhD student in Software Engineering while being employed by large company, Volvo Car Corporation, where I have worked for 9 years prior to the start of the PhD education. The company has a program for about 25 PhD students in various areas. The agreement between the company and the university states that 80% of my full-time employment should be spent towards obtaining a PhD while 20\% of my time still working in industrial projects.
There is also an expectation locally that the research should be relevant for the EESE department where I am employed. Synergy is expected between the industrial project and the conducted research, and at best the research results should be directly beneficial for the company.
Industrial PhD students are often expected to have dual roles and act as neutral or unbiased researchers by the scientific community, and act as practitioners in the area they are researching by the company where they are employed. Furthermore they have a personal goal of pursuing a research education. These factors drives both the focus of the research (e.g. the formulation of research questions) and affects how the research is conducted. It is not impossible to conduct research under these conditions but there are some concerns which are not relevant for a researcher employed by a university or similar. Börjesson is the only other industrial PhD student I have found mentioning the dual roles in her thesis.
The dual roles have been called different things by different authors; ``participant-observer'', ``insider'' (link, link and link) and ``native'', with the last article focuses on ``how complete members may undertake academic research in their own organizations while retaining the choice of remaining a member within a desired career path when the research is completed'', i.e. not going native for the purpose of research but being native before, during and after. But they all consider the role of a researcher being part of the group that is being researched, with the ``insider'' term mostly used in the context of action research. The insider issues relevant for this thesis are mostly related to qualitative research in general and case study research in particular.
I address the issues of the dual roles in this thesis based on four papers (link, link, link, and link). These papers describe some issues which are particular to a industrial PhD student which are not that relevant to a researcher employed by a university or similar institution.
The only mentioning of ethics I found specifically for software engineering research is Runeson & Höst , a general overview of science and ethics can be found by Rosenthal. Both of these focus on the ethics towards any persons being studied and not the ethical issue of having questionable motives for performing the research. In this research project the motives from the funding agencies, Volvo Car Corporation and VINNOVA, are clearly stated and it is difficult to imagine any ulterior motives beyond satisfying these goals.
All case studies in table follows the spirit of the Ethical Considerations by Runeson & Höst even if the exact implementation may differ to their examples (Case I was even conducted before the publication of this article).
In all case studies in table the participants were informed about my dual roles as participant and observer, and that my participation would lead to published research, such as this thesis, and to internal reports in respective company. The latter was possibly more sensitive, and perhaps restrained the answers since the interviewees' managers would be in the audience. However I feel that this only had a minor influence. This pre-information also included a brief overview of the research process.
Unfortunately the consent to participate was not written, just verbal (although recorded in some interviews when the equipment was working as planned), contrary to the guidelines by Runeson & Höst, and the pre-information was also only verbal.
The participants were anonymised as much as possible, but in those cases where I deemed it would be possible for another insider to determine who participated in the study they were informed of this prior to their participation.
In cases II, III and V the participants had the opportunity to review the transcribed data as it was captured before it was used or reported outside of the group participating in the study. One interviewee in case V declined to have the interview recorded, but note-taking was ok, which was obliged by me.
It may be more difficult for someone to decline to participate in a case study in a industrial company than in a general social setting, due to the fact that the observer may have management buy-in to perform the study. However my general impression is contrary, all interview participants saw the interviews as an opportunity for retrospection.
Volvo Cars has a process of reviewing articles by industrial PhD students before publishing. My experience is that this process becomes less strict the more experienced the student becomes in writing about sensitive company information.
Tellis continues with ``the technique (of participant-observation) provides some unusual opportunities for collecting data, but could face some major problems as well. The researcher could well alter the course of events as part of the group, which may not be helpful to the study''. This is in essence what Yin says where he mentions four major problems for a participating observer:
The first problem is that a participant sometimes must assume roles that could be contrary to good scientific practice. For me as a participant in an engineering company this seem to be a small risk since there is a common view that good engineering is based on science. Therefore the claim that I am doing research is usually a valid rationale for a certain role or behaviour.
The second is that the observer may become a supporter of the unit or group studied. If this is a real concern for an industrial PhD student then there is a real problem with such a role doing research since it is expected of the PhD student to be a supporter of his or her company. I also don't think the rest of the scientific community would expect otherwise if it clearly stated when presenting the research as being made by an insider.
Third, the balance between participating and observing may be skewed. This is a real concern for both me and other PhD colleagues I have spoken to at my company.
I have not found any recipes to mitigate this risk, and have tried to judiciously balance this during the project.
The fourth problem Yin mentions is if the studied organisation is ``physically dispersed'', then it may be ``difficult to be at the right pace at the right time; either to participate in or to observe important events''. The last problem is not unique to researchers with dual roles, but is relevant for anybody doing observations. In such a large organisation as Volvo Cars it is impossible to always be ``at the right place at the right time'', but at least all in-house development is done at a single site, Torslanda, Göteborg, Sweden.
Brannick & Coghlan have a more multifaceted view of doing research as a native. They for example state that native researchers have automatic primary access, while secondary access to documents or people may be harder for a native researcher since the organisation may not distinguish between the roles of a researcher and a practitioner, with the practitioner having free access to certain information while still being restricted to other information on a need-to-know principle. I have not experienced this as a problem at all at Volvo Cars.
Brannick & Coghlan continue to discuss the preunderstanding that a native researcher may put him ``too close'' to the data, but concludes that the research challenges "do not invalidate any of the outlined research traditions" (Their article mentions positivism, interpretative/hermeneutic and critical realism/action research). I assume that ``too close'' means not being able to evaluate the data objectively, which may be risk also in this thesis.
There is also an expectation locally that the research should be relevant for the EESE department where I am employed. Synergy is expected between the industrial project and the conducted research, and at best the research results should be directly beneficial for the company.
Industrial PhD students are often expected to have dual roles and act as neutral or unbiased researchers by the scientific community, and act as practitioners in the area they are researching by the company where they are employed. Furthermore they have a personal goal of pursuing a research education. These factors drives both the focus of the research (e.g. the formulation of research questions) and affects how the research is conducted. It is not impossible to conduct research under these conditions but there are some concerns which are not relevant for a researcher employed by a university or similar. Börjesson is the only other industrial PhD student I have found mentioning the dual roles in her thesis.
The dual roles have been called different things by different authors; ``participant-observer'', ``insider'' (link, link and link) and ``native'', with the last article focuses on ``how complete members may undertake academic research in their own organizations while retaining the choice of remaining a member within a desired career path when the research is completed'', i.e. not going native for the purpose of research but being native before, during and after. But they all consider the role of a researcher being part of the group that is being researched, with the ``insider'' term mostly used in the context of action research. The insider issues relevant for this thesis are mostly related to qualitative research in general and case study research in particular.
I address the issues of the dual roles in this thesis based on four papers (link, link, link, and link). These papers describe some issues which are particular to a industrial PhD student which are not that relevant to a researcher employed by a university or similar institution.
Ethics
A researcher funded by the industry may be questioned if there are some ulterior motives to performing the research or of the funding agency have any influence over the results, or what results are published or withheld. Extreme cases could be tobacco industry funding research about the dangers of smoking or oil industries funding research about climate change due to use of fossilised fuels.The only mentioning of ethics I found specifically for software engineering research is Runeson & Höst , a general overview of science and ethics can be found by Rosenthal. Both of these focus on the ethics towards any persons being studied and not the ethical issue of having questionable motives for performing the research. In this research project the motives from the funding agencies, Volvo Car Corporation and VINNOVA, are clearly stated and it is difficult to imagine any ulterior motives beyond satisfying these goals.
All case studies in table follows the spirit of the Ethical Considerations by Runeson & Höst even if the exact implementation may differ to their examples (Case I was even conducted before the publication of this article).
In all case studies in table the participants were informed about my dual roles as participant and observer, and that my participation would lead to published research, such as this thesis, and to internal reports in respective company. The latter was possibly more sensitive, and perhaps restrained the answers since the interviewees' managers would be in the audience. However I feel that this only had a minor influence. This pre-information also included a brief overview of the research process.
Unfortunately the consent to participate was not written, just verbal (although recorded in some interviews when the equipment was working as planned), contrary to the guidelines by Runeson & Höst, and the pre-information was also only verbal.
The participants were anonymised as much as possible, but in those cases where I deemed it would be possible for another insider to determine who participated in the study they were informed of this prior to their participation.
In cases II, III and V the participants had the opportunity to review the transcribed data as it was captured before it was used or reported outside of the group participating in the study. One interviewee in case V declined to have the interview recorded, but note-taking was ok, which was obliged by me.
It may be more difficult for someone to decline to participate in a case study in a industrial company than in a general social setting, due to the fact that the observer may have management buy-in to perform the study. However my general impression is contrary, all interview participants saw the interviews as an opportunity for retrospection.
Volvo Cars has a process of reviewing articles by industrial PhD students before publishing. My experience is that this process becomes less strict the more experienced the student becomes in writing about sensitive company information.
Observer versus participant
Tellis defines this issue as ``participant-observation makes the researcher into an active participant in the events being studied''. This is not unique for the industrial PhD student, but it is almost unavoidable. At Volvo cars it is expected since the PhD program targets to ``reinforce a scientific approach within product development'', and PhD students are expected to participate in the activities of the company.Tellis continues with ``the technique (of participant-observation) provides some unusual opportunities for collecting data, but could face some major problems as well. The researcher could well alter the course of events as part of the group, which may not be helpful to the study''. This is in essence what Yin says where he mentions four major problems for a participating observer:
The first problem is that a participant sometimes must assume roles that could be contrary to good scientific practice. For me as a participant in an engineering company this seem to be a small risk since there is a common view that good engineering is based on science. Therefore the claim that I am doing research is usually a valid rationale for a certain role or behaviour.
The second is that the observer may become a supporter of the unit or group studied. If this is a real concern for an industrial PhD student then there is a real problem with such a role doing research since it is expected of the PhD student to be a supporter of his or her company. I also don't think the rest of the scientific community would expect otherwise if it clearly stated when presenting the research as being made by an insider.
Third, the balance between participating and observing may be skewed. This is a real concern for both me and other PhD colleagues I have spoken to at my company.
I have not found any recipes to mitigate this risk, and have tried to judiciously balance this during the project.
The fourth problem Yin mentions is if the studied organisation is ``physically dispersed'', then it may be ``difficult to be at the right pace at the right time; either to participate in or to observe important events''. The last problem is not unique to researchers with dual roles, but is relevant for anybody doing observations. In such a large organisation as Volvo Cars it is impossible to always be ``at the right place at the right time'', but at least all in-house development is done at a single site, Torslanda, Göteborg, Sweden.
Brannick & Coghlan have a more multifaceted view of doing research as a native. They for example state that native researchers have automatic primary access, while secondary access to documents or people may be harder for a native researcher since the organisation may not distinguish between the roles of a researcher and a practitioner, with the practitioner having free access to certain information while still being restricted to other information on a need-to-know principle. I have not experienced this as a problem at all at Volvo Cars.
Brannick & Coghlan continue to discuss the preunderstanding that a native researcher may put him ``too close'' to the data, but concludes that the research challenges "do not invalidate any of the outlined research traditions" (Their article mentions positivism, interpretative/hermeneutic and critical realism/action research). I assume that ``too close'' means not being able to evaluate the data objectively, which may be risk also in this thesis.
Benefits
There are a number of benefits of being a industrial PhD student as well. Without much elaboration some benefits I have experienced are:- Access - The industrial PhD student is by almost default an ``insider'', especially if he is already is working at the company before starting his studies, so primary access is granted by default.
- Interpretation - The industrial PhD student has a superior possibility to use an interpretative approach to qualitative research.
- Acceptance - Research results may have a better chance of being seen as ``true'' since the results are coming from one of their own. This is not the same as researcher suggestions are more acceptable to implement, but the argument that the researcher does not ``understand'' issues specific to the organisation is absent.
29 December 2012
Thesis chapter 3.2: Qualitative research
Most of the reasoning and analysis in this project is qualitative, based on industrial observations and experiences rather than elaborate theories.
During the course of the project I, together with colleagues, studied 8 cases* of industrial software and architecture development, seen in the table below. The data gathered in these case studies are almost exclusively qualitative empirical data from industry and thus my scientific conclusions are also of a qualitative nature.
Qualitative research can be performed in many traditions, Walsham mentions three types of epistomologies: Positivism, Interpretative (or Non-positivism) and Normativism. This thesis uses the interpretative approach when collecting and analysing data for three reasons: First, I prioritised insight into the cases over reliability for other researchers to reproduce the studies. Second, I judged it impossible to disregard any pre-conceptions I had based on more than ten years of of professional experience of designing and developing software-intensive embedded systems. Third, most of the descriptions of the case studies are based on interview data which already are the interviewees' interpretation of the actual events/facts/situations/...
The selection of interviewees were in cases I, II, III and V done as purposive samples in order to cover a comprehensive variety of roles and teams at the studied organisations.
* A case study being ``an empirical study that investigates a contemporary phenomena in depth and within its real-life context, especially when the boundaries between the phenomenon and the context are not clearly evident''
Qualitative research can be performed in many traditions, Walsham mentions three types of epistomologies: Positivism, Interpretative (or Non-positivism) and Normativism. This thesis uses the interpretative approach when collecting and analysing data for three reasons: First, I prioritised insight into the cases over reliability for other researchers to reproduce the studies. Second, I judged it impossible to disregard any pre-conceptions I had based on more than ten years of of professional experience of designing and developing software-intensive embedded systems. Third, most of the descriptions of the case studies are based on interview data which already are the interviewees' interpretation of the actual events/facts/situations/...
| Case | Company | Description | Data sources | Author role | Chapter(s) |
| I | VCC | Forces shaping the distributed in-vehicle EE architecture in P2 platform | Interviews with 20 developers + design documents | Insider observer | 5, 7, 10 |
| II | VCC | Comparative case study on architecting process on existing platforms | Interviews with 6 architects + design documents + personal notes | Insider observer | 6, 7, 10 |
| III | Scania | Comparative case study on architecting process on existing platforms | Interviews with 5 architects + design documents + personal notes | Observer | 6 |
| IV | VCC | Case study on architecture decisions for new platform | Observed decisions during 3 months | Participant / insider observer | |
| V | VCC | Post mortem analysis of Sensus infotainment development | Interviews with 6 key developers + design documents | Insider observer | 7, 10 |
| VI | VCC | Proof-of-concept development of android-based infotainment system | All project & design documents of both product owner and Scrum team + personal notes | Participant / insider observer | 9, 10, 11 |
| VII | VCC | Agile development of climate control software | Official meeting notes and presentations + personal notes | Insider observer | 7, 10 |
| VIII | VCC | Agile development of next generation infotainment system | Official meeting notes and presentations + personal notes | Insider observer | 10 |
The selection of interviewees were in cases I, II, III and V done as purposive samples in order to cover a comprehensive variety of roles and teams at the studied organisations.
* A case study being ``an empirical study that investigates a contemporary phenomena in depth and within its real-life context, especially when the boundaries between the phenomenon and the context are not clearly evident''
28 December 2012
Thesis chapter 3.1: Design research process
Blessing & Chakrabarti defines a design research process called the Design Research Methodology (DRM). The process emphasise the focus and goals of the research project, the study of factors contributing to the goals, the development of artefacts to support the goals, and the evaluation the developed artefacts (link).
The design process was scoped by the four stages of the DRM, seen in figure below, although the actual artefacts were developed in a nonlinear fashion. All four stages contributed to new learning, which is included in the respective chapters of the thesis.
This resulted in a set of artefacts to achieve the goals and alleviate problems identified in the previous two stages. The artefacts fall into several categories of ways-of-working, model and architectures:
The DRM process assumes an iteration of the last two phases to optimise the design of the artefacts against the design goals, in this project only one cycle was performed.
The set of artefacts is not sufficient for an organisation to evolve its R&D process, in practice there are numerous other factors affecting the efficiency of an R&D process at an OEM. Factors from almost every area of research, ranging from management theory via economics to semiconductor technology. The set of artefacts developed is thus shown to mitigate the investigated problems, but not necessarily solve them, at least not on their own.
The design process was scoped by the four stages of the DRM, seen in figure below, although the actual artefacts were developed in a nonlinear fashion. All four stages contributed to new learning, which is included in the respective chapters of the thesis.
 |
| The four stages of the Design Research Methodology by Blessing and Chakrabarti |
Criteria
The first stage in the design process defined the overall context, research questions and design goals based on cases~I-V in together with selected problems form published literature, described in detail in chapter 2. Chapters 5 and 6 provides a rich insight into the industrial context of mass-produced embedded systems.Descriptive Study I
The second stage investigated existing literature to further understand the problems, elaborated on evaluation criteria and guided to possible solutions, this is described in chapter 7. The aim of this investigation is to answer RQ1 and guide towards answers of answer RQ1.1 and RQ1.2.Prescriptive Study
The third stage, the Prescriptive Study, investigated specific artefacts related to RQ1.1, RQ1.2, RQ1.3 and RQ1.4.This resulted in a set of artefacts to achieve the goals and alleviate problems identified in the previous two stages. The artefacts fall into several categories of ways-of-working, model and architectures:
- Chapter 7 describes a model of how individual teams interact with large projects, and based on this a method to facilitate a transition to agile development for individual teams.
- Chapters 9 and 11 describe two architectures, for compositional architectures and embedded architecture for innovation experiment systems respectively.
- Chapter 10 describes 5 activities to establish an open software ecosystem for MPES.
Descriptive Study II
The fourth stage evaluated the resulting artefacts, methods and ways-of-working in cases VI-VIII from the previous stage (also the focus of chapters 7, 9, 10 and 11).Limitations
The artefacts were evaluated mainly through observational, analytical and descriptive methods as categorised by Hevner et al:- Observation through case studies
- Architectural analysis of designed artefacts
- Informed argument based on insider knowledge to show the artefact's utility
- Scenarios describing the use of the artefact in the context
The DRM process assumes an iteration of the last two phases to optimise the design of the artefacts against the design goals, in this project only one cycle was performed.
The set of artefacts is not sufficient for an organisation to evolve its R&D process, in practice there are numerous other factors affecting the efficiency of an R&D process at an OEM. Factors from almost every area of research, ranging from management theory via economics to semiconductor technology. The set of artefacts developed is thus shown to mitigate the investigated problems, but not necessarily solve them, at least not on their own.
27 December 2012
Thesis chapter 3: Research design and methodology
There are several research methods used when academia interacts with an industrial setting; experiments, design science or research, action research or participative case studies .
This thesis is in essence a design project; developing artefacts, processes and methods to create opportunities for business for embedded software in mass-produced systems in general, and automotive software in particular. Therefore design research was chosen as the research methodology.
This thesis is in essence a design project; developing artefacts, processes and methods to create opportunities for business for embedded software in mass-produced systems in general, and automotive software in particular. Therefore design research was chosen as the research methodology.
26 December 2012
Thesis chapter 2.6: Research questions
To study the identified problems with software development of mass-produced embedded systems, and at least partly solve, and to achieve the goals above a set of research questions was identified:
The project uses automotive software as a concrete example of mass-produced embedded systems. A question which might be answered during the project is if the context for the automotive industry regarding software development is so different it demands other ways-of-working and architectures compared to other business domains?
RQ1: What are the archetypical approaches for software development in the embedded domain?The investigation of RQ1.1 support research goal G1 of leadtime reduction. The investigation of RQ1.2 and RQ1.4 support research goals G1, G2 and G3.
RQ1.1 What ways-of-working in an R&D organisation for mass-produced embedded systems can create new options for business?
RQ1.2: What are the key properties of architectures for mass-produced embedded systems to create business options?
RQ1.3: How can an OEM evolve the R&D process to support a transition from a closed to an open software ecosystem?
RQ1.4: How can an embedded architecture support innovation and delivery of new features of value to the customer?
The project uses automotive software as a concrete example of mass-produced embedded systems. A question which might be answered during the project is if the context for the automotive industry regarding software development is so different it demands other ways-of-working and architectures compared to other business domains?
25 December 2012
Thesis chapter 2.5: Project goals
This research project started with the ambition to create opportunities provided by an R&D organisation in terms of new ways-of-working, new architectures, and possibly supporting new ecosystems. These opportunities could enable new business models for OEMs delivering mass-produced embedded systems.
This lead to three goals for an original equipment manufacturer aspiring to be world leading in software development:
- Minimise leadtime from idea to implementation of new software features.
- The ability to frequently deliver new software features to end customers
- Decoupling of software development from hardware and mechanical development, both in time and by the design dependencies
24 December 2012
Thesis chapter 2.4: Innovation
Innovative ideas for embedded products are typically collected and prioritized during the roadmapping and requirement management process as part of the yearly release cycle. This cycle is usually determined by manufacturing concerns of the hardware. Feedbacks on innovations from real customers are collected only on new product models, if collected at all.
Since more and more embedded products also are connected, it is conceivable to develop, deploy and measure usage on new software in iterations which lengths are determined by the speed of the software development teams instead of the setup of the manufacturing process, going from years to weeks.
Such an innovation experiment system (IES) would utilise feedback from real users of the embedded products in a scale comparable to the entire customer base. The notion of continuous innovation is not new (link to Ries, link to Bosch}, but the concept is novel in the embedded domain.
The driver for having such an IES is that business and design decisions should be based on data, not opinions among developers, domain experts or managers. The company running the most experiments among the customer base against the lowest cost per experiment outcompetes the others by having the decision basis to engineer products with outstanding customer experience.
The innovation experiment system focuses on incremental innovation according to the framework by Henderson and Clark. The short iterations of experiments are primarily aimed to refine and extend established designs. Improvement occurs in individual software parts, but the underlying design concept remain mostly unchanged, even if there is nothing that prohibits the evaluation of e.g. architectural innovations as well.
Since more and more embedded products also are connected, it is conceivable to develop, deploy and measure usage on new software in iterations which lengths are determined by the speed of the software development teams instead of the setup of the manufacturing process, going from years to weeks.
Such an innovation experiment system (IES) would utilise feedback from real users of the embedded products in a scale comparable to the entire customer base. The notion of continuous innovation is not new (link to Ries, link to Bosch}, but the concept is novel in the embedded domain.
The driver for having such an IES is that business and design decisions should be based on data, not opinions among developers, domain experts or managers. The company running the most experiments among the customer base against the lowest cost per experiment outcompetes the others by having the decision basis to engineer products with outstanding customer experience.
The innovation experiment system focuses on incremental innovation according to the framework by Henderson and Clark. The short iterations of experiments are primarily aimed to refine and extend established designs. Improvement occurs in individual software parts, but the underlying design concept remain mostly unchanged, even if there is nothing that prohibits the evaluation of e.g. architectural innovations as well.
23 December 2012
Thesis chapter 2.3: Software ecosystem
Software ecosystems are characterised by a network of developers rather than a single organisation providing the final product to the customer. An example would be the app markets for Android and iPhone users, where 3rd party developers deliver applications directly to the end user based on a provided platform and through an established infrastructure and marketplace.
The strategic approach of developing software in an open ecosystem instead of as an integrator towards the customer is new in the domain of mass-produced embedded systems, but could provide some advantages also here, for example by extending the innovation base and sharing development risks.
The OEM would still play a vital role as keystone organisation in an open software ecosystem since it manufactures the product and delivers the platform underlying the ecosystem.
The strategic approach of developing software in an open ecosystem instead of as an integrator towards the customer is new in the domain of mass-produced embedded systems, but could provide some advantages also here, for example by extending the innovation base and sharing development risks.
The OEM would still play a vital role as keystone organisation in an open software ecosystem since it manufactures the product and delivers the platform underlying the ecosystem.
22 December 2012
Thesis chapter 2.2: Architecture
Architecture is defined as "the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution."
The architecture is an enabler to achieve certain system qualities, or non-functional properties, and many organisation view their architecture as a strategic technology asset.
An important part in designing an architecture is to identify the organisation or structure of the software and systems parts necessary for the desired qualities. If a certain design or style is used consistent throughout the design of the system it can be considered an architectural pattern. However there are reports that quality attributes are of less importance to users or customers, and this suggest that identifying and delivering competitive features may be more critical to business competitiveness.
Many systems are built on available platforms or frameworks, such as .NET for Microsoft Windows applications, Android for mobile phones or AUTOSAR\footnote for automotive software. The choice of platform constraints the design choices, but also decreases the development effort, at least in theory, and allows software to conform to explicit or implicit domain standards. The challenge for the OEM is to tailor the applications built on top of these platforms to a competitive product. In a sense these types of platforms constitute a reference architecture for a specific product or system architecture.
In this thesis a reference architecture (RA) captures the design ideas and patterns that permeates the architecture with a focus on the design decisions that have great impact on the product family as a whole, i.e. the reference architecture is a template for a specific product or system architecture
This definition of an RA is what is categorised as a ``non-structured reference architecture'' according to Angelov et al., and thus falls outside of their five types of structured RA.
An RA and a product architecture differs, among many other aspects, in that the reference architecture dictates the patterns and principles to implement, i.e. what the design should be, while the product architecture instead captures the instance of the reference architecture with deviations meeting various constraints, i.e. what the design is. Another difference between an RA and a product architecture is that the latter gives a coherent view of the product(s) in a project, possible to track the status of.
The architecture is an enabler to achieve certain system qualities, or non-functional properties, and many organisation view their architecture as a strategic technology asset.
An important part in designing an architecture is to identify the organisation or structure of the software and systems parts necessary for the desired qualities. If a certain design or style is used consistent throughout the design of the system it can be considered an architectural pattern. However there are reports that quality attributes are of less importance to users or customers, and this suggest that identifying and delivering competitive features may be more critical to business competitiveness.
Many systems are built on available platforms or frameworks, such as .NET for Microsoft Windows applications, Android for mobile phones or AUTOSAR\footnote for automotive software. The choice of platform constraints the design choices, but also decreases the development effort, at least in theory, and allows software to conform to explicit or implicit domain standards. The challenge for the OEM is to tailor the applications built on top of these platforms to a competitive product. In a sense these types of platforms constitute a reference architecture for a specific product or system architecture.
In this thesis a reference architecture (RA) captures the design ideas and patterns that permeates the architecture with a focus on the design decisions that have great impact on the product family as a whole, i.e. the reference architecture is a template for a specific product or system architecture
This definition of an RA is what is categorised as a ``non-structured reference architecture'' according to Angelov et al., and thus falls outside of their five types of structured RA.
An RA and a product architecture differs, among many other aspects, in that the reference architecture dictates the patterns and principles to implement, i.e. what the design should be, while the product architecture instead captures the instance of the reference architecture with deviations meeting various constraints, i.e. what the design is. Another difference between an RA and a product architecture is that the latter gives a coherent view of the product(s) in a project, possible to track the status of.
21 December 2012
Thesis chapter 2.1: Ways-of-working
An OEM manufacturing and selling complex embedded systems also use a more or less elaborate R&D process to arrive at the finished design of the product. Ways-of-working refer to the both this overall process used by the organisation as a whole and to the methods and practices that teams and individual developers use within this process.
One of the most common ways to describe the overall R&D process is through a V-model or a waterfall model, with requirements elicitation, design, implementation, testing and maintenance occurring as successive activities.
A more iterative R&D process would follow a spiral model where the successive activities would be iterated, ``spiralling in'' towards the final product via a number of prototypes before delivery.
Agile processes are pushing the concept of fast iterations even further, aiming at having working software after each cycle, which typically last 2-6 weeks. There exist a number of specific agile processes, with XP and Scrum being the two most common. XP prescribes a set of practices even for the individual developers such as pair programming and continuous unit testing. Scrum focuses on the process for the team, e.g. how to prioritise and track what is being implemented.
One of the present challenges is how to scale agile from single teams to large organisations, Spotify being one example. The challenge is how to enable an entire R&D organisation to work with very short iterations when multiple teams work on the same product or systems where some customer features are realised by multiple sub-systems working together.
The most common approach to develop complex embedded systems is with an integration-centric approach, as defined by Bosch & Bosch-Sijstsema: Early in the development cycle requirements are allocated to components. The development teams implement the requirements allocated to their component. After the finalisation of the components the integration phase starts where all components are integrated to form the complete systems and system level testing takes place, where most integration problems are found and resolved.
A common way to manage a development project for MPES is to follow a stage-gate process, where the gates are driven by decisions and investment in the manufacturing of the product, i.e. driven by the hardware.
The gate progression of the development process often correspond to finalisation of software artefacts, e.g. user requirements, system requirements, software architecture, component requirements, and software implementation, i.e. a waterfall process even if the artefacts are updated as the project progresses.
One of the most common ways to describe the overall R&D process is through a V-model or a waterfall model, with requirements elicitation, design, implementation, testing and maintenance occurring as successive activities.
A more iterative R&D process would follow a spiral model where the successive activities would be iterated, ``spiralling in'' towards the final product via a number of prototypes before delivery.
Agile processes are pushing the concept of fast iterations even further, aiming at having working software after each cycle, which typically last 2-6 weeks. There exist a number of specific agile processes, with XP and Scrum being the two most common. XP prescribes a set of practices even for the individual developers such as pair programming and continuous unit testing. Scrum focuses on the process for the team, e.g. how to prioritise and track what is being implemented.
One of the present challenges is how to scale agile from single teams to large organisations, Spotify being one example. The challenge is how to enable an entire R&D organisation to work with very short iterations when multiple teams work on the same product or systems where some customer features are realised by multiple sub-systems working together.
The most common approach to develop complex embedded systems is with an integration-centric approach, as defined by Bosch & Bosch-Sijstsema: Early in the development cycle requirements are allocated to components. The development teams implement the requirements allocated to their component. After the finalisation of the components the integration phase starts where all components are integrated to form the complete systems and system level testing takes place, where most integration problems are found and resolved.
A common way to manage a development project for MPES is to follow a stage-gate process, where the gates are driven by decisions and investment in the manufacturing of the product, i.e. driven by the hardware.
The gate progression of the development process often correspond to finalisation of software artefacts, e.g. user requirements, system requirements, software architecture, component requirements, and software implementation, i.e. a waterfall process even if the artefacts are updated as the project progresses.
Thesis chapter 2: Research motivation
Embedded software is becoming increasingly complex. Ebert & Jones show that the size and complexity of software in an embedded product increases exponentially over time. Numbers from Volvo Cars show a similar exponential evolution (seen in figure the figure below), not only for the infotainment software, which resembles mobile phone features, but also for "traditional" vehicle functionality.
Ebert & Jones mention factors contributing to the complexity in their survey of the present state of embedded software development: ``combined software/hardware systems equipped with distributed software, computers, sensors, and actuators'' which points to the integration aspects of these systems.
They list "high demands on availability, safety, information security, and interoperability" as typical quality attributes.
Ronkainen & Abrahamsson also emphasise that embedded systems are characterised by the concurrent co-design of hardware and software. They stress that the `"dynamics of co-design - i.e. the way it effects the concurrent software development processes, has to be understood in order to enable the use of agile software development methods."
Manhart & Schneider describe agile development of software in buses at Daimler-Chrysler. They mention for example that "equipment, functions, or parameter sets are implemented by integrating different proportions of third party- and OEM manufactured components" indicating supplier involvement. In their paper they also point out that software realises "complex electric or electronic functions", e.g. the integration between hardware and software.
The domain of large industrial development of mass-produced embedded systems can thus be defined by five characteristics:
Broy states some challenges that automotive software is experiencing: "The high intensity of software in cars puts the car industry under stress and a high change pressure." He continues that the trend is not close to an end, and is driven by e.g: "High demand of new innovative or improved functionality'', "shorter time-to-market'' and "increased individualization".
In addition to these challenges the development of MPES exhibit some inherent problems for the R&D organisation, amplified by the present ecosystem of specialised suppliers and OEMs acting as system integrators:
The choice of focusing on ways-of-working, architectures and ecosystems was done for three subjective reasons: In my experience it is easier to change these aspects than e.g. culture, knowledge management, or organizational structures. My engineering background made it easier for me to analyse and develop artefacts in these areas. This is a thesis in software engineering, and all these three areas are well within this field of research.
 | |
| Software in Mbytes downloaded in a vehicle at production at VCC over the years. |
Ronkainen & Abrahamsson also emphasise that embedded systems are characterised by the concurrent co-design of hardware and software. They stress that the `"dynamics of co-design - i.e. the way it effects the concurrent software development processes, has to be understood in order to enable the use of agile software development methods."
Manhart & Schneider describe agile development of software in buses at Daimler-Chrysler. They mention for example that "equipment, functions, or parameter sets are implemented by integrating different proportions of third party- and OEM manufactured components" indicating supplier involvement. In their paper they also point out that software realises "complex electric or electronic functions", e.g. the integration between hardware and software.
The domain of large industrial development of mass-produced embedded systems can thus be defined by five characteristics:
- Deep integration between hardware and software for significant parts of the functionality
- Strong focus on manufacturing aspects of the product during development (e.g. by project gates)
- Strong supplier involvement providing a majority of the parts, and associated value, of the finished product
- Some parts of the software and hardware realise safety-critical functionality
- Long production life-time, sometimes spanning years for a single product model
Broy states some challenges that automotive software is experiencing: "The high intensity of software in cars puts the car industry under stress and a high change pressure." He continues that the trend is not close to an end, and is driven by e.g: "High demand of new innovative or improved functionality'', "shorter time-to-market'' and "increased individualization".
In addition to these challenges the development of MPES exhibit some inherent problems for the R&D organisation, amplified by the present ecosystem of specialised suppliers and OEMs acting as system integrators:
- Heavy reliance on external developers and subcontractors complicates coordination through process because each of them use their own processes.
- Outsourcing of significant parts of development to suppliers causes expensive communication and coordination delays during integration. The cause of this is each issue found must be resolved through an OEM-supplier roundtrip with the OEM identifying the issue, discuss with the supplier(s) who resolves it, and the OEM re-integrating the "fixed" parts.
- The exponentially growing feature content severely complicates "big-bang" integration because used architectures requires all parts to be present for the system to work and therefore testable.
The choice of focusing on ways-of-working, architectures and ecosystems was done for three subjective reasons: In my experience it is easier to change these aspects than e.g. culture, knowledge management, or organizational structures. My engineering background made it easier for me to analyse and develop artefacts in these areas. This is a thesis in software engineering, and all these three areas are well within this field of research.
20 December 2012
Thesis chapter1: Software in mass-produced embedded systems
Software is prevalent in many products manufactured today; cars, washing machines, mobile phones, airplanes and satellites (link to paper), the embedded software controls the behaviour of the product and is often critical for the success of the product.
Typically these products are developed in large, and sometimes very complex, industrial projects where the manufacturing and delivery of the product in general is a heavier investment than the software budget. In the automotive domain the purchasing and manufacturing cost of the physical parts for each product is typically an order of magnitude higher than the R&D cost split over the number of products built.
This in turn tends to drive the entire R&D process, and software follows the process logic of the mechanical development and manufacturing setup.
Software differs compared to its mechanical and electronic counterparts; once the software is developed there is no additional cost if one increases the number of products produced.
Likewise, the cost of updating or replacing software in an already built product is orders of magnitude cheaper compared to replacing hardware.
The common business model is to sell the manufactured system as a product, the original equipment manufacturer (OEM) gets paid an agreed amount for each system delivered. From a customer perspective there are some issues with this present business model when it comes to features purely relying on software. An example scenario in the automotive domain could be:
With more and more vehicles becoming connected it is conceivable to have continuous updates with new software features to customers on a scale and to a cost that is impossible would the updates require hardware modifications. This would build trust in the brand to maintain a useful product and extend the value for the customer after the purchase.
The team developing Google music could deploy it after 3 months of development, making it ``almost competitive'' with smartphones. More and more services are used regardless if one is using the phone or driving in a car, and from a customer perspective it is difficult to understand why services in one context is cannot be delivered in another.
The topic of investigation in this thesis is efficient and sustainable development of software for mass-produced embedded systems (MPES), and the implications a chosen way-of-working and software architecture have on R&D, and indirectly on the business.
Typically these products are developed in large, and sometimes very complex, industrial projects where the manufacturing and delivery of the product in general is a heavier investment than the software budget. In the automotive domain the purchasing and manufacturing cost of the physical parts for each product is typically an order of magnitude higher than the R&D cost split over the number of products built.
This in turn tends to drive the entire R&D process, and software follows the process logic of the mechanical development and manufacturing setup.
Software differs compared to its mechanical and electronic counterparts; once the software is developed there is no additional cost if one increases the number of products produced.
Likewise, the cost of updating or replacing software in an already built product is orders of magnitude cheaper compared to replacing hardware.
The common business model is to sell the manufactured system as a product, the original equipment manufacturer (OEM) gets paid an agreed amount for each system delivered. From a customer perspective there are some issues with this present business model when it comes to features purely relying on software. An example scenario in the automotive domain could be:
My neighbour bought a new Volvo four months after I did.Another example scenario would be
He got Spotify, but I didn't.
Do I feel ``cheated''?
Google music turns out to be the next hot thing. It takes Volvo 30 months to include this feature according to the present stage gate process. Is the feature still ``fresh'' when delivered?A future scenario could be that Spotify is deployed to customers independently of when the car is built in the factory, i.e. after the customer has received the vehicle.
With more and more vehicles becoming connected it is conceivable to have continuous updates with new software features to customers on a scale and to a cost that is impossible would the updates require hardware modifications. This would build trust in the brand to maintain a useful product and extend the value for the customer after the purchase.
The team developing Google music could deploy it after 3 months of development, making it ``almost competitive'' with smartphones. More and more services are used regardless if one is using the phone or driving in a car, and from a customer perspective it is difficult to understand why services in one context is cannot be delivered in another.
The topic of investigation in this thesis is efficient and sustainable development of software for mass-produced embedded systems (MPES), and the implications a chosen way-of-working and software architecture have on R&D, and indirectly on the business.
Thesis: Preface
I promised to post my thesis in a previous post. I hoped to have done so already last week, but things don’t always go according to plan. Here is at least the preface.
I don’t know if I should post a new chapter every day during Christmas, if I want to attract readers interested in development of software for embedded systems I guess this it’s not the best period.
This thesis is the result of my conviction that there was an untapped potential of improving present software development in the automotive domain, based on 10 years of industrial experience at Volvo Car Corporation.
The research project described in this thesis started with a goal of improving the architecture process and the management of software architectures in the automotive domain.
The goal evolved as the project progressed to use the right architecture as a means to improve the overall software development process in order to enable shorter leadtimes and to develop and release new features at a sustainable pace indefinitely.
I started the research project with the assumption that one of the main reasons for the automotive domain of not adopting best practices from other domains is that this domain has very different prerequisites compared to other domains, in the form of business practices, architectures and product properties. An assumption that I have completely reversed since I could find nothing in my empirical data supporting it when I compared with published cases form other domains.
The only reasons left that could explain this is a culture of “not invented here” in the automotive domain when we are looking at how software businesses, architectures, processes and teams play out in other domains.
Hopefully this thesis could be a step towards a better understanding that the automotive domain has more in common with other domains of software-intensive systems, than differences.
27 November 2012
Hiatus
The blog has not been updated at all in the last few months. This has many reasons, with the main being me trying to finish my thesis.
I hope to have a coherent draft ready in just a few weeks and plan to post the chapters of the summary as blog posts in December. Comments are appreciated (if there still are any readers out there).
12 June 2012
Is software engineering research relevant?
I try do be a software engineering researcher. If I scrutinise myself I am as much an engineer as a researcher, and a systems engineer on top of that (but with a clear focus on software-intensive systems).
While trying to finish my thesis I often question if I investigate relevant problems from an industrial perspective, which I believe is the only valid perspective in software engineering, everything else is just playing around. Since software development is a completely artificial activity there are not natural phenomena to study, everything is the result of human activity (and ingenuity).
After attending my latest conference, which had a mix of industrial presenters (probably not peer reviewed) and academic presenters (peer-reviewed, of which I was one) I discussed with a colleague. The conclusion we reached was that the academic researchers had a lot of substance in their presentations, but lacked relevance, while the industry presenters had relevant topics, but lacked substance. The latter seemed in many cases more like a sales pitch.
I have also heard in panel debates at other conferences that software research are diverging from industry needs. This is serious! But what is the problem? Are researchers really addressing the wrong thing (I have already complained about formal methods research)? Or is the step from a published research paper to implement it beyond a simplified academic setting too large for practitioners to take? Or are there so many conflicting research "results" that it is impossible to draw any conclusions as a practitioner beyond personal heuristics? In structural mechanics there are the laws of physics that constrain what is working or not, in software there is no clear boundary like that.
Personally I believe it is the gap, it is just not possible for practitioners to grasp how the results are relevant in their context since research is trying to be as general as possible, i.e. trying to cover as many contexts as possible and in the end not being relevant for any context. Resarch results only valid in a specific context (e.g. a deep case study) are considered second-rate by the research community and often does not pass through the eye of the needle.
There are many different views on the relevance, for example read this report on the future of software engineering research.
While trying to finish my thesis I often question if I investigate relevant problems from an industrial perspective, which I believe is the only valid perspective in software engineering, everything else is just playing around. Since software development is a completely artificial activity there are not natural phenomena to study, everything is the result of human activity (and ingenuity).
After attending my latest conference, which had a mix of industrial presenters (probably not peer reviewed) and academic presenters (peer-reviewed, of which I was one) I discussed with a colleague. The conclusion we reached was that the academic researchers had a lot of substance in their presentations, but lacked relevance, while the industry presenters had relevant topics, but lacked substance. The latter seemed in many cases more like a sales pitch.
I have also heard in panel debates at other conferences that software research are diverging from industry needs. This is serious! But what is the problem? Are researchers really addressing the wrong thing (I have already complained about formal methods research)? Or is the step from a published research paper to implement it beyond a simplified academic setting too large for practitioners to take? Or are there so many conflicting research "results" that it is impossible to draw any conclusions as a practitioner beyond personal heuristics? In structural mechanics there are the laws of physics that constrain what is working or not, in software there is no clear boundary like that.
Personally I believe it is the gap, it is just not possible for practitioners to grasp how the results are relevant in their context since research is trying to be as general as possible, i.e. trying to cover as many contexts as possible and in the end not being relevant for any context. Resarch results only valid in a specific context (e.g. a deep case study) are considered second-rate by the research community and often does not pass through the eye of the needle.
There are many different views on the relevance, for example read this report on the future of software engineering research.
5 June 2012
What can be copyrighted?
Since taking the course on Ethics and Intellectual Property at Chalmers I have become increasinlgy interested in how copyright and patent laws affect software development. United States of America have different patent laws compared to western Europe, usually more obliging of what can be patented, but the legal rulings in the former concern also software used in the latter.
Just a few days ago the verdict in the case of Oracle v. Google regarding copyright infringement on Java API was determined with the concölusion that it is not possible to copyrigth an API, but certainly the implementation of it. A summary of the verdict was written by the judge, William H. Alsup, and is most interesting to read. I think it shows a great understanding of the context of software development from a legal perspective.
Watch an interesting film about the american patent system and software patents: Patent absurdity.
Just a few days ago the verdict in the case of Oracle v. Google regarding copyright infringement on Java API was determined with the concölusion that it is not possible to copyrigth an API, but certainly the implementation of it. A summary of the verdict was written by the judge, William H. Alsup, and is most interesting to read. I think it shows a great understanding of the context of software development from a legal perspective.
Watch an interesting film about the american patent system and software patents: Patent absurdity.
25 May 2012
XP 2012
Here are some random notes taken during the 13th International Conference on Agile Software Development in Malmö, Sweden.
This conference has a heavier presence of professionals compared to many academic conferences. To simplify I would say that presentations in academic conferences are heavy with content, but on irrelevant topics, while presentations form professional are on relevant topics but are lacking in substance.
Best quote today, from Jutta Eckstein: “A sign of lack of trust is formalism”. In organisations where trust is completely pervasive they tend to rely on formalism, i.e. meeting protocols, process documentation, etc.
Clarke Ching's TDD Test Drive
Tankesaft, a blog about innovation, inspiration and development by Karl-Magnus Möller – only in Swedish.
So far there have been some highlights: Jan Boris-Möller talked about making food from an engineering perspective. He specialises in catering for events, which is quite different form working at a restaurant. It isn’t very agile in the sense that the prerequisites change once the event takes place, but is is very agile since he does not want to keep notes/plans/… from one event to the next avoiding pushing any preconceived solutions to the client. He talked about the order to implement things as a professional chef (colour->…->amount->texture->taste, and not taste first which is the amateur's starting point). He also talked about balancing quality attributes; the client can only have two of fast, cheap and good, but never all three (if you you want it fast and cheap it can never taste good).
Later in the evening he mingled and talked about the necessity of having both experience and knowledge (and they not being the same), and the necessity to educate the client/customer about the consequences of what they order in order to meet their expectations. Her also wants to inform the guests before eating of the thinking about designing the dishes which he thought enhanced the experience. a lot of developers could learn from this. And yeah, the food was excellent, traditional Swedish resources and flavours in new ways. Definitely the best conference dinner I have had.
One of the most interesting presentations was from Lars Arrhed, a lawyer, talking about contracts regulating agile development. It contained too much information to convey but some a points was: Suppliers (developers) and clients talk different languages. Clients often have a vision of what the resulting product/system should be, which may be very vaguely described in the contract (“Fully integrated system” and “functional administrative system” were two examples from real contracts in court cases). Therefore a supplier should show progress instead of telling about techniques and methods.
I attended some workshops and tutorials on testing and test-driven design. It felt good I could reason about how to refactor a program in a programming language I don't know (Python). On the other hand I was completely stumped when trying to do "wolf-pack programming" in Smalltalk. I could reason about the program in general terms, but it was very hard to write working lines of code.
In test-driven-design I understand the value of producing high-quality code, but the very small loop increments seem almost to hinder elegant designs that are easy to understand.
This conference has a heavier presence of professionals compared to many academic conferences. To simplify I would say that presentations in academic conferences are heavy with content, but on irrelevant topics, while presentations form professional are on relevant topics but are lacking in substance.
Best quote today, from Jutta Eckstein: “A sign of lack of trust is formalism”. In organisations where trust is completely pervasive they tend to rely on formalism, i.e. meeting protocols, process documentation, etc.
Clarke Ching's TDD Test Drive
Tankesaft, a blog about innovation, inspiration and development by Karl-Magnus Möller – only in Swedish.
So far there have been some highlights: Jan Boris-Möller talked about making food from an engineering perspective. He specialises in catering for events, which is quite different form working at a restaurant. It isn’t very agile in the sense that the prerequisites change once the event takes place, but is is very agile since he does not want to keep notes/plans/… from one event to the next avoiding pushing any preconceived solutions to the client. He talked about the order to implement things as a professional chef (colour->…->amount->texture->taste, and not taste first which is the amateur's starting point). He also talked about balancing quality attributes; the client can only have two of fast, cheap and good, but never all three (if you you want it fast and cheap it can never taste good).
Later in the evening he mingled and talked about the necessity of having both experience and knowledge (and they not being the same), and the necessity to educate the client/customer about the consequences of what they order in order to meet their expectations. Her also wants to inform the guests before eating of the thinking about designing the dishes which he thought enhanced the experience. a lot of developers could learn from this. And yeah, the food was excellent, traditional Swedish resources and flavours in new ways. Definitely the best conference dinner I have had.
One of the most interesting presentations was from Lars Arrhed, a lawyer, talking about contracts regulating agile development. It contained too much information to convey but some a points was: Suppliers (developers) and clients talk different languages. Clients often have a vision of what the resulting product/system should be, which may be very vaguely described in the contract (“Fully integrated system” and “functional administrative system” were two examples from real contracts in court cases). Therefore a supplier should show progress instead of telling about techniques and methods.
I attended some workshops and tutorials on testing and test-driven design. It felt good I could reason about how to refactor a program in a programming language I don't know (Python). On the other hand I was completely stumped when trying to do "wolf-pack programming" in Smalltalk. I could reason about the program in general terms, but it was very hard to write working lines of code.
In test-driven-design I understand the value of producing high-quality code, but the very small loop increments seem almost to hinder elegant designs that are easy to understand.
24 May 2012
Where does a good S/W design come from
One of the 12 principles behind the agile manifesto says
This does not happen in reality. I have experienced colleagues who calls this a “manifested architecture” (every system has an architecture, deliberate or not), in a quite derogatory manner. The common problem with a manifested architecture is that it may fulfil all functional requirements (user stories, features, use cases, …) but does not really support any key quality attributes.
Good design, at all levels, are based on a vision of what the system should be, in terms of functionality/properties and structure. In a self-organised team this is hopefully a shared vision. You can appoint a single person to capture and disseminate this vision (commonly known as an architect), or you can use other principles to define and share the vision. The latter is my positive interpretation of the agile principle above. But you don't hope it happens without concious effort and don't do anything about it...
So how do you learn good design? The best (only) way to do this is to look at other good designs, with as much detail as available. This provides the “type of context dependent knowledge that research on learning shows to be necessary to allow people to develop from rule-based beginners to virtuoso experts”. (Bent Flyvbjerg)
The best architectures, requirements, and designs emerge from self-organizing teams.I have seen cases where I think some teams interpret this as good architecture emerges by itself as long as you follow good practices, e.g. XP, TDD, Scrum, etc. Caveat: I haven’t asked them…
This does not happen in reality. I have experienced colleagues who calls this a “manifested architecture” (every system has an architecture, deliberate or not), in a quite derogatory manner. The common problem with a manifested architecture is that it may fulfil all functional requirements (user stories, features, use cases, …) but does not really support any key quality attributes.
Good design, at all levels, are based on a vision of what the system should be, in terms of functionality/properties and structure. In a self-organised team this is hopefully a shared vision. You can appoint a single person to capture and disseminate this vision (commonly known as an architect), or you can use other principles to define and share the vision. The latter is my positive interpretation of the agile principle above. But you don't hope it happens without concious effort and don't do anything about it...
So how do you learn good design? The best (only) way to do this is to look at other good designs, with as much detail as available. This provides the “type of context dependent knowledge that research on learning shows to be necessary to allow people to develop from rule-based beginners to virtuoso experts”. (Bent Flyvbjerg)
23 May 2012
Is there any use of the V-model?
I’m at the 13th International Conference on Agile Software Development in Malmö Sweden. As usual when I listen to presentations these tend to trigger new liner of thoughts instead of pondering the details of what was said. I guess this is a flaw in how I internalise knowledge from others.
Not surprising, nobody here mentioned the V-model. Too bad,since I think it is one of the most important metaphors regarding software (and system) development there is. But it is also on of the metaphors that have been used in ways which are completely inappropriate.
My “condensed understanding” of the strengths of the V-model is this:
It defines a set of activities on the left side of the V with associated artefacts aimed at exploring the problem and detailing the solution down to the actual product (the code!). The important part is that these design activities have corresponding activities of verification & validation on the right hand side of the V, in a one-to-one relationship between the design and V&V activity. The number of levels is individual, but usually about 3-5, including code is reasonable.
Where it goes wrong is when the V is laid out in time as a template for progress of a project. This may make sense if you are designing for manufacturing-heavy products, but is useless for software, the time between understanding the problem (top-left part of the V) and where you verify that your understanding is correct is just way too long to be competitive. This is definitely not news for software developers, and is a key point in agile software development (but probably phrased differently).
But it seems to me that in order to optimise the efficiency and speed there is a tendency to downplay the activities above the point of the V ( the working code). Big-upfront-design is seen as such a bad thing that it ends up in no design at all, there is a direct jump between formulating the problem (e.g. user stories) and start coding.
I believe that in an agile project all activities in a V must be executed in each sprint in order to claim to be “truly agile”. Each sprint means a better understanding the problem, a better design to solve it, and a better implementation in the code. Of course all of these are verified and validated. That does not say that these activates are equally large, or the size of the V is the same in alls sprints, but if you leave out the conscious architecture in the sprints you don’t learn to do better in the next sprints.
You should design the activities in the V to provide the maximum added value with respect to the spent effort, which obviously depends on thousands of context-specific factors), but saying they are irrelevant is only reasonable for the simplest of systems, where you have a definition of the problem and code.
Personally I rather define the result of the activities, i.e.the artefacts, and let the teams decide themselves on how to populate them. I know blog readers may cry about excessive documentation, but what I am talking about is the necessity to externalise information necessary to share between developers, and teams, and to preserve this information over time, something which code never can do.
Long rant, and I’m not even close the exhausting my thoughts on the subject….
Not surprising, nobody here mentioned the V-model. Too bad,since I think it is one of the most important metaphors regarding software (and system) development there is. But it is also on of the metaphors that have been used in ways which are completely inappropriate.
My “condensed understanding” of the strengths of the V-model is this:
It defines a set of activities on the left side of the V with associated artefacts aimed at exploring the problem and detailing the solution down to the actual product (the code!). The important part is that these design activities have corresponding activities of verification & validation on the right hand side of the V, in a one-to-one relationship between the design and V&V activity. The number of levels is individual, but usually about 3-5, including code is reasonable.
Where it goes wrong is when the V is laid out in time as a template for progress of a project. This may make sense if you are designing for manufacturing-heavy products, but is useless for software, the time between understanding the problem (top-left part of the V) and where you verify that your understanding is correct is just way too long to be competitive. This is definitely not news for software developers, and is a key point in agile software development (but probably phrased differently).
But it seems to me that in order to optimise the efficiency and speed there is a tendency to downplay the activities above the point of the V ( the working code). Big-upfront-design is seen as such a bad thing that it ends up in no design at all, there is a direct jump between formulating the problem (e.g. user stories) and start coding.
I believe that in an agile project all activities in a V must be executed in each sprint in order to claim to be “truly agile”. Each sprint means a better understanding the problem, a better design to solve it, and a better implementation in the code. Of course all of these are verified and validated. That does not say that these activates are equally large, or the size of the V is the same in alls sprints, but if you leave out the conscious architecture in the sprints you don’t learn to do better in the next sprints.
You should design the activities in the V to provide the maximum added value with respect to the spent effort, which obviously depends on thousands of context-specific factors), but saying they are irrelevant is only reasonable for the simplest of systems, where you have a definition of the problem and code.
Personally I rather define the result of the activities, i.e.the artefacts, and let the teams decide themselves on how to populate them. I know blog readers may cry about excessive documentation, but what I am talking about is the necessity to externalise information necessary to share between developers, and teams, and to preserve this information over time, something which code never can do.
Long rant, and I’m not even close the exhausting my thoughts on the subject….
1 April 2012
Working hours
I am glad I don’t work in the US. This article confirms my personal experience that is is not productive to work long hours and still sustain creativity.
27 March 2012
Objectives or activities?
Volvo Cars sets objectives for the company each year. Same as I guess almost every other company. Every department is then required to break down these objectives.
One thing I notice is that often there is confusion between what is an objective and what is the activity to achieve the objective.
Concrete vs. abstract and detail vs. overview...
There often seems to be confusion about two concepts relevant to representing design information, including models.
First there is the scale of abstract versus concrete. Second there is the concept of overview versus details.
If one looks at how a design progresses over time, regardless if one follows a waterfall or agile process, one moves both from abstract to concrete and from overview to details, but they are not the same thing. And I think that agile and waterfall puts different emphasis on on to make these transisions, and where to start and end (topic for another blog post!)
Going from overview to details is simple, the more you know about the problem and the solution the more information is added. think of going from a sketch where you only elaborated on the key classes to understand the system to a class diagam with all classes that are implemented. Using a map as analogy; you increase the scale to see more details, the coastline gets more details, or you see all roads and not only the big ones.
Going from abstract to concrete is also about adding details, and I think that is where the confusion begins. But the details that are added are not of the same type as in the more abstract representation. Here it could be adding all attributes of classes or ports to components. You don't get this information by adding more classes or structure components. In the map analogy it would mean adding indvidual houses on a map which previously only had roads, lakes and forests. It is a new type of information which you cannot deduct (transform) from the more abstract representation.
First there is the scale of abstract versus concrete. Second there is the concept of overview versus details.
If one looks at how a design progresses over time, regardless if one follows a waterfall or agile process, one moves both from abstract to concrete and from overview to details, but they are not the same thing. And I think that agile and waterfall puts different emphasis on on to make these transisions, and where to start and end (topic for another blog post!)
Going from overview to details is simple, the more you know about the problem and the solution the more information is added. think of going from a sketch where you only elaborated on the key classes to understand the system to a class diagam with all classes that are implemented. Using a map as analogy; you increase the scale to see more details, the coastline gets more details, or you see all roads and not only the big ones.
Going from abstract to concrete is also about adding details, and I think that is where the confusion begins. But the details that are added are not of the same type as in the more abstract representation. Here it could be adding all attributes of classes or ports to components. You don't get this information by adding more classes or structure components. In the map analogy it would mean adding indvidual houses on a map which previously only had roads, lakes and forests. It is a new type of information which you cannot deduct (transform) from the more abstract representation.
23 March 2012
Testing
I have to admit that I know too little about software testing in practice to be a well-rounded software developer. That does not mean that I am adverse to testing, on the contrary I think that many architecture focus on properties discernible by the end user and not the developers where testers are a key developer role.
So I am curios if there are any patterns on how to design a testable architecture.
I enjoy the blog thoughts from the test eye, which also has a blog roll if you want to explore further test blogs.
I also stumbled across a very good powerpoint summary about testing in industrial settings from Lappeenranta University of Technology.
So I am curios if there are any patterns on how to design a testable architecture.
I enjoy the blog thoughts from the test eye, which also has a blog roll if you want to explore further test blogs.
I also stumbled across a very good powerpoint summary about testing in industrial settings from Lappeenranta University of Technology.
12 March 2012
Quality starts with me
Outside the main dining hall at Volvo Cars R&D headquarters there is some information about ongoing quality work under the heading "Quality starts with me". A quick google search shows this sentence is not something unique to Volvo Cars, but it got me thinking.
To start with: For software (or any product I guess) quality can be seen from to viewpoints:
Let's say that I review a software specification if all requirements are SMART requirements (insert alternative acronym if desired). Does this support quality of type 1 or 2 above?
When it comes to reviewing or auditing I think it can be applied towards both objectives above, but it requires a lot more of the reviewer if it is the second objective that is the goal of the audit.
To start with: For software (or any product I guess) quality can be seen from to viewpoints:
- Free from defects
- Appropriate according to the needs of the user
Let's say that I review a software specification if all requirements are SMART requirements (insert alternative acronym if desired). Does this support quality of type 1 or 2 above?
When it comes to reviewing or auditing I think it can be applied towards both objectives above, but it requires a lot more of the reviewer if it is the second objective that is the goal of the audit.
26 January 2012
Writing user stories
The blog is updated very seldom nowadays. It is not because I have lost interst, it is just that I write scientific articles with an unprecedented speed in parallel with doing improvement work at Volvo.
I just wanted to put in a reminder of how you define a user story (e.g. for use in a Scrum backlog), shamelessly stolen from a presentation by Dean Leffingwell:
I just wanted to put in a reminder of how you define a user story (e.g. for use in a Scrum backlog), shamelessly stolen from a presentation by Dean Leffingwell:
As a <role>
I can <activity>
So that <business value>
"As a Gmail user, I can select and highlight a conversation for further action"
Subscribe to:
Posts (Atom)