Advice and tips

Golden Rules for methodical software development with graphical programming software

A maximum of self-documenting structures is developed because there always is a connection to the specific application context.

Use as many information from the functional specifications as possible. If there are strong diagrams or block diagrams with significant symbols, try to use those diagrams and symbols in the graphical programming system again.

Tip: Application-specific symbols have high implicit information content. You should take the time to use those symbols in the graphical programming system. When you have to change the software some years later, you will appreciate each and every information that you can get.

In the present HDA 10 project, the functional specifications were ideal preconditions to apply the golden rule. The diagrams reflect the context of the application perfectly. Furthermore the diagrams support the application of the top-down draft procedure.

Right use of the software resource

The development and maintenance of technical systems is in a change, as embedding micro processing units is getting more and more complex. Role models rarely exist in that extent. Classic engineering disciplines like machine engineering, process engineering and electrical engineering are confronted with the individualized world of software development because of growing development and quality standards. While in classic engineering science a high attention for documenting ideas, processes, constructions or formulas is payed, many companies are quite careless about documentation, when it comes to the carefully developed software solutions. However, it has commonly been known for a long time that the added value potential of technical systems is determined by the efficiency of the software development.

Even though many projects fail because of software problems, the value of good software solutions is barely recognized and is not documented well enough because of high time and project pressure, so the software cannot be reused.

While process technicians, electrical engineers and machine builders had many years to agree on defined interfaces, software solutions are now rapidly replacing slowly grown development processes. However, software projects are often realized without the basic principles or methodical proceedings. Especially in the sensitive area of embedded systems, some companies are characterized by individual, tricky solo programming. The reason for that is rather the missing tools than the missing awareness of the problem. In machine and plant engineering the hardware solutions are assembled from cataloged, CAD-supported standard modules and special developments are only made for specific parts. In software development, however, it could happen that the same functions are programmed multiple times, as a useful cataloging and presentation of the developed software functions is missing. Flexibility and individuality are indeed two reasons for the successful implementation of software in almost all technical areas, but they are an enormous challenge for mastering the systems as well. Never before has a technology affected other technological disciplines as deeply and profound.

To see technical software as valuable goods and to develop and document it accordingly and responsibly will be one of the most important competition criteria of the future.