Model Based Tool for Planning Optimal

Integration Processes Under Severe Uncertainty

Dr. Meir Tahan Mr. Roy Benish
Ort Braude College, Karmiel, Ort Braude College, Karmiel,
Israel Israel
tahanm@braude.ac.il roy_benish@yahoo.com

Abstract. The preparing of an integration plan is usually done intuitively by

experienced engineers based on their previous experience and the project constraints.
Since the plan is intuitive, it may be not optimal. The integration process involves
severe uncertainties, such as units not being available on time, integration increment
duration, and testing costs. Many times such uncertainties cause changes in the project
plan. The integration team may find that they are not prepared for these changes
again, because the integration plan is not optimal.
This work offers a model-based software tool for finding an optimal path for system
integration. The tool finds the optimum path assuming deterministic integration
parameters or parameters with inherent uncertainties.
The tool is designed for project managers, integration teams and academic integration
research. It has a built-in flexibility in order to serve a variety of organizations and
different users.
 1.0 Introduction
System integration is one of the most complicated tasks in modern system
development. A major issue occupying system integrators is how best to formulate a
program that coordinates many groups to complete the development of the sub-
systems that are under their responsibility in time. Another important issue is how to
integrate these sub-systems and validate the entire systems performance.
Coordinating many groups to complete sub-system development and then integrate
them into a whole system in the allotted time is a very difficult task. Usually sub-
systems do not arrive when they are needed or scheduled to arrive. Frequently,
elements are standing-by, waiting for others to complete development, in order to
launch the integration phase.
The integration process takes place at the end (or almost the end) of the development
phase. The integration process must be as efficient as possible in order to compensate
for any deviations created in earlier development stages, with the objective being to
complete the project on time and within the given budget. Incremental integration was
found to be the most practical strategy in this context (see, e.g., Sommerville 2001
Jorgensen 2002 Ch.13 pp 205230).
Proper project management means preparing intensively for the integration process.
Nevertheless, despite any amount of intensive preparations, the integration process
frequently suffers from many unexpected difficulties. One reason for this
phenomenon is that fairly high uncertainties are involved in the integration process.
These uncertainties may cause an unintended change in the integration order for
which the team is not prepared. This, of course, means that the team responds
reactively to uncertainties.
The current situation is that project management has no tools for predicting the
duration and cost of integration. The tool commonly used for planning is MS Project,
using data usually given by experienced engineers based on their previous experience
and the project constraints. The present paper describes a tool that supports the
estimations given by experts, offers an alternative integration order, and examines
each alternative using a "click" of a button. This paper, based on a PhD dissertation
(Tahan and Ben-Asher 2008 pp. 165-185), is intended to stimulate thought within the
engineering community and demonstrate the benefit of using integration planning-
dedicated tools. The tool presented herein is designed to handle uncertainties in a
proactive manner. In the academic domain, the tool can be used for engineering
systems integration research.
The tool, as we envisioned it, requires the following properties:
1. Flexibility, so that it can be used in various organizations and for research.
2. Manual operation, for investigating specific integration processes.
3. Automatic operation, for exploring the optimal path.
4. Ability to consider uncertainties regardless whether the manual or automated
mode is being used.
The paper is organized as follows: Section 2 presents a brief summary of the
integration model. Section 3 presents a brief summary of the tool and in Section 4, we
conclude.

2. Brief Summary of the Integration Process Model

Project Internal and External Constraint Considerations. Internal constraints are
the systems internal parameters and the relations among them. For a given project
with specified units, these parameters determine an integration steps cost and
duration. External constraints are usually created by peoples decisions or by
situations. For example, geographical distance between development groups may
impose separate integration at each site and then integration of the entire system. It is
possible that integration according to the internal constraints is much more efficient
and relocation of some development group for the integration period is cheaper and
faster since the units are tightly coupled and the de-coupling effort is quite expensive
and time-consuming. The same argument can be used for modules; sometimes some
units in a module are not tightly coupled. When the model in Figure 1 is used at the
beginning of a project, it may affect the module arrangement.
Many concepts for engineering systems integration have been developed over the
years top-down integration, bottom-up integration and neighborhood integration
(geographical or interfaces) (Sommerville 2001 ch 20 pp. 459-462, Jorgensen 2002
Ch.13 pp 205230), are just a few. Using a constraint model, safety constraints can be
a mustbe-integrated-last constraint. Top-down integration can use the constraint
must-be-integrated-first for the Jig unit. The must-beintegrated-as-a-pair (or
group) constraint can be used for neighborhood integration.

Integration Process Model Assumptions. Assume a system with units that must
be integrated within a limited time or budget, or both. At any integration increment
the integrator can choose one of the following options:
1. Integrating two available units to create a MIG (Minimal Integrated Group);
2. Adding one available unit to an existing MIG, thus creating a CIG (Complex
Integrated Group);
3. Integrating two of the existing MIGs or CIGs, thus creating a CIG.
The underlying assumption is that the integration is performed in pairs. This
simplifying assumption is an academic assumption that can be justifiable due to the
fact that it is a common practice in many development projects.
Another assumption is that there is only one integration group; therefore, parallel
integration is not an option.

Figure 1. Integration Process Model

 2.1 Mathematical Modeling
Integration Model Principles. Most projects must meet a given schedule and stay
within a set budget, which means that the integration process is similarly constrained.
The integration process can be expressed in terms of invested cost and/or by its
duration. The "cost effort" is the sum of the financial resources consumed by the
integration process. These resources may be associated with labor, laboratories, test
equipment, disposables, etc. They include direct costs (cost per usage time unit,
materials) and indirect costs such as transportation, and licensing fees. The "time
effort" is the total sum of the duration of all the integration activities that are not done
in parallel.
The total project integration effort is the sum of all of the steps (increments). The
project total time is the sum of the overall integration time and the time thus far spent
on the project. The project start time depends on the unit availability times.
The integration model is based on parameters. Figure 1 illustrates the integration
model parameters.
It is obvious that units should be available for the integration process when it is due to
begin. The optimal integration model assumes that all units are available. Unit
availability can be achieved in two ways: Latest start wait till the last unit is
available; earliest start start the integration when all the units in the critical path are
available. Of course, the earliest start is preferable. The Units Availability step of the
model contains a hidden assumption that all the available units have been or will be
completely tested at the lower level. This assumption facilitates the models use for
planning the integration process in advance.
The Unit Effort parameter represents all the activities and expenses involved with
handling each unit. This parameter is usually negligible since most units require just
power or a mechanical holder. On the other hand, sometimes the unit effort may be
expensive. For example, explosives require integration in a bunker; seeker heads or
navigation systems require an acceleration table; optical units require an optical
collimator etc. These requirements consume time and money that the proposed
integration model takes into consideration.
Missing units are units that are not used in a given step. Missing units result in
missing functions and interfaces. Simulations and stubs are required in order to
circumvent the issue of missing units. Sometimes required simulations and stubs
already exist and setting them up is all that is needed. Nonetheless, even simple
simulators require some development. Sometimes this development is expensive and
integration/test planning should attempt to minimize the number of expensive
simulators that need to be developed. The proposed model considers these costs and
attempts to minimize them. It must be noted that sometimes simulators may cause
problems, and consequently, the integration team may spend valuable time resolving
them. The model takes this extra time into consideration as a factor.
Unit Integration Effort is the effort required for integrating two units. This is a matrix
parameter that considers the reactions between any two integrated units. The difficulty
factor is used when more than two units are being integrated. In some cases
integrating more than two units may be easier since there are less missing functions
and interfaces, and in other cases, it may be harder since if a problem arises, isolating
the problematic unit is more difficult.
The Missing Unit Decoupling Effort is used when two units are tightly coupled and it
is very difficult to integrate one without the other. Development of simulators or stubs
for tightly coupled units is extremely expensive and rarely done. The model considers
such tightly coupled units (a strong internal constraint) in order to avoid problems
integrating them into the optimal integration path.
External interfaces are sometimes difficult to obtain. For example, when integrating
an airborne system, the aircraft signals are necessary but not available in the
integration laboratories so a simulator for this interface is required. The development
of this simulator is very expensive and in many cases the customer may have labs or
simulators that would be appropriate substitutes but some effort is required to obtain
permission to use them.
As mentioned above, the proposed model handles the internal constraints. A dynamic
programming optimization can easily handle external constraints. The external
constraints do not affect the uncertainties, thus the current paper does not describe the
constraints algorithm.
The proposed tools main goal is to offer a method for handling integration
uncertainties. Any of the parameters mentioned above may suffer from uncertainties.
Handling the uncertainties at the integration level is quite straightforward and
common tools are used. As mentioned above, optimization is required at the project
level. The goal is to determine the right time to start the integration in order to reach
the optimal process for the whole project.
Figure 2 demonstrates the average time mathematical model. The calculation of the
main integration factors is shown. The indexed parameters are entered by the user.

Figure 2. Formula for Time Calculation

Handling uncertainties. The tool suggests three models for handling uncertainty
according to the degree of uncertainty about the activities:
1. Statistical for a low level of uncertainty when the organization has knowledge of
the mean and standard deviations of the activities;
2. Monte Carlo for a moderate level of uncertainty when the organization is able to
estimate the possible limits of the activities;
3. Info-Gap for an extremely high level of uncertainty when the organization is
only able to make a relative estimation of the activities.
Statistical analysis is a straightforward approach for handling integration
uncertainties. In this model, it is assumed that the time and cost of every integration
step can be described by normal distribution functions (Elmaghraby 1997, pp. 321
364).
A Monte Carlo test is a common method for finding the most likely result of a
process. Adaptation to the integration optimization model can be done by drawing
uniformly distributed random variables (varying between the given bounds).
Applying dynamic programming to the drawn set establishes a set of optimal
strategies.
The Info-Gap approach (Ben-Haim 2001 pp. 63 - 69; Ben-Haim & Laufer1998, pp.
125-132) developed a robust design methodology for handling projects with inherent
uncertainty. This methodology assumes that there is a critical effort that the
project must meet. An uncertainty parameter is defined as the maximal fractional
deviation from the nominal effort of the various activities (with appropriate weights).
The robustness is the greatest value of the uncertainty parameter for which the
specified time requirement is satisfied. No statistical assumptions are needed to
characterize the integration activities.
Note that the rationale here is based on worst case considerations whereas in
statistical analysis we weigh all alternatives with their associated probabilities. In
principle, more a priori knowledge is assumed in statistical analysis regarding the
activity times. The issue of probabilistic vs. worst-case based decision making is
discussed by Ben-Haim (2001; 9-27). In the present study both approaches were
considered in order to deepen the understating of the underlying factors.
Implementation of the Info-Gap uncertainty in the integration model using dynamic
programming is similar to the statistical approach. As in the statistical model, the
variables are first considered as the nominal values and all the factors and time unit
costs are assumed to be given.

3. Tool Description

3.1 Introduction
The tool proposed in this paper is designed to serve project managers and integration
managers in finding the right integration path for their project and to build an optimal
plan.
The tools main abilities are:
1. Inserting and editing the project integration parameters;
2. Finding the optimal path for the project integration with or without uncertainties;
3. Examining a given integration path with or without uncertainties;
4. Saving and loading projects.
The tool's software has built-in flexibility. The flexibility makes the tool suitable for
various types of firms and as an integration research tool. The flexibility works on
three levels. The basic level is the user level here the user can exploit all the abilities
mentioned above. A higher level is the organizational level at this level the model
parameters can be calibrated to fit the tool to the organizational needs. The highest
level is the research level at this level parameters can be easily added or subtracted
and the user interface will be changed automatically. Additional models can be added
easily to the software.
 3.2 Basic Abilities
Tools basic abilities
Project unit management
Parameter settings and editing
Calculation of a specific integration path (manual operation mode)
Search for an optimal integration path (automatic operation mode).

Project Initialization. The users first step is project initialization (Figure 3). The
tool must have an initialized project to proceed to the next procedure. The user can
initialize the project in one of two ways:
Create a new project: Initiates a new project with default values.
Load a project: Loads an existing project.

Project Unit Management. This procedure enables the user to manage the units in
the current project (Figure 4). The user can add or remove units. The unit numbers
defined in this procedure is used for the parameter settings and integration path
calculations.

Parameter Settings and Editing. This procedure enables setting and editing of the
integration parameters (Figure 5). The tool will alert the user when an illegal value
has been detected. The calculation procedures will be available only after all the
parameters are entered and valid. Removing units using the unit management will
cause the applicable parameters to disappear. Adding units using the unit management
will add new parameters to be defined.

Calculation of a Specific Integration Path (Manual Operation Mode). The manual

operation mode is used for examining an integration path given by the project team
and for modifications of the optimal path given by the tool (Figure 6). When all the
units are determined and all the parameters have been given values, this procedure
enables the user to execute the integration, which consists of a number of steps. The
integration starts when all the units are in different groups and ends when all the units
are in one group. An integration step is the union of two groups, in order to form one
group. Once one group has been formed, the user can select two groups to be
integrated, as shown in Figure 6. For any integration step, the program presents a pie
diagram representing the effect of each parameter and presents the step cost and
duration.

Figure 3. Main Screen

 Figure 4. Unit Setting Screen

Figure 5. Parameter Setting Screen

 Figure 6. Manual Integration Screen

Search for an Optimal Integration Path (Automatic Operation Mode). This

procedure runs an optimization algorithm to find an optimal integration path (Figure
7). The user can choose optimal duration or optimal cost. The optimal path is
presented in the same way as in the manual operation mode. The results are displayed
in the same way as in the manual mode (Figure 6). The user can transfer the results
obtained here to the manual operation mode (the To Calculator button) in order to
make changes in the optimal path and examine the sensitivity of the integration to
variations in the unit integration order.

Figure 7. Optimal Search Screen

 3.3 Tool Assimilation Abilities
As mentioned above, the tool can be used on three levels: the user level, the
organization level and the research level.

User Level. This level is the programs base level. It is designed for the project or
integration manager. At this level, almost all the tool functionality is used as
presented in section 3.2.

Organizational Level. The organizational level is used for calibrating the model so
as to fit it to the organizational product type. At this level the model parameters
weight can be changed (Figure 8). The calibration takes place after the organization
has used the tool on some projects and learned about parameter behavior relative to
the firms product line. For each product line, the firm can use a different calibration
vector.

Figure 8. Calibration Screen

Research Level. Since the tool concept is new and the tool itself has not yet been
field-tested, it is important to enable users to modify the model. For example, the user
may want to fit the tool for use in a firm. The ability to modify the tool is very useful
for integration researchers wanting to explore new directions.
This level is for professional software users as functional changes in the model are
required. Parameters can be easily added or subtracted from the model by changing
the "xml file" (a type of text file); when changed, the user interface will be changed
automatically. The model can easily be changed by replacing a "dll file" (software
pack) or a new model can be added by adding a "dll file" and changing the "xml file".

4. Conclusions
A model based tool for evaluating integration effort is presented in this work. The
tool can be used at the planning stage, facilitating a better understanding of the
planned integration by investigating the system integration parameters and by
changing the integration path. An optimal path is one option offered by the tool. The
tools flexibility enables academic users to make changes in it that will advance
research in the field of integration.
An early version of the model has been used as a teaching tool for graduate systems
engineering students at Ort Braude College. The students are engineers with 3 to 15
years of experience and their positive feedback was encouraging. Nevertheless, the
tool has not yet been used in a real industrial project. Three factors the constraint
model, the calibration factor and the tool flexibility have shown that the tool has the
potential to work and deserves to be developed further. The constraint model can help
with any non-acceptable path the tool may produce. The calibration tool can help with
fitting the tool to a specific firm. Tool flexibility enables tool modifications according
to the field results. The tool is under development and currently is not ready for a
field test. Such a field test for the model is essential.

References
Ben-Haim, Y. 2001. Information Gap Decision Theory Oxford, UK: Academic
Press.
Ben-Haim, Y., and Laufer, A. 1998. Robust Reliability of Projects with Activity-
duration Uncertainty. ASCE Journal of Construction Engineering and
Management 124.
, 1998. Robust Reliability in Project Scheduling with Time Buffering.
Technion papers, laufer buffer buf.txt (Draft) TME 469 9.1.98.
Elmaghraby, S. E. 1977. Activity Network. New York, NY USA: John Willy & Sons.
Jorgensen, P. 2002. Software Testing A Craftsman's Approach. Rockford, Michigan
USA: CRC Press.
Sommerville, I. 2001. Software Engineering, Hoboken, New Jersey USA: Addison
Wesley..
Tahan, M. and Ben-Asher, J. Z. 2008. Modeling and Optimization of Integration
Processes Using Dynamic Programming. Systems Engineering 11 (2): 165
185.

BIOGRAPHY
Mr. Roy Benish was born in Haifa, Israel in 1981. Mr. Benish received a Practical
Engineer in Electronics certificate from Ort Biyalik in 2001and a Bachelor of Science
Degree (BSc) in Computer Engineering from Ort Braude College in 2010. Since 2001
Roy has worked as a technician and a software integration tester. In 2010 Mr. Benish
joined Astea International as an application programmer.

Dr. Meir Tahan was born in 1952 in Beer Sheva. Israel. Dr. Tahan received a
Bachelor of Science Degree (BSc) in Electronic Engineering from Ben-Gurion
University in 1977, a Master of Engineering Degree (ME) in System Engineering
from the TechnionIsrael Institute of Technology in 2001and a PhD in System
Engineering from the TechnionIsrael Institute of Technology in 2008. Since 1977
he has been involved with systems integration and systems engineering, working in
military and civilian projects. In 2010 Dr. Tahan joined Ort Braude College as a
lecturer in the graduate systems engineering program. He is a member in the leading
team of this program. In parallel, Dr. Tahan joined Plasan Ltd. as a leading testing
engineer.