Teaching

Supervised Master's theses


Inherently releasable software components

We work on a huge software system with hundreds of components and thousands of developers involved. Traditionally we have seen the information needed to take a release decision for a software as something we collect "in the end" of the process. When we want to release we (many times manually) collect data from multiple sources about product versions, content and quality. The information is separate from the software itself. This is not working well when the frequency of releases increase (months to days) and number of software variants increase. It also has focus on release in the end of the process which makes e.g. a DevOps setup hard if we want to test small changes early, before all process steps for full release have been completed.

We want to explore other concepts. Can we make the software "inherently releasable". Can we instead of collecting the release information in the end make it possible to at any point in time pick a software component and immediately see all relevant release information that is connected to it? So that we e.g., can pick something in an early development phase, see that is does not fulfil all requirements but enough to run in a customer environment as a test.

Potential study: can we distribute responsibility for the release activity without losing trust in the release process of the complete system. What would such a setup look like? "Can I at any time assess any product component against a set of release requirements without going to other information systems"


Maintained by bendix@cs.lth.se