Cascade model pros and cons. Advantages of the waterfall model. Risk Mitigation Waterfall Development Model is a modification of the classic Waterfall, which adds risk reduction spirals that divide the project into mini-projects and correspond to them.

Software development methodology - organization of work, including ideological principles, a plan, control over processes, an approach to employees. We distinguish 12 types:

Waterfall is the traditional approach.
RUP (Rational Unified Process) - rational.
Agile is a general agile development methodology.
Crystal Clear is a team leveling approach.
Spiral - spiral method.
DSDM (Dynamic Systems Development Model) - dynamic model.
FDD (Feature Driven Development) is a methodology that considers future changes.
JAD (Joint Application Development) is a user-centric approach.
RAD (Rapid Application Development) is a rapid development model.
Scrum is the concept of working in the face of missed deadlines and an ideological crisis.
XP (Extreme Programming) - extreme development in a dynamic environment.
LD (Lean Development) is a method that involves a careful attitude towards all participants in the process.

Let's try to figure out what is hidden behind these English names.

waterfall

The Waterfall model belongs to the classical understanding of software development. The whole process is rigid and linear, has clear goals for each stage, a new phase starts upon completion of the previous one, there is no going back. The advantages of the waterfall methodology are decentralization and strict control over the timing and quality of execution.

In practice, Waterfall often falls short of expectations because it ignores dynamic changes. So, after testing, it is very difficult to roll back the process and lay down functions that were not taken into account at the development stage. Waterfall is also inefficient because it involves temporary downtime for employees within the same project. Testing is done only at the end of development, although problems found at this stage are costly fixes.

RUP

RUP is an iterative approach that solves the problems that Waterfall has. Why RUP is good:

Keeps up with changing requirements. No matter how good the project manager is, it is impossible to take everything into account at the beginning.
The integration of functions occurs gradually, that is, each “detail” goes through a cycle of development, verification and implementation in the project. As a result, risks and production costs are reduced.
Early product release. Software comes out with reduced functionality in order to occupy a niche in the market and resist competitors, after which it becomes overgrown with “meat”.
Reuse. When increasing functionality, it is easier to highlight standard solutions which will shorten the development.
Constant learning. Due to frequent iterations, developers do not have long pauses between code completion, so professional growth happens smoothly and painlessly.
Continuous product improvement. Iterations allow you to evaluate the project not only in terms of compliance with the plan and TOR, but also to find ways to increase the efficiency and quality of the product.

Agile

Agile - agile development method software, which involves a large number of iterations. The Agile Manifesto document describes 4 ideas and 12 principles of an agile approach, it can be briefly described in just two points:

Informal relationships are more important than documented ones. That is, verbal agreements between employees, between the customer and the contractor are most important, which is reflected in the plans, contracts and terms of reference. In other words, the customer is always right.
A working product is the main measure of progress. What matters is not the tools, solutions, performance and elegance, but the fact that all the planned features are implemented.

Despite its shortcomings, Agile has become a fundamental concept for software development and has been reflected in other methodologies, which will be discussed later.

Crystal Clear

A methodology designed for small teams of 6-10 employees. It also supports the principles of agile development, but has a little more specifics. The main idea, which is contained in the name - each team is a set of people with different levels knowledge, skills and experience.

That is why there is no universal approach to software development, it must be determined in the process of communication within the group. Roles, tools, standards are also assigned there. The group is then taken as a unit and the same issues are resolved one level up until the hierarchy reaches the customer.

Spiral

Spiral model life cycle is a complex software lifecycle organization that focuses on early detection and mitigation project risks. Development starts on a small scale, local problems are solved, risks are assessed and ways to reduce them. The next step covers more complex tasks - the next turn of the spiral.

The advantage of the approach is not to increase the speed of development, but to reduce the level of risk occurrence. The success of the spiral method depends on conscientious, careful and competent management, and the size of the project is not of fundamental importance.

DSDM

The Dynamic Systems Development Model was developed in the UK in the mid-1990s and is an evolutionary development of Rapid Application Development (RAD). The main idea is standard: when planning at the very beginning, it is impossible to understand all the intricacies of development, so the whole process is research work.

In DSDM, there is also a division into teams, each of which has an authorized person to make strategic decisions. All interested parties can participate in the process: users, developers, customers, managers. Testing is carried out throughout the entire life cycle.

FDD

FDD is a process to ensure scalability and repeatability while encouraging creativity and innovation. Here are the basic principles:

The development of each major project must be systematic.
Processes should be simple and elaborate.
The value and logic of the process should be clear to every team member.
Preference is given to short iterative development cycles. This reduces the number of errors and allows you to quickly scale up functionality.

FDD regulates the time that should be spent on each of the processes. Organizational activities in the cycle should take no more than 23-25%, while it is necessary to spend 75-77% of the time on the direct development, assembly and testing of functions.

JAD

JAD is a methodology aimed at keeping end user development as busy as possible. This happens through meetings and joint seminars. JAD was invented in the 1970s by IBM employees and is aimed at businesses in general. However, over time, this concept has been successfully applied to software development.

Unlike the Waterfall approach, JAD results in reduced development time, greater customer satisfaction, and cost savings in market research. On the other hand, this requires a large client sample and the need for developers to work not with strict TOR requirements, but with constantly changing opinions.

RAD

RAD is a methodology that prioritizes the speed and convenience of development. One of the main conditions is the use of a rapid development language. This is the name of an abstract programming language with which a programmer is able to solve problems faster than with third generation representatives (C / C ++, Pascal or Fortran). Here are a few more concepts:

Using focus groups to collect requirements.
Prototyping and user testing designs.
Reuse of software components.
Using a plan that does not include rework or designing the next version of the product.
Holding informal meetings at the request of one of the parties.

RAD involves the use of a whole range of tools in addition to the rapid development language: requirements collection systems, development environments, frameworks, group communication programs, testing software.

Scrum

Scrum- flexible method project management, the purpose of which is to increase productivity in teams previously paralyzed by more difficult methodological processes. The concept is based on "sprints". Sprint is a short iteration strictly limited in time (usually 2-4 weeks). At this time, the duration of meetings is minimized, but their frequency is increased (they are called “contractions”).

As a result, execution control becomes more flexible, and developers respond faster to problems that arise. Traditional planning is taking a backseat to the sprint journal.

XP

Extreme Programming - the ability to develop in the face of ever-changing requirements. Here are a few signs:

The planning game. At the beginning of the project, there is only a rough plan; after each iteration, its clarity increases.
High frequency of releases. A new version product has minor changes compared to the previous one, but the release time is minimal.
Contact with the client. To meet the requirements of the end audience, it is necessary prompt response for comments and suggestions.
Refactoring. Improve code quality without reducing functionality.
Code execution standard. Or apply general rules, or disagreements in the design are not subject to discussion and criticism.
Collective responsibility. Despite the fact that each team member performs his own area of work, the entire team is responsible for the code as a whole.

LD

Lean software development is another branch flexible methodology, which implies the preservation of a high moral and functional state of developers. This is expressed in:

Encouragement of employees for successful work.
Changing current tasks only as needed or at the request of the customer.
Strict implementation of the plan: everything that is in excess is considered a waste of time and resources.
Implementation of the general concept "Think big, do small, fail fast, learn fast".

In the context of a short digest, it is difficult to reveal all the advantages and disadvantages of methodologies, to show effective areas of application. We will talk about the most relevant concepts for today separately. About what exactly? Leave your wishes in the comments.

Software development is not like traditional engineering. A methodology is what developers use to break down work into manageable progressive steps where each one can be reviewed to ensure quality. Teams work together with the customer to create a finished software product using one of the software development methodologies. The most popular of them are the spiral, waterfall, or cascade model (Waterfall); RAD, or Rapid Application Development; Agile Model, or flexible and iterative, or iterative model. There are other options, but in this article we will consider only the waterfall, or cascade, model and also explore its advantages and disadvantages. Let us immediately explain that it is a sequence of certain steps, and its peculiarity is that new stage is not possible until the previous one has been completed.

The history of the waterfall model

The methodology in its traditional form leaves little room for unexpected changes. If the development team is not too large, and the projects are predictable, then Waterfall can ensure that they are completed on time.

The waterfall development model has been around for over forty years. It was first described in a 1970 article by W. Royce as one of the very first official models for the development process. It was described as ineffective for large software development projects, but no one forbade its use for small ones. Nearly half a century after it was discovered, this technique is still relevant in today's business world. It has been called the obsolete model and is treated with some disdain due to the obsolescence of the traditional project management approach. But Waterfall is a useful and predictable approach if the requirements are fixed, well-documented and clear, if the technology is understandable, and when the project does not take much time to complete. In this case, the waterfall model can provide a more predictable end result for a given budget, time frame, and scope of work.

What is a waterfall development model?

The Waterfall model can be described as a linear, sequential development of a project, where processes constantly move from requirements to design, then to implementation, verification and deployment, followed by ongoing maintenance. It is believed that the cascade life cycle model was created thanks to W. Royce, although he himself used an iterative development model.

The main emphasis in the development of the Waterfall model is on planning, timing, goals, budgets, and ultimately the implementation of the entire system as a single entity. The main advantages here are simple forward and backward planning and implementation.

Description of the waterfall model

Compared to other methodologies, Waterfall focuses more than others on a clear, defined set of steps. The original model consisted of five stages. It is often described as a linear sequential life cycle model. This means that it follows a simple phase structure, where the results of each phase progress to the next level of development. The main steps are:

Gathering requirements and creating documentation.
System design and engineering.
Implementation.
Testing and deployment.
Support.

Teams must complete the entire step before moving on to the next one, so if something isn't ready by a certain deadline, it becomes immediately noticeable. Also, unlike six sigma or Scrum, Waterfall does not require certification or special training for project managers or employees.

Criticism of the waterfall model

Waterfall life cycle model information system has been criticized for being inflexible after each step is completed, and for delaying the client's ability to provide feedback. However, this methodology can work well for smaller projects with limited budgets. It is often compared to one well-known project life cycle methodology, PRINCE2, which was created by the UK government. This methodology is still used in the public sector. One of the key differences between PRINCE2 and the waterfall lifecycle model is that the latter requires a description in writing all requirements from the very beginning, because later it will be difficult to revise them. Before the creation of any code begins, they must be precisely defined and fixed. This is an important advantage waterfall model life cycle.

Pros and cons of the waterfall model

Since technical documentation is a necessary part of the initial requirements development phase, this means that all team members clearly understand the goals of the project. New developers can quickly understand the rules of code creation and join the workflow without any problems. If the waterfall model of the life cycle of an information system or project is used, phased execution ensures discipline is maintained.

Each step has a well-defined starting point and conclusion, making it easy to track progress. This helps to reduce any deviation of the project from the agreed time frame. In this model, in contrast to the spiral, the software is considered as a whole. Therefore, provided that all requirements are met, it works more efficiently. If we continue to compare the cascade and spiral life cycle models, we can conclude that the first is more universal and can be applied in various fields.

Requirements negotiation stage

Another advantage of the waterfall life cycle model is that costs can be estimated with a fairly high degree of accuracy once all requirements have been identified. If it is applied, it means that at the first stage all test scenarios are already described in detail in the functional specification, which makes the testing process simpler and more transparent. And also, even before the development of the software, the design is worked out in detail, which makes the needs and the result clear to everyone.

One of the great things about using Waterfall is that you are committed to the end product, or end result, from the very beginning. Therefore, teams must avoid deviating from the target. For small projects where the intent is clear enough, this step makes the team aware of common purpose from the very beginning, which reduces the chance of getting lost in the details as the project moves forward. Waterfall's approach is very methodical, which is why it emphasizes the importance of clear communication at every stage. In the software development process, new people appear at each new step. Therefore, it is important to strive to document information throughout the project life cycle.

Disadvantages of the Waterfall Life Cycle Model

Potential development issues can be investigated and resolved during the design phase. Alternative solutions are also being worked out and the optimal ones are selected. All this happens before the start of the project. Many organizations appreciate the attention to documentation right from the start, as it also means that there should be no surprises with the final product. But in practice, it is rarely possible to do without making changes. It is often difficult for clients to understand their own needs in terms of functional specification only at the requirements stage. This means they can change their mind once they see the final product. Such a problem is difficult to solve. Sometimes the application has to be reworked almost completely.

Lack of Flexibility in the Waterfall Model

Another disadvantage of the waterfall model of the IP (or project) life cycle is the potential lack of flexibility. Questions may arise to accommodate new developments or changes in requirements that have occurred since the initial consultations.

Adjustments due to business plans or market influences may not have been taken into account in planning. Also, projects can take longer to complete compared to using an iterative methodology such as Agile.

Important Points When Using the Waterfall Methodology

When it comes to Waterfall development, it is very important that software developers can effectively guide and advise clients in order to work around all these problems later. Often the most critical aspect of applying the waterfall lifecycle model is that customers don't really know what they really want. In many cases, true two-way interaction between developers and clients does not occur until the client has seen the model in action.

For comparison, in Agile development, the client can see fragments of the working code that were created during the work on the project. Unlike Scrum, which divides projects into separate sprints, Waterfall always focuses on the end goal. If your team has a specific goal with a clear end date, Waterfall eliminates the risk of missing a deadline when you work on it. Based on these pros and cons, Waterfall development is generally recommended for projects that are not likely to change or need new development during the life of the project.

What is a waterfall model

Software life cycle is the period of existence of the software associated with the preparation for its development, development, use and processing, starting from the moment when the decision is made to develop new system until the moment when all its use is completely stopped. The software life cycle model highlights specific sets of activities, artifacts, roles, and their relationships. It defines which artifacts are inputs to which activities and which artifacts appear as outputs, which roles are involved in different activities, how activities relate to each other over time, what are the criteria for the quality of the results obtained, how to assess the degree of compliance of various artifacts common tasks project and when you can move from one activity to another.

Waterfall software life cycle model involves the sequential execution of various stages of activity, including requirements analysis, design, coding and testing of individual modules (components), assembly testing and integrated testing of the entire final product. This assumes a clear distinction between the stages at which the set of documents developed at the previous stage is transferred as input to the next one. Thus, each type of activity is performed at any one phase of the software life cycle, movement in reverse side this chain is not possible.

Stages of activity

Analysis. The analysis phase examines and defines the task that the program should perform. The result of this phase is a set of requirements for software.

Design. At this stage, the requirements identified during the analysis are converted into a description of the principles of the solution - a document in accordance with which specific decisions are made in the implementation of the program. The main outcome of the second phase is to obtain a project that may include a text in natural language, a software model, algorithms, tables, mathematical formulas, etc. Detailed design involves the selection of software components, determining their structure and methods of interaction.

Implementation. Upon completion of the initial design, the implementation phase follows, in which the software modules defined during the design are created and tested. The main outputs of this phase are source code modules and standalone module tests. After implementation, they move on to testing the system, and then to putting it into operation.

Implementation and operation. The finished software product is transferred to the customer, acceptance tests are carried out, user training and trial operation are carried out, after which the software is put on maintenance and the production operation of the software system begins.

Disadvantages of the waterfall approach

Accumulation of various mistakes made in the early stages of the project. If only towards the end of the project, it becomes obvious that mistakes have been made, then any return to previous stages in order to correct mistakes becomes extremely costly. The "waterfall" method does not effectively identify and mitigate the consequences of such risks.
Unjustified increase in implementation time, over budget and the risk of a complete failure of the project due to the accumulation of errors from stage to stage.
All key decisions are made when analysts and developers do not have a complete understanding of the system. It is very difficult to fit the real process of creating software into such a rigid scheme, so there is always a need to return to previous stages in order to clarify and revise earlier decisions taken. At the start of a project, developers face the daunting task of fully defining all the system requirements. To do this, you need to carefully and comprehensively discuss with users and research business processes. Users must agree with everything that emerges from such a survey, although they may not be fully familiar with its results. With some luck, about 80% of the requirements for the system can be collected in this way at the analysis stage. When designing, new problems may arise, they need to be discussed again with users, which will result in new requirements for the system. During the implementation and testing process, it is often found that some of the decisions made earlier cannot be implemented or it turns out that the requirements were not detailed enough and their implementation is incorrect. We need to go back to the analysis stage and reconsider these requirements.
The waterfall method does not provide the ability to quickly adapt to changes especially in the later stages of the software life cycle.
The final product may not be in demand due to an inaccurate statement of requirements or their change over a long time of software development.

When to Use the Waterfall Approach

The waterfall approach works well in projects where the requirements for the software product are clearly defined and should not change, and the involvement of the customer in the development process is not required. The same applies to software projects, the complexity of which is determined by the need to implement complex algorithms, and the role and scope of the user interface is small.

Comparison of waterfall and iterative approaches

The above figure clearly shows the differences between the waterfall and iterative approaches. The waterfall approach involves fixing the functionality of the software and the possibility of varying time and resources (usually upwards for the reasons given above).

With the waterfall approach, the customer is involved in the project only at an early stage (to determine the requirements for the software) or if the need for changes is discovered by the developers. He can only evaluate the final result, which may not correspond to his ideas.

The iterative approach assumes the participation of a customer representative in the project at all stages. An iterative approach makes it possible to significantly facilitate and simplify the process of changing the functionality of the software.

The main advantages of the iterative approach can be summarized as follows:

The ability to mitigate the impact of major risks early in the project while it can still be done with minimal cost. The difference in the cost of an error in determining the requirements at the beginning of the project and at the end is 1:200.
the opportunity to organize fruitful feedback with future end users in order to create a system that really meets their needs;
focus on the most important and critical areas of the project;
continuous iterative testing of the final product, which allows you to evaluate the success of the entire project as a whole;
early detection of inconsistencies between requirements, models and program code;
effective use of accumulated experience;
a real assessment of the current state of the project and, as a result, greater confidence of customers and direct participants in its successful completion.

programming,

Mobile Application Development

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 in the process of creation is possible, and, in our experience, requires from one to three additional agreements to a contract with a small TK.

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 - a mobile application for the 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)

In an incremental model, the complete system requirements are divided into different assemblies. Terminology is often used to describe a staged build of software. There are multiple development cycles, and together they make up the multi-waterfall lifecycle. 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 according to the incremental model involves the release of the product at the first major stage in the basic functionality, and then the consistent addition of new features, the so-called "increments". The process continues until a complete system is created.

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 electronic 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 to the desired format. The root element of the architecture appeared - the central Vivaldi server, acting as a single search engine across 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 RAD model is a variation of the incremental model. In the RAD model, components or functions are developed by several highly skilled teams in parallel, like several mini-projects. The time frame of one cycle is strictly limited. The created modules are then integrated into one working prototype. Synergy allows you to quickly present something working to the client for review in order to receive 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 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.

When is the RAD model used?

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.

The methodology is suitable for large or long-term projects that are constantly adapting to market conditions. Accordingly, in the process of implementation, 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 type of leader. We develop internal startups of the company using Agile. An example of client projects is the Electronic System of Medical Examinations, created to conduct mass medical examinations in a matter of minutes. In the second paragraph of this review, our American partners described a very important thing, fundamental to success on Agile.

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 iterative life cycle model does not require a complete requirements specification to begin with. Instead, the creation begins with the implementation of a piece of functionality, which becomes the basis for determining further requirements. This process is repeated. The version may not be perfect, the main thing is that it works. realizing ultimate goal, we strive for it so that each step is effective, and each version is workable.

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 Gioconda, 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 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 inconsistent with company operations, new product lines being launched when needed scientific research and practical testing.

The spiral model assumes 4 stages for each turn:

planning;
risk analysis;
construction;
evaluation of the result and, if the quality is satisfactory, the transition to a new round.

This model is not suitable for small projects, it is reasonable for complex and expensive ones, such as the development of a document management system for a bank, when each next step requires more analysis to assess the consequences than programming. At the project for the development of an EDMS for the ODU of Siberia SO UES, two meetings on changing the codification of sections electronic archive take 10 times longer than merging two folders by a programmer. The state projects in which we participated began with the preparation by the expert community of an expensive concept, which is by no means always useless, since it pays off on a national scale.

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 true 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.

Unfortunately, there is no universal software development process that is completely suitable for every project. At the forefront are methodologies - systems of standards containing concepts, methods and methods that determine the style of software development.

The methodology is selected, firstly, for specific tasks, scope of work, customer goals and budget. Secondly, we do not forget about the specifics of the activities of an IT company. Technical support, outsourcing and internal development of your project involve different approaches.

One of the most common categories of software development models are Agile and Waterfall, Agile and Waterfall, respectively. We will give short description each, consider their pros, cons and decide on the correct system for the project.

Agile methodologies adhere to iterative development principles. The process of creating a product is divided into a series of short cycles of 1-4 weeks. Each iteration is a separate project with planning, design, programming, testing, and retrospective.

When paying developers within Agile, they usually choose between a dedicated team for the project (Dedicated Team) and the Time & Materials (T & M) system. We have already compared some of the mechanisms for building financial relationships with a contractor. Our findings from the perspective of customers and developers can be found.

Agile development model is based on 12 principles, of which we consider the following to be decisive:

working software is the best indicator of the effectiveness of the development team;
editing requirements is welcome at any stage of development;
personal communication is the most productive way of communication;
new versions of the product are released either every iteration or every few months, depending on the project.

The Agile class includes techniques such as Extreme Programming (XP), FDD, DSDM, Scrum and others.

waterfall

Principle cascade system is in sequence. The development process is broken down into the following steps:

1. Requirements analysis

2. Planning

3. Implementation

4. Integration

5. Testing

7. Support

The transition to each phase occurs only after the end of the previous one. New features are added after the release and fixes of previous errors. Due to clear documentation and stable requirements for cascading projects, a fixed price financial interaction model is better suited.

Now let's compare the strengths and weak sides Agile and Waterfall.

Advantages of the methodologies:

Flexible Model

Functional requirement adjustments are built into the development process to ensure competitive advantage. In fact, after 2 iterations, the project can be turned around 360 degrees and make a completely different product.
The project is divided into short and transparent iterations.
Minimize risk with a flexible change process.
Quickly get the first working version of the product.

Cascade model

Clear and simple process structure, suitable for teams with little experience.
High quality and detailed documentation.
In a project, you can easily track resources, risks, and time spent.
Product tasks are stable from start to finish.

Cons of methodologies:

Flexible Model

It is impossible to calculate the exact amount of work due to constantly changing requirements.
Since Agile is more of a philosophy than a process, you need to dive into the system and embrace it, which is not required for every project.
The team must be highly qualified and experienced, customer oriented.
New requirements may conflict with existing architecture or functionality.
With all the adjustments and changes, there is a risk that the project will never end.

Cascade model

Requirements are defined and fixed at the very beginning, which deprives the development process of flexibility.
The project takes more time and resources.
The client will see only the finished product, it is extremely difficult to change anything.
Lack of feedback between development stages.

Having studied the materiel, we will easily learn how to juggle Agile and Waterfall in our projects!

Agile development model works if:

1. An experienced team is involved in the project.

2. The final functionality of the product is still unknown, and changes must be made as quickly as possible.

3. The end user is “cooked” in the project from the very beginning.

4. Need to quickly develop working software.

5. You are a startup.

Choose a waterfall model if:

1. Requirements for the project are stable and practically unchanged;

2. The quality of the product is much more important than the time and resources spent;

3. The project is being developed on outsourcing;

4. The end user only accepts the result of the work, without participating in the process.

It must be said that both models will help to realize your project. First of all, you choose the option that will allow you to make quality products and manage your budget effectively.

Of course, once you are at the finish line, no one will be interested in the chosen methodology. Therefore, even if the development model turned out to be inappropriate, the team must be strong enough to get decent results.

Now just go and make your project!

It might be useful to read: