block the feature from further testing as project specific.
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 devel-opment process.
• All responders consider using all implemented features in their development process Q: What benefits 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 specific Klocwork find-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 eval-uation 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 benefits 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 ques-tionnaire 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
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 specific 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 feed-back without proper management, selection of specific 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 fix 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 fixing Klocwork issues he introduced into the code during his development ac-tivities. 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”.
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 possi-bility 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.
Chapter 8
Conclusion
This chapter provides a summary of the work done in this thesis, the deliverables, and their benefits 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 sum-marized 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.