InfoMedia Planificación. Resumen de tareas ● PLANIFICACIÓN: – Documentación: Asignación de tareas, recursos y fechas. – Revisión: Verificación de los.

Slides:



Advertisements
Presentaciones similares
InfoMedia Exposicion de practicas de Ingenieria del software3.
Advertisements

SYSMOTORFLOW PRESENTACIÓN DEL PROCESO Proyecto de Ingeniería de Software 2010.
Fase Elaboración Conclusiones Grupo 6 – PIS
INSTITUTO TECNOLÓGICO SUPERIO DE LIBRES
PROCESO DE DESARROLLO. Introducción Mediante esta presentación se pretende describir el proceso de desarrollo del TALLER I.
 Tema del proyecto  Integrantes y roles del equipo  Objetivos del proyecto  Alcance.
Contexto Proyecto consolidado dentro de la línea de investigación de Sistemas de Información en el Dpto. de Ingeniería en Sistemas de Información de la.
Planificación, Reingeniería y Plan de Proyecto
Planificación Temporal y Seguimiento del Proyecto
Plan de Sistemas de Información (PSI)
Grupo 51 Evaluación de Fase Inicial Proyecto Ingeniería de Software 2005 Grupo 5.
VISIÓN GENERAL DE LA IS Con independencia del modelo de proceso hay tres fases genéricas: Fase de definición Fase de desarrollo Fase de mantenimiento Cada.
Gestión de los Costos del Proyecto
Implementando PSP / TSP
Ciclo de Vida del Software
Proyecto de Ingeniería de Software 2008 Proyecto TITA Soft. Grupo 02.
Modelo de procesos de software
VERIFICACIÓN Y VALIDACIÓN DE SISTEMAS 3.10 Fase de manejo de requerimientos 4.1 Modelado de pruebas en UML Ponente: ing. Alejandro tapia vazquez.
Ingeniería del Software 2013/2014.  Integrantes del proyecto  Ámbito del proyecto  Arquitectura adoptada  Principal trabajo realizado en el proyecto.
Presentación Proyecto IS3 Grupo InfoMedia: David Pozo Navarro Miguel Ferrando Navalón Pablo Guardiola Sánchez José Antonio Benítez Yáñez Francisco Javier.
Ingeniería del Software 2013/2014.  Integrantes del proyecto  Ámbito del proyecto  Arquitectura adoptada  Principal trabajo realizado en el proyecto.
InfoMedia Planificación. Resumen de tareas ● PLANIFICACIÓN: – Definición del formato de los documentos. – Documentación: Asignación de tareas, recursos.
FACULTAD DE INGENIERÍA CIVIL Y MECÀNICA CARRERA DE INGENIERÍA MÈCANICA EMPLEO DE NUEVAS TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIÓN (NTIC´s II) TEMA: PASOS.
INGENIERÍA DE SOFTWARE RODRÍGUEZ CADENA CYNTHIA VIRIDIANA GRANADOS HERNÁNDEZ ERICK METODOLOGÍA OMT.
Análisis de Proyecto de Software.
Proceso de Implantación y Aceptación del Sistema de Información (IAS)
Gestión de Proyectos.
Gestión de Software Conferencia # 2 Niveles de PSP: PSP0.1.
Grado en Ingeniería Mecánica
CARRERA DE INGENIERÍA EN SISTEMAS E INFORMÁTICA
Especificación de Requisitos
Presenta: TSU. Yuridia Luna Marcos Asesora de tesis:
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno. INTRODUCCIÓN A UML  QUE ES UML?  PARA QUE SE UTILIZA  COMPONENTES  DIAGRAMAS.
Tema 3. Lenguaje unificado de modelado UML
UNIVERSIDAD NACIONAL DE LOJA Área de la Educación, el Arte y la Comunicación Informática Educativa IV INGENIERIA DE SOFTWARE Taller de Análisis y Diseño.
NIA 310 NIA 315 NIA 320 NIA 400.
CICLO DE VIDA DE UN SOFTWARE
CICLO DE VIDA DE UN SOFTWARE
Metodología Merise Universidad Nororiental Privada
Índice temático 2.1 Análisis de problemas. 2.2 Representación de algoritmos: gráfica y pseudocódigo. 2.3 Diseño de algoritmos aplicados a problemas 2.4.
Resumen: Análisis de requerimientos
Verificación y Validación de Software
Verificación y Validación de Software
Taller Organización de Procedimientos Administrativos.
Ciclo de Vida del Software
Ciclo de vida del Software
Metodologías de Desarrollo de Software RUP – Proceso Racional Unificado Gilber BASILIO ROBLES I.E.S.T.P. “DANIEL ALCIDES CARRIÓN” Taller de Modelamiento.
En este periodo el analista se esfuerza por comprender la información que necesitan los usuarios para realizar su trabajo de la manera correcta.
INTRODUCCIÓN A UML Y AL ADOO 1 Diagramas en UML ◦Diagramas de casos de uso ◦Diagramas de clases y objetos ◦Diagramas de secuencia ◦Diagramas de colaboración.
METODOLOGIAS AGILES VS TRADICIONALES SCRUM - RUP FABIO ARNOBY BEJARANO Q. UNIREMINGTON BUGA (V) INGENIERIA DE SOFTWARE II SEPTIEMBRE 2018.
LAS ETAPAS DE LA SIMULACION NUMERICA
CICLO DE VIDA DE SOFTWARE
Curso: Gestión de Proyecto TI (Parte 2)
Aplicación de las TI al cuidado de las Enfermedades Crónicas
Planes del Proyecto.
INGENIERIA DE REQUISITOS
Metodología de Desarrollo de Sistemas II Ingeniería de Software  DEFINICIÓN La ingeniería del software es el establecimiento y uso de principios de.
PARÁMETROS PARA LA PRESENTACIÓN DE PROYECTOS EN LA ESCUELA DE TECNOLOGIAS E INNOVACION. ING. Hugo de Jesús Peláez Giraldo Líder Escuela de Tecnologías.
1 COSTESNOCALIDAD. 2 Todos los costes asociados con la actividad deben ser considerados como parte total de los costes de Calidad : -Trabajo directo:
1 Introducción al proceso unificado de desarrollo de software.
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno. INTRODUCCIÓN A UML  QUE ES UML?  PARA QUE SE UTILIZA  COMPONENTES  DIAGRAMAS.
INTEGRANTES u Álvarez Palomino David u Salazar Colonia Jesús Felipe u Velásquez Huapaya Ricardo.
Desarrollo de Sistemas de Información Contable - Sis USB 1 METODOLOGIAS DE DESARROLLO DE SOFTWARE.
GESTIÓN DE PROYECTOS La gestión de proyectos está conformada por todas aquellas acciones que debes realizar para cumplir con una objetivo definido dentro.
GC-F-004 V.01 CENTRO DE INDUSTRIA Y LA CONSTRUCCIÓN REGIONAL TOLIMA.
Desarrollo de Sistemas de Información Contable - Sis USB 1 METODOLOGIAS DE DESARROLLO DE SOFTWARE.
Plan de Sistemas de Información (PSI). Plan de Sistemas de Información (PSI) Descripción y Objetivos Tiene como objetivo la obtención de un marco de referencia.
ICI 502 Procesos de Software
Luis Fernando Muñoz Pantoja Ingeniero de Sistemas Copyright 2019 Luis Fernando Muñoz Pantoja Ingeniero de Sistemas Derechos reservados UML.
Transcripción de la presentación:

InfoMedia Planificación

Resumen de tareas ● PLANIFICACIÓN: – Documentación: Asignación de tareas, recursos y fechas. – Revisión: Verificación de los plazos de entrega.

Resumen de tareas ● MODELADO DE REQUISITOS: – Modelo funcional: Identificación de actores y casos de uso. – Subsistemas funcionales: Agrupar casos de uso. Diagramas de paquetes. – Requisitos no funcionales. – Operaciones del sistema. – Revisión: Comprobación del modelado con las peticiones del cliente.

Resumen de tareas ● ANÁLISIS: – Clases, atributos y relaciones. – Modelado estático: Determinación de las relaciones entre clases y restricciones. Diagrama de clases. – Modelado comportamiento externo. – Revisión: Comprobación modelo correcto, completo, consistente y realista.

Resumen de tareas ● DISEÑO: – Sistema: Establecimiento de la arquitectura software. – Objetos: Identificación de las nuevas clases para permitir la implementación. – Revisión: Comprobación especificación correcta, completa, completamente definida e implementable.

Resumen de tareas ● IMPLEMENTACIÓN: – Aprendizaje de lenguajes. – Optimización del diagrama de clases de diseño. – Implementación de las clases. – Implementación de las restricciones. – Revisión: Comprobación ejecución correcta de cada subsistema y que se corresponde con el lo especificado en el diseño.

Resumen de tareas ● PRUEBAS: – - Diseño de casos de pruebas de instalación, que cumplan los requisitos de los casos de uso y que detecten fallos en casos excepcionales. – - Ejecución de pruebas.

Análisis de la planificación iteración 1 ● Iteraciones parecidas. ● Reutilización de trabajo. ● Planificación temporal final como referencia. ● Principal defecto: planificación demasiado ajustada. – - Cualquier aplazamiento en una fase implica recorte de tiempo en las siguientes. – - Riesgo de no poder cumplir las fechas de entrga.

Análisis de la planificación iteración 1 ● Consecuencias – - Ultimas fases con tiempos muy reducidos – - Crecimiento abrupto del esfuerzo conforme se acerca la fecha de entrega de la iteración – - Fechas de implementación y pruebas no se pueden cumplir.

Análisis de la planificación iteración 1 ● Soluciones: – - Intentar incrementar el esfuerzo en las fases iniciales. – - Dado que presuponemos que se van a producir retrasos, dejar un margen considerable. – - Disminución del tiempo destinado a las fases iniciales.

Análisis de la planificación iteración 1

Evolución planificación temporal ● Planificación inicial – Entrega de la documentación ● Planificación: 31/03/09 ● Modelado requisitos: 09/04/09 ● Análisis: 12/04/09 ● Diseño: 15/04/09 ● Implementación: 23/04/09 ● Prueba: 24/04/09

Evolución planificación temporal ● Margen 6 dias de retraso. ● Problema: tiempo análisis insuficiente -> 1 dia ● Fases diseño, implementación retrasadas ● Fecha de entrega análisis aplazada al 13/04/2009.

Evolución planificación temporal ● Planificación temporal v02 – Entrega de la documentación ● Planificación: 31/03/09 ● Modelado requisitos: 09/04/09 ● Análisis: 13/04/09 ● Diseño: 16/04/09 ● Implementación: 25/04/09 ● Prueba: 25/04/09

Evolución planificación temporal ● Problema: tiempo diseño insuficiente -> 1 día ● Fase implementación retrasada. ● Fecha entrega diseño aplazada al 16/04/2009

Evolución de la planificación temporal ● Planificación temporal v03 ● Entrega de la documentación – Planificación: 31/03/09 – Modelado requisitos: 09/04/09 – Análisis: 13/04/09 – Diseño: 17/04/09 – Implementación: 25/04/09 – Prueba: 26/04/09

Evolución temporal de la planificación ● Problema: tiempo implementación insuficiente -> 3 días ● Fase pruebas retrasada. ● Fin pruebas en fecha limite. ● Tarea diseño plan de pruebas añadida en paralelo para el 28/04/09. ● Duración tarea ejecución pruebas incrementada (corregir errores detectados) ● Fecha entrega implementación aplazada al 28/04/2009

Evolución de la planificación temporal ● Planificación temporal v04 ● Entrega de la documentación – Planificación: 31/03/09 – Modelado requisitos: 09/04/09 – Análisis: 13/04/09 – Diseño: 17/04/09 – Implementación: 28/04/09 – Prueba: 30/04/09

Evolución temporal de la planificación ● Problema: tiempo implementación insuficiente -> 1 días ● Duración tarea ejecución pruebas reducida en un dia ● Fecha entrega implementación aplazada al 29/04/2009

Evolución de la planificación temporal ● Planificación temporal v05 ● Entrega de la documentación – Planificación: 31/03/09 – Modelado requisitos: 09/04/09 – Análisis: 13/04/09 – Diseño: 17/04/09 – Implementación: 29/04/09 – Prueba: 30/04/09

Evolución temporal de la planificación ● Se pudieron cumplir todas las fechas de entrega excepto la ejecución de las pruebas, aplazada para el dia de la defensa (06/04/2009).

Tiempos finales ● Planificación: – 1 día (dedicación exclusiva)

Tiempos finales ● Modelado Requisitos: 10 días – 4 días dedicación exclusiva – 1 días paralelo con análisis – 5 días paralelo con análisis y diseño

Tiempos finales ● Análisis: 10 días – 1 día paralelamente con modelado de requisitos – 5 días paralelamente con modelado de requisitos y diseño – 4 días paralelamente con diseño

Tiempos finales ● Diseño: 12 días – 4 días paralelamente con modelado de requisitos y análisis – 4 días paralelamente con análisis – 4 días dedicación exclusiva

Tiempos finales ● Implementación: 15 días – 3 días (aprendizaje del lenguaje) – 12 días dedicación exclusiva.

Tiempos individuales – David Pozo Navarro96 – Miguel Ferrando Navalón96 – Pablo Guardiola Sánchez96 – José Antonio Benítez Yáñez10 horas – José Ramón Cano Yribarren10 horas – David Ordóñez Torres10 horas – Javier Molina Reyes35 horas – José Luis López Pino35 horas – José Luis Garrido Rodríguez30 horas

Tiempos individuales

Dificultades encontradas ● El mayor problema ha sido el hecho de tener que terminar la fase de pruebas fuera de plazo debido al último aplazamiento de la entrega de implementación. ● Esto se podría haber evitado aumentando el paralelismo de las tareas iniciales de la implementación con alguna de las tareas finales del diseño aumentando así el tiempo dedicado a la implementación.

Dificultades encontradas ● A finales de la iteración nos dimos cuenta de que la fase de pruebas no se iba a poder llevar a cabo. ● Solución: se divide la fase de pruebas en: – - Confección del documento de plan de pruebas. – - Ejecución del plan de pruebas. ● De esta forma, al ser la primera subfase paralela con la implementación, se puede llevar a cabo antes de que finalice la implementación.

Dificultades encontradas ● A parte de esto, gracias al trabajo hecho en la iteración anterior por parte de la planificación y a que hemos aprendido de los errores cometidos en la misma, hemos podido gestionar la iteración sin grandes problemas.

Conclusión ● Para corregir los errores detectados en la primera iteración, con respecto a la planificación, inicialmente se dejó un gran margen (casi una semana). ● Fases notablemente más cortas.

Conclusión ● Pros: ● Entrega de documentos de desarrollo y análisis retrasados únicamente un día. ● Margen implementación de 4 días. ● Éxito parcial en plazo entrega final (ejecución pruebas). ● Esfuerzo no tan concentrado en la entrega final (td)

Conclusión ● Contras: ● Mayor esfuerzo en las primeras fases (modelado requisitos, análisis y diseño) para cumplir fechas ajustadas. ● Implementación alargada considerablemente. ● Fecha inicial entrega de iteración completamente irreal e inalcanzable. ● Numerosos cambios en la planificación.