All inspired entrepreneurs, who want to create a mobile startup, always have ideas, many ideas at the earliest stages, twice as many during development. It’s vital to structure these ideas and it’s quite logical that every software project starts with defining cost and delivery deadlines; in other words, with an estimation for software development. They want to know how to estimate the cost of their software projects. The available scope must be divided into smaller blocks until each block is understandable and can be evaluated.
There must be added time for testing, project management, integration, communication, and possible risks. It looks rather simple, but there are many factors that affect the precision of a software project estimate:
- precision of requirements
- changes in requirements
- margin of error
- risks
- human factor
Naturally, it only looks simple. Now, we are going to take you deeper into this process. Since we specialize in mobile development, we’d like to discuss the most popular startup solution – the development of an MVP (Minimum Viable Product) for an iOS application.
What Is MVP?
MVP is a software product created with minimal costs and time, but it provides the user with a certain value, a certain set of features. It is not an unfinished product. The user gets a viable version that will receive more features in the future. MVP helps solve the same problems as a regular software product, although in a simpler way. For example, a person must move from point A to point B in real life. A skateboard will make a good start. When this person starts earning more money, they’ll purchase better vehicles.
Two Approaches To Estimation Of Software Projects
Estimates may be carried out for agile or fixed software development methodology. There are two main models.
Estimate for agile software development is an approximate evaluation of the project that depends on the requirements that are available at the moment. It’s not the final estimate but rather preliminary calculations. What are its advantages?
- Software product requirements can be easily modified during development, when the whole picture becomes more or less complete.
- This estimate can be given even with a conceptual description of the requirements.
- It is provided quickly, which means an earlier start of development.
- It doesn’t require deep elaboration before the start; every product owner knows that it’s hard to work out everything when the idea isn’t formed yet, and you want to improve something now and then.
The main drawback is, this estimate can be several times smaller than the final software development cost, because changes in requirements, initiated by the product owner, are mostly inevitable.
Estimate for fixed price software development carries a precise price of the software project that is based on detailed requirements. What are its advantages?
- Software product requirements are clear, everyone understands what the outcome must be.
- Therefore, deadlines and costs are also known.
The drawbacks are:
- All the requirements must be formed precisely before the software project kicks off.
- The requirements are fixed. Any changes lead to re-estimations and new contracts based on them. In other words, flexibility is lost.
- This estimate takes more time.
- This estimate is impossible without UI/UX design estimation, acceptance criteria, and product specification. This slows things down.
Which approach should be chosen? It’s the decision of every software product owner. One thing can be said for sure: detailed product requirements mean more precise estimates, which enables optimal budget planning. The earlier the requirements are defined, the simpler and cheaper they can be implemented. During the analysis, it’s very easy to change them. But as the software project progresses, it gets harder and harder.
How To Prepare Requirements For Software Product Estimation
The perfect situation is when there’s a design, an application map, or a clickable prototype, accompanied by a document that contains a general description of the application and a text description for every screen or feature.
Example: a login screen in a typical application. We’ll start with the description:
The login must contain the company logo in the top part of the screen, 2 input fields (“email” and “password”), as well as buttons “Sign in”, “Facebook”, “Terms of Use / Privacy Policy”, “Register” and “Forgot password?”. Upon tapping “Sign in”, a request with account data is sent to the server, field validation is performed on the server, the application shows messages about success or failure of this operation depending on the response from the server. Upon tapping “Facebook”, the application asks the user for access to their account. If the user gave permission, enter. If doesn’t, an error message must be shown. Upon tapping “Terms of Use / Privacy Policy”, the application must show a simple screen with the corresponding text. Upon tapping “Register”, the user is led to the registration screen. Upon tapping the button “Forgot password?”, the user receives an alert that asks for an email to send a link for a password reset.
Such a description with a design sketch already shows how many input fields and buttons are there, what each one does, what the logic is, and what requests will be processed on the server. Then we can apply Agile methodology to change the screen design, add sign-in via Twitter, check the existence of the email during the input, add animations, and lots of other things – the rest depends on wishes, ideas, and budget, of course. If we take a fixed development estimate, this stage must already have a final approved design, password validation rules, a list of social networks for authentication, and a lot more. Each change in the existing requirements requires re-estimations. Besides that, the preparation of requirements helps understand functional gaps in the application. For example, if there is a login, there must be registered. This way of forming software requirements is brief and understandable. This helps technical and non-technical team members understand each other clearly.
In order to create good software product requirements, it’s important to decide on covered platforms and technologies. It may be native or cross-platform development. Native development makes a highly responsive application that can utilize all the capabilities of a selected operating system. Native development is optimal for the majority of users of different groups, who value the visual part. Cross-platform development brings the advantage of making an application for two or more platforms. This works best for software products that have to be launched as soon as possible, with minimal expenses, and used on several platforms.
Choosing A Platform For Software Development
iOS is the most profitable operating system, according to App Annie, so product owners tend to start there.
Currently, the best solution in a software project is to support the latest two OS versions. It’s important to look into the future and define supported OS versions that will be relevant at the launch of the product. It’s impossible to evaluate support for an OS version that doesn’t exist yet, but one can avoid supporting an OS version that will be obsolete at the moment of launch.
It’s optimal for the first version to support the portrait orientation of the iPhone only. The app will be compatible with the iPad anyway.
Later it will be possible to add full support for the iPad, but for our MVP an iPhone version is quite enough. It’s one of the most widespread practices in software development.
Logical Units
Your requirements should form logical units that will be evaluated separately. Tasks that are dependent on each other should be joined in units. For example, in our MVP there must be login with email and password, as well as Facebook. It’s reasonable to evaluate them separately. Most frequently, every screen is a logical unit, but sometimes you can break it further into several units.
If the estimate surpasses the budget, an analysis will help exclude the least important features. For example, it’s possible to leave login with Twitter for the next version. This is how we can simplify the requirements without making yet another estimate – and we can do it until we get an estimate that fits well with the budget. Nevertheless, there are cases when cutting the functionality makes no sense, because it would be impossible to get the desired MVP. Instead, it’s possible to simplify the navigation, design, and animations in the application. When creating the first version of an application, it’s enough to use system animations, system controls, with minor customization of colors, backgrounds, fonts, etc. This is a very easy way of creating a good-looking application within a short period of time.
These screens, taken from software products called WhereFortune and Inspiration Quotes by MobiDev, are made mostly with standard controls with a few custom elements. It’s the background and images that changed the application beyond recognition.
Sometimes it’s better to make things simpler and launch the product on the market quickly instead of waiting for competitors to occupy your niche.
Optimize Implementation, Deliver Faster
Testing and management go in parallel with development. As practice shows, average testing of a mobile app takes about 30% of total time spent on development, while management takes about 10% of development and testing.
Design and development can go in parallel too. This approach can reduce the time but increase the cost; development may be started earlier, but it’s going to take more time because before the design is ready, the developer will have to sketch the interface according to the available text description and personal experience. When the design is ready, there will be changes in navigation, structure, etc. It takes additional time.
We can say that testing and management increase the scope of work and, consequently, the price—but they don’t increase the duration. In other words, the duration of development basically equals the time spent by the developer.
In many cases backend takes the major bulk of time and effort, because the most complex business logic is performed there. Obviously an app with backend cannot be finished earlier than the backend itself. In such cases, it’s reasonable to start developing the backend earlier. First, calculate the difference by subtracting the app estimate from the backend estimate. Then, plan to finish them at the same time.
For example, if the backend is estimated to take 600 hours, and the app – 520, the work on the app should be started 80 hours (2 weeks) later—which is approximately the amount of time averagely required for the design. This makes the perfect start of the project: we start with the design and backend development, after the design is ready, we start the development with some basic functionality already implemented on the backend. The deadlines must match. When the design is ready, the front-end developer will already have the design and basic functionality of the backend, which allows painless development. This approach makes for the optimal balance between cost and duration of development. This project plan is shown below as a Gantt chart.
It’s necessary to be careful with deadlines. They shouldn’t be cut severely, because the quality of the product may suffer. On the one hand, the product shouldn’t be under constant improvements that aspire for the unreachable perfection. On the other hand, deadlines cannot always be identified precisely. The task of estimating software development is hard by itself, but as well there are numerous external factors that make it impossible to foresee everything.
Risks In Estimation Of Software Development
Here are the risks that can be faced by product owners and software development teams.
• There are cyclical risks of predictable character. For example, we know that every June Apple presents a new iOS version, and a new generation of iPhones is presented every September. Everybody knows when it happens, but no one knows for sure what exactly to expect. Therefore, it’s hard to say how many adjustments of the application code will be required, and how many hours it’s going to take to make the software product support the new generation of the OS and devices.
• There are also periodical risks. For example, Facebook regularly updates its iOS SDK, but no one knows whether it’s going to happen during the development or not, and if it happens, what the consequences are going to be. As a rule, 3rd-party libraries or APIs bring periodical risks, because you never know when the next update is going to be. But one shouldn’t be afraid of updates, because their absence may bring even more troubles.
• There are random risks. For example, the development kicks off, and suddenly a competitor appears with the same product. Making a copycat is not the solution, so you have to think over something new, something to put your product ahead of the competition. You understand that this can’t be foreseen.
Risks can also be internal or external. External risks comprise everything beyond the software company: update of a third-party library, a new OS version, a new device on the market, competitive products, changes in requirements, failures of external services, and servers. Internal risks comprise everything that happens in the software company: vacations, employees quitting, misunderstanding of requirements by team members, errors in project estimates.
As a rule, all the abovementioned risks are not estimated but considered – you need to know them and keep them in mind. Any estimation of these risks is no more than guesswork; an estimate must be made on an actual basis only.
How Many Developers Does A Software Project Need?
Depending on the size of the software project, the involvement of additional developers can speed up product development, but it increases the total time required for the accomplishment of tasks.
The percentage increases for every subsequent developer.
Let’s take an example: the software project duration is 3 months: that is 480 hours. Cost and duration are directly proportional. This is an “up to 500 hours” project, so each subsequent developer gets +35%.
For 2 developers (+1 to the current one) there will be 480*(1+0,35*1) = 648 hours – the total amount, this means that the cost grew 35%, and the duration (648/2 = 324 hours) is reduced by 1.48 times.
For 3 developers (+2 to the current one) it’s 480*(1+0,35*2) = 816 hours. The duration is 816/3 = 272 hours – reduced by 1.79 times.
It’s also important to understand that separate tasks are not performed faster, on the contrary, they take time because developers communicate with each other, agree on the architecture, merge the code in GIT, etc. You may speed up your development by parallelizing tasks, but some of them can be accomplished only successively.
Let’s look at a graph that shows how we speed up the development by the involvement of several developers, and how the costs grow accordingly. This is exemplified by a software project that takes 1 developer and 3 months (480 hours).
It’s easy to see that more than 3 developers is an excess for this project.
Let’s take a look at a project that takes 2,500 hours: Not more than 5 developers should be involved in such a project.
Even if you outsource software development—paying only for the hours spent on your project—excess of developers on smaller projects is not one of effective techniques. There will simply be too little space for them. For small startups and MVPs one developer per platform or direction—in rare cases two—is quite enough. It’s important to understand that these calculations are valid by the involvement of several developers per platform or direction – not the whole project. Developers that work on different platforms/directions don’t increase development time.
Conclusion
Software product development requires the careful elaboration of its functionality. Requirements must be formed properly. Goals must be defined clearly. The team must be well-acquainted with all the models and techniques of estimation. Approach to software development can be selected according to the goals. The first version of the app shouldn’t be over featured. If the budget can’t allow everything, some features may be postponed for the next version, and these features should be defined. The product owner should be open to developers’ suggestions for cutting time by using standard UI elements or other ways that a specialist may suggest. It’s vital to keep an eye on risks and be ready for them. And it’s always good to avoid the haste of recruiting a large team for a small software project.
