Attributes of Information System Development

Author(s): Hugh F. Juergens

Source: MIS Quarterly, Vol. 1, No. 2 (Jun., 1977), pp. 31-41
Published by: Management Information Systems Research Center, University of Minnesota
Stable URL: http://www.jstor.org/stable/249166
Accessed: 01-10-2015 03:32 UTC

Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at http://www.jstor.org/page/
info/about/policies/terms.jsp

JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide range of content
in a trusted digital archive. We use information technology and tools to increase productivity and facilitate new forms of scholarship.
For more information about JSTOR, please contact support@jstor.org.

Management Information Systems Research Center, University of Minnesota is collaborating with JSTOR to digitize,
preserve and extend access to MIS Quarterly.

http://www.jstor.org

This content downloaded from 200.21.227.154 on Thu, 01 Oct 2015 03:32:16 UTC
All use subject to JSTOR Terms and Conditions
 Information System Development

While numerous computer-based information

Attributes of systems have been developed and are in operation
there is no unified or commonly accepted theory to
Information System guide the development process. If there were such a
theory, I suspect that a higher proportion of these
Development systems would be deemed successful [see 16, 20]
and the systems would be more readily adaptable
By: HUGH F. JUERGENS to change with a corresponding reduction in the
high cost of maintenance.
This paper draws upon a variety of sources in an
effort to integrate much of the current thinking on
the information system development process. A
general model of the development process is
presented to provide increased understanding of
the effect that this process has upon the
characteristics of the resulting system. The concept
of decoupling is introduced as a framework for
guiding the development process toward
achievement of the system's desired capabilities,
while recognizing and planning for the
accommodation of change.

Abstract
Computer-based information systems too often do not
satisfactorily meet the information needs of users and are
inflexible in accommodating change. Because change is
inevitable for any system, a framework for viewing the
information system development process which takes
this into account is necessary. The concept of decoupling
as a framework which seeks to minimize the adverse
consequences of change is discussed in this article.
Keywords: Development objectives, development methodology,
development process information system structure,
systems approach, decoupling.
Categories: 1.3, 2.4, 2.43, 3.5, 4.0
Attributes of an
Information System
The criteria by which the attributes of a system can
be evaluated are presented first in order to provide
a perspective from which the system development
process can be evaluated. These criteria are user-
oriented and fall into the broad categories of
effectiveness and cost. The effectiveness attribute
has to do with the ability of the system to satisfy the
users' needs and gives an indication of the benefits
or value provided by the system. Cost, on the other
hand, constrains the development of the systems.
Primary attention in this article will be directed
toward the effectiveness with which the system
satisfies users' needs. Ideally, desired attributes of
the system are specified prior to the development
of the system and become objectives that are used
to guide the development process.
System effectiveness
System effectiveress has three dimensions:
capability, stability, and adaptability [3].
Capability refers to the ability of the existing
system to satisfy the information needs of the
operations and decision-making functions in the
organization. As such, we can look at the outputs
of the system and compare them with what is
needed. Several aspects of capability include the

MIS Quarterly/ June 1977 31

This content downloaded from 200.21.227.154 on Thu, 01 Oct 2015 03:32:16 UTC
All use subject to JSTOR Terms and Conditions
 Information System Development
ability of the system to perform its intended
functions by providing the necessary output and
the relevance of the output in satisfying the needs
of the users. The fact that "well functioning"
systems have unsatisfied users, as described by
McKinsey and Company [16] and Powers and
Dickson [20], gives rise to this distinction between
the two similar views of capability. For example, in
the absence of user participation when defining the
content and format of reports, the development
personnel may define the output in terms that may
be difficult for the users to understand, even
though all the necessary information may be
present. Other aspects of capability include the
accuracy and timeliness of the system's outputs.
Stability and adaptability refer tofuture capability
and are intended to protect the organization's
information system investment. Stability is the
degree to which the capability of a system persists
through changes in the system's non-user
environment. In other words, if the capabilities of
the system remain intact through variations in the
workload, changes in the hardware and hard-
software (e.g., operating system, compilers, data
management systems, etc.), and changes or
additions to other application programs and files,
then the system may be said to be highly stable.
Adaptability, on the other hand, is the degree to
which adjustments to the system can be made as a
result of changes in the user environment. An
example is the ease with which changes in the
information needs of the users can be incorporated
into the system.
System Cost
The attribute of cost refers to the expenditure of
resources during the development, operation, and
maintenance of the system in order to provide the
degree of desired effectiveness. The most visible
resource, capital, is manifested in the information
system organization through hardware, software,
personnel, and supplies.
Theoretically, both the benefits and costs can be
stated in terms of a single quantity, such as dollars,
whose value is to be optimized. It is the
responsibility of the development personnel to
produce the optimum system. Unfortunately many
of the benefits and costs cannot be quantified or
measured a priori. It is not possible to determine
meaningfully if a system will adequately meet user
needs until after it is in use, given the present state
32 MIS Quarterly/ June 1977
This content downloaded from 200.21.227.154 on Thu, 01 Oct 2015 03:32:16 UTC
All use subject to JSTOR Terms and Conditions
of the art. Even then, placing a value on improved
decision-making or increased customer goodwill is
difficult, if not impossible. Benefits associated with
the provisions for achieving stability and
adaptability are not realized until the changes
become imminent, and the danger still exists that
the provisions are not adequate due to unforeseen
circumstances. Yet, resources are expended to
"ensure" the effectiveness of the system before its
value is proven.
It is a risky venture to provide for the dimensions
of capability, stability, and adaptability. This risk
has two distinct, opposite sides: excessive costs are
incurred both by providing capabilities that are not
needed or by failing to provide required
capabilities. It is in the context of this uncertainty
that the planning and development of an
information system takes place.
Conflict exists between the objectives themselves
and the means for achieving them. For example,
there are several ways in which the cost of
developing a system can be reduced. One
alternative is to decrease one or more of the
dimensions of effectiveness, e.g., eliminating some
of the desired capabilities or reducing the
documentation effort. Such means of achieving a
cost reduction may be unacceptable if the
objectives for the system have already been set.
They have often been used as a short-run measure
to cut costs in a project and are symptomatic of
inaccurate initial estimates and an inflexible
project control system [20].
Development Process
Traditionally, the system development process
within the system life cycle has been described as a
series of chronological phases or stages [5, 18].
Different authors have diverse labels for the stages
and have varying conceptions of what must be
done in each stage. Each of these approaches has
its own merits. A "new"series of stages, as such, is
not presented in this paper. Viewing the
development process at the system level as
definition, design, and construction can draw these
approaches together.
Definition
During the definition stage, the information
system is placed into the organizational context. It
is in this stage that the objectives or desired

attributes of the system are defined and the
boundaries for the system are delineated. The
result of the analysis forms a set of requirements
which include a definition of the overall functions
to be performed, system inputs, system outputs,
performance, and integrity.
Design
The design stage is concerned with translating the
requirements for the system into specifications for
providing the needed capabilities. One common
practice associated with system design, especially
when dealing with large-scale systems, is the
factoring of the system into subsystems; each of
these subsystems is in turn further factored into
subsystems. In this manner, the amount of detail
that must be analyzed, assimilated, and
synthesized at any one point in time is reduced. The
underlying logic of this approach is that each of the
subsystems is easier to handle than the system of
which it is a part, the subsystems can be handled
somewhat independently, and ultimately the
subsystems can be recombined or joined in a
straightforward manner to form the complete
system [10, 12, 13, 15].
The design process for a system consists of
understanding the context of the system with
respect to its implications for the super-system of
which it is a part:
* factoring the system into more manageable
and somewhat independent subsystems,
* specifying the requirements to be
accomplished by each subsystem, and
* specifying the interfaces between the
subsystems.
Together with the interface specifications, the
design stake results in the definition stage for each
of the subsystems. Each of these subsystems
becomes the system of concern when it goes
through its design stage. The factoring process
continues with increased refinement at each level
and is increasingly aimed at the "mechanics" of
how the system will function in the hardware and
in manual procedures. It continues until the
system's objectives are refined into a form that can
be understood by the computer, whether in a
higher level language, such as COBOL, or an
assembly language. Figure 1 illustrates the
decomposition process.
A production control system, for example, might
begin with an overall objective of achieving better
This content downloaded from 200.21.227.154 on Thu, 01 Oct 2015 03:32:16 UTC
All use subject to JSTOR Terms and Conditions
Information System Development
control over the costs of production and increased
responsiveness to customer demand. As shown in
Figure 2, it may be initially comprised of
forecasting, production scheduling, purchasing,
raw material inventory control, and finished goods
inventory control subsystems. Each of these
subsystems may be factored further into
subsystems based upon differences in function or
in the timing of inputs or outputs. Within each of
these subsystems or processing cycles, programs
may be identified for purposes such as input
editing, file update, and reporting. Each of the
programs is subdivided further according to
functions performed such as input, output, and
type of calculation. Modules are further factored
and refined into submodules until subroutines are
identified and finally the individual logic elements
that eventually result in programming language
statements are identified.
The arrows in Figures I and 2 identify the
interfaces between subsystems and represent the
flow of data. At the upper levels, this data will, for
the most part, be contained in files although each
arrow does not necessarily represent a single file
[13, 14]. At the lower levels, data will be passed
from one routine to another in central memory.
Construction
The construction stage is concerned with
translating the system's specifications into the
means for providing the identified capabilities. At
each level in the hierarchical structure,
construction consists of providing the interface
between the subsystems and determining when
each subsystem should be executed.
There are two schools of thought regarding how
construction should be integrated with the design:
top-down design with bottom-up construction, or
top-down design with top-down construction.
These two approaches are illustrated in Figures 3
and 4. In bottom-up construction, the lowest level
subsystems are constructed first and tested. The
next higher level is concerned with providing the
necessary logic to coordinate their execution. This
portion of the complete system constructed thus
far is then tested. Construction in this manner
proceeds up through the hierarchy until the entire
system has been completed [2, 8, 19].
In top-down construction, the sequence of events is
essentially reversed. Thus, at a given level in the
MIS Quarterly/ June 1977 33
 Information System Development

Level 0:

Level 1:

Level 2: -

Level 3:

Figure 1. Hierarchical Network Structure

34 MIS Quarterly / June 1977

This content downloaded from 200.21.227.154 on Thu, 01 Oct 2015 03:32:16 UTC
All use subject to JSTOR Terms and Conditions
 Information System Development

Raw Material Receipts

Shipments-Production ... Purchase Orders
Customer DemandControl _ Current Production Status
Customerg
Demand System Production Schedule
Engineering Specs R

al \
Maintain Maintain Prepare
Finished Raw urchase
Goods Material Purchase
Inventory Inventory Orders Orders

]r ^^^. \ \ T ICurrent
Forecast Schedule Status
Demand ,, Production
Demand __-- Production
lg /7~ ' Schedule
lg - F,'

Finished S
Raw Raw- '
Finished Material Material
Goods .. j On Hand Usa

Determine Monitor Current

Raw Current Production
hled MaterialOptOperations Status
ds IAvailabilit
and t

Determine Determine Determine

id - Finished - Total Mfg. Master - Production
Goods
st Requirements Requirements Schedule Schedule

Determine
_- / Parts
ng 1 E Capacity
Exposion
Availability
/
/ Raw \
/ Material Finished
/ Usage Goods

Calculate Maintain Current

Material e Work In - - Production
lUsa e Prncess Status

Work In Time
Process Usage

Figure 2. A Partial Example of the Hierarchical Network Structure

for a Production Control System

MIS Quarterly / June 1977 35

This content downloaded from 200.21.227.154 on Thu, 01 Oct 2015 03:32:16 UTC
All use subject to JSTOR Terms and Conditions
 Information System Development

Level 0: Construct - O perate

Level 1:
I
Define 1 Design -_ Construct

Level 2: Define -^ Design

I

Level n: Define Design Construct

Construct

Figure 3. Top-Down Design With Bottom-Up Construction

Level 0: Define mDesign ,m Construct

Level 1:
I
Define ,Construct
Design

Level 2: Define - Design Construct

Level n:
\
Define
\
Design mm Construct m,Operate

Figure 4. Top-Down Design With Top-Down Construction

36 MIS Quarterly / June 1977

This content downloaded from 200.21.227.154 on Thu, 01 Oct 2015 03:32:16 UTC
All use subject to JSTOR Terms and Conditions

hierarchy the subsystems are defined and the
interfaces and coordination are constructed and
tested before the subsystems themselves are
designed and constructed [2, 4, 19].
Attributes of the
Development Structure
The structure of the system development process
can be viewed both as a hierarchy and a network,
as shown in Figure 1. There is a hierarchical
relationship between a system and its subsystems
and there is a network relationship among the
subsystems.
Vertical decoupling
The hierarchical relationship between a system and
its component subsystems may at times be
clouded. For example, development personnel
may be satisfied with an intuitive feeling regarding
the objectives for a subsystem before proceeding
down to another level in the hierarchy. If one
proceeds in this manner, the link to the overall
system objectives becomes nebulous and
formalization of objectives and subsystem
structure at the lower level becomes more difficult
because of the greater amount of detail that must
be assimilated.
If an effort on the other hand is made at each level
in the hierarchy to formalize the objectives and the
interface between the lower level subsystems, a
clearer distinction will exist between successive
levels. The extent to which this distinction exists is
referred to as the degree of system/subsystem or
vertical decoupling. A high degree of vertical
decoupling implies that there is a logical separation
between subsystems at adjacent levels in the
hierarchy from the standpoint that firm objectives
are set forth for each subsystem prior to its
development. Hence, the definition of objectives
for a higher level system exerts a binding influence
on the lower level subsystems. The capability of the
system will be enhanced if the developmental
efforts at each level are focused on the
accomplishment of a unified purpose.
Tangible evidence of vertical decoupling in the
development process takes the form of
documentation and checkpoints. Periodically we
stop to summarize what has been done and what
This content downloaded from 200.21.227.154 on Thu, 01 Oct 2015 03:32:16 UTC
All use subject to JSTOR Terms and Conditions
Information System Development
will be done next. Checkpoints can be predefined:
the development process can be viewed as a
chronological series of phases or stages [5]. Other
checkpoints may arise spontaneously: top-down
program design or stepwise refinement can be used
in program development [2, 4, 24, 25].
System/subsystem decoupling does not imply that
a system is independent of its subsystems. Quite the
contrary, it is because of the dependence of a
system's effectiveness upon the effectiveness of its
subsystems that this separation should occur. This
allows development personnel to formulate
explicitly the objectives for each subsystem. Such a
formalization forms a basis for discussion with the
users to confirm or revise the system objectives and
provides a mechanism for recording the many
details of the design. Additionally, control over the
development process occurs through a comparison
of the objectives for each subsystem with its design.
The definition of the lower-level subsystems,
during the design of a higher-level subsystem,
resembles the "black box" concept in which the
inputs and outputs of a subsystem are defined, but
the details for accomplishing the transformation
are left undefined. We should concentrate on
specifying realistic objectives for subsystems at
succeeding levels and not become embroiled in the
details of how the objectives will be accomplished.
Decisions regarding the actual functioning of a
system should be made only at the level in which
the detail can be placed into perspective and can be
understood and properly evaluated. In the
previously mentioned production control
example, if a variation of the classic economic
order quantity formula [6] is used, we do not need
to derive the specific formula until we design the
module that will calculate it. Prior to this point, all
that need be known is that the quantity will be
determined by minimizing the appropriate costs.
It should be noted that no general guideline can be
established for the number of levels in the system
structure. The factoring process should result in a
tractable set of subsystems for the development
personnel. The tractability depends upon the skill
and experience of development personnel and the
scope and complexity of the system. Some insight
into the problem of tractability for both the
management of the development effort and for the
actual development can be found in the literature
[2, 17, 23].
MIS Quarterly/ June 1977 37
Information System Development
Horizontal decoupling
A network structure, as shown in Figure 1, can be
used to depict relationships among subsystems at a
given level in the hierarchy. Horizontal or
subsystem/subsystem decoupling refers to the
degree of independence among subsystems in the
network. The rationale for this form of decoupling
is primarily to enhance the stability and
adaptability of the resulting system by isolating the
impact of potential sources of change upon the
system.
This independence can be achieved in two ways.
First, the number of interconnections among
subsystems can be minimized. Hence, need for
communication and coordination is reduced. This
can be done by an appropriate choice of subsystem
boundaries so that the number of interconnections
is reduced, or by defining a special interface among
subsystems or clusters of subsystems. An example
of this latter approach is the use of database
management systems. Data independence is the
term used in the database management literature
for decoupling [1, 9, 11].
A second means of achieving horizontal
decoupling is to minimize the degree of
interconnection. The subsystems should not make
assumptions about the internal workings of other
subsystems to achieve a high degree of
independence. Even though certain assumptions
may be valid at one time, changes to a subsystem
can impact other related subsystems. This means
of horizontal decoupling is aided partially by
vertical decoupling and by specifying the functions
to be performed by each subsystem and deferring
the decisions regarding the means for
accomplishing the intended functions. For
example, Myers [19] has identified six degrees of
interconnection between program modules
ranging from content coupling (lowest or worst
decoupling) whereby modules refer directly to the
contents of other modules (e.g., to modify a
program statement) to data coupling (highest
decoupling) whereby all data elements input and
output of a module are passed as arguments and
the arguments are not used to control execution
(e.g., flags).
Development structure overview
Besides enhancing the various dimensions of
system effectiveness, horizontal and vertical
decoupling are also of benefit in simplifying the
38 MIS Quarterly/ June 1977
This content downloaded from 200.21.227.154 on Thu, 01 Oct 2015 03:32:16 UTC
All use subject to JSTOR Terms and Conditions
development process and in providing greater
flexibility in scheduling the development efforts.
Simplication of the development is achieved by
reducing the amount of detail that must be
comprehended at any one point in time.
Scheduling flexibility is achieved by permitting
both concurrent development and implementation
of subsystems so that partial capabilities within a
long-term plan can be achieved.
Two problems associated with both vertical and
horizontal decoupling are the cost of the
decoupling mechanism itself (e.g., documentation
and database management systems) and the
potential for suboptimization. The alternative to
decoupling, however, is to stretch people's ability
to perceive the masses of detail beyond their
relatively narrow limits. We have to be content to
tackle a large-scale problem a little at a time, until
computers are used more effectively to automate
the development process [21, 22].
Factors to Consider
in the Implementation
of Decoupling
Viewing the development process in terms of the
system life cycle may lead the reader to the
conclusion that system development is sequential
in nature. That is, first the system proceeds
through the definition stage, then the design stage.
the construction
and finally stage.
Chronologically, this may be true. However,
recursion, parallelism, and iteration are inherent in
the development process.
Recursion
Recursion in the development process is
exemplified by the fact that at each level in the
development hierarchy, the overall methodology is
the same, although the orientation and details of
implementing the methodology differ. For
example, the upper levels in the hierarchy are
directed more toward the overall problem to be
solved and hence are oriented to the users and
involve interpersonal skills. The lower levels are
directed toward the computer and the physical
realization of the system in hardware and software.
The development of a subsystem at any given level
in the hierarchy is in general concerned with
obtaining, understanding, translating, and
communicating information. Information is

obtained about the plans of higher levels in the
hierarchy, because it is these plans that set the
objectives for the subsystems. The technology
available to the information system sets
constraints with respect to what can be done. The
environment, which may include other existing
information systems, may also set constraints on
the development. The people who will eventually
be involved with the system, whether they are the
users of the output or preparers of the input, add
information that will help in further refining the
system. Achieving an understanding through
analysis goes hand-in-hand with obtaining the
information; analysis of the information may point
to the need for more information. Design consists
of translating the results of the analysis into more
detailed and specific plans which form the
objectives for the lower level subsystems. These
plans are then communicated to prior phases for
review (feedback) and to subsequent phases for
further development (feedforward).
This indicates that the system designer, in addition
to addressing a current subsystem level, should
think both up one level and down one level in the
hierarchy. Looking at the higher level allows the
system to be viewed in its context within a broader
perspective. The designer should think down one
level because that is the object of his development
efforts. Often, lower levels will set constraints upon
the activities at a higher level, such as the
capabilities of existing hardware.
Parallelism
Parallelism in the development process indicates
that the subsystems, at any given point in time,
may be in different stages of completion; some
subsystems may be in the definition stage, others in
the design stage, and yet others in construction.
This parallelism adds scheduling flexibility to the
development process so that partial capabilities
within a long term plan can be provided.
Alternatively, devoting resources to different
subsystems concurrently may reduce development
time. The degree of parallelism that can exist
depends upon the degree of vertical and horizontal
decoupling that is present.
Iteration
Iteration acknowledges the fact that the objectives
of a system, and in turn the subsystem objectives,
may not be completely defined and may even
This content downloaded from 200.21.227.154 on Thu, 01 Oct 2015 03:32:16 UTC
All use subject to JSTOR Terms and Conditions
Information System Development
change during the development of the system. As
we proceed further into development, insight on
the part of the development personnel is gained
into the properties of the system. Alternatives may
be evaluated: inconsistencies, errors, omissions,
and other desirable but unprovided capabilities.
The users similarly through participation can be
expected to gain increased awareness of (1) their
information and decision making environments,
and (2) the capabilities and limitations of
computerized information processing [20]. These
factors all indicate that it may be necessary to go
back a level in the hierarchy to refine the plans for
the lower level.
A high degree of vertical decoupling facilitates
iteration between levels. Even though the
objectives are subject to change, a clear statement
of the objectives for each subsystem is necessary to
track their evolution and signal any change.
Otherwise there is a risk of having implicit
objectives for each subsystem that reflect
assumptions on the part of the development
personnel rather than having explicit objectives
formulated in the context of the overall system. On
the other hand, having a well documented but
inflexible set of objectives can be just as
dysfunctional as vague objectives. An
unsatisfactory system may result by not taking
advantage of the insight gained through the
development efforts by the users and development
personnel.
Some iteration is seen to be of a rather informal
nature: i.e., iteration that is carried out as the need
arises. On the other hand, some may be of a formal
nature: i.e., iteration that is carried out as the need
arises. On the other hand, some may be of a formal
to either continue, revise, or discontinue the
project. While it may seem desirable to have a
number of these checkpoints to maintain close
control, whatever parallelism exists in the
development up to a checkpoint must halt and
activities that lag behind must be allowed to catch
up to the early finisher.
The preceding discussion focused on iteration
between levels. Iteration is also experienced in the
development efforts of each subsystem. For
example, one must obtain information about the
subsystem before it can be analyzed. However, this
analysis may point to the need for additional
information. Similarly, analysis of the subsystem
precedes its design, but along with design comes
MIS Quarterly/ June 1, 1977 39
 Information System Development
increased understanding of the subsystem which
may point to the need for further analysis; this, in
turn, may require additional information, etc.
The amount of iteration experienced in system
development depends upon the degree to which the
system fits into existing molds and the extent to
which development personnel recognize and are
able to take advantage of the correspondence. For
example, developing a payroll system may involve
little iteration whereas a system to furnish a
manager with information needed to support
decision-making activities may require extensive
iteration.
Conclusion
systems are
Many current information
unsuccessful in that they do not adequately satisfy
user needs and are inflexible when change is
required. Part of this problem occurs because
information s, stem development is frequently
viewed as strictly a technical activity and, as
designers, we often are in too much of a hurry to
delve into the details of the system and produce
tangible evidence of our labor (e.g., computer
programs).
Computer science has recognized this problem for
some time now. As a result, techniques such as
structured programming, modular programming,
top-down program design, and HIPO increasingly
are being accepted and used. All these techniques
for forcing disciplined creativity incorporate the
concept of decoupling and are oriented more
toward the lower levels in the development
hierarchy. Reported benefits of these approaches
include reduced development time and cost,
increased quality of programs, and reduced
maintenance [2].
Recursion, as discussed in this article, suggests that
decoupling is equally valid at the upper levels. The
potential benefits, in fact, may be much greater
given that we are trying to minimize the risk of
developing wrong, inadequate, or inflexible
systems as we venture into the vague area of
improved decision support for management.
Decoupling supports an iterative approach for
determining the desired capabilities of the system
by requiring a formalized, yet tentative,
specification of objectives at each step of
development for feedback to stimulate user
involvement and to guide further development
efforts. Thus, it helps to prevent design decisions
40 MIS Quarterly / June 1, 1977
This content downloaded from 200.21.227.154 on Thu, 01 Oct 2015 03:32:16 UTC
All use subject to JSTOR Terms and Conditions
that could yield unexpected and undesirable
properties for the system. Further, decoupling
recognizes the inevitability of change and in
essence strives to minimize its adverse
consequences by planning for change.
References
[1] ANSI/X3/SPARC Study Group on Data Base
Management Systems. "Interim Report," EDT, Vol. 7, No.
2, (75-02-08), pp. 1-140.
[2] Aron, Joel D. The Program Development Process: The
Individual Programmer, Reading, Mass., Addison-
Wesley, 1974.
[3] Ashenhurst, R. L. (ed.). "Curriculum Recommendations
for Graduate Professional Programs in Information
Systems," A report of the ACM Curriculum Committee on
Computer Education for Management, Communications
of the ACM, Vol. 15, No. 5 (May 1972), pp. 363-398.
[4] Baker, F. Terry. "Chief Programmer Teams Management
of Production Programming," IBM Systems Journal, Vol.
11, No. 1 (1972), pp. 56-73.
[5] Benjamin, Robert I. Control of the Information System
Development Cycle, New York, Wiley, 1971.
[6] Buffa, Elwood S. Operations Management: Problems
and Models, New York, Wiley, 1972.
[7] Canning, Richard G. (ed.). "That Maintenance'Iceberg',"
EDP Analyzer, Vol. 10, No. 10 (October 1972).
[8] Canning, Richard G. (ed.)., "The Search for Software
Reliability," EDP Analyzer, Vol. 12, No. 5 (May 1974).
CODASYL Systems Committee. Feature Analysis of
[9]
Generalized Data Base Management Systems, New York,
Association for Computing Machinery, May 1971.
[10] Davis, Gordon B. Management Information
Systems: Conceptual Foundations, Structure, and
Development, New York, McGraw-Hill, 1974.
[11] Everest, Gordon C. "Managing Corporate Data
Resources: Objectives and a Conceptual Model of
Database Management Systems," Unpublished Ph.D
dissertation, University of Pennsylvania, 1974.
[12] Johnson, Richard A.; Kast, Fremont E.; and Rosenzweig,
James E. The Theory and Management of Systems, 3rd
edition, New York, McGraw-Hill, 1973.
[13] Langefors, Borje. Theoretical Analysis of Information
Systems (2 vol.), Lund, Sweden, Studentlitteratur, 1970.
[14] Langefors, Borje and Sundgren, Bo. Information Systems
Architecture, New York, Petrocelli, 1975.
[15] Machol, Robert E. and Miles, Jr., Ralph F. "The
Engineering of Large-scale Systems," in Systems
Concepts: Lectures on Contemporary Approaches to
Systems, Ralph F. Miles, Jr. (ed.), New York, Wiley, 1973,
pp. 33-50.
McKinsey & Comany, Inc. "Unlocking the Computers
[16]
Profit Potential," Computers and Automation, April 1968.
[17] Miller, George A. "The Magical Number Seven, Plus or
Minus Two: Some Limits on our Capacity for Processing
Information," The Psychological Review, Vol. 63, No. 2
(March 1956), pp. 81-97.
[18] Murdick, Robert G. "MIS Development Procedures,"
Journal of Systems Management, Vol. 21, No. 12
(December 1970).
[19] Myers, Glenford, Jr. Reliable Software Through
Composite Design, New York, Petrocelli/Charter, 1975.
 Information System Development

[20] Powers, Richard F. and Dickson, Gary W. "MIS

Project Management: Myths, Opinions, and Reality,"
California Management Review, Vol. 15, No. 3 (Spring
1973), pp. 147-156.
[21] Prywes, Noah S. "Automatic Generation of Software
Systems," Data Base, Vol. 6, No. 2 (Summer 1974), pp. 7-
17.
[22] Teichroew, Daniel and Sayani, Hasan. "Automation of
System Building," Datamation, Vol. 17, No. 16(August 15,
1971), pp. 25-30.
[23] Urwick, Lyndall F. "The Managers Span of Control"
Harvard Business Review, Vol. 34, No. 3 (May-June 1956).
[24] Wirth, Niklaus. "Program Development by Stepwise
Refinement," Communications of theA CM, Vol. 14, No. 4
(April 1971), pp. 221-227.
[25] Wirth, Niklaus. "On the Composition of Well-structured
Programs," Computing Surveys, Vol. 6, No. 4 (December
1974), pp. 347-259.

About the Author

Hugh F. Juergens is an Assistant Professor of MIS
in the Quantitative Analysis Department at the
Graduate School of Business, University of
Wisconsin - Madison. He received his B.S., M.S.,
and Ph.D. in MIS from the University of
Minnesota. He previously taught at the State
University of New York at Binghamton and was
formerly an Applications Analyst for Control
Data Corporation. Professor Juergens is currently
engaged in research on Database Design.

MIS Quarterly/ June 1977 41

This content downloaded from 200.21.227.154 on Thu, 01 Oct 2015 03:32:16 UTC
All use subject to JSTOR Terms and Conditions