Adriano Autino

Technologies of the Frontier - Andromeda s.r.l.
http://www.tdf.it - http://www.andromeda-srl.com

This paper doesn't aim to treat the theme of Quality in an abstract way, mainly from a metaphysical or philosophical point of view. Nevertheless in this paragraph, as necessary premise, I really tried to frame the problem philosophically, and also ethically. I hold besides rightful to specify that, although the paper contains some critical signs towards the standards of Quality (particularly the ECSSs), the author has not performed a general study of the standards with the objective to comment them in an organic and complete way. Neither, after all, a similar treatment could be complete in the brief space of this paper.

The dissertations around the theme of Quality have very ancient origins. The same concept of Tao seems to have many points in common with the one of Quality. "The Tao Tê Ching" of Lao Tzu[1] (2400 years ago), gives a very poetic and deep definition of it. The first conceptualization of Quality applied to (war) industry reascends to '930, in the United States, by William Edwards Deming[2], which in '950 went to Japan. There the elaboration (by Ishikawa Kaoru[3] and Taguchi Genichi[4]) went well over his original nucleus of ideas. In '980 the Total Quality came (or it came back) to the West, from Japan, initially as a method to minimize the wastes and to improve the production yield. There the evolution of the methodological standards of Quality started, up to the today's conception of Quality of the project and production processes.

If however we want an higher and wider treatment of the Quality theme, we shall study the work of Robert M. Pirsig, an American anthropologist, of German origin. Beginning in early '970, and for the following 20 years and more, Pirsig works around the problem of a Metaphysics of Quality, and deliveries to the world two splendid philosophical novels "Zen and the Art of Motorcycle Maintenance"[5], and then "Lila, an Inquiry into Morals"[6]. By a hard personal suffering (he risked his own mental health, and was interned, for a period, in a menthal hospital), Pirsig crosses the mined fields of the western dualism (mind-subject, subject-object, romanticism-classicism, function-emotion, etc.), he disproves the science' rationalistic substantialism, and succeeds in holding elusive and fleeing categories as the intuition and the illumination in the correct account, without falling in mysticism neither in fatalism. Through such path he reachs to an extremely advanced and mature definition of Quality. Quality cannot be defined in a subject-object logic. Quality finds a possibility of definition (and of measure, I add) only connecting objects - in the largest meaning, including both the natural environments and the technological, artistic, or of any nature, constructions - with the schemes of values of the subjects, in their evolutionary becoming: inorganic - biological - social -- intellectual. Pirsig traces interesting links of paternity among such post-modern (in the sense that it tries to look over the Industrial Age and the philosophy of the purely rationalist science, that excludes the concept of value because too subjective) concept of Quality and the aretè of the pre-Aristotelian Greek Sophists. And between this and the Indian dharma. Pirsig uses such concepts as real staminal cells of philosophy - reascending to the age in which the biological level gave birth (with pain) to the first social organization - in order to recover the Value as a founding category, first and last meaning of Quality.

Introducing the concept of value in the equation, Quality comes to include, besides the scientific meter and the technological one, also the (pre-rational and pre-cognitive) intuitive emotion, and a deep moral connotation. By the moral confrontation among the different evolutionary levels (biological vs. inorganic, social vs. biological, intellectual vs. social), we can draw an idea of the ethical code evolution, up to reach the highest code (at least for our current knowledge): the code coming from the confrontation between the Dynamic Quality and the Static Quality. I.e. the freedom from any static code, which allows and stimulates the continuous rising of Dynamic Quality vectors, without that this implicates the destruction of the static codes, when they are still useful.

Science, by its rationalist and substantialist setup, held the concept of value out of the scientific reasoning for a long time. Submitted to a continuous process by regressive and obscurantist powers, today Science is forced to discuss about Ethics and even about Transcendence[7]. But seeing Quality from the point of view of values, it leads to a fully new perspective. We are also brought to fully understand why any concept of Quality is inseparable from the one of Requirement, at least as far as the technological projects are concerned. The concept of requirement is therefore prevailing in a large majority of cases, even if it loses relevance in a context of pure scientific research, where the experiment has to confirm or deny some hypotheses (generally fruit of observation and intuition only). Or in the artistic field, where both the artist and the customer are free to advance themselves in the creation (or in the enjoyment of it), having no other baggage than their own emotion, and without being forced to preventively define the things they tried to enjoy, to show or to create.

The interesting theme, here to me, is in general the Quality of the Space Systems, and of the Astronautic Systems particularly. To be more specific: the proper systems to support the human space flight and the human survival outside of our native planet. For extension, the same requirement can be applied to terrestrial systems, suitable to support human life, our moves on this planet, life in (until today) uninhabitable areas. In last analysis, what I find interesting, it is the Quality of the systems for the survival and continuation of the Human Civilization' development. Human Civilization will not survive another century, if it will not give life, in the next 50 years, to a baby Solar Civilization[8]. The space technologies and systems are essential for such goal, ethically higher to any other goal that humans are able to set. In the case of the Space Systems, the inseparable tie among Quality and Ethics is even more evident. Such tie finds substance in a series of well precise requirements. The Space Systems Quality should not set or to give priority to low critical goals, until when the highest critical goals were not acquired, or until when an abundance of resources and time would not free us from the necessity of priority choices.

The Space Systems customer highest-level requirements can be reassumed in few lines:

• Space Systems shall allow Mankind to establish as soon as possible self-maintaining bases outside of its birth planet.

• Space Systems shall be sure enough not to put in danger the human life in space, not more than it was in danger on the terrestrial surface.

• Space Systems shall not cost so much to prevent, by facts, the development of a true Space Economy in short time.

So framed the general requirements of the Space Systems Quality, it is clear that any condition or recommendation leading to invalidate one or more of such requirements is to be considered not conforming to the methodological standard, and it should be overcomed.

One could then start re-analyzing the whole politics of the Space Agencies and the Space Community's deal, to verify its conformity to the above listed requirements. But it would take too much time, and it is not the goal of this paper. It's enough to observe, here, that it is very difficult to find mention of the above listed requirements, in the mission statements of the Space Agencies and of the Corporations dealing in the aerospace market. This means that the problem of Quality is faced, yes, but quite a lot levels below the level of the strategic decisions and of the great general development addresses. The big bosses ask us technicians to work accordingly to standard Quality Methodologies, but they probably never set themselves the problem to compare their deal with some general customer requirements as the ones listed above.

Here therefore we can well find ourselves in quite a lot contradictory situations. We could have given and to keep on giving priority to the development of technologies quite not functional to R1. For instance it is believed that the most important objectives of the space programs are "to improve the life on Earth", "to explore the Cosmos", or to bring beautiful documentaries back home, to enjoy comfortably sat on our armchairs. And not the primary objective to bring us to live out there, on other celestial bodies, so drastically reducing the probabilities of extinction of our kind and civilization by asteroid impacts, ecological disasters or other. As far as R2 is concerned (Safety), this is perhaps the overall more respected requirement, despite what the large public opinion could think, after the recent tragedy of Columbia. On the matter an ample discussion[9] was developed, and I don't aim to re-take it here. I just would observe that I don't hold reasonable to require to the spacecrafts a degree of safety higher than the one usually demanded to the line aircrafts, to the trains, and to the other ground transport systems. Why should it be more execrable to die on a shuttle, trying to widen the boundaries of our world, rather than to die falling with the airplane or in an car accident? Obviously, out of the provocation, the Safety requirements of the terrestrial vehicles and their use and maintenance are insufficient, and should be raised to the peer of the space ones, and not the contrary indeed! But a very diffused, philosophically false and ethically misleading conviction exists: that we are sure on our planet, and that we owe to think well before risking outside. We are not sure at all: we live on a grain of dust in the middle of a boundless universe. We will be very much surer (at least as a kind and as a civilization) when we will live at least on three or four grains! For such highly ethical objective, for the future of our children and nephews (besides for a honest profit), it is worth to risk, out there in the space, our lives of individuals. If we consider R3 (the cost), this is certainly the most violated requirement. Considering R3 together with R1, we have to observe that the reality of the space programs is a disaster: we develop expensive and mainly useless technologies. More: the Quality Methodologies (or perhaps the still scarce intelligence in appling them) have a notable responsibility in maintaining high the cost of space technologies. We have therefore a sound case of bad requirements traceability: if we tried to develop the father-child relationships from R1, R2 and R3 (as fathers) up to the children ECSS, or Vision 2000 requirements, passing through the Statements Of Work of the different ESA or NASA programs, we would find a tide of broken links, or impossible to trace ones. In other words: the detailed requirements completely contradict the father requirements. It is diffused opinion that the application of Quality Methodologies double the development time (and therefore the cost) of a technological project. For the goals of R3, such weight is intolerable, and it is necessary to do immediately something to recover such situation. Naturally something should also be made to realign the space programs to R1, but such a problem lays well beyond the capabilities of Quality Methodologies. While to bring the methodological standards not to weigh anymore so much on the projects economy appears instead a very much more affordable and technically resolvable objective, for us softwarists. This would contribute to bring the Space Programs to be more conforming to R3. The start of a true Space Economy, that could follow it, would then have a great influence also on R1.

Can an absolute methodology exist, self-motivating and targeted to itself? Absolutely no. Quality cannot be favorite neither increased by a system of absolute, self-motivating and self-sufficient rules, though the standards-makers probably often cradled themselves in such illusion. According to such a false conception, it would be enough to apply the standard procedures (more and more divided for each design and engineering branch) to have a perfect product in output. They almost comes to consider the creative engineering intelligence an annoying, even harmful, surplus, because susceptible to introduce sand into the delicate mechanisms of the Quality Procedures.

Such conception is fully false: the Quality handbook is not a kind of absolute and omniscient Bible, to slavishly apply in any case (as Soviet bureaucracy pretended to be the notorious "GOST").

Methodology owes:

• being finalized to the single project or class of projects/products;

• being punctually re-validated, according to the Customer specific requirements, eliminating any procedural element totally or partially opposing them (in case of conflict - I mean a true conflict, and not fruit of self-targeted competitions - the specific requirement, and not the standard, shall surely win);

• being remodeled every time, on the degree of real citicality of the single systems to be developed, as far as Safety and Reliability are concerned;

• taking in due account some categories little contemplated (when not fully denied) by the standards: the discarded requirements, the not implemented ones, the destructive criticisms, the irreducible concepts (which cannot enter the setup classification system).

For instance, only the project team, basing upon the specific reliability and safety requirements, can decide whether it is the case to apply this or that technique, FMECA, Hazard Analysis or none. Whether to focus on fault tolerance, on redundance or fault avoidance, etc. And only the project team can decide how many levels of integration test are necessary.

Can methodology really defend us from superficiality and from mental idleness? Also here the answer can only be decidedly negative. Quality Methodologies are on the scene since '980, and their systematic application growth up for more than 20 years. Nevertheless the mission disasters and the failures keep on occurring, in defiance to any dream of omnipotence of the standards producers.

The missed punctual re-examination of the procedures courts the disaster, exactly as the bad or insufficient application of the methodologies or the excessive trust in the experimented procedures. The fact that, by now, for each project phase, proper standard procedures and check lists exists, doesn't mean that such procedures are complete and correct, neither that they were always and fully surely applied. It is a tragic error, already many times paid by an unacceptable price of human lives, to hold an excessive trust in computer technology and in procedures, to fully trust to an intelligence "other", versus to the human one. In order that the other intelligence (the electronic one) was reliable, the human intelligence shall program it, check it, and correct the errors.

The procedures must systematically and continually be checked, re-verified and upgraded, by the designers, by the process technologists and by the users, in a work of continuous re-examination that can never be omitted, and never we should fully entrust ourselves to the procedures. Some examples of the above are unfortunately recent history: the disaster of Arian 5 bringing Cluster to orbit, the inquiry said it was due to the slavish application of the Arian 4 test procedures, considered safe, because tested more times. They were sure, certainly, for the included test cases. But unfortunately they were lacking of a series of tests of many new sensors, that Arian 5 owns, vs. Arian 4. Thus the on-board software was not tested on the receipt of data from the new sensors and, when such data started to arrive, the software considered them a failure symptom, and ordered therefore the self-destruction of the vector, to avoid relapses on inhabited areas.

The heaviest limit of the Quality Methodologies was the one to only insist on the aspects of standardization and re-use, without entering the worth of how the product shall be developed, to be conforming to its customer requirements (Functional, Quality, Reliability, Availability, Safety, etc...). Limiting my examples to the software development (subject that I know), there are obviously a lot of aspects in which a Quality Methodology could and would owe to stick its nose into. An example among so many possible:

• Should the automation software be developed prioritily paying attention to languages (expert of language, programmer style), or to functions (process control expert, automation softwarist style)?

• How should the source code be documented? Should the comments be oriented to functions or should they be cryptic notes of the programmer?

• The system architecture and the structure of the programs should be oriented to functions or to languages?

Who knows a bit the problem knows that very different products can derive from the above different setups, though all properly working. The function-oriented software is easy to maintain and test, also after years. To put hands in the language-oriented software, even the author proceeds through reverse engineering, after only few months, it doesn't matter if a documentation big like the British Encyclopedia was written. While for the function-oriented software a very smaller and functional documentation is enough: generally the Architectural Design and a well commented source listing. The function-oriented software is therefore very much preferable:

• it costs less in terms of documentation;
• it is more easily testable;
• it is more easily maintainable.

Well, ISO 9000 didn't enter the worth of all this. It only recommended (i) to create a Quality handbook, describing the project process; (ii) to always follow the same process.

The Quality Methodologies had the tendency to suppress any sprout of dynamic Quality, favoring the freeze of the static Quality elements.

A good Quality handbook, we should nowadays have understood it, after beating our nose so many times, should contain enough attention to Dynamic Quality, or it should offer suggestions and recommendations (more than rules) to leave dynamically breathe the project teams: phases of consolidation of the reached results (Static Quality) and phases of opening and improvement of the methodology (dynamic Quality).

It is also necessary to bear well in mind that such process is not very much adjustable for decree: generally, where true people exist, competition exists, there are likings and antipathies, feelings, triumphs and defeats, abandonments, disappointments and discontinuity. And sometime progressive solutions come really from where we less expect for them. Can a Quality handbook include all the richness, the complexity and the multiplicity of the stories and of the human relationships? Evidently not! But let's bear in mind, instead, that the project management cannot pretend that the human relationships don't exist, or try to suppress or to cage them: nor good science, neither good technology can exist without human feelings and values!

Also, we can observe that the standards are mainly produced by standards experts, surely qualified as to the standards matter. But these people cannot, of course, deeply really know the practice of each branch of the technologic engineering. As it was several times observed, for instance, the know-how regarding the automation systems (design, development and commissioning) is not so common. And surely it is so for any engineering branch. The only reasonable recommendation, for the standards makers, is the following one: before stating your "truths", please be sure to have involved the proper number and kinds of real experts of the different specific branchs, to collaborate with their experience and skills!

Speaking of the inherent danger in a "monkey" application of procedures, I wrote, in an article published on Technologies of Frontier in 2000 ("An analogical and human Millennium is born"[10]):

"Neither is allowed to close the complexity in a procedure, as a kind of black-box to be re-used without making again the analysis"?"the re-use of well tested software can be useful, provided that the designer (i.e. the human) re-analyzes, punctually and in detailed way, the applicability in the new case, and identifies with sureness the new parts to be added. The same concepts applies to the procedure: to keep the procedure from a previous experience is useful because it allows us not to re-invent all the steps of development and test to be executed in the new case. But anyway we shall re-analyze the procedure, punctually and in detailed way, in order to see which steps we shall add, due to the specific complexity of the new system. It will never be possible thus (as ranks of bureaucrats greedy and lacking of fantasy hope) to give a tested procedure in the hands of a novice (slave of the machine) and to wash one's hands of it: the irreplaceable contribute of an expert human is needed, and also of novice humans, specifically educated by expert humans. The machine will be our faithful and efficient servant, if we will be able to consider it so, and not to attribute to it powers and know-how's that it will never have."

And in another article of the same period ("Lost Spacecrafts and Earthquakes"[11]):

"As far as technology and safety are concerned, it is relevant to observe that the income of electronics and informatics, that determined a formidable jump ahead of the space exploration, is nowadays showing some worrying corollary, not so difficult to restrain, provided we are able to detect and analyze them. Electronics, and even more informatics, brought the automated systems (not only in the space field) to a high degree of flexibility, unimaginable in the previous mechanic age. Such evolution determined a dizzy increase of the freedom degrees for the designers: since the design errors are much more correctable, the mind of the designer is much freer to address to the scientific aspects. He can more and more to allow himself to design a system in the abstract, leaving apart the technicalities and details, which can be solved later, at procedural level, by systematically applying the Quality and safety design methodologies."

Really excellent indeed, but the number of failures and bankrupt missions seems even increased, in comparison to a couple of decades back.

"The fact that, thanks to the informatic technologies, the errors became correctable, it doesn't mean that they are surely corrected. It is still our human task to correct them, taking in consideration all the things that any electronic intelligence, though evolved, is not (and will never be) able to take into account. Though powerful and quick, the machine executes in facts nothing more (and sometimes nothing less) than what our fantasy was able to program inside it. And, as to the methodology, the fact that nowadays standard procedures and checklists exist, for each project phases, doesn't mean that such procedures are complete and correct, and that they are always and surely completely applied. The error is, likely, to place too much confidence both in the technologies and in the methodologies. All this ended to determine a real cultural mutation: a tremendous loss of human active attention, by the side of the designers, in checking and re-checking scientifically, i.e. applying the galilean principles of the scientific experimentation (taking nothing for granted) to their project acting. Scientific method training and humanist training (i.e. able to transmit to the young's the huge value of the human being): these two categories are a little bit lacking in our school programs, maybe also, in part, due to a mistaken primacy of the technology over the science."

Every time that we fully submit ourselves to already tested procedures, without re-examining them in detail, at the light of the current case, we court the disaster. Unfortunately this approach is dictated often by the narrow budgets and by the need to save on the project costs. To the bureaucratic mentality, that underestimates (when it doesn't despise or fears) human intelligence, pressing economic demands are added: if the procedures costed so much in the previous projects, and were successful, this is right the moment to enjoy the return of the investment! Let's apply them without so many excuses!

The thoughtless application of automatisms, plus the inexperience, gives in output the disaster, as the splendid Walt Disney's cartoon "The Apprentice Wizard" remembers us. The old Magician ordered to a young and unprovided Mickey Mouse (inexperienced person) to fill the water cistern, withdrawing the water from the well. Mickey Mouse learned to bewitch the broom, in order it performs the job in place of him. But, since Mickey Mouse didn't yet learn how to stop the process, the broom floods shortly the whole house, and only the old Wizard, back from his trip, will be able to recover the situation.

Regarding the same problem from another point of view, the polished and merciless one of R. M. Pirsig, I can't avoid, at this point, to quote the difference between the handicraft technical arts and the modern industrial technology[5]. This last, daughter of the dualistic separation between subject and object, lacks of that transcendental Quality moment, of deep unity between the artisan and his creation: the Upanisads's tat tvam asi truth. The slavish application of methodologies got the result to reproduce the industrial subject-object separation also at the design level (up to that moment been uninjured by such calamity). Besides, the thoughtless application of a methodology, removes the initial block, that dismay and that mental void that Zen points out as the most fertile moment, for the unfolding of some creativeness. And, we add, for the development of evolutionarily higher solutions.

The above doesn't however mean to disown the high value of methodologies, for the sake of not repeating already made errors, for the completeness and the methodicalness of the project acivities. It only means that methodologies should never be applied: they should, every time, to be used as a trace, in order to reinvent them on the escort of the preceding experience and of a total identification of the designer with the new requirements. In few words, if methodology precedes by now the system design, the creative commitment should be partially transferred to the level of the methodology design, or improvement.

The factors that invalidate the effectiveness of the methodologies (up to be completely self-defeating) are many, and certainly I don't claim to list them all here. One of the most serious is the division between Quality management and Project management. Part of the project control ends outside of the same project, to a corporate body (the company Quality office) which doesn't know the project scheduling nor the budget, or, however, it is not motivated to respect them. The project manager's efforts, targeted to a good commitment result, comes for a large part to be frustrated. That's how the Quality control begins to be perceived as an external factor, awfully troubling. The Quality Manager is seen as a sort of big priest, officiating incomprehensible rites and chewing an incomprehensible and abstruse qualitish latinorum. The Quality office becomes an external client, which doesn't pay anything, however it must be somehow satisfied: "In any case, they [the Quality Managers] don't technically understand anything: let's give them some paper, so they won't rock the boat."

Obviously I extremized, describing the worst possible use that can be done of the Quality philosophy, but I have seen indeed firms the inside organization of which is not so far away from the above described model.

How can a manager withstand the temptation to appraise his subordinate workers proportionally to the number of Non Conformities found in their products? It seems absurd, but firms exist in which the number of NCRs found is used as conclusive factor for lavishing increases of salary, promotions and passings of category. Probably we need a second total Quality revolution. As in the '980, when a small Japanese guy upset the Fiat management, suggesting to stop once and for all to punish who stopped the production lines reporting some problems: very better is to discover the problems well before the Client discovers them! Then the discoverer of problems and errors should be prized, and not punished.

Also this is, therefore, a case of struggle against the mental idleness (or against the causes which decrease enthusiasm). Certainly it is comfortable to have and use simple numerical criterions, to appraise the people, instead of consuming our grey matter, appraising case by case, the qualities of each single person. But it is easy to be wrong: maybe who has few NCRs deals with simpler jobs, or other. Easy to be wrong, as every time that we thoughtless submit ourselves to automatisms and numbers, skipping to reason on the human aspects.

But the factor increasing to excess the cost of Quality, it is certainly the massive use of paper. All Quality Methodologies prescribe in fact the production of an enormous quantity of paper documentation. Let's take them to the letter, and we will spend our time producing paper, rather than systems. When it's time to start testing, we'll realize that we have produced nothing of testable yet, and we'll look with dismay closets full of stackers, asking to ourselves who will hold adjourned that whole of paper. Big part of our budget has been spent and, what it is sadder, we are not quite sure that that huge quantity of paper will really help us in the development.

Obviously, and luckily, methodologies are not always taken to the letter. In the reality different behaviors are developed: systemists and project managers (particularly in the small firms, where the "comfort" of the Quality Manager doesn't exist, and where the attention to costs is a condition of survival) they get by as they are able, and such constant work ends up creating the premises for new evolutionary steps.

Since the initial project phases, that ESA standard defines Requirements Engineering, we need to trace the children requirements to the father requirements. This is a very expensive operation, in terms of time, difficult and generating many anxieties: are we sure to have linked everything? While we write requirements not always we are available to list their fathers, because sometime giving precedence to routine tasks can make the freshness of the solutions (which came to our mind) to fade away. Supposed that we linked all the linkable, we have now to create the Traceability Matrix, and here we are, to traffic with spreadsheets, to format charts, to laboriously connect every child with all its fathers, each father with all its children. We emerge from this weary constant work with the precious Traceability Matrix, we insert it in the documents and? we won't look anymore at it! The project enters more and more the hot phases, of integration and test. We will perhaps have to revise some requirements, some requirements will be cancelled, some new ones will be added. All the above implicates changes to the matrix. But it is a task that is postponed to better times, because we have nomore time for low priority tasks. The better times, as each designer well knows, they won't come anymore: the project will enter more and more emergency, and it is already so much if the fundamental documents (technical specifications) will be up-to-date, don't care about matrixes! Conclusion: we worked a lot for producing a document that will never be used anymore. The same is worth for the traceability matrix of the tests cases vs. the covered requirements.

The test procedures production is another activity that drives the designers and the test engineers crazy. The test procedure is, besides, a very much used document, during the hot integration phases. It owes to be, therefore, reprocessed many times: from the shop test procedures the main points are drawn for the integrated test procedures, from the low-level integrated tests the ones for the higher-level, where the software system tests are integrated with the ones of electronics, instrumentation, of the controlled plants and devices, of the interfaces, etc. Test procedures shall often be produced just before using them, because, before, some essential elements were missing (e.g. the know-how of other suppliers). It is often necessary to modify the procedure during the execution, therefore to correct and re-issue the document. The used tools (usually MSWord and/or MSExcel), force us to spend more time for formal aspects than for substance. The formatting of the step procedures tables (same font, same numbered lists, etc.) makes us lose the light of the reason, and our impatience is great, because we are not calm in our office, we are working in a laboratory or on the installation site, and we have to run, run, run.

The management of a complex commissioning usually oscillates, alternately, among two opposite and apparently incompatible needs: on one side the scarce application of Quality Methodologies is complained, on the other side the customer despairs for the integration activities delay. The standard imposes to write a Non Conformance Report for each detected problem, to deliver it to the Quality Office, to wait the adjourned paper LogBook back, and only at that time to proceed to the solution implementation.

Such process constitutes an intolerable bottle neck. Therefore designers, test engineers and project managers are very busy, studing how to revolve it. The most practiced solutions, when the found problems are quite a lot, are the following ones: (i) to report very less NCRs vs. the really found ones, (ii) to contravene to the prohibition of modifing the sources during the test activities, (iii) to interrupt the official test activity and to re-open a debugging phase.

During the phases of system integration and test, periodic meetings are held, in order to assess the performed tests, to decide the corrective actions, to discuss how to bring to the end the commissioning activities. The meeting coordinator annotates, on the minutes of meeting, the problems and the solutions. If the problems are many, the meeting is very fatiguing and frustrating, particularly for the ones which wanted to manage the project with systematicity and without losing anything on the road. The minutes of meeting is an exercise of beautiful writing, a lot of pages, incomplete, inaccurate and absolutely not systematic, that will go in a stacker in a closet, and that?. nobody will read anymore.

To maintain adjourned the coherence of the documentation is a task that, alone, can hock a Project Manager full time, the whole project duration: you have from 300 to 500 documents, in each of them there is a documentation tree, a table of the applicable documents and one of the reference ones. The documents are produced and upgraded more times in the time period of several months or years, by different people, belonging to different firms. How can we think that the trees and the references, in any given moment, are coherent, unless a person was dedicated full time to re-check all the documents at least every week, updating the references? You will say: a week is not enough to re-check the congruence of 300 documents, and this further complicates the problem. To increase the number of the checkers would only get a further complication. Result: since the PM has well other things to do, and he only has in his head (if he has it) the global project and its evolution in the continuous discussions with the Suppliers and with the Customer, the coherence of the documentation is checked sometime, partially, from some designer or from the PM. Such event occurs when they are forced by frustration and bother, having opened a document whose references are not up-to-date.

The answers to some questions of the questionnaire (please see next section) result diametrically opposite, according to whether they come by Technicians or by Quality Managers. Really this is one of the focal points of the problem. Methodologies are useful working tools only for the Quality Manager, while the Designer often leaves them as a drag or worse. The Quality Manager, when separated from the project team, doesn't live with the project, is not aware of, nor engaged to, the scheduling, is not motivated on the results of the order. For all the above reasons he ends to represent a sort of authority, external to the project, and is perceived more or less as the traffic police, that stops us when we are in a hurry. The problem has different connotations according to the more or less structured company organization. The big firm, endowed with a functional matrix structure, has a Quality function that centralizes and should coordinate all the Quality inherent activities. In reality, it often ends behaving as a government office counter, lacking of any active approach, waiting to receive the documents and the NCRs by the Designers and Test Engineers. On the other side, the project teams miss a Quality Coordinator. This task is developed more or less by the technical Project Leader, if he has time. While the project develops he has less and less time, therefore Quality is most penalized really in the most critical phases (integration and test), in which rigor and methodicalness should be increased.

The standard ESA ECSS-E-40 seems to hold in great account the Customer-Supplier relationship, and notices the fact that, in any Space System project, such kind of relationship is proposed at different levels, in the supply chain. The management of the Customer-Supplier relationship according to Quality criteria[14] would have great influence on the Quality of the final integrated product. Unfortunately, on this road, we are only at the very beginning. Just to start, we need to operate a distinction that the ESA standard doesn't make: the concept of Customer, as expressed, it is in fact too much general. In the Customer's house more subjects exist, each with specific demands. Limiting to two basic types: the User (technical) and the Purchaser (administrative). The first one reasons according to Quality criterions, the second according to economic criterions. Often the two demands clash, and in the biggest part of cases the economic demand is the winner. Point 4 of the 14 points[2] of Edward W. Deming recites as follows: "End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward to single supplier for any one item, on to long-term relationship of loyalty and trust." If we want to be reasonably sure to choose a supplier on the base of the offer Quality, first of all we need to be sure that the different offers are really comparable one each-other. We should therefore start dealing with offer and negotiation Quality, both in the Customer's house and in the Supplier's house, an aspect still neglected by the standards. In general, the standards producers should not confine themselves to enunciate the theoretically correct procedures. They should use very much more the investigation method and the questionnaires, with the goal to identify the critical and contradictory points of the processes, and to try to give answers and/or to systematize the best answers given by the firms.

The answers given to the questionnaire, addressed to around 900 firms, in great majority belonging to the aerospace segment, they reveal deep differences of setup, and of perception, of the Quality Methodologies. The biggest differences are especially in dependence by the following factors:

• dimension of the firm,
• role of the person answering to the questionnaire (designer or Quality Manager).

The questionnaire is divided into three sections: Organization Data, Economy, Opinions. The first section is targeted to identify the dimensions and the prevailing activities of the firm. The second aims to collect data about the cost of Quality on the project economy, the third one how the Quality Methodologies are taken in and used.

The firms which answered have different dimensions, and primarily develop technological projects both for the Space Agencies and for industrial Clients in the aerospace market. The questionnaire didn't have any official credentials, perhaps due to its unofficial character, the number of answers was decidedly small, lower then the expected. Nevertheless some indications emerge, clear enough.

The consulted firms spend in average 20% of the order budget in the phase of requirements engineering, and the remainder 80% in the phases of development, validation and commissioning.

The weight of the Quality cost on the whole project budget is divided as follows:

As we can see, the Quality Methodologies mostly engrave on the integration phase (or commissioning, in case of plant automation systems). Inside such phase, the lion's share is taken by the test procedures production and the meetings to assess the test campaigns. The problems trace and the Traceability Matrixes production follow, separated by few points. Obviously we shall bear in mind that meetings usually hock professional profiles whose hourly cost is higher. Therefore, very likely, in terms of time, they are the tests procedures, their execution and the relative tracing which gobble up the greatest part of the anticipated hours, and often also of the not anticipated ones.

The greatest part of the answering firms uses Office (MSWord, MSExcel) to manage Quality and documentation. Someone uses self-built tools, made by relational databases.

At the question "Relevance of Quality Standard Methodologies for the System Safety and Reliability" all the interviewed gave answers between high and indispensable. "Relevance of QSM for the System Maintainability" is very high for 50%, so and so or low for the remainder (the split doesn't reflect dimensional nor roles aspects). "Relevance of QSM for the Project Management" is high or indispensable for 70% of the sample, low for the rest. If they could decide, the small enterprises would apply the QSM only on very complex projects, while the big corporates would always apply the QSM.

The split between big and small enterprises continues: "In general terms, the Quality standard application cost is" acceptable, for the big corporates, while it is high for the small ones. "The Quality standard application burden the project activities" not so much, for the small companies, not at all for the big ones; for these last ones it supports the project activities. "The high cost of the space technologies is a factor that delays the opening of the high frontier", from yes to very much for the small companies, while the big corporates range of answers goes from "a little bit" to "no" to "no comment" because the question was considered absurd. To the question "What is the heaviest (uselessly expensive) items, weighing on the space technologies development?" the small companies answered the hardware procurement, some of them also the engineering. Some big corp said that high Quality hardware is not always needed.

At the question "Do you think that the QSM are redundant?" 80% of the sample answered "a little bit", 20% (some big company) "not at all". "Does the QSM require to produce too much paper?", for the small companies the range varies from "a little bit" to "very much"; while the bigs said "not at all". "Would a subset of the known QSM be enough to manage the project Quality?" got a 30% of "yes, a very reduced set", 50% of "maybe, a moderately reduced set", while the remainder answered that the company models the QSM use, according to the needs. "The QSM require many repetitive boring activities", "intolerably", for 30%, "a little bit" for 50%, "not at all" for the remainder.

"What is (or should be), in your opinion, the main scopes and purposes of a Quality standard methodology? Please indicate a priority (0-10, 0 = max. Prio)". "To help staying in the budget" got priority between 0 and 1 by 75% of the sample, so the "System safety & reliability", "To help the project management" and "Product Quality". "To help staying in the scheduling" got priority 0 by 50%, prio 2 and lower for the remainder. "Completeness of documentation" is a priority 0 only for 25% of the sample, 2 and lower for the remainder. "Acquired know-how conservation" has priority between 0 and 1 for the big corps, 2 and lower for the rest. "System maintainability", "Uniformity of documentation" and "System easy and property of use" are a priority 1 only for a scarse 20% of the sample.

The Project Quality Manager should take care most of the project Quality for the 50% of the sample, for 20% the whole project team, and the technical project leader for the 30%. 100% had sometimes to manage conflicts between Quality needs and activities scheduling.

50% of the sample thinks that, using more electronics to support the really critical phases, the productivity could be improved. Another 50% (not always coincident with the above) thinks that there are not enough tools, on the market, to support the project Quality management.

The most critical project activities (less time, worst conditions and heaviest work to do)? Are System Design for a scarse 80%, development for a 10%, no answer for the remainder. The most penalized project activity, when the project is in emergency, is the requirements traceability for 50%, problems tracing and solving for the remainder.

As every statistic investigation, also this must be treated a lot with kid gloves, keeping in mind that, besides the differences already noticed - among big and small enterprises - there are other differences, hidden but not less important: for instance, the role of the person answering to the questionnaire. A really accurate investigation should foresee separate questionnaires for Administrators, Technicians and Quality Managers. Another difference, still less evident, it is given by the prevailing typology of projects: Earth Systems (characterized by conspicuous commissioning phases) or Flight Systems, in which the integration and verification phases (however complex) resolves in the laboratory, and therefore it doesn't include all the problems typical of the yard. Nevertheless some data emerge with a certain clearness:

• all had problems of conciliation of the scheduling demands with the Quality ones;

• a good percentage (especially small enterprises) reports characters of heaviness, redundancy and expensiveness of the Quality Methodologies.

Another thing to be noticed, from the answers, is the scarce interdisciplinary discussion around the Quality Methodologies. It seems to be still and above all a subject for those in the know, the Quality big priests, especially in the big corporates: there the Technicians don't discuss of it because it is not their business. The others (in small firms) mainly suffer it, and don't discuss it because they don't have time to do it.

The Electronic Age: Instructions for use

We have to take note, from our daily experience, that our culture often brings us to reason for watertight compartments: since they taught us, or we learned, to use certain tools for certain objectives, and not for others, we are balky to make an analytical step of higher abstraction, considering therefore ours toolbox from a more general point of view. We have for instance gotten used to consider Electronics and Computer Science as parts of the technological equipment to employ in the systems project: with enthusiasm, with worry, with bother, according to our personnel relationship with such technologies. But Electronics is very much more. It changed all the social and economic paradigms in 50 years, it upset the deterministic certainties of the Mechanical Age, redelivering us to the uncertainty, fully analogical, of the systems, endowed with endless degrees of freedom. In front of such changes, the philosophy researchers preferred to retire themselves in a most comfortable filosofology, and they don't like at all to risk, exploring the cognitive and perceptive frontiers opened by Electronics. But luckily we are a pragmatic kind, that never needed to fully know a tool, before using it! Well, Electronics, besides getting us on one side anxieties and enthusiasms in quantity, can, on the other side, give us calm and safety.

The problem, seen by the optics of the dynamic Quality, is the one to proceed to the following evolutionary step: to get a new degree of determinism (without the pretension of that full determinism, that was historically fed by Mechanics), above the complexity determined by the enormous increase of freedom degrees brought by Electronics.

Such goal is nearly unattainable using paper. It is more feasible instead using Electronics: today the Relational Databases, tomorrow Decision Support Systems based on the integration of Artificial Intelligence and Relational Database technologies.

Already with the current tools (relational dbs), it is possible to realize a kind of project electronic secretary, that supports us during the design, and takes care - in our place - to always hold orderly and quickly visualizable / sortable / selectable all the meaningful elements of the project (requirements, tests, problems, signals, systems, subsys-tems, machines, plants, documents, people, clients, suppliers, etc?).

At the current level (relational dbs) the system shall be fed by data and kept up-to-date along the whole System Life Cycle (but it gives back many times each invested hour). Tomorrow - with the addition of Artificial Intelligence - it will be enough to design in an environment visible by the system, and it will capture the meaningful datas (self-feeding), catalog them and make them available, and also give us suggestions and warnings at proper time. Also the current level, however, the use of relational dbs allows to rationalize the project Quality activities, to apply them very better and completely, and to sensitively decrease their cost.

Experienced Designers, Program Managers, System Analysts and Test Engineers perfectly know their work, they know what to do. They don't need a kind of paper or electronic policeman, continuously suggesting them what to do, and preventing them to do something if they didn't yet make something else. What such people really lacks of is time to trace what they are doing, so they often miss to transform in value (consolidated know-how) their problems. Therefore what they really need are tools to support them in the following task: automated tracing their work, automated documents productions.

The methodological standard producers are building a very complex and divided building, going to discipline and to rule in details every smaller project activity, differentiating the procedures according to different technologies and organizational aspects, and many other aspects. I don't aim to frontally contest such analytical tendency (our society dramatically misses of analytical approach), nevertheless it would need, at least, to be balanced. A group of critical auditors should be constitued, whose fundamental requirement was the standards simplification. They should analyze the processes and the methodologies always having in mind questions like the following ones: does this differentiation have really sense? What would happen if we condense this standard and this other? What would happen if we reduce this ramification to the main point? Was the purpose of this norm been enough defined and rendered explicit?

Reduced to the bone, the topic of the systems Quality (not only space), includes the following elements:

• offer and negotiation
• definition and tracing of the requirements
• definition and tracing of the test cases
• problems annotation, tracing and solving
• definition and management of the i/o signals (if any)
• documentation
• management of responsibilities and of the working group
• management of sub-suppliers and subcon-tractors (if any).

The winning approach, in order to turn the methodology into a tool of support to the efficient and qualitative design, consists in the followings five points:

• Use Electronics for the complex, heavy and critical tasks inherent Quality, e.g.: automated work in progress control during requirements engineering phase; automated production of Traceability Matrixes, automated production of test procedure documents, automated production of i/o signals lists, automated production of problems lists and reports (to be annexed to the minutes of meeting). To use paper only as backup of the electronic memory, out of the correction/integration cycle.

• To elaborate an essential philosophy, reasoned, and customized case by case, turning into account, synthesizing them, the different methods present in the methodologies.

• To consider the methodology neither as "God" neither as an external authority "to satisfy". To conceive instead the methodologies as tools, available to the designer and the project manager:

• the methodology as a check list, and

• the methodological items (requirements, tests, problems) as a support to the coherent design and project manage-ment.

• To transform the detected problems in know-how, i.e. in value. To fully use the experience and the know-how acquired in each project in the next projects.

• To always use the human intelligence, never submit completely to methodologies, always re-examine the procedures each time we have a doubt, and not to hesitate to modify them if we believe that it is the case.

ECSS

European Cooperation for Space Standardization

ESA

European Space Agency

NASA

National Aeronautics and Space Administration

FMECA

Failure Mode, Effects and Criticality Analysis

GOST

Gosudarstvennyi Standard = Government Standard

NCR

Non Conformance Report

PM

Project Manager

QM

Quality Manager

QSM

Quality Standard Methodologies

TQM

Total Quality Management

1. Lao Tzu, "Tao Tê Ching", http://www.vedanta.it/sastra/ tao_te_ching/indice.htm
2. E W Deming, "The 14 points" http://www.tpmonline.com/articles_on_total_productive_maintenance/ management/deming14steps.htm
3. Ishikawa Kaoru, 1985, "What is Total Quality Control?", Prentice- Hall Inc., Englewood Cliffs, NJ
4. Genichi Taguchi, June 2003, "Robust Quality",
5. Robert M Pirsig, 1974, "Zen and the Art of Motorcycle Maintenance"
6. Robert M Pirsig, 1991, "Lila, an Inquiry into Morals"
7. E Agazzi, R Levi Montalcini et al, 1990, "Valori, scienza e trascendenza", Fondazione Giovanni Agnelli
8. A Autino, October 2002, "The Copernican Evidence - Requirements for a Space Age Philosophy", paper presented at the 53rd IAF Congress- Houston October 2002, http://www.andromeda-srl.com/work/IAC2PP23.pdf
9. Technologies of the Frontier, "The tragedy of the Shuttle Columbia", http://www.tdf.it/english/homeen.html
10. A Autino, 2000, "An analogical and human Millennium is born", TDF 1/2000-06, http://www.tdf.it/english/editoriali/Millennio%20eng.htm
11. A Autino, 1999, "Lost Spacecrafts and Earthquakes", TDF 16/10/1999 http://www.tdf.it/english/editoriali/sonde%5Feng.htm
12. A Autino, "Project & Test Engineering System (PTESY)", http://www.andromeda-srl.com/Eng/PTESY_eng.htm
13. A Autino, "How to use Electronics and to live happy", (electronic book)
14. ECSS-E-20B, 13/06/2003, "Space Project Management - Project Organization", European Cooperation for Space Standardization
15. ECSS-E-40A, 13/04/1999, "Space Engineering - Software", European Cooperation for Space Standardization