Agile Development vs. traditional Software engineering

after the software crisis broke out in the mid-1960, people were exploring the production mode of software in order to find more efficient and scientific software development ways to improve the productivity of software and improve the quality of software. Then the concept of software engineering was proposed. So we are in the current software development process, or in the introduction of the program engineering teacher, we will see such a development model: in the early stages of the project as far as possible to do research, customer needs to contract the way to "freeze", on the basis of these needs determination and investigation, You can start a preliminary software development proposal, followed by requirements analysis, system design and so on. There may be iterations in the development process, but usually the customer will see the product tolerance distortion only when testing or training. In order to ensure the correctness of the development process and the timely delivery of the product, it is necessary to write detailed design and test documentation before each task is developed. This software development method in the software crisis after the outbreak to a certain extent, improve the development of the normative, reliability, the face of complex software design, can also be based on various types of documents in the division of functional modules, and then the task assigned to the individual completion of collaborative development. However , after entering the 21st century, the rapid development of the information industry has also brought the great prosperity of the software industry, and therefore the competition of the market is more intense, and the product development cycle needs to be shortened correspondingly. In the face of more and more software development projects, the traditional software engineering seems to be no longer as a "panacea" at the beginning of the proposed, so there is a later proposed agile development. So what's the problem? Can agile development effectively face all development scenarios?

In order to get a deep understanding of this problem, we need to know what software development is, and what kind of software can be called a good software. The so-called software development, the essence is to transform the user's needs into executable code to meet the needs of a process, after the transformation of the good or bad how to judge, there is no absolute standard, but we can from the general user feedback summed up the following points:

(1) Correctness: The correctness of software refers to the ability of the software to perform the task correctly and get the correct feedback or result according to the requirement. This is undoubtedly the first guarantee of software quality. Simply imagine, if the result of your calculator software operation is not correct, can be called a good software?

(2) Reliability: Reliability in accordance with the requirements of the IEEE, contains two meanings. On the one hand, it refers to the ability of the program to execute the required function in the specified time period, which is related to the correctness of the software, and the probability that the software does not cause the system failure in the specified conditions and time, and the robustness of the program is mainly involved. That is, if there is an unexpected software that can be handled in a predetermined manner, so as to avoid serious consequences. For example, the bank's account management system, you do the transfer operation, one side of the money you have been deducted, but at this time machine failure, such as power outages, then you need to consider how to deal with this unexpected situation, to avoid the occurrence of one side of the money, the other side of the situation.

But a software can meet the needs of users and get the correct results, the execution process has always encountered an unexpected situation can be effectively handled, so that can be called a good software? Obviously this just satisfies the most basic requirements, you can deliver your product, however it is not known as a good software. You should also take into account the efficiency of the software (how much space to occupy, how much time it takes to perform a task, etc.), the adaptation on different platforms (of course the software can not cross-platform), whether concise and easy to use, and so on, not listed here.

Once we know what a good software is, or a software that meets the basic requirements, let's look at the traditional software development approach, whether we can make the best use of the resources available and design a good software correctly and efficiently.

We use the waterfall development model in traditional software engineering to illustrate the development process, and the basic software engineering project from start to finish basically contains the following basic stages:

The results of each phase of the

process as input to the next stage, the implementation of the next phase of the feedback, the previous phase of the corresponding adjustment. But such a pattern or development method has obvious shortcomings. First, the software development process is based on the correct estimation and design at the beginning of the project, so in the development to a certain stage, will be tested, then found that the bug is likely to be neglected at the beginning of the design of the serious problem, and even affect the structure of the entire system. Then the project will be written in a variety of documents, design must be strictly according to the document, but the actual design changes are ubiquitous, which includes requirements, design, code, testing all aspects, so completely follow the document development is not too realistic. Finally, the customer sees the product is at the end of the entire process, but after all, the customer does not participate in the design, he stated the requirements and the needs of designers understand, or the implementation of the way, not consistent, which led to the product development, but customers do not buy, at this time again overturned redesign, too late. These drawbacks are obvious and can be seen from the development of countless software, in the final analysis, because the situation is changing, and your design is based on an understanding of a previous point in time. Not that using this development model can not develop a good software, the team is superior, of course, but not every team has the foresight and the ability to excel.

Next we look at Agile development. Look at the name to be able to understand this development method has a characteristic, "fast". So-called agile development, I personally think that the core of the idea is to launch a ready-to-use software as early as possible, may not complete all the user's needs, the design is not perfect, but this is only one iteration of the whole process. By using the software, the user provides feedback, and thus participates in each iteration, where the user can of course change existing requirements or propose new requirements. Agile developed this point, of course, there are other requirements, the specific reader can see the agile development of the 12 guidelines, where the author no longer repeat. So let's take a look at how agile development solves the problems encountered in traditional software engineering. The first point is that because this is an iterative incremental development pattern, at the end of each iteration, the user will be able to get in touch with the product in time and be clear about the requirements, so the ambiguous problem of user needs will be solved gradually with the development. Then there is the problem that the test participates too late to cause serious bugs to be discovered too late, which leads to the project not progressing as expected. In agile development, projects are solved to form sub-modules with various functions, each with an integrated and operational feature, so that testing can be infiltrated into each development process. In addition, one of the characteristics of agile development is driven by testing, that is, after understanding the requirements, first, according to the requirements of the test code to write, and then write the relevant code to meet these test cases. It can be said that agile development recognizes that the world is more in line with the reality of the real world, the situation is the time to change, the need to be able to recognize changes in time, and timely response to meet the pace of development. But agile development is not without shortcomings, when the face of the project is relatively large, it may be difficult for us to partition the project module. And as the project grows, the size of the team also needs to increase correspondingly, and the team is responsible for the communication between the various modules becomes more difficult, making integration between modules difficult.

In fact, about these two development methods, in the process of accessing the information, it is very appropriate to see a metaphor. The traditional way of development is like a conventional artillery, and agile development is like a guided missile. The common artillery attack target is, to want to hit, must start to aim the quasi and the target movement trajectory carries on the accurate forecast, even then, after the launch still will be affected by the wind speed, the sudden appearance obstacle and so on. As long as the guidance missile set the target at launch, it can adjust its motion state according to the target in the course of traveling, and finally hit the target. Of course, this metaphor is a bit partial, but I believe that the understanding of the development process is still very image.

Agile Development vs. traditional Software engineering