Project Features: Running Environment is Redhat Linux 9.0, distributed system, no user interface, and uses the running mechanism of the message queue state machine, requiring uninterrupted service programs.
2 project situation
2.1 Development Model
The feature of this project is relatively clear, no user interface, medium size, so the development model uses a waterfall model. Demand analysis, summary design, detailed design, encoding, and several phases.
Only one demand change in the later period of the project, and the impact is small, which proves that the waterfall model is reasonable.
2.2 Time Assignment
It is expected: at the end of April - at the end of August
Actual: late April - early October
Demand Analysis Summary Design Detailed Design Coding Test April in late May - May 25th in late May - 23.5% in late June - 23.5% in late July, 17.6% in mid-August - October 29.4% in early
2.3 personnel arrangement
It is expected:
actual:
Demand Analysis Summary Design Detailed Design Coding Test The maximum 3 people usually 2 people The most, 3 people usually 2 people, 3 people usually 2 people, 3 people usually 2 people, 5 people usually 2 people
2.4 Code Size
It is expected:
actual:
Subsystem Name Simple Module Medium Module Complex Module New Demolition Multiplex Coded Codes B4368700253111231A836870023765798 Test Procedure 121125460 Row 2546
Note:
The unit of code is "line", statistical method: View with wc -l sourcefile commands in Linux
Simple module: logic is simple, no complex operation, code amount is around 100 lines, mainly for the management of containers
Medium module: logic is general, the amount of code is around 300 rows, the module is mainly received, the module is processed
Complex modules: logical complex, or newly written algorithms, the amount of code is above 350 rows, mainly the state machine in this system
2.5 Defect statistics
Subsystem name requirements Summary Design Detailed Design Coded Total Code Quality B0338141087 Row / A112261711 Row /
Note:
The code quality shows a bug in average number of lines, computing mode: short-write code quantity / coding phase defect
Here only the defects introduced at each stage in the project development cycle, more detailed BUG information has been individually organized and submitted to the TD database into the TD database.
2.6 Development Tools
"Workers must have a good fault, you must first make a tool", using good tools can greatly improve efficiency, we also use a lot of tools in this project, I hope to have a reference for similar items in the future:
Ø Modeling with ROSE, painting network topology, state diagram with Visio. When drawing a complicated state diagram, Visio is used more intuitive and concise than ROSE.
Ø Version management adopts Visual SourceSafe6.0
Ø Code: VC 6.0 Visual Assist plugin
Ø Using Samba, and "Mapping Network Drives", this is not used back to return files between Windows and Linux.
Ø Debug: When the program has an abnormality, run the program with the GDB and make it break, and then enter INFO STACK in GDB. You can know where the program burst. Output debugging information in the program and observe it, is also a hassle but effective method.
Ø Open the source file in the VC to view, from the check out on SourceSafe, the file opened in the VC is not turned off, and the VC sometimes does not prompt the file to be updated so if you continue to edit the source file and Check IN, it will cause the file content to be lost. ! For insurance, it is recommended that Check Out or get Latest version, all turn off the file opened in the VC. 2.7 All stage documents
The main documents generated at each stage are as follows:
"ABC requirements manual _B part.doc"
"ABC demand manual _a part .doc"
"ABC profile design .doc"
"ABC Detailed Design _b Part .doc"
"ABC Detailed Design _A Part .doc"
"ABC user manual.doc"
"ABC Technology White Paper.doc"
"ABC Defect Correction Record"
3 summary
Memory leak detection:
1) Operating 1-3 days under pressure, checking the changes in memory share, if the memory usage has been increasing, it can be initially judged that memory leaks
2) Reburning the new / delete and malloc / free, record the address and length of the assigned memory in the container, release memory, delete memory allocation records, and check if there is still not deleted record in the container, if any, There may be memory leaks. This approach can only be checked for source code, and it cannot be detected for third-party libraries without source code.
3) Check with memory leak detection tool VALGRIND, which can check memory leaks in third-party libraries without source code
4) The memory allocation function in the OSIP library is Smalloc, Sfree, and uses the second method that cannot be checked, but you can use the same idea to modify the code of Smalloc, Sfree to implement memory leak detection.
pressure test:
1) Specialty test tools although powerful, it is not necessarily practical. The simulation tool can be written according to the actual needs.
2) The SIPP tool can simulate the SIP client and the server, and you can multiplex, statistics.
test:
The tester can be able to intervene in the project in demand analysis, and perform full tracking, so that the understanding of the system is more deeper, and more targeted when designing test cases.
When designing test cases, more tests are tested more, after all, the purpose of testing is to discover BUG, not just verification.
time management:
The project has been more than 5 months, and it is delayed than expected (end of the end of April to August). The reason is the following two aspects:
1) Change in the process of projects. At the time of detailed design, I changed it once when I was tested, and the progress had a certain impact.
2) In the test phase, the modules in combination with the ABC, such as the AA, BB, and CCs are performing corresponding changes, resulting in the problem of testing, and waiting for other module corrections.
This can also be reflected from the actual allocation ratio of project time. Detailed design and tests account for 23.5% and 29.4%, respectively.
Technical solutions:
The running mechanism of the message queue state machine is better than a session corresponding to a process thread, which can support a lot of concurrency processing, while using load balancing, so that the system has better scalability (scalability).
Review:
It can be seen from the defect distribution of this project that the reviews of each stage have a great help to improve product quality. In particular, there are many errors when the code review in this project is discovered, and then reappeared after the BUG is found in the test phase, and the positioning should be efficient. If you don't have a condition, you can check each other's code between the developers.
When reviewing, it is best to send relevant information to personnel to participate in the review, and see those who have reviewed the review must be prepared to avoid overfolding. State machine programming:
There are two mainstream ways to implement a state machine programming, one is a Switch ... case mode, each state corresponds to a function, and processing various messages of this state within the branch of the function. The advantage is that the logic is clear and easy to maintain; the disadvantage is that repetition is more. The other is an object-oriented manner, each state corresponds to an object, and the state transition is implemented by switching objects, and message processing is implemented by the object. The advantage is that the code is redundant, the disadvantage is not clear enough, it is not easy to maintain.
In this project, B uses the first method, and A uses the second method. According to project practice, the first method is better, after all, the logic of the state machine is more complicated, and it is important to maintain.
Code multiplexing:
In this project, the proportion of multiplexed code accounted for the total code amount is: B 22.54%, A 40.98%, the proportion is relatively high, which has great help to increase productivity, reduce BUG. The code for the actual project test is the value of the company's valuable property. In the future project, we must pay more attention to the accumulation, reuse, "Do not repeat the invention".
The above project statistics and summary can be used in the future similar project reference, good experience should constantly summarize and learn from, and the incadvenation is improved, so our team's development capabilities will continue to improve.
This project statistics and project characteristics and project development have a big relationship, there is a uniqueness, but there are more projects that have been made, and there are more data accumulation, you can summarize our commonality, thus estimating our project Project management has a great help.
The results of this project are not only the ABC product itself, the accumulation of project experience and talents accompanying projects grow up are the greatest wealth of the company.
