1 / 51

Doris Correa - Ximena Romano Jorge Triñanes

Doris Correa - Ximena Romano Jorge Triñanes. Ingeniería de Software InCo - Facultad de Ingeniería - UdelaR. Agenda. Introducción Proyecto MoDSGX Evaluación y trabajo futuro. Introducción. Marco del proyecto Antecedentes Modelo de Proceso - ¿para qué? Objetivos del proyecto

damia
Download Presentation

Doris Correa - Ximena Romano Jorge Triñanes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Doris Correa - Ximena Romano Jorge Triñanes Ingeniería de Software InCo - Facultad de Ingeniería - UdelaR

  2. Agenda • Introducción • Proyecto MoDSGX • Evaluación y trabajo futuro

  3. Introducción • Marco del proyecto • Antecedentes • Modelo de Proceso - ¿para qué? • Objetivos del proyecto • Referencias propuestas

  4. Marco del Proyecto • Carrera Ingeniería en Computación Año Semestre 1 Semestre 2 Proyecto de Grado 5º Modelo de Proceso Retroalimentación 4º Intr. Ing. SW Proy. Ing. SW GX GX GX

  5. Introd. a la Ing. de SW • Principales Temas: • Procesos de SW • Métricas de tamaño y estimación • Gestión de Proyectos de SW • Requerimientos (Casos de Uso) • Diseño (Diagramas UML) • Verificación • Calidad y Gestión de la Configuración

  6. Proy. de Ing. de SW • Objetivos: • contrastar teoría en proyecto sometido a restricciones análogas a las de la industria • reflexionar sobre la forma en que construimos software • Ejemplos de restricciones: • proyecto con duración fija (14 semanas) • dedicación prevista de cada estudiante de 15 horas semanales

  7. Proy. de Ing. de SW (2) • Funcionamiento de grupos de proyectos • El grupo trabaja con autonomía pero • muy pautado: • proceso definido • entregas semanales Interacción semanal con algunos roles Director (docente) Cliente Grupo sin jerarquías, con roles diferenciados Grupo (8 a 15 integrantes)

  8. Antecedentes Año Cambios Estructura actual de cursos (Ing.SW) ... Proceso incremental e iterativo Modelo de Proceso para Java Cliente ajeno al curso Fase de Transición 1997 1998 1999 2000 2001 2002

  9. Modelo de Proceso - ¿para qué? • Base para la mejora del proceso • Facilita incorporar nuevo personal de forma productiva • En el curso todos los años el “personal” es nuevo • Oportunidad para ensayar diversos procesos...

  10. Objetivos del proyecto MoDSGX • Definir un Modelo de Proceso para desarrollo con GeneXus • Poner a prueba el Modelo • Ajustarlo a partir de la experiencia de su utilización

  11. Referencias propuestas • Mejores prácticas en algunas organizaciones que utilizan GeneXus • ISO/IEC TR 15504 • Modelo de Proceso Java Ver. 2001 • XP (eXtreme Programming) • RUP (Rational Unified Process) • MSF (Microsoft Solutions Framework) • Métrica Ver. 3

  12. Proyecto MoDSGX • Introducción • Modelo de proceso propuesto • Trabajando con MoDSGX

  13. Actividades Sistema de software Introducción Modelo de proceso Requerimientos del Usuario Este modelo: Iterativo e incremental Desarrollo con Genexus

  14. Modelo de proceso propuesto • Dimensiones del Modelo de Proceso • Tiempo • Aspecto dinámico • Fases, Iteraciones e Hitos • Líneas de Trabajo • Aspecto estático • Roles, Actividades y Entregables

  15. Tiempo Fase I Inicial Fase II Elaboración Fase III Construcción Fase IV Transición Iter. I Iter. II Iter. I Iter. I Iter. I Iter. II Iter. II Iter. II Hitos

  16. Fase I - Inicial • Objetivo • Identificar requerimientos. • Identificar riesgos. • Estimar los recursos necesarios. • Evaluar la capacidad de hacer el proyecto. • Iteraciones • Iteración I – 3 semanas

  17. Fase II - Elaboración • Objetivo • Dominio del problema. • Fundamento de la arquitectura. • Plan del proyecto. • Eliminar elementos de riesgo. • Prototipo de la arquitectura. • Iteraciones • Iteración I – 2 semanas • Iteración II – 2 semanas

  18. Fase III - Construcción • Objetivo • Construcción completa del software. • Material necesario. • Iteraciones • Iteración I – 2 semanas • Iteración II – 2 semanas

  19. Fase IV - Transición • Objetivo • Usuario apto para operar el sistema. • Sistema al entorno del usuario. • Verificación de la versión “beta”. • Versión “final” del sistema. • Satisfacción del cliente. • Iteraciones • Iteración I – 1 Semana

  20. Entregables Entregables Líneas de Trabajo Rol Actividad

  21. Líneas de trabajo y tiempo

  22. Líneas a destacar • Requerimientos y Análisis • Casos de Uso • Diseño • Diagramas UML • de paquetes • de secuencia o interacción • Modelo de Datos

  23. Caso de uso – Inscripción a curso • 1. Actores • 1.1. Funcionario • Son los posibles usuarios funcionarios de la Institución: Administrador, Bedel, Diseñador, Asistente. • … • 2. Casos de Uso • 2.2 Inscripción a curso • Descripción • Este caso de uso puede ser iniciado de tres formas: • Por un alumno de la institución, cuando tiene la intención… • Por un Funcionario de la Institución, si tiene permisos para… • Pre-condiciones • Debe estar autenticado en el sistema un usuario con permisos …

  24. Funcionario Inscripción a curso 1. Este caso de uso comienza cuando un Funcionario tiene la intención de realizar la inscripción de un alumno a un curso. 2. Le solicita al Funcionario, el identificador del Alumno al cual se le desea hacer la inscripción. 3. Ingresa el identificador del Alumno. 4. Valida el identificador del Alumno y le muestra los principales datos personales del mismo (nombre, apellido, etc.). Caso de uso – Inscripción a curso Flujo de eventos principal

  25. Diseño – Inscripción a curso • Diseño de Casos de Uso • 1.2. Diseño del Caso de Uso Inscripción a curso • 1.2.1. Diagrama de paquetes

  26. Diseño – Inscripción a curso 1.2.2. Diagrama de Interacción

  27. Diseño – Inscripción a curso 5. Diseño de Datos

  28. Líneas a destacar • Gestión de Configuración y Control de Cambios • Control de versiones • Línea base • Metodología de control de cambios • Gestión de Calidad • Planificación • Revisiones de calidad y Técnicas Formales

  29. Líneas a destacar • Comunicación • Establecer métodos de comunicación • Mantener informados a todos los involucrados en el proyecto (equipo de trabajo, cliente, usuario, etc) • Seguimiento de satisfacción del cliente

  30. Trabajando con MoDSGX • Roles • Experiencia • Ajustando el modelo...

  31. Roles - definición • Analista Analiza el sistema, conduce y coordina el relevamiento de requerimeintos ... • Perfil para el rol • Una persona que actúa en éste rol debe tener buenas habilidades de comunicación, interpersonal y en forma escrita... • Actividades que son responsabilidad del rol • Relevamiento de requerimientos ... • Entregables que son responsabilidad del rol • Glosario ... • Actividades en las que está involucrado el rol • Diseño del Sistema ...

  32. Roles

  33. Roles

  34. Roles a destacar • Especialista Técnico • Es responsable de seleccionar, adquirir y configurar las herramientas que sean necesarias, así como investigar tecnologías que se quieran utilizar. • Se definen los siguientes: • Especialista Técnico • Especialista Técnico Java y Configuración • Especialista Técnico Genexus y Base de datos

  35. Roles a destacar • Responsable de SCM • Proporciona la infraestructura y entorno para la Gestión de Configuración. Este entorno debe facilitar la revisión de productos, el rastreo de defectos y controlar las versiones y los cambios. • Es responsable de la creación y seguimiento de la Línea Base del proyecto. • Es responsable del cumplimiento del proceso de gestión de cambios.

  36. Roles a destacar • Responsable del Consolidado • Es responsable de planificar la integración de sistema y llevarla a cabo. • Responsable del Núcleo • Implementa y mantiene la Base de conocimiento Núcleo. • Todos los cambios a esta Base son su responsabilidad. • Debe distribuir la Base de conocimiento Núcleo a las demás Bases de conocimiento del proyecto.

  37. Combinación de Roles • Características del proyecto: • Grupo de 9 personas • 17 roles en el modelo • Compatibilidad de roles • Esfuerzo equilibrado durante el proyecto

  38. Especialista técnico Genexus y Base de datos – Responsable del Núcleo – Implementador Analista - Responsable Consolidado - Implementador Especialista técnico – Implementador Especialista técnico Java y configuración – Implementador Combinación de Roles – 9 personas Analista (Responsable de análisis) - Documentador de usuario - Instructor - Asistente verificación

  39. Responsable de verificación – Analista Responsable de SQA – Responsable de SCM Administrador – Responsable de Comunicación – Asistente verificación Arquitecto – Coordinador de desarrollo – Asistente verificación Combinación de Roles – 9 personas

  40. Experiencia • Producto: • Portal Web para manejo de educación a distancia • Características técnicas: • Genexus 7.5 • Generador Java • DB2 UDB versión 7.1 • Reuso de business objects (chat y foro)

  41. Experiencia - algunos datos

  42. Experiencia – esfuerzo por línea de trabajo

  43. Satisfacción

  44. MoDSGX 2002 MoDSGX 2003 Ajustando el Modelo ... Ajustes Al Modelo Experiencia

  45. Evaluación y trabajo futuro - Plan • Puntos fuertes • Aspectos a mejorar • MoDSGX ¿puede servir fuera de Facultad? • Líneas de trabajo • Planes para el 2003

  46. Evaluación • Puntos fuertes • Se generaron productos razonables a pesar de: • falta de experiencia previa en GeneXus • baja supervisión • grupos con numerosos integrantes • Definición y división de roles con carga equilibrada • Utilización de Casos de Uso muy natural y adecuada para trabajo con GeneXus

  47. Aspectos a mejorar • Interacción con Cliente/Usuario • los grupos tardaron demasiado en mostrar productos andando • en parte debido a dificultades en preparar ambiente • Medir el tamaño de los productos • Automatizar pruebas • Gestión de la configuración • “Agilizar” el proceso

  48. MoDSGX ¿puede servir fuera de Facultad? • Tal cual, seguramente NO • Para equipos numerosos puede ser un punto de partida o referencia interesante

  49. Líneas de trabajo del área IS • Tres líneas relacionadas • Procesos y métricas de software • Verificación • Desarrollo con GeneXus en equipos numerosos

  50. Planes para el 2003 • Utilizar nuevamente MoDSGX, ajustando su formulación y su utilización, con un equipo más numeroso (13) • Desarrollar y probar un nuevo modelo de proceso para desarrollo con GeneXus con eXtreme Programming • Procurar la automatización de las pruebas

More Related