Business Modeling of a Measurement-based Context:
A Methodological Process
Giulio D’Emilia, Gaetanino Paolone, Emanuela Natale, Antonella Gaspari and Denis Del Villano
Department of Industrial and Information Engineering and of Economics, University of L’Aquila, L’Aquila, Italy
Keywords: Use Case, Business Modeling, System Modeling, UML, Measurement, Uncertainty, Metrological
Abstract: A measurement-based context is a working environment where measurements, i.e. quantitative information
from measured quantities, represent a fundamental component and are relevant for behaviors, decisions and
scenario modeling. In such a context, the Rational Unified Process has been customized in order to improve
the methodological approach for the business modeling. The aspects considered concern the analysis of the
involved stakeholders, the measurements concepts to be shared among them and the way this sharing can be
realized for suitable use of the information deriving from measurements. The effects of this study in terms
of definition of the business modeling team, insertion of some specific input documents and increase of
ability of transferring the real physical meaning of the measurement information in the business modeling
process are discussed. The methodological improvements contributing to an aware cooperation among
stakeholders involved are argued.
Nowadays measurements, i.e. quantitative
information from measured quantities, represent a
fundamental component of Enterprise Information
Systems (EIS) and they play a key role in
organizations (D’Emilia, 2014a).
A measurement-based context is intended as a
scenario where measurement data assume a great
relevance with respect to industrial behaviors,
decisions and models describing the applications to
be faced. When this situation has to be faced, care
should be paid with reference to the peculiarity
meaning and characteristics of quantities and
numbers deriving from measurement activity; in
fact, their meaning is definitely different from what
the numerical data represent referring to the
“general” data management (e.g. bills, accounting
and/or administrative records and documents)
(Paolone, 2008a). Moreover, this difference
increases with the amount of processing operations,
derived from experimental data.
Obviously, in both cases (measurement data on
one hand, and general data on the other hand)
numbers representing quantitative entities have to be
managed, but both meaning and characteristics are
quite different.
In fact, first of all, measurement data are strongly
connected to the physical reality, since they quantify
the physical quantities, i.e. the entities able to
quantitatively represent and describe the physical
phenomena. Furthermore, measurement numbers
should be completed by the indication of the
measurement uncertainty, which is itself a direct
derivation of the characteristics of the real situation
where measurements are realized; these
characteristics are generally difficult to model,
therefore the real situation is intrinsically complex
and casual. On the contrary, the numbers of bills or
of accounting documents (just to refer to the above
example) represent deterministic data, deriving from
operational and/or commercial procedures, that are
A further aspect to be taken into account is the
human attitude towards casual situations: generally,
the possibility of acting and thinking with a
deterministic point of view without probabilistic
considerations is by far preferred. On the other hand,
the intrinsic random nature of measurement data
cannot be neglected: they are the final result of an
operational process which is affected by many
factors of different type (technical, environmental,
operational, instrumental). In this way, they
D’Emilia G., Paolone G., Natale E., Gaspari A. and Del Villano D..
Business Modeling of a Measurement-based Context: A Methodological Process.
DOI: 10.5220/0005499402690276
In Proceedings of the 10th International Conference on Software Engineering and Applications (ICSOFT-EA-2015), pages 269-276
ISBN: 978-989-758-114-4
2015 SCITEPRESS (Science and Technology Publications, Lda.)
represent the effective scenario where the
measurements are made. Facing a random situation
appears to be an unavoidable requirement.
Therefore, business modeling must highlight this
difference. In other words, we believe that business
modeling should correctly take into account the role
of measurements in the EIS. In fact, if previously
and correctly validated, measurements are credited
to the ability to provide objective information based
on physical elements. Measurements and their
uncertainty represent engineering parameters, able to
model the systems and the processes of interest,
from both technical and economic point of view,
these latters intended to be, for example, investments
in measurement instrumentation or in personnel
metrological training and education.
Some approaches that consider, as common
practice in modeling processes, the engagement of
anyone who has some specialized knowledge of the
business object [e.g., (Robertson, 2012)] exist in
literature; they give general guidelines to manage
expert contributions regardless of the adopted
modeling approach. Unfortunately, in our daily
experience, measurements are too often incorrectly
endorsed, managed and used and they lose the great
part of their informative content. For this reason, if
business modeling is not able to involve the specific
contributions coming from measurements (such as
their innate randomness nature), a relevant part of its
operating capability is strongly reduced.
A tailoring of the methodological approach for
business modeling of measurement-based context is
needed. A possible way to get this result, avoiding a
misunderstanding of measurement information, is to
approach in a systematic way the EIS modeling in a
measurement-based context.
In the present paper, taking advantage of the high
versatility of the RUP process (Kruchten, 2003a)
(RUP, 2001) a customized solution of the process is
proposed, aimed to the integration of some basic
metrological concepts into the process itself. Section
2 describes the state of the art about the business
modeling in the EIS, by means of a methodological
modification referring to the Business modeling
discipline. Section 3 introduces the general
measurement concepts to be considered priority for
the business modeling allowing us to individuate a
first approximation class of metrological core-
concepts, useful for a conscious treatment of a
measurement-based context. Section 4 describes the
proposed methodological process including the
specific funcions of each involved stakeholder and
section 5 outlines conclusions and future work.
Modern software development processes are
invariably iterative and incremental (Maciaszek,
2007). There are many variants of the typical
iterative and incremental development process.
Among the main variants, according to (Maciaszek,
2004), we can include:
The Rational Unified Process;
The model-driven architecture (MDA);
The agile development process.
Going ahead with the research activity started in
(D’Emilia, 2014a) (D’Emilia, 2014b), trying to
improve and ensure the continuity between business
modeling, system modeling, design, and
implementation according to the model driven
paradigm also in the specific measurement-based
context, we focus on the RUP software engineering
process, especially on the business modeling
2.1 Business Modeling in the Rational
Unified Process
The Rational Unified Process is an iterative and
incremental software engineering process developed
originally by Rational Software, and then by IBM. It
is a disciplined approach that helps who is involved
in a software engineering development process to
assign and manage tasks and responsibilities within
a development organization (RUP, 2001). Its goal is
to ensure the production of high-quality software
that meets the needs of its end-users, within a
predictable schedule and budget (Kruchten, 2003b)
(Jacobson, 1999).
The RUP is not only a guide for how to
effectively use the Unified Modeling Language
(UML) but also it provides detailed and practical
guidance through all phases of the software
development life cycle. The Rational Unified
Process enhances team productivity by providing
easy access to a knowledge base with guidelines,
templates and tool mentors for all critical
development activities. By sharing with all the team
members the same knowledge base, it is able to
ensure that all team members share a common
language, process and view of how to develop
software. It is very important to underline that no
single process is suitable for all software
development. Therefore the RUP process has been
thought to be tailored to suit a wide variety of
projects and organizations (Kruchten, 2003b) and to
be varied to accommodate different real life
situations providing effective support for
configuring the process to suit the needs of a given
organization. For this reason, also in a measurement-
based context, we decided to use the RUP based
approach introduced in (Paolone, 2008b) (Paolone,
The process can be described in two dimensions
(Figure 1):
the horizontal axis represents time and shows
the dynamic aspect of the process as it is
enacted, and it is expressed in terms of cycles,
phases, iterations, and milestones;
the vertical axis represents the static aspect of
the process: how it is described in terms of
activities, artefacts, workers and workflows.
Figure 1: The RUP: overview (SCE, 2015).
For the purpose of this paper, the most important
phase is the inception phase. During the inception
phase the business case for the system and the
project scope limits are established. This involves
identifying all use cases and describing a few
significant ones (the most important or the most
complex ones). The outcomes of the inception phase
are several documents such as a vision document
expressing a general vision of the core project's
requirements, an initial (partial) use-case model, an
initial (and optional) project glossary that can be
expressed as a domain model, and so on. The
process is also described by meaningful sequences
of activities that produce some valuable result and
show interactions between workers: the workflows.
The RUP proposes the most essential type of
workflows in the process as the Core Workflows
(Figure 1): those workflows are revisited again and
again throughout the project lifecycle.
For the purpose of this paper we are very
interested in the business modeling discipline
(Figure 2).
A good business modeling permits to understand
the structure and the dynamics of the target
organization and ensures that customers, end users,
and developers have a common understanding of the
target organization.
Figure 2: Business modeling discipline: overview
(Kruchten, 2003b).
The main roles involved in the business
modeling are:
The Business-Process Analyst: that leads and
coordinates business use-case modeling by
outlining and delimiting the organization
being modelled;
The Business Designer: that details the
specification of a part of the organization by
describing one or several business use cases,
determines the business workers and business
entities needed to realize a business use case,
and also how they work together to achieve
the realization.
Also involved in this discipline are:
Stakeholders, who represent various parts of
the organization and provide input and review
(end-users and customer);
The Business Reviewer, who reviews the
resulting artefacts.
In a business modeling that is carried out in a
measurement-based context, it seems to be necessary
to identify the basic concepts of measurements to be
taken into account; these basic concepts should be
defined and described with the aim of sharing their
true physical meaning and usefulness with all the
actors of the modeling itself, taking care about all
the specific aspects linked to the measurement data.
These aspects should be known by all project
The effort of addressing the definitions to the
modeling process is expected to improve the
efficaciousness of the modeling procedures in a very
large range of possible applications of industrial
The authors are aware that the technical and
professional background of people involved in these
applications is usually different between each other;
for this reason the methodological approach has to
be faced very carefully and it has to be intended as a
first step to be possibly extended in the future. It is
to be noticed that customers also should be involved
in this action of sharing the physical meaning of
concepts, for a good transfer of their requirements to
the business modeling experts.
Furthermore, the authors are conscious that the
VIM - International Vocabulary of Metrology
(JCGM, 2012) is the “address”, where the correct
definitions of metrological terms are found, in
particular if the need of general validity of
definitions is considered.
The aim of sharing the basic metrological
concepts with the stakeholders involved in business
modeling, probably requires that the definition of
concepts to be used in this specific task are fitted to
their typical professional background; the physical
meaning of experienced practice will be also able
and useful to suggest a few formal, and not
substantial, modifications with respect to the
standard approach of VIM (D’Emilia, 2015).
In the following, the bases of the methodology
are defined in order to draw a sort of guide lines
supporting conscious and rigorous management and
analysis of measurement data, during the modeling
For a complete sharing of the measurement
theory, many concepts must be treated and
considered. In this section only a preliminary
number of arguments is analyzed.
The selection criteria mainly refer to these
meaningfulness and relevance of the concepts
with reference to typical decisional situations
and to the relationships between all the
possible actors involved in the industrial
processes (supplier/customer, for instance);
physical representativeness and possibility of
being transferred into the business modeling
actions, preserving good consciousness of all
the involved actors in the business modeling
general interest of the concepts for different
applications and possibility of realizing guide
lines of industrial inter-sectorial validity.
A simple and coarse example is now described,
in order to underline the importance of correctly
using the metrological concepts in an engineering
application of industrial safety.
A tank is considered in an industrial plant; its
working model requires that the safety valve has to
be open by a control system when the real pressure
of the fluid is 2.0 bar, in order to avoid structural
problems of the tank itself. If a typical measurement
configuration is considered, the control system is
driven by a pressure transducer with a measuring
range of 4.0 bar; furthermore, the whole measuring
uncertainty is 0.1 bar with a level of confidence in
the order of 95% and the pressure transducer has
been calibrated before use. In this case, if the
measured pressure by the transducer is 1.9 bar, a
probability of 2.5% can be assumed that the limit
pressure of 2.0 bar was overcome in the tank. If this
level of risk is considered acceptable, the control
system must open the valve when the measured
pressure is 1.9 bar.
In a latter case, if the opening of the safety valve
is set in correspondence of a measured pressure of
2.0 bar, with a threshold set in a deterministic
manner, it has to be assumed a probability of 50 %
that the limit pressure of 2.0 bar was overcome in
the tank at the opening of the valve.
It is quite evident that the latter approach is
remarkably less safe, even though this consciousness
is difficult to be shared with people not expert of
measurements. In this case the needed concept is the
expanded uncertainty and it will be discussed
In this first step of the methodological approach,
being at a very general level, both theoretical
concepts and procedures will be analyzed together.
The priority metrological concepts and
procedures are re-elaborated and presented in the
following trying to underline the practical relevance
of them:
True value: the unique value representing the
physical quantity to be measured in an
exhaustive manner; if the actor refers to it and
the operational and/or decisional models are
correct and completely valid, the selected
actions realize the right solution of the
problem. Furthermore, if all the actors
involved in any situation refer to it, no
misunderstanding can occur, being the target
exactly the same.
It is to be pointed out that the knowledge of the
true value involves the availability of a very large
(theoretically infinite) amount of information about
the problem; in practical cases it is obviously
impossible to get it by preliminary considerations or
by the measurement process.
Typically, the answer to the question what’s the
true value?” should be given according to the
indication of an interval of values comprising the
true value with a given level of confidence.
The half-amplitude of this interval corresponds
to the expanded uncertainty obtained from the
standard uncertainty. This approach requires that
measurements are not affected by any systematic
error; this result is achieved if any measuring
instrument is calibrated before use.
Usually this way of operating is fully satisfactory
from a practical point of view, even though it
appears complicated.
Measurement uncertainty: it represents the
variability of measurements, being all the
values ascribing to the quantity to be
measured. The variability is strictly depending
on the reality of the measurement process. All
the aspects influence it, like performances of
instrumentation and correction of the
systematic measurement error, skill of the
operator, simplified models and assumptions,
environmental conditions, The standard
uncertainty is the statistical indicator of it,
representing the operating context where
measurements are carried out. As a rule of
thumb, it increases as the approximations, the
simplifications and the limitations with respect
to any aspect, increase;
Expanded measurement uncertainty: it is
the way to combine the datum expressing the
measurement and the level of confidence: it
defines the interval around the measurement
datum where you are confident the true value
is, with a given level of confidence.
It is to be noted that an engineering answer
should give an indication of the relevant level
of confidence. This information has to be
treated as an engineering parameter, to be
optimized by a trade-off procedure. In most
cases, decisions and actions to be carried on
could change depending on the acceptable
level of confidence of reaching the set
objectives; in fact, the resources and the
requested investments depend on the level of
Systematic measurement error: it represents
the systematic difference of all measurements
with respect to the situation the systematic
measurement error does not occur.
To be absolutely avoided for more reasons:
the target of measurements is varied with
respect to the true value and, furthermore, the
systematic variation is remarkable with
respect to the random variability.
Both these conditions are very detrimental for
the usefulness of the measurement, the former
making useless statistical operation usually
adopted for improving quality of
measurements (mean of repeated
measurements), the latter since standard
procedures loss their meaning;
Level of confidence: fraction from 0 to 1 of
the values reasonably ascribed to the quantity
to be measured being in the interval defined
by the expanded uncertainty. In other words, it
is the probability that the true value of the
quantity is included in the interval defined by
the expanded uncertainty;
Calibration: procedure to estimate the
systematic measurement error and the
calibration uncertainty with reference to
defined conditions. By using these estimates,
the systematic measurement error could be
corrected in measurements and the
measurement uncertainty also in operating or
field conditions can be estimated, by further
data processing.
Only by guaranteeing that a calibration
has been
realized before measurements, the previous
methodological approach can be assumed; provided
that the measuring devices are calibrated, the
measurements are expected to give reliable
information for typical practical purposes, like the
conformity check of products/processes and the
validation of theoretical models for industrial
process control.
Agreed the strategic importance of information
derived from measured values and their peculiarities,
and acknowledged in literature there are very few
examples that can be supportive (Wen, 2009), we
are going to define a first step towards the definition
of a RUP-based modeling approach to be used in
contexts in which measurement data are central. The
modeling approach we are going to propose is
independent of the specific scope but applicable to a
whole class of application contexts: the
measurement-based contexts.
Our experience suggests that modeling a
software system supporting an organization working
within a measurement-based context, where
information derives from data that are pure
expression of physical concepts, needs to be treated
differently from those the information derives from a
conceptual modeling of the reality (e.g.,
measurement data are conceptually different from
data treated in invoices). Data expressing the value
of a measured quantity have the burden of
representing physical aspects and, as such, need to
be treated as not to lose meaning. Therefore we
believe it is necessary a substantial change in
managing the information arising from
measurement. So, in modeling those systems, we
believe a paradigm change is needed. The first step
towards a paradigm shift in the methodological
approach concerns a change in the business
modeling: the business-modeling team must have
the awareness of measurement’s peculiarities and of
the need for such a paradigm change in their
Any RUP-based software development approach
considers the business modeling disciplines in the
inception phase. The purpose of this workflow is to:
describe the initial requirements;
discriminate the critical business use cases of
the system (that is the primary scenarios of the
behaviour that will drive the system's
assess the status of the organization and
develop a first understanding of the goals and
objectives of the target organization.
Upon all these items, stakeholders and the
business-modeling team should agree.
At this stage, the RUP requires a close
interaction among business analysis roles (Business-
Process Analysts, Business Designers and Business
Reviewers) and, mainly, two stakeholders: Customer
and End-User.
Leveraging the great capacity for customization
provided by the RUP and the chance to tailor it to
the specific context's needs, our proposal provides
for the introduction of a new stakeholder at an early
stage of development, already: we call this
stakeholder the Measurement Expert.
The Measurement Expert, in this context, is a
crucial stakeholder. She/he not only deeply knows
measurement and the metrology (regardless of the
particular application context) but has a good
practice too. From these skills the need of her/ his
participation comes: the theoretical knowledge on
one hand, the more practice on the other allow her/
him to analyze the impacts and the correctness of the
measurement regardless of the specific practical
case. For this reasons, we believe it is necessary and
unavoidable to insist on the participation of this
stakeholder in all the business modeling activities.
It is important that underlining the insertion of
the Measurement Expert stakeholder does not
represent a competence increase but rather a change
in the process. It is not a technical addition, inherent
to a single practical case but a methodological
change impacting on an entire class of problems. In
fact, measurements can concern several scopes of
application and our proposal does not bind to any
specific application area but has the aim to concern
the general use of measurement data.
It should also be clarified that, as it might seem
at first sight, the Measurement Expert is not a
Domain Expert (that is an expert in functional
aspects of processes and supporting systems) but
she/he is an expert of metrology and measurement.
So, she/he not necessarily must deeply know the
specific application context but she/he must be able
to manage measurement data and to understand
information deriving from them. The presence of the
Measurement Expert is necessary because generally,
in our daily experience, End Users and Customers
do not have any adequate sensitivity about the
proper handling and use of measurement data. This
is because they have different perspectives on the
problem and different needs that must be addressed.
Finally, it is moreover important to emphasize
that the understanding of the actual meaning of the
measurements also allows the early detection of
possible sources of error due, for example, to an
excessive demand for information related to
measurements. A typical example is the claim, by
the management, to make decisions based on
threshold values, rather than on bands - thus
ignoring the basic principles of measurements (in
particular, the true value concept). This kind of
errors, being related to some conceptual aspects or
misunderstandings about the data interpretation, are
very impactful in the project management because it
is difficult to detect and mitigate them. Even on this,
thanks to its peculiar skills, the Measurement Expert
has a positive effect.
The Measurement Expert’s tasks are:
sharing the concepts of measurement with the
business analysis team (Section 3);
as regards the understanding of metrological
concept, being the link between business
analysis team, Customers and End-Users;
keeping the focus on the physical
characteristics of the measurement data;
helping in early detection of problems and/or
potential errors in the use of information
derived from measurements;
actively participating in the review activities
of the business use-case model and the
business object model.
In order to achieve an effective business model,
as to be a reliable starting point for the next analysis
phase, it is therefore clear the need to involve the
Measurement Expert in all the workflow details
provided for the business modeling discipline (see
Figure 2).
The set of core concepts meticulously studied
and developed by the working group (composed of
software engineers and measurement and
instrumentation engineers) (see Section 3) must be
made available as an input document supporting the
modeling activities (Measurement core-concepts
document). In it, the basic concepts are presented in
a formally and conceptually correct way but
enriched with specific competences and actual
experiences that could support others stakeholders in
the understanding of their importance. Because of its
importance, this document should be considered a
fundamental input for the business modeling process
when it is carried out in a measurement-based
By way of example, figure 3 shows the
Measurement core-concepts document and the
Measurement-expert stakeholder in the Assess
Business Status workflow detail, part of figure 2.
Looking at figure 3 and at the other workflows
details considered in the business modeling
discipline (Figure 2) it is clear that the insertion of
the Measurement Expert stakeholder and the
Measurement core-concepts document, produces, in
cascade, positive effects on the construction of all
the documents and artefacts that make up the
business model.
Figure 3: The modified Assess Business Status workflow
As an example, the industrial safety case proposed in
Section 3 has been modeled by two different teams
having similar skills. The first one involved in the
business modeling mainly the customer, the
domanin experts and the end-users. The latter one
also involved the Measurement Expert and shared
the Measurement core-concepts document with all
stakeholders. The document allowed sharing the
measurement basic concepts necessary to manage
the measurement-based decisional process.
Comparing the produced artifacts it is clear the
second team produced a more accurate and
conceptually correct business model. For example
the business event (construct used to clearly define
the conditions under which the event occurs) named
HighPressure (see Figure 4) is described with
reference to the desidered Confidence Level (as it is
correct from an engineering and operating point ov
view). Simply taking into account a threshold value
it would have been an incomplete solution with
respect to the safety application; the prevention of
risk requires a probabilistic approach being
impossible achieving a zero-probability risk
solution. This business event was also in detail
described by a supporting Activity Diagram.
Figure 4: The business event called High Pressure.
The proposed approach has been also positively
tested in the industrial context presented in
(D’Emilia, 2014a) (D’Emilia, 2014b) and it allowed
to increase the reliability and the effectiveness of the
implemented decisional process.
In this paper a methodological approach has been set
to customize the business modeling discipline in a
measurement-based context.
The RUP process has been tailored to this
purpose, leading us to the following main results:
identification and description of priority
metrological concepts useful for the business
modeling in a measurement-based context;
insertion of the Measurement Expert as a
crucial stakeholder in the business modeling
discipline carried out in the inception phase.
His role is different from a general Domain
Expert role;
insertion of a specific input document (the
Measurement core concept document)
supporting an efficient and effective sharing
of the measurement concepts with the
business modeling team.
These results represent an effective, even though
preliminary, contribution to an aware cooperation
among stakeholders involved in business modeling
of a measurement-based context. The improved
cooperation will contribute to a better interpretration
of the information deriving from measurement data.
The attention is paid to the inception phase so
far, nevertheless according to the proposed
methodological approach, the Measurement Expert
is also expected to give a contribution in the next
RUP phases: the elaboration, the construction and
the transition ones. Future work will focus on the
evaluation of these perspectives.
D'Emilia, G., Paolone G., Natale E., Gaspari A., Del
Villano D., 2014a. A Measurement-oriented
Modelling Approach - A Step Forward. In
proceedings of the 9th International Conference on
Software Engineering and Applications 2014, pp. 137-
D'Emilia, G., Paolone G., Natale E., Gaspari A., Del
Villano D., 2014b. A Measurement-oriented
Modelling Approach – basic concepts to be shared.
Software and Technologies. Revised Selected Papers
of the 9th International Conference on Software
Engineering and Applications. Wien, Austria, August
29-31, 2014. Springer Communications in Computer
and Information Science. Holzinger, Cardoso,
Cordeiro, Libourel, Maciaszek and Marten Eds. (to
D’Emilia, G., Gaspari, A., Natale, E., 2015. Metrology
applied to the industry: main terms and their
interpretation. Internal report of DIIIE of University of
L’Aquila, Italy. Proposed to Measurement.
Jacobson, I., Booch, G., Rumbaugh, J., 1999. The unified
software development process. Addison-Wesley
Longman Publishing Co., Inc. Boston, MA, USA.
JCGM - Joint Committee for Guides in Metrology, 2012.
International vocabulary of metrology Basic and
general concepts and associated terms (VIM 3rd
edition). Paris: JCGM. Available at
Kruchten, P., Kroll, P., 2003a. Rational Unified Process
Made Easy-A Practitioner's Guide to the RUP.
Addison-Wesley Professional. 3
Kruchten, P., 2003b. The Rational Unified Process: an
Introduction. Addison-Wesley Professional. 3
Maciaszek, L., 2007. Requirements Analysis and Systems
Design. Pearson Education. 3
Maciaszek, L., Liong, B., 2004. Practical Software
Engineering. A Case Study approach. Addison-
Paolone, G., Clementini, E., Liguori, G., 2008a. A
methodology for building enterprise Web 2.0
Applications. MITIP 2008..
Paolone, G., Clementini, E., Liguori, G., 2008b. Design
and Development of web 2.0 Applications. ITAIS
Paolone, G., Clementini, E., Liguori, G., Cestra, G., 2009.
Web 2.0 Applications: model-driven tools and design.
ITAIS 2009.
Robertson, S., Robertson, J., 2012. Mastering the
Requirements Process: Getting Requirements Right.
Addison-Wesley Professional. 3
RUP - Rational Unified Process, 2001. Best Practices for
Software Development Teams. Rational Software
White Paper. TP026B, Rev 11/01.
SCE - School of Science and Computer Engineering,
2015. University of Houston - Clear Lake. Available
Wen B., Zhang L., 2009. Mapping Enterprise Process
Measure into Information Model. First International
Workshop on Education and Computer Science, pp.