2 Software Development Models

Models (or, as they still like to say, methodologies) of software development processes are usually classified according to “weight” - the number of formalized processes (most processes or only the main ones) and the details of their regulation. The more processes are documented, the more detailed they are described, the greater the “weight” of the model.

The most common modern models of the software development process are shown in Figure 3.

Figure 3 Different models of the software development process and their distribution by "weight"

GOSTs

GOST 19 "Unified system of program documentation" and GOST 34 "Standards for the development and maintenance of automated systems" are focused on a consistent approach to software development. Development in accordance with these standards is carried out in stages, each of which involves the implementation of well-defined work, and ends with the release of a sufficiently large number of very formalized and extensive documents. Thus, strict adherence to these guests does not only lead to a waterfall approach, but also requires a very high degree of formalization of the development. On the basis of these standards, software systems are developed for government orders in Russia.

SW-CMM

In the mid-80s of the last century, the US Department of Defense was deeply thinking about how to choose software developers when implementing large-scale software projects. At the request of the military, the Institute for Software Engineering, part of Carnegie Mellon University, developed the SW-CMM Capability Maturity Model for Software [9] as a reference model for software development organization.

This model defines five levels of software development maturity.

1. The initial - the development process is chaotic. Only a few of the processes are identified, and the success of the projects depends on the specific performers.
2. Repeatable - the basic project management processes are established: tracking costs, deadlines and functionality. Some of the processes necessary to repeat previous achievements on similar projects are streamlined.
3. Defined - software development and project management processes are described and implemented in a single system of company processes. All projects use a standard for the organization process of developing and supporting software, adapted for a specific project.
4. Managed - collect detailed quantitative data on the functioning of development processes and the quality of the final product. The meaning and dynamics of this data are analyzed.
5. Optimized - continuous improvement of processes is based on quantitative data on the processes and on the trial implementation of new ideas and technologies.

The SW-CMM full description documentation takes about 500 pages and defines a set of 312 requirements that an organization must meet if it plans to certify to this standard of the 5th level of maturity.

RUP

The Unified Process (RUP) [10] was developed by Philippe Kruchten, Ivar Jacobson, and other Rational Software employees as a supplement to the UML modeling language. The RUP model describes an abstract overall process, on the basis of which an organization or project team must create a specific specialized process that is focused on its needs. It is this feature of RUP that causes the main criticism - since it can be anything, it cannot be considered anything specific. As a result of this general construction, RUP can be used both as a basis for the most traditional waterfall style of development and as a flexible process.

MSF

The Microsoft Solutions Framework (MSF) [11] is a flexible and fairly lightweight model built on the basis of iterative development. An attractive feature of MSF is the large focus on creating an efficient and unbureaucratic project team. To achieve this goal, MSF offers rather non-standard approaches to the organizational structure, distribution of responsibilities and principles of interaction within the team.

PSP / TSP

One of the latest developments of the Institute of software engineering Personal Software Process / Team Software Process [12,13]. Personal Software Process defines developer competency requirements. According to this model, each programmer should be able to:

• take into account the time spent on work on the project;
• take into account the defects found;
• classify types of defects;
• estimate the size of the task;
• implement a systematic approach to the description of test results;
• plan program tasks;
• allocate them over time and schedule work.
• perform an individual check of the project and architecture;
• perform an individual code check;
• perform regression testing.

Team Software Process relies on self-managing teams of 3-20 developers. Teams must:

• set your own goals;
• make your own process and plans;
• track work;
• maintain motivation and maximum performance.

Consistent application of the PSP / TSP model makes it possible to make the fifth level of CMM the norm in the organization.

Agile

The main idea of ​​all flexible models is that the process used in software development must be adaptive. They declare that their highest value is orientation towards people and their interaction, and not towards processes and means. In fact, the so-called flexible methodologies are not methodologies, but a set of practices that can allow (or may not) achieve effective software development based on iteration, incrementality, self-management of the team, and adaptability of the process.

Select process model

Heavy and light models of the production process have their advantages and disadvantages (Table 1).

Table 1. Pros and cons of heavy and light models of software development processes

Those who try to follow the models described in the books, without analyzing their applicability in a specific situation, indications and contraindications, are likened to followers of the cult of “Cargo” - the religion of aircraft fans. In Melanesia, they believe that Western goods (cargo, English cargo) are created by the spirits of their ancestors and are intended for the Melanesian people. It is believed that white people have gained control of these items through dishonest means. In the most famous cults of cargo, coconut palms and straw build exact replicas of the runways, airports and radio towers. Members of the cult build them, believing that these buildings will attract transport aircraft (which are considered to be messengers of spirits), filled with cargo (cargo). Believers regularly conduct military drills (“drill”) and some sort of military marches, using branches instead of rifles and drawing “USA” on the body of the order. All this is in order for the aircraft to descend again from the sky and there are more of these items.

Alistair Cowburn, one of the authors of the Flexible Software Development Manifesto [14] analyzed very different software projects that were carried out on different models from completely lightweight and flexible to heavy (SMM-5) over the past 20 years [15, 16]. He found no correlation between the success or failure of the projects and the models of the development process that were used in the projects. From this, he concluded that the efficiency of software development does not depend on the process model, and that:

• Each project must have its own development process model.
• Each model has its time.

This means that there is no single correct software development process; in each new project, the process must be determined anew each time, depending on the project, product and staff, in accordance with the “4-P Law” (Figure 4). Completely different processes should be applied in projects involving 5 people and in projects involving 500 people. If the product of the project is critical software, for example, a nuclear power plant management system, then the development process should be very different from the development, for example, of the site “rest.” And finally, the development process should be organized in a team of yesterday's students and in a team of successful professionals in different ways.

Figure 4. "The law of 4 P". The process in the project should be determined depending on the project, product and staff

The team that started the project does not remain unchanged, it goes through certain stages of formation and, as a rule, grows quantitatively as the project develops. Therefore, the process must constantly adapt to these changes. The main principle: not people should be built under the selected process model, but the process model should adapt to a specific team in order to ensure its highest efficiency.

What should be done for the success of a software project

Steve McConnell in his book [17] gives a test of a software project for survival. This checklist of 33 points, which I consider necessary to quote with minor adjustments. The program manager should use it periodically for internal audit of his processes.

To make a software project successful, you must:

1. Clearly set goals.
2. Determine how to achieve goals.
3. Monitor and manage the implementation.
4. Analyze threats and counter them.
5. Create a team.

1. Set goals

   1.1. The concept defines clear, unambiguous goals.
   1.2. All team members consider the concept realistic.
   1.3. The project has a rationale for economic efficiency.
   1.4. A user interface prototype has been developed.
   1.5. The specification of the target functions of the software product has been developed.
   1.6. Two-way communication is established with end users of the product.

2. Determine the way to achieve goals

   2.1. There is a detailed written product development plan.
   2.2. The project’s task list includes “secondary” tasks (configuration management, data conversion, integration with other systems).
   2.3. After each phase of the project, the schedule and budget are updated.
   2.4. Architecture and design decisions are documented.
   2.5. There is a quality assurance plan defining testing and peer review.
   2.6. Defined plan for multi-stage delivery of the product.
   2.7. The plan takes into account training, weekends, holidays, sick leave.
   2.8. The project plan and schedule approved by all team members.

3. We control and manage the implementation

   3.1. The project has a curator. This is such a top manager of the executive company who is personally interested in the success of this project.
   3.2. The project has a manager, and only one!
   3.3. The project plan defines “binary” checkpoints.
   3.4. All interested parties can get the necessary information about the progress of the project.
   3.5. Trust is established between management and developers.
   3.6. Established a process for managing changes in the project.
   3.7. The persons responsible for the decision to accept changes in the project are identified.
   3.8. The plan, schedule and status information on the project is available to each participant.
   3.9. The system code is automatically reviewed.
   3.10. The defect management system is applied.

4. Analyzing threats

   4.1. There is a list of project risks. It is regularly analyzed and updated.
   4.2. The project manager tracks the emergence of new risks.
   4.3. For each contractor is determined by the person responsible for working with him.

5. We work to create a team

   5.1. The experience of the team is sufficient to complete the project.
   5.2. The team has sufficient expertise in the application area.
   5.3. The project has a technical leader.
   5.4. The number of staff is sufficient.
   5.5. The team has sufficient cohesion.
   5.6. All participants are committed to the project.

Test evaluation and interpretation

Score: the sum of points, each item is estimated from 0 to 3:

• 0 - did not even hear about it;
• 1 - heard, but not yet used;
• 2 - partially applied;
• 3 - is fully applied.

Correction factors:

• for small projects (up to 5 people) - 1.5;
• for medium ones (from 5 to 20 people) - 1.25.

Result:

• <40 - project completion is doubtful.
• 40-59 - the average result. During the project we should expect serious problems.
• 60-79 is a good result. The project is likely to be successful.
• 80-89 is a great result. The likelihood of success is high.
• > 90 - a great result. 100% chance of success.

This checklist lists what needs to be done for the success of a software project, but does not provide an answer to the question of how to do it. That is what will be discussed in the remaining lectures.

findings

The fact that programmers produce intangible is collective thoughts and ideas expressed in a programming language. Due to the uniqueness of the industry, the experience gained in the branches of material production contributes little to success in managing a software project. Direct analogies with these industries do not work. Manage software development is different.

There is no one correct software development process. An effective production process should be based on iteration, incrementality, team self-management and adaptability. The main principle: not people should be built under the selected process model, but the process model should adapt to a specific team in order to ensure its highest performance.

To make a software project successful, you must:

1. Clearly set goals.
2. Determine how to achieve goals.
3. Monitor and manage the implementation.
4. Analyze threats and counter them.
5. Create a team.