}w!"#$%&'()+,-./012345<ya

(1)

MASARYKUNIVERSITY

FACULTY OFINFORMATICS

}w !"#$%&'()+,-./012345<yA|

Integrating Static Code Analysis and

Defect Tracking

MASTERTHESIS

Jakub Papcun

(2)

(3)

(4)

Declaration

Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

(5)

Acknowledgements

I would like to thank my supervisor, Barbora Bühnová, for providing valuable feedback and guidance.

I would also like to thank Ronny Kolb, for his patient guidance and all the advice he gave me during whole work on the thesis.

Last but not least I would like to thank all members of ACT team in Honeywell ACS in Brno for all their help and inputs to my thesis.

(6)

Abstract

Static code analysis is a powerful way of improving the quality of source code. Using tools such as Klocwork, issues in source code can be automatically detected. Some of those issues represent defects injected during implementation activities or even during earlier develop-ment phases. These issues should be properly tracked and analyzed.

The present thesis investigates on how to best integrate static code analysis and defect tracking with the goal of using static code analysis data for project tracking and continuous improvement of the development process used by teams in Honeywell ACS. The thesis in-cludes the analysis of the state-of-the-art and state-of-the-practice regarding defect tracking from static code analysis tools.

Based on the analysis features integrating Klocwork and Atlassian JIRA are implemented in the form of Atlassian JIRA plug-in. The implemented features are evaluated and future work on improvements and upgrades is proposed.

(7)

Keywords

(8)

Introduction

1.1 Context

Honeywell is an international company that invents and manufactures a wide range of prod-ucts and technologies. It employs over 130 000 employees in North and South America, Africa, Europe, Asia and Australia. The company is divided into four strategic business groups (SBGs).

• Aerospace

• Automation and Control Solutions (ACS) • Performance Materials and Technologies (PMT) • Transportation Systems (TS)

Honeywell aims at implementation of Capability Maturity Model Integration (CMMI) level 5, described in more detail in Section 2.5, which requires putting a process compliant with CMMI into action across Honeywell ACS. As Section 2.5 describes, the goal of CMMI level 5 is continuous improvement of the processes and evaluation of the results across all the software development disciplines according to collected measurements and metrics.

The work on the thesis was conducted in the ACS Center of Technologies (ACT). ACT is responsible, among others, for driving excellence across Honeywell ACS. The support and the deployment of ACS Software Development Process (ASDP) described in detail in Section 3.1 is defined as one of its responsibilities. ACT’s role also includes developing best practices, coaching and mentoring of other teams across Honeywell ACS. Further, ACT sup-ports tools recommended for software development activities. Development of extensions for these tools is one of the major activities of ACT in Brno.

1.2 Goals

The goal of this thesis is to find a way to decrease the development cycle time by integrat-ing some of the tools used for software development across Honeywell ACS, specifically Klocwork Insight (Klocwork) and Atlassian JIRA. This integration should help the develop-ers save time during their development activities as well as code quality of their developed software products.

(11)

1.3. THESIS STRUCTURE The outcome of this thesis should be a set of features integrating Klocwork with JIRA in the form of a plug-in for Atlassian JIRA.

1.3 Thesis Structure

The thesis is further divided into the following seven chapters.

Chapter 2 State of the Artprovides an overview of Code Quality as an important part of software development and ways to ensure high quality of the code of a product. It also de-scribes Defect Tracking and existing solutions of Static Code Analysis and Defect Tracking integration.

Chapter 3 State of the Practicedescribes the use of Static Code Analysis and Defect Track-ing within Honeywell ACS. It discusses possibilities of the integration of the two activities and introduces ideas for the implementation of new features for future use by teams across Honeywell ACS.

Chapter 4 Feasibility Analysis discusses the possibility of the integration between Kloc-work and JIRA, capabilities of both tools, draws conclusions, and creates solutions for issues the integration would have to deal with during the implementation.

Chapter 5 Implementationdeals with the implementation itself. It describes each imple-mented feature, open issues the features still deal with due to various factors, and the re-sulting products of the implementation.

Chapter 6 Evaluationdescribes the methodology of evaluating the results of this thesis and results gathered from users that evaluated the implemented features on their own project.

Chapter 7 Future Worksuggests feature improvements, upgrades, and ideas for new fea-tures to be implemented as part of the integration.

Chapter 8 Conclusion evaluates the goals fulfillment and summarizes the outputs of the thesis.

(12)

Chapter 2

State of the Art

This chapter introduces code quality and the ways of code quality assurance such as Man-ual Code Review, Dynamic Code Analysis and Static Code Analysis. It describes Defect Tracking, another established part of software development and discusses possibilities of integration of Static Code Analysis and Defect Tracking.

2.1 Code Quality

According to ISO/IEC 9126 specification, quality of the software depends on several char-acteristics [1] such as

• functionality — capability of the software to provide functions which meet stated needs when the software is used under stated conditions,

• reliability— capability of software product to maintain a specified level of perfor-mance when used under specified conditions,

• usability— the capability of the software product to be understood, learned, used and attractive to the user, when used under specified conditions,

• efficiency— the capability of the software product to provide appropriate perfor-mance, relative to amount of resources used, under stated conditions,

• maintainability— the capability of the software product to be understood, learned, used and attractive to the user, when used under specified conditions,

• portability— the capability of the software product to be transferred from one envi-ronment to another.

Some quality attributes, such as maintainability or usability are easy to assess by using the program, reading the code or evaluating personal feelings. However depersonalization from one’s written code is often difficult. Several methods for exploiting hypothetical and real errors caused by faulty code were created. Some of these methods provide different but still personal point of view, some of them provide completely depersonalized point of view.

(13)

2.1. CODE QUALITY

2.1.1 Manual Code Review

One of the easiest code verification techniques in terms of technology, although time con-suming, is Manual Code Review. The essence of this kind of review is cooperation of skilled developers on reviewing code changes done by different developer. Reaching higher prob-ability of finding vulnerabilities in the code requires expert developer skilled at reading the code and easy understanding it as well as someone knowledgeable about the design and the architecture of the reviewed code. This brings new point of view at the author’s code.

There are several ways to execute Manual Code Review [2],[3].

• Formal inspections— heavy-process review with three to six participants meeting together and discussing the code.

• Team review— less formal form of Formal inspection. Some of the inspection stages are omitted and some of the participant roles may be combined.

• Over-the-shoulder reviews— a developer standing over the author’s workstation while the author walks the reviewer through a set of code changes.

• E-mail pass-around reviews— all the changes are packed and sent to reviewers via email, reviewers discuss changes and suggest fixes either before committing code to repository or after that.

• Pair programming— two developers work on the same program at the same time at single workstation. They continuously review their code. This lacks the perspective of someone who does not participate in this particular coding activity.

• Tool-assisted reviews— reviews where specialized tools for all aspects of the review are used.

Manual Code Review usually results in less false positives in comparison to static code analysis as the reviewer usually has better understanding of overall design and architecture [4]. Reviewer is able to evaluate overall quality of the code like readability or use of code conventions for the specific programming language.

2.1.2 Static Code Analysis

The goal of Static Code Analysis varies from tool to tool. Some of the most demanded ways of Static Code analysis are [5]

• type checking— checks for correct assignment of types of objects, • style checking— checks the style of the code and its formatting,

• program understanding— helps users make sense of large codebase and may in-clude refactoring capabilities,

(14)

2.1. CODE QUALITY • program verification and property checking— attempts to prove that the code

cor-rectly implements the specification of the program,

• bug finding— looks for places in the code where program may behave in a different way from the way intended by developer,

• security review— most modern security review tools are hybrids between property checkers and bug finders.

The analysis works automatically and does not require the developer looking into the code during an analysis stage. As the name of analysis suggests it is executed on the code without compiling and executing the program behind the analyzed code itself. The opposite of this method is Dynamic Code Analysis which executes the program to do the analysis of the the source code.

The main idea behind Static Code Analysis is to overcome limitations of human mind. Even the best developers very often do the same mistakes in the process of coding, either because of a tight time schedule or carelessness. Therefore it is reasonable to check for such errors as often as possible and avoid having them in the code for a long time.

Static code analysis started with a program called Lint, a tool for static analysis of source code for C language in 1978. Since then many other tools for analysis of source code were created. The market offers tools for many different languages including C++, Java, C# or even PHP and JavaScript.

The main advantages Static Analysis brings developers these days is ability to avoid in-jecting code errors into a production environment even before manual testing and creating executable program. As Static Analysis requires only the code itself the developers can an-alyze and fix errors while coding (at the end of the main coding activity). Errors resulting in null pointers or possible memory leaks are amongst the most frequent errors found by such tools. Some of more advanced analyzers include also measures like number of lines or functions and metrics like cyclomatic complexity for tracing the quality of the code.

2.1.3 Dynamic Code Analysis

The primary goal of Dynamic Code Analysis is identification of potential software errors not found by Static Code Analysis or with traditional testing methods used in Quality As-surance such as automated or manual testing.

Dynamic Code Analysis is based on an execution of the software and analysis of its output. This method of analysis is dependent on the input test data and requires well formed and thought out input in order for the analysis to work effectively.

There are various functionalities which tools for Dynamic Code Analysis implement [6]. • Execution trace

• Call stack

(15)

2.2. STATIC CODE ANALYSIS • Cycle counts etc.

Well known dynamic code analysis tools include [6] • Rational Purify (IBM)

• Valgrind (open source used — for C/C++) • DevPartner

• Insure++

Honeywell’s ASDP (ACS Software Development Process) includes Dynamic Code Anal-ysis for securing code quality. However it is not mandated by the latest version of the process and thus not performed by engineering teams.

2.2 Static Code Analysis

In today’s world where software often deals with very delicate information, security is one of the most important issues software developers have to have in mind when creating it. This fact led to developing various ways for securing the software. One of those ways is Static Code Analysis.

Bola Rotibi summarizes in his paper The Business Value of Software Static Analysis three threats and impacts of code quality level on business relations and success of a project [7].

1. Many organizations do not try to engage code analysis tools to decrease the develop-ment time, deliver more with less quality. Subsequent failures may result in customer frustration, high cost fixing or loss of trust and the customer.

2. With advances in technologies in the last years, software products became complex and prone to more defects. Users’ expectations and requirements are getting higher which requires higher software quality delivered. Organizations try to attract these customers promising more than they are able to deliver.

3. Early identification and removal of software defects helps in the decrease of finan-cial costs for development and further maintenance and fixing software product, software quality and subsequently customer satisfaction.

As it was already stated in Section 2.1.2 Static Code Analysis is the analysis of the code without executing the program itself. This means no need for testing data that would go through the code.

Static Code Analyzers typically contain several parts such as a parser, an internal repre-sentation, an analysis engine, etc. The analyzers have a lot in common with typical compilers especially when parsing the code. They execute a number of steps when analyzing the code [8].

(16)

2.2. STATIC CODE ANALYSIS • Lexical Analysis— transformation of the code into a series of tokens while getting

rid of unimportant parts of the code such as white spaces or comments.

• Parsing— parser uses CFG (Context Free Language) to match the token stream. It performs derivation by matching the token stream against the production rules. • Abstract Syntax— creation of Abstract Syntax Tree (AST). AST provides a

standard-ized version of the program which is more suitable for later analysis.

• Semantic Analysis— symbol resolution and type checking (common with compil-ers and important for object oriented languages).

• Tracking Control Flow — means for increasing efficiency of static analysis algo-rithms build on top of AST. The Control Flow consists of

– nodes — sequences of instructions that will always be executed,

– edges — directed and represent potential control flow paths between nodes,

– back edges — represent potential loops.

• Tracking Dataflow — examination of the way the data move through a program. This usually involves traversing a function’s control flow graph and noting where the data is generated and where it is used.

• Taint Propagation — using dataflow to determine what an attacker can control. Requires knowing where the information enters the program and how it moves through it. This helps identifying many input validation and representation defects. • Pointer Analysis— the purpose is to understand which pointers could possibly refer

to the same location.

Static Analysis requires various checkers according to which the code is matched and the errors are found. A checker is a kind of a rule by which the analyzer is able to determine if some number of lines of the code contains any error.

There exist tens of checkers applicable for any project across most of the programming languages and many more specific for one or some little number of programming languages. Some of well known checkers include

• array index out of bounds, • unreachable code,

• calling method on null object, • memory leaks,

(17)

2.2. STATIC CODE ANALYSIS c l a s s A{ void foo ( ) ; } void A : : foo ( ) { i n t ∗ p t r = new i n t; ∗ p t r = 2 5 ; p t r = new i n t; ∗ p t r = 3 5 ; } /∗ Klocwork c r e a t e s a d e f e c t r e p o r t l i k e t h e f o l l o w i n g :

∗ mlk . must . c c : 8 : E r r o r : Memory l e a k . Dynamic memory s t o r e d i n ’ p t r ’ a l l o c a t e d ∗ through f u n c t i o n ’new ’ a t l i n e 6 i s l o s t a t l i n e 8

∗/

Example 2.2.1: Memory Leak

s t a t i c ovid check (i n t a r r [ ] ) { i f( a r r ! = n u l l & a r r . l e n g t h ! = 0 ) { foo ( ) ; } r e t u r n; } /∗ Klocwork c r e a t e s a d e f e c t r e p o r t l i k e t h e f o l l o w i n g :

∗ JD . BITCMP i s r e p o r t e d f o r l i n e 2 : Q u e s t i o n a b l e use o f b i t o p e r a t i o n ’& ’ ∗ i n e x p r e s s i o n . Did you mean ’&& ’?

∗/

Example 2.2.2: Suspect use of bitwise operator instead of logical one

Static Code Analysis however identifies only “shallow” errors and does not look for problems in design or functionality of the code. It also does not detect and correctly identify all source code errors. It allows us to argue that the code is as follows [9]:

• As compliant with the software requirements as present evaluation methods and technology allows.

• The coding errors have been minimized. Static analysis does not prove that the re-quirements the code was developed from were correct or show that the compiled code is correct.

Static Code Analysis can return three types of results.

• True positives— real issues which are code errors and should be fixed before releas-ing the product.

• False negatives — real issues which Static Code Analysis did not identify and are still hidden from the knowledge of the developers.

(18)

2.3. DEFECT TRACKING s w i t ch( k ) { c a s e 1 : b = 2 ; break; c a s e 2 : b = 3 ; /∗ F a l l Through∗/ c a s e 3 : a = 4 ; break; d e f a u l t: e r r o r ( ) ; } c = b ;

Example 2.2.3: Uninitialized variable

• False positives — issues identified by the analysis but not real threats due to for example architecture of the software.

One of disadvantages of Static Code Analysis is its inability to understand the archi-tecture and the context of the software. This often results in False Positives which have to be confirmed by the developer. Example 2.2.4 shows code where Klocwork finding was re-ported: The ’doStopWatching’ method throws a generic exception ’java.lang.Exception’. As the code was created this way by design, it is a False Positive.

p u b l i c S t r i n g doStopWatching ( ) throws E x c e p t i o n {

r e t u r n STOP_WATCHING_CONFIRM_KEY ;

}

Example 2.2.4: False Positive

2.3 Defect Tracking

Defect tracking is one of the basic parts of software development. Tracking of issues, de-fects, new features or any other types of issues, is important for various reasons. Being able to trace issues, gather data about them, analyze and process these data can give managers, developers and other team members an overview of the project, development progress and quality of software that is being developed. It helps to organize the team and decrease de-velopment cycle time as well as to decrease the probability of mistakes in understanding the problems.

Tracking of defects (or bugs in other terminology) provides an opportunity to evaluate quality of software and the maturity of the team in the development process.

Issue tracking is a standard part of software development. There is a big number of issue tracking systems on the market. From proprietary systems created only for a selected company through paid commercial products to free and open source solutions each having different level of functionality. Examples of defect tracking tools are

(19)

2.4. DEFECT TRACKING OF STATIC CODE ANALYSIS FINDINGS • Bugzilla by Mozilla Foundation (an open source project),

• BugAware and others.

2.4 Defect Tracking of Static Code Analysis findings

Static Code Analysis findings are usually separated from Issue Tracking in the development process. Developers usually do not see any point in duplicating the data from different sys-tems if they only want to fix the issues. This however also means inability to connect the data from these systems and create more interesting measurements and metrics for identify-ing the status of the project. There have been tendencies to connect the two parts of software development in some way such as manual evaluation of Static Code Analysis findings, di-viding them into categories, assigning them priorities and working with them similarly to what David Morgenthaler and John Penix were trying to conduct in Google1. This is how-ever lengthy and complex process.

A more automated way of integration was created between Kiuwan, a cloud based Static Code Analysis tool developed by Optimyth Software and Atlassian JIRA2. The integration is able to create JIRA issues according to the Static Code Analysis findings which were first analyzed and selected into an action plan, a feature implemented inside Kiuwan. This au-tomation however only resides in the possibility to bulk create JIRA issues from the Static Code Analysis tool. The thesis should go further and bring more functionality. Section 3.5 will describe this functionality.

2.5 CMMI

CMMI models are collections of best practices that help organizations to improve their pro-cesses [10]. These best practices describe the best way of development from the beginning of the development cycle to its end. CMMI introduces levels which describe an evolutionary path which is recommended for organizations that aim at improving and optimizing their development activities. The root of CMMI level 5 in development is continuous improve-ment in all the disciplines of software developimprove-ment cycle according to indicators, measure-ments and metrics which are continuously collected. The process is then evaluated accord-ing to these collected data and improved in a right way. Figure 2.1 depicts 5 CMMI Maturity Levels.

1. Using Static Analysis to Find Bugs. (p24) <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp= &arnumber=4602670>

2. Kuiwan integration with Atlassian JIRA <https://www.kiuwan.com/press-release/ kiuwan-integrates-with-jira>

(20)

2.6. CONCLUSION

Figure 2.1: CMMI Maturity Levels

2.6 Conclusion

There are few successful attempts for integration of Static Code Analysis and Defect Track-ing. Automated system integration and data analysis has high potential in several areas. New metrics, increased code quality and increased developers’ willingness to fix code er-rors as well as time reduction of the development process. Research into Static Code Anal-ysis findings found for particular features of programs may even help in predicting future problems and avoid incorrect programming in advance.

(21)

Chapter 3

State of the Practice

Honeywell ACS developed ACS Software Development Process (ASDP) to fulfill Capability Maturity Model Integration (CMMI) level 5. This required implementation of best practices for each of the software development disciplines included in ASDP as well as proposing a use of appropriate tools for gathering and analysis of data for later evaluation and contin-uous improvement of projects across Honeywell ACS. This chapter deals with the Imple-mentation discipline of ASDP, the role of Code Quality and thus Static Code Analysis, Issue Tracking and the role of Static Code Analysis findings in Defect Tracking inside project as well as tools used for achieving the goals of the development.

3.1 ASDP and the UNITY project

ASDP (ACS Software Development Process) is a software development process compliant with CMMI Level 5 implemented within Honeywell ACS. The first version of ASDP was released in January 2010 and is developed by ACT (ACS Centre of Technologies, formerly SoftCo) team.

Many projects within ACS have very different nature, going from projects aimed at hard-ware development through embedded systems to purely softhard-ware development projects. ASDP what to do, not how to do it while ACT creates or uses existing best practices and recommendations for fulfilling ASDP expectations and goals.

The UNITY project is a project with a goal to integrate tools used within ASDP. This project aims to address several issues.

• Decrease in Data Redundancy:Roles of some of the tools overlap and the data that needs to be input into them are the same. The project should remove this redun-dancy by sharing information across different tools without the need to input the information into tools manually by their user.

• Decrease possibility of errors in the data:As the users need to put the same infor-mation into different tools, there is higher probability that they would make mistake in the process.

• Traceability:Different tools for different disciplines may cause the loss of informa-tion which data from one discipline belongs to which data from another.

(22)

3.2. TOOLS The UNITY project includes integration of JIRA and Contour, EA — Contour — ReqPro integration as well as Common User Management and Project Management integration and Confluence Extension Project1. JIRA — Klocwork — Fisheye integration is another step in the development of the UNITY project.

3.2 Tools

ASDP recommends tools for most of the disciplines. Some of them are used in parallel and in each project, use of some of them is not mandatory.

Figure 3.1: ASDP disciplines and ACT recommended tools [11]

3.2.1 JIRA

JIRA is an issue tracking system developed by Atlassian, used for defect tracking as well as project management. JIRA in its latest versions offers users high flexibility of configuration options from an administration point of view.

1. Wiki pages of the UNITY project <https://acswiki.honeywell.com/display/UNITY/Unity+-+ A+United+Tool+Chain+by+ACT>

(23)

3.2. TOOLS • Management of Projects:

– CRUD operations2

– management of Project Roles

– management of Project Versions and Components • Configuration of Issues:

– management of Workflows

– management of Custom fields3

• Custom defined and implemented configuration

JIRA’s main benefits however are not its configuration capabilities but the capability to be very easily and quickly extended. As one of few issue tracking systems JIRA offers devel-opers opportunity to create their own plug-ins extending JIRA’s capabilities which makes both users’ life easier, and drives JIRA to work according to company’s needs and culture. As part of plug-in, developers are able to implement new components such as Custom Field Types4, JQL Function5, Project Tab Panel, Report, Webwork (Web Action definition).6

3.2.2 Klocwork

Klocwork is a company developing two main products – Klocwork Insight (Klocwork) and Klocwork Cahoots.

Klocwork Cahoots is a software development tool for simple Manual Code Review, which can work as an independent review tool or in integration with Klocwork Insight. Honeywell ACS does not use Klocwork Cahoots as ACT recommends Crucible from Atlas-sian for manual code reviews.

Klocwork Insight is a Static Code Analysis tool for identifying security and reliability issues in four languages so far. It supports C, C++, Java, and C#. Klocwork is not only a tool for analysis of the code itself, but implements a wide range of metrics valuable for software developers for assessing current quality of their source code.

As Static Code Analysis is the best practice and activity recommended by ACT, Klocwork is the tool used for the activity inside Honeywell ACS. It houses nearly 400 projects across whole ACS with thousands of Klocwork issues detected across all the projects.

Klocwork is configurable in various ways offering setup of different components which serve as means for analysis or reporting.

2. (C)reate, (R)trieve, (U)pdate, (D)elete operations

3. Custom Fields description <https://confluence.atlassian.com/display/JIRA/Adding+a+ Custom+Field>

4. Custom defined field types implemented as part of JIRA plug-in 5. Function used in JIRA defined query language for searching JIRA issues

6. JIRA Plugin Module Types <https://developer.atlassian.com/display/JIRADEV/JIRA+ Plugin+Module+Types>

(24)

3.2. TOOLS • Taxonomies — an organizational structure for analysis results. Taxonomies allow the user to view the results of their build analysis in wide range of ways. By default, there are three taxonomies: C/C++, Java, and C#. Each taxonomy contains multiple categories, and each category contains multiple issue types. A Klocwork administra-tor can create taxonomies, each with a distinct set of checkers, to match an organi-zation’s reporting needs. Any particular checker can appear in multiple taxonomies [12].

• Checkers— rules used for comparison of the source code with a goal to find code errors or vulnerabilities defined in these checker. These are part of Taxonomies. • Metrics— a value which is calculated/derived from one or more measures usually

by a formula.

Klocwork users often deal with confusion between two Klocwork finding fields with very similar name but different meaning.

• Status— indicates how the issue should be handled. The status is set by the devel-oper analyzing Klocwork finding.

– Analyze:Initial status for each newly created finding.

– Ignore:Set for finding which is to be ignored and left unfixed.

– Not a Problem: Other name for false positive. As Klocwork cannot fully un-derstand the context of the application it can happen that Klocwork reports an issue that is not really a threat or the issue is intended.

– Fix:Valid finding which should be fixed as soon as possible.

– Fix in Next Release:An issue without big impact on the functionality or secu-rity which can be postponed to later time.

– Fix in Later Release:Issue with no impact on the functionality or security which can be postponed for any time in the future.

– Defer:An issue which requires further discussion or analysis.

– Filter:Provided for compatibility with older versions of Klocwork filter files.7 • State — a read only indicator which traces the history of an issue from the time it

was created until the time it was fixed.

– New:Issues detected in the current build.

– Existing:Issues detected in one of the previous builds, but were not fixed yet and are still present in the current build.

– Fixed:Issues that were detected in one of the previous builds, were fixed in the meantime and are not present anymore in the current build.

7. Configuration file which is obsolete from Klocwork v9.5. The file was used to Configure an unsupported C/C++ compiler.

(25)

3.3. CODE QUALITY AND STATIC CODE ANALYSIS

3.2.3 Fisheye

Fisheye is a Source Code Management tool originally created by Cenqua, now being further developed and supported by Atlassian. Fisheye supports several source code repositories such as Subversion, Perforce, CVS, Git and Mercurial. As Subversion is the recommended tool for version control of source code within Honeywell ACS, Fisheye is used with Subver-sion only. Planned Git use will be supported by Stash, another Source Code Management tool by Atlassian.

As an application that does not originate from Atlassian as most of their other prod-ucts, Fisheye was only adapted to work with other Atlassian products and an extension for reporting and manual code review was created under the name Crucible.

3.3 Code Quality and Static Code Analysis

Code Quality and its continuous improvement is an important part of software develop-ment across Honeywell ACS. ASDP deals with code quality by several different approaches. Manual Code Review, Dynamic Code Analysis and Static Code Analysis. Even though Dy-namic Code Analysis is defined as a concept in ASDP, it is not generally used across ACS teams and is not mandated by latest ASDP version 3.6.

Manual Code Review is the best practice recommended as part of software development cycle. Honeywell ACS uses Crucible, a tool for Manual Code Review and advanced report-ing developed as an extension of Fisheye by Atlassian. This tool is defined in ASDP as ACT recommended tool.

Manual Code Review in ASDP aims to [13]

• verify that a code element meets its specifications, • verify that a code element satisfies quality attributes,

• identify refactoring or improvement opportunities that might have been overlooked initially,

• verify that a code element conforms to defined Coding Conventions,

• collect findings into a comprehensive Code Review Record for further appropriate actions.

Static Code Analysis is another way of securing software code quality used in develop-ment process. Honeywell ACT recommends Klocwork as the tool for Static Code Analysis.

Klocwork is an advanced tool for analyzing source code, searching code issues, mea-suring various aspects of the analysis and reporting. Teams across Honeywell ACS request about 15 new projects in Klocwork each month which sums up to almost 400 Klocwork projects to this date.

ACT recommends several approaches and states of development when the developer should execute Static Code Analysis to avoid expensive defect fixing later in time [14].

(26)

3.3. CODE QUALITY AND STATIC CODE ANALYSIS • During the implementation activity— the developer should analyze the code they created or modified on their own working station and fix found code errors before committing any changes to main repository.

• After code integration— the code should be analyzed after the integration of newly created code into the rest of a codebase to find additional anomalies thanks to further overall system availability with additional interprocedural analysis capabilities. • Static analysis after Release— analysis to gather new data and metrics for further

development planning of the following Release as well as offering the feedback to people who work on it.

Klocwork findings are separated into severities by possible impact on the security of the code.

• Critical:Severe errors which can cause crash of the program when failing on this place.

– NullPointerException

– Resources not closed on exit (connection to database)

• Error:Less severe findings however still possible crash of the program or leakage of information to unauthorized users.

– Usage of released resources (files, database connection etc.)

– Security issues (SQL injection, XSS, etc.)

• Warning:Cosmetic errors, code redundancy, unnecessary code.

– Redundancy

– Dead code

• Review: Uncategorized errors with questionable nature whose real impact on the security of the code needs to be determined by the developer.

– Unusual use of language (== vs. equals() etc.)

– Unnecessary operations (always true conditions etc.)

Even though Static Code Analysis is not mandated within Honeywell ACS, it is part of process and is recommended as highly effective practice to increase code quality across the products developed by Honeywell.

The output of Static Code Analysis inside Honeywell ACS is called Static Code Analysis Review. The review displays properly formatted data about [15]

(27)

3.4. DEFECT TRACKING • a reference to the Software Build analyzed,

• a list of anomalies organized by categories such as

– severity,

– component,

– defect type,

– status (analyze, fixed, deferred, not a problem, ignore, etc.).

The report may also contain some information about the trend of detected/resolved anoma-lies over time for consecutive Software Builds and relevant code metrics.

3.4 Defect Tracking

Honeywell ACS gathers many different data about Defects amongst which it also includes “Detection Discipline and Activity”. A reporter of a defect specifies what were the discipline and the actual activity when the defect was identified. It helps to see what part of the devel-opment process is most defective and where members of a team should put more effort in following development.

The Honeywell ACS’s main tool for Issue Tracking is JIRA from Atlassian. The tool found its place inside ACS due to its big extension capabilities. As ASDP is a software development process tailored for the needs of ACS itself the necessity for gathering and processing data specific for the company is high. This necessity is at the moment fulfilled by ACS JIRA Extension project, part of development practices of ACT.

ACS JIRA contains

• over 14 000 users from around the world, • over 2000 projects,

• more than 500 000 issues across the whole ACS where

– over half of the issues are of type “Defect”,

– 739 defects are related to Static Code Analysis,

• integration with various other software development tools. Figure 3.2

ACS JIRA contains broad variety of Reporting capabilities especially due to its extensibil-ity by plug-in. The reporting capabilities allow retrieving any existing data from inside JIRA or other external systems (if the external system has an interface for passing the data), an-alyzing them and visualizing the results in the form of tables, interactive graphs and other. JIRA contains a variety of reports dealing with data about the Defects, either JIRA native reports or reports implemented as part of AJE.

(28)

3.4. DEFECT TRACKING

Figure 3.2: Tools Integration

• Defect Profile Report— See in which disciplines most of the defects in a project are detected and injected.

• Defect Resolution Effectiveness Report— See how effective defect resolution really is and how many defects have to be reopened by testers/reporters as the reported problem was not appropriately fixed.

• Defect Resolution Time Report— See statistics on how long does it take to resolve reported defects.

• Defect Scorecard— See where defects have been detected and originally injected. • Defect Trend Report— See the progress of detecting defects and resolving defects

over the course of the project. Monitoring the percentage of unresolved defects using the Unresolved Defects Index provides an assessment of overall testing and defect resolution progress.

• Detected vs. Resolved Defects Report — Gain insight into the testing and defect fixing activities of a project over a particular period of time. The ideal situation is to timely resolve any created defects as shown by a downward trend for the Unresolved Defects line.

(29)

3.5. DEFECT TRACKING OF STATIC CODE ANALYSIS FINDINGS • Version-Based Defect Leakage Report— See in which version defects were detected

and fixed.

3.5 Defect Tracking of Static Code Analysis Findings

The tracking of Klocwork findings as defects in JIRA is not a common practice within Hon-eywell ACS. This approach is not a part of ASDP definition even though to some extent such functionality is being required by the users of Klocwork and JIRA. At the moment any automated integration between Static Code Analysis and Issue tracking tools is officially nonexistent even though combining the data from both of the systems has high potential for creating overview of the state of project from new point of view. There are several use cases of the integration, one of which has been already required by users for some time.

• Ability to create JIRA Defect from Klocwork finding. With the information about possibility to partially extend some functionality of Klocwork it should be possible to create JIRA Defect remotely from Klocwork finding.

• Mapping Klocwork findings to specific JIRA issues, whose implementation and code creation introduces these Klocwork findings.

• Possibility to control and update Klocwork findings from JIRA which would possi-bly mean centralizing the control of data from the two tools into one of them. • Various reporting capabilities.

Automating the data integration in Honeywell ACS aims to reduce the development cycle time, increase code quality which should be the result of higher Static Code Analysis findings fixing activities and possible ability to predict and avoid code errors while coding.

3.5.1 Proposed Features

Our main focus is creating a JIRA a plug-in that would leverage the integration and put as much functionality inside JIRA as possible.

3.5.1.1 Create JIRA Defect from Klocwork Finding

The first feature is actually requirement from JIRA and Klocwork users. This feature would allow users to create a new JIRA Defect by executing operation from Klocwork Finding view. This will create a JIRA Defect with “Detection Discipline and Activity” set to Implementa-tion – Static Code Analysis value to distinguish this type of Defect from other types.

(30)

3.5. DEFECT TRACKING OF STATIC CODE ANALYSIS FINDINGS 3.5.1.2 List of Klocwork Findings for Specific JIRA Issue

Another feature is the automated generation of a list of Klocwork Findings which were identified after committing code to the repository as part of some specific JIRA Issue. The list will be displayed inside an Issue Tab Panel of JIRA’s View Issue screen. Information displayed will contain short description of Klocwork Finding, its severity, and current status. The feature will furthermore show information about the number of Klocwork Findings of each severity configured for Klocwork, as well as a hint about readiness of feature for further testing activities and deployment of the code to production environment.

The decision about readiness of the feature is non-deterministic. It is not possible to gen-erally decide if the feature for given project is ready for deployment or not. Different types of projects have different requirements for security issues. While projects dealing with rela-tively simple web applications can deal with few Klocwork findings of Warning or Review severity even knowing they were released into production environment, critical ones like power plant systems require perfectly secure code which involves also fixing all Static Code Analysis issues.

Figure 3.3: Issue Tab Panel mockup

3.5.1.3 Version Release Readiness Report

This feature will gather data about a number of Klocwork findings per severity for all Issues in the selected release. The report will contain links to Klocwork displaying list of appropri-ate Klocwork findings. Similarly to previous feature, the report will give the user hint about the version being ready for further manual testing of features and their release to production environment.

(31)

3.5. DEFECT TRACKING OF STATIC CODE ANALYSIS FINDINGS

(32)

Chapter 4

Integration Feasibility Analysis

4.1 Overview

As the topic of the thesis suggests, its goal is to find a way to integrate Static Code Analysis tool with Defect Tracking tool. Section 4.2 however shows that integration between JIRA and Klocwork is very limited due to the functionality offered to the developers by Klocwork. As the result of the feasibility analysis of the Klocwork — JIRA integration shows it is not possible to make use of a lot of functionality valuable for JIRA users across ACS. Thus it is necessary to find another way to use the data retrievable from Klocwork to its fullest potential. The feasibility study of integration between JIRA and Fisheye proves to be one of the ways this thesis can bring more value to the development process.

4.2 Klocwork

When implementing an integration between two different systems, it is necessary to ana-lyze the range of possibilities the systems provide for integration. As Atlassian JIRA and Klocwork are two completely unrelated systems, they do not have any native interface for connecting with each other. There are two approaches available for gathering data from each of the systems, each having its pros and cons.

• Database access • Web services

Knowledge of database schema with access to the database provides possibility to get all the data the system manages. Being dependent on database schema however makes the integration very inflexible especially as neither JIRA nor Klocwork provide their database schemas publicly. It is impossible to fully anticipate the changes in the database schema and thus the integration is very likely to fail.

Both systems however provide WEB APIs. JIRA provides flexible and extensive WEB API which is even more extensible by implementing JIRA plug-in. Klocwork provides less flexible WEB API which allows the users only limited access to the data. WEB APIs are less prone to being radically changed or changed without having public knowledge about it. The implementation will use these WEB APIs to fulfill the integration and build new functionality.

(33)

4.2. KLOCWORK There are two steps that are generally executed when communicating with another sys-tem, Authentication and Retrieving/Updating the data on the external system. It is nec-essary to keep the order of the steps as unauthenticated user is not allowed to retrieve or update any data on any of the two systems.

First of the steps is authentication of the user executing any functionality on the external system. JIRA provides the user with different approaches for authentication.

• Basic Access Authentication:The simplest method for an HTTP user agent to pro-vide user name and password when authenticating.

• OAuth:The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf [16].

• Trusted Applications:Creates trusted way to communicate between the applications not requiring to log into external system again when accessing them.

Figure 4.1: Creating Authentication Token to Klocwork

Klocwork provides only one way of authentication of user accessing the data by WEB API. It uses Authentication Token for authenticating the user through its WEB API. Gener-ating and retrieving the token is executed in two steps as shown in Figure 4.1.

1. Executing kwauth utility, provided by Klocwork Server installation. User login name, password and optionally server URL is required for this step.

2. Extracting authentication token from a file named ltoken, stored in .klocwork folder inside the profile folder of user executing the operation.

• The record in ltoken file has the following form:

– serverUrl;port;userLoginName;authenticationToken

• AuthenticationToken can be extracted from the file and used later in building the REST URL.

(34)

4.3. FISHEYE • The token is presented as value for ltoken attribute in REST call URL.

As the only option to authenticate the user is by the use of external utility on a computer on which Klocwork server is installed it is not possible to make authentication for each in-dividual user logged into JIRA. An account serving for access to Klocwork by all JIRA users is necessary. According to Honeywell policy it is possible to maintain a Technical Account which can get authenticated against Klocwork. The authentication token of the authenti-cated Technical Account will be stored as part of the JIRA plug-in for later use in building the REST URL.

The second step in communicating with an external system is using the system’s func-tionality for our purposes. Table 4.1 lists possible uses of WEB API provided by Klocwork.

Create Retrieve Update Delete Generate Import

Project X X X

Module X X X X

View X X X X

Enabled Defect Types X X

Build X X

Detected Issues X

File Churns Report X

Build Summary Report X

Server Configuration X

Project Import Status X

License Count X

List of Metrics X

Table 4.1: Klocwork WEB API capabilities

Table 4.1 shows that the API provides a variety of functionality for creating, retriev-ing, deleting and updating projects, modules and views. This master thesis however deals mostly with Detected Issues (Klocwork findings) which are the main target for our work. Klocwork restricts us from working with these Klocwork findings to one operation which is retrieving the data.

The API does not allow any modifications to existing Klocwork findings which means, it is not possible to use JIRA as the primary tool to work with findings (e.g. updating the status or commenting) at this time. Proposed features for the integration will only retrieve the data from Klocwork without the possibility to further modify them.

4.3 Fisheye

Fisheye, like JIRA, is a product from Atlassian. Even though JIRA does not provide implicit integration between systems, Fisheye WEB API supports more flexible functions and what

(35)

4.4. CONCLUSION is more important, native authentication mechanism which helps the developer avoid im-plementing their own way of dealing with security issues.

The Fisheye WEB API provides the developers with the following functionality1 • Commit Graph data

– retrieves detailed information about a set of changesets in a repository, designed to be used with the Fisheye commit graph.

• Getting information about changesets and file revisions indexed by Fisheye

– get a list of changesets on a repository,

– get specific changeset from repository,

– get a list of information about files and directories in a path,

– get a specific file revision,

– get a list of the file revisions for a specific path. • List information about the repositories.

• List of changesets from a repository.

• Execute Fisheye queries against a repository,

– execute a Fisheye query against a specific repository,

– list of reviews for a changeset in a given repository,

– list of reviews for each given changeset in a given repository.

4.4 Conclusion

The previously summarized functionality of each system shows that with the right precon-ditions, described for each feature separately, being fulfilled from the part of JIRA users, it is possible to create features which should at the end make the quality of the code and individ-ual features higher and the development time of features reduced. It is possible to aim for creating features which will map Klocwork findings to specific JIRA Issues automatically.

1. Fisheye WEB API <https://docs.atlassian.com/fisheye-crucible/latest/wadl/fisheye. html>

(36)

Chapter 5

Integration Implementation

As Section 1.2, the integration will be implemented as a JIRA plug-in, gathering all necessary data from both Klocwork and Fisheye and process them into more complex and valuable information. The first step of the implementation is to create common functionality and features which will be subsequently used by other features across the JIRA plug-in.

Both JIRA and Klocwork consist of projects, while Fisheye consists of repositories for the code base. At this time, each JIRA project and Klocwork project in Honeywell ACS include the same codebase which is also part of one Fisheye repository. JIRA projects, Klocwork projects and Fisheye repositories are not implicitly mapped by their code bases. This map-ping is the first precondition for further work with the data gathered in JIRA.

JIRA provides a feature called Application Links. Application Links (sometimes called “AppLinks”) are implemented via a bundled plug-in that allows to link JIRA, Confluence, Stash, Fisheye, Crucible and Bamboo applications. Linking two applications allows sharing information and access one application’s functions from within the other. Application Links also allow users of Atlassian products to link them to external non-Atlassian systems in case an Application Link Type is implemented as part of a custom plug-in [17].

(37)

5.1. JIRA PLUG-IN STRUCTURE

5.1 JIRA Plug-in structure

A JIRA plug-in is a single JAR file containing code, a plug-in descriptor (XML) and usually some Velocity template files to render HTML.

Velocity is a template engine based on Java language. It uses simple yet powerful tem-plate language which allows developers using Java objects defined in Java classes. Velocity supports Model-View-Controller model which separates Java code from the web pages. At-lassian uses Velocity template files for easy implementation and generating front-end of its web applications, especially JIRA.

The plug-in descriptor is the only mandatory part of the plug-in. This file has to be called

atlassian-plugin.xmland be located in the root of the JAR file. Each plug-in consists of one or more plug-in modules. These are of different types (for example a report, or a gadget) and each has an individual XML element describing it [18]. Example 5.1.1 depicts atlassian-plugin.xml file.

<!−− t h e plugin key must be unique −−>

< a t l a s s i a n −plugin key ="com . a t l a s s i a n . plugin . sample " name=" Sample Plugin " plugins−v e r s i o n ="2" > <!−− a s h o r t b l o c k d e s c r i b i n g t h e plugin i t s e l f −−> <plugin−i n f o > < d e s c r i p t i o n > This i s a b r i e f t e x t u a l d e s c r i p t i o n o f t h e plugin </ d e s c r i p t i o n > <!−− t h e v e r s i o n o f t h e plugin −−> < v e r s i o n >1.1 </ v e r s i o n > <!−− d e t a i l s o f t h e plugin vendor −−>

</plugin−i n f o >

<web−item key =" google_home " name=" Google Home" weight = " 1 0 " s e c t i o n =" system . admin/example1 " >

< d e s c r i p t i o n key =" item . google . home . desc " > Simple l i n k t o google . com .

</ d e s c r i p t i o n >

< l a b e l key =" item . google . home . l a b e l " />

< l i n k l i n k I d =" google_home " > h t t p :// google . com</ l i n k > </web−item >

</ a t l a s s i a n −plugin >

Example 5.1.1: atlassian-plugin.xml

5.2 Klocwork and Fisheye Application Links

Defining a new Application Link Type is done by creating a Java class implementing the NonAppLinksApplicationType interface (Example 5.2.2) defined by Atlassian applinks

(38)

plug-5.2. KLOCWORK AND FISHEYE APPLICATION LINKS in (Example 5.2.1).

<groupId >com . a t l a s s i a n . applinks </groupId > < a r t i f a c t I d >applinks−api </ a r t i f a c t I d > < v e r s i o n >4.1.1 </ v e r s i o n >

</dependency>

Example 5.2.1: pom.xml dependency

p u b l i c c l a s s KlocworkApplicationType implements NonAppLinksApplicationType {

s t a t i c f i n a l TypeId typeId = new TypeId (" klocwork ") ;

p r i v a t e f i n a l S t r i n g ICON_URL = " h t t p :// developer . klocwork . com/ "+

" s i t e s / d e f a u l t / f i l e s / p i c t u r e s / p i c t u r e −1018.png "; p u b l i c S t r i n g getI18nKey ( ) { r e t u r n " a p p l i n k s . klocwork "; } p u b l i c URI g e t I c o n U r l ( ) { r e t u r n URI . c r e a t e (ICON_URL) ; } p u b l i c TypeId g e t I d ( ) { r e t u r n typeId ; } }

Example 5.2.2: Application type implementation

In order for the Application Link Type to work correctly, it is necessary to register plug-in module (Example 5.2.3).

After startup of JIRA with the plug-in defining this Application Link Type (Figure 5.2) it is possible to create an Application Link to any Klocwork instance. For further use of the Application Link to Klocwork, the authentication token to Klocwork is stored as part of the created Application Link inside JIRA together with the Technical Account login name (Figure 5.3).

As Fisheye is a product from Atlassian, JIRA already contains a definition for the Fisheye Application Link. An authentication of the user is necessary in case gathering of data from the source of the Application Link is needed. Honeywell ACS has JIRA and Fisheye on closed network and both systems include the same user base. Thus the most preferable solution to avoid forcing users to log in twice is Trusted Applications. Creating Application Links from JIRA Administration is described in the Configuration Steps Documentation (Appendix A).

(39)

5.3. MAPPING KLOCWORK PROJECT, JIRA PROJECT AND FISHEYE PROJECT

<applinks−a p p l i c a t i o n −type key =" klocworkApplicationType "

name=" klocworkApplicationType " c l a s s ="com . honeywell . s o f t c o . j i r a . plugin . i n t e g r a t i o n . klocwork . KlocworkApplicationType " >

<manifest−producer c l a s s ="com . honeywell . s o f t c o . j i r a . plugin . i n t e g r a t i o n . klocwork . KlocworkManifestProducer "/>

</applinks−a p p l i c a t i o n −type >

Example 5.2.3: Registering new plug-in module for applinks

5.3 Mapping Klocwork Project, JIRA Project and Fisheye Project

According to the feasibility analysis in Chapter 4, “Integration Feasibility Analysis” it is possible to retrieve names of Klocwork projects as well as names of Fisheye repositories via their respective WEB APIs.

The mapping of projects and repositories needs to be stored in the database of JIRA as this information will be used later when gathering any other data from both systems. At-lassian products however do not allow developers to access its databases directly. In case developers want to store data in database Atlassian provides mechanism called Active Ob-jects. Active Objects is a new ORM (object relational mapping) layer into Atlassian products. Active Objects are implemented as a plug-in into Atlassian applications. It enables easier, faster, and more scalable data access and storage than the existing Bandana and PluginSet-tings APIs [19].

An Active Object entity, which is equivalent of a database table, is created by defining an interface which extends Entity object from Active Objects library (Example 5.3.1). This interface defines getter and setter for each value that is supposed to be stored within the database table. p u b l i c i n t e r f a c e MapJiraKlocwork extends E n t i t y { S t r i n g g e t A p p l i c a t i o n L i n k I d ( ) ; void s e t A p p l i c a t i o n L i n k I d ( S t r i n g a p p l i c a t i o n L i n k I d ) ; long g e t J i r a P r o j e c t I d ( ) ; void s e t J i r a P r o j e c t I d (long j i r a P r o j e c t I d ) ; S t r i n g g e t K l o c w o r k P r o j e c t I d ( ) ; void s e t K l o c w o r k P r o j e c t I d ( S t r i n g k l o c w o r k P r o j e c t I d ) ; }

Example 5.3.1: Active Object Entity

Last step is again registering the entity for plug-in by defining plug-in module in atlassian-plugin.xml (Example 5.3.2). Similar procedure is done for mapping table between JIRA Projects and Fisheye repositories.

As Section 3.1 states, the proposed tool integration is part of the UNITY Project of ACT. The UNITY project consists of integration of several other systems from which some are already implemented, as is the case JIRA – Contour integration, some of them are in the

(40)

5.3. MAPPING KLOCWORK PROJECT, JIRA PROJECT AND FISHEYE PROJECT

Figure 5.2: Klocwork Application Link Type

phase of planning. For higher flexibility and extensibility of the solution, two tables are created, one for Fisheye repository and JIRA project mapping, another for Klocwork project and JIRA project mapping.

The mapping is than created by selecting • JIRA Project

• Klocwork Project • Fisheye Repository • Repository Path

Repository Path is a string defining more specific way into the source code in Repository to avoid gathering unnecessary data and increase performance of the search through REST. This path should be defined to point to codebase which is being analyzed by Klocwork.

(41)

5.4. CREATING DEFECT IN JIRA FROM KLOCWORK

Figure 5.3: Klocwork Authentication Token Configuration

Figure 5.4: Setting authentication to Klocwork

The JSON retrieved from Klocwork REST call for getting Klocwork projects consists of parameters such as

• id — id of project,

• name — name of the project, • creator — creator of the project,

• description — description of the project, • tags — tags of the project.

5.4 Creating Defect in JIRA from Klocwork

Klocwork official website1suggests that their product offers not only WEB API for accessing the data from external systems, but provides the developers and administrators of Klocwork Insight with means for integration with other systems from within Klocwork itself. This is accomplished by creating a script written in Python and saved in project_root/config folder of the Klocwork installation. The script must be saved under the name review_action.py in order for Klocwork to be able to register this script and execute it if necessary. Including script inside this folder displays new button (Figure 5.5) for sending information to external system, which can process this information as necessary.

1. Integrating bug tracking with Klocwork Review <http://www.klocwork.com/products/ documentation/current/Integrating_bug_tracking_with_Klocwork_Review>

(42)

5.4. CREATING DEFECT IN JIRA FROM KLOCWORK

com . honeywell . s o f t c o . j i r a . plugin . i n t e g r a t i o n . klocwork . e n t i t y . MapJiraKlocwork </ e n t i t y >

</ao>

Example 5.3.2: Registering entity in atlassian-plugin.xml

Figure 5.5: Create Defect in JIRA

The developer is provided with an issue object, representing Klocwork finding, which contains various data about the Klocwork finding he/she executed the script from. This data can be further sent to external system through WEB API.

Issue object contains

• username: user name of the person logged into the system and executing the script, • id: the Klocwork finding id,

• name: the Klocwork finding name, • message: the Klocwork finding message,

• file: the file where the Klocwork finding was detected, • code: the code of Klocwork finding,

• severity: the severity of Klocwork finding,

• severityCode: the severity code of Klocwork finding, • state: the state of Klocwork finding,

• status: the status of Klocwork finding

• lastUpdateDate: the date of the last update of Klocwork finding, • owner: the owner of Klocwork finding,

(43)

5.4. CREATING DEFECT IN JIRA FROM KLOCWORK • url: the URL address to Klocwork finding.

The implementation of defect creation in JIRA from Klocwork is composed of two parts: 1. python script executed from Klocwork finding

2. JIRA REST service accepting the data and processing it, creating new issue of type Defect in JIRA

Due to already existing configuration of projects inside JIRA and Klocwork not offering any other interaction with user when executing the python script2several issues which need to be addressed explicitly arise. The “Defect” issue type in ACS JIRA configuration requires several fields to be filled in for the issue to be properly created. The fields and solutions are the following.

• NPI Project:Possible to select value None which is in this case selected explicitly by REST service implementation.

• Summary:Text field, possible to input any text. • Description:Text field, possible to input any text.

• Steps to Reproduce:Text field, possible to input any text.

• Detection Discipline and Activity:Implementation: Static Code Analysis.

• Severity:Set according to severityCode value received from Klocwork, one-to-one mapping of severities 1 being critical and 4 being marginal.

The most important setting is the value for the “Detection Discipline and Activity” field. This field indicates the Defect to be Klocwork-based by setting the value to Implementation: Static Code Analysis. It will be possible to distinguish between Klocwork based defects and other defects by this value which results in possibility to create new metrics and use them in reports and help in searching amongst these issues.

Each JIRA issue may contain links to other systems or external web locations. These links are divided into groups by their purpose. Links to Contour are divided into Tests and Requirements according to the target link. Links to external web locations are in group called“links to”. Backtracking of Klocwork finding that is connected to newly created defect is ensured by creating application link to Klocwork finding instance and putting this link into “Static Code Analysis” group (Figure 5.6).

2. Klocwork Forum - Creating defect in Defect Tracking system <http://developer. klocwork.com/community/forums/customizing-klocwork-insight/miscellaneous/

(44)

5.5. LIST OF KLOCWORK FINDINGS FOR SPECIFIC JIRA ISSUES

Figure 5.6: Link on JIRA View Issue Screen to Klocwork Fidning

5.5 List of Klocwork findings for specific JIRA issues

The ability to gather data from Fisheye and Klocwork and process them in JIRA allows the combination of information about code changes done as part of working on some JIRA issue, Klocwork findings in the code created by static code analysis on the files where the changes were made and subsequently connect this information to specific issue in JIRA.

This feature does this by combining data and creating a list of Klocwork findings that are specific for a JIRA issue.

Figure 5.7: Retrieving data from Klocwork and Fisheye

1. Fisheye WEB API is contacted and used to get changesets using the built up query in the form of EYEQL, query language created for the purposes of searching in Fisheye repositories. The query defines the specific repository to be searched, specific path leading to the codebase (from JIRA – Fisheye mapping table), and the issue key the changesets are being searched for. The precondition for this step to work correctly

is to input issue key into the comment of the commit. These comments are then searched by EYEQL and proper changesets are returned.

2. Klocwork’s WEB API is contacted and used to get the list of builds (analyses) what were executed so far. This step is necessary to select correct builds in which to look