Hello to all the software developers, project managers, testers, quality managers, lead managers, security, and safety and process methods and tools managers today. And of course, all of those I have forgotten. I'm pleased that so many of you have attended this webinar today. So it will be very interesting for you. And I really hope that you can use some of the information in your daily work. So please do not hesitate to contact me and our sales team if you have any questions or want to get started.

Before we get started, something about myself. My name is Christian Guss. I have been working for The bat365 in application engineering for Polyspace for almost seven years. And meanwhile, we have a European-wide acting team to support customers from all industries with the integration of Polyspace with static code analysis in their workflows. So even if you do not have a model base design workflow in place, and you are doing hand code, you are today in good hands with us.

For today, I have prepared the following agenda. First of all, I would like to introduce Polyspace in the context of static code analysis and especially point out where we differ from other tools in the market. But the real topic today is DevOps and continuous integration. So after a short introduction, I will go through the integration of Polyspace into these workflows step by step with you.

So we will orient ourselves on three main stages of expansion, evolutionary of course, not revolutionary. I would like to conclude the webinar and actually each chapter with a short summary of what you should remember and how you could start. Please write down your questions directly in the Q&A. I will take my time to answer the questions after the end of this webinar. So please stay with me at the end. Even if you do not hear from me for one or two minutes, this is because I will read and sort out the questions first.

All right, so let's get to the first part of this webinar, why Polyspace is the right choice when it comes to static code analysis. So why do we need static code analysis if you already spend so much time in testing and you can't really find any errors anymore? The central problem with testing for errors is testing is never complete. As the following quote illustrate, "Testing can be used to show the presence of bug but never their absence. "

Quite often, the method of code review is used, which means that experienced programmers will find the errors of their colleagues. The following example shows impressively how difficult it is, especially with languages like C and C++, which contains implicit conversion rules. So in the following example, we would like to assume that the if condition is true because the value of a minus 1 is less than 0. So the value minus 0 is then passed to the variable divisor, and this is preventing the division by 0 in line 11.

So obviously this is not the case, as debugging shows us. So here, we have a little example in my Eclipse environment. And I like to use a normal debugger like GCC. So if I debug through the codes, you can directly see that I start in the main function going in the can_you_find_a_bug function. And stepping through the function code, you will see directly the divisor is 0 because the if condition was not entered.

So the Polyspace integration in Eclipse can point out these kind of problems quite early, which gives the developer the opportunity to prevent these kind of defects early on so that bugs don't end up in the code repository or cause any dynamic tests to fail because a failed dynamic test does not tell you anything about the cause of the problem. It can take hours of debugging for the developers or even the integrators who didn't write the code.

All right. I can see that you agree with me that static code analysis can be quite helpful to detect these kind of defects. So why are you using Polyspace now and not one of the many other static code analysis tools? And even compilers can usually find a lot of interesting defects. And beyond this, Polyspace use a technology which is based on formal methods. This allows complete analysis of all of possibilities and value ranges through your entire code. Even unknown code like libraries can be considered, for example in the form of worst case analysis.

And the method Polyspace use is called abstract interpretation. Polyspace offers you this in the form of two tools. One is mathematical sound or mathematical proof. It's called Polyspace Code Prover. And the other one is a non-sound but very fast and precise tool. It's called Polyspace Bug Finder.

So you can apply Polyspace to handwritten and automatically generated code. The tools supports you the languages of C, C++, but also Ada code. And the goal is to find as many runtime errors as possible of course, like division by zero, overflows, array exists out of bounds, this kind of stuff. But also race conditions and so on.

The other part is to find coding guidelines violation like MISRA, CERT-C, CWE. And it also provides you a lot of coding metrics. And of course, last but not least, Polyspace Code Prover makes it possible to prove the correctness of a code, which is of great importance as a proof of quality, especially in supply change. And this is quite unique in its form and ensures that more and more customers choose Polyspace.

So you can say that Polyspace Bug Finder is the tool which checks a lot of different coding metrics like cyclomatic complexity, but also stack usage, project, file, and function metrics, and the whole metrics of HIS, but also coding standards and cybersecurity guidelines are included like MISRA-C, C++, but also custom rules and AUTOSAR C++ 14 and CERT-C of course, which is a very popular security guideline. And of course hundreds of defects and vulnerabilities from the areas of numerical issues, static memory issues, also security defects, concurrency issues, and good practice issues, with the goal to write a high quality, secure, and compliant code which has significantly less defects and vulnerabilities and meets the requirements of functional safety and cybersecurity standards.

Furthermore, the Code Prover can be applied to special categories of bugs as a complement to the Bug Finder for proof of absence of runtime errors, for instance. This serves to create fully trusted components that are reliable, robust, and secure and meet additional requirements of the standards.

All right, so let's summarize this chapter. Why you should use Polyspace for static code analysis. So with Polyspace, you have a tool which is fast and reliable and provides the capabilities to directly eliminate bugs and security vulnerabilities during writing your code. You can prove the compliance to coding standards and different code metrics. A unique selling point is the possibility to prove the absence of runtime errors and use software quality objectives to define a certain quality threshold and see if you achieve it. Of course, all this helps you to meet the requirements of various safety and security standards like DO-178, but also ISO 26262 or the more generic IEC 61508 standard.

So now you know why static code analysis is important and why Polyspace is a very good choice for it. But actually today, we want to talk about DevOps and continuous integration. To do this, we first have to deal with the different requirements for the integration of static code analysis in the company itself. There are, in the first place, the developers of course. They want fast results, few barriers, and easy application, actionable results, and so on to make their programming efforts more easier.

Furthermore, there is the project itself. This must comply with regulations, certain standards, and customer requirements. And of course the costs also play a role here, as well as deadlines and deliveries that must be in the same way in line as the scope and the quality. In addition, there is the team, perhaps even the whole company in the broader sense. And this team would like to work together and agree on a working method. The objective of the team is really to automate things if possible and avoid additional work and of course to integrate tools into their working environments.

So this has long been the focus of the continuous integration concept. The developers write code and check in to the central repository, and I strongly suspect that most of you are doing that, in a at least similar way. The code is then automatically checked out and built, tested, and deployed by a central continuous integration tool. This may happen every time a change is made or overnight, but it will happen regularly and automatically.

If something fails, the development team is informed, and the error can be found and fixed. While continuous integration is already widely used and accepted, another concept plays a key role in DevOps workflows as well, and this is the concept of left shift. So for instance, do you have your software tested by your customers? Yes, of course not hopefully.

But when then? So during the test stage? Yeah, maybe that's too late because errors are difficult to trace back to the developers. Well let's say you test during the build stage. Yeah, that's even better. Yeah, or maybe during coding. So the earlier errors are found, the easier it is to fix them and the lower the cost of these errors. Therefore, we try to implement this concept in DevOps workflows.

Let's say if you have a noninitialized local variable, you can quick test on random behavior. That means on Mondays, your tests will pass, and on Tuesdays, they may fail just because of a very simple to detect issue. So what does DevOps actually mean? Because there are a lot of different definitions. And you can also find DevSecOps, which actually integrate security into the activities you like to, let's say, left shift and automate in your workflows.

But to summarize it, I think DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production while ensuring high quality. So that includes testing, static code analysis, but also security analysis of course.

You can find in this definition two major objectives. One is to reduce the time, and the other is to ensure a high quality. But rather to the entire workflow, we are test deployment and operation. And this means that interfaces and workflows must be considered here rather than in the classic approach. And continuous integration does not compete with DevOps for sure, but it's a necessary part of it.

A final look at the various requirements make it clear that DevOps represent these requirements pretty well. Teamwork is highly appreciated, and the individual steps are optimized. And this reduce frustration in the team and brings an economic advantage to the whole company. All right, so we can also make a check on DevOps.

But what about the integration of Polyspace? Is Polyspace the solution for DevOps? No, certainly not. Static code analysis must provide interfaces to be integrated into the DevOps workflows like all the many other tools in the chain and therefore must support the requirements of the different roles before.

To make this happen, Polyspace has made a change from a desktop tool to a continuous integration and team collaboration tool with the version of 2019a. So you can still use the desktop tool, which combines analysis engine and review tool in one interface, especially for the mobile use on a laptop. And furthermore, we have separated the analysis engine from the review of the results at many customer's requests.

So the analysis can now be performed with the tool Polyspace Bug Finder server and Polyspace Code Prover server on a verification server or continuous integration system. You can also deploy it on the Cloud, and of course there is no graphical user interface because it's just an analysis engine. And for the review of the results, the entire team can now use a web browser interface-based solution without the need to install any application. So the product for this is called Polyspace Access and Polyspace Code Prover Access. So also ticketing systems like Jira and so on can be connected.

To illustrate the different Polyspace deployment levels, I like to, in the following slides, a kind of a table, which compares the different expansion stages. So we have already talked a lot about the desktop installation, which is described here as an individual and ad hoc use. So this option offers the greatest freedom for the individual, but also a lot of responsibility to perform individual steps manually and to keep it consistent.

With this sporadic use, problems can of course be overseen or working with a team is quite difficult. But for individuals, you have a lot of flexibility on your local desk. So there are different ways how to use this tool on your local desk. Of course, you can use the Polyspace desktop application, you can use a command line, and also the eclipse integration. The desktop application provides you all of the possibilities for the creation and configuration of your projects, as well as the result review in one desktop application.

In the following section, we will take a deeper look at how Polyspace can be integrated into continuous integration workflows. The advantages are to use the possibilities of automation and a central consistent configuration. Manual workflows always have the disadvantage that the configuration on different workstations can differ. So continuous integration can solve this consistency problem. And this provides a more reliable quality metric than we would get from an individual work or individual use at the personal desktops.

The connection of the team members and other processes is also much easier. And the frequency of the analysis can be increased with the integration into automation tools. Here's an example how Polyspace server and Polyspace Access products can be integrated into a continuous integration environment. So developers work on their code in their private workspace, and when they reach a logical point, they commit their code into the source code repository. Build and automation tools such as Jenkins are watching for the check-ins. And when a check-in happen, they check out the source code and build the software.

After a successful build, the automation tools then kickoff the Polyspace server products to run the analysis and the verification on the integrated builds. And after the analysis and the verification is complete, the Polyspace results are published to Polyspace Access products, allowing the team members to login in their web browsers and to triage the results and to resolve the bugs.

Polyspace provides a plugin for Jenkins, which is a widely used continuous integration tool that makes it easy to create scripts for analyzing and uploading results. But Polyspace also works equally well in other continuous integration systems because it's basically using the command line API of Polyspace server.

For automation, you need Polyspace server products, Polyspace Bug Finder server and Polyspace Code Prover server. The server products are static analysis and verification engines that are designed to run on server machines. You can easily integrate them into software development processes such as continuous integration using scripts and plugins for automation tools such as Jenkins. After the analysis and the verification is complete, you can automatically assign results to component owners, send email notifications to the owners, and upload results to Polyspace Bug Finder and Code Prover Access.

The process of automation basically consists of four steps, the check out of the artifacts from the source code repository, the determination of build information to match the Polyspace verification to the project sources, include folders and defines for instance, and this is followed by the third step, the actual analysis of the source code with the static code analysis engine and the subsequent and fourth step, which is uploading of the results to Polyspace Access for the generation of reports for further use.

Here you can see the integration of Polyspace into Jenkins in form of a pipeline project. So you see the different steps starting from the preparation, which basically includes all of the environment variable settings. The second step is actually the check out of your source codes and additional artifacts like Polyspace project configurations. The third step is, as we explained, to build your codes and extract the information about source codes or source code files, include folders and preprocessor defines. Polyspace provides you a binary, or a tool, to do that.

And this kind of information will be used from the third step, which is actually the analysis step, running the Polyspace Bug Finder server with this kind of information extracted from the last step. And we get the final results of Polyspace, the analysis results, which then can be uploaded in the next step to a tool or dashboard like Polyspace Access. So now we upload this result to Polyspace Access and make it available for the team for further review, source code annotations.

So if the team will do that, we can also download the results from Polyspace Access and create some reports out of that. For instance, we can create quality reports and define further activities like for instance, sending notifications to owners, project managers, or quality managers. So pipeline projects, what we have seen in the last slide, is something provided by Jenkins. You can visualize the different steps much more, and the scripts are also reusable because they are based on a script. You can check it in your subversion as well, redo these server settings after some years. You have all of the settings you need to do that basically.

Often the question arise on which computer Polyspace should actually run and how several analysis from different projects, for instance, can be parallelized. And most continuous integration systems offer a mechanism to control processes on another computer via SSH for instance. With Jenkins, this is called master agent and this is a comfortable solution to control any number of Polyspace installations on any number of different computers.

So the Polyspace does not need to be installed on the Jenkins master. It can be installed on several other machines, which then runs your project code, builds your project code, verify your project code. And the Jenkins master determines which computer is currently free and runs the analysis job from its queue on this machine. So you don't need to worry about the load balancing anymore. If required, so we can provide you with further information material on this subject.

Another part of the continuous integration workflow is the provision of analysis results to the developers. And this is often done by exporting the results to Excel lists and other code review tools. However, this always has the consequence that information is withheld from the developers. So this may be information about the context, the root course, certain value ranges, or simply access to help to understand what's the message actually says. For this reason, I always recommend to use Polyspace Access as a review tool for Polyspace results. The Excel and type-separated results are very well suited for automatic analysis of the number of findings or similar things and automation of the process itself, but it's not ideal for reviewing the results by the developers.

Polyspace Access provides a web-based graphical front end in your browser and have three main advantages. The first one, developers, managers, and quality engineers can triage, assign, and resolve Polyspace findings. The second is managers, team leaders can use Polyspace Access dashboard to monitor project quality and to drill down, to investigate about problematic files and software units and results. And the last one is that quality and development leads can track the progress of projects against standouts like MISRA and CERT-C.

You can use Polyspace Access in your local web browser by log in with your user name. In the project browser, you can see all the projects you have access to. And the administrator can manage the rights for each individual user. The project overview provides you with various links that allows you to quickly access pre-filtered results, and the results are displayed in a filtered list just like in the desktop application. And you can now click through the findings and find more information about the defects and the code in the source code section.

New in Access is the ability to assign defects to a user. This makes it easier to handle larger projects in a team, so the assignment can be done with the embedded Polyspace Access ticketing system or an existing ticket system like Jira. Managers and team leaders responsible for project quality can now track code quality metrics, and especially their trends, to ensure their projects will meet the quality expectations and goals. Polyspace Access products provides you with dashboards that shows key code information, metrics, suggest lines of code, recursions, cyclomatic complexity, but also software quality objectives we will explain later on.

Polyspace dashboards also allows you to drill down to specific projects files and defects. Project team members can log into the Polyspace Bug Finder or Code Prover Access, that front end, and can easily navigate to see the list of defects found in the result view tab and view results directly in the source code and their source view window, but also set the status severity and assign findings to the team members in the result detail window.

Let's say Quinn is a quality engineer, and she's responsible for triaging software defects. So she got an email notification indicating two new findings have been found in her project, and she clicks on the link in the email to view the new findings in Polyspace Web UI. The result list shows the two defects that are in Dara's code. So she opens two Jira tickets and assigns them to Dara.

Dara is a software developer, and she is responsible for writing code and fixing the defects. So she opens the first Jira ticket and clicks on the Polyspace Access link. She used the information provided in the tool, so the result details and contextual help, to formulate a fix for the defects. She fixes the defects in her programming IDE and checks in the changes.

Doug is a project manager, and he's responsible for software quality of the whole project. So he use a web-browser dashboard to monitor the overall 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 to standards like MISRA and CERT-C. But the question is how he can do that.

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.

But 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, there are many intermediate steps. Here are some examples. The software quality objectives are therefore divided into different stages from 1 to 6 in which the scope and the sharpness of the requirements are constantly increasing.

Software quality objectives can be easily defined and tracked in 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 via 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 6 to the value of 6. That means for all the higher levels, this level will be also applied. And you can do this for coding guideline violations for the defect itself. You can opt in, opt out different checks for the software quality levels and therefore define your own software quality thresholds depending on your project needs.

With a continuous integration system like Jenkins, you can now use the programmatic API from Polyspace Access to determine whether a particular project has reached the required quality level. Now you can see this here in my Jenkins pipeline and check SQO level or check SQO stage that I let this stage fail with a warning of software quality level 3 failed. Or if the desired quality level has achieved, the verification appears as green or passed, and you can directly see in Jenkins that your job is OK according to the project's defined quality levels.

Finally, I would like to list a few important questions that still needs to be considered in such a tool integration. And you should have this in mind if you start with integrating Polyspace in your continuous integration workflows. The first thing is how should the analysis be automated? So that means which tool are involved? What kind of workflows you have in place or you would like to established? The next thing is who is responsible for the configuration of the automation jobs, since this is an explicit task for a certain role, a certain person inside of your team? The third is how are the configurations and results versionized? What kind of artifacts you like to create, what are required for your Polyspace run, what is the output of your Polyspace run, what you like to do with that?

And the next is how often and quickly the project shall be analyzed and in which scope. Now you can analyze on unit level. You can also analyze on full integration level. And this needs to be identified in a certain kind of test plan you have in place to start with your continuous integration automation. Then who get the results and in what kind of format? You want to provide results to developers, QA, project managers. And who is responsible for the review? Who is responsible for other actions depending on the results coming from your Polyspace analysis results?

Are there dependencies to other processes? So if you have issue tracking in place you like to adopt or if you have other systems in place who are dependent on the output of Polyspace Access. Then, last but not least, which analysis objectives are being followed? What we've seen with the software quality objectives for instance. Or are there any other quality metrics you like to implement?

Now we have talked in detail about ad hoc and individual use, as well as automated and collaborative use, but a DevOps integration can go much, much further. However, these are often very individual versions and adaptations to a workflow, which cannot be fully discussed here. This includes, for instance, gated commits, integration into development environments, various connections to other tools and business processes. For instance, reporting in general. Of course this allows further individual requirements to be met and the DevOps integration to be further optimized.

One example is in the gated commit as 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 a gated commit by submitting the codes into a kind of a branch. And this branch will be analyzed by a continuous integration tool like Polyspace, in combination with some manual reviews by other colleagues. And if the code changes meet the quality criterias, 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.

So as I said, the possibilities here are quite large, and we already have a lot of experience with customers in implementation of this individual versions. I prepared a quite short list of a few points that often plays a role here. For instance, which third party tool or processes needs to be integrated? What are your specific needs? And how can left shift be optimized?

How can developers be supported in their programming IDE as early as possible? Or how can the analysis be made even faster and more focused on the specific project needs? Another point is in which cycles the results are needed and on which scope? Which tool will be used? And some other objectives.

So now we have learned a lot about Polyspace and the integration into DevOps, DevSecOps, and continuous integration workflows. The question now is probably what's next and how you can start. So let's quickly summarize what you can do with Polyspace and what we discussed in this webinar.

We discussed how you can maintain a high quality code and addressing bugs much earlier. We also spoke about how to comply with industry standards, checking coding guidelines like MISRA, CERT-C, but also achieving credits to cybersecurity guidelines or functional safety guidelines.

We also discussed how to prove yourself and others that you can rely on your software quality, but also how to integrate Polyspace in your continuous integration and DevOps workflows. We also discussed about how to achieve consistency in your software quality analysis by integrating the tools in an automated way. And we discussed how to establish a result review workflow within larger teams using Polyspace Access.

Quite on the end, we also discussed about checking software quality in different stages with software quality objectives and the way how to implement that in Polyspace Access, but also how to connect your own business logic by exporting results from these different stages. Finally, you can also create reports for authorities to show your results and review processes.

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 avoid unnecessary errors when using the tools.

Last but not least, you can also discuss larger projects and individual adjustments with our consulting departments. So please feel free to visit www.polyspace.com. There you will find further informations about the product and contact information from our team. Thank you very much for your attention. I hope it was informative for you, and I would be very happy to hear from you again. As I said, please feel free to stay with me when I respond to your technical or overall questions, and I will take a little time to sort through all of the questions arriving until now. So please give me one or two minutes. Thank you very much.