Lecture
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.
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:
Team Software Process relies on self-managing teams of 3-20 developers. Teams must:
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
Model weight | pros | Minuses |
---|---|---|
Heavy | The processes are designed for the average qualification of the performers. Great specialization of performers. Below are the requirements for team stability. There are no restrictions on the scope and complexity of projects performed. | Requires substantial managerial add-in. Longer stages of analysis and design. More formalized communications. |
Lungs | Less overhead costs associated with project management, risks, changes, configurations. Simplified stages of analysis and design, the main focus on the development of functionality, the combination of roles. Informal communications. | Efficiency is highly dependent on individual abilities, require a more qualified, versatile and stable team. The scope and complexity of the projects performed are limited. |
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:
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.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.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.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.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.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:
Correction factors:
Result:
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:
Comments
To leave a comment
software project management
Terms: software project management