Abstract: User experience design is an important part of software product development, and yet software product line engineering has largely ignored this topic. This paper presents a set of industry best practices for user experience design in software product lines. We conducted multiple-case case study research using two different product lines within the multinational company Siemens AG: in a healthcare software division and in an industrial automation software division. We performed a preliminary exploratory study that will serve as a baseline for future research in the design, implementation, and management of user experience design in the context of software product lines. Practitioners can use our findings and the resulting best practices to improve their user experience design, particularly within
healthcare and industrial automation software product lines.
Keywords: User experience design, UXD, user interface design, software product lines, SPL, engineering best practices, case study research, handbook method
Reference: Nikolay Harutyunyan, Dirk Riehle. “User Experience Design in Software Product Lines.” In Proceedings of the 52nd Hawaii International Conference on System Sciences (HICSS 2019), to appear.
We just finished redoing our original analysis of paid vs. volunteer work in open source for Gitee, a Chinese-dominated code hosting platform from China. We wanted to understand where China stands in open source. Previous blog posts looked at base data, e.g. the half/half split between paid and volunteer work, as well as developer behavior, e.g. that dominantly paid developers still volunteer in their spare time.
In this third and final blog post, I would like to look at projects and how commercially dominated (or not) they are. For the purposes of this analysis, a developer is a (pure) paid developer, if 95% or more of their commits are done during regular working hours, and a developer is a (pure) volunteer, if 95% or more of their commits are done outside of these working hours. Obviously, this is a very conservative definition. How commercial a project is then depends on the percentage of (pure) paid developers and how non-commercial depends on the percentage of (pure) volunteer developers. The following figures shows how many projects exist for the percentage distributions of either pure paid or pure volunteer developers. Please observe the logarithmic y-axis.
We just finished redoing our original analysis of paid vs. volunteer work in open source for Gitee, a Chinese-dominated code hosting platform from China. We wanted to understand where China stands in open source. The previous blog post explained the half / half split between paid vs. volunteer time in terms of total work on open source.
So far, we only discussed commits, now I would like to discuss committer behavior, in particular, whether there are pure paid developers, who only work Mon-Fri, 9am-5pm, i.e. during regular working hours, and pure volunteers, working only outside those hours. Compared to our data for the Western world, the Chinese data is less conclusive. The following figure bins developers into the respective categories, and the following table spells out the bins (categories) explicitly. For the figure, please note the logarithmic scale of the y-axis.
In 2014 we published a study on paid vs. volunteer work in open source, using a representative sample of open source projects from 2008 (i.e. before GitHub). In 2008, open source activity was decidedly Western, with little contributions from China. In 2017, I finally found a student to redo the analysis for China. More specifically, the student was to use what we had identified as the most popular Chinese language code hosting platform and perform the same analysis we had done years earlier. In this sequence of blog posts, I’ll present some of his results. The full thesis can be found on my research group’s blog.
The analysis is based on data from Gitee, a Chinese-language code hosting platform hosted in China, and one of the leading platforms. A first interesting piece of data is that despite its decidedly Chinese focus, 22.4% of all committers to Gitee projects work overseas. They may well be Chinese (at least they are capable of reading and writing Chinese), and I find this number surprisingly large, but we don’t know more than that.
Most interestingly, but perhaps not surprisingly, the weekly work pattern on Gitee is similar to the one in the Western world. The following figure displays this work rhythm. As we can see, work intensity is highest Monday to Friday during regular working hours, similar to Western work patterns.
I just returned from the Berliner Methodentreffen. One of the initiatives that was most interesting to me is a new attempt at agreeing on and standardizing an open exchange format for qualitative data analysis projects between the different QDA tools. As of today, it is not possible to take your data from one vendor’s tool to another; you are locked-in to one product. The Rotterdam Exchange Format Initiative (REFI) is trying to change that using the budding QDA-XML format.
There are three common reasons for why such an exchange format (and hence the initiative) is important.
In our research, we often work with industry. In software engineering research, this is a no-brainer: Industry is, where there the research data is. That’s why we go there. For many research questions, we cannot create adequately, in a laboratory setting, a situation that lets us do our research.
Once a researcher realizes this, they need to decide on whether to charge the industry partner for the collaboration. Many researchers don’t, because sales is not exactly their strength. Also, many shy away from asking for money, because it is an additional hurdle to overcome, once an interested industry partner has been found.
I often discuss with my Ph.D. students how to structure their work and publish the results. There are many pitfalls. It gets more difficult, if we bring in other professors, who may have a different opinion on how to structure the work. Over time, I have found there are really only two main dimensions, though:
Separate work into theory building and theory validation, and publish one or more papers on each topic
Merge work on theory building and validation for an important aspect (hypothesis) into one and publish that