The management of small software projects (this article is reproduced from the software engineering expert network www.21cmm.com) A company's management, large companies have a large company's way, small companies also have small companies, if other people's experience is moved hard to themselves It may be counterproductive. Similarly, the management of a software project is the same, the way the big projects and small projects are not exactly the same. However, from another perspective, the big and small items of the project have no essential difference, and many methods are common. The purpose of this paper is to talk about the management of small project development from the author's experience. First, the characteristics of the small project know that the emergence of "software crisis" originated from some large projects and even failed. Compared with the small project, it features the following characteristics: 1. Project function is relatively small. 3. Developer less 3. The development cycle is short. In reality, there are many small projects to be developed by some SMEs. These The company often has a large liquidity, which is also a reality that does not to ignore. Second, the wrong small project in small project development seems to be simple, it is easier to success, and people tend to ignore the management of small projects, in fact, this is one Misunderstanding, from my experience, it is easy to make the following mistakes in small project development: 1. There is no estimate of project feasibility and workload before development. Due to the smaller items, it will develop a development schedule, and there is no serious estimate of the project difficulty. The actual completion time and estimation completion time often have a large difference. 2. There is no real design process developer, meaning interacting between the procedures of different people, and there are fewer interfaces. The development cycle means that the same several people are responsible for one project from the head to tail. Both are more likely to make more mistakes. It is often a few people touching a head, discussing the most basic data structure, and the function interface is in the hands of their own work, no more formal document. One of this potential danger is that some people may have deviations to the interfaces that are discussed (should recognize that people will make mistakes). A misunderstanding may result in future rework. Another potential danger is to ignore some cases due to discussion, and after all the division of labor belongs to the work, it is found that each module is not a complete system. Its root is that there is no one responsible for the coordinated person to monitor the entire development process. The third potential danger is that once someone quits the development team, others are added, and the new people are difficult to understand the code for others, and they are from the head. In addition, there is no documentation, and it is difficult to maintain and version upgrades in the future. 3. The reason for this phenomenon without the unit testing, and the reason for this phenomenon is that each module is relatively simple, but in order to test a module, some test environments are required. For example, in order to test if a function is correct, you should use some test data to call the function, you need to write some test data. But many developers are suspected, thinking that other modules are also very fast, and they will run several times with real data. As everyone knows, once they go directly to the system test, it is found that the operation results need to find step by step. Due to the call relationship between the modules, it may be found that it is a problem with a module for a long time. This method is relatively low, and a large amount of time is used in the module. In addition, since this test is incomplete, the system is really running. When a module is called, it may be normal data, and there is little boundary. Maybe some borders are easily ignored, and it is only found for a long time. However, if each module is tested, it will easily eliminate some hidden dangers. It's really not reaching it. III. Rational development mode of the development process, one sentence is described "Although the sparrow is small, the five organs", even if the development of small projects, it should still follow the general rules of software development, and the necessary steps must not be omitted.
But the small project has some of its own characteristics, which can be relatively flexible. I will describe the pattern I think that I think is more reasonable. 1. Demand acquisition must first get accurate demand from the user before entering formal development. It is necessary to spend a considerable amount of time here. Software projects can be roughly divided into two categories: dedicated software and general software. For special software, such as developing a unit-specific system to a unit, the general user has a relatively clear profile for software to complete, and it is often generally specified in the development contract. However, it is only a probably framework that the development contract must be made with the user before entering the development, and it is understood that the product is exactly what the product in the user's mind is. This step is not good, and often, it is often found that the developer's understanding and user requirements have some misunderstandings, then it will inevitably cause time waste. For universal software, there should be a certain market survey before development. On the one hand, it is considered for economic benefits. What is the potential market for investigation products, and on the other hand, it is necessary to understand the various types of software. Technical requirements, for example, how the user's existing hardware configuration, how the software configuration is, what network, what database is used, and some technical indicators that are about to be developed according to the statistics of the survey. In order to communicate with the user, it is very beneficial to use some tools. In order to discuss the user interface, you can use VB, Delphi, etc., to discuss demand with the user according to the prototype. (Prototyping is not only to accurately obtain the needs of users, but the prototype of the developed prototype itself can be used as the basis of the next development, and the increase-incrementally completed development) In order to discuss the flow of software, UML can be used. 2. Requirements analysis After understanding the user's needs, the demand is represented by a model. It is a demand analysis. At present, it is currently an object-oriented approach to analyze user needs, use class, and class. Relationships to represent the entire system. This part involves a specific method, discussed herein, but in principle, the relationship between the extraction class-> class may require constant modification to form a analysis document. I want to emphasize a few questions. First, we must divide the problem domain and system responsibility. System responsibility is the function that the software to be developed should be completed, and the problem domain is to include all related parts. For example, you have to develop a program-controlled machine billing program, the program is already ready-made, the output data format is already fixed, and your program only needs to read the corresponding information from the program, then the program control is in your system. It is just an external thing, which may be unnecessary as a class, just a class to complete the operation of reading data. As another example, you need to develop some applications on an existing database, the database's format has been fixed, and there is already a background program running, you need to develop a new front desk program, then the server program is for you. An external thing. However, it is necessary to have some instructions in the analysis document, as the external constraints of the system. The second is the relationship between demand acquisition and demand analysis. What method uses to complete the acquisition of the needs, to a large extent, affect the needs of demand analysis. For example, using USE CASE to represent user needs, the individual entities that interact with each other are selected from various sequence diagrams, that is, one class. The third is the connection between the analysis and design process. The content of the analysis process is the structure of the class to represent the target system, does not design specific implementation, if used, what programming language is used, run on what operating system platform, etc. These specific implementations are done in the design phase. The advantages of object-oriented methods are analyzed, design, and encoding process representations, which can be more good.
