Doris Correa - Ximena Romano InCo - Facultad de Ingeniería - UdelaR

Presentación del tema: "Doris Correa - Ximena Romano InCo - Facultad de Ingeniería - UdelaR"— Transcripción de la presentación:

1 Doris Correa - Ximena Romano InCo - Facultad de Ingeniería - UdelaR
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
5º Proyecto de Grado 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 Estructura actual de cursos (Ing.SW) 1997 ... 1998
Año Cambios 1997 1998 1999 2000 2001 2002 Estructura actual de cursos (Ing.SW) ... Proceso incremental e iterativo Modelo de Proceso para Java Cliente ajeno al curso Fase de Transición

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 A continuación mostraremos una introducción al modelo, describiendo las características principales del modelo de proceso y destacando aquellas que generalmente son menos contempladas en un proceso de desarrollo. Y contaremos sobre la experiencia de prueba del modelo de proceso en un proyecto de Ingeniería de software.

13 Requerimientos del Usuario
Introducción Modelo de proceso Requerimientos del Usuario Sistema de software Actividades Un modelo de proceso es el conjunto de actividades necesarias para transformar los requerimientos del usuario en un sistema de software. Las características principales de este modelo es que es iterativo e incremental y enfocado al desarrollo con Genexus. 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 El modelo de proceso se define utilizando dos dimensiones: Una es el tiempo que describe el aspecto dinámico del proceso y se define en base a fases, iteraciones e hitos. Otra son las Líneas de trabajo que describen el aspecto estático del proceso y se definen en base a actividades, roles 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. II Iter. I Iter. II Iter. I Iter. II Un ciclo de desarrollo está dividido en cuatro fases secuenciales, cada una concluida por un hito. Las fases son: Fase I – Inicial Fase II – Elaboración Fase III – Construcción Fase IV – Transición El Hito es el momento en el tiempo en el que se evalúa el cumplimiento de los objetivos de la fase y se decide si pasar a la fase siguiente o no. (Si no se cumple se pueden manejar las variables para pasar de todas formas a la siguiente fase. Las variables son: cantidad de recursos, tiempo (alargar la fase), aumentar la dedicación horaria.) Todas las fases no son idénticas en términos de cronogramas y esfuerzo. En cada fase se itera para lograr el objetivo, por lo que la fase puede dividirse en iteraciones. En una iteración se realizan actividades en todas las líneas de trabajo del proyecto, resultando en una liberación (interna o externa) de un producto, (el cual es un subconjunto del sistema final que crece incrementalmente de iteración en iteración hasta llegar al sistema final). Una consecuencia de la aplicación de este modelo es que mediante el enfoque iterativo los productos de cada línea de trabajo crecen y maduran a medida que el tiempo transcurre, y a través del enfoque incremental de desarrollo, se van aumentando las capacidades del software a medida que se avanza hacia los objetivos definidos para cada fase en el proceso de software. Hitos

16 Fase I - Inicial Objetivo Iteraciones Identificar requerimientos.
Identificar riesgos. Estimar los recursos necesarios. Evaluar la capacidad de hacer el proyecto. Iteraciones Iteración I – 3 semanas Los objetivos de esta fase son: Identificar requerimientos y especificar detalladamente los más significativos. Identificar riesgos y planificar su mitigación y contingencia. Resolver los riesgos técnicos identificados. Estimar los recursos necesarios. Evaluar la capacidad de hacer el proyecto. Los requerimientos más significativos son los más importantes para el cliente o los que presentan riesgos técnicos.

17 Fase II - Elaboración Objetivo Iteraciones 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 En esta fase se estabilizan los requerimientos, determinando el dominio del problema. Se completa el diseño y se estabiliza la arquitectura. Se desarrolla el plan del proyecto, y se mitigan los riesgos más altos del proyecto. Se construye un prototipo ejecutable de la arquitectura, que contiene los casos de uso críticos identificados en la fase inicial (que generalmente expone los mayores riesgos técnicos del proyecto). Dependiendo del proyecto se puede construir también un prototipo evolutivo de un componente, para estudiar la viabilidad de un componente o para demostraciones a clientes y usuarios finales. Se construye la Base de Conocimiento Núcleo del sistema y un prototipo ejecutable de la misma. Se puede determinar el costo para la realización del desarrollo.

18 Fase III - Construcción
Objetivo Construcción completa del software. Material necesario. Iteraciones Iteración I – 2 semanas Iteración II – 2 semanas Se desarrolla completamente el software y los documentos necesarios que componen el sistema. El resultado de esta fase es un producto listo para que los usuarios lo puedan operar y consiste del software integrado en las plataformas adecuadas, los materiales para soporte del usuario y una descripción de la versión actual (esta versión del sistema es la versión “beta”).

19 Fase IV - Transición Objetivo Iteraciones
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 Se capacita al usuario en el uso del sistema. Se traslada el sistema a la comunidad del usuario. Cuando el sistema ha sido instalado en el entorno del usuario se realiza la verificación de la versión “beta” del sistema y se realizan las correcciones necesarias, generando la versión “final” del sistema. El sistema debe estar completo, en un nivel aceptable de calidad y debe estar disponible la documentación necesaria para que al ser llevado al entorno del usuario produzca resultados positivos para el usuario y para el equipo de trabajo del proyecto, logrando la satisfacción del cliente

20 Líneas de Trabajo Rol Entregables Entregables Actividad
Las líneas de trabajo definen las actividades que se deben realizar para producir un juego particular de productos (entregables). Esta definición se hace en base a la descripción de la actividad y los roles y entregables involucrados. Un rol define el comportamiento y responsabilidades de un individuo, o un conjunto de individuos que trabajan juntos como un equipo, dentro del contexto de una organización de ingeniería de software (Ejemplo: Analista, Implementador). Un miembro del equipo del proyecto puede cumplir varios roles. Una actividad es algo que un rol hace y eso proporciona un resultado significativo en el contexto del proyecto. Un entregable es todo tipo de información creada, producida, cambiada o usada por los miembros del equipo de trabajo. La definición de una actividad se hace en base a las entradas necesarias para poder realizarla (entregables), cual es el rol responsable de realizarla, que debe hacer dicho rol y cual es el resultado de dicha actividad (entregables). **** Rol ingeniería de software. (Los roles tienen un conjunto de actividades cohesivas que realizan. Estas actividades están estrechamente relacionadas y funcionalmente acopladas, y se realizan mejor por el mismo individuo. ) Actividad Las actividades están estrechamente relacionadas a los entregables. Los entregables son la entrada y salida de las actividades, y el mecanismo por que se comunica la información entre las actividades. Entregable Un entregable es un producto del proceso: las personas de los distintos roles usan entregables para realizar actividades, y producen entregables en la realización de las actividades. Los entregables son responsabilidad de un solo rol y promueven la idea de que cada pedazo de información en el proceso debe ser responsabilidad de una persona específica. Aunque una persona puede ser la dueña o responsable del entregable, otras personas pueden usar el entregable, incluso actualizarlo si se les da el permiso de hacerlo. Desarrolladores e involucrados Llamaremos desarrollador (podría también llamarse trabajador pero usamos desarrollador para referirnos al trabajador del equipo de desarrollo de un sistema de software) a la persona que realiza una tarea en el proyecto para obtener un resultado, están incluidos los directores, gerentes, arquitectos, implementadores, verificadores, analistas, especialistas técnicos, administradores y otros. Denominaremos involucrados a los usuarios, vendedores, clientes, agencias reguladoras, y otros. Actividad

21 Líneas de trabajo y tiempo
Requerimientos y Análisis: Definir los requerimientos y el alcance del sistema. Actividades principales: Relevar, especificar, analizar y priorizar requerimientos y definir el alcance del sistema. Diseño: Realizar el diseño y definir la arquitectura del sistema. Actividades principales: Diseñar y describir la arquitectura del sistema. Verificación: Verificar que el sistema cumpla todos los requerimientos definidos en el alcance del sistema. Actividades principales: Verificar los componentes del software, la integración, el software integrado, el sistema y los documentos que componen el sistema. Transición al entorno del usuario: Lograr que el usuario esté apto para operar el sistema y llevar el sistema al entorno del usuario. Actividades principales: Capacitar al usuario, llevar el sistema al entorno del usuario, realizar la prueba de aceptación por parte del usuario y preparar la versión “final” del sistema. Gestión de Configuración y Control de Cambios: Lograr que el proyecto se desarrolle bajo un ambiente controlado y realizar el control y seguimiento de los cambios. Actividades principales: Planificación de la Configuración, definición de la Línea Base, generación del ambiente controlado y control de cambios. Gestión de Calidad: Lograr que el sistema desarrollado cumpla con las propiedades de calidad establecidas. Actividades principales: Planificación de calidad, revisiones técnicas formales y de ajuste al proceso, revisión de las entregas. Gestión de Proyecto: Lograr que el proyecto se desarrolle de manera planificada y controlada. Actividades principales: Planificación de proyecto, seguimiento de proyecto, realizar estimaciones y mediciones, gestión de riesgos, convocar y moderar las reuniones de equipo. Comunicación: Mantener la comunicación dentro del proyecto y del equipo de proyecto con las organizaciones externas a él, y lograr la satisfacción del Cliente. Actividades principales: Definir los métodos de comunicación, mantener informados a todos los involucrados en el proyecto en sus áreas de interés y realizar el seguimiento de la satisfacción del Cliente.

22 Líneas a destacar Requerimientos y Análisis Diseño Casos de Uso
Diagramas UML de paquetes de secuencia o interacción Modelo de Datos Requerimientos y análisis: se hace la descripción detallada de los requerimientos mediante Casos de Uso Diseño: se diseñan los casos de uso mediante diagramas de paquetes y de secuencia o interacción (llegando a nivel de objetos en algunos casos) Se realiza un modelo de datos de las estructuras más relevantes para la arquitectura y/o para el núcleo del sistema. ******** Requerimientos y Análisis Especificar formalmente todos los requerimientos relevados (funcionales y suplementarios) Enumerar los requerimientos candidatos que se relevaron, indicando su estado, prioridad, esfuerzo necesario, riesgo y a quien fue asignado. Especificar detalladamente los requerimientos del sistema mediante Casos de Uso. Definir las abreviaturas, siglas y términos usados en el proyecto (documentos y software) Define el Alcance del Sistema, esto es, de todos los requerimientos especificados cuáles se implementarán y en que momento. Rol responsable  Analista Diseño Especificar formalmente el diseño del sistema, esto incluye su descomposición en subsistema o módulos, la interacción entre las partes, y los datos que maneja el sistema. Rol responsable  Arquitecto Describir la Arquitectura del Sistema desde el punto de vista de Modelo de Casos de Uso, Modelo de Diseño, Modelo de Implementación, Modelo de Distribución y las trazas entre ellos.

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 … En el modelo de casos de uso hay dos secciones: Una Donde se especifican los actores del sistema Otra donde se especifican los Casos de uso Para cada caso de uso se realiza: Descripción del mismo Las pre-condiciones que indican el estado en que debe estar el sistema para la realización del caso de uso(condiciones que se deben dar para realizar el caso de uso) El flujo de eventos principal, mediante diagramas de casos de uso o secuencia de realización

24 Caso de uso – Inscripción a curso
Flujo de eventos principal 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.).

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 Diagrama de paquetes Para el diseño del sistema se elabora un documento llamado Modelo de Diseño Del cual veremos dos secciones que son: Diseño de Casos de Uso, Diseño de Datos El Diseño de casos de uso se realiza en base a: Diagramas de paquetes (indicando los objetos de diseño intervienen en el caso de uso)

26 Diseño – Inscripción a curso
Diagrama de Interacción Diagrama de interacción: indicando la realización del caso de uso Que se puede complementar con una descripción escrita en términos de objetos de diseño.

27 Diseño – Inscripción a curso
5. Diseño de Datos En esta sección se define la estructura de datos que utilizará el sistema, a partir de los requisitos funcionales y no funcionales establecidos para el sistema y las particularidades del entorno tecnológico, que consiga una mayor eficiencia en el tratamiento de los datos. Se realiza el diseño de datos importantes del Núcleo y de datos que son relevantes para la arquitectura del sistema. Se identifican las principales entidades de datos y los datos por los que están compuestas a partir de la especificación de requerimientos. Además se describen las dependencias entre dichas entidades mediante diagramas de Bachman. Subsección - Especificación de la Distribución de Datos Se especifica el modelo de distribución de datos indicando la ubicación de los manejadores de bases de datos o sistemas de archivos, así como los distintos elementos de la estructura física de datos (base de datos, tablas, índices), en los nodos correspondientes. Para elaborar esta sección el Arquitecto trabajará en conjunto con el Especialista Técnico Genexus y Base 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 Gestión de Configuración y Control de Cambios, incluye: Planificar la configuración: Realizar la planificación de las actividades que se realizarán para trabajar en un ambiente controlado durante el desarrollo del sistema. Definir un mecanismo de control de versiones y control de cambios (ciclo de vida de un cambio). Definir la línea base del proyecto: Identificar los elementos de configuración, que son los entregables más relevantes del proyecto y que juntos constituyen el sistema y son los que forman la línea base del proyecto. Definir y generar el ambiente controlado: Se realiza la definición y construcción del ambiente controlado donde se almacenarán, modificarán y consultarán los elementos de la línea base. Se especificará al equipo de proyecto como se debe utilizar este ambiente controlado. Hacer el seguimiento de la línea base del proyecto: Comprende recibir, registrar y mantener todos los productos recibidos a través de todas sus versiones. Realizar la verificación sobre los elementos de configuración que componen la versión actual para asegurar que se encuentran en estado consistente en la Línea Base del Proyecto. Control de cambios: El objetivo es realizar el seguimiento del ciclo de vida de un cambio, que comprende: la solicitud del cambio, la evaluación, la aprobación y la implementación o el rechazo del mismo. En la planificación de la configuración se define el ciclo de vida del cambio. Gestión de Calidad Planificar la calidad: Planificación de las actividades que se realizarán para asegurar un nivel determinado de calidad del producto a ser desarrollado. Revisiones de calidad: En cada revisión de calidad se plantean los aspectos del Producto que serán revisados, que propiedades de la calidad se buscará que cumpla y en que grado, que principios y estándares de calidad aplican al Producto, si ya hubo revisión de otra versión del producto que correcciones quedaron pendientes de realizar. Realizar revisiones técnicas formales (RTF): Es un proceso de revisión riguroso de determinados productos, con el objetivo es llegar a detectar lo antes posible, los posibles defectos o desviaciones en los productos que se van generando a lo largo del desarrollo. Esta característica fuerza a que se adopte esta práctica únicamente para productos que son de especial importancia, porque de otro modo podría frenar la marcha del proyecto. Comentarios sobre revisiones de calidad Se pretende asegurar que la entrega de productos al cliente cumple con los requerimientos mínimos de calidad. ·         Se revisa que existan todos los entregables necesarios. ·         En caso de no contar con un entregable, se debe registrar que no se va a entregar, y dar una fecha tentativa de se entrega. ·         Se verifica que los documentos entregados cumplan con los requerimientos mínimos de calidad. Mecanismo de la RTF El RESPONSABLE DE SQA una vez que conoce los productos que se van a revisar formalmente, establece los grupos que van a llevar a cabo las revisiones, convocando a los participantes por adelantado, e informando del objetivo de la revisión, la agenda y las responsabilidades que tendrán asignadas en la revisión. La revisión se centra en una parte específica (y pequeña) del software total. Antes de la revisión el RESPONSABLE DE SQA debe: ·         Convocar a la reunión a los involucrados. ·         Informar en la convocatoria el material que ellos deben preparar por adelantado. ·         La reunión de revisión no puede ser mayor a 2 horas. ·         Estudiar el producto a ser revisado, anotando las preguntas y dudas que le surgen para hacer en la reunión. Durante la reunión: ·         Se comienza con la explicación de la/s personas que hicieron el producto, explicando como se llegó a ese producto. ·         Se concluye determinando las áreas de problema y elaborando un informe de revisión formal que incluye las acciones correctivas. ·         En la reunión se deben seguir las siguientes directrices: ·         Revisar el producto, no al productor. ·         Fijar una agenda y mantenerla. ·         Limitar el debate y las impugnaciones. ·         Enunciar áreas de problema, pero no intentar resolver los problemas. Esto debe ser hecho por el que hizo el producto. ·         Limitar el número de participantes de 3 a 5. ·         Usar checklist para el producto a revisar. ·         Deben estar agendadas en el cronograma de proyecto y en el Plan de Calidad. Revisar las revisiones anteriores, incluso para encontrar errores en el propio proceso de revisión. RTF Apuntan a revisar los productos para ver si se construyeron cumpliendo con lo establecido en el modelo de proceso (usando la plantilla adecuada, utilizando datos de entrada requeridos, manteniendo trazabilidad con productos relacionados) Revisiones de calidad Revisar los productos para ver si cumplen con los requerimientos de calidad establecidos para cada producto.

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 Se evalúan los métodos posibles de comunicación y las posibilidades de los integrantes del grupo de acceder a éstos, para definir cual será el más adecuado para el grupo en este proyecto. Se preparan las reuniones (orden del día, horario, lugar, materiales), se sita a los involucrados y lleva a cabo la reunión donde se informará sobre algún tema de interés de los involucrados. Algunos temas pueden ser: ·         Avance del proyecto involucrando a cliente ·         Avance del proyecto involucrando al equipo de desarrollo ·         Presentación de un Subsistema (desarrollado por una parte del equipo de desarrollo) al resto del equipo de desarrollo, etc. Esta actividad no se contempla en la agenda de actividades de las iteraciones, se realizará cuando el Responsable de la Comunicación estime conveniente. Se elaboran documentos que contengan información sobre algún tema de interés para clientes, usuarios, equipo de desarrollo y lo envía a los involucrados. Preparar esta información puede implicar que el Responsable de la Comunicación deba reunirse con algún otro integrante de equipo de desarrollo o participar de reuniones o actividades para obtener la información.

30 Trabajando con MoDSGX Roles Experiencia Ajustando el modelo...
Para organizar el trabajo se definieron roles dentro del equipo de proyecto que son los que ejecutan las actividades y generan los entrgables. Proyecto de Ingeniería de Software de Facultad de Ingeniería trabajando con MoDsGX. Dada la experiencia de trabajo que ajustes se planean para 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 Dadas las líneas de trabajo, cada una está compuesta o integrada por roles que se desempeñan en ella. Administrador – Responsable de la gestión de proyecto, planifica, estima, evalua riesgos, registra y realiza el seguimiento del esfuerzo incurrido por el equipo y el avance del proyecto, lidera las reuniones de equipo, mantiene enfocado al equipo en la meta correcta. Coordinador de desarrollo – dentro del área de gestión realiza la planificación y seguimiento de las actividades del equipo de desarrollo. Responsable de verificación – Planifica las actividades de verificación que se realizarán a lo largo del proyecto, diseña los casos de prueba, evalúa las verificaciones generando un informe de evaluación. Asistente de verificación – fundamentalmente ejecuta las pruebas de verificación que tiene asignadas generando un informe para el Responsable de verificación. Responsable de SCM – Genera el ambiente controlado y línea base del proyecto, Planifica el trabajo del equipo bajo un ambiente controlado, control de versiones, control de cambios. Especialista Técnico Java y Configuración – Asiste al SCM en las tareas ténicas de configuración del ambiente controlado. Responsable de SQA – Planifica las tareas de control de calidad a realizarse durante el proyecto, revisiones de calidad durante el proyecto, RTF , Revisiones de apego al proceso Responsable de la comunicación – Definición de métodos de comunicación, generación de documentos de interés para el equipo, reuniones

33 Roles Analista (Responsable de Análisis) – Centraliza las actividades de Requerimientos y Análisis, conduce y coordina el relevamiento de requerimientos y modelado de casos de uso, define y negocia el alcance del sistema Analista – Releva requerimientos, especifica casos de uso Documentador de usuario – Genera los materiales de soporte para el usuario, y materiales de capacitación Arquitecto – Define la arquitectura y realiza el diseño de sistema definiendo responsabilidades, funciones, atributos y relaciones de uno o varios subsistemas y Bases de conocimiento. Coordinador de desarrollo – Dentro del área de implementación planificación de desarrollo para cumplir con el Plan de proyecto y con los objetivos de cada fase. Implementador – Implementa y verifica los componenetes que le fueron asignados, colabora con el responsable de Consolidado en la integración y realiza documentación técnica. Responsable del consolidado – Es responsable de planificar y llevar a cabo la consolidación o integración del sistema, combinando los componentes individuales de cada implementador y formando un subsistema. Responsable del núcleo – Es responsable de implementar la base de conocimiento núcleo y de mantenerla. Especialista técnico – Soporte técnico, selecciona y adquiere herramientas, prepara el ambiente de desarrollo por lo que debe tener conocimiento de las herramientas de programación y debe estudiar e investigar las tecnologías que el proyecto requiera. Especialista técnico Genexus y Base de datos – Es un especialista técnico especializado en la configuración del ambiente Genexus de desarrollo y la configuración del manejador de base de datos para este ambiente. Especialista técnico Java y Configuración – Es responsable de estudiar y realizar la configuración del ambiente Java de acuerdo a lo necesario para el proyecto. Coordinador de desarrollo – Dentro del área de Transición al entorno del usuario describe la versión del producto y las notas de la versión a liberar. Administrador – Dentro del área de Transición al entorno del usuario planifica la liberación del producto de software al ambiente del usuario. Responsable de SCM – Dentro del área Transición al entorno del usuario colabora con la liberación de la versión del sistema. Especilaista técnico Java y Configuración – Preparar el entorno de capacitación. Documentador de usuario – Crea materiales para capacitación, tutoriales, ejemplos, presentaciones y todos los que considere convenientes para facilitar al usuario el entendimiento de uso del sistema. Instructor – realiza la capacitación al usuario final en forma de curso o taller.

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 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 Responsable del Núcleo
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 Se realizó una distribución de roles de forma tal que los roles combinados fueran compatibles entre sí y el esfuerzo se balanceara a lo largo del proyecto.

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

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

40 Experiencia Producto: Características técnicas:
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) Se construyó un portal Web para institutos de educación, que contara con foros de discusión, chats, bedelía, enseñanaza a distancia Reuso de business objects: se usó el chat y el foro con modificaciones para adaptarlo a la estructura de usuarios que tenían definida en el sistema.

41 Experiencia - algunos datos

42 Experiencia – esfuerzo por línea de trabajo

43 Satisfacción

44 Ajustando el Modelo ... MoDSGX 2003 Ajustes Al Modelo Experiencia
2002 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

51 Preguntas? Página Web Direcciones de correo
Direcciones de correo Doris Correa Ximena Romano Jorge Triñanes