For documents in software development, each developer will have some ideas. Today, I want to write some ideas, it is just watching such a post. **************** ****************************************************** HTTP: //www.9cbs.net/expert/topic/839/839157.xml?temp =.7803308? Reply:? Aiwangji (love forget) ?? Mornwoo (insects)? I am fundamentally. But I have to add it. "Software Engineering is the document driver" seems to have no such statement. It is true that the traditional software engineering method of now is mostly driven by documents. But software engineering is for the purpose of improving software quality, increasing development efficiency. Its essence should be an engineered way to improve the quality of "software" (high quality, low cost). When some of the problems areas, we need some documentation to implement this purpose, we should use it, and if some documents are limited and difficult to maintain, we should omit it. Software Engineering is in the end to the software (including documents that can be executed and provided to users), other development documents are intended to improve the quality of "software", which is an indispensable assistant, Not all, not the purpose. Reply to:? Ozzzzzz (Hope agile)? (??)? Reputation: 95 ?? 2002-07-01? 14: 34: 00? Zuore: 0 ??????? AIWANGJI's summary of documents is very exciting Software project is actually a very document is not a companion relationship? The document is just a tool for software engineering? Can you forget the purpose over a hand ??? **************************************************** ******************************************** I have so Idea (1) Document first depends on the scale of the project. In the big project, the cost of facing surface-to-face is relatively large, the importance of the document is self-evident; small items or understanding of the relatively easy project is not necessary to ask the document as the big project. There is an area. (2) The quality of the document is better than the number of documents. It didn't make it clear for a long time. It is better to say more. So the time to leave the code. Therefore, the writing staff of the document must first improve their summary summary. Expressive ability. (3) Do not be too small in the format of the document, a combination of multi-point graphic, is usually a better effect than the full format of the form text. Some people have their own form, If the format box is in turn, it may be unknown. (4) Do not write documents to complete the task, if there is such an idea document, the quality of the idea is rare. It is best to let write documents become the habit of developers, not a forced. .to be update ...
