seven basic development methodologies

Software product development knows many worthy methodologies - in other words, well-established best practices. The choice depends on the specifics of the project, the budgeting system, subjective preferences and even the temperament of the manager.

1. “Waterfall Model” (cascade model or “waterfall”)

One of the oldest implies the successive passing of the stages, each of which must be completed completely before the next one. Waterfall makes it easy to manage a project. Due to its rigidity, the development takes place quickly, the cost and time are predetermined. But this is a double-edged sword. The cascade model will give excellent results only in projects with clearly defined requirements and methods for their implementation. There is no opportunity to take a step back, testing begins only after the development is completed or almost completed. Products developed on this model without a reasonable choice of it may have shortcomings (the list of requirements cannot be adjusted at any time), which becomes known only at the end due to the strict sequence of actions. The cost of making changes is high, because for its initialization you have to wait for the completion of the entire project. However, the fixed cost often outweighs the cons of the approach. Correction of perceived deficiencies in the process of creation is possible, and, in our experience, requires from one to three additional agreements to the contract with a small TK.

With the help of a cascade model, we have created many projects from scratch, including the development of TK only. Projects about which it is written on Habré: medium - X-ray microtomograph, small - auto-update of Windows service on AWS.

When to use cascade methodology?

• Only when the requirements are known, understood and fixed. There are no conflicting requirements.
• There are no problems with the availability of programmers of the necessary qualifications.
• In relatively small projects.

2. "V-Model"

Inherited a step-by-step structure from the cascade model. V-shaped model is applicable to systems that are particularly important uninterrupted operation. For example, application programs in patient monitoring clinics, integrated software for emergency airbag control mechanisms in vehicles, and so on. A feature of the model can be considered that it is aimed at thorough verification and testing of a product that is already at the initial stages of design. The testing stage is carried out simultaneously with the corresponding development stage, for example, unit tests are written during coding.

An example of our work based on the V-methodology is a mobile application for a European mobile operator that saves roaming costs during travel. The project is carried out according to a clear TOR, but it includes a significant stage of testing: interface convenience, functional, load and including integration, which should confirm that several components from different manufacturers work together stably, it is impossible to steal money and loans.

When to use the V-model?

• If thorough testing of the product is required, then the V-model will justify the idea: validation and verification.
• For small and medium projects where requirements are clearly defined and fixed.
• In the conditions of availability of engineers of necessary qualification, especially testers.

3. "Incremental Model" (incremental model)

In the incremental model, the total system requirements are divided into different assemblies. Terminology is often used to describe the phased build of software. There are several development cycles, and together they make up the multi-waterfall life cycle. The cycle is divided into smaller, easily created modules. Each module goes through the phases of requirements definition, design, coding, implementation, and testing. The development procedure for the incremental model involves the release of the first major stage of the product in the basic functionality, and then the sequential addition of new functions, the so-called "increments". The process continues until the complete system is created.



Incremental models are used where individual change requests are clear, can be easily formalized and implemented. In our projects, we used it to create a DefView reader, and then a network of Vivaldi electronic libraries.

As an example, we describe the essence of one increment. The network of electronic libraries Vivaldi has replaced DefView. DefView was connected to one document server, and now it can connect to many. A storage server is installed on the site of an institution that wants to broadcast its content to a specific audience, which directly accesses documents and converts them into the desired format. A root element of the architecture appeared - the central server of Vivaldi, acting as a single search system for all storage servers installed in various institutions.

When to use incremental model?

• When the basic system requirements are clearly defined and understood. At the same time, some parts can be refined over time.
• Early product launch required.
• There are several risky features or targets.

4. “RAD Model” (rapid application development model or rapid application development)

The RAD model is a variation of the incremental model. In a RAD model, components or functions are developed by several highly skilled teams in parallel, as if several mini-projects. The time frame of one cycle is strictly limited. The modules created are then integrated into one working prototype. Synergy allows you to very quickly provide the client with a view of something working in order to get feedback and make changes.



The rapid application development model includes the following phases:

• Business modeling: defining a list of information flows between different departments.
• Data modeling: the information collected in the previous step is used to identify objects and other entities necessary for the circulation of information.
• Process modeling: information flows link objects to achieve development goals.
• Build the application: using automatic assembly tools to convert models of the automatic design system in the code.
• Testing: testing new components and interfaces.

When is the RAD model used?

It can be used only in the presence of highly qualified and highly specialized architects. The project budget is large to pay for these specialists along with the cost of the finished automated assembly tools. RAD-model can be selected with a confident knowledge of the target business and the need for urgent production of the system within 2-3 months.

5. “Agile Model” (flexible development methodology)

In the “flexible” development methodology after each iteration, the customer can observe the result and understand whether it satisfies it or not. This is one of the advantages of the flexible model. Its disadvantages include the fact that, due to the lack of specific wording of the results, it is difficult to estimate the labor costs and cost required for development. Extreme programming (XP) is one of the most well known applications of the flexible model in practice.

This type is based on short daily meetings - Scrum and regularly recurring meetings (once a week, once every two weeks or once a month), which are called Sprint. At daily meetings, team members discuss:

• report on the work done since the last Scrum'a;
• a list of tasks that the employee must complete before the next meeting;
• difficulties encountered during the work.

The methodology is suitable for large or focused on a long life cycle projects that are constantly adaptable to market conditions. Accordingly, in the process of implementing the requirements change. It is worth remembering the class of creative people who tend to generate, issue and test new ideas weekly or even daily. Agile development is best suited for this psycho type of executive. We develop internal startups of the company on Agile.
When to use Agile?

• When user needs are constantly changing in a dynamic business.
• Agile changes are implemented at a lower price due to frequent increments.
• In contrast to the waterfall model, in a flexible model for the start of a project, only a small planning is enough.

6. “Iterative Model” (iterative or iterative model)

An iterative life cycle model does not require a complete specification of requirements to begin with. Instead, creation begins with the implementation of part of the functional, which becomes the basis for determining further requirements. This process is repeated. The version may not be perfect, as long as it works. Understanding the ultimate goal, we strive for it in such a way that each step is effective, and each version is efficient.



The diagram shows an iterative “development” of Mona Lisa. As you can see, in the first iteration there is only a sketch of Gioconda, in the second - colors appear, and the third iteration adds detail, saturation and completes the process. In the incremental model, the functionality of the product is increased in pieces, the product is composed of parts. Unlike the iterative model, each piece is an integral element.

An example of an iterative development is voice recognition. The first studies and the preparation of the scientific apparatus began long ago, in the beginning - in thoughts, then - on paper. With each new iteration, the recognition quality improved. However, the perfect recognition has not yet been achieved, therefore, the task has not yet been completely solved.

When is it best to use an iterative model?

• The requirements for the final system are clearly defined and understood in advance.
• The project is large or very large.
• The main task should be defined, but implementation details may evolve over time.

7. "Spiral Model" (spiral model)

The “spiral model” is similar to the incremental one, but with an emphasis on risk analysis. It works well for solving critical business problems, when failure is incompatible with the company's activities, in terms of the release of new product lines, if necessary, scientific research and practical testing.

The spiral model involves 4 stages for each turn:

1. planning;
2. risk analysis;
3. construction;
4. evaluation of the result and with satisfactory quality, the transition to a new round.

This model is not suitable for small projects, it is reasonable for complex and expensive, for example, such as developing a document management system for a bank, where each next step requires more analysis to assess the consequences than programming. Two meetings on changing the codification of electronic archive sections take 10 times longer on a project to develop an EDS for the ODU of Siberia of the UES of Siberia than combining two folders by a programmer. The state projects in which we participated began with the expert community preparing a costly concept, which is not always useless, because it pays off on a national scale.

Summarize

The slide shows the differences between the two most common methodologies.

In modern practice, software development models are multivariate. No only true for all projects, starting conditions and payment models. Even Agile, so beloved by all of us, cannot be applied everywhere because of the unreadiness of some customers or the impossibility of flexible financing. Methodologies partially overlap in tools and are somewhat similar to each other. Some other concepts were used only to promote their own compilers and did not introduce anything new into the practice.