Lecture
Software engineering is the application of a certain systematic, measurable approach in the development, operation and support of software [1].
The term software (software, software) was introduced in 1958 by world-famous statistician John Tukey. The term software engineering first appeared in the title of a NATO conference held in Germany in 1968 and dedicated to the so-called software crisis. From 1990 to 1995, work was underway on an international standard that was supposed to give a unified view of the software development processes. As a result, ISO / IEC 12207 [2] was released. In 2004, the industry created the foundational work “Guide to the Body of Knowledge in Software Engineering” (SWEBOK) [3], which collected the basic theoretical and practical knowledge accumulated in this industry.
In order to avoid ambiguities, but without pretending to be academic, I will allow myself to introduce working definitions of a number of terms that I will actively use in the future.
Programming is the process of mapping a specific set of goals onto a set of machine instructions and data, the interpretation of which on a computer or computer complex ensures the achievement of the set goals.
There can be any goals: sound reproduction in the PC dynamics, calculation of the spacecraft flight path to Mars, printing of the annual balance report, etc. It is important that they should be defined. It sounds trite, but no matter how often this is said before, you still have to deal with software projects that lack any specific goals.
This mapping can be very simple, for example, punching machine instructions and data on punch cards. And it can be multistage and very complex, when at first goals are mapped to system requirements, requirements to a high-level architecture and component specifications, specifications to the component design, design to the source code. Next, the source code is mapped to the deployment code using compilers and assemblers, the deployment code to calls to the environment software functions (OS, middleware, database), which can be located on many computers connected to the network, and only then to machine commands and data.
Professional programming (synonymous with the production of programs) - an activity aimed at generating income through programming.
The principal difference from simple programming is that there is, or at least some consumer is expected, who is willing to pay for the use of a software product. Hence the important conclusion that professional program production is always a collective activity in which at least two people participate: a programmer and a consumer.
Professional programmer - a person who is engaged in professional programming.
A professional programmer should be distinguished from a professional (master of programming). The spread of professional skills in programming is quite wide and far from everyone who earns a living by programming is a master, but more on that later.
A software product is a set of programs and accompanying documentation on their installation, configuration, use and refinement.
According to the standard [2], the life cycle of a program, a software system, a software product includes the development, deployment, support and maintenance. If the software product is not boxed, but rather complicated, then its deployment to customers, as a rule, is implemented by separate independent implementation projects. Maintenance includes the elimination of critical faults in the system and is often implemented not as a project, but as a process activity. Support is the development of new functionality, the processing of existing functionality, due to changing requirements, and improving the product, as well as the elimination of non-critical comments to the software identified during its operation (Figure 1). The life cycle of a software product ends with the decommissioning of a product and its removal from support and maintenance.
Figure 1 Software life cycle
Software development process - a set of processes that ensure the creation and development of software.
The most common software development process that has been observed over the years in the industry can be called “how it goes”. This does not mean that there is no process as such. It exists and, as a rule, provides software development at reasonable costs and quality, but this process is not documented, is “knowledge of the pack”, rests on people and is passed on from generation to generation. Targeted work to assess the effectiveness and improvement of the process is not conducted.
The software development process model is a formalized representation of the software development process. Often, when describing processes, instead of the word model, the term methodology is used, which leads to an unjustified extension of this concept.
According to SWEBOK 2004, software engineering includes 10 core and 7 additional areas of knowledge on which software development processes are based. The main areas of expertise include the following areas:
Additional areas of expertise include:
All this is necessary to know and be able to use in order to develop software. As you can see, project management, which we will discuss later, is only one of the 17 areas of knowledge of software engineering, and that is auxiliary. However, the main reason for the majority of failures of software projects is precisely the use of inadequate development management practices.
Standish Group, analyzing the work of hundreds of American corporations and the results of the implementation of several tens of thousands of projects related to software development, in its report with the eloquent title “Chaos” [4] came to the following disappointing conclusions (Figure 2):
Figure 2. The results of the analysis of the success of software projects for 2006
Immediately I will give answers to the eternal Russian questions "Who is to blame?" And "What to do?".
Who is guilty? No one. As no one is to blame for the fact that there are clouds in the sky, that it is raining, that the wind is blowing. Since the “chaos” itself was not, and is not, but is only God-given (for atheists - objective) reality, which lies in the specific specifics of the production of programs, as compared to any other production activity, because what programmers produce is intangible, these are collective mental models written in a programming language. And we must reckon with this specificity, unless, of course, we want to "blow against the wind."
What to do? Manage people. Success, as well as failure, of software projects lies in the field of psychology.
Programming guru F. Brooks in 1975 wrote [5]: “A programmer, like a poet, works almost directly with pure thought. He builds his castles in the air and out of the air, creating by the power of imagination. It is difficult to find other material used in the works, which is just as flexible, simple for polishing or processing and is available for the realization of grandiose ideas. ”
The fact that programmers produce intangible is collective thoughts and ideas expressed in a programming language. I do not say that software production is a super-complex intellectual activity. The industry is still in its infancy. The time of entry into the profession is much less than in other engineering disciplines. Developing software is definitely not more difficult than making rockets. Just because of the uniqueness of the industry, the experience of professionals gained in material production and outlined in the PMI PMBOK standard [6] does not contribute much to success in managing a software project. Manage software development is different.
Creativity is an intellectual activity of a person whose laws are unknown to us. If we knew the laws of creativity, then pictures, and poems, and music, and programs would have been creating computers for a long time. Creativity is what makes programming science and art related.
Creativity in programming begins with defining the objectives of the program and ends only when its code, written in any programming language, has the final point. Attempts to divide programmers into creative elite, architects and designers, and non-creative coders-programmers have no objective grounds. Even if the program's algorithm is strictly mathematically defined, two different programmers will encode it differently, and the resulting program will have different consumer qualities.
Creativity is inextricably linked with inspiration, and this substance is capricious and unpredictable (remember the famous dream of DI Mendeleev, about the Periodic Table of the Elements of his name?). I only know that without inspiration in programming is not enough. And the more complex the task, the harder it is to extract this inspiration from the subconscious. Sometimes it takes hours and sometimes weeks.
Programming is not art, in the sense that it is not a creative reflection and reproduction of reality in artistic images. About art in programming can and should speak only in the sense of skill, skill, knowledge of the business, as in any other profession. And as in any other profession, programmer's skill can deliver true aesthetic pleasure, but only for people involved in this profession.
Programming is not a science. The achievements of mathematicians in the field of logic, information theory, numerical methods, relational algebra, graph theory, and some other disciplines do not cover the percentage of programming problems. In programming, there is no system of knowledge about the laws governing the creation of programs. Even outstanding programmers will not take the liberty to assert about the architecture of the new software system that it will be successful. Although programming has already accumulated some experience of failures, which may allow the sophisticated programmer to see antipatterns in the architecture of the new system - the sources of serious future problems. But no more than that.
The current state of software engineering is reminiscent of a large cookbook with numerous descriptions of recipes for once successfully prepared dishes from ingredients that are no longer in the future. Tomorrow in the new system will be other computers, technologies, programming languages, tools and the surrounding software, new problems of interaction with which will have to be solved.
The professional creativity of the programmer is fundamentally different from the creativity in science and art. Programmer tasks become more and more complex every year, and the time needed to solve these tasks, on the contrary, is reduced every year. Therefore, modern programs are created by teams of several to thousands of programmers, while creative artists and scientists work, as a rule, alone.
There is still something that distinguishes the work of a professional programmer from a scientist, artist, composer and poet. The subject of activity of scientists are simplified models in which they can abstract away from most of the details of the real world that are not essential for their purposes. The mathematician, proving a new theorem on tensors, does not care about anything except the system of postulates that are the basis of differential geometry. A physicist, describing the dynamics of fluid in a pipe, abstracts from how molecules move and collide and from how planets move around the sun. Figures of art, too, are largely operated with abstractions. A poet, a composer, an artist need only make a hint, an outline of the object of creativity, and with this his work is finished. Let the reader, the listener, the viewer think out the rest.
The programmer also works with abstractions, but he has to keep in his head much more abstractions than any scientist. Abstractions accompany the programmer at all levels of program development from describing its goals to executable machine code. And these levels can be dozens. And at each level, the abstractions of their parts are becoming more and more.
In addition to abstract thinking, the programmer must have a strong systemic thinking in order to maintain the numerous relationships that exist at all levels of programmer abstractions, as well as the relationships between these levels. Another difficulty is that all these abstractions and the relationships between them change over time, and the programmer must take this dynamics into account.
In addition, the programmer must have manic perseverance, focus and perseverance to go through all possible behaviors of his abstractions and thorough study of all the details. The study should be absolutely accurate and should not contain a single error, an incorrect, unnecessary, or missing symbol of the source code (and this is sometimes millions of lines). Programming tools: parsers, compilers, etc., - only slightly help in this work.
Another feature that is inherent in programmer creativity is the constant updating of information technologies, which the programmer needs to know and successfully use in his work. Therefore, a professional programmer should, as one of our former leaders said, "learn, learn and learn." The programmer must keep in mind, constantly replenish and actively use in practice gigabytes of professional information. This is a device of computers, computer networks and network protocols. These are operating systems and programming languages. These are software interfaces of middleware and application libraries with features and bugs of their implementation in specific products. These are technological standards, development technologies and tools that support them. These are software architecture, design patterns and anti-patterns, and a lot of other information.
Back in the early 70s, a remarkable scientist, Academician A.P. Ershov, said [8]: “A programmer must have the ability of a first-class mathematician for abstraction and logical thinking in combination with Edison's talent to construct anything from zero and one. He must combine the accuracy of an accountant with the insight of a scout, the fantasy of the author of detective novels, and the sober practicality of an economist. ” Figuratively it can be said that the programmer must combine the ease and flight of Mozart’s talent with the diligence and thoroughness of Salieri.
Programming is not art and not science - it is a craft. Today, we are just as far from industrial development programs as 50 years ago.
And since this is a craft, a person who has learned to write programs in C ++ will be as far from a professional as a third-grade student of secondary school who has learned to write in Russian, from A. S. Pushkin or F. M. Dostoevsky. The path to mastery in the craft is only through experience. You can not learn programming by reading books. It is impossible to learn from books to write novels, paintings, poems, music. And programmers need constant work of self-improvement and self-development. Therefore, not everyone who writes programs becomes professionals.
For some reason, if we are talking about poets, artists, composers, then the range of creative performance does not surprise anyone. “Creative flight”, “creative stagnation” is about artists. And when we talk about the uneven performance of programmers, many managers begin to argue with this, and try to "kick" programmers, as if it would make them think faster. Will not force. But can force to quit or do imitation of work.
True, there are still engineering disciplines such as construction, engineering, aircraft manufacturing and other branches of material production, in which hundreds of thousands of people work on the creation of new products. There is a great temptation to draw an analogy with these industries and talk about an industrial approach to software development. Does not work.
Упрощенно, путь от идеи до ее реализации в этих отраслях выглядит следующим образом: НИР-ОКР-завод. В верхней части этой пирамиды находятся отраслевые НИИ, которые производят идеи и занимаются проектированием новых изделий. На втором этаже пирамиды работают конструкторы в конструкторских бюро, в задачу которых входит реализация нового проекта в чертежах деталей и технологиях изготовления и сборки. На нижнем уровне находятся производственные мощности — заводы, на которых инженеры и рабочие воплощают «в железе» чертежи и технологии.
Если проводить аналогию, то программисты работают исключительно на вершине описанной пирамиды. Программирование — это проектирование и только проектирование. Роль конструкторского бюро для программного проекта выполняют компилятор и сборщик программ. А программистским аналогом завода, который переводит конструкторскую документацию в продукт, доступный потребителю, служит вычислительный комплекс, на котором развертывается и выполняется созданная программа.
А теперь давайте вспомним, сколько НИР так и остались на бумаге, не дойдя до ОКР, и сколько еще ОКР закончилось закрытием тематики. Я думаю, что процент инноваций, дошедших до производства от общего числа проектов, выполненных в отраслевых НИИ, будет сравним с процентом успешных программных проектов. И давайте еще учтем, что ученые в НИИ опираются на достаточно хорошо изученные законы математики, физики и химии, а программирование, как мы отмечали выше, пока остается лишь ремесленным производством.
Для коллективного программистского творчества скорее уместна аналогия с созданием художественного кинофильма или театрального спектакля. Количество провальных проектов в этих областях ничуть не меньше, чем в программировании. Дай Бог, если хотя бы пятая часть кинофильмов не «ложится на полки» после первого показа. Об этом же пишет авторитет в управлении программными проектами У.Ройс [7]: «Менеджеры программных проектов смогут добиться большего, если будут применять методы управления, характерные для киноиндустрии».
И еще одна аналогия программных проектов с кинематографом. Наличие даже самых звездных актеров не обеспечивает успех фильма. Только талантливый режиссер способен организовать и вдохновить актеров на создание шедевра, открыть новые звезды. А талантливых режиссеров, как, впрочем, и талантливых менеджеров программных проектов, к сожалению, не так много, как хотелось бы.
За 50 лет развития программной инженерии накопилось большое количество моделей разработки ПО. Интересно провести аналогию между историей развития методов, применяемых в системах автоматического управления летательными аппаратами, и эволюцией подходов к управлению программными проектами.
"We'll see how it goes". Open control system. Full confidence in technical leaders. Business representatives are practically not involved in the project. Planning, if there is one, is informal and verbal. Time and budget are usually not controlled. Analogy: ballistic flight without feedback. It is possible, but close and inaccurate.
“Waterfall” or cascade model. Hard feedback control. Calculation of the reference trajectory (project plan), measurement of deviations, correction and return to the reference trajectory. Better, but not effective.
"Flexible management". The calculation of the reference trajectory, the measurement of deviations, the calculation of the new falling trajectory and the correction for entering it. “Plans are nothing, planning is everything” (Eisenhower, Dwight David)
«Метод частых поставок». Самонаведение. Расчет опорной траектории, измерение отклонений, уточнение цели, расчет новой попадающей траектории и коррекция для выхода на нее.
Классические методы управления перестают работать в случаях, когда структура и свойства управляемого объекта нам не известны и/или изменяются со временем. Эти подходы так же не помогут, если текущие свойства объекта не позволяют ему двигаться с требуемыми характеристиками. Например, летательный аппарат не может развить требуемое ускорение или разрушается при недопустимой перегрузке. Аналогично, если рабочая группа проекта не может обеспечить требуемую эффективность и поэтому постоянно работает в режиме аврала, то это приводит не к росту производительности, а к уходу профессионалов из проекта.
Когда структура и свойства управляемого объекта нам не известны, необходимо использовать адаптивное управление, которое, дополнительно к прямым управляющим воздействиям, направлено на изучение и изменение свойств управляемого объекта. Продолжая аналогию с управлением летательными аппаратами — это расчет опорной траектории, измерение отклонений, уточнение цели, уточнение объекта управления, адаптация (необходимое изменение) объекта управления, расчет новой попадающей траектории и коррекция для выхода на нее.
Для того чтобы понять структуру и свойства объекта и воздействовать на него с целью их приведения к желаемому состоянию, в проекте должен быть дополнительный контур обратной связи — контур адаптации.
Известно, что производительность разных программистов может отличаться в десятки раз. Утверждаю, что производительность одного и того же программиста может так же отличаться в десятки раз. Заставьте лучшего в мире бегуна бегать в мешке, и он покажет в 10 раз худший результат. Заставьте лучшего программиста заниматься «сизифовым трудом»: плодить документацию (которую, как правило, никто не читает) в угоду «Методологии» (именно с большой буквы М), — и его производительность снизится в 10 раз.
Поэтому, помимо чисто управленческих задач руководитель, если он стремится получить наивысшую производительность рабочей группы, должен направлять постоянные усилия на изучение и изменение объекта управления: людей и их взаимодействия.
Comments
To leave a comment
software project management
Terms: software project management