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.

Slides:



Advertisements
Presentaciones similares
Metodologías ágiles.
Advertisements

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.
Postmortem Ciclo2 Proyecto de Notificación y Comunicación Electrónica de la Plataforma de Interoperabilidad Carlos Andrés Arango Jorge Eduardo Garzón Daniel.
ACTIVIDAD 1: El grupo de ingeniería de software participa en la propuesta del proyecto. (objetivos, metas, soluciones, técnicas, estándares).
Estructura de SW-CMM.
Herramientas y metodologías de éxito para el manejo de proyectos TIC: Caso PYME CREATIVA Noviembre 2008.
SYSMOTORFLOW PRESENTACIÓN DEL PROCESO Proyecto de Ingeniería de Software 2010.
2010 Presentación Final Proyecto Originación de Crédito
Metodologías de Desarrollo
[CURSO O MATERIA] [INTEGRANTES DEL GRUPO] POSTMORTEM [EL NUMERO DEL POSTMORTEM O VERSION] Total tiempo: 15 min.
Fase Elaboración Conclusiones Grupo 6 – PIS
Proceso de Originación de Crédito: Banco de los Alpes
Proyecto: Lanzamiento
AUDITORIA INTERNA.
POSTMORTEM TSP - CICLO I
Evaluación de Productos
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.
Propuesta de una metodología para el desarrollo de proyectos informáticos empleando la herramienta para el diseño automatizado GeneXus Autor: Dipl.-Ing.
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.
ADMINISTRACIÓN DE REQUERIMIENTOS
Fase Inicial Grupo 6 – PIS – 2013.
Sistema de Administración de Macro Currículos (SAMA)
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.
Proyecto de Ingeniería de Software Grupo 9 Septiembre 2009
4/27/2015Gestión de Proyectos de Software1 PLANEACIÓN ESTRATÉGICA – PRIMERA PARTE Carlos Mario Zapata J.
Administración Proyectos Jorge Baracaldo Robin Ochoa.
Proyecto de Ingeniería de Software - Grupo 2 - Año 2006 Presentación del Proceso Sistema de Administración de Proteínas Objetivo y eXperimentos del Pasteur.
Presentación Final Proyecto Originación de Crédito Especialización en construcción de software Universidad de los Andes Bogotá Julián Morales.
Ximena Romano – Doris Correa
LSQA + Equipo Proyecto  Definir Proceso: A nivel de la Organización A nivel de Proyecto Actividades SQA: – Asegurar que el Producto cumple con los Requisitos.
Presentación Final Proyecto Originación de Crédito Especialización en construcción de software Universidad de los Andes Bogotá Julián Morales.
Rational Unified Process
Especialización en Desarrollo de Software
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
Roles de Open UP.
PROYECTO ECOS.  Producto desarrollado  Problemas encontrados  Riesgos materializados  PIP.
TIPOS DE AUDITORÍAS EN SISTEMAS DE INFORMACIÓN
1 Motor de Generación de Formularios para Infocorp Presentación del Proceso.
Mini-Assessment Los Alpes Software Grupo Quimera INTEGRANTES: Alexandra Marín Juan Carlos Lopera Camilo Forero Luis Carlos Ávila Javier Murcia.
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.
Mini-Assessment Proceso Desarrollo Quimera INTEGRANTES: Alexandra Marín Juan Carlos Lopera Camilo Forero Luis Carlos Ávila Javier Murcia.
Introducción al proceso de verificación y validación.
Page  1 Herramientas Utilizadas Ciclo I Aplicación FICO HERRAMIENTA UTILIZADAFASE Planeacion - Pruebas Planeacion - PostMortem Analisis - Diseño Implemetación.
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.
INTEGRANTES: Alexandra Marín – Líder de calidad
Proyecto: Lanzamiento QUICK ORDER. Objetivo General  Desarrollar el sistema de información de acuerdo a los requerimientos establecidos por el cliente,
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.
Estructurar tus ideas para hacerlas realidad
Implementando PSP / TSP
Propuesta de Mejoramiento Los Alpes Software Grupo Quimera INTEGRANTES: Alexandra Marín Juan Carlos Lopera Camilo Forero Luis Carlos Ávila Javier Murcia.
CICLO 1 BEATRIZ BARREIRO GÓMEZ HENRY SUÁREZ SÁNCHEZ
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.
Gestión de la Comunicaciones
TEAM SOFTWARE PROCESS CICLO 1. El software propuesto por el equipo de Ingenium para cumplir con las necesidades planteadas, modela los un conjunto de.
Aseguramiento de la Calidad. (Software Quality Assurance, SQA) Por. Ing. Ernesto Soto Roca.
Sistemas de calidad en el desarrollo de software.
Entregables del Proyecto
PROYECTO NYCE Notificaciones y Comunicaciones Electrónicas Ciclo 2.
Junio, 2013.
Transcripción de la presentación:

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 Javier Murcia

Page  2 1. Producto 2. Reporte de datos 3. Propuestas de mejoramiento 4. Organización del grupo 5. Herramientas AGENDA

Page  3 1. Producto 2. Reporte de datos 3. Propuestas de mejoramiento 4. Organización del grupo 5. Herramientas AGENDA

Page  4 Requerimientos Ciclo 1: CU0001-Ingresar datos FICO CU0002-Calcular FICO CU0003-Calcular criterio de histórico de pagos CU0004-Calcular criterio montos adeudados CU0005-Calcular criterio duración del crédito CU0006-Calcular criterio de nuevos créditos CU0007-Calcular criterio del tipo de crédito PRODUCTO (1)

Page  5 PRODUCTO (2) Diagrama de clases

Page  6 PRODUCTO (3) Interfaz gráfica

Page  7 1. Producto 2. Reporte de datos 3. Propuestas de mejoramiento 4. Organización del grupo 5. Herramientas AGENDA

Page  8 REPORTE DE DATOS (1) Objetivos y metas del equipo MetaResultado El n ú mero de horas de trabajo no debe ser superior a 20 a la semana En realidad fueron 130,45h Calificaci ó n del proyecto mayor o igual a 4.5, validando lo aprendido. A ú n no sabemos la nota Porcentaje de informaci ó n registrada en el repositorio del proyecto igual al 100% seg ú n el TSP. 100% de los artefactos fue subida en el SVN La diferencia total en el n ú mero de horas invertidas entre los integrantes, no debe superar el 5%. La diferencia entre lo trabajado por cada integrante fue menor al 6,5h (5%) para 5 de los 6 integrantes Requerimientos solicitados incluidos en el producto final mayor al 90%. El producto a ú n no ha sido terminado Porcentaje de defectos encontrados antes de iniciar las pruebas 80%. A ú n no tenemos forma de medirlo debido a que a que se implemento el core y una pantalla, pero no sus reglas de negocio.

Page  9 REPORTE DE DATOS (2) Objetivos y metas de los miembros del grupo MetaResultado Evaluaci ó n promedio de la contribuci ó n total al equipo mayor a 3. En realidad el promedio fue de 4.3 El n ú mero de las tareas de las que es responsable cada integrante es alrededor del 20% del total. En total fueron 121 tareas, el 20% corresponde a 24,2 tareas La asignaci ó n para 5 de los 6 integrantes estuvieron por encima de 24,2 tareas. El n ú mero de tareas entregadas es igual al n ú mero de las asignadas a cada integrante Todas las tareas fueron realizadas en su totalidad

Page  10 REPORTE DE DATOS (3) Objetivos y metas no de los miembros por rol Líder de equipo: MetaResultado Las evaluaciones promedio de los integrantes del equipo son 3 o mejor. En realidad el promedio fue de 4.8 El equipo alcanza los objetivos de calendario y calidad. Se alcanzaron las tareas de calendario, pero no las de calidad. Todos los miembros trabajan las horas asignadas al proyecto Todos los integrantes trabajaron las horas asignadas para el proyecto. Todos los miembros llevan el control de tiempo y siguen el plan establecido en el dotProject. Al final, todos los integrantes siguieron el plan que estaba disponible en dotProject El n ú mero de tareas entregadas es igual al n ú mero de las asignadas a cada integrante Todas las tareas fueron realizadas en su totalidad

Page  11 REPORTE DE DATOS (3) Objetivos y metas no de los miembros por rol Líder de planeación: MetaResultado Incluir el 100% de las tareas en el plan de trabajo. Se elaboro inicialmente una WBS incluyendo en su totalidad los entregables del producto y del proyecto para el ciclo 1, en base a esta se genero el plan de trabajo. Documentar el plan de trabajo y registrarlo a través de una herramienta de control como DotProject. A partir de la WBS y el plan de trabajo se creo la planeaci ó n dotProject. Planear de tal forma que las horas de trabajo a la semana por cada miembro del equipo esten entre 5 y 10 horas. Esta meta no se logro ya que en la estimaci ó n inicial solo se tuvo en cuenta el tiempo necesario para la elaboraci ó n de los entregables del producto mas no los entregables del proyecto, otro factor con el que no cont á bamos era con el tiempo de elaboraci ó n de lineamientos y formatos para la ejecuci ó n del proyecto. Proveer un reporte del estado del proyecto semanalmente. Se planteo la utilizaci ó n de la herramienta planning tool para la generaci ó n de reportes los cuales nos ayudaran a visualizar el estado del proyecto. Verificar que los miembros del equipo reporten el tiempo usado y estado de las tareas asignadas. El l í der de plantaci ó n hacia seguimiento del reporte de actividades en la herramienta, en caso de encontrar faltantes o inconsistencias se comunicaba con el miembro del equipo para hacer revisi ó n de estos casos.

Page  12 REPORTE DE DATOS (3) Objetivos y metas no de los miembros por rol Líder de desarrollo: MetaResultado La estrategia es comprendida en un 100% por los desarrolladores. Al ser el componente a desarrollar tan peque ñ o fue sencillo comprender la estrategia a su 100%. 100% de los requerimientos desarrollados por ciclo Se realizaron el 100% de los requerimientos para este ciclo, el cual comprend í a el implementar el core del sistema y la pantalla de ingreso de datos para la evaluaci ó n de riesgo.

Page  13 REPORTE DE DATOS (3) Objetivos y metas no de los miembros por rol Líder de calidad: MetaResultado Todos los miembros del equipo registran la informaci ó n del proceso en el 90% de los casos. Al ser un trabajo en equipo se distribuy ó de tal forma el trabajo para que cada entregable fuera entrada para otra parte del proceso, adem á s por cada entregable se definio un par revisor esto nos sirvi ó para controlar la elaboraci ó n de los entregables del proyecto y del producto. El plan de calidad se encuentra completo al 100%.

Page  14 REPORTE DE DATOS (3) Objetivos y metas no de los miembros por rol Líder de soporte: MetaResultado Al iniciar el proyecto est á n definidas el 80% de las herramientas a usar. Los miembros del equipo tienen configurado el 100% de las herramientas definidas al iniciar el proyecto

Page  Producto 2. Reporte de datos 3. Propuestas de mejoramiento 4. Organización del grupo 5. Herramientas AGENDA

Page  16 PROPUESTA DE MEJORAMIENTO (1) Soporte Problemáticas identificadas NúmeroDescripción 1Se tuvieron muchos problemas en la instalación y puesta en marcha de la herramienta DotProject, hasta muy al final del ciclo y por tal razón se dificulto la tarea de seguimiento de actividades. Propuestas de mejora NúmeroDescripción 1Configurar la herramienta antes de ejecutar.

Page  17 PROPUESTA DE MEJORAMIENTO (1) Lanzamiento Problemáticas identificadas NúmeroDescripción 1En la estimación de esfuerzo únicamente se tuvo se hizo pensando a nivel de producto mas no de proyecto, por tal razón lo planeado en la estrategia difiere mucho en el tiempo real empleado del ciclo 1. Propuestas de mejora NúmeroDescripción 1En la estimación tener en cuenta el esfuerzo del producto y del proyecto.

Page  18 PROPUESTA DE MEJORAMIENTO (2) Manejo de Riesgos Problemáticas identificadas NúmeroDescripción 1Definición de tareas críticas que toman mucho tiempo y pueden impactar el proyecto. Propuestas de mejora NúmeroDescripción 1Las tareas se planearán de forma que sean de poca duración y sean fáciles de controlar. 2Se planearán contingencias en caso de presentarse alguno de los riesgos identificados.

Page  19 PROPUESTA DE MEJORAMIENTO (3) Comunicación Problemáticas identificadas NúmeroDescripción 1Algunas veces los objetivos de las reuniones de seguimiento no son claros. 2No hubo una comunicación efectiva para informar el avance de las actividades. Propuestas de mejora NúmeroDescripción 1Dar a conocer los objetivos de la reunión al comienzo de cada una. 2Verificar al inicio de cada reunión el estado de las tareas asignadas por integrante.

Page  20 PROPUESTA DE MEJORAMIENTO (4) Control y Seguimiento Problemáticas identificadas NúmeroDescripción 1El registro de defectos no se está manteniendo de forma disciplinada. 2Se ejecutan tareas fuera del plan original que no son registradas. Propuestas de mejora NúmeroDescripción 1Todos los miembros del equipo registraran los defectos y estos se revisarán en cada reunión de seguimiento. 2Tener en cuenta tareas particulares no planeadas inicialmente e incluirlas en la planeación semanal.

Page  21 Agenda 1. Producto 2. Reporte de datos 3. Propuestas de mejoramiento 4. Organización del grupo 5. Herramientas

Page  Organización del grupo Primera reunión Cumplimiento de compromisos. Que estrategias funcionaron y cuales no funcionaron. Aspectos positivos y negativos Aspectos aprendidos Expectativas vs realidades

Page  23 Agenda 1. Producto 2. Reporte de datos 3. Propuestas de mejoramiento 4. Organización del grupo 5. Herramientas

Page  24 Herramientas Utilizadas Ciclo I Aplicación FICO HERRAMIENTA UTILIZADAFASE Planeacion - Pruebas Planeacion - PostMortem Analisis - Diseño Implemetación 5. Herramientas

Page  25 Herramientas Utilizadas Ciclo I Aplicación FICO HERARAMIENTA UTILIZADADESCRIPCIONPROSCONTRAS DOT PROJECT Es una aplicación Web, fácil de ingreso solo se necesita Browrser Herramienta nueva equipo se necesita aprendizaje Programación Tareas Fácil de Realizar Inconvenientes instalación herramienta Aplicación de gestión de proyectos basada en web Software Gratuito - Fácil implantación diseñada para gestionar proyectos y sus funciones Robustez y portabilidad de los datos: MySQL Backup de control GUI dotProject Sencilla y facil utilizar Gestión Simple de Usuario y Roles Contiene Diagramas Gannt

Page  26 Herramientas Utilizadas Ciclo I Aplicación FICO HERARAMIENTA UTILIZADADESCRIPCIONPROSCONTRAS PLANNING TOOL Fácil Instalar, solo se necesita JAVA No posee seguridad vulnerabilidad a los datos Enfocado a desarrollo de software (Maneja Ciclo) Poco portable, exporta XML se puede perder Extension de la funcionalidad de DOT-PROJECT Facil conexión con DOT- PROJECT Herramienta nueva equipo se necesita aprendizaje especializacion para proyectos de software Reportes Graficos GUI facil de utilizar e intuitiva Asociación de las fases del ciclo con las tareas planeadas Software Gratuito - Fácil implantacion

Page  27 Herramientas Utilizadas Ciclo I Aplicación FICO HERARAMIENTA UTILIZADADESCRIPCIONPROSCONTRAS ENTERPRISE ARCHITECT Herramienta robusta contiene todos los artefactos planeados Licenciada (Precio Bajo) GUI fácil de utilizar e intuitiva No posee seguridad vulnerabilidad a los datos Herramienta UML para modelar todas las fases Facil instalacion Poco portable, exporta EAP se puede perder del ciclo de vida de desarrollo SW Maneja Estandar UML NO se integra con DotProject Generacion documentos poderosa: en archivos, y en web Solo funciona en plataformas Windows Generacion codigo automatica: A partir de los diagramas Ingenieria Inversa ECLIPSE Compilación Automática: Disminuye tiempo Consume muchos recursos - Memoria Entorno de desarrollo en JAVA Conexión con el CVS utilizamos proyecto Software Gratuito - Fácil implantación Utilización de wizard para crear artefactos software