April 3, 2019
Today our PROCESS FELLOW Bernhard Sechser hold a speech on the ocassion of the VDA Automotive SYS Conference China in Shanghai.
For more info please have a look at the abstract of his speech:
The quality of software development is one of the most discussed topics in the past 50 years. At this time nobody worried about software in vehicles as nearly all systems were based on mechanical knowledge and experience. If one of these systems failed it was somehow easy to diagnose and repair it, even for people without deep technical knowledge.
Nowadays this is a kind of impossibility. Modern vehicles contain hundreds of electronic parts and subsystems with millions of lines of code. Software is used by everybody who is driving or even only sitting inside a car. Starting with high complex systems like “Active Cruise Control” down to pretty small ones like the button for opening a window. Most of the drivers will not think about the functionality, they just expect that it works when they need it, like the “old” mechanical parts.
But what is the real difference between software parts and other technologies? Right – the time when the quality is assured! Software quality is nothing you can ensure during production like for mechanical parts. Software quality must be built in during development, by experienced engineers who do not only know how to “hack” something, to create the source code. They need to think about a systematic approach in order do develop the right software system with the desired functionality and reliability. They should not only be proud of their “hero” skills, but on how to work together in a team of experienced software engineers where all the important information must be exchanged and reviewed, like requirements and acceptance criteria.
But what is a good systematic way? How to ensure that engineers behave in a way to avoid serious problems? You have to think about a process-driven approach, which is defined in nearly all companies. But is this approach really used and implemented in projects? Do the engineers understand the purpose of defined roles, activities and responsibilities? Or do they just use tools and fill-in document templates without thinking about their own added value? Is their implementation managed in a defined way, and are the work products really established?
With experts that have many years of experience in systematic engineering approaches and skills to evaluate the work of other engineers, intacs™ founded 14 years ago a scheme for educating assessors with comparable skills in order evaluate such development projects with respect to engineering standard like ISO 15504 (SPICE) resp. ISO 330xx, or domain specific variants like Automotive SPICE®, SPICE4Space, Medical SPICE, and much more. These standards contain the most important basic requirements (practices) for a “good” system and software engineering. For other topics like Functional Safety standards exist, too, e.g. IEC 61508 or ISO 26262. Most of the process relevant requirements in these standards are already covered by the SPICE base practices, but not the safety specific ones. How to evaluate them in a project specific assessment? Is it ensured that assessors are capable of understanding them? Is it even necessary?
Another example is the development with other approaches beside the typical V model, e.g. by using agile methods. Are they compliant with SPICE? Or is it a completely different way of working? What about security related parts of a system, ADAS or even autonomous driving cars?
All these are questions intacs™ must face with. What is the influence on assessor skills and education in order to be capable to evaluate safety- and security-related projects, maybe in an agile development environment? The presentation will show the current situation and the next strategic steps of intacs™ in order to keep up with all these challenges in a distributed world of system and software engineering.
For more info please have a look at the abstract of his speech:
The quality of software development is one of the most discussed topics in the past 50 years. At this time nobody worried about software in vehicles as nearly all systems were based on mechanical knowledge and experience. If one of these systems failed it was somehow easy to diagnose and repair it, even for people without deep technical knowledge.
Nowadays this is a kind of impossibility. Modern vehicles contain hundreds of electronic parts and subsystems with millions of lines of code. Software is used by everybody who is driving or even only sitting inside a car. Starting with high complex systems like “Active Cruise Control” down to pretty small ones like the button for opening a window. Most of the drivers will not think about the functionality, they just expect that it works when they need it, like the “old” mechanical parts.
But what is the real difference between software parts and other technologies? Right – the time when the quality is assured! Software quality is nothing you can ensure during production like for mechanical parts. Software quality must be built in during development, by experienced engineers who do not only know how to “hack” something, to create the source code. They need to think about a systematic approach in order do develop the right software system with the desired functionality and reliability. They should not only be proud of their “hero” skills, but on how to work together in a team of experienced software engineers where all the important information must be exchanged and reviewed, like requirements and acceptance criteria.
But what is a good systematic way? How to ensure that engineers behave in a way to avoid serious problems? You have to think about a process-driven approach, which is defined in nearly all companies. But is this approach really used and implemented in projects? Do the engineers understand the purpose of defined roles, activities and responsibilities? Or do they just use tools and fill-in document templates without thinking about their own added value? Is their implementation managed in a defined way, and are the work products really established?
With experts that have many years of experience in systematic engineering approaches and skills to evaluate the work of other engineers, intacs™ founded 14 years ago a scheme for educating assessors with comparable skills in order evaluate such development projects with respect to engineering standard like ISO 15504 (SPICE) resp. ISO 330xx, or domain specific variants like Automotive SPICE®, SPICE4Space, Medical SPICE, and much more. These standards contain the most important basic requirements (practices) for a “good” system and software engineering. For other topics like Functional Safety standards exist, too, e.g. IEC 61508 or ISO 26262. Most of the process relevant requirements in these standards are already covered by the SPICE base practices, but not the safety specific ones. How to evaluate them in a project specific assessment? Is it ensured that assessors are capable of understanding them? Is it even necessary?
Another example is the development with other approaches beside the typical V model, e.g. by using agile methods. Are they compliant with SPICE? Or is it a completely different way of working? What about security related parts of a system, ADAS or even autonomous driving cars?
All these are questions intacs™ must face with. What is the influence on assessor skills and education in order to be capable to evaluate safety- and security-related projects, maybe in an agile development environment? The presentation will show the current situation and the next strategic steps of intacs™ in order to keep up with all these challenges in a distributed world of system and software engineering.