Management of Small Software Project Development

Author: Unknown

Source: http://www.lnu.edu.cn/book/se/happy.html


For a company, a large company has a large company, and a small company has a small company.
Yourself may be counterproductive. Similarly, managing a software project is the same. The methods for managing a large project and a small project are different. But from
From another perspective, there is no essential difference between project size and project size. Many methods are common. The purpose of this article is to discuss from the author's experience
Management of Small project development.
I. Features of small projects
As we all know, the emergence of the "Software Crisis" originated from the continuous delay or failure of some large projects. Compared with small projects
Features:

1. Relatively few project functions

2. Fewer developers

3. Short development cycle

In addition, in reality, many small projects are developed by some small and medium-sized companies. These companies are often highly mobile, which
Is a reality that cannot be ignored.

Ii. Common Mistakes in small project development
Small projects seem simple and easy to succeed. Therefore, management of small projects is often ignored. In fact, this is a misunderstanding.
In my experience, small project development may easily make the following mistakes:

1. The project feasibility and workload were not carefully estimated before development.

Because the project is small, a development calendar is very hasty, and the difficulty of the project is not estimated seriously. The actual completion time of the result is
There is often a big difference from the estimated completion time.

2. No real design process

A small number of developers means that there are fewer interactions and interfaces between different programs. A short development cycle usually means the same number
An individual is responsible for a project from start to end. Both are easy to make mistakes. Several people often touch their heads and discuss the basic numbers.
Data Structures and function interfaces are used to perform their own work in different parts. There is no formal document.

One of the potential dangers of this approach is that some people may be biased in understanding the interfaces and structures discussed (people should be admitted to making mistakes ).
). A misunderstanding may cause future rework.

Another potential danger is that some situations are ignored during the discussion. Only after everyone completes their work according to the current division of labor
The combination of modules is not a complete system. The root cause is that no person in charge of coordination constantly monitors the entire development.
Process.

The third potential danger is that when someone else quits the development team and joins the team, it is hard for new people to understand what others did before.
Code, simply start from scratch. In addition, it is difficult to maintain programs without documentation and to upgrade Versions later.

3. directly go to the system test without passing the unit test

This is because each module is relatively simple, but some test environments need to be created to test a module. Example
For example, to test whether a function is correct, some test data should be used to call the function. But many open
It is too troublesome for developers to think that other modules are coming out soon. Just run them several times with real data.

As you may not know, once you go directly to the system for testing, you need to perform a step-by-step search if the running results are incorrect. Due to the call relationship between modules,
It may have been a long time before it was found that the problem was caused by a module. This method is less efficient, and a lot of time is used to locate an error in
Module. In addition, because such tests are incomplete and the system is actually running, when a module is called, most of the time it may be normal data,
There are very few boundary situations, and some boundary situations may be easily ignored and discovered after a long time. However, if you perform unit tests on each module
Perform a boundary test during the test to easily eliminate some hidden risks. It can be said that the speed is too low.

3. Reasonable Development Process
A reasonable development model is described as "Although the sparrow is small and dirty". Even the development of small projects should still follow
The general rules of software development cannot be omitted. However, small projects have their own characteristics and can be relatively flexible to implement.
Some.

The following describes the modes that I think are reasonable.

1. requirement acquisition

Before entering formal development, you must obtain accurate requirements from users. It is necessary to spend a considerable amount of time on this.

Software projects can be roughly divided into specialized software and general software.

For specialized software, such as developing a system dedicated to a certain unit, users generally have
Is a clear outline, and is often roughly defined in the development contract.

However, the development contract stipulates only a general framework. before entering the development stage, you must communicate with the user in a more specific manner and discuss with the user.
To understand what the product looks like. If this step is not done well, it will often be done later in the development work.
It is found that there are some misunderstandings between developers' understanding and users' requirements, which will inevitably lead to a waste of time.

For general-purpose software, market research should be carried out before development. On the one hand, the potential of products should be investigated from the perspective of economic benefits.
The market size, on the other hand, from a technical perspective, must be clear about the various technical requirements of potential users for software, such
How the existing hardware is configured, how the software is configured, how the network is used, and what database is used, etc. Based on the statistical results of the survey, it is determined that
Some technical indicators of the developed software.

To better communicate with users, it is very helpful to use some tools.

In order to discuss the user interface, we can use VB and delphi as a prototype to discuss the requirements with users based on the prototype. (Prototype
Development can not only be used to accurately obtain user requirements, but also the developed prototype can be used as the basis for the next step of development.
Development)

To discuss the software running process, you can Use the Use Case diagram of UML.

2. Demand Analysis

After understanding the needs of users, we can use a model to describe the requirements, that is, requirement analysis. Currently, the popular analysis method is
Object method. By analyzing user requirements, various relationships between classes and classes are used to represent the entire system.

This part involves specific methods, which are not discussed in detail here, but in principle it is to extract the class-> the relationship between classes and may need to be constantly modified.
Form an analysis document.

I want to emphasize several issues.

First, we need to clarify the problem domains and system responsibilities. System responsibility refers to the function that the software to be developed should complete, and the problem domain includes all
. For example, if you want to develop a NC Machine billing program, the NC machine is ready to use and the output data format is fixed,
Your program only needs to read the corresponding information from the NC machine. Then, the NC machine is only an external thing in your system.
As a class, it may be unnecessary. You only need a class to complete data read operations. Another example is that you need to specify an existing number.
Some applications are developed on the database. The database format is fixed and a background program is running. You need to develop a new
In this case, the server program is an external thing for you. However, external content like this must be included in the analysis document
As an external constraint of the system.

The second is the relationship between requirement acquisition and requirement analysis.

The method used to obtain the requirement has a great impact on the demand analysis.

For example, when the Use Case is used to express user requirements, the entities that interact with each other are selected from various sequence diagrams.
Class.

Third, the connection between analysis and design processes.

The content of the analysis process is to use the class structure to express the target system, without designing specific implementations, such as what programming languages are used and what operations
For running on the system platform. These specific implementations are completed in the design phase. The advantages of object-oriented methods are analysis, design, and coding.
Unified Process representation and better connection. However, it is to separate the analysis and design phases, adopt waterfall-based development, or adopt others
Depends on the specific situation.

The waterfall model can be used for projects with little potential demand changes. There is a significant design stage. The advantage of doing so is that
Complete analysis documents, so that if you need to use different programming languages or other platforms, you can use this
The analysis document serves as the basis for development.

For projects with frequent changes in requirements, a small amount of analysis may be adopted-> a small amount of design-> a small amount of Code-> the testing method is more suitable and can be used at any time.
It may be returned to a previous stage for modification. However, this means that there may not be a complete analysis document.

Currently, many CASE tools do not differentiate the analysis and design stages. However, this does not mean that developers can leave Analysis and Design independent.
The case tool is like a pen.

3. Design Process

The work in the design phase includes:

Necessary modifications to the analysis model. Some modifications may need to be made to some class structures. The reasons for these modifications may be the requirements of the programming environment.
Or to reuse some previous work.

Define the interface and data access (database.

At present, many programming languages can visually design interfaces, so some of the interface work is often completed in the coding stage. Yu
The workload during the design phase is not large.

4. Encoding

After entering the coding process, you may find some errors in the previous analysis or design phase. In this case, you should return to the previous stage for necessary operations.
.

5. Test

As mentioned above, even small projects should be strictly tested.

Iv. Personnel Arrangement
A relatively small project is usually completed by several people, who basically participate in development from start to end. One of these items
The project owner is responsible for analysis, design and coordination. Because the project is small and the project owner must also participate in programming, this person must take the time
Rational use,

Experience tells me several principles:

1. It is more important to coordinate the work of several people than to complete a code.

Due to coordination vulnerabilities, project owners must monitor the work of developers at any time, including
Whether the content is different from the requirement, and whether the progress is delayed.

Only after completing these tasks can the project owner spend the rest of his time programming.

2. Give each developer a clear task book.

Whether it is development using object-oriented or other methods, the analysis and design model only describes the system from the functional perspective. However
At the time of release, each developer must be very clear about their own tasks. These tasks should be presented in a clear document.

3. Let everyone get familiar with the design model.

Let every developer know the position of their work in the whole system, and sometimes they may find
Vulnerabilities, avoiding the impact of modifying your code after writing.