The specific steps are as follows:
Step 1: Demand Analysis
I called all their business-related departments to hold several meetings, sorted out and unified the functional requirements of each department, and wrote a functional requirements specification, which listed in detail the practical problems to be solved and the goals to be achieved by the software. They demand that software can solve their practical problems and bring real value. For example, directly bring them more orders, help them find and retain customers, save labor costs, prevent unnecessary waste in business, and finally realize the growth of the company's profits. In my opinion, if a software can't bring substantial economic value, it is better not to use it if it is only used to decorate the company's facade and improve work efficiency. This is also the reason why they don't like some finished software and choose custom development. The situation of each company is different, and finished software vendors often can't know the pain points of each customer, so the products they make are not really suitable for customers. Only by their own targeted development can we really solve the problem. Only customers know what their company needs most, how to acquire and retain customers, how to design business processes and so on. The most suitable software is to develop some practical functions.
Through this project, I realize that the process of writing software requirements specification is very important, which determines whether the future development process will take a detour, whether it will waste time and money because of developing unnecessary functions, and whether there will be conflicts between program function modules. A lot of energy has been spent on the preparation of the demand statement, and there is a feeling that sharpening the knife does not mistake the woodcutter. Finally, after all employees unanimously passed this demand statement, we decided to proceed to the next step.
Step 2: Develop the proposal.
The development plan is to transform the functional requirement specification into a specific action plan that can be developed. I wrote it according to the development rules of the development platform, optimized the functional modules in the software requirements specification, analyzed the data structure, data relationship and operation logic of each module, defined the business processes between each module, and finally planned the interface styles of each module according to the actual situation of the personnel in each business department.
My development plan is also very detailed, but it feels easier than the functional requirements specification. After all, the general direction is already there. In the development plan, I plan and name all the tables and fields in the data structure, including their data types and lengths, make tables, and explain the data sources and editing methods of each field. I forgot to explain earlier. Although I don't know programming, I still know a little about the database because of my previous experience in managing software operations. However, this database knowledge is enough for development with our rapid development platform. If you need some more complicated SQL statements in the future, please search online.
The development plan is very important for the later system development. The following development process is actually the process of configuring the development plan content on the rapid development platform.
Step 3: Develop and Test
With the development plan, the next development will be easy. In fact, it is the process of configuring the content of the development plan to the development platform, which is why I found such a development platform to develop this system.
Developing software with configuration development platform is quite simple and fast, and the general module can be done in three steps. The first step is to set module information, the second step is to set form properties, and the third step is to set each field in the table. Maybe you still don't believe me when I say this, okay. Above!
Our company's rapid development platform is divided into development background and application prospect. As the name implies, the development background is for developers, and the application foreground is where the developed system is used. Ok, let's enter the development background, as shown below:
Click module design, and you can start configuring the module.
Choosing the module type is the key to this step, that is, what kind of module you want to develop. There are many function templates built into the development platform. What you need to do is to analyze which template the module you want to develop belongs to, and you can realize your module interface and function by choosing a template. There are many kinds of modules, including all aspects of commonly used management software, as well as special module function templates and operation manuals, which you will know when developing. After defining a module, you can define a table in the module. A module may have multiple tables, define them one by one and establish the relationship between them. As shown in the figure below:
In the process of form definition, it is necessary to set the style of form editing interface and some data rules. After the form is set, it is time to set the fields of each table. As shown in the figure below:
Through three-step configuration, a functional module is basically completed. Isn't it simple and quick! Is the whole development process completed by configuration? Of course, the above are some of the most basic configurations. For modules with complex functional requirements, more detailed configuration may be required.
Because the configuration development platform omits code writing, the development speed is greatly improved. Because the interfaces are automatically generated by the middleware of the development platform according to the configured business parameters, there is no need to write a set of codes for each interface, so the error rate is greatly reduced, and the performance and stability of the software are naturally guaranteed.
Step 4: Write the operation manual.
After the system is developed, there is a finishing work that cannot be saved, that is, writing an operation manual. Fortunately, I like to write some blogs when I have nothing to do, and I am not afraid to write. The operation manual is for users to learn and operate. In the operation manual, I listed the operation process of the system and its precautions in detail. Afterwards, I learned that the operation manual is also one of the important factors for the formal use of this system, because the operation manual I wrote is vivid and clear, and my colleagues who operate this system will soon understand and get started.
My experience is that the earlier the operation manual is written, the better. It is best to write it at the same time as development. Some key contents in the development process should be recorded immediately to remind future users that even the developers themselves may forget it after a long time, and finally let users take fewer detours.
Step 5: Online debugging
After more than half a month's struggle, an internal management system with more than 50 modules has been basically completed. We asked the leaders of several departments of the customer to demonstrate the operation together, and everyone was very satisfied. Finally, we have lived up to the expectations of the old board. As soon as their boss was happy, he approved the purchase of a server to run the system. It took me a day to deploy it to the server and start online trial operation.
Step 6: Formal operation.
After half a month's trial operation, we adjusted some minor problems, and began to convene relevant personnel from various departments for several days' operation training, and began to officially run in the company.