SNESCM

Scandinavian Network of Excellence
in
Software Configuration Management


Scandinavian SCM day

Presentation abstracts:

A Day in the Life of a Project Manager (Kristian Ellebæk Kjær):
The use of CM principles is integral when delivering projects of various sizes and complexity. The same tools and methods should be applied in both very small and very large projects, but sometimes to a different degree. How to apply the principles is an important part of any project plan, must be considered carefully when starting a project, and adhered to during the project. Following these principles is important for the developer, but also makes the daily life easier for the project manager.

SCM vs. WorkItem (Alessandro Notte):
How to coordinate in a office, defferent structure like "finance" "management" and "development" without using old instruments like mail or excel sheet. "All in one" method that allows us to create real KPI involving the entire company.

Traceability in a heterogenous Software development lifecycle (Sofus Albertsen):
The need for efficient traceability in a distributed software development lifecycle (SDLC) is growing with the size of the product under construction. As the lifecycle gets more and more complex, the traceability between the different artifacts is increasingly hard to obtain efficiently, making creation and alternation of a pipeline difficult. By automatically integrating the events of the tools in a graph database and leveraging the ideas of the semantic web, we can make a visualization of the pipeline, giving the much wanted traceability in the SDLC. This thesis will present a data format for creating the graph structure, as well as a framework for extracting the relevant information from the tools included in a distributed SDLC.

Continuous Software Engineering and SCM (Yvonne Dittrich, Jacob Nørbjerg):
Software organizations are moving from short development cycles towards Continuous Testing, Integration and Deployment. Software Configuration Management is a very important enabler for this, but the change also creates new challenges and questions, such as:

We would like to open the floor to a discussion and exchange experiences.

How does CM support the quality of the product? (Artour Klevin):

Repository and Tool Stack Consolidation (Maryanne Kmit):
SimCorp's Open Space discussion will center around exchanging experiences regarding our Repository and Tool Stack Consolidation Proof of Concept project (PoC project), currently underway.
With up to 20+ years of history stored in various repositories, handling history (and how much), handling metadata, pros and cons of DVCS vs. CVCS, handling workflow integration and other questions should be answered in the PoC project. At the same time we want to enable scalability and growth, increase productivity, reduce cost, reduce business risk, and time it all in such a way that the actual implementation of the project becomes an enabler for among other related tools projects, Continuous Integration, ADLM replacement and an Agile transformation project, all in progress today.

CoDe - What is in a word? (Lars Bendix):
Continuous Integration, Continuous Delivery, Continuous Deployment, DevOps - we have many words for the things we love / a favourite child has many names. What are the similarities/commonalities and differences between these concepts?
Who are doing Code? Why are they doing it? And what is it that they do? In this presentation, I will dig into what are the goals that an organization try to obtain by doing CoDe - and what SCM should look out for if they want to succeed in helping the organization to fulfil its goals. In many ways it is more a cultural transformation of a development organization than it is a questions of tools and tricks, so the right pre-requisites have to be in place for this give a positive result (to turn out well).
Finally, I would like to make a strong argument for CoDe being hard-core Configuration Management work that shouldn't be taken care of by "un-informed outsiders".

A Praqmatic approach to Continuous Delivery (Andrey Devyatkin):
A Praqmatic approach to Continuous Delivery. You were a team of 5 and delivering incremental changes wasn't a problem - if something breaks in the continuous delivery pipeline, then you just fix it all together. But now you are ten teams. While you fix your colleagues wait. How to start your journey to continuous delivery and avoid getting into troubles? What can you do to avoid pressure and keep delivery pipeline green? How to stop firefighting and shift towards proactive measures? I would like to share few ways that I used in different projects to overcome growth issues and get teams our of firefighting mode. Which one would work for you?