COMPUTER-AIDED SOFTWARE DEVELOPMENT

Daniel Teichroew, Ernest Al len Hershey I I I , and Yuzo Yamamoto

ISDOS P r o j e c t , Univers i ty of Michigan, Ann Arbor, Michigan, USA.

Abstract

In recent y e a r s , as the hardware c o s t / c a p a b i l i t y r a t i o has continued t o decrease and as much o f the routine data process ing has been computerized, the emphasis in software development has s h i f t e d from jus t g e t t i n g systems operat ional t o the maintenance of e x i s t i n g systems, reduct ion of dupl i ca t ion by i n t e g r a t i o n , s e l e c t i v e addi t ion of new a p p l i c a t i o n s , systems that are more u s a b l e , maintainable , portable and r e l i a b l e and t o improving the product iv i ty of software deve lopers .

This paper examines a number of trends that are changing the methods by which software i s being produced and used. More and more of the research and development i s now being d irec ted towards producing systems that have the d e s i r a b l e propert ies mentioned above. Also , more computer-aided t o o l s are being developed and made a v a i l a b l e . The most important trend probably i s the introduct ion of software development support f a c i l i t i e s which provide an integrated s e t of t o o l s , based on a centra l computerized data base . At t h i s s t a g e , these systems perform primari ly c l e r i c a l work but gradual ly t h e i r f a c i l i t i e s are being expanded. A number of research and development e f f o r t s are concerned with moving c l o s e r t o the u l t imate o b j e c t i v e of producing executable software for a par t i cu lar computing environment d i r e c t l y from a s e t of funct iona l requirements.

A large part of the software developed today i s s t i l l custom b u i l t t o meet a s p e c i f i c s e t of requirements in a s p e c i f i c computing environment. Considerable e f f o r t i s being d irec ted towards reducing the amount of software that must be newly produced each time by making use of software that already e x i s t s .

Many of the concepts and techniques in which these developments are based are not new. Many t o o l s are a v a i l a b l e but are not widely used. The a v a i l a b i l i t y of technology does not n e c e s s a r i l y mean that i t w i l l be used. Some of the reasons for t h i s are examined as a b a s i s for the cons iderat ion of i s s u e s involved in p r a c t i c a l appl i ca t ion of new system development technology.

1. Software Environment

1.1 Computer Based Information Process ing Systems alia. Related Terminology

Large amounts of resources are being devoted t o development and maintenance of computer based information process ing systems, i . e . , systems that include hardware, software and other components. Much of the concern with the e f f i c i e n c y and e f f e c t i v e n e s s of these systems today i s focused on the software e . g . , "software i s the problem". This paper i s primarily concerned with software development, however i t i s des i rab le t o f i r s t place software in i t s proper context wi th in systems. Terminology i s not ye t standard in t h i s f i e l d , and i t i s therefore necessary t o s t a r t with a number of d e f i n i t i o n s . In general these are cons i s t en t with those used in the recent encyclopedias by Ralston and Meek (1976) and

Be izer , Holzman, and Kent (1975 ) .

1.1.1 C l a s s i f i c a t i o n of Systems. The terms such as systems, information sys tems, information process ing systems are used with widely d i f f e r e n t meanings. The meanings i n which they are used in t h i s paper are def ined i n t h i s s e c t i o n and i l l u s t r a t e d i n the example in Figure 1 . 1 . 1 .

Organization

An organizat ion i s a l e g a l e n t i t y , or s u b - u n i t of a l e g a l e n t i t y , that i s uniquely and s p e c i f i c a l l y i d e n t i f i a b l e . Usual ly an Information System i s a part of an organizat ion which has a bas i c func t ion other than information p r o c e s s i n g . In Figure 1.1 .1 the example of an organizat ion i s a Manufacturing Enterpr i se .

Organizational SHb-systemS

An organizat ion may have a number of sub-systems which are used t o accomplish, or contr ibute t o the accomplishment, of the b a s i c func t ion . One o f these subsystems i s an Information System. I n Figure 1 . 1 . 1 , the Manufacturing Enterprise has sub-systems such as Product ion, L o g i s t i c s , D i s t r i b u t i o n , Finance, e t c .

Information Systems

The Information System i s the sub-system of an organizat ion i n which information ( i n the form of data) i s r e c e i v e d , recorded, processed , s t o r e d , r e t r i eved and transmit ted . The Information System may c o n s i s t of an informal system and ( formal) Information Process ing Systems. The informal system c o n s i s t s of a l l the information p r o c e s s i n g i n which data i s not recorded.

Information Processing Systems The subsystems of the Information System i n which data are recorded and processed fo l lowing a formal procedure are c a l l e d Information Process ing Systems. Two kinds of Information P r o c e s s i n g Systems may be d i s t i n q u i s h e d : manual and computer-based. Manual systems are those i n which a l l operat ions are performed manually. Computer-based information process ing systems are those in which some operat ions (though not n e c e s s a r i l y a l l ) are performed by a computer. Since t h i s paper i s pr imari ly concerned wi th computer-based sys tems, the term Information Process ing System w i l l be used t o r e f e r t o Computer-based Information Process ing Systems. Each Information Process ing System c o n s i s t s o f some non-computerized procedures , a data b a s e , app l i ca t ion sof tware , and a computing system as ind icated i n Figure 1 . 1 . 1 .

1 .1 .2 C l a s s i f i c a t i o n of Software. Software may be subdivided i n t o components a t v a r i o u s l e v e l s : System, subsystem, module, and s t a t e m e n t .

Software System. A software system i s a c o l l e c t i o n of software components t h a t , i f used toge ther , accomplish a complete information process ing func t ion .

Software Subsystem. A software subsystem i s a part of software system t h a t , i f used t o g e t h e r ,

- 189 -

accompl ishes a s e p a r a t e l y d e f i n e d p a r t o f t h e whole s o f t w a r e s y s t e m ' s f u n c t i o n . I n v e r y complex s o f t w a r e systems i t may be u s e f u l t o d i s t i n g u i s h more t h a n one l e v e l o f s o f t w a r e subsystems.

S o f t w a r e Components. S o f t w a r e components a r e p a r t s o f s o f t w a r e system t h a t c o n s t i t u t e b a s i c i n d i v i d u a l u n i t s such as programs, r o u t i n e s , s u b r o u t i n e s , m o d u l e s , u n i t s o f d a t a d e s c r i p t i o n and e x e c u t a b l e m o d u l e s .

S o f t w a r e M o d u l e . The s m a l l e s t p a r t o f a s o f t w a r e system t h a t can be u t i l i z e d by a s o f t w a r e component a t t h e same or h i g h e r l e v e l t o accompl ish a d e f i n e d f u n c t i o n .

S t a t e m e n t . The s m a l l e s t s e l f - c o n t a i n e d component o f a S o f t w a r e System which can be expressed i n t h e source programming l a n g u a g e .

I n a p a r t i c u l a r s y s t e m , these d e f i n i t i o n s can be made more s p e c i f i c s i n c e t h e y depend on t h e o p e r a t i n g system under which t h e system i s t o be r u n and t h e programming language i n which i t i s w r i t t e n . S i n c e t h e d i s c u s s i o n i n t h i s paper i s independent o f o p e r a t i n g systems and programming l a n g u a g e s , t h e t e r m s sys tem, subsystem module , and s t a t e m e n t w i l l be used w i t h t h e g e n e r a l meaning g i v e n above .

S o f t w a r e may be c l a s s i f i e d by i t s o p e r a t i o n a l s t a t u s . An e x c e l l e n t taxonomy i s g i v e n by Brooks ( 1 9 7 5 ) F i g u r e 1 . 1 . 1 :

" I n t h e upper l e f t o f F i g . 1 . 1 . 2 i s a p rogram. I t i s complete i n i t s e l f , r e a d y t o be r u n by t h e au thor on t h e system on wh ich i t was d e v e l o p e d . . .

There a r e two ways a program can be c o n v e r t e d i n t o a more u s e f u l , b u t more c o s t l y , o b j e c t . These two ways a r e r e p r e s e n t e d by t h e boundar ies i n t h e d i a g r a m .

Moving down across t h e h o r i z o n t a l boundary , a program becomes a programming p r o d u c t . T h i s i s a program t h a t can be r u n , t e s t e d , r e p a i r e d , and ex tended by anybody. I t i s u s a b l e i n many o p e r a t i n g e n v i r o n m e n t s , f o r many s e t s o f d a t a . . .

P ro mot ion o f a program t o a programming p rod uc t r e q u i r e s i t s thorough d o c u m e n t a t i o n , so t h a t anyone may use i t , f i x i t , and e x t e n d i t . As a r u l e o f thumb, I e s t i m a t e t h a t a programming product c o s t s a t l e a s t t h r e e t i m e s as much as a debugged program w i t h t h e same f u n c t i o n .

Moving a c r o s s t h e v e r t i c a l boundary, a program becomes a component i n a programming system. T h i s i s a c o l l e c t i o n o f i n t e r a c t i n g programs, c o o r d i n a t e d i n f u n c t i o n and d i s c i p l i n e d i n f o r m a t , so t h a t t h e assemblage c o n s t i t u t e s an e n t i r e f a c i l i t y f o r l a r g e t a s k s . . .

A programming system component cos ts a t l e a s t t h r e e t i m e s as much as a s t a n d - a l o n e program o f t h e same f u n c t i o n . The cos t may be g r e a t e r i f t h e system has many components.

I n t h e l o w e r r i g h t - h a n d c o r n e r o f F i g . 1 . 1 . 2 s tands t h e programming systems

p r o d u c t . T h i s d i f f e r s f rom t h e s i m p l e program i n a l l o f t h e above ways. I t c o s t s n i n e t i m e s as much. But i t i s t h e t r u l y u s e f u l o b j e c t , t h e i n t e n d e d p roduc t o f most system programming e f f o r t s . "

S o f t w a r e i s f r e q u e n t l y c l a s s i f i e d as e i t h e r system s o f t w a r e or a p p l i c a t i o n s o f t w a r e . System S o f t w a r e 1

i s used d u r i n g t h e e x e c u t i o n o f o t h e r s o f t w a r e ; i t i n c l u d e s o p e r a t i n g systems, m o n i t o r s , e t c . I t i s n e c e s s a r y because t h e a p p l i c a t i o n s o f t w a r e cannot r u n on t h e raw hardware i t s e l f . A p p l i c a t i o n S o f t w a r e i n c l u d e s s o f t w a r e components t a i l o r e d t o t h e u s e r ' s needs , i n c l u d i n g a l l s o f t w a r e p roduc ts t h a t a r e not p a r t o f system s o f t w a r e as d e f i n e d above .

The a p p l i c a t i o n a r e a t h a t i s o f most concern i n t h i s paper i s t h a t o f s o f t w a r e deve lopment . A l l programs s u p p o r t i n g t h e development o f s o f t w a r e , such as a s s e m b l e r s , c o m p i l e r s , t r a n s l a t o r s , program g e n e r a t o r s , d e s i g n - a i d packages and t h e l i k e a r e i n c l u d e d i n t h i s c l a s s i f i c a t i o n .

I t w i l l be c o n v e n i e n t t o d i s t i n g u i s h between g e n e r a l i z e d s o f t w a r e and c u s t o m - t a i l o r e d s o f t w a r e . G e n e r a l i z e d S o f t w a r e i s s o f t w a r e produced t o meet t h e needs o f a number o f users f o r t h e same g e n e r a l a p p l i c a t i o n i n d i f f e r e n t o r g a n i z a t i o n s and d i f f e r e n t computing e n v i r o n m e n t s . C u s t o m - t a i l o r e d S o f t w a r e i s s o f t w a r e des igned t o meet s p e c i f i c r e q u i r e m e n t s i n a s p e c i f i c s i t u a t i o n and f o r a s p e c i f i c e n v i r o n m e n t .

1 .2 Env i ronment i n Which S o f t w a r e l a Deve loped and Used

S i n c e s o f t w a r e i s deve loped i n many d i f f e r e n t c i r c u m s t a n c e s and used i n many d i f f e r e n t s i t u a t i o n s , i t i s d e s i r a b l e t o c l a s s i f y t h e d i f f e r e n t cases and t o a t t e m p t t o i d e n t i f y some p a r a m e t e r s which c h a r a c t e r i z e them. Boehm ( 1 9 7 6 ) p. 1 2 3 9 , c o n s i d e r s t h e a p p l i c a t i o n o f s o f t w a r e e n g i n e e r i n g t o two a r e a s :

AREA 1 : D e t a i l e d d e s i g n and coding o f system s o f t w a r e by e x p e r t s i n a r e l a t i v e l y economics - independent c o n t e x t .

AREA 2 : Requi rements a n a l y s i s , d e s i g n , t e s t and ma in tenance o f a p p l i c a t i o n s s o f t w a r e by t e c h n i c i a n s i n an e c o n o m i c s - d r i v e n c o n t e x t .

The p a r a m e t e r s t h a t he c o n s i d e r s i n d i s t i n g u i s h i n g between Areas 1 and 2 a r e :

- w h e t h e r t h e r e q u i r e m e n t s a n a l y s i s i s done b e f o r e o r a f t e r t h e

d e s i g n and cod ing s t a r t - w h e t h e r t h e s o f t w a r e i s "system" o r " a p p l i c a t i o n " s o f t w a r e - w h e t h e r t h e development i s done by s o f t w a r e e x p e r t s o r by

t e c h n i c i a n programmers - whether (economic) e f f i c i e n c y i s r e l e v a n t o r n o t .

However , he does n o t c o n s i d e r o t h e r p a r a m e t e r s which a r e a l s o i m p o r t a n t . One o f t h e s e i s t h e

' S y s t e m s o f t w a r e i s u s u a l l y c o n s i d e r e d as b e i n g p r o v i d e d by t h e hardware m a n u f a c t u r e r though D o l o t t a , e t a l . ( 1 9 7 6 ) p r e d i c t s a s e p a r a t i o n between t h e u s e r ' s I n s t a l l a t i o n C o n t r o l Program ( I C P ) and t h e v e n s o r - s u p p l i e d System C o n t r o l Program ( S C P ) .

- 190 -

m o t i v a t i o n which causes t h e s o f t w a r e t o be produced . There appear t o be a t l e a s t t h e f o l l o w i n g reasons f o r o r g a n i z a t i o n s t o produce s o f t w a r e : f o r t h e i r own u s e , f o r o t h e r o r g a n i z a t i o n s under c o n t r a c t , f o r s a l e ( o r l e a s e ) t o o t h e r o r g a n i z a t i o n s , t o s e l l a s e r v i c e , t o s e l l h a r d w a r e , o r t o c a r r y out r e s e a r c h .

Another i m p o r t a n t parameter i s t h e way i n which an o r g a n i z a t i o n meets i t s r e q u i r e m e n t s : by buy ing a s e r v i c e , by h a v i n g a s o f t w a r e system developed by o t h e r s under c o n t r a c t , by p u r c h a s i n g or l e a s i n g a v a i l a b l e s o f t w a r e , o r by d e v e l o p i n g i t s own s o f t w a r e .

The combina t ion o f t h e s e and o t h e r pa ramete rs l e a d s t o t h e i d e n t i f i c a t i o n o f s i x major env i ronments i n which t h e s o f t w a r e problem i s i m p o r t a n t .

The Systems Depar tment i n . .afi. O r g a n i z a t i o n . The u n i t i n an o r g a n i z a t i o n t h a t runs t h e p r o d u c t i o n o p e r a t i o n which produces r e s u l t s f o r v a r i o u s users i n t h e o r g a n i z a t i o n i s f r e q u e n t l y c a l l e d t h e Systems Depar tment . I t s p r o d u c t i o n f a c i l i t i e s i n c l u d e computers , systems s o f t w a r e , a p p l i c a t i o n s s o f t w a r e , d a t a b a s e s , e t c . The depar tment m a i n t a i n s t h e e x i s t i n g a p p l i c a t i o n s o f t w a r e and a l s o develops new systems. Many new systems i n v o l v e i n t e g r a t i o n o f e x i s t i n g sys tems. The Systems Department may deve lop new systems, have systems b u i l t under c o n t r a c t o r a c q u i r e e x i s t i n g systems.

O r g a n i z a t i o n s which a c q u i r e s o f t w a r e systems £y_ c o n t r a c t . T h i s env i ronment i s s i m i l a r t o t h e p r e v i o u s one i n t h a t t h e s o f t w a r e must be m a i n t a i n e d . However s i n c e t h e o r g a n i z a t i o n d i d not deve lop t h e s o f t w a r e i t s e l f , i t must depend on t h e d e v e l o p e r f o r t h e documenta t ion t h a t i s necessary f o r use and m a i n t e n a n c e .

S o f t w a r e E n t e r p r i s e s . These a r e o r g a n i z a t i o n s t h a t produce s o f t w a r e f o r o t h e r s e i t h e r under c o n t r a c t o r f o r s a l e as s t a n d a r d p r o d u c t s .

Companies u s i n g s o f t w a r e £o_ o f f e r a. s e r v i c e . Such bus iness s e r v i c e s a r e becoming more common and a r e p r e d i c t e d t o i n c r e a s e , e . g . , Seidman ( 1 9 7 5 ) :

"The l i n e between computer s e r v i c e s vendors and computer equipment vendors i s b e g i n n i n g t o b l u r . By 1 9 8 0 , most u s e r s w i l l be buying s o l u t i o n s t o problems i n s t e a d o f buy ing hardware a n d / o r s e r v i c e s . I n o r d e r t o d e a l w i t h t h e r a p i d l y i n c r e a s i n g c o m p e t i t i o n a t bo th t h e h i g h and low revenue ends o f t h e s p e c t r u m , computer s e r v i c e s vendors w i l l e v o l v e i n t o M u l t i - S e r v i c e Vendors ( M S V ' s ) , s e l l i n g s o l u t i o n s t o u s e r s ' p rob lems. T h i s w i l l i n c l u d e , as r e q u i r e d , t h e p r o v i s i o n o f h a r d w a r e , s o f t w a r e , and f a c i l i t i e s management ( F M ) , i n a d d i t i o n t o t h e t r a d i t i o n a l remote computing and ba tch s e r v i c e s c u r r e n t l y o f f e r e d . To t h e dp u s e r , t h i s w i l l mean a g r e a t e r o p p o r t u n i t y t o g e t t h e most e f f i c i e n t and most economica l s o l u t i o n t o h i s problem w i t h a minimum o f comparison s t u d i e s and i n s t a l l a t i o n and i n t e g r a t i o n p r o b l e m s . "

Hardware M a n u f a c t u r e s . These produce system s o f t w a r e , p a r t i c u l a r l y o p e r a t i n g sys tems, and o t h e r s o f t w a r e t h a t i n t e r f a c e s d i r e c t l y w i t h hardware .

Academic, r e s e a r c h and development o r g a n i z a t i o n s •

These produce s o f t w a r e p r i m a r i l y t o demonst ra te f e a s i b i l i t y r a t h e r t h a n t o accompl ish a p p l i c a t i o n s i n a p r o d u c t i o n e n v i r o n m e n t . S t a t e - o f - a r t s o f t w a r e i s produced by e x p e r t s p r i m a r i l y f o r r e s e a r c h p u r p o s e s . I n t h i s s i t u a t i o n , t h e s o f t w a r e i s n o t i n t e n d e d t o be used f o r o p e r a t i o n a l u s e s , and c o s t and per formance may n o t be as i m p o r t a n t as d e m o n s t r a t i n g f e a s i b i l i t y .

The above env i ronments a r e ones i n wh ich a l a r g e amount o f s o f t w a r e must be produced and m a i n t a i n e d over a l o n g p e r i o d o f t i m e . D u r i n g t h i s t i m e t h e r e q u i r e m e n t s and comput ing env i ronments may change. I n such an env i ronment any g i v e n s o f t w a r e system i s d i f f i c u l t t o m a i n t a i n . F u r t h e r , s i n c e t h e s o f t w a r e i s a lways b e i n g changed, i t may e x i s t i n many v e r s i o n s , each w i t h many r e l e a s e s .

1 .3 System Deve lopment . S o f t w a r e Development sua S o f t w a r e E n g i n e e r i n g

1 . 3 . 1 E v o l u t i o n o f System Development Methods. S o f t w a r e development i s o n l y one a s p e c t o f I n f o r m a t i o n P r o c e s s i n g Systems. I t i s , t h e r e f o r e , d e s i r a b l e t o examine t h e e v o l u t i o n o f system development because improvements i n s o f t w a r e development must be c o m p a t i b l e w i t h t h e changes i n t h e t o t a l e n v i r o n m e n t .

I n i t i a l l y systems were deve loped by ad hoc methods. Such an approach i s p r a c t i c a l o n l y f o r v e r y s m a l l systems where o n l y few p e o p l e a r e i n v o l v e d . S i n c e i t i s u s u a l l y not f e a s i b l e t o d i v i d e systems i n t o s e p a r a t e , d i s t i n c t s m a l l systems, t h i s approach i s n o t r e l e v a n t t o t h e env i ronments d e s c r i b e d i n s e c t i o n 1 . 2 .

The t r a d i t i o n a l o r c l a s s i c a l approach t o system development i s t h e System L i f e Cyc le method based on a sequence o f phases c o n t r o l l e d by a p r o j e c t management sys tem. The a p p r o a c h , c o v e r e d i n many books and p u b l i c a t i o n s , ( e . g . , Hartman ( 1 9 6 8 ) , H i c e , e t a l . ( 1 9 7 4 ) , M e t z g e r ( 1 9 7 3 ) ) , c o n s i s t s o f : ( 1 ) s p e c i f y i n g a number o f a c t i v i t i e s t h a t must be c a r r i e d o u t , ( 2 ) i d e n t i f y i n g a number o f phases w i t h t h e r e s u l t s t o be o b t a i n e d i n e a c h , and ( 3 ) d e s c r i b i n g t h e r e s u l t s , i . e . , d o c u m e n t a t i o n , which must be produced a t t h e end o f each phase . F i g u r e 1 . 3 - 1 » t a k e n f rom t h e f r o n t cover o f M e t z g e r , i l l u s t r a t e s these a s p e c t s t h a t c h a r a c t e r i z e a l l such methods. F r e q u e n t l y , t h e procedures a r e d e s i g n e d f o r a p a r t i c u l a r t y p e o f system. For example , t h e O . S . Depar tment o f t h e Navy ( 1 9 7 4 ) has a documenta t ion s t a n d a r d f o r t a c t i c a l d i g i t a l sys tems .

Even though i n f o r m a t i o n systems a r e a t y p e o f system, few a p p l i c a t i o n s o f systems t h e o r y have appeared i n t h e l i t e r a t u r e . One i n t e r e s t i n g example i s t h e a t t e m p t t o a p p l y c o n t r o l t h e o r y t o i n f o r m a t i o n systems by Lehman ( 1 9 6 9 ) , B e l a d y and Lehman ( 1 9 7 1 ) , and B e l a d y and Lehman ( 1 9 7 6 ) . T h e i r models o f t h e l i f e c y c l e o f systems i n c l u d e t h e concepts o f r e l e a s e s and v e r s i o n s . Another example i s g i v e n by Putman ( 1 9 7 7 ) who a n a l y z e s a Systems Depar tment w i t h many systems i n d i f f e r e n t s tages o f t h e i r l i f e c y c l e .

1 - 3 - 2 S o f t w a r e peye lopment . The System L i f e C y c l e method u s u a l l y i n c l u d e s t h e f o l l o w i n g a c t i v i t i e s i n s o f t w a r e deve lopment :

D e t e r m i n a t i o n o f t h e r e q u i r e m e n t s t h a t t h e s o f t w a r e i s t o accompl ish D e s i g n o f t h e s o f t w a r e i n c l u d i n g s p e c i f i c a t i o n o f t h e major modules D e s i g n o f t h e i n d i v i d u a l modules

191 -

Programming the individual .modules Assembling or compiling the programs Debugging and t e s t i n g indiv idual programs I n t e g r a t i n g and t e s t i n g the programs as a system

The exact procedure that has t o be fol lowed in a par t i cu lar computing environment depends on the methods used for des ign , the conventions and standards that have been adopted, the programming language, and the operating system.

1 . 3 . 3 Software Engineering and Software Production. While the System Li fe Cycle method i s in widespread u s e , the model on which i t i s based i s too simple for many prac t i ca l s i t u a t i o n s today. One improvement which has been proposed i s frequently re ferred t o as Software Engineering. The term has been defined by Boehm (1976) as f o l l ows :

" SOFTWARE ENGINEER™ ; The p r a c t i c a l a p p l i c a t i o n of s c i e n t i f i c knowledge in the des ign and construct ion of computer programs and the assoc ia ted documentation required t o develop, operate and maintain them."

The Software Engineering concept impl ies a change from preoccupation with programming to a broader view encompassing software ( i . e . , a c o l l e c t i o n of i n t e r r e l a t e d programs), recogni t ion of the need for t r a d e o f f s among a number of c r i t e r i a and cons iderat ion of the a p p l i c a b i l i t y of engineering p r a c t i c e s . However, the term s t i l l i s too narrow for a comprehensive view of systems s ince software i s only one part of systems; systems a l s o include non-computerized procedures and hardware. The non-software or manual procedures include many aspects of user i n t e r f a c e s that determine the value of the system t o the organization which i s paying for i t .

In t h i s paper, the term "Software Engineering" w i l l be used t o descr ibe the i n i t i a l design and development of prototype software. The term "Software Production" w i l l be used to descr ibe a l l the a c t i v i t i e s necessary t o produce software that i s s a t i s f a c t o r y for operat ional use .

1 . 3 .4 Personnel C l a s s i f i c a t i o n . An important cons iderat ion in improvement in software development i s the personnel assoc ia ted with systems and t h e i r re spec t ive r o l e s . Four major groups of personnel involved with can be d i s t i n g u i s h e d : the software personnel , the information process ing personnel , the personnel using the targe t system and the organ iza t ion ' s management. The software personnel are d i r e c t l y involved with the software and are concerned with i t s development, operation and maintenance. These are Software System Designers , Programmers, the software-hardware Operators and Program Librar ians . The second group - the Information process ing personnel are concerned with the development, operat ion and maintenance of the e n t i r e o r g a n i z a t i o n ' s information process ing system. These c o n s i s t of Systems Managers, Project Leaders, System Analysts , System A r c h i t e c t s , Data Base Des igners , Data Base Administrators , System Operators, Hardware Engineers , Communication Engineers, Project and System Librar ians . The th ird group, the targe t sys tem's u s e r s . c o n s i s t of organizat ion ' s personnel and i t s customers or customers' personnel . This group i s involved with preparing input data, observing the software format and

using the output data to perform i t s t a s k s . The fourth group, the organ iza t ion ' s management. c o n s i s t s of persons bearing the o v e r a l l r e s p o n s i b i l i t y for the organ iza t ion ' s image and the o rg a n i za t i o n ' s economic e f f e c t i v e n e s s . Among t h i s group are the managers respons ib le for the Systems Department in the organizat ion .

1.4 Software Costs and Other C h a r a c t e r i s t i c s

While i t i s c l e a r l y des irab le t o "improve" software, in the software f i e l d there i s as ye t no s a t i s f a c t o r y way to measure progress in q u a l i t y or p r o d u c t i v i t y . Currently, the most common measure i s l i n e s of code. Even the bas ic d e f i n i t i o n of "code" i s subject to i n t e r p r e t a t i o n , e . g . , does i t inc lude comment l i n e s ? Furthermore, the use of t h i s measure as a product iv i ty measure l e a d s t o undesirable r e s u l t s . I f a programmer knows that he w i l l be judged by the number of l i n e s of code he w i l l be motivated to avoid the use of macros and l i b r a r i e s , t o use low l e v e l programming rather than higher l e v e l s tatements , and avoid g e n e r a l i z i n g code in to reusable u n i t s because t h i s reduces the number of l i n e s of code and a l s o tends t o make the r e s u l t i n g code more d i f f i c u l t t o produce. The lack of s a t i s f a c t o r y q u a n t i t a t i v e and s c i e n t i f i c methods and adequate measures i s emphasized in most of the surveys of the s t a t e of the art of information systems. See , for example, Dolot ta e t a l . (1976) .

There are a l s o no genera l ly accepted c h a r a c t e r i s t i c s in which improvements can be measured. Terms such as r e l i a b i l i t y , q u a l i t y , m a i n t a i n a b i l i t y , e t c . are used without d e f i n i t i o n or with d i f f e r e n t d e f i n i t i o n s by d i f f e r e n t authors . Recently , severa l e f f o r t s have been made t o def ine software c h a r a c t e r i s t i c s and develop a method for measuring the values of the c h a r a c t e r i s t i c s for a par t i cu lar un i t of so f tware . See , for example, Boehm (1973) , Gl ib (1976) and Reifer (1976) . The c h a r a c t e r i s t i c s t r e e developed by Boehm i s shown in Figure 1 . 4 . 1 . Here c h a r a c t e r i s t i c s w i l l be divided i n t o two c a t e g o r i e s : c o s t and other . The "other" c h a r a c t e r i s t i c s w i l l be c l a s s i f i e d as in Teichroew (1974) .

1.4.1 Software Cost. Three methods for reducing the cos t of software t o the f i n a l user may be considered:

Reducing the cos t t o develop software t o meet given requirements. This in turn can be accomplished by improving the product iv i ty of software deve lopers or by having more of the software developed by machines a t lower c o s t .

Reducing the amount of new software which must be developed to meet a g iven requirement.

Producing software which w i l l be used by a number of u s e r s . The c o s t to each should decrease proport ionate ly t o the number of u s e r s . In prac t i ce the decrease w i l l not be proportionate s ince some of the c o s t such as maintenance increases as the number of users i n c r e a s e s . Furthermore, ob ta in ing a number of users t o use the same software i n e v i t a b l y requires a marketing e f f o r t .

One of the d i f f i c u l t i e s in improving sof tware i s dec iding what should be included in the c o s t of sof tware . I t i s now being recognized that the

- 192 -

cos t of a system i s much more than the cos t of development. For example, there are c o s t s involved in t r a i n i n g and documentation. I t i s a l s o being recognized t h a t development c o s t s may be small r e l a t i v e t o maintenance c o s t s during the l i f e of the system. Dec i s ions on systems are frequently based on c o s t of software on ly , and dec i s i ons on software are frequently based on development c o s t s on ly .

1 .4 .2 Software C h a r a c t e r i s t i c s . I d e a l l y software should have three major types of c h a r a c t e r i s t i c s : accomplishing a given s e t of requirements, be e f f i c i e n t in i t s use of resources , be e a s i l y changeable as the s i t u a t i o n changes.

Achievement of these g o a l s usua l ly involves a tradeoff s ince improvement in one may r e s u l t in degredation in o t h e r s . Systems are b u i l t t o serve organizat ions . Consequently the systems must accomplish the requirements that are s ta ted by the organizat ion. A f i r s t o b j e c t i v e , there fore , i s t o build systems that accomplish those requirements. Requirements are seldom abso lute ; the organizat ion and i t s environment change and therefore the requirements may change. Also , requirements are not independent of c o s t . There i s usua l ly a point beyond which i t i s not worthwhile t o achieve the requirement. There i s a l s o a tradeoff in the other d i r e c t i o n , i . e . , as the cos t of a system decreases the organizat ion becomes more w i l l i n g to adapt i t s e l f t o the system rather than i n s i s t i n g on requirements which may c o s t more.

Many of the techniques considered in t h i s paper have a p o t e n t i a l of reducing the need for the tradeoff by making i t e a s i e r t o change software t o f i t a par t i cu lar s i t u a t i o n .

1.5 Improvement £ £ Software Development

The attempts t o improve software development a r i s e out of the recogn i t ion of the need for changes and the recogni t ion that improvement i s p o s s i b l e .

1.5.1 The Need for Improvement. A number of s tud ie s of the s t a t e of software development have shown that the quanti ty and qual i ty of software being produced i s already a l i m i t a t i o n on the e f f e c t i v e u t i l i z a t i o n of computers and that t h i s problem w i l l become even more ser ious in the future . Two s t u d i e s were conducted for the U.S. Air Force (CCIP-85 and SADPR-85); the f i r s t has been summarized by Boehm (1973) . An ex tens ive study has been conducted by the SILT committee of SHARE, Dolotta e t a l . (1976) . IBM has conducted a survey on a p p l i c a t i o n development problems (Perry 1975). A general overview of the e f f e c t i v e n e s s and e f f i c i e n c y of System Departments i s g iven by Canning (1975) . While these s t u d i e s contain some q u a n t i t a t i v e data, comprehensive data i s hard to obta in . (An e x c e l l e n t summary of ava i lab le data i s g iven by Phi s ter (1976) . ) Development problems sometimes have to be reported as hypothet ica l s i t u a t i o n s as in the MUDD report (Weiss 1975). One s i t u a t i o n where quant i ta t ive data sometimes appears i s in s i t u a t i o n s which have t o be resolved by l e g a l methods. (Wiseman 1976) .

There seems to be no quest ion that improvement in q u a l i t a t i v e c h a r a c t e r i s t i c s i s e s s e n t i a l . Furthermore the amount of software needed in the future cannot be produced by present manual methods (Prywes 1975 and Dolotta 1976).

1 .5 .2 P o s s i b i l i t i e s for Improvement.

I n d u s t r i e s which s t a r t with a new product or s e r v i c e go through a l i f e c y c l e . In the i n i t i a l growth phase, the industry i s rapidly expanding i t s markets, frequent ly by expanding the c a p a b i l i t y of i t s produce or s e r v i c e . The industry reaches maturity when i t s product can no longer f ind new markets; i t i s then l i m i t e d to the replacement market. I f that market shrinks enough, p o s s i b l y due t o newer products , the industry becomes e x t i n c t .

The computer industry has been evolv ing and c l e a r l y i s s t i l l in a growth phase. The r a t e of evo lu t ion of computers has been very rapid. Evolution of computers i s commonly divided i n t o "generat ions", each of which centers around a major jump in c a p a b i l i t y and/or decrease in c o s t . The generat ion concept has been appl ied to hardware, (Withington 1974), operating systems, (Denning 1971) , EDP management, (Gibson and Nolan 1974) , systems development (Benjamin 1972), and systems a n a l y s i s t echniques , (Couger 1973, 1974) . The evo lu t ion i s s t i l l cont inuing, p a r t i c u l a r l y in hardware. The c o s t of hardware t o perform a g iven computation has been decreasing and the r e l a t i v e c o s t of hardware t o software, i n a g iven system, has a l s o been decreas ing .

Since hardware c o s t s have been decreased i t i s worthwhile t o examine the reasons and t o see whether the same approach could be applied t o software t o reduce the cos t of software and a t the same time improve i t s q u a l i t y .

Hardware c o s t s have decreased for three major reasons:

Research in the underlying phenomena. This r e s u l t e d i n discovery of ways of performing bas ic operat ions a t much higher speed with much greater r e l i a b i l i t y .

D i f f e r e n t i a t i o n of funct ions involved in the hardware system l i f e c y c l e , and development and use of appropriate mechanized t o o l s for each of the f u n c t i o n s . The separate funct ions that e x i s t in most hardware manufactures are: eng ineer ing , prototype development, manufacturing, marketing,and maintenance.

Mass production of components and sub-assembl ie s . This has permitted investment i n production f a c i l i t i e s t o reduce the per -un i t c o s t .

The analogy with software production i s not per fec t and some of the r e l a t i v e c o s t s are d i f f e r e n t . For example, the cos t t o produce another copy of a program i s i n s i g n i f i c a n t whereas the cos t t o produce, for example, another d i s c drive i s no t . Neverthe less i f one inc ludes a l l re levant c o s t s a s s o c i a t e d with information process ing system the analogy becomes much c l o s e r .

This paper i s concerned with the a p p l i c a t i o n o f the concepts in the l a s t two po ints above ( d i f f e r e n t i a t i o n of funct ion , and mass production) t o software development. In p a r t i c u l a r S e c t i o n 2 , 3 and 4 descr ibe the t o o l s that might be used in each of the funct ions in the software system l i f e c y c l e . Sec t ion 5 covers the software analogue of mass production; namely the use of e x i s t i n g software components. Sec t ion 6 d i s c u s s e s the t e c h n i c a l , operat iona l and economic f e a s i b i l i t y of changing the development of software. Any approach to improving product iv i ty should take

- 193 -

into account the evolution occurring in the computer field. On one hand, the type of software that is to be developed and the manner by which software productivity is measured will be affected by evolution in hardware. On the other hand, the investment in software at one stage in the cycle may limit the opportunity to make use of new hardware capabilities at another stage.

One factor affecting productivity is the type of systems being built. Systems are becoming large and more complex. Consequently, software development emphasis is on the sharing of facilities. However, the increase in the availability of mini-computers has led to distributed processing which may both make systems smaller and simpler and resource sharing less important. One example of the possible changes in software development is indicated by Rigo (1977):

"We have all heard about Citibank's massive conversion to minicomputers. We are now beginning to hear the rest of the story and it involves a lot more than hardware. In somewhat oversimplified form the current situation was recently described like this: * Citibank, one of the world's largest corporations, is junking all its big IBM mainframes. * It is replacing its big machines with minis - dozens of them, of every make and model. * It has drastically reduced its permanent systems and programming staff. For new development, it rents consultants for as long or short a time as needed. * It used to take two to five years to design and implement a new system. Now the bank is getting the job done in as little as six weeks."

1.6 S u m m a r y and Conclusions

In the development of software that is to be used operationally in computer based information processing systems (see definition in section 1.1), the emphasis must be on "programming system product" as specified by Brooks (1975), Figure 1.1.2.

latter.

Currently much of the software intended for operational use is produced under the system life cycle approach as described in Section 1.3. This approach has been characterized by the following:

- most software is developed manually with little use of tools other than compilers, editors, linkers and loaders, and operating systems.

- most software has been designed to satisfy a particular requirement in a particular computer environment.

To improve software development it is necessary to be able to identify the characteristics in which improvement is desired and to be able to measure improvement. These characteristics are examined in section 1.4. The most important are:

- to reduce the cost of software to a particular user

- to improve the degree to which the functional capabilities meet the users needs

- to increase the liklihood that the software functions correctly and efficiently.

A basic premise is that software development and maintenance will change in the following major ways:

- software development in the future will be aided by coordinated set of tools (manual as well as computer aided).

- more of the software development will be done by computers.

- the amount of new software, that would otherwise have to be produced, will be reduced by synthesizing systems out of existing software modules.

The primary use of programming system products is in System Departments as defined in Section 1.2. The environment in which these techniques are most relevant is one in which a large amount of software must be produced and maintained over a long period of time during which the requirements and computing environment may change. Any given software system in such an environment is large with hundreds of modules and tens of thousands of lines of source statement. The software must be developed and maintained by staff whose membership is also changing. The software may exist in many versions each with many releases. Techniques that are useful in this environment are not appropriate for situations in which state-of-art software is produced by software experts primarily for demonstration purposes. In these situations software is not intended to be used for operational uses and does not have to be maintained and cost and performance may not be as important as demonstrating feasibility.

Software may be developed by the using organization, by software companies under contract, by software companies for sale or lease or by research institutes. The techniques to be discussed are appropriate to all except the

Interest in improvement originates with the desire to utilize more fully the potential capability of computer and is pursued because there are indications that improvement is possible, as indicated in section 1.5.

The basic motivation for the approach to software development outlined in this paper is that a substantial reduction can be obtained in the cost of a software system to an individual user while at the same time making it more reliable and more adaptable to changes in the computing environment. However, these new approaches will not be adopted automatically. Some of the reasons why progress has not been faster are examined in section 6 .

These considerations lead to the following conclusions:

- The productivity of software developers should be improved by making use of the computer for data processing activities.

- The productivity of software developer can be further improved by automating as much of the software development and

194 -

maintenance as possible.

- The productivity can also be further improved by reducing the amount of new software to be developed.

A survey of the state of the art of techniques to accomplish these approaches to improvement of productivity is given to provide the specification for a Software Support System. The current status of development along these lines is summarized in the following sections. The tools available for information processing system development are surveyed and several state of the art approaches to integrating the tools are examined in section 2. The specification for a software system capable of supporting information processing systems during their entire life cycle (development, operation and maintenance) is outlined in section 3. Section 4 describes approaches to using the computer to develop software. Section 5 is concerned with reducing the amount of new software that must be developed.

2. Tools for Software Development, Operation and Maintenance

The tools for system development, operation and maintenance may be divided into manual tools and computer-aided tools. The manual tools are discussed in section 2.1. Computer-aided tools are classified and some of the factors that limit their use are discussed in section 2.2. The next four subsections describe briefly some attempts to overcome these limitations: the National Software Works in section 2.3, the System Development Laboratories in Section 2.4, the Application Management System in section 2.5 and the Information Automat in section 2.6. Some conclusions on the use of tools are given in Section 2.7.

2.1 Manual Tools

The term "manual tools" is intended to cover all the skills, knowledge, disciplines and procedures that are used in system development, operation, and maintenance. To a large extent these tools have been developed out of necessity in order to use the computing hardware and software as they have evolved. The tools therefore, are ad hoc and in many cases have to be learned by experience since they have not been adequately documented.

In the last few years considerable attention has been directed to the Improved Programming Techniques developed by IBM. These include Chief Programmer Team organization, Structured Walk Through, Program Librarian, Top Down Development and Structured Programming. These techniques achieved considerable attention as a result of the spectacular results reported by Eaker (1972) when they were used in a project for the New York Times. Consequently many organizations have adopted these methods and consider them worthwhile.

However, it should be noted that these methods by themselves do not necessarily lead to software that has all the desirable qualities. This is indicated by the experience of the New York Times with the system produced by IBM, as reported by Plauger (1975):

Number of errors. "The developers claimed, in fact, a record of one bug for every 10,000 lines of delivered code:

"That's all they found because they didn't do that much testing. We figure that if there's only one bug per 10,000 lines of code, then IBM owes us about a million additional lines."

Hard to maintain. "Why was it hard to maintain? Among other things it was poorly parameterized. When the staff attempted to introduce a new type of display terminal, they were horrified to discover that all sorts of modules 'knew' how many lines there were to a page, for instance, and how many characters per line. It was a major effort to make the code more general."

"The major drawback is that three or four experts are still required to maintain the code. M s . Szuch estimates that it takes a newcomer about six months to get on board and safely make changes."

Efficiency. "It was slow, for one thing, too slow to be marketable. And when the maintenance programmers looked inside to see how to tune it up, they weren't terribly happy about what they found. The upshot was that the system limped along for about nine months with only one 'friendly user' (i.e., non-paying), while The New York Times programmers puzzled out the code and hammered it into decent shape. The Data Bank is alive and working today, but it has yet to fulfill its original promise."

Quality of code. "As for the quality of the code, the Times programmers found it to be highly variable. They soon learned to spot the individual writing styles of different member of the development team. 'You could hardly call it "egoless" code'."

Design decisions. "But she is critical of some of the design decisions made which, she says, 'meet the letter of the stated requirements but not the spirit.' She suggests that computer professionals have a duty to inform users of specifications that will be regretted later."

This particular example, of course, does not mean that these Improved Programming Productivity techniques should not be used. In fact, practical experience with these techniques in many organizations suggests that they should be adopted, but the desired benefits will not be obtained unless the means to achieve them are explicitly included.

One of the reasons for the lack of adequate manual tools is that there has as yet been relatively little progress in the investigation of the underlying phenonema of information systems; there is, in fact, little agreement as to what classes of phenonema are really basic. Wegner ( 1 9 7 6 ) , for example, considers

"the ramifications of four influential definitions of computer science:

1. Computer science is the study of phenonema related to computers, Newell, Perlis and Simon, (1967).

2. Computer science is the study of

- 195 -

algori thms, Knuth, (1968) .

3. Computer sc i ence i s the study of information s t r u c t u r e s , Wegner, (1968) .

4 . Computer sc i ence i s the study and management of complexity, D i j k s t r a , (1965) ."

He concludes that

"these d e f i n i t i o n s r e f l e c t four d i f f e r e n t approaches to the study of computer s c i ence and has given r i s e to four very d i f f e r e n t paradigms for computer sc i ence research . Computer s c i ence i s perhaps unique in the d i v e r s i t y of i t s admiss ible research paradigms, and t h i s d i v e r s i t y i s perhaps respons ib le both for our d i f f i c u l t i e s in deciding how computer s c i e n t i s t s should be trained and for d i f f erences of opinion concerning the nature of computer sc i ence research ."

2 . 2 Computer-aided Tools

Many computer-aided t o o l s for system development, operation and maintenance have been produced. In p a r t i c u l a r , there are the compilers , l i n k e r s , l oaders , operating systems, u t i l i t i e s such as s o r t , which e x i s t in every computing i n s t a l l a t i o n of any s i z e . There are a l s o many other t o o l s intended to aid the development of a p p l i c a t i o n software.

Each computing f a c i l i t y contains u s u a l l y only one operating system and only one, or very few, compilers . The use of these t o o l s i s e s s e n t i a l for use of the f a c i l i t y and therefore contro l l ed and enforced. Since the e n t i r e operat ion of the computer f a c i l i t y and p o r t f o l i o of app l i ca t ion software depends on these t o o l s , there i s a great re luctance to change the bas ic system software or even t o al low any way to do i t . Unfortunately , e i t h e r the use of appl i ca t ion software development t o o l s frequently i s incompatible with the e x i s t i n g system software, or the b e n e f i t s come from overcoming the d e f i c i e n c i e s of the system software, and there fore , a bas ic c o n f l i c t a r i s e s . The problem becomes one of obtaining the b e n e f i t s from the app l i ca t ion software while a t the same time maintaining s t a b i l i t y in the system software . (The v i r t u a l machine concept i s one approach t o overcoming t h i s dilemma.) D i r e c t o r i e s of t o o l s t o a id in the des ign , development, operat ion , modif icat ion and maintenance of information process ing systems, have been publ ished, e . g . , by ICP and Datapro. More d e t a i l e d d e s c r i p t i o n s have a l s o appeared. For example, Nafta ly , e t a l . (1972) have described a number of t o o l s ava i lab le to aid development of systems in COBOL; Reifer (1975b) has provided a l i s t of t o o l s ava i lab le in the U.S. Air Force. Several authors have attempted to c l a s s i f y a v a i l a b l e t o o l s : Reifer (1975a) and Curry (1976) . Reifer has developed d e f i n i t i o n s for the 80 types of t o o l s ; the types are l i s t e d in Appendix 1.

A l l evidence c l e a r l y ind ica te s that d e s p i t e the ex i s t ence of many computer-aided t o o l s , very few are being used and most of these are not used very e x t e n s i v e l y . This conclusion was the opinion of many at Sess ion L351 of the recent SHARE XLVII meeting which was devoted to a "Survey of F a c i l i t i e s for Application Development." The se s s ion report contains the fo l lowing eva luat ion:

"There are hundreds of t o o l s a v a i l a b l e t o

aid the app l i ca t ion development process . Some i n s t a l l a t i o n s have over a hundred separate products i n s t a l l e d but f ind that most are used by only a handful of people and many are used only once or t w i c e . I t appears that there are some problems as soc ia ted with the use of the t o o l s present ly a v a i l a b l e : 1) poor human f a c t o r s , 2) lack of education and p u b l i c i t y , 3) i n c o m p a t i b i l i t i e s with i n s t a l l a t i o n standards and other t o o l s , 4) not a part of an in tegrated system, 5) s p e c i a l i z e d nature of some t o o l s ( i . e . , only good at serving one par t i cu lar non-recurring problem) and 6) u n s a t i s f a c t o r y performance ( i . e . , does not improve product iv i ty of the app l i ca t ion development p r o c e s s ) . In a d d i t i o n , most users are not aware of the range of t o o l s a v a i l a b l e , t h e i r b e n e f i t s , and other users experience with them."

The major reasons for the l i m i t e d usage of t o o l s are:

- Knowledge of e x i s t e n c e . Despi te the attempt to provide d i r e c t o r i e s of e x i s t i n g t o o l s , i t i s frequently d i f f i c u l t t o determine where a t o o l with the required c h a r a c t e r i s t i c s for a g iven task e x i s t s .

- Access and a v a i l a b i l i t y . A t o o l may not be a v a i l a b l e t o a person, even i f he knows of i t s e x i s t e n c e , understands i t and wishes t o use i t , because he does not have acces s to the computer system on which i t i s i n s t a l l e d .

- New languages. In order to use a t o o l , i t i s usua l ly necessary for a person to learn two languages. F i r s t i s the language used by the too l i t s e l f and second i s the operating system or command language. The f i r s t i s almost always a new language while the second may or may not be .

- I n t e r f a c e s . Most t o o l s have t h e i r own input and output formats and consequent ly , each user must reformat h i s data to be acceptable to the t o o l and then reformat the output i f he needs i t for another t o o l .

- S t a t u s . Many t o o l s , in the terminology used by Brooks (1975) , are "Programs" rather than "Programming Systems Products". They have inadequate user documentation and are inadequately t e s t e d . After a c e r t a i n amount of t ry ing t o use a too l without s u c c e s s , the user may we l l g ive up and decide the e f f o r t t o ge t the too l working i s not worth i t .

The p o t e n t i a l bene f i t of us ing t o o l s in systems development has lead t o a number of attempts to overcome these d i f f i c u l t i e s . These approaches are characterized here by the degree t o which they make use of what already e x i s t s . The f i r s t approach s t a r t s with the premise that i t must be p o s s i b l e t o incorporate e x i s t i n g t o o l s e s s e n t i a l l y unchanged. An example i s the National Software Works (Sec t ion 2 . 3 ) . The second approach a l s o makes as much use of e x i s t i n g t o o l s as p o s s i b l e but attempts t o i n t e g r a t e them by providing common i n t e r f a c e s . Examples are the Software Development Laboratories described in Sec t ion 2 . 4 . A somewhat s imi lar approach i s incorporated in the Applicat ion Management System described in Sect ion 2 . 5 . The th ird approach i s based on the premise that the bas ic c o m p a t i b i l i t y problems can only be solved by a completely new s t a r t . A proposal in t h i s d i r e c t i o n i s the Information Automat (Sec t ion

- 196 -

2 . 6 ) .

2 . 3 na t iona l Software Works

The National Software Works (Figure 2 . 3 . 1 ) i s an extens ion of the ARPANET Projec t , (Braden 1976) . The i n i t i a l o b j e c t i v e of the ARPANET was t o provide communication among a number of computer centers so that any person having access t o one center could use any of the other computing environments. This helped to s impl i fy the acces s problem but i t did not reduce the other d i f f i c u l t i e s mentioned above. The user must s t i l l know the e x i s t e n c e of a too l and the operating system command language of the environment on which i t i s l oca ted before he can s t a r t t o use i t . The National Software Works s t a r t s with a premise that the e x i s t i n g t o o l s w i l l remain unchanged and that a "super s t ruc ture" , i . e . , a network operating system known as the Works Manager w i l l be placed on top of the present network. This Works Manager w i l l a l l o c a t e resources , contro l a c c e s s , handle accounting, and maintain a c e n t r a l index of a v a i l a b l e t o o l s . In add i t ion , each computing environment w i l l contain a front end which i s a Command Language Interface to the Works Manager. Each host computing environment which conta ins t o o l s w i l l have an addi t iona l software component known as the Foreman that w i l l act as the i n t e r f a c e in us ing the l o c a l t o o l s . In add i t ion , each ( t o o l bui ld ing) host w i l l contain a f i l e package t o provide f i l e compat ib i l i t y .

This system i s current ly in development and when completed w i l l make i t e a s i e r for users of the ARPANET t o use t o o l s at other hosts and w i l l somewhat s impl i fy the in ter face problems among t o o l s by the f i l e package. However, i t does not help t o a l l e v i a t e the problem of each t o o l having i t s own language. In e f f e c t , i t adds another language and command system which a user must learn though t h i s one w i l l hopeful ly serve him at many hos t s so that he can use l o c a l t o o l s without having to know the l o c a l operating system language.

The ARPANET i s a research v e h i c l e , most of the hosts are research computing centers and most of the users are researchers who are i n t e r e s t e d in t o o l development. They are , there fore , l e s s l i k e l y to produce Programming System Product Packages and a l s o are more l i k e l y to t o l e r a t e the l i m i t a t i o n s of other peop le ' s programs when they try to use them. To what extent t h i s experience w i l l be t r a n s l a t a b l e in to a production software environment i s not c l e a r .

2 .4 Software Development Laboratories

A number of " laboratories" have been proposed to aid software development by providing an "integrated" s e t of t o o l s . These a r i s e in two d i f f e r e n t s i t u a t i o n s . The f i r s t one i s a development group which needs t o o l s and in which management decides some investment in providing an integrated s e t of t o o l s i s d e s i r a b l e . 1 Examples of t h i s are the DAIS system of the U.S. Air Force, (Ruth 1973) (Figure 2 . 4 . 1 ) , the SDL Laboratory (Naval E l e c t r o n i c s Laboratory Center (1976) , and the Support Software System described by Crafford, e t a l . (1976) . An ear ly example i s Clear-Caster (Brown 1969) . A system which has been in

operat ional use for severa l years i s CADES, produced by ICL for support of production and maintenance of an operating system (Prat ten and Snowdon 1976). Davis and Vick (1976) descr ibe the SDS system which i s intended for support o f development of r e a l time systems. In t h e s e s i t u a t i o n s the re levant t o o l s are i d e n t i f i e d and some investment i s made in making the t o o l s e a s i e r t o use by providing standard i n t e r f a c e s and providing standard data base systems.

Another c l a s s of such systems are ones which are b a s i c a l l y designed as programming development l a b o r a t o r i e s . These include de Jong ( 1 9 7 3 ) , TOPD (Henderson and Snowdon 1974), ECL (Wegbreit 1971, Cheatham and Wegbreit 1972), and SL-1 (Gardner, e t a l . 1976) .

A proposal for such a system i s g iven by I r v i n e and Brackett (1976) (Figure 2 . 4 . 2 ) . They view t h e i r SEF (Software Engineering F a c i l i t y ) as c o n s i s t i n g of a System Analyzer, an I n t e r f a c e , a Test and Val idate Module, and a Report Generator. A l l of these i n t e r f a c e with a Software Engineering Data Base. Other proposals have been made by Hamilton and Zeldin (1976) , Walters ( 1 9 7 7 ) , and F a l l a , e t . a l . (1976) .

Another example of such a system or iented not so much towards software development, but ra ther towards providing app l i ca t ion users d i r e c t a c c e s s t o a number of t o o l s i s the GMIS system developed by Donovan (1976) . GMIS provides the a c c e s s through the use of the v i r t u a l machine concept and through a general ized r e l a t i o n a l data base management system.

These software development l a b o r a t o r i e s form the b a s i s for the Software Support System proposed in Sec t ion 3 .

2 .5 Appl icat ion Management System (AMS)

The Appl icat ion Management System (AMS) was developed by TRES, Inc; user experience i s described by Wright (1975) and in the EDP Analyzer, Canning (1974) . An overview of the system i s g iven in Figure 2 . 5 . 1 .

The system c o n s i s t s of four major subsystems. Each produces or updates a data base . The f i r s t subsystem, the Data Dict ionary Generator, a c c e p t s data d e f i n i t i o n and produces the Data D i c t i o n a r y . The second subsystem, the AMS Compiler, u s e s t h i s Data Dict ionary and produces a data base o f data process ing modules from statements in a Data Process ing Language. This data base t o g e t h e r with the Data Dict ionary i s used by the t h i r d subsystem, the AMS Configurator, t o produce an executable system c a l l e d the Run Control F i l e . The fourth subsystem, the AMS Monitor, e x e c u t e s the Run Control F i l e under the contro l o f the operat ing system. Each of the subsystems i s c o n t r o l l e d by a Control Language and each one a l s o produces documentation in addi t ion t o updating the

AMS data bases .

Wright (1975) descr ibes the use of AMS i n the development of two systems LMS and FMS; some information from h i s paper i s summarized i n Appendix 2 .

1 For an i n t e r e s t i n g d i scuss ion of the r o l e of t o o l development in large p r o j e c t s , see Brooks 1975, p. 127.

- 197 -

2.6 The Information Automat

The Information Automat has been proposed by Wilson (1976). (See also Mills and Wilson (1976)). He begins with a premise that all the support software, including the operating systems, the system utilities, data base management systems, compilers, etc., have been developed independently and each has its own language and its own interfaces. He proposes to develop a kernel system which will be the central software surrounding the hardware to provide these services in an integrated fashion, Hofnagle and Wilson (1976), (Figure 2.6.1). Surrounding this kernel system there will be other layers of support which will provide necessary services for application development and operation. The basic concept is that one language can serve as the communication media for all the various services. His kernel system therefore will provide the basic support that are now provided by a number of independent systems: TSO, JCL, IMS, GIS, FORTRAN, COBOL, PL/I, OS/VS, etc. The central concept is a language known as a "semantic language" which can be used at each level for each service. While the vocabulary and the actions will vary, the structure will be the same and hence it will be simpler to learn by all those who have to use it.

The fundamental advantage of the approach will be to eliminate duplication. Now each tool in the support systems in today's system must have its own language interpreter and analyzer; in the Information Automat kernel system only one will be required. Similarly, all data base management will be done by one program and all the support systems will use the same data base system. This will eliminate the incompatibility among the interfaces of the various support systems. The Information Automat proposal has been described in some detail in a number of documents, but it has not yet been implemented. It is undoubtedly possible to do so and to produce a system which is much smaller and more compact and easier to use than existing systems. However, the elapsed time and costs required are likely to be large. In addition it is likely to be incompatible with existing systems and would therefore require anyone planning to use it to start afresh with this system. Existing software tools would have to be rewritten to be included.

2.7 S y n m a i - Y and Conclusions

A number of software tools are being developed. However, they are seldom compatible. A user has to learn each of the tools, prepare the input in the form needed, and probably have to use the tools on different computing environments.

Some argue that the software development facilities can now be built, for example, Stillman and Leong-Hong (1975):

"The technology already exists to construct a software production facility. Its components, e.g., advanced programming languages, structured programming precompilers, dynamic analyzers, intelligent text editors and sophisticated file management systems, are within the state of the art. What has not been done is to identify and develop an effective set of tools, integrate them into a single system, and make that system available to a broad spectrum of users."

This, at the present time, is probably a little premature. It is certainly true that the individual components can be constructed. However, the technology to produce an integrated set of tools still remains to be demonstrated. A number of approaches are being tried and more have been proposed as the brief summary given in this paper shows.

The approach followed by the National Software Works will undoubtedly make it easier for computer scientists to use tools developed and installed at another computer environment. However, it will probably not be directly useful in systems departments or for software development in which operational software must be produced.

The approach implied by the Information Automat is no doubt ideal and, if implemented, could result both in a substantial decrease of the size of software required for a complete set of tools and a substantial decrease in the cost of using the tools. However, even if it were implemented, there would be problems with incorporating the already existing software produced under previous methods.

One way to solve the interface problem is to have the tools work from a common data base. The approaches to building programming laboratories are usually based on the concept of one level of user using one basic language. To be more useful these systems will have to serve a number of different types of users with a number of different language levels.

What is likely to be practical and applicable in the next few years is the concept of a coordinated facility for software development that makes use of existing operating systems and some other standard software such as data base management systems. Furthermore, this facility should provide not only for the development of new software but also for the maintenance of existing applications software. The specification for such a facility are discussed in the next section.

3. Software Support Systems (SSS)

This section outlines the requirements for a Software Support System (SSS) which would provide a coordinated set of tools for software development, operation and maintenance. The facilities discussed are those necessary to develop a new software system to meet a given set of requirements in the environments described in section 1. The specifications outlined in this section are based on the analysis of software development systems (some of which are mentioned in Section 2) and on experience with prototypes of parts of a system, such as the Problem Statement Analyzer (PSA), Teichroew and Hershey (1977).

Then, assuming that a basic Software Support System exists, the next two sections will describe additional methods of decreasing the cost and increasing the quality of the completed products. Section 4 is devoted to methods for reducing the amount of software which must be produced manually by having more of the software produced by the computer. Section 5 is concerned with synthesizing a system out of software which already exists, i.e., out of "reusable modules".

3.1 Software Support System as â Decision Support System

- 198 -

It has become fashionable to characterize certain types of information processing systems as Decision Support System. For example, Sprague and Watson (1977) define them as follows:

"Just recently, information systems with rather unique characteristics have begun to emerge. These systems, usually referred to as Decision Support Systems, feature decision models, a data base and the decision maker as subsystems and are specifically oriented to supporting decision making."

and state that a

"Decision Support Systems (DSS) should have the following characteristics.

1. The DSS is designed specifically to support decision making. Attention to information flows, report structure, and data base design is specifically related to this primary objective.

2. The DSS is interactive to allow the manager or his representative fast access to models and data. The interactive capability is not necessarily to provide immediate access to minutes-old data, but, rather, to give access to data and models at a speed which matches the thought processes of the manager.

3. The DSS is flexible enough to satisfy the decision making requirements of many types of managers - those in different functional areas, at various managerial levels, and with different management styles.

4. The DSS is an integrated set of data and models which allows the models to work together, and thus avoid suboptimization whenever possible.

5. The DSS is dynamic enough to keep itself up to date without major or frequent ad hoc revisions.

6. The DSS is sophisticated, utilizing modern information processing and management science techniques whenever appropriate."

The Software Support System proposed in this paper can be considered a Decision Support System in the sense that it supports the decision making by System Management (usually a separate department in an organization), Project Leaders, Analysts, System Architects, Software Designers, Programmers, System Operators, Data Base Designers, Data Base Administrators, Project and Program Librarians, and Target System Users, that is, all personnel associated with information processing system and software system development, use and maintenance.

3.2 Users

One of the most effective ways to ensure that a system will be operationally feasible and economically cost effective is to have one system provide for all the needs of a set of users whose needs are related.

All users should be able to enter the results of

their own decisions into the Software Support System data b a s e and then should be able to obtain the information implied by the above characteristics of Decision Support System. An overview of the interaction of the various users with the Software Support System is shown in Figure 3.2.1.

Information Processing Systems management should obtain summary reports describing the status of various projects and various systems. The systems department staff should be able to obtain summary information necessary for the coordination of various projects, evaluation of new projects, and determination of the impact of proposed changes. Project Leaders need to obtain relevant data about projects they manage including both management and technical data.

The Analysts should be able to obtain status and checking reports about the data entered into the data base, including its consistency and completeness. After the analysis is completed, they should also obtain the necessary final reports.

The System Architect should be able to obtain the description of the overall system with which he is concerned and all the information provided by the Analysts. The Software Designer should be able to obtain the requirements produced by the Analysts as well as the specification produced by the System Architect. The Programmer should be able to obtain the up to date specification of the programs he is assigned to develop and the source code of programs of similar functions as well as reports indicating whether all program branches were tested against all requirements and whether the programming documentation is complete. The System Operators should be able to obtain an up to date report on the status and progress of the operated application system (input data preparation, error messages issued, handling of exceptions, action report handling by the target u s e r s ) . During operations, the Operation Staff should be able to record operations data and relate it to the system description. Similarly, the Data Base Designer should be able to obtain the requirements for the data base derived by the Analysts and the System Architect. The Data Base Administrator should be able to enforce data base standards and determine the requirements for integrated data bases. The Project Librarian and Program Librarian together with the maintenance staff, should be able to keep track of all the information regarding the project documentation. It is their responsibility to maintain a complete description of the system and a record of changes that have been made. Target System Users should be able to obtain the description of target systems that pertain to them.

3.3 Data Base

In order to ensure that all the relevant data will be available, it will be necessary to store it in one integrated data base in which the various types of information are separately identified. Thus, the appropriate subparts of the information can be selected for use by the various individuals. As with any data base system, appropriate controls must be exercised to ensure that the integrity of the data base is preserved. Individuals must have access to only that part of the information that they are entitled to and are able to modify, change or augment only the part of the data base which has been authorized for them.

- 199 -

The data base s t ruc ture w i l l be very complex; for example, Figure 3 . 3 . 1 shows the data s tructure for a prototype of one sub-subsystem of an Software Support System which i s designed for the s torage , manipulation and r e t r i e v a l of FORTRAN modules.

3 .4 Major Subsystems a£ a. Software Support System

The Software Support System would c o n s i s t of a number of major subsystems as shown in Figure 3 . 4 . 1 .

The Requirements Determination System al lows Analysts and Target System Users t o enter data descr ibing e x i s t i n g and proposed systems. The software performs various checks and analyses and produces hard copy documentation on reques t . I t maintains a data base containing the descr ip t ion of the targe t system from the "user ' s point of view".

The Development System al lows A r c h i t e c t s , Software Des igners , Data Base Designers and Programmers t o develop and construct a system t o accomplish a s e t of requirements recorded in the Requirements Data Base. This system i s divided i n t o two subsystems. F i r s t , the Software Engineering F a c i l i t y i s designed t o permit the rapid and e f f i c i e n t development of a prototype t o demonstrate f e a s i b i l i t y . This i s c o n s i s t e n t with the d e f i n i t i o n of Software Engineering g iven in Sect ion 1 . 3 - 3 . Second, the Software Production System i s designed t o begin with a prototype system and produce a production v e r s i o n .

The Support System al lows software systems to be operated and maintained. I t i s subdivided i n t o two systems. The Operations F a c i l i t y c o n t r o l s the operation of the t a r g e t system in an actual environment. I t c o l l e c t s s t a t i s t i c s that may be used t o improve performance. The I n s t a l l a t i o n and Maintenance system provides the c a p a b i l i t y to i n s t a l l the target system in a p a r t i c u l a r hardware environment and t o maintain i t as changes occur. The Management System al lows management t o maintain plans and obta in data from each of the various project and system data base s . I t a l s o provides for a l l the coordinat ion necessary among projec t s and systems.

The Data Base System conta ins a l l the data that describe the target systems and the p r o j e c t s . I t i s subdivided i n t o a number of data bases , but the re levant in terconnec t ions among a l l the subdata bases are maintained.

4 . Reducing JUS. Manual E££ar_t_ jfca fxadjagjE Software

4.1 Classification OL Methods

In the d i s cus s ion in the previous s e c t i o n , i t was i m p l i c i t l y assumed that the bas ic t o o l for software development was an assembly or higher l e v e l programming language (FORTRAN, COBOL, PL/1, ALGOL, PASCAL, e t c . ) . The major purpose of the Software Support System was t o have the c l e r i c a l operat ions performed by the computer. In add i t ion , the Software Support System performed a number of checks and provided management information. In essence the software was s t i l l produced manually, though the process was aided by the computer. This s e c t i o n i s concerned with methods by which the software can be produced more automatical ly and, t h e r e f o r e , the manual e f f o r t can be reduced. A l l o f these methods b a s i c a l l y attempt to reduce the number and e f f o r t of manual

operat ions between a statement of requirements and the executable system code. The "decis ion models" and dec i s i on making a i d s of the Software Support System w i l l be increased and i t w i l l become more of a Decis ion Support System.

The methods for producing executable systems from higher l e v e l d e s c r i p t i o n s may be c l a s s i f i e d in three ways. One approach t o higher l e v e l d e f i n i t i o n i s t o "speci fy" larger u n i t s of the system. This concept i s d iscussed in s e c t i o n 4 . 2 . Another approach i s t o present the s p e c i f i c a t i o n s in a form natural to human beings but which can a l s o be implementated by computer software . These forms are described i n s e c t i o n 4 . 3 . The methods by which the executable system i s a c t u a l l y produced are out l ined in s e c t i o n 4 . 4 . Conclusions on the present s t a t e of these methods and trends in t h e i r use are g iven in s e c t i o n 4 . 5 .

4 .2 isssl SiL S p e c i f i c a t i o n s

Software systems g e n e r a l l y may be c l a s s i f i e d as described in s e c t i o n 1 . 1 . 3 . When the current general purpose programming languages are used, the s tructure i s completely s p e c i f i e d by the programmer and the compiler has very l i t t l e freedom i n changing the s t r u c t u r e . Therefore i f the compiler i s t o do more of the work i t must have more freedom to r e c e i v e s p e c i f i c a t i o n s at a higher l e v e l . A number of l e v e l s are p o s s i b l e ; here the l e v e l s used are system, subsystem, and module.

S p e c i f i c a t i o n s g iven a t the system l e v e l are funct ional s p e c i f i c a t i o n s that s t a t e what the system i s t o do but not how i t i s to do i t , at l e a s t not in a way that cons tra ins the software s t r u c t u r e . There need, there fore , be no correspondence between the s tructure in the s p e c i f i c a t i o n s and the s tructure in the software .

When s p e c i f i c a t i o n s are g iven a t the subsystem l e v e l , each subset of s p e c i f i c a t i o n w i l l be transformed i n t o a software subsystem. One case where t h i s occurs i s where s p e c i f i c a t i o n s are given in terms of a t r a n s a c t i o n . The s p e c i f i c a t i o n for a g iven type of t r a n s a c t i o n are implemented as one subsystem; within a s i n g l e type of t ransac t ion the compiler may choose i t s own software s t r u c t u r e .

When s p e c i f i c a t i o n s are given at the module l e v e l , each module i s implemented as a software module and within a module the compiler dec ides on the software s t r u c t u r e .

4 .3 Form o£ S p e c i f i c a t i o n

The form in which requirements are acceptab le as input t o the computer may be c l a s s i f i e d as fo l lows :

Natural language. I d e a l l y , any t e x t in a natural language w i l l be a c c e p t a b l e . The software system s t a r t s without any knowledge of the problem domain and b u i l d s i t s e n t i r e knowledge on what i t obta ins from the input . Severa l systems based on natural languages are d i s c u s s e d by Heidorn (1976) .

S p e c i a l i z e d languages . The s tructure of the input i s s t i l l natural language but c e r t a i n words or phrases have preass igned meanings to the system. These languages are e a s i e r to use and the s p e c i f i c a t i o n s are e a s i e r t o implement but each language i s r e s t r i c t e d t o a s p e c i a l a p p l i c a t i o n f i e l d .

- 200 -

Rela t iona l languages . These languages have s p e c i f i c s t r u c t u r e s and a c e r t a i n s e t of reserved words. Input i s free format. Examples are the Problem Statement Language (Teichroew and Hershey, 1976) and Requirements Statement Language ( B e l l , e t a l . 1977 and Alford 1977).

Forms. Forms have long been advocated as a means of express ing requirements s i n c e they are e a s i e r t o use than languages. Examples of the use of forms are the ADS (Accurately Defined Systems) developed by National Cash Regis ter and TAG (Time Automated Grid) developed by IBM. (A comparison i s g iven by Teichroew 1972). A recent example i s the programming language used in The System for Business Automation (SBA) prepared by Zloof and de Jong (1977) . An example of a program t o produce an invo ice i s g iven in Figure 4 . 3 . 1 . A diagram of the language s tructure i s given in Figure 4 . 3 . 2 . The language attempts t o show the format of the documents g r a p h i c a l l y . The domain over which the program i s t o be executed i s shown by underl in ing an item in a t a b l e (which i s considered to be a r e l a t i o n ) .

Dec i s ion Tables . Decis ion t a b l e s have been advocated as use fu l t o o l s for spec i fy ing requirements. However, there appears t o be general agreement that they are not widely used. See , for example, Chvalovsky (1976) and Central Computer Agency (1973) . One of the reasons g iven in the l a t t e r report i s that dec i s i on t a b l e s by themselves are not enough, they should be incorporated i n t o a more comprehensive system. Attempts t o do so have been made in HSL/1 developed by Hoskyns (Rhodes, 1972) and marketed by Martin Marietta and in AMS developed by TRES, I n c . (Wright 1975) . The HSL/1 approach t o programming i s contrasted with the t r a d i t i o n a l method in Figure 4 . 3 . 3 . (The AMS system i s b r i e f l y described in s e c t i o n 3 . 3 . )

Quest ionnaires . The quest ionnaire approach i s simply a l i s t of mult ip le choice q u e s t i o n s . A s p e c i f i c a t i o n c o n s i s t s of the s e l e c t i o n of one of each of the a v a i l a b l e c h o i c e s . The f i r s t formal descr ip t ion of the technique appears to the one given by Ginsberg, e t a l . 1965. The combination of t h i s technique with dec i s i on t a b l e s was advocated by Low (1973):

"Programming by quest ionnaire combines aspects of dec i s ion t a b l e programming and general purpose programming by using dec i s ion t a b l e s t o construct an a p p l i c a t i o n program through the s e l e c t i o n of c e r t a i n source statements from a predefined f i l e . I t i s proposed that programming by quest ionnaire i s a usefu l compromise between general and s p e c i a l purpose programming for a s i g n i f i c a n t c l a s s of large s c a l e problems."

The most ex tens ive use of the technique appears t o be by IBM in the Applicat ion Customizer which i s used to produce executable code for System/3.

Graphical Languages. Graphical languages appear a t t r a c t i v e as a means of spec i fy ing requirements s ince human beings can comprehend a large amount of information when i t i s presented g r a p h i c a l l y . Graphical languages have been proposed as supplementary forms to other languages, ( s e e , for example, Young and Kent, 1961). When recorded manually, however, graphical languages must be transformed in to input s u i t a b l e for computer

process ing . Few organiza t ions y e t have ex tens ive c a p a b i l i t y to input graphical information d i r e c t l y and, there fore , graphical language input i s not widely used. This conclus ion i s a l s o reached by Rose ( 1 9 7 6 ) i n r e l a t i o n t o s p e c i f i c a t i o n o f hardware :

"Computer hardware d e s c r i p t i o n languages (CHDL's) w i l l continue t o develop and to be used as "front ends" of convent ional hardware des ign automation systems, but the research emphasis w i l l have been on system d e s c r i p t i v e languages such as that used by LOGOS. I t i s probable that these languages w i l l be s t r i n g - o r i e n t e d rather than graphic because of the cos t of s o p h i s t i c a t e d t ermina l s ."

Module S p e c i f i c a t i o n Languages. These languages focus on s p e c i f i c a t i o n s at the func t iona l l e v e l and usua l ly include some f a c i l i t y t o descr ibe r e l a t i o n s h i p s among modules. Examples are the languages proposed by Rin (1976) , Beck(1976) , and DeRemer and Kron(1976).

Augmented (Procedural) P r n g r - a m m l n g Languages. A number o f extens ion t o procedural language have been proposed. Some of these incorporate structured, programming c o n s t r u c t s , for example RATFOR, (Kernighan and Plauger , ( 1 9 7 6 ) ) . Others are des igned, not so much to reduce the amount of manual programming, a s t o provide f a c i l i t i e s to s t a t e requirements which w i l l make the o b j e c t code more r e l i a b l e . Another augmentation i s in the d i r e c t i o n o f making the language e x t e n s i b l e for data types (Liskov 1975) .

4 .4 Production of Software Systems

The methods d i scussed in t h i s s e c t i o n are designed t o implement higher l e v e l s p e c i f i c a t i o n s (a t one of the l e v e l s o u t l i n e d in 4 . 2 ) , in one of the forms described in 4 . 3 , and produce an "executable" system automat ica l ly with minimum human i n t e r v e n t i o n . For the purpose of t h i s s e c t i o n , i t does not matter whether the "executable" system i s objec t code for a g iven computing environment or whether i t i s source code i n a programming language. In p r a c t i c e , o f course , the performance of the system may very we l l be a f f e c t e d by what form of executable system i s produced.

4 . 4 . 1 A r t i f i c i a l I n t e l l i g e n c e . The input t o t h i s method i s e i t h e r t e x t in a natural language or in a s p e c i a l i z e d natural language. A survey of the s t a t e - o f - t h e art in automatic programming natural language d ia logue i s g iven by Heidorn (1976) . He begins with t h i s in troduct ion:

"Since the e a r l y days of computing, e f f o r t has been put i n t o automating more and more of the programming proces s . The u l t imate o b j e c t i v e in automatic programming i s a system that can carry on a natural language dialogue with a user ( e s p e c i a l l y a nonprogrammer) about h i s requirements and then produce an appropriate program for him. Although the b a s i c idea of 'programming i n Eng l i sh ' has o f ten been expressed in the l i t e r a t u r e , only in recent years have any s e r i o u s attempts been made toward producing such a system."

He then descr ibes four experimental systems and d i s c u s s e s a number of research i s s u e s and

- 201 -

concludes with the statement:

"Higher level considerations such as this will have to be dealt with in addition to the more technical issues discussed above before natural language automatic programming can become a practical reality."

One o f the systems surveyed is the SAFE system being developed by Balzer (ISI Research Staff 1 9 7 6 ) . He describes his approach as follows:

"Only modest gains in programming productivity have been produced in 25 years of software research, but the groundwork has been laid for major advances through rationalization and automated aids. This groundwork rests on two critical ideas: that specification must be separated from implementation, and that the separation between these two processes should be a formal operational abstract (i.e., very high level) program rather than a nonoperational requirements specification. Structured programming represents the first results of combining these ideas. It is a special case of a more general two-phase process, called Abstract Programming, in which an informal and imprecise specification is transformed into a formal abstract operational program, which is then transformed into a concrete (i.e., detailed low-level) program by optimization. Abstract programming thus consists of a specification phase and an implementation (optimization) phase which share a formal abstract operational program as their common interface."

He summarizes the current status as follows:

"Though the results using this example are very promising, and although we have attempted to build a general system capable of handling a wide variety of specifications from many different domains, it is extremely difficult to extrapolate from a single data point. We therefore are planning to present several different and more complex examples to the system during the next year."

There seems to be general agreement that while this approach is promising and research should be continued, it will be some time before this method is capable of producing results that compare with what now is being produced manually.

4.4.2 Software System Generators. The concept of generating complete systems from a set of requirements has long been a dream of application software developers. Recently, the generator concept has been described by Dolotta, et al. ( 1 9 7 6 ) . Their description is given in Appendix 3.

The system generator approach differs from the artificial intelligence approach primarily in that some knowledge of either the application area or the software system structure is assumed. The domain is therefore much more limited and specialized.

Three types of software system generators may be considered. In the first, the generator is capable of producing modules and assembling them

to accomplish the stated requirements. In its full generality, this is equivalent to the artificial intelligence approach. In practice, however, the domain must usually be constrained in some way.

A second approach assumes the existence of a number of modules. The generator needs only to decide which modules are necessary and provide for the required interconnections. The system based on "Programming by questionnaire" (Ginsburg (1965), Low ( 1 9 7 2 ) ) is an example of this level of generators. Another example is automatic program synthesis (Feldman (1972), and Lee, Charnig and Waldinger (1974)).

A third level occurs when a skeleton of the system exists and the generator merely parameterizes it to fit a particular environment. The system generation of an operating system for a particular environment is an example of this level.

4.4.3 Module Preprocessors. The module preprocessors work at the module level, i.e. , each unit of specification is transformed into a software module. The methods differ by the degree to which the specification is rearranged or transformed by the preprocessor. In the system proposed by Beck (1976) for example, the specification given in a module specification language are transformed to "Standard Processes ." In general, these methods are based on producing a directed graph from the specifications and then partitioning the graph in some way.

4.4.4 Compilers for Augumented Programming Languages. These software systems accept statements in augumented languages (including structural programming constructs and abstract data types) and produce either source statements in the programming language or object code. These compilers expand the augumented statements but generally do not rearrange statements to the extent done by the Preprocessors.

4.5 Conclusions

The preceeding discussion indicates that a number of approaches for producing executable systems from higher level specifications have been proposed and/or are being developed. These use different levels of specification, different forms of specification and different approaches to the generation of executable systems. However, the use of these techniques, to reduce the amount of software that must be produced, is so far limited.

System Generators are the method with the best chance to yield a dramatic reduction in the cost of the software components of systems and at the same time improving the effectiveness of the system for the user. However, before System Generators achieve widespread use, a number of problems will have to be overcome. The most pressing problem is introducing methods for persuading the organizational unit that needs a new system, to accept one that is generated rather than custom built. One of the necessary conditions for acceptance of the generated target system is that it, in fact, accomplish the requirements. Thus, considerable skill is required to produce generators that meet a wide enough range of users to justify the investment.

Under the right circumstances, these approaches may contribute substantially to reducing the cost of high quality software. Thus, it is worthwhile

- 202 -

t o c o n s i d e r t h e f a c t o r s w h i c h a r e c u r r e n t l y l i m i t i n g t h e i r u s e , s o t h a t t h e s e t e c h n i q u e s c a n b e i n c o r p o r a t e d i n t o t h e a p p r o a c h o u t l i n e d i n s e c t i o n 6 .

5 . R e d u c i n g t h e A m o u n t o f S o f t w a r e t h a t m u s t b e P r o d u c e d

5 . 1 I n t r o d u c t i o n

T h e r e a r e a n u m b e r o f m e t h o d s , t e c h n i q u e s , a n d a p p r o a c h e s t h a t w i l l r e d u c e t h e a m o u n t o f " n e w " s o f t w a r e n e c e s s a r y t o m e e t a s p e c i f i c r e q u i r e m e n t . A p e r s o n o r o r g a n i z a t i o n who h a s a r e q u i r e m e n t c a n o b t a i n s o f t w a r e t o m e e t h i s n e e d s b y o n e o f t h e w a y s i d e n t i f i e d i n s e c t i o n 1 . 2 : d e v e l o p t h e s o f t w a r e h i m s e l f , h a v e i t d e v e l o p e d f o r h i m , s e l e c t f r o m a s e t o f a v a i l a b l e p a c k a g e s , o r s e l e c t i t f r o m a s e t o f a v a i l a b l e " t u r n - k e y " s y s t e m .

T h e g r e a t e r t h e p r o p o r t i o n o f t h e s o f t w a r e t h a t i s a l r e a d y a v a i l a b l e , a n d t h e r e f o r e , d o e s n o t h a v e t o b e d e v e l o p e d , t h e m o r e t h e u s e r g a i n s . T h e s o f t w a r e s h o u l d b e l e s s e x p e n s i v e s i n c e t h e d e v e l o p m e n t c o s t i s s p r e a d o v e r m o r e u s e r s , i t s h o u l d b e a v a i l a b l e s o o n e r s i n c e i t d o e s n o t h a v e t o b e d e v e l o p e d , a n d i t s h o u l d b e m o r e r e l i a b l e s i n c e i t h a s p r e s u m a b l y a l r e a d y b e e n t e s t e d .

T h e d e v e l o p e r o f s o f t w a r e s h o u l d a l s o g a i n f r o m u s i n g p r e d e v e l o p e d s o f t w a r e ; h e s h o u l d b e a b l e t o i m p r o v e h i s p r o f i t t h r o u g h i n c r e a s e d s a l e s s i n c e e a c h u s e r c a n o b t a i n t h e s o f t w a r e a t a l o w c o s t , h e w o u l d b e a b l e t o i n c r e a s e t h e a m o u n t o f d e v e l o p m e n t h e d o e s s i n c e h e b e c o m e s m o r e c o m p e t i t i v e a s c o m p a r e d t o t h e c u s t o m - t a i l o r e d d e v e l o p e r s , a n d h e c a n a f f o r d t o i n v e s t i n i m p r o v i n g h i s d e v e l o p m e n t m e t h o d s a l o n g t h e l i n e s d e s c r i b e d i n s e c t i o n s 3 a n d 4 .

T h e p o t e n t i a l a d v a n t a g e s o f r e u s a b l e m o d u l e s i s i l l u s t r a t e d by t h e p r i c e c h a r g e d b y o n e s o f t w a r e c o m p a n y , M a r t i n - M a r i e t t a , a s s h o w n i n A p p e n d i x 4 . A c c o r d i n g t o i t s a d v e r t i s e m e n t s , t h e c o m p a n y c h a r g e s $ 6 p e r s t a t e m e n t f o r c u s t o m - t a i l o r e d s y s t e m b u t o n l y $1 p e r s t a t e m e n t i f t h e s y s t e m i s b u i l t e n t i r e l y o u t o f e x i s t i n g m o d u l e s .

D e s p i t e t h e a p p a r e n t a d v a n t a g e s o f m a k i n g maximum u s e o f e x i s t i n g s o f t w a r e a n d o f d e s i g n i n g a n d b u i l d i n g s o f t w a r e t o h a v e a maximum n u m b e r o f u s e r s , a l a r g e a m o u n t o f t h e d e v e l o p m e n t t o d a y i s c o n c e r n e d w i t h d e s i g n i n g a n d b u i l d i n g new c u s t o m - t a i l o r e d s y s t e m s t o m e e t e a c h r e q u i r e m e n t . T h i s s e c t i o n e x a m i n e s t h e p r e s e n t s t a t u s o f " g e n e r a l i z e d " s o f t w a r e a n d c o n s i d e r s some o f t h e p r o b l e m s t h a t m u s t b e s o l v e d i f t h e c o n c e p t i s t o b e i n c o r p o r a t e d i n t o t h e S o f t w a r e S u p p o r t S y s t e m .

S e c t i o n 5 . 2 d i s c u s s e s a t t e m p t s t o u s e e x i s t i n g s o f t w a r e w h e r e t h e s o f t w a r e i t s e l f c a n b e o b t a i n e d a t n o m i n a l c o s t . S e c t i o n 5 . 3 o u t l i n e s v e r y b r i e f l y t h e c u r r e n t s t a t u s o f t h e s o f t w a r e i n d u s t r y w h i c h , by d e f i n i t i o n , i s m o t i v a t e d t o p r o d u c e s o f t w a r e w i t h a s b r o a d a m a r k e t a s p o s s i b l e . S e c t i o n 5 . 4 d e s c r i b e s o n e a t t e m p t t o d e v e l o p a m e t h o d t o s y n t h e s i z e s y s t e m s f r o m m o d u l e s b a s e d o n a p p l i c a t i o n f u n c t i o n s . S e c t i o n 5 . 5 a n d 5 . 6 o u t l i n e a t t e m p t s , a t n a t i o n a l l e v e l s , t o d e v e l o p s y s t e m s b a s e d o n r e u s a b l e m o d u l e s i n t h e USSR a n d J a p a n r e s p e c t i v e l y . S e c t i o n 5 . 7 a n d 5 . 8 d e s c r i b e s some o f t h e i s s u e s t h a t m u s t b e a d d r e s s e d a n d o u t l i n e s some p o s s i b l e a p p r o a c h e s i n r e u s i n g m o d u l e s a n d g e n e r a l i z e d s o f t w a r e r e s p e c t i v e l y .

S e c t i o n 5 . 9 s u m m a r i z e s how s o f t w a r e d e v e l o p m e n t i n

a S o f t w a r e S u p p o r t S y s t e m , a s d e f i n e d i n S e c t i o n 3 a n d a u g m e n t e d b y t h e s o f t w a r e g e n e r a t o r t e c h n i q u e s d i s c u s s e d i n S e c t i o n 4 , c a n b e f u r t h e r i m p r o v e d b y i n c o r p o r a t i n g t h e c o n c e p t s o f r e u s a b l e m o d u l e s a n d g e n e r a l i z e d s o f t w a r e .

5 . 2 S o f t w a r e D i s t r i b u t i o n

A g r e a t d e a l o f s o f t w a r e i s a v a i l a b l e f o r u s e a t a n o m i n a l o r e v e n z e r o c o s t . N e v e r t h e l e s s t h i s s o f t w a r e i s n o t w i d e l y u s e d . T h e r e a s o n s f o r t h i s i n c l u d e a l l t h e r e a s o n s g i v e n i n s e c t i o n 2 f o r t h e s p e c i f i c c a s e o f s o f t w a r e f o r d e v e l o p m e n t o f a p p l i c a t i o n s o f t w a r e . L a r g e o r g a n i z a t i o n s f r e q u e n t l y h a v e p r o g r a m s t o d i s s e m i n a t e k n o w l e d g e o f a v a i l a b l e s o f t w a r e . F o r e x a m p l e , C o m p u t e r w o r l d r e c e n t l y r e p o r t e d o n o n e a t t e m p t b y t h e U . S . G o v e r n m e n t t o f o s t e r s h a r i n g o f s o f t w a r e ( A p p e n d i x 5 ) .

5 . 3 G e n e r a l i z e d S o f t w a r e P r o d u c e d bv t h e S o f t w a r e I n d u s t r y

T h e s o f t w a r e i n d u s t r y m a r k e t s p r o g r a m p a c k a g e s w h i c h a r e u s u a l l y r e f e r r e d t o a s g e n e r a l i z e d s o f t w a r e s i n c e a p a c k a g e i s i n t e n d e d t o s a t i s f y a l a r g e n u m b e r o f u s e r s w i t h a s l i t t l e c h a n g e a s p o s s i b l e . M a n y o r g a n i z a t i o n s w h i c h d e v e l o p s o f t w a r e f o r t h e i r own u s e a l s o a t t e m p t t o s e l l i t t o o t h e r s a s g e n e r a l i z e d s o f t w a r e . W h i l e m a n y p a c k a g e s a r e a v a i l a b l e v e r y f e w o f t h e m a c h i e v e a n y s u b s t a n t i a l n u m b e r o f i n s t a l l a t i o n s . T h e m o s t s u c c e s s f u l i s M a r k I V w h i c h i s m a r k e t e d b y I n f o r m a t i o n , I n c . A c c o r d i n g t o D a t a m a t i o n ( D e c e m b e r 1 9 7 6 , p . 1 4 2 ) t h e r e a r e o v e r 1 0 0 0 i n s t a l l a t i o n s o f M a r k I V w h i c h h a v e r e s u l t e d i n m o r e t h a n 4 0 , 0 0 0 , 0 0 0 d o l l a r s i n r e v e n u e . A n a l y s i s o f o t h e r p a c k a g e s t h a t h a v e b e e n p u r c h a s e d b y many u s e r s , shows t h a t t h e m o s t s u c c e s s h a s b e e n a c h i e v e d i n a p p l i c a t i o n - i n d e p e n d e n t p a c k a g e s . D a t a b a s e m a n a g e m e n t i s a n e x a m p l e o f a n a r e a w h e r e f e w o r g a n i z a t i o n s c a n now j u s t i f y p r o d u c i n g a s o f t w a r e s y s t e m f o r t h e m s e l v e s . H o w e v e r , s o f t w a r e e n t e r p r i s e s h a v e h a d l i m i t e d s u c c e s s i n m a r k e t i n g g e n e r a l i z e d a p p l i c a t i o n p a c k a g e s .

5 . 4 M o d u l a r i z a t i o n B a s e d o n D e c o m p o s i t i o n o f A p p l i c a t i o n F u n c t i o n s

T h e s y n t h e s i s a p p r o a c h t o s o f t w a r e s y s t e m d e v e l o p m e n t a t t e m p t s t o r e a l i z e a s y s t e m t o a c c o m p l i s h a g i v e n s e t o f r e q u i r e m e n t s f r o m a g i v e n l i b r a r y o f a v a i l a b l e c o m p o n e n t s . T h e r e h a v e b e e n a n u m b e r o f a t t e m p t s t o u s e t h i s a p p r o a c h t h o u g h f e w h a v e b e e n r e p o r t e d i n t h e l i t e r a t u r e i n a n y d e g r e e o f d e t a i l . O n e a t t e m p t was t h e I n f o r m a t i o n S y s t e m s E n g i n e e r i n g e f f o r t d e s c r i b e d b y W e l s h ( 1 9 6 8 ) . I t i s a n i n s t r u c t i v e e x a m p l e b e c a u s e i t i n v o l v e d a r e l a t i v e l y l a r g e e f f o r t s u s t a i n e d o v e r a n u m b e r o f y e a r s , b e c a u s e i t w a s c o n c e r n e d w i t h a p p l i c a t i o n m o d u l e s , a n d b e c a u s e i t d i d n o t s u c c e e d i n r e p l a c i n g t h e c o n v e n t i o n a l c u s t o m - t a i l o r i n g a p p r o a c h .

T h e e f f o r t was m o t i v a t e d b y t h e a t t e m p t o f a l a r g e i n d u s t r i a l f i r m t o a v o i d b u i l d i n g u n i q u e s y s t e m s t o a c c o m p l i s h e s s e n t i a l l y s i m i l a r r e q u i r e m e n t s ( p a y r o l l , p r o d u c t i o n s c h e d u l i n g , i n v e n t o r y c o n t r o l , e t c . ) i n e a c h s e m i - a u t o n o m o u s s u b s i d i a r y . ( T h e f i r s t a p p r o a c h w a s t o t r y t o b u i l d a s y s t e m t o a c c o m p l i s h a g i v e n r e q u i r e m e n t a t o n e s u b s i d i a r y a n d t h e n t r a n s p o r t i t t o t h e o t h e r s -t h i s w a s a b a n d o n e d a s i m p r a c t i c a l a f t e r a f e w a t t e m p t s ) . T h e a p p r o a c h , s u m m a r i z e d i n F i g u r e 5 . 4 . 1 , u s e s t h r e e t o o l s :

F u n c t i o n s - p r e d e f i n e d u n i t s o f i n f o r m a t i o n

- 203 -

process ing requirements. For example, one Function might be "determine manpower requirements".

S a t i s f i e r s - preprogrammed modules or rout ines that s a t i s f y a given Function. The l i b r a r y of S a t i s f i e r s may contain more than one S a t i s f i e r for a g iven Function.

Configurator - a form in which the needs or requirements of a part i cu lar s e t o f u s e r s are s t a t e d .

The s y n t h e s i s c o n s i s t s of three major s t e p s :

a. The requirements for a system are determined and expressed using the Configurator.

b. A s o l u t i o n t o the needs i s synthes ized us ing the Functions and the ava i lab le S a t i s f i e r s . I f no acceptable S a t i s f i e r i s a v a i l a b l e for a given Function, a new one i s produced.

s tandardizat ion of the modules i s widely emphasized (Maohrov e t a l (1974) , p. 281 and Myasnikov (1974) p.. 9 2 ) . Besides the l o n g - e x i s t i n g Central I n s t i t u t e of S c i e n t i f i c Research in Management and Control Technology in Minsk (employing s e v e r a l thousand r e s e a r c h e r s ) , i n 1974 the computer industry created in Kal in in a Software Development Center charged with deve loping , from standardized modules, a p p l i c a t i o n packages serving a l l the p o t e n t i a l users in the USSR, (Myasnikov (1974) p. 9 2 ) . The users are s t r o n g l y urged to bui ld "open" a p p l i c a t i o n systems, which could be enhanced in the future when the bas ic system has already been in operat ion for some t ime. The wide use of the f i r s t 130 standardized appl i ca t ion packages has been recommended by the Union Committee for Sc ience and Technology of the USSR Council of Min i s ters (Myasnikov (1974) p. 9 2 ) . The cooperation in t h i s f i e l d between the USA and the USSR has become f e a s i b l e s i n c e the same Committee recommended COBOL, ALGOL, FORTRAN and PL/1 as bas i c programming languages and the IBM standards have been adapted for the development of the RIAD Computer S e r i e s (Myasnikov (1974) p. 9 1 ) .

c . The system i s "assembled" and i s then ready for i n s t a l l a t i o n and t e s t .

A large part of t h i s development e f f o r t cons i s t ed of i d e n t i f y i n g and spec i fy ing the Functions. The c r i t e r i a vised t o i d e n t i f y the Functions were:

- the Functions had to be mutually e x c l u s i v e , - the Functions had to be exhaust ive , - the Functions had t o be of approximately the r ight s i z e .

Approximately f i f t y funct ions were i d e n t i f i e d and descr ibed. In some c a s e s a descr ip t ion required severa l hundred pages . The funct ions are l i s t e d i n Appendix 6.

Despite the e x t e n s i v e development e f f o r t and i n t e n s i v e attempts t o apply the r e s u l t s , the approach i s not being used. The reasons are par t ly t e c h n o l o g i c a l . Functions that covered data process ing , e . g . , Message Discrimination and Val idat ion , F i l e Update and Surve i l lance and Report Data Compiler, were apparently implemented in such a way that the synthesized system could not compete i n usage of computer resources with custom t a i l o r e d systems.

However, the main reasons for the lack of adoption were i n s t i t u t i o n a l . The managers of the s u b s i d i a r i e s could not be convinced that there would be s u f f i c i e n t ga ins t o warrant the l o s s of autonomy that they had with the custom t a i l o r e d systems. Corporate management on the other hand was not convinced that corporate b e n e f i t s would be s u f f i c i e n t t o warrant forcing the s u b s i d i a r i e s t o use the s y n t h e s i s approach against t h e i r w i l l .

5 .5 System Development in ihs. USSR

The USSR i s engaged in a major e f f o r t to develop a r e l a t i v e l y large number of computerized management information systems (Myasnikov 1974, pp. 8 8 , 9 5 ) . In order to f a c i l i t a t e the development procedure, d e t a i l e d g u i d e l i n e s have been e s tab l i shed and approved by the Union Committee for Science and Technology of the USSR Council of Ministers (1972) . The development procedure i s based on the concept of s y n t h e s i z i n g systems from a number of e x i s t i n g modules rather than custom building a system for each a p p l i c a t i o n . The need for

5.6 System Development la Japan

In 1973, the Japanese Ministry of I n t e r n a t i o n a l Trade and Industry (MITI) funded a p r o j e c t t o make i t e a s i e r , f a s t e r , and cheaper to produce a p p l i c a t i o n programs from small chunks of prev ious ly wri t ten and stored a p p l i c a t i o n modules, and assemble these i n t o working, or near ly complete , new programs. The r e s u l t s as reported by Datamation, (September 1976 p. 97), were as fo l l ows :

"The f i v e groups, however, each did t h e i r own thing with l i t t l e , i f any, management or coordination from a centra l body. There was not even agreement on the d e f i n i t i o n of a module. At l e a s t one group wrote i t s modules in FORTRAN. Another used DPL. And one group r e a l l y d idn ' t know what the o thers were doing. The r e s u l t , say some observers in Japan, was a f l o p . "

MITI in 1976 created a new corporat ion , J o i n t System Development Corporation (JSD), which has i n i t i a t e d a f i v e year program to produce a Program Produc t iv i ty Development System (PPDS). An overview of the i n i t i a l system i s g iven i n Figure 5.6.1 (JSD, 1976).

5.7 I s s u e s in Reusable Software

In dea l ing with a complex system, e i t h e r in analyz ing an e x i s t i n g system or in b u i l d i n g a new one, i t i s o f ten b e n e f i c i a l to t r e a t i t as a hierarchy of modules comprising the e n t i r e system (Simon 1962). The use of subassemblies in manufacturing industry i s a well-known engineer ing a p p l i c a t i o n of t h i s p r i n c i p l e . With regard t o information process ing systems, modularizat ion has long been recognized as d e s i r a b l e , and many papers have been wr i t ten on modular programs, modular sof tware , modular f i l e organizat ion , and modular systems a r c h i t e c t u r e . However, many systems when completed are not , i n f a c t , modular. There are , t h e r e f o r e , many f a c t o r s which tend t o work a g a i n s t e f f e c t i v e modularization even i f the d e s i g n e r s have that as t h e i r g o a l . Some argue t h a t modularization w i l l be achieved only i f i t i s forced and there i s no other c h o i c e .

- 204 -

5 .7 .1 How ia Modularize. Any given system can be decomposed i n t o smaller systems or components in many d i f f e r e n t ways. A number o f methods for decomposition have been proposed. Some of the problems are :

1. Whether t o modularize on appl icat ion- independent funct ions or on a p p l i c a t i o n dependent func t ions . Frequently an examination of app l i ca t ion software w i l l r evea l some app l i ca t ion independent funct ions that are repeated severa l t imes . The i d e n t i f i c a t i o n of these funct ions and the prov is ion of modules t o accomplish them when they are required usua l ly l e a d s t o a reduct ion in the amount of a p p l i c a t i o n software that i s needed. See for example IBM(1977).

2 . How t o separate data d e f i n i t i o n from process ing d e f i n i t i o n . In the ear ly days the lack of d i s t i n c t i o n between data and i n s t r u c t i o n s was regarded by many as one of the great achievements of the e l e c t r o n i c computer. I t has become i n c r e a s i n g l y c l e a r , however, that the d i s t i n c t i o n should be made and the trend i s c l e a r l y towards further and further separat ion .

- COBOL separated the Data Div i s ion from the Procedure D i v i s i o n , thus al lowing each to be def ined , and hopeful ly modified, separate ly though they have t o be compiled together .

- Data Base Management Systems carry t h i s concept one s t ep further by having separate Data D e f i n i t i o n Languages and Data Manipulation Languages.

- Data D i c t i o n a r i e s provide for d e f i n i t i o n of data elements that contain the user or iented d e s c r i p t i o n s as we l l as computer or iented d e s c r i p t i o n s .

- Another trend i s t o d i s t i n g u i s h data that descr ibes the s tructure of the organizat ion , and i s used t o control process ing , from other data. In i t s past they have frequently been embedded in the programs; the o b j e c t i v e now i s to remove them from the program and put them in t a b l e s so that the t a b l e s can be changed without changing the program.

3 . How t o separate process ing from contro l - f l ow . By separat ing modules which perform bas ic funct ions from the l o g i c which causes one function t o be performed rather than another, the l i k e l i h o o d that the bas ic modules w i l l be reusable i s increased.

5 . 7 . 2 What i s the Best S i ze for a Reusable Module. One of the bas ic quest ions in reusable module development i s the s i z e of the component of software which should be standardized or made reusable . The terminology, re ferr ing to s i z e of software components, used here i s defined in s ec t ion 1 . 1 . 2 . A l l of the l e v e l s system, including subsystem, program, rout ine and module have been used as the uni t of reusable components.

Many programming languages have prov i s ions for incorporating predefined s e t s of s tatements , usual ly c a l l e d macros. One of the very f i r s t

concepts in software development was that of the c losed subrout ine . Almost every i n s t a l l a t i o n has , over t ime, developed a l i b r a r y of subrout ines which perform common u s e f u l f u n c t i o n s , and most programming languages have adopted standard s e t of subroutines such as SIN, COS, e t c . The e x t e n s i o n of t h i s p r i n c i p l e t o the program l e v e l , r e s u l t s in the many u t i l i t y func t ions which are g e n e r a l l y a v a i l a b l e of ten at the system command l e v e l for copying, s o r t i n g , e d i t i n g , e t c . Taking advantage of these w e l l - d e f i n e d and t e s t e d c a p a b i l i t i e s not only s i m p l i f i e s the task of the system deve loper , but makes the developed system e a s i e r t o understand and maintain.

Turn-key systems are acquired in cases where the buyer does not have the c a p a b i l i t y t o produce the system himself or where he i s prevented from doing so by l e g a l or p o l i c y c o n s t r a i n t s . The former occurs primari ly in smal l organizat ions which up t o the present , have absorbed only a small part of the computer i n d u s t r y ' s products . This w i l l probably be r e l a t i v e l y unimportant for the software industry s i n c e the turn-key systems are l i k e l y t o make maximum use of firmware. The l a t t e r occurs in some government departments and in some i n d u s t r i e s under governmnet regu la tory c o n t r o l . These s i t u a t i o n s are a l s o l i k e l y t o remain r e l a t i v e l y unimportant. The second s i t u a t i o n a r i s e s when the c o s t of a turn-key system i s so c l e a r l y l e s s than that of a custom b u i l t system that the buyer has no c h o i c e . This requires that the buyer know the r e l a t i v e c o s t s of both turn-key and custom made systems inc lud ing maintenance and other r e l a t e d c o s t s .

While software components a t a l l these l e v e l s can be made reusab le , the l e v e l with the most p o t e n t i a l for mass usage i s the "module" l e v e l . The term "module", a s def ined in 1 . 1 . 2 , i s a component of software that can be compiled separate ly but may conta in components which can a l s o be compiled s e p a r a t e l y .

5 .7 -3 E f f i o i e n o v . I t i s g e n e r a l l y accepted that modular systems are i n e f f i c i e n t because of the overhead involved i n l i n k i n g and c a l l i n g modules. Camp and Jensen (1976) have i n v e s t i g a t e d the system c o s t or overhead a s s o c i a t e d with software modularity. They conclude that the added c o s t i s r e l a t i v e l y smal l compared t o the s a v i n g s gained in software development and m a i n t a i n a b i l i t y . The overhead that c u r r e n t l y e x i s t s can probably be reduced in future systems by more e f f e c t i v e l i n k i n g and loading .

5 . 7 . t Parameter izat ion. A l l g e n e r a l i z e d approaches, even turn-key systems and those based on modules, require adaptat ion to an i n d i v i d u a l i n s t a l l a t i o n for three major reasons: hardware conf igurat ions are d i f f e r e n t and change over t ime, the ind iv idua l i n s t a l l a t i o n requirements d i f f e r , not a l l want a l l o p t i o n s , and the software i t s e l f i s changed t o c o r r e c t errors and improve performance. I t i s there fore d e s i r a b l e t o embed as few parameters in a module as p o s s i b l e .

The ear ly information process ing systems were s tand-alone a p p l i c a t i o n s with t h e i r own f i l e s . This r e s u l t e d in cons iderable dup l i ca t ion o f data , dupl i ca t ion of process ing opera t ions , and g r e a t d i f f i c u l t y i n maintaining the systems. For example, one major food process ing firm had t o rewrite i t s e n t i r e order entry , production c o n t r o l and d i s t r i b u t i o n software when a new product was introduced because the knowledge of the e x i s t i n g

- 205 -

product codes was embedded in the individual modules. Plauger (1976) describes the difficulties caused by lack of parameterization in the New York Times project.

5.8 Issues in. Generalized Software

The individual programmer should organize his programs so that he can reuse portions of his code without having to rewrite it. However, the components are usually not used by others since they are not documented well enough. If components are going to be reused they must be developed with this in mind. Provisions must be made for component definition and development, description, documentation, cataloging, maintenance and modification, and a system construction method that compiles and links the object code.

Since all this requires a substantial investment, the success of a developer of a system based on reusable modules depends on whether or not there is a sufficiently large market for the modules.

There are a number of different ways in which the subdivision into modules can be made. One of the most pervasive is on whether the function to be performed is dependent on the application or whether it is a data processing function which is independent of a particular application. An example of application independent functions is given in section 5.4

5.9 U s e Qf the. Software SuDjjari. System

The key problem in basing a system on the utilization of modules is specification of what each module should do. An approach which allows each software designer to design his own modules and add them to the library will not be successful. Three requirements are necessary. First, some set of criteria will have to be established for the specification of a module. The criteria will probably include several types of information; both structural and functional. Second, the modules will have to be adequately described, catalogued, and documented so that a prospective user will be able to locate those that might satisfy his needs. Third, the modules will have to be constructed according to some standards for both internal structure and external interfaces.

Generalized systems have had only limited success. If these methods are to be pursued, the reasons for the lack of success must be identified to determine whether they can be overcome or whether the evolution in other areas will change conditions so as to favor generalized systems.

The concepts of reusable modules and generalized software can be incorporated in the Software Support System. This may not immediately and/or completely overcome all the difficulties identified in section 5.7 and 5.8, but considerable improvement can be made. The use of a data base to record all system descriptions automatically enforces a standard definition of a module. Furthermore, the data base contains descriptive information about each module. This will simplify determining whether a module that accomodates a desired function already exists.

Each module will be stored in a data base together with its external description. When a new module is entered into a data base it will be examined

and its external description verified as being consistent with its internal operation. It would be possible also at this time to search for possible overlap with existing modules.

6. Summary and Consideration for Progress

6.1 Siimmary

The concern of this paper has been with surveying the state-of-the-art in software, examining the attempts that have been and are being made to improve software, analyzing the reasons why these attempts have not always been successful, and finally, synthesizing an approach which may overcome many of the reasons for the lack of success in the past. The objective is to propose methods to obtain the same degree of improvement in software as that which has been obtained in hardware. The hardware improvements in capability, reliability and reduction in cost have been achieved through research, separation of engineering and manufacturing functions and mass production. These same concepts can be applied to software, though currently not as readily.

The environment in which these techniques are most relevant is one in which a large amount of software must be produced and maintained over a long period of time during which the requirements and computing environment may change. A software system in such an environment is usually large with hundreds of modules and tens of thousands of lines of source statement. The software must be developed and maintained by staff whose membership is also changing. The software may exist in many versions each with many releases. The techniques are not necessarily appropriate for situations in which state-of-the-art software is produced by experts primarily for research purposes. In these situations software is not intended to be used for operational uses and does not have to be maintained. Cost and performance may not be as important as demonstrating feasibility.

6.1.1 Manor Components. Software can be provided to the user at a substantially lower cost, be more reliable and more adaptable as his environment changes, by an approach that consists of three components.

Coordinated software development tools ta provide assistance io. ine professional software developers. The assistance will be clerical, for enforcing conventions, and managerial. The clerical function will provide storage of the software components and preparation of hard copy documentation. The system will ensure that conventions are being followed, will provide for performing a check of various kinds on the software components. It will also provide managerial functions for keeping track of progress and for evaluating the impact of changes. The system itself, however, at this point does not produce software; the software is still produced manually but through the use of the computer as an automated information storage and retrieval system. More detailed specifications are given in section 3-

Increased use of the computer to reduce the amount of software which must be developed "manually". These techniques permit the computer to be used to reduce the manual work of actually generating the software and also support decision-making by all those involved with software. The techniques are described in section 4.

- 206 -

Increased use of existing software to reduce the amount c¡¿ new software that must be developed in a. given system. One of the most effective ways to reduce cost and time is to make use of software that already exists and has been fully debugged and tested. The techniques for accomplishing this are discussed in section 5.

In the past, individual approaches in most of these areas have been tried, but progress has been slow. The impediments to progress are not limited to technical problems, though these do exist. More serious are the management, economic, and political problems. Analysis of the various techniques indicates that many of these limitations can be overcome by an integrated approach rather than considering them to be mutually exclusive.

6.1.2 Implementation Objectives. The creation of comprehensive Software Support System should be based on the following concepts:

- An integrated, coordinated data base that contains all the relevant information about the software. The more complete the relevant information, the more the data base will be able to serve all the needs of various users of the system. A coordinated data base also eliminates the difficulties caused by incompatible interfaces.

- The system should serve as much of the information needs of all the individuals concerned with systems. The more these needs are met, the more likely it is that the individuals will u s e the system and provide the necessary input data.

- The system should provide for continual evolution. It should be able to accommodate the software which already exists and which must be maintained. It should also be able to provide for future transition to other environments. This includes both hardware and hard software such as operating systems and data base management systems.

- The system should have a consistent approach t o languages. This will make the entire system easier to understand and reduce the time required to learn to use the system. It will also reduce the cost of implementing the system and extending the functions it provides.

- The system should provide consistent interfaces among the various functions that it provides. The reports should have standards formats so that the contents of one report may be used as the input to another.

6.1.3 Potential Benefits.

A Software Support System with the capabilities outlined above has the potential to provide the same improvements for software as has been obtained in hardware. These will become particularly evident over time as a data base of reusable modules is built up and as the techniques to generate software from a higher level specifications are gradually refined.

In time, the quality of the software produced should be so superior that production software produced by these methods will replace software developed by traditional methods. This is exactly the way that commercially produced data base management systems have completely replaced

individually developed data base management systems.

6.2 Considerations for Progress

It is obvious that a development of a Software Support System with the capabilities described above is no small undertaking. The technical, operational and economic feasibility of such a system must be examined and the specific actions that are needed for such a system to become viable determined.

6.2.1 Technical Feasibility- The first requirement is the ability to maintain in a data base, all information about the software system to be developed. Data base management systems are in existence and have been used in cases such as PSA (Teichroew and Hershey, 1977) and REVS (Davis and Vick, 1976). The amount of information that has to be stored is less than that of many . applications in which these data base management systems are now being used. The performance requirements of such systems need to be determined, though again this is not expected to be any major difficulty. It must be recognized, however, that a Data Base Administrator function will be necessary in this application as it is in other applications using data base management systems.

One of the major requirements is to develop an integrated approach to the use of languages for specifying the input to the system, and for commanding it to perform the necessary operations. A consistent approach is necessary as there will be many different users and each requires a language that includes his own vocabulary. A large number of languages, however, become difficult to learn and difficult to maintain. A number of different forms of the languages have been discussed in section 3- It appears that natural languages will not be suitable since natural language processing is still too difficult. The more promising approach is the use of a relational language such as that used in PSL and RSL, supplemented by one or more levels of procedural programming languages. This approach has the advantage that the terms in the language can be selected so as to be natural to the user. The approach of the specifying objects and their relations is easy to follow and applies to most of the areas which the system is to be used. It will of course be necessary for the data base administrator to insure consistency in the naming of objects and relationships. Thus, interrelationships among objects specified by different users can be maintained. The basic relational language can be supplemented by forms, tables, graphical language, etc. as desirable.

It will be desirable to evaluate these languages further to improve their ease of understanding, power of communication, and human engineering.

One of the major advantages of the Software Support System will be the ability to generate executable systems for different computing environments. The techniques available for this have been discussed in section 4 . Many of these techniques require further evaluation; however, with the basic approach of the data base and the languages mentioned above, these can be incorporated as they are being developed and proved. The desirability of developing systems that operate in different computing environments can be improved by the techniques which were

- 207 -

i d e n t i f i e d i n s e c t i o n 5 .

A number of current l i m i t a t i o n s in progress i n reus ing software are i d e n t i f i e d in s e c t i o n 5 . The Software Support System requ ires , and i m p l i e s , that a l l software components can be named. This i s the f i r s t s t ep in being able t o i d e n t i f y and reuse software . The system encourages d e s c r i p t i o n s that w i l l be he lpfu l in reusing the software. Never the l e s s , add i t iona l d i s c i p l i n e w i l l have t o be provided by management t o ensure that the adequate descr ip t ion e x i s t s for the i d e n t i f i c a t i o n o f the p o t e n t i a l l y reusable software components.

6 . 2 . 2 Operational F e a s i b i l i t y . Even i f a Software Support System i s b u i l t there remains the quest ion of whether i t would in f a c t be used. Clear ly , such a system i s f i r s t and foremost a management t o o l . I t s bas ic o b j e c t i v e i s t o reduce the c o s t and improve the qua l i ty of software from the point of view of the organizat ion that i s producing i t . Therefore, i t i s a b s o l u t e l y e s s e n t i a l that the approach has f u l l management understanding and support.

However, the major users of the systems w i l l be the p r o f e s s i o n a l s : Systems Analys ts , System A r c h i t e c t s , Software Des igners , Data Base Des igners , Programmers, Quality Assurers , e t c . These i n d i v i d u a l s w i l l use i t i f i t provides funct ions that they recognize are important, which management recognizes as important, and which the system performs more e f f e c t i v e l y than i f they were done manually. This impl ies that in the des ign of the system considerable a t t e n t i o n must be g iven t o each one of the funct ions i f the system i s t o be cos t e f f e c t i v e .

The use of the system w i l l a l so depend t o a good extent on i t s ease of use and hence, cons iderable a t t e n t i o n must be paid t o making the system as simple t o use and as r e l i a b l e as p o s s i b l e .

Further research and development i s required i n t o what funct ions should be accomplished and how they can bes t be performed in the system. On the b a s i s of experience gained with the prototypes , such as PSA (which at present provides only a part o f the funct ions of a f u l l Software Support System) i t i s evident that i t i s p o s s i b l e t o design a system that such p r o f e s s i o n a l s w i l l use .

6 . 2 . 3 Economic F e a s i b i l i t y . The System c l e a r l y requires s u b s t a n t i a l investment and the i n i t i a l problem i s t o obtain the necessary re sources . One approach i s t o build the system software in phases. Thus, b e n e f i t s are obtained from the beginning and s ince the system i s open ended, compatible components can be added as they become a v a i l a b l e .

Even i f i t i s a v a i l a b l e , can such a system compete with present manual methods? There are c l e a r l y c o s t s a s soc ia t ed with the use of such a system which inc ludes t r a i n i n g , software, maintenance, documentation, e t c . These c o s t s are a l l h i g h l y v i s i b l e . The b e n e f i t s , on the other hand, i n a par t i cu lar appl i ca t ion in a par t i cu lar i n s t a l l a t i o n , are l i k e l y not t o be as v i s i b l e . They w i l l be hard to measure, and take e f f e c t only over a period of t ime. However, i t can be argued t h a t , in genera l , the out-of -pocket d i r e c t c o s t s of producing systems with such a f a c i l i t y should be no more' than the present d i r e c t c o s t s i f they were completely measured.

6 .3 Conclusion

For an organizat ion that i s cont inuously developing and maintaining software, the use of a Software Support System should r e s u l t in s u b s t a n t i a l l y lower c o s t s and b e t t e r o v e r a l l q u a l i t y . As t h i s use becomes completely dominant, the bene f i t of reusing systems and being able t o generate systems with l e s s and l e s s manual in tervent ion w i l l become more e v i d e n t . I f these design o b j e c t i v e s are s u c c e s s f u l , the system should eventua l ly become ind i spensab le .

References

Alford, M., "A requirements engineer ing methodology for r e a l - t i m e process ing requirements", IEEE Transact ions of Software Engineering. February 1977.

Baker, F.T. "Chief Programmer Team Management of Production Programming", IBM Systems Journal , Volume 11, No. 1, 1972.

Beck, L . L . , "Automatic Design of Structured Data Process ing Systems" Proceedings r 1976 SIGMOD Internat iona l Conference on

Management ¡¡t pata, pp. 1 7 9 - 1 8 8 .

Beck, L . L . , Automatic P e s j m . a £ Structured. Process ing Systems Ph.D. D i s s e r t a t i o n , Department of Computer S c i e n c e , Southern Methodist U n i v e r s i t y , December 1975.

Belady, L. A. , Lehman, M. M., "The Evolut ion Dynamics of Large Programs," IBM Research Report, RC5615, September 9 , 1971

Belady, L. A. , Lehman, M. M., "A model of large program development," IBM Systems Journal . Vol. 15 No. 3 , 1976

B e l l , T . E . , D.C. B i x l e r , and M.E. Dyer, "An extendable approach t o computer-aided software requirements eng ineer ing" , IEEE Transactions Q& Software Engineering,, February 1977.

Be izer , Jack(ed) , Holzman, Albert G . ( e d ) , Kent, A l l e n ( e d ) , Encyclopedia M Computer Science and Technology r New York, NY, Marcel Dekker, 1975

Benjamin, Robert I . , "A Generational Perspec t ive of Information System Development," Coma of the ACM, Vol . 15 No. 7, pp. 640-643 , July 1972

B l o s s e r , Patrick Alan, An Automatic System for A p p l i c a t i o n S o f t w a r e g e n e r a t i o n ana. P o r t a b i l i t y , Ph.D. D i s s e r t a t i o n , August 1976, Purdue U n i v e r s i t y .

Boehm, B.W., J.R. Brown, H. Kaspar, M. Lipow, G.J. MacLeod, M.J. Merrl t t C h a r a c t e r i s t i c s of S o f t w a r e Qua l i ty . TRW Systems Group, Report No. 25201, 6001-RO-OO, December 28 , 1973.

Eoehm, B. W. , "Software Engineering", I E E E . Transactions on Computers, Vol . C-25, No. 12, December 1976. pp. 1226-1241.

Braden, Robert, "The National Software Works P r o j e c t , " Proceedings . ¿ H A B E . XLJLL1, Ses s ion C103, Montreal, August 15-20 , 1976

- 208 -

Brooks, Frederick P. , lüg. Mythical Man Month. Essavs on Software Engineering. Addison-Wesley, 1975, 195 pp.

Brown, H.M., "Clear-Caster System," Software Engineering Techniques, NATO Science Committee Report, B r u s s e l s , Belguim, 53-60 (Oct. 1969) .

Camp, J.W., E.D. Jensen, "Cost of Modularity", Hughes Aircraf t Company, Fu l l er ton , CA, Manuscript, 1976, 18 pp.

Canning, Richard C , Appl icat ion Management System (AMS), EDP Analyzer. December 1974, p . 9 . Canning P u b l i c a t i o n s , 925 Anza Avenue, V i s t a , CA 92083.

Canning, Richard C , "Are We Doing Things Right? ," EDP Analyzer. Vol . 13 No. 6, June 1975,

Canning, Richard C , "Are We Doing the Right Thing?," EDP Analyzer, Vol. 13 No. 5 , May 1975,

Canning, Richard C , "Do We Have the Right Resources?," EDP Analyzer, Vol. 13 No. 7, July 1975,

Central Computer Agency of the C iv i l Service Dept. Impl ica t ions aL Using. Modular P m p - i - a m r H n c r , ISBN 0-11-630361-1 . 1973. 148 pp. Her Majesty 's Stat ionary Of f i ce , London.

Central Computer Agency, Guide #6 , "Decision Tables ." Evaluation of Programming and Systems Techniques. London: Her Majesty's S ta t ionery O f f i c e , 1974, ISBN011 6303662 92 pp.

Cheatham J r , T. E . , Wegbreit, B . , "A Laboratory for the Study of Automating Programming," Proceedings of AFIPS FJCC 1Q72, Vol. 40, pp. 11-21

Chvalovsky, V. "Problems with Decis ion Tables ," Comm. of the ACM, December 1976, Vol. 19, No. 12, p. 705

Computer Weekly. "Hewlett-Packard e n l i s t s the marketing a id of Hoskyns," July 15, 1975

Couger, J . D . ( e d ) , Knapp, R. W.(ed), Sj£s£em. Analys i s Techniques, John Wiley & Sons, 1974

Couger, J. D . , "Evolution of Business System Analys is Techniques," Computing Surveys, Vol. 5 No. 3 , September 1973

Crafford, J . C , R.W. Curry, and R.A. DeCarli, "Integrated Test Bed Support Software System Study, Phase I I , " Prepared for U.S. Army Computer Systems Command, 5 November 1976

Curry, R.W., "A Measure to Support Cal ibrat ion and Balancing of the Ef fec t iveness of Software Engineering Tools and Techniques," Sc ience Appl i ca t ions . Inc.. , 25 March 1976, Manuscript

Davis , CG. and CR. Vick, "The Software Development System," Proceedings, 2nd Internat iona l Conference on Software Engineering, 13-15 October 1976, San Francisco , IEEE No. 76CH1125-4C.

Datapro, Directory of Software, Datapro Research Corporation, New Jersey

Denning, Peter J . , "Third Generation Computer Systems," Computing Surveys, Vol . 3 No. 4 , December 1971

DeRemer, Frank, Hans Kron, "Programming-in-the large versus Programming-in the small" 1 s t Conference on Re l iab l e Software. Sjgplan N o t i c e s , May/June 1975.

D i j k s t r a , E.W., "A cons truct ive approach t o the problem of program c o r r e c t n e s s , BIT, August, 1968.

D o l o t t a , T. A. , Berns te in , M. T . , Dickson J r , R. S . , France, N. A . , Rosenblat t , B. A . , Smith, D. M., S t e e l Jr , T. B . , Data Process ing in 1980-1985: A Study of Potential Limitations ia Progress , New York, NY, Wiley I n t e r s c i e n c e , 1976

Donovan, John J . , "Database System Approach t o Management Decis ion Support," MIT Center l o r Information Systems Research, Report COSR-25, Sloan WP-868-76

F a l l a , M.E., Pearce, D . J . , P i e r c e , R.H. "The Gamma Design and Programming System", pp. 89-107 in Software Systems Engineering, Proceedings of the European Computing Conference on Software Systems Engineering, London, September 1976, On- l ine , Uxbridge, England.

Feldman, J . , "Automatic Programming", Stanford Univers i ty Report CS-255, February 1972.

Gardner, R., E s t r i n , G., Potash, H. , "A Struc tura l Modeling Language for Archi tecture o f Computer Systems," In ternat iona l Symposium on Methodologies for the Design and Construction of Software and Hardware Systems, Rio de Janeiro , B r a z i l , June 28-July 2 , 1976

Gibson, Cyrus F . , Nolan, Richard L . , "Managing the four s t a g e s of EDP growth," Harvard Business Review, pp. 76 -88 , January-February 1974

G i l b , T . , Software Metr ics . S t u d e n t l i t t e r a t u r , 1976, 282 pp.

Ginsberg, A . S . , Markowitz, H.M. and Oldfather , P.M., "Programming by Quest ionnaire ," RM-4460-RR, RAND CORP., Santa Monica, Ca l i f . 1965

Hamilton, M., Ze ld in , S . , "Integrated Software Development System/Higher Order Software Conceptual Descr ip t ion ," Version 1, Research and Development Technical Report, ECOM-76-0329-F, November 1976, ECOM, Fort Monmouth, NJ.

Hammer, M. M., Howe, W. Gerry, Wladawsky, I r v i n g , "An I n t e r a c t i v e Business D e f i n i t i o n System," Proceedings of the Symposium on Very High Level Languages, SIGPLAN N o t i c e s , Vol. 9 No. 4 , April 1974

- 209 -

Hartman, W. H., Proeme, A. , Management Information Systems Handbook, McGraw-Hill, 1968

Harvey, F. L . , "The Developing Software Industry ," Infosvstems, July 1976

Heidorn, G. E . , "Automatic Programming Through natural Language Dialogue: A Survey," IBM. Journal of Research and Development, Vol . 20 No. 4, pp. 302-313, July 1976

Heiker, Vince, "Small Shops Need Help, Too," Infosvstems, July 1976

Henderson, P . , Snowdon, R. A. , "A Tool for Structured Program Development," IFIP 74, pp. 204-207, August 1974

Hice, G. F . , Turner, W. S . , Cashwell, L. F . , System Development Methodology, New York, NY, American E l s e v i e r , 1974

Hofnagle, G.F. , M.L. Wilson, "The Kernel System of the Information Automat," IBM, 1800 Frederick Pike, Gaithersburg, MD 20760, A p r i l , 1976

Hunter, John J . , "The Packaged Software Explosion," Infosvstems, July 1976

IBM, IMS. Application Development F a c i l i t y , General Information Manual, GB21-9869-0, Program Number: 5796-PHX, January 1977.

ICP, ICP Quarterly, International Computer Programs, Inc. Indianapolis , Indiana

I r v i n e , C. A. , Brackett , J . W., "Automated Software Engineering Through Structured Data Management," Second Internat ional Conference an. Software Engineering, San Francisco, October 13-15, 1976

ISI Research S t a f f , "A Research Program in Computer Tecnology, Annual Technical Report, July 1975-June 1976," USC Information Sciences I n s t i t u t e , Marina del Rey, C a l i f o r n i a , ISI/SR-76-6

JSD, "An Outline of the Programming Product iv i ty Development System, (PPDS)." Joint System Development Corporation, Tokyo, December 1976.

de Jong, S . P . , "System Building System (SBS) Build 4 Users Manual," IBM Research Report RC4485, Yorktown Heights, NY (August 1973).

Kernighan, B.W. and Plauger, P . J . , Software Tools , Addison-Wesley Publishing Company, Inc. 1976.

Knuth, Donald E . , "The Semantics of Context Free Languages," Mathematical Systems Theory. Volume I I , No. 2, 1968

Konsynski, Benn R., A Model of Computer-Aided D e f i n i t i o n and. Analysis o£ Information System Requirements , Ph.D. D i s s e r t a t i o n , Purdue Universi ty , December 1976.

L e a v i t t , Don, "Center to Aid Sharing of Federal Software." Computer World, 1976

Lee, R.C.T. , Chang, S.K. , and Waldinger, R . J . , "An Improved Program-Synthesizing Algorithm and I t s correctness" , £omm.. of the ACM, April 1974, pp. 211-217.

Lehman, M. M., "The Programming Process ," IBM Research Report, RC2722, December 5 , 1969

Liskov, Barbara H., Z i l l e s , Stephen N., "Programming with Abstract Data Types," Proceedings of the Symposium on Very High Level Languages, SIGPLAN Notices , Vol . 9 No. 4, Apri l 1974

Liskov, Barbara H., Z i l l e s , Stephen N., "Spec i f icat ion Techniques for Data Abstractions, " IEEE. Transactions on Software Engineering. Vol . 1 No. 1, pp. 7-19 , March 1975

L i s t , Eernard, "DAIS: A Major Crossroad in the Development of Avionic Systems," Astronautics &. Aeronautics, January 1973

Low, David W., "Programming by Questionnaire: An E f f e c t i v e Way To Use Decision T a b l e s , " Comm. of the ACM,. Vol . 16 No. 5, pp. 282-286, May 1973

Lucena, Carlos J . , Cowan, Donald D., "Toward a System's Environment for Computer Assisted Programming," Department of Applied Analysis 1 Computer Science, University of Waterloo. Waterloo, Ontario, Canada, CS-76-06

Lufkin, J.M., "Not Invented Here", I E M Transactions QB. Engineering Management. Volume EM-18, no. 4, November 1971.

Machrov, N.V., Modin, A.A. , Iakovienko, E.G., "Development parameters of contemporary computer-aided management systems in e n t e r p r i s e s . " ("Paramietry razrabotki sovriemiennych avtomatizirovannych sistem upravl ienia p r i e d i p r i a t i a m i " , ) I z d a t i e l s t v o "Nauka"• Moskva 1974.

Martin Marietta Data Systems, "Building Computer Systems - Overview," Martin Marietta Data Systems, Sales Brochure (1976)

Maynard, H.S. , "User Requirements for Data BAse Management Systems (DBMS)", Data Base Management Systems (Proc. 1973 SHARE Working Conference on Data Base Management Systems), pp. 129-45, New York: American E l s e v i e r , 1974.

Metzger, P h i l l i p W., Managing a Pi-oc;r«nim1nf!; Pro jec t , Prent ice-Hal l , Inc. New Jersey, 1973, 201 pp.

M i l l s , H.D., and M.L. Wilson, "An Introduction to the Information Automat," IBM, 1800 Frederick Pike, Gaithersburg, MD 20760, May 7, 1976.

Myasnikov, V.A. "Computer-aided management today -Experiences, problems and prospects ." A r t i c l e written by the Head of the Eoard of Computer Technology and Management and Control Systems at the Union Committee for Science and Technology of the USSR Council of Ministers . EKO Economics and

- 210 -

PAGE

O r g a n i z a t i o n o f I n d u s t r i a l M a n u f a c t u r i n g -B i m o n t h l y o f t h e S i b e r i a n C h a p t e r o f t h e USSR A c a d e m y o f S c i e n c e s . (ASU s i e g o d n i a - o p i t . u r o k i , p e r s p e k t i v u -" E K O n o m i k a i O r g a n i z a d a P r o m y s h l i e n n o v o p r o i s v o d s t v a " . A k a d e m i a N a u k S S S R , S i b e r s k o i e O t d i e l i e n i e , I z d a t i e l s t v o " N a u k a , " - S i b e r s k o i e O t d i e l i e n i e , No 6 / 1 9 7 4 . )

N a f t a l y , S t a n l e y M . , C o h e n , M i c h a e l C , J o h n s o n , B r u c e G . , COBOL S u p p o r t P a c k a g e s . . . P r o g r a m m i n g M P r o d u c t i v i t y A i d s , New Y o r k , N Y , J o h n W i l e y & S o n s , 1 9 7 2 1 8 2 p p .

N a v a l E l e c t r o n i c s L a b o r a t o r y C e n t e r , " S y s t e m s D e s i g n L a b o r a t o r y P r e l i m i n a r y D e s i g n R e p o r t , " N a v a l E l e c t r o n i c s L a b o r a t o r y C e n t e r , S a n D i e g o , C a l i f o r n i a , NELC N 7 2 5 T N 3 1 4 5

N e w e l l , A . , P e r l i s , A . J . , S i m o n , H . A . , " C o m p u t e r S c i e n c e , " S c i e n c e , 1 5 7 , p p . 1 3 7 3 - 1 3 7 4 , 1 9 6 7

P e r r y , R . , " A p p l i c a t i o n D e v e l o p m e n t C y c l e P r o b l e m s " , P r e s e n t a t i o n t o G U I D E , M a y 2 1 , 1 9 7 5 , S e s s i o n F - 1 .

P e t e r s , L a w r e n c e J . , T r i p p , L e o n a r d L . , " D e s i g n R e p r e s e n t a t i o n S c h e m e s , " M R I S y m p o s i u m o n C o m p u t e r S o f t w a r e E n g i n e e r i n g . A p r i l 2 0 , 1 9 7 6

P e t e r s , L a w r e n c e J . , T r i p p , L e o n a r d L . , " I s S o f t w a r e D e s i g n " W i c k e d " ? , " D A T A M A T I O N , p p . 1 2 7 - 1 3 6 , May 1 9 7 6

P h i s t e r , M o n t g o m e r y , J r . , D a t a P r o c e s s i n g T e c h n o l o g y a n d E c o n o m i c s . S a n t a M o n i c a P u b l i s h i n g , 1 9 7 6 , 5 7 1 p p .

P l a u g e r , B i l l , "New Y o r k T i m e s R e v i s i t e d , " Y o u r d o n R e p o r t , V o l . 1 N o . 3, A p r i l 1 9 7 6 p p . 4 - 5 , Y o u r d o n I n c . New Y o r k .

P r a t t e n , G . D . , S n o w d o n , R . A . , "CADES - S u p p o r t f o r t h e D e v e l o p m e n t o f C o m p l e x S o f t w a r e , " p p . 1 0 9 - 1 2 4 i n S o f t w a r e S y s t e m s E n g i n e e r i n g , P r o c e e d i n g s o f t h e E u r o p e a n C o m p u t i n g C o n f e r e n c e o n S o f t w a r e S y s t e m s E n g i n e e r i n g , L o n d o n , S e p t e m b e r 1 9 7 6 , O n - l i n e , U x b r i d g e , E n g l a n d .

P r y w e s , N . " P r e p a r i n g f o r F u t u r e N e e d s . " C o m p u t e r . I E E E , J u n e 1 9 7 5 p . 7 0 - 7 2 .

P u t n a m , L . H . , "A G e n e r a l S o l u t i o n t o t h e S o f t w a r e S i z i n g a n d E s t i m a t i n g P r o b l e m , " L i f e C y c l e M a n a g e m e n t C o n f e r e n c e , A m e r i c a n I n s t i t u t e o f I n d u s t r i a l E n g i n e e r s , F e b r u a r y 1 9 7 7 , W a s h i n g t o n , D . C .

R a l s t o n , A n t h o n y ( e d ) , M e e k , C h e s t e r L . ( e d ) , E n c y c l o p e d i a o f C o m p u t e r S c i e n c e . New Y o r k , N Y , P e t r o c e l l i / C h a r t e r , 1976

R e i f e r , D . J . , A G l o s s a r y o f S o f t w a r e T o o l s a n d T e c h n i q u e s , T h e A e r o s p a c e C o r p o r a t i o n . M a n u s c r i p t 2 0 p . 1 9 7 5 a .

R e i f e r , D . J . , " I n t e r i m R e p o r t on t h e A i d s I n v e n t o r y P r o j e c t , " T h e A e r o s p a c e C o r p . . E l S e g u n d o , C a l i f o r n i a , S A M S O - T R - 7 5 - 1 8 4 , 1 9 7 5 b

R e i f e r , D . J . , T o w a r d S p e c i f y i n g S o f t w a r e P r o p e r t i e s , T h e A e r o s p a c e C o r p o r a t i o n . M a n u s c r i p t .

R h o d e s , J . " B e y o n d P r o g r a m m i n g : P r a c t i c a l S t e p s T o w a r d s t h e A u t o m a t o n o f DP S y s t e m C r e a t i o n . " (1972) I n S y s t e m A n a l y s i s T e c h n i q u e s , p p . 328-335. E d i t e d b y J . D a n i e l C o u g e r . New Y o r k : J o h n W i l e y & S o n s .

R i g o , J . T . , " C i t i b a n k ' s M i n i c o m p u t e r A p p r o a c h Seems t o Be W o r k i n g " , C o m p u t e r w o r l d J a n . 3, 1977, p . 1 7 .

R i n , N . A d a m , A u t o m a t i c G e n e r a t i o n o f B u s i n e s s D a t a P r o c e s s i n g P r o g r a m s F r o m a N o n - P r o c e d u r a l L a n g u a g e , P h . D . D i s s e r t a t i o n , U n i v e r s i t y o f P e n n s y l v a n i a , O c t o b e r 1 9 7 6 .

R o s e , C . W . , " D e s i g n S y s t e m s - A F i v e Y e a r V i e w " , I E E E C o m p . - C o n 76 C o n f e r e n c e . S a n F r a n c i s c o , 1 9 7 6 , p . 190-193

R u t h , J o h n C , " D A I S : T h e F i r s t S t e p , " NAECON ' 7 3 R e c o r d

S e i d m a n , H . A . , " C h a n g e s i n C o m p u t e r S e r v i c e s , " DATAMATION. p p . 4 0 - 4 2 , J u l y 1976

S i m o n , H e r b e r t , " T h e A r c h i t e c t u r e o f C o m p l e x i t y , " P r o c e e d i n g s . A m e r i c a n P h i l o s o p h i c a l S o c i e t y , D e c e m b e r 1962, p p . 467-482.

S m o o t , O l i v e r R . , " D e v e l o p m e n t o f a n I n t e r n a t i o n a l S y s t e m f o r L e g a l P r o t e c t i o n o f C o m p u t e r P r o g r a m s , " Comm. o f t h e ACM, V o l . 19 N o . 4, p p . 1 7 1 - 1 7 4 , A p r i l 1974

S t i l l m a n R o ñ a B . , L e o n g - H o n g , B e l k i s , " S o f t w a r e T e s t i n g f o r N e t w o r k S e r v i c e s , " N a t i o n a l B u r e a u o f S t a n d a r d s T e c h N o t e 874, J u l y 1975

T a k a s a k i , I . , E D P - I T ' s P r o d u c t i o n a n d A p p l i c a t i o n i n J a p a n , P r o c e e d i n g s T h i r d A n n u a l C o m p u t e r A p p l i c a t i o n s S y m p o s i u m , C h u k a l o n g k o m U n i v e r s i t y , B a n g k o k , T h a i l a n d , J u l y 1972.

T e i c h r o e w , D a n i e l , "A s u r v e y o f l a n g u a g e s f o r s t a t i n g r e q u i r e m e n t s f o r c o m p u t e r - b a s e d i n f o r m a t i o n s y s t e m s , " F a l l J o i n t C o m p u t e r C o n f e r e n c e , 1972, p p . 1 2 0 3 - 1 2 2 4 .

T e i c h r o e w , D a n i e l , " I m p r o v e m e n t s i n t h e S y s t e m L i f e C y c l e , " I n f o r m a t i o n P r o c e s s i n g 74 p p . 972,978, N o r t h - H o l l a n d P u b l i s h i n g C o m p a n y , 1974.

T e i c h r o e w , D a n i e l , E . A . H e r s h e y , I I I , " C o m p u t e r - A i d e d S t r u c t u r e d D o c u m e n t a t i o n a n d A n a l y s i s o f I n f o r m a t i o n P r o c e s s i n g S y s t e m R e q u i r e m e n t s " , SHARE JJJÍI1, A u g u s t 1976.

T e i c h r o e w , D a n i e l , E . A . H e r s h e y , I I I , " P S L / P S A : A C o m p u t e r - A i d e d T e c h n i q u e f o r S t r u c t u r e d D o c u m e n t a t i o n a n d A n a l y s i s o f I n f o r m a t i o n P r o c e s s i n g S y s t e m s , " I E E E T r a n s a c t i o n s o n S o f t w a r e E n g i n e e r i n g , V o l u m e S E - 3 , N o . 1, J a n u a r y 1977, p p . 4 1 - 4 8 .

- 211 -

Union Committee for Sc ience and Technology of the USSR Council of Minis ters - General methodological g u i d e l i n e s _£ox development of. computer-aided management systems i n e n t e r p r i s e s . (Gosudarstviennyj Comitiet S o v i e t s Ministrov SSSR po Naukie i Tiechnikie - O b s h c h i e o t r a s l i e v i j e rukovodiashchije materialy po sosdaniu avtomatizirovannych s i s tem upravl ien ia pr ied ipr ia t iami (ASUP)", Minsk 1972.)

U.S. Air Force information Processinft/Pata Automation Impl ica t ions ox Air. Force Command and Control Requirements in the 1980s (CCIP-85), Volume 1, H i g h l i g h t s , April 1972.

U.S. Air Force Support of Air Force Automatic Data Process ing Requirements Through £M 1980s t

Volume 1 SADPR-85 Report, L.G. Hanscom F i e l d , June 1974.

U.S. Navy, "Tactical D i g i t a l Systems Documentation Standards", Secnavinst 3 5 6 0 . 1 , August 8 , 1974.

Waidinger, R . J . , Constructing Programs Automatically Using Theorem Proving. Ph.D. D i s s e r t a t i o n , Carnegie-Mellon U n i v e r s i t y , 1969.

Walters, G., "Integrated Software Development Systems (GE/ISDS)" SIGPLAN Not i ce s 1977, p. 10b.

Wegbreit. B . , "The ECL Programming System," Proceedings of AFIPS FJCC 1971, Vol. 39, pp. 253-262

Wegner, P . , P r o g r a m m i n g Languages Information Structures and machine Organization. New York: McGraw-Hill, 1968.

Wegner, P . , "Research Paradigms in Computer Sc ience ," Manuscript, 1976.

Weiss, David M., Ina MUDD Report: A Case Study of Navv Software Development P r a c t i c e s , Naval Research Laboratory, Washington D.C. 20375, NRL Report 7909, May 2 1 , 1975.

Welsh, W. A. , "Engineered Design of EDP Systems," Proceedings Systems and. Procedures Assoc ia t ion , In ternat iona l Meeting, S t . Louis , Missouri , October 1968

Wilson, Max, "The Information Automat," Proceedings, SJäAfiE. X L U I , Ses s ion LI03, Montreal, August 15-20, 1976

Wiseman, T. "Beermaker Sues EDS for $115 Mi l l i on" , Computerworld, September 13, 1976. p . 1 .

Withington, Frederic G., "Five Generations of Computers." Harvard Business Review, pp. 99-108, July-August 1974

Wright, A.W., "User Experience with the Applicat ion Management System (AMS). Info 115., New York September 9 , 1975.

Young, J.W., and Kent, H., "Abstract Formulation of Data Process ing Problems," Journal of Indus tr ia l Engineering, November-December 1958, pp. 471-479. Reprinted in Ideas for Management In ternat iona l Systems-Procedures Assoc iat ion 1959.

Zloof, M.M., S. Peter de Jong, "The System for Business Automation (SBA): Programming Language" Comm. of the ASH. 1977

Appendix 1 Types of Tools Defined by Reifer (1975a)

1. Accuracy Study Processor 2 . Analyt i ca l Modeling 3. Analyzer 4 . Automated Test Generator 5. Automated V e r i f i c a t i o n

Systems 6 . Bootstrap Loader 7. Comparator 8 . Compiler 9. Compiler Bui lding System

10. Compiler Va l idat ion System 11. Compressor 12. Consistency Checker 13. Constants Auto Checker 14. Correctness Proofs 15. Cross-Assembler 16. Cross-Reference Program 17. Data Base Analyzer 18. Data D e f i n i t i o n Language 19. Data-Exception Handler 20. Decompiler ü1 . Design Language Processor 22 . Diagnostics/Debug Aids 23 . Driver 24. Dynamic Simulator 25. Editor 26. E n g i n e e r i n g / S c i e n t i f i c

Simulations 27. Environment Simulator 28. Emulation 29 . EQUATE Program 30. Extens ib le Language

Processor 31. Flowcharter 32. Generator 33. Hardware Monitors 34. I n s t r u c t i o n Simulator 35. I n s t r u c t i o n Trace 36. I n t e r f a c e Checker 37. In terpre ter 38. Interrupt Analyzer 39. Language Processors 40. Library 41 . Linkage Editor 42 . Linking Loader 43 . Loader 44. Logic/Equation Generator 45. Macroprocessor 46. MAP Program 47. Modular Programming 48. Overlay Program 49. Peripheral Simulator 50. Postprocessor 5 1 . Preprocessor 52. Process Construction 53. Production L ibrar i e s 54 . Program Flow Analyzer 55. Program Sequencer 56. Record Generator 57. Report Generator 58 . Requirements Language Processor 59. Requirements Tracer 60. Restructuring Program 61. Scoring Program 62. Simulator 63. SNAP Generator 64. Software Monitor 65. Standards

- 212 -

66. Standards Enforcer s i m p l i c i t y 67. Structure Analyzer 68. Structured Programming reduced amount of code AMS language 69. System Simulat ions f a c i l i t i e s e l i m i n a t e s a p p l i c a t i o n 70. Terminal Simulator programming 71. Test Analyzer 72. Test Beds standard system a r c h i t e c t u r e e l i m i n a t e s 73. Test Dr ivers , S c r i p t s , part of design phase

Data Generators 74. Test -Resu l t Processor documentation machine generated as 75. Text Editor development progresses 76. Timing Analyzer 77. TRACE Program problem r e s o l u t i o n s f a s t e r - debugging and 78. Translator t e s t i n g a ids 79. Units Consistency

Analys is Program O P E R A T I O N A L B E N E F I T S 80. U t i l i t i e s

r e l i a b i l i t y Appendix 2

User Report on the Applicat ion Management System, Wright (1975)

" A P P L I C A T I O N ££QQSM D I M E N S I O N S

L M S FMS TOTAL

PROGRAM/MODULES 527 474 1,001

SOURCE STATEMENTS EXECUTABLE 1 6 6 , 4 8 8 86,851 253,139

COMMENT/DOCUMENTATION 20,538 28,221 48,759

TOTAL 187,026 114,872 301,898

P R Q P U C T I V m A M L J L S I S .

L M S F M S T O T A L

ELAPSED TIME

MANDAYS EXPENDED

TOTAL SOURCE STATEMENTS

16 Mos

1,235 2,375 3 ,610

166,488 86,851 253,139

AVERAGE SOURCE STATEMENT PER MANDAY 151.4 48 .4 83.6

NOTE: MANDAYS ARE ADJUSTED FOR 40-HOUR WEEK AND 21 DAYS PER MANM0NTH

PEVEL0PMENT mEEHS.

REDUCED SKILLS LEVEL

s i m p l i c i t y of language - only 38 verbs

AMS verbs , access methods t o perform complex DP funct ions

standard "building block" arch i t ec ture t o guide personnel

tabular dec i s ion l o g i c e l iminates complex i m p l i c i t l o g i c

high l e v e l , automated, l o g i c a l debugging and t e s t i n g a ids

INCREASEP PRODUCTIVITY

mainta inab i l i t y

e x t e n d a b i l i t y

non-obsolescence"

Appendix 3 Applicat ion Generator Proposed by Do lo t ta (1975)

"The primary purpose of t h i s study i s t o point out those requirements of the end users t h a t imply s i g n i f i c a n t research or development e f f o r t s , rather than t o attempt t o present complete s o l u t i o n s t o meet such requirements. I t seems appropriate , however, t o o u t l i n e an example of the type of s o l u t i o n that could meet the rather severe s e t of requirements g iven above.

One can env i s ion an "appl i ca t ions genera tor ." This t o o l can be implemented in s e v e r a l d i f f e r e n t forms, each meant for a s p e c i f i c type of a p p l i c a t i o n ( e . g . , p a y r o l l ) , or for a c l a s s of a p p l i c a t i o n s . The developer and the a p p l i c a t i o n s generator would i n t e r a c t v i a a "menu" of a l t e r n a t i v e s e l e c t i o n s (pr imari ly m u l t i p l e c h o i c e , or t r u e - f a l s e ) on a t e l e v i s i o n - l i k e c o n s o l e . The generator would view each a p p l i c a t i o n as a h i e r a r c h i c a l l y organized s e t o f bu i ld ing b locks that are t o be t i e d together in a manner d i c t a t e d by the cho ices of fered by the generator and s e l e c t e d by the developer .

At the beginning of the i n t e r a c t i o n , the c h o i c e s of fered t o the developer would c o n s i s t of h i g h - l e v e l function or general i n t e n t a l t e r n a t i v e s . Further on in the development " s e s s i o n , " the of fered a l t e r n a t i v e s would be at more d e t a i l e d funct iona l l e v e l s , u n t i l input formats, output formats, data base requirements , e t c . , would be s p e c i f i e d at the most d e t a i l e d l e v e l . At every l e v e l , however, a l t e r n a t i v e s o f fered t o the developer by the generator would be l imi t ed t o those c o n s i s t e n t with the h i g h e r - l e v e l s e l e c t i o n s already made e a r l i e r in the " s e s s i o n . "

Such a generator cannot, of course , conta in a l l conceivable funct ions that w i l l (or might) be des i red . This introduces the requirement for always being able t o s e l e c t an a l t e r n a t i v e that i s "none of the above." In t h i s c a s e , the developer would wr i te a new module (or a hierarchy of new modules) t o f u l f i l l the new requirements . This would be done in a h i g h l y standardized and structured manner, so t h a t , once implemented and t e s t e d , the new funct ions would be au tomat i ca l l y added t o the a p p l i c a t i o n s generator and could then be s e l e c t e d by subsequent deve lopers .

- 213 -

At the completion o f the s p e c i f i c a t i o n proces s , the generator would bind together the modules of code (which could c o n s i s t of a combination of object modules, generated source modules, and i n t e r p r e t i v e modules) necessary t o perform the s p e c i f i e d f u n c t i o n s . This could (and almost always would) be fol lowed by an i n t e r a c t i v e checkout phase, where e i t h e r automat ica l ly generated or u s e r - s p e c i f i e d t e s t data would be run through the r e s u l t i n g a p p l i c a t i o n s system for v e r i f i c a t i o n by the developer and by the end user .

I t seems qu i t e f e a s i b l e t o develop such an app l i ca t ions generator for a s p e c i f i c type of app l i ca t ion , such as inventory contro l . Although t h i s could have a s i g n i f i c a n t impact on an industry-wide b a s i s , the e f f e c t on product iv i ty in any one g iven i n s t a l l a t i o n would not be revo lut ionary . I t i s a l s o conceivable that generators could be developed for broad s e t s of a p p l i c a t i o n s . A general-purpose generator for o n - l i n e t r a n s a c t i o n systems seems conceivable today, and the development of one such generator has been reported in the l i t e r a t u r e [Maynard 1974] . Given the expected requirements for t h i s type of a p p l i c a t i o n s , such a generator ' s impact on development produc t iv i ty could be s u b s t a n t i a l .

Assuming that such an approach i s p r a c t i c a l , i t i s easy to see how the o b j e c t i v e s s ta ted above could be r e a l i z e d . For example, i f we look at the d i f f i c u l t i e s the end user encounters in t ry ing t o convey h i s requirements t o the system developer, we can see that t h i s approach would help by al lowing the end user and the developer t o work as a team in i n t e r a c t i n g with the generator; conceivably, i t could a l s o al low the end user t o in t erac t d i r e c t l y with the generator; the app l i ca t ions developer would then be needed only in s i t u a t i o n s where a new funct ion i s required.

One of the bas i c s t rengths of t h i s approach i s the prestruoturing of the app l i ca t ion that i s gained by the e x i s t e n c e of the generator and by the i n i t i a t i v e the generator r e t a i n s in i t s d ia log with the developer. One of the severe weaknesses the industry current ly s u f f e r s from i s that the r e s p o n s i b i l i t y for i n i t i a t i v e in app l i ca t ion s tructuring i s ves ted in the developer and i s , therefore , unique for e s s e n t i a l l y every occurrence of each a p p l i c a t i o n . This has defeated most previous e f f o r t s t o use standardized modules as bui lding blocks in new a p p l i c a t i o n s .

I t i s apparent that t h i s approach i s an extreme departure from current development techniques . I f i t i s , in f a c t , necessary t o make such a subs tant ia l departure from current methods (and we be l i eve that i t i s ) in order to so lve the programmer produc t iv i ty problem, then we cannot overemphasize the need for ex tens ive research and development e f f o r t s in t h i s area."

Appendix 4 Pr ices for Software Development, Martin Marietta

(1976)

"SYSTEMS AT $6 $4 $2 $1 PER PROGRAM STATEMENT

In-house programming c o s t s $6 to $10 per l i n e including t e s t i n g . We bui ld customer systems at $6 per l i n e : p r i c e , performance and de l ivery guaranteed. You don't save much money but you may save time and avoid schedule bot t l enecks . You do get f l e x i b i l i t y , acces s t o s p e c i a l i s t s k i l l s and assured r e s u l t s .

Working at your s i t e and in our o f f i c e s , we d e l i v e r programs at $4 per l i n e . We design robust systems: easy t o use , t e s t and modify. We pay a t t e n t i o n t o d e t a i l in coding, documenting and t e s t i n g . We provide a maintenance warranty.

Using o f f - t h e - s h e l f Modular Appl icat ion Systems (MAS) bui ld ing b r i c k s , the cost reduces to $2 per program statement , for a system to your exact s p e c i f i c a t i o n . In some r e s p e c t s , the q u a l i t y exceeds that of custom b u i l t systems: economy of s c a l e permitt ing unusual refinement. MAS, being b u i l t t o f l e x , adapts to changing company needs. So, over the years , the MAS approach can o f f e r a b e t t e r f i t that a custom b u i l t system, while avoiding code redundancy.

I f only standard MAS modules are used, the r e s u l t a n t system w i l l cost $1 per l i n e . You g e t a l l the b e n e f i t s of MAS: performance proven in over 500 implementations, provis ion for t o t a l i n t e g r a t i o n and honed down operating c o s t s . "

Appendix 5 Software Sharing in the U.S. Federal Government,

Computerworld (1976)

"The Federal Software Exchange Center (FSEC), intended to f o s t e r sharing of programs between federa l a g e n c i e s , i s now becoming operat ional under the General Serv ices Administration (GSA) Automated Data and Telecommunications S e r v i c e .

Outlined i n a Federal Property Management Regulation (FPMR 101-32.16) i ssued l a s t February, FSEC's s ta ted goal i s t o reduce ' o v e r a l l c o s t s , time and use of personnel resources for software a c q u i s i t i o n and/or development.'

The FPMR c a l l s for the pooling of information of 'common use software' by a l l federal agencies 'having [DP] f a c i l i t i e s , resources or requirements . '

Once gathered, t h i s information i s to be maintained in a c a t a l o g , published and updated quarter ly by the National Technical Information S e r v i c e .

Agencies w i l l be required to search through the l i s t i n g s of what i s ava i lab le from FSEC before they are al lowed to acquire any software from outs ide sources , according to Chris Bythewood, who has organized the operation at GSA.

Software covered by the exchange i s l i m i t e d to programs w r i t t e n by agency s t a f f s or by outs ide contractors working for agenc ies . E x p l i c i t l y excluded are programs that are c l a s s i f i e d , proprietary or 'developed with revolv ing funds' or software ' t o which the government does not possess the f u l l r i g h t s of ownership' , in the language of the FPMR.

Though developed with federal funding, programs in the FSEC w i l l be considered 'property' and therefore not in the public domain. Only federa l agenc ies w i l l have access to them, Bythewood s a i d , not ing however that the s t a t u s of the software i s current ly under l e g a l review.

Government 'property' cannot be given away ( to a nongovernment user , for example) without s p e c i f i c a u t h o r i z a t i o n , he explained. On the other hand, an agency ' g i v i n g away' a copy of a software rout ine s t i l l has the rout ine for i t s own use 'and hasn ' t

- 214 -

Develop Labor Hours Analyze Attendance Compute Payrol l Develop Purchased Material Costs Develop Service and Loading Rates Develop Labor Rates Develop Standard Costs Develop Pr ice Compute B i l l i n g Compute Recoveries Compute Disbursements Compute Actual Costs

SYSTEM CONTROL FUNCTIONS

Message Discr iminat ion and V a l i d a t i o n F i l e Update and Surve i l lance Report Data Compiler Data Serv ices

RESOURCE CONTROL FUNCTIONS

Forecast Requirements Determine Safe ty Requirements Determine Net Requirements Determine Economic Q u a n t i t i e s Aggregate Economic Planning Deta i l ed Economic Planning Determine Dispatch P r i o r i t y S e l e c t Vendor Determine Changes From Previous Plans Materiel Planning

H lAHUFACTURlNfi ENTERPRISE

FIGURE 1.1.1 EXAMPLE OF SYSTEM STRUCTURE

l o s t any r e a l property at a l l - which makes a very awkward s i t u a t i o n , l o g i c a l l y and l e g a l l y , " he s a i d .

While one part of the FPMR def ines what agenc ies must do t o support the creat ion and maintenance of the FSEC l i b r a r y , another paragraph o u t l i n e s the expected b e n e f i t s from use of the exchange and another s t a t e s what can happen i f agencies t r y t o bypass using the center a l t o g e t h e r . "

Appendix 6 Functions Defined by Welsh (1968)

ENGINEERING FUNCTIONS

Determine System Requirements Determine Logical Design Determine Phys ica l Design Determine Organizational Assignments Determine Procedures Es tab l i sh Time Values Determine Labor C l a s s i f i c a t i o n s Coordinate Design Introduction

ADMINISTRATION FUNCTIONS

Performance Determination Performance Evaluation Performance Project ion Dec i s ion Aids and Simulation Personnel

- 215 -

X3-

A

PROGRAM

X3

PROGRAMMING

PRODUCT

( G E N E R A L I Z A T I O N .

T E S T I N G .

D O C U M E N T A T I O N ,

M A I N T E N A N C E )

PROGRAMMING

SYSTEM

( I N T E R F A C E S , S Y S T E M

I N T E G R A T I O N )

PROGRAMMING

SYSTEMS

PRODUCT

M A N P O W E R

G R O W T H

^ T I V I -

riES

1 A J O R

aocu-1 E N T

I I L E -

5 T O N E S

3 E F I N I T I O N

P H A S E

D E S I G N

P H A S E

P R O G R A M M I N G

P H A S E

S Y S T E M T E S T

P H A S E

A C C E P ­

T A N C E

P H A S E

I N S T A L ­

L A T I O N

& O P E R A ­

T I O N

P H A S E

I B A S E L I N E D E S I G N

D E T A I L E D D E S I G N I

C O D E . U N I T T E S T

D O C U M E N T

I N T E G R A T I O N T E S T

P R E P A R A T I O N

I N T E G R A T I O N

T E S T

S Y S T E M T E S T

P R E P A R A T I O N S Y S T E M T E S T

A C C E P T A N C E T E S T P R E P A R A T I O N D E M O N '

S T R A T I O N

T R A I N I N G C U S T O M E R I N S T A L L

& T E S T

P R O J E C T

P L A N

P R O B L E M

S P E C I F I ­

C A T I O N ^

D E S I G N

S P E C I F I ­

C A T I O N

P R O G R A M ­

M E R ' S H A N D ­

B O O K

P R E L I M I N A R Y

A C C E P T A N C E

T E S T S P E C I ­

F I C A T I O N

INTE­GRATION TEST SPECI-FICATIONl

P R E L I M ­

I N A R Y P R O ­

G R A M D O C U ­

M E N T A T I O N

F I N A L A C ­

C E P T A N C E

T E S T 8 S I T E

T E S T S P E C ­

I F I C A T I O N S

A C C E P ­

T A N C E

A G R E E ­

M E N T

F I N A L

P R O G R A M

D O C U M E N -

T A T I O N

-TIME-

FlGUREl .1.2 E V O L U T I O N O F T H E P R O G R A M M I N G S Y S T E M S P R O D U C T

B R O O K S , F. P . , " T H E M Y T H I C A L M A N M O N T H , " E S S A Y S O N S O F T W A R E

E N G I N E E R I N G - A D D I S O N - W E S L E Y , 1 9 / 5 , 195 pp.

FIGURE 1 . 3 . 1 T H E P R O G R A M D E V E L O P M E N T C Y C L E

M E T Z G E R , P H I L L I P W., MANAGING A PROGRAMMING PROJECT, P R E N T I C - H A L L , I N C . , NEW J E R S E Y , 1973 , 2 0 1 pp.

GENERAL UTILITY

P O I T A I I U I Y u u A M u r r

/ \/ \

D E V K E -I N -DtfENDENCI

COMPIETE-NESS ACCURACY

! Í 1

HUMAN-ENGINEERING

ACC Í SSI -IIUTY

MAINTAINABILITY

MODIFIAMUTY

Ü AUGMENT-

AIIUIY

F I G U R E 1 , 1 , 1 S O F T W A R E C H A R A C T E R I S T I C S T R E E

B O E H M , B. W., J , R, B R O W N , H K A S P A R , M. Lipow, G. J , M A C L E O D ,

M, J . M E R R I T T , " C H A R A C T E R I S T I C S O F S O F T W A R E Q U A L I T Y , " TRW

S Y S T E M S G R O U P , R E P O R T NO . 2 5 2 0 1 , 6001-R0-0Q, D E C E M B E R 2 8 , 1973 ,

- 216 -

WORKS MANAGER

USER COMMAND

L A N G U A G E

I N T E R F A C E

FIGURE 2 . 3 . 1 NATIONAL SOFTWARE WORKS B R A D E N , R . , " T H E N A T I O N A L S O F T W A R E WORKS P R O J E C T , " P R O C E E D I N G S . SHARF

Mil. S E S S I O N C113. I O N T R E A L , A U G U S T 1 5 - 2 0 , 1976.

L A N G U A G E T R A N S -

L A T I O N F A C I L I T I E S

' J O V I A L / H B C C O M P I L E R

' J O V I A L / D E C - 1 0 C O M ­

P I L E R

' H B C A S S E M B L E R

D E C - 1 0 A S S E M B L E R

A E D C O M P I L E R

F O R T R A N C O M P I L E R

M I C R O - C O D E T R A N S ­

L A T O R

DEC - 1 0 OPERATING SYSTEM

S D V S C O N T R O L

: I L E M A N A G E M E N T

F A C I L I T I E S

D A T A B A S E M A N ­

A G E M E N T

- S O U R C E C O D E

- O B J E C T C O D E

- T E S T D A T A

- S C E N A R I O

' L I B R A R Y M A N ­

A G E M E N T

C O N F I G U R A T I O N

M A N A G E M E N T

S T A T U S A C ­

C O U N T I N G

V E R S I O N

C O N T R O L

C H A N G E C O N ­

T R O L

P I M U L A T I O N

A C I L I T I E S

- • - U S E R I N T E R F A C E

J N T E R P E R A -

T I V E C O M ­

P U T E R S I M ­

U L A T I O N

' S T A T E M E N T

L E V E L S I M ­

U L A T I O N

' D A T A B U S

S I M U L A T I O N

' S E N S O R S I M ­

U L A T I O N

' E N V I R O N M E N T

S I M U L A T I O N

' M S F U N C T I O N

S I M U L A T I O N

LOAD MODULE P R E P A R A -

T I O N F A C I L I T I E S

L I N K A G E E D I T O R

L O A D E R

M S P A R T I T I O N I N G

S U P P O R T .

- B U S T R A F F I C

A N A L Y S I S

- R E A L T I M E U S A G E

- C O R E A L L O C A T I O N

I A N M A C H I N E I N T E R -

F A C E F A C I L I T I E S

S D V S C O N T R O L L A N ­

G U A G E P R O C E S S O R

' S I M U L A T I O N C O N T R O L /

S E Q U E N C I N G

' O U T P U T P R E P A R A T I O N

- R E P O R T S

- P L O T S

- S T A T U S

FIGURE 2 . 1 . 1 11A1S SOFTWARF HESIfiN t VERIFICATION SYSTFM (SOTS) R U T H, J. C.."DAIS¡ THE F I R S T S T E P," äflECQä. ' 7 3 , R E C O R D .

T E S T I N G Î

V A L I D A T I O N

T O O L S

T E S T R E S U L T S

T E S T S T A T U :

S Y S T E M

A N A L Y Z E R

I N T E R F A C E

A U D I T O R

R E P O R T

G E N E R A T O R

FIGURE 2 . 1 . 2 SEF: P R O C E S S O R V I E W

I R V I N E , C. A . , A N D J . W. B R A C K E T T , " A U T O M A T E D S O F T W A R E E N G I N E E R I N G

T H R O U G H S T R U C T U R E D DATA M A N A G E M E N T , " S E C O N D

I N T E R N A T I O N A L C O N F E R E N C E O N S O F T W A R E E N G I N E E R I N G ,

SON F R A N C I S C O . O C T O B E R 1 3 - 1 5 , 1976.

- 217 -

DATA DESC

DATA DICTIONARY GENERATOR

SOURCE DBL DPL

-DOC AUS COMPILER

CONTROL

-DOC AMS CONFIRURATOR

CONTROL

-DOC AMS MONITOR

—DOC

DATA D ICT­IONARY

DPD DPL RCI

FIGURE 2 . 5 . 1 APPLICATION MANAGEMENT SYSTEM (AMS) WRIGHT. A . W. . "USER EXPERIENCE WITH THE APPLICATION MANAGEMENT SYSTEM (AMS)

INFO ' 7 5 . NEW YORK. SEPTEMBER 9 . 1 9 7 5 .

APPLICA­TION DATA

IJSASE^,

IA KERNEL SYSTEM

I . BASIC USER FUNCTIONS

BASIC USER SERVICES CONCEPT DEFINITION S MODELING USER INSTRUCTION t INTERROGRATION

I I . DATA STRUCTURE OPERATIONS

BASIC DATA STRUCTURE OPERATIONS DIRECT DATA ENTRY DOCUMENT/GRAPHICS PROCESSING DATA MIGRATION

I I I . PROCEDURE OPERATIONS

INTERACTIVE PROBLEM SOLVING BASIC PROCEDURE OPERATIONS LANGUAGE PROCESSING SERVICES PROCEDURE TESTING PROCEDURE MIGRATION

I V . SYSTEM MANAGEMENT FUNCTIONS SYSTEM ADMINISTRATION CONTROL PROGRAM SERVICES

103

TSO. J C L . SPF. IMS/DC. CRJE, I Q F . REL, GPSS. COURSEWRITER, ETC.

DBDA. IMS. G I S . V I D E O / 3 7 0 , RPG, ATMS, STAIRS, ETC.

BASIC, APL , ALC. FORTRAN, COBOL, P L / 1 , PLAN, VDL, XPL, TESTRAN, CLEAR, ETC.

SMF, RSS, J C L , OS/VS, RTOS, C I C S , ETC.

FIGURE 2 , 6 , 1 COMPARABLE FACILITIES IN THE KERNEL SYSTEM AND TODAY'S SYSTEMS

WILSON, M. , "THE INFORMATION AUTOMAT," PROCEEDINGS, SHARE X L V I I , SESSION L 1 0 3 , MONTREAL, AUGUST 1 5 - 2 9 , 1 9 7 6 .

MANAGEMENT

INFORMATION PROCESSING PERSONNEL

SOFTWARE PERSONNEL

TARGET SYSTEM USERS

COMMANDS

DATA

INPUT ANALYSIS

"FUNCTIONAL" OPERATION

OUTPUT PREPAR­

ATION

REPORTS

DATA BASE ACCESS

MESSAGES

DATA BASE MANAGEMENT SYSTEM

FIGURE 3 . 2 . 1 SOFTWARE SUPPORT SYSTEM

- 2 1 8 -

A R G S O F C A L L

A R G S

ARGOT

TARSYsf WRITER

CALLED Y c C H S Y S

/ NT RESFOR s~~\r WRITER ^^-s

i W R I T B Y T RESOF

^ — I , A L L R E C O R D T Y P E S $ < - L R E C O R D T Y P E S A L L R E C O R D T Y ° E S

• ( E X C E P T N U B S . A R G M T , ( E X C E P T N U B S , ( E X C E P T N U B S , A R G M T ,

T E X T , P E R S O N ) A R f i M T . T E Y T . " «

P A R T S P A R T O F

1 MODULE I—

A L L R E C O R D T Y P E S

( E X C E P T N U B S )

I i

A R G M T , T E X T ,

T A R G E T )

L I N K T O L I N K F R S M P T O C O M P F R

—"-(DH OBJECT H - ( 6 > H PROPRA" f

T E X T , T A R G E T )

P R G F L

T E X T S T

I TEXT ($) j OPRTlj I

t sunnpi)

FIGURE 3.3,1 DATA S T R U C T U R E O F S E L E C T E D SU B S Y S T E M O F SO F T W A R E SU P P O R T SY S T E M

SOFTWARE SUPPORT SYSTEM

REQUIREMENTS DETERMINATION

DEVELOPMENT SUPPORT MANAGEMENT DATA BASE

SOFTWARE ENGINEERING

SOFTWARE PRODUCTION

OPERATION FACILITY

INSTALLATION & MAINTENANCE

FIGURE 3.1.1 MA J O R SU B S Y S T E M O F SO F T W A R E SU P P O R T SY S T E M

- 219 -

PRODUCE INVOICE

CUSTOMER NAME:ALL GM CLASS .. ITEM a QUANT.

CUSTOMER NAME

ITEM * QUANT. I. COST AMOUNT

TOTAL DISCOUNT TOTAL DUE

ORDER 1 CUSTOMER NAME: ALL AB£ CLASS r ITEM » QUANT. 55 SUM.ALL 15

CONDITION CALCULATION CLASS DISCOUNT 7_ m

A lot B 5% C 0%

CUSTOMER NAME:ABC ¡ CALCULATION

ITEM # QUANT. I. COST AMOUNT 55 SUM.ALL 15 2 61-2XSUM.ALL 15

TOTAL SUM ALL 61 DISCOUNT SUM ALL (il x 3 i TOTAL DUE SUM ALL I.Í -

SUM ALL C] x 3 1

CONDITION CALCULATION CUST. RATING DISCOUNT

EJf - 5» » FAIR 4» GOOD 51

EXCELLENT et

ITEM MASTER ITEM # PRICE 55 2

CUST. MASTER j CUST RATING

ABC EX.

FIGURE 1 . 3 . 1 E X A M P L E O F SBA P R O G R A M S T O P R O D U C E AN I N V O I C E

Z L O O F , ,1. 1. A N D S. P E T E R D E J O N G . " T H E S Y S T E M F O R B U S I N E S S

A U T O M A T I O N (SBA): P R O G R A M M I N G L A N G U A G E . " C O M M U N I C A T I O N

O F T H E ACM. 1977 .

1 CONTROL CONTROL

DESTINATION

_J . 1 1

SEQUENCE OPERATION 1

CONDITION CALCULATION

E L E S L E S

E

SCHEDULE SEQUENCE ACTION CONDITION SEQUENCE

OPERATION OBJECT CONDITION

(INFORMATION) OPERATION CREATE DESTROY INITIALIZE INSERT DELETE UPDATE

(SEQUENCE)

CO TO END EXIT

X X X - c a n b e a n y p r o g r a m n a m e .

(INVOCATION)

SEND DESTINATION

(MANUAL) (TRIGGER) (DELAY) (RESIDUE)

FIGURE 1 . 3 . 2 SUMMARY O F SBA P R O G R A M M I N G L A N G U A G E

Z L O O F . M. M. A N D S. P E T E R . D E J O N G , " T H E S Y S T E M F O R B U S I N E S S A U T O M A T I O N (SBfi):, P R O G R A M M I N G L A N G U A G E ,

C O M M U N I C A T I O N O F T H E ACM, 1 9 / 7 .

- 220 -

SYSTEM DEVELOPMENT (CONVENTIONAL)

SYSTEM DEVELOPMENT HSL/1

FILE DESIGN AND

SPECIFICATION

PROGRAM DESIGN AND

SPECIFICATION

PROGRAM CODING

PROGRAM TESTING

ID ED DD FS

TABLEMASTER

RECORD LAYOUTS

PROCEDURE DIVISION

PROGRAM TESTING TESTMASTER

FIGURE 4.3.3 HOSKYNS SYSTEM LANGUAGE HSL/1 RHODES, J , , BEYOND PROGRAMMING: PRACTICAL STEPS TOWARDS THE AUTO­

MATION OF DP SYSTEM CREATION." (1972), SVSTFM AMIYBIS TF PP. 328-335. TFCHNIOUFS

SYNTHESIS APPROACH

FUNCTION SPECS

DEVELOP-SATISFIER LIBRARY

SYNTHESIZE SOLUTION

ASSEMBLE SYSTEM

CONFIGURATIONS

NEED

FIGURE 5.11.1 WELSH, W. A., "ENGINEERED DESIGN OF EDP SYSTEMS," PROCEEDINGS SYSTEMS

tun P u n r r n u R E S ASSOCIATION. INTERNATIONAL MEETING, "IISSOURI, UCTOBER 1968.

j CPL-A Language * Proceeeor | r »ppli Field

1 ieet 1 0 0 Id A

User

Applicatioi Field X

•

Application Field Y

F

P r o g r a m Module D a t a Base Control System

j CPl-B Language * TPO1S"|

o Syntax check

o Ptogram analysis

o Prograa optimization

o Interface check

a Program sioulation

o Performance analyaia

Cirapiler test and •.•valuation ri

O S 1 . I Compiler ^ L . . :

I I « 2 I I Compilar

- J L

I c k i a t i n g t I p r o g r a m a !

- C o n t r o l

Integrity

Retrieval

C o m p i l a t i o n

• Security

P r o g r a m m o d u l e

I Related M e t h o d o l o g i e s and Tools

o Interface atandarditation

o Document production

o Module test ar.d-evaluation

1 o Revision of m o d u l a r i z a - o P r o g r a m e s t i o a t i o n

o D e b u g g i n g function

o Programmaing support

o Project control

FIGURE 5,6.1 PROGRAMMING PRODUCTIVITY DEVELOPMENT SYSTEM (PPDS) IT SYSTEM DEVELOPMENT CORPORATION/ "AN OUTLINE OF THE PROGRAMMING PRODUCTIVITY DEVELOPMENT SYSTEM, (PROS), TOKYO, DECEMBER 19/6

- 221 -