I participated in the "XX Equipment Management System" from October 30, 2003, participated in the previous research, demand analysis, summary design and detailed design in half years, and developed the main business process. Module. Now this project is close to the end, encountered a series of problems during this period, and some problems have experienced after they experience, but some things have come, but I don't know how to solve. Here is some things that happen during the implementation of this project.
I was assigned to the XX room of XX and XX, and the technicians of XX and XX were developed by the technicians of XX, and the cooperation model was jointly developed with our company. They sent 2 people from our company. They developed this system with Visual FoxPro 6.0. The time limit was completed before December 25, 2002, and gave the leadership demonstration at the end of December 2002. At that time, the technical personnel of XX said that their system has completed 70-80%, but after another colleague, another colleague in the JS Technical Department, found that they did only 30%, and there was no document, there is no exact need. Where did the two developers do it? Since the development tool used is not suitable for the development of a C / S structure, it is time to practice from the development schedule. After half a month, they found that it is impossible to complete in the expected time, and then entrusted our company's development, and signed a contract, the agreement is completed at the end of December 2002. A version that can give a demonstration.
In the next month (about around November 20th, 2002), 2 technicians from XX got to the company to tell the developers' ultimate user needs, the interface of the system and plan part of the plan will be developed. And the general appearance of this system that will be developed.
At that time, everything seems to be very smooth, although there have been several customers rush to developers immediately coded, but in the end, the customer agreed to decide the decision after completing the requirements. This system is divided into 3 entities from business entities, namely: supply station, warehouse, application unit. At that time, demand analysis and detailed design were mainly in the supply station part, and the details of the application unit and the warehouse section were for only half a day. The application unit has very little business, but the business of the warehouse section is complex than the supply station in addition to the financial sections. Since many of the services of many business and JS technical units is similar, the traffic departments of the service office of the system is designed in accordance with other systems of business mode. However, it is inconsistent with the warehouse outbound and the on-board part and the existing system. Multiple interfaces and processing processes in the warehouse section have changed multiple times.
At around November 23, 2002, I officially started coding. At the time, the goal was to develop a new version of the leader in December 2002, and the developers at the time.
The software life model used in the coding stage from demand analysis is "waterfall", but the purpose of achieving "gradually deliver" is very applicable. This is what I later realized.
Soon I have encountered trouble: What is the count condition of the warehouse? This has not discussed in the demand analysis and detailed design phase. When I developed the Other system of the JS Technical Department, I made this module interface. I asked one of the JS technical department and one group. Developers, asked the project manager of this project, asked the department manager, but the three people's accounting conditions were completely different. Later, and the department manager and the project manager were discussed to identify a counting condition, I wrote this condition to the comment and completed this part of this section according to this condition. There are 2 sets of playing documents in the mission (later I undertake the settlement of the supply station part), this part has encountered some technical problems, hardware issues, and the problem of development tools. This part is solved for a week. The rest used the 3 weeks and ended, and the unit test was taken for a week. This is already at the end of December, and this system's main business process can be demonstrated. Later, there was no demonstration. The end user is not very satisfied with the part and progress that has been completed. Since this system has already had more than 1 million lines of code, it has completed the main part for a month. It can be said to be successful for development speed, but due to time is too tight. There is no strict test, so it will be reported from time to time. Since the demonstration is postponed, the customer sees the final prototype, they think that some places do not meet their habits at all, this is where they must change, but they said that this place is not clearly proposed in demand analysis. So this part is done according to the similar business of the existing system. Due to the "waterfall" life model, the customer did not see the final implementation before the development of the development, there was also amended to this major business. This part of the encoding is completely done during the subsequent development process. The customer's placement and size of the control on the interface is very picky. These are all proposed as a final opinion and have written "the final draft of the instrument system to the equipment system". This is already around January 10, 2003. During the first phase of the development process, the developers conducted a large number of overtime work, and after the end of the first phase, this project even had a short out of control before the end of the final opinion. With a thick end opinion and personnel change, the entire team is low.
After the Spring Festival, this project rebooted, and the final period of customer consultation completed the final opinion was March 20, 2003. Due to personality changes, the original 12 people have fell to 7 people, and I share another work task from the company. Originally planned on March 5th, I don't know why I started on March 12. The joint adjustment is completed on March 23. But this version of the quality is not good, because this system has not been tested from the development to March 23. The problem should still be there.
In the implementation of this system, I have seen a series of issues, most of which are in small projects or do not produce serious consequences, but in a slightly large project, the consequences they produce are Affect the development progress.
1. Demand research and analysis issues. The implementation results of this project have proved to have some important demands in demand research and analysis. Mainly, the technicians of XX are not end users. At that time, we have mastered their needs, but not all of the end users, and in this system implementation, end users are rarely involved. This is a key to this problem. This caused "change demand"
2. Software Delivery Mode (Selection of Software Life Model). In this project, the customer is basically seen after the software is finished, so they have strong opposition to the part of their business processes and those who do not meet the habits.
So the "change demand" (the customer thinks that their needs have never changed, but we have made changes).
3. Customers' "demand gold plating". Customers hope that this system can be well received by leaders, so some practicality and performance of functions and performance of the business is not very practical. This certainly causes us to increase our development task, while the development cycle is extended. 4. Monitoring of project implementation progress. During this project implementation, there is no guidance and tracking monitoring of people who fully understand the business, which is also one of the reasons why some modules need to be modified or even revisit.
5. Documentation and code processing processes are not synchronized, no one is a document update. There is no complete basis and standards in the implementation of the project.
6. The previous design has omissions. On March 18th, the project manager asked developers to change all the state coding to newly added constants, almost use each function related to the business, which is completed, the unit test has been completed, if this time Modify, at least a week of modifying and modifying tests at least one week. Eventually there is no modification.
7. The interface is not unified. At the beginning of the warehouse section, the database is designed with the field type, and the status value and significance are defined. The supply station does not join this field, and the project is reached, the customer requests to join this field. The database of the supply station part has joined this field, but the status value defined is inconsistent with the warehouse. The project manager requested the code completed by the warehouse modification consistent with the supply station. Developers refuse to modify, the meaning of the status value of the final supply station is consistent with the warehouse.
8. Developers are unfamiliar with the configuration tool SourceSafe, causing multiple versions to overwrite the new version multiple times.
9. Software multiplexed issues. For the public module does not update or launch it in time, it will increase the subsequent modification workload.
10. The demand is blurred, and the developer is not available.
11. Guest impact. Customers are technicians, always hoping that the system uses their development experience and model development. If you are different from them, it is possible to change. In this project, the placement of the interface and the LABLE arguments are arguing on the left side of the Edit.
12. Systematic uniform problem. The window of this system and the form of Button's style are determined in the initial period of the project, but for the color of DBGRID and the color of other controls are not defined, the result is 12 developers' interface "Baihua".
13. Third-party control usage problem. Since one of the Open folders in the LMD is used in a module, everyone must install the LMD control to be compiled. In fact, there are 2 sets of third-party controls used in this system, one is DBGRIDEH, and the other is RXLIB. This control can be solved using a control in RXLIB. There are also non-standard controls using this similar to this.
14. System maintainability problem. After three people, the warehouse part has been developed. After the third person leaving the company, the developer discovers that the data set control used by his code is an uncommon Adodataset, and the results have to be replaced by this part, and the results have to be replaced, even some The code is rewritten. Another one is a detailed comment problem. Some code is not annotated, or very little comments. Reading difficulties.
15. The generation problem of database scripts. Database script maintenance in this project is not automatically generated from the latest database, but generates from a maintenance document. This may result in different from the latest scripts.
16. The problem used by the view and stored procedures. Some views can be public and should be defined as soon as possible. The stored procedure is very efficient, but there should be detailed comments, and it is not easy to debug.
17. Problems in the joint adjustment. The share of the Communist Party will cause a database to use the data to be modified or deleted by the other person, affecting the schedule, can use the database replication method, first use the public data to make unit testing, no problem is after using the same The database performs an overall test. Continue to use the backup data of the joint database after the BUG is tested. 18. Database design problems with naming specifications. There should be a comprehensive, easy to distinguish naming specification.
19. Problem of visibility of project progress. This project does not use the minimum milestone to confirm effective enhanced project visibility. Therefore, for monitoring personnel and customers, no one can accurately expect how much it has been completed, and how many tasks should be completed.
20. Developer function gold plating. Since the customer's demand is not clear, the summary design has not mentioned, so in the hands of the developer, "function gold plating" may be generated, which is to be implemented in other technologies, but in order to make a spare post, or experience new technologies. Some development with test or research and development. This is harmful to projects in progress. In this project, I took over some other people's modules. Since the customer is not satisfied with the interface and execution efficiency, it is improved, but it does not propose how the interface is improved, and what is achieved. And because the original code is not comment, and uses an ineffected control, then I rewrite this module, the result is very satisfactory, the interface is still beautiful, and it is still a difficult to solve a plaguing in the interface. Other developers' equipment tree refresh speed problem. But I admit that I made a mistake of "functional gold plating". I made a 2-day test in order to exploit the use of Rising antivirus. And in that 2 days, I don't know if this test can succeed. If it is not successful, then the time these two days is wasteful. If there is no abundant time, a sensible development should not be done.
The above is the experience and lesson I have summed up from this project. At the same time, I still have a lot of questions can't find the answer. Such as:
1. How should I write in a contract with the customer to avoid customers' "demand spread" and "demand gold plating"?
2. Whether the customer's change needs should be met, how is our bottom line?
3. How to do demand research and analysis can ensure that important needs are not missing?
4. How should a large project monitor the best effect?
5. How to design a system that changes the adaptive adaptive?
6. How can I accurately estimate the deadline required for a system?
7. How to exclude customers do not meet the actual needs?
8. Do you have more Case tools during development, such as Rose, PowerDesigner, etc.
Looking forward to discussing with you!
E-mail: ltf_ty@163.net
