Cascade development. When is the best time to use an iterative model? Waterfall is a project management technique that involves a sequential transition from one stage to another without skipping and returning to previous stages.

A startup is a project. And when you make a project, the question always arises: how to implement it, how to organize a team. The quality of the product and the deadlines depend on the methodology by which the startup is implemented.

Why is a methodology needed? Just take it and do it!

You roughly represent your idea, approximately the time frame and what should be the result. But “about” is chaos.

And in a serious project that counts on success, there should be no chaos.

The methodology structures the mind, the team and forms a clear picture. You can see at what stage the project is, where it is moving and what step to take next.

We are convinced that we need order. It remains to make a choice which methodology to choose.

As we announced in the title, the battle will take place between Agile and Waterfall. Immediately, we note that there is no definite answer, the choice depends on the project.

But we can talk about the advantages and disadvantages :)

waterfall

Waterfall clearly structures the development of the project, we have a plan that consists of stages. Following them, we get the final product:

product idea

It is with the idea that lights up above your head like a light bulb that a startup begins. You need to clearly understand what message you are broadcasting target audience and what are your goals. This disciplines you and creates a vision for the end result.

Initiation

We assemble a team, distribute technical tasks, deadlines and fix business responsibilities on paper or a special program (ERP).

Analysis

We are looking for the best means to implement the idea, we study the market and competitors, we realize who the target audience is.

Thanks to such an analysis, the idea is transformed, elements that will not be in demand leave, and new features that are necessary for implementation come in their place.

In Waterfall, this process stands apart. The entire design is developed, the interface (front end), when the software content is unknown (back end).

Development

At this stage, we code in full. Developers adapt to the interface that the designers have created, filling it with the necessary functionality.

Testing

We get rid of bugs so that customers get the perfect product.

Product launch

We bring the project to the market, launch marketing, make sure that the whole world knows about the product! (at least the target audience)

Exploitation

The first customers appear who visit the site, buy a product or download an application - depending on which startup.

The structure of Waterfall is very simple, all stages follow each other and we know which step we will take next.

Agile

Agile is an agile development methodology. The team does not have strict stages, they are all interconnected and repeated:

The project is divided into iterations - cycles. In each of them, planning, analysis, design, development and testing are carried out.

Iterations are divided into sprints - 1 or 2 weeks, for which each team member has a task package. Every day, the team meets for briefings, sets daily goals, reports on the achievements of the previous day.

Designers are not isolated, they constantly communicate with developers and testers, update the interface for maximum quality and usability for future clients. The analysis is carried out constantly with the same goals.

The whole process is as flexible as possible, after each iteration the team receives a potentially working product that they analyze and can improve.

Let's look at the advantages and disadvantages of both methodologies:

Although careful planning is a big plus (all estimates, concepts, budget are made, risks are worked out), for many projects it turns into a minus. The first stage spends a lot of time and resources, all planning elements can be done in the process. The same situation with a huge array of documentation.

Due to the isolation of all stages, there is no possibility to change something in the development and design. Programmers are forced to adapt to an existing interface. The client does not know his project until the testing stage, when it is too late to make changes.

Unlike Waterfall, all processes in Agile are inseparable. All errors that the tester finds are immediately corrected by the programmer, and the interface can change.

Agile has a strong focus on product quality, and it improves and adapts throughout the work.

A great plus of Agile is that the client is immersed in the project, he can at any time check how the work is going, attend meetings with the team at the end of the iteration and propose changes.

To work agile, you need to be aware of the challenges and know how to deal with them:

• you must be fully involved in the processes so as not to get confused, because they all happen at the same time. In pursuit of improvements, keep in mind the initial requirements of the client.
• do not set too many tasks for one sprint, this worsens the quality of work. Break one big task into several small ones.

When choosing a method, be guided by those principles that are more important for the project. Waterfall is good when you have a fixed list of requirements and a clear idea of ​​the final product. Agile is focused on industries where standards are constantly changing and new technologies are emerging. And you can adjust to them right in the middle of the process.

For example, the IT industry is constantly evolving, new trends are emerging, and with the help of Agile, Artjoker does a great job with startups!

Today we will delve into the topic and talk about the tools that the manager uses in his work.

To bookmarks

Methodology

Methodology in project management is the standardization of project implementation. Standardization here means a description of work steps, checklists for verification - a kind of canvas into which you can throw a project, and under the supervision of a manager, it will sail to completion and the finished product. Since each project is unique to some extent, the methodology is not a panacea, you still have to think.

There are a lot of project management methodologies - they are used only in one company, they are global. Methodologies come in the form of tools (like Agile), come in the form big book with a set of these tools (PMBoK, also a methodology).

In my life, I have used and still use two of the most popular methodologies - Waterfall ("waterfall" / "cascade") and Agile (and its offshoot - Scrum), and we will talk about them. For the sake of broadening the reader's horizons, I will tell you about other things that I know. If the reader works with digital, then the “waterfall” and “agile” will be enough for the eyes - it will be possible to use them in work, life, tell friends and strangers, at meetups, sipping smoothies with a smart look.

Where did the methodologies come from?

Of course, nothing is taken from nowhere, and Peter the Great did not hear anything about agile. Methodologies are invented by all sorts of different organizations and associations, where smart guys collect their problems in heaps, then understand how they could have been avoided, and then share their solutions with ordinary people like me, for example. Sometimes methodologies are thought through at the state level - they also solve problems there and collect best practices (don't put it that way in a decent society) into books and manuals.

Agile and Waterfall

Today we will talk mainly about these two animals. After reading this section, you're good to go and claim the coolest project manager job at the biggest eligible organization in town.

waterfall

Waterfall, waterfall methodology is the traditional, most popular and logical project management methodology. In its pure form, it can work in very simple projects. Let's say you need to plant a tree. “Along the waterfall” the execution of the project looks like this:

• Buy seedling
• Dig a hole
• Put a seedling in it
• Sprinkle with earth
• water the tree

Each stage in such a project follows the previous one and cannot be completed before the previous one - this is the “waterfall”. It also intersects with the “critical path method”, but I’ll talk about it in a separate article - remind me.

I work with projects in the field of website and mobile application development. The stages of development of such waterfall projects are approximately the same:

• Write technical task
• draw design
• Make up design
• Encode
• test
• Start project

To move along the waterfall, you need to have a clear technical task and an understanding of the steps that follow one after another. From practice, I’ll say that working on a pure waterfall is unrealistic - it always turns out somewhere that something was missed, somewhere you need to roll back to the previous stage and do it in parallel with the current stage. However, the clearer the terms of reference, the less likely the project will go sideways. For projects where “going sideways” is acceptable, there is Agile.

Agile

“Agile” (or “agil”, or “what a pity” - he has a lot of cool names) refers to the type flexible methodology. Its main difference from a waterfall is a working product at each stage of work and an unclear final project. In the example with the same tree, where each stage is sequential, this agile will not work: well, you bought a seedling, but what's the point? Agile has a fairly wide scope, but most of all it has taken root in IT. And its types and subtypes covered the adjacent areas with a thick film - business planning, product management, and so on and so forth.

Let's imagine a more complicated project for an example of working “according to Agil”. Let it be a construction project. Task: to build a house where you can live.

Production stages (let's imagine that each stage takes exactly one sprint):

• Build a box with walls and a ceiling
• Build a roof and roll up the walls with plaster
• Put doors and windows in the house
• Conduct electricity, water, sewerage
• Lay laminate, glue wallpaper
• Bring furniture and TV
• let the cat in

Waterfall or Agile?

No methodology is a panacea. The closest analogy I can draw is with checklists - this is such a cool thing (read @salakhmir), which helps a lot in work, but, for some reason, does not work for everyone. Any tool is just a tool and will not work by itself. Imagine that they put a shovel on the ground and are waiting for something to happen - so here, in order for something to happen, you need to do something.

I mainly use a hybrid methodology (both waterfall and agile), where there is a technical task, the stages are clear, but deviations occur during the project. From the outside, it may seem that chaos is happening, the main thing is to make a show-off face, everything is going according to plan. Often, deviations go into separate projects, but more often they remain within the current one and entail an increase in the time (budget) of the project. It seems that this is bad, but the moment of politics in working with people (we work with people, not with sites, remember?) cannot be ruled out.

Organizations managing methodologies

These organizations, for the most part, manage the development of methodologies - they are developed by the same managers that one day you will become. There are not so many of them in the world, but they are all wildly important - for money and time you can get their diplomas and go to interviews, amazing interviewers.

PMI

Project Management Institute is our friend. I have a special attachment to this organization - they have a powerful community and a good base. The organization is based in the USA, has existed since 1969, and their project management standards are recognized by ANSI.

The main product of PMI is a set of knowledge on project management PMBoK, the sixth part was released in the fall of 2017. The body of knowledge contains the outlines of project implementation in detail - from collecting stakeholder requirements to closing the project. I recommend at least to get acquainted with the book - in it you can also read about waterfall with agile, and about the critical path method and the fast pass method - the topics of one of my future articles.

In addition to PMBoK, PMI has such basic things: portfolio (project) and program management standards, risk management standards and the Scrum Guide. PMBoK is not an IT book, the methods from the set are applicable to virtually all projects (there are separate extensions for some types) - a must-have, in general.

PMI has a bunch of types of certifications, with steps and bells and whistles. PMI certifications are famous and popular. For example, a PMP - a project management professional - sort of confirms that you can manage projects. It is impossible to get organization certificates without experience, because they are more like a confirmation than like this university diploma of yours that you received while you were studying to learn.

IPMA

The International Project Management Association is the same organization as PMI, only European (Switzerland), and less is heard about it. It has been operating since 1965, and was originally called the Internet (when there was no Internet).

What they are doing there is unclear. Well, they certify managers. They publish their own magazines - themselves and under representations. Earn money. And thank God.

PRINCE2

“Prince” (PRojects IN Controlled Environments). The methodology appeared in 1989, in the UK (and then separated). A key feature of the methodology is the benefit that the processes within the project will bring to the project. Minimization of risks, compliance with the quality of the project. The PRINCE2 projects also have a difficult organizational structure with the project committee. As for the rest, such projects, as projects based on other methodologies, have a start, stages and completions - everything is familiar and familiar.

P2M

"A Guidebook of Project and Program Management for Enterprise Innovation". The Japanese project management methodology is fresh this time, it is from 1999. The tentacles here are the focus on innovation and managing stakeholder expectations. I didn’t come across closely, I didn’t study it, I can’t give an assessment.

Microsoft Solutions Framework

The "private" project management methodology, MSF, was invented and put into operation in 1994 by Microsoft. It is special in that it was developed directly for the development software, but not adapted, which can be said about the same PMBoK. Outwardly, it looks like a list of internal recommendations (like you have in the intranet) for project managers. In its pure form, even Microsoft is not used - they add the same agile, for example. Wikipedia has an informative article about this framework, please go there - there is more than I can tell.

Summary

Nothing is a panacea, but it is possible and necessary to understand the principles and take the best from them. While writing the article, out of the corner of my eye I came across an article about Stakhanov - there was such a dude under the Soviets, he was used in Soviet propaganda of productivity. He also worked according to the methodology (he mined coal), but one day he realized that if you slightly rearrange people and start some processes in parallel, you can work better. That's how he earned himself a page on Wikipedia. So here - test, apply and refine (then share). Everything you come across, all advice, is a hypothesis that needs to be tested. Enjoy it!

In the next part, I will try to talk about task and time planning, including my own micromanagement. The article should help not only novice managers, but also those who work with them. If enough fuse, then the article will be right this week. Write letters.

You need to have a good understanding of the basic principles life cycle Software, customer requirements for the product being created, and also take into account its financial capabilities. There are several life cycle models (cascade model, spiral model, rapid prototyping, etc.). The choice of a specific life cycle model depends mainly on the content and goals of the project, as well as on the amount of its financing.

As a rule, we prefer the spiral model, which includes Agile development methodologies. However, we sometimes use the waterfall model (also known as the Waterfall) and its derivatives for small or simple projects. In this article, we will describe the waterfall model, which is a classic type of software life cycle.

According to this model, the project is implemented step by step, according to a precise sequence of activities: requirements gathering and study, software design and development, testing and technical support. The waterfall model is quite flexible, and some stages may overlap.

Let's take a look at each stage of the life cycle one by one:

1. Requirements analysis

At this stage, it is important to document all the requirements for future software. Sufficient time should be devoted to discussing the details of the project with all stakeholders. All incoming data must be analyzed and systematized. It is also important to take into account all the technical limitations that may arise on the customer's side. The result of this stage should be the creation of a detailed specification that meets all customer requirements. You should also pay attention to other factors that can hinder the development process. These include deadlines set by the customer, as well as budgetary constraints.

Please note: The more information about the project you collect, the less time you spend on correcting errors, finalizing the project, budget revisions, discussions and other issues.

Project vision

An important task is to create a detailed vision document (or image) of the project , which includes short description project, business goals, as well as project success criteria, business risk factors and a description of the end user of the product.

The finished document must be submitted for approval to the customer to ensure that all the requirements have been taken into account, as well as to inform him of any risks that may arise after the release of the project.

Gathering Requirements

After all the main issues are resolved, it is recommended to hold additional discussions and interactive workshops with all stakeholders. This will help to identify any non-obvious points that in the future may cause changes to the application interface or the need to rewrite code patterns. This stage may also include filling out questionnaires, reviewing cases, brainstorming, etc.

Many projects are stymied by additional requirements that come up during the development phase. Therefore, it is very important to understand the initial business goals and main idea future application.

2. Software design

The next stage of the software life cycle is the creation of a document that describes the scope and boundaries of the project. This document includes mockups or sketches of the interface of the future application, as well as a detailed specification of software requirements. It should be noted that in some cases, the document of the vision (image) of the project and the document on the scope and boundaries of the project can be presented as a single document “On the image and boundaries of the project”.

The scope and boundaries of the project

The document describing the scope and boundaries of the project should list the main features of the software being created. They are determined on the basis of the project vision document, and of course, taking into account the specified time frame and the established budget.
In addition, this document includes mockups or sketches created on the basis of the project vision document, as well as the collected requirements.
You can draw a sketch of the user interface by hand or use mockup programs for this, and then coordinate it with the customer. Below is a list of useful mockup programs that we use in practice:

In the process of discussing the project, the customer may have more and more new ideas regarding its implementation. Therefore, it is recommended to give him time to think about his project and requirements for it, and then reconvene and discuss the details of the project so that nothing is overlooked.
At this stage, the issue of after-sales service of the product is also raised. You must notify the customer of how technical support will be provided after the completion of the testing phase and the subsequent release of the product.
Please note that a project vision document and a project scope and scope document must be created before the contract is signed.

Software requirements specification

The Software Requirements Specification (SRS) describes the requirements that the software being created must meet. It should be logical, consistent, accessible and complete. Requirements can be expressed in various forms, such as traditional must-have statements (e.g., “The Staff Manager system must support the following browsers: Google Chrome, Apple Safari, Mozilla Firefox, Opera, IE 8+”) or user stories ( e.g. “Because I am a manager, I need access to personal information all employees).
There are a large number of specification templates. The choice of a specific template depends on the specifics of the project. In most cases, the specification includes a product description, user classes, functional and non-functional requirements for the software being developed. Sometimes a template also includes a prototype. The main thing is to make the specification clear, concise and useful for developers.

To create a prototype, you need to find out the following:

• a way to receive and process incoming data to create the necessary output data;
• the form in which the output should be presented.

Mockups (or prototypes) are given to UI/UX designers who turn them into colorful templates.

3. Software development

It should be noted that software development may also include the creation of an interactive prototype, which, in essence, is the basis of a future application. Such a prototype helps define the architecture of the system as a whole. At this stage, little code is written: for example, the code for buttons and simple forms to give the customer a general idea of ​​how the final product will work. Therefore, we have included prototyping in the software development phase.

As soon as the interactive prototype and design of the application is ready and approved by the customer, the development of application standards (naming conventions, code documentation method, instructions for the end user, etc.) begins. After that, you can safely move on to the next stage of the life cycle, namely, software development. Software development can be divided into small parts, or units, and each unit is developed and tested by developers to verify its functionality (unit testing).

4. Software testing

Once the development phase is complete, the product must go through rigorous testing to ensure that it meets the requirements. The acceptance testing phase requires the customer to attempt to apply the product locally in exactly the same way that they intend to use it after release. Once major bugs have been fixed, the software can be deployed. A simple tracking system can be used to fix minor bugs, allowing any bugs to be corrected already during the software maintenance phase.

5. Software technical support

After the product has been tested and deployed on the customer's server, the next phase of the software development life cycle begins, which is called maintenance or technical support ON. In general, maintenance means fixing minor bugs that are discovered at this stage.
However, it is quite possible that you will have to make some changes to the created software, despite all the efforts you have made in the previous steps. The customer may decide to make changes to the functionality of the developed product. Therefore, you will have to collect, describe and discuss new requirements with the customer in order to make the necessary changes to the product. AT this case, you have to work with a new waterfall project, and all the above steps will have to be repeated from the beginning.

Conclusion

We have covered the key development steps required to create quality software. In order for your project to be successful, you must discuss all the requirements for the future application with the direct customer, as well as document in detail all the work that must be carried out at each stage of development.

The cascade model is necessarily used in the creation of life support systems used in the military, space development and medicine, for example, in the development of software for flight control, airbag systems, etc. It can also be used in the development of small and simple projects. However, if one of initial stages If an error is made, there is a possibility that it will be discovered only during the development or testing phase. Therefore, it is recommended to apply this model only if all the requirements are very clear and will not change over time.

This article has been prepared under the guidance of experienced business analysts at XB Software.

The following two tabs change content below.

Development software product knows a lot of 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. The article describes the methodologies that we regularly encounter at Edison.

1. "Waterfall Model" (cascade model or "waterfall")

One of the oldest, involves the sequential passage of stages, each of which must be completed completely before the start of the next. It is easy to manage a project in the Waterfall model. Due to its rigidity, the development is fast, the cost and time are predetermined. But this is a double-edged sword. The waterfall model will only work well for projects with clearly defined requirements and how they will be implemented. There is no way to take a step back, testing only starts after development is complete or nearly complete. Products developed according to this model without a justified choice may have shortcomings (the list of requirements cannot be adjusted at any time), which become known only at the end due to the strict sequence of actions. The cost of making changes is high, as you have to wait for the entire project to complete to initialize it. However, the fixed cost often outweighs the downsides of the approach. Correction of deficiencies realized during the creation process is possible, and, in our experience, requires one to three additional agreements to the contract with a small technical specification.

With the help of the waterfall model, we have created many projects from scratch, including the development of only technical specifications. Projects about which it is written on Habré: medium - , small - .

When to use the waterfall 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 required qualifications.
• For relatively small projects.

2. "V-Model"

Inherited the step-by-step structure from the waterfall model. The V-shaped model is applicable to systems that are particularly important for uninterrupted operation. For example, applications in clinics for monitoring patients, integrated software for the control mechanisms of crash airbags in vehicles etc. A feature of the model can be considered that it is aimed at a thorough check and testing of the product, which is already at the initial stages of design. The testing phase is carried out concurrently with the corresponding development phase, for example unit tests are written during coding.

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

When to use the V-model?

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

3. "Incremental Model" (incremental model)

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

As an example, let's describe the essence of one increment. replaced DefView. DefView used to connect to one document server, but now it can connect to many. On the site of an institution that wants to broadcast its content to a specific audience, a storage server is installed that directly accesses the documents and converts them into desired format. The root element of the architecture appeared - the central Vivaldi server, which acts as a single search engine for all storage servers installed in various institutions.

When to use an incremental model?

• When the basic requirements for the system are clearly defined and understood. At the same time, some details can be improved over time.
• Requires early market launch.
• There are several risky features or goals.

4. "RAD Model" (rapid application development model or rapid application development)

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 define the objects and other entities needed to circulate the information.
• Process Modeling: Information flows link objects to achieve design goals.
• Build Application: Uses auto build tools to convert CAD models into code.
• Testing: new components and interfaces are tested.

Can only be used with highly qualified and highly specialized architects. The project budget is large enough to pay for these specialists, along with the cost of ready-made automated assembly tools. The RAD model can be chosen if you know the target business with confidence and need to urgently produce the system within 2-3 months.

5. "Agile Model" (agile development methodology)

In the "agile" development methodology, after each iteration, the customer can observe the result and understand whether he satisfies him or not. This is one of the benefits of a flexible model. Its disadvantages include the fact that, due to the lack of specific formulations of the results, it is difficult to estimate the labor costs and costs required for development. Extreme Programming(XP) is one of the best known applications of the Agile 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) called "Sprint". At daily meetings, team members discuss:

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

When to use Agile?

• When user needs are constantly changing in a dynamic business.
• Agile changes are implemented at a lower cost due to frequent increments.
• Unlike the waterfall model, the agile model only needs a little bit of planning to start a project.

6. "Iterative Model" (iterative or iterative model)

The diagram shows an iterative "development" of the Mona Lisa. As you can see, in the first iteration there is only a sketch of the Mona Lisa, in the second - colors appear, and the third iteration adds details, saturation and completes the process. In the incremental model, the functionality of the product is built up bit by bit, the product is made up of parts. Unlike the iterative model, each piece is an integral element.

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

When is the best time 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 must be defined, but implementation details may evolve over time.

7. "Spiral Model" (spiral model)

The "spiral model" is similar to the incremental model, but with an emphasis on risk analysis. It works well for mission-critical business challenges where failure is incompatible with the company's operations, new product lines, research, and field trials.

The spiral model assumes 4 stages for each turn:

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

Let's summarize

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

In modern practice, software development models are multivariate. There is no one right for all projects, starting conditions and payment models. Even Agile, so beloved by all of us, cannot be applied everywhere due to the unpreparedness of some customers or the impossibility of flexible funding. Methodologies partially overlap in means and are somewhat similar to each other. Some other concepts were used only to promote their own compilers and did not bring anything new to practice.

About development technologies:
.
.
.
.

Only registered users can participate in the survey. Come in, please.

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. The article describes the methodologies that we regularly encounter at Edison.

1. "Waterfall Model" (cascade model or "waterfall")

One of the oldest, involves the sequential passage of stages, each of which must be completed completely before the start of the next. It is easy to manage a project in the Waterfall model. Due to its rigidity, the development is fast, the cost and time are predetermined. But this is a double-edged sword. The waterfall model will only work well for projects with clearly defined requirements and how they will be implemented. There is no way to take a step back, testing only starts after development is complete or nearly complete. Products developed according to this model without a justified choice may have shortcomings (the list of requirements cannot be adjusted at any time), which become known only at the end due to the strict sequence of actions. The cost of making changes is high, as you have to wait for the entire project to complete to initialize it. However, the fixed cost often outweighs the downsides of the approach. Correction of deficiencies realized during the creation process is possible, and, in our experience, requires one to three additional agreements to the contract with a small technical specification.

Using the waterfall model, we created many projects from scratch, including the development of only technical specifications. Projects that are written about in Habré: medium - X-ray microtomograph, small - auto-update of Windows service on AWS.

When to use the waterfall 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 required qualifications.
• For relatively small projects.

2. "V-Model"

Inherited the step-by-step structure from the waterfall model. The V-shaped model is applicable to systems where continuous operation is especially important. For example, application programs in clinics for monitoring patients, integrated software for control mechanisms for emergency airbags in vehicles, and so on. A feature of the model can be considered that it is aimed at a thorough check and testing of the product, which is already at the initial stages of design. The testing phase is carried out concurrently with the corresponding development phase, 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 while traveling. The project is carried out according to a clear TOR, but it includes a significant testing stage: the convenience of the interface, functional, load and including integration, which should confirm that several components from different manufacturers work together stably, theft of money and loans is impossible.

When to use the V-model?

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

3. "Incremental Model" (incremental model)

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

As an example, let's describe the essence of one increment. The Vivaldi digital library network has replaced DefView. DefView used to connect to one document server, but now it can connect to many. On the site of an institution that wants to broadcast its content to a specific audience, a storage server is installed that directly accesses the documents and converts them to the desired format. The root element of the architecture appeared - the central Vivaldi server, which acts as a single search engine for all storage servers installed in various institutions.

When to use an incremental model?

• When the basic requirements for the system are clearly defined and understood. At the same time, some details can be improved over time.
• Requires early market launch.
• There are several risky features or goals.

4. "RAD Model" (rapid application development model or rapid application development)

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 define the objects and other entities needed to circulate the information.
• Process Modeling: Information flows link objects to achieve design goals.
• Build Application: Uses auto build tools to convert CAD models into code.
• Testing: new components and interfaces are tested.

Can only be used with highly qualified and highly specialized architects. The project budget is large enough to pay for these specialists, along with the cost of ready-made automated assembly tools. The RAD model can be chosen if you know the target business with confidence and need to urgently produce the system within 2-3 months.

5. "Agile Model" (agile development methodology)

In the "agile" development methodology, after each iteration, the customer can observe the result and understand whether he satisfies him or not. This is one of the benefits of a flexible model. Its disadvantages include the fact that, due to the lack of specific formulations of the results, it is difficult to estimate the labor costs and costs required for development. Extreme Programming (XP) is one of the best known applications of the agile 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) called "Sprint". At daily meetings, team members discuss:

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

When to use Agile?

• When user needs are constantly changing in a dynamic business.
• Agile changes are implemented at a lower cost due to frequent increments.
• Unlike the waterfall model, the agile model only needs a little bit of planning to start a project.

6. "Iterative Model" (iterative or iterative model)

The diagram shows an iterative "development" of the Mona Lisa. As you can see, in the first iteration there is only a sketch of the Mona Lisa, in the second - colors appear, and the third iteration adds details, saturation and completes the process. In the incremental model, the functionality of the product is built up bit by bit, the product is made up of parts. Unlike the iterative model, each piece is an integral element.

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

When is the best time 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 must be defined, but implementation details may evolve over time.

7. "Spiral Model" (spiral model)

The "spiral model" is similar to the incremental model, but with an emphasis on risk analysis. It works well for mission-critical business challenges where failure is incompatible with the company's operations, new product lines, research, and field trials.

The spiral model assumes 4 stages for each turn:

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

Let's summarize

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

In modern practice, software development models are multivariate. There is no one right for all projects, starting conditions and payment models. Even Agile, so beloved by all of us, cannot be applied everywhere due to the unpreparedness of some customers or the impossibility of flexible funding. Methodologies partially overlap in means and are somewhat similar to each other. Some other concepts were used only to promote their own compilers and did not bring anything new to practice.

About development technologies:
Once again about the seven main development methodologies.
Top 10 System Scaling Mistakes.
8 development planning principles that make life easier.
Top 5 Risks in Custom Software Development .

Only registered users can participate in the survey. , please.