SNESCM

Scandinavian Network of Excellence
in
Software Configuration Management

Presentation abstracts:

A Short Story of Long Transactions (Lars Bendix):
In 1991, Peter Feiler dissected the current functionality of version control tools and how it had evolved over time. Since then very little has happened for version control tools.

Based on Peter Feilers report we will show how version control tool functionality has developed and why different concepts have been invented ending up with the concept of long transactions.

At Lund University, at the beginning of this century, the concept of long transactions was further developed into strict long transactions. We will look at what they are and why they are so useful.

Automating Traceability (Richard Simko):
In order for Software Configuration Management (SCM) tools to provide good traceability links there is usually a great deal of manual effort required. The result is that data becomes unreliable, inconsistent and in many cases nonexistent. The main focus in previous research in this area has been to make general tools which can provide traceability between any type of configuration artifact in any project. The focus of this talk is instead to go back to the core of software development, i.e. the code and the developers. I will talk about how RefinedWiki automated their traceability and turned traceability nightmare into traceability wonderland!

A Day in the Life of an SCM Person (Ulf Steen):
CM within safety development is very "interesting". There are very strict rules and there are many stakeholders that you have to work with. Since everything is under CM it means that you always face new problems, whether it is with the code, test code, tools, environment, documents, etc. The key to keep everything in order, to know what happens to your product, and to be able to support our customers with support, is traceability.

SCM Sales Pitches (Lars Bendix):
How do you explain what (S)CM is and what is your work as a Configuration Manager to an "outsider"?

This "outsider" might be your mother (or father) asking: son, what is it you do when you go to work? Or you meet the CEO of your company in the elevator and he asks you: what is that you do for this company? The project manager might put it more bluntly: why should I pay (part of) your salary? Or you need to convince the developers that your are not always putting obstacles in front of them, but you (SCM) can actually help and support them.

Sometimes you have like "elevator time" (or your father's attention span;-) - other times you will get a podium from where you can communicate - until they "pull the plug" after five minutes.

A group of people have worked with this "challenge" and in this presentation we will show how far they have come - and solicit input, feedback and verification from you.

Continuous Delivery - The Game (Artour Klevin, Ina Volakh):
Continuous Delivery - The Game is a cooperative board game for 3-5 players, where the players together try to transform a traditional Software development way of working into a Continuous Delivery pipeline.

Each player represents a department, for instance development, test or the operations department, and together they can discuss and plan how to improve the software development process.

The goal of this game is to grant awareness in what implementing Continuous Delivery can be about. This game can be played by anyone and does not require any prior knowledge or experience with Continuous Delivery.

Dependencies in a modular architecture (Viktor Attoff, Tobias Landelius):
This open space session will revolve around the dependency related problems that occur when using software with a modular architecture and its solutions. We would like the discussion to cover possible tool functionality as well as process oriented aspects. Our expectation is that including dependencies in a CM-process will increase efficiency of finding inconsistencies of a composition of components, doing impact analyses and being able to focus software testing.

• What is the main dependency related challenges of using a modular architecture and why does these occur?
• What tool functionalities would benefit software projects with modular architecture the most?

Continuous Software Engineering (Jacob Nørbjerg, Paolo Tell):
Using a cafe-based approach, where participants rotate between groups this open space will follow on the steps of last year’s event by continuing the discussion and the experience exchange around the topic of Continuous Software Engineering -- the combination of Continuous Testing, Integration, and Deployment.
Welcoming any related discussion item, we will provide the initial ones based on the outcomes from last year:

• Tooling and Architecting for continuous software engineering
• Continuous quality assurance
• Software processes and interaction with business departments and users

What do we know about Continuous Delivery? (Lars Bendix):
Usually the task of research is to create clarity and insight to drive progress. However, for Continuous Delivery (CoDe) and DevOps it seems like industry is running far ahead of research and driving things - and research could need a helping hand. But people "just doing it" often tend to go in many different - and passionate - directions.
What is CoDe/DevOps? If you look in four different places for an answer, you will get about five different "definitions" - spanning from "semi-religious movement" to "use this/our tool".
Does CoDe/DevOps work - and why? Often the answer is: "it works, trust me" or "it works for me/us". But why? What is it that you do? And will it work for me too - that is, is what you do reproducible?
Is it really a fact that CoDe can give you 200 times faster lead times? Is it just fiction that CoDe will give you 60 times fewer failures?
There is still a lot of work to be done to create clarity and insight. In this talk we will shed light on some of the things that we actually know - and maybe bust a myth or two.