Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

TSP-PSP

No description

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of TSP-PSP

TSP
Es una metodología que nos proporciona un conjunto de procesos definidos que nos indican que hacer en cada etapa de desarrollo para mejorar el trabajo en equipo durante el desarrollo de software.

Los principales objetivos del TSP son:

Desarrollar productos en varios ciclos.
Establecer estándares para medir la calidad y el comportamiento.
Proporcionar métricas para equipos.
Evaluar roles y equipos.
Guías para solución de problemas en equipos.
Maximizar la calidad del software en detrimento de los costos.



TSP (Team Software Process)
PSP-TSP
Ambas metodologías fueron creadas por el Ingeniero y Físico Watts Humphrey (SEI),
en el año de 1996, buscaba dotar a sus estudiantes de ingeniería de software, con una visión total del ciclo de vida del software.


INTRODUCCIÓN AL TSP Y PSP
VENTAJAS Y DESVENTAJAS DE TSP
TSP posee fases donde se describe una serie de pautas para ayudar a realizar un buen desarrollo de software por parte del equipo de trabajo.


FASES DEL TSP
TSP-PSP
METODOLOGÍA DE INGENIERÍA DEL SOFTWARE
POR
PAULA ANDREA URIBE
ANDRES FELIPE CALLE
JESSICA SALAMANCA
MICHEL GÓNZALEZ
ANDRES ORTIZ

1. LANZAMIENTO:

Se dictan los roles y responsabilidades por parte de cada uno de los miembros del equipo. Además se toman en cuenta los requerimientos por parte del cliente y se arma la estrategia a seguir para la culminación del proyecto.

2.ESTRATEGIA

En esta etapa se crea un modelo conceptual de lo que se requiere para brindar la solución más óptima, estableciendo el desarrollo a seguir, así como las estimaciones de esfuerzo y de riesgos.

3.PLANEACIÓN

Una vez desarrollada la estrategia y teniendo en cuenta los procedimientos a seguir y el modelo de la solución del producto, se procede a brindar los roles y las tareas a cada miembro del grupo. En esta etapa se establece el cronograma para la gestión del tiempo y de las tareas que deben de realizarse.
FASES DE TSP
FASES DE TSP
4. REQUERIMIENTOS

Para la gestión de los requerimientos se establecen entrevistas con el cliente a fin de delimitar lo que realmente es necesario producir. Los requerimientos son inspeccionados, con el fin de desarrollar un plan de pruebas para el producto terminado.

6. DISEÑO

Se crea un diseño de alto nivel, se especifica e inspecciona el diseño y se desarrolla un plan de pruebas de integración.

5.IMPLEMENTACIÓN

Es la fase en la cual el diseño se pasa a nivel de código, se analiza y se hace una revisión exhaustiva en busca de errores. Se compilan y se ejecutan los módulos y unidades, al tiempo que se analiza la calidad de estos.

MAPA MENTAL TSP-PSP
VENTAJAS

Mejora los hábitos de programación
Detección temprana de defectos y riesgos.
Mejora de calidad.
Muestra a los ingenieros como generar productos de calidad por medio de una planificación de costos.
Proporciona equipos de proyectos, con guías explicitas sobre como alcanzar sus objetivos.

DESVENTAJAS

Requiere compromiso de cada miembro.
Se debe llenar toda la documentación, no se deben omitir pasos.
Se debe contar con métricas y parámetros de calidad.
PSP (Personal Software Process)
Es un Framework estructurado de formas, guías y procedimientos para desarrollar software.

Con PSP, los desarrolladores utilizan procesos definidos y medibles. Se toma información de tamaño, tiempo y defectos al momento de realizar el trabajo.


Se utilizan los datos para:

Planear y monitorear el trabajo.
Administrar la calidad de los productos que se producen.
Medir y mejorar el desempeño.
PRINCIPALES OBJETIVOS DE PSP
1.Mejorar las estimaciones.

2. Mejorar la planeación y acompañamiento de cronogramas.

3. Proteger contra el exceso de compromisos.

4. Crear un compromiso personal con la calidad.

5. Compromiso del desarrollador en la mejora continua del proceso de desarrollo.

6. Aumento de la calidad a través de la reducción de la incidencia de errores.

7. Mayor precisión en las estimaciones de tamaño del software y tiempo de desarrollo.

8.Metodología de ingeniería del software.
FASES DE PSP
FASES DE PSP
1.MEDICIÓN PERSONAL (PSP0)

El paso inicial en PSP consiste en establecer una base que incluya mediciones y un formato de reportes. Esto permite medir el progreso y define los cimientos para mejorar. Esencialmente, PSP0 es el proceso habitual con el que los desarrolladores escriben software, mejorado para proveer mediciones.

De esta fase se deriva

PSP0.1 : Agregando un estándar de código, mediciones de tamaño y el denominado PIP (Process Improvement Proposal).
El PIP provee una manera estructurada de registrar problemas, experiencias y sugerencias para mejorar.

PSP0.1 también mejora las mediciones para contar separadamente métodos y procedimientos.

FASES DE PSP
Planificación Personal PSP1:

PSP1 le agrega pasos de planeamiento a PSP0. El primer paso agrega estimaciones de tamaño y recursos y un reporte de prueba.
En PSP1.1 se introduce planeamiento de cronograma y seguimiento del proyecto. Los desarrolladores son enseñados a:

Entender la relación entre el tamaño de los programas que escriben y el tiempo que les toma desarrollarlos.
Aprender a realizar compromisos que puedan cumplir.
Preparar un plan ordenado para realizar su trabajo
Establecer una base para realizar un seguimiento de su trabajo.



3.CALIDAD PERSONAL PSP2:

PSP2 agrega diseño personal y revisiones de código a PSP1. Estas revisiones ayudan a encontrar defectos de manera temprana y a ver los beneficios que esto proporciona. Los desarrolladores analizan los defectos que encuentran en los primeros programas y usan estos datos para establecer checklists de revisión que estén hechos a medida de su experiencia de defectos personales.

El proceso de diseño es contemplado en PSP2.1:

Su objetivo es orientar el criterio para la finalización del diseño, es decir, cuando han terminado que es lo que deben haber obtenido. Se establece un criterio de completitud de diseño y se examinan varias técnicas de verificación y consistencia de diseño.

FASES DE PSP
FASES DE PSP
4.PROCESO PERSONAL CÍCLICO PSP3:

PSP3 presenta métodos para ser usados por individuos en la realización de programas de gran escala.

El proceso cíclico PSP3 puede ser un elemento efectivo en un proceso de desarrollo de gran escala solo si cada incremento sucesivo de software es de alta calidad.

De esta manera los desarrolladores pueden concentrarse en la verificación de la calidad del último incremento sin preocuparse por defectos en ciclos anteriores.
Si un incremento anterior tiene muchos defectos, la prueba será más compleja y los beneficios de escalar PSP se pierden. Esta es una razón para enfatizar revisiones de diseño y código en los pasos anteriores de PSP.
LA PLANEACIÓN EN PSP
La Medición del trabajo personal es el primer paso por el que comienza el PSP. Es este primer paso los ingenieros deben aprender como aplicar los formularios del PSP y apuntar datos de su trabajo personal. Para hacer todo esto se mide el desarrollo del tiempo y de los defectos.

Esto hace que los ingenieros recojan datos reales y prácticos y les proporciona una serie de marcar con las cuales ir midiendo el proceso.

Para realizar un trabajo con PSP se debe empezar por el primer paso de medición personal que incluye la gestión del tiempo y el siguiente rastreo del mismo.


LA PLANEACIÓN EN PSP
RECOLECCIÓN DE DATOS
En PSP, los desarrolladores utilizan información para monitorear su trabajo, la cual los ayuda a hacer mejores planes. Para esto, deben recolectar datos de los tiempos que dedican a cada fase del proceso, de los tamaños de los productos que producen, y de la calidad de esos productos.

Las medidas básicas de PSP son el tiempo que el ingeniero utiliza en cada fase del proceso, los defectos introducidos y encontrados en cada fase, y los tamaños de los productos desarrollados en líneas de código (LOC).


Principales Medidas de la recolección datos:
Tamaño y tiempo de estimación de errores.
Coste de realización.
Defectos producidos y corregidos por hora.
Producción del proceso.
Valoración calidad del coste de los fallos (COQ)
Valoración del rango de fallos (A/FR)
FORMATO REGISTRO DEL TIEMPO PSP
El propósito de éste formato es el de registrar el tiempo empleado en cada fase del proyecto. Al mismo tiempo, estos datos son utilizados para complementar el resumen del plan del proyecto.
ESTÁNDAR TIPO DEFECTOS EN PSP
El propósito general de llevar este registro de defectos reside en promover la mejora continúa cada vez que se haga un proyecto:
EVALUACIÓN DE EQUIPOS Y MIEMBROS
FICHA DE RESUMEN PLAN DEL PROYECTO EN PSP
Este formato reúne las estimaciones y los datos reales que conforman al proyecto en toda su amplitud para que al final se realicen las comparaciones necesarias y exista un histórico de todos los proyectos realizados.
APLICACIÓN EN COLOMBIA DE TSP Y PSP
En nuestro país estas metodologías de ingeniería del software están en pleno auge, se ha implementado en ambientes como la inteligencia de negocios TI.

Como se puede ver a continuación: http://www.intersoftware.org.co/content/segunda-convocatoria-tsppsp


VIDEO RESUMEN TSP Y PSP
CMMI CAPABILITY MATURITY MODEL INTEGRATION
El CMMI es un enfoque de mejora de procesos que provee a las organizaciones de los
elementos esenciales para un proceso efectivo.

 El CMMI es el Modelo de Madurez de Capacidades Integrado.
 Fue desarrollado por el SEI (SoftwareEnginnering Institute).
 Mide la madurez del desarrollo del software en una escala del 0 al 5.

OBJETIVOS PRINCIPALES:

 Producir servicios y Productos
de alta calidad.

 Crear valor para los accionistas.

 Mejorar la satisfacción del
cliente.

 Incrementar la participación
en el mercado.

 Ganar reconocimiento en
la industria.

CMMI AREAS QUE CUBRE EN SISTEMAS
El modelo tiene 4 áreas de conocimiento o disciplinas que incluyen :

Ingeniería de Software (SW)
Ingeniería de Sistemas(SE)
Desarrollo Integrado de Productos y Procesos (IPPD)
Acuerdos con Proveedores (SS).
CMMI REPRESENTACIONES
El CMMI tiene dos representaciones:
 Por Etapas (Staged)
 Continuo (Continuous)

Estas representaciones permiten a la organización perseguir diferentes objetivos de mejora.
 La presentación y organización de la información es diferente para cada una,sin embargo el contenido es el mismo.
EJEMPLO DE PROYECTO CON TSP Y PSP
Proyecto: Implementación de un Sistema integrado de Control de Costos de Producción, Órdenes de Trabajo, Presupuesto de Obras, Bodega y Control de Inventario utilizando PSP (Personal Software Process) y TSP( Team Software Process )”

Por :CARLOS MAURICIO ECHEVERRÍA GOYES
CYNTHIA DENISSE ECHEVERRÍA GOYES
JOSÉ LUIS ASENCIO MERA


TESIS DE GRADO
Previa a la obtención del Título de:
INGENIERO EN COMPUTACIÓN, ESPECIALIZACIÓN SISTEMAS TECNOLÓGICOS.
ESCUELA SUPERIOR POLITÉCNICA DEL LITORAL
Facultad de Ingeniería en Electricidad y Computación

VISIÓN:
PSP y TSP nos permitirán controlar individualmente y como equipo nuestro desempeño en el desarrollo del presente proyecto de tesis. Un equipo de trabajo que utiliza TSP está conformado por 5 personas, las mismas que durante todos los ciclos del proyecto asumen los siguientes roles:

Líder de Equipo.
Administrador de Calidad.
Administrador de Planificación.
Administrador de Desarrollo.
Administrador de Configuración.






PROPÓSITO Y ALCANCE DEL PROYECTO


PROPÓSITO:

El propósito de esta tesis es obtener una disciplina de desarrollo de productos de calidad, recolectando y analizando métricas para poder definir estándares que nos ayuden en la mejora de los procesos y demostrar así la aplicabilidad de PSP y TSP.




ALCANCE:

Obtener un producto de software que cumpla con los procedimientos establecidos por PSP y TSP, realizando un seguimiento de la información relativa a la percepción del cliente con respecto al cumplimiento de sus requisitos. El producto a desarrollar es un software denominado “Sistema Integrado de Control de Costos de Producción, Ordenes de Trabajos, Presupuestos por Obra, Bodega y Control de Inventario”, que permitirá ingresar, modificar, consultar e imprimir datos e información relacionada a estos procesos y que apoyen a la toma de decisiones de los directivos de la empresa.









PROPÓSITO,ALCANCE Y ROLES DEL EQUIPO
METODOLOGÍA:DESARROLLO INCREMENTAL
Metodología de Desarrollo :

El modelo de desarrollo incremental fue utilizado para desarrollar el producto de software objeto de nuestra tesis.
Inicialmente se determinaron los siguientes incrementos:
Incremento 1
Módulo de Control de Inventario y Bodega - Módulo Nómina
Incremento 2
Módulo de Ordenes de Trabajo – Procesos que involucran al Módulo de Control de Inventario y Bodega con el Módulo Nómina
Incremento 3
Módulo de Presupuesto por Obra – Módulo Órdenes de Compra
Incremento 4
Módulo de Costos de Producción – Módulo de Facturación

HERRAMIENTAS DE DESARROLLO Y SOPORTE
Herramientas de desarrollo y soporte:

Las herramientas de desarrollo que se utilizaron para este proyecto fueron las siguientes:

Herramientas de programación
o Visual Basic 6.0
o SQL Server 2000
o Crystal Reports 8.0

Herramientas de Control
o Visual Source Safe 6.0
o Microsoft Project 2003

Herramientas de metodología
o Plantillas TSP y PSP Utilitarios.
o Microsoft Office: Word, Excel

RIESGOS DEL PROYECTO
INGENIERÍA DE REQUISITOS
Preparación de entrevistas:

La técnica empleada por nuestro equipo de trabajo para obtener información fue la de “entrevistas”.
Los pasos previos a la aplicación de las entrevistas al cliente y a los usuarios finales fueron los siguientes:
o Identificar a las personas a las que se debía entrevistar.
o Conocer el tema que se iba a tratar.
o Determinar el contenido de las entrevistas.
o Planificar la entrevista.
o Definir el formato de la Minuta de la reunión.

Requisitos C (Cliente)

Los requisitos del Cliente, conocidos también como requisitos C fueron levantados por el equipo de desarrollo, los mismos que describen las necesidades del cliente de manera global sobre cómo el sistema deberá comportarse. Estos requisitos se documentaron de manera explícita y con términos que sean fáciles de entender para el usuario



CASOS DE USO
A continuación se detallan los riesgos identificados en el proyecto:























Descripción:

El Bodeguero verifica una clasificación antes de ingresarla.

A)MCIB notificará la existencia del grupo y en caso de que no exista dará paso para crearlo.

B)El Bodeguero ingresa las especificaciones de dicho grupo.

C)MCIB notificará al Bodeguero sobre el ingreso satisfactorio del grupo.

IMPLEMENTACIÓN
Previa a esta fase, nuestro equipo de trabajo especificó los requisitos, realizó el diseño detallado,
el estándar de programación y la Arquitectura de Software.

6.2 Planificación de la Implementación.

La planificación de la implementación nos llevó a un mejor control de tiempos de desarrollo para
cada uno de los componentes. .

El equipo de trabajo planificó y diseñó las aplicaciones de manera que permitan la reutilización de
código
Se priorizaron los módulos:

1. Módulo Bodega y Control de Inventario
2. Módulo Órdenes de Trabajo
3. Módulo Presupuesto por Obra
4. Módulo Costos de Producción

Manejo y presentación de errores:Para llevar un
control de estos errores, seguimos los
siguientes pasos:

o Realizar revisiones del código.
o Registrar los errores en la plantilla LOGD.
o Ingresar parámetros que puedan generar error.

El equipo clasificó tipos de errores de la siguiente manera:






















MÉTRICAS

El proceso que seguimos para obtener las métricas del proyecto fue (36):
o Analizar y seleccionar las métricas.
o Seleccionar los componentes a medir.
o Medir los componentes.
o Analizar los valores de las métricas.

Las métricas utilizadas son clasificadas por persona según el rol que desempeñan, a continuación se muestra la tabla con las métricas utilizadas.



















MÉTRICAS
MÉTRICAS
Etapa de Desarrollo
Métrica: Longitud de código por tipo de fuente
Total de líneas de código:


Como se podrá apreciar se presentan las líneas de código para cada módulo. El cálculo de LOCs incluye procedimientos, funciones, variables, clases, formularios, comentarios. Como se puede apreciar, los módulos más extensos fueron los de Inventario y Nómina. Coincidentemente, éstos son los que presentaron mayor dificultad durante el desarrollo del sistema debido a la particularidad del negocio.
MÉTRICAS TIEMPO VS COSTO
El tiempo de duración del proyecto de tesis fue de 52 semanas en donde algunos riesgos fueron identificados, algunas tareas fueron desestimadas y los requisitos cambiaron y crecieron.
Como se puede observar en el gráfico anterior vemos los desfases en horas de los roles, el desfase se encuentra en el rango del 17% al 37.5% donde el mayor desfase tuvo el líder del equipo, esto se debió a los cambios constantes de requerimientos de módulos a su cargo, a la falta de experiencia en la herramienta de desarrollo, a la falta de experiencia en planificar y al uso de una nueva metodología.

VERSIONES DEL PROYECTO
En la tabla siguiente se muestra el total de número de versiones obtenidas por módulo y por etapa. Si observamos el cuadro comparativo de esta tabla, podemos ver que existe una disminución en el número de versiones de los elementos de configuración que se encuentran en la etapa de desarrollo como por ejemplo el MCIB se obtuvo un total de 17 versiones de los elementos de configuración, y en MCP que fue uno de los últimos módulos se obtuvieron un total de 6 versiones.

















CONCLUSIONES
1. La metodología TSP puesta en práctica en el equipo contribuyó a que el grupo tenga a una mejor comprensión de sus responsabilidades en los procesos.

2. El TSP funciona en mejor manera siempre y cuando los miembros del equipo trabajen en un mismo lugar.


3.Los modelos facilitan la colaboración entre los distintos miembros del grupo al determinar explícitamente los tipos de interacción que existen en cada etapa del desarrollo de un sistema de software.

4.El registro en las plantillas tanto de PSP como TSP que se utilizaron en el presente trabajo ayudaron a ser más ordenados con el registro en el proceso de desarrollo de software.

5.El modelo incremental es el que más se ajusta a TSP debido a que se puede definir pequeños incrementos y ver las mejoras a medida que se los va desarrollando.
Roles


6. PRUEBAS

En esta etapa el producto ya casi esta terminado, solo falta la integración de los módulos y la documentación para el usuario final, como lo son los manuales de uso. En esta etapa se presentan las diferentes pruebas al sistema con el fin de asegurar su calidad y evaluar el desempeño del equipo de trabajo.

7. POST-MORTEM

Se evalúan los análisis de los resultados de las diferentes pruebas y del desempeño del equipo. Se escribe con detalles el reporte del ciclo de vida del proyecto.
Full transcript