Software Estimation Methodology - MVC Points

MVC Points – a new estimation methodology for web applications

MVC Points – A new estimation methodology for
web applications
Author:
Designation:

Address:
Contact details:
Phone (Work):
Phone (Mobile)
E-mail:

Nagaraja Gundappa
Head,
Execution Excellence group
Talent Transformation
Wipro Technologies
No. 72, Electronic City
Hosur Main road
Bangalore - 560100
5138 1744
94484 94318
nagaraja.gundappa@wipro.com

The updated contact details of the author are as follows:
Chief consultant,
Akshaya Centre of Excellence (ACE), Bangalore
Ph: 99002 49348
Email: nagaraja.gundappa@acoe.in
Web: www.acoe.in

PML 2005

Nagaraja Gundappa, Wipro Technologies

1


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.

PML 2005


2


(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 eventdriven 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.

PML 2005


3


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

PML 2005


4


(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:

View
User

Controller

JSPs

Servlets

Model
EJBs
DBMS

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

PML 2005


5


complex and then effort is calculated based on norms. The major components of the methodology are
depicted in the diagram below:

MVC Points Estimation – work flow view
Classified MVCs
UC1

Simple
V

U
S
E
C
A
S
E
S

UC2

C
V
M
C
V
Medium

Effort
for
coding
and
unit
testing

Life
cycle
effort
for
MVCs

Total
Development
Effort

M
C

UCn
Complex

Other
nonMVC

M

Miscellaneous
requirements

Effort

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

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.
2.
3.
4.

5.

Identify the use cases for the application.
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.
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.
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.
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.

PML 2005


6


6.
7.

8.

Multiply the effort for CUT by 2.5 to get the life cycle effort (Reasons explained in later sections)
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.
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 viewmodel 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.

PML 2005


7


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

PML 2005


8


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

PML 2005


9


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
Views
Controllers
Models

Simple
Medium
3 x 2 pd = 6 pd
1 x 4 pd = 4 pd
1 x 2 pd = 2 pd
0
0
1 x 7 pd = 7 pd
Total CUT effort

Complex
0
0
0

Total
10 pd
2 pd
7 pd
19 pd

Step 6 – Calculate the life cycle effort
The life cycle effort for this use case would 19 * 2.5 = 47.5 pd

PML 2005


10


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 reestimation 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

PML 2005


11


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

(4) Merits and Demerits
(4.1) Merits
1.

2.

3.

4.

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.
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.
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.
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

PML 2005


12


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, technologyindependent 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.

PML 2005


13


References
1.
2.
3.

“Design Patterns”, Eric Gamma et al., Addison-Wesley professional computing series
Function Point Counting Practices Manual, www.ifpug.org/publications/manual.htm
“Estimation using use case points”, Damondaran, Aqua Netta,
http://www.bfpug.com.br/Artigos/UCP/Damodaranestimation_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)

PML 2005


14


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
Simple
Indicator
View
(JSP)

Controller
(Servlet)

Model
(EJB)

PML 2005

Complexity level indicators and effort norms
Medium
Norm
Indicator
Norm
Indicator

Complex
Norm

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

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

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


15


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:
1. Administrator selects system administration area
of Approval system.

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, email 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)
Administrator:

System:

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

PML 2005


16


Administrator:

System:
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)
Administrator:

System:

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)
Administrator:

System:

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

PML 2005


17


Administrator:

System:
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.

PML 2005


18

Software Estimation Methodology - MVC Points

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Software Estimation Methodology - MVC Points

Ähnlich wie Software Estimation Methodology - MVC Points (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Software Estimation Methodology - MVC Points