0% encontró este documento útil (0 votos)
13 vistas17 páginas

Proceso de Software Personal (PSP)

El documento describe el Personal Software Process (PSP) y el Team Software Process (TSP). PSP se enfoca en mejorar los procesos de desarrollo de software a nivel individual mediante métricas, planeación y seguimiento. TSP extiende este enfoque a nivel de equipo para optimizar la interacción entre ellos. Ambos forman parte de una metodología más amplia para mejorar continuamente los procesos de software a nivel organizacional.

Cargado por

cristiandrl
Derechos de autor
© Attribution Non-Commercial (BY-NC)
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
13 vistas17 páginas

Proceso de Software Personal (PSP)

El documento describe el Personal Software Process (PSP) y el Team Software Process (TSP). PSP se enfoca en mejorar los procesos de desarrollo de software a nivel individual mediante métricas, planeación y seguimiento. TSP extiende este enfoque a nivel de equipo para optimizar la interacción entre ellos. Ambos forman parte de una metodología más amplia para mejorar continuamente los procesos de software a nivel organizacional.

Cargado por

cristiandrl
Derechos de autor
© Attribution Non-Commercial (BY-NC)
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd

PSP

PERSONAL SOFTWARE PROCESS

ANTECEDENTES

PSP, es uno de los 3 vértices donde descansa un proceso de mejora que trabaja sobre 3 niveles
de la organización, los otros 2 son CMM y TSP

CMM se enfoca a nivel organizacional


TSP se enfoca a un proceso de grupos de trabajo
PSP se enfoca a nivel personal
"PSP cubre 12 de los 18 KPA’s (áreas claves de procesos del CMM) y materializa lo que han
querido decir CMM, ISO 9000 y SQA (software quality assurance)"
David F. Rico

ANTECEDENTES, justificación

Los ingenieros de software rara vez basan su trabajo en prácticas y metodologías establecidas y
son prácticamnete excépticos a cambiar sus hábitos de trabajo.

Los ingenieros estan en un círculo vicioso, "sólo creen en lo que han probado y no prueban otras
metodologías", por esta rezón para poder implantar PSP, se tuvo que obligarlos y se tuvieron
buenos resultados.

PASOS PARA IMPLANTACION PSP

1. Los ingenieros deben ser entrenados por un instructor calificado de PSP.


2. La Capacitacion es sobre grupos o equipos, y seran grupos que asi lo han sido y
seguiran siendo.
3. Requiere un fuerte soporte de administración, en este sentido es necesario que los
administradores entiendan el PSP, saber como apoyarlos y como monitorear sus
avances, sin un adecuado monitoreo los ingenieros caeran otra vez en los malos
habitos.
4. Después de ser bien entrenados y bien administrados lo que sigue es optimizar la
interaccion entre equipos y aquí entraría Team Software Process, el TSP extiende y
refina los metodos de CMM y PSP sobre desarrollo y mantenimiento de equipos, y llegar
a lo que se le llama un equipo autodirigido.

PSP, ¿ QUE ES ?

Es un ciclo de vida del proceso de software que se caracteriza por:

 Ser definido, conciso


 Altamente prescriptivo
 Rápido y barato (?)

CAPACITACION PSP, ¿ BARATA ?

SEMINARIO P’ EJECUTIVOS 4,498


INGENIEROS I 9,046
INGENIEROS II 9,046
CAPACIT. INSTRUCTORES 14,046
ADMON INGENIEROS 7,587
TOTAL dlls 44,223

BASES DE PSP

PSP combina:

 Admón. de proyectos
 Admón. de calidad
 Ingeniería de software
 Empowerment (delegación exitosa)

DESGLOSANDO PSP

 Metodología planeación de proyectos


 Metodología planeación de calidad
 Conjunto de formas y templates
 Capacitación completa
 Métricas y modelos cuantitativos
 Libretos procedimientos, paso-a-paso
 Ciclo de vida integrado de punta a punta

Lo conciso y prescriptivo de PSP esta basado en:

7 SCRIPTS
2 SUMARIOS E INSTRUCCIONES
3 LOGS
3 STANDARES
8 TEMPLATES
2 CHECKLISTS

76 FORMAS C10-C86, RESPALDAN ESTOS DOCUMENTOS EN 7 NIVELES DE PSP

DESGLOSANDO PSP, PRECISION


El Empowerment de PSP esta basado en

 La responsabilidad y autonomía a los ingenieros


 La experiencia de décadas
 Modelo para la optimización individual

CICLO DE VIDA SW, PSP

Ciclo de vida tradicional:

ANALISIS DISEÑO CODIFICACION PRUEBAS


Ciclo de vida PSP:

planeación Diseño alto nivel Revisión alto nivel Desarrollo PostMortem

7 niveles del PSP docto/seg


PSP3
37
Proceso Personal Cíclico
PSP2 y PSP2.1
58
Manejo Personal de calidad
PSP1 y PSP1.1
42
Proceso Personal de Planeación
PSP0 y PSP0.1
25
Línea Base del PSP

PSP 0

Identificar actividades: definición, secuencia

Bases mejoras: planeación, evaluación, resultados


Documentar proceso:

         Formas de:
   Actividades (Scripts)
   Tiempos (Logs Time)
   Defectos (Defect Logs)
   Resumir planes, resultados (Proyect plan summary)

PSP 0.1

Registrar tamaño del producto y hacer un histórico:

 Lineas de código
 Function points
 Estandarización de la codificación

Registrar problemas y mejoras de propuestas

PSP 1

Mejora la planeación:

 Con la estimación tamaño del producto (historico)


 Decidir en base a reportes de pruebas

PSP 1.1

Mejora la planeación:

 Con la estimación de recursos


 Introducción de calendarizar, plasmar el plan con números, un presupuesto.

PSP 2

Mejora la ejecución:

 Detección temprana de defectos, en base a la predicción de estos.


 Revisiones de diseño
 Revisiones de código
 Uso de checklists (Listas de verificación)

PSP 2.1
Mejora el diseño:

 Al hacer uso de formas detalladas de diseño (formas C76, C77)

PSP 3

Mejora el ciclo, mejora del proceso en términos de hacerlo repetible (ciclico):

 Para aplicación a programas de mayor tamaño


 Registro del seguimiento de asuntos importantes
 Análisis del resumen de la planeación, tiempos, tamaños y defectos por cada ciclo

Especificación

Requisitos y Planeación

Diseño de Alto Nivel

Revisión del Diseño de Alto Nivel

Desarrollo Cíclico (Análisis Ciclo)

  Especificación el ciclo
  Diseño detallado y su revisión
  Definición de pruebas y su revisión
  Implementación y Revisión de Código
  Compilación
  Pruebas
  Evaluación

PostMortem

Integración
Pruebas de Sistema
Uso

Producto

CICLO DE VIDA PSP, FASES

Requisitos
Planeación

Diseño de alto nivel


Revisión de alto nivel del diseño

Desarrollo cliclico

Post Mortem

Integración

Pruebas
Producto

CICLO DE VIDA PSP,


FASE REQUISITOS

REQUISITOS

 Descripción del problema


 Especificación de componentes
 Formas de proceso
 Estimadores del tamaño del producto y tiempos en base a historicos

CICLO DE VIDA PSP,


FASE PLANEACIÓN (PLAN DE PROYECTO)

INPUT Descripción del problema, resumen del proyecto, resumen cíclico, tamaño estimado,
tiempo estimado, formas de planeación.
ACTIVIDAD Requerimientos, tamaño estimado, desarrollo estrategia, estimados de recursos,
planificación y programas de tareas, estimación de defectos.
OUTPUT Diseño conceptual, resumen plan, resumen del ciclo, patrones de estimados de
tamaño y planeación de tareas, programas de patrones de planeación, registro de
tiempos.

CICLO DE VIDA PSP,


FASE DISEÑO DE PRODUCTO

INPUT Tipificación requerimientos, diseño conceptual, patrones de estimaciones de


tamaño, resumen parte ciclico, seguimiento
ACTIVIDAD Especificaciones externas, diseño modular, prototipos, estrategia de desarrollo y
documentación, seguimiento
OUTPUT Diseño de programa, escenarios operacionales, especificación de funciones y lógica,
resumen cíclico, seguimiento y estrategias de pruebas y ciclo
CICLO DE VIDA PSP,
FASE REVISIÓN O VALIDACIÓN DEL DISEÑO

INPUT Programa de diseño, escenarios operacionales, especificación de funciones y lógica,


resumen ciclico, seguimiento y estrategia de pruebas y ciclo.
ACTIVIDAD Diseño de apariencia, verificación de máquinas y lógica, consistencia del diseño,
reuso, estrategia de verificación, detectar errores.
OUTPUT Fiseño de alto nivel, registro de seguimiento, tiempos y defectos.

CICLO DE VIDA PSP,


FASE DESARROLLO O IMPLEMENTACIÓN

INPUT Diseño de alto nivel, registro de seguimiento, tiempos y defectos, ciclo de


desarrollo, estrategia de pruebas, patrones de operación y función.
ACTIVIDAD Diseño de módulos, revisión de diseño, código, revisión de código, compilación,
pruebas, aseguramiento de calidad y del ciclo.
OUTPUT Modulos de sw, patrón de diseño, lista de verificación de código y diseño, resumen
del ciclo, patrón de reporte de pruebas, registro de tiempo, defectos y seguimiento.

CICLO DE VIDA PSP,


FASE POSMORTEM, EVALUACIÓN CICLO

INPUT Definición de problema y requerimientos, plan de proyecto y de ciclo, producto de


software, patrón de diseño, lista de verificación de código y diseño, resumen del
ciclo, patrón de reporte de pruebas, registro de tiempo, defectos y seguimiento.
ACTIVIDAD Defectos previstos, removidos, tamaño, tiempo del producto.
OUTPUT Producto, listas de verificación, plan de proyecto y ciclo, patrón de reporte de
pruebas y diseño, forma con propuesta de mejora, registro seguimiento pruebas y
tiempo.

Team Software Process


(TSP)

Abstract
Se describirá el TSP, cómo y para quién fue desarrollado, su estructura, una breve explicación
de la metodología, resultados de una aplicación real y la versión educativa (TSPi).

¿Qué es el TSP?

Es una metodología para dirigir el trabajo de mejora y desarrollo de software además de


establecer un entorno donde el trabajo efectivo de equipo sea normal y natural

ENTORNOS

ANTECEDENTES

TSP PROSIGUE LAS ESTRATEGIAS DE CALIDAD AMERICANAS QUE INICIO:

DEMMING EN LA INDUSTRIA EN 1982,


FAGAN EN EL PROCESO DE SW 1986,
W. HUMPHREY SW, CMM 1987,
W. HUMPHREY SW, PSP 1995,
W. HUMPHREY SW, TSP 1999.

ESTRUCTURA DE TSP

Planes personales Compromiso Prioridad en calidad


Método planeación Planes agresivos Costo de calidad
Valor agregado Calidad propia Seguir el proceso
Métricas calidad Objetivos proyecto Revisión de status y calidad
Procesos definidos Plan propio Comunicación
Plan detallado
Roles
Recursos de equipo
Objetivos del TSP

 Generar un marco basado en PSP


 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.
 Resumen:

Maximizar calidad SW
Minimizar costos

Antecedentes de trabajo en equipo

Cuando fracasa un proyecto de software es, en la mayoría de los casos, por un problema de
equipo y no por problemas técnicos.

Problemas comunes de Equipos

 Falta de liderazgo
 Falta de compromiso y ganas de cooperar
 Diferencia en contribuciones
 Falta de confianza
 Falta de calidad
 Mejoras excesivas
 Revisiones entre colegas inefectivas

Metodología TSP

Lanzamiento
Requerimientos
Diseño high level
Implementación
Integración y pruebas

Lanzamiento TSP, checklist para planeacion

1. Establecer productos y objetivos de empresa


2. Establecer roles y objetivos de equipo
3. Definir estrategía de desarrollo
4. Hacer un plan general
5. Hacer un plan de calidad
6. Balancear el plan (cargas de trabajo)
7. Proyecto de riesgos
8. Diseñar reporte para administración
9. Revision del plan con administración
10. Analisis Postmortem, nuevo equipo revisa proceso

Lanzamiento TSP, Plan de reuniones

Programa de reuniones

Los puntos 1,2,3 seran en el día 1

Los puntos 4,5,6 seran en el día 2

Los puntos 7,8 seran en el día 3

El punto 9 y el analisis postmortem seran en el dia 4 o bien al final del dia 3

Productos planeacion para lanzamiento TSP

 Objetivos de equipo por escrito


 Roles definidos
 Plan de desarrollo
 Plan de calidad
 Plan de soporte al proyecto
 Desarrollo en conjunto de planes y programas
 Plan detallado para cada ingeniero
 Plan contra riesgos
 Reporte del estado del proyecto

Producto esperado como equipo de trabajo

Los miembros establecen metas comunes y roles definidos

Equipo desarrolla estrategia consensada y todos participan en su creación


El equipo negocia el plan con la Administración

Los miembros hacen el trabajo en la forma planeada

La comunicación es libre y frecuente

Se forma grupo con cohesión, hay cooperación

Cada miembro conoce su status, se realimenta con su trabajo y tiene liderazgo que sustenta su
motivación

Lanzamiento del plan del equipo TSP

Una vez lanzado el plan lo mas importante es que los miembros sigan el plan

Liderear el equipo (guiar,motivar,disciplinar)

Seguimiento de problemas

Comunicación

Reporte administrativo

Mantener plan, seguimiento avance

Equilibrar cargas de trabajo

Manejo de la calidad

Plan de calidad

Identificar problemas de calidad

Encontrar prevenir problemas de calidad

Plan de la calidad

Se enfatiza en la administración de defectos.

Se basa en los estimados de tamaño e historicos, y estimaran los defectos en cada fase, sino
hay historico se basaran en la tabla 3.

Manejo de la calidad

Ejemplo Plan de Calidad


Nombre: x Proyecto: xx parte: xxy
Defectos Plan Actual
Compilación 140 220
En producto 7 21
Revisión código  23 52

Grafica PDF, Porcentaje de Defectos Encontrados

DATOS TIPICOS SIN TSP

DATOS TIPICOS UTILIZANDO TSP


Encontrando y Previniendo Problemas

Las Métricas de TSP indican problemas de calidad antes de la primera compilacion, las acciones
remediales son:

 Monitoree el modulo durante las pruebas y corrija


 Reinspeccione el modulo antes de la integracion y pruebas
 Que el programador retrabaje el modulo o corrija
 Redesarrolle el modulo

Resultados de una aplicación practica, Hill Air Base Force,


Utah

El miedo fue a los altos costos por la planeacion excesiva, entrevistas personales, levantamiento
de informacion pero esto mismo (TSP) reduce las mejoras al plan y el tiempo de pruebas al
grado de sostener que "la calidad es gratis".

Quizás el cambio mas grande fue la relacion administracion e ingenieros, mejoróy asi sera
siempre que la administración crea que los ingenieros trabajan efectivamente.

Además de la confianza entre administración e ingenieros, deben seguirse metodos confiables y


apropiados, reportando constantemente a administración.

Administración deberá entender que los ingenieros saben mas del software y que se ocuparan
solamente de que el equipo de software siga el método disciplinadamente.

Numeros:

Productividad aumento un 123%

Tiempo de prueba redujo de 22% a 2.7%

Cíclo de vida de TSP (TSPi)

 Es una serie de ciclos que inician con la declaración de las necesidades del producto y
terminan con la entrega del producto final
 A continuación presentaremos una representación gráfica con diagramas de actividades
de TSP en su versión educativa conocida como TSPi.

Cíclo de TSPi dividido en fases

 Lanzamiento
 Estrategia
 Planeación
 Requerimientos
 Diseño
 Implementación
 Prueba
 Postmortem

Experiencia, AMCIS

 Lo mejor: definición de roles y sus actividades, desarrollo incremental en varios ciclos.


 Lo más difícil: planeación y recaudación de métricas. Cumplimiento de compromisos.

Bienvenid@

Bienvenid@ a este espacio donde hablaremos de la metodologia TSP y en donde podras


dar tus criticas y opiniones.
Publicado por Jesus Samuel en 14:31 0 comentarios

Introduccion

Las estrategias comienzan con el empleo de evaluaciones a continuación


podemos ver como una metodología como es el TSP primero es dirigido sobre
varios pequeños proyectos para evaluar tanto acercamiento de transición
como el impacto de TSP sobre la organización. Los encargados de guiar
también construyen el entendimiento, el patrocinio, y apoyan en lo necesario
para la amplia aceptación del TSP en la organización.
Publicado por Jesus Samuel en 14:30 0 comentarios

Desarrollo

Team Software Process (TSP)


Es una metodología para dirigir el trabajo de mejora y desarrollo de software
además de establecer un entorno donde el trabajo efectivo de equipo sea
normal y natural. Ayuda a conformar equipos para el desarrollo de software
de calidad.

TSP proporciona un marco de trabajo que se construye sobre la base PSP con
bases de desarrollo bien definidas en las que los productos de software se
generan en varios ciclos y así se establecen medidas estándares para la
calidad del producto y para el desempeño de los equipos y los desarrolladores.

El TSP tiene dos componentes primarios: un componente que construye


equipo y un funcionamiento de equipo o componente de dirección. El
componente que construye equipo del TSP es el lanzamiento de TSP, que pone
el equipo en la situación provocativa de desarrollar su plan.

El TSP usa las mismas medidas básicas del PSP- tamaño, tiempo, y defectos - y
añade fechas de terminación de tarea. Para todas las medidas, datos
planificados y reales son recogidos en el nivel individual. El marco de medida
TSP consolida datos individuales en una perspectiva de equipo.
Los datos son analizados semanalmente por el equipo para entender el estado
de proyecto contra objetivos de calidad. El marco de medida TSP también
hace disponible otros puntos de vista de los datos, como por el producto o la
parte, la fase, la tarea, la semana, el día, etc. El personal y datos de equipo
son archivados para proporcionar un depósito de datos históricos para el
futuro empleo.

En un entorno donde el entendimiento es un factor fundamental para ser


competitivo, las empresas tienen que superar todo tipo de barreras culturales
para poder expandir con éxito sus actividades comerciales a escala mundial,
observemos la siguiente figura:

Vemos tres entornos, PSP es una alternativa dirigida a los ingenieros de


sistemas, que les permite mejorar la forma en la que construyen software.
Considerando aspectos como la planeación, calidad, estimación de costos y
productividad. Gran parte de las tareas y actividades definidas en los scripts
generará en su realización un conjunto de datos, fundamentalmente de
carácter estadístico.

La aplicación de PSP en varios procesos de desarrollo, y el análisis de la


información, estadística generada en cada uno de éstos, permitirán al
ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y
crecer a través de un proceso de autoaprendizaje y auto mejora.

La calidad en PSP, es un aspecto fuertemente relacionado con la cantidad de


defectos que el producto de software contiene. En este nivel se introducen
algunos métodos aplicables al proceso de desarrollo de software, dentro de un
enfoque de proyectos a gran escala, pero sin lidiar con problemas de
comunicación y coordinación de los equipos de trabajo. PSP provee
lineamientos específicos sobre cómo los desarrolladores de software pueden
continuamente mejorar su desempeño, basados en una práctica estándar para
desarrollar software. TSP provee los lineamientos específicos acerca de cómo
los desarrolladores entrenados en PSP pueden trabajar efectivamente como
integrantes de un equipo de alto desempeño.
Otro entorno es el CMM e n la administración para Software que luego
evolucionó a CMMI. Hoy en día CMMI es un conjunto de productos y servicios
de mejora de procesos compuestos por modelos de referencia, material de
entrenamiento y métodos de evaluación en la administración. Estos productos
contienen prácticas que han demostrado ser efectivas y vienen ayudando a
mejorar por más de veinte años a organizaciones en todo el mundo.

ESTRUCTURA DE TSP
PSP: Planes personales, Método, planeación, Valor agregado, Métricas
calidad, Procesos definidos.
TSP Creación de Equipo: Compromiso, Planes agresivos, Calidad propia,
Objetivos proyecto.
TSP Trabajo en equipo: Prioridad en calidad, Costo de calidad, Seguir el
proceso, Revisión de status y calidad.

Objetivos del TSP.


* Generar un marco basado en PSP
* 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.
* Resumen: Maximizar calidad SW, Minimizar costos.

Cíclo de vida de TSP (TSPi).


Es una serie de ciclos que inician con la declaración de las necesidades del
producto y terminan con la entrega del producto final.

Cíclo de TSPi dividido en fases:


* Lanzamiento
* Estrategia
* Planeación
* Requerimientos
* Diseño
* Implementación
* Prueba
* Postmortem
Publicado por Jesus Samuel en 14:29 5 comentarios

Conclusion

TSP describe el uso y las experiencias que ilustran las ventajas de tres
perspectivas. De primera forma tenemos una perspectiva nueva de proyecto.
Las experiencias de un equipo de TSP nuevo son descritas detalladamente, de
PSP que entrena por la entrega de producto. Segundo, están los datos
resumidos de proyecto. Un resumen de datos TSP de las organizaciones y al
menos un numero considerado de proyectos. Finalmente, cambiamos de datos
a experiencias personales. Se presentan anécdotas del PSP y las comunidades
TSP que relacionan las experiencias que no pueden ser descritas solo por
datos.

También podría gustarte