Embed Size (px)
Citation preview
A novel tool for cost estimates of software
developments based in IFPUG and COCOMO II metrics.
A. Ramírez Ramírez IPN_CIC,
Master graduated in computer science at the Research in
Computing Center in the I.P.N. Zacatenco D.F. Mexico.
S. D. Orantes Jiménez IPN_CIC.
Full time professor at the Research in Computing
Center in the I.P.N. Zacatenco, D.F. México.
Abstract: This session discusses the importance of the treatment
and storage of statistical data from the cost estimates in a
software Project and the proposal to use such data in a tool that
merges the metrics most used in the field of Software
Engineering, as they are the COCOMO II (COnstructive COst
MOdel) and IFPUG (International Function-Point, Users Group)
this latter known as metric of function points. Both models face
an important issue for the software industry, which is precisely
the cost estimating. With the use those methodologies is possible
to guarantee to developer and user that the project is being
carried out under certain canons of efficiency and quality. As
result of this research, is present a new option that combines
elements of these different metrics and enhances results of these
separate methods. This new tool is named COCOMO and
Function Points Software (COFPSW), and was developed under
a practical Software Engineering focus.
Keywords: COCOMO II, IFPUG, Cost Estimating, software
metrics, software engineering, COFPSW.
I. INTRODUCTION
In Mexico and in some countries of Latin America, the creation and development of software is usually carried out by independent agents because of the weak integration from a software industry as such. This leads to low compliance with the guidelines and appropriate techniques to enable developers to obtain a quality product. In addition to this, is largely ignored the evaluation mechanisms that exist in other parts of the world, as well as the standards and guidelines for the management of software projects.
Companies that have managed to overcome and who understand the importance of implementing development models which exist or at least try to follow routes appropriate Software development, must know that the safest for business, is to engage first internally with the correct implementation of a cycle of constant evaluation, that enables them to establish the levels of sufficient efficiency and as a result will be possible to reach their goals. In this way these companies will be able to fulfill their contracts and survive economically.
Therefore methods of monitoring and evaluation of the procedures within the terms of the software engineering should be considered as important as the same encoding, because that with these controls and metrics can be faster and better the objectives which it pursues, which is achieving a manner ordered, and tested set of generating computing applications.
II. APPROACH:
From diverse methodologies and measurement standards than exist, one of the most popular, is the widespread by the IFPUG (International Function Point Users Group) and is known as the metric of function points, it was defined by Allan Albrecht, [1] IBM, in 1979 and is considered a method to measure the size of the software, often used in software engineering, aims to measure the functionality delivered to the user regardless of the technology used for the construction and operation of the software. According to its methodology, it is possible to use it throughout the lifecycle of the software
This method of points function is based on the two components intrinsically related in all system information; on the one hand the volume of information handled by the system and on the other the degree of technical difficulty that could represent the end user, this information. Face that, this method proposes to classify these relationships in five different types or degrees of complexity among them. One hand are the logical external, these are the inputs, outputs and search; on the other hand the internal logic, consisting of the system files and finally Interfaces to and from other systems.
Relations between the logic of the software components
provide or receive a score and depending on their complexity
are classified into "simple", "average" and "complex" giving
rise to the functions or "function points" as shown in Table 1,
these adjustable points can apply you a tab to get an
"adjustment" that has to do with certain aspects and factors of
different encoding which faces the programmer regardless of
the programming language that has decided to use.
TABLE I. ADJUSTABLE FUNCTION POINTS COUNTING.
One of the most used is the COCOMO II model [4] which was
created as the adaptation of the successful model COCOMO to
new systems, tools and techniques of development. Using the
basis of his predecessor, COCOMO II implements new
Depict Function: Level Information Processing Total
Simple Average Complex
Inner Class __ * 3 = __ __ * 4 = __ __ * 6 = __ ___
External Cl. __ * 4 = __ __ * 5 = __ __ * 7 = __ ___
Internal Files __ * 7 = __ __ * 10 = __ __ * 15 = __ ___
Interfase Files __ * 5 = __ __ * 7 = __ __ * 10 = __ ___
Consultas __ * 3 = __ __ * 4 = __ __ * 6 = __ ___
Total of Adjustables Function Points:
IPN--Conacyt
concepts to fit most estimate the characteristics of the projects;
this is what defines three sub estimation models:
Composition of applications: used for estimates in the
early stages of the life cycle of a software project.
Advance design: prepared for systems design,
produces estimates as reliable as the degree of
progress has been achieved in the design of the
application.
Post-Architecture: Used for completely designed
systems and as a prelude to the start of the stage of
development, as well as for the follow-up to the effort
invested in the development of the product.
With respect to the previous model, they have also included
new "cost drivers" and removed some others of which
employed. Also and due process of the new computers
capability, calibration tools allow tighter results and manage
databases for larger projects. This way the formulas proposed
by the COCOMO II model are much more reliable. In addition,
the classification of the mode of development in organic,
semi-free, or rigid, is now more complex form with base on
some factors of scale:
Precedence: experience in applications of the same type.
Flexibility of development: degree of subjection of
development times and requirements.
Resolution of architecture and risk: identification of risks
in the application.
Team cohesion: level of integration of the development
team.
Maturity of the process: experience in the development
model.
According to the first model of COCOMO, this evolution also handles the ranks of constants to be used for evaluations with the rest of the variables depending on the type of development that is forecasting, considering the values of Table 2 for the basic model.
TABLE II. ADJUSTABLE FUNCTION POINTS COUNTING.
Will must calculate the effort necessary to end the project, either the time spend showing on PM (person / month) required from Size (size) and E (estimated effort), as shown in 2 and 3, where A and B, are corresponding to the factors of effort multipliers. (COCOMO II 2000), and applied on SF influence factors.
∏
(1)
∑
(2)
The key inputs of the model are Software Size, five Scale Factors and 17 Effort Multipliers (Cost Drivers). The Scale Factors and Effort Multipliers are listed in Table 3. The exponent E in the above equation is an aggregation of five Scale Factors to capture the relative economies or diseconomies of scale encountered for software projects of different sizes [9].
In this way may be an analysis cost-benefit on a software development, an analysis of the influence of all the factors involved in the creation of the product, the project itself or the environment on the production of the same software. Hence, estimation techniques are important because they provide the essential part of good management of projects. Without an acceptable ability to estimate software, projects could be subject to the following problems:
• The programmers do not have a firm foundation on which build to say to your client or employer, that the time and resources that have been awarded to finish the product are sufficient or if unrealistic.
• Mexico’s software analysts, commonly have no way of testing a reliable Exchange of parts hardware-software during the design phase of the system. This could be cause of a design in which the performance of the hardware is below expectations due to software that has cost more than was estimated.
• The project managers do not know how to estimate the time and effort entailed in each phase and activity during the development of a specific project.
Scale Factor Effort Multiplier
Precedency (PREC) Development Flexibility (FLEX) Architecture/Risk Resolution (RESL) Team Cohesion (TEAM) Process Maturity (PMAT)
Product: Required Software Reliability (RELY) Database Size (DATA) Product Complexity (CPLX) Developed for Reusability (RUSE) Docum. Match to Life Cycle Needs (DOCU)
Personnel: Analyst Capability (ACAP) Programmer Capability (PCAP) Personnel Continuity (PCON) Application Experience (APEX) Platform Experience (PLEX) Language and Tool Experience (LTEX)
Project: Use of Software Tools (TOOL) Multisite Development (SITE) Required Development Schedule (SCED)
Platform: Execution Time Constraint (TIME) Main Storage Constraint (STOR) Platform Volatility (PVOL)
III. OBJECTIVE:
Considering the software Engineering and software cost estimation refers to the assessment of the likely amount of effort, time and staffing levels required to build a software system. The most helpful form of effort estimation is the one made at an early stage during a project working primarily from feasibility and requirements specifications documents. However, estimates at the early stages of the development are the most difficult to obtain and they are often the least accurate, because very little detail is known about the project and the product at its start. However the software Engineering has been very important because of next aspects:
The software increasingly necessary to be more specific.
The software is becoming increasingly more expensive.
Software needs to be freed in less time, on pain of falling into obsolescence.
The software is increasingly a major impact on the well-being of the human being.
One might think that we are still designing hardware as the "black box" containing the software, what determines the cost of an information system to be the same hardware. However, the increase in demand for computer programs that are easier to use, ever is a great challenge for the software engineering, first, because it significantly increases the productivity in software development, on second place, because it increases the need for and effectiveness of the maintenance software.
IV. DEVELOPMENT
The proposal is to develop a tool that allows the user to establish the scope of the draft, establish goals and objectives of the project, this application must also suggest or allow the user to enter strategies, policies and procedures to achieve them; all of this, by combining both main methods of measurement which are COCOMO II and IFPUG, to aid in the planning of a new Software development project. This tool should:
• To establish an environment friendly and understandable.
• It offers choice between two proposed method-ologies.
• Must delimit the tasks or activities of the software.
• Allow login resources estimate (hardware, software, personnel, etc....)
• Allow to choose the value for different variables, in defined ranges.
• Provide the user with a prediction based on a probabilistic model (not deterministic) can the user proposing different values whereas the objective of the estimate, reduce costs and increase levels of service and quality aspects.
As a result of these options must obtain information to establish:
• The human effort required to complete the project.
• The time to be taken (even changing the number of staff).
• The cost total project (breakdown of important).
The systems engineer may avail themselves of this application only if you know how to develop their activities even without recourse to any. In Figure 1 is shown in summary, an abstraction of the elements that make up the application, as soon as the user interacts with it.
Figure 1. UML representation of the app.
The module three of the tool, apply the proposed method called COFPSW, it is basically a scheme that takes the Function Points metric obtained by the number of lines of source code (SLOC), assessing the extent of complexity of the functions contains a project. To complement the metric takes COCOMO-II, the part that weighs and evaluates sets of attributes that qualify every aspect of the team of programmers involved in development. The diagram in Figure 2 illustrates the merger.
Figure 2. COFPSW structure diagram.
The idea has COFPSW is that for every developer or software engineer to use the tool, there is an additional option to be increasingly accurate estimates, based on a historical record of their own development, using for it, stored in a Base Data within the same tool, every one of which carried out the assessments and forward that information becomes a compilation that also support their assessments, act as a statistical argument to obtain more accurate estimates.
To do arithmetic provides an average data recorded in the history of each variable or cost driver to drive. For example, in the case of a variable H, which has stored the values [1.4, 1.15, 1.4, 1.4, 1.55, 1.4] by applying (3) yields:
( )
∑
(3)
( ) ( )
∑
( )
This means that the program performs the allocation of extracted average values which have been stored in each variable, but using a control to avoid "spikes in queues", this makes the code snippet below:
Curr_Prec = SELECT Val_Prec FROM VariablesCo WERE id_Proyecto = Curr_Pro
If (Curr_Prec – Average_Prec ) < 1 then Curr_Prec = Average_Prec Return Curr_Prec
V. APPLICATION
It is a desktop software tool that could be part of the project management, is used for programming activities, performs calculations and supports decision making to determine best alternatives. Development emerges as mono-user, but includes characteristics of an information system, that could even be integrated as part of SPSS or as a plug-in of a project management package like MS-Project.
In a typical MDI model includes a splash window and a common dialogue box "Log-in" to validate the user. Once in the program displays a window with options to choose from a selection of the metrics under which you want to make the estimate, depending on the needs of each user or the development itself. In Figure 3 shows also the way that offer enough help to know what should be chosen but in a hidden, visible only at the request of the operator.
. Figure 3. Main window view .
VI. RESULTS
With what has been presented in this document, you could
try to propose to the director or a software development
engineer, that other issues should at least be clear the
following concepts:
1. There is a minimum time of development. Its value is
laid on a system of equations based on some constants
that allow predicting for each case in a reliable manner.
2. Trying to lead a project faster than the limit allows is
impossible, or at least, no one has achieved.
3. Even try to lead a project to comply with minimum
development time implies a superhuman effort, a
substantial increase in costs and an increase in defects in
the application.
4. Use human elements in any task and attempting to
adjust their behavior to a "variable" of the problem,
carries its level of risk.
5. The use of variables susceptible to statistical handling, it
offers the possibility of a more accurate estimate.
VII. CONCLUSIONS
Were analyzed and compared the main methodologies in the
market, highlighting the deepening of their procedures, which
could determine the possibility of improving them by applying
a statistical approach to the management of the variables used
to calculate their estimates.
We designed the software tool that combines the main features
of the COCOMO II and IFPUG metric, following the rules
dictated by the software engineering, which led to its
successful completion.
This tool automates the key functions of the metrics evaluated
and offers a third option for evaluating the parameters used
and combined to achieve better results.
It was found using COFPSW tool, the ability to make a
significant improvement in the planning and development of a
software project. Whenever the results issued by the
application, was remained within the range of acceptance.
REFERENCES
[1] Albrecht, A. J. Measuring Application Development Productivity, IBM Applications Development Symposium, Monterey, CA, USA, 1979.
[2] Symons, Charles R. Function Point Analysis: Difficulties and Improvements IEEE Transactions on Software Engineering, vol. 14, No.1, January 1988
[3] Software Engineering Standards Committee. IEEE Standard for Software Maintenance, IEEE-SA Standards Board June 1998
[4] Boehm, B., COCOMO II Model Definition Manual, available on http://sunset.usc.edu/research/COCOMOII, USA, 2011.
[5] IFPUG, Counting Practices Manual, Release 4, International Function Point Users Group, USA, 1995-2011.
[6] Pressman, R. Software Engineering. A Practitioners Approach. McGraw Hill. USA, 1997
[7] Sommerville, R., Software Engineering. Addison Wesley. 8ª Ed. USA, 2008.
[8] Stephen H. Kan., Metrics and models in software quality engineering, Addison Wesley, 2ª Edición: USA, 2002.
[9] J. Kaczmarek, M. Kucharski, Size and effort estimation for applications written in Java, Information and Software Technology, SE-46 (589–601), 2004.
[10] Fenton, N.E., Software Metrics u Rigorous Approach, London, 2006.
[11] Salazar B. Gabriela, Estimación de proyectos de software: un caso práctico, Ingeniería y Ciencia, ISSN 1794–9165 V.5, No. 9, June 2009.
[12] http://www.ifpug.org/educational/ Educational services, 2011.
