The system analyst gave me a headache

Keywords: Headache insomnia depressing irritability ui gui interface human-computer interaction presentation layer business logic model view control MVC publish subscription observer listener publisher SA com sink callback facade design mode JSP servlet JavaBean ejb cgi FastCGI

Coming to Shanghai in January, I learned what to do (Strategy), how to deploy it, and how to use it (tactics). All aspects of Product Channel promotion prices have started to work (of course, focuses on products and channels ).

Side effects: Headache.

Conclusion:

1. The requirement interface must be straight up and down.
That is, first, to define the system's external characteristics and system boundaries. The interface prototype and use case are followed by the use case text. Use Cases must have detailed text descriptions. Steps:
1. List of border definitions (What are there, nothing)
2. List of participants and their targets
3. Introduction to Use Cases
4. Success Stories
5. Failure
6. Handle failures
7. UI prototype (first sketch, so that the UI is designed before beta)

2. The requirement interface must be led by PM and led by system analysts for preliminary technical pre-development.
The requirement interface must be implemented by PM. System analysts can provide technical assistance at most to determine whether or not the technology can be implemented. If not, pre-research may be required. Sa cannot determine the demand and interface for too many reasons. This is the division of labor and balance between product managers and technical managers. The architecture of the system analyst must meet the requirements and interface, and should be directly responsible to the product manager.

3. The design of the system analyst must be from bottom up.
For desktop software, it is best for system analysts to design all the modules and develop all the exchange interfaces, such as network communication protocols, database design, and important data structures, the communication interface between the presentation layer and the logic layer. Do not let the coding staff determine what to do or how to do it, as long as a defined module is implemented.

4. The presentation layer, logic layer, and network layer must be included in the design list of the system analyst.
The communication interfaces at each layer must be clearly designed, and the modules at each layer must be well designed.
The biggest problem is to design the communication interfaces between the presentation layer and the logic layer to the coding staff.
The second problem is that roles in the presentation layer and logic layer are not clearly divided. For example, whether data update is a query by the presentation layer subject or an active notification by the logic layer, the status of the data is a logical layer record or a presentation layer record. If all the data needs to be recorded, how can we separate the records?
This requires the system analyst to have enough courage.
I personally think that system analysts do not have the ability, but do not give full play to their own thinking and do not follow their own ideas.

5. The problem is complicated.
If you do not need to layer it, you must score it.
You do not need any design patterns.
If there is no need for division of labor and cooperation, we must establish a democratic division of labor, such as the network layer and interface layer. In fact, the core is the communication mechanism of each layer and the external coupling relationship of each module, analysts can do these two things well, and they only need to do these two things. However, I have seen too many developers who have pushed such things to developers who do not know what to do and how to do it. So I discuss the select NiO iocp every day. What is this ??? A communication interface is designed. What model is used in it? Is it so complicated?

6. Principles: Ask the system analyst not to let the developers do what they don't understand.
This kind of things is hard to understand, especially those that do not understand the business logic. You must make it clear when you need to meet your requirements, A definite solution should be provided during design. This principle cannot be violated !!! PDCA, the plan is not just about what XX is doing, but about how to negotiate (or directly tell him), and then proceed with confidence. Believe me, if you don't know how to do it, don't do it first, let alone tell others to do it. Make sure the solution (that is, there is a design solution) (anyone can do this solution), and then do it again.
This is the guarantee of execution.
Employees do not like to get an ambiguous task.

7. System Analyst, salary?
More than the CEO!

8. Common Problems of desktop software: communication problems between GUI and logic layer.
In theory, the mvc pme, the com VCL swing, and the most practical event processing mechanism that can be designed by myself have been thoroughly implemented? Let's not talk about rpc rmi corba.
I know how to use the application to master revision. What stage have you reached?

IX. Transition Design
Simple is beautiful, not too complicated. Is template generics really so useful? Is it suitable for a team less than a month of work? Simple, not only in code, but also in operation. Operations are not only code, but also team and personnel.
Everything is the result of balancing efficiency.
Can you think systematically? Is there a systematic knowledge structure? Is there a methodology? Are there any identification methods? Is there a dialectical methodology?

I wrote this article to myself. Please pay for unexpected events!