***** DAY ****************** EJC/REC Vol. 3, No. 2, 1993 ***

Precis of
BEHAVIORAL AND PERCEPTUAL RESPONSES TO CONSTRAINT MANAGEMENT
IN COMPUTER-MEDIATED DESIGN ACTIVITIES


Donald L. Day
Syracuse University


        Abstract.  This paper proposes the study of
     user responses to constraints applied in tools
     used for computer-mediated design activities.
     Although the domain of study is software
     engineering, the typology of constraints,
     conceptual framework, and understanding of user
     behavior developed in this study should help to
     improve decision support tools in other domains.

        Following an introduction, the paper describes
     the domain, the conceptual framework, the problem
     space, research questions, and justification for
     the study.

                       Introduction

     Computer-mediated software design includes an efficient
but often inflexible communication of decision support rules
and context from design tool developers to design tool
users.  (Communication of rules can be efficient -- that is,
resource-frugal -- without allowing the recipient to engage
in flexible behavioral responses).  This mapping of
developers' process models to user behavior requires skills
drawn from information studies, cognitive psychology, human
factors and decision sciences.  Examination of how such
skills are applied by developers and perceived by
experienced users could lead to improved product quality,
increased user productivity and sustainable levels of
process throughput.  An improved understanding of
Computer-Aided Software Engineering (CASE) decision support
mechanisms and user behavior also could facilitate design
creativity while ensuring reasonable adherence to product
and process standards.

     This study examines computer-mediated cooperation among
(a) skilled users who create program modules as end-
products, (b) software engineers who define intermodule
relationships, schedules and quality assurance, and (c)
developers who create the CASE tools which programmers and
software engineers use.  The tools facilitate implementation
of design concepts.  They do so in part by incorporating
constraints made necessary by a variety of economic,
quality, schedule and maintainability concerns.  Such tools
allow system developers to cooperate with programmers and
software engineers in the creation of software which meets
performance criteria and other standards.

     The constraint management subsystem within a CASE tool
may be considered a knowledge base, in that it represents
the weighted requirements of various stages in the product
development cycle.  Instead of relying upon personal
experience with remote stages in software production and
testing, or upon cooperation directly with individuals
responsible for earlier or later processes, the user deals
with a functional representation (constraint) which guides
decisions in the appropriate task context.

                        The Domain

Key Players

     CASE tool users often are technically skilled system
analysts, software engineers and programmers with system and
code development experience, working as a team in the
generation of software.  They use CASE tools in the design,
fabrication, testing, integration, maintenance and
enhancement of end-products (programs interrelated in a
functional system).  Each user has his or her own
professional perspective regarding appropriate models and
procedures for software development.  Many feel that their
trade is an art as much as a science and resist the
application of constraints.

     Developers generally are highly skilled software
engineers and system analysts employed by firms whose
marketable products are CASE tools.  They often are not the
ultimate authority for requirements which they implement as
constraints.  (Such authority may stem from government or
professional standards, customer specifications, or
management direction -- either at the tool development firm
or at the tool application/user site.)  However, the details
of constraint implementation within CASE tools are the
developer's responsibility; those constraints and user
behavioral responses to such constraints are the focus of
this study.  Therefore, differences among the sources of
authority for requirements are not important except as one
means to categorize various types of constraints, based upon
the origin of requirements from which the constraints stem.

     Developers define the processes, functions and tasks
available through a software tool; users select and
manipulate functions and tasks in a process sequence to make
a product.  One of the difficulties addressed in this study
is the difficulty of some developers to realize the impact
of constraints upon user tasks and upon some end-product
characteristics; another is some users' lack of
understanding of constraint rationale or even of the
software development models underlying various CASE tools.

CASE Tools

     CASE tools range from single-purpose (though
sophisticated) computerized design tools to intertwined
hierarchical or object-oriented packages of tools which
facilitate process and quality control throughout much of
the software development lifecycle.  Included are tools
which provide decision support for

     1. Planning, analysis and design.
     2. Graphical user interface (GUI) development.
     3. Performance assessment.
     4. Business and technical code generation.
     5. Reverse engineering and maintenance.
     6. Programming error detection and module testing.
     7. System test and evaluation.
     8. Configuration management.
     9. Automation of system and user documentation.

     CASE tools provide a meeting ground between users' and
developers' mental maps of desirable processes, functions,
tasks and constraints.  In this sense, they constitute
computer-mediated communication between two sets of
professionals who historically have held notably different
views of the activity which they share in common (software
development).  Since each group brings to the design
activity its own experience and expertise, and since CASE
tools are permeated with details of design models and
process control perspectives, such tools constitute much
more than mere application software.  In consort with the
hardware platforms on which the tools execute, CASE tools
mediate communication between users and developers.

     Although the literature addresses semiotic and
cognitive aspects of user interface design, only in the
recent past have the difficulties of system restrictiveness
received attention (Silver, 1991).  The potential personal,
organizational and economic costs of user dissatisfaction
with unnecessarily inflexible constraint management are
substantial.

                   Conceptual Framework

Perceptual Conflicts

     Apparent conflicts between design creativity and
standards application plague CASE decision support
activities, partly because of the mismatch between process
maps preferred by tool developers and those favored by users
of their tools.  Differences over the functions to be
executed, tasks performed and procedures followed impact

     1. Design process sequences.
     2. End-product attributes.
     3. Task and function integration.
     4. Throughput sustainability.
     5. Change control.
     6. Process and product requirements such as cost,
        schedule, reliability and maintainability.

Developers' perceptions are influenced by concerns regarding
risk assessment, resource management, process control, and
quality assurance; users' perceptions reflect specific
project requirements, design experience, training, the work
environment, time-on-task, cost and satisfaction concerns.
Achieving urgently needed benefits from CASE decision
support requires a more successful negotiation of priorities
between tool developers and tool users.

The Transfer of Knowledge

     Decision support in the CASE activity context is
heavily dependent upon the transfer of design and process
rules from developers to users, via computer-mediated tools.
The tools in effect sponsor developers' process models as
appropriate means to develop high quality software.

     The cognitive transfer of knowledge from developers to
users is plagued not only by quality control and creativity
concerns, but also by classic issues about the implicit
limitations of any such transfer.  Singley & Anderson (1989)
have discussed these problems at some length, though in an
intrapersonal rather than interpersonal context.  (It seems
likely that such limitations exist as much or more in
computer-mediated communication as they do in individual
learning.)

     The unique characteristics of each situation (i.e.,
situational specificity) frustrate users' attempts to
generalize process models appropriately.  Realizing this,
developers favor inflexibility in CASE tool implementation.
They often feel it is better to limit user creativity than
to risk tool usage which may impair end-product quality.

Constraint Issues and Typology

     Developers typically embed constraints (procedural
preferences and quality assurance controls) within CASE
tools to ensure the fulfillment of requirements via process
control.  It is the end-product characteristics, not the
constraints intended to ensure the presence of those
characteristics, that are important.  In the absence of a
more thorough understanding of potential constraint
management flexibility, however, constraint means become
process ends.  Constraints applied inflexibly generate user
frustration, constraint avoidance behavior, schedule delays
and suboptimal software packages.

     It should be noted that constraint satisfaction does
not necessarily imply the application of inflexible rules;
it only mandates that a series of decisions taken as a whole
meets constraints.

     In order to examine the attributes, impact and
management of constraints applied in creative design
activities, a typology is necessary.  The definition of
descriptors implicit in creation of a typology facilitates
(a) unambiguous description, (b) the creation of appropriate
perceptual and behavioral measurement instruments, and (c)
the conceptual validation of analysis.

     The typology to be applied in this study is three-
dimensional.  Its three axes (each a discontinuous set of
descriptors) seek to characterize the key aspects of each
constraint implemented by a developer in a tool in response
to process or product requirements.  The "x" axis is
populated by descriptors adapted from Sheridan's (1980)
human-computer control continuum (Table 1).  This axis
characterizes the flexibility of


============================================================

                          Table 1
            A Human-Computer Control Continuum

------------------------------------------------------------

1.   Human considers alternatives, makes and implements
     decision.
2.   Computer offers a set of alternatives which human may
     ignore in making decision.
3.   Computer offers a restricted set of alternatives, and
     human decides which to implement.
4.   Computer offers a restricted set of alternatives and
     suggests one, but human still makes and implements
     final decision.
5.   Computer offers a restricted set of alternatives and
     suggests one which it will implement if human
     approves.
6.   Computer makes decision but gives human option to veto
     before implmentation.
7.   Computer makes and implements decision, but must
     inform human after the fact.
8.   Computer makes and implements decision, and informs
     human only if asked to.
9.   Computer makes and implements decision, and informs
     human only if it feels this is warranted.
10.  Computer makes and implements decision if it feels it
     should, and informs human only if it feels this is
     warranted.

------------------------------------------------------------
Notes: (1) As interpreted for this study, the user region of
Sheridan's continuum would be characterized by levels of
constraint whose weights are sufficiently low to permit user
override, whereas the system region would be characterized
by levels which assume that the constraint is essential to
the fulfillment of requirements.

Source: Sheridan (1980), p. 65

============================================================


decision guidance in terms of the degree of control
allocated to the tool versus that allowed for the user.  The
"y" axis is populated by descriptors of potential methods of
implementation (characterized by formality, process context,
vehicle/means, and degree of transparency to the user).  The
"z" axis is populated by descriptors indicating the source
of "authority" for requirements which inspired the
constraint.  Such sources may include

     1. Professional standards.
     2. Cost.
     3. Schedule.
     4. Government requirements such as DoD's 2167 standard.
     5. The severity of loss (including legal liability) if
        the end-product fails due to design flaws.
     6. Customer specifications.
     7. Physical limitations of production, manufacture, or
        supporting infrastructure.
     8. Quality assurance.
     9. Resource management (people, materiel, equipment,
        utilities).

During the course of the study, the descriptors for each
axis will be refined and clarified.

                     The Problem Space

     The problem space within which this study is conducted
may be envisioned as a quadrant (Figure 1) anchored by one
axis for experienced user options (functions and component
tasks) and a second axis for constraints reflecting product
requirements.  The behavioral space of this study may be
envisioned as a second quadrant (Figure 2) representing the
relationship between the type and extent of contraint
implementation and the types and degree of user behavioral
response.  Composite variables applied on each axis of the
behavioral space are described briefly below.  Component
variables which form these composites will be identified
both from the review of literature and from preliminary
questionnaires administered at data collection sites.  These
variables will be incorporated in a survey instrument
completed by experienced users and reviewed to provide
procedural and analytic guidelines for direct observation.

============================================================

            | Task A |                     x
Function 1  | Task B |      x
            | Task C |                     x
                     |
            | Task A |      x
Function 2  | Task B |
            | Task C |                     x
                     | _________________________________
                            |              |
                       Constraint 1   Constraint 2

                 Figure 1 - Problem Space

============================================================


 ===========================================================

                 8 - |      x
                 7 - |
 USER RESPONSE,  6 - |
Design Option N  5 - |                     x
                 4 - |
                 3 - |
                 2 - |
                 1 - |
                 0 - | _________________________________
                            |              |
                          Level 1        Level 2

                                    CONSTRAINT 1

                Figure 2 - Behavioral Space

============================================================


     The variables to be weighted and combined for each axis
may be assigned to two single meta-variables (composites).
Within the behavioral space, the composite USER RESPONSE
will be plotted against the composite CONSTRAINT, with the
levels of CONSTRAINT determined by the extent to which
production requirements (i.e., the weighted importance of
the constraint) could be applied to the specific design
option.  There are three component values to USER RESPONSE:
(a) subjects' survey questionnaire answers, (b) user
behavior observed directly, and (c) the degree of
discrepancy between (a) and (b).

Research Questions

     This study seeks provisional answers to a limited set
of research questions related to the flexibility of
constraints implemented within CASE tools.  These include

     1. What attributes of constraints are perceived as key
to experienced users and developers?

     2. How can knowledge of user perceptions be used to
implement constraints in a more acceptable manner?

     3. How can mental maps of processes, functions and
tasks be coordinated best among tool developers and users so
as to relax the coupling of requirements satisfaction to
constraint implementation, effectively allowing constraints
to be more flexible?

     4. What are the product quality, user satisfaction, and
user productivity impacts of constraint imposition?

     5. What are the characteristics of potential constraint
override situations within software development processes?

     6. How can the effects of permitted constraint
overrides be assessed, in terms of their impact upon other
decisions and (potentially) upon product quality?


               Justification and Conclusion

     Computer-mediated design using software tools is a
technology which has become common in a number of
disciplines.  Such tools are used in a variety of
engineering disciplines, plus architecture, industrial
packaging, and publishing.

     Software engineering is an especially appropriate
domain for the study of computer-mediated tools.  CASE tools
are themselves used to build other software (including
tools), thus influence a variety of disciplines.  Because of
this multiplier effect, user responses to the design of CASE
tools constitutes a worthwhile area of investigation.

     This study of constraints and user behavior also would
be important to the decision sciences.  The transfer of
developers' process models to CASE tool users incorporates a
variety of concerns, many of which are characteristic of any
process control/decision support situation.  Thus,
successful characterization of constraint management
problems, user behavioral responses, and the potential
decoupling of product requirements from constraints would be
of high value in any discipline for which computer-mediated
process decision support is important.

     Constraint management will become an increasingly
important element in tool design.  As a result, some means
must be developed to reduce the impact of constraints upon
creativity by providing decision support to users in
selecting task execution, problem solution and constraint
override options.  We must maximize creative design options
while at the same time preventing unacceptably severe
violations of end-product constraints.  Otherwise, user
morale, staffing and productivity problems may result.

     Finally, results of this study could be applied in
future research to specify constraint subsystems that could
operate as knowledge bases.  The automatic recording of
transaction data describing user execution of functions (and
override attempts) could be used to build customized
user-process profiles.  Further, sufficient understanding of
the interplay of constraint implementation and user behavior
could make feasible intelligent software that could allocate
decision flexibility dynamically and in context, always
mindful of the impact of current decisions upon future
choices and end-product quality.


                        References

Sheridan, T. (1980).  Computer control and human alienation.
     Technology Review, 83:1 (October), 65.

Silver, M. (1991).  Systems that support decision makers.
     New York: Wiley & Sons.

Singley, M., & Anderson, J. (1989).  The transfer of
     cognitive skill.  Cambridge, Mass.: Harvard University
     Press.
------------------------------------------------------------
                      Copyright 1993
   Communication Institute for Online Scholarship, Inc.