Posts Tagged ‘Estimation’
November 28, 2009 | 
Author This blog is continuation to my previous blog – Ecommerce Estimation. In this blog we will discuss how can we break up the modules into components and come up with a ball park estimation figure. Estimations are based on expert judgment and this blog will provide an approach to follow
There are many ways of estimation and few of them are
1. Analogous estimation : This is done on variety of project parameters (like budget, scope, cost, etc) and measure of scale. This is typically a form of expert judgment and mostly reliable if previous project is similar to current project. If you are doing retail ecommerce project for second time, then you may opt this methodology.
2. Use case based model: This technique is used to do estimation based on application use cases complexity (simple, average or complex). The main disadvantage of this approach is that it doesn’t cover all non-functional requirements and most of current projects doesn’t cover all possible use cases. I recommend to go with use case model approach to come up with test effort estimation.
3. Top down estimation: This model gives senior management to control for decision making. Many companies have their own estimation tools and these calculations are derived from previous projects metrics. Note: With this estimation effort variance can come up to 100%, that means an effort estimation of 100 hrs in top-down estimate may go up to 200 hours in actual.
4. Bottom up estimation: This estimation model will give us the ability to get more refine estimate for particular component of work. Here, we will break a task into components and estimate the effort required for the tiny components and cumulating of all components gives overall project estimation. These estimates will be almost equal to actual and may go up to +/- 20% variance.
Lets discuss how can we do commerce server bottom up estimations. Commerce server development mainly contains front end (FE), Components (like pipeline, API access, etc), schema creation, etc. To develop the estimation we have to follow below approach.
- Develop factors for the application (mostly you can get them from your previous project or develop new if they don’t exist)
- Divide the application into modules/tasks/components.
- Define inventory street – to map components to factors and complexities.
- Calculate build and other estimations.
1. Defining Factors: Here are some factors and figures shown are in hours.
| Factor Name | Description | VS | S | M | C | VC |
| ASP.NET | to develop & unit test (UT) ASP.NET page | 4 | 8 | 16 | 24 | 30 |
| ASP.NET Component | to develop & unit test ASP.NET page with patterns (like MVP, MVC, etc) | 8 | 16 | 24 | 32 | 40 |
| Win forms | to develop & unit test win forms | 4 | 8 | 12 | 16 | 20 |
| Business Logic | to develop & UT business logic or work flow | 4 | 8 | 12 | 16 | 20 |
| Business entities | to develop business entities required for the application | 2 | 4 | 6 | 8 | 10 |
| Data access | to develop data access components. | 4 | 8 | 12 | 16 | 24 |
| Interface | to develop application interface (web services) to external applications | 4 | 8 | 12 | 16 | 24 |
| Tables | To develop tables required for the application | 2 | 4 | 8 | 16 | 32 |
| Stored procedures(SP) | To develop stored procedure required for the application (blind rule – 1 table = 4 SP) | 2 | 4 | 8 | 16 | 32 |
| Batch/Service programming | to develop & unit test batch or service programming | 4 | 8 | 16 | 24 | 32 |
| Error Handling | To develop error handling framework in to the application | 16 | 32 | 64 | 80 | 128 |
| Validation Framework | To develop validation framework in to the application | 16 | 32 | 64 | 80 | 128 |
| Caching Framework | To develop caching framework in to the application | 16 | 32 | 64 | 80 | 128 |
| Encryption framework | To develop encryption framework in to the application | 16 | 32 | 64 | 80 | 128 |
* Very Simple (VS), Simple (S), Medium (M), Complex ( C), Very Complex (VC)
2. Define Components : I feel this is totally expert task and a novice person can do mistakes. You should have a vision on the entire application and how it works. The goal here not only break up modules into components but also list down the assumptions you made or risks you foresee. For example, If you feel some thing you are not aware or you made an assumption for your estimate (like the third party web services will be ready by before you start developing x component). The accurate estimation comes if you close all risks and assumptions.
3. Build Inventory sheet: Now let’s bring components, factors & its weights in one sheet. This sheet can be used by the client or SME from your company to validate your estimation. Note: A component can have multiple factors.
| Module | Task | Component | Description | Factor | VS | S | M | C | VC | Notes |
| M1 | T1 | C1 | web page | ASP.NET | 1 | 2 | XXX | |||
| Business Logic | 1 | YYY |
4. Calculate Efforts: Once the inventory is completed – it is simple formula to calculate the efforts required to develop that component. In the example above ASP.NET effort is calculated as 1 * 4 (S) + 2* 16 (M), that comes to 36 hours. At the end of the exercise you will get build efforts but project life cycle contains other phases like plan, analysis, design, test, deploy, project management,etc. I recommend to calculate these phase efforts based on build efforts and this rule may not be applicable for app. packaging projects (like CRM, etc). You have to refer to company metrics to come to exact figures and generally I recommend following calculations
| Phase | % of Build |
| Plan |
10 |
| Analysis (more external systems integration exists) |
20 |
| Design (more external systems integration exists) |
75 |
| Build |
100 |
| Test & Fix (it will be more if we are going with performance, usability, security testing) |
100 |
| Deploy |
15 |
| Program Management |
15 |
You may come to tentative figure in your initial round of estimation and this figure will refine once it get reviewed by other SME or whenever the assumption is cleared. Don’t forget to add contingency at the top of the estimate. You might be thinking what is different from .NET applications and the answer is there is not difference in the methodology but the difference is in factors and their weights. Hope you might of gained some knowledge on this topic and If you have any questions or suggestions, drop me an email – kanth @ ravikanth.net.
If you like this post, please click on our sponsor advertisement.
Posted in commerce server 2007, Commerce Server 2009, Ideas | 
Tags: commerce server Estimation, Estimation | 
2 Comments »
Software development effort estimation is a process of predicting most realistic efforts required to develop a product/application. The effort estimation can be passed as inputs to find schedule, budget, team structure, etc. You can opt bottom-up or top-down estimation model or function point or use case analysis estimations but finally by doing this exercise, we are coming to some realistic figures (not exact) which drives the decision of taking the project or not or negotiating scope reduction with client as per limited schedule, effort or cost. For past few years, I have been doing many projects effort estimation. In this blog post, I am trying to record few dev. units (but not limited to) to give more concentration while doing effort estimation. Trust me, all project estimates are different (some fools think all projects are same) but few of the components can be consider as same. Ecommerce application development is so volatile and difficult as client wants or expects something different than their competitors so that they can retain or get customers.
Some of the key dev. units, where efforts will be more (than expected) a special consideration to be taken in ecommerce application effort estimation.
- Efforts to incorporate Application blocks like security (Authentication & Authorization), data access, logging, exception handling, etc.
- Integration entities
- Payment
- Tax
- backend systems like ERP, CRM, etc.
If your company has any metrics then start comparing the actual efforts with these dev. units mentioned above and for most of them actual effort will exceed than planned effort.Client will not agree if you estimate more hours to these items but at the end due to external dependencies we will end up loosing schedule if not effort.
As per my knowledge & experience here are the top 10 risks any ecommerce project has and as a project manager a special attention has to be taken to mitigate them.
- Development schedule.
- Infrastructure related risks (as commerce server application interacts with different third party or backend systems).
- Resource Utilization (productivity).
- Resource Availability (As commerce server is a niche skill – it is difficult to get experience resource availability as per delivery schedule).
- Planning and monitoring (many teams, many communications and difficult for PM to manager and monitor the project).
- Requirements & Scope Stability
- Staffing Level in Key Areas (many companies follow a specific pyramid and sometimes it may not work).
- Team sprit & motivation.
- Resource ramp-up time & Knowledge transfer.
- Internal company policies (for port enablement – 2 days, security approval – 3 days, etc).
If you have any questions or suggestions, drop me an email – kanth@ravikanth.net. In future, I will be sharing some of the commerce server specific estimation techniques.
If you like this post, please click on our sponsor advertisement.
Posted in commerce server 2007, Commerce Server 2009, Ideas | Tags: commerce server Estimation, Estimation | 2 Comments »
