Software demand is a process of developers and user interactions, and no input will lead to failure of the project. Of course, because users are not professional, developers have the right to tell users to treat the needs of the project. All the most successful projects have an important feature: users are very support.
The standard of judgeting a software project is to see if it solves the user's problem, and the user's problem is to reflect the needs of users, and demand is also a success standard for the project. Any inadvertent demand phase may lead to a lot of rework in the software implementation stage, and the demand is not cautious, because you can be careful, because many demand is hidden, even users don't know their needs. At this time, there is a scientific approach to help software organizations implement a demand process.
Master said: "There is no constant demand, the software in the world has changed more than 3 times, the only owner of the software that only changed twice, it is dead, and die on the way to revise the demand."
Demand is unstable, is there any stable thing in the demand? Yes, it is an object. The world is consisting of objects, while the objects are lasting, such as animals, plants have a considerable time. Although objects are also changing, animals, plants are constantly evolving. But the object exists in a quite long period, and the existence time of animals and plants will certainly be longer than any company. The essence of object-oriented development methods analyzes the stable object of enterprises from the instability demand of enterprises, and organizes demand based on corporate objects, and architecture systems. The system thus derived is much more stable than the traditional system, because once the company's mode changes, it is only necessary to reorganize the stable corporate object. This development method is called OOAD (Object Orient Analysis & Design object-oriented analysis and design), and the analyzed corporate object is called Common Business Object. What is the demand? Working purposes in the RUP: 1 / Customers and other related people * are reached and consistent in the work content of the system. 2 / Make system developers more clearly understand system needs. 3 / Define the system boundary (limited). 4 / Foundage for the technical content of the plan iteration. 5 / Provide the basis for the cost and time required to estimate the development system. 6 / Define the user interface of the system, focusing on the needs and objectives of the user. * Zhou: All people are all people who have affected by the project. Such as customer (or customer representative) users (or user representative), investor, shareholder, production manager, buyer, designer, tester, document writing staff, etc.
Many people think that the purpose of demand management is to control the demand process, this is not wrong, but in the thoughts of RUP, more important thinking is iterative *. The purpose of iteration is to develop, in order to evolve, in order to improve. So the software life cycle in RUP is divided into multiple iterative cycles (the software life cycle will be discussed below). * Iteration: Iteration includes all other peripheral elements that generate product issuance (stable, executable product versions) and all other peripheral elements 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.
Is there a need to use a rapid prototype development method and prototype to develop to what level depends on the specific project, many times, use some informal ways to generate prototypes: If you want to develop a web system, let your beauty do a few The page gives the user, if you make a C / S system, do an interface to the user, it is enough to use it, even you can draw a picture of your future software on the blackboard. User is mostly friendly, don't think about the problem. There are many articles in demand for the demand for software demand, which is not the same for the criteria of demand, but they are the same, they are to ensure the smooth progress of the project. Here I summarize some more general standards, it may not be perfect, but as long as you can guarantee these points, your project is not easy: clear (CLEAR), complete (consistent), test (TESTABLE), there are other concepts, such as tracking, modifications, and more.
The revelation of the egg is a British to cook the egg, start, and he will fry when it is boiled 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.
Typical sever life cycle models include waterfall models, rapid prototyping models, iterative models.
Waterfall model (Waterfall Model)
First, it is 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 iterative models is the cycle model recommended by RUP, and it is also the basis for our discussions in this series. 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 impossible to predict all the risks. The difference between the two is as shown below: Due to the characteristics of the waterfall model (the document is the main body), many problems will finally expose, in order to solve the risk of these problems. It 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) Rapid prototype model
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. This discussion of this aspect We will continue RUP and XP RUP in Section 5. 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.
