Applying Software Quality Objectives
Learn how to use Polyspace® products to track and measure code quality throughout the software development lifecycle with Software Quality Objectives (SQOs). For example, early verification focuses on evaluating intermediate software builds and removing defects introduced at coding time. Post-production verification focuses on evaluating final build quality or finding defect root causes. SQOs cover a variety of techniques and measurements, including gathering code metrics, enforcing coding rules, and proving the absence of run-time errors.
Polyspace allows you to use predefined SQO levels or define your own SQOs to compare against code analysis results. SQOs are especially usefully in continuous integration and DevOps workflows, where they can be used to automate build verification—for example, a gated commit is rejected if the resultant build fails to meet the targeted quality objectives.
Published: 21 Oct 2020
Today, I would like to introduce you to a concept to define and track quality in software development projects. The concept is called software quality objectives. It was developed in cooperation with MathWorks, Renault, Piezo, [? Value, ?] and Delphi. And the aim was to define clear and especially measurable quality objectives into different development stages.
This is of great importance, especially when suppliers are involved, In order to decide whether the agreed quality criteria have been met. Polyspace as a static code analysis tool implements this concept of software quality objectives, which I would like to present you in a short story. Finally, you can decide whether this concept might be applicable for you and get in touch with us.
Doug is a project manager. And he's responsible for software quality of the whole project. So he use of that browser dashboard to monitor what it all was project status and trends. So for instance defect density, cyclomatic complexity, number of open findings. But also he wants to check software quality objectives and the compliance is done that's like MISRA and CERT-C. But the question is how he can do that.
What are software quality objectives. Requirements for software quality are also dependent on the stage in which the development is in. From the start of a project to the start of production. How many intermediate steps-- here are some examples. The software quality objectives are therefore divided into different stages from one to six, in which the scope and the sharpness of the requirements are constantly increasing.
Software quality objects can be easily found and tracked in party Polyspace Access. A Certain quality level can be assigned to a project and the remaining defects to achieve the software quality level can then be shown by clicking on the link in this dashboard. Of course the software quality levels can also be adjusted individually and configured according to the project requirements itself.
So with this you can define your own software quality thresholds. For instance here, we change software quality thresholds for the cyclomatic complexity. Let's say in the software quality objective stage six to the value of six. That means for all the higher level these levels will be also applied. And you can do this for coding guideline violations, for defects itself, you can opt-in opt-out different checks for the software quantity levels. And therefore define your software quality thresholds depending on your project needs.
So another important step in integrating Polyspace into the DevOps workflows is the ability to programmatically access results and project status information. And this is necessary, for example, to control further steps or to implement a kind of a quality gate. So Polyspace Access offers various possibilities to create a list of unreviewed results or open points to achieve a certain quality gate.
One example is Gated Commit as I mentioned before. So the problem here is developers don't know the outcome of their commits, into the source code repository, especially if it's committed into the master branch. So very typical developers break the build. The Solution is a gated commit which is a process to reduce the chance for breaking the master branch. And this will be performed usually by a continuous integration server. The workflow here is that the developer requests the gated commit by submitting the codes into a kind of a branch. And this branch will be analyzed by continuous integration tool like Polyspace in combination with some manual reviews by other colleagues. And if the code changes meet the quality criteria then the code is merged automatically into the master branch. If not, developers informed about the rejection of the change and will probably fix the issues and request an auto-gated commit.
But you can imagine that depending on the system you use it's quite individual so there are specific implementations depending on your needs. If you want to do this please contact us and we can discuss a solution with you.
What's next. If you are interested in Polyspace please feel free to contact us. Our sales team will be very happy to discuss prices and the possibility of a test license with you. In addition, our application engineering team can assist you by implementing the technical solution. However, what I would like to recommend is also to attend to official Polyspace training, which will teach you all of the most important functions and working methods within the product. This saves a lot of time and avoids unnecessary errors when using the tools.
Last but not least, you can also discuss larger projects and individual adjustments with our consulting department. So please feel free to visit www.polyspace.com There you will find further informations about the product and contact information from our team.