Reuse, Computer-Aided Evolution, and User-Centered Design: Keys
to Successful Developments by Small Teams
Yadran Eterovic
Sergio Maturana
yadran@ing.puc.cl
smaturan@ing.puc.cl
School of Engineering, Catholic University of Chile, Casilla 306, Santiago 22, Chile
ABSTRACT
Many decision-makers in small- and medium-size firms continue to use primitive tools to support
their decisions, because the construction and operation of optimization-based decision support systems
(OBDSSs) present many difficulties. We describe a new OBDSS development method designed,
implemented, and successfully applied by a small group of specialists to produce OBDSSs that solve
complex optimization-based decision-making problems. The development method is based on combining
computer-aided evolutionary development, software reuse, and user-centered design, and is supported by
a collection of software tools that together form an OBDSS generator.
Keywords: Software reuse, User-centered design, Evolutionary development, Computer-aided
development, Optimization systems, Decision support systems.
1.
INTRODUCTION
Despite advances in computing technology that have greatly affected the way in which people work
within organizations, many decision-makers, especially in small- and medium-size firms, continue to use
relatively primitive tools to support their decisions. One important reason for this is that the construction
and operation of computer programs to solve complex optimization-based decision-making problems are
difficult tasks. These programs—called optimization-based decision support systems (OBDSSs)—use
sophisticated mathematical algorithms, developed by mathematical programmers, and are used to support
highly repetitive decisions, such as monthly production planning, weekly crew scheduling, or daily
vehicle routing. Several problems arise during the construction or operation of an OBDSS [3]:
• The decision-maker and the analyst must interact during a long process to produce a rigorous
specification of the problem; this specification can be represented as a mathematical model.
• The process of designing, implementing, and validating the OBDSS is usually long and costly.
• Users face OBDSSs with poor user interfaces, poor data management, and poor problem
representation management.
• Maintainers face OBDSS designs and implementations that are difficult to adapt to changing user
needs.
Thus, within the context of a Chilean government-funded R&D project, we formed a small team of
10 people—faculty members and graduate students from the Departments of Industrial Engineering and
Computer Science at the Catholic University of Chile—to develop (and then use) an efficient method to
build OBDSSs.
The OBDSSs were to be used directly by managers in manufacturing firms, without the assistance of
mathematical optimization experts. Since managers may not possess the required mathematical
background, the OBDSSs’ user interface and data management facilities become of great importance,
given the underlying mathematical complexity. Thus, the main attributes of the OBDSSs are:
• a representation of the mathematical model of the problem to be solved,
• an appropriate optimization solver,
• data handling facilities with interfaces to external data if necessary,
• a user-friendly interface, and
• the ability to present the solution in a format easily understood by the decision-maker.
We decided to combine modern software engineering techniques to develop a method to be used by a
small group of experts, that would produce an OBDSS in a short period of time, and that would support
the complete life-cycle of the OBDSS. Our approach is based on a software architecture that makes use
of commercial off-the-shelf software components whenever possible, including a component that
implements the optimization algorithms. The two most difficult parts of the production of the OBDSS
remain the mathematical model specification and the user interface design, including good data and
problem management facilities. We developed tools to support these two parts of the process, and we
use evolutionary development techniques to facilitate the periodic updating of the OBDSS.
We tested the method and the supporting tools on two different optimization problems from two
Chilean manufacturing firms:
Problem A. The aggregate planning of the production of several types of home appliances for a period
of 18 months.
Problem B. The daily distribution of candies from a single storage place to several customers in
Santiago (the main city of Chile) and along the rest of the country.
2.
RESEARCH CONTEXT
Several systems for building and managing models have been proposed and developed [2], based on
different approaches: object-oriented frameworks for model management [11]; metagraphs, a
mathematical structure proposed as a unifying basis for DSSs [9]; reverse modeling tools, consisting of a
meta system that captures generic knowledge on model building, a model translator, and an objectoriented model base [10].
Specific efforts to facilitate the construction of OBDSSs include: an object-oriented framework [13]
that relies on the definitions of natural entities to develop OBDSSs for production scheduling, greatly
facilitates model development and understanding by the decision-maker, but is limited to a particular
domain; PDM [12], that enables non-experts to construct linear programming models of production,
distribution, and inventory using a knowledge-base; and Geoffrion and Maturana’s approach [3], that
exploits the distinction between a model’s deep structure—which changes little and is fixed for each
delivery system—and its surface structure—which can be modified by the user.
However, these systems are intended to support the analyst (or modeler) in modeling and solving the
problem. They do not support the complete life-cycle of OBDSSs. A survey [14] on the integration of
artificial intelligence and optimization for decision support, shows that the efforts have been focused on
model formulation and selection, and notes that the radically different data structures and algorithmic
paradigms used by AI and optimization make it difficult to integrate them.
On the other hand, during the last 30 years both process- and product-improvement methods have
been proposed by the software engineering community. Three important achievements of modern
software engineering research are:
• The definition of methods [7] and the creation of tools [8] to design and construct graphical user
interfaces (GUIs), in response to the need of building software that is easier to use and more
difficult to misuse.
• The consolidation of evolutionary development [4], in response to the problem of the uncertainty
and volatility of software requirements.
• The consolidation of systematic software reuse [5], in response to two challenges: to shorten the
length and increase the productivity of the software production process; and to produce software
which is more reliable and of better quality.
2
We decided to put into a combined, systematic, and controlled practice all these achievements, in the
form of a software development method and its associated supporting tools, with the goal of building
OBDSSs to solve problems such as problems A and B.
3.
RESEARCH APPROACH
An OBDSS Development Method
We designed a software development method based on evolutionary development, supported by
software generators, and adapted to solve the type of problems of which problems A and B are typical
representatives: it begins with a user-centered GUI design phase, then moves into an iterative reuse-based
design phase, and finishes with an iterative construction and user-based test phase.
A method to design GUIs can hardly be exact. Thus, although it should be based on a combination of
several theoretical and practical aspects involving application domain expertise, human factors, graphic
and media design, and object-oriented design, a GUI design method should only be considered as a
guideline. In practice, GUI design is usually an iterative refinement process. In our work, we did not
attempt to define a new GUI design method, but put into practice the task analysis method [1] (steps (a)
and (b) below). Thus our OBDSS development method comprises the following five steps:
a. Define the OBDSS in terms of its users and their goals.
b. Design the OBDSS’s architecture and GUI based on the tasks that should be available to the user;
if necessary, iterate with respect to step (a).
c. Find the resulting opportunities for reusing existing software components.
d. Construct the OBDSS and test it with users to identify shortcomings and other problems that
prevent users from achieving their goals.
e. Redesign to fix the problems, reconstruct, and retest the OBDSS until an acceptable usability level
is achieved.
As we will see, to make this method practical, we designed and constructed a software-generator
tool, based on existing software products and components, that supports the various steps.
User-Centered Development and the Structure of the Solutions
Building a program that is easy to use requires identifying first the salient features of the program's
intended users. Only these features can help us to decide the type of support that the users need. Experts
agree that the design of a GUI and its associated interactive program must be centered on the user: the
GUI designer must know the user, and the design process must achieve an early and continuous focus on
the user.
In our cases, the firms’ personnel can use the OBDSSs for two purposes:
a. to actually plan the production for the next 18 months or the distribution for the next day;
b. to analyze hypothetical situations in which some or all of the mathematical models' input
parameters are modified to represent different operating scenarios.
These two purposes define two slightly different types of users (purpose (b) is usually for a higher
level of management). Both, however, have several common characteristics: they have minimal
knowledge of the techniques and models used in mathematical optimization; they are familiar with
standard applications for personal computers, such as word processors and spreadsheets; and they have
expert knowledge on the more practical aspects of the processes being modeled.
Thus, the GUIs must reflect those practical aspects of problems A and B that are known to the users
and, at the same time, must hide from them those aspects of the problems related to the construction of
mathematical optimization models and the use of mathematical optimization algorithms. Therefore, we
began our work by dividing each of these problems into two subproblems:
3
I. To define a mathematical optimization model of the (production or distribution) process, including
the specification of an objective function and a set of constraints.
II. To develop a computer program—an OBDSS—that would enable its users—the firms’ decisionmakers—to solve the model for different values of user-specified input parameters.
Carrying out (I) and (II) required us to frequently interact with the firms’ managers and process
specialists in order to fully understand both the process being modeled and the users’ true needs with
respect to the OBDSS. Thus, our goal in solving (I) was not only to produce accurate models, but also to
give the few modelers within the team a software system that would help them to build models and to
make the resulting models more suitable for communication with non-specialists. We call this system the
modeling system. We produced a modeling system based on the SML modeling language and the
FW/SM modeling environment [2].
Similarly, our goal in solving (II) was not only to build the required OBDSSs, but also to extend the
modeling system to provide more automatization in transforming the mathematical models into the
OBDSSs that could solve them. Thus, the modeling system became an OBDSS generator. We
approached (II) by using PowerBuilder 5.0 as the environment for GUI generation and database access,
and CPLEX and our own heuristics as solvers of the mathematical optimization models. Early on the
project, we had decided that users of the OBDSSs should only be allowed to modify the values of the
input parameters provided; the structure of the mathematical optimization model from (I) remains fixed.
OBDSS's GUI Design
The approach we followed to design the OBDSS's GUI was based on the task analysis method. We
now describe the two most important steps of the method.: task analysis, and appearance and behavior
design.
Task analysis
Considering that the general objective of the two OBDSSs is to solve mathematical models for userspecified values of sets of input parameters, we required that both systems should allow users to carry out
several tasks:
a. To specify the values of the input parameters that define a particular instance of the mathematical
model, that is, to define a particular problem.
b. To execute the optimization algorithm that solves the problem.
c. To examine the results.
From the point of view of the systems' GUIs, task (b) should not be decomposed into subtasks. We
did not want the users to be involved in the operational details of the optimization algorithms (CPLEX or
our own heuristics). All they should do to start the execution of the algorithms, once they had defined a
problem, was to click on a button or menu option on the screen.
But tasks (a) and (c) can only be carried out through the execution of several subtasks that depend on
the specific system. In both systems, there are several input parameters that can be specified, and several
types of output data and several ways to look at the data available to the users. Tasks (a) and (c) are thus
composite tasks that need further decomposition. Table 1 illustrates the subtasks for problems A and B.
Appearance and behavior design
A GUI's appearance and behavior should transmit a model of the task domain that is attractive and
compatible with user expectations. To accomplish this it is necessary to:
• identify the appropriate GUI objects to show syntactic and semantic information, maintaining
global consistency, facilitating the specification of action sequences (offering alternatives), and
reducing the semantic distance (based on syntactic, lexical, and screen layout considerations);
4
• make explicit the state of the OBDSS by showing appropriate physical variables, indicating when
actions are forbidden, displaying the current operation mode, informing the user about long
response times, and showing on the screen the mouse movement;
• define the correspondence between the tasks and the data elements, both syntactic data elements—
e.g., provision for multiple simultaneous views of the semantic data, scrolling and sizing
operations of interaction windows—and semantic data elements, that depend on the domain and
are processed by the OBDSS—; and
• specify the level of computer support required to facilitate the achievement of the tasks, such as
undo-redo, cut-copy-paste, on-line help, default values, and macro definitions.
Problem A

Problem B
number of working days per month,

 specific products considered,
Problem
Specification  availability of the firm's workshop 
Tasks
machines,


production costs,

sale prices estimates, etc.


Results
Visualization 
Tasks


geographic location of firm's delivery
center and of each of its customers,
orders,
volume and weight of each product's
shipping unit,

volume and weight capacity and time
availability of each truck,

time window of each customer for reception of merchandise,
 average speed of trucks, etc.
The output data of the distribution
production level,
problem are the routes that each truck has
stock level,
to follow to deliver the merchandise to
number of pending orders;
the customers. The specification of a
number of employees currently route includes:
working, or recently hired or fired;
 truck's id;
number of overtime hours;
 customers visited, in order;

man-hours total and
workshop basis; and

reports and charts showing production and machine utilization levels.
on
a
per 
route's length;

how much of the truck's capacity is
used;

truck departure and arrival times; and

departure slack time.
Table 1: Example subtasks for problems A and B
We evaluated three main approaches to represent the problems:
• A natural graphical representation, which is easier to understand, but is not always easy to find (eg,
for aggregate production planning), sometimes has to handle too many elements, and almost
always requires adaptation.
• An abstract graphical representation (e.g., a graph), which requires less adaptation—the representation is more general—, but is more difficult to understand by users.
• A database- or spreadsheet-oriented representation, which is easier to learn by users, specially if
they are already familiar with applications using this representation, and which is natural to
problems requiring or producing large volumes of data.
5
In [6] we explain in detail the advantages and limitations of each representation, concluding that the
database-oriented representation is the most appropriate for the purposes of the OBDSSs being built, and
describe in detail the software architecture chosen for those systems. This architecture specifies the data
elements, their functionality, and their methods of communication.
We chose the well-known paradigm of Microsoft products—such as MS Word and MS Excel—
running on MS Windows, and we followed the conventions of these applications as far as we could to facilitate the learning process. Figure 1 shows a window displaying the production level (in number of
units) computed by the OBDSS generated for problem A for an artifact identified as EXHGF-405NL, for
each of the next 18 months.
Nivel de Producción
Tipo de Artefacto
DOS_PUERTAS
MONOPUERTA
Artefacto
Períodos
Unidades
EXFRF-360 SL
EXFRF-410 SL
EXHGF-355 NL
EXHGF-405 NL
FR-280 SL
MES 01
MES 02
MES 03
MES 04
MES 05
552.00
0
410.00
410.00
492.00
FR-340 SL
FRF-350 SL
MES 06
574.00
MES 07
656.00
FRF-360 SL
MES 08
656.00
FRF-410 SL
MES 09
656.00
MR-245 NL
MES 10
MES 11
MES 12
656.00
MR-295 NL
MRF-345 NL
MRF-355 NL
MRF-405 NL
MES 13
MES 14
MES 15
MES 16
MES 17
MES 18
Aceptar
Cancelar
Ay uda
Imprimir
Ex portar
820.00
820.00
0
0
0
0
modo
Tabla
Gráfico
0
0
Figure 1: OBDSS´s output variables for problem A.
4.
RESEARCH RESULTS
The OBDSS Generator
An OBDSS has to provide access to the firm’s databases and solve the optimization problem defined
by the users through the GUI. In order to be effective and efficient in building this type of systems, we
cannot design and construct all these system components every time from scratch. Therefore, we built an
OBDSS generator which:
• allows us to express mathematical programming models in a language that is easier to understand
by the firms' personnel;
• allows us to quickly construct different GUIs, as a means to exploring the real needs of the
systems' users; and
• supports the automatic development of an OBDSS once the mathematical programming model and
the system's GUI have been defined.
6
The construction of the OBDSS generator and the OBDSSs produced by it rely heavily on software
reuse. In particular, our approach involved reuse of the following types of software products:
• A high-level specification language, SML, which is part of the OBDSS generator.
• A modeling environment, FW/SM, which is part of the OBDSS generator. FW/SM integrates
reuse techniques such as specification (in SML), parameterization, and classification; it supports
the verification of several properties of the SML specification; and the translation of the SML
specification into a standard mathematical programming notation.
• A GUI development tool, PowerBuilder 5.0, which is used in the OBDSS generator and is part of
the OBDSS. PowerBuilder offers high level abstractions within the domains of GUIs for database
access, thus effectively reducing the effort required to convert the GUI designs described earlier
into executable implementations.
• A collection of COTS components, the mixed integer programming problem solver CPLEX, which
is part of the OBDSS. These components have been written, tested and are available specifically to
be reused.
• A collection of source code components, written in C, developed by our team and used in both the
OBDSS generator and the two OBDSSs.
Figure 2 shows the general architecture of the OBDSS generator (Modeler level) and the generated
OBDSS (User level). The generator supports not only the definition editing, and verification of models
expressed in SML, but also the automatic generation of the OBDSS, and its subsequent improvement,
once the OBDSS is installed and in use.
FW/SM
Modeler level
User level
ASCII files
with data
*.TXT
Exports data in
comma-delimited
format
1
Exports Model
Model in
SML language
ASCII file with
the optimization
problem in
MPS format
Merges model
with data into a
MPS format
ASCII files with
model in SML format
*.IRT
ASCII file
with the
solution
DBMS
WATCOM
SQL
Solves the problem Imports solution
using CPLEX
into Data Base
2
3
4
APPLICATION
User Interface
Figure 2: Software architecture for OBDSS generator and OBDSSs.
The Evolution of the OBDSS
Evaluating the OBDSS in general, and its GUI in particular, is a fundamental aspect of our work.
Different people have participated in it: the software development team; experts in mathematical
modeling and mathematical programming working in the project; and technical and management
personnel from both firms. Our approach involved several evaluation meetings to improve the
appearance, behavior, and meaning of the GUIs. These evaluations and the subsequent actions followed
an evolutionary development process.
7
As an example we describe the changes made to the OBDSS generated for problem A to provide it
with the capability of scenario management. Scenario management allows users to define and solve new
model instances from a base case.
New tasks
The main purpose of this evolutionary phase is to provide functionality to help users analyze the
results computed by the original OBDSS prototype. From the beginning, it was apparent to us that a
simple and effective way to do this was through the use of scenarios. We worked on the hypothesis that,
when analyzing models' results, users find it more meaningful to look at the results in terms of their
differences with respect to the results of a base case. If users are already familiarized with the base case,
then this difference-based approach can help them to find and prioritize the opportunities and problems
that exist in their production or distribution processes.
The three major new tasks that the OBDSS's GUI should support are the creation of a new scenario,
the definition of the input data in terms of variations with respect to the base case's input data, and the
presentation of the results in terms of differences with respect to the results of the base case. An
appropriate GUI to handle such tasks is a scenario manager that allows users to create, edit, delete, solve,
display and compare scenarios.
Creating a scenario involves describing its basic attributes and defining the changes that scenario will
represent with respect to the chosen base case. This definition is done through a number of subtasks,
such as selecting the corresponding input variable, specifying the range of values that will be affected by
the change, and performing the change. Similarly, editing a scenario involves in turn selecting the scenario, defining the new changes that the user wants to study, or undoing changes no longer of interest.
New GUI
Scenario managers are used in other types of applications, such as spreadsheets. Because
spreadsheets are part of the computer knowledge of the typical user of our OBDSSs, we decided to represent the scenario manager on the screen similarly to the representations used in spreadsheets. While in
the context of spreadsheets a typical change from one scenario to another might involve changing the
values of a block of cells, in the case of our OBDSSs changes usually involve the values of input
variables. Figure 3 illustrates adding a new scenario, Figure 4 illustrates making changes to a current
scenario, and Figure 5 illustrates displaying the differences between the optimal solution to a scenario
and the optimal solution to the corresponding base case.
8
Ag r e g a r E s c e n a r i o
N o m bre d el Es cen ario:
P a r á m e tr o s
N o Ca m b i a d o s
Ca m b i a d o s
Costo de Producción
Costo de Sobredotación
Costo Variable de Mano de O
Demanda Estimada
Demanda Pendiente Inicial
Días Hábiles
Ef iciencia de Máquina
Factor de demanda Pendiente
Co m e n ta r i o s :
Figure 3: Window to add a scenario.
H a c e r Va r i a c i ó n
1.20
Va l o re s s e l e c c i o n a d o s
-
+
A
C
To d o e l P a r á m e tro
*
Figure 4: Window to specify changes with respect to a base scenario
D i fe r e n c i a s c o n e l E s c e n a r i o B a s e
P r o d u c to s
EXFR-240 SL
Producto: EXFR-240 SL
EXFR-325 SL
EXFR-360 SL
EXFR-410 SL
EXHG-225
NLMáquina
Ef
iciencia de
Factor
de demanda
Pendiente
EXHG-315
NL
EXHGF-355 NL
EXHGF-405 NL
FR-240 SL
FR-280 SL
Unidades
150
100
Compra
50
Faltante
0
Producción
-50
-100
Stock
-150
-200
1 2
3 4 5
6 7 8
9 10 11 12 13 14 15 16 17 18
Meses
FR-325 SL
m odo
Gr á fi c o
Ta b l a
Salir
Figure 5: Chart displaying result differences with respect to a base scenario
9
5.
CONCLUSIONS AND FUTURE WORK
We have described a software development method for building OBDSSs. The method is based on
the combined application of validated software engineering techniques: evolutionary development with
user involvement, reuse of software components and interaction paradigms, and task analysis for
designing GUIs. The method can be used by a small group of specialists to produce OBDSSs with goodquality GUIs and data-handling facilities, and in a short period of time. We regard these conditions as
necessary for the success of an OBDSS. To achieve these goals without compromising system
correctness, an important part of the OBDSS is built automatically by an OBDSS generator, an important
result of this work.
The method has been successfully applied by a small team of software engineers and operation
researchers in the construction of OBDSSs for two manufacturing firms. The flexibility of the resulting
designs and the automatization provided by the OBDSS generator have allowed us to make major
changes to both the functional and GUI aspects of the systems in short periods of time.
Because these systems were built as part of the overall research, further applications of the method
and supporting tools, preferably in firms not involved in the research, are required to fully validate the
encouraging results obtained so far. Also, further research in what makes better OBDSSs (eg, the
scenario management facility) and in the software reusing approach will help improve the method and the
supporting tools. For example, we need more flexible software architectures for the OBDSSs and the
OBDSS generator to incorporate different model specification languages, optimization algorithms, and
GUI implementation toolkits.
Acknowledgments
We thank FONDECYT (grants 1980923 and 1980969) and FONDEF (2-55).
REFERENCES
[1]
[2]
L. Bass and J. Coutaz. Developing Software for the User Interface. Addision-Wesley, 1991.
A. Geoffrion. FW/SM: A Prototype Structured Modeling Environment. Management Science 37
(12), 1513–1538 (1991).
[3] A. Geoffrion and S. Maturana. Generating Optimization-Based Decision Support Systems.
Proceedings of the 28th Hawaii International Conference on System Sciences. (1995).
[4] V.S. Gordon and J. Bieman. Rapid Prototyping: Lessons Learned. IEEE Software 12 (1), Jan.
1995, 85–95.
[5] E. Henry and B. Faller. Large-Scale Industrial Reuse to Reduce Cost and Cycle Time. IEEE
Software 12 (5), Sept. 1995, 47–53.
[6] S. Maturana and Y. Eterovic. Vehicle Routing and Production Planning Decision Support
Systems: Designing Graphical User Interfaces. ITOR 2 (3), 1995, 233–247.
[7] A. Puerta. A Model-Based Interface Development Environment. IEEE Software 14 (4),
July/August 1997, 40–47.
[8] L. Valaer and R. Babb II. Choosing a User Interface Development Tool. IEEE Software 14 (4),
July/August 1997, 29–39.
[9] A. Basu and R. Blanning. Metagraphs: A tool for modeling decision support systems.
Management Science 40, No. 12 (1994) 1579–1600.
[10] O. Kwon and S. Park, RMT: A Modeling Support System for Model Reuse, Decision Support
Systems 16, (1996) 131–153.
[11] W. Muhanna. An Object-Oriented Framework for Model Management and DSS Development.
Decision Support Systems 9, (1993) 217—229.
[12] R. Krishnan, PDM: A Knowledge-Based Tool for Model Construction, Decision Support
Systems 7 (1991) 301–314.
10
[13] Pillutla, S. and B. Nag, Object-oriented Model Construction in Production Scheduling Decisions,
Decision Support Systems 18, (1996) 357–375.
[14] A. Dutta, Integrating AI and Optimization for Decision Support: A Survey, Decision Support
Systems 18, (1996) 217–226.
11