2
J. SYSTEMS SOFTWARE 1 1991; 16:1-2 Editor’s Corner Structured Research? (A Partly Tongue-in-Cheek Look) Robert L. Glass There is a problem hardly anyone wants to talk about, but I think it’s time to bring it out into the open. It’s what I’d like to call the “software research crisis.” The software research crisis? What is this crisis, I hear you saying? It’s the tendency of research to be over budget, behind schedule and unreliable. And it’s a real crisis. When did you last hear of a research project that worked to a tightly-controlled budget, came through on a predictable schedule, and was reliable enough to be put to immediate, productive use? I am not here just to bemoan this crisis. I have some positive suggestions as to what we should do about it. First of all, I think it is time we structure our research. In fact, I would like to propose a structured revolution for research. What do I mean by structured research? We need a disciplined, rigorous, orderly, straightforward process for doing research. None of these random opportunistic “goto’s. ” None of that slovenly, uncontrolled, free- dom-loving serendipitous stuff out of the past. We will have a research life cycle, carefully-controlled mile- stones for monitoring research accomplishments, and a set of research documents to be produced along the way so that management can see into research progress. And research metrics. We need ways of measuring both the productivity and the success of research pro- jects [perhaps we could measure person-hours per Source Line Of Published research paper (SLOP)]. To compare future research under this new paradigm with the undisciplined research of the past, we’d better begin collecting this metric data now. Contemporary research metrics data collection is perhaps the most urgent need of the research crisis. And then we need to define research process. Per- haps we could even define a research process model, and invent a process language in which we could define the activities of research and monitor a specific project against that model. This editorial was reprinted with permission from the column “Software Reflections” by Robert L. Glass in System Develop- ment, P. 0. Box 9280, Phoenix, AZ 85068. 0 Elsevier Science Publishing Co., Inc. 655 Avenue of the Americas, New York, NY 10010 What would be in the process model? First of all, we would have all the elements of the research life cycle. We would define the requirements for the research in a formal, rigorous, mathematical language so that we could clearly convey them to our funding sources. In fact, with a rigorous-enough language, perhaps we could look to the automatic generation of research findings from these rigorous requirements languages. And then we would have research design. Perhaps we could have a research design methodology, the Gane-Sarson or the Yourdon of research, a set of orderly steps and processes for doing design. And when we finished the design, we could represent that design in a collection of structured languages- idea flow diagrams (IFDs), in which the flow of ideas and the processes that manipulate them could be shown; research structure charts (RSCs), in which a hierarchic view of the research functions could be represented; and research design languages (RDLs), in which we could represent in a rigorous way the many miniscule details of the design. In fact, even without automatic generation of research from requirements specifica- tions, we could probably, with the help of rigorous and thorough design representations, use technicians to fin- ish the research once a thorough design were written. And then research implementation. With all the for- malization of the preceding processes, research imple- mentation should be straightforward. We will have research design folders (RDFs), a sort of repository in which we put everything pertaining to the research implementation for the future use of whoever looks at RDFs, and we will hold research structured walk- throughs (RSWs), in which research peers will examine and critique research implementation findings. And we will get ready for the research testing process. There are two possible approaches to structured re- search testing. The traditional approach, of course, is via the use of sample inputs, either structured or ran- dom (statistical), where test cases are run against the implemented research to seek flaws in its implementa- tion. Or there is formal verification of the research, in which mathematical proof processes are used on the research findings both to seek errors and to prove the 01641212/91/$3.50

Editor's corner: Structured research? (A partly tongue-in-cheek look)

Embed Size (px)

Citation preview

Page 1: Editor's corner: Structured research? (A partly tongue-in-cheek look)

J. SYSTEMS SOFTWARE 1 1991; 16:1-2

Editor’s Corner

Structured Research? (A Partly Tongue-in-Cheek Look) Robert L. Glass

There is a problem hardly anyone wants to talk about, but I think it’s time to bring it out into the open. It’s what I’d like to call the “software research crisis.”

The software research crisis? What is this crisis, I hear you saying? It’s the tendency of research to be over budget, behind schedule and unreliable. And it’s a real crisis. When did you last hear of a research project that worked to a tightly-controlled budget, came through

on a predictable schedule, and was reliable enough to be put to immediate, productive use?

I am not here just to bemoan this crisis. I have some positive suggestions as to what we should do about it. First of all, I think it is time we structure our research. In fact, I would like to propose a structured revolution for research.

What do I mean by structured research? We need a disciplined, rigorous, orderly, straightforward process for doing research. None of these random opportunistic “goto’s. ” None of that slovenly, uncontrolled, free- dom-loving serendipitous stuff out of the past. We will have a research life cycle, carefully-controlled mile- stones for monitoring research accomplishments, and a set of research documents to be produced along the way so that management can see into research progress.

And research metrics. We need ways of measuring both the productivity and the success of research pro- jects [perhaps we could measure person-hours per Source Line Of Published research paper (SLOP)]. To compare future research under this new paradigm with the undisciplined research of the past, we’d better begin collecting this metric data now. Contemporary research metrics data collection is perhaps the most urgent need of the research crisis.

And then we need to define research process. Per- haps we could even define a research process model, and invent a process language in which we could define the activities of research and monitor a specific project against that model.

This editorial was reprinted with permission from the column “Software Reflections” by Robert L. Glass in System Develop- ment, P. 0. Box 9280, Phoenix, AZ 85068.

0 Elsevier Science Publishing Co., Inc. 655 Avenue of the Americas, New York, NY 10010

What would be in the process model? First of all, we would have all the elements of the research life cycle. We would define the requirements for the research in a formal, rigorous, mathematical language so that we could clearly convey them to our funding sources. In fact, with a rigorous-enough language, perhaps we could look to the automatic generation of research findings from these rigorous requirements languages.

And then we would have research design. Perhaps we could have a research design methodology, the Gane-Sarson or the Yourdon of research, a set of orderly steps and processes for doing design. And when we finished the design, we could represent that design in a collection of structured languages- idea flow diagrams (IFDs), in which the flow of ideas and the processes that manipulate them could be shown; research structure charts (RSCs), in which a hierarchic view of the research functions could be represented; and research design languages (RDLs), in which we could represent in a rigorous way the many miniscule details of the design. In fact, even without automatic generation of research from requirements specifica- tions, we could probably, with the help of rigorous and thorough design representations, use technicians to fin-

ish the research once a thorough design were written. And then research implementation. With all the for-

malization of the preceding processes, research imple- mentation should be straightforward. We will have research design folders (RDFs), a sort of repository in which we put everything pertaining to the research implementation for the future use of whoever looks at

RDFs, and we will hold research structured walk- throughs (RSWs), in which research peers will examine and critique research implementation findings. And we will get ready for the research testing process.

There are two possible approaches to structured re- search testing. The traditional approach, of course, is via the use of sample inputs, either structured or ran- dom (statistical), where test cases are run against the implemented research to seek flaws in its implementa- tion. Or there is formal verification of the research, in which mathematical proof processes are used on the research findings both to seek errors and to prove the

01641212/91/$3.50

Page 2: Editor's corner: Structured research? (A partly tongue-in-cheek look)

2 J. SYSTEMS SOFTWARE 1991; 16:1-Z

Robert L. Glass

correctness of the results. Either way, these testing processes will be performed to structured test plans and be reported in structured test reports.

And maintenance? Well, of course, there is no main- tenance problem in research-or if there is, it is the same as the research development problem-and so we will not define a separate research maintenance pro- cess. (Note that here alone we have saved 40-80% of the research budget.)

Now with this rigorous approach to research, we can finally get control of these researchers. We can esti- mate the time it will take to do research from estimates of the lines of published papers that will result. And with appropriate estimates based on these structured and rigorous approaches, we can then more tightly control and monitor research, eventually solving the research crisis.

There is one more facet of contemporary research

approaches to be dealt with. Current research is heavily ego based, with both institutional and self belief inti- mately tied to the work and its publication. Research must be freed from its ego dependence. To do this, regular reviews will be held, matching the phases of the research life cycle, to monitor progress in front of both managers/customers and research peers. Then there

will be aperiodic audits to check troubled research projects for inherent flaws, and of course to enforce the structuring process on those projects that are trying to avoid its use. The result will be a team-based, egoless

approach to research. And there it is. With a well-defined research process

program, appropriate discipline applied to researchers, a research life cycle with milestones by which we can measure research progress, reviews and audits for get- ting visibility into the process, and metrics to evaluate how well we did when the research ends, we can begin to control this elusive area.

Researchers of the world, rejoice! The structured revolution is at hand, the enforced discipline of rigor-

ous and formal methods is coming, and the research crisis will soon be solved!

ACKNOWLEDGMENT

This research was funded by the International Theological Society for Research and Other Uncontrolled Things (ITSROT), and the author wishes to thank them for making this work possible. In particular, it is important that the sponsors did not insist THIS research be subject to the proposals contained herein- these ideas, of course, are for OTHER researchers and for software engineers, not for elite people such as myself.