Annotation: The concept of software development process. Universal process. current process. specific process. standard process. Process improvement. Pull/Push strategies. Classical process models: waterfall model, spiral model. Phases and activities.

The advantage of this model was the limitation of the possibility of returning to an arbitrary step back, for example, from testing to analysis, from development to working on requirements, etc. It was noted that such returns can catastrophically increase the cost of the project and the timing of its implementation. For example, if design or analysis errors are found during testing, fixing them often results in a complete redesign of the system. This model allowed only returns to the previous step, for example, from testing to coding, from software this model was actively criticized by almost every author of the corresponding articles and textbooks. It has become generally accepted that it does not reflect the features of software development. The disadvantages of the waterfall model are:

• identification of phases and activities, which entails a loss of development flexibility, in particular, the difficulty of supporting an iterative development process;
• the requirement for the complete completion of the activity phase, fixing the results in the form of a detailed source document (terms of reference, project specification); however, software development experience shows that it is not possible to fully complete requirements development, system design, etc. - all this is subject to change; and the reasons here are not only that the environment of the project is mobile, but also that it is not possible to accurately determine and formulate many decisions in advance, they are clarified and refined only later;
• integration of all development results occurs at the end, as a result of which integration problems make themselves felt too late;
• users and the customer cannot get acquainted with the system options during development, and see the result only at the very end; thus, they cannot influence the process of creating the system, and therefore the risks of misunderstanding between developers and users/customer increase;
• the model is unstable to failures in project financing or the redistribution of funds, the development that has begun, in fact, has no alternatives "on the go".

However this model continues to be used in practice - for small projects or in the development of typical systems, where iteration is not so in demand. With its help, it is convenient to track the development and carry out phased control over the project. This model is also often used in offshore projects 1 From English offshore - outside the coast, in an expanded interpretation - outside one country. with hourly wages. The waterfall model has entered as an integral part of other models and methodologies, for example, in MSF.

spiral model was proposed by Bary Boehm in 1988 to overcome the shortcomings of the waterfall model, primarily for better risk management. According to this model, product development is carried out in a spiral, each turn of which is a certain phase of development. Unlike the waterfall model, the spiral model does not have a predetermined and mandatory set of turns, each turn can be the last one in the development of the system, when it is completed, plans for the next turn are drawn up. Finally, the coil is just a phase, and not a type of activity, as in the waterfall model, many different types of activity can be carried out within its framework, that is, the model is two-dimensional.

The sequence of turns can be as follows: at the first turn, a decision is made on the advisability of creating software , at the next system requirements , then the system design is carried out, etc. Turns can have other meanings.

Each coil has the following structure (sectors):

• definition of the purposes, restrictions and alternatives of the project;
• assessment of alternatives, assessment and resolution of risks; it is possible to use prototyping (including the creation of a series of prototypes), system simulation, visual modeling and specification analysis; focusing on the most risky parts of the project;
• development and testing - here a waterfall model or the use of other models and methods of software development is possible;
• planning for the next iterations - the results, plans and resources for subsequent development are analyzed, a decision is made (or not) on a new round; it is analyzed whether it makes sense to continue developing the system or not; development can be suspended, for example, due to disruptions in funding; spiral model allows you to do it correctly.

A single spiral may correspond to the development of some software component or the introduction of the next changes to the product. Thus, the model may have a third dimension.

The spiral model is inappropriate to apply in projects with a low degree of risk, with a limited budget, for small projects. In addition, the lack of good prototyping tools can also make it inconvenient to use the spiral model.

spiral model did not find wide application in the industry and is important, rather, in historical and methodological terms: it is the first iterative model, has a beautiful metaphor - a spiral, and, like the waterfall model, was later used to create other process models and software development methodologies.

Software product development knows many worthy methodologies - in other words, well-established best practices. The choice depends on the specifics of the project, the budgeting system, subjective preferences and even the temperament of the manager. 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, application programs in clinics for monitoring patients, integrated software for the control mechanisms of 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 - 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 stage of testing: the convenience of the interface, functional, load, 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 Vivaldi digital library network.

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. Understanding the 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 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.

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. On the project for the development of an EDMS for the ODU of Siberia SO UES, two meetings on changing the codification of sections of an electronic archive take 10 times more time than a programmer combining two folders. 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 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:
.
.
.
.

What methodologies do you use?