"The hardest part of developing a system is deciding what to develop... no other part makes the resulting system fail so badly if it is done wrong. No other part is more difficult to rectify later."

The experience accumulated over the years of implementing projects indicates that successful projects are those that are managed following a series of processes that allow the project to be organized and then controlled.

It is undoubtedly a fundamental objective of software designers to achieve and maintain a technical level in the systems, according to the current development in the automation of information for management and direction, and it is known the importance of software engineering to raise productivity and quality in automated system designs from a detailed examination of existing methodologies.

The methodology branch, within software engineering, is responsible for developing software development strategies that promote adaptive rather than predictive practices; focused on people or teams, oriented towards functionality and delivery, communication intensive and requiring direct customer involvement.

Many researchers in their studies on the subject of software development methodologies have stopped to define the concept of methodology, some of these definitions are shown below.

In the paper "A Methodology for Database Development" it is said that a methodology is a set of procedures, techniques and documentation aids for the development of a software product.

A methodology defines: - States, stages or phases of a development, together with the criteria of transition between them. - Tasks, activities, etc. - Roles, with their necessary skills and the interactions between them. - Artifacts or deliverables. - Tools for control, follow-up, measurement and improvement. - Principles, criteria for decision making, strategies for handling different types of situations, risk management tools, etc.

The difficulty inherent in software development, and its impact on the business, has highlighted the advantages, and in many cases the need, to apply a formal methodology to carry out projects of this type.

The objective is to turn software development into a formal process, with predictable results, which will allow to obtain a high quality product, which will satisfy the needs and expectations of the client. Gone is the traditional way of working, which often requires great efforts to obtain the final result, with the consequent mismatch of dates and costs, and it is more than likely the personal wear of the project team. So using the methodologies implies improvements in the development processes, in the product and in the customer satisfaction.

Improvements in the development processes - All the members of the project team work under a common framework. - Standardization of concepts, activities and nomenclature. - Development activities supported by procedures and guidelines. - Predictable development results. - Use of software engineering tools. - Planning of activities based on a set of defined tasks and experience in other projects. - Collection of best practices for future projects. Product improvements - It ensures that the products meet the proposed quality objectives. - Early detection of errors. - Product traceability is guaranteed throughout the development process. Improved customer relations - The customer perceives order in the processes. - It makes it easier for the client to follow the evolution of the project. - Mechanisms are established to ensure that the products developed meet the customer's expectations.

Sometimes, the designer, when choosing between the variety of languages, techniques, methods and others, prefers to do things as best suits him and get the design out as soon as possible, which turns out to be a not very good decision, that more than helping to have a system working as soon as possible, it turns out to be a not very functional system where the later generation of errors will abound.

A bad practice in software development is to start trying to develop without to perform any kind of analysis, trying to start from the data model; this generally has drastic consequences since there is no order to solve the problem. The need to follow an orderly process arises, this is the Methodology.

The Methodology is defined as the set of procedures based on logical principles that are used to achieve an objective. Following a structured process that is adapted to a specific situation at the time of developing a software increases the probability of success, since these methodologies have been tested under certain factors in a specific context and have been successful, so integrating it into the project is to identify which methodology best fits the situation and use it.

Documenting the software is necessary regardless of the development strategy we follow. A good documentation will allow us to maintain a complete vision of the software, helping us to understand the characteristics of the system and to modify it if necessary. Documentation is not done for oneself, but for others, helping to eliminate dependency on people.

Therefore, documenting a software will always be useful, even if it may not seem so at first. Having good documentation, proportional to the size of the software developed, can be as important as having good software.

One of the big problems that software development faces, is the little use of methodologies, the small and medium companies believe that the use of methodologies is only for the big ones, the position of the companies before the market, is that they want the complete product as fast as possible, so they do not consider the necessity of a methodology, as they do not look at the short term advance, they feel it a waste of time and prefer to start developing as soon as possible without dedicating time to the analysis and design of the software. The little acceptance and ignorance is one of the biggest challenges towards the methodologies since the fundamental importance in the software development is not understood, when not being used the consequences can be catastrophic, the software instead of being a solution to the problem, becomes another problem to solve. Methodologies impose a disciplined process on software development in order to make it more predictable and efficient. They do this by developing a detailed process with a strong emphasis on planning inspired by other engineering disciplines.

Software development projects, especially those of great size where it takes many iterations to have an important part of it in operation or even more, those that follow a life cycle in scale, suffer important contingencies that can cause it to get out of hand, no matter how much effort is invested.

Contingencies? Among them, it is very typical to find the case of some, such as: poorly defined or implemented functionalities, deficient prioritization of developments, processes that before were of one form, after are of others and later are modified again, etc... that later nobody wants to be responsible and even more if we find functional managers that leave and then come others with other ideas or focus and who have to continue with the work.

In the end, when the deadlines are over and/or the budget begins to run out, there is a rush and people start asking for responsibility, usually on the wrong side, that of the developers. At this point, especially if explanations are requested at higher levels of the hierarchy, the crisis arrives.

Why isn't it there, I've spent so much and have no results, I thought this was more advanced and still has a lot left, I need it for now, and all that long etcetera that we are used to hearing.

Crises are not solved by shouting or pressing more, but they require an orderly work and it starts by assuming each part that there is a problem and the role it has played in it. That really is the most important and difficult thing in solving the crisis, to recognize that there is a problem and that you have been part of it.

It is not a question of making a clean sweep of what has happened. Whoever has made a mistake must assume the decisions he has made and the work he has done (or if it was not his direct fault, make his predecessors' decisions his own in his role) and assume the consequences of it. However, this is something that should be taken into account when it is more appropriate for the project.

Once the problem is recognized, decisions and mistakes are made, the way is clear and the effort is released to start taking the necessary actions to redirect the project, something that will not be easy either.