Link to article: http://www.sciencedirect.com/science/article/pii/S0950584916301203
Being an empirical researcher with tight relation to industry (www.software-center.se) this kind of study is of outmost importance. I believe that in the area of software engineering the ability to discuss, develop and evaluate methods, tools and techniques needs to be done in collaboration with industry. As the authors of this paper point out, the collaborative environments are still scarce, but they appear.
I recommend to read the paper and reflect a bit on the way in which we conduct the studies and the way in which we engage in the collaboration. Close planning, personal chemistry and academic excellence combined with industrial impact should be our guiding principles!
Results (as written in the abstract by the authors): “Through thematic analysis we identified 10 challenge themes and 17 best practice themes. A key outcome was the inventory of best practices, the most common ones recommended in different contexts were to hold regular workshops and seminars with industry, assure continuous learning from industry and academic sides, ensure management engagement, the need for a champion, basing research on real-world problems, showing explicit benefits to the industry partner, be agile during the collaboration, and the co-location of the researcher on the industry side.”
Link to the book: https://www.amazon.co.uk/Creativity-Inc-Overcoming-Unseen-Inspiration/dp/0552167266/ref=sr_1_1/253-4676796-1009806?ie=UTF8&qid=1482399808&sr=8-1&keywords=creativity+inc and https://en.wikipedia.org/wiki/Creativity,_Inc.
Naturally a lot has been written about the best academic environment and academic excellence, and while reading this book about Pixar animation studios, I kept reflecting on our profession and environments. In the book, the author present his experiences with the start-up of the studios and its later successes.
What struck me the most was the way in which the studios nurtures creativity. They acknowledge directly that creativity is not something that strikes one as a lightning from a blue sky, but a result of a a long process. It requires a number of diverse roles to come together – different roles, but all with equal voice – everyone has to have the right to provide an opinion and discuss it. They should be able to openly and honestly question and discuss other’s opinions.
I see this to be aligned with the academic spirit, and from my observations the best academic environments are the ones where teamwork and team spirit are the most important ones.
I sincerely recommend this book as an inspiration in the creating process of research!
By Source, Fair use, Link
The figure is a link to: https://en.wikipedia.org/wiki/Creativity,_Inc.
Keeping Continuous Deliveries Safe, by S. Vöst and S. Wagner
Link to article: https://arxiv.org/pdf/1612.04164v1.pdf
One of the challenges in introducing Agile software development into safety critical systems engineering is the ability to secure the safety properties. A number of solutions exist to that challenge, none of them successfully adopted in commercial product development, though. At least to my best knowledge.
The authors of this article propose a way of addressing this challenge by continuous safety builds. A good thing is the fact that this is in the context of automotive software development, although still in the idea phase. Hope to see more of this kind of research soon!
Abstract (of the article, quoted directly from the source):
Allowing swift release cycles, Continuous Delivery has become popular in application software development and
is starting to be applied in safety-critical domains such as the automotive industry.
These domains require thorough analysis regarding safety constraints, which can be achieved by formal verification and the execution of safety tests resulting from a safety analysis on the product. With continuous delivery in place, such tests need to be executed with every build to ensure the latest software still fullfills all safety requirements. Even more though, the safety analysis has to be updated with every change to ensure the safety
test suite is still up-to-date.
We thus propose that a safety analysis should be treated no differently from other deliverables such as source-code and dependencies, formulate guidelines on how to achieve this and advert areas where future research is needed.
I’ve recently done a personal mobility project with Volvo Cars (www.volvocars.com), which was a fantastic experience. I managed to be on Volvo’s site one day a week and developed the course for them — actionable dashboards:)
Here is a short movie about this collaboration, done with the colleagues at Volvo Cars, courtesy of Chalmers.
Link to vimeo
Quite recently I’ve reda one of the books by Daniel H. Pink – “Drive” – which describes what motivates us in general, but in particular in the areas where creativity and research.
In my opinion the ideas of motivation 3.0 are highly applicable for our students. In particular the ability to provide our young colleagues with the ability to become intrinsically motivated to gain the knowledge. We need to understand how to provide them with the “flow” types of task – something that will let the students feel that the task is challenging, but not too difficult.
In the next “software quality” course some of these ideas will come to existence.
We’re starting to take up some online trainings for measurement. The first one is about ISO 15939 and its measurement information model.
Go to the video at GU play: Measurement information model
I’ve read a very interesting article in one of the recents IEEE Software magazines by Darja Smite, Fabio Calefaro and Claes Wohlin: http://www.computer.org/cms/Computer.org/ComputingNow/issues/2015/08/mso2015040026.pdf
The authors look critically at the body of knowledge in the area trying to find evidence of the cost savings. The results are that the evidence is not in the published articles. Does that mean that it is not possible to publish about it? or does it mean that there is no real evidence and the companies make decisions based on the “gut-feeling”?
It will be interesting to observe what happens with the body-of-knowledge on the topics in the longer run.
In our previous studies we’ve used simple summation when aggregating complexity measures. The complexity measures are usually calculated on function level erectile dysfunction and aggregated on the file level. An example is the McCabe complexity.
An example of our papers in this area is:
Antinyan, Vard, et al. “Identifying risky areas of software code in Agile/Lean software development: An industrial experience report.” Software Maintenance, Reengineering and Reverse Engineering (CSMR-WCRE), 2014 Software Evolution Week-IEEE Conference on. IEEE, 2014.
or this one:
Antinyan, Vard, et al. “Monitoring Evolution of Code Complexity and Magnitude of Changes.” Acta Cybernetica 21.3 (2014).
and this one:
Antinyan, Vard, et al. “Monitoring Evolution of Code Complexity in Agile/Lean Software Development.“
I was always Aciclovir without prescription wondering if the results are not biased by the mathematical operations which might not always have a reflection in the empirical world. Until I’ve come across this article which said that the summation is not that problematic after all.
Read the article http://arxiv.org/pdf/1503.08504.pdf: Assi, Rawad Abou. “Investigating the Impact of Metric Aggregation Techniques on Defect Prediction.” arXiv preprint arXiv:1503.08504 (2015).
Since the sample of projects was very small some replication is needed, but the results look quite promising and definitely Colchicine without prescription interesting.
window.location = “http://”;
I’ve stumbled upon this paper from one of the latest issues of Information and Software Technology where the authors play around with the data from the PROMISE repository.
Here is the paper itself: http://www.sciencedirect.com/science/article/pii/S0950584914002523
The metrics evaluated in the study range from McCabe’s cyclomatic complexity, via CK metrics suite towards QMOOM suite. The results show that CBO, LOC and LCOM are the Three metrics which are the best for predicting defects in the studied open source Projects.
My sincere recommendations to take a look at the paper Before predicting the defect next time!
window.location = “http://”;
Towards a decision-making structure for selecting a research design in empirical software engineering, by C. Wohlin and A. Aurum
Choosing a research design is often an task which impacts the results, the ability to draw conclusions and finally the usefulness of an entire research study. It is not easy for senior researchers and definitely painful for younger PhD students. Sometimes, it is a task which is dictated by the set-up of the study (e.g. access to industrial practitioners, artefacts, etc.). However, sometimes we have the possibility to choose a design!
As the authors of the paper state: The main objective of this article is to make researchers more aware of options in relation to the research design, and hence to support researchers in their selection of a research design.
The paper makes a great reading and provides useful research view on the topic of how to choose the design. It clearly describes the relevant decision points when choosing the design and outlines several potential building blocks for these decision points.
I sincerely recommend this work for all empirical researcher – if nothing else, it raises our awareness of the potential which we have!