At present, the domestic software in China has begun to pay a lot of software engineering, and in the late 1980s, the beginning of the 1980s, the beginning of the Chinese character system, but the understanding of the understanding of the domestic development process, I think software engineering is one aspect ( It may even be a very important side), but the problem hidden after the appearance is also ignored. I think there is some problems or understanding of the current development link, which is typical in:
1, learn to excellent
This problem is very common, many people think this: the issue should be considered after 35 years of age. This idea is the idea of "learning and excellent rules", good developers, not necessarily good managers, because the face is different, the knowledge structure is different. However, due to the very traditional idea, it is considered that leadership should be better all aspects, so strongly push "learning" as "taxi". This not only doesn't have better improvement efficiency, but it is wasting a good talent. At the same time, it is also due to traditional ideas, "scholars" is more respectful, and "learning" is often considered to be blue collar, so many "learning and excellent" people have the incentives of "taxes". I think this is an abnormal phenomenon. The status of "learning and excellent" and the respective respect should have corresponding judgment mechanisms, for example: system designers should be more respect than the project manager. Only in this way, "learning" can be able to design, "Shi" can better play the functions of "Shi".
2, process and stage
Only the process does not seem to say, we all know that the development of any software product is a long time development process. This process is also risky. If there is no effective process, it is just a simple strict According to the process of demand, design, development, encoding, test, the problem is there. It must be clear that there is no absolute successful software engineering, nor does it meet the absolute development process in all circumstances, and the process stage is only lowered, cut the cake, can't eat multiple times at a time. This corresponding solution in the software engineering is a milestone. During the vast majority of development, the role of milestones is very important. In some development, the progressive development, spiral process is also an extension of milestones, but these milestones are defined in their own development process.
A good development process should be flexible as possible in risk management, I don't agree to place the milestone phase management in the details of the development process, but should be flexible in different products or project development. Sometimes a milestone may just be in the early days of the demand phase, but if it is in line with the actual development needs, I think it is a good development method. Observe RUP with this view, I think the definition of milestones in RUP has some stereotypes. RUP is basically an evolutionary development method, and the evolution is clear, but for the actual development of milestones defined flexibility performance Not sufficient. Of course, any development method is not possible to meet all requirements, and RUP still has a large strength on the project relative to fixed demand. At this point, I am more than the development method of MSF.
3, the left and right of software engineering
I used to learn a concept when I learned the Male, it was to go left and right, it seems to be as defined: Left is to do the future. Now, the right thing to do. These two are not good. True to tell, I think there is some left taste of RUP, CMM. From management perspectives, management has three phases: energy management, institutional management, standard management. I think RUP, CMM, etc. belong to standard management. At present, there are many people's ability to manage people's management has not been made, and they are eager to carry out standard management is not the right direction. First, it is a top priority to evolving the ability to manage the man-man management to institutional management. The so-called institutional management is to establish the company's actual rules and regulations, doing people, doing things under a game rules, so you can improve the work efficiency, better communication and development. Problem. Only in this way can it be more profoundly understanding of standard management. Crossing this stage, directly jump to the higher level, just like the idea of communism at this stage, some unrealistic. Of course, the system management of a few companies has been very good, and the work efficiency is really high, then it is another matter. 4, missing what kind of talent
I remember a joke saying that foreigners engage in software projects in a black house, but now still caught it, and the Chinese is in a black room, and there is no cat, then someone says, I said, I I have caught the cat. This joke is an explanation until now, the software engineering is still a process of continuing to explore, develop, and the other side also shows that China engages in software engineering nothing. (The above is taken, "I have a dream", author: Hu Chaohui, see ChinaByte.com detail)
So what kind of talents are China? I think it is a system architecture. Many people will say: We lack software engineers, lack of good project managers, lack ..., yes, these people are indeed lacking, but the most important is system designers. Because, whether the project manager, proficient in software engineering, we can cultivate, relatively cultivation costs are not very high, but the system architect needs many years of industry experience and superb design levels, these are not possible in a short time. get.
Many people say that most of our projects are a low-cost packaged project, but have you think of it, if, there is really a project is to let everyone complete a very deep system, and several companies can be competent. ? ! Why do many Open Source systems can do very much, not because of how software projects these Open Source, just because there are some excellent system designers who are involved in design. Software engineering can only make the work that can be done better and cannot solve the work that does not do. This can also illustrate why the importance of software engineering in business software is very simple: if you can do it, it is better to make better.
Software engineering is a mosaic on the building. It is of course better, but if the structure of the building is not good, it is only a mosaic in many mosaics, and it is only Jin Yu, and it is possible.
5. Normally understanding of programmers
Programmers are required to have creative, almost everyone thinks like this. But in the actual situation, many people began to talk about how to use the programmer as a gear of the running machine! This is not right, it is a misinterpreetment for software engineering! First of all, the programmer is not a typist, the programmer is important, his head is not his keyboard. The programmer is not a designer, which does not require him to have a macro view. Programmers are required to be very proficient in an aspect, even if it is a small part. The system designer cannot make the design to make a program, and he needs to grasp the whole. Relative, programmers need to grasp local. Of course, if any part is doing very well, the overall is not necessarily good, and it is the same. I think a boat, the designer is a helmsman, he needs a macro ability, you need to know that there is a dangerous roof, you need to have a risk, and the programmer is a hand, he needs to do with you, you need the best boating Posture, there is a need for hard work. Don't think that the programmer is a machine, you can know the trajectory of the ship sailing as you can listen carefully, because, sometimes the problem of sailing is often discovered by the people who are boating first.
6. Discussion also needs a certain standard
Sometimes there will be such a problem: a group of market staff discussions with a group of technicians, in order to solve the problem of market and technology, the market staff said the market problem, technical personnel said technology problems, and the results often reasonable , Her mother said that her wife is reasonable. So, the discussion also needs a certain standard! How to define this standard is not the same in different occasions and the environment. Technicians ultimately need to solve the problem of market, but the solution to the solution is not simple to obey. If so, it is impossible to make a product that is really in line with the market, because market staff see is only a certain stage of market items, they don't clear this reason, and they don't know the essence of the reason.
For example: For example, now people often say the 3-story structure, often need to let you use the 3-story idea to solve the actual problem, but they don't clear why, just think that many people do this. I don't have the advantages of the 3-layer structure, but it is not necessary to use the 3-layer structure in a lot of projects, because it will increase the complexity, and the flexibility of the flexibility requires a lot of customers' support (customers very clear Description Business Logic), at the same time, the benefits of truly playing the 3-layer structure also requires a strong designer's good design. There is no need to have more this in many small projects, and 3 layers of problems in two layers.
Establishing the standards of this discussion requires that the technician understands the problem of the problem and knows the essence of the problem. What I mean is not required to have a very strong market in the market, but to listen to market personnel in a timely manner.
Simple obedience to market staff is often directly why the project controllable failed.
7, one-sided understanding management;
Now there is a momentum that managers in software engineering will take a manual to move, and affirm that 10 8, 9 will not have a big problem. But is the question really? There is a myth of the manager in the "Software Engineering - Practitioner Research Method":
Myth: We already have a book about building software standards and procedures. Can they provide people with information that they need?
Fact: Good for standard books already exist, but is it true? ... Is them complete? In many cases, the answers to these issues are "not". (P.11)
We must clearly manage the responsibility, essence and favorable. Excellent management is nothing management, the goal of management is not managed. Regardless of the premise, there is a set of actual game rules, and everyone makes games in accordance with the rules of the game. Some people understand that management is the back of the managed by the manager every day, and the regulation is not promptly scheduled. This is wrong, such a manager is a normal work and is a misinterpreter of management. Therefore, the premise of excellent management is to establish a valid game rule that everyone can follow, under this rule, to achieve efficient work.
That kind of understanding is to find someone talking, picking up the problem, and urges the progress of the progress. If you really have this problem, I think that it does need to re-examine the rules you defined.
8. Do you have a continuous development framework?
What is the consequences of knowing that it is impossible? It may be like this: The project progress is too tight, there are many product problems, and it is falling into the queen of the construction period every day ... Many people say that the project is too tightly too tight. It is not that the project plan is not strict. It is not in the software project. However, if you think about it, if you really have it: the market is full, project plan Strictly, the software engineering is in line with the actual, then do you have a grasp of a project that is actually needed, excellent, low-maintained projects? I think it's okay.
Many people will not be opposed, if the customer's request is to make some Word, PowerPoint template (no need to write a lot of code), we can easily meet the needs of our customers. However, if the customer lets us do some about MIS, POS, or even software, government, etc., our success is greatly reduced. why? If we do other classes, we will be as easy as the Word template, will we still hold? What are we missing? Why is we confident when doing these software?
The problem of the problem is: Do you have a sustainable framework. If you have a Semi-Application that is basically met, you will not encounter those problems.
If you have repeatedly defeated and repeatedly defeated and repeatedly defeated, you will ask yourself: Do you have a sustainable development framework?
9. Misunderstanding of process modes;
Any process model has its advantages and disadvantages. We cannot negate the advantages of the waterfall model, and we cannot deny the shortcomings. We cannot negate the advantages of the evolution model, and it cannot deny its shortcomings, and other models are the same. Many people recommend RUP, XP and other process modes, but the premise is that we must know that such models are evolution models, there are many advantages, and they are not avoided.
For example, we need to do a need for a demand, and when it is difficult to change within a period of time, such as: a data structure class library, a communication underlying library, etc., this time, using the waterfall model may get better. effect. why? First, any drop of the evolution model is the starting point of the next drop, which helps users better grasp the system, better understanding, but this model is not suitable for very clear demand, If the demand is very clear, this drop can only produce redundant documents, which is more likely to produce a lot of transition, which is obviously a waste. Some people, simply use the evolution model as a waterfall model, pay attention to the step, this practice is more problematic!
If you need a system in place (that is, it is very clear, the demand is very small), and the evolution has become a waterfall. At this time, the evolution is nothing more than a few detours.
The correct understanding of the process model is the premise of the correct use of process modes.
10. Misunderstanding of testing; we should pay attention to testing, but excessive attention will have serious problems. The most important thing for testing is to discover problems. It is no longer problems in the software submitted to customers. From this point of view, test is important, but we can't test because of testing, many problems are not able to solve them through testing. .
When the problem is found, it is right, just like a dead sheep, not late. But we need more attention for the source of the problem. We need to pay more attention to the review of demand analysis, for the review, for the review of the code. Eliminate the problem in the cradle, the total ratio is easy to fight the problem.
Testing software is important (whether cell testing or system testing), but this test is only a narrow test of testing. We must never ignore the test (demand review) for demand analysis, the design of the design test (design evaluation), such that the synthesis of these tests is the generalized understanding of the test in software engineering.
If you find that there are too many problems on the circles testing in the work, you really should consider whether the "test" on other links has been problematic. Sometimes, too much sheep is dying, and it is late.
Test is a narrow concept in software engineering, but we should work harder to understand.
11. Error understanding of document role;
Documents are useful during development, but the document is flooding. Some people say that the more documents in the development process, the better, I think this point is wrong. First we have to clarify why the development process will write documents, the most fundamental role of the document is to communicate! A project or product may require a long time, there may be a lot of links during the development process, which may encounter a lot of questions and a lot of solutions. At this time, we need a documentation, we need to have a record, We need to have a common voice. The document is just a gauge, which will open each branches of the branches in the development. If this is too tight, the big tree may develop very straight, but it is some malformations. If this quasi-rope is too small, the big tree may become a bush. How much is the documentation, it is impossible, and it is absolutely can't say, the better.
So how is this degree? I think there are several standards: 1. Document needs to explain the problem of solving problems rather than solving the theory; because the problem of solving the problem is done in document formation. 2, the document is complete, each document describes a problem, there is no need to put the contents of multiple documents in the inside of a document; Tools can be effectively managed); 4, don't let the document become cumbersome, if this is true, I think it is the need to consider writing these documents.
When we are in the document, we must understand why you want to write these (whether it is still for future presentation).
12. Carefully examine myth!
During the implementation of the actual software engineering, we often encounter a lot of myths. "Software myths have some characteristics make it deceptive ... Software myth is still believed by many people" (see "software engineering - practitioners Research Method "P.10), if we use the examined vision, rather than letting blindness, we may find more mystery.
I hope to work together with you to carefully examine myths in software engineering!
