KNOWLEDGE BASE IN SOFTWARE PROJECT ESTIMATION
MAREK MIŁOSZ, MAGDALENA BORYS
Summary The focus of this paper is to present the idea of knowledge base in software project estimation process. It begins by covering the importance of estimation in IT project lifecycle. There are presented selected software estimation methods: Function Points, Use Case Points, Story Points. The paper points the place of knowledge base in an estimation process and shows benefits of using it. The Authoring Tool for Software project Effort Estimator (ATSEE) is presented. Keywords: software project, estimation methods, knowledge base 1. Introduction An estimation is a prediction of project cost and duration. In software projects the estimation also interacts with business objectives, commitments and control. It supports planning activities such as creating a schedule, prioritizing software requirements, identifying the project critical path, creating software development team. Table 1. Software project success statistics categorized by project size in Function Points Project Size [FP] 1 10 100 1000 10000 100000 Avg.
Early delivery [%] 14.7 11.1 6.1 1.2 0.1 0 5.5
On-Time [%] 83.2 81.3 74.8 60.8 28.0 13.7 56.9
Delayed [%] 1.9 5.7 11.8 17.7 23.8 21.3 13.7
Canceled [%] 0.3 2.0 7.3 20.3 48.0 65.0 23.8
Source: [12]. Software estimation has been the center of attention since the late 1970s [1, 2, 6]. The literature contains large amounts of data that show projects statistics in the dependency of project attributes. Tab. 1. presents the dependence of project success on its size. It clearly indicates that with software complexity and scope increase the chance for project failure. Therefore, nowadays when most of IT projects is complicated and on large scale, selecting the estimation method addressing all project needs and conditions is essential to proper project development and management. [5, 16, 19] But not only an estimation method should be selected carefully. The software estimation should be planned as a lifecycle process starting at project initiation, designing, ending up with project closure stage.
194
Marek Miłosz, Magdalena Borys Knowledge base in software project estimation
2. Importance of estimation Most estimation methods start by estimating software size using various units to estimate effort. From effort, other attributes like staffing, schedule, cost and functionality – maximum feature richness for available project constrains, are derived. [15] Accurate estimates produce additional benefits for project. Firstly, reliable estimate helps work out realistic project plan and thus provides the support for project progress control. It helps avoid schedule-related stress quality problems by placing less pressure on developers. Schedule pressure is one of the most significant cause of extremely costly error-prone parts of software. [12] Accurate estimate provides better budgeting. It is crucial in reducing uncertainty and risk early in project. Additionally, the project estimation significantly supports and enhances decision making process, helps to optimize value creation and meet business objectives. Besides the advantages, the estimation has also its limitations. Estimation is probabilistic and the size of its uncertainty differs based on project phase. The core source of estimation error are [5, 15]: – inaccurate information about project, – inaccurate information about the capabilities of the organization performing project, – chaotic development process, – inaccuracies arising from the estimation project itself. 3. Software project estimation using functional metrics To measure the size of the software, two basic types of metrics can be used [21]: quantitative and functional. Quantitative metrics operate on measurable and countable units associated with the software. This is usually a number of lines of code. Functional metrics operate on the conventional measure units due to the functionality supplied by the software. These metrics assess the size of the software based on its serviceable features. Thus they are oriented on the system users and their needs. Measures of these metrics are Function Points, Use Case Points, Story Points. Function Point (FP) is artificial metrics used in the Function Points method. The Function Points method has been developed to estimate the non-existent, designed system. [1] The Function Points method estimates impact of each parameter on the system size and imposes estimated impact of the project implementation conditions on that assessment. The identified in that way Function Points are treated as a measure of development team productivity, and at the same time as a measure of the application complexity. The model used to designate the Function Points based on the traditional, essentially structural, approach to the system requirements specification. The Function Points method allows estimating the project complexity taking into account the two different groups of factors [1, 8, 13] (fig. 1): 1.
Elements of information processing in the system. These elements are: external inputs and outputs, internal logical files and external interface files, queries to the database. They are
195
Studies & Proceedings of Polish Association for Knowledge Management No. 53, 2011
2.
grouped in the sets with estimated separately weights and summed up quantities against the weights. This weighted sum is the Unadjusted Function Points (UFP). A comprehensive assessment of the system complexity and the conditions of its implementation as a variety of the correction factors making up the Value Adjustment Factor (VAF). The correction factors are determined using scale of six for the system as a whole, without going too much into its internal structure.
Figure 1. Software application diagram in the Function Points model Source: [17]. The classic Function Points method makes out the adjustment factors. [8, 16] The combined impact of the correction factor takes into account the Value Adjustment Factor, which is simply the sum of the impact estimation of each factor. The Function Points method is focused on the functionality of the system and is independent from the programming language, development methodology, technology or the ability of design groups involved in the application development. This method is used in different types of projects, such as. [11, 13, 14, 22] The evaluation method of its individual elements prevents the algorithmization, thus automating the designation of Function Points. This method is also strongly associated with a structural approach to the design of systems. An advantage of the Function Points method is its large collection of statistical data supporting the use of the methodology in practice. The Use Case Points method (UCP) is derived directly from the idea of the Function Points method. [10, 18, 20] To estimate the software size, this method uses the Object Oriented model of the application specification – the Use Case model assisted by scenarios and sets of Business Class Models. [16] The UCP method uses two projects artifacts: actors and use cases. Determined by them the software size is then adjusted by taking into account the different conditions for its implementation. The actors and use cases for the estimated project are classified by the complexity scale of three as: easy, medium and complex. The complexity of each use case is assessed based on the number of transactions, unit and indivisible operations, pursuing the use case or the number of analysis class, which fulfill the case.
196
Marek Miłosz, Magdalena Borys Knowledge base in software project estimation
The UCP method, similar to the Function Points method, determines the Unadjusted Use Case Points (UUCP). Then the number of UUCP is adjusted by two correction factors [14, 18]: 1. Technical Complexity Factor (TCF) defines the impact of project development environment complexity on the number of UCP. 2. Environmental Factor (EF) takes into account the impact of the organizational aspects on project complexity. Estimated quantity of UCP is then converted into the working hours. The industrial values of 1 UCP effort are within 15–30 working hours. [19, 20] The undoubted advantage of this method is possibility of making the estimation at the stage of functional requirements collection. Unfortunately, the lack of a structured pattern of use cases is a problem. Another difficulty is fact that this method based on the coefficients assessed by the users. Proper calibration of environmental and technical factors and determination of the size of the transaction are essential for accurate estimation – even minor differences in the assessment can cause a large increase of the final estimation. Used in Agile methodology estimation methods are based on the technique of estimation by analogy. One of these methods uses the Story Point as the unit to express the total size of User Stories, or the another part of the project functionality, i.e. the themes and epics. There is no formula to describe a set of values assigned to the stories in Story Points method. However, the set should present a scale representing the effort of its development, a result of such values as: complexity, technological uncertainty, risk and other factors connected with given element. Used scales should be within one order of magnitude. [7] Most common are the following two scales: [7] – 1, 2, 3, 5 and 8, that is Fibonacci sequence; – 1, 2, 4 and 8, that is power of 2. During size estimation it possible to use 0 value to mark elements requiring narrow effort. In case of using epics and themes for estimation, successive values should be added to scale by appropriate pattern or chosen values. Knowledge of a project team (or teams) velocity is necessary to estimate the parameters of the project in Agile methodologies. The velocity is a measure of a team’s rate of progress; it is calculated by summing the estimations assigned to each features delivered by the team during single iteration.
197
Studies & Proceedings of Polish Association for Knowledge Management No. 53, 2011
Figure 2. Project estimation schema in Agile methodologies When the velocity and a project size are known, the duration of the project, as a number of iterations, could be calculated by dividing a sum of all features estimations by team velocity (fig. 2). Thus, knowing the effort single SP (calculated based on velocity and on the number of executed SP) it is possible to obtain the whole project effort. The advantage of this method is independence of the size estimation from the effort estimation, although the same values are linked. The effort estimation is obtained from calculations; therefore, errors can be quickly corrected by an team efficiency ratio. 4. Model of software project estimation process with Knowledge Base Independently of used method, estimation always involves a calibration. The calibration is used to convert the calculated size of the software, usually defined as the number of line codes, the Use Case Points or other units, for the project effort. The calibration can be performed using the following data [15, 16]: – industry benchmarks, – historical data of previous projects carried out within a single organization, – project data collected in earlier stages of the project, – software engineering experts knowledge. Unfortunately there are no convincing indications of obtaining accurate forecasts of effort. Teams working in the different conditions have different experience, technological assistance, access to resources, etc. And technology is changing so fast that no models are able to keep up with these changes.
198
Marek Miłosz, Magdalena Borys Knowledge base in software project estimation
However, the accuracy of dimensioning with all models can be significantly improved if the Knowledge Base with the previous project data is available, as well as expertise of software engineering experts (SE Expert in fig. 3). The Knowledge Base, containing carefully documented projects data – recorded lesson-learned, enables to draw on collected knowledge and refine its estimating process and the accuracy of the estimation over time, giving the organization a competitive edge. Developing and maintaining the Knowledge Base will improve the process of estimating effort of the new systems. The position of such a system presents fig. 3.
Figure 3. Schema of the Knowledge Base supporting the project estimation The idea of the Knowledge Base can be also enriched by statistical methods as well as machine learning methods [3, 4, 9] and gaining experts knowledge. 5. ATSEE – Authoring Tool for Software project Effort Estimator A tool named Authoring Tool for Software project Effort Estimator (ATSEE) [17] is a platform for data storing, calculations and presentation of project effort estimation. It was built using Microsoft Office Excel. The ATSEE based on the Function Point method (see point 3 and fig. 1) and realizes the processes of Assessment of Productivity Attributes and Software Size Measure (fig. 3). It can be use to collect the data as a part of the Knowledge Base (fig. 3). It includes the sheets like: External inputs, External Outputs, Internal logical files, External logical files, Inquires to date base, which enable taking into consideration the particular elements of data processing in the system. Additionally, the workbook contains the sheet with adjustment factors, which makes possible to include the aspects of system complexity and conditions of its realization. The last sheet named FPs presents the results of effort estimation (fig. 4). The content of this sheet is divided into three parts.
199
Studies & Proceedings of Polish Association for Knowledge Management No. 53, 2011
The first part includes the table with information about value of counted Function Points. The table consists the following data: – the unadjusted Function Points (UDF), – the Total Degree of Influence (TDI), – the Value of Adjustment Factor (VAF).
Figure 4. The view of ATSEE sheet named FPs The second part includes two tables – one table presenting effort estimation measured in man hours without an calibration for the analysis phase, realization phase, testing phase and for a whole project; and one presenting the value of effort with the calibration factor. This factor is a characteristic for the given IT company and is defined on the basis of historical data obtained from previously estimated software projects. The calibration factors are inserted by the expert for each phase separately. The third part presents the table with effort evaluation according to industrial standards. In this table the value of productivity is calculated using formula, which defines the dependency of productivity on size of the project measured in FPs. The formula was obtained as a result of mathematical data processing using Matlab statistic toolbox. Having the amount of men working hours, the total effort is calculated and displayed. Similarly to the second part of sheet named FPs, it is possible to calibrate the effort according to industrial
200
Marek Miłosz, Magdalena Borys Knowledge base in software project estimation
benchmarks using calibration factor. The cells that include the value of this factor are one and only which can be modified in this sheet. All worksheets dedicated for data entering have the appropriate protection, they reduce the possibility of user error significantly. The worksheets also have the hints concerning the proper data selection in an estimation process (fig 5).
Figure 5. Help system in the ATSEE tool 6. Using the ATSEE tool The ATSEE tool supports the expert’s activities in following phases of Function Point method usage scenario (fig. 6): determination of the number of files and its complexity, determination of the number of functional elements and its complexity, calculation of VAF, implementation of FP and productivity calculation. Its usefulness is visible also in phases: Verification, Report, review meeting thanks to the legible form of results presentation.
201
Studies & Proceedings of Polish Association for Knowledge Management No. 53, 2011
Figure 6. The Function Point method and ATSEE tool using scenario The ATSEE tool was built as a help for experts who are involved in effort estimation of software projects. It is very useful tool created in spreadsheet environment, which ensures: – estimating effort using Function Points method, – collecting data characterized software projects in informative and functional aspects, – standardizing the data collected for future use, – automation of data processing that leads to fast effort estimation of project, – protection against human mistakes during data insertion, – presentation of the final effort and productivity with accordance to industrial productivity in form of report. The presented ATSEE tool is an example of a system for project data collection, which can be used for creating Knowledge Base. It shows how project data collection enables IT company to draw on historical knowledge and refines estimating process as well as the accuracy of the estimates over the time. 7. Conclusion The presented issues on software estimation proves that parametric models are insufficient for proper software effort estimation and the problem must be handled using an evolving system such as Knowledge Base. In Knowledge Base, the IT company experience in software effort estimation using parametric model should be represented. This experience is transformed into knowledge, which can be used in next software projects to enhance the accuracy of estimation under definite conditions of software project realization. Other problem is to develop the dataset in way that will reflect the software development characteristics like technology and methodology changing, as well as organizations development.
202
Marek Miłosz, Magdalena Borys Knowledge base in software project estimation
Bibliography [1] Albrecht A. J., Measuring application development productivity. Proc. of IBM Applications Development Joint SHARE/GUIDE Symposium, Monterey, CA, USA, 1979, pp. 83–92. [2] Anda B., Benestad H. Ch., Hove S. E., A Multiple-Case Study of Software Effort Estimation based on Use Case Points. Empirical Software Engineering (ISBN, 0-7803-9507-7), 2005. [3] Baldassarre M.T., Boffoli N., Caivano D., Visaggio G., SPEED, Software Project Effort Evaluator based on Dynamic-calibration. 22nd IEEE International Conference on Software Maintenance (ICSM'06), IEEE 0-7695-2354-4/06, 2006. [4] Bakele B., Turhan B., Bener A., Software Effort Estimation Using Machine Learning Methods. ICTAI '07 Proceedings of the 19th IEEE International Conference on Tools with Artificial Intelligence – Volume 01, IEEE Computer Society Washington, DC, USA, 2007, pp. 181–185. [5] Boehm B., Horowitz E., Software Cost Estimation with CoCoMo II. Prentice Hall, N.J., USA, 2000. [6] Boehm B., Software Engineering Economics. Prentice Hall, N.J., USA, 1981. [7] Cohn M., Agile Estimating and Planning. Robert C. Martin Series. Prentice Hall PTR, 2005. [8] Counting Practices Manual. Release 4.2. IFPUG, August 2004. [9] Czarnacka-Chrobot B., Wymiarowanie funkcjonalne przedsiĊwziĊü rozwoju systemów oprogramowania wspomagających zarządzanie na bazie uogólnionych danych historycznych. Studia i Materiały Polskiego Stowarzyszenia Zarzdzania Wiedz nr 23, red. W. Bojar, R. Budziski, A. Januszewski, A. Straszak, Polskie Stowarzyszenie Zarzdzania Wiedz, Bydgoszcz 2009, pp. 28–40 (in Polish). [10] Fetke T., Abran A.. Tho-Hau N., Mapping th OO-Jacobson Approach into Function Point Analysis. Technology of Object-Oriented Languages and Systems, TOOLS-23’97. IEEE, Santa Barbara, USA, July 28- August 1, 1998, pp. 192–202. [11] Gupta D., Kaushal S.J., Sadiq M., Software estimation tool based on three-layer model for software engineering metrics. ICMIT 2008, 4th IEEE International Conference on Management of Innovation and Technology, 21–24 Sept. 2008, pp. 623–628. [12] Jones C., Patterns of Software Systems Failure and Success. International Thomson Press, Radnor, PA, 1996. [13] Kusumoto S., Inoue K., Kasimoto T., Suzuki A., Yuura K. Tsuda, M., Function point measurement for object-oriented requirements specification. The 24th Annual International Computer Software and Applications Conference, COMPSAC 2000, 25–27 Oct. 2000, pp. 543–548. [14] Kusumoto S., Matukawa F., Inoue K., Hanabusa S., Maegawa Y., Estimating Effort by Use Case Points, Method, Tool and Case Study. Software Metrics. 10th International Symposium on METRICS’04, Chicago, USA, September 11–17, 2004, pp. 292–299. [15] McConnell S., Software Estimation. Microsoft Press, Washington, USA, 2006. [16] Miłosz M., Borys M., Software Project Effort Estimation Methods Comparison, Varia Informatica 2009, PIPS, 2009, Lublin, Poland, pp. 163–184. [17] Miłosz M., Muryjas P., Borys M., Plechawska M., ATSEE, the Authoring Tool for Software Project Effort Estimator Based on Function Points Method, Varia Informatica 2009, PIPS, 2009, Lublin, Poland, pp. 185–210.
203
Studies & Proceedings of Polish Association for Knowledge Management No. 53, 2011
[18] Miłosz M., Punkty przypadków uycia w szacowaniu projektów informatycznych. In, Współczesne Technologie Informatyczne. Inynieria oprogramowania, systemy baz danych. Eds., M. Miłosza, P. Muryjasa. MIKOM, Warszawa, 2005 (ISBN 83-7279-487-1), pp. 17–32 (in Polish). [19] Miłosz M., Szacowanie obiektowych projektów informatycznych. Informatyka i efektywno systemów. Eds., M. Goliskiego, J. Grabary, J. Nowaka, PTI, Katowice, 2005, pp. 149–160 (in Polish). [20] Smith J., The Estimation of Effort Based on Use Cases. Rational Software white paper, Rational Software, 1999. [21] SWEBOK – Guide to the Software Engineering Body of Knowledge. IEEE, Los Alamitos, USA, 2004. [22] Uemura T., Kusumoto S., Inoue K., Function point measurement tool for UML design specification, Proceedings on Sixth International Software Metrics Symposium, 4–6 Nov. 1999, pp. 62–69. BAZA WIEDZY W SZACOWANIU PROJEKTÓW PROGRAMISTYCZNYCH Streszczenie Celem artykułu jest przedstawienie idei zastosowania bazy wiedzy w procesie szacowania projektów programistycznych. Na początku przedstawione zostało znaczenie szacowania projektu informatycznego w jego cyklu Īycia. Zaprezentowane zostały metody szacowania, takie jak: metoda punktów funkcyjnych, metoda punktów przypadków uĪycia oraz punktów historyjek uĪytkownika. Przedstawiono miejsce bazy wiedzy w procesie estymacji projektów oraz wskazano na korzyĞci wynikające z jej uĪycia. Zaprezentowano takĪe autorskie narzĊdzie wspomagające proces szacowania pracochłonnoĞci wytwarzania oprogramowania (ATSEE). Słowa kluczowe: projekt programistyczny, metody szacowania, baza wiedzy
Marek Miłosz Magdalena Borys Institute of Computer Science Faculty of Electrical Engineering and Computer Science Lublin University of Technology ul. Nadbystrzycka str. 36B, 20-618 Lublin, Poland email:
[email protected] [email protected]
