Integrating Static Code Analysis and Defect Tracking

MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345

MASTER THESIS

Jakub Papcun

Brno, 2014

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.

Supervisor: Ing. RNDr. Barbora Bühnová, Ph.D.

iv 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.

v 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 development 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 includes 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.

vi Keywords

Static Code Analysis, Defect Tracking, Klocwork, JIRA, Fisheye, Atlassian, Integration

vii Contents

1 Introduction ...... 1 1.1 Context ...... 1 1.2 Goals ...... 1 1.3 Thesis Structure ...... 2 2 State of the Art ...... 3 2.1 Code Quality ...... 3 2.1.1 Manual Code Review ...... 4 2.1.2 Static Code Analysis ...... 4 2.1.3 Dynamic Code Analysis ...... 5 2.2 Static Code Analysis ...... 6 2.3 Defect Tracking ...... 9 2.4 Defect Tracking of Static Code Analysis findings ...... 10 2.5 CMMI ...... 10 2.6 Conclusion ...... 11 3 State of the Practice ...... 12 3.1 ASDP and the UNITY project ...... 12 3.2 Tools ...... 13 3.2.1 JIRA ...... 13 3.2.2 Klocwork ...... 14 3.2.3 Fisheye ...... 16 3.3 Code Quality and Static Code Analysis ...... 16 3.4 Defect Tracking ...... 18 3.5 Defect Tracking of Static Code Analysis Findings ...... 20 3.5.1 Proposed Features ...... 20 3.5.1.1 Create JIRA Defect from Klocwork Finding ...... 20 3.5.1.2 List of Klocwork Findings for Specific JIRA Issue ...... 21 3.5.1.3 Version Release Readiness Report ...... 21 4 Integration Feasibility Analysis ...... 23 4.1 Overview ...... 23 4.2 Klocwork ...... 23 4.3 Fisheye ...... 25 4.4 Conclusion ...... 26 5 Integration Implementation ...... 27 5.1 JIRA Plug-in structure ...... 28 5.2 Klocwork and Fisheye Application Links ...... 28 5.3 Mapping Klocwork Project, JIRA Project and Fisheye Project ...... 30 5.4 Creating Defect in JIRA from Klocwork ...... 32 5.5 List of Klocwork findings for specific JIRA issues ...... 35 5.6 Version Release Readiness Report ...... 38 6 Evaluation ...... 41

viii 6.1 First Round ...... 41 6.1.1 Method of Evaluation ...... 41 6.1.2 Scenarios ...... 41 6.1.3 Questions and Answers ...... 42 6.2 Second Round ...... 43 6.2.1 Method of Evaluation ...... 43 6.3 Conclusion ...... 44 7 Future Work ...... 45 8 Conclusion ...... 46 8.1 Contribution ...... 46 8.2 Summary ...... 46 Bibliography ...... 49 A JIRA Plug-in Installation and Conﬁguration ...... 50 A.1 JIRA Plug-in ...... 50 A.2 Python Installation ...... 52 B Terms, acronyms and abbreviations ...... 53 C Glossary ...... 54 D Contents of the attached archive ...... 55

ix Chapter 1 Introduction

1.1 Context

Honeywell is an international company that invents and manufactures a wide range of products 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 deﬁned as one of its responsibilities. ACT’s role also includes developing best practices, coaching and mentoring of other teams across Honeywell ACS. Further, ACT supports 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 ﬁnd a way to decrease the development cycle time by integrating some of the tools used for software development across Honeywell ACS, speciﬁcally Klocwork Insight (Klocwork) and Atlassian JIRA. This integration should help the developers save time during their development activities as well as code quality of their developed software products.

1 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 Art provides 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 describes Defect Tracking and existing solutions of Static Code Analysis and Defect Tracking integration.

Chapter 3 State of the Practice describes 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 Implementation deals with the implementation itself. It describes each implemented feature, open issues the features still deal with due to various factors, and the resulting products of the implementation.

Chapter 6 Evaluation describes 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 Work suggests feature improvements, upgrades, and ideas for new features to be implemented as part of the integration.

Chapter 8 Conclusion evaluates the goals fulﬁllment and summarizes the outputs of the thesis.

2 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 speciﬁcation, 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 speciﬁed level of performance when used under speciﬁed conditions,

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

• efﬁciency — the capability of the software product to provide appropriate performance, 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 speciﬁed conditions,

• portability — the capability of the software product to be transferred from one environment 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 difﬁcult. 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.

3 2.1. CODE QUALITY

2.1.1 Manual Code Review

One of the easiest code veriﬁcation 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 probability of ﬁnding 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 ﬁxes 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 speciﬁc 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 include refactoring capabilities,

4 2.1. CODE QUALITY

• program veriﬁcation and property checking — attempts to prove that the code correctly implements the speciﬁcation of the program,

• bug ﬁnding — 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 ﬁnders. 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 analyze and ﬁx 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 identiﬁcation 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

• Allocation and de-allocation of objects

5 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 development time, deliver more with less quality. Subsequent failures may result in customer frustration, high cost ﬁxing 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 representation, 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].

6 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 compilers and important for object oriented languages).

• Tracking Control Flow — means for increasing efﬁciency 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 ﬂow paths between nodes, – back edges — represent potential loops.

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

• Taint Propagation — using dataﬂow 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 speciﬁc 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,

• mismatched override.

7 2.2. STATIC CODE ANALYSIS c l a s s A{ void foo ( ) ; } void A : : foo ( ) { i n t ∗ ptr = new i n t ; ∗ ptr = 2 5 ; ptr = new i n t ; ∗ ptr = 3 5 ; } /∗ Klocwork c r e a t e s a d e f e c t report l i k e the following : ∗ mlk . must . cc : 8 : Error : Memory leak . Dynamic memory stored in ’ ptr ’ a l l o c a t e d ∗ through function ’new ’ at l i n e 6 i s l o s t at l i n e 8 ∗/

Example 2.2.1: Memory Leak s t a t i c ovid check ( i n t arr [ ] ) { i f ( arr != null & arr.length != 0){ foo ( ) ; } return ; } /∗ Klocwork c r e a t e s a d e f e c t report l i k e the following : ∗ JD . BITCMP i s reported f o r l i n e 2 : Questionable use of b i t operation ’&’ ∗ in expression . Did you mean ’&&’? ∗/

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

Static Code Analysis however identiﬁes 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 requirements 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 ﬁxed before releasing the product.

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

8 2.3. DEFECT TRACKING switch ( k ) { case 1 : b = 2 ; break ; case 2 : b = 3 ; /∗ F a l l Through∗/ case 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 identiﬁed 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 architecture and the context of the software. This often results in False Positives which have to be conﬁrmed by the developer. Example 2.2.4 shows code where Klocwork ﬁnding was reported: The ’doStopWatching’ method throws a generic exception ’java.lang.Exception’. As the code was created this way by design, it is a False Positive. public String doStopWatching() throws Exception { return 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, defects, 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 development 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

• JIRA by Atlassian,

9 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 ﬁndings

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 systems 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 identifying 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 Google 1 . This is however 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 JIRA 2 . 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 automation 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 processes [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 improvement in all the disciplines of software development cycle according to indicators, measurements and metrics which are continuously collected. The process is then evaluated according 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) 2. Kuiwan integration with Atlassian JIRA

10 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 ﬁx code errors as well as time reduction of the development process. Research into Static Code Anal- ysis ﬁndings found for particular features of programs may even help in predicting future problems and avoid incorrect programming in advance.

11 Chapter 3 State of the Practice

Honeywell ACS developed ACS Software Development Process (ASDP) to fulﬁll 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 continuous 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 ﬁndings 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 ﬁrst 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 software development projects. ASDP what to do, not how to do it while ACT creates or uses existing best practices and recommendations for fulﬁlling 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 redundancy 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 information 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 information which data from one discipline belongs to which data from another.

12 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 Conﬂuence Extension Project 1 . 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 ﬂexibility of conﬁguration options from an administration point of view.

1. Wiki pages of the UNITY project

13 3.2. TOOLS

• Management of Projects: – CRUD operations 2 – management of Project Roles – management of Project Versions and Components

• Configuration of Issues: – management of Workflows – management of Custom fields 3

• 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 developers 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 Types 4 , JQL Function 5 , 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 conﬁgurable 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 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

14 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 administrator 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 developer 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 understand 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 security 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.

15 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 products, 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 development 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 reporting 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 satisﬁes quality attributes,

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

• verify that a code element conforms to deﬁned Coding Conventions,

• collect ﬁndings into a comprehensive Code Review Record for further appropriate actions. Static Code Analysis is another way of securing software code quality used in development 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 ﬁxing later in time [14].

16 3.3. CODE QUALITY AND STATIC CODE ANALYSIS

• During the implementation activity — the developer should analyze the code they created or modiﬁed on their own working station and ﬁx 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 ﬁnd 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 ﬁndings 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 ﬁndings however still possible crash of the program or leakage of information to unauthorized users.

– Usage of released resources (ﬁles, 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]

• the date of the static code analysis,

17 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, ﬁxed, deferred, not a problem, ignore, etc.).

The report may also contain some information about the trend of detected/resolved anomalies 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 development 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 extensibility 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), analyzing 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.

18 3.4. DEFECT TRACKING

Figure 3.2: Tools Integration

• Defect Proﬁle 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 ﬁxed.

• 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 ﬁxing 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.

19 3.5. DEFECT TRACKING OF STATIC CODE ANALYSIS FINDINGS

• Version-Based Defect Leakage Report — See in which version defects were detected and ﬁxed.

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 ﬁnding. With the information about possibility to partially extend some functionality of Klocwork it should be possible to create JIRA Defect remotely from Klocwork ﬁnding.

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

• Possibility to control and update Klocwork ﬁndings from JIRA which would possibly 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 ﬁndings ﬁxing 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 ﬁrst 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.

20 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 generally 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 ﬁndings per severity for all Issues in the selected release. The report will contain links to Klocwork displaying list of appropriate Klocwork ﬁndings. 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.

21 3.5. DEFECT TRACKING OF STATIC CODE ANALYSIS FINDINGS

Figure 3.4: Version Release Readiness Report mockup

22 Chapter 4 Integration Feasibility Analysis

4.1 Overview

As the topic of the thesis suggests, its goal is to ﬁnd 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 ﬁnd 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 analyze 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.

23 4.2. KLOCWORK

There are two steps that are generally executed when communicating with another system, Authentication and Retrieving/Updating the data on the external system. It is necessary 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 provide 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 ﬁle named ltoken, stored in .klocwork folder inside the proﬁle folder of user executing the operation.

• The record in ltoken ﬁle has the following form:

– serverUrl;port;userLoginName;authenticationToken

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

24 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 individual 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 authenticated 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 functionality 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 Conﬁguration 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, retrieving, 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 ﬂexible functions and what

25 4.4. CONCLUSION is more important, native authentication mechanism which helps the developer avoid implementing their own way of dealing with security issues. The Fisheye WEB API provides the developers with the following functionality 1

• 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 ﬁle 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 speciﬁc 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 individual 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

26 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 mapping 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].

Figure 5.1: Data Flow

27 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 template 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.xml and 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.

< a t l a s s i a n −plugin key="com. atlassian .plugin.sample" name="Sample Plugin" plugins−version="2"> This is a brief textual description of the plugin 1.1

Simple link to google.com. http://google.com

Example 5.1.1: atlassian-plugin.xml

5.2 Klocwork and Fisheye Application Links

Deﬁning a new Application Link Type is done by creating a Java class implementing the NonAppLinksApplicationType interface (Example 5.2.2) deﬁned by Atlassian applinks plug-

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

com. atlassian . applinks applinks−api 4.1.1

Example 5.2.1: pom.xml dependency

public 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 = " http :// 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 /picture −1018.png" ;

public String getI18nKey() { return " applinks . klocwork " ; }

public URI getIconUrl() { return URI . c r e a t e (ICON_URL) ; }

public TypeId getId() { return 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).

29 5.3. MAPPING KLOCWORK PROJECT, JIRA PROJECT AND FISHEYE PROJECT

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 deﬁning an interface which extends Entity object from Active Objects library (Example 5.3.1). This interface deﬁnes getter and setter for each value that is supposed to be stored within the database table. public i n t e r f a c e MapJiraKlocwork extends E nt i t y { String getApplicationLinkId() ; void setApplicationLinkId(String applicationLinkId) ; long getJiraProjectId() ; void setJiraProjectId( long jiraProjectId); String getKlocworkProjectId() ; void setKlocworkProjectId(String klocworkProjectId) ; }

Example 5.3.1: Active Object Entity

Last step is again registering the entity for plug-in by deﬁning 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

30 5.3. MAPPING KLOCWORK PROJECT, JIRA PROJECT AND FISHEYE PROJECT

Figure 5.2: Klocwork Application Link Type phase of planning. For higher ﬂexibility 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.

31 5.4. CREATING DEFECT IN JIRA FROM KLOCWORK

Figure 5.3: Klocwork Authentication Token Conﬁguration

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 ofﬁcial website 1 suggests 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/conﬁg 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

32 5.4. CREATING DEFECT IN JIRA FROM KLOCWORK

com.honeywell. softco . jira .plugin. integration .klocwork. entity .MapJiraKlocwork

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 ﬁnding, which contains various data about the Klocwork ﬁnding 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 ﬁnding id,

• name: the Klocwork ﬁnding name,

• message: the Klocwork ﬁnding message,

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

• code: the code of Klocwork ﬁnding,

• severity: the severity of Klocwork ﬁnding,

• severityCode: the severity code of Klocwork ﬁnding,

• state: the state of Klocwork ﬁnding,

• status: the status of Klocwork ﬁnding

• lastUpdateDate: the date of the last update of Klocwork ﬁnding,

• owner: the owner of Klocwork ﬁnding,

• project: the project where Klocwork ﬁnding belongs,

33 5.4. CREATING DEFECT IN JIRA FROM KLOCWORK

• url: the URL address to Klocwork ﬁnding.

The implementation of defect creation in JIRA from Klocwork is composed of two parts:

1. python script executed from Klocwork ﬁnding

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 script 2 several 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 ﬁeld, possible to input any text.

• Description: Text ﬁeld, possible to input any text.

• Steps to Reproduce: Text ﬁeld, 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

34 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 ﬁndings for speciﬁc 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

35 5.5. LIST OF KLOCWORK FINDINGS FOR SPECIFIC JIRA ISSUES

for Klocwork ﬁndings.

3. Proper Klocwork builds are selected. All changesets are iterated, and builds that have the closest execution time in the future to the given changeset is selected.

4. For each selected Klocwork build, Klocwork WEB API is contacted again to search amongst the ﬁndings to select those which were in state New after the build execution. These were created as part of the given build.

5. The last step contacts Klocwork’s WEB API again to gather the current status of each of found Klocwork ﬁndings. Some may not necessarily exist anymore in the latest Klocwork analysis.

6. These Klocwork ﬁndings are displayed as a list in Issue Tab Panel for each individual JIRA issue.

Klocwork ﬁndings JSON data is very similar to the one that are part of issue object described in Section 5.4 . • JSON data do not include username, name, lastUpdateDate.

• JSON data include additional data: title, processData, taxonomyName, dateOrigi- nated. Searching of Klocwork findings as well as Fisheye changesets is done by the respective query languages in either web interface or via WEB APIs. Fisheye query language (EyeQL) is an extensive and flexible query language for searching among Fisheye changesets. The syntax of the query is intuitively similar to SQL and other similar database languages. For further information see official Atlassian documentation 3 . Klocwork query language supports several keywords such as • build: specific static code analysis,

• code: the code of the checker by which you want to ﬁlter Klocwork ﬁndings,

• ﬁle: ﬁle where Klocwork Finding was found,

• id: the id of Klocwork Finding,

• severity,

• state,

• status etc. 4

3. Fisheye EyeQL 4. Searching in Klocwork

36 5.5. LIST OF KLOCWORK FINDINGS FOR SPECIFIC JIRA ISSUES

As it is possible to collect also the data about the severity of each individual Klocwork finding, it is possible to determine the quality of the code created for the issue. Users can subsequently determine by themselves, for example, if the issue/feature is implemented and its functionality ready to be manually tested or if it is necessary to keep fixing found code errors. The Readiness Indicator gives the user information about the issue being free from the errors in the code. As mentioned in Section 3.5.1.2 the decision about the security status of the feature is non-deterministic in respect to the number of Klocwork findings of each severity which are considered to be safe. This depends from project to project and one of the solutions of this problem will be mentioned in Chapter 7, “Future Work”. As Klocwork findings of Error and Warning severity should be mitigated as soon as possible, the implementation of this feature decides that in case of any open Klocwork findings of error or warning severity are unsafe for manual testing and release.

Figure 5.8: Klocwork Issue Tab Panel

This feature has two main goals to reach. 1. Shorten development time cycle by listing right issues automatically without user having to look for the ﬁndings he/she introduced into the code. The developer working with the code at the moment is able to ﬁx code errors in a shorter time.

2. Increase the code quality by easier access to Klocwork findings and encouraging the developer to fix them before the code errors are introduced to production environment. The solution does have its limitations given especially by Klocwork. Klocwork analysis takes about 20 minutes to be executed for around 600 file project. This means, commit analysis is not an option for bigger projects that are done by Honeywell teams. Klocwork analyses are at the moment executed on nightly basis or on the basis of more days. This means several commits from the user, can have identical Klocwork analysis assigned to them. In case there are two JIRA issues dealing with the same file in the repository, each having changes

37 5.6. VERSION RELEASE READINESS REPORT done and being committed before the Klocwork analysis that is the same for both of them, the same Klocwork ﬁnding can be assigned to both JIRA issues at the same time.

5.6 Version Release Readiness Report

This report consolidates aforementioned functionality of gathering data from Fisheye, Kloc- work and assigning Klocwork findings to JIRA issues. The user is able to select a particular version he/she is interested in, released or non-released, and the report creates statistics of the Klocwork findings for each JIRA issue that has the selected version set as“Fix Version”. The data retrieved and visualized in a graph or table in JIRA are defined by configurable parameters. Our report needs two fields to be filtered by.

• Project — one of the main fields which are mostly selectable of every report. Modifi- cations are selection of Project or Filter or selection of Filter by itself. As versions are project specific, only a single project may be selected in this report.

• Version — selection of version the user is interested in. Fix Version field is always project specific as administrator of a project can create and manage versions of the given project by him/herself. This means that this field is variable and dependent on the project selection.

The functionality for getting data for each relevant issue is identical to implementation of Klocwork Issue Tab Panel. Getting relevant issues is done by selecting all issues which have the selected version stored in Fix Version field. Fix Version field stores the information about issue being planned to be fixed in the selected version.

Figure 5.9: Version Realease Readiness Report

• Row above the table indicates the resolution of the version being ready for release.

• Each issue key is hyperlink to the given issue.

38 5.6. VERSION RELEASE READINESS REPORT

• Each number and severity header is hyperlink to Klocwork with the list of all relevant Klocwork finding. This feature has two main goals to reach. • Analyze and decide if the issues (features) created as part of a selected version are ready for deployment on production environment. • Give a user overall overview about the quality of the code created as part of specific version. This report requires gathering a lot of data from JIRA (all the issues for the selected version) and two external systems (Fisheye – Fisheye changesets for each individual issue, Klocwork – Klocwork builds, Klocwork findings for each selected build, Klocwork findings for checking the current status). This can lead to noticeable execution time of report generating (see Table 5.1). Report generation takes considerable time even in case of just 20-50 issues which make 100-120 REST calls to other systems. The cause of such high number of REST calls is mainly due to the fact, that it is not possible to gather all relevant data from Klocwork in one REST call. As Figure 5.7 and its description mentioned, it is necessary to make a separate call for each Klocwork build with relevant files. Klocwork query language, however, does not support OR operator in Klocwork Insight 5 which makes it impossible to make right selection of findings in one REST call. Possible improvements are mentioned in Chapter 7, “Future Work”. Release 3.2 Release 3.7 (29 Release Release 4.1 (52 Issues) Issues) 3.10 (109 (22 Issues) Issues) Number of Issues 4 2 13 4 with Klocwork Findings Fisheye REST Calls 52 29 109 22 Fisheye Changesets 146 165 584 249 Klocwork REST 68 81 143 77 Calls 1. Attempt 85.757s 98.283s 239.558s 102.058s 2. Attempt 105.656s 96.026s 238.364s 88.925s 3. Attempt 120.780s 101.186s 349.718s 91.372s Average 104.064s 98.498s 275.880s 94.118s

Table 5.1: Klocwork WEB API capabilities

5. Klocwork Forum - OR operator in query searching in Klocwork

39 5.6. VERSION RELEASE READINESS REPORT

Figure 5.10: Version Readiness Report performance chart

40 Chapter 6 Evaluation

This chapter summarizes the evaluation of the master thesis results. The goal of evaluation of the thesis was veriﬁcation of usefulness, usability and beneﬁts that are brought to the development process in Honeywell ACS by use of implemented features.

6.1 First Round

The first round of evaluation collects first data about the right direction in which the implemented features are supposed to bring benefits to development activities.

6.1.1 Method of Evaluation The features are supposed to bring more comfortable work with Static Code Analysis findings inside JIRA. To see the real life benefits coming from the features, it is necessary to know the opinion of the users using the features and collect the data about their usage, especially the time they need to obtain specified data and other . For this reason the scenarios and questionnaire was created. The evaluation consisted of three parts

1. Introduction into the set of features implemented for Klocwork – JIRA integration.

2. Three scenarios the users were supposed to execute.

3. Questionnaire consisting of 7 questions.

The group of evaluators consisted of four software developers from ACT team in Brno one of which is also in the position of project leader. The project used for evaluation was ACS JIRA Extensions (AJE). The evaluators have an experience with the tools used in the integration and use them on daily basis for their development activities.

6.1.2 Scenarios The three scenarios navigated the evaluators through each implemented feature. These scenarios aimed for the evaluators to try each feature, evaluate their personal feelings about it and to compare the results of approach for retrieving speciﬁed data without the integration and with it.

41 6.1. FIRST ROUND

The first scenario introduced feature “Create JIRA Defect from Klocwork Finding”. This simple scenario required the evaluator to navigate to one of Klocwork findings and create JIRA Defect. The second scenario introduced feature “List of Klocwork Findings for Specific JIRA Is- sues”. The goal of the scenario was to select correct Klocwork findings which were result of code commit for specific JIRA issue. The scenario consisted of two approaches. One required selecting the Klocwork findings manually without the implemented integration. The second approach was collecting the Klocwork findings in an automated way with the help of implemented feature. The scenario was meant to get an idea about the time saved and about the Klocwork findings found being correct. The third scenario introduced feature “Version Release Readiness Report”. Another simple scenario required evaluators to test the report on their project and evaluate the value of data collected and displayed.

6.1.3 Questions and Answers

The questions gathered responses from evaluators on the time they saved by using the integration, the beneﬁts of the integration brings into their developments process as well as its drawbacks and the issues they came across. The evaluators were also asked to bring their own ideas about improvements or upgrades of existing features as well as ideas about new features that might be beneﬁcial for their work.

Q: What time difference (in minutes) did you record when testing “List of Klocwork Find- ings for Speciﬁc JIRA Issue”? There were two approaches to get the same results for this scenario, one without integration and one with the integration.

• The integration saved from 5 to 15 minutes on the same data. The wide range of difference was caused by the level of the knowledge of each system by the respondent.

Q: Did you find the same number of Klocwork findings by manual searching in Scenario 2 as did the feature “List of Klocwork Findings for Specific JIRA Issue”? If not, what was the number of manually found Klocwork findings and automatically found Klocwork findings?

• One of the responders did not collect correct data when executing the approach without the integration.

Q: What number of Klocwork ﬁndings of each severity do you consider as a threat to the analyzed JIRA issue. ( “>” = more than) [leave blank if you do not have a number for an answer] The users were asked to decide what number of Klocwork ﬁndings in the given severity they considered unsafe.

1. Critical and Error: All responders considered more than 0 ﬁndings of this severity to be blocker for further testing and release to production.

42 6.2. SECOND ROUND

2. Warning and Review: Most responders consider the number of ﬁndings that would block the feature from further testing as project speciﬁc.

Q: Which of the features would you like to incorporate into your development process? The users were asked to list the features they would be willing to use as part of their development process.

• All responders consider using all implemented features in their development process

Q: What beneﬁts do you see in JIRA-Klocwork-Fisheye integration?

• Increased quality of the code, lower risk of defects and time saving. Easily monitored and measured when the user has possibility to see JIRA Issue speciﬁc Klocwork ﬁnd- ings.

Q: What drawbacks do you see in JIRA-Klocwork-Fisheye integration?

• Non-friendly UI on the end of Klocwork. The defect should contain a code snippet. Decreased performance especially in Version Release Readiness Report. Report and JIRA Issue Tab Panel is not consistent with Atlassian Design Guidelines (as the rest of JIRA design)

Q: Is there anything you would change in JIRA-Klocwork-Fisheye integration?

• E-mail notification for resolved JIRA issues with linked critical/error findings. In- crease performance of the features. Improve UI of all the features according to Atlas- sian Design Guidelines (on the end of JIRA) or create user friendly interface (on the end of Klocwork). The color of Readiness Indicator in List of Klocwork Findings for Specific JIRA issue and in report should have the color of existing finding of highest severity.

6.2 Second Round

The integration is supposed to be used across whole Honeywell ACS. Second round of evaluation will be conducted before releasing the integration into production environment. This evaluation should be conducted by the members of several different teams across Honey- well ACS. The result of this evaluation should show the real beneﬁts of the integration for whole Honeywell ACS.

6.2.1 Method of Evaluation Several ways of evaluation are offered for the second part of the evaluation. These ways go from already existing manual trial by evaluators according to the scenarios and questionnaire through a demonstration by the creator of the integration to a presentation with a video demonstration of the features. Another issue with second round of evaluation is the

43 6.3. CONCLUSION selection of evaluators. One of the options is broadcasting the evaluation to as many people across Honeywell ACS as possible, the other is selecting speciﬁc people who would evaluate the integration. The evaluation by members of other teams requires usually more effort. This is due to the fact that these people usually work on different places around the world. This raises the question about how much effort there is to be put into another evaluation round before the production release. As broadcast evaluation is very costly and very likely to have little feedback without proper management, selection of speciﬁc evaluators from around the world seems as a better option. As the development infrastructure used for the integration in this early phase is not ideal (little data, performance issues, etc.), the likelihood of incorrect use of integration is higher. The presentation with live demonstration of integration or prepared video, and subsequent questionnaire will be better option for this round of evaluation.

6.3 Conclusion

The evaluation gives us an idea about the assets of the integration as well as the problems users encountered during their work with implemented features. First of all using the features should encourage the developers to take care about the quality of their code and ﬁx Klocwork issues found for their JIRA Issue. Responders showed willingness to use the features. Using these features should decrease the time the developer spends on ﬁxing Klocwork issues he introduced into the code during his development activities. The time difference they spent on retrieving the same data with and without the integration declares big time saving. The responders claimed to have issues with performance of the features which were an- ticipated as these issues were already described in Section 5.6 of implementation of Version Release Readiness Report. Issues and suggestions for improvements are further described in Chapter 7, “Future Work”.

44 Chapter 7 Future Work

Issues the implementation came across, necessary improvements and the users’ evaluation of features uncovered several opportunities for improving and upgrading the functionality of the integration. The improvements may be divided into three groups. Performance. Most serious issue the integration suffers from right now is performance. This issue might be fixed by implementation of a cache or by the change of query abilities in Klocwork. Visual Changes. Users’ suggestions included a change of the color scheme indicating Klocwork finding severities in the list of Klocwork findings for specific JIRA issue as well as in the Version Readiness Report. This change could be connected with change of Readiness Indicator behavior which would be in the color of the highest Klocwork finding severity found for the given JIRA issue. The second visual change deals with alert popup message displayed after JIRA Defect is created from Klocwork. However, this change is dependent on ability of Klocwork to change this part of its implementation which is not offered to developers in the latest version 10 of Klocwork. Upgrades of existing functionality. One of the users’ suggestions is to add the possibility to create a JIRA Defect from the list Klocwork findings for a specific JIRA Issue. This should further consolidate integration control into only one of the integrated systems. An- other feature for further implementation comes from the fact that decision about the feature readiness is non-deterministic and it depends on the project purpose what number of Kloc- work findings of each severity is sufficient for passing. For this, a project-specific setting of the number of Klocwork findings of each severity may be implemented. This would allow the project administrators to and set their own limits/thresholds. This integration may offer an opening for more sophisticated features especially code error prediction as the first step to this goal, assigning Klocwork findings to JIRA issues has been implemented in the thesis.

45 Chapter 8 Conclusion

This chapter provides a summary of the work done in this thesis, the deliverables, and their beneﬁts brought into Honeywell ACS software development process. The thesis introduced assurance of Code Quality as an important part of the software development process and basic ways of the assurance itself. It discussed the possibilities of integration with Defect Tracking systems and existing solutions as well as the possible solution for integration inside Honeywell ACS. The implementation part of the thesis summarized the feasibility analysis of integration and the integration itself. The thesis had three goals to accomplish. It aimed to centralize execution of some of actions from different tools to one of them only, reduce the time the action needed to be executed and in the end also raise code quality of created software product.

8.1 Contribution

The output of the thesis is a set of three features implemented as a plug-in for Atlassian JIRA and a Python script extending Klocwork functionality. These features integrate Klocwork, Atlassian JIRA and Atlassian Fisheye and try to combine data about Klocwork findings and commits to a repository in order to encourage developers to work on fixing code errors, increasing code quality, and save time of developers during these activities. As Section 6.2 summarizes, the features are expected to save developers’ time and raise their willingness to put more effort into fixing Static Code Analysis findings. The solution does not really bring more work into the development process; it saves time for activities the developers should already have it practice.

8.2 Summary

The thesis showed the possibility of integration between Static Code Analysis and Defect Tracking system used in Honeywell ACS. Even if limited, the integration should bring the users of the systems more comfort into their development activities and help them create products of higher quality. The implementation dealt with some more serious limitations some of which are however out of the reach of our work. Getting rid of these limitations, the integration may be taken to another level, completely centralizing work with Static Code Analysis from Defect

46 8.2. SUMMARY

Tracking tool, and possibly open way to more sophisticated features like code error predicting. This however requires Klocwork to open up their WEB API functionality.

47 Bibliography

[1] ISO/IEC 9126. Information Technology - Software Product Evaluation - Quality char- acteristics and guidelines for their use. Joint Technical Comitee, 1991. 2.1

[2] COHEN, Jason, et al. Best kept secrets of peer code review. Smart Bear, 2006. URL: . 2.1.1

[3] WIEGERS, Karl E. Seven truths about peer reviews. Cutter IT Journal, 2002, 15.7: 31-37. [article]. URL: . 2.1.1

[4] KESÄNIEMI, Ari. Automatic vs. Manual Code Analysis. OWASP, 2009, 17.11. [presentation] URL: . 2.1.1

[5] CHESS, Brian and Jacob WEST. Secure programming with static analysis. Upper Sad- dle River: Addison-Wesley, 2007, s. 24-35. ISBN 978-0-321-42477-8. 2.1.2

[6] ACT. ACS Software Development Process: Concept: Dynamic Analysis. [online]. [cit. 2014-05-13]. URL: . (internal). 2.1.3

[7] ROTIBI, Bola. The Business Value of Software Static Analysis. Macehiter Ward-Dutton Limited, 2008. [paper] URL: . 2.2

[8] CHESS, Brian and Jacob WEST. Secure programming with static analysis. Upper Sad- dle River: Addison-Wesley, 2007, s. 72-83. ISBN 978-0-321-42477-8. 2.2

[9] GERMAN, Andy. Software static code analysis lessons learned. Crosstalk, 2003, 16.11. [article] URL: . 2.2

[10] TEAM, CMMI Product. CMMI for Development Version 1.3 (CMMI-DEV, V. 1.3) CMU. SEI-2010-TR-033, SEI Carnegie-Mellon University, 2010. URL: . 2.5

[11] ACT. ACS Software Development Process: Version 3.6. [online]. [cit. 2014-05-13]. URL: . 3.1

[12] KLOCWORK. Taxonomy. [online]. [cit. 2014-05-13]. URL: . 3.2.2

48 [13] ACT. ACS Software Development Process: Concept: Code Review. [online]. [cit. 2014- 05-13]. URL: . (internal). 3.3

[14] ACT. ACS Software Development Process: Guideline: When shall I use Static Code Analysis?. [online]. [cit. 2014-05-13]. URL: . (internal). 3.3

[15] ACT. ACS Software Development Process: Artifact: Static Code Analysis Report. [online]. [cit. 2014-05-13]. URL: . (internal). 3.3

[16] HARDT, Dick. The OAuth 2.0 authorization framework. [online]. [cit. 2014-05-13]. URL: . 4.2

[17] ATLASSIAN. Application Links Documentation: Application Links 4.0. [online]. [cit. 2014-05-13]. URL: . 5

[18] ATLASSIAN. Concepts: JIRA Development. [online]. [cit. 2014-05-13]. URL: . 5.1

[19] ATLASSIAN. Active Objects. [online]. [cit. 2014-05-13]. URL: . 5.3

49 Appendix A JIRA Plug-in Installation and Conﬁguration

The appendix describes installation and conﬁguration of JIRA plug-in inside JIRA instance as well as installation of python script inside Klocwork instance. The guidline assumes that the administrator installing the JIRA plug-in has basic knowledge of JIRA administration.

A.1 JIRA Plug-in

Prerequisites

• Built JIRA plug-in (jar ﬁle)

• Existing Technical Account with correctly set permissions in Klocwork projects

• The administrator is in JIRA administration section

Plug-in Installation

• Navigate to Add-ons > Manage Add-ons

• Select Upload add-on

• Select the jar ﬁle (plug-in) and click on Upload

Application Link Creation

• Navigate to Add-ons > Application Links

• Select Add Application Link

• Insert URL address to Klocwork instance and click Next

• Insert Application Name, select Klocwork as Application Type and click Create

Application Link Conﬁguration

• Use kwauth utility to get Authentication Token for Technical Account

• Navigate to Add-ons > Application Links

• Click on Conﬁgure Authentication Token

50 A.1. JIRA PLUG-IN

Figure A.1: Authentication Token for Klocwork Conﬁguration

• Insert username and acquired Authentication Token of Technical Account (Fig- ure A.1) Klocwork – JIRA – Fisheye Mapping • Navigate to Add-ons > Map Klocwork, Fisheye and JIRA

• Click on Map Projects

• Select JIRA Project, Klocwork Project and Fisheye Repository you want to map together

• Optionally insert Fisheye Repository Path to ﬁlter the path to the codebase ( Fig- ure A.2 )

Figure A.2: Authentication Token for Klocwork Conﬁguration

• Click on Save

51 A.2. PYTHON INSTALLATION

• Deleting of mapping is executed by clicking on Delete button in the table of existing mappings ( Figure A.3 )

Figure A.3: Authentication Token for Klocwork Conﬁguration

A.2 Python Installation

Prerequisities.

• json v3.4 python library downloaded

• python script ﬁle named review_action.py which will extend Klocwork functionality

• JIRA plug-in is installed on JIRA instance

• Python script includes correctly set URL to JIRA instance (url)

• Python script includes correctly set username (iusername) and password (password) of Technical Account

Python Script Installation.

• Navigate to Klocwork Server directory

• Navigate to projects_root\conﬁg directory

• Place review_action.py python script inside the directory

• Place json library inside the directory

52 Appendix B Terms, acronyms and abbreviations

Term Deﬁnition ACS Automation and Control Solutions ACT ACT Center of Technologies ASDP ACS Software Development Process CMMI Capability Maturity Model Integration JSON JavaScript Object Notation NPI New Product Introduction process REST Representational State Transfer

Table B.1: Terms, acronyms and abbreviations

53 Appendix C Glossary

Defect: A Defect is an error, ﬂaw, mistake, or fault in the software, product or system under development or associated deliverables and workproducts. If left unresolved, a defect may cause a Failure by producing an incorrect, unexpected or unintended behavior in the end product.

Code Error: A point in the code which may cause the program to behave in a different way from the way intended by the developer.

Klocwork Finding (Klocwork Issue): Klocwork wrapper for Code Error. A Klocwork object storing the details about the Code Error found by the Static Code Analysis inside Klocwork. Presented to the user as a Web Page in Klocwork Insight.

JIRA Issue: JIRA Issue represents a software bug, a project task, a helpdesk ticket, a leave request form and other types of tasks or problems inside JIRA. It stores the details about the task. Presented to the users as Web Page in JIRA.

54 Appendix D Contents of the attached archive

• Source code of Integration implementation (Maven Project)

• Compiled JAR ﬁle of Integration implementation

• Python script extending Klocwork functionality