Pegasus original idea came up against some specific characteristics found in some IBM development environments:
. the analyst did not always know programming;
Today, the analyst has regular training courses, or at least, technical analysis courses that, in one way or another, supply the tools used in this task, but do not go deeper into the environment in which they will be employed;
. the analyst did not know the analysis;
In some IBM environments, especially in large institutions, analysts are trained with the routine of work and are usually “promoted” from some other function to the ranks of programming;
. the programmer did not always understand what the analyst specified;
In some IBM environments it is common to have extremely competent programmers, “glazed” in code, but without the necessary language to communicate with the analysis;
. one programmer does may not solve the same problem in the same way as another;
Creativity is an innate potential in human beings.
In short: it was not always known what to specify to solve a problem and it was not always known what was being specified, due to the large misunderstanding concepts and logical schemes. In principle, the solution to a communication language problem would be joint training, or at the very least, informing both teams what to talk about and what to understand - ethernal problem of transmitter and receiver with truncated languages. It happens that, in practice, we would always include a cost and a deadline to tell both teams in which language to communicate, and sometimes may not be possible to keep the two together without creating any kind of “hierarchy” problem _ there are honorable exceptions _ with the objective of maintaining or raising quality within the intended scope.
The most common view about systems that I found in large environments was the “procedure”: practically all high-level programming analysts think in terms of procedures and jobs, which means that the analysis is linear and, thanks to the amount of system utilities, it is not always a logical or intelligent linearity: at most they are a jumble of steps, redundant or irrational, sometimes.
By definition, a system is a specific view of the whole. In this sense, norms originating from support, for example, sometimes hinder development, reducing the very notion of a system: it is not uncommon to find meaningless impositions in the name of presumed, but not effective, security. (the project involves risks, but the security risk is overcome with the appropriate qualification of those who will create or use a system). Most of the time there is fabulous equipment, an operating system that is known to be functional, flexible and with many resources, badly used because of almost always ridiculous rules originated by disputes between departments, when they should come from the management of the departments. But this is another story ( and a personal specific vision ).
Physically surrounded, without the vision of what a system is, working with repetition of formulas, not always in an intelligent way, the analysis in large systems needed some help. At first, the objective was to correct the problems:
. Analysis without programming;
. Correction of “procedures” before their effective execution;
. Make it possible to verify the approach to the problem, in order to verify compliance with that specific scope.
These three objectives are achieved with:
. A code generator;
. A simulator of routine activities
. Verification of the phases of these activities
This was the initial proposal of Pegasus - today in a version named System Design: just a sequencer of activities, simulable, with a code generation at the end, designed to solve specific problems in the definition of programs. Code is the final object - without taking away the creativity of programmers, who can, in any way, interfere or evolve the proposed codes. The fundamental thing was the logical sequence to reach the solution, and this was supplied by designing a state machine, with the capacity for simulation. Roughly speaking, we would also be introducing UML in large environments, through activity diagrams, even if customized as sequences of operations.
At this point the problem found was the choice of an intermediate language that was understandable to the analyst, to focus the definition of the problem in a clear way. The possible choices would be: a graphics language, a flowchart, or an object-oriented language that approached structured Portuguese/English or pseudo-code. A graphic-only language would bring problems of understanding and prevent the introduction of specific elements of a solution. A flowchart would go back a few "centuries" in the analysis, in addition to which the flow of operations was already part of the system. A language close to the pseudo-code, widely disseminated and accessible was the choice: using object-pascal for the intermediate code, few operations would be difficult for the analyst to understand, that is, the clarity of the definition would be transferred directly to the code, most of the time. Since object-pascal is intermediate code, suitable translators for other languages would be needed.
The next idea was a consequence of the analysis activity itself: if the more specific problem had been solved, why not replicate the solution to higher levels, in the solution, and determine a system _ as it is known in the some IBM environment _ consisting of programs ? Even in this case, as we all know, the sequence and activity diagrams are sufficient and that is what we have included in Pegasus.
We then had a tool that could be used to analyze a problem, from its highest level, down to the details, which was simulable. This idea, however, although sufficient to determine a solution already determined, was not sufficient to determine its viability in terms of costs and deadlines. We guaranteed the quality and scope of the “system” solution, but there were two variables to satisfy formally - informally they were being satisfied by eliminating the “negotiation” between analyst and programmer. The theory says that the only way to decide with certainty on a certain topic is simulation. And the most common technique for the simulation is the use of discrete events. And this was our next step: to create an upper layer, at the level of processes, in which we could have deadlines and costs, provable through the proper simulation.
So far, everything seemed to be under control, on the theory side. The implementation of the theory, however, required some additional activity in the Windows environment, such as the creation of interactive panels with the user, capable of both design and simulation - a technology that few technicians have, often sold at a premium. Once the technology was obtained, however - technical detail - we had the upper layer of systems and programs: the business, detailed in processes that expanded into sequences of activities and generated code at the end. With this, we had the transition between the business and the system, often a painful phase in implementations.
But, detail, how to determine, for example, the values and deadlines in some process, when they did not originate, for example, from the personnel department _ a monthly salary _ or from the dispatch sector _ the time to pack some goods? The obvious solution would be to employ a metric system and we did it from Function Point Analysys. We can play with the metric because, once we have a code as a result of a process - we are going to simplify the operation of the software - we can scale its value, which allows us to retroact with the higher level, and adjust the values of the processes.
Technically, Pegasus is a productivity tool, but not a tool aimed at consulting services, because it either eliminates labor costs, or reduces them for the end user in some way. On the other hand, from the systems point of view, the analyst has the possibility to reach the customer with his laptop, put the tool in execution, as he surveys the system and outlines it in diagrams of activities, according to your understanding, and conclude your interview with the client by simulating the survey made, checking their logical flaws or omissions. From the business point of view, the analyst would act in the same way, raising the processes, costs, etc., also with the possibility of immediately checking with the client, disparities, bottlenecks, etc.
Thanks for the visit.
Follow are some pictures from Pegasus working ( the real application name was changing
with the time, to facilitate their maintainance ):
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
