Software Estimation Methodology - MVC Points
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Software Estimation Methodology - MVC Points

on

  • 2,753 views

This is one of the estimation methodologies called 'MVC points' that was created to estimate J2EE and .Net applications. I have uploaded a .ppt file for the same also and this is a full paper.

This is one of the estimation methodologies called 'MVC points' that was created to estimate J2EE and .Net applications. I have uploaded a .ppt file for the same also and this is a full paper.

Statistics

Views

Total Views
2,753
Views on SlideShare
2,753
Embed Views
0

Actions

Likes
0
Downloads
78
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Software Estimation Methodology - MVC Points Document Transcript

  • 1. 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
  • 2. MVC Points – a new estimation methodology for web applications 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 Nagaraja Gundappa, Wipro Technologies 2
  • 3. MVC Points – a new estimation methodology for web applications (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 Nagaraja Gundappa, Wipro Technologies 3
  • 4. MVC Points – a new estimation methodology for web applications 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 Nagaraja Gundappa, Wipro Technologies 4
  • 5. MVC Points – a new estimation methodology for web applications (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 Nagaraja Gundappa, Wipro Technologies 5
  • 6. MVC Points – a new estimation methodology for web applications 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 Nagaraja Gundappa, Wipro Technologies 6
  • 7. MVC Points – a new estimation methodology for web applications 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 Nagaraja Gundappa, Wipro Technologies 7
  • 8. MVC Points – a new estimation methodology for web applications 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 Nagaraja Gundappa, Wipro Technologies 8
  • 9. MVC Points – a new estimation methodology for web applications 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 Nagaraja Gundappa, Wipro Technologies 9
  • 10. MVC Points – a new estimation methodology for web applications 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 Nagaraja Gundappa, Wipro Technologies 10
  • 11. MVC Points – a new estimation methodology for web applications 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 Actual effort = 180 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 Actual effort = 786 person days PML 2005 Nagaraja Gundappa, Wipro Technologies 11
  • 12. MVC Points – a new estimation methodology for web applications 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 Nagaraja Gundappa, Wipro Technologies 12
  • 13. MVC Points – a new estimation methodology for web applications 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 Nagaraja Gundappa, Wipro Technologies 13
  • 14. MVC Points – a new estimation methodology for web applications 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 Nagaraja Gundappa, Wipro Technologies 14
  • 15. MVC Points – a new estimation methodology for web applications 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 Nagaraja Gundappa, Wipro Technologies 15
  • 16. MVC Points – a new estimation methodology for web applications 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: 4. System displays list of authorized users. With options to ADD, EDIT, DELETE, SEARCH and CANCEL. 5. Administrator selects name(s) of user(s) to be modified. Clicks EDIT. PML 2005 Nagaraja Gundappa, Wipro Technologies 16
  • 17. MVC Points – a new estimation methodology for web applications 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: 4. System displays list of authorized users. With options to ADD, EDIT, DELETE, SEARCH and CANCEL. 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. System displays list of authorized users. With options to ADD, EDIT, DELETE, SEARCH and CANCEL. 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 Nagaraja Gundappa, Wipro Technologies 17
  • 18. MVC Points – a new estimation methodology for web applications 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 Nagaraja Gundappa, Wipro Technologies 18