Software Estimation Methodology - MVC Points

MVC Points – a new estimation methodology for web applications

PML 2005 Nagaraja Gundappa, Wipro Technologies 1

MVC Points – A new estimation methodology for

web applications

Author: Nagaraja Gundappa

Designation: Head,

Execution Excellence group

Talent Transformation

Wipro Technologies

Address: No. 72, Electronic City

Hosur Main road

Bangalore - 560100 Contact details:

Phone (Work):

5138 1744

Phone (Mobile) 94484 94318

E-mail: [email protected]

The updated contact details of the author are as follows:

Chief consultant,

Akshaya Centre of Excellence (ACE), Bangalore

Ph: 99002 49348

Email: [email protected]

Web: www.acoe.in

mailto:[email protected]



Abstract

As technology and development methodologies change, the older effort estimation methodologies become

less applicable or nearly irrelevant. When it comes to web application development using Object Oriented

Software Engineering methodology, it is tedious if not impossible to use older estimation methodologies

such as COCOMO or Function Points. One of the main reasons for the estimation methodologies to

become obsolete is that the methodologies are closed in the sense that the users cannot easily tailor or

extend the methodology. This paper defines a new paradigm of openness in estimation methodologies and

describes one estimation methodology, MVC Points, its usage in detail. This methodology is open and

users can tailor or extend this methodology. This methodology has been developed indigenously and

originally by the J2EE Centre Of Excellence at Wipro Technologies The initial results of piloting this

methodology are very encouraging and the methodology has started gaining acceptance.



(1) Introduction

Estimating the size of a software application has always been a challenge and continues to remain so. When

an estimation technique gains acceptability and tends to become universal, the technology and environment

change so much that the assumptions made in the well accepted methodology would become incomplete

and at times invalid. Established methodologies become less accepted in the new context and new

estimation methodologies emerge. Specifically, when it comes to estimating web applications, the current

estimation methods have the following problems:

The Cocomo methodology provides a way of estimating the efforts given the size in Kilo Lines Of

Code (KLOC). However, it does not provide a methodology to estimate the size in KLOC.

KLOC as a sizing unit is not the most appropriate technique to size web applications. In event-

driven programming used for developing Graphical User Interfaces (GUI), lines of code is not the

best indicator of complexity involved in developing the GUI. Secondly, when both manual code

and tool-generated code are involved it requires different level of effort to develop the same.

Hence it becomes confusing to use KLOC as a sizing unit.

Due to the above complexities, estimating the size of an application in terms of KLOC, given the

requirements is too complex if not impossible.

The Function Points methodology has the following disadvantages:

o It is difficult to visualize a web application using the paradigm of function points

methodology. Function points views the size of an application in terms of data and

transactions and this is different from object oriented thinking in which an application is

viewed as a group of classes related and interacting with each other.

o There is no one-to-one mapping between the 5 elements of the methodology and the units

of code that actually get developed.

o The counting rules are too abstract and can be interpreted very differently by different

persons.

o As one function point does not directly translate into one unit of code that gets developed,

it is difficult to carry out a root cause analysis if there is a mismatch between the

estimated effort and actual effort.

The use case points methodology addresses some of the above limitations as they are based on use

cases and maps well to object oriented view of applications. However, the use case points

methodology has the following disadvantages:

o There is a large variation in the way use cases are written. If not balanced, an application

tends to have smaller number of large use cases and this can cause a large deviation in the

estimates.

o Use case to class mapping is one to many and it is extremely cumbersome to verify the

effort per use case based on actual experience.

o Productivity norms per use case point has a degree of empiricalness and hence

confidence level on the estimates would be low.

As a result of the above limitations, no estimation methodology has become universally accepted and

experience based free-format estimation continues in large scale.

The above observations can be summarized and ascribed to the paradigms that these methodologies are

based on and a new paradigm is needed to develop new estimation methodologies.

(1.1) Current paradigm in estimation methodologies – Generic and closed

The current paradigm in estimation methodologies is to develop methodologies that are generic, applicable

to all technologies and handle technology specific complexities through adjustment factors. For instance,

the function points (FP) methodology was developed during the era of stand-alone applications but has

been abstracted and made applicable to estimating the size of any software. The FP methodology has

adjustment factors called general system characteristics that addresses the technology-specific complexities

of implementing the same functionality. The Use case points (UP) methodology is also considered generic

and has what are called Technical Complexity Factors and Environmental Complexity Factors to handle

technology specific variations. Another new estimation methodology called Class Points is also similar in

nature.



In general, the paradigm of generic and closed estimation methodologies can be summarized as follows:

1. Views the application top down. That is, visualize the application at the highest abstraction level

either in terms of functionality or in terms of use cases.

2. Define adjustment factors to take care of technology and development environment specific

variations. These adjustment factors have empirical numbers to add or multiply the size.

3. Effort norms are per abstracted sizing units

It is due to the above paradigm that these estimation methodologies have still not become universally

accepted. Specifically, following factors pose a hurdle for a gradual maturity of these methodologies -

1. Because sizing units are generic and abstract, validation of effort norms is tedious and

approximate. That is, the sizing unit does not directly correspond to any coding unit that is

developed and hence a unit-level validation of estimates is not possible. For instance, a function

point or a usecase point does not correspond directly to a given set of classes. The relationship

between function points (or use case points) and classes that get developed are many-to-many.

2. Adjustment factors involves empirical numbers and this makes the methodology closed. That is,

if an application involves complexities not listed among the adjustment factors, users cannot

modify or extend the adjustment factors. For instance, if an application has higher reliability

requirements, this complexity is not a factor that is listed in Function Points or Usecase points. A

user would not know how to tweak the adjustment factors as he would not know what empirical

number to assign to this new complexity factor.

Therefore, the current paradigm of generic and closedness does not allow organizations to adopt a

methodology and refine it continuously.

Hence, there is a need for a new paradigm of Open and Technology specific estimation methodologies.

Technology specific, because the sizing units can have a closer mapping to the code units developed and

hence it should be easier to validate effort norms. Open because, it would not be possible for the authors of

any methodology to foresee all possible complexity factors and list them. Users should be free to modify

or extend the complexity factors so that organizations can adopt them and refine continuously.

(1.2) Experience at Wipro Technologies

At Wipro Technologies, experience with estimating for web applications reflects the above observations.

Firstly, it is observed that experience-based free-format estimation has several drawbacks. Most

significantly, it was found that there was no standard way to identify the work-break-down elements of an

application and hence lessons learnt from one estimation exercise could not be leveraged and used as

heuristics for the next estimation. Secondly, it has been found that usage of estimation methodologies such

as Function Points and COCOMO for web application is too tedius and cumbersome if not impossible for

reasons explained earlier in the section. Hence, it was decided to develop a family of estimation

methodologies based on the new paradigm. Developing an open estimation methodology would essentially

involve –

1. Standardization of work-break-down units of a specific technology

2. Defining complexity indicators

3. Defining effort norms for sizing units of different complexities.

To begin with, it was decided to develop methodologies for J2EE and .Net technologies. Called MVC

Points, this paper describes this new methodology. Rest of the paper is organized as follows:

Overview of the MVC Points methodology

Description of steps involved in the methodology

Illustration of the methodology for one use case

Results of initial usage of this methodology

Guidelines for adopting this methodology in an organization

Appendices



(2) MVC Points methodology

The Model-View-Controller pattern is quite popular and is a well accepted practice in developing J2EE and

.Net applications. Hence, standardization of work-break-down units for J2EE and .Net applications was

done based on the MVC pattern. That is, J2EE and .Net applications would be considered to be essentially

consisting of a number of views, controllers and models. Hence, the name MVC Points for this

methodology. A brief overview of MVC Pattern needed to appreciate this methodology is provided in the

next section.

(2.1) MVC Architectural pattern

Any interactive application can be categorized into:

View Classes that present GUIs

Model Classes that handle business logic and interact with database

Controller classes which communicate between the View and Model Classes

Typically in internet applications User interfaces change often, look-and-feel being a competitive

issue. The same information is presented in different ways; however, the core business logic and data

is stable. So model classes would not change often but view classes would. Hence, separating Model

from View (that is, separating data representation from presentation) results in the following

advantages

easy to add multiple data presentations for the same data.

facilitates adding new types of data presentation as technology develops.

Model and View components can vary independently enhancing maintainability, extensibility,

and testability

In a typical J2EE application, the Model, View and Controller would map as shown in the following

diagram:

Diagram 1: MVC Pattern in J2EE technology

The View (GUIs) is implemented by JSP (Java Server Page), Controller is implemented using servlets and

Model is implemented by EJB (Enterprise Java Beans). It should be noted here that the Model includes

the database as well as the helper classes to go with the EJBs.

In a .Net technology, the View is implemented by .ASP, Controller is implemented by Code behind and the

Model is implemented by COM+ components. The model includes the COM+ components as well as the

database.

(2.2) Overview of the methodology

The Paradigm behind this methodology is that the size of a J2EE or a .Net application can be expressed in

terms of the number of views, models and controllers developed. The methodology involves listing the

use cases of the application and for each use case, enumerating the models, views and controllers needed to

realize the use case. Each model, view and controller enumerated is classified as simple, medium or

Model View Controller

JSPs Servlets EJBs

DBMS

User



complex and then effort is calculated based on norms. The major components of the methodology are

depicted in the diagram below:

Diagram 2: Components and work flow of MVCPoints methodology

As shown in the diagram above, the MVC Points methodology essentially consists of a step-by-step

procedure and guidelines to be used in each step. The procedure is as follows:

1. Identify the use cases for the application.

2. For each use case, estimate the number of models, views and controllers required to realize the use

case. The methodology provides tips to appropriately identify the Models, Views and Controllers.

3. Eliminate duplicates. That is, for instance, if a view identified for one use case is required for

another use case also, count it only once.

4. Classify the identified models, views and controllers as simple, medium and complex. The

methodology provides what are called complexity indicators to classify the identified models,

views and controllers.

5. Apply effort norms to identified models, views and controllers. The MVC Points model

recommends effort norm to be defined only for the coding and unit testing (CUT) phase and use

this as the basis for determining the life cycle effort.

Simple

Medium

UC1

UC2

UCn

Classified MVCs

V

C

M

V

C

M

V

C

M Complex

Life

cycle

effort

for

MVCs

Effort

for

coding

and

unit

testing

Total

Development

Effort

Other

non-

MVC

Effort Miscellaneous

requirements

MVC Points Estimation – work flow view

MVC Points Methodology - Elements

Guidelines to identify

Models, View and

Controllers from Use

cases

Guidelines to classify

M,V and Cs into

simple, medium and

complex categories

Effort norms for

coding and unit testing

the Models, Views

and Controllers

Guidelines to

arrive at

overall effort

U

S

E

C

A

S

E

S



6. Multiply the effort for CUT by 2.5 to get the life cycle effort (Reasons explained in later sections)

7. The above steps cover typically 90% of the functionality. There will be miscellaneous work items

that cannot be modeled through the MVC. Use plain work break down structure and estimate the

effort based on experience.

8. Add buffer and project management effort to the above to get the total effort for the project.

(2.3) Using the methodology

This section describes the implementation of each step in detail. J2EE terminology has been used wherever

applicable for ease of reading and it should be noted that the same steps are equally relevant for .Net

technology as well.

Step 1 - Identifying the use cases for the application

The first step in estimation using the MVC Points methodology is to identify the use cases. It is sufficient

to identify the title of the use case and it is not necessary to go into the details although it is beneficial to

have more details. These use cases form the basis for identifying the models, views and controllers

(Referred to as MVC Points in rest of the paper) that will implement the use case.

It has been found in our experience that, for the estimation carried out at a proposal stage, where only a

high level description of the application is available, it will still be possible to identify the use cases for the

application at a title level. Experience has also shown that estimating the MVC Points based on use case

titles has been effective even though having detailed use cases can make the estimation more accurate.

Step 2 - Identify the Models, Views and Controllers For each use case, visualize the scenario getting enacted in the to-be-implemented system. One should ask

as to what type of UI will be needed (if needed) and how many? This step will yield the number of views

(JSPs). Secondly, one should visualize the control flow as well as transaction flow from GUI to the data

source and identify how many models (EJBs) and controllers (Servlets) will be required to implement this

use case. In an object oriented methodology, since we assume that the data design stems out of class

design, the effort to design the data model is accounted for in the effort to develop the Model itself.

Following are some tips to identify the MVCs:

Group the CRUDL (Create, Read, Update, Delete and List) transactions of the same entity into a

single use case. Each such unique use case will have common GUI. For instance add user, update

user, query user, delete user and list users transactions will be a part of the same use case and will

have either a single user screen or a main user screen and few small sub screens depending on the

complexity of the use case.

Deciding how many controllers are needed per use case is tricky. While on one hand, each view-

model combination can have a controller each, on the other extreme, there are implementations

where an entire application has only one controller. One needs to use OOSE (Object Oriented

Software Engineering) best practices and guidelines to resolve this. One of the OOSE guidelines

is to have an optimum number of attributes and methods in a class. Too many attributes and

methods in a class makes it un maintainable. Typically, a class should not have more than 15

methods and one method should not have more than 200 lines of code. Based on this guidelines,

one can have one controller for each view or one controller for multiple views ensuring that the

controller is not too large.

The effort to design and develop the model accounts for data design as well. However, some of

the administrative effort such as database scripts written for archival etc. should be accounted for

separately, outside the MVC model. Experience shows that about 90% of the effort can be

estimated using the MVC model and there will be certain miscellaneous 10% requirements that

have to be estimated separately using plain WBS model. The model includes the EJBs and the

helper classes also.

External interfaces that the EJB connects to do not have to be counted separately as these are

accounted for in the complexity factor.

Helper classes for EJBs are accounted for as part of the EJB. One Model is equivalent to one EJB.



Step 3 - Eliminate duplicates

More than one use case can access the same model, view or controller. Therefore while counting them for

a usecase give them a suggestive name and eliminate redundant counting of the same models, views and

controllers.

Step 4 - Classify the identified units as simple, medium or complex

Each model, view and controller should be classified as simple, medium or complex based on the richness

of functionality required to support it. A view is classified based on the following parameters:

No. of data display and control elements on the screen

Type of formatting required for the page

Amount of validation logic to be implemented in the GUI itself

A controller is classified based on the following parameters:

No. operations that the controller invokes on the model per request from the view

Complexity of the control logic such as determining what operations to invoke depending on the

results returned by the model.

Amount of functionality implemented in the controller such as storing session and state

information, maintenance of a cache etc.

A model is classified based on the following parameters:

Complexity of the business logic

Diversity of data sources that the model maintains

Complexity of the persistence mechanism used.

One should visualize the realization of a use case from end-to-end and estimate the factors influencing the

complexity and accordingly classify the models, views and controllers. Non-functional requirements

translate into complexity factors. A sample of the complexity indicators and indicative effort norms are

listed in Appendix A. Detailed complexity indicators are contained in the MVC Points manual.

Step 5 - Determining the effort for coding and unit testing

The identified and classified MVC Points are multiplied by their corresponding effort norms and added.

The effort norm is the effort in person days required to code (implement) and unit test a given MVC Point.

Following should be noted about the effort norm:

The effort norm is defined only for the coding and unit testing phase as this is the only phase in

which tasks are performed on a per MVC Point basis. That is, coding and unit testing phase

essentially consists of atomic activities to code and unit test the models, views and controllers and

nothing else. Hence, it is easier to validate the effort norm by comparing it with the actual effort

after the implementation. Other phases in the life cycle include work at an application level as

well and hence it is difficult to validate the effort norm per MVC Point. In other words, if the

effort norm defined for the models, views and controllers include the complete life cycle, then it

will be difficult to validate the same later on.

The effort norm is defined for each organization and will include the environmental and

productivity factors. That is, it is assumed that the environmental factors across an organization

are more or less similar.

The complexity factors such as those arising out of non functional requirements get factored into

the complexity indicators themselves.

Following formula summarizes the effort determination:

CUT Effort = ∑ SM * ESM + ∑ MM * EMM + ∑ CM * ECM + ∑ SC * ESC +

∑ MC * EMC + ∑ CC * ECC + ∑ SV * ESV + ∑ MV * EMV + ∑ CV * ECV

Where,

CUT = Coding and Unit Testing

SM = Number of Simple Models

ESM = Effort norm for coding and unit testing a Simple Model



MM = Number of Medium Models

EMM = Effort norm for coding and unit testing a Medium Model

CM = Number of Complex Models

ECM = Effort norm for coding and unit testing a Complex Model

SC = Number of Simple Controllers

ESC = Effort norm for coding and unit testing a Simple Controller

MC = Number of Medium Controllers

EMC = Effort norm for coding and unit testing a Medium Controller

CC = Number of Complex Controllers

ECC = Effort norm for coding and unit testing a Complex Controller

SV = Number of Simple Views

ESV = Effort norm for coding and unit testing a Simple View

MV = Number of Medium Views

EMV = Effort norm for coding and unit testing a Medium View

CV = Number of Complex Views

ECV = Effort norm for coding and unit testing a Complex View

Step 6 - Determining the overall life cycle effort

Multiply the total CUT effort by 2.5 to get the complete life cycle effort. In a healthy project, coding and

unit testing should consume about 40% of the overall application development effort. This is an industry

norm and has been adopted in many organization. Hence if we estimate the effort for coding and unit

testing, we are accounting for 40% of the overall effort and hence a multiplication factor of 2.5 will yield

the overall life cycle effort.

Step 7 - Estimating non-MVC effort

It is observed that even in the strictest object oriented applications, not all the code developed can be

brought under the umbrella of MVC pattern. For instance, database administrative effort such as writing

scripts for archiving can be accounted for in the MVC pattern. Or development of bridges to access

different technologies cannot easily be accounted against a use case either as model or view or controller.

Experience shows that such work accounts for less than 10% of the application development effort and

should be estimated using a plain work-break-down structure with experience-based estimation of effort.

Step 8 - Completing the effort estimation

The previous step would yield the effort needed for complete life cycle development. To this, we should

add the project management effort and buffers to arrive at the total project effort. It is a common practice

nowadays to allocate about 5% to 10% effort as a buffer to account for changes in requirements as well as

effort unaccounted for. Project management effort is assumed to be around 10% of the overall lifecycle

development effort. This step completes the project effort estimation and this input can be used further for

arriving at the cost.

(2.4) Illustration

In this section, the MVC Points methodology is illustrated for a use case.

Step 1 – List the use cases – This illustration contains estimation for one use case listed in the appendix B

Step 2 – Estimate the number of MVC Units –

Views:

Since, the use case is detailed, instead of estimating, we can actually identify the views required. There are

4 views–

1. List of authorized users screen

2. Add / Edit worksheet (It is assumed that the same screen is reused for Add and Edit transactions)

3. Delete user screen

4. Search screen



Please note that main screen is not specific to this use case and has been left out. Same way, error screens

are reusable across the application and would be accounted for when estimating for the whole application.

For the purpose of this illustration, error screens have been left out.

Controllers:

One controller for data retrieval and invoking operations on the model

Models:

Since, the amount of data is limited (about 13 elements) and operations are also not complex, one EJB, say

User would be sufficient. Those familiar with data oriented thinking can visualize that there would be one

table called User or at most one User master table and another child access types table, but both operated

upon by the same model. So, there is only one model.

Step 3 – Eliminate duplicates

If the same MVC Units are being counted for different use cases, then they should be counted only once.

Since, this illustration contains only one use case, there are no duplicates.

Step 4 – Classify the MVC units into simple, medium and complex

Views:

List of authorized users screen – simple, as it has less than 10 data display elements and submit points. No

complex validations or page formatting is involved.

Add / Edit user worksheet – Medium, as it has more than 10 data display elements and submit points (about

13 data elements including a list). No complex validations or page formatting is involved

Delete user screen – Simple, as it has few display elements and no complex validation or formatting.

Search screen – Simple, as it has few display elements.

Controller:

Simple, as it needs only data retrieval and one operation invocation per request.

Model

The User EJB has

- Few methods and attributes – apart from CRUDL (Create, Read, Update, Delete, List)

methods, there would be perhaps two or three extra methods for different types of search.

If there were no additional complexities, this would have been a simple EJB.

- Not so simple, data updating logic – in the view side, if more than one user was selected

for Edit, the data in the Edit worksheet would have to be applied to all users.

- Since, the number of users are expected to be high caching would be involved.

- Deletion refers to another EJB (MyQueue).

Therefore, it is of medium complexity.

Step 5 – Calculate the coding and unit testing effort

According to the indicative norms provided in Appendix A, the coding and unit testing effort for this use

case is 19 person days:

CUT Effort Simple Medium Complex Total

Views 3 x 2 pd = 6 pd 1 x 4 pd = 4 pd 0 10 pd

Controllers 1 x 2 pd = 2 pd 0 0 2 pd

Models 0 1 x 7 pd = 7 pd 0 7 pd

Total CUT effort 19 pd

Step 6 – Calculate the life cycle effort

The life cycle effort for this use case would 19 * 2.5 = 47.5 pd



Step 7 – Add non MVC effort

Typically, those deliverables that do not come under the purview of MVC should be estimated separately

and added to the effort from previous step. In this case, the script to create the table schema for user table

would be a non-MVC effort. Experience based estimate for this work is around ½ day.

Therefore, total life cycle effort = 47.5 + 0.5 = 48 person days.

Step 8 – Add buffer and project management effort

Assuming a buffer of 10% and project management effort of 10%, the total project effort would be

48 + 4.8 + 4.8 = 57.6 person days.

(3) Validating the MVC Points methodology

After finalizing the theoretical model, this methodology has been applied and validated. It has been used at

pre-sale level including for deals that have been one. Large scale usage of this methodology at Wipro

Technologies has just started and the initial results are encouraging and are shared below:

(3.1) Re-estimation of a completed project for a publishing company:

In one of the applications that was in it‟s acceptance stage, a new team member was given the initial

requirement specification and the guidelines of this methodology and was asked to estimate the effort for

one of the modules. Results of re-estimation carried out was compared with the original estimates and

actual effort and significant improvement was found. The results are as follows:

Effort originally estimated by the team = 11 person months

Actual effort = 16 person months

Effort re-estimated using the MVC Points methodology = 18 person months.

The deviation between original estimate and actual effort is around 31.25%, whereas the deviation between

the MVC Points-based re-estimate and actual effort is 12.5%

(3.2) Re-estimation of a completed project for a manufacturing company:

This exercise was similar to the previous one, but it was tried for two modules and the results are as

follows:

Module 1:

Effort originally estimated by the team = 120 person days

Actual effort = 180 person days

Effort re-estimated using the MVC Points methodology = 198 person days.

Module 2:

Effort originally estimated by the team = 140 person days


Effort re-estimated using the MVC Points methodology = 169 person days

In this application, the original estimates had a deviation of 33% and 22% respectively, whereas the re-

estimation using this methodology had a deviation of 10% and 6% respectively.

(3.3) Comparison of estimation and actual effort for a retail company -

In this case, the original estimates were prepared using the MVC Points methodology and was compared to

the actual effort after the completion of project.

Estimated effort = 756 person days




The deviation between the estimation and actual effort is - 4%

(4) Merits and Demerits

(4.1) Merits

1. Maps to object oriented paradigm – Since, the application is visualized in terms of use cases

and eventually the models, views and controllers, the visualization is in line with the object

oriented paradigm.

2. Intuitive to use – The work-break-down units are not abstract. Rather, the work-break-down

units are real and what are going to get developed eventually. Hence, it is easier for the developer

to visualize and enumerate.

3. Easy to validate effort norms – Since, the effort norm is defined in terms of effort required for

coding and unit testing actual deliverables, it is easy to validate the effort norms based on actual

experience.

4. The methodology is open and extendable – If there is a complexity factor missing, it can easily

be added or a new category such as „very complex‟ can be created without too much of process

overheads. This is unlike in other methodologies where any additions to the complexity factor

would have an impact on the empirical adjustment factors and weights and assigning weights and

adjustment factors to the new complexity factor is not possible for users.

(4.2) Demerits

1. Limited applicability - Applicability of the methodology is limited to specific technologies

(5) Adapting the MVC Points methodology in organizations

When an organization starts using the MVC Points methodology, it would typically be done by piloting

with a few projects and then adapting it at organization level. As will be explained later in this section, the

paradigm behind MVC Points methodology can be applied to develop new estimation methodologies.

(5.1) Refining the complexity indicators

The guidelines to classify the MVCs and the effort norms are directly derived from the experience of

developers. When the methodology is taken to a new organization, there would always be scope for minor

variations in these guidelines to classify MVCs based on the way in which developers visualize the

application. So, minor refinement and extension of the complexity indicators should be allowed.

For instance, in one of the pilot projects that tried this methodology, the team felt that there are few GUIs

that are more complex than the complexity indicated by guidelines for “Complex” JSPs. In this project,

they defined another category called “Very complex” and placed these few GUIs in this category. The

team also defined the norm for coding and unit testing effort for this category. This is the benefit of

having an open and extensible methodology.

(5.2) Determining effort norms

Software development productivity can have high level of variations due to various factors including work

environment. However, the MVC Points methodology eliminates these variations because the effort norms

are specific to a technology and specific to an organization. That is, the approximation that is made is that

the work environment related factors are same across an organization and minor productivity variations

among different sub groups are ignored. The second factor to be noted w.r.t. productivity norms is that

practitioners also tend to centre their estimates around norms if available.

Therefore when an organization adapts this methodology, the effort norms are determined based on

experience while piloting the methodology. When the effort norms are standardized, rest of the

organization would centre around this norm even if their experience is slightly different.

(5.3) Extending the paradigm to develop other similar models



Following are the main characteristics of the MVC Points model that can be extended to develop other

estimation models:

1. Work-break-down units evolving out of standard deliverables of a given technology are

standardized into size units

2. Openness and expendability – develop initial guidelines and leave it open to account for additional

complexities not envisaged earlier.

For instance, Enterprise application integration (EAI) applications do not follow standard development

cycle or methodology and hence the currently prevalent estimation methodologies cannot be used. Same

holds true for package implementations or data migration projects. For these type of applications, it would

not be too difficult to develop new estimation methodologies called say, integration points or migration

points.

EAI applications are interface intensive and will consist of many adaptors / connectors, bridges and so on.

So, an interface unit can be a fundamental unit of EAI estimation with complexities being defined by

Quantity and complexity of data flowing through the interface

Complexity of processing

A similar approach can be used to arrive at estimation methodologies for data migration projects as well.

Here, a data point can be a fundamental unit with complexities defined by

Quantity and complexity of data in that point (For instance a table)

Complexity of processing involved in migrating from source to destination.

(6) Conclusion The current paradigm in estimation methodologies is that the methodologies are generic, technology-

independent and involves a degree of empirical ness. When technology and development environment

changes it becomes difficult to use the methodologies as-is for the new environment. Due to a degree of

empiricalness involved, the current methodologies are „closed‟ as it is not possible for users to modify or

extend the adjustment factors in the methodology. This paper has introduced a new paradigm in estimation

methodologies characterized by openness and specificity to application types. The new estimation

methodology „MVC Points‟ fits into this paradigm and is the topic of this paper. The initial results of using

this methodology are encouraging and it is tending to be widely used. The paradigm introduced with this

methodology can be used to develop new estimation methodologies custom made to technology and

application type such as enterprise application integration and data migration.



References

1. “Design Patterns”, Eric Gamma et al., Addison-Wesley professional computing series

2. Function Point Counting Practices Manual, www.ifpug.org/publications/manual.htm

3. “Estimation using use case points”, Damondaran, Aqua Netta,

http://www.bfpug.com.br/Artigos/UCP/Damodaran-estimation_Using_Use_Case_Points.pdf.

Biography of the author

Master of Technology in Computer Science and Engineering, University of Mysore

Total IT industry experience of 14 years

Current position – Head, Execution Excellence group, Talent Transformation

Positions held before include:

o Project Manager

o On-site manager

o Lead Architect

o Program Manager

o Head, J2EE Centre of Excellence

Career highlights:

o Have published several papers including one in IEEE

o Managed a project that was awarded “Best application utilizing reusable components” at

Object World west 97 – a conference conducted by OMG (Object Management Group)

http://www.ifpug.org/publications/manual.htm

http://www.bfpug.com.br/Artigos/UCP/Damodaran-Estimation_Using_Use_Case_Points.pdf

http://www.bfpug.com.br/Artigos/UCP/Damodaran-Estimation_Using_Use_Case_Points.pdf



Appendix A – Complexity indicators and effort norms

The table below lists sample guidelines to classify the MVC Points as simple, medium and complex. The

table also lists the effort required to code and unit test the same. It should be noted here that the guidelines

are only sample and the MVC Points manual contains detailed guidelines. The effort norms provided

below are only indicative and are NOT the ACTUAL norms of any organization including Wipro

Technologies.

MVC Unit Complexity level indicators and effort norms

Simple Medium Complex

Indicator Norm Indicator Norm Indicator Norm

View

(JSP)

Few Data entry and

display elements

and submit points

(< 10)

2 PD

More data entry,

display elements and

submit points ( < 20

)

Page breaks, display

logic, Simple usage

of DHTML

4 PD

Complex Validations,

Complex Formatting,

Complex page layout,

Complex display logic

8 PD

Controller

(Servlet)

1-2 operations /

request.

Retrieval and

passing of data

elements

2 PD

More operations per

request,

Session information

storing;

Operations based on

servlet session

information

4 PD

Keeping track of

processes across pages;

Request routing based

on intermediate

operations

6 PD

Model

(EJB)

Simple Interface

(Few methods and

parameters)

Simple data access,

data logic (no

caching)

3 PD

Multiple data

sources;

Complex data

retrieval and updation

logic;

Caching

7 PD

Multiple data sources;

involves tables and

other sources; connects

to external interfaces

14 PD



Appendix B – Sample Use case – user administration This section contains a normal flow and alternate flows for a user administration use case for a

work-flow system.

Core Flow of Events – Adding a new user

Administrator: System:

1. Administrator selects system administration area

of Approval system.

2. System displays System Administration menu. Menu

items are: AUTHORIZED USERS and USER ACCESS

TYPES.

3. Administrator selects AUTHORIZED USERS.

4. System displays list of authorized users. With options to

ADD, EDIT, DELETE, SEARCH and CANCEL.

5. Administrator selects ADD new user. (See

alternate flow to edit or delete user from authorized

user list.)

6. System displays new user worksheet with the fields:

last name (required)

first name (required)

middle initial (optional)

login (required) – 6 characters

password (required) – 8 characters

e-mail address (required)

notes (optional)

list of access types: All, Approvals Manager,

Approvals Coordinator, Approvals Administrative

Assistant, Reporting Manager

Date added (system sets when new user is created)

This field is not editable

Date modified (system sets when user is edited) This

field cannot be changed by the administrator.

7. Administrator enters name, login, password, e-

mail address and notes into worksheet.

Administrator selects access type(s) user is to be.

See business rules for list of access types and

functions each can perform.

8. System validates user (are manadatory fields filled in, are

login and password formatted properly?) If new user record

is OK, system saves information for new user and displays

list of authorized users with new user added.

6a. If new user has not been set-up properly, system

displays an error message and returns to step #5.

Alternative Flows

EDIT USER RECORD (From step #4 in core flow)




5. Administrator selects name(s) of user(s) to be

modified. Clicks EDIT.




6. System displays user worksheet for selected user. If more

than one user has been selected, the system will display

worksheet for first selected user.

7. Administrator keys in new information and

SAVES.

8. System saves changes (validates as in core flow) and

displays authorized user list.

8a. If administrator has chosen more than one user to edit,

system will ask, “Do you want to change all selected users?

YES/NO” the new information will be applied to all selected

users.

9a. Administrator selects YES.

9b. Administrator selects NO.

10a. System saves changes (validates as in core flow) and

displays authorized user list.

10b. System returns to step #4.

DELETE USER RECORD (From step #4 in core flow)




5. Administrator selects name(s) of user(s) to be

deleted. Clicks on DELETE.

6. System asks, “Do you really want to delete user name(s)?

YES/NO”

7. Administrator selects YES.

7a. Administrator selects NO.

8. If YES, system will run validation to see if user has

outstanding work in his or her “My Edit” queue. If none is

found, system deletes user and returns to authorized user list

with user gone. If work is found, system displays an error

message and returns the administrator to the authorized user

list. User cannot be deleted with work in “My Edit” queue.

8a. If NO, system returns to authorized user list with user

still there.

SEARCH FOR USER (From step #4 in core flow)




5. Administrator clicks on SEARCH.

6. System displays search screen.

7. Administrator enters search text, selects search

type: KEYWORD or BROWSE or ACCESS TYPE,

and then selects SEARCH or CANCEL.

8. System searches per administrator‟s request. A keyword

search searches both first and last name fields and returns list

of all users matching search specification. A browse search

searches the last name field and will take administrator to

place in list of authorized users matching search term most




closely, displaying names falling before and after the browse

term alphabetically. An access type search will return a list

of all authorized users of the specified access type.

9. Administrator may use search results to add, edit

or delete users as detailed above.