Wen two capabilities and processes
content:
1. 1, the revelation of the egg
2, demand process
3, demand process and CMM
4, demand process and software lifecycle model
· 5, RUP and XP
· 6, conclusion
This article is the second article of this software engineering column on demand, the author will continue to spend some space to discuss some basic concepts in software engineering, in order to understand the demand process from the overall angle.
1, cooking egg revelation
There is a British to learn to cook the eggs, start, and he puts the eggs in boiling in the boiled water. He thought of various methods for this, and found a solution: a hole on the egg. But in the egg punching, another problem: the hole is small, the egg will also fell; the holes are large, and the egg will flow before it is coagulated. As a result, this British played a batch of eggs, respectively, each of the holes, and record the size of each egg aperture. Through this method, he found a most suitable size - avoiding both frying and ensuring that the egg white does not flow out. At this time, although the problem of cooking egg frying is solved, this British still doesn't know how long it can cook the egg. In order to solve this problem, he started to try to cook the results of different times and find the best time length. Finally, he finally found a method of cooking eggs in the four seas. This case is a ridiculous example for many Chinese. Because smart Chinese have long known that the eggs are placed in the water to one of them to the eggs.
From a small incident such as cooking eggs, the Chinese and British reflect two completely different thinking habits - Chinese people rely on his smart, but the British carefully puts every process into The simplest, then executive at class. (Management Software Development Road Hongqi)
Although smart Chinese have four inventions, but for modern management ideas, the Chinese have never appreciated the true meaning. No matter which kind of management method, the process capacity is especially important. Although the relevant personnel of the production of a product have thousands, the products produced have only one. This ability is not falling from the sky, which is obtained by developing an extremely detailed production process. After China's thinking of ISO, this ability is also increasing in the domestic manufacturing industry. However, in the software industry, software organizations with this process capacity is still less poor, most software organizations are still a personal heroism in the 1980s, and the development software is strongly powerful. The programmer can successfully complete the software, and the ability is poor. In most software organizations, a few people master the code, they are everything, if they leave the organization, the code in the hand is their capital, and the original organization will be severely blown.
The Chinese is keen on the results. The hotspots in 2001 were in CMM. It is now difficult to say that there is a certain bubble in CMM, but it is certain that CMM enters China Software Organization for the development of China's software industry. New era. China's software industry will gradually get rid of the original workshop development, enter the software industry era. The reason why the software industry does not have a software industry is that software products can enter large-scale production and reduce prices like the industrial revolution.
Unfortunately, software is different from industrial products. In the process of industrial production, one method of quality testing is to set quality inspection before the factory is factory factory, and the factory is passed through quality testing. This method is unable to apply to software. Later, quality testing gradually incorporated to the production process, monitoring product quality during the process. This approach has made a lot more than the previous method, but it needs to track the production process. The idea of this method is the essence of the quality assurance of the software process.
In the "Software Engineering" book, the author divides software engineering into three layers, the bottom is the software process, the last layer is a software method, the highest layer is the Case tool. The software is full of various methodology, from demand to the final maintenance. It is impossible to apply all methods in your own software organization. So if you have a software engineering article, there is a problem to achieve modernization in tomorrow, disseminate the idea, start from zero. 2, demand process
The demand process is a very important part of the software process. Forty-tenth percent of the software project is "LeffingWell 1997) in the demand analysis stage. I have done a small survey by my side, and the results show that the successful project is inseparable from successful demand (an important logo is the user's support).
The demand process, also known as the demand engineering and demand phase, including demand development and demand management, and the specific workflow they involve is shown in the figure:
This process of demand analysis, we can call it demand projects, also known as the demand process and demand. The demand project includes demand development and demand management, and the specific workflow they involve is as indicated above.
3, demand process and CMM
The CMM Capability Maturity Model of Software Engineering Institution provides a well-known software process maturity benchmark. CMM has become a popular tool in many fields for assessing the maturity of an organization's software process. (For more detailed definitions and instructions, please see "CMM White Paper").
CMM and demand are related to the requirements of demand management in the level 2 (reassecale) and the requirements of demand management in the Level 3 (defined stage). It must be pointed out that CMM only specifies the key ability to be reached by mature software organizations, is a strategy for improving software processes, and does not do restrictions on specific methods. Therefore, there is no content involving demand development in CMM.
4, demand process and software lifecycle model
Any software starts from the most blurred concept: for a company design office process; design a business letter printing system and puts the market. This concept is unclear, but it is the prototype of the highest level of business needs. This concept will accompany a purpose, such as the purpose of a "bank deposit system" to improve the efficiency of work. This purpose will become the core idea of the system, the judgment standard for the success or failure of the system. In the 1999 government department, a large amount of OA system has learned a little in Lotus Notes, and IBM is more useful to say), but more common situations are that many government departments have not changed. Instead, a set of flows for automation processing is added. The original intention of improving work efficiency has led to a completely different result. Is this software successful?
Software products have entered the software life cycle from the moment of the concept. After experiencing demand, analysis, design, implementation, software will be used and entered the maintenance phase until it is finally demanding due to lack of maintenance costs. Such a process is called "Life Cycle Model).
Typical sever life cycle models include waterfall models, rapid prototyping models, iterative models. Waterfall Model is first proposed by ROYCE. This model is known for the cool waterfall. In this model, first determine the requirements, and accept the verification of the customer and the SQA team. Then determined the specification, and after the verification, enter the planning phase ... It can be seen that the crucial point in the waterfall model is that only the document has been prepared and obtained by the SQA team can enter the next stage. In this way, the waterfall model provides statute documents through mandatory requirements to ensure that every stage can complete the task. But in fact, it is often difficult to do, because the entire model is almost driven by documents, which is difficult to read and understand for non-professional users. Imagine, when you buy clothes, the salesperson presents you is a thick costume specification, what kind of feelings do you have. Although the waterfall model has a lot of good ideas, it can be used, but there is a natural defect in the process capability. Iterative model
The iterative model is the cycle model recommended by the RUP, and it is also the basis for our discussion in this series of articles. In RUP, iteration is defined as: iteration includes all of the development activities that generate product release (stable, executable product versions) and all other peripheral elements to use to use. Therefore, in a certain extent, development iteration is a complete process of completely passing all workflows: (at least) requirements workflow, analyzes design workflow, implement workflow, and test workflow. It is essentially similar to a small waterfall project. RUP believes that all stages (requirements and other) can be subdivided into iterations. Every iteration produces a product that can be released, this product is a subset of the final product. The idea of iteration is as shown above.
The biggest difference in iterations and waterfalls is in the exposure time of risk. "Any project will involve certain risks. If you can avoid the risk as soon as possible, your plan will naturally be more accurate. There are many risks until you have prepared an integrated system. No matter how the development team experience It is absolutely impossible to predict all risks. The difference between "" (RUP) is shown below:
Due to the characteristics of the waterfall model (the document is the main body), many issues will finally expose, in order to solve the risk of these problems is huge. "In an iterative lifecycle, you need to select new incremental content you want to develop in iteration according to the main risk list. Each iteration is completed, you generate a test-based executable, so you can verify that it has been reduced. Target risk. "(RUP)
The rapid prototype model is another model I like to adopt. The rapid prototype model is equivalent to a subset of the product. Note that it is functional. The shortcomings of the waterfall model are not intuitive, and the rapid prototypes solve this problem. In general, according to the needs of customers, the user's most urgent need is solved in a short period of time and completes a product that can be demo. This product is just a partial function (most important). Its most important purpose is to determine the true demand for the user. In my experience, this method is very effective, the original user without a whit concept is often in front of your prototype, and some views make you feel very surprised. After getting the user's needs, the prototype will be abandoned. Because the speed of prototype development is very fast, the design is hardly considered. If the prototype is retained, it will pay great consideration in subsequent development. As for retention prototype, there is also a kind of incremental model to do this, but this model is not accepted by everyone, not within our discussion.
There are unique ideas in the above model. In fact, there are very few standards in software organizations. Models and practical still have great differences.
The development of software life cycle models actually reflects the development of software engineering theory. At the earliest, the software life cycle is inadvertent, confusing. In order to control the development process of software, some people, the software development is strictly distinguished into a number of different stages, and there is a strict review in the stage. This is the cause of the waterfall model. The waterfall model embodies a hope for the software process: strict control to ensure quality. Unfortunately, reality is often cruel. The waterfall model does not reach this too high demand, because the process of software is often difficult to predict. Instead, other negative impacts, such as a large number of documents, cumbersome approvals. Therefore, people have begun to try to improve or alternative waterfall methods with other methods. For example, the process segmentation increases the predictability of the process. Discussion in this area we will continue 5, RUP and XP in the 5th section
RUP is a set of software development unified processes and method for Rational's development unified process, which has been developed by Rational. Remember the picture of our first chapter, that is, the core map of the RUP. RUP divides software development processes into 4 phases and 9 core workflows, complete the entire software lifecycle through a time iteration (Items). RUP can divide the software development process to very small units, each role (workers), and actifctions. Due to precision control, RUP can be competent in oversized project development. Although RUP defines a lot of tiny activities, it does not fall into the ocean of documents like traditional waterfall models because of the use of the Case tool. RUP can also be tried to smaller items by appropriate tailoring.
XP (EXTreme Programming), extreme programming. But it seems that there is no translation (listened to the right tissue in the computer area). It is proposed by the Kent Beck master. After the pain of traditional software development, the master hopes to find an excellent software development method. Master has summarized a lot of software success and failure, and proposed four elements of improved software development methods: communication, simplicity, feedback (feedback), courage. This forms an XP core value. After years of development, XP has developed many ways to support software development in all aspects of software development.
The RUP method of a large number of rules is known as the Heavyweight method, and the method of using only a small amount of rules like XP is called a method of lightweight (actually, now there is now one The tendency is called this method as the Agile method). Recently, some articles have also been discussing two methods. For example: XP rise, RUP is not suitable for China's national conditions. I think this is the same as if you discuss C and Java who used to discuss anything. The method has two sides, only the most suitable method, there is no best way. I also felt in practice, and the theory of foreign countries can't be moved in China. After all, the Chinese human environment and abroad are too big. However, RUP is not suitable, I think XP may not be suitable. If someone moves the RUP's set of things, causing the result of the final project failure. This kind of behavior is tantamount to the boat.
In my opinion, RUP is like an encyclopedia of software engineering ideas and methods. Among them, you can see the argument of the subsidiaries, you can understand the entire evolution process of software engineering. RUP is worthwhile to have a lot of time to study. A martial arts masters entered the Tibetan Classic Pavilion of Shaolin Temple, you can think about it, is it a scene. XP, which emphasizes the team's full exchange, maximizing people's creativity. It does not set a large number of rules to limit people's actions (the necessary specifications must be observed), and everyone in the development team can freedom, after all, software is creative labor (this sounds like It is a communist implementation of general). At least, domestic companies should learn a rule of XP: only work 40 hours a week. In comparison, RUP is more suitable for large enterprises, big projects, because large teams often need legal system; XP is suitable for small teams, comparing the creativity of small teams. But in practice, there is also an exception. For example, the first item of the XP method is a large project called C3 in Chrysler. In reality, RUP and XP apply to China's software companies have certain difficulties. Have some letters to ask me, RUP is really suitable for Chinese companies? I will tell them directly that it is not suitable. It is difficult to evaluate its excellent and inferiority for RUP. The key is that it is cut later. I have seen an article, which is to discuss how to cut RUP to the XP idea. So the use of RUP is very careful. A high-hit blacksmith can use a hammer to play a good weapon. If it is an ordinary person, it will go to the feet.
Increasing the internal force value of the company is not a one or two days, which requires long-term investment and ignorant efforts. The introduction of the big knife is not a complete set of processes, but it is only the truth that the hard medicine is hurt, everyone should also understand. Many young and well-established software professionals want to introduce advanced development philosophy in their own company, but when they are real implementation, they often have to have a blood flow, and there is also the cause of this. I am very admired to them.
6, conclusion
Although the name of the chapter is a demand process, it spent some space to discuss the concept of software engineering. The main purpose is to understand the demand process from the overall angle, not to treat the demand process, otherwise it is inevitable to see the wood.
