Let you know about software development in advance (39): the idea of Software Development

Part 1 software R & D work summary

Introduction to software development

 

In the classic book 《Mythical man-monthThe author puts forward a point of view:Most software R & D projects cannot be completed on schedule. I have been working for some time and found that this is indeed an indisputable fact. In my projects, there are very few projects that can be completed by quality on schedule. Why? Are I not working hard enough? None. In order to complete the task, I often work overtime for fear that my boss will be annoyed and my job will not be guaranteed.

Software development is a system engineering that consists of many links. It's not enough for you to make sure that the entire system works properly. In this article, I analyze the problems that may occur in each stage of Software Development Based on the software life cycle (as shown in) for your reference.

 

First, the concept phase.

At this stage, the presales personnel (or other names may be called) negotiate with the local team (that is, the customer) to find out what they need, the system engineer (SE) is reported to the system engineer, and SE is then written as the requirement specification to the software developer.

Most of the problems in software development projects are attributed to this stage. The sooner the problem is discovered, the easier it is to solve. In this phase, a small problem will also be put very large in the future.

The main problems at this stage are as follows:

(1)The presales signed some "Incredible" contracts to "please" the team.. Social competition is becoming increasingly fierce, especially in the information technology field. In the bidding of many companies, it is not easy to sign in to the contract. In order to sign in the contract (meeting the company's assessment indicators at the same time), the pre-sales staff always bid in front of the customer, and do not hesitate to exchange various promises and rhetoric to return the profit of the already thin contract. Many of these contracts have yet to be studied and need to be reviewed over and over again. However, most pre-sales personnel do not understand the technology. After the contract is signed, the product will be "rewarded", which impairs the development staff and the progress and quality of product R & D.

(2)Bureau staff are on the top and often change their ideas. Just like the current employer's recruitment of fresh graduates, the local team (also called Party A) selects a large number of companies (also known as Party B), not only lowering the contract amount, call the presales staff to change the demand statement. This is not honest. At this time, someone always says, "who makes people a party ?"

(3)The system engineer (SE) did not clarify the requirements and did not express the meaning of the outsourcers. Different people have different opinions on things, and the written things will be different. What's more, from the Bureau staff to the presales staff, to the se, the middle has already been transferred several times, the error of expression is inevitable. Se is sometimes relatively "lazy" and does not want to have in-depth communication with the Bureau staff. I think I have understood the meaning, which also leads to the incompatibility of software functions in the future, we have to reinvent it again.

We often say that we should put bad things in the bud. In the concept phase, that is, the formation phase of the software prototype, the functions of the software must be clearly defined, which also saves a lot of inconvenience and tossing.

 

Second, the planning phase.

At this stage, the software is designed in detail based on the requirement specification, and the execution process and related functional modules of the program are determined. This is what software development engineers need to do.

At this stage, the following problems may occur:

(1)Coding starts immediately without review after detailed software design is complete. The company stipulates that the detailed design should be reviewed before development can be started. Many times, in order to catch up with the Progress (I personally hate the word "catch up with the Progress"), this step is also omitted, which directly leads developers to design software according to their own ideas, A misunderstanding occurs, leading to the failure of customer acceptance. In order to ensure the correctness of the software, you must not take a moment to review your detailed design. This is the so-called principle of "never cut firewood by mistake.

(2)In order to cope with the review, software developers have written detailed program processes. After the development can be started, they have deviated from their previous ideas.. This often occurs during the R & D process. When we read the code according to the detailed design of the software, we find that the program process does not match the flowchart in the document, and sometimes the deviation is relatively large. This is the issue of developers' personal qualities. In the coding process, be sure to be loyal to your detailed design as much as possible, and update the detailed design documents at the same time when you really need to modify them.

In many projects, the design phase is often combined with the development phase, one side of development, one side of design. I personally think this is inappropriate. You must have a comprehensive understanding of the program process before coding.

 

Third, the development stage.

The development stage is the stage of implementing the idea with a program, also known as the coding stage. The importance of this stage is self-evident, and the most serious problem is also this stage.

Anyone who has participated in software development will know what the problem is at this stage. I have summarized the following aspects:

(1)Write code that can only be read by yourself, rather than according to the company's programming specifications. This is the biggest headache. When we open the program file prepared by the previous developer, we can see its professional quality and attitude at a glance. Among the programs I have read, few really comply with programming specifications, most of which have these problems:No annotations, invalid names of variables and functions, chaotic program logic, and poor program Layout. In the previous article, I also gave a detailed description of this aspect. In a word, regulation is indispensable in any case. Do not destroy the "game rules" as far as possible ".

(2)You don't need to program your skills in the simplest way.. Many developers have a High Level. They like to write code in a way that is unknown to ordinary people to express their own capabilities. But they forgot that we should use code to implement the functions of our products, rather than to show how high our level is (where we are displaying various online programming competitions ). When your successor reads confusing code, they will never praise you for your level, but will scold you in your heart. In many works, I have elaborated on this aspect. A central idea is:We need to write programs in the simplest and easiest way to understand them..

(3)Do not focus on self-testing of the program, think that testing is just a test engineer thing. In the concept of many developers, you just need to write the code, and the remaining test tasks can be completed by dedicated persons. Now, big companies are emphasizing product quality and fully testing their products. For developers, self-testing is required to ensure that the program submitted to the test department is free of errors. Many people may look down on testing and do not want to find their own problems (the test is to find out the problems), but this is not a problem they like, it is the requirement of professional quality for us.

The above three points are almost common faults of developers and the biggest obstacle to improving software quality.

 

Fourth, the verification phase.

The verification phase can also be called the test phase. It is mainly used by software testing engineers to test the programs written by the development engineers to ensure the software quality. There are two testing methods: white box testing and black box testing. Most people who have worked in software companies should know about this.

Originally, testers and developers should be "brothers" and everyone should work together to ensure product quality. However, the current situation is the opposite. Sometimes the development and testing departments are "bitter enemy ", do not communicate with each other. Developers look down on the test and think that there is no technical content. The test is also proud to find the development vulnerabilities. Many projects even set indicators, the number of fault tickets to be submitted every month (the ticket is to find the development problem), which makes developers feel uneasy and disgusted.

How can this problem be solved? First,The company's assessment mechanism should be changed, so it is impossible to assess the number of employees with a ticket; Second,Communication between developers and testers, Do not "keep busy"; again,The goal is to deliver high-quality products.Instead of all day-long fun.

Of course, the above expressions may be inappropriate, but it is more or less true:Development and testing should cooperate more than confrontation.

 

Fifth, the release phase.

After the test is completed, the product should be delivered to the customer and asked for acceptance. At this time, the most feared thing is that they face on the spot, saying that the product features do not meet their requirements. This situation often occurs, causing serious losses to many projects.

In order to avoid such incidents, in the software development stage, the relevant owner (especially SE) must coordinate and communicate, and let the customer know the implemented functions, ask them to confirm whether this is what they want. It can be seen that communication is important everywhere.

 

Sixth, operation and maintenance.

After commercial use of the product, the company must maintain it and rectify any problems in time. Generally, as long as the product test is fully verified, the chances of problems are relatively small. The fear is that the customer's head is hot. After a while, the developer and the tester will be busy again.

 

As mentioned above, software development is a complex system. Only when every part of the system runs properly can the entire system be able to run normally. Once a problem occurs at a stage, the system is like a ship with water leakage. If it is not repaired in time, it will sink into the sea.

They all say that IT practitioners are very tired, whether engaged in technology or sales. This is indeed the case. As long as there is a small problem with the product, will the six stages mentioned above be repeated again?

 

Based on the work experience of the author and my personal feelings, this article expresses my views on software R & D projects. If this is not the case, please correct your criticism. In short, even if the night is dark, the sun will rise as usual tomorrow. My work mainly depends on my mentality. What do you think?

 

 

(My microblogging: http://weibo.com/zhouzxi? Topnav = 1 & WVR = 5, No.: 245924426, welcome !)