Que Es PSP yTSP

ESCUELA SUPERIOR
POLITECNICA DEL LITORAL
FACULTAD DE INGENIERIA
ELECTRICA Y COMPUTACION
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 )
TESIS DE GRADO
18/08/2006
Mauricio Echeverria - Denisse Echeverria - Jose Luis Asencio

Escuela Superior Politécnica del Litoral
INTRODUCCION
A
Justificación.
Qué es PSP y TSP?
Relación entre PSP y TSP
D
Beneficios PSP y TSP

EXPLICACION DEL TRABAJO
N
TSP y su aplicación en el proyecto

Roles y responsabilidades
E
Etapas definidas del proyecto

Evaluación de métricas
ANALISIS DE LA METODOLOGIA
G
Antes y Después de TSP

Factores de mejoramiento
A
CONCLUSIONES Y RECOMENDACIONES
PSP Personal Software Process TSP Team Software Process

INTRODUCCIÓN Escuela Superior Politécnica del Litoral
Hoy en día
Importancia en el desarrollo del software en el Pais.

Crecimiento constante de esta actividad en los ultimos años.
Existen inconvenientes en el desarrollo del software.

Pocas empresas utilizan estándares y factores de medición en el
desarrollo del software
El uso de metodologías de desarrollo ayuda a adoptar

esquemas de trabajo para cumplir los objetivos del equipo.
Gestión de Software
Personas + tecnología Producción heroica
Personas + procesos + tecnología Producción eficiente

Qué es PSP y TSP?
PSP TSP
Procesos individuales definidos Proceso en equipo
Medición gradual del desempeño Mejora continua de desarrollo
Registro de tiempo Equipo eficiente y colaborador
Propuestas de mejoras al proceso Enfocado a cinco roles
Estimación de tamaño - tiempo Genera disciplina en equipo
Las metodologías implementadas son sugeridas por el Instituto de Ingeniería de

Software (SEI)

Relación entre PSP y TSP

TSP en TSP en
PSP desarrolla
construcción trabajo en
habilidades
del equipo equipo
Mediciones personales Objetivos del proyecto Análisis de riesgos
Disciplina en el proceso Roles en el equipo Comunicación del equipo
Estimación y planificación Proceso del equipo Coordinación del equipo
Gestión de la Calidad Plan del proyecto registro del estado

Plan balanceado Informes del proyecto
Miembros del Disciplinas Gestión del

equipo del equipo equipo
Equipos Integrados
para el producto

Beneficios de PSP y TSP
Guiar al equipo en todo el proceso de desarrollo
El producto final incluye funcionalidades de valor agregado
Desarrollar actitudes para de trabajar en equipo
Tener un esquema de trabajo definido
Promover la integración del equipo
Mejorar la estimaciones de tiempo de desarrollo
Proporciona plantillas y estándares para dar seguimiento a procesos

EXPLICACION DEL TRABAJO Escuela Superior Politécnica del Litoral
Aplicación en el proyecto
Los roles distribuyen la gestión entre

TSP los ingenieros.
TEAM SOFTWARE PROCESS
Adm. De Configuración
Definición de responsabilidades para
Adm. De Planificación
Adm. De Desarrollo
Adm. De Calidad
Líder de Equipo
gestionar el entorno de trabajo.
Los planes del equipo e individuales

son la base para un adecuado
seguimiento
PSP Personal Software Process
Los administradores participan en:
Planificación Procesos Calidad GUI Diseño
Desarrollo Pruebas

Roles y Responsabilidades
Objetivo del Rol Responsabilidades
Conducir al equipo en la •Dirigir en el desarrollo.

definición, diseño, •Dar soporte en desarrollo.
desarrollo Adm. De Desarrollo •Verificar código fuente.
y pruebas del producto. •Conducir generación de
documentación técnica.
•Mantener el programa de trabajo.
Apoyar y guiar a los integrantes
•Verificar el cumplimiento.
del equipo en la planificación y
Adm. De Planificación •Controlar el registro de horas.
seguimiento de su trabajo.
•Comparar el progreso del equipo.
Determinación, obtención y •Controlar cambios.

mantenimiento de las herramientas •Definir herramientas de desarrollo.
necesarias para cumplir con las Adm. De Configuración •Evaluar las solicitudes de cambios.
necesidades administrativas. •Administración de riesgos.
Factores tomados en cuenta para la distribución de roles:
Conocimientos de métodos de diseño No ser resistente al cambio
Gusto en construir cosas Seguir un esquema de trabajo definido
Conocimientos de herramientas de apoyo Monitorear actividades definidas

Etapas definidas del proyecto

Dedicación Implicaciones
Menor Etapa general para el desarrollo

del proyecto
Proceso de negocios no definidos
Mayor Frecuencia de cambio de los
requerimientos
Alcance de los módulos no definido.
Mayor Tamaño de unidades a probar

Pruebas de cambios realizados
Productos desarrollados:
Módulo de Control de Inventario y Bodega Módulo de Presupuesto por Obra

MCIB MPO
Módulo de Órdenes de Trabajo Módulo de Costos de Producción

MOT MCP

…las métricas son escalas de unidades sobre las cuales puede medirse un
atributo cuantificable. Cuando se habla de software nos referimos a la disciplina
de recoger y analizar datos basándonos en mediciones reales de software, así
como a las escalas de medición…
Métricas definidas:
Administrador de Desarrollo
Longitud de Código Número de veces que se dio soporte
Reutilización de código
Administrador de Planificación
Horas de equipo trabajadas H. trabajadas vs H. planificadas por rol
Administrador de Configuración
Número de cambios en requerimientos Eficiencia en realizar cambios
Número de versiones en los ECS

Longitud de código
TIPO DE TOTAL
MCIB MCP MOT MPO MNO MFAC MOC
FUENTE GENERAL
Clases 2806 774 1790 1688 1633 981 877 10549
Módulos 273 273 273 273 273 273 273 1911
Formularios 28800 3970 9795 12470 7215 5378 3900 71528
Stored Proc. 6156 961 1465 1630 5828 1176 1311 18527
TOTAL
38035 5978 13323 16061 14949 7808 6361 102515
GENERAL
Implicaciones Factores de mejora
Complejidad en mantenimiento. Uso de estándares

Comunicación entre Definición y utilización de
desarrolladores. componentes.
Definición de los componentes.

Reutilización de código
MÓDULO LOC REUTILIZADAS LOC AHORRADAS
MCIB 3170 255590
MCP 1729 45033
MOT 3170 89613
MPO 2628 129747
MNO 1205 73190
MOC 1187 33258
MFAC 1187 40850
TOTAL LOCS 14276 667281
Componentes no establecidos Definición de componentes

inicialmente reutilizados en los siguientes
módulos.
Disminución en tiempos de
programación.

Número de veces que se dio soporte

%SOPORTE EN MODULOS DESARROLLADOS
% SOPORTE POR TIPO DE

60.0% 53.4%
PROBLEMAS
17,24%
40.0%
25.9%
20.0% 13.8% 51,72%

5.2% 31,03%
1.7%
0.0% Diseño Errores Programación
MNO MCIB MOC MOT MFAC
Los miembros del equipo no Los desarrolladores ganan

conocían las herramientas de experiencia con el tiempo
desarrollo.
Experiencia en proyectos reales

Horas de equipo trabajadas

Implicaciones
DESFASE DE HORAS TRABAJADAS
Falta de experiencia en la
1200 60,00%
55,56% Planificado planificación.
1000 50,00%
Trabajado Cambios del proceso del
800 Desfase 40,00% negocio.
600 30,00% Definición de objetivos
23,58%
400 20,00% generales y no específicos .
200 4,63% 3,48% 0,69%10,00% Adaptación en la metodología
0 0,00% de desarrollo.
Sem 0-20Sem 20-28Sem 28-36Sem 36-52 Sem 52- Estimación excesivamente
optimista de las tareas.
Factores de mejora Planificado Trabajado Desfase
Sem 0-20 646,8 1006,15 55,56%
Estrategias de planificación por
incrementos. Sem 20-28 373,7 461,8 23,58%
Procesos definidos. Sem 28-36 118,9 124,4 4,63%
Integración del equipo. Sem 36-52 342 353,9 3,48%

Comunicación del usuario Sem 52- 115,6 116,4 0,69%

Evaluación
H. Planificadas vs H. trabajadas por rol
de métricas
Implicaciones
Carga de trabajo
desbalanceado.
Falta de experiencia de
herramientas
Factores de mejora ROL HP HT Desfase
Líder Equipo 391.3 538.1 37.5%

Conocimiento de la herramientas
Adm. Desarrollo 375 509 35.7%
Distribución adecuada de tareas.
Adm. Planificación 261.8 314.1 20.1%
Administradores ganaron experiencia
Adm. Calidad 256.2 312.2 21.8 %
en el proceso de desarrollo
Adm. Configuración 312.8 364.55 17.44%
Definición de metas alcanzables
Evaluación
Número de cambios en requerimientos
de métricas
NUMEROS DE CAMBIOS EN
Implicaciones
REQUERIMIENTOS
12
11
10 Cambios en el proceso de
10 negocio.
7 6 7 7
8
4
Poco tiempo en análisis de
6
4
requerimientos.
2 No se tomo en cuenta las
0
M OD U L OS D ES1A R R OL L A D OS
dependencias de los módulos
analizados.
MNO MCIB MOT MOC MPO MFAC MCP
Factores de mejora
Procesos del negocio definido

Identificación de dependencias con otros
módulos.

Eficiencia en realizar cambios

HORAS % Porcentaje
Implicaciones
12 20,00%
17,52%
16,34% 18,00% Tamaño del cambio.
10 15,00% 15,50%
16,00%
14,07% Tardanza en realizar los
8 14,00%
10,95% 10,61% 12,00% cambios.
6 10,00% Sobreestimación del impacto
8,00%
4 6,00% que genera los cambios
2 4,00% No se tomó en cuenta las
2,00%
0 0,00% dependencias de los módulos
MNO MCIB MOT MOC MPO MFAC MCP analizados
DEDICACION EN PROCESO DE CAMBIO

Factores de mejora
2,78%
42,46%
Aplicación de procesos de gestión
de cambios.
Seguimiento de cambios efectuados. 54,76%
Experiencia en el proceso de cambio. EVALUACION IMPLEMENTACION

REVISION

Número de versiones de los ECS

NUM. DE VERSIONES DE ECS POR Implicaciones

MODULO
No se tomó en cuenta
DESARROLLO PRODUCCION TOTAL
30 las dependencias de
25 25 los módulos
22
20 analizados.
17 16 17 Cambios en el proceso
15
13
10 10 de negocios.
5
0
MNO MCIB MOT MOC MPO MFAC MCP
Factores de mejora
Verificación de versiones de los ECS

Seguimiento de cambios efectuados.
Identificación de dependencia con
otros módulos ECS – Elementos de configuración

ANALISIS DE LA METODOLOGIA Escuela Superior Politécnica del Litoral
Antes y después de TSP

Antes Después
No se aplicaban estándares Planificación adecuado del

proyecto
Trabajos descoordinados en
TSP
el proceso de desarrollo de TEAM SOFTWARE
Uso de métricas.
Software PROCESS
Desarrollo de habilidades
Adm. De Configuración
No había registro de del equipo
Adm. De Planificación
Adm. De Desarrollo
Adm. De Calidad
Líder de Equipo
pruebas
Definición y uso de
Documentación pobre estándares en el proceso
de software
Distribución de trabajo
inadecuado El equipo adopta disciplina
de desarrollo
PSP Personal Software Process
PROY.
CON TSP
Desfase promedio en la
6%
Programación del trabajo
Rango aceptable de errores
-20% a
en la programación del
27%
trabajo

ANALISIS DE LA METODOLOGIA Escuela Superior Politécnica del Litoral
Factores de mejoramiento
PSP TSP
Planificación Tareas
Disciplina Individual Disciplina Colectiva
Cumplimiento - Compromisos
Predicción de Trabajo Segregación de Funciones
Revisiones Indicadores / Métricas Organización Estructural
Aumento del Desempeño Trabajo del equipo dirigidos a

Individual producir un producto

CONCLUSIONES Y RECOMEND. Escuela Superior Politécnica del Litoral
Conclusiones
Contribuyó a que el grupo tenga a una mejor comprensión de sus responsabilidades en los procesos
El trabajo centralizado se acopla de mejor manera a estas metodologías
El factor recurso humano es importante para esta metodología
El trabajo ordenado se intensifica con el uso de la metodología
La comunicación es importante entre los miembros del equipo
El trabajo entre las personas del negocio y los desarrolladores debe ser continuo
Debe de haber una buena inducción de la metodología antes de aplicarla
La cultura latinoamericana le cuesta mas adaptarse a disciplinas de desarrollo formales
En nuestra tesis el TSP tomo tiempo acoplarse ya que inicialmente se llevo los métodos y técnicas
personales de cada miembro del equipo pero con el transcurso del tiempo se fue
obteniendo una disciplina de desarrollo y un ambiente de equipo

CONCLUSIONES Y RECOMEND. Escuela Superior Politécnica del Litoral
Recomendaciones para proyectos futuros
Adoptar esta u otras metodologías que ayuden a producir software de calidad
Considerar estas metodologías en el plan de enseñanzas para futuros ingenieros
Fomentar el uso de métricas para mediciones del desempeño individual y en equipo
Adoptar estándares
Desarrollar planes que ayuden al equipo a cumplir objetivos
Definir y dar seguimientos a objetivos específicos y alcanzables
Tener documentación necesario en el desarrollo del software

VISTA DEL SISTEMA Escuela Superior Politécnica del Litoral
INTERACCION DEL SISTEMA

VISTA DEL SISTEMA Escuela Superior Politécnica del Litoral
MPO MOT
•Creación de Obras Generar OT

•Ingreso de Diarios de
•Ingresar Proformas
trabajo
•Modificar Proformas
•Cambiar Estado a las OT
•Aprobación de proformas.
Generar OT
Ing. costos maquinarias y

Ing. costos mano de obra
MCIB
équipos
•Clasificación de
suministros
•Ingreso de Movimientos
de bodega.
•Autorización de Vehículos MCP
•Ingreso de Pedidos
•Autorización de Pedidos Ing, costos de ordenes de viaje •Cons. Costos de mano
•Ingreso de Ordenes de Obra
Viaje •Cons Costos de suminis
•Control de herramientas. Ing, costos de materiales y consumibles tros
•Ingreso de carga personal •Costos proformados vs
costos reales

Que Es PSP yTSP

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Que Es PSP yTSP

Cargado por

Copyright:

Formatos disponibles

ESCUELA SUPERIOR

POLITECNICA DEL LITORAL

Implementación de un Sistema Integrado de Control de

Mauricio Echeverria - Denisse Echeverria - Jose Luis Asencio

Beneficios PSP y TSP

TSP y su aplicación en el proyecto

Etapas definidas del proyecto

Antes y Después de TSP

PSP Personal Software Process TSP Team Software Process

Importancia en el desarrollo del software en el Pais.

Existen inconvenientes en el desarrollo del software.

El uso de metodologías de desarrollo ayuda a adoptar

Personas + tecnología Producción heroica

Personas + procesos + tecnología Producción eficiente

PSP Personal Software Process TSP Team Software Process

Qué es PSP y TSP?

Procesos individuales definidos Proceso en equipo

Medición gradual del desempeño Mejora continua de desarrollo

Registro de tiempo Equipo eficiente y colaborador

Propuestas de mejoras al proceso Enfocado a cinco roles

Estimación de tamaño - tiempo Genera disciplina en equipo

Las metodologías implementadas son sugeridas por el Instituto de Ingeniería de

PSP Personal Software Process TSP Team Software Process

Relación entre PSP y TSP

Mediciones personales Objetivos del proyecto Análisis de riesgos

Disciplina en el proceso Roles en el equipo Comunicación del equipo

Estimación y planificación Proceso del equipo Coordinación del equipo

Gestión de la Calidad Plan del proyecto registro del estado

Miembros del Disciplinas Gestión del

PSP Personal Software Process TSP Team Software Process

Beneficios de PSP y TSP

Guiar al equipo en todo el proceso de desarrollo

El producto final incluye funcionalidades de valor agregado

Desarrollar actitudes para de trabajar en equipo

Tener un esquema de trabajo definido

Promover la integración del equipo

Mejorar la estimaciones de tiempo de desarrollo

Proporciona plantillas y estándares para dar seguimiento a procesos

PSP Personal Software Process TSP Team Software Process

Los roles distribuyen la gestión entre

gestionar el entorno de trabajo.

Los planes del equipo e individuales

Los administradores participan en:

Planificación Procesos Calidad GUI Diseño

PSP Personal Software Process TSP Team Software Process

Conducir al equipo en la •Dirigir en el desarrollo.

Determinación, obtención y •Controlar cambios.

Gusto en construir cosas Seguir un esquema de trabajo definido

Conocimientos de herramientas de apoyo Monitorear actividades definidas

PSP Personal Software Process TSP Team Software Process

Etapas definidas del proyecto

Menor Etapa general para el desarrollo

Mayor Tamaño de unidades a probar

Módulo de Control de Inventario y Bodega Módulo de Presupuesto por Obra

Módulo de Órdenes de Trabajo Módulo de Costos de Producción

PSP Personal Software Process TSP Team Software Process

Longitud de Código Número de veces que se dio soporte

Horas de equipo trabajadas H. trabajadas vs H. planificadas por rol

Número de cambios en requerimientos Eficiencia en realizar cambios

Número de versiones en los ECS

PSP Personal Software Process TSP Team Software Process

Implicaciones Factores de mejora

Complejidad en mantenimiento. Uso de estándares