Listed below are the key factors that are to be considered while starting estimation for an application, as they may have significant impact on cost as well as overall schedule. Level of impact will vary based on the nature of the team that is going to carry out the development. Even though we can think that some of these factors are any way considered for estimation implicitly, they are listed here explicitly to ensure that they are not missed. So when we get a RFP to respond, keeping a ‘special eye’ on these factors will help us in arriving at a reasonable ‘ball-park’ figure.
Even we can allocate a percentage against each of this factor to indicate the level of impact each one has on overall estimation. After the execution of the project, these percentages can be verified with the actual figures and it can be used as benchmarks in subsequent estimation for similar types of application developments. There could be multiple factors that are related to these percentages. Once these factors are well documented, it will help in arriving at reasonable percentages upfront. It will help in arriving at reasonable assumptions when estimation is carried out with the limited availability of information. Also, it will help us to put required, relevant questions to clients before starting the estimation so that the ‘ball park’ figure will be close to actual one.
- Nature of Integration with the legacy systems / other home grown internal applications / COTS applications / Partner integration
Some COTS products are service enabled so that it may be comparatively easy for integration. Same thing is applicable for SOA based applications. But when you have to deal with proprietary APIs or other types of integration like watching a particular folder for files based on some naming conventions and pre-defined templates, then it will impact the schedule. Similarly, in the scenarios where there is a need to integrate with partner systems like consuming partner web services , generating data in a pre-defined format, interacting with proprietary systems of partners etc. then additional time will be required because of the effort involved in learning.
- Proposed Architecture style of the application
When the proposed architecture of an application that is to be build is based on ‘client server’, then it will be comparatively less time when compared with that where a multi-layered, multi-tiered architecture is proposed. Development has to happen across multiple layers and similarly also the testing. In addition to that, system has to be tested in a distributed environment. All these will impact the schedule
- Nature of development platform
If the application development is proposed on a ‘homogenous’ platform then it will need less time when compared to a development where it has to be carried out on heterogeneous platforms. Testing related to ‘interoperability’ issues will add time in addition on other normal tests.
- Significant Non-Functional requirements
Usually as part of ‘system requirement specification, non-functional requirements will be specified. In some scenarios, there will be a special demand on a particular QoS attribute. Say for example, in banking domain, the applications will be subjected to lots of security vulnerability tests like litmus testing, smoke testing, sanity testing, penetration testing, etc to ensure data, application, infrastructure and communication security. This is not a common requirement in general app. development scenarios. So in case of such special ‘Non-functional requirements’ extra time is required towards these additional tasks. These things may not be explicitly specified by clients. Based on the application nature, only the estimating professional should identify the need of such special tasks as part of development cycle and accordingly budget it. Also, they have to educate the customers as well to avoid any miscommunication.
- Life of the application / product
If the life of the application is going to be long, then lot of efforts will go towards good design so that the application does not need to undergo frequent fixes & changes. Similarly, if the final product is like a ‘app. Development framework’ based on which further applications will be developed in an Enterprise, then lot of time has to be spent to ensure that the framework will include all common functional and infrastructure components .
- Compliance to regulatory requirements
Additional learning curve and development effort to deal with industry standard data formats like FIX/SWIFT etc., to design the system to make it comply with regulatory requirements like SOX impact cost and schedule.
- Multilingual Capability
If an application need to be developed targeting multiple languages, then testing effort will increase based on no. of target languages. That too, if data need to be stored in database in different languages, it will add more cost when compared to the scenarios where only a multilingual display is required.