Documente Academic
Documente Profesional
Documente Cultură
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
Attributes
of
Information
System
Development
By: HUGH F. JUERGENS
Attributes of an
Information System
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:
Categories:
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
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
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
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
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
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
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
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
Level 0:
Level 1:
Level 2: -
Level 3:
Figure 1.
34
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
al
Purchase Orders
...
Shipments-Production
_
System
R
\
Maintain
Maintain
Goods
Inventory
]r
Material
Inventory
\
^^^.
Finished
Finished
Goods .. j
Schedule
Raw
Material
On Hand
Raw- '
Material
Usa
Determine
Raw
hled
Current
Production
Status
Monitor
Current
MaterialOptOperations
ds
IAvailabilit
and
Determine
Finished
Goods
Requirements
id
st
ng
Status
Production
__-'
/7~
lg
F,'
urchase
Orders
ICurrent
Schedule
Demand
,, Production
Forecast
Demand
lg -
Prepare
Purchase
Orders
Raw
Finished
_-
Determine
Total Mfg.
Requirements
Determine
Master
Schedule
Parts
E
Exposion
Determine
Capacity
Availability
Production
Schedule
/
/
/
/
Raw
Material
Usage
Calculate
Material
lUsa e
Finished
Goods
Maintain
Work In
Current
Production
Status
Prncess
Work In
Process
Figure 2.
Time
Usage
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
35
Level 0:
Construct - O perate
Level 1:
Define 1
Level 2:
Design
Define -^
Level n:
-_
Design
Define
Figure 3.
Level 0:
Design
,m
Construct
Define
Design
Define -
Level 2:
,Construct
Design
Define
Level n:
Figure 4.
36
Construct
Construct
Define mDesign
Level 1:
Construct
Construct
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
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
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).
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
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
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
References
[1]
[2]
[3]
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
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
ANSI/X3/SPARC
Study Group on Data Base
Management Systems. "Interim Report," EDT, Vol. 7, No.
2, (75-02-08), pp. 1-140.
Aron, Joel D. The Program Development Process: The
Individual Programmer, Reading, Mass., AddisonWesley, 1974.
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.
Baker, F. Terry. "Chief Programmer Teams Management
of Production Programming," IBM Systems Journal, Vol.
11, No. 1 (1972), pp. 56-73.
Benjamin, Robert I. Control of the Information System
Development Cycle, New York, Wiley, 1971.
Buffa, Elwood S. Operations Management: Problems
and Models, New York, Wiley, 1972.
Canning, Richard G. (ed.). "That Maintenance'Iceberg',"
EDP Analyzer, Vol. 10, No. 10 (October 1972).
Canning, Richard G. (ed.)., "The Search for Software
Reliability," EDP Analyzer, Vol. 12, No. 5 (May 1974).
CODASYL Systems Committee. Feature Analysis of
Generalized Data Base Management Systems, New York,
Association for Computing Machinery, May 1971.
Davis, Gordon B. Management
Information
Systems: Conceptual Foundations, Structure, and
Development, New York, McGraw-Hill, 1974.
Everest, Gordon C. "Managing Corporate Data
Resources: Objectives and a Conceptual Model of
Database Management Systems," Unpublished Ph.D
dissertation, University of Pennsylvania, 1974.
Johnson, Richard A.; Kast, Fremont E.; and Rosenzweig,
James E. The Theory and Management of Systems, 3rd
edition, New York, McGraw-Hill, 1973.
Langefors, Borje. Theoretical Analysis of Information
Systems (2 vol.), Lund, Sweden, Studentlitteratur, 1970.
Langefors, Borje and Sundgren, Bo. Information Systems
Architecture, New York, Petrocelli, 1975.
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
Profit Potential," Computers and Automation, April 1968.
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.
Murdick, Robert G. "MIS Development Procedures,"
Journal of Systems Management, Vol. 21, No. 12
(December 1970).
Myers, Glenford, Jr. Reliable Software Through
Composite Design, New York, Petrocelli/Charter, 1975.
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
[21]
[22]
[23]
[24]
[25]
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