escuela superior politecnica del litoral facultad de ingenieria electrica y computacion

ESCUELA SUPERIOR ESCUELA SUPERIOR POLITECNICA DEL LITORALPOLITECNICA DEL LITORAL

FACULTAD DE INGENIERIAFACULTAD DE INGENIERIAELECTRICA Y COMPUTACIONELECTRICA Y COMPUTACION

Implementación de un Sistema Integrado de Control de Implementación de un Sistema Integrado de Control de Costos de Producción, Órdenes de Trabajo, Presupuesto de Costos de Producción, Órdenes de Trabajo, Presupuesto de

Obras, Bodega y Control de Inventario utilizando PSP Obras, Bodega y Control de Inventario utilizando PSP ( Personal Software Process) y TSP ( Team Software ( Personal Software Process) y TSP ( Team Software

Process )Process )

TESIS DE GRADO

18/08/2006

Mauricio Echeverria - Denisse Echeverria - Jose Luis Asencio

PSP Personal Software Process TSP Team Software Process

Escuela Superior Politécnica del LitoralEscuela Superior Politécnica del LitoralA

G

E

N

D

AI N T R O D U C C I O N

E X P L I C A C I O N D E L T R A B A J O

A N A L I S I S D E L A M E T O D O L O G I A

C O N C L U S I O N E S Y R E C O M E N D A C I O N E S

Justificación.Justificación.Qué es PSP y TSP?Qué es PSP y TSP?Relación entre PSP y TSPRelación entre PSP y TSPBeneficios PSP y TSPBeneficios PSP y TSP

TSP y su aplicación en el proyectoTSP y su aplicación en el proyectoRoles y responsabilidadesRoles y responsabilidadesEtapas definidas del proyectoEtapas definidas del proyectoEvaluación de métricasEvaluación de métricas

Antes y Después de TSPAntes y Después de TSPFactores de mejoramientoFactores de mejoramiento


INTRODUCCIÓN Escuela Superior Politécnica del LitoralEscuela Superior Politécnica del Litoral

Hoy en díaHoy en día

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

Existen inconvenientes en el desarrollo del software.Existen inconvenientes en el desarrollo del software.Pocas empresas utilizan estándares y factores de medición en el Pocas empresas utilizan estándares y factores de medición en el desarrollo del softwaredesarrollo del software

Personas + tecnología Producción heroica

Personas + procesos + tecnología Producción eficiente

Gestión de Software

El uso de metodologías de desarrollo ayuda a adoptar esquemas de trabajo para cumplir los objetivos del equipo.



Qué es PSP y TSP?Qué es PSP y TSP?

Procesos individuales definidos

Medición gradual del desempeño

PSP

Registro de tiempo

Propuestas de mejoras al proceso

Estimación de tamaño - tiempo

TSP

Proceso en equipo

Mejora continua de desarrollo

Equipo eficiente y colaborador

Enfocado a cinco roles

Genera disciplina en equipo

Las metodologías implementadas son sugeridas por el Instituto de Ingeniería de Software (SEI)



Relación entre PSP y TSPRelación entre PSP y TSPPSP desarrolla

habilidades

Miembros delequipo

Disciplinasdel equipo

Gestión delequipo

Equipos Integradospara el producto

Mediciones personales

Disciplina en el proceso

Estimación y planificación

Gestión de la Calidad

Objetivos del proyecto

Roles en el equipo

Proceso del equipo

Plan del proyecto

Plan balanceado

Análisis de riesgos

Comunicación del equipo

Coordinación del equipo

registro del estado

Informes del proyecto

TSP enconstrucción

del equipo

TSP entrabajo en

equipo



Beneficios de PSP y TSPBeneficios de PSP y TSP

Guiar al equipo en todo el proceso de desarrollo

Desarrollar actitudes para de trabajar en equipo

El producto final incluye funcionalidades de valor agregado

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 LitoralEscuela Superior Politécnica del Litoral

PSP Personal Software Process

Líde

r de

Equ

ipo

Adm

. De

Calid

ad

Adm

. De

Des

arro

llo

Adm

. De

Plan

ifica

ción

Adm

. De

Conf

igur

ació

n

TSPTEAM SOFTWARE

PROCESS

Los roles distribuyen la gestión entre los ingenieros.

Definición de responsabilidades para gestionar el entorno de trabajo.

Los planes del equipo e individuales son la base para un adecuado seguimiento

Aplicación en el proyectoAplicación en el proyecto

Los administradores participan en:

Planificación Procesos Calidad GUI Diseño

Desarrollo Pruebas



Roles y ResponsabilidadesRoles y Responsabilidades

Conducir al equipo en la definición, diseño,

desarrollo y pruebas del producto.

Apoyar y guiar a los integrantes del equipo en la planificación y

seguimiento de su trabajo.

Determinación, obtención y mantenimiento de las herramientas

necesarias para cumplir con las necesidades administrativas.

Adm. De Desarrollo

Adm. De Configuración

Responsabilidades

•Dirigir en el desarrollo.•Dar soporte en desarrollo.•Verificar código fuente.•Conducir generación dedocumentación técnica.•Mantener el programa de trabajo.•Verificar el cumplimiento.•Controlar el registro de horas.•Comparar el progreso del equipo.

•Controlar cambios.•Definir herramientas de desarrollo.•Evaluar las solicitudes de cambios.•Administración de riesgos.

Adm. De Planificación

Objetivo del Rol

Factores tomados en cuenta para la distribución de roles:Conocimientos de métodos de diseño

Gusto en construir cosas

Conocimientos de herramientas de apoyo

No ser resistente al cambio

Seguir un esquema de trabajo definido

Monitorear actividades definidas



Etapas definidas del proyectoEtapas definidas del proyecto

Introducción Estrategia Lanzamiento Planificación

Requerimientos Diseño Implementación

Pruebas

Definición

Desarrollo

Producción

Mayor

Mayor

Menor

Etapa general para el desarrollo del proyecto

Proceso de negocios no definidosFrecuencia de cambio de los requerimientos Alcance de los módulos no definido.Tamaño de unidades a probarPruebas de cambios realizados

Productos desarrollados:

Módulo de Control de Inventario y BodegaMCIB

Módulo de Presupuesto por ObraMPO

Módulo de Órdenes de TrabajoMOT

Módulo de Costos de ProducciónMCP

Dedicación Implicaciones



Evaluación de métricas Evaluación de métricas …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:

Longitud de Código

Reutilización de código

Número de veces que se dio soporte

Administrador de Desarrollo

Número de cambios en requerimientos

Número de versiones en los ECS

Eficiencia en realizar cambios

Administrador de Configuración

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

Administrador de Planificación



Evaluación de métricas Evaluación de métricas Longitud de código

10251563617808149491606113323597838035TOTAL GENERAL

18527131111765828163014659616156Stored Proc.71528390053787215124709795397028800Formularios1911273273273273273273273Módulos

105498779811633168817907742806Clases

TOTAL GENERALMOCMFACMNOMPOMOTMCPMCIBTIPO DE

FUENTE

Implicaciones

Complejidad en mantenimiento.Comunicación entre desarrolladores.Definición de los componentes.

Factores de mejora

Uso de estándaresDefinición y utilización de componentes.



Reutilización de código Evaluación de métricas Evaluación de métricas

142761187118712052628317017293170

LOC REUTILIZADAS

667281TOTAL LOCS40850MFAC33258MOC73190MNO129747MPO89613MOT45033MCP255590MCIB

LOC AHORRADAS MÓDULO

Implicaciones Factores de mejora

Componentes no establecidos inicialmente

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



Número de veces que se dio soporte Evaluación de métricas Evaluación de métricas

% SOPORTE POR TIPO DE PROBLEMAS

17,24%

31,03%51,72%

Diseño Errores Programación

53.4%

25.9%13.8%

5.2% 1.7%

0.0%

20.0%

40.0%

60.0%

MNO MCIB MOC MOT MFAC

%SOPORTE EN MODULOS DESARROLLADOS

Implicaciones Factores de mejora

Los miembros del equipo no conocían las herramientas de desarrollo.Experiencia en proyectos reales

Los desarrolladores ganan experiencia con el tiempo



Horas de equipo trabajadas Evaluación de métricas Evaluación de métricas Implicaciones

Factores de mejora

Falta de experiencia en la planificación.Cambios del proceso del negocio.Definición de objetivos generales y no específicos .Adaptación en la metodología de desarrollo.Estimación excesivamente optimista de las tareas.

Estrategias de planificación por incrementos.Procesos definidos.Integración del equipo.Comunicación del usuario

DESFASE DE HORAS TRABAJADAS

55,56%

23,58%

4,63% 3,48% 0,69%

0

200

400

600

800

1000

1200

Sem 0-20Sem 20-28Sem 28-36Sem 36-52 Sem 52-0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%Planificado

Trabajado

Desfase

0,69%116,4115,6Sem 52-

3,48%353,9342Sem 36-52

4,63%124,4118,9Sem 28-36

23,58%461,8373,7Sem 20-28

55,56%1006,15646,8Sem 0-20

DesfaseTrabajadoPlanificado



H. Planificadas vs H. trabajadas por rolEvaluación de métricas Evaluación de métricas Gráfico Comparativo De Horas

Planificadas vs. Horas Trabajadas

A. D

es.

A. P

lan.

A. C

al.

A. C

onf.0

100200300400500600

0 2 4 6 Rol

Hor

as

Horas Planif icadasHoras Trabajadas

Implicaciones

Factores de mejora

Carga de trabajo desbalanceado.Falta de experiencia de herramientas

Conocimiento de la herramientasDistribución adecuada de tareas.Administradores ganaron experiencia en el proceso de desarrolloDefinición de metas alcanzables 17.44%364.55312.8Adm. Configuración

21.8 %312.2256.2Adm. Calidad

20.1%314.1261.8Adm. Planificación

35.7%509375Adm. Desarrollo

37.5%538.1391.3Líder Equipo

DesfaseHTHPROL



Número de cambios en requerimientosEvaluación de métricas Evaluación de métricas

Cambios en el proceso de negocio.Poco tiempo en análisis de requerimientos.No se tomo en cuenta las dependencias de los módulos analizados.

Procesos del negocio definidoIdentificación de dependencias con otros módulos.

Implicaciones

Factores de mejora

1110

7 6 7 74

02468

1012

1MODULOS DESARROLLADOS

NUMEROS DE CAMBIOS EN REQUERIMIENTOS

MNO MCIB MOT MOC MPO MFAC MCP



Eficiencia en realizar cambios Evaluación de métricas Evaluación de métricas

DEDICACION EN PROCESO DE CAMBIO

2,78%

54,76%

42,46%

EVALUACION IMPLEMENTACION

REVISION

17,52%16,34%

14,07% 15,00%

10,95%

15,50%

10,61%

0

2

4

6

8

10

12

MNO MCIB MOT MOC MPO MFAC MCP0,00%2,00%4,00%6,00%8,00%10,00%12,00%14,00%16,00%18,00%20,00%

HORAS % Porcentaje

Tamaño del cambio.Tardanza en realizar los cambios.Sobreestimación del impacto que genera los cambiosNo se tomó en cuenta las dependencias de los módulos analizados

Aplicación de procesos de gestión de cambios.Seguimiento de cambios efectuados.Experiencia en el proceso de cambio.

Implicaciones

Factores de mejora



Número de versiones de los ECS Evaluación de métricas Evaluación de métricas

NUM. DE VERSIONES DE ECS POR MODULO

2225

17 1613

17

10

0

5

10

15

20

25

30

MNO MCIB MOT MOC MPO MFAC MCP

DESARROLLO PRODUCCION TOTAL

Implicaciones

Factores de mejora

No se tomó en cuenta las dependencias de los módulos analizados.Cambios en el proceso de negocios.

Verificación de versiones de los ECSSeguimiento 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 LitoralEscuela Superior Politécnica del Litoral

Antes y después de TSP Antes y después de TSP

PSP Personal Software Process

Líde

r de

Equ

ipo

Adm

. De

Des

arro

llo

Adm

. De

Calid

ad

Adm

. De

Plan

ifica

ción

Adm

. De

Conf

igur

ació

n

TSPTEAM SOFTWARE

PROCESS

Antes Después

No se aplicaban estándares

Trabajos descoordinados enel proceso de desarrollo de Software

No había registro de pruebas

Documentación pobre

Distribución de trabajo inadecuado

Planificación adecuado del proyecto

Uso de métricas.

Desarrollo de habilidades del equipo

Definición y uso de estándares en el proceso de software

El equipo adopta disciplina de desarrollo

-20% a 27%

Rango aceptable de erroresen la programación del trabajo

6%Desfase promedio en la Programación del trabajo

PROY.

CON TSP


ANALISIS DE LA METODOLOGIA Escuela Superior Politécnica del LitoralEscuela Superior Politécnica del Litoral

PSP TSP

Disciplina Individual Disciplina Colectiva

Segregación de Funciones

Planificación Tareas

Cumplimiento - CompromisosPredicción de Trabajo

Revisiones Organización EstructuralIndicadores / Métricas

Aumento del Desempeño Individual

Trabajo del equipo dirigidos aproducir un producto

Factores de mejoramiento Factores de mejoramiento


CONCLUSIONES Y RECOMEND. Escuela Superior Politécnica del LitoralEscuela Superior Politécnica del Litoral

ConclusionesConclusiones

Contribuyó a que el grupo tenga a una mejor comprensión de sus responsabilidades en los procesos

Debe de haber una buena inducción de la metodología antes de aplicarla

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

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 LitoralEscuela Superior Politécnica del Litoral

Recomendaciones para proyectos futurosRecomendaciones 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 LitoralEscuela Superior Politécnica del Litoral

INTERACCION DEL SISTEMA INTERACCION DEL SISTEMA


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

MPO

•Creación de Obras•Ingresar Proformas•Modificar Proformas•Aprobación de proformas.

•Ingreso de Diarios de trabajo•Cambiar Estado a las OT

MOT

Generar OT

•Cons. Costos de mano Obra•Cons Costos de suminis tros•Costos proformados vs costos reales

MCP

Ing.

cos

tos

man

o de

obr

a

Ing.

cos

tos

maq

uina

rias

y éq

uipo

s

•Clasificación de suministros •Ingreso de Movimientos de bodega.•Autorización de Vehículos•Ingreso de Pedidos•Autorización de Pedidos•Ingreso de Ordenes de Viaje•Control de herramientas.•Ingreso de carga personal

MCIB

Ing, costos de materiales y consumibles

Ing, costos de ordenes de viaje

Generar O

T

escuela superior politecnica del litoral facultad de ingenieria electrica y computacion

Documents

i s i s d

n d ai n t r

tspbeneficios psp

software sei relacin

j oa n

rdenes de trabajo

entorno de trabajo

esquemas de trabajo