Thesis:
I want to talk to everyone talk about what we do in software engineering: system analysis. I hope that our Chinese code people can learn more and better theoretical and practical experience, and have systematic analysis, development methods, steps, and documents that meet our actual situation. Text: I want to talk to everyone talk about what we do in software engineering: system analysis. I hope that our Chinese code people can learn more and better theoretical and practical experience, and have systematic analysis, development methods, steps, and documents that meet our actual situation. System analysis, I personally think it should be a document that can reflect the soul of the system. What should this documentation? What does it mean? I want to discuss it here with everyone. I think there should be the following in the system analysis book (depending on the item): 1. System Demand Description Description System What is a system, use the existing system in the market, use customers (or we own) What kind of system is needed to illustrate, strive to complete. And describe the development and expansion of the system (no system now is OK). Note What is the same as the existing system, indicating that the development of future systems and the ability to expediency can be foreseen. 2. System Resources Description The software and hardware resources required by the system are described. Describe all TCO costs required by the system. Including personnel, time, equipment, system, one-time input fund, sustainable investment of all resources such as funds. 3, system feasibility analysis analyzes the resources in the implementation of the system, illustrating the rationality of inputting, and rational quantification of all unpredictable inputs therein, and the feasibility of the implementation of the system will be described. The top three documents that should appear in the system analytical manual I think, I don't know what I have, please enlighten me. As a job in the development, it should also include: overall design and detailed design. The key issue that must be answered at this stage: Summary, how should I solve this problem? First, several possible solutions should be considered. For example, some of the main functions of the target system are used automatic completion or using labor; if you use a computer, use a batch method or a human-computer interaction method; information storage uses a traditional file system or a database ... usually at least consider Several category possible solutions: Low-cost solution systems can only complete the most necessary work and do not do more work. Sino-cost solutions such a system can not only complete the predetermined tasks, but it is very convenient to use, and may also have certain features and features that users do not specify specified. Although the user did not propose these specific requirements, the system analyst decided according to its own knowledge and experience, which will prove to be valuable in practice. High-cost "perfect" system such as systems have all functions and features that users may want. System analysts should use system flow charts or other tools to describe each possible system, estimate the cost and benefits of each program, should also recommend a better system based on the pros and cons of various programs (best Program) and formulate a detailed plan for realizing the recommended system. If the user accepts the system recommended by the analyst, you can start the other main job of this phase. The above work determines the policy of solving the problem and which procedures are needed, but how to design these programs? A basic principle of structural design is that the procedure should modular, that is, a large program should be organized by many mode-like modules. The second main task of the overall design phase is the structure of the design software, that is, what modules consisting and between the program are determined. The structure of the software is usually drawn by a hierarchical diagram or structural diagram. The overall design phase of the detailed design is proposed to solve problems in a comparative abstract summary.
The task of the detailed design phase is to make the solution, which is to answer the following key issues: "How should I realize this system?" This stage is not a writing program, but a detailed specification of the program. This specification is similar to the engineers used in other engineers, and they should include the necessary details, and the programmer can write the actual program code. The results of the detailed design are usually described with HIPO diagrams (hierarchical graph plus input / processing / output map) or PDL language (process design language). I think the idea of the document system is a process that slowly accumulates. If JJX comrades said, we now have too many stuff, it is not a systematic analysis / design book that the programmer truly needs. The design of the system is implemented to the final code and the acceptance of too much change, we are survive in an extremely unregulated system, so we can't have too many choices, you can only copy it. So to discuss a documentation that is truly suitable for our documentation, this model or the template can reduce the burden for our code work, bring more kinetic energy :) On the current development ideas, application environment and programming methods, Traditional Demand Analysis - System Analysis - Summary Design - Detailed Design - ... It's getting closer, because: 1, the current application is very different from before. The current application is a huge integration, including cross-platform, network, database, etc., and new technology has become more and faster, anyone is unable to master all technologies. Simple example: Now there are platforms such as Windows, UNIX, Linux, etc., SQL Server, Oracle, Sybase and other databases, C , VB, Delphi and other tools, who can be fine? If you can't, how do you determine whether Windows SQL Server Delphi is good or Unix Oracle C is appropriate? 2, customers have no needs. I have done big customers such as banks, telecommunications and various small customers. They have no other words "I want to be an OA system", "I want to be a business network", "I want to be a ...". They can't determine what to do, because few users are actually doing projects due to business needs; and they don't know what they can achieve (because they don't understand Notes, I don't understand business network). 3, changes in demand and environment. Since there is no substantial demand in front of the project development, coupled with software developers are not familiar with the customer's business, leading to the continuous change in demand during development, will result in analysis and design. 4, the objective tools and procedural procedures, the current development tools are very object, and the procedures we develop are very process. That is to say, although the modularity, hierarchy, you have to constantly modify it as soon as the operating environment changes. The actual situation above shows that we really need to modify the practical practice. If a project has achieved 80%, it really clarifies what this system is like, I think it is the failure of the designer. Therefore, in the design phase, it should not only do a variety of documents and arguments in traditional practices, but also should do some specific design work. For example, the overall operation design of the system and the specific design of each functional module of the system. And these designs should have a detailed design manual. When these instructions are completed, you should be able to find a programmer, he can start the code development by seeing a function module, and don't think about how to do it, the programmer is here. Really just a designer's implementation tool.
Of course, it is also like some brothers, the current system is getting more and more complicated, more and more huge, more and more integrated nature, seems to be not how many people can master the specific use, but the key it's here. Can you really do this? Not too! It is only that the current display is that the design staff is low, and some company designers don't have much development experience. How can he learn too much system? The system design seems to be a lot of work, which is a lot of work, which is abnormal. Cultivating a programmer does not have to spend more effort, one person is not very stupid, not too stupid, give him a chance, I believe you can master a technology or method. But to master a number of methods, it is not possible to solve it. The problem is also here. It seems that all system designers can design all things. actually not. Many people have knowledge limitations, which determines that he can only make decisions and design for something in some directions. Customers don't know what he wants, but we should know. If you can contact the user in the previous period, we will in turn inut the designer as a member of the customer, and he can truly understand the customer's needs, of course, you can make a proper design for him. As for the probaches between various systems, I think anything is absolute, and some are just some of the trade-offs. Such as the trade-off, price and performance trade-off and the trade-off of the functional focus, etc. There is no such thing as the thing in the computer does not contain this weighted. Although it seems to convince the user from business, it is good. It is actually not good, and some are just the difference between the difference and the difference. This is like someone always arguing that Linux and Window are good. Perhaps from "technology", Linux is better than Window, but this is not just just because the beautiful GUI interface and friendly interpersonal interaction should also be part of "technology". Get all things, you know that there is no absolute good. Therefore, it is not necessary to make a queue from the system designed by the system before the user decided, and only need to understand the needs of the user, and then determine the direction from the generous direction to do a specific design. Here I only exemplified from the past practical perspective, as in theory, there is no time to go deeper. First, I agree with two statements: 1. Project (or project) has three main aspects: function, time, cost. 2. Tasks for system analysis: transform the user's business logic to program logic, calculate time, and cost. Let us do a profile design: 1) Features: Simple information release system. 2) The system analyst is based on the time and cost of the project. On the basis of the pros and cons of various programs, the system is fully weighing the pros and cons of various programs ... User is very satisfied, OK, start detailed design: 1) For the convenience of the user's installation Use three-layer structure. 2) The client contains information distribution and queries two modules. 3) Use a variety of diagrams or language to describe various functions, processes, modules, layers ... all go smoothly, start coding ... Code is completed, user trial, then the user suggested that the client can track the change in information in real time, and You find Delphi's CORBA does not support callbacks! Transfer to other parties are impossible, remedial measures are not unlikely (such as using Timer, but customer network environments do not allow multiple users of frequent refresh), what should I do? Analysis of the problem is where: 1) Some people will say that the system analyst does not really understand the customer's needs, but this is impossible (the project time limit) is not realistic (it is impossible to let the analyst go to each post) .
