Estimating software efforts: constraints and solutions

TLDR. We all know that software development is a process that requires a handful of planning, organization and estimation. But just how complex it is, might still be a mystery. Hence, this article. By the end of it, you’ll learn that the estimation part is a crucial one in software development because it helps the project’s team to determine the scope, resources, and time required to complete a project successfully. You’ll also have a pretty good insight into the parameters taken into account when generating an effort estimation, such as functional and non-functional constraints and the technical details that indicate the exact construction method of the app. If all this becomes overwhelming, do not despair, we are also offering a solution.

What is it

Software estimation is the process of forecasting the costs involved with the creation of a software application, given a set of clearly defined constraints. These costs embody the labor put forth by business analysts, user experience designers, software architects, project managers, developers, quality assurance engineers, DevOps engineers and product owners in order to construct a finite and functional software solution.

From a software development company’s perspective, this Waterfall estimation can be performed accurately only after the following three descriptors are well known and understood:

• The functional constraints of the application or what the app is expected to do in all contexts;
• The non-functional constraints of the application or how the app is supposed to fulfil the functional constraints;
• The architectural constraints or how exactly should the application be constructed

In other words, before embarking on the journey of developing a software application, it is essential to have a clear understanding of what it needs to achieve, how it should perform, and how it should be built. This is the moment when technical and business perspectives meet.

Why is it relevant?

Software estimation is relevant because it represents the process of predicting the time, cost and resources needed to deliver a project. This process allows for stakeholders to plan concrete cost strategies regarding the construction of software solutions.

Although the software industry prefers the Agile approach in which customers pay by the hour while software companies allocate resources to their cause in the attempt to figure out the next steps, it is our opinion that the best way of handling software projects is by incrementally crafting a vision and estimating the effort for reaching it. This in fact is not that absurd, as this is the way in which states and large enterprises allocate project budgets. They request fixed price offers from multiple providers, then compute a median of offers and establish a hard budget for a project. As software projects can fairly easily get out of control when it comes to costs, this method ensures that everything is kept within a tight budget.

But sizing software development projects is usually a hard endeavor as these projects can either be constructed from scratch or extended with new functionality. This raises the complexity of performing estimations considerably for the software companies, which need to have an anchoring point on which to base their estimations on. And that anchoring point is given by the state of specification for the project. The more concrete specification, the easier the estimation process.

How it’s done

In order for a software development company to be able to estimate the costs required for the manufacturing of an application, it must have a clear specification as the basis of its estimation. Furthermore, the software company should have a means of converting this specification into required development labor time, that can be estimated and quantified into a monetary amount.

This is why companies require a mental model for viewing application requirements in a way in which they can also place an estimate on their development effort. And this mental model goes something like this:

• An application is practically a collection of modules that allow users to perform certain actions (think of the authentication module of almost any application);
• A module is practically a collection of features that the user can use in order to satisfy various usage scenarios (think of the common features of an authentication module, such as login, register, recover password and so forth);
• A feature is a collection of tasks, that developers need to perform in order to implement its functionality. If we think about a login form, developers will have to implement both the user interface and the backend logic for it to be considered a functional feature;
• A task is practically an activity that can be done by a developer in a certain time frame.

Starting with this mental model, let’s take an example for estimating a simplified version of an application like WhatsApp.

Our simplified WhatsApp should allow its users to authenticate via their phone numbers and to send instant messages to the contacts imported from their phones. This application basically has two modules, an Authentication Module that covers the authentication of each of its users and an Instant Message Module that allows its users to interact with each other. Each of these modules have a finite set of features that can be quantified into development tasks. As these tasks are quantifiable into effort, this is the basic cost driver for the estimation. A simple schema, illustrates this topology:

(App) WhatsApp:

• (Module) Authentication(Feature) Register a new account with phone number(Task) Implement Register form on the UI(Task) Implement Register logic(Feature) Login with an existing phone number(Task) Implement Login form on the UI(Task) Implement Login logic(Feature) Recover an account(Task) Implement Recovery form on the UI(Task) Implement Recovery logic
• Instant Message Module(Feature) View all contacts from phone that have the app(Task) Implement Contact listing on the UI(Task) Implement Contact listing logic(Feature) See chat for a certain contact(Task) Implement Chat on the UI(Task) Implement Chat logic(Feature) Send an instant message to a contact(Task) Implement Send functionality on the UI(Task) Implement Send logic (with under 100ml delay constraint)(Feature) Receive an IM from a contact(Task) Implement Receive functionality on the UI(Task) Implement Receive logic (with under 100ml delay constraint)

Since each task has its own estimation, adding up the estimations for each task will practically give us an amount of time needed for implementing our WhatsApp application. And if we know the time needed and the team that will implement the application in that time, we can clearly output a cost for implementing the application. Pretty neat!

Pros

Understanding the software estimation process is like a win-win solution: it helps you, as a client, to have a structure of what you need, providing, at the same time, precious details about each functionality you are choosing to have; at the same time, the resulted document speaks a language that software development houses speak – the document will offer a pretty good idea of the resources needed to put that solution in motion.

Cons

We can’t really think of one single downside of using a tool for estimations.

Just for the sake of it, if it does one thing, that is to slightly push you to think twice in matters of priorities. What do we mean by that? Well, once you decide that speed and budget are the most important aspects for you, keep in mind that the end quality of the product might be affected. Or if you decide from the get-go that quality and budget are most important, the speed of the delivery might be affected.

Conclusions

We truly hope that we managed to explain how important it is to have at least an initial idea regarding estimating software efforts and regarding what a software development house needs to know from the start so that the delivered solution will respect your vision as a client.?With a proper estimation, you can be confident that your software development project is on a good path.

See you around,

abac software