This is the second day of my participation in Gwen Challenge
preface
The last article focused on what a configuration system is and its technical architecture. I believe you have a relatively simple understanding of the above content.
In this issue, the project will be planned from the perspective of software engineering, and the subsequent development plan and schedule will be determined. Of course, the first thing to do before you start is a feasibility analysis.
What is feasibility analysis?
Not every problem has an easy solution. In fact, many problems cannot be solved within the predetermined system size or time frame. If there is no feasible solution to the problem, then any time, manpower, hardware and software resources and money spent on the project are wasted.
Feasibility analysis is to find the risk points that cause problems in advance and give suggestions for follow-up courses of action. Identify problems early in the project and the cost and cost of correcting them will be lower.
However, it should be noted that in the feasibility analysis stage, it is not necessary to specifically solve the problem, but to study the scope of the problem and explore whether the problem is worth solving and whether there is a feasible solution.
Feasibility analysis is generally carried out from three aspects: economic feasibility, technical feasibility and social feasibility. The following illustrates the contents of these three aspects with practical cases.
The first is economic viability
Economic feasibility mainly determines cost and income two parts. Among the projects to be undertaken:
- Input cost: personal free time
- Limitations: There are no obvious limitations
- Benefits: Improvement of project control ability, overall design ability and coding ability.
- Bonus: You can practice your essay writing skills and even win prizes.
From the above items, it is worth the time and effort to do this project.
Technical feasibility
Here we first review the analysis of configuration software in the previous article:
Generally speaking, configuration software can be divided into three parts: drawing module, data processing module and data source. Between drawing module and data processing module, data is transmitted by fixed duplex protocol (such as WebSocket) to achieve data display and reverse control function. The data processing module is connected to the data source, and the processing module needs to support a variety of data transmission protocols (such as Modbus, MQTT and Restful Api) to receive data and send control instructions. The data source contains both the actual gateway, the group, and the open database. Through the processing module, real-time data or attributes uploaded by the device are also stored in an open database.
Therefore, in terms of technical research, we need to pay attention to the following two points:
The realization of drawing module
Similar to the two-dimensional web configuration drawing plug-in, the more famous are:
Plug-in name and vendor | evaluation |
---|---|
Configuration of graph software | The editing interface is professional and looks great, but there is no community open source version. The enterprise that does not need money or individual can consider doing a set |
le5le | Based on the Canvas. The official online editor is quite configuration friendly. The artboard core component is open source, and there are also official video tutorials to help you develop your own editor |
x6 | Based on SVG, produced by Ant Visualization team. Although the V1 version is stable, there are still some obvious issues that need to be resolved, and some advanced graphical interactions need to be compromised. React components are available for quick prototyping |
mxgraph | Based on SVG, see drawio for details. The editor interaction is the most comfortable with the open source version, and the basic drawing requirements are met. Unfortunately, the official open source version will stop updating around October 2020. Fortunately, the community has taken over the refactoring process, but it will be some time before a new version is released. |
It is worth noting that the latter two do not claim to support the configuration domain, but still support the needs of configuration software development.
Interfacing with multiple data transfer protocol drivers
Device-oriented: COMMON drivers such as MQTT, Modbus and OPC UA all have JavaScript versions. Basic functions can be met. Open storage: Node.js drivers for PG and Cassandra are also available.
Also, on GitHub, you can see a full-stack 2d configuration project: FUXA, which uses Angular + Node.js Express as the technology stack. Analysis of projects, whether front-end frameworks or data access drivers, is something front-end engineers understand.
Social feasibility
The main point here is the question of protocol. Currently, the open source versions of the libraries and frameworks mentioned above are under the MIT protocol, and there is no legal risk.
To sum up, there is no obvious risk in the development process of the project, and it is feasible to continue the development.
After determining the feasibility of the project, it is necessary to decompose the functions required by each module of the project in detail, estimate the workload of each module, and formulate a set of preliminary development plans. This will be covered in a follow-up article.
conclusion
In this issue we cover an important step before developing a software project: feasibility analysis. And according to the current project from the economic feasibility, technical feasibility and social feasibility of the analysis, and finally determine the feasibility of the project.
Subsequent articles will take a modular breakdown of the project as a whole and outline the development plan.
Thanks for watching and feel free to leave your thoughts in the comments section.