Sistema de Administración de Macro Currículos (SAMA)

Slides:



Advertisements
Presentaciones similares
Ciclo de vida de desarrollo de software
Advertisements

ingeniería de software
Metodologías ágiles.
Postmortem Ciclo3 Proyecto de Notificación y Comunicación Electrónica de la Plataforma de Interoperabilidad Carlos Andrés Arango Jorge Eduardo Garzón Daniel.
Administración de Proyectos Instructor: Omar Alvarez Xochihua
Herramientas y metodologías de éxito para el manejo de proyectos TIC: Caso PYME CREATIVA Noviembre 2008.
Guía metodológica para la gestión de proyectos de software en PyMEs que no son fábricas de software por medio de Metodologías ágiles.
SYSMOTORFLOW PRESENTACIÓN DEL PROCESO Proyecto de Ingeniería de Software 2010.
2010 Presentación Final Proyecto Originación de Crédito
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
Metodologías de Desarrollo
Administración de Proyectos Instructor: Omar Alvarez Xochihua.
Fase Elaboración Conclusiones Grupo 6 – PIS
Musitec.
Postmortem Ciclo 1 Mejoramiento Proceso Originación de Crédito Banco de los Alpes 2010 Julián Morales Andrés González Carlos Criales.
Proceso de Originación de Crédito: Banco de los Alpes
Módulo Local. Logo: Correo Electrónico: Slogan: Producir Software de alto nivel Misión: Desarrollar software de calidad para la satisfacción.
Proyecto de Ingeniería de Software 2008
Proyecto: Lanzamiento
SISTEMA DE SEGUIMIENTO DE INDICADORES DE GESTIÓN
HERRAMIENTAS CASE.
Trabajo Práctico Taller de Desarrollo de Proyectos 2 Septiembre 2009.
ITERASOFT. OBJETIVOS DEL GRUPO Producir un sistema Manejador de Itinerarios de alta calidad y confiabilidad Realizar un proyecto bien administrado y productivo.
TEAM SOFTWARE PROCESS CICLO 2.  Producto  Reporte del ciclo  Plan  Inspección  Plan de calidad  Valor ganado  Objetivos  Proceso TSP  Equipo.
Luis Fernando Hevia Rodríguez
PROCESO DE DESARROLLO. Introducción Mediante esta presentación se pretende describir el proceso de desarrollo del TALLER I.
TEAM SOFTWARE PROCESS CICLO 3.  Análisis del Proyecto  Producto  Resultados por Rol  Resultado del Proceso.
 Tema del proyecto  Integrantes y roles del equipo  Objetivos del proyecto  Alcance.
Fase Inicial Grupo 6 – PIS – 2013.
Planeación con Planning Tool y DotProject Grupo de Construcción de Software Facultad de Ingeniería Universidad de los Andes Rubby Casallas, Andrés Yie.
METODOLOGÍA OMT Diseño de sistemas.
Carlos Mario Zapata J., PhD Oscar Ochoa, Ing. Crhistian Cardona, M.Sc.
Presentación Final Proyecto Originación de Crédito Especialización en construcción de software Universidad de los Andes Bogotá Julián Morales.
Presentación Final Proyecto Originación de Crédito Especialización en construcción de software Universidad de los Andes Bogotá Julián Morales.
Team Software Process IntroductionTSPiSM Watts Humphrey
TEMA: DESARROLLO DE UN SISTEMA INFORMÁTICO PARA EL CONTROL DE USO Y EL MANTENIMIENTO DE VEHÍCULOS DE UNA INSTITUCIÓN PÚBLICA AUTOR: EDISON GUAMAN   DIRECTOR:
Especialización en Desarrollo de Software
Proyecto de Ingeniería de Software Grupo Nº 9 - GXPost (Desarrollo con GeneXus 8.0) Evaluación de la Fase Construcción (Jueves 4 de Noviembre de.
El rol de SQA en PIS.
Sistema de Administración de Macro Currículos (SAMA) Líder: Carlos Andrés Muñoz Desarrollo: José Luis Gutiérrez Calidad y Proceso: Juan David Botero Soporte:
Grupo 10 – 2008 Proyecto de Ingeniería de Software
Guía metodológica para la gestión de proyectos de software en PyMEs que no son fábricas de software por medio de metodologías ágiles Tatiana Alejandra.
PROYECTO ECOS.  Producto desarrollado  Problemas encontrados  Riesgos materializados  PIP.
1 Motor de Generación de Formularios para Infocorp Presentación del Proceso.
 Logo:  Correo Electrónico:  Slogan: Producir Software de alto nivel  Misión: Desarrollar software de calidad para la satisfacción.
DISEÑO CURRICULAR Presentado por: Cesar Augusto Sáenz María Alejandra Hernández 1.contenidos curriculares de competencia.
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
Modelos y estándares de procesos TSP Ciclo 2 Credit score Grupo Quimera INTEGRANTES: Alexandra Marín – Líder de calidad Juan Carlos Lopera – Líder de planeación.
Introducción al proceso de verificación y validación.
PROCESOS DE DESARROLLO DE SOFTWARE
Actividades en el Proceso de desarrollo de Software
Ciclo 1 Neotect S.A..  Reporte de Producto Desarrollo y calidad  Reporte de Proceso Desempeño y disciplina del grupo  Autoevaluación del Grupo Por.
Proyecto: Lanzamiento QUICK ORDER. Objetivo General  Desarrollar el sistema de información de acuerdo a los requerimientos establecidos por el cliente,
Estructurar tus ideas para hacerlas realidad
Implementando PSP / TSP
Ciclo de Vida del Software
CICLO 1 BEATRIZ BARREIRO GÓMEZ HENRY SUÁREZ SÁNCHEZ
FACULTAD DE CIENCIAS COMPUTACIONALES Y TELECOMUNICACIONES ASIGNATURA:
Modelos y estándares de procesos TSP Ciclo 1 Credit score Grupo Quimera INTEGRANTES: Alexandra Marín Juan Carlos Lopera Camilo Forero Luis Carlos Ávila.
Proyecto BANALPES Mejoramiento del proceso de originación de crédito
Análisis y Balance del Proyecto Análisis Inicial Estimación Inicial Arquitectura de Datos Propuesta Tecnología Metodología aplicada Estimaciones elaboradas.
Modelos y estándares de procesos de desarrollo de software Universidad de los Andes ECOS – 2010 – Sección I.
Motor de generación de Formularios para Infocorp (MOGEFI) Evaluación del Proyecto.
Modelo de procesos de software
TEAM SOFTWARE PROCESS CICLO 1. El software propuesto por el equipo de Ingenium para cumplir con las necesidades planteadas, modela los un conjunto de.
Procesos de Planeación
Sistemas de calidad en el desarrollo de software.
Entregables del Proyecto
Junio, 2013.
Transcripción de la presentación:

Sistema de Administración de Macro Currículos (SAMA) Grupo: Grupo 1 Sistema de Administración de Macro Currículos (SAMA) Líder: Carlos Andrés Muñoz Desarrollo: José Luis Gutiérrez Calidad y Proceso: Juan David Botero Soporte: Carlos Hernán Brugnoni Planeación: Juan Fernando Domínguez Planeación: Juan Felipe Aranguren Checa

Descripción General

Requerimientos No. Descripción 1 Migrar la arquitectura original de SAMA a la arquitectura de referencia. 2 Migrar y completar la interfaz gráfica de usuario original a la utilizada en SAMI 3 Administrar las excepciones

Casos de Uso

Requerimientos Técnicos No. Nombre Descripción 1 Modificabilidad La aplicación debe construirse de tal forma que tenga bajo acoplamiento y alta cohesión para permitir cambios futuros. 2 Escalabilidad El sistema debe soportar un número creciente de usuarios sin afectar el rendimiento. 3 Usabilidad La aplicación debe permitir un aprendizaje rápido por parte de los usuarios

Requerimientos Técnicos No. Nombre Descripción 1 Plataforma JEE La aplicación será desarrollada utilizando componentes del framework Java Enterprise Edition. 2 Interfaz Web en GXT La interfaz gráfica debe ser desarrollada con las herramientas de GWT-EXT (GXT).

Diagramas Estáticos Diagrama de Conceptos

Diagramas Estáticos Diagrama de Componentes

Diagramas Dinámicos Diagrama de Secuencia

Diagramas Dinámicos Diagrama de Secuencia

Proceso de desarrollo

Análisis de Riesgos Falta de comprensión de la arquitectura requerida. Problemas de configuración del framework. Problemas de reutilización de la arquitectura base. Retraso de Desarrollo. Retraso de Despliegue. Trabajo Inefectivo.

Actividades

Actividades Críticas

Rendimiento según Objetivos Indicador Métrica Resultado Objetivo 1: Desarrollar un producto de buena calidad de acuerdo a las especificaciones del cliente. 1.2 Porcentaje de requerimientos incluidos en el producto final. Debe tender a 100% 50% Objetivo 2: Realizar una gerencia de proyectos productiva.   2.1 Porcentaje de error en la estimación del tiempo necesario de desarrollo. Debe ser < 25%. 30% Objetivo 3: Finalizar la implementación de la aplicación a tiempo. 3.1 Numero de días de desfase entre la finalización del desarrollo y la entrega. Debe ser < 5 7 Objetivo 4: Documentar el proyecto de acuerdo a las especificaciones del cliente. 4.1 Porcentaje de documentación realizada 95%

Rendimiento del Equipo Factores a evaluar: Ayuda y soporte. Contribución global. Desempeño de rol. Nivel de compromiso. Contribución al producto.

Rendimiento del Equipo

Admón. de la Configuración Estrategia: Implementar un repositorio único en la plataforma Google Code. Versión propia (Working Copy) de cada desarrollador. Los tags sobre versiones se realizaran únicamente después de fases de prueba satisfactorias.

Admón. de la Configuración Realidad: El trabajo con versiones propias fue efectivo más no se realizó un repositorio único.

Admón. de la Configuración Versionamiento: Numerado, tanto para el código fuente como para los artefactos de documentación, de la siguiente manera: <versión><promoción><revisión> <versión>: modificaciones sustanciales. <promoción>: disposición de todos los miembros del equipo de desarrollo. <revisión>: pequeños cambios de forma y fondo entre promociones.

Organización del Equipo En cuanto a la reunión semanal: Las reuniones semanales servirán como mecanismo de seguimiento del desarrollo por parte de los pares y del líder del equipo. De igual manera en las reuniones se asignarán las tareas y metas por semana.

Organización del Equipo Horarios:   Lunes Martes Miércoles Jueves Viernes Sábado 14:00 Desarrollo 15:00 16:00 17:00 18:00 Seguimiento 19:00 20:00

Reporte de roles

Reporte del Líder Motivación: Compromisos: Soporte del instructor: Bastante buena, al menos por la mayoría del grupo, todos trabajamos con una meta clara y única, la de lograr cumplir los requerimientos en el plazo establecido. Compromisos: Estructuración de tiempos pobre, se aplazaron algunas actividades para el final del ciclo lo que saturó definitivamente los tiempos del grupo.  Soporte del instructor: Se requiere mayor participación en la resolución de problemas técnicos,

Reporte del Líder Reuniones: Las reuniones iniciales se realizaron a través de Skype, de manera virtual. Las reuniones de desarrollo se realizaron de manera presencial para aportar todos al desarrollo de la aplicación y opinar sobre la documentación que se debía adelantar.  Se propició la autonomía y la participación proactiva de los miembros del equipo.

Reporte del Líder Sugerencias: Se necesita un mayor control sobre responsabilidades asignadas y trabajo de los miembros del equipo.

Reporte del Líder de Desarrollo Requerimientos: No se logró implementar todos los requerimientos del ciclo principalmente debido a problemas con el entorno de desarrollo y el manejo de la interfaz gráfica.

Reporte del Líder de Desarrollo Estrategia de desarrollo: La estrategia de desarrollo se basó en el trabajo sobre un solo computador. Se establecieron similitudes con la arquitectura base de la aplicación Songstock. Se requiere configurar mas equipos para el segundo ciclo con el fin de trabajar de manera simultánea.

Reporte del Líder de Desarrollo Diseño: El diseño (arquitectura, interfaz, base de datos) fue otorgado por el cliente, lo que limitó las decisiones de diseño. Se prescindió del uso de Maven para garantizar la compatibilidad por problemas de versionamiento.

Reporte del Líder de Planeación Desempeño: El seguimiento del plan fue deficiente principalmente debido a los problemas de configuración del entorno. Hubo compromiso para realizar la documentación y programación según los requerimientos.

Reporte del Líder de Planeación Uso de la Herramienta: Bastante complicado a pesar de tener experiencia con eclipse, la incorporación de los nuevos elementos como Glassfish, GWT, GXT y las asociaciones y dependencias entre proyectos complicaron el desarrollo de la programación

Reporte del Líder de Planeación Sugerencias: Ser mas realista y cuidadoso a la hora de estimar los tiempos, no se tuvo en cuenta que la curva de aprendizaje fuese tan prolongada. Los planes de mitigación deben seguirse de mejor manera para poder lidiar con los desfases de tiempo en el desarrollo.

Reporte del Líder de Calidad Estimados: Las clases, sus atributos y métodos, de los requerimientos implementados, están adecuadamente documentados como se había planeado. La interfaz gráfica ofrece las funcionalidades necesarias según los requerimientos del cliente.

Reporte del Líder de Calidad Disciplina del Grupo: Se realizó control de calidad por pares al desarrollo tal y como se estipuló en la estrategia.

Reporte del Líder de Calidad Estándares de calidad: Los estándares de calidad utilizados son adecuados, no obstante se deben precisar estándares mas específicos en cuanto a las tareas asignadas.

Reporte del Líder de Calidad Sugerencias: Realizar un control de calidad mas exhaustivo de los documentos entregables en las primeras etapas, con el fin de garantizar que la información obtenida en los mismos sea consistente y acorde a los requerimientos.

Reporte del Líder de Soporte Logística: Como logística pusimos como puntos de reunión la universidad y cuando se nos hacia tarde nos trasladábamos para la casa de algún compañero hasta terminar los objetivos acordados para las . Algunos problemas surgieron en cuanto a los horarios de algunas reuniones, pero fueron cosas menores.

Reporte del Líder de Soporte Versionamiento: Durante la primera etapa de desarrollo hubo algunos problemas con el versionamiento en cuanto al orden y algunas confusiones sobre la versión en la que se estaba trabajando. Con el paso del tiempo se solucionaron los problemas por medio de backups debidamente versionados.

Reporte del Líder de Soporte Sugerencias: El rol podría ser mejor desempeñado si se le da una guía especial al alumno, ya que si esta persona tiene una pequeña ventaja sobre la tecnología y el ambiente de desarrollo, podría ejecutar su rol de una manera mas viable.

Balance general

Factores a Mejorar Estimación de tiempos Administración del Equipo Aprendizaje Actividades Administración del Equipo Asignación de tareas Criterios de calificación Administración de la Configuración Repositorio

Preguntas 11/19/10 42

Muchas gracias