Information Systems Development

Information Systems Development

Abstract The Information Systems Development Life Cycle (ISDLC) is usuaiiy treated as a rigid sequence of ac- tivities. This artide asserts that differences in the nature of development projects should affect the planning of the iSDLC. Two dasses of factors affecting the iSDLC are identified: factors reiating to the environment and factors reiating to the deveiopment effort (e.g., in- house deveiopment vs. canned software package). Each step aiong the iSDLC is decomposed into several dimensions reiating to the activities that shouid be per- formed, the degree of control that should be exerted, to human resources, to other resources, and to the time factor. The relationship between the six dimensions and the two classes of factors are expiained. Finaiiy, a prac- ticai approach to iSDLC planning is suggested based on a structured procedure and a number of working forms. It assists in preliminary pianning of the development process as weii as in periodic reviews and revisions whenever the project reaches a certain milestone.

Keywords: Information systems life cycle, information system development

ACM Categories: 3.5.0

Introduction The Information System Development Life Cycle (ISDLC) is an established concept in the MIS area. Initially coined by Blumenthal during the late sixties [2], it is now a cornerstone in the MIS literature and a hallmark of every development ef- fort, implying that no MIS activity should be car- ried on without imposing strict ISDLC procedures, practices and methods on system developers.

The traditional (and conceptual) approach to the ISDLC states that a development project has to undergo a series of phases where the completion of each is a prerequisite to the commencement of the next and where each phase consists of a predetermined list of steps. The general scheme for the ISDLC is similar almost everywhere. It typically contains three major phases consisting of several steps each, as suggested by Ahituv and Neumann [1 , Ch. 7]:

I. Definition Phase 1. Preliminary analysis 2. Feasibility study 3. Information analysis 4. System design

II. Construction Phase 5. Programming 6. Development of procedures

III. Implementation Phase 7. Training, conversion, and testing

Subsequent to these is the Operation Phase which is beyond the scope of this article.

The traditional ISDLC has always been a troublesome, complex, costly, and time- consuming process, primarily because of the nature of the systems that must be built with it. While a complete replacement of the traditional systems development approach is not likely in the near future, there is general agreement [12] that some variation of the ISDLC may be a necessary and appropriate approach for transaction pro- cessing and traditional reporting systems.

The traditional approach advocates a rigid ISDLC in order to assure control over the development process. In practice, however, development pro- cesses are not that rigid. They vary with respect to the complexity of the system under develop- ment, the importance attached to that system, and the user’s environment. Moreover, in an era where canned software packages are mushroom-

MIS Quarterly/June 1984 69

Information Systems Deveiopment

ing, there is a real difference between the ISDLC of a system developed in-house, and a system acquired from an external supplier.

With waiting times for new applications running in- to years, managers and users have been casting about for more efficient approaches to systems development. Gremillion and Pyburn [7] suggest that managers may have to abandon traditional patterns and instead evaluate projects by the criteria of commonality, impact, and structure in order to choose an appropriate development strategy. McFarlan [9] notes that different pro- jects required different management approaches in order to reduce the traditional risks of time and cost overruns, technical shortfalls, or outright failure. McFarlan identifies three dimensions that influence the risk inherent in a project: project size (dollar expense, staff, number of depart- ments affected), experience with the technology, and project structure. Consequently, he proposes a series of questions and forms that companies can use to build a risk profile that will help them choose a specific development process.

This article takes a similar line of thought, namely, that the emphasis laid on various phases of the ISDLC should depend on the nature of the specific project. The variety of attributes con- sidered here and their classification are much broader than McFarian’s. Each step in the ISDLC is characterized by several dimensions though a certain aspect (dimension) may be emphasized while another aspect is de-emphasized. For ex- ample, when an off-the-shelf software package is installed, testing can be de-emphasized while training should be highly stressed, but both aspects are part of the implementation phase of the ISDLC.

This article distinguishes between two categories of factors affecting the ISDLC: factors derived from user and environment requirements (pro- ject/environment factors), and factors derived from the nature of the development process (development type factors). The article also distinguishes between various dimensions (at- tributes) of the development process.

Factors Affecting the ISDLC The main proposition of this article is that the amount of effort invested in the various steps of

the ISDLC should be a direct function of assorted factors which may vary among projects. Therefore, an ISDLC should not be viewed as a rigid sequence of activities but rather as a more general framework from which the most adequate development plan can be derived for a particular project. In other words, there is no universally correct way to run all projects. This section ex- plains various factors contributing to the shape and contents of a specific ISDLC (for a more general discussion of such factors see [5,8]). These selected factors are taken from the literature. The measurement of their intensity is based partially on the literature and partially on our studies in a number of organizations. Since this article is methodological in nature, it does not attempt to lay down an analytic framework behind the factors, and they may not be appropriate for all companies; however, they represent a good starting point.

Project/environment factors

This group refers to factors derived from the re- quirements imposed on the system by users and other related bodies. Following is a list of factors and suggestions as to how they can be measured (note that the measures are suggestive and not prescriptive):

Organizational Scope — The number of organizational units that are directly connected to the project. A project can involve only one or two departments (e.g., inventory control), or it can cut through most of the organizational entities (e.g., budget control, cost accounting).

Measuring: Count the number of organizational units involved in the project [7,9].

importance — The importance of the project for the organization. Does it significantly contribute to the operation of the organization?

Measuring: Importance cannot be directly measured, however it can be revealed through the expenditures the organization is willing to commit to the project, or through opportunity costs, such as cost decrease or profit increase. Thus, a surrogate variable for importance can be the budget of the project relative to other similar activities, or the project’s relative contribution to cost saving or profit making. These are usually

70 MIS Quarterly/June 1984

Information Systems Development

assessed at an early stage of the ISDLC [7, 9, 10].

Organizationai iVIaturity — The experience of the users in developing and operating com- puterized information systems. A more ex- perienced organization may expect a smoother in- stallation of a new system.

Measuring: Maturity is hard to measure, however, Gibson and Nolan [6] have defined the stages of EDP growth. By locating an organization as being in one of these stages, one can identify the maturity level of the organization [11]. Another possible measurement is simply the number of computerized applications already installed in the organization.

information System Poiicy — Organizations dif- fer in the way they delegate information process- ing activities to departments. In some organiza- tions there is a central powerful DP function; in others, many functions are distributed. The level of distribution affects the emphasis put on various activities of the ISDLC.

Measuring: Level of distribution cannot be measured by a single variable. One should assess it by considering the aspects of distribution specified by Buchanan and Linowes [3, 4]. They suggest how to portray a profile of distribution. If we follow their assessment procedure we may find, for example, that while deveiopment is cen- tralized, operation is decentralized, or vice versa. Any pattern of centralization and decentralization may have a different effect on the ISDLC [11].

Structuredness Levei — A transaction process- ing system is normally more structured than a system supporting managerial decisions. A more structured system may require less user par- ticipation during various ISDLC steps. Hence, system structuredness is an important factor in planning the development effort.

Measuring: Structuredness can be assessed by examining the information processing the system is supposed to perform. The lower the iocation of information processing on the organizational hierarchy, the more likely it is that the system is highly structured and that its specifications can be defined [7. 9]. Practical measurement can be at- tempted by identifying the location of the system’s major users along the organizational hierarchy.

Technologicai Environment — Some develop- ment projects are based on advanced technology, while others may be still anchored in the conventional batch processing mode of operation. The use of advanced technololgy is riskier, particularly when employees are not that familiar with it. In such cases more attention should be paid to various ISDLC stages.

Measuring: The degree of advancement in technology can be measured simply by the number of years elapsing since a specific technology was announced [9, 10, 11].

Development types

Any development project, be it in a large or small organization, a centralized or decentralized en- vironment, is typified by some traits related to the nature of the particular application under develop- ment. A development project can be one of the following types:

1. Development of a new information system, 2. Modification (enhancement) of an existing

system, 3. Installation of an acquired new system

(e.g., a canned software package), 4. Installation of a new version of an existing

acquired system, or 5. Bug-fixing or a minor change in an existing

system.

The type of project undoubtedly affects the various activities along the ISDLC. For instance, in an installation of an acquired system, the pro- gramming stage entails a relatively small effort while some aspects of the feasibiiity study are highly emphasized. In a bug-fixing project much more attention is paid to the time factor than in the installation of a new version of an existing system.

The next section presents dimensions of the ISDLC in order to show later how these are af- fected by the project/environment factors and by the development types.

The Various Dimensions of an ISDLC That there should be a logical sequence of well- defined steps constituting an ISDLC is a generally

MIS Ouarterly/June 1984 71

Information Systems Development

accepted principle in MIS; that the direction of the development process is generally from top to bot- tom, from a comprehensive view of the system to its technical detailing, is also widely accepted. Differences are most apparent in the labelling of the various steps and in some nuances regarding their content. Nevertheless, the essence of the ISDLC is common to most textbooks and practi- tioner manuals.

The vertical dimension of an ISDLC

The vertical dimension of an ISDLC is simply the sequence of steps which constitute the develop- ment process. Starting from ‘preliminary analysis,’ it goes through various steps, as seen in the seven point outline in the introduction, until it culminates in the installation of a new system. Various factors may increase or decrease the significance of a certain step. In some cases, a certain step can even be eliminated, for instance ‘programming’ in the case of acquired software.

Regarding each step as a rigid entity is an im- proper approach. Within each step there are various elements that can be altered due to the af- fecting factors. For example, while the degree of control that management should exert on a pro- ject is contingent on some factors (such as ‘organizational scope’) that may differ from pro- ject to project, it can also vary during different ISDLC steps.

The horizontal dimensions of the ISDLC

The ISDLC is a formal, gradual progress toward completion of an information system. This pro- gress consists of steps; each step can be con- sidered as a project by itself, including a list of tasks to be accomplished, a final product to be delivered (e.g., a feasibility report), and a se- quence of check-points to be audited. There are some elements that are common to all ISDLC ac- tivities. These elements can be emphasized or deemphasized according to the status of the af- fecting factors. Following is the list of elements labelled ‘horizontal dimensions.’

The Activity Dimension — The process of developing a new system consists of many ac-

tivities. The activities incorporated in the ISDLC are:

1. Studying the organization

2. Information requirement analysis

3. Cost/benefit analysis

4. System analysis (logical design)

5. System design (physical design)

6. Programming

7. Procedure writing

8. Training

9. Testing

We usually tend to associate activities with ver- tical steps; for instance, the programming activity is performed during the programming step. However, this is not always accurate. Sometimes one has to perform a certain activity, not only within its natural step but within another step (for example, in a feasibility study of a very risky and pioneering project, one may program a sample prototype module during the feasibility study step [i.e., a pilot program] in order to validate some assumptions). Another example is the ‘studying of the organization’. This activity is carried out during the feasiblity study step and may be repeated during the information analysis step. Thus, the association of activities and steps is not necessarily a one-to-one or even a many-to-one relationship. Activities are iterated in various steps, although the depth of undertaking an activi- ty may vary through the ISDLC. Table 1 depicts degrees of intensity of the activities during the various steps in a normal project. In any particular project, the intensity is affected by the aforemen- tioned factors.

The Control Dimension — There are a variety of methods to assure that a system development project progresses in the right direction. This in- cludes steering committees, walkthrough tech- niques, audit procedures, quality control and in- spection practices, and the like. The selection of a set of control tools for any particular project depends on the nature of the project and the fac- tors affecting the project. Moreover, control in- tensity may vary along the ISDLC.

The Human Resource Dimension — There are a variety of job categories involved in information

72 MIS Quarterly/June 1984

Information Systems Development

S Q.

(0

O

10

a

(0

u «

O

a OT

Q (0

•>

•s

Ol

I _o tt a.

o

OT Q

E • –

!2 CO

OT5

tt » O)

Q

CO

03 “S3 >

c c g 0) (0 IS E CO E – 5 CO

c cu ^ — OC

O ro >• N T3

o OT

A ct

a. (U

OT

Ml 9 <

is

ja si

bi iit

S tu

dy

• ^ CO

ro >-

.2 <

CO 0 Q

a> ‘co >,OT

c

ra m

m ii

2

ed ur

e

O

2CL

iti ng

cg

Q.

o

E D

T3

E

CO c cu

hi gh

MIS Ouarterly/June 1984 73

Information Systems Development

systems development (e.g., information analysts, system designers, programmers, procedure writers). Not every category participates in every step. Programmers, for instance, are not required in a feasibility study. System programmers may not be required in a simple business application, but are essential in the development of a sophisticated real-time system.

The Non-Human Resource Dimension — A development project consumes many resources other than human; these include computer time, materials, capital investment, and the like. Each of those is a horizontal dimension in itself, because it may be affected by the various factors. For the sake of simplicity, they are all aggregated here under the title ‘non-human resource.’

Tiie Time Dimension — It takes time to under- take each ISDLC step. In some projects, manage- ment allows for a long time; in others, a very short time is allotted for developers to carry out a step. This may vary among projects and along steps, therefore, time is a horizontal dimension as weil.

The horizontal dimensions characterize each step of the ISDLC. They shape the plan for an ISDLC which is uniquely tailored for each given project. For example, a very complex system whose scope is wide and whose chance of success is in doubt, will probably trigger the following dimen- sional values: high iteration of activities during the feasibility study (even to the degree where a pilot program is written and tested), high degree of control, high quality of human resources, reluc- tance to allocate many resources before con- crete proofs of success are evident, and greater time allocated to a feasibility study.

A Practical Procedure for Planning and Reviewing an ISDLC There is no magic wand to assist in shaping the optimai framework for any given development project, nor are we familiar with any mathematical formula that does it. However, we do propose a procedure that, based on two types of forms (working sheets), provides a systematic approach to adjust each ISDLC step, to the project’s specific circumstances. The procedure also enables the review of each step, at predesig-

nated milestones or upon completion, in order to verify the initial anticipations and to revise plans. The procedure is illustrated by the case of an Israeli company where the ideas presented in this article were used in developing an information system.

The case involved a wholesale firm, with a chain of regional warehouses, exploring the possibiiity of installing a new on-line inventory control system to replace an existing batch-processing system. The firm was centrally managed, and so was its computer department. The initial idea was to instail terminals in the regional warehouses and key-in inventory transactions to a central system. The company had long experience with EDP. Management predicted that the new system would mainly contribute to reduce costs of overstocking. The EDP department believed that there were adequate software packages in the market.

The first step in the suggested procedure was to construct a ‘project profile’, namely, the level of risk associated with the project. This was per- formed by filling out Form 1, whose purpose is twofold: to draw a project profile, and to provide inputs to a subsequent Form 2. The evaluator (the user of the form) had to mark, on a scale from 1 to 5, a preprinted assessment for each of the six project/environment factors and the development type. The closer to 5 the marks are, the more “risky” the project is.

Table 2 iilustrates the way Form 1 was filled out during the preliminary analysis step for the wholesale firm. The profile emerging from Exhibit 2 (circled attributes) is of a normal development project, not too risky but far from being trivial. This finding affected the planning of the ISDLC, particulary the next immediate step of the feasibili- ty study.

We suggest that the first attempt to fill out Form 1 be during the first step — preliminary analysis. Normally, great uncertainty prevails during that step, so the assessment of some factors will be questionable (for instance, before performing a feasibility study it is difficult to tell whether a cann- ed software package will be preferred to in-house development or not). Still, this will give a first hint about the nature of the project. Revisions of Form 1 can take place at major milestones along the ISDLC, particularly upon completion of each major step.

74 MIS Ouarterly/June 1984

Information Systems Development

Table 2: Sample Form 1 ( Project Profile ) for the Preliminary Analysis Step.

Affecting Factors

Organizational. Scope

Importance

Organizational Maturity

Information Policy

Structuredness Level

Technological Environment

Development Type

LOW

1

very narrow

very low

very familiar

fully centralized

fully structured

very common

minor change; bug-fixing

2

narrow

low

familiar

centralized

mostly structured

j commor 1 new version of a canned package

SCALE

3

normal

normal

not so familiar

partly distributed

normal

common and new

modifications to an existing system

4

broad

high

unfamiliar

distributed

mostly unstructured

mostly new

new canned package

HIGH

5

very broad

very high

extremely novice

fully decentralized

very unstructured

extremely innovative

new in-house development

Table 3 presents Form 2, which helps in planning the entire life cycle as well as each individual ver- tical step of the ISDLC. Form 2 is a simple tool that assists the evaluator in expressing his or her impressions regarding the horizontal dimension in each ISDLC step. In the two leftmost columns, there is a list of the affecting factors and their marks (between 1 and 5, as determined in the respective Form 1). In the other columns, the evaluator is supposed to write, qualitatively, the effect of each factor on the dimensions of ac- tivities, control, human resources, non-human resources, and time. The evaluator should fill out one Form 2 for each step of the entire project.

Upon completion of a step, the entire set of Form 2’s is to be reviewed and revised. Every review of that kind provides a ‘fresh’ view of the entire pro- ject. The two lines at the top of Form 2 serve to indicate at which step the form is filled out and to what step it pertains.

Table 3 reflects the wholesale firm case presented above. It illustrates the way Form 2 was filled out by the evaluator during the preliminary analysis step regarding the feasibility

study step. This is, in fact, a preconception of a step before it starts (note that the marks were taken from Form 1 in Table 2).

Form 2 has to be filled out for each step. The ag- gregation of the forms (qualitatively, not mathematically) gives the evaluator some ideas about the nature of the ISDLC for this particular project at each given step.

It is very important to note that the procedures presented here are based on an iterative pro- cess. The first time the set of forms is filled out is during the preliminary analysis step. Subsequent- ly, whenever a step or a major activity is com- pleted, re-evaluation should take place culminating in a revised set of forms. Thus, the suggested procedures serve for planning as well as for audit and review purpose.

Conciuding Remarits The process of developing information systems is, in practice, not as rigid as most MIS literature

MIS Quarterly/June 1984 75

information Systems Deveiopment

a0) W M *M ,>• (S c

a a> 55

‘ (0

E

O) c

du r

lie d

ib il

<0 (S

au. o T3 a>

el at

u

u

u a

CM

E ou.

“Q. E (D

<

tn

,1 (0 c (1>

Q

25o Q.

LL O) C

I

Ii c CO o a> Z OC

CO

o

11 I CC

C 7-

£ 0,I o

,-t: JO

CO CO C <a CO CO a>

a T3 « X c

, b CD CO

^ 1 S i ° o 3

a is

S B

oo 0) „- 55

g

Q. CO “O

E ^ 2 0) O CO

CO

g

CO O

T3

o D O •- E o C CO O)

T3 -Q ^ § CO m

O (B £

isz CO Q, C

e <o O 2 O 3 CD ,-= T3 C ™ ai C3

– 6 • <“o i: 0) -g C Q, ._: ,E

O :S C3) CO c r̂- ^ 9’ C T3 CO O d)

*O .— ^3

(U

o CO

CO T3 >< C CD 3

P -s

c CO

” i c CO a S >3 x 2 =

0 CD ^

ro •§ -o Jg

LU a S .yO Q)

,= d) 3

“D CDc o o ,n CO d)

CO C c Q, ,fc S , . E M-

(B U O o iS E M- *- CO (B CU O

“‘ u d) aCO o <” <” Pa ,2 c CO ,9

CO

I

d) O —

‘ CO “a CO D

o a>a > ^ XI

E 0. ro Q CO oj m E

ro

XJ d>

N

O C

a> d>

,E ,E «

CO

cg

I

76 MIS Quarterly/June 1984

Information Systems Development Id

n’ t

0

to

‘c to

‘o c

TJ

§ O)

tu c

.2

O • D

ne ed

t

o

o , __

3

‘o3 ‘to

m uc

h

_2 iS

ia n;

o ‘c •g

B

_to

ck te

a

o

•ĝ

tu tu TD

2 •c tu tu c

to

ne s

• D

ru ct

ur

iv e

to d

er tir

to

d fo

r

o C

c

in gs

fin d

o c S2 (1)

Q)

§ C

Le ve

i

‘is

o

lis t

le ci

a

u.

w

o

^ .

.9

c

re m

en iq

ui

tu

‘to to

E 2O) ^ 2 ro’

C/) o ‘5 ‘a £

‘o tuIS

ou

‘c

re le

va

‘5 c

eo ne

so m

tu T3 .2

ef ul

ck c

ar

o

o

O)

em is

ob i

o

te le

to

o c

o

E

‘ if

th e

on iy

‘3 O”

0

$

CM

ca i

ch no

l” pa

te d

Iti ci

i_ to

io n

ni ca

t

3

E 0 0

g a>

id s

jm m

er

S

‘to .y c tu

0

• –

‘c tu

1 1

lin e

c 0

ln ol

og te

c^

to

a>

tim :

ta ke

a E

vi de

0

°-

E

s c

“o

I co

nt r

tig ht

to

£ to

tu

rv ey

t l

0

tin g

to

B

0

to 0 0

ib Ie

r po

ss ov

ei

Q

ar l

‘c

E

iv el

op

lit ie

s

0

w ar

e so

ft

• Q

0

to

<a ge

s; pa

d

to tu O)

0

‘^

ly p

e tu to c tu C O) to to 0 .ic k_ 0

£ D.

ap s

“o

tends to imply. There are two categories of fac- tors affecting the ISDLC — those derived from the user and the environment and those derived from the nature of the development process itself. The ISDLC of a specific project should reflect these affecting factors. The ISDLC is not seen as a se- quence of steps (though some of them may be iterated), but as a breakdown of each step (or blowup of each step) into various dimensions af- fected by the factors. These factors vary among projects and among the steps of any given pro- ject. The amount of effort invested in each step and in each project can be better planned and controlled by assessing the intensity of the fac- tors not only along the vertical progression from step to step, but also along the horizontal dimen- sion of activities within a step.

The ISDLC should be viewed as a superproject, where each of its traditionally described steps is a project in itself. Instead of a vector of steps, it is, in effect, a matrix of vertical steps and horizontal activities. The contents of the elements of the matrix are affected by the above mentioned fac- tors and may change during the development period. A set of forms has been provided to enable management, users, and MIS profes- sionals to realize the suggested treatment of the ISDLC as a flexible and dynamic process rather than as a straightforward uniform process that is suitable for all information systems development projects. An additional advantage of the forms and the deliberations concerning them is that they provide a communications tool for management, users, and IS professionals. While users frequent- ly operate in a reactive or passive role, in tradi- tional development approaches our approach forces the user to assume a more active role in the process.

References

[1 ] Ahituv, N. and Neumann, S. Principles of In- formation Systems for Management. William C. Brown, Dubuque, Iowa, 1982.

[2] Blumenthal, S.C. Management Information Systems: A Pramwework for Planning and Development, Prentice-Hall, Englewood Cliffs, New Jersey, 1969.

[3] Buchanan, J.R. and Linowes, R.G. “Understanding Distributed Data Process-

MIS Ouarterly/June 1984 77

Information Systems Deveiopment

ing,” Harvard Business Review, Volume 58, Number 4, July-August 1980, pp. 143-153.

[4] Buchanan, J.R. and Linowes, R.G. “Making Distributed Data Processing Work,” Har- vard Business Review. Volume 58, Number 5, September-October 1980, pp. 143-161.

[5] Ein-Dor, P. and Segev, E. Managing Management Information Systems, Lex- ington Books — D.C. Heath and Company, Lexington, Massachusetts, 1978.

[6] Gibson, CF. and Nolan, R.L. “Managing the Four Stages of EPP Growth,” Harvard Business Review, Volume 52, Number 1, January-February 1974, pp. 76-88.

[7] Gremillion, L.L. and Pyburn, P. “Breaking the Systems Development Bottleneck,” Harvard Business Review, Volume 61 , . Number 2, March-April 1983, pp. 130-137.

[8] Lucas, H.C. Why Information Systems Paii, Columbia University Press, New York, New York, 1975

[9] McFarlan, F.W. “Portfolio Approach to In- formation Systems,” Harvard Business Review, Volume 59, Number 5, September-October 1981, pp. 142-150.

[10] McFarlan, F.W., McKinney, J.L., and Pyburn, P. “The Information Archipelago- Plotting a Course,” Harvard Business Review, Volume 6 1 , Number 1, January- February 1983, pp. 145-156.

[11] McKenney, J.L. and McFarlan, F.W. “The Information Archipelago-Maps and Bridges,” Harvard Business Review. Volume 60, Number 5, September- October, 1982, pp. 109-119.

[12] Sprague, R.H. and Carlson, E.D. Building Effective Decision Support Systems, Prentice-Hall, Englewood Cliffs, New Jersey, 1982.

About the Authors Niv Atiituv is a senior lecturer in the facuity of management at Tel-Aviv University. Formerly he lectured at the University of Calgary and at the University of British Columbia. He also managed the DP department at the Bank of Israel. He holds a B.Sc. in mathematics, and a MBA, a M.Sc. and a Ph.D. in information systems. His articles have appeared in Computers and Operations Research, The Computer Journal, Information and Management, MIS Quarterly, Interfaces, Decision Sciences, and the Journal of Systems Management. His main areas of interest are economics of computers, information economics, and information systems management and development.

Michael Hadass has a Bachelor of Science degree from the Technion in Haifa. Israel, and an MBA degree from the University of Paris. He is currently a program manager in the IBM european headquarter in Paris. His previous position was in- formation Systems Department Manager in iBM- Israel. At the same time, for ten years, he lectured on information systems anaiysis at the University of Tei-Aviv.

Seev Neumann is a visiting professor at the Graduate Schooi of Administration, University of California-Davis. He is a professor of information systems at Tel-Aviv University, Israel. He has authored and co-authored four books and various papers in the fields of MiS and computer economics. His most recent book (with Niv Ahituv), Information Systems Principles for Management, was pubiished in 1982.

78 MIS Ouarterly/June 1984


Comments are closed.