The history of the development of design methodologies (software engineering)

When writing an article, I had great difficulty in finding information. Information simply was not. After a long digging in Google’s pages, it was discovered that the design terminology in Russian is somewhat different. In Russian, design is one of the stages of software development, and the discipline studying the problems of creating and managing projects, design methodologies, etc. is called software engineering or industrial programming technology (if in Russian). If there are still those who did not know this, then perhaps my remark will help you a little.

How it all began

The history of the development of project management as such goes back to Noah's Ark and the collective hunt of primitive people for a mammoth. Moreover, some elements of project management can be seen in the behavior of predators hunting in packs.
')
In ancient times, design was associated with the “science of the architect” and connected this science not only with the erection of buildings, but also with the creation of construction and military machines. The Roman engineer and architect Mark Vitruvius in the 1st c. BC in his treatise "10 books on architecture" gave the design the following definition:
In theory - to show and justify the performance in accordance with the requirements of art and expediency.
In a practical sense - the execution of human hands work from any material on this drawing.

However, the history of the development of project management as a discipline is relatively young: it dates back to the 30s of the 20th century and is associated with the development of special methods for coordinating the engineering of large US projects — aviation in the US Air Corporation and oil and gas in the Exon company. In the USSR, in the same period, the theory and practice of the line organization of work on the implementation of large construction projects began to develop.

The emergence of a new discipline

The prerequisites for introducing project management principles into the software development process began in the late 60s - early 70s of the last century, when an event occurred that went down in history as the first programming crisis. The event consisted in the fact that the cost of software began to approach the cost of hardware (“hardware”), and the growth dynamics of these values ​​made it possible to predict that by the mid-90s all of humanity would be engaged in developing software for a computer. The development of microelectronics has led to a sharp increase in computer productivity with a significant reduction in cost. Restrictions for hardware began to go away, the remaining restrictions fall to software. This led to the fact that the ability to build new programs lagged behind the requirements for new programs.
Another development trend originated within the industry itself and was based on strengthening the view on program development as more than simple “coding”. Instead, software is considered to have a full life cycle, starting with the appearance of the concept and going through the stages of design, development, commissioning, maintenance, and development. The shift in focus from coding spawned the development of methodologies and advanced tools that armed teams of engineers involved in all phases of the software life cycle.
Then they started talking about software engineering (industrial programming technology) as a certain discipline whose goal is to reduce the cost of programs. Such a problem should be solved by a more competent organization of the development process. This led to the development of software design methodologies and its construction into the main components of the development.

The term software engineering was first used in 1968 as the theme of a conference devoted to the issues of maximum loading of the most powerful (at that time) computers.
The definition laid the foundations for a new scientific and practical discipline: it was necessary to create a system of engineering principles applicable to software development, to ensure cost-effectiveness and reliability of development, as well as effective performance of the final product on various real machines.

So software engineering is an engineering discipline that is related to all aspects of software production from the initial stages of creating a specification to supporting the system after commissioning.

Software Engineering Methodologies

From this point on, programming “clutters” with various additional activities: requirements development, planning, testing, configuration management, project management, creation of various documentation (project, user, etc.). The development of software code is preceded by analysis and design (the first means the creation of a functional model of the future system without taking into account the implementation, for the programmers to understand the requirements and expectations of the customer; the second means a preliminary layout, sketch, plan of the system on paper).
All these and other additional activities performed in the process of industrial programming and necessary for the successful execution of orders will be called software engineering. It turns out that this is how we designate, firstly, some practical activity, and secondly, a special area of ​​knowledge. Or in other words, scientific discipline. After all, to facilitate the implementation of each individual project, to be able to use the diverse positive experience achieved by other teams and developers, this very experience is subject to reflection, synthesis and proper design. So there are various methods and practices (best practices) - testing, design, work on requirements, etc., architectural patterns, etc. As well as standards and methodologies relating to the whole process. It is these generalizations that are included in software engineering as a field of knowledge.
Thus, methodologies in software engineering are one of the most dynamically developing components of the field of knowledge, since carry a practical component.
Modern classification of project management methodologies or project life cycle models according to SWEBOK is as follows.
Project management methodologies:

• traditional (cascade, waterfall) model;
• spiral model;
• iterative and incremental model (evolutionary approach).

More on methodologies

As the name implies, traditional methodologies are built on the sequential implementation of all phases of a project and the final product will be obtained only after all the steps have been completed. The return to the previous stage is not provided, and when a critical error occurs, the whole project begins anew. The main example of such development methodologies is a cascade model or Waterfall model. The source of this model is considered to be the article of Winston Royce published in 1970. However, Royce himself described this model as an example opposed to an iterative model, applicable only to very simple projects and he himself used iterative methodologies. Royce also wrote that in particularly difficult places of the project and when applying new, previously unused technologies, intermediate stages can be repeated twice and the customer receives a second version of the product at the end of the project. Such an approach cannot be called iterative, but unequivocally consistent too. In the initial period, she played a leading role as a method of regular development of complex software. In the 70x - 80x years of XX century, the model was adopted as the standard of the US Department of Defense.
As methodologies evolved, the cascade model was subjected to harsh criticism from all researchers who proposed their methodologies. Sequential execution of development stages does not change the requirements for a software product before the release itself. The larger the project, the more accumulated the problems in the design process. And the implementation of changes in the next version of the product sometimes becomes unwise. Product must be written with 0 . Thus, the cost of a workable version is not justifiably increasing. And the percentage of successfully completed projects is negligible. However, can traditional development methodologies be called obsolete? Not really. For projects affecting the safety of life strictly set requirements and a high degree of formalization is a fundamental and necessary factor.
In addition, despite the nowadays fashionable criticism of the traditional model, it plays an important role because it imposes on the development process the requirement for the discipline that is extremely necessary for it, with which it is possible to successfully bypass unstructured processes like “write and rule”. This model has made a fundamental contribution to the understanding of software development processes with the following statements:

• the process must be subject to discipline, sound planning and management;
• product sales should be delayed until the full understanding of the objectives of this implementation.

The spiral life-cycle model became the next (after the waterfall) stage of development of development methodologies, since it solves the main problem of the cascade model. Each phase of the waterfall development process in the spiral methodology ends with a prototyping and risk management step. The prototyping stage after each phase of the project allows you to determine how the current state of the project corresponds to the original plan. According to the results of prototyping, either a transition to the next phase or a return to one of the previous phases is performed. However, the phases and phase sequence remain linear. The author of this model is Barry Boehm, who published the article "A Spiral Model of Software Development and Enhancement" in 1988. Despite the fact that in the SWEBOK this model is singled out separately from the iterative one, when describing the models, the conclusion is drawn that the spiral methodology belongs to the iterative family. This is due to the possibility of changing requirements between the stages and the release of product prototypes after each cycle. Perhaps such a separation is due to the author’s affiliation of methodologies.

The iterative model involves splitting the project life cycle into a sequence of iterations, each of which resembles a “mini-project”, including all phases of the life cycle as applied to creating smaller pieces of functionality, as compared with the project, as a whole. Mention of this methodology began to appear long before the article of W. Royce and the emergence of software engineering itself. The origins of the concept of iterative development can be traced to the 30s work of product quality expert Walter Shewart from Bell Labs. An important milestone in history is the project carried out in the 1950s to develop a supersonic jet aircraft X-15. According to the participants of these works, the application of this methodology has largely determined the success of the project.
The most flexible development methodologies currently discussed (Agile methodologies) relate specifically to iterative life-cycle models. When describing any of the flexible methodologies, the principle of separation into iterations is mentioned. However, the peculiarity of these methodologies is an emphasis on the human factor, and not on the project documentation, which is not indicated in any way in the description of the iterative and incremental methodology.

Flexible development methodologies began to emerge against the background of the rapidly growing complexity of technology and general informatization. Now the customer in most cases is a person far from information technology. For such a customer, the main thing is the finished product, not the folios of the documentation. With the exponentially growing rate of development of information technology, the deadlines for software development have shrunk and become tougher. Now there is no time for long planning, writing documentation and full testing. The software product may become obsolete before release. In contrast to traditional development methodologies, iterative methodologies divide project execution into short time-limited iterations. After each iteration, the customer is provided with the result. Provided rollback to previous iterations. The emergence of flexible methodologies is not tied to a specific date, since from the mid-90s began to appear and be implemented almost in parallel. These were development methodologies such as: Scrum (1995), Extreme Programming (1996), Crystal Clear, Lean, Kanban, and others. Created in February 2001, the Agile Manifesto, proclaimed the philosophy of flexible development methodologies and set the vector for the development of these methodologies.

The current stage of development of methodologies

Now the choice of design methodology is more than ever influenced by marketing. More and more agile implementation consultants, coaches, conducting endless trainings, seminars, webinars, endless meetings, conferences, round tables. All these activities are aimed at selling implementation in IT companies for a lot of money by invited experts or upgrading the ratings of companies that have already implemented flexible methodologies.
Flexible methodologies now are more a body of knowledge on the organization of people's work from a psychological point of view. Such methodologies help the team to be creative, teamwork, communication skills, and more. The technical side of the organization of work increasingly goes by the wayside. Only XP (Extreme Programming) has in its arsenal such engineering practices as development through testing, metaphors and refactoring. These practices are successfully used in combination with other methodologies. With poor-quality implementation of Agile, we get what is happening in the market of IT products. The market is oversaturated with poor-quality, unstable products that do not meet the requirements of neither functionality nor interface. Moreover, the speed of production of such products, thanks to the principle of continuous integration promoted by Agile, is constantly growing.

With the growing decline in the quality of IT products, methodologies began to appear, seeking to improve this quality. This methodology has become DEvOps.
The term “devops” was popularized at the DevOps Days conference in Belgium in 2009. Since then, this methodology is increasingly gaining popularity. This is partly due to the fact that the principles of DevOPs promote not a rejection of the organization’s existing methodology, but a combination with it. The overall concept of DevOps is to enhance collaboration between development teams (DEVelopments) and operations (OPerations) within the same organization that are responsible for software development. This methodology is, without exaggeration, a new round of evolution of development methodologies, since it focuses not only on meeting customer requirements within tightly defined deadlines, but also improving the quality and stability of the product.

In conclusion, I would like to add that the topic disclosed in the article is one of the components of my graduation project. That is why the purpose of this article is the opinion of experienced and knowledgeable people in this matter, therefore, comments of any kind (and especially on the topic) are very welcome.

Sources

Project management software development. Discipline "Flexible software development technology" author: DG Shopyrin
devopswiki.net/index.php/DevOps
ivanpesin.info/blog/2012/02/building-a-devops-team/Translation of the article by Brian Henry. Creating a DevOps team.
“Flexible development methodologies. version 1.2 ”by Wolfson Boris
www.ibm.com/developerworks/ru/library/a-devops1 translation of Paul Duval's article. "Agile DevOps - flexible software development and operation: Leveling the software release process"
www.sibinfo.ru/archive/news/03_10_14/iid_history.html Iterative and incremental development: A Brief History. By: Craig Larman
swebok.sorlik.ru/software_engineering.html SWEBOK. Translated by Sergey Orlyk with the participation of Yuri Buluy.
www.cossa.ru/articles/234/33622 statistics of successful IT projects.
ndo.sibsutis.ru/magistr/courses_work/tspo_work/lectures_index.htm lecture notes: Software Development Technology
"Designing Information Systems" Author: Sapozhkova TE
"Project Management: Tutorial" Posted by: Dulzon AA
devopshub.net/top-3-mifa-o-devops-chem-vse-taki-devops-ne-yavlyaetsya Three myths about DevOps
"Introduction to software engineering." Author: S.N. Karpenko
“Scrum and XP: Notes from the Front.” Posted by: Henrik Knieberg
“Software Development Technologies: A Textbook.” Author: S. Orlov.
habrahabr.ru/company/scrumtrek/blog/166039 DevOPs
Wikipedia. Where without it.