Avoiding software emission problems



Tags: , , ,

Much is being written about, found and reported on the Volkswagen AG emissions scandal. As a long time practitioner of software change and configuration management practices, events such as these become teaching moments from which we can all learn.

An average vehicle today contains around 60 microprocessors to run electric content – four times as many as a decade ago. More than 10 million lines of software code run a typical vehicle’s sophisticated computer network – or over half the lines of code that reportedly run Boeing’s 787 Dreamliner (Source: 2014 Center for Automotive Research)

Software innovations are at the heart of the automotive industry, and the speed and velocity at which software changes in order to drive competitive differentiation, profit and market share is increasing.

Safety critical standards such as ISO 26262 ensure functional safety features form an integral part of the automotive development process. However the increasing volume and velocity of software development is increasing the complexity of software configuration management and placing more accountability on the health and quality of software deliverables regardless of whether the software components are sourced from 3rd parties, open source or internally developed.

Eyeballing the changes in real-time is possible and can now be automated such that developers, engineers and reviewers visibly see defects, errors or vulnerabilities before software deliveries are prepared and delivered. Shift left is a practice of DevOps that seeks to provide rapid feedback to developers and ought to be applied to any software development process.

The discipline and practice of Software Change and Configuration Management should now include a visual and real-time representation of branches and stream activities, integrate a collaborative peer and code review, enable continuous inspection and report rapid feedback to the developers and engineers on process failures, defects, findings and vulnerabilities. For example, a collaborative peer review can generally  save up to 30% of re-work hours, improve coding by up to 25%, and find and detect between 70% & 90% of defects (source: Peer Reviews in Software – a Practical Guide by Karl E. Wiegers) and can be further optimized when integrated into the developmental CM process.

I invite you to check out your existing SCM practices and processes and assess how you can avoid bad software emissions. Learn more about how Serena Dimensions CM 14 can help.

Share this post:

Leave a Reply

Your email address will not be published.