Современные информационные технологии/ 3.Программное обеспечение

Monchak M., Bilas O.

Lviv Polytechnic National University, Ukraine

Project documentation metrics adaptation for Scrum development methodology

Abstract - Indicators and metrics of quality documentation in the lifecycle model of Scrum development process are considered. Adaptation of the project documentation quality metrics for agile development methodologies are carried out to improve the quality of the software.

Metrics of software quality should not be considered absolutely, the overall result of this assessment should be regarded as information for analysis. Process improvement and application of relevant metrics are recommended as results.

I. Introduction

During requirements for the software system determining external characteristics and attributes that define various aspects of the behavior of the product in a specific environment are relevant. To assess the characteristics of the quality of the software system mentioned in the requirements determined by the appropriate metrics, models of their estimation and range of measures for measuring individual quality attributes are used [1].

Working and quality product is the main metric of widely used agile development methodology [2]. Preferring direct communication, agile reduce the amount of written documentation in comparison with other methodologies. In Scrum methodology documentations are in the form of user stories, tasks, and retrospectives.

Scrum documentation is updated after the end of the iteration and reflects the degree of implementation of tasks and testing [2]. Analyzing of design documentation metrics and documentation of Scrum methodology identified the need in sophisticated set of metrics for a more complete assessment of the design documentation in Scrum projects. Adaptation of existing classic quality metrics for Scrum methodology is purposed to carry out.

II. Model of quality metrics for Scrum development methodology

Software quality metrics is a function of inputs which are the measured data of software process or product, and the output is a numeric value that can be interpreted as a degree, which possesses the attribute of the software that affect its quality [3].

To develop or refine a set of metrics for Scrum projects, we need to create a list of quality factors that are needed to determine for quality of design documentation.

Scrum documentation is updated after the each iteration finish and reflects the degree of tasks and testing fulfillment. The obtained data contribute to the documentation that assesses the quality metrics of project documentation [4].

2.1 Definition and adaptation documentation metrics for Scrum projects

2.1.1 Accuracy

Defect density of the sprint. Defect density is calculated after each new design description verification (inspection) in the sprint or after the end of sprint.

Primitives:

D - total number of defects

Di - total number of defects detected during the inspection of the sprint

I - total number of inspections

DS - number of source lines of the sprint design goals, expressed in thousands

Defects density can be calculated as:

(1)

Defect density of the sprint can also be measured as

(2)

Accounted for every defect in the later stages, which is a defect of the sprint. The result can be shown as a histogram of the defects density of sprints.

Fig. 1 Histogram of the defects density

2.1.2 Modularity

- Metric integrity to sprint. Integrity or “strength” features associated with sprint points out the relation between elements of features. Values integrity for sprint’s assigned using a standard appraisal chart. The highest level of integrity is a functional level, and the worst is occasional.

Sprint with high strength (functional) performs a single function. Sprint with low strength (random) includes several unrelated functions. Analysis has shown that sprints with high strength, tend to have lower rates of defects, and they are cheaper to develop. According to sprints with high strength modularity is higher.

Toughness is a measure of integrity degree of software module elements.

Calculation of strength:

(3)

where:

X - reciprocal of the number of assignment statements in the sprint

Y - number of unique results of function divided by the number of unique input.

- Connectivity descriptions metric within iterations. Connectivity is measures of the degree for which the functions are implemented in the sprint communicate. Connectivity descriptions can be evaluated using standard evaluation chart. The connectivity data is the best type of connectivity, while the connectivity of the content is the worst.

The connectivity data is data exchange through the options list, while the overall connectivity is in communication through the global (total) area. In the previous guidelines stated that total connectivity should be avoided. But further research showed that error distribution does not depend on the mechanism of connectivity. However, from the modularity point of view and independence descriptions from external factors, value of connectivity should be lower.

Calculation of connectivity:

(4)

where:

Mj - total number of input and output elements distributed between components i and j

Zi - average number of input and output elements distributed between the m components of component i

n - number of components in the software description.

After examining the connectivity descriptions within iterations need to explore the overall coherence of the sprint project.

2.1.3 Clarity

- Metrics of volume. Studding the effect of module size on modularity (and therefore reusability) was made during the research. Module size of itself does not affect the bounce rate. In addition, the cost of large modules per executable statement is less than for a smaller module. This suggests that the rows number of the project and code is not a good indicator of modularity. However, when it’s used with other metrics (complexity, etc) metric size can be an indication that the module should be split on smaller modules. The following metrics can be considered as metrics of volume:

• Number of project sprints

• Number of records on one sprint

• Number of lines of code document

• Number of functions

• Number of inputs and outputs

• Number of interfaces

- Complexity metrics

1. External complexity (D_e) is based on information available during the design of solution architecture, such as hierarchical data flow diagrams, functional descriptions and interfaces.

Calculation of external complexity:

(5)

where:

iflow - number of data entities passed to the function descriptions

oflow - number of data entities sent from the description of the functions

fan-in - number of parental descriptions directly related to the description

fan-out - number of child descriptions directly related to the description

e1 and e2 weight coefficients.

2. The internal complexity of the sprint (D_i) is based on information available after detailed design descriptions, including information that is used for external complexity plus selected algorithms and possibly pseudo-code or view the design language.

Calculation of internal complexity:

(6)

where:

CC (central call - Central calls) - number of calls to procedures or functions

DSM (data-structure manipulation - manipulation of data structures) - the number of references to complex data types

I/O - number of calls to external devices

i1, i2, i3 – weights.

For the optimal sprints planning determination of the descriptions number in the sprint are needed and the size of descriptions depends on the objectives of the sprint, so it can be made in a certain time and resources.

Conclusion

Examining metrics of project documentation standards revealed that the selected metrics can be useful for evaluating documentation according to agile development methodologies. Design documentation metrics can be adopted for Scrum projects after their analysis.

The metric of sprint defects density is calculated after the finish of the sprint and reflects the quality of software code.

The integrity metric of the sprint points to the relationship between elements of the functions associated with sprint. Studies have shown that the features of high strength, tend to have lower rates of defects, and they are cheaper in the development. Therefore, sprint with high strength modularity is better.

The metric of connectivity in Scrum projects are useful for determining the connectivity of the descriptions and how they communicate, as well as connectivity descriptions between sprints. Connectivity descriptions can be evaluated using standard evaluation chart. The connectivity data is the best type of connectivity, while the connectivity of the content is the worst.

During the research was identified that it is necessary to extend the set of metrics of volume because they can be an indication that the description can be divided into smaller.

Complexity metrics used in Scrum projects to measure the complexity of the architecture of the software product, represented by a set of descriptions that is useful for analysis of the project.

References

[1] Boheme B., Brown J., Caspar H. (1981), “Characteristics of software quality”, Mir, p. 206.

[2] Agile Modeling [Electronic resource] - Mode of access: http://www.agilemodeling.com/essays/agileDocumentation.htm/

[3] Stephen Kan (2003), “Metrics and models in software quality assurance (2nd edition)”, Addison-Wesley Professional, p. 520.

[4] Monika Agarwal, Rana Majumdar, “Tracking Scrum projects Tools, Metrics and Myths About Agile”, International Journal of Emerging Technology and Advanced Engineering,рp. 97-104, March 2012.