Software Development misunderstanding (zt)

With the continuous improvement of computer hardware, the scale and complexity of computer software also increases. Computer software development from "Personal Hero" Times In the Team era, the management of computer software projects has also moved from "Workshop-style" management to "software-driven" management.

This requires software developers, especially Software Project management personnel can further understand and master the theoretical methods of modern software engineering and complete the ideological and conceptual changes. I have analyzed 10 misunderstandings that may easily fall into the ideological concepts of modern project management, hoping to inspire others to think about and discuss them.

Misunderstanding 1: In the project demand analysis stage, Development The Party and the customer can reach an agreement on the basic outlines of various issues. The specific details can be filled in later. No matter how detailed at the beginning, modifications to requirements in the future are almost inevitable. Analysis: This is Very Dangerous thinking. In fact, the main cause of failure in many software projects is that the problem is not described in detail in the demand phase, resulting in a later budget exceeding or time schedule failing to meet the requirements. The correct approach is: in the project demand analysis stage, both parties must thoroughly discuss the project's application background, Function Requirements, performance requirements, operation interface requirements, interface requirements with other software, and various evaluation criteria for project evaluation. In addition, after the demand analysis is complete, both parties need to establish channels for direct contact, so as to change the demand as early as possible. Problem Communicate.

Misunderstanding 2: The needs of software projects can be constantly changed and these changes can be easily implemented. Analysis: indeed, it is difficult for the customer to fully and accurately describe all problems in the demand analysis stage for various reasons. As development progresses, there are often some changes in requirements. Modern software engineering theory also uses the flexibility of software to adapt to this situation in various ways. However, this does not mean that "the needs of software projects can be constantly changed and these changes can be easily implemented ". Practice shows that as the development progresses, the cost of changing software requirements increases exponentially. It is assumed that it takes twice the cost to implement demand changes in the demand analysis level. In the design and coding phases, the cost is 1.5-6 times the cost. System The test phase may cost 10-20 times. After the software version is released, it may even cost 60-times. It can be seen that changes to software requirements should be proposed as early as possible during the project development process. In this way, it may cost less and is easy to implement.

Misunderstanding 3: software programs are mainly composed of code. Therefore, the coding stage is the most important stage of the entire software project. A lot of time should be given and the main resources should be concentrated. Analysis: compared with the past, due to the increase of software scale and complexity, and the emergence of semi-automatic software code development platform, the center of modern software project management has been transferred-not focusing on the coding stage, it focuses on the overall/Detailed design stage of the system. Generally, the rational allocation ratio of various resources in modern software project management is: 3% in project demonstration and risk assessment, 8% in project requirement analysis, and 45% in system overall/detailed design, code stage 10%, system test stage 34%.

Misunderstanding 4: In order to facilitate code maintenance and modification, the document work in the detailed design phase of the system should write the pseudo code of all programs. Analysis: Generally, the main function of the pseudo code is to describe the algorithm flow of the program, so that people can gain a deep understanding of the functions and implementation process of the program. It can be seen that, to a certain extent, the pseudo code is indeed conducive to the maintenance and modification of the program code. However, we know that to ensure the one-to-one correspondence between the project document and the program code, we also need to maintain the project document while maintaining the program code. The pseudo code is very similar to the program code. If the pseudo code is maintained, it is equivalent to twice the program code maintenance. The workload is huge. Therefore, the practical method should be to implement a program flow chart for the general program documentation. For those involving more complex algorithms, the pseudo code is required.

Misunderstanding 5: since a dedicated tester is set up in the project staffing, all the internal testing work of the software should be completed by the tester. Analysis: software program testing can be divided into two methods: "white box" and "black box. Because the "white box" method has various requirements on the quality of testers, the "black box" method is always the best choice for testers during program testing ". They often work in the "black box" Test of the program first; if the test fails, they have to consider the "white box" Test of the program code. Obviously, this "escape" intentionally or unintentionally to the "white box method poses a threat to the software's reliability and stability. How can this problem be solved? On the one hand, we need to improve the requirements for testers, and on the other hand, we also need programmers to complete some "white box" tests (in fact, programmers are often the best candidates for "white box" tests ).

Misunderstanding 6: software project management is only related Technology Department matters are irrelevant to other departments of the company. Analysis: In today's increasingly fierce competition, software projects are large, complex, and time-consuming. To improve the company's software project management level, it is necessary to improve the company's overall awareness of participation, the company's various departments need to work together. For example, the accounting department is required to assist in project budget, financial management and cost control; the research department (Technical Committee) is required to assign Experts Assists in risk assessment and provides technical guidance; various support needs from the Logistics Department.

Misunderstanding 7: When the development progress lags behind, you can hire more programmers to join the development team and add human resources to catch up with the progress. Analysis: in the era of team development, developers should carefully consider this practice based on the current software project management level. If the new programmer has a certain understanding of the application industry of the current software project, and can quickly adapt to the developer's project management method, software development style, and team collaboration atmosphere; therefore, it is helpful to join the "new person. Otherwise, you may be "willing to do bad things ". Despite its high personal abilities, the development team had to assign people to train the project-related technical/business personnel in order to work with everyone, what's more important (and the most difficult) is to guide them into the team. This may take a lot of time and effort from the development team, making the project progress slower.

Misunderstanding 8: The technical backbone should be the project manager of the project. The project manager must have the highest salary among all project members. Analysis: In the "software Workshop" era, this is a widely used and effective method. In the "software factory" era, this method has brought about various problems, sometimes the project fails. The main reason is that, with the refined division of labor in modern software development, the requirements for project managers have also undergone fundamental changes-the most important thing is not the mastery of a certain professional technology, it is its ability to organize, lead, and coordinate development teams (of course, both of them can be the best ). As for the salary of the Project Manager, this has a lot to do with the pay-as-you-go system. In general, the Project Manager executes the compensation system of management personnel, while others execute the compensation system of technical personnel. The Project Manager's salary is relatively high among the project members, but not necessarily the highest. Sometimes, to motivate technicians, the technical backbone in the project gets a higher reward than the project manager.

Misunderstanding 9: only the project manager and department director are concerned about the overall progress of the project, and the programmer is only concerned about the development progress. Analysis: This is a bureaucratic idea. In fact, as a member of the team, a programmer not only works as a engineer, but also participates in the creation of a "work. While appreciating the hard work, it is more important for programmers to enjoy the pleasure of creation. The project manager should not ignore the programmer's pursuit of "sense of accomplishment", but should explain to everyone how wonderful and exciting the final "work" will be, and set up a series of milestones on the way to the final goal. Whenever the project moves toward a milestone, the project manager should notify every member of the project. In fact, this not only allows all project members to enjoy the joy of a phase victory, but also inspires greater enthusiasm for work and improves work efficiency.

Misunderstanding 10: to ensure that the project continues, to retain the core programmers, raise the salary. Analysis: salary increase can be said to be a common method used by many enterprises to retain programmers. This offer may take effect temporarily, but it is often because people have stayed, but the side effects have also come. People with salary increases may not see much work, but those without salary increases may start to neglect. In fact, too many projects rely on the programmer's personal technology as a "bad habit" in the "Workshop" era ". Since the flow of people in the IT industry is uncontrollable, project execution should pay more attention to the strength of the group, and the overall technical level and core technical capabilities of the company should be considered. Such as the company's own expert knowledge base, class/function library, third-party control library, and a development platform with independent copyrights. In addition, in fact, the reason why programmers give up their intentions is largely not salary, but lack of encouragement and respect. This requires the project manager to use the "old soil" method, find the right time to do ideological work for programmers, describe the bright future of the project, and let them feel concerned and respect. In short, we should begin to ensure the smooth development of the project from multiple aspects, rather than simply raising the salary.