MULTI-CRITERIA APPROACH FOR AGILE SOFTWARE COST ESTIMATION MODEL

S. Chandrasekaran1, R.Lavanya2 and V.Kanchana3 1

Professor

2,3

Student

1

Department of Computer Science and Engineering, St.Joseph’s College of Engineering, Anna University, Chennai, India -600 119. 2,3

Department of Information Technology, M.N.M. Jain Engineering College, Anna University, Chennai, India -600 096. 1

2

[email protected] [email protected] [email protected]

Abstract: The proposed work is to focus on the various factors affecting the people-oriented environment that will lead to more acceptable agile software cost estimation model. The estimation being a multi-valued, concurrent, functional and logical process, several medium and small-scale software development organizations are facing a major problem in arriving at a robust estimation model. The most appropriate software cost estimation in an agile environment is a complex problem due to different levels of customer requirements, quality attributes and varying individual processes or personal capabilities. The core idea is to model such a software cost estimation process with a number of constraints imposed by stakeholders and environmental characteristics thereby satisfying multitudinous criteria using concurrent constraint programming. The impact of agile software development environment on the cost and completion time of software product leads to a robust estimation model. The proposed estimation model enhances the level of visibility in the planning stage that encourages the team spirit and organization improvements in the long run, as compared with traditional estimation methods. Keywords: Agile Model, Regression, Cost Constructive Model, Effort Adjustment Factor, Manifestoes, Constraint Engine, Quality Weightage, Constraint Satisfaction

1.0 INTRODUCTION Software projects usually follow the waterfall life cycle and other traditional development life cycle models. These do not result in successful product in terms of technology used and satisfaction of revised requirements at the time of product release, thereby increasing the cost of maintenance. The major reason for this is the long duration between the signing of project and its delivery. The result has been a movement towards more iterative and incremental agile models [1]. Estimation of cost or resources for a software development requires experience, good details of the past projects, and the courage to

commit to quantitative measures when qualitative data are all that exist. All the above factors make the estimation inherently uncertain. There are several approaches for the estimation of software cost and these models provide one or more mathematical algorithms through which computation of cost as a function of a number of variables is done. Most of the software estimation models that are available are based on some form of regression technique. Regression models have a mathematical foundation and are constructed by collecting data on completed projects and developing regression equations relating

them. In this way, many empirical estimation models like the COst COnstructive MOdel (COCOMO) by Barry Boehm, have been developed. This model suggests three modes and three classes of software projects where empirical constants are introduced based on past data for each of the organic, semidetached and embedded classes. An Effort Adjustment Factor (EAF) is determined from a set of cost drivers. Another approach is a software equation which is a multivariable model derived from many contemporary projects as proposed by Putnam [2]. However these traditional models suffer a major drawback of not involving the critical people-factor and their soft skills. Recent developments in teaming concepts led to a focus on management and people issues. The introduction of agile methods highlighted the importance of management and people issues in productivity and quality [3]. In accordance with this perspective it can be said that the development organization depends on people-factors like computer science skills, communication skills, and management skills [3, 4]. 2.0 AGILE DEVELOPMENT ENVIRONMENT

functional and non-functional requirements at regular intervals and believes in delivering the working model for each increment rather than elaborate documentation. Customer collaboration over contract negotiation. Customers are involved in the estimation process to the extent that if the developer has difficulty in estimating a user story they can directly discuss it with the customer and try to break the story down further [5]. Instead of giving importance to the contract, agile software development concentrates on its customers first. •

• Responding to change over following a plan. Agile methods welcome changing requirements, even late in development stage. They accept changes in the requirement specification and allow a flexible software development without being restricted to a fixed plan. The usual agile approach is to fix time and price, and to allow the scope to vary in a controlled manner. 3.0 MULTI-CRITERIA MODEL FOR AGILE SOFTWARE COST ESTIMATION

The Agile method paradigm has been practiced primarily due to the indispensable need for quicker and flexible software. This practice is carried out in a view to reduce the cost and development time. The main methods that fall under the agile umbrella include (eXtreme Programming) XP, Scrum, Crystal, (Dynamic Software Development Model) DSDM, (Feature Driven Development) FDD and (Adaptive software Development) ASD. In agile environment, the software is developed iteratively in very small increments each of which aims at finishing off an aspect of the requirement and the development team evaluates it. 2.1 Agile Manifestoes Figure 1 Multi-criteria model The four agile manifestoes that are a concise summary of agile values in software development are given below: •

Individuals and interactions over processes and tools. This value factor essentially concentrates on the quality, efficiency and skills of the development team members. The criteria like communication skills, managerial skills and computer science skills play an important role than the process quality and the sophistication of tools used. Working software over comprehensive documentation. Agile team performs iterations and may not devote much time and effort for the purpose of documentation. It develops product for its •

The derivation of cost factor for agile software is based on a multiple-criteria approach. The conceptual model illustrated in figure 1 describes the idea of arriving at the criteria set required to emulate the agile environment. The criteria used here is an appropriate combination set of agile environmental and people attributes. The agile manifestoes impose certain constraints on the attributes that are concurrently solved to obtain these criteria. In order to identify the agile attributes, certain inherent issues in this environment are to be considered. Agile paradigm considers the people factor to be more critical than the process factor. According to Alistair Cockburn, people are characterized as non-linear, first-order components in software development [7]. For processes to be predictable, components in it need to behave in a

predictable way. However people are not predictable components, hence there exists a difficulty in predicting and quantifying software for cost estimation. Also, uncertainty, risk factors, emerging requirements and complexity issues are present in agile as in any other traditional software development process. Hence any estimation of cost in an agile environment requires a mapping from the qualitative domain to a set of quantitative values. To achieve this mapping, the major quality-attributes affecting the agile software are tabulated in Tables 1 and 2 along with their weightages. Quality and time weightages refer to a numerical quantity that relatively represents the effect of the attribute on the product quality and time of completion respectively. Table 1 Attributes and Weightages pertaining to Manifesto1

High priority attributes

Table 1 gives the set of attributes pertaining to individuals and interactions over processes and tools, that is, manifesto 1. QW and TW in tables 1 & 2 refer to Quality Weightage and Time Weightage respectively that are obtained from a survey among academicians. Table 2 gives the set corresponding to working software over comprehensive documentation, that is, manifesto 2. For example, consider Communication Skills (CS) from table1. It is one of the high priority attributes whose quality weightage is considered to be 5 whereas time weightage is taken to be -4. The negative value indicates a reduction in time. These attributes are the cost drivers in the proposed cost estimation model and by combining the agile manifestoes with the various quality and time attributes, a particular set of the attribute levels are derived that forms the criteria for estimation. Such a set is considered as the agile environment for the estimation model derivation. 4.0 PROCESS MODEL

QW

TW

Low priority attributes

Communication skills

5

-4

Process maturity

Proximity of team

3

-4

Tool availability

4

-2

Feedback

1

5

Tool familiarity

3

5

Courage

1

-3

Conservativ -eness

1

3

Managerial skills

5

-5

Following process model

3

4

Consistent working

2

-2

Training

4

4

Technical – ability

3

-2

Planning

4

-3

QW

TW

4

-3

Table 2 Attributes and Weightages pertaining to Manifesto2 High priority attributes

QW

TW

Low priority attributes

QW

Debugging capability

2

-2

Pages of documents

2

3

Reliability

3

-2

Project complexity

1

4

Function points

3

4

Other expenditure

Ease of use

4

3

Documentation resources

2

3

Early delivery

5

-2

Documentation period

4

3

2

TW

3

Figure 2 Process Model of Cost Estimation The processes of the cost estimation are illustrated in figure 2. The constraint-solving engine processes the people-attributes and their priority factors as inputs. The engine accepts agile environmental attributes and their weightages as inputs, processes them to generate a set of criteria by solving various constraints pertaining to each and every agile manifesto and finally pumps out the cost estimation equation. The criteria for an agile environment are derived from both the inputs and by solving the constraints imposed by the agile manifestoes. The cost

estimation is then performed with these criteria, which results in a mathematical model. An algorithm for the proposed cost estimation relating cost and time factors is shown in figure 3. 1. Identify the attribute set A of agile environment where A = {a1,a2,….ai,….an}, 1:C %4 this constraint satisfies manifesto 1 DC*2+EOU*4+R*3>:PD*2+COM*1+DP*4 DC>:PD DC>:COM DC>:DP EOU>:PD EOU>:COM EOU>:DP R>:PD R>:COM R>:DP %5 the above is the constraint imposed by manifesto 2 {FD.distribute ff Root} %6 this uses the first fail distribution strategy QF=(5*CS+3*PDT+5*MS+3*TF+4*PM+1*C+2 *DC+4*EOU+3*R+2*PD+1*COM+4*DP) %7 calculates the weighted sum which is the Quality factor T = 5*TF-4*PDT-5*MS-4*CS-3*PM+3*C2*DC+3*EOU-2*R+3*PD+4*COM+3*DP %8 calculates the Time factor T1=(T+33)*30 div 42 %9 scales time in the range 1-30 {Browse ['Time' T1 'Quality' QF]} %10 displays the time and quality factors end {ExploreAll Agile} %11 graphical representation of the constraint solving process end

Figure 5 The Oz implementation

Table 4 The tuple set C S

P D T

M S

TF

P M

C

D C

E O U

R

P D

C O M

D P

2

2

2

1

1

1

2

2

3

1

1

1

2

2

2

1

1

1

3

2

2

1

1

1

2

2

2

1

1

1

3

3

3

1

1

1

2

2

2

1

1

1

3

3

3

1

2

2

2

3

3

1

1

1

2

2

3

1

1

1

2

3

2

1

1

1

3

3

3

1

1

1

2

3

2

1

1

1

3

3

3

2

2

1

2

2

3

1

1

1

2

3

3

1

1

1

2

2

3

1

1

1

3

3

3

1

2

1

2

2

3

1

1

1

3

3

3

2

1

2

3

3

2

1

1

1

3

3

3

1

2

1

3

2

2

1

1

1

2

2

2

1

1

1

3

2

3

1

1

1

2

3

3

1

1

1

3

2

3

1

1

1

3

3

3

1

2

1

3

3

2

1

1

1

2

2

3

1

1

1

Table 4 shows a sample set of the tuples generated on solving the constraints imposed by manifestoes 1 and 2, that is, CS*5+PDT*3+MS*5 > TF*3+PM*4+C*1, DC*2+EOU*4+R*3 > PD*2+COM*1+DP*4. The Oz code in figure 5 generates 255 such tuples, all of which are considered for the estimation of cost. Table 5 Time and Quality factors

Figure 6 The Oz Explorer window The process of constraint solving is graphically represented in figure 6. The implementation for constraint satisfaction through Oz generates the tuples pertaining to manifestoes 1 and 2. This can be further extended to the entire set of manifestoes and prominent tuples can be generated to determine time and quality factors Once the time and quality factors are determined, the cost factor is modeled as in equation 4. ..... (4)

CF = TF × QF where: CF = cost factor TF = time factor QF = quality factor 7.1 Implementation Of Cost Factor:

Time duration in days

Quality Factor

14 12 16 15 12 11 15 13 15 16 18 15 17 18 20 10 9 12 11 9

59 62 63 66 61 64 65 68 72 69 73 70 74 71 75 64 67 68 71 66

The time and quality factors obtained from Oz browser as computed on solving the agile constraints are shown in table 5.

Cost Factor Vs Time

1800 1600 1400 Cost Factor 1200 1000 800 600 400 200 0 0

Series1 Power (Series1)

y = 84.475x 0.9678 R 2 = 0.9177 10

20

30

Time (in days)

Figure 7 The Regression graph In order to make the procedure for estimating the cost factor less tedious, the representation of the above statistics in the form of an equation is most desired. To arrive at such an equation, a graph is constructed with cost factor verses time factor as shown in figure 7. The pattern obtained in the graph is observed to determine the relationship and the cost

is represented as a function of time. This relation so obtained is the required cost model that is shown in equation 5. = 84.475 × TF 0.9678

CF

.....(5)

The equation is verified by substituting values for the completion time (TF) in equation 5. If a time of 0 is considered, the Cost Factor (CF) so obtained is a null value which suggests invalidity. By substituting value ‘1’ for T in the above equation, a CF is obtained which is a valid cost factor. Hence it can be inferred that a minimum of one day is required for any project completion. The questionnaire circulated among the various members of agile software development family to arrive at Time and Quality weightages has been mentioned in the Annexure. 8.0 CONCLUSION The agile software cost estimation is modeled through a careful consideration of all attributes relating to the four manifestoes. Multi-criteria approach is adopted in solving concurrent constraints. Quality and time factors are obtained by solving the constraints through a weighted sum approach. The cost model is checked and is found to be suitable for small and medium scale software development team working in agile environment.

9.0 REFERENCES 1.

2. 3. 4.

5. 6.

7.

James E. Tomayko, “An Historian’s View of Software Engineering,” in the Proceedings of the IEEE Conference on Software Engineering Education and Training, IEEE Computer Society Press, Los Alamitos, Ca.,, 2000 Roger Pressman, “Software Engineering: Practioner's Approach”, Fourth Edition, Mc Graw Hill International Edition. pp. 121-125.

Randall W. Jenson, “Extreme Software Cost Estimating”, January 2004. Jenson R.W., C. C. Tonies, “Software Engineering”. Englewood Cliffs, NJ: Prentice-Hall, Inc., 1979:24ff Williams, “The XP Programmer: The FewMinutes Programmer”, IEEE Software,2003, vol. 20, pp.16-20. Alistair Cockburn, “Characterizing People as Non-Linear, First-Order Components in Software Development”, at http://alistair.cockburn.us/crystal/articles/cp anfocisd/characterizingpeopleasnonlinear.ht ml Brian Mayoh, Enn Tyugu, Tarmo Uustalu, “Constraint Satisfaction and Constraint Programming: A Brief Lead-In”, in the proceedings of the “NATO Advanced

Study Institute on Constraint Programming, Estiona”, 1993.