What is the relationship between software management and software development documents? From CSDN)

Jiangtao:
Opinion 1:
 
The document is important, but to what extent it will be discussed together. At present, most documents are meaningless for the purpose of documentation. I prefer to write a rough picture of the document. I keep asking for details during development. If you have to wait until all the details are written, the workload is too large. In fact, it is very rare to understand the document, but it still needs to be explained by the parties. It's easy to explain, and it's hard to write it out. Which of the two methods has a higher cost.
The corporate culture atmosphere is built to maximize the enterprise's interests. Corporate culture focuses on the long-term goal of an enterprise, while what you mean is the short-term goal. Who should obey? A good corporate culture will fully mobilize the enthusiasm and enthusiasm of employees, which is far more efficient than the pipeline production method. Employees don't sell their lives for you if you give them a few more money, but more rely on corporate culture and organizational behavior to constantly infect them.
In the past, employees in India were very envious of having to keep a full record of their daily work, accurate to points, and finally accurate software development to hours. At the same time, this method strictly limits people's creativity and enthusiasm. Is it to ask how many people wish to work in such an enterprise? Enterprises should be more humane and think more about their employees so that they will strive for you and exert their potential enthusiasm. Enterprises may lose some benefits, but they can retain valuable talents to pave the way for future development.
 
Opinion 2:
You said well. I am working abroad now. Our development is precise to a quarter of an hour, because each person has a job record.
I was not used to this method at the beginning, but I gradually got used to it. Haha, when your workload and money are directly linked together, I became more willing to abide by this game rule. However, as you said, it is easy to get rid of your work enthusiasm. To be honest, not many Chinese people can agree with each other from the bottom of their hearts. Most of us like the free way of working: You give me a schedule and I will give you the result at that time, it's my own job, but it won't work here! Why? The capitalist is absolutely unwilling to give you free time during work hours. His purpose is to analyze the workload and squeeze you more rationally. Do you dare not accept it?
 
There are many types of documents. My development is very detailed. However, details are not complex, but concise. Here: simple-> complex-> simple process. There are not many development documents for me, but all you want is detailed. If you still don't understand, the next step is communication.
 
I am learning to write documents. Indeed, I find it very difficult to write a good document. I cannot write a good document without some experience or level. Don't count on your secretary. New employees can do this, you can try it on your own. However, once a document is built, you get far more benefits than you do. The cost of writing other documents is very low.
 
In development, there is no document constraint. In my experience, programmers often think that Lao Tzu is the best in the world .... The last mess.
Mach:
Documents are just a means of management and communication. What is really important is the management methods and development process hidden behind them.
Too much attention to the importance of documents is blind. A truly effective development process should take into account the development standardization and the creativity of the team. in both directions, it is impossible to go to the extreme: if there is no specification, it will lead to confusion, and the creativity will reduce the development efficiency. The final result will lead to a reduction in enterprise profits.
Qingrun:
Agree with mach.
However, in my opinion, documents should be suitable for matching a form of expression in the software development process. Management and Technology are at the same level, and documentation and development process are at the second level.
My personal opinion is as follows:
1. Documentation is an important means to record the software development process. It is a very important and essential form of expression based on the software development process;
2. The relationship between documents and the software development process is similar to the relationship between management and technology in projects:
In the past, some people have argued about the more important management and technology issues. In my opinion, too much attention to technology will lead to excessive human factors in the development process and the loss of effective project controllability. When management is too heavy, it will lead to a strong sense of loss of technical staff, affecting the morale of developers, and even the project extension, no one is willing to take responsibility.
Documents have a similar relationship with the software development process. Too much attention is paid to documents, which is too formal. This results in a lot of time waste, project delays, reduced utilization of funds, and other results. Focusing only on process ignoring documents will lead to the loss of Project controllability, because there is no valid record that can be used for tracking, it will not be able to check the progress of the project, resulting in project failure.
3. The document should be practical. The document content should be developed based on the users of different documents, and the structure, quantity, type, and focus of the document should be adjusted based on different projects.
We only take this into consideration. You are welcome to join us! ^ & ^
Szfanke:
I think this is still a definition of the software development process. The development document is an element in the development process. After the process is defined, it should be strictly implemented. In my opinion, there is a way to avoid conflict with the development efficiency. You can perform different jobs at different stages of software development and write different documents to record the work results more effectively.
 
Why do many people think that writing documents is difficult and can reduce their work efficiency? I want to consider the following factors:
 
The first is to write documents as a task in a centralized manner, and use documents as an auxiliary tool for work achievements and design and development without any stages.
 
Second, most developers copy reference materials or other document templates as standards, but do not understand what is to be written, what is not to be written, or how to write, as a result, many documents do not play a practical role, and many chapters do not have actual content. I think the document template should be defined based on the actual situation of your project, which documents need to be written, which do not need to be written, and which content and chapters in the document can be selected, the purpose should be to clarify all the problems in a concise and clear manner.
Zxl_l:
Many people think that writing documents is difficult and can reduce work efficiency. I think it is mainly because the documents have been developed first and then supplemented. The documents have not played a practical role in system development. System design and analysis documents that can play a practical role in development are not considered redundant.
Arfayr:
The document is actually an objective constraint tool.
 
What can be written clearly before solidification can be taken as a basis
 
Documents in development are really important. A well-managed development team and a set of good document formats and routines are inseparable.
 
Who would like to provide these documents? Hey, ou must be the first to reach out
 
The current team does not reach this point.
Spell:
Document is the regionalization of the designer's ideas and an important basis for measuring the depth of the designer's understanding of the system.
Imagine: 1. understanding the demand stage: if the user (customer) verifies the correctness of the information the designer understands, how much time will it take to explain your test results if no text bar is provided to the customer! Besides, the customer does not have that much time to listen to the long story of the design.
2. design phase: without detailed documents, it takes much longer to explain to the programmer in person than to explain to the programmer what he does not understand.
3. maintenance phase: the maintenance personnel are not necessarily designers .......
Of course there are still a lot of inconvenience caused by lack of documentation, so the documentation is very important !!!
(Welcome to criticism)
Dreammaster:
My personal views on document and software engineering management:
 
In my opinion, software engineering management and documentation are inseparable. Therefore, documents in the early stage of software projects are more important in management. In my past, the development of each project in a company, all include the acceptance of various documents and the signatures of each employee for their work certificates. Documents are some of the initial results and sometimes become milestones, in the future, there may be less documents in the code, but the user manual also enters the project for testing. The document is the core content of its management.
 
I do not want to over-emphasize the role of documents. If there is good management, there will be good documents. If the management is not strong enough, the documents will become routine, it cannot really show what a document should do.
 
A good code specification is a must for a good programmer. If you have good document habits, the programmer will become a class. Some people may think that the code is too dead and there is no need to do so. Otherwise, software is also a product. It has its own specifications and specifications. If you do not comply with the specifications, the product is made out of an unqualified product. unqualified products certainly do not mean they cannot be used, sometimes the TV shape is a little small, it may not have any impact, but it is an unqualified product of this TV type.
Jnwen:
1. Documents must be reviewed, signed, managed by a specialist, printed, rather than electronic.
2. To test the software, the tester must refer to the document.
3. Any change must have a change notice and approval form. Any change requires a change record and a supplemental test, even a data change. (I am often annoyed when programmers ask me to issue a change notice :))
4. The progress requirement is not the reason for not writing the document. If you have no time to write documents or test documents, do not change them.
5. Use configuration item management to ensure that the software version and documentation are consistent. Any changes must be documented and tested at the same time.
6. Each program and module is fixed after being tested and put into the management database. Before the software is officially run, format the hard disk and reload the software from the Management Library, instead of using the software on the current hard disk to ensure that it is not a development version. Some programmers are afraid of this. This is also true for documents.
7. The documents should be documented at each stage from the very beginning as necessary before the review. Mark and number of the document at the beginning.
Ablg123:
Yes, it's really good. I saw the spark of the Chinese software industry.
 
Some people document for the sake of documentation. I have seen system analysis and design as a simple thing like "Drawing with rose.
I think specific issues should be analyzed based on specific situations. Microsoft's documents do not need to be carefully written. This gives full play to the ingenuity of programmers, however, the premise is that "Microsoft programmers are the top experts in training ".
If the prerequisites are different, there is no money to hire high-level programmers or the management is not perfect, there is no ability to retain high-level programmers, or it cannot provide the conditions for high-level programmers to make full use of their abilities, only a few uncreative programmers or people who do not have a good grasp of the development software and do not know what kind of software should be done, the project will inevitably be a mess.
 
For physical labor-like work, supervision must be strengthened; otherwise, the interests of capitalists will be affected. In addition to supervision, mental labor is more about mobilizing employees' enthusiasm. This is the difference between senior employees and people like "coder.
 
"Life is still like sailing in the dark, so we are still leaning over." Let's work together for the rise of the Chinese Software Industry !!!
Ckwangfg:
I have read the discussion in software management and software development documents !!!
There are only a few developers in our company, and the projects we do are basically relatively small. The previous management was all through verbal communication, the so-called software management is just a record of some key points of the program by developers. once the company's core developers leave, the entire project will be stranded and delayed because there are no relevant development documents.
I am committed to establishing the company's software management specifications and various technical documentation specifications, combined with the company's actual situation, it is impossible to fully adopt a certain standard. The whole process should fully take into account the practicality and operability of the specifications. I do not have practical experience in this field. I hope to get help from you and have in-depth exchanges with you.
MY Email: ckwangfg@21cn.com
Mobbs:
I don't have to ask team members to write documents, which is really annoying.
However
1. In the demand phase, I require detailed use case and activity digoal.
2. In the design phase, I need to have detailed activity digoal, sequence digoal and class digoal.
3. For testing (not to mention the Test phase because I want to synchronize Test and Code), there is a Test case (enough ).
4. write comments to Coding.
Do not write other documents. There are not enough manpower.
Taopi2001:
The so-called document can be said to express the programmer's thoughts in words and embody the abstract thoughts. The process is also an in-depth understanding of the programmer's own project. In fact, this kind of work does not have to be done by full-time secretarial staff. Generally, programmers are competent. Of course, it seems that the liberal arts skills of programmers are not very good, but after a period of training, there is no problem. Learning to write documents is helpful for enhancing the organization, logic, and overall grasp of your own thinking.
Speaking of programming and writing documents, I think of the National mathematical modeling competition that students have participated in. The digital-model competition in China is now the largest competition among college students. One person is responsible for the overall idea, such as the overall structure, algorithm, and solution of the model, one person is responsible for programming, and the third person is responsible for writing the paper. Its purpose is to innovate and team spirit. However, it is impossible to win the national awards by relying on these two points. The selection depends on the level of the paper. In some papers, modeling and algorithms are generally used (compared with other papers). However, they have special characteristics in writing and are used to make sentences properly. They are explained in terms and ways of thinking in professional areas, let experts in this field also think that there is a certain degree of professional depth, and on the other hand, we should also pay attention to avoiding the use of blunt words, tongue twisters, wherever it involves a professional, it should be explained in plain words as much as possible, so that even general college students do not have to struggle to understand. In addition, we also need to consider the overall architecture of the paper, the selection of content, the way of expression, the order, the tone used, the characteristics of the text, and the format specifications. Refined
Indeed, we have to consider every word for a long time, from the reader's perspective, to write a thesis.
Of course, the key to digital models lies in innovation. Only papers with bright spots can be chosen. In comparison with papers of the same depth, it is about writing skills. However, this is a digress ,:).
When I first started learning UML, I couldn't say anything professional. I had to talk about some of my experiences. The purpose of writing these documents is that writing a good document is not easy. It requires a certain degree of professional quality and literature cultivation, however, I believe that general programmers can do it after formal training.
For more information, see.
TechSupport:
We should distinguish two types of documents:
 
1. Purely internal technical documentation: required for development. Developer draft (VISIO), make (typographical,
Internal Technical Department Homepage, power point demo ...) Submitted to the secretarial staff.
 
2. External user documents: user manuals, training courses, etc. These documents require full thinking of developers.
Different, let developers write their own does not meet the software engineering requirements, without their difficulties. Document personnel (Liberal Arts Chinese,
(Foreign Language graduation) it is more appropriate to complete the work after understanding the user role. Professionals only need to proofread.
 
Unfortunately, many Chinese companies still allow developers to take full responsibility for all software documents.
 
Purpose: developers ------ document personnel ------- secretary. A savvy boss knows how to make developers take responsibility
How wasteful the work of archive personnel and secretarial staff is.
Tianxinet:
High-quality documents are very beneficial to project management. PM can reasonably clarify the time nodes of each stage in the development process, so as to improve the control of the software development process, for example, milestone check and Release time schedule.
Agree that "document cannot be used for the purpose of documentation ". In fact, for a specific project, high-quality PM, RD, and QA (good technical quality, clear thinking, and collaboration consciousness) do not require too many documents to be standardized, it can also ensure the development time and quality. However, you cannot expect every developer to have a good quality. This document is necessary.
Of course, from the management perspective, documents are necessary under any circumstances.
Yangzhenhai:
I started out working in a Hong Kong company and sent a fax from Hong Kong.
It took me almost a year to know who the project was for, but the program sent out didn't need to be tested. there will be no such good thing in the future. No company has written formal documents, which is also eight shares.
Is there any good document format to share? I know the format is a form, but sometimes it is not comprehensive. You can prompt the following: the form and content are not in conflict!