What are the current methodologies for custom software development? Or, in other words: what should you expect when you ask a software development company to have your requirements met? This is a far from obvious question, and for many different reasons. It should be noted first of all that there are different methodologies for software development, which can lead to different consequences for the customer. In fact, there are methodologies universally - or almost universally - considered more effective, which tend to lead to the development of better solutions, but which, as we'll see, require a significant commitment from the customer. And there are other methodologies, which many labeled as outdated, which require much less participation from the client, but with results that are not equally guaranteed. Starting from this premise, we will try to explain which are the methodologies for the development of custom software that we follow at Onectus, hypothesizing two types of project, one smaller and one larger
Before seeing what are the best methodologies for software development, it's worth quickly discovering in which cases companies should request the creation of ad hoc solutions. We must say that requests for development from scratch of custom software are quite rare. This is because, simply, the market offers a wide range of management and ready-made programs, a range that makes it inconvenient to develop solutions natively customized. When we talk about custom software, in most cases, we therefore refer to integrations at the backend or frontend level to make existing platforms more efficient, or to custom software created specifically to make new scenarios.
Starting from the assumptions seen above, we understand that only the company that has specific needs - which cannot be met by ready-made solutions on the market - requires the development of custom software. This leads us to another consideration: the needs of this company will be largely peculiar, not common. It is therefore clear that the first and fundamental difficulty of those who develop custom software and management is precisely to understand what are the real needs, problems and peculiarities of the customer.
Therefore, the first concern is to understand what the customer needs. And this is where the classic methodology for software development starts, the famous waterfall, where all the steps follow one another in a cascade sequence: first the meeting with the customer, then the preliminary analysis, then the development work according to the predefined requirements, finally, the test, followed by the delivery of the software. Easy, isn't it? Simple, for the client as well as for the developer, who goes through the analysis process for weeks or months and, once he receives the client's approval, he dives into the development for further weeks or months.
We have seen the classic methodology, cascading, dominant over the years in the 90s and until a few years ago. The problem, however, is that in today's world, and increasingly so, progress at technological level is very fast. The preliminary analysis carried out a week before, hyperbolically, is already old the week after: a software developed on the basis of what was written two, three or more months ago, from this point of view, can only be largely obsolete even before being delivered to the customer. But that's not all, as we must consider the possibility that the client forgets to transmit important information before the preliminary analysis phase. This can happen for a variety of reasons: forgetfulness, carelessness, new problems, and the simple fact that at the beginning of a project it is not easy for the customer to know exactly what the software will do when it is finished. Therefore, developing a software according to the fixed prerequisites is not the same as developing the best possible software.
So there are too many variables at play to allow a cascade approach, with the risk of ending up with hours and hours of analysis and development to be discarded. For this reason, we at Onectus have adopted the agile development methodology.
The goal, with the agile development methodology, is no longer to satisfy the prerequisites: the goal is instead the full satisfaction of the customer's needs. Leaving behind the forced and obsolete waterfall methodology, we proceed instead with the development of small parts of the project in a short time, continuously. When a new piece of software has been developed, it is delivered to the customer, to have a field test: the customer is then called-in often, to test not complete (but working) pieces of software, thus having the certainty to have at the end of the work a perfect custom software, that really meets every requirement - even the one that was not expressed at the beginning.
We have seen that, in the current scenario, the agile methodology undoubtedly represents the best approach to software development. This is why at Onectus we firmly stick to these principles, but we take a further step, which leads us to divide projects into two groups: on the one hand, there are the small projects (which may take a month's work, for example), and on the other, there are the large projects (which may take a year or more).
In both cases, the confrontation between the developers and the client company must be continuous, and for this reason it is fundamental to identify a contact person within the company. We're not talking about a technician, nor a person with particular IT skills: the important thing is that the contact person is perfectly familiar with the company's needs, has the decision-making power to be able to move the project forward without obstacles and is willing to follow the work regularly.
Starting from the definition of the figure of the contact person, it is clear that in smaller projects, and therefore shorter, in which the relationship is continuous and direct between developer and contact person, the agility of development is even greater, with the possibility of defining deadlines according to the needs of one and the other.
In larger projects, even if starting from an agile approach, a general planning is necessary, with the need to define, for example, the deadlines for the various software releases: one could, for example, decide upstream the delivery of a new release every 4 weeks (even if with the possibility of shortening or lengthening the intervals between one delivery and another according to the needs of the actors involved and the particularities of the single development activities). The larger, longer project is still agile and dynamic, although with a longer schedule than the shorter project.
Does your company need a customized software, an integration or a customization of the management system? To satisfy your requests we will follow the agile methodology as set out on this page, to be sure to develop the most effective solution for your organization.
Would you like to receive updates on IT news and best practices? Subscribe to our newsletter now: we will share with you few but valuable contents for your company!
