Comparative analysis of UCP and SLIM methods to estimate the development of software products

This study is devoted to analysis different methods to estimate the software products development. The following most popular methods were selected for the study: Use Case Points and SLIM. The considered methods are algorithmic and are used in case of insufficient experience of the project team to use empirical calculation methods. A comparative analysis of these methods was also carried out based on calculating the forecasting error for IT projects for various platforms, such as a mobile device and a personal computer. The disadvantages of using the considered methods for developing applications for mobile platforms were identified. Based on the research results, it was concluded that today algorithmic methods for assessing labor intensity cannot give the best results and must be changed to adapt them to mobile software, considering its specific specifics, which makes it advisable to continue researching this industry in direction of mobile development.


Introduction
Software development is a rather laborious process [1]. Small projects can very easily be evaluated by an experienced project manager who has previously been involved in similar developments, and, as a rule, super-precision in such minor projects is not required. However, with the growth of software products, the issue of accurately predicting the duration and cost of software becomes more and more urgent. Inappropriate evaluation of the project can affect the success of the development, in particular, lead to its failure. Since the accuracy and reliability of labor intensity estimates are very important to the competitiveness of a company's software, enterprises and researchers have focused their best efforts on developing models for estimating the labor intensity of projects with the highest accuracy.
Dynamically changing technologies have led the economics of software engineering to create new assessment methods and evolve old ones. There are many methods of assessment that can be classified based on their formulation: expert judgment [2], estimates based on analogies [3], algorithmic methods (including empirical methods) [4], rule induction methods [5], approaches based on artificial neural networks [6], approaches based on Bayesian networks [7], decision tree [8] and estimation methods based on fuzzy logic [9]. Thus, it became possible to calculate the values most accurately, which made it possible to more adequately plan any forthcoming activity. Unfortunately, in software engineering, labor-intensive estimation is still not the preferred approach. Not all companies use methods for assessing the development labor intensity on an ongoing basis, preferring to rely on their previous experience, using measurement estimates, mainly as a method for additional verification. The refusal to use evaluations and analysis in practice raises an important question -whether the measurement process is generally applicable in software projects. In other branches of technology, scientific results and laws based on measurements are successfully applied in practice, giving valuable help engineering teams in managing their own projects. To determine whether an objective scientific approach can give sufficiently accurate indicators of labor intensity, we will evaluate several well-known methods of measurement and analysis, apply them on several real projects and determine whether these methods can take place in predicting the labor intensity of project development.
Another important question is whether software teams should use the same measurement method when analyzing applications developed for different platforms, or they should look for the most appropriate method for the chosen platform. It can also be challenging related to time, market, user interface constraints, power consumption, and network outages [10,11]. In practice, the development team is required to provide various evaluations throughout the entire project lifecycle. At the beginning of the project, some rough estimates are needed with minimal involvement and analysis.
At later stages of the project, more accurate and binding estimates are needed. In the open literature, various assessment methods of varying complexity are proposed. Hence, they provide different accuracy. But will this accuracy be the same when evaluating a mobile app or a personal computer app? The most effective way to assess the effort required is to correctly combine different measurement methods with different development platforms. Applying assessment methods to the "right" projects and at the right time points in the project life cycle allows for a continuous assessment process, where 3 the accuracy of the assessment converges to the desired value as the project develops. The purpose of this assessment is to develop a methodology for appropriate measurement methods for a software project.
Description of methods. Use Case Points methodology considers various criteria in the assessment, such as non-functional requirements, organizational risks, and so on.
The Use Case Points method was developed by Gustav Karner shortly in 1993. This method was developed based on use cases.
The following equation is used for calculations (1): where UUCP is a generalized weighting indicator; TCF is the technical complexity of the project; EF is the skill level of the developers. When calculating UUCP, it is necessary to determine the actors, divided into three types: simple, actors who use the system using a predefined programming interface (API), middle ones, who use more flexible APIs such as TCP/IP, and complex ones, which represent a person using a graphical interface (GUI) or web page. Each type of characters has a corresponding weighting coefficient: for simple -1, for medium -2, for complex -3.
Further, the use cases and their types are determined, each of which has a corresponding weighting factor: for simple -5, for medium -10, for complex -15. The value of the weighting factor is determined depending on the number of transactions in the event streams (main and alternative). In this case, a transaction is understood as an atomic sequence of actions that is completely executed or canceled.
UUCP is calculated using the following equation (2): where m is the number of use cases; n is the number of actors of a particular type; a is the weight of the actor; b is the weight of the use case.
To calculate TCF, each of the technical complexity indicators must be assigned a significance level in the range from 0 to 5. The TCF value is calculated using the following equation (3): where T is the significance of the indicator; Weight is the weight of the indicator. Indicators of technical complexity and their weights are shown in Table 1. When calculating EP, it is also necessary to determine the significance of each indicator of the level of developer skills; the indicators are presented in Table 2. Part-time employment -1 F8 Complex programming languages -1 After determining the values, it is necessary to calculate the result using the equation (4): where F is the significance of the indicator; Weight is the weight of the indicator. Next, using equation (3), we calculate the UCP, after which we convert this value into man-hours. To do this, it is necessary to select the Kucp coefficient, measured in man-hours, reflecting the standard adopted at a particular enterprise/firm.
The total complexity of development is calculated by the equation (5): In addition, this study uses the SLIM (Software Lifecycle Management) method. Of the techniques under consideration, SLIM was developed earlier than anyone else in 1978 by Lawrence Putnam. The development of the method was based on empirical data from software developments of the US Department of Defense. The model describes the time and effort required to complete a software project of a given size.
Putnam suggests that staffing levels rise smoothly during a project and then plummet during acceptance testing. The SLIM model is expressed as two equations (the programmatic equation and the labor force accumulation equation) that describe the relationship between development effort and schedule.
The central part of Putnam's model, called the program equation, is described by the equation (6): where Size is the size of the software product (the number of lines of code); C is the technological factor; E is the complexity of the project in person-years; t is the time of the project implementation in years.
The value of the technological factor C is usually in the range from 2000 to 12000 and is selected based on the following definitions: C = 2000 implies low development progress, which manifests itself in the absence of a methodology, incomplete (weak) documentation, and so on. C = 8000 assumes a reasonably good level of development. С = 11000 assumes a high level of development (use of automated tools).
The equation for E, the labor accumulation equation, is as follows (7): where D is a coefficient expressing the amount of required labor; t is the time of project implementation in years. The D value is determined depending on the type of project. If the software product is new and has a large number of interfaces and interactions with other systems, then D = 12.3. For stand-alone software products, D = 15. When reworking or changing an existing system, D = 27.
After carrying out the transformations, we get (8): Methods were tested on two real software projects: traditional PC application "Messages" -to improve the educational process of the Institute by automating the communication of the dean's office staff with students; mobile application "Kukla Theater" -to attract a new audience and thereby increase the volume of ticket sales.
The models proposed in this study may not be accurate enough to estimate future labor intensity. In order to improve the accuracy and reliability of the proposed methodologies, a certain criterion of accuracy was used, namely, the forecast error should be the smallest. The accuracy and reliability of the method is very important as it directly affects the success or failure of the project as a whole.
The number of lines of source code was predicted using the Function Points method [10,11].

Result
Calculations of the assessment of labor intensity for the implementation of the project aim to develop the module "Messages". Use Case Points: let us define the characters and their types: • User is a complex type.
• Administrator is a complex type.
Next, let us define the use cases: • User authorization -complex type.
• Choice of the addressee -medium type.
• Attachment of attachments -simple type.
• View message history -simple type.
• Search by messages -simple type.
• Add messages to favorites -simple type.
• Removing messages from favorites -simple type.
Calculations of the assessment of labor intensity for the implementation of a project to develop a mobile application for a puppet theater.
Use Case Points: let us define the characters and their types: • User -medium type.
• Administrator is a complex type.
• Use cases and their types: • User authorization -complex type.
• Viewing the latest news -simple type.
• Viewing the schedule -simple type.
• View events -simple type.
• View information about the theater -simple type.
• View Theatre contacts -simple type.
• Going to the theater group on the Vkontakte / Instagram / Facebook site is a simple type.

Conclusion
The low effectiveness of the SLIM method on these projects is due to its focus on larger projects containing more than 70,000 lines of code and the fact that it is expected that evaluation using SLIM will not be carried out before design and coding. This model assumes that effort for software projects is distributed similarly to the collection of Rayleigh curves, but this relationship has not been confirmed in projects with a small project team and a small amount of work. Such a high error rate is not uncommon for this method, as was shown in a study by Chris Kemerer [12,13].
In the modern world, technologies are rapidly developing, becoming more complex and diversified. Based on the research results, it can be concluded that, since the most popular algorithmic methods for assessing labor intensity appeared before the creation of mobile platforms, today they cannot give the best results. Moreover, they must be changed in order to adapt them to mobile software with considering its specific specifics [14][15][16], which makes it advisable to continue researching this industry in the direction of mobile development.