1

Funciones de un Ingeniero de Software

identificar sus necesidades.

los correctos.

que incluya fuentes de informacin, mdulos

de procesamiento de informacin, y
resultados esperados.

Realizar el anlisis de los requisitos.

ramas de la arquitectura.

Determinar las necesidades esenciales y no

esenciales, as como las que son de
segundo nivel.
Impedir la introduccin de defectos
tempranamente en la construccin del
sistema.
Construir el documento de requisitos de
usuarios.

Establecer una estructura bsica inicial del

sistema.
Establecer interacciones, interrelaciones y
sus contextos en dicha estructura.
Definir la especificacin de la arquitectura
del sistema, en forma de un documento
tcnico

Anlisis de Requerimientos.
1.-La obtencin de requisitos consiste en capturar el propsito y funcionalidades del sistema
desde la perspectiva del usuario. Las tcnicas para esta tarea son: Entrevistas, Escenarios,
Prototipos, Reuniones de Grupo, Observacin.
Las fases de una entrevista son: planificacin, preparacin, inicio, desarrollo, cierre y conclusiones.
Los casos de uso no son nicamente exclusivos al modelado de requisitos, ya que inicialmente fue
ideado para la captura de requisitos funcionales de un sistema, hoy en da se aplica en otros
mbitos de la ingeniera de software.
2.-El anlisis de requisitos es el proceso de estudiar las necesidades del usuario para obtener una
definicin detallada de los requisitos.
El modelo conceptual que tiene como objetivo fundamental facilitar la comprensin de los
requisitos, mediante su presentacin en un lenguaje o notacin que comprendan quienes van a
trabajar con los requisitos.
Notaciones del modelado conceptual.
a) La notacin de Casos de Uso de UML, es la ms utilizada para el modelado y captura de
requisitos funcionales. Consta de Actor, Caso de Uso, Escenarios, Relaciones y una
Representacin detallada.
b) Modelos entidad-relacin.
c) Diagramas de clases UML.
d) Notaciones formales.

2
3.-Se denomina especificacin de requisitos al proceso de documentar el comportamiento
requerido de un sistema de software. A menudo utiliza una notacin de modelado u otro lenguaje
de especificacin.
4.-La validacin de requisitos consiste en examinar los requisitos para asegurarse de que definen
el sistema que el cliente y los usuarios desean.
Para la validacin de requisitos se tienen varios mtodos, los cuales son:
a.- Revisin de requisitos.- Un grupo de personas revisa los documentos de requisitos en
busca de inconsistencias, malentendidos, puntos poco claros o conflictos entre requisitos.
Como resultado se elabora y publica una lista de problemas y posibles soluciones.
b.- Prototipado.- El desarrollo de un prototipado constituye una inmejorable forma de
probar cualquier producto. Un prototipo es un modelo fcilmente ampliable y modificable
de un sistema de software, donde se muestran su interfaz y las funcionalidades de
entrada-salida ms relevantes.
c.- Validacin de modelado.- Sirve para verificar si el modelo es consistente y se refleja
adecuadamente los requisitos reales del sistema.
d.- Pruebas de aceptacin.- Consiste en la elaboracin de un plan, que establece cmo
deben ser verificados los diferentes requisitos.
Se puede crear una matriz de seguimiento, la cual es una tabla de donde se relacionan dos
documentos, probablemente de dos etapas distintas de desarrollo. Lo anterior es para seguir la
pista de los requisitos a lo largo del desarrollo, fundamentalmente en el diseo, plan de pruebas y
casos de prueba, en cuyo caso recibe el nombre de Matriz de Seguimiento de Requisitos.
5.- Otros elementos del anlisis de Requerimientos.
Se denomina actor a un rol perfectamente definido que una persona puede desempear en el
Proceso de requisitos.
a. Usuarios.- Se trata de un grupo heterogneo que comprende a todos aquellos que operan
el software.
b. Clientes.-Todos aquellos que tienen inters en adquirir el software o representan de algn
modo al mercado potencial al que se dirige el software.
c. Analistas de mercado.- Personas especializadas en recabar las posibles necesidades del
mercado obteniendo requisitos a travs de los posibles clientes potenciales.
El documento de especificacin de requisitos de software contiene un conjunto exhaustivo y
preciso de requisitos, modelados de un lenguaje de especificaciones y validados, los cuales
sirven como contrato entre lo que desea el cliente y lo que los desarrolladores se
comprometen a construir.

3
Existen dos tipos de requisitos Funcionales y No funcionales.
Un requisito funcional define una funcin que un sistema o componente de sistemas debe ser
capaz de llevar acabo. Ejemplos:
Imprimir contratos de alquiler, almacenar la informacin relativa a los contratos de alquiler,
guardar informacin de pagos y ventas, realizar el seguimiento por cliente del estado de
pagos, etc.
Un requisito No funcional son aquellos que especifican aspectos tcnicos que debe incluir el
sistema y que pueden clasificarse en restricciones y calidades. Ejemplos:
El sistema debe estar disponible el 95% de tiempo en un periodo de 24 horas, el desarrollo
debe regirse por procesos y actividades definidos por la metodologa de la Administracin
Pblica Espaola, el registro de datos debe cumplir con la Ley Orgnica Espaola.

Modelos de Procesos
Los modelos prescriptivos del proceso de software se han aplicado durante muchos aos en un
esfuerzo encaminado a ordenar y estructurar el desarrollo de software.
A) El modelo en cascada sugiere una progresin lineal del marco de trabajo que a menudo
resulta inconsistente con la realidad moderna en el mundo del software (por ejemplo, el
cambio continuo, los sistemas de evolucin, las fechas de entrega restringidas). Entonces
el modelo se puede aplicar en las situaciones en las cuales los requisitos estn bien
definidos y son estables.
B) Desarrollo rpido de aplicaciones est diseado para proyectos grandes que se entregan
en marcos de tiempo reducido.
C) Los modelos incrementales producen software como una serie de entregas.
D) Los modelos evolutivos reconocen la naturaleza evolutiva de la mayora de los proyectos
de Ingeniera de software y estn diseados para ajustarse al cambio
E) El modelo de prototipos y el de espiral generan productos de trabajo incrementales con
rapidez. Y se adaptan para aplicarlos desde el desarrollo hasta el mantenimiento del
sistema.
F) Modelo basado en componentes destaca la reutilizacin y ensambladura de los
componentes
Segn Bennatan, hay cuatro tipos de componentes:

1. Componentes ya Desarrollados.- Se adquiere de un tercero o de desarrollo

internamente para un proyecto previo y que han sido ampliamente validados.

4
2. Componentes Experimentados.- Especificaciones, diseo, cdigo o datos de
prueba existentes que se desarrollan para proyectos previos o similares. Los
miembros del equipo tienen experiencia en dicho componente
3. Componentes con Experiencia Parcial.- Especificaciones, diseo, cdigo o
datos de prueba existentes que se desarrollan para proyectos previos que
requieren modificaciones sustanciales y que cuentan con experiencia limitada.
4. Componentes nuevos.- El equipo de software debe crear o construir nuevos
componentes de software.
El proceso unificado de un proceso de software guiado por los casos de uso, de arquitectura
cntrica, iterativo e incremental. El proceso unificado se define con 5 fases:
1- Una fase de inicio.
Comunicacin con el cliente, actividades de planeacin, desarrollo y refinamiento de casos
de uso.
2- Una fase de elaboracin. Comunicacin con el cliente, actividades de modelado con un
enfoque de la creacin de modelos de anlisis y diseo.
3- Una fase de Construccin. Refina y traduce el modelo de diseo de componentes de
software implementados.
4- Una fase de transicin. Transfiere el software del desarrollador al usuario final para
realizar las pruebas beta y obtener la aceptacin.
5- Una fase de Produccin en la cual se realiza el monitoreo continuo y el soporte

Diseo
Antes de que el diseo y la construccin de un sistema basado en computadora quedan comenzar,
es necesario entender los requisitos.
Los miembros del equipo de software realizan 7 funciones distintas dentro de la ingeniera de
requisitos: Inicio, Obtencin, Elaboracin, Negociacin, Especificacin, Validacin y Gestin.
La elaboracin posterior expande los requisitos hacia un modelo de anlisis, es decir, una
coleccin de elementos del modelo basado en escenarios, en actividades y clases, de
comportamiento y orientados al flujo.
Objetivo:
Las herramientas para el modelado del anlisis proporcionan la capacidad de desarrollar modelos
basados en escenarios, modelos basados en clases y modelos de comportamiento mediante la
notacin UML.
El objetivo del modelado de anlisis es crear una variedad de representaciones que muestren los
requisitos del software para la informacin, funcin y el comportamiento, esto se logra
implementando dos filosofas de modelado, el Anlisis estructurado y el Anlisis orientado a
objetivos.

5
El anlisis estructurado considera al software como un transformador de informacin, que ayuda
al ingeniero de software a identificar los objetivos de datos, sus relaciones y la manera en la cual
estos objetivos de datos se transforman mientras fluyen a travs de las funciones de
procesamiento del software.
El Anlisis orientado a objetivos examina un dominio de problema definido como un conjunto de
casos de uso en un esfuerzo para extraer clases que definen el problema. Cada clase tiene un
conjunto de atributos y operaciones.
El modelo de anlisis lo componen 4 elementos: Modelos Basados en Escenarios, de Flujo,
Basados en Clases y Basados en Comportamiento

M. B. Escenarios
Muestran los
requisitos del
software desde el
punto de vista
usuario

M. B. en Flujo
Se enfoca en el flujo de
objetivos de datos
conforme a las funciones
de procesamiento que los
transforman.
Los modelos de flujo se
derivan del anlisis
estructurado

El caso de uso - Una

descripcin
narrativa basada en
una plantilla de una
interaccin entre un
actor y el software.

Diagrama de Flujo de
Datos. Muestra la
manera en que una
entrada se transforma en
una salida conforma a los
objetivos de datos se
mueven a travs del
sistema.
Los nodos representan
procesos, los vrtices las
entradas y salidas a los
mismos. Los diagramas
de Flujo de Datos pueden
descomponerse en subdiagramas hasta llegar al
nivel de granularidad.
Los sustantivos son
entidades externas
(cajas), objetos de datos
o de control (flechas) o
almacenamiento de datos

El caso de uso
derivado durante la
obtencin de
requisitos define los
casos clave para la
funcin o
interaccin
especifica; pero el
resultado final
proporciona la
entrada necesaria a
las otras actividades
del modelado de
anlisis.

M. B. en Clases
Utiliza informacin
derivada de elementos
de modelo orientado al
flujo y basado en
escenarios para extraer
clases candidatas,
atributos y operaciones
de las narrativas
basadas en texto.

M. B. en Comportamiento
Utiliza la entrada de los
elementos basados en
escenarios y basados en
clases para representar los
estados de las clases de
anlisis y del sistema como
un todo. Esto se logra
identificando los estados,
definiendo los eventos que
ocasionan que una clase
tenga una transicin
Los paquetes de
Diagramas de Secuencia
anlisis - se utilizan para Indica cmo los eventos
categorizar y agrupar
causan transiciones de un
clases de manera que
objeto a otro, se puede
sean manejables para
decir que es una versin
los sistemas grandes.
corta de los casos de uso

Diagrama de
Actividad es una
representacin
grfica del tipo de
un diagrama de flujo
que muestra el flujo
del procesamiento
dentro de un
escenario especifico.

Diagramas de Carril
- ilustra la forma en
que el flujo de
procesamiento
incumbe a varios
actores o clases.

(lneas dobles).
Este elemento de
modelado tambin
muestra el flujo de
control (representacin
que ilustra la forma en
que los eventos afectan el
comportamiento del
sistema).

Diagramas de ClaseEs un conjunto de clases

y la relaciones entre
ellas, las cuales
permiten modelar
cualquier entidad
mediante la
enumeracin de sus
caractersticas que
pueden ser estticos
(atributo) o dinmicos
(mtodos).
Modelos CRC(Clase Responsabilidad
Colaborador )
Puede usarse en la
definicin de relaciones
entre las clases.
Adems aplica una
variedad de notaciones
del modelado UML,
para definir jerarquas,
relaciones,
asociaciones,
agregaciones y
dependencias entre
clases.

Diagramas de EstadoRepresenta los estados

activos para cada clase y
los eventos (disparadores)
que ocasionan cambios
entre estados activos

El flujo de informacin durante el diseo de software depende de la transformacin del modelo de

anlisis en un modelo de diseo. La tarea de diseo produce un diseo de Datos-clase, un Diseo
arquitectnico, un diseo de Interfaz y un diseo de Componentes

Elementos del diseo de datos.Al igual que otras actividades de la ingeniera de software, el diseo de datos crea un modelo de
datos algunas veces llamado tambin como Arquitectura de Datos.

8
Al nivel de abstraccin, la traduccin de un modelo de datos a una base de datos es esencial para
alcanzar los objetivos de negocio del sistema.
Tenemos tipos de mtodos para el diseo.
Mtodos estructurado.- Se basan en la aproximacin descendente (top-down) que aboga por
descomponer el sistema completo en niveles funcionales desde la perspectiva global completa
hasta el nivel de detalle necesario para su implementacin. Las caractersticas ms importantes
de este modelado son la descomposicin funcional, el modelado de datos y la representacin del
flujo de informacin. Entre las tcnicas ms comunes se tiene.
A)
B)
C)
D)

Diagramas de flujo de datos.

Diagramas entinad-relacin.
Diccionario de datos.
Diagramas de estructura.

Mtodos orientados a objetos.

En UML los diagramas estn clasificados en dos grupos:
a) Diagramas de estructura.- Reflejan la estructura fsica del sistema por medio de sus clases,
mtodos, atributos, interfaces, paquetes, etc. Y sus relaciones.
b) Diagramas de comportamiento.- Muestran la forma en los distintos elementos del sistema
interaccionan, colaboran y cambian de estado durante la ejecucin del sistema para
proveer la funcionalidad requerida.
Los diagramas de UML son:
1.
2.
3.
4.

5.
6.
7.
8.

Diagramas de casos de uso

Diagrama de clases
Diagrama de componentes
Diagrama de iteracin
a. Diagramas de secuencia
b. Diagrama de comunicacin
Diagrama de estado
Diagramas de despliegue
Diagramas de actividad
Diagramas de paquete.

Pruebas
El objetivo principal del diseo de casos de prueba consiste en derivar un conjunto de pruebas
que tenga la mayor probabilidad de descubrir errores en el software.
Un caso de prueba es un conjunto de entradas, condiciones de ejecucin y resultados esperados
que han sido desarrollados para un objetivo particular.

9
Un fallo es un efecto indeseado en las funciones o prestaciones desempeadas por un software.
Se domina error o defecto a una imperfeccin en el software que provoca un funcionamiento
incorrecto del mismo.
Se puede emplear dos categoras: Las pruebas de caja blanca y las pruebas de caja negra.
a) Las pruebas de caja blanca se concentran en la estructura del control del programa, los
casos de prueba se derivan para asegurar que todas las instrucciones del programa se
ejecuten por lo menos una vez durante la prueba y que todas las condiciones lgicas se
ejerciten.
b) Las pruebas de caja negra. Los casos de prueba se basan en el comportamiento de la
entrada y la salida de datos
Las pruebas del sistema se enlistan a continuacin:
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)

Pruebas de funcionalidad y operativa.- Se trata de pruebas de la caja negra.

Pruebas de rendimiento.
Pruebas de aceptacin
Pruebas de instalacin.- Las pruebas de aceptacin comparan el comportamiento de un
mdulo o sistema de software completo con las necesidades del cliente.
Pruebas alfa y beta.
Pruebas de conformidad.
Pruebas de regresin
Pruebas de desgaste.
Pruebas de recuperacin.
Pruebas de configuracin.
Pruebas de usabilidad.- Evalan la facilidad con la que los usuarios utilizan el software,
evala tambin la claridad de la documentacin para el usuario.

Mtricas
Tenemos tres tipos de entidades para medir la Ingeniera de Software.
Productos.- Es cualquier entregable o documento que resulta de cualquiera de las actividades
(procesos) del ciclo de vida del software. El cdigo fuente, las especificaciones de requisitos , los
diseos, el plan de pruebas y los manuales de usuario son algunos productos.

Producto
Especificaciones
Diseo

Atributos Internos
Tamao, reutilizacin
Tamao, acoplamiento, cohesin,
complejidad

Atributos Externos
Calidad, legibilidad
Calidad, complejidad

10
Cdigo

Tamao, complejidad

Casos de prueba

Numero de casos, % de cobertura.

Facilidad de mantenimiento,
fiabilidad
Calidad

Medidas por producto

I Atributos internos
Medidas del tamao del sistema
a. La cuenta de lneas de cdigo.
Los puntos de funcin miden el tamao del software por la cantidad de funcionalidad
que proporcionan a los usuarios (sin considerar al cdigo fuente). Se basan en la cuenta
de entradas, salidas, accesos y modificaciones a las bases de datos y ficheros que se
ponderada por la complejidad de cada uno de ellos. Un ejemplo de mtrica indirecta en
el tamao del software es la densidad de comentarios de un programa.
b. Medidas de complejidad del software
c. Medidas de documentacin
d. Medidas de reutilizacin
e. Medidas de eficiencia
II Atributos externos
a. Modelo de McCall.
b. Modelo Bohem
c. Estndar ISO 9126 y su evolucin ISO 14598.
Medidas por Proceso.- Son todas las actividades del ciclo de vida del software : requisitos ,
diseo, construccin, pruebes, mantenimiento, etc. Y su medicin sirve para ver su estado para
despus mejorarlos

Proceso
Requisitos
Diseo
Diseo

Atributos Internos
Tiempo, esfuerzo, nmero de
requisitos.
Tiempo, esfuerzo, nmero de errores.
Tiempo, esfuerzo, nmero de errores.

Atributos Externos
Calidad, coste, estabilidad.
Calidad, coste, estabilidad.
Calidad, coste, estabilidad.

Existen dos tipos de mtricas:

Las Internas.- Incluyen el tiempo de desarrollo del producto, el esfuerzo y el nmero de
incidencias del desarrollo.
Las Externas.- Incluyen la facilidad de observacin, la estabilidad del proceso o su coste.

11
Ejemplo. CMMI, SPICE, ISO 9000, SIX SIGMA Y COBIT.
Medidas por Recursos.- Cualquier entrada de una actividad. Por ejemplo, el nmero de personas
por actividad o por proyecto, las herramientas utilizadas (para requisitos, compiladores, etc.),
oficinas, computadoras, etc.

Recurso
Personal
Equipos
Software
Hardware

Atributos Internos
Edad, salario
Nmero de personas, estructura del
equipo.
Coste, nmero de licencias.
Marca, coste, especificaciones tcnicas.

Atributos Externos
Productividad, experiencia.
Productividad, experiencia.
Utilidad y factibilidad.
Utilidad y factibilidad.

Existen las siguientes mtricas para recursos:

Medidas de personal
Medicin de las herramientas
Medicin de los materiales
Medicin de los mtodos
Existen tambin metodologas y estndares de medicin.
a.
b.
c.
d.

Mtodo objetivo-pregunta-mtrica
Estndar IEEE 1061-1998
PSM y el estndar ISO/MEC 15939
Estndar ISO/IEC 9126

Existen tambin Estudios Empricos o evaluacin Emprica de mtricas de Ingeniera de Software

los cuales se basan en los siguientes instrumentos:
Entrevistas.- son estudios retrospectivos cuya intencin es documentar relaciones y resultados,
siendo una de las herramientas ms tiles para recabar un buen nmero de datos que
posteriormente sern analizados.
Casos de uso.- Son empleados para identificar y documentar factores clave que pueden afectar
los resultados de una actividad. Investigan por medio de la observacin entornos reales para
contrastar o evaluar datos para descubrir tendencias.
Experimentos formales.- Se emplean para, de forma controlada y rigurosa, investigar aquellos
factores que afecten a las actividades a realizar. Medir el efecto de influencia de una variables
en otras. Un ejemplo es el estudio de que los estudiantes tienen diferentes niveles de

12
comprensin de la lgica de un programa en funcin de la herramienta de presentacin
utilizada. Se demostr con el estudio que los estudiantes prefieren los diagramas de flujo, pues
les ayuda a comprender mejor los programas que el seudocdigo.
Los instrumentos anteriores se utilizan para estudios cualitativos y cuantitativos. Los cualitativos
buscan la interpretacin de un fenmeno en su entorno natural, recabando informacin entre
las persona involucradas. Mientras que los cuantitativos buscan medir la influencia de una
variable en un fenmeno, es decir, la relacin causa-efecto entre ambos.
Ejemplo. La relacin entre la profundidad en la jerarqua de clases en un diseo orientado a
objetos y el nmero de errores en el cdigo de una clase.
Benchmarking implica comparar las prcticas reales o planificadas del proyecto con aquellas de
otros proyectos, a fin de generar ideas para mejorar o para establecer una norma por medio de la
cual medir el desempeo de un proyecto.

Mantenimiento
Tipos de Mantenimiento
1) Mantenimiento correctivo.- Modificaciones reactivas a un producto de software hechas
despus de la entrega para corregir defectos descubiertos.
2) Mantenimiento adaptatitvo.- Modificacin de un producto de software realizada despus
de la entrega para permitir que dicho producto siga en uso en un ambiente diferente.
3) Mantenimiento perfectivo.- Modificacin de un producto de software despus de la
entrega para mejorar el rendimiento o la facilidad de mantenimiento.
Las tcnicas para el mantenimiento de software son:
1) Ingeniera inversa
a) I. inversa de datos.- Se aplica sobre un cdigo de bases de datos para obtener los
modelos relacionales y para obtener el diagrama conceptual.
b) I. inversa de procesos.- Se aplica sobre el cdigo de un programa para extraer su lgica
o obre un documento de diseo para obtener documentos de anlisis o de requisitos.
2) Reingeniera.- Modificacin de un producto de software o de ciertos componentes usando
para el anlisis del sistema existente tcnicas de ingeniera inversa y para la reconstruccin
herramientas de ingeniera directa.
3) Reestructuracin

Calidad
Modelos de Calidad
1) Modelo de calidad de McCall. Tiene una serie de factores que se clasifican de la siguiente
forma:

13
A) Operacin.- correccin, fiabilidad, eficiencia, integridad usabilidad.
B) Revisin.- facilidad de mantenimiento, facilidad de evaluacin, flexibilidad.
C) Transicin.- portabilidad, usabilidad, interoperabilidad.
2) Modelo de Bohm
Utilidad General
Utilidad de cmo est
Facilidad de mantenimiento
Portabilidad
Fiabilidad, Eficiencia,
Facilidad de evaluacin,
Ergonoma
comprensibilidad, Facilidad
para modificar

3) Modelo de calidad de ISO/IEC 9126. Su objetivo es proporcionar tanto una especificacin

de la calidad de productos software como un modelo para su evaluacin. Se divide en
cuatro partes:
1) Modelo de calidad ISO/IEC 9126-1-2001
2) Mtricas externas ISO/IEC TR 9126-2-2003
3) Mtricas internas ISO/IEC TR 9126-3-2003
4) Calidad en las mtricas de uso ISO/IEC TR 9126-4-2004

Otros modelos, estndares y especificaciones relacionados a la calidad en el software.

ITIL, TRILLIUM, BOOTSTRAP, PSP, TSP, TICKIT, SIX SIGMA, SPICE.

La Estimacin de coste, plazos y esfuerzo

En general se puede definir ESTIMACION como el proceso de determinar una variable a partir de
otras conocidas. La Estimacin de coste, plazos y esfuerzo es parte esencial de la Planificacin de
cualquier tipo de proyectos.
Se tiene diferentes mtodos:
A) Estimacin mediante juicio de expertos.
a. Mtodo Delphi.
b. Estimacin de expertos por analoga.
B) Puntos de funcin
a. IFPUG
b. COSMIC
C) Modelos algortmicos o paramtricos.
a. Regresin estadstica. ISLIM, COCOMO
D) Mtodos basados en Inteligencia Artificial.
a. Sistemas basados en reglas.
b. Razonamiento basado en reglas.

14
c. Redes neuronales.
d. Arboles de decisin.
E) Sistemas dinmicos.
F) Evaluacin de modelos.

La Planificacin y seguimientos del proyecto.

Consiste en identificarlas tareas del proyecto, las relaciones entre las tareas (el orden en que
deben ser ejecutadas), asignar los recursos a las tareas y estimar los plazos de ejecucin las tareas.
Tcnicas y mtodos para la planificacin:
A) Estructura de descomposicin del trabajo.
B) Los mtodos grficos CMP (mtodo del camino critico) y PERT (evaluacin y revisin de
proyectos).
C) Diagramas de GANTT. Muestran las evolucin de las tareas con sus fechas e hitos.
D) Mtodo del Valor Conseguido (EVM) Permite hacer el seguimiento del proyecto integrando
informacin de plazos y costes, as como visualizar dicha informacin en una grfica de tres
variables que muestran la evolucin del proyecto.