- Email: [email protected]
4GLs and CASE: What's the payoff?
J. SYSTEMSSOFTWARE 1991;14: 131-132
131
Editor’s Corner Robert L. Glass 4GLs and CASE: What’s the Payoff?
There is a lot of action now on the software automation front. 4GLs and CASE tools promise much. What do they really deliver? That’s a pretty important question. Fortunately, there are some recent research attempts to answer it. Here’s the bottom line of three such studies: 1. A CASE tool improved cost 9% and quality by an unquantified amount. 2. A pair of 4GLs gave code 29-39 % shorter, but over 50 times slower. 3. Another 4GL reduced development effort by fourfive times. Although the fact that there are such studies is good news, the bad news is that this is hardly the stuff of which breakthroughs are made. Let’s look a little more deeply into these studies.
CASE Tool Results
First of all, the CASE tool study. This work is documented in an as-yet unpublished paper called “A Survey on Applications of a CASE Environment: Insights Gained, ” by Rudolf Lauber of the University of Stuttgart and Peter Lempp of SPS Software Products and Services. It explores the use of a European CASE tool called EPOS. EPOS has features to support much of the software life cycle-requirements organization and specification, conceptual design definition and refinement, feasibility analysis, and preliminary and detailed design representation. The study of the value of EPOS was conducted by survey and interview. Twenty-two managers of medium-to-large scale projects at 14 companies were involved. What were the findings? -. This editorialwas reprinted with permission from the ColUmn “Software Reflections” by Robert L. Glass in system Development, P.0. BOX 9280, Phoenix, AZ 85068. 0 Else&r Science Publishing Co., Inc. 655 Avenue of the Americas, New York, NY 10010
1. The greatest benefits were perceived to be in project management and control. 2. Costs tended to increase at the front end of the life cycle, decrease at the back end (with a projected huge improvement in maintenance and documentation costs), with an overall net saving (including the projected savings!) of 9%. 3. Fewer errors during the front-end processes were reported by 69% of the projects. 4. Creativity and motivation of technical people were not influenced at all. 5. Acceptance of the tools ranged from enthusiastic at the outset, to disillusionment during training, back to enthusiastic after some usage. 3GL vs. 4GL Experiment Secondly, let’s look at the 3GL vs. 4GL experiment. Santosh Misra and Paul Jalics of Cleveland State University published their findings, “Third-Generation vs. Fourth-Generation Software Development, ’ ’ in the July 1988 issue of IEEE Software. They wrote a smallto-medium business application three ways-once in dBase III, which they called a “low-level 4GL,” once in PC Focus, which they called a “higher-level 4GL, ” and once in COBOL. The results were disappointing from the 4GL point of view: 1. 4GL source code was 29-39% smaller in length than COBOL. 2. The source code advantage for 4GLs would be improved if data declarations were also considered (the 4GLs required few if any), but most software engineers today believe that having data declarations is better than not having them. 3. Development time was 15% faster for dBase III than COBOL, but 90% slower for PC Focus (even when most learning curve costs are subtracted out). 4. Performance of the 4GL code was 15-174 times slower for the 4GLs than for COBOL.
0164-1212/911$3.50
132
R. L. Glass
J. SYSTEMS SOFTWARE 1991; 14: 131-132
3GL vs. 4GL Case Study
The final set of findings was published in the same issue of the same journal. June Vemer and Graham Tate of Massey University in New Zealand looked at “Estimating Size and Effort in Fourth-Generation Development.” The main focus of their study was on presentday estimation techniques for 4GL developed applications (basically, they found them wanting). But along the way, in the context of a small-business application, they found considerably more advantage to their 4GL than the authors above. Here, the 4GL was ALL, Microdata’s Application Language Liberator, chosen after a competitive process with their specific application in mind. Their relevant
findings
were fairly crisp:
“Effort for the 4GL implementation vs. the estimates for a comparable COBOL implementation favored the 4GL approach by 400%. If feasibility and requirements were factored out (because the time to do them should not be dependent on the language chosen), the savings was 530%.”
There is still a lot for us to learn about software automation. Studies such as these, though preliminary and perhaps even crude by the standards of more traditional experimental research, are still about the only way we have today of getting an objective look at its value. Based on these studies, it would appear that the benefits of software automation are evolutionary, not revolutionary as often claimed.
WARNING-SCHEDULE
PROBLEM
During the months of April through July, 1991, I will be a visiting professor at Linkoping University in Sweden. If you intend to submit papers to the Journal, I strongly recommend that you either submit them before I leave, or hold them until my return. If you are a reviewer, please make an extra effort to get your reviews to me before my departure. Do not be alarmed if editorial services are at best sluggish during my absence. R. L. Glass
131
Editor’s Corner Robert L. Glass 4GLs and CASE: What’s the Payoff?
There is a lot of action now on the software automation front. 4GLs and CASE tools promise much. What do they really deliver? That’s a pretty important question. Fortunately, there are some recent research attempts to answer it. Here’s the bottom line of three such studies: 1. A CASE tool improved cost 9% and quality by an unquantified amount. 2. A pair of 4GLs gave code 29-39 % shorter, but over 50 times slower. 3. Another 4GL reduced development effort by fourfive times. Although the fact that there are such studies is good news, the bad news is that this is hardly the stuff of which breakthroughs are made. Let’s look a little more deeply into these studies.
CASE Tool Results
First of all, the CASE tool study. This work is documented in an as-yet unpublished paper called “A Survey on Applications of a CASE Environment: Insights Gained, ” by Rudolf Lauber of the University of Stuttgart and Peter Lempp of SPS Software Products and Services. It explores the use of a European CASE tool called EPOS. EPOS has features to support much of the software life cycle-requirements organization and specification, conceptual design definition and refinement, feasibility analysis, and preliminary and detailed design representation. The study of the value of EPOS was conducted by survey and interview. Twenty-two managers of medium-to-large scale projects at 14 companies were involved. What were the findings? -. This editorialwas reprinted with permission from the ColUmn “Software Reflections” by Robert L. Glass in system Development, P.0. BOX 9280, Phoenix, AZ 85068. 0 Else&r Science Publishing Co., Inc. 655 Avenue of the Americas, New York, NY 10010
1. The greatest benefits were perceived to be in project management and control. 2. Costs tended to increase at the front end of the life cycle, decrease at the back end (with a projected huge improvement in maintenance and documentation costs), with an overall net saving (including the projected savings!) of 9%. 3. Fewer errors during the front-end processes were reported by 69% of the projects. 4. Creativity and motivation of technical people were not influenced at all. 5. Acceptance of the tools ranged from enthusiastic at the outset, to disillusionment during training, back to enthusiastic after some usage. 3GL vs. 4GL Experiment Secondly, let’s look at the 3GL vs. 4GL experiment. Santosh Misra and Paul Jalics of Cleveland State University published their findings, “Third-Generation vs. Fourth-Generation Software Development, ’ ’ in the July 1988 issue of IEEE Software. They wrote a smallto-medium business application three ways-once in dBase III, which they called a “low-level 4GL,” once in PC Focus, which they called a “higher-level 4GL, ” and once in COBOL. The results were disappointing from the 4GL point of view: 1. 4GL source code was 29-39% smaller in length than COBOL. 2. The source code advantage for 4GLs would be improved if data declarations were also considered (the 4GLs required few if any), but most software engineers today believe that having data declarations is better than not having them. 3. Development time was 15% faster for dBase III than COBOL, but 90% slower for PC Focus (even when most learning curve costs are subtracted out). 4. Performance of the 4GL code was 15-174 times slower for the 4GLs than for COBOL.
0164-1212/911$3.50
132
R. L. Glass
J. SYSTEMS SOFTWARE 1991; 14: 131-132
3GL vs. 4GL Case Study
The final set of findings was published in the same issue of the same journal. June Vemer and Graham Tate of Massey University in New Zealand looked at “Estimating Size and Effort in Fourth-Generation Development.” The main focus of their study was on presentday estimation techniques for 4GL developed applications (basically, they found them wanting). But along the way, in the context of a small-business application, they found considerably more advantage to their 4GL than the authors above. Here, the 4GL was ALL, Microdata’s Application Language Liberator, chosen after a competitive process with their specific application in mind. Their relevant
findings
were fairly crisp:
“Effort for the 4GL implementation vs. the estimates for a comparable COBOL implementation favored the 4GL approach by 400%. If feasibility and requirements were factored out (because the time to do them should not be dependent on the language chosen), the savings was 530%.”
There is still a lot for us to learn about software automation. Studies such as these, though preliminary and perhaps even crude by the standards of more traditional experimental research, are still about the only way we have today of getting an objective look at its value. Based on these studies, it would appear that the benefits of software automation are evolutionary, not revolutionary as often claimed.
WARNING-SCHEDULE
PROBLEM
During the months of April through July, 1991, I will be a visiting professor at Linkoping University in Sweden. If you intend to submit papers to the Journal, I strongly recommend that you either submit them before I leave, or hold them until my return. If you are a reviewer, please make an extra effort to get your reviews to me before my departure. Do not be alarmed if editorial services are at best sluggish during my absence. R. L. Glass