IPI - Universitat de València · La importancia de la documentación 2. Estructura de un proyecto...

i n f o r m a t i c a . u v . e s

Temario IPI

Bloque 1. Gestión integral de proyectos

Bloque 2. El entorno de dirección en IPI.

Aspectos económicos de un proyecto

Bloque 3. Documentación de un

proyecto. Bases y guía para un Proyecto

Final de Carrera en Ingeniería Informática

Bloque 4. Aspectos jurídicos, profesionales

y éticos de la Ingeniería Informática


Documentación de un proyecto

1. Introducción. La importancia de la documentación

2. Estructura de un proyecto clásico

A. Memoria

B. Planos

C. El pliego de condiciones

D. Presupuesto

Ejemplo: Contenido y estructura de proyectos

3. Documentos en la gestión de proyectos

A. Documentos en la gestión y seguimiento de proyectos

4. El proyecto final de carrera


El Proyecto o Trabajo Fin de Carrera (PFC) es una de las

materias obligatorias incluidas en los planes de estudio de

Ingeniero en Informática impartidos en la ETSE (UV) desde 1993

con una carga docente de 15 créditos

Es un trabajo individual, original y englobado en alguno de los

campos que abarca la Ingeniería en Informática

Tiene una finalidad fundamentalmente formativa para los

futuros Ingenieros Informáticos

Debe ser una etapa de aprendizaje que cubra diferentes

aspectos característicos de las tareas propias del Ingeniero

Persigue poner en práctica todos los conocimientos adquiridos

(en particular una metodología de trabajo) a lo largo de los

estudios, pretendiendo con ello que el alumno/a alcance altos

niveles de perfeccionamiento en la globalidad de las

disciplinas cursadas así como en la defensa de las mismas

4. El proyecto fin de carrera


“Ejercicio original a realizar individualmente y presentar y

defender ante un tribunal universitario, consistente en un

proyecto en el ámbito de las tecnologías específicas de

la Ingeniería en Informática de naturaleza profesional en

el que se sinteticen e integren las competencias

adquiridas en las enseñanzas“


Resolución de la Secretaría General de Universidades de 8 de Junio de 2009

(BOE 4-08-09)

Proyecto Fin de Grado:


El PFC de un ingeniero debe: • Analizar las cosas de forma crítica y profunda

• Demostrar una comprensión profunda de lo que se está haciendo

• Tener las decisiones basadas en la aplicación de los conocimientos impartidos en la carrera

No es buen PFC un proyecto en el que las decisiones están basadas en la inercia, idea féliz o en la intuición, sin ninguna justificación, que podría ser válido en el caso de un proyecto empresarial

Consiste en: • Realizar una revisión de la información

• Desarrollo formal de especificaciones

• Construcción de prototipos

También pretende que los alumnos adquieran formación en: • Elaboración de la documentación

• Presentación o defensa oral del proyecto



No se espera que el estudiante haga solamente

lo que se le ha dicho que haga, si no que: • Razone de forma autónoma

• Cuestione las cosas y las mires desde otros puntos de vista

• Sea crítico

• Tenga conocimiento profundo de las situaciones y

problemas

• Documente, como un medio para comunicar el

conocimiento adquirido. Los pensamientos, ideas y

desarrollos propios son importantes, interesan a las personas

que leerán la memoria final



Tipos de PFC: • Proyectos basados en la investigación

• Proyectos de desarrollo (software, hardware, sistemas

telemáticos, de desarrollo de procesos, métodos,

algoritmos, etc.)

• Proyectos de evaluación

• Proyectos en colaboración con la industria

• Proyectos de resolución de problemas



Un proyecto basado en la investigación implica:

• Un análisis cuidadoso de un área en particular, mejorando la

comprensión de ésta

• Identificar los puntos fuertes y débiles en el campo estudiado

• Reconocer los puntos susceptibles de un desarrollo posterior

• Especificar claramente los objetivos y beneficios de la investigación

• Requiere una buena búsqueda y análisis bibliográfico

• Trabajo en equipo, se colabora en una parte

Proyectos de desarrollo. Suelen requerir incluir:

• Una cierta evaluación: Estudio de viabilidad

• Documentación acerca de: requisitos, diseño, análisis y pruebas

• Documentar manuales de usuario o guías

• Evaluar críticamente y especificar, si es posible, como debe ser el

paso de proyecto a producto


Ej.: Desarrollo de modulo de visualización 3D para proteínas de las vías del estrés oxidativo

Ej.: Desarrollo de un software para el análisis de características fundamentales de la voz


Proyectos de evaluación. El objetivo principal es alguna forma de análisis o valoración. Caracterización, estudio-crítico ó estimación de diferentes perspectivas:

• Diferentes enfoques de un mismo problema

• Lenguajes de programación (aplicación)

• Diferentes interfaces de usuario

• Estudio por casos

Proyectos de colaboración con industria: • Implican resolver un problema definido externamente.

• El proyecto no debe ser forzado en la dirección que la empresa desee, que puede no ser la adecuada para el proyecto académico desarrollado por el estudiante

• Se debe separar entre lo que es propiamente el proyecto de la empresa y lo que sería el PFC

• Añadir a la solución particular que propone la empresa un estudio de antecedentes que permitan un análisis más global

Proyectos de resolución de problemas: Puede implicar el desarrollo de una nueva técnica para resolver el problema, o para la mejora de la eficiencia de procesos


Ej.: Análisis de las capacidades y escenarios de aplicación de las tecnologías Data Mashup

Ej.: Desarrollo de un sistema web para la administración de nóminas en Ford España

Ej.: Soluciones al problema del control de calidad en empresas del textil con cámaras IP tipo PTZ


Prólogo/Resumen

Capítulo 1. Introducción: planteamiento del problema proyectual.

Objetivos. Justificación. Alcance. Metodología de resolución

Capítulo 2. Estudios preliminares, anteproyecto.

Estado del arte. Estudio de alternativas. Selección de la opción óptima.

Capítulo 3. Diseño.

Funcionamiento. Bloques componentes. Relaciones, elementos de ensamblado. Algoritmos.

Capítulo 4. Desarrollo y verificación

Construcción del prototipo. Definición y realización de pruebas.

Exposición e interpretación de resultados.

Capítulo 5. Presupuesto económico (si no constituye un documento aparte)

Materia prima. Mano de obra. Servicios externos. Otros.

Capítulo 6. Planificación de la ejecución (si no forma un documento aparte)

Tiempo. Costes.

Capítulo 7. Conclusiones

Recapitulación. Crítica y posibles mejoras. Trabajo futuro.

Christian W. Dawson y Gregorio Martín, “El proyecto fin de carrera en ingeniería informática”, Prentince Hall.

4. El proyecto fin de carrera Estructura Versión 1


Resumen

Capítulo 1. Introducción

Capítulo 2. Motivación y Objetivos • 2.1. Motivación

• 2.2. Objetivos

Capítulo 3. Estado del Arte

Capítulo 4. Especificación • 4.1. Definición de Requisitos de Usuarios

• 4.2. Especificación del Sistema

• 4.3. Planificación y Estimación de Costes

Capítulo 5. Desarrollo del Proyecto • 5.1. Análisis

• 5.2. Diseño

• 5.3. Implementación

Capítulo 6. Pruebas y Resultados • 6.1. Descripción de Experimentos

• 6.2. Resultados y Discusión

• 6.3. Evaluación Presupuestaria

Capítulo 7. Conclusiones y Trabajo Futuro

Referencias

Anexos

Recomendación Pedro Morillo. Departamento de Informática. Universidad de Valencia



Sección 5.1. Análisis del Sistema • 5.1.1 Análisis de Requisitos

• 5.1.2 Modelado de Procesos

• 5.1.3 Modelado de Datos

Sección 5.2. Diseño del Sistema • 5.2.1 Diseño de interfaces de usuario

• 5.2.2 Diseño de procesos

• 5.2.3 Diseño de base de datos

Capítulo 6. Pruebas y Resultados • 6.1. Descripción de Experimentos

• 6.1.2 Pruebas funcionales

• 6.1.3 Pruebas de rendimiento

• 6.1.4 Pruebas de usabilidad

• 6.1.5 Pruebas de ergonomía

• 6.1.6 Pruebas de accesibilidad

• …



Ej: +General


Sección 5.1. Análisis del Sistema • 5.1.1 Casos de Uso

• 5.1.1.1 Casos de uso “Administrador”

• 5.1.1.2 Casos de uso “Cliente”

• 5.1.1.3 Casos de uso “…”

• 5.1.1.N Casos de uso “Invitado”

• 5.1.2 Diagramas de Estados

• 5.1.3 Diagramas de Actividad

• 5.1.4 Diagrama de Clases para el Modelo de Datos

Sección 5.2. Diseño del Sistema • 5.2.1 Diagrama de Componentes

• 5.2.2 Diagrama de Clases

• 5.2.3 Diagrama de Secuencia



Ej: UML


El problema principal está bien definido

Se han considerado debidamente los factores o

variables del entorno o contexto

Se esta probando una hipótesis claramente formulada

El diseño y metodología usadas son las apropiadas.

Además se contribuyen adecuadamente con esos

datos

Los algoritmos y técnicas son las correctas. Además, se

describen las limitaciones (si las hubiera) de los mismos

Se discuten si se pueden generalizar los resultados

logrados

Se discuten las implicaciones de la solución


Cuestiones a nivel general del trabajo

¿Qué se espera en la lectura del proyecto?


Son los antecedentes y corresponde a la revisión de

literatura

Se refiere a los artículos, estudios y libros específicos que

marcan un punto de partida para el abordaje del tema

Definido el contexto del problema, destaca: • El marco de conocimiento del problema a abordar, una breve reseña

histórica y el conjunto de técnicas y metodologías aplicables al mismo

con relación al proyecto

• Los autores/aportaciones más importantes dentro del área de estudio

enmarcándolos en los aspectos o variables que han sido investigados

Debe de ser guiado para permitir centrar al lector sobre

el contexto de trabajo del problema

Evita ser una colección de aportaciones de terceros e

incluye, de forma razonada, ciertos principios de

elección de alternativas metodológicas/técnicas


Estado del Arte


No hay una introducción al tema. Se confunden (o se

obvian) los contenidos esperados en las secciones del

resumen y la introducción

No hay un orden cronológico tanto en la exposición del

estado del arte como en el ámbito general del

proyecto

No se explican y/o referencian las figuras, tablas, código

o variables de las ecuaciones

No hay una unificación en los planteamientos: las

variables para la velocidad son v, pc y z en las

ecuaciones (1), (2) y (3) (deberían ser todas una sola, v

por ejemplo)


Errores típicos del PFC


No se revisan elementos léxicos, sintácticos o semánticos

de la redacción de la memoria

No hay relación entre cada uno de los párrafo y no se

presentan e introducen las secciones futuras

No hay un hilo conductor. Las secciones se plantean

como un listado de métodos y referencias donde hace

falta una discusión. En este sentido, el Estado del Arte es

del tipo “frazada de retazos” en el que se ha copiado

cada uno de los métodos uno tras otro sin guardar una

relación con el problema que se pretende resolver en la

memoria. Al copiar se cometen errores tipográficos,

relacionales, no se introducen términos o acrónimos, o

por el contrario, la presentación es múltiple




No hay conclusiones no sólo en el proyecto global sino

en secciones con mucho peso específico, como el

Estado del Arte, donde el lector ha podido adquirir

mucho criterio a tenor de los contenidos

No hay argumentos razonables que sustenten una

hipótesis de trabajo

El empleo de la metodología de diseño (UML, OMT,

Métrica, etc.) o técnica de programación (orientación a

objetos, programación estructurada, etc.) no queda

bien latente y expresada en la información incluida en

las secciones que conforman el desarrollo del proyecto

(análisis, diseño, implementación)

Los elementos metodológicos clave (casos de uso,

diagrama de clases, etc.) no están bien ubicados




La gestión económica del proyecto no está contrastada

y no se compara la planificación y estimación de costes

(pre-desarrollo) con la evaluación presupuestaria (post-

desarrollo)

La estimación de costes (que deben amortizarse) y

duración del proyecto no está bien justificada y no se

han empleado los estimadores correctos

Las referencias bibliográficas no están indexadas (autor

o aparición en texto), o están incompletas o se abusa

de enlaces tipo web (links) en aspectos muy asentados

en la literatura de la materia

No se evalúa el sistema más allá de las pruebas básicas

funcionales, sin entrar en aspectos clave como el

rendimiento (o usabilidad o accesibilidad en web)





Una aproximación a la evaluación

Modelo evaluación Departamento Informática (UVEG) aprobado a partir curso 2010-2011

DOCUMENTACIÓN EXPOSICION Y DEFENSA DEL

PROYECTO TRABAJO REALIZADO

Documentación (35 %) Exposición y defensa del Proyecto

(25%) Trabajo realizado (40%)

Organización

de la Memoria

(30%)

Claridad y

corrección

de la

expresión

(30%)

Contenido

del

trabajo

(40%)

Organización

de la

presentación

(30%)

Claridad y

corrección

de la

expresión

(40%)

Defensa

del

Proyecto

(30%)

Disposición

y

capacidad

personal

(30%)

Capacidad

Técnica

(30%)

Gestión del

proyecto

(20%)

Conclusiones y

líneas futuras

(20%)

D1 D2 D3 E1 E2 E3 F1 F2 F3 F4

Excelente (10) (1,05) (1,05) (1,40) (0,75) (1,00) (0,75) (1,20) (1,20) (0,80) (0,80)

Muy bien (9) (0,95) (0,95) (1,26) (0,68) (0,90) (0,68) (1,08) (1,08) (0,72) (0,72)

Notable (8) (0,84) (0,84) (1,12) (0,60) (0,80) (0,60) (0,96) (0,96) (0,64) (0,64)

Bien (7) (0,74) (0,74) (0,98) (0,53) (0,70) (0,53) (0,84) (0,84) (0,56) (0,56)

Suficiente (5) (0,53) (0,53) (0,70) (0,38) (0,50) (0,38) (0,60) (0,60) (0,40) (0,40)

Mal (3) (0,32) (0,32) (0,42) (0,23) (0,30) (0,23) (0,36) (0,36) (0,24) (0,24)

Muy mal (1) (0,11) (0,11) (0,14) (0,08) (0,10) (0,08) (0,12) (0,12) (0,08) (0,08)

TOTAL D1+D2+D3+E1+E2+E3+F1+F2+F3+F4 NOTA FINAL



Una aproximación a la evaluación

Estructura

30%

Forma

30%

Fondo

40%

Disposición y

Capacidad

Personal

30%

Capacidad

Técnica

30%

Gestión del

Proyecto

20%

Conclusiones y

Líneas Futuras

20%

DOCUMENTACIÓN

35%

EXPOSICIÓN Y

DEFENSA DEL

PROYECTO

25%

TRABAJO

REALIZADO

40%

NOTA FINAL

TRIBUNAL+TUTOR

Estructura

30%

Forma

40%

Fondo

30%

TRIBUNAL+TUTOR

SÓLO TUTOR


Estructura (30%)

• Apartados organizados y planteados de forma coherente

• Normas y buenas prácticas de textos científico-técnicos

Forma (40%)

• Claridad y corrección en expresión escrita/gráfica

• Grado de autonomía en la elaboración de memoria (plagio)

Fondo (30%)

• Complejidad técnica de objetivos y trabajo realizado

• Soluciones al tipo de problemas ocurridos durante el trabajo

• Capacidad de síntesis

• Reproducibilidad

• Correcta planificación y evaluación de costes



Documentación


Estructura (30%)

• Claridad, dominio en objetivos, SOTA, desarrollo y conclusiones

• Distribución equilibrada de tiempo (tiempo máximo)

Forma (30%)

• Corrección en expresión oral (muletillas, lapsus, repeticiones,…)

• Hilo argumental lógico y coherente conductor de presentación

• Imagen transmitida como presentador

Fondo (40%)

• Dominio en tema y tecnologías que rodean al proyecto

• Capacidad de respuesta a las preguntas

• Argumentación de conclusiones y trabajos futuros



Defensa


Disposición y capacidad personal (30%)

• Capacidad de comunicación y colaboración

• Autonomía

• Integración en equipo de trabajo (si hubiera)

Capacidad técnica (30%)

• Dificultad técnica del proyecto

• Profundidad y nivel de comprensión alcanzada por el

proyectando

• Respuestas a situaciones complejas e imprevistas

• Calidad de la ejecución de los trabajos

• Calidad técnica del resultado final



Trabajo Realizado


Gestión del proyecto (20%)

• Uso correcto de la metología básicad e GdP (PP + Ejecución)

• Realización de informes y documentación del proyecto durante

la ejecución del mismo

• Relación proactiva-reactiva con el Director

• Organización equilibrada del tiempo durante la ejecución

Conclusiones y líneas futuras (20%)

• Capacidad de valorar el trabajo realizado • Aportaciones realizadas a la situación inicial

• Grado de consecución de objetivos planteados

• Proyección futura del proyecto (capacidad de enmarcarla)

• Capacidad por delimitar cuestiones pendientes por resolver



Trabajo Realizado

2º C I C L O u n i v e r s i t a r i o

I N G E N I E R Í A I N F O R M Á T I C A


Ingeniería de Proyectos Informáticos 4.5 créditos

Dr. Pedro Morillo Tena Departamento Informática UVEG

IPI - Universitat de València · La importancia de la documentación 2. Estructura de un proyecto...

Documents

Transcript of IPI - Universitat de València · La importancia de la documentación 2. Estructura de un proyecto...