A CONCEPTUAL SHORT COMMUNICATION PAPER ON PERFORMANCE APPRAISAL TECHNIQUE FOR SOFTWARE DEVELOPERS AND SOFTWARE QAS BASED ON SOFTWARE QUALITY METRICS

in for a while and introduced for the employee where failed usage about them. Thus, the topic of this conceptual paper arose. In this regard, such software quality metrics have been studied and discussed and a conceptual research has been conducted in this paper for the purpose of easy performance appraisal technique research and deployment further in future for software developers and software QAs. Especially, the enhanced description and analysis of different software quality metrics and how proper utilization of software metrics can be effective in terms of employee evaluation, has been done here in an authentic way.

Performance appraisal techniques have been in research for a while and software quality metrics have been introduced for the employee evaluation process already. Currently, there are several organizations, where proper employee evaluation process gets failed due to inefficient usage of software quality metrics and deficiency of knowledge about them. Thus, the topic of this conceptual paper arose. In this regard, such software quality metrics have been studied and discussed and a conceptual research has been conducted in this paper for the purpose of easy performance appraisal technique research and deployment further in future for software developers and software QAs. Especially, the enhanced description and analysis of different software quality metrics and how proper utilization of software metrics can be effective in terms of employee evaluation, has been done here in an authentic way.

…………………………………………………………………………………………………….... Introduction: -
Many organizations rely on Performance Appraisal techniques for their improvement. Eventually, various techniques have been formed to evaluate employees of different sectors of an organization. Numerous software quality metrics have been established for this purpose but none of them were investigated enough to make them into practice. Following these, number of software quality metrics have been discussed in this conceptual paper to support the performance appraisal techniques for Software Developers and Software QAs in organizations.
However, how should software developers and software QAs be appraised, has been off from the research as far investigated for this paper. Not much revealed about the performance appraisal techniques for such employees, although several software quality metrics have been provided in several articles and theories. Researchers have still been going on but could not result in practice yet. Organizations cannot seem to find ways to properly evaluate their employees, especially at IT firms for the software developers and QA engineers. Practitioners seem to not find ways to conduct performance appraisal for these employees within such organizations.
In this paper, we have put emphasis on a broader insight into industrial practice on performance appraisal technique for Software Developers and Software QAs utilizing the already established software quality metrics.

Inclusion and exclusion criteria:
Priorities have been given to topic area of Performance Appraisal of Software Developers and Software QAs. Any other Performance Appraisal criteria have been excluded from this search query for this research. Depth in the topic of Performance Appraisal techniques has also been given with caution.

Theoretical framework of Software Quality Metrics: Agile Process Metrics for Software Developers Velocity:
Velocity is measurement of how many features got done during a period. Most often, velocity is measured by sum of story points but it can also be measured by number of feature tickets delivered within a period. This period can be a sprint, such as, if 20 story points done within 2 weeks and that equals to 1 sprint, then average velocity will be 10 of that team individually. There is another measurement which is the average of story point. From theory we can say that, falling velocity proves there is a bottleneck that the management should investigate to find out the cause behind it. If velocity is stable means target achieving process is working right and an increasing velocity means performance quality increased. If an employee is consistently working on any lower level average story point then it shall mean s/he is not capable of taking on tasks or projects of higher complexity.

Hypothesis:
Velocity gives us insight on measuring the team"s efficiency and capability accomplishing a target of story points.

Throughput:
The delivery rate; conceptually, this is the total work done by a team or an individual within a period of time. Here, work could be any task, milestone, feature or bug etc. Average throughput can also be measured. This metric helps to find out which department of software projects is getting their daily workload done mostly, whether, new features, support tickets or bugs etc. Analyzing the theories from the references, the average throughput is the threshold since it is the ideal delivery rate, so if the throughput is closer to average throughput then it shall define a higher delivery rate. Throughput can also give insight into the capacity planning of the team whether to adjust workload or not by measuring average throughput against current workload.

Hypothesis:
The closer throughput to the average throughput, the higher delivery rate it is.

Open Pull Requests:
These are the pull requests with status open under repositories waiting to be pulled by senior team members or managers. These requests stay there with this status until the code gets reviewed. Once the code is reviewed and necessary changes are made the requests are then put as closed. This metric can be measured from tools like GitHub.

Hypothesis:
Analyzing the theories, tracking Open Pull Requests may help in identifying bottlenecks as this impacts on iteration flow and throughput of a team or individual for any amount of work within a period of time. This may indicate whether the team requires additional time or resources in order to complete and deliver the current projects.

WIP:
Work in Progress metric gives us the number of how many tickets or works are currently in progress. An increasing WIP with a low Resolved Count means there must be some bottleneck in the process or the processes are inefficient. So, ideally, this number should be stable over timeline. On average, the number of WIP will be close to one to one ratio which suggests proceeding with one thing at a time.

Hypothesis:
This metric gives us insight of the team "s or individual"s capacity of handling current pressure or workload.

Cumulative flow:
This metric shows the time delivery, status of work from one state to another, the repeatability and the health of the process being followed for the development of the software projects. This shows whether there is a bottleneck in any state, this will be indicated when there shall be a stack of large number of tickets in that state. If tickets are stacked in Resolved state, not making it to Delivered state then it means there is a bottleneck at QA. So, ideally, the state to state transition should be smooth and stable to indicate a healthy process is being followed for the resolution of the existing workload. This metric can also show us tickets reverting back to the previous state which proves repeatability and needs to be noticed by the manager. This way work becomes predictable and easy to manage for maintaining a smooth working process.

Hypothesis:
This metric shows if there is bottleneck in any state that is hampering the regular workflow.

Lead time:
Lead time is from developing an idea of a software product or even the initialization of the development of software product to its output into delivery. This software metric may give an insight into the trend of our typical software delivery process, that whether to bring a change or not in it for a faster and more efficient delivery. Higher Lead time may require proper investigation. Lead time may also vary on other factors like resource count, velocity or even WIP. Variants in those factors may lead to variety in Lead time for any size of project.

Hypothesis:
Ideally, lower Lead time with high velocity or WIP proves fluency in responsiveness of software developers to customer demands.

Cycle time:
This is either by status or type. Cycle time per type means how long a bug or a feature took to transform from one status to another. Cycle time per status means how long a feature or a bug took in a particular state. How a particular module or a change in a module takes time and this time is called Cycle time. So, ideally, Cycle time may show us the turnaround time of a bug by measuring how much time it took to resolve it from open state to close state.

Hypothesis:
A hike in cycle time graph may help in identifying bottlenecks in that particular state, so we understand that it is time to take efficient steps in order to get back the quality in effort in that state.

Code churn:
Code churn represents the rate of lines of a code added, modified or deleted in the same file. Theoretically, software developer with lower churn is an efficient coder. Higher code churn will also result in missing deadlines, lack of quality and inefficiency as it resembles that the individual is probably struggling in providing efficient contribution in coding.

Hypothesis:
Code churn shows the efficiency of software developers.

MTBF:
From the theory of references, Mean time between failures is the mean time between consecutive failures of service or system. Theoretically, a higher MTBF rate is an ideal rate.

Hypothesis:
This software metric shows the consistency of software systems, whether operation and maintenance department need checkup or not.

Hypothesis:
Theoretically, high percentage of High priority bugs means, QA department is proving to be inefficient and this needs to be noticed.

Test Case Effectiveness:
This is analyzing the test cases written and run by QA engineers and finding out the effectiveness of them. This can be measured by the number of defects found by a particular test case run by the QA.

Hypothesis:
A higher effective test case will generate lower number of bugs but higher number of defects.

Conclusion:-
Utilizing the Software Quality Metrics should be a vastly adopted technique in many organizations for evaluating the performance of software developers and software QAs. These should not only be followed, but also KPIs can be set as a standard for utilizing the performance appraisal technique properly.
In this conceptual paper, such software quality metrics have been discussed and a comparative study has been conducted dividing them into two categories. One is for Software Developers and another is for Software QAs. For QA Engineers it matters how effective are the test cases with a low percentage of Bug Escape Rate. There is also other software quality metrics for QA Engineers like, High Priority Bug rate and Spent time. Utilizing these may result in bug-free delivered projects with an effective QA process.
For Software Developers, it matters how effectively and efficiently spent time is utilized by spending maximum time with high delivery rate touching all level of story points, that is, with a standard average velocity generat ing zero defects with lowest amount of code churn.
Maintaining an appropriate value of all the ACR, MTTR, MTBF, Percentage of Incidents, Front end loading and Back end response time are also a priority for ensuring a healthy software system.