{"id":822,"date":"2014-09-10T19:06:01","date_gmt":"2014-09-11T02:06:01","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Polarion-Blog\/8-Best-Practices-for-Building-Quality-Automotive-Software\/ba-p\/380906"},"modified":"2026-03-26T05:31:15","modified_gmt":"2026-03-26T09:31:15","slug":"8-best-practices-for-building-quality-automotive-software-applications-guest-blog","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/polarion\/8-best-practices-for-building-quality-automotive-software-applications-guest-blog\/","title":{"rendered":"8 Best Practices for Building Quality Automotive Software Applications (Guest Blog)"},"content":{"rendered":"

Are you confident that your safety-critical automotive software applications are working as intended?<\/p>\n

If the answer is “no”, you are not alone. And you have good reason to be apprehensive: in the past year, we\u2019ve seen very public software-related recalls from automotive powerhouses like Toyota, Nissan and GM. “This is just the beginning of software recalls,” Roger Lanctot, associate director of Strategy Analytics says. “In the past it was all about mechanical failures.” 
\n

\"Old<\/A>Why were there so many automotive recalls in 2014?<\/STRONG><\/H2>
\nThe short answer is that automotive recalls are on the upsurge because of an increase in software as a percentage of these systems, which in turn means more malfunctioning electronic systems. This surge in recalls signals a crisis in quality that is affecting the entire software industry, from the healthcare.gov web site to applets on your mobile phone.
\n

How can you minimize the risk?<\/H3>
\nWhat can your organization do about the automotive software quality<\/A> crisis? A good first step is to create a culture focused on quality. Some best practices for engineering high quality applications include:
\n

    \n\t
  1. Build High Quality Requirements:<\/STRONG> During the design phase it is critical to build high quality and consistent requirements that do not just address the nominal features, but also edge cases, functional data ranges, and error handling.<\/LI>
    \n\t
  2. Prototype While Building Requirements:<\/STRONG> Ensure that the design is valid by creating prototypes of critical functionality. Will your algorithm scale from 10 data items to 10 million?<\/LI>
    \n\t
  3. Build Testable Software:<\/STRONG>  No one would design a widget that could not be manufactured and tested efficiently, but engineers consistently build software that is hard to test. Small modules with well-defined pre and post conditions make testing easier.<\/LI>
    \n\t
  4. Coding Style:<\/STRONG> Adhere to organization standards for consistency, industry standards for dependability.<\/LI>
    \n\t
  5. Build Complete Test Cases:<\/STRONG> Correctness tests that map to requirements, robustness tests that stresses functional ranges, completeness tests that stress combinations of values.<\/LI>
    \n\t
  6. Meaningful Peer Review:<\/STRONG>  Focused on the architecture, edge cases, and test cases.<\/LI>
    \n\t
  7. Automated Testing Infrastructure:<\/STRONG> Any test, run any time, by any user.<\/LI>
    \n\t
  8. A Culture of Quality:<\/STRONG> Quality is everyone\u2019s responsibility \u2013 not just the QA department.<\/LI>
    \n<\/OL>
    \n

    Tools of the trade<\/H2>
    \nThe good news is that with an investment in a handful of software development tools, you can greatly reduce the effort of implementing the best practices described above. Regardless of the tools selected, the work-flow implemented must be practical and repeatable. Here are the key tools for your toolbox, and some critical features they should support:
    \n