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 TS P
CMM se enfoca a nivel organizacional TSP se enfoca a un proceso pr oceso de grupos de tr abajo PSP se enfoca a nivel personal "PSP cubre 12 de los 18 KPAs (área s claves de procesos del CMM) y m aterializa lo que han querido decir CMM, ISO 9000 y SQA (software qu ality 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. p rueban Los ingenieros estan en un círculo vicioso, "sólo creen en lo que h an 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 grupo s o equipos, equipos, y seran grupos grup os que asi lo han sido y seguiran siendo. 3. Requiere un fuerte soporte de administración, en este sentido es neces ario que los administradores entiendan el PSP, saber como apoyarlos y como monitorear sus avances, sin un adecuad o monitoreo los ingenieros ingenieros caeran otra vez en los lo s malos habitos. 4. Después de ser bien entrenados y bien administrados lo que sigue es optimiz ar la interaccion entre equipos y aquí entraría Team Software Process, el TSP extiende y refina los metodos de CMM y PSP sobre desarrollo desarrollo y mantenimiento de equipos, y llegar a lo que se le llama un equipo autodirigido. aut odirigido.
PSP, ¿ QUE ES ? Es un ciclo de vida del proceso de software que se caracteriza por:
y y y
Ser definido, conciso Altamente prescriptivo Rápido y barato (?)
CAPACITACION PSP, ¿ BARATA ? SEMINARIO P EJE CUTIVOS 4,498 INGENIEROS I 9,046 INGENIEROS II 9,046 CAPACIT. INSTRUCTORES 14,046 ADMON ING ENIEROS 7,587 TOTAL dlls 44,223
BASES DE PSP PSP combina: y y y y
Admón. de proyectos Admón. de calidad Ingeniería de software Empowerment (delegación exitosa)
DESGLOSANDO PSP y y y y y y y
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 TEMPL ATES 2 CHECK LISTS 76 FORMAS C10-C86, R ESPALDAN ESTOS DOCUMENTOS EN 7 NIVELES DE PSP
DESGLOSANDO PSP, PRECISION
El Empow erm ent de PSP esta basad o en
y
La responsabilidad y autonomía a los ingenieros La experiencia de décadas
y
Modelo para la optimización individual
y
CICLO DE VIDA SW, PSP Ciclo de vida tradicional:
ANALISIS DISEÑO CODIFICACION PRUEBAS Ciclo de vida PSP:
planeación Diseño alto nivel R evisión alto nivel Desarrollo PostMortem
7
niveles del PSP
PSP3 Proceso Personal Cíclico
PSP2 y PSP2.1 Manejo Personal de calidad
PSP1 y PSP1.1 Proceso Personal de Planeación
PSP0 y PSP0.1 Línea Base del PSP
PSP 0
docto/seg 37 58 42 25
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 summar y)
PSP 0.1 Registrar tamaño del producto y hacer un histórico: y y y
Lineas de código
Function points Estandarización de la codificación
Registrar problemas y mejoras de propuestas
PSP 1 Mejora la planeación: y y
Con la estimación tamaño del producto (historico) Decidir en base a reportes de pruebas
PSP 1.1 Mejora la planeación: y y
Con la estimación de recursos Introducción de calendarizar, plasmar el plan con números, un presupue sto.
PSP 2 Mejora la ejecución: y y y y
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: y
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): y y y
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 y y y y
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 oper acionales, 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 prueba s y ciclo.
ACTIVIDAD Diseño de apariencia, verificación de máquina s 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 prueb as, 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 d e ciclo, producto de software, patrón de diseño, lista de verificación de códig o y diseño, resumen del ciclo, patrón de reporte de prueb as, registro de tiempo, defectos y seguimiento. ACTIVIDAD Defectos previstos, removidos, tamaño, tiempo del producto. OUTPUT Producto, listas de verificación, plan de pro yecto 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 q uién fue desarrollado, su estructura, un a 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 L AS ESTRATEGIAS D E CALIDAD AMERICANAS QU E INICIO: DEMMING EN L A 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 Método planeación Valor agregado
Compromiso Planes agresivos Calidad propia
Prioridad en calidad Costo de calidad Seguir el proceso
Métricas calidad Procesos definidos
Objetivos proyecto Plan propio Plan detallado Roles Recursos de equipo
Revisión de status y calidad Comunicación
Objetivos del TSP y y y y y y y
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 y y y y y y y
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 d ia 4 o bien al final del dia 3
Productos planeacion para lanzamiento TSP y y y y y y y y
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
y
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 c on cohesión, hay cooperación Cada miembro conoce su status, se realiment a con su trabajo y tiene liderazgo que sustent a 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 E jemplo Plan de Calidad
Nombre: x
Proyecto: xx parte: xxy
Defectos Compilación En producto Revisión código
Plan 140 7 23
Actual 220 21 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: y y y y
Monitoree el modulo durante las prueb as y corrija Reinspeccione el modulo antes de la integracion y prueb as 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 tiemp o 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) y
y
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 y y y y y y y y
Lanzamiento Estrategia
Planeación Requerimientos Diseño Implementación Prueba Postmortem
Experiencia, AMCIS y y
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 e mpleo 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 T SP 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.
Publi
us Samuel en 14 :
0 comentar ios
Desarrollo
Team Software Process (TSP) Es eo oo í ii i e jo e ejo esarro o e sof ware e torno donde e l trabajo efe ti o de e i o sea ade ás de estable er normal natural. A uda a onformar e ui os ara el desarrollo de sof tware de alidad. TSP ro orciona un marco de trabajo ue se construye sobre la base PSP con bases de desarrollo bien definidas en las ue los roductos de software se eneran en arios ciclos y así se establecen medidas estándares ara la calidad del roducto y ara el desempe o de los e uipos y los desarrolladores. El TSP tiene dos componentes primarios: un componente ue construye e uipo y un funcionamiento de e uipo o componente de dirección. El componente ue construye e uipo del TSP es el lanzamiento de TSP, ue pone el e uipo en la situación pro ocati a 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 reco idos en el ni el indi idual. El marco de medida TSP consolida datos indi iduales en una perspecti a de e uipo.
Los datos son analizados semanalmente por el e uipo para entender el estado de proyecto contra objeti os de calidad. El marco de medida TSP también hace disponible otros puntos de ista 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 e uipo son archi ados para proporcionar un depósito de datos históricos para el futuro e mpleo. En un entorno donde el entendimiento es un factor fundamental para ser competiti o, las empresas tienen ue superar todo tipo de barreras culturales para poder expandir con éxito sus acti idades comerciales a escala mundial, observemos la si uiente fi ura:
Vemos
tres entornos, PSP es una alternativa dirigida a los ingenieros de sistemas, que les permite me orar 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 con unto 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 autoaprendiza e y auto me ora. 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 traba o. PSP provee lineamientos específicos sobre cómo los desarrolladores de software pueden continuamente me orar 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 P SP pueden traba ar 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 con unto de productos y servicios de me ora 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 me orar por m s de veinte años a organizaciones en todo el mundo.
ESTRUCTURA D E TSP PSP: Planes personales, Método, planeación, Valor agregado, Métricas calidad, Procesos definidos. TSP Cre ión de Equip : Compromiso, Planes agresivos, Calidad propia, Ob etivos proyecto. TSP Trabajo en equipo: Prioridad en calidad, Costo de calidad, Seguir el proceso, Revisión de status y calidad. Obj e
ivos del TSP. * Generar un marco basado en PSP * Desarrollar productos en varios ci clos * 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: Ma imizar 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 di vidido en f ases : * 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 e periencias que ilustran las venta as de tres perspectivas. De primera forma tenemos una perspectiva nueva de proyecto. Las e periencias de un equipo de TSP nuevo son descritas de talladamente, 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 e periencias personales. Se presentan anécdotas del PSP y las comunidades TSP que relacionan las e periencias que no pueden ser descritas solo por datos.
