Different models for software development

Authors: Tomasz Soroka

19.10.2016

Different models for software development

We offer four different models for software development. In our opinion it's very crucial to understand them and choose a right one.  In this article I will explain a little bit how each model works and when should be used.





Fixed price

Fixed price  looks like very secure for customer...  looks and works when everything is well defined. The question is - how often project can be prepared before development on the level where we will not miss anything, everything is described very detailed and all risks are covered ? In my opinion  - not to often.
Problem starts when something is changed during development, new requirement come - what's typical for software development because is very hard to predict everything in theory and on paper. What then? How should such cases be covered in price to be sure that it's fair for  both parties? It's tough in linear model.
In most cases this model works when we for example move application one to one  from iOS to Android with shared code base, where uncertainty is on very small level and can be covered in fixed price. Another example of using fixed price is for adding new features to product in small iterations, where everything can be well calculated and product is stable. 

F‍acts:
  • Budget - is a static for project release
  • Quality - should be static but what if customer will miss something important in defined and fixed budget? How it affect quality ? In real quality depends from amount of additional work which couldn't be estimated before start of development.
  • Scope - is static for project release - every change will affect deadline, price.
  • Goal - create product according to specification and fixed budget. Very limited ability to introduce new ideas, changes... 
  • Risk - big if documentation is not enough detailed. From one side is on developer - if anything was underestimated. From second side is on customer - if he missed anything what should be done but was not put in specification.
  • Deadline - is a static variable, based on estimation we know how many weeks for development we have, but what when anything new will come? Should it affect a deadline ?




Time Material

It looks like very nice model for every development company - most of the risk is on customer side. Customer pays for everything. In real it works well  for specific projects... let's say it works in case where requirements changes very fast and working on UX/documentation is not worth effort. In general when we have time pressure, we need to build some kind of prototype then this model can be helpful. But remember You can here easily hurt You and Your customer if customer really don't understand software development process. It can be very dangerous in case of developing bigger projects.

Facts:
  • Budget - if flexible
  • Quality - is a static for project release
  • Scope - flexible - can be change when new requirements, because budget is not controlled then it's very easy to add a lot of unnecessary requirements..
  • Goal - create best possible product - in unknown budget
  • Risk - On client, but ... also on developer because probability of failure is big and can be dangerous if customer don't understand well time material model and it's goals
  • Deadline - is a flexible  variable - we don't know when development will be finished







Fixed budget

In our opinion most fair approach where best things from Fixed Price and Time Material are used.  First - budget is fixed - customer has 100% guarantee that without additional agreement it will not be exceed. Second - we have quite big flexibility with changes, improvements during development. Everything is confirmed with customer before each sprint and customer all time knows where is in comparison to original estimation. If anything new come during development then customer can decide if we should implement it and remove anything what was originally estimated or we leave new requirement for next release of product. Everything is still under control - budget and deadline force customer and developer to make right and best possible decisions:

Facts:
  • Budget - is a static for project release
  • Quality - is a static for project release
  • Scope - flexible - can be change when new requirements, changes come. It's all the time under customer's control
  • Goal - create best possible product inside fixed budget. New ideas come all the time so both parties are responsible for prioritization and deciding if we include them into release or not
  • Risk - reduced and shared by developer and customer
  • Deadline - is a static variable, based on estimation we know how many weeks for development we have





Fixed resource

Last model we use for specified works where customer need only developer support without whole development package. It can be useful in case where our competences are needed for specified time in customer's team.