There is no head without tail - Project development notes: First develop UI layers or first develop businesRules layers !! ??

zhaozj2021-02-16  62

Title: No head, no tail - Project development note: First develop UI layers or first develop businessRules layers !! ??

Keywords: distributed development C # project division of labor Delphi and C # mixed development, development process, sub-module development, hierarchical development, RUP implementation process

November 26: I heard that my friends bought a house at noon, I really want to be happy.

The last note is the following comments: (The following discussion is built in a business system, which is the kind of J) with a database connection.

I think the UI should be put behind the businessrules. After all, the UI is the most likely and adjustable, and attention should be concentrated on BusinessRules. Of course, you can do Demo first, let customers deepen the depth of demand for demand through Demo.

The implementation process of RUP is the most related process with the Coding process. But I checked the information on the Internet, and it seems that it doesn't have to develop by using a layered development method. What should you be a UI layer? Do you first be a businesRules layer?

In fact, there are some discussions on this issue. That is to say, what is the relationship between the development between the hierarchies after we have settled in a layered method? Is it possible for several levels developed in parallel? For this is a problem that there is no answer. My choice is to develop UI first, then develop the businesRules layer, this choice I think I am made according to the reasons described below?

1. The opportunity of the customer's demand (can refer to "without the end without tail - project development notes: Changes in development methods" J)

2. Problems corresponding to our needs

Our needs will be our testers, and the leadership give us a must be fully letting them do things, can't let them be idle. (Briefly, after they write the needs, they can start writing test plans. Their test plan has written our project to test them. L)

3. My own problem

The development of the client is Delphi, which is very unfamiliar. And I need time to prepare the framework of the Server side and the generation of code. So this allocation time is advantageous to development. First fully utilize Delphi's cattle developing clients.

4. Problems with our development team

The development team is the first time to use this Coding method. If we first develop BusinessRules, then our development process must be clearly defined in the beginning. There is also what input and output, and the development process may we develop a debug tool for DEBUG for development when developing. It is better to make an interface directly and then do Rules. This can have a performance of your run, which is very intuitive, you can know that the program is trying to work according to the developer.

5. One reason

The following cranky thinks, it is also a reason to develop the UI layer first, and then develop the businesRules layer.

First of all, I want to summarize the way we have been used to the development method from a more strange angle: the first step is to summarize the user's needs (A refining process); the second step produces an object-oriented design according to the user's needs (B Refining process), the third step is generated according to the object-oriented design generation of the relational database (C refining process). The above step is to prepare before starting Coding process. If these three processes above are complete, then we must program the following procedures:

1. Establish a public object;

2, establish a relational database, and program the connection to the relational database (the legendary doj);

3. Establish a program (the legendary BOJ) of the object (the legendary BOJ); 4. Establish a corresponding interface program (the legendary page objectj);

5. Establish relationship database of various tables and object design;

6. Establish a connection between the user's interface program and the individual objects;

This process should be the process of Coding personnel. These five steps are 123456, or 432145, or .......... This is actually possible in different projects.

Seeing these processes described above, I have a little bit a bit, I suddenly don't understand how my previous software is developing, when is these steps, or I haven't taken it? A few points seem to be a little chaotic, you can really want to make an app is not possible (of course, some people can directly connect all tables in the relationship database from the user-oriented interface. We do not recommend this method Luo) . That may be friends: "Don't play this, I can develop these steps when I develop procedures." But I actually actually do it than I originally doing the project) without realizing the above situation. It is already confused to apply a few stuffs in one way. Why can we go to the development of the development. That is because we have experience and understand when it may have problems. Such a process is that from experienced differences can be developed.

If it is just from an empty angle, the above six processes should be a company, or a type of project is a fixed order relationship. But when you really develop projects, no one cares about what steps are now. The boss will not take you what steps you have developed. Just keep it asking where the project Milestone point? Then use your planned Milestone to you, check your stuff to get out in your defined time. Although this is conducive to the growth of a project, the quality of the project may not be guaranteed under the pressing of the time.

Then my first one you want to implement, you have to see from the head to the end, you can communicate in our project (the document is of course able to play this role, but the document writes not necessarily developed. Come out, customers like the stuff that can be implemented, if this stuff is exactly the same as the interface he wants to use, then it is better!)

Back to the above friend, I think there is a representative. That is, after all, the UI's adjustability and adjustment is the largest! ! This point of view says people I think about 90% of the business system will nod. Can you have anyone else to think about why you are like this! ?

Looking back to see the process of RUP, RUP's process is highly emphasized, but from my understanding, RUP's iterative process is to ensure the integrity of the process, it is the entire development process for iteration. There is no corresponding process of each fine process during the development process, it is independently iterated in this section because of the relationship between division of labor. (I saw a RUP on the other RUP of the upper level and the lower-level system, but it is not obvious.) If a development process is longer, the product developed is in every iteration. It will encounter the inclusiveness of the customer's dissatisfaction with the UI. If we have a way to develop the UI's development in the development process, we form a separate iterative process, then I think it can be solved for this problem.

Then the second aspect of your friends question questions is why the UI is adjustable and the possibility of adjustment. That is because the user can only see the interface. It is not that other no problems, but users cannot see so many questions in one time and make us escape the modifications to BO.

The customer in this project I am doing is very great. They have already defined basic ideas for our understanding of the software industry, instead of understanding his ideas, telling him what kind of way we may use to achieve. I want to have a new technology in the previous software industry, then we have to know what customers want, we want to improve our customers, make money to customers. However, it is basically a problem from our (non-professional, not directly profitable). But the times really already progress. Customers can know what the information system can bring to the user, they really start the brain wants questions ... this is development. From letting us help them design software to them, they can really ask themselves to design software. This thing itself is already progress, but this progress has not essentially changed our development method. That is to say, experience this factor with social attributes has not entered the theory of the development process. RUP did not tell us how much experience should be developed, there is no experience to develop. Of course, there is no way to tell us how to do it if the customer needs to use an app with all applications. J I think I don't know about RUP. I have seen some RUP books, but I always feel that it is not the same as the development model I imagined. It seems that the shortest process is that the five organs are completely incomplete three or four weeks. And at least from demand to design to development, it is a professional personnel. However, I have always had an idea to develop in the current development process must be guided by the user. That is to say, the user is a user, it is a thorough development of users. If new technologies can help us give our customers an iterative interface in the development process, as well as a little perfect for users in the iterative process, this is truly to consider problems for users.

In fact, I am a lot of roller, not to say that I have found a good solution. I just want to remind my friends to pay attention to the kind of idiot that the user will only change the demand. Instead, progress to the real thing that understands the computer is also proficient in business needs. Then we correspond to the change of the user's level. During the Coding process, I think we can have enabled the development method of the hierarchy through the framework technology. Then, the development method of the hierarchy must be guided by the user, be sure to let them know what you are doing now? The fastest speed will come to Dongdong to communicate with them. This process is of course almost impossible to now. But I still have to find this possible.

No, I think the hierarchical structure is the first step to develop in this direction (which is development, not changed), there is a hierarchical structure (also a hardware condition is mature), then the hierarchical development model must develop. . The layered development model is also only a change. The layered development model will increase the division of labor within the program developer, which will definitely integrate part of the UI developers with demand staff. Refining a good tool, it will be easily demand for programs that can be appropriate to see the needs of users. (In fact, I always want to directly put our interface layer directly to our company's needs, I hope they can help us directly from the part of the interface in the development process. So we can go I want to help them generate the connection part of the database [In fact, it is unbearable to ignore the steps that must be elapsed in several developments.] Let them only use the interface to generate a visual application. You can communicate directly with our customers, and you can directly get feedback directly. Then the true Coding personnel can do it is complex business logic. That is, iterations in one or several hierarchies.)

No, my thinking is a bit mess, I will write back, I will write back to the status of the code generated, as if some friends are more concerned about these issues.

转载请注明原文地址:https://www.9cbs.com/read-24203.html

New Post(0)