ANÁLISIS DE UNA RED DE ACTIVIDADES CON · PDF fileenfatizando la ruta crítica del proyecto. ... 2.5 EL MÉTODO CPM ... 2.6.1 TIEMPOS DE ESTIMACIÓN DE ACTIVIDAD

(i)

PROYECTO FIN DE CARRERA

ANÁLISIS DE UNA RED DE ACTIVIDADES CON DURACIONES

CONOCIDAS Y BORROSAS

AUTOR: FRANCISCO JAVIER COCO UTRILLA

MADRID, SEPTIEMBRE 2007

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERO INFORMÁTICO

Autorizada la entrega del proyecto del alumno:

Francisco Javier Coco Utrilla

EL DIRECTOR DEL PROYECTO

Manuel Rojas Guerrero

Fdo.: .............................. Fecha: ....../ ....../ ......

Vº Bº del Coordinador de Proyectos

Miguel Ángel Sanz Bobi

Fdo.: .............................. Fecha: ....../ ....../ ......

ANÁLISIS DE UNA RED DE ACTIVIDADES CON DURACIONES CONOCIDAS Y BORROSAS

- I -

RESUMEN

El concepto de lo que es un proyecto, es universal pero bastante

inconcreto. Existen diversas definiciones, según el punto de vista de cada

descriptor, pero en lo que todos parecen coincidir es que es un medio para

llevar a cabo una proyección hacia el futuro con respecto a una situación actual

que se desea cambiar.

En el complejo mundo de las Organizaciones y Empresas, diseñar y

desarrollar un proyecto que consiga aunar los diferentes intereses existentes y

latentes, es una ardua tarea en la que muchas veces tienen que consensuar

promotores y detractores.

Además, a la hora de acometer un proyecto a veces se suelen encontrar

situaciones complicadas para su dirección, planificación, obtención de recursos,

recopilación de datos e incluso su justificación económica, que pueden dificultar

el éxito del mismo.

Por ello, a lo largo del tiempo se han ido confeccionando distintos

métodos de trabajo que persiguen soslayar estos inconvenientes y que

presentados de manera formal y pública reciben el nombre de Metodologías.

Unas están especializadas para confeccionar proyectos en el mundo de

cada organización y otras son de propósito general.

En este Proyecto Final de Carrera se ha desarrollado un sistema de

propósito general que extiende el algoritmo clásico del PERT-CPM basado en

programación dinámica (que permite estudiar una red de actividades) al caso en


- II -

el que se tiene un conocimiento vago de las duraciones de las diferentes

actividades de la red. Este conocimiento puede ser modelado mediante

números borrosos trapezoidales (y, como casos particulares, intervalos

constantes y números borrosos piramidales).

El sistema se ha diseñado con una arquitectura cliente-servidor que

permite al usuario la creación de un proyecto que parte de una fecha que el

usuario asigna y que está compuesto por un conjunto de actividades que él

mismo diseña a través de un interfaz sencillo e intuitivo.

Por su potencia de desarrollo en soluciones de cualquier tipo,

integración de funciones, facilidad de uso y documentación existente, el

proyecto ha sido desarrollado en su totalidad en el lenguaje de programación

Java (jdk 1.6) con el entorno de desarrollo Eclipse-SDK-3.1.1.

El sistema permite al usuario guardar y cargar los proyectos existentes,

insertar nuevas actividades que puedan surgir, modificarlas y eliminarlas del

proyecto con total facilidad y en cualquier momento. Asimismo se proporcionan

diferentes métodos de desborrosificación de resultados para estimar una

valoración del proyecto en un diagrama de Gantt.

La aplicación se divide en dos subsistemas: cliente y servidor que se

comunican mediante un protocolo a nivel de aplicación diseñando para trabajar

tanto desde el mismo equipo como en una red local o a través de Internet.

La aplicación cliente es la encargada de recoger la información que

aporta el usuario controlando la entrada de datos en el sistema para mantener la


- III -

información en un estado conforme e íntegro de tal manera que se cumplan las

directrices de los diagramas de red y de las duraciones borrosas. Por otra parte

se presentan las tablas de actividades y etapas generadas por el servidor

enfatizando la ruta crítica del proyecto. Como apoyo se muestran gráficas

descriptivas para la ayuda al diseño y a la comprensión de los resultados.

El servidor se encargará de resolver las redes de actividades enviadas

por el cliente con las opciones de solución elegidas para cada una de las fases

del camino crítico.

El sistema desarrollado en definitiva es capaz de proporcionar una

importante ayuda a la toma de decisiones en el ámbito empresarial para

proyectos con actividades modeladas mediante números borrosos combinando

el algoritmo clásico del PERT-CPM con seis técnicas diferentes de

desborrosificación implementadas, de las cuales cuatro de ellas incorporan un

parámetro asociado dotando a la aplicación de una robustez y versatilidad

sorprendentes.


- IV -

ABSTRACT

The concept about what is a project is universal but no specific enough.

Diverse definitions exist, according to the point of view of every describer, but all

of them seem to agree about it is that it is a way to carry out a projection towards

the future with regard to a current situation that one wants to change.

Inside the complex world of the Organizations and Companies, to design

and develop a project that manages to unite the different existing and latent

interests, it is an arduous task in which often promoters and detractors have to

agree.

In addition, at the moment of undertaking a project it is usual to find

complex situations for its direction, planning, obtaining of resources, summary of

information and even its economic justification, which can impede the success of

it.

For all this, throughout the time there have been created different

methods of work that they chase to avoid these disadvantages and they receive

the name of Methodologies.

Some are specialized to make projects in the world of every organization

and others are of general purpose.

In this project a general purpose system has been developed that

extends the classic algorithm of the PERT-CPM based on dynamic programming

(that allows studying an activities network) to the case in which a vague

knowledge exist about the duration of the different activities in the network. This


- V -

knowledge can be shaped by means of trapezoidal fuzzy numbers (and, as

particular cases, constant intervals and pyramidal fuzzy numbers).

The system has been designed with a client - server architecture that

allows the user to create a project that initiates from a date that the user assigns

and is composed by a set of activities designed by him across a simple and

intuitive interface.

For its power of development in solutions of any type, integration of

functions, facility of use and existing documentation, the project has been

developed entirely in the Java programming language (jdk 1.6) using the

development environment Eclipse-SDK-3.1.1.

The system allows the user to save and load the existing projects, to

insert new activities that could arise, modify them and eliminate them from the

project with total facility and at any time. Likewise different methods of

defuzzification are provided to estimate a valuation of the project results in

Gantt's graph.

The application is composed by two subsystems: client subsystem and

server subsystem that communicate by an application level protocol designed to

work as much from the same computer as in a local area network or across the

Internet.

The client subsystem is in charge of gathering the information that the

user put in, controlling the entry of information in the system to support the

information in a right and entire state in such a way that the directives of network


- VI -

diagram and the fuzzy durations are carried out. On the other hand it presents

tables about activities and stages generated by the server emphasizing the

critical path of the project. Descriptive graphs are shown to help with the design

and to the comprehension of the results.

The server will take charge solving the networks of activities sent by the

client with the solution options chosen for each of the phases of the critical path.

The system developed in short is capable to provide an important help to

make a decisions in the business area for projects with activities shaped by

fuzzy numbers combining the classic algorithm of the PERT-CPM with six

different defuzzification methods implemented, in which four of them incorporate

an associate parameter providing the application with a solid and a surprising

versatility.


- A -

ÍNDICE

1. INTRODUCCIÓN Y PLANTEAMIENTO...................................... 1

2. EL PERT/CPM ............................................................................ 5

2.1 GLOSARIO ........................................................................................... 5

2.2 VENTAJAS PERT Y CPM .................................................................... 8

2.3 CAMPO DE ACCIÓN............................................................................ 8

2.4 DISEÑO DEL DIAGRAMA DE RED ..................................................... 9

2.5 EL MÉTODO CPM.............................................................................. 13

2.5.1 APLICACIÓN DEL MÉTODO CPM......................................... 13

2.5.2 EJEMPLO DE CPM................................................................. 18

2.5.3 LIMITACIONES DEL CPM ...................................................... 21

2.6 EL MÉTODO PERT ............................................................................ 22

2.6.1 TIEMPOS DE ESTIMACIÓN DE ACTIVIDAD......................... 22

2.6.2 DETERMINAR LA RUTA CRÍTICA ......................................... 24

2.6.3 VENTAJAS DEL PERT ........................................................... 26

2.6.4 LIMITACIONES....................................................................... 27

2.7 CONCLUSIONES ............................................................................... 27

3. LA LÓGICA BORROSA............................................................ 29

3.1 CONJUNTOS CLÁSICOS .................................................................. 29

3.1.1 FUNCIÓN CARTESIANA ........................................................ 31

3.1.2 OPERACIONES BÁSICAS ENTRE CONJUNTOS ................. 32

3.1.3 PROPIEDADES DE LOS CONJUNTOS CLÁSICOS .............. 33

3.2 CONJUNTOS BORROSOS................................................................ 35


- B -

3.2.1 FUNCIÓN DE PERTENENCIA................................................ 36

3.2.2 DEFINICIONES BÁSICAS SOBRE

CONJUNTOS BORROSOS ............................................................. 41

3.2.3 OPERACIONES BÁSICAS ENTRE

CONJUNTOS BORROSOS ............................................................. 43

3.2.4 PRINCIPIO DE EXTENSIÓN .................................................. 44

3.2.5 α-CORTES .............................................................................. 45

3.3 NÚMEROS BORROSOS.................................................................... 46

4. PLANTEAMIENTO Y OBJETIVOS DEL PROYECTO .............. 48

4.1 PLANTEAMIENTO DEL PROYECTO ................................................ 49

4.2 OBJETIVOS DEL PROYECTO .......................................................... 49

5. SOLUCIÓN PROPUESTA ........................................................ 52

6. DIAGRAMA DE CONTEXTO .................................................... 53

7. PERFILES Y ÁMBITO............................................................... 54

8. ANÁLISIS.................................................................................. 55

8.1 ANÁLISIS DE REQUISITOS .............................................................. 55

8.1.1 REQUISITOS FUNCIONALES................................................ 55

8.1.2 REQUISITOS NO FUNCIONALES ......................................... 56

8.2 ANÁLISIS FUNCIONAL DETALLADO .............................................. 58

8.2.1 CREACIÓN DEL PROYECTO, INSERCIÓN,

MODIFICACIÓN Y ELIMINACIÓN DE ACTIVIDADES .................... 58

8.2.2 TRATAMIENTO DE LAS DURACIONES BORROSAS........... 59

8.2.3 CREACIÓN DEL ALGORITMO DE SOLUCIÓN ..................... 59

8.2.4 PROTOCOLO DE CONEXIÓN ............................................... 60


- C -

8.2.5 PRESENTACIÓN DE LOS DATOS......................................... 61

8.2.6 PRESENTACIÓN DE LOS GRÁFICOS .................................. 61

8.2.7 ALMACENAMIENTO DE LOS DATOS ................................... 62

8.2.8 MODIFICACIÓN DE PARÁMETROS DEL PROYECTO Y DEL

PROGRAMA .................................................................................... 62

9. ESTUDIO DE LA ARQUITECTURA.......................................... 63

9.1 EL LENGUAJE JAVA......................................................................... 63

9.2 ESTRUCTURA DEL SISTEMA........................................................... 65

10. DISEÑO DE LA APLICACIÓN................................................ 67

10.1 MODELO DE DOMINIO.................................................................... 68

10.2 MODELO DE DATOS....................................................................... 69

10.2.1 TABLA DE ACTIVIDADES .................................................... 69

10.2.2 TABLA DE ETAPAS.............................................................. 72

10.2.3 TABLA DE ACTIVIDADES FICTICIAS.................................. 74

10.3 MODELO DE CASOS DE USO ........................................................ 75

10.3.1 IDENTIFICACIÓN DE LOS CASOS DE USO ....................... 75

10.3.2 DIAGRAMA DE CASOS DE USO......................................... 76

10.3.3 DESCRIPCIÓN DE LOS CASOS DE USO ........................... 78

10.4 DIAGRAMA DE PAQUETES............................................................ 92

10.4.1 PACKAGE MOTOR............................................................... 92

10.4.2 PACKAGE CLIENTE............................................................. 93

10.4.3 PACKAGE ORG.................................................................... 93

10.4.4 PACKAGE COMMON ........................................................... 94


- D -

10.5 DIAGRAMA DFD DE PRIMER NIVEL DE

LA APLICACIÓN CLIENTE...................................................................... 95

10.6 DIAGRAMA STATECHART DEL SERVIDOR DE RESOLUCIÓN... 96

11. LA APLICACIÓN CLIENTE .................................................... 97

11.1 DISEÑO Y EDICIÓN DEL PROYECTO............................................ 97

11.1.1 CREACIÓN DE UN NUEVO PROYECTO (CU01) ................ 97

11.1.10 SOLUCIÓN DEL PROYECTO........................................... 124

11.1.2 DEFINIR LOS PARÁMETROS DEL PROYECTO (CU02) .... 98

11.1.3 INICIADOR DE ACTIVIDADES (CU03) .............................. 100

11.1.4 CREADOR DE DURACIONES BORROSAS (CU14).......... 103

11.1.5 INICIADOR DE SUCESORAS (CU04)................................ 107

11.1.6 AÑADIR ACTIVIDADES AL PROYECTO (CU05) ............... 111

11.1.7 MODIFICAR LAS ACTIVIDADES

DEL PROYECTO (CU06)............................................................... 112

11.1.8 ELIMINAR ACTIVIDADES DEL PROYECTO (CU07) ......... 116

11.1.9 MODIFICAR FECHA DE INICIO DEL PROYECTO (CU02) 122

11.2 COMUNICACIONES....................................................................... 126

11.2.1 CONEXIÓN CON EL SERVIDOR DE

RESOLUCIÓN (CU09) ................................................................... 126

11.2.2 MODIFICAR LA CONFIGURACIÓN DE CONEXIÓN CON EL

SERVIDOR (CU13) ........................................................................ 129

11.3 GESTIÓN DE ARCHIVOS .............................................................. 130

11.3.1 GUARDADO DE INFORMACIÓN (CU11)........................... 132

11.3.2 CARGA DE INFORMACIÓN (CU12)................................... 135


- E -

11.4 PRESENTACIÓN DE LA INFORMACIÓN (CU10) ......................... 137

11.4.1 INFORMACIÓN BÁSICA..................................................... 137

11.4.2 INFORMACIÓN RESUELTA............................................... 140

12. EL SERVIDOR DE RESOLUCIÓN........................................ 147

12.1 GESTOR DE PETICIONES ............................................................ 147

12.2 MOTOR DE RESOLUCIÓN (CU08)................................................ 149

12.2.1 CREACIÓN DEL DIAGRAMA DE RED............................... 149

12.2.2 FASE HACIA DELANTE DEL MÉTODO CPM.................... 154

12.2.3 FASE HACIA ATRÁS DEL MÉTODO CPM......................... 158

12.2.4 IDENTIFICACIÓN DE LAS ACTIVIDADES CRÍTICAS ....... 165

12.2.5 CALCULAR LOS MÁRGENES DE CADA ACTIVIDAD....... 165

12.2.6 OPCIONES DE DESBORROSIFICACIÓN

PROPORCIONADAS..................................................................... 166

12.2.7 OPCIONES DE RESOLUCIÓN DEL PROYECTO.............. 174

13. EJEMPLO DE ENSAYO ....................................................... 178

14. PLANIFICACIÓN .................................................................. 187

15. ESTUDIO ECONÓMICO ....................................................... 192

15.1 RECURSOS UTILIZADOS ............................................................. 192

15.2 COSTES DEL PROYECTO ............................................................ 193

15.2.1 COSTES DE PERSONAL ................................................... 193

15.2.2 COSTES DE AMORTIZACIÓN DE PROGRAMAS Y

EQUIPOS....................................................................................... 195

15.2.3 COSTES DE MATERIAL..................................................... 196

15.2.4 COSTES INDIRECTOS ...................................................... 197


- F -

15.3 COSTE TOTAL DEL PROYECTO.................................................. 198

16. CONCLUSIONES Y LÍNEAS FUTURAS .............................. 199

17. BIBLIOGRAFÍA..................................................................... 201


- 1 -

1. INTRODUCCIÓN

Los proyectos, y en especial los proyectos a gran escala, han existido

desde tiempos antiguos. Este hecho lo atestigua la construcción de las

pirámides de Egipto y los acueductos de Roma.

El Proqramme Evaluation and Review Technique (PERT – Técnica de

revisión y evaluación de proyectos) fue desarrollado por científicos de la Oficina

de Proyectos Especiales de la Marina de los Estados Unidos de América. Con

este método se comienza descomponiendo el proyecto en una serie de

actividades, entendiendo por actividad la ejecución de una tarea que necesita

para su realización la utilización de uno o varios tipos de recursos (mano de

obra, maquinaria, materiales, tiempo, etc.), considerando como característica

fundamental su duración. La técnica demostró tanta utilidad que ha ganado

amplia aceptación tanto en el gobierno como en el sector privado.

Casi al mismo tiempo, la Compañía DuPont, junto con la División

UNIVAC de la Remington Rand, desarrolló el Critical Path Method (CPM,

Método del Camino Critico) para controlar la programación de cierres de

mantenimiento de plantas de procesamiento químico de DuPont. El CPM es

idéntico al PERT en concepto y metodología. La diferencia principal entre ellos

es simplemente el método por medio del cual se realizan estimaciones de

tiempo para las actividades del proyecto. Con CPM, los tiempos de las

actividades son deterministas. Con PERT, los tiempos de las actividades son

probabilísticos o estocásticos.


- 2 -

El PERT/CPM fue diseñado para proporcionar diversos elementos

útiles de información para los administradores del proyecto. Primero, el

PERT/CPM expone la "ruta crítica" de un proyecto. Estas son las actividades

que limitan la duración del proyecto. En otras palabras, para lograr que el

proyecto se realice pronto, las actividades de la ruta crítica deben realizarse

pronto. Por otra parte, si una actividad de la ruta crítica se retarda, el proyecto

como un todo se retarda en la misma cantidad. Las actividades que no están

en la ruta crítica tienen una cierta cantidad de holgura; esto significa que

pueden empezarse más tarde, y permitir que el proyecto como un todo se

mantenga en programa. El PERT/CPM identifica estas actividades y la cantidad

de tiempo disponible para retardos. A esto se le llama margen. Hay dos tipos

de márgenes: el margen libre (retraso que puede existir en el comienzo o en la

ejecución de una actividad sin modificar la fecha prevista de la etapa sucesora)

y el margen total (retraso que puede existir en el comienzo o en la ejecución de

una actividad sin modificar la fecha prevista de finalización del proyecto).

Ambos márgenes para la ruta crítica valen cero.

Finalmente, el PERT/CPM proporciona una herramienta para controlar

y monitorizar el progreso del proyecto. Las actividades de la ruta crítica,

permiten por consiguiente, recibir la mayor parte de la atención, debido a que la

terminación del proyecto, depende fuertemente de ellas. Las actividades no

críticas se manipularan y remplazaran en respuesta a la disponibilidad de

recursos.

En los años 60, en la Universidad de California en Berkeley, Lotfi A.

Zadeh introdujo el concepto de la lógica borrosa (ZADE65) guiado por el


- 3 -

principio de que las matemáticas pueden ser usadas para encadenar el

lenguaje con la inteligencia humana. Algunos conceptos pueden ser mejor

definidos en términos de palabras, que por matemáticas; la lógica borrosa y su

expresión en conjuntos borrosos, proveen una disciplina que puede construir

mejores modelos de la realidad.

La lógica borrosa es básicamente lógica multivaluada que amplifica los

enunciados de la lógica clásica intentando aplicar la forma de pensar del ser

humano a la programación de computadores, sensores, chips, etc. La habilidad

de la lógica borrosa para procesar valores parciales de verdad ha sido de gran

ayuda para la ingeniería.

La aplicación del adjetivo "borrosa" es debida a que los valores de

verdad no-deterministas utilizados en la lógica borrosa tienen mayoritariamente

una connotación de incertidumbre. De hecho, lo borroso puede entenderse

como la posibilidad de asignar más valores de verdad a los enunciados que

"falso" o "verdadero" e incluso en determinadas áreas de conocimiento, estos

enunciados van asociados a valores de verdad que son grados de veracidad o

falsedad.

Resumiendo, puede llegar a redefinir los grados de veracidad de los

enunciados de salida conforme se refinan los de los de entrada, por lo que

algunos sistemas de lógica borrosa ejercen una labor de aprendizaje, y son

excelentes mecanismos de control de procesos.

En conclusión, la lógica borrosa crea aproximaciones matemáticas en

la resolución de ciertos tipos de problemas, produciendo resultados exactos a


- 4 -

partir de datos imprecisos, siendo por ello, especialmente útiles en aplicaciones

de tipo electrónico e informático.

En el presente proyecto se estudia la posibilidad de aunar en una

aplicación informática dos reconocidas técnicas de ingeniería, el PERT/CMP y

la lógica borrosa, para integrar en la planificación de proyectos las actividades

que no tengan una duración determinada por diferentes factores. Estos factores

son las actividades nuevas, actividades que han sido desarrolladas de forma

experimental, y no están bien definidas, y actividades que han sido realizadas

múltiples veces pero varían dentro de un rango. Todas ellas se pueden modelar

usando la lógica borrosa por estimación de un experto en la materia.

La planificación de proyectos repercute económicamente en las

empresas que destinan sus recursos a un proyecto determinado deseando

necesariamente que se finalice en la fecha prevista. A la vista del proyecto, los

caminos críticos dependerán de las funciones que rijan sus actividades y

variarán según el tratamiento que se dé a las mismas.


- 5 -

2. EL PERT/CPM 2.1 GLOSARIO

Para lograr una adecuada comprensión del tema a desarrollar ha

redactado un glosario que sirva como guía para comprender la terminología

empleada.

PERT. La traducción de las siglas en inglés significan: técnica de

revisión y evaluación de programas, es una técnica de redes desarrollado en la

década de los 50, utilizada para programar y controlar programas a realizar.

Cuando hay un grado extremo de incertidumbre y cuando el control sobre el

tiempo es más importante sobre el control del costo, PERT es mejor opción que

CPM.

CPM. La traducción de las siglas en inglés significan: método del

camino crítico, es uno de los sistemas que siguen los principios de redes, que

fue desarrollado en 1957 y es utilizado para planear y controlar proyectos,

añadiendo el concepto de costo al formato PERT. Cuando los tiempos y costos

se pueden estimar relativamente bien, el CPM puede ser superior a PERT.

Actividad. Es un trabajo que se debe llevar a cabo como parte de un

proyecto, es simbolizado mediante una arista dirigida de la red de PERT.

Lista de actividades. Es una lista ordenada donde se recopilan todas

las diferentes actividades que intervienen en la realización de un proyecto.

Etapa. Se dice que se realiza una etapa, cuando todas las actividades

que llegan a un mismo nodo han sido terminadas. Son los círculos numerados


- 6 -

que forman parte del diagrama de red y representan el principio y el fin de las

actividades que intervienen en el proyecto.

Arista. Son las flechas que forman parte del diagrama de red y

representan cada una de las actividades del proyecto.

Ruta crítica o camino crítico. Se llama camino crítico tanto al método

como a la serie de actividades contadas desde la iniciación del proyecto hasta

su terminación que no tienen flexibilidad en su tiempo de ejecución, por lo que

cualquier retraso que sufriera alguna de las actividades de la serie provocaría

un retraso en todo el proyecto. Desde otro punto de vista, es la serie de

actividades que indica la duración total del proyecto.

Actividad Predecesora. Es una actividad que debe preceder (estar

antes) inmediatamente a una actividad dada en un proyecto.

Actividad Sucesora. Es una actividad que debe suceder (estar

después) inmediatamente a una actividad dada en un proyecto.

Diagrama de red. Es una red de círculos numerados (etapas)

conectados con flechas (actividades), donde se muestran todas las actividades

que intervienen en un determinado proyecto y la relación de prioridad entre las

actividades en la red así como las duraciones previstas y límites para cada

etapa del proyecto y los márgenes de cada actividad.

Actividad ficticia. Actividades imaginarias que existen dentro del

diagrama de red, sólo con el propósito de establecer las relaciones de

precedencia y no se les asigna tiempo alguno, es decir, que la actividad ficticia


- 7 -

Permite dibujar redes con las relaciones de precedencia apropiadas, se

representa por medio de una línea punteada.

Margen libre. Retraso que puede existir en el comienzo o en la

ejecución de una actividad sin modificar la fecha prevista de la etapa sucesora.

Margen total. Retraso que puede existir en el comienzo o en la

ejecución de una actividad sin modificar la fecha prevista de finalización del

proyecto.

Tiempo optimista. Es el tiempo mínimo o más corto posible en el cual

es probable que sea terminada una actividad, se simboliza con a en las

duraciones borrosas que se estudiaran en el capítulo siguiente.

Tiempo más probable. Es el tiempo más probable que toma una

actividad, en otras palabras, es el tiempo normal que se necesita en

circunstancias ordinarias para realizarla, se simboliza con el intervalo [A,B] en

las duraciones borrosas.

Tiempo pesimista. Es el tiempo máximo o más largo posible en el cual

es probable que sea terminada una actividad, bajo las condiciones más

desfavorables, simbolizado con b en las duraciones borrosas.

Fecha prevista. Es la fecha de una etapa en la que se prevé que todas

las actividades que llegan a ella estarán terminadas.

Fecha límite. Es la fecha de una etapa que si se rebasa implica el

retraso de todo el proyecto.


- 8 -

Intervalo de flotamiento. Es el intervalo de tiempo en el que se puede

completar una etapa sin retrasar el proyecto. Comprende desde la fecha

prevista hasta la fecha límite para cada etapa. Si la etapa forma parte del

camino crítico el intervalo de flotamiento será cero.

2.2 VENTAJAS PERT Y CPM

1. Enseña una disciplina lógica para planificar y organizar un programa

detallado de largo alcance.

2. Identifica los elementos (segmentos) más críticos del plan, en que

problemas potenciales puedan perjudicar el cumplimiento del programa

propuesto.

3. Ofrece la posibilidad de simular los efectos de las decisiones alternativas

o situaciones imprevistas y una oportunidad para estudiar sus

consecuencias en relación a los plazos de cumplimiento de los

programas.

4. Aporta la probabilidad de cumplir exitosamente los plazos propuestos.

En otras palabras: CPM es un sistema dinámico, que se mueve con el

progreso del proyecto, reflejando en cualquier momento el STATUS

presente del plan de acción.

2.3 CAMPO DE ACCIÓN

El campo de acción de este método es muy amplio, dada su gran

flexibilidad y adaptabilidad a cualquier proyecto grande o pequeño. Para


- 9 -

obtener los mejores resultados debe aplicarse a los proyectos que posean las

siguientes características:

1. Que el proyecto sea único, no repetitivo, en algunas partes o en su

totalidad.

2. Que se deba ejecutar todo el proyecto o parte de el, en un tiempo

mínimo, sin variaciones, es decir, en tiempo crítico.

3. Que se desee el costo de operación más bajo posible dentro de un

tiempo disponible.

Dentro del ámbito aplicación, el método se ha estado usando para la

planeación y control de diversas actividades, tales como construcción de

presas, apertura de caminos, pavimentación, construcción de casas y edificios,

reparación de barcos, investigación de mercados, movimientos de colonización,

estudios económicos regionales, auditorias, planeación de carreras

universitarias, distribución de tiempos de salas de operaciones, ampliaciones

de fábrica, planeación de itinerarios para cobranzas, planes de venta, censos

de población, etcétera.

2.4 DISEÑO DEL DIAGRAMA DE RED

Para aplicar CPM o PERT se requiere conocer la lista de actividades

que incluye un proyecto. Se considera que el proyecto esta terminado cuando

todas las actividades han sido completadas. Para cada actividad, puede existir

un conjunto de actividades predecesoras que deben ser completadas antes de

que comience la nueva actividad. Se construye una malla o red del proyecto


- 10 -

para graficar las relaciones de precedencia entre las actividades. En dicha

representación grafica, cada actividad es representada como un arco y cada

nodo (etapa) ilustra la culminación de una o varias actividades.

Consideremos un proyecto que consta de solo dos actividades A y B.

Supongamos que la actividad A es predecesora de la actividad B. La

representación grafica de este proyecto se muestra en la figura. Así, el nodo 2

representa la culminación de la actividad A y el comienzo de la actividad B.

Si suponemos ahora que las actividades A y B deben ser terminadas

antes que una actividad C pueda comenzar, la malla del proyecto queda como

se muestra en la ilustración 2. En este caso, el nodo representa que las

actividades A y B se han terminado, además del inicio de la actividad C. Si la

actividad A fuera predecesora de las actividades B y C, la red quedara como se

muestra en la ilustración 3.

Dado un conjunto de actividades y sus relaciones de predecisión o

sucesión, se puede construir una representación grafica de acuerdo a las

siguientes reglas:

A B

1

2 3

Ilustración 2.1 – Diagrama de red de dos actividades

3

2

1 A

C

B 2 1

A

B

C

Ilustración 2.2 – A y B preceden a C Ilustración 2.3 – A precede a B y C


- 11 -

• El nodo 1 representa el inicio del proyecto. Por lo tanto, las actividades

que parten del nodo 1 no pueden tener predecesoras.

• El nodo Terminal o final del proyecto debe representar el término de

todas las actividades incluidas en la red.

• Una actividad no puede ser representada por más de un arco en la red.

• Dos nodos deben estar conectados como máximo por un arco.

Para no violar las reglas 3 y 4, a veces es necesario introducir una

actividad ficticia o dummy que posee tiempo de duración nulo. Por ejemplo,

supongamos que las actividades A y B tienen como actividad sucesora a la

actividad C y además comienzan al mismo tiempo o en la misma etapa. En

este caso, una primera representación podría ser la indicada en la figura

siguiente.

Ilustración 2.4 – Representación errónea de sucesión sin actividad ficticia

Sin embargo, la red de la ilustración 4 viola el cuarto punto. Para

corregir este problema, se introduce una actividad ficticia indicada con un arco

segmentado en la figura.


- 12 -

Ilustración 2.5 – Actividad dummy

La red de la ilustración 5 refleja el hecho de que la actividad C tiene

como predecesoras a A y B, pero sin violar el punto 4. En otros casos, se

deben agregar actividades dummy para no violar la regla 3. En la siguiente

figura se muestra la lógica para construir un diagrama de red.

Ilustración 2.6 – Lógica de construcción del diagrama de red


- 13 -

2.5 EL MÉTODO CPM

2.5.1 APLICACIÓN DEL MÉTODO CPM

Los pasos a seguir para plantear un proyecto con el método del camino

crítico CPM son:

Especificar las actividades individuales. Se realiza una lista de

todas las actividades de las que se compone el proyecto. En este listado se

puede añadir un identificador a cada actividad y una descripción de la misma.

Es obligado estimar la duración de cada actividad, modelarla según la función

de probabilidad a la que se ajuste o representarla mediante un número borroso

que se explicara en el siguiente apartado del proyecto.

Determinar la secuencia de las actividades. Algunas actividades son

dependientes en la terminación de otras, es decir son las sucesoras de otras

actividades que necesitan completarse antes de que éstas empiecen. Un

listado de los precursores inmediatos de cada actividad o un listado de los

sucesores de cada actividad es útil para construir el diagrama de la red del

CPM.

Dibujar el diagrama de la red. Una vez que se hayan definido las

actividades, el diagrama del CPM puede ser dibujado. El CPM fue desarrollado

originalmente como actividad en red del nodo (AON), pero algunos

planificadores del proyecto prefieren especificar las actividades en los arcos.

Hay que tener en cuenta las reglas para la construcción del diagrama descritas

anteriormente.


- 14 -

Añadir la información al diagrama de red. La información recopilada

para cada actividad es aconsejable añadirla en el diagrama. La etapa inicial se

numerará con un uno. Se irán numerando las diferentes etapas hasta llegar a la

final del proyecto que tendrá el número mayor. En la figura siguiente se

representa la información que debería contener el diagrama en este apartado.

Ilustración 2.7 – Información primaria de un diagrama de red

Fase hacia delante. En esta fase se pretende determinar los

instantes más tempranos o la fecha prevista para cada etapa o nodo. Para ello

se asigna al nodo inicial la fecha prevista cero. Luego se elige un nodo tal que

todos los anteriores que estén unidos directamente a él por una actividad ya

tengan fecha prevista. Se etiqueta el nodo elegido con la duración máxima de

la suma de la duración cada actividad más la fecha prevista del nodo del que

proviene. Por tanto, usando la notación tk para la fecha prevista del nodo k y ti,k

para la duración de la actividad que va del nodo i al k, la formula a emplear es:

},...,,max{ ,,22,11 knmnmknnknnk ttttttt +++=

Ecuación 2.1


- 15 -

Este paso se repite hasta etiquetar el nodo final, entonces esta será la duración

mínima del proyecto.

Fase hacia atrás. En esta fase se pretende determinar los instantes

más tardíos o la fecha límite para cada etapa o nodo. Para ello se asigna al

nodo final la fecha límite, siendo esta la misma que su fecha prevista. Luego se

elige un nodo tal que todos los siguientes que estén unidos directamente a él

por una actividad ya tengan fecha límite. Se etiqueta el nodo elegido con la

duración mínima de la resta de la fecha límite del nodo al que llega menos la

duración de la actividad que los une. Por tanto, usando la notación ti* para la

fecha límite del nodo i y ti,k para la duración de la actividad que va del nodo i al

k, la formula a emplear es:

},...,,min{* ,2,21,1 nminmninnini ttttttt −−−=

Ecuación 2.2

Este paso se repite hasta etiquetar el nodo inicial, debiendo ser éste igual a su

fecha prevista, es decir, cero.

Identificar las actividades críticas. Habiendo determinado las fechas

previstas y límites de todos los nodos de la red, la identificación del camino

crítico es sencilla. Las actividades críticas de la red serán aquellas que unan

aquellos nodos cuyas fechas previstas y límites sean iguales (las etapas con

intervalo de flotamiento igual a cero). Estos nodos también forman parte del

camino crítico.


- 16 -

Calcular los márgenes de cada actividad. Los márgenes u holguras

de cada actividad son los retrasos que puede tener cada actividad. Se calcula

tanto el margen libre como el total denotándolos con Li,k y Si,k respectivamente.

kiikki

kiikki

tttS

tttL

,,

,,

* −−=

−−=

Ecuación 2.3

Por tanto el margen libre de la actividad que va del nodo i al k será el retraso

que puede existir en el comienzo o en la ejecución de la actividad que va de i a

k sin modificar la fecha prevista de la etapa k. El margen total de la actividad

que va del nodo i al k será el retraso que puede existir en el comienzo o en la

ejecución de una actividad que va de i a k sin modificar la fecha prevista de

finalización del proyecto. Cabe destacar que las actividades que formen parte

de la ruta crítica tendrán ambos márgenes iguales a cero.

Los datos ahora de los cuales se compone el diagrama y los lugares

donde se sitúan se muestran en la imagen 8.

Ilustración 2.8 – Información completa de un diagrama de red


- 17 -

Realizar el diagrama de Gantt. El diagrama de es una popular

herramienta gráfica cuyo objetivo es el de mostrar el tiempo de dedicación

previsto para diferentes actividades a lo largo de un tiempo total determinado. A

pesar de que, en principio, el diagrama de Gantt no indica las relaciones

existentes entre actividades, la posición de cada tarea a lo largo del tiempo

hace que se puedan identificar dichas relaciones e interdependencias.

En gestión de proyectos, el diagrama de Gantt muestra el origen y final de las

diferentes actividades y las dependencias entre las mismas. Desde su

introducción los diagramas de Gantt se han convertido en una herramienta

básica en la gestión de proyectos de todo tipo, con la finalidad de representar

las diferentes actividades programadas como parte de un proyecto o para

mostrar una línea de tiempo en las diferentes actividades haciendo el método

más eficiente. Aunque un diagrama de Gantt es fácilmente comprensible para

proyectos pequeños en los que el diagrama cabe en una única hoja de papel o

en una pantalla, puede ser bastante engorroso para proyectos con más de

unas 30 actividades.

Actualizar el diagrama según progresa el proyecto. Los tiempos

reales de la terminación de la tarea serán sabidos y el diagrama de la red se

puede poner al día para incluir esta información. Una trayectoria crítica nueva

puede emerger, y los cambios estructurales se pueden realizar en la red si los

requisitos del proyecto cambian.


- 18 -

2.5.2 EJEMPLO DE CPM

A continuación se muestra un ejemplo siguiendo los pasos para

resolver una red de actividades CPM:

Especificar las actividades individuales y determinar la secuencia

de las actividades.

Tabla 2.1 – Descripción de las actividades del proyecto

Dibujar el diagrama de la red y añadirle la información

Ilustración 2.9 – Diagrama de red con información básica


- 19 -

Fase hacia delante.

Ilustración 2.10 – Diagrama de red tras la fase hacia delante

Fase hacia atrás.

Ilustración 2.11 – Diagrama de red tras la fase hacia atrás


- 20 -

Identificar las actividades críticas.

Ilustración 2.12 – Identificación del camino crítico

Calcular los márgenes de cada actividad.

Ilustración 2.13– Diagrama de red con información completa


- 21 -

Realizar el diagrama de Gantt.

Ilustración 2.14 – Diagrama de red proporcionado por la aplicación

2.5.3 LIMITACIONES DEL CPM

El CPM fue desarrollado para proyectos bastante rutinarios con

incertidumbre mínima en los tiempos de la terminación del proyecto. Para otros

proyectos menos rutinarios hay más incertidumbre en los tiempos de

terminación, ello trae consigo las limitaciones del modelo determinista del CPM

al introducir incertidumbre. Una alternativa al CPM es el modelo del

planeamiento del proyecto del PERT, que permite que una gama de duraciones

sea especificada para cada actividad.


- 22 -

2.6 EL MÉTODO PERT

En CPM se asume que la duración de cada actividad es conocida con

certeza. Claramente, en muchas ocasiones este supuesto no es valido. PERT

intenta corregir este error suponiendo que la duración de cada actividad es una

variable aleatoria.

2.6.1 TIEMPOS DE ESTIMACIÓN DE ACTIVIDAD

Para cada activad, se requiere estimar las siguientes cantidades:

a = Tiempo Optimista. Duración de la actividad bajo las condiciones

más favorables

b = Tiempo Pesimista. Duración de la actividad bajo las condiciones

más desfavorables

m = Tiempo Normal. El valor más probable de la duración de la

actividad.

La forma de la distribución se muestra en la Ilustración 15. El tiempo

más probable es el tiempo requerido para completar la actividad bajo

condiciones normales. Los tiempos optimistas y pesimistas proporcionan una

medida de la incertidumbre inherente en la actividad, incluyendo desperfectos

en el equipo, disponibilidad de mano de obra, retardo en los materiales y otros

factores.


- 23 -

Ilustración 2.15 – Estimación del tiempo optimista, pesimista y normal

Con la distribución definida, la media (esperada) y la desviación están-

dar, respectivamente, del tiempo de la actividad para la actividad Z puede

calcularse por medio de las fórmulas de aproximación:

( )

( )6

6

4

abZ

bmaZTe

−=

++=

σ

Ecuación 2.4

El tiempo esperado de finalización de un proyecto es la suma de todos

los tiempos esperados de las actividades sobre la ruta crítica. De modo similar,

suponiendo que las distribuciones de los tiempos de las actividades son

independientes (una suposición fuertemente cuestionable), la varianza del

proyecto es la suma de las varianzas de las actividades en la ruta crítica.

Si Tij es la variable aleatoria asociada a la duración de la actividad (i,j),

PERT asume que Tij sigue una distribución Beta. Sin entrar en mayores


- 24 -

detalles de esta distribución, se puede demostrar que el valor esperado y la

varianza de la variable aleatoria Tij quedan definidas por:

[ ] ( )

[ ] ( )36

6

4

2ab

TijV

bmaZTijE

e

−=

++=

Ecuación 2.5

Por lo tanto, el valor esperado y la varianza de una ruta pueden ser

estimadas según:

[ ]( )∑∈Rutaij

Tij

= Duración esperada de la ruta

[ ]( )∑∈Rutaij

Vij

= Variación de la duración de la ruta

2.6.2 DETERMINAR LA RUTA CRÍTICA

La ruta crítica es determinada agregando los tiempos para las

actividades en cada secuencia y determinando la ruta mas larga del proyecto.

La ruta crítica determina el tiempo total del calendario requerido para el

proyecto. Si las actividades fuera de la ruta cítrica aceleran o retrasaron el

tiempo (dentro de los límites), entonces el tiempo total de proyecto no varía. Al

tiempo de una actividad no crítica de la ruta, que no altera la duración del

proyecto, se denomina tiempo flojo.

Si la ruta crítica del proyecto no resulta obvia, entonces puede ser

provechoso determinar las cuatro cantidades siguientes para cada actividad:


- 25 -

• ES, principio temprano.

• EF, principio tardío.

• LS, terminación temprana.

• LF, terminación tardía.

Se calculan estos tiempos usando la duración prevista para las

actividades relevantes. Los tiempos más tempranos del comienzo y del final de

cada actividad son determinados trabajando adelante a través de la red y

determinando el tiempo más temprano en el cual una actividad puede

comenzar y acabar a considerar sus actividades del precursor. Los tiempos

más tardíos del comienzo y del final son los tiempos más tardíos en que una

actividad puede comenzar y acabar sin variar el proyecto. El LS y el LF son

encontrados trabajando al revés a través de la red. La diferencia en el final más

tardío y más temprano de cada actividad es holgura de esa actividad. La ruta

crítica entonces es la trayectoria a través de la red en la cual ningunas de las

actividades tienen holgura.

La variación en el tiempo de la terminación del proyecto puede ser

calculada sumando las variaciones en los tiempos de la terminación de las

actividades en la ruta crítica. Dado esta variación, se puede calcular la

probabilidad que el proyecto será terminado por cierta fecha si se asume que

una distribución normal de la probabilidad para la trayectoria crítica.

Sea CP la variable aleatoria asociada a la duración total de las

actividades de la ruta crítica determinadas mediante CPM. PERT asume que la


- 26 -

ruta crítica encontrada a través de CPM contiene suficientes actividades para

emplear el Teorema Central del Límite y concluir que CP se distribuye

normalmente.

( )

TijCPRutaij

∑∈

=

Ecuación 2.6

Puesto que la ruta crítica determina la fecha de la terminación del

proyecto, el proyecto puede ser acelerado agregando los recursos requeridos

para disminuir la duración para las actividades en la ruta crítica.

2.6.3 VENTAJAS DEL PERT

El PERT es útil porque proporciona la información siguiente:

• Tiempo previsto de la terminación del proyecto.

• Probabilidad de la terminación antes de una fecha especificada.

• Las actividades de la trayectoria crítica que afectan directamente el

tiempo de la terminación.

• Las actividades que tienen tiempo flojo y que pueden prestar recursos a

las actividades de la trayectoria crítica.

• Fechas del comienzo y de fin de la actividad.


- 27 -

2.6.4 LIMITACIONES

A continuación se describen algunas de las debilidades del PERT:

• Las estimaciones del tiempo de la actividad son algo subjetivas y

dependen del juicio. En casos donde hay poca experiencia en la

ejecución de una actividad, los números pueden ser solamente una

conjetura. En otros casos, si la persona o el grupo que realiza la

actividad estiman el tiempo puede haber una mejor estimación.

• Incluso si se estiman correctamente los tiempos de la actividad, el PERT

asume una distribución beta para éstos aunque la distribución real

puede ser diferente.

• El PERT asume que la distribución de la probabilidad del tiempo de la

terminación del proyecto es igual que el de la ruta crítica. Otras

trayectorias pueden convertirse en la ruta crítica si se retrasan sus

actividades asociadas, el PERT subestima constantemente el tiempo

previsto de la terminación del proyecto.

2.7 CONCLUSIONES

El PERT y CPM han sido aplicados a numerosos proyectos. El PERT

se desarrolló para proyectos en donde hubiera incertidumbre en el tiempo de

las actividades (usualmente debido a que el proyecto nunca se había intentado

antes y por tanto no había bases de datos para los tiempos de las actividades).

Esto condujo al enfoque probabilístico que se tomó. La principal

desventaja es que no es funcional para grandes proyectos, debido a los tres


- 28 -

estimados de tiempo que se requieren en cada. Además, el coste de actualizar

y mantener la información del proyecto con el tiempo en ambientes tan dinámi-

cos, puede ser excesivamente trabajoso.

Por otra parte, el CPM se desarrolló para manejar proyectos repetitivos.

Obviamente, se gana gran cantidad de experiencia con el tiempo en tales

circunstancias, aun cuando dos proyectos puede que no sean iguales. Esta

experiencia llevó al análisis de técnicas de colisión utilizadas en las redes CPM.


- 29 -

3. LA LÓGICA BORROSA

En 1965, L. A. Zadeh introduce la teoría de conjuntos borrosos

(ZADE65), como un mecanismo para representar la vaguedad e imprecisión de

los conceptos empleados en el lenguaje natural. Estos conjuntos borrosos

fueron definidos como una extensión de los conjuntos clásicos capaz de

modelar la imprecisión propia de los conceptos humanos. A mediados de los 70

llega la ampliación del concepto de conjunto al de lógica, apareciendo las

lógicas borrosas y las aplicaciones a sistemas de control. Hoy en día son

muchas las aplicaciones tanto industriales como domésticas que hacen uso de

este paradigma.

3.1 CONJUNTOS CLÁSICOS

Como se ha apuntado, el origen de la lógica borrosa es la noción de

conjunto borroso. Antes de abordar el estudio de la Teoría de Conjuntos

Borrosos, se revisarán algunos de los conceptos básicos de la Teoría Clásica,

con el objeto de alcanzar una mayor comprensión de ambas.

El punto de partida de la teoría de conjuntos son las nociones de

elemento y de conjunto. Un conjunto se define genéricamente como una

colección de elementos. Típicamente los elementos que forman parte de un

conjunto tienen algún tipo de propiedad en común que les haga susceptibles de

pertenecer al conjunto, pero tal requisito es meramente anecdótico. El conjunto

se suele representar con una letra mayúscula, tipo A, B, C, etc., y los

elementos del mismo se representan con una letra minúscula (a, b, c, etc.).


- 30 -

Sobre los conjuntos se define una relación de pertenencia, la cual se

denota con el símbolo ∈. Así pues, si el elemento a pertenece al conjunto A,

este hecho se formaliza mediante la expresión Aa ∈ y en el caso en que b no

pertenezca a A se escribe Ab ∉ .

Respecto a la forma de descripción del conjunto, ésta se puede realizar

de manera enumerativa, },...,,{ 21 naaaA = , o bien, mediante la ley de formación

a la que se ha hecho referencia A =”los diez primeros números naturales”. Tal

definición, como puede imaginarse, es equivalente a escribir de forma

enumerativa }10,...,2,1{=A .

Se define el cardinal de un conjunto como el número de elementos que

forman parte de dicho conjunto. Si dicho cardinal es un número finito, el

conjunto se denominará finito. Caso contrario será infinito. Dentro de estos

últimos, deben distinguirse los de cardinal numerable, que serán aquellos

cuyos elementos se pueden poner en relación 1:1 con los números enteros (por

ejemplo, el conjunto de los números pares), por otra parte nos encontraremos

conjuntos de cardinal no numerable, como, por ejemplo, el conjunto de los

números reales comprendidos entre dos números a y b.

La relación de inclusión se deriva de la relación de pertenencia; un

conjunto B se dice que está incluido dentro de un conjunto A cuando todos los

elementos de B están en A. Si tal es el caso, podemos expresar de forma

abreviada que AB ⊂ , o bien que BA ⊃ . Si se verifica que AB ⊂ y que BA ⊃

de forma simultánea, entonces es que los dos conjuntos son iguales.


- 31 -

Dos conjuntos de dice que son disjuntos si no tienen ningún elemento

en común. A estos conjuntos se les denomina también mutuamente

excluyentes.

Dado un problema, el conjunto universal, denotado por S, será el

conjunto formado por todos los elementos del problema. De forma

complementaria, el conjunto vacío, denotado por ∅ , será un conjunto sin

ningún elemento. Como es natural, los conjuntos S y ∅ son mutuamente

excluyentes.

Sea S un universo del cual cualquier conjunto A es subconjunto, esto

es:

SA ⊆ , A∀

Ecuación 3.1

En teoría clásica de conjuntos cualquier elemento x perteneciente a S

pertenece o no pertenece al subconjunto A de manera clara e inequívoca, sin

que exista ninguna otra posibilidad al margen de estas dos.

La pertenencia o no de un elemento arbitrario x a un subconjunto A

viene dada en la mayoría de los casos por la verificación o no de un predicado

que caracteriza a A y da lugar a una bipartición del universo de discurso S.

3.1.1 FUNCIÓN CARTESIANA

El concepto de pertenencia o no de un elemento a un conjunto A puede

expresarse numéricamente mediante una función característica. Esta función


- 32 -

asigna a cada elemento x del universo de discurso un dígito binario (1 ó 0)

según x pertenezca o no al conjunto A.

∉

∈=

→

Axsi

Axsix

Sx

A

A

0

1)(

}1,0{:)(

ϕ

ϕ

Ecuación 3.2

Por ejemplo, el conjunto }10,9,8,7,6,5,4,3{=A se puede representar por

su función característica

∈

=casootroen

xparaxA

0

}10,9,8,7,6,5,4,3{1)(ϕ

Ecuación 3.3

3.1.2 OPERACIONES BÁSICAS ENTRE CONJUNTOS

Dados dos conjuntos cualesquiera A y B incluidos en S es posible

definir un conjunto de operaciones básicas entre ellos:

Complemento: El complemento de A se denota por A , y está formado

por todos los elementos de S que no pertenecen a A (operador unario).

AxsiAx ∉∈

Ecuación 3.4

Su función de característica será:

)(1)( xx AAϕϕ −=

Ecuación 3.5


- 33 -

Intersección: se denota por BA ∩ y se define como el conjunto

formado por aquellos elementos de S que pertenecen a A y a B

simultáneamente:

BxyAxsiBAx ∈∈∩∈

Ecuación 3.6


))(),(min()( xxx BABA ϕϕϕ =∩

Ecuación 3.7

Unión: Es el conjunto formado por aquellos elementos que pertenecen

a A, o pertenecen a B, o bien a ambos simultáneamente. Se denota por BA ∪ .

BxóAxsiBAx ∈∈∪∈

Ecuación 3.8


))(),(max()( xxx BABA ϕϕϕ =∪

Ecuación 3.9

3.1.3 PROPIEDADES DE LOS CONJUNTOS CLÁSICOS

Las operaciones entre conjuntos clásicos presentan ciertas leyes y

propiedades:

1. Propiedad conmutativa

ABBA

ABBA

∩=∩

∪=∪

Ecuación 3.10

2. Propiedad asociativa


- 34 -

)()(

)()(

CBACBA

CBACBA

∩∩=∩∩

∪∪=∪∪

Ecuación 3.11

3. Leyes de idempotencia

AAA

AAA

=∩

=∪

Ecuación 3.12

4. Leyes de absorción

AABA

AABA

=∪∩

=∩∪

)(

)(

Ecuación 3.13

5. Propiedad distributiva

)()()(

)()()(

CABACBA

CABACBA

∩∪∩=∪∩

∪∩∪=∩∪

Ecuación 3.14

6. Propiedades de absorción por S y ∅

∅=∅∩

=∪

A

SSA

Ecuación 3.15

7. Propiedades de identidad

AA

ASA

=∅∪

=∩

Ecuación 3.16

8. Involución del complemento


- 35 -

AA =

Ecuación 3.17

9. Leyes de Morgan

BABA

BABA

∪=∩

∩=∪

Ecuación 3.18

10. Leyes complementarias

∅=∩

=∪

AA

SAA

Ecuación 3.19

3.2 CONJUNTOS BORROSOS

En la sección anterior se ha visto cómo la mayoría de las veces los

conjuntos clásicos se definen mediante un predicado que da lugar a una clara

bipartición del universo de discurso S. Sin embargo, el razonamiento humano

utiliza frecuentemente predicados de los cuales no resulta esa bipartición; son

los denominados predicados vagos.

Como ejemplo, se propone la variable edad y tres conjuntos para

definir a los individuos; joven, maduro y viejo.

Por supuesto, es imposible dar a una persona una definición clásica, ya

que su correspondiente predicado no divide el universo en tres partes

claramente diferenciadas. No resulta nada fácil afirmar con rotundidad que una

persona es joven o no lo es. El problema podría resolverse en parte

considerando que una persona es joven cuando su edad supera cierto umbral


- 36 -

fijado de antemano. Decimos que el problema tan sólo se resuelve en parte, y

de manera no muy convincente, por dos motivos: de una parte el umbral

mencionado se establece de una manera arbitraria, y por otro lado podría darse

el caso de que dos personas con edades muy diferentes fuesen considerados

ambos como jóvenes. Evidentemente, el concepto joven así definido nos daría

una información muy pobre sobre la edad de la persona en cuestión.

La manera más apropiada de dar solución a este problema es

considerar que la pertenencia o no pertenencia de una persona x al conjunto

joven no es absoluta sino gradual. En definitiva, definiremos joven como un

conjunto borroso. Su función característica (ahora “de pertenencia") ya no

adoptará valores en el conjunto discreto {0,1}, sino en el intervalo cerrado [0,1].

Mediante notación matemática se define un conjunto borroso A como:

}|))(,{( SxxxA A ∈= µ

Ecuación 3.20

3.2.1 FUNCIÓN DE PERTENENCIA

La función característica es reemplazada por una función de

pertenencia que se define

]1,0[: →SAµ

Ecuación 3.21

de tal modo que ]1,0[)( ∈xAµ es el grado con el que un elemento Sx ∈ (siendo

S el universo de discurso) pertenece al conjunto borroso A. Cuando 0)( =xAµ

el elemento no pertenece al conjunto, y cuando 1)( =xAµ pertenece totalmente.


- 37 -

La forma de la función de pertenencia tiene una cierta componente

subjetiva, frente a la forma rígida (objetiva) de las funciones características de

la lógica clásica. En función de la aplicación de los conjuntos o de los

conceptos representados por ellos, estas funciones pueden adquirir muy

diversas formas, y muchas veces pueden ser elegidas con un amplio grado de

libertad por parte del diseñador, lo que en la práctica puede traducirse como la

posibilidad de incluir cierto conocimiento experto.

A pesar de que las funciones podrían tener cualquier forma, en la

literatura se tiende a trabajar con funciones de pertenencia estándares:

1. Funciones Gaussianas o con forma de “S”. Usan la fórmula

( )

−=

2

2

2exp

2

1)(

d

mx

sx

πµ

Ecuación 3.22

Ilustración 3.1 – Función Gaussiana

Permiten modelar fácilmente modificadores pero son complicadas para el

cálculo.

2. Funciones triangulares o trapezoidales. Se definen en función de los

vértices de las funciones; ∆ (a,b,c) para las triangulares


- 38 -

Ilustración 3.2 – Función Triangular

y T(a,b,c,d) para las trapezoidales. Son sencillas de manejar en algoritmos

numéricos.

Ilustración 3.3 – Función Trapezoidal

Zeng y Singh definen un modelo de función de pertenencia que agrupa

a las principales clases, la función Pseudo-trapezoidal (Del inglés pseudo

trapezoid-shaped (PTS)) es una función continua dada por

∉∈=−∈

∈

∈

∈

=

]},[,|{],[0

],()(

],[

),[)(

),,,,;(

daxUxxdaUx

dcxxD

cbxh

baxxI

hdcbaxA

Ecuación 3.23

donde a ≤b ≤ c ≤ d, a < d, 0)( ≥xI es una función monótona estrictamente

creciente en [a,b) y 0)( ≥xD es una función monótona estrictamente

decreciente en (c,d]. Cuando la función de pertenencia de un conjunto borroso

A es una función PTS, se llama función de pertenencia PTS y se denota por


- 39 -

),,,,;()( hdcbaxAxA = . Cuando el conjunto borroso es normal (es decir, h = 1),

su función de pertenencia se denota simplemente por ),,,;()( dcbaxAxA = .

Ilustración 3.4 – Función Trapezoidal normal

De acuerdo con esta definición, las funciones trapezoidales son un

caso especial de las funciones PTS cuando b < c y

cd

xdxD

ab

axxI

−

−=

−

−=

)(

)(

Ecuación 3.24

y las funciones triangulares es el caso especial cuando b = c y

bd

xd

cd

xdxD

ac

ax

ab

axxI

−

−=

−

−=

−

−=

−

−=

)(

)(

Ecuación 3.25

Como ejemplo, en la siguiente figura se muestran algunos conjuntos

borrosos definidos en el universo de discurso Edad anteriormente mencionado.

El conjunto borroso “Joven" representa el grado de pertenencia respecto al

parámetro juventud que tendrían los individuos de cada edad. Dicho de otra

manera, el conjunto expresa la posibilidad de que un individuo sea


- 40 -

caracterizado como “Joven". Un conjunto borroso podría ser considerado una

distribución de posibilidad, que es diferente a una distribución de probabilidad.

Ilustración 3.5 – Representación de los conjuntos joven, maduro y viejo

Puede verse que los conjuntos borrosos de la figura se superponen,

entonces un individuo x con edad de 30 años, podría tener un grado de

pertenencia en dos conjuntos: “Joven" y “Maduro", indicando que posee

cualidades asociadas con ambos conjuntos.

Por razones prácticas, muchas veces se asume que el universo de

discurso S es finito, esto es { }nxxS ,...,1= , y el par )}),({( xxAµ se denota por

xxA /)(µ , y cada par xxA /)(µ se denomina individualidad borrosa (fuzzy

singleton). El conjunto borroso A se puede reescribir como

∑=

=++===n

i

iiAnnAAAA xxxxxxxxxxA1

11 /)(/)(.../)(}/)({)}),({( µµµµµ

Ecuación 3.26

donde + y Σ deben entenderse en el sentido de la teoría de conjuntos. Por

convenio, los pares xxA /)(µ con 0)( =xAµ se omiten.

3.2.2 DEFINICIONES BÁSICAS SOBRE CONJUNTOS BORROSOS


- 41 -

A continuación se presentan una serie de definiciones básicas de

utilidad en el manejo de los conjuntos borrosos:

Conjunto vacío: Se dice que un conjunto borroso A está vacío, y se

escribe ∅=A , si y sólo si

UxxA ∈∀= 0)(µ

Ecuación 3.27

Igualdad: Se dice que dos conjuntos borrosos A y B definidos sobre

el mismo universo de discurso U son iguales, y se escribe BA = si y sólo si

Uxxx BA ∈∀= )()( µµ

Ecuación 3.28

Contención: Se dice que un conjunto borroso A definido en U está

contenido en B definido en U también (o alternativamente, es un subconjunto

de B ), y se escribe BA ⊆ , si y sólo si

Uxxx BA ∈∀≤ )()( µµ

Ecuación 3.29

Normalidad: Se dice que un conjunto borroso A definido en U es

normal si y sólo si

1)(max =∈

xAUx

µ

Ecuación 3.30

Soporte: El soporte de un conjunto borroso A en U (escrito AS ) es el

conjunto no borroso


- 42 -

USyxUxS AAA ⊆⊆∅>∈= }0)(:{ µ

Ecuación 3.31

Núcleo: El núcleo de un conjunto borroso A en U (escrito AN ) es el

conjunto no borroso

UNyxUxN AAA ⊆⊆∅=∈= }0)(:{ µ

Ecuación 3.32

Partición completa: Se dice que los conjuntos borrosos NAAA ,..., 21

son una partición completa de U si Ux ∈∀ existe al menos un )1( NiiAi ≤≤=

tal que 0)( >xAi . Por simplicidad, se dice que los conjuntos NAAA ,..., 21 son

completos si forman una partición completa.

Consistencia: Se dice que los conjuntos borrosos NAAA ,..., 21

son

consistentes si se verifica que si 1)( =xAi para algún Ux ∈0

, entonces

0)(, 0 =≠∀ xAij j .

Subconjunto Normal de un Conjunto Borroso Normal: Se define el

subconjunto normal de un conjunto borroso normal A como

{ }1)(|)( =∈= xAyUxxAM

Ecuación 3.33

que es un subconjunto de AS (el soporte del conjunto borroso A ). Si el

conjunto borroso normal A tiene función de pertenencia PTS, entonces

],[)( cbAM = .


- 43 -

Orden entre Conjuntos Borrosos Normales: Para dos conjuntos

borrosos normales A y UB ⊂ , se dice que BA > si )()( BMAM > ,

definiéndose esta desigualdad como

)(max)(max BMAMxx

>

Ecuación 3.34

3.2.3 OPERACIONES BÁSICAS ENTRE CONJUNTOS BORROSOS

Las tres operaciones básicas definidas sobre los conjuntos clásicos

(complemento, intersección y unión) pueden ser generalizadas a los conjuntos

borrosos de diversas formas.

Ilustración 3.6 – Operaciones básicas de los conjuntos borrosos

Dentro de la teoría de los conjuntos borrosos tiene especial relevancia

la que hace uso de operaciones conocidas como operaciones estándar,

definidas como:

Intersección (T-norma): ))(),(min()( xxx BABA µµµ =∩

Unión (T-conorma): ))(),(max()( xxx BABA µµµ =∪

Complemento: )(1)( xx AAµµ −=


- 44 -

No obstante, al contrario que pasa con los conjuntos clásicos, ésta no

es la única forma posible de definir estas operaciones; diferentes funciones

pueden ser apropiadas para representarlas en diferentes contextos. Por lo

tanto, no sólo las funciones de pertenencia de los conjuntos borrosos van a ser

dependientes del contexto sino también las operaciones sobre dichos

conjuntos. En este proyecto no se comentarán con más detalle.

3.2.4 PRINCIPIO DE EXTENSIÓN

Este principio proporciona un mecanismo para calcular los conjuntos

borrosos obtenidos por medio de una transformación concreta (no borrosa) de

cierto número ( N ) de conjuntos borrosos. Específicamente, si NXXX ,..., 21 son

conjuntos borrosos con funciones de pertenencia )(),...(),( 2211 NN xxx µµµ , el

nuevo conjunto borroso ),...,( 21 NXXXfY = tendrá como función de

pertenencia:

=

== −)(minmax)(

1)()1( ii

N

iyfx

yy µµ

Ecuación 3.35


- 45 -

3.2.5 α-CORTES

Existe una manera directa de pasar de conjuntos borrosos a conjuntos

clásicos mediante los llamados α -cortes. Dado un número ]1,0[∈α y un

conjunto borroso A , definimos el α -corte de A como el conjunto αA , cuya

función característica se define:

≥

=otro

xx

A

A0

)(1)(

αµϕ

α

Ecuación 3.36

En definitiva, el α -corte se compone de aquellos elementos cuyo grado de

pertenencia supera o iguala el umbral α .

Hablamos de α -cortes estrictos si:

>

=otro

xx

A

A0

)(1)(

αµϕ

α

Ecuación 3.37

Cualquier conjunto borroso A se puede representar mediante la unión

de sus α -cortes de la siguiente manera:

)]([max)(]1,0[

xx AA αϕαµ

α×=

∈

Ecuación 3.38

Los α -cortes son de especial utilidad en el estudio de propiedades

tales como la reflexividad, simetría y transitividad en conjuntos borrosos.


- 46 -

3.3 NÚMEROS BORROSOS

A. Kaufmann emplea el término “Subconjunto borroso” contra “Conjunto

borroso” (KAUF86) ya que siendo el referencial siempre un conjunto vulgar, es

decir tal y como se define intuitivamente en matemáticas modernas, o sea una

colección de objetos bien especificados y bien distintos, el subconjunto borroso

es subconjunto de este referencial.

Un caso particular y de especial interés de los conjuntos borrosos son

los llamados números borrosos. Surgen éstos como un intento de introducir

vaguedad en los números reales.

Un número borroso es un conjunto borroso A definido en la recta real

R y que cumple además las siguientes propiedades:

1. Es normal, o lo que es lo mismo, existe al menos un elemento x de

R tal que 1)( =xAµ .

2. Es convexo, lo cual quiere decir que

))(),(min())1((

,]1,0[

yxyx

Ryx

AAA µµδδµ

δ

≥−+

∈∀∈∀

Ecuación 3.39

Geométricamente esta propiedad quiere decir que todos los α -cortes de A

son intervalos cerrados en R . La función de pertenencia es creciente hasta

llegar al punto en que 1)( =xAµ y decreciente a partir de él.

3. La función de pertenencia es continua en intervalos.


- 47 -

4. El soporte de A es acotado.

Para este proyecto se van a usar únicamente los números borrosos

trapezoidales. Definidas ya las propiedades que ha de cumplir nos

dispondremos a conocer sus principales variantes.

Ilustración 3.7 – Número borroso trapezoidal

Llamaremos número borroso trapezoidal ),,,( dcbaA = a un número

borroso que cumple que dcba ≤≤≤ y que el grado de pertenencia de a y d

es siempre 0 y el de b y c es siempre 1. De este principio se pueden obtener

cuatro patrones diferentes:

Número (Escalar): en caso de que dcba === .

Número borroso lineal: en caso de que dcba =<= .

Número borroso piramidal (triangular): en caso de que dcba <=≤

ó dcba ≤=< .

Número borroso trapezoidal: en caso de que dcba <<≤ ó

dcba ≤<< .

El tratamiento a los números borrosos que se va a dar en el proyecto

se puede ver en el apartado 12.2.


- 48 -

4. PLANTEAMIENTO Y OBJETIVOS DEL PROYECTO

Después de analizar los contextos en los que se va a trabajar se

recuerda que como se vio en el capítulo dos, el método PERT es una técnica

fundamental para la planificación de proyectos especialmente en casos en que

las duraciones de las diferentes actividades de la red o son aleatorias o, siendo

de naturaleza determinista pero de tipo novedoso, su valor solo puede ser

estimado de forma vaga o imprecisa a través de la opinión de expertos en

actividades semejantes.

El modelo CPM expone el camino crítico de un proyecto a partir de una

serie de actividades con duraciones fijas bien conocidas.

Las actividades con duraciones que no son perfectamente conocidas

introducen aleatoriedad dentro del proyecto haciendo trabajosa la

determinación de la ruta crítica.

En un conjunto clásico definido sobre un intervalo U se asigna el valor

0 ó 1 a cada elemento del mismo para indicar la pertenencia o no a dicho

conjunto. Esta función puede generalizarse de forma que a cada elemento de U

se le asigne un valor del intervalo [0,1] que indique el grado de pertenencia de

ese elemento al conjunto en cuestión. A esta función se la llama “función de

pertenencia” y al conjunto que define se denomina “Conjunto Borroso”. Es

decir, en la lógica borrosa los elementos de un conjunto pertenecen con un

cierto grado al intervalo [0,1].


- 49 -

Mediante la estimación de la duración de las actividades con números

borrosos, se obtienen las ventajas que ellos proporcionan, como la aritmética.

Utilizando también la lógica borrosa se puede estimar cada duración por medio

de la desborrosificación y sus diferentes variantes para llegar a una solución

determinista.

4.1 PLANTEAMIENTO DEL PROYECTO

El proyecto se plantea como:

“Extender el algoritmo clásico del PERT-CPM basado en programación

dinámica, que permite estudiar una red de actividades, al caso en el que se

tiene un conocimiento vago de las duraciones de las diferentes actividades de

la red. Este conocimiento puede ser modelado mediante números borrosos

trapezoidales (y, como casos particulares, intervalos constantes y números

borrosos piramidales). Al modelo se le dará el adecuado tratamiento

informático”.

4.2 OBJETIVOS DEL PROYECTO

Por tanto el proyecto se define con los siguientes objetivos:

Modelar el comportamiento de las actividades según se ajusten a

unos determinados patrones como son: números borrosos

trapezoidales, piramidales o constantes.

Programar una aplicación que permita al usuario crear un

diagrama PRET/CMP en el que pueda establecer su propia red


- 50 -

de actividades y etapas del proyecto con sus correspondientes

duraciones: nítidas y borrosas.

Crear un motor de resolución del diagrama PERT/CMP que sea

capaz de calcular los caminos críticos a partir de actividades de

duración fija así como los márgenes libres y totales de cada

actividad y las fechas previstas y límites de las etapas del

proyecto.

Analizar el problema de las duraciones aleatorias derivado de los

números borrosos e integrarlo en el motor de resolución.

Al considerar algunas de las duraciones como borrosas, los

resultados vendrán dados en forma de número borroso, y por

tanto habrá que hacer una estimación de los resultados para

poder trabajar con ellos. Para ello se han elegido diferentes

métodos de desborrosificación que han de ser implementados y

ofrecidos al usuario para seleccionar.

Crear una arquitectura cliente-servidor de tal manera que el

usuario (cliente) sea capaz de diseñar su red y poder modificarla

o actualizarla en cualquier momento enviando así al motor de

resolución (servidor) las modificaciones y devolverle a éste los

resultados para que se le puedan presentar al usuario en la

aplicación cliente.


- 51 -

Presentar al usuario las actividades y etapas correspondientes al

camino crítico y las relaciones existentes entre ellas así como un

diagrama de Gantt que permita determinar fácilmente la ejecución

del proyecto desde su fecha de inicio.


- 52 -

5. SOLUCIÓN PROPUESTA

Se ha descrito cómo se estudia y modela un proyecto a partir de un

conjunto de actividades y cuáles son los principales problemas derivados de la

metodología utilizada. Ante esto, se propone un sistema de bajo coste, basado

en una aplicación interactiva capaz de permitir crear proyectos a partir de un

conjunto de actividades definidas y determinar la ruta o las rutas críticas que lo

forman.

Se trata de implementar un sistema de cálculo de duraciones basado

en la interacción con el usuario. Se presentarán una secuencia de formularios

al usuario que le permitan gestionar las actividades que componen el proyecto

(crearlas, añadirlas, modificarlas y borrarlas). El motor de resolución tiene la

función de construir el diagrama de red a partir de los atributos de las

actividades que compongan el proyecto y proponer la solución al problema en

función de la opción de solución que elija el usuario. Los atributos de las

actividades se transmiten por Internet hasta el motor de resolución donde

mediante algoritmos y técnicas de lógica borrosa se soluciona el proyecto.

En los puntos sucesivos se especifica el proceso seguido para la

elaboración de la aplicación utilizando la ingeniería del software.


- 53 -

6. DIAGRAMA DE CONTEXTO

En este diagrama se reflejan las relaciones que el sistema tiene con las

entidades externas con las que interacciona. Una entidad externa simboliza

cualquier otro sistema o elemento del entorno que interacciona con el sistema,

pero que está fuera de su alcance de definición.

Diagrama 6.1 – Diagrama de contexto del sistema

Se observa que el usuario interacciona con el sistema mediante la

aplicación cliente y que ésta a su vez se relaciona con el motor de resolución

para solucionar las peticiones que solicite el usuario.

El usuario interacciona con la aplicación cliente por medio del interfaz

gráfico de la aplicación y tanto el motor de resolución como la aplicación cliente

se comunican mediante un protocolo con conexión a nivel de aplicación.


- 54 -

7. PERFILES Y ÁMBITO

Un usuario sólo tiene un único perfil en la aplicación. El perfil se define

como “Usuario” que engloba lo siguiente:

- Usuario: Será la persona que podrá crear, modificar y eliminar

actividades para la red que representa el proyecto (y sus parámetros

básicos) así como salvar y guardar los datos y solicitar la solución al

servidor.

Se podría incluir el perfil de administrador del motor de resolución. El

perfil se definiría como “Administrador” y sería el encargado de iniciar el motor

de resolución y seleccionar el puerto de entrada de las conexiones al mismo.


- 55 -

8. ANÁLISIS 8.1 ANÁLISIS DE REQUISITOS

El objetivo de este apartado del Análisis es alcanzar un conocimiento

suficiente del sistema, definiendo las necesidades, problemas y requisitos del

usuario, para expresarlo posteriormente mediante los modelos de procesos y

de datos.

8.1.1 REQUISITOS FUNCIONALES

Modelar el problema: El modelado es la primera actividad que

debe llevar a cabo el sistema. Dicho modelado consiste en la

creación de un esquema de información basado en la información

inherente a las actividades: su identificador unívoco, su

descripción, sus actividades sucesoras y su duración.

Modelar el comportamiento de las duraciones borrosas: Su

objetivo es poder trabajar con ellas aritméticamente para poder

extender el método del camino crítico CPM y permitir darlas un

valor plausible mediante diferentes técnicas de desborrosificación.

Permitir la gestión del proyecto: Esta acción consiste en

ofrecer al usuario la creación de proyectos nuevos, incrementar y

eliminar las actividades que lo componen y modificarlas en

cualquier momento.

Permitir la conexión entre los subsistemas: Crear un protocolo

con conexión capaz de comunicar al cliente con el servidor de

manera síncrona y que permita enviarle la lista de actividades y


- 56 -

este le devuelva el diagrama PERT/CPM solucionado

dependiendo de la opción de solución elegida.

Ofrecer varias formas de solucionar el diagrama: Al trabajar

con números borrosos, se obtiene una mayor cantidad de los

mismos y su interpretación no resulta determinista, por ello se

incluyen varias formas de desborrosificación.

Generación del diagrama de red: Poder transformar un conjunto

de actividades con sus datos en un conjunto de actividades y

etapas consistente y fácilmente entendible por el usuario

siguiendo el modelo de diagrama de red.

Permitir el salvaguardado: Hacer posible en todo momento el

salvado de la información, tanto del proyecto solucionado como

someramente planteado, y poder cargarlo. Asimismo se permitirá

el salvaguardado de los gráficos mostrados.

8.1.2 REQUISITOS NO FUNCIONALES

Requisitos de calidad: La aplicación debe de responder a todos

los requisitos de calidad de la normativa ISO. Se hace especial

hincapié en la velocidad de respuesta, en el control de errores y

en la amigabilidad de la aplicación para el usuario.

Requisitos de interfaces externas: A continuación se describen

las interfaces externas que requiere el sistema con el usuario y


- 57 -

con otros sistemas, cuyos requisitos son importantes para el

correcto desarrollo y funcionamiento.

Interfaz de usuario: El objeto del interfaz de usuario es

establecer un medio interactivo por el que el usuario pueda

gestionar el conjunto de las actividades que compone el

proyecto y por otro ejecutar las funcionalidades de la

aplicación.

Interfaz de datos: El objeto del interfaz de datos es

establecer un medio interactivo por el que el usuario pueda

guardar y cargar el conjunto de las actividades que compone

el proyecto y los gráficos que genera.

Interfaz de conexión: El objeto del interfaz de conexión es

establecer protocolo por el que la aplicación cliente se

comunicará con el servidor de resolución a través de

Internet.

Requisitos de seguridad y control: Estos requisitos abarcan el

control de los valores de los datos que introduce el usuario, la

detección de bucles, y el mantenimiento de la consistencia de la

información.


- 58 -

8.2 ANÁLISIS FUNCIONAL DETALLADO

En este apartado se describe la funcionalidad detallada de la

aplicación, es decir, las acciones básicas que deberá realizar la aplicación para

obtener los objetivos necesarios.

Las funciones que debe realizar el sistema son las siguientes:

8.2.1 CREACIÓN DEL PROYECTO, INSERCIÓN, MODIFICACIÓN Y ELIMINACIÓN DE ACTIVIDADES

El sistema deberá permitir la gestión de estos conceptos

pertenecientes al sistema.

Para la creación de un proyecto el deberá introducir la fecha de inicio

del mismo y el numero de actividades que lo componen. Posteriormente el

sistema iniciará las actividades por defecto y le solicitará al usuario los datos

propios de cada actividad haciendo especial hincapié en el campo de las

duraciones de las actividades para que sean validadas. Tras terminar este

proceso se solicitará que designe las actividades sucesoras para cada una de

las generadas comprobando que no se formen bucles entre ellas.

Para la inserción de actividades en el sistema, el usuario deberá indicar

el número de actividades a insertar. Se inicializarán por defecto y se solicitará

al usuario los datos que la representan al igual que la información de la relación

de anterioridad que tienen con las actividades ya creadas. El sistema

mantendrá la consistencia de las ya creadas y de las actividades nuevas

especialmente en las duraciones y en las relaciones de sucesión.


- 59 -

En el caso de modificación de actividades en el sistema, el usuario

deberá interaccionar con los datos y relaciones ya creados, y el sistema

mantener la consistencia de las duraciones y las precedencias.

En la eliminación el sistema deberá controlar que un proyecto no pueda

tener un número menor de dos actividades y ofrecer nuevas relaciones si

existen entre las predecesoras de la actividad eliminada y sus sucesoras. Del

mismo modo se garantizará la consistencia de la información.

Todos los campos podrán ser modificados menos el código

identificador unívoco de cada actividad.

8.2.2 TRATAMIENTO DE LAS DURACIONES BORROSAS

Se modelará convenientemente el tratamiento de la aritmética borrosa

en las operaciones básica se suma y resta entre duraciones borrosas y de

duraciones borrosas con duraciones fijas para la fase hacia delante y la fase

hacia atrás del modelo CMP.

También se modelarán varias opciones de desborrosificación entre las

que se incluirán valoraciones optimistas y pesimistas de cada duración en

función de un α -corte introducido por el usuario y técnicas de

desborrosificación básicas y complejas como la media máxima, el centro de

área y la media borrosa para la parte PERT.

8.2.3 CREACIÓN DEL ALGORITMO DE SOLUCIÓN

El motor de resolución será capaz de recibir un conjunto de actividades

con la información introducida para el usuario y obtener el diagrama de red


- 60 -

equivalente más optimo de todos los posibles, creando los nodos o etapas de

la red y asignando las fechas de inicio y finalización de cada etapa y los

márgenes u holguras libres y totales de cada actividad. Se contemplará la

posibilidad de introducir actividades dummy (actividades de tiempo nulo) para

ceñirse al formato de diagrama de red. El conjunto de actividades y etapas esta

relacionado entre si consistentemente conociendo cada actividad su etapa de

inicio y fin y poder acceder a su información. Análogamente las etapas conocen

las actividades que acaban en ella y las que se inician en ella y pueden

acceder a su información.

Por otra parte se incluye el tratamiento de las duraciones borrosas y

funciones aritméticas básicas y de desborrosificación para las mismas.

8.2.4 PROTOCOLO DE CONEXIÓN

Se creará un protocolo con conexión a través del cual se comunique la

aplicación cliente con el servidor de resolución de manera que la aplicación

cliente se mantiene a la espera de la solución del servidor usando como

soporte Internet. El formato de los datos deberá ser consistente con el

protocolo tanto para el envió como para la recepción de información.

El cliente deberá conocer la dirección IP del servidor y el puerto de

entrada. El comportamiento del servidor se modelará con un socket multihilo

capaz de procesar varias peticiones a la vez manteniendo la integridad de los

datos y enviándolos de nuevo al cliente que envió la petición de resolución.


- 61 -

8.2.5 PRESENTACIÓN DE LOS DATOS

Cuando exista un proyecto en la aplicación, toda información

susceptible de ser mostrada se representará fácilmente mediante tablas no

editables en los siguientes conjuntos: Actividades, Actividades ficticias (dummy)

y Etapas. La tabla de etapas se mostrará en caso de que esté solucionado el

diagrama y la tabla de actividades dummy en caso de que esté solucionado el

diagrama y de que existan.

Los informes de cada unidad deberán ser mostrados de forma

ordenada, de mayor a menor identificador en el caso de las actividades y

actividades nuevas, y en orden cronológico el de las etapas.

Como se explicó anteriormente la aplicación genera informes cuyo

resultado son los datos previstos, es decir, los datos que se esperan obtener en

el futuro. Estos datos deben aproximarse lo más posible a los datos reales, que

son aquellos que efectivamente se obtienen en la realidad.

8.2.6 PRESENTACIÓN DE LOS GRÁFICOS

Los gráficos de apoyo al programa se generarán para representar un

proyecto solucionado mediante un diagrama de Gantt con la fecha de inicio del

proyecto como inicio del mismo. En caso de que la solución (fecha fin del

proyecto) sea una duración borrosa se mostrará por pantalla. Como ayuda a la

creación de las duraciones borrosas, éstas se representarán en forma gráfica.

En cualquier caso los gráficos serán susceptibles de ser guardados en

un formato de imagen o impresos.


- 62 -

8.2.7 ALMACENAMIENTO DE LOS DATOS

Todos los datos, tanto los generados como los introducidos deberán

ser almacenados en el sistema. Estarán almacenados en ficheros.

Todos los informes serán almacenados automáticamente por el

sistema en el momento posterior a su generación o a su modificación por parte

del usuario.

Se proporcionará un proceso de guardado de datos al iniciar

operaciones que puedan variar o eliminar los datos existentes y al salir de la

aplicación.

Los datos se guardarán y cargarán de ficheros con extensión pert.

Dichos ficheros tendrán un formato determinado único, legible e interpretable

por la aplicación.

8.2.8 MODIFICACIÓN DE PARÁMETROS DEL PROYECTO Y DEL PROGRAMA

Se proporcionará la opción de cambiar la fecha de inicio del proyecto

tanto si es anterior a la actual como si se necesita posponerla. Análogamente la

configuración de conexión al servidor se proporcionará en un formulario que

contenga un campo para la dirección IP del servidor y el puerto de entrada al

mismo.


- 63 -

9. ESTUDIO DE LA ARQUITECTURA

A la hora de elegir la plataforma más conveniente para la explotación

del Sistema se han valorado una serie de factores:

- El volumen de información a almacenar

- Necesidades planteadas en el análisis

- Disponibilidad de herramientas software

- Facilidad de tratamiento y acceso a la información

Dichos factores han llevado a elegir un sistema cliente-servidor, con las

siguientes características:

9.1 EL LENGUAJE JAVA

Java es un lenguaje de programación orientado a objetos desarrollado

por Sun Microsystems. Las aplicaciones Java están típicamente compiladas en

un bytecode, aunque la compilación en código máquina nativo también es

posible. En el tiempo de ejecución, el bytecode es normalmente interpretado o

compilado a código nativo para la ejecución, aunque la ejecución directa por

hardware del bytecode por un procesador Java también es posible.

El lenguaje en sí mismo toma mucha de su sintaxis de C y C++, pero

tiene un modelo de objetos más simple y elimina herramientas de bajo nivel

como punteros.

Sun Microsystems proporciona una implementación GNU General

Public License de un compilador Java y una máquina virtual Java, conforme a


- 64 -

las especificaciones del Java Community Process, aunque la biblioteca de

clases que se requiere para ejecutar los programas Java no es software libre.

Entre noviembre de 2006 y mayo de 2007, Sun Microsystems liberó la

mayor parte de sus tecnologías Java bajo la licencia GNU GPL, de acuerdo con

las especificaciones del Java Community Process, de tal forma que

prácticamente todo el Java de Sun es ahora software libre.

El lenguaje de programación Java ha sido totalmente mejorado,

ampliado y probado por una comunidad activa de unos cuatro millones de

desarrolladores de software.

Se ha escogido Java para la realización del proyecto porque la

tecnología Java es una tecnología madura, extremadamente eficaz y

sorprendentemente versátil, se ha convertido en un recurso inestimable ya que

permite a los desarrolladores:

• Desarrollar software en una plataforma y ejecutarlo en

prácticamente cualquier otra plataforma.

• Crear programas para que funcionen en un navegador Web y en

servicios Web.

• Diseñar aplicaciones con interfaz grafico para el usuario con todos

los componentes necesarios y su fácil gestión de eventos.

• Desarrollar aplicaciones para servidores como foros en línea,

tiendas, encuestas, procesamiento de formularios HTML, etc.


- 65 -

• Combinar aplicaciones o servicios basados en la tecnología Java

para crear servicios o aplicaciones totalmente personalizados.

• Desarrollar potentes y eficientes aplicaciones para teléfonos

móviles, procesadores remotos, productos de consumo de bajo

coste y prácticamente cualquier dispositivo digital.

• Tener gran versatilidad en sistemas para aplicaciones con

conexión.

9.2 ESTRUCTURA DEL SISTEMA

Hardware: Ordenador con

Intel Pentium a 2.4 GHz

Memoria RAM de 512 MB

Conexión a Internet de 5Mbps

Software:

Sistema operativo Windows/Linux

Versión Java: Java Runtime Environment Version 6 Update 2

Plataforma de desarrollo Eclipse.

Software conseguido:

Aplicación capaz de mostrar la programación de un proyecto

mediante el uso de la lógica borrosa.


- 66 -

Servidor de resolución multihilo a través de Internet.

Amos en formato autoejecutable JAR.


- 67 -

10. DISEÑO DE LA APLICACIÓN

Se va a optar por un diseño de la aplicación en dos fases a nivel

conceptual del funcionamiento de la aplicación. Por un lado tenemos el

programa que se presenta al usuario y con el que éste interactúa, y por otro el

motor de resolución que es el encargado de procesar la información. La

siguiente representa el primer nivel conceptual del funcionamiento de la

aplicación:

Diagrama 10.1 – Diagrama de contexto del sistema

En este primer nivel la aplicación queda dividida en dos sistemas:

1. Aplicación cliente: Adquisición de información a través del interfaz

grafico del usuario así como su edición y el guardado y recuperación de los

datos desde disco. Garantizando la corrección y consistencia de la información

introducida para enviarla al motor de resolución a través de la red con el

protocolo diseñado así como su recepción y mostrar los resultados obtenidos

por pantalla.

2. Motor de resolución: Análisis del conjunto de las actividades del

proyecto y su distribución en un diagrama de red. Cálculos de resolución

dependiendo de la opción seleccionada. Recepción y transmisión de los datos

por el protocolo diseñado a través de la red.


- 68 -

10.1 MODELO DE DOMINIO

El modelo de dominio diseñado para la aplicación desarrollada es el

siguiente:

Diagrama 10.2 – Modelo de dominio del sistema

Como se puede observar en la figura superior la complejidad del

problema reside en lo que llamaremos PertCpm y sus relaciones. Se han

representado los atributos de todos los componentes del proyecto y sus


- 69 -

relaciones entre los mismos. La aplicación cliente y el motor de resolución

dependen del PertCpm para poder funcionar.

10.2 MODELO DE DATOS

El objetivo de este apartado es realizar una representación lógica de la

información que maneja el sistema. Por lo tanto este modelo se realiza para

especificar los datos que se manejan y las relaciones entre ellos se han

mostrado en el modelo de dominio.

Existirán tres tablas de datos como máximo en la aplicación. No se

usan bases de datos pero la información se mantiene en un estado conforme

mediante el objeto PertCpm. En él se ha visto que contiene tres listas: la de

actividades, la de actividades ficticias o dummy y la de etapas. Cada uno de los

componentes de esta lista está en la región de memoria asociada al PertCpm.

Todas las relaciones que existen entre ellas están establecidas mediante

punteros a sus datos asociados. Es decir, la actividad C ocupa un lugar en

memoria y es apuntada por las actividades que la precedan, y por las que la

sucedan al igual que su etapa inicial y final, reduciendo así el tamaño de los

datos en memoria.

El fichero de los datos en que se guarda la información, aparte de otros

parámetros de configuración, guarda el PertCpm como una totalidad

beneficiándose de las ventajas apuntadas en el párrafo anterior.

10.2.1 TABLA DE ACTIVIDADES

La tabla de actividades se muestra durante toda la ejecución del

programa. Sus campos son:


- 70 -

Ilustración 10.1 – Tabla de actividades con información básica

Id: Es el identificador unívoco de cada actividad asignado por la

aplicación cliente. Es lo que se conoce como campo clave en una

base de datos. Es una cadena de caracteres ascendentes que

empieza en A, al llegar a Z pasa a AA y así sucesivamente. No

puede ser nulo.

Nombre: Es la descripción de la actividad. Es una cadena de

caracteres y puede tener valor nulo.

Duración: Es la representación de la duración de la actividad en

forma de cadena de caracteres. Ninguna duración será negativa.

Puede tomar cuatro formas diferentes:

Conocida (escalar): Es el número decimal que la

representa.

Borrosa constante: Representada por Lin(A,B) siendo A y

B las duraciones conocidas que la representan.

Borrosa piramidal: Representada por Pir(a,B,b) siendo a, B

y b las duraciones conocidas que la definen.


- 71 -

Borrosa trapezoidal: Representada por Tra(a,A,B,b) siendo

a, A, B y b las duraciones conocidas que la representan.

Actividades Anteriores: Es el conjunto de actividades

inmediatamente anteriores asociadas por punteros representado

por una cadena de caracteres. En caso de ser nulo se declara

como “ninguna”.

Actividades Siguientes: Es el conjunto de actividades

inmediatamente posteriores asociadas por punteros representado

por una cadena de caracteres. En caso de ser nulo se declara

como “ninguna”.

Ilustración 10.2 – Tabla de actividades con información completa

Etapa Inicial: Es la etapa de la que parte la actividad (en la que

se inicia). Está representada por un número entero mayor que

cero. Puede tener valor nulo si el diagrama no esta solucionado y

se representa por una cadena de caracteres vacía.

Etapa Final: Es la etapa a la que llega la actividad (en la que se

termina). Está representada por un número entero mayor que


- 72 -

cero. Puede tener valor nulo si el diagrama no esta solucionado y

se representa por una cadena de caracteres vacía.

Margen Libre: Es la representación del margen libre de la

actividad en forma de cadena de caracteres. Ninguna duración

será negativa. Puede tener valor nulo si el diagrama no esta

solucionado y toma cualquiera de las cuatro formas diferentes

descritas en el campo duración.

Margen Total: Es la representación del margen total de la

actividad en forma de cadena de caracteres. Ninguna duración

será negativa. Puede tener valor nulo si el diagrama no esta

solucionado y toma cualquiera de las cuatro formas diferentes

descritas en el campo duración.

Como se ve en la ilustración superior se enfatiza el camino crítico con

color rojo.

10.2.2 TABLA DE ETAPAS

La tabla de etapas se muestra una vez que se haya solucionado el

diagrama de red.

Sus campos son:

Id: Es el identificador unívoco de cada etapa asignado por el

motor de resolución. Es lo que se conoce como campo clave en

una base de datos. Es un entero ascendentes que empieza en 1.

No puede ser nulo.


- 73 -

Fecha Prevista: Es la representación de la fecha prevista de la

etapa en forma de cadena de caracteres. Ninguna duración será

negativa. No puede tener valor nulo y toma cualquiera de las

cuatro formas diferentes descritas en el campo duración.

Fecha Límite: Es la representación de la fecha límite de la etapa

en forma de cadena de caracteres. Ninguna duración será

negativa. No puede tener valor nulo y toma cualquiera de las

cuatro formas diferentes descritas en el campo duración.

Actividades Anteriores: Es el conjunto de actividades que llegan

a la etapa representado por una cadena de caracteres. En caso

de ser nulo se declara como “ninguna”, únicamente se da en el

caso de la etapa inicial del proyecto.

Actividades Siguientes: Es el conjunto de actividades que salen

a la etapa representado por una cadena de caracteres. En caso

de ser nulo se declara como “ninguna”, únicamente se da en el

caso de la etapa final del proyecto.

Ilustración 10.3 – Tabla de etapas


- 74 -

Como se ve en la ilustración superior se enfatiza el camino crítico con

color rojo.

10.2.3 TABLA DE ACTIVIDADES FICTICIAS

La tabla de actividades ficticias (dummy) se muestra una vez que se

haya solucionado el diagrama de red y si éste las contiene. Se recuerda que es

una actividad creada con tiempo nulo para respetar las obligaciones de

representación del diagrama de red. Por tanto no tiene relevancia darlas un

nombre, ni una duración ni, consecuentemente, valor a los márgenes.

Ilustración 10.4 – Tabla de actividades dummy

Id: Es el identificador unívoco de cada actividad asignado por el

motor de resolución. Es lo que se conoce como campo clave en

una base de datos. Es un entero ascendentes que empieza en 0.

No puede ser nulo.

Actividades Anteriores: Es un conjunto de actividades

inmediatamente anteriores representadas por una cadena de

caracteres. No puede ser nulo.

Actividades Siguientes: Es un conjunto de actividades

inmediatamente posteriores representadas por una cadena de

caracteres. No puede ser nulo.


- 75 -

Etapa Inicial: Es la etapa de la que parte la actividad (en la que

se inicia). Está representada por un número entero mayor que

cero. No puede ser nulo.

Etapa Final: Es la etapa a la que llega la actividad (en la que se

termina). Está representada por un número entero mayor que

cero. No puede ser nulo.

10.3 MODELO DE CASOS DE USO

El modelo de casos de uso permite recoger y documentar los

requerimientos y funcionalidades del sistema. Se compone de la identificación

de los casos de uso, los diagramas de casos de uso y la descripción detallada

de los mismos.

10.3.1 IDENTIFICACIÓN DE LOS CASOS DE USO

Los casos de uso más destacados de la aplicación se citan a

continuación:

CU01: Creación de un nuevo proyecto.

CU02: Definir los parámetros del proyecto.

CU03: Inicializar las actividades.

CU04: Crear relaciones temporales entre las actividades.

CU05: Insertar actividades nuevas.

CU06: Modificar actividades.


- 76 -

CU07: Eliminar actividades.

CU08: Solucionar el diagrama.

CU09: Enviar la información al servidor y recibirla.

CU10: Mostrar la información.

CU11: Guardar la información en un archivo.

CU12: Cargar la información de un archivo.

CU13: Modificar la configuración de conexión con el servidor.

CU14: Edición de duración borrosa.

10.3.2 DIAGRAMA DE CASOS DE USO

El diagrama de casos de uso es el siguiente:


- 77 -

Diagrama 10.3 – Casos de uso del sistema


- 78 -

10.3.3 DESCRIPCIÓN DE LOS CASOS DE USO

A continuación se describen los casos de uso más importantes

identificados con anterioridad:

Identificador CU01

Nombre Creación de un nuevo proyecto

Actor Primario Usuario

Actores Secundarios -

Trigger Selección del usuario en el menú

Precondiciones -

Escenario primario

1- El sistema pregunta al usuario si quiere guardar los datos existentes.

2- El sistema inicia el proceso de definición de los parámetros del proyecto.

3- El sistema muestra los datos introducidos por el usuario.

Extensiones

1.1- No existen datos para guardar.

Se inicia el caso de uso en 2

2.1- El usuario cancela el proceso

Finaliza el caso de uso

Descripción de datos

Información de la actividad:

Identificador

Descripción

Duración

Actividades anteriores

Actividades siguientes

Casos de uso relacionados CU02, CU10, CU11


- 79 -

Identificador CU02

Nombre Definir los parámetros del proyecto



Trigger Selección del usuario

Precondiciones El usuario ha seleccionado previamente la opción de crear nuevo proyecto

Escenario primario

1- El sistema pregunta al usuario la fecha de inicio del proyecto.

2- El sistema pregunta al usuario el número de actividades del proyecto.

3- El sistema inicia el proceso de inicialización de las actividades.

Extensiones

1.1- Cancelación del usuario


2.1- Cancelación del usuario



Información del proyecto:

Fecha de inicio

Numero de actividades del proyecto

Casos de uso relacionados

CU01, CU03


- 80 -

Identificador CU03

Nombre Inicializar las actividades




Precondiciones El usuario ha introducido los datos del proyecto

Escenario primario

1- El sistema inicializa las actividades por defecto.

2- El usuario introduce los datos de las actividades.

3- El sistema inicia el proceso de creación de relaciones temporales entre las actividades.

Extensiones 2.1- El usuario introduce datos no válidos

El sistema advierte al usuario para que corrija los datos erróneos



Identificador

Descripción

Duración

Casos de uso relacionados CU02, CU04, CU05, CU06, CU14


- 81 -

Identificador CU04

Nombre Crear relaciones temporales entre las actividades




Precondiciones El usuario ha introducido los datos de las actividades

Escenario primario

1- El usuario introduce las relaciones temporales entre las actividades.

2- Se devuelve el control al caso de uso que lo invocó.

Extensiones -






CU01, CU03, CU05, CU06, CU07, CU10


- 82 -

Identificador CU05

Nombre Insertar actividades nuevas




Precondiciones -

Escenario primario

1- El sistema pregunta al usuario el número de actividades a añadir al proyecto.

2- El sistema inicia el proceso de inicialización de las actividades.

3- El sistema muestra los datos introducidos por el usuario.

Extensiones 1.1- El usuario cancela el proceso




Identificador

Descripción

Duración




CU03, CU10, C11


- 83 -

Identificador CU06

Nombre Modificar actividades




Precondiciones -

Escenario primario


2- El sistema inicia el proceso de modificación de las actividades.

3- El sistema muestra los datos modificados por el usuario.

Extensiones



2.1- El usuario introduce datos no válidos






Identificador

Descripción

Duración




CU03, CU04, CU10, C11, CU14


- 84 -

Identificador CU07

Nombre Eliminar actividades




Precondiciones El numero de actividades debe ser mayor que dos

Escenario primario


2- El sistema inicia el proceso de eliminación de las actividades.

3- El sistema muestra los datos restantes.

Extensiones



2.1- El usuario intenta eliminar más actividades de las permitidas

El advierte al usuario

2.2- El sistema encuentra nuevas relaciones

Se muestra al usuario





Identificador




Numero de actividades del proyecto

Casos de uso relacionados CU04, CU10, C11


- 85 -

Identificador CU08

Nombre Solucionar el diagrama



Trigger Inicio de la conexión del usuario

Precondiciones -

Escenario primario

1- El sistema recibe las actividades del cliente.

2- El sistema construye el diagrama de red.

3- El sistema rellena los datos mediante cálculos.

4- El sistema envía la solución del proyecto al cliente.

Extensiones

1.1- Se produce un error de conexión.






Duración, Actividades anteriores y siguientes, Etapa Inicial y Final, Margen Libre y Total

Información de la etapa:

Identificador, Actividades anteriores y siguientes, Fecha Prevista y Límite

Información de la actividad nueva:

Identificador, Actividades anteriores y siguientes, Etapa Inicial y Final


Actividades y Actividades nuevas del proyecto

Etapas del proyecto

Casos de uso relacionados CU04, CU05, CU09, CU14


- 86 -

Identificador CU09

Nombre Enviar la información al servidor y recibirla




Precondiciones El servidor debe estar ejecutándose.

Escenario primario

1- El sistema inicia el proceso de solución del proyecto.

2- El sistema inicia la conexión con el servidor.

3- El sistema envía las actividades al servidor.

4- El sistema recibe la solución del proyecto del servidor.

5- El sistema muestra los datos de la solución.

Extensiones


El sistema advierte al usuario del error producido




Id, Descripción, Duración, Actividades anteriores y siguientes, Etapa Inicial y Final, Margen Libre y Total







Etapas del proyecto

Casos de uso relacionados CU08, CU10, CU12


- 87 -

Identificador CU10

Nombre Mostrar la información




Precondiciones -

Escenario primario

1- Se muestran la información de las actividades.

2- Se muestran la información de las etapas.

3- Se muestra el diagrama de Gantt.

4- Se muestran la información de las actividades nuevas.

Extensiones

2.1- No existen etapas.


4.1- No existen actividades nuevas.











Etapas del proyecto

Casos de uso relacionados CU01, CU05, CU06, CU07, CU14


- 88 -

Identificador CU11

Nombre Guardar la información en un archivo



Trigger Selección del usuario directamente o indirectamente

Precondiciones -

Escenario primario

1- El sistema muestra las opciones de guardado.

2- El sistema guarda la información en un fichero.

Extensiones



2.1- Se produce un error de entrada/salida.












Etapas del proyecto


CU01, CU05, CU06, CU07, CU13


- 89 -

Identificador CU12

Nombre Cargar la información de un archivo




Precondiciones -

Escenario primario

1- El sistema carga la información de un fichero.

2- Se muestra la información

Extensiones















Etapas del proyecto


CU13


- 90 -

Identificador CU13

Nombre Modificar la configuración de conexión con el servidor




Precondiciones -

Escenario primario

1- El sistema carga la información del fichero.

2- El usuario introduce los parámetros de conexión.

3- El sistema guarda la información en el fichero.

Extensiones












Información de la conexión:

Dirección IP

Puerto de entrada al servidor


CU09, CU11, CU12


- 91 -

Identificador CU14

Nombre Edición de duración borrosa




Precondiciones -

Escenario primario

1- El sistema carga la información de la duración.

2- El usuario introduce los parámetros de la duración.

3- El sistema actualiza la información de la duración.

Extensiones

1.1- No existe información anterior








Duración

Casos de uso relacionados CU03, CU06, CU08, CU10


- 92 -

10.4 DIAGRAMA DE PAQUETES

El diagrama de paquetes de los cuales consta el proyecto es el

siguiente:

Diagrama 10.4 - Paquetes del sistema

10.4.1 PACKAGE MOTOR

Diagrama 10.5 – Paquete motor


- 93 -

10.4.2 PACKAGE CLIENTE

Diagrama 10.6 – Paquete cliente

10.4.3 PACKAGE ORG

Diagrama 10.7 – Paquete org


- 94 -

10.4.4 PACKAGE COMMON

Diagrama 10.8 – Paquete common


- 95 -

10.5 DIAGRAMA DFD DE PRIMER NIVEL DE LA APLICACIÓN CLIENTE

Diagrama 10.9 – DFD de primer nivel de la aplicación cliente

Se puede ver en el diagrama DFD de primer nivel las funcionalidades

de la aplicación cliente y sus flujos de datos. Se observa que el sistema

interacciona con el usuario (pantalla, ratón y teclado), con el disco y con la red.

Mediante el teclado el usuario introducirá los datos de entrada, con el ratón

seleccionará las funciones a llevar a cabo y en la pantalla podrá ver los

resultados del trabajo realizado. En el apartado 12 se detallarán cada una de

las funcionalidades internas de los cuatro módulos de los cuales se compone.


- 96 -

10.6 DIAGRAMA STATECHART DEL SERVIDOR DE RESOLUCIÓN

Diagrama 10.10 – Statechart del servidor de resolución

En un diagrama statechart se representan los estados en que se

encuentra un sistema y los eventos que los cambian. Se representa en el

diagrama el subsistema del motor de resolución que consta de dos módulos en

paralelo (1 y 2). El gestor de peticiones arranca el sistema y crea hilos de

ejecución de motores de resolución para servir las peticiones que realicen los

diferentes clientes. El motor de resolución soluciona el proyecto pasando por

sus seis estados donde acaba devolviendo la información resuelta y

terminando su ejecución.

Se detallará el funcionamiento de los dos módulos en el capítulo 13.


- 97 -

11. LA APLICACIÓN CLIENTE

Este subsistema es el encargado de arrancar el interfaz (a través del

cual el usuario va a operar con los proyectos) y permitir la conexión con el

servidor. Es de relevante importancia garantizar el salvaguardado de datos en

todo momento. Es un archivo JAR que se inicia mediante un doble clic de

ratón. El subsistema se divide a su vez en cuatro módulos: diseño y edición del

proyecto, comunicaciones, gestión de archivos, presentación de la información.

En cada uno de los módulos se especifican los casos de uso que solucionan.

11.1 DISEÑO Y EDICIÓN DEL PROYECTO

11.1.1 CREACIÓN DE UN NUEVO PROYECTO (CU01)

Ilustración 11.1 – Aspecto de la aplicación cliente al arrancar


- 98 -

En la figura superior se puede observar el inicio de la aplicación que se

inicia maximizada en primer plano. A partir de la cual se puede comenzar a

diseñar un proyecto mediante la selección en la barra de menú de

Archivo/Nuevo proyecto o Ctrl+N.

11.1.2 DEFINIR LOS PARÁMETROS DEL PROYECTO (CU02)

Ilustración 11.2 – Menú de apertura de archivo

Al accionar el AccionListener que gestiona los eventos de selección o

presionar Ctrl+N se inicia el submódulo Parámetros del Proyecto que es una

serie de dos objetos que hereda de JDialog y son modales (se instaura en

primer plano y no permite al usuario la interacción con el resto del programa

hasta que finalice su ejecución), por lo tanto retienen el foco. Al activar esta

serie de diálogos se presentarán las siguientes ventanas requiriendo

información por parte del usuario.


- 99 -

Ilustración 11.3 – Calendario de selección de fecha de inicio del proyecto

En la figura superior se requiere la selección de la fecha de inicio del

proyecto y presionar Aceptar o Enter. Si se cierra esta ventana o se presiona

cancelar se acabará la ejecución del submódulo Parámetros del Proyecto. El

siguiente paso es preguntar al usuario en otro diálogo el número de actividades

del que consta el proyecto.

Ilustración 11.4 – Inserción de numero de actividades del proyecto

Se presenta en esta ventana un JSpinner de actividades con un

SpinModel que va de 2 a infinito incrementándose en números enteros (ya que

se considera como proyecto a un conjunto de actividades mayor o igual que


- 100 -

dos). Por el contrario si se cierra esta ventana o se presiona cancelar se

acabará la ejecución del submódulo Parámetros del Proyecto y se vuelve a la

pantalla de inicio.

A partir de aquí se inicia un objeto que hereda de JDialog y que se

denomina Iniciador de actividades.

11.1.3 INICIADOR DE ACTIVIDADES (CU03)

En él se muestra al usuario los datos referentes a cada actividad en un

formulario dentro de una ventana JDialog también modal y no cerrable.

Ilustración 11.5 – Formulario de inicialización de las actividades

Los datos de que se compone una actividad son los que se muestran:

Identificador de la actividad: Se asigna mediante un algoritmo de

obtención de identificador al que se le pasa un número entero. Es

un campo no editable.

Nombre de la actividad: En él se puede escribir la descripción de

la misma para un mejor seguimiento.

Duración de la actividad: En este caso, y como ya se ha expuesto

anteriormente. Existen dos tipos de duraciones con las que el


- 101 -

programa trabaja: las fijas o conocidas y las borrosas. Por ello el

usuario elige la que desee mediante un JButtonGroup compuesto

por dos JRadioButton mutuamente excluyentes.

Para introducir una duración fija se escribe el número de días que

abarca. En este campo no se permite el uso de caracteres alfanuméricos ni

especiales, únicamente el uso de números y de un carácter “.” para decimales.

Esto es gestionado por el KeyAdapter del JTextField.

Las actividades se inicializan por defecto con la duración fija de un día.

Para introducir una duración borrosa se selecciona el radio destinado al

efecto dando la posibilidad de crearla apretando el botón “Nueva…”.

Ilustración 11.6 – Selección de duración borrosa

Al apretarlo se pasa el control del programa al Creador de duraciones

borrosas que también extiende de la clase JDialog que se detallará en

sucesivos apartados. Tras definir la duración borrosa se da la opción de

modificarla si se necesitara con el botón “Cambiar”.


- 102 -

Ilustración 11.7 – Representación de una duración borrosa

Una vez escogida una duración válida el programa permite moverse a

la siguiente actividad con el botón siguiente.

Ilustración 11.8 - Selección de duración conocida

En todo momento se puede avanzar y retroceder por las actividades

con el objeto de cambiarlas. El botón “Anterior” estará inactivo para la primera

actividad y el botón siguiente se transformará en “Finalizar” en la última donde

se cerrará la ventana y se pasará a la etapa siguiente: Iniciador de Sucesoras.

Si en algún momento se produjera un error en los datos debido a que el

usuario ha dejado vacío el campo de duración de una actividad se mostrará por

pantalla el siguiente error si se trata de una duración fija


- 103 -

Ilustración 11.9 – Error causado en los parámetros de la duración fija

o si se trata de una duración borrosa que no se ha creado aún y está

seleccionado su JRadioButton

Ilustración 11.10 – Error causado en los parámetros de la duración borrosa

ambos devuelven el foco al JtextField y al botón crear respectivamente.

11.1.4 CREADOR DE DURACIONES BORROSAS (CU14)

El creador de duraciones borrosas es un objeto que hereda de JDialog

y es modal y cerrable. Presenta el siguiente aspecto al crear una duración

borrosa nueva para una actividad.


- 104 -

Ilustración 11.11 – Formulario presentado para la creación de una duración borrosa nueva

Está compuesto de tres JRadioButton para elegir entre los tres tipos de

duraciones borrosas (intervalo lineal, piramidal y trapezoidal). Dependiendo de

la opción seleccionada se habilitan o deshabilitan los campos de los

parámetros para definir la duración borrosa. En dichos campos se controla el

input del teclado mediante el KeyAdapter permitiendo únicamente números y

un carácter “.”.

Cuando se presiona el botón de previsualizar y los datos son correctos

se muestra un gráfico con el eje de abcisas representando la duración en días

y el de ordenadas representando la probabilidad de cada uno de los puntos de

la duración borrosa. Asimismo se habilita el botón de listo para dejar definida la

duración borrosa.

En cualquier momento el usuario puede limpiar los parámetros con el

botón destinado al efecto, borrando el contenido de los JTextField y de la

gráfica. También se puede salir cerrando la ventana o presionando el botón

cancelar.


- 105 -

Para que el botón de listo esté activo tiene que haberse definido

completamente la duración habiéndola previsualizado y siendo los datos

consistentes. En caso contrario se mostrará un mensaje de error al usuario

indicándole el motivo y poniendo el foco en el campo que lo haya producido.

Como ejemplo se muestra la figura siguiente:

Ilustración 11.12 – Error en la lógica de los datos

Ilustración 11.13 – Error de tipo de duración escogida

El usuario es advertido en el caso de que esté intentando crear una duración

borrosa de un tipo en otro tipo, como por ejemplo una lineal en la de tipo

trapezoidal.

A continuación se muestran diferentes ejemplos de las duraciones

soportadas por la aplicación que, como puede verse son números borrosos

(subconjuntos borrosos convexos y normales atendiendo a las definiciones de

del apartado de lógica borrosa).


- 106 -

Ilustración 11.14 – Clases de duración borrosa de intervalo constante

Ilustración 11.15 – Clases de duración borrosa piramidales

Ilustración 11.16 – Clases de duración borrosa trapezoidales

Para representar los datos en una gráfica se envía un mensaje a una

clase llamada GraficaBoorsa conteniendo un vector con vectores de pares de

datos y mediante la cual se actualiza el panel en tiempo de ejecución mediante

el comando super.validate().

En caso de que se intente modificar una duración borrosa desde el iniciador de

actividades o el modificador de actividades se pasa al constructor del creador


- 107 -

de duraciones borrosas los parámetros de la duración creada anteriormente

para su edición pudiendo cancelarla en cualquier momento sin variar la original.

11.1.5 INICIADOR DE SUCESORAS (CU04)

Este submódulo se encarga de definir las actividades sucesoras de

cada actividad con el objeto de poder crear el diagrama de red.

Se compone de un conjunto de n JRadioButton (mutuamente

excluyentes) y un conjunto de n JCheckBox (de múltiple selección) siendo n el

número de actividades del proyecto.

Ilustración 11.17 – Iniciador de actividades sucesoras

Esta clase (que hereda de JDialog y es modal y no cerrable) muestra el

identificador de cada actividad con su descripción entre paréntesis y guarda en

todo momento las opciones marcadas. Si la lista de actividades no entra en la

pantalla se activa un JScrollPane activando una barra vertical para poder

mostrarlas.


- 108 -

Ilustración 11.18 – Activación del JScrollPane

Asimismo contiene un algoritmo de detección de bucles que se encarga

de impedir su construcción.

Los bucles no están permitidos en los diagramas de red debido a que si

se produjeran nunca se podría llegar a determinar la fecha de finalización del

proyecto porque las etapas y actividades implicadas nunca pararían de

calcularse.

Por tanto se han analizado las posibilidades de crearlos. Ello se ha

solucionado deshabilitando los JCheckBoxs de la columna “Actividades

sucesoras” que crearían un bucle cuando una actividad concreta está

seleccionada en la columna “Actividad actual”.

Se muestra un ejemplo en la figura siguiente:


- 109 -

Ilustración 11.19 – Ejemplo de funcionamiento del algoritmo

Las condiciones que hacen que se forme un bucle en el diagrama son:

La actividad i no puede tenerse de sucesora a sí misma.

Diagrama 11.1 – Bucle sobre la misma actividad

Si la actividad i ha marcado a la actividad j como siguiente,

ninguna de las actividades que precedan a i en toda la red (tanto

si son inmediatas como si no) podrán ser sucesoras de j

incluyendo a la actividad i. En otras palabras, todo camino desde

cualquier actividad sin actividades anteriores (actividad que saldrá

de la etapa inicial) hasta la actividad i no podrá suceder a j

incluyendo a la actividad i.


- 110 -

Diagrama 11.2 - Bucle sobre diferentes actividades

Si la actividad i ha marcado a la actividad j como siguiente,

ninguna de las actividades siguientes inmediatas de todas las

actividades anteriores de i podrá suceder a la actividad j.

En el supuesto de que la actividad i tenga de sucesoras a j y k la

actividad j no podrá suceder a k ni k a j debido a que se estaría

intentando encadenarlas de la forma kji ⇒⇒ o jki ⇒⇒

respectivamente.

Al terminar de rellenar el formulario se presiona terminar y se pasa a la

aplicación principal un array de objetos de la clase actividad para mostrar en

forma de tabla los datos recogidos.

Ilustración 16 – Presentación de la información básica de las actividades


- 111 -

A partir de este momento todas las opciones del la barra de menú se

desbloquean para poder ser utilizadas.

11.1.6 AÑADIR ACTIVIDADES AL PROYECTO (CU05)

Una vez terminada la fase de creación de actividades, se habilitan las

funcionalidades de inserción, modificación y eliminación de actividades.

En la aplicación se ofrece la opción de añadir una sola actividad o

añadir varias al proyecto, ambas en el menú Insertar de la barra de menú.

Ilustración 11.20 – Menú de inserción de actividades

En funcionalidad son equivalentes entre sí y equivalentes con el

Iniciador de Actividades. En este caso el identificador se genera a partir del

número de las actividades que existen antes de seleccionar la opción de

añadir.

Ilustración 11.21 – Inserción de una actividad


- 112 -

El proceso es idéntico para iniciar las actividades y con la misma

funcionalidad, terminando con una ventana de iniciación de sucesoras que

recoge todas las actividades del proyecto y las recién insertadas, conservando

los datos de las antiguas e inicializando las nuevas sin ninguna actividad

sucesora. Se espera por parte del usuario que se introduzcan las nuevas

dependencias y se presione el botón de “terminado”. Asimismo se conserva el

algoritmo de detección de bucles que se extenderá por todas las actividades,

antiguas y nuevas a la vez.

11.1.7 MODIFICAR LAS ACTIVIDADES DEL PROYECTO (CU06)

Para acceder al modificador de actividades se debe seleccionar el

menú Modificar actividades del menú Modificar de la barra.

Ilustración 11.22 – Menú de modificación de actividades

Se muestra a continuación un formulario que recoge tanto los datos de

las actividades como la información de las sucesoras de cada actividad. El

formulario es una ventana de diálogo modal y que puede ser cerrada.


- 113 -

Ilustración 11.23 – Formulario del modificador de actividades

Al iniciar este proceso se clonan (no se pasan por referencia) las

actividades para que, en caso de que el usuario quiera no guardar los cambios

en la modificación de las actividades, lo pueda hacer. Si ha habido algún

cambio en alguna actividad y se intenta cerrar la ventana aparecerá el mensaje

de la siguiente figura.

Ilustración 11.24 – Solicitud de conservación de la información original

Al presionar el botón de cerrar o presionar la opción “No” se conserva

el formulario en el estado que estaba antes de intentar salir, si por el contrario

se selecciona la opción de “Sí” se devuelve al programa cliente el conjunto de

actividades originales que fueron clonadas al inicio (los datos son los mismos

pero el Hashcode es diferente, es decir que ocupan dos regiones de memoria


- 114 -

distintas). Al presionar el botón “terminado” se devuelve al programa cliente las

modificaciones efectuadas para que se muestren en la tabla de las actividades.

El modificador de actividades incluye la detección de bucles y la

consistencia en los parámetros de duración fija, ya que la borrosa es controlada

por el Creador de Duraciones Borrosas.

Si la lista de actividades no entra en la pantalla se activa un

JScrollPane activando una barra vertical permitiendo poder mostrar todas las

actividades sin variar el tamaño del formulario de atributos de cada actividad

del encabezado.

Ilustración 11.25 – Activación de JscrollPane en el formulario de modificación

El modo de cambiar los atributos de una actividad es presionando en el

JRadioButton con el identificador y la descripción entre paréntesis de la


- 115 -

actividad deseada. Al hacerlo se cargan sus actividades sucesoras y se

deshabilitan las que generen algún bucle. También se cambia la descripción de

las actividades en tiempo de ejecución tanto en el JRadioButton como en el

JCheckBox que corresponde. Por defecto aparece seleccionada la actividad

con el identificador menor (la actividad A) y con sus atributos y actividades

sucesoras cargadas así como deshabilitados los JCheckBoxs que sean

imposibles de seleccionar de acuerdo al algoritmo de detección de bucles.


- 116 -

11.1.8 ELIMINAR ACTIVIDADES DEL PROYECTO (CU07)

Ilustración 11.26 – Menú de eliminación de actividades

Este caso de uso (eliminador de actividades) se inicia desde el menú

“Eliminar actividades” del menú Eliminar de la barra. En caso de que se intente

iniciar este caso de uso siendo el número de actividades del proyecto igual a 2

se mostrará el siguiente mensaje de error.

Ilustración 11.27 – Error causado al llamar al eliminador de actividades

En la imagen 55 se muestra el modelo que presenta esta clase que

hereda de la clase JDialog, que es modal y cerrable. Análogamente al

modificador de actividades, se clonan las actividades al originarse el evento

que lo ejecuta permitiendo no guardar los cambios al salir si así lo prefiriera el

usuario. Consta de un JComboBox que carga el identificador de las actividades

y su descripción entre paréntesis al ser lanzado.


- 117 -

Ilustración 11.28 – Aspecto del eliminador de actividades

Será en él donde el usuario seleccione la actividad o las actividades

que desee eliminar (una por una). Existe un JLabel debajo como ayuda para el

proceso de eliminación que facilita al usuario información útil que se describirá

a lo largo de este apartado.

Por otra parte la ventana consta de un conjunto de JRadioButton y

JCheckBox denominados además con el identificador de cada actividad y su

descripción entre paréntesis. Este conjunto de botones está inicialmente

inactivo en su totalidad esperando a que el usuario seleccione del JComboBox

la actividad que quiere eliminar.

El algoritmo de eliminación es el siguiente:


- 118 -

El usuario selecciona una actividad a eliminar que

denominaremos i y presiona el botón eliminar.

La actividad se marca en rojo y el algoritmo extrae el conjunto de

actividades inmediatamente anteriores de i y el conjunto de

actividades inmediatamente siguientes a i.

Si ambos conjuntos no están vacíos el algoritmo habilita la opción

de crear una relación de sucesión entre sus actividades

predecesoras y sus sucesoras. El usuario comprueba que las

actividades cuyo fin estaba ligado al inicio de la actividad borrada

(las anteriores) se desbloquean en la columna “actividades

anteriores” en forma de JRadioButton y que, por otra parte, se

habilitan las actividades cuyo inicio depende del fin de la actividad

borrada en la columna de “actividades siguientes”. Ambas

columnas por defecto aparecen sin marcar, ya que las nuevas

relaciones posibles que pueden existir ahora, antes no se

hubieran dado de ninguna manera gracias al algoritmo de

detección de bucles diseñado. En la imagen siguiente al eliminar

la actividad i aparecen nueve posibles relaciones

( lhkhkfjf ⇒⇒⇒⇒ ,,...,, ).


- 119 -

Diagrama 11.3 – Ejemplo de eliminación de la actividad I

El usuario selecciona las relaciones de sucesión entre las n

posibles que desee, pudiendo elegir desde ninguna hasta las n

posibles que existan. Por último se actualizan las conexiones

nuevas, se eliminan las antiguas y se elimina la actividad del

proyecto. En este proceso la lista desplegable permanecerá

deshabilitada.

Ilustración 11.29 – Opciones de sucesión encontradas


- 120 -

Como puede observarse en la figura superior el botón “terminado” se

deshabilita hasta que el usuario haya terminado de seleccionar las relaciones

de sucesión nuevas. Asimismo se carga la información de sucesión conocida

de la actividad seleccionada sin posibilidad de ser modificada como puede

verse en la figura superior.

En caso de que no exista ninguna posible relación de sucesión se

indicará al usuario.

Ilustración 11.30 – Opciones de sucesión no encontradas

El sistema permite eliminar como máximo n-2 actividades siendo n el

número total de actividades que compongan el proyecto. En este caso se

deshabilita el JComboBox y el botón “Eliminar”.


- 121 -

Ilustración 11.31 – Eliminación del máximo de actividades permitidas

Si ha habido algún cambio en alguna actividad y se intenta cerrar la

ventana aparecerá el mensaje de la siguiente figura.

Ilustración 11.32 – Solicitud de conservación de la información original

Al presionar el botón de cerrar o presionar la opción “No” se conserva

el formulario en el estado que estaba antes de intentar salir, si por el contrario

se selecciona la opción de “Sí” se devuelve al programa cliente el conjunto de

actividades clonadas al inicio (los datos son los mismos pero el Hashcode es

diferente, es decir que ocupan dos regiones de memoria distintas).


- 122 -

Al presionar el botón “terminado” se genera un mensaje advirtiendo al

usuario que los identificadores de las actividades se reasignarán otra vez para

mantener la consistencia de los datos.

Ilustración 11.33 – Mensaje informativote reasignación de identificadores

Una vez aceptado se devuelve al programa cliente la nueva lista de

actividades con una longitud menor que la inicial y siempre mayor o igual que

dos para que se puedan considerar como proyecto al conjunto de las mismas y

para que las muestre en la tabla de las actividades.

Es importante resaltar que para el óptimo funcionamiento del

eliminador de actividades es necesario que las actividades sucesoras de cada

actividad estén ordenadas con el identificador creciente. Ello se controla desde

la propia clase Actividad.

11.1.9 MODIFICAR FECHA DE INICIO DEL PROYECTO (CU02)

Ilustración 11.34 – Menú de modificación de la fecha de inicio del proyecto

Al accionar el AccionListener que gestiona los eventos de la barra de

menú se inicia el submódulo Modificar fecha de inicio del proyecto que


- 123 -

presentará la siguiente ventana modal y cerrable en primer plano requiriendo

información por parte del usuario. Se cargará la fecha de inicio del proyecto

actual en el calendario para que sea cambiada.

Ilustración 11.35 – Formulario de selección de fecha

En la figura superior se requiere la modificación de la fecha de inicio del

proyecto y presionar “Aceptar” o Enter. Si se cierra esta ventana o se presiona

cancelar se acabará la ejecución del submódulo sin modificar la fecha de inicio

del proyecto.


- 124 -

11.1.10 SOLUCIÓN DEL PROYECTO

Ilustración 11.36 – Opciones de solución para una rede con actividades borrosas

Al accionar el AccionListener que gestiona los eventos de selección por

accionar alguna opción de solución en el menú Archivo/Solucionar o presionar

Alt+”número de opción de solución” se inicia el proceso de comunicación con el

servidor para la solución del proyecto. Para ello los parámetros de conexión

con el servidor deben ser correctos y estar iniciado el servidor.

Se diferenciará entre un proyecto borroso y uno no borroso. Se

denomina proyecto borroso a aquel que tiene una duración borrosa como

mínimo en alguna de sus actividades y proyecto no borroso a aquel que no

tiene ninguna duración borrosa en ninguna de sus actividades.

Un proyecto no borroso no puede ser solucionado con técnicas de

lógica borrosa en el servidor. Por ello se deshabilitan las funciones de solución

borrosa del menú solucionar, obligando al usuario a seleccionar la opción de

“Pert no borroso” en el menú solucionar. Así lo muestra la ilustración inferior.


- 125 -

Ilustración 11.37 – Opciones de solución para una rede sin actividades borrosas

En caso de ser un proyecto borroso, dependiendo de la opción de

solución seleccionada se puede presentar una ventana modal y cerrable de la

clase JDialog requiriendo información de un parámetro para solucionar el

diagrama o no. Como ejemplo se muestra el parámetro requerido para una

solución del tipo “Centro de área”.

Ilustración 11.38 – Ejemplo de introducción de parámetros para la solución

La correcta entrada de datos es controlada para que el parámetro de

solución sea válido. El cuadro de texto permite la entrada de números y del

carácter ”.” como posición decimal. Se comprueba que el dato introducido esté

dentro del rango lícito. En caso contrario se mantendrá la ventana en primer

plano hasta que el usuario que cambie el parámetro o la cierre, cancelando así

la solicitud de solución.


- 126 -

Una vez validada la opción elegida de solución se pasa el control al

módulo de comunicaciones con el servidor para la solucionar del diagrama (ello

se explicara en el apartado de “solucionar el diagrama” del capítulo servidor) y

la posterior presentación de los resultados en pantalla.

11.2 COMUNICACIONES

En este modulo se describirá el protocolo de conexión con el servidor

para enviar y recibir los datos y la modificación de los parámetro de conexión

con el servidor.

11.2.1 CONEXIÓN CON EL SERVIDOR DE RESOLUCIÓN (CU09)

Para conectar la aplicación cliente con el servidor de resolución se

debe conocer la dirección IP del servidor dentro de la red y el puerto abierto en

él para recibir las peticiones de solución por parte de los clientes. La dirección

IP es inherente a la situación de la máquina donde resida el servidor y su

configuración de red. El puerto es una variable que se modifica desde el propio

servidor. Por tanto es necesario conocer ambas para poder establecer la

comunicación. La configuración de la conexión se guarda en el archivo

config.net.

En caso de que se conozcan correctamente ambos parámetros el

cliente iniciará un socket de conexión hacia el servidor (con los parámetros de

configuración de conexión cargados de un fichero) que aceptará la petición. En

ese momento se establece una conexión entre ambos, creándose un hilo de

ejecución paralelo al de aceptación de peticiones en el servidor y dando inicio

al protocolo a nivel de aplicación. El socket de conexión está montado en un


- 127 -

stream de objetos (ObjectOutputStream y ObjectInputStream) lo que facilita el

manejo de los mismos, que mantendrán las relaciones entre ellos intactas ya

que comparten el paquete “common”. Cabe destacar que estas relaciones se

perderían si se mandara por ejemplo actividad por actividad en otro tipo de

stream de los que proporciona java y habría que reconstruir las relaciones en el

receptor de la información, incrementando así el tiempo de ejecución.

El protocolo diseñado a nivel de aplicación es el siguiente:

La aplicación cliente ha recogido la información de los parámetros

de solución introducidos por el usuario y los envía en forma de

Objetos al servidor. Primero la opción seleccionada de solución y

luego el parámetro si éste existiese. El servidor está diseñado

para recibir esta información y detectar si la opción de solución

seleccionada necesita o no un parámetro.

Una vez recibidos los parámetros para la solución se manda un

objeto de la clase PertCpm por parte del cliente. Este objeto se

vio que contenía un array de Actividades, uno de Actividades

dummy y otro de Etapas. El cliente manda el objeto PertCpm con

el que trabajaba que contendrá únicamente actividades con los

datos que introducía el usuario (identificador, descripción,

duración, actividades anteriores y actividades siguientes) y los

arrays etapas y actividades dummy estarán iniciados como nulos.


- 128 -

La aplicación cliente se mantendrá en espera síncrona

(bloqueándose) hasta que el servidor termine de solucionar el

proyecto con la opción seleccionada.

Una vez que se haya solucionado el proyecto se enviará por parte

del servidor al cliente un objeto PertCpm con toda su información

derivada de la solución. En caso de que el proyecto no tenga

actividades dummy, su array será nulo.

El cliente recibe la información y actualiza el archivo con el que

trabajaba para posteriormente mostrar la información que

contiene.

El cliente cierra los streams de entrada y salida y el socket de

comunicación, este mismo proceso es seguido por el servidor que

también finalizará el hilo de ejecución correspondiente a esa

petición.

En caso de un error en la ejecución del protocolo se mostrará el

siguiente mensaje en la aplicación cliente:

Ilustración 11.39 – Error de conexión con el servidor de resolución

Se puede producir un error en cualquiera de los siguientes casos:


- 129 -

Antes de establecer la conexión, causas:

El servidor no está operativo.

La dirección IP es errónea.

El puerto de entrada al servidor no es correcto.

No se dispone de acceso a la red.

Durante la conexión, causas:

El servidor ha terminado su ejecución.

Ha existido un fallo en el acceso a la red.

En cualquiera de los casos el cliente no se bloquea, detecta que se ha

habido un error en el socket de conexión y la espera síncrona finaliza

manteniendo los resultados originales mostrados.

11.2.2 MODIFICAR LA CONFIGURACIÓN DE CONEXIÓN CON EL SERVIDOR (CU13)

Para modificar los parámetros de comunicación con el servidor se inicia

la secuencia en la barra de menú Modificar/Parámetros de conexión.

Ilustración 11.40 – Menú de modificación de los parámetros de conexión


- 130 -

La ejecución de este submódulo muestra un diálogo modal y cerrable

que carga la configuración de red por defecto con la que viene la aplicación

cliente la primera vez que se ejecuta. Una vez introducidos los parámetros de

conexión se guardan en un archivo para la próxima vez que se inicie la

aplicación.

Ilustración 11.41 – Formulario de parámetros de conexión

Consta de la “dirección IP” del servidor y el puerto de entrada de las

peticiones. En caso de usarse en una red local se tiene la posibilidad de poner

el nombre del host en el que se ejecute la aplicación en el campo “dirección

IP”. Esto será resuelto por el servidor de nombres.

Si se cierra la ventana o se cancela el proceso se devolverá el control a

la aplicación cliente sin modificar la configuración de red. En caso contrario se

verificará que el campo “Puerto” sea un número entero. En caso de no cumplir

esta restricción se notificará al usuario para que lo cambie o cancele el

proceso.

11.3 GESTIÓN DE ARCHIVOS

Este módulo se encarga de la carga y guardado de los datos de los

proyectos a ficheros. Consta de dos submódulos, el de guardado de archivos y

el de carga de archivos.


- 131 -

Los archivos que maneja el programa cliente tienen la extensión .pert y

son los únicos con que puede operar. El formato del archivo es el derivado de

un contenedor de objetos y no es legible en editores de textos. Esto garantiza

la seguridad de la no manipulación por parte del usuario de los datos,

manteniéndolos en un estado conforme e íntegro. Con ello se quiere decir que

no se modifiquen las duraciones ni el orden de posterioridad ni anterioridad de

las actividades tanto para construir bucles como para alterar el orden alfabético

de identificadores de ellas que son usados para el correcto funcionamiento del

programa.

Un archivo pert puede guardar proyectos resueltos y sin resolver, es

decir, con las actividades simplemente inicializadas por el usuario. Los datos

que los archivos pert contienen son cuatro:

Un objeto PertCpm que contiene los datos de actividades,

actividades dummy y etapas del proyecto.

Un objeto representando la fecha de inicio del proyecto.

La opción de solución seleccionada en caso de que esté resuelto

el proyecto.

El parámetro para el tipo de solución escogido en caso de que

estuviera resuelto y que necesitara un parámetro.


- 132 -

11.3.1 GUARDADO DE INFORMACIÓN (CU11)

Los archivos se guardan con un objeto de la clase ObjectOutputStream

montado sobre un FileOutputStream con el parámetro de la ruta hasta el

archivo.

Ilustración 11.42 – Menú guardar

Esté submódulo se encarga de guardar archivos cuando el usuario lo

desee (seleccionándolo en el menú) o al producirse un aviso y sugerencia de

guardar los datos del proyecto cuando se vaya a perder información por la

llamada a algún submódulo. Se muestra en la siguiente ilustración.

Ilustración 11.43 – Opciones de guardado automático

El diálogo de advertencia generado contiene la causa de posible

pérdida de la información. Se genera siempre que se intente llamar a un

proceso que vaya a cargar información nueva (crear un nuevo proyecto o abrir

un archivo), vaya a borrar la solución actual si ésta existe (insertar una


- 133 -

actividad, insertar varias actividades, modificar actividades o eliminar

actividades) o se vaya a cerrar el programa.

Seleccionando la opción de “Sí” se guardará la información en el

fichero actual o se pedirá al usuario que cree uno nuevo si éste no existe. Con

la opción “No” se descartan los cambios. En cualquiera de los dos casos se

continúa ejecutando la acción que generó el diálogo de advertencia. En caso

de “cancelar” o cerrar el diálogo se deshecha la ejecución de la acción que

generó el diálogo de advertencia, conservando la información del proyecto en

pantalla.

Hay dos procesos diferenciados:

Guardar archivo: Se ejecuta siempre que se esté manipulando

un archivo y el usuario desee guardar los cambios. Su función es

sobrescribir los datos del fichero que esté abierto. Si se ejecuta

guardar se muestra un mensaje de confirmación del éxito del

proceso.

Ilustración 11.44 – Confirmación de la escritura en disco

Guardar archivo como…: Se ejecuta cuando no existe un

archivo abierto o cuando sea seleccionado por el usuario. Este

proceso inicia un objeto JFileChooser por defecto en la carpeta


- 134 -

“Mis documentos” o en la ruta donde esté el archivo que se está

manipulando. Se requiere un nombre de archivo para guardar la

información. La ruta hasta el archivo se extrae del JFileChooser.

Ilustración 11.45 – Diálogo de guardado con filtro de extensiones pert

En caso de intentar una sobreescritura en otro archivo se advierte al

usuario con el siguiente diálogo:

Ilustración 11.46 – Confirmación de sobreescritura


- 135 -

Por último se comunica que la operación se ha realizado

correctamente o se retorna al punto donde se produjo la excepción si

se ha cancelado el proceso.

Ilustración 11.47 – Confirmación de la escritura en disco

11.3.2 CARGA DE INFORMACIÓN (CU12)

Los archivos se cargan con un objeto de la clase ObjectInputStream

montado sobre un FileInputStream con el parámetro de la ruta hasta el archivo.

Ilustración 11.48 – Menú de carga de archivos

Al submódulo se accede desde el menú Archivo/Abrir o presionando

Ctrl+A y se abre un JFileChooser con un filtro para seleccionar únicamente

archivos pert soportados por el programa.


- 136 -

Ilustración 11.49 – Diálogo de carga con filtro de extensiones pert

Una vez cargado el archivo se muestran los datos por pantalla y se

actualiza el campo de nombre de archivo actual de la cabecera de la

aplicación.

En caso de que exista un error en el formato se notifica al usuario con

un mensaje de error.

Ilustración 11.50 – Error en la carga de archivos


- 137 -

11.4 PRESENTACIÓN DE LA INFORMACIÓN (CU10)

El objetivo de este apartado es realizar una representación lógica de la

información que maneja el sistema de acuerdo al modelo de datos descrito en

el apartado Diseño. Las tablas donde se muestran los datos no son editables

para garantizar la integridad de los datos en todo momento y se construyen

sobre ventanas JInternalFrame dentro de un JDesktopPane para hacer más

fácil su movimiento.

Existirán tres tablas de datos como máximo en la aplicación. No se

usan bases de datos pero la información se mantiene en un estado conforme

mediante el objeto PertCpm. En él se ha visto que contiene tres listas: la de

actividades, la de actividades ficticias o dummy y la de etapas. Cada uno de los

componentes de esta lista está en la región de memoria asociada al PertCpm.

Todas las relaciones que existen entre ellas están establecidas mediante

punteros a sus datos asociados.

En este apartado se distinguirá entre dos tipos de información: la

información básica y la información resuelta.

11.4.1 INFORMACIÓN BÁSICA

La información básica está formada por los parámetros que el usuario

puede manejar directamente mediante submódulos de la aplicación. Como se

ha visto hasta ahora son los referentes a las actividades. Siendo los campos

que se manejan:


- 138 -


aplicación cliente. Es un una cadena de caracteres y no puede

ser nulo.


caracteres y puede tener valor vacío.


forma de cadena de caracteres. Puede tomar cuatro formas

diferentes:


representa.







Actividades Anteriores: Es un conjunto de las actividades

anteriores asociadas a la actividad. Está representado por una

cadena de caracteres. En caso de ser nulo se declara como

“ninguna”.


- 139 -

Actividades Siguientes: Es el conjunto de las actividades

inmediatamente posteriores asociadas a la actividad. Está

representado por una cadena de caracteres. En caso de ser nulo

se declara como “ninguna”.

El formato de la tabla lo gestiona un TableModel asociado a la tabla

actividades. En caso de mostrar información básica presenta el aspecto de la

ilustración:

Ilustración 11.51 – Tabla de información básica de actividades

Esta tabla se genera después de:

Cargar un archivo que no esté resuelto.

Terminar el proceso de creación de un nuevo proyecto.

Insertar actividades.

Modificar actividades.

Eliminar Actividades.


- 140 -

11.4.2 INFORMACIÓN RESUELTA

La información resuelta está formada por todos los datos que contiene

el proyecto. Está compuesta por la tabla de actividades, la de actividades

dummy (en caso de que existan) y la de etapas. Se genera siempre que se

recibe la solución a un proyecto. Los campos que se manejan en cada tabla

son:

TABLA ACTIVIDADES


aplicación cliente. Es un una cadena de caracteres y no puede

ser nulo.


caracteres y puede tener valor vacío.


forma de cadena de caracteres. Puede tomar cuatro formas

diferentes:


representa.






- 141 -



Actividades Anteriores: Es el conjunto de las actividades

anteriores asociadas a la actividad. Está representado por una

cadena de caracteres. En caso de ser nulo se declara como

“ninguna”.

Actividades Siguientes: Es el conjunto de las actividades

inmediatamente posteriores asociadas a la actividad. Está

representado por una cadena de caracteres. En caso de ser nulo

se declara como “ninguna”.

Etapa Inicial: Es la etapa en la que se inicia la actividad. Está

representada por un número entero mayor que cero.

Etapa Final: Es la etapa en la que se termina la actividad. Está


Margen Libre: Es la representación de la duración del margen

libre de la actividad en forma de cadena de caracteres y toma

cualquiera de las cuatro formas diferentes descritas en el campo

duración.

Margen Total: Es la representación de la duración del margen

total de la actividad en forma de cadena de caracteres y toma

cualquiera de las cuatro formas diferentes descritas en el campo

duración.


- 142 -

Como se verá en la ilustración siguiente se enfatiza el camino crítico

con color rojo. Se consigue mediante el TableModel de la tabla actividades que

es capaz de comprobar si tanto el margen libre como el margen total de cada

actividad son iguales a cero. En este caso se colorea la fila entera en color rojo

ya que al ser ambos márgenes iguales a cero significa que la actividad

pertenece al camino crítico.

Ilustración 11.52 – Tabla de información resuelta de actividades

TABLA DE ETAPAS

Id: Es el identificador unívoco de cada etapa y es un entero

Fecha Prevista: Es la representación de la fecha prevista de la

etapa en forma de cadena de caracteres de una de las cuatro

formas diferentes descritas en el campo duración.

Fecha Límite: Es la representación de la fecha límite de la etapa

en forma de cadena de caracteres de una de las cuatro formas

diferentes descritas en el campo duración.

Actividades Anteriores: Es el conjunto de actividades que llegan

a la etapa representado por una cadena de caracteres ordenada.


- 143 -

En caso de ser nulo se declara como “ninguna”, únicamente se da

en el caso de la etapa inicial del proyecto.

Actividades Siguientes: Es el conjunto de actividades que salen

a la etapa representado por una cadena de caracteres ordenada.

En caso de ser nulo se declara como “ninguna”, únicamente se da

en el caso de la etapa final del proyecto.

Como se verá en la ilustración siguiente se enfatiza el camino crítico

con color rojo. Se consigue mediante el TableModel de la tabla etapas que es

capaz de comprobar si tanto la fecha prevista como la fecha límite de cada

etapa son iguales a cero. En este caso se colorea la fila entera en color rojo ya

que al ser ambas fechas iguales a cero significa que la etapa pertenece al

camino crítico.

Ilustración 11.53 – Tabla de información resuelta de etapas

TABLA DE ACTIVIDADES FICTICIAS

Id: Es el identificador unívoco de cada actividad dummy y es un

entero ascendentes que empieza en 0.


- 144 -

Actividades Anteriores: Es un conjunto de actividades

inmediatamente anteriores representadas por una cadena de

caracteres ordenada.

Actividades Siguientes: Es un conjunto de actividades

inmediatamente posteriores representadas por una cadena de

caracteres ordenada.

Etapa Inicial: Es la etapa de la que parte la actividad


Etapa Final: Es la etapa a la que llega la actividad representada

por un número entero mayor que cero.

La tabla de actividades ficticias (dummy) se muestra si existen en la

solución que el motor de resolución envió. Se recuerda que es una actividad

creada con tiempo nulo para respetar las obligaciones de representación del

diagrama de red. Por tanto no tiene relevancia darlas un nombre, ni una

duración ni, consecuentemente, valor a los márgenes así como enfatizarlas de

alguna manera.

Ilustración 11.54 – Tabla de información de actividades dummy


- 145 -

DIAGRAMA DE GANTT

El diagrama de Gantt se muestra siempre que la solución al proyecto

esté desborrosificada. En caso de no estarlo no tendría sentido mostrarlo por la

inviabilidad de la representación en un diagrama de Gantt.

El diagrama se obtiene como panel de una clase que se encarga de

dibujarle. La clase Gantt recibe como parámetros la fecha de inicio del proyecto

y las actividades del mismo. A partir de ellas obtiene la representación que

incluye la duración de la actividad en rojo, el margen libre en verde y el margen

total en azul. Se diferencia cada actividad con su descripción e identificador

entre paréntesis. Se ofrecen al usuario dos tipos de presentación de las

actividades: por orden de identificador o por orden cronológico.

Ilustración 11.55 – Opciones de orden para la muestra del diagrama de Gantt

El diagrama es interactivo pudiéndose hacer zoom en él y guardando la

vista que contenga.


- 146 -

Ilustración 11.56 – Diagrama de Gantt por orden de identificador, por orden temporal y ampliación de

una sección del diagrama


- 147 -

12. EL SERVIDOR DE RESOLUCIÓN

Este subsistema es el encargado de resolver el proyecto diseñado por

el cliente y permitir la conexión con él. Es un archivo JAR que se inicia

mediante un doble clic de ratón. El subsistema se divide a su vez en dos

módulos: gestor de peticiones y el motor de resolución. En cada uno de los

módulos se especifican los casos de uso que solucionan.

12.1 GESTOR DE PETICIONES

El gestor de peticiones es el encargado de arrancar el programa y de

gestionar las peticiones de solución de los clientes que soliciten una solución al

proyecto con el que trabajan.

Al arrancar el programa se pide al usuario el puerto por el que se

aceptarán las peticiones. Es necesario que el puerto esté abierto en el firewall

si ese dispone de él. Esta información se guarda en un fichero llamado

config.net. Si ya está configurado se dará la opción de cambiarlo.

Ilustración 12.1 – Inicio del servidor de resolución

Seguidamente se procede a arrancar el servidor de peticiones

implementado con un ServerSocket en el puerto configurado que siempre

quedará a la espera de peticiones de resolución. Como se vio en el cliente, el

socket funciona con streams de objetos para beneficiarse de las múltiples

funcionalidades que proporciona el trabajar con ellos. Del mismo modo se


- 148 -

utiliza en el gestor de peticiones mediante un ObjectInputStream y

ObjectOutputStream montados sobre el socket que sirve las peticiones.

Cuando un cliente inicie el protocolo con conexión a nivel de aplicación

el servidor aceptará la petición creando un hilo de ejecución independiente y

paralelo al “Gestor de peticiones” donde se recibirán los datos de entrada, se

realizarán los cálculos para resolver el proyecto y se devolverá la solución.

Cuando el proceso de solución finalice y se concluya el protocolo de conexión

el hilo de ejecución terminará liberando espacio en memoria y los recursos que

estaba utilizando.

El protocolo diseñado a nivel de aplicación es el siguiente:

La aplicación cliente manda un objeto de la clase PertCpm. Este

objeto se vio que contenía un array de Actividades, uno de

Actividades dummy y otro de Etapas. El cliente manda el objeto

PertCpm con el que trabajaba que contendrá únicamente

actividades con los datos que introducía el usuario (identificador,

descripción, duración, actividades anteriores y actividades

siguientes) y los arrays etapas y actividades dummy estarán

iniciados como nulos.

El servidor recibe la opción de solución seleccionada por el cliente

y el parámetro de la misma si es necesario.


- 149 -

El servidor termina de solucionar el proyecto con la opción

seleccionada y el parámetro correspondiente si éste último

existiera.

Una vez que se haya solucionado el proyecto se enviará por parte

del servidor al cliente un objeto PertCpm con toda la información

derivada de la solución. En caso de que el proyecto no tenga

actividades dummy, su array será nulo.

El servidor cierra los streams de entrada y salida y el socket de

comunicación, y también finalizará el hilo de ejecución

correspondiente a esa petición.

En caso de un error en la ejecución del protocolo se finalizará el hilo

borrándolo en el estado que estuviera junto con los datos que manejara.

12.2 MOTOR DE RESOLUCIÓN (CU08)

En éste apartado se describirá toda la lógica de solución del proyecto.

Se compone de cuatro submódulos de ejecución secuencial, es decir, una vez

terminado uno se pasa al siguiente.

12.2.1 CREACIÓN DEL DIAGRAMA DE RED

Como se ha visto se recibe un conjunto de actividades y sus relaciones

de predecisión y sucesión. Este apartado se encarga de crear el diagrama de

red mediante el siguiente procedimiento:

Para cada actividad, independientemente de las relaciones que

tenga con las demás, se crea una etapa de inicio y de fin. Por


- 150 -

tanto se obtienen 2n etapas en un principio, siendo n el número

de actividades del proyecto.

Diagrama 12.1 – Método de inicialización de etapas

Se crea una actividad ficticia (dummy de tiempo nulo) para cada

relación de succión. Las relaciones de predecisión no intervienen.

Si la actividad i tiene como actividades siguientes a j y k se crea

una actividad ficticia entre la etapa fin de i y la etapa inicial de j y

otra ficticia entre la etapa fin de i y la etapa inicial de k.

Diagrama 12.2 – Trazo de actividades ficticias entre etapas


- 151 -

Llegados a este punto se inicia una fase de factorización. Su

objetivo es reducir el número de etapas conservando los

principios de en que se basa un Diagrama de red.

Primero se factorizan aquellas etapas en las que todas las

actividades que le lleguen sean ficticias o no tengan ninguna de

ningún tipo (etapa inicial o nodo inicial). A este proceso se le

denominará factorización simple por la izquierda o de

predecesoras. Cuando este proceso es llevado a cabo se

eliminan etapas y actividades ficticias y se actualiza la

información de las etapas y de las actividades de manera que

ninguna etapa existente conozca ninguna actividad ficticia

borrada y viceversa.

Diagrama 12.3 – Factorización por la izquierda


- 152 -

Posteriormente se factorizan aquellas etapas en las que todas las

actividades que salen de ellas sean ficticias o no tengan ninguna

de ningún tipo (etapa final o nodo final). A este proceso se le

denominará factorización simple por la derecha o de sucesoras.

Cuando este proceso es llevado a cabo se eliminan etapas y

actividades ficticias y se actualiza la información de las etapas y

de las actividades de manera que ninguna etapa existente

conozca ninguna actividad ficticia borrada y viceversa.

Diagrama 12.4 – Factorización por la derecha

En gran número de proyectos con este simple proceso bastaría

pero hay casos en los que es necesario introducir operaciones

más avanzadas para conseguir el diagrama de red óptimo. Se


- 153 -

muestra un ejemplo de parte de un diagrama y la solución que

proporciona el servidor.

Diagrama 12.5 – Resolución optima de actividades ficticias

Al terminar de diseñar el diagrama de red se numeran las etapas y las

actividades ficticias. Llegados a este punto las actividades mantienen los

atributos que tenían a la entrada (identificador, descripción, duración,

actividades anteriores y actividades siguientes) y los que proporciona este

submódulo (etapa inicial y etapa final). Las actividades ficticias, en caso de

existir, conocerán todos sus atributos (identificador, actividades anteriores,

actividades siguientes, etapa inicial y etapa final). Las etapas generadas

tendrán resueltos parte de sus atributos (identificador, actividades anteriores y

actividades siguientes). Todos los atributos del proyecto están relacionados con

lo se puede acceder fácilmente a la información de cada elemento a partir de

los demás con los que se tenga relación.


- 154 -

12.2.2 FASE HACIA DELANTE DEL MÉTODO CPM

Para poder realizar la fase hacia delante con éxito se debe conocer la

operación de suma entre dos duraciones y cómo determinar si una es mayor

que otra.

Teniendo en cuenta que estamos trabajando con duraciones borrosas y

duraciones conocidas se pueden presentar tres diferentes tipos de suma:

La suma entre dos duraciones conocidas xA = y yB = se opera

sumando el primer término con el segundo dando lugar a la

duración conocida yxC += .

Gráfica 12.1 – Suma de dos duraciones conocidas

La suma entre una duración conocida xA = y una borrosa

),,,( 1111 dcbaB = se opera incrementando cada parámetro de la

duración borrosa en el valor de duración conocida dando lugar a

la duración borrosa ),,,( 1111 xdxcxbxaC ++++= .


- 155 -

Gráfica 12.2 – Suma de duración borrosa y duración conocida

La suma entre dos duraciones borrosas ),,,( 1111 dcbaA = y

),,,( 2222 dcbaB = se opera sumando cada término de la primera

duración con el correspondiente de la segunda dando lugar al

numero borroso ),,,( 21212121 ddccbbaaC ++++= .

0

1

0 5 10 15 20

Gráfica 12.3 – Suma de duraciones borrosas


duraciones conocidas se establecen tres tipos de comparaciones entre ambas

para determinar cual es la mayor:

Para determinar entre dos duraciones conocidas si xA = es

mayor que yB = se comprueba si yx > .


- 156 -

Gráfica 12.4 – Comparación de duraciones conocidas en que A>B

Para determinar entre una duración conocida xA = y una borrosa

),,,( 1111 dcbaB = si BA > se comprueba si 1dx ≥ .

Gráfica 12.5 – Comparación de duración conocida y duración borrosa en que A>B

Para determinar entre una duración borrosa ),,,( 1111 dcbaA = y

una conocida xB = si BA > se comprueba si xd >1 .

Gráfica 12.6 – Comparación de duración conocida y duración borrosa en que A>B


- 157 -

Para determinar entre dos duraciones borrosas si ),,,( 1111 dcbaA =

es mayor que ),,,( 2222 dcbaB = se comprueba si 21 dd ≥ y en

caso de que sea 21 dd = se comprueba si 21 cc ≥ y en caso de

que sea 21 cc = se comprueba si 21 bb ≥ y en caso de que sea

21 bb = se comprueba si 21 aa > .

Gráfica 12.7– Comparación de duraciones borrosas en que A>B

En la fase hacia delante del camino crítico se pretende determinar los

instantes más tempranos o la fecha prevista para cada etapa o nodo. Para ello

se asigna al nodo inicial la fecha prevista cero. Luego se elige un nodo tal que

todos los anteriores que estén unidos directamente a él por una actividad ya

tengan fecha prevista. Se etiqueta el nodo elegido con la duración máxima de

la suma de la duración cada actividad más la fecha prevista del nodo del que


- 158 -

proviene. Por tanto, usando la notación kt para la fecha prevista del nodo k y

ikt para la duración de la actividad que va del nodo i al k , la formula a emplear

es:

},...,,max{ ,,22,11 knmnmknnknnk ttttttt +++=

Ecuación 12.1 – Resolución de la fecha prevista de cada etapa

Este paso se repite hasta etiquetar el nodo final, entonces ésta será la

duración mínima teórica del proyecto. Al trabajar con duraciones borrosas y

conocidas se puede obtener la duración total del proyecto borrosa.

12.2.3 FASE HACIA ATRÁS DEL MÉTODO CPM

Para poder realizar la fase hacia atrás con éxito se debe conocer la

operación de resta entre dos duraciones y cómo determinar si una es menor

que otra.


duraciones conocidas se pueden presentar cuatro diferentes tipos de resta:

La resta entre dos duraciones conocidas xA = y yB = se opera

restando el primer término con el segundo dando lugar a la

duración conocida yxC −= .


- 159 -

Gráfica 12.8- Resta ente duraciones conocidas

La resta entre una duración borrosa ),,,( 1111 dcbaA = y una

conocida xB = se opera sustrayendo cada parámetro de la

duración borrosa en el valor de duración conocida dando lugar a

la duración borrosa ),,,( 1111 xdxcxbxaC −−−−= .

Gráfica 12.9 - Resta ente duración borrosa y duración conocida

La resta entre dos duraciones borrosas ),,,( 1111 dcbaA = y

),,,( 2222 dcbaB = puede operar de dos formas:

Mediante una resta clásica de dos números borrosos dando

lugar ),,,( 21212121 adbccbdaBAC −−−−=−= . Nótese que

en este caso las propiedades algebraicas de la resta no se

mantienen ya que si BCABAC +≠⇒−= . En cambio las


- 160 -

propiedades del número borroso ( dcba ≤≤≤ ) se

mantienen.

Gráfica 12.10 – Diferencia borrosa clásica entre duraciones borrosas

Mediante una resta de dos números borrosos “ordenados”

también denominada escalar (dado que se multiplica por -1)

dando lugar ),,,()1( 21212121 ddccbbaaBAC −−−−=×−+= .

Nótese que en este caso las propiedades algebraicas de la

resta se mantienen ya que si BCABAC +=⇒−= . En

cambio las propiedades del número borroso ( dcba ≤≤≤ )

no se mantienen la mayoría de las veces.

Gráfica 12.11– Diferencia escalar entre duraciones borrosas

La resta entre una duración conocida xA = y una borrosa

),,,( 1111 dcbaB = puede operar de dos formas:


- 161 -

Mediante resta clásica del número borroso B dando lugar

),,,( 2222 axbxcxdxBAC −−−−=−= . Nótese que en este

caso las propiedades algebraicas de la resta no se

mantienen ya que si BCABAC +≠⇒−= . En cambio las

propiedades del número borroso ( dcba ≤≤≤ ) se

mantienen.

Gráfica 12.12 – Diferencia borrosa clásica entre duración conocida y duración borrosa

Mediante resta del número borroso B escalarmente, es decir

que B se multiplica por -1, dando lugar

),,,()1( 21222 dxcxbxaxBAC −−−−=×−+= . Nótese que en

este caso las propiedades algebraicas de la resta se

mantienen ya que si BCABAC +=⇒−= . En cambio las

propiedades del número borroso ( dcba ≤≤≤ ) cambian su

orden a la forma ( dcba ≥≥≥ ).


- 162 -

Gráfica 12.13 – Diferencia escalar entre duración conocida y duración borrosa


duraciones conocidas se establecen tres tipos de comparaciones entre ambas

para determinar cual es la menor:

Para determinar entre dos duraciones conocidas si xA = es

menor que yB = se comprueba si yx < .

Gráfica 12.14 – Comparación de duraciones conocidas en que A<B

Para determinar entre una duración conocida xA = y una borrosa

),,,( 1111 dcbaB = si BA < se comprueba si 1dx < .


- 163 -

Gráfica 12.15 – Comparación de duración conocida y duración borrosa en que A<B

Para determinar entre una duración borrosa ),,,( 1111 dcbaA = y

una conocida xB = si BA < se comprueba si xd ≤1 .

Gráfica 12.16 – Comparación de duración conocida y duración borrosa en que A<B

Para determinar entre dos duraciones borrosas si ),,,( 1111 dcbaA =

es menor que ),,,( 2222 dcbaB = se comprueba si 21 dd ≤ y en

caso de que sea 21 dd = se comprueba si 21 cc ≤ y en caso de

que sea 21 cc = se comprueba si 21 bb ≤ y en caso de que sea

21 bb = se comprueba si 21 aa < .


- 164 -

Gráfica 12.17 – Comparación de duraciones borrosas en que A<B

En la fase hacia atrás del camino crítico se pretende determinar los

instantes más tardíos o la fecha límite para cada etapa o nodo. Para ello se

asigna al nodo final la fecha límite, siendo esta la misma que su fecha prevista.

Luego se elige un nodo tal que todos los siguientes que estén unidos

directamente a él por una actividad ya tengan fecha límite. Se etiqueta el nodo

elegido con la duración mínima de la resta de la fecha límite del nodo al que

llega menos la duración de la actividad que los une. Por tanto, usando la

notación *it para la fecha límite del nodo i y ikt para la duración de la

actividad que va del nodo i al k , la formula a emplear es:

},...,,min{* ,2,21,1 nminmninnini ttttttt −−−=

Ecuación 12.2 – Resolución de la fecha límite de cada etapa


- 165 -

Este paso se repite hasta etiquetar el nodo inicial, debiendo ser éste igual a su

fecha prevista, es decir, cero. Como se ha visto, utilizando la “resta borrosa” o

la “resta escalar” u ordenada los resultados no serán los mismos. Utilizando la

resta borrosa la fecha límite del nodo inicial será un número borroso con la

mayoría de sus términos negativos (algo incoherente) y utilizando la resta

escalar la fecha límite del nodo inicial será cero.

12.2.4 IDENTIFICACIÓN DE LAS ACTIVIDADES CRÍTICAS

Habiendo determinado las fechas previstas y límites de todos los nodos

de la red, la identificación del camino crítico es sencilla (si se ha empleado la

resta escalar) y compleja (si se ha empleado la resta borrosa). Las actividades

críticas de la red serán aquellas que unan aquellos nodos cuyas fechas

previstas y límites sean iguales (las etapas con intervalo de flotamiento igual a

cero). Estos nodos también forman parte del camino crítico.

En el caso del empleo de la “resta borrosa” sería conveniente usar

técnicas de desborrosificación para señalar el camino crítico como opción más

sencilla. Las opciones de desborrosificación se detallarán en el apartado

12.2.6.

12.2.5 CALCULAR LOS MÁRGENES DE CADA ACTIVIDAD

Los márgenes u holguras de cada actividad son los retrasos que puede

tener cada actividad. Se calcula tanto el margen libre como el total

denotándolos con kiL , y kiS , respectivamente.


- 166 -

kiikki

kiikki

tttS

tttL

,,

,,

* −−=

−−=

Ecuación 12.3 - Resolución de las holguras de las actividades del proyecto

Por tanto el margen libre de la actividad que va del nodo i al k será el retraso

que puede existir en el comienzo o en la ejecución de la actividad que va de i

a k sin modificar la fecha prevista de la etapa k . El margen total de la actividad

que va del nodo i al k será el retraso que puede existir en el comienzo o en la

ejecución de una actividad que va de i a k sin modificar la fecha prevista de

finalización del proyecto. Cabe destacar que las actividades que formen parte

de la ruta crítica tendrán ambos márgenes iguales a cero. Como se ha visto,

utilizando la “resta borrosa” o la “resta escalar” u ordenada los resultados no

serán los mismos. Utilizando la resta borrosa las holguras de una actividad

crítica serán números borrosos con la mayoría de sus términos negativos (algo

incoherente) y utilizando la resta escalar las holguras de una actividad crítica

serán cero.

12.2.6 OPCIONES DE DESBORROSIFICACIÓN PROPORCIONADAS

En este apartado se hace referencia a las opciones de

desborrosificación implementadas en el servidor para un proyecto con

duraciones únicamente borrosas o con duraciones borrosas y conocidas.


- 167 -

Valoración optimista de la duración borrosa A y parámetro α

Llamaremos tramo optimista de un número borroso

),,,( dcbaA = al intervalo ],[ ba que corresponde a la

ecuación ],[)( baxab

axxA ∈∀

−

−=µ .

Dado un número ]1,0[∈α y un conjunto borroso A ,

definimos el α -corte de A como el conjunto αA , cuya


≥

=otro

xx

A

A0

)(1)(

αµϕ

α

Ecuación 12.4

Por tanto la valoración más optimista del numero borroso A

con el α -corte de parámetro α será:

aabxab

ax

x

ab

axx

A

A

+−=⇒≥−

−

≥

−

−=

)(

)(

)(

αα

αµ

µ

Ecuación 12.5

Como ejemplo se muestra la valoración optimista del número

borroso )9,6,3,1(=A con el α -corte de parámetro 75.0=α

siendo 5.21)13(75.0)( =+−×=+−= aabx α


- 168 -

Gráfica 12.18 – Valoración optimista de la duración borrosa A con parámetro α

Valoración pesimista de la duración borrosa A y parámetro α

Llamaremos tramo pesimista de un número borroso

),,,( dcbaA = al intervalo ],[ dc que corresponde a la

ecuación ],[)( dcxcd

xdxA ∈∀

−

−=µ .

Dado un número ]1,0[∈α y un conjunto borroso A ,

definimos el α -corte de A como el conjunto αA , cuya


≥

=otro

xx

A

A0

)(1)(

αµϕ

α

Ecuación 12.6

Por tanto la valoración más pesimista del número borroso A

con el α -corte de parámetro α será:

)(

)(

)(

cddxcd

xd

x

cd

xdx

A

A

−−=⇒≥−

−

≥

−

−=

αα

αµ

µ


- 169 -

Como ejemplo se muestra la valoración pesimista del

numero borroso )9,6,3,1(=A con el α -corte de parámetro

75.0=α siendo 75.6)69(75.09)( =−×−=−−= cddx α

Gráfica 12.19 – Valoración pesimista de la duración borrosa A con parámetro α

Media máxima de la duración borrosa A

Denominaremos el tramo de media máxima de un número

borroso ),,,( dcbaA = al intervalo ],[ cb .

La media máxima MOM (Mean Of Maxima) se calcula como

corresponde a la ecuación 2

cbMOM

+= .

En el caso en que el núcleo del número borroso se

componga únicamente de un valor ( cb = ), la determinación

de A es inmediata. Sin embargo, si el núcleo es un intervalo

de confianza ( cb < ) se operaría. Obsérvese que este

método se basa en la idea estadística de la moda y no se

usa toda la información de la duración borrosa.


- 170 -

Como ejemplo se muestra la media máxima del número

borroso )9,6,3,1(=A siendo 5.42

63=

+=MOM

Gráfica 12.20 – Media máxima (MOM) de la duración borrosa A

Valoración de la media máxima de la duración borrosa A y

parámetro α

Denominaremos el tramo de media máxima de un número

borroso ),,,( dcbaA = al intervalo ],[ cb dado un número

]1,0[∈α .

La media máxima αMOM se calcula como corresponde a la

ecuación )( bcbMOM −+= αα .

En el caso en que el núcleo del número borroso se

componga únicamente de un valor ( cb = ), la determinación

de A es inmediata. Sin embargo, si el núcleo es un intervalo

de confianza ( cb < ) se operaría.


- 171 -

Como ejemplo se muestra la media máxima del número

borroso )9,6,3,1(=A con el parámetro 75.0=α siendo

25.5)36(75.03)( =−×+=−+= bcbMOM αα

Gráfica 12.21 – Media máxima (MOM) de la duración borrosa A con parámetro α

Media borrosa de la duración borrosa A

Partiendo de un número borroso ),,,( dcbaA = cuya función

de pertenencia es:

∈−

−∈

∈−

−

=

otro

baxcd

xd

cbx

baxab

ax

xA

0

],(

],[1

),[

)(µ

Ecuación 12.7 – Función de pertenencia de la duración borrosa A

El soporte del número borroso ],[)( daxAsop ∈=

La media borrosa FM (Fuzzy Mean) se calcula como:


- 172 -

∫

∫ ×

=

)(

)(

)(

)(

Asop

A

Asop

A

dxx

dxxx

FMµ

µ

Ecuación 12.8 – Media borrosa

Obsérvese que se basa en la idea estadística de la media

aritmética ponderada y que este procedimiento utiliza toda la

información del número borroso.

Como ejemplo se muestra la media borrosa del número

borroso )9,6,3,1(=A siendo:

7878.45.5

333.26

)(

)(

)(

)(==

×

=

∫

∫

Asop

A

Asop

A

dxx

dxxx

FMµ

µ

Ecuación 12.9

Gráfica 12.22 – Media borrosa (FM) de la duración borrosa A

Centro de área de la duración borrosa A y parámetro α

Partiendo de un número borroso ),,,( dcbaA = cuya función

de pertenencia es:


- 173 -

∈−

−∈

∈−

−

=

otro

baxcd

xd

cbx

baxab

ax

xA

0

],(

],[1

),[

)(µ

Ecuación 12.10 – Función de pertenencia de la duración borrosa A

El centro de área CEO (Center of Area) del número borroso

A es aquél que acumule el 50% del área que delimita su

función de pertenencia )(xAµ con el eje de las abscisas. Es

decir, CEO es aquel valor que:

Ecuación 12.11 – Centro de área del 50%

Obsérvese, que este método se basa en la idea estadística

de la mediana y utiliza toda la información del número

borroso. Este método permite introducir la aversión al riesgo

del usuario variando el área que )(xAµ debe acumular a su

izquierda dado un número ]1,0[∈α

Ecuación 12.12 - Centro de área del 50%

Como ejemplo se muestra el centro de área del número

borroso )9,6,3,1(=A con el parámetro 75.0=α , 5.0=α y

25.0=α siendo:


- 174 -

375.3

75.4

1277.6

25.0

5.0

75.0

=

=

=

CEO

CEO

CEO

Gráfica 12.23 – Centro de área (CEO) de la duración borrosa A con parámetro α

12.2.7 OPCIONES DE RESOLUCIÓN DEL PROYECTO

Como se acaba de ver en el apartado anterior, se proporcionan seis

maneras diferentes de desborrosificar las duraciones, cuatro de ellas con

parámetro. Se recuerda que dependiendo de si el proyecto contiene al menos

una actividad con duración borrosa o no se le denomina “proyecto borroso” o

“proyecto no borroso” respectivamente.

En caso de que el proyecto sea no borroso, no se permiten opciones

de solución borrosas, simplemente se soluciona el proyecto con el método del

camino crítico con todas las duraciones conocidas que contenga.

Por otra parte, si el proyecto es definido como borroso, se proporcionan

tres grandes métodos de solución:

Desborrosificar la duración de todas las actividades con duración

borrosa antes de iniciar la fase hacia delante. De éste modo se

tiene un conjunto de actividades con duraciones deterministas.


- 175 -

Este método proporciona un diagrama de Gantt e incluye los seis

tipos vistos en el apartado anterior:

Valoración optimista con parámetro α.

Valoración pesimista con parámetro α.

Media máxima.

Valoración de la media máxima con parámetro α.

Centro de área con parámetro α.

Media borrosa.

Desborrosificar la duración de todas las actividades y etapas con

duración borrosa al finalizar la fase hacia delante del camino

crítico. De éste modo se opera con las duraciones borrosas

únicamente en forma de suma que, como se ha visto, es

conmutativa. Se obtiene así una duración del proyecto borrosa

que será desborrosificada según la opción seleccionada por el

usuario. La fase hacia atrás se realizará con duraciones

deterministas proporcionando un camino crítico bien definido.

Este método proporciona un diagrama de Gantt e incluye los seis

tipos vistos en el apartado anterior:

Valoración optimista con parámetro α.

Valoración pesimista con parámetro α.


- 176 -

Media máxima.

Valoración de la media máxima con parámetro α.

Centro de área con parámetro α.

Media borrosa.

Operar con duraciones borrosas durante todo el proceso del

camino crítico, tanto la fase hacia delante como la fase hacia

atrás. De éste modo se opera con las duraciones borrosas tanto

en forma de suma como de resta que, como se ha visto, ésta

última no es conmutativa. Se obtiene así una duración del

proyecto borrosa y todos los datos del mismo en forma de

duración borrosa. Este método no proporciona un diagrama de

Gantt e incluye los dos tipos de resta vistos en anteriores

apartados:

Resta “borrosa” (no conmutativa que conserva la definición

de número borroso y con camino crítico no definido).

Resta “escalar” (conmutativa que no conserva la definición

de número borroso y con camino crítico definido).

Al terminar los cálculos de todas las fechas previstas y límites de

las etapas y los márgenes libres y totales de las actividades se

presenta al usuario un cuadro con la duración borrosa del

proyecto y se le ofrece uno de los seis métodos de

desborrosificación si lo desea, para desborrosificar la información


- 177 -

de todo el proyecto. La desborrosificación de cada duración no

afectará al resto. Por tanto los datos obtenidos para el diagrama

de Gantt pueden no ser realistas. En caso de cerrar la ventana o

presionar cancelar se dejan los datos como borrosos en la

aplicación cliente.

Ilustración 12.2 – Opciones de desborrosificación tras una opción de solución sin desborrosificación


- 178 -

13. EJEMPLO DE ENSAYO

Se presenta a continuación un ejemplo de ejecución de la aplicación y

los resultados obtenidos. Como punto de partida se supondrá que tanto el

servidor como la aplicación cliente están abiertos, activos y debidamente

configurados para comunicarse mediante el protocolo con conexión.

El cliente elige la opción de crear un nuevo proyecto presionando

Ctrl+N, seleccionando la fecha de inicio del proyecto (28 de Junio de 2007) y el

número de actividades del cual está compuesto (16 actividades).

Ilustración 13.1 – Selección de la fecha de inicio del proyecto


- 179 -

Ilustración 13.2 – Selección del numero de actividades del proyecto

El usuario posteriormente facilita una duración borrosa o determinista a

cada actividad y un nombre a cada una de ellas.

Ilustración 13.3 – Duración borrosa de la actividad A

Ilustración 13.4 – Datos de la actividad A

Una vez terminada la asignación de los datos inherentes a cada

actividad se procede a la fase de asignación de sucesoras.


- 180 -

Ilustración 13.5 – Selección de actividades sucesoras de la actividad A

Cuando el usuario presiona el botón de “terminado”, se genera la

siguiente tabla que recoge la información de cada actividad introducida.

Ilustración 13.6 – Tabla de actividades del proyecto

El usuario desea conocer la duración prevista del proyecto entero y

presiona la opción de solucionar el diagrama de red borrosamente en la fase


- 181 -

hacia delante. Dando como resultado la siguiente duración y las opciones de

solución para la fase hacia atrás del método del camino crítico si así lo

deseara.

Ilustración 13.7 – Duración borrosa del proyecto y opciones de desborrosificación

El usuario cierra la ventana y se dispone a determinar el camino crítico

del proyecto mediante dos técnicas de desborrosificación: el centro de área que

recoge el 60% de probabilidad desde la izquierda y un α -corte pesimista a 0.1.

Ambas soluciones se mostrarán en un diagrama de Gantt ordenado por fecha

de inicio de las actividades. El diagrama de red de actividades no contiene

ninguna actividad ficticia.

Para el centro de área al 60% los datos resultantes son los siguientes:


- 182 -

Ilustración 13.8 – Selección de centro de área con parámetro 60% desde la izquierda

Ilustración 13.9 – Orden del diagrama de Gantt por fecha de inicio de la actividad

Ilustración 13.10 – Tabla de actividades resuelta con centro de área con parámetro del 60%

Ilustración 13.11 – Tabla de etapas resuelta con centro de área con parámetro del 60%


- 183 -

Ilustración 13.12 Diagrama de Gantt ordenado cronológicamente con centro de área y parámetro 60%

Como puede observarse en los resultados el camino crítico del

proyecto pasa por las actividades C, H, F, J y O. Se marcan en color rojo en la

tabla de actividades y en el diagrama de Gantt aparecen sin margen libre ni

margen total.

Por otra parte la tabla de etapas muestra consistencia con los datos

anteriormente mencionados dando como etapas del camino crítico 1-4-3-5-8-10

que aparecen resaltadas en rojo. El diagrama de Gantt muestra como fecha

final del proyecto el 2 de Agosto a las 16:20 que es el resultado de sumar


- 184 -

35.6817 días (duración final resultante del proyecto con centro de área con

parámetro 60% desde la izquierda) a la fecha inicial del proyecto que era el 28

de junio. El usuario guarda los datos en el archivo proyecto-COA-60.pert y

continúa solucionando el proyecto con una valoración pesimista.

Para un α -corte pesimista a 0.1 (será una valoración pesimista al 90%)

los datos resultantes son los siguientes:

Ilustración 13.13 – Selección de valoración pesimista con α-corte 0.1

Ilustración 13.14 – Orden del diagrama de Gantt por fecha de inicio de la actividad

Ilustración 13.15 – Tabla de actividades resuelta con valoración pesimista con α-corte 0.1


- 185 -

Ilustración 13.16 – Tabla de etapas resuelta con valoración pesimista con α-corte 0.1

Ilustración 13.17 Diagrama de Gantt ordenado cronológicamente con valoración pesimista y α-corte 0.1


- 186 -

Como puede observarse en los resultados el camino crítico del

proyecto pasa por las actividades C, H, G, L y P. Se marcan en color rojo en la

tabla de actividades y en el diagrama de Gantt aparecen sin margen libre ni

margen total.

Por otra parte la tabla de etapas muestra consistencia con los datos

anteriormente mencionados dando como etapas del camino crítico 1-4-3-6-9-10

que aparecen resaltadas en rojo. El diagrama de Gantt muestra como fecha

final del proyecto el 8 de Agosto a las 8:00 que es el resultado de sumar 41.335

días (duración final resultante del proyecto con valoración pesimista y α-corte

0.1) a la fecha inicial del proyecto que era el 28 de junio. El usuario guarda los

datos en el archivo proyecto-PES-0,1.pert y termina la ejecución del programa.

Como se ha visto en los ejemplos los caminos críticos resultantes para

cada método de solución son diferentes. El camino crítico varía de ser el

conjunto de actividades C, H, F, J y O (primera opción) a ser C, H, G, L y P

(segunda opción). La duración del proyecto varía en seis días más para la

segunda opción. Esto es causado por el extremo al que se ha llevado el α -

corte de la segunda opción. Con un α -corte de 0.2 se habría obtenido la

misma ruta crítica al igual que con la mayoría de opciones de solución. En este

ejemplo concreto se ve que las actividades C y H pertenecen al camino crítico

siempre, lo que obliga a prestarlas más atención que a las demás dentro del

proyecto. Si se hubieran realizado más pruebas se habría determinado que en

el 90% de los casos la ruta crítica es la formada por las actividades C, H, F, J y

O, variando hasta ± 4 días la fecha de finalización del proyecto.


- 187 -

14. PLANIFICACIÓN

La planificación de las tareas a lo largo del proyecto se presenta en el

siguiente diagrama realizado con la aplicación diseñada:


- 188 -

El listado de tareas por orden de aparición en el diagrama es:

1) Estudio de PERT/CPM

Las tareas más importantes realizadas en esta fase son:

a) Estudio del método CMP:

Tarea en la que se asimilaron los conceptos necesarios para la

realización de los diagramas de red. Esta fase comprende también el estudio

de las normas de construcción, la fase hacia delante y la fase hacia atrás del

método del camino crítico.

b) Estudio del método PERT:

Tarea en la que se aprendieron los aspectos importantes de las

tecnologías a utilizar. Se realizó el estudio de los varios supuestos en los que

PERT intenta corregir el error de una actividad de duración conocida

suponiendo que la duración de la actividad es una variable aleatoria,

incluyendo valoraciones de tiempo optimistas, pesimistas y normales.

2) Estudio de los números borrosos

Tarea en la que se asimilaron los conceptos necesarios para el

tratamiento de números borrosos. Esta fase comprende también el estudio de

los diferentes tipos de duraciones borrosas que contendría la aplicación

(intervalo constante, piramidal y trapezoidal).


- 189 -

3) Identificación de necesidades

Fase de la planificación en la que se identificaron las necesidades que

la aplicación debía satisfacer. Algunas tareas importantes realizadas en esta

fase son: recopilación de información y entrevistas con expertos.

4) Análisis funcional y estructural

Fase que constituye el punto de partida en la elaboración del análisis

del sistema que identifica los requerimientos de información de los usuarios.

Estos requerimientos específicos del sistema sirven como punto de referencia

básico para validar el sistema final, es decir, comprobar que el sistema se

ajuste a las necesidades del usuario. Antes de realizar esta fase se ha

intentado comprender cuáles son los elementos del contexto correspondiente y

cómo afectan al desarrollo.

En esta fase se realizó un estudio profundo de las acciones que debe

realizar la aplicación. Se analizó la información teniendo en cuenta los objetivos

del proyecto y los recursos disponibles.

5) Diseño de casos de uso y diseño

Fase en la que se recogen los casos de uso que la aplicación ha de

satisfacer y cómo implementarlos. Es caracterizada por la creación de

esquemas que muestren los casos de uso a realizar y su descripción. La fase

de diseño se inicia conociendo la potencia del software elegido. Se realizó un

diseño que intenta cubrir la totalidad de las necesidades del sistema. Para


- 190 -

llevar a cabo esta fase, se han utilizado diferentes representaciones gráficas de

software.

Por lo tanto, en esta fase se ha realizado el proceso completo de

creación de diagramas y explicaciones necesarios para diseñar la aplicación.

Se comenzó realizando la identificación de los casos de uso y sus

correspondientes descripciones. Posteriormente se realizaron el diagrama de

paquetes y el diagrama de estados.

En esta misma fase se distinguieron los dos módulos en los que

consiste la aplicación y sus funciones y descripción. Por último se crearon los

bocetos del diseño visual de la aplicación, teniendo en cuenta que

posteriormente dichos esquemas podrían sufrir alguna modificación. Tanto el

estudio del software como su diseño, han sido revisados a lo largo del

proyecto.

6) Creación del Motor de Resolución

Una vez se realizó el diseño completo del algoritmo de resolución se

implementaron las diferentes formas de realizar la solución a los proyectos

creados por el usuario. En esta etapa se realizó la programación de los

submódulos de los que consta el motor de resolución.

7) Creación de la Aplicación Cliente

Una vez se realizó el diseño completo de la aplicación y basándose en

los productos que originó se pasó a efectuar el desarrollo de la misma. En esta


- 191 -

etapa se realizó la programación de los submódulos de los que consta la

aplicación.

8) Comunicaciones Cliente-Servidor

En esta etapa se diseñó el protocolo a nivel de aplicación así como las

pruebas pertinentes para su óptimo funcionamiento. También se fue

concluyendo y optimizando los parámetros de la conexión y su salvaguardado

tanto por el motor de resolución como por la aplicación cliente.

9) Realización de pruebas

Una vez finalizada la etapa de desarrollo ya se pudo comenzar esta

etapa en la que se realizaron los ensayos de software para comprobar el

correcto funcionamiento de la aplicación. La finalidad de esta etapa fue

encontrar los fallos cometidos en la fase de desarrollo para su posterior

corrección.

10) Redacción de la memoria

Última etapa en la que se ha unificado y redactado la información

relevante del desarrollo del proyecto. La recopilación y generación de

información ha sido una etapa constante del proceso, no obstante, en esta

última fase, se ha realizado una memoria completa del desarrollo del proyecto.


- 192 -

15. ESTUDIO ECONÓMICO

El objeto del presente proyecto es la creación de un sistema capaz de

solucionar una red de actividades con duraciones borrosas. Los costes

asociados al mismo serán únicamente todos los relacionados con la tarea de

programación del software necesario para el mismo, el programa y las

necesidades que esta tarea requiera.

15.1 RECURSOS UTILIZADOS

Podemos dividir en dos clases los recursos empleados en el desarrollo

del presente proyecto: recursos de hardware y recursos de software.

Dentro de los recursos consideramos como hardware contaremos:

Ordenador ADL, con microprocesador Pentium VI 2.4GHz, 512

MB de memoria RAM y 80 GB de capacidad de disco duro.

Cable de red RJ-45 de 3m.

Router inalámbrico ADSL 802.11b/g de 54Mbps.

Conexión a Internet a 5Mbps.

Los recursos que consideraremos como software, serán:

Sistema operativo Windows XP Profesional SP2.

Java Runtime Environment Version 6 Update 2

Entorno de desarrollo Eclipse-SDK-3.1.1.


- 193 -

Banco de trabajo MyEclipse 5.0.

Aplicaciones ofimáticas del paquete Office 2003.

Herramienta de diseño UML 1.4 Jude Community

15.2 COSTES DEL PROYECTO

La división de los costes totales del proyecto se realizará en dos

partidas diferenciadas:

Costes directos.

Costes indirectos.

Dentro de la partida de costes directos, haremos una segunda división

de los costes según:

Costes de personal.

Costes de amortización de programas y equipos.

Costes de material.

15.2.1 COSTES DE PERSONAL

Para la realización del cálculo del coste de personal se supondrá que el

proyecto está desarrollado por un Ingeniero Informático trabajando para el

Departamento de Organización Industrial de una empresa.

El sueldo correspondiente se considera un gasto efectivo por parte de

dicho departamento, dentro del cual se tienen en cuenta:


- 194 -

Sueldo bruto

Incentivos

Vacaciones

Seguridad Social

Obtenemos el coste de personal teniendo en cuenta el número de

horas empleadas y el coste efectivo de cada hora de trabajo.

Horas anuales estimadas:

Concepto Días

Días medios por año

Sábados y Domingos

Días de vacaciones efectivos

Días de petición extraordinarios

Total días hábiles

365,25

-104,36

-15

-20

210,89

Jornada laboral 8 horas/día

Total horas efectivas anuales 1.687,12

Coste anual de un Ingeniero Informático:

Concepto Euros

Sueldo neto e incentivos

Prestaciones a la Seguridad Social

30.050,60

12,020,24

Coste anual 42.070,84


- 195 -

El coste por hora de trabajo de un Ingeniero Informático se calcula con

los datos obtenidos en las dos tablas anteriores, dividiendo el coste anual entre

el total de horas efectivas anuales. Este coste será por tanto de 24,93 €/hora.

Calculamos ahora el número de horas que se han empleado en la

realización del presente proyecto. Se realiza una descomposición detallada de

las mismas en la siguiente tabla:

Concepto Horas

Estudio de planificación de proyectos

Estudio números borrosos

Diseño de la aplicación

Desarrollo de los módulos

Pruebas

Documentación

100

50

175

225

50

50

Total horas 650

Obtenemos el coste de personal multiplicando las horas totales

empleadas en el proyecto por el coste de cada hora de trabajo, el resultado nos

da el coste de personal y asciende a 16208,71€.

15.2.2 COSTES DE AMORTIZACIÓN DE PROGRAMAS Y EQUIPOS

Vamos a considerar una amortización lineal a cuatro años para el

cálculo de los costes de amortización de los equipos informáticos y sus

programas. En la siguiente tabla aparecen detallados estos costes para cada

uno de los distintos conceptos.


- 196 -

Concepto Euros

Hardware

Sistema Operativo

Aplicaciones ofimáticas

2000,00

270,20

330,30

Total sin IVA 2600,50

IVA (16%) 416,08

Total coste amortización 3016,58

Tanto el leguaje de programación como el compilador y resto de

librerías utilizados son recursos de software libre o código abierto y su coste es

nulo por lo que su coste de amortización también lo será.

El tiempo de uso de los equipos es el tiempo total calculado

anteriormente para el desarrollo de la aplicación, puesto que es necesario tanto

en las etapas de diseño previo como en el desarrollo de la aplicación.

A continuación se calcula el índice de amortización por hora de trabajo

dividiendo el coste total de amortización de programas y equipos entre el

número de horas efectivas de trabajo en cuatro años. Es resultado es por lo

tanto 0,448 €/hora.

Se multiplica ese factor por el número de horas que ha llevado

desarrollar este proyecto teniendo como resultado un coste de 290,55 €.

15.2.3 COSTES DE MATERIAL

Se reflejan en la siguiente tabla los costes relacionados con los

materiales necesarios para el estudio y desarrollo del proyecto y aquellos

asociados a su presentación.


- 197 -

Concepto Euros

Libros de apoyo

Papel

Fotocopias y encuadernación

30,30

30,05

50,70

Total sin IVA 111,05

IVA (16%) 17,768

Total 128,818

Se resumen a continuación, en una tabla los costes directos del

proyecto y su total:

Concepto Euros

Costes personal

Costes de programas y equipos

Costes de material

16204,5

290,55

128,818

Total costes directos 16623,87

15.2.4 COSTES INDIRECTOS

Incluimos en este apartado aquellos gastos producidos en la

elaboración del proyecto que no pueden ser incluidos en apartados anteriores.

Concepto Euros

Consumo eléctrico equipos

Iluminación

Gastos administrativos

210,35

180,30

90,15

Total costes indirectos 480,80


- 198 -

15.3 COSTE TOTAL DEL PROYECTO

El coste total del presente proyecto es el resultante de sumar los costes

directos e indirectos ocasionados por el desarrollo del mismo.

Concepto Euros

Total costes directos

Total costes indirectos

16623,87

480,80

Total costes proyecto 17104,67


- 199 -

16. CONCLUSIONES Y LÍNEAS FUTURAS

Para el diseño del algoritmo que permite resolver los proyectos se han

hecho pruebas con diferentes tipos de duraciones. Mediante estas pruebas se

ha intentado dotar a la aplicación de la máxima robustez para permitir el

funcionamiento con un gran número posibilidades. Por lo tanto, este objetivo

del proyecto se ha conseguido.

Por otra parte se proporciona solución a cualquier tipo de red de

actividades tanto si no incluye ninguna duración borrosa como si incluye

alguna. Manipulando los parámetros de desborrosificación se puede comprobar

cómo varía el camino crítico del proyecto para cada uno de los diferentes

métodos de resolución implementados.

En la aplicación se garantiza en todo momento el salvaguardado de la

información así como la consistencia de los datos introducidos por el usuario.

Para la ayuda a la compresión de los resultados se proporcionan gráficos

explicativos durante todo el proceso de desarrollo de la red y al mostrar su

solución.

El proyecto no sólo constituye un acercamiento a varios métodos de

resolución de proyectos con actividades con duraciones borrosas, sino que se

puede plantear la integración del tratamiento de duraciones aleatorias descritas

por diversos tipos de funciones de probabilidad (funciones triangulares,

procesos de Poisson, distribuciones normales, distribuciones Beta, etcétera)

como un módulo más. También cabe la posibilidad de incrementar métodos de


- 200 -

desborrosificación más avanzados y de implementación más laboriosa como el

método de “el indicador de valor de Delgado”.

El paso siguiente al presente proyecto podría ser el seguimiento de los

proyectos introduciendo los datos del porcentaje de actividad realizada hasta la

fecha actual para la ayuda en la toma de decisiones.

El trabajo realizado es capaz de generar tres tipos de informes

(actividades, etapas y actividades ficticias o dummy). Sería muy interesante la

posibilidad de ofrecer al usuario experimentado un módulo para el desarrollo

gráfico de un diagrama de red a partir de etapas (en forma circular) y

actividades (en forma de flechas unidireccionales). De esta manera se podría

llegar a obtener un sistema que genere la solución más rápidamente dado que

el motor de resolución no tendría que obtener el diagrama de red y más visual

enfatizando el camino crítico y rellenando las duraciones en el mismo

diagrama.

Se recuerda que, dado el diseño de la aplicación, la precisión de los

resultados generados está íntimamente relacionada con la opción de resolución

que se seleccionó en la aplicación debido a que para generar un resultado

plausible la aplicación requiere una desborrosificación de las duraciones.


- 201 -

17. BIBLIOGRAFÍA [GIL_99] Gil-Aluja, J. (1999). “Elements for a theory of decisition in

uncertainty”. Boston, London, Dordrecht: Kluwer Academic

Publishers, (versión española de Ed. Milladoiro).

[GIL_98] Gil-Aluja, J. (1998). “Investment in uncertainty”. Boston,

Dordrecht, London: Kluwer Academic Publishers.

[GIL_97] Gil-Aluja, J. (1997). “The interactive management of the human

resources in uncertainty”. Dordretch, The Netherlands: Kluwer

Academic Publishers.

[KAUF93] Kaufmann, A. y Gil-Aluja, J (1993). “Técnicas especiales para la

gestión de expertos”. Santiago de Compostela, España: Ed.

Milladoiro.

[KAUF71] Kaufmann, A. (1971). “Introducción a la combinatoria y sus

aplicaciones”. Barcelona, España: Ed. C.E.C.S.A.

[KAUF86] Kaufmann, A. y Gil-Ajula, J. (1986). “Introducción de la teoría de

los subconjuntos borrosos a la gestión de las empresas“.

Santiago de Compostela, España: Ed. Milladoiro.

[KAUF95] Kaufmann, A. y Gil-Aluja, J. (1995). “Grafos neuronales para la

economía y la gestión de empresas“. Madrid: Ed. Pirámide.

[KAUF91] Kaufmann, A. y Gil-Aluja, J. ((1991). “Selection of affinities by

means of fuzzy relations and Galois lattices“. Actas del Euro XI

Congress. O.R. Aachen: 16-19 julio.

[KAUF92] Kaufmann, A. y Gil-Aluja, J. (1992). “Técnicas de gestión de

empresa. Previsiones, decisiones y estrategias“. Madrid: Ed.

Pirámide.

[KAUF93] Kaufmann, A. y Gil-Aluja, J. (1993). “Técnicas especiales para la

gestión de Expertos“. Santiago de Compostela, España: Ed.

Milladoiro.


- 202 -

[MATE03] Mateos Perera, Jesús. (2003). “La programación en la

construcción. El PERT en versión completa”. (2ª edición ampliada

y revisada). BELLISCO, Ediciones Técnicas y Científicas.

[POMA77] Pomares Martínez, Juan. (1977). “Planificación gráfica de obras.

Gantt – C.P.M. – P.E.R.T. – Roy...”. Editorial Gustavo Gili, S.A.

Barcelona.

[ROME83] Romero López, Carlos. (1983). “Técnicas de Programación y

Control de proyectos”. (2ª edición corregida). Ediciones Pirámide,

S.A. Madrid.

[SANT99] Santana, Gerardo. (1999). “Planificación y control de Proyectos”.

ROJAS EBERHARD Editores Ltda.

[AREN00] Arenas Reina, José Manuel. (2000). “Control de tiempos y

productividad”. PARANINFO.

[LOCK90] “Gestión de Proyectos“. Dennis Lock. Paraninfo. 1990

[PERA91] “Dirección y Gestión de Proyectos“. Jaime Perá Brand Díaz de

Santos. 1991

[COMP88] “Planificación y Rentabilidad de Proyectos Industriales“ Ramón

Compays Pascual, Albert Corominas Subías Marcombo (Serie

Productiva). 1988

[YUE_89] “Aplicaciones Prácticas del PERT/CPM“ Luis Yue Chuen-Tao

Deusto. 1989

[PRAD88] “Administración de Proyectos con PERT/CPM“. Darci Prado

Paraninfo. 1988Paraninfo. 1988

[BARR01] Barranco, J. “Metodología del análisis estructurado de sistemas”.

ISBN: 84-8468-043-6. Sal Terrae. 2001.

[ARMS05] Armstrong, E., Ball, J., Bodoff, S., Carson, D., Evans, I., Green,

D., Haase, K., Jendrok, E. “The J2EE 1.4 Tutorial”. Sun Java

System Platform Edition. 2005.


- 203 -

[HERB07] Herbert, S. “Fundamentos de Java”. ISBN: 9-70-105930-1.

McGraw-Hill. 2007.

[KOLL07] Kolling, M., Warnes, D. “Programación orientada a objetos con

java” ISBN: 8-48-322350-3. Prentice-Hall. 2007.

[ZADE65] Zadeh, L. (1965). Fuzzy Sets. “Information and Control“, vol. 8,

june.

Documents

ANÁLISIS DE UNA RED DE ACTIVIDADES CON · PDF fileenfatizando la ruta crítica del proyecto. ... 2.5 EL MÉTODO CPM ... 2.6.1 TIEMPOS DE ESTIMACIÓN DE ACTIVIDAD