SNESCM

Scandinavian Network of Excellence
in
Software Configuration Management

Presentation abstracts:

Point/Counter-point: The UCM Emperor is Naked! - keynote (Marc Girod) / panel (Lars Bendix):
The keynote will state and argue a number of points that the panel speaker will try to counter. Both speakers will try to engage the audience to their support.

UCM is dated and was conceived in a historical context. At this point already, the perceived state-of-the-art development process was expressed as a branching pattern: branch off, develop, rebase, merge back (the elegance of this pattern lying in its allowing cascading, for hierarchical propagation of changes).
There was already at that stage experimental evidence that this pattern did not work in practice. It was not adopted or needed to be shortcut under pressure; it was too heavy, too complex, error-prone, inflexible.

So let us put SCM back on its feet. Looking for upside-down patterns, for example in UCM: if UCM does X, then the opposite is worth your consideration!

1. UCM focuses on merging to deliver. This is the wrong problem! Merging back brings all the problems branching off was meant to solve.
2. UCM controls the access and the ownership of source files. The important is derived objects. When did you last read grep.c? Optimally, source files are just expendable. The value comes from usage, i.e. from derived objects.
3. Testing is needed for validation? Wrong! Tests work only when they fail. The important activity in testing is thus not running the tests, but writing the test cases. And fixing the code.
4. Don't control people: help them manage. Don't assign tasks: manage contributions. The more you control, the less I control. The more you manage, the more I manage. Control is exclusive, whereas management is collaborative.

ClearCase vs. Subversion (Peter Walls):
This presentation will go through the differences and similarities between two tools: IBM Rational ClearCase in one corner, and Subversion in the other one. A down to earth, fact based presentation of what the differences really are, based on practical experience.

A Day in The Life of a CM Person (Tommy Karlberg):
Ups, downs and challenges during an average day at work. What have we accomplished? What challenges do I see ahead?

SCM and Process Improvement (Otto Vinter):
Why is it that the CM Process Area in CMMI is the hardest one to implement? You, the professional SCM person in your company, possess a unique knowledge on SCM and how it is applied in your organization.
How can you exploit this knowledge better and contribute to the success of your company? This presentation will take a look at the state of SCM in your organization from a process improvement perspective and hopefully give you some new ideas for your SCM work.

SCM and Lean (Christian Pendleton):
One of the major challenges when implementing agile or lean development in an organisation that has been working with more traditional waterfall or incremental models is the change of mindset. How is CM affected by the paradigms in Lean development and how can we as CM responsibles make use of the lean principles in our work?

Implementing Traceability In Agile Software Development (Marcus Jacobsson):
How traceability is handled in agile methods vary from organization to organization, and project to project. When working with traditional development traceability is an important part of the process.
However for some reason this is not the case when working with agile methods. For example in Scrum there is no real definition of how configuration management is supposed to be done. Can we add traceability to Scrum and still call it Scrum?

CM for model-centric development (Lars Bendix):
Industrial use of model driven development (eg. UML) means that we deal with big models and many people in a team working on the same model. The collaboration in a team inevitably leads to people working in parallel creating different versions that eventually have to be merged together.
The present state of merging in the model domain is pretty bad. Commercial tools are flawed and cannot be trusted. Therefore developers resort to other means - serializing their work, doing manual merge, or working directly on the underlying textual representation. All these "solutions" have undesired consequences.
In this presentation, we pinpoint a number of problems to be aware of - and suggest solutions to some of the problems, though there is still a lot to do for both tool vendors and academic research.