Management of small software project development
Author: Unknown
Article Source:
Http://www.lnu.edu.cn/book/se/happy.html
A company's management, large companies have a big company's way, small companies have a small company's way, if you move someone else's experience, you 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 article 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 it is often the same person from the head to tail responsible for a project. 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 your own work, there is 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, think that anyway, other modules are also very fast, directly using real data to run a few times. 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 bit of boundaries. It may be easily ignored by some borders. After a long time, it was found. However, if each module is tested, you will easily eliminate some hidden dangers. It's really not reaching it. Three. The reasonable development of the reasonable development process is described in a sentence that "the sparrow is small, the five organs". Even the development of small projects 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 a large framework that the development contract must be made before entering the development, and it is necessary to understand what the products in the user's mind are like. 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. (Prototype development can not only be used to accurately acquire user needs, the development of prototype itself can be used as the basis of the next development, increasingly completed) 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-controller 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 "program control machine" in you. The system 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 is used to represent user needs, each entity that interacts with each other is 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, and does not design a specific implementation. What programming language is used in what operational system platform, if you use programming languages? These specific implementations are done in the design phase.
