Keynote at ICSSP 2015: Software Development as an Experiment System

“Software Development as an Experiment System” is the title of the keynote that Jürgen Münch, University of Helsinki, is going to present on 25th of August 1 pm at the International Conference on Software and System Process 2015.


Abstract: Most modern software development activities are focusing on domains of emergence where experts cannot know a priori what kind of software provides value to users and customers. This is fundamentally different to traditional software engineering for large systems where a priori analysis by experts is used to identify requirements. While the latter is gaining a niche software category, developing and establishing development practices for domains of emergence is becoming significantly important and urgent. A major challenge is to find the right scope for software development. There are many options on what to deliver. Software practices are needed that help in determining what customers want and creating the right capabilities for them. In this talk I introduce an approach for steering software development towards the right scope by continuously conducting experiments. This includes systematically observing users’ behavioral responses to stimuli such as features. Insights from experiments directly influence frequent iterative deliveries. Success cases from industry show that such an experimental approach helps companies to gain competitive advantage by reducing uncertainties and rapidly finding product roadmaps that work. This presentation is aimed at process engineers, researchers, product managers, startup founders, business people, software developers, and anyone who is interested in making an impact with their products. It shows the relevance of experimentation in software development and how it influences the software process. In addition, new methods and practices are presented that have been tested in different industry environments. The talk answers questions such as:

  • How do we rapidly and effectively create value for users and customers by integrating experimentation into software processes?
  • How do we identify the relevant experiments we need to conduct for making good product decisions?
  • What are the components of a good hypothesis?
  • How do we link the experimental findings with product decisions and dynamically change a product roadmap?
  • What are the key obstacles when introducing continuous experimentation in an organization and how can we address them?
  • What are future avenues for software process research?

Date: Tuesday, 25th of August 1 pm

Venue: Tallinn, Viro Hotel, Estonia

Jürgen Münch is a full professor in the Department of Computer Science at the University of Helsinki. He specializes in software and systems engineering, in particular data- and value-driven software engineering, software measurement, innovative software processes, software quality assurance, and global software development. Results are documented in five books and more than 140 refereed publications. He is co-inventor of GQM+, a method for aligning company’s software strategies with long-term business goals. Dr. Münch has been a principal investigator of numerous research and industrial development projects and regularly consults for companies on issues including quality improvement, IT business alignment, software measurement, process engineering, and software technology in general.

All keynotes at ICSSP 2015 at a glance.


How to Combine Embedded Systems and Cloud Computing?

Embedded systems are everywhere. Yet, many of these systems are islands in an age where more and more systems are being connected to the Internet. The ability to connect to the Internet can be taken advantage by resources cloud computing can offer. A recently finished thesis conducted in the Software Systems Engineering Research Group at the University of Helsinki presents what cloud enhanced embedded systems are and what their benefits, risks, typical implementation methods, and platforms are.

The study addresses the questions

  • What use cases are there for combining cloud and embedded systems?
  • What kind of experience or empirical evidence exists for integrating cloud into embedded systems?
  • How are cloud enhanced embedded systems classified?
  • What are the benefits of cloud and embedded system integration seen by researchers?
  • What are the risks and challenges of cloud and embedded system integra- tion seen by researchers?

What are the prerequisites for integration of cloud into embedded systems?
How is the integration of cloud into embedded system typically done?
What architectures, platforms and hardware are used in cloud enhanced embedded systems?
The study shows that the interest from academia and practice in cloud enhanced embedded systems has been growing significantly in recent years. The most prevalent research area is wireless sensor networks followed by the more recent research area Internet of things. Most of the technology is available for implementing cloud enhanced embedded systems but comprehensive development tools such as frameworks or middle wares are scarce. Cloud enhanced embedded systems will also be key for the Industrial Internet (sometimes also referred to as Industry 4.0 / Industie 4.0)

Results of the study indicate that existing embedded systems and other non-computing devices would benefit from connectivity and cloud resources. This enables the development of new applications for consumers and industry that would not be possible without cloud resources.

Perceived benefits of cloud integration to embedded systems are

  • Remote Monitoring Ability
  • Extended Data Storage
  • Benefits from Distribution
  • Pervasiveness
  • Offloading (Data, processing)
  • Ad-hoc communication
  • Remote Management
  • Added Functionality
  • New Application Possibilities
  • Web services
  • Mobility

The academic literature is full of use cases for cloud enhanced embedded systems and model implementations. However, the actual integration process as well as specific engineering techniques are rarely explained or scrutinized. Currently, the typical integration process is very custom to the application. There are few examples of efforts to create specific development tools, more transparent protocols, and open hardware to support the development of ecosystems for cloud enhanced embedded systems. Read the study here.

Related article:

  • [PDF] [DOI] Nilay Oza, Jürgen Münch, Juan Garbajosa, Agustin Yague, Eloy Gonzalez Ortega. Identifying Potential Risks and Benefits of Using Cloud in Distributed Software Development. In Proceedings of the 14th International Conference on Product-Focused Software Development and Process Improvement, June 2013. Paphos, Cyphrus, June 12-14, 2013
    [Bibtex] [doi] [url] [pdf]
    author = {Nilay Oza, Jürgen Münch, Juan Garbajosa, Agustin Yague, Eloy Gonzalez Ortega}, 
    title = {Identifying Potential Risks and Benefits of Using Cloud in Distributed Software Development}, 
    booktitle= {Proceedings of the 14th International Conference on Product-Focused Software Development and Process Improvement}, 
    year = {2013},
    month = {June},
    note = {Paphos, Cyphrus, June 12-14, 2013},
    url = {},
    doi =  {10.1007/978-3-642-39259-7_19}

How to Find out Which Features to Implement in Popular Smartphone Apps?

In the world of smartphone applications, there is a rich set of user feedback and feature suggestions which are updated continuously. Especially for smaller development teams, prioritizing these requests is of utmost importance. The prioritization is usually done based on techniques which rely on methods that are built upon predictions and customer interviews such as “Would you buy that feature?”. However, predictions can be wrong and customer interviews suffer from contextual biases.

We developed an approach that allows us to find out about the real business value of a feature. The approach is based on mock purchases and allows product managers and developers to depict the real business value of a feature without having to implement it. Hence, the approach allows feature prioritization based on facts rather than on predictions. The rationale behind the approach is to eliminate contextual biases. On top of that, the approach allows us to experiment with the feature pricing.


Figure 1. Approach.

Figure 1 depicts six elements of the approach:

Product Backlog: Each user is assigned only one of the features from the backlog that are to be tested. Thereby, potential contextual biases can be reduced to a minimum.
Description Page: For each feature, a custom description page is created which describes the feature and contains a button to load the feature’s price.
Purchase Page: After loading the price, the amount is displayed on the page and a purchase button appears.
Acknowledgement Page: After purchasing, the user receives an acknowledgement about the feature not having been implemented yet. Moreover, the user is then asked whether he or she likes, dislikes, or very much dislikes the approach. On top of that, he or she can provide a custom message in case he or she needs the feature urgently or wants to complain.
Questionnaire Page: In case the user cancels the purchase (i.e. wants to move away from the page after having loaded the price), he or she is asked why he or she did so. Users can choose that they are not interested in the feature, it is too expensive, they were disappointed by other in-app purchases, or they do not spend money on apps. They can also provide a custom message.

The study was implemented in an app called Track My Life which is used by Nokia CEO Stephen Elop and the Finnish Minister for European Affairs, Alexander Stubb amongst others. The app is a GPS Tracker that automatically collects the users’ location information in the background and analyses the data upon opening the app. Thereby, it can answer questions such as “How much time do I spend at home, work, and on my way to work?”. On top of that, it provides statistics such as how many kilometers the user travels per day, week, and month, and which places he or she spends most of his or her time at.

Moreover, the app leverages user feedback by providing several mechanisms e.g a Zendesk and Jira client to provide feedback to the developer.

The study started on April 5, 2013 and ended on April 23, 2013. Prior to that, the implementation of the app in both the iOS and Windows Phone version was done. The implementation took about 1.5 days per platform due to specialities such as the possibility to enable and disable the study remotely and converting feature prices to the users’ local currencies in price intervals which correspond to their smartphone operating system’s pricing intervals (i.e. convert 1€ to flat 70 rupee rather than to 71.54 rupees). Figure 2 represents the implementation of the approach on iOS (left) and Windows Phone (right).


Figure 2. Implementation on iOS and Windows Phone.

Finding the Right Features to Implement

Figure 3 depicts the number of purchases that were made as well as the hypothetical revenue attached to those. Each of the six columns represents one feature at a given price tag. In total, there were two features being investigated, each of those at the price tags EUR 1, EUR 3, and EUR 5. As an example, SSF represents feature one and the number 3 represents that the base price (i.e. the price that was converted into the users’ currencies) was EUR 3.


Figure 3: Number of purchases and revenue.

As anticipated, figure 3 depicts a correlation between the number of purchases and the price of a feature. Moreover, it allows us to compare the two features and also allows us to make judgements about the feature pricing. For instance, EUR 5 for the HF feature yields a lower total revenue than EUR 3. In contrast to that, the maximum revenue for SSF seems to be at an even higher price tag than EUR 5. Moreover, the revenue created with SSF is higher than HF.


Figure 4: Number of users who said that they did not buy the feature because it is too expensive.

Figure 4 shows the number of users who regarded the feature as too expensive when surveyed about why they cancelled the purchase (i.e. tried to navigate back from the feature’s description page after loading the price). It underlines the point that there is a correlation between a feature’s price and the number of purchases and also that fewer users are willing to pay for the feature HF at a price tag of EUR 5 than for SSF at the same price.

14% of the users were unsatisfied (i.e. selected I dislike the approach) or very unsatisfied (i.e. selected I am very annoyed by the approach). However, the wide majority of users understood the purpose of the experiment.

We showed that the approach allows us to find out about the real return of a feature and allows us to find the ideal price of a feature.

The study is described in the following article and will be presented at the Lean Enterprise Software and Systems Conference in Galway, Ireland (December 1-4, 2013). The reference for the article is the following:

  • [PDF] [DOI] Alexander-Derek Rein, Jürgen Münch. Feature Prioritization Based on Mock Purchase: A Mobile Case Study. In Proceedings of the Lean Enterprise Software and Systems Conference (LESS 2013, Galway, Ireland, December 1-4), volume 167 of LNBIP, pages 165-179. Springer Berlin Heidelberg, 2013.
    [Bibtex] [doi] [url] [pdf]
      author    = {Alexander-Derek Rein, Jürgen Münch},
      title     = {Feature Prioritization Based on Mock Purchase: A Mobile Case Study},
      booktitle = {Proceedings of the Lean Enterprise Software and Systems Conference (LESS 2013, Galway, Ireland, December 1-4)},
      publisher = {Springer Berlin Heidelberg},
    series = {LNBIP},
    volume = {167},
    pages = {165-179},
      year      = {2013},
    doi = {10.1007/978-3-642-44930-7_11},
    url = {}