Cascade model. Agile vs Waterfall: which project development methodology to choose

The opposition between Agile and Waterfall is not so much theoretical as it is practical. Choosing a technique that is not suitable for your project, in best case scenario will significantly slow down its development, or at worst, will send it to the list of “TOP failures of the year.”

Flexible and waterfall project development models (Agile and Waterfall, respectively) are among the most popular among other management methodologies. Having studied the features of your specific project, and armed with the knowledge from this article, you will be able to answer the question with complete confidence: “What is right for my business - Agile or Waterfall?”

Agile— a system of ideas and principles of “agile” project management, on the basis of which the popular methods Scrum, Kanban and others were developed. The key principle is development through short iterations (cycles), at the end of each of which the customer (user) receives a working code or product.

Waterfall— a project management technique that involves a sequential transition from one stage to another without skipping or returning to previous stages.

What is Agile

Like other popular development and project management methodologies, Agile appeared relatively recently in the United States. Unlike CPM and CCPM, a whole group of people is immediately responsible for the emergence of flexible development methodology - 17 American IT specialists from the state of Utah. Together with the “Manifesto for Agile Software Development,” in which the term “Agile” was first used, they prescribed 12 principles of Agile development.

Their essence boils down to the following key points that determine the nature of the flexible development methodology:

People and interactions are more important than processes and tools
A working product is more important than comprehensive documentation
Cooperation with the customer is more important than agreeing on the terms of the contract
Being prepared to change is more important than sticking to the original plan.

Agile has become the basis for a number of agile methodologies, the most famous of which are Scrum, Lean and Extreme Programming.

Scrum is a flexible development methodology based on Agile, which is based on a “sprint” - a period of 1 to 4 weeks, at the end of which a working version of the product should be obtained.

Lean is a method that grew out of the Toyota Production System. It is based on a philosophy of continuous improvement at all levels of the organization, where one of the key concepts is value (what the customer is willing to pay for).

Extreme Programming (XP) is one of the Agile methods where an important role is played by periodic planning games with the involvement of the customer. It allows you to determine the shortcomings of the previous iteration, the priority of tasks, the desired functionality of the product, taking into account the wishes of the customer.

Advantages and disadvantages of the Agile method

The advantages of the method include:

short and clear iterations - development cycles last from 2 weeks to 2 months, at the end of which the customer receives a working version of the product
high degree of involvement of project performers, organizers and customers
the work product is at the forefront as the main indicator of progress - this can be considered both a plus and a minus, because in this case high demands are placed on the project team for self-organization
minimizing risks thanks to a flexible system for making changes.

The methodology does not avoid shortcomings that organically “complement” its advantages:

stimulating constant changes to the project: the flexibility of product development can lead to the fact that it never reaches the final version
increased requirements for the qualifications and experience of the team: in addition to directly creating the product, the team must analyze possible ways improve the efficiency of your own work, continuously exchange information on the project, be motivated and self-organized. It is not always possible for project resources to attract such specialists
philosophical nature of the methodology: Agile is not a clear instruction for action, but a whole philosophical concept. The team cannot mechanically apply the mechanics of “agile” development, it is necessary to accept the key principles of the system
difficulty in calculating the total amount of work: stimulation of changes and improvements in the final product leads to a floating value of the project cost.

What is Waterfall

The Waterfall methodology is the brainchild of Winston Walker Royce, director of the Lockheed Software Technology Center in Austin, Texas, USA, a pioneer in the field of software development.

With the Waterfall methodology, it turned out the same way as with many inventions: Herbert Bennington in 1956 and Hozier in 1961 made their contribution to the creation of the methodology, and Walker used their developments, securing the fame of “the creator of Waterfall.” The winners are not judged...

The waterfall development model involves a sequential process, divided into stages. The transition to a new stage is possible only after the completion of the previous one.

Walker's original work "Managing the development of large software systems" describes 6 stages of product development, which in 1985 the US Department of Defense enshrined in the standards for working with software developers:

System and software requirements: documented in a PRD (Product Requirements Document).
Analysis: embodied in models, diagrams and business rules.
Design: internal software architecture and methods for implementing requirements are being developed. It's not just about the interface and appearance software, but also about its internal structural logic.
Coding: the program code is directly written, software integration is underway.
Testing: bug testers (testers) check the final product, entering information about defects in the program code or functionality into trackers. In case of errors and availability of time/finance, bugs are corrected.
Operations: the product adapts to different operating systems, is regularly updated to fix bugs found by users and add functionality. As part of the stage, technical support for customers is also provided.

Toyota, which popularized the Lean and Kanban methodologies, used a waterfall model of software development for production needs until the end of the 2000s.

Advantages and Disadvantages of Waterfall

The greatest advantages of the Waterfall methodology include:

clear and simple structure of the development process - this reduces the barrier to entry for teams
convenient reporting - you can easily track resources, risks, time spent and finances thanks to the strict phasing of the development process and detailed project documentation
stability of tasks - the tasks facing the product are clear to the team from the very beginning of development, and remain unchanged throughout the entire process
assessment of the cost and timing of the project - the timing of the release of the finished product, as well as its final cost, can be calculated before the start of development.

Among the disadvantages of the waterfall method are:

a process lacking flexibility - so, if a project requires more time and financial resources than possible, then the testing phase will go under the knife. According to research by the Rothman consulting group, the cost of fixing bugs after a product is released is on average 20 times higher than during full multi-stage testing during the development process
“resistance” to changes - a rigid framework of development stages and the condition of providing only a finished product determine the impossibility of making changes during development
inertia - in the first stages, the forecast of time and financial expenses may change upward, but it is impossible to change the project in the direction of cost optimization, changes in functionality or concept before the release of the finished product
increased risk - the classic testing system involves separately testing each of the project components, including in interaction with others. When using Waterfall, the finished product is tested.

Partially, the shortcomings of the waterfall development model are corrected in the Waterfall modifications: Sashimi, Waterfall with subprojects and waterfall development model with risk reduction.

Sashimi or waterfall model with layering phases is the most famous among them. In it, the stages, as in the original method, follow each other, but at the same time they overlap one another in time.

Waterfall with subprojects is a model in which you work with three large blocks: conceptualization, requirements engineering and product architectural structure. Then, for each one, you go through stages (subprojects) of detailed design, coding, and testing. At the end, the integration of all components is carried out at the system testing stage.

The waterfall development model with risk reduction is a modification of the classic Waterfall, which adds risk reduction spirals that divide the project into mini-projects and correspond to one or more key risks.

Comparison table

		Waterfall
The essence	Flexible development model based on iterative principles	Waterfall development system based on a rigid sequence of development process
Creation date		1956, 1961, 1970
Developers	Group of IT specialists (USA)	G. Bennington, Hozier, W. Walker Royce
Principles of application	highest priority in customer satisfaction throughout the project, the team and the customer interact with each other and with each other on a daily basis a working product is the main indicator of progress work can only be entrusted to a self-organized, motivated team The optimal time frame for releasing a working product is from 2 weeks to 2 months.	strict sequence of development stages transition to a new stage - only after successful completion of the previous one fixed cost of the product the customer is not involved in the direct development process changes can only be made after the entire development process has been completed.
Pros	high level of interaction between project team members quick result (working code) as a result of “sprints” driving changes and improvements to the product during its development direct involvement of the customer in the work process.	clear and precise workflow diagram the ability to calculate the exact amount of resources spent on the project does not require costs to establish communications between all team members.
Cons	risk of endless product changes Greater dependence on the level of qualifications and experience of the team It is almost impossible to accurately calculate the final cost of the project.	priority of a formal approach to the sequence of the work process impossibility of making changes by the customer before the end of product development in the event of a lack of resources, the quality of the project suffers due to a reduction in the testing phase.
Practicing companies	Unilever, a number of banks (Alfa Bank, Home Credit, Raiffeisen Bank, etc.)	Cisco Ericsson AB, Toyota (until 2010)
Suitable for you if...	An experienced, highly qualified team is working on the project you are working on a startup need to quickly get a working version of the product the customer acts as a partner, not an investor The product is being developed in an area subject to constant change.	Most or all of the project work is outsourced you have a clear concept of the product you want to receive you are not limited in time and resources to create a product The creation of a product or business is built on compliance with a strict sequence of tasks.
It won't work if...	you are not ready to spend additional resources on establishing daily stable communication between all participants in the process the product must be created by a specific deadline the project budget is strictly limited you need detailed documentation of all development processes.	you want to create an innovative product or a large project you are not sure about the concept of the proposed project financial resources are not a key constraint in your project.

Verdict

Agile and Waterfall are two completely different methodologies for developing and managing projects. Each of them gave rise to dozens of modifications and methods, “tailored” to a specific project format.

The flexible model will be ideal for IT companies, startups, projects in innovative areas

The waterfall model does not lose ground in construction projects or projects where the key constraint is the duration of the project, and not finances

Taking into account the characteristics of each method and your business, as well as based on the criteria of risk, time and stakeholder involvement, you can independently determine an effective methodology.

Software development. Today we will talk about the most popular of them – Waterfall, or cascade methodology.

The general concept of the approach was presented by Dr. Winston Royce back in 1970. It is based on a logical sequence of steps that must be taken throughout the software development life cycle. Each stage is approved by competent employees, documented and passed on.
Although the popularity of the Waterfall model is recent years weakened, the nature of the sequential process used in the waterfall method is intuitively closer to developers, and therefore dominates in IT.

How the water falls

The model proposed by Royce is extremely simple and understandable. It consists of 7 blocks, each of which covers its own area of responsibility.

This model is not relevant everywhere and not at every enterprise. Long before software began to be developed in every office building, software development was carried out by large enterprises, where timing and accuracy of compliance with technical specifications were primarily important, and correctness and completeness secondarily. decisions made at each stage.

That is why the waterfall model is often mistaken for a development process in which interaction between stages in reverse order is excluded without prescriptive reasons. And the stages themselves are often fragmented to please numerous regulatory bodies, or combined due to related professions of developers.

We will also reduce the specified model to 6 blocks, combining the “Installation” and “Support” operations into one – “Deployment”. Now let's look at the executable functions:

Requirements. Simply put, at this stage all input documentation is created, according to which development will be carried out. First of all, the customer’s requirements and wishes are analyzed, then this is projected onto the company’s capabilities and the state of the market. The result is a document that describes what the software should do, but not how or with what tools.

Design. At this stage, the logic of the software operation is agreed upon. There are still no specific implementation decisions made here, but the functioning of all sections of the application is already described. At the end of the day, the developers already have an idea of how long the project can take in terms of time and personnel.

Construction. Here we are already talking about specific tools for implementing ideas: design requirements, programming languages, data levels, services, etc. are agreed upon. The skeleton of logic described in the previous section acquires “meat”; for the first time, the appearance of the finished product is formed.

Embodiment. The execution stage, which typically accounts for most of the development. If the classical model allows free interaction with previous stages, then in practice only minor changes to the “Design” are allowed.

Testing. At this stage, QA, beta and all other testers discover and report problems in the application. This phase most often causes a necessary repeat of the previous coding phase to resolve critical problems. If testing results in frequent code revisions, this causes a return to the design stage.

Deployment. Once the application is created, it can be presented to the customer and released into the wild. Since this stage also includes support, interaction with previous phases is inevitable.

Advantages of the cascade model

In recent years, the waterfall model has been losing its leading position to more flexible methodologies. This is due to the general dynamics in IT, when teams of 5-9 people are responsible for software development, and the deadline can easily be shifted due to increasing functionality.

However, the waterfall model is still relevant for large projects and organizations. And here's why:

Resistant to changes in personnel composition. Developers may come and go throughout the project's lifecycle, but due to detailed documentation, this has little impact on the project's timeline.
Discipline. The waterfall model forces the developers involved in the project to be disciplined and stay on track. If necessary, general model a governing body responsible for making decisions is added, and the performers are required to work within the system.
Flexibility in the early stages. Changes in the first three phases can be made immediately and with minimal effort since they are not backed up by code. Thus, the customer and the contractor have a significant time reserve for a radical change in the concept of software operation.
Focus on deadlines and finances. Due to the fact that each stage fully outlines the outline of the future software, all developers understand their role, work boundaries and deadlines. This allows you to operate with real numbers in front of the customer, which makes the project model attractive.

Disadvantages of the waterfall model

In the 1970s, Royce's ideas were relevant. But after almost 50 years, the waterfall development method is becoming less and less suitable for IT. Here's why:

Non-adaptive software structure. At the first stages, the waterfall model can be flexible, but if problems in the overall structure are identified during the testing phase, this entails disastrous consequences in the form of missed deadlines and even customer failures. Thus, the role of managers and responsible developers increases, with the level of competence of which there are often problems in any company.
Ignores the end user. The lower the process moves in the waterfall, the less the role of the customer, not to mention the clients he represents. Making any changes to the functionality of the software starts the entire chain of stages anew, so products obtained using the cascade model are far from targeting the mass user.
Late testing. From the description above it is easy to identify the most problematic stage of the methodology - testing. This is where mistakes made at each stage are most often identified. More agile methodologies use testing as a fundamental activity that occurs continuously. “Waterfall” allows for low qualifications of employees at each stage and poor quality of execution, because with belated testing, problems cannot be solved fundamentally, only with the help of “patches.”

It turns out that the cascade methodology is an excellent solution in terms of timing and reporting, but very weak in terms of quality. Therefore, today it is recommended to use it only in three cases:

When the software is oriented towards the customer, who requires transparency of work and execution on time.
If there are appropriately qualified managers on staff.
When executing a project that has no competition in the market.

Despite the fact that these 3 points are becoming less and less common in real practice, the cascade model will be popular and in demand for a long time due to its clear organization. This means that any professional developer must understand its basic principles and be ready to exist within the framework of this scheme.

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

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

You roughly imagine your idea, approximately the timing and what should happen as a result. But “approximately” is chaos.

But in a serious project that expects success, there should be no chaos.

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

We became convinced that we needed order. All that remains is to make a choice which methodology to choose.

As we announced in the title, the battle will take place between Agile and Waterfall. Let us immediately 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 final product:

Product idea

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

Initiation

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

Analysis

Looking for the best means To implement the idea, we research the market and competitors, understand who the target audience is.

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

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

Development

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

Testing

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

Product launch

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

Operation

The first customers appear who visit the site, buy a product or download an application - depending on the 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 a flexible development methodology. The team does not have strict stages; they are all interconnected and repeated:

The project is divided into iterations - cycles. Each of them involves planning, analysis, design, development and testing.

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

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

The whole process turns out to be as flexible as possible; after each iteration, the team receives a potentially working product, which it analyzes and can improve.

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

Despite the fact that careful planning is a big plus (all estimates, concepts, budgets are made, risks are worked out), for many projects it turns out to be a minus. The first stage takes a lot of time and resources; all planning elements can be done in the process. The same situation occurs with a huge amount of documentation.

Due to the isolation of all stages, it is not possible to change anything in development and design. Programmers are forced to adapt to an already existing interface. The client does not know their 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 emphasis on product quality, and it improves and adapts throughout the process.

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

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

you have to be fully involved in the processes so as not to get confused because they are all happening at the same time. In pursuit of improvements, do not forget about the initial requirements of the client.
Don’t assign too many tasks to one sprint, this will degrade the quality of work. Break one large 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 vision of the final product. Agile is focused on industries where standards are constantly changing and new technologies are emerging. And you can adapt to them right in the middle of the process.

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

Cascade model(English waterfall model, sometimes translated as the “Waterfall” model) is a model of the software development process in which the development process looks like a flow, successively passing through the phases of requirements analysis, design, implementation, testing, integration and support.

Following the waterfall model, the developer moves from one stage to anotherstrictly sequentially. First, the “requirements definition” stage is completely completed, resulting in a list of software requirements. Once the requirements are fully defined, the transition to design occurs, during which documents are created that detail for programmers how and how to implement the specified requirements. After the design is completely completed, programmers implement the resulting project. The next stage of the process involves the integration of individual components developed by different teams of programmers. After implementation and integration are completed, the product is tested and debugged; At this stage, all the shortcomings that appeared at the previous stages of development are eliminated. After this, the software product is implemented and its support is provided - introducing new functionality and eliminating errors.

For the classical software development model, the following stages are distinguished:

Analysis of project requirements. The software requirements for the information subject area of the system are determined.
Design.A logically consistent technical specifications software system. System details.
Software implementation.Implementation of a full-fledged project.
Product testing. Test operation of the product
System integration. Includes installation and official acceptance of the product.
Support.Providing technical assistance for the product after launch and commercial operation.

This model implies strictly sequential and one-time execution of each phase of the project. The transition from one phase to another is possible only after the successful completion of the previous stage. Each stage implies detailed planning and complete correctness of the result of the stage.

Such strict sequence restrictions allow us to build a development process that is as transparent and convenient as possible for the Customer.

PROJECT AND DOCUMENTATION

The other side of the coin this method, this is the need to support and constantly update product development documentation. Any change must be agreed upon with the Customer. And an insufficient level of elaboration of requirements entails an increase in the budget and project timescales, which are quite difficult to estimate.

Today, the waterfall model of software development is practically not used due to the low flexibility of the model. However, it continues to be used due to the high transparency of development. Thanks to high level formalization, managing such a project is much easier. It is generally accepted that the waterfall development model reduces risks and brings clarity to the development process when several dozen people are working on a project.

The cascade model is suitable for developing complex and large projects and systems with strictly defined functionality. Use when developing large government orders or scientific developments. It is highly undesirable to use this methodology for developing business applications.

Meta information

Number of processes - 6
Team - dozens of people

Cons

A Watrefall project must have up-to-date documentation at all times. Mandatory updating of project documentation. Redundant documentation
Very non-agile methodology
May create a false impression of work on the project (for example, the phrase “45% completed” does not carry any useful information, but is just a tool for the project manager)
The Customer does not have the opportunity to familiarize himself with the system in advance and even with the “Pilot” of the system
The User does not have the opportunity to get used to the product gradually
All requirements must be known at the beginning of the project life cycle
There is a need for strict management and regular monitoring, otherwise the project will quickly go behind schedule
There is no possibility to take into account rework; the entire project is done at one time

Pros

High transparency of development and project phases
Clear sequence
Stability of requirements
Strict control of project management
Facilitates the work of drawing up a project plan and assembling a project team
Well defines the quality control procedure

Application

For medium and large projects, where dozens of programmers and several different project teams are involved.
Projects in which requirements and boundaries are transparent and precisely known at the beginning of the project life cycle.

Thus, the cascade model implies that the transition from one development phase to another occurs only after the complete and successful completion of the previous phase, and that transitions back or forward or overlap of phases do not occur.

It is necessary to have a good understanding of the basic principles of the software life cycle, the customer's 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 particular life cycle model depends mainly on the content and goals of the project, as well as on the amount of its funding.

We generally favor the spiral model, which incorporates flexible development methodologies called Agile. However, we sometimes use the waterfall model (also called the Waterfall model) and its derivatives to complete small or uncomplicated 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, in accordance with the exact sequence of actions: collecting and studying requirements, software design and development, testing and technical support. The waterfall model is quite flexible, and some stages may overlap.

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

1. Requirements analysis

At this stage, it is important to document all requirements for future software. It is necessary to devote sufficient time to discussing the details of the project with all interested parties. All incoming data must be analyzed and systematized. It is also important to take into account all 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 may complicate the development process. These include deadlines set by the customer, as well as budget restrictions.

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

Project vision

An important task is to create a detailed project vision document (or image) which includes brief 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 to the customer for approval to ensure that all requirements have been taken into account, and also to inform him of any risks that may arise after the release of the project.

Gathering requirements

Once all major issues have been resolved, it is recommended that further discussions and interactive workshops be held with all stakeholders. This will help identify any non-obvious points that may later 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 stall due to additional requirements that crop up during the development stage. Therefore, it is very important to understand the initial business goals and the main idea of the future application.

2. Software design

The next stage of the software life cycle is the creation of a document describing 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 vision document (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”.

Project scope and boundaries

The document describing the scope and boundaries of the project should list the main functions 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 established budget.
In addition, this document includes mockups or sketches created based on 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 agree on it with the customer. Below is a list of useful programs for creating mockups that we use in practice:

During the discussion of 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 its requirements, and then reconvene and discuss the details of the project so that nothing is overlooked.
At this stage, the issue of after-sales service for the product also arises. You must notify the customer of how technical support will be provided after completion of the testing phase and subsequent release of the product.
Please note that a project vision document and a project scope document must be created before the contract is signed.

Software Requirements Specification

A software requirements specification (SRS) describes the requirements that the software being built must meet. It should be logical, consistent, accessible and complete. Requirements can be expressed in different forms, for example, in the form of traditional must statements (for example, “The Staff Manager system must support the following browsers: Google Chrome, Apple Safari, Mozilla Firefox, Opera, IE 8+”) or in the form of user stories (eg, “since I am a manager, I need access to the personal information of 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 description of the product, user classes, functional and non-functional requirements for the software being developed. Sometimes the 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 figure out the following:

a method for receiving and processing incoming data to create the necessary output data;
the form in which the output should be presented.

Mockups (or prototypes) are handed over 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 the future application. Such a prototype helps define the architecture of the system as a whole. At this stage, little code is written: for example, button code and simple shapes to give the customer a general idea of how the final product will perform. Therefore, we included prototyping in the software development phase.

Once the interactive prototype and application design is ready and approved by the customer, the development of application standards (naming conventions, method of documenting code, instructions for the end user, etc.) begins. After this, 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 completed, the product must undergo rigorous testing to ensure that it meets the specified requirements. Acceptance testing requires the customer to try to use the product locally in exactly the same way they will use it after release. Once the major errors are corrected, the software can be implemented. To correct minor errors, a simple tracking system can be used, which will allow any defects to be corrected during the software maintenance stage.

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 software maintenance or technical support. In general, maintenance involves fixing minor bugs that are discovered at this stage.
However, it is 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. IN in 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 looked at the key development stages necessary to create quality software. In order for your project to be successful, it is necessary to 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.

Cascade model in mandatory used in the creation of life support systems used in military affairs, space development and medicine, for example, in the development of software for flight control, airbag systems, etc. It can also be used when developing small and uncomplicated projects. However, if an error is made at one of the initial stages, there is a possibility that it will only be discovered during the development or testing stage. Therefore, it is recommended to use this model only if all the requirements are very clear and will not change over time.

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

The following two tabs change content below.