Las áreas de conocimiento principales que componen el área de competencia, conocimientos básicos son los siguientes:

Transcripción

1 Competency Area 1: Foundational Knowledge (Fundamentos del Conocimiento) Las áreas de conocimiento principales que componen el área de competencia, conocimientos básicos son los siguientes: 1.1 Process Definition (Definición del Proceso) Esta área de conocimiento esboza los conceptos fundamentales y las habilidades que permiten a los profesionales de la ingeniería de software crear, usar, y ajustar los procesos definidos que componen PSP. 1.2 Process Elements (Elementos del Proceso) Esta área de conocimiento delinea los componentes que se incluyen en cualquier proceso personal y constituyen un marco para organizar el trabajo en un proyecto. 1.3 Measurement Principles (Principios de Medición) Esta área de conocimiento describe las métricas del proceso y del producto y explica por qué es importante medir para producir trabajo de alta calidad. 1.4 Statistical Elements (Elementos de Estadística) Esta área de conocimiento analiza las estadísticas que proveen una base para la planificación y el seguimiento de las metodologías utilizadas en el PSP, y que también proporcionan un medio objetivo de analizar y mejorar los procesos personales. Knowledge Area 1.1: Process Definition (Definición del Proceso) El PSP es una serie de procesos definidos que permiten a los profesionales de ingeniería (como los desarrolladores de software) construir productos de alta calidad a tiempo y dentro del presupuesto. Esta área de conocimiento esboza los conceptos y las habilidades necesarias para crear, ajustar, y usar los procesos definidos Process (Proceso) Un proceso describe la secuencia de pasos que un profesional calificado debe seguir para realizar una tarea determinada Defined process (Proceso Definido) Un proceso definido es una secuencia documentada de los pasos necesarios para hacer un trabajo específico. Los procesos se definen habitualmente para los trabajos que se realizan en varias ocasiones y hay que hacer de la misma manera cada vez que se realizan Benefits of defining a process Un proceso definido proporciona: un marco claramente delineado para la planificación, seguimiento y gestión del trabajo una guía para hacer el trabajo correcta y completamente, con los pasos en el orden apropiado. una base objetiva para medir el trabajo y dar seguimiento al progreso en la consecución de metas, y para refinar el proceso en las futuras versiones Una herramienta para la planificación y la gestión de la calidad de los productos Procedimientos acordados y entendidos por los miembros del equipo para usarlos coordinadamente en su trabajo y con ellos construir un producto común. un mecanismo que permite a los miembros del equipo apoyarse mutuamente en el transcurso del proyecto Process documentation (Documentación del proceso) Documentar un proceso es el acto de producir una representación escrita concreta de un proceso, los criterios de entrada y salida, las fases del proceso, y los pasos del proceso para cada fase. La documentación del proceso no debe contener material explicativo tutorial o de otra índole general que requieren las personas no calificadas o desinformadas sino que sólo debería facilitar la información necesaria que requieren profesionales con experiencia para ejecutar los pasos del proceso Processes and plans (procesos y planes) Considerando que los procesos definen conjuntos de pasos para realizar una tarea o proyecto, los planes incluyen tanto los pasos del proceso como otros elementos necesarios para el proyecto en especifico, como los recursos necesarios, las funciones de los miembros de diversos proyectos, programas, presupuesto, metas y objetivos, los compromisos y los riesgos identificados Personal processes (proceso personal) Un proceso de personal es un conjunto definido de pasos o actividades que orientan a las personas en su trabajo personal. Por lo general se basa en la experiencia y puede ser desarrollado completamente desde cero o puede basarse en otro proceso establecido y modificarse de acuerdo a la experiencia. Un proceso personal proporciona a los individuos un marco para mejorar su trabajo y para hacer constantemente un trabajo de alta calidad Enactable and operational processes (Patron de procesos, meta proceso y procesos operativos) Un Metaproceso (enactable process) define precisamente como hacer un proceso, incluye todos los elementos necesarios para usar un proceso. Un metaproceso (enactable process) consiste en una definición del proceso, los insumos que requiere, los agentes asignados, los recursos (por ejemplo, las personas, equipos, tiempo, dinero), y los criterios de salida. Un proceso operativo define con precisión lo que se debe hacer mediante una lista de tareas necesarias con el detalle suficiente para guiar a un profesional bien informado para hacer esa tarea. Los procesos operativos proporcionan suficientes indicaciones para que los equipos y los individuos puedan hacer planes detallados para hacer un proyecto y luego usar el proceso para guiar y seguir su trabajo. El PSP es un ejemplo de un metaproceso operativo Process phases (Fases del proceso) Un proceso definido, consta de una serie de pasos, elementos o actividades que comúnmente se llaman fases. Las fases de un proceso simple consisten en pasos sin mucha estructura. Los procesos más complejos pueden tener fases que son sus propios procesos. Los pasos o actividades en cada fase se definen por un script (véase 1.2.2). Como mínimo, cualquier proceso debe tener tres fases: planificación, desarrollo, y postmortem The PSP process phases (las fases del proceso PSP) El proceso básico PSP tiene tres fases. 1. Planificación: Elaborar un plan para hacer el trabajo. 2. Desarrollo: Realizar el trabajo. a. definir los requerimientos (see 4.2.2) b. diseñar el programa c. revisar el diseño y corregir todos los defectos d. codificar el programa e. revisar el código y corregir todos los defectos

2 f. construir o compilar y corregir todos los defectos g. probar el programa y corregir todos los defectos 3. Post mortem: Comparar los resultados reales con el plan, los datos históricos del proceso, elaborar un informe resumido, y documentar todas las ideas para la mejora de procesos Incremental development (desarrollo incremental) El PSP facilita el desarrollo incremental. Para proyectos grandes, cada incremento puede ser un proyecto completo de PSP, una fase de desarrollo PSP, o parte de una fase de desarrollo PSP, dependiendo de las necesidades particulares. Varios procesos de desarrollo incremental PSP están disponibles [Humphrey 05a]. Los métodos de PSP se usan más eficazmente con desarrollos incrementales a gran escala cuando cada incremento es de alta calidad Process tailoring (adaptación de procesos) La adaptación de procesos es el acto de personalizar la definición de un proceso para soportar la adaptación de ese proceso para un propósito particular (see 7.1) Process building and refining (consolidacion y refinamiento de procesos) Los profesionales calificados PSP pueden utilizar o adaptar los scripts de PSP para definir o personalizar sus propios procesos personales de alta calidad para la construcción de un producto. Deben definir sus propios procesos para garantizar que los procesos se ajusten a sus necesidades lo más posible [Humphrey 95, p. 16]. Como el proceso está definido para diversos proyectos, los usuarios del proceso deben procurar el perfeccionamiento y la mejora continua tanto en el proceso mismo como en la calidad de los productos construidos con ese proceso. Knowledge Area 1.2: Process Elements (Elementos del Proceso) Esta área de conocimiento describe los componentes que se incluyen en cualquier proceso personal y define un marco para organizar el trabajo del proyecto Process elements (Elementos del Proceso) Los elementos del proceso son los componentes de un proceso. El PSP contiene cuatro elementos básicos: scrpts(guiones), formas, measures (métricas), y estándares Scripts (guiones) Scripts are expert-level descriptions that guide personal enactment of a process. Contienen referencias a las formas, estándares, checklists, sub-scripts, y métricas pertinentes. Un script puede definir en un alto nivel todo un proceso o en un nivel más detallado alguna fase de un proceso en particular. Un script de proceso documenta El propósito u objetivo del proceso Los criterios de entrada directrices generales, consideraciones de uso, o restricciones fases o etapas que deben realizarse métricas del proceso y criterios de calidad condiciones de salida (como productos de trabajo definidos o datos requeridos del proceso) Forms (formas) Las formas proporcionan un marco adecuado y coherente para la recolección y registro de datos, especifican los datos requeridos y donde registrarlos. Según corresponda, las formas también definen los cálculos necesarios y la definición de datos. Los formularios en papel pueden ser utilizados si las herramientas automatizadas para la recopilación y el registro no son fácilmente accesibles En PSP, los checklist son formas especiales para guiar las revisiones personales. Cada elemento del checklist verifica un aspecto de la corrección del producto o la conformidad con las normas o especificaciones. Los puntos de la lista incluyen las ocurrencias más frecuentes de defectos que se pueden encontrar con una revisión. Todo el producto es revisado enfocàndose en un solo punto de la lista cada vez. Conforme se revisa cada punto, ese punto se va marcando como completado. Cuando la lista entera se ha completado, sirve como un registro de la revisión Measures (métricas) Las métricas cuantifican el proceso y el producto, proporcionan datos de cómo está funcionando el proceso permitiéndole a los usuarios Desarrollar perfiles de datos de proyectos anteriores que puedan ser usados para la planeación y mejora de procesos Analizar un proceso para determinar la manera de mejorarlo Determinar la eficacia de las modificaciones al proceso supervisar la ejecución de sus procesos y tomar decisiones supervisar la capacidad para cumplir los compromisos y tomar acciones correctivas cuando sea necesario Standards (estándares) Los estándares proporcionan definiciones precisas y consistentes que guían el trabajo, la recopilación y el uso de datos. Los estándares (como el de codificación, conteo de líneas, y tipos de defectos) permiten que las métricas se apliquen uniformemente en diversos proyectos y que se usen de manera habitual. Los profesionales de PSP deberían ser capaces de reconocer las áreas donde los estándares podrían ser útiles y elaborarlos cuando sea necesario. Knowledge Area 1.3: Measurement Principles (Principios de medición) Esta área de conocimiento describe la medición del proceso y del producto y explica por qué las métricas son esenciales para producir trabajo de alta calidad The need for measures (la necesidad de usar métricas) Las métricas se utilizan en PSP de manera que los cambios al proceso pueden ser identificados, evaluados, lógicamente implementados, y considerados efectivos o inefectivos Measurement types Para que sea útil para la gestión de procesos, toda medida debe ser definida, precisa, exacta, y significativa. Hay dos tipos principales de medidas utilizadas en la PSP: medidas del artefacto y de proceso. Las medidas de artefacto se utilizan para cuantificar las características del producto, tales como el tamaño del producto o de los defectos encontrados por elemento Las medidas del proceso describen o cuantifican el proceso de desarrollo o de corrección utilizado, y se clasifican como métricas históricas o actuales.

3 o o Las Métricas históricas del proceso se utilizan después de que el proceso se ha realizado para registrar los datos reales, tales como el tiempo de inspección, el tiempo de prueba, etc. Las métricas actuales del proceso se utilizan mientras el proceso se está ejecutando el proceso se utilizan para registrar datos como la duración de las reuniones de inspección, el tiempo de revisión de código como porcentaje del tiempo total de codificación, y similares. Tanto las métricas de artefactos como las de proceso pueden basarse en mediciones individuales o múltiples. La elección de métricas únicas o múltiples depende de la naturaleza de los datos y el uso que se le dará a cada una. Cuando se toman métricas múltiples, es necesario un procedimiento estadísticamente sensato para calcular los valores de utilización de estas métricas Defined measures (métricas definidas) Una métrica definida es aquella que tiene un significado explícito e inequívoco. Para las métricas de proceso, se requiere que el proceso esté definido con precisión para incluir criterios de entrada y salida para todas las fases. Las propiedades que se miden en un proceso también deben estar completa y explícitamente definidas Precise and accurate measures (Métricas precisas y exactas) Una métrica precisa es la que especifica un valor a un nivel adecuado de precisión, como con un número determinado de dígitos después del punto decimal. Una métrica exacta es la que mide correctamente la propiedad que se pretende medir. Las métricas pueden ser precisas y exactas, precisas, pero inexactas, imprecisa, pero exacta, o ambos imprecisa e inexacta. En gestión de procesos, las medidas deben ser tan precisas y exactas como sea posible Meaningful measures (Medidas significativas) Para ser significativa, las métricas deben representar realmente el verdadero valor de la propiedad del producto o proceso que se está midiendo, lo que indica que la medida representa una característica objetiva de un fenómeno real. La significancia de la métrica aumenta con el número y consistencia de las métricas que se van tomando Uses of process measures (usos de las métricas de proceso) Las métricas de proceso pueden ser utilizadas para evaluar las características del producto o proceso, para estimar elementos del producto o del proceso, o para predecir los resultados futuros. También puede ser utilizado como base para determinar las oportunidades de mejora y sus probables objetivos individuales y de negocio. Knowledge Area 1.4: Statistical Elements (Elementos de Estadística) La estadística es el fundamento para la planeación y las metodologias de seguimiento en PSP, además proporcionan un medio objetivo de analizar y mejorar los procesos personales. (Nota: Las definiciones específicas, interpretaciones o aplicaciones de términos estadísticos que hace PSP se mencionan en cada subsección del área de conocimiento que le corresponda.) Distributions (distribución) Una distribución es un conjunto de valores numéricos que son generadas por un proceso común (tamaños reales de las partes desarrolladas o estimaciones del tamaño de las partes) Mean (Media) La media es el valor promedio aritmético de una distribución. En PSP, la media es normalmente una estimación de la media de la distribución, no es la media real Variance (Varianza) La varianza es una medida de la difusión o estrechez de una distribución alrededor de la media. En PSP, la varianza es normalmente una estimación de la varianza de la distribución, en lugar de la varianza real Standard deviation (Desviación estándar) La desviación estándar es la raíz cuadrada de la varianza. A menudo se utiliza para caracterizar el rango esperado de la desviación entre una estimación y un valor real. Por ejemplo, un método en PSP utiliza la desviación estándar para clasificar el tamaño de software en tablas de tamaño relativo. La desviación estándar también se utiliza como parte del cálculo de los intervalos de predicción Correlation (correlación) La correlación mide el grado de relación que tienen dos conjuntos de datos. En PSP, la correlación está dada entre el tamaño estimado y real, y entre el esfuerzo estimado y el real Significance of a correlation (Significancia de una correlación) La significancia mide la probabilidad de que dos conjuntos de datos que tienen un alto grado de correlación sea por casualidad. Las estimaciones de tamaño y esfuerzo en PSP son más fiables cuando se basan en datos históricos que tienen un alto grado de correlación que es significativo Linear regression (Regresion Lineal) La regresión lineal determina aquella línea que se acerca a los datos y que minimiza la varianza de los datos con respecto a dicha línea. Por ejemplo, cuando el tamaño y el esfuerzo se relacionan linealmente, la regresión lineal puede utilizarse para obtener estimaciones de esfuerzo a partir de las estimaciones del tamaño Prediction interval (Intervalo de predicción) El intervalo de predicción provee el rango alrededor de una estimación hecha mediante regresión lineal en el que el valor real caerá con una probabilidad certera. Por ejemplo, en PSP, el 70% de intervalo de predicción de una estimación de tamaño o de tiempo implica un 0.7 de probabilidad de que el valor real de tamaño o tiempo estará dentro del rango definido por el intervalo de predicción Multiple regression (regression multiple) La regresión múltiple se utiliza en PSP, cuando las estimaciones de tamaño o tiempo dependen de más de una variable. Por ejemplo, si las modificaciones de los programas requieren mucho más tiempo que las adiciones, entonces -añadir y modificar se pueden separar en dos variables para el cálculo de regresión Standard normal distribution (distribución normal estándar) La distribución normal estándar es una distribución normal que se ha convertido a una media de cero y una desviación estándar de uno La distribución normal estándar se usa en PSP al construir una tabla de estimación de tamaño Log-normal distribution (Distribución logarítmica normal) Muchas de las operaciones estadísticas suponen que los valores de los datos se distribuyen normalmente, pero algunas métricas de PSP no cumplen con este requisito. Por ejemplo, los valores de tamaño no pueden ser negativos, pero pueden tener valores pequeños

4 que están cerca de cero. Estas distribuciones también suelen tener probabilidades más altas de tener valores grandes que una distribución normal. Cuando una transformación logarítmica se aplica a un conjunto de datos de este tipo, la distribución resultante puede tener una distribución normal y, por tanto, adecuado para los análisis estadísticos de datos que suponen una distribución normal. Los parámetros estadísticos de la distribución normal se pueden calcular y luego transformarse de nuevo a la distribución original. Los datos de tamaño en PSP obedecen generalmente a una distribución logarítmica normal, por lo que deben transformarse en una distribución normal para la construcción de una tabla de estimación de tamaño Degrees of freedom (Grados de libertad) Los grados de libertad (df) miden el número de puntos de datos (n), en comparación con el número de parámetros (p) que se utilizan para representarlos. En la regresión lineal, dos parámetros (ß0 y ß1) describen la línea que se utiliza para aproximar los datos. Desde al menos dos puntos son necesarios para determinar una línea, el número de grados de libertad es n-2. En general, el número de grados de libertad es n-p The t-distribution (la distribución T) La distribución t permite la estimación de la varianza de una distribución normal, cuando los verdaderos parámetros no son conocidos, permitiendo así el cálculo de los parámetros estadísticos basados en estimaciones de datos de la muestra. Como la distribución normal, tiene forma de campana, pero varía dependiendo del número de puntos en la muestra. Para menos puntos, la distribución es corta con cabos gruesos. Conforme aumenta el número de puntos, la distribución se hace más alta, con pequeños cabos y aproximaciones a la distribución normal. En PSP, la distribución t es importante porque ayuda a determinar la significancia de una correlación y el intervalo de predicción para la regresión, cada una de las cuales depende del número de puntos en el conjunto de datos de la muestra. Competency Area 2: Basic PSP Concepts La segunda área de conocimiento, presenta los conceptos básicos de mejora de procesos y habilidades en las cuales PSP está fundamentado. Las áreas de conocimiento principales que componen esta área de competencia son las siguientes: 2.1 Process Fidelity (Adherencia al proceso) - Esta área de conocimiento introduce el concepto de adherencia al proceso y aborda el efecto de la misma respecto a la calidad del proceso. 2.2 Data colecction (Recolección de Datos) - Esta área de conocimiento aborda habilidades y conceptos relativos a la recolección y utilización de datos de proceso. 2.4 Data Analysis (Análisis de Datos) - Esta área de conocimiento describen los conocimientos y aptitudes necesarios de los profesionales PSP para analizar los datos que se recogen del proceso. 2.5 Process Improvement (Mejora de Procesos) - Esta área de conocimiento describe los conocimientos y habilidades necesarias para los profesionales de PSP para mejorar su propio proceso personal definido. Knowledge Area 2.1: Process Fidelity (Adherencia al proceso) Esta área de conocimiento introduce el concepto de adherencia al proceso y aborda el efecto de la misma respecto a la calidad del proceso Process fidelity (Adherencia al proceso) La adherencia al proceso (a veces llamada la disciplina del proceso o el cumplimiento del proceso) es el grado de que los individuos siguen su propio proceso personal definido. El objetivo de la adherencia al proceso es mejorar el rendimiento de trabajo y construir productos de mayor calidad. A menos que el proceso sea cumplido fielmente, la mejora del proceso no es posible Process fidelity and useful data (Adherencia al proceso y datos útiles) Con el fin de tener datos significativos de la aplicación y mejora de un proceso personal, el proceso debe seguirse tal como se definió Process fidelity and product quality (Adherencia al proceso y calidad del producto) La calidad del producto se rige por la calidad del proceso utilizado para su desarrollo. No es suficiente definir un proceso de alta calidad, los individuos deben seguir ese proceso al elaborar el producto. La creación y el uso consistente de un proceso de alta calidad se traducirán en la construcción de productos de alta calidad. La calidad del producto, a su vez, tiene un efecto directo sobre la capacidad de los individuos para cumplir el calendario y los objetivos presupuestarios del producto Process fidelity and planning (Adherencia al proceso y planeación) Cuando un proyecto está planeado conforme a procesos eficaces y eficientes y se hacen estimaciones basadas en datos sólidos, el resultado del compromiso de entrega, probablemente será exacta. Cuando los proyectos se realizan de acuerdo a las indicaciones dadas en un plan preciso, se suelen entregar a tiempo, siempre y cuando el trabajo se realice con procesos definidos y se realicen ajustes al plan a fin de reflejar los cambios en las condiciones del proyecto Process fidelity and performance improvement (Adherencia al proceso y mejora del desempeño) Un proceso bien definido y medido que se sigue fielmente permite a las personas seleccionar los métodos que mejor se adaptan a sus habilidades particulares soporten las tareas que se debe realizar. Las personas deben utilizar procesos personales bien definidos y medidos con el fin de mejorar consistentemente su desempeño. Knowledge Area 2.2: Data Collection (Recolección de datos) Esta área de conocimiento aborda habilidades y conceptos relativos a la recolección y utilización de datos de proceso Collecting data (recopilación de datos)

5 El PSP se basa en los datos ya que los individuos no pueden mejorar sus procesos de trabajo a menos que entiendan exactamente cómo trabajan y exactamente que hacen. Los datos deben utilizarse para ubicar las áreas de mejora y para proporcionar una base para medir los efectos de los cambios hechos al proceso. Entre los beneficios de la recolección y análisis de los datos se incluye: el establecimiento de estándares para productos y procesos determinar si un determinado producto o proceso cumple con los criterios definidos controlar de manera precisa el trabajo de los individuos generar indicadores de desempeño de los individuos mejorar el rendimiento personal gestionar la calidad de los productos producidos estimar cuando es que el trabajo estará terminado planear, dar seguimiento y reportar precisamente acerca del trabajo Collecting useful data (Recolección de datos útiles) Para ser más útiles, los datos deben ser recogidos de acuerdo a las siguientes directrices: El proceso de recopilación de datos debe tener objetivos y planes específicos. Los datos reales deben ser seleccionados por su relevancia en la aplicación de un modelo o una hipótesis. Los datos deben ser recogidos por aquellas personas que realmente los van a utilizar, y deben entender la importancia y tener el cuidado de recoger información precisa y pertinente. El proceso de recopilación de datos debe incluir consideraciones sobre el impacto que tiene la recopilación de datos en la organización y su gente. El plan de recolección de datos debe contar con el apoyo de la gerencia, la propia gerencia debe considerar la recolección de datos como una inversión de alto valor en términos de poder ser capaces de predecir con precisión los costos de desarrollo de productos y programas, así como proporcionar una base para mejorar la eficiencia de la organización y la calidad de sus productos Collecting high-quality data (recopilación de datos de alta calidad) Los datos de software son altamente propensos a errores. La mejor manera de garantizar que los datos son de alta calidad es entrenar a los individuos en métodos adecuados para tomar medidas del proceso y registrar los datos que recojan. El uso de herramientas automatizadas para la recopilación de datos, cuando las herramientas adecuadas están disponibles, puede ayudar a mejorar la calidad de los datos ofreciendo a las personas un medio conveniente para la captura de información de los procesos inmediatamente después de que esta se genera Ensuring data quality (Garantizar la calidad de datos) La mejor manera de asegurarse de que se recogen datos de alta calidad es hacer que los individuos recojan su propia información en tiempo real (o cuanto antes después de que se generan los datos). Sin embargo, los individuos deben estar seguros que los datos de su proceso personal no serán utilizados para evaluar su desempeño si la gente teme que sus datos sean utilizados para clasificarla o para castigarla, no recogerán datos exactos, si es que recogen alguno Using data for planning purposes (Usar los datos para fines de planificación) Datos de alta calidad son útiles para hacer planes personales precisos, sin embargo, cualquier conjunto de datos (independientemente de la calidad) es mejor que no tener datos. Siempre que sea posible, cada producto, trabajo o proyecto debe ser planeado con estimaciones que se basen en datos históricos análogos (véase el punto 2.3 de las medidas para los tipos de datos que normalmente se utilizan para las estimaciones). Las mejores estimaciones se basan en datos reales de uno o más productos anteriores, trabajos o proyectos de la misma naturaleza. Cuanto más similares sean los esfuerzos anteriores al que se está planeando, más probable será que se llegue a una estimación exacta. Mientras más datos históricos se utilicen al hacer una estimación, es más probable que la estimación sea exacta. La estimación de un trabajo grande o un proyecto completo como un compuesto de varios subproyectos compuesto de productos de trabajo pequeños más precisa que la estimación del proyecto como una gran unidad única. Knowledge Area 2.3: Data Measures Esta área de conocimiento se describen las cuatro métricas básicas de PSP Basic PSP measures (Métricas Básicas de PSP) Las métricas básicas de PSP son el tiempo, tamaño, calidad (defectos), y datos de calendario Time measures (Metricas de Tiempo) El tiempo se mide en minutos y se registra mientras se está haciendo el trabajo, porque los tiempos registrados después es más probable que sean inexactos. Los componentes básicos son start date, start time, end date, end time, interrupt time, off-task time, and delta time. El time in phase es el tiempo planeado o real invertido en una fase particular del proceso. El interrupt time no se incluye en la medición del tiempo para una tarea o fase del proceso. Si hay una interrupción durante el trabajo, ese tiempo se resta de la medición del tiempo.

6 El off-task time es el tiempo haciendo otras cosas que las tareas del proyecto previsto, por lo general, no es medido o un seguimiento, ya que no contribuye a alcanzar los objetivos de horario establecido. off-task time incluye el tiempo pasado en la gestión administrativa y en reuniones, asistir a cursos de formación, lectura de correo electrónico, o cualquiera de las otras actividades esenciales que un miembro del equipo debe hacer. off-task time para una tarea determinada o período de trabajo se calcula restando el delta time total del tiempo total dedicado a una tarea. Delta time es el tiempo que se tardó en completar una tarea o fase del proceso. Se calcula como el tiempo final menos el tiempo de inicio (menos el tiempo de interrupción). Los registros de tiempo son más exactos cuando se recopilan con una herramienta automatizada, la herramienta debe ser capaz de registrar el inicio y finalización así como las fechas, calcular el tiempo transcurrido, y restar el tiempo de interrupción del tiempo transcurrido para calcular el delta time. Cada entrada en el registro de tiempos debe también incluir los nombres de la fase o paso del proceso, el producto y el elemento que se está trabajando, la tarea del proyecto que se está realizando, y la persona haciendo el trabajo Size measures (métricas de tamaño) Una métrica de tamaño se utiliza para medir qué tan grande es un producto de trabajo. Las métricas de tamaño se seleccionan de manera que sean apropiadas para el producto de trabajo, por ejemplo, la utilización de páginas (en vez de palabras o letras) como una medida para documentos, o tomar en cuenta las tareas de programación y el lenguaje para los componentes de software (ver 3.1 y Áreas de Conocimiento 3,2). Los datos de las métricas de tamaño deben recogerse en tiempo real en la medida de lo posible porque los datos recogidos después de los hechos es más probable que sean inexactos. La medición de tamaño se aplica no sólo a los componentes del producto final, sino también a los componentes y versiones provisionales de los productos. Los datos de tamaño son más exactos cuando se recopilan utilizando una herramienta automática en la que se registran tanto el tamaño planeado como el real de los componentes de productos diferentes, usando las categorías de las métricas estadísticas de tamaño descritas en el La herramienta debe calcular los totales de los datos para cada categoría de tamaño o de otra manera, garantizar la propia consistencia de los datos que obtiene Quality measures (defect data) medidas de calidad, datos de defectos En la PSP, la calidad del producto se mide en términos de defectos. Un defecto es cualquier cosa en algún componente de software o del producto que debe ser cambiado para que sea correctamente diseñado, desarrollado, mantenido, fortalecido, o usado. Los defectos pueden estar en el código, diseño, requerimientos, especificaciones, u otra documentación. Un nuevo defecto se puede inyectar, mientras que se corrige otro defecto. En este caso, el segundo defecto se registra por separado, con una referencia (llamada de referencia) al defecto original. El tiempo necesario para corregir cada defecto incluye el tiempo total requerido para encontrar y solucionar el problema, así como validar la corrección. El tiempo de corrección se registra por separado para cada defecto. Los defectos deben registrarse tan pronto como se descuben, de preferencia utilizando una herramienta automatizada. Los siguientes datos deben recopilarse para cada defecto encontrado: número de identificación del defecto, fecha en la que fue descubierto, la fase en la que se inyecta, fase en la que fue eliminado, el tipo de defecto, el tiempo para encontrarlo y corregirlo, y una breve descripción Defect type standard (estandar de tipos de defectos) El estándar define las categorías dentro de las cuales pueden ser colocados defectos similares. La asignación coherente de los defectos similares a la misma categoría de tipo de defecto es fundamental para el análisis del proceso Schedule measures (métricas de fechas) Las métricas de fechas se usan para planificar, cuando es que el proyecto debe terminar y para dar seguimiento al mismo contra el plan. Los datos de las fechas son más exactos cuando se recopilan utilizando una herramienta automatizada que registre nombres y descripciones de las tareas previstas, las fases en las que el trabajo se hará, producto o elemento en cuestión, fechas pertinentes comprometidas para completar las tareas, y las fechas en que se terminaron las tareas. Los datos de las fechas deben ser recolectados en tiempo real en la medida de lo posible, sobre todo la información de las fechas de terminación de las tareas, ya que esta es la manera de obtener el earned value (valor ganado) (EV) que permite a los individuos el seguimiento de sus progresos en relación con el calendario previsto (ver 4.5) Derived measures (métricas deribadas) PSP ofrece un conjunto de métricas de rendimiento y calidad para ayudar a las personas a aplicar y mejorar sus procesos personales. Las métricas derivadas específicas se revisan en las áreas de conocimiento posterior. Knowledge Area 2.4: Data Analysis (análisis de datos) Esta área de conocimiento describe los conocimientos y habilidades necesarias para los profesionales de PSP que les permitan analizar los datos que recolectan del proceso Measurement framework and data analysis (framework de medición y análisis de datos)

7 Todas las medidas en PSP están relacionadas. Las personas deben entender cómo cada métrica se relaciona con las demás y cómo pueden ser utilizados para obtener las medidas que proporcionan información sobre la eficacia del proceso Postmortem Un análisis postmortem sobre el trabajo realizado en una fase o proyecto proporciona información valiosa Los datos del proyecto actualizado a la fecha, tamaño, defectos, calendario (real, hasta la fecha, y porcentaje(%) a la fecha) los cálculos actualizados de calidad y rendimiento una revisión del desempeño contra lo planeado banco de datos históricos actualizado para el tamaño y la productividad ajustes necesarios al proceso, basado en datos personales (notas tomadas en formas de propuestas de mejora de procesos (PIP), cambios en el diseño de las listas de inspección de código indicados por los defectos que se escaparon de alguna fase, etc.) Performance measures (métricas de desempeño) Las medidas clave del desempeño del proceso personal son capacidad para cumplir los compromisos de calendario en el desarrollo de los componentes prometidos calidad de los elementos entregados métricas de proyecto especificas Performance baselines (líneas base del rendimiento) Antes de que las personas puedan mejorar su desempeño, primero tienen que comprender el nivel de su desempeño actual. Después de recoger los suficientes datos del proyecto que nos proporcionen una cantidad significativa de información para el análisis, las personas deben realizar un análisis de base de su desempeño hasta la fecha y formular cambios adecuados en los procesos para mejorar su desempeño en las áreas problemáticas Combined measures (métricas combinadas) Las métricas se pueden combinar para proporcionar datos útiles para los planes de futuros proyectos y mejoras en los procesos. Por ejemplo, las medidas de varios proyectos pueden ser combinadas para crear un gráfico que muestra las tendencias en el tamaño estimado frente a tamaño real para proporcionar datos para las futuras estimaciones de tamaño Analyzing historical data (análisis de datos históricos) Los datos deben ser examinados para determinar si son adecuados para el análisis. Por ejemplo, los datos de los proyectos basados en el lenguaje C# no pueden proporcionar una correlación adecuada para el análisis de proyectos basados en el lenguaje C ++. Los datos históricos también deben ser examinados para determinar si la correlación es adecuada y significativa como base para los procesos de medición y análisis del proyecto Analyzing size-estimating accuracy (Análisis de la precisión de la estimación del tamaño) Los datos Históricos del tamaño estimado frente a tamaño real tomados del proceso personal pueden ser analizados para determinar las posibles causas de malas estimaciones. Considere las siguientes preguntas. Con qué frecuencia está lo estimado contra lo real dentro de los 70% de intervalo de predicción? Hay una tendencia a omitir partes en el diseño conceptual? Qué podría hacerse para mejorar las estimaciones? Están las estimaciones de tamaño sesgadas de alguna manera? Existe una tendencia a juzgar mal los tamaños relativos de las partes? Las estimaciones de tamaño mejoran con el tiempo? Analyzing effort-estimating accuracy Los datos históricos de las estimaciones de esfuerzo estimado vs esfuerzo real del proceso personal pueden ser analizados para determinar las posibles causas de malas estimaciones. Con qué frecuencia está lo estimado contra lo real dentro de los 70% de intervalo de predicción? Los errores de estimación de tamaño se correlacionan con los errores de estimación del esfuerzo? subestimar los proyectos correlaciona con un mayor porcentaje de retrabajo? Están mejorando las estimaciones de esfuerzo? Qué podría hacerse para mejorar la exactitud de la estimación? Analyzing size and time relationships (analisis entre la relacion de tamaño y tiempo) Los datos históricos del proceso personal pueden ser analizados para determinar cualquier relación entre tamaño y esfuerzo. Considere las siguientes preguntas. La productividad es estable? Por qué o por qué no? Existen diferencias cuantitativas entre los proyectos de mayor y menor productividad? Si es así, Cómo se podrían explicar estas diferencias cuantitativas? Analyzing phase yields (analizando los yields de las fases)

8 Los datos históricos del yield por fase del proceso personal pueden ser analizados para identificar los problemas y generar PIP s para posibles mejoras. Considere las siguientes preguntas Existe una relación entre el yield y la tasa de revisión (tamaño revisado por hora) para las revisiones de diseño código? Son encuentran suficientes defectos en las fases adecuadas? Las revisiones se están llevando a cabo de manera efectiva? Cuál es el aprovechamiento, son los defectos personales eliminados provechosamente? Cuál es el aprovechamiento personal de retiro de defectos para las diversas combinaciones de la fase de la valoración/del incidente? Analyzing defects injected per phase (analizando los defectos injectados por phase) Un análisis de Paretto de los tipos de defectos es una herramienta útil para analizar el proceso histórico de los datos personales de los defectos inyectada por fase. Considere las siguientes cuestiones. Determinar qué tipos de defectos se presentan con más frecuencia. Determinar qué tipos de defectos tardan más en encontrarse y corregirse. Analizar por fase y las tendencias generales de los defectos inyectado por unidad de tamaño. Analizar por fase y las tendencias generales de los defectos inyectados por hora Determining the cost of rework (determinar el costo del retrabajo) Los datos pueden ser analizados para determinar el coste del retrabajo. Tenga en cuenta estos aspectos al realizar un análisis. Determinar el porcentaje de tiempo del proyecto PSP que toma hacer una prueba libre de defectos. Determinar cuánto tiempo toman las pruebas para los proyectos de PSP. Determinar qué tipos de defectos son los más costosos para encontrar y corregir en términos de tiempo (por fase y por proyecto). Determinar los tipos de defectos más comúnmente encontrados en la compilación y las pruebas personales. Determinar los tipos de defectos más comúnmente encontrados en las pruebas de producto y en el producto entregado. Generar un análisis de Paretto para identificar las fases en las que los defectos encontrados en el producto fueron inyectados. Knowledge Area 2.5: Process Improvement (mejora de procesos) Esta área de conocimiento describe los conocimientos y habilidades que necesitan los profesionales PSP para mejorar su proceso personal definido Rationale for process improvement (Justificación de la mejora de procesos) Las razones para la implementación de mejoras en los procesos son aumentar la previsibilidad y la calidad de las liberaciones, reducir el tiempo de ciclo, y mantener o mejorar la productividad Scope for process improvement (Ámbito de aplicación del proceso de mejora) Muchos tipos de procesos pueden y deben ser utilizados, incluidos los personales, de equipo, y los procesos de la organización. Aunque las personas implicadas en la mejora del proceso varía en función del tipo de proceso, los principios y métodos son idénticos para todos los tipos de proceso. Las personas que deben realizar las obras de mejora son las personas que utilizan el proceso: los miembros del equipo, los equipos, o incluso las organizaciones enteras. Las personas que no están utilizando actualmente el proceso normalmente son incapaces de definir las mejoras útiles y de ayuda para quienes lo usan. Son raras las grandes mejoras al proceso, pero los pequeños cambios pueden hacerse cada vez que un proceso se utiliza Benchmarks for process improvement (Puntos de referencia para la mejora de procesos) Los puntos de referencia pueden ayudar a las personas a motivar y orientar sus esfuerzos a la mejora de procesos. La estrategia general para obtener y utilizar puntos de referencia de proceso es. Identifique a uno o más proyectos que impliquen un trabajo similar. Establecer convenios de evaluación comparativa con los individuos que hagan un trabajo similar. Al hacerlo, hay que considerar o la similitud del trabajo o oportunidades para los equipos de interactuar y compartir datos relevantes o material confidencial o disposición a la divulgación o gestión de las revisiones y la supervisión Seleccionar los puntos de referencia de la mejor clase de entre los proyectos de colaboración. Periódicamente establecer y actualizar los objetivos de referencia para el costo, fechas, y el rendimiento de calidad Set performance improvement goals based on data (establecer las metas de mejora con base en los datos historicos) Antes de implementar cualquier cambio al proceso, los auditores de PSP deben analizar los datos históricos del proceso para determinar las causas originales de los últimos problemas de rendimiento. La ejecución de un análisis a fondo en las líneas base del rendimiento debe ayudar a los individuos a determinar las partes más importantes para la mejora. Una vez que se han identificado los

9 cambios potenciales, es importante fijar metas apreciables de la mejora del funcionamiento (e.g., reducir el costo del retrabajo en 20%) para saber cuándo se ha alcanzado la mejora deseada Record process improvement suggestions (registro de PIPS) PSP utiliza una Propuesta de Mejora de Procesos (PIP) la forma recoge los problemas en el uso del proceso y las sugerencias para mejorarlo o modificarlo. Mantener la forma del PIP a la mano en todo momento para la registro de ideas en oportunidades de mejora de los procesos antes de que estas ideas se pierdan Implement highest payoff improvements first (implementar primero las mejoras de mas alto valor) El análisis de datos personales genera muchas PIPs. Los auditores deben decidir la aplicación de la PIP que ofrecen el mayor potencial de mejora en comparación con el esfuerzo requerido para hacer los cambios Measure process changes (Métricas de Cambios de proceso) Debido a que los profesionales de PSP utilizan procesos personales como base para hacer su trabajo, deben entender la forma de actualizar sus procesos para reflejar los cambios realizados a esos procesos. Deben también ser conscientes del impacto que los cambios pueden tener en la aplicabilidad de sus datos históricos para el trabajo futuro que se realizará con el proceso modificado Monitor performance results (Monitor de resultados de desempeño) Para determinar si las mejoras de proceso ejecutadas han sido eficaces, Los profesionales de PSP periódicamente debe repetir los pasos para la línea base de sus procesos de trabajo y comparar contra el rendimiento de referencia para los objetivos de mejora previamente establecidos. El Bolstering es el recuerdo selectivo de únicamente los resultados que refuerzan una opinión o creencia, por lo general se manifiesta por olvidar los fracasos y recordar solamente los éxitos. El uso de todos los datos de PSP de todos los proyectos debe evitar el bolstering. Clutching es la tendencia a un mal rendimiento cuando están bajo presión o cuando un buen resultado es especialmente crítico, negando así el desempeño exitoso de los proyectos anteriores utilizando los mismos procesos. Siguiendo procesos establecidos y usando datos (y algo de instinto) como base para crear instancias de cambios en el proceso, el Clutching puede ser minimizado o evitado Watch for improvement opportunities (Estar atento a las oportunidades de mejora) Cuando se trabaja en proyectos de PSP, los profesionales deben estar atentos a las nuevas áreas problemáticas y ser conscientes de las ideas para la mejora continua. Competency Area 3: Size Measuring and Estimating (métricas de tamaño y estimación) Esta área de competencia se describe la medición de tamaño y la estimación de los conceptos en que se basa PSP. Los elementos esenciales de la medición y estimación de tamaño son la capacidad de definir las medidas de tamaño adecuado y utilizar métodos disciplinados y datos históricos para calcular el tamaño. Las áreas de conocimiento principales que componen esta área de competencia son las siguientes: 3.1 Size Measures (métricas de tamaño) Esta área de conocimiento se exponen los objetivos para medir el tamaño, los criterios para la selección de una medida de tamaño, y el sistema de conteo de tamaño de PSP. 3.2 Size Data (datos de tamaño) Esta área de conocimiento describe las principales formas en que los datos de tamaño se utilizan en PSP. 3.3 Size Estimating Principles (principios de estimación de tamaño) En esta área de conocimiento se revisan los principios sobre los cuales se basa el proceso de estimación de tamaño de PSP. El PSP apoya la estimación de tamaño de muchos métodos, pero todos los métodos deben adherirse a estos principios. 3.4 Proxies Esta área de conocimiento se describe la selección y organización de los datos de proxy. 3.5 The PROBE Estimating Method (el método de estimación PROBE) PSP utiliza un proceso de estimación definido llamado basado en proxies (PROBE). Este método se utiliza para estimar tanto el tamaño como el esfuerzo. Esta área de conocimiento define cómo las estimaciones del tamaño se realizan mediante el método PROBE. 3.6 Combining Estimates (combinación de estimaciones) Esta área de conocimiento describe las distintas maneras en que las estimaciones pueden ser combinadas 3.7 Size Estimation Guidelines (guias de estimación de tamaño) Esta área de conocimiento se explican las limitaciones de la estimación de tamaño. Knowledge Area 3.1: Size Measures (métricas de tamaño) Esta área de conocimiento se exponen los objetivos para medir el tamaño, los criterios para la selección de una medida de tamaño, y el sistema de conteo de tamaño de PSP Rationale for using size measures (Justificación para el uso de medidas de tamaño) Entre los objetivos para utilizar métricas de tamaño se incluyen lograr la coherencia en la descripción de tamaño

10 normalizar los datos de tiempo y defectos lograr mejores estimaciones de tamaño y planes Types of measures (tipos de métricas) Las métricas pueden clasificarse como: Absolutas o relativas Explicitas o derivadas objetivas o subjetivas dinámicas o estáticas predictivas or explicativas Criteria for size measures (Criterios para las métricas de tamaño) Las buenas métricas de tamaño deben ser relacionadas con el esfuerzo de desarrollo o el tamaño del producto correlaciona estadísticamente con el esfuerzo de desarrollo? o El tiempo invertido en el desarrollo de las partes medidas del producto representan una parte significativa del trabajo del proyecto? definidas con precisión directamente contables adecuados para la planificación temprana Counting standards (estándares de conteo) Los estándares de conteo proveen una guía que es precisa sobre lo que debe contar específica para el lenguaje y el tipo de aplicación invariable, que de el mismo resultado cada vez que el estándar se aplica Physical and logical size (tamaño físico y lógico) Una medida de tamaño físico proporciona información acerca del tamaño de una entidad física (el número real de ocurrencias de un elemento en algún producto). Una medida de tamaño lógico también proporciona información sobre el tamaño, pero se basa en el recuento de las agrupaciones de entidades físicas que, se pueden agrupar lógicamente. La medida lógica del tamaño de una entidad física no corresponde necesariamente a la medida física del tamaño de esa misma entidad, dependiendo del estándar de conteo definido para la medida lógica Size accounting (conteo de tamaño) Los métodos de conteo de tamaño de PSP para el tamaño planeado, actual, y a la fecha define métricas para base (B): la parte no modificada del programa a la que se añaden mejoras posteriores added (A): código que se agrega a la base modified (M): la parte de la base de código que se cambia deleted (D): la parte de la base de código que posteriormente se borra reused (R): partes o elementos que son copiados sin cambios de una fuente distinta de la base added and modified (A&M): todo el código añadido y modificado new reusable (NR): una parte o elemento que se desarrolla con la intención de volverlo a utilizar después total (T): el tamaño complete del programa Using the size measure selection procedure Los pasos para la selección de medidas de tamaño son las siguientes. 1. Recopilar datos sobre el desarrollo de productos (recursos necesarios, las medidas de las características del producto, las condiciones especiales de desarrollo, etc.) 2. Ordenar los productos con base en los recursos necesarios. 3. Identificar las características que distinguen a los productos que requrieron el mayor esfuerzo de los que requirieron el menor esfuerzo. 4. Seleccione una métrica o métricas de tamaño. Para las métricas de tamaño viables determinar la correlación entre el tamaño y los recursos necesarios. Si no hay una correlación, repita los pasos 3 y 4 para las otras métricas de tamaño viables. Algunas métricas típicas de tamaño incluyen elementos de base de datos: un recuento de los campos, consultas, o de otros elementos de uso común en un producto de base de datos. líneas de código (LOC): un recuento de las líneas lógicas de código en un producto. elementos de la pantalla: un recuento de los elementos de una interfaz de usuario o GUI del producto. Tamaño del documento: un conteo de las paginas, líneas, palabras o caracteres del documento. Tamaño del diseño: un conteo de las clases, definiciones de datos, especificaciones de interface, o características definidas de interfaz grafica de usuario. Tamaño de los requerimientos: un conteo de páginas de requerimientos, narrativas o puntos de función.

11 Knowledge Area 3.2: Size Data (datos de tamaño) Esta área de conocimiento describe las principales formas en que los datos de tamaño se utilizan en PSP Size data help to make better plans (los datos ayudan a hacer mejores planes) El tamaño y el tiempo a menudo se relacionan, y cuando eso ocurre, las estimaciones de tamaño se pueden utilizar para estimar el esfuerzo. Los planes pueden ser creados con base en las estimaciones de tamaño y esfuerzo Size data are useful for tracking development effort (los datos de tamaño son útiles para el seguimiento del esfuerzo de desarrollo) Tamaño y el tiempo a menudo se relacionan, y cuando lo son, las estimaciones de tamaño se puede utilizar para dar seguimiento al esfuerzo Size data help in assessing program quality (los datos de tamaño ayudan a evaluar la calidad del programa) La normalización de los datos de los defectos basándose en el tamaño permite determinar la la calidad de la totalidad o una parte del proceso de desarrollo contenido relativo de defectos de algunas partes de programas grandes carga de trabajo futura para el mantenimiento y soporte Knowledge Area 3.3: Size Estimating Principles (principios de estimación de tamaño) En esta área de conocimiento se revisan los principios sobre los cuales se basa el proceso de estimación de tamaño de PSP. El PSP apoya la estimación de tamaño de muchos métodos, pero todos los métodos deben adherirse a estos principios Estimating is uncertain (la estimación es incierta) Nadie sabe cuán grande será el producto, y mientras mas pronto en el proceso se hace la estimación, menos se sabe. Las estimaciones pueden estar sesgadas por las necesidades comerciales y otras presiones Estimating is a learning process (la estimación es un proceso de aprendizaje) La estimación de mejora con la experiencia y con los datos Estimating is a skill (Estimar es una habilidad) Algunas personas pueden ser mejores estimando que otras. La mayoría de las personas mejoran en la estimación mediante la práctica Strive for consistency (Luchar por la coherencia) El objetivo del proceso de estimación del tamaño es que que constantemente se generen estimaciones objetivas hechas de la misma manera. Hacerlo, equilibrará las sobreestimaciones y las subestimaciones Use defined methods for making estimates(uso de metodos definidos para hacer estimaciones) Utilizar un proceso definido de estimación de tamaño facilita el aprendizaje, proporciona una estructura para el uso de datos históricos, establece una línea de referencia contra la cual se puede medir la mejora, y ayuda a eliminar el sesgo en el proceso Estimates are subject to error (Las estimaciones están sujetas a error) La exactitud de estimaciones fluctuará alrededor de una media. Las estimaciones pueden también tener cierto sesgo Estimate in detail (Estimación en detalle) Cuando se estima en partes, el error total será menor que la suma de los errores de las partes, suponiendo que las partes se estiman de forma independiente. La estimación de detalle también ayuda a asegurar que la estimación está completa Use historical data to make estimates (utilizar datos historicos para hacer estimaciones) Al hacer las estimaciones de tamaño, encontrar una manera de utilizar cualquier dato histórico disponible. Knowledge Area 3.4: Proxies (Proxies) Esta área de conocimiento se describe la selección y organización de los datos de los proxies Using proxies instead of a size measure (Usando proxies en lugar de una métrica de tamaño) La mayoría de las medidas de tamaño que cumplen los criterios necesarios no están disponibles durante la planeación. Un proxy es una medida sustituta que relaciona el tamaño del producto con la funcionalidad planeada y proporciona un promedio en la fase de planeación para juzgar (y por lo tanto, estimar) la probabilidad del tamaño de un producto Criteria for choosing a proxy (criterios para elegir un proxy) Los criterios de un buen proxy son los siguientes. El tamaño de la métrica del proxy debe correlacionar cercanamente con el esfuerzo necesario para desarrollar el producto correlacionar con los costos de desarrollo. El contenido de proxies en un producto debe ser directamente cuantificables.

12 El proxy debe ser fácil de visualizar en el inicio de un proyecto. El proxy debe ser adaptable a las necesidades de cada proyecto e individuo El proxy debe ser sensible a las variaciones de la implementación que afectan el costo o el esfuerzo Using relative size tables (usando tablas de tamaños relativos) Las tablas de tamaño relativo se utilizan para organizar los datos de los proxies para que los datos históricos puedan ser utilizados para estimar el tamaño de partes nuevas semejantes Building a relative size table (construyendo tablas de tamaño relativo) PSP establece dos procedimientos para la creación de una tabla de datos históricos de tamaños relativos: el método de clasificación y el método de la desviación estándar. Otros métodos pueden ser utilizados, pero deben cumplir con los principios de estimación de tamaño Building a relative size table with the sort procedure Cuando se utiliza el procedimiento de clasificación para la construcción de una tabla del tamaño relativo, las partes están separadas en categorías funcionales, tales como el cálculo, texto, datos, etc. La tabla se llena completando los pasos siguientes para cada categoría: 1. Ordenar los datos de tamaño. 2. Elija el valor más pequeño como muy pequeño (VS). 3. Elija el valor más grande como muy grande (VL). 4. Escoja el valor de la mediana como medio (M). 5. Para grande (L) y pequeño (S), elegir el punto medio entre M y VL, y M y VS, respectivamente Building a relative size table with the standard deviation procedure (La construcción de una tabla de tamaño relativo con el procedimiento de la desviación estándar) Cuando se utiliza el procedimiento de la desviación estándar para la creación de una tabla de tamaño relativo, las partes se han separado en categorías funcionales, tales como el cálculo, texto, datos, etc La tabla se llena completando los pasos siguientes para cada categoría: 1. Si los datos son una distribución logarítmica normal (como es usualmente el caso de los datos de tamaño de programa), transformar los datos en una distribución normal mediante el cálculo del logaritmo natural de cada dato, de no ser así saltarse este paso. 2. Calcular la media (avg) y la desviación estándar (s) del conjunto de datos. 3. Calcular la mediana de los tamaños a travez de VS = avg 2S; S = avg S; M = avg; L = avg+s; VL = avg+2s. 4. Si los datos originales fueron una distribución logarítmica normal, aplicar la transformación inversa mediante el cálculo del antilogaritmo de cada uno de VS, S, M, L, y VL; otra cosa no hacer nada. Knowledge Area 3.5: The PROBE Estimating Method (el método de estimación PROBE) PSP utiliza un proceso de estimación definido llamado basado en proxies (PROBE). Este método se utiliza para estimar tanto el tamaño como el esfuerzo. Esta área de conocimiento define cómo las estimaciones del tamaño se realizan mediante el método PROBE What is PROBE? ( Qué es PROBE?) PROBE es un procedimiento para estimar el tamaño y el esfuerzo. El procedimiento general es el siguiente. 1. Desarrollar el diseño conceptual (véase 3.5.2). 2. Identificar y clasificar los proxies. 3. Estimar los otros elementos. 4. Estimar el tamaño del programa. (Seleccione el método PROBE apropiado, como se describe en ) 5. Calcular los intervalos de predicción (para los métodos A y B solamente) (véase 3.5.8) Conceptual design (diseño conceptual) El diseño conceptual es una representación de alto nivel de los elementos del producto y de sus funciones. El diseño conceptual divide un producto deseado en sus partes principales. El diseño conceptual se utiliza únicamente como una base para construir la estimación de tamaño y esfuerzo (ver 4.2.4) y no necesariamente refleja cómo el producto real será diseñado y construido Formulate size estimates for proxies (Formular las estimaciones del tamaño de los proxies) Compare el tamaño de las piezas nuevas en el diseño conceptual contra las partes similares en la base de datos histórica de acuerdo al tipo y tamaño relativo. Utilice el número de elementos por parte y los datos históricos de tamaño por parte para estimar el tamaño de proxy Formulate estimates for various types of program elements (Formular las estimaciones para los distintos tipos de elementos de programa) Conteo de tamaño base (B). Modificaciones Estimadas (M). Eliminaciones Estimadas (D). Adiciones a la base Estimadas (BA). Partes Aañadidas Estimadas (PA). Reuso Estimado (R). Estimacion de nuevo reuso planeado (NR) Select the appropriate PROBE method

13 1. Compruebe si el método A puede ser utilizado para asegurar que los datos cumplen los criterios de abajo, y la correlación de la evaluación, ß0, y ß1. o o Usted tiene tres o más puntos de datos (estimados E y reales A&M) que correlacionan. El valor absoluto de ß0 es inferior al 25% del tamaño esperado del nuevo programa. o ß1 se sitúa entre 0,5 y 2. o o Si el método PROBE se puede utilizar, entonces, calcular el tamaño proyectado como y = ß0 + ß1(E), donde y = tamaño proyectado de modificaciones y añadiduras E = tamaño estimado del proxy ß0 y ß1 se calculan utilizando el tamaño de proxy estimado y el tamaño real de añadiduras y modificaciones 2. Si el método A no puede ser usado, revise para ver si el método B se puede utilizar. o o Usted tiene tres o más puntos de datos (A&M planeadas y A&M reales) que correlacionan. El valor absoluto de ß0 es inferior al 25% del tamaño esperado del nuevo programa. o ß1 se sitúa entre 0,5 y 2. o o Si el método PROBE B se puede utilizar, entonces, calcular el tamaño proyectado como y = ß0 + ß1(E), donde y = tamaño proyectado de modificaciones y añadiduras E = tamaño estimado del proxy ß0 y ß1 se calculan utilizando el tamaño pleaneado de añadiduras y modificaciones y el tamaño real de añadiduras y modificaciones. 3. Si los métodos A y B no puede ser utilizados y se tiene datos históricos, utilice el método C. Calcular el tamaño del proyecto como y = ß0 + ß1 (E), donde o o y = tamaño proyectado de modificaciones y añadiduras E = tamaño estimado del proxy o ß0 = 0 o ß1 = ActualTotalAdded&ModifiedSizeToDate o PlanTotalAdded&ModifiedSizeToDate 4. Si usted no tiene datos históricos, utilice el método D, que consiste en utilizar su juicio para estimar el tamaño de añadiduras y modificaciones Estimate program size (Estimar el tamaño del programa) Calcular el tamaño del proxy estimado, E = BA + PA + M. Calcular el tamaño proyectado de A&M, P = ß0 + ß1 (E), para los métodos A, B, y C. Para el método D, P = tu juicio profesional Calcular el tamaño de añadiduras planeado, A = A&M M. Calcular el tamaño total planeado, T = P + B M + R Count and calculate actual data for various program elements (Contar y calcular los datos reales para los diferentes elementos del programa) Contar BA, PA, M, D, R. Calcular el tamaño real del proxy, E = BA+PA+M. Contar el tamaño total real, T. Calcular el tamaño real de añadiduras, A = T-B+D-R. Calcular el tamaño actual de añadiduras y modificaciones, A&M = A+M. Contar el tamaño real de reuso nuevo, NR Prediction interval definition (Definición de intervalo de predicción) El intervalo de predicción se utiliza en los métodos PROBE A y B. Un intervalo de predicción es el intervalo en que el tamaño real es probable que caiga el 70% del tiempo no un pronóstico aplicable solamente si la estimación se comporta como datos históricos Knowledge Area 3.6: Combining Estimates (La combinación de estimaciones) Esta área de conocimiento describe las distintas maneras en que las estimaciones pueden ser combinadas Combine independent estimates (combinar estimaciones independientes) Utilice este método de combinar estimaciones independientes. 1. Hacer proyecciones de regresión lineal separadas. 2. Sumar los tamaños proyectados. 3. Sume los cuadrados de los rangos individuales y calcule la raíz cuadrada para calcular intervalo de la predicción Use multiple proxies (utilizar multiples proxies) Utilice regresión múltiple cuando hay (a) correlación entre el tiempo de desarrollo y cada proxy y (b) los proxies no tienen datos de tamaño y tiempo separados. 1. Identifique y clasifique cada proxie. 2. Utilice regresión múltiple para proyectar el tamaño del programa. y = ß0 + x1ß1 + x2ß xmßm 3. Calcular los intervalos de predicción.

14 UPI = projected size + range (70%) LPI = projected size range (70%) Knowledge Area 3.7: Size Estimation Guidelines (Directrices de la estimación del tamaño) Esta área de conocimiento describe las limitaciones de la estimación de tamaño Clustered or grouped data (datos amontonados o agrupados) Para datos amontonados o agrupados, las estimaciones de tamaño pueden no ser muy útiles para estimar esfuerzo. Sin embargo, la estimación de tamaño todavía puede ser útil en el cálculo del esfuerzo promedio Extreme data points (Puntos de datos extremos) Puntos extremos de datos pueden llevar a valores ß0 y ß1 erróneos, incluso habiendo alta correlación. Estimaciones hechas con puntos fuera de rango de los datos utilizados para calcular ß0 y ß1 son seriamente probables de estar equivocadas Unprecedented products (Productos sin precedentes) Resístase a hacer una estimación antes de terminar un estudio de viabilidad y un desarrollo de prototipos. No confunda el hacer estimación con adivinar Data range (rango de datos) Para datos amontonados o agrupados, las estimaciones de tamaño pueden no ser muy útiles para estimar esfuerzo. Sin embargo, la estimación de tamaño todavía puede ser útil en el cálculo del esfuerzo promedio. Competency Area 4: Making and Tracking Project Plans (construir y dar seguimiento a planes de proyecto) Esta área de conocimiento discute la capacidad de utilizar una estimación de tamaño del software para planear y dar seguimiento a un proyecto de software. Partes esenciales de la planificación del proyecto son la capacidad de construir una agenda, definir tareas, planear las tareas de conformidad a la agenda, y hacer un seguimiento de finalización de tareas contra lo planeado. Las áreas de conocimiento principales que componen el área de competencia son las siguientes: 4.1 PSP Planning Principles (principios de planeación) Esta área de conocimiento enuncia los principios sobre los que se basa el marco de planificación de PSP. 4.2 The PSP Planning Framework (marco de planificación de PSP) Esta área de conocimiento delimita el marco de PSP que integra las tareas de planificación, bases de datos históricos, y el seguimiento de las actividades. También dirige mediante PROBE para generar estimaciones de recursos en general. 4.3 Software Size and Effort (tamaño del software y esfuerzo) La planificación de proyectos requiere una estimación del tamaño del software (véase el área de Competencia 3). Esta área de conocimiento se describe la relación entre el tamaño y esfuerzo. 4.4 Task and Schedule Planning (tareas y calendario de planeacion) Esta área de conocimiento describe cómo utilizar una estimación global de los recursos para crear una agenda que define las tareas que deben completarse y la fecha de finalización prevista. 4.5 Schedule Tracking with Earned Value (Seguimiento contra el calendario del Valor Ganado) El sistema de Valor Ganado (EV) de PSP se usa para rastrear el progreso del trabajo realizado contra el plan. Esta área de conocimiento describe el cálculo de EV, usando el EV para determinar el progreso del trabajo contra el plan, y revisar el calendario previsto, con base en el EV medio obtenido hasta la fecha en el proyecto. 4.6 Planning and Tracking Issues (planeacion y seguimiento de asuntos pendientes) La administración debe mantenerse informada del estatus de proyecto. Los proyectos que no serán terminados a tiempo deben ser replaneados. Knowledge Area 4.1: PSP Planning Principles (principios de planeación) Esta área de conocimiento enuncia los principios sobre los que se basa el marco de planificación de PSP Plan your work (planea tu trabajo) Las personas que hacen el trabajo son los más adecuados para planificar. Las personas siempre deben desarrollar un plan de trabajo antes de comprometerse o iniciar un proyecto. Cuando las personas están involucradas en el desarrollo del plan, es más probable que se apeguen a ese plan. Los planes deben basarse en un proceso definido y datos históricos, y estar hecho con un nivel de detalle apropiado para el trabajo a realizar. Cuando es difícil hacer un plan exacto, comience con un plan preliminar y replanifique a menudo. Cuando el plan no corresponde al trabajo, revisar el plan What is a PSP plan? (que es un plan de PSP) Un plan de PSP define el trabajo y cómo se hará es una base para un acuerdo sobre el costo, horario, y los recursos para un proyecto es una organización estructurada para hacer el trabajo es un marco para la obtención de los recursos necesarios proporciona un registro a lo que inicialmente nos hemos comprometido Detailed plans (planes detallados) Los planes de trabajo detallados orientan a las personas y les permite precisamente el seguimiento de su progreso. Los planes detallados son más precisos, proporcionan medidas más precisas, y dan una mejor orientación para los planes de alto nivel. Los planes detallados también permiten que las personas puedan hacer proyecciones precisas y compromisos realistas, ser más productivos, hacer un trabajo de alta calidad, y mantener su motivación para alcanzar los objetivos del plan.

15 Knowledge Area 4.2: The PSP Planning Framework (El Marco de Planificación de PSP) Esta área de conocimiento delimita el marco de PSP que integra las tareas de planificación, bases de datos históricos, y el seguimiento de las actividades. También dirige usando PROBE para generar estimaciones totales del recurso Software product plan components (Plan de producto de componentes de software) Los componentes de un plan de producto de software son las siguientes. conjunto? El tamaño del proyecto: Qué tan grande es el proyecto y cuánto tiempo se necesitará para realizar el proyecto en su Estructura del proyecto: Cómo se llevará a cabo el trabajo? Cómo debe ser secuenciado las tareas? Estado del proyecto: Cuál es el estado del proyecto en un momento determinado? Cómo puede estimarse la fecha de finalización? Evaluación: Comparar los datos reales contra los estimados. Qué tan bueno fue el plan? Cómo se puede mejorar el plan la próxima vez? PSP planning framework (Marco de planificación de PSP) El marco de planificación de PSP consiste en siete tareas básicas. 1. Definir los requerimientos (see 4.2.3). 2. Producir el diseño conceptual (see 4.2.4). 3. Producir la estimación de tamaño del producto (see 3.5.5). 4. Producir la estimación de recursos (see 4.2.6). 5. Producir el calendario (see and 4.5). 6. Desarrollar el producto (see ). 7. Analizar el proceso (see and 2.3.2) Requirements definition (La definición de requerimientos) Empezar por definir el trabajo a realizar, en tanto detalle como sea posible. La precisión del plan depende de cuánto sepan las personas acerca de la labor a realizar en el momento en que se está planificando Produce the conceptual design (producir el diseño conceptual) El diseño conceptual (véase 3.5.2) es un acercamiento preliminar al producto, nombra los objetos previstos y sus funciones. Al hacer un diseño conceptual, varios acercamientos alternativos se pueden considerar para elegir el acercamiento óptimo para hacer el trabajo de desarrollo. Para productos grandes, varios pasos pueden ser necesarios para producir un diseño conceptual. Producir una lista preliminar de objetos del producto y sus funciones esperadas. o Comience con un diseño de alto nivel del sistema o del producto. o Subdividir las piezas resultantes en un nivel de detalle que corresponda a los elementos existentes en la base de datos histórica (si las hay). Utilice el método PROBE adecuado para producir estimaciones de recursos y de tamaño. El total de la estimación de los elementos para producir la estimación del producto Use PROBE for size and resource estimation (Utilizar PROBE para estimar tamaño y recursos) El método PROBE se utiliza para estimar el tamaño del producto y el tiempo necesario para hacer el trabajo (véase y 4.2.6) Select the appropriate PROBE method for resource estimation (seleccione el metodo PROBE adecuado para estimacion de recursos) Compruebe si el método A puede ser utilizado. o Se tienen tres o más puntos de datos (E estimada y el tiempo de desarrollo real) que se correlacionan. o El valor absolute de ß0 está cerca de 0. o ß1 está dentro del 50% de 1/(productividad histórica). Si el método A no puede ser usado, revise para ver si el método B se puede utilizar. o Se tienen tres o más puntos de datos (A&M planeadas y el tiempo de desarrollo real) que se correlacionan. o El valor absoluto de ß0 está cerca de 0. o ß1 está dentro del 50% de 1/(productividad histórica). Si el método B no puede ser utilizado y tiene datos históricos, utilice el método C. Si usted no tiene datos históricos, utilice el método D To-date time in phase (tiempos hasta la fecha en las fases) El tiempo a la fecha en fase es la suma de el tiempo real para una fase determinada en un proyecto en particular más el tiempo a la fecha de esa fase histórico de proyectos To-date percent time in phase (pocentaje de tiempo a la fecha en fase) El porcentaje de tiempo por ciento de la fecha en la fase es el porcentaje de tiempo al día en cada fase Distributing time across phases (La distribución de tiempo a través de las fases) El tiempo planeado se distribuye a través de fases usando el porcentaje de tiempo a la fecha en cada fase Schedule projection (proyección de calendario)

16 Un calendario de valor ganado proporciona una proyección de la fecha de terminación del proyecto (ver 4.5) Product development (desarrollo del producto) El desarrollo de productos es dirigido por el proceso personal definido usado para generar el plan. Como se hace el trabajo, los individuos recopilan y registran datos Process analysis (analisis de proceso) Al final de un proyecto, los datos recogidos son analizados (ver 2.3.2) Cost performance index (CPI) (índice de costo del desempeño) El índice de costo del desempeño (CPI) se calcula como tiempo de desarrollo total planeado/tiempo real total a la fecha. Knowledge Area 4.3: Software Size and Effort (tamaño y esfuerzo del software) La planificación de proyectos requiere una estimación del tamaño del software (véase el área de Competencia 3). Esta área de conocimiento se describe la relación entre el tamaño y esfuerzo Size and effort correlation (correlacion de tamaño con esfuerzo) Grandes proyectos de programación requieren más esfuerzo. Estimar con precisión el esfuerzo de programación requiere el uso de una medida de tamaño que tenga una correlación significativa con el esfuerzo. Los datos de tamaño son adecuados para la planificación si el valor de r² es más grande que 0.5 y si y si el área de la cola en el cálculo de la significancia es = 0, Productivity (productividad) La productividad es la relación del tamaño de un producto contra el tiempo dedicado a desarrollar este producto, por lo general se determina como medida de tamaño por hora. Knowledge Area 4.4: Task and Schedule Planning (planeacion de tareas y calendario) Esta área de conocimiento describe cómo utilizar una estimación global de los recursos para crear una agenda que define las tareas que deben completarse y la fecha de finalización prevista Project plan characteristics (Las características del plan de proyecto) Un plan de proyecto debe ser accesible: fácil de localizar y de referenciar claro: concreto y fácil de leer Específico: responsabilidades y costes identificados Preciso: nivel apropiado de precisión exacto: basado en datos relevantes y un proceso de cálculo objetivo Period plans and project plans (Planes del período y planes del proyecto) Un plan del período cubre una unidad de tiempo específica, tal como una semana o un mes. Un plan del proyecto describe todos los esfuerzos y costes para desarrollar un producto Task hours and working hours (Horas de tareas y horas de trabajo) Hora de Tareas es una medida del tiempo dedicado a trabajar en las tareas definidas del proyecto. Las horas de trabajo incluyen horas de la tarea y explican actividades de tareas no definidas tales como tiempo de lectura y contestación del y , atención en reuniones, etc Milestones (hitos) Los hitos son los indicadores clave del progreso del proyecto. Sus fechas de terminación pueden ser estimadas para poder seguir progreso contra ellas y los riesgos a su terminación puedan ser tratados antes de que vaya el proyecto seriamente fuera de tiempo Schedule plan requirements (requerimientos de la agenda planeada) Los elementos necesarios para elaborar un plan de tiempos son un calendario de tiempo disponible el orden en que las tareas se completarán esfuerzo estimado para cada tarea Task order (orden de las tareas) El orden de las áreas está determinado por la estrategia de desarrollo Cada tarea necesita criterios de la terminación. Las interdependencias de las tareas deben estar definidas Estimated task time (tiempo estimado de las tareas) El tiempo necesario para completar la tarea se estima en una de varias maneras, mediante: El tamaño del producto fabricado por la tarea y los datos históricos de productos con tareas similares una estimación total basada en datos de porcentaje a la fecha de procesos terminados similares una técnica apropiada PROBE de estimación PSP schedule plans (planes calendario) Los planes de calendario son producidos para los proyectos de PSP siguiendo estos tres pasos de progresión. 1. Elija un período de tiempo adecuado (por ejemplo, de tres a seis meses a partir de la fecha de inicio planeda). 2. Distribuya el tiempo disponible estimado para tareas a lo largo de la duración del calendario del proyecto. 3. Calcular el acumulativo de horas calendario planeadas al final de cada ciclo del proyecto.

17 4.4.9 PSP task plans (planes de tareas PSP) Los planes de trabajo son producidos para los proyectos de PSP siguiendo estos cuatro pasos. 1. Estimar el tiempo de trabajo en horas (véase 4.4.7). 2. Calcular la suma del total de horas previstas. 3. Calcule el plazo del plan en el cual cada tarea definida será terminada, basado en el cronograma (véase 4.4.8). 4. Calcular la fecha planeada para la finalización del del proyecto. Knowledge Area 4.5: Schedule Tracking with Earned Value (seguimiento al calendario con valor ganado ) El sistema de Valor Ganado (EV) de PSP se usa para rastrear el progreso del trabajo realizado contra el plan. Esta área de conocimiento describe el cálculo de EV, usando el EV para determinar el progreso del trabajo contra el plan, y revisar el calendario previsto, con base en el EV medio obtenido hasta la fecha en el proyecto Planned value (PV) (valor planeado) El valor planeado de una tarea es igual al tiempo planeado, expresado en porcentaje del tiempo total previsto para el proyecto. Por ejemplo, una tarea de 5 horas en un proyecto de 50 horas tendría un PV de Earned value (EV) (valor ganado) Earned Value es un método utilizado para el seguimiento de los progresos reales de trabajo terminado en contra del plan general del proyecto. Al completar cada tarea, su PV se suma al EV acumulado para el proyecto. Las tareas parcialmente completadas no contribuyen al EV total Using EV measures (usando metricas de valor ganado) Cuando se utiliza VE, tenga en cuenta estas limitaciones. El método EV supone que la tasa de finalización de la tarea en el futuro será aproximadamente la misma que en el pasado. Si este no es el caso, la proyeccion de EV no será exacta. Las medidas del método de EV progresan en relación con el plan. Si el plan es inexacto, las proyecciones de EV es también probable que sean inexactas. El método de EV asume que los recursos del proyecto son uniformes. Si el nivel de personal aumenta, las proyecciones de EV serán pesimistas, y si disminuye el personal, las proyecciones serán optimistas EV as a measure of actual progress relative to planned progress (EV como una forma de medir el progreso real en relación con los avances planeados) En cualquier momento durante un proyecto, la suma del valor obtenido para las tareas completadas representa el porcentaje de trabajo que se ha completado. Una comparación del EV acumulativo contra el PV acumulativo indica en un momento dado el progreso del trabajo contra el calendario planeado. Si PV es el mismo que EV: el trabajo está a tiempo EV es más grande que PV: el trabajo se termina antes de lo previsto PV es mayor que EV: el trabajo se ha retrasado Project tracking with EV (Seguimiento del proyecto con EV) Durante la planificación, el PV total de las tareas del proyecto se puede calcular para cada período de tiempo. Del mismo modo, sumando los EV s de las tareas completadas en cualquier período de tiempo en un proyecto, se determina el porcentaje de trabajo realizado hasta la fecha para el proyecto. En cualquier punto en el proyecto, el EV se puede comparar con el PV acumulativo para determinar si el proyecto está en tiempo, retrazado, o anticipado (see above) Calculating PV for each task (calculando el valor planeado para cada tarea) El PV para una tarea es calculado dividiendo el tiempo estimado (tiempo planeado) para esa tarea por el tiempo planeado total para todas las tareas, entonces se multiplica el cociente por Calculating PV for each time period (calculando el PV para cada periodo de tiempo) El PV de un periodo se calcula sumando los PVs para todas las tareas que se planeen terminar en ese periodo Calculating cumulative PV for a given time period (Cálculo del PV acumulado para un período de tiempo determinado) El PV acumulado hasta la fecha en un período de tiempo determinado se calcula sumando los PV s de todos los plazos precedentes al PV del plazo dado Calculating EV to-date against PV to-date (calculando el valor ganado a la fecha contra el valor planeado a la fecha) EV para un período de tiempo determinado y el EV acumulado para ese mismo período de tiempo puede calcularse utilizando el mismo procedimiento que para calcular el PV. El EV acumulativo puede ser comparado con el PV acumulativo para determinar si el proyecto sigue el calendario previsto (véase supra) Estimating the project completion date (Estimación de la fecha de terminación del proyecto)

18 La fecha estimada de terminación del proyecto se puede calcular mediante el cálculo de la EV promedio por semana hasta la fecha y, a continuación, utilizar el valor promedio de VE por semana para calcular el tiempo necesario para completar el valor planeado restante. Esto asume que el proyecto continúa ganando la tasa media de EV como antes. Knowledge Area 4.6: Planning and Tracking Issues (Planeacion y seguimiento de Issues) La administración debe mantenerse informada del estatus de proyecto. Los proyectos que no serán terminados a tiempo deben ser replaneados Informing management of issues (Informar a la administracion de los issues) Mantenga a la gerencia informada resultados de análisis de valor ganado e infórmeles sobre problemas de cumplimiento del calendario. Los datos acerca del estado del proyecto pueden ser útiles para obtener ayuda de la administración When to adjust a plan (cuando ajustar un plan) El plan debe reflejar la forma en que el individuo está realmente trabajando. Si no lo hace, el plan debe ser revisado. Cuando se revisan los métodos o los procesos del trabajo, el plan entero debe ser reexaminado Handling part-time assignments Asignaciones de tiempo parcial pueden ser problematicas porque porque las horas de trabajo se dividen entre varios proyectos. El intercambio conmutación frecuente entre las tareas hace el trabajo en cualquier tarea se dificulte, y obstaculiza la coordinación con otros miembros de equipo en un proyecto. Competency Area 5: Planning and Tracking Software Quality (planeacion y seguimiento a la calidad del software) Esta área de competencia describe la necesidad de construir productos que satisfagan las necesidades de los usuarios, las formas de medir el grado de satisfacción de las necesidades del usuario, y las maneras de construir productos de alta calidad. Las áreas de conocimiento principales que componen esta área de competencia son las siguientes: 5.1 PSP Quality Principles (principios de calidad) Esta área de conocimiento se esbozan los principios sobre los que se basa el marco de calidad de PSP. 5.2 Quality Measures (métricas de calidad) Los datos de PSP permiten la determinación de medidas de calidad de producto y del proceso así como de la eficacia del proceso en la eliminación de defectos. 5.3 Quality Methods (Métodos de Calidad) Las revisiones personales son efectivas y una manera eficaz de mejorar la calidad del producto y la productividad individual. Los diversos métodos de revisión son eficaces en diversas situaciones. 5.4 PSP Code Reviews (revisiones de codigo) Las revisiones de código deben seguir un proceso definido y emplear los checklists constructed con base en los datos personales de defectos. La coherencia en el seguimiento de una estrategia de revisión basada en la experiencia puede hacer revisiones más eficientes y eficaces. 5.5 PSP Design Reviews (revisiones de diseño) Las revisiones de diseño deben seguir un proceso definido de revisión, usando los checklists que están construidos sobre robustos principios de diseño. La coherencia en el seguimiento de una estrategia de revisión basada en la experiencia de medición puede hacer revisiones más eficientes y eficaces. 5.6 Review Issues (cuestiones de revisiones) Las revisiones pueden ser muy eficaces si se conducen usando las directrices basadas en experiencia extensa y cuantitativa Personal responsibility (responsabilidad personal) Para construir productos de calidad, los individuos deben sentirse personalmente responsables de la calidad de sus productos (see 7.4). Para construir productos de calidad constantemente, los individuos deben ser disciplinados en el desarrollo y en seguir los planes, en el seguimiento y la gestión de su tiempo personal, y mantener la calidad como la máxima prioridad The economics of quality (la economía de la calidad) Es menos costoso encontrar y corregir los defectos antes en un proceso, que después. Cuanto más tiempo permanece un defecto en un producto, mayor será el costo para extraerlo. Las pruebas son una manera ineficiente e ineficaz para eliminar los defectos. Es más eficiente prevenir los defectos que encontrarlos y arreglarlos La manera correcta es siempre la manera más rápida y más barata de producir un resultado de alta calidad. Las revisiones son fundamentalmente más eficientes que las pruebas para encontrar y corregir defectos Product quality (La calidad del producto) Un producto de calidad es aquel que satisface al cliente. Este producto debe satisfacer un umbral mínimo de funcionalidad y utilidad. El producto también debe satisfacer las expectativas del usuario con respecto a un número de otros criterios. El producto debe funcionar, es decir, desempeñarse con una coherencia razonable. Si este objetivo no se logra, entonces nada es más importante. Inquietudes adicionales de los usuarios podrían incluir o rendimiento o Seguridad o invulnerabilidad o Usabilidad

19 o funcionalidad El producto debe proporcionar la funcionalidad que el usuario necesita y en el momento que lo necesita. En muchos proyectos de desarrollo, las percepción de calidad de los usuarios es con frecuencia pasada por alto ya que los individuos pasan la mayor parte de su tiempo encontrando y eliminando los defectos Process quality (calidad del proceso) Un proceso de calidad debe satisfacer las necesidades de sus usuarios para construir productos de calidad de manera eficiente. Un proceso de calidad debe Construir productos de calidad sistemáticamente ser utilizable y eficiente ser fácil de aprender y adaptarse a las nuevas circunstancias Knowledge Area 5.2: Quality Measures (métricas de calidad) Los datos de PSP permiten la determinación de medidas de calidad de producto y del proceso así como de la eficacia del proceso en la eliminación de defectos Personal defect data (datos personales de defectos) Los datos personales de defectos son útiles para comprender y refinar el proceso personal. El análisis de estos datos proporciona un recurso valioso para la construcción de checklists personales de revisión To-date defects injected and removed (defectos insertados y removidos a la fecha) Los defectos insertados y removidos a la fecha es la suma de los defectos reales inyectados y retirados, para cada fase del proyecto, mas los defectos insertados y removidos a la fecha por fase de los históricos de los proyectos To-date percent defects injected and to-date percent defects removed (porcentaje de defectos inyectados y defectos removidos a la fecha) El porcentaje de defectos insertados a la fecha es el porcentaje de defectos insertados en cada fase. El porcentaje de defectos removidos a la fecha es el porcentaje de defectos removidos en cada fase Yield (rendimiento) El yield es el porcentaje de defectos en el producto que se eliminan en una fase particular o grupo de fases. Una métrica de yield se puede calcular para cualquier fase o grupo de fases Phase Yield (yield de fase) Phase yield es el porcentaje de defectos removidos durante una fase Process Yield (yield del proceso) Process yield es el porcentaje de defectos removidos antes de entrar en la fase de compilación (o antes de entrar a prueba la unidad si no hay fase de compilación) Review Yield (revision del yield) Review yield es el porcentaje de defectos en el programa encontrados durante la revisión Percent appraisal cost of quality (COQ) (Porcentaje de coste de evaluación de la calidad) Percent appraisal cost of quality (COQ) es el porcentaje de tiempo de desarrollo empleado en el diseño y revisión de código Percent failure COQ (Porcentaje de fracas de COQ) Percent failure COQ es el porcentaje de tiempo de desarrollo empleado en compilar y probar Cost of Quality (COQ) Costo de la calidad es el porcentaje de tiempo dedicado a realizar tareas de evaluación y en tareas correctivas. COQ define los asuntos relativos a la calidad en términos de gerencia y del negocio. Las principales métricas de COQ son: performance costs: los costos de hacer el trabajo en el primer lugar appraisal costs: el costo de examinar un producto para determinar su calidad failure costs: los costos de la corrección de un producto defectuoso, incluyendo todos los costos derivados de las deficiencias del producto. prevention costs: los costos de la elaboración e implementación de medidas para prevenir fallas COQ appraisal to failure ratio (COQ A/FR) (COQ relación de la evaluación de las fallas) COQ A/FR es la proporción de tiempo gastado en tareas de evaluación con respecto al tiempo invertido en tareas de corrección de fallas Defect Density (densidad de defectos)

20 Densidad de defectos es el número de defectos detectados por medida de tamaño. Se normaliza al tamaño del producto para permitir la comparación de diversos productos y procesos que los construyeron Process Quality Index (PQI) (índice de calidad del proceso) El índice de calidad del proceso (PQI) es una medida derivada que caracteriza la calidad de un proceso de desarrollo del software. El valor de PQI es el producto de cinco valores de componentes de perfil de la calidad. 1. Calidad de diseño se expresa como la proporción del tiempo de diseño entre el tiempo de codificación. 2. Calidad de revisión del diseño es la proporción de tiempo de revisión de diseño entre el tiempo de diseño. 3. Calidad de revisión de código es la proporción del tiempo de revisión de código de tiempo de codificación. 4. Calidad de codificación es la proporción de defectos de compilación entre medida de tamaño. 5. Calidad del programa es la proporción de defectos en pruebas de unidad entre una medida de tamaño. Los componentes PQI se normalizan a [0, 1] tal que el cero representa una mala práctica y el uno representa la práctica deseada. Las proporciones se representan en los ejes de un pentágono con la escala [0, 1]. El polígono resultante puede ser comparado con el pentágono que lo contiene para determinar la calidad del proceso. Los valores recomendados para cada componente PQI son los siguientes. La calidad del diseño es el mínimo de 1,0 o el tiempo empleado en hacer diseño detallado, dividido entre el tiempo empleado en codificación. Calidad de revisión de diseño es el mínimo de 1,0 o dos veces el tiempo empleado en la revisión del diseño detallado, dividido entre el tiempo empleado en el diseño detallado). Calidad de revisión de Código es el mínimo de 1,0 o dos veces el tiempo empleado en la revisión de código dividido entre el tiempo empleado en la codificación. Calidad de la revisión de código es el mínimo de 1,0 o dos veces el tiempo empleado en la revisión de código dividido por el tiempo empleado en la codificación. La calidad del código es el mínimo de 1,0 o 20/(10 + Defectos/Kloc en compilacion). La calidad del programa es el mínimo de 1,0 o 10/(5 + Defectos/Kloc en pruebas de unidad) Calculating values for the PQI components (Cálculo de los valores de los componentes PQI) Para calcular e interpretar los valores PQI: Multiplicar los cinco métricas de elementos PQI juntas para dar un número entre 0,0 y 1,0. Los valores inferiores a 0,5 indican que el producto es probable que sea de mala calidad. Cuanto menor sea el valor, el más pobre la calidad es probable que sea Composite PQI (Compoestos PQI) Una medida PQI compuesta representa la calidad del proceso global para un proyecto que construyó múltiples programas. Esta composición PQI se puede calcular de tres formas, cada uno de los cuales tiene ventajas y desventajas. 1. La medida del producto PQI se calcula tomando el producto de todos los PQI de los componentes del programa. a. Ventaja: Esta medida indicará rápidamente que un producto tiene componentes con valores bajos de PQI b. Desventaja: Para los grandes sistemas, los valores tienden a ser demasiado bajos para ser útiles en la gestión de sistemas de calidad. 2. La medida PQI general se determina mediante el uso de los valores globales para la totalidad de los programas calculando los valores de perfil de calidad de los componentes. Por ejemplo, el tiempo de revisiones sería la suma de los tiempos de revisión para todos los elementos de programa y los defectos de pruebas de unidad serían la densidad total del defecto para todos los programas combinados. a. Ventaja: Esta medida tiene la ventaja de ser fácil de calcular y proporcionar un indicador general de la calidad global del producto. b. Desventaja: Algunos componentes de mala calidad no podrán ser percibido por que hay un número de componentes de alta calidad. 3. La medida PQI mínimo se calcula utilizando el valor de PQI para este componente del programa que tuvo el valor de PQI mínimo. a. Ventaja: Esta medida tiene la ventaja de la rápida localización de cualquier componente de mala calidad. b. Desventaja: La medida no indica nada sobre la calidad del programa en general. Puesto que no hay la mejor metrica compuesta para todos los propósitos, las metricas compuestas de PQI se deben utilizar con el cuidado y su significado ser explicados a conciencia Phase defect removal rate (la tasa de corrección de defectos) Para cada fase de un proceso, la tasa de corrección de defectos de la fase es el número de defectos encontrados por hora en esa fase Review Rate (tasa de revisión)