A little about “ashipki” in software and the help of the theory of the finite state machine

When working in the IT field, willy-nilly, you notice a huge number of errors in various software. Whether it’s the mistakes of Microsoft’s world vendors, or in 1C’s applied business solutions, or in Apple’s praised Apple with a children's fatal error “January 1, 1970”. What can we say about small companies with a small staff of programmers?

How software errors are a natural process? Let's figure it out. Everything below is solely the author's opinion, including classification, the possibility of applying the theory of a finite automaton, observation.

Not so long ago, Samsung announced the launch of the Samsung Pay service, and having Samsung Gear 3 watches opened up new mischief for me - to pay for purchases with a touch of watches to the terminal. I do not know what difficulties occurred during the production of the product, but the first versions of the program did not allow me to adjust. Only with the release of several releases I was able to use the service.

All manufacturers make mistakes in the field of software, no matter how large and certified they are.

The mental work of programmers constantly requires innovations. They must apply modern technology in order to provide the business idea of ​​investors and dreamers. Information and technologies become obsolete very quickly and therefore the programmer needs to be at the forefront, as if the pioneer researcher to overcome thickets in the taiga, arid deserts, and ice hummocks.

How many researchers have killed in an attempt to go through difficult routes: G. Sedov, R. Scott, V. Bering ... What am I talking about?

The programmer works with new, not beaten technology, in which it is easy to make mistakes. The bugs are in the supplied modules of external developers, and in their use in their own software.

Errors and Theory of the State Machine

Let's turn to the theory of finite automata. At one time, the institute had to apply this methodology both in the programming of controllers and in the construction of control systems.

But what if on the basis of the theory to show the complexity of software development and the ease of the occurrence of errors. For example, setting an applied task is to implement an automatic transition to statuses in the buyer's order.

Imagine a standard graph of the state machine of a manufacturing enterprise with the states:
')

• Payment
• To production
• In production
• Is done
• Completed

State machine events:

• a - set by the manager after confirmation by the buyer;
• b - set by the head of production, assessing production capacity and the ability to perform;
• c - set by the warehouse worker at the time of receipt at the warehouse;
• d - set by the manager upon receipt of money and transfer of cargo;
• e - set by the manager manually.

A trivial process is described. In the competition, it is necessary to use all modern capabilities and, of course, sending an SMS to the customer would be a good plus, and, perhaps, already a duty. And as you remember, the original task is to automate the process. For example, a loader accepts a manufactured product using a barcode scanner, and the system sends sms to the buyer: “Done, come.”

This is a common task, but for the designer, many nuances are hidden here. For example, produced products, and some turned out to be a marriage. What state should be? Have you taken into account? The customer came to buy, but during the inspection he decided to abandon part of the product - is it completed or canceled? By mistake, the order was canceled, but it must be returned to production.

We do not consider difficult examples when there can be a groupage load, a lot of storage places and many states, but in this simple task many software designers make mistakes. Any automation requires an analytical approach - to work out transitions that the task director doesn’t guess. In real life, the number of transitions for the above process is much higher.


The more functional the software, the more errors. The tester helps, but not always - he is not familiar with the subject area as the designer.

I have determined for myself that the construction of a status graph based on the theory of a finite automaton makes it possible to have a volume look at the problem being solved.

I remember that the Finance Director turned to me with a request to develop a system for depreming employees. Accounting orders of all employees was carried out in 1C: Document Management (DL), accounting of working time in 1C: Manufacturing Enterprise Management (UPP). If an employee has delayed an important task, then he was deprived of bonuses by X%. To do this, we check the time of the completion of the task in the DL, we obtain the employee's data on the time sheet from the SCP and determine the place with a comma in “Execute cannot be pardoned”.

Well, but the number of transitions between states (according to the theory of limiting systems) has increased so much that we had to respond to dozens of unplanned scenarios, according to which the depremiration system becomes inoperative. For example:



The temptation to introduce such a system was great, because the more employees wage wages from employees, the better it will buy a car for New Year holidays based on the results of the year. Therefore, for the implementation of this task, dozens of improvements 1C were made taking into account all the transitions.

Software testing procedure has long been debugged and standardized. But mass products are still constantly releasing bug fixes. Examples:

• Wordpress

• 1C: Integrated Automation 2

Is it possible to release Functional Software without errors? No, such cases were not observed.

The relationship of economics and technical knowledge in the field of error

Is it possible to minimize errors? Definitely. Their number nonlinearly decreases, according to the time spent on their search and elimination. Time means costs. There are 2 reasons to improve the search for errors - the loss of economic effect on further search and the loss of technical knowledge to eliminate them.



Ideally, they are located side by side on the "required resources" axis. This means harmony between the economic model of your business and the quality of your software.

For example, the task is to develop software for the onboard computer of the new aircraft. Considering the enormous number of parameters and functions in the physics of flight, one cannot allow the software debugging to be stopped due to loss of funding. The result will be sad.

If the point of "loss of technical knowledge" comes much earlier, then it is necessary to raise the quality standards and the professionalism of the developers.

With all this, there will be “ninja mistakes” that will disappear from all tests and will only be discovered by users.

Weight errors

The weight of each error is different. In general, I divide them into 4 types.

Critical error. Stops a business (for accounting systems), equipment, service. Such errors should not be. The presence of such "bugs" indicates a weak technical side of the developer (including testing methods).

For example, I downloaded an actively promoted program on the Google Play Store. Immediately upon startup, an error occurred.



Important Irresistible Mistake

This does not stop the work, but leads to an inaccurate result that cannot be corrected manually by the user.

I laid a route to the city of Podolsk. In one area, the navigator made a very strange route (it does not drive around traffic jams, there is no repair or overlap of the road). This error is not critical and I can continue to use the program, but there are no changes to make.



Important avoidable error

For example, the calculation of cost in business is extremely important, but difficult because of the solution of a multidimensional system of equations with many unknowns. Errors occur, including, as stated above, in the vendor modules supplied.

The cost calculation gives only the final result, which is based on a series of previous calculations, and if an error occurs at some iteration, the result will be incorrect.



The program 1C was derived such an error in the calculation of cost. The user could (of course, through experimentation) eliminate it - re-translate the documents. In the stated possibilities of the method of the RAUSE, it is not necessary to do this, but not in practice.

Remarks

This is all the rest. For example, a message comes to me from Good-natured, and the link is broken. We immediately see that the testing was not conducted.

Analysis of your mistakes as a summary

Remembering all my mistakes as a programmer and project manager, I can single out the following reasons for their appearance:

• The problem is said and heard. How to remember the projections of the cylinder, where one circle and another rectangle. As a result, we are talking about one requirement, but we understand it differently.
• Limit the depth of thinking. Each person has his own level and if the further deepening is not formalized (do not take notes on the slip or in the program code), then you can get into a functional break.
• Not giving importance to the code element. Wrote, and did not even doubt that this is wrong. In the best case, this results in a non-optimal code.
• Incomplete knowledge of feature development tools. Although we were taught that the task of the engineer is to work with reference documentation, experience helps to minimize communication with the book.