Text seven details demand period (below)
content:
· Think about 1. "The relationship between" and other stages ".
· 2, architecture
· 3, mode
· 4, simple design
· 5, how to unify
· 6, test
· 7, decomposition
· 8. How do customers participate?
· 9, small knot
Different from the business modeling period, I no longer spend on how to discuss the demand, because the practice, attention and business modeling period don't have much difference. On the complete process, learning like RUP, XP can learn more than what I will say. Therefore, I will focus on some confusion in my actual work, and some thinking.
1. Think about the relationship between "and other stages".
The end of the last end we simply discuss the relationship between the details and other stages. For the various stages of the software process, the difference is only the focus of focus. In the business modeling phase, we focus on the overall needs of the system; in the details of the details, we focus more on the details of the demand. Other phases are the same, the architecture phase, which is of course how to design a suitable architecture; to the design phase, the attention is transferred to how to design.
Of course, the focus is different, resulting in the same skills and tools required by each stage. The business modeling phase requires you to have a whole grasp, you can use a simple model, basic user material and other tools. The details of the details require you to fully explore the needs and conduct good communication. Accordingly, there will be different needs in the architecture, analysis, design, etc.
The essence of each stage is the difference in attention, which is the same for most software development. Regardless of the process you use is traditional or iterative.
2, architecture
Martin Fowler is written in his ISA:
I'm using architecture to mean the important design decisions, the ones that shape most aspects of a software system. These are often the harder decisions to change later on in the project (although often not as hard as people think). As a result ................. ..
The architecture is not mysterious, nothing more than a decision, but this decision is especially important for software. Software developers may have no active architectural design, but his behavior has been subtracted; and some people are always talking about architectures, but does not understand the meaning of this word.
The Spring Festival is coming, and the students must go home. How to choose a transportation of home is an important decision. The distance from the distance, the price of different transportation is explicit, it is easy to know. And the experience also tells you that the train ticket is cheap, but it is more tense, the time spends longer, the whole process is not comfortable; the plane ticket is more expensive, but it is easy to buy, the time is small, the whole process is very comfortable. At this time you have to make the right decisions, choose a correct architecture for home. What are the factors you may consider? Some possible factors are listed below:
· The degree of crowding, everyone knows the situation during the Spring Festival;
· The difficulty of purchasing tickets, the train ticket needs to be booked very early;
· Is there an additional channel, such as you can buy a student ticket for aircraft; · Economic strength
Based on these factors, as well as these factors, you can estimate one or more possible architectural programs yourself. And this architecture selection directly affects the behavior after you and affects the result of behavior.
What is the difference between development software and buy a ticket? The same should take into account the cost, result, time. Different are just complicated: professional skills are required, there are many uncertain factors.
So what is the problem of architecture here? What is the relationship between demand? In the above example, you can see what the architecture is determined? It is a factor. What is the essence of factors? It is a need. Factors are demand. Therefore, the demand determines the architecture. In the previous article, I talked about that the architecture must be set before the details are required. Of course, the architecture at this time may be just a sketch. why? Because we have made business modeling, there is a certain understanding of the project, and it is also clear that the needs of users have a certain feature, cost, scope, time, etc. (if you still don't understand this, please return to business) The mode of mode of modeling is not over yet. At this time, the factors of the decision architecture have been formed, and the architecture can be designed.
Demand can determine the architecture, and the architecture can also affect demand. The most obvious example is the design of the user interface. Although the user interface is mainly from demand, different architectures will also have an impact on the user interface, such as a browser-based client, and the interface that can be provided based on the Windows interface client is different.
In XP, this architecture design is called Architecture Spike. Why is it called Spike? That is to say, you need to study, solve some major problems, but you don't provide a complete solution. For example, at the beginning of the project, if you don't know about the new server and operating system, you will definitely take time to understand, try, go to test; if you don't understand the database, you will definitely try to use it. This behavior is Spike. So, the design of the architecture is just a preliminary design, not a perfect, styled design. This should be aware of this.
The selection of architecture is very related to the experience and ability of developers. In general, it requires developers with relevant experience. Providing architectural manufacturers, such as cattle, how to choose, and a study. For example, the platform of the data warehouse is a lot of varieties; the choice of Web Server is also a five-flowers; the operating system is the same. These are also closely related to the architecture.
3, mode
The martial arts have a moving, playing chess. Whether it is a move, or a chess, it is a specific solution for a certain problem. In the field of software development, this solution is called mode.
"Every pattern describes a problem that has been repeated around us, as well as the core of the solution, so that you can use the scheme again and not to do repetitive labor" [AIS, 77]
This sentence is derived from the nasal ancestor - Christopher Alexander. In the field of software development, the most worth mentioning work is the "design mode" written by GOF. In this book, the authors describe 23 design patterns, which can be said that these patterns have laid the foundation for object-oriented design. Another work worth reading is the "analysis mode" in Martin Fowler.
In software design, we encounter a variety of questions, we may lack experience, or have limited capacity. This is very normal. But the reality is that the code we produce is not clear enough due to design defects, it is easy to make mistakes, it is difficult to expand. I believe that as long as it is a developed software, I have encountered this problem. So, we hope to see how other people are handling this problem. The "other people" here may be a technical expert, or some people who have experienced the same kind, they have the ability to encounter problems, and have experience. The solution they propose is often very mature and can solve the problems you have currently encountered, and you can solve the problem that you have not yet encountered. This is very great for you. So, we talk about what is derived from the model. Note that the mode is a solution for a certain class. The problem here is a demand. For example, customers want to achieve different tax rate calculations in software, then we naturally think of Strategy mode; when the customer's product has a very complex unit exchange mechanism, we can naturally think of it. Quantity mode. Using mode, we can quickly grasp the needs of the needs. On the other hand, mode often tells us more aspects more than current problems, because models are all experienced precipitation. As mentioned above, it can solve the problem you have not encountered. Therefore, we can also find deeper demand from the model.
Another point is also very important, although it is not the relationship between it. Mode often has a pattern name. This forms a communication language. For example, when we are in the chess, just say "the horse behind the gun", everyone knows what this means, absolutely does not need to explain the way each step. The same is true for software development. I smiled with my companion, said: "Factory Method." Two people can understand what this means, because this is a common language, which represents the various types of relationships and code implementations behind behind. . This is very important in software development. Of course, this has a premise that everyone has a transparent understanding.
4, simple design
The pattern is a ring of the design, so before we discussed the relationship between the design and demand. We still discuss this topic in this section. But the focus is different. There is a principle in XP: KISS. Not KISS. It is an abbreviation for Keep IT Simple and Stupid. In addition to XP, other agile methods are advocated simply designed, objected to overchaif. That is to say, designed the current software for the current needs.
Many software personnel are perfect, they like the perfect design, then provide this design to the user. This kind of thought is the beginning of excessive design. Unnecessary functions areted to invest in customers. When we do demand, we often find that developers will sell some new features to customers, or when designing, excessive consideration changes in the future.
Therefore, simple design means designing the current needs of the current customer, do not think too much about the functionality currently mentioned.
5, how to unify
Careful readers see that this may be suspected. While encouraging the use, the most perfect solution is designed; on the other hand, it emphasizes simple. It seems to be self-contradictory. Nice this is where contradictions, but there is also a consistent place. Therefore, we need to trade between using the simple model and the simplicity of maintaining the design.
Once, we saw a pattern about permission settings, we think this model is very good, it provides permission control similar to the UNIX operating system, can increase group, user, and can set permissions at the file level . If we got treasure, I think this is a very useful model. So, we spent some time will be implemented and intended to be applied to new software. In practice, we have found that there is no such powerful feature that may only be password control, or simple user management. Such complex features have no meaning to them. Perfect model has been cold in reality.
In fact, users don't need this feature at present, and don't need this feature in the future. The user's computer is raising, and we estimate that more than a year or two, users may need this feature to manage his increasingly huge employees. However, this feature is complicated to the user, so they are not willing to accept this "valuable" function.
Finally, we think of a solution, we define a universal interface for this feature. With this interface, you can achieve complex features, or you can achieve simple features. In short, as long as you have a way to implement an interface. There are many ways to interface, but in the current simple implementation, it may be just a return statement and there is no much implementation. Correspondingly, the user only needs to use a simple method, such as adduser (), updatePasswd (), and the like. The interface has also been simplified.
In this way, we can replace the permissions module when users need, do not affect other applications. Of course, there are a lot of details to pay attention. After completion, we also discovered another by-products: the entire permissions control module is high polymerization, low coupling.
Mode, it is like the design drawings of the nut, which specifies the technical specifications of the nut, but there is no specific size. For different needs, we can design different sizes of nuts for use. The drawings are only one need, and it is not necessary to draw a drawing for each size of the nut.
So, a model that has experienced practical tests is often powerful. But it can have a variety of different implementations. Which legal stipulates that you have to fully implement a mode. In actual use, you need to weigh the cost and benefits of the model use. You will find that in many cases, you still have a model, but just a framework, or part of the mode, but this is enough. When demand changes, or when new demand occurs, you can easily add bricks on the original frame. Everything is so natural. For example, in a software stored software, there is a transportation selection algorithm, and the current transportation route is one, but it is very likely to increase the new way. At this time, you decide to use the Strategy mode. But you just have a simple framework, only one specific subclass, to achieve the current algorithm. When the new transportation path appears, you need to add an algorithm, you can add a subclass, as long as the interface is the same, the change does not affect the other part of the system.
6, test
Test is very important and is the key to software success or failure. But the current domestic pair is not concerned, or pretending to pay attention. This will not guarantee the quality of the software. There are a lot of tests, and we are talking about it here is that the requirements are closely related to the Acceptance Test (about this word, there may be different translations).
Surely you are not going to assume you're getting what you need. Prove that it works! Acceptance tests allow the customer to know when the system works, and tell the programmers what needs to be done. The above excerpt "XPInstalled . There are two effects on reception test: first, let customers understand what the system can do, and then let the programmer understand what to make the system.
There is a test method to keep the test to finalize, let customers discover the error. Don't do this. The original cost can be corrected for 1 yuan, and it may take 1000 yuan to solve this time. This is the magnification effect of software development. Because many of the work has been established based on this error, developers have also no image for this error.
There is a very important value in XP called feedback. Kent Beck has a very good sentence in Extreme Programming Explained: "Optimism is a professional disease, feedback is its prescription." From the needs of the needs, the system is delivered to the customer, and the customer comments. This is a feedback process. The less time spent on the feedback process. Acceptance is an effective means to address customer feedback. Customers write repeatable test scripts, the software developed by developers should experience this test script. This feedback speed is very high and can effectively solve the problem of feedback.
Therefore, when the customer is required to implement demand, it is also obligated to provide relevant receiving tests:
IF It's Worth Having The Program Build It, It's Worth Knowing That They Got It Right.
A valuable function must be testable, if not, then this function is either worthless or not, it is not described.
Note that this test must be repeatable. This is because of the variability of demand. Demand is constantly changing, which means that the code is constantly changing. Therefore, the code that has been proven to receive testing has also need to prove again. This requires testing to be repeated.
A large number of tests, even duplicate tests lead to a new problem: a lot of time is tested by manual testing. Therefore, the variable demand puts forward a new requirement for the test: automated test. Only automated testing can only complete such a large number of testing. At present, the best automation test tool should be the XUnit series. Regarding this issue, you can refer to the relevant information, which we don't discuss in-depth discussion.
One form of receiving test is the description of the natural language and takes a group of test data. One thing to emphasize is that this test data must include input and output. This can be compared. If only input is not output. Test is likely to be white. Therefore, calculating this output is manually calculated, it is also necessary.
In addition to receiving testing, there is a very important concept that unit tests. However, the relationship between unit testing and design is relatively large, and there is no excessive relationship with demand. We just click here. If you are interested, you can refer to the relevant information.
7, decomposition
For demand, the most skills that need to be used may be decomposed skills. It can be said that the most important thinking of software science is the idea of "divided into force". Not? Object-oriented is an idea of decomposition. Class, components, packages, this hierarchical structure is not embarrassing "Separate"? Of course, I may confuse the bags and components here. But my main purpose is to point out that this decomposition method is ubiquitous in software development. The same is true for demand. Our earliest business model is to get a profile of a system. Then I went to the details of the details, we will put this picture, down, until we have a grasp. How to take 100 bricks? If a piece of tired, it is easy to fall. A more good practice is to first 10 pieces of packaging, so that 100 bricks become 10 bricks, and then tired of them. Object-oriented is actually doing this, of course, object-oriented achievements is much more difficult than tired.
Let's take a look at how XP handles decomposition. The biggest cycle in XP is called release (Release), a publishing requires a month or month, generally no more than 6 months. The final version of the release, you need to provide a publishing version that can run software. Then, XP also defines the secondary cycle, called iteration, once it iterations require a week or weeks. Every iteration is a "Psend Release" (preted release ", that is, iterative finals must also provide a software that can work, this software can be released at any time. In order to define things to handle in an iteration, XP also defines the material (Story), a material represents a feature that customers want in software (Feature), a material is small, it only needs to spend A developer a few days or weeks. The material is already small, but it also needs to be subdivided to the task (Task), and a task only takes 1 to 4 days of workload. This is not the smallest unit, XP also divides the task to test (Test), but this has arrived at a personal level.
We see that XP defines a 5-level unit from the customer to every developer and accurate time to days, hours. So I sometimes listen to people saying that XP seems to be un strold for developers. Wrong, XP can be said to be the most stringent method required, this classification method can be seen. What is the benefit of this classification?
First of all, let's see the release version, the shortest time released is one month, that is, the most frequently delivered a software to the customer a month. In this way, the feedback is guaranteed to be largely carried out. Avoiding the last customer discovery in the traditional development method is too late.
Look at iteration, iterative is called a counterfeit version, that is, because its nature of its output is the same. It is a product that can be delivered, but iterate is relatively small, there is no need to deliver it to the customer. We know that integration is a big problem in traditional software development. Integration will inevitably have problems, but no one knows where there is a problem. So, XP avoids this problem through uninterrupted integration.
However, the cycle of iteration is so short, what can you do? This is the cause of the material. The material is proposed by the customer, and the customer decides the priority, which is determined which release and iteration of the client. At the same time, as we mentioned above, the customer needs to make a reception test for material.
A material period is a few days or a few weeks, and the time iterate will be a few weeks. This shows that the material is too large, and the unit is too large. So the material is once again decomposed into tasks. Every task requires a developer to claim, sign. In the process of breaking down, we can find that there are some tasks to share multiple materials, this concept and the concept of use in the use case are consistent. Developers will estimate their tasks. Thereby, a total time of an iterative cycle is obtained. The estimate of this time is based on past experience, so this estimate tends to be more accurate as the project progresses. Let's talk about XP here, don't ask everyone to paint gourd, you can't do that. Because the various practices of XP are all integrated, only all practices can reflect their power. We don't do this. But we can borrow it. Decomposition, classify, sort, estimate. This method of analyzing problems is also our dedication. There are some attention here:
· The earliest decomposition basis is often the time for customers. For example, customer wants what to see within 3 months. After the customer and development is discounted, it decides to develop two releases. This decision allows the developer to provide reference, but the decision is in the customer;
· Propose of the material, the material's priority, the arrangement of the material, these are the rights of customers. Customers also have the right to cancel, increase, modify the material, or change its priority;
· How much software can be seen? Customers can also cancel current projects, and previous investments will also have some software output;
· The estimate of development time is the power of developers, and any other time schedule that is strongly added to developers is wrong;
· The choice of mission is also due to the principle of voluntary developers;
• If the total time and iteration of the developer estimate is in stock, it is absolutely unsalarmed to sacrifice the additional time exchange iteration of the development personnel to complete within a limited time. This approach is tantamount to drinking thirst. A better approach is to remove some tasks.
8. How can customers participate?
This is a pure supplementary problem. Once, a reader wrote to ask me that China's customer quality is relatively low, and the computer does not understand the computer, XP emphasizes the on-site customer reality.
XP requires developers to support it in the development of software. It is very difficult to do this. It is difficult to do this. I have encountered this problem, know the problem of problems. I think this problem can be divided into two aspects.
One is a customized software. For this project, you need to solve the problem of users' participation, and often the client's older is willing to invest in funds, but it is not willing to put support. I have also seen the client side specialize in a situation where you are going to deal with demand. In this case, if you have no ability to overcome it, then this item is definitely failed. Even if the project is finally successful, I applied for awards such as "major research", you are very clear, this is just a surface skill. There are a lot of reasons for this problem, you need to analyze them, list the deepest reasons, and to ensure that these reasons listed are not interacting. Then try again to solve it. In general, if the customer is really willing to implement this software, things are not unresolved.
The other is productive software. We can divide the customers of this software into three categories: market staff, field experts, end users. Market people tend to have initial understandings for software, but this kind of understanding is often not deep enough. Therefore, when developing product chemical software, it is necessary to equip special market staff, and their needs for customers is the most demand for the first source of demand. Since your boss wants to develop this software, it means that the future market of the software is expected, and the requirements of market personnel join should be satisfied. Secondly, it is a domain expert. Nowadays, there are now field experts, and their role is not small, and they are equally familiar with demand compared to market staff, because they are a senior user, and they are familiar with theory, they can Software has developed great effort. Finally, the end users, the participation of the two categories of people in front is not enough, and if the end user does not recognize the software, it is still useless. Therefore, it is very important to ask the market staff to find a possible target customer, trial software, and comments. The Beta test we often say is to do. 9, conclusion
The earliest idea of this article is from a credit system (in the view of the article, this system is a failure case). In addition, there have been some experience of some previous projects, as well as some of your friends. Finally, it has become this article.
This series of articles have a long span. During this period, my thoughts have also experienced a big change, so there is a situation in which some of them have been done in writing. Although this article named "Practice of Demand", the various ideas and methods mentioned have theoretical basis. Of course, I also have a lot of information. And my personal ability is extremely limited, so sometimes I have a weak force. In this case, there will be a lot of errors. I also hope to get the readers' understanding and correct.
In the process of writing, there are also a lot of enthusiastic people writing letters, which have become good friends. I have wanted to organize the problem inside, but because of negligence, some of them have been found. I hope I can have the opportunity to do this.
Reference:
Karl Wieger: "Software Requirements"
Scott W. Ambler: Agilemodeling: http://www.agilemodeling.com
Scott W. Ambler: The Object Primer 2nd Edition
Jacobson, I., Booch, G., And Rumbaugh, J. (1999). The Unified Software Developments Process
GOF: "Design Patterns: Elements of Reusable Object Oriented Software"
Eric Gamma, Kent Beck: junit: http://www.junit.org
KENT BECK, MARTIN FOWLER: "Planning Extreme Programming"
About the Author:
Lin Xing, Chen Yun Software Studio Project Management Group Senior Project Manager, many years of project implementation experience. Chen Xun Software Studio is committed to the application of advanced software ideas, software technology applications, main research directions lies in software process ideas, Linux cluster technology, OO technology and software plant models. You can contact him by email IAMLINX@21cn.com.
"cited from
IBM DW China
