Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

PROGRAM MODIFIABILITY

IP.com Disclosure Number: IPCOM000148837D
Original Publication Date: 1980-Mar-06
Included in the Prior Art Database: 2007-Mar-30

Publishing Venue

Software Patent Institute

Related People

Belady, L.A.: AUTHOR [+3]

Abstract

L . A. Belady and B. Leavenworth IBM T. J. CJatson Research Center Yorktown Heights, N.Y. 10598 ABSTRACT: The authors' e a r l i e r research concluded t h a t t h e major o b s t a c l e t o programmer p r o d u c t i v i t y and program q u a l i t y i s t h e r e s i s t a n c e t o change o f software. Too many progranlmers a r e t i e d down i n maintenance and enhancement; progratns becoir~e i n c r e a s i n g l y complex and i n t h i s endlezs m o d i f i c a t i o n process more and more e r r o r s a r e generated. For s e v e r a l years t h e encapsulation o f data in programs, in t h e form o f data a b s t r a c t i o n s , has been t h e focus o f worldwide research in programming technology. T h i s approach o f f e r s a d i s c i p l i n e d design methodology which i s s t r o n g l y t i e d t o implementation and t o t h e automatic generation o f documentation. The r e s u l t i n g program s t r u c t u r e i s easy t o understand and tends t o l o c a l i z e t h e impact o f a program change. However, t h e approach has n o t been t r i e d on a l a r g e i n d u s t r i a l scale.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 19% of the total text.

Page 1 of 14

RC 8147 (//35397) 3/6/80 Computer Science 19 pages

PROGRAM MODIFIABILITY

L . A. Belady and

B. Leavenworth

IBM T. J. CJatson Research Center

Yorktown Heights, N.Y. 10598

ABSTRACT: The authors' e a r l i e r research concluded t h a t t h e major o b s t a c l e t o programmer p r o d u c t i v i t y and program q u a l i t y i s t h e r e s i s t a n c e t o change o f software. Too many progranlmers a r e t i e d down i n maintenance and enhancement; progratns becoir~e i n c r e a s i n g l y complex and i n t h i s endlezs m o d i f i c a t i o n process more and more e r r o r s a r e generated.

For s e v e r a l years t h e encapsulation o f data in programs, in t h e form o f data a b s t r a c t i o n s , has been t h e focus o f worldwide research in programming technology. T h i s approach o f f e r s a d i s c i p l i n e d design methodology which i s s t r o n g l y t i e d t o implementation and t o t h e automatic generation o f documentation. The r e s u l t i n g program s t r u c t u r e i s easy t o understand and tends t o l o c a l i z e t h e impact o f a program change. However, t h e approach has n o t been t r i e d on a l a r g e i n d u s t r i a l scale.

The authors' p r o j e c t i n Yorktown has been developing t o o l s , e.g. a preprocessor t o PL/I, t o accommodate data a b s t r a c t i o n s . The same t o o l s a r e t h e n b e i n g used t o redesign p a r t s o f an e x i s t i n g program i n t h e 100K l i n e s o f code category in order t o t e s t t h e v i a b i l i t y , and a i d t h e refinement, o f t h e method and t h e associated t o o l s . E v a l u a t i o n o f m a i n t a i n a b i l i t y w i l l be done b y u s i n g two c o n t r o l groups o f programmers t o compare e f f o r t s necessary t o work w i t h t h e o l d v e r s i o n and w i t h t h e new version.

[This page contains 1 picture or other non-text object]

Page 2 of 14

PAGE 2

During the last decade a great deal has been written about
the unpredictabilitv of programming 1 2 It is indeed
difficult to forecast the cost and the schedule of a progratn
development project. The resulting product is also full of
surprises: it runs usually slower than expected and it
requires endless maintenance. Operation is continually
disrupted by errors which must be removed. Even without
errors, most programs must be adjusted to reflect changes in
hardware and in functional requirements. And the larger the
program, the larger the development and maintenance
organization, the greater the probl.em.

In spite of this apparent flux, programming methodologies in
the past considered programs as static artifacts. Work
concentrated on the development of correct programs w:;ich,
by assumption, presented no challenge beyond delivery to
users: after all, programs do not suffer physical wear as
hardware devices do. However, in Phe early 70'...