- Email: [email protected]
The impact of fourth generation languages on systems development
81
Techniques
OQ@kNions
ts, and low transactions tions of 4GL’s and are gene&y *&eir use.
the benefits and limitamaking go& decisions abrt
Km&: Fourth generation languages, Systems development, Application development aids, Prototyping.
today
are facing a tough set of
and systems programmers continues to be a constraint 121. Methods of improving the productivity of the application development process include the use of software packages, the support of end-user application development, and the use of fourth generation languages MGL) [12]. While these toofs have been used extensively to sup computing there is Limited evidence systems development projects conducted by MIS professionals. 4GL’s can be used to create programs for many applications with substantially fewer lines of code than COBOL. Features like on-line data dictionaries, libraries of re-usable modules, and pre-programmed functions can speed up the application building pr-s. These tools can also effectively support the prototyping approach There is some evidence of the tarpes of productivity increases through the use-of 4GL tools. According to research by Dr. Ebe
is an Associate Profesthe Department of Management Information Systems at the School of Business at Southern Illinois Unitersity at Edwardswille. Her teaching and research interests include information systems design, end-user and departmental computing, and office automation. She has authored textbooks in computer concepts, management information systems, and automated office systems management.
037%7206/88/%3.5~ @ 1988, Elsevier Science Publishers B.V. (North-Holland)
R&ert Bemion is Dean of ahe School of Technology and In iormri ‘ion Management at Weshingtc,n Un!versity in St. Louis. He is also Associate Vice-Chanceilor, Compu tin& and Communications with adninistrative responsibility for university-tide conputing. His academic interests have centered on the Enterprise-wide Information Management projx t between the Center for the Stud) of Iota Processing and IBM’s Lo; Angeles Zcientific Center
82
Information & Management
Techniques
the development time for a small-scale prO!@t 10,ilOO to 20,000 lines of COBOL) of typical complexity was slightly over 10 person-days with LING (Burroughs’ fourth generation tool) as compared with 200 person-days with COBOL. ‘This represents a 17 to 1 productivity increase. With large-scale development projects (e.g., 200,000 line of COBOL), the productivity ratio was 45 to 1. In both cases, function point analysis was used to compare procedural and nonprocedural code (161. case studies in recent trade publications also depict productivity gains as measured by percentage improvement in overall time and labor savings and accomplishing more work with fewer people. Ease of learning, through help menus and diagnostics, and the prototyping approach have frequently been cited as qualitative impacts of 4GL’s. However, experiences with 4GL’s are not always successful. Gne involved the CisastroW Ciisequences of using a 4GL to develop the New Jersey Division of Motor Vehicles’ new computer terminals system. It was :o have more than 1 with thousands of transactions per day accessing a data base containing records on several million licensed drivers, 4i~ mill_iou regisierti veiiicies, and 20 million title documents. In spite of unacceptable response times during a preliminary system test, the project used an untried 4GL and the system inevitably crashed. Since the tool was inadequate for the job of developing a complex on-line system requiring fast response, the system was redeveloped using both the 4GL and a procedural language. Concern over the machine resource utilization problem has also been cited by Atre Fourth generation language systems for production processing run about one-third as fast as COBGL. In another test, a 4GL demonstrated a 2 : 1 improvement in development time, but the program ran 30 times slower 1131. Concerns about machine utilization, lack of integration among 4GL projects, and programmer resistance have delayed the e ve use of 4GL’s in sy.:tems development. M IS professionals are not sure how 4GL tools can be used sue fully. Managers need to reco cm be used effect gement and org r their effective use.
2. Objectives of the Study
(e.g.,
A number of orgiurizations have accunntlated experience in using 4GL’s over the past four to five yeais. This study is designed to learn the characteristics of projects in which 4CL’s have been used and to provide guidelines about the types of projects in which they can be used effectively. The specific objectives are: (1) To identify the nature and scope of systems development projects in which &L’s are being Used.
(2) To compare the characteristics of projects using 4GL’s with the characteristics of projects using proceoural languages. pare the systems development prac‘ects using 4GL’s with those using ages. e :henefits and limitations o 4GL’s in systems development.
The sampie for this study consist organizations in four cities listed of Top Computer Executives [22]. tors in each organization received a letter explaining the purpose and study. Approximately a week later, each director received two questionnaires, one asking about the characteristics of a project using a fourth generation language and the second asking similar questions about the characteristics of a project using a procedurji9 language. They were asked to distribute the questionnaires to project m sponsible for the two types of projects. Each questionnaire asked about project characteristics, such as cost, duration, size, and type. Respondents were asked to describe their al#cations, including scope, data volum retention, scheduling requirements, also dealt with ap-
~nfmnation & Management
M. Sumner, R. Benson / Impact $&L’s
ity assurance procedures being practiced. Respondents were also asked to describe the success factors and pitfalls of using 4GL’s and to identify the characteristics of projects which they felt were suitable for them.
Table 2 Number of employees in responding firms
4. F
2,ouu co 2$99 r,ooo to 1,999
dthdtudy
Thirty-three respondents with experience in both 4GL and procedural language projects returned both questionnaires. An additional ten respondents returned only procedural language questionnaires or indicated that their organizations had no experience using 4GL’s in MIS systems development. This represented a response The low percentage of project managers returning both 4GL project and procedural project questionnaires may indicate that many of their fii were not using 4GL’s in production data processing projects. 4.1. Chatacteeristics of the Respondents The respondents represented large and smaII . . 11s in many different industries. A of the types of industries of the re: spondents is shown in Table 1. The number of employees in these fkms ranged and the average was 8,032. A from to 20 detailed breakdowu is shown in Table 2. The number of full-time data process’ sionals in the firms ranged from 15 to an average of 242. The distribution is shown in TM& 3.
Number of employees
Number of firms
10,000 and over S,W to 9,999 4,ooo to 4,999 3,090 to 3,999
6 7 1 S
83
3 6 S
under 1.000
Table 3 Number of data proce&ng
professionals
Range
Number of ftrms
1 toso 51 to200 Gver 2W
12 11 10
The application development backlog was 66 months for all the firms; the average maintenance backlog was 27 months. In 72 percent of the firms, a formal systems deveIopment methodology was beiig used. The size of these bat ogs is consistent with the results of prior studi=, with invisible backlogs of projects not yet approved as large as eight years. 4.2. Pmject Churacteristics A framework developed by Alloway and Quillard was used to categorize each project by type. Definitions are given in Table 4.
Tab!e 4 ARoway and Quillard’s system types
Type of industry Insurance and financial services Manufacturing Petroleum, steel Public utilities Banking Health services Government and education Pharmaceuticals Retailing Communications Pood Products
Number of fvms 6 6 5 3 3 -\ 1. 2 2 2 1 1 33
Project type --
Deftiuon
Monitor
A system which monitors daily detail activity producing standard reports on a fixed schedule. A system which processes detail acuvity reports where the definition of exception conditiors is fixed. A system which provides a database with flexible inquiry ability, enabling managers to design and change their monitoriig a~! exception reports. A system which provides data analysis capabilities and the appropriate database to support managerial decision-making.
Exce;:tior
Inqui$
Analysis
84
Information & Mmagement
T4cAniqrreS
Approximately two-thirds of the 4GL projects fen into the inquiry and analysis categories. Many of these projects involved setting up on-line databases so that users could have access for query and reporting purposes. They included on-line access to construction project expenditures, pat&us records, sales history data, and customer order status information. Other databases were set up for monitoring and tracking purposes. Systems to track union employees, patents, job applications,inventory, and customer credit history were all designed using 4GL’s. Few projects involving transactions processing used 4GCs. In contrast, nineteen of the procedural language projects were accounting and financial systems. These were largely transactions processing systems involving file maintenance, updating, and reporting. Systems supported c stomer invoicing international general ledger, pipeline tation accounting, and automated Nine projects involved the develop systems to replace old batch ones. In three instances, new on-line order entry and invoicing systems were being designed. In on-line personl trust system was to replace an antiquated batch system. Of these procedural language projects, four were tracking and two were analysis systems. The financial statement and market analysis systems in particuhu we= des
designed to automate existing operational paperwo pondents were asked to categorize their projectsusingAlloway and Quillard’s framework; the results are shown in Tiable 5. Seventy percent of the 4GL sy percent of the procedural language inquiry systems. In addition, 50 4GL projects were analysis type
Table 6 Number of applications in wmbined
categories
system type
4GL
Procedura!
Mon.itoring/exception Monitoring/inquiry Inquiry/analysis Total projects
7 12 13 33
11 14 10 32
languages. In conpared to ural lang&Uge systrast, 81 tems were monitoring in nature, compared to 54 percent of the 4GL systems. Many of the respondents classified theii projects in multiple categories. The most common combinations were “monitorin “ inquiry and analysis”. jects in combined categories was analyzed, more monitoring and exception systems were beiig developed ausingprocedural languages, and more iind analysis systems using 4GL’s, as sh 6. Wowever, the number
systems had built-in inquiry capability. 4.3. Project Size, Cart, and Duration About three-fourths of the projects were new systems development projects, and an additional 20 to 25 percent involved the redesign of existing systems, as shown in Tdle 7. The projects using procedural languages averaged 17.75 months in duration, while 4GL projects averaged 12.4 months. T&le 8. The person days requ o accomplish the
anguages were used were longer in duration.
Table 5 Number of applications System type
4GL
in’onitoa
18
Exception
Inquiry Analysis Total projects
ROdUGd
‘1
*# ..3 16 33
-- .~
26 13 18 11 32
Table 7 Number of projects by type
Type of
prc$xt
Total projects
Procedurd
33
32
Information & Management
M. Sumner, R Benson / Impact of &L’s
Table 8 Projectcost
85
ers in selecting an appropriate approach, Shementa, Kamp, Hanso;l, and Simpson evaluated the characteristics of applications which rqked traditional vs. 4CL development (ZL]. Ihey r-mmended traditional development for organizauontide systems development projects with high data volume, WelkMine ouQmts, multiple wo&tations, md moderate to high system complexity. security was important audit automated data recovery to
Table 9 Pmject
capacity to build prot can be ~ntinuously re ment are met. Prototyping
A variety of different fourth generation S developers. FOCUS
tools
were mentioned
by at
pointed to lack of r resistance as factors ive use of 4GL owever, training of project staffs was considered “moderately adequate” by most respondents. In addition, the attitude of project staff members toward the use of 4GL’s was considered ive”.
as
an application is primarily a reporting or decision support system, or 151.Good opportuni in systems which interactive, and w the presentation and format&tig of data [4,17]. However, prototyping with &L’s is not suitable in all projects. When a project involves the automation of a well-defii& system, when there are large data volumes, where application complexity is great, znd when computations are complex, prototyping will probably not work we!l. Prototyping will also not work well when the information systems staff is not willing ta develop prototype builders and when users are not willing to invest time in development. this study, project managers were asked to be the number of users, workstations, and d locations; application scope; data volume; data pertinence; data retention; data recovery prxedues; and system life expectancy of their projects. &spo&ents weic L&G asked to provide shed& hg requirements, variability of output, level of SXUI-&Y, level of audit, data currency, complexity of program logic, and application significance. 6.1. Users, Locations, and Scope me average number of concurrent u~r;~s, geegraphic lotx&ms, and worYkstations was greater ural language projects akes sense: the pr guage prcjects were older, well-established appfi-
86
information & Management
Techniques
Table 10 System users System chracteristics
4GL
Procedural
NUIX&~of concurrent users NW&~-X oi geographic locations Number of workstations
32 8 169
113 14 244
Thus, high-volume transactions processing systems requiring data recovery are being developed using produral languages. The high data volumes of many of the 4GL applications probably meant that copies of production data files were being used for data query and reporting purposes.
ik?. App&wtiOn Characteristics Table 11 System life expect;ancy System life
4GL
RotXdUGd
Under one year One to five years Over five years
10% 48% 42%
0% 30% 3nm IUio
cations. ‘Ihe 4GL projects were more short-lived, as shown in Table II.
Olle of the limitations of 4GL’s expressed in trade literature is their inability to support high volume transactors systems efficiently [lo). Although the data volume supported by 4GL and procedural language systems was similar, the transactions volume was hiE;her in traditional pro. jects, as shown in Tab! One of the study iss; -_L he legal retention of data. Legal retention of .~.i:z was an issue in 70 percent of the project using procedural languages, but in only 29 percent using 4GL’s. In the 20 traditional projects in which data was legally required to be retained, the average retention was 6.4 years. In contrast + data retention was a concern in only eight 4GL projects, with the average retention time of 3.1 years. One of the major issues affec transactions processing systems is data rc,.2*.,n> after system failure. This problem was considered of greater concern in the traditional projects, as showwnin Table 13. Table 12 hita and transaction volplme~ Data volume Under loo0 records 1000 to 10,000 records Over 10,000 records Not applicable
Certain application characteristics, including scheduling of output, variability of output, level of security, importance of data currency, and complexity of program logic, were reported using a I to 5 Likert scale; e.g., respondents were asked to indicate the level of system security with a “5” meaning full security and a “1” meaning minimum security. The mean of the responses were calculated, and a student t test was used to determine whether the differences between the means for the 4GL and procedural language projects were statistically significant at the 0.05 level. T&te 14 shows the differences between the means for the 4GL and procedural projects for scheduling requirements, variability of system output, and level of audit required of system processes. to be schedSystem outputs were more uled and well-defined in projects designed using procedural languages. Where program logic was highly complex, procedural tools were being used. Moderate audit and security procedures were considered acceptable for 4GL applications. 6.4. Application Significance Since applications written by traditional develment methods are ect to strict audit and security procedures, organizations feel that corporate data systems with business significance chould be developed by the methods. Systems as kite the business and developers were fin impact of and procedural applications using a 1 to 5 scale, t vith a “5” meaning
Information & Management Table 13 Data recovery procedures Type of recovery
4GL
Procedural
30%
58%
48% 12%
39% 3%
Automat& recovery of data to failed transaction; upto-the-minute recovery Automated recoveq to last backup; recovery to previous day Manual recovery of data
Table 14 Application characteristics Application characteristics
war&
Scheduling of system outputs
structuring of system outputs Level of audit required of system travel of system security Pmportance of data currenq -p!eJdacfp=wmw
* statistically siflicant
‘Table 15 Application
%GL
Proccdural
Tvalue
3.03 3.08 3.00 3.62 3.32 3_32
3.67 3.96 4.09 3.90 3.94 3-94
1.952.58’ 3.80* 0.94 166 1.54
at the 0.05 leveL
significance
Applicationcharachstics
lh3sksssignifii Finawzial impact * Statistically sign&ant
4GL
ProceduraI
T value
321 3.38
3.84 3.55
2.110.52
at the 0.05 level.
that the application had significant impact. The fiidings are shown in T&Ie 15. These fiidhgs indicate that applications with greater business significance and with greater financial impact were more likely to be developed with traditional methods. In the area of business significance, the difference between the means for the 4GL projects and the procedural language pro&Z =as statistically significant at thz 0.05 Table 16 Time distribution ir1 &I,
projects
Phases
Percefilage of time
Requirements analysis General design Detailed design ~mp~erne~~tio~
22% 22% 22% 23% II%
lever. This reinforces the view that systems developers were not willing to risk developing important business systems using a technology with which they had limited experience.
7. Appiication
Pra&Es
Fourth generation languages can be used for prototyphqg, followed by implementation using a ;theyeanbed on once requirements be used to support querie& systems development; and they can be integrated throughout an information engineering process involving information planning, data administ&?&t, and at. There is some evidence that beused to B* the application developmeet process. When prototyping is used durkg analysis, Alavi reports, the process of specifying requirements is shorter When 4G are used during the implementation phase, uctivity increases f7,8]. Respondents were asked to proximate percentage of time phases of the systems devel 4GL systems; their estimate 16. Similar percentages ef time speat i3I: vzshs phases of the life cycle were reported also for the projects in which procedural languages were used. Fourth generation language users did not indicate that their use saved time, particularly in detailed design and implementation. Project managers reported that they saved 25 percent of the time normally spent in detailed design and 31 percent of the tune usually spent in implementation. These findings would support the view that 4GL’s were primarily being used to support coding and testing in systems development projects. Another impact of 4GL development is the re-distribution of responsibility for systems devellopment. Users, it is felt, can work with system rate and refine prototypes using builders to anagers responding to this study 4GYs. The S professionals were asked to identify whether for each of the or users were primarily responsi steps in the systems development process in 4GL and procedural projects. onsible for problem defiition ssment in most of the projects
88
Techniques
8. Benefits and Limitations of Fourth Generation Tools
Table 17 Systems development responsibilities MIS responsibility
User responsibility
Procedural 4GL
?r&io;al
4GL
Problem definition Feasibility study Systems analysis Generaldesign Detaileddesign fieg
15 22 30 27 30 32
OptXMiOnS
25
Maintenance
29
10 16 29 26 28 30 21 27
25 12 4 9 5 3 10 5
26 14 9 9 6 8 11 7
Total projects
32
33
32
33
Projwt phases
-Tported, but MIS professionals were responsible for most 9:’ the other project phases. Details are given in T&e 17. Apparently the systems development process, and MIS professionals’ responsibihties in it, are not significantly different in 4GL projects. Development methodologies have not been directly modified by use of new tools. Although a number of studies have shown that end-users who develop applications using 4GL’s do not always follow quality assurance procedures, there was no indication in this study that MIS professionals conducting 4GL projects did not adhere to practice such as data validation and documentation. Table 18 ijlustrates this. Although the nature and scope of systems development projects in which 4GL’s were used were different, quality assurance procedures were being maintained. MIS professionals adhered to the requirements of their systems development methodologies regardless of the type of languag:: being USC!d.
Table 18 Systems development prxtices
A list of productivity impacts and drawbacks of using 4GL’s was developed, and respondents were asked to rank these impacts in terms of their importance. 8.1. The Benejits of Fowth Generation Tads One of the main benefits cited for 4GE’s is reduction in application development time. Productivity increases over COBOL deve!qme~t range from between 5 to 1 to 300 to 1. Case studies also report that 4GL’s have been used to speed the development of systems that are urgently needed [ll). Prototyping facilitates user involvement in systems design and makes it possible to match system features with ‘user expectations in less time *a traditional methods [9]. Prototyping can decrease the time spent in analysis and design because user requirements are satisfied more rapidly [19]. Another benefit attributed to the use of 4GL-‘s is a decrease in the time spent on the debugging and maintenance phases. Coding, testing, and debugging comprise about half of a total program’s cost. Maintenance, an ongoing concern, can be alleviated by using program generators as to invoke coded modules stored in libraries and to combine them on demand to produce and to enhance applications. Respondents were asked to rank the impacts attributed to 4GL tools in order of their importance. A rank of “1” was to indicate the most significant impact. The results were used to c&ulate an average r score for each of the statements. The findings are shown in Table 19. The major positive impacts cited were consistent s mo!;t frequently described in case articles.
of FourthGeneration LAW
Systems development practices
4GL
Procedural
8.2. The Limitaticw wges
Data validation . ” T&z Syste: documentation User documentation Data security arrangements Backup and recovery procedures
27 28 26 22 22 19
26 30 29 30 25 30
rofessionals have consistently expressed that 4GL’s cannot provide the performance necess
Total number of projcxts
33
32
Informah
& ItianagemenJ
M. Sumner, R Benson / Impact of 4GL’s
Table 19 Benefits of fourth generation languages a Average rank score
Impact Improvement in application development time Ability to handle ad hoc reporting needs quickly
1.7 3.0
Ability to use prototyping in requirements definition Easier to handle maintenance impacts Better understanding of users’requirements Better quality systems design Lsstimespentindocumentation 8 scale: “1” = most importa impact.
3.1 4.6 4.1 3.3 5.9 impact to “8” = least important
propriate forpduction data prming oftenm about one-3rd as fast as COBOL. Other issues affecting the use of 4GL’s relate to the lack of integration among 4GL products and the lack of integration of 4GL’s aEd pmcedural languages. Various 4GL tools, including query languages, report generators, and application generators have unique features and require learning different comman ds. Because special purpose tools often need to be learn& programmers face an ongoing learning curve [20]. Table 20 Limitstions
of four& generation I-
a
Drawback
Average rank score
High useobmachineresourceS Inefkient processing of high transaction volumes Difficulty implementing complex programming logic Lack of integration between 4GL’s and procedural languages High rate of chargeback for 4GL use Tendsq to develop badly documented systems Lack of integration among 4GL products Lack of integration between 4GL’s and the life cycle
2.6
’ Gale = tificant &;Ljvback .
$9
Another argument against &L’s is that they foster poor design methods and lead to the development of poorly documented systems. Because systems using 4GL’s are so easy to construct, scrap, and re-invent, it is easy to take design short-cuts 131.The availability of 4GL’s may foster the deve!opment of “shadow systems’* that duplicate production systems and enable developers to circumvent production schedules. These systems can cause confusion with regard to the validity of reports because they use production data extracts which are not updated as frequently as production data files. It is more difficult to provide an audit trail to validate 4GL programs, because the trail is often covered [6]. Respondents were asked to rank the drawbacks attributed to 4GL’s according to their importance. g of ““1”was used t0 in& A significant drawback. The results were used to calculate the average rank scores for each; they are shown in T&ie 20. Fourth generation lanpage systems developed by MIS professionals were Wig fully documented and these tools were fully integrated into the existing life cycle methodology, which explains why these were not viewed as drawbacks. Much of the criticism about pooriy documented systems applies to the tuse of 4GL’s by end-users, not by MIS professionals. The lack af integration of 4GL’s and procedural languages may not have been a major conceA”nbecause 4GL tools were primarily being used to support query aml reporting subsystems. f&t of intzgration among 4GL products was probably not viewe as a concern because most MIS organizations had standardized on the use of one 4GL.
2.7 3.1
4.4 4.9 5.1 5.4 5.5
Although there are reports of project successes and failures in trade literature, very few articies identify the characteristics of systems suitable for 4GL development. In one article, Culhtm suggests that management must be willing to implement a project in small pieces and is use an iterative design approach to apply a 4GL successfully. oreover, success requires adequate machine resources, a thoroughly wledgeable developme umentation of the fi ete version.
90
Information & Management
Techniques
PO.summary
Table 21 Characteristics of “goad” 4GL projects Project characteristics
Number of responses
Ad hoc reporting and inquiry needed Prototyping needed Urgency of development required Low traixactions volumt?s High end-user interaction Independent, self-contained system
IG 7 7 7 5 5
Flexible,highly changeablesystem
5
When the respondents were asked if the use of &L’s in their projects was a success, 29 of 33 said ):zs, one said no, and the others did not have enough experience to ow. Respondents said that speed was the -majorr-n for project sup-. Eight of the 33 managers reportti that they were able to complete their projects in a shorter time frame with 4GL’s. A number of respondents gave the ability to prototype application requirements, to meet USA requirements, to support ad hoc reporting needs, and to change preliminary designs as re2sons for project success. The final question asked respondents to name three characteristics of an application developrnenk projcrt which would make it suitable for development using a 4GL. When these answers were summarized, the major characteristics were situations where ad hoc reporting and inquiry were needed, where prototyping was desirable, where there was urgency, and where tr2nsactions volumes were low. Fourth generation tools could effectively support the development of independent, self-contained systems and of highly changeable, dynamic systems. When users were highly involved in interacting with an informztion system and were willing to bL
The results of the study illustrate that project managers have mrde B clear distinction between the types of projects that ape appropriate for development using procedural 12nguages and for 4GL’s. Procedural projects cost more, required more effort, had higher transactions volumes, had more users, and were generally larger in scale. In contrast, 4GL projects had more variable outputs, less security requirements, less chance of audit, and less complexity. The “perfect” 4GL project was an inquuy and reporting system with kss structured outputs, dynamic scheduling re@rements, and low complezty; s’adalone applications with low transactions volumes were “ candidates. Although most of the respondents indicated to speed deve!op,7lent, their use that 4GL’s he1 did not alter the traditional systems development life cycle methodology. Full documentation and quality assurance procedures were beiig followed for both types of projects. User participation in systems development was primarily felt during the problem definition and feasibility study phases of the life cycle for both 4GL and procedural language projects.
The experiences suggest some issues relating to 4GL development, mainly dealing with project selection and system development methodology. ii. 1. Project
Selection
e serious deficiency of
experience of project managers may have been due to selection of projects with characteristics
hford dion & Marragement
11.2. Systems
M. Sumner, R. Benson / Impact of 4iX.k
eve jopment
Methodology
Although the MIS professionals realized that the use of 4GL’s made it possible to speed up systems development activities, the characteristics of the projects were quite different from those of procedural projects. The improvement in apphcation development time could have been attributed to the difference in the nature and scope of the other words, if a 4GL had been transactions volume production projects, the productivity have been so obtious. inl projects with high transaction volumes, it could not be determined if large traditional projects would @ave been impacted by the use of 4GL’s. The current systems development life cycle was tely altered for 4GL were being 0 *&e life cyc!e to up cert! phases, such as prototyping and code generation. Fourth generation tools might have a greater impact on application development if a systems deincorporating their use velopment S organizatioRs. were introd The effective use of 4GL’s requires a software development environment which combines new technology with training, procedures, and top management support. The environment must suprt experimentation through pilot projects. Tools, workstations, and technical support personne! must be readily available to support the environment. If a programmer has to move to a new to q*end hours obtaining access workstation to databases needed for 4GL projects, then_MIS management is not fully behind 4GL development. Although application development productivity can be improved with the use of 4GL’s, their use needs to be coupled with other productivity strategies, such as developer workstations, team approaches to testing, and subroutine sharing. Re-usable libraries can be utilized effectively only if programmers are already trained in structurexl
le projects are selected for organizat:ons may experi-
91
ence considerable success wit 4(3L’s. &den= indicates that pro+ct managers are deliberately selecting projects witZ~characteristics which make them suitable for 4GL development. However, greater productivit:r improvements may occur if MIS organizations use systems develo odologies which support 4GL use effective organizational strategies supporting their USe.
Abi. Mayam. “The Evolution of fnformatio~~ systems ~ehpment Approach: Some Fiehi Obser~atilons,” &Z~U &se. Spring 1984. pp. 19-24. Ahoway, Robert M. and QuiEard. Judith A., “User Manager’s Systems NW MIS Qtfmterb. .Jum 1983, pp. 27-41. Bernstein, Amy, “Shortcut to systems Design+” B&&%%.r C?xzzqt&er S_v5&?m.June 1985. Bum!%,RN. and &nn& A-R., "+kCkg t-heAppmpria:e App!.ication Development Methodology.” Data Base, Fall 1985. pp. :9-23. Canning, Richard G, ed. “Tools to Rejuvenate Your Old Systems,” EDP Analyzer, Vol. 22. No. 4, A@l 1984, pp. l-14. Christoff, Kurt A., L1Building a Fourth Qenerntton Eavirontnent,” Duration, VoL 31, No. 18, Sept. 1985. Cobb, Richard H., “In Praise of 4GL’s,” Datamatiwt . July 1985, pp. W-96. Cullum, Ronald, L., “Iterative Development” Datm;i~::, Feb. 1985, pp. 92-98. Cook, Rick, “Automated Tools are Backlog Breakers,” ComprrterDec-isi.n.~-April 1085, pp. 92-102. Grant, FJ., “The Downside fo 4GL’s.” Datamation, July 1985, pp. 99-104. Green Jesse, “Productivity in the Fourth Generation: Si Case Studies,” Journal of Management Information Systems, Vol. 1, No. 3, inter 1984-85, pp. 49-63. GremiJiion, Lee L. and Pybum, Phillip, “Brezking the Systems Development Bottieneck,” Haruard Business Reuiew, March-Apr. 1983, pp.. 130-137. Heffeman, Henry, “Trade-offs in FOCUS, COBOL Test.” Government Computing News, June 1985. Jenkins, A. Milton. “Surveying the Software Generzlor Market,” Datcsmatian, September 1985. KuIL David, -‘Anatomy of a 4GL Disaster,” Computer Decisions, Vol. 8, No. 4, Feb. 1986, pp. 58-65. Martin, James, f~urrf2 Generation Languages: Vulzm~ 1. Principles (fEnglewood Cliffs. NJ: Prentice-Hall, 1985). Mason, R.E.A. and Carey, T-T., “Prototyping Interactive information Systems,” Communications of the ACM. Vol. 26. No. 5, May 1983, pp. 347-354. McFarlan, F.W., -’Portfolio Approach is Inform&On Systems,” H~tvard Business Review, S+:.-Oct. 1981. PP. 142-150.
92
191 humann,
AD. and Jenkins, A. ., “Prototyping: The fo: SI Items Development,‘” MIS Quarter&, Vol. 6, No. 3, Sept. 1982, pp. 29-44. New Paradigm
Techniques
OQ@kNions
ts, and low transactions tions of 4GL’s and are gene&y *&eir use.
the benefits and limitamaking go& decisions abrt
Km&: Fourth generation languages, Systems development, Application development aids, Prototyping.
today
are facing a tough set of
and systems programmers continues to be a constraint 121. Methods of improving the productivity of the application development process include the use of software packages, the support of end-user application development, and the use of fourth generation languages MGL) [12]. While these toofs have been used extensively to sup computing there is Limited evidence systems development projects conducted by MIS professionals. 4GL’s can be used to create programs for many applications with substantially fewer lines of code than COBOL. Features like on-line data dictionaries, libraries of re-usable modules, and pre-programmed functions can speed up the application building pr-s. These tools can also effectively support the prototyping approach There is some evidence of the tarpes of productivity increases through the use-of 4GL tools. According to research by Dr. Ebe
is an Associate Profesthe Department of Management Information Systems at the School of Business at Southern Illinois Unitersity at Edwardswille. Her teaching and research interests include information systems design, end-user and departmental computing, and office automation. She has authored textbooks in computer concepts, management information systems, and automated office systems management.
037%7206/88/%3.5~ @ 1988, Elsevier Science Publishers B.V. (North-Holland)
R&ert Bemion is Dean of ahe School of Technology and In iormri ‘ion Management at Weshingtc,n Un!versity in St. Louis. He is also Associate Vice-Chanceilor, Compu tin& and Communications with adninistrative responsibility for university-tide conputing. His academic interests have centered on the Enterprise-wide Information Management projx t between the Center for the Stud) of Iota Processing and IBM’s Lo; Angeles Zcientific Center
82
Information & Management
Techniques
the development time for a small-scale prO!@t 10,ilOO to 20,000 lines of COBOL) of typical complexity was slightly over 10 person-days with LING (Burroughs’ fourth generation tool) as compared with 200 person-days with COBOL. ‘This represents a 17 to 1 productivity increase. With large-scale development projects (e.g., 200,000 line of COBOL), the productivity ratio was 45 to 1. In both cases, function point analysis was used to compare procedural and nonprocedural code (161. case studies in recent trade publications also depict productivity gains as measured by percentage improvement in overall time and labor savings and accomplishing more work with fewer people. Ease of learning, through help menus and diagnostics, and the prototyping approach have frequently been cited as qualitative impacts of 4GL’s. However, experiences with 4GL’s are not always successful. Gne involved the CisastroW Ciisequences of using a 4GL to develop the New Jersey Division of Motor Vehicles’ new computer terminals system. It was :o have more than 1 with thousands of transactions per day accessing a data base containing records on several million licensed drivers, 4i~ mill_iou regisierti veiiicies, and 20 million title documents. In spite of unacceptable response times during a preliminary system test, the project used an untried 4GL and the system inevitably crashed. Since the tool was inadequate for the job of developing a complex on-line system requiring fast response, the system was redeveloped using both the 4GL and a procedural language. Concern over the machine resource utilization problem has also been cited by Atre Fourth generation language systems for production processing run about one-third as fast as COBGL. In another test, a 4GL demonstrated a 2 : 1 improvement in development time, but the program ran 30 times slower 1131. Concerns about machine utilization, lack of integration among 4GL projects, and programmer resistance have delayed the e ve use of 4GL’s in sy.:tems development. M IS professionals are not sure how 4GL tools can be used sue fully. Managers need to reco cm be used effect gement and org r their effective use.
2. Objectives of the Study
(e.g.,
A number of orgiurizations have accunntlated experience in using 4GL’s over the past four to five yeais. This study is designed to learn the characteristics of projects in which 4CL’s have been used and to provide guidelines about the types of projects in which they can be used effectively. The specific objectives are: (1) To identify the nature and scope of systems development projects in which &L’s are being Used.
(2) To compare the characteristics of projects using 4GL’s with the characteristics of projects using proceoural languages. pare the systems development prac‘ects using 4GL’s with those using ages. e :henefits and limitations o 4GL’s in systems development.
The sampie for this study consist organizations in four cities listed of Top Computer Executives [22]. tors in each organization received a letter explaining the purpose and study. Approximately a week later, each director received two questionnaires, one asking about the characteristics of a project using a fourth generation language and the second asking similar questions about the characteristics of a project using a procedurji9 language. They were asked to distribute the questionnaires to project m sponsible for the two types of projects. Each questionnaire asked about project characteristics, such as cost, duration, size, and type. Respondents were asked to describe their al#cations, including scope, data volum retention, scheduling requirements, also dealt with ap-
~nfmnation & Management
M. Sumner, R. Benson / Impact $&L’s
ity assurance procedures being practiced. Respondents were also asked to describe the success factors and pitfalls of using 4GL’s and to identify the characteristics of projects which they felt were suitable for them.
Table 2 Number of employees in responding firms
4. F
2,ouu co 2$99 r,ooo to 1,999
dthdtudy
Thirty-three respondents with experience in both 4GL and procedural language projects returned both questionnaires. An additional ten respondents returned only procedural language questionnaires or indicated that their organizations had no experience using 4GL’s in MIS systems development. This represented a response The low percentage of project managers returning both 4GL project and procedural project questionnaires may indicate that many of their fii were not using 4GL’s in production data processing projects. 4.1. Chatacteeristics of the Respondents The respondents represented large and smaII . . 11s in many different industries. A of the types of industries of the re: spondents is shown in Table 1. The number of employees in these fkms ranged and the average was 8,032. A from to 20 detailed breakdowu is shown in Table 2. The number of full-time data process’ sionals in the firms ranged from 15 to an average of 242. The distribution is shown in TM& 3.
Number of employees
Number of firms
10,000 and over S,W to 9,999 4,ooo to 4,999 3,090 to 3,999
6 7 1 S
83
3 6 S
under 1.000
Table 3 Number of data proce&ng
professionals
Range
Number of ftrms
1 toso 51 to200 Gver 2W
12 11 10
The application development backlog was 66 months for all the firms; the average maintenance backlog was 27 months. In 72 percent of the firms, a formal systems deveIopment methodology was beiig used. The size of these bat ogs is consistent with the results of prior studi=, with invisible backlogs of projects not yet approved as large as eight years. 4.2. Pmject Churacteristics A framework developed by Alloway and Quillard was used to categorize each project by type. Definitions are given in Table 4.
Tab!e 4 ARoway and Quillard’s system types
Type of industry Insurance and financial services Manufacturing Petroleum, steel Public utilities Banking Health services Government and education Pharmaceuticals Retailing Communications Pood Products
Number of fvms 6 6 5 3 3 -\ 1. 2 2 2 1 1 33
Project type --
Deftiuon
Monitor
A system which monitors daily detail activity producing standard reports on a fixed schedule. A system which processes detail acuvity reports where the definition of exception conditiors is fixed. A system which provides a database with flexible inquiry ability, enabling managers to design and change their monitoriig a~! exception reports. A system which provides data analysis capabilities and the appropriate database to support managerial decision-making.
Exce;:tior
Inqui$
Analysis
84
Information & Mmagement
T4cAniqrreS
Approximately two-thirds of the 4GL projects fen into the inquiry and analysis categories. Many of these projects involved setting up on-line databases so that users could have access for query and reporting purposes. They included on-line access to construction project expenditures, pat&us records, sales history data, and customer order status information. Other databases were set up for monitoring and tracking purposes. Systems to track union employees, patents, job applications,inventory, and customer credit history were all designed using 4GL’s. Few projects involving transactions processing used 4GCs. In contrast, nineteen of the procedural language projects were accounting and financial systems. These were largely transactions processing systems involving file maintenance, updating, and reporting. Systems supported c stomer invoicing international general ledger, pipeline tation accounting, and automated Nine projects involved the develop systems to replace old batch ones. In three instances, new on-line order entry and invoicing systems were being designed. In on-line personl trust system was to replace an antiquated batch system. Of these procedural language projects, four were tracking and two were analysis systems. The financial statement and market analysis systems in particuhu we= des
designed to automate existing operational paperwo pondents were asked to categorize their projectsusingAlloway and Quillard’s framework; the results are shown in Tiable 5. Seventy percent of the 4GL sy percent of the procedural language inquiry systems. In addition, 50 4GL projects were analysis type
Table 6 Number of applications in wmbined
categories
system type
4GL
Procedura!
Mon.itoring/exception Monitoring/inquiry Inquiry/analysis Total projects
7 12 13 33
11 14 10 32
languages. In conpared to ural lang&Uge systrast, 81 tems were monitoring in nature, compared to 54 percent of the 4GL systems. Many of the respondents classified theii projects in multiple categories. The most common combinations were “monitorin “ inquiry and analysis”. jects in combined categories was analyzed, more monitoring and exception systems were beiig developed ausingprocedural languages, and more iind analysis systems using 4GL’s, as sh 6. Wowever, the number
systems had built-in inquiry capability. 4.3. Project Size, Cart, and Duration About three-fourths of the projects were new systems development projects, and an additional 20 to 25 percent involved the redesign of existing systems, as shown in Tdle 7. The projects using procedural languages averaged 17.75 months in duration, while 4GL projects averaged 12.4 months. T&le 8. The person days requ o accomplish the
anguages were used were longer in duration.
Table 5 Number of applications System type
4GL
in’onitoa
18
Exception
Inquiry Analysis Total projects
ROdUGd
‘1
*# ..3 16 33
-- .~
26 13 18 11 32
Table 7 Number of projects by type
Type of
prc$xt
Total projects
Procedurd
33
32
Information & Management
M. Sumner, R Benson / Impact of &L’s
Table 8 Projectcost
85
ers in selecting an appropriate approach, Shementa, Kamp, Hanso;l, and Simpson evaluated the characteristics of applications which rqked traditional vs. 4CL development (ZL]. Ihey r-mmended traditional development for organizauontide systems development projects with high data volume, WelkMine ouQmts, multiple wo&tations, md moderate to high system complexity. security was important audit automated data recovery to
Table 9 Pmject
capacity to build prot can be ~ntinuously re ment are met. Prototyping
A variety of different fourth generation S developers. FOCUS
tools
were mentioned
by at
pointed to lack of r resistance as factors ive use of 4GL owever, training of project staffs was considered “moderately adequate” by most respondents. In addition, the attitude of project staff members toward the use of 4GL’s was considered ive”.
as
an application is primarily a reporting or decision support system, or 151.Good opportuni in systems which interactive, and w the presentation and format&tig of data [4,17]. However, prototyping with &L’s is not suitable in all projects. When a project involves the automation of a well-defii& system, when there are large data volumes, where application complexity is great, znd when computations are complex, prototyping will probably not work we!l. Prototyping will also not work well when the information systems staff is not willing ta develop prototype builders and when users are not willing to invest time in development. this study, project managers were asked to be the number of users, workstations, and d locations; application scope; data volume; data pertinence; data retention; data recovery prxedues; and system life expectancy of their projects. &spo&ents weic L&G asked to provide shed& hg requirements, variability of output, level of SXUI-&Y, level of audit, data currency, complexity of program logic, and application significance. 6.1. Users, Locations, and Scope me average number of concurrent u~r;~s, geegraphic lotx&ms, and worYkstations was greater ural language projects akes sense: the pr guage prcjects were older, well-established appfi-
86
information & Management
Techniques
Table 10 System users System chracteristics
4GL
Procedural
NUIX&~of concurrent users NW&~-X oi geographic locations Number of workstations
32 8 169
113 14 244
Thus, high-volume transactions processing systems requiring data recovery are being developed using produral languages. The high data volumes of many of the 4GL applications probably meant that copies of production data files were being used for data query and reporting purposes.
ik?. App&wtiOn Characteristics Table 11 System life expect;ancy System life
4GL
RotXdUGd
Under one year One to five years Over five years
10% 48% 42%
0% 30% 3nm IUio
cations. ‘Ihe 4GL projects were more short-lived, as shown in Table II.
Olle of the limitations of 4GL’s expressed in trade literature is their inability to support high volume transactors systems efficiently [lo). Although the data volume supported by 4GL and procedural language systems was similar, the transactions volume was hiE;her in traditional pro. jects, as shown in Tab! One of the study iss; -_L he legal retention of data. Legal retention of .~.i:z was an issue in 70 percent of the project using procedural languages, but in only 29 percent using 4GL’s. In the 20 traditional projects in which data was legally required to be retained, the average retention was 6.4 years. In contrast + data retention was a concern in only eight 4GL projects, with the average retention time of 3.1 years. One of the major issues affec transactions processing systems is data rc,.2*.,n> after system failure. This problem was considered of greater concern in the traditional projects, as showwnin Table 13. Table 12 hita and transaction volplme~ Data volume Under loo0 records 1000 to 10,000 records Over 10,000 records Not applicable
Certain application characteristics, including scheduling of output, variability of output, level of security, importance of data currency, and complexity of program logic, were reported using a I to 5 Likert scale; e.g., respondents were asked to indicate the level of system security with a “5” meaning full security and a “1” meaning minimum security. The mean of the responses were calculated, and a student t test was used to determine whether the differences between the means for the 4GL and procedural language projects were statistically significant at the 0.05 level. T&te 14 shows the differences between the means for the 4GL and procedural projects for scheduling requirements, variability of system output, and level of audit required of system processes. to be schedSystem outputs were more uled and well-defined in projects designed using procedural languages. Where program logic was highly complex, procedural tools were being used. Moderate audit and security procedures were considered acceptable for 4GL applications. 6.4. Application Significance Since applications written by traditional develment methods are ect to strict audit and security procedures, organizations feel that corporate data systems with business significance chould be developed by the methods. Systems as kite the business and developers were fin impact of and procedural applications using a 1 to 5 scale, t vith a “5” meaning
Information & Management Table 13 Data recovery procedures Type of recovery
4GL
Procedural
30%
58%
48% 12%
39% 3%
Automat& recovery of data to failed transaction; upto-the-minute recovery Automated recoveq to last backup; recovery to previous day Manual recovery of data
Table 14 Application characteristics Application characteristics
war&
Scheduling of system outputs
structuring of system outputs Level of audit required of system travel of system security Pmportance of data currenq -p!eJdacfp=wmw
* statistically siflicant
‘Table 15 Application
%GL
Proccdural
Tvalue
3.03 3.08 3.00 3.62 3.32 3_32
3.67 3.96 4.09 3.90 3.94 3-94
1.952.58’ 3.80* 0.94 166 1.54
at the 0.05 leveL
significance
Applicationcharachstics
lh3sksssignifii Finawzial impact * Statistically sign&ant
4GL
ProceduraI
T value
321 3.38
3.84 3.55
2.110.52
at the 0.05 level.
that the application had significant impact. The fiidings are shown in T&Ie 15. These fiidhgs indicate that applications with greater business significance and with greater financial impact were more likely to be developed with traditional methods. In the area of business significance, the difference between the means for the 4GL projects and the procedural language pro&Z =as statistically significant at thz 0.05 Table 16 Time distribution ir1 &I,
projects
Phases
Percefilage of time
Requirements analysis General design Detailed design ~mp~erne~~tio~
22% 22% 22% 23% II%
lever. This reinforces the view that systems developers were not willing to risk developing important business systems using a technology with which they had limited experience.
7. Appiication
Pra&Es
Fourth generation languages can be used for prototyphqg, followed by implementation using a ;theyeanbed on once requirements be used to support querie& systems development; and they can be integrated throughout an information engineering process involving information planning, data administ&?&t, and at. There is some evidence that beused to B* the application developmeet process. When prototyping is used durkg analysis, Alavi reports, the process of specifying requirements is shorter When 4G are used during the implementation phase, uctivity increases f7,8]. Respondents were asked to proximate percentage of time phases of the systems devel 4GL systems; their estimate 16. Similar percentages ef time speat i3I: vzshs phases of the life cycle were reported also for the projects in which procedural languages were used. Fourth generation language users did not indicate that their use saved time, particularly in detailed design and implementation. Project managers reported that they saved 25 percent of the time normally spent in detailed design and 31 percent of the tune usually spent in implementation. These findings would support the view that 4GL’s were primarily being used to support coding and testing in systems development projects. Another impact of 4GL development is the re-distribution of responsibility for systems devellopment. Users, it is felt, can work with system rate and refine prototypes using builders to anagers responding to this study 4GYs. The S professionals were asked to identify whether for each of the or users were primarily responsi steps in the systems development process in 4GL and procedural projects. onsible for problem defiition ssment in most of the projects
88
Techniques
8. Benefits and Limitations of Fourth Generation Tools
Table 17 Systems development responsibilities MIS responsibility
User responsibility
Procedural 4GL
?r&io;al
4GL
Problem definition Feasibility study Systems analysis Generaldesign Detaileddesign fieg
15 22 30 27 30 32
OptXMiOnS
25
Maintenance
29
10 16 29 26 28 30 21 27
25 12 4 9 5 3 10 5
26 14 9 9 6 8 11 7
Total projects
32
33
32
33
Projwt phases
-Tported, but MIS professionals were responsible for most 9:’ the other project phases. Details are given in T&e 17. Apparently the systems development process, and MIS professionals’ responsibihties in it, are not significantly different in 4GL projects. Development methodologies have not been directly modified by use of new tools. Although a number of studies have shown that end-users who develop applications using 4GL’s do not always follow quality assurance procedures, there was no indication in this study that MIS professionals conducting 4GL projects did not adhere to practice such as data validation and documentation. Table 18 ijlustrates this. Although the nature and scope of systems development projects in which 4GL’s were used were different, quality assurance procedures were being maintained. MIS professionals adhered to the requirements of their systems development methodologies regardless of the type of languag:: being USC!d.
Table 18 Systems development prxtices
A list of productivity impacts and drawbacks of using 4GL’s was developed, and respondents were asked to rank these impacts in terms of their importance. 8.1. The Benejits of Fowth Generation Tads One of the main benefits cited for 4GE’s is reduction in application development time. Productivity increases over COBOL deve!qme~t range from between 5 to 1 to 300 to 1. Case studies also report that 4GL’s have been used to speed the development of systems that are urgently needed [ll). Prototyping facilitates user involvement in systems design and makes it possible to match system features with ‘user expectations in less time *a traditional methods [9]. Prototyping can decrease the time spent in analysis and design because user requirements are satisfied more rapidly [19]. Another benefit attributed to the use of 4GL-‘s is a decrease in the time spent on the debugging and maintenance phases. Coding, testing, and debugging comprise about half of a total program’s cost. Maintenance, an ongoing concern, can be alleviated by using program generators as to invoke coded modules stored in libraries and to combine them on demand to produce and to enhance applications. Respondents were asked to rank the impacts attributed to 4GL tools in order of their importance. A rank of “1” was to indicate the most significant impact. The results were used to c&ulate an average r score for each of the statements. The findings are shown in Table 19. The major positive impacts cited were consistent s mo!;t frequently described in case articles.
of FourthGeneration LAW
Systems development practices
4GL
Procedural
8.2. The Limitaticw wges
Data validation . ” T&z Syste: documentation User documentation Data security arrangements Backup and recovery procedures
27 28 26 22 22 19
26 30 29 30 25 30
rofessionals have consistently expressed that 4GL’s cannot provide the performance necess
Total number of projcxts
33
32
Informah
& ItianagemenJ
M. Sumner, R Benson / Impact of 4GL’s
Table 19 Benefits of fourth generation languages a Average rank score
Impact Improvement in application development time Ability to handle ad hoc reporting needs quickly
1.7 3.0
Ability to use prototyping in requirements definition Easier to handle maintenance impacts Better understanding of users’requirements Better quality systems design Lsstimespentindocumentation 8 scale: “1” = most importa impact.
3.1 4.6 4.1 3.3 5.9 impact to “8” = least important
propriate forpduction data prming oftenm about one-3rd as fast as COBOL. Other issues affecting the use of 4GL’s relate to the lack of integration among 4GL products and the lack of integration of 4GL’s aEd pmcedural languages. Various 4GL tools, including query languages, report generators, and application generators have unique features and require learning different comman ds. Because special purpose tools often need to be learn& programmers face an ongoing learning curve [20]. Table 20 Limitstions
of four& generation I-
a
Drawback
Average rank score
High useobmachineresourceS Inefkient processing of high transaction volumes Difficulty implementing complex programming logic Lack of integration between 4GL’s and procedural languages High rate of chargeback for 4GL use Tendsq to develop badly documented systems Lack of integration among 4GL products Lack of integration between 4GL’s and the life cycle
2.6
’ Gale = tificant &;Ljvback .
$9
Another argument against &L’s is that they foster poor design methods and lead to the development of poorly documented systems. Because systems using 4GL’s are so easy to construct, scrap, and re-invent, it is easy to take design short-cuts 131.The availability of 4GL’s may foster the deve!opment of “shadow systems’* that duplicate production systems and enable developers to circumvent production schedules. These systems can cause confusion with regard to the validity of reports because they use production data extracts which are not updated as frequently as production data files. It is more difficult to provide an audit trail to validate 4GL programs, because the trail is often covered [6]. Respondents were asked to rank the drawbacks attributed to 4GL’s according to their importance. g of ““1”was used t0 in& A significant drawback. The results were used to calculate the average rank scores for each; they are shown in T&ie 20. Fourth generation lanpage systems developed by MIS professionals were Wig fully documented and these tools were fully integrated into the existing life cycle methodology, which explains why these were not viewed as drawbacks. Much of the criticism about pooriy documented systems applies to the tuse of 4GL’s by end-users, not by MIS professionals. The lack af integration of 4GL’s and procedural languages may not have been a major conceA”nbecause 4GL tools were primarily being used to support query aml reporting subsystems. f&t of intzgration among 4GL products was probably not viewe as a concern because most MIS organizations had standardized on the use of one 4GL.
2.7 3.1
4.4 4.9 5.1 5.4 5.5
Although there are reports of project successes and failures in trade literature, very few articies identify the characteristics of systems suitable for 4GL development. In one article, Culhtm suggests that management must be willing to implement a project in small pieces and is use an iterative design approach to apply a 4GL successfully. oreover, success requires adequate machine resources, a thoroughly wledgeable developme umentation of the fi ete version.
90
Information & Management
Techniques
PO.summary
Table 21 Characteristics of “goad” 4GL projects Project characteristics
Number of responses
Ad hoc reporting and inquiry needed Prototyping needed Urgency of development required Low traixactions volumt?s High end-user interaction Independent, self-contained system
IG 7 7 7 5 5
Flexible,highly changeablesystem
5
When the respondents were asked if the use of &L’s in their projects was a success, 29 of 33 said ):zs, one said no, and the others did not have enough experience to ow. Respondents said that speed was the -majorr-n for project sup-. Eight of the 33 managers reportti that they were able to complete their projects in a shorter time frame with 4GL’s. A number of respondents gave the ability to prototype application requirements, to meet USA requirements, to support ad hoc reporting needs, and to change preliminary designs as re2sons for project success. The final question asked respondents to name three characteristics of an application developrnenk projcrt which would make it suitable for development using a 4GL. When these answers were summarized, the major characteristics were situations where ad hoc reporting and inquiry were needed, where prototyping was desirable, where there was urgency, and where tr2nsactions volumes were low. Fourth generation tools could effectively support the development of independent, self-contained systems and of highly changeable, dynamic systems. When users were highly involved in interacting with an informztion system and were willing to bL
The results of the study illustrate that project managers have mrde B clear distinction between the types of projects that ape appropriate for development using procedural 12nguages and for 4GL’s. Procedural projects cost more, required more effort, had higher transactions volumes, had more users, and were generally larger in scale. In contrast, 4GL projects had more variable outputs, less security requirements, less chance of audit, and less complexity. The “perfect” 4GL project was an inquuy and reporting system with kss structured outputs, dynamic scheduling re@rements, and low complezty; s’adalone applications with low transactions volumes were “ candidates. Although most of the respondents indicated to speed deve!op,7lent, their use that 4GL’s he1 did not alter the traditional systems development life cycle methodology. Full documentation and quality assurance procedures were beiig followed for both types of projects. User participation in systems development was primarily felt during the problem definition and feasibility study phases of the life cycle for both 4GL and procedural language projects.
The experiences suggest some issues relating to 4GL development, mainly dealing with project selection and system development methodology. ii. 1. Project
Selection
e serious deficiency of
experience of project managers may have been due to selection of projects with characteristics
hford dion & Marragement
11.2. Systems
M. Sumner, R. Benson / Impact of 4iX.k
eve jopment
Methodology
Although the MIS professionals realized that the use of 4GL’s made it possible to speed up systems development activities, the characteristics of the projects were quite different from those of procedural projects. The improvement in apphcation development time could have been attributed to the difference in the nature and scope of the other words, if a 4GL had been transactions volume production projects, the productivity have been so obtious. inl projects with high transaction volumes, it could not be determined if large traditional projects would @ave been impacted by the use of 4GL’s. The current systems development life cycle was tely altered for 4GL were being 0 *&e life cyc!e to up cert! phases, such as prototyping and code generation. Fourth generation tools might have a greater impact on application development if a systems deincorporating their use velopment S organizatioRs. were introd The effective use of 4GL’s requires a software development environment which combines new technology with training, procedures, and top management support. The environment must suprt experimentation through pilot projects. Tools, workstations, and technical support personne! must be readily available to support the environment. If a programmer has to move to a new to q*end hours obtaining access workstation to databases needed for 4GL projects, then_MIS management is not fully behind 4GL development. Although application development productivity can be improved with the use of 4GL’s, their use needs to be coupled with other productivity strategies, such as developer workstations, team approaches to testing, and subroutine sharing. Re-usable libraries can be utilized effectively only if programmers are already trained in structurexl
le projects are selected for organizat:ons may experi-
91
ence considerable success wit 4(3L’s. &den= indicates that pro+ct managers are deliberately selecting projects witZ~characteristics which make them suitable for 4GL development. However, greater productivit:r improvements may occur if MIS organizations use systems develo odologies which support 4GL use effective organizational strategies supporting their USe.
Abi. Mayam. “The Evolution of fnformatio~~ systems ~ehpment Approach: Some Fiehi Obser~atilons,” &Z~U &se. Spring 1984. pp. 19-24. Ahoway, Robert M. and QuiEard. Judith A., “User Manager’s Systems NW MIS Qtfmterb. .Jum 1983, pp. 27-41. Bernstein, Amy, “Shortcut to systems Design+” B&&%%.r C?xzzqt&er S_v5&?m.June 1985. Bum!%,RN. and &nn& A-R., "+kCkg t-heAppmpria:e App!.ication Development Methodology.” Data Base, Fall 1985. pp. :9-23. Canning, Richard G, ed. “Tools to Rejuvenate Your Old Systems,” EDP Analyzer, Vol. 22. No. 4, A@l 1984, pp. l-14. Christoff, Kurt A., L1Building a Fourth Qenerntton Eavirontnent,” Duration, VoL 31, No. 18, Sept. 1985. Cobb, Richard H., “In Praise of 4GL’s,” Datamatiwt . July 1985, pp. W-96. Cullum, Ronald, L., “Iterative Development” Datm;i~::, Feb. 1985, pp. 92-98. Cook, Rick, “Automated Tools are Backlog Breakers,” ComprrterDec-isi.n.~-April 1085, pp. 92-102. Grant, FJ., “The Downside fo 4GL’s.” Datamation, July 1985, pp. 99-104. Green Jesse, “Productivity in the Fourth Generation: Si Case Studies,” Journal of Management Information Systems, Vol. 1, No. 3, inter 1984-85, pp. 49-63. GremiJiion, Lee L. and Pybum, Phillip, “Brezking the Systems Development Bottieneck,” Haruard Business Reuiew, March-Apr. 1983, pp.. 130-137. Heffeman, Henry, “Trade-offs in FOCUS, COBOL Test.” Government Computing News, June 1985. Jenkins, A. Milton. “Surveying the Software Generzlor Market,” Datcsmatian, September 1985. KuIL David, -‘Anatomy of a 4GL Disaster,” Computer Decisions, Vol. 8, No. 4, Feb. 1986, pp. 58-65. Martin, James, f~urrf2 Generation Languages: Vulzm~ 1. Principles (fEnglewood Cliffs. NJ: Prentice-Hall, 1985). Mason, R.E.A. and Carey, T-T., “Prototyping Interactive information Systems,” Communications of the ACM. Vol. 26. No. 5, May 1983, pp. 347-354. McFarlan, F.W., -’Portfolio Approach is Inform&On Systems,” H~tvard Business Review, S+:.-Oct. 1981. PP. 142-150.
92
191 humann,
AD. and Jenkins, A. ., “Prototyping: The fo: SI Items Development,‘” MIS Quarter&, Vol. 6, No. 3, Sept. 1982, pp. 29-44. New Paradigm