csw02 ver2

Calidad en el Desarrollo de Software

UNIDAD II Métricas y Procesos PSP

Personal Software Process

LCC. Marcela García Alonso


Objetivo General:

• Introducir al alumno a la Metodología del PSP, así como conocer los conceptos acerca de métricas en el desarrollo de Software.


Índice

II.I. Introducción al Personal Software Process (PSP)

II.II. Estructura del PSP

III.III. Métricas del PSP



Objetivo:

• Conocer los antecedentes, principios y pasos del PSP.

• Definir y explicar los orígenes de PSP


Antecedentes• Después de la segunda guerra mundial, la estrategia de calidad en la

mayoría de las organizaciones industriales se basaba casi por completo en las pruebas. Las empresas establecieron departamentos especiales de la calidad para encontrar y arreglar problemas después de la producción de los productos.

• No fué sino hasta los años 70 y los años 80 que W. Edwards Deming y J.M. Juran convencieron a la industria estadounidense que se centrara en mejorar la forma en la que la gente hacía sus trabajos y desarrollaban sus procesos. [ DEMING; 82 ], [ JURAN 88]

• En los siguientes años, este enfoque a los procesos de trabajo, ha sido responsable de las mejoras importantes en la calidad de automóviles, de la electrónica, o de casi cualquier otra clase de producto.

• La estrategia tradicional que había de "prueba-y-arregla" ahora es reconocida como costosa, que desperdicia tiempo y que además es ineficaz para el trabajo de la ingeniería y de la fabricación.


Antecedentes• Aunque la mayoría de las organizaciones industriales ahora han adoptado

principios modernos de calidad, la comunidad del software ha continuado confiando en la prueba como el método principal de la administración de la calidad. Para el software, la primera medida principal en la dirección iniciada por Deming y Juran fué tomada por Michael Fagan cuando en 1976 él introdujo las inspecciones del software [ FAGAN; 86]

• Usando inspecciones, las organizaciones han mejorado substancialmente la calidad del software. Otra medida significativa en la mejora de calidad del software fué tomada con la introducción del modelo de capacidad de madurez (CMM) en 1987.

• El enfoque principal de CMM estaba en el sistema que administraba la ayuda que se le proporcionaba a los ingenieros de desarrollo. CMM ha tenido un efecto positivo en el funcionamiento de las organizaciones del software [ HERBSLEB; 97]

• Otra medida significativa en la mejora de calidad del software fué tomada con la esencia del proceso personal del software (PSP) ya que PSP amplía el proceso de mejora a la gente que realiza el trabajo de desarrollo de software.


Antecedentes• PSP se concentra en las prácticas de trabajo de los ingenieros en una

forma individual. El principio detrás de PSP es ése, sirve para producir software de calidad, cada ingeniero debe trabajar en la necesidad de realizar trabajo de calidad.

• PSP se diseñó para ayudar a profesionales del software para que utilicen constantemente prácticas sanas de ingeniería de software.

• Asimismo les enseña a cómo planear y darle un seguimiento a su trabajo, a utilizar un proceso bien definido y medido, a establecer metas mesurables, y finalmente a la utilización del rastreo constante para alcanzar dichas metas.

• PSP les demuestra a los ingenieros a cómo manejar la calidad desde el principio del trabajo, a cómo analizar los resultados de cada trabajo, y a cómo utilizar los resultados para mejorar el proceso del proyecto siguiente. [SEI; 2000] .


¿ Cómo fue desarrollado PSP?

• Después de que Watts S. Humphrey condujera el desarrollo inicial de CMM para software, se decidió a aplicar los principios de CMM a los programas pequeños.

• Posteriormente, mucha gente preguntaba cómo aplicar CMM a las organizaciones pequeñas o al trabajo de los equipos pequeños de software.

• Mientras que los principios de CMM se aplicaron a tales grupos, cada vez se volvía mas necesaria la asesoría para saber que hacer. Fué entonces cuando Humphrey decidió personalmente utilizar los principios de CMM para desarrollar programas modulares para ver si dicho enfoque podría funcionar para convencer a los ingenieros de software a que adoptaran tales prácticas.

• Fué entonces en el desarrollo de estos programas modulares, cuando Humphrey utilizó personalmente todas las prácticas de CMM para que él subiera poco a poco hasta llegar al nivel 5. Poco después él comenzó a trabajar en el proyecto tiempo completo en abril de 1989, el Instituto de la Ingeniería de Software (SEI) hizo a Humphrey un colaborador del SEI, permitiéndole trabajar tiempo completo en la investigación detallada de PSP.



• Durante los siguientes tres años, él desarrolló un total de 62 programas y definió cerca de 15 versiones de PSP. Utilizó los siguientes lenguajes de programación: PASCAL y C++ , para desarrollar cerca de 25.000 líneas de código que ayudarían a darle la forma final a PSP. [SEI; 2002]

• De esta experiencia, él concluyó que los principios de la administración de procesos que desarrolló Deming y de Juran eran totalmente aplicables tanto al trabajo de los ingenieros de software de manera individual como a ingenieros enfocados al trabajo en equipo, el resultado? Proceso en equipo de software (TSP)

• Humphrey después escribió un libro que les proporcionó a varios asociados el material necesario para enseñar cursos de PSP. En septiembre de 1993, Howie Dow enseñó el primer curso de PSP a cuatro estudiantes graduados en la Universidad de Massachusetts.

• Humphrey también enseñó el curso de PSP durante el semestre del invierno de 1993-1994 en la universidad de Carnegie Mellon, al igual que Nazim Madhavji en la Universidad McGill y Soheil Khajanoori lo enseñó en la Universidad Aeronáutica de Embry. De acuerdo con las experiencias y los datos que proporcionaron estos cursos, Humphrey realizó la revisión del libro de PSP y publicó la versión final a finales de 1994. [HUMPHREY; 95 ]



• Casi al mismo tiempo, Jim Over y Neil Reizer del SEI y Robert Powels de la compañía de Servicios Informativos Avanzados (AIS por sus siglas en inglés) desarrollaron el primer curso para entrenar a los instructores a enseñar el curso de PSP en la industria. Humphrey junto con el SEI han continuado trabajando en el desarrollo de PSP y asímismo han aplicado los mismos principios al Proceso en Equipo de Software o TSP.


¿ Qué es PSP?

• Un PSP es un proceso personal desarrollar software.– pasos definidos– formularios– estándares

• Un PSP es un marco de trabajo de medición y análisis que te ayuda a caracterizar tu proceso.

• Es también un procedimiento definido para ayudarte a mejorar tu rendimiento.


II.I.I.Principios del PSP

• La calidad de un sistema software está condicionada por la calidad del peor de sus componentes.

• La calidad de un componente software está condicionada por el individuo que lo desarrolló.

• Está condicionada por tu:– conocimiento– disciplina– compromiso



• Como todo profesional software deberías conocer tu propio rendimiento.

• Deberías medir, seguir y analizar tu trabajo.

• Deberías aprender de tus variaciones de tu rendimiento.

• Deberías incorporar esas lecciones a tu manera personal de hacer.



El diseño de PSP se basa en los siguientes principios de planeación y de calidad [HUMPHREY; 95]

• Cada ingeniero es esencialmente diferente; para ser más precisos, los ingenieros deben planear su trabajo y basar sus planes en sus propios datos personales.

• Para mejorar constantemente su funcionamiento, los ingenieros deben utilizar personalmente procesos bien definidos y medidos.

• Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos.


II.I.I. Principios del PSP

• Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que encontrarlos en las etapas subsecuentes.

• Es más eficiente prevenir defectos que encontrarlos y arreglarlos.

• La manera correcta de hacer las cosas es siempre la manera más rápida y más barata de hacer un trabajo.



Para hacer un trabajo de ingeniería de software de la manera correcta, los ingenieros deben planear de la mejor manera su trabajo antes de comenzarlo y deben utilizar un proceso bien definido para realizar de la mejor manera la planeación del trabajo.

Para que los desarrolladores lleguen a entender su funcionamiento de manera personal, deben medir el tiempo que pasan en cada proceso, los defectos que inyectan y remueven de cada proyecto y finalmente medir los diferentes tamaños de los productos que llegan a producir.



Para producir constantemente productos de calidad, los ingenieros deben planear, medir y rastrear constantemente la calidad del producto y deben centrarse en la calidad desde el principio de un trabajo.

Finalmente, deben analizar los resultados de cada trabajo y utilizar estos resultados para mejorar sus procesos personales.



Objetivo:

• Conocer las métricas de PSP.

• Identificar los objetivos de cada nivel de PSP.


Introducción

• El PSP es un proceso diseñado para uso individual, basado en una versión a escala de un proceso industrial.

• El principal objetivo del PSP es ayudar a los ingenieros software a hacer mejor su trabajo.

• EL PSP se ha diseñado también para demostrar el valor del uso de un proceso definido y medido.

• Por ultimo, el PSP intenta ayudar a los ingenieros y a las organizaciones a que cumplan las demandas cada vez mas estrictas para el desarrollo de sistemas software de calidad


Introducción

• El PSP se aplica en tareas personales estructuradas:– Desarrollo de módulos de programas.– Definición de requisitos o procesos.– Realización de revisiones o pruebas.– Escritura de documentación, etc.– El PSP se puede extender al desarrollo de sistemas

software de gran tamaño.– Es un proceso de Nivel 5 para los individuos y es un

prerrequisito para el TSP


Introducción

• PSP se introduce con siete pasos compatibles.

• Escribes uno o dos pequeños programas en cada paso.

• Recoges y analizas los datos de tu trabajo.

• Los usas y analizas para mejorar tu trabajo.


Estructura de PSP

• Comenzando con los requerimientos, el primer paso en el proceso de PSP es la planificación.

• Existe un script de planificación que sirve de guía y un resumen del plan para registrar todos los datos del mismo. Mientras los desarrolladores van siguiendo el lineamiento de trabajo sugerido por los scripts, deben ir registrando los tiempos dedicados y los datos de defectos en los logs de tiempos y defectos.

• Al final de la tarea, durante la fase de postmortem (PM), deben resumir los datos de tiempo y defectos, medir el tamaño del programa, e ingresar esos datos en el formulario de sumario del plan. Al finalizar, deben entregar el producto finalizado y el formulario de sumario del plan completado.


Flujo del Proceso


Estructura de PSP

• Debido a que generalmente ciertos métodos de PSP no son utilizados por los desarrolladores, los métodos de PSP son presentados en una serie de siete versiones de procesos.

• Estas versiones son denominadas como PSP0 a PSP3. Cada versión tiene un mismo conjunto de logs, formularios, scripts, y standards.

• Los scripts de proceso definen los pasos de cada parte del proceso, los logs y formularios proveen templates para registrar y almacenar datos, y los standards guían a los desarrolladores a mientras hacen el trabajo.

• En otras palabras, PSP es un proceso que está diseñado para ser utilizado.


Elementos del Proceso


Estructura de PSP

• Está construido en un formato simple de utilizar con instrucciones simples y precisas. Si bien los scripts describen qué hacer, en realidad se parecen más a checklists que a tutoriales.

• Estos no incluyen los materiales instructivos que serían necesarios para usuarios no entrenados. El propósito de los scripts es el de guiar a los desarrolladores en el uso consistente de los procesos, los cuales ellos conocen (mediante la asistencia a cursos de capacitación en PSP o a través de bibliografía introductoria en el uso de PSP).


Evolución del PSP

PSP 3Desarrollo Cíclico


PSP 2Revisión del códigoRevisión del diseño

PSP 2Revisión del códigoRevisión del diseño

PSP 1Estimación del Tamaño

Informe de pruebas

PSP 1Estimación del Tamaño

Informe de pruebas

PSP 0Proceso

PSP 0Proceso

Medición Personal

Planificación Personal

Calidad Personal

Proceso Personal Cíclico


Visión General de PSP

• PSP0 - estableces una línea base del rendimiento mensurable.

• PSP1 - haces planes de tamaño, recursos y calendario.

• PSP2 - Practicas gestión de defectos y rendimiento.

• PSP3 - Amplias los métodos del PSP a proyecto mayores.


II.II.I. Los 7 Pasos de PSP

PSP 0Proceso actual

Registro de tiempoRegistro de defectos

Estándar de tipos de defectos

PSP 0Proceso actual

Registro de tiempoRegistro de defectos


PSP 0.1Estándar de Codificación

Medición de TamañoPropuesta de mejora del

proceso

PSP 0.1Estándar de Codificación

Medición de TamañoPropuesta de mejora del

proceso

PSP 1Estimación de tamañoReporte de pruebas

PSP 1Estimación de tamañoReporte de pruebas

PSP 1.1 Planeación de tareas

Planeación de tiempos de actividades


PSP 1.1 Planeación de tareas

Planeación de tiempos de actividades


PSP 2Revisión de CódigoRevisión de Diseño

PSP 2Revisión de CódigoRevisión de Diseño

PSP 2.1Formatos de Diseño

PSP 2.1Formatos de Diseño



Proceso de Medición Personal

Proceso de Planeación

Personal

Administración de Calidad Personal

Proceso Personal Cíclico


II.II.I.I. PSP0

El punto de partida de PSP


II.II.I.I. PSP0 El punto de partida de PSP

• PSP0 es un proceso sencillo, definido y personal.

• Utiliza tus métodos actuales de diseño y desarrollo.

• Recoge datos sobre tu trabajo:– tiempo gastado por fase– defectos encontrados en compilación y

pruebas

• Proporciona un informe resumen.


II.II.I.I. PSP0 El punto de partida de PSP

• 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.


II.II.I.I. PSP 0.1

• Se pasa a 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.


II.II.II. PSP1

Planeación Personal


II.II.II. PSP1

• PSP1 Planeación personal

• 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:


II.II.II. PSP1

• 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.

Mientras que la importancia de estas técnicas en proyectos grandes es comprendida, pocos desarrolladores las aplican a su trabajo personal. PSP demuestra el valor de estos métodos en el nivel personal.


II.II.III. PSP2

Calidad Personal


II.II.III. PSP2

• Un objetivo de PSP es ayudar a los desarrolladores a lidiar de manera realista y objetiva con los defectos que introducen. Los programadores por lo general se avergüenzan de sus errores. El hecho de que la mayoría de los errores sean tipográficos o errores tontos hace que los desarrolladores sientan que pueden mejorar haciendo más esfuerzo.


II.II.III. PSP2

• El problema es que hacer más esfuerzo por lo general hace que las cosas empeoren; las claves, como en otras actividades, son las habilidades inherentes y las capacidades.

• En PSP2 se enfoca en mejorar la habilidad del desarrollador para producir programas de calidad.

• La idea es hacer al trabajo de calidad más natural y consistente. Mejoras significativas en la frecuencia de defectos de los desarrolladores no son posibles a menos que conozcan cuantos errores cometen y que comprendan sus causas y consecuencias.


II.II.III. 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.


II.II.III. PSP2

• El proceso de diseño es contemplado en PSP2.1. El objetivo no es decirle a los desarrolladores como diseñar sino 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.


II.II.IV. PSP3

Proceso Personal Ciclico


II.II.IV. PSP3

• Hasta este punto PSP se concentró en el proceso lineal para construcción de pequeños programas. PSP3 presenta métodos para ser usados por individuos en la realización de programas de gran escala. De todas formas sigue enfocado en el individuo y no trata los problemas de comunicación y coordinación que son una parte importante del desarrollo de sistemas de gran escala.


II.II.IV. PSP3

• Para escalar PSP2 a proyectos más grandes la estrategia consiste en subdividir el proceso personal de desarrollo de grandes programas en elementos en la escala de PSP2. Estos programas son entonces diseñados para ser desarrollados en pasos incrementales. La primera construcción consiste en un módulo base o kernel que es ampliado en ciclos iterativos. En cada iteración se utiliza un PSP2 completo, incluyendo diseño, codificación, compilación y pruebas.


Proceso Personal CíclicoEspecificaciones

RequerimientosY

Planificación

Diseño deAlto nivel

IntegraciónPruebas del sistema

Uso

Postmortem

Repaso al DiseñoDe

Alto nivel

DesarrolloCíclico

Ciclo específico

Diseño detalladoY

Repaso del diseño

Pruebas

Valorar de nuevoY Reciclar

Desarrollo de las pruebasY repaso

ImplementaciónY Repaso del código

Compilación

Producto

.

.

.

.

.

.


II.II.IV. PSP3

• 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.


Planeación en PSP

• ¿Por qué hacer planes?

• Te permiten llegar a acuerdos que tu puedas cumplir

• Proporcionar las bases para acuerdo en tu trabajo

• Guía tu trabajo

• Te ayuda a seguir tu progreso

• Terminación del proyecto


Planeación PSP• La primera tarea consiste en definir los requerimientos,

describiendo el trabajo a realizar en el mayor detalle posible. • Como la etapa de planificación es demasiado temprana como para

hacer un diseño completo del producto, los desarrolladores realizan un diseño conceptual, mediante el cual se obtiene un primer acercamiento de cómo debe basarse el producto a ser construido en la etapa de desarrollo.

• La siguiente tarea consiste en la estimación de tamaño y de esfuerzo.

• La correlación entre el tamaño de un programa y tiempo de desarrollo es moderadamente buena para equipos de desarrollo; sin embargo, para un solo desarrollador, la correlación es generalmente un poco mayor. Los desarrolladores realizan las estimaciones utilizando datos históricos personales de tamaño y productividad. En PSP, las estimaciones se efectúan mediante el método PROBE (PROxy Based Estimating).


Planeación PSP

Entregar el producto

Define los requerimientos

Producir diseño Conceptual

Estimar el tamaño del producto

Estimar los recursos

Base de Datos deTamaño

Base de Datos de Productividad

Recursos disponibles

Tamaño, Recursos,Datos, Plazos

Producir Calendario

Usuario

Necesidad del usuario

Desarrollar el producto

Analizar el proceso

Seguimiento deReportes

Gestión

Método PROBE Tareas

Items


Planeación PSP• Una vez que los desarrolladores conocen el tiempo requerido para

cada proceso, deben estimar el tiempo que van a dedicar al trabajo cada día de la semana, conformando entonces el calendario.

• Luego, durante la etapa de desarrollo del producto, los desarrolladores efectúan el diseño detallado, la implementación y las pruebas.

• Después de completar el trabajo, los desarrolladores realizan un análisis postmortem, en el cual se actualiza el sumario del plan con los datos reales de tiempos invertidos en cada etapa del desarrollo, defectos encontrados y removidos, etc, y se comparan los resultados obtenidos con lo planeado.

• Finalmente, los desarrolladores registran toda esta información en sus bases de datos históricas de tamaño y productividad. Además se examinan las Propuestas de Mejoras (PIP) para hacer ajustes en los procesos.


Planeación 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.


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).

• Estos datos se recopilan en cada fase del proceso y se resumen a la terminación del proyecto. Todos estos datos se utilizan para proporcionar una familia de medidas de calidad de procesos que los ingenieros usan como guía en su trabajo.


Recolección de datos

Las principales medidas son:• Tamaño tiempo de estimación de errores• Coste de realización• Defectos producidos y corregidos por hora• Producción del proceso• Valoración y calidad del coste de los fallos

(COQ)• Valoración del rango de fallos (A/FR)


Elementos del Proceso

• Elementos– un guión de proceso– un formulario resumen de plan proyecto– un registro tiempo– un registro de defectos– un estándar de tipos defecto


Flujo del Proceso


Guión del procesoNúmero de Fase Propósito Guiarte en el desarrollo de programas a nivel de módulo

Entradas Necesarias

* Descripción del problema Formulario de Resumen del plan del Proyecto PSPO•Tablas de Registro de Tiempos y Defectos•Cronometro (opcional)

1 Planificación

•Producir u obtener los requisitos•Estimar las LOC necesarias•Estimar el tiempo de desarrollo necesario•Indicar los datos del plan en el Resumen del Plan de Proyecto•Completar el Log de Registro de Tiempos

2 Desarrollo

•Diseñar el programa•Implementar el diseño•Compilar el programa y corregir todos los defectos encontrados•Completar la Tabla de Registro de Tiempos

3 Post-mortem * Completar el Resumen del plan del Proyecto con los datos actuales de tiempo, defectos y tamaño

Criterios de salida

Un programa probadoUn resumen del Plan de Proyectos con los datos estimados y actualesLas tablas de Registro de Tiempos y Defectos Rellenos


Guión del proceso

• Planificación – Estimar tiempo de desarrollo.

• Desarrollo – Desarrollar el producto utilizando tus métodos

actuales.

• Post-mortem – Completar el resumen del plan proyecto, con

los tiempos gastados y defectos encontrados e inyectados en cada fase.


Guión del proceso

• Diseño – Diseñar el programa, usando tus métodos de diseño

actuales.• Codificación

– Implementa el programa.• Compilación

– Compila hasta que este libre defectos.• Prueba

– Prueba el programa y corrige todos los defectos.• Registra los defectos en el Log de defectos y

tiempos por fase en el Log de tiempos.


Resumen del PlanEstudiante: _Juan Luís Guerra_________ Fecha: _09/10/06__Programa:_Raíz Cuadrada_____________ Programa #: _1AInstructor: _XX_______________________ Lenguaje: ___C____Tamaño del programa (LOC) Plan ActualTotal (Nuevas&Modificadas) 50 33

Tiempo en Fase (minutos) Plan Actual A la Fecha A la Fecha%Planeación 2 2 1.6Diseño 0 0 0Codificación 53 53 44.2Compilación 20 20 16.7Prueba 25 25 20.8Postmortem 20 20 16.7Total 240 120 120 100.0

Defectos Introducidos Actual A la Fecha A la Fecha%Planeación 0 0 0Diseño 0 0 0Codificación 10 10 100Compilación 0 0 0Prueba 0 0 0Total 10 10 100

Defectos Removidos Actual A la Fecha A la Fecha %Planeación 0 0 0Diseño 0 0 0Codificación 3 3 30Compilación 5 5 50Prueba 2 2 20Total 10 10 100Después del Desarrollo 0 0 0


Resumen del Plan

• Encabezado– Nombre, fecha, programa, instructor,

lenguaje.

• Tamaño del Programa– Plan :Indica tu mejor estimación del tiempo

total que tendrá el desarrollo.– Actual :Indica el tiempo actual en minutos

gastado en cada fase.


Resumen del Plan

• Tiempo– A la fecha: Indica el tiempo total gastado en

cada fase hasta hoy. Para programa 1A, es el tiempo gastado en el programa 1A.

– A la fecha % :Indica el porcentaje del total tiempo hasta hoy que se gasto en cada fase.

• Defectos introducidos y removidos:– Indicar el número actual de defectos

inyectados y eliminados en cada fase.


Resumen del Plan

• Defectos– A la fecha: Indica el total de defectos

inyectados y eliminados en cada fase hasta hoy. Para el programa 1A, son los defectos inyectados y eliminados en el programa 1A.

– A la fecha % :Indicar el porcentaje sobre el total defectos inyectados y eliminados hasta hoy en cada fase.


Log Registro del Tiempo

Fecha Inicio Fin

Tiempo de Interrupción

Tiempo Delta Fase Comenta

rios

Estudiante: ____________________ Fecha: __________

Instructor:______________________ Programa #: ______



• Encabezado– Indicar nombre, fecha, instructor y número de

programa.

• Fecha– Indicar la fecha actual.

• Inicio– Indicar el tiempo en minutos cuando

empiezas una fase del proyecto.



• Fin – Indicar el tiempo en minutos cuando tu paraste tu

trabajo en una fase del proyecto, aun cuando tu no has terminado esa fase.

• Tiempo de interrupción – Indicar el tiempo perdido por interrupciones desde el

periodo de arranque a parada.

• Tiempo Delta time – Indicar el tiempo transcurrido desde el inicio al tiempo

de parada descontado el tiempo de interrupción.



• Fase– Anotar la fase en la que estas trabajando.– Use el nombre de cada fase.

• Comentarios – Descripción de la interrupción– La tarea que estas haciendo– Cualquier aspecto significativo que afecte a tu

trabajo


Por ejemploFecha Inicio Fin

Tiempo de Interrupción

Tiempo Delta

Actividad Comentarios

9/9 9:00 9:50 50 Planeación

12:40 1:18 38 Diseño

2:45 3:53 10 58 Diseño Teléfono

6:25 7:45 80Codificación

10/9 11:06 12:19 6+5 62Codificación

Baño, tomé café

11/9 9:00 9:50 50Codificación

1:15 2:35 3+8 69Compilación

Consulta de un libro

4:18 5:11 25 28 Prueba Reunión con mi jefe

12/9 6:42 9:04 10+6+12 114 Prueba Teléfono, Baño, Teléfono

13/9 9:00 9:50 50 Prueba

12:33 1:16 38 Postmortem


Manejo de Interrupciones

• Uno de los problemas que se presenta a la hora de gestionar el tiempo son las interrupciones. Es muy normal que nos interrumpan por llamadas de teléfono, gente que viene a hablar con nosotros, o tenemos que parar porque necesitan nuestra ayuda.

• Cuando se producen estos casos se almacena este tiempo en el Registro de Almacenamiento de Tiempo anotándolo en la columna Tiempo de Interrupción. Durante este periodo no solo se anota el tiempo de la interrupción sino también porqué se ha producido en la columna de Comentarios.


Manejo de Interrupciones

• Ya que el tiempo de interrupción no es un tiempo productivo para el trabajo, se debe llevar un registro de las interrupciones. El tiempo de las interrupciones suele ser variable, por lo tanto si no se mide, se debería añadir un número aleatorio para todos los datos de tiempo.

• Estos datos de tiempo pueden ser útiles para comprender mejor como es interrumpido el trabajo, ya que las interrupciones no solo gastan tiempo, sino que rompen la forma de trabajo y pueden provocar que se produzcan errores. Conocer como son las interrupciones podría ayudar a realizar un trabajo más eficaz y de más calidad.


Tamaño

• El tiempo en desarrollar un producto se encuentra altamente determinado por el tamaño del mismo. En PSP, los desarrolladores primero estiman el tamaño de los productos que planean desarrollar. Luego, al finalizar el producto, se mide el tamaño real obtenido.

• Esta información permite a los desarrolladores realizar a futuro una estimación de tamaños más precisa. Sin embargo, para que esta información sea útil, el tamaño de las mediciones debe corresponderse con el tiempo de desarrollo del producto. En PSP, el tamaño se mide en Líneas de Código (LOC).

• Para realizar un seguimiento de la variación del tamaño de un programa durante el desarrollo, se deben considerar varias categorías de LOC.


Tamaño

Estas son: • Base (son los LOC iniciales del producto original)• Agregadas (es el código agregado a un programa base

existente)• Modificadas (es el código base que es modificado en un

programa existente)• Eliminadas (es el código base que es eliminado de un

programa existente)• Reutilización (es el código tomado de una librería u utilizado,

sin realizar ninguna modificación, en un nuevo programa)• Nueva Reutilización (esta medida cuenta los LOC que se

agregan a una librería)• Total (es tamaño total del programa, independientemente del

código fuente).


Tamaño

• Luego, para medir el tamaño total de un producto, el cálculo es el siguiente:

• Total LOC = Base – Eliminadas + Agregadas + Reutilización

• Las LOC modificadas y de “nueva reutilización” no son incluidas en el total; esto se debe a que las LOC modificadas pueden representarse por LOC eliminadas y agregadas, y las LOC de “nuevo reutilización” ya se encuentran contabilizadas en las LOC agregadas.


Estándar tipo de Defectos

• El estándar de tipos de defectos proporciona un conjunto general de categorías de defectos.

• Aunque tu puedes reemplazar este estándar por el tuyo propio, es deseable que te manejes con estas definiciones simples de tipos hasta que tengas datos que te puedan guiar en las modificaciones.


Estándar tipo de Defectos


Log Registro Defectos

Nombre: _______________________________ Fecha: ___

Instructor: ______________________________ Programa :__

Fecha Número Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado

10/10/06 1 40 CÓDIGO CODIGO 11

Descripción: Agregar una variable a la estructura


10/10/06 2 20 CÓDIGO CODIGO 1

Descripción: Variable multidefinida


10/10/06 3 w0 CÓDIGO COMPILAR 1

Descripción: Las comillas de la instrucción de impresión no existen “”


10/10/06 4 10 CÓDIGO PRUEBA 39

Descripción: Alinear y agregar instrucciones de impresión , mejorar la apariencia



• Encabezado – Indicar el nombre, fecha, instructor, y numero

de programa.

• Fecha– Indicar la fecha cuando encontraste y

corregiste el defecto.

• Número– Indicar un número único para este defecto.

Comienza cada proyecto con 1.



• Tipo– Indicar el tipo de defecto a partir del estándar

de tipos de defectos.

• Introducido – Indicar la fase donde tu juzgas que el defecto

fue inyectado o introducido.

• Eliminado– Indicar la fase en la que encontraste y

eliminaste el defecto.



• Tiempo de Arreglo– Indicar el tiempo que tomaste para corregir el defecto.

Tu puedes dar el tiempo exacto o usar tu mejor estimación.

• Defecto Arreglado – Si este defecto fue inyectado durante la corrección de

otro defecto, indicar el número de ese defecto o una X si lo desconoces.

• Nota – Un defecto es cualquier cosa en el programa que

debe ser cambiado para que sea desarrollado, mejorado o utilizado de manera adecuada.



• Finalmente, la manera más eficaz de encontrar y arreglar defectos es repasando el código fuente del programa personalmente. Mientras esto puede parecer como una manera difícil de limpiar un programa defectuoso, resulta ser más rápido y más eficaz. Un método para realizar revisiones de código es la utilización de guías en las que se determina cuales son los defectos que mas frecuentemente se inyectan.


Guía Personal de Revisión de Código

Propósito Guía para realizar una revisión de código efectiva # # # 3

Para Fechar

Para Fechar %

General

Cuando se completa cada paso de revisión, anota el número de defectos del tipo encontrado in la caja de la derecha.Completa el catálogo para un programa, clase, objeto o método antes de empezar la próxima revisión

CompletaVerifica que todas las funciones del diseño están codificadas.

Includes Verifica cada include que esté completo

Inicialización

Chequea las variables e inicialización de parámetros.

LlamadasChequea los formatos de llamadas de función: punteros, parámetros.

NombresChequea los nombres y su uso: consistencia, declaraciones, y estructuras.

StringsChequea que los punteros están:Identificados por punterosTerminados en NULL

Punteros

Chequea que los punteros están:Inicializados a NULLBorrarlos después de crearlosBorrarlos siempre después del uso


Guía Personal de Revisión de Código

Propósito Guía para realizar una revisión de código efectiva # # # 3

Para Fechar

Para Fechar %

Formato de salida

Cheque el formato de salda

{} Parejas

Asegurarse de que {} están cerrados

Operadores lógicos

Verificar el uso de ==, =, ||, etc.Chequea cada función entre ()

Chequeeo Línea por línea

Chequea cada línea del código:Sintaxis de las instruccionesPuntuación

Estándares

Asegura que el código sigue el estándar de codificación

Abrir y cerrar ficheros

Verificar que todos los ficheros estas:DeclaradosAbiertosDeclarados

GlobalRealizar un escaneo global del programa para chequear el sistema e inspeccionar los problemas


Mediciones de Tiempo

• Los desarrolladores utilizan el log de registro de tiempo para medir el tiempo que dedican a cada fase del proceso. En este log se anota la hora en que empezaron a trabajar en una tarea, la hora en que terminaron una tarea, y cualquier hora en que efectuaron una interrupción y/o retomaron una tarea. Por ejemplo, una interrupción podría ser una llamada telefónica, un descanso, o alguien interrumpiendo para hacer una pregunta. Tomando estos tiempos en forma precisa, los desarrolladores pueden conocer el esfuerzo que realmente se dedica a las tareas del proyecto. Debido a que los tiempos de interrupciones son esencialmente al azar, ignorar estos tiempos sería introducir un error de gran tamaño en la información de tiempos que reduciría la exactitud de las estimaciones.


Administración del Tiempo

Para la llevar a cabo una buena gestión del tiempo se pueden tener en cuenta los siguientes puntos:

• Tener en cuenta que normalmente el tiempo se gasta de la misma forma.

• Se debe realizar un seguimiento la forma en la que se gasta el tiempo.

• Para chequear con exactitud las estimaciones del tiempo y la planificación, se debe documentar y más tarde compáralo con lo que actualmente se hace.

• Para hacer planes más exactos, se deben determinar los planes previos erróneos y que deberíamos hacer mejor.

• Planificar el tiempo y seguir un plan. • Todo esto se puede resumir mejor diciendo que la mejor forma de

gestionar el tiempo es comprender como empleamos el tiempo y esto exige que sepamos catalogar las actividades, registrar el tiempo empleado en cada actividad y almacenar estos datos en un lugar conveniente.


Seguimiento del Tiempo

• Una vez que sabemos gestionar el tiempo, es necesario almacenar todos estos datos de alguna forma mediante un formulario. Es importante resaltar que utilizar como unidad de medida la hora no nos proporciona detalles para manejar o planificar el trabajo, es mucho más fácil en minutos.


II.III. Métricas del PSP


II.III. Métricas del PSP

Objetivo:

• Aplicar las métricas de PSP.

• Definir y explicar: Los indicadores de medición del PSP.


Métricas del PSP• Con datos de tamaño, tiempo y defectos, existen muchas formas de

medir, evaluar, y manejar la calidad de un programa. PSP provee una serie de mediciones de calidad que ayudan a los desarrolladores a examinar la calidad de sus programas desde varias perspectivas. Como ninguna medición por sí sola puede indicar adecuadamente la calidad de un programa, el panorama que provee la utilización de todas estas mediciones es generalmente un indicador confiable de calidad.

• Las principales mediciones de calidad son:– Densidad de defectos– Índice de revisión– Índices de tiempo de desarrollo– Índices de defectos– Rendimiento– Defectos por hora– Efectividad de remoción de defectos– Evaluación del índice de fallas


Resumen del registro de Métricas

Nombre: Fecha: 18/10/96Programa Programa # 13Profesor Lenguaje: C++Resumen Plan Actual a la Fecha

Minutos/LOC 5,92 4,87 5,73LOC/Hora 10,14 12,32 10,47Defectos/KLOC 94,79 106,4 96,90RendimientoA/FR

Tamaño Programa (LOC):Total nuevo & Cambiado 58 47 258Tamaño Máximo 72Tamaño Mínimo 41



Tiempo en fase (min.) Plan Actual Para Fecha Para Fecha %Planing 18 22 88 6,0Diseño 35 24 151 10,2Código 149 93 637 43,1Revisión código 20 37 111 7,5Compilación 24 4 92 6,2Test 64 8 240 16,2Postmortem 33 41 160 10,8Total 343 229 1479 100Tiempo Máximo 426Tiempo Mínimo 243



Introducción de defectos Plan Actual Para Fecha Para Fecha % Def/HoraPlaningDiseño 1 4 16,0Código 5 5 21 84,0Revisión códigoCompilaciónTestTotal 6 5 25 100,0



Eliminación de defectos Plan Actual Para Fecha Para Fecha % Def/HoraPlaningDiseñoCódigoRevisión código 2 3 8 32,0Compilación 3 2 12 48,0Test 1 5 20,0Total 6 5 25 100,0


Comparación de PSP

Característica PSP Inspecciones CMM ISO900

PropósitoGerenciamiento y mejora de la calidad Mejora de la calidad Mejora del

gerenciamientoGerenciamiento de la calidad

Metodología Prescriptiva Presciptiva Descriptiva Descriptiva

Definición Exacta Exacta Vaga Vaga

AudienciaDesarrolladores y gerentes Desarrolladores Gerentes Gerentes

CoberturaCiclo de vida del desarrollo

Verificación y validación

Gerenciamiento de proyectos

Aseguramiento de la Calidad

Costo Muy bajo Bajo Alto Alto

Calidad Muy alta Alta Baja Baja

Implementación Semanas Días Años Años

Alcance Integral Estrecho Ambiguo Ambiguo

Cuan Mensurable es Muy Alto Alto Bajo Bajo


Conclusiones

• Conociendo los principios y las características de la metodología de PSP, conformada por los procesos de planificación, estimación de tamaño y esfuerzo, recolección de datos, manejo de calidad y especificaciones de diseño, se plantea la posibilidad de incorporar esta metodología al contexto de una empresa pequeña, o grupo de desarrollo de software pequeño analizando los factores operativos, económicos y los riesgos a los que se expone

• Una vez implementada esta metodología en el ambiente de trabajo, un siguiente paso consiste en enfocarse en la mejora de la eficiencia y de la dinámica de trabajo a nivel de equipos de desarrollo, mediante el método conocido como TSP (Team Software Process).


Team Software ProcessTeam Software Process

TSP


Team Software ProcessTeam Software Process

• El resultado final es que incluso aunque un equipo de ingenieros esté entrenado en PSP, todavía les queda combinar sus procesos de trabajo personal dentro de un único proceso de equipo. Esto es para ellos un problema, incluso en los más altos niveles de CMMI. Por esta razón se ha desarrollado Team Software Process SM (TSPSM).


Perspectiva de PSP

PSPSM

Construye capacidades individuales y disciplina de trabajo

TSPSM

Construye productos de calidad sobre coste y planificación

CMMI®

Construye capacidad de organización


Introducción TSP

• PSPSM: Construye capacidades individuales y disciplina de trabajo

• TSPSM: Construye productos de calidad sobre coste y planificación

• CMMI® :Construye capacidad de organización• TSP extiende y refina los métodos CMM y PSP, para

guiar a los miembros de los equipos en el trabajo de mantenimiento y desarrollo. TSP les muestra como construir un equipo autodirigido y como ser un efectivo miembro del equipo. También les enseña como dirigir y soportar estos equipos y como mantener un medio para obtener un alto nivel de desarrollo.


Objetivos TSP

En resumen, se puede decir que TSP tiene 5 objetivos principales:

• Construir equipos autodirigidos que planifiquen y realicen un seguimiento de su trabajo, estableciendo metas además sus propios procesos y planes.

• Mostrar a los directores como entrenar y motivar a sus equipos y como ayudarles para mantenerles en el más alto nivel de desarrollo.

• Acelerar la mejora del proceso software haciendo normal la conducta del Nivel 5 de CMMI

• Mejorar la dirección para obtener organizaciones de un alto nivel de madurez


Objetivos TSP• La principal ventaja de TSP es que muestra a los ingenieros como

producir productos de calidad por medio de una planificación de costos. Esto lo hace, enseñándoles cómo planificar su propio trabajo y haciéndoles participes de los planes y procesos que se van a llevar a cabo.

• TSP proporciona equipos de proyectos con guías explícitas sobre como alcanzar sus objetivos. TSP conduce al equipo a través de cuatro fases dentro de un mismo proyecto. Estos proyectos deben empezar o terminar con alguna fase o pueden ejecutarse desde el principio al final. Antes de cada fase, el equipo planifica y organiza su trabajo mediante una puesta en marcha completa (launch) o relaunch.

• Generalmente, una vez que los miembros del equipo han sido entrenados en PSP, es suficiente alrededor de cuatro días para proporcionar una guía para la puesta en marcha de una fase entera del proyecto.


Evolución de TSUP

LanzamientoFase Inicial. Creación

de los Grupos y Requerimientos

Fase Inicial. Creación de los Grupos y Requerimientos

Relanzamiento

Segunda Fase. DiseñoSegunda Fase. Diseño

Relanzamiento

Tercera Fase. Implementación

Tercera Fase. Implementación

Postmortem

Postmortem

RelanzamientoCuarta Fase. Integración

y Pruebas

Cuarta Fase. Integración y Pruebas


Equipos de Trabajo

• El Software Engineering Institute (SEI) ha desarrollado el TSP para ayudar a equipos de ingenieros de software a desarrollar productos de software de manera eficiente.

• Este proceso ataca varios de los problemas actuales en el desarrollo intenso de productos de software y enseña a equipos de trabajo y gerencia como resolverlos.

• El TSP muestra a grupos de ingenieros como aplicar conceptos integrados en el desarrollo de software, encamina a los ingenieros y a la gerencia en un proceso de 4 días para establecer los objetivos, definir los roles, atacar los riesgos y producir un plan de trabajo comprensivo. Siguiendo el lanzamiento el TSP provee un marco de procesos definidos y medibles para administrar, supervisar y reportar el trabajo en equipo.


Equipos de Trabajo

El TSP tiene 5 fases principales.• Requerimientos • Diseño• Implementación• Pruebas• PostmortemCada equipo puede estar conformado por al menos 2

personas y hasta 15 personas como máximo. Los miembros del equipo deben trabajar hacia un objetivo común y tiene roles específicos o responsabilidades dentro del equipo. Existe una interdependencia entre el trabajo de los miembros del equipo que requiere cooperación para que el equipo sea exitoso y por lo mismo siguen un proceso de trabajo común.


Generación de Equipos con PSP y TSP

• Se puede decir que esta sería una fase preliminar a la hora de arrancar un proyecto utilizando TSP. En esta fase se establecen la función de cada uno de los miembros del grupo, las metas, los mecanismos de comunicación y los datos requeridos.

• Es importante que cada miembro del grupo sepa cual va a ser su función y sus responsabilidades, y debería comprobar si alguno de los miembros del grupo necesita ayuda. Además cada miembro del grupo debe proporcionar una copia completa del formulario WEEK para que el jefe del proyecto pueda planificar la siguiente fase.

• Se debe crear un diseño conceptual para cada producto planificado y dividir en ciclos y documentar el trabajo. Además se debe de tener una infraestructura para poder realizar estas funciones como por ejemplo formularios que controlen los errores, el control de la entrada/salida, etc.



• Los miembros del grupo deben planificar una fase de implementación personal utilizando por ejemplo PSP. Esta planificación y documentación debe ser estándar para todos los miembros del grupo y para ello utilizar los mismos formularios.

• Se deben especificar los bucles de pruebas, los valores de las variables que se van a usar y los condiciones de error que se vayan a producir, establecer los límites de posibles valores de las variables, los datos más críticos, etc.

• Además se debe realizar un desarrollo explicito de las pruebas que se vayan a realizar y las revisiones de código que se vayan a hacer

• Como se ha explicado antes todas las pruebas se deben planificar con anticipación y establecer una forma estándar de realizarlas y documentarlas para solucionar los posibles problemas y errores que hayan producido.

• En la documentación debe aparecer quien o quienes de los miembros del grupo son los encargados de realizar las pruebas y quienes son los encargados de instalar el producto final.



• Al final de cada ciclo y cada grupo debe realizar una memoria de su trabajo y comparar el resultado con las metas establecidas al principio del ciclo para poder así extraer conclusiones.

• Esta memoria debería contener:– El tamaño del producto– Las horas de desarrollo– El rango de líneas de código por hora (LOC/Hours)– El rendimiento antes de la compilación– El rendimiento antes de las pruebas del sistema– El nivel de defectos en la compilación– El nivel de defectos en todas las fases de pruebas

• Además de todo lo anterior expuesto, los grupos deberían aportar la relación de inspecciones y revisiones realizadas y los valores obtenidos en ellas.


Relación del TSP con CMMI y PSP

• Mientras que el CMMI se enfoca en lo que tienen que hacer las organizaciones, no especifica como alcanzar esos objetivos. El PSP provee una guía especifica en como los ingenieros de software de manera individual pueden continuamente mejorar su desempeño. El TSP provee guías especificas de como ingenieros capacitados en PSP pueden trabajar de manera efectiva como miembros de un equipo de alto desempeño. Todas estas tecnologías pueden trabajar juntas para permitir a las organizaciones producir software de calidad en tiempo y presupuesto.


Relación del TSP con CMMI y PSP

Individual

Organización

Equipo

PSP

TSP

CMMI


PSP y TSP respecto a CMMI

• CMMI, PSP y TSP proporcionan un marco tridimensional para la mejora de los procesos.

• CMMI (SW/SE) tiene 22 áreas de proceso, y PSP y TSP guían a los ingenieros en el direccionamiento de casi todo el trabajo. Estos métodos no solo ayudan a que los ingenieros sean más efectivos sino también proporcionan el entendimiento necesario para acelerar la mejora del proceso.

• Una vez que los grupos han empezado el proceso de mejora y están en el camino de alcanzar el Nivel 2 de CMMI, PSP muestra a los ingenieros como direccionar sus tareas de una forma profesional. Aunque relativamente nuevo, PSP también mejora la habilidad de los ingenieros para planificar y realiza un seguimiento de su trabajo y producir así productos de calidad.


PSP y TSP respecto a CMMI

Nivel Enfoque del Proceso Clase de Área de Proceso PSP TSP

5 Optimizado Mejora Continua del ProcesoAnálisis Causal y Resolución X X

Implementación e Innovación Organizacional X X

4 Administrado Cuantitativamente

Administración Cuantitativa del Proceso

Administración cuantitativa del Proyecto X X

Rendimiento del Proceso Organizacional X X

3. Definido Estandarización del Proceso

Enfoque en el Proceso Organizacional X X

Definición del Proceso Organizacional X X

Capacitación Organizacional

Administración del proyecto Integrado X X

Desarrollo de Requerimientos X X

Solución Técnica X X

Integración del Producto X X

Verificación X X

Validación X X

Administración de Riesgos X

Análisis y Resolución de Decisión X X

Administración de Requisitos X

Planeación de Proyectos X X

Monitoreo y control de Proyectos X X

Aseguramiento de la Calidad Software X

Administración de la Configuración del Software X

Administración de Acuerdos con Proveedores

Medición y Análisis X X


Componentes del TSP• Los equipos de TSP estiman proyectos con una aproximación

arriba-abajo, utilizando todo el tamaño y mediante la productividad del equipo, determinar el programa completo. Como se ha descrito anteriormente, el proyecto se divide en fases y cada una de ellas es estimada y rastreada.

• En las puestas en marcha de cada fase, se definen las tareas y para cada tarea se realiza una estimación usando métodos rigurosos de Personal Software Process (PSPSM). Estas estimaciones se utilizan para generar un plan detallado de valores-ganados, con el cual se identificara el seguimiento y planificación de las metas del proyecto, criterios de calidad y riesgos de las puestas en marcha.

• TSP requiere entrevistas periódicas donde se comparan los progresos con la planificación del equipo en términos de valores ganados y calidad. Si hay desviaciones con respecto a la planificación, se pueden determinar las razones y tomar medidas para que se retorne otra vez a dicha planificación. Es también durante estas entrevistas periódicas, donde se revisan los riesgos que se han producido durante la puesta en marcha.


Componentes del TSP• Las puestas en marcha de TSP no concluyen satisfactoriamente

hasta que el equipo y la dirección estén de acuerdo sobre los requerimientos y el desarrollo. Una vez que se ha determinado el desarrollo, se usa como base para una medida personal y los valores se rastrean por cada persona y periódicamente por el equipo.

• El TSP también requiere replanificación de un proyecto, o más tarde actualización, cuando las especificaciones del plan cambian. Esto significa que cuando estas especificaciones cambian a lo largo del proyecto, el equipo renegocia la planificación, delibera la funcionalidad y si es necesario el coste.

• Finalmente, los problemas con la calidad pueden ser virtualmente eliminados usando TSP, ya que los métodos de calidad usados son los mismos que los usados en PSP y que los ingenieros realizan individualmente cuando llevan a cabo sus revisiones, diseños y codificaciones.


Roles dentro del TSP• TSP se ha utilizado con grupos de software y también con grupos donde se

mezcla el hardware, software y sistemas. El tamaño de los grupos puede variar desde 3 hasta 12 o 15 personas. Estos grupos a su vez pueden interactuar entre ellos. Pero para que todo esto funcione es necesario que previamente los integrantes de cada grupo hayan sido entrenados en PSP.

• La puesta en marcha de un proyecto TSP incluye los siguientes pasos:– Revisar con la dirección los objetivos del proyecto.– Establecer los roles del equipo.– Documentar los objetivos del equipo.– Producir la totalidad de la estrategia de desarrollo.– Definir los procesos de desarrollo del equipo.– Planificar los soportes que se necesitan.– Realizar una planificación del desarrollo para el proyecto entero.– Realizar una planificación de la calidad y el conjunto de objetivos de calidad.– Realizar una planificación detallada para cada ingeniero para la siguiente fase.– Unir las planificaciones individuales dentro de un plan de equipo– Rebalancear el trabajo de equipo para conseguir un mínimo programa.– Calcular los riesgos y asignar responsabilidades para cada clase de riesgo.– Tener una puesta en marcha de postmortem.


Roles dentro del TSP

• Al final de cada puesta en marcha, el equipo revisa los planes y los riesgos del proyecto con la dirección. Una vez que el proyecto comienza, el equipo realiza semanalmente reuniones y periódicamente informa de ello a la dirección y al cliente. Después de establecer estos pasos, TSP produce los siguientes resultados:– Se han escrito las metas– Se han definido los roles como por ejemplo Director de Diseño,

Director de Planificación, Director de Proceso, Director de Soportes, Director de Pruebas o Jefe de Equipo. Normalmente los miembros del equipo con rol, son los encargados de detectar los riesgos. Pro ejemplo, un riesgo implica que las negociaciones con el cliente deberían estar asignadas al Director de Interfaces del Cliente.


Bibliografía

• HUMPHREY WATTS S., A DISCIPLINE FOR SOFTWARE ENGINEERING. (USA : ADDISON-WESLEY, 1995)


Deming: 14 Puntos1. CONSTANCIA• El propósito es mejorar constantemente los productos y servicios de la

empresa, teniendo como objetivo la consecución de la competitividad permaneciendo en el mercado para proporcionar empleo por medio de la innovación, la investigación, el mejoramiento continuo y el mantenimiento adecuado.

2. NUEVA FILOSOFÍA• Se trata de adoptar una nueva filosofía de empresa ya que estamos

viviendo una nueva era económica (mucho más ahora) en la que los gerentes deben tomar conciencia de sus responsabilidades y afrontar la cuota de liderazgo que les cabe para lograr el cambio.

3. LA INSPECCIÓN• Se debe dejar de depender de la inspección masiva para alcanzar la

calidad, hay que eliminar la inspección en masa a través de la integración del concepto de calidad en todo el proceso de producción, lo cual aminora costos y permite aumentar calidad.


Deming: 14 Puntos4. LAS COMPRAS• Hay que eliminar la práctica de comprar basándose exclusivamente en el

precio, ya que los departamentos de compras tienden a elegir al proveedor con los precios más bajos. En su lugar, se deben concentrar esfuerzos en minimizar los costos totales, creando relaciones sólidas y duraderas con un solo proveedor para cada materia prima, basándose en la fidelidad y la confianza.

5. MEJORAMIENTO CONTINUO• La búsqueda por mejorar debe ser continua, no momentánea ni estática, se

deben mejorar los procesos productivos, el servicio y la planeación, además la administración debe propender por la minimización de costos a través de la reducción de pérdidas y mermas y productos defectuosos.

6. ENTRENAMIENTO• Se debe instituir el entrenamiento y la capacitación de los trabajadores

como una de las tareas del diario acontecer, con esto no sólo se consiguen mejores empleados sino mayores resultados en cuanto a calidad y costos.


Deming: 14 Puntos7. LIDERAZGO• Las organizaciones deben adoptar e instituir el liderazgo, de manera que la

labor de los supervisores o jefes no se limite a dar órdenes o impartir castigos, sino que más bien se convierta en un orientador que le ayude a la gente a hacer mejor su trabajo y que identifique quiénes son las personas que necesitan mayor ayuda para hacerlo.

8. EL MIEDO• Las firmas deben desterrar el temor y el miedo de todos sus niveles, hay

que generar confianza entre la gente de manera que no sientan temor de opinar o preguntar, esto permite mayor efectividad en el trabajo y permite que las personas se esfuercen porque quieren que la empresa alcance el éxito.

9. BARRERAS• Romper las barreras que existan entre los diferentes departamentos y su

gente, no crear competencias que las hagan chocar sino más bien generar la visión de largo plazo que les permita a todos trabajar por conseguir los mismo objetivos, permitiendo así la colaboración y la detección temprana de fallos.


Deming: 14 Puntos10. SLOGANS• Hay que borrar los slogans o las frases preestablecidas, estos no sirven y lo

que causan es relaciones adversas que redundan en pérdidas de competitividad y calidad.

11. CUOTAS• Deben eliminarse las cuotas numéricas, tanto para trabajadores como para

gerentes. Las cuotas sólo toman en cuenta los números, no los procesos, los métodos o la calidad y por lo general se constituyen en garantía de baja calidad y altos costos. Las cuotas se deben sustituir con liderazgo, eliminando el concepto de gerencia por objetivos.

12. LOGROS PERSONALES• Hay que derribar las barreras que le quitan a las personas el orgullo que les

produce su trabajo, eliminando los sistemas de comparación o de méritos, estos sistemas sólo acarrean nerviosismo y disputas internas.


Deming: 14 Puntos13. CAPACITACIÓN• Se debe establecer un programa interno de educación y automejoramiento

para cada quien, hay que permitir la participación de la gente en la elección de las áreas de desarrollo

14. TRANSFORMACIÓN• Todos, absolutamente todos los miembros de la organización deben

esforzarse por alcanzar la transformación en cuanto a calidad, procesos, productos y servicios, la transformación es el trabajo de todos, pero eso si, hay que basarse en un equipo que reúna condiciones suficientes de capacidad y liderazgo.


Deming: 7 pecados capitales

• 1. Carencia de constancia en los propósitos• 2. Enfatizar ganancias a corto plazo y

dividendos inmediatos• 3. Evaluación de rendimiento, calificación de

mérito o revisión anual• 4. Movilidad de la administración principal• 5. Manejar una compañía basado solamente en

las figuras visibles• 6. Costos médicos excesivos• 7. Costos de garantía excesivo


Juran

Juran tiene una talla comparable a la de Deming, pero a diferencia de éste, creó una empresa de gran tamaño dedicada a la explicación e implantación de la calidad total en cualquier negocio. Existen cursos, videos, ciclos de conferencias, personal especializado en todos los aspectos de esta teoría, que se ofrecen a cualquier compañía que pueda beneficiarse con la aplicación de la calidad total.

A) LOS TRES pasos:• Alcanzar continuamente progresos estructurados, mediante la

dedicación y un sentido de urgencia• Establecer programas abarcadores de entrenamiento• Comprometer a los supervisores a tomar en serio sus

responsabilidades (“diminishing return”)


JuranB) LOS DIEZ pasos:• Crear conciencia de la necesidad de mejorar• Establecer metas de progreso• Organizarse para alcanzar las metas propuestas• Proveer entrenamiento• Establecer proyectos dedicados a la solución de problemas• Hacer reportes de progreso• Dar reconocimientos• Hacer públicos los logros alcanzados• Mantener un sistema operacional de medición de logros• No dejar caer el entusiasmo por la superación aunque todo esté

marchando bien (no dormirse en los laureles)


Juran

– EL PRINCIPIO ...• También llamado 80/20. Lo enunció por

primera vez el economista Wilfredo Pareto a principios del siglo. Establece que en un sistema de control de calidad debe hacerse un esfuerzo por identificar las fuentes de problemas y concentrarse en eliminarlas antes que nada. Según datos estadísticos, las fuentes del 80% de los problemas están en sólo un 20% de los empleados. Aunque es una regla antigua, Juran la demostró y revitalizó.


Juran

• LA TRILOGÍA ...

– La administración de una empresa debe tener tres programas básicos:

– Planificación de calidad que consiste en desarrollar los productos, sistemas y procesos necesarios para satisfacer las esperanzas de los clientes. Esto requiere los siguientes pasos:» Determinar quiénes son los clientes.» Identificar sus necesidades.» Desarrollar productos que respondan a estas

necesidades» Desarrollar sistemas y procesos que permitan producir

esos productos, y» Establecer planes detallados a todos los niveles de

operación.


Juran• Control de calidad. Esto requiere los siguientes pasos:

– Evaluar la calidad inicial– Comparar el funcionamiento de la empresa con lo que sería

una situación ideal, y– Resolver las diferencias entre el estado actual y el ideal

• Mejoramiento de la calidad. Esto debe ser un objetivo al cual deben dedicarse esfuerzos constantes. Se logra con los siguientes cuatro pasos:

– Desarrollar la infraestructura necesaria para lograr mejoras anuales en la calidad

– Identificar áreas específicas que deben mejorarse, y poner en práctica planes para lograrlo

– Establecer un equipo de trabajo para cada proyecto de mejoramiento de la calidad

– Dar a estos equipos de trabajo todo lo que necesiten para cumplir con sus encomiendas

csw02 ver2

Documents