FIUBA 2.0 Grupo 3 Orlando Gerbolés Tomas Niño Kehoe Gustavo Narcisi Sabrina Marcus.

Slides:



Advertisements
Presentaciones similares
SACP.
Advertisements

Presentación Inicial Grupo 3 Fondato, Rodrigo Cieri, Juan Cristian
Presentación Final SUBI Fondato, Rodrigo Cieri, Juan Cristian Gonzalez, Ailin Verbner, Alan.
Metodologías ágiles.
Presentación final Administración de Proyectos
Red Social Universitaria IntegrantePadrón Keena, Hernán84471 Kehoe, Sebastián79996 Knight, Juan83476 Kuperman, Jonathan º Cuatrimestre 2009.
FIUBA 2.0.
75.47 PRESENTACIÓN INICIAL Taller de Desarrollo de Proyectos II
SERVICIO DE EVALUACIÓN PARA CERTIFICACIÓN PMP
Sambayón PMP Evaluator
FIUBA 2.0 Grupo 3 Orlando Gerbolés Tomas Niño Kehoe Gustavo Narcisi
El Mercado del Proyecto.
1 FIUBA 2.0 Grupo 3 Orlando Gerbolés Tomas Niño Kehoe Gustavo Narcisi Sabrina Marcus.
PORTAL WEB Manual de Usuario Perfil Autorizador
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.
Presentación de seguimiento del proyecto Equipo LSI 02
Taller de Desarrollo de Proyectos II (75.47) Presentación Inicial ERNESTO GIMENO PABLO BESADA SANTIAGO PETERSEN PATRICIO FAGALDE
PMO Vicepresidencia TyO _Servicios PMO
Experiencia e innovación
Data Mart para la gestión de reportes y apoyo a la toma de decisiones del departamento de RR.HH. de la empresa de agua S.A.” Agosto 2010.
Proceso de Originación de Crédito: Banco de los Alpes
Proyecto de Ingeniería de Software 2008
Empresa: Liebre Primer ciclo Proyecto TripleC. Conseguir soluciones inteligentes para satisfacer de una manera rápida y segura las necesidades de nuestros.
Red Social Universitaria
Presentación Final Equipo 4
Beneficios Fiuba4Android
Características Técnicas
Taller de Desarrollo de Proyectos II 2do cuatrimestre 2010.
Sistema de Administración de Subastas Inversas
Taller de Desarrollo de Proyectos II 2do cuatrimestre 2010
CheckIn4Android.
Trabajo Práctico Taller de Desarrollo de Proyectos 2 Septiembre 2009.
Propuesta de una metodología para el desarrollo de proyectos informáticos empleando la herramienta para el diseño automatizado GeneXus Autor: Dipl.-Ing.
Ciclos de vida ágiles.  Es una metodología ágil que plantea: ◦ Iteraciones cortas ◦ Entregables periódicos ◦ Colaboración con el cliente full time ◦
 Tema del proyecto  Integrantes y roles del equipo  Objetivos del proyecto  Alcance.
Fase Inicial Grupo 6 – PIS – 2013.
¿El nivel de detalle? “Esta es una de las preguntas más difíciles en el RCM.” John Moubray.
Evaluación de sistemas de cómputo Edna Martha Miranda Chavez Sergio Fuenlabrada Velázquez Sep 2010 BENCH MARK para compra de software de base, herramientas,
Aplicaciones de Ingeniería de Software
LINQ TO AMAZON IN SILVERLIGHT Presentación del Producto.
Presentación de seguimiento del proyecto Equipo LSI 02 Resultados de la 1ª Iteración de Construcción.
Presentación de seguimiento del proyecto Equipo LSI 02 Resultados de la 3ª Iteración de Construcción.
Modelo en Cascada Planeación Estratégica Estudio de Factibilidad
Integrantes:  Gabriel Centurión  Maximiliano Félix  Felipe Rodríguez  Rodrigo Santana.
Arnoni, Mauro García, Nicolás Getti, Esteban Monti, Javier
El rol de SQA en PIS.
Taller de Desarrollo de Proyectos II (75.47) Grupo 2 Taller de Desarrollo de Proyectos II (75.47) Presentación Final ERNESTO GIMENO PABLO BESADA.
Universidad Andrés BelloESCUELA DE INFORMATICAFacultad de Ingeniería.
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 E-HOCKEY Grupo 3 [75.47] Taller de Desarrollo de Proyectos II.
Roles de Open UP.
Jonathan Levy (82.897) Juan Pablo Pérez Perri (83.558) Mariano Converti (85.617) Esteban Lopez (84.960) Equipo: Taller de Desarrollo de Proyectos.
Ingeniería de Requerimientos
Evaluación de Desempeño Proceso, Métodos
Proyecto: Lanzamiento QUICK ORDER. Objetivo General  Desarrollar el sistema de información de acuerdo a los requerimientos establecidos por el cliente,
ADN2 Diseño ágil de noticias Historia de un trabajo profesional.
Colegio de Bachilleres Plantel 13 Xochimilco - Tepepan
Taller de desarrollo de proyectos II Presentación Inicial.
Taller de Desarrollo de Proyectos II Taller de Desarrollo de Proyectos II.
Daniel Labra Fernando Figueroa ¿Qué Hicimos? -Refinar Causa-Efecto -Gestión de la Configuración -Control de versiones -Encuesta ¿Qué estamos haciendo?
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede.
Sistema Empresarial de Gestión de Tickets, Clientes, Proveedores e Insumos.
Taller de Desarrollo de Proyectos II (75.47) Grupo 2 Taller de Desarrollo de Proyectos II (75.47) Presentación Final ERNESTO GIMENO PABLO BESADA.
Análisis y Balance del Proyecto Análisis Inicial Estimación Inicial Arquitectura de Datos Propuesta Tecnología Metodología aplicada Estimaciones elaboradas.
Autor: Reinozo Cuesta Christian Marcelo
TEAM SOFTWARE PROCESS CICLO 1. El software propuesto por el equipo de Ingenium para cumplir con las necesidades planteadas, modela los un conjunto de.
Taller de Desarrollo de Proyectos II (75.47) 2º cuatrimestre 2008.
Canchas al Móvil Proyecto Integrador 1 Carolina Garcés.
Junio, 2013.
Transcripción de la presentación:

FIUBA 2.0 Grupo 3 Orlando Gerbolés Tomas Niño Kehoe Gustavo Narcisi Sabrina Marcus

Í NDICE Metodología Herramientas Solución elegida Manejo de riesgos Lecciones aprendidas Demo

M ETODOLOGÍA

PMBOCK utilizando conceptos básicos de LEAN Explico esto?

H ERRAMIENTAS

WBS Visual Studio 2008 NUnit SQL Server 2005 Assembla (Seguimiento de incidentes y SVN) Enterprise Architect Word / Excel – Open Office

S OLUCIÓN ELEGIDA Lenguaje Base de datos Arquitectura

S OLUCIÓN ELEGIDA Lenguaje: C# Organización de la solución 5 Proyectos FIUBA20 (parte central de la aplicación) FIUBA20.DA (mapeo de esquema de base de datos) FIUBA20BACKEND (Administrador de la aplicación) FIUBA20Servicio (capa de servicios) FIUBA20Test (test unitarios de la capa de servicios)

B ASE DE DATOS Puede venir un esquema de la tabla utilizada?

A RQUITECTURA

R IESGOS

L ECCIONES APRENDIDAS Selección del lenguaje Gold-Plating Calculo de EV Comunicación Cambio de roles según necesidades Unificación del criterios Seguimiento de incidentes ?

S ELECCIÓN DEL LENGUAJE Selección inicial del lenguaje: Python Intención de aprender el lenguaje por parte de uno de los miembros El resto aceptó sin considerar las complicaciones y cantidad de trabajo a realizar Primer entrega con Python y poca funcionalidad cerrada. Un sólo desarrollador El resto del grupo no tuvo intención de aprender Python Cambio de lenguaje C# Consecuencias 3 desarrolladores disponibles Retrabajo – se reescribió lo pactado para la primer entrega y se incluyó lo pactado para la segunda en una sola iteración. Reestructuración de roles. Fricciones dentro del grupo Descontento por el cambio. Eliminación de riesgos Se dejó de depender de la disponibilidad de una sola persona para el desarrollo, con lo cual la probabilidad de ocurrencia descendió. Demostrar al cliente que tomamos una mala decisión pero tenemos acciones para corregir el desvió no es una muestra de debilidad sino de madurez

G OLD -P LATING ¿Qué es Gold-Plating? Dar al cliente más de lo que fue solicitado No posee valor alguno Exceder los requerimientos especificados es una perdida de tiempo y dinero sin ningún agregado al projecto. En contra de los conceptos de LEAN El cliente debiera Esperar y recibir exactamente lo que se especifico, ni más ni menos En FIUBA20 Inclusión de detalles no solicitados Funcionalidad no especificada se elimino luego de mostrar los prototipos o las funcionalidades en reuniones formales Retrabajo

C ÁLCULO DE EV

C OMUNICACIÓN Grupo google Seguimiento de los issues con comentarios al hacer commits

C AMBIO DE ROLES SEGÚN NECESIDADES Adaptación de los distintos integrantes a distintos roles Con el cambio del lenguaje se readaptaron los roles Versatilidad permitió que se pudiera avanzar dependiendo de disponibilidad de tiempo de cada uno

U NIFICACIÓN DEL CRITERIOS Diferentes criterios en definición de bugs Qué es bug y que no Cuando un bug está cerrado y cuando no Solución buscada Determinar los criterios para establecer estándar propio del grupo. Por lo general, se consiguió aplicar.

S EGUIMIENTO DE INCIDENTES

D EMO

?