Source: http://docplayer.es/2357113-Proyecto-fin-de-carrera.html
Timestamp: 2017-06-28 14:25:59+00:00

Document:
Cristóbal Caballero Río
1 Departamento de Informática PROYECTO FIN DE CARRERA Creación y uso de patrones de producto en el marco del proceso de gestión de proyectos software Autor: Tutor: Pedro Escribano Romero María Isabel Sánchez Segura Leganés, 6 de Junio de 20112 Pedro Escribano Romero Página 23 Título: Creación y uso de patrones de producto en el marco del proceso de gestión de proyectos software. Autor: Pedro Escribano Romero Director: María Isabel Sánchez Segura EL TRIBUNAL Presidente: Fuensanta Medina Domínguez Vocal: Arturo Mora Soto Secretario: Diana Vasquez Realizado el acto de defensa y lectura del: Proyecto Fin de Carrera el día 6 de Junio de 2011 en Leganés, en la Escuela Politécnica Superior de la Universidad Carlos III de Madrid, acuerda otorgarle la CALIFICACIÓN de: PRESIDENTE SECRETARIO VOCAL Pedro Escribano Romero Página 34 Pedro Escribano Romero Página 45 AGRADECIMIENTOS Desocupado lector: sin juramento me podrás creer que quisiera que este libro, como hijo del entendimiento, fuera el más hermoso, el más gallardo y más discreto que pudiera imaginarse; pero no he podido yo contravenir al orden de naturaleza, que en ella cada cosa engendra su semejante. Miguel de Cervantes Saavedra. Don Quijote de la Mancha Con el prologo que escribió este dramaturgo hace cuatrocientos años, empiezo los agradecimientos de este proyecto. En las líneas anteriores se desprende la grandeza de haber realizado algo importante, con inteligencia y a mi modo de pensar algo perfecto. A pesar de todo ello, si el lector encuentra algún fallo, le pido disculpas, ya que ese error no es fruto de todo el esfuerzo que he puesto para sacar adelante este proyecto. En primer lugar tengo que agradecer a mis padres, Julio e Isabel, todo. Y en este adjetivo incluyo lo que me han dado desde que estoy en la vida. Los inicios fueron duros, pero ellos trabajaron, lucharon para remontar en la carrera de la vida y hacer de mí, lo que soy hoy. Ellos fueron mis primeros profesores que más recuerdo y aprecio tengo, me enseñaron a leer, escribir, contar y no se conformaron con alcanzar al penúltimo, si no que la remontada duró hasta que me pusieron primero. Después de esto, me enseñaron valores, actitudes y me dejaron volar solo, siempre con su apoyo y ánimos en los momentos duros. Sin ellos no podría haber escrito estas líneas. A mi hermana Mónica, por haber sido una referencia en mi vida, y cumplir con su trabajo de hermana mayor. Ha sido una gran satisfacción personal coincidir con ella en algunas asignaturas de esta carrera, apoyándome y ayudándome siempre que lo he necesitado. A Vero, por su apoyo, comprensión y toda la paciencia que ha tenido conmigo en los momentos más duros y en los que más había que luchar para seguir adelante en la carrera. A mis abuelos y familia, que siempre veían en mi algo grande. La ilusión al ver que tenían en mí un ingeniero, es muy difícil de expresar. A mi tutora de proyecto, Maribel, sin ella no podría haber sacado esto adelante. Tuvo una gran idea al pensar y ofrecerme este proyecto, dirigiéndolo con gran maestría y profesionalidad. A mi compañero de clase y amigo, Román. Juntos hemos sacado adelante asignaturas y prácticas que parecían imposibles. Pedro Escribano Romero Página 56 A nivel personal estoy muy satisfecho con el camino que escogí al elegir esta carrera. Son muchos los conocimientos que he adquirido durante estos años. A todos ellos y a los no mencionados, gracias por haberme acompañado durante estos duros años, que con vuestros ánimos, ha sido más fácil conseguir todos mis retos. Pedro Escribano Romero Página 67 RESUMEN Este proyecto tiene como objetivo generar unidades de conocimiento transferibles y reutilizables relacionadas con los procesos de gestión de proyectos de desarrollo software. Se construirán patrones de producto, que serán accesibles a través de un portal de Learning Management System y una Wiki. ABSTRACT The main goal of this project is the development of knowledge units that encapsulate best practices in the field of software project management. These knowledge units are called product patterns and are developed to be reused during the development of software projects management. Product patterns will be accessible via a Learning Management System and a Wiki. Pedro Escribano Romero Página 78 Pedro Escribano Romero Página 89 ÍNDICE GENERAL 1. INTRODUCCIÓN HISTORIA DE LA GESTIÓN DE PROYECTOS CICLO DE VIDA DE UN PROYECTO SOFTWARE CICLOS DE VIDA Modelo de desarrollo en cascada o Waterfall Modelo de desarrollo en V Modelo de desarrollo en espiral Prototipado evolutivo Entrega por etapas Entrega evolutiva CICLO DE VIDA RUP LIFECYCLE VENTAJAS Y DESVENTAJAS DE CICLOS DE VIDA ANTIGUOS FRENTE A MODERNOS PROBLEMAS EN PROYECTOS SOFTWARE ASPECTOS ECONÓMICOS Y TEMPORALES DE UN PROYECTO SOFTWARE PROCESOS DE GESTIÓN DE PROYECTOS SOFTWARE ESTIMACIÓN DE PROYECTOS SOFTWARE Puntos de función Cocomo ORGANIZACIÓN DE PROYECTOS SOFTWARE WBS PBS RBS PLANIFICACIÓN DE PROYECTOS SOFTWARE Diagrama Gantt SEGUIMIENTO DE PROYECTOS SOFTWARE Seguimiento predictivo: valor conseguido BENEFICIOS DE LA GESTION DE PROYECTOS SOFTWARE Pedro Escribano Romero Página 910 8. ROLES DEL PERSONAL DE UN PROYECTO DE DESARROLLO SOFTWARE DESCRIPCIÓN GLOBAL DEL PROYECTO PATRONES DE PRODUCTO DE GESTIÓN DE PROYECTOS Patrón de Producto: Puntos de función de Albrecht sin ajustar Patrón de Producto: Puntos de función de Albrecht ajustados Patrón de Producto: Cocomo Patrón de Producto: WBS Patrón de Producto: RBS Patrón de Producto: PBS Patrón de Producto: Diagrama de Gantt Patrón de Producto: Valor conseguido DESCRIPCIÓN DE LA WIKI DESCRIPCIÓN DEL PORTAL DE SOPORTE A LA GESTIÓN DE PROYECTOS VALIDACIÓN DE LA SOLUCIÓN DESARROLLADA Etapa 1: Realización de casos prácticos sin patrones de producto Etapa 2: Realización de casos prácticos con patrones de producto Etapa 3: Análisis de los datos Ejecución etapa Caso práctico 1: Estimación con Puntos de Función Solución del caso práctico Caso práctico 3: Estimación con Cocomo Solución del caso práctico Caso práctico 5: Estimación con Cocomo Solución del caso práctico Caso práctico 7: Organización con PBS Solución del caso práctico Caso práctico 9: Planificación mediante Diagrama de Gantt Solución del caso práctico Caso práctico 11: Seguimiento mediante técnica de Valor Conseguido Solución del caso práctico Toma de tiempos y características Pedro Escribano Romero Página 1011 9.4.5 Ejecución etapa Caso práctico 2: Estimación con Puntos de Función Solución al caso práctico Caso práctico 4: Estimación con Cocomo Solución al caso práctico Caso práctico 6: Estimación con Cocomo Solución del caso práctico Caso práctico 8: Organización con WBS Solución del caso práctico Caso práctico 10: Planificación mediante Diagrama de Gantt Solución al caso práctico Caso práctico 12: Seguimiento mediante técnica de Valor Conseguido Solución del caso práctico Toma de tiempos y características Ejecución etapa ANÁLISIS DE USABILIDAD DE LA SOLUCIÓN PROPUESTA Test de usabilidad Resultados obtenidos Retroalimentación realizada a la Wiki y Portal PRESUPUESTO DEL PROYECTO REALIZADO PLANIFICACION DEL PROYECTO REALIZADO CONCLUSIONES LÍNEAS FUTURAS GLOSARIO BIBLIOGRAFÍA Pedro Escribano Romero Página 1112 ÍNDICE DE FIGURAS Figura 1: Modelo de desarrollo en cascada Figura 2: Modelo de desarrollo en V Figura 3: Modelo de desarrollo en espiral Figura 4: Modelo del prototipado evolutivo Figura 5: Modelo de entrega por etapas Figura 6: Modelo de entrega evolutiva Figura 7: Ciclo de vida moderno Figura 8: Ejemplo de un mal desarrollo Figura 9: Estructura conceptual de gestión de proyectos software Figura 10: Desarrollo temporal de las actividades de gestión de proyectos software Figura 11: Relación entre procesos de gestión Figura 12: Transformación del modelo teórico en un plan de acción Figura 13: Algoritmo para encontrar un patrón de producto Figura 14: Página principal de la Wiki Figura 15: Diagrama para buscar un patrón de producto Figura 16: Patrones de producto de gestión de proyectos Figura 17: Ejemplo de patrón de producto I Figura 18: Ejemplo de patrón de producto II Figura 19: Ejemplo de patrón de producto III Figura 20: Portal SelCampus Figura 21: Portal de gestión de proyectos Figura 22: Carpeta de documentos Figura 23: Ejemplo de subcarpeta de documentos Figura 24: Estructura del temario en carpetas Figura 25: Patrones de producto en portal SelCampus Figura 26: Clases grabadas en Portal SelCampus Pedro Escribano Romero Página 1213 Figura 27: Seguimiento de un usuario Figura 28: Seguimiento de un grupo de usuarios Figura 29: Ejemplo de diagrama de actividad Figura 30: Caso práctico 1 - Baja de cliente Figura 31: Caso práctico 1 - Baja de cliente Figura 32: Caso práctico 7 - Diagrama WBS Figura 33: Solución caso práctico 7 - PBS Figura 34: Solución al caso práctico 9 - Diagrama de Gantt Figura 35: Caso práctico 8 - Diagrama de Gantt Figura 36: Solución al caso práctico 8. WBS Figura 37: Solución al caso práctico 10 - Diagrama de Gantt Figura 38: Diagrama de barras - Comparación Figura 39: Encuesta de usabilidad Figura 40: Gráfico circular - Resultados generales de encuesta Figura 41: Gráfico circular - Resultados de facilidad de aprendizaje Figura 42: Gráfico circular - Resultados de pregunta Figura 43: Gráfico circular - Resultados de pregunta Figura 44: Gráfico circular - Resultados de pregunta Figura 45: Gráfico circular - Resultados de pregunta Figura 46: Gráfico circular - Resultados de pregunta Figura 47: Gráfico circular - Resultados de pregunta Figura 48: Gráfico circular - Resultados de pregunta Figura 49: Gráfica circular - Resultados de pregunta Figura 50: Gráfico circular - Resultados de pregunta Figura 51: Gráfico circular - Resultados de pregunta Figura 52: Gráfico circular - Resultados de percepción de utilidad Figura 53: Gráfico circular - Resultados de pregunta Pedro Escribano Romero Página 1314 Figura 54: Gráfico circular - Resultados de pregunta Figura 55: Gráfico circular - Resultados de pregunta Figura 56: Gráfico circular - Resultados de pregunta Figura 57: Gráfico circular - Resultados de pregunta Figura 58: Gráfico circular - Resultados de pregunta Figura 59: Gráfico circular - Resultados de pregunta Figura 60: Gráfico circular - Resultados de pregunta Figura 61: Gráfico circular - Resultados de pregunta Figura 62: Gráfico circular - Resultados de facilidad de uso Figura 63: Gráfico circular - Resultados de pregunta Figura 64: Gráfico circular - Resultados de pregunta Figura 65: Gráfico circular - Resultados de pregunta Figura 66: Gráfico circular - Resultados de pregunta Figura 67: Gráfico circular - Resultados de pregunta Figura 68: Gráfico circular - Resultados de pregunta Figura 69: Gráfico circular - Resultados de satisfacción Figura 70: Gráfico circular - Resultados de pregunta Figura 71: Gráfico circular - Resultados de pregunta Figura 72: Gráfico circular - Resultados de pregunta Figura 73: Gráfico circular - Resultados de pregunta Figura 74: Gráfico circular - Resultados de pregunta Figura 75: Gráfico circular - Resultados de pregunta Figura 76: Enlaces de los patrones de producto desde el portal Figura 77: Planificación Noviembre Figura 78: Planificación Diciembre Figura 79: Planificación Enero Figura 80: Planificación - Febrero Pedro Escribano Romero Página 1415 Figura 81: Planificación - Marzo Figura 82: Planificación - Abril Figura 83: Planificación - Mayo Figura 84: Origen de acceso a patrones de producto Pedro Escribano Romero Página 1516 ÍNDICE DE TABLAS Tabla 1: Entidad partida Tabla 2: Entidad certificación del cliente Tabla 3: Entidad certificación del subcontratista Tabla 4: Entidad materia prima Tabla 5: Entidad recursos Tabla 6: Entidad de actividades Tabla 7: Campos de un patrón de producto Tabla 8: Caso práctico 9 - Tareas planificadas Tabla 9: Caso práctico 11 - Tabla de seguimiento Tabla 10: Solución caso práctico 11 - Tabla de seguimiento Tabla 11: Tiempo de casos prácticos en etapa Tabla 12: Caso práctico 4 - Valores de RELY Tabla 13: Caso práctico 10 - Tareas planificadas Tabla 14: Caso práctico 12 - Esfuerzo por tareas Tabla 15: Caso práctico 12 - Valor presupuestado Tabla 16: Caso práctico 12 - Tareas completadas Tabla 17: Caso práctico 12 - Tabla de seguimiento Tabla 18: Solución caso práctico 12 - Valor presupuestado por semana Tabla 19: Solución caso práctico 12 - Tabla de seguimiento Tabla 20: Tiempo de casos prácticos en etapa Tabla 21: Resumen de tiempos de los casos prácticos Tabla 22: Presupuesto del proyecto Tabla 23: Actividades del proyecto Tabla 24: Sitios web de referencia Tabla 25: Palabras clave en motores de búsqueda Pedro Escribano Romero Página 1617 Pedro Escribano Romero Página 1718 1. INTRODUCCIÓN Este proyecto está ubicado dentro de la Ingeniería del Software, concretamente, en el marco de la gestión de proyectos. Las tecnologías de la información están avanzando y se están integrando con gran aceptación en la sociedad, sobre todo en la comunidad docente, esto hace que la transferencia de conocimiento y el método didáctico se tengan que adaptar a estas tecnologías. Para ello se han construido patrones de producto [1] que encapsulan el conocimiento de un conjunto de técnicas de gestión de proyectos, que serán accesibles a través de un portal de Learning Management System y a través de la propia wiki donde están ubicados. Un patrón de producto es un artefacto que almacena el conocimiento de los ingenieros expertos para obtener un producto software específico. Entendiendo como producto el elemento mínimo en la ingeniería del software que se obtiene de la ejecución de una actividad. El principal objetivo del proyecto consiste en generar unidades de conocimiento transferibles y reutilizables relacionadas para los procesos de gestión de proyectos de desarrollo software. Para esto se han desarrollado patrones de producto que almacenan y reutilizan el conocimiento sobre gestión de proyectos. En el portal de soporte construido para la gestión de proyectos, además de encontrarse los patrones de producto, el usuario encontrará información de utilidad para sacar adelante un proyecto o para aprender a gestionarlos. Existen unidades didácticas de sus distintas fases, casos prácticos resueltos, videos explicativos, etc. en general un gran material didáctico para su aprendizaje. En una segunda fase del proyecto se ha realizado un estudio de validación de la solución propuesta, mediante unos casos prácticos, para demostrar los beneficios que se obtienen. Este estudio consta de varias etapas. En la primera etapa se resolverán unos casos prácticos sin la ayuda de patrones de producto, se recogerán los tiempos empleados en su resolución y se tomarán notas o características expuestas por los usuarios. En la segunda etapa se resolverán unos casos prácticos con la ayuda de patrones de producto, e igualmente, se recogerán los tiempos empleados en su resolución y se tomarán notas o características expuestas por los usuarios. En una última etapa, se analizarán los tiempos recogidos en las etapas anteriores y se compararán, argumentando los beneficios de la utilización de los patrones de producto creados. Pedro Escribano Romero Página 1819 Por último se ha elaborado un test de usabilidad con el fin de hacérselo llegar a todos los usuarios para comprobar opiniones y realizar así el propio análisis de usabilidad, para posibles mejoras o cambios que pudiesen surgir. Las métricas de usabilidad analizadas son: facilidad de aprendizaje, percepción de utilidad, facilidad de uso y la satisfacción. Pedro Escribano Romero Página 1920 2. HISTORIA DE LA GESTIÓN DE PROYECTOS En este apartado se expone la historia de la gestión de proyectos software desde los años 70 hasta nuestros días, así como la organización referente a nivel mundial en gestión de proyectos, PMI (Project Management Institute). PMI es un organización sin fines lucrativos creada en 1969 en Atlanta (Estados Unidos). Los objetivos de PMI son: - Formular estándares profesionales para la Gestión de Proyectos. - Generar conocimiento a través de la investigación en Gestión de Proyectos. - Promover la Gestión de Proyectos como profesión a través de sus programas de certificación. En los años 70 se creó el primer capítulo, y se realizó el primer seminario fuera de Estados Unidos, por eso se dijo anteriormente su visión mundial en gestión de proyectos. Durante los años 1980 se efectuó la primera evaluación para la certificación como PMP o Profesional en Gestión de Proyectos y se estableció un código de ética para la profesión. A principios de los años 90, se publicó la primera edición de la guía del PMBOK (Project Management Body of Knowledge), que hasta hoy, es un pilar básico para la gestión y dirección de proyectos. Es una colección de procesos y áreas de conocimiento generalmente aceptadas como las mejores prácticas dentro de la gestión de proyectos. El PMBOK reconoce 5 grupos de procesos básicos y 9 áreas de conocimiento común aplicadas a casi todos los proyectos. Los procesos se traslapan e interactúan a través de un proyecto o fase y son descritos en términos de: - Entradas: documentos, planes y diseños. - Herramientas y Técnicas: mecanismos aplicados a las entradas. - Salidas: documentos y productos. La calidad del producto final no viene marcada por la metodología utilizada o las tecnologías empleadas, si no por el conjunto de todo, es decir, de la política de gestión y nivel de madurez del equipo de trabajo que esté realizando un proyecto. Pedro Escribano Romero Página 2021 Hay que tener en cuenta que cada vez son más los usuarios que demandan un mismo producto realizado, por lo que se debe reducir cada vez más el tiempo de desarrollo del mismo. A continuación se explican las técnicas y herramientas de trabajo en la gestión de proyectos software desde los años 70 hasta la actualidad. Medidas tomadas para la gestión de proyectos software en los años 70: Los años 70 es el nacimiento de pequeños productos software. La gestión que se hacía en este tipo de trabajos es mínima o casi nula. Las únicas medidas que se hacían eran referentes a la observación del producto que se estaba realizando, dando una idea del poco estudio de seguimiento y control previo que se realizaba en este tipo de desarrollos. Las medidas realizadas eran el conteo de líneas de código, número de sentencias GoTo, numero de errores finales al compilar, etc. cosas básicas sobre el mismo producto que se estaba realizando. Medidas tomadas para la gestión de proyectos software en los años 80: En esta década de los 80, sobre todo en sus años más avanzados, se empezaron a conocer y a utilizar modelos de estimación de proyectos software como fue los Puntos de Función de Albrecht y sobre todo Cocomo. Cocomo fue utilizado para la estimación de coste y tiempo en el desarrollo de proyectos software. Para el mismo proceso de gestión, pero con un resultado distinto, se utilizaban los Puntos de Función de Albrecht, de los cuales se obtenía la estimación de esfuerzo y plazos de tiempo para una aplicación. Sus creadores e incluso los ingenieros que posteriormente utilizaban estas herramientas intentaron estandarizar estas medidas y sus modelos de estimación. Se empezaba a crear la gestión de proyectos. Medidas tomadas para la gestión de proyectos software en los años 90 hasta la actualidad: Esta década fue la continuidad hasta nuestros días de poner en práctica y seguir realizando estudios para la mejora, sobre lo que se empezó a utilizar en la década anterior. Todos los proyectos tenían interés en establecer una metodología o procesos de gestión fiables para sus proyectos software. Pedro Escribano Romero Página 2122 3. CICLO DE VIDA DE UN PROYECTO SOFTWARE Los modelos de proceso que se siguen en la gestión de proyectos convergen a periodos del ciclo de vida software, resultando ser un factor estratégico para la consecución exitosa de un proyecto software. Para evitar errores de conceptos se debe tener claro los siguientes puntos, donde se comparan los Ciclos de Vida a los Modelos de Proceso: - Un ciclo de vida marca el orden entre procesos. - Un modelo de proceso no marca ningún orden entre sus procesos. - El ciclo de vida está orientado al producto. - El modelo de proceso está orientado al proceso. En los siguientes puntos, de forma breve, se expone la tendencia actual de estos procesos: - El término ciclo de vida se está quedando obsoleto al no incluir procesos de gestión. - Se busca la convergencia entre los dos términos, procesos de gestión y ciclo de vida. A continuación se explican brevemente los ciclos de vida más representativos que han existido hasta la elaboración del ciclo de vida Rup Lifecycle. Pedro Escribano Romero Página 22 23 3.1 CICLOS DE VIDA En este apartado se explica de forma resumida las características de los ciclos de vida antiguos. Los ciclos de vida que se van a tratar son: - Modelo de desarrollo en cascada o waterfall. - Modelo de desarrollo en V. - Modelo de desarrollo en espiral. - Prototipado evolutivo. - Entrega por etapas. - Entrega evolutiva Modelo de desarrollo en cascada o Waterfall Este modelo pone énfasis en la realización temprana de actividades de definición y documentación, como son requisitos y diseño, como paso previo a la codificación. Proporciona un método estructurado para el desarrollo de software, pero no soporta prácticas modernas de desarrollo, como prototipo y generación automática de código. Figura 1: Modelo de desarrollo en cascada Pedro Escribano Romero Página 2324 3.1.2 Modelo de desarrollo en V Este modelo tiene una serie de fases sucesivas y en cada fase se define las actividades de producción y control. La descomposición de este ciclo en dichas actividades facilita ver las actividades de desarrollo, coordinación de las mismas, estimación, el seguimiento de progreso, y por lo tanto, la rápida detección de desviaciones y la realización de medidas correctoras si procede. Figura 2: Modelo de desarrollo en V Modelo de desarrollo en espiral Gracias al modelo de desarrollo en espiral se puede dar una aproximación al desarrollo de software, proporcionando énfasis en la reducción de riesgo. Cada vuelta en esta espiral se corresponde con los siguientes pasos: - Determinación de objetivos, alternativas y restricciones. - Evaluación de alternativas e identificación y resolución de riesgos. - Desarrollo del siguiente nivel de producto. - Planificación del siguiente paso. Pedro Escribano Romero Página 24 25 Figura 3: Modelo de desarrollo en espiral Prototipado evolutivo Con este tipo de ciclo de vida el cliente es capaz de observar y explorar las distintas alternativas que se puedan generar, por lo que no es necesario que explique los requisitos que necesita de partida, ya que estos irán saliendo con el tiempo mayormente. El modelo de prototipado puede reducir costes y plazos, siendo capaz de identificar las dificultades de requisitos tempranamente. Puede utilizarse según se necesite a lo largo del ciclo de vida. Figura 4: Modelo del prototipado evolutivo Pedro Escribano Romero Página 25 26 3.1.5 Entrega por etapas Este modelo implica el desarrollo de software en grupos de capacidades funcionales, de tal forma, que se crean particiones en incrementos cuyo desarrollo se realiza en etapas que incluyen todo un ciclo normal de desarrollo. De esta forma, el cliente podrá utilizar los productos que se vayan obteniendo antes de su construcción final. La estrategia con la que cuenta este modelo es seguir la filosofía de la construcción de un poco y prueba de ese poco. Figura 5: Modelo de entrega por etapas Entrega evolutiva Este modelo de desarrollo evolutivo implica el desarrollo temprano de un producto operativo, para posteriormente desarrollar sucesivas versiones de dicho producto operativo. Pese a esto, debe existir un Plan de Progreso, y tener muy en cuenta la participación del usuario. Figura 6: Modelo de entrega evolutiva Pedro Escribano Romero Página 2627 3.2 CICLO DE VIDA RUP LIFECYCLE El ciclo de vida moderno incorpora una serie de fases: planificación, análisis, diseño, implantación y soporte de sistemas. En términos generales se puede decir que se desarrollan de forma iterativa e incremental, y cada una de ellas incorpora mayor grado de detalle que la anterior. Las fases de planificación y análisis han de abordarse correctamente, puesto que por muy inteligentes que sean las soluciones técnicas, sin un análisis correcto será muy difícil que el sistema sea todo lo útil que potencialmente podría ser. Figura 7: Ciclo de vida moderno 3.3 VENTAJAS Y DESVENTAJAS DE CICLOS DE VIDA ANTIGUOS FRENTE A MODERNOS En los puntos anteriores se ha resumido sin entrar en detalle el funcionamiento de los distintos ciclos de vida y ciclo de vida iterativo e incremental. Elegir un ciclo de vida para aplicar a un proyecto es una cuestión compleja y hay que guiarse por factores como los siguientes: - Analizar la complejidad del proyecto. - Experiencia del equipo y de la organización que realizará el proyecto. - Fecha de entrega del proyecto al cliente. - Posibles entregas parciales al cliente en determinadas fechas. - Comunicación entre el analista y el cliente. - Especificación de requisitos obtenida. Pedro Escribano Romero Página 2728 A continuación se detallan de forma general las ventajas y desventajas que tienen los ciclos de vida. Ventajas: - Los ciclos de vida antiguos son fáciles de entender por las personas sin experiencia y por el propio cliente. - El cliente y el desarrollador obtienen requisitos claros. - El ciclo de vida en espiral controla los posibles riesgos que pudiesen surgir en el desarrollo del proyecto. - En el ciclo de vida prototipo el usuario ve el avance del proyecto Desventajas: - Tanto en el ciclo de vida en cascada como en el modelo de desarrollo en V, el cliente no puede ver hasta fases avanzadas el funcionamiento del sistema que se está desarrollando. - Si los riesgos surgidos en un proyecto son muy pequeños, el ciclo de vida en espiral es muy costoso. - El modelo de desarrollo en espiral sólo es aplicable en grandes proyectos. Por último, se detallan las ventajas y desventajas que tiene el ciclo de vida Rup Lifecycle: Ventajas: - El impacto de los riesgos es menor. - El progreso de los productos es visible por parte del cliente: - El jefe de proyectos tiene las primeras iteraciones como base de mediciones para las siguientes. - La división del proyecto en partes hace más manejable el trabajo. - Se pueden realizar evaluaciones al final de cada incremento para mejorar en los siguientes. - A medida que se desarrolla el siguiente incremento, se estabiliza el anterior. Desventajas: - El modelo de datos debe ser claro desde la primera iteración para que los incrementos se realicen de forma correcta. - Es difícil dar una fecha ajustada como entrega del proyecto al cliente. Pedro Escribano Romero Página 2829 4. PROBLEMAS EN PROYECTOS SOFTWARE Existen varios problemas que influyen en la realización de un proyecto software. De forma simplificada serían: - Detección sistemática de errores software: El cliente después de recibir el producto pedido encuentra multitud de errores. - Excederse en tiempo: El proyecto no cumple los plazos planificados inicialmente. - Excederse en presupuesto: El proyecto no cumple el presupuesto inicialmente estimado. - Agregar más mano de obra: Solución que se hace para aliviar el plazo de entrega. - Fallo en los requisitos: La comunicación entre el cliente y el jefe de proyectos no ha sido la suficiente o ésta no ha sido eficaz. - Marcha de los empleados: Los empleados debido a la multitud de problemas que pueden existir, abandonan el proyecto. A continuación se explica de forma extendida todos estos problemas. Los dos problemas más graves que pueden existir, relacionados con la gestión de un proyecto software, son en tiempo y presupuesto. Uno de los problemas puede venir desde el inicio cuando se empieza a trabajar en la construcción de un proyecto software. Los elementos más importantes que tienen que tener claro los desarrolladores son los requisitos que pide el cliente. Por lo tanto, la comunicación entre el cliente y el equipo, juega un papel fundamental desde el principio del desarrollo. En la siguiente imagen se expresa un simple caso, donde el cliente requería un producto y debido al mal entendido o falta de actitud por parte del equipo, se desarrolló otro producto totalmente distinto al que pedía de inicio el cliente. Pedro Escribano Romero Página 2930 Figura 8: Ejemplo de un mal desarrollo Otro factor importante aparte de tener los requisitos claros al inicio del proyecto, es el seguimiento mediante reuniones de todas las partes implicadas en el proyecto, e incluso la asistencia a estas del cliente, para que se vea efectivamente si se está construyendo lo realmente pedido, y si se siguen los plazos previstos en la planificación inicial. En el momento en que uno de estos factores falla, el proyecto no tendrá la calidad que el cliente se esperaba cuando contrato al equipo de trabajo, y la detección sistemática de errores será muy frecuente. Este tipo de fallos hace que los proyectos no cumplan los plazos previstos y se tengan que cambiar ciertas características, con el aumento de presupuesto que esto genera. La inestabilidad que se puede crear en el equipo de trabajo hace que los empleados no estén cómodos en el proyecto y lo abandonen, buscando ellos mismos otros caminos donde poder expresar sus conocimientos. Esto agravaría aún más la situación de los plazos de entrega, ya que habría que buscar sustitutos que empiecen de cero en un proyecto que desconocen. En grandes proyectos software cuando los plazos de entrega de los productos están fuera de plazo, se intenta que se adelanten según la planificación establecida, agregando más mano de obra en los sectores que más lo requieran, pudiéndose ser el caso más frecuente, el añadir más programadores. Pedro Escribano Romero Página 3031 La medida anterior es una solución a priori para acortar plazos, pero a posteriori se comete un grave error debido a que al añadir más recursos al proyecto, ya sean humanos o materiales, hace que el proyecto incumpla el presupuesto inicial estimado. Por lo que se llegaría al caso de incurrir en dos problemas de nuevo ya conocidos, tiempo y presupuesto. Hasta este punto y enlazando con lo que se explicó al principio del tema se llega a ciertas conclusiones que hacen afirmar aún más que los dos problemas existentes más importantes en el desarrollo de proyectos software son tiempo y presupuesto. Aquí es donde entraría a trabajar la Gestión de Proyectos para evitar estos problemas. Aunque más adelante se tratarán estos temas en profundidad, se darán unas pequeñas premisas a seguir para no incurrir en estos errores. Estas premisas o elementos de trabajo sería hacer una estimación del proyecto software, para saber la duración, los recursos materiales y humanos que necesitamos, el presupuesto con el que contamos, y ciertos detalles menos importantes pero eficaces que utiliza el jefe de proyecto también en su estimación. Seguidamente, y con los datos que se han obtenido, se organizará el proyecto. La organización puede ser variada pero eficaz. La organización más típica es referente a los recursos humanos y materiales, y en qué actividades se aplican cada uno, la organización de las tareas que se realizan y que se ordenarán por etapas de obtención, y unida a esta última, los productos que se obtienen de estas tareas. Una vez que se saben las tareas que hay que realizar y se cuenta con los recursos humanos suficientes, se realiza la planificación del proyecto. Una de las actividades más importantes es la realización del seguimiento del proyecto, para indicar el dato real del progreso del mismo tanto en plazos como en costes. De tal forma, y si fuese necesario se tomarían medidas. Es importante detallar que este seguimiento se realizará a lo largo de todo el proyecto de forma frecuente. Pedro Escribano Romero Página 3132 5. ASPECTOS ECONÓMICOS Y TEMPORALES DE UN PROYECTO SOFTWARE Este punto trata la importancia que tiene la Gestión de Proyectos en materia de gestión económica y temporal que tantos problemas puede tener un proyecto. Como queda recogido en el libro: Ingeniería del Software, Aspectos de Gestión [2]. El papel de esta gestión es estimar, organizar, planificar y controlar el proceso de ejecución de un proyecto software. Para cumplir los costes, plazos y restricciones de calidad, a pesar de los problemas, teniendo en cuenta el hecho de que la calidad del proceso de ejecución depende altamente de la calidad de la gestión del proyecto. Para que la gestión de proyectos software sea segura y fiable, y por ello lleve a buen fin al proyecto, debe de contar con las siguientes actividades: - Elaboración de elementos entregables y estimación de los costes y plazos asociados con la ejecución. - Planificación del proyecto, determinando la estructura de los equipos humanos, maquinaria y materia prima del proyecto y de la distribución de los presupuestos asignados a los mismos. - Programación de todas las actividades de ejecución teniendo en cuenta las restricciones de plazos, disponibilidades, costes y prioridades u objetivos. - Seguimiento del proyecto, controlando las desviaciones presupuestarias y cronológicas, a través de las acciones correctoras. - Evaluación del desarrollo al final del proyecto considerando todo el proceso. Todas estas actividades son realizadas a través del ciclo de vida seleccionado para el proyecto, y que ya se explicó en el apartado 2. A continuación se expone la estructura conceptual de la gestión de proyectos software. Pedro Escribano Romero Página 3233 Calidad Contrato Partida o Entrega Certificación Cliente Recursos Certificación Subcontrata Actividades Materia Prima Figura 9: Estructura conceptual de gestión de proyectos software Las principales entidades que intervienen en la gestión de proyectos son: Partidas: Código de partida Fecha prevista de entrega Unidad Descripción Partida Fecha actual de entrega Cantidad prevista Cantidad actual Coste unitario previsto Coste actual unitario Precio de venta actual Avance Estado pruebas Actividades afectadas Precio de venta previsto Entregado (Si/No) Pruebas Proyectado (Si/No) Tabla 1: Entidad partida Pedro Escribano Romero Página 3334 Certificación del cliente: Código de certificación Partidas/Unidades Partida/Final Fecha de certificación Partidas/Unidades no proyectadas Tabla 2: Entidad certificación del cliente Certificación del Subcontratista: Código de certificación Partidas/Unidades Partida/Final Fecha de certificación Partidas/Unidades no proyectadas Tabla 3: Entidad certificación del subcontratista Materia Prima: Código de materia prima Unidad Descripción Cantidad presupuestada Cantidad actual Coste unitario presupuestado Coste actual unitario Fecha de entrega actual Fechas pedido Nº pedido de compras Fecha de entrega prevista Estado pedido/ entregado/ devuelto) Suministrador (No pedido/ Tabla 4: Entidad materia prima Pedro Escribano Romero Página 3435 Recursos: Código de recurso Tipo (Mano de obra/herramienta/ Maquinaria/Vehículo Coste previsto unidad Coste previsto por uso Cantidad prevista Fecha prevista de disponibilidad Tipo (Subcontratado /propio) Descripción Unidad de coste Coste actual unidad Coste actual por uso Cantidad actual Fecha actual de disponibilidad Subcontratista Tabla 5: Entidad recursos Actividades: Código de actividad Fecha prevista de comienzo Fecha actual de comienzo Duración prevista Subcontratada/ Propia Coste actual Partidas afectadas Estado (No comenzada/ Comenzada/ parada/anulada/ terminada) Código de subproyecto Descripción Fecha prevista de finalización Fecha actual de finalización Duración actual Coste previsto Recursos Actividades (precedentes / siguientes) Subproyecto (Si/No) Tabla 6: Entidad de actividades Pedro Escribano Romero Página 3536 El seguimiento que se realiza en los proyectos consiste en la comparación del progreso del proyecto con la previsión inicial. En el seguimiento se analizan las desviaciones y se planifican acciones correctoras si procede. Se deben realizar reuniones periódicas a lo largo del proyecto para generar informes de progreso. A continuación se muestra la imagen del desarrollo temporal de las actividades de gestión de proyectos software. Figura 10: Desarrollo temporal de las actividades de gestión de proyectos software En los proyectos software existirán los siguientes presupuestos y planificaciones: - Presupuesto inicial. - Presupuesto Actual: Será actualizado a lo largo de la ejecución del proyecto por el Jefe de Proyectos. - Presupuesto Real: Refleja los costes reales y plazos reales. - Evaluación final del proyecto. La comparación del presupuesto inicial con la evaluación final permite el control de gestión comercial, mientras que el resto de comparaciones (entre actual y real o entre actuales) permiten el control de gestión de ejecución del proyecto. Pedro Escribano Romero Página 3637 6. PROCESOS DE GESTIÓN DE PROYECTOS SOFTWARE El ejercicio de la Ingeniería de Software está guiado por el establecimiento de estándares de desarrollo que definen un lenguaje común de expresión e interpretación de modelos. De esta forma el panorama en Ingeniería del Software está bastante más claro, existiendo dos modelos de proceso bien establecido, ISO e IEEE 1074, que se presentan a continuación. El estándar ISO establece un marco común de trabajo para los procesos del ciclo de vida del software que pueden usarse como referencia en la industria del desarrollo del software. En este estándar se consideran los procesos, actividades y tareas que deben realizar para la adquisición de un producto software y durante el suministro, desarrollo, operación, mantenimiento y disposición de un producto software. El estándar IEEE 1074 especifica procesos del ciclo de vida del software para el desarrollo y mantenimiento del mismo. Determina el conjunto de actividades esenciales, no ordenadas en el tiempo, que deben ser incorporadas dentro del desarrollo de un producto software. El ciclo de vida que seguirá el producto a desarrollar es seleccionado y establecido por el jefe del proyecto para cada proyecto. Los procesos de gestión son el conjunto de procesos que establecen la estructura del proyecto, coordinan y gestionan sus recursos durante todo el ciclo de vida del software. La mayor parte de los procesos propuestos en IEEE 1074 tienen su correspondencia con los procesos de ISO y viceversa. Para obtener un modelo de proceso común se deben mezclar procesos de IEEE 1074 e ISO A parte de lo expuesto anteriormente, el principal estándar de gestión se correspondería con PMBOK (Project Management Body of Knowledge), creado por PMI (Project Management Institute). Este estándar comprende dos secciones: - Procesos y contextos de un proyecto. - Áreas de conocimiento específico para la gestión de proyectos. Los beneficios que se obtienen de este estándar son: - Indica el conocimiento necesario para manejar el ciclo de vida de cualquier proyecto, programa y portafolio a través de sus procesos. - Define para cada proceso sus herramientas, técnicas y entregables necesarios. - Define un cuerpo de conocimiento en el cual cualquier industria pueda construir las mejores prácticas específicas para su área de aplicación. Pedro Escribano Romero Página 3738 Cada año, en todo el mundo existen medio millón de jefes de proyecto que gestionan alrededor de un millón de proyectos software. Pero muchos de estos proyectos no cumplen las expectativas de calidad del cliente o incluso fallan en presupuesto y plazo. Existen estudios que indican que uno de cada tres proyectos sobrepasa en un 125% costes y tiempo previsto. Las razones de estos fallos fueron comentadas en el punto 4 (Problemas en Proyecto Software) de este proyecto, pero se recuerda a modo de resumen para adentrarnos en este capítulo, las causas más importantes: - Objetivos poco claros. - Mala planificación. - Tecnología nueva. - Metodología de gestión de proyectos que no se usa. - Recursos humanos insuficientes. Por lo tanto la metodología para minimizar el fracaso es la utilización de gestión de proyectos. Eficientemente un gestor de proyectos puede aumentar las posibilidades de éxito del proyecto. La Gestión de Proyectos aplica el conocimiento, habilidades, herramientas y técnicas a las actividades de un proyecto para alcanzar con éxito los requisitos del proyecto. Trata de controlar y planificar adecuadamente las actividades de gestión de modo que se alcancen los objetivos cumpliendo en coste, tiempo y calidad. A continuación se ubican de forma ejemplificada los conceptos de los principales procesos de gestión de proyectos software. - Estimación: Es la fase donde se calcula los posibles recursos a utilizar, así como el tiempo de duración y costes. - Organización: Es la fase donde se organizan los recursos humanos y materiales a las distintas tareas de un proyecto software. - Planificación: Es la fase donde se identifican las tareas en el tiempo. - Seguimiento: Es la fase que estudia si el proyecto sigue el curso de su planificación inicial tanto en tiempo como en costes. Es importante destacar la relación entre los procesos de gestión: Pedro Escribano Romero Página 38 39 Figura 11: Relación entre procesos de gestión A continuación, se explica detalladamente cada una de estas metodologías y herramientas que se utilizan en cada una de ellas para obtener los resultados esperados. 6.1 ESTIMACIÓN DE PROYECTOS SOFTWARE El proceso de estimación es la primera etapa en la gestión de proyectos y proporciona un valor a un conjunto de variables para la realización de un trabajo dentro de un rango aceptable de tolerancia. Calcula la predicción de personal, del esfuerzo, de los costes y del tiempo que se requerirá para realizar todas las actividades y construir todos los productos asociados a un proyecto. La estimación es un proceso difícil de realizar, ya que no existe un modelo universal de estimación o fórmulas universalmente aplicables a todos los proyectos. Son muchas las personas implicadas en los proyectos a distintos niveles organizativos que precisan distintas vistas de la estimación. La utilidad de la estimación depende de la etapa del desarrollo. Uno de los objetivos de la estimación es buscar estimaciones claras y precisas al comienzo de un proyecto, pero esto no se puede obtener. Desde el punto de vista tecnológico es importante señalar que las nuevas tecnologías infieren directamente en la estimación y hay poco tiempo para adaptarse a dichos cambios. Muchas veces se dan casos en los que se tiende a subestimar y a realizar malas interpretaciones de las unidades de medida. Los requisitos de la persona encargada en realizar la estimación son generalmente profesionales que no tengan ningún interés, directo o indirecto en los resultados del proceso de estimación, guiado exclusivamente por su profesionalidad. La estimación es un proceso continuo, pero que va cambiando a medida que conocemos el proyecto. Es importante estimar en distintos momentos del proyecto para saber con exactitud las estimaciones a lo largo del desarrollo. Pedro Escribano Romero Página 3940 Existen dos tipos de salidas en el proceso de estimación. Según su grado de importancia, tenemos, información básica e información adicional. Como información básica obtenemos la cantidad del coste total y el tiempo que llevará hacerlo. Como información adicional obtenemos el esfuerzo, el tamaño del sistema, etc. Es importante destacar las unidades que se utilizar para medir el esfuerzo en la estimación. La unidad de esfuerzo utilizada es meses.hombre: 1 mes.hombre = horas de trabajo de un hombre en un mes 2 meses.hombre = 2 meses de trabajo de 1 persona 1 mes de trabajo de 2 personas A continuación se explica resumidamente los tipos de métricas existentes para realizar la estimación, pero antes de esto, es preciso definir que es una métrica, la cual se describe como una aplicación continua de técnicas basadas en las medidas de los procesos de desarrollo software y sus productos, para producir información de gestión significativa y a tiempo. Los tipos de métricas existentes son dos, del producto y del proceso. Las métricas del producto nos sirven para estimar según el tamaño: - Puntos de Función de Albretch. - Cocomo 81 - Cocomo II - Líneas de código. Las métricas del proceso nos sirven para estimar el tiempo de desarrollo y esfuerzo: - Basadas en opinión de expertos. - Analogías - Descomposición - Ecuaciones de estimación (Modelos estadísticos basados en teorías y modelos compuestos). Este proyecto se va a focalizar en realizar el estudio de Puntos de Función de Albrecht y Cocomo 81, para realizar sus Patrones de Producto correspondientes. Pedro Escribano Romero Página 4041 6.1.1 Puntos de función La métrica puntos de función es un método utilizado en la gestión de proyectos para medir el tamaño del software. Fue definida por Allan Albrecht en 1979 [10] y pretende medir la funcionalidad entregada al usuario independientemente de la tecnología utilizada para la construcción y explotación del software, y también ser útil en cualquiera de las fases de vida del software, desde el diseño inicial hasta la explotación y mantenimiento. Tradicionalmente se ha medido el tamaño del software mediante distintas métricas: recuento de las líneas de código, número de programas fuente, o técnicas similares, que no resultan aceptables como una buena práctica profesional debido a: - Su resultado depende fuertemente del entorno técnico y el lenguaje de programación utilizado. - Varía en función de la habilidad de cada programador y del uso de normas y metodologías. - No resultan significativas al usuario ni a la dirección. Cuando se trata de establecer métricas de productividad y calidad en la construcción de software, o realizar estimaciones de coste y duración, es imprescindible disponer de una medida fiable y comprensible del tamaño de lo que se construye. El coste de desarrollo de software por cada punto función varía dependiendo de la tecnología utilizada, el tamaño del proyecto, los requisitos de calidad exigidos y otros parámetros. La media general de todos los proyectos está en 11,35 horas.hombre por punto de función. La técnica de medición del tamaño en punto de función consiste en asignar una cantidad de "puntos" a una aplicación informática según la complejidad de los datos que maneja y de los procesos que realiza sobre ellos. Siempre tratando de considerarlo desde el punto de vista del usuario. El método de trabajo establece los siguientes pasos: - Determinar el tipo de recuento: Puede tratase de un proyecto, una mejora a una aplicación o recontar una aplicación ya instalada. Según el tipo se incluirán funciones de conversión, modificación y baja de funcionalidad. - Identificar el alcance del recuento y los límites de la aplicación: Se delimita el alcance de lo que se va a medir. - Contar las funciones de datos: Se realiza un inventario de los ficheros lógicos utilizados (vistos como un usuario) tanto internos de la aplicación como mantenidos por otra aplicación. Para cada uno de ellos se recuenta el número de datos y de registros lógicos. En función de este número se calcula para cada Pedro Escribano Romero Página 4142 fichero un índice de complejidad y posteriormente una contribución en puntos función. - Contar las funciones transaccionales: De modo similar se realiza un inventario de los procesos elementales del sistema, distinguiendo los procesos de entrada, salida y consulta. Según el número de ficheros lógicos y datos que maneja cada proceso y de su naturaleza, se calcula su índice de complejidad y su contribución en puntos de función. - Calcular el recuento bruto de puntos de función: A partir de los recuentos anteriores se calcula un recuento total bruto. - Determinar el factor de ajuste: En función de 14 "características generales del sistema" que se valoran de 0 a 5 en función de su grado de influencia, se calcula un factor de ajuste al recuento. Estas características tienen que ver con la arquitectura de la aplicación, sus requisitos de carga y rendimiento, complejidad de cálculos, etc. - Calcular el recuento ajustado: Aplicando el factor de ajuste al recuento bruto se obtiene el recuento final Cocomo 81 El Modelo Constructivo de Costes o Cocomo, es un modelo matemático de base empírica utilizado para la estimación de costes de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado. Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 [10] y comienzos de los 80, exponiéndolo detalladamente en su libro Software Engineering Economics. Pertenece a la categoría de modelos de subestimaciones basados en estimaciones matemáticas. Está orientado a la magnitud del producto final, midiendo el tamaño del proyecto, en líneas de código principalmente. Las ecuaciones que se utilizan en los tres modelos son: Donde: - E = a(kl) b * m(x), en persona-mes - Tdev = c(e) d, en meses - P = E / Tdev, en personas Pedro Escribano Romero Página 4243 - E: es el esfuerzo requerido por el proyecto, en persona-mes - Tdev: es el tiempo requerido por el proyecto, en meses - P: es el número de personas requerido por el proyecto - a, b, c y d: son constantes con valores definidos en una tabla, según cada submodelo - Kl: es la cantidad de líneas de código, en miles. - m(x): es un multiplicador que depende de 15 atributos. A la vez, cada submodelo también se divide en modos que representan el tipo de proyecto, y puede ser: - Modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles (medio). - Modo semilibre: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas. - Modo rígido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla. En las siguientes líneas se darán las pinceladas de las características con las que cuentan los modelos de Cocomo 81: - Modelo básico: Se utiliza para obtener una primera aproximación rápida del esfuerzo. - Modelo intermedio: Añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación. - Modelo detallado: Establece una jerarquía de tres niveles de productos, de forma que los aspectos que representan gran variación a bajo nivel, se consideran a nivel módulo, los que representan pocas variaciones, a nivel de subsistema; y los restantes son considerados a nivel sistema. Pedro Escribano Romero Página 4344 6.2 ORGANIZACIÓN DE PROYECTOS SOFTWARE La organización o estructuración de un proyecto se puede ver como el paso previo a la planificación del mismo, en la cual partiendo de la definición de los objetivos del proyecto, se llega la estructuración de las diferentes actividades que lo componen. Hay que tener en cuenta las siguientes pautas antes de realizar la organización de un proyecto: - Las tareas a llevar a cabo, que permitirán delimitar exactamente el alcance del proyecto. - Los productos resultantes de realizar cada una de las tareas, de modo que se pueda valorar más fácilmente la magnitud de cada una de ellas. - Los recursos disponibles, que posteriormente serán asignados a cada una de las tareas identificadas. Lo anterior lleva a concluir que existen una serie de factores que pueden alterar el buen desarrollo del proyecto. Por lo tanto, habrá que determinar: - Las tareas a realizar a lo largo de todo el desarrollo. - Los productos a entregar a lo largo del desarrollo. - Los recursos disponibles con sus costes asociados. La estructuración de un proyecto requiere de una disciplina mental que permita descomponer el proyecto desde múltiples puntos de vista, bien orientado a las tareas, a los productos o a los recursos. En los siguientes puntos se presentan las técnicas que permitirán plasmar de una forma gráfica el proceso mental que lleve a la estructuración de un proyecto en tareas, productos y recursos, y que se han tenido en cuenta para realizar posteriormente los patrones de producto asociados a esta WBS La descomposición de actividades, WBS o Work Breakdown Structure, es una representación gráfica de las diferentes actividades que se han de llevar a cabo para la realización de un proyecto. Dichas actividades estarán agrupadas por paquetes de trabajo. El propósito de un WBS es dividir el proyecto en porciones que posteriormente sean fáciles de planificar en tiempo, coste, recursos En el nivel más alto de la estructura WBS o primer nivel, se tendrá el principal objetivo del proyecto o fase que estemos gestionando. En el segundo nivel se tienen las metas Pedro Escribano Romero Página 4445 más significativas a alcanzar y en el tercer nivel una división de estas metas en hitos más pequeños. Así la estructura se divide en niveles y sub-niveles hasta alcanzar las llamadas unidades de trabajo. Todas las tareas tienen asignado un código numérico gracias al cual es posible identificar a que paquete de trabajo pertenece cada tarea y en qué nivel se encuentra situado dentro de la estructura. Las unidades de trabajo son actividades pequeñas, de una duración en torno a una semana y que son asignables a una persona. Desde el punto de vista de la Ingeniería del Software existen reglas generales aplicables a todo proyecto de desarrollo de software que serán las responsables de proporcionar las pautas necesarias para identificar el número de niveles de descomposición para el WBS. Por ejemplo, el criterio puede venir dado por las fases del ciclo de vida elegido para ese proyecto, por la metodología de desarrollo seleccionada, etc. Con la técnica de descomposición de actividades WBS no se ve claramente la dependencia entre las distintas tareas, ni el orden en que deben ejecutarse, por este motivo esta técnica debe ser complementada con otros diagramas que se verán a continuación en el apartado dedicado a las técnicas de planificación, Diagrama de Gantt PBS La descomposición según productos, PBS o Product Breakdown Structure, es una representación del producto o sistema a desarrollar en el proyecto en forma de árbol, que describe el producto a diferentes niveles, desde el más alto que representa todo el producto, y descendiendo progresivamente hacia subsistemas, elementos de configuración y componentes (niveles más bajos). Es un medio muy potente de definición de todas las partes, entregables y no entregables, del producto objeto del proyecto, que se apoya en las técnicas de gestión de la configuración. Los niveles que refleja un PBS son los siguientes: Nivel 0: Sistema Completo. Nivel 1: Subsistemas. Nivel 2: Elementos de configuración. Nivel 3: Componentes software. Como regla general, la estructura de un PBS tiene un nivel más que el WBS del mismo proyecto. En dicho nivel se incluyen las tareas propias de cada una de las tareas del último nivel, identificadas en el WBS. Pedro Escribano Romero Página 4546 6.2.3 RBS La descomposición en recursos, RBS o Resource Breakdown Structure es un árbol jerárquico que representa los recursos humanos y materiales del proyecto. Esta técnica de organización de proyectos software tiene por objeto representar la organización de recursos humanos del proyecto, su estructura, responsabilidades, etc. así como la estructura de recursos tecnológicos y materiales. Los principales objetivos del RBS son los siguientes: - Mostrar gráficamente la organización humana y material del proyecto. - Maximizar el uso de los conocimientos y experiencia del personal disponible. - Reflejar la estructura de recursos materiales necesarios para la realización del proyecto (herramientas y plataforma), así como sus costes asociados. En general, la estructura jerárquica que se refleja en la parte correspondiente a los recursos humanos del RBS viene marcada por las políticas propias de la organización en la que se vaya a desarrollar el proyecto software. Aun así, existen algunas reglas generales aplicables a todos los desarrollos software y que son independientes de la organización en la que se esté llevando a cabo el desarrollo software. A continuación se identifican dichas reglas: - El responsable de calidad y el jefe de proyecto no deben depender uno del otro, ya que sus tareas deben ser absolutamente independientes y no deben estar supeditadas las unas a las del otro. - Un jefe de proyecto no debería gestionar a un equipo formado por más de siete personas. Ello implica que debería existir un jefe de proyecto por cada siete personas que se precisen para llevar a cabo un proyecto software. El RBS puede representarse de modo que se puedan observar por separado los recursos con los que cuenta la propia organización y por otro lado, los recursos con los que se cuenta del lado del cliente, para el cual se está llevando a cabo el proyecto. Pedro Escribano Romero Página 4647 6.3 PLANIFICACIÓN DE PROYECTOS SOFTWARE El proceso de planificación toma su entrada del proceso de estimación y de organización, y se define como el proceso de selección de una estrategia para la obtención de unos productos finales dados. Los objetivos de la planificación son los siguientes: - Identificar de una forma precisa lo que se debe hacer. - Identificar la secuencia de realización - Establecer la coherencia con los recursos disponibles. - El conjunto de actividades de un proyecto debe satisfacer un conjunto de restricciones. - El conjunto de actividades de un proyecto debe de alcanzar un objetivo preestablecido. - La planificación divide el tiempo y coste y lo reparte entre tareas, asignándole recursos a estas tareas. - Transforma el modelo teórico en un plan de acción aplicable, es decir: - Lo que debe ser hecho - Lo que es necesario - Y en qué orden - De lo que se dispone - Objetivos a alcanzar - Plan de acciones - Presupuestos Figura 12: Transformación del modelo teórico en un plan de acción Para adentrarnos en el lenguaje que se utiliza en la planificación es importante tener clara las definiciones de proyecto, actividad, tarea y estado de la tarea. Un proyecto es un conjunto de actividades, eventos e hitos entrelazados para la consecución de un resultado común. Una actividad expresa un trabajo a realizar para alcanzar un resultado específico. La actividad requiere tiempo y recursos. Puede comprender un conjunto de acciones y tareas. Una tarea es una actividad que deriva en un resultado entregable único. Supone el nivel de detalle mínimo. Pedro Escribano Romero Página 4748 El estado de la tarea puede tomar los valores: no comenzada, en proceso, parada, abandonada o terminada. Las técnicas usadas para la planificación de proyectos y que explicaremos más extensamente a continuación son las siguientes: - Análisis de redes (Network Analysis) - Método del camino critico (CPM) - PERT (Programme Evaluation Review Technique) - Diagrama de Gantt Este proyecto se centra en el Diagrama de Gantt, para posteriormente realizar su patrón de producto asociado Diagrama Gantt El Diagrama de Gantt es un gráfico que permite la visualización clara y completa de la ubicación de las actividades en el tiempo. Tiene forma de tabla, en la que cada columna representa una unidad de tiempo (Día, semana o mes), y cada fila, una actividad. Un diagrama Gantt no representa las relaciones de precedencia/sucesión de actividades. El nombre de la actividad se sitúa a la izquierda de la tabla, y a su misma altura (en la misma fila) se dibuja un segmento (barra) que va desde la fecha de comienzo a la de finalización de la actividad. También se pueden representar los márgenes libre y total de las actividades. Mediante el diagrama Gantt, y a través de la suma por columnas de los recursos que intervienen en cada actividad, se puede obtener el diagrama de carga de recursos del proyecto (por cada tipo de recurso o del total de recursos). Este diagrama representará los picos y valles de recursos del proyecto. Puesto que, normalmente, por cada tipo de recursos existirá un máximo, a partir de este diagrama se puede nivelar el uso de recursos teniendo en cuenta los márgenes libres (no los totales) de cada actividad. En caso de que, aun realizando esta nivelación, faltaran recursos, habría que nivelar en base a los márgenes totales, y en último extremo incrementar el número de recursos o desplazar la fecha de finalización del proyecto. Los diagramas Gantt de seguimiento presentan dos tipos de barras: las de las fechas de comienzo y finalización previstas y las de las fechas de comienzo y/o finalización reales. Pedro Escribano Romero Página 4849 6.4 SEGUIMIENTO DE PROYECTOS SOFTWARE El seguimiento de un proyecto es el proceso de obtención de información acerca del progreso, estado y trayectoria del proyecto. Las principales fases en la realización del seguimiento son: 1- Obtención de información. 2- Análisis. 3- Comparación. 4- Acción correctora en el caso de que proceda. El seguimiento facilita una visión adecuada del progreso real, de forma que la dirección pueda tomar unas medidas eficaces cuando el desarrollo del proyecto software se desvía notablemente de los planes software. Para ello es necesario establecer marcas de seguimiento o hitos. A continuación se identifican los objetivos que busca el seguimiento en un proyecto software: - Identificar diferencias entre lo planificado y lo realizado. - Evaluar el avance del proyecto. - Adaptar el plan de acción a las diferencias encontradas. - Prever desviaciones importantes para buscar remedios. - Contribuir a la creación de históricos. - Contabilizar costes de cada actividad. El seguimiento es una acción que realiza el jefe de proyectos. Su bondad depende de la transparencia y etiquetado del proyecto, es decir, del almacenamiento del progreso del mismo. El seguimiento puede hacerse en varias partes del proyecto. De esta forma el seguimiento se realizará: - Inmediatamente después de hacer la planificación detallada. - Periódicamente se deberán recoger medidas de avance y se verán las diferencias si estas existiesen. - En periodos más grandes se revisan desviaciones y se decide cómo afectan al Plan de proyecto. Pedro Escribano Romero Página 4950 - En ciertos hitos importantes se revisa el progreso y se toman medidas correctoras. El seguimiento se realiza en función de dos factores, duración y actuación. Cada tipo de factor tiene sus herramientas que resumiremos aquí en primer lugar, para más adelante explicarlas en profundidad. - Seguimiento en función de la duración: Seguimiento a corto plazo (cada semana) Seguimiento a largo plazo (cada mes) - Seguimiento en función de la actuación: Estático: Básicamente vamos anotando en fichas el seguimiento del proyecto. Dinámico: Se realiza con un Gantt de seguimiento. Predictivo: Se realiza mediante el diagrama de 45 grados o con la técnica del valor conseguido. Este proyecto se centra en el seguimiento predictivo, concretamente con la técnica de valor conseguido Seguimiento predictivo: valor conseguido La gestión del valor conseguido es una técnica de gestión de proyectos que permite controlar la ejecución de un proyecto a través de su presupuesto y de su calendario de ejecución. Compara la cantidad de trabajo ya completada en un momento dado con la estimación realizada antes del comienzo del proyecto. De este modo, se tiene una medida de cuánto trabajo se ha realizado, cuanto queda para finalizar el proyecto y extrapolando a partir del esfuerzo invertido en el proyecto, el jefe de proyecto puede estimar los recursos que se emplearán para finalizar el proyecto. Con esta metodología se puede estimar en cuanto tiempo se completaría el proyecto si se mantienen las condiciones con las que se elaboró el cronograma o considerando si se mantienen las condiciones que se presentaron durante el desarrollo del proyecto. También se puede estimar el costo total del proyecto. Cuenta con las siguientes variables o formulas: Pedro Escribano Romero Página 5051 - Trabajo previsto o presupuestado: PRE - Trabajo o valor conseguido: CON - Trabajo invertido o valor actual: ACT - Varianza de coste: CON-ACT - Varianza de plazo: CON-PRE - Varianza de coste relativa: VCR= (CON-ACT)/ACT - Varianza de plazo relativa: VPR= (CON-PRE)/PRE - Índice de eficiencia de coste: IEC=CON/ACT - Índice de eficiencia de plazo: IEP=CON/PRE - Porcentaje completado: (CON/LBAC)*100 - Porcentaje gastado: (ACT/LBAC)*100 Pedro Escribano Romero Página 5152 7. BENEFICIOS DE LA GESTION DE PROYECTOS SOFTWARE En este punto se explica cuales son los beneficios de realizar una buena gestión a un proyecto software. Los beneficios más importantes son los siguientes: - En el caso de que el cliente quiera realizar cambios en sus requisitos iníciales, la respuesta por parte del equipo de proyectos será rápida. Cuenta con la capacidad de adaptarse a requisitos cambiantes. - La organización con la que se cuenta al gestionar un proyecto software, todos los implicados saben sus responsabilidades y trabajaran exclusivamente por ellas, llevando a buen fin el proyecto software que están desarrollando. De esta forma, la empresa puede quedar segura de que todo el equipo de trabajo conoce sus responsabilidades. Al tener todo el equipo organizado, ellos mismos son capaces de identificar mejoras en algunos procesos, lo que puede llevar a grandes ahorros de tiempo y presupuesto. - En algunas ocasiones, y sobre todo cuando los proyectos son muy grandes, la empresa puede recurrir a la utilización de recursos internos y externos. Gracias a una buena coordinación de estos recursos todo el equipo será capaz de trabajar en el mismo camino sin que existan desviaciones. - Con la forma de trabajo conjunta entre los distintos departamentos del proyecto, la comunicación de este equipo es excelente. De esta forma los conocimientos y mejoras que puedan surgir, podrán ser transferidos entre distintos departamentos, que de no realizar una gestión de proyectos sería nula esta comunicación. Los presupuestos y planificación del proyecto software estará presente en estos departamentos y serán capaces de marcar prioridades cuando la planificación esté más ajustada. - Gracias a la gestión de proyectos software y de toda la documentación que se crea durante la elaboración del proyecto y a su finalización, será una gran experiencia con la que contará ese equipo de desarrollo cuando le vengan proyectos futuros. Toda esta experiencia con la que contará el equipo se verá reflejada en la planificación del nuevo proyecto software. - Gracias a la estimación previa que se hace al inicio de un proyecto software y al seguimiento que se hace durante su elaboración, se puede saber la capacidad que tiene el equipo en su conjunto, y separadamente cada trabajador del mismo. Pedro Escribano Romero Página 5253 - Cuando un proyecto software está retrasado y no sigue la planificación establecida, se tomarán medidas correctivas en fases tempranas para solucionar este problema y que no influya a las demás actividades del proyecto. - Existe un jefe de proyectos software que hará la función de interlocutor entre el cliente y el equipo de trabajo, y defenderá sus intereses dentro de la organización. - El jefe de proyecto será la persona indicada para realizar los informes que posteriormente pasará al gerente del proyecto. Esto hace que la información quede centralizada en el jefe de proyectos y se reduzcan la necesidad de que los miembros del equipo de proyecto estén realizando informes frecuentemente. - La realización de gestión de proyectos software garantiza una calidad en el producto final obtenido, cumpliendo con los requisitos y adecuación de uso, exigida por el cliente. Pedro Escribano Romero Página 5354 8. ROLES DEL PERSONAL DE UN PROYECTO DE DESARROLLO SOFTWARE En este punto se explican los roles y las funciones que tiene un equipo de desarrollo software. Jefe de proyecto software: Es el responsable del proyecto y actúa de interlocutor entre la dirección de la empresa y el cliente. Sus funciones a destacar son las siguientes: o Es el responsable del presupuesto, del cumplimiento de los plazos, y de la aplicación del Plan de Gestión realizado y del Plan de Calidad del Software en cuya elaboración también participa. o Es el responsable de las fases de Especificación de requisitos por parte del cliente, diseño de arquitectura e integración del producto. Participa en la validación del producto software. o Define la modalidad de gestión de la configuración. o Es el responsable de la gestión, el encuadramiento y la coordinación de los equipos. o Es el responsable de la fase de validación del producto software. o Es el interlocutor con el cliente. Responsable de equipo: Es el responsable del desarrollo de las tareas asignadas a su equipo. Sus funciones a destacar son las siguientes: o Es el encargado de realizar las tareas de gestión de proyectos, planificación detallada y seguimiento, para el trabajo asignado a su equipo. o Participa en el diseño de arquitectura. o Es el responsable de las fases de diseño detallado, codificación, y pruebas unitarias de la parte que le concierne. o Realiza la dirección técnica del equipo. Pedro Escribano Romero Página 5455 Personal de desarrollo: Son las personas encargadas en realizar las actividades técnicas dentro del proyecto. Responsable de la gestión de configuración: Es el responsable de la existencia de coherencia en la configuración. Sus funciones a destacar son las siguientes: o Identifica los elementos de la configuración. o Controla y administra las modificaciones. o Controla las bibliotecas del proyecto. Responsable de calidad: Es el responsable de garantizar la calidad del software y garantiza esta calidad ante un posible cliente externo. Sus funciones a destacar son las siguientes: o Dirige el Plan de Calidad del Software de acuerdo con el jefe del proyecto. o Asegura las acciones para el seguimiento de la calidad del proyecto (revisiones, inspecciones, auditorias, etc.), controlando a los posibles subcontratistas del proyecto. o Define las medidas de calidad a realizar. o Interpreta el balance del proyecto en lo referente a calidad. En general, estos son los roles para el desarrollo de un proyecto software, aunque en algunos proyectos pueden existir otras funciones tales como responsable de herramientas de desarrollo, asistencia metodológica, expertos, etc. También hay que destacar que en función del tamaño del proyecto, es posible que una persona del equipo de desarrollo pueda realizar varias funciones o roles. Como consejo para el buen funcionamiento del proyecto, es conveniente que los responsables de equipo no tengan más de 7 u 8 personas bajo su responsabilidad. Pedro Escribano Romero Página 5556 9. DESCRIPCIÓN GLOBAL DEL PROYECTO El principal objetivo del proyecto consiste en generar unidades de conocimiento transferibles y reutilizables relacionadas para los procesos de gestión de proyectos de desarrollo software. Para ello, en primer lugar, se han construido patrones de producto que encapsulan el conocimiento sobre un conjunto de técnicas de gestión de proyectos, que serán accesibles a través de un portal de Learning Management System y a través de la propia wiki donde están ubicados. Un patrón de producto es un artefacto que almacena el conocimiento de los ingenieros expertos para obtener un producto software específico. Entendiendo como producto el elemento mínimo en la ingeniería del software que se obtiene de la ejecución de una actividad. Por lo se han desarrollado patrones de producto que almacenan y reutilizan el conocimiento sobre gestión de proyectos. En el portal de soporte construido para la gestión de proyectos, aparte de encontrarse los patrones de producto, el usuario encontrará diversa información de utilidad para sacar adelante un proyecto o para aprender a gestionarlos. Existen unidades didácticas de sus distintas fases, casos prácticos resueltos, videos explicativos, etc. en general un gran material didáctico para su aprendizaje. En una segunda fase del proyecto se ha realizado un estudio de validación, mediantes unos casos prácticos, de la solución propuesta para demostrar los beneficios que se obtienen. Este estudio consta de varias etapas. En la primera etapa se resolverán unos casos prácticos sin la ayuda de patrones de producto, se recogerán los tiempos empleados en su resolución y se tomarán notas o características expuestas por los usuarios. En la segunda etapa se resolverán unos casos prácticos con la ayuda de patrones de producto, e igualmente, se recogerán los tiempos empleados en su resolución y se tomarán notas o características expuestas por los usuarios. En una última etapa, se analizarán los tiempos recogidos en las etapas anteriores y se compararán, argumentando los beneficios de la utilización de los patrones de producto creados. Por último se ha elaborado un test de usabilidad con el fin de hacérselo llegar a todos los usuarios para comprobar opiniones y realizar así el propio análisis de usabilidad, para posibles mejoras o cambios que pudiesen surgir. Pedro Escribano Romero Página 5657 Las métricas de usabilidad analizadas son: facilidad de aprendizaje, percepción de utilidad, facilidad de uso y la satisfacción. Con todo lo explicado, y como se verá paso por paso seguidamente, se verifican los beneficios que tiene la utilización de los patrones de producto creados para la gestión de proyectos. 9.1 PATRONES DE PRODUCTO DE GESTIÓN DE PROYECTOS En este punto del proyecto se explica en profundidad que es un patrón de producto y se presentan los patrones de productos creados para la gestión de proyectos. Un patrón de producto es un artefacto que permite la encapsulación del conocimiento que tienen los expertos en ingeniería del software para crear cualquier producto software del ciclo de vida de desarrollo del software. Dicho conocimiento, es presentado de una manera accesible y fácil de comprender, con la intención de promover y difundir el uso y reutilización de las buenas prácticas de la ingeniería del software. Según Christopher Alexander [11], cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, así como la solución a ese problema, de tal modo que se pueda aplicar esta solución un millón de veces, sin hacer lo mismo dos veces. Se dio cuenta de la necesidad de crear un formato único de documentación para unir distintos tipos de conocimiento. Los Patrones de Producto fueron creados para determinar cómo debe ser creado un producto software durante la ejecución de un proyecto de desarrollo de software. Para utilizarlos, los jefes de proyecto o los desarrolladores de software tienen la posibilidad de utilizar uno o varios patrones para llevar a cabo las actividades de un proyecto en el que estén involucrados, siguiendo la siguiente regla: SI te encuentras a ti mismo dentro de este contexto ENTONCES (y) con este problema concreto (y) satisfaces este conjunto de fuerzas Enlaza este patrón de producto a tu proyecto (y) busca más patrones Figura 13: Algoritmo para encontrar un patrón de producto Si se acepta que los patrones pueden resultar útiles en el desarrollo de software, el siguiente paso es reunirlos en catálogos de forma que resulten accesibles mediante distintos criterios, pues lo que se necesita no es tan solo la completa descripción de cada Pedro Escribano Romero Página 5758 uno de los patrones sino, esencialmente, la correspondencia entre un problema real y un patrón (o conjunto de patrones) determinado. Un catalogo de patrones es un medio para comunicar la experiencia de forma efectiva, reduciendo lo que se conoce como curva de aprendizaje. Los patrones de producto deben de tener una estructura de contenido fija. El formato de los patrones de producto creados para la gestión de proyectos, cuentan con las características que se exponen en la siguiente tabla: NOMBRE PATRONES RELACIONADOS CONTEXTO INICIAL CONTEXTO RESULTANTE PROBLEMA RESTRICCIONES SOLUCIÓN ROLES ENTRADAS SALIDAS PLANTILLAS EJEMPLOS LECCIONES APRENDIDAS NIVEL DE MADUREZ REFERENCIAS BIBLIOGRÁFICAS CONOCIMIENTOS BÁSICOS CAMPOS DE UN PATRÓN DE PRODUCTO Nombre del Patrón de Producto. Nombre de los patrones de producto relacionados con el que se está describiendo. Contexto inicial del patrón de producto. Contexto resultante de haber ejecutado el patrón de producto. Descripción del problema. Restricciones bajo las cuales se ejecuta el patrón de producto. Relaciones estratégicas y reglas dinámicas que describen cómo conseguir el producto. Roles implicados en el desarrollo del producto. Productos que son requeridos para poder aplicar el patrón de producto. Producto que se obtiene de la realización del patrón de producto. Plantilla que permitirá realizar el proceso software de una forma más usable. Ejemplos de haber aplicado el patrón de producto en otros desarrollos software. Lecciones aprendidas. Nivel de madurez que se obtiene una vez realizado el patrón del producto. Referencias bibliográficas que puede utilizar el usuario a la hora de desarrollar los pasos descritos en el campo solución. Conocimiento básico que tiene que tener el usuario que quiera utilizar el patrón de producto. Tabla 7: Campos de un patrón de producto Pedro Escribano Romero Página 5859 No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error". El acceso a los patrones creados para la gestión de proyectos, se puede hacer desde la propia wiki donde están alojados, o mediante el portal de apoyo a la gestión de proyectos. El tener dos tipos de acceso a los patrones de producto hace que se pueda observar el comportamiento de los usuarios, ya que su nivel docente es bastante avanzado, y podemos sacar así conclusiones posteriores sobre el acceso a los mismos. Para esto se les ofreció a los usuarios un login y password para que puedan acceder desde la wiki, si así lo desean, aunque actualmente el acceso es público. Para ambos tipos de acceso, se han observado las estadísticas de uso de los patrones, sabiendo por lo tanto, la fecha de última conexión, número de accesos y tiempo de uso de los mismos. Los patrones de producto creados para la ayuda en la gestión de proyectos se encuentran en la siguiente dirección: Es una wiki para facilitar la encapsulación del conocimiento y promover su reutilización y aprendizaje. En el siguiente punto, 9.2 Descripción de la Wiki, se explica de forma extensa la wiki donde se alojan los patrones de producto. Pedro Escribano Romero Página 5960 9.1.1 Patrón de Producto: Puntos de función de Albrecht sin ajustar SECCIÓN NOMBRE DEL PATRÓN PATRONES RELACIONADOS CONTEXTO INICIAL DESCRIPCIÓN Puntos de función de Albrecht sin ajustar. Puntos de función de Albrecht ajustados. Este producto puede utilizarse en la primera etapa de gestión de proyectos que requiera un proceso de estimación para medir el software cualificando la funcionalidad que proporciona externamente basándose en el diseño lógico del sistema. Si un sistema tiene varios subsistemas será preciso estimar los subsistemas por separado y luego sumarlos. CONTEXTO RESULTANTE Se obtendrá una predicción de personal, del esfuerzo, de los costes y del tiempo que se requerirá para realizar todas las actividades y construir todos los productos asociados a un proyecto. PROBLEMA Se desea crear un documento que detalle de manera precisa la estimación al proyecto que se está desarrollando. El personal encargado en realizar esta tarea debe ser capaz de identificar entradas, salidas y consultas al sistema, cantidad de ficheros lógicos internos y ficheros lógicos externos. RESTRICCIONES (FORCES) Características de las organizaciones: Este patrón puede utilizarse en los proyectos existentes en cualquier tipo de compañía. Tipo de sistema a desarrollar: Este producto puede utilizarse en proyectos en los que los requerimientos de usuario sean cambiantes. Tipo de cliente: Debe existir, o debe conseguirse, que el área de negocio destinataria del desarrollo se implique en la consecución del mismo. Heurísticas de uso: Si se necesita disponer urgentemente del aplicativo o de algunas de sus funcionalidades. ENTRADAS Documento de especificación de requisitos o descripción del problema. Pedro Escribano Romero Página 60 61 SALIDAS MEDIDAS DIRECTAS: o Estimación software. o Puntos de función. MEDIDAS INDIRECTAS: o Productividad. o Calidad. o Coste. o Documentación. o Líneas de código. PROCESO Pedro Escribano Romero Página 6162 TIEMPO DE DESARROLLO Para adquirir el conocimiento necesario para desarrollar el producto software: 4 horas. Para crear el Patrón de Producto: 2 días. Para aplicar el Patrón de Producto: 2 horas. ROLES VIDEO EXPLICACIÓN Gerente del proyecto. Este Patrón de Producto no tiene relacionado ningún video. LECCIONES APRENDIDAS ILF y EIF son elementos tipo dato porque están relacionados con datos del sistema. En ILF los datos son mantenidos y utilizados dentro de la aplicación a diferencia de EIF que es mantenida por otro sistema. Si una entrada no modifica un ILF, no es una entrada Reglas para identificar DET: o Contar cada campo único y no recursivo. o Contar un DET por cada dato que exista en un EIF. Reglas para identificar RET: o Contar un RET por cada grupo de DETs. o Contar un RET siempre por defecto. Reglas para identificar FTR: o Número de accesos a datos cuando se procesa la función tipo transacción. NIVEL DE MADURÉZ Este Patrón de Producto no se relaciona con ningún nivel de madurez(n/a). CONOCIMIENTOS BÁSICOS Conocimientos: Definición de requisitos software. Conocimientos previos sobre Lógica de la Programación e Ingeniería del Software I. Conocimientos en Diseño de Bases de datos. Habituarse a utilizar un paradigma concreto. Habilidades: Capacidad de análisis. Capacidad de abstracción. Pedro Escribano Romero Página 6263 CONTROLADORES DE CALIDAD PLANTILLAS EJEMPLOS HERRAMIENTAS DE SOPORTE Ninguno Tabla complejidad EI,EO,EQ.JPG Tabla complejidad ILF,EIF.JPG PLANTILLA_PFs.doc ejemplo PF sin ajustar.pdf Microsoft Word Open office Writer RECURSOS DE INFORMACIÓN Gonzalo, Agustín y de Amescua Antonio. Gestión del proceso software. Ed. Centro de Estudios Ramón Areces DeMarco, Tom. Controlling software projects. Ed Yourdon Press Sommerville, Ian. Ingeniería del software. Ed. Addison-Wesley Dolado, J.L. y Fernández, L. Medición para la gestión en la ingeniería del software. Ed. RAMA McConell, Steve. Desarrollo y gestión de proyectos informáticos. Ed. Mc Graw Hill Pressman, R. Ingeniería del Software, Un enfoque práctico, 6ª edición. Ed. Mc Graw Hill López-Cortijo y Amescua. Ingeniería del Software: Aspectos de Gestión. Ed. Instituto Ibérico de la Industria del Software Garmus, David y Herron, David. Measuring the software process: a practical guide to functional measurements. Ed. Yourdon Press computing series Pedro Escribano Romero Página 6364 9.1.2 Patrón de Producto: Puntos de función de Albrecht ajustados SECCIÓN NOMBRE DEL PATRÓN PATRONES RELACIONADOS CONTEXTO INICIAL CONTEXTO RESULTANTE PROBLEMA RESTRICCIONES (FORCES) DESCRIPCIÓN Puntos de función de Albrecht ajustados Puntos de función de Albrecht sin ajustar Este producto puede utilizarse en la primera etapa de gestión de proyectos que requiera un proceso de estimación para medir el software cualificando la funcionalidad que proporciona externamente basándose en el diseño lógico del sistema. Se obtendrá una predicción de personal, del esfuerzo, de los costes y del tiempo que se requerirá para realizar todas las actividades y construir todos los productos asociados a un proyecto. Se desea crear un documento que detalle de manera precisa la estimación al proyecto que se está desarrollando. El personal encargado en realizar esta tarea debe ser capaz de identificar de qué tipo de proyecto se trata y cuál es el entorno o restricciones en el que se va a realizar. Además será capaz de identificar y dar valor a atributos de producto, ordenador, personales y del proyecto en general. Características de las organizaciones: Este patrón puede utilizarse en los proyectos existentes en cualquier tipo de compañía. Tipo de sistema a desarrollar: Este producto puede utilizarse en proyectos en los que los requerimientos de usuario sean cambiantes. Tipo de cliente: Debe existir, o debe conseguirse, que el área de negocio destinataria del desarrollo se implique en la consecución del mismo. Heurísticas de uso: Si se necesita disponer urgentemente del aplicativo o de algunas de sus funcionalidades. ENTRADAS Documento de especificación de requisitos o descripción del problema. SALIDAS MEDIDAS DIRECTAS: o Estimación software. o Puntos de función. MEDIDAS INDIRECTAS: o Productividad. Pedro Escribano Romero Página 64 65 PROCESO o Calidad. o Coste. o Documentación. o Líneas de código. Pedro Escribano Romero Página 6566 TIEMPO DE DESARROLLO Para adquirir el conocimiento necesario para desarrollar el producto software: 4 horas. Para crear el Patrón de Producto: 2 días. Para aplicar el Patrón de Producto: 2 horas. ROLES Gerente del proyecto. VIDEO EXPLICACIÓN Este Patrón de Producto no tiene relacionado ningún video. LECCIONES APRENDIDAS Al calcular el valor de grado de influencia en GDI, hay que tener en cuenta ciertos criterios: Las entradas de datos on-line, se refiere a si las entradas son interactivas, no si el procesamiento es on-line. En la eficiencia de usuario, como ayuda, si se trata de un sistema Batch, esta característica será siempre cero porque no se pone mucho interés en el diseño de interfaz de esto tipo de aplicaciones. Hay que tener claro y saber diferenciar para evitar errores la diferencia entre entrada on-line y actualización on-line. NIVEL DE MADURÉZ Este Patrón de Producto no se relaciona con ningún nivel de madurez(n/a). CONOCIMIENTOS BÁSICOS Conocimientos: Definición de requisitos software. Conocimientos previos sobre Lógica de la Programación e Ingeniería del Software I. Conocimientos en Diseño de Bases de datos. Habituarse a utilizar un paradigma concreto. Habilidades: Capacidad de análisis. Capacidad de abstracción. CONTROLADORES DE CALIDAD PLANTILLAS Ninguno Plantilla_GDI.doc Pedro Escribano Romero Página 6667 EJEMPLOS HERRAMIENTAS DE SOPORTE RECURSOS DE INFORMACIÓN Ejemplo PF ajustados.pdf Microsoft Word Open office Write Gonzalo, Agustín y de Amescua Antonio. Gestión del proceso software. Ed. Centro de Estudios Ramón Areces DeMarco, Tom. Controlling software projects. Ed Yourdon Press Sommerville, Ian. Ingeniería del software. Ed. Addison-Wesley Dolado, J.L. y Fernández, L. Medición para la gestión en la ingeniería del software. Ed. RAMA McConell, Steve. Desarrollo y gestión de proyectos informáticos. Ed. Mc Graw Hill Pressman, R. Ingeniería del Software, Un enfoque práctico, 6ª edición. Ed. Mc Graw Hill López-Cortijo y Amescua. Ingeniería del Software: Aspectos de Gestión. Ed. Instituto Ibérico de la Industria del Software Garmus, David y Herron, David. Measuring the software process: a practical guide to functional measurements. Ed. Yourdon Press computing series Pedro Escribano Romero Página 6768 9.1.3 Patrón de Producto: Cocomo81 SECCIÓN DESCRIPCIÓN NOMBRE DEL PATRÓN Cocomo 81 PATRONES RELACIONADOS Puntos de función Ajustados CONTEXTO INICIAL Este producto puede utilizarse en cualquier tipo de proyecto durante las fases de Planificación y Definición de Requisitos, Diseño de Producto, Diseño detallado, Codificación y pruebas unitarias, Integración y Pruebas, Implantación, Explotación y Mantenimiento. Es utilizado para realizar estimaciones de costes software. CONTEXTO RESULTANTE El jefe de proyectos obtendrá una predicción de personal, del esfuerzo realizado por el equipo de desarrollo, de los costes y la duración del proyecto para realizar todas las actividades y construir todos los productos asociados a un proyecto. PROBLEMA El jefe de proyectos desea crear un documento que detalle de manera precisa la estimación al proyecto que se está desarrollando. El personal encargado en realizar esta tarea debe ser capaz de identificar de qué tipo de proyecto se trata y cuál es el entorno o restricciones en el que se va a realizar. Además será capaz de identificar y dar valor a atributos de producto, ordenador, personales y del proyecto en general. RESTRICCIONES (FORCES) Características de las organizaciones: Este patrón puede utilizarse en los proyectos existentes en cualquier tipo de compañía. Tipo de sistema a desarrollar: Este producto puede utilizarse en proyectos en los que los requerimientos de usuario sean cambiantes. Pedro Escribano Romero Página 6869 Tipo de cliente: Debe existir, o debe conseguirse, que el área de negocio destinataria del desarrollo se implique en la consecución del mismo. Heurísticas de uso: Si se necesita disponer urgentemente del aplicativo o de algunas de sus funcionalidades. ENTRADAS Documento de especificación de requisitos o descripción del problema. Tamaño del software a realizar (Líneas de código). Puntos de Función de Albrecht. SALIDAS MEDIDAS DIRECTAS: o Esfuerzo del equipo de desarrollo. o Duración del proyecto. MEDIDAS INDIRECTAS: o Productividad. o Calidad. o Coste. o Documentación. o Líneas de código. PROCESO Pedro Escribano Romero Página 6970 Pedro Escribano Romero Página 7071 TIEMPO DE DESARROLLO ROLES Para adquirir el conocimiento necesario para desarrollar el producto software: 4 horas. Para crear el Patrón de Producto: 2 días. Para aplicar el Patrón de Producto: 2 horas. Jefe del proyecto. VIDEO EXPLICACIÓN Este Patrón de Producto no tiene relacionado ningún video. LECCIONES APRENDIDAS Para evitar errores al realizar la estimación hay que tener siempre en cuenta que primero se determina el modelo de estimación y después se elige el modo de desarrollo. El esfuerzo es lo primero que se debe calcular y es medido en MM (meses hombre). NIVEL DE MADURÉZ Este Patrón de Producto no se relaciona con ningún nivel de madurez(n/a). CONOCIMIENTOS BÁSICOS Conocimientos: Definición de requisitos software. Conocimientos previos sobre Ingeniería del Software I o Lógica de la Programación. Habituarse a utilizar un paradigma concreto. Habilidades: Capacidad de análisis. Capacidad de abstracción. CONTROLADORES DE CALIDAD PLANTILLAS Ninguno. COCOMO-81-II-Conductores-coste.doc EJEMPLOS Ejemplo Cocomo81.pdf HERRAMIENTAS DE SOPORTE Microsoft Word. OpenOffice Writer. Pedro Escribano Romero Página 7172 Barry w. Boehm. Software Engineering Economics. Engineering-Economics-Barry- Boehm/dp/ #reader_ RECURSOS DE INFORMACIÓN Gonzalo, Agustín y de Amescua Antonio. Gestión del proceso software. Ed. Centro de Estudios Ramón Areces DeMarco, Tom. Controlling software projects. Ed Yourdon Press Sommerville, Ian. Ingeniería del software. Ed. Addison-Wesley Dolado, J.L. y Fernández, L. Medición para la gestión en la ingeniería del software. Ed. RAMA McConell, Steve. Desarrollo y gestión de proyectos informáticos. Ed. Mc Graw Hill Pressman, R. Ingeniería del Software, Un enfoque práctico, 6ª edición. Ed. Mc Graw Hill López-Cortijo y Amescua. Ingeniería del Software: Aspectos de Gestión. Ed. Instituto Ibérico de la Industria del Software Garmus, David y Herron, David. Measuring the software process: a practical guide to functional measurements. Ed. Yourdon Press computing series Pedro Escribano Romero Página 7273 9.1.4 Patrón de Producto: WBS SECCIÓN NOMBRE DEL PATRÓN WBS DESCRIPCIÓN PATRONES RELACIONADOS Ninguno. CONTEXTO INICIAL Este producto puede utilizarse en cualquier tipo de proyecto y se utilizará como herramienta de organización, seguimiento y estimación. Es un paso previo a la planificación del mismo proyecto, en la cual partiendo de la definición de los objetivos del proyecto, se llega a la estructuración de las diferentes actividades que lo componen. CONTEXTO RESULTANTE El jefe de proyectos obtendrá una representación gráfica de las diferentes actividades que se han de llevar a cabo para la realización de un proyecto. Dichas actividades estarán agrupadas por paquetes de trabajo. PROBLEMA El jefe de proyectos será capaz de dividir el proyecto en porciones que posteriormente sean fáciles de planificar en tiempo, coste, recursos y sirva para organizar el proyectos de forma eficiente. RESTRICCIONES (FORCES) Características de las organizaciones: Este patrón puede utilizarse en los proyectos existentes en cualquier tipo de compañía. Tipo de sistema a desarrollar: Este producto puede utilizarse en proyectos en los que los requerimientos de usuario sean cambiantes. Tipo de cliente: Debe existir, o debe conseguirse, que el área de negocio destinataria del desarrollo se implique en la consecución del mismo. Heurísticas de uso: Si se necesita disponer urgentemente del aplicativo o de algunas de sus funcionalidades. ENTRADAS Tareas a realizar. SALIDAS Representación gráfica de las distintas tareas ordenadas. Pedro Escribano Romero Página 73 74 Metas significativas a alcanzar. Identificación de paquetes de trabajo pertenecientes a dicha tarea. PROCESO TIEMPO DE DESARROLLO ROLES Para adquirir el conocimiento necesario para desarrollar el producto software: 2 horas. Para crear el Patrón de Producto: 1 día. Para aplicar el Patrón de Producto: 2 horas. Jefe del proyecto. VIDEO EXPLICACIÓN Este Patrón de Producto no tiene relacionado ningún video. Pedro Escribano Romero Página 7475 LECCIONES APRENDIDAS NIVEL DE MADURÉZ Ninguna. Este Patrón de Producto no se relaciona con ningún nivel de madurez(n/a). CONOCIMIENTOS BÁSICOS Conocimientos: Definición de requisitos software. Conocimientos previos sobre Ingeniería del Software I o Lógica de la Programación. Habituarse a utilizar un paradigma concreto. Habilidades: Capacidad de análisis. Capacidad de abstracción. CONTROLADORES DE CALIDAD PLANTILLAS Ninguno. Ninguna. EJEMPLOS Ejemplo WBS.pdf HERRAMIENTAS DE SOPORTE RECURSOS DE INFORMACIÓN Microsoft Word. OpenOffice Writer. Gonzalo, Agustín y de Amescua Antonio. Gestión del proceso software. Ed. Centro de Estudios Ramón Areces DeMarco, Tom. Controlling software projects. Ed Yourdon Press Sommerville, Ian. Ingeniería del software. Ed. Addison-Wesley Dolado, J.L. y Fernández, L. Medición para la gestión en la ingeniería del software. Ed. RAMA McConell, Steve. Desarrollo y gestión de proyectos informáticos. Ed. Mc Graw Hill Pressman, R. Ingeniería del Software, Un enfoque práctico, 6ª edición. Ed. Mc Graw Hill López-Cortijo y Amescua. Ingeniería del Software: Aspectos de Gestión. Ed. Instituto Pedro Escribano Romero Página 7576 Ibérico de la Industria del Software Garmus, David y Herron, David. Measuring the software process: a practical guide to functional measurements. Ed. Yourdon Press computing series Patrón de Producto: RBS SECCIÓN NOMBRE DEL PATRÓN RBS DESCRIPCIÓN PATRONES RELACIONADOS CONTEXTO INICIAL Ninguno. Este producto puede utilizarse en cualquier tipo de proyecto y se utilizará como herramienta de organización, seguimiento y estimación. Es un paso previo a la planificación del mismo proyecto, en la cual partiendo de la definición de los objetivos del proyecto, se quiere tener una representación de los recursos humanos y materiales. CONTEXTO RESULTANTE El jefe de proyectos obtendrá una representación jerárquica donde tendrá representado los recursos humanos, materiales, responsabilidades del proyecto. PROBLEMA El jefe de proyectos será capaz de mostrar gráficamente la organización humana del proyecto, maximizar el uso de los conocimientos y experiencia del personal disponible y reflejar la estructura de recursos materiales necesarios para la realización del proyecto, así como sus costes asociados. RESTRICCIONES (FORCES) Características de las organizaciones: Este patrón puede utilizarse en los proyectos existentes en cualquier tipo de compañía. Tipo de sistema a desarrollar: Este producto puede utilizarse en proyectos en los que los requerimientos de usuario sean cambiantes. Pedro Escribano Romero Página 76 77 Tipo de cliente: Debe existir, o debe conseguirse, que el área de negocio destinataria del desarrollo se implique en la consecución del mismo. Heurísticas de uso: Si se necesita disponer urgentemente del aplicativo o de algunas de sus funcionalidades. ENTRADAS Recursos humanos disponibles. Recursos materiales disponibles. Sistemas y segmentos del proyecto. SALIDAS Asociación de recursos humanos a determinados sistemas. Recursos materiales disponibles del proyecto PROCESO Pedro Escribano Romero Página 7778 TIEMPO DE DESARROLLO ROLES VIDEO EXPLICACIÓN LECCIONES APRENDIDAS NIVEL DE MADURÉZ Para adquirir el conocimiento necesario para desarrollar el producto software: 2 horas. Para crear el Patrón de Producto: 1 días. Para aplicar el Patrón de Producto: 2 horas. Jefe del proyecto. Este Patrón de Producto no tiene relacionado ningún video. Ninguno. Este Patrón de Producto no se relaciona con ningún nivel de madurez(n/a). CONOCIMIENTOS BÁSICOS CONTROLADORES DE CALIDAD PLANTILLAS EJEMPLOS HERRAMIENTAS DE SOPORTE Conocimientos: Conocimientos previos sobre Ingeniería del Software I o Lógica de la Programación. Habituarse a utilizar un paradigma concreto. Habilidades: Capacidad de análisis. Capacidad de abstracción. Ninguno. Ninguno. Ejemplo RBS.pdf Microsoft Word. OpenOffice Writer. RECURSOS DE INFORMACIÓN Gonzalo, Agustín y de Amescua Antonio. Gestión del proceso software. Ed. Centro de Estudios Ramón Areces DeMarco, Tom. Controlling software projects. Ed Yourdon Press Sommerville, Ian. Ingeniería del software. Ed. Addison-Wesley Pedro Escribano Romero Página 7879 Dolado, J.L. y Fernández, L. Medición para la gestión en la ingeniería del software. Ed. RAMA McConell, Steve. Desarrollo y gestión de proyectos informáticos. Ed. Mc Graw Hill Pressman, R. Ingeniería del Software, Un enfoque práctico, 6ª edición. Ed. Mc Graw Hill López-Cortijo y Amescua. Ingeniería del Software: Aspectos de Gestión. Ed. Instituto Ibérico de la Industria del Software Garmus, David y Herron, David. Measuring the software process: a practical guide to functional measurements. Ed. Yourdon Press computing series Patrón de Producto: PBS SECCIÓN NOMBRE DEL PATRÓN PBS DESCRIPCIÓN PATRONES RELACIONADOS WBS CONTEXTO INICIAL Este producto puede utilizarse en cualquier tipo de proyecto y se utilizará como herramienta de organización, seguimiento y estimación. Es un paso previo a la planificación del mismo proyecto, en la cual partiendo de la definición de los objetivos del proyecto, se llega a la estructuración de las diferentes actividades y productos que se obtienen. CONTEXTO RESULTANTE El jefe de proyectos tendrá inicialmente una representación gráfica de las diferentes actividades que se han de llevar a cabo para la realización de un proyecto, donde dichas actividades estarán agrupadas por paquetes de trabajo, y cada tarea tendrá asociada los productos que se obtienen. Pedro Escribano Romero Página 79 80 PROBLEMA RESTRICCIONES (FORCES) El jefe de proyectos será capaz de saber que productos se obtendrán en cada tarea. Características de las organizaciones: Este patrón puede utilizarse en los proyectos existentes en cualquier tipo de compañía. Tipo de sistema a desarrollar: Este producto puede utilizarse en proyectos en los que los requerimientos de usuario sean cambiantes. Tipo de cliente: Debe existir, o debe conseguirse, que el área de negocio destinataria del desarrollo se implique en la consecución del mismo. Heurísticas de uso: Si se necesita disponer urgentemente del aplicativo o de algunas de sus funcionalidades. ENTRADAS Diagrama WBS. SALIDAS Productos a obtener en cada tarea. Representación gráfica de las distintas tareas ordenadas. Metas significativas a alcanzar. Identificación de paquetes de trabajo pertenecientes a dicha tarea. PROCESO Pedro Escribano Romero Página 80 Mostrar más
GESTIÓN DE PROYECTOS Índice DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDADES DE INICIO DEL PROYECTO...2 ACTIVIDAD GPI 1: ESTIMACIÓN DE ESFUERZO...2 Tarea GPI 1.1: Identificación de Elementos a Desarrollar...3 Tarea Más detalles Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software
UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA P1 Elaboración de un plan de proyecto utilizando MS Project G3 José Luís Espinosa Aranda Noelia Vállez Enano Manuel Ramón Guerrero Álvarez Más detalles Ingeniería de Software I
Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00 Más detalles Tema 2. Ingeniería del Software I feliu.trias@urjc.es
Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición Más detalles CICLO DE VIDA DEL SOFTWARE
Tema 2: Ciclo de vida del Software Marcos López Sanz Índice Qué es el ciclo de vida del Software? La norma 12207-2008 Modelos de desarrollo Qué es el Ciclo de Vida del SW? Es una sucesión de etapas por Más detalles GESTIÓN DE PROYECTOS DE SOFTWARE
GESTIÓN DE PROYECTOS DE SOFTWARE LA PLANIFICACIÓN de proyectos se define como la predicción de la duración de las actividades y tareas a escala individual. LA ESTIMACIÓN se define como la predicción de Más detalles DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA
DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA Resumen AUTORIA CARLOS CABALLERO GONZÁLEZ TEMATICA INFORMÁTICA ETAPA ESO-BACHILLERATO-CFGM(ESI,ASI,DSI) Se describe la revolución que supuso la incursión Más detalles Cristian Blanco www.cristianblanco.es
3.1.- INTRODUCCIÓN Para realizar el desarrollo de cualquier proyecto de software es necesario llevar una sistemática de trabajo, que nos asegure el éxito del mismo. Lo que tenemos que evitar, en el desarrollo Más detalles cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.
cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema Más detalles I Edición Curso de Dirección y Gestión de Proyectos en Ingeniería en Informática
I Edición Curso de Dirección y Gestión de Proyectos en Ingeniería en Informática Modalidad presencial y online Junio de 2012 C/ Mayor, 4 6ª planta 28013 Madrid Teléfono: 91.523.86.20 Fax: 91.521.48.25 Más detalles IT Project Management Desarrollo de Software
IT Project Management Desarrollo de Software Es posible una mezcla de Waterfall y Agile? Cómo se acerca el PMBOK a Agile? Autor: Norberto Figuerola Resulta muy frecuente que se suela confundir una aproximación Más detalles Administración del Tiempo en el Desarrollo de un Sistema de Información
Administración del Tiempo en el Desarrollo de un Sistema de Información José Jimmy Camacho Martínez (1) Ramón David Chávez Cevallos (2) Ing. Lennin Freire (3) Facultad de Ingeniería en Electricidad y Computación Más detalles GUÍA DOCENTE. Curso 2014-2015. Ingeniería Informática en Sistemas de Información Doble Grado: M6: Tecnología Específica de Sistemas de Información
1. DESCRIPCIÓN DE LA ASIGNATURA Grado: Ingeniería Informática en Sistemas de Información Doble Grado: Asignatura: Ingeniería de Proyectos Módulo: M6: Tecnología Específica de Sistemas de Información Departamento: Más detalles ANEXO 4 - REQUERIMIENTOS DE GESTIÓN DE PROYECTOS PMO DE INFORMATICA
ANEXO 4 - REQUERIMIENTOS DE GESTIÓN DE PROYECTOS PMO DE INFORMATICA ETB requiere que el CONTRATISTA cumpla los lineamientos para la Dirección y Gestión de proyectos, éstos últimos definidos a nivel corporativo Más detalles I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L
I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L REFERE CIA AL SISTEMA EDUCATIVO ACTUAL. Los contenidos de este tema, están enfocados a introducir al alumno en el concepto de Ingeniería del Más detalles CURSO INTENSIVO DE INTRODUCCÓN A LA DIRECCIÓN / GESTIÓN DE PROYECTOS y CURSO DE PREPARACION INTENSIVA EXAMEN PMP / CAPM (52 HORAS) PARTE 1
CURSO INTENSIVO DE INTRODUCCÓN A LA DIRECCIÓN / GESTIÓN DE PROYECTOS y CURSO DE PREPARACION INTENSIVA EXAMEN PMP / CAPM (52 HORAS) PARTE 1 CURSO INTENSIVO DE INTRODUCCÓN A LA DIRECCIÓN / GESTIÓN DE PROYECTOS Más detalles PLANIFICACIÓN Y PROGRAMACIÓN DE PROYECTOS METODOS PERT Y GANTT
PLANIFICACIÓN Y PROGRAMACIÓN DE PROYECTOS METODOS PERT Y GANTT [Escriba aquí una descripción breve del documento. Normalmente, una descripción breve es un resumen corto del contenido del documento. Escriba Más detalles Modelos de desarrollo de software. septiembre de 2007 1
Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville, Más detalles Escuela Técnica Superior de. Informática. Máster en Ingeniería Informática. aplicada a la Industria, la Ingeniería del. Software y a los Sistemas y
Escuela Técnica Superior de Informática Máster en Ingeniería Informática aplicada a la Industria, la Ingeniería del Software y a los Sistemas y Tecnologías de la Información GUÍA DOCENTE DE LA ASIGNATURA: Más detalles ESTRUCTURA DE DESGLOSE DEL TRABAJO EDT
ESTRUCTURA DE DESGLOSE DEL TRABAJO EDT Una de las primeras tareas en el proceso de creación de un proyecto es la definición de su alcance, delimitando los trabajos a realizar para lograr cumplir los objetivos Más detalles Análisis del Sistema de Información
Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación Más detalles LOS INDICADORES DE GESTIÓN
LOS INDICADORES DE GESTIÓN Autor: Carlos Mario Pérez Jaramillo Todas las actividades pueden medirse con parámetros que enfocados a la toma de decisiones son señales para monitorear la gestión, así se asegura Más detalles Análisis de la gestión de configuración de software aplicada al modelo de espiral
Análisis de la gestión de configuración de software aplicada al modelo de espiral Abstract No hay nada permanente, excepto el cambio Heráclito (540 475 A.C.)- Grecia Fernandez, Sebastian Osso, Mariano Más detalles CICLO DE VIDA DEL SOFTWARE. Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software
3.010 CONCEPTO DE CICLO DE VIDA Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software IEEE 1074 Un marco de referencia que contiene los Más detalles SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE
Recibido: 23 de febrero de 2011 Aceptado: 29 de marzo de 2011 SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE MSc. Ailin Orjuela, MSc. Luis Alberto Esteban, MSc. Más detalles CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE
CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE INTRODUCCIÓN El avance informático actual es muy alto comparado con lo se tenía en los años 90, al hablar de desarrollo de software se hace más notable, en el Más detalles Preparación al Examen PMP - Introducción al PMBOK
La Guía del PMBOK ó Guía de los Fundamentos de la Dirección de Proyectos constituye un compendio de conocimientos de la profesión de dirección de proyectos. Al igual que en otras profesiones, como la abogacía, Más detalles Ingeniería de Software
Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6 Más detalles TESTS EXAMEN ISG ACTUALIZADO SEP 2008 TEMA 3 GESTIÓN DE PROYECTOS SOFTWARE
1. INTRODUCCIÓN TEMA 3 GESTIÓN DE PROYECTOS SOFTWARE 01 [Jun. 2005] [Jun. 2007] [Sep. 2007] Según Cori, el ciclo de gestión de proyectos software tiene como áreas: a) Planificación, toma de decisión, organización Más detalles Ges3ón de Proyectos So9ware
Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI Más detalles Planificación y Control de Proyectos de Software mediante MS Project
Práctica 2 Planificación y Control de Proyectos de Software mediante MS Project E n esta práctica vamos a introducirnos en la Planificación y Control de Proyectos de Software mediante herramientas informáticas Más detalles Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura
Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta Más detalles CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización
Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia Más detalles COMBINACION DE ALTERNATIVAS PARA LA ESTIMACION DE PROYECTOS SOFTWARE
COMBINACION DE ALTERNATIVAS PARA LA ESTIMACION DE PROYECTOS SOFTWARE Gramajo, E., García-Martínez, R., Rossi, B., Claverie, E. y Britos, P. CAPIS - CENTRO DE ACTUALIZACION PERMANENTE EN INGENIERIA DE SOFTWARE Más detalles PRACTICA 1 Elaboración de un plan de proyecto utilizando Microsoft Project
UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA PRACTICA 1 Elaboración de un plan de proyecto utilizando Microsoft Project AUTORES: Alfonso Franco Garcia Alicia Martín-Benito Escalona Más detalles TEST (0 30 puntos por pregunta correcta, -0 075 puntos por error) [Marcar sólo una opción]
EXAMEN PARCIAL 1 TEST (0 30 puntos por pregunta correcta, -0 075 puntos por error) [Marcar sólo una opción] Indicar la opción errónea. Los proyectos se diferencian de los trabajos en que: a) Tienen un Más detalles Diseño del Sistema de Información
Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2: Más detalles CIF 9159 Taller Integrado. Sección 4. Planificación. Prof. José Miguel Rubio L. jose.rubio.l@ucv.cl jrubio.leon@gmail.com
CIF 9159 Taller Integrado Sección 4 Planificación Prof. José Miguel Rubio L. jose.rubio.l@ucv.cl jrubio.leon@gmail.com Temas a Tratar Planificar Definiciones Proceso / Herramientas Estructura de Desglose Más detalles Planificación de Sistemas de Información
Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación Más detalles Rational Unified Process (RUP)
Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP Más detalles Planificación de Sistemas de Información
Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación Más detalles METODOLOGÍA DE GESTION DE PROYECTOS
METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE Más detalles CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA
CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15 Más detalles CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización
Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización Más detalles Desarrollo de proyectos
Desarrollo de proyectos DESARROLLO DE PROYECTOS 1 Sesión No. 1 Nombre: Gestión de proyectos Objetivo: Durante la sesión el participante identificará las principales características de la definición y dirección Más detalles GUÍA DOCENTE. Curso 2014-2015. Ingeniería Informática en Sistemas de Información. Planificación de Proyectos M5: Proyecto Informático
1. DESCRIPCIÓN DE LA ASIGNATURA Grado: Doble Grado: Asignatura: Módulo: Ingeniería Informática en Sistemas de Información Planificación de Proyectos M5: Proyecto Informático Departamento: Deporte e Informática Más detalles Mantenimiento del Software
Mantenimiento del Software S4 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad Más detalles Denominación de la materia. N créditos ECTS = 36 carácter = OBLIGATORIO SISTEMAS DE SOFTWARE. Ubicación dentro del plan de estudios y duración
Denominación de la materia SISTEMAS DE SOFTWARE N créditos ECTS = 36 carácter = OBLIGATORIO Ubicación dentro del plan de estudios y duración La materia Sistemas de Software está formada por 6 asignaturas Más detalles El Proceso Unificado
El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias Más detalles Etapa de Implementación de la Ejecución del Plan
MINISTERIO DE OBRAS PÚBLICAS Gestión y Monitoreo de Planes de Obras Públicas Etapa de Implementación de la Ejecución del Plan Dirección de Planeamiento SUBDIRECCION DE PLANIFICACION ESTRATEGICA Noviembre Más detalles 5 La Gerencia de Proyectos
5 La Gerencia de Proyectos La gran mayoría de las civilizaciones han tenido como factor común la ejecución de grandes hazañas dignas de recordarse, que han quedado plasmadas en los libros de historia y Más detalles CURSO DE PREPARACION INTENSIVA EXAMEN PMP - CAPM (40 HORAS)
CURSO DE PREPARACION INTENSIVA EXAMEN PMP - CAPM (40 HORAS) Focalizado en la nueva versión del PMBOK Introducción Este curso ha sido diseñado para cualquier profesional que piense en rendir el examen PMP Más detalles Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software
Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Introducción Este documento recopila las preguntas, opiniones y respuestas que se produjeron en un pequeño curso sobre las Más detalles Impala Risk. Simulación de Riesgo en Proyectos. Servicios. Capacitación. www.impalarisk.com
Simulación de Riesgo en Proyectos Servicios Capacitación www.impalarisk.com Software Simulador de Riesgo en Proyectos El peor riesgo es desconocer el riesgo Los actuales Gerentes de Proyectos se enfrentan Más detalles M t é rica c s a s de d l e Pr P oc o e c s e o s o de d Ing n e g n e i n er e ía a de d e So S f o twa w r a e e y y de d P od o u d c u t c o
Proceso de Ingeniería de Software Métricas del Proceso de Ingeniería de Software y de Producto 4. Métricas del proceso y el producto 4.1. Métricas del proceso 4.2. Métricas del producto 4.3. Calidad y Más detalles Tema I: Gestión de Proyectos Software: Planificación
Tema I: Gestión de Proyectos Software: Planificación Bibliografía Calvo-Manzano, J.A., Cervera, J., Fernández, L., Piattini, M. Aplicaciones Informáticas de Gestión. Una perspectiva de Ingeniería del Software. Más detalles DESARROLLO DEL CURSO DE EVALUADORES DE EMPRESAS DE SFA Guía docente módulo 2 El modelo de mejora de procesos de Cenatic
DESARROLLO DEL CURSO DE EVALUADORES DE EMPRESAS DE SFA Guía docente módulo 2 El modelo de mejora de procesos de Cenatic Fecha:14/10/2010 HOJA DE CONTROL Título Desarrollo del curso de evaluadores Más detalles Ciclo de formación en Dirección y Gestión. de Proyectos en Informática. 2015 Edición
Ciclo de formación en Dirección y Gestión de Proyectos en Informática 2015 Edición Ciclo de formación en Dirección y Gestión de Proyectos en Informática 1. Presentación del ciclo de formación Tras la encuesta Más detalles PFC- Aplicaciones Web para trabajo colaborativo:
PFC- Aplicaciones Web para trabajo colaborativo: Aplicación para Control de una Integración de S.I. 2º Ciclo Ingeniería Informática Curso 2011-2012 Consultor : Fatos Xhafa Autor : Miguel Angel Pineda Cruz Más detalles Proyecto de Desarrollo de una Base de Datos para un concesionario
Proyecto de Desarrollo de una Base de Datos para un concesionario Etienne Boshoff de Jong Enginyeria en Informàtica Juan Martinez Bolaños 14 enero 2013 Proyecto Final de Carrera: Base de Datos Page 1 1. Más detalles Postgrado en Gestión de Proyectos con Microsoft Project 2016 (Doble Titulación + 35 Créditos PDUs) (Certificación PMP - PMI)
Postgrado en Gestión de Proyectos con Microsoft Project 2016 (Doble Titulación + 35 Créditos Titulación certificada por EUROINNOVA BUSINESS SCHOOL Postgrado en Gestión de Proyectos con Microsoft Project Más detalles 3 3 X (1) Observaciones: (2) Observaciones: Docente/s. Espacios Curriculares Correlativos Precedentes Aprobada/s Cod. Asig. Cursada/s Cod. Asig.
Ciclo Académico: 2009 Año de la Carrera: Horas de Clases Semanales Régimen de Cursado 1 Teoría Práctica Otros (1) Anual 1er.Cuatr. 2do.Cuatr. Otros (2) 3 3 X (1) Observaciones: (2) Observaciones: Docente/s Más detalles Mantenimiento del Software
Mantenimiento del Software S3 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad Más detalles DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL
Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización Más detalles Tema 2. El Ciclo de Vida del Software (ISG1-ITIG)
Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Grupo de Ingeniería del Software Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual - 3.0 - España 1 Objetivos del Tema Qué Más detalles Estimación de costos y esfuerzos. Calidad en el Desarrollo de Software. Estimación de costos para el software. Planificación de proyectos
Estimación de costos y esfuerzos Métricas de procesos de software Depto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur COCOMO otros Segundo Cuatrimestre 2007 de proyectos Estimación Más detalles CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización
Página 1 de 18 CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC297_2 Versión 5 Situación RD 1201/2007 Actualización Más detalles CURSO DE DIRECCIÓN Y GESTIÓN DE PROYECTOS - PMP
CURSO DE DIRECCIÓN Y GESTIÓN DE PROYECTOS - PMP Objetivos Generales: Adquirir los conceptos y las estrategias y practicar los procedimientos y técnicas necesarios para el desempeño de las funciones asociadas Más detalles SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI. MSc. Mauricio Rojas Contreras
Recibido: 06 de agosto de 2009 Aceptado: 21 de octubre de 2009 SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI MSc. Mauricio Rojas Contreras Más detalles Ingeniería del So8ware II
Ingeniería del So8ware II Tema 04 (2). Alcance de Proyectos So8ware Carlos Blanco Bueno DPTO. DE MATEMÁTICAS, ESTADÍSTICA Y COMPUTACIÓN carlos.blanco@unican.es Este tema se publica bajo Licencia: CreaQve Más detalles Gerenciamiento de Proyectos. Estándar PMI. Cambio Organizacional UDELAR
Gerenciamiento de Proyectos Estándar PMI Cambio Organizacional UDELAR Agenda Concepto de Proyecto Qué es la dirección de proyectos? PMI y Guía del PMBOK Dirección de Proyectos Áreas de Conocimiento 2 Definición Más detalles Guía Docente 2015-16
Guía Docente 2015-16 GESTIÓN DE PROYECTOS INFORMÁTICOS Information Technology Project Management Grado en Ingeniería Informática Presencial Índice Gestión de Proyectos Informáticos... 3 Breve descripción Más detalles GESTIÓN DE TIC. Desarrollar tus competencias y habilidades en Gestión de Proyectos bajo los estándares del PMBOK 5ta.
Las Tecnologías de la Información y Comunicaciones (TIC) son actualmente un factor clave en las organizaciones que les permite mantener su competitividad en un mundo cada vez mas globalizado. En la actualidad Más detalles Laboratorio de Software de Comunicaciones
Universidad Carlos III de Madrid Laboratorio de Software de Comunicaciones Trabajo de Tecnología Educativa: Diseño de un curso Web de programación en Java Titulación: Ingeniería de Telecomunicación, Curso Más detalles 2 EL DOCUMENTO DE ESPECIFICACIONES
Ingeniería Informática Tecnología de la Programación TEMA 1 Documentación de programas. 1 LA DOCUMENTACIÓN DE PROGRAMAS En la ejecución de un proyecto informático o un programa software se deben de seguir Más detalles TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES
Programa de Certificación Internacional en Dirección y Gestión de Proyectos TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Programa de Certificación Más detalles Ingeniería de Software II
Ingeniería de Software II Primer Cuatrimestre de 2008 Clase 2: Planificación de Proyectos de Software Buenos Aires, 27 de Marzo de 2008 Temas para hoy Repaso de la clase anterior: modelos de ciclo de vida Más detalles Programa Internacional en Administración de Proyectos: Preparación para el examen de Certificación PMI
Programa Internacional en Administración de Proyectos: Preparación para el examen de Certificación PMI Organizar y llevar a cabo con éxito un proyecto no solo depende de conocimientos técnicos. También Más detalles MÉTODOS DE ESTIMACIÓN
MÉTODOS DE ESTIMACIÓN 1 MÉTODOS DE ESTIMACIÓN 1. Introducción 2. Precisión y exactitud de las estimaciones 3. Estimación de costes 4. Técnica Delphi 5. Técnicas de descomposición 6. Modelos de coste y Más detalles Gestión de Proyectos
Gestión de Proyectos Agenda: Gestión de Proyectos Técnicas y Herramientas de Planificación Estimaciones de Tamaño, Esfuerzo, Costo y Duración Métricas de Tamaño Recursos Humanos y Organización Evaluación Más detalles En verde están algunas propuestas que entendemos que faltan y que ayudarían a mejorar las fichas sustancialmente.
NOTAS ACLARATORIAS: Esta ficha de grado es la resultante de las dos reuniones celebradas (9 enero 2009 y 23 de febrero de 2009) por la subcomisión creada desde el MICIIN para debatir las fichas de Grado Más detalles El desarrollo del software.
El desarrollo del software 1 El desarrollo del software. Introducción. El ciclo de vida. El modelo de desarrollo en cascada. Definición. Diseño. Codificación. Integración. Prueba. Documentación. Los "productos Más detalles Monografía. Adecuación gráfica a nivel de íconos de un sitio web
Monografía Adecuación gráfica a nivel de íconos de un sitio web Curso: Estrategia de Evaluación para Comprender y Mejorar la Calidad en Uso de Aplicaciones Web Doctorado en Ciencias Informáticas Facultad Más detalles Construcción de sistemas de soporte a la toma de decisiones
INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE CÓMPUTO Construcción de sistemas de soporte a la toma de decisiones M. En C. Eduardo Bustos Farías 1 Desarrolla en Sistemas de Apoyo de Decisión Como Más detalles DISEÑO DE UN SISTEMA INFORMÁTICO PARA LA
DISEÑO DE UN SISTEMA INFORMÁTICO PARA LA ADMINISTRACIÓN DE COMPRAS DE ALMACÉN INITE, S.C. no es responsable del contenido, de la veracidad de los datos, opiniones y acontecimientos vertidos en el presente Más detalles TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE. Dr. José Ignacio Peláez Sánchez E.T.S.I. Informática de Sistemas. 3 er Curso.
TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE Dr. E.T.S.I. Informática de Sistemas. 3 er Curso. Año 2004/2005 Visión General Importancia de la Ingeniería del Software. Retraso en la llegada de la Ingeniería Más detalles Calidad de Software - CMM
Calidad de Software - CMM Herramientas y Procesos de Software Facultad de Informática, Ciencias de la Comunicación y Técnicas Especiales Lic. Cecilia Palazzolo Año 2008 1 Qué es un modelo de procesos? Más detalles Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 2: EL CICLO DE VIDA DEL SOFTWARE
Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 2: EL CICLO DE VIDA DEL SOFTWARE 1 DEFINICIÓN DE CICLO DE VIDA DEL SOFTWARE ISO/IEC 12207-1 Marco de referencia que contiene Más detalles Postgrado en Gestión de Proyectos con Microsoft Project 2013 (Doble Titulación + 35 Créditos PDUs)
Postgrado en Gestión de Proyectos con Microsoft Project 2013 (Doble Titulación + 35 Créditos Postgrado en Gestión de Proyectos con Microsoft Project 2013 (Doble Titulación + 35 Créditos Duración: 460 horas Más detalles INGENIERÍA INDUSTRIAL
PROGRAMA DE ASIGNATURA ACTIVIDAD CURRICULAR: GESTIÓN DE PROYECTOS Código: 952573 Área: Industrial Bloque: Tecnologías Aplicadas Nivel: 5º Tipo: Electiva Modalidad: Cuatrimestral Carga Horaria Total: 60 Más detalles ESTUDIO DE CASO PROCESO DE MEDICIÓN EN PROYECTOS DE TI
UNIVERSIDAD DON BOSCO FACULTAD DE INGENIERIA ESCUELA DE COMPUTACION INGENIERIA DE SOFTWARE CICLO II/2008 ESTUDIO DE CASO PROCESO DE MEDICIÓN EN PROYECTOS DE TI DOCENTE: ING. MILTON NARVÁEZ. PRESENTADO Más detalles Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1
Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir Más detalles ÁREA DE CALIDAD Página 1 de 28 MODELOS DE GESTIÓN DE SISTEMAS DE CALIDAD: ISO 9001:2008
Página 1 de 28 4.1 Conocimiento de la organización y de su contexto La organización debe determinar las cuestiones externas e internas que son pertinentes para su propósito y que afectan a su capacidad Más detalles Fase de Planeación. Unidad
Fase de Planeación. Unidad 2 Una etapa primordial en la gestión de un proyecto es la Planeación. Durante ésta se realizan actividades para estimar costos y recursos asegurando que el proyecto satisfaga Más detalles Taller de Secretos para Dominar la Gestión de Riesgos en Proyectos
Taller de Secretos para Dominar la Gestión de Riesgos en Proyectos Desarrollado por la reconocida autora Lic. Liliana Buchtik, PMP, PMI-RMP autora del libro Secretos para Dominar la Gestión de Riesgos Más detalles CAPÍTULO 4 NORMA IEEE 1058.1 PARA LA PLANIFICACIÓN DE PROYECTOS SOFTWARE ESTE DOCUMENTO ES PARTE DEL SIGUIENTE TRABAJO:
ESTE DOCUMENTO ES PARTE DEL SIGUIENTE TRABAJO: La norma IEEE 1058.1: Plan para la Gestión de Proyectos Software realizado por el alumno Ismael Caballero Muñoz-Reja para la asignatura Planificación y Gestión Más detalles 2017 © DocPlayer.es Política de privacidad | Condiciones del servicio | Feedback

References: resolución 
 resolución 
in fine
 resolución 
 resolución 
 resolución