Skip to content

The Solution

Gordon Moore predicted in 1965 that hardware complexity would double every 1–2 years. He was right up to today. At the same time, software engineering methods have not significantly increased programming productivity. The gap between hardware complexity and software efficiency is growing irresistibly, and the consequences are alarming.

complexity

The Productivity Gap

  • excellent hardware, but worrying about the software?
  • thinking about outsourcing software development?
  • wondering if the size of your software development team is not proportional to the size of your (hardware) company?
  • starting a new project and wanting to see if it is possible to increase software development and maintenance efficiency by more than 50%?

You know how unreliable software for everyday use can be. For instance, editors from large companies are first tested by thousands of beta testers and later by millions of users, and they still fail. Do you think that this unreliable software is written by weak programmers? No, it is written by very good programmers—large companies can afford them.

Now compare this with the situation in your company, where you write custom-tailored software. Do you have any chance to test it as intensively as mass-market products? Of course not—your software is always an unreliable prototype. You have no hope of writing good, reliable software unless you make a radical change to your method.

You will be surprised to read a Lucent (AT&T) report on how successful software development can be when using the engineering methods we introduce.

For more information, refer to References.

Users of StateWORKS benefit from an enormous cost reduction in their software development compared with competitors using conventional methods. The three major advantages of using StateWORKS are:

  • design efficiency increased by well over 50%
  • almost total elimination of software errors
  • tremendous reduction in maintenance effort

Further side effects include greater transparency in software design and reduced dependence on so-called “key programmers”.

StateWORKS is a software design and execution environment. The design environment consists of a set of tools such as editors, simulators, etc. The execution environment is a library (RTDB) that you link with your StateWORKS specification. The library can be provided for any common operating system.

While the execution environment concept is fairly common, the technology inside it, as well as the design environment, is unique: StateWORKS is the first commercial implementation of VFSM, the next generation of application development methods. The VFSM method is based on the theory of finite state machines (FSM), but with the addition of significant new elements.

We must stress that the method proposed is not merely another way of programming finite state machines embedded in other software for certain applications—or parts of applications—that could obviously use them. We are proposing a major rethinking of the way software is designed, in which most of the usual “control-flow” coding is avoided, and the state machine concept is pushed much further than before to take a predominant role in the design process.

In this way, the designer is helped to create truly exact specifications of the behavior of their software, using tools that tend to bring subtle problems to the surface, to be resolved in discussions with users or whoever can determine what should be done, and defined at the state machine level rather than being discovered later during coding.

For more information, refer to What is StateWORKS?

The following figure shows the StateWORKS components:

multi-component

StateWORKS Components

You need one development environment (StateWORKS Studio) for each of your software engineers. There, you design and test your software specification. The final specification can be run by the executor, which is your application containing the generated specification code, the StateWORKS library (RTDB), your I/O interfaces, and special functions. Using our monitoring tools—or your own—the running system can be controlled.

Differences between StateWORKS and other approaches

Section titled “Differences between StateWORKS and other approaches”

There are vital differences between StateWORKS and other “similar” approaches. The similarity is limited to the names: State and State Machine. StateWORKS is not merely a simple software development tool.

  • StateWORKS is used to develop the precise specification of behavior in your project so that it leaves no scope for later decisions in a coding phase. It covers the entire spectrum—from establishing general high-level specifications (as in UML) to the production of run-time software—in one seamless process.
  • StateWORKS is a true implementation of a run-time-executable specification.