Using software archaeology on the way to A-SPiCE® Level 3

Handling legacy software

Authors: Kosmas Kopmeier, Christian Steinmann, Synspace Group

Contribution – Embedded Software Engineering Congress 2018

Most companies' processes describe the development workflow of a product or software starting from scratch. However, there are often projects where the prototype or nearly fully functional code has existed for a long time, sometimes for years. This code, however, was not developed according to the structured and documented processes required for a production project. We refer to this case as software archaeology. The standard procedure of first documenting requirements and then creating an architectural design before writing it down into code doesn't work because the code, for example, doesn't conform to the new, elegant layered model developed by the new software architect.

In the automotive industry, an Automotive SPiCE is typically used.^® Level 2 or Level 3 is required. This means, among other things, that extensive development byproducts must be created, which must also be consistent with each other. If the prototype is not to be discarded but used as a basis, the normal development processes are not suitable, or at least not entirely. This presentation discusses how the process flows can be adapted to achieve the Automotive SPiCE quality objective.^® Level 3 can be reached.

Automotive SPiCE® Level 1-3 Fundamentals

Automotive SPiCE^® is a model for verifying the process maturity of a project. It does not define the process itself, but is, simply put, a collection of idealized action patterns, so-called "„Base Practices“ and "„Generic Practices“, which can be used as a questionnaire to check whether a development process meets certain quality requirements.

An assessment typically focuses on a specific part of the processes, which has been defined by the German Association of the Automotive Industry (VDA) as the VDA scope.

(See Fig. 1.). PDF)

Automotive SPiCE^® This defines the levels 0-5 of process maturity and associated process attributes, each of which receives an evaluation.

List of levels and associated process attributes up to level 3:

• Level 0: Incomplete Process
• Level 1: Performed Process
• PA1.1 Process Performance Process Attributes
• Level 2: Managed Process
• PA2.1 Performance Management Process Attributes
• PA2.2 Work Product Management Process Attributes
• Level 3: Established Process
• PA3.1 Process Definition Process Attributes
• PA3.2 Process Deployment Process Attributes

A level is reached when the associated PAs are rated F or L and all PAs of the levels below are rated F.

(See Fig. 2.). PDF)

Development process on a greenfield site

When a new product or software is developed – at least that's how top managers or clients usually imagine it – the first step is to consider what the software should be able to do. Requirements are written down. These requirements are then categorized into features, which can subsequently be assigned to the various planned releases.

Then you create an architecture, e.g., multiple layers, and define basic concepts, e.g., preemptive or non-preemptive operating system, time-slice or event-driven control, etc.

A design is created according to the specifications of the architecture, e.g. in UML or Matlab, and the code is developed from it.

Subsequently, everything is tested, from unit testing to interface testing, in which the design is verified, integration testing, in which compliance with the concepts of the software architecture is checked, to testing against the requirements.

The entire development process is framed, on the one hand, by project management, which, at least if you consider an A-SPiCE^® Reaching Level 3 involves not only planning all tasks, but also estimating the effort, monitoring it, and responding appropriately to deviations from the plan.

Secondly, the development process is framed by quality assurance, in which the quality objectives of all work products and the process flows are defined, reviews are planned and carried out, and deviations are tracked until corrective action is taken.

Naturally, all work products are under version control, and the intended baselines are created in the various configuration management tools for each release.

In the development of series products, several prototypes – in the automotive world called A-samples, B-samples, and C-samples – are typically developed in iterative cycles. In this process, all steps of the development process are repeatedly performed, and the work products, and of course the final product, are continuously improved. This iterative process is controlled by a problem-solving and change management process.

(See Fig. 3.). PDF)

Development process in software archaeology

However, there are also development projects that do not start from scratch, but rather those where large parts of the code already exist, but – more or less – no written documentation of requirements, architectural specifications, UML designs or similar exist.

The existing code is then transformed into a more human-readable design, for example using Doxygen. Often, some initial optimizations are visible, achieved through a... refactoring of the code without any change to the content.

Creating a software architecture is considerably more difficult if the software wasn't originally developed according to a clear, written model with different layers; in such cases, it usually doesn't correspond to even the most elegant structure devised later. Nevertheless, it's important to define such a target structure so that future iterations can progressively approach it.

It is somewhat easier, but also challenging, to subsequently determine the requirements that the software already meets and then write them down.

In the following steps – just like in a greenfield development process – everything is tested, from unit tests to interface tests that verify the design. These tests are particularly important as regression tests to ensure that... refactoring No accidental errors occur in the code.

Furthermore, there is also the integration test, in which compliance with the concepts of the software architecture is checked, and the test against the requirements.

Of course, project management is also involved here, and although the planning includes not only the implementation of new features but also the optimization of existing code, everything still needs to be planned. Efforts must be planned and monitored, and in the event of deviations from the plan, which can occur much more frequently, replanning and updating of all plans are necessary. There are usually clearly defined milestones by which a release must be created for the customer, so careful consideration must be given to how much effort is invested in optimizing existing code and how much in developing new features.

Here, too, the development process is framed by quality assurance. With a continuous integration and testing process, different quality standards can be defined using the right tools: one for existing code and one for new features. This approach will be examined in detail in the following chapters and slides. In any case, defining the quality of individual work products for each iteration is significantly more difficult here than with a completely new development. Nevertheless, to achieve an A-SPiCE^® To achieve Level 3, the quality objectives of each work product are planned, monitored, and deviations are tracked.

Naturally, in this process too, all work products are under version control and the intended baselines are created in the various configuration management tools for each release.

Iterations in new developments

New development involves implementing new features and bug fixes for upcoming releases. Both typically come with new requirements. Ideally, the architectural concepts remain unchanged or are slightly extended, and then, of course, the design and code are also expanded. Testing is expanded concurrently with development.

Everything grows at the same rate.

Iterations in software archaeology

In software archaeology, the desired test depth must first be achieved and the coverage of the unit tests increased. Then, the number of discrepancies between the software architecture diagram and the code must be reduced by further aligning both sides. Due to the refactoring The interface tests must also be adapted to the code. The better the product is understood over the course of the project, the better the appropriate requirements can be defined, which can then be verified during testing.

The number of unit tests, requirements, and software tests is increasing, while the number of architectural elements and Lines of Code remain constant.

Rules and objectives for new development

• The architecture is based on the non-functional requirements for the software.
  The goal is to ensure compliance with these requirements.

• Design and code correspond to the architecture.
  The goal is good maintainability.

• The number of MISRA warnings (violations of coding policy) will be reduced.
  The goal is to minimize risk.

• There are unit tests for every function or even every line of code. This can be easily implemented alongside the development effort.
• There are test cases for every requirement.
  The goal is to ensure compliance with the requirements.

Rules and goals in software archaeology

• The architecture should meet the non-functional requirements. This takes several iterations.
• Changing external interfaces leads to incompatibility.
• A change in behavior may lead to incompatibility.
• Adapting the code to the architecture leads to better maintainability, but is also a source of new errors.
• Adapting the architecture to the existing code may lead to better maintainability, but also to an unreadable architecture.
• While resolving MISRA warnings reduces the risk of unwanted behavior, it also introduces new errors.
• Creating unit tests for each function (100% function coverage) sometimes takes several iterations according to the release plan.
• Having test cases for all requirements is only possible for requirements that have already been identified.

Continuous integration and continuous testing

To compare a subsequently created UML architecture with the actual code, tool support is needed. Axivion's Bauhaus Suite offers a good solution, employing a continuous integration and continuous testing approach. It allows for continuous monitoring of the number of violations between the architecture and the actual code, and whether these violations are new or were present in previous versions. Similarly, it handles errors, providing a simple visual distinction between newly added MISRA warnings and those already present in a previous version (adjustable via a slider).

The advantage of this distinction between old and new errors is crucial for quality assurance. Different quality standards can be defined here:

• For code that remains untouched
• For code that is modified
• For code that is being rewritten

This makes quality significantly more predictable, which has a positive impact on Automotive SPiCE.^® process attributes PA2.1 and PA2.2 are affected and thus impact SPiCE^® Levels 2 and 3.

Practical experience with a software archaeology project on the way to Automotive SPiCE® Level 3

The experience with software archaeology is based, among other things, on a specific project in the automotive sector. Here, a supplier was commissioned to re-archive a software program called "SPiCE," which had evolved over eight years based on an open-source project and was already in series production.^® To achieve "Level 3 compliance," development processes had to be adapted, new development tools introduced, and, above all, the planning process implemented very closely. We provided intensive process support to the development team for a year until a SPiCE (Self-Proofing Certificate for Development) was achieved.^® Level 2 could be demonstrated in all processes, and SPiCE is expected to be demonstrated a further year later.^® Level 3 must be demonstrated in absolutely all processes.

External links

https://www.automotivespice.com/fileadmin/software-download/Automotive_SPICE_PAM_30.pdf

https://www.axivion.com/de/produkte-58

https://www.synspace.com

authors

Mr. Kosmas Kopmeier is a graduate in Computer Science (FH) and an intacs™ certified Automotive SPiCE^® Assessor. He has worked as Director of Engineering Consulting for SynSpace Group GmbH in Freiburg since 2017 and is a consultant for process quality and functional safety, as well as an Automotive SPiCE.^® Assessor at numerous automotive suppliers and manufacturers, as well as at manufacturers of industrial products. He has over 20 years of experience in the development of embedded systems and therefore takes a pragmatic approach to all process-related issues.

Mr. Christian Steinmann He is a Senior Consultant for Process Improvement and has been Managing Director of the SynSpace subsidiary "HM&S IT-Consulting GmbH" in Graz since 1995. He holds a degree in Technical Mathematics, is intacs™ certified, a Scrum Master, and the owner of a technical engineering firm. He leads the (further) development of the SPiCE 1-2-1 Assessment Tool. In the banking and automotive sectors, he has conducted more than 100 assessments according to SPiCE and CMMI standards, respectively, and has also provided training on these topics. On Fridays, he lectures on computer science and software development at the FH Joanneum University of Applied Sciences in Graz for the Automotive Engineering program, teaching students programming.

Download the article as a PDF file