4.

Recomendaciones Generales para contar puntos de función en MKII

El propósito de este capítulo es proporcionar a los usuarios del método MKII reglas más detalladas y
casos prácticos que van a ilustrar como se aplica el método en varias situaciones reales. La estructura del
capítulo corresponde con los cinco pasos del Proceso de Cuenta de MKII descrito en el capítulo 3.

4.1 Determinación del Punto de Vista, Propósito y tipo de la Cuenta.

As defined in Rule 1, the first important step before starting any MkII Function Point count is to decide
the ‘boundary’ of the application which has to be counted; this determines what functionality is included
and what is excluded.

Como definido en la Regla 1, el primer paso importante antes del comienzo de cualquier cuenta de Punto
de Función de MkII debe decidir 'el límite' del aplicación que tiene que ser contado; esto determina lo
que la funcionalidad es incluída y que es excluído.

The choice of the boundary depends on the viewpoint, and perhaps the purpose of the count. There are
three commonly encountered viewpoints.

La opción del límite depende del punto de vista, y quizás el objetivo de la cuenta. Hay tres puntos de vista
comúnmente encontrados.

4.2 Delimitar la frontera de la Cuenta.

· The Project Viewpoint. We wish to determine the size of the functionality delivered, i.e. the ‘work-
output’, by a specific application development or change project, or the functionality supported by a
specific application maintenance or support activity. The purpose might be that we wish to use the
resulting functional size measure as a component of measuring productivity of the project, or as a
component of estimating the effort to develop the project. In this case the boundary is drawn around the
functionality delivered by the project team or as maintained by the support team.

· el Punto de vista De proyecto. Deseamos determinar el tamaño de la funcionalidad entregada, esto es

'la salida trabajo', por un desarrollo específico de aplicación o el proyecto de cambio, o la funcionalidad
apoyada por un mantenimiento específico de aplicación o la actividad de apoyo. El objetivo podría
consistir en que deseamos usar la medida de tamaño funcional que pasa como un componente de medir
la productividad del proyecto, o como un componente de estimar el esfuerzo de desarrollar el proyecto.
En este caso el límite es dibujado alrededor de la funcionalidad entregada por el equipo de proyecto o
como mantenido por el apoyo el equipo.

· The Application Manager Viewpoint. We wish to determine the total size of applications which support
a specific business functional area, and which are managed as a unit by an Application Manager. The
purpose might be to track the extent of automation of the business area as it progresses each year, or to
measure the support productivity of the Application Manager’s team for that whole area. In this case the
boundary is drawn around the functionality supported by the Application manager’s team.

· el Gerente De aplicación Punto de vista. Deseamos determinar el tamaño total de los aplicacións que
apoyan un área específica funcional de negocio, y que es manejado como una unidad por un Gerente De
aplicación. El objetivo podría ser para rastrear el grado de automatización de el área de negocio como
esto progresa cada año, o medir la productividad de apoyo del equipo del Gerente De aplicación para
aquella área entera. En este caso el límite es dibujado alrededor de la funcionalidad apoyada por el
equipo del gerente De aplicación.

· The Business Enterprise Viewpoint. We wish to determine the total size of the application portfolio of
the enterprise for the purpose of asset valuation. In this case the boundary is drawn around the whole of
the portfolio of the Enterprise.
· el Punto de vista De negocio De la empresa. Deseamos determinar el tamaño total de la cartera de
aplicación de la empresa para el objetivo de valoración de activo. En este caso el límite es dibujado
alrededor la el todo el cartera de la Empresa.

The reason for distinguishing these different viewpoints is that the MkII FP counts arising from these
different viewpoints are not necessarily related in a simple additive way. Usually, the whole is less than
the sum of the parts. Examples will illustrate.

La razón de la distinción de estos puntos de vista diferentes es que el MkII FP cuentas que provienen de
estos puntos de vista diferentes no necesariamente es relacionado de un modo simple aditivo. Por lo
general, el todo es menos que la suma de las partes. Los ejemplos ilustrarán.

· The functional requirements of a Business area are developed in three successive application
development projects. For the purposes of estimating and of measuring the productivity of the three
separate projects, we need to count the FP’s delivered by each of the projects separately. However,
because of the architecture of the systems of this Business area in our example, each project had to deliver
some temporary, ‘throw-away’ functionality to convert data from the previous generation of applications,
and in addition some permanent interface files have to be created for the three applications to work
coherently.

· las exigencias funcionales de un área De negocio son desarrollados en tres proyectos de desarrollo
sucesivos de aplicación. Para los objetivos de estimación y de medir la productividad de los tres
proyectos separados, tenemos que contar el FP'S entregado por cada uno de los proyectos
separadamente. Sin embargo, debido a la arquitectura de los sistemas de esta área De negocio en
nuestro ejemplo, cada proyecto tuvo que entregar alguna funcionalidad temporal, 'desechable' para
convertir datos de la generación anterior de aplicacións, y además algunos archivos de interfaz
permanentes tienen que ser creados para los tres aplicacións para trabajar coherentemente.

Clearly, to measure the productivity of the individual projects, we need to count the total functionality
delivered from the Viewpoint of the Project Leader by each separate project. This would include the FP’s
of any ‘throw-away’ functionality, and of any interface files which that project had to provide. But when
measuring the final total or ‘nett’ functionality from the viewpoint of the Business area when all three
projects have been completed, we would not count the ‘throw-away’ functionality, and it may arise that
not all of the functionality implied in the interfaces is credited to the ‘nett’ functionality (see further the
discussion on interfaces below).

Claramente, para medir la productividad de los proyectos individuales, tenemos que contarnos la
funcionalidad total libró del Punto de vista del Líder De proyecto por cada proyecto separado. Esto
incluiría el FP'S de cualquier funcionalidad 'desechable', y de cualesquiera archivos de interfaz los que
aquel proyecto tuvo que proveer. Pero midiendo el total final o la funcionalidad 'nett' del punto de vista
de el área De negocio cuando todos los tres proyectos han sido completados, nosotros no contaríamos la
funcionalidad 'desechable', y esto puede surgir que no toda la funcionalidad implícita en los interfaces es
acreditada a la funcionalidad 'nett' (visto más lejos la discusión sobre interfaces debajo).

· A similar type of boundary problem arises when counting the FP’s delivered for client-server systems.
A client-server application could be developed by two sub-project teams, one specialising in PC client
applications, and the other in main-frame server applications. The application boundaries for the two
projects may well overlap, with some user functionality being dealt with by both projects. If we wish to
measure the performance of each development sub-project team separately, then the total functionality
delivered by each team would be counted separately. Alternatively, if we wish to size the integrated
client-server application, to measure the functionality delivered to the user or project sponsor,
then the overlapping functionality would not be double-counted.

· un tipo similar de problema divisorio surge contando el FP'S entregado para sistemas de servidor-
cliente. Un aplicación de servidor-cliente podría ser desarrollado por dos equipos sub-de proyecto, una
especialización en aplicacións de cliente de ORDENADOR PERSONAL, y otro en aplicacións de
servidor de unidad central. Las fronteras de aplicación para los dos proyectos bien pueden traslapar,
con alguna funcionalidad de usuario ser(siendo,estando) tratada con por ambos proyectos. Si deseamos
medir el funcionamiento de cada sub-proyecto de desarrollo el equipo separadamente, entonces la
funcionalidad total entregada por cada equipo sería contada separadamente. O bien, si deseamos poner
la talla el aplicación de servidor-cliente integrado, medir la funcionalidad entregada al usuario o el
patrocinador de proyecto, entonces la funcionalidad de traslapo no sería doble-|contada.

4.2 Dibujar la frontera para una cuenta

As shown in the preceding paragraph, where the boundary of an application is drawn for FP counting
depends on the intended viewpoint, purpose and use of the count. Drawing the boundary determines what
functionality is to be included in the count, and what excluded.

Como mostrado en el párrafo precedente, donde el límite de un aplicación es dibujado para el contar de
FP depende del punto de vista intencionado, el objetivo y el empleo de la cuenta. El dibujo del límite
determina lo que la funcionalidad debe ser incluida en cuenta, y que excluyó.

When the application boundary is drawn, it defines the conceptual border between the software and the
‘user’ (see further below). ‘Input data’ from the user crosses the boundary to enter the application.
‘Output data’ leaves the application and crosses the boundary to reach the user. Within the boundary are
the Data Entity Types (hereinafter referred to as ‘entities’, for simplicity) that are processed by the
Logical Transaction Types (hereinafter referred to as ’logical transactions’ or just ‘transactions’) of the
application.

Cuando el límite de aplicación es dibujado, esto define la frontera conceptual entre el software 'y el
usuario' (visto más lejos debajo). ' Los datos de Entrada ' del usuario cruzan el límite para entrar en
aplicación. ' Los datos de Salida ' abandonan(dejan) el aplicación y cruzan el límite para alcanzar al
usuario. Dentro del límite son los Tipos de Entidad de Datos (denominado de aquí en adelante como '
entidades, para la simplicidad) que es procesado por los Tipos de Transacción Lógicos (denominado de
aquí en adelante como ' las transacciones lógicas o solamente(justo) ' transacciones) del aplicación.

In the context of FPA, examples of ‘user’ are:

En el contexto de FPA, los ejemplos 'de usuario' son:

· Business User - e.g. a manager, a clerk, someone at a terminal, or some other person who enters data
into the application and receives output.

· el Usuario empresarial - por ejemplo un gerente, un empleado, alguien en un terminal, o alguna otra
persona quien entra en datos en el aplicación y recibe la salida.

· Automated User - another application or automatic data collection device that supplies data to or
receives data from the application being counted. (Note that an application can also be regarded as the
user from the viewpoint of a ‘lower-level’ piece of software such as a file handler or network access
device. But MkII FPA was designed to work at the business application level, and great care should be
taken about applying the method at lower, infrastructure software levels.)

· el Usuario Automatizado - otro dispositivo de colección de datos de aplicación o automático que

suministra datos a o recibe datos del aplicación ser(siendo,estando) contado. (Note que un aplicación
también puede ser considerado como el usuario del punto de vista de un pedazo 'de nivel bajar' de
software como un tratante de archivo o el dispositivo de acceso de red. Pero MkII FPA ha sido diseñado
para trabajar en el nivel de negocio de aplicación, y el gran cuidado debería ser tomado sobre la
aplicación del método en inferior, niveles de software de infraestructura.)

In all cases, data from the user which crosses the application boundary to be processed will:

En todos los casos, datos del usuario que se cruza el límite de aplicación para ser procesado va a :

· cause some part of the application to change state according to the requirements
of the user.

· causan a alguna parte del aplicación para cambiar el estado según las exigencias del usuario.

and/or
y/o

· cause data to be made available to the user.

· hacen que datos sean hechos disponible al usuario.

Drawing an application boundary must not result in incomplete logical transactions. Any logical
transaction must have some user input from across the boundary, do some processing on data entity types
within the boundary, and return output across the boundary.

El dibujo de un límite de aplicación no debe causar transacciones incompletas lógicas. Cualquier

transacción lógica debe tener alguna entrada de usuario de a través del límite, haga algún tratamiento
sobre tipos de entidad de datos dentro del límite, y devuelva la salida a través del límite.

Whether the requirements of the application are implemented in on-line or in batch mode is immaterial to
the FP count; there is no logical difference between data crossing the application boundary on-line, and
data crossing the boundary off-line (batch).

Si las exigencias del aplicación son puestas en práctica en en línea o en el modo de por lotes es
inmaterial a la cuenta de FP; no hay ninguna diferencia lógica entre datos que cruzan el límite de
aplicación en línea, y datos que cruzan (la por lotes) divisoria autónoma.

Figure 4.1 below shows a typical example of an application boundary from a business user perspective,
encompassing on-line and batch transactions.

Figure 4.1 debajo muestra un ejemplo típico de un límite de aplicación de una perspectiva de usuario
empresarial, abarcando en línea y transacciones de por lotes.

Figura 4.1 – Visión del Usuario de Negocio sobre la Frontera de la aplicación

Referring to figure 4.1, we can see that there is an on-line transaction that updates one database. This
transaction involves the user at a terminal holding an input/output dialogue across the application
boundary.

Refiriéndose a la figura(número) 4.1, podemos ver que hay una transacción en línea que pone al día una
base de datos. Esta transacción implica al usuario en un terminal que sostiene un diálogo de entrada /
salida a través del límite de aplicación.

In figure 4.1 there is also a batch transaction which accesses three databases. This transaction is initiated
in a production environment, under the control of the computer operators, and produces a report, which is
sent to the business application user. The input from the operators, who initiate the job, crosses the
application boundary, as does the output report that is sent to the user.

En la figura(número) 4.1 hay también una transacción de por lotes que tiene acceso sobre tres bases de
datos. Esta transacción es iniciada en un ambiente de producción, en control de los operadores del
ordenador, y produce un informe, que es enviado al usuario de negocio de aplicación. La entrada de los
operadores, quien inician el trabajo, cruza el límite de aplicación, como la salida relata que es enviado
al usuario.

There are three databases shown within the application boundary in figure 4.1. It does not matter for the
FP count of this application if one or more of these databases happens to be shared with other applications
that may create, read, update or delete data on the databases. For the purposes of the function point count
being described, the entities implied in all three databases are included within the application boundary as
they are referenced by the two transactions shown in figure 4.1, and the relevant entity references will be
counted in each of those transactions.

Hay tres bases de datos mostradas dentro del límite de aplicación en la figura(número) 4.1. Esto no
importa para la cuenta de FP de este aplicación si un o más de estas bases de datos pasan de ser
compartidas con otros aplicacións que pueden crear, leer, poner al día o suprimir datos sobre las bases
de datos. Para los objetivos de la cuenta de punto de función ser(siendo, estando) descrita, las entidades
implícitas en todas las tres bases de datos son incluidas dentro del límite de aplicación como ellos son
referido por las dos transacciones mostradas en la figura(número) 4.1, y las referencias de entidad
relevantes serán contadas en cada una de aquellas transacciones.

Databases can appear within the boundaries of any number of applications. The criterion for their
inclusion is simply whether or not the data is referenced by one or more logical transactions included
within the application being counted. Logical transactions, on the other hand, normally appear in only one
application, unless functionality is deliberately duplicated across more than one application.

Las bases de datos pueden aparecer dentro de las fronteras de cualquier número de aplicacións. El
criterio para su inclusión es simplemente si realmente los datos son referido por un transacciones o más
lógicas incluídas dentro del aplicación ser(siendo,estando) contado. Transacciones lógicas, de otra
parte, normalmente aparecen en sólo un aplicación, a no ser que la funcionalidad deliberadamente sea
duplicada a través más de un aplicación.

4.3 Interfaces

When an application boundary is drawn for the purposes of a particular FP count, it may result in
identifying ‘interfaces’ to other applications. In common understanding, the word ‘interfaces’ is used for
two physically different processes.

Cuando un límite de aplicación es dibujado para los objetivos de una cuenta de FP particular, esto puede
causar la identificación ' interfaces a otros aplicacións. En el entendimiento común, la palabra '
interfaces es usada para dos procesos físicamente diferentes.

· a file of ‘data’ (eg master data records, ‘transactions’, a string of messages, etc.) is made available as an
interface file from one application to be shared with another

· un archivo 'de datos' (eg registros de datos de amo(maestro), ' las transacciones, una cuerda de
mensajes, etc.) son hechas disponibles como un archivo de interfaz de un aplicación para ser compartido
con otro

· ‘data’ are transmitted via an interface, either one at a time or as a batch, from one application to another

· 'datos' son transmitidos vía un interfaz, o sea uno por uno o sea como una por lotes, de un aplicación a
otro

N.B. When we use the term ‘transactions’ in the above, these are not complete logical transactions in the
meaning of MkII FPA. Typically, these ‘transactions’ might be the input part of a set of logical
transactions. For example a file (or stream) of orders, or bank terminal withdrawals, would be the input
part of the logical transactions for the receiving application which is going to process them. (Remember, a
complete logical transaction always involves an input, process and output component, which leaves the
application in a self-consistent state.)

N.B. Cuando usamos el término ' transacciones en el susodicho, estos no son transacciones completas
lógicas en el significado de MkII FPA. Típicamente estos ' transacciones podría ser la parte de entrada
de un juego de transacciones lógicas. Por ejemplo un archivo (o la corriente) de ordenes, o bancario
retiradas terminales, sería la parte de entrada de las transacciones lógicas para el aplicación de
recepcioón que va a tratarlos. (Recuerde, una transacción completa lógica siempre implica una entrada,
el proceso y el componente de salida, que abandona(deja) el aplicación en un estado coherente.)

In the first type of interface above where one application shares a file with another, both applications, the
one making the interface file available (i.e. the application maintaining the file) and the other using (i.e.
reading) the same interface file, encompass this file within their boundaries. Therefore the entity types
implied in the file should be counted in the relevant logical transactions of each of the applications.

En el primer tipo de interfaz encima donde un aplicación comparte un archivo con otro, ambos
aplicacións, el que que hace el archivo de interfaz disponible (esto es el aplicación que mantiene el
archivo) y otra utilización (esto es la lectura) el mismo archivo de interfaz, abarca este archivo dentro de
sus fronteras. Por lo tanto los tipos de entidad implícitos en el archivo deberían ser contados en las
transacciones relevantes lógicas de cada uno de los aplicacións.

In the second type of interface above, the data transmitted across the common application boundary form
the output part of a logical transaction of the sending application, and similarly also the input part of a
logical transaction of the receiving application. As in the first type of interface above, any entity types
referenced by the transmitted data should be counted in both the sending and receiving applications, as
both process such data.

En el segundo tipo de interfaz encima, los datos transmitidos a través del límite de aplicación común
forman la parte de salida de una transacción lógica del aplicación de enviar, y de modo similar también
la parte de entrada de una transacción lógica del aplicación de recepción. Como en el primer tipo de
interfaz encima, cualesquiera tipos de entidad referidos por los datos transmitidos deberían ser contados,
y en enviar y aplicacións de recepción, como ambos tratan tales datos.

At first sight, these two types of interfaces seem to discuss different physical implementations of the same
logical requirement and thus might be expected to give identical MkII FP counts. But this is not
necessarily so – the two types of interfaces may result from distinct logical requirements.

A primera vista, estos dos tipos de interfaces parecen hablar de las puestas en práctica diferentes físicas
de la misma exigencia lógica y así podría esperar dar MkII idéntico FP cuentas. Pero esto no es
necesariamente tan - los dos tipos de interfaces pueden ser resultado de exigencias distintas lógicas.

Three cases below will illustrate how to apply the counting rules when interfaces arise. In each case it is
assumed that the Viewpoint requires each application processing the interface file to be sized separately.
In the table headings, ‘DET’ means ‘Data Element Type’.

Tres casos debajo ilustrarán como aplicar las reglas de contar cuando los interfaces surgen. En cada
caso es asumido que el Punto de vista requiere cada aplicación que procesa el archivo de interfaz para
ser puesto la talla separadamente. En los títulos de mesa, 'DET' significa(piensa) ' el Tipo de Elemento
de Datos '.

Case 1. Orders are entered on-line in Application A and validated, and accumulated on a file which can
be accessed directly by, i.e. shared with, Application B. The shared order file is within the boundary of
both applications, and hence the orders do not have to ‘cross an application boundary’ to be passed from
A to B. At some arbitrary time chosen by Application B, it processes the accumulated orders against a
Stock file and produces a summary report. Application A has no influence on when Application B reads
the file. Applications A and B both also read a master Customer file during their respective processing.

Caso 1. Las ordenes son entradas sobre - la línea en el Aplicación A y validados, y acumulados sobre un
archivo que puede ser tenido acceso directamente por, esto es compartido con, la B De aplicación. El
archivo de orden(pedido) compartido es dentro del límite de ambos aplicacións, y de ahí las ordenes no
tienen que ' cruzar un límite de aplicación ' para ser pasado de un a la B. En algún tiempo arbitrario
escogido por la B De aplicación, esto procesa las ordenes acumuladas contra un archivo de
Acción(reserva) y produce un informe sumario. El aplicación no un tiene ninguna influencia sobre
cuando la B De aplicación lee el archivo. Aplicacións A y la B ambos también leen un archivo de Cliente
de amo(maestro) durante su tratamiento respectivo.

Applic. Transaction Input DET’s Processing ER’s Output DET’s

A Order Entry 20 2 (Ord, Cust) 1 (Error /Confirm),
B Order Process 1 (Trigger) 3 (Ord, Cust, 10 (Ord Summary)
Stock)

Case 2. As Case 1, but before Application B begins to process the interface file, Application A sends a
notification that ‘on-line processing has completed’. There is therefore a separate transaction sent by
Application A, and received by Application B, that synchronises the two applications. If we are counting
both applications separately, this transaction should be counted in both applications.
Caso 2. Como el Caso 1, pero antes de que la B De aplicación comience a tratar el archivo de interfaz, el
Aplicación A envía una notificación que ' el tratamiento en línea ha completado '. Hay por lo tanto una
transacción separada enviada por el Aplicación A, y recibida por la B De aplicación, que sincroniza los
dos aplicacións. Si contamos ambos aplicacións separadamente, esta transacción debería ser contada en
ambos aplicacións.

Applic. Transaction Input DET’s Processing ER’s Output DET’s

A Order Entry 20 2 (Ord, Cust) 1 (Error / Confirm)
A Entry Complete 1 1 1
B Begin Order 1 (Trigger) 3 (Ord, Cust, 10 (Ord Summary)
Process Stock)

(Note: Case 2 gives a different count to Case 1. But in Case 1, Application A has no control regarding
which processing cycle of Application B will handle any specific Order. There is also in Case 1, arguably,
a requirement for a ‘transaction’ to Application B informing the latter that it may start its processing, but
this originates from somewhere other than Application A and has not been shown as required in Case 1. It
may, for instance, be a timed trigger, such as ‘Time_Of_Day’, or an operator intervention.

( Nota: el Caso 2 da una cuenta diferente al Caso 1. Pero en caso de aplicació A no tiene ningún control
en cuanto a el que el tratamiento del ciclo de B De aplicación manejará cualquier Orden(pedido)
específica. Hay también en caso de 1, posiblemente, una exigencia para 'una transacción' a la B De
aplicación que informa el éste que esto puede comenzar su tratamiento, pero esto origina de en algún
sitio otro que el un y no ha mostrado como requerido en caso de 1. Esto por ejemplo puede, ser un
gatillo de timed, como 'Time_Of_Day', o una intervención de operador.

Case 3. As Case 1, but each order, immediately after entry and validation, is transmitted ‘on-line’ by
Application A to Application B.

Caso 3. Como el Caso 1, pero cada orden(pedido), inmediatamente después de que la entrada y la
validación, son transmitidas 'en línea' por el Aplicación A a la B De aplicación.

Applic. Transaction Input DET’s Processing ER’s Output DET’s

A Order Entry 20 2 (Ord, Cust) 1 (Error, etc) plus
‘n’ *
B Order Process 5 (revali-dated) 3 (Ord, Cust, 10 (Ord Summary)
Stock)

* ‘n’, the count of the number of DET’s transmitted out across the common boundary depends on the
requirements for formatting agreed with Application B. If the 20 DET’s transmitted out are treated as a
block, unchanged in format from the data entered, count ‘one’. If all 20 DET’s are re-formatted to meet
the requirements of Application B, count 20.

* 'La n', la cuenta del número del DET'S transmitido de a través del límite común depende de las
exigencias para el formatear de la B estada de acuerdo De aplicación. Si el 20 DET'S transmitido de es
tratado como un bloque, inalterado en el formato de los datos entrados, cuenta "el que". Si todo el 20
DET'S es reformateado para encontrar las exigencias de B De aplicación, contarse 20.

Case 3 also differs from Cases 1 & 2 in that each Order is processed discretely and sequentially by both
Applications A & B. No additional notification messages are needed, as, upon receipt of each Order
transaction, Application B processes it and waits for Application A to transmit the next.

El caso 3 también se diferencia de Casos 1 y 2 en el que cada Orden(pedido) es procesada discretamente

y secuencialmente por ambos Aplicacións A y la B. Ningunos mensajes de notificación adicionales son
necesarios, como, al recibir de cada transacción de Orden(pedido), la B De aplicación lo procesa y
espera el Aplicación A para transmitir el siguiente.

In all of Cases 1, 2 & 3, Applications A & B may reside on the same or different processors. This is a
physical implementation detail which does not affect the functional size.
En todos los Casos 1, 2 y 3, los Aplicacións A y la B pueden residir sobre el mismo o procesadores
diferentes. Esto es un detalle de puesta en práctica físico que no afecta el tamaño funcional.

The General Rules therefore are as follows:

Las Reglas Generales por lo tanto son así:

(a) Input read from an Interface File: If information read from an interface file requires validation, then
count the input DET’s that require validation as part of a logical transaction of the receiving application.

(a) Entrada leída de un Archivo de Interfaz: Si la información leída de un archivo de interfaz requiere la
validación, luego contar la entrada el DET'S que requiere la validación como la parte de una
transacción lógica del aplicación receptora.

(b) Output transmitted across an Interface: Count the DET’s made available or transmitted across the
interface that have to be specially formatted for the receiving application in the output component of a
logical transaction of the transmitting application

(b) Salida transmitida a través de un Interfaz: Cuente el DET'S hecho disponible o transmitido a través
del interfaz que especialmente tiene que ser formateado para el aplicación de recepción en el
componente de salida de una transacción lógica del aplicación de transmisión

(c) The files made available or transmitted across an interface comprise DET’s which will may create or
cause updates of one or more entities. Count any references to these entities in the relevant logical
transactions of both the sending and receiving applications.

(c) Los archivos hicieron disponible o transmitieron a través de un interfaz comprenden el DET'S que
podrá crean o causan la modernización de un o más entidades. Cuente cualesquiera referencias a estas
entidades en las transacciones relevantes lógicas, y de aplicacións de recepción y enviar.

(d) Take care to understand any logical requirements to synchronise interacting applications and count the
transactions made necessary.

(d) Tener cuidado para entender cualesquiera exigencias lógicas para sincronizar aplicacións que
actúan recíprocamente y contarse las transacciones hicieron necesario.

(Note also that if the task were to produce the size of the combined system A+B as one unit, ignoring
interface considerations, then the relevant transactions and their sizes would be as in Case 1 above,
irrespective of how the requirements had been implemented.)

( La Nota también que si la tarea de produjera el tamaño del sistema combinado A+B como una unidad,
haciendo caso a consideraciones de interfaz, entonces las transacciones relevantes y sus tamaños
estarían como en caso de 1 encima, independientemente de como las exigencias había sido puesta en
práctica.)

4.4 Identificación de transacciones lógicas

Después de decidir el propósito de un estudio de Puntos de Función, y de delimitar la frontera adecuada,

la siguiente decisión más crítica cuando se realiza un FPA (Análisis de Puntos de Función) es identificar
correctamente el conjunto de transacciones lógicas involucradas. Esta sección pretende ayudar al lector a
identificar las transacciones lógicas correctamente y aclara algunas de las situaciones encontradas
normalmente.

Nota: Pruebas realizadas por expertos en Análisis de Puntos de Función MKII han demostrado que el
error mas corriente es omitir la identificación, y por lo tanto el cálculo de su tamaño, de las
Transacciones lógica del Sistema. La recomendación de esta sección para distinguir las transacciones
lógicas es, por lo tanto, especialmente importante.

Los usuarios del Análisis de Puntos de Función MKII deben darse cuenta de que al principio del ciclo de
vida de un proyecto, normalmente se establecen los requisitos de una forma muy general tal como “El
sistema debe ser utilizable por cualquiera que tenga familiarización con los convenio GUI”. La tentación
en esta etapa es decir que dicho requisito solo puede ser manejado con el Ajuste de Complejidad Técnica
(olvidándose de considerar su contribución al tamaño de Puntos de Función MKII)

Cuando estos requisitos ya se han acordado en detalle, muchos de estos requisitos “fácil de uso” habrán
influido en el contenido de proceso de información en diferentes Transacciones Lógicas, y por lotanto
este requisito habrá sido tomado en cuenta en el Tamaño Funcional MKII. Las transacciones Lógicas
contadas deben corresponder al conjunto acordado de requisitos lógicos asignados al
software a medir.

4.4.1 ¿Qué es una transacción lógica?

Las Transacciones Lógicas son el nivel más bajo de proceso de negocio soportado por una aplicación
software. Cada una de ellas consta de tres elementos: entrada a través de una frontera de aplicación.,
algunos procesos relacionados, y salida a través de la frontera de la aplicación.

La definición dice que:

Cada transacción lógica se arranca por un evento único del mundo exterior, o una petición de
información y, cuando se ha completado, abandona la aplicación en un estado auto consistente en
relación al evento único.

Esta sentencia requiere más explicación. A continuación examinamos las palabras clave.

Se arranca.
Cada transacción tiene una parte de entrada, un proceso asociado y una parte de salida –
Este proceso y salida ocurren como respuesta al estímulo proporcionado por la entrada
que as su vez corresponde con un evento en el mundo exterior

Único
En el Análisis de Puntos de Función, nos preocupamos solo de tipos de evento únicos –
ocurrencias sinónimas y múltiples se ignoran, siempre que se arranque el mismo
conjunto de proceso en cualquier caso. Es decir, se realiza la misma adquisición y
validación, las referencias son al mismo conjunto de entidades y el mismo formateado y
presentación. Las variaciones en el camino de proceso resultante de diferentes valores
de entrada en distintas ocasiones no se consideran que dan lugar a diferentes tipos de
Transacciones Lógicas. Todas las entidades que se puedan referenciar por todos los
posibles caminos de proceso deben contarse en la Transacción Lógica a que nos
referimos.

Evento de Interés
Las personas están interesadas en información de diferentes clases; dicha información
se origina cuando ocurren cosas en el “mundo real” por ejemplo, cuando se abre una
cuenta en un banco, cuando el ascensor llega a un piso específico, cuando un cliente
paga los productos que compró en la tienda, o cuando en un programa de televisión se
da la señal de comenzar la emisión. El “evento de interés” son aquellos que el software
de aplicación necesita para procesar la información.

Los eventos son:

 Atómicos. Los eventos son indivisibles y no se pueden descomponer en dos o más
eventos componentes a menos que cambie el nivel de abstracción (granularidad) de
la descripción que está haciendo, y por lo tanto el propósito y requisitos de la la
aplicación.
 Preservadoras de la Consistencia e Instantáneo. Cada evento o tiene lugar o falla
totalmente. No es posible un evento “que ha ocurrido parcialmente”.
 Detectable. Para poder almacenar la información sobre un evento, el evento debe
ser observable, o como mínimo se debe poder deducir de las observaciones.
 A estos criterios se les conoce como prueba ACID – Si un “evento” candidato falla uno
o más de los criterios anteriores, rechazarlo del modelo lógico de la aplicación.

En algunas circunstancias podemos concluir que los eventos de interés del mundo
exterior directamente genera mensajes que forma la parte de entrada de una transacción
lógica. En otras circunstancias, una aplicación software debe inspeccionar
periódicamente (por ejemplo haciendo polling) el mundo externo para determinar si ha
ocurrido un evento de interés, generando un mensaje de entrada para documentar un
resultado positivo. En cualquier caso, el mensaje resultante se le considera como la
parte de entrada de una transacción lógica (el mecanismo de detección simplemente es
detalle de la implementación). El mecanismo de polling es, desde luego, arrancado por
un evento del mundo exterior, que es el paso de una cantidad específica de tiempo.

Mundo exterior
Todo lo que está fuera de la frontera de una aplicación se considera como mundo
exterior de esa aplicación. Todos los usuarios de una aplicación existen en este mundo
externo, así como los sucesos que se registran en forma de eventos, y las peticiones de
información hechas por los usuarios de la aplicación. Afortunadamente, estos son solo
componentes del mundo exterior que necesitan una descripción para el propósito del
Análisis de Puntos de Función. Explicación, que por otra parte, es absolutamente
necesaria para establecer el contexto de la aplicación.

Petición de información
Las personas desean almacenar y recordar la información sobre los eventos, como se ha
indicado arriba . En orden a recuperar parte de esta información almacenada por la
aplicación, se puede hacer una petición (por un usuario en el mundo exterior). Esta toma
la forma de un mensaje de entrada, que arranca un proceso y una respuesta (salida), de
la misma forma que lo hace un evento. Las peticiones individuales son siempre
atómicas, preservadoras de la consistencia (ya que por definición no causan cambio de
estado), instantáneas y detectable. Por lo tanto, las peticiones de información (con
frecuencia llamadas “queries”) son una fuente esencial de transacciones lógicas.
Difieren de los eventos en que estos ocurren con independencia de la existencia del
software de aplicación mientras que las peticiones de información solo se hacen como
consecuencia de que existe la aplicación.

Totalmente completadas
La definición de una transacción lógica no especifica el tiempo entre la recepción del
mensaje de entrada y el final de la respuesta de salida, la duración puede ser unos pocos
microsegundos o años (en teoría). Sin embargo la transacción lógica comienza cuando
el eventos e ha detectado y está totalmente completado solo cuando la respuesta ha
abandonado la frontera de la aplicación.

Estado auto-consistente
Como se ha hincado arriba los eventos se definen como instantáneos, y las transacciones
lógicas se definen como que registran el hecho de que un evento ha ocurrido. Como un
evento no se puede descomponer, no puede ocurrir parcialmente, tampoco pueden las
transacciones lógicas que lo representa. La transacción debe ser totalmente exitosa o
fallar enteramente si la información almacenada en la aplicación debe ser correcta, es
decir ser auto consistente en relación al evento único. Ningún ítem individual de
información almacenada por una aplicación debe contradecir otro ítem de información –
si tal situación ocurriera como resultado de un fallo software, se diría que la aplicación
ha “perdido integridad”. (¡pero esto no se puede detectar normalmente por el Análisis de
Puntos de Función!)

4.4.2 CRUDL –Create, Read, Update, Delete, List

En una aplicación que almacena información sobre un conjunto de entidades (es decir un conjunto de
objetos de negocio), la presencia de cada entidad automáticamente implica la existencia de un conjunto
mínimo de transacciones lógicas. Este conjunto mínimo se le conoce coloquialmente con el acrónimo de
“CRUDL”, que quiere decir “Create, Read, Update, Delete and List”.

La situación particular de una entidad debe seguir una historia de vida minimalista iniciada por el evento
de creación (create), seguida de una secuencia de cero o más eventos de actualización (update) y
terminando con el evento de borrado (delete) lógico. Véase la figura 4.2. En cualquier momento de su
historia los usuarios de aplicación pueden pedir información, por ejemplo lectura (Read), para ver los
detalles de una situación específica de una entidad, o pedir una lista (List) de todas o una selección de las
situaciones de una entidad almacenada. Durante el primer intento de catalogar las transacciones lógicas de
una aplicación, se le aconseja al utilizador de este Análisis de Puntos de Función que asuma la presencia
de al menos estos cinco tipos de transacción (CRUDL) – aunque no todos los tipos puedan ser requeridos
en una aplicación determinada.

Figure 4.2: Historia Mínima y Más compleja de una entidad

Un análisis posterior puede poner en evidencia información más detallada en relación a la historia de las
entidades. En particular, usted puede esperar que encontrar un modelo que utilice un evento simple de
actualización (Update) es demasiado simplista. La mayoría de las entidades de negocio tienen una historia
mucho más rica, en donde cada instancia de la entidad pasa por una variedad de estados, sufriendo un
conjunto específico de cambios cada uno de los cuales está representado por una transacción lógica
diferente.

Nótese que la transacción llamada “Mantenimiento de Detalles del Cliente”, casi con certeza NO es el
nivel más bajo del proceso de negocio.

“Mantener” implica requisitos para una serie de transacciones lógicas tales como “Ver (View)” un ítem
existente, si <no encontrado> “añadir (Add)” un nuevo item, “Cambiar” el ítem visionado, o “Borrar” el
ítem, “Autorizar” el cambio hecho por personal nuevo, o “listar” la totalidad de ítems disponible, etc.

Cuando esté definiendo transacciones lógicas hágase las siguientes presguntas:

 ¿Quién la utiliza?
 ¿Porqué se necesita?
 ¿Qué es lo que hace?
 ¿Cuándo se inicia?
 ¿En que se diferencia de otras transacciones lógicas?

4.4.3. Catalogado de Transacciones lógicas

Se recomienda el siguiente enfoque cuando se analiza y definen requisitos software: producir

sucesivamente versiones refinadas de un catálogo de transacciones lógicas que son (o que son requeridas)
por la aplicación (o proyecto). Durante las primeras fases de análisis, el catálogo de transacciones
consistirá de una sencilla lista de los eventos candidatos y peticiones de información (en donde el término
“candidato” implica que todavía no se ha tomado definitivamente la decisión de su inclusión). Véase la
figura 4.3. Mientras se registran transacciones candidatas, si existe otras informaciones como por
ejemplo, el tiempo de respuesta requerido por la transacción o criterios de seguridad, puede ser útil
registrar esto también en el catálogo. Esto ayudará en el cálculo del Ajuste de Complejidad Técnica si es
requerido, y ayuda a documentar los requisitos tanto funcionales como calidad relativa.

Figura 4.3: Catalogo de Transacciones Lógicas Candidatas Anidadas (Clustered)

A medida que progresa el trabajo, la información se hace menos ambigua y los requisitos se acuerdan más
claramente. Se pueden añadir detalles progresivamente para describir las partes de entrada, proceso y
salida de cada transacción. Se pueden tomar decisiones de confirmación o rechazo, de transacciones
candidatas, y se pueden encontrar nuevas transacciones.

Cuando los requisitos software hayan sido completamente descritos en detalle, el catálogo de
transacciones contendrá toda la información requerida para realizar una medida de Análisis de Puntos de
Función MKII acertada y precisa. También puede proporcionar la información necesaria para controlar el
alcance y para realizar análisis de impacto cuando se propongan cambios posteriormente. Como ejemplo
de un catálogo de Catálogo de Transacciones completado con los detalles véase la figura 4.4.
(nuevamente aquí , el tiempo de respuesta y volúmenes serán también relevantes cuando se calcule el
Ajuste de Complejidad Técnica).

Figura 4.4: Catalogo de Transacciones Lógicas completado con detalles

4.4.4 Los tres elementos de una transacción lógica

Toda transacción lógica consta de los tres elementos, entrada, proceso y salida.
El MKII FPA hace las siguientes hipótesis básicas en relación al tamaño funcional de estos tres
elementos:
 el tamaño del elemento de entrada es proporcional al número de Tipos de Elementos de Datos –
Data Element Types (DET) procesados únicamente que componen el lado de entrada de la
transacción
 El tamaño del elemento de proceso es proporcional al número de Tipos de Entidades de Datos -
Data Entity Types (o entidades) que se referencian durante el curso de la transacción lógica.
 El tamaño del elemento de salida es proporcional al numero de Tipos de Elementos de Datos –
DETs procesados únicamente que componen el lado de salida de la transacción.

Como convenio del MKII FPA, cada transacción lógica debe tener, como mínimo, un tipo de elementos
de datos de Entrada, debe hacer referencia a un tipo de Entidad debe tener un tipo de elementos de datos
de Salida.

Cuando se examina el catálogo de transacciones lógicas que componen la aplicación software (o

proyecto), se tienen que sacar tres cuentas base de las anteriores: el número total de Tipos de Elementos
de Datos (DETs) de Entrada, el número total de Entidades Referenciadas y el número total de Tipos de
Elementos de Datos (DETs) de Salida. En las secciones 4.5 y 4.6 respectivamente se encuentran reglas
detalladas para identificar las entidades y los DETs de entrada y salida.

Los tres elementos entrada, proceso y salida representan cada uno información de procesado de diferente
naturaleza. Específicamente:

 el elemento de entrada consta de adquisición y validación de los datos entrantes bien sea
describiendo un evento de interés en el mundo exterior, o los parámetros de una petición de
información de la aplicación;
 el elemento de proceso consta de almacenamiento e recuperación (retrieval) de información que
describe el estatus de las entidades de interés en el mundo exterior;
 el elemento de salida consta de formateo y presentación de la información del mundo exterior

La funcionalidad involucrada para proporcionar cada uno de estos tres tipos distintos de información de
procesado es distinta. Por lo tanto, en MKII FPA, se utilizan tres factores de ponderación para permitir
combinar estos tres tipos de funcionalidades en un único valor para determinar el Tamaño Funcional
(Estos pesos han sido calibrados con esfuerzos relativos medios de la industria para las fases de análisis,
diseño, programación, pruebas e implementación, de forma que la escala del Tamaño Funcional MKII
proporciona una medida relativa media de la industria sobre el trabajo necesario para estas actividades)

4.4.5 Transacciones Lógicas en las Interfaces de Programas de Aplicación

Como se ha visto anteriormente, el definir la frontera de la aplicación clarifica las interfaces con el mundo
exterior a la aplicación y con los usuarios de la aplicación que existen en el mundo exterior. Cuando se
considera la entrada y salida lógicas de información, tiene pocas consecuencias la fuente y el destino de
mensajes específicos, por lo que para el propósito de nuestro MKII FPA solo estamos interesados en los
datos que cruzan la frontera de la aplicación. Sin embargo, algunos de los usuarios externos pueden ser
otras aplicaciones, y es interesante examinar las clases de situaciones que pueden ocurrir.

4.4.5.1 Interfaz del Programa de Aplicación (API) con otra aplicación

Dos aplicaciones Inter-operan de forma tal que se transmite información de la primera aplicación a la
segunda.

Figura 4.5 – Ejemplo de interfaz entre dos aplicaciones

En este ejemplo eventos del negocio arrancarán una transacción lógica que será tratada por una
aplicación, causando cambios en el estado de los datos retenidos por esa aplicación y una respuesta al
usuario de negocio. Como resultado de esta transacción se escribirán datos en un fichero. El fichero será
subsecuentemente leído y procesado por una segunda aplicación. Esta segunda aplicación es un software
desarrollado mantenido y gestionado separadamente, que tiene su propia frontera de aplicación. La
transacción ha completado su trabajo cuando abandona la primera aplicación en un estado consistente,
independientemente del éxito o fracaso del proceso proporcionado por la segunda aplicación.

La segunda aplicación lee la información contenida en el fichero y trata los registros que contiene como
un flujo de mensajes de entrada, cada uno de los cuales forma el lado de entrada de la transacción lógica.
Para maximizar la fiabilidad de la aplicación receptora deberá validar el contenido de datos del fichero
como si fuese información procedente de cualquier otra fuente. Por lo tanto, suponiendo que se ha
publicado y que las partes se adhieren a la estructura y contenido de la interface, las organizaciones
internas de las dos aplicaciones inter-operantes son independientes la una de la otra. Por lo tanto cumplen
con el principio de ingeniería de software de ocultamiento de información diseñado para favorecer el
bajo acoplamiento de los componentes software y por lo tanto maximizar la mantenibilidad y minimizar
los costes de soporte.

Para el propósito del MKII FPA, la información escrita en el fichero de interface se ve como elementos de
datos de salida de la transacción lógica que arranca el proceso. Adicionalmente, la aplicación receptora
verá los registros contenidos en el fichero de interface como el lado de entrada de una serie de
transacciones lógicas, y se podría esperar que la aplicación receptora contuviese el proceso
correspondiente que proporcionase una adecuada salida como respuesta.

4.4.5.2 Actualización de Ficheros Nominalmente ‘Owned By’ Otra Aplicación

In a situation somewhat different from that above, the first application might directly create entity types
stored as files more usually updated (and hence regarded as being owned by the second application).

En una situación algo diferente de esto encima, el primer aplicación directamente podrían crear tipos de
entidad almacenados como los archivos más por lo general puestos al día (y de ahí consideraron como
ser(siendo,estando) poseído por el segundo aplicación).

In this circumstance, no application program interface exists, as the first application is intimately
dependent on the internal structure of the second application. The second application would need to
perform no validation of input, as all the processing related to the initial stimulus is performed by the first
application. Hence, in MkII FPA, under these circumstances the creation of the files would be counted as
references to entity types taking place during the processing part of the logical transaction concerned in
the first application. Hence these files would be considered as being included within the boundary of the
first application.

En esta circunstancia, ningún interfaz de programa de aplicación existe, como el primer aplicación es
con intimidad el dependiente sobre la estructura interna del segundo aplicación. El segundo aplicación
tendría que realizar ninguna validación de entrada, como todo el tratamiento relacionado al estímulo
inicial es realizado por el primer aplicación. De ahí, en MkII FPA, en estas circunstancias la creación de
los archivos sería contada como referencias a tipos de entidad que ocurren durante la parte de
tratamiento de la transacción lógica afectada(preocupada) en el primer aplicación. De ahí estos archivos
serían considerados como ser(siendo,estando) incluído dentro del límite del primer aplicación.

Confusion may arise here because the concept of the ‘application boundary’ is commonly used in two
senses. One sense is the well defined MkII FPA concept of the application boundary. On the other hand,
sometimes a set of files and related software programs are allocated as the responsibility of a particular
maintenance team and are regarded as an ‘application’. This arises due to a political division of work and
responsibility. In such a case, the political boundary of the application may not coincide with the MkII
FPA concept of the ‘application boundary’.

La turbación puede surgir aquí porque el concepto de ' el límite de aplicación ' comúnmente es usado en
dos sentidos. Un sentido es MkII bien definido FPA el concepto del límite de aplicación. De otra parte, a
veces un juego de archivos y programas de software relacionados es asignado como la responsabilidad
de un mantenimiento particular combina y es considerados como 'un aplicación'. Esto surge debido a
una división política de trabajo y la responsabilidad. En tal caso, el límite político del aplicación no
puede coincidir con el MkII FPA el concepto de ' el límite de aplicación '.

4.4.5.3 Vista de usuario de la frontera de la aplicación

An application boundary can be drawn from a number of points of view. As components of transactions
can be recognised by examining the inputs and outputs where they cross the boundary, understanding the
nature of the boundary has a profound effect on the set of transactions identified. Consider the following
client/server application shown in Figure 4.6

Un límite de aplicación puede ser dibujado de unos puntos de vista. Como los componentes de
transacciones pueden ser reconocidos por examinando las entradas y salidas donde ellos cruzan el
límite, entendiendo la naturaleza del límite tiene un efecto profundo sobre el juego de transacciones
identificadas. Considere el aplicación de cliente / servidor siguiente mostrado en la Figura(número) 4.6

Figura 4.6 – Ejemplo de una aplicación cliente / servidor

In this example there is a PC that runs a client routine providing a GUI front end to the business user. The
routine accesses a network database residing on a local file server. This database contains a summary of
commonly used data that resides in a more complete form on a mainframe machine (possibly
geographically distant).

En este ejemplo hay un ORDENADOR PERSONAL que controla un rutina de cliente el suministro de un
frente de GUI el final al usuario empresarial. La rutina tiene acceso sobre una base de datos de red que
reside sobre un servidor de ficheros local. Esta base de datos contiene un sumario de los datos
comúnmente usados que residen en más forma completa sobre una máquina de unidad central
(posiblemente geográficamente distante).

When the user enters an enquiry on the PC, the local database on the file server is used to provide
information displayed on the screen. However, only summary data is shown. If the user wants more
detailed information, double clicking with the mouse causes the detailed data to be extracted from the
master database that resides on the mainframe. All updates that the user makes cause the summary
database on the network to be updated, as well as the mainframe master.

Cuando el usuario entra en investigación sobre el ORDENADOR PERSONAL, la base de datos local al
servidor de ficheros es usada para proporcionar la información mostrada sobre la pantalla. Sin
embargo, sólo muestran datos sumarios. Si el usuario quiere la información más detallada, doblar
chascar con el ratón hace que los datos detallados sean extraídos de la base de datos de amo(maestro)
que reside sobre la unidad central. Toda la modernización que el usuario hace la causa la base de datos
sumaria a la red ser puesto al día, así como el amo(maestro) de unidad central.

The two databases are used to improve response times. The network database, holding only summary
data, is quite small, and the response time for the majority of transactions, which only require summary
information, is very fast. On the few occasions when detailed information is required, the mainframe is
accessed, and the response time of the transaction is much longer.

Las dos bases de datos son usadas para mejorar veces de respuesta. La base de datos de red, sosteniendo
sólo datos sumarios, es bastante pequeña, y la respuesta el tiempo para la mayoría de transacciones, que
sólo requieren la información sumaria, es muy rápido. Sobre poca ocasión cuando la información
detallada es requerida, la unidad central es tenida acceso, y la respuesta el tiempo de la transacción es
mucho más largo.

The business user view of the system is shown in Figure 4.7, below.

La vista(opinión) de usuario empresarial del sistema es mostrada en la Figura(número) 4.7, debajo.

Figura 4.7 – Vista del Usuario de una aplicación cliente / servidor

The physical location of the data is of little concern to the business user. The user enters data and the
required responses are displayed. The fact that two physical databases are used is a technical solution
chosen for performance reasons. From the user perspective there is only one logical database. Duplicate
entity types in the two physical databases are perceived as single logical entity types. As there is only a
single boundary enclosing both the local and mainframe databases, logical transactions are recognised
only as their inputs and outputs cross this boundary. Inter-operation of the application components is
invisible to the business user and no logical transactions are recognised in the messages passing between
PC and mainframe.

La posición física de los datos es de pequeña preocupación(interés) al usuario empresarial. El usuario

entra en datos y las respuestas requeridas son mostradas. El hecho que dos bases de datos físicas son
usadas es una solución técnica escogida para motivos de funcionamiento. De la perspectiva de usuario
hay sólo una base de datos lógica. La entidad doble teclea las dos bases de datos físicas son percibidos
como tipos de entidad solos lógicos. Como hay sólo un límite solo que incluye, y el local y bases de datos
de unidad central, transacciones lógicas son reconocidas sólo como sus entradas y las salidas cruzan
este límite. La inter-operación de los componentes de aplicación es invisible al usuario empresarial y
ningunas transacciones lógicas son reconocidas en los mensajes que pasan entre el ORDENADOR
PERSONAL y la unidad central.

Example transactions might be…

Las transacciones de ejemplo podrían ser …

ID Transaction Name Event No. Response No. of Entity No.
or of Output Types of
Query Input DET Referred ER
DET to
T001 QUERY_CUSTOMER_SUMMARY_DATA Q 2 Display 5 Customer 1
Summary
Data
T002 QUERY_CUSTOMER_DETAIL_DATA Q 2 Display 20 Customer 1
Detail
Data

However…

Sin embargo …

…three groups of development staff were involved in building this application. And it is easy to imagine
a scenario whereby IS management is interested in the size of the application attributable to each team.
That is, how much did each team build?

…tres grupos de personal de desarrollo han sido implicados en edificio de este aplicación. Y es fácil
imaginarse que un guión por el cual ES la dirección está interesado en tamaño del aplicación atribuible
a cada equipo. ¿Es decir cuánto cada equipo construye?

Figure 4.8 shows the view of the project team that was involved in the development of the PC client
aspect of the application.

Figura 4.8 espectáculos la vista(opinión) del equipo de proyecto que ha sido implicado en desarrollo del
aspecto de cliente de ORDENADOR PERSONAL del aplicación.

Figure 4.8 - The PC Client Project Team’s View of the Boundary

In this scenario the user is the business user who initiates logical transactions triggering processing of
data held on the network file server.

En este guión el usuario es el usuario empresarial quien inicia el tratamiento de provocación de

transacciones lógico de datos se agarraron el servidor de ficheros de red.

As described previously, when the user double clicks the mouse button, detailed information is retrieved
from the mainframe database, via a mainframe server routine. From the PC Client project team viewpoint,
this is achieved via an interface with the mainframe application. The PC client outputs some data across
the application boundary, sending it to the mainframe server routine. This, in its turn, processes the
message passing back across the application boundary the data requested from the mainframe.

Como descrito antes, cuando el usuario chasquidos dobles el botón de ratón, la información detallada es
recuperado de la base de datos de unidad central, vía una rutina de servidor de unidad central. Del
proyecto de Cliente de ORDENADOR PERSONAL el equipo del punto de vista, esto es alcanzado vía un
interfaz con el aplicación de unidad central. Las salidas de cliente de ORDENADOR PERSONAL
algunos datos a través del límite de aplicación, enviándolo a la rutina de servidor de unidad central.
Esto, en su turno, procesa el mensaje que pasa atrás(trasero) a través del límite de aplicación los datos
solicitados de la unidad central.

Example transactions might be…

Las transacciones de ejemplo podrían ser …

ID Transaction Name Event No. Response No. of Entity No.
or of Output Types of
Query Input DET Referred ER
DET to
T001 QUERY_CUSTOMER_SUMMARY_DATA Q 2 Display 5 Customer 1
Summary
Data
T002 QUERY_CUSTOMER_DETAIL_DATA Q 2 Request to 2 Customer 2
mainframe System
T003 RECEIVE_DETAILS_FROM_MAINFRAME E 20 Display 20 System 1
Customer
details

In MkII FPA, and from the perspective of the project team, the size of the PC Client application includes
the DET’s output across the application program interface with the mainframe as part of the output side of
the triggering transaction. Additionally, the response from the mainframe is regarded as the input side of a
distinct logical transaction, triggering processing and the corresponding output to the business user.

En MkII FPA, y de la perspectiva del equipo de proyecto, el tamaño del aplicación de Cliente de
ORDENADOR PERSONAL incluye la salida del DET'S a través del interfaz de programa de aplicación
con la unidad central como la parte del lado de salida de la transacción de provocación. Además, la
respuesta de la unidad central es considerada como el lado de entrada de una transacción distinta
lógica, provocando el tratamiento y la salida correspondiente al usuario empresarial.

Figure 4.9 shows the project from the viewpoint of the mainframe project team.

Figura 4.9 muestra el proyecto del punto de vista del proyecto de unidad central el equipo.

Figure 4.9 - The Mainframe Project Team’s View of the Boundary

To the mainframe project team, the user is the PC Client. It is the PC Client that initiates logical
transactions requiring data to be processed on the mainframe.

Al proyecto de unidad central el equipo, el usuario es el Cliente de ORDENADOR PERSONAL. Es el

Cliente de ORDENADOR PERSONAL que inicia transacciones lógicas que requieren datos ser
procesado sobre la unidad central.

Input from the PC Client crosses the application program interface i.e. the boundary, is processed by the
mainframe server routine, which accesses the mainframe database, and causes output to be sent across the
application boundary back to the PC Client. In MkII FPA, and from the perspective of the project team,
each distinct kind of message received from the PC Client is regarded as the input side of a separate
logical transaction, with corresponding processing (in the form of references to logical entity types stored
on the mainframe database) and an output message (sent back to the PC Client).

La entrada del Cliente de ORDENADOR PERSONAL cruza el interfaz de programa de aplicación esto es
el límite, es procesada por la rutina de servidor de unidad central, que tiene acceso sobre la base de
datos de unidad central, y hace que la salida sea enviada a través del límite de aplicación atrás(trasero)
al Cliente de ORDENADOR PERSONAL. En MkII FPA, y de la perspectiva del equipo de proyecto, cada
clase distinta de mensaje recibido del Cliente de ORDENADOR PERSONAL es considerada como el lado
de entrada de una transacción separada lógica, con la correspondencia el tratamiento (en forma de
referencias a tipos de entidad lógicos almacenados sobre la base de datos de unidad central) y un
mensaje de salida (enviado atrás(trasero) al Cliente de ORDENADOR PERSONAL).

Example transactions might be…

Las transacciones de ejemplo podrían ser …

ID Transaction Name Event No. Response No. of Entity No.
or of Output Types of
Query Input DET Referred ER
DET to
T001 QUERY_CUSTOMER_DETAIL_DATA Q 2 Pass 20 Customer 1
Customer
Details to
PC

In addition to the PC Client and mainframe development teams, there was an infrastructure team that
developed the routines which were used for file access on the network server, and on the mainframe.
These routines were built so that they could be used by a number of future projects, that is, the
infrastructure team was responsible for designing and constructing re-usable components. Figure 4.10
shows the infrastructure team’s view of the project.

Además del Cliente de ORDENADOR PERSONAL y el desarrollo de unidad central equipos, había una
infraestructura el equipo que desarrolló las rutinas que han sido usadas para el acceso de archivo sobre
el servidor de red, y sobre la unidad central. Estas rutinas han sido construídas para que ellos pudieran
ser usados por unos proyectos futuros, es decir la infraestructura el equipo era responsable del diseño y
la construcción de componentes reutilizables. Calcule 4.10 espectáculos la infraestructura la
vista(opinión) del equipo del proyecto.

Figure 4.10 - The Infrastructure Project Team’s View of the Boundary

The infrastructure team produced two potentially r-usable routines. One routine provides database access
to the local summary database stored on the network server; the other routine provides database access to
the detailed data stored on the mainframe database.

La infraestructura equipo de producido dos rutinas potencialmente utilizables r. Una rutina proporciona
el acceso de base de datos a la base de datos local sumaria almacenada sobre el servidor de red; otra
rutina proporciona el acceso de base de datos a los datos detallados almacenados sobre la base de datos
de unidad central.

In MkII FPA, and from the perspective of the PC Client and Mainframe project teams, both these routines
are extensions to the programming language used for software development. They are bottom-up
components on a par with other programming language instructions such as IF…THEN…ELSE, MOVE,
READ…FILE, WRITE…RECORD, ADD A TO B, etc. Hence they are invisible to the business users,
and to the PC Client and the Mainframe application project teams.

En MkII FPA, y de la perspectiva del Cliente de ORDENADOR PERSONAL y el proyecto de Unidad

central equipos, ambos estas rutinas son extensiones al lenguaje de programación usado para el
desarrollo de software. Ellos son encima de profundizarás componentes sobre una par con otras
instrucciones de lenguaje de programación como IF…THEN…ELSE, EL MOVIMIENTO, READ…FILE,
WRITE…RECORD, SUMAN UN a la B, etc. De ahí ellos son invisibles a los usuarios empresariales, y al
Cliente de ORDENADOR PERSONAL y el proyecto de aplicación de Unidad central equipos.

They would not normally be sized by MkII FPA as application functionality.

Ellos normalmente no serían puestos la talla por MkII FPA como la funcionalidad de aplicación.

However, if it is desired to measure the potentially re-usable functionality developed by an infrastructure

support team, such routines can be measured using MkII FPA but great care should be taken. MkII FPA
was designed for use with software in the business applications domain, and applying it to infrastructure
software is extending its design envelope. Certainly, FPA values obtained from these distinct domains
should not be mixed together.
Sin embargo, si se desea para medir la funcionalidad potencialmente reutilizable desarrollada por un
apoyo de infraestructura el equipo, tales rutinas puede ser medido usando MkII FPA pero el gran
cuidado debería ser tomado. MkII FPA ha sido diseñado para el empleo con el software en el dominio de
aplicacións de negocio, y la aplicación de ello al software de infraestructura amplía su sobre de diseño.
Seguramente, FPA valores obtenidos de estos dominios distintos no debería ser mezclado juntos.

Note, that the level of granularity (i.e. the abstraction used) is more finely grained for the infrastructure
components than that used when drawing the application boundaries for the PC Client and Mainframe
components (which is itself a more finely grained abstraction than that used to draw the boundary from
the viewpoint of the business user). Also, separate boundaries should be drawn around each distinct set of
related bottom-up components, and disparate and unrelated components should not be lumped together.
This is because the logical model used to describe the context of one component will be different from the
logical model used to describe a separate, unrelated component. Any similarity is by chance and is liable
to lead to future confusion. Where different things are described, making clearly distinct descriptions
leads to less eventual ambiguity.

Note, que el nivel de granularidad (esto es la abstracción usada) es más de grano fino para los
componentes de infraestructura que esto usado dibujando las fronteras de aplicación para el Cliente de
ORDENADOR PERSONAL y componentes de Unidad central (que es una abstracción más de grano fino
que esto usado para dibujar el límite del punto de vista del usuario empresarial). También, fronteras
separadas deberían ser dibujadas alrededor de cada juego distinto de componentes relacionados encima
de profundizarás, y dispar y sin relaciones los componentes no deberían ser amontonados. Esto es
porque el modelo lógico usado para describir el contexto de un componente diferente de sobre el modelo
lógico usado para describir un separado, sin relaciones el componente. Cualquier semejanza es por
casualidad y es obligada de conducir a la turbación futura. Donde cosas diferentes son descritas,
haciendo descripciones claramente distintas conduce a la ambigüedad menos eventual.

Hence, in the case above, the routine used to provide access to the network database is enclosed in a
distinct boundary, and is sized separately from the routine used to provide access to the mainframe
database.

De ahí, en el caso encima, la rutina usada para proporcionar el acceso a la base de datos de red es
incluída en un límite distinto, y es puesta la talla separadamente de la rutina usada para proporcionar el
acceso a la base de datos de unidad central.

4.4.5.4 Distinción entre el tamaño Desplegado y el tamaño Entregado

The foregoing examples illustrate the impact of the user view and the corresponding understanding of the
application boundary.

Los ejemplos precedentes ilustran el impacto de la vista(opinión) de usuario y el entendimiento de

correspondencia del límite de aplicación.

· The business user viewpoint results in a size measure of the business functionality independent of the
application architecture and is sometimes referred to as the deployed size.

· el punto de vista de usuario empresarial causa una medida de tamaño de la funcionalidad de negocio
independiente de la arquitectura de aplicación y a veces es mencionado el tamaño desplegado.

· The project team viewpoint results in a size measure of each application that is separately designed,
developed and maintained, and the sum of such measures is sometimes referred to as the delivered size.

· el equipo de proyecto del punto de vista causa una medida de tamaño de cada aplicación que
separadamente es diseñado, desarrollado y mantenido, y la suma de tales medidas a veces es
mencionada el tamaño entregado.

· The infrastructure team’s viewpoint results in a size measure of all the software components that extend
the functionality delivered by the underlying operating system, middleware, database management
systems, network communications systems, etc., delivering this functionality not to the business user, but
to applications developers.

· la infraestructura el punto de vista del equipo causa una medida de tamaño de todos los componentes
de software que amplían la funcionalidad entregada por el sistema subyacente de operaciones,
middleware, sistemas de gestión de datos, conectan una red sistemas de comunicaciones, etc., entregando
esta funcionalidad no al usuario empresarial, pero a reveladores de aplicacións.

Each of the three measures above are derived using distinct abstractions and levels of granularity in the
descriptions used to describe their respective contexts. The terminology used in these descriptions will
invariably be different. Hence, such measures should be kept distinct. It rarely makes any sense to add
them together.

Cada una de las tres medidas encima es sacada usando abstracciones distintas y los niveles de
granularidad en las descripciones usadas para describir sus contextos respectivos. La terminología
usada en estas descripciones invariablemente será diferente. De ahí, tales medidas deberían ser
guardadas(mantenidas) distintas. Esto raras veces(poco probable) hace cualquier sentido de agregarlos
juntos.

4.4.6 Accounting for Housekeeping

4.4.6.1 Database Management and Integrity Functions

Database management and integrity functions are only included in a MkII FPA size when they represent
agreed business requirements, i.e. not technical or quality requirements. So a good question to ask is, ‘Is
this function specifically required by the application user as part of the business requirements?’. If the
answer is TRUE, then it is justifiable to include it in the FP count.

La gestión de datos y funciones de integridad sólo son incluídas en MkII FPA el tamaño cuando ellos
representan las exigencias acordadas de negocio, esto es no técnico o exigencias de calidad. ¿Entonces
una pregunta buena para preguntar es, ' esta función expresamente es requerido por el usuario de
aplicación como la parte de las exigencias de negocio? '. Si la respuesta es VERDADERA, entonces es
justificable incluirlo en cuenta de FP.

For instance, it is normally expected that a software application is complete and internally consistent.
Hence any functions required to check and maintain database integrity and performance (e.g. database
rebuild routines) are regarded as implicitly required implementation detail, and dictated by the choice of a
software solution. Such functions would be expected to be provided as a part of the operational
environment and to be executed by IS staff. They would not be included in a MkII FPA study as distinct
logical transactions.

Por ejemplo, normalmente lo esperan que una aplicación de software es completa e internamente
constante. De ahí cualesquiera funciones requeridas para comprobar y mantener la integridad de base
de datos y el funcionamiento (por ejemplo la base de datos reconstruye rutinas) es considerado como el
detalle de puesta en práctica implícitamente requerido, y dictados por la opción de una solución de
software. Esperarían que tales funciones fueran proporcionadas como una parte del ambiente
operacional y ser ejecutado por ES el personal. Ellos no serían incluídos en MkII FPA el estudio como
transacciones distintas lógicas.

However, if the business user requires specific functions to enable the end user to perform integrity
checks, to determine the percentage free space available and to initiate database rebuild processing, then
such functionality would be counted as logical transactions. The difference here is that, in the second
case, the logical transactions have to be provided with an interface usable by business users, and have to
be subjected to the same development disciplines as any other business functionality intended for staff
without special IS knowledge, skills and tools.

Sin embargo, si el usuario empresarial requiere que funciones específicas permitan al usuario final
realizar comprobaciónes de integridad, determinen que el porcentaje libera el espacio disponible e
iniciar la base de datos reconstruyen el tratamiento, entonces tal funcionalidad sería contada como
transacciones lógicas. La diferencia aquí es que, en el segundo caso, tienen que proporcionar las
transacciones lógicas por un interfaz utilizable por usuarios empresariales, y tienen que ser sujetados a
las mismas disciplinas de desarrollo que cualquier otra funcionalidad de negocio intencionada para el
personal sin especial ES el conocimiento, habilidades e instrumentos.

If the application provides a ‘deletion routine’ or tool for error correction, then this is a legitimate
function that can be measured. Generic tools automatically provided by the operational environment
should not be counted

Si el aplicación proporciona ' un rutina de tachadura ' o el instrumento para la corrección de error,
entonces esto es una función legítima que puede ser medida. Instrumentos genéricos automáticamente
proporcionados por el ambiente operacional no deberían ser contados

4.4.6.2 Operational Logs

If a log is a necessary part of maintaining the integrity of the application e.g. it provides information
necessary to enable database back-up and recovery routines to execute successfully, then it is normally
regarded as implicit in the choice of a software solution to the business problem and is not counted.

Si un log es una parte necesaria de mantener la integridad del aplicación por ejemplo esto proporciona
la información necesaria de permitir al respaldo de base de datos y rutinas de recuperación ejecutar
satisfactoriamente, entonces esto normalmente es considerado como implícito en la opción de una
solución de software con el problema de negocio y no es contado.

However, if the log is required by the business user as an additional, user controlled function e.g. to
provide management with a means of determining the volume of transactions processed per period, then it
is regarded as user-specified functionality and any related logical transactions would be recognised.

Sin embargo, si el log es requerido por el usuario empresarial como un adicional, el usuario controló la
función por ejemplo para proporcionar la dirección por el medio de determinar el volumen de
transacciones procesadas por el período, entonces esto es considerado como la funcionalidad
especificada de usuario y cualesquiera transacciones relacionadas lógicas serían reconocidas.

Example 1. A transaction is required to process many records and produce the sum total of certain
numeric values. If the business requirement is only to calculate the total, any logs that are produced as a
by-product are not ‘...of interest to the user...’ and are not counted.

Ejemplo 1. Requieren que una transacción trate muchos registros y produzcan el total de suma de ciertos
valores numéricos. Si la exigencia de negocio es sólo para calcular el total, algunos logs que son
producidos como un subproducto no es '... De interés al usuario... ' Y no son contados.

Example 2. If, in the above transaction, the user specifies that an audit log is required to show that all
records have been processed, then the output is ‘...of interest to the user...’ and is counted.

Ejemplo 2. Si, en la susodicha transacción, el usuario especifica que requieren que un log de auditoría
muestre que todos los registros han sido procesados, entonces la salida es '... De interés al usuario... ' Y
es contado.

4.4.6.3 Security Access

If the Logical Transactions involved in gaining user access are provided by the operating environment,
they should not be counted. Additional requirements for security allocated to the software being sized (i.e.
giving rise to Logical Transactions specific to and provided by the software) should be counted.

Si el ambiente de operaciones provee las Transacciones Lógicas complicadas en la ganancia

de(adelantamiento) del acceso de usuario, ellos no deberían ser contados. Exigencias adicionales para la
seguridad asignada al software ser(siendo,estando) puesto la talla (esto es dando lugar a Transacciones
Lógicas específicas a y proporcionado por el software) deberían ser contadas.

4.4.7 Batch Programs

MkII FPA is concerned with the measurement of the Functional Size of software.
The Functional Size excludes, by definition, consideration of the qualitative (i.e.
performance) characteristics of the software. Hence, MkII FPA makes no distinctions
regarding speed of response, volume of transaction throughput, etc. It is concerned
only with the logical functions.
Batch programs are a physical implementation of a logical function, and batch mode
is chosen usually due to issues such as the need to process large volumes of input
with little user intervention. So far as a logical model is concerned, whether a
function is implemented in batch or on-line mode is of no concern to MkII FPA.
Hence, the same process is used to identify logical transactions and to calculate the
size for functionality implemented in batch or on-line.
Although batch program flows often contain many steps, implemented as distinct
programs connected by intermediate files, usually only a few of these programs
process any input or output across the logical application boundary. Typically, these
include the first and last programs in the flow, and any programs that generate
printed reports. Figure 4.11 illustrates a batch flow containing several program
steps.

4.4.8 Camouflaged Transactions

4.4.8.1 Retrieve Before Create, Update or Delete

A menudo en la práctica, una transacción de actualización (Update) puede estar precedida por una
transacción recuperación (Retrieve). Esta transacción de recuperación se hace para facilitar al usuario a
decidir si continuar con la actualización o no, después de verificar visualmente de que ha sido
seleccionado el registro adecuado para actualización, Esta transacción“Retrieve – before – Update” puede
ser idéntica a una transacción normal de Lectura (Read) (en cuyo caso solamente se cuenta una vez para
el software), o puede ser requerido que sea diferente de una lectruea (Read) normal, en cuyo caso se
debería contar como una transacción diferente de la transacción normal de lectura.

Ejemplo de las diferencias serían si el “Retrieve – before – Read “ no mostrara tos la información
disponible mediante una lectura (Read) normal, o si la utilización de una transacción de Lectura (Read)
normal estuviese restringida de alguna manera, como por ejemplo, si los datos se presentasen de una
forma no actualizable, o si tuviesen otros procesamientos distintivos.

Se aplicarán las mismas consideraciones a una función Añadir (Add) y a Borrar (Delete) que pueda estar
precedida por la necesidad de un recuperación confirmatoria. Sin embargo , en donde el proceso
“Retrieve –Before“ sea idéntico, este contará solamente una vez como una transacción tipo “Retrieve –
Before”.

4.4.8.2 Encadenamiento y Anidado de Transacciones

Por conveniencia de algunos usuarios, las transacciones lógicas pueden estar encadenadas, de forma que a
la terminación de una de ellas, automáticamente navegará la aplicación a la otra transacción lógica.

Such chaining together of several transactions typically is arranged in response to

usability requirements, e.g. to facilitate rapid navigation for telephone sales staff.
Often, information entered as input to one transaction is stored locally and reused as
input in subsequent transactions, without requiring the user to re-enter it. One
transaction may be said to inherit data input to an earlier transaction.

En el MkII FPA, se distinguen las transacciones lógicas la nivel inferior de negocio que deje el contenido
de datos de la aplicación auto-consistente. De esta forma , aunque las transacciones puedan estar
encadenadas desde el punto de vista navegacional, si existen pasos sucesivos que abandonan la aplicación
de forma auto-consistente, entonces cada paso se considera una transacción lógica diferente
La navegación no se cuenta en el MkII FPA, por lo tanto, independientemente de cualquier
encadenamiento todos los DET’s necesarios como entrada para una transacción se cuentan,
independientemente de los esfuerzos para maximizar la usabilidad o de si los dispositivos tales como los
que heredan datos de las transacciones anteriores son utilizados.

Similarly, in some applications, requirements may be resolved such that, during the
course of one transaction it is necessary for the user to initiate (and possibly
complete) a distinct separate transaction. For example, part way through a
Create_Order transaction, it may prove necessary to perform a Query_Stock enquiry.
The Query_Stock enquiry transactions is logically distinct; it may be reached by
navigation from several parts of the system. Hence it is counted as a separate
logical transaction with unique processing, distinct from the Create_Order
transaction.

4.4.8.3 Sinónimos

Large software projects can involve large numbers of people, both from the user and
the supplier side of the project. During software requirements capture, the disparate
requirements of a wide variety of users with a variety of purposes are considered.
Also, several different people may provide their personal views of the requirements
of a single user group. Under these circumstances, it is likely that different people will use distinct
terminology. The result can be that the catalogue of logical
transactions may contain several transactions with different names but requiring
exactly similar processing. That is, one transaction exists with several synonyms.

It is the analysts’ responsibility to identify such situations and resolve them, clarifying
whether there are really multiple transactions or a single logical transaction with
multiple names. Note however, that MkII FPA measures functional requirements,
and similar requirements may be imposed by distinct user groups for their own
purposes. If distinct user groups require similar functionality, this functionality is, by
definition, delivered to distinct customers. Hence, it is admissible to keep the
requirements of each user group distinct and to size the relevant logical transactions
due to each user group, if they are really different.

Example 1:

The user wants a report of sales performance, with a separate report of the sub-totals
for:
· Area
· Department
· Salesman.
All the information is reported at a single point in time and the various elements of
the reports are synchronised, aggregated, and delivered to a single user group on
one report. The reports fulfil a single user need, the provision of Sales Performance
information. Therefore a single logical transaction is recognised, the output size of
which consists of the entire set of DET’s on the report, including the sub-totals.

Example 2:

Alternatively, if there were three different customers (e.g. Area Manager,

Department Manager, Sales Manager) each with a distinct requirement for a report
on Sales Performance, then there would be 3 separate logical transactions, even
though the requirements of all three had been satisfied by the developers by
providing copies of the same shared physical report. In this case the size of each
report should in theory include only the DET’s requested by each respective
customer.

4.4.8.4 Distinción de requisitos lógicos combinados en una única implementación física.

A frequent failing in understanding user requirements derives from inadequate

functional decomposition of the problem. In MkII FPA, the measure of Functional
Size is very sensitive to the recognition of all the required logical transactions.

Therefore, when sizing requirements during development, care should be taken to

ensure that functional requirements are first decomposed to the lowest level of
business process required by the user.

Example 1:

A user group requires that customer data be updated either on-line, or stored and
updated automatically at the end of the working day. As a first attempt, the
requirement is described by the transaction

· Update Customer Record.

If the user is really unconcerned regarding the precise implementation and it makes
no difference to the business when customer details are updated, then this may be
sufficient.

However, if the user wishes to be provided with a choice to be made at run time,
enabling the user to specify whether a specific customer’s details should be updated
immediately or the update delayed until later, then a single transaction would be
insufficient. It is not the ‘lowest level business process...’. A further decomposition of
the requirement results in the recognition of the following:

· Update Customer Details on-line

· Update Customer Records off-line

On even closer analysis, it will be realised that in order to perform an off-line update,
new customer details must be captured and temporarily stored and a subsequent
update triggered by some stimulus – in this case, the tick of the clock or some other
signal indicating the end of the working day. Therefore, in the final analysis, there
could be a total of three logical transactions as follows:

· Update Customer Details on-line

· Capture and Store Customer Details
· Apply Customer Updates at end of day

There are obvious performance differences between these later requirements and
the earlier single update transaction. Not least, the degree to which the customer
details accurately reflect the events that have occurred in the external world is
different between the two cases. In the second case, the deferred update can result
in customer details lagging the external world by one whole day. This may or may
not be a desirable feature – only the user can comment adequately.

4.4.8.5 Reused Components

How to identify the transactions represented by modules that are used in many
applications or many places in a single application may cause uncertainty.

A logical transaction may be implemented so that it makes use of a common module,

for instance retrieving address details for a client. This re-use does not affect the
size of the logical transaction. How the logical transaction is physically implemented
is not at issue: MkII FPA is concerned with the logical view, so the reused module is
‘invisible’ to this view. The input DET’s, references to entity types and output DET’s
are counted in the usual way.

Alternatively, an entire logical transaction may be implemented so that it is available

from multiple places within the application. In this case also, the transaction is counted only once,
regardless of the number of different ways in which it is possible to navigate to it.
If software which implements one or more logical transactions is utilised in more than
one application, then its functionality should be counted in as many applications as it
appears in (once per required transaction per application) as it is to be assumed that
it implements distinct user requirements in each such application. The fact that
implemented software is reused in this way does not affect the Functional Size,
which is a measure of the requirements. Reuse will, of course, affect the effort, time
and cost of software development, which will typically be lower than if reuse where
not an option. The benefit therefore, will show up as improved capability on the part
of the developer. This is entirely reasonable – a business problem of measured size
is being solved more efficiently.

4.5 Identificación de Entidades

4.5.1 Reglas básicas para Contar Referencias a Tipos de Entidades

En el MkII FPA, como medida del tamaño de la fase de proceso de cada transacción lógica, contamos los
tipos de entidad primarios referenciados en el proceso.

Contar el número de tipos de entidad a los que hacemos referencia. No contar el número de veces que son
referenciados dentro de cada transacción; por ejemplo si la entidad ”cliente” se lee y actualiza dentro de la
transacción, contar solamente una referencia a entidad. De forma similar, contar solamente un tipo de
entidad, independientemente del número de ocurrencias del tipo entidad. (A partir de ahora usaremos
“entidad” y “entidades” por simplicidad, cuando no haya riesgo de malentendimiento)

Se deben contra las entidades primarias, NO las entidades no primarias; las últimas se agrupan juntas en
la “Entidad de sistema). Esta última se debe contra también como una única referencia, si cualquiera de
loa componentes de esta entidad no primaria son referenciados en una transacción Lógica (vease la
sección 4.5.3 más abajo), incluso si la Entidad de Sistema no se considera una entidad primaria.

Se recomienda siempre realizar siempre un análisis entidad / relación, o un análisis de datos relacionales
para hacer un diagrama de entidades para la aplicación, antes de comenzar la cuenta de puntos de función
MKII. No contra los archivos físicos, tanto si son permanentes como transitorios, ya que estos podrían ser
altamente engañosos.

4.5.2 Tipos Entidad

Un tipo entidad es algo (estrictamente, algún tipo de cosa) en el mundo real sobre la cuela el usuario de
negocio quiere mantener información. Los tipos de elementos de datos mantienen información sobre tipos
de entidad..

Por ejemplo:

 “Empleado” sería un tipo entidad en un sistema de personal (José Pérez podría ser una
ocurrencia de la entidad).
 “Fecha de nacimiento del empleado” es un Tipo de Elemento de Datps – Data Element Type
(“DET”) que contiene información sobre el empleado (“Fecha de nacimiento del empleado” es
altamente improbable que sea un tipo de entidad. No queremos saber nada sobre esto).

Si se ha hecho un análisis de datos relacionales dando lugar a un conjunto de tablas, entonces el asunto de
cada tabla sería un tipo entidad (pero no necesariamente un tipo de entidad primario)

4.5.3 Distinción entre Tipos de entidad Primario y No-Primario: la “Entidad de Sistema”

Las Entidades primarias son las cosas principales en el mundo real que la aplicación que estamos
dimensionando necesita para contener datos.
Hay varios criterios para distinguir tipos de entidades primarias y no primarias.

Criterio Entidad Primaria Entidad No-Primaria

Número de Atributos Varios, con valores cambiantes Muy pocos, por ejemplo solo
frecuentemente (ejemplo: código, nombre, descripción;
cantidades) valores que raramente cambian

Frecuencia de Ocurrencia El número de ocurrencias cambia Fijos permanentemente, o que

Propietario
Tiempo entre cambios de los
valores del atributo
Autorización para cambiar los
valores de atributo.
Ciclos de vida de la entidad
a menudo, por ejemplo número cambian ráramente.
de pedidos o pagos en un sistema
cambia con el tiempo.
Probablemente pertenece a la Bien pueden pertenecer a la
aplicación a ser contada. organización, y ser utilizados por
varias aplicaciones.
Durante la operación normal del Normalmente fuera del
sistema. funcionamiento normal del
sistema.
No requiere autorización especial; Realizado por el administrador
realizada por el usuario normal del sistema.
del sistema.
Normalmente muchas etapas o Normalmente solo “vivo” o no
estados. existente; probablemente se
mantienen los atributos del último
periodo y actuales.

Nótese que no hay nada absoluto en la distinción entre tipos de entidad primarios y no-primarios. Puede
haber incluso casos que estén en la línea de frontera de ambos casos, como por ejemplo la entidad
“Grado” en un sistema de Personal, que tenga los atributos tales como Grade_Code, Grade_Name,
Lower_Salary_Limit, Upper_Salary_Limit, Date_of_Validity, etc. Esta tiene pocos atributos, no cambian
frecuentemente, y requieren autorización especial para su cambio, pero al ser fundamentales para el
negocio de personal podrían muy bien necesitar ser considerados como una entidad Primaria.

Dentro de una aplicación, las entidades primarias y no primarias se clasifican como tales para la totalidad
de la aplicación, y esta clasificación no cambia entre las transacciones.

Sin embargo, un tipo de entidad que es no-primario para una aplicación podría ser primario para otra. Por
ejemplo, una aplicación que mantenga cuentas bancarias “tipo-cliente” , podría tener un atributo del tipo
de entidad “cliente”. Un análisis de la Tercera Forma Normal de la totalidad del área de negocio mostraría
a “tipo-cliente” como una entidad, pero como la aplicación “mantenimiento de cuentas bancarias” no
quiere saber nada sobre “tipo-cliente”, sería un tipo entidad no-primario en esta aplicación. Sin embargo,
otra aplicación de análisis de mercado podría querer acumular un montón de información cada mes sobre
cada cliente tipo, y por lo tanto para esta última aplicación , “tipo-cliente” sería una entidad primaria.

Los valores permitidos de atributos de las entidades no-primarias se mantienen normalmente en “Tablas
Maestras”, a las cuales se hace referencia normalmente con el propósito de validación por muchos tipos
de transacciones.

Como un convenio simplificador de la cuenta de Puntos de Función MKII, todas las entidades no-
primarias se “agrupan juntas” en lo que se conoce como “Entidad de Sistema”. La Entidad de Sistema se
cuenta solo una vez en cada Transacción Lógica que referencia cualquiera de los componentes de esta
entidad no-primaria. La Entidad de Sistema no se debe mirar como una Entidad Primaria para los
propósitos de otras reglas en este manual de prácticas de contar (por ejemplo véase el capítulo 5. “ ‘Drop-
down/pop-up List Box’).

4.5.4 Entity Sub-Types

Algunas veces es necesario distinguir entre entidades y “sub-entidades”, y contarlas separadamente.

Una sub-entidad es un tipo específico o variación de una entidad primaria, para la cual existen reglas de
proceso distintas.

Por ejemplo

TIP ENTIDAD DUB TIPO ENTIDAD

Cuenta Cuenta Ahorro, Cuenta Depósito
Empleado Fijo, Temporal

La relación característica entre Tipo / sub-tipo es, por ejemplo, que “todas las cuentas de ahorro son
cuentas, pero no todas las cuentas son cuentas-ahorro”.

Las Sub-entidades se cuentan separadamente cuando se utiliza diferente lógica de proceso en la

transacción en las que las entidades están involucradas, por ejemplo:

 Transferencia de fondos de una “Cuenta Ahorro” a una “Cuenta Depósito”.

Cada una es una sub-entidad de “Cuenta”, pero la lógica de proceso es diferente para cada sub-
entidad en esta transacción. Contar 2.

 Crear una nueva ocurrencia de “Empleado Fijo”

Contar 1 para la referencia a “Empleado Fijo”

 Contar todos los empleados, haciendo referencia tanto a los Fijos como a los Temporales

No existe distinción entre Fijo y Temporal, por lo tanto contar 1 por la referencia a “Empleado”

 Listar los nombres de todos los Empleados Temporales y sus salarios individuales (Las sub-
entidades Temporales tienen atributos adicionales para salarios, periodo de prueba y progreso)

Lógicamente, aquí solo tratamos con un tipo de entidad, por lo tanto cuenta 1 por la referencia a
la sub-entidad Empleado Temporal

 Suma el coste total de todos los empleados

Cuenta 1 por la referencia a las sub-entidades Fijos y 1 por la referencia a las sub-entides
Temporales (Hay diferentes procesos para los salarios). Cuenta total 2.

4.5.5 Entidades Involutivas

(También se conocen como “recursivas” o “auto-referenciales”).

Existe una excepción adicional a las reglas para contar anteriores. Si una entidad se relaciona consigo
misma, como por ejemplo en una lista de partes o en una jerarquía de clientes, entonces para la
transacción que atraviesa de arriba abajo la jerarquía, contar dos referencias a entidad, una para la
referencia inicial y otra para el bucle repetitivo, independientemente de cuantas veces la jerarquía es
atravesada.

4.5.6 Entidades Lógicas en Sistemas por lotes (Batch)

El MkII FPA se preocupa en contra las referencias a los tipos de entidad lógica, no de los ficheros físicos.
El distinguir estos en una aplicación por lotes requiere atención. En el ejemplo de la figura 4.11 de un
Sistema por lotes, la corriente de transacción puede contener varios tipos de transacción lógica (ejemplo
Crear, Actualizar, Borrar), y la cuenta del proceso debe contener referencias a, por ejemplo 2 entidades,
tales como Order_Header y Order_Item. El ejemplo muestra varios ficheros físicos en la secuencia del
proceso, pero en este caso solo hay dos referencias involucradas en cada una de las transacciones lógicas.
Cuando se analiza el sistema utilizando el MkII FPA, examina los ficheros físicos para ayudarte a
identificar los tipos entidad, pero solo cuenta las referencias a tipos entidad para cada transacción no los
ficheros físicos involucrados.

4.6 Counting Input and Output Data Element Types

La regla general para identificar y contra los Tipos de Elementos de Datos - Data Element Types
(DET’s) son los siguientes:

Tipos versus Ocurrencias

Contar solamente los tipos de elementos de datos procesados, no las ocurrencias individuales.

Elementos de datos Simples, Compuestos, Multi-uso, etc.

Contar los DETs compuestos, como por ejemplo nombre y dirección, como un único DET, a menos que
exista un requisito de manejar (ejemplo validar) las partes separadas (por ejemplo el código postal) , en
cuyo caso se deberá contar los DET’s individuales procesados separadamente.

Contar las fechas mostradas como día / mes /año como un solo DET, a menos que exista una necesidad
específica de proceso que necesite distinguir las partes separadas de la fecha.

Contar las entradas heredadas el número de veces que son utilizadas. Entrada heredada es cuando un DET
se introduce una vez, se almacena localmente, y proporciona entradas a dos o más transacciones.

Si la aplicación requiere proporcionar valores por defecto para los DET’s de entrada y los presenta al
usuario para aceptación o modificación, contarlos una vez como datos de entrada normales.

Cuando se requiere que un DET de entrada se vuelva a mostrar como salida o fallo después de validación,
contarlo tanto como entrada y salida.

Mira a todos los mensajes de error requeridos como una ocurrencia del tipo de elemento “mensaje de
error”, es decir cuéntalo como 1. Nota: los mensajes de error del sistema operativo o de la red que no se
crean o mantienen por el equipo de proyecto no se convierten en puntos de función si son parte del
entorno técnico utilizado. Pero sie estos mensajes de error contienen datos de negocio embebidos que
cambian con la ocurrencia del mensaje de error, hay que contar los DET’s involucrados separadamente.

Arrays

Cuando los datos se representan como un array o tabla, contar = (número de tipos de columna) x (número
de tipos de filas).

Por ejemplo, si el usuario quiere visualizar los pagos de 12 meses sucesivos, esto se podría representar
por una tabla con dos columnas y 12 filas:

Mes Valor
Pago Abril 12
Mayo 57
Junio 56
Julio 78
Agosto 23
Septiembre 121
Octubre 68
Noviembre 83
Diciembre 55
Enero 60
Febrero 23
Marzo 92

La cuenta sería:
 (2 tipos de columnas [mes y valor]) x ( 1tipo de fila [pago]) = 2.
Esto daría la cuenta para este tipo de información, independientemente del número de ocurrencias que
añadamos.

Si en este ejemplo añadiéramos también el valor total de la columna valor:

Mes Valor
Pago Abril 12
Mayo 57
Junio 56
Julio 78
Agosto 23
Septiembre 121
Octubre 68
Noviembre 83
Diciembre 55
Enero 60
Febrero 23
Marzo 92
Total pagos 728

La cuenta se aumentaría por el tamaño del Nuevo tipo de datos como sigue:

(1 tipo de columna [valor]) x (1 tipo de filas [total pagos]) = 1,

dando un total de cuenta para la totalidad de la tabla de 3.

Menus, e Inicio de Transacción

No contar los menús o las teclas de función cuando estas se utilizan solamente para el propósito de
navegación. Los Puntos de Función de MKII miden las funciones proporcionadas de proceso de
información del usuario. La estructura del menú simplemente permite al usuario moverse entre las
funciones proporcionadas, no contribuye a ninguna función de procesado de información por si misma.

Sin embargo, a veces un menú se utiliza no solamente para seleccionar e invocar a una transacción, sino
también para introducir datos, como por ejemplo parámetros que se pasan a la aplicación a través del
menú. Contar cada uno de estos parámetros pasados como si fuesen sido entrados directamente a la
transacción. Los Datos que pueden ser utilizados para iniciar una transacción pueden incluir parámetros
de selección, comparación o margen permisible y estos también se cuentan como DETs de entrada.

Cuando una transacción se inicia “automáticamente” hay que encontrar el “arrancador” real. Por ejemplo
una fecha puede ser un “disparador” válido. Un cambio de fecha, por ejemplo el final del mes, es un
evento externo válido y se trata como si fuese una entrada a la aplicación, arrancando una transacción. Se
cuenta como un DET de entrada. Similarmente, las transacciones que se corren periódicamente también
se inician por eventos temporales (cambio de fecha o de hora).

El Identificador de Tipo de Transacción

Cuando la parte de entrada de una transacción lógica incluye un “identificador de tipo de transacción” que
es necesario para que el sistema conozca que hacer con la entrada, este debe ser contado como un DET.
Considere lo siguiente: un a aplicación tiene dos tipos de transacción, cada una con un mensaje de entrada
consistente de los campos ID_Cliente, ID_Cuenta y Cantidad. A menos que se reconozca la necesidad por
un campo “tipo de transacción” la aplicación no tiene ninguna forma para determinar que estas dos
transacciones son, respectivamente, Cuenta_Crédito y Cambio_Limite_Préstamo.

Headings, Headers, Footers, etc de Campo

No se debe contar ninguna etiqueta de campo, títulos, o subrayados que no contienen información
variable.
No contar encabezamientos (headers) o pies que aparecen automáticamente en cualquier informe o
pantalla, como por ejemplo los mensajes de copyright.

Limitaciones Físicas de la Pantalla

Ignorar las limitaciones físicas de la pantalla, por ejemplo muchas aplicaciones tienen salidas que
consisten en listas de datos que se extienden sobre varias pantallas, requiriendo paginación, y pasar de
página (scrolling) para acceder a la totalidad. La cuenta es sobre los únicos DETs presentados,
independientemente del número de pantallas físicas.

Granularidad y DETs con Proceso Único en el flujo de Entrada / Salida.

Si los datos de entrada / salida es en forma de un string de datos cuya estructura consta de más de un
DET, entonces el número de DETs de entrada o salida a contar se identifica aplicando la lógica siguiente:

1. Si la transacción lógica procesa los datos como una DET individual, infependiente de la
estructura, existe solo un DET: Contar 1 entrada o 1 salida.

Ejemplo: Archivar registros de datos. La estructura del registro contendrá muchos DETs, pero el registro
en su totalidad será almacenado sin validación o cambios en el formateo.

2. Si la transacción lógica procesa DET’s individuales (validación y formateo) o grupos de DET’s

dentro de la estructura entonces se cuenta un DET por cada Det o grupo de DET’s procesados
distintamente.

Ejemplo (a) Actualización de un registro existente sin validación. Esto implicará típicamente la
extracción de los DET’s que representa la clave única. La clave única se contará como un DET y los
restantes DET’s se contarán también como 1 DET.

Ejemplo (b) Actualización de un registro existente con validación antes de actualización. Cada DET
único, o grupo de DET’s requeridos para ser validados serán contados

Entradas / Salidas en Formas Diferentes

Cuando la misma información se requiere para ser presentada en “formas” diferentes en las partes de
entrada o salida de las transacciones lógicas, hay que prestar mucha atención en la interpretación de las
reglas para contar del MKII FPA.

Por diferentes formas de presentación de la misma información, queremos decir, por ejemplo:

 Salida tanto en forma de tabla numérica o en forma gráfica (ejemplo gráfico de barras, gráfico de
tarta, etc.)
 Entrada y salida en diferentes lenguajes naturales
 Entrada y/o salida tanto en blanco y negro, como en presentación de color.

Como la información es la misma en todos los casos, la interpretación podría ser que los Puntos de
Función MKII solo contaran una “forma” e ignoraran los requisitos de presentación de las otras formas.
Sin embargo el objetivo establecido por el método MKII FPA es el de producir un tamaño que es
“adecuado para el propósito de medidas de rendimiento y estimación en relación con cualquier actividad
asociada con el producto software”.

El requerir producir información en diferentes formas requiere un trabajo extra, de forma que ignorar el
“tamaño extra” asociado con producir las “formas extras” (por ejemplo presentaciones en diferentes
idiomas, etc.) produciría una medida de tamaño injustamente baja. Los siguientes ejemplos son relativos a
varias “formas” diferentes de presentar información, diseñados para ilustrar como se deben aplicar las
reglas de contar Puntos de Función MKII.

Ejemplo 1: Se requiere imprimir de dos formas diferentes un array de datos, como tabla numérica y como
gráfico de pastel. Se pueden distinguir tres casos dependiendo de cuales son los requisitos aceptados.

(a) Un Transacción Lógica, con presentación simultánea de los datos en dos formas: Contar dos
DET’s de salida, una para cada forma.
(b) Los requisitos son de dos Transacciones Lógicas separadas para cada forma. Contar
separadamente las transacciones lógicas siguiendo las reglas normales de contar.
(c) El requisito es dar al usuario la elección de que forma de salida desea, dependiendo de su
selección del valor de un DET de entrada. Contar el DET de entrada y dos DET’s de salida.

Ejemplo 2 : Se requiere que una transacción lógica imprima un código de producto en una etiqueta tanto
de forma numérica como en forma de código de barras. Trár como el ejemplo 1ª)

Ejemplo 3: Todas las salidas en blanco y negro se deben convertir en colores por razones estéticas. No
contar ningún DET añadido o cambiado en el proyecto de Cambio. Este tipo de trabajo no se puede
dimensionar fiablemente con el Análisis de Puntos de Función (FPA)

Ejemplo 4: Todas las salidas existentes en blanco y negro se convierten a color lo cual añade información
significativa, por ejemplo rojo indica que los precios han caído, verde que están aumentando. Contar
todos los DET’s cambiados en el tamaño del Cambio.

Ejemplo 5: Se introduce color para resaltar los campos que tienen error. No contar más que uno – se
aplicará la regla normal para los mensajes de error.

Ejemplo 6: Hay que dar todas las etiquetas de campo en un lenguaje para que estén disponibles para otro
lenguaje, vía opción de firma. Se debe contar el DET de entrada de la firma, pero las etiquetas son
literales y normalmente no se cuentan con las reglas de Puntos de Función MKII. Este tipo de trabajo no
se puede medir fiablemente con el Análisis de Puntos de Función (FPA).

Ejemplo 7: Se requiere almacenar las etiquetas de campo como variables, con diferentes valores para
diferentes lenguajes. Contar las etiquetas de campo como DET’s.

Ejemplo 8: Se requiere presentar valores de DETs en más de un idioma. Estos valores de DET han sido
almacenados como atributos de la misma entidad, de forma que cada variación de idioma del DET se
cuenta, en la entrada o salida, según sea apropiado. Nótese que solo se cuenta una entidad referencia para
el sacado (retrieval) de estos DET’s independientemente del número de lenguajes

Ejemplo 9: Se requiere que la transacción lógica imprima un listado de deudores con las cantidades
debidas, tanto en orden alfabético, o como una opción del usuario, ordenado por la cantidad de deuda.
Contar solo un conjunto de DET’s para la salida, ya que la otra secuencia proporciona la misma
información. Contar un DET de entrada para el control de la clase de secuencia.

Ejemplo 10: Un programa de informes de un club de miembros permite listar los miembros a imprimir,
clasificados de diferentes formas y con selección de subconjuntos de información que van desde un
listado completo a nombres y direcciones seleccionados. El tamaño depende de los requisitos acordados
con el usuario:

i). El requisito del usuario establece que cada informe sea programado previamente. Contar
una transacción lógica por cada informe.
ii). El requisito del usuario establece que sea una herramienta que permita al usuario generar sus
propios informes ad-hoc. Contar todos los DET’s de entrada que se puedan usar para determinar
la salida, todas las referencias a entidades que puedan necesitarse y todos los DET’s de salid que
se puedan producir. El punto de vista aquí es el de los requisitos para la herramienta, no la
aplicación de la herramienta.
Ejemplo 11: Un informe ha sido formateado para una impresora de 132 caracteres, y tiene que ser
reformateado para una pantalla de 80 caracteres. Contar todos los DET’s afectados por el Cambio.

Ejemplo 12: Un informe normalmente se imprime en una impresora laser, pero el Cambio requiere que se
envíe a otra impresora laser para la cual se necesita un nuevo driver. No contar ningún DET adicional a
nivel de la aplicación, ya que no ha cambiado nada a ese nivel. (si el software del driver tiene que ser
dimensionado, desarrollar un modelo lógico para las transacciones del dispositivo driver).
Entidad externa
Proceso
Almacén de datos
Flujo de datos

Diagrama de contexto (primer nivel)

Entidad
Interrelación
Grado
Unitarias o reflexivas
Binarias
n-arias
Cardinalidad máxima (o tipo)
1:1
1:n
n:m
atributos (columnas)  número de atributos: grado
tuplas (filas) ocurrencias de la tabla o relación => número de tuplas: cardinalidad

Dominio del atributo

Clave primaria
Primera forma normal: si no tiene grupos repetitivos