One of the most complex tasks but of vital importance in the management of any software development project is sizing, which is a common cause of problems and can make the difference between the success or failure.
A software sizing can have various purposes like:
- Analyzing the economic viability of a project.
- Preparing a service proposal.
- Accurately determine the budget of a project after it has been approved.
- Establish the price of a software product.
Amongst many other useful purposes, it depends on the degree of accuracy that we need, then we'll apply the method that best fits and provides the desired outcome.
What is Software Sizing?
A software size estimate is a prediction of how long it will take and/or cost to develop and maintain a project. The sizing effort can be expressed in person-hours or another unit, the sizing cost can be expressed in the preferred currency.
The challenge in developing software is that you have to make realistic predictions based on incomplete and uncertain information.
In software engineering and software project management, estimates are used to:
- Develop project plans.
- Prepare iteration plans in software development.
- Prepare budgets.
- Perform investment analysis.
- Pricing of a software for a business client.
- Analysis to determine the price in software aimed at the consumer.
- To plan strategy when you are about to participate in contract auctions in which several suppliers participate.
Software Sizing Techniques
Software size estimation techniques can be classified into four different types:
- Software sizing by expert judgment
Software size estimation methods based on expert judgment consist of delivering software requirements (for example, meeting summary or software requirements specification document) information and delivering it to one or more responsible knowledgeable about software development and the software development business area that we want to be represented in the new system.
- Software sizing by analogy
This type of software size estimation consists of comparing the proposed software development with similar previous projects. The great advantage over expert judgment estimation is that the analogy is based on experiences that are documented, so it is based on documented numbers.
A disadvantage is that, if there are many variations in technologies and functionalities from one project to another, it will be more difficult to establish reliable estimates.
- Software sizing by decomposition
It consists of breaking down the project into components, and these into more detailed subcomponents. This type of estimation is based on the principle of dividing a problem into parts to facilitate its approach and analysis (divide and conquer).
- Software sizing by means of estimation models
It includes the use of parametric, procedural, algorithmic or other models to perform software estimates. The advantage of these methods is that by being numerically based they tend to reduce the bias associated with an estimator's judgment in making the estimates.
An example of estimation by model is COCOMO, in which a linear regression formula applied to historical data from previous projects is used, producing the estimates through this estimation function.
Another example is function point analysis, under this method, a standard classification is applied to software components, then determined amounts of function points are assigned according to their characteristics, obtaining a measure of their size.
Unlike other techniques, estimating models produce a size that is based on mathematical and statistical formulas.
How Elaniin Does Software Sizing
We as Elaniin use a mixture of software sizing techniques. To begin with and as a first instance we start with a component decomposition analysis based on the information obtained from the client, then this goes through our own model-based estimation methodology, to finally be reviewed and adjusted by our technical experts.
For us as a technology company, our clients rarely have clear and well-defined visibility or documentation of their requirements or functionalities for their digital products, and even if they do, now the world moves at a very high speed, due to which, your requirements are constantly changing or mutating, this is why our sizings remain as that, simply as an estimate. In the Tech industry software size estimation is unfortunately an uncertain and inexact science as there are too many moving parts and variables that can affect a software project.
Here are some variables to take into account to estimate a software development project:
- How much is the budget that the client wants or can invest?
- How much time does the client have in mind to launch their product into production?
- Do we need to connect with third party components?
- Do we need to connect with client-owned components?
- What software architecture will be used?
- What type of infrastructure will be implemented, local/on-premise or in the cloud?
- How complex is the UX & UI to build?
- Does the product include web, mobile and/or tablet applications?
- Do the applications require responsive behavior for mobiles and/or tablets?
- How well known is the technology to be used for construction?
- How complex is the technology to be used for construction?
- How many applications are required?
Based on the answer to all the previous points, a work team proposal must be formed, which normally includes at least one of the following roles (also indicating the level of each profile):
- Scrum Master
- Product Owner
- UX UI Designers
- Back End Developers
- Front End Developers *
- Quality Control Analysts
- DevOps Engineers**
* At least one front end developer specialized in the technologies corresponding to each type of application (web or mobile) is required.
** The DevOps engineer is an optional role depending on whether the client provides and supports the infrastructure or requires us to do so.
Based on everything explained above, Elaniin seeks to establish the best work team and an adequate timeline to execute the project based on our experience.
As additional data and recommendation, it is important that an adequate time for the inception of the project is considered in the planning, since in this stage the Minimum Viable Product (MVP) is defined. Once the MVP is defined we focus our development teams so they seek to deliver it as soon as possible; In case there is time left after the delivery of the MVP, normally we must have already defined and prioritized additional functionalities and/or requirements to continue adding value to the product, which can be built during remaining time.
We hope that this article helps you improve your project size estimates in the future and if you ever need help estimating your projects or want more information about it you can contact us!