2013.6.2
Design capability is one of the main symbols of the level of technical staff. The technical staff of the project team have traveled through various stages and finally ushered in their own time. The general design of excellent systems and the general design of excellent modules are the display of the designer's own capabilities, which requires them to have enough vision, experience, and thinking. Project management plays a major role in the design phase:
1. Help the team members with insufficient design experience to prevent defects and keep the bottom line of design quality. 2. Give experienced experts with clear objectives, to further improve design quality 3. reduce rework risks
According to the five elements of the project, the design phase is divided into the following stages (images can be zoomed in to the webpage ):
1. Stakeholder Expectations-goalsIn the project process, divide the general settings and general settings. The main purpose of the detailed settings is to: divide the system into multiple functions and basic modules according to the architecture and requirements, define the interaction methods and interfaces of these modules. Overview: the module overview design Splits a module into multiple sub-modules and defines the interaction methods and interfaces between sub-modules. Details: Clear the internal logic, flowcharts, and even pseudocode of each sub-module to serve the subsequent encoding. Common stakeholders in the design phase: 1) lead/Product Manager: They mainly expect the stability and scalability of the product. Generally, a design is recognized by everyone, at least one of these two factors must be included. The stability of basic functions can attract the customer's favor, and scalability can reduce the workload for subsequent development, which will be expected by the supervisor and product manager. Stability is usually required in product requirements, and scalability is often a breakthrough for bright spots. 2) technical support personnel/customer service personnel: they expect that the system and module can be easily debugged for troubleshooting, that is, the maintainability of the design. 3) test team: the test team expects that the development should consider the Automated Testing Solution in the design phase to reduce the workload for testing and regression testing. 4) Project Manager/supervisor: public code can be extracted during the overall setup phase to reduce the risks and workload of the current version and help the subsequent projects.
2. Sand Table-ideas1) the premise that the design and the design of the slot can be well explained before the start is that the parties should be clear about the criteria for judging "good? If the expectation is exceeded, the client must first understand what the expectation is? Therefore, it is vital for new employees or team members with insufficient design experience to help them clarify "what kind of design is a good design, in this way, they can put their energy in the right direction. The best way to do this is to explain the typical good design and bad design in the current department or company before starting the design, in this way, we can get a consensus in the direction before departure. It should be noted that the significance of design education is often greater than that of a good design, because a good design requires accumulation and inspiration, and the design of the cake is often avoided, A well-designed design is not a high requirement.
2) robustness analysis is often necessary to perform robustness analysis on the entire system and key modules. When the system or key module encounters an exception, it may cause a huge impact to the customer, or even irreparable loss. The main method of robustness analysis is to list possible exception scenarios and how the system or module should handle them. For example, the user authentication module should at least consider the following abnormal scenarios: 1) how to ensure the authentication priority when the system memory is insufficient 2) when the process is suspended, how to check out and prevent authentication requests from being affected for a long time 3) How to quickly recover the process when the program crashes 4) how to ensure that the authenticated customer is successful when the device powers down or the program crashes, do not re-authenticate all. 3) Scalability Analysis is particularly important for business modules that may change frequently. A good way to achieve good scalability is to separate the Business Code from the logic code through "High Cohesion and low coupling. Good scalability can greatly reduce subsequent development costs and is very important for continuous projects. For example, if you do a packet capture protocol analysis software (for example, wireshake), its scalability mainly lies in 1) More protocols may need to be analyzed in the future. 2) in the future, there may be more presentation methods of package analysis results. It is very appropriate to make these two parts into plug-in loading. 4) maintainability analysis (automatic upgrade, etc) the Maintainability Design usually consists of two parts. A. When a system or module fails, is it easy to troubleshoot? This requires the system or module design to provide a convenient troubleshooting method, the user authentication mentioned above is used as an example: for example: log classification, we can divide the user authentication steps into 12 steps, and print a log for each step to facilitate problem tracking. Memory printing: input parameters in the background to print the current memory status of a specified user or all users.
B. When a system or module fails, check whether the repair cost and risks are controllable. After a fault is rectified, there are already many customers who are using problematic products. It is very important to update the product quickly and conveniently at this time. Whether it is convenient and fast depends on the maintainability of the system or module. For example, a product has an automatic upgrade function. The current fault is that the network traffic is updated, leading to invalid plug-in functions. At the same time, the main program has a strong validation of the plug-in, at this time, we can quickly update the new plug-in to the network.
5) The design of automated testing and analysis should be considered from the very beginning. A system or module can easily compile automated test cases for basic functions, which is very beneficial to quality. Taking protocol analysis software as an example, we can design the following automated methods: A. Compile a tool to generate a data packet for the specified protocol. B. The system can load data packets directly from the file for protocol analysis, and automatically checks whether it is consistent with the input expected results
6) before the design starts, the designer should introduce his or her ideas and solutions to the experts. The document of the solution selection is not complicated. It can be an email or a diagram, however, after doing this, we can avoid a lot of design rework. I have to say that at work, there are often some such feelings: "How do you want to do this ?" "This must have been redone" and so on, all of which are caused by the lack of basic ideas.
3. Plan Formulation
The review workload in the design phase is very large. If the project team requires a lot of external experts to check the workload at this time, it is necessary to negotiate with these experts for a time and develop a unified review plan, to prevent delays in review, resulting in incomplete start of work in the next phase.
4. Risk management
1) I have to say that there are some colleagues who like to abuse or over-design patterns. This is an uncomplicated module, so I need to put on several design patterns, the code can be inherited with a lot of polymorphism, and the code readability is greatly reduced. Therefore, we need to be cautious here. Facts often prove that people who often talk about design patterns and methods often have problems with over-design. Therefore, a group member who is not familiar with him cannot reduce his or her design risks only based on his words and deeds.
2) If the logic is incomplete and the design is insufficient, as opposed to the previous risk, some colleagues with insufficient design experience often get used to simplifying one thing, this led to many unexpected "surprises" in the coding stage. After a good number of details, the code should be smooth, and there should be no great waves. For these Members, it is necessary to have a basic design process constraint. For example, for details, you must draw a flowchart for all the major functions and review them.
5. Team Management1) new employees with mentoring employees often have no design philosophy. At this time, they can not only review and clarify their ideas to solve the problem. At this time, they need more detailed guidance, so it is necessary to arrange a master for them.
2) during the review, the responsible experts are often held in a State that has no direct relationship with themselves. This may also happen during design document review. Therefore, prior to the review, it is helpful to determine which expert is responsible for the design.
3) after the strict execution plan is estimated, there is a clear plan in the design phase. We should try to be as democratic as possible when developing a project plan, but after the plan is formulated, we must maintain its seriousness and cannot adjust it blindly. For example, it is reasonable to work overtime when there is a planned extension and adjustment is not feasible. Otherwise, the project plan will soon become a blank article.
