Drakon Book : Chapter 4 [English Translation]

Chapter 4

Page HistoryLast edited by PBworks 8 years, 7 months ago

UNDERSTANDING AND UNDERSTANDING -

KEY ISSUES OF INFORMATION

Understanding – the function of the mind, its main function …

Natalia Avtonomova

Lack of understanding LEADS TO millions in losses

The main requirement of the language is considered DRAGON relief and improvement of the mind, improving understandability, algorithms, programs and technological knowledge. To indicate this requirement, introduced the concept of “ultra-high understandability criterion.” It is believed that the language satisfies this criterion if written on its projects, algorithms, programs and technologies have the highest cognitive quality.

Let us recall the well-known facts is not so distant past. One of the leaders of IBM Joseph Fox said that in the early 1970s.two major airlines sue its contractors because they have created a data processing system worth 40 million. dollars. Not only did not work, but in general showed no signs of life. A major European bank has sent a lawsuit to recover 70 mln. USD., Paid for the software. Air Force United States has spent more than 300 million. Dollars. Futile attempt to automate complex system of transportation and logistics. Continuing the theme, Algirdas Avizhenis noted cases where complex and expensive systems have not been able to make of the fact that, within the deadlines and resources does not fix software bugs. John Musa points: operational and economic consequences of software errors are “truly awful”. The cause of all these “earth catastrophes” large programming projects tend to lay in the fact that the customer and performer quite differently understood the task. Roughly speaking, the client was hoping to get the system “about Thomas,” and artist made “about Eremu.”

These classic examples of large-scale failures, as well as many other facts, including the epidemic seemed incomprehensible failure of the project ACS 1 in our country although they have become part of history, nevertheless remains instructive to this day. The analysis in such incidents allows us to four conclusions:

  1. the success of a major project depends on the mutual understanding between its participants;
  2. to achieve mutual understanding, it takes weeks and months, and in severe cases – years of painstaking work together customer and performer;
  3. Understanding the problem can not be considered solved until now; mutual understanding – a heavy and complex intellectual work, the performance of which is extremely low;
  4. it would be highly desirable to formalize this work and dramatically increase productivity.

Mockery of common sense

CALLED “absolutely correct program”

In all these cases the system generated were subjected to scrutiny. The question arises: why is such a powerful tool as the tests revealed no gross errors in the software product?

The answer is clear. In the example described the beginning of the work was seemingly quite reasonable. Artist advance made and agreed with the customer multivolume document – the technical specification for development of software (the formal specification), and only then started to work: designing, programming and testing. Testing has shown that the program code has been unmistakable, and corresponded exactly to specifications. In short, the program was absolutely right.

The paradox is that the program is called proper if it meets the terms of reference. And if mistakes have managed to seep into the “holy of holies” – the task of designing the system? Here’s the crux of the matter! It turns out that testing – is not a panacea. In other words, testing programs, even the most meticulous nagging and in most cases in principle does not detect errors in specifications.

Program specification – are the main “gadyuchnik”!

Over time, it became clear that wearing “hats invisible” error in the specifications the most insidious and represent the main danger. They are virtually invulnerable to attack massed frontal tank testing. However, the most sensational was the conclusion that the preparation of specifications – one of the main sources of errors. It turned out that the elimination of errors in the requirements for the program takes an average of 82% of all effort spent on a team of developers fixing bugs project, while eliminating coding errors – 1%.

The errors in the specifications usually found only after the acceptance tests of the developed system. They “float like mines in the fairway at the stage of implementation and maintenance of the finished software product in the contracting authority” (G. Gromov, 1993).

Problem specifications – one central programming. James Martin writes: “Every now and then met the same sad story: after several years of intensive development of data end-users claim that this is not what they want … normal reaction to such a development a bad situation – the statement that the system requirements have not been adequately defined by the user.This is despite the fact that the system requirements are sometimes presented as many volumes of documentation. “

What is the cause of the error in the specifications? Let us consider the example of the development of automation of technological processes of nuclear power plant (NPP APCS). Customers (developers of nuclear power plants) are well aware of “physics of the process”, t. E. Technology works reactor and turbine units and other systems of nuclear power plants, but, unfortunately, are not part of the professors at ASU and programming. Artists (developers NPP APCS), contrast, detail familiar with computers, programming, features of building management systems, but, alas, there is little sense in the reactors, special water treatment and other nuclear secrets. Thus, the problem is that they both need to understand each other. To do so, mutual learning, mutual exchange of knowledge, which are usually presented in the form of one or other documentation. The success of peer education depends largely on the cognitive features used by professional language (knowledge representation). It is obvious that this is a very thin, delicate and complex cognitive problems in the first place, about the problem of understanding.

The analysis allows to make two observations:

  1. errors in specifications are one of the most difficult problems in the theory and practice of programming;
  2. unresolved the problem is related to the whole range of reasons, among which recently took underestimation cognitive problems and the lack of effective linguistic tools to facilitate and improve the work of the mind and solve the problem of understanding.

SPECIFICATIONS AND METHODOLOGY PROGRAMS RAD

The RAD methodology used a very original approach to the problem of specifications – something like “Smart in the mountain will not go, the clever mountain bypass.” In fact, why create labor-intensive paper specifications when in the presence of CASE -Instrument much easier to get a workable prototype of the system!

The new approach is closely related to the concept of “quality of software”. According to James Martin, before the majority of organizations use a bad definition of the term. They knew him as “the best possible match between the written specifications.” In the traditional approach the specification, signed by the user, frozen for the entire period as long as the design, coding and testing. This often led to the fact that changes in the specifications forbidden for a period of eighteen months, and was allowed only after the system starts to work. Of course, during this time the business requirements for the projected system time to change significantly, but to create a system completely ignored this fact! So that the customer was forced to start with a known system unsuitable, since it takes into account not all but only a part of its requirements, not to mention an error in the specifications caused by failures in the connection of the baseline requirements were inaccurate, and many have lost out of sight.

So it was. However, the methodology RAD gives a new definition of program quality, understanding it as “the greatest possible satisfaction of the true business requirements (user needs) at the time of submission of the running system to the customer.” To achieve this, we had to change a lot: dramatically increase the speed of development with the help of I-CASE-Instrument and, above all, radically improve relations between the developer and the user. If before the user “twisted arms”, forcing to sign the paper specifications that it is poorly understood, but now the situation has changed. After a short series of well-organized study of initial negotiations, the results are immediately entered into the computer, the developer quickly create a prototype of a computer system and immediately transmit it to the user. The latter, sitting at the computer, trying to project “to the tooth”, realizes his error and directs the developer feedback portion refinements. Developer rapidly changing prototype and then gives the user an improved version. This game of ping-pong between the developer and the user is repeated several times and leads to the fact that the prototype is gradually turning into a working system.

Main trick is that users no longer have to buy a pig in a poke and sign swarming bugs paper specification (understand where – beyond their powers). They put signature on the draft, obtained using tools I-CASE, which is fully accessible to their understanding and they can professionally evaluate. Thus, the user’s actions related to the control of the project, have the computer accuracy. Taking part in working out the project for a computer screen, the user is much deeper delve into the details than with speculative analysis paper specifications. The above method is sometimes called “early prototyping in spiral development cycle”, because the prototype is tested by the customer at every turn of the spiral, to reduce the likelihood of errors in the complete system.

There is no doubt that these are very useful innovations. However, we should not forget two things. Firstly, RAD – it is not shared, private and methodology, as it is not applicable to any system, but only to a certain class of systems (business applications). Secondly, along with the advantages RAD methodology has significant shortcomings. They are underestimating the importance of the problem of improving the work of the mind, problems of understanding and cognitive-ergonomic design approach of linguistic resources. Consequently, graphic and other means RAD have weaknesses and in need of improvement.

According to the author, the inability to understand and to prioritize the issue of improving the priority role of the mind and the problem is a general lack of understanding of many contemporary approaches to the creation of linguistic resources of design and programming.

CONCEPT OF COGNITIVE PROGRAMMING

When a new programming language, usually try to find a reasonable compromise between the various and often conflicting requirements, which, inter alia, include the following:

  1. ease of understanding of the program;
  2. the complexity of writing small programs;
  3. minimize the need for computer memory;
  4. a small run-time programs;
  5. small the broadcast;
  6. ease of automated error detection.

These requirements can be divided into two groups. Group cognitive requirements include ease of writing programs and the possibility of a quick and deep understanding. Machine requirements cover all the rest: the saving of machine resources, small and run-time translation software, and so on. D.

The development of language is based on the concept DRAGON cognitive programming, which is based on the following postulates.

Postulate 1. Cognitive language requirements are considered as basic machine – as secondary. Justification of a postulate is that today, when the speed of computers and the amount of memory has increased dramatically, and their unit cost decreased, the main problem is the low productivity of personnel in this improving the work of the mind, increasing the productivity of the human brain is the number one task.

Postulate 2. Ease of understanding programs – more important requirement than the convenience of their writing. According to J. Pyle, an opportunity to read the program and is clearly aware of its meaning is more important than the ability to concisely and quickly write it. The reason is a one-time performance of work by the author of the program and the need for repeated reading program during its life cycle 1. It is known that high readability software facilitates their support.

Postulate 3. When you create a language performance of cognitive and computer requirements should be carried out in two stages, using different means. In the first phase should focus on the implementation of the cognitive requirements and (reasonably) to ignore the issues of machine efficiency programs. With this approach, the use of language is guaranteed to lead to the creation of clear, but possibly ineffective programs. In the second phase (which may overlap in time with the first) must address engine efficiency programs, which should be used:

  1. optimizing compilers of the new generation;
  2. Automatic methods of improvement (optimization) programs allow conversion of inefficient, but it is clear to equivalent programs are more effective;
  3. methods of intellectualization of computers;
  4. improved performance computers to the borders, making massive operation inefficient (or partially ineffective) program is economically feasible, and even profitable;
  5. an introduction to the main language more opportunities, you can write individual pieces of programs in assembly language. This feature is used when the ineffectiveness of a program written in fixed assets language goes beyond reason.

The advantage of a two-step approach to the implementation of cognitive and computer requirements is that it allows you to ease the pressure on the requirements of machine language, making it easier development of language and allowing them to concentrate on the radical improvement of the properties of the language, on which depends the solution of the most important task – a radical increase staff productivity.

Thus, the paradigm of cognitive programming considering the criterion of improving the work of the mind and super understanding as the main requirement for the language (although, of course, in life there is always some exceptions possible).

CONCLUSIONS

  1. To solve the problem of understanding and reduce the economic losses caused by mutual misunderstanding between customers, developers and operators, it is necessary to accept the concept of cognitive programming and radically change the priorities in creating a new generation of languages.
  2. Today paramount requirement to facilitate and improve the work of the mind, to minimize the cost of intelligent staff spent on the creation and maintenance of software throughout the life cycle.
  3. Significant or even the major share intellectual efforts of staff in the development of complex projects is spent on the process of cognition, perception and understanding of the information. Therefore, the requirement cognizability projects and algorithms and the associated test ultra high understandability become decisive.

Leave a comment

Your email address will not be published. Required fields are marked *


7 − one =

Leave a Reply