Chapter 4
[1]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.
References
Visible links
1.
https://translate.googleusercontent.com/translate_c?depth=1&hl=en&rurl=translate.google.com&sl=ru&tl=en&u=
http://drakon.pbworks.com/w/page-revisions/18205509/%25D0%2593%25D0%25BB%25D0%25B0%25D0%25B2%25D0%25B0%25204&usg=ALkJrhh4RSUm0BkVfR_Mc71EU43mma_saQ
