Embed Size (px)
Citation preview
UNIVERSITI PUTRA MALAYSIA
INTRODUCING CONTROL AND STRUCTURE IN SOFTWARE PROTOTYPING
MD. MAHBUBUR RAHIM
FSAS 1992 1
INTRODUCING CONTROL AND STRUCTURE IN SOFTWARE PROTOTYP ING
By
MD. MAHBUBUR RAHI M
The s i s Submitted in Ful f i l ment o f t he Requ i re ments f o r
t h e Degree o f Ma s t e r o f Science in t he Faculty o f
Sci e n c e and E nv i ronmental Studi e s
Uni v e rs it i P e rtan i an Ma l ay s i a
Marc h 1992
Dedicated in the name of the all merciful Almighty Allah.
ACKNOWLEDGEM ENTS
T he autho r wis hes to e xp res s his deepe s t grat itude to
Dr. A bu Ta l i b ot h man , Cha irman o f the sup e rv is o ry c o mmittee,
for his constant guidance , a s s i stance and encou ra gement during
the entire course of the stu dy.
The author is extreme l y t hankful to c o -superv isor Mohd.
Hasan Se lamat , Lecture r , Department of Compute r s c ien c e , UPM,
for his inval u a bl e adv ic e s and c o mme nt s during t he various
stage s of the study. His keen int e rest in t h i s topic has a lway s
been a sourc e o f inspiration to the aut ho r .
The autho r a l so wis hes to
c o -superv i s o rs Mrs . Fatima h Ahma d
Lecture rs , Depa rtment o f Computer
a s s i s tance and s c ho l a rl y guidan ce.
exp res s
and Md.
Scien ce,
h is
Na s ir
f o r
thanks to
Sul a iman ,
their kind
The auth o r further l ikes to exp res s esp ecia l thanks to
B .A.A. Mus t a f i , for go ing through the ma nus crip t f rom t ime to
t i m e .
The aut ho r a l so ac know l ed ge s the c o -o p e ra t ion o f a l l the
Bang l ad e s h i students in UPM and UKM t hat m a de his stay in
Mal a y s i a enj oyabl e and m emo ra bl e .
The aut ho r furt he r l ikes t o re co rd specia l apprec iation t o
h i s be loved w i f e Sha heen Akhter for t yp in g some p a rt s o f the
the s i s and f o r cont inuous mo ra l e suppo rt and encoura gement .
Last but by no means the lea s t , the au tho r l ikes to
expre s s h e a rt fu l ind e btedne s s to his pa ren ts , brothers and
s i sters , p a rents -in -l a w , bro ther-in-l a w , s is ter-in -l aw and
other membe rs of h is famil y who ha ve suppo rted and encoura ge d
him during t h e ent i re p erio d o f the s tu dy.
iii
TABLE OF CONTENTS
Page
ACKNOWLEDGEMENTS iii
LIST OF TABLES viii
LIST OF FIGURES x
LIST OF ABBREVIATIONS • • • • • • • • . • • • . • • • • • • • • • . • • • . • . • . • xiii
ABSTRACT xiv
ABSTRAK
CHAPTER
I
I I
xvi
INTRODUCTION 1
Background o f the Problem • • • . • • . • . . . . . . . • . . • • 2
The Signif icance of the Study • • . . . . . . . . . • . . . . 5
Obj ectives of the Study 9
Organisat ion o f the Thesis • . . . • . • . . . . • . . . • • . • 1 0
PROBLEMS OF PROTOTYPING • . • . . . • • . . • . • • • . • • • • . . 1 1
I ntroduct ion • . • • • • • • . • • • • • • • • . . . • • • • • . • . . • • • • 1 1
Analysis o f Existing Definitions of Prototyping • . . . . . • . . . . . . . . . . . . . . . . . . . • . . . . 12
Proposed Definit ion of Prototyping . . . • . . . • • • . 15
Maj or Problems with Prototyping 1 5
The Need to Control Prototyping 1 6
iv
Exist ing L iterature on Control l ing
Protot yping • • . • • • • • • . . . • . . . . . . . . . . • . • . . • • . . . .
Discu s s ions on the Exist ing Methods to Control Prototyping • . • . . • . . • • • • • • • • • • • . • • •
I ndis c ip line : Another Dimens ion o f Problem in Prototyping • . • . . . . • . • • • . • • . • • • . . • •
Existing prototyping Methodologies . . . . . • • • • • •
Conclus ions • . • • • • • • • . . • . . • • . . . . . • . • . . . • • • . • • •
I I I PROPOSED SCHEMES FOR PROTOTYPE CONTROL AND DEVELOPMENT • • • • • • . • • • . . • • • . • . . • • . • • . • • • • • • . . •
I ntroduction • . . • • • . . . • • • . . • . . • • . . . . • . . . . • • . • •
User Satis faction Approach: Proposed Scheme to Control Prototyping • • • . . • . . . . . . • . . .
A Model to Measure User Satisfaction in Evaluat ing Prototypes . . • . • • . . . . • • . • • . . • . . .
Decision to Ceas e the Iteration Proces s • • • • • • . • • • • • • • . . • • . • . • • • • • . . . • . • • • . . • .
Merits o f User Satisfact ion Scheme . • . • • • . . . . •
Structured Prototyping : A Framework of Prototyping • . • • . • • . • . • . . . . . . . . . . . . . . . . . • • •
Proposed State-Structured Transition Model for Structured Prototyping . • . . . • • . . • • • •
structured Transitions • . . • • • . • . . . • • . • . . . • .
Merits of State-structured Transition
Mode 1 • • • . • • • . . . . . • • . . . • . . • . . . . . . . . • . • . • . . •
Rapid Prot otyping Versus Structured Prototyping . • • • • . . • . . . . . . • • . • . . • . . . . . . • • . . • . .
A prototypical Case Study • . . • • . . . . . . . • • . . • • . •
v
Page
17
2 6
2 7
2 8
34
36
36
37
38
44
47
48
49
53
57
58
6 1
B a c k ground o f the P rototype Pro ject
Rea s o n s to Se lect PA s y s t em as a
P rototyping P ro ject . . . . . . . . . . . . . . • . • . . . . . .
Type o f P rototype Approach Adopted
in Ca s e Study . . . . . . . . . . . . . . . . • . . . . . . . . • . . .
Time Frame o f Cons t ruction o f
P rototype P A S y s t e m . . . . • . . . . . . . . . . . . . . . . . .
Functionality in P rototype . . .. .. .. .... . . . .
Too ls u s ed in P rototyp i ng . .......... .. . .. .
Fo rmation o f U s e r Group ..... ............ . .
Eva luat i o n o f Prototypes ................. .
Demo n s t ration a nd Du ra tio n o f
P rototyp e s . . . • . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D e ve lopment and Circ u latio n o f
Que s t ionna i re s
Computation o f U s e r sati s factio n
Mann e r o f Pre s entat ion o f U s e r
s a t i s f a c t ion . . . . ... .... ....... . . . .. .. .. . . .
U s e o f CAS E Too ls in Structu red
P rototyping
P re s entation of F indings f o r
S t ructured P rototy p i ng .... ... , . . . . . . . . . . . . . . .
Con c lu s io n s . . .. . ......................... ... .
IV ADOPTING USER SAT I S FACTION APPROACH IN
CONTROLLING PROTOTYPING
P a ge
61
63
64
64
64
65
66
66
67
68
69
69
70
70
7 1
73
Introduct io n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
U s e r Sat i s f a c t ion at the 2nd It eratio n .. ....... 73
vi
v
U s e r sat i s faction at the 4th It e ra t io n
Comp a ra t i ve study o f U s e r Sat is f a ct io n
Between the 2nd a nd t h e 4th It era t �o n
P a ge
78
81
Guideli ne s ba s e d on the Find�ng s ....... ........ 84
Conc lu s io n s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
INTRODUCI NG STRUCTURE IN PROTOTYP ING . . • . . . . . . . . 87
I n t roduction . . • . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . • 87
The Evo lut ion o f the Data ba s e S cheme .. .. .. .. .. .. .. .. . .. ..
The Evo lution o f the P ro ce s s Mode l . .. .. .. .. .. .. .. .. .. .. .. ..
The Evo lut ion of the D e s i g n
Spe c i f i cat io n s .. .. .. .. .. .. . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
The Evo lution o f the U s e r Sugg e s t io ns
Evo lution o f P rototyping in Co ntext
to State-St ructured Tra ns it io n Model
87
92
99
101
106
Conclu s io n s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
VI CONCLUS IONS AND RECOMMENDATIO NS FO R
FURTHER STUDY 109
BIBLI OGRAP HY 117
APPEND I C ES 124
VITA . . . . . . . . . . . . . . . . . . . . . . . ........... . ........ 144
vii
LIST OF TABLES
Table
1 The Background Pro f ile o f Users • • • • . • • • • • • • • •
2 User Reactions towards the Prototype at the 2nd Iterat ion • • • . . . • • • • • • • • • • • • • • • • • • •
3 Grouping o f Users based on their Levels
4
5
of S atis faction • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Statist ic s based on the User Reactions towards the Prototype at the 2nd Iteration • • . • . . • • . • . • • • . • • • • • . . • • • • • . • • • • • • . •
User React ions towards the Prototype at the 4th Iteration • • . . . • • • • . • • • • • . . • • • • • . • •
6 Statistics based on the User Reactions towards the Prototype at the 4th
7
8
9
10
Iteration • . . • • • • • • • • • • • • • • . . • • • • • . • • • • • • • • • • •
Comparison o f User Satis factions towards the Prototype Measured at the 2nd and the 4th Iterations • • • • • • . • • • • • • • • • . • • • • • • • • • • • • • •
Comparison o f Standard Deviations in User Reactions towards Each of the Factors of the Prototype . • • • • • • • • . . . . . • . • • • • . . . . • • • • • . • . •
Number o f Changes in the Database S cheme
Number o f Attributes in Success ive Prototype Iterations • • • • • • • • • . • • • • • • • • • • • • • • • •
1 1 The Evo lut ion o f Processes i n the DFD during t he Successive Prototype
12
Iterat ions
The Number o f New Processes during the Success ive Prototype Iterat ions
viii
Page
6 7
7 4
75
7 7
7 9
80
83
85
88
90
94
9 6
1 3 The Evolut ion of Modules in the SCD during the Success ive Prototype
14
15
Iterat ions • • . • • • . . . • • • • • • • . • • • • • • • • • • • • . • . • • • •
The Evolution of Changes as Suggested by Users during the Successive Prototype Iterat ions • • . • • . • • . • • • • • • . • • • . • • • • • • • • • • • • • • . •
User Responses using Adj ect ives
1 6 User Responses i n Corresponding
Page
99
106
128
Numeric F igures • • • • • . . . . . • • • • . • • . • . . • • • • • • • . • • 128
17
18
19
20
Description of New and Updated Attributes at the 1st Prototype Iteration • • • . . • • • • • . • • . • • • • . • . . • • • • . • • • • • • • • • •
Descript ion of New and Updated Attributes at the 2nd Prototype Iterat ion • . • • . . . • . • . . . • . • • • • • • • • . • • . • . • . • • • • • •
Description of New and Updated Attributes at the 3rd Prototype Iteration • • . . • • • • • . • • • . • . . . . . • . . • . • . • • . • • . • . • •
Descript ion of New and Updated Attributes at the 4th Prototype Iterat ion • . • • . • . • • . • . . • . . • • • • • • • • • • • • • • • • • • • . •
ix
141
142
142
143
LIST OF FIGURES
Figure
1 Software Life Cycle : Per Error Fix Cost Per Phase . . . . . . . . • . . • . . . . . . . • • . . • • • . . . . .
2 Three Dif ferent Views on Prototyping • • • • . • . . •
3 Idealised Change Trend Curves . • • . • . • • • • • • . • . .
4 A Variation o f Idealised Change Trend Curves . . . . . . . . . . . . . . . . . . . . • . . . . . . . . . . . .
S Another Variation of Idealised Change
6
7
8
Trend Curves . . . . • . . . • . . . . • • . . • • . • . • . • . • . . • • . .
Boar ' s View on Prototyping • . . • . . . • . • . • . . . . . . .
state-Transit ion Model of Prototyping as Suggested by Kraushaar and Shirland
Rating Scale to Measure User Satisfaction . . . . . • . . . . . . . . . . . . . . • . . . . . . . . . . . .
9 An Illustrat ion o f us ing Semant ic Dif ferent ial Technique in Questionnaire . . . . • . . . . . . . . . . . . . • . . . . . • . . • . . . .
10 The Growth Pattern of User Satisfaction towards t he Prototype
1 1 The Growth Pattern of User Reactions towards the Factors . . . • . . . . . . • . . . • . . . • • • • . . . .
12 The State-Structured Trans ition Model of structured Prototyping
13 The Details of Inner View of the State-Structured Trans it ion Model
14 The Details of Inner View o f Rapid Prototyping . . . . . . . . . . . . • . . . . • . . • . . • • . . •
x
Page
4
1 4
2 1
2 4
2 S
30
32
42
42
4S
4 6
S 1
5 2
60
1 5
1 6
A Comparat ive Picture Showing the Maximum, the Minimum and the Average Sat i s f act ion of t he Users towards the Prototype • • • . . . . . . • . . . . . . . • . . . . . • • . . . . . . . . . . .
The Trend o f Changes in the Database Scheme against Prototype Iterations
17 The Growth Pattern of Changes in
18
19
20
2 1
the Database Scheme • • . • . . • • • • • • • . • • • • . • . • • . . •
The Growth Pattern of Processes in DFD
The Trend of Addit ion of New Processes in DFD . • • • . • • . • . . • . • . . . . . . . . . . . . . • . . • . . . . . . . .
The Trend o f Changes in Various Leve l s of Processes i n DFD . . . . . . . . . . . . . . . . . . . . . • • . . .
The Evolution of Modul e s of the PA System against Prototype Iterat ions
22 The Growth Pattern of SCD Modu les
23
24
25
26
2 7
o f Student , student Grades and Reports Components of the PA system • . • . . . . . . . . . . . . • .
The Growth Pattern of SCD Modu les in Course , PA and Course Registration Component s of the PA System . . . . . . . . . . . . . • . . .
The Growth Pattern of Changes as Suggested by Users • . . . • • . • . . . . . . . • . . . . . . • • . . .
The Represent ation of the PA System in terms of State-Structured Transit ion Mode 1 ....................................... .
An Unnormal ised D ata Model for the PA System at t he 5th Iterat ion . . . . . . . . . . . . . . .
A Normal ised Data Model for the PA system at the 5th Iterat ion . . . . . . . . . . . . . . .
xi
Page
82
89
9 1
93
95
97
100
102
103
105
107
133
134
Page
28 A Sample Data Flow Diagram used in the PA System . . . . . • . . . . . . . . . . . . . • . . . . 1 3 5
29 Another Sample Data F low Diagram used in the PA System . • . . . • . . . . • . . . . . . . . . . . . 1 3 6
3 0 A Sample Structure Chart Diagram used in the PA System . . . . . • . . • . • • . . . . . . • . . • • • 138
3 1 Another Sample Structure Chart D iagram used in the PA System • . . . • • • • . • • • • . . . . . . • . . • • 1 3 9
x i i
ACD
CAS E
CB I S
DBMS
DFD
D MD
E/ R
FSAS
I -CAS E
I S
LAN
MI S
PA
POSE
SCD
SDLC
SP
ST
UP M
LI ST OF ABBREVIATIONS
Ac tion Chart DLag ram
Computer As s Ls ted So ftware Eng uleerLng
Computer- B as ed Info rmatLo n Sy s tems
D a ta Ba s e Mana gemen t Sy s tems
D a ta F low D �a grammer
D a ta Model D �a grammer
Ent�ty Relat�onsh�p
Facu lty o f S c�en c e and Env �ronmental s tudies
Integra ted Computer As s �s ted So ftware
En g�neer�ng
I n fo rm at�on Sy s tems
Loc a l Area Netwo rk
Man agement Info rmat�o n S y s tems
P ena s �h at Akadem�k
P �c tu re OrLented So ftware EngLneer�ng
S tructure Chart D�ag rammer
S y s tems D evelopment L�fe Cycle
S truc tured P ro to typ�ng
S tru c tu red Trans �t�ons
Univ ers �t� P ertanLan Malay s La
Abstract of thesis submitted to the Senate of Universiti Pertanian Malaysia in fulf ilment of the requirements for the degree o f Master o f Sc ience .
INTRODUCING CONTROL AND STRUCTURE IN SOFTWARE PROTOTYPING
By
MD. MAHBUBUR RAHIM
March , 1992
Chairman Dr. Abu Talib Othman
Faculty science and Environmental Studies
Software prototyping is emerging as an attractive software
development paradigm in which a series of executable prototypes
are constructed and u sers are encouraged to exerc ise with such
prototypes in a live environment in order to solicit their
overall requirement s . In spite o f these benefit s , prototyping
i s not free f ro m pit f alls . A ma j o r problem of s o ftware
prototyping is the lack of explicit gu idelines to control
prototype iterat ions which tend to continue infinitely in a
volatile environment . The problem is further aggravated by the
unavailability of a suitable framework, within which to develop
prototype s y s t em s in a manageable and flex ible manne r .
Therefore , current practice o f prototyping lacks in discipline .
xiv
This study is directed to address these critical is sues of
prototyping . The primary goal is to develop a strategy to
c on t r o l and to s u gge s t a f r amewo r k to manage s o ft ware
prototyping . A s c heme cal led 'User satisfaction Method' which
relates the degree of u ser satis faction with the prototype's
c apab i l ity in c larifying user requirements is developed that
prov i d e s r at i o na l e gu idel ines in dec i d i ng when to c e a s e
prototype iterations . To complement this scheme, a framework
for structured prototyping , which is cal led 'State-Structured
Tran s ition' model is also deve loped . The framework cons iders
each prototype 'vers ion' as a ' state' and suggests that the
transitions from one state to another need
u s ing structured prin c iple s .
to be performed
In order to verify the appl icabi lity of such a framework
and scheme , a case study has been undert aken . The resu lts
obtained conf irm that 'User Sati sfaction Scheme' can be
adopted as a surrogate to control prototyping process . The
research f indings further estab l ish that the framework o f
s t r u c tured prototyping e n s u re s smoot h t r a n s it ion f rom o n e
prototype ver s i on t o another . The r e f o r e , the 'User
S at i s fact ion S cheme' should be adopted in con j unction with the
framework of 'structured Prototyping' in order to successfully
control and manage so ftware prototyping .
xv
Abstrak tes is Pertanian Malaysia Sains .
yang bagi
dikemukakan kepada Senat Universit i memenuh i syarat untuk Ij azah Master
MEMPERKENALKAN KAWALAN DAN STRUKTUR DALAM PEMPROTOTAIPAN PERISIAN
Oleh
MD. MAHBUBUR" RAHIM
Mac , 1992
Pengerus i : Dr. Abu Talib Othman
Fakulti : Fakulti Sains dan Pengaj ian A l am Sekitar
P emprot o t a ipan pe r i s i an s edang mu n c u l s eb ag a i s atu
paradigma pembangunan peris ian yang menarik di mana satu s iri
protot a ip yang b o l e h di l aks anakan , d i b i n a dan penggu n a
digalakkan mencuba prototaip tersebut di persekitaran sebenar
untuk memperolehi keperluan keseluruhan . Oi sebal ik faedah-
faedah ini , prototaip j uga tidak terlepas dari kelemahannya .
Satu masalah besar pemprototaipan peris ian ialah kekurangan
petunj uk yang sesuai untuk mengawal lelaran prototaip dalam
persekitaran yang berubah-ubah . Masalah ini menj adi bertambah
rumit apabila t idak ada rangka ker j a yang sesuai untuk membina
s istem-sistem prototaip dalam keadaan terurus dan teratur . O leh
itu , amalan prototaip sekarang kekurangan dari segi dis ipl in .
xvi
K a j i a n i n i d i tu mpukan kepada i s u - i s u kr it i k a l d a l am
pemprotot ipan . Tuj uan utama ialah memb ina satu strategi untuk
mengawal dan mencadangkan satu rangka kerj a untuk mengurus
pemprototaipan perisian . Satu skema yang dipanggil , Kaedah
Kepuasan Pengguna ' yang menghubungkait darj ah kepuasan pengguna
dengan keupayaan prototaip yang menerangkan kehendak pengguna
telah dibina untuk member i garis panduan yang ras ional dalam
membu at pert imb angan b i l a l e l aran protot a i p patut
diberhentikan . Untuk mel engkapkan skema ini , satu rangka ker j a
model protota ip berstruktur yang dinamakan ' Peral ihan Kaedah
Berstruktur ' j uga telah dibina. Rangka ker j a ini mengambilkira
setiap versi prototaip sebagai satu keadaan ke keadaan yang
lain perlu di laksana menggunakan prins ip-prin s ip berstruktur .
Dalam mentahkikkan pengguna rangka ker j a dan skema ini ,
satu kaj ian kes telah dibuat . Hasil daripada kaj ian ini telah
mengesahkan bahawa ' Skema Kepuasan Pengguna ' boleh diguna untuk
mengawal proses pemprototaipan . Kaj ian ini j uga telah berj aya
membuktikan bahawa rangka kerj a pemprotota ipan berstruktur
b o l eh memp a s t ikan per a l ihan yang l a n c ar dar i s a t u ver s i
pro t o t a i p k e v e r s i yang l a i n . O l e h i t u ' S kema Kepu a s an
P e nggu n a ' patut d igunakan s e l a r i dengan rangka ker j a
' pemprototaipan Berstruktur ' supaya dapat mengawal dan mengurus
pemprototaipan peris ian dengan j ayanya.
xvii
CHAPTER I
INTRODUCTION
S oftware prototyping as an a lt e r n a t ive appro a c h for
developing Information Systems ( IS ) , has recently been widely
publicised in the computer l iterature . Also, there has been an
incre a s e i n awarene s s amo ng s oftwa�e c o mmun it y about t h e
strengths o f this new concept ( Mayhew , Wor sl ey and Dearnley,
1989 ) . Recent survey studies ( Gu imares , 1987 ; Mohd . Hasan
Selamat , 1988 ; Carey and Currey , 1989 ; D oke , 1990) confirm
t hat prototyping approach i s s l ow ly g a i n i n g popu l a r it y .
However, in spite of widespread publicity and discuss ions ,
st i l l a l arge part of software developers remain sceptical and
r e l at iv e l y few orga n i s at i o n s have a c t u a l l y adopted t h i s
approach i n developing their systems ( Mayhew e t al . , 1989 ) . I t
i s l argely due t o the lack of adequate know-how for developing ,
control l ing and managing the evolving nature of prototyping . In
this thesis , attempts have been made to examine the problems
associated with the development and control of prototyping .
This chapter introduces the background of the problems
a s s o c iated w i t h t he s y stems deve l oped by t h e t radit i o n a l
methods and presents prototyping as a pos s ible solution t o
overcome t h e s e prob l ems . However , i n s p i t e of e no rmou s
potential benefit s , prototyping is not without any pitfa ll s .
1
2
T h i s c hapt e r a l s o h ig h l i g ht s t h e i n h e r e nt weakne s s e s o f
prototyping t hat impedes its appl icat ions and argues for a
need o f r e s e a r c h i n order t o over come t h e d rawbacks o f
prototyping . This chapter also presents obj ectives of the
study to addre s s the cr it i c a l i s su e s of prototyping and
attempt s t o f o rmu l at e new s t r at e g i e s t o overcome t h e s e
pitfalls .
Background of the Problem
During the l ast three decades , there has been a phenomenal
pro l i feration o f comput er s . T h i s i s part l y due t o t he
cost/performance rat io of the hardware which has improved
drast ically and to the micro-computer revolution . As computer
has become more acces s ible , the demand for informat ion in order
to i n c r e a s e bu s ine s s opportun i t i e s and better management
pract ices has also grown up ( Yeh , 1990) . This growing demand
for computer solutions , coupled with increasingly complex and
dynamic bus ines s environment , has resulted in the development
of complex computer based information systems ( CBrS) . These
systems are no longer as s imple and small as they were in the
early 60 ' s . The informat ion requirements of these systems
have become more sophisticated , highly volat i le and complex due
to the competit ive and dynamic bus ines s environment . Unt i l
now , most of these informat ion systems are developed based on
t he c l a s s i c a l wat e r f a l l mode l ( Boehm , 1 9 8 1 ; Fox , 1 9 8 2 ;
Sommerville , 1982), commonly known as Systems Deve lopment Life
3
Cycle ( SOLC ) . Although the SOLC has been enhanced by adopting
new techniques , its maj or weaknesses have not been el iminated
( S l u s ky , 1 9 8 7 ) . I n SOLC , att empt ing t o e l i c it exact
requirements is an extremely diff icult task because of the
cultural gul f that exists between systems developers and users .
The second reason is that in SOLC , requirements are usually
expres sed in terms of natural language . Although natural
languages are excellent medium for novels and poems , where the
quality of such works is partly judged by the degree of
amb igu i t y in t h e t ext , but t he ir u s e in requ irements
spec i f icat ion may often lead to a disaster ( Ince , 1988 ) . Such
t extu a l des c r ip t i on s are not s u it ab l e in c ommu n i c at i ng
technical concepts between users and developers ( Morrison ,
1988 ) . The third reason is that users do not cons ider system
definit ions to be a front end act ivity with a def inite ending
point , rather it is viewed as an ongoing process ( Scharer,
198 1 ) .
An inadequate and inconsistent requirements are bound to
introduce errors and such errors may somet imes be disastrous .
Exist ing l iterature reports that many systems have failed due
to t h e e r r o r s a r i s i ng f rom m i s i nt erpret ing r equ i rement s .
Conse quent l y , u s er requ i r ement s need to b e ident i f i ed
carefully because good requirements is an important factor in
the success of a system ( Scharer , 198 1 ) . The SOLC provides
l ittle opportunities to overcome requirements ident ificat ion
4
problem. Many of the systems developed by SOLe result i n
unsatisfactory systems and frustrate end users. These systems
are expensive to repair because the later. the errors are
detected, the more costly they a::e to repair (Davis e t al.,
1989). Figure 1 highlights the fact that the cost of fixing an
error rises dramatically as tne software progresses through its
life-cycle. However, sometimes, it is possible to salvage
these systems, but only at the expense of high maintenance
costs and frequently such maintenance costs far exceeds the
development costs. Ince (1988) states that a survey conducted
in U.S.A. finds that software professionals spend 48% of their
time in maintenance while 43% time in development of new
systems. Vonk (1990) mentions that total maintenance costs of
Figure 1 Software Life Cycle: Per Error Fix Cost Per Phase
(After, Glass, 1981)
a system consumes 60% of the total life-cycle costs and 3 0% to
5 0% of t he total life-cyc le costs is due to inadequate analysis
and understanding of user requirement s . The net ef fect is that
users are experiencing a growing degree of frustration with the
seeming inability of the information systems professionals to
meet their needs . These problems have created a tremendous
bottl eneck in SOLC . Consequent ly , the appropriatenes s of this
model has been criticised by many researchers ( Hekmatpur and
Ince , 1988 ; Ooke , 1990 ; Yeh , 1990 ) because of its inability to
meet user requirements . As such researchers like Naumann and
Jenkins ( 1982 ) suggest that new tools and methodologies should
be u s he re d in to deve lop the right so ftware within t he
constraints of budget , resources and schedu le . In this study ,
an alternative software development paradigm known as software
prototyping , has been addres sed which has the potential to
overcome many of the weaknesses associated with the SOLC
approach .
The Significance of the Study
This study focuses on the software prototyping approach
which is receiving growing attention and recognition from many
academicians and practitioners as a possible alternative
solution to develop a right system based upon a clear and
u nambiguo u s r e qu ir emen t s ( Mahmood , 1 9 8 7 ) . I n prototyping
approach , a series of working mode ls commonly known as
prototypes are developed , to provide the users with an
6
opportunity to interact with a real system to test their ideas
and a ssumptions about the new system. Thus prototyping allows
more c o n c r e t e ident ifi cat ion and v a l i d at i o n of u s e r s
informat ion requirements ( Alav i , 1984a ; Naumann and Jenkins ,
1 9 8 2 ) , fac i l i t at e s system s imp l ement at i o n and ac cept ance
( Applet o n , 1 9 8 3 ; D e ar n l ey and Mayhew , 1 9 8 3 ) , improves
c ommu n i c a t i o n between u se r s and s y s tems de s i g n e r s ( Al av i ,
1 9 8 4a ; Dearn l ey and Mayhew , 1 9 8 3 ) , s ign i f i c ant ly redu c es
maintenance efforts and shortens the over-al l total l ife-cycle
budget and s c he du l e . Once the requ i r ement s are c le ar ly
understood and the proposed system is in development in the
t ar get env ironment , t he prototype s may not be ab s o lu t e l y
discarded , rather they can b e wisely util ised as a training
vehicle for the novice users ( Morrison , 1988 ) . These novice
users can receive " hands-on " experience us ing the prototypes ,
well ahead of t he proposed system is implemented . Prototyping
enables the system to be designed from the users ' perspectives
( Harrison , 1985 ) . Because of these benefit s , the prototyping
approach is often viewed as an ' insurance pol icy for succe s s '
in systems development ( Guimares , 1987 ) .
Prototyping i s relatively a new concept in context to
information systems development and like any new technology , it
is not without any pitfalls . One maj or problem is that there
exists l ittle consensus among IS community on the definition ,
scope , environment , too l s and benefits of prototyping . It i s
7
due to the fact that many authors have def ined prototyping from
a wide range of perspectives based on their own perceptions .
consequent ly, prototyping is frequently misinterpreted and
misunderstood by the I S profess ionals and very often it is not
properly practised . This il l-practice based on incorrect view
of prototyping actually deprives IS people from the real
benef its of prototyping . As such, a comprehensive definition
needs to be proposed for software prototyping .
Another problem is that prototyping is often equated
with the unstructured way of developing systems that were in
pract i c e b e f o re t h e arrival of s t ru ctured methods and
techniques ( Vonk , 1990 ) . It is primarily due to the lack o f a
discipl ine in developing systems using prototyping approach .
Boehm and Standise ( 1983 ) ment ion that prototyping lacks a
coherent methodology . In prototyping , the focus is on the
identification of user requirements through a series of quickly
produced prototypes . As such , developers have the tendency to
rus h to coding immediately after requirements are clarified
through user evaluation of prototypes . Developers are tempted
t o p l unge i n t o prototype construction before suf f i c ient
analys is is carried out ( Carey , 1990 ) . Experiments conducted by
B oe hm , Gray and S eewa l dt ( 1 9 8 4 ) a l s o c onfirm t hat i n
prototyping approach much less effort is devoted for planning
and design . This clearly bypas ses the analys is and des ign
phases of prototype construct ion and consequently resu lts in
