TEAM SOFTWARE PROCESS CICLO 1. El software propuesto por el equipo de Ingenium para cumplir con las necesidades planteadas, modela los un conjunto de.

Slides:



Advertisements
Presentaciones similares
Unida III Software para la administración de proyectos
Advertisements

ingeniería de software
Ingeniería de Software II
Proyectos Informáticos
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.
BizAgi - Business Agility
2010 Presentación Final Proyecto Originación de Crédito
Metodologías de Desarrollo
10º2 Sergio Posso. Jonatán Agualimpia. Julia Blandón. Docente:
Fundamentos de la Gestión de Proyectos
[CURSO O MATERIA] [INTEGRANTES DEL GRUPO] POSTMORTEM [EL NUMERO DEL POSTMORTEM O VERSION] Total tiempo: 15 min.
Especificación y Descripción de Liberación. Líneas Base.
Fase Elaboración Conclusiones Grupo 6 – PIS
Proceso de Originación de Crédito: Banco de los Alpes
Neotect S.A.. Desarrollar el Software CreditScore de acuerdo a los requerimientos del Banco de los Alpes, y a las restricciones de tiempo y costo acordadas.
CreditScore: Plan de calidad
Proyecto: Lanzamiento
POSTMORTEM TSP - CICLO I
Unidad I: CONCEPTOS FUNDAMENTALES
Evaluación de Productos
MSI. Nancy A. Olivares Ruiz
Ciclo de formulación del proyecto.
Ingeniería del software de la usabilidad (I)
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.
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.
Conclusiones de Fase de Construcción Grupo 2 – Año 2006.
Fase Inicial Grupo 6 – PIS – 2013.
Líder: Mayeline Castiblanco Desarrollo: Jefferson Rodríguez Calidad y Proceso: John Rodríguez y Adriana Flores Soporte: Diego Andrade Planeación: Javier.
Inspecciones de Software
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.
Administración Proyectos Jorge Baracaldo Robin Ochoa.
Análisis y diseño detallado de aplicaciones informáticas de gestión
Presentación Final Proyecto Originación de Crédito Especialización en construcción de software Universidad de los Andes Bogotá Julián Morales.
Fin Fase Elaboración Presentación al director del proyecto Agenda –Objetivos –Cumplimientos –Conclusiones Presentación al director del proyecto Agenda.
Team Software Process IntroductionTSPiSM Watts Humphrey
35 años de investigación, innovando con energía 1 Mayo, 2012 P LAN DE ASEGURAMIENTO DE LA CALIDAD DEL DESARROLLO DE SOFTWARE E STÁNDAR IEEE 730 Y G UÍA.
Especialización en Desarrollo de Software
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:
INGENIERÍA DEL SOFTWARE GESTIÓN DE PROYECTOS
Alexander Aristizabal Ángelo flores herrera
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.
Unidad I: CONCEPTOS FUNDAMENTALES
Ingeniería de Software
PROCESOS DE DESARROLLO DE SOFTWARE
Proyecto: Lanzamiento QUICK ORDER. Objetivo General  Desarrollar el sistema de información de acuerdo a los requerimientos establecidos por el cliente,
Implementando PSP / TSP
Ingeniería en Informática F UNDAMENTOS DE C OMPUTACIÓN B ACHILLERATO EN I NGENIERÍA I NFORMÁTICA L IC. C ARLOS H. G UTIÉRREZ L EÓN.
MÓDULO INTRODUCCIÓN AL CICLO DE VIDA DEL SOFTWARE
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.
Proyecto de Ingeniería de Software 2008 Proyecto TITA Soft. Grupo 02.
Proceso de desarrollo de Software
TAREAS DEL CONTROL DE CALIDAD
CONCEPTO DE CICLO DE VIDA 1 En los departamentos de Sistemas se debe definir un marco de referencia común que debe ser:  Pueda ser empleado por todos.
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.
Procesos de Planeación
Aseguramiento de la Calidad. (Software Quality Assurance, SQA) Por. Ing. Ernesto Soto Roca.
PSP Y TSP.
Sistemas de calidad en el desarrollo de software.
Entregables del Proyecto
Taller de Desarrollo de Proyectos II (75.47) 2º cuatrimestre 2008.
Gestión del Alcance del Proyecto
Junio, 2013.
Transcripción de la presentación:

TEAM SOFTWARE PROCESS CICLO 1

El software propuesto por el equipo de Ingenium para cumplir con las necesidades planteadas, modela los un conjunto de requerimientos que tienen por objetivo permitir llevar el seguimiento del desarrollo de un equipo que sigue TSP como proceso de desarrollo

El producto de software incluirá las siguientes funcionalidades por ciclo.  Permitir al usuario generar el reporte de productividad del grupo, así como también la productividad de cada integrante. (Ciclo 1)  Permitir al usuario registrar el grupo de trabajo dentro de la aplicación (Ciclo 3)  Permitir al usuario registrar las tareas planeadas por cada ciclo y asignarlas a un responsable (Ciclo 3).  Permitir al usuario registrar el plan de calidad (Ciclo 3)  Permitir al usuario generar el reporte de productividad del grupo, así como también la productividad de cada integrante del grupo de manera gráfica. (Ciclo 2)

Resultados del aplicativo, donde se procesan las anotaciones por cada persona del equipo Resultados ciclo 1

Resultados del aplicativo, donde se procesan las anotaciones por cada persona del equipo Resultados ciclo 1

Resultados del aplicativo, donde se procesan las anotaciones por cada persona del equipo y se presentan de manera agradable al usuario. Resultados ciclo 3

En total se registraron 54,4 horas de trabajo para realizar 84 líneas de código, con un a productividad de 2 líneas de código por hora aproximadamente.

Para el desarrollo del proceso TSP se planteó la generación de algunos entregables que guiaron todo el proceso de desarrollo, en cada fase se consideraron los artefactos necesarios para le apoyo al desarrollo del software y fueron recopilados en el documento TSP.

Se Inicio todo el proceso con la creación del documento de lanzamiento. Se desarrollo el proxy y se realizaron las estimaciones con la recopilación de los datos de cada uno de los integrantes del grupo, estos datos fueron normalizados para que pudieran utilizarse de manera confiable. Con todos estos datos el líder de planeación nos guio para crear un cronograma que nos permitiera con los recursos disponibles alcanzar el producto que definimos desarrollar. A través de un repositorio con control de versiones y un plan se llevó el seguimiento, y se logró control permanente de las actividades tanto del desarrollo del software, como el proceso TSP. Finalmente, con ayuda de las herramientas seleccionadas y nuestro propio software, se realizó la evaluación de las actividades para este ciclo y se cerró satisfactoriamente.

En general el grupo de acuerdo a sus comentarios sabe que el proceso ha sido costoso pero espera que esto facilite los próximos ciclos.

Todos los integrantes del equipo deben estar presentes y llegar a un acuerdo de las actividades a desarrollar para que no se sobrecargue a nadie. Es indispensable que se normalicen los datos de cada persona para que se puedan tener en cuanta en el análisis grupal.

Se debe considerar un análisis a nivel de tareas para aprender de cada integrante de manera más detallada y proponer mejoras más conscientemente. Se debe seguir con la buena práctica de buscar errores en cada fase a través de los diferentes métodos, inspección, pruebas, discusiones, etc.

Se debe considerar plantear objetivos y métricas más sencillas y en una menor cantidad para evaluar mejor el proceso, el grupo y el software. Para evaluación de ciclos posteriores se debe considerar el tiempo completo desde el ciclo 1 debido a que gran trabajo de preparación para los ciclos siguientes se realizo en el primer ciclo.